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

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





--- Comment #5 from www at applejelly.org  2011-12-05 01:26:07 ---
Created an attachment (id=370)
 --> (http://bugzilla.netfilter.org/attachment.cgi?id=370)
A test case

SNAT fails to maquerade some TCP CWR, TCP ECN, TCP URG, TCP ACK, and TCP PSH
packets


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

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


www at applejelly.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |www at applejelly.org




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

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


Jozsef Kadlecsik <kadlec at netfilter.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kadlec at netfilter.org




--- Comment #6 from Jozsef Kadlecsik <kadlec at netfilter.org>  2011-12-05
12:39:24 ---
The NAT engine ignores any packet with state INVALID, because there's no
reliable way to determine what kind of NAT should be performed. So the proper
way to prevent the leakage of private address space is to drop INVALID packets.

It's not a well documented feature, unfortunately.

If the conntrack engine fails to properly identify a packet and thus assings it
to the INVALID state, that's a bug. But too late packets do not fall to that
category.


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

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





--- Comment #7 from Doug Smythies <dsmythies at telus.net>  2011-12-05
16:59:00 ---
(In reply to comment #6)
Thank you for your reply Jozef. Since my posting of February 19th, I have
continued to study iptables, nat and conntrack and such. Yes, I had come
realize that the NAT stage simply could not know what to do with an INVALID
packet. I also agree that this "feature" is not well documented or
well known.



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

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





--- Comment #8 from Doug Smythies <dsmythies at telus.net>  2011-12-05
21:08:44 ---
(In reply to comment #5)
www at applejelly.org: If I understand your example correctly, you are trying to
make new TCP sessions in violation of the protocol. That senario is, in my
opinion, well documented (or at least better documented). Following is the
related segment of my iptables script:

# A NEW TCP connection requires SYN bit set and FIN,RST,ACK reset.
# Un-NAT'ed packets go out to internet without this rule.
# Sending RFC1918 packets to internet is considered poor form, by me anyhow.
$IPTABLES -A INPUT -p tcp ! --syn -m state --state NEW -j LOG --log-prefix
"NEW
TCP no SYN:" --log-level info
$IPTABLES -A INPUT -p tcp ! --syn -m state --state NEW -j DROP


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

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


Steffen Sledz <sledz at dresearch-fe.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|sledz at dresearch-fe.de       |




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

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





--- Comment #9 from www at applejelly.org  2011-12-06 19:30:11 ---
(In reply to comment #8)
> (In reply to comment #5)
> www at applejelly.org: If I understand your example correctly, you are
trying to
> make new TCP sessions in violation of the protocol. That senario is, in my
> opinion, well documented (or at least better documented). Following is the
> related segment of my iptables script:
> 
> # A NEW TCP connection requires SYN bit set and FIN,RST,ACK reset.
> # Un-NAT'ed packets go out to internet without this rule.
> # Sending RFC1918 packets to internet is considered poor form, by me
anyhow.
> $IPTABLES -A INPUT -p tcp ! --syn -m state --state NEW -j LOG --log-prefix
"NEW
> TCP no SYN:" --log-level info
> $IPTABLES -A INPUT -p tcp ! --syn -m state --state NEW -j DROP
> 
That would be what I was doing while I was investigating why I saw an internal
IP on PPP0 as in the initial report. Sorry for wasting time. Summery: me too
Thanks for comment #6 and informing me.


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