ICMP packets associated with NAT connections sent out wrong
yasuyuki.kozakai at toshiba.co.jp
Sat Jul 7 08:27:06 CEST 2007
I'll sort out observations from your report and try to explain my idea in
other mail after finishing some tests.
From: Jordan Russell <jr-list-2007 at quo.to>
Date: Fri, 06 Jul 2007 12:42:24 -0500
> Jordan Russell wrote:
> > BTW: does the LOG output indicate that netfilter translated the source
> > address of 22.214.171.124 to 192.168.0.133? If so, shouldn't it have
> > instead translated the *destination* address of 126.96.36.199 (=eth1) to
> > 192.168.0.133? Could this be why the ICMP packet was generated in the
> > first place?
> To clarify my question:
> If tcpdump on eth1 reports:
> 188.8.131.52.1703 > 184.108.40.206.25000
> while my LOG rule reports for the same packet:
> ... [SRC=192.168.0.133 DST=220.127.116.11 ... SPT=25000 DPT=25000
> isn't this saying that netfilter translated the *source* address of the
Yes, but from this log, we can say only that source address of TCP packet
was mangled, OR the source address of IP header in ICMP body was mangled.
Inserting LOG rule just before REJECT rule will clarify that.
> Since port 25000 is covered by a DNAT rule:
> -A PREROUTING -i eth1 -p tcp -m tcp --dport 25000 -j DNAT
> --to-destination 192.168.0.133
> shouldn't it have set the *destination* address of the packet to
> 192.168.0.133, while leaving the source address unchanged?
If TCP packet is valid, yes. If not, no address is mangled.
> So: It appears as though netfilter is (in rare cases) translating the
> source address of packets when it should be translating the destination
> address. Or am I misinterpreting the log output?
The current NAT code does that, but I suspect that it is due to bug.
-- Yasuyuki Kozakai
More information about the netfilter-devel