Add-On doesen’t recognize internal URLs behind reverse proxy?

Does the domain name contain any non-ASCII characters (e.g., umlauts)?

Nope.

I also updated to Version 2022.10.0, tried different clients, other login forms.

I can’t pinpoint anything special to those affected sites/forms compared to the other ones that work without problems.

But I’ve noticed that only internal sites that aren’t public are affected.

Strange. Just a random idea: if those internal domains have static IP addresses on your internal network, trying adding the IP address as an additional URI.

They are all behind internal reverse proxies (apache or nginx).

I just noticed that your URI starts with http instead of https. Is this really correct for your environment ?

Yes this is correct, gitlab (now using gitea) is one of the few applications that are not behind the reverse proxy. What’s interesting though, is that if I use the IP to access these internal applications, bitwarden recognizes the host credentials correctly!

I reproduced this with gitea and another application. So it has to be some issue with the bitwarden extension not being able to lookup the local DNS from the machine/browser. The DNS is configured on the docker host where bitwarden is located and I can nslookup gitea without problems.

Can anyone else test/confirm/reproduce this on their internal sites?

I think Peter may be onto something that would be worth testing further. Can you test what happens if you change the stored URI from http:gitlab... https:gitlab...? If your server is not using SSL, the browser should redirect to the http: page, but perhaps this will help Bitwarden recognize the URL?

Another option to try: Use Host or Regexp options for the URI matching (instead of your default Begins With).

Just tested setting the URLS form http to https, didn’t solve anything.

I will try the Regex solution on monday.

Very late update, but I tried regex with ^gitlab$ and host, same thing, the url is not recognized.

Smells like a bug to me.

Can you provide a little more information? For example, what is the domain name suffix? My understanding is that there may be issues with URI matching if the domain suffix is not on the public suffix list.

Also, it may be a good idea to let us know more about your environment (OS, browser, etc.).

The suffix is not included in this list.

I have an AIO selfhosted installation (on debian bullseye) and I just updated everything to the latest 2022.12 version:

VERSION

Server Installed 2022.12.0
Web Installed 2022.12.0

I doubt it’s related to the browser, since I have installed Chrome v108 and the issue is present on any other client I’ve tested this.

Does URL matching work if you set your matching rule to Host or Domain?

Hey, as mentioned earlier, no. The only thing that works for our internal domain are http/s URLs with IPs (such as https://127.0.0.1).

If you read this comment on GitHub Issue #1509, as well as the discussion that follows, it seems that Bitwarden’s domain matching algorithms only allow domains that have suffixes in the Public Suffix list.

Since it is possible to match on the IP address — would this not be an acceptable work-around for you?

Pinging @cksapp, since he has some experience with internal domains.

I think @grb is correct then - if you are making up your own domain name instead of using a domain with a recognized public suffix, Bitwarden cannot parse it for a match. My recommendation is to contact Bitwarden support to see if they are aware of a workaround or if they have any plans to change their matching algorithm.

No, because we have several applications running behind two load balancers and two reverse proxies.

I just wrote a mail to support, in hopes of finding a solution (among other authentication issues that have suddenly appeared in the last days).

Thanks for the ping, I actually had this post bookmarked for review later on so this helped bring it to my forefront.

Unfortunately I’ve never come across this issue similarly within my internal networks. My home network is using a personal valid domain.tld and all internal devices have linked hostnames for my internal subdomain. Our work’s network is a .local which as it appears in the linked

seems to be a valid public suffix per the comment

jamescridland commented on Oct 31, 2021

Good catch.

I’ve reported the lack of .local to the public suffix list. .local is defined by RFC 6762, so is a valid public TLD.

Perhaps you might star the issue over there?

publicsuffix/list#1466

Though I do not see this on the public suffix list used, and in the linked issue the maintainers closed this as “:x: wontfix


This perhaps could be explained in this comment further down in the post.

As a temporary workaround, you can change the match detection options from the default ‘Base domain’ to ‘Host’. This is working for my local .lan addresses now, but will likely break auto-fill on sites that share the same credentials across multiple sub-domains or ports.

Referencing my logins for work they either have URIs set for the pure https:Hostname:port or https:Hostname.domain.local:port with match detection also set to Host.
I believe this was due to some machines running multiple services on the same Hostname but with different ports i.e https:Machine1.domain.local:8080 & https:Machine1.domain.local:8443, etc.


@justarandomsysadmin Perhaps you can test your http://gitlab.whateverinternal.lan your login is set to and test to see if the Host match detection will work for you?

While I don’t currently have any HA setup, I do have a few internal services running behind a reverse proxy and some others that are not. As mentioned I use the Host detection for internal services as the standard Base domain function would match all different logins for separate services from sub-domains, as expected from the documentation.
I.e machine1.corp.domain.tld & machine1.corp.domain.tld
The Host option allows for Bitwarden to separate logins for the separate internal services.


One last thing I can possibly think of would be to check your URI matching, if it is set to your default Starts with as you say. Possibly check for any discrepancies in the URI such as a trailing /, according to https://bitwarden.com/help/uri-match-detection/#starts-with

For example, if the URI https://sub.domain.com/path/ uses starts with match detection:

URL Auto-fill?
https://sub.domain.com/path (absent trailing slash) :x:
1 Like

Thank you for the insightful answer.

I have tried to set the URL-matching to the host with the respective port, but it hasen’t worked yet.

The only thing that has worked out is to set the IP of the application and then actually calling the website like http://<ip-address> but this is no solution for our end users (that very limited IT knowledge) and doesen’t work with most applications that have a proper ROOT-URL set:

I know that this is basically a niche issue that not many people are experiencing, but it’s kind of a bummer especially since we have chosen to get the enterprise plan and host multiple internal sites for which the users basically can’t use one of the main funcitons of bitwarden properly.

I too am experiencing this issue on specific internal servers in my workplace with the browser extension in Chrome and Edge in a Windows 10 environment.

The issue though started about a month ago.

I have several internal servers in multiple DEV/QA/PROD that I have multiple URLs assigned the same LDAP username and password which I have to change every 60 days. About a month ago, it stopped working and I have to get to resolve.

I am and have been using Default Detection with autofill for over a year.

Please advise

@OhioN8v are the affected sites running behind a reverse proxy?

@cksapp You’ve mentioned that you do have a few internal services running behind a reverse proxy, but not if these specific entries are recognized by bitwarden. Can you test this and try to reproduce this specific scenario for us?

I have been in contact with enterprise support and sadly haven’t got any response regarding this, not even an acknowledgement that this is in fact an issue or it being recognized as such.