Networking on Sysadmin Tales

Routing to Tailscale clients from a local network with OPNSense

Sat, 15 Aug 2026 16:45:12 -0400

Overview

Effectively, what we’re trying to accomplish here today is the opposite of a Tailscale Subnet Router.

As in, allowing clients on our local network to talk to devices via their Tailscale subnet IP addresses.

When I started looking into how to do this, I could not find a complete guide on the topic.

I’ll do my best to do this start to finish so that anyone else can follow along with me.

Prerequisites

You already have an OPNSense gateway setup and enabled as a Subnet Router on your Tailnet.
You’ll also need to have approved the subnets that you told the Subnet Router to advertise in your admin console.

Recommendations

Create an alias for the Tailscale subnet range so you can avoid typing it in 10x times.

Firewall > Aliases

Explanation

Tailscale Subnet Routers by default use SNAT (Source NAT).

This means that packets sent from your Tailscale devices to the Subnet Router will go through Network Address Translation on their way to the local subnets you’ve advertised.

So, any devices inside your LAN by default will only ever see the IP address of your OPNSense gateway - they will not see the IP addresses of the individual Tailscale clients. This is the first thing that we will need to disable.

Once we have this disabled, we’ll need to configure both a static route as well as firewall rules to allow the traffic to pass.

Step by step

Log into your OPNSense router and navigate to VPN > Tailscale > Settings. You’ll need to toggle on “Advanced Mode”. Check the box for “Disable SNAT”.
Now, what we need to do is create a static route - but before we can do that, we need to take care of some other items:
1. Add the Tailscale interface by going to Interfaces > Assignments. Click on the + button and add the Tailscale interface from the dropdown. Don’t forget to enable the interface - by default it will be added in a disabled state.
2. Create a new gateway - System > Gateways > Configuration. The interface should be “Tailscale”. Gateway name is technically arbitrary, but for the sake of simplicity I’ve also called it “Tailscale”. Make sure you disable gateway monitoring.
3. Now that we’ve done this, we can finally define our static route (System > Routes > Configuration). The Tailscale subnet is 100.64.0.0/10:
Now that we have the routing taken care of, we need to create some firewall rules to allow the traffic to pass. You’ll need to create at minimum 2 rules on the OPNSense side (Firewall > Rules):
1. On your LAN interface, define a rule that allows communication from your LAN to your Tailnet. For example -
```
Interface: LAN (Or whatever yours is called)
Action: Pass
Source: LAN network
Destination: 100.64.0.0/10
```
2. On your Tailscale interface, define the inverse:
```
Interface: Tailscale
Action: Pass
Source: 100.64.0.0/10
Destination: LAN network
```
Rule 1 may not be needed if you have the default “Allow All” rule in your configuration on the LAN interface. I do not, so I needed to allow that traffic.

Feel free to restrict this traffic however you would like. Personally, I only allow through a few kinds of traffic - DNS, HTTP/HTTPS, and ICMP echo-request / echo-reply.
You’ll also need to go into your Tailscale ACL controls and allow access there from your local subnets.
Any device that you wish to reach via this connection needs to have the --accept-routes option enabled when you run tailscale up. The device you’re trying to access needs to have a route to get back to your LAN subnet, after all.

--accept-routes is enabled by default on MacOS and Windows, but disabled by default on Linux. Once enabled, the device should be reachable from any device on your LAN.

You may also want to configure MSS clamping to avoid unnecessary IP fragmentation. Under Firewall > Settings > Normalization, click the + to add a new rule:

Interface: Select your assigned Tailscale interface.
Direction: Any
Max MSS: 1240 (for standard Tailscale 1280 MTU) or 1380 (if your Tailnet uses 1420 MTU).
Description: Clamp MSS for Tailscale traffic.

I highly recommend thinking carefully about your firewall rules and Tailscale ACLs, and what you allow to connect to what.

Now that I’ve gotten this working I’ll be spending some time narrowing my LAN to Tailnet access ACL down to specific tags. But that’s a whole other post.

Exit Node

If, like me, you are also using your home OPNSense gateway as a Tailscale Exit Node, you’ll quickly realize that this process broke it.

The fix is simple, we need to add an Outbound NAT rule to replace the missing SNAT on the Tailscale service.

Go to Firewall > NAT > Outbound.

Your Outbound NAT mode must be set to “Hybrid” or “Manual”. If you don’t know what this means, set it to “Hybrid”.

Configure a rule that looks like this:

Interface: WAN
Source address: 100.64.0.0/10
Destination address: any
Translation target: Interface address

Fluxer Over Tailscale

Sat, 20 Jun 2026 21:36:21 -0400

This weekend I’ve been playing with setting up a self-hosted Fluxer instance.

In my traditional fashion, I made things much harder by myself by refusing to use their provided Caddy setup, and instead using Traefik.

And for an additional challenge - I wanted this to be completely inaccessible from the public Internet, instead using my Tailscale mesh network.

The setup required some heavy modifications to the Docker Compose file provided by Fluxer’s team, and a few tweaks to livekit.yaml.

Note

The Docker Compose file for this service is extremely long, so instead of posting it inline here as I normally do, I have created this Gist containing both the modified Compose project and livekit.yaml.

With this setup, I’m able to access Fluxer at fluxer.mytailnet.ts.net with full TLS encryption and valid certificates.

I am using:

A Tailscale sidecar container
The Tailscale Traefik provider for TLS certificates

Effectively, what you need to do is tell Traefik and the Livekit service to share the Tailscale container’s network namespace.

Then we tell Livekit to advertise the Tailscale container’s IP address instead of the one for the Docker bridge (see livekit.yaml, it’s the node_ip setting).

Note - you’ll need to add the TS_SOCKET: /var/run/tailscale/tailscaled.sock environment variable to the Tailscale container, and pass the Tailscale socket through to the Traefik container - it needs access to the Tailscale daemon to be able to grab your certificates.

You’ll also need to have enabled HTTPS on your Tailnet.

What works

Text chat
Voice chat

What doesn’t work (yet)

Video chat - I think this has something to do with Livekit video codecs. I need to play a bit more with this and do some more testing.

Wireguard configuration concepts

Sun, 26 Oct 2025 15:04:55 -0400

Wireguard concepts

The point of this post

This is intended as a high level starting point for someone who is new to using Wireguard.

If you spot any errors or inaccuracies, feel free to open a pull request in the Github repo, or leave a comment.

Overview

Wireguard is a modern VPN protocol.

Instead of using a traditional client server model, Wireguard uses a peer-to-peer mechanism. Authentication is handled with private and public key pairs, and optionally a pre-shared key.

Wireguard configuration on Linux

There are many ways to configure Wireguard on Linux, but the one that I typically use is by setting up a file in /etc/wireguard.

On Linux, this is the default location that the wg-quick userspace utility looks for Wireguard interface configurations.

The interface configuration can contain both the definition for the interface as well as any peers.

Anatomy of the Wireguard configuration file

Consider the following configuration file: /etc/wireguard/demo.conf.

When using wg-quick, the interface name will be generated from the name of the configuration file. In this case, the interface name would be demo.

Sample configuration file:

[Interface]

Address = 192.168.99.5/24
PrivateKey = 2COm4EMxP5tcF9cpgCxBAsSGRwrjoMmWjkr+emGtylY=
ListenPort = 51820

[Peer]

PublicKey = Tlm3payEVQWCj7GK7Y7usejF4mix5FBULZryxfu9kxY=
PreSharedKey = chooseabetterkey
AllowedIPs = 192.168.99.8/32,10.10.33.0/24
Endpoint = demo.wireguard.com:51820

Lets break down this config file into its components.

Wireguard uses an INI-like syntax.

There are 2 top level blocks that can be configured, [Interface] and [Peer]. There can be multiple [Peer] definitions, but only one [Interface].

The Interface Block

Address: What address do you want this particular peer to have? Make sure you set the correct CIDR notation for your subnet size. This one is /24 for a 254 address subnet.
PrivateKey: The private key is a secret! I’ve generated this one just for this demo, it will be discarded after.; But make sure you secure these properly!
ListenPort: The default listen port is 51820, but you can set it to anything you want. This is the network port that Wireguard will use to listen on this interface.

The Peer Block

PublicKey: This is the public key associated with the peer’s private key, not the private key of this interface.
PreSharedKey: Preshared keys are optional but good for additional security. This is a key that needs to match on both sides of the connection.
AllowedIPs: The AllowedIPs stanza is an interesting one. It is what Wireguard uses to make internal routing decisions, but those packets need to arrive at the Wireguard interface first.; This is the reason I like to use wg-quick to set up my interfaces - if you don’t, you’ll need to add the routes yourself. This is personal preference.; The configuration above would allow this peer to have the 192.168.99.8 IP on the Wireguard internal subnet, and any traffic destined for 10.10.33.0/24 would also get passed along.; Note how I’m using /32 for the Wireguard internal subnet here. This is because I only want that one IP to be valid for this peer. The subnet is still a /24 as configured on the interface itself.
Endpoint: Endpoint is technically an optional field.; But it does need to be set on at least one side of each connection.; At least one of the peers needs to have a public IP address that’s reachable on the internet. (And the ListenPort needs to be open.)

There are other stanzas that can be used in the configuration file, but these are the basic ones.

You can see the wg and wg-quick man pages for more information on configuration file syntax.

Using wg-quick with systemd

When installing Wireguard on Linux, it comes with a template systemd unit file for wg-quick.

This is a wrapper that allows you to quickly set Wireguard configurations that load at startup.

To start up our config file from earlier using wg-quick, you can do it like so:

sudo systemctl start wg-quick@demo

Where the text after the @ symbol will always been the config file name without its .conf extension. For more info on this, see the Arch Wiki page on systemd.

If you want to make the configuration start at boot, you can enable the systemd unit.

sudo systemctl enable wg-quick@demo

Note

Yes, you can have multiple Wireguard interfaces on one machine. Just make sure that they listen on different ports.

General usage notes

While Wireguard as a protocol is peer-to-peer, many people do still use it in a client-server architecture.

One use case for this is if you’re using Wireguard to set up your own privacy VPN endpoint.

Note

If you do use Wireguard as a VPN server, remember that you also need to enable IP forwarding.

PSA: Unifi IPSec site-to-site tunnels and DHCP

Tue, 01 Apr 2025 13:09:28 -0400

Bit of a PSA of sorts, as this is the second time that I have run into this particular issue.

Scenario: You had a Unifi gateway such as a UDM Pro with a static IP address. You switched your WAN IP from static to dynamic, for whatever reason. (In my case it was a different ISP that doesn’t hand out actual static IPs, only DHCP reservations.)

You may find that the router holds onto that old IP, and if you’re like me, you’ll be confused as hell.

The cause is your IPSec site-to-site tunnel.

You’ll need to make note of any settings it had (Pre-shared keys, remote endpoints, remote subnets, etc), delete the tunnel completely, and then once you’ve successfully gotten your new IP from DHCP, recreate the tunnel from scratch.

Once you remove the tunnel, you should get an IP from DHCP almost immediately.

Adventures in DNS (But it's actually DHCP this time.)

Mon, 02 Dec 2024 23:57:12 -0500

So, story time.

Boss has a friend who does IT for an electrical contractor 30 mins or so away from our primary office, and he brings us in because he’s having DNS issues he can’t figure out

Get onsite there and go over his setup – typical mess of a network closet with no brand consistency and mismatched patch cables, whatever. Otherwise looks good from a network perspective.

However, he mentions that he has no access to the firewall since it’s owned by the ISP.

Personally, I would have been on top of the ISP until they either gave me the ability to log into that thing, or had them put it in bridge mode and installed my own firewall. I do not like and do not trust any firewall that I do not control. Sorry, it’s just the paranoid sysadmin in me.

So we finally start looking at the problem and the issue is that he keeps having to hardcode his DNS settings and he’s having weird WiFi connectivity issues. Everything points to DHCP not setting the DNS settings consistently… which made me suspect a rogue DHCP server.

So I connect my laptop and run an ifconfig – and I see that DHCP is coming from some IP address 10.0.0.69. Knowing at this point he didn’t have access to the firewall, I asked him if that was one of his servers, he says no. I asked him where he WAS running DHCP, and was told it was on one of the domain controllers, but he didn’t remember which one. Red flag #1.

I do an nmap scan to see if I can grab the vendor of the device that has that IP – it reports back that it’s from Axis Communications. Not being familiar with it, I asked about that vendor, and was told that that was the brand of their security cameras and NVR.

I go okay, so there’s your problem right there. You have 2 DHCP servers, and it’s a question of which one responds first to the DHCPDISCOVER broadcast.

So we go look at the cameras – no passwords for ANYTHING. we lucked into finding the password for the computer controlling them written on a piece of paper near the rack it was installed in.

Eventually I figured out that one of the cameras had DHCP running, and we turned it off, but then we tried getting a new DHCP lease – it got one, but in the wrong subnet entirely.

This of course, understandably confuses me. I noticed that the DHCP server is now 192.168.0.1, which isn’t even the right subnet. What the deuce?

Ran another network scan, that IP has the same vendor as before, but a different MAC address now, so it’s a totally different device.

Turns out, the appliance they have running their cameras? it’s 2 devices in one – a windows PC acting as the controller, and the built in switch which has its own DHCP server (and presumably it’s own operating system and mainboard).

Of course, no password for that either, so I Googled and found it’s on a sticker on the bottom of the unit. I found the password, logged in and turned off DHCP. That’s it, right? We’ve fixed it?

Tried to get a lease once more… nothing happens at all.

Turns out… he was NOT running DHCP on the domain controller. Or anywhere except for this NVR, that had it turned on by default.

I installed the DHCP role on one of the domain controllers and configured it with the proper settings, and a reasonable scope, along with primary and secondary DNS for their domain. Did another ipconfig /renew on one of their machines and… success! We got an IP in the correct subnet, and it is assigning the correct DNS servers to the client machines. WiFi works perfectly as well!

How the network got into this state and stayed operational for as long as it did? Who can say? Miracles happen every day, right?

Like they say, it’s always DNS. But sometimes it’s not DNS, sometimes it’s badly misconfigured DHCP.