Tailscale on Sysadmin Tales

Set up auto-renewing HTTPS certificates on a GLiNet KVM

Fri, 02 Oct 2026 20:21:30 -0400

I’m quite fond of the small little IP KVMs that have become more and more available lately.

My favorites are the JetKVM and the GliNet Comet series.

I have 2 of the Comets that I use internally, and I mostly access them via their Tailscale ts.net names.

I could do I what I usually do and put them behind a reverse proxy, but there’s one of these that I keep in my work bag and take with me onto client sites, so there’s no reverse proxy in that scenario.

I could just ignore the certificate error, but where’s the fun in that when we can fix it?

Activate and log into Tailscale on your device.
Ensure that HTTPS is enabled for your TailNet. This can be done here.
SSH into the GliNet KVM.
Update Tailscale, you heathen.
```
tailscale update
```

Once Tailscale is updated, lets create the renewal script.

vi /etc/tailscale-cert-renew.sh

And the contents of the script:

#!/bin/sh

set -eu

HOSTNAME="your-kvm.your-tailnet.ts.net"
CERT_DIR="/etc/kvmd/user/ssl"
TMP_DIR="/tmp/tailscale-cert"
RENEWAL_WINDOW=1209600 # 14 days

# Exit if the existing certificate is valid for more than 14 days.
if openssl x509 \
    -checkend "$RENEWAL_WINDOW" \
    -noout \
    -in "$CERT_DIR/server.crt" >/dev/null 2>&1; then
    exit 0
fi

echo "Certificate expires within 14 days. Renewing..."

rm -rf "$TMP_DIR"
mkdir -p "$TMP_DIR"

CERT="$TMP_DIR/server.crt"
KEY="$TMP_DIR/server.key"

tailscale cert \
    --cert-file="$CERT" \
    --key-file="$KEY" \
    "$HOSTNAME"

# Make sure we actually received a valid certificate.
openssl x509 \
    -in "$CERT" \
    -noout \
    -subject \
    -issuer \
    -dates

# Replace the existing certificate and key.
cp "$CERT" "$CERT_DIR/server.crt"
cp "$KEY" "$CERT_DIR/server.key"

rm -rf "$TMP_DIR"

# Restart the KVM's nginx instance.
/etc/init.d/S99kvmd-nginx restart

echo "Tailscale certificate renewed and nginx restarted."

Make the script executable.
```
chmod 700 /etc/tailscale-cert-renew.sh
```
Run the script once to test it.
```
/etc/tailscale-cert-renew.sh
```
You should be able to reload the GLiNet web interface and see that you have a valid LetsEncrypt certificate for your Tailscale MagicDNS name.

Aside
Make sure you’re accessing the device at your-kvm.yourtailnet.ts.net and not it’s IP address, or the certificate won’t validate.
Now, lets create a cron job to run the script automatically. The GliNet KVMs already run a cron daemon (at least the ones that I’ve used do) - so you should be able to directly edit the crontab.
```
crontab -e
```
To run the script once a day at 0300:
```
0 3 * * * /etc/tailscale-cert-renew.sh
```

You should now have a GliNet KVM that automatically renews your Tailscale certificates when needed. :)

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.