Unable to get client IP when running on overlay network

[marccampbell]

This may be an issue with Docker overlay networks and not Traefik specifically.

When running traefik as a docker 1.12 service and exposing a port, it connects to both the specified network from the service file and the built-in ingress network. When the upstream service receives requests forwarded from Traefik, the X-Forwarded-For header contains an IP address from the overlay network, not the actual client address.

[osixia]

May be related to:
kubernetes/kubernetes#10921

this is what i get on my kubernetes cluster via emilevauge/whoami image:
https://api.osixia.net/user/whoami

Hostname: whoami-1929362576-lm19i
IP: 127.0.0.1
IP: ::1
IP: 10.244.63.10
IP: fe80::42:aff:fef4:3f0a
GET / HTTP/1.1
Host: api.osixia.net
[...]
Dnt: 1
Upgrade-Insecure-Requests: 1
X-Forwarded-For: 10.244.12.1
X-Forwarded-Host: api.osixia.net
X-Forwarded-Proto: https
X-Forwarded-Server: traefik-3278890820-a3rja

10.244.63.10 is the pod IP
10.244.12.1 is the ip of the node running kube-proxy that accept ingress trafic

No information about the client IP :(

[Starefossen]

I am experiencing the same behaviour when working with Kubernetes and Træfɪk locally through Minikube.

[Starefossen]

I had some hopes that the Kubernetes v1.4 would solve this; ref http://kubernetes.io/docs/user-guide/load-balancer/#loss-of-client-source-ip-for-external-traffic. But so far I have not had any success.

[osixia]

I now run kubernetes 1.4.0 and nothing changed :(

[emilevauge]

Ping @vdemeester, any idea on this?

[rio]

Just ran in to this today while slowly moving away from our old load balancing infra.
Solution for us was to use an external load balancer to send traffic to NodePorts for the service... not ideal.

[Starefossen]

@rio are you using Træfik at all in your setup?

[rio]

Yes, we plan use it as our main ingress point. We've been already using it for services like grafana, staytus and other services that are not dependent on source ip.

[viet]

I still need this new feature, because I run a startup that provides TCP connection only for Minecraft players, there's no IP forwarding via HTTP header. Getting users IP via network layer is always better.

[tzapu]

i think this should be possible now using
--publish mode=host,target=80,published=80
and maybe --global

i however was unable to access traefik when publish is set to mode=host...

[farko88]

any update for this?

[mbrucher]

Noticed the same problem, spent several weeks figuring out this problem!!

[ilan-schemoul]

https://stackoverflow.com/questions/44639958/nginx-behind-traefik-docker-swarm-mode-real-ip

[samip5]

This is present on non-kubernets deployments.

[georg90]

I am wondering why this is not getting more interest. Any swarm cluster is (IMHO) not usable with traefik..
We can route and forward but we do not know where the request came from, this kills the traefik own ipWhitelist feature as well as anything in the backend (e.g. fail2ban).

Did anybody manage to work around this issue? Currently I am split between using host mode and having the ip but loosing the ingress network or having no option to limit access by source address / exposing the client ip to my apps (e.g. adguard would be much more useful with client IP)

[CumpsD]

I am trying to figure this out as well. I have downstream DNS services and they all receive the IP of the traefik instance, while I need the IP of the client

[munrad]

Maybe this solution will help in some way
newsnowlabs/docker-ingress-routing-daemon