[ta1243]

This looks nice, but a couple of things

> curl http://public.server.address:8080/register_device?key=e83253...

> The service will return a fully templated response

It looks like the "registration" involves the server generating a private key then sending to the client, rather than the client generating a private key and sending the public key to the server.

Not only that but your example is http! Probably worth replacing that part at least in case people think http is a reasonable option.

> To authenticate the user should browse to the servers vpn address, in the example, case 192.168.1.1:8080, where they will be prompted for their 2fa code.

So when the session times out, is there any way for the client to realise this? Or does their ssh session (or whatever) just stop working?

I've on and off looked for a wireguard client which can do something like the captive portal detection on wifi. Ideally it would be an extra line in the config file (like persistentkeepalive), which does a URL pull. Could be checked periodically (like with the keepalive). If it returns "OK", then fine, if it doesn't return then there's a network problem, but if it returns a "Location" header, the client would pop up a browser at that location, allowing for session reauthentication or whatever.

I haven't found one.

[Nullence]

Howdy! Kind of forgot that I put this up, the registration url can also take an optional pubkey parameter, so you dont have to rely on the server generating the private key for you (docs are a little lacking so I understand the confusion!)

To answer your last question, eBPF XDP which is what I use can only do PASS, DROP or REDIRECT. So I stick with the easiest possible outcome and do PASS/DROP, which means your connections will just stop working.

However you can always set up the detection yourself by adding the captive portal detection pages to your wag MFA list then the browser should do everything else for you.

Unfortunately doing interception or acting like a proxy isnt something Im looking to do with wag (which makes authorisation timeout/logout a bit easier to deal with)

Hope that answers things!

[ta1243]

The problem I've seen when I've looked at this is signalling to the user that the session has ended. Sure your EBF filter stops passing traffic, but the user as to know that they need to visit a page to reauthenticate

That requires integration with a client, which is a massive pain to integrate

[hnarn]

It sounds like upon expiry, you could redirect all 80/443 traffic to the same node, serving an error page. In my mind, that's better than having to install a client.

[Nullence]

Probably then is how you do TLS, i.e do you give your service a wildcard cert to capture any 443 traffic.

Then how do you do that for things like ssh, or other non-http based protocols.

[20after4]

> I've on and off looked for a wireguard client which can do something like the captive portal detection on wifi. Ideally it would be an extra line in the config file (like persistentkeepalive), which does a URL pull. Could be checked periodically (like with the keepalive). If it returns "OK", then fine, if it doesn't return then there's a network problem, but if it returns a "Location" header, the client would pop up a browser at that location, allowing for session reauthentication or whatever.

That would be really cool. I hope the author of this will consider it.

[Nullence]

Ironically I've also been thinking about this on and off for a bit, as it is definitely one of the pain points of using Wag at the moment.

My only problem is that if you capture that route and then redirect it, or whatnot, your peers wont be able to log in to wifi in public areas like coffee-shops/libraries/etc because the route will be trying to go via a VPN which wont be returning any real data.

Such as where you should be going to log in haha

[baobun]

Should be doable using FwMark and routing policy / nft rule?

So you'd put a fwmark on the interface , allowing you to route the VPN traffic separate from the traffic that should go over it. Then you have some mechanism to trigger when VPN is down. Curl someplace dedicated which also has a routing exception to go outside the tunnel. Detect captive portal IP. Add route (and clean up, like when online or switching).

[ta1243]

Detecting captive portals re-establishing is a separate, but linked issue. It's mostly solved too.

Setting aside a VPN client, your browser and/or OS will send out a http get request to a site which returns "OK" or "success". If it returns a redirection, then it will go "ahha I'm behind a captive portal" and pop up a page for you to log in.

VPNs do something similar. The MozillaVPN client for example will periodically check for reauthentication by doing a http call over the non-VPN route to a server and looking for a response saying "success". If it needs a redirect it flags up a message on the client to disable your client and reroute traffic via normal networking to allow reauthenticaiton.

What I want from a wireguard client is it to check for captive portals outside (in a situation I'm routing the entire of 0.0/0 via wireguard), but also check for reachability inside the tunnel. Have "check" and "checktime" parameters, which poll a given server (presumably via the tunnel) preset a popup to reauthenticate.

[blipvert]

I have written a similar server (per-device client cert required which gets you mTLS to a logon page which uses OIDC the authenticate the user and enable the tunnel) but the client is the tricky bit.

I have written one in Go for the Mac which uses the command line wg from Brew and handles key gen, but it is clunky and requires sudo.

A proper native app which uses the network entitlements would be great, but it is beyond my ken