Wireguard only supports UDP. The main reason being TCP over TCP is extremely slow.

You could try OpenVPN, I think that has a TCP mode though, as said, don’t expect good performance.

Try UDP port 123 sometimes that goes through the firewalls

For my setup, I used UDP port 443. For the vast majority of situations it works well as TCP 443 is for secure internet traffic. It seems admins often blanket 443 port open regardless of protocol 🙃

I’ve never tried this myself, but the docs have some ways of maybe getting into working https://www.wireguard.com/known-limitations/#tcp-mode .

The udp2raw repo has the following description:

A Tunnel which Turns UDP Traffic into Encrypted UDP/FakeTCP/ICMP Traffic by using Raw Socket,helps you Bypass UDP FireWalls(or Unstable UDP Environment)

Good news: it’s possible! :) From Known Limitations on the Wireguard project site:

TCP Mode

WireGuard explicitly does not support tunneling over TCP, due to the classically terrible network performance of tunneling TCP-over-TCP. Rather, transforming WireGuard’s UDP packets into TCP is the job of an upper layer of obfuscation (see previous point), and can be accomplished by projects like udptunnel and udp2raw.

Have a look into udptunnel and udp2raw and see how that works in your environment.

https://www.starvpn.com/obfuscate-wireguard-vpn-with-shadowsocks/

As long as you’re certain your wireguard server works from other networks… You could use nginx as a proxy to have your server accept incoming traffic from UDP port 53 (DNS)… But, be careful!

I would strongly suggest you whitelist the restrictive network for use on UDP port 53. Is the WAN IP static on the restrictive network? Do you know the size of the WAN subnet? I’d try a quick test over UDP port 53 using nginx, then close it up. If it works, create your firewall rule to whitelist only the restrictive network and Bob’s your aunt.

PS: If the restrictive network uses DPI (deep packet inspection) to verify they are real DNS queries on UDP 53, you can try putting DNSmuggle behind nginx. Do not have anything listen on localhost:53 as that may interfere with your local DNS at the server side. I don’t know how well this will perform, but I’m assuming not amazing. DNSmuggle supports encrypted DNS, which should prevent the network(s) from hijacking your requests.