Access control policy works differently for secure.

[#1]

After enableMultipleXForwardCheckForACL at org level we can't spoof http request, but can still spoof https. Here are the things which are happening when.

==>Attempt to access secure from an unauthorised client IP. (issue - fault string has a 10.* IP).

{{"faultstring":"Access Denied for client ip : [10.10.21.96]","detail":{"errorcode":"accesscontrol.IPDeniedAccess"}}} * Connection #0 to host paymark-dev.apigee.net left intact

}

==>Attempt to access default from an unauthorised client IP. (works as expected)

==>Attempt to access default from an unauthorised client IP with an X-Forwarded-For header added (works as expected)

==>- Attempt to access secure from an unauthorised client IP with an X-Forwarded-For header added (issue - unauthorised client is allowed).

==>Attempt to access secure from an authorised client IP (issue - access denied and fault string has a 10.* IP)

==>Attempt to access default from an authorised client IP (works as expected)

[gnanasekaran]

when you run trace, you should be able to see the incoming X-forwarded-for headers, can you verify if those values look correct to you?

If it looks correct, then we need to verify the policy configuration or VH configuration

If it is not, then we need to check if the upstream components are actually setting x-forwarded-for correctly. For cloud, you can reach out to support.

In either case, can you verify the incoming headers in trace?