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?
It might be a "limitation", rather than a bug or undocumented feature.
Let me see if I can find out.
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
BTW, Apigee today works with these headers:
|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?