Connections to proxy not resolving

[JacobHume]

Hi all!

I just set up an Apigee X paid organization. However, I'm not able to connect to my proxies from the external internet, nor have my connections from VMs worked as well. Consequentially, my external load balancers are also in an unhealthy state.

I've tried curling at the nodes by targeting the URL I have set up in DNS, by using the IP of the external load balancer, by using another VM and targeting the internal IP address of one of my proxy nodes, but none of these work. When I directly use the internal IP of the service that is behind my proxy, then it works fine, so as far as I can tell I have an issue with the configuration of my proxy but I am not sure what it is.

Thanks!

[dchiesa1]

Did you configure routing? This part is important. 

If your connections from VMs within your VPC did not work, then.... I don't know what to suggest beyond "check your IP addresses". 

Miguel did a long screencast walkthrough of setting up Apigee.  It's from August 2021, so a little old, and a few things have changed since then. Even so, you might want to look at it though, to see if you can get some hints. 

[JacobHume]

I did set up routing externally. To reduce variables, I looked at the instructions you provided, and it says routing internally is automatically set up, and then there is a section to test the internal routing. Fundamentally, I think these steps have you ssh into a VM so you can access the internal network, then curl a hello-world URL. I didn't set up the DNS for this address, nor did I configure a hello-world proxy manually, so that may be the issue here, but when I get to the final substantive step of the test, I don't get a connection.

$ curl -is -k -v -H "Host: $ENV_GROUP_HOSTNAME"   https://example.$PROJECT_ID.apigee.internal/hello
-world   --cacert cacert.crt   --resolve example.$PROJECT_ID.apigee.internal:443:$INTERNAL_LOAD_BALANCER_IP
* Expire in 0 ms for 6 (transfer 0x55cae6a88fb0)
* Added example.hume-data.apigee.internal:443:10.47.0.2 to DNS cache
* Hostname example.hume-data.apigee.internal was found in DNS cache
*   Trying 10.47.0.2...
* TCP_NODELAY set
* Expire in 200 ms for 4 (transfer 0x55cae6a88fb0)
* connect to 10.47.0.2 port 443 failed: Connection timed out
* Failed to connect to example.hume-data.apigee.internal port 443: Connection timed out
* Closing connection 0

This leads me to believe that the issue is downstream of the routing, but maybe I have the wrong impression?

[dchiesa1 · Accepted solution]

Fundamentally, I think these steps have you ssh into a VM so you can access the internal network, then curl a hello-world URL.

Yes

OK I am following.

I didn't set up the DNS for this address, nor did I configure a hello-world proxy manually, so that may be the issue here.

You don't need a DNS entry of course, you can use the --resolve option to get what you want. I think (not certain) that you don't need both -k and --cacert on your curl command line. The -k says "ignore cert issues" and the --cacert says "resolve certs with this trust store."  As far as I understand, you will never need to use them together, on the same command line. But anyway, certificate and TLS handshake is not the problem you're encountering. The main problem is no connection.

You seem to be doing the right thing. Can you step back and check the basics? Rather than trying to  connect to the specific IP:port combination, can you check

• have you got the right IP address for the internal load balancer?
• have you any connectivity to the internal load balancer IP from your VM?
• The VM is in the VPC that you used for Apigee.

The ILB must be reachable from the VM, and it seems like it is not. So either the IP is wrong, or there is a firewall in place that is preventing connection.  Does your organization have default firewall rules set in place that would prevent this kind of connectivity? That's where I would start checking.

[JacobHume]

• have you got the right IP address for the internal load balancer?

I feel fairly good about this as the instructions seem to curl an endpoint to get the internal IP:

export INTERNAL_LOAD_BALANCER_IP=$(curl -H "$AUTH" https://apigee.googleapis.com/v1/organizations/$PROJECT_ID/instances -s | jq -r '.instances[0].host')

I don't know how to find this from the console, however, so I don't have a method to double check this; maybe you can help me out with that?

• have you any connectivity to the internal load balancer IP from your VM?

Just tried a ping here, and it doesn't appear to be connected.

• The VM is in the VPC that you used for Apigee.

I feel like this is very likely to be the issue at hand; at the recommendation of the documentation I set up a new VPC called "apogee-network" separate from the default VPC. I didn't do anything special when creating this VM to give it knowledge of the VPC; I haven't done much of anything with it short of specifying it when creating my organization via the wizard. If this is the issue then perhaps this also explains why the external load balancer can't find my Apigee instance; is it possible that the external load balancer is in one VPC and has no connectivity to the instance, which is in another VPC? And if this were the case, how would I check this?

Thanks so much for your help thus far.

[JacobHume]

Ultimately decided to redo my setup on the default VPC, which made things a lot easier.

[dchiesa1]

I'm sorry it was messy, but glad you got it sorted out. I am not a networking expert, so I'm not much use in helping with all of that.