0

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

Improve this question
1
  • It is TCP on your NAT box doing what it is supposed to do: send RST when it receives something outside an existing connection. You are not stopping the TCP segment from the server reaching your NAT box TCP. You must intercept at the IP layer in the stack and stop IP from sending its payload to TCP.
    – Ron Maupin
    Jul 19, 2022 at 18:13

1 Answer 1

Reset to default
0

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.

Improve this answer
2
  • I have a complete control over the network under question (it is just 3 VMs in a virtual box on a single host). I can ssh from the NAT to the client with no problem.
    – Necto
    Jul 6, 2016 at 19:38
  • Another consideration you must have is that if the 3 VM's are running NAT configuration of networking on them, then you have double NATTING so to say, that could be the cause of your NAT boxen thinking that it is traffic directed to itself and finding that the traffic is meant for a closed port, it sends a RST packet out. So whole setup could be confusing to debug. Can you not setup 3 separate machines and test this out first, to see if it is reproducible in a real world scenario, not just on networking that is with Virtual box?
    – mkzia
    Jul 6, 2016 at 21:28

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .