AWS CIDR Not Within VPC Ranges – Troubleshooting

I would recommend the following considerations:

If you creating an IPSEC connection between your corporate LAN and your VPC, use a CIDR that is different than that on your corporate LAN. This will prevent routing overlaps and create an identity distinction for reference.

For very large networks, use at least different 16-bit masks in different regions eg

eu-west-1 10.1.0.0/16
us-east-1 10.2.0.0/16
us-west-1 10.3.0.0/16

For smaller networks, use a 24-bit mask in different regions eg

eu-west-1 10.0.1.0/24
us-east-1 10.0.2.0/24
us-west-1 10.0.3.0/24

Consider making a distinction between private and public subnets, eg

private 10.0.1.0/24 (3rd byte < 129)
public 10.0.129.0/24 (3rd byte > 128)

Don't over-allocate address space to subnets, eg

eu-west-1 10.0.1.0/26
eu-west-1 10.0.1.64/26
eu-west-1 10.0.1.128/26
eu-west-1 10.0.1.192/26

(62 hosts per subnet)

Don't under-allocate either. If you use a load of Elastic Load Balancers, remember that they will also consume available ip addresses on your subnets. This is a particularly true if you use ElasticBeanstalk.

You need a route and open network ACLs from the webserver-tier subnet back to the bastion-tier subnet or your response packets will never make it back to the server. Enable ICMP (and make sure your ping client is using ICMP only -- some use UDP packets by default) from webserver subnet to bastion and open the appropriate ephemeral TCP ports (range is generally OS-dependent; see http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_ACLs.html#VPC_ACLs_Ephemeral_Ports) from webserver-tier to bastion-tier.

If you run tcpdump on a webserver instance and a bastion instance simultaenously, you would likely see the webserver is getting the bastion packets and sending a response, but the bastion instance is never getting the response.