You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have been struggling with getting my setup working correctly, but have finally figured it out.
So wanted to share my notes in case anyone else want to use tailscale in the same way.
This is my setup and network flow:
A (router) -> B (RPi, two interfaces, eth0 and tailscale0) -> C (remote location, part of the tailscale VPN network)
A:
Open portforwarding to B.
B:
Forward the ports from local LAN to Tailscale
edit /etc/ufw/before.rules
(at the end, below the commit for the filter section)
When launching the Vrising server from a remote location, some traffic will go directly to steam. There will be a mismatch in the public server IP you want, and the IP that the server reports to Steam.
You will see this as Authentication Error when logging on to the game server.
So we need to route the Steam networks via the same IP.
sudo tailscale set --advertise-routes "192.168.2.0/24,155.133.224.0/19,162.254.192.0/21"
Then go to the tailscale admin page, and click on "Edit routes" for the machine, and approve the new routes.
C:
sudo tailscale set --accept-routes
Start the Vrising server
The text was updated successfully, but these errors were encountered:
My question to you is: if B and C are on the same Tailscale network (tailnet) why is A necessary at all?
My use case: I have a very powerful homeserver running Ubuntu with multiple dockerized apps forwarded via Tailscale and Cloudflared. I picked up a very low-end VPS in the same city as myself with sub 10ms ping times between server and vps. This VPS is specifically just used as an EXIT node/port forwarding on tailscale.
Appreciate any additional insight you can give, massively appreciated. Have not attempted to run server as of yet, so no issues to report.
A is needed because that's my router with the external ip. If you will just be playing with clients inside the tailnet, then you don't need that setup. In my case, A and B is at home and C is at work.
My apologies, I didn't realize you where running the server at work but exposing it publicly via your home public IP. Thanks for the clarifications!
I am actually looking to exact opposite, run the server at home but expose it via the cheapo vps. Should be simple enough to swap around the config info you provided for my use case.
I have been struggling with getting my setup working correctly, but have finally figured it out.
So wanted to share my notes in case anyone else want to use tailscale in the same way.
This is my setup and network flow:
A (router) -> B (RPi, two interfaces, eth0 and tailscale0) -> C (remote location, part of the tailscale VPN network)
A:
Open portforwarding to B.
B:
Forward the ports from local LAN to Tailscale
edit /etc/ufw/before.rules
(at the end, below the commit for the filter section)
When launching the Vrising server from a remote location, some traffic will go directly to steam. There will be a mismatch in the public server IP you want, and the IP that the server reports to Steam.
You will see this as Authentication Error when logging on to the game server.
So we need to route the Steam networks via the same IP.
Then go to the tailscale admin page, and click on "Edit routes" for the machine, and approve the new routes.
C:
Start the Vrising server
The text was updated successfully, but these errors were encountered: