FortiOS 5.4 Cookbook PDF
FortiOS 5.4 Cookbook PDF
Version 5.4
FORTINET DOCUMENT LIBRARY
https://docs.fortinet.com
FORTINET BLOG
https://blog.fortinet.com
NSE INSTITUTE
https://training.fortinet.com
FORTIGUARD CENTER
https://fortiguard.com/
FEEDBACK
Email: [email protected]
Change Log 18
What's New 19
802.1X with VLAN Switch interfaces on a FortiGate 21
1. Configuring a CA 22
2. Configuring RADIUS authentication 22
3. Configure the supplicant and test 25
4. Results 25
Adding Endpoint Control to the Security Fabric 28
1. Enabling endpoint control on the FortiGate 28
2. Enforcing FortiClient registration on the internal interface 29
3. Configuring the FortiClient Profile 30
4. Setting up a compliant FortiClient device 32
5. Results 34
Assigning WiFi users to VLANs dynamically 37
1. Configure the FortiAuthenticator 37
2. Add the RADIUS server to the FortiGate configuration 39
3. Create an SSID with dynamic VLAN assignment 39
4. Create the VLAN interfaces 41
5. Create security policies 44
6. Create the FortiAP Profile 46
7. Connect and authorize the FortiAP 47
Results 48
Blocking Facebook with Web Filtering 50
1. Enabling Web Filtering 50
2. Editing the default Web Filter profile 51
3. Creating the Web filtering security policy 52
4. Results 53
Blocking social media websites using FortiGuard categories 56
1. Enabling the Web Filter feature 56
2. Editing the default Web Filter profile 57
3. Adding the Web Filter profile to the Internet access policy 58
4. Results 60
Blocking Tor traffic 61
1. Enabling Application Control 61
2. Blocking Tor traffic in Application Control using the default profile 61
3. Adding application control to your security policy 62
4. Results 63
Blocking Windows XP traffic 65
1. Enabling Application Control 65
2. Creating a custom application signature 66
5. Results 534
SSL VPN single sign-on using LDAP-integrated certificates 536
1. Windows 10 certificate 536
2. Requesting and installing a server certificate for FortiOS 538
3. Configuring LDAP, PKI and a group 543
4. Configuring a group 544
5. Configuring the SSL VPN settings 545
6. Configuring the policy 546
7. Results 548
8. Logs 549
9. Summary 550
SSL VPN troubleshooting 551
Diagnose commands 551
1. Display debug messages 551
2. Verify the debug configuration 551
3. Display debug messages 551
4. End the debug process 552
Common issues 552
There is no response from the SSL VPN URL 552
FortiClient cannot connect 552
The SSL VPN login hangs or disconnects at 98% 553
Tunnel-mode connection shuts down after a few seconds 553
You receive the following error message: "Unable to logon to the server. Your user
name or password may not be configured properly for this connection. (-12)." 553
The tunnel connects but there is no communication 553
You can connect remotely to the VPN tunnel but are unable to access the network
resources 554
Users are unable to download the SSL VPN plugin 554
Users are being assigned to the wrong IP range 554
SSL VPN throughput is slow 554
SSL VPN using web and tunnel mode 556
1. Creating a user and a user group 556
2. Creating an SSL VPN portal for remote users 557
3. Configuring the SSL VPN tunnel 559
4. Adding an address for the local network 560
5. Adding security policies for access to the internal network and Internet 560
6. Setting the FortiGate unit to verify users have current AntiVirus software 563
7. Results 563
Web browsers: 563
FortiClient: 567
SSL VPN with certificate authentication 569
1. Enabling certificate management 569
2. Installing the server certificate 569
3. Installing the CA certificate 570
4. Creating PKI users and a user group 571
The following video goes through some of the features and updates in FortiOS 5.4, including: a new interface, new tools
for monitoring your network, new features to protect against new threats, and thousands of updates and tweaks to make
managing your firewall easier.
What's New In FortiOS 5.4
This recipe follows from the general introductory video, Manage FortiSwitch from FortiGate, which uses the FortiLink
protocol.
NOTE: This recipe is specific to FortiOS 5.4. For the most recent FortiSwitch (standalone and managed) administration
guides, see https://docs.fortinet.com/product/fortiswitch.
Using 802.1X with VLAN Switch interfaces on the FortiGate secures the network at the switch port by requesting a
connecting user to authenticate. In most deployments the user database will be external to the FortiGate.
This example uses FortiAuthenticator for the RADIUS authentication server, however the example is generic enough to
be adapted to any authentication server supported by the FortiGate and the EAP protocol. Also this example can be
adapted for other products which make use of 802.1X, such as wireless access points.
In this example we will configure EAP-TTLS.
There are three elements to be configured:
l The supplicant, which identifies the client, in this case a Ubuntu host.
l The authenticator, which translates EAP to RADIUS messages, and vice-versa. This is the FortiGate switch
controller.
l The authentication server, which processes the RADIUS messages. This is the FortiAuthenticator.
The topology is as shown:
1. Configuring a CA
In this example we configure EAP-TTLS which requires, as a minimum, server certificate validation. To do this we use
FortiAuthenticator, we create a CA root, self signed, and a service certificate for the authentication server. The
supplicant requires access to the CA certificate in order to validate the server authentication.
On FortiAuthenticator, go to Certificate Management > Certificate Authorities > Local CAs and create a new
Local CA. Enter a Certificate ID and Name (CN). Leave all other settings default.
This creates a root CA certificate that is self signed. This certificate must be copied to the supplicant.
Go to Certificate Management > End Entities > Local Services and create a new service. Enter a Certificate ID,
Issuer (your local CA), and Name (CN). Leave all other settings default.
This creates a certificate for the authentication server.
The FortiAuthenticator will be the RADIUS sever and the FortiGate the RADIUS client.
On the FortiAuthenticator, go to Authentication > RADIUS Service > Clients and create a new client. Enter the
Name, Client name/IP, and shared Secret. For Realms, use the local user realm and set EAP types to use EAP-
TTLS.
Go to Authentication > User Management > Local Users and create a local user and password.
This is your user account for 802.1X authentication.
Go to Authentication > RADIUS Service > EAP and select the local CA and local service certificates for the server's
authentication.
On the FortiGate, go to User & Device > RADIUS Servers and create a new server connection. Enter Name,
Primary Server IP/Name, and Primary ServerSecret.
We will configure the 802.1X supplicant settings on the wired interface of our Ubuntu host. Use the settings in the
following screenshot to test your connection.
Edit your wired connection and select 802.1X security. Chose Tunneled TLS (TTLS), your CA certificate,
MSCAPv2 for Inner authentication, and the Username.
4. Results
Using ifconfig, you should see that you have been allocated an address from the DHCP server.
If this does not work, check again the RADIUS client works using the testauth command. If that is ok, check your
certificates, paying attention to the valid from date and time.
In this example, you will use endpoint control on an ISFW FortiGate that is part of a Cooperative Security Fabric (CSF).
To do this, you will create a FortiClient Profile that only allows traffic from compliant devices to flow through the
FortiGate. The FortiClient Profile will also enforce the use of AntiVirus, Web Filtering, and Application Control, and
make sure that a current version of FortiClient is used.
In the example, the ISFW FortiGate has the host name Marketing. The FortiClient Profile is applied on the Marketing
FortiGate, rather than External, because the internal network connects directly to this FortiGate.
This recipe is part of the Cooperative Security Fabric collection. It can also be used as a standalone recipe.
This recipe requires both FortiOS 5.4.1 (or higher) and FortiClient 5.4.1 (or higher). If you need to upgrade, make sure
to upgrade registered FortiClient endpoints to FortiClient 5.4.1 before you upgrade FortiGate.
On the Marketing FortiGate, go to System > Feature Select and make sure that Endpoint Control is enabled.
Go to Network > Interfaces and edit the interface used for the internal network.
Under Administrative Access, enable FortiTelemetry.
UnderAdmission Control, enable Enforce FortiTelemetry for all FortiClients. You can also Exempt Sources
and/or Exempt Destinations/Services. If you were to exempt a source device, that device would not require
FortiClient registration to access network services or the Internet.
Configuring a FortiClient Profile allows you to control the security features enabled on the registered endpoint. The
profile is automatically downloaded by FortiClient when it connects to the FortiGate. You can add additional FortiClient
Profiles to define exceptions to the default profile. The configuration of the exception profiles includes devices, users, or
addresses to which the exception applies.
Go to Security Profiles > FortiClient Profiles and edit the default profile.
Set Non-compliance action to Auto-update, to make sure any non-compliant endpoints will have their configurations
updated to become compliant.
Enable AntiVirus, then enable both Realtime Protection and Up-do-date signatures.
Enable both Web Filter and Application Firewall and select the default filters.
Enable System compliance, then enable Minimum FortiClient version. Set both Windows endpoints and Mac
endpoints to FortiClient 5.4.1 (or higher).
Use a PC on the internal network that does not have FortiClient installed and attempt to connect to the Internet. A
message appears stating that endpoint compliance has failed. The message also contains instructions about how to
become compliant.
Install FortiClient on the PC, then go to the Compliance screen. Set up a FortiTelemetry connection to the Marketing
FortiGate.
After the connection is made, the device may still appear as Non-compliant because it has to receive and apply updates
from the Marketing FortiGate.
5. Results
Once FortiClient shows that your device is Compliant, you are able to connect to the Internet.
On the Marketing FortiGate, go to Monitor > FortiClient Monitor. The PC is listed as a Compliant device.
On the External FortiGate, go to FortiView > Physical Topology. The PC appears connected to the Marketing
FortiGate.
Go to FortiView > Logical Topology. The PC appears connected to the Marketing FortiGate.
Go to Monitor > FortiClient Monitor. Because endpoint control is applied to the Marketing FortiGate, the PC is listed
as an Exempt device.
Virtual LANs (VLANs) are used to assign wireless users to different networks without requiring the use of multiple SSIDs.
Each user's VLAN assignment is stored in the user database of the RADIUS server that authenticates the users.
This example creates dynamic VLANs for the Techdoc and Marketing departments. The RADIUS server is a
FortiAuthenticator.
Go to Authentication > RADIUS Service > Clients to register the FortiGate as a client.
Enter a Secret (a password) and remember it. It will also be used in the FortiGate configuration.
Go to Authentication > User Management > Local Users and create local user accounts as needed.
For each user, add these RADIUS attributes which specify the VLAN information to be sent to the FortiGate.
Tunnel-Private-Group-Id specifies the VLAN ID.
In this example, jsmith is assigned VLAN 100 and twhite is assigned VLAN 200.
Select WPA2 Enterprise security and select your RADIUS server for authentication.
Set the default VLAN ID to 10. This VLAN is used when RADIUS doesn't assign a VLAN.
Go to the Dashboard and use the CLI Console to enable dynamic VLANs on the SSID.
config wireless-controller vap
edit example-wifi
set dynamic-vlan enable
next
end
Create the VLAN interface for marketing-100 and set up DHCP service.
Create the VLAN interface for techdoc-200 and set up DHCP service.
Create a policy that allows outbound traffic from techdoc-200 to the Internet.
For this policy too, in Logging Options enable logging for all sessions.
Results
The SSID will appear in the list of available wireless networks on the users' devices.
Both twhite and jsmith can connect to the SSID with their credentials and access the Internet (if a certificate warning
message appears, accept the certificate).
Go to Log & Report > Forward Traffic.
Note that traffic for jsmith and twhite pass through different policies (the column selections were customized for clarity).
The security policies could be made different so that Marketing and Techdoc departments were allowed different
access, but didn't think that was fair.
This recipe explains how to use a static URL filter to block access to Facebook and its subdomains.
By using SSL inspection, you ensure that Facebook and its subdomains are also blocked when accessed through
HTTPS.
Go to Security Profiles > Web Filter and edit the default Web Filter profile.
To block Facebook, go to Static URL filter, select URL Filter, and then click Create.
Set URL to *facebook.com. Set Type to Wildcard, set Action to Block, and set Status to Enable.
Go to Policy & Objects > IPv4 Policy, and click Create New. Give the policy a name that identifies its use.
Set Incoming Interface to the internal network and set Outgoing Interface to the Internet-facing interface.
Enable NAT.
Under Security Profiles, enable Web Filter and select the default web filter profile.
Enable certificate-inspection from the dropdown menu. This allows the FortiGate to inspect and apply web filtering to
HTTPS traffic.
The new policy has to be first on the list in order to be applied to Internet traffic. Confirm this by viewing policies By
Sequence.
To move a policy up or down, click and drag the far-left column of the policy.
4. Results
Visit facebook.com
HTTPS is automatically applied to facebook.com, even if it is not entered in the address bar. A FortiGuard Web Page
Blocked! message appears.
This recipe explains how to block access to social media websites using FortiGuard categories. An active license for
FortiGuard Web Filtering service is required.
Web filtering with FortiGuard categories allows you to take action against a group of websites, whereas a Static URL
Filter is intended to block or monitor specific URLs. Consult this blog post to determine whether to use FortiGuard
categories or a Static URL Filter to control your internal network’s access to websites.
If you wish to use a static URL filter to block access to a website and its subdomains, follow the example described in
Blocking Facebook with Web Filtering on page 50.
Go to System > Feature Select and confirm that the Web Filter feature is enabled.
Go to Security Profiles > Web Filter and edit the default Web Filter profile. Confirm that the FortiGuard category
based filter is enabled. FortiGuard’s web filtering categories are organized into six main groups; descriptions can be
found at FortiGuard Center.
Right-click on the General Interest – Personal FortiGuard category. Scroll down to the Social Networking
subcategory and right-click again. Select Block.
Go to Policy & Objects > IPv4 Policy, and click Create New. Give the policy a name that identifies its use.
Set Incoming Interface to the internal network and set Outgoing Interface to the Internet-facing interface.
Enable NAT.
Under Security Profiles, enable Web Filter and select the default web filter profile.
Enable HTTPS traffic. Using the deep-inspection profile may cause certificate errors. See Preventing certificate
warnings on page 445 for more information.
In order to be applied to Internet traffic, the new policy has to be higher in the policy sequence than any other policy that
could manage the same traffic. Confirm this under Policy & Objects > IPv4 Policy by viewing policies By
Sequence.
To move a policy up or down, click and drag the far-left column of the policy.
4. Results
Attempt to visit a social networking site such as facebook.com, twitter.com, or meetup.com. The HTTPS protocol is
automatically applied to these addresses, even if it is not entered.
A FortiGuard Web Page Blocked! message appears when attempting to visit sites in the blocked category.
Go to FortiView > Websites and select the 5 minutes view. The blocked social networking sites are listed in the
Domain column.
For further reading, check out FortiGuard Web Filtering Service in the FortiOS 5.4 Handbook.
In this recipe, you will block users on your network from accessing the Internet who use the Tor browser.
The Tor network allows users to browse the Internet anonymously by bouncing traffic around a distributed network of
relays located around the world. Observers are unable to determine the source and destination of Tor traffic since it
doesn’t take a direct route from source to destination.
This recipe uses the default Application Control signatures for the Tor client and web-based Tor. These signatures only
match unmodified versions of the Tor application.
Two signatures will appear: one for the web-based Tor usage and one for the Tor client.
Highlight both signatures and click Use Selected Signatures.
Both signatures now appear in the Application Overrides list, with the Action set to Block.
Go to Policy & Objects > IPv4 Policy to edit the policy that allows connections from the internal network to the
Internet.
Set Source to all.
Under the Security Profiles heading, enable Application Control and use the default profile. Enable SSH
Inspection and use deep-inspection. Using the deep-inspection profile may cause certificate erros. See Preventing
certificate warnings on page 445 for more information.
4. Results
Browse the Internet using the Tor browser. The Tor browser will be blocked.
Go to Log & Report > Application Control. You will see that Tor traffic has been blocked.
For further reading, check out Application Control in the FortiOS 5.4 Handbook.
This recipe demonstrates how you can use the Application Control security profile to block web traffic from PCs running
Windows NT 5 operating systems, including Windows XP and Windows Server 2003 (includes Windows virtual
machines).
When a computer’s operating system lacks vendor support, it becomes a threat to the network because newly
discovered exploits will not be patched. Using the FortiGate application control feature, you can restrict these
computers from accessing external resources. This recipe will only block web traffic from computers running the
designated operating systems. If you wish to block these computers from being on the network entirely, further action
will be necessary. However, the logs generated by this recipe can be used to identify the computers you wish to block.
Go to System > Feature Select. Under Security Features, enable Application Control.
Go to Security Profiles > Application Control and select View Application Signatures in the upper right-hand
corner. Create a new signature with the syntax presented here.
You can copy and paste this text into the Signature field.
The signature will appear at the top of the application list in the Web.Client category.
Go to Security Profiles > Application Control and edit the default policy.
Under Application Overrides, select Add Signatures.
The new signature should appear at the top of the list. If it does not, search for the signature’s name (in the example,
block-windows-nt5).
Select the signature, then click on Use Selected Signatures at the bottom of the page.
Go to Policy & Objects > IPv4 Policy and edit the policy that allows connections from the internal network to the
Internet.
Under Security Profiles, enable Application Control and use the default profile.
5. Results
When a PC running one of the affected operating systems attempts to connect to the Internet using a browser, a
replacement message appears. Because Application Control uses flow-based inspection, if you apply an additional
security profile to your traffic that is proxy-based, the connection will simply timeout rather than display the replacement
message. Howerver, Application Control will still function.
PCs running other operating systems, including later versions of Windows, are not affected.
Go to Log & Report > Forward Traffic. Filter the results to show denied traffic.
You will see that the application control signature, Windows.NT.5.Web.Surfing, appears in the Application column
and was used to block traffic from PCs running Windows XP (device writer-0735721d).
For further reading, check out Custom Application & IPS Signatures in the FortiOS 5.4 Handbook.
If you are installing and configuring your applications on Amazon Elastic Compute Cloud (EC2) dynamically at instance
launch time, you will typically need to pull and install packages, deploy files, and ensure services are started. This
bootstrapping instruction helps simplify, automate, and centralize FortiGate next-generation firewall deployment
directly from the configuration scripts stored in AWS Simple Storage Services (S3).
On the AWS console, create an Amazon S3 bucket at the root level for the bootstrap files. If the folder is nested,
bootstraping will fail because you cannot specify a path to the files.
IAM roles need S3 bucket read access. In this example, you are applying the existing policy
AmazonS3ReadOnlyAccess to the role by adding the following code:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:Get*",
"s3:List*"
],
"Resource": "*"
}
]
}
If you need further instructions, please refer to the AWS documentation on IAM Roles for Amazon EC2.
Upload the license file and configuration file(s) to the S3 bucket. In this example, one license file and two configuration
files are uploaded.
Amazon S3 creates bucket in a region you specify. You can choose any AWS Region that is geographically close to you
to optimize latency, minimize costs, or address regulatory requirements. To choose a region, use the following code:
{
"bucket" : "confftnt",
"region" : "us-west-2",
"license" : "/FGVM080000066848.lic",
"config" : "/configfirewall.conf",
}
Although the S3 bucket and the firewall can be in different regions, it is highly recommended that they are in the same
region in order to speed up the bootstrapping process.
Follow the normal procedure to launch the instance from the AWS marketplace.
When selecting the VPC subnet, the instance needs to be with the role that was created and must specify the
information about the license file and configuration file from the AWS S3 bucket previously configured under Advanced
Settings.
5. Result
After the instance is launched, check the FortiGate’s System Information widget and verify that the settings and the
license information are correct.
For more information on how to bootstrap the FortiGate firewall with configuration and license files within the S3
bucket, please email [email protected].
In this example, you will allow WiFi traffic to specific destinations from Apple devices or Google Chromebooks to bypass
your Captive Portal. This allows those devices to receive updates or device logon authentication, a process which a
Captive Portal would interrupt.
Not all users or traffic types need to be authorized and authenticated by the Captive Portal. In some circumstances the
authentication required by the Captive Portal can cause problems impacting the functionality of your users mobile
device or laptop.
Chromebooks require user authentication to log onto the device, which can be blocked by the captive portals
requirement for user authentication, to gain network access.
Apple devices make use of Captive Network Assistant (CNA) which can detect the use of a captive portal. The apple
device attempts to visit the page captive.apple.com. If the apple device is successful, the CNA doesn't load, but if it
unsuccessful, then it launches a browser to prompt the user with the login page from the captive portal. When this
browser is inadvertently closed or ignored, the device is disconnected from the network. Often times the user is unaware
and does not know why email and updates are not being downloaded.
Go to User & Device > User Definition and create a Local user. Create additional users as needed. You can use any
authentication method.
We need to create address objects to be used for the exemptions. Go to Policy & Objects > Addresses and create
an FQDN address for accounts.google.com.
Create an IP/Netmask address object for the apple Subnet range 17.0.0.0/8.
Create IP/Netmask address object(s) for any external DNS servers the client computers might use.
Create an address for your SSID, using the same IP range that was set on the DHCP server.
Go to Policy & Objects > IPv4 Policy and create a policy allowing WiFi users to connect to the Internet. Select the
Fortinet-WiFi-IP-range for the permitted Source Addresses.
Enable NAT.
The Web Filter and Application Control security profiles are enabled, so we can see the results of our configuration.
Enable these profiles and others to provide secure internet access to your wireless clients.
Go to System > Interface and edit the interface the FortiAP connects to.
Set Administrative Access to allow CAPWAP.
The FortiAP will broadcast for the controller using the CAPWAP protocol. Go to WiFi Controller > Managed
FortiAPs.
The FortiAP is listed, with a grey question mark beside it because the device is not authorized.
A green check mark is now shown beside the FortiAP, showing that it is authorized and online.
Go to WiFi Controller > WiFi Network > FortiAP Profiles and edit the profile. For each radio:
Enable Radio Resource Provision.
Select your SSID.
6. Results
In this example a Chromebook is displayed with the IP address of 192.168.20.3. The user has authenticated against the
portal.
An iPhone is listed with the IP address of 192.168.20.4. A User is not listed as they have not yet authenticated against
the portal. We can see in the Bandwidth TX/RX column, that there is bidirectional traffic.
Go to FortiView > Sources
Review the current sessions of the connected network clients, by drilling down through each layer to view the related
sessions.
In this example, we see the sessions for the connected Chromebook. You can see towards the bottom that the sessions
happened prior to the user authentication against the portal. This proves the result of our exemption list.
Go to FortiView > Policies
Review the current sessions of the connected network clients for the SSID to internet security policy, by drilling down
through each layer to view the related sessions.
In this example, we see the sessions for the connected iPhone. We see that the user has not yet authenticated against
the portal, but the iPhone is making DNS requests and accessing the apple subnet. This proves the result of our
exemption list.
Go to Log & Report > Forward Traffic Log
Review the traffic and destinations for the Apple iPhone.
In the these logs you can see that the iPhone is receiving push notifications prior to the captive portal logon.
The first time that a wireless user attempts to use a web browser, the captive portal login screen is displayed. Users who
are members of the Forti-WiFi-users group can log on using their username and password and proceed to access the
wireless network.
For more information, see Captive Portals in the FortiOS 5.4 handbook.
For this recipe, you will set up a FortiGate to require users on an internal network to use two-factor authentication with
FortiToken Mobile through a captive portal to access the Internet.
The captive portal will be added to the FortiGate's internal interface and you will customize the portal by changing the
login page appearance and adding a new image.
This scenario assumes that you have already added an Internet access policy, that you have added FortiToken Mobile
to the FortiGate, and the elainemarley user is a member of the FortiToken user group named FTK-users.
Open the FortiToken Mobile application and go to Add account > Enter Manually > Fortinet. Use the Scan
Barcode option to scan the attached QR code if you received your activation code by email instead of SMS.
Enter your email address, enter the activation code you received, and select Add account.
The token will activate and start generating codes.
Enter a name for the new replacement image, select a Content Type (select from GIF, JPEG, TIFF, or PNG), and
upload an image file of your choice (in the example, Mêlée-Island.png).
Note that your image must be 24 KB or less.
In the HTML panel for Login Page, scroll down to the logo, and configure the HTML as follows:
}.logo{
background:#eee center 5px url(%%IMAGE:Example%%) no-repeat;
padding-top:110px;}
Under Authentication, select FortiToken Page and make the same customization changes made for the login page.
5. Results
Internal network users will be redirected to the captive portal login page when attempting to browse the Internet.
Enter elainemarley‘s user credentials. You will then be prompted to enter a FortiToken Code. Enter the code and
select Continue.
The user is now successfully authenticated and has access to the Internet.
To verify the elainemarley‘s connection, go to Monitor > FortiClient Monitor.
In this recipe, you will configure the FortiGate for captive portal access so users can log on to your WiFi network.
You will create a user account (rgreen), add it to a user group (employees), create a captive portal SSID (example-
staff), and configure a FortiAP unit. When the user attempts to browse the Internet, they will be redirected to the captive
portal login page and asked to enter their username and password.
Go to User & Device > User Definition and create a Local user (rgreen).
Create additional users if needed, and assign any authentication methods.
Go to User & Device > User Groups and create a user group (employees).
Add rgreen to the group.
Go to WiFi & Switch Controller > SSID and configure the wireless network. Some FortiGate models may show the
GUI path as WiFi & Switch Controller.
Enter an Interface Name (example-wifi) and IP/Network Mask.
Under WiFi Settings, enter an SSID name (example-staff), set Security Mode to Captive Portal, and add the
employees user group.
Go to Policy & Objects > Addresses and create a new address for the SSID (example-wifi-net).
Set Subnet/IP Range to the same range set on the DHCP server in the previous step.
Set Interface to the SSID interface.
Go to Policy & Objects > IPv4 Policy and create a new policy for WiFi users to connect to the Internet.
Add both the example-wifi-net address and employees user group to Source.
Connect the FortiAP unit to the configured interface, then go to WiFi & Switch Controller > Managed FortiAPs.
The FortiAP is listed, but its State shows a greyed-out question mark — this is because it is waiting for authorization.
Highlight the FortiAP and select Authorize.
The question mark is now replaced by a red down-arrow — this is because it is authorized, but still offline.
Go to WiFi & Switch Controller > FortiAP Profiles and edit the profile.
For each radio, enable Radio Resource Provision and select your SSID.
Go back to WiFi & Switch Controller > Managed FortiAPs to verify that the FortiAP unit is online.
7. Results
When a user attempts to connect to the wireless network, they will be redirected to the captive portal login screen.
Members of the employees group must enter their Username and Password. The user will then be redirected to the
URL originally requested.
On the FortiGate, go to Monitor > WiFi Client Monitor to verify that the user is authenticated.
In this recipe, you will enforce two-factor authentication for WiFi users who have physical FortiToken-200 devices
through a captive portal. FortiToken-200 users who attempt to browse the Internet will be redirected to the captive
portal login page and asked to enter their username, password, and token code.
This recipe assumes that you already have a FortiAP unit connected and authorized to the FortiGate, and that the SSID
has been set up and configured to use Captive Portal. For a recipe on how to set up a wireless network through a captive
portal, see Captive portal WiFi access control on page 96.
This recipe is designed for a FortiToken-200 physical key generator. See step 2 for information about using FortiToken
Mobile.
Go to User & Device > User Definition and edit the user (rgreen).
Select Enable Two-factor Authentication and select the token created earlier.
Select Add this user to groups and add the user to the captive portal user group (employees).
This recipe is designed for a FortiToken-200 physical key generator. If the user has FortiToken Mobile, the user's
contact information must be included so that the FortiToken code can be sent to the user via Email or SMS.
3. Results
When a user attempts to browse the Internet, they will be redirected to the captive portal login screen.
Members of the FortiToken group must enter their Username and Password, but will then be redirected to a screen
requiring the user to enter their Token Code. Retrieve the code by pressing the button on the FortiToken device.
Once the code is successfully entered, the user will be redirected to the URL originally requested.
On the FortiGate, go to Monitor > WiFi Client Monitor to verify that the user is authenticated.
This recipe is a followup to the ADVPN basic recipe. As we have seen in the base configuration, ADVPN provides the
means for spokes to automatically establish VPN sessions in a peer-to-peer fashion without the hub being involved in
data forwarding. This recipe explores how redundancy can be achieved for the hub functions within an ADVPN
environment.
As ADVPN leverages BGP, a redundant hub configuration involves having a second hub device that will also act as a
route reflector for the topology. That redundant hub device could be located in a geographically distinct site, in the same
datacenter or even as an additional VDOM on the same physical device. Each ADVPN topology generally benefits from
residing in its own VDOM or physical device.
ADVPN topologies can be regrouped under 3 deployment scenarios. While each of these scenario can benefit from
FGCP for physical device redundancy, only the dual hub scenario provides logical redundancy for a given group of
spokes (which we will term a “region”):
l Single hub: this offers no logical redundancy. A single hub with a single ADVPN IPSec topology running in a single
BGP autonomous system.
l Dual hub: this offers logical redundancy. Each additional hub role runs on a distinct VDOM or physical device.
Each additional hub runs a topology within the same BGP autonomous system, however hubs (route reflectors) are
unaware of each other.
l Dual regions: this offers no logical redundancy. This reflects a configuration in which we have distinct BGP
autonomous systems, each with distinct hubs which are interconnected and have shortcut forwarding enabled
between the hubs. Spokes are only connected to the hub of their own region. While this scenario can be combined
with “dual hub” to effectively create logically redundant regions, it is not in itself a redundancy technique as spokes
are not peered with more than a single BGP route reflector. It is redundant only in the sense that one hub being
unavailable would result in only partial availability issues.
More information on dual region setups can be obtained here:
https://kb.fortinet.com/kb/microsites/search.do?cmd=displayKC&docType=kc&externalId=FD39360
When multiple ADVPN hubs are deployed, careful consideration should be given to ensure that traffic will use the same
forward and reverse path due to the issues that can arise from symmetric routing in a firewall environment. While a
layered model with a stateless ADVPN topology can be leveraged for ECMP load balancing, in this recipe we will explore
a simpler version of redundancy in which one hub is designated as primary, with the secondary hub's topology being only
leveraged upon failure of the first hub.
Our topology is the following:
When compared with our original ADVPN article, this topology sees the addition of a hub unit. Our example assumes
WAN connectivity between the hub sites, which could be replaced with additional hub-to-hub VPN links. We are also
adding an additional device to this scenario, termed “ISFW”, which we use to advertise a route in OSPF in order to test
connectivity.
A few topology notes are in order before we go over the configuration:
l The topology makes use of a second BGP route reflector however neither route reflector is aware of the other, as
this introduces complexity related to route advertisement.
l The topology prioritizes ADVPN1.
l The topology assumes that both hubs and spokes have a single ISP link. In the case of multiple ISPs at either hub
or spoke, a decision must be made as to which ADVPN topology is used for each ISP and how fully meshed the
overlay VPNs must be. A common scenario is to have dual ISPs for the spokes where one ISP is used for ADVPN1
and the second is used for ADVPN2, in which case the configuration is no different from the topology we use in
this article.
l This example however does maintain that ADVPN2‘s hub direct attached subnets are being sent towards
ADVPN2 directly. All other hub-destined traffic will cross ADVPN1.
Things are going to get slightly more complex that a standard ADVPN configuration here, however this article will try to
clarify the configurations made as they are listed below.
1. Configure HUB1
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.
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
2. Configure HUB2
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
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 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 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
Results
The following schemas help understand the routing logic implemented by this article:
OSPF routes are redistributed into BGP using a local preference of 50 for HUB1 and 25 for HUB2 (#1 in diagram).
Connected routes are redistributed with the defaultlocal preference of 100 (#2 in diagram) . As BGP prefers routes
with higher local preferences, this logic ensures that a connected route advertised by a HUB to its spokes is preferred
over that connected route being redistributed in OSPF and advertised by the other HUB (#3 in diagram). Take a look at
this output from SPOKE1:
SPOKE1 # get router info bgp network
BGP table version is 2, local router ID is 192.168.3.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*>i192.168.0.0 10.10.10.1 0 100 0 ?
* i 10.10.11.1 0 100 0 ?
* i192.168.1.010.10.11.1 2 25 0 ?
In this topology's use case, this is preferable as it ensures traffic going to 192.168.1.0/24 or 192.168.2.0/24 will, under
normal conditions, use the VPN to the hub the route is directly connected to rather than circling around through the other
hub. As the output illustrates, while SPOKE1 has alternate paths for both HUB networks but prefers using the direct path
through each respective network's hub.
When receiving routes from spokes on either HUB, BGP routes are redistributed into OSPF. Metrics of 1 on the
preferred path and 5 on the backup path ensure that traffic flowing in and out of the datacenter's shared subnets (e.g.
192.168.100.0/24) follows the same path. The following output from our ISFW device (which is a basic OSPF router for
the intent of this topology) shows those metrics applied with preference for SPOKE1 prefix 192.168.3.0/24 taking the
path through ADVPN1 (HUB1):
Spokes advertise their own routes by setting a local preference of 200 on the primary ADVPN topology and leaving
the default local preference of 100 on the secondary ADVPN topology. This is consistent with the goals of this
architecture by ensuring spoke-originated routes are systematically preferred using ADVPN1.
Both local preferences associated with spoke originated routes (200 and 100) are higher than those of OSPF
redistribution (50 and 25) – again, this is to ensure we never favour spoke routes that have looped through OSPF for
inter-spoke traffic. In the above example of routing, SPOKE1 has advertised its routes to HUB1 using local preference of
200. HUB1 reflects this route to SPOKE2 and we have reachability as shown from the below output from SPOKE2:
SPOKE2 # get router info bgp network 192.168.3.0
BGP routing table entry for 192.168.3.0/24
Paths: (2 available, best #1, table Default-IP-Routing-Table)
Not advertised to any peer
Local
10.10.10.3 from 10.10.10.1 (192.168.3.1)
Origin IGP metric 0, localpref 200, valid, internal, best
Originator: 192.168.3.1, Cluster list: 10.10.10.1
Last update: Mon Jan 9 12:37:06 2017
Local
As expected, SPOKE2 prefers routes from SPOKE1 when advertised over ADVPN1 due to the local preference being
higher. As the output confirms however, there is predictably no route originating from either HUB and injected from
OSPF – both hubs having an administrative distance of 100 for internal BGP results in BGP routes always being
preferred over OSPF routes and thus, “backdoor” routes going through OSPF are not normally inserted into BGP by
either hub. However, if we simulate a failure between SPOKE1 and HUB2 (ADVPN2):
SPOKE1 # config sys int
SPOKE1 (interface) # edit ADVPN2
SPOKE1 (ADVPN2) # set status down
SPOKE1 (ADVPN2) # end
SPOKE1 #
SPOKE2 # get router info bgp network 192.168.3.0
BGP routing table entry for 192.168.3.0/24
Paths: (2 available, best #1, table Default-IP-Routing-Table)
Not advertised to any peer
Local
10.10.10.3 from 10.10.10.1 (192.168.3.1)
Origin IGP metric 0, localpref 200, valid, internal, best
Originator: 192.168.3.1, Cluster list: 10.10.10.1
Last update: Mon Jan 9 12:37:06 2017
Local
10.10.11.1 from 10.10.11.1 (10.10.11.1)
Origin incomplete metric 1, localpref 25, valid, internal
Last update: Mon Jan 9 13:02:19 2017
… SPOKE2's route that was redistributed by HUB1 into OSPF now does indeed appear in the list as HUB2 no longer
receives a better iBGP route from SPOKE1. That route is still not being used given that our primary ADVPN1 path is still
quite functional. Should we however add another failure, this time between SPOKE2 and HUB1 (ADVPN1):
SPOKE2 # config sys int
SPOKE2 (interface) # edit ADVPN
SPOKE2 (ADVPN) # set status down
SPOKE2 (ADVPN) # end
SPOKE2 #
SPOKE2 # get router info bgp network 192.168.3.0
BGP routing table entry for 192.168.3.0/24
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Not advertised to any peer
Local
10.10.11.1 from 10.10.11.1 (10.10.11.1)
Origin incomplete metric 1, localpref 25, valid, internal, best
Last update: Mon Jan 9 13:02:19 2017
… SPOKE2 now only has the path going through HUB2, then HUB1 in order to reach SPOKE1. Worthwhile to note that
in this condition, no ADVPN SHORTCUT will establish as spoke devices are on segregated ADVPN topologies and do
not share a common ADVPN hub. If we restore services:
SPOKE1 # config sys int
SPOKE1 (interface) # edit ADVPN2
SPOKE1 (ADVPN2) # set status up
SPOKE1 (ADVPN2) # end
SPOKE1 #
SPOKE2 # config sys int
SPOKE2 (interface) # edit ADVPN
SPOKE2 (ADVPN) # set status up
SPOKE2 (ADVPN) # end
SPOKE2 #
… we return to correct routing tables. If we then issue some traffic towards SPOKE1's subnet, we get the initiation of an
ADVPN SHORTCUT directly to SPOKE1:
SPOKE2 # get router info routing-table details 192.168.3.0
Routing entry for 192.168.3.0/24
Known via "bgp", distance 200, metric 0, best
Last update 00:00:37 ago
* 10.10.10.3 (recursive via 10.10.10.1)
In this recipe, we will explore a new VPN feature introduced in FortiOS 5.4.0: ADVPN.
ADVPN (Auto Discovery VPN) is an IPsec technology based on an IETF RFC draft (https://tools.ietf.org/html/draft-
sathyanarayan-ipsecme-advpn-03). In simple terms, ADVPN allows a traditional hub and spoke VPN's spokes to
establish dynamic, on-demand direct tunnels between each other so as to avoid routing through the topology's hub
device. ADVPN requires the use of dynamic routing in order to function and FortiOS 5.4 supports both BGP and RIP.
This recipe will focus on using BGP and its route-reflector mechanism as the dynamic routing solution to use with
ADVPN.
ADVPN's primary advantages is that it provides the full meshing capabilities to a standard hub and spoke topology,
greatly reducing the provisioning effort required for full spoke to spoke low delay reachability and addressing the
scalability issues associated with very large fully meshed VPN networks.
BGP (and specifically, iBGP) is a natural fit for ADVPN as its route reflector mechanism resides on the VPN hub device
and mirrors routing information from each spoke peer to each other. Furthermore, dynamic group peers result in near
zero-touch hub provisioning when a new spoke is introduced in the topology.
As pictured, while the static configuration will involve both spoke FortiGate units to connect to our circular hub
FortiGate, Spoke A will be able to establish a dynamic on-demand shortcut IPSec tunnel to Spoke B (and vice versa) if a
host behind either spoke attempts to reach a host behind the other spoke. We will complete the configuration below and
our verification step below will include reachability from 192.168.2.1 (spoke A) to 192.168.3.1 (spoke B) over the
dynamically created shortcut link.
This recipe is documented in CLI as configuration such as BGP and ADVPN are best done using the command line
interface. We are assuming basic IP and default routing configuration has been completed on the devices.
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 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 policies.
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 ---
Some additional data can be obtained using the very useful diag vpn tunnel list command. We are highlighting the
aspects in the output which convey data specific to ADVPN, in this case the auto-discovery flag and the child-parent
relationship of new instantiated dynamic tunnel interfaces.
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
------------------------------------------------------
Hair-pinning, also known as interface, connecting to its external IP. It is then forwarded by the FortiGate through a
virtual IP to the intended destination.
As a convenience, if a VIP is being used simultaneously with hair-pinning, the same address can be used whether you
are on the inside or the outside of the firewall. A VIP, also known as port forwarding, is set up to allow external users to
access an internal server. The VIP will take traffic sent to a public IP address and forward it to an internal IP address,
such as the server’s private IP.
The following hair-pinning scenario uses the situation where the VIP is associated to “any” interface.
Scenario:
1. Create a VIP
Before creating a policy for the hair-pinning, ensure that there is a policy managing traffic from the external to internal
through the VIP.
Go to Policy & Objects > Virtual IPs > Create New > Virtual IP. Enter a name for the VIP in the name box.
Set Interface to any.
Enter the External IP Address/Range and the Mapped IP Address/Range.
Enable Port Forwarding and specify the External Service Port and the Map to Port.
In order to propose a solution, there must first be a problem. Let’s verify if there is an issue:
You can try to connect to the external server via the external IP and VIP from a computer on the external side of the
firewall.
The connection is successful.
You can try to connect to the internal server via the external IP and VIP from a computer on the internal side of the
firewall.
The connection is unsuccessful.
2. Create a policy
When creating a policy for hair-pinning, it is important to use the internal interface as the Incoming Interface even
though the traffic will be hitting the external interface of the VIP. In this case, the Incoming Interface and Outgoing
Interface will be the same interface.
Go to Policy & Objects > IPv4 Policy > Create New. Enter a name for the policy in the name box.
Use the settings displayed in the graphic to create the policy.
Ensure that NAT is disabled.
3. Results
Here you can see that the hair-pinning technique was successful.
In this recipe you will learn how to configure LDAP over SSL (LDAPS) with Windows Server 2012. This external
authentication server provides secure password checking for selected FortiGate users or groups.
The Lightweight Directory Access Protocol (LDAP) is used to read from Active Directory. By default, LDAP traffic is
transmitted unsecured. You can make LDAP traffic confidential and secure by using Secure Sockets Layer (SSL).
The goal is to generate and export a CA certificate from the AD server, then import it, as an external CA certificate, into
the FortiGate. Finally, enable the CA certificate in the LDAPS server object.
Active Directory Certificate Services (AD CS) must be installed in your Windows Server 2012.
Open the Command Prompt, type mmc and hit enter. Select File and then click Add/Remove Snap-in. Select
Certificates and then click Add. In Certificates snap-in select Computer account and then click Next.
In Select Computer, if you are working at the LDAP server requiring the certificate, select Local. Otherwise, select
Another computer and click Browse to locate the LDAP server requiring the certificate. Once you have the correct
computer selected, click OK and then click Finish.
In the console tree, expand Certificates (<computer>). In the certificates console of a computer that contains a
certificate that can be used for Certificate Signing, right-click the CA certificate, click All Tasks, and then click
Export.
On the Certificate Export Wizard welcome screen, click Next. On the Export Private Key screen, select No, then
click Next.
On the File to Export screen, enter a path, file name, and .cer file extension in the File name box and then click Next.
Confirm the settings on the completion screen and then click Finish. You should see a pop-up message indicating that
the export was successful. Click OK.
Go to System > Certificates and select Import > CA Certificate. Select Local PC and Choose File, then browse
for certificate file and click OK.
4. Results
This collection of related recipes shows how to configure a Cooperative Security Fabric (CSF) – also known as a Fortinet
Security Fabric – throughout your network, using a range of Fortinet products. This Fabric will link different security
sensors and tools together to collect, coordinate, and respond to malicious behavior anywhere it occurs on your network
in real time.
Below, you will find links to a number of Cookbook recipes. By using these recipes in the listed order, you can create a
network similar to the one shown above.
You can find more information about Security Fabric at the Fortinet Document Library.
Between most steps are screenshots showing the FortiView Topology dashboards, which can be seen in the video
above. These dashboards display the devices that make up your Security Fabric. The Physical Topology dashboard
shows all access layer devices, while the Logical Topology dashboard displays information about the interface (logical or
physical) that each device is connected to.
In this recipe, you install the initial FortiGate, which will later be used as the Internet-facing, or upstream, FortiGate in
the Security Fabric.
Because the CSF has not yet been enabled, the FortiView topology dashboards are not yet available.
In this recipe, two additional FortiGates are added to the network as an Internal Segmentation Firewalls (ISFWs). Once
the FortiGates are installed, a Security Fabric is set up between them and the external FortiGate which was installed in
the network previously.
In the example network, the Internet-facing FortiGate is called External, with two additional FortiGates, called
Accounting and Marketing, configured as ISFWs. The FortiGates all appear in the FortiView toplogy dashboards on the
External FortiGate.
Physical topology:
Logical topology:
In this recipe, a FortiAnalyzer is installed to record and display logs from all FortiGates in the Security Fabric.
The FortiAnalyzer does not appear in the FortiView dashboards, so they remain unchanged.
In this recipe, the External FortiGate is set up as part of an High Availability (HA) cluster. This provides redundancy for
the network in case one of the FortiGates in the cluster fails.
The topology dashboards do not show both FortiGates in the HA cluster. However, the name of the upstream FortiGate
has changed to the name of the primary unit in the cluster (External-Primary).
Physical topology:
Logical topology:
In this recipe, two FortiSwitches are installed behind the ISFWs. The FortiSwitches are managed by the FortiGates and
will be used to connect two internal networks that will be protected by the FortiGates.
The FortiSwitches now appears in the Physical Topology dashboard, provided the Access Device view is selected. The
switches do not appear in the Logical Topology dashboard.
Physical topology:
Logical topology:
In this recipe, a FortiClient profile is used to enforce endpoint control for devices that are connected to the CSF.
In the screenshots below, endpoint control has been applied to a PC on the Marketing Network. Also, the Marketing
FortiSwitch now appears in the Logical Topology dashboard because traffic is flowing through it.
Physical topology:
Logical topology:
In this recipe, a FortiManager is added to provide central management for the FortiGates in the Security Fabric.
In this example, you will create a virtual wire pair (consisting of port3 and port4) to make it easier to protect a web server
that is behind a FortiGate operating as an Internal Segmentation Firewall (ISFW). Users on the internal network will
access the web server through the ISFW over the virtual wire pair.
A virtual wire pair consists of two interfaces that have no IP addresses and all traffic received by one interface in the pair
can only be forwarded out the other; as controlled by firewall policies. Since the interfaces do not have IP addresses,
you can insert a virtual wire pair into a network without having to make any changes to the network.
In FortiOS 5.4, virtual wire pair replaces the feature port pairing from earlier firmware versions. Unlike port pairing,
virtual wire pair can be used for a FortiGate in NAT/Route mode, as well as Transparent mode.
Interfaces used in a virtual wire pair cannot be used for admin access to the ISFW FortiGate. Before creating a virtual
wire pair, make sure you have a different port (in the example, port1) configured to allow admin access using your
preferred protocol.
Go to Network > Interfaces and select Create New > Virtual Wire Pair.
Add port3 and port4 add to the virtual wire pair. If the interfaces you wish to use are part of a switch, such as the default
lan/internal interface, you will need to remove them before they can be added to the virtual wire pair.
Go to Policy & Objects > IPv4 Virtual Wire Pair Policy and create a policy will allow users on the internal network
to connect to the server. Give the policy an appropriate name (in the example, Network-server-access).
Select the direction that traffic is allowed to flow (from port3 to port4).
Configure the other firewall options as needed. In the example, AntiVirus is enabled to protect the server.
Create a second virtual wire pair policy allowing traffic from port4 to exit out of port3. This policy allows the server to
connect to the Internet, in order to download updates.
3. Results
To test both virtual wire pair policies, connect to the web server from a PC on the internal network, and also connect to
the Internet from the web server.
In this recipe, you will create and order multiple security policies in the policy table, to apply the appropriate policy to
various types of network traffic.
In the example, three IPv4 policies will be configured:
l Internet: a policy allowing general Internet access to the LAN
l Mobile: a policy allowing Internet access while applying web filtering for mobile devices. In this example, a wireless
network has already been configured that is in the same subnet as the wired LAN.
l Admin: a policy allowing the system administrator's PC (named SysAdminPC) to have full access
A fourth policy, the default Implicit Deny policy, will also be used.
Go to Policy & Objects > IPv4 Policy and edit the policy allowing outgoing traffic. Set Name to Internet.
Set Service to HTTP, HTTPS, and DNS.
Ensure that you have enabled NAT. In order to view the results later, enable Log Allowed Traffic and select All
Sessions.
Go to Policy & Objects > IPv4 Policy and create a new policy. Set Name to Mobile.
Set Incoming Interface to lan, Source Device Type to Mobile Devices (a custom device group that includes tablets
and mobile phones), Outgoing Interface to your Internet-facing interface, and Service to HTTP, HTTPS, and DNS.
Using a device group will automatically enable device identification on the lan interface.
Enable NAT.
Under Security Profiles, enable Web Filter and set it to use the default profile. Enable SSL Inspection and and set
it to certificate-inspection to allow HTTPS traffic to be inspected. Doing this will enable Proxy Options; set that to
use the default profile.
Enable Log Allowed Traffic and select All Sessions.
3. Defining SysAdminPC
Go to User & Device > Custom Devices & Groups and create a new device. This will identify the system
administrator's PC.
Select an appropriate Alias, then set the MAC Address. Set the appropriate Device Type.
Go to Policy & Objects > IPv4 Policy and create a new policy. Set Name to Admin.
Set Incoming Interface to lan. Select Source and set Address to all and Device to SysAdminPC. Set Outgoing
Interface to your Internet-facing interface and Service to ALL.
Enable NAT. Enable Log Allowed Traffic and select All Sessions.
Go to Policy & Objects > IPv4 Policy to view the policy table. Select the By Sequence view, which shows the
policies in the order that they are used by the FortiGate.
Currently, the policies are arranged in the order they were created.
In order to have the correct traffic flowing through each policy, they must be arranged so that the more specific policies
are located at the top.
To rearrange the policies, select the column on the far left (in the example, Seq.#) and drag the policy to the desired
position, as shown on the right.
6. Results
Browse the Internet using the system administrator's PC, a different PC, and a mobile device.
Go to FortiView > Policies and select the now view. You can see traffic flowing through all three security policies.
(Optional) Attempt to make an SSL connection to a web server with all three devices. Only the system administrator's
PC will be able to connect.
In these days of heightened security awareness, it makes sense to understand what is protecting your passwords from
prying eyes. For anyone that has seen the configuration file of a FortiGate device, you are aware that there are some
passwords stored in this plain text file. With the processing power of computers getting faster some people are
concerned that if someone can access this string of characters that a password can be decrypted. This information is to
help relieve that concern.
The string of characters in place of the password in the configuration file is an encrypted hash of the password. The
encryption hash used for admin account passwords is Advanced Encryption Standard (AES). The value that is seen in
the configuration file is the Base64 encoded hash value. Any size discrepancy between the actual size and the size that
might be expected is probably because the actual size includes a 3-byte value to identify the type of password (four
types are supported) and a 12-byte IV.
In the case of the password field in a config user local entry, in the pre-shared key (PSK) field in a config FortiOS then
the fields are not stored as a hash of the password. Instead, the plain text password is stored. What is seen in the
configuration file is an encoded version of the password. The encoding consists of encrypting it with a fixed key using
AES (the same that is used in Federal Information Processing Standards (FIPS) mode of the firmware) and then Base64
encoding the result.
There is often no alternative to storing the (DES/AES encoded) plain text password. For example, the PSK in a config
VPN IPsec phase1 is defined by IKE to be the key in a keyed-hash message authentication code (HMAC) calculation
that is used to derive the actual key that will be used to secure the Internet Key Exchange (IKE) messages. Since neither
the PSK or a hash of it are sent on the wire in the IKE handshake it requires that both sides have the plain text PSK.
Thus
In this recipe, you will learn how to enforce a FortiClient Profile on an internal network such that only internal devices
registered with FortiClient can access the Internet and the corporate network. You will edit the default FortiClient Profile
to enforce realtime antivirus protection and malicious website blocking.
This recipe requires you to enable FortiHeartBeat on a FortiGate interface. When you enable FortiHeartBeat on an
interface, the option to enforce FortiClient registration becomes available. Devices connecting to that interface are
forced to register to the FortiGate and install FortiClient before getting access to network services.
FortiGates come with a free FortiClient license allowing a limited number of devices to register to the FortiGate and
download FortiClient. Your FortiGate gets the latest version of FortiClient for Mac and for Windows from FortiGuard.
When devices register with the FortiGate they download and install one of these copies of FortiClient. You can see the
status of your FortiClient licensing and purchase additional FortiClient licenses from the License Information Dashboard
Widget.
This recipe was tested using FortiClient version 5.4 and FortiOS (FOS) version 5.4.
There was a change in the FortiClient security profile from FOS 5.4 to FOS 5.4.1. The VPN, Advanced and Mobile tabs
do not appear in FOS versions 5.4.1 and above. Features emphasizing compliance of the endpoint devices have been
added. These enhancements facilitate integration with the Cooperative Security Fabric (called “Security Fabric” in FOS
5.6). Read more in the What’s New for Security Profiles 5.4.1.
On the FortiGate, go to System > Feature Select and make sure that Endpoint Control is enabled.
Under Admission Control, enable Enforce FortiHeartBeat for all FortiClients. You can also Exempt Sources
and/or Exempt Destinations/Services. If you were to exempt a source device, that device would not require
FortiClient registration to access network services or the Internet.
Configuring a FortiClient Profile allows you to control the security features enabled on the registered endpoint. The
profile is automatically downloaded to FortiClient when it registers to the FortiGate. You can add additional FortiClient
Profiles to define exceptions to the default profile. The configuration of the exception profiles includes devices, users, or
addresses to which the exception applies.
Go to Security Profiles > FortiClient Profiles and edit the default profile to provide realtime antivirus protection that
scans files as they are downloaded or copied to the device, block malicious websites and block attack channels.
4. Results
In this image, an internal device has FortiClient installed but not registered with a FortiGate. This is indicated by the
Attention banner, and also because the option to Register Endpoint is available.
When a user on this device attempts to browse the Internet, an Endpoint Security Required page appears instructing
the user to install and register endpoint security in the form of FortiClient.
A download link is provided at the bottom of the page. When the user clicks on this link, the FortiGate responds with a
download of the latest FortiClient software.
Similarly, since the device requires a registered FortiClient to access network services, internal servers (such as
Exchange mail servers) will also be blocked, unless otherwise exempted - see 2. Enforcing FortiClient registration on the
internal interface on page 171.
By comparison, a registered device appears below. The device shows as registered, with a lock icon next to the device
name in the upper right corner.
FortiClient should automatically attempt to register to the nearest FortiGate, provided that FortiHeartBeat has been
enabled and registration enforced.
A user on this device can verify their registration status by clicking on the device name.
FortiClient displays the device’s On-Net/Off-Net status, Hostname, Domain, registered FortiGate’s serial number
(SN), and IP address.
Upon registration, the FortiGate updates the FortiClient configuration to match the FortiClient Profile and downloads
the latest FortiGuard antivirus database to the device.
You can verify that the registered configuration update matches the FortiClient Profile.
Depending on the FortiClient Profile, the user may also have the option to Unregister the device. This can be disabled
on the FortiGate in Security Profiles > FortiClient Profiles, under the Advanced tab.
The registered device can now access corporate network services and browse the Internet.
To verify the status of the endpoints on the FortiGate, go to User & Device > Device List. Note that this list also
includes unregistered endpoints and any other connected device.
By default, this list shows On-Net/Off-Net Status, endpoint Device (Hostname and device name), endpoint IP
Address, and the device’s operating system (OS).
To view only the status of FortiClient connections, go to Monitor > FortiClient Monitor. Note that this list also
includes unregistered endpoints and any other connected device.
In this example, a second FortiAP are used to extend the range of a WiFi network. The second FortiAP is connected to
the FortiGate WiFi controller through a dedicated WiFi backhaul network.
In this example, both FortiAPs provide the example-staff network to clients that are in range.
More mesh-connected FortiAPs could be added to further expand the coverage range of the network. Each AP must be
within range of at least one other FortiAP. Mesh operation requires FortiAP models with two radios, such as the FortiAP-
221C units used here.
Go to WiFi Controller > SSID . Create the WiFi network (SSID) that clients will use.
Go to WiFi Controller > FortiAP Profiles and create a profile for the Platform (FortiAP model) that you are using.
Configure Radio 1 for the client channel on the 2.4GHz 802.11n/g Band.
Configure Radio 2 for the backhaul channel on the 5GHz 802.11ac/n Band.
Go to Policy & Objects > IPv4 Policy and create a new policy.
Go to Network > Interfaces and edit an available interface (in this example, port 15). Set Addressing mode to
Dedicate to Extension Device.
6. Preauthorizing FortiAP-1
Connect FortiAP-2's Ethernet port to the FortiGate network interface that you configured for FortiAPs.
Go to WiFi Controller > Managed FortiAPs. Click Refresh every 15 seconds until FortiAP-2 is listed. Select the AP,
then select Authorize.
Log in with the username admin, then enter the following CLI commands, substituting your SSID and password where
necessary:
cfg -a MESH_AP_TYPE=1
cfg -a MESH_AP_SSID=fortinet.mesh.root
cfg -a MESH_AP_PASSWD=hardtoguess
cfg -c
exit
Connect FortiAP-1. Go to WiFi Controller > Managed FortiAPs. Click Refresh every 15 seconds until FortiAP-1 is
listed.
Power up FortiAP-2. Periodically click Refresh. With a minute or two, Radio 2 of FortiAP-1 will indicate 1 client and
FortiAP-2 will be listed as mesh-connected.
Go to WiFi Controller > Managed FortiAPs. Edit FortiAP-2. Enter the Name and select the FortiAP Profile that
you created earlier.
Click Refresh to update the display as needed. Within a minute or two, FortiAP-2 will be listed as Online.
9. Results
Go to Monitor > WiFi Client Monitor. Both backhaul and client SSIDs are shown. Click Refresh as needed to see
updated information.
Connect to the network near FortiAP-2. The FortiAP column shows the client is associated with the mesh-connected
FortiAP-2.
Connect to the network near FortiAP-1. The FortiAP column shows the client is associated with FortiAP-1.
IP pools are a useful tool in NATing where the basic principles are fairly straightforward and the more basic options are
used with great success. However, this SysAdmin Note is going to concentrate on one of the lesser used IP Pool types –
Fixed Port Range. To focus on something even more low level, we’re going to look at how the IP addresses and ports
are selected.
In a Fixed Port Range type of IP pool there is nothing to force the internal and external ranges to be the same size so
there isn’t an obvious way to predict what the external IP address is going to be based on the internal or source address.
There is no one-to-one relationship between the addresses.
Here’s an example scenario for when you might want to use Fixed Port Range IP pool:
l Internal IP subnet of computers using an IP pool: 172.16.4.1 - 172.16.7.255. This means there are 1022 usable IP
addresses.
l The company has what used to be called a C-class address which is 254 usable addresses on the Internet. Of
these, 64 have been set aside for the IP pool.
While there isn’t any obvious method of prediction, in some situations there can be a requirement to be able to predict
the relationship between the source IP address and the one that it is given from the IP pool. This can occur in situations,
that for security reasons, the public IP address of a session needs to be known because communications between sites
are limited to specific IP addresses.
I apologize for those that hoped they wouldn’t have to deal with math and formulas after leaving high school or college
but let’s face it, computers are all about numbers. The following is the logic used to determine the IP address.
The first step in having the algorithm make sense is to define the variables we will be using:
src_ip Incoming IP address from the source device. This will fall in the range [src_start,
src_end])
The equations
Now that we have defined the variables, we can start to place them in the algorithm. In order to make the algorithm
more manageable and understandable, it is broken into 2 parts.
Note: You should be aware that floating point calculations are not used so the result from the factor calculation will be
an integer. The value is truncated, not rounded, so 36/10=3, not 4, as would be the case if rounded to the nearest
integer.
Because spanning multiple subnets make the math trickier we are going to use a simpler example of a Fixed Port
Range IP pool.
Variable Value
If a computer with the IP address 192.168.1.160 initiates a session through a policy using the example IP pool,
10.1.1.65 will be assigned as the NATed address.
These calculations get more complicated when you overlap subnets, but this example should give the basic principles
behind the process for assigning IP addresses.
TCP ports
The TCP port being use in a session could also be used to help determine which computer is the originating source of
the session, if it could be narrowed down far enough. This is more difficult than working with the IP addresses. The
problem is that determining which ports are assigned can have less to do with a unique computer identity than the order
in which he sessions were initiated.
There can be some narrowing down from the total of possibilities, but normally the scope of probable TCP ports is a
larger range of numbers than the scope of IP addresses.
Just like we did when determining the IP addresses, we’ll start by defining some variables and values.
port_share The range size that the total number of available ports will be divided into in order
to distribute the ports among the sessions
first_port_choice The number the port that the system will try to use first for the session
Now that we know what all of the variables mean, let’s give some values to a few in order to begin the calculations.
Variable Value
snat_port_begin 5117
snat_port_end 65533
These values are the default ones in the system. With an entire port range of possibilities from 5117 (snat_port_begin)
to 65533 (snat_port_end), It makes for a large number of possibilities. It does get narrowed down a little by using the
factor equation (see the section for calculating the IP addresses) to divide the range into shares for the sessions to use.
The equations
This equation is used to divide the total number of available ports into port shares that are of equal size for the sessions
to be divided between.
To determine the first choice of ports for a session, second equation is used.
This equation make use of the modulus function, of as shown in the equation, MOD. The use of MOD makes this
equation a little more interesting because we are multiplying by the remainder, instead of the resulting value from that
portion of the equation. This has the effect of distributing the ports for session not like a continuous stream but more like
dealing out cards from a deck to players. Session from IP address x goes to port share 1. Session from IP address x+1
goes to port share 2 and so on until we run out of shares that we start over from the beginning.
Using the information from the previous example, walking the calculations through step by step looks like this:
Second equation – determining the first port choice for the session
Before running the whole second equation let’s solve the MOD portion.
It happens in this case that 4 went into 60 cleanly with no remainder, making the value 0 and forcing us to multiply by 0,
which nobody likes, but it will still work in the final equation. If the src_ip was 162, the remainder would have ended up
being 2
To add a little ambiguity, the value produced by this equation does not guarantee that it will be the port used. Ports are
assigned on a first come, first served basis. If the first_choice_port is being used by another session already, then the
FortiGate will use generic logic going up the port list incrementally, to search for the next available port.
This methodology in determining the port used for a session tries to strike the balance between assigning specific port
numbers and making sure that every session can be assigned a port. Because some computers will generate a lot more
sessions than others a certain amount of flexibility has to be built in. With that flexibility comes unpredictability.
If the options for the port were limited to the scope of the port_share, one could expect the options for the ports
assigned to sessions from the IP address in the example to be anywhere from 5117 to 20220. 20220 being the number
before the first_port_choice in the next port share. If the remainder for the MOD portion of the equation been 1 instead
of 0, the first_port_choice value would have been 20221. However, because the system keeps going up the port list until
it finds a free one, if for some reason all of the ports in the first range are already in use, the system will keep going
through the list until it finds a free port, even if it is a number above 20221.
The algorithm for assigning ports works very will for making sure that whenever possible, every attempted session gets
a port for the purposes of NATing. The drawback is that it, while it gives a probable port range, it doesn’t guarantee the
sessions will be within the range. This means that reversing the algorithm to determine the source computer for the
purposes of forensic analysis will not give a definite conclusion.
Additional information
For this recipe, you will configure the FortiAuthenticator as a Certificate Authority (CA). This will allow the
FortiAuthenticator to sign certificates that the FortiGate will use to secure administrator GUI access.
This scenario includes creating a certificate request on the FortiGate, downloading the certificate to the network’s
computers, and then importing it to the FortiAuthenticator. You will sign the certificate with the FortiAuthenticator’s own
certificate, then download and import the signed certificate back to the FortiGate.
The process of downloading the certificate to the network’s computers will depend on which web browser you use.
Internet Explorer and Chrome use one certificate store, while Firefox uses another. This configuration includes both
methods.
On the FortiAuthenticator, go to Certificate Management > Certificate Authorities > Local CAs and create a new
CA.
Enter a Certificate ID, select Root CA certificate, and configure the key options as shown in the example.
The certificate must now be installed on the computers in your network as a trusted root CA. The steps below show
different methods of installing the certificate, depending on your browser.
In Windows Explorer, right-click on the certificate and select Install Certificate. Open the certificate and follow the
Certificate Import Wizard.
Make sure to place the certificate in the Trusted Root Certification Authorities store.
Finish the Wizard, and select Yes to confirm and install the certificate.
Firefox
In the web browser, go to Options > Advanced > Certificates and select View Certificates.
On the FortiGate, go to System > Certificates and select Generate to create a new certificate signing request (CSR).
Enter a Certificate Name, the Internet facing IP address of the FortiGate, and a valid email address, then configure
the key options as shown in the example.
Once created, the certificate will show a Status of Pending. Highlight the certificate and select Download.
This will save a .csr file to your local drive.
Back on the FortiAuthenticator, go to Certificate Management > End Entities > Users and import the .csr
certificate created earlier.
Make sure to select the Certificate authority from the dropdown menu and set the Hash algorithm to SHA-256, as
configured earlier.
Once imported, you should see that the certificate has been signed by the FortiAuthenticator, with a Status of Active.
Highlight the certificate and select Export Certificate.
This will save a .cer file to your local drive.
Back on the FortiGate, go to System > Certificates and select Local Certificate from the Import dropdown menu.
Browse to the .cer certificate you just created. Select Open and then select OK.
You should now see that the certificate’s Status has changed from Pending to OK. You may have to refresh your page
to see the status change.
7. Results
Close and reopen your browser, and go to the FortiGate admin login page. If you click on the lock icon next to the
address bar, you should see that the certificate has been signed and verified by the FortiAuthenticator. As a result, no
certificate errors will appear.
This document includes information about the steps you can take if your FortiGate isn’t functioning as expected after
you’ve installed it in either NAT/Route or Transparent mode. Steps apply to both NAT/Route and Transparent mode,
unless noted otherwise.
Verify that all network equipment is powered on and all cables connect to the right interfaces.
There are multiple LEDs on the faceplate of your FortiGate that you can use to troubleshoot the connections. Check
your device's QuickStart Guide for more information about the LEDs.
Use a computer on the internal network to IP address of the internal interface. For Transparent mode, ping the
management IP address.
If you can’t ping the FortiGate, verify that the IP address of the computer is on the same subnet as the IP address you’re
trying to reach. Also, make sure that PING is enabled for Administrative Access on the FortiGate interface.
If you can ping the interface but can’t connect to the GUI , make sure that HTTPS is enabled for Administrative
Access on the interface.
If you’re unable to connect using HTTPS or SSH, you need to connect through the console port on the FortiGate. If you
are using FortiOS 5.6 or higher, you can also connect using the FortiExplorer app for iOS.
Check the configuration of the FortiGate interfaces to make sure you use the correct Addressing Mode for your
network.
Check the Internet access policy to make sure Action is set to ACCEPT and that the policy is located near the top of
the policy list. Check the Sessions column to verify that traffic has been processed by this policy (if this column doesn’t
appear, right-click the title row, select Sessions, and select Apply).
If you’re using NAT/Route mode, make sure that NAT is enabled and Use Destination Interface Address is
selected.
Make sure you configured a default gateway IP address, provided by your ISP.
Use a computer on the internal network to ping the IP address of the Internet-facing interface. If you can’t connect to the
interface, verify that PING has been enabled for Administrative Access on the interface.
If you are still unable to connect, traffic is not allowed to flow from the internal network to the Internet-facing interface.
Go back to the installation recipe for your operation mode and verify that you correctly followed all the steps.
8. Verify that you can connect to the gateway provided by your ISP
Use a computer on the internal network to ping the default gateway IP address. If you can’t reach the gateway, contact
your ISP to verify that you are using the correct IP address.
On the FortiGate, use the CLI command execute ping to ping the IP address an IP address on the Internet, such as
8.8.8.8, the IP address of Google Public DNS. If you can’t ping the address, then the FortiGate isn’t able to access the
Internet.
You can also use the execute traceroute command to troubleshoot connectivity to the Internet.
The FortiGate uses the Domain Name System (DNS) to map domain names to the corresponding website IP
addresses. Use the CLI command execute ping to ping a domain name, such as www.fortinet.com, and verify that
the name can be resolved.
If it can’t, check that the DNS settings on the FortiGate are correct.
If none of the above steps identify your problem, reset the FortiGate to factory defaults using the CLI command
execute factoryreset. When prompted, type y to confirm the reset. Resetting the FortiGate to factory defaults
puts the FortiGate back into NAT/Toure mode.
If you need further assistance with troubleshooting your FortiGate, visit the Fortinet Support website.
This section contains tips to help you with some common challenges of FortiGate logging.
Ensure that logging is enabled in both the Log Settings and the policy used for the traffic you wish to log, as logging
will not function unless it is enabled in both places.
If logging is enabled in both places, check that the policy in which logging is enabled is the policy being used for your
traffic. Also make sure that the policy is getting traffic by going to the policy list and adding the Sessions column to the
list.
Ensure that the correct log source has been selected in the Log Settings, under GUI Preferences.
If logs still do not appear, use the following CLI command:
config system global
set gui-lines-per-page 20
end
If enabling disk logging has impacted overall performance, change the log settings to either send logs to a FortiAnalyzer
unit, a FortiManager unit, or to FortiCloud.
After installing a FortiGate in your network, there are some basic administrative tasks which you should complete. In
this recipe, you will complete these tasks to get your FortiGate ready for use:
l Registering your FortiGate with a Fortinet Support account
l Setting the correct system time
l Adding a password to the default administrative account
l (optional) Restricting administrative access to a trusted host PC
Registering your FortiGate allows you to receive FortiGuard updates and is required for firmware upgrades and access
to Fortinet Support.
Before registering your FortiGate unit, it must have Internet connectivity.
Go to the Dashboard and locate the License Information widget.
Next to Support Contract, select Register.
Either use an existing Fortinet Support account or create a new one. Select your Country and Reseller. To allow the
Support site to keep a complete listing of your devices, we recommend that you use one account to register all of your
Fortinet products.
Select your Time Zone and either set the time manually or select Synchronize with NTP Server. Since not all time
zones have names, you may need to know how many hours ahead (+) or behind (-) you are from Greenwich Mean Time
(GMT). The image displayed here is from FortiOS 5.4.0; the GUI for FortiOS 5.4.1 differs slightly.
It is also recommended to change the user name of this account; however, since you cannot change the user name of
an account that is currently in use, a second administrator account will need to be created in order to do this.
4. Results
Attempt to log in using the admin account without a password. Access is denied.
Log in using the admin account with your new password. Access is granted.
Go to the Dashboard and locate the Alert Message Console widget, which indicates the failed authentication
attempt.
If desired, you can configure an administrative account to only be accessible to someone using a trusted host. The host
can be either a particular device, or any device on a particular subnet.
Go to System > Administrators and edit the default admin account.
Enable Restrict login to trusted hosts. Set Trusted Host #1 to the static IP address of the PC you will use to
administer the FortiGate unit.
If required, set additional trusted hosts.
For further reading, check out Basic Administration in the FortiOS 5.4 Handbook.
In this recipe, you will set up FortiAuthenticator to function as a RADIUS server to allow SSL VPN users to authenticate
with a FortiToken-200.
You will configure a user (gthreepwood), FortiToken-200, and the RADIUS client on the FortiAuthenticator, create the
SSL VPN tunnel, and configure the FortiGate to use the FortiAuthenticator as a RADIUS server.
Note: Since publication, edits have been made to reflect minor GUI path changes made in the release of
FortiAuthenticator 4.2.
On the FortiAuthenticator, go to Authentication > User Management > FortiTokens, and select Create New.
Make sure Token type is set to FortiToken Hardware, and enter the FortiToken's serial number into the field
provided. The serial number, located on the back of the FortiToken device, is case sensitive. Note that the token can
only be registered to one device.
On the FortiAuthenticator, go to Authentication > User Management > Local Users, and select Create New.
Enter a Username (gthreepwood), enter and confirm a password, and make sure that Allow RADIUS authentication
is enabled.
Select OK to access additional settings.
Enable Token-based authentication, select to deliver the token code by FortiToken, and select the FortiToken
added earlier from the FortiToken Hardware dropdown menu.
Next, go to Authentication > User Management > User Groups, create a user group (RemoteFortiTokenUsers),
and add gthreepwood to the group.
On the FortiAuthenticator, go to Authentication > RADIUS Service > Clients, and select Create New.
Enter a name (OfficeServer), set Client name/IP to the IP of the FortiGate, and set a Secret. The secret is a pre-
shared, secure password that the FortiGate will use to authenticate to the FortiAuthenticator.
Set Authentication method to Enforce two-factor authentication, set Realms to local | Local users, and add
RemoteFortiTokenUsers to the Groups filter.
Note the Username input format. This is the format that the user must use to enter their username in the web portal.
On the FortiGate, go to User & Device > RADIUS Servers, and select Create New.
Enter a Name (OfficeRADIUS), set Primary Server IP/Name to the IP of the FortiAuthenticator, and enter the
Secret created before.
Test the connectivity and enter the credentials for gthreepwood. The test should come back with a successful
connection.
The FortiGate can now log into the RADIUS client added earlier to the FortiAuthenticator.
Then go to User & Device > User Groups, and select Create New.
Enter a Name (SSLVPNGroup), and under Remote groups, select Create New.
Select OfficeRADIUS under the Remote Server dropdown menu.
On the FortiGate, go to VPN > SSL-VPN Portals, and edit the full-access portal.
Disable Split Tunneling.
Go to Policy & Objects > IPv4 Policy and create a new SSL-VPN policy.
Set Incoming Interface to the SSL-VPN tunnel interface and set Outgoing Interface to the Internet-facing
interface.
Set Source to the SSLVPNGroup user group and set Destination Address to all.
Set Schedule to always, Service to ALL, and enable NAT.
6. Results
From a remote device, open a web browser and navigate to the SSL VPN web portal (https://FortiGate-IP:10443).
Enter gthreepwood‘s credentials and select Login.
Note that the username has to be entered in the format ‘realm\username‘, as per the client configuration on the
FortiAuthenticator (in this example, local\gthreepwood).
Once the code is successfully entered, gthreepwood will successfully log into the SSL VPN Portal.
On the FortiGate, go to Monitor > SSL-VPN Monitor to confirm the user's connection.
In this example, you will create guest accounts that can connect to your FortiGate's WiFi network for a limited amount of
time after authenticating using a captive portal. To make management easier, you will also create a separate
administrative account that can only be used to create and manage guest accounts.
In this example, a FortiAP in Tunnel mode is used to provide WiFi access to guests.
Go to User & Device > User Groups and create a new group.
Set Type to Guest. Set User ID to Email, Password to Auto-Generate, and Expire Type to After first login.
Leave Default Expire Time set to 4 Hours.
Go to WiFi & Switch Controller > SSID and create a new SSID.
Set Traffic Mode to Tunnel to Wireless Controller. Assign an IP/Network Mask to the interface and enable DHCP
server.
Under WiFi Settings, set Security Mode to Captive Portal and User Groups to the WiFi guest user group.
Go to WiFi & Switch Controller > FortiAP Profiles and edit the profile used by the FortiAP.
Set Radio 1 to broadcast the new SSID .
Go to Policy & Objects > IPv4 Policy and create a new policy. Give the policy a name that identifies its use.
Set Incoming Interface to the guest SSID, Source User(s) to the WiFi guest user group, Outgoing Interface to your
Internet-facing interface, and Service to ALL.
Enable NAT.
To simply guest account creation, an admin account can be made that is only used for guest user management. This
allows new accounts to be made as needed without requiring full administrative access to the FortiGate. In this
example, the account is made for use by reception staff.
Go to System > Administrators and create a new account.
Set a User Name and Password for the account. Set Type to Local User. Select Restrict admin to guest account
provisioning only and set Guest Group to the WiFi guest user group.
Sign in to the FortiGate using the new admin account. You will only be able to see the menu for Guest User
Management.
After you select OK, a User Created Successfully notice appears that shows the new account's Password. This
password can then be printed or emailed to the guest user.
6. Results
On a PC, connect to the guest SSID and attempt to browse the Internet.
When the authentication screen appears, log in using the guest user's credentials.
After the account is authenticated, you can connect to the Internet.
Five minutes after the initial login, the guest user account will expire and you will no longer be able to log in using those
credentials.
Use the reception account to log on to the FortiGate. The guest account is listed as Expired.
For further reading, check out Managing Guest Access in the FortiOS 5.4 Handbook.
This recipe describes how to enhance the reliability of a network protected by a FortiGate unit by adding a second
FortiGate unit and setting up a FortiGate Clustering Protocol (FGCP) High Availability cluster.
The FortiGate already on the network will be configured to become the primary unit by enabling HA, increasing its
device priority and enabling override. The new FortiGate will be prepared by setting it to factory defaults to wipe any
configuration changes. Then it will be licensed, configured for HA, and then connected to the FortiGate already on the
network. The new FortiGate becomes the backup unit and its configuration is overwritten by the primary unit.
This recipe describes best practices for configuring HA and involves extra steps that are not required for a basic HA
setup. If you are looking for a basic HA recipe see High Availability with two FortiGates on page 241.
Before you start, the FortiGates should be running the same FortiOS firmware version and interfaces should not be
configured to get their addresses from DHCP or PPPoE.
Connect to the primary FortiGate and locate the System Information Dashboard widget.
Change the unit's Host name to identify it as the primary FortiGate.
Register and apply licenses to the primary FortiGate unit before configuring it for HA operation. This includes activation
of FortiCloud and licenses for FortiGuard, FortiSandbox, and FortiClient, as well as entering a license key if you
purchased more than 10 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. If the FortiGates in the cluster will be running FortiOS Carrier, apply the
FortiOS Carrier license before configuring the cluster (and before applying other licenses). Applying the FortiOS Carrier
license sets the configuration to factory defaults, requiring you to repeat steps performed before applying the license.
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, 200) and enable override.
config system ha
set mode a-p
set group-id 25
set group-name External-HA-Cluster
set password
set priority 200
set override enable
set hbdev port3 50 port4 40
end
Enabling override and increasing the device priority means this unit should always become the primary unit.
This command also selects port3 and port4 to be the heartbeat interfaces and sets their priorities to 50 and 40
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 setting causes MAC address conflict you
can select a different group id.
You can also use the GUI (System > HA) to configure most of these settings.
Override and the group id can only be enabled from the CLI.
config system ha
set group-id 25
The FortiGate unit negotiates to establish an HA cluster. When you select OK you may temporarily lose connectivity
with the FortiGate unit as FGCP negotiation takes place and the MAC addresses of the FortiGate unit are changed to
HA virtual MAC addresses. These virtual MAC addresses are used for failover. The actual virtual MAC address assigned
to each FortiGate interface depends on the HA group ID. Since this example does not involve changing the HA group
ID, the FortiGate unit's interfaces will have the following MAC addresses: 00:09:0f:09:00:00, 00:09:0f:09:00:01,
00:09:0f:09:00:02 and so on. If these steps don't start HA mode, make sure that none of the FortiGate's interfaces use
DHCP or PPPoE addressing.
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.
To confirm these MAC address changes, you can use the get hardware nic (or diagnose hardware
deviceinfo nic) command to view the virtual MAC address of any FortiGate unit interface. Depending on the
FortiGate model, the output from this command could include lines similar to the following:
Current_HWaddr: 00:09:0f:09:00:00
Permanent_HWaddr 02:09:0f:78:18:c9
Enter this command to reset the new FortiGate that will become the 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 is
recommended to set it back to factory defaults to reduce the chance of synchronization problems.
If required, change the firmware running on the new FortiGate to be the same version as is running on the primary unit.
Register and apply licenses to the new FortiGate unit before adding it to the cluster. This includes activation of
FortiCloud and licenses for FortiGuard, FortiSandbox, FortiClient, and FortiToken, as well as entering a license
key if you purchased more than 10 Virtual Domains (VDOMS). All FortiGates in the cluster must have the same level
of licensing for FortiGuard, FortiCloud, FortiClient and VDOMs. If the FortiGates in the cluster will be running FortiOS
Carrier, apply the FortiOS Carrier license before configuring the cluster (and before applying other licenses). Applying
the FortiOS Carrier license sets the configuration to factory defaults, requiring you to repeat steps performed before
applying the license.
Duplicate the primary unit HA settings, except set the Device Priority to a lower value (for example, 50) and do not
enable override. If these steps don't start HA mode, make sure that none of the FortiGate's interfaces use DHCP or
PPPoE addressing.
config system ha
set mode a-p
set group-id 25
set group-name External-HA-Cluster
set password
set priority 50
set hbdev port3 50 port4 40
end
Connect the HA cluster as shown in the network diagram. Making these connections will disrupt network traffic as you
disconnect and re-connect cables.
If possible, make direct Ethernet connections between the heartbeat interfaces of the two FortiGate units. This example
uses two FortiGate-600Ds and the default heartbeat interfaces are used (port3 and port4). You can use any interfaces
for HA heartbeat interfaces. A best practice is to use interfaces that do not process traffic, but this is not a requirement.
Switches must be used between the cluster and the Internet and between the cluster and the internal networks 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.
When connected, the primary and backup FortiGates find each other and negotiate to form an HA cluster. The Primary
unit synchronizes its configuration with the backup FortiGate. Forming the cluster happens automatically with minimal
or no disruption to network traffic.
Check the cluster synchronization status to make sure the primary and backup units have the same configuration. Log
into the primary unit CLI and enter this command:
diag sys ha checksum cluster
The command output lists all cluster members' configuration checksums. If both cluster units 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 contact Fortinet support to help troubleshoot the problem.
The System Information Dashboard widget also shows if the cluster units are synchronized. Mouse over each FortiGate
in the cluster to verify that they both have the same checksum.
When the checksums are identical, disable override on the primary unit (recommended).
config system ha
set override disable
end
The HA cluster dynamically responds to network conditions. If you keep override enabled the same FortiGate will always
be the primary FortiGate. Because of this, however; the cluster may negotiate more often potentially increasing traffic
disruptions.
If you disable override it is more likely that the new FortiGate unit could become the primary unit. Disabling override is
recommended unless its important that the same FortiGate remains the primary unit.
From the System Information widget, select HA Status (or go to System > HA) to view the cluster status.
Select View HA Statistics for more information on how the cluster is operating and processing traffic.
5. Results
Normally, traffic should now be flowing through the primary FortiGate. If the primary FortiGate is unavailable traffic fails
over to the backup FortiGate. Failover will also cause the primary and backup FortiGates to reverse roles, even when
both FortiGates are available again.
To test this, ping the IP address 8.8.8.8 using a PC on the internal network. After a moment, power off the primary
FortiGate. If you are using port monitoring, you can also unplug the primary FortiGate's Internet-facing interface to test
failover. You will see a momentary pause in the Ping results, until traffic diverts to the backup FortiGate, allowing the
Ping traffic to continue.
For further reading, check out FGCP configuration examples and troubleshooting in the FortiOS 5.4 Handbook.
In this recipe, a backup FortiGate unit will be installed and connected to a previously installed primary FortiGate to
provide redundancy if the primary FortiGate fails. If you have not already installed a FortiGate, see Installing a
FortiGate in NAT/Route mode on page 256.
Before you start the FortiGates should be running the same FortiOS firmware version and interfaces should not be
configured to get their addresses from DHCP or PPPoE.
This recipe is part of the Cooperative Security Fabric collection. It can also be used as a standalone recipe.
This setup, called FortiGate High Availability (HA), improves network reliability. The previously installed FortiGate will
continue to operate as the primary unit and the new FortiGate will operate as the backup FortiGate.
For a more advanced HA recipe that includes CLI steps and involves using advanced options such as override to
maintain the same primary FortiGate, see High Availability with FGCP (Expert) on page 233.
Make sure both FortiGates are running the same FortiOS firmware version. Register and apply licenses to the new
FortiGate unit before adding it to the cluster. This includes activation of FortiCloud and licenses for FortiGuard,
FortiSandbox, and FortiClient, as well as entering a license key if you purchased more than 10 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. If the
FortiGates in the cluster will be running FortiOS Carrier, apply the FortiOS Carrier license before configuring the cluster
(and before applying other licenses). Applying the FortiOS Carrier license sets the configuration to factory defaults,
requiring you to repeat steps performed before applying the license.
You can also install any third-party certificates on the primary FortiGate before forming the cluster. Once the cluster is
formed third-party certificates are synchronized to the backup FortiGate.
Connect to the primary FortiGate GUI and from the System Information Dashboard widget change the HostName to
identify this as the primary FortiGate in the HA cluster.
Also on the System Information widget, configure HA Status (or go to System > HA). Set the Mode to Active-
Passive. Set theDevice Priority to a higher value than the default to make sure this FortiGate will always be the
primary FortiGate. Also set a Group Name and Password.
Make sure that the two Heartbeat Interfaces (port3 and port4) are enabled and their priorities are both set to 50.
Since the backup FortiGate is not available, when you save the HA configuration the primary FortiGate will form a
cluster of one FortiGate but will keep operating normally. If these steps don't start HA mode, make sure that none of the
FortiGate's interfaces use DHCP or PPPoE addressing.
If there are other FortiOS clusters on your network you may need to change the cluster group id using this CLI
command.
config system ha
set group-id 25
end
Connect the backup FortiGate to the primary FortiGate and the network as shown in the network diagram at the top of
the recipe. Making these network connections will disrupt traffic so you should do this when the network is quiet.
If possible, make direct Ethernet connections between the heartbeat interfaces of the two FortiGate units. This example
uses two FortiGate-600Ds and the default heartbeat interfaces are used (port3 and port4). You can use any interfaces
for HA heartbeat interfaces. A best practice is to use interfaces that do not process traffic, but this is not a requirement.
Switches must be used between the cluster and the Internet and between the cluster and the internal networks 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.
Connect to the backup FortiGate GUI and from the System Information Dashboard widget change the HostName to
identify this as the backup FortiGate.
Also on the System Information widget, configure HA Status (or go to System > HA) and duplicate the HA
configuration of the primary FortiGate (except for the Device Priority): set the Mode to Active-Passive, set theDevice
Priority to a lower value than the default to make sure this FortiGate will always be the backup FortiGate. Also set the
same Group Name and Password as the primary FortiGate.
Make sure that the two Heartbeat Interfaces (port3 and port4) are enabled and their priorities are both set to 50.
When you save the backup FortiGate's HA configuration, the FortiGates will find each other and form a cluster of two
FortiGates. Network traffic may be disrupted for a few seconds while the cluster is negotiating. If these steps don't start
HA mode, make sure that none of the FortiGate's interfaces use DHCP or PPPoE addressing.
Change the cluster group id if you changed it for the primary unit using this CLI command.
config system ha
set group-id 25
end
Connect to the primary FortiGate GUI. The System Information widget displays the HA status and some information
about the cluster. For example, the System Information widget can indicate when the configurations of the cluster units
in not synchronized.
From on the System Information widget, select HA Status (or go to System > HA) to view the cluster status.
Select View HA Statistics for more information on how the cluster is operating and processing traffic.
6. Results
Traffic is now passing through the primary FortiGate. However, if the primary FortiGate becomes unavailable, traffic
should failover and the backup FortiGate will process traffic.
Failover also causes the primary and backup FortiGate to reverse roles, even when both FortiGates are available again.
To test this, ping the IP address 8.8.8.8 using a PC on the internal network. After a moment, power off the primary
FortiGate. If you are using port monitoring, you can also unplug the primary FortiGate's Internet-facing interface to test
failover. You will see a momentary pause in the ping results, until traffic diverts to the backup FortiGate, allowing the
ping traffic to continue.
When a new version of the FortiOS firmware becomes available, upgrading the firmware on the primary FortiGate
automatically upgrades the backup FortiGate's firmware. Both FortiGates are updated with minimal traffic disruption.
For information about accessing firmware images, see Updating your FortiGate's firmware on page 623
Always review the Release Notes and Supported Upgrade Paths tool before installing new firmware. These can be
found in the Fortinet Document Library.
From the System Information widget, select Backup beside System Configuration. Always remember to back up
your configuration before upgrading the firmware.
From the System Information widget select Upgrade beside Firmware Version. Find the firmware image file that you
downloaded and select OK to upload and install the firmware build.
The firmware loads onto both the primary and the backup FortiGates with minimal traffic interruption.
After the upgrade is process is complete, verify that the System Information widget shows the new firmware version.
For further reading, check out FGCP configuration examples and troubleshooting in the FortiOS 5.4 Handbook.
In this recipe, you will set your FortiGate’s inspection mode to use flow-based scanning. You will then apply flow-based
antivirus scanning to network traffic.
FortiGates can inspect traffic in proxy mode or flow mode. Proxy mode, the default, uses a proxy to look for threats.
Proxy mode is usually preferred because, compared to flow mode, it offers more control and an improved user
experience. In addition, some security profiles are only available in proxy mode, such as DNS filter, AntiSpam, DLP, and
VoIP.
In some cases, however, you may want to use flow mode. Flow mode uses in-line IPS inspection instead of proxying.
For example, some traffic may not be compatible with proxy mode or you may want to avoid using proxy mode for
performance reasons.
Go to Dashboard and locate the System Information widget. If the Inspection Mode is set to the proxy (the
default), click on [Change] and select Flow-based. If you are working with VDOMs enabled, go to System > VDOM
and click Edit for the VDOM you want to change and select the Inspection Mode you would like to use.
Go to Security Profiles > AntiVirus. By default, the GUI only shows flow-based inspection options.
When configuring flow-based virus scanning FortiOS 5.4 allows you to now choose between Quick and Full mode.
Full mode is the same as flow-based scanning in FortiOS 5.2. Quick mode uses a compact antivirus database and
advanced techniques to improve performance. Files can only be sent to FortiSandbox for inspection while in Full scan
mode Flow-based virus scanning.
Go to Policy & Objects > IPv4 Policy and edit the policy for outgoing traffic. Under Security Profiles, enable the
AntiVirus profile.
4. Results
To test the AV scanning, go to www.eicar.org and attempt to download a test file. The browser will display a message
denying permission to download the file.
For further reading, check out Changing the FortiGate’s inspection mode to flow or proxy and AntiVirus sections in the
FortiOS 5.4 Handbook.
In this example, you will learn how to connect and configure a new FortiGate unit in NAT/Route mode to securely
connect a private network to the Internet.
In NAT/Route mode, a FortiGate unit is installed as a gateway or router between two networks. In most cases, it is used
between a private network and the Internet. This allows the FortiGate to hide the IP addresses of the private network
using network address translation (NAT).
Connect the FortiGate's Internet-facing interface (typically WAN1) to your ISP-supplied equipment and Connect a PC to
the FortiGate using an internal port (typically port 1).
Power on the ISP's equipment, the FortiGate unit, and the PC on the internal network.
From the PC on the internal network, connect to the FortiGate's web-based manager using either FortiExplorer or an
Internet browser (for information about connecting to the web-based manager, please see your models QuickStart
Guide).
Login using an admin account (the default admin account has the username admin and no password).
Go to Network > Interfaces and edit the Internet-facing interface (in the example, wan1).
If your FortiGate is directly connecting to your ISP, set Addressing Mode to Manual and set the IP/Netmaskto the
public IP address your ISP has provided you with.
If you have ISP equipment between your FortiGate and the Internet (for example, a router), then the wan1 IP will also
use a private IP assigned by the ISP equipment. If this equipment uses DHCP, set Addressing Mode to DHCP to get
an IP assigned to the interface.
If the ISP equipment does not use DHCP, your ISP can provide you with the correct private IP to use for the interface.
Edit the laninterface (called internal on some FortiGate models).
Make sure the interface's Role is set to LAN .
Set Addressing Mode to Manual and set the IP/Netmask to the private IP address you wish to use for the FortiGate.
The FortiGate unit's DNS Settings are set to use FortiGuard DNS servers by default, which is sufficient for most
networks. However, if you need to change the DNS servers, go to Network > DNS, select Specify, and add Primary
and Secondary servers.
Some FortiGate models include an IPv4 security policy in the default configuration. If you have one of these models,
edit it to include the logging options shown below, then proceed to the results section.
Go to Policy & Objects > IPv4 Policy and create a new policy. Give the policy a Name that indicates that the policy
will be for traffic to the Internet (in the example, Internet).
Set the Incoming Interface to the lan interface and the Outgoing Interface to the Internet-facing interface. Set
Source, Destination Address, Schedule, and Services as required.
Make sure the Action is set to ACCEPT. Turn on NAT and make sure Use Outgoing Interface Address is selected.
Scroll down to view the Logging Options. In order to view the results later, enable Log Allowed Traffic and select
All Sessions.
5. Results
You can now browse the Internet using any computer that connects to the FortiGate's internal interface.
You can view information about the traffic being processed by your FortiGate by going to FortiView > All Sessions
and selecting the now view.
Select Add Filter and filter for Policy, selecting the name of your new policy. Only traffic flowing through the new
policy is displayed.
In this example, you will learn how to connect and configure a new FortiGate unit in Transparent mode to securely
connect a private network to the Internet.
Transparent mode is used if you want to apply security scanning to traffic without applying routing or network address
translation (NAT), such as when a FortiGate is used as an Internal Segmentation Firewall (ISFW).
From the PC on the internal network, connect to the FortiGate's web-based manager using either FortiExplorer or an
Internet browser (for information about connecting to the web-based manager, please see your models QuickStart
Guide).
Login using an admin account (the default admin account has the username admin and no password).
Go to the Dashboard and enter the following command into the CLI console widget, substituting your own IP
addresses where necessary:
config system settings
set opmode transparent
set manageip 192.168.200.111 255.255.255.0
set gateway 192.168.200.99
end
You can now access the FortiGate using the new Management IP address (in the example, https://192.168.200.111).
Go to the Dashboard. The System Information widget shows the Operation Mode is Transparent.
The FortiGate unit's DNS Settings are set to use FortiGuard DNS servers by default, which is sufficient for most
networks. However, if you need to change the DNS servers, go to Network > DNS, select Specify, and add Primary
and Secondary DNS servers.
Some FortiGate models include an IPv4 security policy in the default configuration. If you have one of these models,
edit it to include the logging options shown below, then proceed to the results section.
Go to Policy & Objects > IPv4 Policy and create a new policy. Give the policy a Name that indicates that the policy
will be for traffic to the Internet (in the example, Internet).
Set the Incoming Interface to the internal interface (called internal on some FortiGate models) and the Outgoing
Interface to the Internet-facing interface (typically wan1). Set Source, Schedule, and Services as required.
Make sure the Action is set to ACCEPT.
Scroll down to view the Logging Options. In order to view the results later, enable Log Allowed Traffic and select
All Sessions.
Go to the Dashboard and locate the System Resources widget. Select Shutdown to power off the FortiGate unit.
Alternatively, you can enter the following command in the CLI Console:
execute shutdown
Wait until all the lights, except for the power light, on your FortiGate have turned off. If your FortiGate has a power
button, use it to turn the unit off. Otherwise, unplug the unit.
You can now connect the FortiGate unit between the internal network and the router.
Connect the wan1 interface to the router internal interface and connect the internal network to the FortiGate internal
interface port.
5. Results
You can now browse the Internet using any computer that connects to the FortiGate's internal interface.
You can view information about the traffic being processed by your FortiGate by going to FortiView > All Sessions
and selecting the now view.
Select Add Filter and filter for Policy, selecting the name of your new policy. Only traffic flowing through the new
policy is displayed.
In this example, you will install two Internal Segmentation Firewalls (ISFWs) behind your External FortiGate. One of
these FortiGates will be used to protect your Accounting team's network, while the other will be used for the Marketing
team. You will also enable a Cooperative Security Fabric (CSF) and use OSPF routing between these FortiGates. The
External FortiGate has already been installed in NAT/Route mode. For more information, see Installing a FortiGate in
NAT/Route mode on page 256.
This recipe is part of the Cooperative Security Fabric collection. It can also be used as a standalone recipe.
In this example, the External FortiGate's port 10 will connect to the Accounting FortiGate's wan1.
On the External FortiGate, go to Network > Interfaces and edit port 10.
Set an IP/Network Mask for the interface (in the example, 192.168.10.2).
Configure Administrative Access to allow FortiTelemetry, required for communication between FortiGates in the
CSF. Configure other services as required.
Go to Policy & Objects > IPv4 Policy and create a policy for traffic from the Accounting FortiGate to the Internet.
Enable NAT.
Go to Policy & Objects > IPv4 Policy and create a policy to allow users on the Accounting network to access the
Internet.
Because OSPF routing will be used, make sure NAT is not enabled.
Connect and configure the Marketing FortiGate using the same method as the Accounting FortiGate. Make sure to
include the following:
On External On Marketing
l Configure an interface to connect to the Marketing l Configure wan1 to connect to the External
FortiGate (this example uses port 11 with the IP FortiGate (example IP: 192.168.200.10)
192.168.200.2) l Configure the lan interface for the Marketing
l Create a policy for traffic from the Marketing Network (example IP: 10.10.200.1)
FortiGate to the Internet l Create a policy to allow users on the Marketing
network to access the Internet
On the External FortiGate, go to Network > OSPF. Set Router ID to 0.0.0.1 and select Apply.
Expand the Advanced Options and set Default Information to Always, to make sure the default route is broadcast
from External to the ISFW FortiGates.
In Areas, select Create New. Set Area to 0.0.0.0, Type to Regular, and Authentication to None.
In Networks, select Create New. Set IP/Netmask to 192.168.10.0/255.255.255.0 (the subnet that includes
Accounting's wan1) and Area to 0.0.0.0.
Create a second entry with the IP/Netmask set to 192.168.200.0/255.255.255.0 (the subnet that includes Marketing's
wan1).
On the Accounting FortiGate, configure OSPF routing as shown. The Networks in this configuration are the subnet that
includes Accounting's wan1 and the subnet for the Accounting Network.
In the example, the Marketing FortiGate is a 90D, a model that does not support OSPF configuration using the GUI. To
add OSPF routing, use the following CLI command:
config router ospf
set router-id 0.0.0.3
config area
edit 0.0.0.0
next
end
config network
edit 1
set prefix 192.168.200.0/255.255.255.0
next
edit 2
set prefix 10.10.200.0/255.255.255.0
next
end
end
On the External FortiGate, go to System > Cooperative Security Fabric. Enable Cooperative Security Fabric
(CSF) and set a Group name and Group password.
On the Accounting FortiGate, go to System > Cooperative Security Fabric. Enable Cooperative Security Fabric
(CSF) and enter the name and password for the fabric.
Enable Connect to upstream FortiGate and enter the IP address of External port 10.
Configure CSF on the Marketing FortiGate, using the IP address of External port 11.
6. Results
Go to Monitor > Routing Monitor. You will see both ISFW FortiGates listed, using OSPF routing.
CSF configurations allow you to distribute security functions to different FortiGates in the security fabric. For example,
you may want to implement virus scanning on the External FortiGate but add application control and web filtering to the
ISFW FortiGates.
This results in distributed processing between the FortiGates in the CSF; reducing the load on each one. It also allows
you to customize the web filtering and application control for the specific needs of the Accounting network as other
internal networks may have different application control and web filtering requirements.
This configuration may result in threats getting through the External FortiGate which means you should very closely limit
access to the network connections between the FortiGates in the CSF.
On the External FortiGate, go to Policy & Objects > IPv4 Policy and edit the policy allowing traffic from the
Accounting FortiGate to the Internet.
Under Security Profiles, enable AntiVirus and select the default profile.
Do the same for the policy allowing traffic from the Marketing FortiGate to the Internet.
On the Accounting FortiGates, go to Policy & Objects > IPv4 Policy and edit the policy allowing traffic from the
Accounting Network to the Internet.
Under Security Profiles, enable Web Filter and Application Control. Select the default profiles for both.
Do the same on the Marketing FortiGate.
Another strategy you could choose is to have flow-based inspection on the External FortiGate and proxy-based
inspection used by the ISFW FortiGates. For more information, see Inspecting traffic content using flow-based
inspection on page 250.
In this recipe, you will learn how to integrate a FortiGate with FortiClient Enterprise Management Server (EMS) and your
Active Directory server to protect the devices or endpoints on your network. Using this Internal Segmentation Firewall
(ISFW) configuration you can relatively easily deploy and manage FortiClient to protect all of the endpoints on your
network.
FortiClient EMS supports ISFW by simplifying FortiClient deployment and by providing endpoint management from a
single console. FortiClient EMS helps to provide real-time control and visibility into your endpoints when they are both
on and off corporate networks.
In FortiGate Integrated mode, FortiClient EMS deploys the endpoint clients while an integrated FortiGate running
FortiOS 5.4 handles Network Access Control (NAC) and policy enforcement.
For more information on FortiClient EMS, please refer to the FortiClient EMS Administration Guide.
In the FortiClient EMS Dashboard, go to Endpoints > Domains and select the Add a new domain button.
In the Domain Settings window, enter the Active Directory server information.
Test the connection, and then select Save.
Select the new domain in the Domains list to view the Client Details and FortiClient Information.
If you have previously configured Endpoint Profiles on a FortiGate and you wish to import them into FortiClient EMS,
follow the instructions below.
Navigate to the Endpoint Profiles list on the left pane and click on the Import profile from FortiGate icon.
Enter the FortiGate IP/Hostname and valid administrator credentials and click Next.
You can assign a profile to a Domain or Workgroup by right-clicking on it and selecting Assign profile.
On the FortiGate, go to Network > Interfaces and edit the internal interface.
Under Restrict Access, enable FortiHeartBeat.
Scroll down to Admission Control and enable Enforce FortiHeartBeat for all FortiClients. You can also Exempt
Sources (such as non-FortiClient supported devices—routers, printers, Linux devices) and/or Exempt
Destinations/Services (such as the EMS server itself, if necessary). When you exempt a source or destination, it does
not require FortiClient registration to access network services or the internet.
With the above configuration, devices on the internal network that aren’t registered with FortiClient are presented with
an Endpoint Security Required page that includes a download link to the FortiClient application on the FortiGate.
You can customize the FortiClient download installer link to use the EMS installer link instead.
On the FortiGate, go to System > Replacement Messages, switch to the Extended View, and edit the Endpoint
Control replacement message for the appropriate endpoints.
5. Results
When a device on the internal network that isn’t registered with FortiClient attempts to connect to the Internet, or
access other services behind the FortiGate, the user of that device is presented with an Endpoint Security Required
page that includes a download link to the FortiClient application.
When the user downloads and installs FortiClient, they are prompted for registration.
Enter the Registration Key and select Accept.
Note that the Registration Key matches the FortiHeartBeat Connection Key entered in Step 1.
The FortiClient then registers to the FortiGate (or FortiClient EMS, depending on the installation) and downloads a
configuration update from FortiClient EMS.
The registered endpoint now has access to the Internet and network services as defined by NAC and policy enforcement
on the FortiGate.
The registration information and FortiClient profile configuration can be verified in the FortiClient window.
To view the details of registered endpoints on FortiClient EMS, select Endpoints from the left pane.
Highlight one of the endpoints in the All Endpoints list to view Client Details.
To view the details of registered endpoints on the FortiGate, go to one of the following:
FortiView > Sources (Double-click the item in the list to drill down to greater detail).
In this recipe, you will use the FortiGate IPsecVPN Wizard to set up an IPsec VPN between a FortiGate and a device
running iOS 9. This configuration allows iPhone users to securely connect to an internal network.
The IPsec VPN is a pre-shared key configuration that also requires users to authenticate with their own credentials to be
able to connect to the VPN.
This recipe assumes that a user (dbuchanan) and a user group (iphone-users) have already been created on the
FortiGate.
An Apple iPhone SE running iOS 9.3.5 was used for this configuration.
Set Local Interface to the internal interface and set Local Address to all.
Enter an IP address range for VPN users in the Client Address Range field, enter a Subnet Mask, and select
Create.
Make sure no other interfaces on the FortiGate are using the same address range.
A summary page shows the wizard's configuration, including a remote-to-local access security policy.
On the iPhone, go to Settings > General > VPN and select Add VPN Configuration.
Make sure the IPsec VPN configuration is highlighted (indicated by the ✓ icon), and select the button next to Not
Connected.
The IPsec VPN will connect with the user's credentials and secret. The status will change to Connected, and a VPN
icon will appear at the top of the screen.
3. Results
To verify the connection, on the FortiGate, go to Log & Report > VPN Events. The user has been assigned an IP
from the client address range.
You may also verify the user's connection by going to FortiView > VPN .
In this recipe, you will use the FortiGate IPsec VPN Wizard to set up an IPsec VPN between a FortiGate and a device
running Windows Phone 10. The configuration will allow Windows Phone 10 users to securely connect to an internal
network.
The IPsec VPN is a pre-shared key configuration that also requires users to authenticate with their own credentials to be
able to connect to the VPN.
This recipe assumes that a user (dprince) and a user group (WinPhone_Users) have already been created on the
FortiGate.
A Windows Phone 10 Lumia 930 running build 10581 was used for this configuration.
Set Local Interface to the internal interface and set Local Address to all.
Enter an IP address range for VPN users in the Client Address Range field, enter a Subnet Mask, and select
Create.
Make sure no other interfaces on the FortiGate are using the same address range.
Go to Policy & Objects > IPv4 Policy and confirm that the wizard has created two policies: one policy for remote
users to access the VPN, and one policy that has Service set to L2TP.
On the Windows Phone 10, go to Settings > Network & wireless > VPN and select Add a VPN connection.
Enter a Connection name and set the Server name or address to the FortiGate's Internet-facing interface.
Set VPN type to Automatic and enter the pre-shared key — this key is the same one you added to the FortiGate.
Select Save.
3. Results
You will now connect to the IPsec VPN tunnel. From the VPN screen, select TheOffice.
Sign in and connect using dprince‘s credentials.
To verify the connection, on the FortiGate, go to Log & Report > VPN Events.
You may also verify the user's connection by going to FortiView > VPN .
The following recipe demonstrates how to configure a site-to-site IPsec VPN tunnel to Microsoft Azure™.
Using FortiOS 5.4, the example describes how to configure the tunnel between each site, avoiding overlapping subnets,
so that a secure tunnel can be established.
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.
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.
In the Create virtual network gateway blade, fill in the values for your virtual network gateway.
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.
Set the Remote Gateway to Static IP Address, and include the gateway IP Address provided by Microsoft Azure.
Located under All Resources > MyMainGateway (Virtual network gateway) > Overview > Public IP address.
Note that it may take some time for this address to populate.
Set the Local Interface to wan1.
Disable NAT Traversal and set Dead Peer Detection to On Idle.
Under Authentication, enter a Pre-shared Key and ensure that you enable IKEv2.
Under Phase 1 Proposal set the Encryption algorithm combinations to the following: AES 256 – SHA1, 3DES –
SHA1, and AES256 – SHA256.
Note that these are just three supported encryption-algorithm combinations that are accepted by Azure. For more
information about these combinations, and an up to date list of recommended IPsec VPN settings, see this article.
Select 2 for Diffie-Hellman Group.
Set Key Lifetime (seconds) to 28800.
Go to Policy & Objects > Addresses and create a firewall object for the Azure VPN tunnel subnet.
Go to Policy & Objects > IPv4 Policy and create a new policy for the site-to-site connection that allows outgoing
traffic.
Set the Source Address and Destination Address using the firewall objects you just created.
Ensure that NAT is disabled.
Create a second policy for the same connection to allow incoming traffic.
This time, invert the Source Address and Destination Address.
In order to avoid packet drops and fragmentation, it is strongly recommended to limit the TCP maximum segment size
(MSS) being sent and received.
Enter the following in the CLI Console for both firewall policies:
config firewall policy
edit <policy-id>
set tcp-mss-sender 1350
set tcp-mss-receiver 1350
next
end
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.
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.
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. If the tunnel fails to come up, begin troubleshooting by double-
checking the encryption algorithm and PSK settings match on both ends for Phase 1 and Phase 2. For other
troubleshooting tips, refer to IPsec VPN troubleshooting on page 332.
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.
Ingress and egress bytes confirm traffic flowing through the tunnel.
This section contains tips to help you with some common challenges of IPsec VPNs.
A VPN connection has multiple stages that can be confirmed to ensure the connection is working properly. It is easiest
to see if the final stage is successful first since if it is successful the other stages will be working properly. Otherwise, you
will need to work back through the stages to see where the problem is located.
When a VPN connection is properly established, traffic will flow from one end to the other as if both ends were physically
in the same place. If you can determine the connection is working properly then any problems are likely problems with
your applications.
On some FortiGate units, such as the FortiGate 94D, you cannot ping over the IPsec tunnel without first setting a
source-IP. In this scenario, you must assign an IP address to the virtual IPSEC VPN interface. Anything sourced from
the FortiGate going over the VPN will use this IP address.
If the IP address, then use the IP address of the egress/outgoing interface. Otherwise, use the IP address of the first
interface from the interface list (that has an IP address).
The first diagnostic command worth running, in any IPsec VPN troubleshooting situation, is the following:
diagnose vpn tunnel list
This command is very useful for gathering statistical data such as the number of packets encrypted versus decrypted,
the number of bytes sent versus received, the SPI identifier, etc. This kind of information in the resulting output can
make all the difference in determining the issue with the VPN.
Another appropriate diagnostic command worth trying is:
diagnose debug flow
This command will inform you of any lack of firewall policy, lack of forwarding route, and of policy ordering issues.
The following is a list of such potential issues. Bear in mind that the troubleshooting suggestions below are not
exhaustive, and may not reflect your network topology.
Go to System > Feature Select. Select Show More and turn on Policy-based IPsec VPN .
If your VPN fails to connect, check the following:
l Ensure that the pre-shared keys match exactly (see The pre-shared key does not match (PSK mismatch error)
below).
l Ensure that both ends use the same P1 and P2 proposal settings (see The SA proposals do not match (SA
proposal mismatch) below).
l Ensure that you have allowed inbound and outbound traffic for all necessary network services, especially if services
such as DNS or DHCP are having problems.
l Check that a static route has been configured properly to allow routing of VPN traffic.
l Ensure that your FortiGate unit is in NAT/Route mode, rather than Transparent.
l Check your NAT settings, enabling NAT traversal in the Phase 1 configuration while disabling NAT in the security
policy. You might need to pin the PAT/NAT session table, or use some of kind of NAT-T keepalive to avoid the
expiration of your PAT/NAT translation.
l Ensure that both ends of the VPN tunnel are using Main mode, unless multiple dial-up tunnels are being used.
l If you have multiple dial-up IPsec VPNs, ensure that the Peer ID is configured properly on the
l FortiGate and that clients have specified the correct Local ID.
l If you are using FortiClient, ensure that your version is compatible with the FortiGate firmware by reading the
FortiOS Release Notes.
l If you are using Perfect Forward Secrecy (PFS), ensure that it is used on both peers. You can use the diagnose
vpn tunnel list command to troubleshoot this.
l Ensure that the Quick Mode selectors are correctly configured. If part of the setup currently uses firewall
addresses or address groups, try changing it to either specify the IP addresses or use an expanded address range.
This is especially useful if the remote endpoint is not a FortiGate device.
l If XAUTH is enabled, ensure that the settings are the same for both ends, and that the FortiGate unit is set to
Enable as Server.
l Check IPsec VPN Maximum Transmission Unit (MTU) size. A 1500 byte MTU is going to exceed the overhead of
the ESP-header, including the additional ip_header,etc. You can use the diagnose vpn tunnel list
command to troubleshoot this.
l If your FortiGate unit is behind a NAT device, such as a router, configure port forwarding for UDP ports 500 and
4500.
l Remove any Phase 1 or Phase 2 configurations that are not in use. If a duplicate instance of the VPN tunnel
appears on the IPsec Monitor, reboot your FortiGate unit to try and clear the entry.
If you are still unable to connect to the VPN tunnel, run the following diagnostic command in the CLI:
diagnose debug application ike -1
diagnose debug enable
The resulting output may indicate where the problem is occurring. When you are finished, disable the diagnostics by
using the following command:
diagnose debug reset
diagnose debug disable
If your VPN tunnel goes down often, check the Phase 2 settings and either increase the Keylife value or enable
Autokey Keep Alive.
It is possible to identify a PSK mismatch using the following combination of CLI commands:
diagnose vpn ike log filter name <phase1-name>
diagnose debug app ike -1
diagnose debug enable
This will provide you with clues as to any PSK or other proposal issues. If it is a PSK mismatch, you should see
something similar to the following output:
ike 0:TRX:322: PSK auth failed: probable pre-shared key mismatch
ike Negotiate SA Error:
The most common problem with IPsec VPN tunnels is a mismatch between the proposals offered between each party.
Without a match and proposal agreement, Phase 1 can never establish. Use the following command to show the
proposals presented by both parties.
diagnose debug app ike -1
diagnose debug enable
The resulting output should include something similar to the following, where blue represents the remote VPN device,
and green represents the local FortiGate.
responder received SA_INIT msg
incoming proposal:
proposal id = 1:
protocol = IKEv2:
encapsulation = IKEv2/none
type=ENCR, val=AES_CBC (key_len = 256)
type=INTEGR, val=AUTH_HMAC_SHA_96
type=PRF, val=PRF_HMAC_SHA
type=DH_GROUP, val=1536.
proposal id = 2:
protocol = IKEv2:
encapsulation = IKEv2/none
type=ENCR, val=3DES_CBC
type=INTEGR, val=AUTH_HMAC_SHA_2_256_128
type=PRF, val=PRF_HMAC_SHA2_256
type=DH_GROUP, val=1536.proposal id = 1:
protocol = IKEv2:
encapsulation = IKEv2/none
type=ENCR, val=AES_CBC (key_len = 128)
type=INTEGR, val=AUTH_HMAC_SHA_96
type=PRF, val=PRF_HMAC_SHA
type=DH_GROUP, val=1536.
Should you need to clear an IKE gateway, use the following commands:
diagnose vpn ike restart
diagnose vpn ike gateway clear
To confirm whether a VPN connection over LAN interfaces has been configured correctly, issue a ping or traceroute
command on the network behind the FortiGate unit to test the connection to a computer on the remote network. If the
connection is properly configured, a VPN tunnel will be established automatically when the first data packet destined for
the remote network is intercepted by the FortiGate unit.
If the ping or traceroute fail, it indicates a connection problem between the two ends of the tunnel. This may or may not
indicate problems with the VPN tunnel. You can confirm this by going to Monitor > IPsec Monitor where you will be
able to see your connection. A green arrow means the tunnel is up and currently processing traffic. A red arrow means
the tunnel is not processing traffic, and this VPN connection has a problem.
Dialup connection
A dialup VPN connection has additional steps. To confirm that a VPN between a local network and a dialup client has
been configured correctly, at the dialup client, issue a ping command to test the connection to the local network. The
VPN tunnel initializes when the dialup client attempts to connect.
If the ping or traceroute fail, it indicates a connection problem between the two ends of the tunnel. This may or may not
indicate problems with the VPN tunnel, or dialup client. As with the LAN connection, confirm the VPN tunnel is
established by checking Monitor > IPsec Monitor.
If you have determined that your VPN connection is not working properly through troubleshooting, the next step is to
verify that you have a Phase2 connection.
If traffic is not passing through the FortiGate unit as you expect, ensure the traffic does not contain IPcomp packets (IP
protocol 108, RFC 3173). FortiGate units do not allow IPcomp packets, they compress packet payload, preventing it
from being scanned.
Testing Phase 1 and 2 connections is a bit more difficult than testing the working VPN. This is because they require
diagnose CLI commands. These commands are typically used by Fortinet customer support to discover more
information about your FortiGate unit and its current configuration.
Before you begin troubleshooting, you must:
l Configure FortiGate units on both ends for interface VPN
l Record the information in your VPN Phase 1 and Phase 2 configurations – for our example here the remote IP
address is 10.11.101.10 and the names of the phases are Phase 1 and Phase 2
l Install a telnet or SSH client such as putty that allows logging of output
l Ensure that the admin interface supports your chosen connection protocol so you can connect to your FortiGate
unit admin interface.
For this example, default values were used unless stated otherwise.
1. Log into the CLI as admin with the output being logged to a file.
2. Stop any diagnose debug sessions that are currently running with the CLI command:
diagnose debug disable
4. Set the log-filter to the IP address of the remote computer (10.11.101.10). This filters out all VPN connections
except ones to the IP address we are concerned with. The command is:
5. Set up the commands to output the VPN handshaking. The commands are:
diagnose debug app ike 255
diagnose debug enable
6. Have the remote FortiGate initiate the VPN connection in the web-based manager by going to VPN > IPsec
Tunnels and selecting Bring up.
This makes the remote FortiGate the initiator and the local FortiGate becomes the responder. Establishing the
connection in this manner means the local FortiGate will have its configuration information as well as the
information the remote computer sends. Having both sets of information locally makes it easier to troubleshoot
your VPN connection.
7. Watch the screen for output, and after roughly 15 seconds enter the following CLI command to stop the output.
diagnose debug disable
8. If needed, save the log file of this output to a file on your local computer. Saving the output to a file can make it
easier to search for a particular phrase, and is useful for comparisons.
Using the output from To get diagnose information for the VPN connection – CLI, search for the word proposal in
the output. It may occur once indicating a successful connection, or it will occur two or more times for an unsuccessful
connection — there will be one proposal listed for each end of the tunnel and each possible combination in their
settings. For example if 10.11.101.10 selected both Diffie-Hellman Groups 1 and 5, that would be at least 2 proposals
set.
A successful negotiation proposal will look similar to:
IPsec SA connect 26 10.12.101.10->10.11.101.10:500
config found
created connection: 0x2f55860 26 10.12.101.10->10.11.101.10:500
IPsec SA connect 26 10.12.101.10->10.11.101.10:500 negotiating
no suitable ISAKMP SA, queuing quick-mode request and initiating ISAKMP SA negotiation
initiator: main mode is sending 1st message...
cookie 3db6afe559e3df0f/0000000000000000
out [encryption]
sent IKE msg (ident-i1send): 10.12.101.10:500->10.11.101.10:500, len=264, id=3-
3db6afe559e3df0f/0000000000000000
diaike 0: comes 10.12.101.1:500->10.11.101.1:500,ifindex=26....
Note the phrase “initiator: main mode is sending 1st message...” that shows you the handshake
between the ends of the tunnel is in progress. Initiator shows the remote unit is sending the first message.
If you are trying to off-load VPN processing to a network processing unit (NPU), remember that only SHA1
authentication is supported. For high levels of authentication such as SHA256, SHA384, and SHA512 hardware
offloading is not an option — all VPN processing must be done in software.
Much like NPU-offload in IKE phase1 configuration, you can enable or disable the usage of ASIC hardware for IPsec
Diffie-Hellman key exchange and IPsec ESP traffic. By default hardware offloading is used. For debugging purposes,
sometimes it is best for all the traffic to be processed by software.
config sys global
set ipsec-asic-offload [enable|disable]
end
Ensure that both sides have at least one Phase 1 proposal in common. Otherwise they will not connect. If there are
many proposals in the list, this will slow down the negotiating of Phase 1. If its too slow, the connection may timeout
before completing. If this happens, try removing some of the unused proposals.
NPU offloading is supported when the local gateway is a loopback interface.
If routing is not properly configured with an entry for the remote end of the VPN tunnel, traffic will not flow properly. You
may need static routes on both ends of the tunnel. If routing is the problem, the proposal will likely setup properly but no
traffic will flow.
If one end of an attempted VPN tunnel is using XAuth and the other end is not, the connection attempt will fail. The log
messages for the attempted connection will not mention XAuth is the reason, but when connections are failing it is a
good idea to ensure both ends have the same XAuth settings. If you do not know the other end’s settings enable or
disable XAuth on your end to see if that is the problem.
Most connection failures are due to a configuration mismatch between the FortiGate unit and the remote peer. In
general, begin troubleshooting an IPsec VPN connection failure as follows:
1. Ping the remote network or client to verify whether the connection is up.
2. Traceroute the remote network or client. If DNS is working, you can use domain names. Otherwise use IP
addresses.
3. Check the routing behind the dialup client. Routing problems may be affecting DHCP. If this appears to be the
case, configure a DHCP relay service to enable DHCP requests to be relayed to a DHCP server on or behind the
FortiGate server.
4. Verify the configuration of the FortiGate unit and the remote peer. Check the following IPsec parameters:
l The mode setting for ID protection (main or aggressive) on both VPN peers must be identical.
l The authentication method (preshared keys or certificates) used by the client must be supported on the
FortiGate unit and configured properly.
l If preshared keys are being used for authentication purposes, both VPN peers must have identical preshared
keys.
l The remote client must have at least one set of Phase 1 encryption, authentication, and Diffie-Hellman
settings that match corresponding settings on the FortiGate unit.
l Both VPN peers must have the same NAT traversal setting (enabled or disabled).
l The remote client must have at least one set of Phase 2 encryption and authentication algorithm settings that
match the corresponding settings on the FortiGate unit.
l If you are using manual keys to establish a tunnel, the Remote SPI setting on the FortiGate unit must be
identical to the Local SPI setting on the remote peer, and vise versa.
5. To correct the problem, see the following table.
Peer ID or certificate name of the Check Phase 1 configuration. Depending on the Remote Gateway and
remote peer or dialup client is not Authentication Method settings, you have a choice of options to authenticate
recognized by FortiGate VPN FortiGate dialup clients or VPN peers by ID or certificate name.
server. If you are configuring authentication parameters for FortiClient dialup clients,
refer to the Authenticating FortiClient Dialup Clients Technical Note.
Phase 1 or Phase 2 key Make sure that both VPN peers have at least one set of proposals in common for
exchange proposals are each phase.
mismatched.
When a device with NAT capabilities is located between two VPN peers or a VPN peer and a dialup client, that device
must be NAT traversal (NAT-T) compatible for encrypted traffic to pass through the NAT device.
In this recipe, you will configure two-factor authentication using a FortiToken-200 for IPsec VPN connections.
This recipe assumes that you have already created a user (elainemarley) and a user group (FTK-users). You will add a
FortiToken-200 to the FortiGate, assign the token to the user, and add the user to the group. You will then use the
Wizard to create an IPsec VPN tunnel that allows FortiToken-200 users to securely access an internal network and the
Internet. You will test the setup by having the user access the VPN from a remote device, using FortiClient.
Go to VPN > IPSec Wizard and create a new IPsec VPN tunnel.
Name the VPN connection (in the example, FTK–VPN ).
Select the Remote Access template, set Remote Device Type to FortiClient VPN for OS X, Windows, and
Android, and select Next.
Set Local Interface to the internal interface and set Local Address to all.
Enter an IP address range for VPN users in the Client Address Range field. Make sure no other interfaces on the
FortiGate are using the same address range. A Subnet Maskshould already be set.
Select Next.
On your remote device, open the FortiClient application, go to Remote Access, and add a new connection.
Set VPN Type to IPsec VPN , and enter a Connection Name.
Set Remote Gateway to the IP address of the FortiGate, set Authentication Method to Pre-Shared Key, and enter
a Pre-Shared Key.
The key must match the same key entered in the wizard on the FortiGate earlier.
When finished, select Add.
5. Results
You will then be prompted to enter a FortiToken Code. Enter the code and select OK.
You can also go to Monitor > IPsec Monitor to view the tunnel's status, and Monitor > FortiClient Monitor to view
the user and device.
In this example, you will allow remote users to access the corporate network using an IPsec VPN that they connect to
using FortiClient for Mac OS X, Windows, or Android. Traffic to the Internet will also flow through the FortiGate, to
apply security scanning.
In this example, FortiClient 5.4.0.493 for Mac OS X is used.
Go to User & Device > User Definition. Create a local user account for an IPsec VPN user.
Go to User & Device > User Groups. Create a user group for IPsec VPN users and add the new user account.
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.
Go to VPN > IPsec Wizard and create a new tunnel using a pre-existing template.
Name the VPN connection. The tunnel name may not have any spaces in it and should not exceed 13 characters. 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 (the pre-shared key is a credential for the VPN and should differ from the user's password) 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. The IP range you enter here prompts FortiOS to create a new firewall
object for the VPN tunnel using the name of your tunnel followed by the _range suffix (in the example, IPsec-FCT_
range).
Make sure Enable IPv4 Split Tunnel is not selected, so that all Internet traffic will go through the FortiGate. If you do
select Enable Split Tunneling, traffic not intended for the corporate network will not flow through the FortiGate or be
subject to the corporate security profiles.
After you create the tunnel, a summary page appears listing the objects which have been added to the FortiGate's
configuration by the wizard.
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
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 unit, 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 > 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).
Go to FortiView > VPN to see which users have connected to the VPN.
In this recipe, you will learn how to create an IPsec VPN on a FortiGate, and connect to it using the default Mac OS X
client.
This configuration allows Mac users to securely access an internal network and browse the Internet through the VPN
tunnel. This recipe assumes that a user group (mac-users) has already been created.
This recipe was tested using Mac OS X El Capitan version 10.11.5.
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.
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
On the Mac, go to System Preferences > Network and select the Plus (+) button.
Set Interface to VPN , set VPN Type to Cisco IPsec, and select Create.
Set Server Address to the IP address of the FortiGate, enter the network account details for the user, and open
Authentication Settings.
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.
On the FortiGate, go to Monitor > IPsec Monitor and confirm that the tunnel Status is Up.
In this recipe, you will learn how to create an L2TP IPsec tunnel that allows remote users running the Windows 7 L2TP
client to securely connect to a private network.
The FortiGate implementation of L2TP enables a remote user to establish an L2TP IPsec tunnel with the FortiGate. For
the tunnel to work you configure a remote client (abhassan) to connect using an L2TP IPsec VPN connection.
This recipe assumes that the FortiGate unit is operating in NAT/Route mode and that it has a static public IP address.
This recipe is designed as a policy-based IPsec VPN, not route-based.
Most of the configuration occurs in the CLI Console, as L2TP settings are not configurable in the GUI. You can access
the FortiGate CLI Console from the FortiGate GUI using the administration menu or from the CLI Console Dashboard
widget.
Go to User & Device > User Definition and create a new L2TP user via the creation wizard (abhassan).
Next go to User & Device > User Groups and create a new user group for L2TP users (L2TP-group), and add
abhassan to the group.
Enter the following CLI command to set up an L2TP tunnel that includes the user group just created and defines the
L2TP client IP address range (start IP (sip) to end IP (eip)):
config vpn l2tp
set sip 10.20.100.1
set eip 10.20.100.101
set status enable
set usrgrp L2TP-group
end
Enter the following CLI command to configure Phase 1 (named l2tp-p1 below):
config vpn ipsec phase1
edit l2tp-p1
set type dynamic
set interface wan1
set dhgrp 2
set keylife 86400
Enter the following CLI command to configure Phase 2 (named l2tp-p2 below):
config vpn ipsec phase2
edit l2tp-p2
set phase1name l2tp-p1
set l2tp enable
set proposal 3des-sha1 aes192-sha1 aes256-md5
set pfs disable
set encapsulation transport-mode
set keylifeseconds 86400
next
end
Go to Policy & Objects > Addresses and create a new firewall address.
Enter a Name, set Type to IP Range, and enter the same IP range as configured earlier when enabling L2TP in the
CLI Console.
Go to System > Feature Select, enable Policy-based IPsec VPN , and select Apply.
Next go to Policy & Objects > IPv4 Policy, and create an IPsec VPN security policy that allows inbound and
outbound traffic.
Set Incoming Interface to the internal network and Source Address to all.
Set Outgoing Interface to wan1, Destination Address to all, Service to ALL, and Action to IPsec.
Under VPN Tunnel, select Use Existing and select the name of the Phase 1 configuration that you created (l2tp-p1).
On a PC, open the Start menu, search for VPN , and select Set up a virtual private network (VPN) connection.
Enter the FortiGate's IP address, enter a Destination name, and make sure to select the Don't connect now…
checkbox. Then select Next.
Enter the same User name and Password as configured earlier on the FortiGate and select Create.
Next, go to Start > Control Panel > Network and Sharing Center and select Connect to a network.
Enter the L2TP IPsec VPN's user credentials and select Connect.
You will then be connected to the VPN.
7. Results
On the FortiGate, go to Monitor > IPsec Monitor. The tunnel shows a Status of Up, with incoming and outgoing data.
You can also go to Log & Report > VPN Events, where you can select an entry and view more details. The user has
been assigned an IP address from within the L2TP client range.
When a particular IP address uses too many resources, you can prevent that IP from consuming your bandwidth
indiscriminately. In this recipe, you learn how to use Traffic Shaping on your FortiGate to limit the bandwidth for a
specific IP address.
This recipe also explains how to configure traffic shaping to set a maximum bandwidth limit for uploads and/or
downloads to 200 kb/s.
Go to System > Feature Select and under Additional Features enable Traffic Shaping. Two new traffic shaping
menus, Traffic Shapers and Traffic Shaping Policy, will appear under Policy & Objects.
Go to Policy & Objects > Addresses to define the address you would like to limit. Select Create New and select
Address from the drop down menu.
Enter a name: limited_bandwidth. Set Type to IP/Netmask. Set the Subnet/IP Range to the internal IP address you
wish to limit. In this example, 192.168.10.10/32. Set Interface to Any.
Go to Policy & Objects > Traffic Shapers and select Create New to define a new shared Traffic Shaper profile.
Set Type to Shared. Sharedshapers affect upload speeds, Reverse shapers affect download speeds, and Per IP
shapers affect both upload and download speeds simultaneously.
Enter the name limited_bandwidth for your shaper and set the Traffic Priority to Medium. Setting a Traffic Priority
will only have an impact if you have enabled Traffic Shaping in ALL your other Internet access policies using the same
two interfaces. There must also be some variation, for example you will not see any differences while all policies are set
to the default setting (High).
Select Max Bandwidth and enter 200 kb/s (0.2 Mbps). If you would like to set a Guaranteed Bandwidth make sure
the rate is lower than the Max Bandwidth. Apply your changes.
By default, shared shapers apply shaping by evenly distributing the bandwidth to all policies using it. You can also
enable Per Policy shaping to apply shaping individually to each policy. Right-click your new limited_bandwidth
shaper, and select Edit in CLI from the drop down menu.
Now that Per Policy shaping is enabled, edit your limited_bandwidth shaper and set Apply Shaper to Per Policy.
Now, each security policy using this shaper will have the same distribution of bandwidth, regardless of the number of
policies using the shaper. In this example, 200 kb/s (0.2 Mbps) each.
Go to Policy & Objects > IPv4 Policy and look at your general Internet access policy. Take a note of the Incoming
interface, Outgoing interface, Source and Destination.
If necessary, edit your policy and ensure that Logging Options is set to All Sessions for testing purposes.
Go to Policy & Objects > Traffic Shaping Policy and select Create New to create a shaping policy that will set
regular traffic to high priority.
Under Matching Criteria, set Source, Destination, Service to match your Internet Access policy.
Under Apply Shaper, set the Outgoing Interface to match your Internet Access policy and enable Shared Shaper
and Reverse Shaper. Shared Shapers affect upload speeds and reverse shapers affect download speeds. Set both
shapers to high-priority.
Select Create New to create a second traffic shaping policy that will affect the IP address you wish to limit.
Under Matching Criteria, set Source to limited_bandwidth. Set Destination and Service to ALL. Apply the shaper
to the same Outgoing Interface. Enable Shared Shaper and Reverse Shaper and set both shapers to limited_
bandwidth.
Order your traffic shaping policies so that your more granular limited_bandwidth policy is above your general high-
priority Internet access policy. Click on the far left column of the policy and move it up or down to change the sequence
order.
6. Results
When a computer with the IP you have specified, 192.168.10.10, browses the Internet from your internal network, its
bandwidth will be restricted by the amount you set in your shaper.
Go to FortiView > Sources to view traffic, and use the search field to filter your results by the Source IP
(192.168.10.10).
Go to FortiView > Traffic Shaping to view the current bandwidth usage for any active shapers. Users on the local
network will have high-priority traffic.
The IP address you have specified will receive limited-bandwidth treatment and may experience dropped bytes. Your
limited-bandwidth shaper should not exceed 200kbps. Note that the results show the Bytes (Sent/Received) in
Megabytes (MB) and the Bandwidth in kilobits per second (kbps).
You can also view these results in a bubble graph by changing the graph type in the drop down menu. Sort by
Bandwidth to verify that your regular traffic is using more bandwidth.
You can also double-click on either shaper to see more granular information. Select the Destinations tab to see which
websites are using up the most bandwidth.
For further reading, check out Traffic Shaping in the FortiOS 5.4 Handbook.
In this example, you will configure logging to record information about sessions processed by your FortiGate. You will
then use FortiView to look at the traffic logs and see how your network is being used.
FortiView is a logging tool made up of a number of dashboards that show real time and historical logs. The dashboards
can be filtered to show specific results, and many of them also allow you to drill down for more information about a
particular session. Each dashboard focuses on a different aspect of your network traffic, such as traffic sources of WiFi
clients.
Some FortiView dashboards, such as Applications and Web Sites, require security profiles to be applied to traffic
before they can display any results.
You can also use Remote Logging and Archiving to send logs to either a FortiAnalyzer/FortiManager, FortiCloud, or
a Syslog server.
Under Log Settings, enable both Local Traffic Log and Event Logging.
You can choose to Enable All logging or only specific types, depending on how much network data you want to collect.
Under the GUI Preferences, set Display Logs From to the same location where the log messages are recorded (in
the example, Disk).
Go to Policy & Objects > IPv4 Policy. Edit the policies controlling the traffic you wish to log.
Under Logging Options, select All Sessions.
In most cases, it is recommended to select security events, as all sessions requires more system resources and storage
space. For now, however, all sessions will be used to verify that logging has been set up successfully.
3. Results
Generate network traffic through the FortiGate, then go to FortiView > All Sessions and select the now view. A real
time display of active sessions is shown. Historical views are only available on FortiGate models with internal hard
drives.
If you right-click on a listed session, you can choose to remove that session, remove all sessions, or quarantine the
source address of that session.
Select the 24 hours view. A historical view of your traffic is shown. If you select a session, more information about it is
shown below.
Go to FortiView > Sources and select the 5 minutes view. A list of the sources of your network traffic is shown, as
well as a graph showing their activity during the last five minutes.
Right-click on any of the sources listed and select Drill Down to Details.
You can view a variety of information about the source address, including traffic destinations, security policies used, and
if any threats are linked to traffic from this address.
For further reading, check out FortiView in the FortiOS 5.4 Handbook.
This recipe demonstrates how to use FortiGate Cloud, an online logging service provided by Fortinet, to store logs of
your FortiGate unit's traffic. In this example, the log shows sites visited by users on the internal network.
You can access logs using the FortiGate and also through the FortiGate Cloud website. Before you can use FortiGate
Cloud, you must register your FortiGate. For more information, see FortiGate registration and basic settings on page
208.
Go to Dashboard and locate the License Information widget. In the FortiCloud row, select Activate.
Use an existing FortiGAte Cloud account or create a new one. It is recommended to use a common FortiGAte Cloud
account for all your Fortinet logs.
Information about your FortiGate Cloud account now appears in the License Information widget.
Go to Log & Report > Log Settings and disable local logging.
Enable Send Logs to FortiCloud and confirm that Upload Option is set to Realtime.
Select Test Connectivity to verify the connection between your FortiGate and FortiGate Cloud.
Adjust the Event Logging settings as desired and set the GUI Preferences to Display Logs From FortiCloud.
Go to Policy & Objects > IPv4 and edit the policy that allows connections from the internal network to the Internet.
Scroll down to view Logging Options. In order to confirm that logs are being sent to FortiGAte Cloud, enable Log
Allowed Traffic and select All Sessions.
4. Results
Browse the Internet. Then, go to Log & Report > Forward Traffic. In the top right corner of the screen, the Log
location is shown as FortiCloud.
Go to Dashboard. In the FortiCloud row of the License Information widget, select Launch Portal.
A screen will open in your browser, showing all the devices linked with your FortiGate account. Select the appropriate
unit.
You can also access your FortiGate Cloud account by going to www.forticloud.com
After you select your device, the FortiGate Cloud Dashboard appears, displaying information about traffic. If traffic does
not appear in FortiGate Cloud right away, wait 10-15 minutes and try again.
From the portal's top menu bar, you can also access options for FortiView, Drilldown, Reports, and Management.
For more information about using FortiGate Cloud, see the FortiGate Cloud Administration Guide
For further reading, check out FortiCloud in the FortiOS 5.4 Handbook.
This recipe demonstrates how to add device definitions to your FortiGate using Media Access Control (MAC) addresses.
These definitions are then used to identify which devices can access the WiFi network.
By using a MAC address for identification, you can also assign a reserved IP for exclusive use by the device when it
connects to the WiFi network.
Warning: Since MAC addresses can be easily spoofed, using MAC to control access should not be considered a
security measure.
Open the command prompt and type ipconfig /all to display configuration information for all network
connections.
The MAC address of your Windows device is the Physical Address, under information about the wireless adapter.
Open Settings > General > About Phone > Hardware Info.
Take note of the Wi-Fi MAC address of your Android device.
Go to User & Device > Custom Devices & Groups and create a new device definition.
Set MAC Address to the device's address and set the other fields as required. In the example, a device definition is
created for an iPhone with the MAC Address B0:9F:BA:71:D8:BB.
Go to User & Device > Device Inventory. The new definition now appears in your device list. If you have enabled
device identification on the wireless interface, device definitions will be created automatically. You can then use MAC
addresses to identify which device a definition refers to.
Go to User & Device > Custom Devices & Groups and create a new group.
Add the new device to the Members list.
Go to Network > Interfaces and edit the wireless interface. If the FortiAP is in bridge mode, you will need to edit the
internal interface.
Under DHCP Server, expand Advanced. Create a new entry in the MAC Reservation + Access Control list that
reserves an IP address within the DHCP range for the device's MAC address.
6. Results
Connect to the wireless network with a device that is a member of the device group. The device should be able to
connect and allow Internet access.
Connection attempts from a device that is not a group member will fail.
Go to FortiView > All Sessions and view the results for now. Filter the results using the reserved Source IP (in the
example, 10.10.1.12), to verify that it is being used exclusively by the wireless device.
For further reading, check out Managing “bring your own device” in the FortiOS 5.4 Handbook.
There is always an underlying assumption that system administrators know what is passing through their networks.
While this may be true most of the time, there are always the old truisms about what happens when you make
assumptions. Sometimes it’s the system administrators themselves making this assumption. To help correct any
differences between assumptions and reality, the feature “Policy Learning” was introduced in FortiOS 5.4.1. Its purpose
is to help inform sysadmins what is actually moving through their networks.
Policy Learning is very simple to set up. All it takes is a simple mouse click to choose the new option and enable the
feature on an individual firewall policy. It is however, worth going over how to use the feature and to know what is going
on in the background. And just as important, is going over why you should be using this feature.
Before getting into the details, it should be pointed out that because this feature requires a minimum level of logging
capabilities, it is only available on FortiGates with hard drives that can be used for logging. Smaller models may not be
able to use this feature. It some cases it is best to check in advance. An interesting example is the FortiGate 100 series.
There is a small hard drive in the “100” units that deemed acceptable for logging in 5.2, but not in 5.4. If logging to the
hard drive was enabled in 5.2 and then the unit was upgraded to 5.4, the Learning Report would be available. The
challenge appears when you attempt to enable logging after the unit has been upgraded to 5.4. The option no longer
exists, so even though you can enable a Learning Policy you would not be able to view the Learning Report.
Recently, the hard drive issue in FortiGates became easier to address. In the more recent models, such as the “E”
series, if the model number ends in a “0” it does not have an appropriate hard drive. If it ends in “1” it does. Therefore, a
FortiGate 100E would not be useable for logging and therefore Learning Reports, but the FortiGate 101E would have a
suitable hard drive and thus be fine for logging and the Learning Reports.
The scenario
To keep things simple and generic, we will use the fictional working environment of an existing network that has just
installed a brand new FortiGate. To make it more fun we’ll say it’s your first day on the job at a brand new company.
This way we can be sure you haven’t developed any bad habits yet.
When installing a new FortiGate, the first policy set up is usually one that goes from the inside to the Internet with fairly
little in the way of restrictions. After all, first you want to make sure that you can connect to things before the access is
limited for policy reasons. Once you have verified that you have that first connection and that everyone can access the
Internet it is time to start locking things down. Wouldn’t it be nice to know which traffic you should be locking down,
which you should be letting through and which should be managed instead of prevented?
To make life easy for the purposes of this example, we will work on the premise that you have a little bit of time before
you have to complete and finalize all of your policies. Take that first policy, the one that most outbound traffic will be
going through. When it was first set up, the Action field was set to ACCEPT.
The options for this field are ACCEPT, DENY, LEARN , and IPsec.
l ACCEPT allows all match traffic to go through the policy.
l DENY drops all of the matching packets.
l IPsec is for setting up IPsec VPN policies.
The option that interests us now is LEARN .
As cool as it would be for the FortiGate to be the one doing the learning, the purpose of this particular option is to make
it easier for the system administrator to learn what sort of traffic is occurring on the network.
When the LEARN option is selected, a few things will be going on in the background.
The profiles
The first thing you are likely to notice is that all of the Security Profile options that you would normally see in the
configuration window will no longer be displayed. You don’t need them because a number of predefined, hard coded
profiles have been assigned to the policy for you.
These profiles:
l Are all flow-based
l Are static and cannot be changed
l Have SSL inspection disabled
l Are configured to monitor all the traffic that goes through the policy
Profiles not included are:
Monitoring the traffic is of little use unless the system administrator can make use of it. Once the learning policy has
been active sufficiently long enough to collect some useful information, reports built from the analyzed logs can be
viewed in an area of the Log and Reporting session set aside specifically for these reports. What is considered
“sufficiently long enough” will depend on which time frame of report you will want to look at. Just have the policy monitor
the traffic for a longer period of time than the scope of the report.
To get to the Learning Report Window, go to Log & Report and select Learning Report.
Here you can select whether you want a Full Report which includes all of the details or a Report Summary. You also
choose from the different time frames of
l the past 5 minutes
l the past hour
l the past 24 hours
Both the Full Report and the Report Summary will include, but with different levels of granularity, these topic headings:
l Deployment Methodology
l Test Details
l Start time
l End time
l Model
l Firmware
l Policy List
l Executive Summary
l Total Attacks Detected
l Top Application Category
l Top Web Category
l Top Web Domain
l Top Host by Bandwidth
l Host with Highest Session Count
l Security and Threat Prevention
l High Risk Applications
l Application Vulnerability Exploits
l Malware, botnets and Spyware/Adware
l At-Risk Devices and Hosts
l User Productivity
l Application Usage
l Top Application Categories
l Top Social Media Applications
l Top Video/Audio Streaming Applications
l Top Peer to Peer Applications
l Top Gaming Applications
l Web Usage
l Top Web Categories
l Top Web Applications
l Top Web Domains
Once you have this information you can perform the most important aspect of a system administrators role; make
informed decisions. It makes no sense to be configuring policies based upon what you think is happening on your
network. You may have a policy that locks down the usage of peer to peer traffic because you’re worried about people
using the company bandwidth to download their torrents, because that’s what happened at the last place you were at.
Trouble is at this new place nobody cares about torrents because there spending all of their time playing Facebook
games.
This is the scenario for one policy, going in one direction. Every time a new policy is set up it is worth spending an hour
or a day to find out what is going through that policy before determining what restrictions are necessary to put on it. Not
only is it a good idea to discover the different ways in which policies are being used for unintended purposes, but it is
also good to verify that policies are being used for the intended purpose. If you set up a policy specifically to manage the
traffic between some internal servers and a third party service on the Internet, it’s worth your time to verify that the
intended traffic is going through that policy and not another one.
In order to be an effective system administrator it helps to have current and actual data to base decisions on.
Once you have a realistic idea what is going through your network you can start to make plans on how to manage that
traffic. The intended traffic should go through, but do you just allow it and forget about it or do you monitor it? As for the
less desirable traffic, do you block it, schedule it for specific time periods or do you set up quotas for it? Some choices
will be easier than others. For malicious traffic or traffic that is against organizational policy, the decision has already
been made. For traffic that isn’t dangerous, other than to productivity, there may need to be some discussions with
stake holders and those with appropriate levels of authority.
Maintenance
This feature doesn’t have to be only for new policy configurations. Like any other complex system, network
environments evolve over time. The traffic that was captured when you were first setting up the policy may have also
changed over time. It could be because new people are now on the network, the network configuration has changed or
there are new roles for people and devices on your network. As part of your maintenance plan set aside some time for
re-learning what traffic is going through your policies so that you can update your policies accordingly.
Because the profiles that are used in the learning mode only monitor and do not block anything, it is only recommended
that they be used on outbound policies or policies between segments of the internal network. The time an unsecured
system is available to the Internet without an attempt by someone trying to compromise it is measured in seconds. If
you are going to set up learning on an incoming policy make sure that
In this recipe, you will use Application Control to monitor application traffic on your network and then selectively block
unwanted traffic. Peer-to-peer (P2P) traffic is blocked in this example.
Go to System > Feature Select and ensure that Application Control and Multiple Security Profiles are enabled.
The default Application Control profile is set to monitor all applications except for Unknown pplications. You will use
this profile to monitor traffic and identify any applications that should be blocked.
Go to Security Profiles > Application Control and view the default profile.
Confirm that all Categories are set to Monitor with the exception of Unknown Applications.
Go to Policy & Objects > IPv4 Policy and edit the policy that allows connections from the internal network to the
Internet.
Under Security Profiles, turn on Application Control and use the default profile.
To inspect all traffic, SSH inspection must be set to deep-inspection profile. Using the deep-inspection profile may
cause certificate errors. See Preventing certificate warnings on page 445 for more information.
Go to FortiView > Applications and select the now view to display network traffic flowing through your FortiGate
listed by application.
You can see P2P traffic occurring in your network.
Double-click any application to view drilldown information, including traffic sources, traffic destinations, and information
about individual sessions.
In step 4, Application Control detected traffic from BitTorrent, a P2P downloading application. In this step, you create an
Application Control profile to block all P2P applications.
Go to Security Profiles > Application Control and create a new profile.
Set the P2P category to Block.
Go to Policy & Objects > IPv4 Policy and edit the policy that allows connections from the internal network to the
Internet.
Set Application Control to use the new profile.
7. Results
Attempt to visit the BitTorrent site. A FortiGuard warning message will appear, stating that the application was blocked.
Application Control uses flow-based inspection; if you apply an additional security profile to your traffic that is proxy-
based, the connection will simply timeout rather than display the warning message.
Test the P2P blocking by attempting to use the BitTorrent application. Traffic blocked.
To view information about the blocked traffic, go to FortiView > Applications, select the 5 minutes view, and filter
the traffic by Security Action: Blocked.
For further reading, check out Application control in the FortiOS 5.4 Handbook.
Netflow Templates
Netflow is a networking feature introduced by Cisco to collect and export information about traffic flow through routers.
IPFIX (Internet Protocol Flow Information Export) is the standardized Internet Protocol based on NetFlow version 9. The
standard requirements for IPFIX are outlined in RFC 3197 and its basic specifications and other information are
documented in RFC 5103, RFC 6759 and RFC 7011 through RFC 7015.
As of FortiOS 5.4.x, the firmware supports Netflow 9.0. In order to effectively use Netflow, it helps to have a reference
for the supported Netflow templates. The template parameters have been included in the listed tables.
Name ID Description
Scope Fields
Data Fields
Scope Fields
Data Fields
ID 258 – IPV4
Data Fields
ID 259 – IPV6
Data Fields
ID 260 – ICMP4
Data Fields
16 IP_DST_ADDR IP_DST_ADDR(12) 4
ID 261 – ICMP6
Data Fields
ID 262 – IPV4_NAT
Data Fields
21 postNAPTDestinationTransportPort postNAPTDestinationTransportPort 2
(228)
ID 263 – IPV6_NAT
Data Fields
13 Unknown(65) Unknown(65) 2
21 postNAPTDestinationTransportPort postNAPTDestinationTransportPort 2
(228)
ID 264 – IPV4_AF_NAT
Data Fields
13 Unknown(65) Unknown(65) 2
21 postNAPTDestinationTransportPort postNAPTDestinationTransportPort 2
(228)
ID 265 – IPV6_AF_NAT
Data Fields
21 postNAPTDestinationTransportPort postNAPTDestinationTransportPort 2
(228)
ID 266 – ICMPV4_NAT
Data Fields
20 postNAPTDestinationTransportPort postNAPTDestinationTransportPort 2
(228)
ID 267 – ICMPV6_NAT
Data Fields
20 postNAPTDestinationTransportPort postNAPTDestinationTransportPort 2
(228)
ID 268 – ICMPV4_AF_NAT
Data Fields
20 postNAPTDestinationTransportPort postNAPTDestinationTransportPort 2
(228)
ID 269 – ICMPV6_AF_NAT
Data Fields
20 postNAPTDestinationTransportPort postNAPTDestinationTransportPort 2
(228)
For a list of field type definitions see Table 6 on the Cisco Whitepaper found here.
In this recipe, one user is temporarily allowed to override a web filter profile in order to access sites that would otherwise
be blocked. Web filtering blocks the Bandwidth Consuming category for all users, except those who can override the
filter.
This recipe only works for FortiGates operating in proxy-based inspection mode.
Go to System > Feature Select to enable Web Filter and Multiple Security Profiles.
Apply changes if necessary.
Go to User & Device > User Groups. Create a new group for users who can override web filtering (in this example,
web-filter-override).
Go to User & Device > User Definition to create two users (in this example, ckent and bwayne).
Go to Policy & Objects > IPv4 Policy to edit the policy that allows connections from the internal network to the
Internet.
Set Source all, bwayne, and web-filter-override.
Under Security Profiles, enable Web Filter and select the block-bandwidth-consuming profile.
5. Results
Browse to youtube.com again, this time authenticating the ckent account. You can access the website until the override
expires.
For further reading, check out the Web Filter chapter in the FortiOS 5.4 Handbook.
In this recipe, you will prevent users from receiving a security certificate warning when your FortiGate applies full SSL
inspection to incoming traffic.
When full SSL inspection is used, your FortiGate impersonates the recipient of the originating SSL session, then
decrypts and inspects the content. The FortiGate then re-encrypts the content, creates a new SSL session between the
FortiGate and the recipient by impersonating the sender, and sends the content to the end user. This is the same
process used in “man-in-the-middle” attacks, which is why a user’s device may show a security certificate warning.
For more information about SSL inspection, see Why you should use SSL inspection.
Often, when a user receives a security certificate warning, they simply select Continue without understanding why the
error is occurring. To avoid encouraging this habit, you can prevent the warning from appearing in the first place.
There are two methods for doing this, depending on whether you are using your FortiGate’s default certificate or using
a self-signed certificate.
All FortiGates have a default certificate that is used for full SSL inspection. This certificate is also used in the default
deep-inspection profile. To prevent your users from seeing certificate warnings, you can install this certificate on your
users’ devices.
If you have the right environment, you can distribute the certificate and have it installed automatically.
Run the following CLI command to make sure that your SSL certificate is unique to your FortiGate:
exec vpn certificate local generate default-ssl-ca
Go to Security Profiles > SSL/SSH Inspection. Use the dropdown menu in the top right corner to select deep-
inspection, the profile used to apply full SSL inspection.
The default FortiGate certificate is listed as the CA Certificate. Select Download Certificate.
The above browsers use the operating system’s certificate store for Internet browsing. If your users will be using these
applications, you must install the certificate into the certificate store for your OS.
If you are using Windows 7/8/10, double-click on the certificate file and select Open. Select Install Certificate to
launch the Certificate Import Wizard.
Use the wizard to install the certificate into the Trusted Root Certificate Authorities store. If a security warning
appears, select Yes to install the certificate.
If you are using Mac OS X, double-click on the certificate file to launch Keychain Access.
Locate the certificate in the Certificates list and select it. Expand Trust and select Always Trust. If necessary, enter
the administrative password for your computer to make this change.
If you have the right environment, the certificate can be pushed to your users’ devices. However, if Firefox is used, the
certificate must be installed on each individual device, using the instructions below.
Firefox has its own certificate store. To avoid errors in Firefox, then the certificate must be installed in this store, rather
than in the OS.
Go to Tools > Options > Advanced or Firefox > Preferences > Advanced and find the Certificates tab.
Select View Certificates, then select the Authorities list. Import the certificate and set it to be trusted for website
identification.
4. Results
Before installing the certificate, an error message would appear in the browser when a site that used HTTPS was
accessed (the example shows an error message appearing in Firefox).
After you install the certificate, you should not experience a certificate security issue when you browse to sites on which
the FortiGate unit performs SSL content inspection.
If you view information about the connection, you will see that it is verified by Fortinet.
In this method, a self-signed certificate is created using OpenSSL. This certificate will then be installed on the FortiGate
for use with SSL inspection.
In this recipe, OpenSSL for Windows version 0.9.8h-1 is used.
If necessary, download and install Open SSL. Make sure that the file openssl.cnf is located in the BIN folder for
OpenSSL.
Using Command Prompt (CMD), navigate to the BIN folder (in the example, the command is cd
c:\OpenSSL\openssl-0.9.8h-1-1bin\bin.
Generate an RSA key with the following command:
OpenSSL genrsa -aes256 -out fgcaprivkey.pem 2048 -config openssl cnf
This RSA key uses AES 256 encryption and a 2058-bit key.
When prompted, enter a pass phrase for encrypting the private key.
Use the following command to launch OpenSSL, submit a new certificate request, and sign the request:
openssl req - new -x509 -days 3650 -extensions v3_ca -key fgcaprivkey.pem -out fgcacert.pem -
config openssl.cnf
The result is a standard x509 binary certificate that is valid for 3,650 days (approx. 10 years)
When prompted, re-enter the pass phrase for encryption, then enter the details required for the certificate request, such
as location and organization name.
Two new files have been created: a public certificate (fgcacert.pem) and a private key (in the example,
fgcaprivkey.pem).
Go to System > Feature Select. Under Additional Features, enable Certificates and Apply the changes.
To use your certificate in an SSL inspection profile go to Security Profiles > SSL/SSH Inspection. Use the
dropdown menu in the top right corner to select deep-inspection, the profile used to apply full SSL inspection.
The above browsers use the operating system’s certificate store for Internet browsing. If your users will be using these
applications, you must install the certificate into the certificate store for your OS.
If you are using Windows 7/8/10, double-click on the certificate file and select Open. Select Install Certificate to
launch the Certificate Import Wizard.
Use the wizard to install the certificate into the Trusted Root Certificate Authorities store. If a security warning
appears, select Yes to install the certificate.
If you are using Mac OS X, double-click on the certificate file to launch Keychain Access.
Locate the certificate in the Certificates list and select it. Expand Trust and select Always Trust. If necessary, enter
the administrative password for your computer to make this change.
If you have the right environment, the certificate can be pushed to your users’ devices. However, if Firefox is used, the
certificate must be installed on each individual device, using the instructions below.
Firefox has its own certificate store. To avoid errors in Firefox, then the certificate must be installed in this store, rather
than in the OS.
Go to Tools > Options > Advanced or Firefox >Preferences > Advanced and find the Certificates tab.
Select View Certificates, then select the Authorities list. Import the certificate and set it to be trusted for website
identification.
6. Results
Before installing the certificate, an error message would appear in the browser when a site that used HTTPS was
accessed (the example shows an error message appearing in Firefox).
After you install the certificate, you should not experience certificate errors when you browse to sites on which the
FortiGate unit performs SSL content inspection.
If you view information about the certificate in the browser, you will see that your self-signed certificate is used.
In this recipe, you will keep files containing sensitive information from leaving your network. To do this, criteria for
retaining files are created and applied in a Data Leak Prevention (DLP) security profile. This example applies DLP to
retain Windows executable (.exe) files and files matching a specific file name pattern. Note: DLP can only be configured
for FortiGate units in proxy-based inspection.
Go to System > Feature Select and confirm that DLP and Multiple Security Profiles are enabled.
Go to Security Profiles > Data Leak Prevention. In the Filter list, select Create New.
Set the filter to look for Files. Select Specify File Types and set File Types to Executable (exe).
Set Examine the Following Services to all the services required by your network.
Go to Policy & Objects > IPv4 Policy and edit your Internet-access policy.
Under Security Profiles, enable DLP Sensor and set it to use the new profile.
SSL Inspection is automatically enabled. Set it to use the deep-inspection profile to ensure that DLP is applied to
encrypted traffic. Using the deep-inspection profile may cause certificate erros. See Preventing certificate warnings on
page 445 for more information.
Under Logging Options, enable Log Allowed Traffic and select Security Events.
4. Results
Attempt to send either an .exe file or a file that fits the file naming pattern blocked in step 2. Use a protocol that the DLP
filter is set to examine. For example, send a file called securityleak.pdf via email or WeTransfer. Depending on which
protocol is used, the attempt will either be blocked by the FortiGate or it will timeout.
Go to FortiView > All Sessions and select the 24 hours view for information about the blocked session. Note that
the Security Event identified is DLP.
For further reading, check out Data leak prevention in the FortiOS 5.4 Handbook.
In this recipe, you will use a Web Application Firewall profile to protect a server that is running a web application, such
as web mail. In this example, the default profile will be targeted to block SQL injection attempts, as well as generic
attacks.
Web Application Firewall is only available when Inspection Mode is Proxy-based.
Go to System > Feature Select and enable Web Application Firewall. Select Show More and enable Multiple
Security Profiles.
Apply your changes.
Web Application Firewall profiles are created with a variety of options, called Signatures and Constraints. Once these
options are enabled, Action can be set to Allow, Monitor, or Block, and Severity can be set to High, Medium, or
Low.
You can also use a Web Application Firewall profile to enforce an HTTP method policy, which controls the HTTP
method allowed when accessing websites that match the specified pattern.
Go to Security Profiles > Web Application Firewall and edit the default profile.
In this example, the signatures for SQL Injection (Extended) and Generic Attacks (Extended) have been enabled,
with the Action set to Block and Severity set to High.
Trojans and Known Exploits are also blocked by default.
Go to Policy & Objects > IPv4 Policy and edit the policy that allows access to the web server.
Under Security Profiles, enable Web Application Firewall and set it to use the default profile. Set the appropriate
Proxy Option and set SSH Inspection to use the deep-inspection profile.
4. Results
Use the following URL to simulate an attack on your web server, substituting the IP address of your server:
http:///<server IP>/index.php?username=1'%20or%20'1'%20=%20'1&password=1'%20or%20'1'%20=%20'1
An error message appears, stating that the web application firewall has blocked the traffic.
5. Offloading to a FortiWeb
If you have a FortiWeb, you may be able to offload the functions of the Web Application Control to your FortiWeb. To
find out if this option is available, refer to the FortiOS or FortiWeb Release Notes for information about device
compatibility.
Go to System > External Security Devices and enable HTTP Service. Enter your FortiWeb’s IP address.
If necessary, enable Authentication and enter the FortiWeb’s password.
In this recipe, you will protect a web server by connecting it to your FortiGate's DMZ network. In addition to protecting
the web server, the DMZ also protects the rest of the network. A hole in the network protection must be made to allow
outside users to access the web server. This hole creates a potential vulnerability that is mitigated by the DMZ.. A DMZ
network (from the term ‘demilitarized zone') is a secure network, protected by the FortiGate, that only grants access if it
has been explicitly allowed. In this example the DMZ network uses a private subnet and allows access to a web server
using different addresses for internal and external users, while preventing access from the web server to the internal
network if the web server is compromised.
A WAN-to-DMZ firewall policy with a Virtual IP (VIP) uses source NAT to hide the DMZ address of the web server,
allowing external users to access the web server using a public IP address (in this example, 172.20.120.22). An internal
to DMZ firewall policy allows internal users to access the web server using its DMZ address (10.10.10.22). Both of these
firewall policies only allow access to the web server using HTTP and HTTPS. No other access is allowed. For this recipe
to work the web server must be properly configured with its default route pointing at the FortiGate's DMZ interface.
Go to Policy & Objects > Virtual IPs. Create two virtual IPs: one for HTTP access and one for HTTPS access.
Each virtual IP has the same address, mapping from the Internet to the DMZ interface. The difference is the port for
each traffic type: port 80 for HTTP and port 443 for HTTPS.
In this example the Internet address of the web server is 172.20.120.35.
Go to Policy & Objects > IPv4 Policy. Create a firewall policy to allow HTTP and HTTPS traffic from the Internet to
the web server. Add both VIPs as the destination address.
Do not enable NAT. Enabling the NAT option actually enables source NAT which is not required for this configuration
since the VIPs are added to perform destination NAT. If you do enable source NAT the configuration will still work but all
traffic received by the web server will have the same source IP address so you will loose information about your website
users.
You can also enable logging for all sessions to make it easier to test the configuration.
Create a second firewall policy to allow HTTP and HTTPS traffic from the internal network to the web server.
Do not enable NAT. If you enable source NAT the configuration will still work but all traffic received by the web server
will have the same source IP address so you will loose information about your website users.
You can also enable logging for all sessions to make it easier to test the configuration.
4. Results
Internet users and internal network users can access the web server by browsing to the web server's Internet address (in
this example, http://172.20.120.35 and https://172.20.120.35). Internal users can also access the web server using its
DMZ address (in this example, http://10.10.10.22 and https://10.10.10.22).
Since only HTTP and HTTPS are enabled, the web server is not accessible using other protocols (such as FTP) and you
also cannot ping the web server from the Internet or from the internal network.
Go to FortiView Policies to see current sessions for each firewall policy. If you add a filter to just show policies with the
DMZ interface as the destination interface you will see sessions from the Internal network to the web server and from
the Internet to the web server.
Double-clicking on the Internet to DMZ web server session shows sessions from Internet addresses (in the example
172.20.120.100) and from the internal network (192.1681.20).
For further reading, check out Firewall in the FortiOS 5.4 Handbook. Also, see this Knowledge Base article for
information about improving VIP security.
This recipe uses a new FortiGuard feature: the Botnet C&C (command and control) database to protect your network
from Botnet C&C attacks.
For this recipe, you will create a new DNS Filter Profile called Botnet&Facebook, block access to all known C&C
addresses, and block access to the Social Networking FortiGuard category. In addition, you will enhance this with a
Static Domain Filter in order to block access to www.facebook.com, and all of its affiliated subdomains.
For this recipe to work, your device must be licensed for the FortiGuard Web Filtering service. If you are using FortiOS
5.4.0 or 5.4.1, DNS filtering is only available when Inspection Mode is Proxy-based.
Go to System > Feature Select, and enable DNS Filter under Security Features. Select Apply.
2. Creating the DNS Filter Profile and enabling Botnet C&C database
Go to Security Profiles > DNS Filter, and create a new profile called Botnet&Facebook.
Right-click and block the Social Networking category from the FortiGuard category based filter table.
In the DNS Filter Profile, enable Domain Filter under Static Domain Filter. You will now be able to add domains of
your choosing.
Go to Policy & Objects > IPv4 Policy, and create a firewall policy that allows Internet access.
Set Incoming Interface to the internal interface and set Outgoing Interface to the external interface.
Set Source to all and set Destination Address to all.
Set Schedule to always, set Services to ALL, and make sure NAT is enabled.
Under Security Profiles, enable DNS Filter and select the Botnet&Facebook DNS Filter profile — this will
automatically enable Proxy Options.
5. Results
To confirm that the DNS Filter Profile has been added, go to Policy & Objects > IPv4 Policy. The policy will now
have the DNS filter icon in the Security Profiles column.
To confirm that the filter is working correctly, open a browser and attempt to browse to www.facebook.com. The DNS
request will be blocked.
To confirm that the known Botnet C&C feature is working correctly, browse to a known Botnet site — the example is
nateve.us. Again, the DNS request will be blocked.
Note that the blocked pages may look different on other web browsers.
In this example, you will create a WAN link interface that provides your FortiGate unit with redundant Internet
connections from two Internet service providers (ISPs). The WAN link interface combines these two connections into a
single interface.
This example includes weighted load balancing so that most of your Internet traffic is handled by one ISP.
Connect your ISP devices to your FortiGate so that the ISP you wish to use for most traffic is connected to WAN1 and
the other connects to WAN2.
You will not be able to add an interface to the WAN link interface if it is already used in the FortiGate's configuration, so
you must delete any security policies or routes that use either WAN1 or WAN2. Traffic will not be able to reach WAN1 or
WAN2 through the FortiGate after you delete the existing policies.
Many FortiGate models include a default Internet access policy that uses WAN1. This policy must also be deleted.
Go to Policy & Objects > IPv4 Policy and delete any policies that use WAN1 or WAN2.
Go to Network > Static Routes and delete any routes that use WAN1 or WAN2.
Under Load Balancing Algorithm, select Volume as the type. This will allow you to prioritize the wan1 interface so
that more traffic uses it. For the weight, set wan1 to 3 and set wan2 to 1.
The weight settings will cause 75% of traffic to use WAN1, with the remaining 25% using WAN2.
To help analyze the effectiveness of the algorithm selected, the WAN Links Usage graph shows you the volume and
bandwidth usage.
You can optionally configure Health Check to verify the health and status of the links that make up the virtual WAN
link. Health Check is only available via the CLI. Go to Dashboard > CLI and enter the following commands:
Scroll down to view the Logging Options. To view the results later, turn on Log Allowed Traffic and select All
Sessions.
7. Results
Browse the Internet using a computer on the internal network and then go to FortiView > All Sessions.
Make sure that the Destination Interface column is shown. If it's not, right-click on the top menu row to add it to the
menu.
The log shows traffic flowing through both WAN1 and WAN2.
Go to Network > Interfaces and disable the wan1 port. Then browse the Internet from the internal network.
Go back to FortiView > All Sessions and the results should show that traffic is only flowing through wan2, until you
enable WAN1 again.
For further reading, check out Redundant Internet installation in the FortiOS 5.4 Handbook.
In this recipe, you will set up sandboxing to send suspicious files to a FortiSandbox Appliance for further inspection. The
FortiSandbox scans for threats that can get past other detection methods, using Windows virtual machines (VMs) to test
suspicious files in isolation from your network.
You will also configure your FortiGate to automatically receive signature updates from FortiSandbox and add the
originating URL of any malicious file to a blocked URL list. Finally, you will configure FortiClient to use extended
scanning that includes FortiSandbox. This feature is currently only available in FortiClient 5.4 for Windows.
There was a change in the FortiClient security profile from FOS 5.4 to FOS 5.4.1. The VPN, Advanced and Mobile tabs
do not appear in FOS versions 5.4.1 and above. Features emphasizing compliance of the endpoint devices have been
added. These enhancements facilitate integration with the Cooperative Security Fabric (called “Security Fabric” in FOS
5.6). Read more in the What’s New for Security Profiles 5.4.1.
Connect the FortiSandbox to your FortiGate as shown in the diagram, so that port 1 and port 3 on the FortiSandbox are
on different subnets.
FortiSandbox port 3 is used for outgoing communication triggered by the execution of the files under analysis. It is
recommended to connect this port to a dedicated interface on your FortiGate (in the example, port 15), to protect the
rest of the network from threats currently being investigated by the FortiSandbox.
FortiSandbox port 3 must be able to connect to the Internet. On the FortiGate, go to Policy & Objects > IPv4 Policy
and create a policy allowing connections from the FortiSandbox to the Internet (using the isolated interface on the
FortiGate mentioned above).
On the FortiSandbox, go to System > Network > Static Routing and add static routes for both port 1 and port 3.
The static route for port 3 must have the Destination/IP Mask0.0.0.0/0.0.0.0, while port 1 is assigned the
Destination/IP Mask for traffic in the local network.
Once the FortiSandbox has access to the Internet through port 3, it will begin to activate its VM licenses.
Before continuing with this recipe, wait until a green arrow shows up beside Windows VM in the FortiSandbox’s
System Information widget, found at System > Status. This indicates that the VM activation process is complete.
On the FortiGate, go to System > External Security Devices. Select Enable Sandbox Inspection and select
FortiSandbox Appliance.
Set the IP Address (in the example, 172.20.121.128) and enter a Notifier Email, where notifications and reports will
be sent.
If you select Test Connectivity, the Status shows as Service is not configured because the FortiGate has not been
authorized to connect to the FortiSandbox.
On the FortiSandbox, go to File-based Detection > File Input > Device. Edit the entry for the FortiGate.
Under Permissions, enable Authorized.
On the FortiGate, go to System > External Security Devices and for FortiSandbox select Test Connectivity. The
Status now shows that Service is online.
Go to Security Profiles > Web Filter and edit the default profile.
Under Static URL Filter, enable Block malicious URLS discovered by FortiSandbox.
If the FortiSandbox discovers a threat, the URL that threat came from will be added to the list of URLs that will be
blocked by the FortiGate.
Go to Security Profiles > FortiClient Profiles and edit the default profile.
Under AntiVirus, enable Realtime Protection, then enable Scan Downloads, followed by Scan with
FortiSandbox. Enter the IP of the FortiSandbox.
Decide if you want to wait for FortiSandbox results before sending files to the PC running FortiClient, or if you want
downloaded files to be sent at the same time as they are being scanned by FortiSandbox.
Enable Use FortiSandbox signatures to make sure new virus signatures and blocked URLs from the FortiSandbox
are added to FortiClient’s databases.
This profile will be pushed to any device running FortiClient that is registered to your FortiGate. These settings can also
be configured from within FortiClient’s AntiVirus settings.
Go to Policy & Objects > IPv4 Policy and view the policy list. If a policy has AntiVirus and web filtering scanning
applied, the profiles will be listed in the Security Profiles column.
If scanning needs to be added to any security policy (excluding the Implicit Deny policy) select the + button in the
Security Profiles column for that policy, then select the default AntiVirus Profile, the default Web Filter Profile,
the appropriate Proxy Options, and the deep-inspection profile for SSL Inspection Options (to ensure that
encrypted traffic is inspected). Then select OK.
7. Results
If your FortiGate discovers a suspicious file, it will now be sent to the FortiSandbox. To view information about the files
that have been sent on the FortiGate, go to FortiView > FortiSandbox to see a list of file names and current status.
You can also view results on the FortiSandbox by going to System > Status and viewing the Scanning Statistics
widget. There may be a delay before results appear on the FortiSandbox.
Open FortiClient using a Windows PC on the internal network. Make sure it is registered to your FortiGate.
Go to AntiVirus > Realtime Protection Enabled and edit the settings. You will see that the Realtime Protection
settings match the FortiClient Profile configured on the FortiGate. These settings cannot be changed using FortiClient.
On the FortiGate, go to Monitor > FortiClient Monitor. Select the FortiClient device, then select Quarantine.
The PC is now quarantined by FortiClient and cannot connect to the Internet or other network devices.
A message appears in FortiClient, telling the user to contact the system administrator.
FortiClient cannot be shutdown on the PC. It can also not be uninstalled or unregistered from the FortiGate.
If a FortiClient device attempts to download a file that FortiSandbox discovers is malicious, the FortiSandbox notifies
the FortiGate. The administrator can take action to quarantine the device. When a quarantine is in effect, FortiClient
cuts off other network traffic from the device directly, preventing it from infecting or scanning the local network. When a
device is under quarantine, FortiClient cannot be shutdown or uninstalled. A user is also unable to unregister from the
FortiGate that quarantined them, or register to another FortiGate unit. A quarantine can only be lifted by the
administrator of the FortiGate where the FortiClient device is registered.
In this example you will set up a WiFi network with a FortiGate managing a FortiAP in Bridge mode.
You can configure a FortiAP unit in either Tunnel or Bridge mode. When a FortiAP is in Bridge mode, the Ethernet and
WiFi interfaces are connected (or bridged), allowing wired and wireless networks to be on the same subnet. Tunnel
mode is the default mode for a FortiAP. A FortiAP in Tunnel mode uses a wireless-only subnet for wireless traffic.
For information about using a FortiAP in Tunnel mode, see Setting up WiFi with a FortiAP on page 512.
Go to WiFi & Switch Controller > Managed FortiAPs. The FortiAP is listed. It may take a few minutes for the
FortiAP to appear. The device is not yet authorized, as indicated by the in the State column.
By default, the FortiGate adds newly discovered FortiAPs to the Managed FortiAPs list but does not authorize them.
You can disable this in the CLI. See Deploying Wireless Networks.
After a few minutes, hit the Refresh button and will appear to tell you that the device is authorized.
2. Creating an SSID
Go to WiFi & Switch Controller > SSID and create a new SSID.
Set Traffic Mode to Local bridge with FortiAP's Interface.
Configure the WiFi Settings as you would for a regular wireless network and set a secure Pre-shared Key.
Go to WiFi & Switch Controller > FortiAP Profiles and create a new profile.
Set Platform to the FortiAP model you are using (FAP11C ).
Set SSID to use the new SSID. Set LAN Port mode to bridge to the new SSID.
Go to WiFi & Switch Controller > Managed FortiAPs and edit the FortiAP. Set FortiAP Profile to the new profile.
You have the option to enter a name for the FortiAP (MyFortiAP in this example). If you don't, the FortiAP will be
identified by its serial number.
4. Results
Connect to the SSID with a wireless device. After a connection is established, you can browse the Internet using the
wireless network configured in this recipe.
Go to FortiView > All Sessions and observe the wireless activity. Hover over the Device column to see details.
For further reading, check out Deploying Wireless Networks in the FortiOS 5.4 Handbook.
If you have purchased FortiGuard services and registered your FortiGate, it should automatically connect to FortiGuard
and display license information about your services. In this example, you will verify whether the FortiGate unit is
communicating with FortiGuard. If the FortiGate cannot connect, you will troubleshoot the connection.
l : the FortiGate unit cannot connect to FortiGuard network or the FortiGate unit is not registered. For information
about registering your FortiGate, see the recipe FortiGate registration and basic settings on page 208.
l : the subscription has not been activated or is expired. To add/renew a subscription, go to Fortinet Support.
You can also view FortiGuard license information by going to System > FortiGuard.
If a service that you subscribe to is shown as unavailable, there are several things you can do to troubleshoot the
connection.
Go to Network > DNS and ensure that the primary and secondary DNS servers are correct and the FortiGate is
Connected to FortiGuard.
To test if your DNS can reach FortiGuard, go to the Dashboard and enter the following command into the CLI
Console:
execute ping guard.fortinet.net
If the connection is successful, the CLI Console should display a similar output as the example below:
PING guard.fortinet.net (208.91.112.198): 56 data bytes
64 bytes from 208.91.112.198: icmp_seq=0 ttl=59 time=60.0 ms
64 bytes from 208.91.112.198: icmp_seq=1 ttl=59 time=50.0 ms
64 bytes from 208.91.112.198: icmp_seq=2 ttl=59 time=50.0 ms
64 bytes from 208.91.112.198: icmp_seq=3 ttl=59 time=50.0 ms
64 bytes from 208.91.112.198: icmp_seq=4 ttl=59 time=50.0 ms
--- guard.fortinet.net ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max = 50.0/52.0/60.0 ms
Under Filtering, check Filtering Services Availability. If you don't see a , select Check Again.
If FortiGuard services can still not be reached, your ISP may be blocking access to port 53 (used for DNS). Change the
FortiGuard Filtering Port to the alternate port (8888). Select Apply and see if the services become available. If you
are updating FortiGuard using a FortiManager, the FortiGuard Filtering Port can also be 80.
If your FortiGate is still unable to connect to FortiGuard, you can find more troubleshooting methods and other
information in the FortiGuard section of the FortiOS 5.4 Handbook.
3. Results
Go to the Dashboard and view the License Information widget. Any subscribed services should have a beside it.
Go to System > FortiGuard. Features and services you are subscribed to should have a beside it.
For further reading, check out FortiGuard in the FortiOS 5.4 Handbook.
In this recipe, you will set up a WiFi network with a FortiGate managing a FortiAP in Tunnel mode.
You can configure a FortiAP unit in either Tunnel mode or Bridge mode. Tunnel mode is the default mode for a FortiAP.
A FortiAP in Tunnel mode uses a wireless-only subnet for wireless traffic. When a FortiAP is in Bridge mode, the
Ethernet and WiFi interfaces are connected (or bridged), allowing wired and wireless networks to be on the same
subnet.
For information about using a FortiAP in Bridge mode, see Setting up a WiFi Bridge with a FortiAP on page 500.
Go to Network > Interfaces and edit the interface that will connect to the FortiAP (in this example, port 16).
Set Addressing Mode to Dedicate to Extension Device and set an IP/Network Mask.
Go to WiFi & Switch Controller > Managed FortiAPs. The FortiAP is listed. It may take a few minutes for the
FortiAP to appear. The device is not yet authorized, as indicated by the in the State column.
By default, FortiGate adds newly discovered FortiAPs to the Managed FortiAPs list but does not authorize them. You
can disable this in the CLI. See Deploying Wireless Networks.
After a few minutes, hit the Refresh button and will appear to tell you that the device is authorized.
2. Creating an SSID
Go to WiFi Controller > WiFi Network > SSID and create a new SSID.
Go to WiFi & Switch Controller > FortiAP Profiles and create a new profile.
Set Platform to the FortiAP model you are using (FAP11C in this recipe).
The SSID defaults to Automatically assign Tunnel-mode SSIDs. Your network is assigned.
Go to WiFi Controller > Managed Access Points > Managed FortiAPs and edit the FortiAP. Set FortiAP Profile
to use the new profile.
By default, the FortiGate assigns all SSIDs to this profile.
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. Confirm that NAT is
enabled.
5. Results
Connect to the SSID with a wireless device. After a connection is established, you are able to browse the Internet.
Go to FortiView > All Sessions to see the traffic allowed by the wireless policy.
For further reading, check out Configuring a WiFi LAN in the FortiOS 5.4 Handbook.
In this example, you will allow transparent communication between two networks that are located behind different
FortiGates at different offices using route-based IPsec VPN. The VPN will be created on both FortiGates by using the
VPN Wizard's Site to Site - FortiGate template.
In this example, one office will be referred to as HQ and the other will be referred to as Branch.
In the Authentication step, set IP Address to the IP of the Branch FortiGate (in the example, 172.20.120.135). After
you enter the gateway, an available interface will be assigned as the Outgoing Interface. If you wish to use a different
interface, select it from the drop-down menu.
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 (in the example, 5.5.5.5/24).
A summary page shows the configuration created by the wizard, including firewall addresses, firewall address groups, a
static route, and security policies.
In the Authentication step, set IP Address to the IP of the HQ FortiGate (in the example, 172.20.121.92). After you
enter the gateway, an available interface will be assigned as the Outgoing Interface. If you wish to use a different
interface, select Change.
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.10.10.1/24).
A summary page shows the configuration created by the wizard, including firewall addresses, firewall address groups, a
static route, 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 BringUp.
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 the Branch FortiGate's internal interface from the HQ's
internal network.
In this recipe, you will learn how to configure an SSL VPN portal for users with passwords that expire after two days.
Users will be warned after one day about the password expiring and will have one day to renew it.
If the users also have access to an IPsec VPN, the expiration time applies to that tunnel’s access as well, since the
passwords expire and not the tunnel itself.
The example uses local users but the password policy can be applied to any user. The password policy cannot be
applied to a user group.
This recipe involves some minor configuration in the CLI Console.
1. Go to User & Device > User Definition > Create New and create a new user via the Users/Groups Creation
wizard.
3. Enter contact information via Email Address. SMS information should be provided if required.
6. Go to User & Device > User Groups and create a user group that includes the newly created user.
1. Enter the CLI Console and configure a password policy using the following commands:
config user password-policy
edit "pwpolicy1"
set expire-days 2
set warn-days 1
next
end
By default, the start time for the password is set to the time the user was created.
3. Enable Tunnel Mode Client Options as required, ensure that you Enable Web Mode and click OK.
6. Under Tunnel Mode Client Settings, set Address Range to Automatically assign addresses. You can
Specify custom IP ranges.
7. Under Authentication/Portal Mapping, assign the newly created user group (“TempVPNGroup“) to the full-
access portal and Apply your changes.
1. Go to Policy & Objects > IPv4 Policy and add a security policy allowing access to the internal network through
the VPN tunnel interface.
3. Add a second security policy allowing access to the Internet through the VPN tunnel interface.
4. Include the newly created user group an enable NAT.
5. Results
When jsnow browses to the SSL VPN web portal, they are prompted to enter their username and password.
When the warning time is reached (see 2. Configuring and assigning the password policy on page 530), the user is
prompted to enter a new password. There is no warning that the user will expire for IPsec VPN, as there is no protocol
for that in IPsec Xauth.
However, when the expiration time is reached, the user will not be able to enter a new password and must contact the
administrator for assistance.
Go to Log & Report > VPN Events to see the SSL VPN alert labeled ssl-alert.
Highlight the alert message and click Details to see the log in greater detail, specifically under Action.
In this recipe, you will configure an SSL VPN tunnel that requires users to authenticate solely with a certificate. We will
configure a PKI peer object in order to search our LDAP using the certificate’s UserPrincipalName in order to determine
group memberships of the user. We will then be able to base our SSL VPN policies on LDAP group membership, without
the need to explicitly request the user’s LDAP credentials during the client VPN session establishment.
This recipe was tested with a Windows 2012R2 Active Directory acting as both the user certificate issuer, the certificate
authority and the LDAP server.
While it is possible to force explicit LDAP authentication for the user during VPN establishment, this cookbook article’s
goal is to offer a true “single-sign on” approach in which we use pre-established credentials (the user’s issued certificate)
while maintaining the ability to know what Active Directory groups the connecting user belongs to based on the
username found in the certificate.
Note that this article skims over the basics of SSL VPN configuration – refer to other more basic articles if you need a
refresher on the basic mechanics related to SSL VPN or other features found in this article.
1. Windows 10 certificate
While it is not the goal of this article to cover Microsoft’s Certificate Authority and its operation, suffice to note that our
test user (user1) has been issued a standard “User” template certificate for which he has enrolment permissions for.
In our case, we duplicated the standard “User” template and made certain that we have the User Principal Name
included in the subject name of the issued certificate – this is the user field we will be using to search LDAP during the
connection attempt.
For reference, UPN designates the format “user@domain”, with domain being the Active Directory domain.
Using our Microsoft Certificate Authority’s web interface, we request a “Web Server” type certificate and use the CSR
generated from FortiOS’s GUI to obtain a trusted certificate. Do note that “trusted” in this example is limited in scope to
the organization’s assets – you would use a public CA to generate a certificate for FortiOS if you expect non-corporate
assets to connect to the SSL VPN as those are unlikely to trust the Active Directory CA we are using in our example.
While the below process goes through the manual certificate request process, FortiOS is SCEP capable which can be
used to automate the certificate request process with a SCEP-compliant CA server (Microsoft CA does support SCEP).
Export the CA certificate from your CA using the available methods. In our case, we use the Windows CA web interface
to download our CA cert in BASE64 format.
The CA certificate now appears in the list of Certificates. Note that it is named “G_CA_Cert_1″ – keep that in mind as
we refer to this later in the article.
Next, we generate a CSR on FortiOS which we will use to obtain a signed certificate from our CA, again in our case the
Microsoft CA. The domain name used should match the domain name users will be connecting to using FortiClient and
is generally what resolves to the IP of the interface listening for SSL VPN.
Download the generated CSR, which is a text file containing the BASE64 certificate request.
We again use our Microsoft CA web interface to submit our CSR and obtain a certificate of type “Web Server”.
Finally, import that signed request as a local certificate on FortiOS to finalize our SSL VPN server certificate.
Our request is complete and our certificate is now usable. We will use this certificate later in our SSL VPN configuration.
As we will be validating incoming VPN requests using the UserPrincipalName found in the trusted certificates used by
clients, we need to define our LDAP server.
Go to User & Device > LDAP Servers and create a new LDAP server definition.
This definition is common, except for the fact that we will be using UserPrincipalName as our Common Name Identifier
– the UPN field is what we are extracting from the certificates and need to match to locate users in LDAP.
Next, head to the CLI. This is the only part of this article that requires a CLI definition.
Create a PKI “peer” object as shown. This is a relatively static object which will not require frequent visits to the CLI.
config user peer
edit "FORTIQC_CERTS"
set ca "G_CA_Cert_1"
set ldap-server "FORTIQC"
set ldap-mode principal-name
next
end
A PKI “peer” object is created in order to instruct FortiOS to match an incoming certificate’s UserPrincipalName to a
target LDAP server object, providing that certificate is signed by the designated CA and is valid. You will recognize the
G_CA_Cert_1 as the name of the CA certificate we imported earlier.
The “ldap-mode” parameter is important as it dictates that authentication is not explicit (the user does not need to pass
a username and password) and instead is based on validating that the UserPrincipalName found in the certificate does
exist. We will extend this in a moment to also request that the user be a member of a specific LDAP group.
4. Configuring a group
Next, we configure the group object that will assemble our previously configured LDAP and PKI objects together.
Go to User & Device > User groups and create a new group.
Add the PKI peer object previously created as a local member of the group.
Next add a remote group on the LDAP server and select the group of interest you need these users to be members of
using the LDAP browser window.
Finally, under Policy & Objects > IPv4 Policy create or modify your existing SSL VPN policies to incorporate your
new group.
7. Results
Our FortiClient is configured with the target hostname and local certificate issued to the user. Connecting to the VPN
requires neither username or password – only the user’s certificate.
Lets look at the output of “diag debug app fnbamd -1” while the user connects. We have shortened the output of the
diag in a few locations to focus on the important parts.
We can see the lookups being done to find the group memberships (3 groups total) of the user and that the correct
group being found results in a match.
We can also use “diag firewall auth list” to validate that a firewall user entry exists for our SSLVPN user and is part of the
right groups.
As a reference, fnbamd is short for “Fortinet Non-Blocking Authentication Management Daemon” and is the
process responsible for the vast majority of explicit authentication duties found in FortiOS.
MN140D-1 (root) # diag debug reset
diagnose debug
MN140D-1 (root) # diag debug app fnbamd -1
Debug messages will be on for 30 minutes.
[1590] cert_check_group_list-checking group type 1 group name 'FORTIQC_PKI_GrpCertAuth'
[1425] quick_check_peer-Cert subject 'CN = user1'
8. Logs
9. Summary
This article presented a technique allowing for “credential-less” VPN connectivity using certificates while maintaining the
ability to authorize access with policies that are based on LDAP groups. As a side note, this technique may not be
suitable to the levels of security requirements of all environments as it forgoes explicit authentication in addition to PKI
authentication. Your organization’s security versus ease-of-use requirements ultimately dictate the requirements.
This page contains tips to help you with common challenges for VPN. Tips are organized in two sections: Diagnose
commands and Common issues.
Diagnose commands
To display debug messages for SSL VPN, use the following command:
diagnose debug application sslvpn -1
This command enables debugging of SSL VPN with a debug level of -1. The -1 debug level produces detailed results.
This output verifies that SSL VPN debugging is enabled with a debug level of -1, and shows which filters are in place.
The output above indicates that debug output is disabled, so debug messages are not displayed. The output also
indicates that debugging isn’t enabled for any software systems.
To view the debug messages, log into the SSL VPN portal. The CLI displays debug output similar to the following:
FGT60C3G10002814 # [282:root]SSL state:before/accept initialization (172.20.120.12)
[282:root]SSL state:SSLv3 read client hello A (172.20.120.12)
[282:root]SSL state:SSLv3 write server hello A (172.20.120.12)
[282:root]SSL state:SSLv3 write change cipher spec A (172.20.120.12)
[282:root]SSL state:SSLv3 write finished B (172.20.120.12)
[282:root]SSL state:SSLv3 flush data (172.20.120.12)
Common issues
The following is a list of potential issues. The suggestions below aren’t exhaustive and may not reflect your network
topology.
l Go to VPN > SSL-VPN Settings and check the SSL VPN port assignment. Also check the Restrict Access
settings to ensure the host you are connecting from is allowed.
l Go to Policy > IPv6 policy) and make sure that the policy for SSL VPN traffic is configured correctly.
l Check the URL you are attempting to connect to. It should follow this pattern:
https://<FortiGate IP>:<Port>/remote/login
l Ensure that you are using the correct port number in the URL.
l Use a computer on the local network to connect to the VPN, rather than a remote connection.
l If you are using external authentication, create a local user and connect to the VPN using this local account.
Read the Release Notes to ensure that the version of FortiClient you are using is compatible with your version of
FortiOS.
You can export FortiClient debug logs by doing the following:
1. Go to File > Settings. Under the Logging section, enable Export logs.
2. Set the Log Level to Debug and select Clear logs.
3. Attempt to connect to the VPN.
4. Select Export logs after you receive the connection error.
A new SSL VPN driver was added to FortiClient 5.6.0 and later to resolve various SSL VPN connection issues. If your
FortiOS version is compatible, upgrade to use one of these versions.
In addition, latency or poor network connectivity can cause the default login timeout limit to be reached on the
FortiGate. In FortiOS 5.6.0 and later, the following commands allow a user to increase timers related to SSL VPN login.
config vpn ssl settings
set login-timeout 180 (default is 30)
set dtls-hello-timeout 60 (default is 10)
end
This issue can occur when there are multiple interfaces connected to the Internet (for example, SD-WAN). This can
cause the session to become “dirty.” To fix this, you must allow multiple interfaces to connect without issue.
If you are using a FortiOS 6.0.1 or later, use the following CLI command:
config system interface
edit <name>
set preserve-session-route enable
next
end
If you are using a FortiOS 6.0.0 or earlier, use the following CLI command:
config vpn ssl settings
set route-source-interface enable
end
You receive the following error message: "Unable to logon to the server. Your
user name or password may not be configured properly for this connection. (-
12)."
Make sure there is a interface by going to Monitor > Routing Monitor. Also, check the routing table on you computer
to ensure the routes for the VPN are added (use the command route print on Windows, or netstat -nr on
MacOS).
You can connect remotely to the VPN tunnel but are unable to access the
network resources
Verify that your firewall policy for SSL VPN traffic is configured correctly by going to Policy & Objects > IPv4 Policy
and making sure the source/destination addresses, user group, and destination interfaces are correct.
You can also use the command diagnose debug flow to get more information about network traffic. To learn
more about this command, see How to use debug flow to filter traffic.
Go to VPN > SSL-VPN Portals to make sure that the option to Limit Users to One SSL-VPN Connection at a
Time is disabled. This allows users to connect to the resources on the portal page while also connecting to the VPN
through FortiClient.
Go to VPN > SSL-VPN Portals and VPN > SSL-VPN Settings and make sure that the same IP Pool is used in VPN
Portal and VPN Settings to avoid conflicts. If there is a conflict, the portal settings are used.
Although many factors can contribute to slow throughput, one recommendation is to try is the FortiOS Datagram
Transport Layer Security (DTLS) tunnel option, available in FortiOS 5.4 and above.
DTLS allows the SSL VPN to encrypt the traffic using TLS and uses UDP at the transport layer instead of TCP. This
avoids retransmission problems that can occur with TCP-in-TCP.
To make sure that the DTLS tunnel is enabled on the FortiGate, use the following commands:
config vpn ssl settings
set dtls-tunnel enable
end
FortiClient 5.4.0 to 5.4.3 uses DTLS by default. FortiClient 5.4.4 and later uses normal TLS, regardless of the DTLS
setting on the FortiGate. To use DTLS with FortiClient, go to File > Settings and enable Preferred DTLS Tunnel.
In this example, you will allow remote users to access the corporate network using an SSL VPN, connecting either by
web mode using a web browser or tunnel mode using FortiClient. This allows users to access network resources, such
as the Internal Segmentation Firewall (ISFW) used in this example.
For users connecting via tunnel mode, traffic to the Internet will also flow through the FortiGate, to apply security
scanning to this traffic.
During the connecting phase, the FortiGate will also verify that the remote user's antivirus software is installed and up-
to-date.
Go to User & Device User Definition. Create a local user account for a SSL VPN user.
Go to User & Device > User Groups. Create a user group for SSL VPN users and add the new user account.
Go to VPN > SSL-VPN Portals. Edit the full-access portal. The full-access portal allows the use of tunnel mode
and/or web mode.
Make sure Enable Split Tunneling is not selected, so that all Internet traffic will go through the FortiGate. If you do
select Enable Split Tunneling, traffic not intended for the corporate network will not flow through the FortiGate or be
subject to the corporate security profiles. You will also have to set your corporate network's address as the Routing
Address.
Set Source IP Pools to use the default IP range SSLVPN_TUNNEL-ADDR1.
Under Predefined Bookmarks, select create new to add a new bookmark. Bookmarks are used as links to internal
network resources.
In the example, a bookmark is added to connect to a FortiGate being used as an ISFW, which can be accessed at
https://192.168.200.111.
Under Authentication/Portal Mapping, add the SSL VPN user group and map it to the full-access portal.
If necessary, map a portal for All Other Users/Groups.
Go to Policy & Objects > IPv4 Policy. Add a security policy allowing access to the internal network through the VPN
tunnel interface. Set a policy name that will identify what this policy is used for (in the example, SSL-VPN-internal)
Set Incoming Interface to ssl.root and Outgoing Interface to the local network interface. Select Source and set
Address to all and Source User to the SSL-VPN user group. Set Destination Address to the local network address,
Service to ALL, and enable NAT.
Configure any remaining firewall and security options as desired.
Add a second security policy allowing SSL VPN access to the Internet.
For this policy, Incoming Interface is set to ssl.root, Outgoing Interface is set to wan1, and Destination is set to
all.
Go to the Dashboard. In the CLI Console widget, enter the following commands to enable the host to check for
compliant AntiVirus software on the remote user's computer:
config vpn ssl web portal
edit full-access
set host-check av
end
7. Results
The steps for connecting to the SSL VPN different depending on whether you are using a web browser or FortiClient.
Web browsers:
Using a supported Internet browser, connect to the SSL VPN web portal using the remote gateway configured in the
SSL VPN settings (in the example, 172.20.121.46:10443)
Use the SSL VPN user's credentials to authenticate.
In this example, selecting the ISFW Bookmark allows you to connect to the ISFW FortiGate.
To connect to the Internet, select Quick Connection. Select HTTP/HTTPS, then enter the URL and select Launch.
You can also use the Quick Connection for other allowed types of traffic, such as SSH .
An SSH connection will open in your browser, connecting to the requested Host.
Java is required for an SSH connection.
On the FortiGate, go to Monitor > SSL-VPN Monitor. The user is connected to the VPN.
FortiClient:
On the FortiGate, go to Monitor > SSL-VPN Monitor. The user is connected to the VPN.
In this recipe, you will configure an SSL VPN tunnel that requires users to authenticate using a certificate.
This recipe requires that you have three certificates:
l CA certificate
l server certificate (signed by the CA certificate)
l user certificate (signed by the CA certificate)
You will install the CA certificate and server certificate on the FortiGate. The user certificate will be installed on the
remote user’s PC. The certificates in the example were created using OpenSSL.
Go to System > Feature Select and make sure that Certificates is enabled.
The server certificate is used for encrypting SSL VPN traffic and will be used for authentication.
Go to System > Certificates and select Import > Local Certificate.
Set Type to Certificate, choose the Certificate file and the Key file for your certificate, and enter the Password. You
can also change the Certificate Name.
The CA certificate is the certificate that signed both the server certificate and the user certificate. In this example, it is
used to authenticate SSL VPN users.
Go to System > Certificates and select Import > CA Certificate.
Select Local PC, then select the certificate file.
To use certificate authentication, PKI users must be created in the CLI. Go to Dashboard and enter the following
commands into the CLI Console widget:
config user peer
edit rdiaz
set ca CA_Cert_1
set subject User01
next
end
Make sure that subject matches the name of the user certificate (in this example, User01)
Now that you have created a PKI user, a new menu has been added to the GUI. You may need to refresh the GUI
before the menu appears. Go to User & Device > User group > PKI to see the new user listed.
Edit the user account and expand Two-factor authentication. Enable Require two-factor authentication and set a
Password for the account.
Go to User & Device > User > User Groups and create a group for SSL VPN users. Add the new user to the group.
Go to Policy & Objects > IPv4 Policy. Create a security policy allowing SSL VPN users to access the internal
network.
Set Incoming Interface to ssl.root. Set Source to all and include the new SSL VPN User’s group. Set Outgoing
Interface to the local network interface so that the remote user can access the internal network.
Set Destination Address to all, enable NAT, and configure any remaining firewall and security options.
Add a second security policy allowing SSL VPN users to access the Internet.
For this policy, Incoming Interface is set to ssl.root and Outgoing Interface is set to wan1.
Make sure that NAT is enabled.
Every user should have a unique user certificate, so that you can distinguish each user and so that it is possible to
revoke a user’s certificate when necessary.
If you are using Windows 7/8/10, open the certificate file and select Install Certificate. The Import Wizard appears.
Import the certificate into the Personal store.
If you are using Mac OS X, open the certificate file. Keychain Access opens.
Double-click the certificate. Expand Trust and select Always Trust.
Open FortiClientand go to Remote Access > Configure VPN . Create a new SSL VPN connection.
Set the Connection Name, Remote Gateway, and Customize port. Enable Client Certificate and select the
authentication certificate.
Depending on the operating system, go to Menu > Options or Preferences > Advanced and find the Certificates
tab.
Select View Certificates, then select the Your Certificates list. Import the certificate file.
9. Results
Using FortiClient
Open FortiClient, select the newly created VPN, enter user credentials and click Connect.
On the FortiGate, go to Monitor > SSL-VPN Monitor. You can see that the user is currently connected to the VPN.
The first instance correlates to the SSL VPN Web portal connection while the second entry relates to the FortiClient
connection.
This recipe demonstrates FortiGate user authentication with a FortiAuthenticator as a Single Sign-On server. In this
example, the FortiAuthenticator is configured to collect the user logon by polling the Domain Controller logs. User
authentication controls Internet access.
Go to Fortinet SSO Methods > SSO > General and configure these general settings.
Go to Fortinet SSO Methods > SSO > Domain Controllers and add the Windows DC to the FortiAuthenticator.
Go to Authentication > Remote Auth. Servers > LDAP to set the Windows AD as an LDAP server. This will be
useful to import SSO Filtering Objects from Windows AD to the FortiAuthenticator.
Go to Fortinet SSO Methods > SSO > FortiGate Filtering and create a new FortiGate Filter.
Under Fortinet Single Sign-On (FSSO), enable Forward FSSO information for users from the following
subset of users/groups/containers only.
Under SSO Filtering Objects, select Import. In the Remote LDAP Server field, select the LDAP server created in
the previous step (WinLDAP in this example) and select Apply.
Next, select groups or containers to be imported, controlled, and monitored by the FortiAuthenticator. In this example,
the “FortiOS Writers” user group is selected.
Go to User & Device > Single Sign-On and create a new SSO server.
In the Type field, select Fortinet Single-Sign-On Agent and set the Name, the Primary Agent IP/Name, the
Password and select Apply & Refresh.
When selecting the Users/Groups field, the SSO user groups initially polled by the FortiAuthenticator from the Domain
Controller appear.
In this example, only the “FortiOS Writers” group appears because of the FortiGate Filtering configuration in the
previous step.
Go to User & Device > User Groups and create a new Fortinet Single Sign-On (FSSO) user group. Under Members,
select the user group to be monitored. In this example only “FortiOS Writers” appears because of the FortiGate
Filtering configured earlier.
Go to Policy & Objects > IPv4 Policy and create a policy allowing “FortiOS_writers” to navigate the Internet with
appropriate security profiles.
The default Web Filter security profile is used in this example.
Go toMonitor > SSO > Domains to verify monitored domains. In this example “techdoc.local” is monitored by the
FortiAuthenticator.
You can also verify FSSO users in the User Inventory widget under System > Dashboard > Status.
Upon successful authentication, go to Monitor > Firewall User Monitor and verify FSSO Logons.
Have authenticated users navigate the Internet. Security profiles will be applied accordingly.
Go to Log & Report > Forward Traffic to verify the log.
This recipe demonstrates FortiGate user authentication with FSSO agent installed on a Windows Domain Controller,
and the use of a FortiAuthenticator as an LDAP server. In this example, user authentication controls Internet access.
Go to Authentication > User Management > Local Users to create a user list. Make sure to enable Allow LDAP
browsing.
Go to Authentication > User Management > User Groups to create a user group and add users to it. “FortiOS_
Writers” user group is used in this example.
Go to Authentication > LDAP Service > Directory tree and configure the LDAP directory tree.
On the FortiGate, go to User & Device > LDAP Servers to configure the LDAP server.
In the Collector Agent IP address field, enter the IP address of the Windows AD server.
Go to User & Device > Single Sign-On and create a new SSO server. In the Primary Agent IP/Name field, enter
the Collector Agent IP Address used in step 3. Likewise, enter the Password required for authentication.
Under the Groups tab, select the user groups to be monitored. In this example, the “FortiOS_Writers” group is used.
Go to User & Device > User Groups to create new user group. Under Remote groups, add the remote LDAP server
created earlier in the FortiAuthenticator (in this example it's called “FAC_LDAP”).
Go to Policy & Objects > IPv4 Policy and create a policy allowing “FortiOS_Writers” to navigate the Internet with
appropriate security profiles.
The default Web Filter security profile is used in this example.
7. Results
Have users log on to the domain, go to the FSSO agent, and select Show Logon Users.
From the FortiGate, go to Dashboard to look for the CLI Console widget and type this command for more detail
about current FSSO logons:
# diagnose debug authd fsso list
----FSSO logons----
IP: 10.10.20.3 User: ADMINISTRATOR Groups: CN=FORTIOS WRITERS,CN=USERS,DC=TECHDOC,DC=LOCAL
Workstation: WIN2K8R2.TECHDOC.LOCAL MemberOf: FortiOS_Writers
IP: 10.10.20.7 User: TELBAR Groups: CN=FORTIOS WRITERS,CN=USERS,DC=TECHDOC,DC=LOCAL Work-
station: TELBAR-PC7.TECHDOC.LOCAL MemberOf: FortiOS_Writers
Total number of logons listed: 2, filtered: 0
----end of FSSO logons----
Have users belonging to the “FortiOS_Writers” user group navigate the Internet. An authentication portal is presented to
allow only authorized users. Security profiles will be applied accordingly.
Upon successful authentication, from the FortiGate, go to Monitor > Firewall User Monitor and verify FSSO Logons.
This recipe illustrates FortiGate user authentication with FSSO and a Windows DC LDAP server. In this example, user
authentication controls Internet access.
Go to User & Device > LDAP Servers to configure the LDAP server.
In the Collector Agent IP address field, enter the IP address of the Windows AD server.
Go to User & Device > Single Sign-On and create a new SSO server.
Under the Groups tab, select the user groups to be monitored. In this example, the “FortiOS Writers” group is used.
Go to User & Device > User Groups to create a new FSSO user group.
Under Members, select the “FortiOS Writers” group.
Go to Policy & Objects > IPv4 Policy and create a policy allowing “FortiOS_Writers” to navigate the Internet with
appropriate security profiles.
The default Web Filter security profile is used in this example.
Results
Have users log on to the domain, go to the FSSO agent, and select Show Logon Users.
From the FortiGate, go to Dashboard to look for the CLI Console widget and type this command for more detail
about current FSSO logons:
# diagnose debug authd fsso list
----FSSO logons----
IP: 10.10.20.3 User: ADMINISTRATOR Groups: CN=FORTIOS WRITERS,CN=USERS,DC=TECHDOC,DC=LOCAL
Workstation: WIN2K8R2.TECHDOC.LOCAL MemberOf: FortiOS_Writers
IP: 10.10.20.7 User: TELBAR Groups: CN=FORTIOS WRITERS,CN=USERS,DC=TECHDOC,DC=LOCAL Work-
station: TELBAR-PC7.TECHDOC.LOCAL MemberOf: FortiOS_Writers
Total number of logons listed: 2, filtered: 0
----end of FSSO logons----
From the FortiGate, go to Monitor > Firewall User Monitor and verify FSSO Logons.
Have users go to the Internet and the security profiles will be applied accordingly.
Go to Log & Report > Forward Traffic to verify the log.
This traffic shaping document describes Priority Queueing (PRIQ), Type of Service (ToS) priority, and Quality of Service
(QoS). It also explains the following:
l Why traffic shaping only occurs when traffic approaches the configured capacity on a given interface.
l Why you should configure the FortiGate unit to preemptively drop excess packets.
l How priority queues work on the FortiGate.
l The difference between ToS-based priority and global ToS priority.
l Why you must enable traffic shaping for ALL firewall policies to get expected results.
l How firewall policy priorities and ToS policies affect each other.
l Why traffic shaper priorities only effect per port egress queueing.
Any CLI commands and GUI references in this article have been tested for both FortiOS 5.2.5 and FortiOS 5.4, and any
differences between versions will be documented.
One of the most common misconceptions with traffic shaping on your FortiGate is that setting a “priority” will ensure
that high priority traffic will download faster than low priority traffic. This perfectly reasonable expectation does not fully
encapsulate what “priority” means in FortiOS, which needs to be taken into consideration. Traffic shaping will only begin
to take effect when an interface with traffic shaping configured reaches its capacity. Until this threshold is reached all
traffic is treated equally. As the interface experiences high traffic levels that reach its threshold, you will begin to notice a
variation in traffic flow or download speeds.
A screenshot of a shaper at capacity in the FortiView > Traffic Shaping section (FortiOS 5.4).
There are a few things you need to know about Traffic Shaping and priority queueing before we begin:
l Packets are prioritized based on their priority value.
l The priority value is based on whether you have configured Type of Service (ToS) priority and/or Firewall
policy priority.
l The total priority value then determines which queue the packet is placed in, out of six queue options.
Also, remember that only per port egress queueing works!
Other considerations that affect which queue is used include:
When deciding how to configure QoS techniques, it can be helpful to know when FortiGate units employ each technique
in the overall traffic processing flow, and the considerations that follow.
As traffic arrives (ingress) and departs (egress) on an interface, the FortiGate unit begins to process the traffic. In later
phases of network processing — such as enforcing maximum bandwidth on sessions handled by a security policy — if
the current rate for the destination interface or traffic regulated by that policy is too high, the FortiGate unit may drop the
packet. Time spent on prior processing — like web filtering, decryption, or IPS — is wasted on these dropped packets.
You can prevent wasted effort on ingress by configuring the FortiGate unit to preemptively drop excess packets when
they are received at the source interface, before most other traffic processing is performed:
config system interface
edit <interface_name>
set inbandwidth <rate_int>
set outbandwidth <rate_int>
next
end
Where <rate_int> is set to the bandwidth limit in Kb/s, excess packets will be dropped. If the inbandwidth <rate_
int> is set to 0, then the rate is not limited.
As with ingress, if you set the rate to 0 (zero) that means you are setting the rate to unlimited. Rate limiting traffic
accepted by the interface enables you to restrict incoming traffic to rates that, while no longer the full capacity of the
interface, at the traffic shaping point in the processing are more likely to result in acceptable rates of outgoing traffic per
destination interface or all security policies. This conserves FortiGate processing resources for those packets likely to be
viable (to the point of egress).
This diagram shows how excess packets going from WAN 1 can be intercepted and dropped at the source interface.
After packet acceptance, the FortiGate unit classifies traffic and may apply traffic policing at additional points during
processing. It may also apply QoS techniques, such as prioritization and traffic shaping. Traffic shaping consists of a
mixture of traffic policing to enforce bandwidth limits, and priority queue adjustment to assist packets in achieving the
guaranteed rate.
If you have configured prioritization, the FortiGate unit prioritizes egressing packets by distributing them among FIFO
(first in, first out) queues associated with each possible priority number. Each physical interface has six priority queues.
Virtual interfaces use the priority queues of the physical interface to which they are bound.
Each physical interface’s six queues are queue 0 to queue 5, where queue 0 is the highest priority queue. However, you
may observe that your traffic uses only a subset of those six queues. For example, some traffic may always use a
certain queue number. Queuing may also vary by the packet rate or mixture of services. Some queue numbers may only
be used by through traffic for which you have configured traffic shaping in the security policy that applies to that traffic
session.
Types of priority
Prioritization and traffic shaping behavior vary based on the configuration, service type, traffic volume, and whether the
traffic is through traffic or originates at the FortiGate unit itself.
Packets can be assigned a priority in one of three ways:
l On entering ingress – for packets flowing through the firewall.
l Upon generation – for packets generated by the firewall (including packets generated due to AV proxying).
l On passing through a firewall policy – for packets passing through a firewall policy that has a traffic shaper
defined.
Ingress priority and priority for generated packets is controlled via two different CLI settings:
config system global
set traffic-priority-level {high|medium|low}
end
Type of Service is an 8-bit field in the IP header that allows you to determine how the IP datagram should be delivered,
using the following criteria: Delay, Throughput, Priority, Reliability, and Cost. The criteria help gateways pick the best
way to route datagrams.
A router maintains a ToS value for each route in its routing table. The lowest priority ToS is 0, and the highest is 7 (when
bits 3, 4, and 5 are all set to 1). There are four other bits that are seldom used or reserved that are not included here.
Together these bits are the tos variable of the tos-based-priority command. The router tries to match the ToS of the
datagram to the ToS on one of the available routes to the destination. If there is no match, then the datagram is sent
over a zero ToS route. Using increased quality may increase the cost of delivery, because better performance may
consume limited network resources.
Each bit represents the priority as per RFC 1349:
l 1000 – minimize delay
l 0100 – maximize throughput
l 0010 – maximize reliability
l 0001 – minimize monetary cost
The tos value is set in the CLI using the commands:
config system tos-based-priority
edit <sequence_number>
set tos [0-15]
set priority [high | medium | low]
next
end
Where tos is the value of the type of service bit in the IP datagram header with a value between 0 and 15, and priority is
the priority of this type of service.
High 1
Medium 2
Low 3
These priority levels conform to the firewall traffic shaping priorities, as defined in RFC 1349.
All traffic shapers are enabled within a security policy, including the Application Control shapers. As such, the shapers
take effect after any DoS detection policies, and before any routing or packet scanning occurs.
The shaper you select for the security policy (shared shaper) will affect the traffic in the direction defined in the policy.
For example, if the source port is lan and the destination is wan 1, the shaping affects the flow in this direction only —
affecting the upload speed of the outbound traffic.
By selecting Shared Traffic Shaper Reverse Direction, you can define the traffic shaper for the policy in the opposite
direction to affect the download speed of the inbound traffic. In this example, from wan 1 to lan.
config firewall policy
edit <policy_number>
...
set traffic-shaper <shaper_name>
set per-ip-shaper <shaper_name>
set traffic-shaper-reverse <shaper_name>
next
end
In a firewall policy you can enable traffic shaping and set the firewall priority to high, medium, or low:
High (default) 1
Medium 2
Low 3
Since all security policies are set to “high” priority by default, it is necessary to set some traffic at a lower priority to get
results. When you enable traffic shaping, and change the priority to medium or low it will override the default setting.
To have proper QoS using the FortiGate, the firewall policy you create between your incoming interface and outgoing
interface should include two interfaces. For example, a LAN to WAN 1 policy.
Important: Make sure that ALL the firewall policies that use these two interfaces for communication have traffic
shaping enabled!
In versions of FortiOS 5.2 and earlier, you must enable traffic shaping at the policy level for each individual policy:
A screenshot of a FortiOS 5.2 Security Policy with all types of traffic shaping enabled, under Policy & Objects >
Policy > IPv4.
This is no longer necessary in FortiOS 5.4, as the new Traffic Shaping Policies allow you to apply traffic shaping globally
to any traffic matching your criteria. The criteria must specify a source, a destination, a service, and the outgoing
interface:
A screenshot of a FortiOS 5.4 traffic shaping policy, under Policy & Objects > Traffic Shaping Policy.
The global or ingress ToS-based priority value is combined with the firewall policy priority value:
Global priority (0, 1, 2) + policy priority (1, 2, 3) = total priority (queue number).
Let’s take a look at some examples:
l If we assume a default ingress priority of low (2) and a firewall policy priority of low (3), then the resulting priority is
5.
l If the packet flowing through results in a rate that is less than the guaranteed bandwidth, then the priority is set
to 0 regardless of the priority in the firewall policy.
l If the packet flowing through results in a rate that’s above the maximum bandwidth, then the packet is dropped.
l If the packet flowing through results in a rate that is between the guaranteed and the maximum bandwidth,
then the packet priority is increased by the priority from the policy. Therefore, assuming a default ingress priority of
high (0) and a firewall policy of high (1), then the resulting priority is 1.
l When a packet is sent to the egress device, it is attached to a queue based on the packet priority. For example,
priority 0 is attached to queue 1, and so on. If the queue is full, then the packet is dropped.
Important: Shaper priority only affects per port egress queueing. Thus, if there are two streams of traffic — with
one egressing over port 1 and one egressing over port 2 — then the priority has no effect whatsoever. Both streams will
continue to run at full speed.
The method a FortiGate unit uses to determine the priority queue for traffic passing through the FortiGate unit depends
on whether you have enabled Traffic Shaping. Packets may or may not use a priority queue directly or indirectly derived
from the type of service (ToS) bit — sometimes used instead with differentiated services — in the packet’s IP header.
If Traffic Shaping is not enabled in the security policy, the FortiGate unit neither limits nor guarantees bandwidth. Traffic
shaping for that session uses the priority queue determined by matching the ToS bit in its header with your configured
values:
config system global
set traffic-priority-level {high | medium | low}
end
or, if you have configured a priority specifically for that TOS bit value:
config system tos-based-priority
edit <id_int>
set tos [0-15]
set priority {high | medium | low}
next
end
Where tos is the value of the ToS bit in the packet’s IP header, and high has a value of 0 and low is 2. Priority values
configured in the second location will override the global ToS-based priority. In other words, packet priority = ToS-
based priority.
For example, you might specify that packets with a ToS bit value of 2 should use queue 0, the highest priority queue:
config system tos-based-priority
edit 15
set tos 2
set priority high
next
end
If Traffic Shaping is enabled in the security policy using shared traffic shapers, the FortiGate unit may instead or also
subject packets to traffic policing or priority queue increases in an effort to meet bandwidth guarantees configured in the
shaper:
config firewall shaper traffic-shaper
edit <shaper_name>
...
set priority {high | medium | low }
set maximum bandwidth <rate>
set guaranteed-bandwidth <rate>
next
end
Where high has a priority value of 1 and low is 3, and <rate> is the bandwidth limit in kilobits per second.
Security policies do not apply to administrative access traffic to the FortiGate through IPsec tunnel negotiations.
Consequently, FortiGates do not apply traffic shaping to these types of traffic. These typesof traffic use the highest
priority queue, queue 0. In other words, packet priority = 0.
Exceptions to this rule include traffic types with connections that are related to a session governed by a security policy.
For example, if you have enabled FortiGuard AntiVirus scanning, traffic from the sender technically terminates at the
FortiGate proxy that scans that traffic type; the FortiGate unit initiates a second connection that transmits scanned
content to its destination. Because the second connection’s traffic is technically originating from the FortiGate proxy,
and therefore the FortiGate unit itself, it uses the highest priority queue, queue 0. However, this connection is logically
associated with through traffic, and is therefore subject to possible bandwidth enforcement and guarantees in its
governing security policy. In this way, it behaves partly like other through traffic.
Egress queueing
Shaper priority only affects per port egress queueing, so if you have two streams of traffic, like one egressing
over Port1 and one egressing over Port2, then priority has no effect whatsoever. Both streams will continue to run at full
speed.
To make any difference to the order in which packets egress the interface, there must be packets of a lower priority
queued on the egress interface. This usually happens when there is an imbalance between the packet rates on the
interfaces.
For example, if the LAN is 1Gb, but the WAN is only 100MB. In this scenario the priority of the traffic egressing the WAN
is very important, but the traffic egressing the LAN is rendered irrelevant (as it would take 10 WAN links to drive traffic at
a high enough rate to cause queuing interference on the LAN interface).
This was tested by performing a debug on the kernel to determine when priority would take effect. In this case, by
counting how many times the egress interface had more than one packet in the queue. Two simultaneous 500MB
downloads via HTTP were performed, with one policy set to a high priority and one set to a low priority. Results showed
that there was more than one packet in the egress queue only 23 times. With over 600,000 packets egressing over that
interface, altering the priority of 23 does not make a practical difference to the relative speed of downloads.
Resources
In the FortiOS Handbook, you may be interested in checking out the following Traffic Shaping sections:
l Important Considerations for more information.
l Troubleshooting for diagnose commands.
l Traffic Shaper Monitor for how to view traffic shaping results.
In this example, you will update your FortiGate to use the latest version of FortiOS, so that you can use the latest
FortiOS features.
In this recipe, a FortiGate is updated from FortiOS 5.2.5 to 5.4.0. This upgrade path is supported, as shown in the
FortiOS Upgrade Path Tool.
Go to the Dashboard (in FortiOS 5.2, System > Dashboard > Status) and view the System Information dashboard
widget. The Firmware Version section shows the firmware that is currently installed and if a new version is available.
If a new version is available, select View Release Notes to access the Release Notes for that version. Review the
release notes to determine if you want to upgrade to this version.
Pay extra attention to the Upgrade Information section, to find out if you can upgrade directly from your current
firmware to the latest version. You should also check the Supported Upgrade Paths tool, found at the Fortinet
Documentation Library.
Firmware can also be downloaded directly from Fortinet Support, then uploaded manually to your FortiGate.
4. Results
The FortiGate unit uploads the firmware image file, updates to the new firmware version, restarts, and displays the
FortiGate login. This process takes a few minutes. You might see a message to check the disk or filesystem; this is
normal.
You may have to refresh your browser to see the FortiGate login.
Go to Dashboard. In the System Information dashboard widget, the Firmware Version will show the updated
version of FortiOS.
For further reading, check out Firmware in the FortiOS 5.4 Handbook.
In this recipe, you will provide different network access for staff members based on full-time or part-time status.
Wireless access will be allowed for users with laptops but denied for tablets and mobile phones.
In this recipe, a WiFi network has already been configured that is in the same subnet as the wired LAN. For more
information, see Setting up a WiFi Bridge with a FortiAP on page 500.
Create two new users with the Users/Group Creation Wizard (mlennox and ccraven, for example). Add one user to
the full-time group and the other to the part-time group.
Go to Policy & Objects > Schedules and create a new recurring schedule.
Set an appropriate schedule. In order to get results later, do not select the current day of the week.
Go to Policy & Objects > IPv4 Policy and create a new policy.
Set Incoming Interface to the local network interface. Select Source and set Address to all and User to the full-time
group. Set Outgoing Interface to your Internet-facing interface, and make sure Schedule is set to always.
Turn on NAT.
Scroll down to view the Logging Options. In order to view the results later, enable Log Allowed Traffic and select
All Sessions.
Go to Policy & Objects > IPv4 Policy and create a new policy.
Set Incoming Interface to the local network interface. Select Source and set Address to all and User to the part-
time group. Set Outgoing Interface to your Internet-facing interface, and set Schedule to use the part-time schedule.
Turn on NAT.
Scroll down to view the Logging Options. In order to view the results later, enable Log Allowed Traffic and select
All Sessions.
View the policy list. Click on the part-time policy row and right-click anywhere in the row. Select > Edit in CLI from the
dropdown menu.
Note that the policy ID column is not shown by default. You must add that column if you wish to see it but it is not
necessary in order to complete this recipe.
Enter the command set schedule-timeout enable, as shown into the CLI Console. The other commands
appear as a result of the previous step.
Close the console when done.
This ensures that access for part-time users (under policy ID 3) is revoked on days not on schedule, even if their current
session began when access was allowed.
Set Incoming Interface to the local network interface. Select Source and set Address to all and Device to Mobile
Devices (a default custom device group that includes tablets and mobile phones; using a device group will
automatically enable device identification on the local network interface), Outgoing Interface to your Internet-facing
interface, and set Action to DENY.
Leave Log Violation Traffic turned on.
Go to Policy & Objects > IPv4 Policy and view policies By Sequence.
The deny mobile traffic policy must be above the other Internet access policies. To move a policy, select any area in the
far-left column of the policy and drag it to where you want it.
6. Results
Browse the Internet using a computer. You will be prompted to enter authentication credentials. If the site you try to
access uses HTTP Strict Transport Security (HSTS), you won’t get the prompt for authentication credentials. Be sure to
go to a site that does not use HSTS. Once you authenticate, you can then go to any website that is not blocked by any
filters your network has in place.
Log in using the mlennox account. You will be able to access the Internet at any time.
Go to Monitor > Firewall User Monitor. Highlight mlennox and select De-authenticate. Your connection will be
dropped.
Attempt to browse the Internet again. This time, log in using the ccraven account. After entering login credentials, you
will not be able to access the Internet because you are attempting access on a day that is not on ccraven‘s schedule.
Attempts to connect to the Internet with any mobile device accessing the WiFi configured for this recipe will also be
denied.
Go to Fortiview > Sources and select the 5 minutes view. You can see mobile and part-time user traffic is blocked
and that the full-time user traffic is allowed.
For further reading, check out Users and user groups in the FortiOS 5.4 Handbook.
Hair-pinning, in a networking context, is the method where a packet travels to an interface, goes out towards the
Internet but instead of continuing on, makes a “hair pin turn”, and comes back in on the same interface. Initially, it may
seem unnecessary or pointless even but it does serve a purpose.
These days, due to the shortage of IPv4 addresses, most networks behind a firewall, use private IP addresses. Private
IPv4 addresses are not routable so a virtual IP needs to be configured to allow users from the Internet to access any
private IP addresses on the internal side of the FortiGate. For more information on private IPv4 addresses, you can
check out RFC 1918.
For instance, on the Internet you could use the address of the external IP, where the traffic would then be forwarded to
the internal address of the server. You could then use the internal IP address to access the server if you are on the
internal LAN. There is also the option to allow everyone to use a consistent address by setting up a Fully Qualified
Domain Name (FQDN). This simplifies access seeing as words are easier to remember than IP addresses.
In recent years, system administrators focused on finding ways to strengthen their systems to prevent outside threats
from intruding their networks. Unfortunately, they did not always take the time to protect their networks from internal
threats, a situation where an internal resource became compromised. Hackers, crackers and other malicious actors took
advantage of this weakness and invented “spoofing”. The bad guys used the spoofing method to alter packets to appear
as if they were coming from the internal network, kind of like buzzing at the door of an apartment building and when
someone answers, saying “let me back in, please”.
It took some time for the devices and programmers of network protocols to catch up. Networking and protocols were
originally designed to work where everybody was on the same side. The security aspect was added later on as some
people began exploiting the system.
It was not long before the good guys developed techniques to harden their systems to prevent packets coming in from
what appear as internal IP addresses, when in reality, the packets are coming in from the Internet.
In order to use a common FQDN in combination with the VIP, the traffic has to come in to through the external interface
to access the server. This is where the VIP accepts traffic.
System administrators put a lot of effort into preventing packets with internal IP addresses from coming in through the
external interface. Humans have the ability of understanding the context of what is going on and use their judgment
accordingly, but computers have no judgment and do only what you tell them to; nothing more. A computer has no basis
for setting apart malicious attacks and safe traffic based only on the source address of the traffic. However, it is safe to
assume that something coming in from the outside with an internal address raises some red flags. This is the reason
why it is important to specify the source IPs of which traffic can be forwarded to the internal IP through the VIP.
A properly configured FortiGate is aware of the criteria to determine which source IP addresses will allow a packet to be
forwarded to the internal IP address. If the incoming packets are from an allowed IP address, along with the other
allowed parameters, they are forwarded to the appropriate internal address. If they are not explicitly approved, they are
explicitly denied.
In the growing battle and evolution of those building a mousetrap and those trying to build an even better mousetrap,
adapting to those changes becomes necessary. System administrators need to acclimate to the evolution on both sides
all the while ensuring the user’s needs are met and the security on the network is maintained. Right now, one of the
adaptations we make is to use a hair-pinning technique. This means working around the protections put in place to
prevent malicious attacks and at the same time, accommodating users on a network. This technique provides users with
the convenience of a continuous method of access and the security of preventing a commonly used attack technique.
This recipe demonstrates how to use Virtual IPs (VIPs) to configure port forwarding on a FortiGate unit. This
configuration allows users on the Internet to connect to your server protected behind a FortiGate firewall, without
knowing the server’s internal IP address and only through ports that you choose.
In this example, TCP ports 80 (HTTP), 21 (FTP), and 22 (SSH) are opened for remote users to communicate with a
server behind the firewall. The external IP address used is 172.20.121.67 and is mapped to 192.168.100.1 by the VIP.
Go to Policy & Objects > Virtual IPs > Create New > Virtual IP.
Enter the External IP Address/Range. Next, enter the Mapped IP Address/Range.
Enable Port Forwarding and add a VIP for TCP port 80, webserver-http. While this example maps port 80 to port 80,
any valid External Service port can be mapped to any listening port on the destination computer.
Go to Policy & Objects > Virtual IPs > Create New > Virtual IP Group.
Create a VIP group, in this example, webserver group. Under Members, include all three VIPs previously created.
Go to Policy & Objects > IPv4 Policy and create a security policy allowing access to a server behind the firewall.
Set Incoming Interface to your Internet-facing interface, Outgoing Interface to the interface connected to the server,
and Destination Address to the VIP group (webserver group). If the FortiGate has Central NAT enabled, the VIP
objects will not be available for selection in the policy editing window. Set Service to allow HTTP, FTP, and SSH
traffic.
NAT is disabled for this policy so that the server sees the original source addresses of the packets it receives. This is the
preferred setting for a number of reasons. For example, the server logs will be more meaningful if they record the actual
source addresses of your users.
Use the appropriate Security Profiles to protect the servers.
4. Results
To ensure that TCP port 80 is open, connect to the web server from a remote connection on the other side of the
firewall.
Next, ensure that TCP port 21 is open by using an FTP client to connect to the FTP server from a remote connection on
the other side of the firewall.
Finally, ensure that TCP port 22 is open by connecting to the SSH server from a remote connection on the other side of
the firewall.
For further reading, check out Virtual IPs in the FortiOS 5.4 Handbook.
VDOM configuration
This example illustrates how to use virtual domains (VDOMs) to host multiple FortiOS instances on a single FortiGate.
In this example, two companies (called Company A and Company B) use the same FortiGate but have different Internet
service providers (ISPs). To provide both departments with network and Internet connectivity, each company has its own
VDOM (called VDOM-A and VDOM-B) that are managed independently.
The root VDOM will be used to manage the FortiGate’s global settings.
Connect a PC to FortiGate using an Ethernet cable, as described in your model’s QuickStart Guide.
Log in using the admin account (the default admin account has the username admin and no password).
Go to the Dashboard and locate the System Information widget. Find Virtual Domain and select Enable.
You will be required to re-login after enabling virtual domains because the GUI menu options change.
Certain FortiGate models will not show the above option in the System Information widget. For these models, go to the
Dashboard and enter the following command in the CLI Console:
config system global
set vdom-admin enable
end
Make sure that Global is selected from dropdown menu located in the top-left corner. This allows you to make changes
to the global configuration.
Go to System > VDOM and create two VDOMs: VDOM-A and VDOM-B.
In this example, the Inspection Mode is set to Proxy for VDOM-A. This will allow this VDOM to use both proxy and
flow-based security scanning.
The Inspection Mode for VDOM-B is set to Flow-based, so only flow-based security scanning is available.
Go to Network > Interfaces. By default, all interfaces are in the root VDOM.
Edit the interface you wish to use to manage the FortiGate (in the example, mgmt). If you wish to use this interface
exclusively for FortiGate management, you can enable Dedicated Management Port.
Set Administrative Access to HTTPS, PING, and SSH .
In this example, two interfaces will be added to VDOM-A: one for Internet access and one for use by the local network.
If an interface is used in an existing FortiGate configuration, its VDOM assig ent cannot be changed. Because some
FortiGate models have a default configuration, you may need to delete existing policies and routes in order to add a
particular interface.
Go to Network > Interfaces and edit the interface that VDOM-A will use for Internet access (in the example, wan1). In
the example, the interface’s Link Status is Down because nothing is currently connected to the interface.
Set Virtual Domain to VDOM-A and Role to WAN .
If your FortiGate is directly connecting to your ISP, set Addressing Mode to Manual and set the IP/Netmaskto the
public IP address your ISP has provided you with (in the example, 172.20.121.46/255.255.255.0).
If you have some ISP equipment between your FortiGate and the Internet (for example, a router), then the wan1 IP will
also use a private IP assigned by the ISP equipment. If this equipment uses DHCP, set Addressing Mode to DHCP to
get an IP assigned to the interface.
If the ISP equipment does not use DHCP, your ISP can provide you with the correct private IP to use for the interface.
Go to Network > Interfaces and edit the interface that will be connected to VDOM-A’s internal network (in the
example, port1).
Set Virtual Domain to VDOM-A and Role to LAN .
Set Addressing Mode to Manual, assign an IP/Network Mask to the interface (in the example,
192.168.100.1/255.255.255.0), set Administrative Access to HTTPS, PING, and SSH.
In this example, multiple interfaces will be added to VDOM-B: one for Internet access and four additional interfaces for
use by the internal network. These four interfaces will be combined into a hardware switch interface called LAN-B, which
the FortiGate treats as a single interface. This example also adds a DHCP server to LAN-B to provide IP addresses for
the VDOM-B’s internal network.
Go to Network > Interfaces and edit the interface that VDOM-B will use for Internet access (in the example, wan2).
Set Virtual Domain to VDOM-B and Role to WAN . Set an appropriate Addressing Mode and IP/Netmask (in the
example, 172.20.120.100/255.255.255.0).
Go to Network > Interfaces and edit a physical interface that will be used by VDOM-B’s internal network (in the
example, port5).
Set Virtual Domain to VDOM-B and Role to LAN .
Repeat this process for any other physical interfaces that will be used by VDOM-B (in the example, port6, port7, and
port8).
Go to Network > Interfaces and create a new interface to be used by VDOM-B’s internal network, called LAN-B.
Set Type to Hardware Switch and Virtual Domain to VDOM-B. Add VDOM-B’s physical interfaces as Physical
Interface Members. Set Role to LAN.
Set Addressing Mode to Manual, assign an IP/Network Mask to the interface (in the example,
192.168.200.1/255.255.255.0), set Administrative Access to HTTPS, PING, and SSH and enable DHCP Server.
6. Configuring VDOM-A
Access VDOM-A‘s configuration using the dropdown menu and go to Network > Static Routesto add a default route.
Set Destination to Subnet (this destination type allows you to input a numeric IP address or subnet), Destination
IP/Mask to 0.0.0.0/0.0.0.0, the Device to the Internet-facing interface, and the Gatewayto the gateway (or default
route) provided by your ISP or to the next hop router, depending on your network requirements.
Go to Policy & Objects > IPv4 Policies and create a new policy to allow Internet access for VDOM-A. Give the policy
a Name that indicates that the policy will be for traffic to the Internet (in the example, Internet-VDOM-A).
Set Incoming Interface to port1, Outgoing Interface to wan1, Source to all, Destination Address to all, and
Service to ALL. Make sure NAT is enabled.
Because this VDOM uses proxy inspection, you can enable a variety of security profiles that use either proxy or flow-
based inspection.
For testing purposes, under Logging Options, enable Log Allowed Traffic and select All Sessions.
7. Configuring VDOM-B
Access VDOM-B‘s configuration using the dropdown menu and go to Network > Static Routesto add default route.
Set Destination to Subnet, Destination IP/Mask to 0.0.0.0/0.0.0.0, the Device to the Internet-facing interface, and
the Gateway to the gateway (or default route) provided by your ISP or to the next hop router, depending on your
network requirements.
Go to Policy & Objects > IPv4 Policies and create a new policy to allow Internet access for VDOM-B. Give the policy
a Name that indicates that the policy will be for traffic to the Internet (in the example, Internet-VDOM-B).
Set Incoming Interface to LAN-B, Outgoing Interface to wan2, Source to all, Destination Address to all, and
Service to ALL. Make sure NAT is enabled.
Because this VDOM uses flow-based inspection, you can only enable security profiles that use flow-based inspection.
For testing purposes, under Logging Options, enable Log Allowed Traffic and select All Sessions.
8. Results
Using a PC located on VDOM-A’s internal network, browse to the IP of the LAN-A interface (in the example,
https://192.168.100.1).
Login to the VDOM using admin-a‘s credentials. When the GUI loads, only the options for configuration VDOM-A
appear.
Right-click on the policy, then select Drill Down to Details. You can see more information about the traffic.
Logout of the VDOM, then attempt to login using the global admin‘s credentials. You will not be able to log in. You can
also not log in using admin-b‘s credentials.
Using a PC located on VDOM-B’s internet network, browse to the IP of the LAN-B interface (in the example,
https://192.168.200.1).
Login to the VDOM using admin-b‘s credentials. When the GUI loads, only the options for configuration VDOM-B
appear.
This section contains tips to help you with some common challenges of FortiGate web and DNS filtering.
Verify that Web 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 all this is correct, verify that proxy options and HTTP and HTTPS enabled and use the correct ports.
Verify that DNS Filter is enabled in a policy. 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 all this is correct, verify that DNS requests are going through the policy, rather than to an internal DNS server.
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.
Verify that you entered the entire URL of the website, not just the domain name. Also verify that you have not used a
web rating override to change the local website categorization.
If the categorizations still do not match, verify whether your web filter profile has the option to Rate URLs by domain
and IP Address enabled. If this option is enabled, the categorization could be different if the IP address that the URL
resolves to has a different rating than the URL itself.
If this occurs, verify that web filtering is enabled in one of your security policies. FortiGuard services will sometimes
show as expired those services are not actively used.
If web filtering is enabled in a policy, go to your FortiGuard settings. In the options for web filtering, change the
FortiGuard port from 53 (default) to 8888. Verify whether the license is shown as active. If it is still inactive/expired,
switch back to the default port and verify again.
Go to the DNS settings to verify that your FortiGate is pointing to appropriate DNS servers and can resolve and reach
FortiGuard at service.fortiguard.net. If you can reach this service, you can then verify the connection to FortiGuard
servers by running the command diagnose debug rating. This displays a list of FortiGuard IP gateways you can
connect to, as well as the following information:
l Weight: Based on the difference in time zone between the FortiGate and this server
l RTT: Return trip time
l Flags: D (IP returned from DNS), I (Contract server contacted), T (being timed), F (failed)
l TZ: Server time zone
l Curr Lost: Current number of consecutive lost packets
l Total Lost: Total number of lost packets
You can control which scans that you wish to exempt the URL from in the CLI:
config webfilter urlfilter
edit <id>
config entries
edit <id>
set exempt {av | web-content | activex-java-cookie | dlp | fortiguard | range-
block | pass | all}
next
end
next
end
This recipe demonstrates how to set up a web filter security profile with a quota that dynamically limits the amount of
time users on an internal network can access websites categorized as "General Interest". An active license for
FortiGuard Web filtering Services is required to use web filtering with quotas.
You can also apply quotas to specific users on your network by creating granular policies that apply different quotas to
different user groups using specific firewall addresses or needing authentication.
See User and device authentication on page 628 for information about creating user accounts.
Go to System > Feature Select and confirm that Web Filter is ON. If necessary, click Apply to make your changes.
Go to Security Profiles > Web Filter. Edit the default profile and enable FortiGuard category based filter.
Right-click on the category General Interest – Personal and select Monitor. Do the same for the category General
Interest – Business.
These categories include a variety of sites that are commonly blocked in the workplace, such as games, instant
messaging, and social media. For a complete description of each web filtering category, visit the FortiGuard Web
Filtering page.
The web filter now displays all the General Interest sub-categories and the applied quota.
Go to Policy & Objects > IPv4 Policy and edit the policy that allows connections from the internal network to the
Internet.
Under Security Profiles, turn on Web Filter and use the default profile.
Note: If you are applying quotas to specific users or devices, edit Source Address to apply the policy only to them.
4. Results
Go to FortiView > Threats and select the 5 minutes view. You can see the blocked traffic.
For further reading, check out Blocking social media websites using FortiGuard categories on page 56, Blocking
Facebook with Web Filtering on page 50, and FortiGuard Web Filtering Service in the FortiOS 5.4 Handbook.
In this example, a school enables its WiFi network only during school hours. The school is open from 8am to 6pm
Monday through Friday.
A schedule applied in the security policy would control access to the Internet, but outside of the scheduled period the
SSID would still be visible and clients could associate with it. In this example, the schedule is applied in the SSID
configuration. The SSID is available only during the scheduled hours.
This example assumes that a user group has already been configured for WiFi users.
Go to Policy & Objects > Schedules. Create a recurring schedule for school hours (in the example, 8am-6pm,
Monday through Friday).
Enable DHCP Server to provide a range of IP addresses for your WiFi clients.
Set Schedule to the new schedule, and configure the other WiFi Settings as required.
Go to Policy & Objects > IPv4 Policy and create a policy that allows Internet access for mobile devices on the
Student-net wireless network. Give the policy a name that identifies what it is used for (in the example, Student-WiFi-
Internet).
Set Incoming Interface to the wireless interface and Outgoing Interface to the Internet-facing interface. Set
Schedule to the new schedule and make sure NAT is enabled.
Results
Verify that mobile devices can connect to the Internet outside of class time, when the schedule group is valid. Verify that
the SSID is not available after scheduled times.
This page contains information to help you troubleshoot wireless network issues.
In the following sections, you will learn basic troubleshooting techniques for a secure Fortinet wireless LAN including:
l strategies for troubleshooting Fortinet wireless devices
l how to avoid common misconfigurations
l solutions to connectivity issues
l capturing and analyzing wireless traffic
l wireless debug commands
The goal is to provide you with practical knowledge that you can use to troubleshoot the CLI commands for
maintenance and troubleshooting of your wireless network infrastructure, analyze problems per OSI layer, explore
diagnostics for commissioning issues regarding at-client and access point connectivity problems, and understand the
packet sniffer technique as a strong troubleshooting tool.
Note that the GUI paths mentioned are for FortiOS 5.4 and may differ from earlier FortiOS versions. Likewise, some
CLI may be slightly different, unless otherwise indicated.
Poor signal strength is possibly the most common customer complaint. Below you will learn where to begin identifying
and troubleshooting poor signal strength, and learn what information you can obtain from the customer to help resolve
signal strength issues.
Asymmetric power issues are a typical problem. Wireless is two-way communication; high power access points (APs)
can usually transmit a long distance, however, the client’s ability to transmit is usually not equal to that of the AP and, as
such, cannot return transmission if the distance is too far.
To solve an asymmetric power issue, measure the signal strength in both directions. APs usually have enough power to
transmit long distances, but sometimes battery-powered clients have a reply signal that has less power, and therefore
the AP cannot detect their signal.
It is recommended that you match the transmission power of the AP to the least powerful wireless client—around 10
decibels per milliwatt (dBm) for iPhones and 14dBm for most laptops.
Even if the signal is strong enough, other devices may be emitting radiation as well, causing interference. To identify the
difference, read the client Rx strength from the FortiGate GUI (under Monitor > WiFi Client Monitor) or CLI.
The Signal Strength/Noise value provides the received signal strength indicator (RSSI) of the wireless client. For
example, A value of -85dBm to -95dBm is equal to about 10dB levels; this is not a desirable signal strength. In the
following screenshot, one of the clients is at 18dB, which is getting close to the perimeter of its range.
Note: The Signal Strength/Noise value received from the FortiAP by clients, and vice versa, should be within the range
of -20dBm to -65dBm.
You can also confirm the transmission (Tx) power of the controller on the AP profile (wtp-profile) and the FortiAP
(iwconfig), and check the power management (auto-Tx) options.
Result:
wlan00 IEEE 802.11ng ESSID:"signal-check"
Mode:Master Frequency:2.412 GHz Access Point:<MAC add>
Bit Rate:130 Mb/s Tx-Power=28 dBm
The most thorough method to solve signal strength issues is to perform a site survey. To this end, Fortinet offers the
FortiPlanner, downloadable at http://www.fortinet.com/resource_center/product_downloads.html.
The site survey provides you with optimal placement for your APs based on the variables in your environment. You must
provide the site survey detailed information including a floor plan (to scale), structural materials, and more. It will allow
you to place the APs on the map and adjust the radio bands and power levels while providing you with visual wireless
coverage.
Below is a list of mechanisms for gathering further information on the client for Rx strength. The goal is to see how well
the client is receiving the signal from the AP. You can also verify FortiAP signal strength on the client using WiFi client
utilities, or third party utilities such as InSSIDer or MetaGeek Chanalyzer. You can get similar tools from the app stores
on Android and iOS devices.
l Professional Site Survey software (Ekahau, Airmagnet survey Pro, FortiPlanner)
l InSSIDer
l On Windows: "netsh wlan show networks mode=bssid" (look for the BSSID, it’s in % not in dBm!)
l On MacOS: Use the "airport" command:
“/System/Library/PrivateFrameworks/Apple80211.framework/Versions/A/Resources/ai
rport” airport –s | grep <the_bssid> (live scan each time)
l On Droid: WiFiFoFum
Frequency interference
If the wireless signal seems to be strong but then periodically drops, this may be a symptom of frequency interference.
Frequency interference is when another device also emits radio frequency using the same channel, co-channel, or
adjacent channel, thereby overpowering or corrputing your signal. This is a common problem on a 2.4GHz network.
MetaGeek Chanalyzer
You can perform a site survey using spectrum analysis at various points in your environment looking for signal versus
interference/noise. MetaGeek Chanalyzer is an example of a third party utility which shows a noise threshold.
Note that a signal of -95dBm or less will be ignored by Fortinet wireless adapters.
Throughput issues
You can identify delays or lost packets by sending ping packets from your wireless client. If there is more than 10ms of
delay, there may be a problem with your wireless deployment, such as:
l a weak transmit signal from the client (the host does not reach the AP)
l the AP utilization is too high (your AP could be saturated with connected clients)
l interference (third party signal could degrade your AP or client’s ability to detect signals between them)
l weak transmit power from the AP (the AP does not reach the host) — not common in a properly deployed network,
unless the client is too far away
Keep in mind that water will also cause a reduction in radio signal strength for those making use out of outdoor APs or
wireless on a boat.
Performance testing
If the FortiAP gives bad throughput to the client, the link may drop. The throughput or performance can be measured on
your smartphone with third party applications tool such as iPerf and jPerf.
Another way to get a sense of your throughput issues is to measure the speed of a file transfer on your network. Create
a test file at a specific size and measure the speed at which Windows measures the transfer. The command below will
create a 50MB file.
fsutil file createnew test.txt 52428800
The following image shows a network transfer speed of just over 24Mbps. The theoretical speed of 802.11g is 54Mbps,
which is what this client is using. A wireless client is never likely to see the theoretical speed.
TKIP limitation
If you find that throughput is a problem, avoid WPA security encrypted with Temporal Key Integrity Protocol (TKIP) as it
supports communications only at 54Mbps. Use WPA-2 AES instead.
Speeds are very much based on what the client computer can handle as well. The maximum client connection rate of
130Mbps is for 2.4GHz on a 2×2, or 300Mbps for 5Ghz on a 2×2 (using shortguard and channel bonding enabled).
If you want to get more than 54Mbps with 802.11n, do not use legacy TKIP, use CCMP instead. This is standard for
legacy compatibility.
TKIP is not the only possible source of decreased throughput. When a wireless client sends jumbo frames using a
CAPWAP tunnel, it can result in data loss, jitter, and decreased throughput.
Using the following commands you can customize the uplink rates and downlink rates in the CAPWAP tunnel to prevent
fragmentation and avoid data loss.
config wireless-controller wtp
edit new-wtp
(in 5.2, you must enable the override profile: set override-profile enable)
(in 5.4, you must enable override-ip-fragment: set override-ip-fragment enable)
set ip-fragment-preventing [tcp-mss-adjust | icmp-unreachable]
set tun-mtu-uplink [0 | 576 | 1500]
set tun-mtu-downlink [0 | 576 | 1500]
end
end
The default value is 0, however the recommended value will depend on the type of traffic. For example, IPsec in tunnel
mode has 52 bytes of overhead, so you might use 1400 or less for uplink and downlink.
It’s important to know all the elements involved in the CAPWAP association:
l Request
l Response
l DTLS
l Join
l Configuration
All of these are bidirectional. So if the DTLS response is slow, this might be the result of a configuration error. This issue
can also be caused by a certificate during discovery response. You can read more about this in RFC 5416.
Connection issues
If the client has a connectivity issue that is not due to signal strength, the solution varies by the symptom.
Debug
You should also enable client debug on the controller for problematic clients to see the stage at which the client fails to
connect. Try to connect from the problematic client and run the following debug command, which allows you to see the
four-way handshake of the client association:
diagnose wireless-controller wlac sta_filter <client MAC address> 2
The following is a sample debug output for the above command, with successful association/DHCP phases and PSK
key exchange (identified in color):
FG600B3909600253 #
91155.197 <ih> IEEE 802.11 mgmt::assoc_req <== 30:46:9a:f9:fa:34 vap signal-check rId 0 wId 0
00:09:0f:f3:20:45
91155.197 <ih> IEEE 802.11 mgmt::assoc_resp ==> 30:46:9a:f9:fa:34 vap signal-check rId 0 wId 0
00:09:0f:f3:20:45 resp 0
91155.197 <cc> STA_CFG_REQ(15) sta 30:46:9a:f9:fa:34 add ==> ws (0-192.168.35.1:5246) rId 0
wId 0
91155.197 <dc> STA add 30:46:9a:f9:fa:34 vap signal-check ws (0-192.168.35.1:5246) rId 0 wId 0
bssid 00:09:0f:f3:20:45 NON-AUTH
91155.197 <cc> STA add 30:46:9a:f9:fa:34 vap signal-check ws (0-192.168.35.1:5246) rId 0 wId 0
00:09:0f:f3:20:45 sec WPA2 AUTO auth 0
91155.199 <cc> STA_CFG_RESP(15) 30:46:9a:f9:fa:34 <== ws (0-192.168.35.1:5246) rc 0 (Success)
91155.199 <eh> send 1/4 msg of 4-Way Handshake
91155.199 <eh> send IEEE 802.1X ver=1 type=3 (EAPOL_KEY) data len=95 replay cnt 1
91155.199 <eh> IEEE 802.1X (EAPOL 99B) ==> 30:46:9a:f9:fa:34 ws (0-192.168.35.1:5246) rId 0
wId 0 00:09:0f:f3:20:45
91155.217 <eh> IEEE 802.1X (EAPOL 121B) <== 30:46:9a:f9:fa:34 ws (0-192.168.35.1:5246) rId 0
wId 0 00:09:0f:f3:20:45
91155.217 <eh> recv IEEE 802.1X ver=1 type=3 (EAPOL_KEY) data len=117
91155.217 <eh> recv EAPOL-Key 2/4 Pairwise replay cnt 1
91155.218 <eh> send 3/4 msg of 4-Way Handshake
91155.218 <eh> send IEEE 802.1X ver=1 type=3 (EAPOL_KEY) data len=175 replay cnt 2
91155.218 <eh> IEEE 802.1X (EAPOL 179B) ==> 30:46:9a:f9:fa:34 ws (0-192.168.35.1:5246) rId 0
wId 0 00:09:0f:f3:20:45
91155.223 <eh> IEEE 802.1X (EAPOL 99B) <== 30:46:9a:f9:fa:34 ws (0-192.168.35.1:5246) rId 0
wId 0 00:09:0f:f3:20:45
91155.223 <eh> recv IEEE 802.1X ver=1 type=3 (EAPOL_KEY) data len=95
91155.223 <eh> recv EAPOL-Key 4/4 Pairwise replay cnt 2
91155.223 <dc> STA chg 30:46:9a:f9:fa:34 vap signal-check ws (0-192.168.35.1:5246) rId 0 wId 0
bssid 00:09:0f:f3:20:45 AUTH
91155.224 <cc> STA chg 30:46:9a:f9:fa:34 vap signal-check ws (0-192.168.35.1:5246) rId 0 wId 0
00:09:0f:f3:20:45 sec WPA2 AUTO auth 1
91155.224 <cc> STA_CFG_REQ(16) sta 30:46:9a:f9:fa:34 add key (len=16) ==> ws (0-
192.168.35.1:5246) rId 0 wId 0
91155.226 <cc> STA_CFG_RESP(16) 30:46:9a:f9:fa:34 <== ws (0-192.168.35.1:5246) rc 0 (Success)
91155.226 <eh> ***pairwise key handshake completed*** (RSN)
91155.257 <dc> DHCP Request server 0.0.0.0 <== host ADMINFO-FD4I2HK mac 30:46:9a:f9:fa:34 ip
172.16.1.16
91155.258 <dc> DHCP Ack server 172.16.1.1 ==> host mac 30:46:9a:f9:fa:34 ip 172.16.1.16 mask
255.255.255.0 gw 172.16.1.1
where:
l orange represents the association phase,
l blue represents the PSK exchange,
l and green represents the DHCP phase.
It is important to note the messages for a correct association phase, four-way handshake, and DHCP phase.
Clients are not the only device that can fail to connect, of course. A communication problem could arise from the
FortiAP.
Some examples include:
l The FortiAP is not connecting to the wireless controller.
l One FortiAP intermittently disconnects and re-connects.
l All FortiAPs intermittently disconnect and re-connect.
l Unable to Telnet to FortiAP from controller/administrator workstation.
In the above cases:
l Check networking on the distribution system for all related FortiAPs.
l Check the authorization status of managed APs from the wireless controller.
l Restart the cw_acd process (Note: All APs will drop if you do this, and you may be troubleshooting just one AP).
l Check the controller crash log for any wireless controller daemon crash using the following command:
diagnose debug crashlog read
Debug
For a quick assessment of the association communication between the controller and the FortiAP, run the following
sniffer command to see if you can verify that the AP is communicating to the controller by identifying the CAPWAP
communication:
diagnose sniff packet <interface_name> “port 5246” 4
If you do not see this communication, then you can investigate the network or the settings on the AP to see why it is not
reaching the controller.
The following command allows you to collect verbose output from the sniff that can be converted to a PCAP and viewed
in Wireshark.
diagnose sniff packet <interface_name> “port 5246” 6 o l
The image below shows the beginning of the AP’s association to the controller. You can see the discovery Request and
Response at the top.
l Try to connect to the wireless controller from the problematic FortiAP to verify routes exist.
l Enable wtp (FortiAP) debugging on the wireless controller for problematic FortiAPs to determine the point at which
the FortiAP fails to connect:
diag wireless-controller wlac wtp_filter FP112B3X13000193 0-192.168.6.8:5246 2
(replace the serial number and IP address of the FortiAP)
di de console timestamp en
di de application cw_acd 0x7ff
di de en
The previous debug command provides similar output to the sample debug message below for a successful association
between the FortiAP and the wireless controller. This includes the elements of the CAPWAP protocol; the Request,
Response, DTLS, Join, and Configuration (identified in color). All of these are bi-directional, so if the DTLS response is
slow, it may be an example of a configuration error.
56704.575 <msg> DISCOVERY_REQ (12) <== ws (0-192.168.35.1:5246)
56704.575 <msg> DISCOVERY_RESP (12) ==> ws (0-192.168.35.1:5246)
56707.575 <msg> DISCOVERY_REQ (13) <== ws (0-192.168.35.1:5246)
56707.575 <msg> DISCOVERY_RESP (13) ==> ws (0-192.168.35.1:5246)
56709.577 <aev> - CWAE_INIT_COMPLETE ws (0-192.168.35.1:5246)
56709.577 <aev> - CWAE_LISTENER_THREAD_READY ws (0-192.168.35.1:5246)
56709.577 <fsm> old CWAS_START(0) ev CWAE_INIT_COMPLETE(0) new CWAS_IDLE(1)
56709.577 <fsm> old CWAS_IDLE(1) ev CWAE_LISTENER_THREAD_READY(1) new CWAS_DTLS_SETUP(4)
56709.623 <aev> - CWAE_DTLS_PEER_ID_RECV ws (0-192.168.35.1:5246)
56709.623 <aev> - CWAE_DTLS_AUTH_PASS ws (0-192.168.35.1:5246)
56709.623 <aev> - CWAE_DTLS_ESTABLISHED ws (0-192.168.35.1:5246)
56709.623 <fsm> old CWAS_DTLS_SETUP(4) ev CWAE_DTLS_PEER_ID_RECV(7) new CWAS_DTLS_AUTHORIZE(2)
56709.623 <fsm> old CWAS_DTLS_AUTHORIZE(2) ev CWAE_DTLS_AUTH_PASS(3) new CWAS_DTLS_CONN(5)
56709.623 <fsm> old CWAS_DTLS_CONN(5) ev CWAE_DTLS_ESTABLISHED(8) new CWAS_JOIN(7)
56709.625 <msg> JOIN_REQ (14) <== ws (0-192.168.35.1:5246)
56709.625 <aev> - CWAE_JOIN_REQ_RECV ws (0-192.168.35.1:5246)
56709.626 <fsm> old CWAS_JOIN(7) ev CWAE_JOIN_REQ_RECV(12) new CWAS_JOIN(7)
56709.629 <msg> CFG_STATUS (15) <== ws (0-192.168.35.1:5246)
56709.629 <aev> - CWAE_CFG_STATUS_REQ ws (0-192.168.35.1:5246)
56709.629 <fsm> old CWAS_JOIN(7) ev CWAE_CFG_STATUS_REQ(13) new CWAS_CONFIG(8)
56710.178 <msg> CHG_STATE_EVENT_REQ (16) <== ws (0-192.168.35.1:5246)
56710.178 <aev> - CWAE_CHG_STATE_EVENT_REQ_RECV ws (0-192.168.35.1:5246)
56710.178 <fsm> old CWAS_CONFIG(8) ev CWAE_CHG_STATE_EVENT_REQ_RECV(23) new CWAS_DATA_CHAN_
SETUP(10)
56710.220 <aev> - CWAE_DATA_CHAN_CONNECTED ws (0-192.168.35.1:5246)
56710.220 <msg> DATA_CHAN_KEEP_ALIVE <== ws (0-192.168.35.1:5246)
56710.220 <aev> - CWAE_DATA_CHAN_KEEP_ALIVE_RECV ws (0-192.168.35.1:5246)
56710.220 <msg> DATA_CHAN_KEEP_ALIVE ==> ws (0-192.168.35.1:5246)
56710.220 <fsm> old CWAS_DATA_CHAN_SETUP(10) ev CWAE_DATA_CHAN_CONNECTED(32) new CWAS_DATA_
CHECK(11)
56710.220 <aev> - CWAE_DATA_CHAN_VERIFIED ws (0-192.168.35.1:5246)
56710.220 <fsm> old CWAS_DATA_CHECK(11) ev CWAE_DATA_CHAN_KEEP_ALIVE_RECV(35) new CWAS_DATA_
CHECK(11)
56710.220 <fsm> old CWAS_DATA_CHECK(11) ev CWAE_DATA_CHAN_VERIFIED(36) new CWAS_RUN(12)
56710.228 <msg> WTP_EVENT_REQ (17) <== ws (0-192.168.35.1:5246)
56710.228 <aev> - CWAE_WTP_EVENT_REQ_RECV ws (0-192.168.35.1:5246)
56710.228 <fsm> old CWAS_RUN(12) ev CWAE_WTP_EVENT_REQ_RECV(42) new CWAS_RUN(12)
56710.230 <msg> CFG_UPDATE_RESP (1) <== ws (0-192.168.35.1:5246) rc 0 (Success)
56710.230 <aev> - CWAE_CFG_UPDATE_RESP_RECV ws (0-192.168.35.1:5246)
56710.230 <msg> WTP_EVENT_REQ (18) <== ws (0-192.168.35.1:5246)
56710.230 <aev> - CWAE_WTP_EVENT_REQ_RECV ws (0-192.168.35.1:5246)
56710.230 <fsm> old CWAS_RUN(12) ev CWAE_CFG_UPDATE_RESP_RECV(37) new CWAS_RUN(12)
56710.230 <fsm> old CWAS_RUN(12) ev CWAE_WTP_EVENT_REQ_RECV(42) new CWAS_RUN(12)
56710.231 <msg> WTP_EVENT_REQ (19) <== ws (0-192.168.35.1:5246)
56710.231 <aev> - CWAE_WTP_EVENT_REQ_RECV ws (0-192.168.35.1:5246)
56710.231 <fsm> old CWAS_RUN(12) ev CWAE_WTP_EVENT_REQ_RECV(42) new CWAS_RUN(12)
56710.232 <msg> CFG_UPDATE_RESP (2) <== ws (0-192.168.35.1:5246) rc 0 (Success)
56710.232 <aev> - CWAE_CFG_UPDATE_RESP_RECV ws (0-192.168.35.1:5246)
56710.232 <fsm> old CWAS_RUN(12) ev CWAE_CFG_UPDATE_RESP_RECV(37) new CWAS_RUN(12)
56710.233 <msg> WTP_EVENT_REQ (20) <== ws (0-192.168.35.1:5246)
56710.233 <aev> - CWAE_WTP_EVENT_REQ_RECV ws (0-192.168.35.1:5246)
56710.233 <fsm> old CWAS_RUN(12) ev CWAE_WTP_EVENT_REQ_RECV(42) new CWAS_RUN(12)
56712.253 < . > AC (2) -> WTP (0-192.168.35.1:5246) State: CWAS_RUN (12) accept 3 live 3 dbg
00000000 pkts 12493 0
56715.253 < . > AC (2) -> WTP (0-192.168.35.1:5246) State: CWAS_RUN (12) accept 3 live 6 dbg
00000000 pkts 12493 0
56718.253 < . > AC (2) -> WTP (0-192.168.35.1:5246) State: CWAS_RUN (12) accept 3 live 9 dbg
00000000 pkts 12493 0
56719.253 <aev> - CWAE_AC_ECHO_INTV_TMR_EXPIRE ws (0-192.168.35.1:5246)
56719.253 <fsm> old CWAS_RUN(12) ev CWAE_AC_ECHO_INTV_TMR_EXPIRE(39) new CWAS_RUN(12)
56719.576 <msg> ECHO_REQ (21) <== ws (0-192.168.35.1:5246)
56719.576 <aev> - CWAE_ECHO_REQ_RECV ws (0-192.168.35.1:5246)
56719.577 <fsm> old CWAS_RUN(12) ev CWAE_ECHO_REQ_RECV(27) new CWAS_RUN(12)
where:
l orange represents the Discovery phase,
l blue indicates that the control channels have been established using DTLS,
l green represents the access point Discovery and Join phase,
l purple represents the Clear Text channel,
l and pink indicates that the FortiAP successfully connected to the wireless controller.
General problems
Not all WiFi problems are related to signal strength, interference, or misconfiguration. The following OSI model
identifies some of the more common issues per layer.
Best practices for troubleshooting vary depending on the affected layer (see below).
In high density deployments, multiple APs are used, and each one services an area called a cell. However, these cells
can cause interference with each other. This is a common problem. The radio signal from one AP interferes with, or
cancels out, the radio signal from another AP.
In the following diagram, note the interference zone created by one radio, causing interference on its neighbouring APs.
The interference zone can be twice the radius of the signal, and the signal at its edge can be -67dBm.
For best results, use a ‘honeycomb’ pattern as a deployment strategy. The idea is to stagger repeated channels furthest
from each other to avoid interference.
For TCP/IP layers and above, a common source of latency, or slowness in the wireless traffic, is too many broadcasts or
multicasts. These types of issues can result from non-business and/or unwanted traffic.
To resolve issues at the TCP/IP layer and above:
Packet sniffer
Capturing the traffic between the controller and the FortiAP can help you identify most FortiAP and client connection
issues.
This section describes the following recommended packet sniffing techniques:
l CAPWAP packet sniffer on page 689
l Wireless traffic packet sniffer on page 690
Result:
WTP 0-FortiAP2223X11000107 Plain Control: enabled
l On the FortiAP:
cw_diag plain-ctl 1
Result:
Current Plain Control: enabled
Note that some issues are related to the keep-alive for control and data channel.
l Data traffic on UDP port 5247 is not encrypted. The data itself is encrypted by the wireless security mechanism.
Data traffic is helpful to troubleshoot most of the issues related to station association, EAP authentication, WPA
key exchange, roaming, and FortiAP configuration.
You can also set up a host or server to which you can forward the CAPWAP traffic:
1. Configure the host/server to which CAPWAP traffic is forwarded:
diagnose wireless-controller wlac sniff-cfg <Host_IP_address> 88888
Result:
Current Sniff Server: 192.168.25.41, 23352
2. Choose which traffic to capture, the interface to which the FortiAP is connected, and the FortiAP’s serial number:
Result:
WTP 0-FortiAP2223X11000107 Sniff: intf port2 enabled (control and data message)
In the above syntax, the ‘2’ captures the control and data message—’1′ would capture only the control message, and ‘0’
would disable it.
3. Run Wireshark on the host/server to capture CAPWAP traffic from the controller.
• Decode the traffic as IP to check inner CAPWAP traffic.
The following image shows an example of a CAPWAP packet capture, where you can see: the Layer 2 header; the
sniffed traffic encapsulated into Internet Protocol for transport; CAPWAP encapsulated into UDP for sniffer purpose and
encapsulated into IP; CAPWAP control traffic on UDP port 5246; and CAPWAP payload.
The second recommended technique consists of sniffing the wireless traffic directly ‘on the air’ using your FortiAP.
Packet captures are useful for troubleshooting all wireless client related issues because you can verify data rate and
802.11 parameters, such as radio capabilities, and determine issues with wireless signal strength, interference, or
congestion on the network.
A radio can only capture one frequency at a time; one of the radios is set to sniffer mode depending on the traffic or
channel required. You must use two FortiAPs to capture both frequencies at the same time.
l Set a radio on the FortiAP to monitor mode.
iwconfig wlan10
Result:
wlan10 IEEE 802.11na ESSID:""
Mode:Monitor Frequency:5.18 GHz Access Point: Not-Associated
Syntax
The following syntax demonstrates how to set the radio to sniffer mode (configurable from the CLI only). Sniffer mode
provides options to filter for specific traffic to capture. Notice that you can determine the buffer size, which channel to
sniff, the AP’s MAC address, and select if you want to sniff the beacons, probes, controls, and data channels.
configure wireless-controller wtp-profile
edit <profile_name>
configure <radio>
set mode sniffer
set ap-sniffer-bufsize 32
set ap-sniffer-chan 1
set ap-sniffer-addr 00:00:00:00:00:00
set ap-sniffer-mgmt-beacon enable
set ap-sniffer-mgmt-probe enable
set ap-sniffer-mgmt-other enable
set ap-sniffer-ctl enable
set ap-sniffer-data enable
end
next
end
Once you’ve performed the previous CLI configuration, you’ll be able to see the packet sniffer mode selected in the GUI
dashboard under WiFi & Switch Controller > FortiAP Profiles and WiFi & Switch Controller > Managed
FortiAPs. Bear in mind that if you change the mode from the GUI, you’ll have to return to the CLI to re-enable the
Sniffer mode.
To disable the sniffer profile in the CLI, use the following commands:
Caution: If you change the radio mode before sending the file wl_sniff.cap to an external TFTP, the file will be deleted
and you will lose your packet capture.
The following image shows an example of the AP packet capture. Note the capture header showing channel 36; the
beacon frame; the source, destination, and BSSID of the beacon frame; and the SSID of the beacon frame.
For a comprehensive list of useful debug options you can use the following help commands on the controller:
diagnose wireless-controller wlac help
(this command lists the options available that pertain to the wireless controller)
Sample outputs
Syntax
diagnose wireless-controller wlac -c vap
(this command lists the information about the virtual access point, including its MAC address,
the BSSID, its SSID, the interface name, and the IP address of the APs that are broadcasting
it)
Result:
bssid ssid intf vfid:ip-port rId wId
00:09:0f:d6:cb:12 Office Office ws (0-192.168.3.33:5246) 0 0
00:09:0f:e6:6b:12 Office Office ws (0-192.168.1.61:5246) 0 0
06:0e:8e:27:dc:48 Office Office ws (0-192.168.3.36:5246) 0 0
0a:09:0f:d6:cb:12 public publicAP ws (0-192.168.3.33:5246) 0 1
Syntax
diagnose wireless-controller wlac -c darrp
(this command lists the information pertaining to the radio resource provisioning statistics,
including the AP serial number, the number of channels set to choose from, and the operation
channel. Note that the 5GHz band is not available on these APs listed)
Result:
wtp_id rId base_mac index nr_chan vfid 5G oper_chan age
FAP22A3U10600400 0 00:09:0f:d6:cb:12 0 3 0 No 1 87588
FW80CM3910601176 0 06:0e:8e:27:dc:48 1 3 0 No 6 822
In this example, you use a RADIUS server to authenticate your WiFi clients.
The RADIUS server is a FortiAuthenticator (v4.00-build0008) that is used authenticate users who belong to the
employees user group.
Go to Authentication > User Management > Local Users and create a user account.
User Role settings are available after you click OK.
Create additional user accounts as needed, one for each employee.
Go to Authentication > User Management > User Groups and create the local user group “employees” on the
FortiAuthenticator.
Go to Authentication > RADIUS Service > Clients and create a client account.
Enable all of the EAP types.
Go to User & Device > RADIUS Servers and add the FortiAuthenticator as a RADIUS server.
Go to Network > Interfaces and configure a dedicated interface for the FortiAP.
Go to Policy & Objects > IPv4 Policy and add a policy that allows WiFi users to access the Internet.
Results
This recipe will walk you through the configuration of FortiAuthenticator as the RADIUS server for a FortiGate wireless
controller. WPA2-Enterprise with 802.1X authentication can be used to authenticate wireless users with
FortiAuthenticator. 802.1X utilizes the Extensible Authentication Protocol (EAP) to establish a secure tunnel between
participants involved in an authentication exchange.
EAP-TLS is the most secure form of wireless authentication because it replaces the client username/password with a
client certificate. Every end user, including the authentication server, that participates in EAP-TLS must possess at least
two certificates: 1) a client certificate signed by the certificate authority (CA) and 2) a copy of the CA root certificate.
This recipe specifically focus on the configuration of the FortiAuthenticator, FortiGate and Windows 7 computer.
The FortiAuthenticator will act as the certificate authority for all certificates authenticated for client access. To enable
this functionality, a self-signed root CA certificate must be generated.
On the FortiAuthenticator, go to Certificate Management > Certificate Authorities > Local CAs. Click Create
New. Complete the information in the fields pertaining to your organization.
In order for the FortiAuthenticator to use a certificate in mutual authentication (supported by EAP‐
TLS), a local services
certificate has to be created on behalf of the FortiAuthenticator.
Go to Certificate Management > End Entities > Local Services. Click Create New. Complete the information in
the fields pertaining to your organization.
In order for the FortiAuthenticator to present the newly created Local Services certificate as its authentication to the
WiFi client, the RADIUS-‐ EAP must be configured to use this certificate.
Go to Authentication > RADIUS Service > EAP. Click Create New. Select the corresponding Local Services
certificate in the EAP Server Certificate section. Choose the Local CA certificate previous configured in the Local
CAs section.
The FortiAuthenticator has to be configured to allow RADIUS clients to make authorization requests to it.
Go to Authentication > RADIUS Service > Clients. Click Create New. Enter Name, then Client name IP which is
the FortiGate’s IP address. Enter the Secret (password). On Authentication method select Password-only
authentication and on Username input format select username@realm.
EAP-‐ TLS should be the only EAP type selected to prevent fallback to a less secure version of authentication if a
certificate is not presented by the WiFi client.
The authentication of the WiFi client will be tied to a user account on the FortiAuthenticator. In this scenario, a local
user will be configured but remote users associated with LDAP can be configured as well.
Go to Authentication > User Management > Local Users. Click Create New. Fill out applicable user information.
The certificate created locally on the FortiAuthenticator will be associated with the local user. It is important to note that
the Name (CN) must match the username exactly of the user that is registered in the FortiAuthenticator (i.e. eap‐
user).
Go to Certificate Management > End Entities > Users. Click Create New. Fill out applicable user information to
map the certificate to the correct user.
In order to proxy the authentication request from the wireless client, the FortiGate will need to have a RADIUS server to
submit the authentication request to.
On the FortiGate, go to User & Device > RADIUS Servers. Select Create New. Type FortiAuth. Enter the
FortiAuthenticator’s IP address and the Server Secret (password). Optionally, you can click Test Connectivity. Enter a
RADIUS user’s ID and password. The result should be “Successful”.
In order for the WiFi client to connect using its certificate a SSID has to be configured on the FortiGate to accept this
type of authentication.
Go to WiFi & Switch Controller > SSID . Create an SSID and set up DHCP for clients.
In order for the WiFi client to authenticate with the RADIUS server, the user certificate created in the FortiAuthenticator
must first be exported.
On the FortiAuthenticator, go to Certificate Management > End Entities > Users. Click the checkbox beside the
certificate. Click Export PKCS#12.
In the Export User Certificate and Key File type a password in Passphrase, and confirm it. This password will be
used when importing the certificate into a Windows 7 computer. Click OK.
Click Download PKCS#12 file to pull this certificate to the Widows 7 computer. Click Finish.
On the Windows 7 computer, double-click the downloaded certificate file from the FortiAuthenticator. This will launch
the Welcome to Certificate Import Wizard. Click Next.
Make sure the correct certificate is shown in the File Name section in the File to Import window. Click Next.
Below Password, type the password created on the FortiAuthenticator during the export of the certificate. Select Mark
this key as exportable. Leave remaining defaults. Click Next.
In the Certificate Store, choose the Place all certificates in the following store. Click Browse and choose
Personal. Click Next, and then Finish. A dialog box will show up confirming the certificate was imported successfully.
Create a new wireless SSID for this secure connection, in this case EAP-TLS. On Windows 7, got to Control Panel >
Network and Sharing Center > Manage Wireless Networks > Add. Select Security type: WPA2-Enterprise and
Encryption type: AES.
Modify the newly created wireless connection EAP-TLS by right clicking and choosing Properties.
On EAP-TLS Wireless Network Properties, Under Choose a network authentication method select Microsoft:
Smart card or other certificates. Then click on Settings.
On Smart Card or other Certificates Properties. Under When connecting, select Use a certificate on this
computer, and check Use simple certificate selection. Click OK and click OK.
Please note, for simplification purposes, the Validate server certificate has been disabled but EAP-‐ TLS allows the
client to validate the server as well as the server validate the client. To enable this, you will need to import the CA from
the FortiAuthenticator to the Windows 7 computer and make sure that it is enabled as a Trusted Root Certification
Authority.
The configuration for the Windows 7 computer has been completed and the user should be able to authenticate to WiFi
via the certificate without using username and password.
When the user attempts to authenticate to WiFi using the certificate, they will have a specific log entry in the
FortiAuthenticator.
The log on the FortiGate shows plenty of details, such as the client’s MAC address, IP address, SSID, Security Mode,
Encryption, AP, Radio, Band and Channel
This is an example of wireless single sign-on (WSSO) with a FortiGate and FortiAuthenticator. The WiFi users are
teachers and students at a school. These users each belong to a user group, either teachers (smaguire) or students
(whunting). The FortiAuthenticator performs user authentication and passes the user group name to the FortiGate so
that the appropriate security policy is applied.
This recipe assumes that an SSID and a FortiAP are configured on the FortiGate unit. In this configuration, you will be
changing the existing SSID’s WiFi settings so authentication is provided by the RADIUS server. To learn more about
configuring FortiAP, see Setting up WiFi with a FortiAP on page 512.
For this example, the student security policy applies a more restrictive web filter.
On the FortiAuthenticator, go to Authentication > RADIUS Service > Clients and create a new account.
Enter a Name, the Internet-facing IP address of the FortiGate in Client name/IP, and enter a Secret.
Select the Password-only authentication method, select the Local users realm, and enable all EAP types.
Go to Authentication > User Management > Local Users and select Create New.
Create one teacher user (smaguire) and another student user (whunting).
Note that, after you create a user, RADIUS Attributes appears as an option.
If your configuration involves multiple users, it is more efficient to add RADIUS attributes in their respective user groups,
in the next step.
Go to Authentication > User Management > User Groups and create two user groups: teachers and students.
Add the users to their respective groups.
Add the Fortinet-Group-Name RADIUS attribute to each group, which specifies the user group name to be sent to the
FortiGate.
On the FortiGate, go to User & Device > RADIUS Servers and select Create New.
Enter a Name, the Internet-facing IP address of the FortiAuthenticator in Primary Server IP/Name, and enter the
same Primary Server Secret as you entered on the FortiAuthenticator.
You can optionally select Test Connectivity. Enter a RADIUS user’s name and password. The result should be
Successful.
Go to User & Device > User Groups and create two groups named the same as the ones created on the
FortiAuthenticator.
Go to Policy & Objects > IPV4 Policy and select Create New.
Create two policies with WiFi-to-Internet access: one policy with Source set to the students user group, and the other
set to teachers. Make sure to add the SSID address (example-wifi) to both policies also.
The student policy has a more restrictive Web Filter enabled.
Go to WiFi & Switch Controller > SSID and edit your pre-existing SSID interface.
Under WiFi Settings, set Security Mode to WPA2 Enterprise, set Authentication to RADIUS Server, and add
the RADIUS server configured on the FortiGate earlier from the dropdown menu.
8. Results
Then on the FortiGate go to Monitor > Firewall User Monitor. From here you can verify the user, the user group, and
that the WSSO authentication method was used.
You can also go to FortiView > Policies to verify that the appropriate security policy was applied.
This is an example of wireless single sign-on (WSSO) with a FortiGate. The WiFi users are students at a school. They
belong to a Windows Active Directory (AD) group called WiFiAccess. The Network Policy Server (NPS) or RADIUS
server performs user authentication and passes the WiFi group attribute to the FortiGate so that the appropriate
security policy is applied.
There is an alternative way to setup WiFi with WSSO. To learn more about it, see WiFi with WSSO using Windows NPS
and FortiGate Groups on page 737
From the NPS, right click on RADIUS Clients, and create an entry for the FortiGate. Enter the FortiGate’s IP address.
Enter the Shared secret (password).
Right click Connection Request Policies under Policies and select New. Leave default values for Overview and
Settings tab. Under Conditions tab, enter Client IPv4 Address as the FortiGate’s IP address.
Right click Network Policies under Policies and select New to create a new policy. Leave default values in Overview
tab. In Conditions tab, click on Add, select Windows Group, then select Add. Finally Add Groups, then enter
WiFiAccess, and select OK.
In Constraints tab, under Authentication Methods, click Add, then select Microsoft: Protected EAP (PEAP) then
OK. Next select Microsoft Encrypted Authentication version 2 (MS-CHAP-v2), and finally select User can
change password after it has expired and select OK.
In Settings tab, go to RADIUS Attributes > Vendor Specific, then click Add, select Custom under Vendor and
Vendor Specific under Attributes select Add. On Attribute Information window, click Add, type 12356 next to
Enter Vendor Code, next select Yes. It conforms. Click on Configure Attribute and a new window pops up, on
Vendor-assigned attribute number enter 1, on Attribute format select String, and in Attribute value enter WiFi
and select OK.
On the FortiGate, go to User & Device > RADIUS Servers. Select Create New DC-RADIUS. Enter the Domain
Controller IP address and the Server Secret that you entered on NPS. Optionally, you can click Test Connectivity.
Enter a RADIUS user’s ID and password. The result should be “Successful”.
Go to User & Device > User Groups. Create a group that matches the WiFi RADIUS attribute. Do not add any
members or remote servers.
Go to WiFi & Switch Controller > SSID . Create an SSID and set up DHCP for clients.
Go to Policy & Objects > IPv4 Policy. Create a WiFi-to-Internet policy. Use WiFi group as the Source.
8. Results
Connect to the WiFi network, authenticate, and browse the Internet. Try this with a user that belongs to the
WiFiAccess Windows AD Group.
Go to Monitor > Firewall User Monitor. You can see the User Name, User Group and verify that WSSO
authentication Method was used.
This is an example of wireless single sign-on (WSSO) with a FortiGate. The WiFi users are students at a school. These
users belong to a Windows Active Directory (AD) group called WiFiAccess. When users enter their WiFi username and
password, the FortiGate checks the local group WiFi. Since the group has been set up with remote RADIUS server, the
FortiGate performs user authentication against the Network Policy Server (NPS) or RADIUS server. If the user is
authenticated successfully, the FortiGate will check for a policy that allows the WiFi group access.
There is an alternative way to setup WiFi with WSSO. To learn more about it, see WiFi with WSSO using Windows NPS
and Attributes on page 729.
From the NPS, right click on RADIUS Clients, and create an entry for the FortiGate. Enter the FortiGate’s IP address.
Enter the Shared secret (password).
Right click Connection Request Policies under Policies and select New. Leave default values for Overview and
Settings tab. Under Conditions tab, enter Client IPv4 Address as the FortiGate’s IP address.
Right click Network Policies under Policies and select New to create a new policy. Leave default values in Overview
tab. In Conditions tab, click on Add, select Windows Group, then select Add. Finally Add Groups, then enter
WiFiAccess, and select OK.
In Constraints tab, under Authentication Methods, click Add, then select Microsoft: Protected EAP (PEAP) then
OK. Next select Microsoft Encrypted Authentication version 2 (MS-CHAP-v2), and finally select User can
change password after it has expired and select OK.
On the FortiGate, go to User & Device > RADIUS Servers. Select Create New DC-RADIUS. Enter the Domain
Controller IP address and the Server Secret that you entered on NPS. Optionally, you can click Test Connectivity.
Enter a RADIUS user’s ID and password. The result should be “Successful”.
Go to User & Device > User Groups. Create a group named WiFi. Click on Create New underRemote groups,
then enter DC-RADIUS for Remote Server, and Any for Groups. Select OK, and OK again.
Go to WiFi & Switch Controller > SSID . Create an SSID and set up DHCP for clients.
Set WPA2-Enterprise with Local authentication, and choose the local group WiFi.
Go to Policy & Objects > IPv4 Policy. Create a WiFi-to-Internet policy. Use WiFi group as the Source.
8. Results
Connect to the WiFi network, authenticate, and browse the Internet. Try this with a user that belongs to the
WiFiAccess Windows AD Group.
Go to Monitor > Firewall User Monitor. You can see the User Name, User Group and verify that WSSO
authentication Method was used.