Problems with connecting to Vaultwarden instance through the Windows and Android application.

[FabianMeijneken]

Hi everyone, I recently set up a Vaultwarden instance and am using a Cloudflare tunnel to access it from outside of my network. When going to the web page it works flawlessly, same with the Firefox browser extension. I am, however, experiencing problems when trying to access the vault through the Windows or Android application.

I am on the latest version of Vaultwarden and have the latest version of the Bitwarden applications installed. For android I tested the version on the play store and the latest version from the GitHub repository.
The requests made by the web vault seems to make a GET request to /api/organizations/undefined/policies/token, and gets through the tunnel no problem.

The Android an Windows application make a POST request to /identity/connect/token and/identity/connect/token. Those requests do not get blocked by cloudflare but don’t make it into the tunnel. I know this by checking the security logs for my domain in cloudflare and checking the Live logs for the tunnel.

A discussion i found linked to this Bitwarden discussion topic, on that discussion the problem was blamed on a change in Let’s Encrypt's chain of trust. This change brought problems for older devices, but that isn’t the case in my situation. I am running om a Pixel 8a.

In another discussion the cert chain was marked as a potential problem. I am pretty certain that my cert chain is good, so that shouldn't be a problem.

Does anyone have any ideas about what the problem could be?
Thanks in advance!

Windows error

Android error

The android error says "An error has occurred. We were unable to process your request. Please try again or contact us."

Your environment (Generated via diagnostics page)

• Vaultwarden version: v1.32.7
• Web-vault version: v2024.6.2c
• OS/Arch: linux/aarch64
• Running within a container: true (Base: Debian)
• Database type: SQLite
• Database version: 3.46.0
• Environment settings overridden!: true
• Uses a reverse proxy: true
• IP Header check: false (X-Forwarded-For)
• Internet access: true
• Internet access via a proxy: false
• DNS Check: true
• Browser/Server Time Check: true
• Server/NTP Time Check: true
• Domain Configuration Check: false
• HTTPS Check: false
• Websocket Check: true
• HTTP Response Checks: true

Config & Details (Generated via diagnostics page)

Show Config & Details

Environment settings which are overridden: ADMIN_TOKEN

Config:

{
  "_duo_akey": null,
  "_enable_duo": true,
  "_enable_email_2fa": false,
  "_enable_smtp": true,
  "_enable_yubico": true,
  "_icon_service_csp": "",
  "_icon_service_url": "",
  "_ip_header_enabled": true,
  "_max_note_size": 10000,
  "_smtp_img_src": "***:",
  "admin_ratelimit_max_burst": 3,
  "admin_ratelimit_seconds": 300,
  "admin_session_lifetime": 20,
  "admin_token": "***",
  "allowed_connect_src": "",
  "allowed_iframe_ancestors": "",
  "attachments_folder": "data/attachments",
  "auth_request_purge_schedule": "30 * * * * *",
  "authenticator_disable_time_drift": false,
  "data_folder": "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_context_purge_schedule": "30 * * * * *",
  "duo_host": null,
  "duo_ikey": null,
  "duo_skey": null,
  "duo_use_iframe": false,
  "email_2fa_auto_fallback": false,
  "email_2fa_enforce_on_verified_invite": false,
  "email_attempts_limit": 3,
  "email_change_allowed": true,
  "email_expiration_time": 600,
  "email_token_size": 6,
  "emergency_access_allowed": true,
  "emergency_notification_reminder_schedule": "0 3 * * * *",
  "emergency_request_timeout_schedule": "0 7 * * * *",
  "enable_db_wal": true,
  "enable_websocket": true,
  "enforce_single_org_with_reset_pw_policy": false,
  "event_cleanup_schedule": "0 10 0 * * *",
  "events_days_retain": null,
  "experimental_client_feature_flags": "fido2-vault-credentials",
  "extended_logging": true,
  "helo_name": null,
  "hibp_api_key": null,
  "http_request_block_non_global_ips": true,
  "http_request_block_regex": null,
  "icon_blacklist_non_global_ips": true,
  "icon_blacklist_regex": null,
  "icon_cache_folder": "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,
  "increase_note_size_limit": false,
  "invitation_expiration_hours": 120,
  "invitation_org_name": "Vaultwarden",
  "invitations_allowed": true,
  "ip_header": "X-Real-IP",
  "job_poll_interval_ms": 30000,
  "log_file": null,
  "log_level": "info",
  "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": "",
  "org_events_enabled": false,
  "org_groups_enabled": false,
  "password_hints_allowed": true,
  "password_iterations": 600000,
  "push_enabled": false,
  "push_identity_uri": "https://identity.bitwarden.com",
  "push_installation_id": "***",
  "push_installation_key": "***",
  "push_relay_uri": "https://push.bitwarden.com",
  "reload_templates": false,
  "require_device_email": false,
  "rsa_key_filename": "data/rsa_key",
  "send_purge_schedule": "0 5 * * * *",
  "sendmail_command": null,
  "sends_allowed": true,
  "sends_folder": "data/sends",
  "show_password_hint": false,
  "signups_allowed": false,
  "signups_domains_whitelist": "",
  "signups_verify": false,
  "signups_verify_resend_limit": 6,
  "signups_verify_resend_time": 3600,
  "smtp_accept_invalid_certs": false,
  "smtp_accept_invalid_hostnames": false,
  "smtp_auth_mechanism": null,
  "smtp_debug": false,
  "smtp_embed_images": true,
  "smtp_explicit_tls": null,
  "smtp_from": "",
  "smtp_from_name": "Vaultwarden",
  "smtp_host": null,
  "smtp_password": null,
  "smtp_port": 587,
  "smtp_security": "starttls",
  "smtp_ssl": null,
  "smtp_timeout": 15,
  "smtp_username": null,
  "templates_folder": "data/templates",
  "tmp_folder": "data/tmp",
  "trash_auto_delete_days": null,
  "trash_purge_schedule": "0 5 0 * * *",
  "use_sendmail": false,
  "use_syslog": false,
  "user_attachment_limit": null,
  "user_send_limit": null,
  "web_vault_enabled": true,
  "web_vault_folder": "web-vault/",
  "yubico_client_id": null,
  "yubico_secret_key": null,
  "yubico_server": null
}

[eociar]

I've got the same message with Bitwarden client app on Samsung S22 ultra and Samsung Tablet S7 since yesterday.
Before, everything ran well for months. As far as I rememeber, there was no update of the Bitwarden client app on the two devices.

I am running a self-hosted Vaultwarden server (docker container, using traefik with letsencrypt, no cloudflare).
The Windows client app is working well (2024.12.1 and latest 2025.1.1).
Also access via brower (Chrome) is possible on all devices.
Bitwarden client app on iPhone is working, too.

Renewal of Letsencrypt certificates didn't help.
Wiping cache on phone or even uninstall/reinstall Bitwarden client app did not solve the problem.

[KuntzeM]

Hi,
I had the same problem on two phones.
Do you have the newest vaultwarden/server installed?
I updated my docker vaultwarden from 1.32.2 to 1.32.7. Now it's working again.

[FabianMeijneken]

Yes I do, this is confirmed by the vaultwarden diagnostics page.

[BlackDex]

The testing branch has some fixes the latest doesn't, and might solve your issues

[eociar]

Updating vaultwarden to V1.32.7 solved my problems, too.

[4m3r7h157dr460n]

I have a self-hosted version I have run into this issue but I have installed it via CasaOS the problem is I don't know who is responsible for that installation process as the Vaultwarden Web
Version 2023.10.0. Any and all help is welcomed the android app Is Version: 2025.1.0 (19622) I have the bitwarden app on my iPad and it works and running version: 2025.1.0 (1790)

[Gerardv514]

2023.10 is very old. You need to update.

[4m3r7h157dr460n]

2023.10 is very old. You need to update.

I know this I need to find out who is responsible for the CasaOS version and yes I have sent a message on their chosen channel discord

[FabianMeijneken]

@BlackDex

The testing branch has some fixes the latest doesn't, and might solve your issues

Unfortunately this did not fix the issue.

For clarification, the requests made by the Bitwarden android application do not go through the tunnel, and don't reach the Vaultwarden instance i am hosting.

I did notice another interesting thing, the requests made by the web application of Vaultwarden and the Firefox addon show up as HTTP/3 in Cloudflare. All the requests from the Android application show up as HTTP/2. Could this be an issue?

[sjmf]

I also started encountering Android app issues (as of 1.32.7, although perhaps co-incidentally?) and I'm currently trying to narrow down whether it's a configuration issue on my end. Phone is a Google Pixel 7a.

I first hit the issue with self-hosted Vaultwarden (release 1.32.7) and the Bitwarden Android app version 2025.1.0. My Vaultwarden docker container sits behind a traefik reverse proxy which handles the TLS certificates etc. I have no Cloudflare in my setup.

The error message given by the Bitwarden Android app in English is: "We were unable to process your request. Please try again or contact us". This is practically useless for diagnosis so if anyone knows of any way to get actually meaningful logs out of the Android app, I'd love to know!

Examining the logs in the Vaultwarden docker container, I too suspect that requests aren't getting through to the container for some reason or another: I can load the web vault just fine, and I see the HTTP requests from my browser, but configuring a self-hosted instance in the Bitwarden Android app and attempting to log in doesn't seem to result in any requests being logged server-side. This perhaps lends weight to the HTTP/3 theory? I will see if I can adjust my Traefik configuration to support v3.

There's an issue posted by a user on the official Bitwarden mobile repository which may be related: bitwarden/mobile#3453 One user seemed to think it might be a certificate verification issue, but didn't elaborate. I've also verified that the Android app can log in with my old account to the bitwarden.com hosted instance, hoping to rule out network issues with my phone.

Restarting the server-side application didn't seem to have any appreciable effect. I also tried downgrading the Android app using the APKs to the Android app versions 2024.12.0; and 2024.11.7 from bitwarden/android/tags, and have tried downgrading the Vaultwarden container incrementally as far as 1.32.2. Downgrading didn't seem to improve the situation, and I've also tried upgrading to the 'testing' tag.

So, I'm skeptical as to whether there's a Vaultwarden or even Bitwarden app code change actually at fault here, but also perplexed as my self-hosted instance has been running stably and happily for the better part of two years.

[sjmf]

Just a reply back to say that while trying to diagnose the problem, I port-forwarded Vaultwarden to a high port (50080) for testing a direct HTTP connection without the traefik stack. After verifying that I could see the requests in the log when made directly to that port, I tried my usual setup via traefik again, and, mysteriously... it just started working again. I don't believe I've changed any configuration of note, but the container restart seems to have worked this time, as others have reported. The whole issue seems oddly intermittent. I'll bookmark this thread and report back if it dies again, I guess?!

[kpfleming]

For what it's worth, I have version 2025.1.0 of the Android app on an Android 14 (OxygenOS) device, connecting to Vaultwarden 1.32.7 (built from source). VW is behind an NGINX reverse proxy. Connections work fine, I'm able to sync without problems, and logout/login (using a Yubikey NEO plugged into the phone). Based on that sample, it appears that this issue is being caused by some sort of networking configuration between Android and Vaultwarden.

[FabianMeijneken]

Check, thanks for the sample. Like you said I think it has something to do with Cloudflare. This is proven by the fact that the requests aren't going into the tunnel... They do reach Cloudflare, do not get mitigated by WAF, but don't get sent through the tunnel to my Docker container.

[eociar]

I just updated my vaultwarden docker container to image V1.32.7 and I can access it again via Andoid Bitwarden clients on both devices (Samsung Galaxy S22 ultra and Galaxy Tab S7), that failed before. I did not change anything on the Android devices or traefik-settings or Letsencrypt certification.
My versions are now:
Vaultwarden docker image V1.32.7
Bitwarden Android client app V2025.1.0
Traefik docker image V3.1.0

[FabianMeijneken]

Hi everyone,

After a bit more testing I have found something intresting.
I thought the problem could be related to HTTP/2 or HTTP/3 requests, but after some more testing it utrns out not only HTTP/2 requests are blocked, but some HTTP/3 requests aswell. I am making HTTP/3 requests from a browser and a windows application, of which the browser functions well, but the windows application doesn’t get through. My HTTP/2 requests are comming from an Android phone

The other thing besides HTTP version that differentiates the requests I am doing is the User Agent.

This is an example from a working request (made from the web application) (HTTP/3):
Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:134.0) Gecko/20100101 Firefox/134.0

This is an example from a non working request (made from the windows application)(HTTP/3):
Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/128.0.6613.137 Safari/537.36

Could this be the reason some of the requests make it into the tunnel and some don’t?

[BlackDex]

That is something to ask your tunnel provider i guess, and not something we can answer.

Vaultwarden only supports HTTP/1.1 and not HTTP/2 or HTTP/3.
If you do not use websocket connections, then HTTP/1.0 is probably ok too.

On my own server I have HTTP/2 and HTTP/3 working for Vaultwarden just fine. Nginx uses HTTP/1.1 to talk to the Vaultwarden instance and keeps the communication with the clients in the other protocols where possible, and uses HTTP/1.1 for the websocket connection.

[FabianMeijneken]

Thanks, I was hoping someone here has had the same problem and has found a solution. That's why I asked the question on this repository.
I am currently also posting on the Cloudflare community page, if I find a solution I will post it here.

Thanks, for the help!

[FabianMeijneken]

After lots of video’s and forums I finally figured it out. In my tunnel’s public hostnames I have the public hostname setup as an HTTP service. This means the TLS opstions are disabled. The simple fix for this problem was switching to an HTTPS service type, changing the HTTP2 connection under TLS settings to on. After that I set the service type back to HTTP, otherwise the application would not function.

It was, like suspected, an issue with my cloudflare setup. After changing the setting the tunnel works like a charm. A simple yet so frustrating solution.

Thanks for the help everyone!