Identity log still showing container IP instead of real IP

Hello, so I followed the instructions at

For those who would ask, you then need to perform the following tasks to enable Fail2Ban for Bitwarden.

Add the following to bwdata/env/global.override.env :

Add the following to bwdata/config.yml :


Restart Bitwarden.
Be sure bwdata/logs/identity/Identity/log.txt is there.

I did updateconf and rebuild and I see that it has added the IPs to the nginx config but in the log.txt I see:

2020-06-17 15:16:12.843 +00:00 [WRN] Failed login attempt. 172.X.0.1

In the nginx access.log it is also showing:

172.X.0.1 - - [17/Jun/2020:15:16:12 +0000] “POST /api/accounts/prelogin HTTP/1.1” 200 32 “https://</removed/>/” “Mozilla/5.0 (Windows NT 10.0;
Win64; x64; rv:77.0) Gecko/20100101 Firefox/77.0” “-”

This server is hosted on a cloud provider and not behind another proxy or anything like that. Did I miss a step?

1 Like

I have the exact same problem!
Was hoping someone in this thraed already solved it but sadly there are no replys :frowning:
Only difference for me is that I use another apache reverseproxy between bitwarden and public access.

172.X.X.X should definitely be the internal docker IP address. But I dont’t know how to forward (or something like that) the real accessing IP adresses to to container. This issue also causes wrong e-mail notifications for me btw. If I login on a new device the e-mail I receive also shows this internal IP address instead of my real one.
For clarification: my Bitwarden is selfhosted using docker.

Would be very happy if someone could help us out with that

Okay, after some more resreach and reading some recent other forum posts I finally found the solution:

It’s actually very easy I I feel kind of stupid now that it took me SO long to finally fix this.

You just have to set the “real_ips” parameter in the config.yml. I always misinterpreted this parameter which is why I discarded these approaches.
It already is enough to just set the container ip there but because of other proxy addesses appearing for after that I just included the whole private subnet here.

So this is my configuration of …./bwdata/config.yml that did the trick:

Of course you have to perform a “ rebuild” and “ start” after it