netfilter buglog - Mar 2003 - [Bug 71] dnat breaks connection tracking?

https://bugzilla.netfilter.org/cgi-bin/bugzilla/show_bug.cgi?id=71





------- Additional Comments From laforge@netfilter.org  2003-03-30 21:18 -------
First of all: You didn't even specify the particular kernel version you are
running, not even mentioning which versions of which patches you are using (if
any). 

Secondly, I don't see anything strange in this setup. DNAT with FTP sessions
has
been working quite fine for years.  In fact, the whole NAT code is an addon to
the conntrack code - and the decision 'RELATED or not' happens before
NAT is
done on the related (ftp data) session at all.

Can you really make sure that this is not a misconfiguration or something? 
I'm
sorry, but it definitely is one of the standard iptables setups which dozens of
people are running, and I've never seen the described behaviour before.

So unless you cannot tell me more about this problem, I have no idea where to
start...



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

https://bugzilla.netfilter.org/cgi-bin/bugzilla/show_bug.cgi?id=71





------- Additional Comments From mbm@alt.org  2003-03-31 01:53 -------
Created an attachment (id=16)
config-2.4.20


------- Additional Comments From mbm@alt.org  2003-03-31 01:58 -------
It's just a stock 2.4.20 kernel

ifconfig eth0 192.168.1.2 netmask 255.255.255.0 up
ifconfig eth0:0 24.247.211.234 netmask 255.255.255.255 up
route add default gw 192.168.1.1

iptables -t nat -A PREROUTING -p tcp -s \! 192.168.1.0/24 -d 192.168.1.2 -j LOG
--log-prefix "DNAT:"
iptables -t nat -A PREROUTING -p tcp -s \! 192.168.1.0/24 -d 192.168.1.2 -j DNAT
--to-destination 24.247.211.234

iptables -A INPUT -m state --state RELATED -j LOG --log-prefix
"RELATED:"
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -s 192.168.1.0/24 -j ACCEPT
iptables -A INPUT -p tcp -m multiport -m state --state NEW --destination-port
21,22  -j ACCEPT

iptables -A INPUT -j LOG --log-prefix "REJECT:"
iptables -A INPUT -p tcp -j REJECT --reject-with tcp-reset




------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

https://bugzilla.netfilter.org/cgi-bin/bugzilla/show_bug.cgi?id=71





------- Additional Comments From mbm@alt.org  2003-03-31 02:22 -------
and some logs:

DNAT:IN=eth0 OUT= MAC=00:90:27:35:b6:13:00:20:78:c5:72:06:08:00 SRC=y.y.y.y
DST=192.168.1.2 LEN=52 TOS=0x10 PREC=0x00 TTL=51 ID=6246 DF PROTO=TCP SPT=40234
DPT=21 WINDOW=5840 RES=0x00 ACK FIN URGP=0 

DNAT:IN=eth0 OUT= MAC=00:90:27:35:b6:13:00:20:78:c5:72:06:08:00 SRC=y.y.y.y
DST=192.168.1.2 LEN=58 TOS=0x10 PREC=0x00 TTL=51 ID=6245 DF PROTO=TCP SPT=40234
DPT=21 WINDOW=5840 RES=0x00 ACK PSH URGP=0

DNAT:IN=eth0 OUT= MAC=00:90:27:35:b6:13:00:20:78:c5:72:06:08:00 SRC=y.y.y.y
DST=192.168.1.2 LEN=60 TOS=0x00 PREC=0x00 TTL=51 ID=53374 DF PROTO=TCP SPT=40339
DPT=21 WINDOW=5840 RES=0x00 SYN URGP=0

conntrack_ftp: RECORDING: y.y.y.y => 24.x.x.x:32778

DNAT:IN=eth0 OUT= MAC=00:90:27:35:b6:13:00:20:78:c5:72:06:08:00 SRC=y.y.y.y
DST=192.168.1.2 LEN=60 TOS=0x00 PREC=0x00 TTL=51 ID=50350 DF PROTO=TCP SPT=40349
DPT=32778 WINDOW=5840 RES=0x00 SYN URGP=0

REJECT:IN=eth0 OUT= MAC=00:90:27:35:b6:13:00:20:78:c5:72:06:08:00 SRC=y.y.y.y
DST=24.x.x.x LEN=60 TOS=0x00 PREC=0x00 TTL=51 ID=50350 DF PROTO=TCP SPT=40349
DPT=32778 WINDOW=5840 RES=0x00 SYN URGP=0

--- ip_conntrack_ftp.c.orig     2003-03-30 19:20:21.000000000 -0500
+++ ip_conntrack_ftp.c  2003-03-30 19:20:26.000000000 -0500
@@ -374,6 +374,10 @@
 
        exp->expectfn = NULL;
 
+       printk("conntrack_ftp: RECORDING: %u,%u,%u,%u =>
%u.%u.%u.%u:%d\n",
+                       NIPQUAD(ct->tuplehash[!dir].tuple.src.ip),
+                       NIPQUAD(ct->tuplehash[dir].tuple.src.ip),(array[4]
<< 8
| array[5]));
+
        /* Ignore failure; should only happen with NAT */
        ip_conntrack_expect_related(ct, &expect);
  out:




------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

https://bugzilla.netfilter.org/cgi-bin/bugzilla/show_bug.cgi?id=71





------- Additional Comments From mbm@alt.org  2003-03-31 10:03 -------
Alright, I missed the "decision 'RELATED or not' happens before NAT
is done"
remark in that last comment and only now realized it after walking through the
code.

The packets don't match comming in; it's not until after the dnat in the
prerouting that they'd ever match and there's no connection tracking
hook there.
(I'd consider this a bug)

I'm still working my way through the netfilter code so feel free to jump in
and
correct me at any point; it looks like what I need is to patch
ip_conntrack_standalone.c so that there's another call to ip_conntrack_in.
It
only matters for NF_IP_LOCAL_IN, probably set at NF_IP_PRI_LAST.



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

https://bugzilla.netfilter.org/cgi-bin/bugzilla/show_bug.cgi?id=71





------- Additional Comments From laforge@netfilter.org  2003-03-31 12:29 -------
I'm still not sure whether I understand correctly where the problem is.

Usually the flow of events is:

first packet of control connection comes in:
- conntrack entry is created at PRE_ROUTING
- NAT code assigns a nat binding to the connection (using PREROUTING+DNAT)
- NAT binding is applied to this and every futher packet in this connection
- ip_conntrack_ftp detects PASV/PORT and raises an expectation
- ip_nat_ftp alters this expectation to consider DNAT that happened
- first packet of data connection is coming in
- tuple of packet (with NAT'ed addresses) matches the tuple in the
expectation
- expectfn() of ip_nat_ftp configures NAT bindings of data connection
- nat bindings are applied to this and all further packets.

So from what I gather, something in ip_nat_ftp seems not to be working, not
manipulating the expectation as intended.  Can you try to turn debugging in
ip_nat_ftp.c on (and/or insert a few printk's?)




------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

https://bugzilla.netfilter.org/cgi-bin/bugzilla/show_bug.cgi?id=71





------- Additional Comments From mbm@alt.org  2003-03-31 19:29 -------
DNAT:IN=eth0 OUT= MAC=00:90:27:35:b6:13:00:20:78:c5:72:06:08:00 SRC=y.y.y.y
DST=192.168.1.2 LEN=60 TOS=0x00 PREC=0x00 TTL=51 ID=46557 DF PROTO=TCP SPT=47097
DPT=21 WINDOW=5840 RES=0x00 SYN URGP=0 

conntrack_ftp: RECORDING: y.y.y.y => 24.x.x.x:32774
nat_ftp: Not touching dir REPLY at hook OUTPUT
nat_ftp: Not touching dir REPLY at hook POSTROUTING

DNAT:IN=eth0 OUT= MAC=00:90:27:35:b6:13:00:20:78:c5:72:06:08:00 SRC=y.y.y.y
DST=192.168.1.2 LEN=60 TOS=0x00 PREC=0x00 TTL=51 ID=51693 DF PROTO=TCP SPT=47101
DPT=32774 WINDOW=5840 RES=0x00 SYN URGP=0 

REJECT:IN=eth0 OUT= MAC=00:90:27:35:b6:13:00:20:78:c5:72:06:08:00 SRC=y.y.y.y
DST=24.x.x.x LEN=60 TOS=0x00 PREC=0x00 TTL=51 ID=51693 DF PROTO=TCP SPT=47101
DPT=32774 WINDOW=5840 RES=0x00 SYN URGP=0 

. . . 

rehashed:

y.y.y.y connects to 24.x.x.x which is the upstream nat (aka 192.168.1.1)
upstream nat sends the packet to 192.168.1.2 (ftp server)
192.168.1.2 does a dnat translation to make itself 24.x.x.x and keep conntrack
happy
conntrack fails to see related connections

why do I do this?
case 1: If I do nothing then the ftp server will think it's192.168.1.2, the
upstream nat will mangle the ip headers to 24.x.x.x but won't address the
problem of the data containing 192.168.1.2.
case 2: If I tell the ftp server to bind to 192.168.1.2 but send out data as if
it were 24.x.x.x I confuse conntrack with 192.168.1.2 != 24.x.x.x

I used to just use case 2 and disable the sanity checks but that gets tedious to
on every kernel upgrade for various protocols, so I came up with the idea of
mapping 192.168.1.2 back to 24.x.x.x to make conntrack happy.

The problem isn't limited to just ftp, I get pretty much the same situation
with
irc dcc.



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

https://bugzilla.netfilter.org/cgi-bin/bugzilla/show_bug.cgi?id=71





------- Additional Comments From mbm@alt.org  2003-03-31 21:00 -------
just to be absolutely clear on what's going on here -
192.168.1.1 is a rather stupid hardware nat
192.168.1.2 is the linux box (also doing some nat) that you're seeing logs
of

I'm trying to work around the fact that the hardware nat can't do the
job
ip_nat_ftp and fix the data portion itself.



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

https://bugzilla.netfilter.org/cgi-bin/bugzilla/show_bug.cgi?id=71





------- Additional Comments From mbm@alt.org  2003-04-03 04:40 -------
Hmm, I was on the wrong track before with just calling ip_conntrack_in; while
that works for the
baisc problem it doesn't address the larger issues. 
 
Let's try solving a slightly more complex problem: 
 
1. packet comes in 
2. connection tracking says new, unrelated 
3. dnat'd to one of the machine's alternate ip addresses 
4. connection tracking now picks up the connection as expected (due to the dnat)
5. expect requests another nat 
6. dnat'd to another machine on the local subnet 
 
With the stock netfilter code I'd have trouble going from steps 3->4; at
the end of 3 my packet
wouldn't be related and would simply be dropped. If I simply try to call
resolve_ct again at step 3 I
can accomplish step 4 but it's probably too late to hit step 6 as I'm
already out or on my way out of
the nat code. 
 
Ideas? 



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

https://bugzilla.netfilter.org/cgi-bin/bugzilla/show_bug.cgi?id=71

laforge@netfilter.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |WONTFIX



------- Additional Comments From laforge@netfilter.org  2003-04-14 09:51 -------
Please try enabling the debug code in ip_conntrack_ftp.c, I think the problem is
that the IP address contained in the data packet (PORT/PASV command) is
different from the IP header source/destination address.

In a 'normal' case, this would be most likely somebody trying to break
the
firewall by specifying bogus adresses in order to set up connection expectations
at the firewall.  

But in your case you will have to remove those checks from the conntrack/nat
helper code in order to make it work.  please note, however, that you are
opening a major security hole.




------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

https://bugzilla.netfilter.org/cgi-bin/bugzilla/show_bug.cgi?id=71

mbm@alt.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|WONTFIX                     |



------- Additional Comments From mbm@alt.org  2003-04-18 18:40 -------
No, that's pretty much what I was trying to avoid doing.

Isn't there a way to take the dnat'd packets and insert them back into
the
incoming queue so that all the netfilter rules run again on the newly dnat'd
packet? This would solve the problem without introducing new security holes, 
although it has a potential to setup an infinite loop if the netfilter rules 
are set wrong.



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

https://bugzilla.netfilter.org/cgi-bin/bugzilla/show_bug.cgi?id=71

laforge@netfilter.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
         Resolution|                            |WONTFIX



------- Additional Comments From laforge@netfilter.org  2003-04-18 19:47 -------
there is no way to do so.

And even if there was, it wouldn't help you since the 'nat' table is
just
traversed for every first packet of a connection (and since we've seen the
first
packet already, it is no longer considered the first).



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.