On Thu, 22 Jul 2004, Brian Degenhardt wrote:
> I'm having an issue with NAT when multiple machines on the LAN ping
> multiple hosts on the WAN side at the same time. I've tested this on
> m0n0 1.0 and 1.1b16 and both exhibit this behavior.
Well, multiple machines pinging *multiple* hosts isn't the problem - it's
multiple machines pinging the *same* host. :-)
> My setup is this:
> linuxpc1: 172.16.0.200
> linuxpc2: 172.16.0.199
> LAN-m0n0: 172.16.0.1
> WAN-m0n0: 192.168.0.191
A private network address for the WAN? So you have another level of
> As far as m0n0wall configuration is concerned, it's pretty much
> vanilla. I set the devices, set the LAN ip and dhcp range and that's
> On both the linux boxes, I run fping -c 1 -w 1 ns1.google.com
> ns1.yahoo.com www.ingateusa.com and sleep for 5 seconds. Basically they
> send simultaneous pings to three hosts once a second.
> On the WAN side of the m0n0wall box, I've uploaded an run tcpdump via
> exec.php, here's what it sees:
> 02:08:43.250343 172.18.0.199 > ns1.google.com: icmp: echo request (DF)
> 02:08:43.302480 172.18.0.199 > www.ingateusa.com: icmp: echo request
> 02:08:43.302572 172.18.0.199 > ns1.yahoo.com: icmp: echo request (DF)
> 02:08:47.915300 192.168.0.191 > ns1.google.com: icmp: echo request (DF)
> 02:08:47.930059 192.168.0.191 > ns1.yahoo.com: icmp: echo request (DF)
> 02:08:47.935127 ns1.google.com > 192.168.0.191: icmp: echo reply (DF)
> 02:08:47.951580 ns1.yahoo.com > 192.168.0.191: icmp: echo reply (DF)
> 02:08:47.973592 192.168.0.191 > www.ingateusa.com: icmp: echo request
> 02:08:47.980707 172.18.0.200 > ns1.google.com: icmp: echo request (DF)
> 02:08:47.991093 172.18.0.200 > ns1.yahoo.com: icmp: echo request (DF)
I take it either the 172.16s or the 172.18s are typos.
> Note that some packets are not getting NATted?
That isn't *quite* the symptom I would have expected, but I guess if it
resolves "conflicts" by bypassing NAT rather than overwriting the entries,
that's what would happen.
> This seems to be a bug in freebsd but I was wondering if anyone had any
> pointers to how to fix it?
> Here's some references to one other guy who has seen this problem:
I don't know about the "router dies completely" part, but the basic
problem is that IPFilter's NAT code has no provision to handle ICMP
request/reply sequences *at all*, other than by the default handling that
has no ability to multiplex/demultiplex multiple clients' traffic. It's
not a bug, it's a deficiency. :-)
Right now, the only ICMP that IPFilter's NAT code pays special attention
to is ICMP errors, which is a completely different case (also broken in
the current m0n0wall betas, but the next one should have it fixed).