EdgeRouter - Policy-Based Site-to-Site IPsec VPN to Azure (IKEv1/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 Policy-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

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 Policy-Based over IKEv1/IPsec tunnel.

azure_policy-based_topology_new.png


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

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 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 3600
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 define the local and remote subnets.

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 tunnel 1 esp-group FOO0
set vpn ipsec site-to-site peer 192.0.2.1 tunnel 1 local prefix 192.168.1.0/24
set vpn ipsec site-to-site peer 192.0.2.1 tunnel 1 remote prefix 172.16.0.0/22

7. If you are experiencing MTU issues or TCP sessions not establishing correctly, try setting the TCP Maximum Segment Size (MSS) to 1350.

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

8. 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: Policy-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-1: #1, ESTABLISHED, IKEv1, 88f1089a87512385:ba7111edb4e0680e
 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 674s ago, reauth in 27486s
 peer-192.0.2.1-tunnel-1: #1, INSTALLED, TUNNEL, ESP:AES_CBC-256/HMAC_SHA1_96
   installed 14 ago, rekeying in 2517s, expires in 3586s
   in  cc545afa,   1989 bytes,    11 packets,     6s ago
   out 74d8dfc0,   3042 bytes,    16 packets,     7s ago
   local  192.168.1.0/24
   remote 172.16.0.0/22
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 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-1
       left=203.0.113.1
       right=192.0.2.1
       leftsubnet=192.168.1.0/24
       rightsubnet=172.16.0.0/22
       ike=aes256-sha1-modp1024!
       keyexchange=ikev1
       ikelifetime=28800s
       esp=aes256-sha1!
       keylife=3600s
       rekeymargin=540s
       type=tunnel
       compress=no
       authby=secret
       auto=route
       keyingtries=1
#conn peer-192.0.2.1-tunnel-10

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] CHILD_SA peer-192.0.2.1-tunnel-1{1} established with SPIs cb2_i 51_o and TS 192.168.1.0/24 === 172.16.0.0/22
NOTE: This is a live capture of IPsec traffic.

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