info_i_25x25.png See important information about Ubiquiti Devices and KRACK Vulnerability in this article. We will update this document as more information becomes available.

EdgeRouter - IPsec Route-Based Site-to-Site VPN to Azure (BGP 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 dynamic routing with BGP (Border Gateway Protocol). Configuring BGP will create a BGP session on top of the IKEv2/IPSec session between the peers (Azure Gateway and on-Premises VPN). The BGP session is established using internal facing (non-exposed) interfaces connected over the IKEv2/IPsec session. Configuring BGP requires additional steps and PowerShell knowledge and is generally not advisable unless your specific scenario requires it. For the most common user scenarios we recommend to configure a Azure Route-Based (VTI over IKEv2/IPsec) Site-to Site VPN. 

 

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). This example focuses on creating dynamic routing entries with BGP, however it is also possible to manually create static routing entries. Please see the Azure Policy-Based (IKEv1/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, 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 - 
  • BGP AS - 65510
  • BGP Update Source - 192.168.1.1

Azure GW

  • Virtual Gateway - 192.0.2.1
  • Virtual Network - 172.16.0.0/22
  • Default Subnet - 172.16.1.0/24
  • BGP AS - 65515
  • BGP Update Source 172.16.0.254

 


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. The Border Gateway Protocol (BGP) 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 BGP peering address pointing towards the VTI.

set protocols static interface-route 172.16.0.254/32 next-hop-interface vti0
info_i_25x25.png Note: This step is necessary because Azure uses an address on the ‘gateway subnet’ as the source of the BGP session (BGP peering address). If you do not add this static route, the ER will not know how to reach the address of the defined BGP neighbor (172.16.0.254 in this example). You will find the peering address that Azure uses for BGP by running the PowerShell commands in the Azure Gateway configuration below.

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. Create a prefix-list for BGP that will be used to filter advertised and received prefixes.

set policy prefix-list BGP rule 10 action deny
set policy prefix-list BGP rule 10 description 'Deny Local Gateway Address'
set policy prefix-list BGP rule 10 prefix 203.0.113.1/32

set policy prefix-list BGP rule 20 action deny
set policy prefix-list BGP rule 20 description 'Deny Azure Gateway Address'
set policy prefix-list BGP rule 20 prefix 192.0.2.1/32

set policy prefix-list BGP rule 30 action deny
set policy prefix-list BGP rule 30 description 'Deny Local Peering Address'
set policy prefix-list BGP rule 30 prefix 192.168.1.1/32

set policy prefix-list BGP rule 40 action deny
set policy prefix-list BGP rule 40 description 'Deny Azure Peering Address'
set policy prefix-list BGP rule 40 prefix 172.16.0.254/32

set policy prefix-list BGP rule 100 action permit
set policy prefix-list BGP rule 100 description 'Local Subnets'
set policy prefix-list BGP rule 100 prefix 192.168.1.0/24

set policy prefix-list BGP rule 110 action permit
set policy prefix-list BGP rule 110 description 'Azure Subnets'
set policy prefix-list BGP rule 110 prefix 172.16.0.0/22
info_i_25x25.png Note: In this example the same prefix-list is used for filtering the advertised and received prefixes. You may choose to split this up into a BGPout and BGPin prefix-list for example. The entry that matches the ‘Azure Subnets’ needs to match the subnet in the Azure Virtual Network configuration below. Note that this subnet matches on a /22, and not only the 172.16.1.0/24 range. This is because Azure advertises the entire address-space defined in the Virtual Network.

14. Define the BGP neighbor and peering options.

set protocols bgp 65510 timers holdtime 180
set protocols bgp 65510 timers keepalive 60
set protocols bgp 65510 neighbor 172.16.0.254 ebgp-multihop 2
set protocols bgp 65510 neighbor 172.16.0.254 prefix-list export BGP

set protocols bgp 65510 neighbor 172.16.0.254 prefix-list import BGP
set protocols bgp 65510 neighbor 172.16.0.254 remote-as 65515
set protocols bgp 65510 neighbor 172.16.0.254 soft-reconfiguration inbound
set protocols bgp 65510 neighbor 172.16.0.254 update-source 192.168.1.1
info_i_25x25.png Note: The BGP neighbor is the internal IP address in the Azure Gateway Subnet range, NOT the Public IP address of the Azure Gateway. The ebgp-multihop command is required, as the peers are not directly connected (the source of the BGP session on the ER side is 192.168.1.1). You may choose to increase the maximum amount of hops that the BGP neighborship is allowed to connect over.

15. Advertise the local subnets into BGP.

set protocols bgp 65510 network 192.168.1.0/24
info_i_25x25.png Note: You may also choose to redistribute connected routes or prefixes learned from another routing protocol (set protocols bgp 65510 redistribute connected).

16. Commit the changes.

commit

17. 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 in addition to Windows PowerShell (PS). Links to the articles below:

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)
info_i_25x25.png Note: In this example the Virtual Network and Gateway Subnet are created via the Azure Portal. It is also possible to do this via PowerShell. The steps to create Virtual Networks via PowerShell can be found in the articles linked above.

 

 

image4.png PS STEPS: Run Windows PowerShell on a local computer as Administrator. General info on how to use Windows PowerShell to manage Azure can be found in the Getting started with Azure PowerShell Microsoft article.

1. Install PowerShellGet.

$psversiontable
Name                           Value

----                           -----
PSVersion                      5.1.14393.1358

Get-Module PowerShellGet -list | Select-Object Name,Version,Path
Name          Version Path

----          ------- ----
PowerShellGet 1.0.0.1 C:\Program Files\WindowsPowerShell\Modules\PowerShellGet\1.0.0.1\PowerShellGet.psd1

If the output above is blank or shows an error message, verify that you are running the most up to date version of PowerShell (5.0) or download and install the additional modules here.

info_i_25x25.png Note: If you are running Windows 10, the build-in version of PowerShell is 5.0. This version includes PowerShellGet by default.

2. Define the the PowerShell Execution Policy.

Get-ExecutionPolicy
Restricted


Set-ExecutionPolicy -ExecutionPolicy Unrestricted

Using PowerShellGet requires an Execution Policy that allows you to run scripts. In this example the policy is set to unrestricted. More information can be found in the About Execution Policies Microsoft article.

3. Install the AzureRM (Resource Manager) PowerShell module.

Install-Module AzureRM

4. Connect to your Azure Resource Manager Account and select your subscription.

Login-AzureRmAccount
Select-AzureRmSubscription -SubscriptionName "<subscription name>"

5. Verify the Virtual Network created in the Azure Portal above (only relevant output is shown).

Get-AzureRmVirtualNetwork -ResourceGroupName "ServerNetwork"
Name                   : ServerNetwork

ResourceGroupName      : ServerNetwork
Location               : eastus
ProvisioningState      : Succeeded
AddressSpace           : {
                          "AddressPrefixes": [
                            "172.16.0.0/22"
                          ]
                        }
Subnets                : [
                          {
                            "Name": "default",
                            "AddressPrefix": "172.16.1.0/24",
                            "ProvisioningState": "Succeeded"
                          },
                          {
                            "Name": "GatewaySubnet",
                            "AddressPrefix": "172.16.0.0/24",
                            "ProvisioningState": "Succeeded"
                          }
                        ]

6. Define aliases (variables) that will be used in the Virtual Network Gateway configuration.

$Resource = "ServerNetwork"

$Location = "East US"

$vNet = Get-AzureRmVirtualNetwork -Name "ServerNetwork" -ResourceGroupName $Resource

$PublicIP = New-AzureRmPublicIpAddress -Name VirtualGateway -ResourceGroupName $Resource -Location $Location -AllocationMethod Dynamic

$GateWaySubnet = Get-AzureRmVirtualNetworkSubnetConfig -Name "GatewaySubnet" -VirtualNetwork $vNet

$GatewayIP = New-AzureRmVirtualNetworkGatewayIpConfig -Name "VirtualGateway" -Subnet $GatewaySubnet -PublicIpAddress $PublicIP
  • $Resource - This is the name of the Resource Group (ServerNetwork)
  • $Location - This is the Azure location  (East US)
  • $vNet - This is the Virtual Network created earlier (ServerNetwork / 172.16.0.0/22)
  • $PublicIP - This is the public IP for the Virtual Gateway generated by Azure (VirtualGateway)
  • $GatewaySubnet - This is the Gateway Subnet created earlier (GatewaySubnet / 172.16.0.0/24)
  • $GatewayIP - This is the public IP that will be used by the Virtual Gateway (VirtualGateway)

7. Create the Virtual Network Gateway (Optionally change the AS number).

New-AzureRmVirtualNetworkGateway -Name "VirtualGateway" -ResourceGroupName $Resource -Location $Location -IpConfigurations $GatewayIP -GatewayType Vpn -VpnType RouteBased -GatewaySku VpnGw1 -Asn 65515
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. A SKU of ‘VpnGw1’ or higher is required for BGP support on the Virtual Network Gateway.

8. Verify the Virtual Gateway settings (only relevant output is shown).

Get-AzureRmVirtualNetworkGateway -Name "VirtualGateway" -ResourceGroupName "ServerNetwork"
Name                   : VirtualGateway

ResourceGroupName      : ServerNetwork
Location               : eastus
ProvisioningState      : Succeeded
GatewayType            : Vpn
VpnType                : RouteBased
Sku                    : {
                          "Capacity": 10,
                          "Name": "VpnGw1",
                          "Tier": "VpnGw1"
                        }
BgpSettings            : {
                          "Asn": 65515,
                          "BgpPeeringAddress": "172.16.0.254",
                          "PeerWeight": 0

                        }

Take note of the BgpPeeringAddress in the output above. This is the neighbor address of the BGP peer which needs to be configured on the EdgeRouter (172.16.0.254). You need to define this neighbor address when using the set protocols bgp 65510 neighbor command in the ER configuration above.

9. Create the Local Network Gateway (Optionally change the AS)

New-AzureRmLocalNetworkGateway -Name "LocalGateway" -ResourceGroupName $Resource -Location $Location -GatewayIpAddress "203.0.113.1" -AddressPrefix "192.168.1.0/24" -Asn 65510 -BgpPeeringAddress "192.168.1.1"
  • GatewayIpAddress - Public IP of the EdgeRouter (ER)
  • AddressPrefix - Local subnet behind the ER
  • BgpPeeringAddress - Neighbor IP address of the ER (Update Source)
  • Asn - Autonomous System Number (65510)

10. Verify the Local Gateway settings (only relevant output is shown).

Get-AzureRmLocalNetworkGateway -Name "LocalGateway" -ResourceGroupName "ServerNetwork"
Name                     : LocalGateway

ResourceGroupName        : ServerNetwork
Location                 : eastus
ProvisioningState        : Succeeded
GatewayIpAddress         : 76.237.8.193
LocalNetworkAddressSpace : {
                            "AddressPrefixes": [
                              "192.168.1.0/24"
                            ]
                          }
BgpSettings              : {
                            "Asn": 65510,
                            "BgpPeeringAddress": "192.168.1.1",
                            "PeerWeight": 0

                          }

11. Define aliases (variables) for both the VirtualGateway and the LocalGateway.

$VirtualConnection = Get-AzureRmVirtualNetworkGateway -Name "VirtualGateway"  -ResourceGroupName $Resource
$LocalConnection  = Get-AzureRmLocalNetworkGateway -Name "LocalGateway" -ResourceGroupName $Resource

12. Create and initiate the Virtual Gateway Connection.

New-AzureRmVirtualNetworkGatewayConnection -Name "IPsecER" -ResourceGroupName $Resource -VirtualNetworkGateway1 $VirtualConnection -LocalNetworkGateway2 $LocalConnection -Location $Location -ConnectionType IPsec -SharedKey '<secret>' -EnableBGP $True
  • Name - Name of the VPN connection (locally significant)
  • VirtualNetworkGateway1 - The Virtual Gateway created earlier (VirtualGateway)
  • LocalNetworkGateway2 - The Local Gateway created earlier (LocalGateway)
  • SharedKey - The pre-shared-secret between the sites (replace <secret> with your desired passphrase)
  • EnableBGP - Needs to be specifically enabled, otherwise BGP is not operational ($True)

13. Verify the 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

 

 

 

 


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

7. Verify the BGP connection and prefix advertisement / reception on the ER:

show ip route bgp
IP Route Table for VRF "default"

B    *> 172.16.0.0/22 [20/0] via 172.16.0.254 (recursive is directly connected, vti0) ), 00:22:56

show ip bgp summary
BGP router identifier 203.0.113.1, local AS number 65510

BGP table version is 9
2 BGP AS-PATH entries
0 BGP community entries
Neighbor                 V   AS   MsgRcv    MsgSen TblVer   InQ   OutQ    Up/Down   State/PfxRcd
172.16.0.254             4 65515   46         41       9      0      0  00:38:32               2
info_i_25x25.png Note: You should see a number (amount of prefixes) for the State/PfxRcd state. Any other state, such as ‘CONNECT’ means that the BGP session is NOT active.
show ip bgp
BGP table version is 9, local router ID is 203.0.113.1

Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, l - labeled
             S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
   Network          Next Hop            Metric    LocPrf       Weight Path
*>  192.168.1.0/24   0.0.0.0                       100          32768    i
*                    172.16.0.254         0                     0       65515 i
*>  172.16.0.0/22    172.16.0.254         0                     0       65515 i

Total number of prefixes 2

show ip bgp neighbors 172.16.0.254
BGP neighbor is 172.16.0.254, remote AS 65515, local AS 65510, external link

 BGP version 4, remote router ID 172.16.0.254
 BGP state = Established, up for 00:39:26
 Last read 00:39:26, hold time is 180, keepalive interval is 60 seconds
 Configured hold time is 180, keepalive interval is 60 seconds
 Neighbor capabilities:
   Route refresh: advertised and received (new)
   4-Octet ASN Capability: advertised and received
   Address family IPv4 Unicast: advertised and received
   Address family IPv6 Unicast: received
 Received 47 messages, 0 notifications, 0 in queue
 Sent 43 messages, 0 notifications, 0 in queue
 Route refresh request: received 0, sent 0
 Minimum time between advertisement runs is 30 seconds
 Update source is 192.168.1.1
For address family: IPv4 Unicast
 BGP table version 10, neighbor version 9
 Index 1, Offset 0, Mask 0x2
   Graceful restart: received
 Inbound soft reconfiguration allowed
 Community attribute sent to this neighbor (both)
 Inbound path policy configured
 Outbound path policy configured
 Incoming update prefix filter list is *BGP
 Outgoing update prefix filter list is *BGP
 2 accepted prefixes
 1 announced prefixes
Connections established 1; dropped 0
 External BGP neighbor may be up to 2 hops away.
Local host: 192.168.1.1, Local port: 179
Foreign host: 172.16.0.254, Foreign port: 49328
Nexthop: 192.168.1.1
Nexthop global: fe80::46d9:e7ff:fe50:8bbf
Nexthop local: ::
BGP connection: non shared network

show ip bgp neighbors 172.16.0.254 received-routes
BGP table version is 10, local router ID is 203.0.113.1

Status codes: s suppressed, d damped, h history, * valid, > best, i - internal
Origin codes: i - IGP, e - EGP, ? - incomplete
   Network          Next Hop            Metric    LocPrf       Weight Path
*>  192.168.1.0/24     172.16.0.254                               0       65515 i
*>  192.168.1.1/32     172.16.0.254                               0       65515 i
*>  172.16.0.0/22    172.16.0.254                               0       65515 i
info_i_25x25.png Note: The 192.168.1.0/24 and 192.168.1.1/32 prefixes are advertised back to us from the Azure BGP peer. The filtering prefix-list defined earlier (as well as our own connected route Administrative Distance) prevent the routes from being installed in the routing table.
show ip bgp neighbors 172.16.0.254 advertised-routes
BGP table version is 10, local router ID is 203.0.113.1

Status codes: s suppressed, d damped, h history, * valid, > best, i - internal
Origin codes: i - IGP, e - EGP, ? - incomplete
   Network          Next Hop            Metric    LocPrf       Weight Path
*>  192.168.1.0/24     192.168.1.1                     100          32768    i

show ip bgp 192.168.1.0/24
BGP routing table entry for 192.168.1.0/24

Paths: (2 available, best #1, table Default-IP-Routing-Table)
 Advertised to non peer-group peers:
 172.16.0.254
 Local
   0.0.0.0 from 0.0.0.0 (203.0.113.1)
     Origin IGP, localpref 100, weight 32768, valid, sourced, local, best
     Last update: Tue Jul  4 20:35:08 2017
 65515
   172.16.0.254 from 172.16.0.254 (172.16.0.254)
     Origin IGP, metric 0, localpref 100, valid, external
     Last update: Tue Jul  4 20:39:21 2017

show ip bgp 172.16.0.0/22
BGP routing table entry for 172.16.0.0/22

Paths: (1 available, best #1, table Default-IP-Routing-Table)
 Not advertised to any peer
 65515
   172.16.0.254 from 172.16.0.254 (172.16.0.254)
     Origin IGP, metric 0, localpref 100, valid, external, best
     Last update: Tue Jul  4 20:39:21 2017

Related Articles


Back to Top