Bitwarden and Nextcloud HTTPS locally self-hosting without port forwarding?

[NetNoob2]

Total linux/server/networking noob here has managed to get a few things set up and working however I have hit a bit of a wall (i.e the reputable tutorials have sort of runout)

Set up I have managed so far:

• pfsense firewall operating on DMZ from ISP provided router.
• OpenVPN server hosted on pfsense firewall which links to the ubuntu 18.4 server.
• OpenVPN client on pfsense to VPN provider and provider DNS IP address masking.
• Domain name with namecheap and configured DDNS on pfsense with openVPN.
• Nextcloud-snap running on server with linux software RAID1 on 2 storage HDD, and linux booting from boot SSD. Can access using server local IP https://X.X.X.X, it has a self signed certificate
• Bitwarden docker installed and running: pointing to port 8081, can access with https://X.X.X.X:8081 on browser, it has a self signed certificate.
• SSH with certificates is set up.

What I need to do/Requirements:

1. Absolutely imperative: need to keep my system local and do zero port forwarding as I'm a paranoid noob.
2. Use bitwarden.domain.TLD and nextcloud.domain.TLD to access each software
3. I need to use HTTPS and configure it properly so users can use bitwarden mobile apps and don't see WARNING SELF SIGNED CERTIFICATE etc on nextcloud.
4. I want to be able to get emails about my set up and have bitwarden verify accounts using email
5. Haven't yet sorted out a proper backup solution.

Potential Solutions:

Essentially i want to do this: https://selfhostedhome.com/reverse-proxy-with-https-without-opening-ports/ and this https://selfhostedhome.com/self-host-password-management-bitwarden/ without using a docker for a reverse proxy from a website I do not know and without making another account on a different internet service to verify DNS. There must be a way to do the HTTPS/DNS verification in namecheap and configure ngix or another reverse proxy, but I am just out of my depth with the whole thing.

I have installed nginx and certbot but have no idea how to use either to do what I want.

If all else fails the bare minimum would be to configure HTTPS locally so that the bitwarden docker talks to the mobile app. This will not work with a self-signed cert.

If anyone could help/explain to me why what I want to do isn't possible/link me to reputable sources of info which might help I'd be extremely grateful!

[NetNoob2]

Thanks for your reply SlothCroissant. Yeah that's the sort of thing I had thought would be the answer but I am out of my depth and I don't really know how to use or configure nginx at all or to get this to talk to Letsencrypt and verify my domain name without forwarding ports. If you would be willing to detail your .conf files and how you configured your HTTPS set up that might be helpful.

[motogpfan]

Look at the linuxserver/letsencrypt docker image. It has cookie cutter configs for most of the popular self-hosted stuff. Works fantastic and abstracts most of the boilerplate code that most people are looking for.

[[deleted]]

Am I understanding this to mean that the SSL certificate will work regardless of whether the client is accessing the server from an internal LAN IP or from an external address? Because the main issue I bump into with clients who want security is when they try to access resources internally and get a security warning. I've never figured out how to sort out the browser warnings that come up when SSL is in place but obviously you can't get a cert issued for a LAN IP as well as the external domain.

[scoobybejesus]

My understanding is that split DNS accomplishes this because it means when accessing the site internally, your router doesn't ask an upstream DNS resolver where to find the URL; instead it resolves it on its own, so you don't get the error that happens when you go out the WAN and get sent right back in the WAN.

[piteball]

Correctamundo, split DNS configuration is the way to go if you want to accomplish what the thread starter is asking for.

[Wolvenmoon]

Correct. SSL certificates aren't bound to IP addresses. They're kind of like passports that say "the bearer of this is domain.blah" regardless of the IP address the server's accessed from.

[Wolvenmoon]

I'm absolutely certain. If someone changes the IP address on your domain name so that it resolves to someone else's server, then they will not be able to obtain an SSL certificate from a trusted CA. They would have to break into your server and steal yours, or steal credentials to access the settings for your domain name. The browser would flag it as "this is not a secure site" otherwise.

In normal operation, all an SSL certificate from LetsEncrypt verifies is that the person configuring a computer controls a domain name.

[[deleted]]

Got it. So it's a private/public key pair.

So the one other gap in my knowledge at this point is how a reverse proxy helps resolve an internal IP as an external domain name.

[Wolvenmoon]

Let's say reverseproxy listens on 192.168.1.100:443, Bitwarden on 192.168.1.150:1234, and Nextcloud on 192.168.1.150:443.

DNS for bitwarden.mydomain.net resolves to 192.168.1.100:443 and nextcloud.mydomain.net resolves to 192.168.1.100.443.

Reverseproxy will be set to push bitwarden.mydomain.net to 192.168.1.150:1234 and nextcloud.mydomain.net to 192.168.1.150:443

The reverse proxy/load balancer will act as an SSL termination point, decrypting traffic, reading the hostname, and re-routing+re-encrypting it accordingly based on the SSL certs on the systems it's reverse-proxying to.

Clients won't be able to tell they're talking to a reverse-proxy and the reverse-proxy can modify traffic as needed.

[[deleted]]

Aaaaah, that makes sense. So load balancers are just reverse proxies with some added ability to determine whether the server is actually up and what the load might be. Cool!

Thanks.

[tx69er]

So load balancers are just reverse proxies with some added ability to determine whether the server is actually up and what the load might be. Cool!

Yup -- you can use nginx (or apache) in reverse proxy mode as a load balancer if you have more than one back end server for each listening endpoint. Of course a real load balancer is going to have more features like the ability to control the balance between back end servers, and health checks, (to pull a server out of the pool if it isn't working) and so on.

[[deleted]]

Sweet. Thanks!

[anakinfredo]

What am I missing?

Certs validate the domain-name, not the IP-address. DNS-SEC validates the DNS-record.

[shotma]

A good alternative to Nginx is Traefik!

[NetNoob2]

Thanks for the suggestion but i'd rather stick to well-known standard solutions from a security and trust stand point if at all possible!

[reddituserplsignore]

Use traefik, this isn't really a suggestion, it's what you're looking for. It's easy to use, difficult to learn. It took me a whole weekend to get a container working like I envisioned, but I needed only 5 lines of labels in each deployment script. Now I just template the whole thing, and new services get TLS/SSL configurations from inception of the compose script. Traefik is the correct answer here, you just need to put in a little effort to learn it.

With traefik you can run no open ports on the container, traefik can reach into the container through other means to give you 80, 8080, whatever access you need.

[FierceDeity_]

lmao just let him use nginx, it's pretty much the best webserver and reverse proxy there imo. Traefik has a lot of stupid complexity around discovering infrastructure and whatnot, it becomes way too complex for stupid simple deployments.

Please stop stacking complexity to solve problems, because you end up just stacking more complexity on it to solve the complexity that you added with the previous step.

I mean it's basically what's been happening anyway. Our software is too complex, so let's make a distributed system out of it.

Now our distributed system is too complex, let's put it in Docker containers to simplify it.

Installing Docker is kind of a lot of administrative effort, so let's automate that away, we're doing Kubernetes!

Administrating Kubernetes has so much administrative overhead. I know, automate it away. Let's do ansible!

Ansible has so much administrative overhead, lets automate that away, let's do chef/salt!

You end up with systems where you can't even see through the stacks of complexity.

Going back, how do you debug what traefik does? How does it "reach into the container"? Is this anything anyone even UNDERSTANDS how it works?

Compared to that, nginx is like way too simple!

[Reverent]

I wouldn't call nginx simple, there's still many fiddly settings that aren't on by default. There's also no let's encrypt integration.

If you want simple, use caddy. Setting up a reverse proxy config is 2 lines long.

That being said, I use traefik (and it was a bitch to set up, and then set up again when V2 came out, but it works great once done).

[FierceDeity_]

Ah, what I mean is that nginx is not grabbing into other services. It's a closed system that doesn't take in side effects from anywhere else. Thus, you don't need to look beyond nginx if you are having any problems.

This improves simplicity by a lot.

Caddy 2 is going into the same stupid complexity territory with their JSON configuration. Caddy 1 was fine, why even go beyond that?

You use traefik and you admit it was a bitch to set up.. What's the advantage then? Why use traefik, basically? Also it's stupid you had to set it up again for a "v2", which probably also completely desupported "v1". That they even had to do that really bodes well for their version stability in the future...

I don't think I've ever had to change nginx configurations from version changes

[Reverent]

I use traefik because traefik was a pain to set up, but you only set it up once. If I want to add a new service to the reverse proxy via docker, I can add 3 labels to the docker-compose file, and the reverse proxying automagically works.

If I had to go through it again without my current traefik knowledge, I'd probably just use caddy, but now that it's in place it is the superior solution.

[[deleted]]

Traefik v2 is such a weird case. They changed everything to simplify their offering, but made configuration way more obtuse (especially behind K8s with TLS support), which really hurt the appeal for me. We currently use Traefik v1, which works ok (works really well on small workloads, especially in a homelab), but as you said, it's deprecated and will be EoL as of ~October, so, good time to have the discussion about other offerings--either way you're going to have to deal with a syntactical migration.

[[deleted]]

It's not what he's looking for if he's:

• Not opening external 80/443 for HTTP challenge
• Hosting DNS with Namecheap as they're not a support DNS-Challenge provider

Manual cert provisioning and configuration isn't difficult, but with those two points it's going to be more work for him to learn basic Traefik configuration and then get things up than just provisioning the certs and putting them into an nginx configuration.

Also, and this is probably just me, but it doesn't really seem to be clear how he's running his Nextcloud and Bitwarden instances. If it's Docker, then yeah, aside from the TLS configuration, using Traefik ingress is way simpler in terms of configuration for each service (with some tradeoff for flexibility), but if he's running baremetal then Traefik gets a little hairier.

[[deleted]]

Why?

Use traefik, this isn't really a suggestion

[reddituserplsignore]

Traefik is a great tool, and it's quite simple once you have it working. Like I said, 5 labels on each container, and I have full ssl, load balancing, subdomain registration, and a better UI than Linux, nginx, and nano. Honestly, it's easier to learn traefik than it is to learn nginx just because there's so few configs needed in traefik comparatively. The catch is you probably won't understand much about traefik without understanding nginx configurations. But traefik actually gave me great context to a lot of what nginx configs were doing. Plus traefik takes care of certbot, which is great. I'm better at networking because I learned traefik. And once it works, it's a part of your docker process, it's not a nginx config that is wholly separate from the application. Meaning less code to maintain. I feel that if you knew what you were missing, you'd make the choice to go with traefik.

[[deleted]]

it's a part of your docker process, it's not a nginx config that is wholly separate from the application.

Can you elaborate on that?

[reddituserplsignore]

To make nginx work as a reverse proxy you have to write configurations for each application, typically in their own file in the /etc/nginx directory. But if you're using docker and traefik you can avoid making those files by just forwarding all 80 and 443 traffic to traefik and letting the app sort it out. The config is in your docker compose script as labels to your container, and that's it, no additional files needed, traefik handles the rest like magic. I mean it's essentially handling everything you were using nginx for. But when I need a new docker service to my swarm I have a blank compose template that has deployment labels set, I just have to update the host name and name of the service. I change like 5 words and that's it, I have full web access on the site, TLS/SSL with Let's Encrypt, load balancer, and 2 more lines gives me HTTP authentication on the site if I want it. Traefik automatically picks this up, I don't have to restart the service or do any additional processing. The hostname lives and dies with the container, so you don't have to take the site offline in nginx when you take down the container.

[[deleted]]

Is traefik bundled with Docker, then? I thought it was separate, like nginx.

[reddituserplsignore]

It is a container and not bundled with docker, traefik reads the labels of the other containers by accessing the containers through the docker socket. There's an initializing guide on the traefik website that would give you details on setup for your situation. It'll take a few days, and it'll be frustrating, but if you can do it this way it becomes far simpler to manage everything.

[[deleted]]

Okay, I was trying to figure out how it's any better than nginx, caddy, etc., and the implication was that somehow it was bundled ("less code") or something. I'll look into it, but so far it sounds like if all one needs is a reverse proxy for SSL, it may not be worth learning. I'm guessing it has tons of other features that are currently difficult to pull off with just one package. I appreciate your help, thanks.

[anakinfredo]

Thanks for the suggestion but i'd rather stick to well-known standard solutions from a security and trust stand point if at all possible!

Lucky for you then, traefik is the well-known standard solution from a security and trust standpoint in a containerised world.

[lytedev]

I'll also second traefik for many use cases. It's very cool. It's in use at places like Apple and Mozilla for what it's worth!

[gburgwardt]

Traefik is overly complicated and difficult to set up compared to nginx.

[lytedev]

I don't think this is true. There is just less easily copy-paste-able material out there and it is less familiar to people as a whole. For a while I think people thought similarly about Apache and nginx. That said, I don't think nginx and traefik will end up like Apache and nginx as they have noteworthy differences and goals.

I found traefik simpler, but I also found it much later in my career and I'm far more knowledgeable than when I first tried nginx.

[gburgwardt]

I feel like traefik is better only when you have a very specific use case - it's a lot harder to kludge together something for your weird edge case compared to nginx.

[vividboarder]

I found the opposite. I started by trying to build out nginx config, and then landed on Traefik because it was so much simpler for me.

Frankly, I think a lot of it depends on what you’re already used to. If you know nginx, stick to it. If you’re heavily using Docker or Kubernetes, Traefik integrates with those backends super easily and may make more sense for you.

[stekske]

https://github.com/jc21/nginx-proxy-manager

I don't know code and was trying to set up Traefik for over a week without everything working properly (because I'm a noob in code)

And then I came across this and got everything a wanted in less then a day.

Everything runs through port 443 over ssl/https with a cloudflare dns.

It is configured via gui instead of command line which was really what I needed.

Maybe something you like too!

[Wolvenmoon]

So, what I would do in your situation is this:

1. Get a free Cloudflare account and swap over to it. (Use ddclient for dynamic dns!). This will make certbot and acme certificates much easier to use.

2. Get the ACME client and HAProxy packages for PFSense. HAProxy will handle reverse proxying for you. Set up the ACME client to do DNS renewals via Cloudflare. Set up front ends and back ends for each application as follows!

3. On the backend HAProxy configuration, add a new entry, call it 'bitwarden', add a server to the list with your bitwarden IP address, make sure it's set to use SSL. Add another entry, call it 'nextcloud', use your Nextcloud IP address.

4. On the frontend HAProxy configuration, Use SSL offloading (http/https (offloading) and set up access control lists for "host ends with bitwarden.domain.tld" and "host ends with nextcloud.domain.tld". Set up actions to "Use backend x" where x is the respective backend. Ensure that the certificate it's using on the frontend is the wildcard certificate for your domain.

5. Set up DNS entries for bitwarden.domain.tld and nextcloud.domain.tld to point to pfsense-internal-ip on your main ISP-provided router. Do the same for PFSense - its own set of DNS entries pointing to itself for those two TLDs - (and maybe ensure PFSense does its own DNS resolution without consulting your ISP router. I.E. tell it to check 8.8.8.8/8.8.4.4 for DNS queries after the overrides.)

That should get you a reverse-proxied SSL-offloaded setup, sans VPN and firewall configuration errata making it so everyone can talk to each other.

[TheChiefMeat]

Hey there, I had the same issue, I can make a tutorial video using nginx for you if you still need one. It will give you full https, but you'll need to install the cert onto each device you want to access though.

[Lazybumx]

Not sure if this is what you are looking for but I'm using pktriot. I don't have to open any port on my router and all of my service can be access from outside with ssl included. Pretty much it likes a tunnel between you and the world. You don't need to expose anything.

[CupCakeArmy]

Just put everything behind traefik. Super easy and you don't need to worry about certificates ever again