I started out testing Wireguard on port 51820, found that it would occasionally be blocked (no handshake at all), tried 1194 and 4500 with better luck and it got me thinking: while I might eventually go back to wstunnel as the ultimate workaround, how could I parallel-test multiple ports most conveniently? Changing the client config to move to a different port is quite easy.
define multiple Wireguard interfaces on different ports, each one with essentially duplicated settings including peers
keep one single server and remap everything at the firewall level
What would the pros and cons of each approach be?
For the record, at the moment 4500 seems to work nicely: Android AP on D.Telekom (Germany), ICE wifi, OEBB wifi, Android AP on Iliad (Italy), Vodafone Fiber, all work fine.
Where is the port not accessable?
As for outgoing packets or on the incoming side of an ISP termination point?
Edit. You said so. While sending from the client to the server...
I've seen these days that a company build a wire guard addon for peer discovery without a rendezvous point at best.
But with wire guard alone you can only provide different configs with different ports.
Depending what and how traffic is filtered yes a port where otherwise also only udp traffic is send it's a good candidate but i.e. port 53 could actually also be filtered by its content.
If I'm not mistaken then it's also quiet trivial to distinct openvpn from wire guard on port 1194.. and so on.
Whatever problems I still have on the client side, those are entirely due to firewalls on the client side. Linux I can handle, given time. Windows is a tougher nut to crack, for me.
Here however the issue is the connection estabilishment: with my German operator, port 51820 would occasionally not get through over an Android hotspot. Changed port and the same setup worked. That is why I was wondering how to best conduct a survey, assuming it makes sense, which is not a given
I make firewall rules directing to the WG port. I use this method to have other ports avaliable on remote networks that block the configured port (such as in your case).
config redirect
option target 'DNAT'
list proto 'udp'
option src 'wan'
option src_dport '53'
option dest_ip '192.168.1.1'
option dest_port '51820'
option name 'WG_redirect_53udp'
option dest 'lan'
Yeah, for the moment I am sticking to 4500, will try fw rules for remapping, then, thanks.
(fun fact: the suggested remap would be blocked by my DSL provider... I am running unbound mostly via tcp to get around that)
I'm using default 51820 and redirects, too. Any kind of VPN-related ports might work (500, 1701, 1194, 4500), VoIP might work (e.g. 5060), sometimes QUIC (443).
The environments where I'm not able to use 51820 are usually not people blocking VPN specifically. In my experience, enterprise-grade firewalls are often used in the "block everything by default" mode with some commonly known services on the allow list. Company networks (the ones I am accessing as part of my job) are usually not trying to block me from doing my job but simply want to use the most restrictions possible without causing distress for their employees and contractors.
So my advice would be: Start with ports somewhat related to VPN, extend to ports related to any day-to-day business use, and only move to exotic ports as a last resort.
Argument one: I don't want to have too much of a discussion when this gets detected and asked about. Argument two: Sticking to a sane and believable list has worked out well so far.
I'm mostly considering non-business use, precisely for the reason you noted: no discussions. I was at a customer in the UK in april, I needed outside access for my own company vpn and they happily lent me a hotspot for the time needed.
