1. Registering and downloading your license

FortiGate-VM for Microsoft Azure supports both bring-your-own-license (BYOL) and on-demand (PAYG) licensing models. If you’re deploying a FortiGate-VM in the Microsoft Azure marketplace with BYOL, you must obtain a license to activate it. 

Licenses can be obtained through any Fortinet partner. If you don’t have a partner, contact azure@fortinet.com for assistance in purchasing a license.

After you purchase a license or obtain an evaluation license (60-day term), you will receive a PDF with an activation code. 

Go to Asset > Register/Renew to start the registration process.

In the Specify Registration Code field, enter your license activation code and select Next to continue registering the product. Fill in the other fields with your information.

At the end of the registration process, download the license (.lic) file for your FortiGate-VM.

After registering a license, Fortinet servers may take up to 30 minutes to fully recognize the new license. When you upload the license (.lic) file to activate the FortiGate-VM (in step 5), if you get an error that the license is invalid, wait 30 minutes and try again.

2. Creating a Microsoft Azure VNet

This section shows you how to create a Microsoft Azure VNet and create two subnets in it. For many of the steps, you will have a choice to make that can be specific to your own environment. 

Log in to the Microsoft Azure Portal and select + New. 

Search for and select Virtual network from the search results.

Under Select a deployment model, ensure that Resource Manager is selected. Select Create.

Set a Name for your VNet.

Select an Address space for your VNet. This is the range of IP addresses available within your VNet. It’s possible to extend this later.

Set Subnet name to Subnet1.

Set the Subnet address range. This must be a subset of your VNet address range and you must leave room for a second subnet.

Choose a Subscription.

Either create a new Resource group or select an existing one.

Set a Location. This is the region of the world where your VNet will reside. In the next steps, when we deploy virtual machines, they must exist within the same location.

Select Create.

Browse to your new virtual network and select it.

There are a number of ways to do this. The simplest is to select Virtual networks on the left bar. If you don’t see text there, select the three horizontal lines near the top left of the Microsoft Azure portal to expand the left tool bar.

Under SETTINGS, select Subnets. Select + Subnet.

Set Subnet name to Subnet2.

Select an address space for the subnet from the available range or ranges in your VNet.

Leave Network security group and Route table set to None.

Select OK.

3. Installing the FortiGate-VM in the VNet 

In the Microsoft Azure Dashboard, select + New and search for FortiGate.

Select the option FortiGate NGFW Single VM and select Create.

In the Basics section, set a FortiGate-VM Name.

Select the PAYG/BYOL License option that corresponds to the license type that you purchased.

Set a FortiGate administrative username. This name can’t be admin or root. An account named admin will also be created that has a randomly generated password. After the installation, you should change the password of the admin account. 

Choose a FortiGate Password for the new account and confirm the password. This must be a complex password containing three of the following types of characters: numbers, capital letters, lowercase letters, and special characters. For security reasons, it’s not possible to reset this password through the Microsoft Azure portal, so make sure that you remember the password.

Select the appropriate Subscription from the drop-down list. You may have only one option here.

Create a new Resource group. Currently, it’s not possible to select an existing resource group for a Microsoft Azure Marketplace template set.

Set the same Location as you did when you created the VNet in the previous section.

Select OK.

In the Network Settings and Instance section, select Virtual network, then select the VNet that you created in the previous step.

Select Configure subnets.

Set Outside Subnet to Subnet1. This will be the subnet on which the WAN port resides.

Set Internal Subnet to Subnet2. This will be the subnet on which the protected port resides.

Select OK.

Select the Virtual machine size of the FortiGate from the Recommended choices, or select View all to get additional options. Select OK.

In the FortiGate IP Address Assignments section, set a resource name for the new public IP address. Choose between a Dynamic or Static public IP. A static IP may have associated costs, while a dynamic public IP may be replaced if your FortiGate reboots.

Select OK.

Wait for Validation to pass, then select OK.

Select Purchase to buy the FortiGate-VM instance from Microsoft Azure. 

Once the FortiGate-VM is deployed, you will see a “Deployment succeeded” message.

4. Associating the route tables with the subnets

You must associate both Subnet1 and Subnet2 to their corresponding Route tables (in this example, FortiGate-Subnet1-routes and FortiGate-Subnet2-routes).

You must associate the route table to a subnet.

Under Settings, select Subnets.

Select + Associate.

Select your second subnet (in this example, Subnet2). Select OK.

Wait about 30 seconds for the route table to be associated with the subnet.

5. Connecting to the FortiGate-VM

To connect to the FortiGate-VM, you must find its public IP address. There are a number of ways to do this. One way is to select Virtual machines on the left bar and then select the FortiGate-VM you created. Under Essentials, you will see the FortiGate-VM’s public IP address in the Public IP address field. 

Connect to the FortiGate using your browser and the FortiGate-VM’s IP address. You will see a certificate error message from your browser, which is normal because the default FortiGate certificate is self-signed and isn’t recognized by browsers. Proceed past this error. At a later time, you can upload a publicly-signed certificate to avoid this error. 

Log in to the FortiGate-VM with the FortiGate Administrative Username and FortiGate Password that you configured above. 

If you’re using a BYOL license, upload your license (.lic) file to activate the FortiGate-VM. Restart the FortiGate-VM and log in again.

After you log in, you will see that the license has been uploaded. You need to wait for authentication with the registration servers. This can take up to 15 minutes.

Select Return.

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.

WAN destination bubbles

• Shows traffic to interfaces that have the WAN role
• Does not require device detection on the interface

LAN device bubbles

• Shows any device detected on any FortiGate interfaces, regardless of interface role
• Requires device detection on the interfaces

1. Acquiring the MAC address

Acquire the MAC address of a particular device as follows:

• Windows device:
  Open the command prompt and type ipconfig /all.
  The MAC address of your Windows device is the Physical Address, under information about the wireless adapter.
• Mac OS X device:
  Open Terminal and type ifconfig en1 | grep ether.
  Take note of the displayed MAC address.
  
• iOS device:
  Open Settings > General > About.
  The Wi-Fi Address  is the MAC address of your iOS device.
  
• Android device:
  Open Settings > About Device > Status.
  Take note of the Wi-Fi MAC address of your Android device.

2. Creating the FortiAP interface

Go to Network > Interfaces and create an internal FortiAP interface.

Set Addressing Mode to Manual and set an IP/Network Mask.

Under Administrative Access, enable CAPWAP.

Enable DHCP Server and set the Starting IP and End IP.

Enable Device Detection and click OK.

3. Defining a device using its MAC address

Go to User & Device > Custom Devices & Groups and create a new device definition.

Set MAC Address to the device’s address obtained in Step 1 and set the other fields as required.

4. Creating the new SSID

Go to WiFi & Switch Controller > SSID and create a new SSID.

Set Traffic Mode to Tunnel.

Select an IP/Network Mask for the wireless interface and enable DHCP Server.

Enable Device Detection.

Under WiFi Settings, name the SSID (in the example, MySecureWiFi).

Set the Security Mode as required and enter a secure Pre-shared Key.

Enable Broadcast SSID.

Under Filter clients by MAC Address, enable Local and select Add from device list.

Add the device you configured in Step 3 and set its Action to Accept. Set the Action for Unknown MAC Addresses to Deny.

If you haven’t already, connect the FortiAP unit to the interface created in Step 2.

5. Managing the FortiAP

Go to WiFi & Switch Controller > Managed FortiAPs.

If the FortiAP is not listed you may need to wait a few minutes. If the device still does not appear, select Create New > Managed AP.

Once you enter the Serial Number, the default FortiAP Profile for that model is selected. Click OK.

6. Authorizing the managed FortiAP

7. Editing the default FortiAP Profile

Go to WiFi & Switch Controller > FortiAP Profiles and Edit the default profile for your particular FortiAP model.

For all radios you wish to use, set the SSID to Manual and select the SSID created in Step 4.

8. Allowing wireless access to the Internet

Go to Policy & Objects > IPv4 Policy and create a new policy.

Set Incoming Interface to the SSID and Outgoing Interface to your Internet-facing interface.

Enable NAT.

9. Results

Using the authorized device, connect to the broadcast SSID (in the example, MySecureWifi).

Go to Log & Report > WiFi Events and verify the authorized connection.

1. Determining your licensing model

FortiGate-VM for AWS supports both on-demand (PAYG) and bring-your-own-license (BYOL) licensing models.

On-demand users don’t need to register from the FortiGate GUI console. If you’re using an on-demand licensing model, once you create the FortiGate-VM instance in AWS, contact Fortinet Customer Support (http://www.fortinet.com/support/contact_support.html) with the following information:

• The serial number of your FortiGate-VM instance
• The email ID of your Fortinet account. If you don’t have a Fortinet account, you can create one at https://support.fortinet.com/login/CreateAccount.aspx.

If you’re deploying a FortiGate-VM in the AWS Marketplace with BYOL, you must obtain a license to activate it.

2. Registering and downloading your license (BYOL)

Licenses for the BYOL licensing model can be obtained through any Fortinet partner. If you don’t have a partner, contact aws@fortinet.com for assistance in purchasing a license.

After you purchase a license or obtain an evaluation license (60-day term), you will receive a PDF with an activation code.

Go to https://support.fortinet.com/ and either create a new account or log in with an existing account.

Go to Asset > Register/Renew to start the registration process.

In the Specify Registration Code field, enter your license activation code and select Next to continue registering the product. Enter your details in the other fields.

At the end of the registration process, download the license (.lic) file to your computer. You will upload this license later (in step 6) to activate the FortiGate-VM.

After registering a license, Fortinet servers may take up to 30 minutes to fully recognize the new license. When you upload the license (.lic) file to activate the FortiGate-VM, if you get an error that the license is invalid, wait 30 minutes and try again.

3. Creating an AWS VPC

This section shows you how to create an AWS VPC and create two subnets in it. For many of the steps, you will have a choice to make that can be specific to your own environment.

Log in to the AWS Management Console.

In the Networking & Content Delivery section, select VPC.

In the Virtual Private Cloud menu, select Your VPCs, then select Create VPC.

In the Name tag field, set a name for your VPC.

In the CIDR block field, specify an IPv4 address range for your VPC.

In the Tenancy field, select Default.

Select Yes, Create.

In the Virtual Private Cloud menu, select Subnets, then select Create Subnet. Create a public subnet (in this example, Subnet1) and a private subnet (Subnet2), as shown in this example.

Both subnets belong to the VPC that you created.

4. Connect the new VPC to the Internet gateway

This section shows you how to connect the new VPC to the Internet gateway. Note that if you’re using the default VPC, the Internet gateway should already exist.

In the Virtual Private Cloud menu, select Internet Gateways, then select Create Internet Gateway.

In the Name tag field, set a name for the Internet gateway, then select Yes, Create.

Select the Internet gateway, then select Attach to VPC.

Select the VPC that you created and select Yes, Attach.

The state of the Internet gateway will change from detached to attached.

5.   Subscribing to the FortiGate-VM

This section shows you how to subscribe to and configure the FortiGate-VM. 

In the Network field, select the VPC that you created.

In the Subnet field, select the public subnet.

In the Network interfaces section, you will see the entry for eth0 that was created for the public subnet. Select Add Device to add another network interface (in this example, eth1), and select the private subnet. It is recommended that you assign static IP addresses.

When you have two network interfaces, a global IP address isn’t assigned automatically. You must manually assign a global IP address later.

Select Review and Launch, then select Launch.

To easily identify the instance, set a name for it in the Name field.

In the Network & Security menu, select Elastic IPs, then select a global IP address that is available for you to use. Select Actions > Associate Address.

If you don’t have a global IP address available to use, create one.

In the Resource type section, select Network Interface. 

In the Network interface field, select the Interface ID of the network interface that you created for the public subnet (in this example, eth0). In the Private IP field, select the IP address that belongs to the public subnet. To find these values, go to the EC2 Management Console, select Instances, and select the interface in the Network interfaces section in the lower pane of the page (Interface ID and Private IP Address fields). Select Associate.

A message is displayed indicating the address association was successful. Note that if the Internet Gateway isn’t associated with a VPC, the elastic IP assignment will fail.

Next, configure the routing tables. Since the FortiGate has two interfaces, one for the public subnet and one for the private subnet, you must configure two routing tables.

To configure the routing table for the public subnet, select VPC in the Networking & Content Delivery section of the AWS Management Console. In the VPC Dashboard, select Your VPCs, and select the VPC you created. In the Summary tab in the lower pane, select the route table ID located in the Route table field. To easily identify the route table, set a name for it in the Name field.

In the Routes tab, select Edit, then select Add another route. In the Destination field, type 0.0.0.0/0. In the Target field, type ig and select the Internet Gateway from the auto-complete suggestions. Select Save. 

The default route on the public interface in this VPC is now the Internet Gateway.

In the Subnet Associations tab, select Edit, and select the public subnet to associate it with this routing table. Select Save.

To configure the routing table for the private subnet, select Create Route Table. To easily identify the route table, set a name for it in the Name field. Select the VPC you created. Select Yes, Create.

In the Routes tab, select Edit, then select Add another route. In the Destination field, type 0.0.0.0/0. In the Target field, enter the interface ID of the private network interface. To find the interface ID, go to the EC2 Management Console, select Instances, and select the interface in the Network interfaces section in the lower pane of the page (Interface ID field). Select Save.

The default route on the private subnet in this VPC is now the private network interface of the FortiGate.

In the Subnet Associations tab, select Edit, select the private subnet to associate it with this routing table. Select Save.

Two routing tables, one for the public segment and one for the private segment, have now been created with default routes.

In the EC2 Management Console, select Instances, and select the network interface that you created for the private subnet (in this example, eth1) in the Network interfaces section in the lower pane. Select the interface ID.

Select the network interface, select the Actions drop-down menu, select Change Source/Dest. Check. Select Disabled. Select Save.

6. Connecting to the FortiGate-VM  

To connect to the FortiGate-VM, you need your login credentials and its public DNS address.

The default username is admin and the default password is the instance ID.

You can find the public DNS address in the EC2 Management Console. Select Instances and look at the Public DNS (IPv4) field in the lower pane. If you don’t see the DNS address, you may need to enable DNS host assignment on your VPC. In this case, go back to the VPC Management Console, select Your VPCs, and select your VPC. Select the Action drop-down menu, and select Edit DNS Hostnames. Select Yes. Select Save.

Open an HTTPS session using the public DNS address of the FortiGate-VM.

Use your credentials to log in to the FortiGate-VM.

If you’re using a BYOL license, upload your license (.lic) file to activate the FortiGate-VM. 

The FortiGate-VM will automatically restart. After it restarts, log in again.

You will now see the FortiGate-VM dashboard.

Depending on your license type, the information in the license widget on the dashboard may vary.

7. Setting up the Windows server

In the AWS Management Console, select EC2. Select Launch Instance, then select the Microsoft Windows Server 2012 R2 that applies to your environment.

You will use this to test connectivity with Remote Desktop access.

In the Configure Security Group step, configure a security group for the Windows server so that it allows Internet access. In this example, we use Remote Desktop TCP port 3389, and other ports are optional. Select Review and Launch.

8. Configuring FortiGate firewall policies

In the FortiGate-VM console, select Policy & Objects > IPv4 Policy and create two new policies, as shown in this example. 

Create one policy for outgoing traffic from the private subnet, through the public subnet, to the Internet. Create another policy for incoming traffic from the Internet, through the public subnet, to the private subnet.

9. Results

Open a web browser and try to access the following site: metal.fortiguard.com/tests

Scroll down the page and select one of the test virus files that are listed as infected.

You should see a blocked page alert because your Internet access is now protected by FortiGate.

1. Configuring rogue scanning

On the FortiGate, go to WiFi & Switch Controller > WIDS Profiles and edit the default profile.

Enable Rogue AP Detection as shown.

2. Monitoring rogue APs

Go to Monitor > Rogue AP Monitor and view the table of APs found during scanning.

You can identify interfering APs in the Signal Interference column, indicated by the  icon.

3. Suppressing rogue APs

To suppress a rogue AP, you must first mark the AP as rogue.

Right-click the desired entry and select Mark as rogue.

4. Reverting a suppressed AP 

To revert a suppressed AP, highlight its entry and select Unsuppress AP as shown.

The AP will remain identified as rogue.

5. Exempting an AP from rogue scanning

Go to WiFi & Switch Controller > FortiAP Profiles and select the desired FortiAP Profile.

Enable WIDS Profile, select the profile you just created, and click OK.

 AP is detected but not yet classified.
AP is accepted. 
AP is marked as rogue, but unsuppressed. 
AP is marked as rogue and suppressed.

 AP is online and active.
 AP is inactive.

 AP signal interferes with a managed AP.  

 
AP signal interference ranges from low (green) to high (red), measured in dBm.

 AP is a suspected rogue. 
 AP is not a suspected rogue. 

1. Creating the VLAN interfaces

Go to Network > Interfaces and select Create New > Interface.

Create the VLAN interface for VLAN ID 10 and enable the DHCP server option.

2. Creating the zone

Under Network > Interfaces, select Create New > Zone, name the zone LAN Zone, and add the newly created VLANs to the zone.

Leave Block intra-zone traffic enabled to prevent communication between the VLAN interfaces.

3. Creating a firewall policy for the zone

Navigate to Policy & Objects > IPv4 Policy and create a firewall policy allowing any VLAN in the “LAN Zone” permission to access the Internet.

Select any security profiles desired with best practices and business requirements in mind.

Results

Users from VLAN10, VLAN20, or VLAN30 will now have Internet access.

As new VLANs are added in the future, they can be added to “LAN Zone” without having to modify the firewall policy we created in Step 3.

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.

Set the Authentication Method to Pre-shared Key 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.

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

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

Set the Authentication Method to Pre-shared Key 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. Setting the system inspection mode

2. Testing FortiSandbox connectivity

On the FortiGate, go to Security Fabric > Settings and enable Sandbox Inspection.

Select your FortiSandbox type and Server address.

Confirm that the service is available by selecting Test connectivity.

The Status should read “Service is online.”

3. Enabling Content Disarm and Reconstruction

Go to Security Profiles > AntiVirus.

Under APT Protection Options, enable Content Disarm and Reconstruction and select the Original File Destination.

If you enable FortiSandbox as the file destination, original files caught by the AntiVirus profile are archived on the FortiSandbox. The FortiSandbox administrator can retrieve the original files, but only for a short time.

If you enable either File Quarantine or Discard as the file destination, original files caught by the AntiVirus profile are lost. Only the disarmed content is made available.

4. Configuring the Internet access policy

Go to Policy & Objects > IPv4 Policy and Edit the Internet access policy.

Under Security Profiles, enable the default AntiVirus profile. Proxy Options and SSL Inspection are automatically enabled.

5. Results

As the AntiVirus profile scans files using CDR, it replaces content that is deemed malicious or unsafe with content that will allow the traffic to continue but not put the recipient at risk.

If you wish to disable the cover page, enter the following commands in the CLI Console:

config antivirus profile
  edit default
    config content-disarm
      set cover-page disable
  end
end

6. Troubleshooting

The feature is not visible in the GUI

Confirm that the Inspection Mode is set to Proxy under System > Settings.

Also check that the AntiVirus profile inspection mode is set to proxy using the CLI Console:

config antivirus profile
  edit default
    set inspection-mode proxy
  next
end

Error messages and/or conflicts

If you receive an error message when attempting to enable Content Disarm and Reconstruction on the AntiVirus profile, check the Proxy Options settings in the CLI Console and disable splice and clientcomfort on CDR-supported protocols:

config firewall profile-protocol-options
  edit default
    config smtp
      unset options splice
    next
    config http
      unset options clientcomfort
    next
  end
end

You should also confirm the AntiVirus profile’s protocol settings under config antivirus profile:

• ensure that set options scan is enabled on CDR-supported protocols
• if set options av-monitor is configured on a CDR-supported protocol , it overrides the config content-disarm detect-only setting (and CDR will not occur)

The FortiSandbox service is unreachable

If testing the FortiSandbox connectivity returns a “Service is unreachable” error message, then you may need to authorize the FortiGate on the FortiSandbox.

On the FortiSandbox, go to Scan Input > Device and edit the entry for the FortiGate.

Under Permissions & Policy, enable Authorized.

1. Feature visibility

If DNS Filter is not listed under Security Profiles, go to System > Feature Visibility, and enable DNS Filter under Security Features.

2. Creating a DNS web filter profile

Go to Security Profiles > DNS Filter, and edit the default profile.

Enable FortiGuard category based filter, right-click Bandwidth Consuming, and set it to Block.

3. Enabling DNS filtering in a security policy

All traffic that matches this policy will be redirected to the FortiDNS server.

Go to Policy & Objects > IPv4 Policy, and edit the outgoing policy that allows Internet access.

Under Security Profiles, enable DNS Filter and set it to default.

Proxy Options and SSL Inspection profiles are automatically enabled.

4. Results

Open a browser using a computer on the internal network and navigate to dailymotion.co.uk. The page will be blocked.

Enter the following CLI command to sniff packets with a destination URL that does not belong to the bandwidth consuming category:

diagnose sniffer packet any 'port 53' and 'host 194.153.110.160' 4

The resulting output should indicate that the IP (in this example, paris.fr) was allowed by FortiGuard:

interfaces=[any]
filters=[port 53]
2.851628 172.20.121.56.59046 -> 208.91.112.52.53: udp 43
2.916281 208.91.112.52.53 -> 172.20.121.56.59046: udp 436
3.336945 10.1.2.102.51755 -> 208.91.112.53.53: udp 37
3.338611 208.91.112.53.53 -> 10.1.2.102.51755: udp 37

5. (Optional) Changing the FortiDNS server and port

You can use the default FortiDNS server located in Sunnyvale, USA (IP address 208.91.112.220), or you can switch to the server in London, UK (IP address 80.85.69.54).

Communication between your FortiGate and the FortiDNS server uses Fortinet’s proprietary DNS communication protocol.

config system fortiguard
   set sdns-server-ip 208.91.112.220
end

The North American server should work in most cases, however you can switch to the European server to see if it improves latency.

You can also change the port used to communicate with the FortiDNS server using the following command:

config system fortiguard
   set sdns-server-port <value>
end

6. Troubleshooting

The Security Profiles > DNS Filter menu is missing

Go to System > Feature Visibility and enable DNS Filter.

You configured DNS Filtering, but it is not working

Verify that DNS Filter is enabled in a policy and SSL Inspection has been applied as needed (SSL inspection is required in order to block traffic to sites that use HTTPS).

If both settings are enabled, verify that the policy is being used for the correct traffic and that traffic is flowing by going to the policy list and viewing the Sessions column. 

If the above settings are correct, verify that DNS requests are going through the policy, rather than to an internal DNS server. Also verify that proxy options and SSL/SSH inspection settings have both HTTP and HTTPS enabled and use the correct ports.

Communication with the FortiDNS server fails

Verify that the correct FortiDNS server is configured using the following diagnose command:

diag test application dnsproxy 3

The resulting output should indicate that communication with the correct FortiDNS server was established. For example:

FWF60D4615016384 # diag test application dnsproxy 3
vdom: root, index=0, is master, vdom dns is enabled, mip-169.254.0.1 dns_log=1
dns64 is disabled
dns-server:208.91.112.53:53 tz=0 req=919160 to=545900 res=117880 rt=1800 secure=0 ready=1 
dns-server:208.91.112.52:53 tz=0 req=913029 to=520111 res=134810 rt=6 secure=0 ready=1 
dns-server:208.91.112.220:53 tz=-480 req=0 to=0 res=0 rt=0 secure=1 ready=1
dns-server:80.85.69.54:53 tz=0 req=0 to=0 res=0 rt=0 secure=1 ready=1
vfid=0, interface=wan1, ifindex=6, recursive, dns
DNS_CACHE: hash-size=2048, ttl=1800, min-ttl=60, max-num=5000
DNS FD: udp_s=12 udp_c=14:15 ha_c=18 unix_s=19, unix_nb_s=20, unix_nc_s=21, v6_udp_s=11, v6_udp_c=16:17
DNS FD: tcp_s=24, tcp_s6=23
FQDN: hash_size=1024, current_query=1024
DNS_DB: response_buf_sz=131072
LICENSE: expiry=2016-08-15, expired=0, type=2
FDG_SERVER:208.91.112.220:53
SERVER_LDB: gid=6d61, tz=-480
FGD_REDIR:208.91.112.55 

This CLI result shows that the DNS server IP is set to the North American server, and is being accessed through port 53 (208.91.112.220:53).

Next, verify that bandwidth consuming sites are blocked, while other URLs are allowed.

Go to the CLI Console and enter the following:

diagnose sniffer packet any 'port 53' and 'host 195.8.215.138' 4

The resulting output should indicate that the IP (in this example, dailymotion.co.uk) was blocked by the FortiDNS server:

interfaces=[any]
filters=[port 53]
2.026733 172.20.121.56.59046 -> 208.91.112.220.53: udp 117
2.027316 172.20.121.56.59046 -> 80.85.69.54.53: udp 112
2.028480 172.20.121.56.59046 -> 208.91.112.220.53: udp 116
2.029591 172.20.121.56.59046 -> 208.91.112.220.53: udp 117

FortiGuard has the wrong categorization for a website

If you believe a website has been placed in the wrong category by FortiGuard, you can submit the URL for re-classification by going to the FortiGuard website.

1. Configuring the primary FortiGate

Connect to the primary FortiGate, click on the System Information dashboard widget and select Configure settings in System > Settings.

Change the Host name to identify this FortiGate as the primary FortiGate.

You can also enter this CLI command:

config system global
  set hostname Primary
end

Enter this CLI command to set the HA mode to active-passive, set a group id, group name and password, increase the device priority to a higher value (for example, 250) and enable override.

config system ha
  set mode a-p
  set group-id 100
  set group-name My-cluster
  set password <password>
  set priority 250
  set override enable
  set hbdev lan4 200 lan5 100
end

Enabling override and increasing the device priority means this FortiGate always becomes the primary unit.

This configuration also selects lan4 and lan5 to be the heartbeat interfaces and sets their priorities to 200 and 100 respectively. Its a best practice to set different priorities for the heartbeat interfaces (but not a requirement).

If you have more than one cluster on the same network, each cluster should have a different group id. Changing the group id changes the cluster interface virtual MAC addresses. If your group id causes a MAC address conflict on your network, you can select a different group id.

You can also configure most of these settings from the GUI (go to System > HA).

config system ha
  set group-id 100
  set override enable
end

After you enter the CLI command or make the GUI changes, the FortiGate negotiates to establish an HA cluster. You may temporarily lose connectivity with the FortiGate as FGCP negotiation takes place and the MAC addresses of the FortiGate interfaces are changed to HA virtual MAC addresses.

To reconnect sooner, you can update the ARP table of your management PC by deleting the ARP table entry for the FortiGate unit (or just deleting all ARP table entries). You can usually delete the ARP table from a command prompt using a command similar to arp -d.

The FGCP uses virtual MAC addresses for failover. The virtual MAC address assigned to each FortiGate interface depends on the HA group ID. A group ID of 100 sets FortiGate interfaces to the following MAC addresses: 00:09:0f:09:64:00, 00:09:0f:09:64:01, 00:09:0f:09:64:02 and so on. For details, see Cluster virtual MAC addresses.

You can verify that the FGCP has set the virtual MAC addresses by viewing the configuration of each FortiGate interface from the GUI (go to Network > Interfaces) or by entering the following CLI command (shown below for lan2 on a FortiGate-51E):

get hardware nic lan2
... 
Current_HWaddr 00:09:0f:09:64:01 
Permanent_HWaddr 70:4c:a5:98:11:54
... 

You can also use the diagnose hardware deviceinfo nic lan2 command to display this information.

The output shows the current hardware (MAC) address (the virtual MAC set by the FGCP) and the permanent hardware (MAC) address for the interface.

2. Configuring the backup FortiGate

If required, change the firmware running on the new FortiGate to be the same version as is running on the primary FortiGate.

Enter the following command to reset the new backup FortiGate to factory default settings.

execute factoryreset

You can skip this step if the new FortiGate is fresh from the factory. But if its configuration has been changed at all, it’s a best practice to reset your FortiGate to factory defaults to reduce the chance of synchronization problems.

Register and apply licenses to the backup FortiGate before configuring it for HA operation. This includes licensing for FortiCare Support, IPS, AntiVirus, Web Filtering, Mobile Malware, FortiClient, FortiCloud, Security Rating, Outbreak Prevention, and additional virtual domains (VDOMs). All FortiGates in the cluster must have the same level of licensing for FortiGuard, FortiCloud, FortiClient, and VDOMs. FortiToken licenses can be added at any time because they are synchronized to all cluster members.

Click on the System Information dashboard widget and select Configure settings in System > Settings. Change the FortiGate’s Host name to identify it as the backup FortiGate.

config system global
  set hostname Backup
end

Duplicate the primary unit HA settings, except set the Device Priority to a lower value (for example, 50) and do not enable override.

config system ha
  set mode a-p
  set group-id 100
  set group-name My-cluster
  set password <password>
  set priority 50
  set hbdev lan4 200 lan5 100
end

Similar to when configuring the primary FortiGate, once you enter the CLI command the backup FortiGate negotiates to establish an HA cluster. You may temporarily lose connectivity with the FortiGate as FGCP negotiation takes place and the MAC addresses of the FortiGate interfaces are changed to HA virtual MAC addresses.

If the group ID is the same, the backup FortiGate interfaces get the same virtual MAC addresses as the primary FortiGate. You can check Network > Interfaces on the GUI or use the get hardware nic command to verify.

3. Connecting the primary and backup FortiGates

Connect the primary and backup FortiGates together and to your network as shown in the network diagram at the start of the recipe. Making these connections disrupts network traffic as you disconnect and re-connect cables.

Switches must be used between the cluster and the Internet and between the cluster and the internal network as shown in the network diagram. You can use any good quality switches to make these connections. You can also use one switch for all of these connections as long as you configure the switch to separate traffic from the different networks.

The example shows the recommended configuration of direct connections between the lan4 heartbeat interfaces and between the lan5 heartbeat interfaces.

When the heartbeat interfaces are connected, the FortiGates find each other and negotiate to form a cluster. The primary FortiGate synchronizes its configuration to the backup FortiGate. The cluster forms automatically with minimal or no additional disruption to network traffic.

The cluster will have the same IP addresses as the primary FortiGate had. You can log into the cluster by logging into the primary FortiGate CLI or GUI using one of the original IP addresses of the primary FortiGate.

4. Checking cluster operation

Check the cluster synchronization status to make sure the primary and backup FortiGates both have the same configuration. Log into the primary FortiGate CLI and enter this command:

diagnose sys ha checksum cluster

The command output lists all cluster members’ configuration checksums. If both cluster members have identical checksums you can be sure that their configurations are synchronized. If the checksums are different, wait a short while and enter the command again. Repeat until the checksums are identical. It may take a while for some parts of the configuration to be synchronized. If the checksums never become identical you can use the information in Synchronizing the configuration to troubleshoot the problem or visit the Fortinet Support website for assistance.

The HA Status dashboard widget also shows synchronization status. Mouse over the host names of each FortiGate in the widget to verify that they are synchronized and both have the same checksum.

To view more information about the cluster status, click on the HA Status widget and select Configure Settings in System > HA (or go to System > HA).

5. Disabling override (recommended)

When the checksums are identical, disable override on the primary FortiGate by entering the following command:

config system ha
   set override disable
end

FGCP clusters dynamically respond to network conditions. If you keep override enabled, the same FortiGate always becomes the primary FortiGate. With override enabled; however, the cluster may negotiate more often to keep the same FortiGate as the primary FortiGate, potentially increasing traffic disruptions.

If you disable override it is more likely that the backup FortiGate could become the primary FortiGate. Disabling override is recommended unless its important that the same FortiGate remains the primary FortiGate.

6. Results

To test this, ping a reliable IP address from a PC on the internal network. After a moment, power off the primary FortiGate. You will see a momentary pause in the ping results, until traffic diverts to the backup FortiGate, allowing the ping traffic to continue.

64 bytes from 184.25.76.114: icmp_seq=69 ttl=52 time=8.719 ms\
64 bytes from 184.25.76.114: icmp_seq=70 ttl=52 time=8.822 ms\
64 bytes from 184.25.76.114: icmp_seq=71 ttl=52 time=9.034 ms\
64 bytes from 184.25.76.114: icmp_seq=72 ttl=52 time=9.536 ms\
64 bytes from 184.25.76.114: icmp_seq=73 ttl=52 time=8.877 ms\
64 bytes from 184.25.76.114: icmp_seq=74 ttl=52 time=8.901 ms\
Request timeout for icmp_seq 75\
64 bytes from 184.25.76.114: icmp_seq=76 ttl=52 time=8.860 ms\
64 bytes from 184.25.76.114: icmp_seq=77 ttl=52 time=9.174 ms\
64 bytes from 184.25.76.114: icmp_seq=78 ttl=52 time=10.108 ms\
64 bytes from 184.25.76.114: icmp_seq=79 ttl=52 time=8.719 ms\
64 bytes from 184.25.76.114: icmp_seq=80 ttl=52 time=10.861 ms\
64 bytes from 184.25.76.114: icmp_seq=81 ttl=52 time=10.757 ms\
64 bytes from 184.25.76.114: icmp_seq=82 ttl=52 time=8.158 ms\
64 bytes from 184.25.76.114: icmp_seq=83 ttl=52 time=8.639 ms}

You can log into the cluster GUI or CLI using the same IP address as you had been using to the log into the primary FortiGate. If the primary FortiGate is powered off you will be logging into the backup FortiGate. Check the host name to verify the FortiGate that you have logged into. The FortiGate continues to operate in HA mode and if you restart the primary FortiGate, after a few minutes it should rejoin the cluster and operate as the backup FortiGate. Traffic should not be disrupted when the restarted primary unit rejoins the cluster.

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