starred/vaultwarden
1
0
Fork 0
mirror of https://github.com/dani-garcia/vaultwarden.git synced 2026-04-26 09:46:00 +03:00
Code Issues 39 Projects Releases 5 Packages Wiki Activity

[GH-ISSUE #1417] Actual client ip for websocket connections not showing up in logs #948

New issue
Closed
opened 2026-03-03 02:04:55 +03:00 by kerem · 9 comments
kerem commented 2026-03-03 02:04:55 +03:00
Owner
Copy link

Originally created by @mustaphazorgati on GitHub (Feb 20, 2021).
Original GitHub issue: https://github.com/dani-garcia/vaultwarden/issues/1417

Subject of the issue

Your environment

  • Bitwarden_rs version: 1.19.0
  • Install method: Docker image
  • Clients used: web
  • Reverse proxy and version: caddy v2.3.0
  • Version of mysql/postgresql:
  • Other relevant information:

Steps to reproduce

start bitwarden normally and enable websocket.

docker-compose file:

version: '3'
services:
  bitwarden:
    image: bitwardenrs/server
    environment:
      WEBSOCKET_ENABLED: 'true'
    volumes:
      - bitwarden-data:/data
    ports:
      - 8005:80
      - 3012:3012

volumes:
  bitwarden-data:

forward X-Real-IP from caddy to bitwardenrs
caddy config:

https://<DOMAIN> {
	encode gzip

  	header {
       		# Enable HTTP Strict Transport Security (HSTS)
       		Strict-Transport-Security max-age=31536000;
       		# Enable cross-site filter (XSS) and tell browser to block detected attacks
       		X-XSS-Protection "1; mode=block"
       		# Disallow the site to be rendered within a frame (clickjacking protection)
       		X-Frame-Options DENY
       		# Prevent search engines from indexing (optional)
       		X-Robots-Tag none
       		# Server name removing
       		-Server
   	}

	# The negotiation endpoint is also proxied to Rocket
  	reverse_proxy /notifications/hub/negotiate localhost:80 {
		# Send the true remote IP to Rocket, so that bitwarden_rs can put this in the
        	# log, so that fail2ban can ban the correct IP.
		header_up X-Real-IP {remote_host}
	}

  	# Notifications redirected to the websockets server
  	reverse_proxy /notifications/hub localhost:3012 {
		# Send the true remote IP to websocket server, so that bitwarden_rs can put this in the
        	# log, so that fail2ban can ban the correct IP.
		header_up X-Real-IP {remote_host}
	}

  	# Proxy the Root directory to Rocket
	reverse_proxy localhost:80 {
		# Send the true remote IP to Rocket, so that bitwarden_rs can put this in the
        	# log, so that fail2ban can ban the correct IP.
		header_up X-Real-IP {remote_host}
	}
}

Expected behaviour

The real client ip should show up in bitwardenrs log for websocket and regular logs.

Actual behaviour

The real client ip only shows up for regular logs, not for websocket logs. There the ip 172.19.0.1 shows up. (see below)

Relevant logs

pi@homepi:~/bitwarden $ docker-compose up
Starting bitwarden_bitwarden_1 ... done
Attaching to bitwarden_bitwarden_1
bitwarden_1  | /--------------------------------------------------------------------\
bitwarden_1  | |                       Starting Bitwarden_RS                        |
bitwarden_1  | |                           Version 1.19.0                           |
bitwarden_1  | |--------------------------------------------------------------------|
bitwarden_1  | | This is an *unofficial* Bitwarden implementation, DO NOT use the   |
bitwarden_1  | | official channels to report bugs/features, regardless of client.   |
bitwarden_1  | | Send usage/configuration questions or feature requests to:         |
bitwarden_1  | |   https://bitwardenrs.discourse.group/                             |
bitwarden_1  | | Report suspected bugs/issues in the software itself at:            |
bitwarden_1  | |   https://github.com/dani-garcia/bitwarden_rs/issues/new           |
bitwarden_1  | \--------------------------------------------------------------------/
bitwarden_1  | 
bitwarden_1  | [INFO] No .env file found.
bitwarden_1  | 
bitwarden_1  | [2021-02-20 12:02:26.191][parity_ws][INFO] Listening for new connections on 0.0.0.0:3012.
bitwarden_1  | [2021-02-20 12:02:26.198][start][INFO] Rocket has launched from http://0.0.0.0:80
bitwarden_1  | [2021-02-20 12:02:58.231][parity_ws::io][INFO] Accepted a new tcp connection from 172.19.0.1:47016.
bitwarden_1  | [2021-02-20 12:02:58.253][request][INFO] GET /api/sync?excludeDomains=true
bitwarden_1  | [2021-02-20 12:02:58.263][response][INFO] GET /api/sync?<data..> (sync) => 200 OK
bitwarden_1  | [2021-02-20 12:03:14.643][request][INFO] POST /api/accounts/prelogin
bitwarden_1  | [2021-02-20 12:03:14.646][response][INFO] POST /api/accounts/prelogin (prelogin) => 200 OK
bitwarden_1  | [2021-02-20 12:03:14.738][request][INFO] POST /identity/connect/token
bitwarden_1  | [2021-02-20 12:03:19.963][bitwarden_rs::api::identity][INFO] User XXX@gmail.com logged in successfully. IP: XXx.XXX.XXX.XXX
bitwarden_1  | [2021-02-20 12:03:19.964][response][INFO] POST /identity/connect/token (login) => 200 OK
bitwarden_1  | [2021-02-20 12:03:20.078][parity_ws::io][INFO] Accepted a new tcp connection from 172.19.0.1:47032.
bitwarden_1  | [2021-02-20 12:03:20.103][request][INFO] GET /api/sync?excludeDomains=true
bitwarden_1  | [2021-02-20 12:03:20.106][response][INFO] GET /api/sync?<data..> (sync) => 200 OK
Originally created by @mustaphazorgati on GitHub (Feb 20, 2021). Original GitHub issue: https://github.com/dani-garcia/vaultwarden/issues/1417 <!-- # ### NOTE: Please update to the latest version of bitwarden_rs before reporting an issue! This saves you and us a lot of time and troubleshooting. See: https://github.com/dani-garcia/bitwarden_rs/issues/1180 # ### --> <!-- Please fill out the following template to make solving your problem easier and faster for us. This is only a guideline. If you think that parts are unnecessary for your issue, feel free to remove them. Remember to hide/obfuscate personal and confidential information, such as names, global IP/DNS addresses and especially passwords, if necessary. --> ### Subject of the issue <!-- Describe your issue here.--> ### Your environment <!-- The version number, obtained from the logs or the admin diagnostics page --> <!-- Remember to check your issue on the latest version first! --> * Bitwarden_rs version: 1.19.0 <!-- How the server was installed: Docker image / package / built from source --> * Install method: Docker image * Clients used: web<!-- if applicable --> * Reverse proxy and version: caddy v2.3.0<!-- if applicable --> * Version of mysql/postgresql: <!-- if applicable --> * Other relevant information: ### Steps to reproduce <!-- Tell us how to reproduce this issue. What parameters did you set (differently from the defaults) and how did you start bitwarden_rs? --> start bitwarden normally and enable websocket. docker-compose file: ``` version: '3' services: bitwarden: image: bitwardenrs/server environment: WEBSOCKET_ENABLED: 'true' volumes: - bitwarden-data:/data ports: - 8005:80 - 3012:3012 volumes: bitwarden-data: ``` forward X-Real-IP from caddy to bitwardenrs caddy config: ``` https://<DOMAIN> { encode gzip header { # Enable HTTP Strict Transport Security (HSTS) Strict-Transport-Security max-age=31536000; # Enable cross-site filter (XSS) and tell browser to block detected attacks X-XSS-Protection "1; mode=block" # Disallow the site to be rendered within a frame (clickjacking protection) X-Frame-Options DENY # Prevent search engines from indexing (optional) X-Robots-Tag none # Server name removing -Server } # The negotiation endpoint is also proxied to Rocket reverse_proxy /notifications/hub/negotiate localhost:80 { # Send the true remote IP to Rocket, so that bitwarden_rs can put this in the # log, so that fail2ban can ban the correct IP. header_up X-Real-IP {remote_host} } # Notifications redirected to the websockets server reverse_proxy /notifications/hub localhost:3012 { # Send the true remote IP to websocket server, so that bitwarden_rs can put this in the # log, so that fail2ban can ban the correct IP. header_up X-Real-IP {remote_host} } # Proxy the Root directory to Rocket reverse_proxy localhost:80 { # Send the true remote IP to Rocket, so that bitwarden_rs can put this in the # log, so that fail2ban can ban the correct IP. header_up X-Real-IP {remote_host} } } ``` ### Expected behaviour <!-- Tell us what should happen --> The real client ip should show up in bitwardenrs log for websocket and regular logs. ### Actual behaviour <!-- Tell us what happens instead --> The real client ip only shows up for regular logs, not for websocket logs. There the ip `172.19.0.1` shows up. (see below) ### Relevant logs <!-- Share some logfiles, screenshots or output of relevant programs with us. --> ``` pi@homepi:~/bitwarden $ docker-compose up Starting bitwarden_bitwarden_1 ... done Attaching to bitwarden_bitwarden_1 bitwarden_1 | /--------------------------------------------------------------------\ bitwarden_1 | | Starting Bitwarden_RS | bitwarden_1 | | Version 1.19.0 | bitwarden_1 | |--------------------------------------------------------------------| bitwarden_1 | | This is an *unofficial* Bitwarden implementation, DO NOT use the | bitwarden_1 | | official channels to report bugs/features, regardless of client. | bitwarden_1 | | Send usage/configuration questions or feature requests to: | bitwarden_1 | | https://bitwardenrs.discourse.group/ | bitwarden_1 | | Report suspected bugs/issues in the software itself at: | bitwarden_1 | | https://github.com/dani-garcia/bitwarden_rs/issues/new | bitwarden_1 | \--------------------------------------------------------------------/ bitwarden_1 | bitwarden_1 | [INFO] No .env file found. bitwarden_1 | bitwarden_1 | [2021-02-20 12:02:26.191][parity_ws][INFO] Listening for new connections on 0.0.0.0:3012. bitwarden_1 | [2021-02-20 12:02:26.198][start][INFO] Rocket has launched from http://0.0.0.0:80 bitwarden_1 | [2021-02-20 12:02:58.231][parity_ws::io][INFO] Accepted a new tcp connection from 172.19.0.1:47016. bitwarden_1 | [2021-02-20 12:02:58.253][request][INFO] GET /api/sync?excludeDomains=true bitwarden_1 | [2021-02-20 12:02:58.263][response][INFO] GET /api/sync?<data..> (sync) => 200 OK bitwarden_1 | [2021-02-20 12:03:14.643][request][INFO] POST /api/accounts/prelogin bitwarden_1 | [2021-02-20 12:03:14.646][response][INFO] POST /api/accounts/prelogin (prelogin) => 200 OK bitwarden_1 | [2021-02-20 12:03:14.738][request][INFO] POST /identity/connect/token bitwarden_1 | [2021-02-20 12:03:19.963][bitwarden_rs::api::identity][INFO] User XXX@gmail.com logged in successfully. IP: XXx.XXX.XXX.XXX bitwarden_1 | [2021-02-20 12:03:19.964][response][INFO] POST /identity/connect/token (login) => 200 OK bitwarden_1 | [2021-02-20 12:03:20.078][parity_ws::io][INFO] Accepted a new tcp connection from 172.19.0.1:47032. bitwarden_1 | [2021-02-20 12:03:20.103][request][INFO] GET /api/sync?excludeDomains=true bitwarden_1 | [2021-02-20 12:03:20.106][response][INFO] GET /api/sync?<data..> (sync) => 200 OK ```
kerem 2026-03-03 02:04:55 +03:00
kerem commented 2026-03-03 02:04:57 +03:00
Author
Owner
Copy link

@BlackDex commented on GitHub (Feb 20, 2021):

Not sure if we can fix this. This is a message from a third party library.
They do not use these headers. Also not sure if they are willing to accept PR's for this, since they created this as a short term fix waiting for its upstream source to merge a PR.

<!-- gh-comment-id:782724176 --> @BlackDex commented on GitHub (Feb 20, 2021): Not sure if we can fix this. This is a message from a third party library. They do not use these headers. Also not sure if they are willing to accept PR's for this, since they created this as a short term fix waiting for its upstream source to merge a PR.
kerem commented 2026-03-03 02:04:57 +03:00
Author
Owner
Copy link

@stefan0xC commented on GitHub (Mar 13, 2021):

According to docs.rs/parity_ws the client_addr function looks for the X-Forwarded-For header to look up the IP of a client. So probably caddy does not implicitly set the right address. 172.19.0.1 looks like a docker address. Are you running caddy inside a container? Can you set this header manually?

<!-- gh-comment-id:798557037 --> @stefan0xC commented on GitHub (Mar 13, 2021): According to [docs.rs/parity_ws](https://docs.rs/parity-ws/0.10.0/parity_ws/) the [client_addr](https://docs.rs/parity-ws/0.10.0/parity_ws/struct.Request.html#method.client_addr) function looks for the `X-Forwarded-For` header to look up the IP of a client. So probably caddy does not implicitly set the right address. `172.19.0.1` looks like a docker address. Are you running caddy inside a container? Can you set this header manually?
kerem commented 2026-03-03 02:04:57 +03:00
Author
Owner
Copy link

@mustaphazorgati commented on GitHub (Mar 13, 2021):

Hey @stefan0xC,

thanks for your short reply. According to caddy's documentation the X-Forwarded-For header is set. I've tried to set that header manually, but that won't work.

Regarding the IP address: No, I am using bitwarden_rs with docker, not caddy.

<!-- gh-comment-id:798773303 --> @mustaphazorgati commented on GitHub (Mar 13, 2021): Hey @stefan0xC, thanks for your short reply. According to caddy's [documentation](https://caddyserver.com/docs/caddyfile/directives/reverse_proxy#headers) the `X-Forwarded-For` header is set. I've tried to set that header manually, but that won't work. Regarding the IP address: No, I am using bitwarden_rs with docker, not caddy.
kerem commented 2026-03-03 02:04:57 +03:00
Author
Owner
Copy link

@stefan0xC commented on GitHub (Mar 13, 2021):

@mustaphazorgati You are right. Sorry, I should have checked my own logs. (Because I have the same problem with nginx on host and bitwarden_rs.)

<!-- gh-comment-id:798779222 --> @stefan0xC commented on GitHub (Mar 13, 2021): @mustaphazorgati You are right. Sorry, I should have checked my own logs. (Because I have the same problem with nginx on host and bitwarden_rs.)
kerem commented 2026-03-03 02:04:57 +03:00
Author
Owner
Copy link

@ak2k commented on GitHub (Mar 15, 2021):

Does anyone with a better understanding of how this function is used in bitwarden_rs have a theory about why this isn't working as expected, given that the function is indeed documented to (and the source seems consistent with the documentation) pass the X-Forwarded-For header, yet doesn't seem to be doing so as used in bitwarden_rs?

<!-- gh-comment-id:799552304 --> @ak2k commented on GitHub (Mar 15, 2021): Does anyone with a better understanding of how this function is used in bitwarden_rs have a theory about why this isn't working as expected, given that the function is indeed documented to (and the source seems consistent with the documentation) pass the X-Forwarded-For header, yet doesn't seem to be doing so as used in bitwarden_rs?
kerem commented 2026-03-03 02:04:57 +03:00
Author
Owner
Copy link

@Masgalor commented on GitHub (Jun 7, 2021):

I do not know much about caddy, but would not the optimal solution be to add support for the (HA)proxy-protocol?

Link for reference Link

<!-- gh-comment-id:855792432 --> @Masgalor commented on GitHub (Jun 7, 2021): I do not know much about caddy, but would not the optimal solution be to add support for the (HA)proxy-protocol? Link for reference [Link](https://www.haproxy.com/blog/haproxy/proxy-protocol/)
kerem commented 2026-03-03 02:04:57 +03:00
Author
Owner
Copy link

@BlackDex commented on GitHub (Jun 7, 2021):

If you want to to be fixed, make sure that you add x-forwarded-for header at the reverse proxy.
The websocket library only supports that specific header.

<!-- gh-comment-id:855846294 --> @BlackDex commented on GitHub (Jun 7, 2021): If you want to to be fixed, make sure that you add `x-forwarded-for` header at the reverse proxy. The websocket library only supports that specific header.
kerem commented 2026-03-03 02:04:57 +03:00
Author
Owner
Copy link

@mustaphazorgati commented on GitHub (Jun 8, 2021):

@BlackDex: Caddy already sets that header automatically. See: https://caddyserver.com/docs/caddyfile/directives/reverse_proxy#headers

<!-- gh-comment-id:856527565 --> @mustaphazorgati commented on GitHub (Jun 8, 2021): @BlackDex: Caddy already sets that header automatically. See: https://caddyserver.com/docs/caddyfile/directives/reverse_proxy#headers
kerem commented 2026-03-03 02:04:57 +03:00
Author
Owner
Copy link

@BlackDex commented on GitHub (Jun 21, 2021):

Ok, i have checked the source code a bit better now, and that part of the code is not even used at all where i saw the x-fowarded-for header, it even has #[allow(dead_code)] defined there 🙄.

So, this is really not something we can fix, as this is all inside the provided library.
I have created a FAQ item at the WIKI. https://github.com/dani-garcia/vaultwarden/wiki/FAQs

<!-- gh-comment-id:865278032 --> @BlackDex commented on GitHub (Jun 21, 2021): Ok, i have checked the source code a bit better now, and that part of the code is not even used at all where i saw the `x-fowarded-for` header, it even has `#[allow(dead_code)]` defined there :roll_eyes:. So, this is really not something we can fix, as this is all inside the provided library. I have created a FAQ item at the WIKI. https://github.com/dani-garcia/vaultwarden/wiki/FAQs
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
revert-7033-patch-1
cached-config-operations
test_dylint
1.35.8
1.35.7
1.35.6
1.35.5
1.35.4
1.35.3
1.35.2
1.35.1
1.35.0
1.34.3
1.34.2
1.34.1
1.34.0
1.33.2
1.33.1
1.33.0
1.32.7
1.32.6
1.32.5
1.32.4
1.32.3
1.32.2
1.32.1
1.32.0
1.31.0
1.30.5
1.30.4
1.30.3
1.30.2
1.30.1
1.30.0
1.29.2
1.29.1
1.29.0
1.28.1
1.28.0
1.27.0
1.26.0
1.25.2
1.25.1
1.25.0
1.24.0
1.23.1
1.23.0
1.22.2
1.22.1
1.22.0
1.21.0
1.20.0
1.19.0
1.18.0
1.17.0
1.16.3
1.16.2
1.16.1
1.16.0
1.15.1
1.15.0
1.14.2
1.14.1
1.14
1.13.1
1.13.0
1.12.0
1.11.0
1.10.0
1.9.1
1.9.0
1.8.0
1.7.0
1.6.1
1.6.0
1.5.0
1.4.0
1.3.0
1.2.0
1.1.0
1.0.0
0.13.0
0.12.0
0.11.0
0.10.0
0.9.0
Labels
Clear labels   
SSO

   
Third party

   
better for forum

   
bug

   
bug

   
documentation

   
duplicate

   
enhancement

   
future Vault

   
future Vault

   
future Vault

   
good first issue

   
help wanted

   
low priority

   
notes

   
pull-request

Mirrored from GitHub Pull Request

  
question

   
troubleshooting

   
wontfix
No labels
SSO
Third party
better for forum
bug
bug
documentation
duplicate
enhancement
future Vault
future Vault
future Vault
good first issue
help wanted
low priority
notes
pull-request
question
troubleshooting
wontfix
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/vaultwarden#948
No description provided.