Page MenuHomeVyOS Platform

Wireguard listen ports lower than 1024
Closed, WontfixPublicFEATURE REQUEST


I'm attempting to setup a wireguard endpoint with port 443 or 80 to circumvent some more aggressive outbound DPI environments.

 Number 443 is not in the 1024-65535 range

Invalid value
Value validation failed
Set failed

Is there a particular reason that it's off limits? I could potentially work around it with a NAT rule or port forward but that seems like it's another layer to add.


Difficulty level
Unknown (require assessment)
Why the issue appeared?
Will be filled on close
Is it a breaking change?
Unspecified (possibly destroys the router)

Event Timeline

@trystan Listen or endpoint? The listen port had been limited to avoid issues with IANA assigned ports.
udp/80 or udp/443 might not m=be the best option anyway.

set interfaces wireguard wg1 port 443

results in

Number 443 is not in the 1024-65535 range

Invalid value
Value validation failed
Set failed

This would be a server (endpoint) for an associated wireguard client or peer. The peer is behind a strict outbound firewall that blocks any ports other than 80/443.

I have worked around it by using the following destination nat rule:

rule 1 {
     destination {
         port 443
     inbound-interface eth0
     protocol udp
     translation {
         port 51820 ##wireguard listen port

This functions as expected but being able to directly set the wireguard listen port under 1024 will likely become a common request for corporate environments that perform significant filtering of arbitrary ports.

That is listen port. endpoints are peer specific, if you have multiple peers on the same interface, each one has of course it's own endpoint if you want to initiate the connections. Otherwise, once the other peer connected to your gateway (assuming the handshake was successful), this information is taken from the header.

Yes, I understand that. The primary request is to be able to set a listen port lower than 1024 without having to create a destination NAT rule to get the same result.

Why not using ports higher 1024? Port 80 and 443 are so called privileged ports, not sure if that is really required. Port udp/80, udp/443 for instance may interfere in the future with QUIC.

As long as the local nginx is not listening on the external interface on udp/443, functionally there should be no limitation to running wireguard on 443 there. A convoluted script to check that the current config has no existing 443 mapping is one solution, but that seems a bit fragile, and wouldn't really tell you where in the config the blocking 443 instance is.

As Hagbard pointed out though, future HTTP/3 (QUIC based) is looking at using UDP to accelerate connections, and is expected to use UDP 80/443, so this represents a conflict.

I had thought maybe using SSLH as a multiplexer to frontend Wireguard and the local VyOS nginx instance might work, but since Wireguard is UDP, that won't work here. You would need something additional like UDPtunnel or UDP2raw to fake the external TCP packet encapsulation. Once things get this complicated though, using an offboard VM to handle your VPN activities directly, using something like Streisand or Algo VPN distros would be a better choice.

I was thinking some more along the lines of stunnel and wrapping wireguard that way but it would require additional packaging and integration on the vyos side. Luckily whatever outbound filtering is in place for this specific implementation seems to be relatively basic and limited to port blocking/whitelisting.

The destination nat rule seems to work well for now and I appreciate the input. The multiplexing/SSLH idea combined with stunnel or an obfuscation mechanism built into wireguard itself both sound like promising ideas for the future.

Actually somebody made a nifty websocket tunnel named wstunnel (similar to stunnel conceptually, but websockets is more natural for tunneling generic binary protocols thanks to webRTC...) that seems to work alright for Wireguard.

wstunnel apparently can play well with native nginx websocket support, so nginx can be the multiplexer?

hagbard closed this task as Wontfix.EditedSep 10 2019, 3:36 AM

I think encapsulate the udp based traffic into tcp is more than counter productive and makes it an easy DoS target.