Allowing Amazon VPC A to get to a new private subn

Question

I have an existing VPC (vpcA) and have recently setup a new VPC (vpcB) with both a private subnet (privateSubnet) and public subnet (publicSubnet). I want to allow connectivity from vpcA to vpcB.

vpcB was setup with a Bastion server to allow ssh from publicSubnet and privateSubnet - this works so I know ssh is setup properly... so to get started I figured I would try allow ssh connectivity from vpcA to the privateSubnet on vpcB.

I've setup a Peer Connection and I've followed all the instructions in Amazon's Troubleshooting guide on resolving VPC peer network connectivity issues. The connection is active, I have routes setup from vpcA to route 10.0.1.0/24 to the private network (the private address is 10.0.1.10), ACL policies appear to allow all traffic on port 22 (for now), and the security groups allow access on port 22 (again for now). There are no firewall rules currently configured on the instances themselves, but when I attempt to connect via ssh from an instance on vpcA what I get is:

$ ssh -vvv 10.0.1.10
OpenSSH_6.6.1, OpenSSL 1.0.1f 6 Jan 2014
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to 10.0.1.10 [10.0.1.10] port 22.
debug2: fd 3 setting O_NONBLOCK
debug1: connect to address 10.0.1.10 port 22: Connection timed out
ssh: connect to host 10.0.1.10 port 22: Connection timed out

traceroute gives me this:

traceroute to 10.0.1.10 (10.0.1.10), 30 hops max, 60 byte packets
1  * * *
2  * * *
... [same up to 30]

ssh from bastion server in publicSubnet on vpcB to privateSubnet on vpcB works fine so I know ssh itself is working on the instance itself. But clearly traffic is not getting through the VPC Peer Connection.

I realize troubleshooting might require more detail than what I've so far provided but does anyone out there have this setup? Any suggestions on where to look next or what piece of configuration I can supply to give us hints on where the problem lies?

Thanks!

Answer 1

Your traceroute output suggests, there is no route to forward your request.

• Make sure the CIDR for your vpcA and vpcB do not overlap
• Check if the routing tables for private subnet and public subnets in vpcA have an entry for routing traffic to vpcB.
• There is a separate routing table for public and private.
• The target for the route 10.0.1.0/24 should be the VPC peering connection - starts with pcx-
• Is the VPC peering connection approved and active?
• If nothing works, post a screenshot of subnets' routing tables

Answer 2

All of the things mentioned by helloV need to be covered since there are many things that can go wrong here. However, my specific case was that I had entries to route from vpcA to vpcB BUT no route for the return traffic from vpcB to vpcA.

The Amazon documentation on routing tables for VPC Peering alludes to this need in this quote:

To enable the routing of traffic between VPCs in a VPC peering connection, you must add a route to one or more of your VPC route tables that points to the VPC peering connection to access all or part of the CIDR block of the other VPC in the peering connection. Similarly, the owner of the other VPC must add a route to their VPC route table to route traffic back to your VPC.

The last sentence here is the key - and the examples mentioned highlight the issue. Honestly I was a little confused by this initially but this explanation which refers to overlapping CIDR blocks in routes also sheds light on why this route is needed:

AWS currently does not support unicast reverse path forwarding in VPC peering connections that checks the source IP of packets and routes reply packets back to the source.

So overall follow this advice and the advice in helloV's post. But keep in mind that those routes need to be bi-directional between the subnets in question in order for you to get packets flowing in both directions.