2

In order to allow instances in a VPC in Oregon (us-west-2) to contact instances on another VPC in Ireland (eu-west-1), I've installed OpenSwan gateway machines on both regions and established an IPSEC tunnel between the two regions which operates properly.

Details:
Oregon VPC CIDR: 172.31.0.0/16
Ireland VPC CIDR: 172.91.0.0/16

In Ireland, I've used a CloudFormation template which I wrote to create a new stack which among other stuff creates a new isolated VPC and one of the tasks that CloudFormation is running is to peer between the default Ireland VPC and the newly created (isolated) VPC.

The new isolated VPC CIDR: 172.52.0.0/16.

At the moment, if I run a ping command from an instance residing in the default VPC in Oregon (172.31.x.x) toward an instance residing in the Ireland default VPC (172.91.x.x) it works like a charm.

Next, I would like machines in the new isolated VPC (172.52.x.x) to be able to reach instances in the default VPC in Oregon (172.31.x.x).

The route table which is associated with the default VPC in Oregon is configured to route traffic:

to: 172.52.0.0/16 GW: Interface of the OpenSwan server in Oregon.
to: 172.91.0.0/16 GW: Interface of the OpenSwan server in Oregon.

The route table which is associated with the default VPC in Ireland is configured to route traffic:

to: 172.31.0.0/16 GW: Interface of the OpenSwan server in Ireland.
to: 172.52.0.0/16 GW: The peering connection ID (between 172.52.x.x and 172.91.x.x)

Security group which is attached to OpenSwan instance @ Oregon:

Allows all traffic to 172.52.x.x/16, 172.91.x.x/16, 172.31.x.x/16.
Allows UDP 500 and 4500 to the EIP of the OpenSwan instance in Ireland.

Security group which is attached to OpenSwan instance @ Ireland:

Allows all traffic to 172.52.x.x/16, 172.91.x.x/16, 172.31.x.x/16.
Allows UDP 500 and 4500 to the EIP of the OpenSwan instance in Oregon.

ipsec.conf:

version 2.0     # conforms to second version of ipsec.conf specification

# basic configuration
config setup
        protostack=netkey
        nat_traversal=yes
        virtual_private=%v4:10.0.0.0/8,%v4:192.168.0.0/16,%v4:172.16.0.0/12,%v4:172.91.0.0/16,%v4:172.52.0.0/16,%v4:25.0.0.0/8,%v4:172.31.0.0/16,%v4:172.59.0.0/20,%v6:fd00::/8,%v6:fe80::/10
        oe=off

include /etc/ipsec.d/*.conf

I am able to ping an instance residing in the default VPC of Oregon from each one of the OpenSwan machines (Oregon/Ireland) and vice versa but I'm unable to ping that instance from an instance residing in the 172.52.x.x/16 subnet.

Which route you think I'm missing? I need to allow instances in the isolated VPC in Ireland to reach the default VPC in Oregon.

HBruijn
  • 72,524
  • 21
  • 127
  • 192
Itai Ganot
  • 10,424
  • 27
  • 88
  • 143
  • Can instances in the isolated VPC ping the Ireland open swan server? Have you considered setting up a second tunnel to directly connect from the isolated VPC to Oregon? Rather than double hopping it. – Appleoddity Dec 03 '17 at 19:15
  • Per your question, yes, instances in the isolated VPC in Ireland are able to ping the OpenSwan instance in Ireland. In addition, I wanted the tunnel to stay active all the time as the stack can be taken down any day and then back up, if there won't be any other way around it, I'll do it like you proposed. – Itai Ganot Dec 04 '17 at 08:35

2 Answers2

1

Your Config won't work because VPC peering isn't transitive, see: http://docs.aws.amazon.com/AmazonVPC/latest/PeeringGuide/invalid-peering-configurations.html#transitive-peering for the offical doc on it. what this means for your setup is that only traffic between ireland Default VPC and Ireland Isolated VPC will flow (172.91.0.0/16 <-> 172.91.0.0/16)

The packets from Oregon destined to the isolated VPC (172.31.0.0/16 <-> 172.52.0.0/16) will be dropped by the peering link, even if you put routes in both the isolated and default VPCs route tables, which I think you are missing.

If you only need connective in one direction (ie server in isolated VPN client in Oregon. you could have the openVPN instance Ireland NAT traffic from Oregon towards the Isolated VPC.. this would make the traffic across the peering link be sourced from 172.91.0.0/16 which is allowed.

IF NAT isn't going to work you'll need to setup direct connectivity between the isolated VPC and the Oregon VPC, either with more VPN tunnels or the new cross-region peering https://aws.amazon.com/about-aws/whats-new/2017/11/announcing-support-for-inter-region-vpc-peering/ (note I haven't used it yet so I have no idea what additional limitations it may have)

Nath
  • 1,282
  • 9
  • 10
1

Ok, so it seems like Amazon heard my call and extended their current "create-vpc-peering" command just a few days ago and it now allows to peer VPC's across different regions.

It also seems like at the moment it is not yet supported by AWS Cloud Formation, but it can be done through the UI and the Cli.

If you look in Amazon's official documentation - create-vpc-peering, you will see a new switch: 

[--peer-region <value>]

So the need for VPN between the regions is no longer because I can use this cross region peering feature to achieve my goal of establishing networking between my isolated VPC in Ireland and the Management VPC in Oregon.

Itai Ganot
  • 10,424
  • 27
  • 88
  • 143