Thankfully I’m running all on proxmox, so with Dietpi template VM’s and snapshots.
Still… Thx for the heads up 
gut das wir alle deutsch sprechen 
I guess biggest problem is to have NPM running on a different VM than Vaultwarden. Therefore blocking / fail2ban would need to be running on that VM hosting NPM. What you could try is to share vaultwarden log via NFS. Means you create an NFS export on Vaultwarden VM hosting the log file and mount it on NPM VM. This way fail2ban should be able to read the log file.
Continuing in english for the sake of all
Yes, shared log was the idea with rsyslog. Will look at your suggestion.
I wanted Vaultwarden separate from nginx because of security and because all tutorials of self hosted Bitwarden do it like this…
But as sees this adds another layer of complexity.
SOLVED. @Joulinar Super Idee!!!
I have done the following:
- install samba server on Vaultwarden (dietpi easy stuff)
- add the Vaultwarden log folder (as specified above, thanks a lot again to @ Jappe) to /etc/samba/smb.conf as share folder
- install samba client on nginx
- mount abnove share via dietpi-drive_manager
- create fail2ban filter and jail as specified above with the samba share as log folder
WORKS! Fail2ban in Vaultwarden logs the error to the shared log file (and bans the IP if more than 3 tries). Fail2ban on nginx also sees the attempt in the shared log file and also acts accordingly, as it now sees the correct IP it ban it.
Thank you all so much for arriving at this (easy) solution. Now I have self hosted Vaultwarden vis nginx proxy with adequate protection (apart from obviously blocking access via firewall).
All good, which ends good.
3 Likes
I guess F2B on Nginx VM should be enough as this is the point where initial connection happen
One hint, keep in mind that F2B on Nginx VM depends on the shared log file now. Means, if you reboot system or due to whatever reason, the mount could be hanging or F2B might have some challenges if the log is not available on reboot. Maybe a specific reboot order is needed to ensure the log beging available before F2B is trying to access it . Something to play around with.
Guess you’re right about superfluous F2B on Vaultwarden, will uninstall it to test.
Yes boot order now is an issue (there always is one) BUT in proxmox I can specify boot orders, so I can workaround this. Thx for pointing this out!
Fail2ban on Vaultwarden removed. ALL fine now!
1 Like
I didn’t read everything as the thread is long 
, but as you can see in the defaults part of the jail.conf, the systemd backend is used by default so that fail2ban can scan the system journal for failed login logs, so no file login required.
@MichaIng
Challange was, F2B running on a different system and it was needed to share Vaultwarden log from VM1 with F2B running on VM2.
Exactly. And creating the file on a smb share and reading it on Fail2ban with smb client was so easy!
Ah okay, makes sense then. In theory, there is systemd-journal-upload, but it’s not worth it.
I hope this rather long thread will be worthwhile for others as the issue poses itself each time we have the nginx reverse proxy in the middle and want to use fail2ban to ban IP’s coming from there… No matter the end application being attacked.
It would not be that complex if all apps would be running on a single host 
True! But As Sun Tzu said: “Divide and conquer”
1 Like
