Confused about SSH into private EC2 instance from a public EC2 instance

Question

I have two separate NACLs, one for my public subnet and one for my private subnet. I am able to SSH into my public EC2 instance but not able to SSH into the private one without adding an outbound rule for my private NACL that allows ALL TCP to be open. What I'm confused about is why SSH fails if I only specify port 22 to be open on my private NACL outbound and inbound rule.

Answer 1

NACLs are stateless and need both inbound and outbound rules to allow a specific type of communication.For example ,if you want to access an ec2 instance on using ssh (tcp port 22) ,then in the inbound direction you will need to allow tcp port 22 and for the outbound direction ,since the destination port can be anything in the range 1024-65535 (depending on the client os),you will need to have such kind of rule for the ssh access.

Inbound
Rule # Type Protocol Port Range Source Allow/Deny
101 SSH TCP 22 (CLIENT IP or 0.0.0.0/0) Allow
Outbound
Rule # Type Protocol Port Range Destination Allow/Deny
101 Custom TCP TCP 1024-65535 (CLIENT IP or 0.0.0.0/0) Allow

ref:https://docs.aws.amazon.com/vpc/latest/userguide/vpc-network-acls.html#custom-network-acl

Now specifically to your setup,rules need to be created depending on how you are trying to access your ec2 instance in the private subnet.If you are using a bastion host to connect to your ec2 instance in private subnet ,then you will need to allow that ip/port in the outbound nacl rule .If you are using VPN then the rules will need to be changed accordingly.Perhaps more details about the nacl rule in your public and private subnet and how you are accessing the instances should help us provide more details on the problem.

Answer 2

As a general rule, you should never modify NACLs. They can be used for specific purposes (such as creating a DMZ), but there is rarely a need to change them from their default "Allow All" settings.

Instead, you should be using Security Groups to manage network permissions.

The typical configuration for your scenario would be:

• On the Public (Bastion) instance, add a Security Group (Bastion-SG) that permits Inbound connections on port 22 (SSH) from your IP address (it is a good idea to restrict such access to the smallest possible range of IP addresses to prevent unauthorized access)
• On the Private instance, add a Security Group (Private-SG) that permits Inbound connections on port 22 from Bastion-SG

This way, the Private-SG specifically references Bastion-SG, which will allow connections from the Bastion. Access attempts from any other location will be denied.

Security Groups are stateful, which means that return traffic will be permitted. This works well with SSH, which could use a range of different port numbers for return traffic.