netfilter buglog - Mar 2007 - [Bug 554] Packet illegaly bypassing SNAT

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





------- Additional Comments From kaber@trash.net  2007-03-15 02:53 MET -------
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

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

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





------- Additional Comments From kaber@trash.net  2007-03-15 02:53 MET -------
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

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

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





------- Additional Comments From renean@gmx.de  2007-03-15 15:36 MET -------
(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.

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.

And the solution has another drawback, nmap -sX does not work anymore, whether
on the router itself (brings up many permission denied errors) nor on hosts 
behind it.

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

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





------- Additional Comments From kaber@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.

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





------- Additional Comments From kaber@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 reported the bug, or are watching the reporter.

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





------- Additional Comments From renean@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.