Linux Netfilter discussions
 help / color / mirror / Atom feed
From: Jordan Russell <jr-list-2007@quo.to>
To: Yasuyuki KOZAKAI <yasuyuki.kozakai@toshiba.co.jp>
Cc: netfilter-devel@lists.netfilter.org, netfilter@lists.netfilter.org
Subject: Re: ICMP packets associated with NAT connections sent out wrong  interface?
Date: Thu, 05 Jul 2007 00:51:05 -0500	[thread overview]
Message-ID: <468C86C9.7050204@quo.to> (raw)
In-Reply-To: <200707050111.l651Bu9t008798@toshiba.co.jp>

Yasuyuki KOZAKAI wrote:
>> Jul  4 14:54:33 webby kernel: [packet out wrong interface] IN= OUT=eth1
>> SRC=123.23.23.23 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=123.23.23.23
>> LEN=40 TOS=0x00 PREC=0x20 TTL=239 ID=39262 PROTO=TCP SPT=25000 DPT=25000
>> WINDOW=64172 RES=0x00 RST URGP=0 ]
>>
>> the real packet on eth1 according to tcpdump seems to be:
>>
>> 14:54:33.931831 IP (tos 0x20, ttl 239, id 39262, offset 0, flags [none],
>> proto: TCP (6), length: 40) 70.243.226.250.1703 > 123.23.23.23.25000: R,
>> cksum 0xacb6 (correct), 4070626809:4070626809(0) win 64172
>
> Thanks, I want to see dump of real ICMP packet. 'cksum' of ICMP packet is
> marked 'correct' ?

The logged ICMP packet doesn't seem to show up in the tcpdump output.
When I grep for the ID 39698 there are no matches at 14:54:xx.  (??)

BTW: does the LOG output indicate that netfilter translated the source
address of 70.243.226.250 to 192.168.0.133? If so, shouldn't it have
instead translated the *destination* address of 123.23.23.23 (=eth1) to
192.168.0.133? Could this be why the ICMP packet was generated in the
first place?

> 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

>> Jul  4 14:58:39 webby kernel: nf_ct_icmp: bad HW ICMP checksum IN= OUT=
>> SRC=80.133.170.211 DST=123.23.23.23 LEN=119 TOS=0x00 PREC=0x20 TTL=234
>> ID=22079 PROTO=ICMP TYPE=3 CODE=1 [SRC=123.23.23.23 DST=80.133.170.211
>> LEN=91 TOS=0x00 PREC=0x00 TTL=114 ID=25502 PROTO=UDP SPT=25000 DPT=21519
>> LEN=71 ]
> 
> This is ICMP error for UDP pakcet. ICMP packets TYPE=3 and CODE=3 were
> logged ?

Yes, there are TYPE=3 CODE=3 too. Here's a log snippet showing the "bad
HW ICMP checksum" messages together with the messages from my LOG rule:

...
Jul  4 14:53:57 webby kernel: nf_ct_icmp: bad HW ICMP checksum IN= OUT=
SRC=80.203.45.12 DST=123.23.23.23 LEN=119 TOS=0x00 PREC=0x20 TTL=102
ID=23775 PROTO=ICMP TYPE=3 CODE=3 [SRC=123.23.23.23 DST=80.203.45.12
LEN=91 TOS=0x00 PREC=0x00 TTL=115 ID=41422 PROTO=UDP SPT=25000 DPT=21227
LEN=71 ]
Jul  4 14:53:57 webby kernel: nf_ct_icmp: bad HW ICMP checksum IN= OUT=
SRC=80.203.45.12 DST=123.23.23.23 LEN=98 TOS=0x00 PREC=0x20 TTL=102
ID=23783 PROTO=ICMP TYPE=3 CODE=3 [SRC=123.23.23.23 DST=80.203.45.12
LEN=70 TOS=0x00 PREC=0x00 TTL=115 ID=41504 PROTO=UDP SPT=25000 DPT=21227
LEN=50 ]
Jul  4 14:54:33 webby kernel: [packet out wrong interface] IN= OUT=eth1
SRC=123.23.23.23 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=123.23.23.23
LEN=40 TOS=0x00 PREC=0x20 TTL=239 ID=39262 PROTO=TCP SPT=25000 DPT=25000
WINDOW=64172 RES=0x00 RST URGP=0 ]
Jul  4 14:58:04 webby kernel: [packet out wrong interface] IN= OUT=eth1
SRC=123.23.23.23 DST=192.168.0.133 LEN=92 TOS=0x00 PREC=0xC0 TTL=64
ID=32353 PROTO=ICMP TYPE=3 CODE=3 [SRC=192.168.0.133 DST=123.23.23.23
LEN=64 TOS=0x00 PREC=0x20 TTL=38 ID=47850 DF PROTO=TCP SPT=25000
DPT=25000 WINDOW=63 RES=0x00 ACK URGP=0 ]
Jul  4 14:58:39 webby kernel: nf_ct_icmp: bad HW ICMP checksum IN= OUT=
SRC=80.133.170.211 DST=123.23.23.23 LEN=119 TOS=0x00 PREC=0x20 TTL=234
ID=22079 PROTO=ICMP TYPE=3 CODE=1 [SRC=123.23.23.23 DST=80.133.170.211
LEN=91 TOS=0x00 PREC=0x00 TTL=114 ID=25502 PROTO=UDP SPT=25000 DPT=21519
LEN=71 ]
Jul  4 15:01:06 webby kernel: [packet out wrong interface] IN= OUT=eth1
SRC=123.23.23.23 DST=192.168.0.133 LEN=68 TOS=0x00 PREC=0xC0 TTL=64
ID=39699 PROTO=ICMP TYPE=3 CODE=3 [SRC=192.168.0.133 DST=123.23.23.23
LEN=40 TOS=0x00 PREC=0x20 TTL=239 ID=39688 PROTO=TCP SPT=25000 DPT=25000
WINDOW=64172 RES=0x00 RST URGP=0 ]
Jul  4 15:09:18 webby kernel: [packet out wrong interface] IN= OUT=eth1
SRC=123.23.23.23 DST=192.168.0.133 LEN=68 TOS=0x00 PREC=0xC0 TTL=64
ID=39700 PROTO=ICMP TYPE=3 CODE=3 [SRC=192.168.0.133 DST=123.23.23.23
LEN=40 TOS=0x00 PREC=0x20 TTL=239 ID=40226 PROTO=TCP SPT=25000 DPT=25000
WINDOW=64172 RES=0x00 RST URGP=0 ]
Jul  4 15:11:10 webby kernel: [packet out wrong interface] IN= OUT=eth1
SRC=123.23.23.23 DST=192.168.0.133 LEN=71 TOS=0x00 PREC=0xC0 TTL=64
ID=21127 PROTO=ICMP TYPE=3 CODE=3 [SRC=192.168.0.133 DST=123.23.23.23
LEN=43 TOS=0x00 PREC=0x20 TTL=17 ID=0 PROTO=TCP SPT=25000 DPT=25000
WINDOW=0 RES=0x00 RST URGP=0 ]
...

-- 
Jordan Russell


  parent reply	other threads:[~2007-07-05  5:51 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-06-16 16:43 ICMP packets associated with NAT connections sent out wrong interface? Jordan Russell
2007-06-26 22:22 ` Martijn Lievaart
2007-06-27 11:44   ` Ray Leach
2007-06-27 18:16     ` Jordan Russell
2007-06-28  6:56     ` Martijn Lievaart
2007-06-28 16:26       ` Jordan Russell
2007-06-28 19:10         ` Martijn Lievaart
2007-06-29  1:00 ` Yasuyuki KOZAKAI
     [not found] ` <200706290100.l5T1028w016087@toshiba.co.jp>
2007-07-04 23:25   ` Jordan Russell
     [not found]   ` <468C15EE.9060806@quo.to>
2007-07-05  1:11     ` Yasuyuki KOZAKAI
2007-07-05  1:16       ` Yasuyuki KOZAKAI
2007-07-05  5:51       ` Jordan Russell [this message]
2007-07-05 11:17         ` Yasuyuki KOZAKAI
2007-07-05 12:21           ` Patrick McHardy
2007-07-05 12:33             ` Krzysztof Oledzki
2007-07-05 17:05             ` Jordan Russell
     [not found]             ` <200707050111.l651Bu2w016010@toshiba.co.jp>
2007-07-06  0:14               ` Yasuyuki KOZAKAI
2007-07-06  0:50                 ` Jordan Russell
2007-07-06 17:42         ` Jordan Russell
2007-07-07  6:27           ` Yasuyuki KOZAKAI
2007-07-07 12:24             ` Yasuyuki KOZAKAI
2007-07-07 15:34               ` Patrick McHardy
2007-07-07 17:28                 ` Yasuyuki KOZAKAI
2007-07-07 17:48                   ` Yasuyuki KOZAKAI
2007-07-08  6:31                     ` Yasuyuki KOZAKAI
     [not found]                   ` <200707071748.l67HmfE2005051@toshiba.co.jp>
2007-07-09 13:34                     ` Patrick McHardy
2007-07-13 14:25                       ` Yasuyuki KOZAKAI
     [not found]                       ` <200707131425.l6DEPBYv013659@toshiba.co.jp>
2007-07-13 14:50                         ` Patrick McHardy
2007-07-13 15:49                           ` Yasuyuki KOZAKAI
2007-07-07 21:04               ` Jordan Russell
2007-07-09  7:03                 ` Yasuyuki KOZAKAI

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=468C86C9.7050204@quo.to \
    --to=jr-list-2007@quo.to \
    --cc=netfilter-devel@lists.netfilter.org \
    --cc=netfilter@lists.netfilter.org \
    --cc=yasuyuki.kozakai@toshiba.co.jp \
    /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