Allow Amazon VPC A to migrate to a new private subnet on VPC B?

Question

I have an existing VPC ( vpcA ) and have recently configured a new VPC ( vpcB ) from both a private subnet ( privateSubnet ) and an open subnet ( publicSubnet ). I want to allow connection from vpcA to vpcB .

vpcB was configured with the Bastion server to allow ssh from publicSubnet and privateSubnet - it works, so I know that ssh is configured correctly ... so for a start I decided that I would try to allow ssh connection from vpcA to privateSubnet on vpcB .

I established a peer-to-peer connection and I followed all the instructions in the Amazon Troubleshooting Guide for troubleshooting VPC peer-to-peer network connection problems . The connection is active, I have the configuration of routes from vpcA to the route 10.0.1.0/24 to the private network (private address - 10.0.1.10 ), ACL policies display allow all traffic on port 22 (at the moment) and security groups allow access to the port 22 (again at the moment). In the instances themselves there are no firewall rules, but when I try to connect via ssh from the instance on vpcA , I get:

 $ 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] 

The ssh from the bastion server in publicSubnet on vpcB to privateSubnet on vpcB works fine, so I know that ssh itself works on the instance itself. But it’s obvious that traffic does not go through the VPC Peer connection.

I understand that troubleshooting may require more details than what I have provided so far, but does anyone there have this setting? Any suggestions on where to look next or what part of the configuration I can provide to give us clues about where the problem is?

Thanks!

Answer 1

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

Amazon's documentation of routing tables for VPC Peering refers to this need for this quote:

To enable traffic routing between VPCs in a VPC peer-to-peer connection, you must add a route to one or more of your VPC route tables that points to a VPC peer-to-peer connection to access all or part of the CIDR block of another VPC in the peer-to-peer connection. Likewise, the owner of another VPC must add a route to their VPC route table in order to redirect traffic to your VPC.

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

AWS currently does not support unidirectional return path redirection in VPC peer-to-peer connections that check the source IP address of packets and route the response packets back to the source.

So the general follows this advice and advice in the helloV post. But keep in mind that these routes must be bi-directional between the subnets in question so that you can receive packets in both directions.

Answer 2

The traceroute output suggests that there is no way to redirect your request.

• Make sure the CIDR for your vpcA and vpcB does not overlap.
• Check if the routing tables for the 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 purpose of route 10.0.1.0/24 should be a VPC peer-to-peer connection - starts with pcx -
• Is VPC peer to peer approved and active?
• If nothing works, send a screenshot of the subnet routing tables