Receiving packets even when I shouldn't be

[avinassh]

Sorry for the odd little, but I ran into the odd issue myself. I created a TUN interface and tried netcat on it. But when I close my netcat, I still see it is receiving packets. Weirdly, if I keep nc running, it doesn't receive any!

Details:

rust-tun version: 0.5.1 OS, version: Mac OS Catalina, 10.15.7 (19H2) rust: rustc 1.50.0 (cb75ad5db 2021-02-10)

My reproducible code is here - main.rs. Once this is running, it replies the TCP packet only once and then it just keeps logging whatever the data it has received. So, first packet it gets is TCP SYN, to which it responds with TCP ACK and then logs rest of the packets to console.

Steps to reproduce:

1. Build and run it:

   cargo build --release
   sudo ./target/release/testing-tun

2. Setup the links:

   sudo ifconfig utun4 192.168.0.10 192.168.0.20 up     

3. start netcat:

   nc 192.168.0.20 80

If you don't close netcat, you will see the output something like this:

192.168.0.10:50829 → 192.168.0.20:80 ip_size=44b tcp_size=0b proto=tcp ttl=64
writing(44) [0, 0, 0, 2, 69, 0, 0, 40, 0, 0, 64, 0, 64, 6, 185, 97, 192, 168, 0, 20, 192, 168, 0, 10, 0, 80, 198, 141, 0, 0, 0, 0, 83, 10, 20, 42, 80, 18, 255, 255, 0, 82, 0, 0]
192.168.0.10:50829 → 192.168.0.20:80 ip_size=20b tcp_size=0b proto=tcp ttl=64

If you close the netcat (Ctrl + C), then the packets start appearing!

192.168.0.10:50829 → 192.168.0.20:80 ip_size=20b tcp_size=0b proto=tcp ttl=64
192.168.0.10:50829 → 192.168.0.20:80 ip_size=20b tcp_size=0b proto=tcp ttl=64
192.168.0.10:50829 → 192.168.0.20:80 ip_size=20b tcp_size=0b proto=tcp ttl=64
192.168.0.10:50829 → 192.168.0.20:80 ip_size=20b tcp_size=0b proto=tcp ttl=64

How is it even receiving these! I also confirmed it running tshark:

$ tshark -i utun4
Capturing on 'utun4'

    1   0.000000 192.168.0.10 → 192.168.0.20 TCP 68 50838 → 80 [SYN, ECN, CWR] Seq=0 Win=65535 Len=0 MSS=1460 WS=64 TSval=689213287 TSecr=0 SACK_PERM=1
    2   0.000202 192.168.0.20 → 192.168.0.10 TCP 44 80 → 50838 [SYN, ACK] Seq=0 Ack=1 Win=65535 Len=0
    3   0.000245 192.168.0.10 → 192.168.0.20 TCP 44 50838 → 80 [ACK] Seq=1 Ack=1 Win=65535 Len=0

and when I close netcat:

$ tshark -i utun4
Capturing on 'utun4'

    1   0.000000 192.168.0.10 → 192.168.0.20 TCP 68 50838 → 80 [SYN, ECN, CWR] Seq=0 Win=65535 Len=0 MSS=1460 WS=64 TSval=689213287 TSecr=0 SACK_PERM=1
    2   0.000202 192.168.0.20 → 192.168.0.10 TCP 44 80 → 50838 [SYN, ACK] Seq=0 Ack=1 Win=65535 Len=0
    3   0.000245 192.168.0.10 → 192.168.0.20 TCP 44 50838 → 80 [ACK] Seq=1 Ack=1 Win=65535 Len=0
    4  47.650802 192.168.0.10 → 192.168.0.20 TCP 44 50838 → 80 [FIN, ACK] Seq=1 Ack=1 Win=65535 Len=0
    5  48.852183 192.168.0.10 → 192.168.0.20 TCP 44 [TCP Retransmission] 50838 → 80 [FIN, ACK] Seq=1 Ack=1 Win=65535 Len=0
    6  51.053430 192.168.0.10 → 192.168.0.20 TCP 44 [TCP Retransmission] 50838 → 80 [FIN, ACK] Seq=1 Ack=1 Win=65535 Len=0
    7  55.254724 192.168.0.10 → 192.168.0.20 TCP 44 [TCP Retransmission] 50838 → 80 [FIN, ACK] Seq=1 Ack=1 Win=65535 Len=0
    8  63.458208 192.168.0.10 → 192.168.0.20 TCP 44 [TCP Retransmission] 50838 → 80 [FIN, ACK] Seq=1 Ack=1 Win=65535 Len=0

Where are the packets coming from! I am new to TUN/TAP, so it could be my understanding of these interfaces is not correct

[avinassh]

Oh wait, I just noticed the packet itself. It could netcat is sending to terminate the connection cleanly. Sorry 🤦

[meh]

No worries!

Out of curiosit, what are you working on?

[avinassh]

I started thinking how do VPNs actually work and learnt about TUN/TAP. Then decided to write my own really shitty version of VPN to understand how it exactly works :D