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. The following VPN options are available when connecting to Azure:

Microsoft recommends to use Route-Based IKEv2 VPNs over Policy-Based IKEv1 VPNs as it offers additional rich connectivity features. These features include Point-to-Site VPNs, Active Routing Support (BGP), Support for multiple tunnels as well as ECMP with metric routing, Active-Active Azure Gateway configurations for redundancy, Transit Routing with Point-to-Site, DPD detection and Virtual Network Peering.

NOTES & REQUIREMENTS:
Applicable to EdgeOS firmware v1.10.0 and up 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.
 
More info about Azure VPNs and their requirements can be found here.
 
Devices used in this article:

Table of Contents


  1. Network Diagram
  2. Configuring a Route-Based VPN
  3. Setting up the Azure Gateway
  4. Testing and Verification
  5. Related Articles

Network Diagram


Back to Top

The network topology is shown below and the following interfaces are in use on the EdgeRouter and Azure:

ER-X

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

Azure VGW

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

The type of VPN that will be created is a VTI over IKEv2/IPsec tunnel. Static routing will be used to facilitate routing between the sites.


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

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 set the key-exchange to IKEv2.

set vpn ipsec ike-group FOO0 key-exchange ikev2
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 aes256
set vpn ipsec ike-group FOO0 proposal 1 hash sha1

4. Create the ESP / Phase 2 (P2) SAs and disable Perfect Forward Secrecy (PFS).

set vpn ipsec esp-group FOO0 lifetime 27000
set vpn ipsec esp-group FOO0 pfs disable
set vpn ipsec esp-group FOO0 proposal 1 encryption aes256
set vpn ipsec esp-group FOO0 proposal 1 hash sha1
NOTE: Azure also supports other encryption and hashing methods. For the full list of supported SAs please see the Microsoft article here.

5. Define the Azure VPN Gateway peering address and set the connection-type to respond.

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 respond
set vpn ipsec site-to-site peer 192.0.2.1 description ipsec
set vpn ipsec site-to-site peer 192.0.2.1 local-address 203.0.113.1
ATTENTION: It is of vital importance that the connection-type is set to respond.

6. Link the SAs created above to the Azure 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. Configure the virtual tunnel interface (vti0) without an IP address assigned to it.

set interfaces vti vti0

8. Lower the TCP Maximum Segment Size (MSS) on the vti interfaces to 1350.

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

9. Create a static route for the remote subnet.

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

10. Commit the changes and save the configuration.

commit ; save

Setting up the Azure Gateway


Back to Top

The Microsoft Azure side of the Site-to-Site VPN connection is based on this Microsoft article.

GUI: Access the Azure Management Portal.

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)

create_virtual_network___add_subnet.png

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

create_virtual___local_gateway.png

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>

servernetwork___virtualgateway.png

local_gateway___connection.png


Testing and Verification


Back to Top

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

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

2. Verify the IPsec strongSwan configuration file.

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 IPsec 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]
NOTE: This is a live capture of IPsec traffic.

4. Capture and analyze the IPsec VPN log messages.

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 and TS 0.0.0.0/0               
NOTE: This is a live capture of IPsec traffic.

5. Verify the routing table.

show ip route
S    *> 172.16.0.0/22 [1/0] is directly connected, vti0

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
NOTE: More info on how to use Windows PowerShell to manage Azure can be found in the this Microsoft article.

Related Articles


Back to Top