#Cannot communicate with a AWS instance, what needs to be done?

1 messages · Page 1 of 1 (latest)

scarlet ingot
#

One instance is located in AWS, the other is in Azure.
We know There are no ACLs between AWS and Azure to restrict specific traffic. Traffic seems blocked on the AWS instance. The attached screenshot is provided by AWS admin. I am not so famiiar with what needs to be done in order to have http/https traffic to reach to an instance. He also created a similar for the other direction.

Can you please provide your ideas about what could go wrong here?

AWS_instance_SG_rule.png
naive sapphire
#

Hi @scarlet ingot , thanks for being part of the NetApp discord! How is the routing configured between this instance and the Azure instance? Are they able to ping/traceroute to each other?

clear plinth
#

More to Dan's question - how is connectivity between the two cloud environments established? From the look of your security group rules above, this is only allowing traffic on ports 80/443 from that one private IP address.

#

(Note that ping would not work unless the incoming ICMP port were allowed in the security group, too)

scarlet ingot
#

@clear plinth @naive sapphire "traceroute" indciated that traffic stops once entering AWS over the directconnect and stops when about to hit the AWS connector host. But, upon AWS admin, ICMP is not open on AWS side, and also there are no ACLs between AWS and Azure to restrict specific traffic.

Further, I got the following error from Azure instance to AWS instance, so, the traffic seesm stopped at AWS instance, correct?
curl: (28) Failed to connect to 10.193.19.119 port 80: Operation timed out

@clear plinth

From the look of your security group rules above, this is only allowing traffic on ports 80/443 from that one private IP address.
What else do we need to do?

I don't have the access to AWS, nor to Azure. I am not sure if they have correctly done those rules. But, don't know how to troubleshoot the issue.

clear plinth
#

Hrmm... difficult one to help with if you don't have direct access to how the AWS side of things is configured.

Here's a few pointers that may help you in conversations with your peers that do have access to the AWS account you're using:

  • Just for background, there are two ways to control traffic in AWS: Security Groups and NACLs. NACLs are rarely used and honestly we discourage users from using them (they are stateless and rarely needed). Security Groups are the more common way to limit traffic and are stateful (meaning if you send a request to machine A that allows traffic from an machine B, then machine A is also then allowed to send traffic back to machine B).
  • AWS Direct Connect (DX) requires some additional configuration to connect to an AWS VPC. The VPC needs a Virtual Private Gateway associated with it and a Virtual Private Interface. From there, you would need to have proper routing on prem to forward IP traffic through the Direct Connect connection and on to the appropriate VPC Virtual Private Gateway. There's an entire troubleshooting guide to aid in diagnosing any issues with DX: https://docs.aws.amazon.com/directconnect/latest/UserGuide/Troubleshooting.html
  • You can also enable ICMP on a security group to allow ping/traceroute packets to go through.
  • If you're able to access the instance in AWS by other means, you can try to see if it is possible to connect back to anything that is on-prem (over the DX connection - to validate that it is working).
Troubleshooting AWS Direct Connect - AWS Direct Connect

Diagnose, troubleshoot, and repair your cross connection or remote connection to AWS Direct Connect.

scarlet ingot
#

@clear plinth Your messages are very helpful, Thanks!
Based on the traceroute, the traffic stops once entering AWS over the directconnect. From this point, what else can we check?
As shown by attached screenshot, it looks the AWS Admin already created SG rules for http/https. I can request for enabling ICMP on the SG...

clear plinth
#

Just so I better understand the scope of the issue - is this an existing Direct Connect connection to a VPC that is already being used (and a known good configuration) and this is just an issue related to the instance that you're attempting to connect to? Or is this a new DX connection to a VPC that you still need to validate is working?

scarlet ingot
#

DX has been in-placed for long time already for the organization. This is an issue just related to the instance that we are attempting to connect to.
Also, other than SG and it's rules for the instance, are there any SG type of boundary for the VPC as well?