(github.com)
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.
fly.io provides a way to connect to their servers via wireguard (https://fly.io/docs/blueprints/connect-private-network-wireg...), and so tailguard could connect to their wireguard instance?
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.
What do you mean? I've had great luck using specific routes over wireguard with the official app on my phone. It works great with "on-demand" wg, and only routing my home subnet over it.
Now, some "business" vpns suck donkey balls, but these are usually borked beyond belief without any external help. I'm specifically thinking about the dotted red square one.
https://developer.android.com/reference/android/net/VpnServi...
"There can be only one VPN connection running at the same time. The existing interface is deactivated when a new one is created."
Note this is not about routing some traffic to the VPN and other traffic to the clear net. This is about running two VPN connections simultaneously.
On Linux, I have no problem running either bare wireguard or tailscale alongside Forticlient. On Windows and macOS it's a bit more janky, specifically the DNS resolution, but I don't daily drive these platforms so I may be missing some kind of knowledge to fix this.
- 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.
It works great.
I might misunderstand, but to me it looks like the solution in this post might be better than my setup because if that single node is down I won't be able to reach the fenced router.
Even in this case, you still need to have a node somewhere to run the container and store the WireGuard keys, to be able to link the tailnet and the WireGuard endpoint. So that single point of failure still unfortunately remains.
The benefit of having it all configured in a single container means it's pretty easy to spin up anywhere (where the fenced router is accessible), all you need is the tunnel config file.
I also wanted to make sure it works for both IPv4 and IPv6 connections, because many ISPs in my area are starting to only give public IPv6 addresses. That way as long as the WireGuard router has IPv6 and the node running the container has IPv4/IPv6 dual stack, one can still access the Wireguard from an IPv4 only device.
It will also by default route traffic to the already advertised other subnets in the tailnet, but taking that into use requires a bit of manual configuration on the other end of the WireGuard tunnel. Each subnet needs to be routed through the WireGuard tunnel first to make it work.
Managing the advertised subnets manually is a bit of a pain, while the downsides of accidentally advertising a subnet are negligible, since you still have full control over them in the Tailscale console.
I have several of them in a cross Atlantic Wireguard mesh, and they are bulletproof.
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.