- Newest
- Most votes
- Most comments
Is an internet gateway (IGW) attached to the VPC where your instance resides?
In the EC2 management console, open the instance properties, and under "networking", click the subnet where the instance resides. Is there a default route for 0.0.0.0/0 with the IGW specified as the next hop?
In the instance properties, is a public IPv4 address shown, and is that the IP you're trying to SSH to?
In the security group(s) configured for the instance (and technically attached to its network interface/s), is outbound traffic permitted towards 0.0.0.0/0? And is inbound access to tcp/22 permitted from the public IP address from which you are trying to connect via SSH?
VPC Block Public Access could be enabled. When set to bidirectional block, all ingress and egress VPC traffic is denied.
Can you go to VPC console, Settings and check the Block public access section?
Block public access is not enabled.
You could use the VPC Reachability Analyzer to run a trace through the AWS network components from your instance to a manually entered destination IP address (such as 8.8.8.8 for Google's public DNS as an example) on a generic port number, such as tcp/443: https://docs.aws.amazon.com/vpc/latest/reachability/getting-started.html
However, since you already checked all the most likely causes of the problem, and given that you mentioned having recreated the VPC, ensuring that no block rules exist in the subnet's network ACL, it sounds more likely that the issue is with your instance. You might want to check the local firewall, such as iptables, for rules limiting outbound access. Also check if DNS resolution is working from the command line.
If everything above checks out, you could run a traceroute towards 8.8.8.8, for example. Does it show as receiving a response from the default gateway (ensuring that the operating system is routing the packet out to the VPC) and any responses from intermediate hops beyond the default gateway?
A traceroute or curl attempt might also directly show an error about the connection attempt failing immediately, rather than after a timeout, in case the local firewall blocked the attempt.
No local firewall at play here, it happens on every AMI I try. Linux, FreeBSD, etc
VPC Reachability Analyzer might be the quickest way to find out if anything is out of place, such as a network ACL blocking the connections. It traces the full path through the relevant AWS components. Running a traceroute from the instance to 8.8.8.8 should help to narrow down the issue, if the Reachability Analyzer finds nothing wrong.
I created a flow log and see this
2 989240142699 eni-0c78751e22ebb5ca8 97.x.x.x 172.31.21.249 28011 22 6 10 600 1735742671 1735742730 REJECT OK, but the Reachability Analyzer says everything is fine.That log entry is for an inbound SSH connection, and since you haven't got Block Public Access enabled for the VPC, the "REJECT" action practically means that either the security group(s) attached to the ENI eni-0c78751e22ebb5ca8 didn't permit the connection, or that a network ACL (NACL) blocked the attempt. What did the outbound traceroute from the instance show?
Both the SG attached to the ENI and the NACL are completely permissive, both in and outbound. The only AMI I've managed to get into solely via serial console is FreeBSD with an empty password. The Amazon Linux, Ubuntu, etc. AMIs expect key-based authentication. From the FreeBSD instance, traceroute just times out. But again, this can't be an host level firewall issue because every AMI that I use to spin up an instance in u\s-east-1 behaves the same...no internet access
This is a long shot, but could AWS Network Firewall be in play here? Could it have been enabled in us-east-1 (but not any other regions) a long time ago, by you or somebody else in your organisation, and you've forgotten about it? https://docs.aws.amazon.com/prescriptive-guidance/latest/secure-outbound-network-traffic/restricting-outbound-traffic.html#restricting-outbound-traffic-network-firewall-hostnames
It's probably not that though.
I find it curious that you're not able to SSH into any of the instances you're spinning up, and that you can only get into the FreeBSD instance via the serial console. Are the instances definitely being created with public IPv4 addresses? Check the IPv4 public addressing attribute of the subnet(s) in the VPC in us-east-1 https://docs.aws.amazon.com/vpc/latest/userguide/subnet-public-ip.html
I know you said that you recreated the Default VPC, and so this should be set to true, but it's worth checking.
Relevant content
asked 2 years ago
- AWS OFFICIALUpdated 2 years ago
- AWS OFFICIALUpdated 2 years ago
Yes
Yes
Yes. And even from the serial console to the EC2 instance, I am unable to ping outbound or reach any internet resource. I am able to ping the default gateway in the VPC subnet from the EC2 instance. So that at least works.
Yes.
Comparing things to another region that works like us-east-2, I see nothing out of the ordinary. They both look bog standard and boring.
Creating a non-default VPC works in every other region except u\s-east-1. So I know the steps I'm taking work.