Is there a way to hack the way Traefik deals with X-Forwarded-For headers?

Context

I am using Traefik (v1.7.12, as an Ingress Controller in a kubernetes instance) as a gatekeeper to access another site (through a kubernetes service of type ExternalName) that I don’t control (a private status page on site24x7.eu for the record, that has a very limited configuration regarding IP whitelisting).

I was expecting that the only IP that the target site would see would be the egress Nat IP of my cluster (in the context of a private GKE cluster with a Cloud Nat configuration so that all nodes are private only).

But it looks like the target site is using the X-Forwarded-For header to check the client IP, and for the moment, the values in the X-Forwarded-For header are [“real_client_ip, cluster_nat_ip”] (the real_client_ip is added by the GoogleLB in front of Traefik, the cluster_nat_ip is added by Traefik that sees the GoogleLB with the Google Nat IP)

As the real_client_ip is not whitelisted on the target site, the request is blocked (by the target site).

Note

  • I already tried to use ingress.kubernetes.io/custom-request-headers and ingress.kubernetes.io/proxy-headers but the result that I have is that the X-Forwarded-For value is added to existing one
    [“real_client_ip, cluster_nat_ip”,“cluster_nat_ip”]
  • I checked with the support of the site24x7 target site, and they confirmed they are using values in the X-Forwarded-For headers (/off : does-it only seem weak to me?)

My questions
Is there a way to hack (REPLACE and not ADD for instance) the content of the X-Forwarded-For?

Hello, have you try to use:

[entryPoints]
  [entryPoints.http]
    address = ":80"

    [entryPoints.http.forwardedHeaders]
      insecure = false

This will remove all X-Forwarded-For value before Traefik.

Thank your for the suggestion, I did not try yet.

The solution I’m using for the moment is that I have setup a nginx between traefik and the final target host site, and I’m using a config to replace the existing X-Forwarded-For values (and yes, I’m sad because I had to start a nginx just for that)

It’s a hack of the forwarded-header, it’s an “internal” and undocumented option.
You can produce the same behavior with trustedIPs and an “impossible” IP.
https://docs.traefik.io/configuration/entrypoints/#forwarded-header

The option will be applied only on one entrypoint, but if it’s your “main” entrypoint it’s an issue.

I think we need to add something to do that on v2 :smiley:

I already tried the “trustedIP with impossible IP” without success but I will try again in case of a PBCK issue.

Yes, definitely, it would be nice to add a per-ingress configuration for this kind of hack in traefik V2.

We really like Traefik, keep the good work going on folks!

1 Like