0

My ISP sets the incoming packets' TTL such that it is always TTL=1 on my devices (after a router).
TTL=1 always, without wireguard

They do it so that the end user cannot add another router and re-share the connection. But it also results in me not being able to use internet in WSL2. WSL2 creates a virtual LAN interface to access internet.

After some poking around, I found that when I use wireguard, WSL2 gets internet, I can re-share internet from my PC, and also, TTL value is higher.

Higher TTL with wireguard

Now my question is how is that possible?

My router won't know that the said packet is sent to wireguard server. So the packet coming back from wireguard server will have TTL=2 on my router, just like any other packet. And then my PC will get the packet with TTL=1, just like any other packet. But how is that packet having a TTL higher than 1? Can packets be "wrapped"? Like the incoming packet has TTL=1, comes to my wireguard interface, but after it is unwrapped by the wireguard interface, it gets a new TTL. Any resource on this "wrapping" will also be helpful.

Markus Meyer
  • 1,910
amin2783
  • 3

1 Answers1

0

Can packets be "wrapped"? Like the incoming packet has TTL=1, comes to my wireguard interface, but after it is unwrapped by the wireguard interface, it gets a new TTL. Any resource on this "wrapping" will also be helpful.

Yes, and such wrapping (more commonly called 'tunneling') is literally the purpose of WireGuard, or indeed the purpose of pretty much any VPN software1. It's what makes it possible for the VPN's network interface to have its own IP addresses invisible to the outer network – and since the TTL is part of IP, by extension it becomes possible to have a TTL that's invisible to the outer network as well.

The packet's original TTL is not actually altered by WireGuard; rather, it produces a packet with two TTLs – and two IP headers in general – the original "inner" header from 'ovh.net' and the "outer" header from your WireGuard server. Sending a packet through VPN software causes it to generate a new packet with an additional IP header over the original, and vice versa. (In case of WireGuard there are also additional UDP and WG headers, but that's somewhat besides the point; direct IP-in-IP would be equally possible.)

In your case, your ISP is only able to change the TTL of the outer header, but not the inner one from ovh.net. So when the wrapped WireGuard UDP packet (with TTL=1) is received by the OS, it is unwrapped by WireGuard and the original ICMP Echo packet (with TTL=45) that was inside is re-injected to the OS where it becomes visible as the ping response.

Wireshark could be used to inspect this visually; it cannot see through WireGuard's encryption, but it could see through unencrypted tunnel types such as GRE or IP-in-IP – take a look at some collected example captures.

1 (Except for "SSH tunneling" and browser-integrated VPNs; both of those are really higher-layer proxies, so they don't deal with TTLs directly. The term 'tunneling' still applies to them, but with a slightly broader meaning of putting one protocol inside another same-layer protocol, in general terms – e.g. "HTTP inside HTTP" or "HTTP inside SSH" – rather than specifically being "IP packet inside IP packet" as with WireGuard.)

grawity
  • 501,077