Can't understand security group rule when accessing ssh over vpn

Question

i have a vpc, a subnet with an instance running, and a split tunnel VPN endpoint associated to that subnet.

My VPN has 20.0.0.0/22 as its client CIDR. My computer when connected receives the IP 20.0.0.132.

When the security group for the instance has an inbound rule for SSH with Source 20.0.0.0/16, I CANNOT connect.
When I change the rule to have Source 10.0.0.0/16, I CAN connect.

I don't understand and would appreciate anyone explaining this to me. Is the 20.0.0.132 ip address considered my public IP when connected to the VPN and I am being assigned a 10.0.0.0/16 IP when inside the subnet?

re:Post Agent · Accepted Answer

The behavior you're experiencing suggests that there's a discrepancy between the IP address you think you're connecting from and the actual source IP address seen by the EC2 instance. This is likely due to how your VPN and AWS network are configured.

When you connect to your EC2 instance through the VPN, the traffic is likely being routed through the VPC's internal network. In this case, the source IP address seen by the EC2 instance would be an internal IP address (likely in the 10.0.0.0/16 range) rather than the VPN client IP address (20.0.0.132) you're assigned.

This explains why allowing 10.0.0.0/16 in the security group works, while 20.0.0.0/16 doesn't. The security group is seeing the internal IP address, not your VPN client IP.

To resolve this, you have a few options:

1. Keep the security group rule allowing 10.0.0.0/16, as this seems to be working.

2. If you want to restrict access further, you could narrow down the IP range in the security group to only the specific subnet IPs used by your VPN connection within the VPC.

3. Check your VPN and VPC configurations to see if there's a way to preserve the original source IP. This might involve adjusting NAT settings or VPN configurations.

4. If you need to use the 20.0.0.0/16 range for security reasons, you may need to reconfigure your VPN to ensure the original client IP is preserved when traffic reaches the EC2 instance.

Remember, security groups operate based on the immediate source of the traffic they receive. In your case, that appears to be an internal VPC IP rather than your VPN client IP.
      
**Sources**  
[vpn ip is blocked from access my ec2 server | AWS re:Post](https://repost.aws/questions/QU-zf1Em0xQkeAovGduaMJBw/vpn-ip-is-blocked-from-access-my-ec2-server)  
[allow security group , which associated with other ec2, to allow it access | AWS re:Post](https://repost.aws/questions/QUCmR7_UepQXiEA5ABG4XKSA/allow-security-group-which-associated-with-other-ec2-to-allow-it-access)

Riku_Kobayashi · Answer

Hello.

The packet reaches EC2 after being NATed to the IP address attached to the Client VPN endpoint.  
When setting up permissions by IP address in the EC2 security group, you need to allow the IP addresses of the subnet or ENI attached to the Client VPN endpoint, not the "Client CIDR" of the Client VPN endpoint.  
If you are in the same VPC, you can also connect by configuring the EC2 security group to allow the security group set for Client VPN.  
https://docs.aws.amazon.com/vpn/latest/clientvpn-admin/how-it-works.html#scenario  
https://aws.amazon.com/jp/blogs/networking-and-content-delivery/using-aws-client-vpn-to-scale-your-work-from-home-capacity/  
> The Client VPN endpoint attaches to one or more subnets per AZ. For high availability, at least two subnets are recommended. The attachment creates an elastic network interface (ENI) in the subnet. All of the network traffic from the client subnet is NATed (Network Address Translated) to the ENI IP address. This allows connected clients to use the subnet route table to connect to resources both inside and outside of the VPC.

Can't understand security group rule when accessing ssh over vpn

Relevant content