EdgeRouter - IPsec Policy-Based Site-to-Site VPN to Azure (IKEv1/IPsec)

 Overview


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

A Policy-Based VPN is characterized by the definition of local and remote subnets (Proxy IDs) and the usage of IKEv1 when connecting to Azure. This type of VPN differs from a Route-Based VPN which is characterized by the usage of Virtual Tunnel Interfaces (VTIs) and routing entries. Please see the Azure Route-Based (BGP over IKEv2/IPsec) and the Azure Route-Based (VTI 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. 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 - Policy-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

Azure GW

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


Steps - Policy-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 Policy-Based VPN which uses remote and local subnets, otherwise known as proxy IDs. These values need to match exactly between the two peers and need to be mirrored images of each other. Only the prefixes defined in the proxy IDs will be carried over the tunnel. In the example ER has the 192.168.1.0/24 present on the LAN side, whereas the Azure side uses 172.16.0.0/22.

The first part of the configuration focuses on the ER, afterwards the gateway will be set up 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
Description: IPsecAzure
Local IP: 203.0.113.1
Encryption: AES-256
Hash: SHA1
DH Group: 2
Pre-shared Secret: <secret>
Local subnet: 192.168.1.0/24
Remote subnet: 172.16.0.0/22
info_i_25x25.png Note: The remote subnet (proxy ID) corresponds with the ‘address space’ defined on the Virtual Network. This remote subnet includes both the default (172.16.1.0/24) and the gateway subnet (172.16.0.0/24) created in the Azure steps below.

 

 

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 {
       lifetime 3600
       pfs enable
       proposal 1 {
           encryption aes256
           hash sha1
       }
   }
   ike-group FOO0 {
       key-exchange ikev1
       lifetime 28800
       proposal 1 {
           dh-group 2
           encryption aes256
           hash sha1
       }
   }
... 
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. Disable Perfect Forward Secrecy (PFS).

set vpn ipsec esp-group FOO0 pfs disable

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

5. (Optional) Change the local IPsec interface address.

Use the following command to specify the local IP address to be used as the source for IPsec packets destined for the remote peer. The dhcp-interface and local-address statements CANNOT be used simultaneously. Decide on which command is best for your situation using these options:

(A) You are using multiple WAN interfaces and want the VPN to respond on multiple interfaces.

With this statement any IPv4 address present on the system can be used as the source of the VPN. You can also use this command if your WAN interface receives an address through PPPoE.

set vpn ipsec site-to-site peer 192.0.2.1 local-address 0.0.0.0 
info_i_25x25.png Note: We currently recommend using local-address 0.0.0.0 over local-address any

(B) Your WAN interface receives an address through DHCP.

delete vpn ipsec site-to-site peer 192.0.2.1 local-address
set vpn ipsec site-to-site peer 192.0.2.1 dhcp-interface eth0

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

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

7. Commit the changes.

commit

8. 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: Policy-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 ‘address space’ is the defined remote subnet (proxy ID) and corresponds with the subnet used behind the ER. The local subnet is the ‘address space’ used on the Virtual Network, in this case 172.16.0.0/22. These proxy 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

After configuring the IPsec VPN, verify the connection/state using the following commands.

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

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

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

 uptime: 13 minutes, since Jul 14 09:27:42 2017
 malloc: sbrk 376832, mmap 0, used 267656, free 109176
 worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 2
Listening IP addresses:
 192.16.1.1
 203.0.113.1
Connections:
peer-192.0.2.1-tunnel-1:  203.0.113.1...192.0.2.1  IKEv1
peer-192.0.2.1-tunnel-1:   local:  [203.0.113.1] uses pre-shared key authentication
peer-192.0.2.1-tunnel-1:   remote: [192.0.2.1] uses pre-shared key authentication
peer-192.0.2.1-tunnel-1:   child:  192.168.1.0/24 === 172.16.0.0/22 TUNNEL
Routed Connections:
peer-192.0.2.1-tunnel-1{1}:  ROUTED, TUNNEL
peer-192.0.2.1-tunnel-1{1}:   192.168.1.0/24 === 172.16.0.0/22
Security Associations (1 up, 0 connecting):
peer-192.0.2.1-tunnel-1[1]: ESTABLISHED 13 minutes ago, 203.0.113.1[203.0.113.1]...192.0.2.1[192.0.2.1]
peer-192.0.2.1-tunnel-1[1]: IKEv1 SPIs: 88f1089a87512385_i ba7111edb4e0680e_r*, pre-shared key reauthentication in 7 hours
peer-192.0.2.1-tunnel-1[1]: IKE proposal: AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
peer-192.0.2.1-tunnel-1{1}:  INSTALLED, TUNNEL, ESP SPIs: cc545afa_i 74d8dfc0_o
peer-192.0.2.1-tunnel-1{1}:  AES_CBC_256/HMAC_SHA1_96, 2053 bytes_i (13 pkts, 13s ago), 3042 bytes_o (16 pkts, 125s ago)
peer-192.0.2.1-tunnel-1{1}:   192.168.1.0/24 === 172.16.0.0/22

2. Verify the ER IPsec strongSwan configuration:

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


config setup

conn %default
       keyexchange=ikev1

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 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] CHILD_SA peer-192.0.2.1-tunnel-1{1} established with SPIs cb321982_i 5d4174b1_o and TS 192.168.1.0/24 === 172.16.0.0/22       
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:

ping 192.168.1.10
PING 192.168.1.10 (192.168.1.10) 56(84) bytes of data.

64 bytes from 192.168.1.10: icmp_seq=1 ttl=63 time=45.9 ms
64 bytes from 192.168.1.10: icmp_seq=2 ttl=63 time=45.2 ms
64 bytes from 192.168.1.10: icmp_seq=3 ttl=63 time=45.5 ms

ping 172.16.1.10
PING 172.16.1.10 (172.16.1.10) 56(84) bytes of data.

64 bytes from 172.16.1.10: icmp_seq=1 ttl=63 time=45.9 ms
64 bytes from 172.16.1.10: icmp_seq=2 ttl=63 time=45.2 ms
64 bytes from 172.16.1.10: icmp_seq=3 ttl=63 time=45.5 ms

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