Connecting a local FortiGate to an Azure VNet VPN

This recipe provides a sample configuration of a site-to-site VPN connection from a local FortiGate to an Azure VNet VPN via IPsec with static routing.

Instances that you launch into an Azure VNet can communicate with your own remote network via a 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:

• An Azure VNet with some configured subnets, routing tables, security group rules, and so on
• An 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:
3. From the Subscription dropdown list, select the correct subscription.
4. In the Name field, enter a name.
5. From the Region dropdown list, select the VNet gateway region. You should select the same region as the VNet.
6. For Gateway type, select VPN.
7. For VPN type, select Policy-based.
8. For SKU, at the time of this recipe's publication, only Basic can be selected for policy-based VPN.
9. From the Virtual network dropdown list, select the desired VNet to connect to. Azure should automatically detect the gateway subnet created earlier.
10. Under PUBLIC IP ADDRESS, create a new public IP address or select an existing public IP address for the VPN gateway.

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:
3. In the Name field, enter a name.
4. In the IP address field, enter the on-premise FortiGate's external IP address.
5. In the Address space field, enter the CIDR of the network behind the on-premise FortiGate that will access the Azure VNet.
6. From the Subscription dropdown list, select the correct subscription.
7. From the Resource group dropdown list, select the resource group. This example uses the resource group that the other resources belong to.
8. 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:
3. In the Name field, enter a name.
4. From the Connection type dropdown list, select Site-to-site (IPsec).
5. Azure should automatically populate and lock the Virtual network gateway field.
6. For Local network gateway, select the local network gateway created earlier.
7. In the Shared key (PSK) field, enter the key. You must configure this on the on-premise FortiGate as well.
8. 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:
2. Set the interface to the external-facing interface.
3. If your FortiGate is behind NAT, enter the interface's local private IP address for local-gw. Otherwise, this step is unnecessary.
4. For proposal and Diffie-Hellman groups, use the ones that Azure supports as described in IPsec/IKE parameters.
5. For the remote gateway, use the VNet gateway's public IP address.
6. For the PSK secret, use the one configured when creating a connection for the VNet gateway in Azure.
7. If desired, configure dead peer detection. This is not necessary.
8. config vpn ipsec phase1-interface
9. edit "azurephase1"
10. set interface "port1"
11. set local-gw 10.0.0.15
12. set keylife 28800
13. set peertype any
14. set proposal aes256-sha256 3des-sha1 aes128-sha1 aes256-sha1
15. set dhgrp 2
16. set remote-gw 40.112.93.0
17. set psksecret ENC VI0OQ084K91BwEqYp7kzBnMpEfNM1Gg5MnlcTSfxwn4kR5Lsc7QHo0bDAUtqDQMpSrL3bbDBesSxpgezyTrlEbzukP5wZHU66uzrG90RARM+f2yZlkEMljw/X3QWl75SAIA4/eSEib3h6M2PqEYvKZf19O/tiBihS1ilBM81RblYFI2l2tNLoSatODgRGv8nXkvKVA==
18. set dpd-retryinterval 10
19. next
20. end
21. Configure the phase-2 interface as follows:
22. For phase1name, enter the phase-1 interface name as configured in step 1.
23. For proposal, use the ones that Azure supports as described in IPsec/IKE parameters.
24. Disable PFS. Azure does not support it on policy-based mode connections.
25. You can enable auto-negotiation.
26. Set the key life to 3600 seconds.
27. Configure the source subnet to the one behind the on-premise FortiGate.
28. Configure the destination subnet to the Azure VNet's CIDR.
29. config vpn ipsec phase2-interface
30. edit "azurephase2"
31. set phase1name "azurephase1"
32. set proposal aes256-sha1 3des-sha1 aes256-sha256 aes128-sha1
33. set pfs disable
34. set auto-negotiate enable
35. set keylifeseconds 3600
36. set src-subnet 10.0.1.0 255.255.255.0
37. set dst-subnet 172.29.0.0 255.255.0.0
38. next
39. end
40. Configure ingress and egress firewall policy to the VPN interface:
41. config firewall policy
42. edit 1
43. set uuid cd18116c-9215-51e9-8398-3398085fff69
44. set srcintf "azurephase1"
45. set dstintf "port2"
46. set srcaddr "all"
47. set dstaddr "all"
48. set action accept
49. set schedule "always"
50. set service "ALL"
51. next
52. edit 2
53. set uuid dadd6cd4-9215-51e9-288b-73a4336e9600
54. set srcintf "port2"
55. set dstintf "azurephase1"
56. set srcaddr "all"
57. set dstaddr "all"
58. set action accept
59. set schedule "always"
60. set service "ALL"
61. next
62. end
63. Configure a static route for traffic to enter the VPN tunnel:
64. config router static
65. edit 1
66. set dst 172.29.0.0 255.255.0.0
67. set device "azurephase1"
68. next
69. 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.

1. On the Ubuntu client, conduct a ping test to a resource in the Azure VNet:
2. root@ubuntu-internal:~# ping 172.29.0.4
3. PING 172.29.0.4 (172.29.0.4) 56(84) bytes of data.
4. 64 bytes from 172.29.0.4: icmp_seq=1 ttl=253 time=101 ms
5. 64 bytes from 172.29.0.4: icmp_seq=2 ttl=253 time=101 ms
6. 64 bytes from 172.29.0.4: icmp_seq=3 ttl=253 time=101 ms
7. Verify that the on-premise FortiGate forwards ICMP traffic through the Azure VPN tunnel:
8. EXAMPLE-FGT # diagnose sniffer packet any 'icmp' 4
9. interfaces=[any]
10. filters=[icmp]
11. 9.537389 port2 in 10.0.1.2 -> 172.29.0.4: icmp: echo request
12. 9.537453 azurephase1 out 10.0.1.2 -> 172.29.0.4: icmp: echo request
13. 9.638766 azurephase1 in 172.29.0.4 -> 10.0.1.2: icmp: echo reply
14. 9.638800 port2 out 172.29.0.4 -> 10.0.1.2: icmp: echo reply

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.