Nat+Iptables+Tcp Keepalive Problem

Nat+Iptables+Tcp Keepalive Problem

[Emiliano Romero]

Hi list!, I dont know if I'm doing right posting this problem here.

I'm doing a DNAT to forward connections to port 5555 to another server. 
The connection gets forwarded fine, I can connect, send and recieve data 
over that connection. The problem appear with TCP KeepAlive packets (No 
flags, win=0, len=0). When that packets of a connection that is 
ESTABLISHED (Send and recieve data before) arrives to my iptables 
machine. They arent matched with nat entries of the conection where it 
belongs. So they are marked as INVALID and go to INPUT insted of FORWARD.

TCP Keepalive in the remote side (The one that start the connection) is 
seted at 20 seconds with 4 tries at 10 seconds each one. That's because 
it's over a very bad communication channel.

I add some of my configurations:

Iptables config:
iptables -t raw -A PREROUTING -p tcp --dport 5555 -j TRACE
iptables -t nat -A PREROUTING -p tcp --dport 5555 -j DNAT 
--to-destination 192.168.1.100:5555

Output of Trace: http://pastebin.com/f65e41319

Visual Output of Wireshark of another try: http://tinyurl.com/qlaj9n

# iptables --version
iptables v1.4.1.1

# iptables -S
-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT

# iptables -t nat -S
-P PREROUTING ACCEPT
-P POSTROUTING ACCEPT
-P OUTPUT ACCEPT
-A PREROUTING -p tcp -m tcp --dport 5555 -j DNAT --to-destination 
192.168.1.100:5555

# iptables -t raw -S
-P PREROUTING ACCEPT
-P OUTPUT ACCEPT
-A PREROUTING -p tcp -m tcp --dport 5555 -j TRACE

WireShark output of TCP Keepalives:
186449    11772.258110    200.49.201.26=>172.16.102.11    TCP    [TCP 
ZeroWindow] [TCP Keep-Alive] 14032 > 5555 [] Seq=10 Win=0 Len=0
188417    11835.763745    172.16.102.11=>200.49.201.26    TCP    5555 > 
48538 [RST, ACK] Seq=1012825070 Ack=10 Win=0 Len=0

Any idea of what could be happening? Maybe that's not supported. If 
that's the case I'd never develop a kernel module, but I could try.

Regards

Re: Nat+Iptables+Tcp Keepalive Problem

[Jozsef Kadlecsik]

On Thu, 4 Jun 2009, Emiliano Romero wrote:

> I'm doing a DNAT to forward connections to port 5555 to another server. The
> connection gets forwarded fine, I can connect, send and recieve data over that
> connection. The problem appear with TCP KeepAlive packets (No flags, win=0,
> len=0). When that packets of a connection that is ESTABLISHED (Send and
> recieve data before) arrives to my iptables machine. They arent matched with
> nat entries of the conection where it belongs. So they are marked as INVALID
> and go to INPUT insted of FORWARD.
> 
> TCP Keepalive in the remote side (The one that start the connection) is seted
> at 20 seconds with 4 tries at 10 seconds each one. That's because it's over a
> very bad communication channel.
> 
> I add some of my configurations:
> 
> Iptables config:
> iptables -t raw -A PREROUTING -p tcp --dport 5555 -j TRACE
> iptables -t nat -A PREROUTING -p tcp --dport 5555 -j DNAT --to-destination
> 192.168.1.100:5555
> 
> Output of Trace: http://pastebin.com/f65e41319
> 
> Visual Output of Wireshark of another try: http://tinyurl.com/qlaj9n

The TCP keepalived packet in the output above is invalid: it's sequence 
number is wrong.

Best regards,
Jozsef
-
E-mail  : kadlec@blackhole.kfki.hu, kadlec@mail.kfki.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : KFKI Research Institute for Particle and Nuclear Physics
          H-1525 Budapest 114, POB. 49, Hungary

Re: Nat+Iptables+Tcp Keepalive Problem

[Emiliano Romero]

Jozsef Kadlecsik escribió:
> The TCP keepalived packet in the output above is invalid: it's sequence 
> number is wrong.
> 
> Best regards,
> Jozsef

Thanks for your reply Jozsef. After your reply I look at RFC 1122, It say:
"Some TCP implementations, however, have included a keep-alive 
mechanism.  To confirm that an idle connection is still active, these 
implementations send a probe segment designed to elicit a response from 
the peer TCP.  Such a segment generally contains SEG.SEQ = SND.NXT-1"
..."so that this SEG.SEQ will be outside the window.  Therefore, the 
probe causes the receiver to return an acknowledgment segment"

When I try with a linux box sending TCP KA, I see that this sets the ACK 
flag on TCP KeepAlive and that works correctly. I think that my remote 
equipments (GPRS Modems) are making TCP KA is the wrong way. Or maybe 
the GPRS Service Provider are touching my packets.

Thanks Again.

Regards
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Nat+Iptables+Tcp Keepalive Problem

[Jozsef Kadlecsik]

On Thu, 4 Jun 2009, Emiliano Romero wrote:

> Jozsef Kadlecsik escribi?:
> > The TCP keepalived packet in the output above is invalid: it's sequence
> > number is wrong.
> 
> Thanks for your reply Jozsef. After your reply I look at RFC 1122, It say:
> "Some TCP implementations, however, have included a keep-alive mechanism.  To
> confirm that an idle connection is still active, these implementations send a
> probe segment designed to elicit a response from the peer TCP.  Such a segment
> generally contains SEG.SEQ = SND.NXT-1"
> ..."so that this SEG.SEQ will be outside the window.  Therefore, the probe
> causes the receiver to return an acknowledgment segment"

So the packet is intentionally outside of the window :-).
 
> When I try with a linux box sending TCP KA, I see that this sets the ACK flag
> on TCP KeepAlive and that works correctly. I think that my remote equipments
> (GPRS Modems) are making TCP KA is the wrong way. Or maybe the GPRS Service
> Provider are touching my packets.

On which device did you capture the packets? 

The best would be to capture at both sides, i.e. real sender and receiver. 
Thus one can make sure whether any device between modified packets or not.

Best regards,
Jozsef
-
E-mail  : kadlec@blackhole.kfki.hu, kadlec@mail.kfki.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : KFKI Research Institute for Particle and Nuclear Physics
          H-1525 Budapest 114, POB. 49, Hungary