Tailscale on OPNsense is a plugin now, so you don’t need SSH, a root login or a ports build to get it running. On OPNsense 24.7.11 and later, the Tailscale OPNsense plugin (os-tailscale) installs from System > Firmware > Plugins, and it’s configured from VPN > Tailscale in the web GUI. Everything below is on OPNsense 26.7.8 with os-tailscale 1.4 (as of November 2026).
This guide used to walk the SSH and ports route, because there wasn’t a plugin when it was first written. If you installed Tailscale that way, the last section shows how to move to the plugin, and it’s the only part that needs a shell on OPNsense.
The reason to run Tailscale on the firewall is that you can reach your whole network without a port forward. I’ve never port forwarded to get into my own network and don’t plan to, since I use a VPN instead. If you need a forward for something else, here’s OPNsense port forwarding. If you’d rather run a traditional VPN server, WireGuard on OPNsense is the alternative, and Tailscale vs WireGuard covers how they differ. For pfSense, there’s a separate guide for Tailscale on pfSense.
Install the os-tailscale Plugin
To install Tailscale on OPNsense, you use the normal plugins page. os-tailscale is a community plugin, though, and OPNsense doesn’t list those by default, so there’s one extra click before it shows up.
1. Open System, select Firmware, and finally, Plugins.
2. Scroll to the bottom of the list and select Click to view the community plugins. (The OPNsense manual and Tailscale’s docs both still describe a Show community plugins checkbox, but on 26.7.8 it’s this link.)
3. Filter the list to tailscale, find os-tailscale (version 1.4, “VPN mesh securely connecting clients using WireGuard”) and select + to install it.
4. When the install finishes, the plugin adds VPN > Tailscale to the menu, with Authentication, Settings and Status pages.
The OPNsense Tailscale plugin first shipped as os-tailscale 1.0 in OPNsense 24.7.11 (December 2024). Tailscale lists OPNsense as a community supported platform in its OPNsense documentation. Since it’s a regular plugin, it updates through System > Firmware with the rest of OPNsense, so there’s none of the manual make deinstall and make install routine the ports build needed.
Connect OPNsense to Your Tailnet
The OPNsense Tailscale setup is spread over three pages. Settings turns the service on, Authentication logs it in to your tailnet, and Status shows whether it worked.
1. Open VPN, select Tailscale, and finally, Settings. On the Settings tab, tick Enabled.
2. Leave Listen Port at 41641 and Accept DNS ticked unless you have a reason to change them, leave Accept Subnet Routes unticked (it’s for using routes other nodes advertise), then select Apply.
Turning on advanced mode adds Login timeout, Enable SSH and Disable SNAT. Leave Login timeout at its default of 10 seconds, because the plugin’s own help warns that 0 (wait indefinitely) “may prevent OPNsense booting completely if the Tailscale control plane is unavailable.”
3. Open VPN > Tailscale > Authentication. Leave Login Server at its default, https://controlplane.tailscale.com, to use Tailscale’s own service (it’s the field you’d point at a self-hosted control server such as Headscale).
4. With nothing in Pre-authentication Key, select Apply, open VPN > Tailscale > Status, copy the AuthURL value on the General tab into your browser and log in. To use a key instead, generate one with Generate auth key on the Keys page of the Tailscale admin console’s Settings, leaving Reusable and Ephemeral off, then turn on advanced mode, paste it into Pre-authentication Key and select Apply.
Both stay off: Tailscale’s auth keys page says “Be very careful with reusable keys!” An ephemeral device is removed after it goes offline, which is the last thing you want for a firewall.
5. Once OPNsense shows up in the Tailscale admin console, open the Machines page, select the menu at the far right of its row, and select Disable Key Expiry.
Node keys expire every 180 days by default, and when one does, connections to and from that device stop working. Tailscale’s key expiry docs suggest turning it off on a subnet router, and the plugin’s own help says the same. Once it’s connected, the Status page’s General, Peers and Net Check tabs show the node, your other devices and Tailscale’s network check from the firewall.
Advertise Your LAN as a Subnet Route
Advertised routes are just the local subnets you want to reach over Tailscale. Adding them turns this into an OPNsense Tailscale subnet router, so tailnet devices can reach things on your LAN that don’t run Tailscale themselves. In my 2022 Tailscale on pfSense video, that was my 192.168.100 subnet, but yours is going to be something different depending on what you have at home.
1. Open VPN > Tailscale > Settings, select the Advertised Routes tab, and select +.
2. Enter the Subnet in CIDR notation (for example, 192.168.1.0/24), give it a Description such as LAN, and select Save. Add one row for each subnet or VLAN you want to reach (IPv6 routes work too).
3. Select Apply.
4. In the Tailscale admin console, open Machines, find OPNsense (it carries a Subnets badge, or filter by property:subnet), select it, then select the routes in its Subnets section and Save.
It doesn’t matter whether you add routes before or after logging in, because the plugin sends them every time the service comes up. Android, iOS, macOS, tvOS and Windows clients pick up new routes automatically, while Linux clients need --accept-routes. The subnet routers docs cover that, plus the autoApprovers option that skips the approval step. Subnet routers also use source NAT by default, so tailnet traffic shows up on your LAN as coming from OPNsense. Disable SNAT (advanced mode) changes that, but its help reads “Disable source NAT to disable subnet routing (experimental)”, so leave it off.
Use OPNsense as a Tailscale Exit Node
An OPNsense Tailscale exit node is how you get a full tunnel VPN out of this. You advertise it in the plugin, approve it in the admin console, then pick it on each client. I explained the full tunnel part this way when I covered pfSense in 2022: when you use the exit node, all traffic routes through it. If you leave your device’s exit node set to None, you’re still going to be able to access everything on your local network, just in split tunnel mode. I want to be clear that you don’t have to use it as an exit node, but you’ll have the option, and it’s worth turning on when you’re on public Wi-Fi.
1. Open VPN > Tailscale > Settings, tick Advertise Exit Node on the Settings tab, and select Apply.
2. In the Tailscale admin console, open Machines, find OPNsense (it carries an Exit Node badge, or filter by property:exit-node), open its menu, select Edit route settings, tick Use as exit node and Save.
3. On each client, choose OPNsense as the exit node (the Exit Node section on Android, the top of the screen on iOS), and turn on Allow LAN access (Allow Local Network Access on macOS and Windows) if you still want to reach your local devices. Selecting None turns it back off.
The subnet route on its own doesn’t make anything full tunnel (the exit node does), and every client has to opt in to the exit node before any of its traffic goes through OPNsense. FreeBSD isn’t on the platform list on Tailscale’s exit nodes page, so this is the plugin offering it on a community supported platform, not an officially supported setup.
Assign the Tailscale Interface and Add a Firewall Rule
OPNsense doesn’t assign the Tailscale interface for you, and the plugin adds no firewall rules of its own. Until you do both, Tailscale’s docs say the default policy “blocks incoming Tailscale traffic to the OPNsense host, including ping, SSH, and web UI access.” The tailscale0 device shows up in the assignment list as soon as the service is enabled, before it’s even logged in. OPNsense 26.7 rebuilt the Assignments page and made the newer Rules page the default, so the steps below use the new labels rather than the older ones in Tailscale’s docs.
1. Open Interfaces, select Assignments, and select the add button (+).
2. Set Device to tailscale0, leave Enabled and Lock (which prevents accidental removal) ticked, and give it a Description such as Tailscale. Save the dialog, then select Apply on the Assignments page.
3. Open Firewall > Aliases, add a Host(s) alias (for example TailscaleAdmins) with the Tailscale IP of each device that should reach the firewall (its 100.x address on the admin console’s Machines page), then save and Apply.
4. Open Firewall > Rules, select the Tailscale interface in the interface filter, and add a rule (the selected interface is filled in for you). Set Action to Pass, set Source to that alias, then save and apply.
A Pass rule that matches all traffic lets any device in your tailnet reach the OPNsense host, which is why Tailscale’s docs suggest the alias as the source. This rule is what lets tailnet devices reach the firewall itself. If something still isn’t getting through, Firewall > Log Files > Live View shows any tailscale0 traffic the default deny is blocking.
You don’t need to open anything on the WAN, but there’s one NAT caveat. Tailscale’s docs describe OPNsense’s NAT as endpoint-dependent (“hard”) NAT, so devices behind it often fall back to Tailscale’s DERP relays instead of connecting directly. OPNsense 26.7.2 added endpoint-independent (full cone) UDP translations to source NAT (the Endpoint Independent option on a source NAT rule), which Tailscale says can replace the workaround it suggested for earlier versions. NAT-PMP is the other option, from the os-upnp plugin: under Services > UPnP IGD & PCP > Settings, tick Enabled and Enable PCP/NAT-PMP protocols, and pick your LAN under Internal interfaces, then Save. To see whether a LAN device connects directly or through a relay, run tailscale ping <node> on it, and the reply shows which path it took.
If Tailscale Is Not Running on OPNsense
If the Status page’s General tab shows “Unable to determine Tailscale status, is the service running?”, the service is not running. Tick Enabled on the Settings tab and select Apply, since the service does not exist until that box is ticked. After that, it’s listed as Tailscale under System > Diagnostics > Services, where you can start, stop or restart it.
If OPNsense dropped off your tailnet, an expired node key is the first thing to check. An admin can select Temporarily extend key from the device’s menu on the Machines page, which buys 30 minutes to select Disable Key Expiry from the same menu.
Moving From the Old Ports Install to the Plugin
If you followed the old version of this guide, Tailscale is running from a ports build that you update by hand. The switch below is the one an OPNsense forum user posted in March 2025, in the New Tailscale plugin VS old method of installation thread.
1. Over SSH from your LAN (not over Tailscale) or at the console, as root, run the commands below to check, stop and disable the old daemon.
service tailscaled status
service tailscaled stop
service tailscaled disable2. Install os-tailscale from System > Firmware > Plugins and configure it the way the sections above describe.
3. In the Tailscale admin console, approve the subnet routes and the exit node again, since that forum user had to redo both under Machines.
Once it’s working, turn off Permit root user login and Permit password login under System > Settings > Administration (Secure Shell) if you enabled them only for the old method. Security changes all the time and nothing here is guaranteed, so keep the plugin updated and keep that Pass rule as narrow as you can.
