A brief technical description of Tailscale: Tailscale builds an encrypted private network using WireGuard, while handling peer discovery, authentication, NAT traversal and changing public IP addresses for you. Unlike a traditional self-hosted WireGuard server, it normally does not require port forwarding or a dynamic DNS service. I still prefer bare WireGuard as my primary VPN when it is available because it is simpler and can provide better throughput, but Tailscale is an excellent backup and is sometimes the only practical option.
Reasons to choose Tailscale include:
gl-tailscale-fix plugin replaces the old manual system-file modification. The plugin also provides a stronger daemon-independent kill switch and remains useful on 4.9+ for IPv6 and guest-network protection. See Route A and Step 6 below.
Whenever possible, Tailscale establishes a direct peer-to-peer connection. In some cases it cannot, so traffic uses one of Tailscale's DERP relay servers instead, which can reduce throughput and add latency. Tailscale documents several steps that may help establish a direct connection. For more information on bare WireGuard versus Tailscale and why I use WireGuard as my primary and Tailscale as my backup, see my VPN Comparison page.
It is also possible to host your own DERP relay server, but it can be complex for someone inexperienced with networking and web hosting. For this reason, I offer a monthly option on my Tiers page (Diamond Tier) to use your own unthrottled custom DERP relay server with a simple ACL configuration.
Relay update: Tailscale has introduced Peer Relays, an easier built-in way to turn a device in your tailnet into a high-throughput relay. Peer Relays entered public beta in October 2025 and became generally available in February 2026. The important caveat is that Peer Relays use a configurable UDP port which must be reachable by the participating devices. If blocked UDP is the reason a direct connection cannot be established, a Peer Relay may be unreachable for the same reason. That is why I still use the older custom DERP approach: its TCP-based relay path is more likely to work through restrictive firewalls that block UDP.
Note: When Tailscale is running directly on a device, corporate VPN software such as Zscaler or Cisco Secure Client/Umbrella may interfere with Tailscale networking, including direct UDP connectivity. However, when Tailscale is running on the travel router, software running on a connected laptop does not control whether the router establishes a direct Tailscale connection or uses a DERP relay. Corporate VPN software on the laptop may still cause routing, DNS, or MTU issues inside the Tailscale connection (to avoid MTU issues, consider a ZeroTier setup, which RemoteToHome can configure for you).
Before I continue with the technical implementation, a quick disclaimer: I am not liable for any troubles you cause yourself or your company including but not limited to: termination of employment due to policy violation, failure to obey tax compliance laws, protection of customer data, country data requirements in your respective country.
GL.iNet now supports Tailscale on a much wider range of routers; use the current supported-model list rather than relying on an old fixed list. As of August 2026, firmware 4.9 is in the stable channel for Flint 3, Slate 7, Flint 2, Brume 3 and Beryl 7, while the 4.9 builds for Beryl AX, Spitz AX and Puli AX remain beta. Check the GL.iNet Download Center for your exact model before following the 4.9 path below. GL.iNet's documentation still labels the Tailscale feature itself beta; a stable firmware channel does not mean every Tailscale edge case has been eliminated.
You only need one device acting as the home exit node. Choose the route that matches your hardware and firmware, complete that section, and then continue with the shared travel-router instructions in Step 4.
Easiest route. Use GL.iNet's native Run Exit Node control. Add the RTH plugin to the travel router for stronger kill-switch coverage.
Use the GL.iNet routeUse RemoteToHome's plugin to add Advertise as Exit Node without modifying GL.iNet-owned system files.
Use the plugin routeUse a dedicated Linux exit node when your router is unsupported or when you prefer to keep the VPN server separate.
Use the Pi routeThis route replaces Raspberry Pi Steps 1–3. Plug the GL.iNet home router's WAN port into a LAN port on your primary home router, connect a personal computer to the GL.iNet router's LAN port, and open its admin panel (normally http://192.168.8.1).
Firmware 4.9 supplies the exit-node function natively, so the RTH plugin is not required merely to advertise the home router. I still recommend installing it on the travel router in Step 6 because its daemon-independent kill switch extends protection to IPv6, the guest network and exit-node changes.
gl-tailscale-fix package, then enable Advertise as Exit Node under Tailscale Enhanced.Use either installation method from the maintainer's current guide:
gl-tailscale-fix_latest_all.ipk, then open System > Advanced Settings > LuCI > System > Software > Upload Package.ssh root@192.168.8.1, then run:wget -q https://github.com/RemoteToHome-io/gl-tailscale-fix/releases/latest/download/install-gl-tailscale-fix.sh -O install-gl-tailscale-fix.sh && sh install-gl-tailscale-fix.sh
After installation, return to Applications > Tailscale. The additional controls appear under Tailscale Enhanced. Do not edit /usr/bin/gl_tailscale; current plugin installers detect and restore that obsolete manual modification to avoid conflicts.
A travel router is needed because we are unable to install 3rd party software, let alone a VPN client, onto our work machine. So we will connect the work computer to the travel router like a normal Wi-Fi network, and the router will point everything to our VPN server. Think of the travel router as a repeater that takes your Airbnb/hotel Wi-Fi network and re-broadcasts it to your device. Of course, we will only use a wired ethernet connection from the laptop to the travel router, never Wi-Fi as this can expose our location.
Follow Steps 1–3 below only if you selected the Raspberry Pi/Linux route. GL.iNet exit-node users should continue directly to Step 4.
Raspberry Pi Documentation - Getting started
The official documentation for Raspberry Pi computers and microcontrollers
Insert the microSD card into your personal laptop using whatever adapter necessary. Install the official Raspberry Pi Imager and go follow the steps to flash the OS to your microSD. Don't forget these things:
Once you finish flashing the microSD, insert it into the Raspberry Pi and power the Pi. Then, attach an Ethernet cable between the Pi and your computer (you may need a Thunderbolt or USB-C to Ethernet adapter). Turn off Wi-Fi on your Mac so we can only connect to the Pi.
Navigate to your command prompt or terminal (on Mac/Linux), or on Windows open start menu and type "command prompt" and connect to the Pi by running 'ssh username@hostname'. Below, we use the default 'pi' username and the 'raspberrypi.local' hostname. Alternatively, you can use the Pi’s IP for the hostname assuming your laptop has a built-in DHCP server (it should).
ssh pi@raspberrypi.local
or if that doesn't work, use the Pi's IP address:
ssh pi@your-Pi-IP-address
You can find the Pi IP address a number of ways. One way is to go into Network settings on Mac and view the IPv4 address on the Ethernet connection. Or type "ifconfig" in the terminal.
Note that as you type in the password, you will not see the characters show on the screen. This is normal. If you having issues with SSH, it's possible you have a bad cable.
Once you’ve logged into the Pi via SSH, run the following:
systemctl enable ssh
systemctl start ssh
These two commands will permanently enable SSH on the Pi and start the service. This really shouldn’t be necessary since the imager should already run this for you, but it doesn’t hurt.
And lastly (optional), disable Wi-Fi since we don’t need it and to reduce power draw.
1. Open the config.txt file located on the boot partition: /boot/config.txt inside Raspberry Pi.
2. Add dtoverlay=disable-wifi under [all] to disable Wi-Fi.
3. Save and reboot your Raspberry Pi.
To enable it again just remove dtoverlay=disable-wifi in your configuration and reboot.
Simply re-run this command but with “unblock” if you wish to re-enable it ever.
First, we need the subnet to match the local internet’s. So, verify whether your router at home uses 192.168.1.x or 10.0.0.x addresses (remember x is only 1-254). To do this, open a terminal window on your laptop connected to the Wi-Fi and type ifconfig and then look for the IPv4 addresses to the right of en0:. Alternatively, go to your network settings and view the IPv4 address. Also, take note of the router IP, you will need that in a second.
Next, we will modify /etc/network/interfaces and add some code. Note: Since Bookworm, you will have to follow these instructions to configure the static IP.
Use your preferred editor by typing sudo nano /etc/network/interfaces or sudo vi /etc/network/interfaces.
Add the below block of code, where “??”, is any number (0–254) that is not a currently used IP on your network. Next, 10.0.0.1 is the IP of the Xfinity home router in my case. Replace this with whatever your router IP. This is set to both the gateway and dns-nameservers entries as shown below. 8.8.8.8 is an additional DNS entry and happens to be Google’s server.
#static IP address for eth0
auto eth0
iface eth0 inet static
post-up /sbin/ethtool --set-eee eth0 eee off
address 10.0.0.??
netmask 255.255.255.0
gateway 10.0.0.1
dns-nameservers 10.0.0.1 8.8.8.8
eth0 at the top specifies that we are using an ethernet connection to our router’s LAN port. Using an ethernet/wired connection to your home’s internet service ensures the fastest possible speeds.
Reboot for the changes to take effect.
sudo reboot
Now, plug the Pi into one of your home router’s LAN port and ensure the green light is blinking.
Now that we’ve set a static IP for the Raspberry Pi and connected the Pi to the router, we should be able to access it by using SSH on the local network. Using your laptop (connected to the home Wi-Fi) open a terminal window and type:
ssh pi@raspberrypi.local
OR
ssh pi@static-IP-you-set (ex. 10.0.0.?? or 192.168.1.??)
If you are successfully able to access your Pi, then congrats for making it this far! If not, there could be a problem with the IP you set. Go verify your /etc/network/interfaces again.
We’re ready to install Tailscale on the server to create the VPN, or what Tailscale calls an “exit node”. To install on your Rasp Pi running Linux, simply run the following command:
curl -fsSL https://tailscale.com/install.sh | sh
If this doesn’t work, then determine the particular OS you are running on the Pi. If you don’t remember, simply run the command below and read the first line of the output:
cat /etc/os-release
You’ll see the Linux distro name on your Pi. Using this info, try a manual install by following instructions here.
Once installed, follow the Tailscale documentation in order to set up your exit node. Be sure to select the "Linux" instructions in order to properly configure your Raspberry Pi's operating system. Step 2 and 3 here: https://tailscale.com/kb/1103/exit-nodes/
Run the IP-forwarding commands:
echo 'net.ipv4.ip_forward = 1' | sudo tee -a /etc/sysctl.d/99-tailscale.conf
echo 'net.ipv6.conf.all.forwarding = 1' | sudo tee -a /etc/sysctl.d/99-tailscale.conf
sudo sysctl -p /etc/sysctl.d/99-tailscale.conf
NOTE: In Step 2, run it as:
sudo tailscale up --advertise-exit-node --accept-routes
This allows the GL.iNet subnets that we approve in Step 5. If you missed it, you can run the command again later.
Once finished, give your Tailscale web admin panel a look-over to confirm everything is configured correctly as the documentation instructs. For example, click the 3 dots button all the to the right of the "raspberrypi" exit node and click on "Edit route settings…" and make sure exit node is switched ON.
Your Tailscale machines page should now show your Raspberry Pi and your Travel Router as such:
Don't forget to click the 3 dots on the right side for both the Pi and the GL router and "disable key expiry" for both the Pi and your GL-iNet router. This is extremely important to ensure we maintain authenticated. For example, if the key expires on the exit node and you are out of the country, you will be unable to regenerate a key without manually being present at the Raspberry Pi.
In general, Tailscale documentation is very good so it's good to refer to it often throughout the process.
Once your exit node is live and all settings are correct based on Tailscale documentation, we can configure the travel router.
Simply connect an ethernet cable between the powered GL-iNet router’s LAN port and your personal laptop. Then, open a browser and type 192.168.8.1 to see the login screen.
Once you’ve logged in, enable the Repeater function on the “Internet” page, and connect the router to your cellphone hotspot or some Wi-Fi network other than the home network hosting your exit node.
Next, navigate to the Applications page and at the bottom enable Tailscale. If you don’t see Tailscale and/or the installation of the Tailscale plugin fails, try upgrading the firmware on your GL-iNet first.
Follow the binding instructions here: Tailscale - GL.iNet Router Docs 4
Enabling Tailscale will allow us to force all Internet traffic coming into the router (i.e., from your work laptop) to pass through your VPN server (aka “exit node”) back at home.
Once you’re finished with this step, you can confirm the router has Tailscale installed and connected to your account by viewing the Tailscale web admin page to see “Connected” with the green dot as shown below:
Enable Custom Exit Node, select the home exit node and click Apply. On firmware 4.9+, also enable Advertise LAN Subnets and IP Masquerading. Wait for the Tailscale status to return to green before testing.
Open the Tailscale Machines page, locate the travel router, choose Edit route settings and approve its advertised LAN route. Approve the guest route too if you enabled guest-network access through the plugin. Current GL.iNet firmware advertises these routes from the admin panel, so the old manual tailscale up --advertise-routes=... command is no longer the default procedure.
Use a unique LAN and guest subnet on every router. If the home and travel routers both use GL.iNet's default 192.168.8.0/24, Tailscale cannot reliably determine which router owns that route. For example, keep the home router on 192.168.8.0/24 and change the travel router to 192.168.10.0/24 under Network > LAN.
Once you’ve enabled subnets, verify that the “Edit route settings” page for your GL.iNet router shows the intended, non-overlapping route:
tailscaled itself crashes, is killed for lack of memory or is absent during a service restart. A brief leak can still be enough for a continuously connected service to record the travel IP.
Install the current gl-tailscale-fix plugin on the travel router and enable its Kill Switch after selecting the custom exit node. The plugin keeps independent kernel policy-routing blocks in place when the Tailscale daemon is not running, and its current release covers both IPv4 and IPv6 as well as the optional guest network.
The plugin remains useful on firmware 4.9+. Newer 4.9 builds include a native daemon-independent kill switch, but RemoteToHome's testing describes the native coverage as IPv4 on the primary LAN only. The plugin coexists with it and adds guest-network, IPv6 and exit-node-change protection. Follow the maintainer's current guide because these details may change with later GL.iNet releases.
Do not substitute GL.iNet's general Block Non-VPN Traffic control for this step; that control is designed around GL.iNet's conventional WireGuard/OpenVPN client framework, not this Tailscale failure mode. After setup, test from a device behind the travel router by confirming the home IP, stopping tailscaled on the travel router and verifying that internet access stops rather than falling back to the local WAN.
Now that you’ve turned on the Tailscale exit node on your travel router, connect your client laptop to the travel router using the Repeater function (connect to a phone hotspot, not your home network). You don’t want to test if your VPN works by connecting your travel router to the home internet!
Once your travel router is receiving internet, open a new browser tab on your connected device and visit: https://icanhazvpn.com
Check if the IP address matches your home IP address.
Remember that the maximum DOWNLOAD speed you will be able to achieve at your work computer when connected to the Tailscale exit node will be your home internet’s UPLOAD speed. If this doesn’t make sense, try drawing out on a piece of paper the connection including acknowledgements/requests between your client computer and the Internet (via your exit node).
On the travel router, go to Network > DNS, enable Override DNS Settings of All Clients, then use Encrypted DNS (recommended) or manually enter public resolvers such as 1.1.1.1 and 8.8.8.8. Automatic DNS can inherit a private resolver from a hotel or local ISP that becomes unreachable after traffic moves through the exit node.
GL.iNet's Tailscale integration uses --accept-dns=false, so nameserver and MagicDNS selections in the Tailscale admin console generally do not configure DNS for clients behind the router. Configure DNS on the GL.iNet router itself.
After configuration, verify both the public IP and DNS path from a device connected behind the travel router. The exit-node router at home can normally remain on Automatic DNS because its local WAN resolver is directly reachable.