X-Forwarded-For problem with ports

Not applicable

I'm working with Apigee on-premises and we have upstream infrastructure that is adding a X-Forwarded-For header with "X.X.X.X:port" value. I need to whitelist only specific IP ranges, however the AccessControl policy cannot seem to match any rule when a port number is present, no matter how broad the mask. If a port number is not present, then the AccessControl policy works fine. Of course, we are constrained in that the upstream infrastructure cannot be modified to exclude the port number.

While we could figure out a way to strip out the port number(s) from the header within Apigee, it doesn't seem appropriate that every proxy would need to add custom code just to make the AccessControl policy work as expected.

Is this a bug / "undocumented feature" that the AccessControl policy does not work at all if port numbers are present?

Solved Solved
1 6 5,627
1 ACCEPTED SOLUTION

It might be a "limitation", rather than a bug or undocumented feature.

Let me see if I can find out.

Update: Yes, i think this is a limitation. The AccessControl policy assumes the XFF is a hostname or IP address. To work around that limitation, you would need to modify the XFF header in each proxy prior to employing the AccessControl policy. Possibly you'd do that with a small JavaScript callout.

There is a way to inject common code in all API proxies for an environment, via a feature called flow hooks. This is first available in OPDK 17.01

With 17.01, you could use a shared flow and flow hook, and set the JavaScript callout there. This would then automatically run for all proxies in an environment.

BTW, Apigee today works with these headers:

header contents
X-Forwarded-For IP address or Hostname
X-Forwarded-Port port number used by client
X-Forwarded-Proto scheme or protocol used to connect (http or https)

I looked around for standards stating that XFF must/should contain an optional port, but did not find any. I am thinking the XFF is governed more by convention than standard; correct me if I am wrong. There is an applicable standard here: RFC7239. But this standard is not in wide use as far as I can tell. And Apigee Edge does not support it today, as far as I know.

Does this answer your question?

View solution in original post

6 REPLIES 6

It might be a "limitation", rather than a bug or undocumented feature.

Let me see if I can find out.

Update: Yes, i think this is a limitation. The AccessControl policy assumes the XFF is a hostname or IP address. To work around that limitation, you would need to modify the XFF header in each proxy prior to employing the AccessControl policy. Possibly you'd do that with a small JavaScript callout.

There is a way to inject common code in all API proxies for an environment, via a feature called flow hooks. This is first available in OPDK 17.01

With 17.01, you could use a shared flow and flow hook, and set the JavaScript callout there. This would then automatically run for all proxies in an environment.

BTW, Apigee today works with these headers:

header contents
X-Forwarded-For IP address or Hostname
X-Forwarded-Port port number used by client
X-Forwarded-Proto scheme or protocol used to connect (http or https)

I looked around for standards stating that XFF must/should contain an optional port, but did not find any. I am thinking the XFF is governed more by convention than standard; correct me if I am wrong. There is an applicable standard here: RFC7239. But this standard is not in wide use as far as I can tell. And Apigee Edge does not support it today, as far as I know.

Does this answer your question?

Fair. Just to share, it seems adding a port number may be common among IIS installations based on other posts such as this one: http://serverfault.com/questions/753682/iis-server-farm-with-arr-why-does-http-x-forwarded-for-have-...

To correct my statement above - the shared flows & flowhooks are already available in OPDK 17.01. I had originally said they'd be available in 17.05.

Yes, it looks like it's a common option for IIS servers running ARR.

Modifying XFF within the proxy before AccessControl policy execution doesn't seem to work for me.

Just did a noddy proxy with a JS setting XFF to 3.3.3.3 and an AccessControl policy that denies 3.3.3.3. In trace, I can see that AccessControl is still reading the original client ip address and surprisingly lists proxy.client.ip variable in "variables read" section.

Will create a support ticket for this.

Facing same issue! How to fix this !!