How do I connect to the internet from an EC2 instance in a VPC?

0

This question is asked a lot and I have followed the helpful steps others have mentioned but have had no success (My guess is it is in the network setting below but I don't see the issue). What I am trying to do is seed an RDS database that is not accessible outside the VPC it was created. I attempt to update the packages in the instance and all attempts timeout. I'm really confused and would appreciate some help. Thank you.

Below is a description of my environment:

  • VPC with public and private subnets, internet gateway attached
  • Routing table shows I'm connected to an internet gateway for ip4 and ip6 as well as local networking for public subnets
  • EC2 instance is hosted in a public subnet
  • NACLs allow http/s for ip4 and ip6 and ssh from my home network
  • Security groups that were created to connect the EC2 instance to RDS, sg for ssh-ing from home
  • Elastic IP is associated with EC2 instance
  • I am able to ssh into EC2 instance from home

Below are the public route table associated with the subnet where the EC2 instance resides, NACLs, and security groups. Public route tables associated with the subnet where EC2 instance is hosted:

DestinationTargetStatusPropogated
::/0igw-xxxxxxxxxxxxActiveNo
2600:1f14:de1:300::/56localActiveNo
0.0.0.0/0igw-xxxxxxxxxxxxActiveNo
10.0.0.0/16localActiveNo

Inbound NACLs

Rule NumberTypeProtocolPort rangeSourceAllow/Deny
100HTTP (80)TCP (6)800.0.0.0/0Allow
105HTTP (80)TCP (6)80::/0Allow
110HTTPS (443)TCP (6)4430.0.0.0/0Allow
115HTTPS (443)TCP (6)443::/0Allow
120SSH (22)TCP (6)22home ip4 cidrAllow
*All trafficAllAll0.0.0.0/0Deny
*All trafficAllAll::/0Deny

Outbound NACLs:

Rule NumberTypeProtocolPort rangeSourceAllow/Deny
100All trafficAllAll0.0.0.0/0Allow
101All trafficAllAll::/0Allow
102HTTP (80)TCP (6)800.0.0.0/0Allow
103HTTP (80)TCP (6)80::/0Allow
104HTTPS (443)TCP (6)4430.0.0.0/0Allow
105HTTPS (443)TCP (6)443::/0Allow
*All trafficAllAll0.0.0.0/0Deny
*All trafficAllAll::/0Deny

EC2 security groups:

sg-local-ssh inbound rule:

TypeProtocolPort rangeDestinationDescription
SSHTCP22ip4/32ssh from home

sg-local-ssh outbound rules:

TypeProtocolPort rangeDestinationDescription
All trafficAllAll0.0.0.0/0ip4
All trafficAllAll::/0ip6

ec2-rds security group inbound rules:

TypeProtocolPort rangeDestinationDescription
PostgreSQL5432Alllocal ip cidrip4
PostgreSQL5432Alllocal ip cidrip6

ec2-rds security group outbound rules:

TypeProtocolPort rangeDestinationDescription
PostgreSQLTCP5432rds-ec2-security-groupsecurity group connecting rds to ec2
All trafficAllAllhome ip cidrip6

RDS security inbound group:

TypeProtocolPort rangeDestinationDescription
PostgreSQLTCP5432ec2-rds-security-groupsecurity group to connect ec2 to rds

RDS security outbound group:

TypeProtocolPort rangeDestinationDescription
All trafficAllAllec2-rds-security-groupsecurity group to connect ec2 to rds
PostgreSQLTCP5432internal ip4 cidrip4
PostgreSQLTCP5432internal ip6 cidrip6
paul
asked 9 months ago515 views
3 Answers
1
Accepted Answer

Not answering the question directly but more general troubleshooting tips:

First, don't try and boil the ocean by setting up all of the things (routing, security groups, NACLs, etc.) all at the same time. Start with the minimal set of things and make sure that they work and after that add in additional components.

In this case, I would set up an instance in a public subnet with an public IP address and an Internet Gateway. Use the simplest security group you can and make sure it works.

After that, start locking down the security group(s).

Finally, add NACLs if you must - but I'd note that NACLs don't add a huge amount of value here if you're using security groups. They add complexity and make it harder to manage your network. I always advise customers that NACls are great for blocking whole subnets (e.g. "10.x.x.x cannot ever communicate 10.y.y.y.y") but trying to be very fine-grained with NACLs and deal with ephemeral ports is going to give you stress and increase your administrative burden. Security groups already do stateful packet filtering - only use NACLs when you find something that security groups don't do.

profile pictureAWS
EXPERT
answered 9 months ago
  • Thank you for guidance in troubleshooting. I am still looking through the items suggested. I really needed the, "don't try to boil the ocean" suggestion as I tend to try to do everything at once.

  • I created another less restrictive NACL and associated it with the subnet related to my EC2 instance. This fixed the issue. Thanks everyone for you assistance. I really appreciate it.

1

I noticed a couple of potential issues or areas to check:

  • Outbound NACL Rules: Your outbound Network Access Control Lists (NACLs) are currently allowing all outbound traffic (All traffic All All 0.0.0.0/0 and All traffic All All ::/0). While this is fine for general internet access, it's essential to ensure that your NACL rules allow outbound traffic initiated by your EC2 instance, including responses to its requests. The default outbound rules in NACLs should generally allow all traffic (0.0.0.0/0 and ::/0) as you have it.
  • DNS Resolution: Ensure that your EC2 instance can resolve DNS properly. Issues with DNS resolution can lead to timeouts when trying to access external resources, as package managers often rely on DNS to locate repositories and resources.
  • Update Package Manager Configuration: Sometimes, package managers may be configured to use specific repositories that are unreachable or slow. You can check and update your package manager's configuration to use mirrors or repositories that are geographically closer to your AWS region.
  • Check System Logs: If the timeout issue persists, it may be helpful to check the system logs on your EC2 instance for any error messages or indications of network connectivity issues. You can typically find these logs in /var/log.
  • Security Group Logging: Consider enabling VPC Flow Logs for your security groups. Flow Logs can help you analyze network traffic and diagnose connectivity issues by providing detailed information about the traffic that is allowed or denied by your security groups and NACLs.
  • Route Table: Your route table looks correct with the default route pointing to the internet gateway. However, verify that your EC2 instance also uses this route table.
  • EC2 Instance Firewall: Ensure that there are no local firewalls or security software running on your EC2 instance that might be blocking outgoing traffic.

If you continue to experience timeouts when trying to update packages on your EC2 instance after checking these points, examining the system logs and reviewing the specific error messages encountered during package updates would be a useful next step in diagnosing the issue. Hope this helps!

profile pictureAWS
JC
answered 9 months ago
  • Thank you for the guidance. I am presently addressing the items suggested.

    In terms of DNS resolution, I am able to use nslookup to display the correct public DNS and IP address for the EC2 instance from my computer. From within the EC2 instance I am not able to resolve public-facing websites with curl or wget - the commands time out.

    I have checked /var/logs and no error logs have been created in the EC2 instance.

    Flow logs are now enabled for the EC2 instance and RDS security groups.

    Subnet is pointed to the correct route table.

  • Since you mentioned, "From within the EC2 instance I am not able to resolve public-facing websites with curl or wget - the commands time out." Please look at bullets #1 and #2 above.
    #1. "ensure that your NACL rules allow outbound traffic initiated by your EC2 instance, including responses to its requests." #2. "Ensure that your EC2 instance can resolve DNS properly."

1

Elastic IP is associated with EC2 instance

I'd like to explore this a bit more.

When the instance was first provisioned, did it have a public IP address?

And independently of provisioning the instance, did you allocate an elastic IP address, and then associate that IP address with a network interface, and then attach the network interface to the instance?

And since then have you stopped and started the instance?

Because you mention SSH I assume the OS is Linux, so what is the output of:

route -n
ip a

In particular, note the device that the default route uses in route -n.

Then find this device in the output of ip a and make a note of its IP address.

Then find the interface with this (private) IP address in the EC2 Console https://console.aws.amazon.com/ec2/home#NIC: (make sure it's set to the correct region).

Does this interface - the one that's being used for the default route - have a public IP address?

profile picture
EXPERT
Steve_M
answered 9 months ago
  • Thank you for the follow-up questions. When first provisioned, the instance had a public IP. I had previously allocated an Elastic IP based on guidance from the docs and questions posted here. The Elastic IP was then associated with the instance. As far as I know I only associated the Elastic IP with the instance and not a network interface. I remember the option and selected "Instance".

    Regarding the route and ip commands, I have verified the NIC exists, is in the correct region, and has a public IP address - the Elastic IP address. There is also a public DNS entry that corresponds with the Elastic IP address.

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.

Guidelines for Answering Questions