From: Patrick McHardy <kaber@trash.net>
To: netdev@vger.kernel.org
Subject: Re: stateless 1:1 NAT
Date: Wed, 17 Oct 2007 21:44:27 +0200 [thread overview]
Message-ID: <4716661B.3020301@trash.net> (raw)
In-Reply-To: <4716510E.3090300@andrei.myip.org>
Florin Andrei wrote:
> So here's the thing I'm trying to solve.
>
> Gigabit network.
> Dual homed firewall, doing 1:1 NAT for a bunch of web servers. Some
> protocols are allowed inbound to the servers (the external, NATed
> addresses).
> Firewall is running CentOS 5 (kernel 2.6.18)
>
> I run pktgen on a test machine to generate a whole lot of small UDP
> packets with random source addresses. I send the packets to the
> firewall, to one of the 1:1 NATed addresses, to a port that's blocked by
> the firewall.
> Meanwhile, I'm downloading a 2GB file from a web server through the
> firewall, in a while [ 1 ] loop, to monitor the functioning of the
> firewall.
>
> When I start the UDP flood, the current download is able to finish up,
> but a new one won't start. The firewall has one of the cores pegged at
> 100% CPU usage, with a lot of interrupts being generated all the time.
> I assume there's something related to conntrack, that's why I want to
> test stateless rules. I assume the firewall has much less work to do if
> it's doing everything stateless, at least at the NAT level.
Its not really related to the amount of work, conntrack has a fixed
limit of connections it will track, if you flood it with connections
it will stop accepting new ones at some point (you should see a message
about that in the ringbuffer). So as long as you have conntrack loaded
the problem will likely persist. But as I wrote, previously, 2.6.23 has
a change in the eviction algorithm that should make it behave much
better in the scenario you describe. It would be interesting if you
could test that. Alternatively you could of course just increase the
maximum number of conntracks.
> Is it going to be possible to combine stateless 1:1 NAT with stateful
> filtering?
Yes, but that probably won't solve your problem.
> By the way:
> OpenBSD 4.1 as a firewall fails even worse in this test case (it freezes
> instantly).
> OpenBSD 4.2 works fine under the UDP flood, as if nothing happened.
And Linux 2.6.23? :)
next prev parent reply other threads:[~2007-10-17 19:44 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-10-17 0:29 stateless 1:1 NAT Florin Andrei
2007-10-17 1:10 ` Herbert Xu
2007-10-17 18:14 ` Florin Andrei
2007-10-17 19:44 ` Patrick McHardy [this message]
2007-10-17 21:03 ` Florin Andrei
2007-10-26 17:49 ` Florin Andrei
2007-10-18 0:45 ` Herbert Xu
2007-10-24 19:12 ` Florin Andrei
2007-10-25 1:54 ` Herbert Xu
2007-11-09 21:04 ` Florin Andrei
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4716661B.3020301@trash.net \
--to=kaber@trash.net \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).