For my phone service I use GoogleFi, which rents T-Mobile’s network in the US. I also use OpenVPN at home so I can tunnel traffic from wherever I happen to be to my house so I can either access internal services or to go outbound to the Internet.
That’s all well and good. Or it was, until a year or so ago when traffic would sometimes just get hung or appear to completely drop when using 4G/5G. It would work fine otherwise on Wifi.
I see a ton of entries in the openvpn.log:
MULTI: bad source address from client [192.0.0.4], packet dropped
So I went down this rabbit hole. Turns out 192.0.0.4 is a “private” IP range, and sometimes the Android client says where it’s coming from. But it’s a red herring.
For mobile data, T-Mobile famously uses only IPv6 (an oddity in the mobile space), and 192.0.0.4 is an internal IP, given to every phone, that goes through this IPv4-IPv6-IPv4 translation as it traverses the network, where it then comes out some random gateway IP 172.56.92.x to its destination. Sometimes the client, like, just says it’s coming from 192.0.0.4 because that’s all it knows.
Red herring. So much time wasted.
The solution? The actual solution? It’s found here on a PiVPN (OpenVPN on Pi-Hole) forum. It’s an MTU problem. In server.conf, just set the MTU to an amount lower than the standard Internet packet MTU of 1500, to something like 1400, and also do some mss fixup (not sure about that part).
tun-mtu 1400
mssfix 1360Save, restart the service. You’ll still see the 192.0.0.4 warnings, but traffic will flow.
My theory is that the IPv4-6-4 translation is adding extra bytes to the UDP packet as it wraps the packet in a v6 frame, so many bytes that it’s going over the standard MTU of 1500 bytes. If we tell the server to tell the client to keep the MTU size smaller, that allows for plenty of space for the translation to enclose the packet without exceeding 1500.
I’ve wasted so much time today (and the past year) on the wrong things.