Verizon blocking wireguard?

VPN
1

Update: Turns out enabling ‘data saver’ turns off ipv4 and udp. Turned that off and now wireguard works fine.

I been debugging why wireguard wont work while on a cell connection. I use a tracfone prepaid phone(on verizon network) and a vultr box as my server. My learnings so far:

  1. Ipv4 access is heavily restricted, eg if I run udp/tcp on my personal box on port 443, phone can’t access that via ipv4. Common ipv4 websites work.
  2. Switching to an ipv6 IP makes tcp connections like ssh work. UDP connections mostly work.
  3. I had one successful wireguard connection during my testing over ipv6…However eventually I noticed it verizon started rejecting wireguard responses from server.
  4. If I swap out wireguard server for UDP echo server then I stop getting the ICMP ‘destination unreachable errors’, packets make it back to my phone.

Has anyone seen ISP blocking of wireguard like this? I noticed wireshark has handlers for wireguard protocol packets, so verizon can tell them apart too.

What’s the way out of this? I’ve seen people tunnel wireguard over websockets, but that’s not part of standard client, requires more complicated connection sequence. Any other suggestions?

tcpdump:

05:10:59.829872 IP6 (flowlabel 0x00d71, hlim 237, next-header UDP (17) payload length: 156) 2600:1010:b054:33e1:cce4:580d:932e:4318.38081 > server.4000: [udp sum ok] UDP, length 148

05:10:59.830679 IP6 (class 0x88, hlim 64, next-header UDP (17) payload length: 100) server.4000 > 2600:1010:b054:33e1:cce4:580d:932e:4318.38081: [udp sum ok] UDP, length 92

05:10:59.909712 IP6 (hlim 236, next-header ICMPv6 (58) payload length: 148) 2600:1010:b054:33e1:cce4:580d:932e:4318 > server: [icmp6 sum ok] ICMP6, destination unreachable, unreachable port, 2600:1010:b054:33e1:cce4:580d:932e:4318 udp port 38081

2

I’ve had similar issues on T-Mobile.

I don’t think it’s intentional blocking as much as quirks in the IPv6-4 stacks that they’re running. I’m not sure about Verizon but T-Mobile exclusively provisions IPv6 to devices. Anything that doesn’t cleanly route through the conversions will behave weirdly.

When I last researched it, I found an article talking about how reducing the MTU in the tunnel might help because the 6-4 conversion takes up some of that space.

I didn’t find a solution that worked well but get around it by connecting to a paid public VPN provider. They act as the default route and the wireguard tunnel can make it to the server through that connection.

3

I have Verizon and I run wireguard (hosting it myself) and also an IVPN account. Both work on cellular.

4

That’s clever. Thank you

5

I tried this, while this might work on a laptop. On android VPNs don’t seem to nest

6

It kind of makes sense. With so many devices they don’t need to do a massive NAT operation or use up valuable IPv4 address space.

7

Same here. I have a WG server on Vultr and have no problems using it while on Verizon.

8

I just tried pia. Only way I can get access to vpn is via TCP. openvpn UDP doesn’t work either.

9

Same here. Curious on what you find as maybe network is built different in different areas … But I have cellular modems connected 24/7 to an AWS wireguard server I have. I have devices on Verizon pre paid and Visible connecting … Both work. Prior to Wireguard I used to use OpenVPN and it also always worked but was more difficult on the server side to set up.

10

Turned out data-saver setting on android turns off UDP and ipv4. This wasn’t verizon/tracfone fault

11

this seems like a uniquely useful piece of information - even 4 years later