Hello, I'm a beginner when it comes to servers.
I'm trying to figure things out as best as I can.

I've just created my own NAS from an old PC.
I have Vaultwarden installed on Unraid along with Tailscale for remote access.
I managed to install an SSL certificate, but it only works on the Unraid interface. As soon as I specify a port, the certificate doesn't work.
When I try to use my Tailscale link in Bitwarden, it doesn't work because the SSL isn't set up.
Could you please help me?

Do I need a reverse proxy? How do I generate an SSL certificate? Should I use Cloudflare for the certificate?
And if I use Cloudflare, will they hassle me if I put the certificate on a service like Plex?

I also bought a domain name to access my web services without having to type the IP address. Can I redirect the IP address provided by Tailscale? For example: 100.10.25.1:8080 -> webservice.domain.com

 

Btw, I can't port forward on my router.

I am using the Tailscale plugin and Vaultwarden docker. The settings below work for my Unraid remote access needs, adjust as necessary. The Tailscale Youtube channel has good explanations of what you can do in general with Tailscale.

 

On the Tailscale Settings page in Unraid:

 

Unraid Services Listen on Tailscale IP – Yes

Enable IP Forwarding – Yes

Use Tailscale Subnets – Yes

Use Tailscale DNS Settings – No

 

In the WebUI for Unraid open the terminal (it’s on the top right of any Unraid page) and turn on Tailscale “Serve” for the Vaultwarden docker http port, this gives you https (I don’t know the stock port so replace with your setup

 

tailscale serve --bg --https=4280 localhost:4280

 

It’ll show the full address for your Tailscale net there with the port – use that address & port in whatever app your using.

 

Now I have issue with this setup, I believe it’s likely with Vaultwarden Docker network settings that come stock with that docker template - So Tailscale automatically starts with the server fine but having serve setup on that port prevents the Vaultwarden docker from automatically starting – Port in Use. It’s quick to remidey but really annoying. All the other dockers I have serve setup for autostart fine.

 

The quick way I’m fixing this is after reboot in Unraid WebUI is goto Tailscale setting turn it off, jump over to the docker page start Vaultwarden then reenable Tailscale. It takes 3 seconds. When doing this on your home network, disable the Tailscale app on the computer first or it will likely prevent you from accessing the Unraid UI till you do – Since you just turned off Tailscale. It was fun figuring this out remotely but I have Tailscale on my router too, so once I turned the Tailscale app off then on it routed through the router & got back to Unraid by subnet sharing...

 

fyi in the Unraid terminal you can do ‘tailscale serve status’ to see what ports you have setup for https access. You can turn off Serve by ‘tailscale serve --https=4280 localhost:4280 off’ You pass http ports to the serve command.

 

No need for cloudflare, open ports, reverse proxy - just run the tailscale app on your phone or laptop then you can access Vaultwarden. It'll only be available on your Taillscale net. 

Edited July 27, 20241 yr by AKHuff

A suggestion that will help with the port conflict: use a different port for the Vaultwarden "WebUI HTTP Port" (in the Vaultwarden container settings) and the Tailscale serve command.

 

For example, if you have the Vaultwarden HTTP port set to 4743 (the default), you can serve Vaultwarden via HTTPS using this command:

 

tailscale serve --bg --https=4280 localhost:4743

 

Awesome, Thanks EDACerton. That was the only issue I was having with this Unraid box.

On 7/27/2024 at 1:40 PM, EDACerton said:

A suggestion that will help with the port conflict: use a different port for the Vaultwarden "WebUI HTTP Port" (in the Vaultwarden container settings) and the Tailscale serve command.

 

For example, if you have the Vaultwarden HTTP port set to 4743 (the default), you can serve Vaultwarden via HTTPS using this command:

 

tailscale serve --bg --https=4280 localhost:4743

 

 

EDACerton and AHKuff,

Just wanted to thank you both for giving me a really sleek method to remove my vaultwarden container from being exposed to the outside Internet. Although 'mostly' secured... its always better to be never 'exposed' on the Net. 

 

Running vaultwarden plus SSL via Tailscale Serve was a really good idea. 

 

Quick question for anyone who may know..... 

 

Does EDACerton's CLI input as noted above survive a server reboot/shutdown? If not, does anyone have any ideas as to how to inject that CLI prompt into a server/docker start up? So we don't need to do it manually every reboot/restart?

 

Thanks Lads

 

1 minute ago, onyxunraid said:

 

EDACerton and AHKuff,

Just wanted to thank you both for giving me a really sleek method to remove my vaultwarden container from being exposed to the outside Internet. Although 'mostly' secured... its always better to be never 'exposed' on the Net. 

 

Running vaultwarden plus SSL via Tailscale Serve was a really good idea. 

 

Quick question for anyone who may know..... 

 

Does EDACerton's CLI input as noted above survive a server reboot/shutdown? If not, does anyone have any ideas as to how to inject that CLI prompt into a server/docker start up? So we don't need to do it manually every reboot/restart?

 

Thanks Lads

 

That change is persisted in the Tailscale state. 

I have been experimenting with this. I got it working, but am I right in concluding that in order for the Bitwarden browser plugin on my pc to be able to connect to the Vault on my Unraid server, the pc has to always be connected to the tailnet? That is the only way I was able to connect the browser plugin to the vault on my server.

 

If so, that's not ideal as I don't want all the traffic on my pc to go through Tailscale all the time.

2 hours ago, lococola said:

If so, that's not ideal as I don't want all the traffic on my pc to go through Tailscale all the time.

if you’re not using an exit node, only the data that your PC is requesting from vaultwarden goes through Tailscale.

Using a reverse proxy (always HTTPS), no need for special serve settings for Tailscale and no issues whether any PC/device (on the LAN) is, or is not, connected to the Tailnet when using Bitwarden client/plugin. When away from the LAN, must use the tailnet, as expected. Easy setup, easy to manage, always works. Reverse proxy is highly recommended to allow reaching Vaultwarden and other services by HTTPS using FQDN.

 

 

Edited December 12, 20241 yr by Espressomatic

I already have it set up using reverse proxy, but I am looking for a 100% offline way to access Vaultwarden inside my own lan. So without having to go through the internet at all. With a reverse proxy there is still the need for an online ocnnection because of the SSL requirement. I was hoping Tailscale could be the offline solution, but I now realize that of course it can't be, because you still have to connect to the tailnet.

 

I guess it's simply impossible to use Vaultwarden 100% locally.

16 hours ago, MowMdown said:

if you’re not using an exit node, only the data that your PC is requesting from vaultwarden goes through Tailscale.

This is very interesting, I didn't realize it works that way. Still requires an active internet connection though.

1 minute ago, lococola said:

This is very interesting, I didn't realize it works that way. Still requires an active internet connection though.

Inside your own LAN won't require an internet connection. Only when outside your LAN.

11 minutes ago, MowMdown said:

Inside your own LAN won't require an internet connection. Only when outside your LAN.

That's not what I've read. Unless you mean once devices have been connected on a tailnet (using an active internet connection) they can then still find eachother if the internet connection goes down after this? That is something that I will need to test.

Say your Local unraid IP is 10.0.0.2, tailscale will forward any requests for Vaultwarden to 10.0.0.2, since 10.0.0.2 is a local IP it will not traverse the WAN to contact 10.0.0.2. That would be a waste of resources.

 

When you are not on you LAN, it will send 10.0.0.2 over the tailnet.

 

It's called "Split-Tunneling"

And for whatever reason if it doesn't work, you can just have tailscale disable itself when you're on your LAN. It supports "On Demand" mode

1 minute ago, MowMdown said:

Say your Local unraid IP is 10.0.0.2, tailscale will forward any requests for Vaultwarden to 10.0.0.2, since 10.0.0.2 is a local IP it will not traverse the WAN to contact 10.0.0.2. That would be a waste of resources.

 

When you are not on you LAN, it will send 10.0.0.2 over the tailnet.

 

It's called "Split-Tunneling"

And for whatever reason if it doesn't work, you can just have tailscale disable itself when you're on your LAN. It supports "On Demand" mode

This is not entirely accurate.

 

When a subnet route is advertised over Tailscale, all traffic to that network is sent via the tailnet, even when you are on the same network. This is by design for Tailscale -- there are cases where you might connect to a network that uses the same private IP space as home (e.g., public wifi), and you don't want to lose access to your devices / connect to a device on the local network that you didn't want to.

 

The traffic doesn't (shouldn't) go over the internet when you're on the same network, though. In that case, data will still flow through Tailscale, but the two devices should be able to negotiate a direct connection to transfer data (unless you have something on your network/router/firewall preventing them from talking to each other). The traffic between the devices should not traverse the WAN.

 

All of the devices do need access to the control server, though -- so if your WAN is down, Tailscale won't work at all, and local access will operate as if Tailscale wasn't there.

 

26 minutes ago, lococola said:

That's not what I've read. Unless you mean once devices have been connected on a tailnet (using an active internet connection) they can then still find eachother if the internet connection goes down after this? That is something that I will need to test.

Tailscale behavior after losing internet access can be unpredictable. The client regularly communicates with the control plane. The best I can offer is that, depending on when the devices last talked to each other / control servers / etc., you *might* be able to make a connection, or you might not, or it might connect and then disconnect a short time later -- but I would expect failure after losing internet.

 

In the case of subnet routes, it's kind of moot anyways, since if Tailscale disconnects you'd just be able to connect locally.

Thanks for the detailed explanation. I've learned more about Tailscale which is always useful. Too bad it's not the perfect solution for my Vaultwarden woes, but I am using Tailscale on Unraid for other applications and it's fantastic!

2 hours ago, lococola said:

I am looking for a 100% offline way to access Vaultwarden inside my own lan. So without having to go through the internet

 

Which is exactly what you will accomplish going the route I mentioned. TLS/HTTPS/RevProxy doesn't need internet. Vaultwarden doesn't need internet. LAN connections don't need Tailscale whatsoever. So I'm not sure what the issue is.

 

42 minutes ago, lococola said:

Too bad it's not the perfect solution for my Vaultwarden woes

 

It's the perfect solution for accessing Vaultwarden from anywhere outside your LAN. From inside your LAN, nothing besides Vaultwarden is needed (rev proxy if you want SSL and FQDN).

 

  

2 hours ago, EDACerton said:

When a subnet route is advertised over Tailscale, all traffic to that network is sent via the tailnet

 

Only when a node is specifically set to use the advertised route - which isn't automatic nor default. So, IMO moot for most installations. There's a good reason to use this, like when you have a node running on a virtual server off-premises, but generally no good reason to run it internally within the LAN.

 

In addition, nothing in the setup of the firewall or router (as far as routing tasks go) should have any impact as the packets won't even hit the router, and go between only client and VW IPs.

 

I'm making some assumptions here based on what else has been mentioned. One not mentioned is that there's a local private resolver/forwarder on the LAN so any query on a local FQDN never needs to go to an outside authoritative server. Example: PiHole, AdGuard Home (A record mappings), Unbound, DNSMasq, etc.

 

 

Edited December 12, 20241 yr by Espressomatic

44 minutes ago, Espressomatic said:

Which is exactly what you will accomplish going the route I mentioned. TLS/HTTPS/RevProxy doesn't need internet. Vaultwarden doesn't need internet. LAN connections don't need Tailscale whatsoever. So I'm not sure what the issue is.

 

It's the perfect solution for accessing Vaultwarden from anywhere outside your LAN. From inside your LAN, nothing besides Vaultwarden is needed (rev proxy if you want SSL and FQDN).

 

The issue is that I cannot connect to my vault without the connection going over HTTPS. Because if I access the vault simply by its local IP and port, it won't allow me to login for lack of SSL. Hence the whole domain/reverse proxy setup. Which means there has to be an internet connection for the SSL validation.

 

At least, every tutorial/forum thread/youtube video I have seen on the subject says to set it up this way. I would love to hear how I can manage all this without having any internet connection at all.

 

2 hours ago, lococola said:

Which means there has to be an internet connection for the SSL validation

 

But there doesn't.

 

2 hours ago, lococola said:

least, every tutorial/forum thread/youtube video I have seen on the subject says to set it up this way

 

Then either of two things:

 

1. You've misunderstood what they said

2. They're completely wrong

 

If you can forward a link to any guide you've followed that says this, I'm curious to check.

Anyway, your browser/OS already had a store of trusted CAs. If you're certs are issued by, for example, Let's Encrypt, you don't need an internet connection when you hit that cert at any point in the future after setting it up. Obviously you'll need an internet connection to initially procure and later renew the certificate every 60 days.

 

Imagine my entire LAN being down just because my ISP had a hiccup.  No, no thanks. 🤣 I use HTTPS and a FQDN for absolutely every single service I put through my browser hosted on my LAN.

 

 

Edited December 12, 20241 yr by Espressomatic

3 hours ago, lococola said:

 

Which means there has to be an internet connection for the SSL validation.

In concept, this is true. In practice, though, it’s not a big deal. 
 

It is accurate that you need an internet connection to do an online CRL/OCSP check. However, some browsers don’t even do online checks by default (e.g., Chrome uses CRLSets instead of online checks), and browsers that do use online checks use a “soft-fail” mechanism (if the OCSP/CRL server can’t be reached, the certificate is assumed to be OK).

 

While it is possible to force browsers into a hard-fail configuration, that’s not the default in anything that I’m aware of. So, even without internet, your browser will handle something like a LE certificate just fine. 

14 hours ago, Espressomatic said:

But there doesn't.

...

Obviously you'll need an internet connection to initially procure and later renew the certificate every 60 days.

So, you do need an internet connection, and not even for only the initial connection, but every time the cert needs to be renewed. This is what I meant when I said internet is required for SSL certification. Your point was of course that it's not required to be online 100% of the time, but that is not the same as not needing an internet connection at all.

As you say here:

Quote

From inside your LAN, nothing besides Vaultwarden is needed (rev proxy if you want SSL and FQDN).

And as far as I know you cannot use Vaultwarden without SSL. Which means you always need some solution for that, like a reverse proxy.

 

In any case, the original point of my post was the question whether Tailscale could be an (fully and completely) offline alternative to the reverse proxy way. I would say no. Because the devices need to be connected to the tailnet all the time. But on the flip-side Tailscale is definitely a lot easier to set up than the custom domain/reverse proxy/wildcard ssl over dns route that I am using now.

 

Thanks for the help everyone!

1 hour ago, lococola said:

So, you do need an internet connection, and not even for only the initial connection, but every time the cert needs to be renewed. This is what I meant when I said internet is required for SSL certification. Your point was of course that it's not required to be online 100% of the time, but that is not the same as not needing an internet connection at all.

If "no internet connection ever" is what you want, you would need to set up and trust a private CA.

Just now, EDACerton said:

If "no internet connection ever" is what you want, you would need to set up and trust a private CA.

 

That can't work to solve the problem unless he also intends to write all his own software from scratch, without so much as referencing existing code. And certainly posting here about it will be equally impossible. Unless he also hosts an offline forum and we all show up at his house to post in-person on his LAN.

 

 

 

  

1 hour ago, lococola said:

In any case, the original point of my post was the question whether Tailscale could be an (fully and completely) offline alternative to the reverse proxy way. I would say no. Because the devices need to be connected to the tailnet all the time. But on the flip-side Tailscale is definitely a lot easier to set up than the custom domain/reverse proxy/wildcard ssl over dns route that I am using now.

 

I hope this reply is read as it's intended - somewhat hyperbolic and mildly entertaining, but still trying to make a reasonable point.

 

I'm confident now that you've misunderstood the purpose of both a reverse proxy and Tailscale. One in no way replaces the other for any purpose/outcome.

Let me make the blanket statement again:

Vaultwarden does not need an internet connection at all, nor at any time after it's set up. Literally never. With or without SSL.

I don't mean to be pedantic, but this "offline" meme is getting frustrating to the point of exhaustion (not just here). You need an internet connection to do things like download. How will you download Vaultwarden or anything else without an internet connection? You need an internet connection to participate in a global forum like this one - how can you do this offline? So, let's agree that at some point, everyone needs an internet connection to do at least SOME things.

 

So, internet required to download and set up Unraid. Download Vaultwarden. Download certificates. See, the cert is just like anything else you don't have or make yourself - it needs to be downloaded. But you can do that on any machine, from literally anywhere. You can download certs on your phone. On a Commodore 64 running a WiFi modem adapted to its cartridge or serial port. You get the picture. What doesn't need to ever have an internet connection, is the machine running Vaultwarden. You copy the cert to that machine on your LAN or you serve it and then proxy VW with a reverse proxy.

 

You absolutely do NOT use Tailscale at all for any reason to accomplish any of this. It's of no use whatsoever for LAN-only.

 

The entire point of Tailscale is to be a secure tunnel between the LAN and one or more devices outside the LAN (somewhere beyond the WAN) - aka the "internet." So "offline" doesn't factor into the Tailscale discussion and Tailscale doesn't factor into the offline discussion. If you 100% want INTERNET, then Tailscale is for you and this is the thread. If you 100% don't want INTERNET, then Tailscale is not for you (at all) and this is not the thread.

 

It sounds to me like you need to stay away from Tailscale like a communicable disease. Recognize it exists, don't worry about its inner workings, just know you don't want it.

 

Now if you intend to run any services whatsoever on your LAN you absolutely want domain resolution and for some services you may want secure certificates. You can do this a bunch of ways, but the absolute easiest is to kill multiple birds with one stone and use a reverse proxy to map domain names to IP+PORTS while ALSO obtaining and serving certificates. Obtaining valid public certificates requires downloading them from the internet. If you don't want to use the internet for this, on any machine, then you can use self-signed certificates which will work for some, but not all services, or you can also run, as EDACerton mentioned, your own certificate authority - which you then also have to manually trust in every browser that will access a certificate it verifies. IMO, good luck with this, because the info available for it is far less readily available and you'll need an internet connection to find/access it anyway. Serving a self-signed cert with NPM is otherwise super simple - just select it from the menu.

 

So let's say that this all gets set up and is now working 100% "OFFLINE" - What's the point?

 

How is an offline instance of Vaultwarden going to help you? What passwords and login credentials is it going to store that you will only use OFFLINE on your LAN? OK, maybe you have a lot of secure services that you use locally and need to keep locked down with different an elaborate passwords - fair enough.

 

But maybe you intend to use Bitwarden clients ON-LINE while Vaultwarden itself is completely cut off from the inernet? Sure, that can work, but only while you're at home. Once you're outside the LAN, Bitwarden clients will no longer be able to access Vaultwarden and therefore become useless. Remember Tailscale? Nevermind, forget about it.

 

I've come long enough into this reply that I've already forgotten why I started it and pretty soon I'll be discussing something completely unrelated like Immich or suspension geometry.

 

Clearly outlining a goal would likely have made for a really short and quick suggestion at some point in the past which would have avoided the entire Tailscale discussion, possibly also anything about reverse proxies. You never know, maybe a plain text file on an encrypted disk volume could have been floated as a replacement for Vaultwarden. At the end of the day, it really seems like a piece of software expressly designed for anywhere connectivity is trying to be used for an as-yet unknown purpose.

 

 

 

Edited December 13, 20241 yr by Espressomatic

It looks like I ruffled some feathers, and I sincerely apologize for that. I guess I am dense, but I'm honestly trying to understand.

 

Let me be clear in when I say I say "no internet connection at all" I mean purely for the communication between the local Vaultwarden docker and for example a local computer running a browser. Of course I want to use the Bitwarden browser plugin to login to online websites etc. I am just having a hard time understanding why I can't just enter the local IP and port of the Vaultwarden vault and connect that way. Yes it wouldn't be as secure but if it's LAN-only then why not.

 

When I began setting up the reverse proxy I had to forward ports on my router in order for it to work. Which bothered me a lot, especially since I didn't see the need for it. Now I have it working through DNS challenge. No open ports, no firewall exceptions, and I think it's as safe as can be now. Even though I have no desire to ever access Vaultwarden outside of my LAN. It just works, and hopefully will continue to work even if my ISP decides to crap out for 3 weeks.

 

But anyway, I'm going to do for Vaultwarden what you so eloquently suggested I do for Tailscale, and stop worrying about it. I have the reverse proxy, it's secure, it works, and Tailscale is not something that I need for this particular thing. Done.

 

As for Tailscale, you won't believe it but I am actually using it as intended for other purposes, like securely accessing photos stored on my server when I am abroad etc. And now also for rsync backups to a remote location. It's great. So no I won't be staying away from it, but I just want to learn. And although I'm ignorant, I actually did pick up some things from your extensive reply, so thank you for that.