I decided to be extra sneaky with my wireguard VPN and set it to run on port 53/udp to masquerade as DNS traffic.
When then phone client is on WiFi, everything works fine. When the phone switches to the AT&T Mobile network, wireguard breaks. No handshake / no packets get through.
After changing the port to a random high port on both ends, it works again on both carrier and wifi networks. Conclusion is that AT&T Wireless is doing something wonky with DNS traffic.
I read some posts accusing AT&T of MITMing DNS but didn’t see much evidence of this, but it would explain this behavior…
most major ISPs MITM DNS for that sweet sweet user data money.
Use 443 instead if you’re trying to be sneaky.
Give shadowsocks a shot. Shadowsocks is essentially an encrypted https proxy that masks your data as web traffic. You may even just be able to get away with just using shadowsocks instead of wireguard over shadowsocks but better safe than sorry.
I’ve got a standard wireguard instance setup on my server then a separate wireguard instance setup to go over shadowsocks as as a backup in case someone decides they don’t want me using wireguard. Works like a charm to get past deep packet inspection.
Basically, you setup a shadowsocks instance between your two weeks(client and server). On the client, you have your shadowsocks proxy bound to 127.0.0.1:{port} and configure wireguard to send all traffic there.
Then on your server, you configure shadowsocks to listen on a specific port, typically 443, since its an HTTPS proxy and all. And configure wireguard to listen to traffic coming from that shadowsocks proxy.
At the end of the day youre sending traffic over the same routers that you normally would, except it’s masked as HTTPS traffic so DPI doesn’t see the handshake.
Here’s the guide I used: https://web.archive.org/web/20221021041220/https://www.oilandfish.com/posts/wireguard-shadowsocks.html
Be sure to save it, it looks like someones trying to bleach it off of the internet because it’s a powerful tool against dictatorships and others who seek to censor the people.
If you think network engineers are that silly. 53 is a well known port and where many content filtering systems take place. And if you route high traffic to port 53 they will know. Well because DNS request is pretty small.
We just came off a cruise and the ships Wi-Fi was sold in two tiers, basic which only allowed e-mail and iMessage or premium that allowed all traffic. We bought basic and I figured I would use WireGuard to get around their filters but even though I use a non standard port the ships system detected WireGuard and blocked it. Same for openvpn and IkeV2. I finally got around the firewall by using TLS on TCP on port 443. It worked slow, but it worked. Only thing it would not allow was Wi-Fi calling. Guess that does not go thru the tunnel.
Can someone eli5 what’s the reason and why is it sneaky vs a standard wg install that uses 51820? Sorry added port by memory and might not be correct.
I’m on AT & T and have no problem with WireGuard getting back to my home network. I’m running on port 51280, I think.
I sometimes run into this with hotel WiFi too, because they block port 53 traffic.
This is what I’ve done, however wireguard uses UDP, whereas HTTPS (prior to HTTP/3 and QUIC) uses TCP. I’ve found networks that block 443/UDP.
NTP uses 123/UDP, however like DNS, that’s something that networks may interfere with.
I was experimenting to get unfiltered / unmonitored internet access on airline flights. I hypothesize the heavy filtering is because they want to control bandwidth and not enable access to sites that could disrupt the peace on the plane if shoulder surfers see something they don’t like. The random high port worked just fine on the Jetblue flight I was on last night.
They’re trying to get around vpn blocking by using a different/common port that wouldn’t be blocked. Wireguard is easy to detect on any port, though, if somebody really wants to block it. It will get past some simple port-based blocking, though.
I don’t have any issues being blocked, but use port 443 udp, just in case. It’s a simple, low effort thing to try. If they want to block 443 udp, they’ll also be blocking QUIC web traffic.
The issue is when using wireguard on port 53 (to circumvent port based blocking on various wi-fi networks).
It is possible to run wireguard on tcp instead of udp.
True, however such functionality is not built in to wireguard, so you’ll only be able to do this with the help of some third-party software, which is fine, but may not work on all the same devices that raw wireguard is supported on.
I’ve started to use Tailscale for a few things in tricky environments. It uses wireguard under the hood but with a bunch of NAT/firewall traversal techniques, including falling back to TCP.
I’m not sure what docs you’re reading, but they’re not the same ones I am: https://www.wireguard.com/known-limitations/#tcp-mode
Ha! It’s only just past 10 in my timezone so you’ve done well 