netfilter buglog - Aug 2011 - [Bug 693] SNAT is failing to maquerade some TCP RST packets

http://bugzilla.netfilter.org/show_bug.cgi?id=693


David Davidson <david at commroom.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |david at commroom.net




--- Comment #3 from David Davidson <david at commroom.net>  2011-08-10
01:26:47 ---
I have the exact same problem.

Many thanks to Ludovico and Doug for discovering and posting about this issue.
I am so grateful that somebody else noticed this and was able to comment about
it and even be able to provide a workaround.

This is very weird and adverse behavior! I noticed this by accident yesterday
afternoon. Because I have never had a problem, I never really scrutinized the
masquerading interface for RFC1918 addresses. But I was testing something else,
and while looking at this interface with a packet capture, I accidentally
noticed that a public internet interface was occasionally sending packets
sourced from internal private machines, using an RFC1918 address as the source
address. These were FIN and RSTs, only, just like you say.

Unlike some of you, I use a front-end for IPtables that makes use of perl
scripting (which in the end, scripts IPtables similarly in the way most of you
are also scripting your policies).
So then I composed a huge bug report that I was going to submit to the
developer of this front-end, and I probably spent 2-3 hours describing the bug
and what I noticed was happening. I was just about to post it and I said to
myself "well you better have one more re-check of the IPtables/netfilter
bugs
and make certain that this isn't a netfilter problem." Then I noticed
this
post. I am relieved to know that I wasn't the only one affected by this
really
obscure and strange problem.

Thank you Doug for the workaround! I have inserted a drop rule in the forward
chain and I can say that I have NOT seen any packets traversing the internet
interface [masqueraded interface] with RFC1918 addresses for TCP packets that
are marked with the FIN or RST flags. The new workaround has survived 24 hours
without a leak; again, my hat's off to you Doug for your work on this. I am
so
thankful I found this post and this workaround because I believe that NO
RFC1918 addressed packets should ever be able to escape to the internet, and if
I worked for an ISP, I would deprecate this kind of thing (the RFC1918
leakage).

You're absolutely right - it only seems to affect only RST's or
FIN's. I agree
with Doug - this seems like a bug. Certainly adverse behavior too, because
RFC1918 addresses should NEVER escape the internet interface as it wouldn't
be
routed by anyone's ISP anyway. Leakage is the absolute best and most
appropriate word for the behavior.

It also seems that this is a connection tracking related problem, so now I am
wondering if this has anything to do with iptables/netfilter at all, since
conntrack is usually implemented in the Linux kernel (while even sometimes as a
loadable module, but still operated in kernel space).

The other related bug that was mentioned
(http://bugzilla.netfilter.org/show_bug.cgi?id=627) also appears to be
something related to conntrack. That used downgraded the Linux kernel and the
problem seemed to go away (or so I recall). 

So what do you guys think? Is this something netfilter might consider fixing in
iptables, or should patches be submitted to the Linux kernel source to fix the
conntrack code?


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