Setting up a VPN connection to Amazon VPC - routing

Question

I am having some real issues setting up a VPN between out office and AWS VPC. The "tunnels" appear to be up, however I don't know if they are configured correctly.

The device I am using is a Netgear VPN Firewall - FVS336GV2

If you see in the attached config downloaded from VPC (#3 Tunnel Interface Configuration), it gives me some "inside" addresses for the tunnel. When setting up the IPsec tunnels do I use the inside tunnel IP's (e.g. 169.254.254.2/30) or do I use my internal network subnet (10.1.1.0/24)

I have tried both, when I tried the local network (10.1.1.x) the tracert stops at the router. When I tried with the "inside" ips, the tracert to the amazon VPC (10.0.0.x) goes out over the internet.

this all leads me to the next question, for this router, how do I set up stage #4, the static next hop?

What are these seemingly random "inside" addresses and where did amazon generate them from? 169.254.254.x seems odd?

With a device like this, is the VPN behind the firewall?

I have tweaked any IP addresses below so that they are not "real". I am fully aware, this is probably badly worded. Please if there is any further info/screenshots that will help, let me know.

 Amazon Web Services
Virtual Private Cloud

IPSec Tunnel #1
================================================================================
#1: Internet Key Exchange Configuration

Configure the IKE SA as follows
  - Authentication Method    : Pre-Shared Key 
  - Pre-Shared Key           : ---
  - Authentication Algorithm : sha1
  - Encryption Algorithm     : aes-128-cbc
  - Lifetime                 : 28800 seconds
  - Phase 1 Negotiation Mode : main
  - Perfect Forward Secrecy  : Diffie-Hellman Group 2

#2: IPSec Configuration

Configure the IPSec SA as follows:
  - Protocol                 : esp
  - Authentication Algorithm : hmac-sha1-96
  - Encryption Algorithm     : aes-128-cbc
  - Lifetime                 : 3600 seconds
  - Mode                     : tunnel
  - Perfect Forward Secrecy  : Diffie-Hellman Group 2

IPSec Dead Peer Detection (DPD) will be enabled on the AWS Endpoint. We
recommend configuring DPD on your endpoint as follows:
  - DPD Interval             : 10
  - DPD Retries              : 3

IPSec ESP (Encapsulating Security Payload) inserts additional
headers to transmit packets. These headers require additional space, 
which reduces the amount of space available to transmit application data.
To limit the impact of this behavior, we recommend the following 
configuration on your Customer Gateway:
  - TCP MSS Adjustment       : 1387 bytes
  - Clear Don't Fragment Bit : enabled
  - Fragmentation            : Before encryption

#3: Tunnel Interface Configuration

Your Customer Gateway must be configured with a tunnel interface that is
associated with the IPSec tunnel. All traffic transmitted to the tunnel
interface is encrypted and transmitted to the Virtual Private Gateway.

The Customer Gateway and Virtual Private Gateway each have two addresses that relate
to this IPSec tunnel. Each contains an outside address, upon which encrypted
traffic is exchanged. Each also contain an inside address associated with
the tunnel interface.

The Customer Gateway outside IP address was provided when the Customer Gateway
was created. Changing the IP address requires the creation of a new
Customer Gateway.

The Customer Gateway inside IP address should be configured on your tunnel
interface. 

Outside IP Addresses:
  - Customer Gateway                : 217.33.22.33 
  - Virtual Private Gateway         : 87.222.33.42

Inside IP Addresses
  - Customer Gateway                : 169.254.254.2/30
  - Virtual Private Gateway             : 169.254.254.1/30

Configure your tunnel to fragment at the optimal size:
  - Tunnel interface MTU     : 1436 bytes


#4: Static Routing Configuration:

To route traffic between your internal network and your VPC, 
you will need a static route added to your router.

Static Route Configuration Options:

  - Next hop       : 169.254.254.1

You should add static routes towards your internal network on the VGW.
The VGW will then send traffic towards your internal network over 
the tunnels.        

IPSec Tunnel #2
================================================================================
#1: Internet Key Exchange Configuration

Configure the IKE SA as follows
  - Authentication Method    : Pre-Shared Key 
  - Pre-Shared Key           : ---
  - Authentication Algorithm : sha1
  - Encryption Algorithm     : aes-128-cbc
  - Lifetime                 : 28800 seconds
  - Phase 1 Negotiation Mode : main
  - Perfect Forward Secrecy  : Diffie-Hellman Group 2

#2: IPSec Configuration

Configure the IPSec SA as follows:
  - Protocol                 : esp
  - Authentication Algorithm : hmac-sha1-96
  - Encryption Algorithm     : aes-128-cbc
  - Lifetime                 : 3600 seconds
  - Mode                     : tunnel
  - Perfect Forward Secrecy  : Diffie-Hellman Group 2

IPSec Dead Peer Detection (DPD) will be enabled on the AWS Endpoint. We
recommend configuring DPD on your endpoint as follows:
  - DPD Interval             : 10
  - DPD Retries              : 3

IPSec ESP (Encapsulating Security Payload) inserts additional
headers to transmit packets. These headers require additional space, 
which reduces the amount of space available to transmit application data.
To limit the impact of this behavior, we recommend the following 
configuration on your Customer Gateway:
  - TCP MSS Adjustment       : 1387 bytes
  - Clear Don't Fragment Bit : enabled
  - Fragmentation            : Before encryption

#3: Tunnel Interface Configuration

Outside IP Addresses:
  - Customer Gateway                : 217.33.22.33 
  - Virtual Private Gateway         : 87.222.33.46

Inside IP Addresses
  - Customer Gateway                : 169.254.254.6/30
  - Virtual Private Gateway             : 169.254.254.5/30

Configure your tunnel to fragment at the optimal size:
  - Tunnel interface MTU     : 1436 bytes


#4: Static Routing Configuration:

Static Route Configuration Options:

  - Next hop       : 169.254.254.5

You should add static routes towards your internal network on the VGW.
The VGW will then send traffic towards your internal network over 
the tunnels.  

EDIT #1

After writing this post, I continued to fiddle and something started to work, just not very reliably. The local IPs to use when setting up the tunnels where indeed my network subnets. Which further confuses me over what these "inside" IP addresses are for.

The problem is, results are not consistent what so ever. I can "sometimes" ping, I can "sometimes" RDP using the VPN. Sometimes, Tunnel 1 or Tunnel 2 can be up or down.

When I came back into work today, Tunnel 1 was down, so I deleted it and re-created it from scratch. Now I cant ping anything, but Amazon AND the router are telling me tunnel 1/2 are fine.

I guess the router/vpn hardware I have just isnt up to the job.....

EDIT #2

Now Tunnel 1 is up, Tunnel 2 is down (I didn't change any settings) and I can ping/rdp again.

EDIT #3

Screenshot of route table that the router has built up. Current state (tunnel 1 still up and going string, 2 is still down and wont re-connect)

Solution 1

I am not sure, but I don't think you can do it with this device. AWS VPC Network guide requires your Customer Gateway to be configured with a tunnel interface that is associated with the IPSec tunnel and I do not see that option in Netgear's manual.

Edit: Can you try the following settings: (VPN / IPSec VPN / VPN Wizard)

Gateway,
ConnectionName,
<preshared_key>
Remote WAN: 87.222.33.42
Local WAN: 217.33.22.33
Remote LAN: 10.0.0.0
Remote Subnet mask: 255.255.252.0

Solution 2

I don't think it is a problem that only one tunnels works at a time. This is by design; AWS keeps one tunnel down, and only connects it if the other tunnel fails. See this text from the Windows documentation on AWS.

http://docs.aws.amazon.com/AmazonVPC/latest/NetworkAdminGuide/CustomerGateway-Windows.html#ConfFileData

"We suggest that you configure both tunnels as part of the VPN connection. Each tunnel connects to a separate VPN concentrator on the Amazon side of the VPN connection. Although only one tunnel at a time is up, the second tunnel automatically establishes itself if the first tunnel goes down. Having redundant tunnels ensure continuous availability in the case of a device failure. Because only one tunnel is available at a time, the AWS Management Console displays a yellow icon indicating that one tunnel is down. This is expected behavior, so there's no action required from you."

I have the same drama connecting as you using a Cisco/Linksys IPsec router. This router works fine with several other IPsec system it connects to like Cisco ASA, Vyatta, and StrongSwan, but the Amazon AWS VPN has this internal IP hassle. For 'Generic' devices it tells you to use this internal numbering, yet for other platforms like Cisco and Windows it makes no mention of internal numbering. It only works at all if I ignore the internal numbering and configure my subnet and the VPC subnet. But then there is not way to make this static route, and the tunnel only works from AWS to me, and not the other direction.

I have usually found a lot easier to set up StrongSwan on a t1.micro that it is to use AWS VPN.

Comments

[digital0011]

Thanks for the reply. Those settings where indeed the ones I was using, and using them (after tweeking the encryption after the wizard to SHA-1) the 2 tunnels establish. The problems I am having are after this stage. Getting information to flow over the VPN.

[digital0011]

Hi, see edit#2, things are working, sort of (tunnel 2 is down) the route table does indeed show the entire 10.0.0.0/24 subnet as single entries. all going out over the "lan" interface via the routers IP.

[Dusan Bajic]

can you paste screenshot of your full routing table?

[digital0011]

added the pic, see edit#3

[Dusan Bajic]

I am puzzled by the way it looks (it might be that it just has a strange way of displaying routes). Can you try deleting everything from your config related to tunnels, rebooting (if possible), then setup only tunnel1 and see how that goes?

[digital0011]

let us continue this discussion in chat