github-starred/vaultwarden
2
0
Fork 0
mirror of https://github.com/dani-garcia/vaultwarden.git synced 2026-03-25 15:50:21 -05:00
Code Issues 79 Packages Projects Releases 78 Wiki Activity

vaultwarden attempts postgresql connection with SLAAC address, not the websocket address #4928

New Issue
Closed
opened 2026-03-07 20:06:57 -06:00 by GiteaMirror · 3 comments
GiteaMirror commented 2026-03-07 20:06:57 -06:00
Owner
Copy Link

Originally created by @DerVerruckteFuchs on GitHub (May 29, 2022).

Subject of the issue

vaultwarden attempts potsgresql connection with SLAAC address, not the configured websocket address

Deployment environment

Your environment (Generated via diagnostics page)

  • Vaultwarden version: v1.25.0
  • Web-vault version: v2.28.1
  • Running within Docker: false (Base: Alpine)
  • Environment settings overridden: false
  • Uses a reverse proxy: true
  • IP Header check: true (X-Real-IP)
  • Internet access: true
  • Internet access via a proxy: false
  • DNS Check: true
  • Time Check: true
  • Domain Configuration Check: true
  • HTTPS Check: true
  • Database type: PostgreSQL
  • Database version: PostgreSQL 14.3 on x86_64-alpine-linux-musl, compiled by gcc (Alpine 10.3.1_git20211027) 10.3.1 20211027, 64-bit
  • Clients used: web vault, Android, browser extension
  • Reverse proxy and version: Nginx 1.20.2
  • Other relevant information: run as LXC container on proxmox

Config (Generated via diagnostics page)

Show Running Config

Environment settings which are overridden:

{
  "_duo_akey": null,
  "_enable_duo": false,
  "_enable_email_2fa": true,
  "_enable_smtp": true,
  "_enable_yubico": true,
  "_ip_header_enabled": true,
  "admin_ratelimit_max_burst": 3,
  "admin_ratelimit_seconds": 300,
  "admin_token": "***",
  "allowed_iframe_ancestors": "",
  "attachments_folder": "/var/www/vaultwarden/data/attachments",
  "authenticator_disable_time_drift": false,
  "data_folder": "/var/www/vaultwarden/data",
  "database_conn_init": "",
  "database_max_conns": 10,
  "database_timeout": 30,
  "database_url": "**********://***************:********************************+**********=@[****:****:****:****::**]:****/*********",
  "db_connection_retries": 15,
  "disable_2fa_remember": false,
  "disable_admin_token": false,
  "disable_icon_download": false,
  "domain": "*****://*********.*******.***",
  "domain_origin": "*****://*********.*******.***",
  "domain_path": "",
  "domain_set": true,
  "duo_host": null,
  "duo_ikey": null,
  "duo_skey": null,
  "email_attempts_limit": 3,
  "email_expiration_time": 600,
  "email_token_size": 6,
  "emergency_access_allowed": true,
  "emergency_notification_reminder_schedule": "0 5 * * * *",
  "emergency_request_timeout_schedule": "0 5 * * * *",
  "enable_db_wal": true,
  "extended_logging": true,
  "helo_name": "*********.*******.***",
  "hibp_api_key": null,
  "icon_blacklist_non_global_ips": true,
  "icon_blacklist_regex": null,
  "icon_cache_folder": "/var/www/vaultwarden/data/icon_cache",
  "icon_cache_negttl": 259200,
  "icon_cache_ttl": 2592000,
  "icon_download_timeout": 10,
  "icon_redirect_code": 302,
  "icon_service": "internal",
  "incomplete_2fa_schedule": "30 * * * * *",
  "incomplete_2fa_time_limit": 3,
  "invitation_org_name": "vaultwarden",
  "invitations_allowed": true,
  "ip_header": "X-Real-IP",
  "job_poll_interval_ms": 30000,
  "log_file": null,
  "log_level": "Error",
  "log_timestamp_format": "%Y-%m-%d %H:%M:%S.%3f",
  "login_ratelimit_max_burst": 10,
  "login_ratelimit_seconds": 60,
  "org_attachment_limit": null,
  "org_creation_users": "",
  "password_iterations": 100000,
  "reload_templates": false,
  "require_device_email": false,
  "rsa_key_filename": "/var/www/vaultwarden/data/rsa_key",
  "send_purge_schedule": "0 5 * * * *",
  "sends_allowed": true,
  "sends_folder": "/var/www/vaultwarden/data/sends",
  "show_password_hint": true,
  "signups_allowed": false,
  "signups_domains_whitelist": "",
  "signups_verify": true,
  "signups_verify_resend_limit": 6,
  "signups_verify_resend_time": 3600,
  "smtp_accept_invalid_certs": false,
  "smtp_accept_invalid_hostnames": false,
  "smtp_auth_mechanism": "Login",
  "smtp_debug": false,
  "smtp_explicit_tls": true,
  "smtp_from": "*******@*********.*******.***",
  "smtp_from_name": "vaultwarden",
  "smtp_host": "****.*******.***",
  "smtp_password": "***",
  "smtp_port": 465,
  "smtp_security": "force_tls",
  "smtp_ssl": true,
  "smtp_timeout": 15,
  "smtp_username": "**********@*********.*******.***",
  "templates_folder": "/var/www/vaultwarden/data/templates",
  "tmp_folder": "/var/www/vaultwarden/data/tmp",
  "trash_auto_delete_days": null,
  "trash_purge_schedule": "0 5 0 * * *",
  "use_syslog": false,
  "user_attachment_limit": null,
  "web_vault_enabled": true,
  "web_vault_folder": "/var/www/vaultwarden/web-vault",
  "websocket_address": "****:****:****:****::**",
  "websocket_enabled": true,
  "websocket_port": 3012,
  "yubico_client_id": null,
  "yubico_secret_key": null,
  "yubico_server": null
}

Steps to reproduce

  1. Configure vaultwarden to connect to postgresql database via IPv6.
  2. Start vaultwarden.

Expected behaviour

Vaultwarden starts and connects to postgresql database normally.

Actual behaviour

Vaultwarden fails to connect to postgresql database, since it is using the wrong IPv6 address.

Troubleshooting data

I'm using pfsense for my router. When I have my server subnet use "Unmanaged" RA mode (SLAAC, I think), then my vaultwarden server gets a SLAAC IP along with the static address I've configured. For whatever reason vaultwarden uses the SLAAC address, instead of the static websocket address, for the database connection. When setting the server subnet to "Router Only" RA mode (no SLAAC, just advertise router info), then my vaultwarden server only gets the static IP address I assigned it. The "Router Only" mode works as a workaround, but it would be preferable that the websocket IP is used for connecting to the database. Another option is a config option to set which IP to use when connecting to the database.

I've only permitted specific hosts to connect to my postgresql database, so that is why my vaultwarden server fails to connect with the SLAAC address. The behavior is rather unexpected, as I assumed it would connect with the configured websocket address. Nextcloud, among other services I self-host, connects with the IP I set in the relevant config files.

Edit: subdomain -> subnet

Originally created by @DerVerruckteFuchs on GitHub (May 29, 2022). ### Subject of the issue vaultwarden attempts potsgresql connection with SLAAC address, not the configured websocket address ### Deployment environment ### Your environment (Generated via diagnostics page) * Vaultwarden version: v1.25.0 * Web-vault version: v2.28.1 * Running within Docker: false (Base: Alpine) * Environment settings overridden: false * Uses a reverse proxy: true * IP Header check: true (X-Real-IP) * Internet access: true * Internet access via a proxy: false * DNS Check: true * Time Check: true * Domain Configuration Check: true * HTTPS Check: true * Database type: PostgreSQL * Database version: PostgreSQL 14.3 on x86_64-alpine-linux-musl, compiled by gcc (Alpine 10.3.1_git20211027) 10.3.1 20211027, 64-bit * Clients used: web vault, Android, browser extension * Reverse proxy and version: Nginx 1.20.2 * Other relevant information: run as LXC container on proxmox ### Config (Generated via diagnostics page) <details><summary>Show Running Config</summary> **Environment settings which are overridden:** ```json { "_duo_akey": null, "_enable_duo": false, "_enable_email_2fa": true, "_enable_smtp": true, "_enable_yubico": true, "_ip_header_enabled": true, "admin_ratelimit_max_burst": 3, "admin_ratelimit_seconds": 300, "admin_token": "***", "allowed_iframe_ancestors": "", "attachments_folder": "/var/www/vaultwarden/data/attachments", "authenticator_disable_time_drift": false, "data_folder": "/var/www/vaultwarden/data", "database_conn_init": "", "database_max_conns": 10, "database_timeout": 30, "database_url": "**********://***************:********************************+**********=@[****:****:****:****::**]:****/*********", "db_connection_retries": 15, "disable_2fa_remember": false, "disable_admin_token": false, "disable_icon_download": false, "domain": "*****://*********.*******.***", "domain_origin": "*****://*********.*******.***", "domain_path": "", "domain_set": true, "duo_host": null, "duo_ikey": null, "duo_skey": null, "email_attempts_limit": 3, "email_expiration_time": 600, "email_token_size": 6, "emergency_access_allowed": true, "emergency_notification_reminder_schedule": "0 5 * * * *", "emergency_request_timeout_schedule": "0 5 * * * *", "enable_db_wal": true, "extended_logging": true, "helo_name": "*********.*******.***", "hibp_api_key": null, "icon_blacklist_non_global_ips": true, "icon_blacklist_regex": null, "icon_cache_folder": "/var/www/vaultwarden/data/icon_cache", "icon_cache_negttl": 259200, "icon_cache_ttl": 2592000, "icon_download_timeout": 10, "icon_redirect_code": 302, "icon_service": "internal", "incomplete_2fa_schedule": "30 * * * * *", "incomplete_2fa_time_limit": 3, "invitation_org_name": "vaultwarden", "invitations_allowed": true, "ip_header": "X-Real-IP", "job_poll_interval_ms": 30000, "log_file": null, "log_level": "Error", "log_timestamp_format": "%Y-%m-%d %H:%M:%S.%3f", "login_ratelimit_max_burst": 10, "login_ratelimit_seconds": 60, "org_attachment_limit": null, "org_creation_users": "", "password_iterations": 100000, "reload_templates": false, "require_device_email": false, "rsa_key_filename": "/var/www/vaultwarden/data/rsa_key", "send_purge_schedule": "0 5 * * * *", "sends_allowed": true, "sends_folder": "/var/www/vaultwarden/data/sends", "show_password_hint": true, "signups_allowed": false, "signups_domains_whitelist": "", "signups_verify": true, "signups_verify_resend_limit": 6, "signups_verify_resend_time": 3600, "smtp_accept_invalid_certs": false, "smtp_accept_invalid_hostnames": false, "smtp_auth_mechanism": "Login", "smtp_debug": false, "smtp_explicit_tls": true, "smtp_from": "*******@*********.*******.***", "smtp_from_name": "vaultwarden", "smtp_host": "****.*******.***", "smtp_password": "***", "smtp_port": 465, "smtp_security": "force_tls", "smtp_ssl": true, "smtp_timeout": 15, "smtp_username": "**********@*********.*******.***", "templates_folder": "/var/www/vaultwarden/data/templates", "tmp_folder": "/var/www/vaultwarden/data/tmp", "trash_auto_delete_days": null, "trash_purge_schedule": "0 5 0 * * *", "use_syslog": false, "user_attachment_limit": null, "web_vault_enabled": true, "web_vault_folder": "/var/www/vaultwarden/web-vault", "websocket_address": "****:****:****:****::**", "websocket_enabled": true, "websocket_port": 3012, "yubico_client_id": null, "yubico_secret_key": null, "yubico_server": null } ``` </details> ### Steps to reproduce <!-- Tell us how to reproduce this issue. What parameters did you set (differently from the defaults) and how did you start vaultwarden? --> 1. Configure vaultwarden to connect to postgresql database via IPv6. 2. Start vaultwarden. ### Expected behaviour Vaultwarden starts and connects to postgresql database normally. ### Actual behaviour Vaultwarden fails to connect to postgresql database, since it is using the wrong IPv6 address. ### Troubleshooting data I'm using pfsense for my router. When I have my server subnet use "Unmanaged" RA mode (SLAAC, I think), then my vaultwarden server gets a SLAAC IP along with the static address I've configured. For whatever reason vaultwarden uses the SLAAC address, instead of the static websocket address, for the database connection. When setting the server subnet to "Router Only" RA mode (no SLAAC, just advertise router info), then my vaultwarden server only gets the static IP address I assigned it. The "Router Only" mode works as a workaround, but it would be preferable that the websocket IP is used for connecting to the database. Another option is a config option to set which IP to use when connecting to the database. I've only permitted specific hosts to connect to my postgresql database, so that is why my vaultwarden server fails to connect with the SLAAC address. The behavior is rather unexpected, as I assumed it would connect with the configured websocket address. Nextcloud, among other services I self-host, connects with the IP I set in the relevant config files. Edit: subdomain -> subnet
GiteaMirror added the questiontroubleshooting labels 2026-03-07 20:06:57 -06:00
GiteaMirror commented 2026-03-07 20:06:58 -06:00
Author
Owner
Copy Link

@BlackDex commented on GitHub (May 29, 2022):

I'm not sure what you mean here, web-sockets have nothing to do specifically with database connections.

Vaultwarden is running on the default interface of the host. If you want the application to only be accessible from/to a specific IP address i suggest to configure Vaultwarden to only listen on that specific address. You can configure Vaultwarden to use a specific address via ROCKET_ADDRESS, the same goes for the web-sockets btw via WEBSOCKET_ADDRESS.

Vaultwarden as (most) any other application does not determine the route, interface or outgoing IP address it self, that is all done by the OS/Host. So I'm not sure what you would expect from us.

If you configure a a specific IP address (that may be v4 or v6) as your database IP address, then Vaultwarden will use that IP address to connect to it. Again, how that connection is established is not determined by Vaultwarden it self, it just uses the Host/OS Network Stack.

I would first check what happens if you try to connect to the database manually from the same LXC container you are running Vaultwarden on and if you are able to connect or not.

@BlackDex commented on GitHub (May 29, 2022): I'm not sure what you mean here, web-sockets have nothing to do specifically with database connections. Vaultwarden is running on the default interface of the host. If you want the application to only be accessible from/to a specific IP address i suggest to configure Vaultwarden to only listen on that specific address. You can configure Vaultwarden to use a specific address via `ROCKET_ADDRESS`, the same goes for the web-sockets btw via `WEBSOCKET_ADDRESS`. Vaultwarden as (most) any other application does not determine the route, interface or outgoing IP address it self, that is all done by the OS/Host. So I'm not sure what you would expect from us. If you configure a a specific IP address (that may be v4 or v6) as your database IP address, then Vaultwarden will use that IP address to connect to it. Again, how that connection is established is not determined by Vaultwarden it self, it just uses the Host/OS Network Stack. I would first check what happens if you try to connect to the database manually from the same LXC container you are running Vaultwarden on and if you are able to connect or not.
GiteaMirror commented 2026-03-07 20:06:59 -06:00
Author
Owner
Copy Link

@DerVerruckteFuchs commented on GitHub (May 29, 2022):

I have set bothWEBSOCKET_ADDRESS and ROCKET_ADDRESS. My setup has worked fine with IPv4 for months now. The issue came up when I tried IPv6 addresses recently. The static IPv6 address works fine with the websocket and rocket. The connection from vaultwarden to the database is wonky. Vaultwarden tries to connect to the database with the SLAAC address, then fails, and does not even try connecting with the static address. Both the SLAAC and static addresses are available to vaultwarden.

Preventing the vaultwarden LXC container from getting a SLAAC address only leaves vaultwarden with a single static IPv6 address to use, then it works fine. I have applied it as a workaround on my subnet, and it works pretty well.

It just seems that vaultwarden is using whichever IP it feels like for the client side of the database connection if it has more than one to pick from. It does use the correct host IP for the database.

@DerVerruckteFuchs commented on GitHub (May 29, 2022): I have set both`WEBSOCKET_ADDRESS` and `ROCKET_ADDRESS`. My setup has worked fine with IPv4 for months now. The issue came up when I tried IPv6 addresses recently. The static IPv6 address works fine with the websocket and rocket. The connection from vaultwarden to the database is wonky. Vaultwarden tries to connect to the database with the SLAAC address, then fails, and does not even try connecting with the static address. Both the SLAAC and static addresses are available to vaultwarden. Preventing the vaultwarden LXC container from getting a SLAAC address only leaves vaultwarden with a single static IPv6 address to use, then it works fine. I have applied it as a workaround on my subnet, and it works pretty well. It just seems that vaultwarden is using whichever IP it feels like for the client side of the database connection if it has more than one to pick from. It does use the correct host IP for the database.
GiteaMirror commented 2026-03-07 20:06:59 -06:00
Author
Owner
Copy Link

@BlackDex commented on GitHub (May 29, 2022):

Again, Vaultwarden or any library it's using isn't going to select an interface it self. The host will determine the best path on a number of metrics. Stuff like router position, subnet maybe even interface order.
You can check with ip route get which path the os will take.

It's all up to the os not per application (by default)

@BlackDex commented on GitHub (May 29, 2022): Again, Vaultwarden or any library it's using isn't going to select an interface it self. The host will determine the best path on a number of metrics. Stuff like router position, subnet maybe even interface order. You can check with `ip route get` which path the os will take. It's all up to the os not per application (by default)
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
better for forum
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
wontfix
No Label question troubleshooting
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/vaultwarden#4928
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?