Large NAT: ipf/ipnat, pf - opinions?
segr at hotmail.com
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.
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
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 freebsd.org
\ / Max Laier | ICQ #67774661
X http://pf4freebsd.love2party.net/ | mlaier at EFnet
/ \ ASCII Ribbon Campaign | Against HTML Mail and News
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (FreeBSD)
-----END PGP SIGNATURE-----
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