[Bug 554] Packet illegaly bypassing SNAT

[bugzilla-daemon at bugzilla.netfilter.org]

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





------- Additional Comments From kaber at trash.net  2007-03-16 06:49 MET -------
(In reply to comment #2)
> (In reply to comment #1)
> > Most likely these packets are considered invalid by connection tracking and
> > therefore not handled by NAT. Try this:
> > 
> > iptables -t mangle -A POSTROUTING -m state --state INVALID -j DROP
> 
> I tried that and it seems to be a workaround for the problem. But it does not
> solve it.

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

> The question is, why these packets are considered INVALID as in earlier kernels
> they are not. Also if i put the staterule from above in the nat-table prior to
> the SNAT-rule, it does not match.
> 
> I observed the following interesting behaviour:
> 
>         I set the timeout for the conntrack entry down to 60s and opened a
>         telnetconnection to an outside ftp. Then I typed in nothing and waited
>         for the timeout. After it expired I reset the connection. That packet
>         made it unNATed through iptables. In earlier kernelversions a new entry
>         in the conntracktable was spawned.
>         Now the receiving server has no chance of ACKing the action, cause only
>         the internal IP is seen.

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

-- 
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.