Open WireGuard Endpoints
proxylity.com
proxylity.com
It 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?
It's a primitive for building secure, but open to any client (any peer public/private key will be accepted).
To use it as a VPN would require write a complex Lambda on the AWS end. But that isn't the point.
The point is providing very efficient encryption for UDP from the edge to the cloud, or between machines. It's lighter weight and more reliable than DTLS because of the lack of sequence number and retry.
That's it.
You said the handshake is establishing a tunnel, and that it is delivering raw traffic, but how is that possible in a L3 environment that uses IP addresses to determine route(s) to an endpoint? When you refer to "encapsulated traffic", you probably mean traffic from the unregistered endpoint to a known WireGuard server, This would give the known WireGuard server the public IP of the unregistered endpoint, but unless the WireGuard server has an IP address for the unregistered endpoint's encrypted L3 subnet, no traffic will ever flow in the other direction.
A few years ago, I had an idea for a secure way for two WireGuard endpoints to find each others' public IP address, which I have not yet implemented, but even in that environment both endpoints would need the keys and private IP/subnet addresses of their peers in order to communicate.
Some background on my WireGuard experience:
I've set up a lot of WireGuard systems and have even done some WireGuard demonstrations for government research purposes (over five years ago, before I retired).
Right now I'm maintaining (for myself, my family, some former consulting clients, and two of our security systems) a dual-stack multi-point WireGuard network with three cloud servers, and about 30 endpoints scattered across four physical locations and five mobile devices. I even set up some kludgy scripts so that two of the locations using dynamic IP can communicate directly point-to-point with each other, and fall back to one of the cloud-based WireGuard routers to re-sync if/when one of their public IP addresses changes. Direct point-to-point communication cuts latency in half and reduces my cloud data fees.
I have a fleet of small battery powered temperature sensors that send readings to a backend built with it. On the sensors, I’m using the vanilla WireGuard-ESP library to connect over Wi-Fi to the backend (full tunnel). So the IP for the device is assigned like normal, the the tunnel is established. The sensor also needs to pull time (NTP) over the tunnel. So it talks to two different “IPs” that are completely virtual. At the other end of the tunnel the packets are inspected in the Lambda and if they match one of the two magic IPs, things happen (temperature stored or NTP response). The Lambda function does all that work (there is no real NTP server).
Another example is what I call CoAP/wg where raw CoAP requests are sent by a client application. By raw I mean what goes over the tunnel isn’t encapsulated IP, it’s just plain CoAP. In that case the backend just handles it like any other CoAP implementation would since the UDP Gateway terminates the encryption/tunnel. This isn’t a tunnel in the networking sense but it uses the same backend as the temp sensor example.
It’s a weird tool, but a really nice one IMHO.
That’s how every other implementation works. It’s not a requirement of the protocol though, and that inspired this tweak in my implementation.
FWIW, it still allows configuring known peers separately from unknown ones.
Sorry for the double reply, I had meant to address that in the first.
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.
It's different than the VPN use case where you absolutely want to lock down access to known peers.