EdgeRouter - IPsec Route-Based Site-to-Site VPN to AWS VPC (VTI over IKEv1/IPsec)

Overview


Readers will learn how to configure a Route-Based Site-to-Site IPsec VPN between an EdgeRouter and the Amazon Web Services (AWS) Virtual Private Cloud (VPC). A Route-Based VPN is characterized by the usage of Virtual Tunnel Interfaces (vti) and routing entries. This example uses static routing but is also possible to use dynamic routing with BGP

NOTES & REQUIREMENTS:
Applicable to the latest EdgeOS firmware on all EdgeRouter models. Knowledge of the Command Line Interface (CLI) and basic networking knowledge is required. Please see the Related Articles below for more information and see the attachments for the configuration used in this article.
 
Devices used in this article:
  • EdgeRouter-4
  • AWS Virtual Private Gateway (VGW)
  • Test clients

 

AWS Requirements:

- Static public IP address on the ER

- If behind NAT forward UDP ports 4500 (NAT-T) and 500 (IKE) on the NATting device, as well as configure Approach #2 in this article.

- Active AWS subscription

 

More information about Amazon VPC and customer requirements can be found in the AWS Managed VPN Connections article.


Table of Contents


  1. Network Diagram
  2. Steps: Route-Based VPN
  3. Steps: Amazon Virtual Private Gateway
  4. Steps: Testing & Verification
  5. Related Articles

FAQ


Back to Top

1. Can I also use  dynamic routing with BGP instead of static routing?
2. What is the function of traffic offloading and how does it affect IPsec tunnels?

Offloading is used to execute functions of the router using the hardware directly which greatly increases performance. If traffic is not offloading, it is routed using the CPU with limited performance. Please see the Hardware Offloading article for more information.

 

Packets passed through an IPsec tunnel are eligible for offloading and thus routed via hardware when IPsec offloading is enabled. You can enable IPsec offloading via the Command Line Interface (CLI) with:

configure
set system offload ipsec enable
commit ; save
3. Do I need to create firewall rules for IPsec and exclude the traffic from NAT?

You do not need to create any firewall or NAT policies for IPsec if you add the auto-firewall-nat-exclude statement in the CLI.

 

If you wish to create your own firewall/NAT policies, please follow the steps in the EdgeRouter - IPsec Site-to-Site VPN Additions and Changes (CLI) article.

4. How do I start troubleshooting if my VPN does not establish?
  • Send relevant traffic (ping) over the tunnel between two hosts located behind the EdgeRouters.
  • Verify the state of the VPN tunnel using the CLI.
  • Capture the IPsec traffic on the WAN interface using the CLI.
  • Analyze the VPN log messages.
  • Verify if any host-based firewalls are blocking the (ping) traffic.

 

All of these verification steps are shown in the Testing & Verification section.


Network Diagram


Back to Top

The network topology is shown below. 

 

EdgeRouter (ER)

  • eth0 - 203.0.113.1
  • eth1 - 192.168.1.1/24
  • vti0 - 169.254.x.x/30
  • vti1 - 169.254.x.x/30

AWS

  • vgw - 192.0.2.1
  • vgw - 198.51.100.1
  • vpc cidr - 172.16.0.0/22
  • vpc subnet - 172.16.1.0/24

NOTE: Amazon uses two tunnels for VPN connections, with each tunnel using a unique virtual private gateway public IP address (192.0.2.1 and 198.51.100.1 in this example). This means that two IPsec peers need to be configured on the EdgeRouter.

Steps: Route-Based VPN


Back to Top

For the purpose of this article, it is assumed that the routing and interface configurations are already in place and that reachability has been tested. The AWS peer IP addresses can be found under 'VPC Dashboard > VPN Connections > Tunnel Details'. 

CLI: Access the command line interface (CLI). You can do this using the CLI button in the GUI or by using a program such as PuTTY.

1. Enter configuration mode.

configure

2. Enable the auto-firewall-nat-exclude feature which automatically creates the IPsec firewall/NAT policies in the iptables firewall.

set vpn ipsec auto-firewall-nat-exclude enable

3. Create the IKE / Phase 1 (P1) Security Associations (SAs) and enable Dead Peer Detection (DPD).

set vpn ipsec ike-group FOO0 key-exchange ikev1
set vpn ipsec ike-group FOO0 lifetime 28800
set vpn ipsec ike-group FOO0 proposal 1 dh-group 2
set vpn ipsec ike-group FOO0 proposal 1 encryption aes128
set vpn ipsec ike-group FOO0 proposal 1 hash sha1
set vpn ipsec ike-group FOO0 dead-peer-detection action restart
set vpn ipsec ike-group FOO0 dead-peer-detection interval 15
set vpn ipsec ike-group FOO0 dead-peer-detection timeout 30

4. Create the ESP / Phase 2 (P2) SAs.

set vpn ipsec esp-group FOO0 lifetime 3600
set vpn ipsec esp-group FOO0 pfs enable
set vpn ipsec esp-group FOO0 proposal 1 encryption aes128
set vpn ipsec esp-group FOO0 proposal 1 hash sha1

5. Define the first AWS peer address (replace <secret> with the AWS generated passphrase).

set vpn ipsec site-to-site peer 192.0.2.1 authentication mode pre-shared-secret
set vpn ipsec site-to-site peer 192.0.2.1 authentication pre-shared-secret <secret>
set vpn ipsec site-to-site peer 192.0.2.1 connection-type initiate
set vpn ipsec site-to-site peer 192.0.2.1 description IPsecAWS
set vpn ipsec site-to-site peer 192.0.2.1 local-address 203.0.113.1

6. Link the SAs created above to the first AWS peer and bind the VPN to a virtual tunnel interface (vti0).

set vpn ipsec site-to-site peer 192.0.2.1 ike-group FOO0
set vpn ipsec site-to-site peer 192.0.2.1 vti bind vti0
set vpn ipsec site-to-site peer 192.0.2.1 vti esp-group FOO0

7. Repeat the process for the second AWS peer address using a different virtual tunnel interface (vti1)

set vpn ipsec site-to-site peer 198.51.100.1 authentication mode pre-shared-secret
set vpn ipsec site-to-site peer 198.51.100.1 authentication pre-shared-secret <secret>
set vpn ipsec site-to-site peer 198.51.100.1 connection-type initiate
set vpn ipsec site-to-site peer 198.51.100.1 description IPsecAWS
set vpn ipsec site-to-site peer 198.51.100.1 local-address 203.0.113.1

set vpn ipsec site-to-site peer 198.51.100.1 ike-group FOO0
set vpn ipsec site-to-site peer 198.51.100.1 vti bind vti1
set vpn ipsec site-to-site peer 198.51.100.1 vti esp-group FOO0

8. Configure the RFC 3927 IP addresses on the virtual tunnel interfaces.

set interfaces vti vti0 address 169.254.x.x/30
set interfaces vti vti1 address 169.254.x.x/30
NOTE: The IP addresses used above can be found in the downloaded 'Vyatta Network OS' configuration file. You can also calculate them based on the 169.254.x.x/30 addresses listed under 'VPC Dashboard > VPN Connections > Tunnel Details'.

9. Lower the TCP Maximum Segment Size (MSS) on the vti interfaces to 1379.

set firewall options mss-clamp interface-type vti
set firewall options mss-clamp mss 1379

10. Create static routes for the remote VPC subnet.

set protocols static interface-route 172.16.0.0/22 next-hop-interface vti0
set protocols static interface-route 172.16.0.0/22 next-hop-interface vti1

11. Commit the changes and save the configuration.

commit ; save

Steps: Amazon Virtual Private Gateway


Back to Top

The names of the AWS gateway connections and subnets are randomly generated and unique for each environment. For your reference, the names used in this example are:

  • vpc: vpc-f8e99891
  • sbn: subnet-fb400392
  • rtbl: rtb-389cd051
  • cgw: cgw-4e2ca07e
  • vgw: vgw-d5c945e5
  • vpn: vpn-2704cf10
GUI: Access the AWS Management Console.

1. If not already created, create a new virtual private cloud (vpc).

Services > VPC > VPC Dashboard > Your VPCs > Create VPC

IPv4 CIDR Block: 172.16.0.0/22
IPv6 CIDR Block: No IPv6 CIDR Block
Tenancy: default

 

2. If not already created, create a new subnet in the vpc address range. 

VPC Dashboard > Subnets > Create Subnet

VPC: vpc-f8e99891
VPC CIDRs: 172.16.0.0/22
Availability Zone: No Preference
IPv4 CIDR Block: 172.16.1.0/24

3. Create a new customer gateway (cgw) and enter the EdgeRouter's public IP address.

VPC Dashboard > Customer Gateways > Create Customer Gateway

Name: IPsecER
Routing: Static
IP Address: 203.0.113.1

4. Create a new virtual private gateway (vgw).

VPC Dashboard > Virtual Private Gateways > Create Virtual Private Gateway

Name: IPsecER
ASN: Amazon default ASN

5. Attach the vgw to the vpc created earlier.

VPC Dashboard > Virtual Private Gateway > IPsecER > Actions > Attach to VPC

6. Propagate the routes that will be received on the vgw to the vpc.

VPC Dashboard > Route Tables > Route Propagation > Edit

Check Propagate: IPsecER Virtual Private Gateway

NOTE: This step ensures that the AWS virtual hosts receive a route for the 192.168.1.0/24 network after the VPN establishes.

7. Create a new VPN connection and associate the previously created vgw and cgw.

VPC Dashboard > VPN Connections > Create VPN Connection

Name tag: IPsecER
Virtual Private Gateway: vgw-d5c945e5
Customer Gateway: Existing
Customer Gateway ID: cgw-4e2ca07e
Routing Options: Static
Static IP Prefixes: 192.168.1.0/24
Tunnel Options: Generated by Amazon

8. Download the configuration which contains all the SAs, pre-shared keys and IP addresses.

VPC Dashboard > VPN Connections > IPsecER > Download Configuration

Vendor: Generic
Platform: Generic
Software: Vendor Agnostic


Steps: Testing & Verification


Back to Top

1. Verify that both tunnels are up for the VPN connection.

VPC Dashboard > VPN Connections > Tunnel Details

2. Verify that the remote EdgeRouter subnet is propagated to the vpc route table.

VPC Dashboard > Route Tables > Route Table

NOTE: You The output shows that the 192.168.1.0/24 network is reachable via the vgw and not via the default route (igw).

3. Verify that the customer gateway is available.

VPC Dashboard > Customer Gateways

4. Verify the IPsec Security Associations (SAs) and tunnel status.

show vpn ipsec sa
peer-192.0.2.1-tunnel-vti: #2, ESTABLISHED, IKEv1, 2e95d14d87b77239:727fcd2a809b88fc
  local  '203.0.113.1' @ 203.0.113.1
  remote '192.0.2.1' @ 192.0.2.1
  AES_CBC-128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
  established 181s ago, reauth in 27989s
  peer-192.0.2.1-tunnel-vti: #6, INSTALLED, TUNNEL-in-UDP, ESP:AES_CBC-128/HMAC_SHA1_96/MODP_1024
    installed 181 ago, rekeying in 2612s, expires in 3420s
    in  c534961b,  13656 bytes,   164 packets,    25s ago
    out dac7cc75,  13168 bytes,   158 packets,    26s ago
    local  0.0.0.0/0
    remote 0.0.0.0/0
peer-198.51.100.1-tunnel-vti: #1, ESTABLISHED, IKEv1, 2b77d65c21c6762a:a08e6fee029e7a95
  local  '203.0.113.1' @ 203.0.113.1
  remote '198.51.100.1' @ 198.51.100.1
  AES_CBC-128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
  established 200s ago, reauth in 27723s
  peer-198.51.100.1-tunnel-vti: #5, INSTALLED, TUNNEL-in-UDP, ESP:AES_CBC-128/HMAC_SHA1_96/MODP_1024
    installed 200 ago, rekeying in 2554s, expires in 3400s
    in  cc40e8b9,  12420 bytes,   114 packets,    50s ago
    out ca59c2c7,  12992 bytes,   120 packets,    49s ago
    local  0.0.0.0/0
    remote 0.0.0.0/0
NOTE: If there is no (or only partial) output, the tunnel is not established. Verify that the in and out traffic counters are increasing at the same time and that the remote and local subnets are listed as 0.0.0.0/0 in the output.

5. Verify the IPsec strongSwan configuration file.

sudo cat /etc/ipsec.conf
# generated by /opt/vyatta/sbin/vpn-config.pl

config setup

conn %default
        keyexchange=ikev1

conn peer-198.51.100.1-tunnel-vti
        left=203.0.113.1
        right=198.51.100.1
        leftsubnet=0.0.0.0/0
        rightsubnet=0.0.0.0/0
        ike=aes128-sha1-modp1024!
        keyexchange=ikev1
        ikelifetime=28800s
        dpddelay=15s
        dpdtimeout=30s
        dpdaction=restart
        esp=aes128-sha1-modp1024!
        keylife=3600s
        rekeymargin=540s
        type=tunnel
        compress=no
        authby=secret
        mark=9437185
        auto=route
        keyingtries=%forever
#conn peer-198.51.100.1-tunnel-vti

conn peer-192.0.2.1-tunnel-vti
        left=203.0.113.1
        right=192.0.2.1
        leftsubnet=0.0.0.0/0
        rightsubnet=0.0.0.0/0
        ike=aes128-sha1-modp1024!
        keyexchange=ikev1
        ikelifetime=28800s
        dpddelay=15s
        dpdtimeout=30s
        dpdaction=restart
        esp=aes128-sha1-modp1024!
        keylife=3600s
        rekeymargin=540s
        type=tunnel
        compress=no
        authby=secret
        mark=9437186
        auto=route
        keyingtries=%forever
#conn peer-192.0.2.1-tunnel-vti

6. Capture the IKE traffic on the WAN interface.

sudo tcpdump -i eth0 -n udp dst port 500 or port 4500 or esp   
IP 203.0.113.1.500 > 192.0.2.1.500: isakmp: phase 1 I ident
IP 192.0.2.1.500 > 203.0.113.1.500: isakmp: phase 1 R ident
IP 203.0.113.1.500 > 192.0.2.1.500: isakmp: phase 1 I ident[E]
IP 192.0.2.1.500 > 203.0.113.1.500: isakmp: phase 1 R ident[E]
IP 203.0.113.1.500 > 192.0.2.1.500: isakmp: phase 2/others I oakley-quick[E]
IP 192.0.2.1.500 > 203.0.113.1.500: isakmp: phase 2/others R oakley-quick[E]

IP 203.0.113.1.500 > 198.51.100.1.500: isakmp: phase 1 I ident
IP 198.51.100.1.500 > 203.0.113.1.500: isakmp: phase 1 R ident
IP 203.0.113.1.500 > 198.51.100.1.500: isakmp: phase 1 I ident[E]
IP 198.51.100.1.500 > 203.0.113.1.500: isakmp: phase 1 R ident[E]
IP 203.0.113.1.500 > 198.51.100.1.500: isakmp: phase 2/others I oakley-quick[E]
IP 198.51.100.1.500 > 203.0.113.1.500: isakmp: phase 2/others R oakley-quick[E]
NOTE: This is a live capture. If there is no output then the traffic is either not being generated or there is something blocking the traffic upstream.

7. Capture and analyze the IPsec VPN log messages.

sudo swanctl --log
[KNL] creating acquire job for policy 203.0.113.1/32[ipencap] === 198.51.100.1/32[ipencap] with reqid {5}
[IKE] initiating Main Mode IKE_SA peer-198.51.100.1-tunnel-vti[1] to 198.51.100.1
[NET] sending packet: from 203.0.113.1[500] to 198.51.100.1[500] (244 bytes)
[NET] received packet: from 198.51.100.1[500] to 203.0.113.1[500] (228 bytes)
[IKE] remote host is behind NAT
[NET] sending packet: from 203.0.113.1[4500] to 198.51.100.1[4500] (108 bytes)
[NET] received packet: from 198.51.100.1[4500] to 203.0.113.1[4500] (76 bytes)
[IKE] IKE_SA peer-198.51.100.1-tunnel-vti[1] established between 203.0.113.1[203.0.113.1]...198.51.100.1[198.51.100.1]
[IKE] CHILD_SA peer-198.51.100.1-tunnel-vti{5} established with SPIs and TS 0.0.0.0/0 === 0.0.0.0/0

[KNL] creating acquire job for policy 203.0.113.1/32[ipencap] === 192.0.2.1/32[ipencap] with reqid {6}
[IKE] initiating Main Mode IKE_SA peer-192.0.2.1-tunnel-vti[2] to 192.0.2.1
[NET] sending packet: from 203.0.113.1[500] to 192.0.2.1[500] (156 bytes)
[NET] received packet: from 192.0.2.1[500] to 203.0.113.1[500] (124 bytes)
[IKE] remote host is behind NAT
[NET] sending packet: from 203.0.113.1[4500] to 192.0.2.1[4500] (108 bytes)
[NET] received packet: from 192.0.2.1[4500] to 203.0.113.1[4500] (76 bytes)
[IKE] IKE_SA peer-192.0.2.1-tunnel-vti[2] established between 203.0.113.1[203.0.113.1]...192.0.2.1[192.0.2.1]
[IKE] CHILD_SA peer-192.0.2.1-tunnel-vti{6} established with SPIs and TS 0.0.0.0/0 === 0.0.0.0/0
NOTE: This is also a live capture. Alternatively, you can use the show vpn log | no-more command to view the entire IPsec log history.

8. Verify the routing table.

show ip route
C    *> 169.254.x.x/30 is directly connected, vti1
C    *> 169.254.x.x/30 is directly connected, vti0
S    *> 172.16.0.0/22 [1/0] is directly connected, vti1
     *>               [1/0] is directly connected, vti0 

Related Articles


Back to Top