Secure portal between Internet and internal services
I thought I was going to use Authentik for this purpose but it just seems to redirect to an otherwise Internet accessible page. I'm looking for a way to remotely access my home network at a site like remote.mywebsite.com. I have Nginx proxy forwarding with SSL working appropriately, so I need an internal service that receives the traffic, logs me in, and passes me to services I don't want to expose to the Internet.
My issue with Authentik is if I need to access questionable internal websites I have to make an Internet accessible subdomain. I don't want authentik.mywebsite.com to redirect to totallyillegal.mywebsite.com. I want it to redirect to 10.1.1.30:8787.
Then point that record to 127.0.0.0. This will not resolve for anyone. But you'll have an internal dns enty (useig pihole/adguard/unbound) that redirects to your reverse proxy.
You could also point to your revers proxy internal address instead of 127.0.0.0.
I use traefik as reverse proxy. I have externally accessible domains for and then extra secure internal only domains that require wireguard connection first as an extra layer of security.
Authentik can be used as a forward auth proxy and doesn't care if it's an internal or external domain.
Apps that don't have good login or user management just get Authentik proxy for single sign on (sonarr, radar etc).
Apps that have oAuth integration get that for single sign on (seafile, immich, etc)
To make it work the video will talk about adding both the internal and external domains to the local DNS so that if you access it from outside it works and if you access from wireguard or inside the lan it also works.
You can try setting up a VPN, eg headscale/tailscale with your home server being an exit node, and then just set up your questionable services on a domain that only resolves locally - and then you don't need to use authentik for authorisation to those services.
This is what I have been trying recently, and seems to work well.
I just set up a Vouch-Proxy for this yesterday. It uses the nginx auth_request directive to authenticate users with an SSO server, and then stores the token in a domain-wide cookie, so you're logged in across all subdomains. Works pretty well so far, you don't even notice it when you're logged in to your SSO provider.
But you do have to tell the proxy where you want to redirect a request somehow, either by subdomain (illegal.yourdomain.com) or port (yourdomain.com:8787) or path (yourdomain.com/illegal). I'm not sure if it works with raw IPs as hosts, but you can add additional restrictions like only allowing local client IPs.
In my special case I'm using the local Synology SSO server, and I have to spin up an additional nginx server because the built-in one doesn't support auth_request.
it just seems to redirect to an otherwise Internet accessible page.
I'm using authelia with caddy but I'm guessing it could be similar, you need to configure the reverse proxy to expect the token the authentication service adds to each request and redirect to sign in if not. This way all requests to the site are protected (of course you'll need to be aware of APIs or similar non-ui requests)
I have to make an Internet accessible subdomain.
That's true, but you don't have to expose the actual services you're running. An easy solution would be to name it other thing, specially if the people using it trust you.
Another would be to create a wildcard certificate, this way only you and those you share your site with will know the actual sub domain being used.
My advice is from my personal setup, but still all internal being able to remotely access it via tailscale, so do you really need to make your site public to the internet?
Only if you need to share it with multiple people is worth having it public, for just you or a few people is not worth the hassle.