[Bug 554] Packet illegaly bypassing SNAT

bugzilla-daemon at bugzilla.netfilter.org bugzilla-daemon at bugzilla.netfilter.org
Fri Mar 16 16:01:16 CET 2007


https://bugzilla.netfilter.org/bugzilla/show_bug.cgi?id=554





------- Additional Comments From renean at gmx.de  2007-03-16 16:01 MET -------
(In reply to comment #3)
> Well, I'm not so sure its a problem at all, nmap _does_ send invalid packets.
> 2.6.8/2.6.9 is about the time we introduced TCP window tracking, which is
> probably the reason why it worked before. To find out why it thinks the
> packets are invalid, do:
> 
> modprobe ipt_LOG
> echo 255 >/proc/sys/net/ipv4/netfilter/ip_conntrack_log_invalid

> If you have connection pickup enabled it should create a new connection.

I did that, following has been observed:
	packets generated with nmap were logged and the reason given was an
       	illegal combination of flags, thats all ok.

	The steps with the ftp, did not generate a log entry, they could be
       	dropped but no reason for invalid state was given. I think I have
       	connection pickup enabled, as if I send new data, the connection gets
       	written to the conntrack table. These packets making it out, through
       	SNAT without being NATed are complete legal packets in the sense of TCP,
       	they only do not generate a conntrack entry.

And as in the first post said, nmap was the way to a fast reproduction of
outgoing packets with wrong source. The problem occured during normal usage of
programs, bittorrent and even a webbrowser.

And why does the SNAT-target take packets from POSTROUTING and as it is not able
to SNAT them, puts them out unNATed, isn't that kind of a fault? Also all
documentation I have seen on the net would need to be rewritten, cause then SNAT
is not reliable.

I think it would be better to put those unNATable packets back to POSTROUTING
so that they can be handled seperately (e.g. dropped) or just DROP them, rather
than letting them out (cause then they would be dropped at the next router, not
knowing anything about the unrouted net, or they would give information about
the internal net away, that also is not desirable).

-- 
Configure bugmail: https://bugzilla.netfilter.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.



More information about the netfilter-buglog mailing list