Large NAT: ipf/ipnat, pf - opinions?

Stephane Raimbault segr at
Tue Nov 23 17:59:32 PST 2004

You mention diffrent ways to fine-tune pf. I'm particularly interested in 
the number of states.  I have a situation where I'm running pf around 8000 
states and the box seems to perform quite beautifully, I have increased the 
max states to 100K to cover large peaks which can occur, however I haven't 
yet observed anything about 10K.

One problem I do find, is if one IP has 200 ~ 500 states, the user reports 
timeouts thru the nat.

In my particular situation, I'm forwarding port 80 to a webserver in the nat 
environment and the clients are internet users.  I don't seem to have this 
problem when running natd on FreeBSD 4.9, however the load of the nat box is 
quite a bit higher (~ 10 times) then running pf on FreeBSD 5.3.

Any suggestions?

Here are my pf rules

# Set pf limits
set limit states 100000

# NAT the internal network
nat on $ext_vip from $web_servers port 80 to any -> ($ext_vip)
nat on $ext_vip from $ssl_servers port 443 to any -> ($ext_vip)
nat on $ext_if from $int_net to any -> ($ext_if)

# Forward ports from external to internal
rdr on $ext_if proto tcp from any to any port 80 -> $web_servers round-robin
rdr on $ext_if proto tcp from any to any port 443 -> $ssl_servers 

# forward ports from internal to internal
rdr on $int_if proto tcp from $int_net to $ext_if port 80 -> $web_servers 
rdr on $int_if proto tcp from $int_net to $ext_if port 443 -> $ssl_servers 
no nat on $int_if proto tcp from $int_if to $int_net
nat on $int_if proto tcp from $int_net to $web_servers port 80 -> $int_if
nat on $int_if proto tcp from $int_net to $ssl_servers port 443 -> $int_if


Content-Type: text/plain;
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On Monday 22 November 2004 19:29, Pawel Malachowski wrote:

>>  I'm interested in opinions/comparisons how ipnat and pf perform
>>on FreeBSD 5.x in real working large NAT setups (about 50Mbit/s, few
>>thousands of workstations, 300k of mappings or more). Problems noticed,
>>memory and CPU consumption, mbufs utilization etc.

While the state information in pf is slightly larger than that of ipfilter=
(and thus the memory consumption). pf offers many functionalities that make=
it the "easier-to-manage" tool. There are also a couple of optimizations in=
pf that should make it perform better, but only measuring your specific=20
application can tell you which is the better for you. I'd guess that pf can=
lift the load described above with an average workstation (good NICs and=20
plenty of RAM provided). Note, however, that for CPU consumption packets pe=
second is the important factor. For pf - with it's stateful inspection -=20
connection initialization has some meaning as well (once established, passi=
more traffic through a connection is cheap).

Depending on your application, you might find pf's TABLES which greatly=20
improve management of large IP-sets. There are also many options to fine-tu=
the number of concurrent states that a (NAT)rule can create. This helps to=
keep down memory consumption during DDoS-Attacks. The additional "adaptive=
timeouts" can also help to manage load peaks.

That is comparing pf 3.5 (what is in RELENG_5) with ipfilter 3.x (also in=20
RELENG_5). ipfilter 4.x has gained some, but isn't included in FreeBSD.

/"\  Best regards,                      | mlaier at
\ /  Max Laier                          | ICQ #67774661
X  | mlaier at EFnet
/ \  ASCII Ribbon Campaign              | Against HTML Mail and News

Content-Type: application/pgp-signature

Version: GnuPG v1.2.6 (FreeBSD)



Designer Mail isn't just fun to send, it's fun to receive. Use special 
stationery, fonts and colors. 
  Start enjoying all the benefits of MSN® Premium right now and get the 
first two months FREE*.

More information about the freebsd-net mailing list