"New Device Logged In" shows wrong IP #355

New Issue

OVERLORD · 2026-02-04T19:54:02+03:00

OVERLORD commented

2026-02-04 19:54:02 +03:00

Originally created by @tycho on GitHub (Aug 1, 2019).

The "New Device Logged In" email gave me this:

Date: Thursday, August 1, 2019 at 10:19
IP Address: 127.0.0.1
Device Type: Chrome

My nginx config is setting the X-Real-IP and X-Forwarded-For headers for the reverse proxy. Am I missing some other one that would make it recognize what the real client IP is? Or is bitwarden_rs just ignoring those headers for some reason?

Originally created by @tycho on GitHub (Aug 1, 2019). The "New Device Logged In" email gave me this: ``` Date: Thursday, August 1, 2019 at 10:19 IP Address: 127.0.0.1 Device Type: Chrome ``` My nginx config is setting the `X-Real-IP` and `X-Forwarded-For` headers for the reverse proxy. Am I missing some other one that would make it recognize what the real client IP is? Or is bitwarden_rs just ignoring those headers for some reason?

OVERLORD closed this issue

2026-02-04 19:54:13 +03:00

OVERLORD commented

2026-02-04 19:54:19 +03:00

@janost commented on GitHub (Aug 1, 2019):

Are you sure you are properly setting X-Real-IP?

I was able to reproduce the issue without that header, however adding it back fixed the issue.

@janost commented on GitHub (Aug 1, 2019): Are you sure you are properly setting `X-Real-IP`? I was able to reproduce the issue without that header, however adding it back fixed the issue.

OVERLORD commented

2026-02-04 19:54:27 +03:00

@tycho commented on GitHub (Aug 1, 2019):

I just figured it out. nginx seems to violate the "principle of least astonishment" for me rather frequently.

Here's basically what I had (removed the unimportant stuff to focus on the issue itself):

upstream bitwarden {
        server 127.0.0.1:8378;
        keepalive 16;
}
server {
        listen 443 ssl http2;
        listen [::]:443 ssl http2;

        [...]

        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;

        location / {
                proxy_http_version 1.1;
                proxy_set_header Connection "";
                proxy_pass http://bitwarden;
        }

        location /notifications/hub {
                proxy_pass http://127.0.0.1:3012;
                proxy_set_header Upgrade $http_upgrade;
                proxy_set_header Connection "upgrade";
        }

        location /notifications/hub/negotiate {
                proxy_http_version 1.1;
                proxy_set_header Connection "";
                proxy_pass http://bitwarden;
                access_log off;
        }
}

The problem was that apparently the proxy_set_headers in the server{} scope don't propagate to child location ... {} scopes. When I do this, it works as intended:

upstream bitwarden {
        server 127.0.0.1:8378;
        keepalive 16;
}
server {
        listen 443 ssl http2;
        listen [::]:443 ssl http2;

        [...]


        location / {
                proxy_http_version 1.1;
                proxy_set_header Connection "";

                proxy_set_header Host $host;
                proxy_set_header X-Real-IP $remote_addr;
                proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
                proxy_set_header X-Forwarded-Proto $scheme;

                proxy_pass http://bitwarden;
        }

        location /notifications/hub {
                proxy_set_header Upgrade $http_upgrade;
                proxy_set_header Connection "upgrade";

                proxy_set_header Host $host;
                proxy_set_header X-Real-IP $remote_addr;
                proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
                proxy_set_header X-Forwarded-Proto $scheme;

                proxy_pass http://127.0.0.1:3012;
        }

        location /notifications/hub/negotiate {
                proxy_http_version 1.1;
                proxy_set_header Connection "";

                proxy_set_header Host $host;
                proxy_set_header X-Real-IP $remote_addr;
                proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
                proxy_set_header X-Forwarded-Proto $scheme;

                proxy_pass http://bitwarden;
                access_log off;
        }
}

I feel like I should just write a tool that generates my nginx configs at this point. They are uncomfortably verbose and I end up doing a lot of duplication to get things to behave.

@tycho commented on GitHub (Aug 1, 2019): I just figured it out. nginx seems to violate the "principle of least astonishment" for me rather frequently. Here's basically what I had (removed the unimportant stuff to focus on the issue itself): ``` upstream bitwarden { server 127.0.0.1:8378; keepalive 16; } server { listen 443 ssl http2; listen [::]:443 ssl http2; [...] proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; location / { proxy_http_version 1.1; proxy_set_header Connection ""; proxy_pass http://bitwarden; } location /notifications/hub { proxy_pass http://127.0.0.1:3012; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; } location /notifications/hub/negotiate { proxy_http_version 1.1; proxy_set_header Connection ""; proxy_pass http://bitwarden; access_log off; } } ``` The problem was that apparently the `proxy_set_header`s in the `server{}` scope don't propagate to child `location ... {}` scopes. When I do this, it works as intended: ``` upstream bitwarden { server 127.0.0.1:8378; keepalive 16; } server { listen 443 ssl http2; listen [::]:443 ssl http2; [...] location / { proxy_http_version 1.1; proxy_set_header Connection ""; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; proxy_pass http://bitwarden; } location /notifications/hub { proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; proxy_pass http://127.0.0.1:3012; } location /notifications/hub/negotiate { proxy_http_version 1.1; proxy_set_header Connection ""; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; proxy_pass http://bitwarden; access_log off; } } ``` I feel like I should just write a tool that generates my nginx configs at this point. They are uncomfortably verbose and I end up doing a *lot* of duplication to get things to behave.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/vaultwarden#355