IP whitelisting and Static IP range

[#1]

If I were to use Apigee Edge between my customer and us what IP restriction options are available?

Specifically - inbound options where I can restrict customer IP ranges when they connect to Apigee

- outbound options where the traffic flows from Apigee to our network in which case all we need are the IP ranges used by Apigee (is there a static option enabled by calling support or self configuration) to be listed on our whitelist

What are the definitions of what Northbound and Southbound as mentioned in some of the articles and please elaborate

[DChiesa]

Good questions.

I think we use "Northbound" and "Southbound" sort of informally, without defining them. The analogy is to computer engineering parlance. In general,

• "northbound" implies the interface facing the client, consumer, customer, or caller. This is inbound from the perspective of the API proxy.
• "southbound" refers to the backend connection to an existing API implementation. Outbound from the perspective of the API Proxy.

To enforce inbound IP range restrictions on the northbound interface, you can use the AccessControl policy in an Apigee Edge proxy.

To get the IP addresses that your Apigee proxies use on the Southbound interface, you can inquire with Apigee Support if you have an enterprise license. For Edge trial or "Apigee Edge Start", there is no fixed set of IP addresses for whitelisting.

In general we recommend that you configure 2-way TLS between Apigee Edge and your systems, on the southbound interface. That means you would self-issue a key, or get a cert+key from your CA, and provision it into Apigee Edge. And you'd also do the same and provision it on your firewall. Then both systems can authenticate the other. This is a best practice, and will work better in elastic cloud-based systems. Cloud-based systems may get moved or may scale out, leading to IP address changes. This means IP range based security is rather brittle.

[williamking]

@Dino

We have a paid, EDGE cloud instance, and I have not yet been able to find an "true" client ip in the request headers. I see only a single internal style IP that I've always assumed to be a load balancer. We recently had someone ask us from which IP their requests were coming, and I was unable to answer.

I've tried creating a custom report that makes use of the "Referred Client IP" dimension, but ended-up with only "not set" for hundreds of thousands of requests.

Do you have any guidance?

[DChiesa]

Are you asking a question about the inbound IP addresses? Inbound w.r.t. Apigee Edge proxies?

[williamking]

Correct. I'm asking about the IP address of the "app" making the HTTP call to our EDGE proxy.

[dchiesa1]

sorry delay. Have you checked the X-Forwarded-For header?

[rajendra_biswal]

@williamking, did you get a clarification for your last query?

[dchiesa1]

check the X-Forwarded-For header?

[#9]

@williamking,

Referred Client IP contains value from 'True-Client-IP' header that gets populated by routing products such as Akamai. I guess, there is no Akamai configured here.

have you tried 'proxy_client_ip' dimesnion? Lets know the result.

Also, note that our guideline is to ask a new question separately.

Regards,

Rajesh Doda

[williamking]

Sorry, I considered opening a new question but thought it might be related enough.

I don't believe I've added `proxy_client_ip` to a custom report. Everything I've ever seen in trace logs related to that value are internal IPs, not the actual request IP (i.e. outside of your AWS network).

I have an open ticket regarding this issue and will update this (or a new question) with whatever is figured out.