Wrong source IP with deployment via Helm

[julianhindenberg]

Steps To Reproduce

1. Checkout the Bitwarden demo repository containing the config files:
   https://github.com/julianhindenberg/bitwarden-demo
2. (On K3s host) Create a K3s cluster (or use an existing K8s cluster):
   curl -sfL https://get.k3s.io | INSTALL_K3S_EXEC="server" sh -s - --disable=traefik
3. Copy kubeconfig file located in /etc/rancher/k3s/k3s.yaml, see https://docs.k3s.io/quick-start#install-script
4. (On K3s host) Create directories for persistent volumes:
   mkdir -p /data/Bitwarden/volume{1,2,3,4,5,6,7}
5. (On K3s host) Set ownership for MSSQL volumes:
   chown 10001:10001 /data/Bitwarden/volume{5,6,7}
6. Install ingress nginx:

helm upgrade --install ingress-nginx ingress-nginx \
--repo https://kubernetes.github.io/ingress-nginx \
--namespace ingress-nginx \
--create-namespace \
--set controller.service.externalTrafficPolicy=Local

7. Create namespace:
   kubectl create namespace bitwarden
8. Apply additional manifests:
   kubectl apply -f secrets.yaml -f persistent-volumes.yaml
9. Install Bitwarden:
   helm upgrade bitwarden bitwarden/self-host --install --namespace bitwarden --values my-values.yaml
10. Configure domain override in /etc/hosts file
11. Execute request against the IP endpoint:
    curl --insecure https://bitwarden.example.com/api/ip

Expected Result

The resolved IP address should be 192.168.1.20, as forwarded by the Ingress Controller.
{"ip":"192.168.1.20","headers":{"X-Forwarded-For":{"key":"X-Forwarded-For","value":["192.168.1.20"]}}}

Actual Result

The resolved IP address is an IPv4-mapped IPv6 address containing the internal IPv4 address of the Ingress Controller, even though the forwarded IP address is set properly.
{"ip":"::ffff:10.42.0.10","headers":{"X-Forwarded-For":{"key":"X-Forwarded-For","value":["192.168.1.20"]}}}

Screenshots or Videos

No response

Additional Context

An IPv4-mapped IPv6 address is displayed as the source IP (e.g. ::ffff:10.42.0.10; address of the Ingress Controller), both in the /api/ip endpoint and in the emails (new device logged in).
This happens both when calling via IPv4 and via IPv6 (not reproducible in this example; I can also reproduce this behavior in my productive cluster via IPv6, whereby I get the same IPv4-mapped IPv6 address displayed via IPv4 and IPv6).

Bitwarden runs in a K3s cluster with the Nginx Ingress Controller. In other containers in the same cluster, the source IP is resolved correctly.

Build Version

2024.9.1

Environment

Self-Hosted

Environment Details

Environment:

• Debian (Bookworm) VM
• Single Node K3s cluster without Traefik
• Ingress Nginx as Ingress Controller
  • Set externalTrafficPolicy to Local to properly pass the source IP
• IPv4 only setup in this example, but reproducible with a Dual Stack setup as well
• Bitwarden was installed via Helm

Issue Tracking Info

• I understand that work is tracked outside of Github. A PR will be linked to this issue should one be opened to address it, but Bitwarden doesn't use fields like "assigned", "milestone", or "project" to track progress.

[Neonwarden]

Hi there,

This has been escalated for further investigation. If you have more information that can help us, please add it below.

Thanks!

[gertjanvg]

Experiencing the same issue with version 2024.11.0. I think issues #2908 and #3116 are related.

It's possible to define exact trusted proxy IPs using the globalSettings__knownProxies, but that's obviously not realistic in Kubernetes, as IPs can and will change all the time. I think this is the relevant piece of code:

server/src/SharedWeb/Utilities/ServiceCollectionExtensions.cs

Lines 588 to 603 in 092b0b8

	if (!string.IsNullOrWhiteSpace(globalSettings.KnownProxies))
	{
	var proxies = globalSettings.KnownProxies.Split(',');
	foreach (var proxy in proxies)
	{
	if (IPAddress.TryParse(proxy.Trim(), out var ip))
	{
	options.KnownProxies.Add(ip);
	}
	}
	}
	if (options.KnownProxies.Count > 1)
	{
	options.ForwardLimit = null;
	}
	app.UseForwardedHeaders(options);

One solution would be to be supply a trusted proxy subnet as described in #2908.