[Docs] Update README regarding Traefik access log IPs

[ToshY]

Problem

Like many others, #13, #23, #25, #29, #30, I've been trying to use this plugin, in particually with a Crowdsec instance which uses the Traefik access logs.

While the plugin does exactly what it says it does, fixing the headers, many (like myself) incorrectly assume that the plugin will also fix the access log with the actual user IP instead of the CloudFlare IP, which this plugin does not.

In order to have the user IPs instead of CloudFlare IPs in the logging, the idea is to set trustedIPs under the forwardedHeaders, see docs.

An example would be as follows:

static.yml

entryPoints:
  websecure:
    forwardedHeaders:
      trustedIPs:
        - 173.245.48.0/20
        - 103.21.244.0/22
        - 103.22.200.0/22
        - 103.31.4.0/22
        - 141.101.64.0/18
        - 108.162.192.0/18
        - 190.93.240.0/20
        - 188.114.96.0/20
        - 197.234.240.0/22
        - 198.41.128.0/17
        - 162.158.0.0/15
        - 104.16.0.0/13
        - 104.24.0.0/14
        - 172.64.0.0/13
        - 131.0.72.0/22
        - 2400:cb00::/32
        - 2606:4700::/32
        - 2803:f800::/32
        - 2405:b500::/32
        - 2405:8100::/32
        - 2a06:98c0::/29
        - 2c0f:f248::/32

or if you use environment variables for static configuration:

.env

TRAEFIK_ENTRYPOINTS_WEBSECURE_FORWARDEDHEADERS_TRUSTEDIPS="173.245.48.0/20,103.21.244.0/22,103.22.200.0/22,103.31.4.0/22,141.101.64.0/18,108.162.192.0/18,190.93.240.0/20,188.114.96.0/20,197.234.240.0/22,198.41.128.0/17,162.158.0.0/15,104.16.0.0/13,104.24.0.0/14,172.64.0.0/13,131.0.72.0/22,2400:cb00::/32,2606:4700::/32,2803:f800::/32,2405:b500::/32,2405:8100::/32,2a06:98c0::/29,2c0f:f248::/32"

_{IPs in the above examples are available from https://www.cloudflare.com/ips/.}

---

Suggestion

Minor addition to the documentation to state that this plugin only fixes the headers and that additional steps have to be taken (like the examples denoted earlier) to get the actual IP changes in the access logs.

[mrinc]

https://github.com/traefik/traefik/blob/1ffbffb26a3676b368c4fc52c4fb737de56cd65d/pkg/config/static/entrypoints.go#L19

So, I think the big thing here is the issue is because traefik is using the entrypoint for logging, and not after a middleware (it occurs before).

We also don't want to be doubling config and specifically denoting to trust those IPs because realistically that shouldn't work with CF?
reason: CF do not use the default headers, so the entrypoint shouldn't be able to parse it correctly.

mmmm..... I am going to add some tests with this info later this week and will see what I can find to make it better.

[github-actions[bot]]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days

[ToshY]

@mrinc have you made any progress on this issue?

[sdwilsh]

We also don't want to be doubling config and specifically denoting to trust those IPs because realistically that shouldn't work with CF? reason: CF do not use the default headers, so the entrypoint shouldn't be able to parse it correctly.

It works because they do support the default headers as well, although I do not know how Traefik handles multiple addresses in this field. See https://developers.cloudflare.com/fundamentals/reference/http-request-headers/#x-forwarded-for

[mrinc]

@ToshY haven't done anything yet sorry... been a bit busy this side.
Happy to look at a PR if you got any ideas.

@sdwilsh but we also can't trust the x-forwarded-for since it could be manipulated by the client.
So for safety, we should stick with the verification methods provided by CF.

Ideally we want to do it before traefik actually logs the request... somehow

[mrinc]

So looks like we can't really make something to intercept ... but we can do this: https://doc.traefik.io/traefik/observability/access-logs/

So you can add the CF-Connecting-IP - the issue I have right now is I have not done enough research, but if this access log occurs before the middleware, then that is it - however if it occurs after , then we can also include the trusted state.

[mrinc]

Not sure if it was one of you guys, but there is some docs on how to do this here: https://www.reddit.com/r/selfhosted/comments/1dcn19v/standing_up_the_crowdsec_bouncer_plugin_in_traefik/

I will leave this issue open to add some docs on this.

[github-actions[bot]]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days

[github-actions[bot]]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days

[github-actions[bot]]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days