FortiOS 5.4 Cookbook PDF

FortiOS - Cookbook
Version 5.4
FORTINET DOCUMENT LIBRARY
https://docs.fortinet.com
FORTINET VIDEO GUIDE

https://video.fortinet.com
FORTINET BLOG
https://blog.fortinet.com
CUSTOMER SERVICE & SUPPORT

https://support.fortinet.com
FORTINET TRAINING & CERTIFICATION PROGRAM

https://www.fortinet.com/support-and-training/training.html
NSE INSTITUTE
https://training.fortinet.com
FORTIGUARD CENTER
https://fortiguard.com/
END USER LICENSE AGREEMENT

https://www.fortinet.com/doc/legal/EULA.pdf
FEEDBACK
Email: techdoc@fortinet.com
October 08, 2019

FortiOS 5.4 Cookbook
01-540-000000-20191008
TABLE OF CONTENTS
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
FortiOS Cookbook Fortinet Technologies Inc.

4
3. Adding the signature to the default Application Control profile 67

4. Adding the default profile to a security policy 68
5. Results 68
Bootstrapping a FortiGate-AWS 70
1. Storing configuration and license information 70
2. Setting up IAM roles 70
3. Creating S3 buckets with license and firewall configurations 70
4. Launching the instance using roles and user data 71
5. Result 72
Captive Portal bypass for Apple updates and Chromebook authentication 74
1. Creating a user account and user group 75
2. Creating firewall addresses 75
3. Creating the SSID 77
4. Creating the security policy 77
5. Connecting and authorizing the FortiAP 80
6. Results 81
Captive portal two-factor authentication with FortiToken Mobile 85
1. Enabling FortiToken for elainemarley 85
2. Adding a user account to FortiToken Mobile 86
3. Editing the internal interface 92
4. Customizing the captive portal login page 92
5. Results 94
Captive portal WiFi access control 96
1. Enabling HTTPS authentication 96
2. Creating the user 97
3. Creating the user group 97
4. Creating the SSID 97
5. Creating the security policy 99
6. Connecting and authorizing the FortiAP 100
7. Results 102
Captive portal WiFi access with a FortiToken-200 105
1. Adding the FortiToken 105
2. Editing the user and assigning the FortiToken 106
3. Results 106
Configuring ADVPN in FortiOS 5.4 - Redundant hubs (Expert) 108
1. Configure HUB1 110
2. Configure HUB2 113
3. Configure the Spoke FortiGates 116
Results 118
Configuring ADVPN in FortiOS 5.4 (Expert) 126
1. Configure the Hub FortiGate 127
2. Configure the Spoke FortiGates 129
Results 131

5
Configuring Hair-pinning on a FortiGate 134

Scenario: 134
1. Create a VIP 135
Verifying the situation 135
2. Create a policy 136
3. Results 137
Configuring LDAP over SSL with Windows Active Directory 139
1. Exporting the LDAPS Certificate in Active Directory (AD) 139
2. Importing the LDAPS Certificate into the FortiGate 143
3. Creating the LDAPS Server object in the FortiGate 145
4. Results 146
Cooperative Security Fabric 148
1. Installing a FortiGate in NAT/Route mode 148
2. Installing internal FortiGates and enabling a Security Fabric 149
3. Adding FortiAnalyzer to a Security Fabric 149
4. High Availability with two FortiGates 149
5. Setting up an internal network with a managed FortiSwitch 150
6. Adding endpoint control to a Security Fabric 151
7. Adding FortiManager to a Security Fabric 152
Creating a virtual wire pair 154
1. Adding a virtual wire pair 154
2. Adding virtual wire pair firewall policies 155
3. Results 157
Creating security policies 160
1. Configuring the Internet policy 160
2. Creating the Mobile policy 161
3. Defining SysAdminPC 164
4. Creating the Admin policy 164
5. Ordering the policy table 165
6. Results 166
Encryption hash used by FortiOS for local pwd/psk 168
Enforcing network security using a FortiClient Profile 170
1. Enabling endpoint control on the FortiGate 171
2. Enforcing FortiClient registration on the internal interface 171
3. Configuring the FortiClient Profile 171
4. Results 172
Extending WiFi range with mesh topology 179
1. Creating the backhaul SSID 179
2. Creating the client SSID 180
3. Creating the FortiAP Profile 181
4. Configuring the security policy 182
5. Configuring an interface dedicated to FortiAP 183
6. Preauthorizing FortiAP-1 184

6
7. Configuring FortiAP-2 for mesh operation 184

8. Connecting and authorizing the FortiAPs 185
9. Results 186
Fixed Port Range IP Pools algorithm 187
Determining the IP address from the pool 187
Defining the variables 187
The equations 188
Setting values for the example 188
First equation – determining the factor 188
Second equation – determining the IP address from the pool 188
TCP ports 189
Defining the variables 189
Setting values for the example 189
The equations 190
First equation – determining the port share 190
Second equation – determining the first port choice for the session 190
Additional information 191
FortiAuthenticator as a Certificate Authority 193
1. Creating a new CA on the FortiAuthenticator 193
2. Installing the CA on the network 195
Internet Explorer and Chrome 195
Firefox 197
3. Creating a CSR on the FortiGate 199
4. Importing and signing the CSR on the FortiAuthenticator 200
5. Importing the local certificate to the FortiGate 201
6. Configuring the certificate for the GUI 201
7. Results 202
FortiGate installation troubleshooting 203
1. Check your equipment and cables 203
2. Check the FortiGate LEDs 203
3. Ping the FortiGate 203
4. Check the FortiGate interface configurations (NAT/Route mode only) 203
5. Verify the security policy configuration 204
6. Verify the static routing configuration (NAT/Route mode only) 204
7. Verify that you can connect to the Internet-facing interface’s IP address (NAT/Route
mode only) 204
8. Verify that you can connect to the gateway provided by your ISP 204
9. Ping an IP on the Internet 204
10. Verify the DNS configuration 205
11. Resetting the FortiGate 205
12. Contacting Fortinet Support 205
FortiGate logging troubleshooting 206
No log messages appear in the GUI. 206
Logs from a FortiAnalyzer, FortiManager, or from FortiCloud do not appear in the GUI. 206
The FortiGate unit’s performance level has decreased since enabling disk logging. 206

7
Logging to a FortiAnalyzer unit is not working as expected. 206

FortiGate registration and basic settings 208
1. Registering your FortiGate 208
2. Setting the system time 210
3. Changing the default admin password 211
4. Results 212
5. (Optional) Restricting administrative access to a trusted host 213
FortiToken two-factor authentication with RADIUS on a FortiAuthenticator 215
1. Adding the FortiToken to FortiAuthenticator 215
2. Adding the FortiToken user to FortiAuthenticator 216
3. Creating the RADIUS Client on FortiAuthenticator 217
4. Connecting the FortiGate to the RADIUS Server 218
5. Configuring the SSL VPN on FortiGate 220
6. Results 222
Guest WiFi accounts 225
1. Creating a WiFi guest user group 225
2. Creating a guest SSID that uses Captive Portal 226
3. Creating a security policy for WiFi guests 228
4. Creating a restricted admin account for guest user management 229
5. Creating a guest user account 230
6. Results 232
High Availability with FGCP (Expert) 233
1. Configuring the primary FortiGate 233
2. Configuring the backup FortiGate 236
3. Connecting the cluster 238
4. Checking cluster operation and disabling override 238
5. Results 239
High Availability with two FortiGates 241
1. Setting up registration and licensing 242
2. Configuring the Primary FortiGate for HA 242
3. Connecting the backup FortiGate 244
4. Configuring the backup FortiGate for HA 244
5. Viewing the cluster status 245
6. Results 247
7. (Optional) Upgrading the firmware for the HA cluster 247
Inspecting traffic content using flow-based inspection 250
1. Changing from proxy to flow mode 250
2. Configuring the AntiVirus profile 251
3. Enabling AntiVirus in a policy 252
4. Results 253
Installing a FortiGate in NAT/Route mode 256
1. Connecting the network devices and logging onto the FortiGate 256
2. Configuring the FortiGate's interfaces 257

8
3. Adding a default route 259

4. (Optional) Setting the FortiGate's DNS servers 259
5. Creating a policy to allow traffic from the internal network to the Internet 259
5. Results 260
Installing a FortiGate in Transparent mode 263
1. Changing the FortiGate's operation mode 263
2. (Optional) Setting the FortiGate's DNS servers 264
3. Creating a policy to allow traffic from the internal network to the Internet 265
4. Connecting the network devices 265
5. Results 266
Installing internal FortiGates and enabling Security Fabric 269
1. Configuring External to connect to Accounting 269
2. Configuring the Accounting FortiGate 271
3. Installing and configuring the Marketing FortiGate 273
4. Configuring OSPF routing between the FortiGates 273
5. Enabling the Cooperative Security Fabric 275
6. Results 276
7. (Optional) Adding security profiles to the fabric 276
Integrating a FortiGate with FortiClient EMS 279
1. Configuring FortiClient EMS 279
2. (Optional) Importing Endpoint Profiles into FortiClient EMS 282
3. Enabling and enforcing FortiHeartBeat on the FortiGate 283
4. (Optional) FortiClient installer configuration 284
5. Results 286
IPsec VPN for iOS 9 293
1. Configuring the IPsec VPN using the IPsec VPN Wizard 293
2. Connecting to the IPsec VPN from iPhone 297
3. Results 301
IPsec VPN for Windows Phone 10 302
2. Connecting to the IPsec VPN from the Windows Phone 10 305
3. Results 308
IPsec VPN to Microsoft Azure 310
1. Configuring the Microsoft Azure virtual network 310
2. Specifying the Microsoft Azure DNS server 313
3. Creating the Microsoft Azure virtual network gateway 314
4. Creating the Microsoft Azure local network gateway 317
5. Configuring the FortiGate tunnel 318
6. Creating the Azure firewall object 321
7. Creating the FortiGate firewall policies 322
8. Creating the FortiGate static route 324
9. Creating a Microsoft Azure Site-to-Site VPN connection 325
10. Results 327

9
IPsec VPN troubleshooting 332

The options to configure policy-based IPsec VPN are unavailable. 332
The VPN tunnel goes down frequently. 333
The pre-shared key does not match (PSK mismatch error). 333
The SA proposals do not match (SA proposal mismatch). 334
Pre-existing IPsec VPN tunnels need to be cleared. 334
LAN interface connection 334
Dialup connection 335
Troubleshooting VPN connections 335
VPN troubleshooting tips 336
General troubleshooting tips 337
A word about NAT devices 338
IPsec VPN two-factor authentication with FortiToken-200 340
1. Adding the FortiToken 340
2. Editing the user and assigning the FortiToken 341
4. Connecting to the IPsec VPN 346
5. Results 346
IPsec VPN with FortiClient 352
1. Creating a user group for remote users 352
2. Adding a firewall address for the local network 353
4. Creating a security policy for access to the Internet 356
5. Configuring FortiClient 358
6. Results 359
IPsec VPN with native Mac OS X client 362
1. Configuring the IPsec VPN using the Wizard 362
2. Creating a security policy for remote access to the Internet 366
3. Results 366
L2TP IPsec VPN on FortiGate 372
1. Creating an L2TP user and user group 372
2. Enabling L2TP in the CLI Console 373
3. Configuring the L2TP/IPsec phases 373
4. Creating a firewall address for L2TP clients 374
5. Creating Security Policy for access to the internal network and the Internet 375
6. Configuring a remote Windows 7 L2TP client 376
7. Results 380
Limiting bandwidth with traffic shaping 383
1. Enabling Traffic Shaping 383
2. Creating a firewall address 384
3. Configuring a traffic shaper to limit bandwidth 384
4. Verifying your Internet access security policy 386
5. Create two Traffic Shaping Policies 386
6. Results 388

10
Logging FortiGate traffic and using FortiView 392

1. Configuring log settings 392
2. Enabling logging in security policies 393
3. Results 394
Logging traffic with FortiGate Cloud 398
1. Activating FortiGate Cloud 398
2. Sending logs to FortiGate Cloud 399
3. Enabling logging in your Internet access security policy 400
4. Results 401
MAC access control with a WiFi network 405
1. Finding the MAC address of a device 405
For Windows devices: 405
For Mac OS X devices: 405
For iOS devices: 406
For Android devices: 406
2. Defining a device using its MAC address 407
3. Creating a device group 408
4. Reserving an IP address for the device 408
5. Creating a security policy for wireless traffic 409
6. Results 410
Make it a policy to learn before configuring policies 412
The scenario 412
The profiles 413
Logging and Reporting 414
Why do you want to know this information? 415
Maintenance 416
The obligatory warning 416
Monitoring and blocking P2P traffic 417
1. Enabling Application Control and Multiple Security Profiles 417
2. Using the default Application Control profile to monitor network traffic 418
3. Editing the security policy for outgoing traffic 419
4. Reviewing the FortiView dashboards 420
5. Creating an application profile to block P2P applications 420
6. Adding the blocking profile to a security policy 421
7. Results 422
Netflow Templates 425
Listing of Netflow Templates for FortiOS 5.4.x or later 425
ID 256 – Flow options 425
ID 257 – Flow options 426
ID 258 – IPV4 427
ID 259 – IPV6 427
ID 260 – ICMP4 428
ID 261 – ICMP6 429
ID 262 – IPV4_NAT 430
ID 263 – IPV6_NAT 431

11
ID 264 – IPV4_AF_NAT 431

ID 265 – IPV6_AF_NAT 432
ID 266 – ICMPV4_NAT 433
ID 267 – ICMPV6_NAT 434
ID 268 – ICMPV4_AF_NAT 435
ID 269 – ICMPV6_AF_NAT 436
Field Type Definitions 437
Overriding a web filter profile 438
1. Enabling web filtering and multiple profiles 438
2. Creating a user group and two users 438
3. Creating a web filter profile and an override 440
4. Adding the new web filter profile to a security policy 442
5. Results 442
Preventing certificate warnings 445
Using the default certificate 445
1. Generating a unique certificate 446
2. Downloading the certificate used for full SSL inspection 446
3. Installing the certificate on the user’s browser 446
4. Results 449
Using a self-signed certificate 450
1. Creating a certificate with OpenSSL 450
2. Enabling certificate configuration in the GUI 450
3. Importing the self-signed certificate 451
4. Edit the SSL inspection profile 451
5. Importing the certificate into the web browser 452
6. Results 455
Preventing data leaks 457
1. Enabling DLP and Multiple Security Profiles 457
2. Creating a DLP profile 458
3. Adding the profile to a security policy 460
4. Results 462
Protecting a server running web applications 463
1. Enabling Web Application Firewall 463
2. Editing the default Web Application Firewall profile 464
3. Applying the profile to a security policy 466
4. Results 467
5. Offloading to a FortiWeb 467
Protecting a web server with DMZ 468
1. Configuring the FortiGate's DMZ interface 468
2. Creating virtual IPs (VIPs) 469
3. Creating firewall policies 471
4. Results 472
Protection from Botnet C&C attacks 475
1. Enabling the DNS Filter Security Feature 475
2. Creating the DNS Filter Profile and enabling Botnet C&C database 476

12
3. Configuring Static Domain Filter in DNS Filter Profile 477

4. Creating a DNS Filtering firewall policy 477
5. Results 478
Redundant internet connections 481
1. Connecting your ISPs to the FortiGate 481
2. Deleting security policies and routes that use WAN1 or WAN2 481
3. Creating a WAN link interface 482
4. Configuring Health Check (optional) 483
5. Creating a default route for the WAN link interface 484
6. Allowing traffic from the internal network to the WAN link interface 484
7. Results 485
Sandboxing with FortiSandbox and FortiClient 489
1. Connecting the FortiSandbox 489
2. Enabling Sandbox Inspection 491
3. Configuring sandboxing in the default AntiVirus profile 493
4. Configuring sandboxing in the default Web Filter profile 493
5. Configuring sandboxing in the default FortiClient profile 494
6. Applying AntiVirus and Web Filter scanning to network traffic 495
7. Results 496
Setting up a WiFi Bridge with a FortiAP 500
1. Connecting and authorizing the FortiAP unit 500
2. Creating an SSID 501
3. Creating a custom FortiAP profile 502
4. Results 503
Setting up FortiGuard services 505
1. Verifying the connection 505
2. Troubleshooting communication errors 507
3. Results 509
Setting up WiFi with a FortiAP 512
1. Connecting and authorizing the FortiAP unit 512
2. Creating an SSID 513
3. Creating a custom FortiAP profile 515
4. Allowing wireless access to the Internet 516
5. Results 517
Site-to-site IPsec VPN with two FortiGates 520
1. Configuring the HQ IPsec VPN 520
2. Configuring the Branch IPsec VPN 524
3. Results 527
SSL VPN for users with passwords that expire 528
1. Creating the SSL VPN user and user group 528
2. Configuring and assigning the password policy 530
3. Configuring the SSL VPN web portal and settings 530
4. Adding security policies for access to the internal network and the Internet 532

13
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

14
5. Creating an SSL VPN portal 572

6. Configuring the SSL VPN tunnel 574
7. Adding security policies for access to the Internet and internal network 575
8. Installing the user certificate 576
Internet Explorer or Safari (on Windows or Mac OS): 576
FortiClient (on Windows or Mac OS) 578
Firefox (on Windows or Mac OS) 579
9. Results 580
Using a web browser 580
Using FortiClient 581
SSO using a FortiGate, FortiAuthenticator, and DC Polling (Expert) 583
1. Configuring the FortiAuthenticator 583
2. Configuring SSO on the FortiGate 586
3. Creating a user group on the FortiGate 587
4. Adding a policy on the FortiGate 587
5. Results from the FortiAuthenticator 588
6. Results from the FortiGate 590
Single Sign-On using FSSO agent in advanced mode and
FortiAuthenticator (Expert) 591
1. Configuring an LDAP directory on the FortiAuthenticator 591
2. Integrating the FortiGate with the FortiAuthenticator 593
3. Installing FSSO agent on the Windows DC 593
4. Configuring Single Sign-On on the FortiGate 598
5. Adding a user group to the FortiGate 598
6. Adding a policy to the FortiGate 598
7. Results 599
Single Sign-On using LDAP and FSSO agent in advanced mode (Expert) 603
1. Integrating the FortiGate with the Windows DC LDAP server 603
2. Installing FSSO agent on the Windows DC server 604
3. Configuring Single Sign-On on the FortiGate 608
4. Adding a user group to the FortiGate 609
5. Adding a policy to the FortiGate 609
Results 610
Traffic Shaping Priority Queueing (PRIQ) 613
How traffic shaping really works 613
Before you begin 613
Traffic shaping methods 614
Dropping excess packets early on 614
How priority queuing works 615
Types of priority 616
Type of Service (ToS) priority 616
Firewall policy priority 617
How do these priorities affect each other? 618
Traffic passing through the FortiGate 619
Traffic originating at the FortiGate 620

15
Egress queueing 621

Resources 621
Updating your FortiGate's firmware 623
1. Checking the current FortiOS firmware 623
2. Reviewing the Release Notes 624
3. Updating to the latest firmware 624
4. Results 625
User and device authentication 628
1. Creating two users groups and adding users 628
2. Creating a schedule for part-time staff 629
3. Creating a policy for full-time staff 630
4. Creating a policy for part-time staff that enforces the schedule 631
5. Creating a policy that denies mobile traffic 632
6. Results 633
Using Hairpinning in a Network 637
What do hair pins have to do with networking? 637
Using virtual IPs to configure port forwarding 640
1. Creating three VIPs 640
2. Adding VIPs to a VIP group 643
3. Creating a security policy 644
4. Results 645
VDOM configuration 647
1. Switching to VDOM mode and creating two VDOMs 647
2. Configuring the root VDOM for FortiGate management 649
3. Adding interfaces to VDOM-A 651
4. Adding interfaces to VDOM-B 653
5. Adding administrators to each VDOM 656
6. Configuring VDOM-A 657
7. Configuring VDOM-B 659
8. Results 661
Web and DNS filter troubleshooting 663
The Web Filter menu is missing 663
You cannot create new web filter profiles 663
You configured web filtering, but it is not working 663
You configured DNS Filtering, but it is not working 663
FortiGuard has the wrong categorization for a website 663
The website categorization on your FortiGate does not match the FortiGuard
categorization 664
An active FortiGuard web filter license displays as expired/unreachable 664
Using URL Filters in conjunction with FortiGuard Categories is not working 664
Web filtering using quotas 666
1. Enabling web filtering 666
2. Creating a web filter profile that uses quotas 666

16
3. Adding web filtering to a security policy 669

4. Results 670
WiFi network on a schedule 672
1. Create the schedule 672
2. Create the SSID 673
3. Create the security policy 674
Results 675
WiFi Network troubleshooting 676
Signal strength issues 676
Asymmetric power issue 676
Frequency interference 678
Throughput issues 679
Testing the link 679
Performance testing 680
Preventing IP fragmentation in CAPWAP 681
Slowness in the DTLS response 681
Connection issues 681
Client connection issues 681
FortiAP connection issues 683
General problems 686
Best practices for Layer 1 687
Best practices for Layer 2 687
Best practices for Layer 3 and above 688
Packet sniffer 689
CAPWAP packet sniffer 689
Wireless traffic packet sniffer 690
Useful debugging commands 693
Sample outputs 693
WiFi RADIUS authentication with FortiAuthenticator 694
1. Create the user accounts and user group on the FortiAuthenticator 694
2. Register the FortiGate as a RADIUS client on the FortiAuthenticator 695
3. Configure FortiGate to use the RADIUS server 696
4. Create the SSID and set up authentication 697
5. Connect and authorize the FortiAP 698
6. Create the security policy 700
Results 701
WiFi using FortiAuthenticator RADIUS with Certificates 702
1. Creating a local CA on FortiAuthenticator 702
2. Creating a local service certificate on FortiAuthenticator 703
3. Configuring RADIUS EAP on FortiAuthenticator 703
4. Configuring RADIUS client on FortiAuthenticator 704
5. Configuring local user on FortiAuthenticator 705
6. Configuring local user certificate on FortiAuthenticator 706
7. Creating RADIUS server on FortiGate 706
8. Creating WiFi SSID on FortiGate 707

17
9. Exporting user certificate from FortiAuthenticator 709

9. Importing user certificate into Windows 7 710
10. Configuring Windows 7 wireless profile to use certificate 714
11. Results on FortiAuthenticator 717
12. Results on FortiGate 718
WiFi with WSSO using FortiAuthenticator RADIUS and Attributes 719
1. Registering the FortiGate as a RADIUS client on the FortiAuthenticator 719
2. Creating users on the FortiAuthenticator 721
3. Creating user groups on the FortiAuthenticator 722
4. Configuring FortiGate to use FortiAuthenticator as the RADIUS server 724
5. Configuring user groups on the FortiGate 725
6. Creating security policies 726
7. Configuring the SSID to RADIUS authentication 726
8. Results 727
WiFi with WSSO using Windows NPS and Attributes 729
1. Registering the FortiGate as a RADIUS client on NPS 729
2. Creating a Connection Request Policy 730
3. Creating a Network Policy 731
4. Configuring FortiGate to use the RADIUS server 733
5. Configuring a user group on the FortiGate 733
6. Creating an SSID with RADIUS authentication 733
8. Results 736
WiFi with WSSO using Windows NPS and FortiGate Groups 737
1. Registering the FortiGate as a RADIUS client on NPS 737
2. Creating a Connection Request Policy 738
3. Creating a Network Policy 739
4. Configuring FortiGate to use the RADIUS server 740
5. Configuring a user group on the FortiGate 741
6. Creating an SSID with RADIUS authentication 741
8. Results 744

Change Log
Date Change Description
2019-10-08 Initial release.

What's New
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

802.1X with VLAN Switch interfaces on a FortiGate
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.
2. Configuring RADIUS authentication
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.
Go to WiFi & Switch Controller > VLANs

Modify your VLAN and change the admission control authentication method to RADIUS, and select you RADIUS server.
(This example follows on from the local user configuration, given in the video.)
Test the RADIUS configuration from the the FortiGate CLI:

# diagnose test authserver radius myRADIUS mschap2 mike@local mypassword
authenticate 'mike@local' against 'mschap2' succeeded, server=primary assigned_rad_
session_id=790684157 session_timeout=0 secs idle_timeout=0 secs!

3. Configure the supplicant and test
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
Check FortiAuthenticator's log messages, look for 802.1x authentication successful.

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.


Adding Endpoint Control to the Security Fabric
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.
1. Enabling endpoint control on the FortiGate
On the Marketing FortiGate, go to System > Feature Select and make sure that Endpoint Control is enabled.

2. Enforcing FortiClient registration on the internal interface
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.

3. Configuring the FortiClient Profile
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).


4. Setting up a compliant FortiClient device
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.

Assigning WiFi users to VLANs dynamically
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.
1. Configure the 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.
2. Add the RADIUS server to the FortiGate configuration
Go to User & Device > RADIUS Servers. Select Create New.

Enter the FortiAuthenticator IP address and the server secret that you entered on the FortiAuthenticator. Optionally, you
can click Test Connectivity. Enter a RADIUS user's ID and password. The result should be “Successful”.
3. Create an SSID with dynamic VLAN assignment
Go to WiFi Controller > SSID . Create a new SSID.

Set up DHCP service.
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
4. Create the VLAN interfaces
Go to Network > Interfaces.

Create the VLAN interface for default VLAN-10 and set up DHCP service.

Create the VLAN interface for marketing-100 and set up DHCP service.

Create the VLAN interface for techdoc-200 and set up DHCP service.

5. Create security policies
Go to Policy & Objects > IPv4 Policy.

Create a policy that allows outbound traffic from marketing-100 to the Internet.

In Logging Options, enable logging for all sessions.
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.

6. Create the FortiAP Profile
Go to WiFi Controller > FortiAP Profiles.

Create a new profile for your FortiAP model and select the new SSID for both Radio 1 and Radio 2.

7. Connect and authorize the FortiAP
Go to Network > Interfaces and choose an unused interface.

Set Addressing mode to Dedicated to Extension Device.
Connect the FortiAP unit to the this interface and apply power.
Go to WiFi Controller > Managed FortiAPs.
Right-click on the FortiAP unit. Select Authorize.
Right-click on the FortiAP unit again. Select Assign Profile and select the FortiAP profile that you created.

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.

Blocking Facebook with Web Filtering
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.
1. Enabling Web Filtering
Go to System > Feature Select to enable the Web Filter feature.

2. Editing the default Web Filter profile
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.
3. Creating the Web filtering security policy
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.
Visit a subdomain of Facebook, for example, attachments.facebook.com.

A FortiGuard Web Page Blocked! message appears, blocking the subdomain.


Blocking social media websites using FortiGuard

categories
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.
1. Enabling the Web Filter feature
Go to System > Feature Select and confirm that the Web Filter feature is enabled.

2. Editing the default Web Filter profile
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.
3. Adding the Web Filter profile to the Internet access policy
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.

Blocking Tor traffic
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.
1. Enabling Application Control
Go to System > Feature Select to ensure that Application Control is enabled.
2. Blocking Tor traffic in Application Control using the default

profile
Go to Security Profiles > Application Control to edit the default profile.

Under Application Overrides, select Add Signatures.

Filter by Category: Tor and Proxy: Name to search for Tor.
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.
3. Adding application control to your security policy
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.

Blocking Windows XP traffic
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.
1. Enabling Application Control
Go to System > Feature Select. Under Security Features, enable Application Control.

2. Creating a custom application signature
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.
F-SBID(--attack_id 8151; --vuln_id 8151; --name "Windows.NT.5.Web.Surfing"; --default_action

drop_session; --service HTTP; --protocol tcp; --app_cat 25; --flow from_client; --pattern
!"FCT"; --pattern "Windows NT 5.1"; --no_case; --context header; --weight 40; )
The signature will appear at the top of the application list in the Web.Client category.

3. Adding the signature to the default Application Control profile
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.

4. Adding the default profile to a security policy
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.

Bootstrapping a FortiGate-AWS
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).
1. Storing configuration and license information
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.
2. Setting up IAM roles
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.
3. Creating S3 buckets with license and firewall configurations
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.
4. Launching the instance using roles and user data
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 aws@fortinet.com.

Captive Portal bypass for Apple updates and Chromebook
authentication
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.

1. Creating a user account and user group
Go to User & Device > User Definition and create a Local user. Create additional users as needed. You can use any
authentication method.
Go to User & Device > User Groups.

Create a user group for employees and add the new user(s) to the group.
2. Creating firewall addresses
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 FQDN address object for gstatic.com.
Create an IP/Netmask address object for the apple Subnet range 17.0.0.0/8.

Create an FQDN address object for captive.apple.com.
Create IP/Netmask address object(s) for any external DNS servers the client computers might use.

3. Creating the SSID
Go to WiFi Controller > SSID and configure your wireless network.
Configure DHCP addressing for clients.
Configure Captive Portal authentication using the Forti-WiFi-users user group.

Set Exempt Destination Services to exempt the addresses created in the previous step.
4. Creating the security policy
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.


5. Connecting and authorizing the FortiAP
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.
Highlight the FortiAP unit on the list and select Authorize.
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
Connect your Chromebook or Apple device to the captive portal SSID.

The user's device shows the WiFi network as “open” and associates with it without requesting credentials.
On the Chromebook you will be able to log onto the device and authenticate with Google accounts.
On the Apple device you will not get the CNA prompt with the captive portal popup, requesting you to authenticate. The
Apple device will stay connected to the WiFi.
Go to WiFi Controller > Monitor > Client Monitor to see connected users.

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.

Captive portal two-factor authentication with FortiToken
Mobile
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.
1. Enabling FortiToken for elainemarley
Go to User & Device > User Definition and edit elainemarley.

Select Enable Two-factor Authentication and select the FortiToken Mobile from the dropdown menu.
Under Contact Info, enable Email Address or SMS, enter elainemarley's contact information, and select Send
Activation Code Email or Send Activation Code SMS. The internal network user will receive the activation code by
the method specified.

2. Adding a user account to FortiToken Mobile
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.



3. Editing the internal interface
Go to Network > Interfaces and edit the internal interface.

Under Admission Control, set Security Mode to Captive Portal.
Set Authentication Portal to Local, and set User Groups to FTK-users.
4. Customizing the captive portal login page
Go to System > Replacement Messages. Under Authentication, select Login Page.

Two panels will open showing the login page that users will see when attempting to browse the Internet, and the HTML
format.
You can customize the login page, such as border color and thickness, using the HTML panel. When finished, select
Save, then select Manage Images > Create New.

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;}
Make any other changes you wish.

The new logo will replace the old image, as shown here.

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.

Captive portal WiFi access control
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.
1. Enabling HTTPS authentication
Go to User & Device > Authentication Settings.

Under Protocol Support, enable Redirect HTTP Challenge to a Secure Channel (HTTPS). This will make sure
that user credentials are communicated securely through the captive portal.

2. Creating the user
Go to User & Device > User Definition and create a Local user (rgreen).
Create additional users if needed, and assign any authentication methods.
3. Creating the user group
Go to User & Device > User Groups and create a user group (employees).
Add rgreen to the group.
4. Creating the SSID
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.

An address range underDHCP Server will be automatically configured.
Under WiFi Settings, enter an SSID name (example-staff), set Security Mode to Captive Portal, and add the
employees user group.

5. Creating the security policy
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.
6. Connecting and authorizing the FortiAP
Go to Network > Interfaces and edit an available interface.

Under Address, set Addressing mode to Dedicated to Extension Device and assign it an IP address.

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.

Captive portal WiFi access with a FortiToken-200
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.
1. Adding the FortiToken
Go to User & Device > FortiTokens and create a new FortiToken.

Set Type to Hard Token and enter the FortiToken's Serial Number into the field provided. Note that the serial
number, located on the back of the FortiToken device, is case sensitive and must not be previously used.

2. Editing the user and assigning the FortiToken
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.

Configuring ADVPN in FortiOS 5.4 - Redundant hubs
(Expert)
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
Configure phase 1 parameters

Note that we added some DPD settings to ensure DPD detects IPSec failures much faster than usual in order for
convergence to occur.
config vpn ipsec phase1-interface
edit "ADVPN"
set type dynamic
set interface "port1"
set proposal aes128-sha1
set add-route disable
set dhgrp 14
set auto-discovery-sender enable
set psksecret somereallysecuresauuuuce
set dpd-retrycount 3
set dpd-retryinterval 2
set dpd on-idle
next
end
Configure phase2 parameters

edit "ADVPN-P2"
set phase1name "ADVPN"
next
end
Configure the tunnel interface IP

config system interface
edit "ADVPN"
set vdom "root"
set ip 10.10.10.1 255.255.255.255
set type tunnel
set remote-ip 10.10.10.254
next
end
Configure prefix-lists and route-maps

We use a first route-map to select which connected networks to advertise.
Our second route-map ensures to clear the weight of redistributed OSPF routes to 0 to ensure they do not become
sticky and also assigns OSPF redistributed routes a local preference of 50.

config router prefix-list

edit "PF_REDIS_CONNECTED"
config rule
edit 1
set prefix 192.168.1.0 255.255.255.0
unset ge
unset le
next
edit 2
set prefix 192.168.0.0 255.255.255.0
unset ge
unset le
next
end
next
end
config router route-map
edit "RM_REDIS_CONNECTED"
config rule
edit 1
set match-ip-address "PF_REDIS_CONNECTED"
next
edit 2
set action deny
next
end
next
edit "RM_OSPF_TO_BGP"
config rule
edit 1
set set-local-preference 50
set set-weight 0
next
end
next
end
Note regarding BGP weight: routes that are sourced by a given BGP instance (either by network statements or
through redistribution) are always by default marked with a weight of 32768. When a route stops being learnt from a
spoke over iBGP and instead is learnt through OSPF from the other hub, that route will be inserted with a high weight
and will no longer be displaced when the spoke reestablishes its BGP adjacency. As this mechanism does not
account for IGP backdoor connectivity as our topology does with OSPF, we have to break this mechanism in order to
ensure convergence favours routes coming directly from the spokes.
Configure iBGP and route-reflection
Timers for BGP are modified to accelerate convergence. Care should however be given to ensure that the combination
of faster DPD and faster BGP timers does not result in issues when the topology deployed has a very large number of
spokes.
We have route-map filtering configured for the redistribution of both connected networks and OSPF-learnt networks.
The admin distance of iBGP routes is also modified to be preferred over OSPF. While not a common configuration, it is
however crucial in our usage as both HUB devices must always prefer their iBGP routes to anything learnt over OSPF.
This is supplemental to our previous “route weight” route-map fix.

config router bgp

set as 65000
set router-id 192.168.1.1
set distance-internal 100
config neighbor-group
edit "ADVPN"
set advertisement-interval 10
set next-hop-self enable
set remote-as 65000
set keep-alive-timer 2
set holdtime-timer 6
set route-reflector-client enable
next
end
config neighbor-range
edit 1
set prefix 10.10.10.0 255.255.255.0
set neighbor-group "ADVPN"
next
end
config redistribute "connected"
set status enable
set route-map "RM_REDIS_CONNECTED"
end
config redistribute "ospf"
set status enable
set route-map "RM_OSPF_TO_BGP"
end
end
Configure OSPF
This is a standard OSPF configuration with BGP redistribution. Note that we are bumping the redistribution metric for
our second HUB as documented further along in this article.
config router ospf
config area
edit 0.0.0.0
next
end
config network
edit 1
set prefix 192.168.0.0 255.255.0.0
next
end
config redistribute "bgp"
set status enable
end
end
Configure firewall policies

config firewall policy
edit 0
set name "OUT ADVPN"
set srcintf "port1" "port2" "port3" "ADVPN"
set dstintf "port1" "port2" "port3" "ADVPN"

set srcaddr "all"

set dstaddr "all"
set action accept
set schedule "always"
set service "ALL"
set status enable
next
end
2. Configure HUB2

This part is identical to HUB1.
edit "ADVPN"
set type dynamic
set dhgrp 14
set psksecret somereallysecuresauuuuce
set dpd on-idle
next
end
Configure the phase2 parameters

This part is identical to HUB1.
edit "ADVPN-P2"
next
end
Configure the tunnel interface IP

Our second topology's IP subnet is configured.
edit "ADVPN"
set vdom "root"
set ip 10.10.11.1 255.255.255.255
set type tunnel
next
end
Configure prefix-lists and route-maps

Other than modifying the connected subnets advertised, we are using a local preference of 25 for OSPF routes
redistributed by BGP on our second hub. This ensures HUB1 is prioritized for reaching those subnets.
config router prefix-list
edit "PF_REDIS_CONNECTED"
config rule
edit 1
set prefix 192.168.2.0 255.255.255.0
unset ge
unset le
next
edit 2
set prefix 192.168.0.0 255.255.255.0
unset ge
unset le
next
end
next
end
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-weight 0
next
end
next
end
Configure iBGP and route-reflection

Our second topology uses the same AS number therefore most of the configuration is identical except for router-id and
subnets.
config router bgp
set as 65000
set distance-internal 100
edit "ADVPN"
set advertisement-interval 10
set remote-as 65000
set keep-alive-timer 2
set holdtime-timer 6
next

end
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
config area
edit 0.0.0.0
next
end
config network
edit 1
set prefix 192.168.0.0 255.255.0.0
next
end
config redistribute "bgp"
set status enable
set metric 5
end
end
Configure firewall policies

edit 0
set srcintf "port1" "port2" "port3" "ADVPN"
set dstintf "port1" "port2" "port3" "ADVPN"
set srcaddr "all"
set dstaddr "all"
set action accept
set service "ALL"
set status enable
next
end

3. Configure the Spoke FortiGates

Compared with a single hub setup, we add a second ADVPN connection towards our second hub.
Note that we are configuring only one of the spokes in this example – the parameters that need to change for each
spoke are highlighted in red.
edit "ADVPN"
set dhgrp 14
set auto-discovery-receiver enable
set remote-gw 192.0.2.11
set psksecret ***
set dpd on-idle
next
edit "ADVPN2"
set dhgrp 14
set psksecret ***
set dpd on-idle
next
end
Configure the phase2 parameters

Spokes benefit from having auto-negotiate enabled in order to ensure tunnels come up given the usage of dynamic
routing to learn actual protected traffic subnets.
edit "ADVPN-P2"
set auto-negotiate enable
next
edit "ADVPN2-P2"
set phase1name "ADVPN2"
next
end
Configure the tunnel interface IPs

Each ADVPN topology needs a hardcoded IP configured.


edit "ADVPN"
set vdom "root"
set ip 10.10.10.3 255.255.255.255
set type tunnel
next
edit "ADVPN2"
set vdom "root"
set ip 10.10.11.3 255.255.255.255
set type tunnel
next
end
Configure iBGP
To ensure our primary ADVPN topology is prioritized, we apply a local preference of 200 to inbound and outbound routes
towards the primary ADVPN topology's hub.
edit "RM_ADVPN1"
config rule
edit 1
next
end
next
end
config router bgp
set as 65000
config neighbor
edit "10.10.10.1"
set remote-as 65000
set route-map-out "RM_ADVPN1"
next
edit "10.10.11.1"
set remote-as 65000
next
end
config network
edit 1
set prefix 192.168.3.0 255.255.255.0
next
end
end
Configure a static route for the tunnel IP subnet

Both ADVPN topologies require a summary route to be present on spokes in order for recursive routing to function when
addressing other spokes.
For good measure however, we have two additional floating blackhole routes to ensure that if the tunnels are down,
BGP does not attempt to establish connections with the hub over the default gateway nor install recursive routes for
other spokes through the default gateway. This ensures faster convergence upon tunnel restoration.

config router static

edit 0
set dst 10.10.10.0 255.255.255.0
set device "ADVPN"
next
edit 0
set dst 10.10.11.0 255.255.255.0
set device "ADVPN2"
next
edit 0
set dst 10.10.10.0 255.255.255.0
set distance 254
set blackhole enable
next
edit 0
set dst 10.10.11.0 255.255.255.0
set distance 254
set blackhole enable
next
end
Configure policies
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 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 ?

*>i 10.10.10.1 0 100 0 ?

* i192.168.2.010.10.10.1 2 50 0 ?
*>i 10.10.11.1 0 100 0 ?
*> 192.168.3.0 0.0.0.0 100 32768 i
*>i192.168.4.0 10.10.10.4 0 200 0 i
* i 10.10.11.4 0 100 0 i
Total number of prefixes 5
SPOKE1 #
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):

FGT-5 # get router info routing-table details 192.168.3.0

Routing entry for 192.168.3.0/24
Known via "ospf", distance 110, metric 1, best
Last update 00:03:21 ago
* 192.168.0.1, via port1
FGT-5 # get router info ospf database external lsa 192.168.3.0
AS External Link States
LS age: 816
Options: 0x2 (*|-|-|-|-|-|E|-)
LS Type: AS-external-LSA
Link State ID: 192.168.3.0 (External Network Number)
Advertising Router: 192.168.0.1
LS Seq Number: 80000001
Checksum: 0x1adf
Length: 36
Network Mask: /24
Metric Type: 2 (Larger than any link state path)
TOS: 0
Metric: 1
Forward Address: 0.0.0.0
External Route Tag: 1
LS age: 133
Options: 0x2 (*|-|-|-|-|-|E|-)
LS Type: AS-external-LSA
Link State ID: 192.168.3.0 (External Network Number)
Advertising Router: 192.168.0.2
LS Seq Number: 80000002
Checksum: 0x28cc
Length: 36
Network Mask: /24
Metric Type: 2 (Larger than any link state path)
TOS: 0
Metric: 5
Forward Address: 0.0.0.0
External Route Tag: 0

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

10.10.11.3 from 10.10.11.1 (192.168.3.1)

Origin IGP metric 0, localpref 100, valid, internal
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 #
Local
10.10.10.3 from 10.10.10.1 (192.168.3.1)
Origin IGP metric 0, localpref 200, valid, internal, best
Local
10.10.11.1 from 10.10.11.1 (10.10.11.1)
Origin incomplete metric 1, localpref 25, valid, internal
… 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 (interface) # edit ADVPN
SPOKE2 (ADVPN) # set status down
SPOKE2 (ADVPN) # end
SPOKE2 #
Local
10.10.11.1 from 10.10.11.1 (10.10.11.1)
Origin incomplete metric 1, localpref 25, valid, internal, best
SPOKE2 # exec ping-options source 192.168.4.1

SPOKE2 # 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=253 time=6.5 ms
^C
--- 192.168.3.1 ping statistics ---

4 packets transmitted, 4 packets received, 0% packet loss

round-trip min/avg/max = 0.9/2.4/6.5 ms
SPOKE2 # get router info routing-table details 192.168.3.0
Known via "bgp", distance 200, metric 1, best
* 10.10.11.1, via ADVPN2
… 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 (interface) # edit ADVPN2
SPOKE1 (ADVPN2) # set status up
SPOKE1 (ADVPN2) # end
SPOKE1 #
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:
* 10.10.10.3 (recursive via 10.10.10.1)
SPOKE2 # exec ping 192.168.3.1

PING 192.168.3.1 (192.168.3.1): 56 data bytes
SPOKE2 #
* 10.10.10.3, via ADVPN_0
SPOKE2 # get vpn ipsec tunnel summary

'ADVPN_0' 192.0.2.13:0 selectors(total,up): 1/1 rx(pkt,err): 4/0 tx(pkt,err): 4/0
'ADVPN' 192.0.2.11:0 selectors(total,up): 1/1 rx(pkt,err): 148/0 tx(pkt,err): 149/0
'ADVPN2' 192.0.2.12:0 selectors(total,up): 1/1 rx(pkt,err): 4102/0 tx(pkt,err): 4103/2

Configuring ADVPN in FortiOS 5.4 (Expert)
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.

1. Configure the Hub FortiGate
Using the CLI, configure phase 1 parameters.

The auto-discovery commands enable the sending and receiving of shortcut messages to spokes (the hub is responsible
for lettings the spokes know that they should establish those tunnels).
Note: aggressive mode is not supported currently for ADVPN.
edit "ADVPN"
set type dynamic
set interface "wan1"
set dhgrp 2
set psksecret fortinet
next
end
Configure the phase2 parameters.

This is a standard phase 2 configuration.


edit "ADVPN-P2"
next
end
Configure the tunnel interface IP.

ADVPN requires that tunnel IPs be configured on each device connecting to the topology. Those IP addresses need to
be unique for each peer. A particularity of the hub is that it needs to define a bogus remote-IP address (10.10.10.254 in
our example). This address should be unused in the topology and it will not be actually considered as part of the
configuration for the hub.
edit "ADVPN"
set vdom "root"
set ip 10.10.10.1 255.255.255.255
set type tunnel
next
end
Configure iBGP and route-reflection.

iBGP will be our overlay protocol of choice for enabling ADVPN communications. We are using an arbitrary private AS
number (65000) in our example, and configuring a dynamic client group to reduce provisioning requirements.
While we are advertising our LAN network directly (“config network” command), route redistribution is a perfectly valid
alternative.
config router bgp
set as 65000
edit "ADVPN-PEERS"
set remote-as 65000
next
end
edit 0
set prefix 10.10.10.0 255.255.255.0
set neighbor-group "ADVPN-PEERS"
next
end
config network
edit 0
set prefix 192.168.1.0 255.255.255.0
next
end
end
Configure basic policies to allow traffic to flow between the local network and the ADVPN VPN topology. As we generally
desire traffic to be allowed between spokes in an ADVPN setup, we must remember to create a policy allowing spoke to
spoke communications.


edit 0
set srcintf "lan"
set dstintf "ADVPN"
set srcaddr "all"
set dstaddr "all"
set action accept
set service "ALL"
set status enable
next
edit 0
set name "IN ADVPN"
set srcintf "ADVPN"
set dstintf "lan"
set srcaddr "all"
set dstaddr "all"
set action accept
set service "ALL"
set status enable
next
edit 0
set name "ADVPNtoADVPN"
set srcintf "ADVPN"
set dstintf "ADVPN"
set srcaddr "all"
set dstaddr "all"
set action accept
set service "ALL"
set status enable
next
end
2. Configure the Spoke FortiGates
Using the CLI, configure phase 1 parameters.

Note that we are configuring only one of the spokes in this example – the parameters that need to change for each
spoke are highlighted in red.
edit "ADVPN"
set dhgrp 2
set psksecret fortinet
next
end

Configure the phase2 parameters.

edit "ADVPN-P2"
next
end
Configure the tunnel interface IP.

Notice that on the spokes, the remote IP is actually used and points to the IP defined on the hub.
edit "ADVPN"
set vdom "root"
set ip 10.10.10.2 255.255.255.255
set type tunnel
next
end
Config iBGP.
This is a static standard configuration and as stated for the hub, redistribution could be used instead of explicit route
advertisement.
config router bgp
set as 65000
config neighbor
edit "10.10.10.1"
set soft-reconfiguration enable
set remote-as 65000
next
end
config network
edit 0
set prefix 192.168.2.0 255.255.255.0
next
end
end
Configure a static route for the tunnel IP subnet.

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


edit 0
set srcintf "lan"
set dstintf "ADVPN"
set srcaddr "all"
set dstaddr "all"
set action accept
set service "ALL"
set status enable
next
edit 0
set name "IN ADVPN"
set srcintf "ADVPN"
set dstintf "lan"
set srcaddr "all"
set dstaddr "all"
set action accept
set service "ALL"
set status enable
next
end
Results
We can validate the behaviour of our configuration using a few commands. We are going to run these commands from
SPOKE A.
get router info routing-table bgp will at a minimum display the learned routes from the topology. Note the recursive
routing – a result of our spoke's required static route. In this case, there has not been any traffic between our local
subnet (192.168.2.0/24) and the other spoke's subnet, as the routes are both going through the hub.
B 192.168.1.0/24 [200/0] via 10.0.0.1, ADVPN, 22:30:21
B 192.168.3.0/24 [200/0] via 10.0.0.3 (recursive via 10.0.0.1), 22:30:21
However once we initiate a ping between both spokes, we obtain a different display of routing information – routing now
goes through a newly established dynamic tunnel directly through the remote spoke rather than through the hub. The
ping hiccup that occurs is the tunnel rerouting through a newly negotiated tunnel to the other spoke.
Our routing information now displays the remote subnet as being available through the spoke directly, through interface
ADVPN_0, a dynamically instantiated interface going to that spoke.
FG # exec ping-options source 192.168.2.1
FG # exec ping 192.168.3.1
PING 192.168.3.1 (192.168.3.1): 56 data bytes
Warning: Got ICMP 3 (Destination Unreachable)


FG # get router info routing-table bgp
B 192.168.1.0/24 [200/0] via 10.0.0.1, ADVPN, 22:34:13
B 192.168.3.0/24 [200/0] via 10.0.0.3, ADVPN_0, 00:02:28
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
------------------------------------------------------

Configuring Hair-pinning on a FortiGate
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:
l A company has a server on its internal LAN at IP address 192.168.1.98/24.

l The Fully Qualified Domain Name for the website is test1.fortidoc.info, which resolves to 172.20.121.41.
l SSH is running on the server and it will be used for testing purposes. The server listens for SSH traffic on port 22 but
because there are multiple servers using SSH and only a few external IP address; port forwarding will be set up
from port 12345.
l Seeing as words are easier to remember than numbers, most people bookmark this connection rather than try to
remember it. To avoid confusion, the IT department has been asked to make sure the same bookmark works
whether the user’s computer is connected to the internal LAN or anywhere on the Internet.
l As a test, the packets will try and connect to the server from an IP on the same subnet, 172.20.121.41.
Follow the recipe below to configure hair-pinning on your FortiGate.

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.
Verifying the situation
In order to propose a solution, there must first be a problem. Let’s verify if there is an issue:
Testing the connection externally
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.

Testing the connection internally
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.

In the CLI, enable the match-vip setting.
3. Results
Testing the connection internally:

Try to make an SSH connection to the internal server from the internal side of the FortiGate.
Here you can see that the hair-pinning technique was successful.


Configuring LDAP over SSL with Windows Active Directory
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.
1. Exporting the LDAPS Certificate in Active Directory (AD)
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 Export File Format screen, select DER .

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.
2. Importing the LDAPS Certificate into the FortiGate
Go to System > Config > Features, and enable Certificates.

Go to System > Certificates and select Import > CA Certificate. Select Local PC and Choose File, then browse
for certificate file and click OK.
You may rename the system-generated CA_Cert_1 to be more descriptive.

CLI Example:

FGT # config vpn certificate ca

FGT (ca) # rename CA_Cert_1 to LDAPS-CA
FGT (ca) # end
The Name under External CA Certificates now shows as LDAPS-CA.
3. Creating the LDAPS Server object in the FortiGate
User DN must have server administrator access.

4. Results
Verifying that the LDAPS Server object is authenticating correctly.

On the FortiGate use the following diagnose command to test authenticating with the LDAPS server. When you enter
the command use an actual username and password on the LDAPS server (in the example administrator and
pa$$w0rd). If everything is configured correctly, the command output should indicate that authentication has
succeeded and also list the group memberships.
FGT # diagnose test authserver ldap LDAPS administrator pa$$w0rd
authenticate 'administrator' against 'LDAPS' succeeded!
Group membership(s) - CN=Domain Admins,CN=Users,DC=fortinet,DC=local
CN=Administrators,CN=Builtin,DC=fortinet,DC=local
CN=Domain Users,CN=Users,DC=fortinet,DC=local

Cooperative Security Fabric
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.
1. Installing a FortiGate in NAT/Route mode
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.

2. Installing internal FortiGates and enabling a Security Fabric
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:
3. Adding FortiAnalyzer to a Security Fabric
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.
4. High Availability with two FortiGates
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:
5. Setting up an internal network with a managed FortiSwitch
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:

6. Adding endpoint control to a Security Fabric
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:

7. Adding FortiManager to a Security Fabric
In this recipe, a FortiManager is added to provide central management for the FortiGates in the Security Fabric.

Creating a virtual wire pair
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.
1. Adding a virtual wire pair
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.
2. Adding virtual wire pair firewall policies
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.

Go to FortiView > Policies to see traffic flowing through both policies.

Creating security policies
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.
1. Configuring the Internet policy
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.

2. Creating the Mobile policy
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.
4. Creating the Admin policy
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.

5. Ordering the policy table
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.
Right-click on the Admin policy and select Drill Down to Details.

View the Sources tab to confirm that this policy is being used exclusively by SysAdminPC .

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

Encryption hash used by FortiOS for local pwd/psk
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

Enforcing network security using a FortiClient Profile
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.

1. Enabling endpoint control on the FortiGate
On the FortiGate, go to System > Feature Select and make sure that Endpoint Control is enabled.
2. Enforcing FortiClient registration on the internal interface
Go to Network > Interfaces and select the internal interface.

Under Restrict Access, enable FortiHeartBeat.
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.
3. Configuring the FortiClient Profile
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.

For further reading, check out the FortiClient Administration Guide.

Extending WiFi range with mesh topology
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.
1. Creating the backhaul SSID
Go to WiFi Controller > SSID .

Create a new SSID. Set Traffic Mode to Mesh Downlink.
You will need the pre-shared key when configuring the mesh-connected FortiAP.

2. Creating the client SSID
Go to WiFi Controller > SSID . Create the WiFi network (SSID) that clients will use.
Configure DHCP to provide IP addresses for your clients.

3. Creating the FortiAP Profile
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.

4. Configuring the security policy
Go to Policy & Objects > IPv4 Policy and create a new policy.

5. Configuring an interface dedicated to FortiAP
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
Go to WiFi Controller > Managed FortiAPs and create a new entry.

Enter the serial number of the FortiAP unit and give it a name. Select the FortiAP profile that you created earlier.
Doing this will allow FortiAP-1 to go online as soon as it is connected to the FortiGate. Optionally, you could connect the
FortiAP to the FortiGate and then manually authorize it at that point, as will be done with FortiAP-2.
7. Configuring FortiAP-2 for mesh operation
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.
Edit FortiAP-2. Under Managed AP Status, select Connect to CLI.

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
Disconnect FortiAP-2 from the FortiGate.
8. Connecting and authorizing the FortiAPs
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.

Fixed Port Range IP Pools algorithm
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.
Determining the IP address from the pool
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.
Defining the variables
The first step in having the algorithm make sense is to define the variables we will be using:
Variable Name Description
src_start Starting IP address of the IP pool’s source IPs
src_end End or last IP address of the IP pool’s source IPs
start Starting IP of the IP pool’s translated IP addresses
end End or last IP of the IP pool’s translated IP addresses
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.
Setting values for the example
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
Source (internal) range 192.168.1.100 – 192.168.1.200
External range 10.1.1.50 – 10.1.1.80
example source IP address 160
First equation – determining the factor
Second equation – determining the IP address from the pool
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.
Defining the variables
Just like we did when determining the IP addresses, we’ll start by defining some variables and values.
Variable name Description
snat_port_begin The beginning of the range of NATed ports
snat_port_end The end of the range of NATed ports
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
l src_ip These variable were all defined in the previous algorithm

l src_start
l factor
Setting values for the example
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:
First equation – determining the port share
We know the factor is 4, so determining the port_share is straightforward.
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
l KnowledgeBase article: How FortiOS selects unused NAT ports

FortiAuthenticator as a Certificate Authority
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.
1. Creating a new CA on the FortiAuthenticator
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.

Once created, highlight the certificate and select Export.

This will save a .crt file to your local drive.

2. Installing the CA on the network
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.
Internet Explorer and Chrome
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.

In the Authorities tab, select Import.
Find and open the root certificate.

You will be asked what purposes the certificate will be trusted to identify. Select all options, and select OK.

3. Creating a CSR on the FortiGate
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.

4. Importing and signing the CSR on the FortiAuthenticator
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.

5. Importing the local certificate to the FortiGate
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.
6. Configuring the certificate for the GUI
Go to System > Admin > Settings.

Under Administration Settings, set HTTPS Server Certificate to the certificate created/signed earlier, then select
Apply.

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.

FortiGate installation troubleshooting
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.
1. Check your equipment and cables
Verify that all network equipment is powered on and all cables connect to the right interfaces.
2. Check the FortiGate LEDs
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.
3. Ping the FortiGate
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.
4. Check the FortiGate interface configurations (NAT/Route mode

only)
Check the configuration of the FortiGate interfaces to make sure you use the correct Addressing Mode for your
network.

5. Verify the security policy configuration
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.
6. Verify the static routing configuration (NAT/Route mode only)
Make sure you configured a default gateway IP address, provided by your ISP.
7. Verify that you can connect to the Internet-facing interface’s IP

address (NAT/Route mode only)
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.
9. Ping an IP on the Internet
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.

10. Verify the DNS configuration
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.
11. Resetting the FortiGate
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.
12. Contacting Fortinet Support
If you need further assistance with troubleshooting your FortiGate, visit the Fortinet Support website.

FortiGate logging troubleshooting
This section contains tips to help you with some common challenges of FortiGate logging.
No log messages appear in the GUI.
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.
Logs from a FortiAnalyzer, FortiManager, or from FortiCloud do not

appear in the GUI.
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
The FortiGate unit’s performance level has decreased since

enabling disk logging.
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.
Logging to a FortiAnalyzer unit is not working as expected.

FortiGate registration and basic settings
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
1. Registering your FortiGate
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.

The License Information widget now displays the unit as Registered.

A Launch Portal button also appears, which allows you to quickly access the Fortinet Support Portal.
2. Setting the system time
Go to the Dashboard and locate the System Information widget.

Next to System Time, select Change.

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.
The System Information widget now displays the correct time.
3. Changing the default admin password
Go to System > Administrators and edit the default admin account.

Select Change Password. Leave Old Password blank and enter the New Password.
You will be automatically signed out after changing the password.

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.

5. (Optional) Restricting administrative access to a trusted host
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.

FortiToken two-factor authentication with RADIUS on a

FortiAuthenticator
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.
1. Adding the FortiToken to FortiAuthenticator
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.

2. Adding the FortiToken user to FortiAuthenticator
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.
3. Creating the RADIUS Client on FortiAuthenticator
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.
4. Connecting the FortiGate to the RADIUS Server
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.

5. Configuring the SSL VPN on FortiGate
On the FortiGate, go to VPN > SSL-VPN Portals, and edit the full-access portal.
Disable Split Tunneling.
Go to VPN > SSL-VPN Settings.

Under Connection Settings set Listen on Port to 10443.
Under Tunnel Mode ClientSettings, select Specify custom IP ranges andset it to SSLVPN_TUNNEL_ADDR1.
Under Authentication/Portal Mapping, select Create New.
Assign the SSLVPNGroup user group to the full-access portal, and assign All Other Users/Groups to web-access
— this will grant all other users access to the web portal only.

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).
The user will then be prompted to enter their FortiToken code.

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.

Guest WiFi accounts
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.
1. Creating a WiFi guest user group
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.

2. Creating a guest SSID that uses Captive Portal
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 .

3. Creating a security policy for WiFi guests
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.

4. Creating a restricted admin account for guest user management
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.
5. Creating a guest user account
Using the reception account, create a guest account.

Set Email to the user's email address (in the example, ballen@example.com). To test the account, set Expiration to 5
Minutes.

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.

High Availability with FGCP (Expert)
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.
1. Configuring the primary FortiGate
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.

You can also enter this CLI command:

set hostname External-Primary
end
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

set override enable

end
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
2. Configuring the backup FortiGate
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.

From the System Information Dashboard widget, change

the new FortiGate's HostName to identify it as the backup FortiGate.
You can also enter this CLI command:

set hostname External-Backup
end
Duplicate the primary unit HA settings, except set the Device Priority to a lower value (for example, 50) and do not
enable override. 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

3. Connecting the cluster
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.
4. Checking cluster operation and disabling override
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.

High Availability with two FortiGates
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 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.

1. Setting up registration and licensing
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.
2. Configuring the Primary FortiGate for HA
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
3. Connecting the backup FortiGate
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.
4. Configuring the backup FortiGate for HA
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
5. Viewing the cluster status
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.
7. (Optional) Upgrading the firmware for the HA cluster
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.

Inspecting traffic content using flow-based inspection
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.
1. Changing from proxy to flow mode
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.

The System Information widget shows that flow-based inspection is set.
2. Configuring the AntiVirus profile
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.
3. Enabling AntiVirus in a policy
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.

Installing a FortiGate in NAT/Route mode
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).
1. Connecting the network devices and logging onto the FortiGate
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).
2. Configuring the FortiGate's interfaces
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.

3. Adding a default route
Go to Network> Static Routes and create a new 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. A default route always
has a Destination IP/Mask of 0.0.0.0/0.0.0.0. Normally, you would have only one default route. If the static route list
already contains a default route, you can edit it or delete it and add a new one.
4. (Optional) Setting the FortiGate's DNS servers
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.
5. Creating a policy to allow traffic from the internal network to the

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


Installing a FortiGate in Transparent mode
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).
1. Changing the FortiGate's operation mode
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.
2. (Optional) Setting the FortiGate's DNS servers
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.

3. Creating a policy to allow traffic from the internal network to the

Internet
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.
All Sessions.
4. Connecting the network devices
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.
Power on the FortiGate unit.
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.


Installing internal FortiGates and enabling Security Fabric
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.
1. Configuring External to connect to Accounting
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.
Connect the FortiGates.

2. Configuring the Accounting FortiGate
On the Accounting FortiGate, go to Network > Interfaces and edit wan1.

Set an IP/Network Mask for the interface that is on the same subnet as the External FortiGate's port 10 (in the
example, 192.168.10.10).
Configure Administrative Access to allow FortiTelemetry.
Edit the laninterface.

Set Addressing Mode to Manual and set the IP/Netmask to a private IP address (in the example, 10.10.10.1).
Configure Administrative Access to allow FortiTelemetry.
Under Networked Devices, enable Device Detection.

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.

3. Installing and configuring the Marketing FortiGate
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
4. Configuring OSPF routing between the FortiGates
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
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
5. Enabling the Cooperative Security Fabric
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
On the External FortiGate, go to FortiView > Physical Topology.

This dashboard shows a visualization of all access layer devices in the Cooperative Security Fabric.
On the External FortiGate, go to FortiView > Logical Topology.

This dashboard displays information about the interface (logical or physical) that each device in the CSF is connected
to.
Go to Monitor > Routing Monitor. You will see both ISFW FortiGates listed, using OSPF routing.
7. (Optional) Adding security profiles to the fabric
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.

Integrating a FortiGate with FortiClient EMS
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.
1. Configuring FortiClient EMS
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.

Go to View > Settings.

Enter and confirm a FortiHeartBeat Connection Key and enable Scan Local Workgroups. Make note of the
FortiHeartBeat Connection Key. This key will be required for the FortiClient endpoint to register.
Also note the FortiClient Download URL.
Save your changes.

2. (Optional) Importing Endpoint Profiles into FortiClient EMS
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.
3. Enabling and enforcing FortiHeartBeat on the FortiGate
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.

4. (Optional) FortiClient installer configuration
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.

You can also customize the installer itself in FortiClient EMS.

Go to View > Software Manager and +Add a custom installer.
Configure the installer as desired, then select Save.

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).
User & Device > Device List
Monitor > FortiClient Monitor


IPsec VPN for iOS 9
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.
1. Configuring the IPsec VPN using the IPsec VPN Wizard
On the FortiGate, go to VPN > IPsec Wizard.

Name the VPN connection (iPhoneVPN ).
Select the Remote Access template, select the iOS Native device type, and select Next.

Set the Incoming Interface to the Internet-facing interface (wan1).

Select the Pre-shared Key authentication method and enter a pre-shared key.
Select the iphone-users user group 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, 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.

2. Connecting to the IPsec VPN from iPhone
On the iPhone, go to Settings > General > VPN and select Add VPN Configuration.
Set Type to IPsec and enter a Description (required).

Set Server to the FortiGate's Internet-facing interface, and enter the user's name in Account.
Enter the user's password, the pre-shared IPsec VPN secret, and select Done.


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 .

IPsec VPN for Windows Phone 10
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.
Go to VPN > IPSec Wizard.

Name the VPN connection (WinPhoneVPN ).
Select the Remote Access template, select the Windows Native device type, and select Next.


Select the WinPhone_Users user group and select Next.

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.
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.
2. Connecting to the IPsec VPN from the Windows Phone 10
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.
You should now be connected to the IPsec VPN.

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 .

IPsec VPN to Microsoft Azure
The following recipe demonstrates how to configure a site-to-site IPsec VPN tunnel to Microsoft Azure™.
Using FortiOS 5.4, the example describes how to configure the tunnel between each site, avoiding overlapping subnets,
so that a secure tunnel can be established.
1. Configuring the Microsoft Azure virtual network
Log into Microsoft Azure and click New. In the Search the marketplace field, type “Virtual Network”.
Locate Virtual Network from the returned list and click to open the Virtual Network blade.

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

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

2. Specifying the Microsoft Azure DNS server
Open the virtual network you just created, navigate to DNS Servers, and click to open the DNS servers blade.
Enter the IP address of the DNS server and click Save at the top of the blade.

3. Creating the Microsoft Azure virtual network gateway
In the portal dashboard, go to New.

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

In the Create virtual network gateway blade, fill in the values for your virtual network gateway.
Create a Public IP address if necessary and click Create at the bottom.

Provisioning the virtual network gateway may take some time.

You will receive a notification about the deployment.

4. Creating the Microsoft Azure local network gateway
From the dashboard, select All resources.

Click +Add and then choose to See all.
In the Everything blade search box, type Local network gateway, and select Create local network gateway.
Set IP address to the local network gateway address (the FortiGate's external IP address).

Fill in the remaining values for your local network gateway and click Create.
5. Configuring the FortiGate tunnel
Go to VPN > IPsec Wizard.

Enter a Name for the tunnel, select Custom, and click Next.
Set the Remote Gateway to Static IP Address, and include the gateway IP Address provided by Microsoft Azure.
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.

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

Set the Encryption combinations.
Disable Perfect Forward Secrecy.
Set Key Lifetime Seconds to 27000.

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

7. Creating the FortiGate firewall policies
Go to Policy & Objects > IPv4 Policy and create a new policy for the site-to-site connection that allows outgoing
traffic.
Set the Source Address and Destination Address using the firewall objects you just created.
Ensure that NAT is disabled.

Create a second policy for the same connection to allow incoming traffic.
This time, invert the Source Address and Destination Address.

In order to avoid packet drops and fragmentation, it is strongly recommended to limit the TCP maximum segment size
(MSS) being sent and received.
Enter the following in the CLI Console for both firewall policies:
edit <policy-id>
set tcp-mss-sender 1350
set tcp-mss-receiver 1350
next
end
8. Creating the FortiGate static route
Go to Network > Static Routes and create a new static route forcing outgoing traffic destined to the Microsoft Azure
network to flow through the route-based tunnel.

Set the Administrative Distance to a value lower than the value set for the existing default route.
9. Creating a Microsoft Azure Site-to-Site VPN connection
In the Azure portal, locate and select your virtual network gateway.
On the Settings blade, click Connections, and then click Add at the top of the blade to open the Add connection
blade.

Fill in the values for your connection and click OK.

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

10. Results
Go to Monitor > IPsec Monitor. You should see that the tunnel is UP.
If it is down, right-click the tunnel and select Bring Up. 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.

Go to Log & Report > VPN Events

Select an entry to view more information and verify the connection.
Return to the Microsoft Azure portal, click All resources and navigate to your virtual network gateway.
On the blade for your virtual network gateway, click Connections. You can see the status of each connection.
Click the name of the connection that you want to verify to open Essentials.

In Essentials, you can view more information about your connection.
The Status is ‘Connected' when you have made a successful connection.

Ingress and egress bytes confirm traffic flowing through the tunnel.

IPsec VPN troubleshooting
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.
The options to configure policy-based IPsec VPN are unavailable.
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
The VPN tunnel goes down frequently.
If your VPN tunnel goes down often, check the Phase 2 settings and either increase the Keylife value or enable
Autokey Keep Alive.
The pre-shared key does not match (PSK mismatch error).
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
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 SA proposals do not match (SA proposal mismatch).
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
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:
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:
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.
Pre-existing IPsec VPN tunnels need to be cleared.
Should you need to clear an IKE gateway, use the following commands:
diagnose vpn ike restart
diagnose vpn ike gateway clear
LAN interface connection
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.
Troubleshooting VPN connections
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.
To get diagnose information for the VPN connection – CLI
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:
3. Clear any existing log-filters by running:

diagnose vpn ike log-filter clear
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:

diagnose vpn ike log-filter dst-addr4 10.11.101.10.
5. Set up the commands to output the VPN handshaking. The commands are:
diagnose debug app ike 255
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.
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.
To troubleshoot a phase1 VPN connection
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.
VPN troubleshooting tips
Attempting hardware offloading beyond SHA1
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.

Enable/disable IPsec ASIC-offloading
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
Check Phase 1 proposal settings
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.
Check your routing
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.
Try enabling XAuth
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.
General troubleshooting tips
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.
VPN troubleshooting tips
Configuration problem Correction
Mode settings do not match. Select complementary mode settings.
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.
Preshared keys do not match. Reenter the preshared key.
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.
NAT traversal settings are Select or clear both options as required.

mismatched.
A word about NAT devices
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.

IPsec VPN two-factor authentication with FortiToken-200
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.
1. Adding the FortiToken
Go to User & Device > FortiTokens and create a new FortiToken.

Set Type to Hard Token and enter the FortiToken's Serial Number into the field provided. Note that the serial
number, located on the back of the FortiToken device, is case sensitive and must not be in use elsewhere.

2. Editing the user and assigning the FortiToken
Go to User & Device > User Definition and edit elainemarley.

Select Enable Two-factor Authentication and select the token.
Select Add this user to groups and add the user to FTK-users.
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 Authentication Method to Pre-shared Key and enter a pre-shared key.
Select the user group created earlier (FTK-users) and select Next.

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.

Configure additional Client Options and select Create.

A summary page will appear showing the VPN's configuration.

4. Connecting to the IPsec VPN
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
Go to Remote Access and attempt to log into the VPN as elainemarley.

You will then be prompted to enter a FortiToken Code. Enter the code and select OK.

The useris now successfully connected to the IPsec VPN FTK-VPN .

To verify the user's connection, go to FortiView > VPN .
You can also go to Monitor > IPsec Monitor to view the tunnel's status, and Monitor > FortiClient Monitor to view
the user and device.


IPsec VPN with FortiClient
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.
1. Creating a user group for remote users
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.
2. Adding a firewall address for the local network
Go to Policy & Objects > Addresses and create an address for the local network.
Set Type to IP/Netmask, Subnet/IP Range to the local subnet, and Interface to an internal port.

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.

Select Client Options as desired.
After you create the tunnel, a summary page appears listing the objects which have been added to the FortiGate's
configuration by the wizard.

4. Creating a security policy for access to the Internet
The IPsec wizard automatically created a security policy allowing IPsec VPN users to access the internal network.
However, since split tunneling is disabled, another policy must be created to allow users to access the Internet through
the FortiGate.
Go to Policy & Objects > IPv4 Policies and create a new policy. Set a policy name that will identify what this policy is
used for (in the example, IPsec-VPN-Internet).
Set Incoming Interface to the tunnel interface and Outgoing Interface to wan1. Set Source to the IPsec client
address range, Destination Address to all, Service to ALL, and enable NAT.
Configure any remaining firewall and security options as desired.


5. Configuring FortiClient
Open FortiClient, go to Remote Access and Add a new connection.
Set the Type to IPsec VPN and Remote Gateway to the FortiGate IP address.
Set Authentication Method to Pre-Shared Key and enter the key below.

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

Once the connection is established, the FortiGate assigns the user an IP address and FortiClient displays the status of
the connection, including the IP address, connection duration, and bytes sent and received.
On the FortiGate 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.

IPsec VPN with native Mac OS X client
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.
1. Configuring the IPsec VPN using the Wizard
Go to VPN > IPsec Wizard.

Name the VPN connection, set Template Type to Remote Access, select the Cisco Client remote device type, and
select Next. You must select Cisco Client because the native Mac OS client is a Cisco client. If you require an IPsec
VPN created for Mac mobile devices (such as iPhones and iPads), select the iOS Native remote device type.

Set Incoming Interface to the Internet-facing interface.

Apply the appropriate User Group and select Next.

Enter a Client Address Range for VPN users and select Create.
Disable split tunneling if you want all traffic (Internet and internal) to go through the IPsec VPN tunnel.

The VPN Creation Wizard provides a summary of created objects.

2. Creating a security policy for remote access to the Internet
Go to Policy & Objects > IPv4 Policy and create a new policy that allows remote users to securely access the
Internet.
Set Incoming Interface to the newly created tunnel interface and set Outgoing Interface to the Internet-facing
interface.
Set Source to all, Destination Address to all, Schedule to always, and Service to ALL.
Enable NAT and select OK.
3. Results
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.

L2TP IPsec VPN on FortiGate
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.
1. Creating an L2TP user and user group
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.
2. Enabling L2TP in the CLI Console
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
3. Configuring the L2TP/IPsec phases
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

set peertype dialup

set dpd disable
set proposal 3des-sha1 aes192-sha1 aes256-md5
set usrgrp L2TP-group
set psksecret <preshared_key>
next
end
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
4. Creating a firewall address for L2TP clients
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.

5. Creating Security Policy for access to the internal network and

the Internet
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).

6. Configuring a remote Windows 7 L2TP client
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.

The connection is now ready to use. Select Close.
Next, go to Start > Control Panel > Network and Sharing Center and select Connect to a network.

Open the L2TP VPN configured earlier.

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.


Limiting bandwidth with traffic shaping
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.
1. Enabling Traffic Shaping
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.

2. Creating a firewall address
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.
3. Configuring a traffic shaper to limit bandwidth
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.
Enter the following CLI commands:

set per-policy enable
end
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.

4. Verifying your Internet access security policy
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.
5. Create two Traffic Shaping Policies
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.

Logging FortiGate traffic and using FortiView
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.
1. Configuring log settings
Go to Log & Report > Log Settings.

Select where log messages will be recorded. In this example, Local Log is used, because it is required by FortiView.
Local logging is not supported on all FortiGate models. If your FortiGate does not support local logging, it is
recommended to use FortiCloud.
Enable Disk, Local Reports, and Historical FortiView.

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).
2. Enabling logging in security policies
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.

Logging traffic with FortiGate Cloud
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.
1. Activating FortiGate Cloud
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.
2. Sending logs to FortiGate Cloud
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.
3. Enabling logging in your Internet access security policy
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.

MAC access control with a WiFi network
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.
1. Finding the MAC address of a device
For Windows devices:
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.
For Mac OS X devices:
Open Terminal and type ifconfig en1 | grep ether.

Take note of the displayed MAC address.
For iOS devices:
Open Settings > General> About.

The Wi-Fi Address is the MAC address of your iOS device.
For Android devices:
Open Settings > General > About Phone > Hardware Info.
Take note of the Wi-Fi MAC address of your Android device.

2. Defining a device using its MAC address
Go to User & Device > Custom Devices & Groups and create a new device definition.
Set MAC Address to the device's address 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.

3. Creating a device group
Go to User & Device > Custom Devices & Groups and create a new group.
Add the new device to the Members list.
4. Reserving an IP address for the device
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.
5. Creating a security policy for wireless traffic
Go to Policy & Objects > IPv4Policy and create a new policy.

Set Incoming Interface to your wireless interface, Source Device Type to the device group, and Outgoing
Interface to the Internet-facing interface.
Ensure that NAT is turned on.

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.

Make it a policy to learn before configuring policies
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:

l DNS Filter – There is no Flow mode for this profile

l Web Application Firewall – There is no Flow mode for this profile
l SSL deep inspection. Without SSL inspection, turning on CASI serves little purpose.)
Logging and Reporting
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
Why do you want to know this information?
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.
The obligatory warning
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

Monitoring and blocking P2P traffic
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.
1. Enabling Application Control and Multiple Security Profiles
Go to System > Feature Select and ensure that Application Control and Multiple Security Profiles are enabled.

2. Using the default Application Control profile to monitor network

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

3. Editing the security policy for outgoing traffic
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.

4. Reviewing the FortiView dashboards
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.
5. Creating an application profile to block P2P applications
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.

6. Adding the blocking profile to a security policy
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.
Listing of Netflow Templates for FortiOS 5.4.x or later
Name ID Description
Flow Options 256 Statistics info about exporter
Flow Options 257 Application Info
IPv4 258 No NAT IPv4 traffic
IPv6 259 No NAT IPv6 traffic
ICMP4 260 No NAT ICMPv4 traffic
ICMP6 261 No NAT ICMPv6 traffic
IPv4_NAT 262 Source/Dest NAT IPv4 traffic
IPV4_AF_NAT 263 AF NAT IPv4 traffic (4->6)
IPV6_NAT 264 Source/Dest NAT IPv6 traffic
IPV6_AF_NAT 265 AF NAT IPv6 traffic (6->4)
ICMPv4_NAT 266 Source/Dest NAT ICMPv4 traffic
ICMP4_AF_NAT 267 AF NAT ICMPv4 traffic (4->6)
ICMP6_NAT 268 Source/Dest NAT ICMPv6 traffic
ICMPv6_AF_NAT 269 AF NAT ICMPv6 traffic (6->4)
ID 256 – Flow options
l Description: Statistics info about exporter

l Scope Field Count: 1
l Data Field Count: 7
l Option Scope Length: 4
l Option Length: 28
l Padding: 0000

Scope Fields
Field # Field Scope Type Length
1 System System (1) 2
Data Fields
1 TOTAL_BYTES_EXP TOTAL_BYTES_EXP (40) 8
2 TOTAL_PKTS_EXP TOTAL_PKTS_EXP (41) 8
3 TOTAL_FLOWS_EXP TOTAL_FLOWS_EXP (42) 8
4 FLOW_ACTIVE_TIMEOUT FLOW_ACTIVE_TIMEOUT (36) 2
5 FLOW_INACTIVE_TIMEOUT FLOW_INACTIVE_TIMEOUT (37) 2
6 SAMPLING_INTERVAL SAMPLING_INTERVAL (34) 4
7 SAMPLING_ALGORITHM SAMPLING_ALGORITHM (35) 1
ID 257 – Flow options
l Description: Application Info

l Scope Field Count: 1
l Option Scope Length: 4
l Option Length: 16
l Padding: 0000
Scope Fields
1 System System (1) 2
Data Fields
1 APPLICATION_ID APPLICATION_ID (95) 9
2 APPLICATION_NAME APPLICATION_NAME (96) 64
3 APPLICATION_DESC APPLICATION_DESC (94) 64
4 applicationCategoryName applicationCategoryName (372) 32

ID 258 – IPV4
l Description: No NAT IPv4 traffic

Data Fields
1 BYTES BYTES (1) 8
2 OUT_BYTES OUT_BYTES (23) 8
3 PKTS PKTS (2) 4
4 OUT_PKTS OUT_PKTS (24) 4
5 FIRST_SWITCHED FIRST_SWITCHED (22) 4
6 LAST_SWITCHED LAST_SWITCHED (21) 4
7 L4_SRC_PORT L4_SRC_PORT (7) 2
8 L4_DST_PORT L4_DST_PORT (11) 2
9 INPUT_SNMP INPUT_SNMP (10) 2
10 OUTPUT_SNMP OUTPUT_SNMP (14) 2
11 PROTOCOL PROTOCOL (4) 1
13 Unknown(65) Unknown (65) 2
14 FORWARDING_STATUS FORWARDING_STATUS (89) 1
15 flowEndReason flowEndReason (136) 1
16 IP_SRC_ADDR IP_SRC_ADDR (8) 4
17 IP_DST_ADDR IP_DST_ADDR (12) 4
ID 259 – IPV6
l Description: No NAT IPv6 traffic

Data Fields
1 BYTES BYTES (1) 8

3 PKTS PKTS (2) 4
16 IPV6_SRC_ADDR IPV6_SRC_ADDR (27) 16
17 IPV6_DST_ADDR IPV6_DST_ADDR (28) 16
ID 260 – ICMP4
l Description: No NAT ICMPv4 traffic

Data Fields
1 BYTES BYTES (1) 8
3 PKTS PKTS (2) 4

9 ICMP_TYPE ICMP_TYPE (32) 2
16 IP_DST_ADDR IP_DST_ADDR(12) 4
ID 261 – ICMP6
l Description: No NAT ICMPv6 traffic

Data Fields
1 BYTES BYTES (1) 8
3 PKTS PKTS (2) 4

ID 262 – IPV4_NAT
l Description: Source/Dest NAT IPv4 traffic

Data Fields
1 BYTES BYTES (1) 8
3 PKTS PKTS (2) 4
18 postNATSourceIPv4Address postNATSourceIPv4Address (225) 4
19 postNATDestinationIPv4Address postNATDestinationIPv4Address (226) 4
20 postNAPTSourceTransportPort postNAPTSourceTransportPort (227) 2
21 postNAPTDestinationTransportPort postNAPTDestinationTransportPort 2
(228)

ID 263 – IPV6_NAT
l Description: Source/Dest NAT IPv6 traffic

Data Fields
1 BYTES BYTES (1) 8
3 PKTS PKTS (2) 4
13 Unknown(65) Unknown(65) 2
(228)
ID 264 – IPV4_AF_NAT
l Description: AF NAT IPv4 traffic (4->6)


Data Fields
1 BYTES BYTES (1) 8
3 PKTS PKTS (2) 4
13 Unknown(65) Unknown(65) 2
(228)
ID 265 – IPV6_AF_NAT
l Description: AF NAT IPv6 traffic (6->4)

Data Fields
1 BYTES BYTES (1) 8

3 PKTS PKTS (2) 4
(228)
ID 266 – ICMPV4_NAT
l Description: Source/Dest NAT ICMPv4 traffic

Data Fields
1 BYTES BYTES (1) 8
3 PKTS PKTS (2) 4

(228)
ID 267 – ICMPV6_NAT
l Description: Source/Dest NAT ICMPv6 traffic

Data Fields
1 BYTES BYTES (1) 8
3 PKTS PKTS (2) 4

(228)
ID 268 – ICMPV4_AF_NAT
l Description: AF NAT ICMPv4 traffic (4->6)

Data Fields
1 BYTES BYTES (1) 8
3 PKTS PKTS (2) 4

(228)
ID 269 – ICMPV6_AF_NAT
l Description: AF NAT ICMPv6 traffic (6->4)

Data Fields
1 BYTES BYTES (1) 8
3 PKTS PKTS (2) 4

(228)
Field Type Definitions
For a list of field type definitions see Table 6 on the Cisco Whitepaper found here.

Overriding a web filter profile
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.
1. Enabling web filtering and multiple profiles
Go to System > Feature Select to enable Web Filter and Multiple Security Profiles.
Apply changes if necessary.
2. Creating a user group and two users
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).

Assign ckent to the web-filter-override group, but not bwayne.
3. Creating a web filter profile and an override
Go to Security Profiles > Web Filter to create a new profile (block-bandwidth-consuming).

Enable FortiGuard category based filter, then right-click Bandwidth Consuming and select Block.

Enable Allow users to override blocked categories.

Set Groups that can override to web-filter-override, Profile can switch to default, Switch applies to User Group,
and Switch Duration to Ask.

4. Adding the new web filter profile to a security policy
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, a website that is part of the Bandwidth Consuming category.

Authenticate using the bwayne account. The website is blocked.
Go to Monitor > Firewall User Monitor and De-authenticate bwayne.
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.

Preventing certificate warnings
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.
Using the default 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.

1. Generating a unique certificate
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
2. Downloading the certificate used for full SSL inspection
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.
3. Installing the certificate on the user’s browser
Internet Explorer, Chrome, and Safari (on Windows or Mac OS):
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 (on Windows or Mac OS)
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.

Using a self-signed certificate
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.
1. Creating a certificate with OpenSSL
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).
2. Enabling certificate configuration in the GUI
Go to System > Feature Select. Under Additional Features, enable Certificates and Apply the changes.

3. Importing the self-signed certificate
Go to System > Certificates and select Import> Local Certificate.

Set Type to Certificate, then select your Certificate file and Key file. Enter the Password used to create the
certificate.
The certificate now appears on the Local CA Certificates list.
4. Edit the SSL inspection profile
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.
Set CA Certificate to use the new certificate.

Select Download Certificate, to download the certificate file needed in the next step.

5. Importing the certificate into the web browser
Internet Explorer, Chrome, and Safari (on Windows or Mac OS):
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.


Preventing data leaks
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.
1. Enabling DLP and Multiple Security Profiles
Go to System > Feature Select and confirm that DLP and Multiple Security Profiles are enabled.

2. Creating a DLP profile
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.

Set Action to Block.
Create a second filter.

Set the filter to look for Files. Select Specify File Types. In the File Name Patterns field, enter the pattern you wish
to match. If desired, use a wildcard character in the pattern.
Set Action to Block.

Both filters now appear in the Filter list.
3. Adding the profile to a security policy
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.

Protecting a server running web applications
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.
1. Enabling Web Application Firewall
Go to System > Feature Select and enable Web Application Firewall. Select Show More and enable Multiple
Security Profiles.
Apply your changes.

2. Editing the default Web Application Firewall profile
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.

3. Applying the profile to a security policy
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.

Protecting a web server with DMZ
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.
1. Configuring the FortiGate's DMZ interface
Go to Network > Interfaces and edit the DMZ interface.

This example uses the port3 interface as the DMZ interface. The interface Alias indicates that this is the DMZ
interface. As well the Role is set to DMZ.
For enhanced security, disable all Administrative Access options.

2. Creating virtual IPs (VIPs)
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.


3. Creating firewall policies
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.

Protection from Botnet C&C attacks
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.
1. Enabling the DNS Filter Security Feature
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.
Under Options, enable Block DNS requests to known botnet C&C .

3. Configuring Static Domain Filter in DNS Filter Profile
In the DNS Filter Profile, enable Domain Filter under Static Domain Filter. You will now be able to add domains of
your choosing.
Select Create and enter *.facebook.com.

Set Type to Wildcard, and set Action to Block. Make sure Status is enabled. This will block access to Facebook, and
all its other affiliated subdomains.
4. Creating a DNS Filtering firewall policy
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.

Redundant internet connections
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.
1. Connecting your ISPs to the FortiGate
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.
2. Deleting security policies and routes that use WAN1 or 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.
3. Creating a WAN link interface
Go to Network > WAN LLB (WAN Link Load Balancing).

Set the Interface State to Enable.
Under WAN LLB, select Create New to add an interface.

Add wan1 and enter the Gateway IP provided by your primary ISP. Do the same for wan2, but this time use the
Gateway IP provided by your secondary ISP.

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.
4. Configuring Health Check (optional)
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:

config system virtual-wan-link

set fail-detect [enable | disable]
set fail-alert-interfaces (available only if fail-detect is enabled)
config health-check
edit [health check name]
set server <string>
set protocol [ping | tcp-echo | udp-echo | http | twamp ]
...
set timeout <integer>
set failtime [1-10]
set recoverytime [1-10]
set update-cascade-interface [enable | disable]
set update-static-route [enable | disable ]
next
end
end
5. Creating a default route for the WAN link interface
Go to Network > Static Routes and create a new default route.

Set Device to the WAN link interface.
6. Allowing traffic from the internal network to the WAN link

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

Set Incoming Interface to your internal network's interface and set Outgoing Interface to the WAN link interface.
Turn on NAT.

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.

Sandboxing with FortiSandbox and FortiClient
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.
1. Connecting the FortiSandbox
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.

2. Enabling Sandbox Inspection
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.

3. Configuring sandboxing in the default AntiVirus profile
Go to Security Profiles > AntiVirus and edit the default profile.

Under Inspection Options, enable both Send Files to FortiSandbox Appliance for Inspection and Use
FortiSandbox Database.
If FortiSandbox discovers a threat, it creates a signature for that file that is added to the FortiGate’s AntiVirus signature
database.
4. Configuring sandboxing in the default Web Filter profile
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.
5. Configuring sandboxing in the default FortiClient profile
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.
6. Applying AntiVirus and Web Filter scanning to network traffic
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.

Setting up a WiFi Bridge with a FortiAP
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.
1. Connecting and authorizing the FortiAP unit
Connect the FortiAP to the lan interface.
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.

3. Creating a custom FortiAP profile
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.

Setting up FortiGuard services
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.
1. Verifying the connection
Go to the Dashboard and find the License Information widget.

An icon appears beside each FortiGuard service, indicating its current status. Only services that have been enabled in
Feature Select will appear in the widget. To enable more services, go to System > Feature Select.
l : the service is active and the FortiGate is connected to FortiGuard network.
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.

2. Troubleshooting communication errors
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
--- guard.fortinet.net ping statistics ---
To test if the FortiGuard services are reachable, go to System > FortiGuard.
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.

Setting up WiFi with a FortiAP
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.
1. Connecting and authorizing the FortiAP unit
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.

Connect the FortiAP unit to the interface.
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.

Set Traffic Mode to Tunnel to Wireless Controller.

Select an IP/Network Mask for the wireless interface and enable DHCP Server.
Set the WiFi Settings as required and set a secure Pre-shared Key.

3. Creating a custom FortiAP profile
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.

4. Allowing wireless access to the Internet
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.

Site-to-site IPsec VPN with two FortiGates
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.
1. Configuring the HQ IPsec VPN
On the HQ FortiGate, go to VPN > IPsec Wizard.

Select the Site to Site template, and select FortiGate.

In the Authentication step, set IP Address to the IP of the Branch FortiGate (in the example, 172.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.

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

Select the Site to Site template, and select FortiGate.
In the Authentication step, set IP Address to the IP of the HQ FortiGate (in the example, 172.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.

SSL VPN for users with passwords that expire
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. Creating the SSL VPN user and user group
1. Go to User & Device > User Definition > Create New and create a new user via the Users/Groups Creation
wizard.

2. Enter a User Name and Password.
3. Enter contact information via Email Address. SMS information should be provided if required.
4. Enable the user account and apply Two-factor Authentication if required.

5. Click Create.
6. Go to User & Device > User Groups and create a user group that includes the newly created user.

2. Configuring and assigning the password policy
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
The password policy includes an expiration time and a warning time.

2. Assign the password policy to the newly created user using the following commands.
config user local
edit "jsnow"
set type password
set passwd-policy "pwpolicy1"
next
end
By default, the start time for the password is set to the time the user was created.
3. Configuring the SSL VPN web portal and settings
1. Go to VPN > SSL-VPN Portals and select full-access.

2. Disable Enable Split Tunneling. and select the Source IP Pools. In the example, the default SSLVPN_
TUNNEL_ADDR1 pool will suffice.

3. Enable Tunnel Mode Client Options as required, ensure that you Enable Web Mode and click OK.
4. Go to VPN > SSL-VPN Settings.

5. Under Connection Settings, set Listen on Interface(s) to the Internet-facing interface and set Listen on Port
to 10443. This will avoid an administrative HTTPS port conflict. You can also change the administration HTTPS
port in System > Settings.

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.
4. Adding security policies for access to the internal network and

the Internet
1. Go to Policy & Objects > IPv4 Policy and add a security policy allowing access to the internal network through
the VPN tunnel interface.

2. Include the newly created user group and enable NAT.
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.


SSL VPN single sign-on using LDAP-integrated certificates
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.


2. Requesting and installing a server certificate for FortiOS
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.
Go to System > Certificates and select Import > CA Certificate.

Select the Microsoft CA certificate file.

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

Download the resulting signed request in BASE64 format.

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.

3. Configuring LDAP, PKI and a group
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.
What just happened here?

This configuration is counter-intuitive at first glance as matching against a group object generally means matching at
least one of its members.
However when using a PKI object in the “member” field, the group object’s behaviour change and instead, the group will
only match if the PKI object is true (the certificate is valid and trusted and the user exists in LDAP) AND the group
memberships obtained from LDAP for the user also match one of the remote LDAP groups defined.
We will look at connection debug information later to see this process happening.
5. Configuring the SSL VPN settings

Ensure that the Require Client Certificate option is checked.
Select the certificate we generated earlier for FortiOS.
If needed, map our newly created group to a specific portal definition. This is only necessary if the default portal
(designated by “All Other Users/Groups” entry) is not the right one. In our case, it wasn’t necessary to define the group
to portal mapping as the default portal was the same.

6. Configuring the policy
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'

[1483] check_add_peer-check peer user 'FORTIQC_CERTS' in group 'FORTIQC_PKI_GrpCertAuth', res-

ult is 4
[1614] cert_check_group_list-Status pending for group 'FORTIQC_PKI_GrpCertAuth'
[804] resolve_ldap_FQDN-Resolved address 192.168.129.40, result 192.168.129.40
[1185] fnbamd_ldap_init-search filter is: (&(userPrincipalName=user1@fortiqc.local)
(!(UserAccountControl:1.2.840.113556.1.4.803:=2)))
[1189] fnbamd_ldap_init-search base is: dc=fortiqc,dc=local
[258] start_search_dn-base:'dc=fortiqc,dc=local' filter:(&(user-
PrincipalName=user1@fortiqc.local)
(!(UserAccountControl:1.2.840.113556.1.4.803:=2)))
...
[306] get_all_dn-Found 1 DN's
[556] start_user_attrs_lookup-Adding attr 'memberOf'
[577] start_user_attrs_lookup-base:'CN=user1,CN=Users,DC=fortiqc,DC=local' filter:cn=*
...
[1851] fnbamd_ldap_get_result-Going to DONE state res=0
[141] __ldap_copy_grp_list-copied CN=GrpCertAuth,CN=Users,DC=fortiqc,DC=local
[141] __ldap_copy_grp_list-copied CN=testgroup,CN=Users,DC=fortiqc,DC=local
[141] __ldap_copy_grp_list-copied CN=Domain Users,CN=Users,DC=fortiqc,DC=local
[1845] __match_ldap_group-Matching server 'FORTIQC' - 'FORTIQC'
[1853] __match_ldap_group-Matching group
'CN=GrpCertAuth,CN=Users,DC=fortiqc,DC=local' - 'CN=GrpCe-
ertAuth,CN=Users,DC=fortiqc,DC=local'
[1953] fnbamd_auth_cert_poll-Result for ldap svr[0] '192.168.129.40' is SUCCESS
[1959] fnbamd_auth_cert_poll-matched user 'FORTIQC_CERTS', matched group 'FORTIQC_PKI_GrpCer-
tAuth'
...
MN140D-1 (root) # diag firewall auth list

10.212.134.200, cn=user1, FORTIQC_PKI_GrpCertAuth
type: fw, id: 0, duration: 181, idled: 0
expire: 28797, allow-idle: 28797
flag(a0): idle sslvpn
packets: in 1427 out 1505, bytes: in 291364 out 359030
group_id: 2
group_name: FORTIQC_PKI_GrpCertAuth
----- 1 listed, 0 filtered ------
8. Logs
Finally, our logs show our LDAP user’s traffic:

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.

SSL VPN troubleshooting
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
Use the following diagnose commands to identify SSL VPN issues:
1. Display debug messages
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.
2. Verify the debug configuration
To verify the debug configuration, use the following command:

diagnose debug info
debug output: disable
console timestamp: disable
console no user log message: disable
sslvpn debug level: -1 (0xffffffff)
CLI debug level: 3
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.
3. Display debug messages
To enable displaying debug messages, use the following command:

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)

[282:root]SSL state:SSLv3 read finished A:system lib(172.20.120.12)

[282:root]SSL state:SSLv3 read finished A (172.20.120.12)
[282:root]SSL state:SSL negotiation finished successfully (172.20.120.12)
[282:root]SSL established: DHE-RSA-AES256-SHA SSLv3 Kx=DH Au=RSA Enc=AES(256) Mac=SHA1
4. End the debug process
To stop displaying debug messages, use the following command:

diagnose debug reset
Common issues
The following is a list of potential issues. The suggestions below aren’t exhaustive and may not reflect your network
topology.
There is no response from the SSL VPN URL
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.
FortiClient cannot connect
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.

The SSL VPN login hangs or disconnects at 98%
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
Tunnel-mode connection shuts down after a few seconds
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:
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:
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)."
l Make sure that your browser has cookies enabled.

l If you are using a remote authentication server, confirm that the FortiGate is able to communicate with it.
The tunnel connects but there is no communication
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.
Users are unable to download the SSL VPN plugin
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.
Users are being assigned to the wrong IP range
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.
SSL VPN throughput is slow
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:
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.

SSL VPN using web and tunnel mode
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.
1. Creating a user and a user group
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.
2. Creating an SSL VPN portal for remote users
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.

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

To avoid port conflicts, set Listen on Port to 10443. Set Restrict Access to Allow access from any host.
In the example, the Fortinet_Factory certificate is used as the Server Certificate. It is, however, recommended that
you purchase a certificate for your domain and upload it for use with an SSL VPN.
Under Tunnel Mode Client Settings, set IP Ranges to use the default IP range SSLVPN_TUNNEL-ADDR1.
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.

4. Adding an address for the local network
Go to Policy & Objects > Addresses.

Add the address for the local network. Set Type to IP/Netmark, Subnet/IP Range to the local subnet, and Interface
to an internal port.
5. Adding security policies for access to the internal network and

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


6. Setting the FortiGate unit to verify users have current AntiVirus

software
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.
The web portal appears.

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.

The website will 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:
If you have not done so already, download FortiClient from www.forticlient.com.

Open the FortiClient Console and go to Remote Access. Add a new connection.
Set VPN Type to SSL VPN , set Remote Gateway to the IP of the listening FortiGate interface (in the example,
172.20.121.46). Select Customize Port and set it to 10443.
Select Add.
Connect to the VPN using the SSL VPN user's credentials.

You are able to connect to the VPN tunnel.
On the FortiGate, go to Monitor > SSL-VPN Monitor. The user is connected to the VPN.

SSL VPN with certificate authentication
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.
1. Enabling certificate management
Go to System > Feature Select and make sure that Certificates is enabled.
2. Installing the server certificate
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 server certificate now appears in the list of Certificates.
3. Installing the CA certificate
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.

The CA certificate now appears in the list of External CA Certificates (CA_Cert_1).
4. Creating PKI users and a user group
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.

5. Creating an SSL VPN portal
Go to VPN > SSL-VPN Portals.

Edit the full-access portal to confirm the default configuration.
Make sure that Enable Split Tunneling is disabled so that all SSL VPN traffic will go through the FortiGate unit.


6. Configuring the SSL VPN tunnel

Under Connection Settings, set Listen on Interface(s) to wan1. To avoid admin port conflicts, set Listen on Port
to 10443.
Set Server Certificate to the authentication certificate and enable Require Client Certificate.
Under Authentication/Portal Mapping, assign the user group to the full-access portal. If necessary, assign a portal
for All Other Users/Groups.

7. Adding security policies for access to the Internet and internal

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

8. Installing the user certificate
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.
Internet Explorer or Safari (on Windows or Mac OS):
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.

FortiClient (on Windows or Mac OS)
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 a web browser
Browse to the SSL VPN portal (https://172.20.120.184:10443).

When prompted,select the user certificate.
Enter user credentials when requested.

You are able to connect to the SSL VPN web portal.
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.

SSO using a FortiGate, FortiAuthenticator, and DC Polling
(Expert)
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.
1. Configuring the FortiAuthenticator
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.

2. Configuring SSO on the FortiGate
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.

3. Creating a user group on the FortiGate
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.
4. Adding a policy on the FortiGate
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.

5. Results from the FortiAuthenticator
Go toMonitor > SSO > Domains to verify monitored domains. In this example “techdoc.local” is monitored by the
FortiAuthenticator.
Have users log on to the domain.

Go toMonitor > SSO > SSO Sessions to verify SSO sessions.

Go toLogging > Log Access > Logs to verify logs.
Select an entry for details.
You can also verify FSSO users in the User Inventory widget under System > Dashboard > Status.

6. Results from the FortiGate
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.

Single Sign-On using FSSO agent in advanced mode and
FortiAuthenticator (Expert)
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.
1. Configuring an LDAP directory on the FortiAuthenticator
Go to Authentication > User Management > Local Users to create a user list. Make sure to enable Allow LDAP
browsing.

Single Sign-On using FSSO agent in advanced mode and FortiAuthenticator (Expert) 592
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.

2. Integrating the FortiGate with the FortiAuthenticator
On the FortiGate, go to User & Device > LDAP Servers to configure the LDAP server.
3. Installing FSSO agent on the Windows DC
Accept the license and follow the Wizard.

Enter the Windows AD administrator password.

Select the Advanced access method for Windows Directory.
In the Collector Agent IP address field, enter the IP address of the Windows AD server.

Select the domain you wish to monitor.
Next, select the users you do not wish to monitor.

Under Working Mode, select DC AgentMode.
When prompted, select Yes to reboot the Domain Controller.

Upon reboot, the collector agent will start up.

You can choose to Require authenticated connection from FortiGate and set a Password which will be used in
step 4.

4. Configuring Single Sign-On on the FortiGate
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.
5. Adding a user group to the FortiGate
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”).
6. Adding a policy to the FortiGate
Go to Policy & Objects > IPv4 Policy and create a policy allowing “FortiOS_Writers” to navigate the Internet with

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.


Single Sign-On using LDAP and FSSO agent in advanced
mode (Expert)
This recipe illustrates FortiGate user authentication with FSSO and a Windows DC LDAP server. In this example, user
authentication controls Internet access.
1. Integrating the FortiGate with the Windows DC LDAP server
Go to User & Device > LDAP Servers to configure the LDAP server.

2. Installing FSSO agent on the Windows DC server
Accept the license and follow the Wizard.

Enter the Windows AD administrator password.
Select the Advanced Access method.

In the Collector Agent IP address field, enter the IP address of the Windows AD server.
Select the domain you wish to monitor.

Next, select the users you do not wish to monitor.
Under Working Mode, select DC AgentMode.

Reboot the Domain Controller.
Upon reboot, the collector agent will start up.

You can choose to Require authenticated connection from FortiGate and set a Password.

3. Configuring Single Sign-On on the FortiGate
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.

4. Adding a user group to the FortiGate
Go to User & Device > User Groups to create a new FSSO user group.
Under Members, select the “FortiOS Writers” group.
5. Adding a policy to the FortiGate
Go to Policy & Objects > IPv4 Policy and create a policy allowing “FortiOS_Writers” to navigate the Internet with

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.


Traffic Shaping Priority Queueing (PRIQ)
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.
How traffic shaping really works
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).
Before you begin
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:

l Whether the traffic is through traffic or originates on the FortiGate.

l Whether traffic shaping is enabled in all your firewall policies.
Traffic shaping methods
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.
Dropping excess packets early on
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:
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.

How priority queuing works
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.
This diagram illustrates the following description:

l Administrative access traffic will always use queue 0.
l Traffic matching security policies without traffic shaping may use queue 0, queue 1, or queue 2. The queue is
selected based on the priority value you have configured for packets with that ToS (Type of Service) bit value, if you
have configured ToS-based priorities.
l Traffic matching security policies with traffic shaping enabled in the policy may use any queue. The queue is
selected based on whether the packet rate is currently below the guaranteed bandwidth (queue 0), or above the
guaranteed bandwidth. Packets at rates greater than the maximum bandwidth limit are dropped.
l If the global tos-based-priority is low (3) and the priority in a traffic-shaper is medium (2), when a packet flows
through a policy that refers to the shaper, the packet will be assigned the priority defined by the shaper. In this
case, medium (2).

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:
set traffic-priority-level {high|medium|low}
end
config system tos-based-priority

edit 1
set tos [0-15]
set priority (high|medium|low)
next
end
Type of Service (ToS) priority
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:
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.
ToS Priority Setting
High 1
Medium 2
Low 3
These priority levels conform to the firewall traffic shaping priorities, as defined in RFC 1349.
Firewall policy priority
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.
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:
Firewall Policy Priority Setting
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.
How do these priorities affect each other?
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.
Traffic passing through the FortiGate
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:
set traffic-priority-level {high | medium | low}
end
or, if you have configured a priority specifically for that TOS bit value:
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:
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.
Traffic queueing as as the packet rate increases.

l If the current packet rate is less than the guaranteed bandwidth, packets use priority queue 0. In other words,
packet priority = 0.
l If the current packet rate is greater than the guaranteed bandwidth, but less than maximum bandwidth, the
FortiGate unit assigns a priority queue by adding the numerical value of the security policy-based priority, where
high has a priority value of 0 and low is 2. Because the two values are added, depending on the configured ToS-
based priorities, packets in this category could use queues from queue 1 to queue 5. In other words, packet
priority = ToS-based priority + security policy-based priority. For example, if you have enabled Traffic
Shaping in the security policy, and the security policy’s Traffic Priority is Low (value 3), and the priority normally
applied to packets with that ToS bit is medium (value 1), then packets have a total packet priority of 4, and use
priority queue 4.
l If the current packet rate exceeds the maximum bandwidth, excess packets are dropped.
Traffic originating at the FortiGate
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.

Updating your FortiGate's firmware
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.
1. Checking the current FortiOS firmware
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.

2. Reviewing the Release Notes
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.
3. Updating to the latest firmware
If you wish to upgrade to the latest FortiOS version, select Update.

Under Available Firmware, select the Recommended tab, then select Backup Config and Upgrade.
If the firmware version you wish to upgrade to is not shown in this tab, it may be listed under All Available. When a
new FortiOS version is released, it may not be listed on your FortiGate right away. If this occurs, go to
https://support.fortinet.com to download the firmware, then use Upload Firmware to upgrade your FortiGate.

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.

User and device authentication
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.
1. Creating two users groups and adding users
Go to User & Device > User Groups.

Create the user group full-time.
Create a second user group, part-time.
Go to User & Device > User Definition.

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.
Both user names now appear in the user list.
2. Creating a schedule for part-time staff
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.

The default always schedule will be used for full-time staff.
3. Creating a policy for full-time staff
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.
All Sessions.

4. Creating a policy for part-time staff that enforces the schedule
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.
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.
5. Creating a policy that denies mobile traffic
Go to Policy & Objects > IPv4 and create a new policy.

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.

Using Hairpinning in a Network
What do hair pins have to do with networking?
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.

Using virtual IPs to configure port forwarding
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.
1. Creating three VIPs
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.

Next, create a second VIP for TCP port 21, webserver-ftp.

Finally, create a third a VIP for TCP port 22, webserver-ssh.

2. Adding VIPs to a VIP group
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.

3. Creating a security policy
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.
1. Switching to VDOM mode and creating two VDOMs
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:
set vdom-admin enable
end
Enter y when you are asked if you want to continue.

You will be required to re-login to the GUI after enabling virtual domains because the GUI menu options change.

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.
2. Configuring the root VDOM for FortiGate management
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 .

Go to System > Administrators and edit the admin account.

Select Change Password to add a password to this account.
Enable Restrict login to trusted hosts and add the IP/Netmask of the admin PC. This ensures that the admin must
login using the admin PC to be able to manage the FortiGate.

3. Adding interfaces to VDOM-A
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.

4. Adding interfaces to VDOM-B
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.


5. Adding administrators to each VDOM
Go to System > Administrators. Create an administrator for VDOM-A, called admin-a.

This administrator will be able to access and configure VDOM-A, without accessing either the root VDOM or VDOM-B.
The account will also not be able to affect global settings.
Enter and confirm a Password. Set Type to Local User and Administrator Profile to prof_admin. Remove the
root VDOM from the Virtual Domains list, then add VDOM-A.
Create an administrator that can access VDOM-B, called admin-b.

Enter and confirm a Password. Set Type to Local User and Administrator Profile to prof_admin. Remove the
root VDOM from the Virtual Domains list, then add VDOM-B.

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.
Generate Internet traffic for VDOM-A.

Go to FortiView > Policies and select the now view. You can see traffic flowing through the Internet-VDOM-A
policy.
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.
Generate Internet traffic for VDOM-B.

Go to FortiView > Policies and select the now view. You can see traffic flowing through the Internet-VDOM-B
policy.

Web and DNS filter troubleshooting
This section contains tips to help you with some common challenges of FortiGate web and DNS filtering.
The Web Filter menu is missing
Go to Feature Select/ Feature Visibility and enable Web Filter.
You cannot create new web filter profiles
Go to Feature Select/ Feature Visibility and enable Multiple Security Profiles.
You configured web filtering, but it is not working
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.
You configured DNS Filtering, but it is not working
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.
FortiGuard has the wrong categorization for a website
If you believe a website has been placed in the wrong category by FortiGuard, you can submit the URL for re-
classification by going to the FortiGuard website.

The website categorization on your FortiGate does not match the

FortiGuard categorization
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.
An active FortiGuard web filter license displays as

expired/unreachable
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
Using URL Filters in conjunction with FortiGuard Categories is not

working
Web filtering inspection is applied in the following order:

1. URL filters
2. FortiGuard category filtering
3. Advanced filters (ex. safe search or removing Active X components)
Because of this order, a URL can trigger two matches: first, for a URL filter with Action set to Allow, and the a second
for a blocked FortiGuard Category. This results in the website being blocked. To avoid this, set Action to Exempt to
bypass further web filter inspection of that URL.

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

Web filtering using quotas
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.
1. Enabling web filtering
Go to System > Feature Select and confirm that Web Filter is ON. If necessary, click Apply to make your changes.
2. Creating a web filter profile that uses quotas
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.
Under Category Usage Quota, select Create New.

Select both General Interest – Personal and General Interest – Business. For testing purposes, set the Quota to 5
Minutes.

The web filter now displays all the General Interest sub-categories and the applied quota.

3. Adding web filtering to a security policy
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
Browse to www.ebay.com, a website in the General Interest – Personal category.

Access to the website is allowed for 5 minutes, after which time a "web page blocked" message appears. The message
appears each time users affected by the security policy try to access General Interest sites until the quota is reset
(every 24 hours at midnight).
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.

WiFi network on a schedule
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.
1. Create the schedule
Go to Policy & Objects > Schedules. Create a recurring schedule for school hours (in the example, 8am-6pm,
Monday through Friday).

2. Create the SSID
Go to WiFi Controller > SSID and create the WiFi interface.

Set a Name and IP/Network Mask for the interface.
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.
3. Create the security policy
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.

WiFi Network troubleshooting
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.
Signal strength issues
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 issue
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.

Measuring signal strength in both directions
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.
Controller configured transmitting power – CLI:

config wireless-controller wtp-profile
config <radio>
show
(the following output is limited to power levels)
auto-power-level : enable
auto-power-high : 17
auto-power-low : 10
Actual FortiAP transmitting power – CLI:

iwconfig wlan00
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
Using FortiPlanner PRO with a site survey
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.

Sample depiction of a site survey using FortiPlanner
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.

There are two types of interference: coherent and non-coherent.

l Coherent interference: a result of another device using the same channel as your AP, or poor planning of a
wireless infrastructure (perhaps the other nearby APs are using the same channel or the signal strength is too high).
l Non-coherent interference: a result of other radio signals such as bluetooth, microwave, cordless phone, or (as in
medical environments) x-ray machines.
Most common and simple solution for frequency interference is to change your operation channel. Typically, the
channel can be set from 1 to 11 for the broadcast frequency, although you should always use channels 1, 6, and 11 on
the 2.4GHz band.
Another solution, if it’s appropriate for your location, is to use the 5GHz band instead.
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
Sometimes communication issues can be caused by low performance.
Testing the link
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.
Measuring file transfer speed
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.

Preventing IP fragmentation in CAPWAP
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.
Slowness in the DTLS response
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.
Client connection issues
1. If client is unable to connect to FortiAP:

l Make sure the client’s security and authentication settings match with FortiAP and check the certificates as
well.
l Try upgrading the Wi-Fi adapter driver and FortiGate/FortiAP firmware.
If other clients can connect, it could be interoperability; run debug commands and sniffer packets.
l Look for rogue suppression by sniffing the wireless traffic and looking for the disconnect in the output (using
the AP or wireless packet sniffer).
l Try changing the IEEE protocol from 802.11n to 802.11bg or 802.11a only.

2. If the client drops and reconnects:

l The client might be de-authenticating periodically. Check the sleep mode on the client.
l The issue could be related to power-saver settings. The client may need to udpate drivers.
l The issue could also be caused by flapping between APs. Check the roaming sensitivity settings on the client
or the preferred wireless network settings on the client—if another WiFi network is available, the client may
connect to it if it is a preferred network. Also, check the DHCP configuration as it may be an IP conflict.
3. If the client drops and never connects:
l It could have roamed to another SSID, so check the standby and sleep modes.
l You may need to bring the interface up and down.
4. If the client connects, but no IP address is acquired by the client:
l Check the DHCP configuration and the network.
l It could be a broadcast issue, so check the WEP encryption key and set a static IP address and VLANs.
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
Example of a successful client connection:
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.
FortiAP connection issues
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.
Throughout debugging it is recommended to:

l Enable Telnet login to the FortiAP device so that you can log in and issue local debugging commands:
config wireless-controller wtp
edit "<FortiAP_serial_number>"
set override-allowaccess {disable|enable}
set allowaccess {telnet|http}
end
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
Example of a successful AP and controller association:
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 <fsm> old CWAS_RUN(12) ev CWAE_CFG_UPDATE_RESP_RECV(37) 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)
56712.253 < . > AC (2) -> WTP (0-192.168.35.1:5246) State: CWAS_RUN (12) accept 3 live 3 dbg
00000000 pkts 12493 0

00000000 pkts 12493 0
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).
Common sources of wireless issues

Best practices for Layer 1
Common physical layer issues include:

l Weak received signal,
l WiFi capability: 802.11b, 1×1, 2×2,
l Co-channel WiFi interference,
l Side band WiFi interference,
l Non 802.11 noise (microwave ovens…).
To avoid physical layer issues:
l Determine RST (Receiver Sensitivity Threshold) for your device, or use -70dBm as a rule of thumb.
l Match AP TX output power to the client TX output power. Note: iPhone TX power is only 10dBm.
l Use DFS (Dynamic Frequency Selection) for high performance data 20/40 MHz.
l Use 5GHz UNII-1 & 3 (Non-DFS) bands with static channel assignment for latency-sensitive applications.
l Do not use 40MHz channels in 2.4 GHz band (channel bonding is not allowed in FortiOS).
Best practices for Layer 2
Common data link (MAC) layer issues include:

l Too many clients on a single channel (CSMA/CA) backoff,
l Too many high-priority traffic clients (WMM),
l Incorrect password or encryption settings,
l Too many beacons (in dense installs).
To avoid data link layer issues:
l Only use CCMP/AES (WPA2) encryption (not TKIP).
l In high density deployments, turn off SSID broadcast or turn down SSID rates. Review and possibly reduce the
beacon interval.
l Determine the best cell size for applications:
l For few users and low bandwidth latency sensitive applications, use high transmit power to create larger cells.
l For high performance/high capacity installations, use lower transmit power to create smaller cells (set
FortiPlanner at 10dBm TX power), but bear in mind that this will require more roaming.
Cells and co-channel interference
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.

Reducing co-channel interference
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.
Best practices for Layer 3 and above
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:

l Identify business-critical applications.

l Use Application Control, Web Filtering, Traffic Shaping, and QoS to prioritize applications.
l Identify unwanted traffic, high-bandwidth web-related traffic, and use Security Profiles.
l Use the traffic shaper on a policy to rate-limit this traffic
These configurations are performed directly on the FortiGate.
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
CAPWAP packet sniffer
The first recommended technique consists of sniffing the CAPWAP traffic.

l Enable plain control on the controller and on the FortiAP to capture clear control traffic on UDP port 5246.
l On the controller:
diagnose wireless-controller wlac plain-ctl <FortiAP_serial_number> 1
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:

diagnose wireless-controller wlac sniff <interface_name> <FortiAP_serial_number> 2
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.
Example CAPWAP packet capture
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.
Wireless traffic packet sniffer
The second recommended technique consists of sniffing the wireless traffic directly ‘on the air’ using your FortiAP.

Wireless traffic packet capture
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
l The capture file is stored under the temp directory as wl_sniff.pcap

/tmp/wl_sniff.cap
l Remember that the capture file is only stored temporarily. If you want to save it, upload it to a TFTP server
before rebooting or changing the radio settings.
l The command cp wl_sniff.cap newname.pcap allows you to rename the file.
l Rather than TFTP the file, you can also log in to the AP and retrive the file via the web interface. Move the file
using the command: mv name /usr/www
You can verify the file was moved using the command cd/usr/www and then browsing to: <fortiAP_
IP>/filename
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:

config wireless-controller wtp-profile

edit <profile_name>
config <radio>
set ap-sniffer-mgmt-beacon disable
set ap-sniffer-mgmt-probe disable
set ap-sniffer-mgmt-other disable
set ap-sniffer-ctl disable
set ap-sniffer-data disable
end
next
end
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.
Example AP 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.

Useful debugging commands
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)
diagnose wireless-controller wlwtp help

(this command lists the options available that pertain to the AP)
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

WiFi RADIUS authentication with FortiAuthenticator
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.
1. Create the user accounts and user group on the

FortiAuthenticator
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.
2. Register the FortiGate as a RADIUS client on the

FortiAuthenticator
Go to Authentication > RADIUS Service > Clients and create a client account.
Enable all of the EAP types.

3. Configure FortiGate to use the RADIUS server
Go to User & Device > RADIUS Servers and add the FortiAuthenticator as a RADIUS server.

4. Create the SSID and set up authentication
Go to WiFi Controller > SSID and define your wireless network.
Set up DHCP for your clients.

Configure WPA2 Enterprise security that uses the RADIUS server.
5. Connect and authorize the FortiAP
Go to Network > Interfaces and configure a dedicated interface for the FortiAP.

Connect the FortiAP unit. Go to WiFi Controller > Managed FortiAPs.
When the FortiAP is listed, select and authorize it.
Go to WiFi Controller > FortiAP Profiles and edit the profile.

This example used a FortiAP-221C, so the FAP221C-default profile applies.
For each radio:
l Enable Radio Resource Provision.
l Select your SSID.

6. Create the security policy
Go to Policy & Objects > IPv4 Policy and add a policy that allows WiFi users to access the Internet.

Results
Connect to the example-staff network and browse Internet sites.

Go to Monitor > Client Monitor to see that clients connect and authenticate.

WiFi using FortiAuthenticator RADIUS with Certificates
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.
1. Creating a local CA on FortiAuthenticator
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.

2. Creating a local service certificate on FortiAuthenticator
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.
3. Configuring RADIUS EAP on FortiAuthenticator
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.

4. Configuring RADIUS client on FortiAuthenticator
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.

5. Configuring local user on FortiAuthenticator
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.

6. Configuring local user certificate on FortiAuthenticator
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.
7. Creating RADIUS server on FortiGate
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”.

8. Creating WiFi SSID on FortiGate
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.

Set WPA2-Enterprise with RADIUS Server authentication, and choose FortiAuth.

9. Exporting user certificate from FortiAuthenticator
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.
9. Importing user certificate into Windows 7
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.

10. Configuring Windows 7 wireless profile to use certificate
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.

11. Results on FortiAuthenticator
When the user attempts to authenticate to WiFi using the certificate, they will have a specific log entry in the
FortiAuthenticator.

12. Results on FortiGate
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

WiFi with WSSO using FortiAuthenticator RADIUS and
Attributes
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.
1. Registering the FortiGate as a RADIUS client on the

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

2. Creating users on the FortiAuthenticator
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.

3. Creating user groups on the FortiAuthenticator
Go to Authentication > User Management > User Groups and create two user groups: teachers and students.
Add the users to their respective groups.

Once created, edit both user groups—RADIUS Attributes becomes available.

Select Add Attribute.

Add the Fortinet-Group-Name RADIUS attribute to each group, which specifies the user group name to be sent to the
FortiGate.
4. Configuring FortiGate to use FortiAuthenticator as the RADIUS

server
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.
5. Configuring user groups on the FortiGate
Go to User & Device > User Groups and create two groups named the same as the ones created on the
FortiAuthenticator.
Do not add any members to either group.

6. Creating security policies
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.
7. Configuring the SSID to RADIUS authentication
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
Connect to the WiFi network as a student.
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.

WiFi with WSSO using Windows NPS and Attributes
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
1. Registering the FortiGate as a RADIUS client on NPS
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).

2. Creating a Connection Request Policy
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.

3. Creating a Network Policy
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.

4. Configuring FortiGate to use the RADIUS server
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”.
5. Configuring a user group on the FortiGate
Go to User & Device > User Groups. Create a group that matches the WiFi RADIUS attribute. Do not add any
members or remote servers.
6. Creating an SSID with RADIUS authentication

Set WPA2-Enterprise with RADIUS Server authentication, and choose DC-RADIUS.

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.

WiFi with WSSO using Windows NPS and FortiGate
Groups
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.
1. Registering the FortiGate as a RADIUS client on NPS
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).

2. Creating a Connection Request Policy
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.

3. Creating a Network Policy
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.

4. Configuring FortiGate to use the RADIUS server
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”.

5. Configuring a user group on the FortiGate
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.
6. Creating an SSID with RADIUS authentication

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.

Copyright© 2019 Fortinet, Inc. All rights reserved. Fortinet®, FortiGate®, FortiCare® and FortiGuard®, and certain other marks are registered trademarks of Fortinet, Inc., in
the U.S. and other jurisdictions, and other Fortinet names herein may also be registered and/or common law trademarks of Fortinet. All other product or company names may be
trademarks of their respective owners. Performance and other metrics contained herein were attained in internal lab tests under ideal conditions, and actual performance and
other results may vary. Network variables, different network environments and other conditions may affect performance results. Nothing herein represents any binding
commitment by Fortinet, and Fortinet disclaims all warranties, whether express or implied, except to the extent Fortinet enters a binding written contract, signed by Fortinet’s
General Counsel, with a purchaser that expressly warrants that the identified product will perform according to certain expressly-identified performance metrics and, in such
event, only the specific performance metrics expressly identified in such binding written contract shall be binding on Fortinet. For absolute clarity, any such warranty will be
limited to performance in the same ideal conditions as in Fortinet’s internal lab tests. In no event does Fortinet make any commitment related to future deliverables, features or
development, and circumstances may change such that any forward-looking statements herein are not accurate. Fortinet disclaims in full any covenants, representations, and
guarantees pursuant hereto, whether express or implied. Fortinet reserves the right to change, modify, transfer, or otherwise revise this publication without notice, and the most
current version of the publication shall be applicable.

FortiOS 5.4 Cookbook PDF

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

FortiOS 5.4 Cookbook PDF

Încărcat de

Drepturi de autor:

Formate disponibile

FortiOS - Cookbook

FORTINET VIDEO GUIDE

CUSTOMER SERVICE & SUPPORT

FORTINET TRAINING & CERTIFICATION PROGRAM

END USER LICENSE AGREEMENT

October 08, 2019

FortiOS Cookbook Fortinet Technologies Inc.

3. Adding the signature to the default Application Control profile 67

FortiOS Cookbook Fortinet Technologies Inc.

Configuring Hair-pinning on a FortiGate 134

FortiOS Cookbook Fortinet Technologies Inc.

7. Configuring FortiAP-2 for mesh operation 184

FortiOS Cookbook Fortinet Technologies Inc.

Logging to a FortiAnalyzer unit is not working as expected. 206

FortiOS Cookbook Fortinet Technologies Inc.

3. Adding a default route 259

FortiOS Cookbook Fortinet Technologies Inc.

IPsec VPN troubleshooting 332

FortiOS Cookbook Fortinet Technologies Inc.

Logging FortiGate traffic and using FortiView 392

FortiOS Cookbook Fortinet Technologies Inc.

ID 264 – IPV4_AF_NAT 431

FortiOS Cookbook Fortinet Technologies Inc.

3. Configuring Static Domain Filter in DNS Filter Profile 477

FortiOS Cookbook Fortinet Technologies Inc.

FortiOS Cookbook Fortinet Technologies Inc.

5. Creating an SSL VPN portal 572

FortiOS Cookbook Fortinet Technologies Inc.

Egress queueing 621

FortiOS Cookbook Fortinet Technologies Inc.

3. Adding web filtering to a security policy 669

FortiOS Cookbook Fortinet Technologies Inc.

9. Exporting user certificate from FortiAuthenticator 709

FortiOS Cookbook Fortinet Technologies Inc.

Date Change Description

2019-10-08 Initial release.

FortiOS Cookbook Fortinet Technologies Inc.

FortiOS Cookbook Fortinet Technologies Inc.

802.1X with VLAN Switch interfaces on a FortiGate

FortiOS Cookbook Fortinet Technologies Inc.

2. Configuring RADIUS authentication

FortiOS Cookbook Fortinet Technologies Inc.

FortiOS Cookbook Fortinet Technologies Inc.

Go to WiFi & Switch Controller > VLANs

Test the RADIUS configuration from the the FortiGate CLI:

FortiOS Cookbook Fortinet Technologies Inc.

3. Configure the supplicant and test

Check FortiAuthenticator's log messages, look for 802.1x authentication successful.

FortiOS Cookbook Fortinet Technologies Inc.

FortiOS Cookbook Fortinet Technologies Inc.

FortiOS Cookbook Fortinet Technologies Inc.

1. Enabling endpoint control on the FortiGate

FortiOS Cookbook Fortinet Technologies Inc.

2. Enforcing FortiClient registration on the internal interface

FortiOS Cookbook Fortinet Technologies Inc.

3. Configuring the FortiClient Profile

FortiOS Cookbook Fortinet Technologies Inc.

FortiOS Cookbook Fortinet Technologies Inc.

4. Setting up a compliant FortiClient device

FortiOS Cookbook Fortinet Technologies Inc.

FortiOS Cookbook Fortinet Technologies Inc.

FortiOS Cookbook Fortinet Technologies Inc.

FortiOS Cookbook Fortinet Technologies Inc.