Decided to try dusting off my old Gl.Inet travel router and replacing OpenVPN with Wireguard for both fun and performance. I realize support is a bit "beta" (but works thanks to the efforts of several community members to write luci modules, thanks!) but I've run into some issues that perhaps people have solved already:
Scenario: I'm trying to make the travel router as "self service" as possible so I can let family borrow it and or use it when I'm not in the room. Essentially under OpenVPN it followed this cadence after boot/interface detection:
Detect captive portal.
If none detected, attempt to start OpenVPN. Backoff on failure, re-check for portal every hour or so.
If portal detected, then stop OpenVPN and sleep for a bit. Re-check with backoff.
Test ping to a known public IP every few mins. If it fails, try to restart openvpn, then portal, etc.
(yes, I realize this isn't as secure as failing closed without VPN, but I'd rather a family member hit the captive portal and re-login to it with a couple mins of unencrypted internet than explain to them how to manually stop the daemon).
OpenVPN as a "batteries included" solution seems to do a good job of restoring routes. Wireguard isn't meant to do this AFAIK as a "minimal secure viable product" type of thing, so you'll have to do it yourself.
Enough background, sorry about that! I've been trying to ifdown the Wireguard interface to do portal detection, only to find it...well, it doesn't come back up. Just gone. If I wait a few mins OpenWRT decides "oh dear" and restarts the entire networking stack (not sure how to trigger this manually), at which point Wireguard is back.
Additionally, if you ifdown Wireguard, it takes the default gateway with it. Manually setting routes doesn't seem to fix it.
Finally, and this might be my wg server, Wireguard seems to be pretty spotty with handshakes. I've seen the gateway listed as up but the last handshake occurring over 16 hours ago, now it just went to 7 seconds ago. Maybe a keepalive issue?
WireGuard, according to their website, "is not a chatty protocol."
By default, WireGuard tries to be as silent as possible when not being used; it is not a chatty protocol. For the most part, it only transmits data when a peer wishes to send packets. When it's not being asked to send packets, it stops sending packets until it is asked again.
I have the same Gl inet travel router and have make it self service. I found
the easiest way is have multiply AP points with multiply dnsmasq.
repeater - passthrough with rebind protection off (captive portal)/using upstream dns
repeaterVPN - openvpn vpn with killswitch/dnsleak protection/using its sets of dns
repeaterWG - wireguard vpn with killswitch/dnsleak protection/using its sets of dns
Luci will not do any of this, shell scripts will. So you need to lookup
policy based routing (default route is the passthrough)
how to create multiple dnsmasq, one for each AP
how to create multiple AP point
dns redirect for each AP
Testing using ping is poor as website might ignore icmp. check if port 443 is open is a better solution
nc -z -w1 www.example.com 443 ### uses default route
nc -z -w1 www.example.com 443 -s <ipAddr of openvpn/WG tunnel tun0/> ### check through the tun0
@jeff - I'll have to look in there to see why a manual ifup (which uses ubus I think) isn't bringing wg back up. A lot of my scripting was on the userspace daemon implementation of wg, so I might have forgotten something. Also, +1 on wg being silent, though it should be sending a keepalive packet every 25 seconds. In addition, I believe it re-handshakes every so often to maintain PFS. I'll have to enable more verbose logging if I can to see what's happening when it restarts networking.
@sammo - that's awesome! Would you care to share a sanitized version of the scripts? One note though, some captive portals are designed to ack on either common ports or all ports, so that might fail. I've noticed google does a HTTP 204 check and Apple does a load of a site that just returns text "Success". Maybe a broader use of these might be best?
Cheers - I ended up upgrading to a slightly beefier travel router (gl.inet 750S Slate) and it looks like between that and some of the custom scripting (gl.inet has an on/off script that restarts the entire networking stack) it's helped. Now if I could just get them to contrib to the main branch...