starred/vaultwarden
1
0
Fork 0
mirror of https://github.com/dani-garcia/vaultwarden.git synced 2025-12-11 09:13:02 +03:00
Code Issues 429 Packages Projects Releases 10 Wiki Activity

Actual client ip for websocket connections not showing up in logs #1471

New Issue
Closed
opened 2025-10-09 17:16:25 +03:00 by OVERLORD · 9 comments
OVERLORD commented 2025-10-09 17:16:25 +03:00
Owner
Copy Link

Originally created by @mustaphazorgati on GitHub.

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. <!-- # ### 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 ```
OVERLORD added the low priorityThird party labels 2025-10-09 17:16:25 +03:00
OVERLORD commented 2025-10-09 17:16:27 +03:00
Author
Owner
Copy Link

@stefan0xC commented on GitHub:

@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.)

@stefan0xC commented on GitHub: @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.)
OVERLORD commented 2025-10-09 17:16:28 +03:00
Author
Owner
Copy Link

@mustaphazorgati commented on GitHub:

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.

@mustaphazorgati commented on GitHub: 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.
OVERLORD commented 2025-10-09 17:16:28 +03:00
Author
Owner
Copy Link

@stefan0xC commented on GitHub:

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?

@stefan0xC commented on GitHub: 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?
OVERLORD commented 2025-10-09 17:16:28 +03:00
Author
Owner
Copy Link

@ak2k commented on GitHub:

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?

@ak2k commented on GitHub: 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?
OVERLORD commented 2025-10-09 17:16:29 +03:00
Author
Owner
Copy Link

@BlackDex commented on GitHub:

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.

@BlackDex commented on GitHub: 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.
OVERLORD commented 2025-10-09 17:16:30 +03:00
Author
Owner
Copy Link

@BlackDex commented on GitHub:

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.

@BlackDex commented on GitHub: 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.
OVERLORD commented 2025-10-09 17:16:30 +03:00
Author
Owner
Copy Link

@Masgalor commented on GitHub:

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

@Masgalor commented on GitHub: 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/)
OVERLORD commented 2025-10-09 17:16:30 +03:00
Author
Owner
Copy Link

@mustaphazorgati commented on GitHub:

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

@mustaphazorgati commented on GitHub: @BlackDex: Caddy already sets that header automatically. See: https://caddyserver.com/docs/caddyfile/directives/reverse_proxy#headers
OVERLORD commented 2025-10-09 17:16:30 +03:00
Author
Owner
Copy Link

@BlackDex commented on GitHub:

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

@BlackDex commented on GitHub: 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
Labels
Clear labels
better for forum
bug
bug
bug
documentation
duplicate
enhancement
future Vault
good first issue
help wanted
low priority
notes
pull-request
Mirrored from GitHub Pull Request
 question
SSO
Third party
troubleshooting
troubleshooting
wontfix
No Label low priority Third party
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
OVERLORD
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/vaultwarden#1471
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?