ICMP packets associated with NAT connections sent out wrong
kaber at trash.net
Thu Jul 5 14:21:52 CEST 2007
Yasuyuki KOZAKAI wrote:
> From: Jordan Russell <jr-list-2007 at quo.to>
> Date: Thu, 05 Jul 2007 00:51:05 -0500
>>Yasuyuki KOZAKAI wrote:
>>>>Jul 4 14:54:33 webby kernel: [packet out wrong interface] IN= OUT=eth1
>>>>SRC=184.108.40.206 DST=192.168.0.133 LEN=68 TOS=0x00 PREC=0xC0 TTL=64
>>>>ID=39698 PROTO=ICMP TYPE=3 CODE=3 [SRC=192.168.0.133 DST=220.127.116.11
>>>>LEN=40 TOS=0x00 PREC=0x20 TTL=239 ID=39262 PROTO=TCP SPT=25000 DPT=25000
>>>>WINDOW=64172 RES=0x00 RST URGP=0 ]
>>BTW: does the LOG output indicate that netfilter translated the source
>>address of 18.104.22.168 to 192.168.0.133? If so, shouldn't it have
>>instead translated the *destination* address of 22.214.171.124 (=eth1) to
>>192.168.0.133? Could this be why the ICMP packet was generated in the
> Hmmm, REJECT in your rule might generate it, but I'm not sure.
Its pretty certain the REJECT target, it defauls to port unreachable
and the network stack doesn't generate port unreachables for TCP.
Jordan, please post your ruleset.
>>>workaround fix is disable hardware checksum offload if you use it.
>>eth1 is running off a 10-year-old 3Com 3C905 adapter, which doesn't
>>appear to support hardware checksums. dmesg says:
>> 0000:01:0c.0: scatter/gather disabled. h/w checksums disabled
I can't find this message in the kernel tree. Which driver are you
More information about the netfilter-devel