IPsec VPN to Microsoft Azure


The following recipe demonstrates how to configure a site-to-site IPsec VPN tunnel to Microsoft Azure™.

Using FortiOS 5.6, the example describes how to configure the tunnel between each site, avoiding overlapping subnets, so that a secure tunnel can be established.​​

PREP 10 mins      COOK 25 mins      TOTAL 35 mins


  • One (1) FortiGate with an Internet-facing IP address.
  • One (1) valid Microsoft Azure account.

Find this recipe for other FortiOS versions
5.4 | 5.6


1. Configuring the Microsoft Azure virtual network

Log into Microsoft Azure and click New. In the Search the Marketplace field, type “Virtual Network”.

Locate Virtual Network from the returned list and click to open the Virtual Network blade.

Near the bottom of the Virtual Network blade, from the Select a deployment model list, select Resource Manager, and then click Create.

On the Create virtual network blade, fill in the values for your Virtual Network settings and click Create.

2. Specifying the Microsoft Azure DNS server

Open the virtual network you just created, navigate to DNS Servers, and click to open the DNS servers blade.

Enter the IP address of the DNS server and click Save at the top of the blade.

3. Creating the Microsoft Azure virtual network gateway

In the portal dashboard, go to New.

Search for “Virtual Network Gateway” and select it to open the Create virtual network gateway blade.

In the Create virtual network gateway blade, fill in the values for your virtual network gateway.


Create a Public IP address if necessary and click Create at the bottom.

Provisioning the virtual network gateway may take some time.

You will receive a notification about the deployment.

4. Creating the Microsoft Azure local network gateway

From the dashboard, select All resources.

Click +Add and then choose to See all.


In the Everything blade search box, type Local network gateway, and select Create local network gateway.

Set IP address to the local network gateway address (the FortiGate’s external IP address). 

Fill in the remaining values for your local network gateway and click Create.

5. Configuring the FortiGate tunnel

Go to VPN > IPsec Wizard.

Enter a Name for the tunnel, select Custom, and click Next.

Set the Remote Gateway to Static IP Address, and include the gateway IP Address provided by Microsoft Azure.

Set the Local Interface to wan1.

Disable NAT Traversal and set Dead Peer Detection to On Idle.

Under Authentication, enter a Pre-shared Key and ensure that you enable IKEv2.


Under Phase 1 Proposal set the Encryption algorithm combinations to the following: AES 256 – SHA1, 3DES – SHA1, and AES256 – SHA256.

Note that these are just three supported encryption-algorithm combinations that are accepted by Azure.

Select 2 for Diffie-Hellman Group.

Set Key Lifetime (seconds) to 28800.

Scroll down to Phase 2 Selectors and expand the Advanced section.

Set the Encryption combinations.

Disable Perfect Forward Secrecy.

Set Key Lifetime Seconds to 27000.

6. Creating the Azure firewall object

Go to Policy & Objects > Addresses and create a firewall object for the Azure VPN tunnel subnet.

7. Creating the FortiGate firewall policies

Go to Policy & Objects > IPv4 Policy and create a new policy for the site-to-site connection that allows outgoing traffic.

Set the Source Address and Destination Address using the firewall objects you just created.

Ensure that NAT is disabled.

Create a second policy for the same connection to allow incoming traffic.

This time, invert the Source Address and Destination Address.

In order to avoid packet drops and fragmentation, it is strongly recommended to limit the TCP maximum segment size (MSS) being sent and received.

Enter the following in the CLI Console for both firewall policies:

config firewall policy
   edit <policy-id>
      set tcp-mss-sender 1350
      set tcp-mss-receiver 1350

8. Creating the FortiGate static route

Go to Network > Static Routes and create a new static route forcing outgoing traffic destined to the Microsoft Azure network to flow through the route-based tunnel.

Set the Administrative Distance to a value lower than the value set for the existing default route.

9. Creating a Microsoft Azure Site-to-Site VPN connection

In the Azure portal, locate and select your virtual network gateway.

On the Settings blade, click Connections, and then click Add at the top of the blade to open the Add connection blade.


Fill in the values for your connection and click OK.

Make sure that the Shared Key (PSK) matches the shared key configured on the FortiGate in step 5.

10. Results

Go to Monitor > IPsec Monitor. You should see that the tunnel is UP.

If it is down, right-click the tunnel and select Bring Up.

Go to Log & Report > VPN Events

Select an entry to view more information and verify the connection.

Return to the Microsoft Azure portal, click All resources and navigate to your virtual network gateway.

On the blade for your virtual network gateway, click Connections. You can see the status of each connection.

Click the name of the connection that you want to verify to open Essentials.

In Essentials, you can view more information about your connection.

The Status is ‘Connected’ when you have made a successful connection.

Ingress and egress bytes confirm traffic flowing through the tunnel.


Keith Leroux

Keith Leroux

Technical Writer at Fortinet
Keith Leroux is a writer on the FortiOS 'techdocs' team in Ottawa, Ontario. He obtained a Bachelor's degree from Queen's University in English Language and Literature, and a graduate certificate in Technical Writing from Algonquin College. He spent a year teaching ESL in South Korea. Annyeong!
Keith Leroux

Latest posts by Keith Leroux (see all)

  • Was this helpful?
  • Yes   No
This prep time assumes the time it takes to create a Microsoft Azure account.
“Cook” time is largely dependent on Azure resource deployment times, which may vary.
All times listed are approximations.
Located under All Resources > MyMainGateway (Virtual network gateway) > Overview > Public IP address. Note that it may take some time for this address to populate.
For more information about these combinations, and an up to date list of recommended IPsec VPN settings, see this article.
If the tunnel fails to come up, begin troubleshooting by double-checking the encryption algorithm and PSK settings match on both ends for Phase 1 and Phase 2. For other troubleshooting tips, refer to IPsec VPN Troubleshooting.
  • Alex

    (Since above is using route-based, ie. interface-based VPN configuration) is it equally acceptable to configure MSS Clamping on the virtual Phase 2 interface (ie. ‘set tcp-mss 1350’) rather than in the firewall policy as above (ie. ‘tcp-mss-sender 1350’ and ‘set tcp-mss-receiver 1350’)?

    • Keith Leroux

      Hi Alex, that would seem reasonable enough, but I don’t see “set tcp-mss” in the CLI for phase1-interface.

      • Alex

        I’m referring to the interface (of type ‘tunnel’) that phase1-interface created.

        show full system interface
        set tcp-mss 1350

  • bdickie

    We have been informed that the phase 1 and phase 2 Encryption and Authentication algorithms selected on step 5 are incorrect. The current recommendation is to select more than one encryption algorithm and more than one authentication algorithm. Also the phase 1 and phase 2 don’t have to match.

    Here are the recommended Phase 1 Encryption and Authentication list:
    1. AES128, SHA256
    2. 3DES, SHA256

    And here is the recommended Phase 2 Encryption and Authentication list:

    1. AES256GCM
    2. AES256, SHA1
    3. 3DES, SHA1
    4. AES256, SHA256
    5. AES128, SHA1

    The recommended settings are described in this article: https://docs.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-about-vpn-devices

  • Derek G

    Set this up with a FortiWiFi 60D-POE v5.6.0. I had an issue with Phase 2, got a mismatch error “peer SA proposal not match local policy”, had to use AES256, SHA256. Everything else worked great.

    • Sukrit Phiboon

      Hi Derek,

      Can you show the configurations of both (phase1 and phase 2).


  • Alex

    The Diffie-Hellman Group and the Key Lifetime (seconds) settings presented here is valid earlier and upon our discovery, the these configurations are not valid anymore and this will disconnect your connection to Azure. The settings for Diffie-Hellman Group is 5, 2,1 (check all these numbers) while the Key Lifetime (in seconds) should be 28800. Refer to the image attached. Comments please from Fortigate team needed. Our current setup by the way is Fortigate 100e with OS 5.6 GA. https://uploads.disquscdn.com/images/6948aa1f434d6bead94e0355e4687d7cf65381d6c893435881e3992d5ade1336.png

    • Keith Leroux

      Thanks Alex! The DH Groups and Key Lifetime were recommended by Azure when we wrote this recipe. I’ll have to return to testing, since it appears that Azure has changed the requirements.

  • Moi

    Why had every forticook different timers and proposals to Azure?

    • Keith Leroux

      Hi Moi, the short answer is that Azure changes the requirements for their endpoint to establish the tunnel.