@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 {
         address 192.0.2.1
         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.

https://lists.zx2c4.com/pipermail/wireguard/2019-January/003809.html

https://lists.zx2c4.com/pipermail/wireguard/2018-September/003289.html

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.

https://kirill888.github.io/notes/wireguard-via-websocket/

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