Using an external app gateway public IP as target endpoint to api proxy for host based routing

[gauravkjha]

HI,

I have an app gateway with two listeners and two backend pools where I have created a route rule to route the traffic. I have one public IP address from the gateway that I want to use as a endpoint for API proxy for two different Virtual Hosts in same env on APIGEE. Basically same API will have two Virtual hosts and one endpoint so that the gateway can route the traffic based on the hostnames. 

The gateway seems to be working fine when I bypass the proxy but the apigee proxy gives 404 error while I try to hit. I have added the IP of gateway as endpoint for now but the issue persists. Pls help or tag someone who can. 

@dchiesa1 @ssvaidyanathan @sgilson 

[dchiesa1]

I have an app gateway with two listeners and two backend pools

What's an app gateway? Is that part of Google cloud? Maybe it does not matter for the purposes of your question.

I have one public IP address from the gateway that I want to use as a endpoint for API proxy for two different Virtual Hosts in same env on APIGEE. Basically same API will have two Virtual hosts and one endpoint so that the gateway can route the traffic based on the hostnames.

It sounds like you're trying to set up an Apigee API proxy that uses a different system, "app gateway" as the target. That all sounds good. I am not sure what the two virtualhosts have to do with anything. If I were you I would eliminate one of the virtual hosts for now. You can add it later. It sounds like connectivity from Apigee to the other system is the obstacle, currently. So the virtualhost will have nothing to do with that.

The gateway seems to be working fine when I bypass the proxy but the apigee proxy gives 404 error while I try to hit. I have added the IP of gateway as endpoint for now but the issue persists.

The 404 status code is not "Cannot connect". So it is probably not happening because of an IP restriction. The 404 indicates "that resource is not found."  In other words the target is affirmatively responding that it received the request and does not have the requested resource.  So I would check the verb/path you are sending to the upstream system. It may not be what you think it is.

Be sure you are getting the 404 from the upstream. Sometimes it is Apigee that returns the 404.  You can do this by using the Trace/Debug session tool in the Apigee UI.  Start a trace session for your proxy, then send a request in.  The trace window will show where the 404 is coming from.  If you see nothing in the trace window, then the proxy never received the request!  In that case you need to check the path and verb that you are sending to the Apigee proxy. 

A common surprise for some people is that Apigee prepends the API proxy path suffix to the request sent to the upstream system. If you don't want that behavior, you can turn it off by setting a context variable to false. target.coy.pathsuffix.

[gauravkjha]

Thanks @dchiesa1 for your suggestions.

I traced the api..I can see that Request is received from the Client but 404 error on Response sent to Client. When I dug further down the flow, I can see the following outcome -

My target connection is the public IP of an application gateway. This application Gateway is not a part of google cloud, it's an azure application gateway that listens to an incoming hostname and routes it to respective backend. I am not sure what I am missing here.

[dchiesa1]

It seems like the upstream system *(your Azure app gateway) is responding affirmatively, that "that resource is not known."  So the next thing to look at is, what resource is Apigee requesting? 

If you look at the Trace session from a few steps prior, you will see the effective URL used at the target.  That might give you more hints.  It will show you the full path.  Maybe the full path is not known by the Azure-hosted thing. 

Also - check it.  Your app gateway thing is returning content-type:html.  Is that expected? Normally Apigee does not proxy html.  It is an API proxy.  So we would expect text/xml, or application/json, or something suitable for consumption by API clients. Not web page markup.  If you are using Apigee as an API proxy and you are getting text/html from your upstream system, something is amiss. Worth investigating.