Get hands-on experience with 20+ free Google Cloud products and $300 in free credit for new customers.

Connections to proxy not resolving

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!

Solved Solved
0 6 1,054
1 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.

View solution in original post

6 REPLIES 6