Klox

Get a router/travel router and set it up as a gateway where it provides its own SSID for the Roku to connect to. Basically a bridge to the complex, where you can inject some software. A lot of the travel devices have baked in Wireguard+Tailnet support. iNet are generally good products.

to get something that is idiot proof.

The problem with Jellyfin in particular is that it needs to support binary streaming protocols. You can implement some gateway/firewall-based security in front of Jellyfin, but in the end it is still Jellyfin’s internal mechanisms mostly responsible for its own security. I don’t use Authentik but I have read many good things. The only real “advantage” of it is that it forces your users to somewhat better credential handling. Jellyfin still only supports LDAP, so the users will have to enter their Authentik username and password – very similar to just local accounts managed by Jellyfin. So IMO, not offering you that much extra in terms of security. You will be better served by firewall tools like fail2ban, crowdsec, geo-fencing, etc.

Depending on where/how your users access Jellyfin you could have something a bit tighter. If they never run it on a TV you could do something more advanced like mTLS where you issue them a certificate with a TTL of several years, walk them through installing it on their phones/laptops, and then have that in a reverse proxy. But at that point you might as well walk them through setting up a VPN mesh network.

For Seerr, it’s just a standard web app .You could put a reverse proxy in front that requires OIDC with Authentik. Seerr is also pretty close to having native OIDC integration. Personally I prefer having two rounds of OIDC – reverse proxy really narrows what the public can see as a first layer.

For BookOrbit, I am not familiar enough with the Kobos. My guess is, you could put BookOrbit behind a reverse proxy that enforces OIDC, but you might have to allow a bypass for /api route. Then you’re relying on BookOrbit to authenticate all /api requests through API tokens. This would look like the normal Kobo linking process, so no real difference, but then your BookOrbit web UI is locked behind OIDC authentication.

Two NIC. I’m usually using the SFF. I went 10G last year and it’s been so great. Single, used, low profile, dual port SFP+ module. One port has SFP+ to RJ45 to my modem. Other port is SFP+ passive DAC to a used Brocade ICX 2750.

I was Unifi gear and then went back to Opnsense :P. That shit is way too expensive to replace.

OPNsense on used dell optiplex. Very easy but it can do whatever you want to grow into as you learn more.

OIDC and zero signups for everything. I’ve been very happy with Pomerium (ZTNA) + Keycloak for all my public facing apps, although the free version doesn’t have any client signals which I was hoping for when I starteed.

My project this week is integrating the app logging I have into Crowdsec and start having Crowdsec do more analysis.

Your really need to define your scope first. Is it just you? Family? Extended family? Strangers?

After understanding that, the best bang for your buck is a private mesh/tunnel VPN. Tailscale, Netbird, Pangolin, or plain wireguard. If you want real public routing, then you need to understand reverse tunnels and your app’s lifecycle/quality. After that, all the security guidelines are basically trying to reduce blast radius. And that depends a lot on how you’re running the app, what it has access to, etc. DMZ network for isolation goes a long way.

Does that bypass my DNS server when the client is connected to the tailnet?

Yes. A search path is installed so that the OS queries MagicDNS. MagicDNS is a DNS resolver within Headscale and nodes that are on the tailnet will use it to get the tailnet IP of the names being queried under your MagicDNS domain. You MagicDNS path can be a subdomain of your domain (hs or ts.mydomain.com) or anything (.magic). https://photos/ -> check with MagicDNS does it have photos.magic? Return the photos node IP 100.x.x.x.).

It doesn’t need to go to your AdGuard DNS server because every node will query the search path that is added to the OS when joining the tailnet. It’s the reason why your MagicDNS domain name needs to be unique, and why it doesn’t technically need to be a subdomain of your internet routed domain.

Should I still leave it on for local traffic?

Depends on what you want. Is your local traffic expected to go over the tailnet? If every device isn’t on the tailnet then you probably still want the local network setup you have.

And if I’m connected to the tailnet from outside, how do I propagate all the addresses?

Every tailnet node has a node name. You can spin up extra nodes so that they resolve a node name to the service it’s managing. You can do this pretty easily with containers. The alternative is to configure MagicDNS with extra_records so that multiple A records resolve to the same tailnet IP. Then you either need the services to be on different ports or have a reverse proxy split out based on the connection header (e.g. to route photos to Immich and music to Navidrome).

This is ignoring all “exit node” scenarios. Exit nodes can help bridge your local traffic to the tailnet, or bridge your services to the public.