Open WireGuard Endpoints
mlhpdx
33 points
9 comments
August 14, 2026
Related Discussions
Found 5 related stories in 43.7ms across 4,128 title embeddings via pgvector HNSW
- Show HN: An MCP server that turns async-work practices into tools benbalter · 17 pts · July 21, 2026 · 45% similar
- OpenLogi amatheus · 241 pts · August 19, 2026 · 44% similar
- Show HN: Noisegate – a differential-privacy gateway for untrusted AI agents yashmahajan10 · 17 pts · July 30, 2026 · 43% similar
- Telegram Serverless soheilpro · 186 pts · July 15, 2026 · 43% similar
- Open-weight AI is having its Kubernetes moment tknaup · 355 pts · July 25, 2026 · 42% similar
Discussion Highlights (4 comments)
cube00
>the Listener rejects any handshake from an unknown key. 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.
pamcake
Why stop there? Give use Wireguard certificate auth already!
tosti
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.
anonymousiam
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?