DSM 7.0 Vaultwarden doesnt work since DSM 7 update Synology

[Nash]

Hello,
I ve just updated my Synology to DSM 7. However my vaultwarden is not working anymore. Here the problem :

• i can access to HTTP link but cant login because vaultwarden works only in HTTPS
• I can’t access to HTTPS because i have a “404 not found nginx” page.

I tried to uninstall / reinstall but nothing happened.
I checked my port in the docker (7002 + 7003) + reverse proxy (7024 for going in https and 7003 for http)
My certificate is good and worked great befofre the DSM update. The certificate is choosen for my vaultwarden docker.

Thx a lot !

 

[Rusty]

Are you using any custom reverse proxy configuration for your vault warden setup? If so the nginx will probably be “broken” after migrating to dsm 7.

 

[Nash]

Are you using any custom reverse proxy configuration for your vault warden setup? If so the nginx will probably be “broken” after migrating to dsm 7.

Hello,

Thx for your reply. No i dont use custom reverse proxy configuration, i just installed it as "normal". I just proceeded to a standard installation then put my reverse proxy configuration into the DSM nothing else.

-- post merged: 8. Aug 2021 --

Here the ports configuration in docker + RP in DSM

 

[Rusty]

Just a problem with this particular docker container or with any other one?

Same problem if you use ip address of your nas instead of localhost in reverse proxy?

 

[Nash]

Just a problem with this particular docker container or with any other one?

Same problem if you use ip address of your nas instead of localhost in reverse proxy?

This is the only docker which is running.

I tried to change with my NAS IP but for HTTPS it doesnt work i cant write a ip address the box is red. But for HTTP it works and i can still access to the vaultwarden through the 7003 port.

 

[Rusty]

This is the only docker which is running.

I tried to change with my NAS IP but for HTTPS it doesnt work i cant write a ip address the box is red. But for HTTP it works and i can still access to the vaultwarden through the 7003 port.

I was thinking about the destination ofc not the source. Ok and when you enter ip there you still can’t access it?

Same problem when you try and access it outside your lan? Like over 4G?

 

[Telos]

Activate HSTS... and use NAS IP, not "localhost". Any change?

 

[Nash]

I was thinking about the destination ofc not the source. Ok and when you enter ip there you still can’t access it?

Same problem when you try and access it outside your lan? Like over 4G?

Yeah over WAN or LAN cant access to the HTTPS.

-- post merged: 8. Aug 2021 --

Activate HSTS... and use NAS IP, not "localhost". Any change?

You cant use nas ip insidethe https box of the RP. But i tried with HSTS activate : no change.

 

[Gerard]

I’m thinking there’s a block with httpS, 7024, can you provide screenshots of the router port forward/firewall?

 

[Telos]

You cant use nas ip insidethe https box of the RP. But i tried with HSTS activate : no change.

You use the NAS IP on the target where you have HTTP localhost. HSTS has no issue with that.

 

[Nash]

I’m thinking there’s a block with httpS, 7024, can you provide screenshots of the router port forward/firewall?

Hello its all good this side im network admin !

-- post merged: 9. Aug 2021 --

You use the NAS IP on the target where you have HTTP localhost. HSTS has no issue with that.

It doesnt work. But i suspect a certificate problem. I tried to switch with the synology certificate then back to my domain certificate and now i got this : SSL_ERROR_INTERNAL_ERROR_ALERT

P.S : tried to re-generate the certificate : still not working.

 

[Telos]

There are reports over at the Community that reverse proxy cannot use 443 inbound without triggering an error in DSM7. Perhaps a bug? Or another intentional DSM7 regression. Apparently existing RPs work, but edit them, or adding additional fail.

Maybe related to your Vaultwarden issue?
https://community.synology.com/enu/forum/20/post/145064.

 

[Telos]

There are reports over at the Community that reverse proxy cannot use 443 inbound without triggering an error in DSM7

I came across a related post on Reddit that was traced to the installation of the Tailscale package. Once that was uninstalled, 443 was available to RP.

 

[dracarys94]

i do have the same problem, but unfortunately i do not have a solution yet.

I have a Synology DS218+ with the latest DSM 7.0.1-42218 and a FritzBox 6591 with the latest firmware.

I am using the vaultwarden image (latest version 1.23.0) with a docker and configured a reverse proxy on the NAS with a DNAT on the Fritzbox for external usage.

Before the upgrade of DSM (before it has been 6.2.4) everything worked pretty well. After the upgrade not anymore.

Right now, the following happens:

bitwarden over http from the internal network --> works fine

bitwarden over https from the internal network --> i guess that never worked (i even used the external DNS name from the internal network)

bitwarden over http from the external network --> 400 Bad Request The plain HTTP request was sent to HTTPS port
nginx (i only use HTTPS for external usage)

bitwarden over https from the external network --> 404 Not Found nginx

In the following you can see the current configuration of my reverse Proxy, so internally the bitwarden is reachable on Port 5555 and from the external another dynamic port which is normally forwarded through the DNAT and reverse Proxy.

What can i do now?
I even deactivated HSTS, changed the hostname from localhost to the IP-adress, but actually everything worked well before the upgrade. Apart from that i even deleted the docker image and built a new image with a new container - it does not work.

 

[Rusty]

i do have the same problem, but unfortunately i do not have a solution yet.

Is this the only RP host that you have? Any other host having problems like this? I guess you are not running BW liveSync feature as it requires a custom RP config that you can't setup using the UI, so that might not be it.

Try and log into your NAS via SSH, and check the /var/log/nginx location for the logs (error log especially).

 

[dracarys94]

Yes this is the only RP i have.
I just logged into my NAS but the error.log and the error_default.log file don't show any current logs. I guess, the logs are generated in another file or directory, because even the latest attempts from me reaching BW (vaultwarden) haven't generated any new logs in those mentioned files.

I can't think of any new ideas at the moment.....

 

[Rusty]

because even the latest attempts from me reaching BW (vaultwarden) haven't generated any new logs in those mentioned files

That could mean that your reverse proxy was not hit at all. Maybe it would be a good idea to set up another container and test it access over RP just to see if this problem can be reproduced.

 

[jeyare]

First:
it doesn’t matter if you use localhost or IP of your NAS interface, when you don’t use manually configured IPTABLES (by SSH)
it is still the localhost which handling the packets based on IPTABLES rules defined in Synology DSM (6.x or 7.x)

all what you need to check is described here:

Tutorial - Synology Reverse Proxy under the hood

one-eyed-king submitted a new resource: Synology Reverse Proxy under the hood - Fed up with the limitation of the Synology reverse proxy? Introduction Rusty made a fabulous beginner friendly tutorial on how to configure reverse proxy configurations using the UI: Tutorial - Synology Reverse...

www.synoforum.com

be careful, in the DSM7 you need change command:
synoservice
to
systemctl

when you will finish with same stage, you are the next candidate of broken nginx

 

[dracarys94]

honestly that doesn't help me

unfortunately i piped the output of grep in vim itself and now the nginx.conf seems to be broken. I even cannot access to my nas GUI anymore.

If i wan't to view the nginx.conf right now with "vi nginx.conf", the following output appears:

And if i press R and then ENTER , i can access the nginx.conf file and the code starts with the following (i guess, that's the input from my keyboard, i just entered directy after the "vi nginx.conf | grep "3456" command

what could i do now to fix the broken nginx.conf file, so that i can proceed with troubleshooting of the actual problem?

 

[one-eyed-king]

Make sure to sudo vi /etc/nginx/nginx.conf or do sudo -i before the vi command.

Edit the file, navigate to the character or line you want to remove, then:
- delete chracter: x
- delete line: dd (yes, twice)
- undo last action if required: u

Make sure you are not in the "INSERT" mode (i) when using these commands.

Once the file is fixed
- esc
- then either :x or :wq

What made it necessery to even mess arround with /etc/nginx/nginx.conf? See Tutorial - Synology Reverse Proxy under the hood for alternatives places where to store your custom nginx rules, how to test if the config is valid and how to restart nginx on Syno.

You can find an unmodified version of /etc/nginx/nginx.conf from DSM6.2 in the attachment of the post. You could potently download it, copy it to a share and then copy it as root from the share back to /etc/nginx/nginx.conf. Make sure to backup your existing copy if you choose this approach! Or just use the file to check for differences of your broken nginx.conf and the unmodified one like this diff /etc/nginx/nginx.conf /volume1/docker/nginx.conf (assumed your docker package is installed on volume1, thus your docker share is on volume1 and you renamed the file from nginx.conf.txt to nginx.conf).