0

I have a local machine on a VPN network with private IP A , and a VPS with private IP B which acts as an exit node, i.e. all traffic in the local machine is supposedly being routed from the local machine encrypted to the VPS which then routes it to the final public destination.

I was trying to find out if my VPN was leaking so I span up Wireshark and had it listen on the virtual interface created by the VPN and filtered by ip.addr != B

I would expect to only see DNS requests there, but all BitTorrent traffic shows up as well. I can see packets with source/destination as A -> <Public IP> and vice-versa

It's clearly leaving via the interface and using the local machine's (macOS) private IP address A, but looking at the WireShark output it seems to not pass through the VPS.

Weirder still, if I use ipleak.net I don't see any leak, the torrent address comes out as the public address of the VPS.

Am I just interpreting the output incorrectly?

Improve this question

1 Answer 1

Reset to default
1

You're interpreting the output incorrectly. More specifically, you're expecting that output on the wrong interface.

It's completely normal to see your regular Internet traffic on the virtual interface created by the VPN client: that's what the virtual interface is for. Its entire purpose is to take "regular" traffic to Internet so that the VPN client could encapsulate it – invisibly to your apps, which just carry on talking to various Internet hosts as they did before.

The traffic that you were expecting to see (DNS traffic as well as the encrypted A↔B VPN tunnel traffic) will be visible on the original network interface, i.e. the Ethernet or Wi-Fi adapter, and it will have B's external address on the outside.

enter image description here

If you want to see this "live", try to set up a GRE or IPIP tunnel without encryption so that Wireshark could see both the outer and inner headers at once. But since macOS doesn't really do either of those, you can load a sample capture e.g. GRE.pcap or IP-in-IP.pcap into Wireshark.

(Both examples use 10.0.0.1↔10.0.0.2 as the external/WAN addresses and 1.1.1.1↔2.2.2.2 as the internal/VPN addresses, and both samples show the "outer" traffic of a 'ping 2.2.2.2' that goes through the 10.0.0.2 VPN server. The site has more samples available.)

Improve this answer
3
  • Thanks for this, seems like I'm confused about how VPNs and network interfaces. I thought the packet would be wrapped and the final destination would only be seen once unwrapped by the VPS, so that the local interface only knows to redirect it to the VPS. I see now that the only traffic which includes the VPS IP address is DNS traffic which must be because of how tailscale's magicDNS works
    – Scb
    Commented Jan 21 at 15:57
  • 1
    Yes, that's how VPNs generally work, but keep in mind that Tailscale might not necessarily be relaying directly through your VPS – if it finds it impossible to make a direct WireGuard connection for some reason (e.g. if you forgot to adjust firewall on the VPS), the packets will be sent through Tailscale's "DERP" relay servers instead (being encapsulated twice, practically speaking).
    – grawity_u1686
    Commented Jan 21 at 16:00
  • I see, my understanding of how these things work is very muddled. Your third point about how the packets hit the interface before the VPN software does its thing cleared it up. Thanks again.
    – Scb
    Commented Jan 21 at 16:04

You must log in to answer this question.

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