I think this would nerf wireguard similarly to how a "null" encryption effectively nerfed IPSec. Fine for a specific use case (debugging comes to mind) but should never be upstreamed imho.
This is confusing to me, and I'm not a novice to WireGuard.
WireGuard is a layer-3 protocol. Given that WireGuard does not natively support DHCP or dynamic internal IP allocation within its encrypted tunnels, and it instead relies on static tunnel IP configurations (Address and AllowedIPs for each pre-registered client), how would a new unregistered client be assigned an IP address within the encrypted subnet?
I don't understand why you would want to over-complicate WireGuard like this.
The default setup is perfect - you set up your profiles, and the server doesn't respond if you try to connect with an invalid one. Any other addon to this is just reducing security.
6 comments
[ 2.6 ms ] story [ 21.2 ms ] threadIt never responds, there's no indication of rejection.
The client can't even be sure a service is actually there or they've hit a default drop firewall rule.
WireGuard is a layer-3 protocol. Given that WireGuard does not natively support DHCP or dynamic internal IP allocation within its encrypted tunnels, and it instead relies on static tunnel IP configurations (Address and AllowedIPs for each pre-registered client), how would a new unregistered client be assigned an IP address within the encrypted subnet?
The default setup is perfect - you set up your profiles, and the server doesn't respond if you try to connect with an invalid one. Any other addon to this is just reducing security.
Why muddy that perfect process with this?
The “why” is pretty simple: the WireGuard protocol is really nice and makes a better protection layer than DTLS in my opinion.
All this implementation does that is different is make hosting public services (accessible to unknown peers) possible.