Best way to resolve tailscale and wireguard race condition
from Infernal_pizza@lemm.ee to linux@lemmy.ml on 02 May 23:06
https://lemm.ee/post/62929645

I’ve had a VPN running on my server via Wireguard for ages with no issues. A couple of weeks ago I finally got round to setting up Tailscale so I could access it remotely and again it worked fine without any issues. I rebooted my server this morning and while I was out I realised I could no longer access it, once I got home I discovered everything else was working fine it was just inaccessible over Tailscale.

After some troubleshooting I’ve come to the conclusion that if Tailscale starts first the other VPN’s routing entries take priority and Tailscale doesn’t work. If Tailscale starts second then it seems to work fine. As far as I can tell I have a few options for fixing this but I’m not sure what would be the most recommended. The simplest solution is probably just to disable Tailscale from autostarting and start it manually, however I’m likely to forget that at some point and will probably only notice when I’m out and can’t access the server to start it.

If I add the following to the Wireguard config file this solves the issue: PostUp = ip route add 100.64.0.0/10 dev tailscale0
PostDown = ip route del 100.64.0.0/10 dev tailscale0 However in that case if the other VPN tries to start first it just fails as the tailscale0 interface doesn’t exist yet, so all I’ve done is reverse the order I need them to start.

I could also edit the wireguard or tailscale service files with before or after targets, that would be fairly simple to do but I think its not recommended to manually edit package provided service files? The tailscale one specifically says its meant to be read only.

The final option I can think of is to disable the tailscale service on startup and then create a systemd timer to start the tailscale service with a slight delay after boot. I think this may be the best method as I can’t see any downsides, but maybe I’m overlooking something?

#linux

threaded - newest

TauZero@mander.xyz on 02 May 23:42 next collapse 

PostUp = ip route add 100.64.0.0/10 dev tailscale0

Looks like you need to stick this line in the tailscale service file, since it’s the only time that the existence of the tailscale0 device is guaranteed. If you don’t want to modify the service file inside the package, could you write your own systemd service file and include the tailscale service as a prerequisite?

Also make sure that when you start the VPN first and then tailscale, you don’t get a double tunnel situation where tailscale goes out through the VPN (unless that’s what you wanted).

Infernal_pizza@lemm.ee on 03 May 08:29 collapse

Also make sure that when you start the VPN first and then tailscale, you don’t get a double tunnel situation where tailscale goes out through the VPN

Do you know how to check if this is the case and how to prevent it? I’d rather it wasn’t doing that but there’s a decent chance it is

TauZero@mander.xyz on 03 May 14:32 collapse

Use wireshark and listen on your ethernet interface. When you use tailscale, are the packets coming in/out from the tailscale server IP or the VPN ip? Check through the ip route routing table and figure out which pathway a packet will take in each use case. Might need to add a route exception specifically for the tailscale server IP to go out on the ethernet device.

melmi@lemmy.blahaj.zone on 03 May 00:37 collapse

Editing the systemd services seems a neat solution here. Rather than editing the package-provided service files directly, you can create overrides using systemctl edit.

Another more hacky option would be to use the PostUp directive but account for the case there’s no tailscale0 device yet. Write a simple shell script or something.

Infernal_pizza@lemm.ee on 03 May 08:28 collapse

Thanks, I didn’t know systemctl edit was a thing!