27 ms·

I could see the server side effectively operating like a public wifi hotspot and force all routing to a disclaimer type page. Then you could implement the 2FA

I could see the server side effectively operating like a public wifi hotspot and force all routing to a disclaimer type page. Then you could implement the 2FA there (or even proper username/password logins, which seems weird for WireGuard). If you enter the correct 2FA code, then your IP is no longer blocked. I know phones (and computers) can handle this when connecting to a new WiFi SSID, but do they also run their check when connecting over VPN? I might have to try that.

zamadatix 8y ago
I can confirm automatic captive portals work on most wired devices. Those that don't will have to go to http://example.com http://example.com or similar to be redirected. Word of warning for anyone that implements this: your DNS portal needs to be internal and captive as well.
ownagefool 8y ago
You could write a web portal that generate the wireguard configs on the server and offers the user the client config as a download. The portal then can hook upto to SAML / OIDC endpoint, use claims / groups / roles to offer specific profile configurations and you treat the keys in the configs as temporary tokens, as you attach an empiry time to the profile such as 8 hours, so your devs need to download a new configuration every day. I have a portal that does this for openvpn: https://github.com/secureweb/openvpn-portal https://github.com/secureweb/openvpn-portal The code quality isn't great as it's my hello world golang project, but I think the idea is fairly sound.