Connecting a local FortiGate to an Azure VNet VPN

This example provides sample configuration of a site-to-site VPN connection from a local FortiGate to an Azure VNet VPN via IPsec VPN with static or border gateway protocol (BGP) routing.

Instances that you launch into an Azure VNet can communicate with your own remote network via site-to-site VPN between your on-premise FortiGate and Azure VNet VPN. You can enable access to your remote network from your VNet by configuring a virtual private gateway (VPG) and customer gateway to the VNet, then configuring the site-to-site VPC VPN.

The following prerequisites must be met for this configuration:

• Azure VNet with some configured subnets, routing tables, security group rules, and so on
• On-premise FortiGate with an external IP address

The following demonstrates the topology for this recipe:

This recipe consists of the following steps:

1. Create a gateway subnet.
2. Create a VPN gateway.
3. Create a local network gateway.
4. Create a connection for the VNet gateway.
5. Configure the on-premise FortiGate.
6. Verify the connection.
7. Troubleshoot the connection.

To create a gateway subnet:

A gateway subnet is a subnet in your VNet that contains the IP addresses for the Azure VNet gateway resources and services. Azure requires a gateway subnet for VNet gateways to function.

1. In the Azure management console, go to your VNet, then Subnets > + Gateway subnet. You do not need to configure any fields on the Add subnet screen. You cannot change the name, as it must be GatewaySubnet for the VNet gateway to function. Azure should automatically populate the Address range (CIDR block) field with a subnet within your VNet. In this example, the VNet is 172.29.0.0/16, while the subnet is 172.29.2.0/24. You do not need to configure a route table or security group unless your environment needs special handling.

   

To create a VPN gateway:

You must create a VPN gateway to configure the Azure side of the VPN connection.

1. Go to Create a resource. Search for Virtual network gateway. Click Create.
2. On the Create virtual network gateway screen, configure the following:
   1. From the Subscription dropdown list, select the correct subscription.
   2. In the Name field, enter a name.
   3. From the Region dropdown list, select the VNet gateway region. You should select the same region as the VNet.
   4. For Gateway type, select VPN.
   5. For VPN type, select Policy-based.
   6. For SKU, at the time of publishing this guide, you can only select Basic for policy-based VPN.
   7. From the Virtual network dropdown list, select the desired VNet to connect to. Azure should automatically detect the gateway subnet created earlier.
   8. Under PUBLIC IP ADDRESS, create a new public IP address or select an existing public IP address for the VPN gateway.
   9. If desired, configure BGP. The BGP peer IP address is based on the VNet gateway's gateway subnet.

      

Azure may take up to 45 minutes to create the VPN gateway.

To create a local network gateway:

The local gateway refers to your local side of the VPN settings. You can configure a local network gateway to let Azure know your on-premise-side settings.

1. Go to Create a resource. Search for Local network gateway. Click Create.
2. On the Create local network gateway screen, configure the following:
   1. In the Name field, enter a name.
   2. In the IP address field, enter the on-premise FortiGate's external IP address.
   3. In the Address space field, enter the CIDR of the network behind the on-premise FortiGate that will access the Azure VNet.
   4. If desired, enable Configure BGP settings. You define the BGP peer IP address for the local network gateway, but there are restrictions. See About BGP with Azure VPN Gateway.
   5. From the Subscription dropdown list, select the correct subscription.
   6. From the Resource group dropdown list, select the resource group. This example uses the resource group that the other resources belong to.
   7. From the Location dropdown list, select the location. This example uses the location that the VNet resides in, but this is not a requirement.

   

To create a connection for the VNet gateway:

A VNet gateway can have multiple connections to multiple VPN endpoints. These connections share the resource of the VNet gateway. To connect to an on-premise FortiGate, you must configure a connection.

1. Go to the VNet gateway page > Connections > Add.
2. On the Add connection screen, configure the following:
   1. In the Name field, enter a name.
   2. From the Connection type dropdown list, select Site-to-site (IPsec).
   3. Azure should automatically populate and lock the Virtual network gateway field.
   4. For Local network gateway, select the local network gateway created earlier.
   5. In the Shared key (PSK) field, enter the key. You must configure this on the on-premise FortiGate as well.
   6. Azure should automatically populate and lock the Resource group field.

To configure the on-premise FortiGate:

On the on-premise FortiGate, you must configure the phase-1 and phase-2 interfaces, firewall policy, and routing to complete the VPN connection. For Azure requirements for various VPN parameters, see Configure your VPN device.

1. Configure the phase-1 interface as follows in the FortiOS CLI:
   1. Set the interface to the external-facing interface.
   2. If your FortiGate is behind NAT, enter the interface's local private IP address for local-gw. Otherwise, this step is unnecessary.
   3. For proposal and Diffie-Hellman groups, use the ones that Azure supports as Default IPsec/IKE parameters describes.
   4. For the remote gateway, use the VNet gateway's public IP address.
   5. For the PSK secret, use the one configured when creating a connection for the VNet gateway in Azure.
   6. If desired, configure dead peer detection. This is not necessary.

   config vpn ipsec phase1-interface

   edit "azurephase1"

   set interface "port1"

   set local-gw 10.0.0.15

   set keylife 28800

   set peertype any

   set proposal aes256-sha256 3des-sha1 aes128-sha1 aes256-sha1

   set dhgrp 2

   set remote-gw 40.112.93.0

   set psksecret ENC VI0OQ084K91BwEqYp7kzBnMpEfNM1Gg5MnlcTSfxwn4kR5Lsc7QHo0bDAUtqDQMpSrL3bbDBesSxpgezyTrlEbzukP5wZHU66uzrG90RARM+f2yZlkEMljw/X3QWl75SAIA4/eSEib3h6M2PqEYvKZf19O/tiBihS1ilBM81RblYFI2l2tNLoSatODgRGv8nXkvKVA==

   set dpd-retryinterval 10

   next

   end

   If configuring BGP routing, also run the following commands. Here, 10.1.254.1 255.255.255.255 is the local network gateway BGP peer IP address. 172.0.0.254 255.255.255.255 is the VNet gateway BGP peer IP address:

   config system interface

   edit "azurephase1"

   set vdom "root"

   set ip 10.1.254.1 255.255.255.255

   set tcp-mss 1350

   set remote-ip 172.0.0.254 255.255.255.255

   next

   end

2. Configure the phase-2 interface as follows:
   1. For phase1name, enter the phase-1 interface name as you configured in step 1.
   2. For proposal, use the ones that Azure supports as Default IPsec/IKE parameters describes.
   3. Disable PFS. Azure does not support it on policy-based mode connections.
   4. You can enable auto-negotiation.
   5. Set the key life to 3600 seconds.
   6. Configure the source subnet to the one behind the on-premise FortiGate.
   7. Configure the destination subnet to the Azure VNet's CIDR.

   config vpn ipsec phase2-interface

   edit "azurephase2"

   set phase1name "azurephase1"

   set proposal aes256-sha1 3des-sha1 aes256-sha256 aes128-sha1

   set pfs disable

   set auto-negotiate enable

   set keylifeseconds 3600

   set src-subnet 10.0.1.0 255.255.255.0

   set dst-subnet 172.29.0.0 255.255.0.0

   next

   end

3. Configure ingress and egress firewall policy to the VPN interface:

   config firewall policy

   edit 1

   set uuid cd18116c-9215-51e9-8398-3398085fff69

   set srcintf "azurephase1"

   set dstintf "port2"

   set srcaddr "all"

   set dstaddr "all"

   set action accept

   set schedule "always"

   set service "ALL"

   next

   edit 2

   set uuid dadd6cd4-9215-51e9-288b-73a4336e9600

   set srcintf "port2"

   set dstintf "azurephase1"

   set srcaddr "all"

   set dstaddr "all"

   set action accept

   set schedule "always"

   set service "ALL"

   next

   end

4. Configure the route for traffic to enter the VPN tunnel:
   1. Configure a static route for traffic to enter the VPN tunnel:

      config router static

      edit 1

      set dst 172.29.0.0 255.255.0.0

      set device "azurephase1"

      next

      end

   2. Configure BGP. The example uses the following values:

      Value	Description
      64521	Local network gateway BGP ASN
      172.0.0.254	VNet gateway BGP peer IP address
      64520	VNet gateway BGP ASN

      config router bgp

      set as 64521

      config neighbor

      edit "172.0.0.254"

      set soft-reconfiguration enable

      set remote-as 64520

      set update-source "azurephase1"

      next

      end

      end

To verify the connection:

1. In FortiOS, go to Monitor > IPsec Monitor to see if the tunnel is up. If it is not up, manually bring up the tunnel.

   

2. On the Ubuntu client, conduct a ping test to a resource in the Azure VNet:

   root@ubuntu-internal:~# ping 172.29.0.4

   PING 172.29.0.4 (172.29.0.4) 56(84) bytes of data.

   64 bytes from 172.29.0.4: icmp_seq=1 ttl=253 time=101 ms

   64 bytes from 172.29.0.4: icmp_seq=2 ttl=253 time=101 ms

   64 bytes from 172.29.0.4: icmp_seq=3 ttl=253 time=101 ms

3. Verify that the on-premise FortiGate forwards ICMP traffic through the Azure VPN tunnel:

   EXAMPLE-FGT # diagnose sniffer packet any 'icmp' 4

   interfaces=[any]

   filters=[icmp]

   9.537389 port2 in 10.0.1.2 -> 172.29.0.4: icmp: echo request

   9.537453 azurephase1 out 10.0.1.2 -> 172.29.0.4: icmp: echo request

   9.638766 azurephase1 in 172.29.0.4 -> 10.0.1.2: icmp: echo reply

   9.638800 port2 out 172.29.0.4 -> 10.0.1.2: icmp: echo reply

4. If you configured BGP routing, verify the BGP connection between the peers:

   diagnose sniffer packet azurephase1
   interfaces=[azurephase1]
   filters=[none]
   2.608265 10.1.254.1.3965 -> 172.0.0.254.179: syn 3528484722
   2.610865 172.0.0.254.179 -> 10.1.254.1.3965: syn 330055282 ack 3528484723
   2.610889 10.1.254.1.3965 -> 172.0.0.254.179: ack 330055283
   2.610910 10.1.254.1.3965 -> 172.0.0.254.179: psh 3528484723 ack 330055283
   2.616039 172.0.0.254.179 -> 10.1.254.1.3965: psh 330055283 ack 3528484784
   2.616051 10.1.254.1.3965 -> 172.0.0.254.179: ack 330055346
   2.616061 172.0.0.254.179 -> 10.1.254.1.3965: psh 330055346 ack 3528484784
   2.616064 10.1.254.1.3965 -> 172.0.0.254.179: ack 330055365
   get router  info bgp summary
   BGP router identifier 10.1.1.37, local AS number 64521
   BGP table version is 2
   2 BGP AS-PATH entries
   0 BGP community entries
   Neighbor        V         AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
   172.0.0.254     4      64520    1586    1596        1    0    0 00:01:08        1
   Total number of neighbors 1
   get router info routing-table  bgp
   Routing table for VRF=0
   B       172.0.0.0/16 [20/0] via 172.0.0.254, azurephase1, 00:01:38

To troubleshoot the connection:

If any aspects of the VPN are incorrectly configured, you must troubleshoot the Azure and on-premise FortiGate sides.

For Azure-side help, see the Azure documentation.

For the on-premise FortiGate, use debugging to see possible problems:

EXAMPLE-FGT # diagnose debug enable

EXAMPLE-FGT # diagnose debug application ike -1

Debug messages will be on for 30 minutes.

EXAMPLE-FGT # ike 0: cache rebuild start

ike 0:azurephase1: cached as static-ddns

ike 0: cache rebuild done

ike shrank heap by 106496 bytes

ike 0:azurephase1: NAT keep-alive 3 10.0.0.15->94.245.93.197:4500.

ike 0:azurephase1:125: out FF

ike 0:azurephase1:125: sent IKE msg (keepalive): 10.0.0.15:4500->94.245.93.197:4500, len=1, id=ff00000000000000/0000000000000000

ike 0:azurephase1:azurephase2: IPsec SA connect 3 10.0.0.15->94.245.93.197:4500

ike 0:azurephase1:azurephase2: using existing connection

ike 0:azurephase1:azurephase2: config found

ike 0:azurephase1:azurephase2: IPsec SA connect 3 10.0.0.15->94.245.93.197:4500 negotiating

Common issues include misconfiguring the local gateway parameter, mismatching security proposals and protocols, and mismatching phase-2 source and destination subnets.