|
List Info
Thread: Re: ICMP packets associated with NAT connections sent out wrong interface?
|
|
| Re: ICMP packets associated with NAT
connections sent out wrong interface? |
|
2007-07-05 00:51:05 |
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 x.
(??)
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
|
|
| Re: ICMP packets associated with NAT
connections sent out wrong interface? |
 
Japan |
2007-07-05 06:17:10 |
From: Jordan Russell <jr-list-2007 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=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:54x.
(??)
Indeed it seems to be generated by local node and dropped.
> 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?
Hmmm, REJECT in your rule might generate it, but I'm not
sure.
> > 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
Then it's purely kernel bug, I think.
> >> 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 ]
> ...
The issue of UDP and TCP seems to be different.
-- Yasuyuki Kozakai
|
|
| Re: ICMP packets associated with NAT
connections sent out wrong interface? |
Japan |
2007-07-05 19:14:21 |
From: Patrick McHardy <kabertrash.net>
Date: Thu, 05 Jul 2007 14:21:52 +0200
> Yasuyuki KOZAKAI wrote:
> > From: Jordan Russell <jr-list-2007quo.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=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 ]
> >>>>
> >>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?
>
> > 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.
He has already posted it. REJECT is in INPUT chain. This
means TCP packet
was not mangled. TCP packet might be handled as error, but
there seemed to
be no log "nf_ct_tcp: ...".
Jordan, is there the message "nf_conntrack: table full,
dropping packet"
in your log ? I've heard that BitTorrent creates huge
connections.
> > *nat
> > :PREROUTING ACCEPT [32:2910]
> > :POSTROUTING ACCEPT [29:2330]
> > :OUTPUT ACCEPT [2:152]
> > -A PREROUTING -i eth1 -p tcp -m tcp --dport 25000
-j DNAT
> > --to-destination 192.168.0.133
> > -A PREROUTING -i eth1 -p udp -m udp --dport 25000
-j DNAT
> > --to-destination 192.168.0.133
> > -A POSTROUTING -o eth1 -j MASQUERADE
> > COMMIT
> > *filter
> > :INPUT DROP [0:0]
> > :FORWARD DROP [0:0]
> > :OUTPUT DROP [0:0]
> > -A INPUT -i lo -j ACCEPT
> > -A INPUT -i eth0 -j ACCEPT
> > -A INPUT -i eth1 -m state --state ESTABLISHED -j
ACCEPT
> > -A INPUT -i eth1 -j REJECT --reject-with
icmp-port-unreachable
> > -A INPUT -j DROP
> > -A FORWARD -j ACCEPT
> > -A OUTPUT -o lo -j ACCEPT
> > -A OUTPUT -d 192.168.0.0/255.255.255.0 -o eth0 -j
ACCEPT
> > -A OUTPUT -d 192.168.0.0/255.255.255.0 -j LOG
--log-prefix "[packet out
> > wrong interface] "
> > -A OUTPUT -o eth1 -j ACCEPT
> > -A OUTPUT -j DROP
> > COMMIT
-- Yasuyuki Kozakai
|
|
| Re: ICMP packets associated with NAT
connections sent out wrong interface? |
|
2007-07-06 12:42:24 |
Jordan Russell wrote:
> 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?
To clarify my question:
If tcpdump on eth1 reports:
70.243.226.250.1703 > 123.23.23.23.25000
while my LOG rule reports for the same packet:
... [SRC=192.168.0.133 DST=123.23.23.23 ... SPT=25000
DPT=25000
isn't this saying that netfilter translated the *source*
address of the
packet?
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?
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?
--
Jordan Russell
|
|
| Re: ICMP packets associated with NAT
connections sent out wrong interface? |
Japan |
2007-07-07 07:24:21 |
From: Yasuyuki KOZAKAI <yasuyuki.kozakaitoshiba.co.jp>
Date: Sat, 07 Jul 2007 15:27:06 +0900 (JST)
> Hi, Jordan,
>
> I'll sort out observations from your report and try to
explain my idea in
> other mail after finishing some tests.
OK, I try to explain what the current netfilter does in
Jordan's situation.
I also attach the patch to fix this problem. Jordan, can you
try it ?
Patrick, please consider to apply it. Even if following my
idea is not
correct, clearly it fixes a bug. I'm wondering why I missed
'!'
when I copied & pasted ip_conntrack_proto_icmp.c...
- This situation occurred on 2.6.20.12 and 2.6.21.5 at
least.
- your rules are following
*nat
:PREROUTING ACCEPT [32:2910]
:POSTROUTING ACCEPT [29:2330]
:OUTPUT ACCEPT [2:152]
-A PREROUTING -i eth1 -p tcp -m tcp --dport 25000 -j DNAT
--to-destination 192.168.0.133
-A PREROUTING -i eth1 -p udp -m udp --dport 25000 -j DNAT
--to-destination 192.168.0.133
-A POSTROUTING -o eth1 -j MASQUERADE
COMMIT
*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT DROP [0:0]
-A INPUT -i lo -j ACCEPT
-A INPUT -i eth0 -j ACCEPT
-A INPUT -i eth1 -m state --state ESTABLISHED -j ACCEPT
-A INPUT -i eth1 -j REJECT --reject-with
icmp-port-unreachable
-A INPUT -j DROP
-A FORWARD -j ACCEPT
-A OUTPUT -o lo -j ACCEPT
-A OUTPUT -d 192.168.0.0/255.255.255.0 -o eth0 -j ACCEPT
-A OUTPUT -d 192.168.0.0/255.255.255.0 -j LOG --log-prefix
"[packet out wrong interface] "
-A OUTPUT -o eth1 -j ACCEPT
-A OUTPUT -j DROP
COMMIT
- ICMP error is generated by this router but destination
address of it is strange.
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 ]
- original TCP reset is following
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
- no error message is printed by nf_ct_tcp, no 'table is
full' error.
My idea is following.
- This TCP reset is not initial packet of TCP connection. If
it is initial packet,
no address in ICMP packet should be mangled. Jordan, if
you see
/proc/net/netfilter/nf_conntrack, you will find the entry
matched the TCP packet.
- TCP packet was marked as error packet. Because '--state
ESTABLISHED'
didn't match the packet. No conntrack entry wasn't
assigned to the
packet. Usually, error log by nf_conntrack_tcp should be
generated in
such case, but no message is generated in some cases. I
don't know why
this TCP reset was handled as error.
- Then ICMP error generated at this router was not assigned
to any conntrack entry.
- nf_conntarck_icmp.c assigns the ICMP error to the
conntrack which matches
the TCP reset. But IP_CT_IS_REPLY didn't set to *ctinfo.
This is bug.
h = nf_conntrack_find_get(&innertuple, NULL);
if (!h) {
/* Locally generated ICMPs will match
inverted if they
haven't been SNAT'ed yet */
/* FIXME: NAT code has to handle half-done
double NAT --RR */
if (hooknum == NF_IP_LOCAL_OUT)
h =
nf_conntrack_find_get(&origtuple, NULL);
if (!h) {
DEBUGP("icmp_error_message: no
matchn");
return -NF_ACCEPT;
}
/* Reverse direction from that found */
if (NF_CT_DIRECTION(h) == IP_CT_DIR_REPLY)
*ctinfo += IP_CT_IS_REPLY;
} else {
if (NF_CT_DIRECTION(h) == IP_CT_DIR_REPLY)
*ctinfo += IP_CT_IS_REPLY;
- As a result, nf_nat_packet mistook the address in ICMP
packet which
should be mangled.
>From e36c67a5f57a0bd45f6666627ad3d60d42ee4497 Mon Sep 17
00:00:00 2001
From: Yasuyuki Kozakai <yasuyuki.kozakaitoshiba.co.jp>
Date: Sat, 7 Jul 2007 20:29:39 +0900
Subject: [PATCH 1/1] [NETFILTER]: nf_conntrack: Fixes
direction of locally generated ICMP error
The conntrack assigned to locally generated ICMP error is
usually the one
assigned to the original packet which has caused the error.
But if
the original packet is handled as invalid by nf_conntrack,
no conntrack
is assigned to the original packet. Then nf_ct_attach()
cannot assign
any conntrack to the ICMP error packet. In that case
nf_conntrack_icmp
tries to assign appropriate conntrack to it. But the current
code
mistakes the direction of the packet. As a result, NAT code
mistakes
the address in the packet to mangle.
Spotted by Jordan Russell.
Signed-off-by: Yasuyuki Kozakai <yasuyuki.kozakaitoshiba.co.jp>
---
net/ipv4/netfilter/nf_conntrack_proto_icmp.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/ipv4/netfilter/nf_conntrack_proto_icmp.c
b/net/ipv4/netfilter/nf_conntrack_proto_icmp.c
index f4fc657..5973b58 100644
--- a/net/ipv4/netfilter/nf_conntrack_proto_icmp.c
+++ b/net/ipv4/netfilter/nf_conntrack_proto_icmp.c
-201,7
+201,7 icmp_error_message(struct sk_buff *skb,
}
/* Reverse direction from that found */
- if (NF_CT_DIRECTION(h) == IP_CT_DIR_REPLY)
+ if (NF_CT_DIRECTION(h) != IP_CT_DIR_REPLY)
*ctinfo += IP_CT_IS_REPLY;
} else {
if (NF_CT_DIRECTION(h) == IP_CT_DIR_REPLY)
--
1.5.2.2
|
|
| Re: ICMP packets associated with NAT
connections sent out wrong interface? |
 
Switzerland |
2007-07-07 10:34:49 |
On Sat, 7 Jul 2007, Yasuyuki KOZAKAI wrote:
> OK, I try to explain what the current netfilter does in
Jordan's situation.
> I also attach the patch to fix this problem. Jordan,
can you try it ?
>
> Patrick, please consider to apply it. Even if following
my idea is not
> correct, clearly it fixes a bug. I'm wondering why I
missed '!'
> when I copied & pasted
ip_conntrack_proto_icmp.c...
I'm currently travelling, I'll look into it tomorrow. Just
one
question below ..
> My idea is following.
>
> - This TCP reset is not initial packet of TCP
connection. If it is initial packet,
> no address in ICMP packet should be mangled. Jordan,
if you see
> /proc/net/netfilter/nf_conntrack, you will find the
entry matched the TCP packet.
>
> - TCP packet was marked as error packet. Because
'--state ESTABLISHED'
> didn't match the packet. No conntrack entry wasn't
assigned to the
> packet. Usually, error log by nf_conntrack_tcp should
be generated in
> such case, but no message is generated in some cases.
I don't know why
> this TCP reset was handled as error.
>
> - Then ICMP error generated at this router was not
assigned to any conntrack entry.
>
> - nf_conntarck_icmp.c assigns the ICMP error to the
conntrack which matches
> the TCP reset. But IP_CT_IS_REPLY didn't set to
*ctinfo. This is bug.
>
> h = nf_conntrack_find_get(&innertuple,
NULL);
> if (!h) {
> /* Locally generated ICMPs will match
inverted if they
> haven't been SNAT'ed yet */
> /* FIXME: NAT code has to handle
half-done double NAT --RR */
> if (hooknum == NF_IP_LOCAL_OUT)
> h =
nf_conntrack_find_get(&origtuple, NULL);
The local ICMP tracking is basically useless nowadays since
we always
manually attach the conntrack reference from the original
packet
(exactly because of the half-done double NAT FIXME quoted
above).
But this is an interesting case, the connection tracking
code itself
thought the RST was invalid, but ICMP tracking will still
associate
the ICMP containing the RST with the original connection.
I'm wondering
whether it should really do that. In case it shouldn't, just
removing
all locally generated ICMP special-casing should also fix
the bug,
right?
|
|
| Re: ICMP packets associated with NAT
connections sent out wrong interface? |
|
2007-07-07 16:04:37 |
Yasuyuki KOZAKAI wrote:
> OK, I try to explain what the current netfilter does in
Jordan's situation.
> I also attach the patch to fix this problem. Jordan,
can you try it ?
Excellent. The patch does appear to fix the problem. I
repeated the
BitTorrent test, and no packets matched my LOG rule.
I'll keep watching the logs and report back if it happens
again.
Thanks for looking into this!
--
Jordan Russell
|
|
[1-7]
|
|