matrix-docker-ansible-deploy icon indicating copy to clipboard operation
matrix-docker-ansible-deploy copied to clipboard

All IPv6 clients show up as coming from 172.23.0.1

Open lordgurke opened this issue 2 years ago • 1 comments

I'm running a dualstacked instance using the playbook. All IPv4 clients are shown in Logs, Synapse sessions list etc. with their original IP address. That's all fine. All IPv6 clients are shown as connecting from 172.23.0.1. Since > 90% of the clients on that server connect over IPv6 it's quite enerving not being able to acutally see these information.

IP 172.23.0.1 belongs to the docker network bridge matrix-container-socket-proxy. I found no documentation on how to configure that one or what it acutally does. Also, it could be some stupid coincidence, this IP is showing up for whatever reason and it has nothing to do with that socket-proxy (i.e. some NAT mixup).

# docker network ls
NETWORK ID     NAME                            DRIVER    SCOPE
b182601b1734   bridge                          bridge    local
f24dd17ae8bd   host                            host      local
85bf2b894eb4   matrix                          bridge    local
c540f245538e   matrix-client-element           bridge    local
43a36812bb32   matrix-container-socket-proxy   bridge    local
e60767faa946   matrix-coturn                   bridge    local
1a2ea9b63275   matrix-dimension                bridge    local
090a6916571d   matrix-jitsi                    bridge    local
1bbd46169320   matrix-ntfy                     bridge    local
6edc3c1a0f5f   matrix-synapse-admin            bridge    local
930533646e1c   none                            null      local
c15e94cb7209   traefik                         bridge    local

# ip addr show dev br-43a36812bb32
19: br-43a36812bb32: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default 
    link/ether 02:42:56:ba:b7:6c brd ff:ff:ff:ff:ff:ff
    inet 172.23.0.1/16 brd 172.23.255.255 scope global br-43a36812bb32
       valid_lft forever preferred_lft forever
    inet6 fe80::42:56ff:feba:b76c/64 scope link 
       valid_lft forever preferred_lft forever

I sniffed the traffic on the bridge between Traefik and Synapse, and it seems Traefik does not even know the actual IPv6 address of the client. Thus, it sends 172.23.0.1 in X-Forwarded-For. With IPv4 clients, the correct IP address is submitted in X-Forwarded-For.

22:41:05.877122 IP 172.24.0.5.43300 > 172.24.0.4.8080: Flags [P.], seq 1:535, ack 935, win 501, options [nop,nop,TS val 349207052 ecr 2961028515], length 534: HTTP: 
GET /_matrix/client/r0/sync?filter=4&set_presence=online&timeout=30000&since=s7461_678613_816_7280_16305_76_10054_684_0_6 HTTP/1.1
[....]
X-Forwarded-For: 172.23.0.1
X-Forwarded-Host: <redacted>
X-Forwarded-Port: 443
X-Forwarded-Proto: https
X-Forwarded-Server: 9de69cd46c21
X-Real-Ip: 172.23.0.1

Expected behavior IPv6 addresses should show up correctly.

Matrix Server:

  • OS: Debian 11.6
  • Architecture: amd64

Client: Affects all clients, including Element Web on the same server

lordgurke avatar Apr 10 '23 20:04 lordgurke

You probably have an AAAA DNS record (and thus incoming IPv6 traffic) to your server, but your Docker container networks are not configured for IPv6.

When this happens, Docker uses NAT64 and the remote client's IPv6 address is lost. Services running in Docker only see some Docker internal IP (like 172.23.0.1).

To fix this, you should enable IPv6 support for the playbook.

[!WARNING] Note that changing devture_systemd_docker_base_ipv6_enabled subsequently for an existing server (as you would need to do) requires manual work - see I've changed the devture_systemd_docker_base_ipv6_enabled setting, but it doesn't seem to have any effect.

spantaleev avatar Mar 08 '25 13:03 spantaleev