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

book_25x25white.png

NOTES & REQUIREMENTS:

Applicable to the latest EdgeOS firmware on all EdgeRouter models. Knowledge of the Command Line Interface (CLI) and advanced networking knowledge is required. Please see the Related Articles below for more information and see the attachments for the configuration used in this article.

 

Equipment used in this article:

EdgeRouter-4 (ER-4)

- AWS Virtual Private Gateway (VGW)

- Test clients behind the peers

 

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

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

info_i_25x25white.png

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. 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. 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

3. 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

4. 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

5. 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

6. 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

7. 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
info_i_25x25white.png

NOTE: The IP addresses used above can be found in the downloaded 'Generic / Vendor Agnostic' configuration file. You can also calculate them based on the 169.254.x.x/30 addresses listed under 'VPC Dashboard > VPN Connections > Tunnel Details'.  

8. 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

9. 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

10. 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

info_i_25x25white.png

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

info_i_25x25white.png

NOTE: 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
info_i_25x25white.png

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.

sudo ipsec statusall
Status of IKE charon daemon (strongSwan 5.2.2, Linux 3.10.14-UBNT, mips):
  uptime: 6 minutes, since Oct 04 11:28:15 2017
  malloc: sbrk 376832, mmap 0, used 286576, free 90256
  worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 6
Listening IP addresses:
  203.0.113.1
  192.168.1.1
Connections:
peer-198.51.100.1-tunnel-vti:  203.0.113.1...198.51.100.1  IKEv1, dpddelay=15s
peer-198.51.100.1-tunnel-vti:   local:  [203.0.113.1] uses pre-shared key authentication
peer-198.51.100.1-tunnel-vti:   remote: [198.51.100.1] uses pre-shared key authentication
peer-198.51.100.1-tunnel-vti:   child:  0.0.0.0/0 === 0.0.0.0/0 TUNNEL, dpdaction=restart
peer-192.0.2.1-tunnel-vti:  203.0.113.1...192.0.2.1  IKEv1, dpddelay=15s
peer-192.0.2.1-tunnel-vti:   local:  [203.0.113.1] uses pre-shared key authentication
peer-192.0.2.1-tunnel-vti:   remote: [192.0.2.1] uses pre-shared key authentication
peer-192.0.2.1-tunnel-vti:   child:  0.0.0.0/0 === 0.0.0.0/0 TUNNEL, dpdaction=restart
remote-access:  203.0.113.1...%any  IKEv1, dpddelay=15s
remote-access:   local:  [203.0.113.1] uses pre-shared key authentication
remote-access:   remote: uses pre-shared key authentication
remote-access:   child:  dynamic[udp/l2f] === dynamic[udp] TRANSPORT, dpdaction=clear
Routed Connections:
peer-192.0.2.1-tunnel-vti{6}:  ROUTED, TUNNEL
peer-192.0.2.1-tunnel-vti{6}:   0.0.0.0/0 === 0.0.0.0/0
peer-198.51.100.1-tunnel-vti{5}:  ROUTED, TUNNEL
peer-198.51.100.1-tunnel-vti{5}:   0.0.0.0/0 === 0.0.0.0/0
Security Associations (2 up, 0 connecting):
peer-192.0.2.1-tunnel-vti[2]: ESTABLISHED 3 minutes ago, 203.0.113.1[203.0.113.1]...192.0.2.1[192.0.2.1]
peer-192.0.2.1-tunnel-vti[2]: IKEv1 SPIs: 2e95d14d87b77239_i* 727fcd2a809b88fc_r, pre-shared key reauthentication in 7 hours
peer-192.0.2.1-tunnel-vti[2]: IKE proposal: AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
peer-192.0.2.1-tunnel-vti{6}:  INSTALLED, TUNNEL, ESP in UDP SPIs: c534961b_i dac7cc75_o
peer-192.0.2.1-tunnel-vti{6}:  AES_CBC_128/HMAC_SHA1_96, 13656 bytes_i (164 pkts, 39s ago), 13168 bytes_o (158 pkts, 39s ago)
peer-192.0.2.1-tunnel-vti{6}:   0.0.0.0/0 === 0.0.0.0/0
peer-198.51.100.1-tunnel-vti[1]: ESTABLISHED 3 minutes ago, 203.0.113.1[203.0.113.1]...198.51.100.1[198.51.100.1]
peer-198.51.100.1-tunnel-vti[1]: IKEv1 SPIs: 2b77d65c21c6762a_i* a08e6feee7a95_r, pre-shared key reauthentication in 7 hours
peer-198.51.100.1-tunnel-vti[1]: IKE proposal: AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
peer-198.51.100.1-tunnel-vti{5}:  INSTALLED, TUNNEL, ESP in UDP SPIs: cc40e8b9_i ca59c2c7_o
peer-198.51.100.1-tunnel-vti{5}:  AES_CBC_128/HMAC_SHA1_96, 420 bytes_i (5 pkts, 208s ago), 992 bytes_o (11 pkts, 62s ago)
peer-198.51.100.1-tunnel-vti{5}:   0.0.0.0/0 === 0.0.0.0/0

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   
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode

listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
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]
info_i_25x25white.png

NOTE: This is a live capture. If there is no output that means that the traffic is either not being generated by the peer(s), 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
info_i_25x25white.png

NOTE: This is also live capture. If there is no output that means that the traffic is either not being allowed through the firewall. 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
> - selected route, * - FIB route, p - stale info
IP Route Table for VRF "default"
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