Allow clientIPGeoLocations without clientIPDetection.xForwardedFor

[sboulkour]

What would you like to be added?

Relax the clientIPGeoLocations validator so that ClientTrafficPolicy.spec.clientIPDetection is no longer mandatory. When omitted, EG should emit the geoip filter without xff_config / custom_header_config, letting Envoy fall back to its native default: the downstream connection source address (TCP peer).

No new CRD fields needed — only relaxing the check in validateAuthorizationGeoIP:

if clientIPDetection == nil {
    return nil, errors.New("authorization clientIPGeoLocations requires ClientTrafficPolicy.spec.clientIPDetection to be configured")
}

Why is this needed?

Envoy's HTTP geoip filter (proto) supports three IP-source modes:

1. xff_config set → use XFF
2. custom_header_config set → use a named header
3. Neither set → use the downstream connection source address

EG today only exposes modes 1 and 2. Mode 3 — Envoy's own default and the correct behavior for L4-transparent topologies — is unreachable through any EG configuration.

This matters for setups behind L4-transparent load balancers that preserve the client source IP at TCP level and don't touch HTTP headers, e.g.:

• AWS NLB with target-type: instance + externalTrafficPolicy: Local
• Azure Standard Load Balancer (default behavior)

In these topologies the TCP peer is the real client IP. The current workaround — setting numTrustedHops: 1 purely to satisfy the validator — also opens an XFF spoofing window, since EG then asks Envoy to trust whatever the client puts in XFF.

Proposed solution

In validateAuthorizationGeoIP: accept nil clientIPDetection, and emit the geoip filter without xff_config / custom_header_config in that case. Operator intent is expressed by omission, mirroring raw Envoy config.

Environment

• Envoy Gateway: v1.8.0-rc.1+
• Topology: Client → AWS NLB / Azure Standard LB → Envoy Gateway → Backend

[sboulkour]

cc @zhaohuabing @arkodg

May I have your opinion on this ?
Current situation is that L4 LB in Azure doesn't have any option to populate trustable value in XFF header. It makes current GeoIP feature no usable as XFF values can be anything put by the client.

[zhaohuabing]

Hi @sboulkour thanks for raising the L4-transparent use case. I agree this is a legitimate use case.

One concern is whether we should require an explicit opt-in for this. Since Envoy’s HTTP GeoIP filter falls back to the downstream remote address when neither XFF nor a custom header is configured, an accidental omission of clientIPDetection could change the trusted IP source. In topologies where the downstream address is a load balancer, node, or NAT address rather than the original client IP, that could lead to incorrect or unsafe authorization decisions.

[sboulkour]

@zhaohuabing OK, I agree. Lets update PR to make it explicite to chose between headers or TCP source IP.

Im thinking of:

clientTrafficPolicy:
  spec:
    clientIPDetection:
      downstreamSourceAddress: {}

Also @arkodg , can this be shipped within v1.8.0 milestone ?

[sboulkour]

PR #8956 updated accordingly.

[sjoukedv]

I am using a similar setup AWS NLB with client IP preservation, but some listeners are behind an additional proxy like Cloudflare. It's possible to extract the correct DOWNSTREAM_REMOTE_ADDRESS_WITHOUT_PORT using ClientIPDetection.XForwardedFor.TrustedCIDRs, but this is not compatible with GeoIP module and the SecurityPolicy also shows this:

clientIPGeoLocations does not support ClientIPDetection.XForwardedFor.TrustedCIDRs`

Is it also an option to use this with a "local" CIDR like 127.0.0.1/32 instead of which you know it will never match and fallback to the remote address?