You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
(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
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.
The text was updated successfully, but these errors were encountered:
Steps To Reproduce
https://github.com/julianhindenberg/bitwarden-demo
curl -sfL https://get.k3s.io | INSTALL_K3S_EXEC="server" sh -s - --disable=traefik
kubeconfig
file located in/etc/rancher/k3s/k3s.yaml
, see https://docs.k3s.io/quick-start#install-scriptmkdir -p /data/Bitwarden/volume{1,2,3,4,5,6,7}
chown 10001:10001 /data/Bitwarden/volume{5,6,7}
kubectl create namespace bitwarden
kubectl apply -f secrets.yaml -f persistent-volumes.yaml
helm upgrade bitwarden bitwarden/self-host --install --namespace bitwarden --values my-values.yaml
/etc/hosts
filecurl --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:
externalTrafficPolicy
toLocal
to properly pass the source IPIssue Tracking Info
The text was updated successfully, but these errors were encountered: