Bypassing blocked ports

Hi,

At a local library it seems they have some ports blocked. I can’t get to my VPN when I’m on their network. I’ve been reading up on how to bypass this and I saw people talking about forwarding ports so while Wireguard is running on it’s default (51820) port, I can set my firewall or iptables to allow it through.

I’m unfamilar with iptables, so I’m not sure what to do… Should I be looking at altering the PostUp/PostDown in the configuration file on the server itself, or if it’s a firewall thing I should be looking at opening up ports? I’m running pfSense as my firewall.

Thanks for any help, I’ve hard to fallback to my OpenVPN at 443tcp and while it works… it made me really remember why I switch to WireGuard haha

Shouldn’t need to change PostUp or PostDown, or even listening port.

In my experience the easiest way to accomplish this is to apply port translation as part of the forwarding from your home router. Most devices have a ‘listen on public IP port x’, ‘send to private IP port y’ kind of setup. You should be able to just set that up twice, one listening on 51820 and one on 53 (say), both pointing to your same WireGuard server.

If you’re just exposing WireGuard directly on a public IP (like at a VPS) then you’ll need some iptables routing, though, unless you want two instances.

You can just run it through port 53

It’s possible the library has blocked all outgoing traffic and pushes web browsing through a local proxy and DNS resolution through a local resolver.

In that case, you’d be out of luck.

The rule I have for Wireguard setup on my pfSense firewall

  • NAT Port Forward > Destination Address : WAN address, port 51820 to NAT (Wireguard IP) port 51820
  • It has a firewall rule associated with it in the WAN

In that sense, I would just need to create another port forward rule that has a destination of port (example) 53, to NAT port 51820 with the wireguard IP?

Also, how would my client know to use port 53? Would I have to change anything there? On my iPhone’s Wireguard app the only two port options I see are for interface listen port and peer endpoint.

And get your Dns weirded out !! Don’t do this

443, 123, and 53 – what other ones are there?

Yeah it seems that way here too. And like all ports are closed except common ports like I can test 22 53 443 and other common ones their open but any other ones except gaming ports is closed and you know that all of them common ports are shit for gamin

Ive been looking into ws tunneling but open wrt scripts without GitHub are garbage basically so it’s lookin like I’m bout to be getting a new laptop soon

In theory you could tunnel Wireguard over a TCP connection and then connect to this via the libraries local proxy. Performance would likely suck though since you’re tunnelling TCP/IP via Wireguard which is itself tunnelled over TCP.

Correct about pfsense. On your client you need to change the peer endpoint to use :53 instead of :51820.

This can be done safely; rather than running directly on 53/udp, you run wireguard on a different port and create an iptables rule to redirect inbound traffic on 53/udp on your WAN interface to wireguard’s port. This will avoid interfering with systemd-resolved’s stub resolver.

I run wireguard on 51820/udp and then redirect 53/udp as well as 123/udp to 51820/udp.

I do that for my VPN and it works fine unless you misconfigured routing

You can pick any port you want but 53 is usually open

If it’s a pure HTTP or HTTPS MitM proxy, then it will be expecting the client to talk HTTP to it. It will probably drop anything else.

You’d need a SOCKS proxy for a TCP-based VPN connection.

So I just tried it and it worked… kinda.

Opened up port 53 to test and no luck going through. Triple checked the settings, but nothing. I opened up 123 and surprisingly it worked.

Do you think it might have something to do with pfSense already using port 53? I know Wireguard itself can’t be listening on port 53 without changing a few things.

I ran it directly, depending on the OS/distro this isn’t a problem.

Some systems use 53 internally

I can’t find any other common UDP ports that network admins would be required to keep open.

Yeah, could just be that pretty already had something bound to it. Would have expected it to work though.

Traffic on port 53 is often intercepted and redirected to an internal resolver in networks that do DNS-level censorship or have captive portals. Port 123 (used for NTP) often works better in cases like this.