Bitwarden Letsencrypt Proxy Config / DuckDNS


Recommended Posts

I've followed SpaceInvader videos regarding Nextcloud/Letsencrypt/Duckdns reverse proxy and I'm trying to mimic it for bitwarden to access outside of network but I can't get it working. I think I'm stuck on the config.

 

 

my settings for bitwarden

Network Type - Custom myserver123
Container Port - 8888 - changed from default 80

 

my nginx proxy config - Server_name is a sample for duck dns, such myserver123bitwarden.duckdns.org

# make sure that your dns has a cname set for bitwarden and that your bitwarden container is not using a base url

server {
    listen 443 ssl;
    listen [::]:443 ssl;

    server_name myserver123bitwarden.*;

    include /config/nginx/ssl.conf;

    client_max_body_size 128M;

    # enable for ldap auth, fill in ldap details in ldap.conf
    #include /config/nginx/ldap.conf;

    location / {
        # enable the next two lines for http auth
        #auth_basic "Restricted";
        #auth_basic_user_file /config/nginx/.htpasswd;

        # enable the next two lines for ldap auth
        #auth_request /auth;
        #error_page 401 =200 /login;

        include /config/nginx/proxy.conf;
        resolver 127.0.0.11 valid=30s;
        set $upstream_bitwarden bitwarden;
        proxy_pass http://$upstream_bitwarden:8888;
    }

    location /notifications/hub {
        include /config/nginx/proxy.conf;
        resolver 127.0.0.11 valid=30s;
        set $upstream_bitwarden bitwarden;
        proxy_pass http://$upstream_bitwarden:8888;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "Upgrade";
    }

    location /notifications/hub/negotiate {
        include /config/nginx/proxy.conf;
        resolver 127.0.0.11 valid=30s;
        set $upstream_bitwarden bitwarden;
        proxy_pass http://$upstream_bitwarden:8888;
    }

}

 

Link to comment
3 hours ago, WhazZzZzup17 said:

Looks like I fixed it.

 

I had to make a new duckdns for whatever reason

Sounds strange, as the problem looks to be your port. You should use 80 instead of the port you mapped to the container as it uses dockers internal network to resolve names.

Link to comment
  • 2 months later...
On 8/21/2019 at 7:48 AM, saarg said:

Sounds strange, as the problem looks to be your port. You should use 80 instead of the port you mapped to the container as it uses dockers internal network to resolve names.

That will not work, because the docker is still part of the 0.0.0.0 network of unraid. There's no new IP for that docker instance. I'd prefer it if it was that way, but none of the dockers for unRAID do this.

Link to comment
8 hours ago, fluisterben said:

That will not work, because the docker is still part of the 0.0.0.0 network of unraid. There's no new IP for that docker instance. I'd prefer it if it was that way, but none of the dockers for unRAID do this.

 

Not sure what you mean here.

If you use a custom network for letsencrypt and the containers you reverse proxy are using our proxy-confs, you have to use the container port, not the host port.

Link to comment
7 hours ago, fluisterben said:

Name resolving has nothing to do with either network or ports of a docker container.

 

Not sure if I should bother answering you or not.

 

Name resolving in a docker network has to do with the network used. The default docker bridge created doesn't support name resolving and a custom bridge have to be made for this to work.

The port have nothing to do with name resolving, but I haven't claimed it to be either. Inside the docker network, the containers talk to each other on the container ports and not the host ports. That is why I mentioned the ports have to be the container ports.

Link to comment
4 hours ago, saarg said:

 

Not sure if I should bother answering you or not.

 

Name resolving in a docker network has to do with the network used. The default docker bridge created doesn't support name resolving and a custom bridge have to be made for this to work.

The port have nothing to do with name resolving, but I haven't claimed it to be either. Inside the docker network, the containers talk to each other on the container ports and not the host ports. That is why I mentioned the ports have to be the container ports.

You wrote;

"You should use 80 instead of the port you mapped to the container as it uses dockers internal network to resolve names."

which is just incorrect. First, docker does not by definition 'uses an internal network'. You set it to do so. Second, names are resolved using DNS, which can point anywhere, regardless of where in a network you are.

Link to comment
5 hours ago, fluisterben said:

You wrote;

"You should use 80 instead of the port you mapped to the container as it uses dockers internal network to resolve names."

which is just incorrect. First, docker does not by definition 'uses an internal network'. You set it to do so. Second, names are resolved using DNS, which can point anywhere, regardless of where in a network you are.

We are talking about the OP setup here and not in general.

I haven't specified if things happens automatically or it's set up by the user , that is you putting words in my mouth.

 

 

Link to comment
On 11/14/2019 at 5:58 PM, fluisterben said:

Name resolving has nothing to do with either network or ports of a docker container.

Name resolving has everything to do with the docker network used in this case. The dns resolver is defined as "127.0.0.11" in the user's config as posted above (also as such in the preset proxy confs we provide), which is docker's resolver. If both containers are in a "user defined bridge network", that resolver will resolve container names and aliases to container IPs used in that "user defined bridge network". There is no such resolution in the default docker bridge network. Also fyi, you can simply not set any network in the container creation arguments and docker by default will use the default bridge. And when a container connects to another container via the docker bridge network IP, it should use the container port, not the host port mapped as saarg wrote.

 

Either you are confused, or you are arguing semantics for the sake of arguing. In any case, you are not being helpful.

Edited by aptalca
Link to comment

There are no names to resolve when you proxy outside of a docker container using nginx. Not much of what I read here makes any sense;

The name resolving is done outside of the container here, for nginx, with dyndns. NGINX listens to that name and serves its vhost, then proxies to/from the docker container on a specified port, which isn't 80 or 443, because those are already used in the network.

Port numbers are not being 'resolved' by DNS.

Link to comment
4 minutes ago, fluisterben said:

Not much of what I read here makes any sense;

That much is clear.

 

I think you're really confused. 

 

Dyndns is irrelevant. We're not talking about name resolution of the domain url. We're talking about name resolution of container names used in the nginx proxy_pass directive. 

 

Ports 80 or 443 also have no relevance. They are the listening ports of the nginx/letsencrypt container. There is no such thing as "already used in the network". Ports are device specific, not network.

 

No one said anything about ports being resolved. We are trying to make a distinction between container ports and host ports, which docker maps via -p (--publish) and can be different.

Link to comment
  • 5 months later...

I still have a problem getting Bitwarden to work with letencrypt. 
Other then letencrypt config file modification with subdomain. Is there anything else that need to me changed

I set up duckdns with a new bitwarden subdomain. 
added the subdomain to letencrypt and modified the config file. Anything else I am missing. 

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.