Home / server / Questions / 787355
In Process
Necto
Asked: 2016-07-02 01:53:42 +0800 CST

How to figure out why my NAT-box sends TCP RST packets?

  • 772

TL;DR: I see that an ubuntu (which I have an absolute control of) host sends a packet under certain circumstances. How to find the application/kernel module responsible for that packet?

I am developing a homegrown NAT-box, and I arrived to this point:

The network topology: [192.168.1.100] -- [192.168.1.1 : 10.0.0.4] -- [10.0.0.1]

  • [10.0.0.1] runs the default Apache2 web server.
  • [192.168.1.1 : 10.0.0.4] is the custom NAT-box with 192.168.1.1 being the internal iface and 10.0.0.4 - the external one.
  • [192.168.1.100] - is the client, running wget -O - 10.0.0.1

When I request a page from the server here is the traffic I see on the two NAT interfaces:

No.     Time           Source                Destination           Protocol Length Info
      1 0.000000000    ae:29:9f:0e:3a:0d     da:32:d6:6c:18:e6     ARP      42     Who has 10.0.0.1?  Tell 10.0.0.4
      2 0.002477000    da:32:d6:6c:18:e6     ae:29:9f:0e:3a:0d     ARP      42     10.0.0.1 is at da:32:d6:6c:18:e6
      3 0.752175000    192.168.1.100         10.0.0.1              TCP      74     52054 > http [SYN] Seq=0 Win=29200 Len=0 MSS=1460 SACK_PERM=1 TSval=1584 TSecr=0 WS=512
      4 0.762395000    10.0.0.4              10.0.0.1              TCP      74     48394 > http [SYN] Seq=0 Win=29200 Len=0 MSS=1460 SACK_PERM=1 TSval=1584 TSecr=0 WS=512
      5 0.763218000    10.0.0.1              10.0.0.4              TCP      74     http > 48394 [SYN, ACK] Seq=0 Ack=1 Win=28960 Len=0 MSS=1460 SACK_PERM=1 TSval=1587 TSecr=1584 WS=512
      6 0.763230000    10.0.0.4              10.0.0.1              TCP      54     48394 > http [RST] Seq=1 Win=0 Len=0
     11 0.770654000    10.0.0.1              192.168.1.100         TCP      74     http > 52054 [SYN, ACK] Seq=0 Ack=1 Win=28960 Len=0 MSS=1460 SACK_PERM=1 TSval=1587 TSecr=1584 WS=512
     12 0.771153000    192.168.1.100         10.0.0.1              TCP      66     52054 > http [ACK] Seq=1 Ack=1 Win=29696 Len=0 TSval=1589 TSecr=1587
     13 0.771350000    192.168.1.100         10.0.0.1              HTTP     172    GET / HTTP/1.1 
      7 0.781889000    10.0.0.4              10.0.0.1              TCP      66     48394 > http [ACK] Seq=1 Ack=1 Win=29696 Len=0 TSval=1589 TSecr=1587
      8 0.782015000    10.0.0.1              10.0.0.4              TCP      54     http > 48394 [RST] Seq=1 Win=0 Len=0
      9 0.782163000    10.0.0.4              10.0.0.1              HTTP     172    GET / HTTP/1.1 
     10 0.782173000    10.0.0.1              10.0.0.4              TCP      54     http > 48394 [RST] Seq=1 Win=0 Len=0
     14 0.791486000    10.0.0.1              192.168.1.100         TCP      54     http > 52054 [RST] Seq=1 Win=0 Len=0
     15 0.792103000    10.0.0.1              192.168.1.100         TCP      54     http > 52054 [RST] Seq=1 Win=0 Len=0

In other words what happens is (ignoring the ARP):

  1. The client sends a SYN packet
  2. The NAT-box receives it, and resends to the external server
  3. The server responds with SYN,ACK - second step for the handshake.
  4. The NAT-box receives the SYN,ACK and does two things:
    • It sends the SYN,ACK to the client (that is good)
    • It sends an RST packet to the server (that breaks the connection)

I believe my application running NAT is not capable of sending an RST packet. I suspect it comes from the NetFilter, but I do not know how to confirm it.

How do I find out where this packet (#6) comes from?

P.S. I run this in a mininet 2.2.1 under ubuntu 14.04

linux nat tcpdump iptables linux-networking

1 Answers

  1. Are you able to verify that the source/client sending original SYN packet is NOT actually two endpoints with the same IP address being shared behind the NAT??? YOu must verify this first before we can proceed to resolving this for you. Please verify and get back to us. One way to test is to SSH from the NAT box to the client box, and that connection should be reset within a minute or two if the 'client(original SYN sender in your scenario above)' is actually two endpoints with the same IP.

    • 0