Re: ICMP packets associated with NAT connections sent out wrong interface?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Ray Leach wrote:
On Wed, 2007-06-27 at 00:22 +0200, Martijn Lievaart wrote:
Jordan Russell wrote:
Hi,

My machine is functioning as a NAT box. It has two NICs:
- eth0, connected to the LAN, IP address 192.168.0.1
- eth1, connected to the Internet, IP address 123.23.23.23


(snip)

[outdrop] IN= OUT=eth1 SRC=123.23.23.23 DST=192.168.0.4 LEN=68 TOS=0x00
PREC=0xC0 TTL=64 ID=61136 PROTO=ICMP TYPE=3 CODE=3 [SRC=192.168.0.4
DST=123.23.23.23 LEN=40 TOS=0x00 PREC=0x20 TTL=53 ID=16088 PROTO=TCP
SPT=1229 DPT=44851 WINDOW=0 RES=0x00 ACK RST FIN URGP=0 ]
That's a port unreachable message, seemingly coming from the outside, in response to a RST coming from the inside. That in itself is not very usual, but it can happen.

This packet going out the wrong interface seems like a pretty serious bug. I advice you to repost on the netfilter-devel list, there are many more people there that are really into this. However, this may be a bug in the network code, not the netfilter code. Or something else completely.


HTH,
M4

Doesn't seem like a bug ...

The port unreachable ICMP replay is coming from your machine in response
to a packet coming in eth1 trying to get to 192.168.0.x ...
You have just denied the echo replies by youe DROP rule.

The source of the packet is 123.23.23.23, it comes from the Internet. The destination is local. Why do you think this packet is generated locally?

M4



[Index of Archives]     [Linux Netfilter Development]     [Linux Kernel Networking Development]     [Netem]     [Berkeley Packet Filter]     [Linux Kernel Development]     [Advanced Routing & Traffice Control]     [Bugtraq]

  Powered by Linux