1. Configuring the IPsec VPN using the Wizard

Go to VPN > IPsec Wizard.

Name the VPN connection, set Template Type to Remote Access, select the Cisco Client remote device type, and select Next. 

Set Incoming Interface to the Internet-facing interface.

Select the Pre-shared Key authentication method and enter a pre-shared key.

Apply the appropriate User Group and select Next.

Set Local Interface to the internal interface and set Local Address to all.

Enter a Client Address Range for VPN users and select Create.

Disable split tunneling if you want all traffic (Internet and internal) to go through the IPsec VPN tunnel.

The VPN Creation Wizard provides a summary of created objects.

2. Creating a security policy for remote access to the Internet

Go to Policy & Objects > IPv4 Policy and create a new policy that allows remote users to securely access the Internet.

Set Incoming Interface to the newly created tunnel interface and set Outgoing Interface to the Internet-facing interface.

Set Source to all, Destination Address to all, Schedule to always, and Service to ALL.

Enable NAT and select OK.

3. Results

Select the Shared Secret authentication and enter the same pre-shared key that was entered in the IPsec VPN Wizard, then select OK.

Be sure to Apply your network configuration.

In the Network window on the Mac, select the VPN and select Connect.

You should now be able to browse the Internet and have access to the internal network.

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

3. Creating the Microsoft Azure virtual network gateway

In the portal, go to New. Type “Virtual Network Gateway” in search. Locate Virtual network gateway in the search return and click the entry. This opens the Create virtual network gateway blade.

Click Create at the bottom of the Virtual network gateway blade. The Create virtual network gateway blade will open. Fill in the values for your virtual network gateway and click Create.

4. Creating the Microsoft Azure local network gateway

 The ‘local network gateway’ refers to your on-premises location. Give the local network gateway a name by which Azure can refer to it.

In the portal, from All resources, click +Add. In the Everything blade search box, type Local network gateway, then click to search. This will return a list. Click Local network gateway to open the blade, then click Create to open the Create local network gateway blade.

5. Configuring the FortiGate tunnel

Go to VPN > IPsec Wizard and select Custom.

Enter a Name for the tunnel 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 Transversal and Dead Peer Detection.

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

Under Phase 1 Proposal set the Encryption algorithm to AES 128 and the Authentication algorithm to SHA1.

Select 2 for Diffie-Hellman Group.

Scroll down to Phase 2 Selectors and set Local Address to the local subnet and Remote Address to the VPN tunnel endpoint subnet (found under Virtual Network Address Spaces in Microsoft Azure).

Enable the encryption types to match Phase 1.

6. Creating the FortiGate firewall addresses

Go to Policy & Objects> Addresses and configure a firewall address for the local network.

Create another 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. Make sure that NAT is disabled.

When you are done, create another policy for the same connection to allow incoming traffic.

This time, invert the Source Address and Destination Address.

8. Creating the FortiGate static route

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

Locate your virtual network gateway and click All settings to open the Settings blade.

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

 Make sure that the Shared Key (PSK) matches the shared key configured earlier in FortiGate unit.

10. Results

Go to Monitor > IPsec Monitor. You see the tunnel is UP with incoming and outgoing Data.

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.

1. Configure HUB1

Configure phase 1 parameters

Note that we added some DPD settings to ensure DPD detects IPSec failures much faster than usual in order for convergence to occur.

config vpn ipsec phase1-interface
    edit "ADVPN"
        set type dynamic
        set interface "port1"
        set proposal aes128-sha1
        set add-route disable
        set dhgrp 14
        set auto-discovery-sender enable
        set psksecret somereallysecuresauuuuce
        set dpd-retrycount 3
        set dpd-retryinterval 2
        set dpd on-idle
    next
end

Configure phase2 parameters

config vpn ipsec phase2-interface
    edit "ADVPN-P2"
        set phase1name "ADVPN"
        set proposal aes128-sha1
    next
end

config system interface
    edit "ADVPN"
        set vdom "root"
        set ip 10.10.10.1 255.255.255.255
        set type tunnel
        set remote-ip 10.10.10.254
        set interface "port1"
    next
end

Configure prefix-lists and route-maps

We use a first route-map to select which connected networks to advertise.

Our second route-map ensures to clear the weight of redistributed OSPF routes to 0 to ensure they do not become sticky and also assigns OSPF redistributed routes a local preference of 50. 

config router prefix-list
    edit "PF_REDIS_CONNECTED"
        config rule
            edit 1
                set prefix 192.168.1.0 255.255.255.0
                unset ge
                unset le
            next
            edit 2
                set prefix 192.168.0.0 255.255.255.0
                unset ge
                unset le
            next
        end
    next
end
config router route-map
    edit "RM_REDIS_CONNECTED"
        config rule
            edit 1
                set match-ip-address "PF_REDIS_CONNECTED"
            next
            edit 2
                set action deny
            next
        end
    next
    edit "RM_OSPF_TO_BGP"
        config rule
            edit 1
                set set-local-preference 50
                set set-weight 0
            next
        end
    next
end

Note regarding BGP weight: routes that are sourced by a given BGP instance (either by network statements or through redistribution) are always by default marked with a weight of 32768. When a route stops being learnt from a spoke over iBGP and instead is learnt through OSPF from the other hub, that route will be inserted with a high weight and will no longer be displaced when the spoke reestablishes its BGP adjacency. As this mechanism does not account for IGP backdoor connectivity as our topology does with OSPF, we have to break this mechanism in order to ensure convergence favours routes coming directly from the spokes.

Configure iBGP and route-reflection

Timers for BGP are modified to accelerate convergence. Care should however be given to ensure that the combination of faster DPD and faster BGP timers does not result in issues when the topology deployed has a very large number of spokes.

We have route-map filtering configured for the redistribution of both connected networks and OSPF-learnt networks.

The admin distance of iBGP routes is also modified to be preferred over OSPF. While not a common configuration, it is however crucial in our usage as both HUB devices must always prefer their iBGP routes to anything learnt over OSPF. This is supplemental to our previous “route weight” route-map fix.

config router bgp
    set as 65000
    set router-id 192.168.1.1
    set distance-internal 100
    config neighbor-group
        edit "ADVPN"
            set advertisement-interval 10
            set next-hop-self enable
            set remote-as 65000
            set keep-alive-timer 2
            set holdtime-timer 6
            set route-reflector-client enable
        next
    end
    config neighbor-range
        edit 1
            set prefix 10.10.10.0 255.255.255.0
            set neighbor-group "ADVPN"
        next
    end
    config redistribute "connected"
        set status enable
        set route-map "RM_REDIS_CONNECTED"
    end
    config redistribute "ospf"
        set status enable
        set route-map "RM_OSPF_TO_BGP"
    end
end

Configure OSPF

This is a standard OSPF configuration with BGP redistribution. Note that we are bumping the redistribution metric for our second HUB as documented further along in this article.

config router ospf
    set router-id 192.168.0.1
    config area
        edit 0.0.0.0
        next
    end
    config network
        edit 1
            set prefix 192.168.0.0 255.255.0.0
        next
    end
    config redistribute "bgp"
        set status enable
    end
end

Configure firewall policies

config firewall policy
    edit 0
        set name "OUT ADVPN"
        set srcintf "port1" "port2" "port3" "ADVPN"
        set dstintf "port1" "port2" "port3" "ADVPN"
        set srcaddr "all"
        set dstaddr "all"
        set action accept
        set schedule "always"
        set service "ALL"
        set status enable
    next
end

2. Configure HUB2

Configure phase 1 parameters

This part is identical to HUB1.

config vpn ipsec phase1-interface
    edit "ADVPN"
        set type dynamic
        set interface "port1"
        set proposal aes128-sha1
        set add-route disable
        set dhgrp 14
        set auto-discovery-sender enable
        set psksecret somereallysecuresauuuuce
        set dpd-retrycount 3
        set dpd-retryinterval 2
        set dpd on-idle
    next
end

Configure the phase2 parameters

This part is identical to HUB1.

config vpn ipsec phase2-interface
    edit "ADVPN-P2"
        set phase1name "ADVPN"
        set proposal aes128-sha1
    next
end

Our second topology’s IP subnet is configured.

config system interface
    edit "ADVPN"
        set vdom "root"
        set ip 10.10.11.1 255.255.255.255
        set type tunnel
        set remote-ip 10.10.11.254
        set interface "port1"
    next
end

Configure prefix-lists and route-maps

Other than modifying the connected subnets advertised, we are using a local preference of 25 for OSPF routes redistributed by BGP on our second hub. This ensures HUB1 is prioritized for reaching those subnets.

config router prefix-list
    edit "PF_REDIS_CONNECTED"
        config rule
            edit 1
                set prefix 192.168.2.0 255.255.255.0
                unset ge
                unset le
            next
            edit 2
                set prefix 192.168.0.0 255.255.255.0
                unset ge
                unset le
            next
        end
    next
end
config router route-map
    edit "RM_REDIS_CONNECTED"
        config rule
            edit 1
                set match-ip-address "PF_REDIS_CONNECTED"
            next
            edit 2
                set action deny
            next
        end
    next
    edit "RM_OSPF_TO_BGP"
        config rule
            edit 1
                set set-local-preference 25
                set set-weight 0
            next
        end
    next
end

Configure iBGP and route-reflection

Our second topology uses the same AS number therefore most of the configuration is identical except for router-id and subnets.

config router bgp
    set as 65000
    set router-id 192.168.2.1
    set distance-internal 100
    config neighbor-group
        edit "ADVPN"
            set advertisement-interval 10
            set next-hop-self enable
            set remote-as 65000
            set keep-alive-timer 2
            set holdtime-timer 6
            set route-reflector-client enable
        next
    end
    config neighbor-range
        edit 1
            set prefix 10.10.11.0 255.255.255.0
            set neighbor-group "ADVPN"
        next
    end
    config redistribute "connected"
        set status enable
        set route-map "RM_REDIS_CONNECTED"
    end
    config redistribute "ospf"
        set status enable
        set route-map "RM_OSPF_TO_BGP"
    end
end

Configure OSPF

HUB2’s OSPF configuration is identical to HUB1 except for a redistribution metric which is bumped to ensure HUB2 is not the preferred egress for the datacenter to use.

config router ospf
    set router-id 192.168.0.2
    config area
        edit 0.0.0.0
        next
    end
    config network
        edit 1
            set prefix 192.168.0.0 255.255.0.0
        next
    end
    config redistribute "bgp"
        set status enable
        set metric 5
    end
end

Configure firewall policies

config firewall policy
    edit 0
        set name "OUT ADVPN"
        set srcintf "port1" "port2" "port3" "ADVPN"
        set dstintf "port1" "port2" "port3" "ADVPN"
        set srcaddr "all"
        set dstaddr "all"
        set action accept
        set schedule "always"
        set service "ALL"
        set status enable
    next
end

3. Configure the Spoke FortiGates

Configure phase 1 parameters

Compared with a single hub setup, we add a second ADVPN connection towards our second hub.

Note that we are configuring only one of the spokes in this example – the parameters that need to change for each spoke are highlighted in red.

config vpn ipsec phase1-interface
 edit "ADVPN"
  set interface "port1"
  set proposal aes128-sha1
  set add-route disable
  set dhgrp 14
  set auto-discovery-receiver enable
  set remote-gw 192.0.2.11
  set psksecret ***
  set dpd-retrycount 3
  set dpd-retryinterval 2
  set dpd on-idle
 next
 edit "ADVPN2"
  set interface "port1"
  set proposal aes128-sha1
  set add-route disable
  set dhgrp 14
  set auto-discovery-receiver enable
  set remote-gw 192.0.2.12
  set psksecret ***
  set dpd-retrycount 3
  set dpd-retryinterval 2
  set dpd on-idle
 next
end

Configure the phase2 parameters

Spokes benefit from having auto-negotiate enabled in order to ensure tunnels come up given the usage of dynamic routing to learn actual protected traffic subnets.

config vpn ipsec phase2-interface
    edit "ADVPN-P2"
        set phase1name "ADVPN"
        set proposal aes128-sha1
	set auto-negotiate enable
    next
    edit "ADVPN2-P2"
        set phase1name "ADVPN2"
        set proposal aes128-sha1
	set auto-negotiate enable
    next
end

Configure the tunnel interface IPs

Each ADVPN topology needs a hardcoded IP configured.

config system interface
    edit "ADVPN"
        set vdom "root"
        set ip 10.10.10.3 255.255.255.255
        set type tunnel
        set remote-ip 10.10.10.1
        set interface "port1"
    next
    edit "ADVPN2"
        set vdom "root"
        set ip 10.10.11.3 255.255.255.255
        set type tunnel
        set remote-ip 10.10.11.1
        set interface "port1"
    next
end

Configure iBGP

To ensure our primary ADVPN topology is prioritized, we apply a local preference of 200 to inbound and outbound routes towards the primary ADVPN topology’s hub.

config router route-map
    edit "RM_ADVPN1"
        config rule
            edit 1
                set set-local-preference 200
            next
        end
    next
end
config router bgp
    set as 65000
    set router-id 192.168.3.1
    config neighbor
        edit "10.10.10.1"
            set remote-as 65000
            set route-map-out "RM_ADVPN1"
        next
        edit "10.10.11.1"
            set remote-as 65000
        next
    end
    config network
        edit 1
            set prefix 192.168.3.0 255.255.255.0
        next
    end
end

Configure a static route for the tunnel IP subnet

Both ADVPN topologies require a summary route to be present on spokes in order for recursive routing to function when addressing other spokes.

For good measure however, we have two additional floating blackhole routes to ensure that if the tunnels are down, BGP does not attempt to establish connections with the hub over the default gateway nor install recursive routes for other spokes through the default gateway. This ensures faster convergence upon tunnel restoration.

config router static
    edit 0
        set dst 10.10.10.0 255.255.255.0
        set device "ADVPN"
    next
    edit 0
        set dst 10.10.11.0 255.255.255.0
        set device "ADVPN2"
    next
    edit 0
        set dst 10.10.10.0 255.255.255.0
        set distance 254
        set blackhole enable
    next
    edit 0
        set dst 10.10.11.0 255.255.255.0
        set distance 254
        set blackhole enable
    next
end

Configure policies

config firewall policy
    edit 0
        set name "Allowed traffic"
        set srcintf "lan" "ADVPN" "ADVPN2"
        set dstintf "lan" "ADVPN" "ADVPN2"
        set srcaddr "all"
        set dstaddr "all"
        set action accept
        set schedule "always"
        set service "ALL"
        set status enable
    next
end

1. Creating a user group for remote users

Go to User & Device > User Definition. Create a local user account for an IPsec VPN user.

2. Adding a firewall address for the local network

Go to Policy & Objects > Addresses and create an address for the local network.

Set Type to IP/Netmask, Subnet/IP Range to the local subnet, and Interface to an internal port.

3. Configuring the IPsec VPN using the IPsec VPN Wizard

Go to VPN > IPsec Wizard and create a new tunnel using a pre-existing template.

Name the VPN connection. Set Template to Remote Access, and set Remote Device Type to FortiClient VPN for OS X, Windows, and Android.

Set the Incoming Interface to the internet-facing interface and Authentication Method to Pre-shared Key.

Enter a pre-shared key and select the new user group, then click Next.

Set Local Interface to an internal interface (in the example, lan) and set Local Address to the local LAN address.

Enter an Client Address Range for VPN users.

Make sure Enable IPv4 Split Tunnel is not selected, so that all Internet traffic will go through the FortiGate.

Select Client Options as desired.

After you create the tunnel, a summary page appears listing the objects which have been added to the FortiGate’s configuration by the wizard.

4. Creating a security policy for access to the Internet

The IPsec wizard automatically created a security policy allowing IPsec VPN users to access the internal network. However, since split tunneling is disabled, another policy must be created to allow users to access the Internet through the FortiGate.

Go to Policy & Objects > IPv4 Policies and create a new policy. Set a policy name that will identify what this policy is used for (in the example, IPsec-VPN-Internet)

Set Incoming Interface to the tunnel interface and Outgoing Interface to wan1. Set Source to the IPsec client address range, Destination Address to all, Service to ALL, and enable NAT.

Configure any remaining firewall and security options as desired.

5. Configuring FortiClient

Open FortiClient, go to Remote Access and Add a new connection.

Set the Type to IPsec VPN and Remote Gateway to the FortiGate IP address.

Set Authentication Method to Pre-Shared Key and enter the key below.

6. Results

On FortiClient, select the VPN, enter the username and password, and select Connect.

Once the connection is established, the FortiGate assigns the user an IP address and FortiClient displays the status of the connection, including the IP address, connection duration, and bytes sent and received.

On the FortiGate, go to Monitor > IPsec Monitor and verify that the tunnel Status is Up.

Under Remote Gateway, the monitor shows the FortiClient user’s assigned gateway IP address.

Browse the Internet, then go to FortiView > All Segments > Policies and select the now view. You can see traffic flowing through the IPsec-VPN-Internet policy.

Right-click on the policy, then select Drill Down to Details. You can see more information about the traffic.

Under Source, you can also see the IP address assigned to the FortiClient user (10.10.100.1).

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 to AES 128 and the Authentication algorithm to SHA256.

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 type to match Phase 1.

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.

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.

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 to AES 128 and the Authentication algorithm to SHA256.

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 type to match Phase 1.

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.

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.

1. Establishing the tunnel

If the tunnel is currently down, go to Monitor > IPsec Monitor, right-click the tunnel, and select Bring Up.

2. Capturing packets

Go to Network > Packet Capture and create a new entry.

Set Interface to the external-facing interface (in this case, wan1).

Select Enable Filters and enter Protocol 50 (the protocol number for ESP).

In the Packet Capture list, highlight the new entry and select Start/Resume Capturing to begin capturing packets for the next step.

Ping through the tunnel to populate the packet capture with traffic.

For example, in Windows Command Prompt, enter: ping x.x.x.x -n 100, where x.x.x.x is the remote tunnel endpoint (-n 100 will ping 100 times).

In the Packet Capture list on the FortiGate, select the Download option to save the .pcap file to your computer once the packets have been captured.

3. Configuring Wireshark

Go to Edit > Preferences and navigate to Protocol > ESP.

Check all BUT Attempt to detect/decode NULL encrypted ESP payloads.

Select Edit… to open the ESP SAs configuration table. 

On the FortiGate, open the CLI Console and enter the command diag vpn tunnel list.

Make note of the information next to dec: and enc:. You will need the SPI information, as well as the ESP and AH keys for both the remote and local FortiGates.

In Wireshark’s ESP SAs configuration table, add a new entry for each direction of the tunnel.

Note the image in the example:

• Src IP and Dest IP refer to the gateway addresses.
• The SPI information in the diag output will help you determine which encryption and authentication keys to use for each direction.
• Note that 0x must be prepended to the SPI entries as well as each of the Encyrption and Authentication Keys.

Click OK when you are done.

4. Results

1. Creating the HQ tunnel

For the sake of simplicity, you will create a site-to-site IPsec VPN tunnel using the VPN Creation Wizard. You will later convert it to a custom tunnel.

Go to VPN > IPsec Wizard.

Enter a Name for the tunnel.

Select the Site to Site template and set the Remote Device Type to FortiGate.

Click Next.

Set IP address to the remote gateway interface. The Outgoing Interface should populate automatically.

Enter a Pre-shared Key and click Next.

Select the Local Interface and set the Local Subnets and Remote Subnets. Ensure that the subnets do not overlap.

Click Create.

The VPN Creation Wizard provides a summary of the VPN configuration.

Click Show Tunnel List.

2. Customizing the HQ tunnel

In the Edit VPN Tunnel dialog, click Convert to Custom Tunnel.

Edit the Authentication section and enable IKE Version 2.

Edit the Phase 1 Proposal section.

Deselect Diffie-Hellman groups 5 and 14 and select groups 28, 29, and 30.

Edit the Phase 2 Selectors section (don’t click the Add Button) and click Advanced….

Once again, deselect Diffie-Hellman groups 5 and 14 and select groups 28, 29, and 30.

Click OK.

3. Creating and customizing the Remote Office tunnel

Repeat steps 1 and 2 on the Remote Office FortiGate, alternating names and IP addresses appropriately.

Ensure that the same Phase 1 and Phase 2 selectors are applied and that there are no overlapping subnets.

4. Results

On either FortiGate, navigate to Monitor > IPsec Monitor and verify that the tunnel status is Up.

You can confirm the use of Brainpool curves by performing diagnostics on the tunnel:

Go to Monitor > IPsec Monitor, highlight the tunnel and select Bring Down.

Open the CLI Console (>_) and enter the following command:

diagnose debug application ike 63
diagnose debug enable

Return to Monitor > IPsec Monitor and bring the tunnel up again, then view the CLI Console.

While the SA proposal negotiates the tunnel, the output of the diagnose command should be similar to the following, where I’ve highlighted the relevant parts:

FGT_1 # ike 0: comes 172.25.177.56:500->172.25.176.56:500,ifindex=5....
ike 0: IKEv2 exchange=INFORMATIONAL id=262e65aad12e5e8e/598faf8398c7acbe:00000001 len=80
ike 0:HQ_to_Remote:7: received informational request
ike 0:HQ_to_Remote:7: processing delete request (proto 3)
ike 0:HQ_to_Remote: deleting IPsec SA with SPI 00f82773
ike 0:HQ_to_Remote:HQ_to_Remote: deleted IPsec SA with SPI 00f82773, SA count: 0
ike 0:HQ_to_Remote: sending SNMP tunnel DOWN trap for HQ_to_Remote
ike 0:HQ_to_Remote:7: sending delete ack
ike 0:HQ_to_Remote:7: sent IKE msg (INFORMATIONAL_RESPONSE): 172.25.176.56:500->172.25.177.56:500, len=80, id=262e65aad12e5e8e/598faf8398c7acbe:00000001
ike 0: comes 172.25.177.56:500->172.25.176.56:500,ifindex=5....
ike 0: IKEv2 exchange=CREATE_CHILD id=262e65aad12e5e8e/598faf8398c7acbe:00000002 len=656
ike 0:HQ_to_Remote:7: received create-child request
ike 0:HQ_to_Remote:7: responder received CREATE_CHILD exchange
ike 0:HQ_to_Remote:7: responder creating new child
ike 0:HQ_to_Remote:7:1: peer proposal:
ike 0:HQ_to_Remote:7:1: TSi_0 0:192.168.180.0-192.168.180.255:0
ike 0:HQ_to_Remote:7:1: TSr_0 0:192.168.1.0-192.168.1.255:0
ike 0:HQ_to_Remote:7:HQ_to_Remote:1: trying
ike 0:HQ_to_Remote:7:HQ_to_Remote:1: matched phase2
ike 0:HQ_to_Remote:7:HQ_to_Remote:1: accepted proposal:
ike 0:HQ_to_Remote:7:HQ_to_Remote:1: TSi_0 0:192.168.180.0-192.168.180.255:0
ike 0:HQ_to_Remote:7:HQ_to_Remote:1: TSr_0 0:192.168.1.0-192.168.1.255:0
ike 0:HQ_to_Remote:7:HQ_to_Remote:1: autokey
ike 0:HQ_to_Remote:7:HQ_to_Remote:1: incoming child SA proposal:
ike 0:HQ_to_Remote:7:HQ_to_Remote:1: proposal id = 1:
ike 0:HQ_to_Remote:7:HQ_to_Remote:1: protocol = ESP:
ike 0:HQ_to_Remote:7:HQ_to_Remote:1: encapsulation = TUNNEL
ike 0:HQ_to_Remote:7:HQ_to_Remote:1: type=ENCR, val=AES_CBC (key_len = 128)
ike 0:HQ_to_Remote:7:HQ_to_Remote:1: type=INTEGR, val=SHA
ike 0:HQ_to_Remote:7:HQ_to_Remote:1: type=DH_GROUP, val=ECP512BP
ike 0:HQ_to_Remote:7:HQ_to_Remote:1: type=DH_GROUP, val=ECP384BP
ike 0:HQ_to_Remote:7:HQ_to_Remote:1: type=DH_GROUP, val=ECP256BP
ike 0:HQ_to_Remote:7:HQ_to_Remote:1: type=ESN, val=NO
ike 0:HQ_to_Remote:7:HQ_to_Remote:1: matched proposal id 1
ike 0:HQ_to_Remote:7:HQ_to_Remote:1: proposal id = 1:
ike 0:HQ_to_Remote:7:HQ_to_Remote:1: protocol = ESP:
ike 0:HQ_to_Remote:7:HQ_to_Remote:1: encapsulation = TUNNEL
ike 0:HQ_to_Remote:7:HQ_to_Remote:1: type=ENCR, val=AES_CBC (key_len = 128)
ike 0:HQ_to_Remote:7:HQ_to_Remote:1: type=INTEGR, val=SHA
ike 0:HQ_to_Remote:7:HQ_to_Remote:1: type=DH_GROUP, val=ECP512BP
ike 0:HQ_to_Remote:7:HQ_to_Remote:1: type=ESN, val=NO
ike 0:HQ_to_Remote:7:HQ_to_Remote:1: lifetime=43200
ike 0:HQ_to_Remote:7:HQ_to_Remote:1: PFS enabled, group=30
ike 0:HQ_to_Remote:7:HQ_to_Remote:1: replay protection enabled
ike 0:HQ_to_Remote:7:HQ_to_Remote:1: set sa life soft seconds=42929.
ike 0:HQ_to_Remote:7:HQ_to_Remote:1: set sa life hard seconds=43200.
ike 0:HQ_to_Remote:7:HQ_to_Remote:1: IPsec SA selectors #src=1 #dst=1
ike 0:HQ_to_Remote:7:HQ_to_Remote:1: src 0 7 0:192.168.1.0-192.168.1.255:0
ike 0:HQ_to_Remote:7:HQ_to_Remote:1: dst 0 7 0:192.168.180.0-192.168.180.255:0
ike 0:HQ_to_Remote:7:HQ_to_Remote:1: add IPsec SA: SPIs=2bf96e39/00f82774
ike 0:HQ_to_Remote:7:HQ_to_Remote:1: added IPsec SA: SPIs=2bf96e39/00f82774
ike 0:HQ_to_Remote:7:HQ_to_Remote:1: sending SNMP tunnel UP trap
ike 0:HQ_to_Remote:7:HQ_to_Remote:1: responder preparing CREATE_CHILD message
ike 0:HQ_to_Remote:7: sent IKE msg (CREATE_CHILD_RESPONSE): 172.25.176.56:500->172.25.177.56:500, len=336, id=262e65aad12e5e8e/598faf8398c7acbe:00000002

Note how the SA proposal finds the first matching encryption type, in this case ECP512BP (DH Group 30), which represents ‘Elliptic Curve Parameter 512-bit Brainpool Primitive’.

The diagnostic debug will run for 30 minutes, but you can stop it with these commands:

diagnose debug disable
diagnose debug reset

1. Configuring the IPsec VPN on HQ

On HQ, go to VPN > IPsec Wizard and create a new tunnel.

In the VPN Setup step, set Template Type to Site to Site and Remote Device Type to FortiGate.

In the Authentication step, set IP Address to the public IP address of the Branch FortiGate (in the example, 172.25.177.46).

After you enter the IP address, an available interface will be assigned as the Outgoing Interface. If you want to use a different interface, select it from the drop-down menu.

Set a secure Pre-shared Key.

In the Policy & Routing step, set Local Interface to LAN. The local subnet is added automatically. Set Remote Subnets to Branch’s local subnet (in the example, 192.168.13.0/24).

A summary page shows the configuration created by the wizard, including firewall addresses, static routes, and security policies.

2. Configuring the IPsec VPN on Branch

On Branch, go to VPN > IPsec Wizard and create a new tunnel.

In the VPN Setup step, set Template Type to Site to Site and Remote Device Type to FortiGate.

In the Authentication step, set IP Address to the public IP address of the HQ FortiGate (in the example, 172.25.176.142).

After you enter the IP address, an available interface will be assigned as the Outgoing Interface. If you want to use a different interface, select it from the drop-down menu.

Set a secure Pre-shared Key that was used for the VPN on HQ.

In the Policy & Routing step, set Local Interface to LAN. The local subnet is added automatically. Set Remote Subnets to HQ’s local subnet (in the example, 192.168.37.0/24).

A summary page shows the configuration created by the wizard, including firewall addresses, static routes, and security policies.

3. Results

On either FortiGate, go to Monitor > IPsec Monitor to verify the status of the VPN tunnel. Right-click under Status and select Bring Up.

A user on either of the office networks should be able to connect to any address on the other office network transparently.

If you need to generate traffic to test the connection, ping Branch’s LAN interface from a device on HQ’s internal network.

1. Configure the HQ IPsec VPN

On the HQ FortiGate, go to VPN > IPsec Wizard.

Select the Site to Site template, and select FortiGate.

In the Authentication step, set IP Address to the IP of the Branch FortiGate (in the example, 172.31.1.65). After you enter the gateway, an available interface will be assigned as the Outgoing Interface.  Set a secure Pre-shared Key.

In the Policy & Routing step, set the Local Interface. The Local Subnets will be added automatically. Set Remote Subnets to the Branch FortiGate’s local subnet (10.1.2.0/24)

A summary page shows the configuration created by the wizard.

2. Configure the Branch IPsec VPN

On the Branch FortiGate, go to VPN > IPsec Wizard.

Select the Site to Site template, and select FortiGate.

In the Authentication step, set IP Address to the IP of the HQ FortiGate (in the example, 172.31.1.64). After you enter the gateway, an available interface will be assigned as the Outgoing Interface.

Set the same Pre-shared Key that was used for HQ’s VPN.

In the Policy & Routing step, set the Local Interface. The Local Subnets will be added automatically. Set Remote Subnets to the HQ FortiGate’s local subnet (in the example, 10.1.1.0/24).

A summary page shows the configuration created by the wizard, including firewall addresses, firewall address groups, a static route, and security policies.

On either FortiGate, go to Monitor > IPsec Monitor to verify the status of the VPN tunnel. Right-click under Status and select Bring Up.

At this point in the configuration, the multicast server behind the HQ FortiGate should be able to ping the client at Branch.   If you need to generate traffic to test the connection, ping the Branch FortiGate’s internal interface from the HQ’s internal network.

3. Configure the HQ multicast policy and phase 2 settings

On the HQ FortiGate, go to Policy & Objects > Multicast Policy.  (If multicast policy is not available, go to System > Feature Visibility and enable the feature).

Create a new policy and allow the multicast traffic from the source interface to the tunnel.

Create another multicast policy that allows multicast traffic from the tunnel to the LAN interface of the multicast server.

Add a phase 2 selector to the VPN tunnel by going to VPN > IPsec Tunnels and editing the tunnel.  Add a phase 2 selector with 10.1.1.0/24 as the local address and 239.0.0.0/8 as the remote address.

Enable multicast forwarding

At the CLI prompt, enter:

config system settings
       set multicast-forward enable
end

4. Configure Branch multicast policy and phase 2 settings

On the Branch FortiGate, go to Policy & Objects > Multicast Policy.  (If multicast policy is not available, go to System > Feature Visibility and enable the feature).

Create a new policy and allow the multicast traffic from the source interface to the tunnel.

Create another multicast policy that allows multicast traffic from the tunnel to the LAN interface of the multicast server.

Add a phase 2 selector to the VPN tunnel by going to VPN > IPsec Tunnels and editing the tunnel.  Add a phase 2 selector with 239.0.0.0/8 as the local address and 10.1.1.0/24 as the remote address.

Enable multicast forwarding

At the CLI prompt, enter:

config system settings
    set multicast-forward enable
end

5. Results

Multicast traffic should now flow from the multicast server to the client.  Start the multicast stream and make note the of the address being used.  In this configuration, all multicast traffic that matches 239.0.0.0/8 should flow from the HQ to the Branch.

Multicast traffic flow can be verified by issuing the “diag sys mcast-session list” command on the branch Fortigate.

In the example above, we see the multicast group sourcing from the HQ server and transmitting on multicast group address 239.1.1.100:1234.  The multicast receiver application on the branch host should now be able to receive this multicast traffic.

1. Configuring the tunnel interfaces

In order for FortiTelemetry traffic to flow securely through the IPsec VPN, FortiTelemetry traffic must travel between the tunnel interfaces, with the interface on External listening for this traffic.

The tunnel interfaces require IP addresses. In this example, the External tunnel interface is assigned the IP address 1.1.1.1 and the Branch tunnel interface is assigned the IP address 1.1.1.2.

On External, go to Network > Interfaces and edit the tunnel interface.

Set IP to the local IP address for this interface (1.1.1.1) and Remote IP to the local IP address for the Branch tunnel interface (1.1.1.2).

Under Administrative Access, enable FortiTelemetry.

On Branch, go to Network > Interfaces and edit the tunnel interface.

Set IP to the local IP address for this interface (1.1.1.2) and Remote IP to the local IP address for the External tunnel interface (1.1.1.1). 

2. Adding the tunnel interfaces to the VPN

Create a second address for the Branch tunnel interface.

For this address, enable Static Route Configuration.

Go to VPN > IPsec Tunnels and edit the VPN tunnel. Select Convert To Custom Tunnel.

Under Phase 2 Selectors, create a second Phase 2 allowing traffic between the External tunnel interface to the Branch tunnel interface.

Go to Network > Static Routes and create a route to the Branch tunnel interface.

Set Destination to Named Address and select the firewall address. Set Device to the tunnel interface.

Go to Policy & Objects > IPv4 Policy and edit the policy allowing local VPN traffic.

Set Source to include the External tunnel interface and Destination to include the Branch tunnel interface.

On Branch, repeat this step to include the following:

• Addresses for both tunnel interfaces (the address for the Branch tunnel interface must have Static Route Configuration enabled)
• A Phase 2 allowing traffic between the Branch tunnel interface and the External tunnel interface
• A static route to the External tunnel interface
• Edited policies that allow traffic to flow between the tunnel interfaces

Go to Monitor > IPsec Monitor and restart the VPN tunnel, allowing the new phase 2 to take effect.

3. Adding Branch to the Security Fabric

On Branch, go to Security Fabric > Settings and enable FortiGate Telemetry. Set the Group name and Group password of the Security Fabric.

Enable Connect to upstream FortiGate and set FortiGate IP to the IP address of the External tunnel interface.

Add lan to the list of FortiTelemetry enabled interfaces.

4. Allowing Branch to access the FortiAnalyzer

On Branch, go to Policy & Objects > Addresses and create an address for the FortiAnalyzer.

Enable Static Route Configuration.

Go to VPN > IPsec Tunnels and create a Phase 2 allowing traffic between the Branch tunnel interface and the FortiAnalyzer.

Go to Network > Static Routes and create a route to the FortiAnalyzer.

Go to Policy & Objects > IPv4 Policy and create a policy allowing traffic from the VPN tunnel to the FortiAnalyzer.

Enable NAT for this policy.

5. Results

6. (Optional) Using local logging for Branch

If you would prefer to use local logging for Branch, rather than sending logs to a remote FortiAnalyzer, you can do so using the following CLI command:

config system csf
  set logging-mode local
end

You can then go to Log & Report > Log Settings and configure local logging as required.

This option is available for all FortiGates in the Security Fabric, except for the root FortiGate.

1. Configuring the site-to-site IPsec VPN on FGT_1

Go to VPN > IPSec Wizard.

Name the VPN connection and select Site to Site.

Set IP Address to the Internet-facing interface.

Select Pre-shared Key for Authentication Method and enter the pre-shared key.

Set Local Interface to the internal interface and set Local Subnets to include the internal and SSL VPN subnets for FGT_1.

Set Remote Subnets to include the internal subnet for FGT_2.

2. Configuring SSL VPN settings

Go to VPN > SSL-VPN Settings and set Listen on Interface(s) to wan1.

To avoid port conflicts, set Listen on Port to 10443.

Set Restrict Access to Allow access from any host.

Under Tunnel Mode Client Settings, enable Specify custom IP ranges and include the SSL VPN subnet range created by the IPsec VPN wizard.

Under Authentication/Portal Mapping, add the VPN user group to the tunnel-access portal. Set All Other Users/Groups to the web-access portal.

3. Configuring the SSL VPN portal

Go to VPN > SSL-VPN Portals and edit the tunnel-access portal.

Turn on Enable Split Tunneling so that only traffic intended for the local or remote networks will flow through FGT_1 and be subject to the corporate security profiles.

Next to Routing Address, add the local and remote IPsec VPN subnets created by the IPsec VPN wizard.

Next to Source IP Pools, add the SSL VPN subnet range created by the IPsec VPN wizard.

4. Adding policies on FGT_1

Go to Policy & Objects > IPv4 Policy and create a new policy that allows SSL VPN users access to the internal network.

Set Incoming Interface to ssl.root and set Outgoing Interface to internal.

Set Source to the SSL VPN subnet created by the IPsec VPN wizard and add the VPN user group.

Set Destination to the local IPsec VPN subnet (which represents the internal subnet).

Set the Schedule and set Service to all.

Enable NAT.

Create another policy that allows SSL VPN users access to the IPsec VPN tunnel.

Set Incoming Interface to ssl.root and set Outgoing Interface to the IPsec tunnel interface (in this case, Site1).

Set Source to the SSL VPN subnet created by the IPsec VPN wizard and add the VPN user group.

Set Destination to the remote IPsec VPN subnet.

Set the Schedule and set Service to all.

Do NOT enable NAT.

5. Configuring the site-to-site IPsec VPN on FGT_2

Go to VPN > IPSec Wizard.

Name the VPN connection and select Site to Site.

Set IP Address to the Internet-facing interface.

Select Pre-shared Key for Authentication Method and enter the pre-shared key that matches the FGT_1 configuration.

Set Local Interface to the internal interface and set Local Subnets to include the internal network subnet for FGT_2.

Set Remote Subnets to include the internal and SSL VPN subnets for FGT_1.

6. Results

7. Debug

In order to diagnose potential issues, run the following debug commands on FGT_1 using the CLI Console:

diag debug reset
diag debug flow show function-name enable
diag debug flow show iprope enable
diag debug flow filter addr 192.168.177.99
diag debug flow filter proto 1
diag debug flow trace start 2
diag debug enable

Send a PING through the SSL VPN tunnel to 192.168.177.99 and analyze the output of the debug. Disable the debug output with the following command:

diag debug disable

If the traffic is entering the correct VPN tunnel on FGT_1, then run the same commands on FGT_2 to check whether the traffic is reaching the correct tunnel. If it is reaching the correct tunnel, confirm that the SSL VPN tunnel range is configured in the remote side quick mode selectors.

You can also run a sniffer command on FGT_1 as follows:

diag sniff packet any "host 192.168.177.99 and icmp" 4

If you suspect an IPsec VPN issue, run the following commands on either FortiGate:

diag debug reset
diag vpn ike gateway clear
diag debug application ike -1
diag debug enable

When you are satisfied with the debug output, disable the debug as follows:

diag debug disable

For more troubleshooting information for SSL VPN and IPsec VPN, refer to the following:

• SSL VPN Troubleshooting
• IPsec VPN Troubleshooting

1. Enabling OCVPN

On FGT_1, go to VPN > One-Click VPN Settings.

Set Status to Enabled and confirm Cloud Status. This may take a minute or two.

As indicated, a green checkmark appears along with the message Connected to the cloud service.

Finally, add the required Subnets from FGT_1.

On FGT_2, repeat the steps above.

Enable and confirm connection to the cloud service, and then add the required subnets from FGT_2.

2. Confirming cloud membership

In the Cloud Members table on FGT_1, click Refresh and confirm the entries.

The remote gateway and corresponding subnets for each device should populate the list.

You can perform the step above on any FortiGate that is a member of the OCVPN cloud.

FGT_2 should return the same results as above.

3. Results

As the Cloud Members table populates, the OCVPN cloud updates each member automatically.

You can now verify that the remainder of the configuration has also been created, and proceed to test the tunnel.

Using Command Prompt/Terminal, attempt a ping from one internal network to the other. Ping should be successful:

ping 192.168.177.99

Pinging 192.168.177.99 with 32 bytes of data:
Reply from 192.168.177.99: bytes=32 time=5ms TTL=254
Reply from 192.168.177.99: bytes=32 time=1ms TTL=254
Reply from 192.168.177.99: bytes=32 time<1ms TTL=254
Reply from 192.168.177.99: bytes=32 time<1ms TTL=254

Ping statistics for 192.168.177.99:
 Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
 Minimum = 0ms, Maximum = 5ms, Average = 1ms

Now, disable OCVPN (VPN > One-Click VPN Settings) and repeat the ping attempt to confirm that OCVPN was indeed responsible for the successful ping above:

ping 192.168.177.99

Pinging 192.168.177.99 with 32 bytes of data:
Reply from 192.168.176.99: Destination net unreachable.
Reply from 192.168.176.99: Destination net unreachable.
Reply from 192.168.176.99: Destination net unreachable.
Reply from 192.168.176.99: Destination net unreachable.

Ping statistics for 192.168.177.99:
 Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

Re-enable OCVPN.

4. Troubleshooting

The following diagnose commands may prove useful.

To verify OCVPN status, use the following command:

FGT_1 # diag vpn ocvpn status
Current State : registered
OCVPN Status : OK (200)

To view device states, use the following command:

FGT_1 # diag vpn ocvpn device-state
FGT_1 wan1 172.25.176.56 0 6 0 2 200 2 0x3 0x3

To print a log report, use the following command:

FGT_1 # diag vpn ocvpn log
OCVPN Polling: state = undefined
cvpn_save_state: FGT_1 <null> 0.0.0.0 -1 0 0 0 0 0 0x0 0x0
OCVPN Polling: state = undefined
cvpn_save_state: FGT_1 <null> 0.0.0.0 -1 0 0 0 0 0 0x0 0x0
OCVPN Polling: state = undefined
cvpn_save_state: FGT_1 <null> 0.0.0.0 -1 0 0 0 0 0 0x0 0x0

========================

Thurs Mar 29 09:00:00 2018

========================

cvpn_load_state: FGT_1 <null> 0.0.0.0 -1 0 0 0 0 0 0x0 0x0
OCVPN Register: sn=x, num_subnets=0
Current State: undefined -> registering
cvpn_save_state: FGT_1 <null> 0.0.0.0 -1 2 0 0 0 0 0x0 0x0
WAN intf wan1, IP 172.25.176.56/255.255.255.0
WAN intf changed from <null> to wan1
WAN IP changed from 0.0.0.0 to 172.25.176.56

Local Subnets:
192.168.176.0/255.255.255.0
JSON Update request = '{ "SN": "x", "IPv4": "172.25.176.56", "port": "500", "Name": "FGT_1", "subnets": [ "192.168.176.0\/255.255.255.0" ] }'
Sending OCVPN request: method=Update, data='{ "SN": "x", "IPv4": "172.25.176.56", "port": "500", "Name": "FGT_1", "subnets": [ "192.168.176.0\/255.255.255.0" ] }'
Received OCVPN response: method=Update, res=0, http_resp=200
JSON Response: '{"key":"","rev":1,"members":[{"IPv4":"172.25.176.56","port":"500","slot":0,"subnets":["192.168.176.0/255.255.255.0"],"Name":"FGT_1"}]}'
Member table size = 1
Member: { "IPv4": "172.25.176.56", "port": "500", "slot": 0, "subnets": [ "192.168.176.0\/255.255.255.0" ], "Name": "FGT_1" }
Subnet 192.168.176.0/255.255.255.0
cvpn_config_install: prev mask 0x1, new mask 0x1
Update response code = 200
Current State: updating -> registered
cvpn_save_state: FGT_1 wan1 172.25.176.56 0 6 0 1 200 1 0x1 0x1
JSON Response: '{"key":"8TVdIwG2xS400jMOxyNN9WKOYWZEsaJDIV8JUGVK2FaHoEVqQPw2qDgt5RLHlZXAuInpCHwl9t8WpZ7jWD+6xg==",
"rev":1,"members":[{"IPv4":"172.25.176.56","port":"500","slot":0,"subnets":["192.168.176.0/255.255.255.0"],"Name":"FGT_1"}]}'
Member table size = 1
Member: { "IPv4": "172.25.176.56", "port": "500", "slot": 0, "subnets": [ "192.168.176.0\/255.255.255.0" ], "Name": "FGT_1" }
Subnet 192.168.176.0/255.255.255.0
cvpn_config_install: prev mask 0x0, new mask 0x1
New members table, revision = 1
Register response code = 200
Current State: registering -> registered
cvpn_save_state: FGT_1 wan1 172.25.176.56 0 6 0 1 200 1 0x1 0x0
Current State: registered -> acknowledging
cvpn_save_state: FGT_1 wan1 172.25.176.56 0 5 6 1 200 1 0x1 0x0
JSON regack request = '{ "SN": "x", "rev": 1 }'
Sending OCVPN request: method=RegAck, data='{ "SN": "x", "rev": 1 }'
Received OCVPN response: method=RegAck, res=0, http_resp=200
JSON Response: '{"message":"Device successfully acknowledged"}'
Message='Device successfully acknowledged'
RegAck response code = 200
Current State: acknowledging -> registered
cvpn_save_state: FGT_1 wan1 172.25.176.56 0 6 6 1 200 1 0x1 0x0
OCVPN Update: sn=x, num_subnets=0
Current State: registered -> updating
cvpn_save_state: FGT_1 wan1 172.25.176.56 0 3 0 1 200 1 0x1 0x0
WAN intf wan1, IP 172.25.176.56/255.255.255.0

Local Subnets:
cvpn_build_json_reg_upd: internal error, line 1187
cvpn_build_json_reg_upd: res = -1
sys_ocvpn_update: res=-1
WAN intf wan1, IP 172.25.176.56/255.255.255.0
OCVPN Update: sn=x, num_subnets=1
Current State: updating
WAN intf wan1, IP 172.25.176.56/255.255.255.0

Local Subnets:

192.168.176.0/255.255.255.0
JSON Update request = '{ "SN": "x", "IPv4": "172.25.176.56", "port": "500", "Name": "FGT_1", "subnets": [ "192.168.176.0\/255.255.255.0" ] }'
Sending OCVPN request: method=Update, data='{ "SN": "IPv4": "172.25.176.56", "port": "500", "Name": "FGT_1", "subnets": [ "192.168.176.0\/255.255.255.0" ] }'
Received OCVPN response: method=Update, res=0, http_resp=200
JSON Response: '{"key":"","rev":1,"members":[{"IPv4":"172.25.176.56","port":"500","slot":0,"subnets":["192.168.176.0/255.255.255.0"],"Name":"FGT_1"}]}'
Member table size = 1
Member: { "IPv4": "172.25.176.56", "port": "500", "slot": 0, "subnets": [ "192.168.176.0\/255.255.255.0" ], "Name": "FGT_1" }
Subnet 192.168.176.0/255.255.255.0
cvpn_config_install: prev mask 0x1, new mask 0x1
Update response code = 200
Current State: updating -> registered
cvpn_save_state: FGT_1 wan1 172.25.176.56 0 6 0 1 200 1 0x1 0x1

To view a list of OCVPN cloud members, use the following command:

FGT_1 # diag vpn ocvpn print-members
Member: { "IPv4": "172.25.176.56", "port": "500", "slot": 0, "subnets": [ "192.168.176.0\/255.255.255.0" ], "Name": "FGT_1" }
Member: { "IPv4": "172.25.177.56", "port": "500", "slot": 1, "subnets": [ "192.168.177.0\/255.255.255.0" ], "Name": "FGT_2" }

1. Configure the Hub FortiGate

Using the CLI, configure phase 1 parameters.

The auto-discovery commands enable the sending and receiving of shortcut messages to spokes (the hub is responsible for lettings the spokes know that they should establish those tunnels).

Note: aggressive mode is not supported currently for ADVPN in 5.6, however support has been implemented starting in version 6.0.1.

config vpn ipsec phase1-interface
    edit "ADVPN"
        set type dynamic
        set interface "wan1"
        set proposal aes128-sha1
        set add-route disable
        set net-device enable
        set dhgrp 2
        set auto-discovery-sender enable
        set psksecret fortinet
    next
end

Configure the phase2 parameters.

This is a standard phase 2 configuration.

config vpn ipsec phase2-interface
    edit "ADVPN-P2"
        set phase1name "ADVPN"
        set proposal aes128-sha1
    next
end

Configure the tunnel interface IP.

ADVPN requires that tunnel IPs be configured on each device connecting to the topology. Those IP addresses need to be unique for each peer. A particularity of the hub is that it needs to define a bogus remote-IP address (10.10.10.254 in our example). This address should be unused in the topology and it will not be actually considered as part of the configuration for the hub.

config system interface
    edit "ADVPN"
        set vdom "root"
        set ip 10.10.10.1 255.255.255.255
        set type tunnel
        set remote-ip 10.10.10.254
        set interface "wan1"
    next
end

 Configure iBGP and route-reflection.

iBGP will be our overlay protocol of choice for enabling ADVPN communications. We are using an arbitrary private AS number (65000) in our example, and configuring a dynamic client group to reduce provisioning requirements.

While we are advertising our LAN network directly (“config network” command), route redistribution is a perfectly valid alternative.

config router bgp
    set as 65000
    set router-id 10.10.10.1
    config neighbor-group
        edit "ADVPN-PEERS"
            set remote-as 65000
            set route-reflector-client enable
            set next-hop-self enable
        next
    end
    config neighbor-range
        edit 0
            set prefix 10.10.10.0 255.255.255.0
            set neighbor-group "ADVPN-PEERS"
        next
    end
    config network
        edit 0
            set prefix 192.168.1.0 255.255.255.0
        next
    end
end

Configure basic policies to allow traffic to flow between the local network and the ADVPN VPN topology. As we generally desire traffic to be allowed between spokes in an ADVPN setup, we must remember to create a policy allowing spoke to spoke communications.

config firewall policy
    edit 0
        set name "OUT ADVPN"
        set srcintf "lan"
        set dstintf "ADVPN"
        set srcaddr "all"
        set dstaddr "all"
        set action accept
        set schedule "always"
        set service "ALL"
        set status enable
    next
    edit 0
        set name "IN ADVPN"
        set srcintf "ADVPN"
        set dstintf "lan"
        set srcaddr "all"
        set dstaddr "all"
        set action accept
        set schedule "always"
        set service "ALL"
        set status enable
    next
    edit 0
        set name "ADVPNtoADVPN"
        set srcintf "ADVPN"
        set dstintf "ADVPN"
        set srcaddr "all"
        set dstaddr "all"
        set action accept
        set schedule "always"
        set service "ALL"
        set status enable
    next
end

2. Configure the Spoke FortiGates

Using the CLI, configure phase 1 parameters.

Note that we are configuring only one of the spokes in this example – the parameters that need to change for each spoke are highlighted in red.

config vpn ipsec phase1-interface
 edit "ADVPN"
  set interface "wan1"
  set proposal aes128-sha1
  set add-route disable
  set dhgrp 2
  set auto-discovery-receiver enable
  set remote-gw 10.1.1.1
  set psksecret fortinet
 next
end

Configure the phase2 parameters.

config vpn ipsec phase2-interface
    edit "ADVPN-P2"
        set phase1name "ADVPN"
        set proposal aes128-sha1
	set auto-negotiate enable
    next
end

 Configure the tunnel interface IP.

Notice that on the spokes, the remote IP is actually used and points to the IP defined on the hub.

config system interface
    edit "ADVPN"
        set vdom "root"
        set ip 10.10.10.2 255.255.255.255
        set type tunnel
        set remote-ip 10.10.10.1
        set interface "wan1"
    next
end

Config iBGP.

This is a static standard configuration and as stated for the hub, redistribution could be used instead of explicit route advertisement.

config router bgp
    set as 65000
    set router-id 10.10.10.2
    config neighbor
        edit "10.10.10.1"
            set soft-reconfiguration enable
            set remote-as 65000
            set next-hop-self enable
        next
    end
    config network
        edit 0
            set prefix 192.168.2.0 255.255.255.0
        next
    end
end

Configure a static route for the tunnel IP subnet.

This is an important special step for the spokes as they need a summary route that identifies all tunnel IP used over your topology to point towards the ADVPN interface. In our example, we use 10.10.10.0/24 (if our network planning expects less than 255 sites). Be sure to adequately plan this IP range as it needs to be hardcoded in the spokes.

config router static
    edit 0
        set dst 10.10.10.0 255.255.255.0
        set device "ADVPN"
    next
end

Configure policies.

config firewall policy
    edit 0
        set name "OUT ADVPN"
        set srcintf "lan"
        set dstintf "ADVPN"
        set srcaddr "all"
        set dstaddr "all"
        set action accept
        set schedule "always"
        set service "ALL"
        set status enable
    next
    edit 0
        set name "IN ADVPN"
        set srcintf "ADVPN"
        set dstintf "lan"
        set srcaddr "all"
        set dstaddr "all"
        set action accept
        set schedule "always"
        set service "ALL"
        set status enable
    next
end

Results

We can validate the behaviour of our configuration using a few commands. We are going to run these commands from SPOKE A.

get router info routing-table bgp will at a minimum display the learned routes from the topology. Note the recursive routing – a result of our spoke’s required static route. In this case, there has not been any traffic between our local subnet (192.168.2.0/24) and the other spoke’s subnet, as the routes are both going through the hub.

B       192.168.1.0/24 [200/0] via 10.0.0.1, ADVPN, 22:30:21
B       192.168.3.0/24 [200/0] via 10.0.0.3 (recursive via 10.0.0.1), 22:30:21

However once we initiate a ping between both spokes, we obtain a different display of routing information – routing now goes through a newly established dynamic tunnel directly through the remote spoke rather than through the hub. The ping hiccup that occurs is the tunnel rerouting through a newly negotiated tunnel to the other spoke.

Our routing information now displays the remote subnet as being available through the spoke directly, through interface ADVPN_0, a dynamically instantiated interface going to that spoke.

FG # exec ping-options source 192.168.2.1

FG # exec ping 192.168.3.1
PING 192.168.3.1 (192.168.3.1): 56 data bytes
64 bytes from 192.168.3.1: icmp_seq=0 ttl=254 time=38.3 ms
64 bytes from 192.168.3.1: icmp_seq=1 ttl=254 time=32.6 ms
Warning: Got ICMP 3 (Destination Unreachable)
64 bytes from 192.168.3.1: icmp_seq=2 ttl=255 time=43.0 ms
64 bytes from 192.168.3.1: icmp_seq=3 ttl=255 time=31.7 ms
64 bytes from 192.168.3.1: icmp_seq=4 ttl=255 time=31.2 ms

--- 192.168.3.1 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max = 31.2/35.3/43.0 ms

FG # get router info routing-table bgp 

B       192.168.1.0/24 [200/0] via 10.0.0.1, ADVPN, 22:34:13
B       192.168.3.0/24 [200/0] via 10.0.0.3, ADVPN_0, 00:02:28

FG # diag vpn tunnel list
list all ipsec tunnel in vd 0
------------------------------------------------------
name=ADVPN_0 ver=1 serial=a 10.1.1.2:0->10.1.1.3:0
bound_if=6 lgwy=static/1 tun=intf/0 mode=dial_inst/3 encap=none/0
 parent=ADVPN index=0
proxyid_num=1 child_num=0 refcnt=19 ilast=3 olast=604 auto-discovery=2
stat: rxp=7 txp=7 rxb=1064 txb=588
dpd: mode=on-demand on=1 idle=20000ms retry=3 count=0 seqno=0
natt: mode=none draft=0 interval=0 remote_port=0
proxyid=ADVPN-P2 proto=0 sa=1 ref=2 serial=1 auto-negotiate adr
  src: 0:0.0.0.0/0.0.0.0:0
  dst: 0:0.0.0.0/0.0.0.0:0
  SA: ref=3 options=2f type=00 soft=0 mtu=1438 expire=42680/0B replaywin=2048 seqno=8 esn=0
  life: type=01 bytes=0/0 timeout=43152/43200
  dec: spi=9a487db3 esp=aes key=16 55e53d9fbc8dbeaa6df1032fbc80c4f6
       ah=sha1 key=20 a1470452c6a444f26a070add087f0d970c18e3a7
  enc: spi=3c37fea7 esp=aes key=16 8fd62a6745a9ba4fda062d4504b76851
       ah=sha1 key=20 44c606f1ef1bf5739ba62f6572031aa956974d0a
  dec:pkts/bytes=7/588, enc:pkts/bytes=7/1064
------------------------------------------------------
name=ADVPN ver=1 serial=9 10.1.1.2:0->10.1.1.1:0
bound_if=6 lgwy=static/1 tun=intf/0 mode=auto/1 encap=none/0
proxyid_num=1 child_num=1 refcnt=22 ilast=8 olast=8 auto-discovery=2
stat: rxp=3120 txp=3120 rxb=399536 txb=191970
dpd: mode=on-demand on=1 idle=20000ms retry=3 count=0 seqno=12
natt: mode=none draft=0 interval=0 remote_port=0
proxyid=ADVPN-P2 proto=0 sa=1 ref=2 serial=1 auto-negotiate adr
  src: 0:0.0.0.0/0.0.0.0:0
  dst: 0:0.0.0.0/0.0.0.0:0
  SA: ref=3 options=2f type=00 soft=0 mtu=1438 expire=4833/0B replaywin=2048 seqno=5ba esn=0
  life: type=01 bytes=0/0 timeout=43148/43200
  dec: spi=9a487db2 esp=aes key=16 4f70d27edad656cfcacbae61b23d4b11
       ah=sha1 key=20 b19ea87c90dd92d1cab58cbf24ae8fe12ee927cb
  enc: spi=b3dde355 esp=aes key=16 efbb4440df75018610b4ba8f5756167d
       ah=sha1 key=20 81cc9cee3bee1c2dba0eb1e7ac66e9d34b67bde9
  dec:pkts/bytes=1465/90152, enc:pkts/bytes=1465/187560
------------------------------------------------------

1. Configuring the tunnel interfaces

To configure Edge to listen for FortiTelemetry traffic over the VPN, connect to Edge, go to Network > Interfaces, and edit the tunnel interface.

Set IP to the local IP address for this interface (10.10.10.1) and Remote IP/Network mask to the IP address for the Branch tunnel interface (10.10.10.2/32).

Under Administrative Access, enable FortiTelemetry.

Connect to Branch, go to Network > Interfaces, and edit the tunnel interface.

Set IP to the local IP address for this interface (10.10.10.2) and Remote IP/Network mask to the IP address for the Edge tunnel interface (10.10.10.1/32).

2. Adding the tunnel interfaces to the VPN

To create an address for the Edge tunnel interface, connect to Edge, go to Policy & Objects > Addresses, and create a new address.

Set Category to Address and set Subnet/IP Range to the IP address for the Edge tunnel interface (10.10.10.1/32).

Create a second address for the Branch tunnel interface. For this address, enable Static Route Configuration.

To allow VPN traffic between the Edge tunnel interface and the Branch tunnel interface, go to VPN > IPsec Tunnels, and edit the VPN tunnel. Select Convert To Custom Tunnel.

Under Phase 2 Selectors, create a new Phase 2. Set Local Address to use a Named Address and select the address for the Edge tunnel interface. Set Remote Address to use a Named Address, and select the address for the Branch tunnel interface.

To route traffic to the Branch tunnel interface, go to Network > Static Routes, and create a new route.

Set Destination to Named Address, and select the address for the Branch tunnel interface. Set Device to the tunnel interface.

To allow traffic between the tunnel interfaces, go to Policy & Objects > IPv4 Policy and edit the policy allowing local VPN traffic.

Set Source to include the Edge tunnel interface and Destination to include the Branch tunnel interface.

On Branch, repeat this step to include the following:

• Addresses for both tunnel interfaces (enable Static Route Configuration for the Branch tunnel interface address)
• A Phase 2 that allows traffic between the Branch tunnel interface and the Edge tunnel interface
• A static route to the Edge tunnel interface
• Edited policies that allow traffic to flow between the tunnel interfaces

To allow the new phase 2 to take effect, go to Monitor > IPsec Monitor, and restart the VPN tunnel.

3. Authorizing Branch for the Security Fabric

You can authorize a FortiGate, FortiAP, or FortiSwitch to join the Security Fabric by using the device’s serial number, rather than sharing the password for the Security Fabric.

To authorize Branch, connect to Edge, and enter the following CLI command:

config system csf
  config trusted-list
    edit <serial_number>
  end
end

To add Branch to the Security Fabric, connect to Branch, and go to Security Fabric > Settings. 

Enable FortiGate Telemetry. Set the Group name. Leave Group password blank. Enable Connect to upstream FortiGate. Set FortiGate IP to the IP address of the Edge tunnel interface.

To verify that Branch is now part of the Security Fabric, connect to Edge, and go to Security Fabric > Settings. Branch appears in the Topology.

4. Allowing Branch to access the FortiAnalyzer

To create an address for the FortiAnalyzer, connect to Branch, go to Policy & Objects > Addresses, and create a new address. Enable Static Route Configuration.

To allow VPN traffic between the FortiAnalyzer and the Branch tunnel interface, go to VPN > IPsec Tunnels, and create a new Phase 2.

To route traffic to the FortiAnalyzer, go to Network > Static Routes, and create a new route.

On Edge, repeat this step to create an address for FortiAnalyzer and a new Phase 2 that allows traffic between the FortiAnalyzer and the Branch tunnel interface. Edge doesn’t require a new static route.

To allow traffic between Branch and the FortiAnalyzer, go to Policy & Objects > IPv4 Policy, and create a new policy.

Set Incoming Interface to the VPN interface, and set Outgoing Interface to the interface that connects to the FortiAnalyzer (in the example, port16). Set Source to the Branch tunnel interface, and set Destination to the FortiAnalyzer.

Enable NAT for this policy.

To authorize the Branch FortiGate on the FortiAnalyzer, connect to the FortiAnalyzer, and go to Device Manager > Unregistered.

Select Branch, then select +Add to register Branch.

5. Results

To view Branch as part of the Security Fabric topology, connect to Edge and go to Security Fabric > Logical Topology. Branch is shown as part of the Security Fabric, connecting over the IPsec VPN tunnel.

6. Desynchronizing Branch from the FortiAnalyzer, FortiSandbox, and FortiManager (optional)

If you don’t want Branch to automatically use the settings that Edge pushes for the FortiAnalyzer, FortiSandbox, and FortiManager, use the following CLI command to configure these settings locally:

config system csf
  set configuration-sync local
end

Go to Security Fabric > Settings. You can now configure the settings for FortiAnalyzer logging, Central Management, and Sandbox Inspection. You can also choose to use local logging rather than sending logs to a FortiAnalyzer.

This option is available for all FortiGate devices in the Security Fabric, except for the root FortiGate.

1. Configuring the IPsec VPN on HQ

To create a new IPsec VPN tunnel, connect to HQ, go to VPN > IPsec Wizard, and create a new tunnel.

In the VPN Setup step, set Template Type to Site to Site, set Remote Device Type to FortiGate, and set NAT Configuration to No NAT between sites.

In the Authentication step, set IP Address to the public IP address of the Branch FortiGate (in the example, 172.25.177.46).

After you enter the IP address, the wizard automatically assigns an interface as the Outgoing Interface. If you want to use a different interface, select it from the drop-down menu.

Set a secure Pre-shared Key.

In the Policy & Routing step, set Local Interface to lan. The wizard adds the local subnet automatically. Set Remote Subnets to the Branch network’s subnet (in the example, 192.168.13.0/24).

Set Internet Access to None.

A summary page shows the configuration created by the wizard, including interfaces, firewall addresses, routes, and policies.

To view the VPN interface created by the wizard, go to Network > Interfaces.

To view the firewall addresses created by the wizard, go to Policy & Objects > Addresses.

To view the routes created by the wizard, go to Network > Static Routes.

To view the policies created by the wizard, go to Policy & Objects > IPv4 Policy.

2. Configuring the IPsec VPN on Branch

To create a new IPsec VPN tunnel, connect to Branch, go to VPN > IPsec Wizard, and create a new tunnel.

In the VPN Setup step, set Template Type to Site to Site, set Remote Device Type to FortiGate, and set NAT Configuration to No NAT between sites.

In the Authentication step, set IP Address to the public IP address of the HQ FortiGate (in the example, 172.25.176.62).

After you enter the IP address, the wizard automatically assigns an interface as the Outgoing Interface. If you want to use a different interface, select it from the drop-down menu.

Set the secure Pre-shared Key that was used for the VPN on HQ.

In the Policy & Routing step, set Local Interface to lan. The wizard adds the local subnet automatically. Set Remote Subnets to the HQ network’s subnet (in the example, 192.168.65.0/24).

Set Internet Access to None.

A summary page shows the configuration created by the wizard, including interfaces, firewall addresses, routes, and policies.

To bring the VPN tunnel up, go to Monitor > IPsec Monitor. Right-click under Status and select Bring Up.

3. Results

Users on the HQ internal network can access resources on the Branch internal network and vice versa.

To test the connection, ping HQ’s LAN interface from a device on the Branch internal network.