EdgeRouter - Route-Based Site-to-Site VPN to Azure (VTI over IKEv2/IPsec)

 Overview


Readers will learn how to configure a Route-Based Site-to-Site IPsec VPN between a Microsoft Azure VPN gateway and an EdgeRouter using static routing.

A Route-Based VPN is characterized by the usage of Virtual Tunnel Interfaces (VTIs) and the usage of IKEv2 when connecting to Azure. This type of VPN differs from a Policy-Based VPN which relies on a definition of local and remote subnets (Proxy IDs). Please see the Azure Policy-Based (IKEv1/IPsec) and the Azure Route-Based (BGP over IKEv2/IPsec) articles for more information on these other methods.

 book_25x25.png  Notes & Requirements:

Applicable to EdgeOS 1.9.7 + firmware in all EdgeRouter models. Knowledge of the Command Line Interface (CLI), Azure Portal and advanced networking skills are required, as well as knowledge of Windows PowerShell. Please see the Related Articles below for more information.

 

Equipment used in this article:

EdgeRouter X (ER-X)

- Azure VPN Gateway

- Test clients behind the peers (Host1 and Server1)

 

Additional Azure Requirements:

- Public IP address on the EdgeRouter (cannot be located behind NAT)

- Active Azure subscription

 

More info about Azure VPNs and requirements can be found in the Microsoft About VPN Devices article.


Table of Contents


  1. Network Diagram
  2. Steps - Route-Based VPN
  3. Steps - Azure Gateway
  4. Steps - Testing & Verification
  5. Related Articles


Network Diagram


Back to Top

The network topology is shown below. The following interfaces / IP addresses are in use on the EdgeRouter (ER) and Azure VPN Gateway (GW):

ER-X

  • eth0 (WAN) - 203.0.113.1
  • eth1 (LAN) - 192.168.1.1/24
  • vti0 - 

Azure GW

  • Virtual Gateway - 192.0.2.1
  • Virtual Network - 172.16.0.0/22
  • Default Subnet - 172.16.1.0/24

 


Steps - Route-Based VPN


Back to Top

For the purpose of this article it is assumed that the routing and interface configuration is already in place and that reachability has been tested.

The UDP ports and protocols relevant to IPsec are:

  1. UDP 500 (IKE)
  2. ESP (Protocol 50)
  3. UDP 4500 (NAT-T)

The type of VPN that will be created is called a VTI over IPsec tunnel (IPIP encapsulation). This means that packets will be routed over a VTI interface (vti0) and encrypted using IPsec afterwards. Static routing will be used to facilitate routing between the sites.

The first part of the configuration focuses on the ER, afterwards the gateway will be setup in Azure. The IPsec peer IP address of Azure can be found under (Dashboard > All Resources > Public IP address) after configuring the Azure Gateway in the second step of the article.

www.png  GUI STEPS: Access the router's Web Management Portal (GUI).

1. Define the IPsec peer and Security Associations (SAs) on the ER (replace <secret> with your desired passphrase).

VPN > IPsec Site-to-Site > +Add Peer

  • Show advanced options
  • Automatically open firewall and exclude from NAT
Peer: 192.0.2.1 (needs to be the Azure public IP address, not 0.0.0.0)
Description: IPsecAzure
Local IP: 203.0.113.1 (needs to be the local public IP address, not any)
Encryption: AES-256
Hash: SHA1
DH Group: 2
Pre-shared Secret: <secret>
Local subnet: 192.168.1.0/24 (does not matter because it will be removed later)
Remote subnet: 172.16.0.0/22 (does not matter because it will be removed later)
info_i_25x25.png Note: Currently the Route-Based VTI configuration does NOT support dynamic peer addresses or Fully Qualified Domain Names (FQDN) used by Dynamic DNS (DynDNS). The VTI endpoints need to connect to known IP addresses and do NOT work with local-address any or peer 0.0.0.0.

 

 

CLI_circle.png  CLI STEPS: 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. Display the current IPsec VPN peer configuration (only relevant output is shown).

show vpn
ipsec {
   esp-group FOO0 {
       proposal 1 {
           encryption aes256
           hash sha1
       }
   }
   ike-group FOO0 {
       proposal 1 {
           dh-group 2
           encryption aes256
           hash sha1
       }
   }
   site-to-site {
       peer 192.0.2.1 {
           local-address 203.0.113.1
           tunnel 1 {
               esp-group FOO0
               local {
                   prefix 192.168.1.0/24
               }
               remote {
                   prefix 172.16.1.0/24
               }
           }
...
info_i_25x25.png Note:The Azure VPN Gateway also supports other encryption and hashing methods. In this case the Security Associations (SA) AES256 and SHA1 are chosen. For the full list of supported SAs please see the Microsoft About VPN Devices article.

3. Change the ESP/IKE lifetimes (in seconds).

set vpn ipsec esp-group FOO0 lifetime 27000
set vpn ipsec ike-group FOO0 lifetime 28800 (default)

4. Disable Perfect Forward Secrecy (PFS).

set vpn ipsec esp-group FOO0 pfs disable

5. Change the IKE Key Exchange from version 1 to version 2.

set vpn ipsec ike-group FOO0 key-exchange ikev2

6. Change the IPsec connection type.

set vpn ipsec site-to-site peer 192.0.2.1 connection-type respond
info_i_25x25.png Note: This mainly influences how many times a non-functional connection is renegotiated (keyingtries). With respond this value is set to 1 retry, with initiate the connection is retried indefinitely.

7. Create a VTI to be used by the VPN (this interface does not require a defined IP address).

set interfaces vti vti0

8. Lower the MSS settings on the VTI interface-type.

set firewall options mss-clamp interface-type vti
set firewall options mss-clamp mss 1350
info_i_25x25.png Note: Unlike GRE tunnels, VTI interfaces do not add an additional 24 bytes of overhead. The MTU will be automatically lowered to accommodate the IPsec overhead. The maximum segment size (MSS) must be lowered to 1350 to account for all possible permutations when connected to Azure.

9. Create routing entries for the remote subnets pointing towards the VTI.

set protocols static interface-route 172.16.1.0/24 next-hop-interface vti0

10. Remove the IPsec tunnel(s).

delete vpn ipsec site-to-site peer 192.0.2.1 tunnel 1

11. Link the IPsec peer configuration to the VTI interface created earlier.

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

12. (Optional) Enable the IPsec offloading feature to increase ESP (not IKE) performance.

set system offload ipsec enable (this requires a reboot to become active)

13. Commit the changes.

commit

14. Save the configuration.

save

Steps - Azure Gateway


Back to Top

The Microsoft Azure side of the Site-to-Site VPN connection is based on the Microsoft article which uses the ‘new’ Azure Portal. Link to the article below:

Create a Site-to-Site connection in the Azure portal

info_i_25x25.png Note: It is also possible to configure a VPN gateway using the ‘old’ Classic Portal. In this example we are focusing on the newer method which uses the Resource Manager deployment model.

 

www.png  GUI STEPS: Access the Azure Management Portal (GUI).

1. Create a Virtual Network.

Dashboard > New > Networking > Virtual Network

Name: ServerNetwork
Address Space: 172.16.0.0/22
Subnet name: default
Subnet Address Space: 172.16.1.0/24

Resource Group: ServerNetwork

2. Create a Gateway Subnet.

Dashboard > Virtual Networks > ServerNetwork > Subnets > + Gateway subnet

Name: GatewaySubnet (Required / cannot be changed)
Address Range: 172.16.0.0/24 (Cannot be the same as the default subnet address space)

3. Create a Virtual Network Gateway.

Dashboard > New > Networking > Virtual Network Gateway

Name: VirtualGateway
Gateway Type: VPN
VPN Type: Route-Based
SKU: Basic (depends on usage)
Virtual Network: ServerNetwork
Public IP Address: Create new > VirtualGateway
info_i_25x25.png Note: The provisioning process for a new Virtual Gateway will take time. The Gateway Stock-Keeping Unit (SKU) defines the throughput capabilities of the VPN connection. More info about SKUs can be found in the About VPN Gateway Microsoft article.

4. Create a Local Network Gateway.

Dashboard > New > Networking > Local Network Gateway

Name: LocalGateway
IP Address: 203.0.113.1
Address Space: 192.168.1.0/24
info_i_25x25.png Note: The defined 'address spaces' correspond with the subnets used behind the ER. For every address space / subnet added here a static route will be created in Azure. This is NOT the same as a Policy-Based VPN where remote and local subnets (policy IDs) are defined. In the latter case the IDs need to match exactly, otherwise the VPN will not establish.

 

 

5. Create a VPN Connection and link the LocalGateway to the VirtualGateway.

Daskboard >Virtual Network Gateways > VirtualGateway > Connections > + Add

Name: IPsecER
Connection Type: Site-to-Site (IPsec)
Virtual Network Gateway: VirtualGateway
Local Network Gateway: LocalGateway
Shared Key: <secret>

5. Create a VPN Connection and link the LocalGateway to the VirtualGateway.

 

  

 


Steps - Testing & Verification


Back to Top

1. Verify the IPsec Security Associations (SAs) and status on the ER:

show vpn ipsec sa
peer-192.0.2.1-tunnel-vti: #2, ESTABLISHED, IKEv2, ecdf3193545e701f:ee1b587910cc8b32

 local  '203.0.113.1' @ 203.0.113.1
 remote '192.0.2.1' @ 192.0.2.1
 AES_CBC-256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
 established 787s ago, rekeying in 27228s
 peer-192.0.2.1-tunnel-vti: #1, INSTALLED, TUNNEL, ESP:AES_CBC-256/HMAC_SHA1_96
   installed 787 ago, rekeying in 25448s, expires in 26213s
   in  c92b831a,   4180 bytes,    85 packets,     3s ago
   out 596eba1a,   3366 bytes,    62 packets,     3s ago
   local  0.0.0.0/0
   remote 0.0.0.0/0

sudo ipsec statusall
Status of IKE charon daemon (strongSwan 5.2.2, Linux 3.10.14-UBNT, mips):

 uptime: 26 minutes, since Jul 04 19:48:43 2017
 malloc: sbrk 376832, mmap 0, used 276328, free 100504
 worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 2
 
Listening IP addresses:
 192.168.1.1
 203.0.113.1
Connections:
peer-192.0.2.1-tunnel-vti:  203.0.113.1...192.0.2.1  IKEv2
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
Routed Connections:
peer-192.0.2.1-tunnel-vti{1}:  ROUTED, TUNNEL
peer-192.0.2.1-tunnel-vti{1}:   0.0.0.0/0 === 0.0.0.0/0
Security Associations (1 up, 0 connecting):
peer-192.0.2.1-tunnel-vti[2]: ESTABLISHED 14 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]: IKEv2 SPIs: ecdf3193545e701f_i ee1b587910cc8b32_r*, rekeying in 7 hours
peer-192.0.2.1-tunnel-vti[2]: IKE proposal: AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
peer-192.0.2.1-tunnel-vti{1}:  INSTALLED, TUNNEL, ESP SPIs: c92b831a_i 596eba1a_o
peer-192.0.2.1-tunnel-vti{1}:  AES_CBC_256/HMAC_SHA1_96, 4343 bytes_i (89 pkts, 12s ago), 3497 bytes_o (65 pkts, 12s ago)
peer-192.0.2.1-tunnel-vti{1}:   0.0.0.0/0 === 0.0.0.0/0

2. Verify the ER IPsec strongSwan configuration:

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


config setup

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=aes256-sha1-modp1024!
       keyexchange=ikev2
       reauth=no
       ikelifetime=28800s
       esp=aes256-sha1!
       keylife=27000s
       rekeymargin=540s
       type=tunnel
       compress=no
       authby=secret
       mark=9437186
       auto=route
       keyingtries=1
#conn peer-192.0.2.1-tunnel-vti

3. Capture the arrival of IKE traffic on the ER external 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]   
info_i_25x25.png Note: This is a live capture. If there is no output that means that the traffic is either not being generated on the client, or there is something blocking the traffic upstream.

4. Capture the ER IPsec VPN logs:

sudo swanctl --log
[KNL] creating acquire job for policy 192.168.1.10/32[icmp/8] === 172.16.1.10/32[icmp/8] with reqid {1}

[IKE] initiating Main Mode IKE_SA peer-192.0.2.1-tunnel-1[1] to 192.0.2.1
[ENC] generating ID_PROT request 0 [ SA V V V V ]
[NET] sending packet: from 203.0.113.1[500] to 192.0.2.1[500] (160 bytes)
[NET] received packet: from 192.0.2.1[500] to 203.0.113.1[500] (108 bytes)
[ENC] parsed ID_PROT response 0 [ SA V ]
[IKE] received NAT-T (RFC 3947) vendor ID
[ENC] generating ID_PROT request 0 [ KE No NAT-D NAT-D ]
[ENC] parsed ID_PROT response 0 [ KE No V V V V NAT-D NAT-D ]
[ENC] generating ID_PROT request 0 [ ID HASH N(INITIAL_CONTACT) ]
[ENC] parsed ID_PROT response 0 [ ID HASH ]
[IKE] IKE_SA peer-192.0.2.1-tunnel-1[1] established between 203.0.113.1[203.0.113.1]...192.0.2.1[192.0.2.1]
[ENC] generating QUICK_MODE request 561157166 [ HASH SA No ID ID ]
[ENC] parsed QUICK_MODE response 561157166 [ HASH SA No ID ID N((24576)) ]
[IKE] <peer-192.0.2.1-tunnel-vti|1> CHILD_SA peer-192.0.2.1-tunnel-vti{1} established with SPIs c02f6d74_i dcfd3294_o and TS 0.0.0.0/0 === 0.0.0.0/0                
info_i_25x25.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.

5. Send traffic over the tunnel from Server1 to Host1 and vice versa:

sudo traceroute -n 192.168.1.10
traceroute to 192.168.1.10 (192.168.1.10), 30 hops max, 60 byte packets

1  172.16.0.10 (172.16.0.10)  1.846 ms  1.824 ms  1.812 ms
2  192.168.1.1 (192.168.1.1)  49.158 ms  53.873 ms  55.646 ms

3  192.168.1.10 (192.168.1.10)  57.799 ms *  59.623 ms
info_i_25x25.png Note: The 172.16.0.10 address in the output above is the Azure Gateway subnet defined earlier. From the local network to Azure we can see that the traffic takes another path and is routed through 169.254.0.31.
sudo traceroute -n 172.16.1.10
traceroute to 172.16.1.10 (172.16.1.10), 30 hops max, 60 byte packets

1  192.168.1.1 (192.168.1.1)  1.726 ms  1.734 ms  1.712 ms
2  169.254.0.31 (169.254.0.31)  46.268 ms  48.562 ms  49.542 ms
3  172.16.1.10 (172.16.1.10)  56.236 ms *  55.567 ms

6. Verify the ER state of the tunnel and capture the traffic that is sent over the tunnel:

show interfaces vti vti0
vti0: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1436 qdisc noqueue state UNKNOWN group default

   link/ipip 203.0.113.1 peer 192.0.2.1

   RX:  bytes    packets     errors    dropped    overrun      mcast
        51978        593          0          0          0          0
   TX:  bytes    packets     errors    dropped    carrier collisions
        50543        556          0          0          0          0

show interfaces vti vti0 capture
22:40:10.503017 IP 172.16.1.10 > 192.168.1.10: ICMP echo request, id 12993, seq 18, length 64

22:40:10.504918 IP 192.168.1.10 > 172.16.1.10: ICMP echo reply, id 12993, seq 18, length 64
22:40:11.509699 IP 172.16.1.10 > 192.168.1.10: ICMP echo request, id 12993, seq 19, length 64
22:40:11.512768 IP 192.168.1.10 > 172.16.1.10: ICMP echo reply, id 12993, seq 19, length 64

6. Verify the Azure Virtual Gateway Connection (only relevant output is shown).

Get-AzureRmVirtualNetworkGatewayConnection -Name "IPsecER" -ResourceGroupName "ServerNetwork"

Name                    : IPsecER

ResourceGroupName       : ServerNetwork
Location                : eastus
ProvisioningState       : Succeeded
ConnectionStatus        : Connected
EgressBytesTransferred  : 3854
IngressBytesTransferred : 3104
info_i_25x25.png Note: This verification command requires Azure PowerShell. General info on how to use Windows PowerShell to manage Azure can be found in the Getting started with Azure PowerShell Microsoft article.

 


Related Articles


Back to Top