Hacker News Reader

Comment by asimops | Hacker News Reader

Have you tackled the issue of session management or are you planning to do so? Essentially wireguard key are just eternal session keys.

I would expect software that implements the wireguard transport layer to implement session management to be called a working VPN server solution. This means a second channel to the server for periodically rotating session keys, terminating sessions, changing IP addresses, configuring new routes and repeating authentication if necessary.

View on HN

I'd use firezone for that. It has an option that forces the user to login to the platform regularly. Coupling that with an external identity provider via oidc is a very solid and simple solution for session management.

Just a quick note -- 1.0 goes a little further and rotates the WireGuard keys upon each auth session, so the private key never leaves the tunnel process memory. You need the Firezone client for that, though.

Firezone seems to have come really far from when i last used it wow... But ... I really like running headscale for most of my stuff as i prefer the p2p meshing for direct connections from server to server latency regardless of where they are.

Im not entirely sure what you mean by "eternal session keys" in the context of wag specifically.

While the wireguard key effectively gives you the ability to talk to the wag server, the session is effectively maintained by a map in ebpf, as to whether you've authorised or not.

So even if someone steals your private key material, they wont be able to access MFA restricted routes

It seems to me that if I were building a VPN client like Global Protect but using WG, I'd have an eternal per client auth key that is used to set up an initial tunnel to the VPN controller, over that you perform auth, etc, then you're given another session key, which is valid as long as that session is. The first tunnel would disconnect as soon as you finished authenticating and got your actual session key.

Why even have the first tunnel? You could do the entire thing out of hand over a web interface or other mechanism. If the public address of the WG server (or the authn server) is known and available, then there’s no real difference in setting up the connection over a persistent WG channel vs an HTTPS service.

Both solutions are custom for that VPN, so I’d just have one WG tunnel that’s controlled through a secured (web)service. The bonus is that you wouldn’t need a hard coded initial key. (You’d still need some authentication mechanism, but it could be more than fixed public/private key pairs).

> This means a second channel to the server for periodically rotating session keys, terminating sessions, changing IP addresses, configuring new routes and repeating authentication if necessary.

So IPsec's IKE protocol? Why not just... use IPsec?

Reply on news.ycombinator.com