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
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?
Though I do not see this on the public suffix list used, and in the linked issue the maintainers closed this as “ 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.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
@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.
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: