I have heard not so great things about Forti VPNs, sorry to hear you have to work with those.
In theory, as long as the Forti VPN does not overlap with the Tailscale IP address range, the simplest solution is to just run Tailscale and openfortivpn on a single node. You can then advertise the Forti VPN subnets within Tailscale, that's effectively what my image does as well in a nutshell, except that it's parsing the WireGuard config and setting up firewall rules for convenience.
Tailscale does NAT automatically by default, so it will look like all traffic is coming from the openfortivpn client itself.
When I just try to run tailscale and forticlient together naively, tailscale does not like it very much heh. Looks like I'll need to study what your image is doing in depth
There’s unfortunately no always-on host supporting Tailscale. The Apple TV suggestion in the other comment is pretty good though, since it’s easy for anyone to use. Naturally requires having one though.
While I have no experience of their 5G routers specifically, based on my experiences with other GL.iNet routers and the TG-Link I have, I don't disagree. The Deco they have has the benefit of easy mesh wifi setup with fast roaming, but the easier access and configurability of GL.iNet are generally nice, and they're fairly affordable.
Since you have tailscale, and assuming your parents don’t do anything fancy, you can always double NAT. It especially doesn’t matter since you’re on CGNAT. Use the gl inet router as the primary and attach a mesh router behind it. You’ll be able to configure the secondary router through the primary.
Yeah you're exactly on point here, and this limitation exists on both iOS and Android alike. I got very frustrated with switching between VPNs and connections breaking every time I did that.
Looks interesting, I see you've added a light React UI and a simple REST API on the Go service to query for status and control the Tailscale interface. I'll make a note for sure!
I myself didn't really have a need to disable the interface during the lifecycle of the container, so I went with the standard containerboot process provided by Tailscale. I also wanted the container to be "invisible" and not respond to any incoming connections, so that it feels like you're running Tailscale on the actual router.
Keeping things a bit more granular and flexible for this use case makes total sense.
You definitely don't need that many lines of code, started with just a couple. After that I started having several small issues:
- the router is behind DDNS and changes its IP address on every connect, had to set up reresolve script and cron
- my WireGuard was capturing the default route and I wanted to use the DNS server behind the tunnel when using it as exit node, but that initially broke the DNS reresolve
- one WireGuard tunnel only supported IPv4, but the node I was running on had dual stack, half of the traffic ended up using IPv6 and not going through the tunnel at all
- when routing incoming connections from the other end of the tunnel to the tailnet, I realised Tailscale does SNAT by default for connections from tailnet to the router (this can be disabled), but the WireGuard connections were coming from an unknown subnet and I had to add masquerading rules
- Tailscale doesn't work so nicely with firewalls, it wants to either inject its chains as first or make you configure it after the startup, worked around by modifying a healthcheck to fix the firewall after startup
- I wanted to exclude the WireGuard device from Tailscale monitoring to avoid noise, there's a patch and multiple issues for that on GitHub that haven't been merged, included the patches in my image
I may have forgotten some other edge cases that came up, but here's a few. In addition, I wanted it to automatically parse the advertised subnets from the WG config, which added to the scripts a bit.
In short, it started out as a hack I didn't even think worth sharing, but more things broke than I would've imagined. So wanted to share with anyone who might find it useful.
I actually use the non-mobile Flint 2 myself at home, and it's one of the devices in my tailnet. I worked with their engineers on the forums to get better IPv6 support for their WireGuard tunnels. Running both Tailscale and WireGuard on it can mess up the routing at times though, so I prefer to stick to just either or.
It's a bit unfortunate they decided to go with Broadcom for their Flint 3 router, since Broadcom is known to not play well with open source. One of the reasons I got Flint 2 was its Mediatek chip, since stock OpenWRT support for that should get reasonably good eventually. They're all still way more open than TP-Link Decos.
Not super familiar with fly.io, but with a quick look at that page it should work just fine.
Just instead of dropping that camellia.conf to the WireGuard MacOS client or Linux wg-quick, spin up the TailGuard container somewhere (pretty much anywhere, but with good ping to fly.io). That way you should have the fly.io private network accessible in your Tailscale tailnet, it runs wg-quick internally alongside Tailscale anyway, just with a bit of scripting to automatically configure the network and the firewall to avoid connections leaking.
If it doesn't work, feel free to raise an issue and I can have a look.
In theory, as long as the Forti VPN does not overlap with the Tailscale IP address range, the simplest solution is to just run Tailscale and openfortivpn on a single node. You can then advertise the Forti VPN subnets within Tailscale, that's effectively what my image does as well in a nutshell, except that it's parsing the WireGuard config and setting up firewall rules for convenience.
Tailscale does NAT automatically by default, so it will look like all traffic is coming from the openfortivpn client itself.