NAT dropping FIN ACK from remote server

NAT dropping FIN ACK from remote server

[vDev]

I am experiencing a problem with Linux as a NAT router. A host/client
on the private LAN establishes a TCP connection to a server on the WAN
(Internet) through the Linux/NAT router. Here's what happens when
client attempts to tear down the socket.

1. Client on private LAN opens a TCP connection to the remote server
on the public network through Linux/NAT router.
2. Client exchanges data with the remote server.
3. The server closes the TCP connection by sending a FIN to the
client. Linux/NAT router successfully forwards the FIN to the client.
4. The client now sends an ACK to FIN to the remote host, which is
forwarded by the Linux/NAT router to the server.
5. The client then sends a FIN to the remote host, which is forwarded
by the Linux/NAT router to the remote server.
6. The server now sends an ACK to the client. THE Linux/NAT router
DOES NOT FORWARD THE ACK TO THE CLIENT. GETS DROPPED!
7. The client keeps sending FIN to the remote host for a period of time.
8. The client times out and send a RST to the remote host.

I am trying to find out why Linux/NAT router dropped the ACK. This
seems like a problem where connection tracking is prematurely tearing
down the mapping and does not forward the ACK back to the client.

Is there a way to resolve this?

Also, any debugging techniques will be helpful.

Re: NAT dropping FIN ACK from remote server

[Marcelo Ricardo Leitner]

On 16-10-2014 18:57, vDev wrote:
> I am experiencing a problem with Linux as a NAT router. A host/client
> on the private LAN establishes a TCP connection to a server on the WAN
> (Internet) through the Linux/NAT router. Here's what happens when
> client attempts to tear down the socket.
>
> 1. Client on private LAN opens a TCP connection to the remote server
> on the public network through Linux/NAT router.
> 2. Client exchanges data with the remote server.
> 3. The server closes the TCP connection by sending a FIN to the
> client. Linux/NAT router successfully forwards the FIN to the client.
> 4. The client now sends an ACK to FIN to the remote host, which is
> forwarded by the Linux/NAT router to the server.
> 5. The client then sends a FIN to the remote host, which is forwarded
> by the Linux/NAT router to the remote server.
> 6. The server now sends an ACK to the client. THE Linux/NAT router
> DOES NOT FORWARD THE ACK TO THE CLIENT. GETS DROPPED!
> 7. The client keeps sending FIN to the remote host for a period of time.
> 8. The client times out and send a RST to the remote host.
>
> I am trying to find out why Linux/NAT router dropped the ACK. This
> seems like a problem where connection tracking is prematurely tearing
> down the mapping and does not forward the ACK back to the client.
>
> Is there a way to resolve this?
>
> Also, any debugging techniques will be helpful.

Try checking if this ignored ack is being marked as invalid by conntrack with 
something like iptables -I FORWARD -m conntrack --ctstate INVALID -j LOG

If it's marked as INVALID, for whatever reason, we won't NAT it.. (and you 
probably have another rule that ends up dropping the not-NATed packet, if 
that's the case)

Marcelo

Re: NAT dropping FIN ACK from remote server

[Florian Westphal]

vDev <vijaypas@gmail.com> wrote:
> I am experiencing a problem with Linux as a NAT router. A host/client
> on the private LAN establishes a TCP connection to a server on the WAN
> (Internet) through the Linux/NAT router. Here's what happens when
> client attempts to tear down the socket.
> 
> 1. Client on private LAN opens a TCP connection to the remote server
> on the public network through Linux/NAT router.
> 2. Client exchanges data with the remote server.
> 3. The server closes the TCP connection by sending a FIN to the
> client. Linux/NAT router successfully forwards the FIN to the client.
> 4. The client now sends an ACK to FIN to the remote host, which is
> forwarded by the Linux/NAT router to the server.
> 5. The client then sends a FIN to the remote host, which is forwarded
> by the Linux/NAT router to the remote server.
> 6. The server now sends an ACK to the client. THE Linux/NAT router
> DOES NOT FORWARD THE ACK TO THE CLIENT. GETS DROPPED!

Any chance to get a tcpdump of such a connection?
(Dumping on the interface in direction of the server, so we can see
 the server ACK that is being dropped).