undefined | Better HN

0 pointsNullence1y ago0 comments

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

0 comments

baobun1y ago

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).

ta12431y ago

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.

j / k navigate · click thread line to collapse