Fortios Handbook 40 Mr2

FortiOS™ Handbook v2
for FortiOS 4.0 MR2

FortiOS™ Handbook
v2
26 October 2010
01-420-99686-20101026
for FortiOS 4.0 MR2
© Copyright 2010 Fortinet, Inc. All rights reserved. No part of this publication including text, examples,
diagrams or illustrations may be reproduced, transmitted, or translated in any form or by any means,
electronic, mechanical, manual, optical or otherwise, for any purpose, without prior written permission of
Fortinet, Inc.
Trademarks
Dynamic Threat Prevention System (DTPS), APSecure, FortiASIC, FortiBIOS, FortiBridge, FortiClient,
FortiGate®, FortiGate Unified Threat Management System, FortiGuard®, FortiGuard-Antispam,
FortiGuard-Antivirus, FortiGuard-Intrusion, FortiGuard-Web, FortiLog, FortiAnalyzer, FortiManager,
Fortinet®, FortiOS, FortiPartner, FortiProtect, FortiReporter, FortiResponse, FortiShield, FortiVoIP, and
FortiWiFi are trademarks of Fortinet, Inc. in the United States and/or other countries. The names of actual
companies and products mentioned herein may be the trademarks of their respective owners.
Contents Quick Look
Chapter 1 What’s New 99

Firmware upgrade practices 103
Web-based manager 109
FortiOS software enhancements 115
CLI 125
System 129
High availability 135
Firewall 141
User 145
UTM 147
VPN 153
Endpoint 155
WAN Opt. & Cache 159
FortiOS Carrier 161
Logging and reporting 167
Chapter 2 FortiGate Fundamentals 175

The Purpose of a Firewall 177
Life of a Packet 189
Firewall components 201
Firewall Policies 231
Troubleshooting 251
Configuration Examples 261
Concept Example: Small Office Network Protection 263
Concept Example: Library Network Protection 299
01-420-99686-20101026 3
http://docs.fortinet.com/ • Feedback
Contents Quick Look
Chapter 3 System Administration 331

Basic setup 333
Centralized management 359
Using the CLI 365
Tightening security 385
Best Practices 391
Monitoring 397
Multicast forwarding 429
IPv6 459
Virtual LANs 481
PPTP and L2TP 513
Session helpers 527
Advanced firewall concepts 537
Advanced concepts 551
Chapter 4 Logging and Reporting 569

Logging overview 571
The SQL log database 579
Log devices 583
Logging FortiGate activity 595
Log message usage 609
Reports 613
Chapter 5 Troubleshooting 629

Troubleshooting process 631
Troubleshooting tools 635
Technical Support Organization Overview 663
Troubleshooting connectivity 677
Troubleshooting get commands 687
Troubleshooting bootup issues 731
for FortiOS 4.0 MR2

4 01-420-99686-20101026
Contents Quick Look
Chapter 6 UTM Guide 735

UTM overview 737
Network defense 749
AntiVirus 761
Email filter 781
Intrusion protection 797
Web filter 827
FortiGuard Web Filter 843
Data leak prevention 857
Application control 871
DoS policy 881
Sniffer policy 887
Chapter 7 User Authentication 895

Introduction to authentication 897
Authentication servers 905
Users and user groups 915
Configuring authenticated access 923
FSAE for integration with Windows AD or Novell 933
Certificate-based authentication 961
Monitoring authenticated users 973
Example 975
01-420-99686-20101026 5
Contents Quick Look
Chapter 8 IPsec VPNs 983

IPsec VPN concepts 985
FortiGate IPsec VPN Overview 993
Gateway-to-gateway configurations 997
Hub-and-spoke configurations 1011
Dynamic DNS configurations 1025
FortiClient dialup-client configurations 1031
FortiGate dialup-client configurations 1047
Supporting IKE Mode config clients 1055
Internet-browsing configuration 1059
Redundant VPN configurations 1063
Transparent mode VPNs 1085
Manual-key configurations 1091
IPv6 IPsec VPNs 1093
L2TP and IPsec (Microsoft VPN) configurations 1105
GRE over IPsec (Cisco VPN) configurations 1117
Protecting OSPF with IPsec 1127
Auto Key phase 1 parameters 1135
Phase 2 parameters 1151
Defining firewall policies 1157
Hardware offloading and acceleration 1163
Monitoring and troubleshooting VPNs 1169
Chapter 9 SSL VPNs 1175

Introduction to SSL VPN 1177
Setting up the FortiGate unit 1185
Working with the web portal 1227
Using the SSL VPN tunnel client 1239
Examples 1249
Chapter 10 Advanced Routing 1265

Advanced Static routing 1267
Dynamic Routing Overview 1293
Routing Information Protocol (RIP) 1309
Border Gateway Protocol (BGP) 1347
Open Shortest Path First (OSPF) 1385
for FortiOS 4.0 MR2

6 01-420-99686-20101026
Contents Quick Look
Chapter 11 Virtual Domains 1423

Virtual Domains 1425
Virtual Domains in NAT/Route mode 1453
Virtual Domains in Transparent mode 1471
Inter-VDOM routing 1491
Troubleshooting Virtual Domains 1527
Chapter 12 High Availability 1533

Solving the High Availability problem 1537
An introduction to the FortiGate Clustering Protocol (FGCP) 1541
Configuring and connecting HA clusters 1567
Configuring and connecting virtual clusters 1629
Configuring and operating FortiGate full mesh HA 1651
Operating a cluster 1665
HA and failover protection 1705
HA and load balancing 1753
HA with third-party products 1767
VRRP 1771
TCP session synchronization 1777
Chapter 13 Endpoint 1783

Network Access Control and monitoring 1785
Network Vulnerability Scan 1801
Chapter 14 Traffic Shaping 1809

The purpose of traffic shaping 1811
Traffic shaping methods 1821
Examples 1833
Troubleshooting 1841
01-420-99686-20101026 7
Contents Quick Look
Chapter 15 FortiOS Carrier 1845

Overview of FortiOS Carrier features 1849
Dynamic profiles and profile groups 1871
MMS Carrier End Point features 1889
MMS UTM features 1897
Message flood protection 1917
Duplicate message protection 1931
MMS Replacement messages 1939
Configuring GTP on FortiOS Carrier 1947
GTP message type filtering 1957
GTP identity filtering 1963
Chapter 16 Deploying Wireless Networks 1977

Introduction to wireless networking 1979
Configuring a wireless LAN 1987
Access point deployment 2001
Wireless network monitoring 2007
Configuring wireless network clients 2011
Wireless network example 2021
Reference 2031
Chapter 17 VoIP Solutions: SIP 2035

FortiGate VoIP solutions: SIP 2037
Chapter 18 WAN Optimization, Web Cache, Explicit Proxy, and WCCP 2115
WAN optimization, web cache, and web proxy concepts 2117
WAN optimization and Web cache storage 2133
WAN optimization peers and authentication groups 2135
Configuring WAN optimization rules 2141
WAN optimization configuration examples 2151
Web caching 2171
Advanced configuration example 2189
SSL offloading for WAN optimization and web caching 2211
FortiClient WAN optimization 2219
The FortiGate explicit web proxy 2221
FortiGate WCCP 2239
WAN optimization, web cache and WCCP get and diagnose commands 2245
for FortiOS 4.0 MR2

8 01-420-99686-20101026
Contents Quick Look
Chapter 19 Load Balancing 2251

Configuring load balancing 2253
Load balancing configuration examples 2275
Chapter 20 Hardware 2291

FortiGate installation 2293
FortiGate hardware accelerated processing 2305
Configuring RAID 2327
FortiBridge installation and operation 2333
Chapter 21 Certifications and Compliances 2365

FIPS-CC operation of FortiGate units 2367
Configuring FortiGate units for PCI DSS compliance 2389
Index ................................................................................................... 2403
01-420-99686-20101026 9
Contents Quick Look
for FortiOS 4.0 MR2

10 01-420-99686-20101026
Detailed Contents
How this Handbook is organized . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
Document conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
IP addresses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
Example Network configuration . . . . . . . . . . . . . . . . . . . . . . . . . . 92
Cautions, Notes and Tips . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
Typographical conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
CLI command syntax conventions . . . . . . . . . . . . . . . . . . . . . . . . . 94
Entering FortiOS configuration data . . . . . . . . . . . . . . . . . . . . . . . . . . 96
Entering text strings (names). . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
Entering numeric values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
Selecting options from a list . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
Enabling or disabling options. . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
Registering your Fortinet product. . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
Fortinet products End User License Agreement . . . . . . . . . . . . . . . . . . . . 97
Training . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
Fortinet Tools and Documentation CD . . . . . . . . . . . . . . . . . . . . . . . 98
Fortinet Knowledge Base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
Comments on Fortinet technical documentation . . . . . . . . . . . . . . . . . 98
Customer service and technical support . . . . . . . . . . . . . . . . . . . . . . . . 98
Chapter 1 What’s New 99

Top ten features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
Upgrading issues for FortiOS 4.0 MR2 . . . . . . . . . . . . . . . . . . . . . . . . . 99
Endpoint (previously Endpoint NAC) . . . . . . . . . . . . . . . . . . . . . . . . 100
Topology viewer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
Customizing the GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
Basic traffic reports (system memory only). . . . . . . . . . . . . . . . . . . . . 100
PPTP VPNs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
VoIP settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
NNTP DLP archive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
Email filter banned word setting . . . . . . . . . . . . . . . . . . . . . . . . . . 100
HTTPS invalid certificate setting . . . . . . . . . . . . . . . . . . . . . . . . . . 101
HTTPS AV scanning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
Upgrading issues for FortiOS Carrier. . . . . . . . . . . . . . . . . . . . . . . . . . 101
01-420-99686-20101026 11
Detailed Contents
Firmware upgrade practices 103

Upgrading from earlier firmware to FortiOS . . . . . . . . . . . . . . . . . . . . . . 103
Upgrading practices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
Example: Upgrading from FortiOS 3.0 MR7 to FortiOS . . . . . . . . . . . . . . . . 104
Verifying and downloading the required firmware images . . . . . . . . . . . . . 104
Backing up the configuration file . . . . . . . . . . . . . . . . . . . . . . . . . . 104
Installing FortiOS 4.0.4 build-0113 . . . . . . . . . . . . . . . . . . . . . . . . . 105
Installing FortiOS using the test procedure. . . . . . . . . . . . . . . . . . . . . 106
Web-based manager 109

The redesigned web-based manager . . . . . . . . . . . . . . . . . . . . . . . . . 109
Navigating in the web-based manager . . . . . . . . . . . . . . . . . . . . . . . 109
Modifying settings within a feature . . . . . . . . . . . . . . . . . . . . . . . . . 110
Switching VDOMs in the web-based manager . . . . . . . . . . . . . . . . . . . 110
Adding dashboards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
Widgets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
Per-IP Bandwidth Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
P2P Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
IM Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
VoIP Usage. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
Storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
Alert Message Console enhancement . . . . . . . . . . . . . . . . . . . . . . . 113
FSAE enhancements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
Dynamic proxy allocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
FortiOS software enhancements 115

Disk management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
Disk I/O scalability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
Storage Health Monitor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
ELBC blade configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
Support for AMC modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
Storing configuration history and templates on local hard disk . . . . . . . . . . . . . 117
FortiOS 4.0 MR2

12 01-420-99686-20101026
Detailed Contents
SIP features available on all FortiGate models . . . . . . . . . . . . . . . . . . . . . 118

SIP header conformance check . . . . . . . . . . . . . . . . . . . . . . . . . . 118
SIP message per method rate limitation . . . . . . . . . . . . . . . . . . . . . . 118
SIP NAT IP address conservation . . . . . . . . . . . . . . . . . . . . . . . . . 119
Support for multiple RTP endpoint . . . . . . . . . . . . . . . . . . . . . . . . . 119
SIP HA failover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
Deep SIP message inspection . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
Stateful SCTP firewall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
SIP Hosted NAT Traversal (HNT) . . . . . . . . . . . . . . . . . . . . . . . . . 122
Logging and statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
CLI 125
grep . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
IS-IS routing support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
IS-IS CLI commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
Trouble-shooting command updates . . . . . . . . . . . . . . . . . . . . . . . . . . 127
System 129
Concurrent username restriction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
MD5 hash for log transfers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
Limiting the number of concurrent explicit proxy users . . . . . . . . . . . . . . . . . 129
sFlow client support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
WCCP client mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
WCCP router mode configuration . . . . . . . . . . . . . . . . . . . . . . . . . 131
WCCP client mode configuration. . . . . . . . . . . . . . . . . . . . . . . . . . 132
Client certificate handling for SSL inspection. . . . . . . . . . . . . . . . . . . . . . 133
Controlling the source interface IP address for self-originating traffic . . . . . . . . . 133
Web Proxy replacement messages . . . . . . . . . . . . . . . . . . . . . . . . . . 133
Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
High availability 135

Configurable Ethernet types for HA heartbeat packets. . . . . . . . . . . . . . . . . 135
HA subsecond failover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
HA reserved management interface . . . . . . . . . . . . . . . . . . . . . . . . . . 136
Configuring the reserved management interface and SNMP
remote management of individual cluster units . . . . . . . . . . . . . . . . . . 137
01-420-99686-20101026 13
Detailed Contents
Firewall 141
Protection profile re-organization and enhancement . . . . . . . . . . . . . . . . . . 141
VoIP profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
Explicit Proxy improvements (including Citrix/TS support) . . . . . . . . . . . . . . . 142
Central NAT Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
User 145
LDAP/RADIUS password renewal . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
BGP support for four-byte AS Path . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
IM users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
UTM 147
FortiGuard Web Filtering quotas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
Viewing FortiGuard quota usage . . . . . . . . . . . . . . . . . . . . . . . . . . 148
Skype control improvements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
Flow-based antivirus database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
Extreme antivirus database. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
SSL proxy exemption by FortiGuard Web Filter category . . . . . . . . . . . . . . . 149
Application control enhancements . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
Monitoring application control traffic . . . . . . . . . . . . . . . . . . . . . . . . 150
Applying traffic shaping settings to an application control list . . . . . . . . . . . 151
VPN 153
FortiMobile SSL-VPN app . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
L2TP and IPSec support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
Endpoint 155
Endpoint menu enhancements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
Endpoint application enforcement . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
Network Vulnerability Scan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
Configuring assets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
Scheduling a scan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
FortiOS 4.0 MR2

14 01-420-99686-20101026
Detailed Contents
WAN Opt. & Cache 159

Web Cache exempt. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
FortiOS Carrier 161

Opera Mini Browser support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
MMS filtering enhancements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
Carrier menu in UTM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
Profile Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
Configuring a profile group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
Logging and reporting 167

Archiving support for local hard drives . . . . . . . . . . . . . . . . . . . . . . . . . 167
Log viewing enhancement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
Report enhancements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
Configuring a theme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
Importing images . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
Configuring a chart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
Configuring a report layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
Viewing generated FortiOS reports . . . . . . . . . . . . . . . . . . . . . . . . 172
Chapter 2 FortiGate Fundamentals 175
The Purpose of a Firewall 177

Firewall features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
Antivirus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
Web Filtering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
Antispam/Email Filter. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
Intrusion Protection. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
Traffic Shaping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
NAT vs. Transparent Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
NAT mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
Transparent mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
Operating mode differences . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
Life of a Packet 189

Stateful inspection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
Flow inspection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
01-420-99686-20101026 15
Detailed Contents
Proxy inspection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191

FortiOS functions and security layers . . . . . . . . . . . . . . . . . . . . . . . . . 191
Packet flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192
Packet inspection (Ingress) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192
Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
DoS sensor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
IP integrity header checking . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
IPsec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194
Destination NAT (DNAT) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194
Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194
Policy lookup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194
Session tracking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194
User authentication. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
Management traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
SSL VPN traffic. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
Session helpers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
Flow-based inspection engine . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
Proxy-based inspection engine. . . . . . . . . . . . . . . . . . . . . . . . . . . 195
IPsec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196
Source NAT (SNAT) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196
Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196
Egress . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196
Example 1: client/server connection . . . . . . . . . . . . . . . . . . . . . . . . . . 196
Example 2: Routing table update . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
Example 3: Dialup IPsec with application control. . . . . . . . . . . . . . . . . . . . 198
Firewall components 201

Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201
Physical . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201
Administrative access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203
Wireless . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204
Aggregate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204
Virtual domains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205
Virtual LANs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
Zones. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208
FortiOS 4.0 MR2

16 01-420-99686-20101026
Detailed Contents
Addressing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209
Wildcard masks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211
Fully Qualified Domain Name addresses . . . . . . . . . . . . . . . . . . . . . 211
Virtual IPs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212
Address groups. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217
DHCP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
IP pools. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219
IP Pools for firewall policies that use fixed ports . . . . . . . . . . . . . . . . . . 220
Source IP address and IP pool address matching . . . . . . . . . . . . . . . . . 221
IPv6. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222
Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223
Originating traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223
Receiving traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224
Closing specific ports to traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . 225
Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226
Custom service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226
Schedules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227
Schedule groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228
UTM profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229
Profiles and sensors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229
Firewall Policies 231

Policy order . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232
Denial of Service policies. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233
Rearranging policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233
Firewall policy 0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234
Firewall policy list details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234
Creating basic policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235
Using an interface of “any” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235
Basic accept policy example . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236
Basic deny policy example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236
Basic VPN policy example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237
DoS Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238
Basic DoS policy example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238
Sniffer Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239
Basic one-armed sniffer policy example . . . . . . . . . . . . . . . . . . . . . . 239
Identity-based Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240
Identity-based policy positioning . . . . . . . . . . . . . . . . . . . . . . . . . . 242
Identity-based sub-policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242
ICMP packet processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243
01-420-99686-20101026 17
Detailed Contents
Firewall policy examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244

Blocking an IP address . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244
Scheduled access policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245
Troubleshooting 251
Basic policy checking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251
Verifying traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251
Using log messages to view violation traffic . . . . . . . . . . . . . . . . . . . . . . 252
Traffic trace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253
Session table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253
Finding object dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255
Flow trace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255
Flow trace output example - HTTP . . . . . . . . . . . . . . . . . . . . . . . . . 256
Packet sniffer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258
Simple trace example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258
Simple trace example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258
Trace with filters example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259
Configuration Examples 261

Exempted URLs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261
Create a local category. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261
Add URLs to the category . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261
Enable the category in web filtering . . . . . . . . . . . . . . . . . . . . . . . . 262
Test it . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262
Concept Example: Small Office Network Protection 263

Example small office network. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263
Network management and protection requirements . . . . . . . . . . . . . . . . 264
Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264
Features used in this example . . . . . . . . . . . . . . . . . . . . . . . . . . . 265
First steps. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266
Configuring FortiGate network interfaces . . . . . . . . . . . . . . . . . . . . . 266
Adding the default route . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267
Removing the default firewall policy . . . . . . . . . . . . . . . . . . . . . . . . 268
Configuring DNS forwarding . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268
Setting the time and date. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269
Registering the FortiGate unit . . . . . . . . . . . . . . . . . . . . . . . . . . . 269
Scheduling automatic antivirus and attack definition updates . . . . . . . . . . . 270
Configuring administrative access and passwords. . . . . . . . . . . . . . . . . 270
FortiOS 4.0 MR2

18 01-420-99686-20101026
Detailed Contents
Configuring settings for Finance and Engineering departments . . . . . . . . . . . . 272

Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
Adding the Finance and Engineering department addresses . . . . . . . . . . . 272
Configuring web category block settings . . . . . . . . . . . . . . . . . . . . . . 273
Configuring FortiGuard spam filter settings . . . . . . . . . . . . . . . . . . . . 273
Configuring antivirus grayware settings . . . . . . . . . . . . . . . . . . . . . . 274
Configuring a corporate set of UTM profiles . . . . . . . . . . . . . . . . . . . . 274
Configuring firewall policies for Finance and Engineering . . . . . . . . . . . . . 276
Configuring settings for the Help Desk department . . . . . . . . . . . . . . . . . . 277
Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278
Adding the Help Desk department address . . . . . . . . . . . . . . . . . . . . 278
Creating and Configuring URL filters . . . . . . . . . . . . . . . . . . . . . . . . 278
Creating a recurring schedule . . . . . . . . . . . . . . . . . . . . . . . . . . . 282
Configuring firewall policies for help desk . . . . . . . . . . . . . . . . . . . . . 282
Configuring remote access VPN tunnels . . . . . . . . . . . . . . . . . . . . . . . . 284
Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284
Adding addresses for home-based workers . . . . . . . . . . . . . . . . . . . . 284
Configuring the FortiGate end of the IPSec VPN tunnels . . . . . . . . . . . . . 285
Configuring firewall policies for the VPN tunnels . . . . . . . . . . . . . . . . . . 287
Configuring the FortiClient end of the IPSec VPN tunnels . . . . . . . . . . . . . 289
Configuring the web server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289
Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289
Configuring the FortiGate unit with a virtual IP . . . . . . . . . . . . . . . . . . . 290
Adding the web server address . . . . . . . . . . . . . . . . . . . . . . . . . . 290
Configuring firewall policies for the web server . . . . . . . . . . . . . . . . . . 291
Configuring the email server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293
Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293
Configuring the FortiGate unit with a virtual IP . . . . . . . . . . . . . . . . . . . 293
Adding the email server address . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294
Configuring firewall policies for the email server . . . . . . . . . . . . . . . . . . 294
ISP web site and email hosting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297
The Example Corporation internal network configuration . . . . . . . . . . . . . . . 298
Other features and products for SOHO. . . . . . . . . . . . . . . . . . . . . . . . . 298
Concept Example: Library Network Protection 299

Current topology and security concerns . . . . . . . . . . . . . . . . . . . . . . . . 299
Library requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300
The library’s decision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300
Proposed topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301
Features used in this example . . . . . . . . . . . . . . . . . . . . . . . . . . . 303
Network addressing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303
01-420-99686-20101026 19
Detailed Contents
Configuring the main office . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304

Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305
High Availability (HA) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305
FortiGuard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307
IPsec VPN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 308
Configuring IPsec VPNs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 308
IP Pools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309
User Disclaimer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 310
Protection Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311
Staff access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314
Catalog terminals. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316
Public access terminals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316
Wireless access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 318
Mail and web servers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321
The FortiWiFi-80CM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324
Configuring branch offices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325
Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325
Staff access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326
Catalog terminals. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326
Wireless/public access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326
Mail and web servers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326
IPsec VPN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 327
Branch Firewall Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 327
Traffic shaping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 328
Priorities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 329
The future. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 329
Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 329
Decentralization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330
Staff WiFi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330
Further redundancy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330
Chapter 3 System Administration 331
Basic setup 333

Connecting to the FortiGate unit . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333
Connecting to the web-based manager . . . . . . . . . . . . . . . . . . . . . . 333
Connecting to the CLI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334
FortiExplorer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334
FortiOS 4.0 MR2

20 01-420-99686-20101026
Detailed Contents
Configuring NAT mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334

Configure the interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335
Configure a DNS server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 336
Add a default route and gateway . . . . . . . . . . . . . . . . . . . . . . . . . . 337
Add firewall policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 338
Configuring transparent mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 339
Switching to transparent mode . . . . . . . . . . . . . . . . . . . . . . . . . . . 339
Verifying the configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342
Additional configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342
Setting the time and date. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342
Configuring FortiGuard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343
Passwords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344
Password considerations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344
Password policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344
Forgotten password? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345
Administrators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345
Trusted hosts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346
Backing up the configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346
Download a configuration file using SCP. . . . . . . . . . . . . . . . . . . . . . 347
Restoring a configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 349
Firmware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 349
Downloading firmware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 350
Upgrading the firmware - web-based manager . . . . . . . . . . . . . . . . . . 350
Upgrading the firmware - CLI. . . . . . . . . . . . . . . . . . . . . . . . . . . . 351
Testing new firmware before installing . . . . . . . . . . . . . . . . . . . . . . . 356
Centralized management 359

Adding a FortiGate to FortiManager . . . . . . . . . . . . . . . . . . . . . . . . . . 359
FortiGate configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 359
FortiManager configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 360
Configuration through FortiManager . . . . . . . . . . . . . . . . . . . . . . . . . . 360
Configuration and installation status . . . . . . . . . . . . . . . . . . . . . . . . 361
Global objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 361
Firmware updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 361
FortiGuard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362
Backup and restore configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . 362
Administrative domains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362
01-420-99686-20101026 21
Detailed Contents
Using the CLI 365

Connecting to the CLI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365
Connecting to the CLI using a local console . . . . . . . . . . . . . . . . . . . . 365
Enabling access to the CLI through the network (SSH or Telnet) . . . . . . . . . 366
Connecting to the CLI using SSH . . . . . . . . . . . . . . . . . . . . . . . . . 367
Connecting to the CLI using Telnet . . . . . . . . . . . . . . . . . . . . . . . . 368
Command syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 369
Sub-commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 371
Permissions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374
Tips . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 377
Help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 377
Shortcuts and key commands . . . . . . . . . . . . . . . . . . . . . . . . . . . 377
Command abbreviation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 377
Environment variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 378
Special characters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 378
Using grep to filter get and show command output . . . . . . . . . . . . . . . . 379
Language support and regular expressions . . . . . . . . . . . . . . . . . . . . 379
Screen paging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 382
Baud rate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 382
Editing the configuration file on an external host . . . . . . . . . . . . . . . . . . 382
Using Perl regular expressions. . . . . . . . . . . . . . . . . . . . . . . . . . . 383
Tightening security 385

Administrators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 385
Idle time-out . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 385
Administrator lockout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 385
Change the admin username . . . . . . . . . . . . . . . . . . . . . . . . . . . 386
Disable admin services. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 386
Segregated administrative roles . . . . . . . . . . . . . . . . . . . . . . . . . . 386
Administrative ports. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 386
Interface settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 387
Rejecting PING requests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 388
Opening TCP 113 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 388
Obfuscate HTTP headers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 389
FortiOS 4.0 MR2

22 01-420-99686-20101026
Detailed Contents
Best Practices 391

Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 391
Environmental specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . 391
Grounding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 392
Rack mount instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 392
Shutting down . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393
Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393
Firewall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393
Intrusion protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394
Antivirus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394
Web filtering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394
Antispam . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394
Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395
Monitoring 397
Dashboard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 397
Widgets. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 397
sFlow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 398
Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 398
Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 399
FortiGate memory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 399
FortiGate hard disk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 399
Syslog server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 400
FortiGuard Analysis and Management service. . . . . . . . . . . . . . . . . . . 400
FortiAnalyzer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 400
Alert email . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 400
SNMP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 401
SNMP agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 402
SNMP community . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403
Enabling on the interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404
Fortinet MIBs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404
SNMP get command syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405
Fortinet and FortiGate traps . . . . . . . . . . . . . . . . . . . . . . . . . . . . 406
Fortinet and FortiGate MIB fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . 409
01-420-99686-20101026 23
Detailed Contents
Multicast forwarding 429

Multicast IP addresses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 429
Multicast forwarding and FortiGate units . . . . . . . . . . . . . . . . . . . . . . . . 430
Multicast forwarding and RIPv2 . . . . . . . . . . . . . . . . . . . . . . . . . . 430
Configuring FortiGate multicast forwarding. . . . . . . . . . . . . . . . . . . . . . . 431
Adding multicast firewall policies . . . . . . . . . . . . . . . . . . . . . . . . . . 432
Enabling multicast forwarding . . . . . . . . . . . . . . . . . . . . . . . . . . . 432
Multicast routing examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434
Example FortiGate PIM-SM configuration using a static RP . . . . . . . . . . . . 435
FortiGate PIM-SM debugging examples . . . . . . . . . . . . . . . . . . . . . . 439
Example multicast destination NAT (DNAT) configuration . . . . . . . . . . . . . 444
Example PIM configuration that uses BSR to find the RP . . . . . . . . . . . . . 447
IPv6 459
IPv6 overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 459
Differences between IPv6 and IPv4 . . . . . . . . . . . . . . . . . . . . . . . . 460
IPv6 MTU. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 460
IPv6 address format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 461
IP address notation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 461
Netmasks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 462
Address scopes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 462
Address types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 462
IPv6 neighbor discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 464
FortiGate IPv6 configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 465
UTM protection for IPv6 networks . . . . . . . . . . . . . . . . . . . . . . . . . 465
Displaying IPv6 options on the web-based manager. . . . . . . . . . . . . . . . 465
Configuring IPv6 interfaces. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 466
Configuring IPv6 routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 467
Configuring IPv6 firewall policies . . . . . . . . . . . . . . . . . . . . . . . . . . 467
Configuring IPv6 DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 468
Configuring IPv6 over IPv4 tunneling . . . . . . . . . . . . . . . . . . . . . . . 468
Configuring IPv6 IPSec VPNs . . . . . . . . . . . . . . . . . . . . . . . . . . . 469
Transition from IPv4 to IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 471
Configuring FortiOS to connect to an IPv6 tunnel provider. . . . . . . . . . . . . . . 471
IPv6 troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 474
ping6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 474
diagnose sniffer packet. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 477
diagnose debug flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 478
IPv6 specific diag commands . . . . . . . . . . . . . . . . . . . . . . . . . . . 478
Additional IPv6 resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 479
FortiOS 4.0 MR2

24 01-420-99686-20101026
Detailed Contents
Virtual LANs 481

VLAN ID rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 482
VLAN switching and routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 482
VLAN layer-2 switching. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 482
VLAN layer-3 routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 485
VLANs in NAT/Route mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 489
Adding VLAN subinterfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . 490
Configuring firewall policies and routing . . . . . . . . . . . . . . . . . . . . . . 492
Example VLAN configuration in NAT mode . . . . . . . . . . . . . . . . . . . . . . 493
General configuration steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . 494
Configure the FortiGate unit . . . . . . . . . . . . . . . . . . . . . . . . . . . . 494
Configure the VLAN switch. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 498
Test the configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 499
VLANs in transparent mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 500
VLANs and transparent mode . . . . . . . . . . . . . . . . . . . . . . . . . . . 500
Example of VLANs in transparent mode . . . . . . . . . . . . . . . . . . . . . . 502
Test the configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 508
Troubleshooting VLAN issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 508
Asymmetric routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 508
Layer-2 and Arp traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 509
Forward-domain solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 510
NetBIOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 511
STP forwarding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 511
Too many VLAN interfaces. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 512
PPTP and L2TP 513

How PPTP VPNs work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 513
FortiGate unit as a PPTP server . . . . . . . . . . . . . . . . . . . . . . . . . . . . 515
Configuring user authentication for PPTP clients . . . . . . . . . . . . . . . . . 515
Enabling PPTP and specifying the PPTP IP address range . . . . . . . . . . . . 516
Adding the firewall policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 517
Configuring the FortiGate unit for PPTP VPN . . . . . . . . . . . . . . . . . . . . . 518
PPTP pass through configuration overview . . . . . . . . . . . . . . . . . . . . 518
Configuring the FortiGate unit for PPTP pass through . . . . . . . . . . . . . . . . . 518
Configuring a virtual IP address . . . . . . . . . . . . . . . . . . . . . . . . . . 518
Configuring a port-forwarding firewall policy . . . . . . . . . . . . . . . . . . . . 519
Testing PPTP VPN connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . 520
Logging VPN events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 520
Configuring L2TP VPNs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 520
Network topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 522
01-420-99686-20101026 25
Detailed Contents
L2TP configuration overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 523

Authenticating L2TP clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . 524
Enabling L2TP and specifying an address range . . . . . . . . . . . . . . . . . 524
Defining firewall source and destination addresses . . . . . . . . . . . . . . . . 524
Adding the firewall policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 525
Configuring a Linux client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 525
Monitoring L2TP sessions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 526
Testing L2TP VPN connections . . . . . . . . . . . . . . . . . . . . . . . . . . 526
Logging L2TP VPN events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 526
Session helpers 527

Viewing the session helper configuration. . . . . . . . . . . . . . . . . . . . . . . . 528
Changing the session helper configuration . . . . . . . . . . . . . . . . . . . . . . . 528
Changing the protocol or port that a session helper listens on. . . . . . . . . . . 528
Disabling a session helper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 530
DCE-RPC session helper (dcerpc) . . . . . . . . . . . . . . . . . . . . . . . . . . . 531
DNS session helpers (dns-tcp and dns-udp) . . . . . . . . . . . . . . . . . . . . . . 531
File transfer protocol (FTP) session helper (ftp) . . . . . . . . . . . . . . . . . . . . 532
H.245 session helpers (h245I and h245O) . . . . . . . . . . . . . . . . . . . . . . . 532
H.323 and RAS session helpers (h323 and ras) . . . . . . . . . . . . . . . . . . . . 532
Alternate H.323 gatekeepers . . . . . . . . . . . . . . . . . . . . . . . . . . . . 532
Media Gateway Controller Protocol (MGCP) session helper (mgcp) . . . . . . . . . . 533
ONC-RPC portmapper session helper (pmap) . . . . . . . . . . . . . . . . . . . . . 533
PPTP session helper for PPTP traffic (pptp) . . . . . . . . . . . . . . . . . . . . . . 534
Remote shell session helper (rsh) . . . . . . . . . . . . . . . . . . . . . . . . . . . 535
Real-Time Streaming Protocol (RTSP) session helper (rtsp) . . . . . . . . . . . . . 535
Session Initiation Protocol (SIP) session helper (sip) . . . . . . . . . . . . . . . . . 536
Trivial File Transfer Protocol (TFTP) session helper (tftp) . . . . . . . . . . . . . . . 536
Oracle TNS listener session helper (tns) . . . . . . . . . . . . . . . . . . . . . . . . 536
Advanced firewall concepts 537

Session tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 537
Viewing session tables in the web-based manager . . . . . . . . . . . . . . . . 537
Viewing session tables in the CLI . . . . . . . . . . . . . . . . . . . . . . . . . 538
Adding NAT firewall policies in transparent mode . . . . . . . . . . . . . . . . . . . 540
Adding a static NAT virtual IP for a single IP address and port . . . . . . . . . . . . 542
Double NAT: combining IP pool with virtual IP . . . . . . . . . . . . . . . . . . . . . 544
Using VIP range for Source NAT (SNAT) and static 1-to-1 mapping. . . . . . . . . . 546
FortiOS 4.0 MR2

26 01-420-99686-20101026
Detailed Contents
Advanced concepts 551

Central NAT table. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 551
DHCP servers and relays. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 552
Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 552
Reserving IP addresses for specific clients . . . . . . . . . . . . . . . . . . . . 552
FortiGate DNS services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 553
Split DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 553
Configuring the FortiGate DNS database . . . . . . . . . . . . . . . . . . . . . 555
Administration for schools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 556
Firewall policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 556
UTM Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 557
Blocking port 25 to email server traffic . . . . . . . . . . . . . . . . . . . . . . . . . 560
Dedicated traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 560
Restricting traffic on port 25 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 561
Blocking HTTP access by IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 562
Assigning IP address by MAC address. . . . . . . . . . . . . . . . . . . . . . . . . 563
Server load balancing and HTTP cookie persistence fields . . . . . . . . . . . . . . 563
Stateful inspection of SCTP traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . 565
Configuring FortiGate SCTP filtering . . . . . . . . . . . . . . . . . . . . . . . . 565
Adding an SCTP custom service . . . . . . . . . . . . . . . . . . . . . . . . . . 566
Adding an SCTP policy route. . . . . . . . . . . . . . . . . . . . . . . . . . . . 566
Changing the session time to live for SCTP traffic . . . . . . . . . . . . . . . . . 567
Adding an SCTP port forwarding virtual IP . . . . . . . . . . . . . . . . . . . . . 567
Chapter 4 Logging and Reporting 569
Logging overview 571

What is logging? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 571
What is a log message? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 571
Explanation of a log message . . . . . . . . . . . . . . . . . . . . . . . . . . . 575
How the FortiGate unit records log messages . . . . . . . . . . . . . . . . . . . . . 576
Example: How the FortiGate unit records a DLP event . . . . . . . . . . . . . . 576
Log management practices. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 577
The SQL log database 579

SQL overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 579
SQL tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 579
01-420-99686-20101026 27
Detailed Contents
SQL statement examples. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 580

Distribution of Applications by Type in the last 24 hours . . . . . . . . . . . . . . 580
Top 10 Application Bandwidth Usage Per Hour Summary . . . . . . . . . . . . . 580
Troubleshooting SQL issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 581
SQL statement syntax errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . 581
Connection problems. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 581
SQL database error . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 582
Log devices 583

Selecting a log device . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 583
Example: Setting up a log device and backup solution . . . . . . . . . . . . . . 584
Configuring the FortiGate unit to store logs on a log device . . . . . . . . . . . . . . 585
Logging to the FortiGate unit’s system memory . . . . . . . . . . . . . . . . . . 585
Logging to the FortiGate unit’s hard disk . . . . . . . . . . . . . . . . . . . . . . 586
Logging to a FortiAnalyzer unit . . . . . . . . . . . . . . . . . . . . . . . . . . . 587
Logging to a FortiGuard Analysis server . . . . . . . . . . . . . . . . . . . . . . 588
Logging to a Syslog server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 589
Logging to a WebTrends server . . . . . . . . . . . . . . . . . . . . . . . . . . 590
Logging to multiple FortiAnalyzer units or Syslog servers . . . . . . . . . . . . . 591
Example of configuring multiple FortiAnalyzer units . . . . . . . . . . . . . . . . 593
Troubleshooting connectivity problems. . . . . . . . . . . . . . . . . . . . . . . . . 594
Logging FortiGate activity 595

Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 595
Traffic. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 596
Event . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 596
Data Leak Prevention . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 597
Application control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 597
Antivirus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 598
Web Filter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 598
IPS (attack) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 598
Email filter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 599
Archives (DLP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 599
Network scan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 599
Configuring logging of FortiGate activity on your FortiGate unit . . . . . . . . . . . . 599
Enabling logging within a firewall policy . . . . . . . . . . . . . . . . . . . . . . 600
Enabling logging of events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 600
Configuring logging for the application control monitoring feature . . . . . . . . . 601
Configuring IPS packet logging . . . . . . . . . . . . . . . . . . . . . . . . . . 602
Configuring NAC quarantine logging . . . . . . . . . . . . . . . . . . . . . . . . 602
Viewing log messages and quarantine files . . . . . . . . . . . . . . . . . . . . . . 603
Viewing quarantined files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 604
FortiOS 4.0 MR2

28 01-420-99686-20101026
Detailed Contents
Customizing the display of log messages . . . . . . . . . . . . . . . . . . . . . . . 605

Filtering and customizing application control log messages example . . . . . . . 605
Alert email messages. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 606
Configuring an alert email message . . . . . . . . . . . . . . . . . . . . . . . . 606
Configuring an alert email for notification of FortiGuard license expiry . . . . . . 607
Log message usage 609

Using log messages when troubleshooting. . . . . . . . . . . . . . . . . . . . . . . 609
HA log messages indicate lost neighbor information. . . . . . . . . . . . . . . . 609
Alert email test configuration issues example . . . . . . . . . . . . . . . . . . . 610
Using log messages to verify settings and for testing purposes . . . . . . . . . . . . 610
Verifying to see if a network scan was performed example . . . . . . . . . . . . 610
Testing for the FortiGuard license expiry log message example. . . . . . . . . . 611
Using diag log test to verify logs are sent to a log device . . . . . . . . . . . . . 611
Reports 613
Report overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 613
FortiOS reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 614
Creating datasets for charts . . . . . . . . . . . . . . . . . . . . . . . . . . . . 615
Configuring the charts for the report . . . . . . . . . . . . . . . . . . . . . . . . 615
Configuring a theme for the report . . . . . . . . . . . . . . . . . . . . . . . . . 616
Customizing and creating styles for a theme. . . . . . . . . . . . . . . . . . . . 617
Importing images for the report. . . . . . . . . . . . . . . . . . . . . . . . . . . 618
Configuring the layout for the report . . . . . . . . . . . . . . . . . . . . . . . . 619
FortiAnalyzer reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 620
Configuring a FortiAnalyzer report schedule . . . . . . . . . . . . . . . . . . . . 620
Executive Summary reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 621
Viewing reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 621
Report examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 622
Report for analyzing traffic on the network . . . . . . . . . . . . . . . . . . . . . 622
Report for application usage on the network . . . . . . . . . . . . . . . . . . . . 623
Chapter 5 Troubleshooting 629
Troubleshooting process 631

Establish a baseline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 631
Define the Problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 631
Gathering Facts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 632
01-420-99686-20101026 29
Detailed Contents
Search for a solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 633

Technical Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 633
Release Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 633
Knowledge Center . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 633
Fortinet Technical Discussion Forums . . . . . . . . . . . . . . . . . . . . . . . 633
Fortinet Training Services Online Campus . . . . . . . . . . . . . . . . . . . . . 633
Create a troubleshooting plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 633
Providing Supporting Elements . . . . . . . . . . . . . . . . . . . . . . . . . . 634
Obtain any required additional equipment . . . . . . . . . . . . . . . . . . . . . . . 634
Ensure you have administrator level access to required equipment . . . . . . . . . . 634
Contact Fortinet Customer Support for assistance . . . . . . . . . . . . . . . . . . . 634
Troubleshooting tools 635

FortiOS Diagnostics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 635
Resource Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 635
Processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 636
Proxy Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 637
Hardware NIC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 638
Conserve Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 640
Traffic Trace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 642
Session Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 642
Finding Object Dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . 645
Flow Trace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 646
Packet Sniffer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 650
Debug Command. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 653
Other Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 655
FortiGate Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 657
Diagnostic Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 658
FortiAnalyzer/FortiManager Ports . . . . . . . . . . . . . . . . . . . . . . . . . 659
FortiGuard Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 660
FortiGuard URL Rating . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 662
Technical Support Organization Overview 663

Fortinet Global Customer Services Organization. . . . . . . . . . . . . . . . . . . . 663
Creating an Account . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 664
Registering a Device . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 665
Reporting Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 667
Logging Online Tickets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 667
Following Up On Online Tickets . . . . . . . . . . . . . . . . . . . . . . . . . . 670
Telephoning a Technical Support Center . . . . . . . . . . . . . . . . . . . . . 671
FortiOS 4.0 MR2

30 01-420-99686-20101026
Detailed Contents
Assisting Technical Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 672

Support Priority Levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 673
Priority 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 673
Priority 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 673
Priority 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 673
Priority 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 673
Return Material Authorization Process . . . . . . . . . . . . . . . . . . . . . . . . . 674
Troubleshooting connectivity 677

Check hardware connections . . . . . . . . . . . . . . . . . . . . . . . . . . . 678
Run ping and traceroute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 678
Verify the contents of the routing table (in NAT mode). . . . . . . . . . . . . . . 682
For Transparent mode, check the bridging information . . . . . . . . . . . . . . 682
Perform a sniffer trace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 683
Debug the packet flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 685
Examine the firewall session list . . . . . . . . . . . . . . . . . . . . . . . . . . 686
Other diagnose commands. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 686
Troubleshooting get commands 687

exec tac report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 687
get firewall iprope list . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 688
get firewall iprope appctrl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 689
get firewall proute. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 689
get hardware cpu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 690
get hardware nic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 692
get hardware cpu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 693
get hardware memory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 694
get hardware npu ipsec-sa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 695
get hardware npu list . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 695
get hardware npu performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 697
get hardware npu status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 698
get hardware status. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 699
get ips session . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 700
get router info kernel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 701
get system arp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 702
get system auto-update. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 702
get system auto-update version . . . . . . . . . . . . . . . . . . . . . . . . . . . . 705
get system ha status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 706
01-420-99686-20101026 31
Detailed Contents
get system performance firewall . . . . . . . . . . . . . . . . . . . . . . . . . . . . 707

get system performance firewall packet-distribution . . . . . . . . . . . . . . . . . . 708
get system performance status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 709
get system performance top . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 710
get system session-info full-stat . . . . . . . . . . . . . . . . . . . . . . . . . . . . 711
get system session-helper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 712
get system session-table list . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 712
get system session-table statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . 713
get system session-info ttl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 714
get system startup-error-log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 714
get test application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 715
get test application urlfilter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 719
get vpn status ike config . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 720
get vpn status ike crypto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 720
get vpn status ike errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 721
get vpn status ike status detailed . . . . . . . . . . . . . . . . . . . . . . . . . . . . 722
get vpn status ipsec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 722
get vpn status ssl hw-acceleration-status . . . . . . . . . . . . . . . . . . . . . . . 723
get vpn status ssl list . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 724
get vpn status tunnel dialup-list. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 724
get vpn status tunnel list . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 724
get vpn status tunnel stat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 725
get vpn status concentrator. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 726
get webfilter ftgd-statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 726
get webfilter status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 728
Troubleshooting bootup issues 731

A. You have text on the screen, but you have problems . . . . . . . . . . . . . . . . 731
B. You don’t see the boot options menu . . . . . . . . . . . . . . . . . . . . . . . . 731
C. You have problems with the console text . . . . . . . . . . . . . . . . . . . . . . 732
D. You have visible power problems . . . . . . . . . . . . . . . . . . . . . . . . . . 732
E. You have a suspected defective FortiOS unit . . . . . . . . . . . . . . . . . . . . 733
FortiOS 4.0 MR2

32 01-420-99686-20101026
Detailed Contents
Chapter 6 UTM Guide 735
UTM overview 737

UTM components. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 737
AntiVirus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 737
Intrusion Protection System (IPS) . . . . . . . . . . . . . . . . . . . . . . . . . 738
Anomaly protection (DoS policies) . . . . . . . . . . . . . . . . . . . . . . . . . 738
One-armed IDS (sniffer policies) . . . . . . . . . . . . . . . . . . . . . . . . . . 738
Web filtering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 738
Email filtering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 738
Data Leak Prevention (DLP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 738
Application Control (for example, IM and P2P). . . . . . . . . . . . . . . . . . . 739
UTM profiles/lists/sensors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 739
UTM and Virtual domains (VDOMs) . . . . . . . . . . . . . . . . . . . . . . . . . . 739
Conserve mode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 740
The AV proxy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 740
Entering and exiting conserve mode . . . . . . . . . . . . . . . . . . . . . . . . 740
Conserve mode effects. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 740
Configuring the av-failopen command . . . . . . . . . . . . . . . . . . . . . . . 741
SSL content scanning and inspection . . . . . . . . . . . . . . . . . . . . . . . . . 741
Setting up certificates to avoid client warnings . . . . . . . . . . . . . . . . . . . 742
SSL content scanning and inspection settings . . . . . . . . . . . . . . . . . . . 743
Viewing and saving logged packets . . . . . . . . . . . . . . . . . . . . . . . . . . 745
Configuring packet logging options. . . . . . . . . . . . . . . . . . . . . . . . . 745
Using wildcards and Perl regular expressions . . . . . . . . . . . . . . . . . . . . . 746
Network defense 749

Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 749
Blocking external probes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 749
Address sweeps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 749
Port scans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 750
Probes using IP traffic options . . . . . . . . . . . . . . . . . . . . . . . . . . . 750
Evasion techniques. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 752
01-420-99686-20101026 33
Detailed Contents
Defending against DoS attacks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 753

The “three-way handshake” . . . . . . . . . . . . . . . . . . . . . . . . . . . . 754
SYN flood. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 754
SYN spoofing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 755
DDoS SYN flood . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 755
Configuring the SYN threshold to prevent SYN floods . . . . . . . . . . . . . . . 756
SYN proxy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 756
Other flood types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 757
Traffic inspection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 757
IPS signatures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 757
Suspicious traffic attributes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 758
DoS policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 758
Application control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 758
Content inspection and filtering. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 759
AntiVirus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 759
FortiGuard Web Filtering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 759
Email filter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 760
DLP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 760
AntiVirus 761
Antivirus concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 761
How antivirus scanning works . . . . . . . . . . . . . . . . . . . . . . . . . . . 761
Antivirus scanning order . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 762
Antivirus databases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 764
Antivirus techniques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 765
FortiGuard Antivirus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 766
Enable antivirus scanning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 766
Viewing antivirus database information . . . . . . . . . . . . . . . . . . . . . . 766
Changing the default antivirus database . . . . . . . . . . . . . . . . . . . . . . 767
Overriding the default antivirus database . . . . . . . . . . . . . . . . . . . . . 767
Adding the antivirus profile to a firewall policy . . . . . . . . . . . . . . . . . . . 768
Configuring the scan buffer size . . . . . . . . . . . . . . . . . . . . . . . . . . 768
Configuring archive scan depth . . . . . . . . . . . . . . . . . . . . . . . . . . 769
Configuring a maximum allowed file size. . . . . . . . . . . . . . . . . . . . . . 769
Configuring client comforting . . . . . . . . . . . . . . . . . . . . . . . . . . . . 770
Enable the file quarantine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 771
Configuring the file quarantine . . . . . . . . . . . . . . . . . . . . . . . . . . . 771
Viewing quarantined files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 772
Downloading quarantined files . . . . . . . . . . . . . . . . . . . . . . . . . . . 772
FortiOS 4.0 MR2

34 01-420-99686-20101026
Detailed Contents
Enable file filtering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 773

Creating a file filter list . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 773
Creating a file pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 774
Creating a file type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 774
Enabling file filtering in a profile . . . . . . . . . . . . . . . . . . . . . . . . . . 774
Enable grayware scanning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 775
Testing your antivirus configuration . . . . . . . . . . . . . . . . . . . . . . . . . . 775
Antivirus examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 775
Configuring simple antivirus protection. . . . . . . . . . . . . . . . . . . . . . . 776
Protecting your network against malicious email attachments . . . . . . . . . . . 777
Email filter 781

Email filter concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 781
Email filter techniques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 781
Order of spam filtering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 782
Enable email filter. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 783
Enabling FortiGuard IP address checking . . . . . . . . . . . . . . . . . . . . . 784
Enabling FortiGuard URL checking . . . . . . . . . . . . . . . . . . . . . . . . 784
Enabling FortiGuard email checksum checking . . . . . . . . . . . . . . . . . . 784
Enabling FortiGuard spam submission. . . . . . . . . . . . . . . . . . . . . . . 785
Enabling IP address black/white list checking . . . . . . . . . . . . . . . . . . . 785
Enabling HELO DNS lookup . . . . . . . . . . . . . . . . . . . . . . . . . . . . 787
Enabling email address black/white list checking . . . . . . . . . . . . . . . . . 787
Enabling return email DNS checking . . . . . . . . . . . . . . . . . . . . . . . . 788
Enabling banned word checking . . . . . . . . . . . . . . . . . . . . . . . . . . 789
How content is evaluated. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 789
Configure the spam action . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 792
Configure the tag location . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 792
Configure the tag format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 793
Email filter examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 793
Configuring simple antispam protection . . . . . . . . . . . . . . . . . . . . . . 793
Blocking email from a user . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 794
Intrusion protection 797

IPS concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 797
Anomaly-based defense . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 797
Signature-based defense. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 797
01-420-99686-20101026 35
Detailed Contents
Enable IPS scanning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 799

Creating an IPS sensor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 799
Creating an IPS filter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 799
Updating predefined IPS signatures . . . . . . . . . . . . . . . . . . . . . . . . 800
Creating an IPS signature override. . . . . . . . . . . . . . . . . . . . . . . . . 800
Creating a custom IPS signature . . . . . . . . . . . . . . . . . . . . . . . . . . 801
Custom signature syntax and keywords . . . . . . . . . . . . . . . . . . . . . . 801
IPS processing in an HA cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . 810
Active-passive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 811
Active-active . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 811
Configure IPS options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 811
Configuring the IPS engine algorithm . . . . . . . . . . . . . . . . . . . . . . . 811
Configuring the IPS engine-count . . . . . . . . . . . . . . . . . . . . . . . . . 811
Configuring fail-open . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 812
Configuring the session count accuracy . . . . . . . . . . . . . . . . . . . . . . 812
Configuring the IPS buffer size . . . . . . . . . . . . . . . . . . . . . . . . . . . 812
Configuring protocol decoders . . . . . . . . . . . . . . . . . . . . . . . . . . . 812
Configuring security processing modules . . . . . . . . . . . . . . . . . . . . . 813
Enable IPS packet logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 813
IPS examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 814
Configuring basic IPS protection . . . . . . . . . . . . . . . . . . . . . . . . . . 814
Using IPS to protect your web server . . . . . . . . . . . . . . . . . . . . . . . 815
Create and test a packet logging IPS sensor . . . . . . . . . . . . . . . . . . . 817
Creating a custom signature to block access to example.com. . . . . . . . . . . 819
Creating a custom signature to block the SMTP “vrfy” command . . . . . . . . . 820
Configuring a Fortinet Security Processing module . . . . . . . . . . . . . . . . 822
Web filter 827

Web filter concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 827
Different ways of controlling access . . . . . . . . . . . . . . . . . . . . . . . . 829
Order of web filtering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 829
Web content filter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 829
Creating a web filter content list . . . . . . . . . . . . . . . . . . . . . . . . . . 830
Configuring a web content filter list. . . . . . . . . . . . . . . . . . . . . . . . . 830
How content is evaluated. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 831
Enabling the web content filter and setting the content threshold . . . . . . . . . 832
URL filter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 832
URL filter actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 833
Creating a URL filter list . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 835
Configuring a URL filter list . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 836
FortiOS 4.0 MR2

36 01-420-99686-20101026
Detailed Contents
SafeSearch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 836
Advanced web filter configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . 837
ActiveX filter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 837
Cookie filter. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 837
Java applet filter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 837
Web resume download block. . . . . . . . . . . . . . . . . . . . . . . . . . . . 837
Block Invalid URLs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 837
HTTP POST action . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 838
Web filtering example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 838
School district . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 838
FortiGuard Web Filter 843

Before you begin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 843
FortiGuard Web Filter and your FortiGate unit . . . . . . . . . . . . . . . . . . . . . 844
Order of web filtering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 844
Enable FortiGuard Web Filter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 846
Configuring FortiGuard Web Filter settings . . . . . . . . . . . . . . . . . . . . 846
Configuring FortiGuard Web Filter categories . . . . . . . . . . . . . . . . . . . 846
Configuring FortiGuard Web Filter classifications . . . . . . . . . . . . . . . . . 847
Configuring FortiGuard Web Filter usage quotas . . . . . . . . . . . . . . . . . 848
Checking quota usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 850
Advanced FortiGuard Web Filter configuration . . . . . . . . . . . . . . . . . . . . . 850
Provide Details for Blocked HTTP 4xx and 5xx Errors . . . . . . . . . . . . . . . 850
Rate Images by URL (blocked images will be replaced with blanks) . . . . . . . 850
Allow Websites When a Rating Error Occurs . . . . . . . . . . . . . . . . . . . 850
Strict Blocking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 851
Rate URLs by Domain and IP Address . . . . . . . . . . . . . . . . . . . . . . 851
Block HTTP Redirects by Rating . . . . . . . . . . . . . . . . . . . . . . . . . . 851
Daily log of remaining quota . . . . . . . . . . . . . . . . . . . . . . . . . . . . 851
Add or change FortiGuard Web Filter ratings . . . . . . . . . . . . . . . . . . . . . 851
Create FortiGuard Web Filter overrides . . . . . . . . . . . . . . . . . . . . . . . . 852
Understanding administrative and user overrides . . . . . . . . . . . . . . . . . 852
Customize categories and ratings . . . . . . . . . . . . . . . . . . . . . . . . . . . 853
Creating local categories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 853
Customizing site ratings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 853
FortiGuard Web Filter examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . 854
Configuring simple FortiGuard Web Filter protection. . . . . . . . . . . . . . . . 854
School district . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 855
01-420-99686-20101026 37
Detailed Contents
Data leak prevention 857

Data leak prevention concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 857
DLP sensor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 857
DLP rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 857
DLP compound rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 858
Enable data leak prevention . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 859
Creating a DLP rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 859
Understanding the default DLP rules. . . . . . . . . . . . . . . . . . . . . . . . 862
Creating a compound DLP rule . . . . . . . . . . . . . . . . . . . . . . . . . . 863
Creating a DLP sensor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 863
Adding rules to a DLP sensor . . . . . . . . . . . . . . . . . . . . . . . . . . . 864
Understanding default DLP sensors . . . . . . . . . . . . . . . . . . . . . . . . 866
DLP archiving. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 867
DLP examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 868
Configuring DLP content archiving . . . . . . . . . . . . . . . . . . . . . . . . . 868
Blocking sensitive email messages . . . . . . . . . . . . . . . . . . . . . . . . 868
Application control 871

Application control concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 871
Enable application control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 872
Creating an application control list . . . . . . . . . . . . . . . . . . . . . . . . . 872
Adding applications to an application control list . . . . . . . . . . . . . . . . . . 872
Understanding the default application control lists . . . . . . . . . . . . . . . . . 874
Application traffic shaping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 874
Enabling application control traffic shaping . . . . . . . . . . . . . . . . . . . . 874
Reverse direction traffic shaping . . . . . . . . . . . . . . . . . . . . . . . . . . 875
Shaper re-use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 875
Application control monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 876
Enabling application control monitor . . . . . . . . . . . . . . . . . . . . . . . . 876
Application control packet logging . . . . . . . . . . . . . . . . . . . . . . . . . . . 877
Application considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 878
IM applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 878
Skype. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 878
Application control examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 878
Blocking all instant messaging . . . . . . . . . . . . . . . . . . . . . . . . . . . 878
Allowing only software updates . . . . . . . . . . . . . . . . . . . . . . . . . . 879
FortiOS 4.0 MR2

38 01-420-99686-20101026
Detailed Contents
DoS policy 881

DoS policy concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 881
Enable DoS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 881
Creating and configuring a DoS sensor . . . . . . . . . . . . . . . . . . . . . . 881
Creating a DoS policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 883
Apply an IPS sensor to a DoS policy . . . . . . . . . . . . . . . . . . . . . . . . 884
DoS example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 884
Sniffer policy 887

Sniffer policy concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 887
The sniffer policy list . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 887
Before you begin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 888
Enable one-arm sniffing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 889
Designating a sniffer interface . . . . . . . . . . . . . . . . . . . . . . . . . . . 890
Creating a sniffer policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 890
Sniffer example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 891
An IDS sniffer configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . 891
Chapter 7 User Authentication 895
Introduction to authentication 897

What is authentication?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 897
Means of authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 897
Local password authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . 897
Server-based password authentication . . . . . . . . . . . . . . . . . . . . . . 897
Certificate-based authentication . . . . . . . . . . . . . . . . . . . . . . . . . . 898
Two-factor authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 899
Types of authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 899
Firewall authentication (or Identity-based policies). . . . . . . . . . . . . . . . . 899
VPN authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 900
User’s view of authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 901
Web-based user authentication . . . . . . . . . . . . . . . . . . . . . . . . . . 901
VPN client-based authentication . . . . . . . . . . . . . . . . . . . . . . . . . . 902
FortiGate administrator’s view of authentication . . . . . . . . . . . . . . . . . . . . 902
01-420-99686-20101026 39
Detailed Contents
Authentication servers 905

RADIUS servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 905
Configuring the FortiGate unit to use a RADIUS server . . . . . . . . . . . . . . 906
LDAP servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 907
Configuring the FortiGate unit to use an LDAP server . . . . . . . . . . . . . . . 909
TACACS+ servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 911
Configuring the FortiGate unit to use a TACACS+ authentication server . . . . . 912
Directory Service servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 913
RSA/ACE (SecurID) servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 913
Using the SecurID user group for authentication. . . . . . . . . . . . . . . . . . 914
Users and user groups 915

Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 915
Creating local users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 916
Creating PKI or peer users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 917
User groups. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 919
Firewall user groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 919
Directory Service user groups . . . . . . . . . . . . . . . . . . . . . . . . . . . 921
Configuring Peer user groups . . . . . . . . . . . . . . . . . . . . . . . . . . . 921
Configuring authenticated access 923

Authentication timeout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 923
Password policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 923
Authentication protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 924
Authentication in firewall policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . 925
Configuring authentication for a firewall policy . . . . . . . . . . . . . . . . . . . 925
Configuring authenticated access to the Internet . . . . . . . . . . . . . . . . . 927
VPN authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 927
Configuring authentication of SSL VPN users . . . . . . . . . . . . . . . . . . . 927
Configuring authentication of remote IPsec VPN users . . . . . . . . . . . . . . 928
Configuring authentication of PPTP VPN users and user groups . . . . . . . . . 930
Configuring authentication of L2TP VPN users/user groups . . . . . . . . . . . . 930
FSAE for integration with Windows AD or Novell 933

Introduction to FSAE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 933
Using FSAE in a Windows AD environment . . . . . . . . . . . . . . . . . . . . 933
Using FSAE in a Novell eDirectory environment . . . . . . . . . . . . . . . . . . 937
Operating system requirements . . . . . . . . . . . . . . . . . . . . . . . . . . 937
FortiOS 4.0 MR2

40 01-420-99686-20101026
Detailed Contents
Installing FSAE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 937

FSAE components for Windows AD . . . . . . . . . . . . . . . . . . . . . . . . 937
FSAE components for Novell eDirectory . . . . . . . . . . . . . . . . . . . . . . 938
Installing FSAE for Windows AD . . . . . . . . . . . . . . . . . . . . . . . . . . 938
Installing FSAE for Novell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 939
Configuring FSAE on Windows AD. . . . . . . . . . . . . . . . . . . . . . . . . . . 940
Configuring Windows AD server user groups . . . . . . . . . . . . . . . . . . . 940
Configuring collector agent settings . . . . . . . . . . . . . . . . . . . . . . . . 941
Configuring Directory Access settings . . . . . . . . . . . . . . . . . . . . . . . 943
Configuring the Ignore User List . . . . . . . . . . . . . . . . . . . . . . . . . . 943
Configuring FortiGate group filters . . . . . . . . . . . . . . . . . . . . . . . . . 944
Configuring TCP ports for FSAE on client computers . . . . . . . . . . . . . . . 946
Configuring ports on the collector agent computer . . . . . . . . . . . . . . . . . 946
Configuring alternate user IP address tracking. . . . . . . . . . . . . . . . . . . 946
Viewing collector agent status . . . . . . . . . . . . . . . . . . . . . . . . . . . 946
Viewing DC agent status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 947
Selecting Domain Controllers and working mode for monitoring. . . . . . . . . . 948
Configuring FSAE on Novell networks . . . . . . . . . . . . . . . . . . . . . . . . . 949
Configuring a group filter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 951
Configuring FSAE on FortiGate units. . . . . . . . . . . . . . . . . . . . . . . . . . 952
Configuring LDAP server access. . . . . . . . . . . . . . . . . . . . . . . . . . 952
Specifying your collector agents or Novell eDirectory agents . . . . . . . . . . . 954
Selecting Windows user groups (LDAP only) . . . . . . . . . . . . . . . . . . . 955
Viewing information imported from the Windows AD server . . . . . . . . . . . . 955
Creating Directory Service user groups . . . . . . . . . . . . . . . . . . . . . . 957
Creating firewall policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 957
Enabling guests to access FSAE policies . . . . . . . . . . . . . . . . . . . . . 958
Testing the configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 959
Certificate-based authentication 961

Certificates overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 961
SSL, HTTPS, and certificates . . . . . . . . . . . . . . . . . . . . . . . . . . . 961
IPsec VPNs and certificates . . . . . . . . . . . . . . . . . . . . . . . . . . . . 962
Managing X.509 certificates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 962
Generating a certificate signing request . . . . . . . . . . . . . . . . . . . . . . 962
Generating certificates with CA software. . . . . . . . . . . . . . . . . . . . . . 964
Obtaining a signed server certificate from an external CA . . . . . . . . . . . . . 965
Installing a CA root certificate and CRL to authenticate remote clients . . . . . . 965
Online updates to certificates and CRLs . . . . . . . . . . . . . . . . . . . . . . 966
Backing up and restoring local certificates . . . . . . . . . . . . . . . . . . . . . 968
01-420-99686-20101026 41
Detailed Contents
Configuring certificate-based authentication . . . . . . . . . . . . . . . . . . . . . . 970

Authenticating administrators with security certificates . . . . . . . . . . . . . . 970
Authenticating SSL VPN users with security certificates . . . . . . . . . . . . . 970
Authenticating IPsec VPN users with security certificates . . . . . . . . . . . . . 971
Monitoring authenticated users 973

Monitoring firewall users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 973
Monitoring SSL VPN users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 973
Monitoring IPsec VPN users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 974
Example 975
Firewall authentication example . . . . . . . . . . . . . . . . . . . . . . . . . . . . 975
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 975
Creating a locally-authenticated user account . . . . . . . . . . . . . . . . . . . 976
Creating a RADIUS-authenticated user account . . . . . . . . . . . . . . . . . . 976
Creating user groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 977
Defining firewall addresses. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 979
Creating firewall policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 979
Chapter 8 IPsec VPNs 983
IPsec VPN concepts 985

IP packets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 985
VPN tunnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 986
VPN gateways . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 987
Clients, servers, and peers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 989
Encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 989
Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 990
Phase 1 and Phase 2 settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 990
Phase 1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 990
Phase 2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 991
Security Association . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 991
FortiGate IPsec VPN Overview 993

About FortiGate VPNs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 993
Planning your VPN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 994
Network topologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 994
Choosing policy-based or route-based VPNs . . . . . . . . . . . . . . . . . . . . . 994
FortiOS 4.0 MR2

42 01-420-99686-20101026
Detailed Contents
General preparation steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 995

How to use this guide to configure an IPsec VPN . . . . . . . . . . . . . . . . . . . 995
Gateway-to-gateway configurations 997

Configuration overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 997
Gateway-to-gateway infrastructure requirements . . . . . . . . . . . . . . . . . 999
General configuration steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 999
Configure the VPN peers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 999
Configuration example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1001
Define the phase 1 parameters on FortiGate_1 . . . . . . . . . . . . . . . . . 1001
Define the phase 2 parameters on FortiGate_1 . . . . . . . . . . . . . . . . . 1002
Define the firewall policy on FortiGate_1 . . . . . . . . . . . . . . . . . . . . . 1002
Configure FortiGate_2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1004
How to work with overlapping subnets . . . . . . . . . . . . . . . . . . . . . . . . 1006
Solution for route-based VPN . . . . . . . . . . . . . . . . . . . . . . . . . . 1007
Solution for policy-based VPN . . . . . . . . . . . . . . . . . . . . . . . . . . 1008
Hub-and-spoke configurations 1011

Configuration overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1011
Hub-and-spoke infrastructure requirements . . . . . . . . . . . . . . . . . . . 1012
Spoke gateway addressing. . . . . . . . . . . . . . . . . . . . . . . . . . . . 1012
Protected networks addressing . . . . . . . . . . . . . . . . . . . . . . . . . 1012
Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1013
Configure the hub. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1013
Define the hub-spoke VPNs . . . . . . . . . . . . . . . . . . . . . . . . . . . 1013
Define the hub-spoke firewall policies . . . . . . . . . . . . . . . . . . . . . . 1014
Configuring communication between spokes (policy-based VPN) . . . . . . . . 1015
Configuring communication between spokes (route-based VPN) . . . . . . . . 1016
Configure the spokes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1017
Configuring firewall policies for hub-to-spoke communication . . . . . . . . . . 1017
Configuring firewall policies for spoke-to-spoke communication . . . . . . . . . 1018
Dynamic spokes configuration example . . . . . . . . . . . . . . . . . . . . . . . 1020
Configure the hub (FortiGate_1) . . . . . . . . . . . . . . . . . . . . . . . . . 1020
Configure the spokes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1023
Dynamic DNS configurations 1025

Dynamic DNS infrastructure requirements . . . . . . . . . . . . . . . . . . . 1026
General configuration steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1026
01-420-99686-20101026 43
Detailed Contents
Configure the dynamically-addressed VPN peer . . . . . . . . . . . . . . . . . . . 1027

Configure the fixed-address VPN peer . . . . . . . . . . . . . . . . . . . . . . . 1029
FortiClient dialup-client configurations 1031

Peer identification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1032
Automatic configuration of FortiClient dialup clients . . . . . . . . . . . . . . . 1032
Using virtual IP addresses . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1033
FortiClient dialup-client infrastructure requirements . . . . . . . . . . . . . . . 1035
FortiClient-to-FortiGate VPN configuration steps . . . . . . . . . . . . . . . . . . 1035
Configure the FortiGate unit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1035
Configuring FortiGate unit VPN settings . . . . . . . . . . . . . . . . . . . . . 1036
Configuring the FortiGate unit as a VPN policy server . . . . . . . . . . . . . . 1038
Configuring DHCP service on the FortiGate unit . . . . . . . . . . . . . . . . . 1038
Configure the FortiClient Endpoint Security application . . . . . . . . . . . . . . . 1040
Configuring FortiClient to work with VPN policy distribution . . . . . . . . . . . 1040
Configuring FortiClient manually . . . . . . . . . . . . . . . . . . . . . . . . . 1040
Adding XAuth authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1041
FortiClient dialup-client configuration example . . . . . . . . . . . . . . . . . . . . 1042
Configuring FortiGate_1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1042
Configuring the FortiClient Endpoint Security application . . . . . . . . . . . . 1045
FortiGate dialup-client configurations 1047

FortiGate dialup-client infrastructure requirements . . . . . . . . . . . . . . . 1049
FortiGate dialup-client configuration steps . . . . . . . . . . . . . . . . . . . . . . 1050
Configure the server to accept FortiGate dialup-client connections . . . . . . . . . 1050
Configure the FortiGate dialup client . . . . . . . . . . . . . . . . . . . . . . . . . 1052
Supporting IKE Mode config clients 1055

Automatic configuration overview . . . . . . . . . . . . . . . . . . . . . . . . . . 1055
IKE Mode Config overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1055
Configuring IKE Mode Config. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1055
Configuring an IKE Mode Config client. . . . . . . . . . . . . . . . . . . . . . 1056
Configuring an IKE Mode Config server . . . . . . . . . . . . . . . . . . . . . 1056
Example: FortiGate unit as IKE Mode Config server . . . . . . . . . . . . . . . . . 1057
Example: FortiGate unit as IKE Mode Config client . . . . . . . . . . . . . . . . . 1058
FortiOS 4.0 MR2

44 01-420-99686-20101026
Detailed Contents
Internet-browsing configuration 1059

Creating an Internet browsing firewall policy . . . . . . . . . . . . . . . . . . . . . 1060
Routing all remote traffic through the VPN tunnel . . . . . . . . . . . . . . . . . . 1061
Configuring a FortiGate remote peer to support Internet browsing . . . . . . . 1061
Configuring a FortiClient application to support Internet browsing . . . . . . . . 1062
Redundant VPN configurations 1063

General configuration steps . . . . . . . . . . . . . . . . . . . . . . . . . . . 1064
Configure the VPN peers - route-based VPN . . . . . . . . . . . . . . . . . . . . 1065
Redundant route-based VPN configuration example. . . . . . . . . . . . . . . . . 1066
Partially-redundant route-based VPN example. . . . . . . . . . . . . . . . . . . . 1077
Creating a backup IPsec interface . . . . . . . . . . . . . . . . . . . . . . . . . . 1083
Transparent mode VPNs 1085

Transparent VPN infrastructure requirements . . . . . . . . . . . . . . . . . . 1088
Configure the VPN peers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1089
For more information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1090
Manual-key configurations 1091

Specify the manual keys for creating a tunnel . . . . . . . . . . . . . . . . . . . . 1091
IPv6 IPsec VPNs 1093

Overview of IPv6 IPsec support . . . . . . . . . . . . . . . . . . . . . . . . . . . 1093
Certificates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1093
01-420-99686-20101026 45
Detailed Contents
Configuring IPv6 IPsec VPNs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1094

Phase 1 configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1094
Phase 2 configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1094
Firewall policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1094
Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1094
Site-to-site IPv6 over IPv6 VPN example. . . . . . . . . . . . . . . . . . . . . . . 1095
Configure FortiGate A interfaces . . . . . . . . . . . . . . . . . . . . . . . . . 1095
Configure FortiGate A IPsec settings . . . . . . . . . . . . . . . . . . . . . . 1096
Configure FortiGate A firewall policies . . . . . . . . . . . . . . . . . . . . . . 1096
Configure FortiGate A routing . . . . . . . . . . . . . . . . . . . . . . . . . . 1097
Configure FortiGate B . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1097
L2TP and IPsec (Microsoft VPN) configurations 1105

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1105
Configuring the FortiGate unit . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1106
Configuring users and user group . . . . . . . . . . . . . . . . . . . . . . . . 1106
Configuring L2TP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1107
Configuring IPsec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1107
Configuring firewall policies . . . . . . . . . . . . . . . . . . . . . . . . . . . 1109
Configuring the Windows PC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1111
Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1112
Quick checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1112
Setting up logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1112
Understanding the log messages . . . . . . . . . . . . . . . . . . . . . . . . 1112
Using the FortiGate unit debug commands . . . . . . . . . . . . . . . . . . . 1113
FortiOS 4.0 MR2

46 01-420-99686-20101026
Detailed Contents
GRE over IPsec (Cisco VPN) configurations 1117

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1117
Configuring the FortiGate unit . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1118
Enabling overlapping subnets . . . . . . . . . . . . . . . . . . . . . . . . . . 1118
Configuring the IPsec VPN . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1118
Configuring the GRE tunnel . . . . . . . . . . . . . . . . . . . . . . . . . . . 1120
Configuring routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1122
Configuring the Cisco router . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1123
Quick checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1123
Setting up logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1124
Understanding the log messages . . . . . . . . . . . . . . . . . . . . . . . . 1124
Using diagnostic commands . . . . . . . . . . . . . . . . . . . . . . . . . . . 1124
Protecting OSPF with IPsec 1127

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1127
OSPF over IPsec configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . 1128
Configuring the IPsec VPN . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1128
Configuring static routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1129
Configuring OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1129
Creating a redundant configuration. . . . . . . . . . . . . . . . . . . . . . . . . . 1133
Adding the second IPsec tunnel . . . . . . . . . . . . . . . . . . . . . . . . . 1133
Adding the OSPF interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1133
Auto Key phase 1 parameters 1135

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1135
Defining the tunnel ends . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1136
Choosing main mode or aggressive mode . . . . . . . . . . . . . . . . . . . . . . 1136
Choosing the IKE version. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1137
Authenticating the FortiGate unit . . . . . . . . . . . . . . . . . . . . . . . . . . . 1137
Authenticating the FortiGate unit with digital certificates . . . . . . . . . . . . . 1137
Authenticating the FortiGate unit with a pre-shared key . . . . . . . . . . . . . 1138
Authenticating remote peers and clients . . . . . . . . . . . . . . . . . . . . . . . 1139
Enabling VPN access for specific certificate holders . . . . . . . . . . . . . . 1140
Enabling VPN access by peer identifier . . . . . . . . . . . . . . . . . . . . . 1142
Enabling VPN access using user accounts and pre-shared keys . . . . . . . . 1143
01-420-99686-20101026 47
Detailed Contents
Defining IKE negotiation parameters . . . . . . . . . . . . . . . . . . . . . . . . . 1144

Generating keys to authenticate an exchange . . . . . . . . . . . . . . . . . 1145
Defining IKE negotiation parameters . . . . . . . . . . . . . . . . . . . . . . . 1145
Defining the remaining phase 1 options . . . . . . . . . . . . . . . . . . . . . . . 1146
NAT traversal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1147
NAT keepalive frequency . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1147
Dead peer detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1147
Using XAuth authentication. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1148
Using the FortiGate unit as an XAuth server . . . . . . . . . . . . . . . . . . . 1148
Authenticating the FortiGate unit as a client with XAuth . . . . . . . . . . . . . 1149
Phase 2 parameters 1151

Basic phase 2 settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1151
Advanced phase 2 settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1151
P2 Proposal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1152
Replay detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1152
Perfect forward secrecy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1152
Keylife . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1152
Auto-negotiate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1152
Autokey Keep Alive. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1153
DHCP-IPsec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1153
Quick mode selectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1153
Configure the phase 2 parameters . . . . . . . . . . . . . . . . . . . . . . . . . . 1154
Specifying the phase 2 parameters . . . . . . . . . . . . . . . . . . . . . . . 1154
Defining firewall policies 1157

Defining firewall addresses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1157
Defining firewall policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1158
Defining an IPsec firewall policy for a policy-based VPN . . . . . . . . . . . . 1158
Defining firewall policies for a route-based VPN . . . . . . . . . . . . . . . . . 1161
Hardware offloading and acceleration 1163

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1163
IPsec session offloading requirements . . . . . . . . . . . . . . . . . . . . . . 1163
Packet requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1164
IPsec encryption offloading. . . . . . . . . . . . . . . . . . . . . . . . . . . . 1164
HMAC check offloading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1164
IPsec offloading configuration examples . . . . . . . . . . . . . . . . . . . . . . . 1165
Accelerated route-based VPN configuration . . . . . . . . . . . . . . . . . . . 1165
Accelerated policy-based VPN configuration. . . . . . . . . . . . . . . . . . . 1166
FortiOS 4.0 MR2

48 01-420-99686-20101026
Detailed Contents
Monitoring and troubleshooting VPNs 1169

Monitoring VPN connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1169
Monitoring connections to remote peers . . . . . . . . . . . . . . . . . . . . . 1169
Monitoring dialup IPsec connections . . . . . . . . . . . . . . . . . . . . . . . 1169
Monitoring IKE sessions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1171
Testing VPN connections. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1171
Logging VPN events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1171
VPN troubleshooting tips . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1173
A word about NAT devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1174
Chapter 9 SSL VPNs 1175
Introduction to SSL VPN 1177

History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1177
What is a VPN?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1178
What is SSL? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1178
Goals of SSL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1178
SSL certificates. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1180
Choosing the level of security for your SSL VPN tunnel . . . . . . . . . . . . . 1180
Choosing between SSL and IPsec VPN . . . . . . . . . . . . . . . . . . . . . . . 1180
Legacy versus web-enabled applications . . . . . . . . . . . . . . . . . . . . 1180
Authentication differences . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1181
Connectivity considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . 1181
Relative ease of use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1181
Client software requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . 1181
Access control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1181
Session failover support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1181
General topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1182
SSL VPN modes of operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1182
Web-only mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1183
Tunnel mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1183
Single Sign-on (SSO). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1184
Setting up the FortiGate unit 1185

Before you begin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1185
General configuration steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1186
01-420-99686-20101026 49
Detailed Contents
Configuring SSL VPN settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1186

Enabling SSL VPN operation. . . . . . . . . . . . . . . . . . . . . . . . . . . 1187
Specifying an IP address range for tunnel-mode clients . . . . . . . . . . . . 1187
Adding WINS and DNS services for clients . . . . . . . . . . . . . . . . . . . 1188
Setting the idle timeout setting . . . . . . . . . . . . . . . . . . . . . . . . . . 1189
Setting the client authentication timeout . . . . . . . . . . . . . . . . . . . . . 1189
Specifying the cipher suite for SSL negotiations . . . . . . . . . . . . . . . . 1189
Enabling strong authentication through X.509 security certificates . . . . . . . 1190
Changing the port number for web portal connections . . . . . . . . . . . . . 1191
Customizing the web portal login page . . . . . . . . . . . . . . . . . . . . . 1192
Configuring SSL VPN web portals . . . . . . . . . . . . . . . . . . . . . . . . . . 1193
Before you begin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1194
Configuring basic web portal settings . . . . . . . . . . . . . . . . . . . . . . 1196
Configuring tunnel mode settings . . . . . . . . . . . . . . . . . . . . . . . . 1199
Configuring the Session Information widget . . . . . . . . . . . . . . . . . . . 1202
Configuring the Bookmarks widget . . . . . . . . . . . . . . . . . . . . . . . . 1202
Configuring the Connection Tool widget . . . . . . . . . . . . . . . . . . . . . 1206
Configuring host checking . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1207
Configuring cache cleaning . . . . . . . . . . . . . . . . . . . . . . . . . . . 1209
Configuring virtual desktop . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1209
Configuring client OS Check . . . . . . . . . . . . . . . . . . . . . . . . . . . 1211
Configuring user accounts and user groups for SSL VPN . . . . . . . . . . . . . . 1212
Creating user accounts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1212
Creating a user group for SSL VPN users . . . . . . . . . . . . . . . . . . . . 1213
Configuring firewall policies. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1214
Configuring firewall addresses . . . . . . . . . . . . . . . . . . . . . . . . . . 1215
Configuring the SSL VPN firewall policy . . . . . . . . . . . . . . . . . . . . . 1216
Configuring the tunnel mode firewall policy . . . . . . . . . . . . . . . . . . . 1218
Adding an Internet browsing policy. . . . . . . . . . . . . . . . . . . . . . . . 1220
Enabling connection to an IPsec VPN . . . . . . . . . . . . . . . . . . . . . . 1221
Viewing SSL VPN logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1222
Monitoring active SSL VPN sessions. . . . . . . . . . . . . . . . . . . . . . . . . 1224
Working with the web portal 1227

Connecting to the FortiGate unit . . . . . . . . . . . . . . . . . . . . . . . . . . . 1227
Web portal overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1228
Applications available in the web portal . . . . . . . . . . . . . . . . . . . . . 1229
Using the Bookmarks widget . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1229
Adding bookmarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1230
Using the Connection Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1231
Tunnel-mode features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1237
FortiOS 4.0 MR2

50 01-420-99686-20101026
Detailed Contents
Using the SSL VPN Virtual Desktop . . . . . . . . . . . . . . . . . . . . . . . . . 1237
Using the SSL VPN tunnel client 1239

Client configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1239
Web mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1239
Tunnel mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1239
Virtual desktop application . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1240
Downloading the SSL VPN tunnel mode client . . . . . . . . . . . . . . . . . . . . 1240
Installing the tunnel mode client . . . . . . . . . . . . . . . . . . . . . . . . . . . 1241
Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1241
Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1241
MAC OS client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1241
Using the tunnel mode client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1242
Windows client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1242
Linux client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1244
MAC OS X client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1246
Uninstalling the tunnel mode client . . . . . . . . . . . . . . . . . . . . . . . . . . 1248
Examples 1249
Basic SSL VPN example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1249
Creating the firewall addresses . . . . . . . . . . . . . . . . . . . . . . . . . 1250
Enabling SSL VPN and setting the tunnel user IP address range . . . . . . . . 1251
Creating the web portal. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1251
Creating the user account and user group . . . . . . . . . . . . . . . . . . . . 1252
Creating the firewall policies . . . . . . . . . . . . . . . . . . . . . . . . . . . 1253
Add routing to tunnel mode clients . . . . . . . . . . . . . . . . . . . . . . . . 1254
Multiple user groups with different access permissions example . . . . . . . . . . 1255
Creating the firewall addresses . . . . . . . . . . . . . . . . . . . . . . . . . 1256
Creating the web portals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1257
Creating the user accounts and user groups. . . . . . . . . . . . . . . . . . . 1258
Creating the firewall policies . . . . . . . . . . . . . . . . . . . . . . . . . . . 1259
Create the static route to tunnel mode clients . . . . . . . . . . . . . . . . . . 1262
Enabling SSL VPN operation. . . . . . . . . . . . . . . . . . . . . . . . . . . 1262
OS patch check example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1263
01-420-99686-20101026 51
Detailed Contents
Chapter 10 Advanced Routing 1265
Advanced Static routing 1267

Routing concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1267
Routing in VDOMs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1267
Default route . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1268
Routing table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1268
Building the routing table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1274
Static routing security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1274
Multipath routing and determining the best route . . . . . . . . . . . . . . . . 1276
Route priority . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1277
Troubleshooting static routing . . . . . . . . . . . . . . . . . . . . . . . . . . 1278
ECMP route failover and load balancing . . . . . . . . . . . . . . . . . . . . . . . 1280
Route priority . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1280
Equal-Cost Multi-Path (ECMP) . . . . . . . . . . . . . . . . . . . . . . . . . . 1281
Configuring spill-over or usage-based ECMP . . . . . . . . . . . . . . . . . . 1282
Configuring weighted static route load balancing . . . . . . . . . . . . . . . . 1284
Static routing tips . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1285
Policy Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1286
Adding a policy route . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1286
Moving a policy route. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1288
Transparent mode static routing . . . . . . . . . . . . . . . . . . . . . . . . . . . 1289
Zones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1289
Creating or editing a zone . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1290
Blocking intra-zone traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1290
IP pools and zones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1291
Zones in VDOMs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1291
Zones in transparent mode. . . . . . . . . . . . . . . . . . . . . . . . . . . . 1291
Dynamic Routing Overview 1293

What is dynamic routing?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1293
Comparing static and dynamic routing . . . . . . . . . . . . . . . . . . . . . . 1293
Dynamic routing protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1294
Minimum configuration for dynamic routing . . . . . . . . . . . . . . . . . . . 1296
Comparison of dynamic routing protocols . . . . . . . . . . . . . . . . . . . . . . 1296
Features of dynamic routing protocols . . . . . . . . . . . . . . . . . . . . . . 1296
When to adopt dynamic routing . . . . . . . . . . . . . . . . . . . . . . . . . 1299
Choosing a routing protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . 1301
Dynamic routing terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1302
IPv6 in dynamic routing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1307
FortiOS 4.0 MR2

52 01-420-99686-20101026
Detailed Contents
Routing Information Protocol (RIP) 1309

RIP background and concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1309
Background. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1309
Parts and terminology of RIP. . . . . . . . . . . . . . . . . . . . . . . . . . . 1310
How RIP works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1315
Troubleshooting RIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1320
Routing Loops . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1320
Split horizon and Poison reverse updates . . . . . . . . . . . . . . . . . . . . 1323
Debugging IPv6 on RIPng . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1323
RIP routing examples. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1324
Simple RIP example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1324
Network layout and assumptions. . . . . . . . . . . . . . . . . . . . . . . . . 1324
Configuring the FortiGate units system information . . . . . . . . . . . . . . . 1326
Configuring FortiGate unit RIP router information . . . . . . . . . . . . . . . . 1334
Configuring other networking devices . . . . . . . . . . . . . . . . . . . . . . 1337
Testing network configuration . . . . . . . . . . . . . . . . . . . . . . . . . . 1338
RIPng — RIP and IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1338
Configuring the FortiGate units system information . . . . . . . . . . . . . . . 1340
Configuring RIPng on FortiGate units . . . . . . . . . . . . . . . . . . . . . . 1342
Configuring other network devices . . . . . . . . . . . . . . . . . . . . . . . . 1343
Testing the configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1343
Border Gateway Protocol (BGP) 1347

BGP background and concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . 1347
Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1347
Parts and terminology of BGP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1347
BGP and IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1348
Roles of routers in BGP networks . . . . . . . . . . . . . . . . . . . . . . . . 1349
Confederations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1352
Network Layer Reachability Information (NLRI) . . . . . . . . . . . . . . . . . 1353
BGP attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1354
How BGP works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1357
IBGP versus EBGP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1357
BGP path determination — which route to use. . . . . . . . . . . . . . . . . . 1357
Troubleshooting BGP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1360
Clearing routing table entries. . . . . . . . . . . . . . . . . . . . . . . . . . . 1360
Route flap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1360
01-420-99686-20101026 53
Detailed Contents
BGP routing examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1364

Dual-homed BGP example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1364
Configuring the FortiGate unit . . . . . . . . . . . . . . . . . . . . . . . . . . 1368
Testing this configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1376
Redistributing and blocking routes in BGP . . . . . . . . . . . . . . . . . . . . . . 1378
Open Shortest Path First (OSPF) 1385

OSPF Background and concepts. . . . . . . . . . . . . . . . . . . . . . . . . . . 1385
Background. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1385
The parts and terminology of OSPF . . . . . . . . . . . . . . . . . . . . . . . 1385
How OSPF works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1391
Troubleshooting OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1396
Clearing OSPF routes from the routing table. . . . . . . . . . . . . . . . . . . 1396
Checking the state of OSPF neighbors . . . . . . . . . . . . . . . . . . . . . 1396
Passive interface problems. . . . . . . . . . . . . . . . . . . . . . . . . . . . 1396
Timer problems. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1397
Bi-directional Forwarding Detection (BFD) . . . . . . . . . . . . . . . . . . . . 1397
Authentication issues. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1397
DR and BDR election issues . . . . . . . . . . . . . . . . . . . . . . . . . . . 1398
OSPF routing examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1398
Basic OSPF example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1398
Configuring the FortiGate units. . . . . . . . . . . . . . . . . . . . . . . . . . 1401
Configuring OSPF on the FortiGate units . . . . . . . . . . . . . . . . . . . . 1403
Advanced inter-area OSPF example . . . . . . . . . . . . . . . . . . . . . . . . . 1411
Configuring the FortiGate units. . . . . . . . . . . . . . . . . . . . . . . . . . 1413
Configuring OSPF on the FortiGate units . . . . . . . . . . . . . . . . . . . . 1417
FortiOS 4.0 MR2

54 01-420-99686-20101026
Detailed Contents
Chapter 11 Virtual Domains 1423
Virtual Domains 1425

Before you begin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1425
Benefits of Virtual Domains. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1425
Improving Transparent mode configuration . . . . . . . . . . . . . . . . . . . 1426
Easier administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1426
Continued security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1426
Savings in physical space and power . . . . . . . . . . . . . . . . . . . . . . 1427
More flexible MSSP configurations. . . . . . . . . . . . . . . . . . . . . . . . 1427
Enabling and accessing Virtual Domains. . . . . . . . . . . . . . . . . . . . . . . 1427
Enabling Virtual Domains . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1428
Viewing the VDOM list . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1430
Global and per-VDOM settings. . . . . . . . . . . . . . . . . . . . . . . . . . 1431
Resource settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1439
Virtual Domain Licensing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1442
Logging in to VDOMs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1444
Configuring Virtual Domains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1446
Creating a Virtual Domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1446
Disabling a Virtual Domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1447
Deleting a VDOM. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1448
Removing references to a VDOM . . . . . . . . . . . . . . . . . . . . . . . . 1448
Administrators in Virtual Domains . . . . . . . . . . . . . . . . . . . . . . . . 1449
Virtual Domains in NAT/Route mode 1453

Virtual domains in NAT/Route mode . . . . . . . . . . . . . . . . . . . . . . . . . 1453
Changing the management virtual domain . . . . . . . . . . . . . . . . . . . . 1453
Configuring interfaces in a NAT/Route VDOM . . . . . . . . . . . . . . . . . . 1454
Configuring VDOM routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1457
Configuring firewall policies for NAT/Route VDOMs . . . . . . . . . . . . . . . 1459
Configuring UTM profiles for NAT/Route VDOMs . . . . . . . . . . . . . . . . 1460
WAN Optimization using VDOMs. . . . . . . . . . . . . . . . . . . . . . . . . . . 1460
Example NAT/Route VDOM configuration . . . . . . . . . . . . . . . . . . . . . . 1461
Network topology and assumptions . . . . . . . . . . . . . . . . . . . . . . . 1461
Creating the VDOMs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1462
Configuring the FortiGate interfaces . . . . . . . . . . . . . . . . . . . . . . . 1463
Configuring the vdomA VDOM . . . . . . . . . . . . . . . . . . . . . . . . . . 1465
Configuring the vdomB VDOM . . . . . . . . . . . . . . . . . . . . . . . . . . 1467
01-420-99686-20101026 55
Detailed Contents
Virtual Domains in Transparent mode 1471

Before you begin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1471
Transparent operation mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1471
Broadcast domains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1472
Forwarding domains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1472
Spanning Tree Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1473
Differences between NAT/Route and Transparent mode . . . . . . . . . . . . 1473
Operation mode differences in VDOMs . . . . . . . . . . . . . . . . . . . . . . . 1474
Configuring VDOMs in Transparent mode . . . . . . . . . . . . . . . . . . . . . . 1475
Switching to Transparent mode . . . . . . . . . . . . . . . . . . . . . . . . . 1475
Adding VLAN subinterfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . 1476
Creating firewall policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1476
Example of VDOMs in Transparent mode . . . . . . . . . . . . . . . . . . . . . . 1476
Configuring common items . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1478
Creating virtual domains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1478
Configuring the Company_A VDOM . . . . . . . . . . . . . . . . . . . . . . . 1479
Configuring the Company_B VDOM . . . . . . . . . . . . . . . . . . . . . . . 1483
Configuring the VLAN switch and router . . . . . . . . . . . . . . . . . . . . . 1487
Inter-VDOM routing 1491

Benefits of inter-VDOM routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1491
Freed-up physical interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . 1491
More speed than physical interfaces . . . . . . . . . . . . . . . . . . . . . . . 1492
Continued support for secure firewall policies . . . . . . . . . . . . . . . . . . 1492
Configuration flexibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1492
Getting started with VDOM links . . . . . . . . . . . . . . . . . . . . . . . . . . . 1493
Viewing VDOM links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1493
Creating VDOM links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1494
Deleting VDOM links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1496
Inter-VDOM configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1496
Standalone VDOM configuration . . . . . . . . . . . . . . . . . . . . . . . . . 1497
Independent VDOMs configuration. . . . . . . . . . . . . . . . . . . . . . . . 1497
Management VDOM configuration . . . . . . . . . . . . . . . . . . . . . . . . 1498
Meshed VDOM configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . 1499
Dynamic routing over inter-VDOM links . . . . . . . . . . . . . . . . . . . . . . . 1500
HA virtual clusters and VDOM links . . . . . . . . . . . . . . . . . . . . . . . . . 1501
What is virtual clustering? . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1501
FortiOS 4.0 MR2

56 01-420-99686-20101026
Detailed Contents
Example of inter-VDOM routing . . . . . . . . . . . . . . . . . . . . . . . . . . . 1503

Creating the VDOMs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1504
Configuring the physical interfaces. . . . . . . . . . . . . . . . . . . . . . . . 1505
Configuring the VDOM links . . . . . . . . . . . . . . . . . . . . . . . . . . . 1506
Configuring the firewall and UTM settings . . . . . . . . . . . . . . . . . . . . 1508
Troubleshooting Virtual Domains 1527

VDOM admin having problems gaining access . . . . . . . . . . . . . . . . . . . 1527
Confirm the admin’s VDOM . . . . . . . . . . . . . . . . . . . . . . . . . . . 1527
Confirm the VDOM’s interfaces . . . . . . . . . . . . . . . . . . . . . . . . . 1527
Confirm the VDOMs admin access. . . . . . . . . . . . . . . . . . . . . . . . 1527
FortiGate unit running very slowly . . . . . . . . . . . . . . . . . . . . . . . . . . 1527
Too many VDOMs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1528
One or more VDOMs are consuming all the resources . . . . . . . . . . . . . 1528
Too many UTM features in use . . . . . . . . . . . . . . . . . . . . . . . . . 1528
General VDOM tips and troubleshooting . . . . . . . . . . . . . . . . . . . . . . . 1528
Perform a sniffer trace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1528
Debug the packet flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1530
Chapter 12 High Availability 1533
Solving the High Availability problem 1537

FortiGate Cluster Protocol (FGCP) . . . . . . . . . . . . . . . . . . . . . . . . . . 1537
TCP session synchronization. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1538
VRRP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1538
An introduction to the FortiGate Clustering Protocol (FGCP) 1541

About the FGCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1541
FGCP failover protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1543
Session Failover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1543
Load Balancing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1543
Virtual Clustering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1543
Full Mesh HA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1543
Cluster Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1544
Configuring a FortiGate unit for FGCP HA operation. . . . . . . . . . . . . . . . . 1544
Connecting a FortiGate HA cluster . . . . . . . . . . . . . . . . . . . . . . . . 1546
01-420-99686-20101026 57
Detailed Contents
Active-passive and active-active HA . . . . . . . . . . . . . . . . . . . . . . . . . 1547

Active-passive HA (failover protection). . . . . . . . . . . . . . . . . . . . . . 1547
Active-active HA (load balancing and failover protection) . . . . . . . . . . . . 1548
Identifying the cluster and cluster units . . . . . . . . . . . . . . . . . . . . . . . . 1548
Group name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1549
Password . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1549
Group ID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1549
Device failover, link failover, and session failover . . . . . . . . . . . . . . . . . . 1549
Primary unit selection. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1550
Primary unit selection and monitored interfaces . . . . . . . . . . . . . . . . . 1551
Primary unit selection and age . . . . . . . . . . . . . . . . . . . . . . . . . . 1552
Primary unit selection and device priority . . . . . . . . . . . . . . . . . . . . 1554
Primary unit selection and FortiGate unit serial number . . . . . . . . . . . . . 1556
Points to remember about primary unit selection . . . . . . . . . . . . . . . . 1556
HA override . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1556
Override and primary unit selection . . . . . . . . . . . . . . . . . . . . . . . 1557
Controlling primary unit selection using device priority and override. . . . . . . 1558
Points to remember about primary unit selection when override is enabled . . . 1559
Configuration changes can be lost if override is enabled . . . . . . . . . . . . 1559
Override and disconnecting a unit from a cluster . . . . . . . . . . . . . . . . 1560
FortiGate HA compatibility with PPPoE and DHCP . . . . . . . . . . . . . . . . . 1560
Hard disk configuration and HA . . . . . . . . . . . . . . . . . . . . . . . . . . . 1560
Recommended practices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1561
Heartbeat interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1561
Interface monitoring (port monitoring) . . . . . . . . . . . . . . . . . . . . . . 1562
Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1562
FGCP HA terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1562
Configuring and connecting HA clusters 1567

About the procedures in this chapter . . . . . . . . . . . . . . . . . . . . . . . . . 1567
Example: NAT/Route mode active-passive HA configuration . . . . . . . . . . . . 1567
Example NAT/Route mode HA network topology . . . . . . . . . . . . . . . . 1568
Configuring a NAT/Route mode active-passive cluster of two
FortiGate-620B units - web-based manager . . . . . . . . . . . . . . . . . . . 1569
Configuring a NAT/Route mode active-passive cluster of two
FortiGate-620B units - CLI . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1573
FortiOS 4.0 MR2

58 01-420-99686-20101026
Detailed Contents
Example: Transparent mode active-active HA configuration . . . . . . . . . . . . . 1578

Example Transparent mode HA network topology . . . . . . . . . . . . . . . . 1579
Configuring a Transparent mode active-active cluster of two
FortiGate-620B units - web-based manager . . . . . . . . . . . . . . . . . . . 1580
Configuring a Transparent mode active-active cluster of two
FortiGate-620B units - CLI . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1585
Example: advanced Transparent mode active-active HA configuration . . . . . . . 1591
Example Transparent mode HA network topology . . . . . . . . . . . . . . . . 1591
Configuring a Transparent mode active-active cluster of three
FortiGate-5005FA2 units - web-based manager . . . . . . . . . . . . . . . . . 1591
Configuring a Transparent mode active-active cluster of three
FortiGate-5005FA2 units - CLI . . . . . . . . . . . . . . . . . . . . . . . . . . 1594
Example: converting a standalone FortiGate unit to a cluster . . . . . . . . . . . . 1598
Example: adding a new unit to an operating cluster . . . . . . . . . . . . . . . . . 1600
Example: replacing a failed cluster unit. . . . . . . . . . . . . . . . . . . . . . . . 1601
Example: HA and 802.3ad aggregated interfaces . . . . . . . . . . . . . . . . . . 1602
HA interface monitoring, link failover, and 802.3ad aggregation . . . . . . . . . 1602
HA MAC addresses and 802.3ad aggregation . . . . . . . . . . . . . . . . . . 1602
Link aggregation, HA failover performance, and HA mode . . . . . . . . . . . 1603
Configuring active-passive HA cluster that includes aggregated
interfaces - web-based manager . . . . . . . . . . . . . . . . . . . . . . . . . 1604
Configuring active-passive HA cluster that includes aggregate
interfaces - CLI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1608
Example: HA and redundant interfaces . . . . . . . . . . . . . . . . . . . . . . . 1613
HA interface monitoring, link failover, and redundant interfaces . . . . . . . . . 1614
HA MAC addresses and redundant interfaces . . . . . . . . . . . . . . . . . . 1614
Connecting multiple redundant interfaces to one switch while
operating in active-passive HA mode . . . . . . . . . . . . . . . . . . . . . . 1614
Connecting multiple redundant interfaces to one switch while
operating in active-active HA mode . . . . . . . . . . . . . . . . . . . . . . . 1614
Configuring active-passive HA cluster that includes redundant
interfaces - web-based manager . . . . . . . . . . . . . . . . . . . . . . . . . 1615
Configuring active-passive HA cluster that includes redundant
interfaces - CLI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1619
Troubleshooting HA clusters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1624
Before you set up a cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1624
Troubleshooting the initial cluster configuration . . . . . . . . . . . . . . . . . 1624
More troubleshooting information . . . . . . . . . . . . . . . . . . . . . . . . 1626
01-420-99686-20101026 59
Detailed Contents
Configuring and connecting virtual clusters 1629

Virtual clustering overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1629
Virtual clustering and failover protection . . . . . . . . . . . . . . . . . . . . . 1629
Virtual clustering and heartbeat interfaces . . . . . . . . . . . . . . . . . . . . 1630
Virtual clustering and HA override . . . . . . . . . . . . . . . . . . . . . . . . 1630
Virtual clustering and load balancing or VDOM partitioning . . . . . . . . . . . 1631
Configuring HA for virtual clustering . . . . . . . . . . . . . . . . . . . . . . . . . 1631
Example: virtual clustering with two VDOMs and VDOM partitioning . . . . . . . . 1633
Example virtual clustering network topology . . . . . . . . . . . . . . . . . . . 1633
Configuring virtual clustering with two VDOMs and VDOM
partitioning - web-based manager . . . . . . . . . . . . . . . . . . . . . . . . 1635
Configuring virtual clustering with two VDOMs and VDOM
partitioning - CLI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1639
Example: inter-VDOM links in a virtual clustering configuration . . . . . . . . . . . 1646
Configuring inter-VDOM links in a virtual clustering configuration . . . . . . . . 1647
Troubleshooting virtual clustering . . . . . . . . . . . . . . . . . . . . . . . . . . 1648
Configuring and operating FortiGate full mesh HA 1651

Full mesh HA overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1651
Full mesh HA and redundant heartbeat interfaces . . . . . . . . . . . . . . . . 1652
Full mesh HA, redundant interfaces and 802.3ad aggregate interfaces . . . . . 1653
Example: full mesh HA configuration . . . . . . . . . . . . . . . . . . . . . . . . . 1653
FortiGate-620B full mesh HA configuration . . . . . . . . . . . . . . . . . . . 1654
Full mesh switch configuration . . . . . . . . . . . . . . . . . . . . . . . . . . 1654
Full mesh network connections . . . . . . . . . . . . . . . . . . . . . . . . . 1654
How packets travel from the internal network through the full mesh
cluster and to the Internet . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1655
Configuring FortiGate-620B units for HA operation - web-based manager . . . 1655
Configuring FortiGate-620B units for HA operation - CLI . . . . . . . . . . . . 1659
Troubleshooting full mesh HA . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1663
Operating a cluster 1665

Operating a cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1665
Operating a virtual cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1666
Managing individual cluster units using a reserved management interface . . . . . 1667
Configuring the reserved management interface and SNMP remote
management of individual cluster units. . . . . . . . . . . . . . . . . . . . . . 1668
The primary unit acts as a router for subordinate unit management traffic. . . . . . 1672
Cluster communication with RADIUS and LDAP servers . . . . . . . . . . . . 1673
FortiOS 4.0 MR2

60 01-420-99686-20101026
Detailed Contents
Clusters and FortiGuard services. . . . . . . . . . . . . . . . . . . . . . . . . . . 1673

FortiGuard and active-passive clusters . . . . . . . . . . . . . . . . . . . . . 1673
FortiGuard and active-active clusters . . . . . . . . . . . . . . . . . . . . . . 1673
FortiGuard and virtual clustering . . . . . . . . . . . . . . . . . . . . . . . . . 1674
Clusters and logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1674
Viewing and managing log messages for individual cluster units . . . . . . . . 1674
HA log messages. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1676
Example log messages. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1676
Fortigate HA message "HA master heartbeat interface <intf_name>
lost neighbor information" . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1679
Clusters and SNMP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1681
SNMP get command syntax for the primary unit . . . . . . . . . . . . . . . . . 1681
SNMP get command syntax for any cluster unit . . . . . . . . . . . . . . . . . 1682
Getting serial numbers of cluster units . . . . . . . . . . . . . . . . . . . . . . 1683
SNMP get command syntax - reserved management interface enabled . . . . 1684
Clusters and file quarantine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1684
Cluster members list . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1685
Virtual cluster members list . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1686
Viewing HA statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1687
Changing the HA configuration of an operating cluster. . . . . . . . . . . . . . . . 1688
Changing the HA configuration of an operating virtual cluster . . . . . . . . . . . . 1689
Changing the subordinate unit host name and device priority . . . . . . . . . . . . 1689
Upgrading cluster firmware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1690
Changing how the cluster processes firmware upgrades . . . . . . . . . . . . 1690
Synchronizing the firmware build running on a new cluster unit . . . . . . . . . 1691
Downgrading cluster firmware . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1691
Backing up and restoring the cluster configuration . . . . . . . . . . . . . . . . . . 1692
Monitoring cluster units for failover . . . . . . . . . . . . . . . . . . . . . . . . . . 1693
Viewing cluster status from the CLI. . . . . . . . . . . . . . . . . . . . . . . . . . 1693
Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1695
About the HA cluster index and the execute ha manage command . . . . . . . 1698
Managing individual cluster units. . . . . . . . . . . . . . . . . . . . . . . . . 1700
Disconnecting a cluster unit from a cluster . . . . . . . . . . . . . . . . . . . . . . 1701
Adding a disconnected FortiGate unit back to its cluster . . . . . . . . . . . . . . . 1702
01-420-99686-20101026 61
Detailed Contents
HA and failover protection 1705

About active-passive failover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1706
Device failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1706
Link failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1706
Session failover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1706
Primary unit recovery. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1707
About active-active failover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1707
Device failover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1707
HA heartbeat and communication between cluster units . . . . . . . . . . . . . . . 1708
Heartbeat interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1709
Connecting HA heartbeat interfaces . . . . . . . . . . . . . . . . . . . . . . . 1710
Heartbeat interfaces and FortiGate switch interfaces . . . . . . . . . . . . . . 1710
Heartbeat packets and heartbeat interface selection . . . . . . . . . . . . . . 1710
Interface index and display order. . . . . . . . . . . . . . . . . . . . . . . . . 1711
HA heartbeat interface IP addresses. . . . . . . . . . . . . . . . . . . . . . . 1711
Heartbeat packet Ethertypes . . . . . . . . . . . . . . . . . . . . . . . . . . . 1712
Modifying heartbeat timing . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1713
Enabling or disabling HA heartbeat encryption and authentication . . . . . . . 1715
Cluster virtual MAC addresses . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1715
Changing how the primary unit sends gratuitous ARP packets
after a failover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1716
How the virtual MAC address is determined . . . . . . . . . . . . . . . . . . . 1717
Displaying the virtual MAC address . . . . . . . . . . . . . . . . . . . . . . . 1718
Diagnosing packet loss with two FortiGate HA clusters in the
same broadcast domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1720
Synchronizing the configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . 1721
Disabling automatic configuration synchronization. . . . . . . . . . . . . . . . 1721
Incremental synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . 1722
Periodic synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1723
Console messages when configuration synchronization succeeds . . . . . . . 1723
Console messages when configuration synchronization fails . . . . . . . . . . 1724
Comparing checksums of cluster units . . . . . . . . . . . . . . . . . . . . . . 1725
How to diagnose HA out of sync messages . . . . . . . . . . . . . . . . . . . 1726
Synchronizing routing table updates . . . . . . . . . . . . . . . . . . . . . . . . . 1728
Configuring graceful restart for dynamic routing failover . . . . . . . . . . . . . 1728
Controlling how the FGCP synchronizes routing updates . . . . . . . . . . . . 1729
Synchronizing IPsec VPN SAs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1730
FortiOS 4.0 MR2

62 01-420-99686-20101026
Detailed Contents
Link failover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1731

If a monitored interface on the primary unit fails . . . . . . . . . . . . . . . . . 1733
If a monitored interface on a subordinate unit fails . . . . . . . . . . . . . . . . 1733
How link failover maintains traffic flow . . . . . . . . . . . . . . . . . . . . . . 1734
Recovery after a link failover . . . . . . . . . . . . . . . . . . . . . . . . . . . 1735
Testing link failover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1735
Updating MAC forwarding tables when a link failover occurs . . . . . . . . . . 1735
Multiple link failures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1736
Example link failover scenarios . . . . . . . . . . . . . . . . . . . . . . . . . 1736
Remote link failover. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1737
Ping server priority and the failover threshold . . . . . . . . . . . . . . . . . . 1739
Flip timeout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1739
Detecting HA remote IP monitoring failovers. . . . . . . . . . . . . . . . . . . 1740
Session failover (session pick-up) . . . . . . . . . . . . . . . . . . . . . . . . . . 1740
Session failover not supported for all sessions. . . . . . . . . . . . . . . . . . 1741
SIP session failover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1742
Session failover and explicit web proxy, WCCP, and WAN
optimization sessions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1742
Session failover and SSL offloading and HTTP multiplexing. . . . . . . . . . . 1742
IPsec VPN and SSL VPN sessions . . . . . . . . . . . . . . . . . . . . . . . 1742
PPTP and L2TP VPN sessions . . . . . . . . . . . . . . . . . . . . . . . . . 1742
Session failover and UDP, ICMP, multicast and broadcast packets . . . . . . . 1742
FortiOS Carrier GTP session failover . . . . . . . . . . . . . . . . . . . . . . 1743
Active-active HA subordinate units sessions can resume after a
failover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1743
Subsecond failover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1744
Subsecond failover and cluster firmware upgrades . . . . . . . . . . . . . . . 1744
WAN optimization and HA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1744
Failover and attached network equipment . . . . . . . . . . . . . . . . . . . . . . 1745
Monitoring cluster units for failover . . . . . . . . . . . . . . . . . . . . . . . . . . 1745
NAT/Route mode active-passive cluster packet flow . . . . . . . . . . . . . . . . . 1745
Packet flow from client to web server . . . . . . . . . . . . . . . . . . . . . . 1746
Packet flow from web server to client . . . . . . . . . . . . . . . . . . . . . . 1746
When a failover occurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1747
Transparent mode active-passive cluster packet flow . . . . . . . . . . . . . . . . 1747
Packet flow from client to mail server . . . . . . . . . . . . . . . . . . . . . . 1748
Packet flow from mail server to client . . . . . . . . . . . . . . . . . . . . . . 1748
Failover performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1750
Device failover performance . . . . . . . . . . . . . . . . . . . . . . . . . . . 1750
Link failover performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1750
Reducing failover times . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1750
01-420-99686-20101026 63
Detailed Contents
HA and load balancing 1753

Load balancing overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1753
Load balancing schedules . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1754
Selecting which packets are load balanced . . . . . . . . . . . . . . . . . . . 1755
More about active-active failover . . . . . . . . . . . . . . . . . . . . . . . . . 1755
HTTPS sessions, active-active load balancing, and proxy servers . . . . . . . 1755
Using FortiGate network processor interfaces to accelerate
active-active HA performance . . . . . . . . . . . . . . . . . . . . . . . . . . 1756
Configuring load balancing settings . . . . . . . . . . . . . . . . . . . . . . . . . 1757
Selecting a load balancing schedule . . . . . . . . . . . . . . . . . . . . . . . 1757
Load balancing UTM sessions and TCP sessions . . . . . . . . . . . . . . . . 1757
Configuring weighted-round-robin weights . . . . . . . . . . . . . . . . . . . . 1758
NAT/Route mode active-active cluster packet flow. . . . . . . . . . . . . . . . . . 1759
Packet flow from client to web server . . . . . . . . . . . . . . . . . . . . . . 1760
Packet flow from web server to client . . . . . . . . . . . . . . . . . . . . . . 1761
Transparent mode active-active cluster packet flow . . . . . . . . . . . . . . . . . 1762
Packet flow from client to mail server . . . . . . . . . . . . . . . . . . . . . . 1763
Packet flow from mail server to client . . . . . . . . . . . . . . . . . . . . . . 1764
HA with third-party products 1767

Troubleshooting layer-2 switches. . . . . . . . . . . . . . . . . . . . . . . . . . . 1767
Forwarding delay on layer 2 switches . . . . . . . . . . . . . . . . . . . . . . 1768
Failover issues with layer-3 switches . . . . . . . . . . . . . . . . . . . . . . . . . 1768
Changing spanning tree protocol settings for some switches . . . . . . . . . . . . 1768
Spanning Tree protocol (STP) . . . . . . . . . . . . . . . . . . . . . . . . . . 1769
Bridge Protocol Data Unit (BPDU) . . . . . . . . . . . . . . . . . . . . . . . . 1769
Failover and attached network equipment . . . . . . . . . . . . . . . . . . . . . . 1769
Ethertype conflicts with third-party switches . . . . . . . . . . . . . . . . . . . . . 1769
LACP, 802.3ad aggregation and third-party switches . . . . . . . . . . . . . . . . 1770
VRRP 1771
Configuring VRRP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1772
Example VRRP configuration: two FortiGate units in a VRRP group . . . . . . 1772
Example VRRP configuration: VRRP load balancing two FortiGate
units and two VRRP groups . . . . . . . . . . . . . . . . . . . . . . . . . . . 1773
Optional VRRP configuration settings . . . . . . . . . . . . . . . . . . . . . . 1775
FortiOS 4.0 MR2

64 01-420-99686-20101026
Detailed Contents
TCP session synchronization 1777

Notes and limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1778
Configuring session synchronization . . . . . . . . . . . . . . . . . . . . . . . . . 1778
Configuring the session synchronization link . . . . . . . . . . . . . . . . . . . . . 1779
Basic example configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1780
Chapter 13 Endpoint 1783
Network Access Control and monitoring 1785

NAC overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1785
User experience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1785
Configuration overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1787
Configuring FortiClient required version and download location . . . . . . . . . . . 1788
Configuring application detection and control . . . . . . . . . . . . . . . . . . . . 1789
Configuring application sensors . . . . . . . . . . . . . . . . . . . . . . . . . 1789
Viewing the application database . . . . . . . . . . . . . . . . . . . . . . . . 1791
Configuring Endpoint profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1792
Enabling Endpoint NAC in firewall policies . . . . . . . . . . . . . . . . . . . . . . 1793
Monitoring endpoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1794
Viewing details about the endpoint . . . . . . . . . . . . . . . . . . . . . . . . 1795
Modifying Endpoint NAC replacement pages . . . . . . . . . . . . . . . . . . . . 1795
Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1796
Configuring FortiClient download source and required version . . . . . . . . . 1796
Configuring an application sensor . . . . . . . . . . . . . . . . . . . . . . . . 1796
Configuring an endpoint profile. . . . . . . . . . . . . . . . . . . . . . . . . . 1798
Configuring the firewall policy . . . . . . . . . . . . . . . . . . . . . . . . . . 1798
Network Vulnerability Scan 1801

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1801
Selecting assets to scan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1801
Discovering assets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1801
Adding assets manually . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1803
Configuring scans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1804
01-420-99686-20101026 65
Detailed Contents
Viewing scan results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1806

Viewing scan logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1806
Viewing Executive Summary graphs . . . . . . . . . . . . . . . . . . . . . . . 1807
Creating reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1807
Viewing reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1808
Chapter 14 Traffic Shaping 1809
The purpose of traffic shaping 1811

Quality of Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1811
Traffic policing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1812
Bandwidth guarantee, limit, and priority interactions . . . . . . . . . . . . . . . . . 1813
FortiGate traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1814
Through traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1814
Important considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1818
Traffic shaping methods 1821

Traffic shaping options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1821
Shared policy shaping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1821
Per policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1822
All policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1822
Maximum and guaranteed bandwidth . . . . . . . . . . . . . . . . . . . . . . 1822
Traffic priority . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1822
VLAN, VDOM and virtual interfaces . . . . . . . . . . . . . . . . . . . . . . . 1823
Per-IP shaping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1823
Application control shaping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1824
Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1824
Shaping order of operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1825
Enabling in the firewall policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1825
Reverse direction traffic shaping . . . . . . . . . . . . . . . . . . . . . . . . . 1826
Application control shaper . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1826
Type of Service priority . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1826
TOS in FortiOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1827
Differentiated Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1827
DSCP examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1828
Tos and DSCP mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1832
FortiOS 4.0 MR2

66 01-420-99686-20101026
Detailed Contents
Examples 1833
QoS using priority from firewall policies . . . . . . . . . . . . . . . . . . . . . . . 1833
Sample configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1834
QoS using priority from ToS or differentiated services . . . . . . . . . . . . . . . . 1835
Sample configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1836
Example setup for VoIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1836
Creating the traffic shapers. . . . . . . . . . . . . . . . . . . . . . . . . . . . 1837
Creating firewall policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1838
Interface diagnosis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1841
Shaper diagnose commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1841
TOS command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1841
Shared shaper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1842
Per-IP shaper. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1842
Packet loss with statistics on shapers . . . . . . . . . . . . . . . . . . . . . . 1843
Packet lost with the debug flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . 1843
Session list details with dual traffic shaper . . . . . . . . . . . . . . . . . . . . . . 1843
Additional Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1844
Chapter 15 FortiOS Carrier 1845
Overview of FortiOS Carrier features 1849

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1849
Dynamic profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1849
MMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1849
GTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1850
MMS background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1850
MMS content interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1850
How MMS content interfaces are applied . . . . . . . . . . . . . . . . . . . . 1851
How FortiOS Carrier processes MMS messages . . . . . . . . . . . . . . . . . . 1853
FortiOS Carrier and MMS content scanning . . . . . . . . . . . . . . . . . . . 1854
FortiOS Carrier and MMS duplicate messages and message floods . . . . . . 1859
MMS protection profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1861
Bypassing MMS protection profile filtering based on user’s carrier end points . . . . 1862
Applying MMS protection profiles to MMS traffic . . . . . . . . . . . . . . . . . . . 1862
GTP basic concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1862
GPRS security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1863
01-420-99686-20101026 67
Detailed Contents
Parts of a GPRS network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1863

Radio access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1864
Transport . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1864
Billing and records . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1865
PDP Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1866
GPRS network common interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . 1868
Packet flow through the GPRS network . . . . . . . . . . . . . . . . . . . . . . . 1869
Dynamic profiles and profile groups 1871

Dynamic profile and RADIUS-based accounting systems . . . . . . . . . . . . . . 1871
About carrier end points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1872
Dynamic profiles and firewall policies . . . . . . . . . . . . . . . . . . . . . . 1872
Accounting system RADIUS configuration . . . . . . . . . . . . . . . . . . . . 1872
About the user context list . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1873
Accepting sessions from dynamic profile users only . . . . . . . . . . . . . . . 1874
Configuring the dynamic profile . . . . . . . . . . . . . . . . . . . . . . . . . 1875
Example: Parental control dynamic profile group configuration . . . . . . . . . 1879
THTTP header options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1883
How FortiOS Carrier applies HTTP header options . . . . . . . . . . . . . . . 1884
Configuring carrier end point HTTP header options . . . . . . . . . . . . . . . 1885
Example: How FortiOS Carrier applies carrier end point prefix options . . . . . 1886
Cookie Override configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1887
MMS Carrier End Point features 1889

Controlling access to MMS services based on a user’s carrier end point . . . . . . 1889
Configuring carrier end point filtering. . . . . . . . . . . . . . . . . . . . . . . 1889
Blocking network access for IP addresses based on carrier end points . . . . . . . 1890
Configuring end point IP filtering . . . . . . . . . . . . . . . . . . . . . . . . . 1891
Extracting carrier end points for user and administrative notifications . . . . . . . . 1893
Configuring MMS address translation . . . . . . . . . . . . . . . . . . . . . . 1893
FortiOS 4.0 MR2

68 01-420-99686-20101026
Detailed Contents
MMS UTM features 1897

MMS virus scanning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1897
Why scan MMS messages? . . . . . . . . . . . . . . . . . . . . . . . . . . . 1897
MMS virus monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1898
MMS virus scanning blocks messages (not just attachments) . . . . . . . . . . 1898
Removing or replacing blocked messages . . . . . . . . . . . . . . . . . . . . 1898
Scanning MM1 retrieval messages. . . . . . . . . . . . . . . . . . . . . . . . 1899
Passing or blocking fragmented messages . . . . . . . . . . . . . . . . . . . 1899
Client comforting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1899
Server comforting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1900
Handling oversized MMS messages . . . . . . . . . . . . . . . . . . . . . . . 1900
MM1 sample messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1900
Configuring MMS virus scanning . . . . . . . . . . . . . . . . . . . . . . . . . 1901
MMS file filtering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1903
Built-in patterns and supported file types. . . . . . . . . . . . . . . . . . . . . 1904
MMS file filtering blocks messages (not just attachments) . . . . . . . . . . . . 1906
Configuring MMS file filtering. . . . . . . . . . . . . . . . . . . . . . . . . . . 1906
Configuring sender notifications . . . . . . . . . . . . . . . . . . . . . . . . . 1907
MMS content-based Antispam protection . . . . . . . . . . . . . . . . . . . . . . 1909
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1909
Scores and thresholds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1910
Configuring content-based antispam protection . . . . . . . . . . . . . . . . . 1911
Configuring sender notifications . . . . . . . . . . . . . . . . . . . . . . . . . 1911
Using wildcards and Perl regular expressions . . . . . . . . . . . . . . . . . . 1912
MMS DLP archiving . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1914
Configuring MMS DLP archiving . . . . . . . . . . . . . . . . . . . . . . . . . 1914
Viewing DLP archives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1915
Message flood protection 1917

Setting message flood thresholds . . . . . . . . . . . . . . . . . . . . . . . . . . 1918
Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1918
Flood actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1920
Notifying administrators of floods . . . . . . . . . . . . . . . . . . . . . . . . . . . 1920
Example of using three flood threshold levels and different sets of actions
for each threshold . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1921
Notifying message flood senders and receivers . . . . . . . . . . . . . . . . . . . 1923
Responses to MM1 senders and receivers . . . . . . . . . . . . . . . . . . . 1923
Forward responses for MM4 message floods . . . . . . . . . . . . . . . . . . 1924
Viewing DLP archived messages. . . . . . . . . . . . . . . . . . . . . . . . . . . 1924
Order of operations: flood checking before duplicate checking . . . . . . . . . . . 1925
01-420-99686-20101026 69
Detailed Contents
Bypassing message flood protection based on user’s carrier end points . . . . . . 1925
Configuring message flood detection. . . . . . . . . . . . . . . . . . . . . . . . . 1925
Sending administrator alert notifications . . . . . . . . . . . . . . . . . . . . . . . 1926
Configuring how and when to send alert notifications . . . . . . . . . . . . . . 1926
Configuring who to send alert notifications to . . . . . . . . . . . . . . . . . . 1928
Duplicate message protection 1931

Using message fingerprints to identify duplicate messages . . . . . . . . . . . . . 1932
Messages from any sender to any recipient . . . . . . . . . . . . . . . . . . . . . 1932
Setting duplicate message thresholds . . . . . . . . . . . . . . . . . . . . . . . . 1932
Duplicate message actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1932
Notifying duplicate message senders and receivers . . . . . . . . . . . . . . . . . 1933
Responses to MM1 senders and receivers . . . . . . . . . . . . . . . . . . . 1933
Forward responses for duplicate MM4 messages . . . . . . . . . . . . . . . . 1934
Viewing DLP archived messages. . . . . . . . . . . . . . . . . . . . . . . . . . . 1934
Order of operations: flood checking before duplicate checking . . . . . . . . . . . 1935
Bypassing duplicate message detection based on user’s carrier end points. . . . . 1935
Configuring duplicate message detection . . . . . . . . . . . . . . . . . . . . . . 1935
Sending administrator alert notifications . . . . . . . . . . . . . . . . . . . . . . . 1936
Configuring how and when to send alert notifications . . . . . . . . . . . . . . 1936
Configuring who to send alert notifications to . . . . . . . . . . . . . . . . . . 1937
MMS Replacement messages 1939

Changing replacement messages . . . . . . . . . . . . . . . . . . . . . . . . . . 1939
Multimedia content for MMS replacement messages . . . . . . . . . . . . . . . . 1940
MMS replacement message types . . . . . . . . . . . . . . . . . . . . . . . . . . 1942
Replacement message tags . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1942
Replacement message groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1943
Configuring GTP on FortiOS Carrier 1947

GTP support on the FortiOS Carrier unit . . . . . . . . . . . . . . . . . . . . . . . 1947
Packet sanity checking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1947
GTP stateful inspection. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1948
Protocol anomaly detection and prevention . . . . . . . . . . . . . . . . . . . 1948
HA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1948
Configuring General Settings on the FortiOS Carrier unit . . . . . . . . . . . . . . 1948
FortiOS 4.0 MR2

70 01-420-99686-20101026
Detailed Contents
Configuring Encapsulated Filtering on the FortiOS Carrier unit . . . . . . . . . . . 1950

Configuring Encapsulated IP Traffic Filtering . . . . . . . . . . . . . . . . . . 1950
Configuring Encapsulated Non-IP End User Address Filtering . . . . . . . . . 1951
Configuring Protocol Anomaly on the FortiOS Carrier unit . . . . . . . . . . . . . . 1952
Configuring Anti-overbilling in FortiOS Carrier . . . . . . . . . . . . . . . . . . . . 1952
Overbilling in GPRS networks . . . . . . . . . . . . . . . . . . . . . . . . . . 1952
Anti-overbilling with FortiOS Carrier . . . . . . . . . . . . . . . . . . . . . . . 1953
Configuring anti-overbilling with FortiOS Carrier . . . . . . . . . . . . . . . . . 1953
Logging events on the FortiOS Carrier unit. . . . . . . . . . . . . . . . . . . . . . 1953
Configuring FortiOS Carrier logging events . . . . . . . . . . . . . . . . . . . 1953
GTP message type filtering 1957

Common message types on carrier networks . . . . . . . . . . . . . . . . . . . . 1957
GTP-C messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1957
GTP-U messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1958
Unknown Action messages . . . . . . . . . . . . . . . . . . . . . . . . . . . 1959
Configuring message type filtering in FortiOS Carrier . . . . . . . . . . . . . . . . 1959
Message Type Fields. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1959
GTP identity filtering 1963

IMSI on carrier networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1963
Other identity and location based information elements . . . . . . . . . . . . . . . 1963
When to use APN, IMSI, or advanced filtering . . . . . . . . . . . . . . . . . . 1965
Configuring APN filtering in FortiOS Carrier . . . . . . . . . . . . . . . . . . . . . 1966
Configuring IMSI filtering in FortiOS Carrier . . . . . . . . . . . . . . . . . . . . . 1966
Configuring advanced filtering in FortiOS Carrier . . . . . . . . . . . . . . . . . . 1967
FortiOS Carrier diagnose commands. . . . . . . . . . . . . . . . . . . . . . . . . 1969
Dynamic Profile diagnose commands . . . . . . . . . . . . . . . . . . . . . . 1969
GTP related diagnose commands . . . . . . . . . . . . . . . . . . . . . . . . 1970
Applying Intrusion and Prevention System (IPS) signatures to IP
packets within GTP-U tunnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1970
01-420-99686-20101026 71
Detailed Contents
GTP packets are not moving along your network . . . . . . . . . . . . . . . . . . 1971

Attempt to identify the section of your network with the problem. . . . . . . . . 1971
Ensure you have an APN configured. . . . . . . . . . . . . . . . . . . . . . . 1972
Check the logs and adjust their settings if required . . . . . . . . . . . . . . . 1972
Check the routing table. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1972
Perform a sniffer trace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1973
Generate specific packets to test the network . . . . . . . . . . . . . . . . . . 1975
Chapter 16 Deploying Wireless Networks 1977
Introduction to wireless networking 1979

Wireless concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1979
Bands and channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1979
Power. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1980
Antennas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1980
Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1980
Whether to broadcast SSID . . . . . . . . . . . . . . . . . . . . . . . . . . . 1980
Encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1980
Separate access for employees and guests . . . . . . . . . . . . . . . . . . . 1981
Captive portal. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1981
Power. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1981
Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1981
Wireless networking equipment . . . . . . . . . . . . . . . . . . . . . . . . . . . 1982
FortiWiFi units . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1982
FortiAP units . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1983
Third-party WAPs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1983
Deployment considerations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1983
Types of wireless deployment . . . . . . . . . . . . . . . . . . . . . . . . . . 1983
Deployment methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1983
Single access point networks . . . . . . . . . . . . . . . . . . . . . . . . . . 1985
Multiple access point networks . . . . . . . . . . . . . . . . . . . . . . . . . . 1985
Configuring a wireless LAN 1987

Overview of wireless controller configuration. . . . . . . . . . . . . . . . . . . . . 1987
Creating a virtual access point (wireless controller) . . . . . . . . . . . . . . . . . 1988
More about security modes . . . . . . . . . . . . . . . . . . . . . . . . . . . 1989
Creating an AP Profile (wireless controller) . . . . . . . . . . . . . . . . . . . . . 1990
Adding a MAC filter. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1991
Configuring a WLAN interface (standalone FortiWiFi unit) . . . . . . . . . . . . . . 1991
Configuring MAC filtering. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1993
FortiOS 4.0 MR2

72 01-420-99686-20101026
Detailed Contents
Configuring the WLAN interface (wireless controller) . . . . . . . . . . . . . . . . 1993

Configuring DHCP on the WLAN . . . . . . . . . . . . . . . . . . . . . . . . . . . 1994
Configuring user authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . 1994
Creating a wireless user group . . . . . . . . . . . . . . . . . . . . . . . . . . 1995
Configuring firewall policies for the WLAN . . . . . . . . . . . . . . . . . . . . . . 1995
Customizing the captive portal . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1996
Adding a disclaimer page to the captive portal . . . . . . . . . . . . . . . . . . 1996
Modifying the Disclaimer page . . . . . . . . . . . . . . . . . . . . . . . . . . 1997
Modifying the Declined Disclaimer page . . . . . . . . . . . . . . . . . . . . . 1998
Enabling the disclaimer page. . . . . . . . . . . . . . . . . . . . . . . . . . . 1999
Access point deployment 2001

Network topology for managing APs . . . . . . . . . . . . . . . . . . . . . . . . . 2001
Attaching an AP unit as a WAP. . . . . . . . . . . . . . . . . . . . . . . . . . . . 2002
Controller discovery methods . . . . . . . . . . . . . . . . . . . . . . . . . . 2003
Connecting to the FortiAP CLI . . . . . . . . . . . . . . . . . . . . . . . . . . 2004
Configuring a FortiWiFi unit as a WAP . . . . . . . . . . . . . . . . . . . . . . 2004
Discovering and adding APs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2004
Wireless network monitoring 2007

Monitoring wireless clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2007
Monitoring rogue APs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2008
Monitoring with a FortiWiFi unit . . . . . . . . . . . . . . . . . . . . . . . . . 2008
Monitoring with a FortiGate wireless controller. . . . . . . . . . . . . . . . . . 2008
Configuring wireless network clients 2011

Windows XP client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2011
Windows 7 client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2015
Mac OS client. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2016
Linux client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2017
Checking that the client has received IP address and DNS server
information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2019
01-420-99686-20101026 73
Detailed Contents
Wireless network example 2021

Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2021
Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2021
Configuring the virtual access points . . . . . . . . . . . . . . . . . . . . . . . 2021
Configuring the AP profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2022
Configuring the wireless LAN interfaces . . . . . . . . . . . . . . . . . . . . . 2023
Configuring authentication for employee wireless users . . . . . . . . . . . . . 2023
Configuring authentication for guest wireless users . . . . . . . . . . . . . . . 2025
Customizing the captive portal . . . . . . . . . . . . . . . . . . . . . . . . . . 2028
Connecting the FortiAP units . . . . . . . . . . . . . . . . . . . . . . . . . . . 2028
Reference 2031
Wireless radio channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2031
Chapter 17 VoIP Solutions: SIP 2035
FortiGate VoIP solutions: SIP 2037

SIP overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2037
Common SIP VoIP configurations . . . . . . . . . . . . . . . . . . . . . . . . . . 2038
Peer to peer configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2038
SIP proxy server configuration . . . . . . . . . . . . . . . . . . . . . . . . . . 2039
SIP redirect server configuration . . . . . . . . . . . . . . . . . . . . . . . . . 2039
SIP registrar configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2040
SIP with a FortiGate unit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2041
SIP messages and media protocols . . . . . . . . . . . . . . . . . . . . . . . . . 2043
SIP request messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2045
SIP response messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2045
SIP message start line . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2047
SIP headers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2047
The SIP message body and SDP session profiles . . . . . . . . . . . . . . . . 2049
Example SIP messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2050
The SIP session helper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2052
SIP session helper configuration overview . . . . . . . . . . . . . . . . . . . . 2052
Configuration example: SIP session helper in Transparent Mode . . . . . . . . 2054
SIP session helper diagnose commands. . . . . . . . . . . . . . . . . . . . . 2056
FortiOS 4.0 MR2

74 01-420-99686-20101026
Detailed Contents
The SIP ALG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2057

SIP ALG configuration overview . . . . . . . . . . . . . . . . . . . . . . . . . 2060
Conflicts between the SIP ALG and the session helper . . . . . . . . . . . . . 2062
Stateful SIP tracking, call termination, and session inactivity timeout . . . . . . 2063
SIP and RTP/RTCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2065
How the SIP ALG creates RTP pinholes . . . . . . . . . . . . . . . . . . . . . 2065
Configuration example: SIP in Transparent Mode . . . . . . . . . . . . . . . . 2066
RTP enable/disable (RTP bypass) . . . . . . . . . . . . . . . . . . . . . . . . 2069
Opening and closing SIP register and non-register pinholes. . . . . . . . . . . 2069
Accepting SIP register responses . . . . . . . . . . . . . . . . . . . . . . . . 2070
How the SIP ALG performs NAT . . . . . . . . . . . . . . . . . . . . . . . . . . . 2071
Source address translation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2071
Destination address translation . . . . . . . . . . . . . . . . . . . . . . . . . 2072
Call Re-invite messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2072
How the SIP ALG translates IP addresses in SIP headers . . . . . . . . . . . 2072
How the SIP ALG translates IP addresses in the SIP body . . . . . . . . . . . 2075
SIP NAT scenario: source address translation (source NAT) . . . . . . . . . . 2076
SIP NAT scenario: destination address translation (destination NAT) . . . . . . 2077
SIP NAT configuration example: source address translation
(source NAT) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2080
SIP NAT configuration example: destination address translation
(destination NAT). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2082
Additional SIP NAT scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 2085
NAT with IP address conservation . . . . . . . . . . . . . . . . . . . . . . . . 2088
Controlling how the SIP ALG NATs SIP contact header line addresses . . . . . 2089
Controlling NAT for addresses in SDP lines . . . . . . . . . . . . . . . . . . . 2090
Translating SIP session destination ports . . . . . . . . . . . . . . . . . . . . 2090
Translating SIP sessions to multiple destination ports . . . . . . . . . . . . . . 2092
Enhancing SIP pinhole security . . . . . . . . . . . . . . . . . . . . . . . . . . . 2093
Hosted NAT traversal. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2095
Configuration example: Hosted NAT traversal for calls between SIP
Phone A and SIP Phone B . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2096
Restricting the RTP source IP . . . . . . . . . . . . . . . . . . . . . . . . . . 2098
SIP over IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2099
Deep SIP message inspection . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2100
Actions taken when a malformed message line is found. . . . . . . . . . . . . 2100
Logging and statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2101
Recommended configurations . . . . . . . . . . . . . . . . . . . . . . . . . . 2101
Configuring deep SIP message inspection. . . . . . . . . . . . . . . . . . . . 2102
Blocking SIP request messages . . . . . . . . . . . . . . . . . . . . . . . . . . . 2104
SIP rate limiting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2105
Limiting the number of SIP dialogs accepted by a firewall policy . . . . . . . . 2107
SIP logging and DLP archiving . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2107
01-420-99686-20101026 75
Detailed Contents
SIP and HA: session failover and geographic redundancy . . . . . . . . . . . . . . 2107

SIP geographic redundancy . . . . . . . . . . . . . . . . . . . . . . . . . . . 2108
Support for RFC 2543-compliant branch parameters . . . . . . . . . . . . . . 2109
SIP debugging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2109
SIP debug log format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2109
SIP-proxy filter per VDOM . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2110
SIP-proxy filter command . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2110
SIP debug log filtering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2111
SIP debug setting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2111
SIP test commands. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2112
Display SIP rate-limit data . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2112
Chapter 18 WAN Optimization, Web Cache, Explicit Proxy, and WCCP 2115
WAN optimization, web cache, and web proxy concepts 2117

WAN optimization topologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2117
Basic WAN optimization topologies . . . . . . . . . . . . . . . . . . . . . . . 2118
Out-of-path topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2118
Topology for multiple networks . . . . . . . . . . . . . . . . . . . . . . . . . . 2120
Web-cache-only WAN optimization . . . . . . . . . . . . . . . . . . . . . . . 2120
WAN optimization with web caching . . . . . . . . . . . . . . . . . . . . . . . 2122
WAN optimization and web caching with FortiClient peers . . . . . . . . . . . 2122
Explicit Web proxy topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2123
WCCP topology. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2124
WAN optimization client/server architecture . . . . . . . . . . . . . . . . . . . . . 2125
WAN optimization peers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2126
Peer-to-peer and active-passive WAN optimization . . . . . . . . . . . . . . . 2127
WAN optimization and the FortiClient application . . . . . . . . . . . . . . . . 2127
Operating modes and VDOMs . . . . . . . . . . . . . . . . . . . . . . . . . . 2127
WAN optimization tunnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2127
Tunnel sharing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2128
Protocol optimization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2129
Byte caching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2130
WAN optimization and HA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2130
Monitoring WAN optimization. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2130
FortiOS 4.0 MR2

76 01-420-99686-20101026
Detailed Contents
WAN optimization and Web cache storage 2133

Formatting the hard disk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2133
Configuring WAN optimization and Web cache storage . . . . . . . . . . . . . . . 2134
Changing the amount of space allocated for WAN optimization
and Web cache storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2134
WAN optimization peers and authentication groups 2135

Basic WAN optimization peer requirements . . . . . . . . . . . . . . . . . . . . . 2135
Accepting any peers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2135
How FortiGate units process tunnel requests for peer authentication . . . . . . . . 2136
Configuring peers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2137
Configuring authentication groups . . . . . . . . . . . . . . . . . . . . . . . . . . 2138
Secure tunneling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2140
Configuring WAN optimization rules 2141

WAN optimization rules, firewall policies, and UTM protection . . . . . . . . . . . . 2141
WAN optimization transparent mode . . . . . . . . . . . . . . . . . . . . . . . . . 2142
WAN optimization rule list . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2142
How list order affects rule matching . . . . . . . . . . . . . . . . . . . . . . . 2144
Moving a rule to a different position in the rule list . . . . . . . . . . . . . . . . 2145
WAN optimization address formats. . . . . . . . . . . . . . . . . . . . . . . . . . 2145
Configuring WAN optimization rules . . . . . . . . . . . . . . . . . . . . . . . . . 2146
Processing non-HTTP sessions accepted by an HTTP rule . . . . . . . . . . . 2148
Processing unknown HTTP sessions . . . . . . . . . . . . . . . . . . . . . . 2149
WAN optimization configuration examples 2151

Example: Basic peer-to-peer WAN optimization configuration . . . . . . . . . . . . 2151
Configuring basic peer-to-peer WAN optimization - web-based manager . . . . 2152
Configuring basic peer-to-peer WAN optimization - CLI . . . . . . . . . . . . . 2154
Testing and troubleshooting the configuration . . . . . . . . . . . . . . . . . . 2155
Example: Active-passive WAN optimization . . . . . . . . . . . . . . . . . . . . . 2157
Configuring basic active-passive WAN optimization - web-based manager . . . 2158
Configuring basic active-passive WAN optimization - CLI . . . . . . . . . . . . 2161
01-420-99686-20101026 77
Detailed Contents
Example: Adding secure tunneling to an active-passive WAN optimization

configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2165
Configuring WAN optimization with secure tunneling - web-based manager . . 2166
Configuring WAN optimization with secure tunneling - CLI . . . . . . . . . . . 2168
Web caching 2171

Configuring Web Cache Only WAN optimization . . . . . . . . . . . . . . . . . . . 2172
Exempting web sites from web caching . . . . . . . . . . . . . . . . . . . . . . . 2172
Example: Web Cache Only WAN optimization . . . . . . . . . . . . . . . . . . . . 2173
Configuring Web Cache Only WAN optimization - web-based manager. . . . . 2174
Configuring Web Cache Only WAN optimization - CLI. . . . . . . . . . . . . . 2175
Configuring active-passive web caching . . . . . . . . . . . . . . . . . . . . . . . 2177
Example: Active-passive Web Caching . . . . . . . . . . . . . . . . . . . . . . . 2178
Configuring active-passive web caching - web-based manager . . . . . . . . . 2178
Configuring active-passive web caching - CLI . . . . . . . . . . . . . . . . . . 2180
Configuring peer-to-peer web caching . . . . . . . . . . . . . . . . . . . . . . . . 2182
Example: Peer-to-peer web caching . . . . . . . . . . . . . . . . . . . . . . . . . 2182
Configuring peer-to-peer web caching - web-based manager . . . . . . . . . . 2183
Configuring peer-to-peer web caching - CLI . . . . . . . . . . . . . . . . . . . 2184
Changing web cache settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2185
Advanced configuration example 2189

Out-of-path WAN optimization with inter-VDOM routing . . . . . . . . . . . . . . . 2189
Configuration steps. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2190
Client-side configuration steps - web-based manager . . . . . . . . . . . . . . 2191
Server-side configuration steps - web-based manager . . . . . . . . . . . . . 2198
Client-side configuration steps - CLI . . . . . . . . . . . . . . . . . . . . . . . 2201
Server-side configuration steps - CLI . . . . . . . . . . . . . . . . . . . . . . 2208
FortiOS 4.0 MR2

78 01-420-99686-20101026
Detailed Contents
SSL offloading for WAN optimization and web caching 2211

Example: SSL offloading for a WAN optimization tunnel . . . . . . . . . . . . . . . 2211
Client-side configuration steps . . . . . . . . . . . . . . . . . . . . . . . . . . 2213
Server-side configuration steps . . . . . . . . . . . . . . . . . . . . . . . . . 2214
Example: SSL offloading and reverse proxy web caching for an Internet
web server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2215
Configuration steps. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2216
FortiClient WAN optimization 2219

Configuring FortiClient WAN optimization . . . . . . . . . . . . . . . . . . . . . . 2219
FortiClient configuration steps . . . . . . . . . . . . . . . . . . . . . . . . . . 2220
FortiGate unit configuration steps . . . . . . . . . . . . . . . . . . . . . . . . 2220
The FortiGate explicit web proxy 2221

Proxy auto-config (PAC) configuration . . . . . . . . . . . . . . . . . . . . . . 2225
Authentication realm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2226
Global explicit web proxy options . . . . . . . . . . . . . . . . . . . . . . . . 2226
Explicit web proxy authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . 2226
IP-Based authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2226
Per session authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2227
UTM features and the explicit web proxy . . . . . . . . . . . . . . . . . . . . . . . 2228
Explicit proxy sessions and protocol options . . . . . . . . . . . . . . . . . . . 2229
Explicit proxy sessions web filtering and FortiGuard web filtering . . . . . . . . 2229
Explicit proxy sessions and antivirus . . . . . . . . . . . . . . . . . . . . . . . 2230
Example: users on an internal network browsing the Internet through the
explicit proxy with web caching, RADIUS authentication, web filtering and
virus scanning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2230
Configuring the explicit web proxy - web-based manager . . . . . . . . . . . . 2231
Configuring the explicit web proxy - CLI . . . . . . . . . . . . . . . . . . . . . 2233
Explicit web proxy sessions and user limits . . . . . . . . . . . . . . . . . . . . . 2235
FortiGate WCCP 2239

How WCCP works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2239
01-420-99686-20101026 79
Detailed Contents
Example: WCCP router and client configuration . . . . . . . . . . . . . . . . . . . 2240

WCCP router configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . 2240
Configuring the forward and return methods and adding authentication . . . . . . . 2242
WCCP Messages. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2243
Troubleshooting WCCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2243
Real time debugging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2243
Application debugging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2243
WAN optimization, web cache and WCCP get and diagnose commands
2245
get test {wa_cs | wa_dbd | wad | wad_diskd | wccpd} <test_level> . . . . . . . . . 2245
Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2245
diagnose wad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2248
Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2248
diagnose wacs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2250
diagnose wadbd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2250
diagnose debug application {wa_cs | wa_dbd | wad | wad_diskd |
wccpd} [<debug_level>] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2250
Chapter 19 Load Balancing 2251
Configuring load balancing 2253

Load balancing overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2253
Configuring load balancing virtual servers . . . . . . . . . . . . . . . . . . . . 2254
Load balancing method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2255
Session persistence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2256
Real servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2256
Health check monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2257
Monitoring load balancing . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2258
Load balancing get command . . . . . . . . . . . . . . . . . . . . . . . . . . 2259
Load balancing diagnose commands . . . . . . . . . . . . . . . . . . . . . . 2259
Real server diagnostics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2260
Basic load balancing configuration example . . . . . . . . . . . . . . . . . . . . . 2261
HTTP and HTTPS load balancing, multiplexing, and persistence . . . . . . . . . . 2264
HTTP and HTTPS multiplexing. . . . . . . . . . . . . . . . . . . . . . . . . . 2264
HTTP and HTTPS persistence . . . . . . . . . . . . . . . . . . . . . . . . . . 2265
SSL/TLS load balancing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2266
SSL offloading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2266
IP, TCP, and UDP load balancing . . . . . . . . . . . . . . . . . . . . . . . . . . 2274
FortiOS 4.0 MR2

80 01-420-99686-20101026
Detailed Contents
Load balancing configuration examples 2275

Example: HTTP load balancing to three real web servers . . . . . . . . . . . . . . 2275
Web-based manager configuration. . . . . . . . . . . . . . . . . . . . . . . . 2276
CLI configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2278
Example: Basic IP load balancing configuration . . . . . . . . . . . . . . . . . . . 2280
Example: Adding a server load balance port forwarding virtual IP . . . . . . . . . . 2281
Example: Weighted load balancing configuration . . . . . . . . . . . . . . . . . . 2282
Web-based manager configuration. . . . . . . . . . . . . . . . . . . . . . . . 2282
CLI configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2284
Example: HTTP and HTTPS persistence configuration . . . . . . . . . . . . . . . 2285
CLI configuration: adding persistence for a specific domain . . . . . . . . . . . 2288
Chapter 20 Hardware 2291
FortiGate installation 2293

Mounting the FortiGate unit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2293
Desk or table mounting. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2293
Rack mounting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2293
Plugging in the FortiGate unit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2302
Connecting to the network . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2302
Turning off the FortiGate unit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2302
Further configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2303
FortiGate hardware accelerated processing 2305

How hardware acceleration alters packet flow . . . . . . . . . . . . . . . . . . . . 2305
Network processors overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2307
Network processor models . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2307
Determining the network processors installed on your FortiGate unit . . . . . . 2308
Content processors overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2308
Determining the content processor in your FortiGate unit . . . . . . . . . . . . 2309
Security processing modules overview . . . . . . . . . . . . . . . . . . . . . . . . 2309
Security processor module models. . . . . . . . . . . . . . . . . . . . . . . . 2309
Displaying information about security processing modules . . . . . . . . . . . 2309
Setting switch-mode mapping on the ADM-XD4 . . . . . . . . . . . . . . . . . 2310
Configuring overall security priorities . . . . . . . . . . . . . . . . . . . . . . . . . 2311
01-420-99686-20101026 81
Detailed Contents
Configuring traffic offloading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2312

Session fast path requirements . . . . . . . . . . . . . . . . . . . . . . . . . 2312
Packet fast path requirements . . . . . . . . . . . . . . . . . . . . . . . . . . 2312
Session offloading in HA active-active configuration . . . . . . . . . . . . . . . 2313
Configuring traffic shaping offloading . . . . . . . . . . . . . . . . . . . . . . 2313
Checking that traffic is offloaded . . . . . . . . . . . . . . . . . . . . . . . . . 2314
Disabling offloading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2314
Multicast offloading / acceleration . . . . . . . . . . . . . . . . . . . . . . . . 2314
Configuring IPsec VPN offloading . . . . . . . . . . . . . . . . . . . . . . . . . . 2315
IPsec offloading requirements . . . . . . . . . . . . . . . . . . . . . . . . . . 2315
Configuring HMAC check offloading . . . . . . . . . . . . . . . . . . . . . . . 2316
Configuring VPN encryption/decryption offloading . . . . . . . . . . . . . . . . 2316
Examples of ASM-FB4 accelerated VPNs . . . . . . . . . . . . . . . . . . . . 2317
Configuring IPS offloading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2320
Configuring pre-IPS anomaly detection . . . . . . . . . . . . . . . . . . . . . 2321
Configuring policy-based IPS on SP modules . . . . . . . . . . . . . . . . . . 2322
Configuring interface-based IPS on SP modules . . . . . . . . . . . . . . . . 2322
Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2322
Accelerated tunnel mode IPsec . . . . . . . . . . . . . . . . . . . . . . . . . 2323
Accelerated interface mode IPsec . . . . . . . . . . . . . . . . . . . . . . . . 2324
Configuring RAID 2327

RAID levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2327
Configuring a RAID array . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2328
Checking the status of a RAID array . . . . . . . . . . . . . . . . . . . . . . . . . 2329
Rebuilding a RAID array . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2329
Why rebuild a RAID array? . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2330
How to rebuild the RAID array . . . . . . . . . . . . . . . . . . . . . . . . . . 2330
FortiBridge installation and operation 2333

Example FortiBridge application . . . . . . . . . . . . . . . . . . . . . . . . . . . 2333
Connecting the FortiBridge unit . . . . . . . . . . . . . . . . . . . . . . . . . 2334
Normal mode operation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2336
How the FortiBridge unit monitors the FortiGate unit. . . . . . . . . . . . . . . 2336
Probes and FortiGate firewall policies . . . . . . . . . . . . . . . . . . . . . . 2337
Enabling probes to detect FortiGate hardware failure . . . . . . . . . . . . . . 2338
Enabling probes to detect FortiGate software failure. . . . . . . . . . . . . . . 2339
Probe interval and probe threshold. . . . . . . . . . . . . . . . . . . . . . . . 2339
Bypass mode operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2339
FortiBridge power failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2340
FortiOS 4.0 MR2

82 01-420-99686-20101026
Detailed Contents
Example FortiGate HA cluster FortiBridge application . . . . . . . . . . . . . . . . 2340

Connecting the FortiBridge-2002 (copper gigabit ethernet) . . . . . . . . . . . 2341
Connecting the FortiBridge-2002F (fiber gigabit ethernet) . . . . . . . . . . . . 2342
Example configuration with other FortiGate interfaces . . . . . . . . . . . . . . . . 2342
Completing the basic FortiBridge configuration . . . . . . . . . . . . . . . . . . . 2345
Adding an administrator password . . . . . . . . . . . . . . . . . . . . . . . . 2345
Changing the management IP address . . . . . . . . . . . . . . . . . . . . . 2345
Changing DNS server IP addresses . . . . . . . . . . . . . . . . . . . . . . . 2346
Changing the default gateway and adding static routes . . . . . . . . . . . . . 2346
Allowing management access to the EXT1 interface . . . . . . . . . . . . . . 2347
Changing the system time and date . . . . . . . . . . . . . . . . . . . . . . . 2347
Adding administrator accounts . . . . . . . . . . . . . . . . . . . . . . . . . . 2347
Resetting to the factory default configuration. . . . . . . . . . . . . . . . . . . . . 2348
Installing FortiBridge unit firmware . . . . . . . . . . . . . . . . . . . . . . . . . . 2348
Changing firmware versions . . . . . . . . . . . . . . . . . . . . . . . . . . . 2348
Installing firmware from a system reboot . . . . . . . . . . . . . . . . . . . . . 2350
Example network configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2353
Configuring FortiBridge probes. . . . . . . . . . . . . . . . . . . . . . . . . . 2354
Probe settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2355
Enabling probes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2356
Verifying that probes are functioning . . . . . . . . . . . . . . . . . . . . . . . 2357
Tuning the failure threshold and probe interval . . . . . . . . . . . . . . . . . 2358
Configuring FortiBridge alerts . . . . . . . . . . . . . . . . . . . . . . . . . . 2358
Recovering from a FortiGate failure . . . . . . . . . . . . . . . . . . . . . . . . . 2361
Manually switching between FortiBridge operating modes . . . . . . . . . . . . . . 2362
Backing up and restoring the FortiBridge configuration . . . . . . . . . . . . . . . 2362
Chapter 21 Certifications and Compliances 2365
FIPS-CC operation of FortiGate units 2367

Introduction to FIPS-CC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2367
Security level summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2367
Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2367
Overview of Common Criteria compliant operation. . . . . . . . . . . . . . . . . . 2368
Use of non-FIPS-CC compliant features . . . . . . . . . . . . . . . . . . . . . 2368
Effects of FIPS-CC compliant mode . . . . . . . . . . . . . . . . . . . . . . . 2368
01-420-99686-20101026 83
Detailed Contents
Initial configuration of the FortiGate unit . . . . . . . . . . . . . . . . . . . . . . . 2371

Installing the unit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2371
Configuration of units with AMC cards . . . . . . . . . . . . . . . . . . . . . . 2371
Registering the unit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2371
Downloading and installing FIPS-CC compliant firmware . . . . . . . . . . . . 2371
Verifying the firmware version of the unit. . . . . . . . . . . . . . . . . . . . . 2372
A note about non FIPS-CC functionality . . . . . . . . . . . . . . . . . . . . . 2372
Enabling FIPS-CC mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2373
Configuring interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2374
FIPS-CC mode status indicators . . . . . . . . . . . . . . . . . . . . . . . . . 2374
Administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2375
Administrator roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2375
Administrator accounts and profiles . . . . . . . . . . . . . . . . . . . . . . . 2375
Remote access requirements . . . . . . . . . . . . . . . . . . . . . . . . . . 2376
Disclaimer access banner . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2377
Administrator account lockout settings . . . . . . . . . . . . . . . . . . . . . . 2377
Scheduled administrator access . . . . . . . . . . . . . . . . . . . . . . . . . 2377
Using custom administrator access keys (certificates) . . . . . . . . . . . . . . 2377
Enabling multiple virtual domain configuration . . . . . . . . . . . . . . . . . . 2378
Configuration backup. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2378
Firewall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2379
Firewall policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2379
Firewall authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2379
Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2379
Excluding specific logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2380
Viewing log messages from the web-based manager . . . . . . . . . . . . . . 2381
Viewing log messages from the CLI . . . . . . . . . . . . . . . . . . . . . . . 2381
Backing up log messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2382
Viewing log file information . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2382
Deleting filtered log messages . . . . . . . . . . . . . . . . . . . . . . . . . . 2383
Deleting rolled log files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2383
Alarms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2383
Configuring alarms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2383
Alarm notifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2385
Acknowledging alarms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2386
Alarm polling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2386
Error modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2386
FIPS Error mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2386
CC Error mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2386
Disabling FIPS-CC mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2387
FortiOS 4.0 MR2

84 01-420-99686-20101026
Detailed Contents
Configuring FortiGate units for PCI DSS compliance 2389

Introduction to PCI DSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2389
What is PCI DSS? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2389
What is the Customer Data Environment . . . . . . . . . . . . . . . . . . . . 2389
PCI DSS objectives and requirements . . . . . . . . . . . . . . . . . . . . . . 2390
Network topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2392
Internet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2392
The CDE wired LAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2393
The CDE wireless LAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2393
Other internal networks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2393
Firewall policies for the CDE network . . . . . . . . . . . . . . . . . . . . . . . . 2393
Controlling the source and destination of traffic . . . . . . . . . . . . . . . . . 2393
Controlling the types of traffic in the CDE . . . . . . . . . . . . . . . . . . . . 2394
The default deny policy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2394
Wireless network security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2394
Scanning for rogue access points . . . . . . . . . . . . . . . . . . . . . . . . 2394
Securing a CDE network WAP . . . . . . . . . . . . . . . . . . . . . . . . . . 2395
Protecting stored cardholder data . . . . . . . . . . . . . . . . . . . . . . . . . . 2396
Protecting communicated cardholder data . . . . . . . . . . . . . . . . . . . . . . 2396
Configuring IPsec VPN security . . . . . . . . . . . . . . . . . . . . . . . . . 2396
Configuring SSL VPN security . . . . . . . . . . . . . . . . . . . . . . . . . . 2397
Protecting the CDE network from viruses . . . . . . . . . . . . . . . . . . . . . . 2397
Enabling FortiGate antivirus protection. . . . . . . . . . . . . . . . . . . . . . 2397
Configuring antivirus updates . . . . . . . . . . . . . . . . . . . . . . . . . . 2398
Enforcing firewall use on endpoint PCs . . . . . . . . . . . . . . . . . . . . . 2398
Monitoring the network for vulnerabilities. . . . . . . . . . . . . . . . . . . . . . . 2398
Using the FortiOS Network Vulnerability Scan feature . . . . . . . . . . . . . . 2398
Monitoring with other Fortinet products . . . . . . . . . . . . . . . . . . . . . 2399
Restricting access to cardholder data . . . . . . . . . . . . . . . . . . . . . . . . 2399
Controlling access to the CDE network. . . . . . . . . . . . . . . . . . . . . . . . 2400
Password complexity and change requirements . . . . . . . . . . . . . . . . . 2400
Password non-reuse requirement . . . . . . . . . . . . . . . . . . . . . . . . 2400
Administrator lockout requirement . . . . . . . . . . . . . . . . . . . . . . . . 2401
Administrator timeout requirement . . . . . . . . . . . . . . . . . . . . . . . . 2401
Administrator access security . . . . . . . . . . . . . . . . . . . . . . . . . . 2401
Remote access security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2401
Index 2403
01-420-99686-20101026 85
Detailed Contents
FortiOS 4.0 MR2

86 01-420-99686-20101026
Introduction
This FortiOS™ Handbook v2 is the definitive guide to configuring and operating FortiOS
4.0 MR2. It contains concept and feature descriptions, as well as configuration examples
worked out in detail for the web-based manager and the CLI. This document also contains
operating and troubleshooting information.
This is the second version of the handbook. This version is still a work in progress but
includes many improvements, corrections and additions. Among the additions are new
chapters that describe troubleshooting and FortiGate hardware (including hardware
installation, hardware acceleration, RAID, and FortiBridge). The new compliances and
certifications chapter describes FortiOS PCI support and FIPS/CC support. New sections
include more information about VRRP, SNMP, sFlow, advanced static routing, and more
information about deploying wireless networks.
The next version of the handbook (v3) will document FortiOS 4.0 MR3 and will also
include more examples, concepts, corrections and improvements. If you notice problems
with the handbook or have suggestions for improvements, send an email about them to
Fortinet Technical Documentation at techdoc@fortinet.com.
This introduction describes the following topics:
• How this Handbook is organized
• Document conventions
• Entering FortiOS configuration data
• Registering your Fortinet product
• Fortinet products End User License Agreement
• Training
• Documentation
• Customer service and technical support
How this Handbook is organized

This handbook contains the following chapters:
• Chapter 1, What’s New describes the new features in FortiOS 4.0 MR2 and includes
some general upgrading information.
• Chapter 2, FortiGate Fundamentals describes FortiOS firewall functionality on all
FortiGate units. It includes the purpose of the firewall, how traffic moves through the
FortiGate unit, the components involved in the firewall and its policies. This chapter
also describes how to configure the basics and some more involved examples.
• Chapter 3, System Administration describes a number of administrative tasks to
configure and setup the FortiGate unit for the first time. It also describes the best
practices and sample configuration tips to secure your network and the FortiGate unit
itself.
01-420-99686-20101026 87
• Chapter 4, Logging and Reporting describes how to begin choosing a log device for
your logging requirements, the types of log files, how to configure your chosen log
device, including detailed explanations of each log type of log message.
• Chapter 5, Troubleshooting describes concepts of troubleshooting and solving issues
that may occur with FortiGate units.
• Chapter 6, UTM Guide describes the Unified Threat Management (UTM) features
available on your FortiGate unit, including antivirus, intrusion prevention system (IPS),
anomaly protection (DoS), one-armed IPS (sniffer policies), web filtering, email
filtering, data leak prevention (DLP), and application control. The chapter includes
step-by-step instructions showing how to configure each feature. Example scenarios
are included, with suggested configurations.
• Chapter 7, User Authentication defines authentication and describes the FortiOS
options for configuring authentication for FortiOS.
• Chapter 8, IPsec VPNs provides a general introduction to IPsec VPN technology,
explains the features available with IPsec VPN and gives guidelines to decide what
features you need to use, and how the FortiGate unit is configured to implement the
features.
• Chapter 9, SSL VPNs provides a general introduction to SSL VPN technology, explains
the features available with SSL VPN and gives guidelines to decide what features you
need to use, and how the FortiGate unit is configured to implement the features.
• Chapter 10, Advanced Routing provides detailed information about FortiGate dynamic
routing including common dynamic routing features, troubleshooting, and each of the
protocols including RIP, BGP, and OSPF.
• Chapter 11, Virtual Domains describes FortiGate Virtual Domains (VDOMs) and is
intended for administrators who need guidance on solutions to suit different network
needs and information on basic and advanced configuration of VDOMs. Virtual
Domains (VDOMs) multiply the capabilities of your FortiGate unit by using virtualization
to partition your resources.
• Chapter 12, High Availability describes FortiGate HA, the FortiGate Clustering Protocol
(FGCP), FortiGate support of VRRP, and FortiGate standalone TCP session
synchronization.
• Chapter 13, Endpoint describes how to use the Endpoint features of FortiOS: endpoint
Network Access Control (NAC), endpoint application detection, endpoint monitoring,
and network vulnerability scanning.
• Chapter 14, Traffic Shaping describes how to configure FortiOS traffic shaping.
• Chapter 15, FortiOS Carrier describes FortiOS Carrier dynamic profiles and groups,
Multimedia messaging service (MMS) protection, and GPRS Tunneling Protocol (GTP)
protection.
• Chapter 16, Deploying Wireless Networks describes how to configure wireless
networks with FortiWiFi, FortiGate, and FortiAP units.
• Chapter 17, VoIP Solutions: SIP describes FortiOS SIP support.
• Chapter 18, WAN Optimization, Web Cache, Explicit Proxy, and WCCP describes how
FortiGate WAN optimization, web caching, and web proxy work and also describes
how to configure these features.
• Chapter 19, Load Balancing describes firewall HTTP, HTTPS, SSL or generic
TCP/UDP or IP server load balancing.
FortiOS 4.0 MR2

88 01-420-99686-20101026
• Chapter 20, Hardware describes how to mount, connect power, and turn on your
FortiGate unit. Other topics include descriptions and configuration instructions for
FortiGate accelerated hardware processing, RAID, and FortiBridge protection.
• Chapter 21, Certifications and Compliances explains how Fortinet products can help
you comply with the Payment Card Industry Data Security standard and also describe
FortiOS FIPS/CC support.
01-420-99686-20101026 89
Document conventions
Fortinet technical documentation uses the conventions described below.
IP addresses
To avoid publication of public IP addresses that belong to Fortinet or any other
organization, the IP addresses used in Fortinet technical documentation are fictional and
follow the documentation guidelines specific to Fortinet. The addresses used are from the
private IP address ranges defined in RFC 1918: Address Allocation for Private Internets,
available at http://ietf.org/rfc/rfc1918.txt?number-1918.
Most of the examples in this document use the following IP addressing:
• IP addresses are made up of A.B.C.D
• A - can be one of 192, 172, or 10 - the non-public addresses covered in RFC 1918.
• B - 168, or the branch / device / virtual device number.
• Branch number can be 0xx, 1xx, 2xx - 0 is Head office, 1 is remote, 2 is other.
• Device or virtual device - allows multiple FortiGate units in this address space
(VDOMs).
• Devices can be from x01 to x99.
• C - interface - FortiGate units can have up to 40 interfaces, potentially more than one
on the same subnet
• 001 - 099- physical address ports, and non -virtual interfaces
• 100-255 - VLANs, tunnels, aggregate links, redundant links, vdom-links, etc.
• D - usage based addresses, this part is determined by what device is doing
• The following gives 16 reserved, 140 users, and 100 servers in the subnet.
• 001 - 009 - reserved for networking hardware, like routers, gateways, etc.
• 010 - 099 - DHCP range - users
• 100 - 109 - FortiGate devices - typically only use 100
• 110 - 199 - servers in general (see later for details)
• 200 - 249 - static range - users
• 250 - 255 - reserved (255 is broadcast, 000 not used)
• The D segment servers can be farther broken down into:
• 110 - 119 - Email servers
• 120 - 129 - Web servers
• 130 - 139 - Syslog servers
• 140 - 149 - Authentication (RADIUS, LDAP, TACACS+, FSAE, etc)
• 150 - 159 - VoIP / SIP servers / managers
• 160 - 169 - FortiAnalyzers
• 170 - 179 - FortiManagers
• 180 - 189 - Other Fortinet products (FortiScan, FortiDB, etc.)
• 190 - 199 - Other non-Fortinet servers (NAS, SQL, DNS, DDNS, etc.)
• Fortinet products, non-FortiGate, are found from 160 - 189.
FortiOS 4.0 MR2

90 01-420-99686-20101026
The following table shows some examples of how to choose an IP number for a device
based on the information given. For internal and dmz, it is assumed in this case there is
only one interface being used.
Table 1: Examples of the IP numbering
Location and device Internal Dmz External

Head Office, one FortiGate 10.011.101.100 10.011.201.100 172.20.120.191
Head Office, second FortiGate 10.012.101.100 10.012.201.100 172.20.120.192
Branch Office, one FortiGate 10.021.101.100 10.021.201.100 172.20.120.193
Office 7, one FortiGate with 9 10.079.101.100 10.079.101.100 172.20.120.194
VDOMs
Office 3, one FortiGate, web n/a 10.031.201.110 n/a
server
Bob in accounting on the 10.0.11.101.200 n/a n/a
corporate user network (dhcp)
at Head Office, one FortiGate
Router outside the FortiGate n/a n/a 172.20.120.195
01-420-99686-20101026 91
Example Network configuration

The network configuration shown in Figure 1 or variations on it is used for many of the
examples in this document. In this example, the 172.20.120.0 network is equivalent to the
Internet. The network consists of a head office and two branch offices.
Figure 1: Example network configuration

WLAN: 10.12.101.100
SSID: example.com
Password: supermarine
DHCP range: 10.12.101.200-249
Linux PC
10.11.101.20
IN
10 T
.11
.10
FortiWiFi-80CM 1.1
01
Windows PC
10.11.101.10
Internal network 10
.11
.10 Po
1.1 rt 2
02
P P
10 ort 2 17 ort 1
.11 10 2.2 (s
.10 .11 0 . 1 n i ff
1.1 Switch .10 Po 20 er
FortiAnalyzer-100B 30 1.1 rt 2 FortiGate-82C .14 mo
00 1 de
)
10
.11
.10 Por
1.1 t 1
10 P
17 ort 1 3)
2.2 nd
0.1 2a
20 s
FortiGate-620B
.14
1 p ort
f
Po rt 8 r o
HA cluster
an rt 2 Po mirro
FortiMail-100C d3 (
rt 1
Po
Switch
He
ad
o ff
ice
P
10 ort 1
.21
.10
FortiGate-3810A 1.1
01
Linux PC 17
2.2
10.21.101.10 Bra 0.1
20 WAN
nch Bra .12 1
o ff nch 2
ice o ff
ice I
10 ntern
.31 al
.10
FortiGate-51B 1.1
0 0
60
1.1
rt 1 10
Po 0.21.
1
Windows PC
10.31.101.10
FortiManager-3000B
rt 4
Po .100
1
2 .10
.2
10 Cluster
Port 1: 10.21.101.102
FortiGate-5005FA2
Port 1: 10.21.101.102
FortiGate-5005FA2
Port 1: 10.21.101.103
FortiSwitch-5003A
Port 1: 10.21.101.161
FortiGate-5050-SM
Port 1: 10.21.101.104
Engineering network
10.22.101.0
FortiOS 4.0 MR2

92 01-420-99686-20101026
Cautions, Notes and Tips

Fortinet technical documentation uses the following guidance and styles for cautions,
notes and tips.
Caution: Warns you about commands or procedures that could have unexpected or
undesirable results including loss of data or damage to equipment.
Note: Presents useful information, but usually focused on an alternative, optional method,
such as a shortcut, to perform a step.
Tip: Highlights useful additional information, often tailored to your workplace activity.
01-420-99686-20101026 93
Typographical conventions
Fortinet documentation uses the following typographical conventions:
Table 2: Typographical conventions in Fortinet technical documentation
Convention Example
Button, menu, text box, From Minimum log level, select Notification.
field, or check box label
CLI input config system dns
set primary <address_ipv4>
end
CLI output FGT-602803030703 # get system settings
comments : (null)
opmode : nat
Emphasis HTTP connections are not secure and can be intercepted by a third
party.
File content <HTML><HEAD><TITLE>Firewall
Authentication</TITLE></HEAD>
<BODY><H4>You must authenticate to use this
service.</H4>
Hyperlink Visit the Fortinet Technical Support web site,
https://support.fortinet.com.
Keyboard entry Type a name for the remote VPN peer or client, such as
Central_Office_1.
Navigation Go to VPN > IPSEC > Auto Key (IKE).
Publication For details, see the FortiOS Handbook.
CLI command syntax conventions

This guide uses the following conventions to describe the syntax to use when entering
commands in the Command Line Interface (CLI).
Brackets, braces, and pipes are used to denote valid permutations of the syntax.
Constraint notations, such as <address_ipv4>, indicate which data types or string
patterns are acceptable value input.
Table 3: Command syntax notation
Convention Description
Square brackets [ ] A non-required word or series of words. For example:
[verbose {1 | 2 | 3}]
indicates that you may either omit or type both the verbose word and
its accompanying option, such as:
verbose 3
FortiOS 4.0 MR2

94 01-420-99686-20101026
Table 3: Command syntax notation (Continued)
Angle brackets < > A word constrained by data type.
To define acceptable input, the angled brackets contain a descriptive
name followed by an underscore ( _ ) and suffix that indicates the
valid data type. For example:
<retries_int>
indicates that you should enter a number of retries, such as 5.
Data types include:
• <xxx_name>: A name referring to another part of the
configuration, such as policy_A.
• <xxx_index>: An index number referring to another part of the
configuration, such as 0 for the first static route.
• <xxx_pattern>: A regular expression or word with wild cards
that matches possible variations, such as *@example.com to
match all email addresses ending in @example.com.
• <xxx_fqdn>: A fully qualified domain name (FQDN), such as
mail.example.com.
• <xxx_email>: An email address, such as
admin@mail.example.com.
• <xxx_url>: A uniform resource locator (URL) and its associated
protocol and host name prefix, which together form a uniform
resource identifier (URI), such as
http://www.fortinet./com/.
• <xxx_ipv4>: An IPv4 address, such as 192.168.1.99.
• <xxx_v4mask>: A dotted decimal IPv4 netmask, such as
255.255.255.0.
• <xxx_ipv4mask>: A dotted decimal IPv4 address and netmask
separated by a space, such as
192.168.1.99 255.255.255.0.
• <xxx_ipv4/mask>: A dotted decimal IPv4 address and
CIDR-notation netmask separated by a slash, such as such as
192.168.1.99/24.
• <xxx_ipv6>: A colon( : )-delimited hexadecimal IPv6 address,
such as 3f2e:6a8b:78a3:0d82:1725:6a2f:0370:6234.
• <xxx_v6mask>: An IPv6 netmask, such as /96.
• <xxx_ipv6mask>: An IPv6 address and netmask separated by a
space.
• <xxx_str>: A string of characters that is not another data type,
such as P@ssw0rd. Strings containing spaces or special
characters must be surrounded in quotes or use escape
sequences.
• <xxx_int>: An integer number that is not another data type,
such as 15 for the number of minutes.
01-420-99686-20101026 95
Entering FortiOS configuration data
Table 3: Command syntax notation (Continued)
Curly braces { } A word or series of words that is constrained to a set of options
delimited by either vertical bars or spaces.
You must enter at least one of the options, unless the set of options is
surrounded by square brackets [ ].
Options Mutually exclusive options. For example:
delimited by {enable | disable}
vertical bars | indicates that you must enter either enable or disable, but must
not enter both.
Options Non-mutually exclusive options. For example:
delimited by {http https ping snmp ssh telnet}
spaces indicates that you may enter all or a subset of those options, in any
order, in a space-delimited list, such as:
ping https ssh
Note: To change the options, you must re-type the entire list. For
example, to add snmp to the previous example, you would type:
ping https snmp ssh
If the option adds to or subtracts from the existing list of options,
instead of replacing it, or if the list is comma-delimited, the exception
will be noted.
Entering FortiOS configuration data

The configuration of a FortiGate unit is stored as a series of configuration settings in the
FortiOS configuration database. To change the configuration you can use the web-based
manager or CLI to add, delete or change configuration settings. These configuration
changes are stored in the configuration database as they are made.
Individual settings in the configuration database can be text strings, numeric values,
selections from a list of allowed options, or on/off (enable/disable).
Entering text strings (names)

Text strings are used to name entities in the configuration. For example, the name of a
firewall address, administrative user, and so on. You can enter any character in a
FortiGate configuration text string except, to prevent Cross-Site Scripting (XSS)
vulnerabilities, text strings in FortiGate configuration names cannot include the following
characters:
" (double quote), & (ampersand), ' (single quote), < (less than) and < (greater than)
You can determine the limit to the number of characters that are allowed in a text string by
determining how many characters the web-based manager or CLI allows for a given name
field. From the CLI, you can also use the tree command to view the number of
characters that are allowed. For example, firewall address names can contain up to 64
characters. When you add a firewall address to the web-based manager you are limited to
entering 64 characters in the firewall address name field. From the CLI you can do the
following to confirm that the firewall address name field allows 64 characters.
config firewall address
tree
-- [address] --*name (64)
|- subnet
|- type
|- start-ip
|- end-ip
FortiOS 4.0 MR2

96 01-420-99686-20101026
Registering your Fortinet product
|- fqdn (256)
|- cache-ttl (0,86400)
|- wildcard
|- comment (64 xss)
|- associated-interface (16)
+- color (0,32)
Note that the tree command output also shows the number of characters allowed for other
firewall address name settings. For example, the fully-qualified domain name (fqdn) field
can contain up to 256 characters.
Entering numeric values

Numeric values are used to configure various sizes, rates, numeric addresses, or other
numeric values. For example, a static routing priority of 10, a port number of 8080, or an
IP address of 10.10.10.1. Numeric values can be entered as a series of digits without
spaces or commas (for example, 10 or 64400), in dotted decimal format (for example the
IP address 10.10.10.1) or as in the case of MAC or IPv6 addresses separated by colons
(for example, the MAC address 00:09:0F:B7:37:00). Most numeric values are standard
base-10 numbers, but some fields (again such as MAC addresses) require hexadecimal
numbers.
Most web-based manager numeric value configuration fields limit the number of numeric
digits that you can add or contain extra information to make it easier to add the acceptable
number of digits and to add numbers in the allowed range. CLI help includes information
about allowed numeric value ranges. Both the web-based manager and the CLI prevent
you from entering invalid numbers.
Selecting options from a list

If a configuration field can only contain one of a number of selected options, the
web-based manager and CLI present you a list of acceptable options and you can select
one from the list. No other input is allowed. From the CLI you must spell the selection
name correctly.
Enabling or disabling options

If a configuration field can only be on or off (enabled or disabled) the web-based manager
presents a check box or other control that can only be enabled or disabled. From the CLI
you can set the option to enable or disable.
Registering your Fortinet product

Before you begin configuring and customizing features, take a moment to register your
Fortinet product at the Fortinet Technical Support web site, https://support.fortinet.com.
Many Fortinet customer services, such as firmware updates, technical support, and
FortiGuard Antivirus and other FortiGuard services, require product registration.
For more information, see the Fortinet Knowledge Center article Registration Frequently
Asked Questions.
Fortinet products End User License Agreement

See the Fortinet products End User License Agreement.
01-420-99686-20101026 97
Training
Training
Fortinet Training Services provides courses that orient you quickly to your new equipment,
and certifications to verify your knowledge level. Fortinet provides a variety of training
programs to serve the needs of our customers and partners world-wide.
To learn about the training services that Fortinet provides, visit the Fortinet Training
Services web site at http://campus.training.fortinet.com, or email training@fortinet.com.
Documentation
The Fortinet Technical Documentation web site, http://docs.fortinet.com, provides the
most up-to-date versions of Fortinet publications, as well as additional technical
documentation such as technical notes.
In addition to the Fortinet Technical Documentation web site, you can find Fortinet
technical documentation on the Fortinet Tools and Documentation CD, and on the Fortinet
Knowledge Center.
Fortinet Tools and Documentation CD

Many Fortinet publications are available on the Fortinet Tools and Documentation CD
shipped with your Fortinet product. The documents on this CD are current at shipping
time. For current versions of Fortinet documentation, visit the Fortinet Technical
Documentation web site, http://docs.fortinet.com.
Fortinet Knowledge Base

The Fortinet Knowledge Base provides additional Fortinet technical documentation, such
as troubleshooting and how-to-articles, examples, FAQs, technical notes, a glossary, and
more. Visit the Fortinet Knowledge Base at http://kb.fortinet.com.
Comments on Fortinet technical documentation

Please send information about any errors or omissions in this or any Fortinet technical
document to techdoc@fortinet.com.
Customer service and technical support

Fortinet Technical Support provides services designed to make sure that your Fortinet
products install quickly, configure easily, and operate reliably in your network.
To learn about the technical support services that Fortinet provides, visit the Fortinet
Technical Support web site at https://support.fortinet.com.
You can dramatically improve the time that it takes to resolve your technical support ticket
by providing your configuration file, a network diagram, and other specific information. For
a list of required information, see the Fortinet Knowledge Base article FortiGate
Troubleshooting Guide - Technical Support Requirements.
FortiOS 4.0 MR2

98 01-420-99686-20101026
Chapter 1 What’s New
This section explains general upgrading issues for both FortiOS and FortiOS Carrier that
may affect your configuration. This section also includes a top ten features topic that
explains the top most interesting features in FortiOS 4.0 MR2. For more information about
upgrading to FortiOS 4.0 MR2, see “Upgrading practices” on page 103.
This section contains the following topics:
• Top ten features
• Upgrading issues for FortiOS 4.0 MR2
• Upgrading issues for FortiOS Carrier
Top ten features

In FortiOS 4.0 MR2, there are many interesting new features, as well as changes to
existing features. The following list contains the top ten most interesting features.
• Limiting the number of concurrent explicit proxy users
• Flow-based antivirus database and Extreme antivirus database
• Report enhancements and Log viewing enhancement
• sFlow client support
• Monitoring application control traffic
• FortiGuard Web Filtering quotas
• Network Vulnerability Scan
• FSAE support Polling Domain Controllers (PDC)
• SSL proxy exemption by FortiGuard Web Filter category
• The redesigned web-based manager
Upgrading issues for FortiOS 4.0 MR2

When you are ready to upgrade to FortiOS 4.0 MR2, it is important to understand what
configuration settings may not carry forward during the upgrade process. This topic
explains what issues may occur during the upgrade process from FortiOS 4.0 MR1 to
FortiOS 4.0 MR2.
Fortinet recommends always backing up your current configuration before installing a new
firmware image, such as FortiOS 4.0 MR2, so that you always have a current version of
your configuration settings in the event those configuration settings do not carry forward.
FortiOS™ Handbook v2: What’s New

01-420-99686-20101026 99
Upgrading issues for FortiOS 4.0 MR2
Endpoint (previously Endpoint NAC)

The endpoint NAC feature is not working properly in FortiOS 4.0 MR2 GA. If you have
configured endpoint NAC settings previously in FortiOS 4.0 MR1 or earlier, you should
upgrade to FortiOS 4.0 MR2 Patch Release 1. This patch release resolves the issues.
Topology viewer
The Topology viewer is not supported in FortiOS 4.0 MR2 and, therefore, the settings that
you configured for this feature do not carried forward.
Customizing the GUI

Previously, you could assign to an administrator the read and write privileges of
customizing the web-based manager. However, in this release, this feature is no longer
supported and the customized settings configured previously are not carried forward.
Basic traffic reports (system memory only)

Previously, if you enabled memory logging on your FortiGate unit, you could view basic
traffic reports from Log&Report > Report Access > Memory. In FortiOS 4.0 MR2, this
feature is not supported.
PPTP VPNs
PPTP VPN configuration was previously available in both the web-based manager and
the CLI; however, now PPTP VPNs are configured only in the CLI. The following
commands are used when configuring PPTP VPNs
config vpn pptp
set status {enable | disable}
set eip <end_ip_address>
set ip-mode {range | usrgrp}
set sip <start_ip_address>
set usrgrp <user_group>
end
VoIP settings
When you upgrade to FortiOS 4.0 MR2, VoIP settings that were implemented in the
following scenario are not moved to the DLP archive feature.
• In FortiOS 4.0 Patch Release 4 has two protection profiles, PP1 and PP2.
• PP1 contains a DLP sensor (DLP1) and application control list (APP1); APP1
archives SIP messages.
• PP2 contains a DLP sensor (DLP1) and application control list (APP2); APP2 which
has content-summary enabled for SIMPLE.
NNTP DLP archive

NNTP log archives are not carried forward when upgrading to FortiOS 4.0 MR2.
Email filter banned word setting

The set spam-bword-table x setting under config firewall profile is not
carried forward after upgrading from FortiOS 4.0 Patch Release 4 to FortiOS 4.0 MR2.
What’s New for FortiOS 4.0 MR2

100 01-420-99686-20101026
Upgrading issues for FortiOS Carrier
HTTPS invalid certificate setting

The HTTPS allow-invalid-server-cert setting under config firewall
profile is not carried forward when upgrading from FortiOS 4.0 Patch Release 4 to
FortiOS 4.0 MR2.
HTTPS AV scanning
In FortiOS 4.0 MR2, if the FortiGate unit is configured to perform a deep inspection using
explicit web proxy, it does not work properly. There is currently no workaround.

When you are ready to upgrade to FortiOS Carrier 4.0 MR2, it is important to understand
what configuration settings may not carry forward during the upgrade process. This topic
explains what issues may occur during the upgrade process from FortiOS Carrier 4.0 MR1
to FortiOS Carrier 4.0 MR2.
Fortinet recommends always backing up your current configuration before installing a new
firmware image, such as FortiOS Carrier 4.0 MR2, so that you always have a current
version of your configuration settings in the event those configuration settings do not carry
forward.
The following are issues that occur when upgrading to FortiOS Carrier 4.0 MR2:
• The source IP address and MSISDN number are mismatched in the traffic log packet
that is sent to FortiAnalyzer
• MMS traffic may cause scannunitd to crash.
• MMS remove blocked feature does not work for MM3 and MM4 single part messages.
• Profile-group name is missing in the event log
• When the file type is set to allow for MMS file transfers, no log entry is added to the log
file.

01-420-99686-20101026 101

102 01-420-99686-20101026
Firmware upgrade practices
Administrators with read and write privileges can upgrade the firmware on a FortiGate
unit; however, proper upgrading procedures must be followed to ensure a successful
firmware upgrade. This section explains what you need to do before upgrading to the new
firmware image, FortiOS, as well as an example of how to properly upgrade to a new
firmware image from an earlier firmware image.
The following topics are included in this section:
• Upgrading from earlier firmware to FortiOS
• Upgrading practices
• Example: Upgrading from FortiOS 3.0 MR7 to FortiOS
Upgrading from earlier firmware to FortiOS

Before upgrading to FortiOS, you need to know if you can directly upgrade to FortiOS from
the current firmware that is running on your FortiGate unit. Directly upgrading from one
firmware image to another is not always supported, so you must find out if you need to first
upgrade to a patch release and then upgrade to the new firmware image.
The following table provides information about what firmware you need to install before
installing FortiOS. The following also provides examples of how to properly update to
FortiOS from an earlier firmware version and/or maintenance release.
Table 4: Upgrading to FortiOS 4.0 MR2
Current firmware Must upgrade to New firmware

version/maintenance release version/maintenance release
FortiOS 3.0 MR7 Patch Release 9 FortiOS 4.0.4 FortiOS (build-272) GA
(or later) build-o113
FortiOS 4.0.4 build-0113 (or later) N/A FortiOS (build-272) GA
FortiOS 4.0.4 build-196 (or later) N/A FortiOS (build-272) GA
After upgrading, verify that the build number and branch point match the firmware image.
You can view this in the web-based manager in the System Information widget, or use the
get system status command syntax in the CLI.
You should review the release notes for FortiOS, because it contains specific information
about what did not carry forward when upgrading from the firmware that is mentioned in
the above table.
Upgrading practices
When you are ready to install the new firmware on your unit, for either FortiOS or FortiOS
Carrier, you need to follow the below general procedure for upgrading.

01-420-99686-20101026 103
Example: Upgrading from FortiOS 3.0 MR7 to FortiOS Firmware upgrade practices
General procedure for upgrading current firmware

1 Verify what firmware images you need to upgrade to from the current firmware image
that is running on the unit.
For example, the FortiGate unit is running FortiOS 3.0 MR7 Patch Release 9.
According to Table 4 on page 103, the images required are FortiOS 4.0.4 build-0113
and FortiOS build-272 from the support website.
2 Download the new firmware image or images.
3 Back up your current configuration file.
4 Install the firmware during a low-traffic time period (for example, at night).
5 Clear your browser’s cache after the installation process is finished.
Example: Upgrading from FortiOS 3.0 MR7 to FortiOS

The following example explains how to properly upgrade to a new firmware image, such
as FortiOS, from the current firmware image that is running on your FortiGate unit. You
can use this example when you are upgrading the firmware on your own unit, to ensure a
successful upgrade.
In this example, the “test” procedure is used–the “test” procedure does not permanently
install the firmware image, and after the unit restarts, the previous firmware is installed. If
you require more information about the test procedure, see the System Admin chapter of
the FortiOS Handbook.
Verifying and downloading the required firmware images

The FortiGate unit is currently running FortiOS 3.0 MR7 Patch Release 9. In Table 4 on
page 103, the upgrade path is FortiOS 3.0 MR7 Patch Release 9 to FortiOS 4.0.4 build-
0113, and then to FortiOS build-272.
You immediately go to the support website, log in, and then download the required
firmware images to the management computer.
After downloading these images to the management computer, you start the TFTP server.
You also start the hyperterminal software for accessing the CLI; after the software starts,
you log in and enter the execute ping command to verify that the FortiGate unit is able to
connect to the management computer.
Before doing anything else, you log into the web-based manager to start backing up the
FortiGate unit’s configuration file.
Backing up the configuration file

Caution: Always back up your configuration before installing a patch release,
upgrading/downgrading firmware, or resetting configuration to factory defaults.
Before installing any firmware image, you must back up the current configuration file on
the FortiGate unit. This ensures that you have a current configuration file if the upgrade is
not successful. You are also ensuring that all configuration settings are available if there
are some that are not carried forward.
The following procedure backs up the configuration file from the web-based manager.
To back up your configuration file - web-based manager

1 Go to System > Dashboard > Status.

104 01-420-99686-20101026
Firmware upgrade practices Example: Upgrading from FortiOS 3.0 MR7 to FortiOS
2 In the System Information widget, select Backup in the System Configuration line.
You are automatically redirected to the Backup page.
3 Select the location where the configuration file will be stored on.
4 Select the check box beside Encrypt configuration file to encrypt the configuration file.
If you want to encrypt your configuration file to save VPN certificates, select the
Encrypt configuration file check box, enter a password, and then enter it again to
confirm.
5 Select Backup.
6 Save the file.
Installing FortiOS 4.0.4 build-0113

After backing up the configuration file, you can then begin to install the firmware images
on your FortiGate unit. The first firmware image that you need to install is FortiOS 4.0.4
build-0113.
The following procedure installs FortiOS 4.0.4 build-0113 permanently on your FortiGate
unit.
To upgrade to FortiOS 4.0 through the CLI

1 Copy the new firmware image file to the root directory of the TFTP server.
2 Start the TFTP server.
3 Log in to the CLI.
4 Enter the following command to ping the computer running the TFTP server:
execute ping <server_ipaddress>
Pinging the computer running the TFTP server verifies that the FortiGate unit and
TFTP server are successfully connected.
5 Enter the following command to copy the firmware image from the TFTP server to the
FortiGate unit:
execute restore image <name_str> <tftp_ipv4>
Where <name_str> is the name of the firmware image file and <tftp_ipv4> is the
IP address of the TFTP server. For example, if the firmware image file name is
image.out and the IP address of the TFTP server is 192.168.1.168, enter:
execute restore image.out 192.168.1.168
The FortiGate unit responds with a message similar to the following:
This operation will replace the current firmware version!
Do you want to continue? (y/n)
6 Type y.
The FortiGate unit uploads the firmware image file, upgrades to the new firmware
version, and restarts. This process takes a few minutes.
7 Reconnect to the CLI.
8 Enter the following command to confirm the firmware image installed successfully:
get system status
9 To update antivirus and attack definitions from the CLI, enter the following:
execute update-now

01-420-99686-20101026 105
Installing FortiOS using the test procedure

The next firmware you need to install is FortiOS. The following procedure allows you to
save the new firmware image to the system memory. This type of procedure provides a
way to become familiar with the new features and changes to existing features.
To install the new firmware image using the “test” procedure

2 Make sure the FortiGate unit can connect to the TFTP server using the execute
ping command.
3 Enter the following command to restart the FortiGate unit:
execute reboot
4 As the FortiGate unit reboots, press any key to interrupt the system startup. As the
FortiGate unit starts, a series of system startup messages appears. When the following
message appears:
Press any key to display configuration menu …
5 Immediately press any key to interrupt the system startup.
Note: You have only three seconds to press any key. If you do not press a key soon
enough, the FortiGate unit reboots and you must log in and repeat the execute reboot
Y
command.
6 If you successfully interrupt the startup process, the following message appears:
[G]: Get firmware image from TFTP server
[F]: Format boot device
[B]: Boot with backup firmware and set as default
[C]: Configuration and information
[Q]: Quit menu and continue to boot with default firmware
[H]: Display this list of options.
Enter G, F, Q, or H:
7 Type G to get the new firmware image from the TFTP server.
The following message appears:
Enter TFTP server address [192.168.1.168]:
8 Type the address of the TFTP server and press Enter.
Enter Local Address [192.168.1.168]:
9 Type an IP address of the FortiGate unit to connect to the TFTP server.
The IP address must be on the same network as the TFTP server, but make sure you
do not use the IP address of another device on the network.
Enter File Name [image.out]:
10 Enter the firmware image file name and press Enter.
The TFTP server uploads the firmware image file to the FortiGate unit and the
following appears:
Save as Default firmware/Backup firmware/Run image without
saving: [D/B/R]

106 01-420-99686-20101026
Firmware upgrade practices Example: Upgrading from FortiOS 3.0 MR7 to FortiOS
11 Type R.
The firmware image is installed to system memory and the FortiGate unit starts running
the new firmware image, but with its current configuration.
12 When you are done, reboot the FortiGate unit and it will resume using the previous
firmware image, FortiOS 4.0.4 build-0113.

01-420-99686-20101026 107

108 01-420-99686-20101026
Web-based manager
This section explains general information about what is new or changed for the web-based
manager in FortiOS 4.0 MR2.
• The redesigned web-based manager
• Widgets
• FSAE enhancements
• Dynamic proxy allocation
The redesigned web-based manager

The web-based manager has been redesigned for FortiOS 4.0 MR2. This new design
includes a fresh new look and new navigation while maintaining the same functionality and
familiar structure of FortiOS. Configuration of many features stays the same, unless
changes to existing features have occurred in FortiOS 4.0 MR2.
When logging into the web-based manager, you will notice the new design also includes
the log-in screen, which is shown in Figure 1.
Figure 2: New web-based manager login
Navigating in the web-based manager

After logging in to the web-based manager, you will notice that even though the main
menus are still located in the left-hand column, how you access the menus and sub-
menus (previously these were tabs) is quite different.
When you select a menu, for example System, all menus below System move down, and
then the sub-menus for System appear. You can then access the tabs by selecting the
plus sign (+) beside the name of the sub-menu that you want to access. This path location
is still the same as before, for example System > Network > Interface, but how you access
that tab is different.

01-420-99686-20101026 109
The redesigned web-based manager Web-based manager
Modifying settings within a feature

Within the menus, there is a column that contains check boxes for each row and this
column is referred to as the check box column. When you select a check box within that
column, the row is immediately highlighted and certain icons, such as the Edit icon, at the
top of the page are accessible. If you select the check box in the column name area, all
check boxes within that column are selected. These check boxes are for highlighting a row
within a list on a page, which you then decide to remove, modify, or other available options
such as moving an item in the list above another item.
Figure 3: Modifying settings within the VDOM list in System > VDOM > VDOM
Check box
column
Selected check box for modifying

settings. When selected, the entire row
becomes highlighted.
Use the following procedure whenever you need to make modifications to any feature’s
settings. This procedure assumes that you are already at the location where you need to
make modifications in, such as in Figure 2.
To access icons for modifications to items within a list

1 In the Check box column, within the row of the setting you want to change, select the
check box to highlight the row.
The grayed icons are now accessible, similar to that in Figure 2. On some pages, all
icons may not be accessible when you highlight the row.
2 With the icon or icons now accessible, select the icon that you want to use to make
modifications with (such as the Edit icon).
Tip: You can edit a row by simply double-clicking your mouse in that row. You are
automatically redirected to the page where you can modify the settings of that item. This
applies only to editing an item.
After the modifications are made, and you are back to the list on the page, the check box
is unselected and the row unhighlighted.
Switching VDOMs in the web-based manager

When VDOMs are enabled in the web-based manager, you may need to switch from
VDOM to VDOM. In this new re-design, how you switch between VDOMs is very simple
and easy. After VDOMs are enabled, a new menu appears at the bottom of the left
column, called Current VDOM. Beside the menu is a drop-down list where you select the
VDOM you want, and are then redirected to that VDOM. You can verify that you have
switched to a specific VDOM by viewing which main menus appear, and by the name that
appears in the Current VDOM’s drop-down list.
The Current VDOM main menu appears only when VDOMs are enabled. Creation and
configuring of VDOMs still remains the same and in System > VDOM > VDOM.

110 01-420-99686-20101026
Web-based manager Adding dashboards
Adding dashboards
You can add multiple dashboards within the Dashboard menu. The dashboards are add
as menus within the Dashboard menu. For example, branchoffice, is added below Usage,
within the Dashboard menu (System > Dashboard > branchoffice).
You must add the first dashboard from within the Status page. The dashboards that you
add to the Dashboard menu appear below the first two menus, Status and Usage. You can
add any type of widget that you want, to the dashboard that you created.
To add a dashboard to the dashboard menu

1 Go to Dashboard > Status.
2 Select the Dashboard icon.
A drop-down list appears with the following options:
Add Dashboard Add a new dashboard to the Dashboard menu.
Rename Dashboard Rename the current dashboard. You can rename the existing
default menus Status and Usage.
Delete Dashboard Removes the current dashboard that you are viewing from the
Dashboard menu.
Reset Dashboards Resets the entire Dashboard menu back to its default settings.
3 Select Add Dashboard.

4 Enter a name for the dashboard in the Name field in the Add Dashboard window.
5 Select OK.
You are automatically redirected to the new dashboard. You can start adding widgets to
the dashboard.
Widgets
The existing IM/P2P/VoIP widgets from UTM > Application Control > Statistics are now
available as widgets an can be customized.
These dashboard widgets are customized using either the web-based manager or CLI;
however, Fortinet encourages administrators to customize dashboard widgets within the
web-based manager, because you can see the customized settings immediately after
applying them.
This topic contains the following:
• Per-IP Bandwidth Usage
• P2P Usage
• IM Usage
• VoIP Usage
• Storage
• Alert Message Console enhancement

01-420-99686-20101026 111
Widgets Web-based manager
Per-IP Bandwidth Usage

The Per-IP Bandwidth Usage widget provides per-IP address session data. This data,
which displays each IP address that initiated the traffic, and its current bandwidth
consumption (in kbps), appears as a default widget in System > Dashboard > Usage. The
widget, similar to the top session widget, allows you to refresh the interval time, display the
user name instead of the IP address, and how the information displays either in the form
of a chart of table.
The following procedure assumes that the Per-IP Bandwidth Usage widget has already
been added to the dashboard of your choice, and that you are already on that dashboard’s
page.
To customize the per-IP bandwidth traffic shaping widget

1 Select the Edit icon in the title bar area.
The Custom Per-IP Bandwidth Usage Display window appears.
2 Modify the following to customize the widget:
• To rename the widget, enter the new name in the Custom Widget Name field.
• To display host names by a recognizable name instead of IP addresses, select the
check box beside Resolve Host Name.
• To change the display from chart to table, select Table in the Display Format row.
• To show top entries, select a number from the drop-down list in Top Entries to Show;
you can display up to the top 20 entries.
• To refresh the information at a set interval, enter a number (10-240) in seconds in
the Refresh Interval field.
3 Select OK.
P2P Usage
The P2P Usage widget displays the total bytes and total bandwidth for each supported
instant messaging client. These clients are WinNY, BitTorrent, eDonkey, Guntella, and
KaZaa. The P2P Usage widget can be displayed on either the Status or Usage page. You
can add it to either page by select +Widget, which is located at the bottom of the page.
Widgets can be customized to suite your needs; however, the P2P Usage widget can only
be renamed.
To change the name, select the Edit icon in the title bar area and then enter a new name in
the Custom Widget Name field. Select OK to save the change.
Note: The information displayed in this widget comes from the new application control
monitoring feature. You must enable this feature within the application control so that the
information is displayed in the widget.
IM Usage
The IM Usage widget provides detailed information about instant messaging client activity
that is occurring on your network. In the IM Usage widget, you can view information
regarding users, chats, messages, file transfers between clients, and any voice chats that
occurred as well. IM Usage provides this detailed information for IM, Yahoo!, AIM, and
ICQ.
Widgets can be customized to suite your needs; however, the IM Usage widget can only
be renamed.

112 01-420-99686-20101026
Web-based manager Widgets
VoIP Usage
The VoIP Usage widget displays information about VoIP calls that use the SIP and SCCP
protocols. You can view the number of calls that were dropped, failed or went
unanswered. You can easily and quickly view how many calls succeeded in getting
through, and how many calls there were in total from when you last cleared the
information in the widget.
Widgets can be customized to suite your needs; however, the VoIP Usage widget can only
be renamed.
Storage
The Storage widget provides detailed information about the amount of space available and
used on your local hard disk. This widget also shows the interface that is primarily using
the space as well as the total capacity (in GB) of the local disk.
Widgets can be customized to suite your needs; however, the Storage widget can only be
renamed.
Alert Message Console enhancement

You can now configure a separate Alert Message Console widget that displays only
FortiGuard alert information that is received from the FortiGuard Center. The Alert
Message Console is available by default from System > Dashboard > Status. You can
rename the newly created Alert Message Console widget and select the option FortiGuard
security alerts to enable alerts are received and display on the widget.
The following procedure assumes that you have already added the Alert Message
Console to a dashboard of your choice, and that you are already on that dashboard’s
page.
To configure FortiGuard alert information and the widget

1 Select the Edit icon in the title bar area.
The Custom Alert Display window appears.
2 Enter the name, FortiGuard alerts, in the Custom Widget Name field.
By entering this name, you can easily distinguish it from the Alert Message Console
widget.
3 Select the check box beside FortiGuard security alerts.
4 To display a specific number of alerts in the widget, select a number from the drop-
down list beside Number of alerts to display on the dashboard.
5 Select OK.
The following CLI command syntax supports this new option for the Alert Message
Console widget:
config system global

01-420-99686-20101026 113
FSAE enhancements Web-based manager
set fgd-alert-subscription [advisory | latest-threat | latest-

virus | latest-attack | new-virus-db | new-attack-db]
set advisory {enable | disable}
set latest-threat {enable | disable}
set latest-virus {enable | disable}
set latest-attack {enable | disable}
set new-virus-db {enable | disable}
set new-attack-db {enable | disable}
end
FSAE enhancements
The Fortinet Server Authentication Extension (FSAE) has two enhancements, support for
polling domain controllers and DC agent distribution. FSAE provides authentication
information to the FortiGate unit so that users automatically gain access to permitted
resources on a Microsoft Windows or Novell network without having to input login
information twice.
You can now install FSAE on a separate Windows server where it will poll the Domain
Controller (DC) periodically for log on and log off events. These events will then be sent
directly to the FortiGate unit.
The FSAE DC agent distribution feature provides a way to automate software distribution
on the FSAE DC agent itself. An MSI file is created which is then installed on the DC
agent. A simple GUI program is created to configure the DC agent setting. The installation
then installs a file (dcagent.dll) and the simple configuration utility to the Windows server.
Dynamic proxy allocation

FortiOS 4.0 MR2 allocates resources dynamically for the virus scanning, web filtering,
email filtering, and DLP UTM processing. The result is more efficient use of FortiGate
memory, CPU and FortiASIC resources.
On FortiGate models with more than one CPU you can use the following CLI commands
to change the number of proxy workers and scan units. These commands are for only
advanced users.
set proxy-worker-count <integer>
set scanunit-count <integer>
end

114 01-420-99686-20101026
FortiOS software enhancements
This section explains software enhancements that have been implemented, such as
storage management or blade topology enhancements. This section also includes the SIP
features that are now available across all FortiGate models.
• Disk management
• ELBC blade configuration
• Support for AMC modules
• Storing configuration history and templates on local hard disk
• SIP features available on all FortiGate models
Disk management
This new feature allows you to manage disk storage for log files as well as WAN Opt
storage. The data that you can store on the disk also includes firmware images,
configuration files, Antivirus databases and IPS databases, and much more.
Partitions are sections or databases within the drive itself. Partitions provide a more
manageable storage location because data is accessed more quickly and efficiently.
The following table explains the data types and where they are located on a drive on a
FortiGate unit. The partitions themselves are represented as numbers, for example,
section 1 of the hard disk contains primary and secondary firmware, section 2 contains
only archives, and section 3 contains only firmware images. The table also explains the
new data types (identified by the asterisk symbol) and their location on the disk.
Table 5: The data types where they are located on the drive
Data Description Location

Primary and Secondary FortiOS supports two sets of Flash partitions 1 and 2
firmware, and configuration firmware images and configuration
which are always stored on the disk
*Firmware image Extended firmware storage Flash partition on 3 only
*Revision History and On-the-box revision history or Flash partition on 3 only
Templates template storage
Disk Log Local logging feature Flash partition on either 2
or 3
Archive Local archiving feature Flash partition on either 2
or 3
Quarantine Local quarantine feature Flash partition on either 2
or 3
WAN Opt and Web Cache Disk allocation for WAN Opt and Flash partition on either 2
Web Cache features or 3
Extended AV Database Extended antivirus database, which Flash partition on either 2
is currently supported in the third or 3
partition.
*Extreme AV Database Complete antivirus database. Flash partition on either 2
or 3

01-420-99686-20101026 115
ELBC blade configuration FortiOS software enhancements
Table 5: The data types where they are located on the drive (Continued)
*Extreme IPS Database IPS Database extensions to include Flash partition on either 2
malware and malicious URL entries or 3
*Vulnerability Database Vulnerability Database Flash partition on either 2
or 3
If your FortiGate unit has a fixed disk, or if there is only a single disk on the unit, the
configuration is determined by the size of the partitions. Platforms that are affected by this
are ones that use one system partition, and two user partitions.
If your FortiGate unit has multiple disks, Fortinet recommends choosing one disk to store
log and system data on, and then choose which disk to use for which data types. For
example, disk 1 is used for log and system data storage, while disk 2 is used for firmware
image storage, disk 3 is used for databases (all databases, such as Vulnerability), and
disk 4 is used for quarantined files. The FortiGate unit will automatically make the decision
on how to load balance WAN Opt and Web Cache storage issues among the multiple
disks.
Configuration options may vary widely with removable disks, since there could be up to
ten removable disks. If the user inserts extra disks into a multiple-disk FortiGate model,
the administrator will have the option to assign the disks for WAN Opt and Web Cache.
Note: RAID is not included in this release of the Disk Management feature.
Disk I/O scalability

The new Disk I/O scalability allows FortiGate units with multiple disks and high capacity
disk access to be configured to do a type of “load-balance” with WAN Opt and Web Cache
deployments.
With this feature, you can:
• configure an optimal partitioning scheme
• maximize parallel reads/writes based on optimizing either total throughput for WAN Opt
and Web Cache deployments or total number of sessions.
Storage Health Monitor

An extension to disk management, the Disk I/O scalability provides you with the ability to
by-pass disk access when the disk becomes a bottleneck for traffic.
When the disk I/O spikes and becomes a bottleneck for traffic, specific settings that you
enable allow the traffic to flow properly again. This settings automatically by-pass the
web-cache and WAN optimization features.
ELBC blade configuration

This enhancement to the ELBC blade deployment topology allows FortiGate blades to
synchronize their configuration, similar to the HA primary and subordinate unit scenario.
This enhancement is available on FortiGate models with an ELBC blade deployment
topology. These models must be running FortiOS 4.0 MR2 to use this synchronization
feature.

116 01-420-99686-20101026
FortiOS software enhancements Support for AMC modules
Support for AMC modules

FortiOS 4.0 MR2 now supports the following AMC modules.
• ASM-CD4
• ADM-XE2
• ADM-XD4
• RTM-XD2
Storing configuration history and templates on local hard disk

Multiple configuration files, revisions and templates can now be stored on a FortiGate
unit’s flash disk, if that flash disk is 1G or larger. The configuration files can be stored on a
third partition.
The configuration files are uploaded to the third partition, and then listed under the section
Config File. Firmware images will also be listed, located under the OS images section. If
you try to upload a file that is not recognized by the FortiGate unit, that file is deleted.
The following table explains the amount of revisions, templates and configuration files can
be stored on a flash drive.
Table 6: The maximum number of revisions, templates and firmware images for each flash
drive
Compact Flash Number of Number of Number of

Size Revisions Templates Firmware
Images
1 GB 20 20 5
2 GB 40 20 5
4 GB 100 40 10
8 GB 200 40 10
Firmware images and templates must be deleted when the limit is reached and for
revision history, when the maximum number of files is reached, the FortiGate replaces the
oldest files with the new ones. This behavior is similar to how logs are rolled, since you
can configure the FortiGate unit to roll a log when the maximum log size is reached.
The following is a CLI command syntax that you can use to find the flash size on your
FortiGate unit.
get hardware status
An example of what may display after entering the above CLI command syntax (from a
FortiGate-51B unit):
Model name: Fortigate-51B
ASIC version: CP6
ASIC SRAM: 64M
CPU: Geode(TM) Integrated Processor by AMD PCS
RAM: 502 MB
Compact Flash: 981 MB /dev/hda
Hard disk: 30711 MB /dev/hde
USB Flash: not available
Network Card chipset: ip175c-vdev (rev.)

01-420-99686-20101026 117
SIP features available on all FortiGate models FortiOS software enhancements
SIP features available on all FortiGate models

Previously, SIP features were found only on FortiOS Carrier. In FortiOS 4.0 MR2, they are
now available on all FortiGate models that are running FortiOS 4.0MR2.
These SIP features are available only in the CLI, under the voip profile command.
The following are the SIP features that are available in FortiOS 4.0 MR2.
• SIP header conformance check
• SIP message per method rate limitation
• SIP NAT IP address conservation
• Support for multiple RTP endpoint
• SIP HA failover
• Deep SIP message inspection
• Stateful SCTP firewall
• SIP Hosted NAT Traversal (HNT)
• Logging and statistics
SIP header conformance check

The SIP header conformance check allows for detection of malformed, and perhaps,
malicious SIP messages. You can enable this check by using the unknown-header [
discard | pass | respond] variable in the voip command. The following is an
example.
config voip profile
edit voip_1
config sip
set unknown-header respond
end
SIP message per method rate limitation

The SIP message per method rate limitation allows the limitation of message rates per SIP
methods. Previously, FortiOS specified only two methods, INVITE and REGISTER, while
FortiOS Carrier provided additional request methods. This feature will also be able to rate
limit, in particular, non-dialog SIP services such as presence services.
The following variables configure this feature in the CLI:
set message-rate <per second_per policy>
set bye-rate <per second_per policy>
set cancel-rate <per second_per policy>
set publish-rate <per second_per policy>
set options-rate <per second_per policy>
set notify-rate <per second_per policy>
set subscribe-rate <per second_per policy>
set prack-rate <per second_per policy>
set ack-rate <per second_per policy>
set update-rate <per second_per policy>
set info-rate <per second_per policy>
set register-rate <per second_per policy>
set invite-rate <per second_per policy>
set provisional-invite-expiry-time <seconds> (between 10-3600)

118 01-420-99686-20101026
FortiOS software enhancements SIP features available on all FortiGate models
SIP NAT IP address conservation

The SIP NAT IP address conservation provides the ability to store the external IP address
and port information that is overwritten in a SIP NAPT in the SDP i-line (information line).
This information is particularly important for debugging purposes of the operator.
The following CLI variable is used to configure SIP NAT IP address conservation:
set preserve-override [enable | disable]
Support for multiple RTP endpoint

This previous, FortiOS Carrier-only feature allows you to configure a large number of RTP
endpoints in a RTP NAT configuration. Previously, this required a VIP configuration where
the IP addresses of the RTP endpoint needed to be configured. With a larger number of
RTP endpoint (for example, larger than 64), this may become an issue, for example in
enterprise IP PABX networks.
The following CLI variable is used to configure RTP endpoint support:
set rtp [enable | disable]
RTP bypass option

The RTP Bypass Option allows the RTP stream to bypass the SIP signaling firewall.
SIP HA failover
The SIP HA failover supports a low outage configuration for carrier grade networks to
reduce the downtime to a minimum. This applies to planned outages, such as software or
hardware upgrades, or an unplanned outage, such as a hardware failure. In large
enterprise configurations, SIP HA failover has become a requirement for high-end IP
PABX and high capacity SIP trunking applications for the same reason.
Deep SIP message inspection

Deep SIP message syntax inspection (also called Deep SIP header inspection or SIP
fuzzing protection) provides protection against malicious SIP messages by applying SIP
header and SDP profile syntax checking. SIP Fuzzing attacks can be used by attackers to
discover and exploit vulnerabilities of a SIP entity (for example, a SIP proxy server). These
attacks could often crash or compromise the SIP entity. The SIP Firewall in FortiOS 4.0
MR2 helps detect these types of malicious messages and drop or reject them.
The SIP stateful firewall checks all messages in syntax and semantics against the SIP
standards. If a malformed header, which is a violation against the standard list, is
detected, one of the following options can be configured so that the FortiGate unit takes
the appropriate action:
• pass – passes the message along
• discard – discards the message altogether
• respond – responds with a SIP 4xx, 5xx, or 6xxx message (hard-coded message)
The above options are configurable in the CLI. These types of actions can be logged, if
required. The following information is logged by the FortiGate unit when a message was
detected as a malformed message:
• Malformed SIP message
• Header field – to indicated which header field is malformed)
• Line – header content as long as it fits into the maximum length of the log message;
this is truncated if it is too long)

01-420-99686-20101026 119
• Column – assists the analyst to locate the point where the FortiGate unit believes the
header is malformed.
The following table outlines the SIP header field with the option associated with it in the
CLI.
Table 7: SIP header fields and their associated CLI variable
SIP Header field CLI variable options

SIP Request Line malformed-request-line {discard | pass}
SIP VIA malformed-header-via {discard | pass}
SIP FROM malformed-header-from {discard | pass}
SIP TO malformed-header-to {discard | pass}
SIP CALL-ID malformed-header-call-id {discard | pass}
SIP CSEQ malformed-header-cseq {discard | pass}
SIP RACK malformed-header-rack {discard | pass}
SIP RSEQ malformed-header-rseq {discard | pass}
SIP CONTACT malformed-header-contact {discard | pass}
SIP RECORD-ROUTE malformed-header-record-route {discard | pass}
SIP EXPIRES malformed-header-expires {discard | pass}
SIP CONTENT-TYPE malformed-header-content-type {discard | pass}
SIP CONTENT-LENGTH malformed-header-content-length {discard | pass}
SIP MAX-FORWARDS malformed-header-max-forwards {discard | pass}
SIP ALLOW malformed-header-allow {discard | pass}
SIP P-ASSERTED- malformed-p-asserted-identity {discard | pass}
IDENTITY
If the FortiGate unit detects a new or unknown SIP header field, you can configure the
FortiGate unit to take an action in that case. This may mean the message is passed or
discarded.
Stateful SCTP firewall

The FortiGate firewall can no w apply firewall policies to SCTP sessions in the same way
as TCP and UDP sessions. You can create firewall policies that accept or deny SCTP
traffic by setting the service to ANY. FortiOS does not included pre-defined SCTP
services. When configuring firewall policies for traffic with specific SCTP source or
destinations ports, you must create custom firewall services for SCTP.
FortiGate units route SCTP traffic in the same way as TCP and UDP traffic. You can
configure policy routes specifically for routing SCTP traffic by setting the protocol number
to 132. SCTP policy routes can route SCTP traffic according to the destination port of the
traffic if you add a port range to the policy route.
You can configure a FortiGate unit to perform stateful inspection of different types of SCTP
traffic by creating custom SCTP services and defining the port numbers or port ranges
used by those services. FortiGate units support SCTP over IPv4.
The stateful SCTP firewall supports the following:
• IPv4 networks, as well as IPv6 and NAT
• IPSec VPN transport (SCTP over IPSec)
• configure and view status of SCTP firewall from remote devices, such as FortiManager
and SNMP agent, along with web-based manager, CLI and SNMP.

120 01-420-99686-20101026
• log events and alarms of stateful firewall events

• SNMP MIB for stateful SCTP firewall
• CLI commands that allow for debugging and displaying of SCTP content and statistics
Adding an SCTP custom service

Use the following command to create a custom SCTP service that accepts SCTP traffic
using destination port 2905. SCTP port number 2905 us used for SS7 Message Transfer
Part 3 (MTP3) User Adaptation Layer (M3UA) over IP.
The following is an example using the following CLI commands and variables:
config firewall service custom
edit M3UA_service
set protocol TCP/UDP/SCTP
set sctp-portrange 2905
end
To add the same custom service from the web-based manager, go to Firewall > Service >
Custom and select Create New. Use the following example when configuring the custom
service.
New Custom Service page

Name M3UA_service
Protocol Type TCP/UDP/SCTP
Protocol SCTP
Source Port (Low) 1
Source Port (High) 65535
Destination Port (Low) 2905
Destination Port (High) 2905
Adding an SCTP policy route

You can add policy routes that route SCTP traffic based on the SCTP source and
destination port as well as other policy route criteria. The SCTP protocol number is 132.
Use the following commands to direct all SCTP traffic with SCTP destination port 2905 to
the next hop gateway at IP address 1.1.1.1.
config router policy
edit 1
set input-device internal
set src 0.0.0.0 0.0.0.0
set dst 0.0.0.0 0.0.0.0
set output-device external
set gateway 1.1.1.1
set protocol 132
set start-port 2905
set end-port 2905
end
To add the same policy router example configuration from the web-based manager, go to
Router > Static > Policy Route and select Create New. Use the following to configure the
policy router and then select OK.
New Policy Route page

If incoming traffic matches:

01-420-99686-20101026 121
Protocol 132
Incoming interface internal
Source address/mask 0.0.0.0 0.0.0.0
Destination address/mask 0.0.0.0 0.0.0.0
Destination Ports From 2905 to 2905
Type of Service 00 and 00
Force traffic to:
Outgoing interface external
Gateway address 1.1.1.1
Changing the session time to live for SCTP traffic

You can change the session timeout for SCTP traffic in the CLI. Use the following example
to help you change the session timeout for SCTP traffic. It changes the protocol M3UA on
port 2905 to 3600 seconds.
config system session-ttl
config port
edit 1
set protocol 132
set start-port 22905
set end-port 2905
set timeout 3600
end
Adding an SCTP port forwarding virtual IP

In the following example, it shows how to add a static NAT port forwarding virtual IP that
uses port address translation to allow external access to a server on a private network. In
this example, the external IP address of the server 172.20.120.11 and the real IP address
of the web server on the internal network is 10.21.101.11. Use the example to help you
add an SCTP port forwarding virtual IP of your own.
config firewall vip
edit web_Server
set portforward enable
set extintf port1
set extip 172.20.120.11
set extport 2905
set mappedip 10.31.101.11
set mappedport 2905
set protocol sctp
end
SIP Hosted NAT Traversal (HNT)

Hosted NAT Traversal (HNAT) for SIP is now supported in FortiOS. You can configure this
new feature so that a UAC that is behind a NAT firewall that is not SIP aware and can
allow RTP to flow through the FortiGate unit.
The following is an example of the CLI command syntax used to configure this feature.
config voip profile
edit voip_1
config sip
set hosted-NAT-traversal enable

122 01-420-99686-20101026
set hnt-restrict-source-IP enable

next
end
end
Logging and statistics

With this enhancement, improvements to log, statistical and debug information as well for
FortiOS Carrier SIP implementation are provided. These improvements are as follows:
• Logging -- logs discarded SIP messages when they are detected as invalid.
• Statistics -- more information is included within the log to help explain what occurred
and why the log was recorded.
• Debugging -- more readable and easier to understand the information shown.
Logging command variables:
log-violations
log-call-summary
Debugging variable
call-keepalive (continue tracking calls with no RTP for this many minutes)

01-420-99686-20101026 123

124 01-420-99686-20101026
CLI
This section explains specific CLI commands for FortiOS 4.0 MR2. This section does not
include all CLI commands that were changed or new ones added. For more information
about what CLI commands are new and what commands changed, see the FortiGate CLI
Reference.
• grep
• IS-IS routing support
• Trouble-shooting command updates
grep
The grep command allows users to search the CLI using the show, get and diag
commands. A grep command is a type of command line text search utility that searches
files or standard input globally for lines that match a given regular expression. The grep
command is based on the standard UNIX grep command.
The grep command supports:
• ignore case distinctions
• print line number with output line
• select non-matching lines
• only print count of matching lines
• print NUM lines of trailing context
• print NUM lines of leading context
• print NUM lines of output context
The grep command is used in the following way:
show <config_command> <subcommand> | grep regex_expression
diag <config_command> <subcommand> | grep regex_expression
get <config_command> <subcommand> | grep regex_expression
Example
The following is an example of how to use the grep command to display all TCP sessions
in the session list, including the session list line number.
get system session list | grep -n tcp
2:tcp 47 172.16.120.110:1132 - 10.10.20.5:80 -
3:tcp 3355 172.16.120.110:1156 - 10.10.20.5:80 -
4:tcp 3352 172.16.120.110:1157 - 10.10.20.5:80 -
5:tcp 3354 172.16.120.110:1155 - 10.10.20.5:80 -
11:tcp 3599 172.16.120.110:115 - 192.168.110.220 -

01-420-99686-20101026 125
IS-IS routing support CLI
IS-IS routing support

FortiOS 4.0 MR2 includes support for the Intermediate system to intermediate system
(IS-IS) routing protocol. IS-IS is described in RFC 1142. You can enable and configure
IS-IS on your FortiGate unit if this routing protocol is in use on your network. You configure
IS-IS and view information about IS-IS using the from the CLI using the following
commands:
Note: For each routing protocol, you can also use a redistribute command to
redistribute IS-IS routes with the other protocol. For example, to redistribute IS-IS routes
over OSFP enter:
config router ospf
config redistribute isis
set statue enable
end
end
IS-IS CLI commands

config router isis
set adjacency-check {disable | enable}
set auth-mode-l1 {md5 | password}
set auth-password-l1 <password>
set auth-sendonly-l1 {disable | enable}
set auth-sendonly-l2 {disable | enable}
set default-originate {disable | enable}
set dynamic-hostname {disable | enable}
set ignore-lsp-errors {disable | enable}
set is-type {level-1 | level-1-2 | leve-2-only}
set lsp-gen-interval-l1 <interval_int>
set lsp-gen-interval-l2 <interval_int>
set lsp-refresh-interval <interval_int>
set max-lsp-lifetime <lifetime_int>
set metric-style {narrow | narrow-transition | narrow-
transition-11 | narrow-transition-12 | transition |
transition-11 | transition-12 | wide | wide-11 | wide-12 |
wide-transition | wide-transition-11 | wide-transition-12}
set overload-bit {disable | enable}
set overload-bit-on-startup <5-864000_seconds>
set overload-bit-suppress {external | interlevel}
set redistribute-l1 {disable | enable}
set redistribute-11-list <access_list_str>
set redistribute-l2 {disable | enable}
set redistribute-12-list <access_list_str>
set spf-interval-exp-l1 <min_delay_int>
set spf-interval-exp-l2 <min_delay_int> <max_delay_int>
config isis-interface
edit <interface_str>
set auth-send-only-l1 {disable | enable}

126 01-420-99686-20101026
CLI Trouble-shooting command updates
set auth-send-only-l2 {disable | enable}

set circuit-type {level-1 | level-1-2 | level2-only}
set csnp-interval-l1 <interval_int>
set csnp-interval-l2 <interval_int>
set hello-interval-l1 <interval_int>
set hello-interval-l2 <interval_int>
set hello-multiplier-l1 <multipler_int>
set hello-multiplier-l2 <mulipler_int>
set hello-padding {disable | enable}
set lsp-interval <interval_int>
set lsp-retransmit-interval <interval_int>
set mesh-group {disable | enable}
set mesh-group-id <id_int>
set metric-l1 <metric_int>
set metric-l2 <metric_int>
set network-type {broadcast | point-to-point}
set priority-l1 <priority_int>
set priority-l2 <priority_int>
set status {disable | enable}
set wide-metric-l1 <metric_int>
set wide-metric-l2 <metric_int>
config isis-net
edit <id>
set net <user_defined>
config redistribute {bgp | connected | ospf | rip | static}
set metric <metric_int>
set metric-type {external | internal}
set level <level-1 | level-1-2 | level-2}
set routemap <routemap_name>
config summary-address
edit <id>
set level {level-1 | level-1-2 | level-2}
set prefix <prefix_ipv4> <prefix_mask>
end
end
Trouble-shooting command updates

In FortiOS 4.0 MR2, there are new get commands that provide trouble-shooting
information. These new get commands are similar to previous diag commands, because
of the information they can retrieve.
Here are the get commands that you can use for trouble-shooting:
get system auto-update Retrieves update status information for scheduled updates,
status push update, virus defniitions, IPS definitions, server
override, push address override, and web proxy tunneling.
The information also indicates whether FDN is available.
get system auto-update Retrieves information about updates for FortiGuard services,
version such as antivirus.
get system startup-error-log Retrieves any errors that occurred during start up.

01-420-99686-20101026 127
Trouble-shooting command updates CLI
get system auto-update Retrieves update status information for scheduled updates,
status push update, virus defniitions, IPS definitions, server
override, push address override, and web proxy tunneling.
The information also indicates whether FDN is available.
get webfilter status The refresh-rate variable provides how often to refresh the
<refresh-rate> server lists in minutes.
exec tac report A debug report is generated.
get system performance Retrieves packet distribution statistics.
firewall packet-distribution
get system performance Retrieves traffic statistics. These statistics retrieve how
firewall statistics many packets were created during sessions such as IM,
web browsing and generic UDP.
get system session-helper- Retrieves the session’s protocol amount and port number
info used.
get system session-ttl Retrieves the session’s TTL configuration information.
get system performance top Retrieves detailed information about the top performance
protocols
get router info kernel Retrieves information about the routing kernel.
get hardware npu Retrieves information about hardware NPU. When you enter
{legacy | npux …} the command, it must be in the following order:
{list | session | setting} get hardware npu {legacy | npu1 | npu2 |
npu3} {list | session | setting}
Note: For get hardware npu there are additional settings
within the NPU device list. For example, under npu2, the
following is available: performance.

128 01-420-99686-20101026
System
This section explains the new features and changes to existing features that concern the
System menu in the web-based manager.
• Concurrent username restriction
• MD5 hash for log transfers
• Limiting the number of concurrent explicit proxy users
• sFlow client support
• WCCP client mode
• Client certificate handling for SSL inspection
• Controlling the source interface IP address for self-originating traffic
• Web Proxy replacement messages
• Maintenance
Concurrent username restriction

There are now options for restricting concurrent user sessions for either per-user or per-
administrator. This is an extension to administrator and firewall user session enforcement.
You can configure this restriction in the CLI. The following is the CLI syntax to use when
configuring concurrent user restrictions:
set admin-concurrent {enable | disable}
set policy-auth-concurrent {enable | disable}
end
MD5 hash for log transfers

MD5 hash for log transfers feature helps maintain the integrity of log files when in transfer,
ensuring that the log information was not altered before making it outside the
FortiAnalyzer unit, or backing up.
config system central-management
set fmg-source-ip 172.16.122.154
end
Limiting the number of concurrent explicit proxy users

In FortiOS 4.0 MR2, you can now place a limit on how many users there should be for
explicit proxy. You can configure this limit either in the CLI or the web-based manager.
Example
When the vdom-admin is enabled, the following CLI command syntaxes are available:
config global
config system resource-limits

01-420-99686-20101026 129
sFlow client support System
set webproxy <max global user>

end
config system vdom-property
edit <vdom_name>
set webproxy <vdom_max_user>
next
end
To limit the number of concurrent explicit proxy users

1 Go to System > VDOM > VDOM.
2 Edit the VDOM that you want to limit concurrent explicit proxy users.
3 On the Edit Virtual Domain page, under Resource Usage, enter the guaranteed MB
amount in the Guaranteed field of the Concurrent web proxy users row.
4 Select OK.
sFlow client support

sFlow is a network monitoring protocol described in http://www.sflow.org. FortiOS
implements sFlow version 5. You can configure one or more FortiGate interfaces as sFlow
agents that monitor network traffic and send sFlow datagrams containing information
about traffic flow to an sFlow collector. You can add sFlow agents to any FortiGate
interface, including physical interfaces, VLAN interfaces, and aggregate interfaces.
sFlow is normally used to provide an overall traffic flow picture of your network. You would
usually operate sFlow agents on switches, routers, and firewall on your network, collect
traffic data from all of them and use a collector to show traffic flows and patterns.
Using this data you can determine normal traffic flow patterns for your network and then
monitor for traffic flow problems. As these problems are found you can attempt to correct
them and continue to use the sFlow agents and collectors to view the results of your
corrective action.
The FortiGate sFlow agent functions like any sFlow agent, combining interface counters
and flow samples into sFlow datagrams that are immediately sent to an sFlow collector.
Because the sFlow datagrams are sent immediately without processing the data and
without collecting large amounts of data, running the sFlow agent has almost no affect on
system performance.
You can configure sFlow only from the CLI. To begin using sFlow, you must add the IP
address of your sFlow connector to the FortiGate configuration and then configure sFlow
agents on FortiGate interfaces.
Example configuration
The following is an example that helps to explain how to configure your FortiGate unit to
send sFlow datagrams to an sFlow collector. This example configuration also includes
how to config sFlow with multiple VDOMs.
To configure the FortiGate unit to send sFlow datagrams to an sFlow collector

1 Enter the following command syntax to set the IP address of your sFlow collector to
172.20.120.11:
config system sflow
set collector-ip 172.20.120.11
end

130 01-420-99686-20101026
System WCCP client mode
2 If required you can also change the UDP port number that the sFlow agent uses. You
should only change this port if required by your network configuration or sFlow
collector. The default sFlow port is 6343. The following command changes the sFlow
agent port to 5345.
config system sflow
set collector-port 6345
end
3 Use the following command to enable sFlow for the port1 interface:
config system interface
edit port1
set sflow-sample enable
end
4 Repeat this step to add sFlow agents to other FortiGate interfaces.
5 You can also change the sampling rate, polling interval, and sample direction for each
sFlow agent:
edit port1
set sample-rate <rate_number>
set polling-interval <frequency>
set sample-direction {both | rx | tx}
end
sFlow with multiple VDOMs

For a FortiGate unit operating with multiple VDOMs, you can add different sFlow collector
IP addresses and port numbers to each non-management VDOM. Use the following
command syntax to customize the sFlow configuration for a VDOM named VDOM_1:
config vdom
edit VDOM_1
config system vdom-sflow
set vdom-sflow enable
set collector-ip 172.20.120.11
end
The management VDOM and all VDOMs that you have not configured a VDOM-specific
configuration for use the global sFlow configuration.
WCCP client mode

You can configure a FortiGate unit to operate as a WCCP router or client. The WCCCP
client configuration is new for FortiOS 4.2.
• A FortiGate unit operating as a WCCP router can intercept HTTP and HTTPS sessions
and forward them to a web caching engine that caches web pages and returns cached
content to the web browser.
• A FortiGate unit operating as a WCCP client can accept and forward WCCP sessions
and use firewall policies to apply NAT, UTM, and other FortiGate security features to
them. A FortiGate unit operates as a WCCP client only in NAT/Route mode (and not in
Transparent mode)
WCCP router mode configuration

Enter the following command to configure a FortiGate unit to operate as a WCCP router
(this is the default FortiGate WCCP configuration).

01-420-99686-20101026 131
WCCP client mode System
config system settings

set wccp-cache-engine disable
end
Use the following command to configure WCCP router mode:
config system wccp
edit <service-id>
set router-id <interface_ipv4>
set group-address <multicast_ipv4>
set server-list <router_ipv4>
set authentication {disable | enable}
set forward-method {GRE | L2 | any}
set return-method {GRE | L2 | any}
set assignment-method {HASH | MASK | any}
set password <password_str>
next
end
WCCP client mode configuration

Enter the following command to configure a FortiGate unit to operate as a WCCP cache
engine:
set wccp-cache-engine enable
end
When you enter this command an interface named w.<vdom_name> is added to the
FortiGate configuration (for example w.root). All WCCP received by a FortiGate unit
operating as a WCCP client is considered to be received at this interface and you can
enter firewall policies for the WCCP traffic. For example, the following firewall policy
accepts WCCP traffic routed from the w.root interface to the wan1 interface. This firewall
policy applies NAT and an antivirus UTM profile named scan to the WCCP traffic.
.config firewall policy
edit 4
set srcintf w.root
set dstintf wan1
set srcaddr all
set dstaddr all
set action accept
set schedule always
set service any
set nat enable
set utm-status enable
set av-profile scan
end
You can also use the following commands to configure how a FortiGate unit in WCCP
client mode communicates with WCCP routers:
config system wccp
edit <service-id>
set cache-id <cache_engine_ip4>
set group-address <multicast_ipv4>
set router-list <server_ipv4mask>
set authentication {disable | enable}
set service-type {auto | dynamic | standard}
set assignment-weight <weight_int>

132 01-420-99686-20101026
System Client certificate handling for SSL inspection
set assignment-bucket-format {cisco-implementation |

wccp-v2}
set password <password_str>
next
end
Client certificate handling for SSL inspection

SSL sessions that use client-certificates now bypass the SSL inspection. For this
enhancement to work properly, an SSL server should be set up that requires client-side
certificates; these certificates are then uploaded to the client, making a connection
through the FortiGate unit with the SSL Inspection feature enabled on the FortiGate unit.
Controlling the source interface IP address for self-originating

traffic
This new feature is an extension to the general system operation, allowing you to specify
the source IP address of self-originated traffic. The following are supported for this feature:
• SNMP
• Syslog servers
• FortiAnalyzer units
• Alert Email
• FortiManager connection
This feature is available only in the CLI. The following is an example of the CLI command
syntax used to configure a source IP address for self-originating traffic.
config system central-management
set fmg-source-ip 172.16.122.154
end
Web Proxy replacement messages

Web proxy replacement messages were included in the Replacement Messages menu for
web proxy. These messages are specifically for triggers that are associated with web
proxy, such as web proxy access, login, authorization, and HTTP errors.
These web proxy replacement messages are:
Table 8: Web Proxy replacement messages
Message name Description

Web proxy If no web proxy policy is defined, and the default action is set to Deny, this
access denied message displays. This message also displays when both of the following are
true:
• no web proxy policy is defined OR no existing policy matches the incoming
request
• default action is set to Deny (System > Network > Web Proxy)
Note: The default action is ignored when there is at least one web policy
defined.
Web proxy login This replacement message is triggered by a log in, and is always sent to the
challenge client’s browser with it is triggered; however, some browsers (Internet Explorer
and Firefox) are unable to display this replacement message.

01-420-99686-20101026 133
Maintenance System
Table 8: Web Proxy replacement messages
Message name Description

Web proxy login If a user name and password authentication combination is entered, and is
fail accepted as incorrect, this replacement message appears.
Web proxy If a username and password is entered and is correct, this replacement message
authorization fail appears. However, if the following is true, this replacement message also
appears:
• The user is not allowed to view the request resources, (for example in an
FSAE setup and the authentication passes), and the username and
password combo is correct, but the user group does not match a user group
defined in the firewall policy.
Web proxy This replacement message is triggered whenever there is a web proxy HTTP
HTTP error error. This message forwards the actual servers’ error message and a web proxy
internal error message, for example, error 404: web page is not found.
Web proxy user- If you have enabled user-limit within config system replacemsg
limit (CLI only) webproxy, this message is triggered when a web proxy user has met the
threshold that is defined in global resources or vdom resources.
Maintenance
The Maintenance menu has been redesigned for FortiOS 4.0 MR2. This new redesign
incorporates the disk management enhancements introduced in this release. The new
redesign moves the Backup and Restore menu’s settings to the System Information
widget.
The System Information widget displays the date and time of when the configuration was
previously backed up, as well as the options to backup (select Backup to back up the
configuration) or restore a configuration (select Restore to restore a previously backed up
configuration). When you select Backup, you are automatically redirected to the Backup
page which contains the same options that were previously found in the Backup and
Restore menu. When you select Restore, you are automatically redirected to the Restore
page, which contains the same options that were previously found in the Backup and
Restore menu.
The Maintenance menu now contains the following menus:
• Firmware – allows you to upgrade firmware; if you have partitioned the hard drive, you
can also upload or upgrade the firmware on that partition
• FortiGuard – allows you to view FortiGuard subscriptions as well as configuring
settings for the FortiGuard Analysis server
• Advanced – allows you to upload scripts, configure an automatic install of a firmware
image and configuration file from a USB key, and you can also download a debug log
file for use in debugging the FortiGate unit.
• License – has not changed; still allows you to include a VDOM license to extend the
amount of VDOMs on your FortiGate unit.
• Disk – provides information about the amount of space being used or that is free on the
hard drive; also includes detailed information about the data that is being stored, for
example disk logging has 5 MB allocated, 1 MB that is being used, and 100 percent of
quota usage.

134 01-420-99686-20101026
High availability
This section explains all new features and changes to existing features that concern High
Availability in the web-based manager.
• Configurable Ethernet types for HA heartbeat packets
• HA subsecond failover
• HA reserved management interface
Configurable Ethernet types for HA heartbeat packets

Normal IP packets are 802.3 packets that have an Ethernet type (Ethertype) field value of
0x0800. Ethertype values other than 0x0800 are understood as level2 frames rather than
IP packets.
By default, HA heartbeat packets use the following Ethertypes:
• HA heartbeat packets for NAT/Route mode clusters use Ethertype 0x8890. These
packets are used by cluster units to find other cluster units and to verify the status of
other cluster units while the cluster is operating.
• HA heartbeat packets for Transparent mode clusters use Ethertype 0x8891. These
packets are used by cluster units to find other cluster units and to verify the status of
other cluster units while the cluster is operating.
• HA synchronization packets use Ethertype 0x8893. These packets are used to
synchronize the cluster units.
Since heartbeat packets are recognized as level2 frames, the switches and routers on
your heartbeat network that connect to heartbeat interfaces must be configured to allow
them. If level2 frames are dropped by these network devices, heartbeat traffic will not be
allowed between the cluster units.
Some third-party network equipment may use packets with these Ethertypes for other
purposes. For example, Cisco N5K/Nexus switches use Ethertype 0x8890 for some
functions. When one of these switches receives Ethertype 0x8890 packets from an
attached cluster unit, the switch generates CRC errors and the packets are not forwarded.
As a result, FortiGate units connected with these switches cannot for a cluster.
In some cases, if the heartbeat interfaces are connected and configured so regular traffic
flows but heartbeat traffic is not forwarded, you can change the configuration of the switch
that connect the HA heartbeat interfaces to allow level2 frames with Ethertypes 0x8890,
0x8893, and 0x8891 to pass.
For FortiOS 4.0 MR2, you can use the following CLI command syntax on each cluster unit
to change the Ethertypes of the HA heartbeat packets:
config system ha
set ha-eth-type <ha_ethertype_4-digit_hex> default: 8890
set hc-eth-type <hc_ethertype_4-digit_hex> default: 8891
set l2ep-eth-type <l2ep_ethertype_4-digit_hex> default: 8893
end

01-420-99686-20101026 135
HA subsecond failover High availability
HA subsecond failover
HA subsecond failover is an extension of the HA failover mechanism. This new feature
allows you to configure subsecond failover for your HA configuration. This feature applies
to interfaces (or ports) with NP2 or newer network processors. FortiGate-310B units and
above support this feature.
The following is an example of the CLI command syntax used to configure subsecond
failover for HA:
config system ha
set subsecond enable
end
HA reserved management interface

You can provide direct management access to all cluster units by reserving a
management interface as part of the HA configuration. Once this management interface is
reserved, you can configure a different IP address and administrative access settings for
this interface for each cluster unit. Then, by connecting this interface of each cluster unit to
your network, you can be manage each cluster unit separately from a different IP address.
The reserved management interface provides direct management access to each cluster
unit and gives each cluster unit a different identity on your network. This simplifies using
external services, such as SNMP, to monitor and manage each cluster unit.
If you enable SNMP administrative access for the reserved management interface, you
can use SNMP to monitor each cluster unit using the reserved management interface IP
address. You can monitor each cluster unit using SNMP by adding the IP address of each
cluster unit’s reserved management interface to the SNMP server configuration. You must
also enable direct management of cluster members in the cluster SNMP configuration.
If you enable HTTPS or HTTP administrative access for the reserved management
interfaces, you can connect to the web-based manager of each cluster unit. Any
configuration changes made to any of the cluster units is automatically synchronized to all
cluster units. From the subordinate units, the web-based manager has the same features
as the primary unit, except that unit-specific information is displayed for the subordinate
unit. For example:
• The System Information widget displays the subordinate unit serial number but also
displays the same information about the cluster as the primary unit
• On the Cluster members list, (go to System > Config > HA), you can change the HA
configuration of the subordinate unit that you are logged into. For the primary unit and
other subordinate units, you can change only the host name and device priority.
• Log Access displays the logs of the subordinate that you are logged into first. You use
the HA Cluster list to view the log messages of other cluster units, including the primary
unit.
If you enable SSH or TELNET administrative access for the reserved management
interfaces, you can connect to the CLI of each cluster unit. The CLI prompt contains the
host name of the cluster unit that you have connected to. Any configuration changes made
to any of the cluster units is automatically synchronized to all cluster units. You can also
use the execute ha manage command to connect to other cluster unit CLIs.

136 01-420-99686-20101026
High availability HA reserved management interface
Configuring the reserved management interface and SNMP remote management

of individual cluster units
This example describes how to configure SNMP remote management of individual cluster
units using the HA reserved management interface. The configuration consists of two
FortiGate-620B units already operating as a cluster. In the example, the port8 interface of
each cluster unit is connected to the internal network using the switch and configured as
the reserved management interface.
Figure 4: SNMP remote management of individual cluster units
Internal
Network
SNMP Server
10.11.101.20
Switch
Port2: 10.11.101.100
Port8: 10.11.101.102 FortiGate-620B

(Subordinate Unit) Cluster
Port8: 10.11.101.101
(Primary Unit) Port1: 172.20.120.141
Internet
To configure the reserved management interface - web-based manager

1 Go to System > Config > HA.
2 Edit the primary unit.
3 Select Reserve Management Port for Cluster Member and select port8.
4 Select OK.
From the CLI, you can also configure a default route that is only used by the reserved
management interface.
To configure the reserved management interface - CLI

1 Log in to the CLI of any cluster unit.
2 Enter the following command to enable the reserved management interface, set port8
as the reserved interface, and add a default route of 10.11.101.100 for the reserved
config system ha
set ha-mgmt-status enable
set ha-mgmt-interface port8
set ha-mgmt-interface-gateway 10.11.101.100
end

01-420-99686-20101026 137
HA reserved management interface High availability
You can change the IP address of the primary unit reserved management interface from
the primary unit web-based manager. Configuration changes to the reserved
management interface are not synchronized to other cluster units.
To change the primary unit reserved management interface configuration -

web-based manager
1 From a PC on the internal network, browse to http://10.11.101.100 and log in to the
cluster web-based manager.
This logs you in to the primary unit web-based manager.
You can identify the primary unit from its serial number or host name that appear on the
System Information dashboard widget.
2 Go to System > Network > Interface and edit the port8 interface as follows:
Alias primary_reserved
IP/Netmask 10.11.101.101
Administrative Access Ping, SSH, HTTPS, SNMP
3 Select OK.
You can now log into the primary unit web-based manager by browsing to
https://10.11.101.101 and the primary unit CLI by using an SSH client to connect to
10.11.101.101.
At this point, you cannot connect to the subordinate unit’s reserved management interface
because it does not have an IP address. Instead, the following procedure describes
connecting to the primary unit’s CLI and using the execute ha manage command to
connect to that subordinate unit’s CLI to change the port8 interface. You can also use a
serial connection to connect to the cluster unit’s CLI. Configuration changes to the
reserved management interface are not synchronized to other cluster units.
To change subordinate unit reserved management interface configuration - CLI

1 Connect to the primary unit CLI and use the execute ha manage command to
connect to a subordinate unit CLI.
You can identify the subordinate unit from is serial number or host name. The host
name appears in the CLI prompt.
2 Enter the following command to change the port8 IP address to 10.11.101.102 and
set management access to https, ping, ssh, and snmp.
edit port8
set ip 10.11.101.102/24
set allowaccess https ping ssh snmp
end
You can now log in to the subordinate unit web-based manager by browsing to
https://10.11.101.102 and the subordinate unit CLI by using an SSH client to connect to
10.11.101.102.

138 01-420-99686-20101026
High availability HA reserved management interface
The following procedure describes how to configure the cluster to allow the SNMP server
to get status information from the primary unit and the subordinate unit. The SNMP
configuration is synchronized to all cluster units. To support using the reserved
management interfaces for, you must add at least one HA direct management host to an
SNMP community. If your SNMP configuration includes SNMP users with user names and
passwords, you must also enable HA direct management for SNMP users.
To configure the cluster for SNMP management using the reserved management
interfaces - CLI
1 Enter the following command syntax to add an SNMP community called Community
and add a host to the community for the reserved management interface of each
cluster unit. The host includes the IP address of the SNMP server (10.11.101.20).
config system snmp community
set name Community
edit 1
config hosts
edit 1
set ha-direct enable
set ip 10.11.101.20
end
end
2 Enter the following command syntax to add an SNMP user for the reserved
config system snmp user
edit 1
set ha-direct enable
set notify-hosts 10.11.101.20
end
3 Configure other settings as required.

01-420-99686-20101026 139
HA reserved management interface High availability

140 01-420-99686-20101026
Firewall
Firewall menu.
• Protection profile re-organization and enhancement
• Explicit Proxy improvements (including Citrix/TS support)
• Central NAT Table
Protection profile re-organization and enhancement

The way to configure UTM features in a firewall policy has dramatically changed in
FortiOS 4.0 MR2. This new re-organization allows you to select options individually, which
simplifies the configuration procedure for applying UTM features to a firewall policy.
The changes are:
• Profiles are configured within each of the UTM submenus, such as UTM > Antivirus.
The path is UTM > Antivirus > Profile.
• Profiles are available only in Antivirus, Email Filtering, Web Filtering, and VoIP.
• VoIP profile is introduced which allows you to configure a profile containing settings for
VoIP protocols, SIP and SCCP, that can then be applied to a firewall policy.
The protection profile menu in Firewall, (previously Firewall > Protection Profile) is no
longer available because of this re-organization. When upgrading to FortiOS 4.0 MR2, the
protection profiles that you previously created carry forward and are automatically
reorganized to the new organization arrangement.
Example
The following is an example of how to configure a profile in the UTM menu and then how
to apply it to a firewall policy. All profiles are applied to a firewall policy the same way as in
this example, even DLP sensors and protocol options.
To create an antivirus profile

1 Go to UTM > Antivirus > Profile.
2 Enter av_email in the Name field.
3 In the Virus row of the table, select the check box for POP3.
4 In the HTTP row of the table, select the check box for POP3, and in the Option column
of that row, select email_only from the drop-down list.
5 In the Method row, select Virus’s Incoming Interface from the drop-down list.
6 Select OK.
To apply the antivirus profile to a firewall policy

1 Go to Firewall > Policy > Policy.
2 Edit wan1-> internal row.
3 Select the check box beside UTM.

01-420-99686-20101026 141
Explicit Proxy improvements (including Citrix/TS support) Firewall
4 Select the check box beside Antivirus, and then select av_email from the drop-down
list.
5 Select OK.
VoIP profile
The VoIP menu in UTM contains configuration settings for creating multiple profiles for
applying SIP and SCCP protocols to firewall policies. The VoIP menu allows you to
configure specific SIP or SCCP settings that will monitor and examine these protocols
when applied to a firewall policy. For example, you create a profile that is only for SIP calls
and enable logging which includes logging of violation traffic.
When configuring a VoIP profile, you can enable logging of SIP and/or SCCP traffic,
including violation of traffic. These logs appear in the Log Access menu of the Log&Report
menu.
Explicit Proxy improvements (including Citrix/TS support)

The explicit proxy improvements include Citrix/TS support. This provides support for
setting a web proxy address to point to a FortiGate unit from the Citrix server. The
behaviors for both the FortiGate unit and the Citrix server is as follows:
FortiGate unit
• Web-proxy is a special source added when used as a source interface of a firewall
policy. When the traffic hits the explicit-web-proxy, it is considered its source
interface as web-proxy when matching the firewall policy.
• Firewall policy is added from web-proxy to any other interface or zone for secured
explicit web proxy. Source addresses are the client IP addresses and destination is
the targeted server IP addresses, similar to a firewall policy. Authentication and
protection profile is supported for services that are supported by explicit web proxy.
Citrix
• Administrator on a Citrix server can set an explicit web proxy address to point to a
FortiGate unit so that the system uses the FortiGate unit as an explicitly proxy. The
Citrix server can then send the authentication information to the FortiGate unit.
• Using the authentication information, the FortiGate unit can block or inspect the
Citrix user traffic, based on individual user names, not source IP addresses.
Basically, the FortiGate unit will co-relate the user information from Citrix server with
the user group information in its policy, and then apply it to the right profile that is
associated with each user group.
• The FortiGate unit, if logging is enabled for web filtering, generates logs with the
user information for each action taken to block or a URL category violation.
In each VDOM, a read-only zone web proxy is created by default when an explicit web
proxy is configured. This type of proxy can only be used as a source interface of a firewall
policy. A firewall policy that uses web-proxy as srcintf defines secure policy for secured
explicit web proxy. The command syntax is as follows:
configure firewall policy
edit 1
set srcintf web-proxy
set dstintf <destination interface_or_zone>
set srcaddr <source_address>
set dstaddr <destination_address>

142 01-420-99686-20101026
Firewall Central NAT Table
set action {allow | deny}
Central NAT Table

In the Policy menu, a new menu is available for configuring NAT rules called Central NAT
Table. NAT rules can be applied to a firewall policy.
The Central NAT Table allows users to create NAT rules, as well as view NAT mappings
that are set up by the global firewall table. You can use these NAT rules on firewall policies
by selecting Use Central NAT Table option within the policy.
Configure central NAT rule sets in Firewall > Policy > Central NAT Table using the
following table.
Central NAT Table page

Lists all the NAT rule sets that you have configured. On this page, you can edit, delete, move, or
create a new NAT rule set. You can also organize NAT rule sets within the list, in the order that you
want.
Create New Creates a new NAT rule set. When you select Create New, you are automatically
redirected to the New Nat page where you can configure a NAT rule set.
Edit Modifies settings within the NAT rule set. When you select Edit, you are
automatically redirected to the Edit Nat page where you can modify the settings of
the NAT rule set.
Delete Removes a NAT rule set from within the list on the Central NAT Table page. You
can also remove multiple NAT rule sets at once within the list, or remove all the
sets within the list at once as well.
To remove multiple NAT rule sets in the list, on the Central NAT Table page, in
each of the rows of the sets you want removed, select the check box and then
select Delete.
To remove all NAT rules sets in the list, on the Central NAT Table page, select the
check box in the check box column, and then select Delete.
Enable Enables the NAT rule set so that it can be used. When the set is enabled, the
Status column displays a check mark in the check box.
Disable Disables the NAT rule set so that it cannot be used. When the set is disabled, the
Status column does not display a check mark in the check box, and that NAT rule
set’s row is grayed.
Insert Inserts a new NAT rule set above a NAT rule set. When you select Insert, you are
automatically redirected to the New Nat page.
Move To Moves a NAT rule set either before or after a NAT rule set in the list. When you
select Move, you are automatically redirected to the Move Policy page.
When you move NAT rule sets within the list, their individual NAT ID number does
not change when it is moved to its new location in the list. For example, Policy ID
contains 1, with the Policy ID field containing 10; that NAT rule set (1) is moved to
the tenth row in the list, but still keeps its original ID number, 1.
Policy ID The current row that is highlighted, and that will be moved to a different place
(Move Policy within the list. For example, Policy ID contains 1, with the Policy ID field
page) containing 10; that NAT rule set (1) is moved to the tenth row in the list.
Move To Select Before to move a NAT rule set before another set, and then enter the ID
(Move Policy number of the set that will come before it. The ID is the number from the NAT ID
page) column. For example, Policy ID is 1; 2 is entered in the Policy ID field so that 2
comes before 1 in the list.
Select After to move a NAT rule set after another set, and then enter the ID
number of the set that comes after it. The ID is the number from the NAT ID
column. For example, Policy ID is 4; 3 is entered in the Policy ID field so that 3
comes before 4.
Status Indicates whether the NAT rule set has been enabled or disabled. The check
mark in the check box indicates that it is enabled. If the row is grayed, and there is
no check mark in the check box, then the NAT rule set is disabled.

01-420-99686-20101026 143
Central NAT Table Firewall
NAT ID The NAT identification number. This number is used when indicating where to
move the NAT rule set within the list.
Original The source IP address. You can add multiple IP addresses to the Source Address
Address by select Multiple. When you select Multiple, the Choose Multiple Address
window appears.
To choose multiple addresses, from the Choose Multiple Addresses window,
select the address in Available Addresses, and then select the down arrow to
move it to Members:.
Original Port The original source port number range.
Translated The translated IP address range
Address
Translated Port The translated port number range.
New Nat page
Provides settings for configuring the NAT rule set.
Source Address Select the source IP address from the drop-down list. You can optionally create a
group of source IP addresses when you select Multiple in the drop-down list. You
can also create a new source IP address when you select Create New in the
drop-down list.
Translated Select the dynamic IP pool from the drop-down list.
Address
Original Port Enter the port that the address is originating from.
Translated Port Enter the translated port number range. The number in the Original Source Port
field must be greater than the port number that is entered in this field.

144 01-420-99686-20101026
User
User menu.
• LDAP/RADIUS password renewal
• BGP support for four-byte AS Path
• IM users
LDAP/RADIUS password renewal

You can now configure settings for password renewal and notice of expiry for LDAP
servers. You can also now configure support for UTF-8 encoding log ins for RADIUS
servers.
Configuration of these settings is available in the CLI.
For RADIUS:
config vpn ssl settings
set force-utf8-login {enable | disable}
end
For LDAP password renewal:
config user ldap
edit <name>
set password-expiry-warning {enable | disable}
set password-renewal {enable | disable}
end
BGP support for four-byte AS Path

FortiGate models now support four-byte AS Path. This new BGP capability provides AS
with a four-byte octet number instead of the current two-byte octet number. For more
information about this new BGP capability, see RFC 4893.
IM users
Previously, by default, the IM tabs in User > IM and User > Monitor > IM appeared by
default. The new menu arrangement in the User menu in FortiOS 4.0 MR2 hides these
menus by default until you create an IM user in the CLI.
The menus for IM users appear in User > User and User > Monitor in the web-based
manager after configuring an IM user using the config imp2p command.

01-420-99686-20101026 145
IM users User

146 01-420-99686-20101026
UTM
UTM menu.
• FortiGuard Web Filtering quotas
• Skype control improvements
• Flow-based antivirus database
• Extreme antivirus database
• SSL proxy exemption by FortiGuard Web Filter category
• Monitoring application control traffic
• Applying traffic shaping settings to an application control list
FortiGuard Web Filtering quotas

FortiGuard Web Filtering quotas allow administrators to set time limits for authenticated
users when those users access web sites that fall under the FortiGuard Web Filtering
categories, category groups and classifications.
The administrator, who must have read and write privileges, defines each user group’s
time limits for the category, category group and classification. Quotas are calculated
separately for each user and the daily quota amounts used are reset at midnight. The
quota is applied to each user individually so the FortiGate unit must be able to identify
each user. Quotas are ignored if applied to a firewall policy that does not require user
authentication.
When a user first attempts to access a URL, they are prompted to authenticate with the
FortiGate unit. When they provide their username and password, the FortiGate unit
recognizes them, determines their quota allowances, and monitors their web use. The
category and classification of each page they visit is checked, and the FortiGate unit
adjusts the user’s remaining available quota for the category or classification.
The following procedure explains how to configure FortiGuard Web Filtering quotas in an
existing web filter profile.
To configure FortiGuard Web Filtering quotas

1 Go to UTM > Web Filter > Profile.
2 Edit an existing web profile.
3 In the FortiGuard Web Filtering row, select the check box for HTTP to enable
FortiGuard Web Filtering.
If you require FortiGuard Web Filtering for HTTPS, select that check box.
4 Expand FortiGuard Web Filtering.

01-420-99686-20101026 147
Skype control improvements UTM
5 In the table under FortiGuard Web Filtering, in the FortiGuard Quota area, use the
following to configure the settings you want for each category, category group and
classification:
Disable By default, quotas are disabled for all categories, category groups and
classifications. Select Enable to allow configuration of quota settings.
Enable Select to allow access to configuring the quota settings.
Exempt The quota checking sequence occurs for every URL that the user accesses and
this can cause unexpected behavior. Select to effectively ignore the category,
category group, or classification entirely. Use when accessed web pages load
elements from other sites that contain different category ratings. For example,
pages that load ads from advertising sites.
This action does not stop an already running quota timers.
Quota Enter a number for the time, which can be in hours, minutes or seconds. Select
the type of time from the drop-down list, Minute(s) Hour(s) or Second(s).
6 Select OK.
Viewing FortiGuard quota usage

You can view current web quota usage from UTM > Web Filter > FortiGuard Quota. This
list displays all of the users, which are sorted by user names, who have used up some of
their quota time. The list also displays how much time has been used. You can view each
individual user’s quota by selecting the View icon in the row of the user.
Skype control improvements

The FortiGate unit can now learn IP addresses and ports that are used by Skype. This
type of detection provides a much better way for the FortiGate unit to detect Skype users,
because previously, Skype detection was based on packet patterns. Since the traffic is
encrypted, some connections eventually sneak out, and the Skype client is connected
regardless of whether the connection was blocked or not.
The way the FortiGate unit learns IP addresses and ports used by Skype is an internal
change, so there is no configuration required in the CLI or in the web-based manager.
Flow-based antivirus database

The flow-based antivirus database, located in UTM > Antivirus > Virus Database, uses the
FortiGate IPS engine to examine network traffic for viruses, worms, trojans, and malware
without the need to buffer the file being checked.
This flow-based scanning includes fast scanning and no maximum file size. Flow-based
scanning eliminates the maximum file size limit since it does not require that the file be
buffered during the scan as it passes through the FortiGate unit, packet-by-packet. This
elimination allows the client receiving the file data, to receive it immediately.
The trade-off for these advantages is that flow-based scans detect a smaller number of
infections. Viruses in documents, packed files, and some archives are less likely to be
detected because the scanner can only examine a small portion of the file at any moment.

148 01-420-99686-20101026
UTM Extreme antivirus database
Extreme antivirus database

The extreme antivirus database contains both “In the wild” viruses and all available “zoo”
viruses. The “zoo” viruses are viruses that are no longer seen in recent virus studies, and
are largely dormant today. Some zoo viruses may rely on operating systems and
hardware that are no longer widely used.
The extreme antivirus database is located in UTM > Antivirus > Virus Database. This
database provides better flexibility, allowing you to have maximum protection against both
current and older viruses, without sacrificing performance. For example, testing if the
FortiGate unit is catching all viruses.
The extreme antivirus database is supported on FortiGate models with large storage
space.
SSL proxy exemption by FortiGuard Web Filter category

Administrators can now exempt a FortiGuard Web Filter category from SSL content
inspection on higher-end FortiGate models. This is configured in the CLI using the
following command syntax:
config webfilter profile
edit <profile_name>
config ftgd-wf
set ssl-exempt {all | <category_str>}
end
Use the get command to view all available category codes with descriptions. For
example, g01 Potentially Liable.
When the exemption is configured, the SSL proxy prevents the decryption of sessions to
the specified FortiGuard Web Filter categories by behaving this way:
• Reads the client hello but does not complete the handshake.
• Connects to the server.
• Passes the client hello to the server and reads the server hello.
• Extracts the common-name from the server hello and checks it with the server IP
address from the FortiGuard Web Filtering lists.
• If the traffic will be exempted, the client and SSL handshakes are completed and
clear-text traffic is passed through the HTTP proxy to handle all scanning options that
are in place.
Application control enhancements

In this release, you can configure three new settings within an application control list:
monitor application traffic, apply traffic shaping settings, and enable packet logging. The
following explains how to monitor application control traffic and apply traffic shaping
settings to an application control list.
Enabling packet logging in an application control list is similar to enabling packet logging.
Packet logging in an application control list can be used for false positive analysis or
forensic analysis.

01-420-99686-20101026 149
Application control enhancements UTM
Monitoring application control traffic

The application control monitoring feature provides the ability to monitor application
control traffic on your network. When this feature is enabled in an application control list
entry and the list is selected in a firewall policy, all the detected traffic required to populate
the selected charts is logged to the SQL database on the FortiGate unit hard drive.
The charts are available for display in Log&Report > Report Access > Executive
Summary. The advantage over these charts is that the information is stored on the hard
drive, and if you need to restart the system, the information is not affected. The monitor
widgets that are available, such as Top Application Usage, are reset whenever the system
is reset. The charts within the Executive Summary page provide more detail than the
widgets do within the Dashboard menu.
The application control monitoring feature is available only on FortiGate units that have
internal hard drives.
You can enable application control monitoring within the application control list (UTM
>Application Control > Application Control List), by selecting the check box beside Enable
Monitoring. The application control list must then be applied to the firewall policy.
The application control monitoring feature is configured within the application control list
itself. Use the following procedure to enable monitoring.
To configure application control monitoring

1 Go to UTM > Application Control > Application Control List.
2 Edit the application control list that you want to enable monitoring on.
If you have not created an application control list for monitoring, create a new one
before proceeding. For example, an application list that contains only P2P
3 On the Edit Application Control List page, select the check box beside Enable
Monitoring.
5 Edit the firewall policy that you want to apply monitoring on.
6 In the UTM section, select the check box beside Enable Application Control.
When you enable application control, three check boxes appear: Top 10 Applications,
Top 10 P2P Users and Top 10 Media Users.
7 Select the application control item that has monitoring enabled on it from the
drop-down list.
8 Select the check boxes beside Top 10 Applications, Top 10 P2P Users and Top 10
Media Users.
9 Go to Log&Report > Report Access > Executive Summary.
There are three charts within the Executive Summary page that will display the
application control monitoring information, one for top 10 applications, media users and
P2P users.
10 Add the following widgets to the Executive Summary page:
• appcrtl.Count.Bandwidth.Top10.Apps.last24h(Graph)
• appcrtl.Count.Bandwidth.Top10.MediaUser.last24h(Graph)
• appcrtl.Count.Bandwidth.Top10.P2Puser.last24h(Graph)
When application control logs begin recording, you will see information about the top 10
applications, media users and P2P users in the charts. You can edit these charts if you
want by select the Edit icon in the title bar area.

150 01-420-99686-20101026
UTM Application control enhancements
Applying traffic shaping settings to an application control list

You can apply traffic shaping settings to an application control list to better control the
application traffic on your network. When you apply traffic shaping to an application control
list, it allows you to limit or guarantee the bandwidth available to the application or
applications specified in the application control list. You can also prioritize the traffic by
using traffic shaping. You can apply traffic shaping only to application lists that have Action
set to Pass. When Action is set to Pass, the traffic shaping settings are displayed. They
are disabled by default.
You must have a traffic shaper configured before enabling this option because you cannot
configure a traffic shaper from within the application control entry.
Note: You cannot edit the existing Implicit 1 or Implicit 2 application entries to include traffic
shaping.
The following procedure assumes that you have already configured a traffic shaper and an
application control list.
To apply traffic shaping to an application entry

2 Edit the application control list that you want to apply the traffic shaper to.
3 Within the application control list, edit an application control entry.
If you want to, you can create a new entry by selecting Create New.
4 Select Pass from the Action drop-down list.
Traffic Shaping and Reverse Direction Traffic Shaping options appear.
5 Select the check box beside Traffic Shaping, and then select the traffic shaper from the
drop-down list.
If you want to include reverse direction traffic shaping, select the check box beside
Reverse Direction Traffic Shaping, and then select the traffic shaper from the
drop-down list.
6 Select OK.

01-420-99686-20101026 151
Application control enhancements UTM

152 01-420-99686-20101026
VPN
VPN menu.
• FortiMobile SSL-VPN app
• L2TP and IPSec support
FortiMobile SSL-VPN app

The FortiMobile SSL-VPN app allows you to remotely connect to your FortiGate unit
without a browser or computer. The app uses only SSL-VPN web mode. SSL VPN web
mode provides remote users with a fast and efficient way to access server applications
from any client computer that is equipped with a web browser. Configuring the SSL VPN
web mode on the FortiGate unit involves enabling the SSL VPN feature and selecting the
appropriate web portal configuration in the user group setting.
The FortiMobile SSL-VPN app is found on Apple’s iTunes app store, and is available for
free; however, you must have an iTunes account to access the app and download it from
the store. The Fortinet SSL-VPN app supports iPhone and iPod touch hardware running
OS 3.0 and above, and can communicate with a FortiGate unit running FortiOS 4.0 MR2
or higher.
The FortiMobile SSL-VPN app includes configuration for:
• gateway (FortiGate IP address)
• user name
• password
When using the FortiMobile SSL-VPN app, the following occurs:
• The app becomes a browser that connects to the web mode to get the bookmarks
• When you tap on the bookmark, it starts Mobile Safari and shows the bookmark
content page
• HTTP/HTTPS type bookmarks are only supported; other types are hidden.
• You can add, edit, or delete user-defined bookmarks
• Tunnel mode is not supported.
Note: You must have an iTunes account to access the FortiMobile SSL-VPN web access
app.
L2TP and IPSec support

L2TP and IPSec is supported for native Windows XP, Windows Vista, and Mac OSX
native VPN clients. However, in Mac OSX (OSX 10.6.3, including patch releases) the
L2TP feature does not work properly on the Mac OS side. The L2TP-IPSec between the
FortiGate unit and Mac OSX native client fails during L2TP negotiation. This negotiation
failure is caused by a bug in the Mac OSX L2TP client.

01-420-99686-20101026 153
L2TP and IPSec support VPN
This negotiation failure is clearly seen in the log message, within the hostname field; the
hostname field contains no information at all.

154 01-420-99686-20101026
Endpoint
This section explains the new features and changes to existing features that concerns the
Endpoint menu on the web-based manager.
In FortiOS 4.0 MR2, this menu was renamed from Endpoint NAC to Endpoint.
• Endpoint menu enhancements
• Endpoint application enforcement
Endpoint menu enhancements

In FortiOS 4.0 MR2, several enhancements were made to the Endpoint NAC menu,
including changing its name to Endpoint. The enhancements provide a network scanning
feature that was previously only available on FortiAnalyzer units, as well as configuration
of application sensors, which were previously application detection lists.
The Endpoint menu contains the following menus:
• NAC
• Profile
• Application Sensor
• Application Database
• FortiClient
• Asset
• Scan
• Monitor
• Endpoint Monitor
The Network Vulnerability Scan provides a way to scan vulnerabilities on the FortiGate
unit. A schedule for a scan is configured on the Network Scan page. An asset provides
information about what type of scan will occur, as well as the IP address host or range.
Endpoint application enforcement

Endpoint application enforcement is an extension of the Endpoint Application Detection
feature. This new enforcement allows you to quarantine hosts that are not running
software required by your company or organization’s policy. Previously, when defining an
application, you specified a profile of violating applications. This new extension allows you
to now toggle between violating and required applications. This extension is available in
Endpoint > NAC > Application Sensor.
The following is an example of the CLI command syntax to configure endpoint application
enforcement:
config endpoint-control app-detect rule-list

01-420-99686-20101026 155
Network Vulnerability Scan Endpoint
edit rule-list
config entries
edit 1
set application 379
set category 0
set vendor 446
set action allow
set status installed
next
end
set comment “for branch office use only”
set other-application-action deny
end
end
Network Vulnerability Scan

Caution: In FortiOS 4.0 MR2 GA build-272, the network vulnerability scan feature does not
work properly. Fortinet recommends upgrading to FortiOS 4.0 MR2 Patch 1 release
(build-279). This patch release resolves the issues as well as adds the Discovery Assets,
Start Scan, and Last Scan icons to the Asset page. These are explained in this topic.
The Network Vulnerability feature, previously found only on FortiAnalyzer units and
FortiScan, allows you to analyze information as well as ensure and enforce PCI
compliance. This feature is used for larger enterprises.
Network Vulnerability Scan options and settings are found in Endpoint > Network
Vulnerability Scan. When you are ready to start configuring network vulnerability scan
options, you must ensure that an asset is configured and then you can schedule a scan.
An asset must be configured because it is used by the FortiGate unit as instructions on
what to scan and whether there is windows authentication required or unix authentication
required.
When the scan is performed, it automatically applies all assets or asset groups that are
enabled. The scan behaves as follows:
• all Host assets are discovered as specified in the host definition
• all discovered hosts are scanned for the configured sensors, port scan, and so on
• all IP Range assets are discovered as specified in the range definition
• scanning is run for each unique IP in the list, and up to the maximum number of IPs
supported per-platform
• results from the scan are stored either on the FortiAnalyzer unit, or in the SQL
database
In FortiOS 4.0 MR2 Patch 1 release, you can discover assets or start a scan from the
Asset page. You can also view when the last scan was performed, which is displayed
beside Last scan:. For example, if a scan was performed over the weekend, it displays
Last scan: 2010-06-05 13:15:50.
Configuring assets
Assets must be configured so that the unit knows what to scan.
Configure an asset in Endpoint > Network Vulnerability Scan > Asset using the following
table. The information in the following table is based on FortiOS 4.0 MR2 Patch 1 release
because it resolves issues in the GA release.

156 01-420-99686-20101026
Endpoint Network Vulnerability Scan
Asset page
Lists each individual asset that you created. On this page, you can edit, delete or create a new
asset.
Create New Creates a new asset. When you select Create New, you are
automatically redirected to the new asset page, called Asset in the
web-based manager.
Edit Modifies settings in an asset. When you select Edit, you are
automatically redirected to the edit asset page, called Asset in the
web-based manager.
Delete Removes an asset from the list on the Asset page. You can also
remove multiple assets from the list, or remove all assets from the list
as well.
To remove multiple assets in the list, on the Asset page, in each of the
rows of the sets you want removed, select the check box and then
select Delete.
To remove all NAT rules sets in the list, on the Asset page, select the
check box in the check box column, and then select Delete.
Last scan: Displays when the last scanned occurred. The time format is in year,
[yyyy-mm-dd hh:mm:ss] month, day, and then the 24 hour format. For example, a scan was
performed at 1 pm, the time displays 2010-06-04 13:00:00.
Start Running. Started: Appears when a user selects Start Scan, and the FortiGate unit begins
[yyyy-mm-dd hh:mm:ss] scanning the network. Displays the time when the scan began.
Stop Appears when a user selects Start Scan. Select whenever you want to
immediately stop scanning the network.
Assets Found (n) Displays how many assets where found. If there were any found, you
can select Assets Found and view the Assets window, which allows
you to import the assets to the FortiGate unit. Any duplicates that are
found during the importing process are removed.
Discover Assets Select to find out if there are any assets on the network. The FortiGate
unit uses the asset list that you created to perform the scan.
Start Scan The last discovery that the asset found.
Name The name of the asset.
IP Address/Range The IP address and/or range entered for that asset.
If Host was chosen as the type for the asset, then the IP address of
the host displays. If Range was chosen as the type for the asset, the
IP address range appears.
Enable Displays whether or not the asset is enabled for scanning.
Last Discovery The last discovery that was found.
Asset Settings page
Provides settings for configuring an asset.
Name Enter a name for the asset that you are creating.
Type Select Host to configure the host’s IP address. Select Range to
configure the IP address range.
IP Address Enter the IP address of the host, or the IP address range. This
depends on what type you selected in Type.
Scan Type Select Asset Discovery Only to use only the asset for scanning. Select
Vulnerability Scan to scan for various vulnerabilities.
Windows Authentication Select to use authentication on a Windows operating system. Enter
the username and password in the fields provided. The fields appear
after selecting Windows Authentication.
Unix Authentication Select to use authentication on a Unix operating system. Enter the
username and password in the fields provided. The fields appear after
selecting Unix Authentication.

01-420-99686-20101026 157
Network Vulnerability Scan Endpoint
Scheduling a scan
You can configure settings to schedule when a scan is performed by the FortiGate unit.
Configure a schedule in Endpoint > Network Vulnerability Scan > Scan using the following
table.
Network Scan page

Provides settings for configuring a schedule and what type of scanning you want the FortiGate unit
to perform.
Scan Mode Select the mode the FortiGate unit will use to scan for vulnerabilities.
• Quick – checks only the most commonly used ports
• Standard – checks only the ports used by the most known applications
• Full – checks all TCP and UDP ports
Schedule Select the schedule to begin and end the vulnerability scan.
• Manually – performs a scan only on request
• Schedule – a schedule of when the scan will be performed
Recurrence Select to have the schedule occur on a daily, weekly, or monthly basis. If you
select Weekly, the Day of Week drop-down list appears. If you select Monthly,
the Day of Month drop-down list appears.
Time Select the time to start the schedule, in the format HH:MM.
Day of Week Select a day of the week from the drop-down list when you want to schedule a
scan during the week.
Day of Month Select a day of the month from the drop-down list when you want to schedule a
scan on that day of the month.

158 01-420-99686-20101026
WAN Opt. & Cache
This section explains the Web Cache list, a new feature for FortiOS 4.0 MR2, which
concerns the WAN Opt. & Cache menu.
Web Cache exempt

A new exempt list is now available for the Web Cache feature. This new list allows users
to exempt URLs from being cached. You can configure the list either in the CLI or the
web-based manager.
To configure the exempt list - web-based manager

1 Go to WAN Opt. & Cache > Cache > Exempt List.
2 Select Create New.
3 Enter the URL address in the URL Pattern field.
4 If you do not want the URL address to be considered, select the check box beside
Enable to disable the URL.
5 Select OK.
The following is an example of a configured Web Cache exempt list when configured
using the CLI.
config wanopt webcache
set explicit enable
set cache-exempt enaqble
config cache-exemption-list
edit 1
set url-pattern 192.168.1.99
set status disable
next
edit 2
set url-pattern example.com/pic123/321
next
edit 3
set url-pattern 10.10.10.1
end

01-420-99686-20101026 159
Web Cache exempt WAN Opt. & Cache

160 01-420-99686-20101026
FortiOS Carrier
This section explains the new features and changes to existing features for FortiOS
Carrier in FortiOS Carrier 4.0 MR2.
FortiOS Carrier 4.0 MR2 also contains the same redesign of the web-based manager as in
FortiOS. For more information about the changes, see “The redesigned web-based
manager” on page 109.
• Opera Mini Browser support
• MMS filtering enhancements
• Carrier menu in UTM
• Profile Group
Opera Mini Browser support

The Opera Mini is a service for end users to browse web pages from MIDP 1 and MIDP 2
compliant handsets. This new feature allows for extraction of URLs from the Opera client
when it requests them, as well as updating the HTTP header if a block page is returned.
The following CLI command syntax is used when configuring support for handling of
Opera Mini browser traffic with VDOMs configured:
config vdom
edit <vdom_name>
edit <name>
config url-extraction
set server-fqdn <fqdn_name>
set redirect-header <x-redirect>
set redirect-url <url_address>
set redirect-no-content {enable | disable}
end
next
end
When you have configured the Opera Mini browser support, you also need to configure
the special requests that the client generates that need to be pass directly through to the
Opera Mini servers. For example, End-User License Agreement requests to eula.* .
The following CLI command syntax example is used when configuring the special
requests for the Opera Mini servers.
config webfilter urlfilter
edit 0
config entries
edit “*/server:test”
set action pass
set type wildcard
next
edit “*/server:t0”
set action pass

01-420-99686-20101026 161
MMS filtering enhancements FortiOS Carrier
set type wildcard

next
edit “*/eula:*”
set action pass
set type wildcard
next
edit “*/b:*”
set action pass
set type wildcard
next
edit “*/search:*”
set action pass
set type wildcard
next
edit “*/news:*”
set action pass
set type wildcard
next
edit “*/feeds:*”
set action pass
set wildcard
next
edit “*/opera:”
set action pass
set type wildcard
next
edit “*/operaette:”
set action pass
set action wildcard
next
edit “*/javascript:”
set action pass
set action wildcard
next
end
set name “opera-mini-special-requests”
end
end
MMS filtering enhancements

In FortiOS 4.0 MR2, you can now block MMS messages by a checksum value against the
attachment and image file types within the message.
You can configure the checksum value for blocking MMS messages against the
attachment by going to UTM > Carrier > MMS Content Checksum, and then apply it to the
MMS Profile in UTM > Carrier > MMS Profile.
In the MMS Scanning section of the New MMS Profile page (or if you are editing an
existing MMS Profile, the Edit MMS Profile page), you select the checksum from the drop-
down list in the MMS Content Checksum line. You can select the checksum for each of the
available MMS protocols within the MMS Content Checksum line.
When the checksum is enabled, the content will be verified as a match or not, and if
matched the attachment will be blocked.

162 01-420-99686-20101026
FortiOS Carrier Carrier menu in UTM
The file extension for blocking images in MMS messages is:

• JPG
• GIF
• TIFF
• PNG
• BMP
You must first configure a file filter that contains the file types that you want blocked when
MMS messages are scanned. The file filter is then applied to the MMS profile.
Example of blocking images for MMS messages

This example shows how to configure the file filter that contains the file types that you
want blocked when the FortiGate unit is scanning MMS messages. This example includes
how to apply that file filter to an MMS profile which is then applied to a firewall policy.
To configure a file filter

1 Go to UTM > Antivirus > File Filter.
3 Enter MMS_filter in the Name field on the New List page and then select OK.
4 Select Create New on the File Filter Settings page.
5 Select File Type in the drop-down Filter Type list.
6 In the File Type drop-down list, select JPEG.
7 In the Action drop-down list, select Block.
8 Make sure Enable is selected and then select OK.
9 Repeat steps 4-8 to include GIF and TIFF file types in the list.
To apply the file filter to the MMS profile

1 Go to UTM > Carrier > MMS Profile.
2 On the Profile page, edit the MMS_filter_profile profile.
3 On the Edit MMS Profile page, expand the MMS Scanning section to reveal the
options.
4 In the File Filter line, select MM1, MM4 and MM7 check boxes.
5 In the File Filter line, select the file filter in the Options drop-down list.
6 Select OK to save the changes.
Carrier menu in UTM

In the UTM menu, a new menu called Carrier is included. It contains all MMS and GTP
features previously found in a protection profile. This new menu provides a central location
for configuring Carrier UTM features. From the Carrier menu, you can configure an MMS
profile or GTP profile and then apply to firewall policies.

01-420-99686-20101026 163
Profile Group FortiOS Carrier
The Carrier menu also provides configuration of MMS content checksum lists, notification
lists, carrier endpoint filter lists, and IP filter lists. You can view message floods, or a
volume of messages that have been sent by one subscriber, from the Message Flood
menu. This menu also provides filtering capabilities so that you can view specific
messages. You can also view duplicate messages that were sent by senders from the
Duplicate Message menu. For more information about the features available in UTM >
Carrier, see the FortiOS Carrier MMS Protection chapter.
Profile Group
A profile group is a group of UTM features, including replacement message groups, that
can be applied to a firewall policy. A profile group allows you to group individual profiles for
each UTM function that you would otherwise apply individually to the firewall policy. These
UTM features include the following:
• Protocol options
• antivirus profiles
• IPS sensors
• web filter profiles
• email filter profiles
• DLP sensors
• application control lists
• VoIP profiles
• MMS profiles
• replacement message groups
If you want to include a replacement message group in a profile group, you must first
configure a replacement message group in System > Config > Replacement Message
Group. For more information about the features available in UTM > Carrier, see the
FortiOS Carrier MMS Protection chapter.
The FortiOS Carrier Dynamic Profile feature now dynamically assigns profile groups to
traffic.
Configuring a profile group

The following procedures explains how to configure a profile group and then apply that
profile group to a firewall policy. If you are including a replacement message group in the
profile group, you must configure the replacement message group first.
To configure a profile group

1 Go to UTM > Profile Group > Profile Group.
3 On the New Profile Group page, enter a name for the profile group and then select the
check box beside one or more of the UTM features that are listed.
4 After selecting a check box, make sure to select the profile, sensor or group in each of
the UTM features drop-down lists.
5 Select OK.

164 01-420-99686-20101026
FortiOS Carrier Profile Group
To apply the profile group to a firewall policy

2 Edit the firewall policy that you want to apply the profile group to.
3 On the Edit Policy page, select Group in the Profile Type row.
4 Select the check box beside Profile Group and then select the profile group from the
drop-down list.
5 Select OK.

01-420-99686-20101026 165
Profile Group FortiOS Carrier

166 01-420-99686-20101026
Logging and reporting
This section includes all new features and changes to existing features that concern the
Log&Report menu on the web-based manager.
• Archiving support for local hard drives
• Log viewing enhancement
• Report enhancements
Note: The basic traffic reports that were available in Log&Report > Report Access >
Memory are not supported.
Archiving support for local hard drives

FortiGate units with local hard drives can now archive logs, which includes IPS packet
logs. This feature is supported only on FortiGate models that contain a new generation
HDD, an ASM-S08 or ASM-SAS hard disk, or FMC or FSM module storage.
There are now settings for rolling logs, as well as archives, and deleting logs on the local
hard disk. You can configure archiving to the local hard disk by using the following
command syntax in the CLI:
config log disk filter
set dlp-archive {enable | disable}
end
Log viewing enhancement

When accessing log messages, you can now view them from a table within the page. The
table, which appears on the right side of the page that contains log messages, provides a
more clear view of each of the fields that are within a log message. The table provides
next and previous arrows, allowing you to view each log message from the table.
This table appears when you select a row within the log messages’ page and is available
until you close the table.
To view log messages using the log table

1 Go to Log&Report > Log Access.
2 Select the menu that you want to access logs from.
For example, the DLP menu.
3 From within the page, select inside the row of the log message that you want to view.
The log message row is highlighted and the log table appears, located on the right side
of the page.

01-420-99686-20101026 167
Report enhancements Logging and reporting
Report enhancements
You can now configure reports that are based on logs stored on your FortiGate unit. These
new reports are called FortiOS reports. The Report Config menu provides settings for
configuring the report’s layout and schedule. This enhancement allows you to create and
generate reports directly on the FortiGate unit itself, without having to use a FortiAnalyzer
unit.
The Reports Config menu contains only the menus that are available for the remote
logging configuration. For example, on a FortiGate unit with an SQL database (which has
been configured to store logs), contains the menus Theme, Layout, Chart, and Image.
However, on another FortiGate unit that has been configured to store logs on a
FortiAnalyzer unit, only the FortiAnalyzer menu appears.
Both the menus, Report Config and Report Access, may not appear after upgrading to
FortiOS 4.0 MR2. You must use the following command syntax to enable them on the
web-based manager.
config log fortianalyzer setting
set gui-display enable
end
The Report Config menu contains the following menus:
• Theme – create a simple page layout with report title which you can then apply to a
report layout
• Layout – create a report that includes a theme, chart, image and schedule when the
report will be generated
• Chart – create different charts that will gather specific log information that displays
within the chart
• Image – import your company’s logo to include it within the report
A report is generated similarly to how a report is a generated on a FortiAnalyzer unit.
These new reports are available only on FortiGate units with hard drives that an SQL
database has been configured.
Note: Sending out a report as an email attachment, or uploading report files to a specific
server is not supported in FortiOS 4.0 MR2.

• Configuring a theme
• Configuring a report layout
• Importing images
• Importing images
• Viewing generated FortiOS reports
Configuring a theme
A theme allows you to configure how the information displays on the page, as well as the
type of font, page orientation, and if there will be multiple columns. After a theme is
configured, you can then apply it to the report’s layout. Themes are configured only in the
CLI.
If you want, you can apply the two default themes that are available in the Add Report
Layout page.

168 01-420-99686-20101026
Logging and reporting Report enhancements
For more information about the theme commands, see the FortiGate CLI Reference.
To configure a theme for a report, log in to the CLI and then enter the following commands.
config report theme
edit <theme_name>
set column-count [ 1 | 2 | 3]
set default-html-style <string>
set default-pdf-style <string>
set graph-chart-style <string>
set heading1-style <string>
set hline-style <string>
set image-style
set normal-text-style
set page-footer-style
set page-header-style
set page-orient {landscape | portrait}
set page-style
set report-subtitle-style
set report-title-style
set table-chart-caption-style
set table-chart-even-row-style
set table-chart-head-style
set table-chart-odd-row-style
set table-chart-style
set toc-heading1-style
set toc-title-style
end
When you are choosing a setting for any of the above commands (except for column-
count), enter ? to view the choices that are available.
You can configure a specific style that is then applied to the theme using the config
report style command syntax. You must first select the settings in the options
variable before you can configure the styles for each.
Importing images
You can import an image to use for a report. The image formats that are supported are
JPEG, JPG and PNG.
Import images from Log&Report > Report Config > Image using the following table.
Image page
Lists all the images that you have imported. On this page, you can delete an image, import an image
from your local PC, or view an image.
Delete Removes an image from the list on the page. You can remove multiple images,
or all images at once.
To remove multiple images from the list, on the Image page, select the check
box in each of the rows of the images you want to remove, and then select
Delete.
To remove all images from the list, on the Image page, select the check box in
the check box column, and then select Delete.

01-420-99686-20101026 169
Import Imports an image from your local PC.

View Displays the image. When you select View, you are automatically redirected to
the View Image page where the image displays. Select Return to go back to the
Image page.
Image Name The file name of the image.
Thumbnail A thumbnail image of the actual image you imported.
Import Image File page
Provides settings for importing images.
File to Import Enter the location of the image on the local PC or select Browse to locate the
image file. Select OK to start importing the image file.
Configuring a chart
There are default charts available when configuring a report layout; however, you can
configure your own charts for report layouts. When configuring charts, you must also
configure datasets because datasets are used to gather specific data from the SQL
database. You should configure the datasets you need for a report layout first, and then
configure the chart.
You must have prior knowledge about Structured Query Language (SQL) before
configuring datasets because datasets require SQL statements. Datasets are configured
only in the CLI.
Configure charts in Log&Report > Report Config > Chart using the following table.
Chart page
Lists all the charts, both default and the ones that you created. On this page, you can edit, delete
and create new charts.
Create New Creates a new chart. When you select Create New, you are automatically
redirected to the Add Graph Report Chart page.
Edit Modifies settings of an existing chart. When you select Edit, you are
automatically redirected to the Edit Graph Report Chart page.
Delete Removes a chart from the list on the Chart page. You can also remove multiple
charts, or all charts within the list.
To remove multiple charts from the list, on the Chart page, select the check box
in each of the rows of the charts you want to remove, and then select Delete.
To remove all charts from the list, on the Chart page, select the check box in the
check box column, and then select Delete.
Name The name of the chart.
Type The type of information that will display within the chart. For example, a bar
chart displays attack log information in the Attacks_February chart.
Dataset The dataset that will be used for the chart.
Comments The description about the chart.
Add Graph Report Chart page
Provides settings for configuring charts for report layouts.
Name Enter a name for the chart.
Dataset Select a configured dataset for the chart.
Category Select a log category for the chart.
Comments Enter a comment to describe the chart. This is optional.
Graph Type Select the type of graph that will display the information within the chart. If you
select Pie, only Category Series and Value Series appears.
Category Series Enter the fields for the category in the Databind field.
The databind is a combination of the fields derived rom the SQL statement or
named fields in the CLI. For example, field(3).

170 01-420-99686-20101026
Value Series Enter the fields for the value in the Databind field.
X-series The settings for the x axis of the line, bar or flow chart.
Databind Enter an SQL databind value expression for binding data to the series being
configured. For example, field(3).
Category Axis Select to have the axis show the type of log category. The default is no log
category will appear on the axis.
Scale Sets the type of format to display the date and time on the x axis.
Format Choose the type of time format that displays on the x axis.
Number of Step Choose the number of steps on the horizontal axis of the graph.
Step Enter the number of scale units in each x axis scale step.
Unit Select the unit of the scale-step on the x-axis.
Y-series The Y-series settings to configure the y part of the line, bar or flow chart.
Databind Enter the fields for the x-series.
Group Enter a group in the field.
Configuring a report layout

After configuring a theme, charts, and importing the images you want to use in the report,
you can then configure the report in the Layout menu.
This layout, similar to the layout that you must configure for a FortiAnalyzer report,
contains settings for including charts, sections, adding images and scheduling when the
layout will be generated.
The Report Components section on the Add Report Layout page provides a place where
you can view what charts, sections, and images you have chosen for that report. This
section also allows you to move the parts, such as charts, to where you want them in the
report.
Configure a report layout in Log&Report > Report Config > Layout using the following
table.
Layout page
Lists all the report layouts that you configured, as well as default layouts. On this page, you can edit,
delete, clone a report, or create a new report.
Create New Creates a new layout. When you select Create New, you are automatically
redirected to the Add Report Layout page.
Edit Modifies the settings within a layout. When you select Edit, you are
automatically redirected to the Edit Report Layout page.
Delete Removes the layout from the list on the Layout page. You can remove multiple
layouts from the list, or all layouts from the list.
To remove multiple layouts from the list, on the Layout page, select the check
box in each of the rows of the layouts you want to remove, and then select
Delete.
To remove all layouts from the list, on the Layout page, select the check box in
the check box column, and then select Delete.
Clone Use to base a new report layout on an existing one. For example, layout_1 is
used as a base (cloned using the Clone icon) for the new layout, layout_april,
which is a report on application control logs that were recorded in the month of
April.
Run Immediately generates a report.

01-420-99686-20101026 171
Report Layout The name of the report layout.

Title The name of the title that appears on the generated report.
Format The type of format that the report is in, either PDF or HTML.
Schedule The time that the report is generated on.
Description A description about the report.
Add Report Layout page
Provides settings for configuring a report layout.
Name Enter a name of the report layout. This is not the name that will be the report’s
title.
Report Theme Select a theme from the drop-down list.
Description Enter a description, if you want, to explain what the report is about. This does
not appear within the report.
Output Format The type of format the report will be generated in. You can choose PDF to
have the report generated as a PDF.
Schedule Select what type of schedule you want the report generated on. The type of
schedule can be on a daily basis, weekly, on demand (whenever you want), or
only once.
If you select On Demand, the report can be generated whenever you want it. If
you select Once, the report is generated as soon as the report is saved.
Title Enter a name for the title of the report.
Sub Title Enter a name that will be the sub title of the report.
Option Select to include all or some of the following report options:
• Table of Contents – includes a table of contents in the report
• Auto Heading Number – automatically provides a heading number for
each heading, in numerical format.
• HTML navigation bar – provides a navigational bar to help you navigate in
report whose format is HTML
• Chart Name as Heading – allows for a chart’s name to be the heading
Report Select Add to add the type of information that you want in the report.
Components These components are required since they contain what log information needs
to be included in the report, and how that information will be displayed and
formatted in the report.
This section provides a preview in the sense that tit allows you to edit each part
of the report, such as a chart or an image. You can move each part to be in the
order that you want it within the generated report.
Add Component page
Text Select the type of format the heading will have. For example, if you select
Heading 1, the headings will be in the Heading 1 format.
When you select Normal, you will be providing a comment for a section within
the report.
Chart Select a category from the Categories drop-down list. Each category contains
different charts that are specific to that category.
Image Select an image to include within the report.
Misc Select a page break, column break, or horizontal line to include in the report.
Viewing generated FortiOS reports

After creating a report layout, you can go to the Report Access > Disk to view your
generated report. When you choose to generate a report only once, the report is
generated right away.

172 01-420-99686-20101026
Disk page
Lists all the reports that are generated by the FortiGate unit. You can also remove reports from the
list.
Delete Select to remove a report from the list.
Report File The report name that the FortiGate unit gave the report. This name is in the
format <scheduletype>-<report_title>-<yyyy-mm-dd>-<start_time>. For
example, Once-examplereport_1-2010-02-12-083054, which indicates that the
report titled examplereport_1 was scheduled to generate only once and did on
February 12, 2010 at 8:30 am. The hour format is in hh:mm:ss format.
Started The time when the report began generating. The format is in yyyy-mm-dd
hh:mm:ss.
Finished The time when the report finished generating. The format is in yyyy-mm-dd
hh:mm:ss.
Size The size of the report after it was generated. The size is in bytes.
Other Formats The other type of format you choose the report to be in, for example, PDF. When
you select PDF in this column, the PDF opens up within the Disk page. You can
save the PDF to your local PC when it is opened on the Disk page as well.

01-420-99686-20101026 173

174 01-420-99686-20101026
Chapter 2 FortiGate Fundamentals
This document describes firewall components, and how to implement firewall policies on
FortiGate units operating in both NAT/Route, and Transparent mode.
This FortiOS Handbook chapter contains the following sections:
The Purpose of a Firewall provides an overview of the FortiGate firewall and its traffic
controlling options.
Life of a Packet describes how a FortiGate unit processes incoming and outgoing network
traffic through its interfaces and firewall policies.
Firewall components describes the FortiGate interfaces, addressing, services and user
configuration that goes into creating a firewall policy.
Firewall Policies describes what policies are, the types of firewall policies and how to
configure and arrange them to ensure proper traffic management.
Troubleshooting describes some common problems and solutions when setting up firewall
policies to manage network traffic.
Concept Example: Small Office Network Protection walks through a small office
configuration of firewall policies.
Concept Example: Library Network Protection walks through an enterprise network
configuration of firewall policies.
v2 FortiGate Fundamentals
01-420-99686-20101026 175
176 01-420-99686-20101026
The Purpose of a Firewall
Ranging from the FortiGate-30B series for small offices to the FortiGate-5000 series for
large enterprises, service providers and carriers, the FortiGate line combines the
FortiOS™ security operating system and latest hardware technologies to provide a
comprehensive and high-performance array of security and networking functions.
FortiGate platforms incorporate sophisticated networking features, such as high
availability for maximum network uptime, and virtual domain (VDOM) capabilities to
separate various networks requiring different security policies.
At the heart of these networking security functions, is the firewall policies.Firewall policies
control all traffic attempting to pass through the FortiGate unit, between FortiGate
interfaces, zones, and VLAN subinterfaces. They are instructions the FortiGate unit uses
to decide connection acceptance and packet processing for traffic attempting to pass
through. When the firewall receives a connection packet, it analyzes the packet’s source
address, destination address, and service (by port number), and attempts to locate a
firewall policy matching the packet.
Firewall policies can contain many instructions for the FortiGate unit to follow when it
receives matching packets. Some instructions are required, such as whether to drop or
accept and process the packets, while other instructions, such as logging and
authentication, are optional. It is through these policies that the FortiGate unit grants or
denies the packets and information in or out of the network, who gets priority (bandwidth)
over other users, and when the packets can come through.
This chapter describes the features of the FortiGate firewall that help to protect your
network, and the firewall policies that are the instructions for the FortiGate unit. The
following topics are included in this section:
• Firewall features
• NAT vs. Transparent Mode
Firewall features
The FortiGate unit includes a rich feature set to protect your network from unwanted
attacks. This section provides an overview of what the FortiGate unit can protect against.
Each of these elements are configured and added to firewall policies as a means of
instructing the FortiGate unit what to do when encountering an security threat.
Antivirus
Antivirus is a group of features that are designed to prevent unwanted and potentially
malicious files from entering your network. These features all work in different ways,
whether by checking for a file size, name, type, or the presence of a virus or grayware
signature.
The antivirus scanning routines used are designed to share access to the network traffic.
This way, each individual feature does not have to examine the network traffic as a
separate operation, reducing overhead significantly. For example, if you enable file
filtering and virus scanning, the resources used to complete these tasks are only slightly
greater than enabling virus scanning alone. Two features do not require twice the
resources.
01-420-99686-20101026 177
Firewall features The Purpose of a Firewall
Antivirus scanning function includes various modules and engines that perform separate
tasks. The FortiGate unit performs antivirus processing in the following order:
• File size
• File pattern
• File type
• Virus scan
• Grayware
• Heuristics
If a file fails any of the tasks of the antivirus scan, no further scans are performed. For
example, if the file “fakefile.exe” is recognized as a blocked pattern, the FortiGate unit will
send the recipient a message informing them that the original message had a virus, and
the file will be deleted or quarantined. The virus scan, grayware, heuristics, and file type
scans will not be performed as the file is already been determined to be a threat and has
been dealt with.
For more information on FortiGate antivirus processes, features and configuration, see the
UTM chapter.
Web Filtering
Web filtering is a means of controlling the content that an Internet user is able to view.
With the popularity of web applications, the need to monitor and control web access is
becoming a key component of Secure Content Management systems that employ
antivirus, web filtering, and messaging security. Important reasons for controlling web
content include:
• Lost productivity because employees are accessing the web for non-business reasons.
• Network Congestion - valuable bandwidth is being used for non-business purposes
and legitimate business applications suffer.
• Loss or exposure of confidential information through chat sites, non-approved email
systems, instant messaging, and peer-to-peer file sharing.
• Increased exposure to web-based threats as employees surf non-business related web
sites.
• Legal liability when employees access/download inappropriate and offensive material.
• Copyright infringement caused by employees downloading and/or distributing
copyrighted material.
As the number and severity of threats increase on the web, the risk potential is increasing
within a company's network as well. Casual non-business related web surfing has caused
many businesses countless hours of legal litigation as hostile environments have been
created by employees who download and view offensive content.web-based attacks and
threats are also becoming increasingly sophisticated. New threats and web-based
applications that are causing additional problems for corporations include:
• Spyware/Grayware
• Phishing
• Instant Messaging
• Peer-to-Peer File Sharing
• Streaming Media
• Blended Network Attacks
178 01-420-99686-20101026
The Purpose of a Firewall Firewall features
Spyware/Grayware
Spyware is also known as Grayware. Spyware is a type of computer program that
attaches itself to a user’s operating system. It does this without the user’s consent or
knowledge. It usually ends up on a computer because of something the user does such as
clicking on a button in a popup window. Spyware can do a number of things such as track
the user’s Internet usage, cause unwanted popup windows, and even direct the user to a
host web site. It is estimated that 80% of all personal computers are infected with
spyware. For further information, visit the FortiGuard Center.
Some of the most common ways of grayware infection include:
• Downloading shareware, freeware or other forms of file-sharing services
• Clicking on pop-up advertising
• Visiting legitimate web sites infected with grayware
Phishing
Phishing is the term used to describe social engineering attacks that use web technology
to trick users into revealing personal or financial information. Phishing attacks use web
sites and emails that claim to be from legitimate financial institutions to trick the viewer into
believing that they are legitimate. Although phishing is initiated by spam email, getting the
user to access the attacker’s web site is always the next step.
Pharming
Pharming is a next generation threat that is designed to identify, and extract financial, and
other key pieces of information for identity theft. Pharming is much more dangerous than
Phishing because it is designed to be completely hidden from the end user. Unlike
phishing attacks that send out spam email requiring the user to click to a fraudulent URL,
Pharming attacks require no action from the user outside of their regular web surfing
activities. Pharming attacks succeed by redirecting users from legitimate web sites to
similar fraudulent web sites that have been created to look and feel like the authentic web
site.
Instant messaging
Instant Messaging presents a number of problems. Instant Messaging can be used to
infect computers with spyware and viruses. Phishing attacks can be made using Instant
Messaging. There is also a danger that employees may use instant messaging to release
sensitive information to an outsider.
Peer-to-peer
Peer-to-Peer networks are used for file sharing. Such files may contain viruses.
Peer-to-Peer applications take up valuable network resources and lower employee
productivity but also has legal implications with the downloading of copyrighted material.
Peer-to-Peer file sharing and applications can also be used to expose company secrets.
Streaming media
Streaming media is a method of delivering multimedia, usually in the form of audio or
video to Internet users. The viewing of streaming media has increased greatly in the past
few years. The problem with this is the way it impacts legitimate business.
01-420-99686-20101026 179
Blended network attacks

Blended network threats are rising and the sophistication of network threats is increasing
with each new attack. Attackers are learning from each previous successful attack and are
enhancing and updating attack code to become more dangerous and fast spreading.
Blended attacks use a combination of methods to spread and cause damage. Using virus
or network worm techniques combined with known system vulnerabilities, blended threats
can quickly spread through email, web sites, and Trojan applications. Blended attacks can
be designed to perform different types of attacks - from disrupting network services to
destroying or stealing information to installing stealthy back door applications to grant
remote access.
For more information on FortiGate web filter processes, features and configuration, see
the UTM chapter.
Antispam/Email Filter
The FortiGate unit performs email filtering (formerly called antispam) for IMAP, POP3, and
SMTP email. Email filtering includes both spam filtering and filtering for any words or files
you want to disallow in email messages. If your FortiGate unit supports SSL content
scanning and inspection you can also configure spam filtering for IMAPS, POP3S, and
SMTPS email traffic.
You can configure the FortiGate unit to manage unsolicited commercial email by detecting
and identifying spam messages from known or suspected spam servers. The FortiGuard
Antispam Service uses both a sender IP reputation database and a spam signature
database, along with sophisticated spam filtering tools, to detect and block a wide range of
spam messages. Using FortiGuard Antispam protection profile settings you can enable IP
address checking, URL checking, E-mail checksum check, and Spam submission.
Updates to the IP reputation and spam signature databases are provided continuously via
the global FortiGuard distribution network.
From the FortiGuard Antispam Service page in the FortiGuard center you can use IP and
signature lookup to check whether an IP address is blacklisted in the FortiGuard antispam
IP reputation database, or whether a URL or email address is in the signature database.
Email filter techniques

The FortiGate unit has a number of techniques available to help detect spam. Some use
the FortiGuard AntiSpam service, requiring a subscription. The remainder use your DNS
servers, or lists you must maintain.
The FortiGate unit queries the FortiGuard Antispam service to determine if the IP address
of the client delivering the email is blacklisted. A match will have the FortiGate unit treat
delivered messages as spam. If enabled, the FortiGate unit will check all the IP addresses
in the header of SMTP email against the FortiGuard Antispam service.
The FortiGate unit queries the FortiGuard Antispam service to determine if any URL in the
message body is associated with spam. If any URL is blacklisted, the FortiGate unit
determines that the email message is spam
The FortiGate unit sends a hash of an email to the FortiGuard Antispam server which
compares the hash to hashes of known spam messages stored in the FortiGuard
Antispam database. If the hash results match, the email is flagged as spam.
The FortiGate unit compares the IP address of the client delivering the email to the
addresses in the IP address black/white list specified in the protection profile. If a match is
found, the FortiGate unit will take the action configured for the matching black/white list
entry against all delivered email.
180 01-420-99686-20101026
The Purpose of a Firewall Firewall features
The FortiGate unit takes the domain name specified by the client in the HELO greeting
sent when starting the SMTP session, and does a DNS lookup to determine if the domain
exists. If the lookup fails, the FortiGate unit determines that any messages delivered
during the SMTP session are spam.
The FortiGate unit compares the sender email address, as shown in the message
envelope MAIL FROM, to the addresses in the email address black/white list specified in
the protection profile. If a match is found, the FortiGate unit will take the action configured
for the matching black/white list entry.
The FortiGate unit performs a DNS lookup on the reply-to domain to see if there is an A or
MX record. If no such record exists, the message is treated as spam.
The FortiGate unit will block email messages based on matching the content of the
message with the words or patterns in the selected spam filter banned word list.
For more information on FortiGate antispam processes, features and configuration, see
the UTM chapter.
Intrusion Protection
The FortiGate Intrusion Protection system combines signature detection and prevention
with low latency and excellent reliability. With intrusion Protection, you can create multiple
IPS sensors, each containing a complete configuration based on signatures. Then, you
can apply any IPS sensor to each protection profile. The FortiGate intrusion protection
system protects your network from outside attacks. Your FortiGate unit has two techniques
to deal with these attacks.
Anomaly-based defense is used when network traffic itself is used as a weapon. A host
can be flooded with far more traffic than it can handle, making the host inaccessible. The
most common example is the denial of service attack, in which an attacker directs a large
number of computers to attempt normal access of the target system. If enough access
attempts are made, the target is overwhelmed and unable to service genuine users. The
attacker does not gain access to the target system, but it is not accessible to anyone else.
The FortiGate unit DoS feature will block traffic over a certain threshold from the attacker,
allowing connections from other legitimate users.
Signature-based defense is used against known attacks or vulnerability exploits. These
often involve an attacker attempting to gain access to your network. The attacker must
communicate with the host in an attempt to gain access, and this communication will
include particular commands or sequences of commands and variables. The IPS
signatures include these command sequences, allowing the FortiGate unit to detect and
stop the attack.
The basis of signature-based intrusion protection are the IPS signatures, themselves.
Every attack can be reduced to a particular string of commands or a sequence of
commands and variables. Signatures include this information so your FortiGate unit
knows what to look for in network traffic.
Signatures also include characteristics about the attack it describes. These characteristics
include the network protocol in which it will appear, the vulnerable operating system, and
the vulnerable application.
Before examining network traffic for attacks, the FortiGate will identify each protocol
appearing in the traffic. Attacks are protocol-specific so your FortiGate unit conserves
resources by looking for attacks only in the protocols used to transmit them. For example,
the FortiGate unit will only examine HTTP traffic for the presence of a signature describing
an HTTP attack.
Once the protocol decoders separate the network traffic by protocol, the IPS engine
examines the network traffic for the attack signatures.
01-420-99686-20101026 181
The IPS engine does not examine network traffic for all signatures, however. You must
first create an IPS sensor and specify which signatures are included. You do not have to
choose each signature you want to include individually, however. Instead, filters are used
to define the included signatures.
IPS sensors contain one or more IPS filters. A filter is simply a collection of signature
attributes you specify. The signatures that have all of the attributes specified in a filter are
included in the IPS signature.
For example, if your FortiGate unit protects a Linux server running the Apache web server
software, you could create a new filter to protect it. Set OS to Linux, and Application to
Apache and the filter will include only the signatures applicable to both Linux and Apache.
If you wanted to scan for all the Linux signatures and all the Apache signatures, you would
create two filters, one for each.
For more information on FortiGate IPS processes, features and configuration, see the
UTM chapter.
Traffic Shaping
Traffic shaping, when included in a firewall policy, controls the bandwidth available to, and
sets the priority of the traffic processed by, the policy. Traffic shaping makes it possible to
control which policies have the highest priority when large amounts of data are moving
through the FortiGate unit. For example, the policy for the corporate web server might be
given higher priority than the policies for most employees’ computers. An employee who
needs extra high speed Internet access could have a special outgoing policy set up with
higher bandwidth.
Traffic shaping is available for firewall policies whose Action is ACCEPT, IPSEC, or
SSLVPN. It is also available for all supported services, including H.323, TCP, UDP, ICMP,
and ESP
Traffic shaping cannot increase the total amount of bandwidth available, but you can use it
to improve the quality of bandwidth-intensive and sensitive traffic.
The bandwidth available for traffic set in a traffic shaper is used to control data sessions
for traffic in both directions. For example, if guaranteed bandwidth is applied to an internal
and an external FTP policy, and a user on an internal network uses FTP to put and get
files, both the put and get sessions share the bandwidth available to the traffic controlled
by the policy.
Once included in a firewall policy, the guaranteed and maximum bandwidth is the total
bandwidth available to all traffic controlled by the policy. If multiple users start multiple
communications session using the same policy, all of these communications sessions
must share from the bandwidth available for the policy.
However, bandwidth availability is not shared between multiple instances of using the
same service if these multiple instances are controlled by different policies. For example,
you can create one FTP policy to limit the amount of bandwidth available for FTP for one
network address and create another FTP policy with a different bandwidth availability for
another network address
Traffic shaping attempts to “normalize” traffic peaks/bursts to prioritize certain flows over
others. But there is a physical limitation to the amount of data which can be buffered and
to the length of time. Once these thresholds have been surpassed, frames and packets
will be dropped, and sessions will be affected in other ways. For example, incorrect traffic
shaping configurations may actually further degrade certain network flows, since the
excessive discarding of packets can create additional overhead at the upper layers that
may be attempting to recover from these errors.
182 01-420-99686-20101026
The Purpose of a Firewall NAT vs. Transparent Mode
A basic traffic shaping approach is to prioritize certain traffic flows over other traffic whose
potential discarding is less advantageous. This would mean that you accept sacrificing
certain performance and stability on low-priority traffic, in order to increase or guarantee
performance and stability to high-priority traffic.
If, for example, you are applying bandwidth limitations to certain flows, you must accept
the fact that these sessions can be limited and therefore negatively impacted. Traffic
shaping applied to a firewall policy is enforced for traffic which may flow in either direction.
Therefore a session which may be set up by an internal host to an external one, through
an Internal-to-External policy, will have traffic shaping applied even if the data stream
flows external to internal. One example may be an FTP “get” or a SMTP server connecting
to an external one, in order to retrieve email.
Note that traffic shaping is effective for normal IP traffic at normal traffic rates. Traffic
shaping is not effective during periods when traffic exceeds the capacity of the FortiGate
unit. Since packets must be received by the FortiGate unit before they are subject to traffic
shaping, if the FortiGate unit cannot process all of the traffic it receives, then dropped
packets, delays, and latency are likely to occur.
For more information on traffic shaping, see the Traffic Shaping chapter.
NAT vs. Transparent Mode

The FortiGate unit can run in two modes: Network Address Translation (NAT) mode and
Transparent mode. Generally speaking, both modes function the same, with some minor
differences in feature availability due to the nature of the mode. With both modes,
however, firewall policies define how traffic moves, or is prevented, from moving within the
local network or to an external network or the Internet.
NAT mode
In NAT mode, the FortiGate unit is visible to the network that it is connected to. All of its
interfaces are on different subnets. Each interface that is connected to a network must be
configured with an IP address that is valid for that subnetwork.
You would typically use NAT mode when the FortiGate unit is deployed as a gateway
between private and public networks. In its default NAT mode configuration, the FortiGate
unit functions as a firewall. Firewall policies control communications through the FortiGate
unit to both the Internet and between internal networks. In NAT mode, the FortiGate unit
performs network address translation before IP packets are sent to the destination
network. For example, a company has a FortiGate unit as their interface to the Internet.
The FortiGate unit also acts as a router to multiple sub-networks within the company.
01-420-99686-20101026 183
NAT vs. Transparent Mode The Purpose of a Firewall
Figure 5: FortiGate unit in NAT mode
172
.20 WA
traf NAT .12 N 1
fic po 0.1
ext betw licies 29
P
ern ee
al n n in contr 192 ort 1
etw tern ollin .16
ork al a g 8.1
s. nd .1
k
P w or
10. ort 2 t
Ne /24
10.
10. n al .1.0
1 er 8
Int 2.16
P ffic al n
ol b e
19
ic e tw
tra ern
ie tw o
s e rk
in
co e s
t
nt n .
ro
li
ng
k
w or
t
Ne 24
n al 0.0/
er .1
Int .10
10
In this situation, as shown in Figure 5, the FortiGate unit is set to NAT mode. Using this
mode, the FortiGate unit can have a designated port for the Internet, in this example,
wan1 with an address of 172.20.120.129, which is the public IP address. The internal
network segments are behind the FortiGate unit and invisible to the public access, for
example port 2 with an address of 10.10.10.1. The FortiGate unit translates IP addresses
passing through it to route the traffic to the correct subnet or the Internet.
How address translation works

In NAT mode, firewall policies perform the address translation between the internal and
external interfaces. When a user accesses a web site, for example, the web site only
knows the request by the external interface of the FortiGate unit, in this example, wan1.
For example, a user surfs to a web server (IP address 172.50.20.20). The user’s PC has
an IP address of 10.10.10.2 on the Internal interface. The FortiGate unit receives the
request from the user to go to the web server. The external interface for the FortiGate unit
to send and receive information is want 1 (172.20.120.129). The FortiGate unit looks at
the firewall policies to determine where the request should go, in this case, out the
external interface.
The FortiGate unit changes the packet information of the return address to its external
interface, while keeping track of the originating user request, and the originating PC
address. Once modified, the FortiGate unit sends the packet information to the web
server.
184 01-420-99686-20101026
Figure 6: Sender’s IP internal address translated to the FortiGate unit’s external address
C
tP
en .2
Cli 0.10
.1
10
1 Fir
3 nt ew
2 Se et N A all P
ck T e olic
Pa 1 nab y
led
D S
es o
2
t i n ur
Inte
at ce
3
io : 1
rna
n: 0
l
17 .10
2. .1
5 0 0.
.2 2
0.
d
20
WA 1 ive
N 1 3 e c e et
2 R ck
Pa
D ou
es rc
S
tin e:
at 1
io 72
n: .2
17 0.
2. 12
50 0.
.2 12
0. 9
20
r
rve
b Se .20
0
We 50.2
7 2.
1
When the web server sends the response, it sends it to what it believes to be the
originating address, the FortiGate wan1 address, 172.20.120.129. When the FortiGate
unit receives the information, it determines where it should go by looking at its session
information. Using firewall policies, it determines that the information should be going to
the originating user at 10.10.10.2. The FortiGate changes the destination IP to the correct
user and delivers the packet.
Figure 7: Web server sends to FortiGate external address and translated to internal address
C
tP
en .2
Cli 0.10
.1
10
d
1 ive Fir
ce ew
3
2 R e cket N A all P
Pa T e olic
nab y
1 led
D ou
2
es rc
S
Inte
tin e:
3
at 1
rna
io 72
n: . 5
l
10 0.
.1 20
0. .2
10 0
.2
WA 1
N 1 nt
3
2 Se et
ck
Pa
D So
es u
tin rce
at :
io 17
n: 2
17 .50
2. .2
20 0.
.1 2 0
20
.1
er
S erv 20
b 0.
We 50.2
7 2.
1
Throughout this exchange, which occurs in nanoseconds, and because of network

address translation, the web server does not know that the originating address is really
10.10.10.2, but 172.20.120.129.
01-420-99686-20101026 185
Central NAT table

The central NAT table enables you to define, and control with more granularity, the
address translation performed by the FortiGate unit. With the NAT table, you can define
the rules which dictate the source address or address group and which IP pool the
destination address uses.
The NAT table also functions in the same way as the firewall policy table. That is, the
FortiGate unit reads the NAT rules in a top-down methodology, until it hits a matching rule
for the incoming address. This enables you to create multiple NAT policies that dictate
which IP pool is used based on the source address. The NAT policies can be rearranged
within the policy list as well, the same way as firewall policies.
NAT policies are applied to network traffic after a firewall policy. For more information on
central NAT tables, see “Central NAT table” on page 551.
Transparent mode
In Transparent mode, the FortiGate unit is invisible to the network. All of its interfaces are
on the same subnet and share the same IP address. You only have to configure a
management IP address so that you can make configuration changes.
You would typically use the FortiGate unit in Transparent mode on a private network
behind an existing firewall or behind a router. In Transparent mode, the FortiGate unit also
functions as a firewall. Firewall policies control communications through the FortiGate unit
to the Internet and internal network. No traffic can pass through the FortiGate unit until you
add firewall policies.
For example, the company has a router or other firewall in place. The network is simple
enough that all users are on the same internal network. They need the FortiGate unit to
perform antispam, antivirus and intrusion protection and similar traffic scanning. In this
situation, as shown in Figure 8, the FortiGate unit is set to transparent mode. The traffic
passing through the FortiGate unit does not change the addressing from the router to the
internal network. Firewall policies and protection profiles define the type of scanning the
FortiGate unit performs on traffic entering the network.
186 01-420-99686-20101026
Figure 8: FortiGate unit in transparent mode
20
4.2
3.1
.5
Ga
tew
net ay to 10
.10
wo pu .10 WA
rk blic .2 N1
tra NAT Inte

rna
ffic po l
ext betw licies
ern ee
al n n in contr
etw tern ollin
ork al a g
s. nd
By default when shipped, the FortiGate unit operates in NAT mode. To use the FortiGate
unit in Transparent mode, you need to switch its mode. When switched to a different
mode, the FortiGate unit does not need to be restarted; the change is automatic.
In the following example, the steps change the FortiGate unit to Transparent mode with an
IP of 10.11.101.10, netmask of 255.255.255.0 and a default gateway of 10.11.101.1
To enable Transparent mode - web-based manager

1 Go to System > Config > Operation.
2 Select Transparent for the Operation Mode from the list box.
3 Enter the Management IP address and netmask 10.11.101.10 255.255.255.0.
4 Enter the Default Gateway address of 10.11.101.1.
5 Select Apply.
To enable Transparent mode - CLI

set opmode transparent
set manageip 10.11.101.10 255.255.255.0
set gateway 10.11.101.1
end
For information on unique Transparent mode firewall configurations, see “Advanced
firewall concepts” on page 537.
Note: This guide and its examples are constructed with the FortiGate unit running in NAT
mode, unless otherwise noted.
01-420-99686-20101026 187
Operating mode differences

The FortiGate unit, running in either NAT or Transparent mode have essentially the same
feature set. Due to the differences in the modes, however, some features are not available
in Transparent mode. The list below outlines the key features not available in Transparent
mode:
• Network > DNS Databases
• DHCP
• Router (basic routing is available by going to Network > Routing Table)
• Virtual IP
• Load Balance
• IPSec Concentrator (Transparent mode supports policy-based configurations)
• SSL VPN
• WCCP cache engine
188 01-420-99686-20101026
Life of a Packet
Directed by firewall policies, a FortiGate unit screens network traffic from the IP layer up
through the application layer of the TCP/IP stack. This chapter provides a general,
high-level description of what happens to a packet as it travels through a FortiGate
security system.
The FortiGate unit performs three types of security inspection:
• stateful inspection, that provides individual packet-based security within a basic
session state
• flow-based inspection, that buffers packets and uses pattern matching to identify
security threats
• proxy-based inspection, that reconstructs content passing through the FortiGate unit
and inspects the content for security threats.
Each inspection component plays a role in the processing of a packet as it traverses the
FortiGate unit en route to its destination. To understand these inspections is the first step
to understanding the flow of the packet.
Stateful inspection
With stateful inspection, the FortiGate unit looks at the first packet of a session to make a
security decision. Common fields inspected include TCP SYN and FIN flags to identity the
start and end of a session, the source/destination IP, source/destination port and protocol.
Other checks are also performed on the packed payload and sequence numbers to verify
it as a valid communication and that the data is not corrupted or poorly formed.
The FortiGate unit makes the decision to drop, pass or log a session based on what is
found in the first packet of the session. If the FortiGate unit decides to drop or block the
first packet of a session, then all subsequent packets in the same session are also
dropped or blocked without being inspected. If the FortiGate unit accepts the first packet of
a session, then all subsequent packets in the same session are also accepted without
being inspected.
01-420-99686-20101026 189
Flow inspection Life of a Packet
Figure 9: Stateful inspection of packets through the FortiGate unit
1 SY
3 N,
2 IP,
1 TC
2 P
nt 3
Se et
ck
Pa
1
3
2
ed
c eiv t
Re cke
Pa
Flow inspection
With flow inspection, the FortiGate unit samples multiple packets in a session and multiple
sessions, and uses a pattern matching engine to determine the kind of activity that the
session is performing and to identify possible attacks or viruses. For example, if
application control is operating, flow inspection can sample network traffic and identify the
application that is generating the activity. Flow-based antivirus can sample network traffic
and determine if the content of the traffic contains a virus, IPS can sample network traffic
and determine if the traffic constitutes an attack. The security inspection occurs as the
data is passing from its source to its destination. Flow inspection identifies and blocks
security threats in real time as they are identified.
Figure 10: Flow inspection of packets through the FortiGate unit
IPS
,
3 Ap Flow
p C -AV
2 ont ,
rol
2
nt
Se et
ck
Pa
1
2
d
ive
e ce et
R ck
Pa
Flow-based inspections typically require less processing than proxy-based inspection, and
therefore flow-based antivirus performance can be better than proxy-based antivirus
performance. However, some threats can only be detected when a complete copy of the
payload is obtained so, proxy-based inspection tends to be more accurate and complete
than flow-based inspection.
190 01-420-99686-20101026
Life of a Packet Proxy inspection
Proxy inspection
With flow inspection, the FortiGate unit will pass all the packets between the source and
destination, and keeps a copy of the packets in its memory. It then uses a reconstruction
engine to build the content of the original traffic. The security inspection occurs after the
data has passed from its source to its destination.
Proxy inspection examines the content contained a content protocol session for security
threats. Content protocols include the HTTP, FTP, and email protocols. Security threats
can be found in files and other content downloaded using these protocols. With proxy
inspection, the FortiGate unit downloads the entire payload of a content protocol sessions
and re-constructs it. For example, proxy inspection can reconstruct an email message and
its attachments. After a satisfactory inspection the FortiGate unit passes the content on to
the client. If proxy inspection detects a security threat in the content, the content is
removed from the communication stream before the it reaches its destination. For
example, if proxy inspection detects a virus in an email attachment, the attachment is
removed from the email message before its sent to the client. Proxy inspection is the most
thorough inspection of all, although it requires more processing power, and this may result
in lower performance.
Figure 11: Proxy inspection of packets through the FortiGate unit
1 Em
a
3
2 filteil filter
r, D , we
LP, b
AV
nt
Se et
ck 3
Pa 2
1
1
3
2
d
ive
e ce et
R ck
Pa
FortiOS functions and security layers

Within these security inspection types, FortiOS functions map to different inspections. The
table below outlines when actions are taken as a packet progresses through its life within
a FortiGate unit.
Table 9: FortiOS security functions and security layers
Security Function Stateful Flow Proxy

Firewall 9
IPsec VPN 9
Traffic Shaping 9
User Authentication 9
Management Traffic 9
01-420-99686-20101026 191
Packet flow Life of a Packet
Table 9: FortiOS security functions and security layers (Continued)
Security Function Stateful Flow Proxy

SSL VPN 9
Intrusion Prevention 9
Flow-based Antivirus 9
Application Control 9
VoIP inspection 9
Proxy Antivirus 9
Email Filtering 9
Web Filtering (Antispam) 9
Data Leak Prevention 9
Packet flow
After the FortiGate unit’s external interface receives a packet, the packet proceeds
through a number of steps on its way to the internal interface, traversing each of the
inspection types, depending on the firewall policy and UTM profile configuration. The
diagram in Figure 12 on page 193 is a high level view of the packet’s journey.
The description following is a high-level description of these steps as a packet enters the
FortiGate unit towards its destination on the internal network. Similar steps occur for
outbound traffic.
Packet inspection (Ingress)

In the diagram in Figure 12 on page 193, in the first set of steps (ingress), a number of
header checks take place to ensure the packet is valid and contains the necessary
information to reach its destination. This includes:
• Packet verification - during the IP integrity stage, verification is performed to ensure
that the layer 4 protocol header is the correct length. If not, the packet is dropped.
• Session creation - the FortiGate unit attempts to create a session for the incoming data
• IP stack validation for routing - the firewall performs IP header length, version and
checksum verifications in preparation for routing the packet.
• Verifications of IP options - the FortiGate unit validates the rouging information
192 01-420-99686-20101026
Life of a Packet Packet flow
Figure 12: Packet flow
3 1
2
Packet
Packet flow: Ingress
Interface DoS IP Integrity NAT
IPsec (DNAT) Routing
(Link layer) Sensor Header checking
Stateful
Session Management User Traffic Session Policy
Inspection Helpers Traffic
SSL VPN
Authentication Shaping Tracking Lookup
Engine
No
UTM
Yes
Antivirus, Flow-based
No Web Filter, VoIP Flow-based Application
Email Filter, Inspection Antivirus Control
IPS
Inspection
DLP
Engine
Yes
Antivirus Proxy-based
Web Filter (HTTP(S), SMTP(S),
Data Leak Prevention Email Filter
(HTTP, HTTPS) POP3(S), IMAP(S), FTP, Inspection
NNTP, IM)
Engine
3 1
NAT Routing Interface
IPsec 2
(SNAT)
Packet flow: Egress Packet
Interface
Ingress packets are received by a FortiGate interface.The packet enters the system, and
the interface network device driver passes the packet to the Denial of Service (DoS)
sensors, if enabled, to determine whether this is a valid information request or not.
DoS sensor
DoS scans are handled very early in the life of the packet to determine whether the traffic
is valid or port of a DoS attack. Unlike signature-based IPS which inspects all the packets
within a certain traffic flow, the DoS module inspects all traffic flows but only tracks packets
that can be used for DoS attacks (for example TCP SYN packets), to ensure they are
within the permitted parameters. Suspected DoS attacks are blocked, other packets are
allowed.
IP integrity header checking

The FortiGate unit reads the packet headers to verify if the packet is a valid TCP, UDP,
ICMP,SCTP, or GRE packet. The only verification that is done at this step to ensure that
the protocol header is the correct length. If it is, the packet is allowed to carry on to the
next step. If not, the packet is dropped.
01-420-99686-20101026 193
Packet flow Life of a Packet
IPsec
If the packet is an IPsec packet, the IPsec engine attempts to decrypt it. The IPsec engine
applies the correct encryption keys to the IPSec packet and sends the unencrypted packet
to the next step. IPsec is bypassed when for non-IPSec traffic and for IPsec traffic that
cannot be decrypted by the FortiGate unit.
Destination NAT (DNAT)

The FortiGate unit checks the NAT table and determines the destination IP address for the
traffic. This step determines whether a route to the destination address actually exists.
For example, if a user’s browser on the internal network at IP address 192.168.1.1 visited
the web site www.example.com using NAT, after passing through the FortiGate unit the
source IP address becomes NATed to the FortiGate unit external interface IP address.
The destination address of the reply back from www.example.com is the IP address of the
FortiGate unit internal interface. For this reply packet to be returned to the user, the
destination IP address must be destination NATed to 192.168.1.1.
For more information on network address translation, see “How address translation works”
on page 184.
DNAT must take place before routing so that the FortiGate unit can route packets to the
correct destination.
Routing
The routing step determines the outgoing interface to be used by the packet as it leaves
the FortiGate unit. In the previous step, the FortiGate unit determined the real destination
address, so it can now refer to its routing table and decide where the packet must go next.
Routing also distinguishes between local traffic and forwarded traffic and selects the
source and destination interfaces used by the firewall policy engine to accept or deny the
packet.
Policy lookup
The policy look up is where the FortiGate unit reviews the list of firewall policies which
govern the flow of network traffic, from the first entry to the last, to find a match for the
source and destination IP addresses and port numbers. The decision to accept or deny a
packet, after being verified as a valid request within the stateful inspection, occurs here. A
denied packet is discarded. An accepted packet will have further actions taken. If IPS is
enabled, the packet will go to Flow-based inspection engine, otherwise it will go to the
Proxy-based inspection engine.
If no other UTM options are enabled, then the session was only subject to stateful
inspection. If the action is accept, the packet will go to Source NAT to be ready to leave
the FortiGate unit.
Session tracking
Part of the stateful inspection engine, session tracking maintains session tables that
maintain information about sessions that the stateful inspection module uses for
maintaining sessions, NAT, and other session related functions.
194 01-420-99686-20101026
Life of a Packet Packet flow
User authentication
User authentication added to firewall policies is handled by the stateful inspection engine,
which is why Firewall authentication is based on IP address. Authentication takes place
after policy lookup selects a firewall policy that includes authentication. This is also known
as identify-based policies. Authentication also takes place before UTM features are
applied to the packet.
Management traffic
This local traffic is delivered to the FortiGate unit TCP/IP stack and includes
communication with the web-based manager, the CLI, the FortiGuard network, log
messages sent to FortiAnalyzer or a remote syslog server, and so on. Management traffic
is processed by applications such as the web server which displays the FortiOS
web-based manager, the SSH server for the CLI or the FortiGuard server to handle local
FortiGuard database updates or FortiGuard Web Filtering URL lookups.
SSL VPN traffic

For local SSL VPN traffic, the internal packets are decrypted and are routed to a special
interface. This interface is typically called ssl.root for decryption. Once decrypted, the
packets goes to policy lookup.
Session helpers
Some protocols include information in the packet body (or payload) that must be analyzed
to successfully process sessions for this protocol. For example, the SIP VoIP protocol
uses TCP control packets with a standard destination port to set up SIP calls. To
successfully process SIP VoIP calls, FortiOS must be able to extract information from the
body of the SIP packet and use this information to allow the voice-carrying packets
through the firewall.
FortiOS uses session helpers to analyze the data in the packet bodies of some protocols
and adjust the firewall to allow those protocols to send packets through the firewall.
Flow-based inspection engine

Flow-based inspection is responsible for IPS, application control, flow-based antivirus
scanning and VoIP inspection. Packets are sent to flow-based inspection if the firewall
policy that accepts the packets includes one or more of these UTM features.
Note: Flow-based antivirus scanning is only available on some FortiGate models.
Once the packet has passed the flow-based engine, it can be sent to the proxy inspection
engine or egress.
Proxy-based inspection engine

The proxy inspection engine is responsible for carrying out antivirus protection, email
filtering (antispam), web filtering and data leak prevention. The proxy engine will process
multiple packets to generate content before it is able to make a decision for a specific
packet.
01-420-99686-20101026 195
Example 1: client/server connection Life of a Packet
IPsec
If the packet is transmitted through an IPsec tunnel, it is at this stage the encryption and
required encapsulation is performed. For non-IPsec traffic (TCP/UDP) this step is
bypassed.
Source NAT (SNAT)

When preparing the packet to leave the FortiGate unit, it needs to NAT the source address
of the packet to the external interface IP address of the FortiGate unit. For example, a
packet from a user at 192.168.1.1 accessing www.example.com is now using a valid
external IP address as its source address.
Routing
The final routing step determines the outgoing interface to be used by the packet as it
leaves the FortiGate unit.
Egress
Upon completion of the scanning at the IP level, the packet exits the FortiGate unit.
Example 1: client/server connection

The following example illustrates the flow of a packet of a client/web server connection
with authentication and FortiGuard URL and antivirus filtering.
This example includes the following steps:
Initiating connection from client to web server

1 Client sends packet to web server.
2 Packet intercepted by FortiGate unit interface.
2.1 Link level CRC and packet size checking. If the size is correct, the packet
continues, otherwise it is dropped.
3 DoS sensor - checks are done to ensure the sender is valid and not attempting a denial
of service attack.
4 IP integrity header checking, verifying the IP header length, version and checksums.
5 Next hop route
6 Policy lookup
7 User authentication
8 Proxy inspection
7.1 Web Filtering
7.2 FortiGuard Web Filtering URL lookup
7.3 Antivirus scanning
9 Source NAT
10 Routing
11 Interface transmission to network
12 Packet forwarded to web server
196 01-420-99686-20101026
Life of a Packet Example 1: client/server connection
Response from web server

1 Web Server sends response packet to client.
2 Packet intercepted by FortiGate unit interface
2.1 Link level CRC and packet size checking.
3 IP integrity header checking.
4 DoS sensor.
5 Proxy inspection
5.1 Antivirus scanning.
6 Source NAT.
7 Stateful Policy Engine
7.1 Session Tracking
8 Next hop route
10 Packet returns to client
Figure 13: Client/server connection
3 1
2
Client sends packet

to web server FortiGate Unit
Interface DoS IP Integrity NAT
(Link layer) Sensor Header checking (DNAT)
Stateful
Session User Policy
Policy Tracking Authentication Lookup
Routing
Engine
Proxy
FortiGuard
Inspection Antivirus Web Filter
Web Filtering
Engine
FortiGuard
Packet
NAT Interface
Exits
Routing
(SNAT) (Link layer)
Proxy Inspection Internet

Engine
Web Server
DoS IP Integrity Interface
Antivirus Sensor Header checking (Link layer)
Packet
Enters
NAT Session
Routing
(SNAT) Tracking
Stateful Policy
Engine
Interface
(Link layer)
3 1 Packet exits and

2 returns to client
01-420-99686-20101026 197
Example 2: Routing table update Life of a Packet
Example 2: Routing table update

1 FortiGate unit receives routing update packet
of service attack.
5 Stateful policy engine
4.1 Management traffic (local traffic)
6 Routing module
5.1 Update routing table
Figure 14: Routing table update
Routing
3 1
2 update
packet
Packet
FortiGate Unit
Interface DoS IP Integrity Stateful
Management
(Link layer) Sensor Header checking Policy
Traffic
Engine
Routing
Routing Table
Module
Update routing table
Example 3: Dialup IPsec with application control

1 FortiGate unit receives IPsec packet from Internet
of service attack.
5 IPsec
5.1 Determines that packet matched IPsec phase 1 configuration
5.2 Unencrypted packet
6 Next hop route
7.1 Session tracking
198 01-420-99686-20101026
Life of a Packet Example 3: Dialup IPsec with application control
8 Flow inspection engine

8.1 IPS
8.2 Application control
9 Source NAT
10 Routing
12 Packet forwarded to internal server
Response from server

1 Server sends response packet
2.1 Link level CRC and packet size checking
3 IP integrity header checking.
4 DoS sensor
5 Flow inspection engine
5.1 IPS
5.2 Application control
6.1 Session tracking
7 Next hop route
8 IPsec
8.1 Encrypts packet
9 Routing
11 Encrypted Packet returns to internet
01-420-99686-20101026 199
Example 3: Dialup IPsec with application control Life of a Packet
Figure 15: Dialup IPsec with application control

IPsec packet
3
2
1
received from
Internet
Encrypted or
encapsulated packet
FortiGate Unit
Interface DoS IP Integrity
IPsec NAT
(Link layer) Sensor Header checking
Packet decryption
Application Session Next Hop

Control IPS Tracking Route
Flow Inspection Engine Stateful Policy Engine
Packet Exits
Source Interface
NAT Routing 3 1
(Link layer)
2
Internal
Server
DoS IP Integrity Interface 3 1

Destintion
Sensor Header checking (Link layer)
NAT 2
Response Packet
Packet Enters
Session Next Hop

Application
IPS Tracking Route
Control
Flow Inspection Engine Stateful Policy Engine
Interface Routing IPsec

(Link layer)
Packet encryption
Packet
3
2
1 Exits and returns
to source
Encrypted or
encapsulated packet
200 01-420-99686-20101026
Firewall components
The FortiGate unit’s primary purpose is to act as a firewall to protect your networks from
unwanted attacks and to control the flow of network traffic. The FortiGate unit does this
through the use of firewall policies. The policies you create review the traffic passing
through the device to determine if the traffic is allowed into or out of the network, if it is
normal network traffic or encrypted VPN or SSL VPN traffic, where it is going and how it
should be handled.
Every firewall policy uses similar components. This section briefly describes these
components.
• Interfaces
• Addressing
• Ports
• Services
• Schedules
• UTM profiles
Interfaces
Interfaces, both physical and virtual, enable traffic to flow to and from the internal network,
and the Internet and between internal networks. The FortiGate unit has a number of
options for setting up interfaces and groupings of subnetworks that can scale to a
company’s growing requirements.
Physical
FortiGate units have a number of physical ports where you connect Ethernet or optical
cables. Depending on the model, they can have anywhere from four to 40 physical ports.
Some units have a grouping of ports labelled as internal, providing a built-in switch
functionality.
In FortiOS, the port names, as labeled on the FortiGate unit, appear in the web-based
manager in the Unit Operation the Dashboard. They also appear when you are configuring
the interfaces, by going to System > Network > Interface. As shown below, the
FortiGate-100A has eight interfaces
Figure 16: FortiGate-100A physical interfaces
4 3 2 1
DC+12V
Console Internal DMZ 2 DMZ 1 WAN 2 WAN 1

USB
01-420-99686-20101026 201
Interfaces Firewall components
Figure 17: FortiGate-100A interfaces on the Dashboard
Figure 18: Configuring the FortiGate-100A ports
Normally the internal interface is configured as a single interface shared by all physical
interface connections - a switch. The switch mode feature has two states - switch mode
and interface mode. Switch mode is the default mode with only one interface and one
address for the entire internal switch. Interface mode allows you to configure each of the
internal switch physical interface connections separately. This enables you to assign
different subnets and netmasks to each of the internal physical interface connections.
The larger FortiGate units can also include Advanced Mezzanine Cards (AMC), which can
provide additional interfaces (ethernet or optical), with throughput enhancements for more
efficient handling of specialized traffic. These interfaces appear in FortiOS as port
amc/sw1, amc/sw2 and so on. In the following illustration, the FortiGate-3810A has three
AMC cards installed: two single-width (amc/sw1, amc/sw2) and one double-width
(amc/dw).
Figure 19: FortiGate-3810A AMC card port naming
202 01-420-99686-20101026
Firewall components Interfaces
For more information on configuring physical ports, see “Addressing” on page 209.
Administrative access
Interfaces, especially the public-facing ports can be potentially accessed by those who
you may not want access to the FortiGate unit. When setting up the FortiGate unit, you
can set the type of protocol an administrator must use to access the FortiGate unit. The
options include:
• HTTPS
• HTTP
• SSH
• TELNET
• PING
• SNMP
You can select as many, or as few, even none, that are accessible by an administrator.
Example
This example adds an IPv4 address 172.20.120.100 to the WAN1 interface as well as the
administrative access to HTTPS and SSH. As a good practice, set the administrative
access when you are setting the IP address for the port.
To add an IP address on the WAN1 interface - web-based manager

1 Go to System > Network > Interface.
2 Select the WAN1 interface row and select Edit.
3 Select the Addressing Mode of Manual.
4 Enter the IP address for the port of 172.20.120.100/24.
5 For Administrative Access, select HTTPS and SSH.
6 Select OK.
To create IP address on the WAN1 interface - CLI

edit wan1
set ip 172.20.120.100/24
set allowaccess https ssh
end
Note: When adding to, or removing a protocol, you must type the entire list again. For
example, if you have an access list of HTTPS and SSH, and you want to add PING, typing:
set allowaccess ping
...only PING will be set. In this case, you must type...
set allowaccess https ssh ping
01-420-99686-20101026 203
Wireless
A wireless interface is similar to a physical interface only it does not include a physical
connection. The FortiWiFi units enables you to add multiple wireless interfaces that can be
available at the same time (the FortiWiFi-30B can only have one wireless interface). On
FortiWiFi units, you can configure the device to be either an access point, or a wireless
client. As an access point, the FortiWiFi unit can have up to four separate SSIDs, each on
their own subnet for wireless access. In client mode, the FortiWiFi only has one SSID, and
is used as a receiver, to enable remote users to connect to the existing network using
wireless protocols.
Wireless interfaces also require additional security measures to ensure the signal does
not get hijacked and data tampered or stolen.
Aggregate
Link aggregation (IEEE 802.3ad) enables you to bind two or more physical interfaces
together to form an aggregated (combined) link. This new link has the bandwidth of all the
links combined. If a link in the group fails, traffic is transferred automatically to the
remaining interfaces with the only noticeable effect being a reduced bandwidth.
This is similar to redundant interfaces with the major difference being that a redundant
interface group only uses one link at a time, where an aggregate link group uses the total
bandwidth of the functioning links in the group, up to eight.
Support of the IEEE standard 802.3ad for link aggregation is available on some models.
An interface is available to be an aggregate interface if:
• it is a physical interface, not a VLAN interface or subinterface
• it is not already part of an aggregate or redundant interface
• it is in the same VDOM as the aggregated interface. Aggregate ports cannot span
multiple VDOMs.
• it does not have a IP address and is not configured for DHCP or PPPoE
• it is not referenced in any firewall policy, VIP, IP Pool or multicast policy
• it is not an HA heartbeat interface
• it is not one of the FortiGate-5000 series backplane interfaces
To see if a port is being used or has other dependencies, use the following diagnose
command:
diagnose sys system.interface.name <interface_name>
When an interface is included in an aggregate interface, it is not listed on the System >
Network > Interface page. Interfaces will still appear in the CLI, although configuration for
those interfaces will not take affect. You cannot configure the interface individually and it is
not available for inclusion in firewall policies, VIPs, IP pools, or routing.
You can add an accelerated interface (FA2, NP2 interfaces) to an aggregate link, but you
will lose the acceleration. For example, if you aggregate two accelerated interfaces you
will get slower throughput than if the two interfaces were separate.
204 01-420-99686-20101026
Example
This example creates an aggregate interface on a FortiGate-3810A using ports 4-6 with
an internal IP address of 10.13.101.100, as well as the administrative access to HTTPS
and SSH.
To create an aggregate interface - web-based manager

1 Go to System > Network > Interface and select Create New.
2 Enter the Name as Aggregate.
3 For the Type, select 802.3ad Aggregate.
If this option does not appear, your FortiGate unit does not support aggregate
interfaces.
4 In the Available Interfaces list, select port 4, 5 and 6 and move it to the Selected
Interfaces list.
7 For Administrative Access select HTTPS and SSH.
8 Select OK.
To create aggregate interface - CLI

edit Aggregate
set type aggregate
set member port4 port5 port6
set vdom root
set ip 172.20.120.100/24
end
Virtual domains
Virtual domains (VDOMs) are a method of dividing a FortiGate unit into two or more virtual
units that function as multiple independent units. A single FortiGate unit is then flexible
enough to serve multiple departments of an organization, separate organizations, or to act
as the basis for a service provider’s managed security service.
Note: Some smaller FortiGate units do not support virtual domains.
VDOMs provide separate security domains that allow separate zones, user authentication,
firewall policies, routing, and VPN configurations. By default, each FortiGate unit has a
VDOM named root. This VDOM includes all of the FortiGate physical interfaces, modem,
VLAN subinterfaces, zones, firewall policies, routing settings, and VPN settings.
When a packet enters a VDOM, it is confined to that VDOM. In a VDOM, you can create
firewall policies for connections between Virtual LAN (VLAN) subinterfaces or zones in the
VDOM. Packets do not cross the virtual domain border internally. To travel between
VDOMs, a packet must pass through a firewall on a physical interface. The packet then
arrives at another VDOM on a different interface, but it must pass through another firewall
before entering the VDOM. Both VDOMs are on the same FortiGate unit. Inter-VDOMs
change this behavior in that they are internal interfaces; however their packets go through
all the same security measures as on physical interfaces.
01-420-99686-20101026 205
Example
This example shows how to enable VDOMs on the FortiGate unit and the basic and create
a VDOM accounting on the DMZ2 port and assign an administrator to maintain the VDOM.
First enable Virtual Domains on the FortiGate unit. When you enable VDOMs, the
FortiGate unit will log you out.
To enable VDOMs - web-based manager

2 In the System Information widget, select Enable for Virtual Domain.
The FortiGate unit logs you out. Once you log back in, you will notice that the menu
structure has changed. This reflects the global settings for all Virtual Domains.
To enable VDOMs - CLI

set vdom-admin enable
end
Next, add the VDOM called accounting.
To add a VDOM - web-based manager

1 Go to System > VDOM > VDOM, and select Create New.
2 Enter the VDOM name accounting.
3 Select OK.
To add a VDOM - CLI
config vdom
edit <new_vdom_name>
end
With the Virtual Domain created, you can assign a physical interface to it, and assign it an
IP address.
To assign physical interface to the accounting Virtual Domain - web-based manager

2 Select the DMZ2 port row and select Edit.
3 For the Virtual Domain drop-down list, select accounting.
6 Set the Administrative Access to HTTPS and SSH.
7 Select OK.
To assign physical interface to the accounting Virtual Domain - CLI

config global
edit dmz2
set vdom accounting
set ip 10.13.101.100/24
next
end
206 01-420-99686-20101026
Virtual LANs
The term VLAN subinterface correctly implies the VLAN interface is not a complete
interface by itself. You add a VLAN subinterface to the physical interface that receives
VLAN-tagged packets. The physical interface can belong to a different VDOM than the
VLAN, but it must be connected to a network route that is configured for this VLAN.
Without that route, the VLAN will not be connected to the network, and VLAN traffic will not
be able to access this interface.The traffic on the VLAN is separate from any other traffic
on the physical interface.
FortiGate unit interfaces cannot have overlapping IP addresses—the IP addresses of all
interfaces must be on different subnets. This rule applies to both physical interfaces and to
virtual interfaces such as VLAN subinterfaces. Each VLAN subinterface must be
configured with its own IP address and netmask. This rule helps prevent a broadcast
storm or other similar network problems.
Any FortiGate unit, with or without VDOMs enabled, can have a maximum of 255
interfaces in Transparent operating mode. In NAT/Route operating mode, the number can
range from 255 to 8192 interfaces per VDOM, depending on the FortiGate model. These
numbers include VLANs, other virtual interfaces, and physical interfaces. To have more
than 255 interfaces configured in Transparent operating mode, you need to configure
multiple VDOMs with many interfaces on each VDOM.
Example
This example shows how to add a VLAN, vlan_accounting on the FortiGate unit internal
interface with an IP address of 10.13.101.101.
To add a VLAN - web-based manager

1 Go to System > Network > Interface and select Create New.
The Type is by default set to VLAN.
2 Enter a name for the VLAN to vlan_accounting.
3 Select the Internal interface.
4 Enter the VLAN ID.
The VLAN ID is a number between 1 and 4094 that allow groups of IP addresses with
the same VLAN ID to be associated together.
7 Set the Administrative Access to HTTPS and SSH.
8 Select OK.
To add a VLAN - CLI

edit VLAN_1
set interface internal
set type vlan
set vlanid 100
set ip 10.13.101.101/24
next
end
01-420-99686-20101026 207
Zones
Zones are a group of one or more FortiGate interfaces, both physical and virtual, that you
can apply firewall policies to control inbound and outbound traffic. Grouping interfaces and
VLAN subinterfaces into zones simplifies the creation of firewall policies where a number
of network segments can use the same policy settings and protection profiles. When you
add a zone, you select the names of the interfaces and VLAN subinterfaces to add to the
zone.
For example, in the illustration below, the network includes three separate groups of users
representing different entities on the company network. While each group has its own set
of port and VLANs, in each area, they can all use the same firewall policy and protection
profiles to access the Internet. Rather than the administrator making nine separate firewall
policies, he can add the required interfaces to a zone, and create three policies, making
administration simpler.
Figure 20: Network zones
Zone 1
Zone 1 policies
WAN1, DMZ1,
Zo VLAN 1, 2, 4
ne
2p
Zone 3
oli
cie
s
policies
Zone 2
Internal
ports 1, 2, 3
Zone 3
WAN2, DMZ2,
VLAN 3
You can configure policies for connections to and from a zone, but not between interfaces
in a zone. Using the above example, you can create a firewall policy to go between zone 1
and zone 3, but not between WAN2 and WAN1, or WAN1 and DMZ1.
Example
This example explains how to set up a zone on the FortiGate unit to include the Internal
interface and a VLAN.
To create a zone - web-based manager

1 Go to System > Network > Zone, and select Create New.
2 Enter a zone name of Zone_1.
208 01-420-99686-20101026
Firewall components Addressing
3 Select the Internal interface and the virtual LAN interface vlan_accounting from the
previous section.
4 Select OK.
To create a zone - CLI

config system zone
edit Zone_1
set interface internal VLAN_1
end
Addressing
Firewall addresses and address groups define network addresses that you can use when
configuring a firewall policies’ source and destination address fields. The FortiGate unit
compares the IP addresses contained in packet headers with firewall policy source and
destination addresses to determine if the firewall policy matches the traffic. Addressing in
firewall policies can be IPv4 addresses and address ranges, IPv6 addresses, and fully
qualified domain names (FQDNs).
A firewall address can contain one or more network addresses. Network addresses can
be represented by an IP address with a netmask, an IP address range, or a fully qualified
domain name (FQDN).
When representing hosts by an IP address with a netmask, the IP address can represent
one or more hosts. For example, a firewall address can be:
• a single computer, such as 192.45.46.45
• a subnetwork, such as 192.168.1.0 for a class C subnet
• 0.0.0.0, which matches any IP address
The netmask corresponds to the subnet class of the address being added, and can be
represented in either dotted decimal or CIDR format. The FortiGate unit automatically
converts CIDR formatted netmasks to dotted decimal format. Example formats:
• netmask for a single computer: 255.255.255.255, or /32
• netmask for a class A subnet: 255.0.0.0, or /8
• netmask for a class B subnet: 255.255.0.0, or /16
• netmask for a class C subnet: 255.255.255.0, or /24
• netmask including all IP addresses: 0.0.0.0
Valid IP address and netmask formats include:
• x.x.x.x/x.x.x.x, such as 192.168.1.0/255.255.255.0
• x.x.x.x/x, such as 192.168.1.0/24
Note: An IP address 0.0.0.0 with netmask 255.255.255.255 is not a valid firewall

address.
When representing hosts by an IP Range, the range indicates hosts with continuous IP
addresses in a subnet, such as 192.168.1.[2-10], or 192.168.1.* to indicate the
complete range of hosts on that subnet. Valid IP Range formats include:
• x.x.x.x-x.x.x.x, such as 192.168.110.100-192.168.110.120
• x.x.x.[x-x], such as 192.168.110.[100-120]
01-420-99686-20101026 209
Addressing Firewall components
• x.x.x.*, such as 192.168.110.*

When representing hosts by a FQDN, the domain name can be a subdomain, such as
mail.example.com. A single FQDN firewall address may be used to apply a firewall policy
to multiple hosts, as in load balancing and high availability (HA) configurations. FortiGate
units automatically resolve and maintain a record of all addresses to which the FQDN
resolves. Valid FQDN formats include:
• <host_name>.<second_level_domain_name>.<top_level_domain_name>, such as
mail.example.com
• <host_name>.<top_level_domain_name>
Caution: Be cautious when employing FQDN firewall addresses. Using a fully qualified
domain name in a firewall policy, while convenient, does present some security risks,
because policy matching then relies on a trusted DNS server. Should the DNS server be
compromised, firewall policies requiring domain name resolution may no longer function
properly.
Example
This example adds an IPv4 firewall address for guest users of 10.13.101.100 address the
port1 interface.
To add a firewall IP address to the port1 interface - web-based manager

1 Go to Firewall > Address > Address and select Create New.
2 For the Address Name, enter Guest.
3 Leave the Type as Subnet/IP Range.
4 Enter the IP address of 10.13.101.100/24.
5 For the Interface, select port1.
6 Select OK.
To add a firewall IP address to the port1 interface- CLI

edit Guest
set type ipmask
set subnet 10.13.101.100/24
set associated-interface port1
end
Example
This example adds an IPv4 firewall address range for guest users with the range of
10.13.101.100 to 10.13.101.110 addresses on any interface. By setting the interface to
Any, the address range is not bound to a specific interface on the FortiGate unit.
To add a firewall IP address to the port1 interface - web-based manager

3 Leave the Type as Subnet/IP Range.
4 Enter the IP address range of 10.13.101.[100-110].
5 For the Interface, select Any.
6 Select OK.
210 01-420-99686-20101026
To add a firewall IP address to the port1 interface - CLI

edit Guest
set type iprange
set start-ip 10.13.101.100
set end-ip 10.13.101.110
end
Wildcard masks
Wildcard masks, are common with OSPF and Cisco routers. The use of wildcard masks is
most prevalent when building Access Control Lists (ACLs) on Cisco routers. ACLs are
filters and make use of wildcard masks to define the scope of the address filter.
Masks are used with IP addresses to specify what addresses are permitted and denied.
To configure IP addresses on interfaces, the netmask starts with 255. For example, to filter
a subnetwork 10.1.1.0 which has a Class C mask of 255.255.255.0, the ACL will require
the scope of the addresses to be defined by a wildcard mask which, in this example is
0.0.0.255. When the value of the mask is shown in binary (0s and 1s), the results
determine which address bits are the “do and don’t care” bits for processing the traffic. A
zero is the do care bit and the one is a don’t care bit. This is also known as an inverse
mask.
For example, an address of 1.1.1.0, and a netmask of 0.0.0.255 would appear in binary as
an address of 00000001.00000001.00000001.00000000 and a netmask of
00000000.00000000.00000000.11111111
Based on the binary mask, it can be seen that the first three octets of the address must
match the given binary network address exactly (00000001.00000001.00000001). The
last set of numbers is made of “don't cares” (all ones). As such, all traffic that begins with
1.1.1. matches since the last octet o the netmask is “don't care”. All IP addresses 1.1.1.1
through 1.1.1.255 are acceptable.
Wildcard masks are configured in the CLI:
set type wildcard
set wildcard 1.1.1.0/0.0.0.255
end
Fully Qualified Domain Name addresses

Using Fully Qualified Domain Name (FQDN) addresses in firewall policies has the
advantage of causing the FortiGate unit to keep track of DNS TTLs and adapt as records
change. As long as the FQDN address is used in a firewall policy, it stores the address in
the DNS cache. The FortiGate unit will query the DNS for an amount of time specified, in
seconds, and update the cache as required. This feature can reduce maintenance
requirements for changing firewall addresses for dynamic IP addresses. This also means
that you can create firewall policies for networks configured with dynamic addresses using
DHCP.
Caution: Be cautious when employing FQDN firewall addresses. Using a fully qualified
domain name in a firewall policy, while convenient, does present some security risks,
because policy matching then relies on a trusted DNS server. Should the DNS server be
compromised, firewall policies requiring domain name resolution may no longer function
properly.
You specify the TTL time in the CLI only. For example, to set the TTL for 30 minutes on an
FQDN of www.example.com on port 1, enter the following commands:
01-420-99686-20101026 211

edit FQDN_example
set type fdqn
set associated-interface port 1
set fqdn www.example.com
set cache-ttl 1800
end
Virtual IPs
Virtual IP addresses (VIPs) can be used when configuring firewall policies to translate IP
addresses and ports of packets received by a network interface. When the FortiGate unit
receives inbound packets matching a firewall policy whose Destination Address field is a
virtual IP, the FortiGate unit applies NAT, replacing packets’ IP addresses with the virtual
IP’s mapped IP address.
IP pools, similarly to virtual IPs, can be used to configure aspects of NAT; however, IP
pools configure dynamic translation of packets’ IP addresses based on the Destination
Interface/Zone, whereas virtual IPs configure dynamic or static translation of a packets’ IP
addresses based upon the Source Interface/Zone.
To implement the translation configured in the virtual IP or IP pool, you must add it to a
NAT firewall policy.
Note: In Transparent mode, from the CLI, you can configure NAT firewall policies that
include Virtual IPs and IP pools. For more information, see the System Administration
chapter of The Handbook.
Virtual IPs can specify translations of packets’ port numbers and/or IP addresses for both
inbound and outbound connections. In Transparent mode, virtual IPs are available from
the FortiGate CLI.
Example
This example adds a virtual IP of 10.13.100.1 that allows users on the Internet to connect
to a web server on the DMZ IP address of 192.168.1.1. In the example, the wan1 interface
of the FortiGate unit is connected to the Internet and the dmz1 interface is connected to
the DMZ network.
To add a static NAT virtual IP for a single IP address - web-based manager

1 Go to Firewall > Virtual IP > Virtual IP and select Create New.
2 For the Name, enter Static_NAT.
3 Select the External interface of wan1
4 Enter the External IP Address of 10.13.100.1.
5 Enter the Mapped IP Address of 192.168.1.1.
6 Select OK.
To add a static NAT virtual IP for a single IP address - CLI

config firewall vip
edit Static_NAT
set extintf wan1
set extip 10.13.100.1
end
212 01-420-99686-20101026
Inbound connections
Virtual IPs can be used in conjunction with firewall policies whose Action is not DENY to
apply bidirectional NAT, also known as inbound NAT.
When comparing packets with the firewall policy list to locate a matching policy, if a firewall
policy’s Destination Address is a virtual IP, FortiGate units compares packets’ destination
address to the virtual IP’s external IP address. If they match, the FortiGate unit applies the
virtual IP’s inbound NAT mapping, which specifies how the FortiGate unit translates
network addresses and/or port numbers of packets from the receiving (external) network
interface to the network interface connected to the destination (mapped) IP address or IP
address range.
In addition to specifying IP address and port mappings between interfaces, virtual IP
configurations can optionally bind an additional IP address or IP address range to the
receiving network interface. By binding an additional IP address, you can configure a
separate set of mappings that the FortiGate unit can apply to packets whose destination
matches that bound IP address, rather than the IP address already configured for the
network interface.
Depending on your configuration of the virtual IP, its mapping may involve port address
translation (PAT), also known as port forwarding or network address port translation
(NAPT), and/or network address translation (NAT) of IP addresses.
If you configure NAT in the virtual IP and firewall policy, the NAT behavior varies by your
selection of:
• static vs. dynamic NAT mapping
• the dynamic NAT’s load balancing style, if using dynamic NAT mapping
• full NAT vs. destination NAT (DNAT)
The following table describes combinations of PAT and/or NAT that are possible when
configuring a firewall policy with a virtual IP.
Static NAT Static, one-to-one NAT mapping: an external IP address is always translated to
the same mapped IP address.
If using IP address ranges, the external IP address range corresponds to a
mapped IP address range containing an equal number of IP addresses, and
each IP address in the external range is always translated to the same IP
address in the mapped range.
Static NAT with Static, one-to-one NAT mapping with port forwarding: an external IP address is
Port Forwarding always translated to the same mapped IP address, and an external port number
is always translated to the same mapped port number.
If using IP address ranges, the external IP address range corresponds to a
mapped IP address range containing an equal number of IP addresses, and
each IP address in the external range is always translated to the same IP
address in the mapped range. If using port number ranges, the external port
number range corresponds to a mapped port number range containing an equal
number of port numbers, and each port number in the external range is always
translated to the same port number in the mapped range.
01-420-99686-20101026 213
Server Load Dynamic, one-to-many NAT mapping: an external IP address is translated to one
Balancing of the mapped IP addresses, as determined by the selected load balancing
algorithm for more even traffic distribution. The external IP address is not always
translated to the same mapped IP address.
Server load balancing requires that you configure at least one “real” server, but
can use up to eight. Real servers can be configured with health check monitors.
Health check monitors can be used to gauge server responsiveness before
forwarding packets.
Server Load Dynamic, one-to-many NAT mapping with port forwarding: an external IP
Balancing with address is translated to one of the mapped IP addresses, as determined by the
Port Forwarding selected load balancing algorithm for more even traffic distribution. The external
IP address is not always translated to the same mapped IP address.
Server load balancing requires that you configure at least one “real” server, but
can use up to eight. Real servers can be configured with health check monitors.
Health check monitors can be used to gauge server responsiveness before
forwarding packets.
Note: If the NAT check box is not selected when building the firewall policy, the resulting
policy does not perform full (source and destination) NAT; instead, it performs destination
network address translation (DNAT).
For inbound traffic, DNAT translates packets’ destination address to the mapped private IP
address, but does not translate the source address. The private network is aware of the
source’s public IP address. For reply traffic, the FortiGate unit translates packets’ private
network source IP address to match the destination address of the originating packets,
which is maintained in the session table.
A typical example of static NAT is to allow client access from a public network to a web
server on a private network that is protected by a FortiGate unit. Reduced to its essence,
this example involves only three hosts, as shown in Figure 21: the web server on a private
network, the client computer on another network, such as the Internet, and the FortiGate
unit connecting the two networks.
When a client computer attempts to contact the web server, it uses the virtual IP on the
FortiGate unit’s external interface. The FortiGate unit receives the packets. The addresses
in the packets are translated to private network IP addresses, and the packet is forwarded
to the web server on the private network.
Figure 21: A simple static NAT virtual IP example
Int
e
S 10
10 rnal
10
er .1
ve 0.
.
.10 IP
r 42
.10
IP
.2
V
19 irtua
2.1 l IP
68
.37
.4
19
C 168
lie .
2.
nt 37
IP .55
214 01-420-99686-20101026
The packets sent from the client computer have a source IP of 192.168.37.55 and a
destination IP of 192.168.37.4. The FortiGate unit receives these packets at its external
interface, and matches them to a firewall policy for the virtual IP. The virtual IP settings
map 192.168.37.4 to 10.10.10.42, so the FortiGate unit changes the packets’ addresses.
The source address is changed to 10.10.10.2 and the destination is changed to
10.10.10.42. The FortiGate unit makes a note of this translation in the firewall session
table it maintains internally. The packets are then sent on to the web server.
Figure 22: Example of packet address remapping during NAT from client to server
.2
0 .10 0.42
. 1 1
10 0.
e IP 10.1
urc IP
1
So ation 3
2
n
sti
De NA
Tw
ith
av
irtu
al 1
IP 3
2 5
7.5 4
6 8.3 .37.
2.1 68
P 19 92.1
e I IP 1
o urc tion
S ina
st
De
Note that the client computer’s address does not appear in the packets the server
receives. After the FortiGate unit translates the network addresses, there is no reference
to the client computer’s IP address, except in its session table. The web server has no
indication that another network exists. As far as the server can tell, all packets are sent by
the FortiGate unit.
When the web server replies to the client computer, address translation works similarly,
but in the opposite direction. The web server sends its response packets having a source
IP address of 10.10.10.42 and a destination IP address of 10.10.10.2. The FortiGate unit
receives these packets on its internal interface. This time, however, the session table is
used to recall the client computer’s IP address as the destination address for the address
translation. In the reply packets, the source address is changed to 192.168.37.4 and the
destination is changed to 192.168.37.55. The packets are then sent on to the client
computer.
The web server’s private IP address does not appear in the packets the client receives.
After the FortiGate unit translates the network addresses, there is no reference to the web
server’s network. The client has no indication that the web server’s IP address is not the
virtual IP. As far as the client is concerned, the FortiGate unit’s virtual IP is the web server.
01-420-99686-20101026 215
Figure 23: Example of packet address remapping during NAT from server to client
.42
0 .10 10.2
0.1 10.
I P 1 10.
e IP
urc n
1
So inatio 3
2
st
De NA
Tw
ith
av
irtu
al
IP 1
3
2
7.4 5
6 8.3 37.5
.1 .
92 168
I P 1 192.
e
urc IP
So ation
tin
D es
In the previous example, the NAT check box is checked when configuring the firewall
policy. If the NAT check box is not selected when building the firewall policy, the resulting
policy does not perform full NAT; instead, it performs destination network address
translation (DNAT).
For inbound traffic, DNAT translates packets’ destination address to the mapped private IP
address, but does not translate the source address. The web server would be aware of
the client’s IP address. For reply traffic, the FortiGate unit translates packets’ private
network source IP address to match the destination address of the originating packets,
which is maintained in the session table.
Outbound connections
Virtual IPs can also affect outbound NAT, even though they are not selected in an
outbound firewall policy. If no virtual IPs are configured, FortiGate units apply traditional
outbound NAT to connections outbound from private network IP addresses to public
network IP addresses. However, if virtual IP configurations exist, FortiGate units use
virtual IPs’ inbound NAT mappings in reverse to apply outbound NAT, causing IP address
mappings for both inbound and outbound traffic to be symmetric.
For example, if a network interface’s IP address is 10.10.10.1, and its bound virtual IP’s
external IP is 10.10.10.2, mapping inbound traffic to the private network IP address
192.168.2.1, traffic outbound from 192.168.2.1 will be translated to 10.10.10.2, not
10.10.10.1.
Note: A virtual IP setting with port forwarding enabled does not translate the
source address of outbound traffic. If both virtual IP (without port forwarding) and
IP Pools are enabled, IP Pools is preferred for source address translation of
outbound traffic.
216 01-420-99686-20101026
Virtual IP, load balance virtual server / real server limitations

The following limitations apply when adding virtual IPs, load balancing virtual servers, and
load balancing real servers. Load balancing virtual servers are actually server load
balancing virtual IPs. You can add server load balance virtual IPs from the CLI.
• Virtual IP External IP Address/Range entries or ranges cannot overlap with each
other or with load balancing virtual server Virtual Server IP entries.
• A virtual IP Mapped IP Address/Range cannot be 0.0.0.0 or 255.255.255.255.
• A real server IP cannot be 0.0.0.0 or 255.255.255.255.
• If a static NAT virtual IP External IP Address/Range is 0.0.0.0, the Mapped IP
Address/Range must be a single IP address.
• If a load balance virtual IP External IP Address/Range is 0.0.0.0, the Mapped IP
Address/Range can be an address range.
• When port forwarding, the count of mapped port numbers and external port
numbers must be the same. The web-based manager does this automatically but
the CLI does not.
Virtual IP and virtual server names must be different from firewall address or address
group names.
Address groups
Similar to zones, if you have a number of addresses or address ranges that require the
same firewall policies, you can put them into address groups, rather than creating multiple
similar policies. Because firewall policies require addresses with homogenous network
interfaces, address groups should contain only addresses bound to the same network
interface, or to Any — addresses whose selected interface is Any are bound to a network
interface during creation of a firewall policy, rather than during creation of the firewall
address.
For example, if address 1.1.1.1 is associated with port1, and address 2.2.2.2 is associated
with port2, they cannot be in the same group. However, if 1.1.1.1 and 2.2.2.2 are
configured with an interface of Any, they can be grouped, even if the addresses involve
different networks.
You cannot mix IPv4 firewall addresses and IPv6 firewall addresses in the same address
group.
Example
This example creates an address group accounting, where addresses for User_1 and
User_2 have port association of Any. It is recommended to add the addresses you want to
add to the group before setting up the address group.
Setup
To create an address group - web-based manager
1 Go to Firewall > Address > Group, and select Create New.
2 Enter the Group Name of accounting.
3 From the Available Addresses list, select an address and select the down-arrow button
to move the address name to the Members list.
4 Repeat step three as many times as required. You can also hold the SHIFT key to
select a range of address names from the list.
5 Select OK.
01-420-99686-20101026 217
To create an address group - CLI

config firewall addrgrp
edit accounting
set member User_1
set member User_2
end
DHCP
The Dynamic Host Configuration Protocol (DHCP) enables hosts to automatically obtain
an IP address from a DHCP server. Optionally, hosts can also obtain default gateway and
DNS server settings.
Note: DHCP is not available when the FortiGate unit is operating in Transparent mode.
On FortiGate 30B, 50 and 60 series units, a DHCP server is configured, by default, on the
Internal interface, as follows:
IP Range 192.168.1.110 to 192.168.1.210

Netmask 255.255.255.0
Default gateway 192.168.1.99
Lease time 7 days
DNS Server 1 192.168.1.99
A FortiGate interface can provide the following DHCP services:

• Basic DHCP servers
• IPSec DHCP servers for IPSec (VPN) connections
• DHCP relay for regular Ethernet or IPSec (VPN) connections
An interface cannot provide both a server and a relay for connections of the same type.
You can configure one or more DHCP servers on any FortiGate interface. A DHCP server
dynamically assigns IP addresses to hosts on the network connected to the interface. The
host computers must be configured to obtain their IP addresses using DHCP. The IP
range of each DHCP server must match the network address range. The routers must be
configured for DHCP relay.
Example
This example sets up a DHCP server on the Internal interface for guests with an IP range
of 10.13.101.100 to 10.13.101.110, a default gateway of 10.13.101.2 and address lease of
5 days.
To configure a DHCP server on the internal interface - web-based manager

1 Go to System > DHCP Server > Service.
2 For the internal interface, select the ‘plus’ sign for Servers and complete the following:
Name Guest DHCP
Type Regular
IP Range 10.13.101.100
10.13.101.110
Netmask 255.255.255.0
218 01-420-99686-20101026
Default Gateway 10.13.101.2

Lease 5 days
3 Select OK.
To configure a DHCP server on the internal interface - CLI

config system dhcp server
edit guest_dhcp
set server-type regular
set start-ip 10.13.101.100
set end-ip 10.13.101.105
set netmask 255.255.255.0
set default-gateway 10.13.101.2
set lease-time 432000
end
A FortiGate interface can also be configured as a DHCP relay. The interface forwards
DHCP requests from DHCP clients to an external DHCP server and returns the responses
to the DHCP clients. The DHCP server must have appropriate routing so that its response
packets to the DHCP clients arrive at the FortiGate unit.
Example
This example sets up a DHCP relay on the internal interface from the DHCP server
located at 172.20.120.55. The FortiGate unit will send a request for an IP address from the
defined DHCP server and forward it to the requesting connection.
To configure a DHCP relay on the internal interface - web-based manager

1 Go to System > DHCP Server > Service.
2 Select the internal interface and select Edit for the Relay option.
3 Select Enable for the DHCP Relay Agent.
4 Select the Type of Regular.
5 Enter the DHCP Server IP address of 172.20.120.55.
6 Select OK.
To configure a DHCP server on the internal interface - CLI

edit internal
set dhcp-relay-service enable
set dhcp-relay-type regular
set dhcp-relay-ip 172.20.120.55
end
IP pools
An IP pool defines a single IP address or a range of IP addresses. A single IP address in
an IP pool becomes a range of one IP address. For example, if you enter an IP pool as
1.1.1.1, the IP pool is actually the address range, 1.1.1.1 to 1.1.1.1. Use IP pools to add
NAT policies that translate source addresses to addresses randomly selected from the IP
pool, rather than the IP address assigned to that FortiGate interface.
If a FortiGate interface IP address overlaps with one or more IP pool address ranges, the
interface responds to ARP requests for all of the IP addresses in the overlapping IP pools.
01-420-99686-20101026 219
For example, consider a FortiGate unit with the following IP addresses for the port1 and
port2 interfaces:
• port1 IP address: 1.1.1.1/255.255.255.0 (range is 1.1.1.0-1.1.1.255)
• port2 IP address: 2.2.2.2/255.255.255.0 (range is 2.2.2.0-2.2.2.255)
And the following IP pools:
• IP_pool_1: 1.1.1.10-1.1.1.20
• IP_pool_2: 2.2.2.10-2.2.2.20
• IP_pool_3: 2.2.2.30-2.2.2.40
The port1 interface overlap IP range with IP_pool_1 is:
• (1.1.1.0-1.1.1.255) and (1.1.1.10-1.1.1.20) = 1.1.1.10-1.1.1.20
• (2.2.2.0-2.2.2.255) & (2.2.2.10-2.2.2.20) = 2.2.2.10-2.2.2.20
• (2.2.2.0-2.2.2.255) & (2.2.2.30-2.2.2.40) = 2.2.2.30-2.2.2.40
And the result is:
• The port1 interface answers ARP requests for 1.1.1.10-1.1.1.20
• The port2 interface answers ARP requests for 2.2.2.10-2.2.2.20 and for 2.2.2.30-
2.2.2.40
Select NAT in a firewall policy and then select Dynamic IP Pool. Select an IP pool to
translate the source address of packets leaving the FortiGate unit to an address randomly
selected from the IP pool.
Example
This example sets up an IP Pool with an address range of 10.13.101.100 to 10.13.101.110
for guest accounts on the network.
To configure an IP Pool - web-based manager

1 Go to Firewall > Virtual IP > IP Pool and select Create New.
2 Enter the Name of Guest.
3 Enter the IP Range/Subnet of 10.13.101.100-10.13.101.110.
4 Select OK.
To configure an IP Pool - CLI

config firewall ippool
edit Guest
set startip 10.13.101.100
set endip 10.13.101.110
end
IP Pools for firewall policies that use fixed ports

Some network configurations do not operate correctly if a NAT policy translates the source
port of packets used by the connection. NAT translates source ports to keep track of
connections for a particular service.
From the CLI you can enable fixedport when configuring a firewall policy for NAT
policies to prevent source port translation.
220 01-420-99686-20101026
config firewall policy

edit policy_name
...
set fixedport enable
...
end
However, enabling fixedport means that only one connection can be supported
through the firewall for this service. To be able to support multiple connections, add an IP
pool, and then select Dynamic IP pool in the policy. The firewall randomly selects an IP
address from the IP pool and assigns it to each connection. In this case, the number of
connections that the firewall can support is limited by the number of IP addresses in the IP
pool.
Source IP address and IP pool address matching

When the source addresses are translated to the IP pool addresses, one of the following
three cases may occur:
Scenario 1: The number of source addresses equals that of IP pool addresses

In this case, the FortiGate unit always matches the IP addressed one to one.
If you enable fixedport in such a case, the FortiGate unit preserves the original source
port. This may cause conflicts if more than one firewall policy uses the same IP pool, or
the same IP addresses are used in more than one IP pool.
Original address Change to

192.168.1.1 172.16.30.1
192.168.1.2 172.16.30.2
...... ......
192.168.1.254 172.16.30.254
Scenario 2: The number of source addresses is more than that of IP pool addresses
In this case, the FortiGate unit translates IP addresses using a wrap-around mechanism.
If you enable fixedport in such a case, the FortiGate unit preserves the original source
port. But conflicts may occur since users may have different sessions using the same TCP
5 tuples.

192.168.1.1 172.16.30.10
192.168.1.2 172.16.30.11
...... ......
192.168.1.10 172.16.30.19
192.168.1.11 172.16.30.10
192.168.1.12 172.16.30.11
192.168.1.13 172.16.30.12
...... ......
01-420-99686-20101026 221
Scenario 3: The number of source addresses is fewer than that of IP pool addresses
In this case, some of the IP pool addresses are used and the rest of them are not be used.

192.168.1.1 172.16.30.10
192.168.1.2 172.16.30.11
192.168.1.3 172.16.30.12
No more source addresses 172.16.30.13 and other addresses are not used
IPv6
Internet Protocol version 6 (IPv6) is the next-generation version of IP addressing, to
eventually replace IPv4. IPv6 was developed because there is a concern that in the near
future, the available addresses for the IPv4 infrastructure will be exhausted. The IPv6
infrastructure will supplement, and eventually, replace the IPv4 standard.
Where IPv4 uses 32 bit addressing, IPv6 uses 128 bit addressing, effectively providing
trillions upon trillions of unique addresses, whereas IPv4 can have a a little over 4 billion.
With this larger address space, allocating addresses and routing traffic becomes easier,
and network address translation (NAT) becomes virtually unnecessary.
Where IPv4 addresses are written numerals separated by a decimal, the IPv6 address is
written with hexadecimal digits separated by a colon. For example,
fe80:218:8bff:fe84:4223.
By default, the FortiGate unit is not enabled to use IPv6 addressing. To enable this
feature, go to System > Admin > Settings and select IPv6 Support on GUI. When enabled
you can use IPv6 addressing on any of the address-dependant components of the
FortiGate unit, including firewall policies, interface addressing, DNS servers. IPv6
addressing can be configured on the web-based manager and in the CLI.
For further information on IPV6 in FortiOS, see “IPv6” on page 459.
Example
This example adds an IPv6 address 2001:db8:0:1234:0:567:1:1 for the WAN1 interface as
well as the administrative access to HTTPS and SSH. As a good practice, set the
administrative access when you are setting the IP address for the port.
To add an IP address for the WAN1 interface - web-based manager

2 Select WAN1 row and select Edit.
4 Enter the IPv6 Address of 2001:db8:0:1234:0:567:1:1.
5 For Administrative Access select HTTPS and SSH.
6 Select OK.
222 01-420-99686-20101026
Firewall components Ports
To create IP address for the WAN1 interface - CLI

edit wan1
config ipv6
set ip6-address 2001:db8:0:1234:0:567:1:1
set ip6-allowaccess https ssh
end
end
Example
This example adds an IPv6 firewall address for guest users of 2001:db8:0:1234:0:567:1:1.
To add a firewall IPv6 address - web-based manager

1 Go to Firewall > Address > Address.
2 On the Create New button, click the down arrow on the right.
If there is no arrow, ensure you have enabled IPv6 by going to System > Admin >
Settings and select IPv6 Support on GUI.
3 Select IPv6 Address.
5 Enter the IP address of 2001:db8:0:1234:0:567:1:1/128.
6 Select OK.
To add a firewall IPv6 address - CLI

config firewall address6
edit Guest
set ip6 2001:db8:0:1234:0:567:1:1/128
end
Ports
A port is a type of address used by specific applications and processes. The FortiGate unit
uses a number of port assignments to send and receive information for basic system
operation and communication by default.
Originating traffic
Function Port(s)
DNS lookup; RBL lookup UDP 53
FortiGuard Antispam or Web Filtering rating lookup UDP 53 or UDP
8888
FDN server list UDP 53 (default) or
Source and destination port numbers vary by originating or reply traffic. UDP 8888, and
UDP 1027 or UDP
1031
NTP synchronization UDP 123
SNMP traps UDP 162
01-420-99686-20101026 223
Ports Firewall components
Syslog UDP 514

All FortiOS versions can use syslog to send log messages to remote syslog
servers.
Note: If a secure connection has been configured between a FortiGate and a
FortiAnalyzer, Syslog traffic will be sent into an IPSec tunnel. Data will be
exchanged over UDP 500/4500, Protocol IP/50.
Configuration backup to FortiManager unit or FortiGuard Analysis and TCP 22
Management Service
SMTP alert email; encrypted virus sample auto-submit TCP 25
LDAP or PKI authentication TCP 389 or TCP
636
FortiGuard Antivirus or IPS update TCP 443
When requesting updates from a FortiManager unit instead of directly from the
FDN, this port must be reconfigured as TCP 8890.
FortiGuard Analysis and Management Service TCP 443
FortiGuard Analysis and Management Service log transmission (OFTP) TCP 514
SSL management tunnel to FortiGuard Analysis and Management Service TCP 541
FortiGuard Analysis and Management Service contract validation TCP 10151
Quarantine, remote access to logs & reports on a FortiAnalyzer unit, device TCP 514
registration with FortiAnalyzer units (OFTP)
RADIUS authentication TCP 1812
Receiving traffic
When operating in the default configuration, FortiGate units do not accept TCP or UDP
connections on any port except the default internal interface, which accepts HTTPS
connections on TCP port 443.
Function Port(s)
FortiGuard Antivirus and IPS update push UDP 9443
The FDN sends notice that an update is available. Update downloads then
occur on standard originating ports for updates.
SSH administrative access to the CLI; remote management from a TCP 22
FortiManager unit
Telnet administrative access to the CLI; HA synchronization (FGCP L2) TCP 23
Changing the telnet administrative access port number also changes the HA
synchronization port number.
HTTP administrative access to the web-based manager TCP 80
HTTPS administrative access to the web-based manager; remote TCP 443
management from a FortiManager unit; user authentication for policy override
SSL management tunnel from FortiGuard Analysis and Management Service TCP 541
(FortiOS v3.0 MR6 or later)
HA heartbeat (FGCP L2) TCP 703
User authentication keep alive and logout for policy override (default value of TCP 1000
port for HTTP traffic)
This port is closed until enabled by the auth-keepalive command.
User authentication keepalive and logout for policy override (default value of TCP 1003
port for HTTPS traffic)
This port is closed until enabled by the auth-keepalive command.
Windows Active Directory (AD) Collector Agent TCP 8000
User authentication for policy override of HTTP traffic TCP 8008
224 01-420-99686-20101026
Firewall components Ports
FortiClient download portal TCP 8009

This feature is available on FortiGate-1000A, FortiGate-3600A, and
FortiGate-5005FA2.
User authentication for policy override of HTTPS traffic TCP 8010
VPN settings distribution to authenticated FortiClient installations TCP 8900
SSL VPN TCP 10443
HA ETH 8890 (Layer 2)
Closing specific ports to traffic

By default, FortiGate units do not accept remote administrative access except by HTTPS
connections on TCP port 443 to the default internal network interface for some FortiGate
models. Restricting administrative access by default ensures that only you can change
your firewall policies and security configuration. It also improves security of the FortiGate
unit itself by reducing the number of ports that potential attackers can discover by network
probes and port scans, a common method of discovering open ports for denial of service
(DoS) attacks.
Port 113
TCP port 113 (Ident/Auth) is an exception to the above rule. By default, FortiGate units
receiving an IDENT request on this port respond with a TCP RST, which resets the
connection. This prevents delay that would normally occur if the requesting host were to
wait for the connection attempt to time out.
This port is less commonly used today. If you do not use this service, you can make your
FortiGate unit less visible to probes. You can disable TCP RST responses to IDENT
requests and subject those requests to firewall policies, and thereby close this port.
For each network interface that should not respond to ident requests on TCP port 113,
enter the following CLI commands:
edit <port_name>
set ident-accept enable
end
For example, to disable ident responses on a network interface names port1, enter the
following commands:
edit port1
set ident-accept enable
end
Port 541
By default, FortiGate units use this port to initiate an SSL-secured management tunnel
connection to centralized device managers such as the FortiGuard Analysis and
Management Service.
If you do not use centralized management you can make your FortiGate unit less visible to
probes. You can disable the management tunnel feature, and thereby close this port using
the following CLI command:
config sys central-management
set status disable
end
01-420-99686-20101026 225
Services Firewall components
Services
Services represent typical traffic types and application packets that pass through the
FortiGate unit. Firewall services define one or more protocols and port numbers
associated with each service. Firewall policies use service definitions to match session
types. You can organize related services into service groups to simplify your firewall
policy list.
Many well-known traffic types have been predefined in firewall services and protocols on
the FortiGate unit. These predefined services and protocols are defaults, and cannot be
edited or removed. However, if you require different services, you can create custom
services.
To view the predefined servers, go to Firewall > Service > Predefined.
Custom service
Should there be a service that does not appear on the list, or you have a unique service or
situation, you can create your own custom service. You need to know the port(s), IP
addresses or protocols the particular service or application uses to create the custom
service.
Example
This example creates a custom service for the “Widget” application, which communicates
on TCP port 9620 for source traffic and between ports 4545 and 4550 for destination
traffic.
To create a custom service - web-based manager

1 Go to Firewall > Service > Custom and select Create New.
2 Enter the following and select Add:
Name Widget
Protocol TCP
Source Port
Low 9620
Hi 9620
Destination Port
Low 4545
High 4550
3 Select OK.
To create a custom service - CLI

edit Widget
set tcp-portrange 9620:4545-4550
end
226 01-420-99686-20101026
Firewall components Schedules
Schedules
When you add firewall policies on a FortiGate unit, those policies are always on, policing
the traffic through the device. Firewall schedules control when policies are in effect, that is,
when they are on. You can create one-time schedules which are schedules that are in
effect only once for the period of time specified in the schedule. You can also create
recurring schedules that are in effect repeatedly at specified times of specified days of the
week.
You can create a recurring schedule that activates a policy during a specified period of
time. For example, you might prevent game playing during office hours by creating a
recurring schedule that covers office hours.
If a recurring schedule has a stop time that is earlier than the start time, the schedule will take effect
at the start time but end at the stop time on the next day. You can use this technique to create
recurring schedules that run from one day to the next. For example, to prevent game playing except
at lunchtime, you might set the start time for a recurring schedule at 1:00 p.m. and the stop time at
12:00 noon. To create a recurring schedule that runs for 24 hours, set the start and stop times to 00.
Example
This example creates a schedule for surfing the Internet at lunch time. The company
restricts the amount of surfing on company time, but over lunch, the restrictions are lifted.
For this schedule, a firewall policy would be created to enable all services for a limited
amount of time. This example sets up the time frame.
To create a recurring firewall schedule - web-based manager

1 Go to Firewall > Schedule > Recurring, and select Create New.
2 Enter the schedule Name of Lunch-Surfing.
3 Select the days of the week this schedule is employed.
In this case, Monday through Friday.
4 Select the Start Hour of 12.
5 Select the Stop Hour of 01.
6 Select OK.
To create a recurring firewall schedule - CLI

config firewall schedule recurring
edit Lunch-Surfing
set day monday tuesday wednesday thursday friday
set start 12:00
set end 1:00
end
Example
This example creates a one-time schedule for a firewall policy. In this example, a company
is shut down over the Christmas holidays. To prevent employees from coming to work to
use the internet connection, the company sets up a one-time firewall policy to block most
internet traffic during this time period. A schedule needs to be created to limit internet
traffic between December 25 and January 1.
01-420-99686-20101026 227
Schedules Firewall components
To create a one-time firewall schedule - web-based manager

1 Go to Firewall > Schedule > One-time, and select Create New.
2 Enter the schedule Name of Xmas-Shutdown.
3 Enter the following and select OK.
/Start
Year 2009
Month 12
Day 25
Hour 00
Minute 00
Stop
Year 2010
Month 01
Day 01
Hour 23
Minute 00
To create a firewall schedule - CLI

config firewall schedule onetime
edit Xmas-Shutdown
set start 00:00 2009/12/25
set end 23:00 2010/01/01
end
Schedule groups
You can organize multiple firewall schedules into a schedule group to simplify your firewall
policy list. For example, instead of having five identical policies for five different but related
firewall schedules, you might combine the five schedules into a single schedule group that
is used by a single firewall policy.
Schedule groups can contain both recurring and one-time schedules. Schedule groups
cannot contain other schedule groups.
Example
This example creates a schedule group for the schedules created in the previous
schedule examples. The schedule group enables you to have one firewall policy that
covers both schedules, rather than creating two separate policies.
To create a firewall schedule group - web-based manager

1 Go to Firewall > Schedule > Group, and select Create New.
2 Enter the group Name of Schedules.
3 From the Available Schedules list, select the Lunch-Surfing schedule and select the
down-arrow button to move the address name to the Members list.
4 From the Available Schedules list, select the Xmas-Shutdown schedule and select the
down-arrow button to move the address name to the Members list.
5 Select OK.
228 01-420-99686-20101026
Firewall components UTM profiles
To create a recurring firewall schedule - CLI

config firewall schedule group
edit Schedules
set member Lunch-Surfing Xmas-Shutdown
end
UTM profiles
Where firewall policies provide the instructions to the FortiGate unit as to what traffic is
allowed through the device, the Unified Threat Management (UTM) profiles provide the
screening that filters the content coming and going on the network. The UTM profiles
enable you to instruct the FortiGate unit what to look for in the traffic that you don’t want, or
want to monitor, as it passes through the device.
A UTM profile is a group of options and filters that you can apply to one or more firewall
policies. UTM profiles can be used by more than one firewall policy. You can configure
sets of UTM profiles for the traffic types handled by a set of firewall policies that require
identical protection levels and types, rather than repeatedly configuring those same UTM
profile settings for each individual firewall policy.
For example, while traffic between trusted and untrusted networks might need strict
antivirus protection, traffic between trusted internal addresses might need moderate
antivirus protection. To provide the different levels of protection, you might configure two
separate protection profiles: one for traffic between trusted networks, and one for traffic
between trusted and untrusted networks.
UTM profiles are available for various unwanted traffic and network threats. Each are
configured separately and can be used in different groupings as needed. You configure
UTM profiles in the UTM menu and applied when creating a firewall policy by selecting the
UTM profile type.
Profiles and sensors

The UTM profiles can be identified by two categories: profiles (VoIP, antivirus, web filter
and email filter) and sensors (intrusion prevention, application control and data leak
prevention). Profiles are a group of identifiers to filter unwanted email such as spam, web
content and provide virus detection. Sensors are a grouping of common or custom
signature information that the FortiGate unit uses to identify, or sense, an intrusion or data
leak and prevent it from occurring. FortiOS includes a selection of common sensors, and
you can create custom ones as well.
For both categories, you create a unique set of criteria for the profile or sensor and select
it for the firewall policy. When traffic passes through the FortiGate unit, the FortiGate unit
compares the traffic information to see if the policy is valid. If it is, it then applies the
profiles and sensors to the traffic to determine if the traffic is an attack, virus, spam or
unwanted web content and either blocks or allows the traffic through depending on how
the sensor or policy was configured.
FortiOS includes a selection default UTM profiles and sensors. The defaults provide
varying levels of security from very strict, monitoring or blocking everything, to very light
allowing most traffic through. You can use these default protection profiles as is to quickly
configure your network security or as the bases for creating your own.
01-420-99686-20101026 229
UTM profiles Firewall components
Example
This example creates an antivirus profile that will scan all email traffic for viruses. The new
profile will be called email_scan.
To create a antivirus profile for email - web-based manager

1 Go to UTM > AntiVirus > Profile and select Create New.
2 Enter the Name of email_scan.
3 For the Virus Scan row, select IMAP, POP3 and SMTP.
4 Select OK.
To create a antivirus profile for email - CLI

config antivirus profile
edit email_scan
config imap
set options scan
end
config smtp
set options scan
end
config pop3
set options scan
end
end
Example
This example creates an web filter profile that prevents Active X and Java applets from
being downloaded in a web browser when a user visits a web site with these elements on
the page. The new profile will be called activex_java.
To create a antivirus profile for email - web-based manager

1 Go to UTM > Web Filter > Profile and select Create New.
2 Enter the schedule Name of activex_java
3 Select the blue arrow for the Advanced Filter to expand the options.
4 Select the check boxes for ActiveX Filter and Java Applet Filter.
5 Select OK.
To create a antivirus profile for email - CLI

edit activex_java
config http
set options activexfilter
end
config http
set options javafilter
end
end
230 01-420-99686-20101026
Firewall Policies
Firewall policies control all traffic attempting to pass through the FortiGate unit, between
FortiGate interfaces, zones, and VLAN subinterfaces.
Firewall policies are instructions the FortiGate unit uses to decide connection acceptance
and packet processing for traffic attempting to pass through. When the firewall receives a
connection packet, it analyzes the packet’s source address, destination address, and
service (by port number), and attempts to locate a firewall policy matching the packet.
Firewall policies can contain many instructions for the FortiGate unit to follow when it
receives matching packets. Some instructions are required, such as whether to drop or
accept and process the packets, while other instructions, such as logging and
authentication, are optional.
Policy instructions may include network address translation (NAT), or port address
translation (PAT), or by using virtual IPs or IP pools to translate source and destination IP
addresses and port numbers.
Policy instructions may also include UTM profiles, which can specify application-layer
inspection and other protocol-specific protection and logging, as well as IPS inspection at
the transport layer.
This chapter describes what firewall policies are and how they affect all traffic to and from
your network. It also describes how to configure some key policies; these are basic
policies you can use as a building block to more complex policies, but they enable you to
get the FortiGate unit running on the network quickly.
This chapter contains the following topics:
• Policy order
• Creating basic policies
• DoS Policies
• Sniffer Policies
• Identity-based Policies
• ICMP packet processing
• Firewall policy examples
You configure firewall policies to define which sessions will match the policy and what
actions the FortiGate unit will perform with packets from matching sessions.
Sessions are matched to a firewall policy by considering these features of both the packet
and policy:
• Source Interface/Zone
• Source Address
• Destination Interface/Zone
• Destination Address
• Schedule and time of the session’s initiation
• Service and the packet’s port numbers.
If the initial packet matches the firewall policy, the FortiGate unit performs the configured
Action and any other configured options on all packets in the session.
01-420-99686-20101026 231
Policy order Firewall Policies
Packet handling actions can be ACCEPT, DENY, IPSEC or SSL-VPN.

• ACCEPT policy actions permit communication sessions, and may optionally include
other packet processing instructions, such as requiring authentication to use the policy,
or specifying one or more UTM profiles to apply features such as virus scanning to
packets in the session. An ACCEPT policy can also apply interface-mode IPSec VPN
traffic if either the selected source or destination interface is an IPSec virtual interface.
• DENY policy actions block communication sessions, and you can optionally log the
denied traffic. If no firewall policy matches the traffic, the packets are dropped,
therefore it is not required to configure a DENY firewall policy in the last position to
block the unauthorized traffic. A DENY firewall policy is needed when it is required to
log the denied traffic, also called “violation traffic”.
• IPSEC and SSL-VPN policy actions apply a tunnel mode IPSec VPN or SSL VPN
tunnel, respectively, and may optionally apply NAT and allow traffic for one or both
directions. If permitted by the firewall encryption policy, a tunnel may be initiated
automatically whenever a packet matching the policy arrives on the specified network
interface, destined for the local private network.
Create firewall policies based on traffic flow. For example, a policy for POP3, where the
email server is outside of the internal network, traffic should be from an internal interface
to an external interface rather than the other way around. It is typically the user on the
network requesting email content from the email server and thus the originator of the open
connection is on the internal port, not the external one of the email server. This is also
important to remember when view log messages as to where the source and destination
of the packets can seem backwards.
Policy order
Each time a FortiGate unit receives a connection attempting to pass through one of its
interfaces, the unit searches its firewall policy list for a matching firewall policy.
The search begins at the top of the policy list and progresses in order towards the bottom.
The FortiGate unit evaluates each policy in the firewall policy list for a match until a match
is found. When the FortiGate unit finds the first matching policy, it applies the matching
policy’s specified actions to the packet, and disregards subsequent firewall policies.
Matching firewall policies are determined by comparing the firewall policy and the
packet’s:
• source and destination interfaces
• source and destination firewall addresses
• services
• time/schedule.
If no policy matches, the connection is dropped.
As a general rule, you should order the firewall policy list from most specific to most
general because of the order in which policies are evaluated for a match, and because
only the first matching firewall policy is applied to a connection. Subsequent possible
matches are not considered or applied. Ordering policies from most specific to most
general prevents policies that match a wide range of traffic from superseding and
effectively masking policies that match exceptions.
Note: One slight variation on this is identity-based policies. For more information
see “Identity-based Policies” on page 240.
232 01-420-99686-20101026
Firewall Policies Policy order
For example, you might have a general policy that allows all connections from the internal
network to the Internet, but want to make an exception that blocks FTP. In this case, you
would add a policy that denies FTP connections above the general policy.
Figure 24: Example: Blocking FTP — Correct policy order
}Exception
}General
FTP connections would immediately match the deny policy, blocking the connection.
Other kinds of services do not match the FTP policy, and so policy evaluation would
continue until reaching the matching general policy. This policy order has the intended
effect. But if you reversed the order of the two policies, positioning the general policy
before the policy to block FTP, all connections, including FTP, would immediately match
the general policy, and the policy to block FTP would never be applied. This policy order
would not have the intended effect.
Figure 25: Example: Blocking FTP — Incorrect policy order
}General
}Exception
Similarly, if specific traffic requires authentication, IPSec VPN, or SSL VPN, you would
position those policies above other potential matches in the policy list. Otherwise, the
other matching policies would always take precedence, and the required authentication,
IPSec VPN, or SSL VPN might never occur.
Note: A default firewall policy may exist which accepts all connections. You can move,
disable or delete it. If you move the default policy to the bottom of the firewall policy list and
no other policy matches the packet, the connection will be accepted. If you disable or delete
the default policy and no other policy matches the packet, the connection will be dropped.
You can arrange the firewall policy list to influence the order in which policies are
evaluated for matches with incoming traffic. When more than one policy has been defined
for the same interface pair, the first matching firewall policy will be applied to the traffic
session.
Denial of Service policies

An exception to the above description is denial of service (DoS), also known as anomaly
thresholds, and sniffer firewall policies. These policies are created in a separate location in
the Firewall menu, and processed first before any other policy, yet in their own respective
order. This is done to determine early in the traffic processing if the traffic is valid traffic or
an unwanted attack, and therefore shutting it down before further processing of anti-spam
and anti-virus definitions. For more information on DoS policies, see “DoS Policies” on
page 238.
Rearranging policies
Moving a policy in the firewall policy list does not change its ID, which only indicates the
order in which the policy was created.
01-420-99686-20101026 233
Policy order Firewall Policies
To move a policy in the policy list

2 In the firewall policy list, note the ID of a firewall policy that is before or after your
intended destination.
3 Select the row corresponding to the firewall policy you want to move and select Move.
4 Select Before or After, and enter the ID of the firewall policy that is before or after your
intended destination. This specifies the policy’s new position in the firewall policy list.
5 Select OK.
Firewall policy 0
FortiGate units create a firewall policy of 0 (zero) which can appear in the logs, but will
never appear in the firewall policy list, and therefore can never be repositioned in the list.
When viewing the FortiGate logs, you may find an entry indicating policyid=”0”.
For example:
2008-10-06 00:13:49 log_id=0022013001 type=traffic
subtype=violation pri=warning vd=root SN=179089 duration=0
user=N/A group=N/A rule=0 policyid=0 proto=17 service=137/udp
app_type=N/A status=deny src=10.181.77.73 srcname=10.181.77.73
dst=10.128.1.161 dstname=10.128.1.161 src_int=N/A
dst_int="Internal" sent=0 rcvd=0 src_port=137 dst_port=137 vpn=N/A
tran_ip=0.0.0.0 tran_port=0
Any firewall policy that is automatically added by the FortiGate unit has a policy ID number
of 0. The most common reasons the FortiGate unit creates this policy is
• The IPsec policy for FortiAnalyzer (and FortiManager version 3.0) is automatically
added when an IPsec connection to the FortiAnalyzer unit or FortiManager is enabled.
• The policy to allow FortiGuard servers to be automatically added has a policy ID
number of 0.
• The (default) drop rule that is the last rule in the policy and that is automatically added
has a policy ID number of 0.
• When a network zone is defined within a VDOM, the intra-zone traffic set to allow or
block is managed by policy 0 if it is not processed by a configured firewall policy.
Firewall policy list details

The firewall policy table includes by default a number of columns to display information
about the policy, for example, source, destination, service, and so on. You can add a
number of additional columns to the table to view more information about the policies and
what is in their configuration. By going to Firewall > Policy > Policy and selecting the
Column Settings link, you can add or remove a number of different columns of information
to the policy list, and arrange their placement within the table.
234 01-420-99686-20101026
Firewall Policies Creating basic policies
Figure 26: Firewall policy column selection
Creating basic policies

This section describes how to configure basic firewall policies based on the selectable
actions described above. The following criteria will be used for each policy for
internal/source and external/destination information. Single addresses are used for
simplification.
Source interface/Zone Internal

Source address 10.13.20.22
Destination interface/Zone WAN1
Destination address 172.20.120.141
Using an interface of “any”

When adding a firewall policy with Source interface/zone or Destination interface/zone set
to ANY, that the firewall policy list can only be displayed in Global View. This is because a
firewall policy with an ANY interface potentially applies to all interfaces, however it does
not accurately reflect the actual firewall configuration if all of the ANY interface policies
appears in every section in Section View.
The actual affect to policy matching of a firewall policy with any as the source or
destination interface is only clear on the global policy list.
01-420-99686-20101026 235
Creating basic policies Firewall Policies
Basic accept policy example

With this basic accept policy example, the firewall policy will accept all HTTP traffic
passing from the external interface (WAN1) to the internal interface (Internal) at all times.
This enables users to surf the internet using HTTP (port 80). Using this policy alone, no
other traffic (email, FTP and so on) to pass through the FortiGate unit. The policy allows a
session to be created that traverses the FortiGate unit from WAN1 (the source) to Internal
(the destination). That is the direction data is moving when an internal user views a web
page, but the incoming page data first has to be requested, and that happens by opening
a session from Internal to WAN1 first.
To create a basic accept policy for HTTP - web-based manager

1 Go to Firewall > Policy > Policy and select Create New.
2 Enter the following and select OK:
Destination address ALL
Schedule always
Service HTTP
Action ALLOW
To create a basic accept policy for HTTP - CLI

edit 1
set srcintf internal
set scraddr 10.13.20.22
set dstintf wan1
set dstaddr all
set action accept
set schedule always
set service http
end
Basic deny policy example

With this basic deny policy example, the firewall policy will deny all FTP traffic passing
from the internal interface (Internal) to the external interface (WAN1) at all times. This
prevents users from uploading files to an FTP site. Ideally, this would not be the only policy
on the FortiGate unit.
To create a basic deny policy for FTP - web-based manager

Schedule always
236 01-420-99686-20101026
Firewall Policies Creating basic policies
Service FTP
Action DENY
To create a basic accept policy for FTP - CLI

edit 1
set srcaddr 10.13.20.22
set dstintf wan1
set dstaddr 172.20.120.141
set action deny
set schedule always
set service ftp
end
Basic VPN policy example

With this basic VPN policy example, the firewall policy will allow VPN traffic between the
FortiGate unit in the branch office and the head office. For simplicity, the VPN
configuration has been completed. The Phase 1 name is Head_Office. This firewall policy
would be configured on the Branch office FortiGate unit.
To create a basic VPN policy - web-based manager

Schedule always
Service any
Action IPSEC
VPN Tunnel Select Head_Office from the configured list of VPN tunnels.
To create a basic VPN tunnel - CLI

edit 1
set dstintf wan1
set dstaddr 172.20.120.141
set action allow
set schedule always
set service any
set vpntunnel Head_Office
end
01-420-99686-20101026 237
DoS Policies Firewall Policies
DoS Policies
Denial of Service (DoS) policies, also known as anomaly thresholds, are primarily used to
apply DoS sensors to network traffic based on the FortiGate interface it is entering as well
as the source and destination addresses. DoS sensors are a traffic anomaly detection
feature to identify network traffic that does not fit known or common traffic patterns and
behavior. A denial of service attack occurs when an attacking system starts an abnormally
large number of sessions with a target system. The large number of sessions slows down
or disables the target system so legitimate users can no longer use it.
DoS policies examine network traffic very early in the sequence of protective measures
the FortiGate unit deploys to protect your network. Because of this, DoS policies are a
very efficient defence, using few resources. The previously mentioned denial of service
would be detected and its packets dropped before requiring firewall policy look-ups,
antivirus scans, and other protective but resource-intensive operations.
You can create DoS sensors to protect against variety of different attack patterns. By
default, the FortiGate unit includes two sensors; one to pass all traffic and one to block the
more common DoS attack patterns. To create your own DoS sensor, go to UTM >
Intrusion Protection > DoS Sensor and select Create New.
For more information on DoS sensor configuration, see the UTM chapter.
DoS sensor policies are stored separately in the FortiGate web-based manager and do
not appear in the firewall policy list. As traffic passes through the FortiGate interface, the
DoS policy is applied first to determine whether the traffic is genuine or an attack. If it is
genuine, the packets are forwarded to the normal firewall policies and applied as required.
If the FortiGate unit determines the traffic is a DoS attack, the policy is applied as
configured in the DoS sensor.
Basic DoS policy example

This example demonstrates setting up a simple DoS policy using the default sensor
block_flood to monitor HTTP traffic the WAN1 port for any addresses through that port.
The block_flood sensor monitors for flood attacks.
To create the DoS firewall policy - web-based manager

1 Go to Firewall > Policy > DoS Policy and select Create New.
2 Set the Source Interface/Zone to WAN1.
3 Set the Source Address to All.
4 Set the Destination Address to All
5 Set the Service to HTTP.
6 Select the check box for DoS Sensor, and select block_flood from the list.
7 Select OK.
To create the DoS firewall policy - CLI

config firewall interface-policy
edit 1
set interface wan1
set srcaddr all
set dstaddr all
set service http
set ips-DoS-status enable
set ips-DoS block_flood
238 01-420-99686-20101026
Firewall Policies Sniffer Policies
end
Sniffer Policies
Sniffer policies are used to configure a physical interface on the FortiGate unit as a
one-arm intrusion detection system (IDS). Traffic sent to the interface is examined for
matches to the configured IPS sensor and application control list. Matches are logged and
then all received traffic is dropped. Sniffing only reports on attacks. It does not deny or
otherwise influence traffic.
Sniffer policies are applied to sniffer interfaces. Traffic entering a sniffer interface is
checked against the sniffer policies for matching source and destination addresses and for
service. This check against the policies occurs in listed order, from top to bottom. The first
sniffer policy matching all three attributes then examines the traffic. Once a policy matches
the attributes, checks for policy matches stop. If no sniffer policies match, the traffic is
dropped without being examined.
Once a policy match is detected, the matching policy compares the traffic to the contents
of the DoS sensor, IPS sensor, and application control list specified in the policy. If any
matches are detected, the FortiGate unit creates an entry in the log of the matching
sensor/list. If the same traffic matches multiple sensors/lists, it is logged for each match.
Before creating the sniffer policy, you must setup the FortiGate unit to the network and
configure a port as a dedicated sniffer port.The easiest way to do this is to either use a hub
or a switch with a SPAN port. A SPAN port is a special-purpose interface that mirrors all
the traffic the switch receives. Traffic is handled normally on every other switch interface,
but the SPAN port sends a copy of everything. If you connect your FortiGate unit sniffer
interface to the switch SPAN port, all the network traffic will be examined without any being
lost because of the examination.
The FortiGate interface needs to be enabled for sniffing. In the example below, the WAN1
port is configured for one-armed sniffing.
To configure a FortiGate interface as a one-arm sniffer - web-based manager

2 and select the WAN1 interface row and select Edit.
3 Select the check box for Enable one-arm sniffer.
4 Note that the port that is set up in sniffer mode will not require an IP address.
5 Select OK.
To configure a FortiGate interface as a one-arm sniffer - CLI

edit wan1
set ips-sniffer-mode enable
end
Basic one-armed sniffer policy example

This example demonstrates setting up a simple one-armed sniffer policy using the default
DoS sensor block_flood and IPS sensor protect_email_server to monitor SMTP traffic the
WAN1 port for any addresses through that port. Note that the WAN1 port was enabled in
the previous steps to be used as a sniffer port.
01-420-99686-20101026 239
Identity-based Policies Firewall Policies
To create the one-armed sniffer firewall policy - web-based manager

1 Go to Firewall > Policy > Sniffer Policy and select Create New.
2 Set the Source Interface/Zone to WAN1.
3 Set the Source Address to All.
4 Set the Destination Address to All
5 Set the Service to SMTP.
6 Select the check box for DoS Sensor, and select block_flood from the list.
7 Select the check box for IPS Sensor and select protect_email_server from the list.
8 Select OK.
To create the DoS firewall policy - CLI

edit 1
set interface wan1
set srcaddr all
set dstaddr all
set service smtp
set ips-sensor-status enable
set ips-sensor protect_email_server
set ips-DoS-status enable
set ips-DoS block_flood
end
Identity-based Policies
If you enable Enable Identity Based Policy in a firewall policy, network users must send
traffic involving a supported firewall authentication protocol to trigger the firewall
authentication challenge, and successfully authenticate, before the FortiGate unit will
allow any other traffic matching the firewall policy.
User authentication can occur through any of the following supported protocols:
• HTTP
• HTTPS
• FTP
• Telnet
Authentication can also occur through automatic login using NTLM and FSAE, to bypass
user intervention.
The authentication style depends on which of these supported protocols you have
included in the selected firewall services group and which of those enabled protocols the
network user applies to trigger the authentication challenge. The authentication style will
be one of two types. For certificate-based (HTTPS or HTTP redirected to HTTPS only)
authentication, you must install customized certificates on the FortiGate unit and on the
browsers of network users, which the FortiGate unit matches. For user name and
password-based (HTTP, FTP, and Telnet) authentication, the FortiGate unit prompts
network users to input their firewall user name and password.
240 01-420-99686-20101026
Firewall Policies Identity-based Policies
For example, if you want to require HTTPS certificate-based authentication before

allowing SMTP and POP3 traffic, you must select a firewall service (in the firewall policy)
that includes SMTP, POP3 and HTTPS services. Prior to using either POP3 or SMTP, the
network user would send traffic using the HTTPS service, which the FortiGate unit would
use to verify the network user’s certificate; upon successful certificate-based
authentication, the network user would then be able to access his or her email.
In most cases, you should ensure that users can use DNS through the FortiGate unit
without authentication. If DNS is not available, users will not be able to use a domain
name when using a supported authentication protocol to trigger the FortiGate unit’s
authentication challenge.
Note: If you do not install certificates on the network user’s web browser, the network users
may see an SSL certificate warning message and have to manually accept the default
FortiGate certificate, which the network users’ web browsers may then deem as invalid.
Note: When you use certificate authentication, if you do not specify any certificate when
you create a firewall policy, the FortiGate unit will use the default certificate from the global
settings. If you specify a certificate, the per-policy setting will override the global setting.
Authentication requires that Action is ACCEPT or SSL-VPN, and that you first create
users, assign them to a firewall user group, and assign UTM profiles to that user group.
Identity-based policy example

With this basic identity-based policy example, the firewall policy will allow HTTPS traffic
passing from the external interface (WAN1) to the internal interface (Internal) at all times,
as soon as the network user enters their username and password. For simplicity, the
policy will request the firewall authentication. This authentication can be set up for users
by going to User > Local and their groupings by going to User > Groups. For this example,
the group “accounting” is used. When a user attempts to browse to a secure site, they will
be prompted for their log in credentials.
To create a identity-based policy - web-based manager

2 Enter the following:
Schedule always
Action ACCEPT
3 Select Enable Identity Based Policy.

4 Firewall authentication is enabled by default.
5 Select Add.
6 From the Available User Groups list, select the Accounting user group and select the
right arrow to move it to the Selected User Groups area.
7 From the Available Services list, select the HTTPS and select the right arrow to move it
to the Selected Services area.
8 For the Schedule, select Always.
9 Select OK.
01-420-99686-20101026 241
Identity-based Policies Firewall Policies

edit 1
set dstintf wan1
set dstaddr 172.20.120.141
set action accept
set schedule always
set identity-based enable
config identity-based-policy
edit 1
set group accounting
set service HTTPS
set schedule always
end
end
Identity-based policy positioning

With identity-based firewall policies, positioning is extremely important. For a typical
firewall policy, the FortiGate unit matches the source, destination and service of the policy.
If matched, it acts on that policy. If not, the FortiGate unit moves to the next policy.
With identity-based policies, once the FortiGate unit matches the source and destination
addresses, it processes the identity sub-rules for the user groups and services. That is, it
acts on the authentication and completes the remainder of that policy and goes no further
in the policy list.
The way identity based policies work is that once src/dest are matched, it will process the
identity based sub-rules (for lack of a better term) around the user groups and services. It
will never process the rest of your rulebase. For this reason, unique firewall policies
should be placed before an identity-based policy.
For example, consider the following policies:
DNS traffic goes through successfully as does any HTTP traffic after being authenticated.
However, if there was FTP traffic, it would not get through. As the FortiGate unit processes
FTP traffic, it skips rule one since it’s matching the source, destination and service. When
it moves to rule two it matches the source and destination, it determines there is a match
and, sees there are also processes the group/service rules, which requires authentication
and acts on those rules. Once satisfied, the FortiGate unit will never go to rule three.
In this situation, where you would want FTP traffic to traverse the FortiGate unit, create a
firewall policy specific to the services you require and place it above the authentication
policy.
Identity-based sub-policies
When adding authentication to a firewall policy, you can add multiple authentication rules,
or sub-policies. Within these policies you can include additional UTM profiles, traffic
shaping and so on, to take affect on the selected services.
242 01-420-99686-20101026
Firewall Policies ICMP packet processing
Figure 27: Authentication sub-policies
These sub-policies work on the same principle as normal firewall policies, that is, top
down until the criteria has been met (see “Policy order” on page 232). As such, if there is
no matching policy within the list, the packet can still be dropped even after authentication
is successful.
ICMP packet processing

ICMP messages are used to relay feedback to the traffic source that the destination IP is
not reachable. ICMP message types are
• ICMP_ECHO
• ICMP_TIMESTAMP
• ICMP_INFO_REQUEST
• ICMP_ADDRESS
For ICMP error messages, only those reporting an error for an existing session can pass
through the firewall. The firewall policy will allow traffic to be routed, forwarded or denied.
If allowed, the ICMP packets will start a new session. Only ICMP error messages of a
corresponding firewall policy is available will be sent back to the source. Otherwise, the
packet is dropped. That is, only ICMP packets for a corresponding firewall policy can
traverse the FortiGate unit.
Common error messages include:
• destination unreachable messages
• time exceeded messages
• redirect messages
For example, a firewall policy that allows TFTP traffic through the FortiGate unit. User1
(192.168.21.12) attempts to connect to the TFTP server (10.11.100.1), however, the UDP
port 69 has not been opened on the server. The corresponding sniffer trace occurs:
diagnose sniffer packet any “host 10.11.100.1 or icmp 4”
3.677808 internal in 192.168.21.12.1262 -> 10.11.100.1.69: udp 20
3.677960 wan1 out 192.168.21.12.1262 -> 10.11.100.1.69: udp 20
3.678465 wan1 in 10.11.100.1.132 -> 192.168.21.12: icmp: 10.11.100.1
udp port 69 unreachable
3.678519 internal out 10.11.100.1 -> 192.168.21.12: icmp:
192.168.182.132 udp port 69 unreachable
01-420-99686-20101026 243
Firewall policy examples Firewall Policies
Firewall policy examples

This section provides some simple, real-world, examples of firewall policies you can use
as a starting point when creating policies for your network.
Blocking an IP address
This example describes how to create a firewall policy to block a specific IP address. Any
traffic from the configured IP address will be dropped at the point of hitting the FortiGate
unit. To block an IP address, you need to create an address entry before creating a firewall
policy to block the address.
Add an Address
First create the address which the FortiGate will identify to be blocked. In this example, the
address will be 172.20.120.29 for the address name of Blocked_IP.
To add an address entry - web-based manager

2 Enter a Name of Blocked_IP.
3 Enter the IP address and subnet of 172.20.120.29/255.255.255.255.
The subnet is set to 255.255.255.255 to block the specific address. If you wanted to
block the entire subnet enter 172.20.120.0/255.255.255.0.
To add an address entry - web-based CLI

edit Blocked_IP
set subnet 172.20.120.29/32
end
Add a Firewall Policy

With the address added, you can now create the DENY firewall policy which will prevent
any traffic from this IP address from traversing the network. In this policy, the traffic will be
restricted from the IP of an outside source through the external interface, WAN1.
To add a firewall policy - web-based manager

2 Complete the following and select OK:
Source Interface/Zone WAN1
Source Address Blocked_IP
Destination Interface/Zone Internal
Destination Address All
Schedule Always
Service ALL
Action DENY
3 Move the firewall policy to the top of the policy list.
To add a firewall policy - web-based CLI

config firewall poliy
edit 1
244 01-420-99686-20101026
Firewall Policies Firewall policy examples
set srcintf wan1

set srcaddr Blocked_IP
set dstintf Internal
set dstaddr all
set action deny
set schedule always
set service any
end
Scheduled access policies

Firewall schedules control when policies are in effect, that is, when they are on. You can
create one-time schedules which are schedules that are in effect only once for the period
of time specified in the schedule. You can also create recurring schedules that are in effect
repeatedly at specified times of specified days of the week. For more information on
schedules, see “Services” on page 226.
This example describes firewall policy rules that:
• On weekdays, allow all users to fully access the Internet during lunchtime and after
business hours
• Allow full access to the Internet without any restriction for users from a specific IP
range, called Admin_PCs
• During business hours, allow only access to www.example.com and
www.example2.com for the other users
• No restriction during the weekend
It should be noted that a Firewall Policy is inactive outside of its schedule and that the
schedule relies upon the date/time that is configured on the FortiGate unit.
In this example all users are connected to the Internal interface and that the Internet
access is connected to WAN1.
Configuring the schedules

Begin by adding the schedule time when the firewall policies take affect.
Note: If the stop time is set earlier than the start time, the stop time will be
considered as the next day. If the start time is equal to the stop time, the schedule
will run for 24 hours.
To configure schedules - web-based manager

1 Go to Firewall > Schedule > Recurring, and select Create New.
2 Enter the schedule Name of week-end.
3 Select the days of the week this schedule is employed. In this case, Saturday and
Sunday.
4 Select OK.
5 Select Create New
6 Enter the schedule Name of lunch-time.
7 Select the days of the week this schedule is employed. In this case, Monday through
Friday.
01-420-99686-20101026 245
10 Select OK.
11 Select Create New
12 Enter the schedule Name of late evening early morning.
13 Select the days of the week this schedule is employed. In this case, Monday through
Friday.
16 Select OK.
To configure schedules - web-based manager

edit week-end
set day sunday saturday
next
edit lunch-time
set end 14:00
set start 12:00
next
edit late evening to early morning
set end 08:00
set start 18:00
next
end
Configuring the IP addresses

Configure the addresses for the administrator computers and the web sites that can be
accessible during the scheduled times.
To configure addresses and web sites - web-based manager

2 Enter a Name of Admin_PCs.
3 Enter the Subnet/IP Range of 192.168.1.200-192.168.1.254.
4 Select OK.
6 Enter the Name of example.com
7 Select the Type of FQDN.
8 Enter the FQDN of www.example.com.
9 Select OK.
11 Enter the Name example2.com
12 Select the Type of FQDN.
13 Enter the FQDN of www.example2.com.
14 Select OK.
246 01-420-99686-20101026
To configure addresses and web sites - CLI

edit Admin_PCs
set type iprange
set end-ip 192.168.1.254
set start-ip 192.168.1.200
next
edit example.com
set type fqdn
set fqdn www.example.com
next
edit example2.xom
set type fqdn
set fqdn www.example2.com
next
end
Configuring the firewall policies

With the key components, the schedules and addresses, create the firewall policies to
employ these components and set the schedules to drive what users can view during the
day. There are a total of five required for this example.
To create the firewall policies - web-based manager

2 Complete the following for the weekend access policy and select OK:
Source Interface/Zone Internal

Source Address All
Destination Interface/Zone WAN1
Schedule week-end
Service ALL
Action Accept
NAT Select to Enable.
Comments Week-end policy.

4 Complete the following for the administrator access policy and select OK:

Source Address Admin_PCs
Schedule Always
Service ALL
Action Accept
Comments Admin PCs no restriction.
01-420-99686-20101026 247

6 Complete the following for the lunch-time surfing policy and select OK
:

Source Address All
Schedule lunch-time
Service ALL
Action Accept
Comments Lunch-time policy.

8 Complete the following for the overnight policy and select OK
:

Source Address All
Schedule late_eveing_early_morning
Service ALL
Action Accept
Comments Late evening to early morning policy.

10 Complete the following for the web site access policy and select OK
:

Source Address All
Destination Interface/Zone example.com and example2.com
Schedule Always
Service ALL
Action Accept
Comments Access to the example.com websites policy.
To create the firewall policies - CLI

edit 1
set dstintf wan1
set srcaddr all
set dstaddr all
set action accept
set comments week-end policy
248 01-420-99686-20101026
set schedule week-end

set service ANY
set nat enable
next
edit 2
set dstintf wan1
set srcaddr Admin_PCs
set dstaddr all
set action accept
set comments Admin PCs no restriction
set schedule always
set service ANY
set nat enable
next
edit 3
set dstintf wan1
set srcaddr all
set dstaddr all
set action accept
set comments lunch time policy
set schedule lunch-time
set service ANY
set nat enable
next
edit 4
set dstintf wan1
set srcaddr all
set dstaddr all
set action accept
set comments “late evening to early morning policy”
set schedule “late evening to early morning”
set service ANY
set nat enable
next
edit 5
set dstintf wan1
set srcaddr all
set dstaddr example.com example2.com
set action accept
set schedule always
set service ANY
set nat enable
next
end
01-420-99686-20101026 249
250 01-420-99686-20101026
Troubleshooting
When the firewall policies are in place and traffic is not flowing, or flowing more than it
should, there may be an issue with the one or more firewall policies. This chapter outlines
some troubleshooting tips and steps to diagnose where the traffic is not getting through, or
letting too much traffic through.
This chapter includes the topics:
• Basic policy checking
• Verifying traffic
• Using log messages to view violation traffic
• Traffic trace
• Packet sniffer
Basic policy checking

Before going into a deep troubleshooting session, first verify a few simple settings in the
firewall policy configuration to ensure everything is setup correctly.
For example:
• Verify the policy position. The FortiGate unit evaluates each policy in the firewall policy
list for a match until a match is found. When the FortiGate unit finds the first matching
policy, it applies the matching policy’s specified actions to the packet, and disregards
subsequent firewall policies. Is the order of the policies affecting traffic flow? For more
information see “Policy order” on page 232.
• Verify that the source and destination ports and their addresses (IP Pools and virtual
IPs) are selected correctly for the correct subdomain.
• Ensure that the NAT check box is selected in the policy. If you selected a virtual IP as
the destination address, but did not select the NAT option, the FortiGate unit performs
destination NAT rather than full NAT.
• Verify that the UTM profiles you selected are properly configured, and that any URLs or
IP addresses are entered correctly.
• Verify that the policy is enabled. In the firewall policy list (Firewall > Policy > Policy), the
Status column indicates whether a firewall policy is enabled or not. To be enabled, the
check box must be selected.
Verifying traffic
With many firewall policies in place, you may want to verify that traffic is being affected by
the policy. There is a simple way to get a quick visual confirmation within the web-based
manager. This is done by adding a counter column to the firewall policy table. These steps
are only available in the web-based manager.
01-420-99686-20101026 251
Using log messages to view violation traffic Troubleshooting
To view the traffic count on firewall policies

2 Select Column Settings in the upper right of the window.
3 From Available fields list, select Count.
4 Select the right-facing arrow to add it to the Show these fields column.
5 Select OK.
As packets hit this policy, the count will appear in the column in kilobytes.
Note: For accelerated traffic, NP2 ports the count does not reflect the real traffic count.
Only the start of a session packet will be counted. For non-accelerated traffic, all packets
are counted.
Using log messages to view violation traffic

Firewall policies are instructions the FortiGate unit uses to decide connection acceptance
and packet processing for traffic attempting to pass through. When the firewall receives a
connection packet, it analyzes the packet’s source address, destination address, and
service (by port number), and attempts to locate a firewall policy matching the packet. If no
Firewall Policy is matching the traffic, the packets are dropped. Because of this, you do not
need to configure a DENY Firewall Policy in the last position to block the unauthorized
traffic.
However, you may want to see what type of traffic is attempting to access the network. By
adding a DENY firewall policy, you can log the dropped traffic for analysis. Note that
storing and viewing the log for denied traffic requires a FortiAnalyzer, or a Syslog server,
or a FortiGate unit with a local hard disk.
To configure logging denied traffic you need to crate the DENY firewall policy and enable
logging. In this example, the firewall policy will deny all HTTP traffic passing from the
internal interface (Internal) to the external interface (WAN1) at all times.
To configure the logging of violation traffic - web-based manager


Schedule always
Service HTTP
Action DENY
3 Select Log Violation Traffic.

4 Select OK.
252 01-420-99686-20101026
Troubleshooting Traffic trace

edit 1
set dstintf wan1
set dstaddr 172.20.120.141
set action deny
set schedule always
set service http
set logtraffic enable
end
The following is a sample syslog message from a logged traffic violation.
Warning 10.160.0.110 date=2009-09-14 time=10:16:25
devname=FG300A3906550380 device_id=FG300A3906550380 log_id=0022000003
type=traffic subtype=violation pri=warning fwver=040000 status=deny
vd="root" src=10.160.1.10 srcname=10.160.1.10 src_port=0 dst=4.2.2.1
dstname=10.2.2.1 dst_port=0 service=8/icmp proto=1 app_type=N/A
duration=0 rule=3 policyid=1 sent=0 rcvd=0 vpn="N/A" src_int="port2"
dst_int="port1" SN=12215 user="N/A" group="N/A" carrier_ep="N/A"
Traffic trace
Traffic tracing enables you to follow a specific packet stream. View the characteristics of a
traffic session though specific firewall policies using the CLI command diagnose
system session, trace per-packet operations for flow tracing using diagnose debug
flow and trace per-Ethernet frame using diagnose sniffer packet.
Session table
The FortiGate session table can be viewed from the web-based manager or the CLI. The
most useful troubleshooting data comes from the CLI. The session table in web-based
manager also provides some useful summary information, particularly the current policy
number that the session is using.
Sessions only are appear if a session was established. If a packet is dropped, then no
session will appear in the table. Using the CLI command diagnose debug flow can be
used to identify why the packet was dropped.
To view the session table in the web-based manager

2 Select Add Content > Top Sessions.
3 In the Top Sessions pane, select Details.
The Policy ID displays which firewall policy matches the session. The sessions that do not
have a Policy ID entry originate from the FortiGate unit.
To view the session table in the CLI

diagnose sys session list
The session table output using the CLI is very verbose. You can use filters to display only
the session data of interest. An entry is placed in the session table for each traffic session
passing through a firewall policy.
01-420-99686-20101026 253
Traffic trace Troubleshooting
Sample output
session info: proto=6 proto_state=05 expire=89 timeout=3600
flags=00000000 av_idx=0 use=3
bandwidth=204800/sec guaranteed_bandwidth=102400/sec
traffic=332/sec prio=0 logtype=session ha_id=0 hakey=4450
tunnel=/
state=log shape may_dirty
statistic(bytes/packets/err): org=3408/38/0 reply=3888/31/0
tuples=2
orgin->sink: org pre->post, reply pre->post oif=3/5
gwy=192.168.11.254/10.0.5.100
hook=post dir=org act=snat 10.0.5.100:1251-
>192.168.11.254:22(192.168.11.105:1251)
hook=pre dir=reply act=dnat 192.168.11.254:22-
>192.168.11.105:1251(10.0.5.100:1251)
pos/(before,after) 0/(0,0), 0/(0,0)
misc=0 domain_info=0 auth_info=0 ftgd_info=0 ids=0x0 vd=0
serial=00007c33 tos=ff/ff
Filter options enable you to view specific information from this command:
diagnose sys session filter <option>
The <option> values available include the following:
clear clear session filter
dport dest port
dst destination IP address
negate inverse filter
policy policy ID
proto protocol number
sport source port
src source IP address
vd index of virtual domain. -1 matches all
Even though UDP is a sessionless protocol, the FortiGate unit still keeps track of the
following two different states:
• UDP reply not seen with a value of 0
• UDP reply seen with a value of 1
The table below shows the firewall session states from the session table:
State Meaning
log Session is being logged.
local Session is originated from or destined for local stack.
ext Session is created by a firewall session helper.
may_dirty Session is created by a policy. For example, the session for ftp control
channel will have this state but ftp data channel will not. This is also seen
when NAT is enabled.
ndr Session will be checked by IPS signature.
nds Session will be checked by IPS anomaly.
br Session is being bridged (TP) mode.
254 01-420-99686-20101026
Finding object dependencies

An administrator may not be permitted to delete a configuration object if there are other
configuration objects that depend on it. For example, you may not be able to delete a user
group because that user group is connected with a firewall policy. This command identifies
other objects which depend on or make reference to the configuration object in question. If
a message appears that an object is in use and cannot be deleted, this command can help
identify where this is occurring.
When running multiple VDOMs, this command is run in the Global configuration only and it
searches for the named object both in the Global and VDOM configuration most recently
used:
diagnose sys checkused <path.object.mkey>
For example, to verify which objects are referred to in a firewall policy with an ID of 1, enter
the command:
diagnose sys checkused firewall.policy.policyid 1
To verify what is referred to by port1 interface, enter the command:
diagnose sys checkused system.interface.name port1
To show all the dependencies for the WAN1 interface, enter the command:
diag sys checkused system.interface.name wan1
Sample output
entry used by table firewall.address:name '10.98.23.23_host’
entry used by table firewall.address:name 'NAS'
entry used by table firewall.address:name 'all'
entry used by table firewall.address:name 'fortinet.com'
entry used by table firewall.vip:name 'TORRENT_10.0.0.70:6883'
entry used by table firewall.policy:policyid '21'
In this example, the interface has dependent objects, including four address objects, one
VIP, and three firewall policies.
Flow trace
To trace the flow of packets through the FortiGate unit, use the command
diagnose debug flow trace start
Follow the packet flow by setting a flow filter using the command:
diagnose debug flow filter <option>
Filtering options include:
addr IP address
clear clear filter
daddr destination IP address
dport destination port
port port
saddr source IP address
01-420-99686-20101026 255
Traffic trace Troubleshooting
sport source port

vd index of virtual domain, -1 matches all
Enable the output to in the console:
diagnose debug flow show console enable
Start flow monitoring with a specific number of packets using the command:
diagnose debug flow trace start <N>
Stop flow tracing at any time using:
diagnose debug flow trace stop
Sample output
This an example shows the flow trace for the device at the IP address 203.160.224.97.
diag debug enable
diag debug flow filter addr 203.160.224.97
diag debug flow show console enable
diag debug flow show function-name enable
diag debug flow trace start 100
Flow trace output example - HTTP

Connect to the web site at the following address to observe the debug flow trace. The
display may vary slightly:
http://www.fortinet.com
Comment: SYN packet received:
id=20085 trace_id=209 func=resolve_ip_tuple_fast
line=2700 msg="vd-root received a packet(proto=6,
192.168.3.221:1487->203.160.224.97:80) from port5."
SYN sent and a new session is allocated:
id=20085 trace_id=209 func=resolve_ip_tuple line=2799
msg="allocate a new session-00000e90"
Lookup for next-hop gateway address:
id=20085 trace_id=209 func=vf_ip4_route_input line=1543
msg="find a route: gw-192.168.11.254 via port6"
Source NAT, lookup next available port:
id=20085 trace_id=209 func=get_new_addr line=1219
msg="find SNAT: IP-192.168.11.59, port-31925"
direction“
Matched firewall policy. Check to see which policy this session matches:
id=20085 trace_id=209 func=fw_forward_handler line=317
msg="Allowed by Policy-3: SNAT"
Apply source NAT:
id=20085 trace_id=209 func=__ip_session_run_tuple
line=1502 msg="SNAT 192.168.3.221->192.168.11.59:31925"
SYN ACK received:
id=20085 trace_id=210 func=resolve_ip_tuple_fast line=2700
msg="vd-root received a packet(proto=6, 203.160.224.97:80-
>192.168.11.59:31925) from port6."
256 01-420-99686-20101026
Found existing session ID. Identified as the reply direction:

msg="Find an existing session, id-00000e90, reply
direction"
Apply destination NAT to inverse source NAT action:
line=1516 msg="DNAT 192.168.11.59:31925-
>192.168.3.221:1487"
Lookup for next-hop gateway address for reply traffic:
ACK received:
msg="vd-root received a packet(proto=6,
192.168.3.221:1487->203.160.224.97:80) from port5."
Match existing session in the original direction:
msg="Find an existing session, id-00000e90, original
direction"
Apply source NAT:
line=1502 msg="SNAT 192.168.3.221->192.168.11.59:31925"
Receive data from client:
192.168.3.221:1487->203.160.224.97:80) from port5."
line=2727 msg="Find an existing session, id-00000e90,
original direction"
Apply source NAT:
line=1502 msg="SNAT 192.168.3.221->192.168.11.59:31925"
Receive data from server:
203.160.224.97:80->192.168.11.59:31925) from port6."
Match existing session in reply direction:
reply direction"
line=1516 msg="DNAT 192.168.11.59:31925-
>192.168.3.221:1487"
01-420-99686-20101026 257
Packet sniffer Troubleshooting
Packet sniffer
The packet sniffer in the FortiGate unit can sniff traffic on a specific Interface or on all
Interfaces. There are 3 different Level of Information, a.k.a. Verbose Levels 1 to 3, where
verbose 1 shows less information and verbose 3 shows the most information.
Verbose levels in detail:
• 1Print header of packets
• 2Print header and data from the IP header of the packets
• 3Print header and data from the Ethernet header of the packets
• 4Print header of packets with interface name
• 5Print header and data from IP of packets with interface name
• 6Print header and data from ethernet of packets with interface
All Packet sniffing commands are in the format:
diagnose sniffer packet <interface> <'filter'> <verbose> <count>
... where...
<interface> can be an Interface name or “any” for all Interfaces. An interface can be
physical, VLAN, IPsec interface, Link aggregated or redundant.
<verbose> the level of verbosity as described above.
<count> the number of packets the sniffer reads before stopping.
<'filter'> is a very powerful filter functionality which will be described below.
Simple trace example

In this example, the packet sniffer sniffs three packets of all traffic with verbose level 1 on
internal interface
diagnose sniffer packet internal “none” 1 3
The none variable means no filter applies, 1 means verbose level 1 and 3 means catch 3
packets and stop. The resulting output is
192.168.0.1.22 -> 192.168.0.30.1144: psh 2859918764 ack
1949135261?192.168.0.1.22 -> 192.168.0.30.1144: psh 2859918816 ack
1949135261?192.168.0.30.1144 -> 192.168.0.1.22: ack 2859918884
The sniffer has caught some packets in the middle of a communication. Because the
192.168.0.1 IP address uses port 22 (192.168.0.1.22) this particular sniff is from a SSH
Session.
Simple trace example

In this example, the packet sniffer sniff 3 packets of all traffic with verbose 1evel 1 on
internal interface
The none variable means no filter applies, 1 means verbose level 1 and 3 means catch 3
packets and stop. The resulting output is
192.168.0.30.1156 -> 192.168.0.1.80: syn 2164883624
192.168.0.1.80 -> 192.168.0.30.1156: syn 3792179542 ack 2164883625
192.168.0.30.1156 -> 192.168.0.1.80: ack 3792179543
In this example, the sniffer captures a TCP session being set up. 192.168.0.30 is
attempting to connect to 192.168.0.1 on Port 80 with a SYN and gets a SYN ACK
returned. The session is acknowledged and established after the 3-way TCP handshake.
258 01-420-99686-20101026
Troubleshooting Packet sniffer
With information level set to verbose 1, the source and destination IP address is visible, as
well as source and destination port. The corresponding Sequence numbers is also visible.
Note: If you do not enter a <count> value, for example as above, 3, the sniffer will
continue to run until you stop it.
Verbose levels 2 and 3

Verbose level 2 contains much more information; the IP header as with verbose level 1
and the payload of the IP packet itself.
The output of verbose 2 is:
192.168.0.1.22 -> 192.168.0.30.1144: psh 2867817048 ack 1951061933
0x0000 4510 005c 8eb1 4000 4006 2a6b c0a8 0001 E..\..@.@.*k....
0x0010 c0a8 001e 0016 0478 aaef 6a58 744a d7ad .......x..jXtJ..
0x0020 5018 0b5c 8ab9 0000 9819 880b f465 62a8 P..\.........eb.
0x0030 3eaf 3804 3fee 2555 8deb 24da dd0d c684 >.8.
.%U..$.....
0x0040 08a9 7907 202d 5898 a85c facb 8c0a f9e5 ..y..-X..\......
0x0050 bd9c b649 5318 7fc5 c415 5a59 ...IS.....ZY
Verbose level 3 includes the previous information as well as Ethernet (Ether Frame)
information. This is the format that technical support will usually request when attempting
to analyze a problem.
A script is available on the Fortinet Knowledge Base (fgt2eth.pl), which will convert a
captured verbose 3 output, into a file that can be read and decoded by Ethereal.
Trace with filters example

In this example, use the filter option of the sniffer to see the traffic information between two
PCs or a PC and a FortiGate unit. Using the following command:
diagnose sniffer packet internal 'src host 192.168.0.130 and dst
host 192.168.0.1' 1
The resulting output is:
192.168.0.130.3426 -> 192.168.0.1.80: syn 1325244087
192.168.0.1.80 -> 192.168.0.130.3426: syn 3483111189 ack
1325244088?192.168.0.130.3426 -> 192.168.0.1.80: ack 3483111190
192.168.0.130.3426 -> 192.168.0.1.80: psh 1325244088 ack 3483111190
192.168.0.1.80 -> 192.168.0.130.3426: ack 1325244686
192.168.0.130.1035 -> 192.168.0.1.53: udp 26
192.168.0.130.1035 -> 192.168.0.1.53: udp 42?192.168.0.130.1035 ->
192.168.0.1.53: udp 42
192.168.0.130 -> 192.168.0.1: icmp: echo request?192.168.0.130.3426 ->
192.168.0.1.80: psh 1325244686 ack 3483111190
192.168.0.1.80 ->
192.168.0.130.3426: ack 1325244735?192.168.0.130 -> 192.168.0.1: icmp:
echo request
Assuming there is a lot of traffic, this filter command will only display traffic (but all traffic)
from the source IP 192.168.0.130 to the destination IP 192.168.0.1. It will not show traffic
to 192.168.0.130 (for example the ICMP reply) because the command included:
'src host 192.168.0.130 and dst host 192.168.0.1'
Additional information such as ICMP or DNS queries from a PC are included. If you only
require a specific type of traffic, for example, TCP traffic only, you need to change the filter
command as below:
01-420-99686-20101026 259
Packet sniffer Troubleshooting
diagnose sniffer packet internal 'src host 192.168.0.130 and dst host
192.168.0.1 and tcp' 1?
The resulting output would be:
192.168.0.130.3569 -> 192.168.0.1.23: syn 1802541497
192.168.0.1.23 -> 192.168.0.130.3569: syn 4238146022 ack 1802541498
192.168.0.130.3569 -> 192.168.0.1.23: ack 4238146023
Though ICMP (ping) was also running, the trace only shows the TCP part. The destination
IP is 192.168.0.1.23, which is IP 192.168.0.1 on port 23 - a Telnet session.
260 01-420-99686-20101026
Configuration Examples
This section describes small parcels of configurations on the FortiGate unit. The
configurations involve practical setups of various features within FortiOS that you can use
to apply to your network.
This chapter is also dynamic, in that it will continue to evolve and grow as configurations
are considered, tested and added.
The examples in this section include
• Exempted URLs
Exempted URLs
With FortiGuard categories, you only need to select the particular categories you wish to
block. However, within those categories, there may be specific sites you still need or want
to access, or certain sites include sub-sites which cause blocks where you don’t need
them. For example, a particular web site may have advertising on it, and you have
enabled blocking of web ads. As such, the web site you want to visit is blocked.
By adding exempted URLs, you can include the site you want to visit to allow it to be
viewed. This is done through the use of local categories and local ratings. This example
describes the steps to create local ratings and local categories.
This configuration involves three steps:
• Create a local category
• Add the URLs to the category
• Enable and set the option for the category in the web filter profile.
Create a local category

First, you need to create a local category. This will be the grouping of URLs that will be
exempted from being blocked by FortiGuard. For this example, add a local category called
“exemptions”.
To create a local category - web-based manager

1 Go to UTM > Web Filter > Local Categories.
2 Enter the category name of Exemptions and select Create New.
To create a local category - CLI

config webfilter ftgd-local-cat
edit exemptions
end
Add URLs to the category

Next, add the URLs that will be included in the new local category called exemptions.
To add web filter URLs for the local category - web-based manager
1 Go to UTM > Web Filter > Local Ratings.
01-420-99686-20101026 261
Exempted URLs Configuration Examples

3 Enter the URL, for example www.fortinet.com.
4 In the Local Categories list, select the blue arrow to expand the list.
5 Select the check box for the category Exemptions.
6 Select OK.
Repeat for each URL you want to include.
To add web filter URLs for the local category - CLI

config webfilter ftgd-local-rating
edit www.fortinet.com
set rating 140
end
Enable the category in web filtering

Note that for the rating, it is a value associated with the FortiGuard filters and categories.
You will need to scroll through the list until you find your custom local category.
With the category and ratings in place, you need to enable the category in the web filter
profile.
To enable the category in the web profile - web-based manager

1 Go to UTM > Profile.
2 Select Create New, or double-click an existing profile.
3 Select the blue arrow for FortiGuard Web Filtering to expand the options.
4 A new option appears in the list called Local Categories. Select the blue arrow to
expand the options.
5 Select the check box next to the newly created category, Exemptions.
6 Select OK.
To enable the category in the web profile - CLI

edit <profile_name>
config ftgd-wf
set enable 140
end
end
Test it
Go to the web site that before was blocked. It will now be available, while others within the
FortiGuard category are not.
262 01-420-99686-20101026
Concept Example: Small Office
Network Protection
This document describes an example network and firewall configuration for a
small office-home office (SOHO) or a small- to medium-sized business (SMB).
SOHO and SMB networks, in this case, refer to
• small offices
• home offices
• broadband telecommuter sites or large remote access populations
• branch offices (small- to medium-sized)
• retail stores
Note: IP addresses and domain names used in this document are examples and are not valid
outside of this example.
This document includes

• Example small office network
• First steps
• Configuring settings for Finance and Engineering departments
• Configuring settings for the Help Desk department
• Configuring remote access VPN tunnels
• Configuring the web server
• Configuring the email server
• ISP web site and email hosting
• Other features and products for SOHO
Example small office network

The Example Corporation is a small software company performing development and
providing customer support. In addition to their internal network of 15 computers, they also
have several employees that work from home all or some of the time.
The Example Corporation requires secure connections for home-based workers. Like
many companies, they rely heavily on email and Internet access to conduct business.
They want a comprehensive security solution to detect and prevent network attacks, block
viruses, and decrease spam. They want to apply different protection settings for different
departments. They also want to integrate web and email servers into the security solution.
The Example Corporation network provides limited functionality for their needs, including:
• a very basic router to manage the network traffic
• an email server hosted by the Internet Service Provider (ISP)
• a web server hosted by the ISP
01-420-99686-20101026 263
Example small office network Concept Example: Small Office Network Protection
• client-based antivirus software with no reliable central distribution of updates

• no secure method of providing remote connections for home-based workers
Network management and protection requirements

The Example Corporation established several goals for planning a network security
solution. Table 10 describes the company’s goals and the FortiGate options that meet
them.
Table 10: Company security goals and FortiGate solutions
Security Policy/Goal FortiGate solution

Protect the internal network from attacks, Enable IPS, antivirus, and spam filters.
intrusions, viruses, and spam.
Automate network protection as much as There are several features to make maintenance
possible to make management simpler simpler:
• enable automatic daily updates of antivirus and
attack definitions
• enable automatic “push” updates so that Fortinet
updates the virus list when new threats occur
• enable FortiGuard web filtering so that web requests
are automatically filtered based on configured
policies, with no required maintenance
• enable FortiGuard Antispam, an IP address black list
and spam filter service that keeps track of known or
suspected spammers, to automatically block spam
with no required maintenance
Provide secure access for remote Configure secure IPSec VPN tunnels for remote access
workers with static or dynamic IP employees. Use Dynamic Domain Name Server
addresses. Use a secure VPN client (DDNS) VPN for users with dynamic IP addresses. Use
solution. the FortiClient software to establish a secure connection
between the FortiGate unit and the home-based worker.
See “Configuring remote access VPN tunnels” on
page 284.
Serve the web site and email from a DMZ Place the web and email servers on the DMZ network
to further protect internal data. and create appropriate policies.
See “Configuring the web server” on page 289.
Block access by all employees to Enable FortiGuard web content filtering solution.
potentially offensive web content. See “Configuring web category block settings” on
page 273.
Severely limit web access for certain Create a schedule that covers business hours, create a
employees (help desk) during work custom web access solution, and include these in a
hours. firewall policy for specific addresses.
See “Configuring settings for the Help Desk
department” on page 277.
Topology
Figure 28 shows the The Example Corporation network configuration after installation of
the FortiGate-100A.
264 01-420-99686-20101026
Concept Example: Small Office Network Protection Example small office network
Figure 28: SOHO network topology with FortiGate-100A
VPN nel
Tun Tun
21 2
90 1
VPN
2
n
8. er
2
8. er
.1
el
.1
16 Us
16 Us
2. e
2. e
19 om
19 om
H
H 17 Exte
2.2 rn
0.1 al
20
.14
1
D
al 1 0 MZ
ern .1 .20
Int 1.10 .10
.1
.1
10
F 1 1.
in 1 1
10 0.1
an .1 01
.
ce 01 .2
1
U 10
se -
. 0
rs
.3 r
10 ve
0. er
.2 S
10 eb
W
.2 er
E 10 .11
ng .1 .
H 0. .11
10 rv
el 11 .1
0. e
in 1. 10
.2 il S
p .1 0
1 0
ee 10 1.
D 0 1.
10
10 ma
rin 1. 10
es 1 5
1
g 51 0
k .21 0
E
U -
U -
se
se
rs
rs
Features used in this example

The following table lists the FortiGate features implemented in the Example Corporation
example network.
01-420-99686-20101026 265
First steps Concept Example: Small Office Network Protection
System • “Configuring FortiGate network interfaces” on page 266

• “Configuring DNS forwarding” on page 268
• “Scheduling automatic antivirus and attack definition updates” on page 270
• “Setting the time and date” on page 269
• “Configuring administrative access and passwords” on page 270
• “Registering the FortiGate unit” on page 269
Router • “Adding the default route” on page 267
Firewall • “Removing the default firewall policy” on page 268
• Adding firewall policies for different addresses and address groups, see
“Configuring firewall policies for Finance and Engineering” on page 276,
“Configuring firewall policies for help desk” on page 282, and “Configuring
firewall policies for the VPN tunnels” on page 287
• Adding addresses and address groups, see “Adding the Finance and
Engineering department addresses” on page 272, “Adding the Help Desk
department address” on page 278, “Adding addresses for home-based
workers” on page 284, “Adding the web server address” on page 290, and
“Adding the email server address” on page 294
• “Creating a recurring schedule” on page 282
VPN • “Configuring remote access VPN tunnels” on page 284 (IPSec)
IPS • “Scheduling automatic antivirus and attack definition updates” on page 270
Antivirus • “Configuring antivirus grayware settings” on page 274
• enabling virus scanning (see Configuring protection profiles)
• “Scheduling automatic antivirus and attack definition updates” on page 270
Web Filter • “Configuring web category block settings” on page 273 (FortiGuard)
• “Creating and Configuring URL filters” on page 278
Spam Filter • “Configuring FortiGuard spam filter settings” on page 273
First steps
First steps includes creating a network plan and configuring the basic FortiGate settings.
• Configuring FortiGate network interfaces
• Adding the default route
• Removing the default firewall policy
• Configuring DNS forwarding
• Setting the time and date
• Registering the FortiGate unit
• Scheduling automatic antivirus and attack definition updates
• Configuring administrative access and passwords
Configuring FortiGate network interfaces

The Example Corporation assigns IP addresses to the three FortiGate interfaces to
identify them on their respective networks. It is important to limit administrative access to
maintain security. The Example Corporation configures administrative access for each
interface as follows:
Interface Administrative access

internal HTTPS for web-based manager access from the internal network, PING for
connectivity troubleshooting, and SSH for secure access to the command line
interface (CLI) from the internal network.
266 01-420-99686-20101026
Concept Example: Small Office Network Protection First steps
wan1 HTTPS for remote access to the web-based manager from the Internet.
dmz1 PING access for troubleshooting.
To configure FortiGate network interfaces - web-based manager

2 Select the Internal interface row and select Edit:
Addressing mode Manual

IP/Netmask 10.11.101.1/255.255.255.0
Administrative access HTTPS, PING, SSH
3 Select OK.
4 Select the wan1 interface row and select Edit:

IP/Netmask 172.20.120.141/255.255.255.0
Administrative access HTTPS
5 Select OK.
6 Select the dmz1 interface row and select Edit:

IP/Netmask 10.20.10.1/255.255.255.0
Administrative access PING
7 Select OK.
To configure the FortiGate network interfaces - CLI

edit internal
set ip 10.22.101.1 255.255.255.0
set allowaccess ping https ssh
next
edit wan1
set ip 172.20.120.141 255.255.255.0
set allowaccess https
next
edit dmz1
set ip 10.20.10.1 255.255.255.0
end
Adding the default route

The Example Corporation gets the default gateway address from their ISP.
To add the default route - web-based manager

1 Go to Router > Static > Static Route.
2 Select Create New and enter the following information:
01-420-99686-20101026 267
Destination IP/ 0.0.0.0/0.0.0.0

Mask
Device wan1
Gateway 172.20.120.39
Distance 10
3 Select OK.
Note: Entering 0.0.0.0 as the IP and mask represents any IP address.
To add the default route - CLI

config router static
edit 1
set device wan1
set distance 10
end
Removing the default firewall policy

The FortiGate-100A comes preconfigured with a default internal -> wan1 firewall policy
which allows any type of traffic from any internal source to connect to the Internet at any
time. Remove this policy to simplify policy configuration and increase security. By deleting
this policy you ensure that any traffic which does not match a configured policy is rejected,
rather than possibly matching the default policy and passing through the FortiGate unit.
To remove the default firewall policy

2 Expand the internal -> wan1 entry.
3 Select policy 1 (Source: All, Dest: All) and select Delete.
To remove the default firewall policy using the CLI

delete 1
end
Configuring DNS forwarding

After deleting the default firewall policy, configure DNS forwarding from the internal
interface to allow DNS requests and replies to pass through the firewall. DNS server
addresses are usually provided by the ISP.
To configure DNS forwarding - web-based manager

1 Go to System > Network > Options.
2 For DNS Settings, enter the primary and secondary DNS server addresses:
Primary DNS Server 239.120.20.1

Secondary DNS Server 239.10.30.31
3 Select OK
268 01-420-99686-20101026
4 Got to Network > Interface.

5 Select the Internal interface row and select Edit.
6 Select Enable DNS Query and set it to Recursive.
7 Select OK.
To configure DNS forwarding - CLI

config system dns
set autosvr disable
set primary 239.120.20.1
set secondary 239.10.30.31
end
edit internal
set dns-query recursive
end
Setting the time and date

Time can be set manually or updated automatically using an NTP server. The Example
Corporation sets the time manually.
To set the time and date - web-based manager

1 Go to System > Status and select the Change link for the System Time.
2 Select the correct time zone for your location.
3 Select Set Time and set the current time and date.
4 Select OK.
To configure the time zone - CLI

set timezone 04
end
To configure the time and date - CLI

execute date <2010-03-31>
execute time <21:12:00>
Registering the FortiGate unit

The FortiGate-100A must be registered with Fortinet to receive automatic scheduled
updates and push updates. Enter the support contract number during the registration
process.
Begin by logging in to the web-based manager.
To register the FortiGate unit - web-based manager

1 Go to System > Status and get the product serial number from the Unit Information
section or check the label on the bottom of the FortiGate unit.
2 Go to http://support.fortinet.com and click Product Registration.
3 Fill in all the required fields including the product model and serial number.
4 Select Finish.
01-420-99686-20101026 269
Scheduling automatic antivirus and attack definition updates

The Example Corporation schedules daily antivirus and attack definition updates at 5:30
am. They also enable push updates so that critical antivirus or attack definitions are
automatically delivered to the FortiGate-100A whenever a threat is imminent.
FortiProtect Distribution Network (FDN) services provide all antivirus and attack updates
and information. A virus encyclopedia and an attack encyclopedia with useful protection
suggestions, as well as a daily newsletter, are available on the web site at
http://www.fortiguard.com.
To check server access and enable daily and push updates - web-based manager
1 Go to System > Maintenance > FortiGuard.
2 Expand the Antivirus and IPS Options blue arrow.
3 Select Allow Push Update.
4 Select Scheduled Update.
5 Select Daily and select 5 for the hour.
6 Select Apply.
Note: If you want to set the update time to something other than the top of the hour, you
must use the CLI command.
To check server access and enable daily and push updates - CLI
config system autoupdate push-update
set status enable
end
config system autoupdate schedule
set frequency daily
set status enable
set time 05:30
end
Configuring administrative access and passwords

The Example Corporation adds an administrator account and password using a new read-
only access profile. This read-only administrator monitors network activity and views
settings. They can notify the admin administrator if changes are required or a critical
situation occurs. The read-only administrator can only access the FortiGate web-based
manager from their own computer or the lab computer.
The admin administrator gets a new password (default is a blank password).
To configure a new access profile and administrator account - web-based manager

1 Go to System > Admin > Admin Profile.
3 Enter admin_monitor as the Profile Name.
4 Select Read Only.
5 Select OK.
6 Go to System > Admin > Administrators.
7 Select Create New and enter or select the following settings:
270 01-420-99686-20101026
Administrator admin_2
Password <psswrd>
Confirm Password <psswrd>
Trusted Host #1 10.11.101.60 / 255.255.255.255 (administrator’s computer)
Trusted Host #2 10.11.101.51 / 255.255.255.255 (lab computer)
Access Profile admin_monitor
8 Select OK.
To configure a new access profile and administrator account - CLI

config system accprofile
edit admin_monitor
set admingrp read
set authgrp read
set avgrp read
set fwgrp read
set ipsgrp read
set loggrp read
set mntgrp read
set netgrp read
set routegrp read
set spamgrp read
set sysgrp read
set updategrp read
set vpngrp read
set webgrp read
end
config system admin
edit admin2
set accprofile admin_monitor
set password <psswrd>
set trusthost1 192.168.100.60 255.255.255.255
set trusthost2 192.168.100.51 255.255.255.255
end
To change the admin password - web-based manager

2 Select the admin name and select Change Password.
3 Enter the new password and enter it again to confirm.
4 Select OK.
To change the admin password - CLI

config system admin
edit admin
set password <psswrd>
end
01-420-99686-20101026 271
Configuring settings for Finance and Engineering departments Concept Example: Small Office Network Protection
Configuring settings for Finance and Engineering departments

Goals
• Provide control of web access. Tasks include:
• Adding the Finance and Engineering department addresses
• Configuring web category block settings
• Protect the network from spam and outside threats. Tasks include:
• Configuring FortiGuard spam filter settings
• Configuring a corporate set of UTM profiles
• Control traffic and maintain security. Tasks include:
• Configuring firewall policies for Finance and Engineering
Adding the Finance and Engineering department addresses

Firewall addresses and address groups are used to configure connections to and through
the FortiGate-100A.Each address represents a component of the network that requires
configuration with policies.
The Example Corporation adds address ranges to the firewall for Finance and
Engineering so they can be included in firewall policies. The two address ranges are
included in an address group to further simplify policy configuration.
To add address ranges for Finance and Engineering - web-based manager

Address Name Finance

Type Subnet / IP Range
Subnet / IP Range 10.11.101.10 - 10.11.101.20
Interface Internal
3 Select OK.
4 Repeat to add an address called Eng with the IP Range 10.11.101.51–10.11.101.99.
To add address ranges for Finance and Engineering - CLI

edit Finance
set type iprange
set start-ip 192.168.100.10
set end-ip 192.168.100.20
next
edit Eng
set type iprange
set start-ip 192.168.100.51
set end-ip 192.168.100.99
end
To include the Finance and Eng addresses in an address group - web-based

manager
1 Go to Firewall > Address > Group.
272 01-420-99686-20101026
Concept Example: Small Office Network Protection Configuring settings for Finance and Engineering departments

3 Enter FinEng as the Group Name.
4 Use the down arrow button to move the Finance and Eng addresses into the Members
box.
5 Select OK.
To include the Finance and Eng addresses in an address group - CLI

config firewall addrgrp
edit FinEng
set member Finance Eng
end
Configuring web category block settings

The Example Corporation employs the FortiGuard web filtering service to block access by
all employees to offensive web sites. After ordering the FortiGuard service, licensing
information is automatically obtained from the server.
To enable the FortiGuard web filtering service - web-based manager

2 Expand Web Filtering and Email Filtering Options.
3 Select Test Availability to ensure the FortiGate unit can access the FortiGuard server.
After a moment, the FDN Status should change from a red/yellow flashing indicator to a
solid green.
4 Select Enable CacheTTL and enter 3600 in the field.
5 Select Apply.
Note: Enabling cache means web site ratings are stored in memory so that the FortiGuard
server need not be contacted each time an often-accessed site is requested.
To enable FortiGuard web filtering - CLI

config system fortiguard
set webfilter-cache enable
set webfilter-cache-ttl 3600
end
Configuring FortiGuard spam filter settings

The Example Corporation configures spam blocking using FortiGuard, the IP address
black list and spam filtering service from Fortinet. FortiGuard works much the same as
real-time blackhole lists (RBLs). The FortiGate unit accesses the FortiGuard server,
compares addresses against the black list, applies proprietary filters for spam and tags,
passes or blocks potential spam messages.
To enable the FortiGuard spam filtering service - web-based manager

2 Expand Web Filtering and Email Filtering Options.
3 Select Enable CacheTTL and enter 3600 in the field.
4 Select Apply.
01-420-99686-20101026 273
Note: Marking email as spam allows end-users to create custom filters to block tagged
spam using the keyword.
To configure the FortiGuard RBL spam filter settings - CLI

config system fortiguard
set antispam-cache enable
set antispam-cache-ttl 3600
end
Configuring antivirus grayware settings

The Example Corporation blocks known grayware programs from being downloaded by
employees. Grayware programs are unsolicited commercial software programs that get
installed on computers, often without the user’s consent or knowledge. The grayware
category list and contents are added and updated whenever the FortiGate unit receives a
virus update.
To enable grayware blocking - web-based manager

1 Go to UTM > Antivirus > Virus Database.
2 Select Enable Grayware Detection.
3 Select Apply.
To enable grayware blocking - CLI

config antivirus settings
set grayware enable
end
Configuring a corporate set of UTM profiles

The Example Corporation configures a set of firewall UTM profiles called standard_profile
to apply to the Finance and Engineering departments as well as the home-based workers.
For detailed information on creating and configuring UTM profiles, see the FortiGate UTM
Guide.
With UTM profiles, the Example Corporation configures each UTM profile for antivirus,
web filtering, email filtering and IPS protection
Antivirus UTM profile

To create and configure a antivirus profile - web-based manager
3 Enter standard_profile as the Profile Name.
4 For Virus Scan select HTTP, FTP, IMAP, POP3, and SMTP.
5 Select OK.
To create and configure a antivirus profile - CLI

edit standard_profile
config http
set options scan
274 01-420-99686-20101026
Concept Example: Small Office Network Protection Configuring settings for Finance and Engineering departments
end
config ftp
set options scan
end
config imap
set options scan
end
config pop3
set options scan
end
config smtp
set options scan
end
end
Web filter UTM profile

The Example Corporation orders FortiGuard for web filtering. FortiGuard gives
administrators the option of allowing, blocking, or monitoring web sites in 77 categories.
Categories are divided into groups to make configuration easier. By default, all categories
are set to allow. The Example Corporation configures selected categories as follows:
To create and configure a web filter profile - web-based manager

4 Select the HTTP option.
5 Select the following and select OK.
Potentially Liable Block

Controversial
Adult Materials Block
Extremist Groups Block
Pornography Block
Potentially Non-productive
Games Block
Potential Bandwidth Consuming Block
Potentially Security Violating Block
General Interest
Job Search Block
Social Networking Block
Shopping and Auction Block
To create and configure a web filter profile - CLI

config ftgd-wf
set deny g01 8 12 14 20 g04 g05 34 37 42
end
config http
set options fortiguard-wf
01-420-99686-20101026 275
end
end
Email filter UTM profile

To create and configure a email filter profile - web-based manager
4 For the IP Address BWL select the SMTP check box.
5 For the Email Address BWL Check, select the SMTP check box.
6 Select OK.
To create and configure a email filter profile - CLI

config spamfilter profile
config smtp
set options spamemailbwl
set options spamipbwl
end
end
Configuring firewall policies for Finance and Engineering

By configuring firewall policies for specific users you can grant different levels of access to
different groups as required.
Important points for firewall policy configuration

• Policies are organized according to the direction of traffic from the originator of a
request to the receiver of the request. For example, even though viruses may come
from the external interface, the request for email or a web page comes from the
internal interface. Therefore the policy protecting the network would be an internal ->
wan1 policy.
• Policies are matched to traffic in the order they appear in the policy list (not by ID
number)
• Policies should go from most exclusive to most inclusive so that the proper policies are
matched. As a simple example, a policy blocking internal to external HTTP access for
some employees should come before a policy that allows HTTP access for everyone.
• Each interface can benefit from layered security created through multiple policies
Note: The following policy is an internal to wan1 policy which uses the standard_profile
protection profile to provide antivirus, web category blocking, and FortiGuard spam
filtering.
276 01-420-99686-20101026
Concept Example: Small Office Network Protection Configuring settings for the Help Desk department
To configure the Finance and Engineering firewall policy - web-based manager

3 Enter or select the following settings:
Source Interface / Zone internal

Source Address FinEng
Destination Interface / Zone wan1
Schedule Always
Service ANY
Action ACCEPT
4 Select Enable NAT.

5 Select UTM and select the Protocol Options of default.
6 Select Enable Antivirus and select standard_profile.
7 Select Enable IPS and select all_default.
8 Select Enable Web Filter and select standard_profile.
9 Select Enable Email Filter and select standard_profile.
10 Select OK.
To configure the Finance and Engineering firewall policy - CLI

edit 1
set action accept
set dstaddr all
set dstintf wan1
set schedule always
set service ANY
set srcaddr FinEng
set nat enable
set profile-protocol-options default
set av-profile standard_profile
set ips-sensor all_default
set webfilter-profile standard_profile
set spamfilter-profile standard_profile
end
Configuring settings for the Help Desk department

Because of a high turnover rate and a need for increased productivity in the Help Desk
department, The Example Corporation implements very strict web access settings. Help
desk employees can only access four web sites that they require for their work. During
lunch hours, help desk employees have greater access to the web but are still blocked
from using Instant Messaging and Peer-to-Peer programs and accessing objectionable
web sites.
01-420-99686-20101026 277
Configuring settings for the Help Desk department Concept Example: Small Office Network Protection
Goals
• Provide complete control of web access. Tasks include:
• Adding the Help Desk department address
• Creating and Configuring URL filters
• Enable greater access at certain times. Tasks include:
• Creating a recurring schedule
• Configuring firewall policies for help desk
Adding the Help Desk department address

The Example Corporation adds an address range for the Help Desk department so it can
be included in a separate firewall policy.
To add the help desk department address - web-based manager

Address Name Help_Desk

Subnet / IP Range 10.11.101.21 - 10.11.101.50
Interface Any
3 Select OK.
Adding the help desk department address - CLI

edit Help_Desk
set type iprange
set start-ip 10.11.101.21
set end-ip 10.11.101.50
end
Creating and Configuring URL filters

Antivirus, spam filter, and web filter are global settings previously configured for the
Finance and Engineering set up. In this step The Example Corporation adds additional
web filter settings to block web access with the exception of four required web sites. Web
URL filters are then enabled in the web URL policy for help desk employees.
Before you can configure filters, you must first create a list to place the filters in.
To create a filter list for blocked URLs - web-based manager

1 Go to UTM > Web Filter > URL Filter.
3 Enter Example_URL_Filter as the name.
4 Select OK.
To create a filter list for blocked URLs - CLI

278 01-420-99686-20101026
edit # (select any unused number)

set name Example_URL_Filter
end
To configure a URL block - web-based manager

2 Select Example_URL_Filter and select Edit.
4 Enter the following settings:
URL .*
Type Regex
Action Block
5 Select Enable.
6 Select OK.
This pattern blocks all web sites.
To configure URL block - CLI

edit #
config entries
edit #
set action block
set type regex
set status enable
end
end
Note: The edit command will only accept a number. Type edit ? for a list of URL filter
lists and their corresponding number
To configure a filter to exempt URLs - web-based manager

2 Select Example_URL_Filter and select Edit.
URL www.example.com
Type Simple
Action Exempt
5 Select Enable.
6 Select OK.
7 Repeat for each of the following URLs:
• intranet.example.com
• www.dictionary.com
• www.ExampleReferenceSite.com
01-420-99686-20101026 279
To configure URL exempt - CLI

edit #
config entries
edit www.example.com
set action exempt
set type simple
set status enable
next
edit intranet.example.com
set action exempt
set type simple
set status enable
next
edit www.dictionary.com
set action exempt
set type simple
set status enable
next
edit www.ExampleReferenceSite.com
set action exempt
set type simple
set status enable
end
Web filter UTM profile

With the URL filtered defined, add a web filter profile to be used in the firewall policies.
To create and configure a web filter profile - web-based manager

3 Enter help_desk_work as the Profile Name.
4 For Web URL Filter, select the HTTP option, and select the help_desk_work.
5 Select OK.
To create and configure a web filter profile - CLI

edit help_desk_work
config http
set options urlfilter
end
config web
set urlfilter-table 1
end
end
280 01-420-99686-20101026
Ordering the filtered URLs

While the list includes all the exempt URLs the help desk needs with a global block filter,
there is a problem. Since the URL Filter list is parsed from top to bottom, and the block
filter appears first, every URL will match the block filter and parsing will stop. The exempt
URL statements that follow will never be referenced. To fix this problem, reorder the list to
put the global block filter at the end.
To order the filter URLs - web-based manager

1 Select the Move To icon for the “.*” URL.
2 Select After and type www.ExampleReferenceSite.com into the URL field.
3 Select OK.
To order the filtered URLs - CLI

move # after #
end
Note: The move command will only accept a number. Type move ? for a list of URL filter
lists and their corresponding numbers.
Application control or IM and P2P

By creating an application control profile, you can include the IM/P2P applications that
need to be blocked from the help desk users.
To configure the application control profile - web-based manager

1 Go to UTM > Application Control > Profile.
3 Enter the profile name of IM_P2P.
4 Select OK.
5 Select the new group name and select Edit.
7 In the Category list, select IM.
8 Set the Action to Block and Select OK.
9 Repeat the above steps to add an entry for P2P.
To configure the application control profile - CLI

config application list
edit IM_P2P
config entries
edit 1
set category 1
next
edit 2
set category 2
end
end
01-420-99686-20101026 281
Creating a recurring schedule

The Example Corporation uses this schedule in a firewall policy for help desk employees
to allow greater web access during lunch hours. The schedule is in effect Monday through
Saturday from 11:45am to 2pm.
To create a recurring schedule - web-based manager

1 Go to Firewall > Schedule > Recurring.
3 Enter lunch as the name for the schedule.
4 Select the days Mon through Fri.
5 Set the Start time as 11:45 and set the Stop time as 14:00.
6 Select OK.
To create a recurring schedule - CLI

edit lunch
set start 11:45
set end 14:00
end
Configuring firewall policies for help desk

The Example Corporation configures two firewall policies for the help desk employees, to
implement the web block settings and use the schedule for lunch hour web access
created above. For tips on firewall policies see “Important points for firewall policy
configuration” on page 276.
The first policy is an internal -> wan1 policy which uses the help_desk protection profile to
block most web access during working hours. The second policy goes above the first
policy and uses the lunch schedule and the help_desk_lunch protection profile to allow
web access at lunch.
To create and insert a policy for the help desk - web-based manager
2 Expand the internal -> wan1 entry and select the Insert Policy before icon beside
policy 1.

Source Address Help_Desk
Schedule Always
Service ANY
Action ACCEPT

282 01-420-99686-20101026

10 Select Enable Application Control and select IM_P2P.
11 Select OK.
12 Select the policy and select Move.
13 Select Before and enter Policy ID 2.
Note: The FortiGate unit checks for matching policies in the order they appear in the list
(not by policy ID number). For the ‘lunch’ policy to work, it must go before the policy using
the help-desk protection profile (above).


Source Address Help_Desk
Schedule lunch
Service ANY
Action ACCEPT

22 Select OK.
Configuring firewall policies for help desk - CLI

edit 2
set action accept
set dstaddr all
set dstintf wan1
set profile-status enable
set schedule always
set service ANY
set srcaddr Help_Desk
set nat enable
01-420-99686-20101026 283
Configuring remote access VPN tunnels Concept Example: Small Office Network Protection

set application-list IM_P2P
next
edit 3
set action accept
set dstaddr all
set dstintf wan1
set schedule lunch
set service ANY
set srcaddr Help_Desk
set nat enable
next
move 2 before 1
move 3 before 2
end
Configuring remote access VPN tunnels

Goals
• Configure a secure connection for home-based workers. Tasks include:
• Adding addresses for home-based workers
• Configuring the FortiGate end of the IPSec VPN tunnels
• Configuring firewall policies for the VPN tunnels
Adding addresses for home-based workers

To support VPN connections to the internal network, add a firewall address for the The
Example Corporation internal network.
To support a VPN connection for a home-based employee with a static IP address, add a
firewall address for this employee.
The Example Corporation uses a Dynamic Domain Name Server (DDNS) VPN
configuration for a home-based employee with a dynamic IP address. The DDNS VPN
uses the All firewall address.
To add address for home-based workers - web-based manager

Address Name Example_Network

284 01-420-99686-20101026
Concept Example: Small Office Network Protection Configuring remote access VPN tunnels
Subnet / IP Range 192.168.100.0

Interface Any
3 Select OK.
Address Name Home_User_1

Subnet / IP Range 220.100.65.98
Interface Any
5 Select OK.
To add addresses for home-based workers - CLI

edit Example_Network
set subnet 192.168.100.0 255.255.255.0
next
edit Home_User_1
set subnet 220.100.65.98 255.255.255.0
end
Configuring the FortiGate end of the IPSec VPN tunnels

The Example Corporation uses AutoIKE preshared keys to establish IPSec VPN tunnels
between the internal network and the remote workers.
Home_User_1 has a static IP address with a straightforward configuration.
Home_User_2 has a dynamic IP address and therefore some preparation is required. The
Example Corporation will register this home-based worker with a domain name. The
DDNS servers remap the IP address to the domain name whenever Home_User_2 gets a
new IP address assigned by their ISP.
The Example Corporation home-based workers use FortiClient software for VPN
configuration.
To configure IPSec phase 1 - web-based manager

1 Go to VPN > IPSEC > Auto Key (IKE).
2 Select Create Phase 1.
3 Enter or select the following settings for Home_User_1:
Name Home1 (The name for the peer that connects to the The Example
Corporation network.)
Remote Gateway Static IP Address
IP Address 220.100.65.98
Local Interface wan1
Mode Main (ID protection)
Note: The VPN peers must use the same mode.
Authentication Preshared Key
Method
01-420-99686-20101026 285
Pre-shared Key ke8S5hOqpG73Lz4

Note: The key must contain at least 6 printable characters and should only
be known by network administrators. For optimum protection against
currently known attacks, the key should consist of a minimum of 16
randomly chosen alphanumeric characters. The VPN peers must use the
same preshared key.
Peer options Accept any peer ID
4 Select OK.
6 Enter or select the following settings for Home_User_2:
Name Home2 (The name for the peer that connects to the The Example
Corporation network.)
Remote Gateway Dynamic DNS
Dynamic DNS example.net
Local Interface wan1
Note: The VPN peers must use the same mode.
Authentication Preshared Key
Method
Pre-shared Key GT3wlf76FKN5f43U
Note: The key must contain at least 6 printable characters and should only
be known by network administrators. For optimum protection against
currently known attacks, the key should consist of a minimum of 16
randomly chosen alphanumeric characters. The VPN peers must use the
same preshared key.
Peer options Accept any peer ID
7 Select OK.
Note: Both ends (peers) of the VPN tunnel must use the same mode and authentication
method.
To configure IPSec phase 1 - CLI

config vpn ipsec phase1
edit Home1
set type static
set interface wan1
set authmethod psk
set psksecret ke8S5hOqpG73Lz4
set remote-gw 220.100.65.98
set peertype any
next
edit Home2
set type ddns
set interface wan1
set authmethod psk
set psksecret GT3wlf76FKN5f43U
set remotewgw-ddns example.net
set peertype any
end
286 01-420-99686-20101026
Concept Example: Small Office Network Protection Configuring remote access VPN tunnels
To configure IPSec phase 2

Name Home1_Tunnel
Phase 1 Home1
4 Select OK.
Name Home2_Tunnel
Phase 1 Home2
7 Select OK.
To configure IPSec phase 2 using the CLI

edit Home1_Tunnel
set phase1name Home1
next
edit Home2_Tunnel
set phase1name Home2
end
Configuring firewall policies for the VPN tunnels

The Example Corporation configures specific policies for each home-based worker to
ensure secure communication between the home-based worker and the internal network.
To configure firewall policies for the VPN tunnels - web-based manager

2 Select Create New and enter or select the following settings for Home_User_1:

Source Address Example_Network
Destination Address Home_User_1
Schedule Always
Service ANY
Action IPSEC
VPN Tunnel Home1
Allow Inbound yes
Allow outbound yes
Inbound NAT yes
Outbound NAT no

01-420-99686-20101026 287

8 Select OK
9 Select Create New and enter or select the following settings for Home_User_2:

Source Address Example_Network
Schedule Always
Service ANY
Action IPSEC
VPN Tunnel Home2_Tunnel
Allow Inbound yes
Allow outbound yes
Inbound NAT yes
Outbound NAT no

15 Select OK
To configure firewall policies for the VPN tunnels - CLI

edit 5
set dstintf wan1
set srcaddr Example_Network
set dstaddr Home_User_1
set action ipsec
set schedule Always
set service ANY
set inbound enable
set outbound enable
set natinbound enable
set vpntunnel Home1
next
edit 6
288 01-420-99686-20101026
Concept Example: Small Office Network Protection Configuring the web server

set dstintf wan1
set srcaddr Example_Network
set dstaddr All
set action ipsec
set schedule Always
set service ANY
set inbound enable
set outbound enable
set vpntunnel Home2
end
Configuring the FortiClient end of the IPSec VPN tunnels

Fortinet has a complete range of network security products. FortiClient software is a
secure remote access client for Windows computers. Home-based workers can use
FortiClient to establish VPN connections with remote networks. For more information
about installing and configuring FortiClient please see the FortiClient Installation Guide.
Note: The specific configuration given in this example will only function with licensed copies
of the FortiClient software. The default encryption and authentication types on the FortiGate
unit are not available on the FortiClient Demo software.
To configure FortiClient for Home_User_1 and Home_User_2 - web-based manager

1 Open the FortiClient software on Home_User_1’s computer.
2 Go to VPN > Connections.
3 Select Add.
4 Enter the following information:
Connection Name Home1_home (A descriptive name for the connection.)

VPN Type Manual IPSec
Remote Gateway 172.10.120.141 (The FortiGate external interface IP address.)
Remote Network 10.11.101.0 / 255.255.255.0 The Example Corporation internal
network address and netmask.)
Authentication method Preshared Key
Preshared key ke8S5hOqpG73Lz4 (The preshared key entered in phase 1.)
5 Select OK.
6 Repeat on Home_User_2’s computer for Home_User_2.
Configuring the web server

Goals
• Host the web server on a separate but secure DMZ network
01-420-99686-20101026 289
Configuring the web server Concept Example: Small Office Network Protection
• Hide the internal IP address of the web server. Tasks include:

• Configuring the FortiGate unit with a virtual IP
• Adding the web server address
• Configuring firewall policies for the web server
Alternately, The Example Corporation could have their web server hosted by an ISP. See
“ISP web site and email hosting” on page 297.
Configuring the FortiGate unit with a virtual IP

With the web server located on the DMZ interface, The Example Corporation configures a
virtual IP (VIP) address so that incoming requests for the web site are routed correctly.
The virtual IP can be included later in wan1 -> dmz1 firewall policies.
To configure the FortiGate unit with a virtual IP - web-based manager

1 Go to Firewall > Virtual IP > Virtual IP.
Name Web_Server_VIP
External Interface wan1
Type Static NAT
External IP Address/ Range 172.20.120.141
Mapped IP Address/ Range 10.20.10.3
3 Select OK.
To configure a virtual IP - CLI

config firewall vip
edit Web_Server_VIP
set extintf wan1
set extip 172.20.120.141
end
Adding the web server address

The Example Corporation adds the web server address to the firewall so it can be
included later in firewall policies.
To add the web server address - web-based manager

Address Name Web_Server

Type Subnet/ IP Range
Subnet/ IP Range 10.20.10.3/255.255.255.0
Interface Any
3 Select OK.
290 01-420-99686-20101026
Concept Example: Small Office Network Protection Configuring the web server
To add the web server address - CLI

edit Web_Server
set subnet 10.20.10.3 255.255.255.0
end
Configuring firewall policies for the web server
wan1 -> dmz1 policies

Add a policy for users on the Internet (wan1) to access the The Example Corporation web
site on the DMZ network.
To add a policy for web server access

Source Interface / Zone wan1

Source Address All
Destination Interface / Zone dmz1
Destination Address Web_Server_VIP
Schedule Always
Service HTTP
Action ACCEPT

8 Select OK.
To add a policy for web server access - CLI

edit 7
set action accept
set schedule always
set service HTTP
set srcaddr all
set srcintf wan1
set dstaddr Web_Server_VIP
set dstintf dmz1
end
01-420-99686-20101026 291
Configuring the web server Concept Example: Small Office Network Protection
dmz1 -> wan1 policies

The Example Corporation does not require any dmz1 -> wan1 policies since there is no
reason for the server to initiate requests to the external interface.
dmz1 -> internal policies

The Example Corporation does not require any dmz1 -> internal policies since there is no
reason for the server to initiate requests to the internal interface.
internal -> dmz1 policies

Add a policy for the web developer to upload updates web site to the web server using
FTP.
To add the web master address to the firewall - web-based manager

Address Name Web_Master_J

Subnet/ IP Range 10.11.101.63/255.255.255.0
Interface Any
3 Select OK.
To add the web master address to the firewall - CLI

edit Web_Master_J
set subnet 10.11.101.63 255.255.255.0
end
To add a policy for web master access to the web server - web-based manager
1 Go to Firewall > Policy.

Source Address Web_Master_J
Destination Address Web_Server
Schedule Always
Service FTP
Action ACCEPT

8 Select OK.
292 01-420-99686-20101026
Concept Example: Small Office Network Protection Configuring the email server
To add a policy for web master access to the web server - CLI
edit 8
set action accept
set dstaddr Web_Server
set dstintf dmz1
set schedule always
set service FTP
set srcaddr Web_Master_J
end
Configuring the email server

Goals
• Host the email server on a separate but secure network
• Hide the internal IP addresses of the servers. Tasks include:
• Configuring the FortiGate unit with a virtual IP
• Adding the email server address
• Configuring firewall policies for the email server
Alternately, The Example Corporation could have their email server hosted by an ISP. See
“ISP web site and email hosting” on page 297.
Configuring the FortiGate unit with a virtual IP

With the email server on the DMZ network, The Example Corporation uses a virtual IP
(VIP) address so that incoming email requests are routed correctly. The Example
Corporation uses the IP address of the FortiGate wan1 interface for email and any SMTP
or POP3 traffic is forwarded to the email server on the DMZ. The virtual IP can be included
later in wan1 -> dmz1 firewall policies.
To configure a virtual IP - web-based manager

Name Email_Server_VIP
Type Static NAT
External IP Address/ Range 172.20.120.141
Mapped IP address/ Range 10.20.10.2
3 Select OK.
01-420-99686-20101026 293
Adding the email server address Concept Example: Small Office Network Protection
To configure a virtual IP - CLI

config firewall vip
edit Email_Server_VIP
set extintf wan1
set extip 172.20.120.141
end
Adding the email server address

The Example Corporation adds the email server address to the firewall so it can be
included later in firewall policies.
To add the email server address to the firewall - web-based manager

Address Name Email_Server

Subnet/ IP Range 10.10.10.3/255.255.255.0
Interface Any
3 Select OK.
To add the email server address to the firewall - CLI

edit Email_Server
set subnet 10.20.10.3 255.255.255.0
end
Configuring firewall policies for the email server

Add and configure firewall policies to allow the email servers to properly handle emails.
dmz1 -> wan1 policies

Add a firewall policy to allow the email server to forward messages to external mail
servers.
To add a dmz1 -> wan1 firewall policy - web-based manager

Source Interface / Zone dmz1

Source Address Email_Server
Schedule Always
Service SMTP
Action ACCEPT
294 01-420-99686-20101026
Concept Example: Small Office Network Protection Adding the email server address

8 Select OK.
To add a dmz1 -> wan1 firewall policy- CLI

edit 9
set action accept
set dstaddr all
set dstintf wan1
set schedule always
set service SMTP
set srcaddr Email_Server
set srcintf dmz1
end
wan1 -> dmz1 policies

Add a policy to allow Internet email servers to forward messages to the email server.
To add a wan1 -> dmz1 firewall policy - web-based manager

Source Interface / Zone wan1

Source Address All
Destination Address Email_Server_VIP
Schedule Always
Service SMTP
Action ACCEPT

8 Select OK.
01-420-99686-20101026 295
Adding the email server address Concept Example: Small Office Network Protection
To add a wan1 -> dmz1 firewall policy - CLI

edit 10
set action accept
set srcintf wan1
set srcaddr all
set dstintf dmz1
set dstaddr Email_Server_VIP
set schedule always
set service SMTP
end
dmz1 -> internal policies

The Example Corporation does not require any dmz -> internal policies since there is no
reason for the server to initiate requests to the internal network.
internal -> dmz1 policies

The Example Corporation needs to add two internal -> dmz1 policies. One policy for
internal users to send outgoing messages to the server (SMTP) and a second policy for
internal users to read incoming mail (POP3).
To add internal -> dmz1 firewall policies - web-based manager


Source Address All
Destination Address Email_Server
Schedule Always
Service SMTP
Action ACCEPT

8 Select OK.

Source Address All
296 01-420-99686-20101026
Concept Example: Small Office Network Protection ISP web site and email hosting

Destination Address Email_Server
Schedule Always
Service POP3
Action ACCEPT
15 Select OK.
To add internal -> dmz1 firewall policies - CLI

edit 11
set action accept
set dstaddr Email_Server
set dstintf dmz1
set schedule always
set service SMTP
set srcaddr all
next
edit 12
set action accept
set dstaddr Email_Server
set dstintf dmz1
set schedule always
set service POP3
set srcaddr all
end
ISP web site and email hosting

Small companies such as The Example Corporation often find it more convenient and less
costly to have their email and web servers hosted by an ISP. This scenario would change
the The Example Corporation example in the following ways:
• no need to set up a separate DMZ network
01-420-99686-20101026 297
The Example Corporation internal network configuration Concept Example: Small Office Network Protection
• no need to create policies for external access to the web or email servers
• add an internal -> wan1 firewall policy for the web master to upload web site updates
via FTP
• add an internal -> wan1 POP3 firewall policy so that users can use POP3 to download
email
• add an internal -> wan1 SMTP firewall policy so that users can use SMTP to send
email
The Example Corporation internal network configuration

The Example Corporation internal network only requires a few changes to individual
computers to route all traffic correctly through the FortiGate-100A.
• set the IP addresses within the prescribed ranges for each computer on the network
(see Figure 28 on page 265)
• set the default gateway to the IP address of the FortiGate internal interface for each
computer on the network
• set the DNS server to the IP address of the FortiGate internal interface for each
computer on the network
Other features and products for SOHO

Small or branch offices can use the FortiGate unit to provide a secure connection between
the branch and the main office.
Other tasks or products to consider:
• Configuring logging and alert email for critical events
• Backing up the FortiGate configuration
• Enabling Internet browsing for the home users through the VPN tunnel to ensure no
unencrypted information enters or leaves the remote site
• VoIP communications between branches
298 01-420-99686-20101026
Concept Example: Library Network
Protection
Located in a large city, the library system is anchored by a main downtown location
serving most of the population, with a dozen branches spread throughout the city. Each
branch is wired to the Internet but none are linked with each other by dedicated
connections.
Current topology and security concerns

Each office connects to the Internet with no standard access policy or centralized
management and monitoring.
The library system does not log Internet traffic and does not have the means to do so on a
system-wide basis. In the event of legal action involving network activity, the library
system will need this information to protect itself.
The branches currently communicate with the main office through the Internet with no
encryption. This is of particular concern because all staff members access the central
email server in the main office. Email sent to or from branch office staff could be
intercepted.
Both the main and branch offices are protected from the Internet by firewalls. This
protection is limited to defending against unauthorized intrusion. No virus, worm, phishing,
or spyware defences protect the network, resulting in computer downtime when an
infection strikes.
Like the branches, the main office is protected by a single firewall device connected to the
Internet. Should this device fail, connectivity will be lost. The library system’s web page
and catalog are mission critical applications and access would be better protected by
redundant hardware.
The internal network at each location has staff computers and public access terminals
connected together. Concerns have been raised over possible vulnerabilities involving
staff computers and public terminals sharing the same network.
Budgetary constraints limit the number of public access terminals the library can provide.
With the popularity of wifi enabled laptops, the addition of a wireless access point is an
economical way to allow library patrons to access the Internet using their own equipment.
Efficient use of the library’s limited public access terminals and bandwidth can be
compromised by the installation and use of instant messaging and peer to peer file sharing
applications.
Use of library resources to browse inappropriate content is a problem. These activities are
prohibited by library policies, but there is no technical means of enforcement, leaving it to
the staff to monitor usage as best they can.
01-420-99686-20101026 299
Current topology and security concerns Concept Example: Library Network Protection
Figure 29: The library system’s current network topology

Branch configuration
(only one branch shown)
P
ub
lic
te
rm
B
in
ra
al
nc
s
Fir
h
st
ew
af
all
f
C
at
al
og
ac Main office configuration
ce
ss
te
rm
Fir
in
ew
al
s
al l
DM
s s
al es
Z
in cc
rm a
te log
a
at
C
rv log
se ta
er
M
a
P
ai
er C
ub
n
rv b
of
lic
se e
fic
W
te
e
rm
st
in
af
al
f
rv i l
s
se a
er
M
Library requirements
• VPN to secure all traffic between main and branch offices.
• Public wireless Internet access for mobile clients.
• Strict separation of public access terminals from staff computers.
• An automatically maintained and updated system for stopping viruses and intrusions at
the firewall.
• Instant messaging is blocked for public Internet terminals and public wireless access,
but not for staff. Peer-to-peer downloads are blocked network-wide.
• All Internet traffic from branch offices travels securely to the main office and then out
onto the Internet. Inbound traffic follows the reverse route. This allows a single point at
which all protection profiles and policies may be applied for simplified and consistent
management.
• The ability to block specific web sites and whole categories of sites from those using
the public terminals and public wireless access if deemed necessary. Users granted
special permission should be allowed to bypass the restrictions.
• Public access traffic originates from a different address than staff and server traffic.
• DMZ for web and email server hosting in main office.
• The library catalog is available on the library’s web page allowing public access from
anywhere.
• Redundant hardware for main office firewall.
The library’s decision

Every model of the FortiGate Dynamic Threat Prevention System offers real time network
protection to detect and eliminate the most damaging, content-based threats from email
and Web traffic such as viruses, worms, intrusions, inappropriate Web content and more
in real time — without degrading network performance.
The library decided to standardize on the FortiGate-800 and the FortiWiFi-80CM:
300 01-420-99686-20101026
Concept Example: Library Network Protection Current topology and security concerns
• Two FortiGate-800 units for main office. These enterprise-level devices have the
processing power and speed to handle the amount of traffic expected of a large busy
library system with public catalog searches, normal staff use, and on-site research
using the Internet as a resource. The two units are interconnected in HA (high
availability) mode to ensure uninterrupted service in the case of failure. A
FortiWiFi-80CM is also used to provide wireless access for patrons in main office.
• A FortiWiFi-80CM for each branch office. In addition to being able to handle the
amount of traffic expected of a branch office, the FortiWiFi-80CM provides wireless
access for library patrons.
Proposed topology
Figure 30 shows the proposed network topology utilizing the FortiGate units. Only one
branch office is shown in the diagram although more than a dozen are configured in the
same way, including the VPN connection to the main office.
The VPN connections between the branch offices and the main office are a critical feature
securing communication between locations.
The two FortiGate-800 units in HA mode serve as the only point through which traffic flows
between the Internet and the library’s network, including the branch offices. VPN
connections between the main and branch offices provide the means to securely send
data in either direction.
Branch Internet browsing traffic is routed to the main office through the VPN by the
branch’s FortiWiFi-80CM. After reaching the FortiGate-800 at the main office, the traffic
continues out to the Internet. Inbound traffic follows the same path back to the branch
office.
With two FortiGate-800 units in HA mode serving as a single point of contact to the
Internet, only two FortiGuard subscriptions are required to protect the entire network.
Otherwise each branch would also need separate FortiGuard subscription. The
FortiGuard web filtering service can also be configured on the FortiGate-800 units,
ensuring consistent web filtering policies for all locations.
No provision is made for direct communication between branches.
01-420-99686-20101026 301
Current topology and security concerns Concept Example: Library Network Protection
Figure 30: Proposed library system network topology

CM
B .1.
Int
ra 2.
10
80
nc [2
e
Fi-
54 ls
10 rnal
-2 na
h -25
Wi
st 4
Z
]
.[2 mi
.1.
af ]
DM4.1
.4 r
2.1
.1 c te
.1.
10 bli
10
u
P
N2 19 WAN
WA.3.1 2.1 1
. 1 68
10 .23
.8 CM
C
9 80
at
Fi-
al 10
og .1
ac .3.
ce [2- Wi
ss 25
V
P
te 4]
N
rm 00
Tu
19 Exte
in
T-8 er rt4
n
a
ne
ls
2.1 rm FG lust Po .5.1
-2 als
68 al C 00
]
.[2 in
54
.14 HA . 1
.4 rm
7.3 10 rt3
00 te
0 Po .4.1
.1 lic
0
10 ub
.10
P
1 0
rt2
Po .3.1 DM
10 Z
. 1 00 al .10
10 ern 1 0.1
Int 0.2. .1
.10
10
.1 rv log
10 se a
2
00 er
at
.1
C
.1
M .1
ai 00
10
n .2
Ca
of .[
tal
fic 2-
.1 rv il
10 se a
10. og ac
1
00 er
e 25
.1
st 4]
.1
af
100 ces
f
.3.[ s te
2-2 rm
.1 rv b
10 se e
54] ina
0
00 er
W
.1
ls
.1
Main office configuration
Table 11 on page 302 details the allowed connectivity between different parts of the
network.
Table 11: Access permission between various parts of the network
Connecting to:
Branch Catalog access
Branch Public Access
Main Public Access
Internet Access
Catalog Server
Main Catalog
Branch Staff
Web Server
Mail Server
Main Staff
Branch staff No No No No No Yes Yes Yes* Yes

Branch Public Access No No No No No Yes No Yes* Yes
Branch Catalog access No No No No No Yes No Yes* No
Connecting from:
Main Staff No No No No No Yes Yes Yes* Yes

Main Catalog No No No No No Yes No Yes* No
Main Public Access No No No No No Yes No Yes* Yes
Web Server No No No No No No No Yes No
Mail Server No No No No No No No No Yes
Catalog Server No No No No No No No No No
Internet No No No No No No Yes Yes† Yes†
†Only SMTP connections are permitted from the Internet to the mail server.
* An indirect connection. Access to the catalog is through the library web page. Direct
connections to the catalog server are not permitted.
302 01-420-99686-20101026
Concept Example: Library Network Protection Current topology and security concerns
Features used in this example
Table 12: Features used to fulfil requirements
Feature requirement Location in this Description

example
Secure communication between each “IPsec VPN” on Traffic between the each branch
branch and the main office. page 308 and the main office is encrypted.
WiFi access for mobile clients. “Wireless access” on The FortiWiFi-80CM provides WiFi
page 318 access.
Strict separation of public access “Topology” on Traffic is permitted between
terminals from staff computers. page 305 network interfaces only when
policies explicitly allow it.
An automatically maintained and “FortiGuard” on The FortiGuard Subscription
updated system for stopping viruses page 307 service keeps antivirus and
and intrusions at the firewall. intrusion prevention signatures up
to date. Also included is a spam
blacklist and a web filtering service.
Instant messaging blocked for public “Protection profiles, Since staff user traffic and public
access, and P2P blocked system- Application Control” access user traffic is controlled by
wide. on page 314 separate policies, different
protection profiles can be created
for each.
The ability to block specific sites and “Protection profiles, The FortiGuard Web Filtering
whole categories of sites from the FortiGuard Web service breaks down web sites in to
public access terminals and public Filtering/Advanced 56 categories. Each can be allowed
WiFi. Filter” on page 312 or blocked.
Public access traffic originates from a “IP Pools” on IP pools can have traffic controlled
different address than staff and server page 309 by one policy originate from an IP
traffic in case of abuse. address different than the physical
network interface.
Mail and web server have their own IP “Mail and web Virtual IP addresses allow a single
addresses, but share the same servers” on physical interface to share
connection to the Internet as the rest page 321 additional IP addresses and route
of the main branch. traffic according to destination
address.
Before they’re allowed access, public “User Disclaimer” on Each policy can be set to require
access users must agree that the page 310 authentication and/or agreement to
library takes no responsibility for what a disclaimer before access is
they might see on the Internet. permitted.
Redundant hardware to ensure “High Availability Two FortiGate-800 units operate
availability. (HA)” on page 305 together to ensure a minimum
interruption should a hardware
failure occur.
Network addressing
The IP addresses used on the library’s internal network follow a 10.x.y.z structure with a
255.255.255.0 subnet mask, where:
• x is the branch number. The main office uses 100 while the branches are assigned
numbers starting with 1
01-420-99686-20101026 303
Configuring the main office Concept Example: Library Network Protection
• y indicates the purpose of the attached devices in this range:

• 1 - servers and other infrastructure
• 2 - staff computers
• 3 - catalog terminals
• 4 - public access terminals
• 5 - public WiFi access
• z is a range of individual machines
For example, 10.3.2.15 and 10.3.2.27 are two staff members' computers in the third library
branch.
Assigning IP addresses by location and purpose allows network administrators to define
addresses and address ranges to descriptive names on the FortiGate unit. These address
names then can also be incorporated into address groups for easy policy maintenance.
For example, the address range 10.1.2.[2-254] is assigned the name Branch_1_Staff on
the FortiGate-800 unit. Anytime a policy is required for traffic from the staff in branch 1,
this address name can be selected. Further, once an address name is specified for the
staff of each branch, all of those names can be combined into an address group named
Branch_Staff so all the branch staff can be referenced as a single entity.
Figure 31: IP address ranges are assigned names, and the names combined into address
groups.
IP Address Ranges Address Names Address Group

10.1.2.[2-254] Branch 1 Staff
10.2.2.[2-254] Branch 2 Staff

Branch Staff
10.3.2.[2-254] Branch 3 Staff
10.100.2.[2-254] Main Staff
The address names defined on the FortiGate-800 for Branch 1 traffic are Branch_1_Staff
(10.1.2.2-10.1.2.254), Branch_1_Catalog (10.1.3.2-10.1.3.254), Branch_1_Public
(10.1.4.2-10.1.4.254), and Branch_1_WiFi (10.1.5.2-10.1.5.254). Four address groups will
be created incorporating each type of address name from all the branches: Branch_Staff,
Branch_Catalog, Branch_Public, and Branch_WiFi.
At the main office, additional address names are configured for the web server
(Web_Server) and for the web and email servers combined (Servers).
Address names are configured in Firewall > Address > Address.
Address groups are configured in Firewall > Address > Group.
Configuring the main office

The FortiGate-800 cluster forms the hub of virtually all network communication, whether
within the main office, from the branch offices to the main branch, or from anywhere in the
library network to the Internet. This way, all virus scanning, spam and web filtering, as well
as access restrictions can be centralized and maintained in this one place.
304 01-420-99686-20101026
Concept Example: Library Network Protection Configuring the main office
Topology
The main office network layout is designed to keep the various parts of the network
separate. Computers on different segments of the network cannot contact each other
unless a FortiGate policy is created to allow the connection. Public terminals can access
the library’s web server for example, but they cannot access any machines belonging to
staff members. See Table 11 on page 302 for details on permitted access between
different parts of the library network.
Staff computers, email and web servers, public access terminals, and WiFi connected
systems are all protected by the FortiGuard service on the FortiGate-800 cluster. Push
updates ensure the FortiGate unit is up to date and prepared to block viruses, worms,
spyware, and attacks.
Figure 32: Main branch network topology
CM
- 80
W iFi
V
P
N
00
Tu
19 Exte T-8 er rt4

nne
2.1 rm FG lust Po .5.1

l
-2 als
68 al C 0
.10 t3
]
.[2 in
54
.14 HA
.4 rm
7.3 10 r
00 te
0 Po .4.1
.1 lic
0
10 ub
.1 0
P
rt2 10
Po .3.1 D
10 MZ
0 al
.10 .10
10 ern 1 0.1
Int 0.2. .1
.10
10
.1 rv log
10 se a
2
00 er
at
.1
C
.1
M .1
ai 00
10
n .2
Ca
of .[
tal
fic 2-
.1 rv il
10 se a
10. og ac
1
00 er
e 25
.1
st 4]
.1
af
100 ces
f
.3.[ s te
2-2 rm
.1 rv b
10 se e
54] ina
0
00 er
W
ls .1
.1
Main office configuration
High Availability (HA)

The two FortiGate-800 units will be connected in a high-availability (HA) cluster in active-
active mode. This is a redundant configuration ensuring network traffic will be virtually
uninterrupted should one unit fail. If only a single unit were present and experienced
problems, the main branch would be cut-off from the Internet and the branch offices.
Because the branches route their traffic through the main office, they’d also be isolated.
Active-active mode has the advantage of using the processing power of the subordinate
unit to increase the efficiency of antivirus scanning. The two FortiGate-800 units fulfil a
mission-critical role.
Configuring HA
Connect the cluster units to each other and to your network. You must connect all
matching interfaces in the cluster to the same hub or switch. Then you must connect these
interfaces to their networks using the same hub or switch.
01-420-99686-20101026 305
Configuring the main office Concept Example: Library Network Protection
To connect the cluster units

1 Connect the internal interfaces of each FortiGate-800 unit to a switch or hub connected
to your internal network.
2 Connect port2, port3, port4, external, and DMZ interfaces as described in step 1. See
Figure 33.
3 Connect the heartbeat interface of the both FortiGate-800 units using a crossover
cable, or normal cables connected to a switch.
Figure 33: HA Cluster Configuration with switches connecting redundant interfaces

INTERNAL EXTERNAL DMZ HA 1 2 3 4 CONSOLE USB
Esc Enter
PWR
Heartbeat
External
192.168.147.30
Port3
10.100.4.1
DMZ Port2
10.100.1.1 10.100.3.1
Internal Port4
10.100.2.1 10.100.5.1
INTERNAL EXTERNAL DMZ HA 1 2 3 4 CONSOLE USB

Esc Enter
PWR
To configure the primary unit - web-based manager

1 Power on one of the cluster units and log in to its web based interface.
2 Go to System > Config > HA and set the mode to Active-Active.
3 For the Group Name enter Library.
4 Enter a cluster password.
5 Select ha as the heartbeat interface.
6 Select OK.
7 Go to System > Network > Interface and set the interface IP addresses as indicated in
Figure 33 on page 306
To configure the primary unit - CLI

config system ha
set mode a-a
set group-name library
set password #####
set hbdev ha
end
To configure the subordinate unit - web-based manager

1 Power on the subordinate cluster unit and log in to its web based interface.
2 Go to System > Config > HA and set the mode to Active-Active.
3 Change the device priority from the default 128 to 64. The FortiGate unit with the
highest device priority in a cluster becomes the primary unit.
306 01-420-99686-20101026
Concept Example: Library Network Protection FortiGuard
4 For the Group Name enter Library.

5 Enter the cluster password.
6 Select ha as the heartbeat interface.
7 Select OK.
To configure the subordinate unit - CLI

config system ha
set mode a-a
set priority 64
set group-name library
set password #####
set hbdev ha
end
The two cluster units will then connect begin communication to determine which will
become the primary. The primary will then transfer its own configuration data to the
subordinate. In the few minutes required for this process, traffic will be interrupted. Once
completed, the two clustered units will appear as a single FortiGate unit to the network.
You can now configure the cluster as if it were a single FortiGate unit.
Note: All the FortiGate units in a cluster must have unique host names. Default host names
are the device serial numbers so unique names are automatic unless changed. If any
FortiGate device host names have been changed, confirm that there is no duplication in
those to be clustered.
HA is configured in System > Config > HA. For more information about HA, see the
FortiGate HA Overview on the Fortinet Technical Documentation web page.
FortiGuard
Four FortiGate features take advantage of the FortiGuard Service. They are Antivirus,
Intrusion Prevention, Web Filtering, and Antispam
Antivirus and intrusion prevention (IPS) signatures are updated automatically to detect
new attacks and viruses with FortiGuard updates. Virus scanning and IPS are configured
in protection profiles.
FortiGuard Web filtering is enabled and configured in each protection profile. When a web
page is requested, the URL is sent to the FortiGuard service and the category it belongs to
is returned. The FortiGate unit checks the FortiGuard Web Filtering settings and allows or
blocks the web page. The FortiGuard Web Filtering is configured in protection profiles.
FortiGuard Antispam is also enabled or disabled in each protection profile. The FortiGuard
service is consulted on whether each message in question is spam, and the FortiGate acts
accordingly. There are a number of ways to check a message, and each method can be
enabled or disabled in the protection profile. The Antispam is configured in protection
profiles.
The library network is configured with the FortiGate-800 cluster performing all virus
scanning, spam filtering, and FortiGuard web filtering. The settings defining how the
FortiGuard Distribution Network is contacted are configured in System > Maintenance >
FortiGuard.
01-420-99686-20101026 307
IPsec VPN Concept Example: Library Network Protection
IPsec VPN
The main office serves as a hub for the VPN connections from the branch offices. To make
the generation and maintenance of the required policies simpler, interface-mode VPNs will
be used. Interface-mode VPNs are configured largely the same as tunnel-mode VPNs, but
the way they’re use differs significantly. Interface-mode VPNs appear as network
interfaces, like the DMZ, port2, and external network interfaces.
Network topology is easier to visualize because you no longer have a single interface
sending and receiving both encrypted VPN traffic and unencrypted regular traffic. Instead,
the physical interface handles the regular traffic, and the VPN interface handles the
encrypted traffic. Further, policies no longer need to specify whether traffic is IPsec
encrypted. If traffic is directed to a VPN interface, the FortiGate unit knows it is to be
encrypted.
Interface-mode VPNs are used in this configuration because they will require far fewer
policies. Policies for tunnel-mode VPNs require selection of a tunnel in the policy. Many
tunnels can connect to a single physical interface, so the policy needs to know what traffic
it is responsible for.
Since interface-mode VPNs are used as any other network interface, they can be
collected into a zone and treated as a single entity. Addressing names and groups
differentiate what type of user is generating the traffic, so what tunnel it comes out of isn’t
important in the library’s configuration. All branch offices are treated the same.
For example, using tunnel-mode VPNs, 12 branches would require twelve policies to allow
employees to connect directly to the email and web servers. The branch 1 policy would
allow the IP range defined for staff coming from the branch 1 tunnel access to the DMZ. A
second policy would allow the IP range defined for staff coming from the branch 2 tunnel
access to the DMZ, and so on. Since the tunnel must be specified, there must be one
policy for each tunnel, and this is just for branch staff to DMZ traffic. In the library’s network
configuration, there are nine traffic type/destination combinations using the VPN. This
would require 108 policies for 12 branches.
To simplify things we instead give names to the address ranges based on use and
location. IP address range 10.1.2.[2-255] is named Branch 1 Staff and 10.2.2.[2-255] is
named Branch 2 Staff. The same procedure is followed for the remainder of the branches
and all the resulting branch staff names are put into an address group called Branch Staff.
All branch staff computers can be referenced with a single name. Similarly, after all the
branch VPNs are created and named Branch 1, Branch 2, etc., they can be combined into
a single zone named Branches.
From here, it’s a simple matter to configure a single policy to handle staff traffic from all
branches to the email and web servers located on the main office DMZ rather than a policy
for each branch office. Should any branch require special treatment, its VPN interface can
be removed from the zone and separate policies tailored to it.
Configuring IPsec VPNs

The VPNs secure data exchanged between each branch and the main office.
To create the main office VPN connection to branch 1 - web-based manager

1 Go to VPN > IPsec > Auto Key (IKE).
3 Enter Branch 1 for the Name.
4 Select Static IP Address for Remote Gateway.
308 01-420-99686-20101026
Concept Example: Library Network Protection IPsec VPN
5 Enter 192.168.23.89 for the IP Address.

6 Select External for the Local Interface.
7 Select Main (ID Protection) for the Mode.
8 Select Preshared Key as the Authentication Method and enter the preshared key.
9 Select advanced and select Enable IPsec Interface Mode.
10 Select OK.
To create the main office VPN connection to branch 1 - CLI

edit Branch1
set remote-qw 192.168.23.89
set interface external
set mode main
set psksecret ########
end
Note: The preshared key is a string of alphanumeric characters and should be unique for
each branch. The preshared key entered at each end of the VPN connection must be
identical.
To configure the Phase 2 portion of the VPN connection to Branch 1 - web-based

manager
3 Enter Main to Branch1 for the Name.
4 Select Branch 1 from the Phase 1 drop down list.
5 Select OK.
The advanced options can be left to their default values.
To configure the Phase 2 portion of the VPN connection to Branch 1 - CLI

edit Branch1
set phase1name Branch1
end
The configuration steps to create the VPN tunnel have to be repeated for each branch
office to be connected in this way. Additional branches use the same Phase 1 settings
except for Name, IP Address, and Preshared Key.
IP Pools
IP Pools allow the traffic leaving an interface to use an IP address different than the one
assigned to the interface itself. One use of IP pools is if the users receive a type of traffic
that cannot be mapped to different ports.Without IP pools, only one user at a time could
send and receive these traffic types.
In the library’s case, a single IP address will be put into an IP pool named
Public_Access_Address. All of the policies that allow traffic from the public access
terminals (including the WiFi access point) will be configured to use this IP pool. The result
is that any traffic from the public access terminals will appear to be coming from the IP
pool address rather than the external interface’s IP address. This is true even though the
public access traffic will flow out of the external interface.
01-420-99686-20101026 309
The purpose is to separate the public access users from the library staff from the point of
view of the Internet at large. Should a library patron abuse the Internet connection by
sending spam or attempting to unlawfully access to a system out on the Internet, any
action taken against the source IP will not inconvenience staff. The library can continue to
function normally while the problem is dealt with.
Configuring IP pools
To add a new IP pool for public access users - web-based manager
1 Go to Firewall > Virtual IP > IP Pool and select Create New.
2 Enter Public_Access_Address for the Name.
3 In the IP Range/Subnet field, enter 192.168.230.64. This address was obtained
from the library’s Internet service provider.
4 Select OK.
To add a new IP pool for public access users - CLI

edit Public_Access_Address
set startip 192.168.230.64
set endip 192.168.230.64
end
Note: Although IP pools are usually created with a range of addresses, an IP pool with a
single address is valid.
User Disclaimer
When using the public terminals or wireless access, the first time a web page external to
the library’s network is requested, a disclaimer will pop up. This is configured in policies
controlling access to the Internet. The user must agree to the stated conditions before they
can continue.
Configuring the user disclaimer

The disclaimer message is set in System > Config > Replacement Message >
Authentication > Disclaimer page. The default message is changed to reference the library
instead of the generic ‘network access provider’ as shown here:
You are about to access Internet content that is not under the control of the library. The
library is therefore not responsible for any of these sites, their content, or their privacy
policies. The library and its staff do not endorse or make any representations about these
sites, or any information, software, or other products or materials found there, or any
results that may be obtained from using them. If you decide to access any Internet
content, you do this entirely at your own risk and you are responsible for ensuring that any
accessed material does not infringe the laws governing, but not exhaustively covering,
copyright, trademarks, pornography, or any other material which is slanderous,
defamatory or might cause offence in any other way.
Do you agree to the above terms?
If the user decides not to agree to the disclaimer, a second message appears and they are
not allowed to communicate with any systems out on the Internet. This second disclaimer
message is set in System > Config > Replacement Message > Authentication > Declined
disclaimer page. The default text of this declined disclaimer is acceptable:
Sorry, network access cannot be granted unless you agree to the disclaimer.
310 01-420-99686-20101026
The enabling this feature will be detailed in the policy configuration steps.
Protection Profiles
Policies control whether traffic flowing through a FortiGate unit from a given source is
allows to travel to a given destination. UTM profiles are selected in each policy and define
how the traffic is examined and what action may be taken based on the results of the
examination. But before they can be selected in a policy, UTM profiles have to be defined.
A brief overview is given for a typical protection profile, and the information required for all
protection profiles, in this example, follows in table form. For complete policy construction
steps, see the FortiGate Administration Guide.
UTM profiles are grouped based on the type of network threat, and added as needed to a
given firewall policy. UTM profiles include:
• AntiVirus
• Protocol Options
• Intrusion Protection
• Web Filter
• Email Filter (antispam)
• Data Leak Prevention
• Application Control
• VoIP
The following tables provide all the settings of all four UTM profiles used in the library
network example. Each table focuses on one section of the specific UTM profile settings.
Note: The settings in the tables listed below are for the library example only. For complete
UTM profile information see the FortiGate Administration Guide.
In this example, if a setting is to be left in the default setting, it is not expanded in the tables
below.
Table 13: UTM profiles, Name and Comments
Profile Name Staff Public Servers Web_Internal

Comment Use with all Use with all Use for policies Use for policies
(optional) policies for traffic policies for traffic allowing the allowing access
from staff from the public public access to to the library web
computers. access or WiFi. the library web server from
server from the catalog terminals.
Internet, or email
server
communication.
The comment field is optional, but recommended. With many profiles, the comment can
be invaluable in quickly identifying profiles.
01-420-99686-20101026 311
Table 14: UTM profiles, Antivirus settings

Virus Scan Enable for HTTP, Enable for HTTP, Enable for HTTP, Disable
FTP, IMAP, POP3, FTP, IMAP, FTP, IMAP,
SMTP, IM and POP3, SMTP, IM POP3, SMTP, IM
NNTP, Logging and NNTP, and NNTP,
Logging Logging
File Filter Disable Disable Disable Disable
Quarantine Enable for HTTP, Enable for HTTP, Enable for HTTP, Disable
FTP, IMAP, POP3, FTP, IMAP, FTP, IMAP,
SMTP, IM and POP3, SMTP, IM POP3, SMTP, IM
NNTP and NNTP and NNTP
Note: The FortiGate unit must have either an internal hard drive or a configured
FortiAnalyzer unit for the Quarantine option to appear.
Table 15: UTM profiles, Protocol Options settings

Pass Fragmented Enable for IMAP, Enable for IMAP, Enable for IMAP, Disable
Emails POP3, and SMTP POP3, and POP3, and
SMTP SMTP
Comfort Clients Enable for HTTP Enable for HTTP Disable Disable
and FTP and FTP
Interval 10 10 10 10
Amount 1 1 1 1
Oversized Pass Pass Pass Pass
File/Email
Threshold Default Default Default Default
Append Signature Disable Disable Disable Disable
Table 16: Protection profiles, FortiGuard Web Filtering/Advanced Filter

Enable FortiGuard Web Disable Enable HTTP* Disable Disable
Filtering
Enable FortiGuard Web Disable Disable Disable Disable
Filtering Overrides
Provide details for Disable Enable HTTP Disable Disable
blocked HTTP 4xx and
5xx errors
Rate images by URL Disable Enable HTTP Disable Disable
(blocked images will be
replaced with blanks)
Allow websites when a Disable Disable Disable Disable
rating error occurs
312 01-420-99686-20101026
Table 16: Protection profiles, FortiGuard Web Filtering/Advanced Filter

Strict Blocking Enable HTTP Enable HTTP Enable HTTP Enable HTTP
Rate URLs by domain and Disable Enable HTTP Disable Disable
IP address
*The Public protection profile has FortiGuard web filtering enabled and set to block
advertising, malware, and spyware categories. Additional categories can be blocked if
required by library policy.
Table 17: Protection profiles, Email Filtering

IP address check Enable for IMAP, Disable Enable for IMAP, Disable
POP3 and SMTP POP3 and SMTP
URL check Enable for IMAP, Disable Enable for IMAP, Disable
E-mail checksum Enable for IMAP, Disable Enable for IMAP, Disable
check POP3 and SMTP POP3 and SMTP
Spam submission Enable for IMAP, Disable Enable for IMAP, Disable
IP address BWL Disable Disable Disable Disable
check
HELO DNS lookup Disable Disable Disable Disable
E-mail address BWL Enable for IMAP, Disable Enable for IMAP, Disable
Return e-mail DNS Enable for IMAP, Disable Enable for IMAP, Disable
Banned word check Disable Disable Disable Disable
Spam Action Tagged Disable Tagged Disable
Tag Location Subject Subject Subject Subject
Tag Format [spam] [spam]
Email is not scanned for spam using the Public protection profile. Users of the public
access terminals will use their own webmail accounts if checking mail, and WiFi
connected users will have their own spam solutions, if desired.
Table 18: Protection profiles, Intrusion Protection

Select all_default Select Select all_default Disable
all_default
You can create your own IPS sensors by going to Intrusion Protection > Signature > IPS
Sensor. The IPS option does not select denial of service (DoS) sensors. For more
information, see the FortiGate Administration Guide.
01-420-99686-20101026 313
Table 19: Protection profiles, Application Control
Profile Staff Public Servers Web_Internal

Block IM Disable for all IM Enable for all IM Disable for all IM Disable for all
protocols protocols protocols IM protocols
Block P2P Block for all P2P Block for all P2P Block for all P2P Block for all
protocols protocols protocols P2P protocols
Staff employees are permitted to use instant messaging while public access users are not.
All users have peer to peer clients blocked.
Staff access
Staff members can access the Internet as well as directly connect to the library web and
email servers.
Since the network uses private addresses and has no internal DNS server, connections to
the web and email servers must be specified by IP address. The private network address
will keep all communication between the server and email client on the local network and
secure against interception on the Internet.
If a staff member attempts to open the library web page or connect to the email server
using either server’s virtual IP or fully qualified domain name, their request goes out over
the Internet, and returns through the FortiGate unit. This method will make their
transmission vulnerable to interception.
The web browsers on staff computers will be configured with the library web page as the
default start page. Staff members’ email software should be configured to use the email
server’s private network IP address rather than the virtual IP or fully qualified domain
name. These two steps will prevent staff from having to remember the servers’ IP
addresses.
Creating firewall policy for staff members

The first firewall policy for main office staff members allows full access to the Internet at all
times. A second policy will allow direct access to the DMZ for staff members. A second
pair of policies are required to allow branch staff members the same access.
The staff firewall policies will all use a protection profile configured specifically for staff
access. Enabled features include virus scanning, spam filtering, IPS, and blocking of all
P2P traffic. FortiGuard web filtering is also used to block advertising, malware, and
spyware sites.
A few users may need special web and catalog server access to update information on
those servers, depending on how they’re configured. Special access can be allowed
based on IP address or user.
A brief overview procedure is given for a typical policy, and the information required for all
staff policies follows in table form. For more detailed information see the FortiGate
Administration Guide.
Step-by-step policy creation example - web-based manager

1 To create a policy to allow main office staff to connect to the Internet, go to Firewall >
Policy > Policy and select Create New.
314 01-420-99686-20101026
2 Fill in the following fields:

• Source interface/Zone
• Source address
• Destination interface/Zone
• Schedule
• Service
• Action
• Enable NAT
• UTM Profile - enable all Staff profiles.
• Log allowed traffic
• Traffic shaping
• User authentication disclaimer
• Comments (optional)
3 Select OK.
The settings required for all staff policies are provided in Table 20.
Table 20: Library staff policies
Main office staff Main office staff Branch office Branch office
connect to the connect to library staff connect to staff connect to
Internet servers the Internet library servers
Source Internal Internal Branches Branches
Interface/Zone
Source All All Branch_Staff Branch_Staff
Address
Destination External DMZ External DMZ
Interface/Zone
Destination All Servers All Servers
Address
Schedule Always Always Always Always
Service All All All All
Action Accept Accept Accept Accept
NAT Enable Enable Enable Enable
UTM Profiles Enable and select Enable and select Enable and select Enable and
(all configured) Staff Staff Staff select Staff
Log Allowed Enable Enable Enable Enable
Traffic
Authentication Disable Disable Disable Disable
Traffic Shaping Disable Disable Disable Disable
User Disable Disable Disable Disable
Authentication
Disclaimer
Comment Main office: staff Main office: staff Branch offices: Branch offices:
(optional) computers computers staff computers staff computers
connecting to the connecting to the connecting to the connecting to the
Internet. library servers. Internet. library servers.
01-420-99686-20101026 315
Catalog terminals
Dedicated computers are provided for the public to search the library catalog. The only
application available on the catalog terminals is a web browser, and the only site the
catalog terminal web browser can access is the library web page, which includes access
to the catalog. The browser is configured to use the library web server’s private network
address as the start page.
Creating firewall policies for catalog terminals

The policy used for the catalog access terminals only allows communication with the DMZ.
Create two new policies, one for main office access and another to allow access from the
branch offices.
The settings required for all catalog terminal policies in this example are provided in
Table 21 on page 316.
For complete policy construction steps, see the FortiGate Administration Guide.
Table 21: Catalog terminal policies
Main office catalog terminals Branch office catalog

connect to web server terminals connect to web
server
Source Interface/Zone port2 Branches
Source Address All Branch_Catalog
Destination Interface/Zone DMZ DMZ
Destination Address Web_Server Web_Server
Schedule Always Always
Service HTTP HTTP
Action Accept Accept
NAT Enable Enable
UTM Profiles Disable Disable
Log Allowed Traffic Enable Enable
Authentication Disable Disable
Traffic Shaping Disable Disable
User Authentication Disable Disable
Disclaimer
Comments (optional) Main office: catalog terminals Branch offices: catalog
connecting to the web server. terminals connecting to the web
server.
Public access terminals

Terminals are provided for library patrons to access the Internet. Protection profile settings
block all instant messaging and peer to peer connections. In addition, library staff can
block individual sites and entire site categories as deemed necessary. Site categories are
blocked using FortiGuard web filtering configured in the protection profile.
316 01-420-99686-20101026
Creating firewall policies for public access terminals

Library users can access the Internet from the public terminals. The public terminal
machines have the library’s web page as the web browser’s default start page. The
address is the web server’s private network IP so the traffic between the terminal and the
web server remains on the library’s network.
The settings required for all public access terminal policies in this example are provided in
Table 22: Public access terminal policies
Main office Public Main office Branch offices Branch offices

access users public access public access public access
connect to Internet users connect to users connect to users connect
web server Internet to web server
Source Port3 Port3 Branches Branches
Interface/Zone
Source Address Main_Public Main_Public Branch_Public Branch_Public
Destination External DMZ External DMZ
Interface/Zone
Destination All Web_Server All Web_Server
Address
Schedule Always Always Always Always
Service All HTTP All HTTP
Action Accept Accept Accept Accept
NAT Enable NAT, enable Enable NAT. Enable NAT, Enable NAT.
Dynamic IP Pool enable Dynamic
and select IP Pool and select
Public_Access_Add Public_Access_A
ress ddress
UTM Profiles Enable and select Enable and select Enable and select Enable and
Public for each type. Web_Internal for Public for each select
each type. type. Web_Internal
for each type.
Log Allowed Enable Enable Enable Enable
Traffic
Authentication Disable Disable Disable Disable
Traffic Shaping Disable Disable Disable Disable
User Enable User Disable Enable User Disable
Authentication Authentication Authentication
Disclaimer Disclaimer and Disclaimer and
leave Redirect URL leave Redirect
field blank. URL field blank.
Comments Main office: public Main office: public Branch offices: Branch offices:
(optional) access terminals access terminals public access public access
connecting to the connecting to the terminals terminals
Internet. library web connecting to the connecting to
server. Internet. the library web
server.
01-420-99686-20101026 317
Wireless access
Wireless access allow library visitors to browse the Internet from their own WiFi-enabled
laptops. The same protection profile is applied to WiFi access as is used with the Public
terminals so IM and P2P are blocked, and all the same FortiGuard web blocking is
applied.
Security considerations
The wireless interface of the FortiWiFi-80CM will have its DHCP server assign IP
addresses to users wanting to connect to the Internet. The FortiWiFi-80CM will also have
its SSID broadcast and set to ‘library’ or something similarly identifiable. Stricter security
would be of limited value because anyone could request and receive access. Also, library
staff would spend significant time serving as technical support to patrons not entirely
familiar with their own equipment. Instead, the firewall policy applied to wireless access
will limit Internet connectivity to the main office’s business hours.This decision will be
reviewed periodically, especially if public access is abused.
Wireless security is configured in System > Wireless > Settings.
The number of concurrent wireless users can be adjusted by reducing or expanding the
range of addresses the DHCP server on the WiFi port has available to assign. Using this
means of limiting users is only partially effective because some users may set a static
address in the same subnet and gain access. To prevent this, configure the IP range
specified in the address name used in the policy to have the same range the DHCP server
assigns. Users can still set a static IP, but the policy will not allow any access.
The wireless DHCP server is configured in System > Network > Interface. Select the edit
icon for the wlan interface.
Creating schedules for wireless access

Library users can access the Internet from the WiFi connection. The policies used for WiFi
incorporates a schedule to limit Internet access to only when the library is open to the
public.
The protection profile used for library users enables virus scanning, IPS, and blocking of
all P2P traffic and IM logins. Spam filtering is not enabled. FortiGuard web filtering is used
to block malware, and spyware sites. Additional categories can be blocked if required by
library policy.
The library hours are:
Mon-Thurs 10am - 9pm

Fri-Sat 10am - 6pm
Sun 1pm - 5pm
Because of the varying library hours through the week, three separate schedules are
required.
To create Monday to Thursday business hours schedule - web-based manager

1 Go to Firewall > Schedule > Recurring and select Create New.
2 Enter Mon-Thurs for the schedule name.
3 Select the check boxes for Monday, Tuesday, Wednesday, and Thursday.
4 Select 10 for the start hour and 00 for the start minute.
5 Select 21 for the end hour and 00 for the end minute.
6 Select OK.
318 01-420-99686-20101026
To create Monday to Thursday business hours schedule - CLI

edit Mon-Thurs
set day monday tuesday wednesday thursday
set start 10:00
set end 21:00
end
To create Friday and Saturday business hours schedule - web-based manager

2 Enter Fri-Sat for the schedule name.
3 Select the check boxes for Friday, and Saturday.
6 Select OK.
To create Friday and Saturday business hours schedule - CLI

edit Fri-Sat
set day friday saturday
set start 10:00
set end 18:00
end
To create Sunday business hours schedule - web-based manager

2 Enter Sun for the schedule name.
3 Select the check box for Sunday.
6 Select OK.
To create Monday to Thursday business hours schedule - CLI

edit Sun
set sunday
set start 13:00
set end 17:00
end
For holidays, special one-time schedules can be created. These schedules allow
specifying the year, month, and day in addition to the hour and minute. Duplicate policies
can be created with one-time schedules to cover holidays. Policies are parsed from top to
bottom so position these special holiday policies above the regular recurring-schedule
policies, otherwise the holiday policies will never come into effect.
One-time schedules are configured in Firewall > Schedule > One-time in the web-based
manager and config firewall schedule onetime in the CLI.
Grouping schedules
01-420-99686-20101026 319
To facilitate easier firewall policy creation for the wifi policies, these policies created above
can be added to a schedule group, thereby having to make one policy with the schedule
group rather than three separate policies.
To create a schedule group - web-based manager

1 Go to Firewall > Schedule > Group.
3 Enter WiFi_Schedule for the Name.
4 Select the schedules from the Available Schedules list.
5 Select the Down-arrow to add them to the Members list.
6 Select OK.
To create a schedule group - CLI

config firewall schedule
edit WiFi_Schedule
set member Mon-Thurs Fri-Sat Sun
end
Creating firewall policies for WiFi access

Two main office WiFi access policies are required. One incorporates the schedules to
cover the entire week and only allow access while the library is open to the public. The
fourth policy allows access to the library web server.
Table 23: Main office WiFi terminal policies
Main office WiFi users Main office WiFi users

connect to Internet connect to web library server
Source Interface/Zone Port4 Port4
Source Address Main_WiFi Main_WiFi
Destination Interface/Zone External DMZ
Destination Address All Web_Server
Schedule Mon-Thurs Always
Service All HTTP
NAT Enable NAT, enable Dynamic IP Enable NAT.
Pool and select
Public_Access_Address
UTM Profile Enable and select Public for Enable and select Web_Internal
each type. for each type.
User Authentication Enable User Authentication Disable
Disclaimer Disclaimer and leave Redirect
URL field blank.
Comments (optional) Main office: WiFi connecting to Main office: WiFi connecting to
the Internet (Mon-Thurs). the library web server.
320 01-420-99686-20101026
Two branch office WiFi access policies are required. One incorporates the schedules to
cover the entire week and only allow access while the library is open to the public. The
fourth policy allows access to the library web server.
The settings required for all branch office WiFi terminal policies in this example are
provided in Table 24 on page 321.
Table 24: Branch office WiFi terminal policies
Branch office WiFi users Branch office WiFi users

connect to Interne connect to web library server
Source Interface/Zone Branches Branches
Source Address Branch_WiFi Branch_WiFi
Destination External DMZ
Interface/Zone
Destination Address All Web_Server
Schedule Mon-Thurs Always
Service All HTTP
NAT Enable NAT, enable Dynamic IP Enable NAT.
Pool and select
Public_Access_Address
UTM Profile Enable and select Public for each Enable and select Web_Internal
type. for each type.
User Authentication Enable User Authentication Disable
Disclaimer Disclaimer and leave Redirect
URL field blank.
Comments (optional) Branch offices: WiFi connecting to Branch offices: WiFi connecting to
the Internet (Fri-Sat). the library web server.
Mail and web servers

Since the branch offices do not have their own email servers, all library staff email is sent
or received using the main office email server. Users in branch offices connect though
their VPN to the main office. Maintenance of a single server is more convenient and cost
effective than each branch office having their own email server.
Staff email software will be set up with the email server’s private network IP address.
Specifying the virtual IP address or domain name would cause the email traffic to loop out
to the Internet and return, allowing the information to be intercepted. Similarly, staff
computers will be pre-configured with the library web server’s internal network IP address
as the start page address.
Creating a virtual IP for the web server

The library has arranged for another external IP address which will be used for the
library’s Internet web presence. A virtual IP configured on the FortiGate will take any traffic
directed to 172.20.16.192 on the Internet and remap it to the web server at 10.100.1.10 on
the library’s network. The 172.20.16.192 address can be registered with the library’s
domain name so anyone on the Internet entering the URL will bring up the library’s page.
01-420-99686-20101026 321
To create a virtual IP for the web server - web-based manager

2 Enter Web_Server_VIP for the Name.
3 Select External from the External Interface drop down.
4 Select Static NAT as the Type
5 Enter 172.20.16.192 as the External IP Address.
6 Enter 10.100.1.10 as the Mapped IP Address.
7 Disable Port Forwarding.
8 Select OK.
To create a virtual IP for the web server - CLI

config firewall vip
edit Web_Server_VIP
set extintf external
set nat-soruce-vip enable
set extip 172.20.16.192
set portforward diable
end
Creating a virtual IP for the email server

Similar to the web server, the library has another external IP address reserved for the
email server. A virtual IP configured on the FortiGate will take any traffic directed to
172.20.16.120 and remap it to the web server at 10.100.1.11 transparently.
To create a virtual IP for the email server - web-based manager

2 Enter Email_Server_VIP for the Name.
3 Select External from the External Interface drop down.
4 Select Static NAT as the Type
5 Enter 172.20.16.120 as the External IP Address.
6 Enter 10.100.1.11 as the Mapped IP Address.
7 Disable Port Forwarding.
8 Select OK.
To create a virtual IP for the email server - CLI

config firewall vip
edit Email_Server_VIP
set extintf external
set nat-soruce-vip enable
set extip 172.20.16.120
set portforward diable
end
322 01-420-99686-20101026
Creating a server service group

Access to and from the web and email servers can be combined into a single policy. The
only difficulty is email servers exchange mail using the SMTP protocol on port 20 and
contact is made with a web server using HTTP on port 80. If the policy is to restrict traffic
to only the required ports, a service group is required.
To create a server service group - web-based manager

1 Go to Firewall > Service > Group and select Create New.
2 Enter Servers in the Group Name field.
3 From the Available Services list, select HTTP
4 Select the right-pointing arrow icon to move HTTP to the Members list.
5 From the Available Services list, select SMTP
6 Select the right-pointing arrow icon to move SMTP to the Members list.
7 Select OK.
To create a server service group - CLI

config firewall service group
edit Servers
set members HTTP SMTP
end
Creating firewall policies to protect email and web servers

An External to DMZ policy is required for access to the web and email servers. Only ports
80 (HTTP) and 25 (SMTP) need to be open.
A DMZ to External policy opening port 25 is required for the library email server to deliver
messages sent to addresses outside the library system.
The settings required for all server policies in this example are provided in Table 25 on
page 323.
Table 25: Server policies

Inbound to web and email servers Outbound from email
server
Source Interface/Zone External DMZ
Source Address All Servers
Destination DMZ External
Interface/Zone
Destination Address Servers All
Schedule Always Always
Service Servers SMTP
NAT Enable Enable
UTM Profiles Enable and select Servers for each Enable and select Servers
type. for each type.
01-420-99686-20101026 323
Table 25: Server policies (Continued)
Inbound to web and email servers Outbound from email

server
User Authentication Disable Disable
Disclaimer
Comments (optional) Incoming web connections and Outbound email server
incoming email delivery from other mail connections.
servers.
The FortiWiFi-80CM
In the main office network, the FortiWiFi-80CM is used to provide WiFi access to main
library patrons with their own WiFi-capable laptops, and as a connection point to all the
main office public access terminals. Since all the policies and protection profiles are
configured on the FortiGate-800 cluster, the FortiWiFi-80CM only has to pass the traffic
along. For this reason, the FortiWiFi-80CM configuration is not complex.
Configuring the main office FortiWiFi-80CM.

The FortiWiFi-80CM is connected as shown in the main branch network topology diagram,
Figure 32 on page 305.
To Configure the operation mode - web-based manager

1 Go to System > Config > Operation and set the unit to Transparent Mode.
Since the FortiWiFi-80CM is within the library’s network, no address translation is
required.
2 Enter 10.100.1.99/255.255.255.0 as the Management IP/Netmask and
10.100.1.3 as the Default Gateway.
3 Select Apply.
You will be disconnected and will have to log in to the FortiWiFi-80CM using the
management IP address.
To Configure the operation mode - CLI

set manageip 10.100.1.99 255.255.255.0
end
Since the FortiWiFi-80CM will not be examining the traffic for content, only a single simple
policy is required.
The settings required for all main office WiFi-80CM policies in this example are provided in
324 01-420-99686-20101026
Concept Example: Library Network Protection Configuring branch offices
Table 26: Main office FortiWiFi-80CM policies
WiFi
Source Interface/Zone Wlan
Source Address All
Destination Interface/Zone Wan1
Schedule Always
Service All
Action Accept
UTM Profiles Disable
Log Allowed Traffic Disable
Authentication Disable
Traffic Shaping Disable
User Authentication Disclaimer Disable
Comments (optional) WiFi users connected to the main office FortiWiFi-80CM
Although the WiFi policy allows access at all times, the policies on the FortiGate-800
cluster restrict Internet access to library business hours.
Configuring branch offices

The three sections of each branch’s network (staff computers, catalog terminals, and
public access terminals) are wired separately to different interfaces on the FortiWiFi-80CM
and cannot access each other.
All external communication is sent to the main office through the VPN by the FortiWiFi-
80CM. After reaching the FortiGate-800, the traffic continues out to the Internet. Inbound
traffic follows the same course back.
Unless they use the email and web server private IP addresses, the computers accessing
the library web page and email server have their connections sent out to the Internet, then
back to the servers.
Topology
The branch network layout is designed to keep the various parts of the network separate.
The staff computers and public terminals are connected to different network interfaces on
the FortiGate, and those interfaces are configured to not allow direct connections between
them. See Table 11 on page 302 for details on permitted access between different network
areas.
Staff computers, email and web servers, public access terminals, WiFi connected systems
are all protected by the FortiGuard service subscription on the FortiGate-800 cluster at the
main branch.
01-420-99686-20101026 325
Configuring branch offices Concept Example: Library Network Protection
Figure 34: Branch office network topology
B .1.
C
ra 2.
10 Int -80
nc [2
54 ls
ern i
-2 na
h -25
10 al Wi F
st 4
Z
]
.[2 mi
af ]
DM4.1
.4 r
.1.
.1 c te
2.1
.1.
10 bli
10
u
P
N2 19 WAN
WA.3.1 2 .1 1
.1 68
10 .23
.89
C
at
al 10
og .1
ac .3.
ce [2-
ss 25
V
P
te 4]
N
rm
Tu
in
n
a
ne
ls
l
Staff access
All staff traffic is routed through the VPN to the main branch. Requests for the email or
web servers are routed to the main office DMZ while general Internet traffic is sent to the
main office then out of the library network to the Internet.
Catalog terminals
Dedicated computers are provided for library patrons to search for books and periodicals
in the library’s catalog. The catalog computers are configured so the only application
available is a web browser, and the only site it can access is the library web page which
includes access to the catalog. Requests are routed through the VPN to the web server in
the library’s main office.
Wireless/public access
Public access terminals and wireless access allow library patrons to access the Internet.
Profile settings deny all instant messaging and peer to peer connections. Also, main
branch library staff can block individual sites and entire site categories as deemed
necessary using FortiGuard web filtering.
Mail and web servers

Branch offices do not have their own email servers. When staff members send or receive
email, their email software connects to the email server in the main library location. This
connection is made through the VPN between the main and branch office. Email server
access is not available from the Internet at large.
326 01-420-99686-20101026
Concept Example: Library Network Protection Configuring branch offices
IPsec VPN
Each branch will have a VPN connection to the main office.
To create the Phase 1 portion of the VPN to the main office - web-based manager
1 Go to VPN > IPsec > Auto Key (IKE) and Select Create Phase 1.
2 In the Name field, enter Main_Office.
3 Select Static IP for Remote Gateway.
4 Enter 192.168.147.30 in the IP Address field.
5 Select WAN1 for the Local Interface.
6 Select Main (ID Protection) for the Mode.
7 Select Preshared Key as the Authentication Method and enter the key in the Preshared
Key field.
8 Select Advanced and select Enable IPsec Interface Mode.
9 Select OK.
To create the Phase 1 portion of the VPN to the main office - CLI
edit Main_Office
set remote-qw 192.168.147.30
set interface WAN1
set mode main
set psksecret ########
end
Note: The preshared key is a string of alphanumeric characters and should be unique for
each branch. The preshared key entered at each end of the VPN connection must be
identical.
To create the Phase 2 portion of the VPN to the main office - web-based manager
2 Enter Branch 1 to Main_Office in the Name field.
3 Select Main_Office from the Phase 1 drop down.
4 Select OK.
To create the Phase 2 portion of the VPN to the main office - CLI
edit Main_Office
set phase1name Main_Office
end
The configuration steps to create the VPN tunnel have to be repeated for each branch
office to be connected in this way. Additional branches use the same Phase 1 settings
except for Name, IP Address, and Preshared Key.
Branch Firewall Policy

All traffic leaving the branch, whether destined for the main office or the Internet, is
controlled by a single policy. Additional policies and routing configured on the FortiGate-
800 cluster at the main office direct the traffic once it arrives there.
01-420-99686-20101026 327
Traffic shaping Concept Example: Library Network Protection
Creating firewall policy for the branch office

The firewall policy for all traffic leaving the branch is sent through the VPN to the main
office. For simplicity, the four network interfaces we use for the internal network (internal,
DMZ, WLAN, and WAN2) are collected into a zone called Inside_Zone. This allows a
single policy to control all the traffic leaving the branch.
Policies are configured in Firewall > Policy > Policy. Interface zones are defined in System
> Network > Zone.
The settings required for all main office WiFi-80CM policies in this example are provided in
Table 27: Branch office FortiWiFi-80CM policies
Branch policy
Source Interface/Zone Inside_Zone
Source Address All
Destination Interface/Zone Main_Office
Schedule Always
Service All
Action Accept
UTM Profiles Disable
Log Allowed Traffic Disable
Authentication Disable
Traffic Shaping Disable
User Authentication Disable
Disclaimer
Comments (optional) Policy to allow branch traffic to
main office.
Traffic shaping
Traffic shaping regulates and prioritizes traffic flow. Guaranteed bandwidth allows a
minimum bandwidth to be reserved for traffic controlled by a policy. Similarly, maximum
bandwidth caps the rate of traffic controlled by the policy. Finally, the traffic controlled by a
policy can be assigned a high, medium or low priority. If there is not enough bandwidth to
transmit all traffic, high priority traffic is processed before medium priority traffic, and
medium before low priority traffic.
Traffic shaping limits are applied only to traffic controlled by the policy they're applied to. If
you do not apply any traffic shaping rules to a policy, the policy is set to high priority by
default. Because of this, traffic shaping is of extremely limited use if applied to some
policies and not others. Enable traffic shaping on all firewall policies.
Because guaranteed bandwidth and maximum bandwidth settings are entirely dependant
on the maximum bandwidth available, the current traffic, and the relative priority of each
type of traffic, defining exact values for each policy is beyond the scope of this document
and traffic shaping is therefore disabled in the example policies.
328 01-420-99686-20101026
Concept Example: Library Network Protection The future
Priorities
Traffic can be assigned high, medium, or low priority depending on importance. Ideally,
traffic will be spread across all three priorities. If all traffic is assigned the same setting,
prioritizing traffic is effectively disabled.
On the library system’s network, there are four types of users accessing two services.
Table 28: Priority of traffic based on source and destination
To servers To Internet
From catalog terminals* high
From Internet† high
From public terminals/WiFi* high low
From staff* high medium
* includes both branch and main office traffic
† includes both inbound and outbound mail server connections
On the library system’s network, the most important traffic is to and from the web and mail
servers. Locating research materials in the library’s collection is extremely difficult without
a working catalog. Email is important to staff members as they maintain important
communication using it.
Staff access to the Internet is of medium priority. Although staff members do need Internet
access, it’s rarely as time-critical as catalog access and email.
Public access to the Internet (both from provided terminals and WiFi connections) are of
the lowest priority.
Although most traffic appears to be of high importance, the most bandwidth is consumed
by Internet access, partly by staff but mostly by the public terminals/WiFi.
With this in mind, a maximum bandwidth value can also be set to limit the bandwidth
consumed by traffic controlled by the public policies. Since the rate entered for maximum
bandwidth applies only to the traffic the policy controls, care has to be taken because
public access traffic is controlled by four policies at any given time. There are branch and
main office policies for public terminals and WiFi connections. The maximum bandwidth
specified in each policy doesn’t take into account any of the others. If you wanted to limit
all public access to the Internet to no more than 200KB/s, you have to divide this value
among the four active policies.
The future
In the design of the example library network detailed in this document, decisions were
made about how it should function when initially installed. Assumptions on how the
network will be used may be incorrect, or usage may change over time. The network can
be modified to facilitate changing usage or new requirements. For example:
Logging
Should the library require detailed logging, a FortiAnalyzer unit can be added to the main
office network. The FortiGate-800 cluster could then be configured to send traffic and
event data to the FortiAnalyzer. Detailed reports can be generated to chart network
utilization, Internet use, and attack activity.
Should the library switch to a VoIP telephone system, reports can also be generated on
telephone usage.
01-420-99686-20101026 329
The future Concept Example: Library Network Protection
Decentralization
If a more decentralized approach is required, Internet access from branch offices could
bypass the main office entirely. Branch FortiGate units would still maintain VPN-encrypted
communication for secure access to the library servers. A FortiManager device would
minimize the administrative effort required to deploy, configure, monitor, and maintain the
security policies across all branch office FortiGate units.
Staff WiFi
The FortiWiFi-80CM supports the creation of virtual WiFi interfaces. If staff members
require WiFi connectivity, a virtual WiFi interface could be created to allow them full
access to staff network resources while maintaining the current limited access provided to
public access users.
Further redundancy
Although the FortiGate-800 cluster ensures minimal downtime with hardware redundancy,
adding another Internet connection from a different ISP can provide connection
redundancy to the main office.
The FortiWiFi-80CM used in the branch offices supports the same High-Availability
clustering as the FortiGate-800 so if needed, the branch offices could enjoy the same HA
protection as the main office without having to upgrade to higher models.
330 01-420-99686-20101026
Chapter 3 System Administration

Basic setup describes the simple setup requirements an Administrator should do to get
the FortiGate unit on the network and enabling the flow of traffic.
Centralized management describes how to configure the FortiGate unit to use
FortiManager as a method of maintaining the device and other features that FortiManager
has to facilitate the administration of multiple devices.
Using the CLI provides an overview of the command line interface (CLI) for FortiOS. If you
are new to the FortiOS CLI, this chapter provides a high level overview of how to use this
method of administration.
Tightening security discusses additional steps to take to further secure your network from
intruders and malicious users.
Best Practices discusses methods to make the various components of FortiOS more
efficient, and offer suggestions on ways to configure the FortiGate unit.
Monitoring describes various methods of collecting log data and tracking traffic flows and
tends.
Multicast forwarding describes multicasting (also called IP multicasting) and how to
configure it on the FortiGate unit.
IPv6 describes the IPv6 integration into FortiOS and how to configure and troubleshoot
issues with this new addressing system.
Virtual LANs discusses their implementation in FortiOS and how to configure and use
them.
PPTP and L2TP describes these VPN types and how to configure them.
Session helpers describes what they are and now to view and configure various session
helpers.
Advanced firewall concepts delves into more detailed firewall information and examples.
Advanced concepts describes more involved administrative topics to enhance network
security and traffic efficiency.
FortiOS™ Handbook v2: System Administration

01-420-99686-20101026 331
System Administration for FortiOS 4.0 MR2
332 01-420-99686-20101026
Basic setup
The FortiGate unit, requires some basic configuration to add it to your network. These
basic steps include assigning IP addresses, adding routing and firewall policies. Until the
administrator completes these steps internetwork and internet traffic will not flow through
the device.
There are two methods of configuring the FortiGate unit: either the web-based manager or
the command line interface (CLI). This chapter will step through both methods to complete
the basic configurations to put the device on your network. Use whichever you are most
comfortable with.
This chapter also provides guidelines for password and administrator best practices as
well as how to upgrade the firmware.
This section includes the following topics:
• Connecting to the FortiGate unit
• Configuring NAT mode
• Configuring transparent mode
• Verifying the configuration
• Additional configuration
• Passwords
• Administrators
• Backing up the configuration
• Firmware
Connecting to the FortiGate unit

To configure, maintain and administer the FortiGate unit, you need to connect to it from a
management computer. There are two ways to do this:
• using the web-based manager: a GUI interface that you connect to using a current web
browser such as Firefox or Internet Explorer.
• using the command line interface (CLI): a command line interface similar to DOS or
UNIX commands that you connect to using SSH or a Telnet terminal.
Connecting to the web-based manager

To connect to the web-based manager, you require:
• a computer with an Ethernet connection
• Microsoft Internet Explorer version 6.0 or higher or any recent version of a common
web browser
• an Ethernet cable.

01-420-99686-20101026 333
Configuring NAT mode Basic setup
To connect to the web-based manager

1 Set the IP address of the management computer to the static IP address
192.168.1.2 with a netmask of 255.255.255.0.
2 Using the Ethernet cable, connect the internal or port 1 interface of the FortiGate unit to
the computer Ethernet connection.
3 Start your browser and enter the address https://192.168.1.99. (remember to
include the “s” in https://).
To support a secure HTTPS authentication method, the FortiGate unit ships with a
self-signed security certificate, which is offered to remote clients whenever they initiate
a HTTPS connection to the FortiGate unit. When you connect, the FortiGate unit
displays two security warnings in a browser.
The first warning prompts you to accept and optionally install the FortiGate unit’s self-
signed security certificate. If you do not accept the certificate, the FortiGate unit
refuses the connection. If you accept the certificate, the FortiGate login page appears.
The credentials entered are encrypted before they are sent to the FortiGate unit. If you
choose to accept the certificate permanently, the warning is not displayed again.
Just before the FortiGate login page is displayed, a second warning informs you that
the FortiGate certificate distinguished name differs from the original request. This
warning occurs because the FortiGate unit redirects the connection. This is an
informational message. Select OK to continue logging in.
4 Type admin in the Name field and select Login.
Connecting to the CLI

The command line interface (CLI) is an alternative method of configuring the FortiGate
unit. The CLI compliments the web-based manager in that it not only has the same
configuration options, but additional settings not available through the web-based
manager.
If you are new to FortiOS or a command line interface configuration tool, see “Using the
CLI” on page 365 for an overview of the CLI, how to connect to it, and how to use it.
FortiExplorer
Included with the FortiGate-60C and FortiWiFi-60C, is FortiExplorer. FortiExplorer is a
Windows-based application that you can use to connect to the FortiGate unit using a USB
cable. FortiExplorer includes a connection wizard to guide you through the basic setup to
configure administrator password, WAN settings, LAN settings, register your unit with
Fortinet. You can also access the web-based manager and the CLI.
FortiExplorer is available on the Tools and Documentation CD included with the
FortiGate-60C or FortiWiFi-60C, and from the Fortinet website at
http://www.fortinet.com/resource_center/product_demos.html.
For information on installing and using FortiExplorer, see the FortiGate-60C or
FortiWiFi-60C QuickStart Guides.
Configuring NAT mode

When configuring NAT mode, you need to define interface addresses and default routes,
and simple firewall policies. You can use the web-based manager or the CLI to configure
the FortiGate unit in NAT mode.

334 01-420-99686-20101026
Basic setup Configuring NAT mode
Configure the interfaces

When shipped, the FortiGate unit has a default address of 192.168.1.99 and a netmask of
255.255.255.0. for either the Port 1 or Internal interface. You need to configure this and
other ports for use on your network.
Note: If you change the IP address of the interface you are connecting to, you must
connect through a web browser again using the new address. Browse to https:// followed by
the new IP address of the interface. If the new IP address of the interface is on a different
subnet, you may have to change the IP address of your computer to the same subnet.
To configure interface for manual addressing - web-based manager

2 Select an interface and select Edit.
3 Enter the IP address and netmask for the interface.
4 Select OK.
To configure an interface for manual addressing - CLI

edit <interface_name>
set mode static
set ip <interface_ipv4mask>
end
To configure DHCP addressing - web-based manager

2 Select the Edit icon for an interface.
3 Select DHCP and complete the following:
Distance Enter the administrative distance, between 1 and 255 for the default
gateway retrieved from the DHCP server. The administrative distance
specifies the relative priority of a route when there are multiple routes to
the same destination. A lower administrative distance indicates a more
preferred route.
Retrieve default gateway Enable to retrieve a default gateway IP address from the DHCP server.
from server
Override internal DNS Enable to use the DNS addresses retrieved from the DHCP server
instead of the DNS server IP addresses on the DNS page on System >
Network > Options. You should also enable Obtain DNS server address
automatically in System > Network > Options.
4 Select OK.
Note: For more information on DHCP, see “DHCP servers and relays” on page 552.
To configure DHCP addressing - CLI

set mode dhcp
set distance <integer>
set defaultgw enable
end

01-420-99686-20101026 335
To configure PPPoE addressing - web-based manager

2 Select an interface and select Edit.
3 Select PPPoE, and complete the following:
Username Enter the username for the PPPoE server. This may have been
provided by your Internet Service Provider.
Password Enter the password for the PPPoE server for the above user name.
Unnumbered IP Specify the IP address for the interface. If your Internet Service Provider
has assigned you a block of IP addresses, use one of these IP
addresses. Alternatively, you can use, or borrow, the IP address of a
configured interface on the router. You may need to do this to minimize
the number of unique IP addresses within your network.
If you are borrowing an IP address, remember the interface must be
enabled, and the Ethernet cable connected to the FortiGate unit.
Initial Disc Timeout Initial discovery timeout in seconds. The amount of time to wait before
starting to retry a PPPoE discovery. To disable the discovery timeout,
set the value to 0.
Initial PADT Timeout Initial PPPoE Active Discovery Terminate (PADT) timeout in seconds.
Use this timeout to shut down the PPPoE session if it is idle for this
number of seconds. Your Internet Service Provider must support PADT.
To disable the PADT timeout, set the value to 0.
Distance Enter the administrative distance, between 1 and 255, for the default
gateway retrieved from the DHCP server. The administrative distance
specifies the relative priority of a route when there are multiple routes to
the same destination. A lower administrative distance indicates a more
preferred route.
Retrieve default gateway Enable to retrieve a default gateway IP address from the DHCP server.
from server The default gateway is added to the static routing table.
Override internal DNS Enable to use the DNS addresses retrieved from the DHCP server
instead of the DNS server IP addresses on the DNS page on System >
Network > Options. On FortiGate-100 units and lower, you should also
enable Obtain DNS server address automatically in System > Network >
Options.
4 Select OK.
To configure PPPoE addressing - CLI

set mode pppoe
set username <pppoe_username>
set password <pppoe_password>
set ipunnumbered <unnumbered_ipv4>
set disc-retry-timeout <pppoe_retry>
set padt-retry-timeout <pppoe_retry>
set distance <integer>
set defaultgw enable
end
Configure a DNS server

A DNS server is a service that converts symbolic node names to IP addresses. A domain
name server (DNS server) implements the protocol. In simple terms, it acts as a phone
book for the Internet. A DNS server matches domain names with the computer IP
address. This enables you to use readable locations, such as fortinet.com when browsing
the Internet.

336 01-420-99686-20101026
Basic setup Configuring NAT mode
The FortiGate unit includes default DNS servers. However, these should be changed to
those provided by your Internet Service Provider. The defaults are DNS proxies and are
not as reliable as those from your ISP.
To configure DNS server settings - web-based manager

2 Enter the IP address of the primary DNS server.
3 Enter the IP address of the secondary DNS server.
4 Select Apply.
Note: For more information on DNS servers see “FortiGate DNS services” on page 553.
To configure DNS server settings - CLI

config system dns
set primary <dns_ipv4>
set secondary <dns_ipv4>
end
Add a default route and gateway

A route provides the FortiGate unit with the information it needs to forward a packet to a
particular destination. A static route causes packets to be forwarded to a destination other
than the default gateway. You define static routes manually. Static routes control traffic
exiting the FortiGate unit. You can specify through which interface the packet will leave
and to which device the packet should be routed.
In the factory default configuration, entry number 1 in the Static Route list is associated
with a destination address of 0.0.0.0/0.0.0.0, which means any/all destinations. This route
is called the “static default route”. If no other routes are present in the routing table and a
packet needs to be forwarded beyond the FortiGate unit, the factory configured static
default route causes the FortiGate unit to forward the packet to the default gateway.
For an initial configuration, you must edit the factory configured static default route to
specify a different default gateway for the FortiGate unit. This will enable the flow of data
through the unit.
To modify the default gateway - web-based manager

2 Select the default route and select Edit.
3 In the Gateway field, type the IP address of the next-hop router where outbound traffic
is directed.
4 If the FortiGate unit reaches the next-hop router through a different interface
(compared to the interface that is currently selected in Device, select the name of the
interface from the Device drop-down list.
5 Select OK.

01-420-99686-20101026 337
To modify the default gateway - CLI

edit <sequence_num>
set gateway <gateway_address_ipv4>
set device <interface_name>
end
Add firewall policies

Firewall policies enable traffic to flow through the FortiGate interfaces. Firewall policies
define how the FortiGate unit processes the packets in a communication session. For the
initial installation, a single firewall policy that enables all traffic to flow through will enable
you to verify your configuration is working. On lower-end units such a default firewall policy
is already in place. For the high-end FortiGate units, you need to add a firewall policy.
The following steps add two policies that allows all traffic through the FortiGate unit, to
enable you to continue testing the configuration on the network.
These steps provide a quick way to get traffic flowing through the FortiGate unit. It is a
very broad policy and not recommended to keep on the system once initial setup and
testing are complete. You will want to add more restrictive firewall policies to provide better
network protection. For more information on firewall policies, see the FortiGate
Fundamentals.
To add an outgoing traffic firewall policy - web-based manager

3 Set the following and select OK.
Source Interface/Zone Select the port connected to the network.

Source Address All
Destination Interface/Zone Select the port connected to the Internet.
Schedule always
Service Any
Action Accept
To add an outgoing traffic firewall policy - CLI

set srcintf <name_str>
set srcaddr <name_str>
set dstintf <name_str>
set dstaddr <name_str>
set schedule always
set service ANY
set action accept
end

338 01-420-99686-20101026
Basic setup Configuring transparent mode
To add an incoming traffic firewall policy - web-based manager

Source Interface Select the port connected to the Internet.

Source Address All
Destination Interface Select the port connected to the network.
Schedule always
Service Any
Action Accept
To add an incoming traffic firewall policy - CLI

set schedule always
set service ANY
set action accept
end
To create an incoming traffic firewall policy, you use the same commands with the
addresses reversed. Firewall policy configuration is the same in NAT and transparent
mode.
These policies allow all traffic through. No UTM profiles have been configured or applied.
Ensure you create additional firewall policies to accommodate your network requirements.
Configuring transparent mode

When configuring transparent mode, you need first to switch to transparent mode. You can
then configure the management IP address, default routes, and firewall policies. You can
use the web-based manager or the CLI to configure the FortiGate unit in transparent
mode.
Switching to transparent mode

First need to switch to transparent mode.
To switch to transparent mode - web-based manager

1 Go to System > Status.
2 Under System Information, select Change beside the Operation Mode.
3 Select Transparent.
4 Enter the Management IP/Netmask address and the Default Gateway address.
The default gateway IP address is required to tell the FortiGate unit where to send
network traffic to other networks.

01-420-99686-20101026 339
Configuring transparent mode Basic setup
5 Select Apply.
To switch to transparent mode

set manageip <manage_ipv4>
set gateway <gw_ipv4>
end
Configure a DNS server

A DNS server is a service that converts symbolic node names to IP addresses. A domain
name server (DNS server) implements the protocol. In simple terms, it acts as a phone
book for the Internet. A DNS server matches domain names with the computer IP
address. This enables you to use readable locations, such as fortinet.com when browsing
the Internet.
DNS server IP addresses are typically provided by your Internet Service Provider.
To configure DNS server settings - web-based manager

2 Enter the IP address of the primary DNS server.
3 Enter the IP address of the secondary DNS server.
4 Select Apply.
To configure DNS server settings - CLI

config system dns
set primary <dns_ipv4>
set secondary <dns_ipv4>
end
Add firewall policies

Firewall policies enable traffic to flow through the FortiGate interfaces. Firewall policies
define the FortiGate unit process the packets in a communication session. You can
configure the firewall policies to allow only specific traffic, users and specific times when
traffic is allowed.
For the initial installation, a single firewall policy that enables all traffic through will enable
you to verify your configuration is working. On lower-end units such a default firewall policy
is already in place. For the higher end FortiGate units, you will need to add a firewall
policy.
The following steps add two policies that allows all traffic through the FortiGate unit, to
enable you to continue testing the configuration on the network.
These steps provide a quick way to get traffic flowing through the FortiGate unit. It is a
very broad policy and not recommended to keep on the system once initial setup and
testing are complete. You will want to add more restrictive firewall policies to provide better
network protection. For more information on firewall policies, see the FortiGate
Fundamentals.

340 01-420-99686-20101026
Basic setup Configuring transparent mode
To add an outgoing traffic firewall policy - web-based manager

Source Interface/Zone Select the port connected to the network.

Source Address All
Destination Interface/Zone Select the port connected to the Internet.
Schedule always
Service Any
Action Accept
To add an outgoing traffic firewall policy - CLI

edit <policy_number>
set schedule always
set service ANY
set action accept
end
To add an incoming traffic firewall policy - web-based manager

Source Interface Select the port connected to the Internet.

Source Address All
Destination Interface Select the port connected to the network.
Schedule always
Service Any
Action Accept

01-420-99686-20101026 341
Verifying the configuration Basic setup
To add an incoming traffic firewall policy - CLI

set schedule always
set service ANY
set action accept
end
To create an incoming traffic firewall policy, you use the same commands with the
addresses reversed.
Firewall policy configuration is the same in NAT/Route mode and transparent mode.
These policies allow all traffic through. No UTM profiles have been configured or applied.
Ensure you create additional firewall policies to accommodate your network requirements.
Verifying the configuration

Your FortiGate unit is now configured and connected to the network. To verify that the
FortiGate unit is connected and configured correctly, use your web browser to browse a
web site, or use your email client to send and receive email.
If you cannot browse to the web site or retrieve/send email from your account, review the
previous steps to ensure all information was entered correctly and try again.
Remember to verify the firewall policies. The firewall policies control the flow of
information through the FortiGate unit. If the policies are not set up correctly, or are too
restrictive, they can prohibit network traffic flow.
Additional configuration
Once the FortiGate unit is connected and traffic can pass through, several more
configuration options are available. While not mandatory, they will help to ensure better
control with the firewall.
Setting the time and date

For effective scheduling and logging, the FortiGate system date and time should be
accurate. You can either manually set the system date and time or configure the FortiGate
unit to automatically keep its time correct by synchronizing with a Network Time Protocol
(NTP) server.
To set the date and time - web-based manager

2 Under System Information > System Time, select Change.
3 Select your Time Zone.
4 Optionally, select Automatically adjust clock for daylight saving changes.
5 Select Set Time and set the FortiGate system date and time.
6 Select OK.

342 01-420-99686-20101026
Basic setup Additional configuration
Set the time and date - CLI

set timezone <zone_value>
set dst enable
end
execute date [<date_str>]
execute time [<time_str>]
Note: If you choose the option Automatically adjust clock for daylight saving changes, the
system time must be manually adjusted after daylight saving time ends.
Using the NTP Server

The Network Time Protocol enables you to keep the FortiGate time in sync with other
network systems. By enabling NTP on the FortiGate unit, FortiOS will check with the NTP
server you select at the configured intervals. This will also ensure that logs and other time-
sensitive settings on the FortiGate unit are correct.
Note: The FortiGate unit maintains its internal clock using the built-in battery. At startup, the
time reported by the FortiGate unit will indicate the hardware clock time, which may not be
accurate. When using NTP, the system time might change after the FortiGate has
successfully obtained the time from a configured NTP server.
Configuring FortiGuard
The FDN is a world-wide network of FortiGuard Distribution Servers (FDS). When the
FortiGate unit connects to the FDN, it connects to the nearest FDS. To do this, all
FortiGate units are programmed with a list of FDS addresses sorted by nearest time zone
according to the time zone configured for the FortiGate unit.
Before you can begin receiving updates, you must register your FortiGate unit from the
Fortinet web page. After which, you need to configure the FortiGate unit to connect to the
FortiGuard Distribution Network (FDN) to update the antivirus, antispam and IPS attack
definitions.
Updating antivirus and IPS signatures

After you have registered your FortiGate unit, you can update antivirus and IPS
signatures. The FortiGuard Center enables you to receive push updates, allow push
update to a specific IP address, and schedule updates for daily, weekly, or hourly intervals.
To update antivirus definitions and IPS signatures

2 Select the expand arrow for AntiVirus and IPS Options to expand the options.
3 Select Update Now to update the antivirus definitions.
If the connection to the FDN is successful, the web-based manager displays a
message similar to the following:
Your update request has been sent. Your database will be updated in
a few minutes. Please check your update page for the status of the
update.
After a few minutes, if an update is available, the FortiGuard Center Services information
on the Dashboard lists new version information for antivirus definitions. The System Status
page also displays new dates and version numbers for the antivirus definitions. Messages
are recorded to the event log indicating whether or not the update was successful or not.

01-420-99686-20101026 343
Passwords Basic setup
Note: Updating antivirus definitions can cause a very short disruption in traffic currently
being scanned while the FortiGate unit applies the new signature database. Schedule
updates when traffic is light, for example overnight, to minimize any disruption.
Passwords
The FortiGate unit ships with a default empty password, that is, there is no password.
You will want to apply a password to prevent anyone from logging into the FortiGate unit
and changing configuration options.
To change the administrator password - web-based manager

2 Select the admin account and select Change Password.
3 Enter a new password and select OK.
Set the admin password - CLI

config system admin
edit admin
set password <admin_password>
end
Password considerations
When changing the password, consider the following to ensure better security.
• Do not make passwords that are obvious, such as the company name, administrator
names or other obvious word or phrase.
• Use numbers in place of letters, for example, passw0rd. Alternatively, spell words with
extra letters, for example, password.
• Include a mixture of letters, numbers, and upper and lower case.
• Use multiple words together, or possibly even a sentence, for example
keytothehighway, or with a combination of the above suggestions.
• Use a password generator.
• Change the password regularly and always use a code unique (not a variation of the
existing password by adding a “1” to it, for example password, password1).
• Write the password down and store it in a safe place away from the management
computer, in case you forget it.
• Alternatively, ensure at least two people know the password in the event that one
person becomes ill, is away on vacation or leaves the company. Alternatively have two
different admin logins.
Password policy
The FortiGate unit includes the ability to enforce a password policy for administrator login.
with the policy, you can enforce regular changes and specific criteria for a password
including:
• minimum length between 8 and 32 characters.
• if the password must contain uppercase (A, B, C) and/or lowercase (a, b, c) characters.
• if the password must contain numbers (1, 2, 3).

344 01-420-99686-20101026
Basic setup Administrators
• if the password must contain non-alphanumeric characters (!, @, #, $, %, ^, &, *, ().

• where the password applies (admin or IPsec or both).
• the duration of the password before a new one must be specified.
To apply a password policy - web-based manager

1 Go to System > Admin > Settings.
2 Select Enable and configure the settings as required.
To apply a password policy - CLI

config system password-policy
set status enable
Configure the other settings as required.
Forgotten password?
It happens that the administrator of the FortiGate unit leaves the company and does not
have the opportunity to provide the administrative password or forgets. Or you simply
forgot the password.
In the event you lose or forget the password, you need to contact Customer Support for
the steps required to reset the password. For information on contacting Customer
Support, see the Support web site at web site at https://support.fortinet.com.
Administrators
By default, the FortiGate unit has a super administrator called “admin”. This user login
cannot be deleted and always has ultimate access over the FortiGate unit. As well you can
add administrators for various functions and VDOMs. Each one can have their own
username and password and set of access privileges.
To add an administrator - web-based manager

3 Enter the administrator name.
4 Select the type of account it will be. If you select Remote, the FortiGate can reference
a RADIUS, LDAP or TACAS+ server.
5 Enter the password for the user. This may be a temporary password that the
administrator can change later for added security.
6 Select OK.
To add an administrator - CLI

config system admin
edit <admin_name>
set password <password>
set accprofile <profile_name>
end

01-420-99686-20101026 345
Backing up the configuration Basic setup
Trusted hosts
Setting trusted hosts for an administrators increases limiting what computers an
administrator can log in from. When you identify a trusted host, the FortiGate unit will only
accept the administrator’s login from the configured IP address. Any attempt to log in with
the same credentials from any other IP address will be dropped. To ensure the
administrator has access from different locations, you can enter up to ten IP addresses.
Ideally, this should be kept to a minimum. For higher security, use an IP address with a net
mask of 255.255.255.255, and enter an IP address (non-zero) in each of the three default
trusted host fields.
Trusted hosts are configured when adding a new administrator by going to System >
Admin > Administrators in the web-based manager or config system admin in the
CLI.
The trusted hosts apply to the web-based manager, ping, snmp and the CLI when
accessed through Telnet or SSH. CLI access through the console port is not affected.
Also ensure all entries contain actual IP addresses, not the default 0.0.0.0.
Backing up the configuration

Once you configure the FortiGate unit and it is working correctly, it is extremely important
that you back up the configuration. In some cases, you may need to reset the FortiGate
unit to factory defaults, or perform a TFTP upload of the firmware. In these instances, the
configuration on the device will be lost.
Always back up the configuration and store it on the management computer or off site. It is
also recommended that once the FortiGate is configured, and any further changes are
made, that you back up the configuration immediately, to ensure you have the most
current configuration available.
You have the option to save the configuration file to various locations including the local
PC, USB key, FTP and TFTP site. The latter two are configurable through the CLI only.
To back up the FortiGate configuration - web-based manager

2 On the System Information widget, select Backup for the System Configuration.
3 Select to back up to your Local PC, FortiManager or to a USB key.
The USB Disk option will be grayed out if no USB drive is inserted in the USB port. The
FortiManager option will not be available if the FortiGate unit is not being managed by
a FortiManager system.
4 Select Encrypt configuration file.
Encryption must be enabled on the backup file to back up VPN certificates.
5 Enter a password and enter it again to confirm it. You will need this password to restore
the file.
6 Select Backup.
7 The web browser will prompt you for a location to save the configuration file. The
configuration file will have a .conf extension.

346 01-420-99686-20101026
Basic setup Backing up the configuration
To back up the FortiGate configuration - CLI

execute backup config management-station <comment>
… or …
execute backup config usb <backup_filename> [<backup_password>]
… or for FTP, note that port number, username are optional depending on the FTP site…
execute backup config ftp <backup_filename> <ftp_server>
[<port>] [<user_name>] [<password>]
… or for TFTP …
execute backup config tftp <backup_filename> <tftp_server> <password>
It is a good practice to backup the FortiGate configuration after any modification to any of
the FortiGate settings. Alternatively, before performing an upgrade to the firmware, ensure
you back up the configuration before upgrading. Should anything happen during the
upgrade that changes the configuration, you can easily restore the saved configuration.
Download a configuration file using SCP

You can use secure copy protocol (SCP) to download the configuration file from the
FortiGate unit as an alternative method of backing up the configuration file. This is done by
enabling SCP for and administrator account and enabling SSH on a port used by the SCP
client application to connect to the FortiGate unit.
Enable SCP
To enable SCP - web-based manager
2 Select Enable SCP.
3 Select Apply.
To enable SCP - CLI:

set admin-scp enable
end
Enable SSH access on the interface

SCP uses the SSH protocol to provide secure file transfer. The interface you use for
administration must allow SSH access.
To enable SSH - web-based manager:

2 Select the interface you use for administrative access and select Edit.
3 In the Administrative Access section, select SSH.
4 Select OK.
To enable SSH - CLI:

set allowaccess ping https ssh
end

01-420-99686-20101026 347
Backing up the configuration Basic setup
Note: When adding to, or removing a protocol, you must type the entire list again. For
example, if you have an access list of HTTPS and SSH, and you want to add PING, typing:
...only PING will be set. In this case, you must type...
Using the SCP client

The FortiGate unit downloads the configuration file as sys_conf. Use the following
syntax to download the file:
Linux
scp admin@<FortiGate_IP>:sys_config <location>
Windows
pscp admin@<FortiGate_IP>:sys_config <location>
These examples show how to download the configuration file from a FortiGate-100A, at IP
address 172.20.120.171, using Linux and Windows SCP clients.
Linux client example

To download the configuration file to a local directory called ~/config, enter the following
command:
scp admin@172.20.120.171:sys_config ~/config
Enter the admin password when prompted.
Windows client example

To download the configuration file to a local directory called c:\config, enter the following
command in a Command Prompt window:
pscp admin@172.20.120.171:sys_config c:\config
Enter the admin password when prompted.
SCP public-private key authentication

SCP authenticates itself to the FortiGate unit in the same way as an administrator using
SSH accesses the CLI. Instead of using a password, you can configure the SCP client and
the FortiGate unit with a public-private key pair.
To configure public-private key authentication

1 Create a public-private key pair using a key generator compatible with your SCP client.
2 Save the private key to the location on your computer where your SSH keys are stored.
This step depends on your SCP client. The Secure Shell key generator automatically
stores the private key.
3 Copy the public key to the FortiGate unit using the CLI commands:
config system admin
edit admin
set ssh-public-key1 "<key-type> <key-value>"
end

348 01-420-99686-20101026
Basic setup Firmware
<key-type> must be the ssh-dss for a DSA key or ssh-rsa for an RSA key. For the
<key-value>, copy the public key data and paste it into the CLI command.
If you are copying the key data from Windows Notepad, copy one line at a time and
ensure that you paste each line of key data at the end of the previously pasted data. As
well:
• Do not copy the end-of-line characters that appear as small rectangles in Notepad.
• Do not copy the ---- BEGIN SSH2 PUBLIC KEY ---- or Comment: “[2048-
bit dsa,...]” lines.
• Do not copy the ---- END SSH2 PUBLIC KEY ---- line.
4 Type the closing quotation mark and press Enter.
Your SCP client can now authenticate to the FortiGate unit based on SSH keys rather than
the administrator password.
Restoring a configuration
Should you need to restore a configuration file, use the following steps.
To restore the FortiGate configuration - web-based manager

2 On the System Information widget, select Restore for the System Configuration.
3 Select to upload the configuration file to be restored from your Local PC or a USB key.
The USB Disk option will be grayed out if no USB drive is inserted in the USB port. The
FortiManager option will not be available if the FortiGate unit is not being managed by
a FortiManager system.
4 Enter the path and file name of the configuration file, or select Browse to locate the file.
5 Enter a password if required.
6 Select Restore.
To back up the FortiGate configuration - CLI

execute restore config management-station normal 0
… or …
execute restore config usb <filename> [<password>]
… or for FTP, note that port number, username are optional depending on the FTP site…
execute backup config ftp <backup_filename> <ftp_server>
[<port>] [<user_name>] [<password>]
… or for TFTP …
execute backup config tftp <backup_filename> <tftp_server> <password>
The FortiGate unit will load the configuration file and restart. Once the restart has
completed, verify that the configuration has been restored.
Firmware
Fortinet periodically updates the FortiGate firmware to include new features and address
issues. After you have registered your FortiGate unit, you can download firmware updates
from the support web site, http://support.fortinet.com.

01-420-99686-20101026 349
Firmware Basic setup
You can also use the instructions in this chapter to revert, to a previous version. The
FortiGate unit includes a number of firmware installation options that enables you to test
new firmware without disrupting the existing installation, and load it from different locations
as required.
Fortinet issues patch releases--maintenance release builds that resolve important issues.
Fortinet strongly recommends reviewing the release notes for the patch release, as well
as testing and reviewing the patch release before upgrading the firmware. Follow the
steps below:
• download and review the release notes for the patch release
• download the patch release
• back up the current configuration
• test the patch release until you are satisfied that it applies to your configuration.
Installing a patch release without reviewing release notes or testing the firmware may
result in changes to settings or unexpected issues.
Only FortiGate admin user and administrators whose access profiles contain system read
and write privileges can change the FortiGate firmware.
Downloading firmware
Firmware images for all FortiGate units is available on the Fortinet Customer Support web
site. You must register your FortiGate unit to access firmware images. Register the
FortiGate unit by visiting http://support.fortinet.com and select Product Registration.
To download firmware
1 Log into the site using your user name and password.
2 Go to Firmware Images > FortiGate.
3 Select the most recent FortiOS version.
4 Locate the firmware for your FortiGate unit, right-click the link and select the Download
option for your browser.
Note: Always review the Release Notes for a new firmware release before installing. The
Release Notes can include information that is not available in the regular documentation.
Upgrading the firmware - web-based manager

Installing firmware replaces your current antivirus and attack definitions, along with the
definitions included with the firmware release you are installing. After you install new
firmware, make sure that antivirus and attack definitions are up to date.
Note: Always remember to back up your configuration before doing any firmware upgrade
or downgrade.
To upgrade the firmware

1 Download the firmware image file to your management computer.
2 Log into the web-based manager as the admin administrative user.
4 Under System Information > Firmware Version, select Update.

350 01-420-99686-20101026
5 Type the path and filename of the firmware image file, or select Browse and locate the
file.
6 Select OK.
version, restarts, and displays the FortiGate login. This process takes a few minutes.
Reverting to a previous version

The following procedures revert the FortiGate unit to its factory default configuration and
deletes any configuration settings.
Before beginning this procedures, ensure you back up the FortiGate unit configuration.
If you are reverting to a previous FortiOS version, you might not be able to restore the
previous configuration from the backup configuration file.
Note: Installing firmware replaces the current antivirus and attack definitions, along with the
Note: To use this procedure, you must log in using the admin administrator account, or an
administrator account that has system configuration read and write privileges.
To revert to a previous firmware version

1 Copy the firmware image file to the management computer.
2 Log into the FortiGate web-based manager.
4 Under System Information > Firmware Version, select Update.
5 Type the path and filename of the firmware image file, or select Browse and locate the
file.
6 Select OK.
The FortiGate unit uploads the firmware image file, reverts to the old firmware version,
resets the configuration, restarts, and displays the FortiGate login. This process takes
a few minutes.
7 Log into the web-based manager.
8 Restore your configuration.
For information about restoring your configuration see “Restoring a configuration” on
page 349.
Upgrading the firmware - CLI

Installing firmware replaces your current antivirus and attack definitions, along with the
firmware, make sure that antivirus and attack definitions are up to date. You can also use
the CLI command execute update-now to update the antivirus and attack definitions.
For more information, see the FortiGate Administration Guide.
Before you begin, ensure you have a TFTP server running and accessible to the FortiGate
unit.

01-420-99686-20101026 351
To upgrade the firmware using the CLI

1 Make sure the TFTP server is running.
3 Log into the CLI.
4 Make sure the FortiGate unit can connect to the TFTP server.
You can use the following command to ping the computer running the TFTP server. For
example, if the IP address of the TFTP server is 192.168.1.168:
execute ping 192.168.1.168
FortiGate unit:
execute restore image tftp <filename> <tftp_ipv4>
Where <name_str> is the name of the firmware image file and <tftp_ip4> is the IP
address of the TFTP server. For example, if the firmware image file name is
image.out and the IP address of the TFTP server is 192.168.1.168, enter:
execute restore image tftp image.out 192.168.1.168
The FortiGate unit responds with the message:
6 Type y.
version, and restarts. This process takes a few minutes.
8 Update antivirus and attack definitions, by entering:
execute update-now
USB Auto-Install
The USB Auto-Install feature automatically updates the FortiGate configuration file and
firmware image file on a system reboot. Also, this feature provides you with an additional
backup if you are unable to save your system settings before shutting down or rebooting
your FortiGate unit.
Note: You need an unencrypted configuration file for this feature. Also the required files,
must be in the root directory of the USB key.
To configure the USB Auto-Install - web-based manager

1 Go to System > Maintenance > Advanced.
2 Select the following:
• On system restart, automatically update FortiGate configuration file if default file
name is available on the USB disk.
• On system restart, automatically update FortiGate firmware image if default image
is available on the USB disk.
3 Enter the configuration and image file names or use the default configuration filename
(system.conf) and default image name (image.out).

352 01-420-99686-20101026
4 The default configuration filename should show in the Default configuration file name
field.
5 Select Apply.
To configure the USB Auto-Install using the CLI

1 Log into the CLI.
2 Enter the following command:
config system auto-install
set default-config-file <filename>
set auto-install-config {enable | disable}
set default-image-file <filename>
set auto-install-image {enable | disable}
end
Reverting to a previous version

This procedure reverts the FortiGate unit to its factory default configuration and deletes
IPS custom signatures, web content lists, email filtering lists, and changes to replacement
messages.
Before beginning this procedure, it is recommended that you:
• back up the FortiGate unit system configuration using the command
execute backup config
• back up the IPS custom signatures using the command execute
backup ipsuserdefsig
• back up web content and email filtering lists
To use the following procedure, you must have a TFTP server the FortiGate unit can
connect to.
To revert to a previous firmware version using the CLI

1 Make sure the TFTP server is running
2 Copy the firmware image file to the root directory of the TFTP server.
3 Log into the FortiGate CLI.
4 Make sure the FortiGate unit can connect to the TFTP server execute by using the
execute ping command.
FortiGate unit:
execute restore image tftp <name_str> <tftp_ipv4>
Where <name_str> is the name of the firmware image file and <tftp_ip4> is the IP
address of the TFTP server. For example, if the firmware image file name is
imagev28.out and the IP address of the TFTP server is 192.168.1.168, enter:
execute restore image tftp image28.out 192.168.1.168
The FortiGate unit responds with this message:

01-420-99686-20101026 353
6 Type y.
The FortiGate unit uploads the firmware image file. After the file uploads, a message
similar to the following appears:
Get image from tftp server OK.
Check image OK.
This operation will downgrade the current firmware version!
7 Type y.
The FortiGate unit reverts to the old firmware version, resets the configuration to
factory defaults, and restarts. This process takes a few minutes.
9 To restore your previous configuration, if needed, use the command:
execute restore config <name_str> <tftp_ip4>
10 Update antivirus and attack definitions using the command:
execute update-now.
Installing firmware from a system reboot using the CLI

This procedure installs a firmware image and resets the FortiGate unit to default settings.
You can use this procedure to upgrade to a new firmware version, revert to an older
firmware version, or re-install the current firmware.
To use this procedure, you must connect to the CLI using the FortiGate console port and a
RJ-45 to DB-9, or null modem cable.
This procedure reverts the FortiGate unit to its factory default configuration.
For this procedure you install a TFTP server that you can connect to from the FortiGate
internal interface. The TFTP server should be on the same subnet as the internal
interface.
Before beginning this procedure, ensure you back up the FortiGate unit configuration.
If you are reverting to a previous FortiOS version, you might not be able to restore the
previous configuration from the backup configuration file.
Note: Installing firmware replaces your current antivirus and attack definitions, along with
the definitions included with the firmware release you are installing. After you install new
To install firmware from a system reboot

1 Connect to the CLI using the RJ-45 to DB-9 or null modem cable.
4 Make sure the internal interface is connected to the same network as the TFTP server.
5 To confirm the FortiGate unit can connect to the TFTP server, use the following
command to ping the computer running the TFTP server. For example, if the IP
address of the TFTP server is 192.168.1.168:
execute ping 192.168.1.168
6 Enter the following command to restart the FortiGate unit.

354 01-420-99686-20101026
execute reboot
The FortiGate unit responds with the following message:
This operation will reboot the system!
7 Type y.
As the FortiGate unit starts, a series of system startup messages appears. When the
following messages appears:
Press any key to display configuration menu..........
Immediately press any key to interrupt the system startup.
Note: You have only 3 seconds to press any key. If you do not press a key soon enough,
the FortiGate unit reboots and you must log in and repeat the execute reboot command.
If you successfully interrupt the startup process, the following messages appears:
[G]: Get firmware image from TFTP server.
[F]: Format boot device.
[B[: Boot with backup firmware and set as default
[Q]: Quit menu and continue to boot with default
firmware.
8 Type G to get to the new firmware image form the TFTP server.
9 Type the address of the TFTP server and press Enter:
10 Type an IP address the FortiGate unit can use to connect to the TFTP server. The IP
address can be any IP address that is valid for the network the interface is connected
to. Make sure you do not enter the IP address of another device on this network.
11 Enter the firmware image filename and press Enter.
The TFTP server uploads the firmware image file to the FortiGate unit and a message
similar to the following appears:
saving: [D/B/R]
12 Type D.
The FortiGate unit installs the new firmware image and restarts. The installation might
take a few minutes to complete.

01-420-99686-20101026 355
Backup and Restore from a USB key

Use a USB key to either backup a configuration file or restore a configuration file. You
should always make sure a USB key is properly install before proceeding since the
FortiGate unit must recognize that the key is installed in its USB port.
Note: You can only save VPN certificates if you encrypt the file. Make sure the
configuration encryption is enabled so you can save the VPN certificates with the
configuration file. An encrypted file is ineffective if selected for the USB Auto-Install feature.
To backup configuration using the CLI

1 Log into the CLI.
2 Enter the following command to backup the configuration files:
exec backup config usb <filename>
3 Enter the following command to check the configuration files are on the key:
exec usb-disk list
To restore configuration using the CLI

1 Log into the CLI.
2 Enter the following command to restore the configuration files:
exec restore image usb <filename>
The FortiGate unit responds with the following message:
3 Type y.
Testing new firmware before installing

FortiOS enables you to test a new firmware image by installing the firmware image from a
system reboot and saving it to system memory. After completing this procedure, the
FortiGate unit operates using the new firmware image with the current configuration. This
new firmware image is not permanently installed. The next time the FortiGate unit restarts,
it operates with the originally installed firmware image using the current configuration. If
the new firmware image operates successfully, you can install it permanently using the
procedure “Upgrading the firmware - web-based manager” on page 350.
To use this procedure, you must connect to the CLI using the FortiGate console port and a
RJ-45 to DB-9 or null modem cable. This procedure temporarily installs a new firmware
image using your current configuration.
For this procedure you install a TFTP server that you can connect to from the FortiGate
internal interface. The TFTP server should be on the same subnet as the internal
interface.
To test the new firmware image

1 Connect to the CLI using a RJ-45 to DB-9 or null modem cable.
4 Make sure the FortiGate unit can connect to the TFTP server using the execute
ping command.

356 01-420-99686-20101026
5 Enter the following command to restart the FortiGate unit:

execute reboot
6 As the FortiGate unit reboots, press any key to interrupt the system startup. As the
FortiGate unit starts, a series of system startup messages appears.
When the following messages appears:
Press any key to display configuration menu....
7 Immediately press any key to interrupt the system startup.
Note: You have only 3 seconds to press any key. If you do not press a key soon enough,
the FortiGate unit reboots and you must login and repeat the execute reboot command.
If you successfully interrupt the startup process, the following messages appears:
[G]: Get firmware image from TFTP server.
[F]: Format boot device.
[B[: Boot with backup firmware and set as default
[Q]: Quit menu and continue to boot with default
firmware.
8 Type G to get the new firmware image from the TFTP server.
9 Type the address of the TFTP server and press Enter:
10 Type an IP address of the FortiGate unit to connect to the TFTP server.
The IP address must be on the same network as the TFTP server, but make sure you
do not use the IP address of another device on the network.
11 Enter the firmware image file name and press Enter.
The TFTP server uploads the firmware image file to the FortiGate unit and the
following appears.
saving: [D/B/R]
12 Type R.
The FortiGate image is installed to system memory and the FortiGate unit starts
running the new firmware image, but with its current configuration.
You can test the new firmware image as required. When done testing, you can reboot the
FortiGate unit, and the FortiGate unit will resume using the firmware that was running
before you installed the test firmware.

01-420-99686-20101026 357

358 01-420-99686-20101026
Centralized management
Administering one or two FortiGate units is fairly simple enough, especially when they are
in the same room or building. However, if you are administering many FortiGate units that
may be located in locations in a large geographical area, or in the world, you will need a
more efficient method of maintaining firmware upgrades, configuration changes and
updates.
The FortiManager family of appliances supply the tools needed to effectively manage any
size Fortinet security infrastructure, from a few devices to thousands of appliances. The
appliances provide centralized policy-based provisioning, configuration, and update
management. They also offer end-to-end network monitoring for added control. Managers
can control administrative access and simplify policy deployment using role-based
administration to define user privileges for specific management domains and functions by
aggregating collections of Fortinet appliances and agents into independent management
domains. By locally hosting security content updates for managed devices and agents,
FortiManager appliances minimize Web filtering rating request response time and
maximize network protection.
This chapter describes the basics of using FortiManager as an administration tool for
multiple FortiGate units. It describes the basics of setting up a FortiGate unit in
FortiManager, and some key management features you can use within FortiManager to
manage the FortiGate unit. For full details and instructions on FortiManager, see the
FortiManager Administration Guide.
This chapter includes the following sections:
• Adding a FortiGate to FortiManager
• Configuration through FortiManager
• Firmware updates
• FortiGuard
• Backup and restore configurations
• Administrative domains
Adding a FortiGate to FortiManager

Before you can use the FortiManager unit to maintain a FortiGate, you need to add it to
the FortiManager unit. To do this requires configuration on both the FortiGate and
FortiManager.
FortiGate configuration
These steps ensure that the FortiGate unit will be able to receive updated antivirus and
IPS updates, and allow remote management through the FortiManager system. You can
add a FortiGate unit whether it is running in either NAT/Route mode or Transparent mode.

01-420-99686-20101026 359
Configuration through FortiManager Centralized management
Note: If you have not already done so, register the FortiGate unit by visiting
http://support.fortinet.com and select Product Registration. By registering your
Fortinet unit, you will receive updates to threat detection and prevention
databases (Antivirus, Intrusion Detection, etc.) and will also ensure your access to
technical support.
You must enable the FortiGate management option so the FortiGate unit can
accept management updates to firmware, antivirus signatures and IPS signatures.
To configure the FortiGate unit - web-based manager

1 Log in to the FortiGate unit.
2 Go to System > Admin > Central Management.
3 Select Enable FortiManager.
4 Enter the IP address for the FortiManager.
5 Select Apply.
The FortiManager ID appears in the Trusted FortiManager table, and can now be
managed by the FortiManager unit, once you add it to the Device Manager.
To configure the FortiGate unit - CLI

config system central-mamagement
set status enable
set fmg <ip_address>
end
FortiManager configuration
After enabling Central Management and indicating the FortiManager unit that will provide
the management of the FortiGate unit, you can add it to the Device Manager in the
FortiManager web-based manager.
To add the FortiGate unit to the Device Manager in FortiManager

1 Log in to the FortiManager unit.
2 Select Add Device from the top toolbar.
3 Enter the IP address of the FortiGate unit.
4 Enter the Name of the device.
This can be the model name, or functional name, such as West Building, or Accounting
Firewall.
5 Enter the remaining information as required.
6 Select OK.
Configuration through FortiManager

With the FortiManager system, you can monitor and configure multiple FortiGate units
from one location and log in. Within the FortiManager system, you can view a FortiGate
unit and it’s web-based manager from the Device Manager. From there you can make the
usual configuration updates and changes, without having to log in and out of multiple
FortiGate units.

360 01-420-99686-20101026
Centralized management Firmware updates
FortiManager enables you to complete the configuration, by going to the Device Manager,
selecting the FortiGate unit and using the same menu structure and pages as you would
see in the FortiGate web-based manager. All changes to the FortiGate configuration are
stored locally on the FortiManager unit until you synchronize with the FortiGate unit.
Configuration and installation status

From within the FortiManager, you can view the device status the same way you can on
the FortiGate web-based manager. An additional dashboard widget, Configuration and
Installation Status, provides real-time information on the configuration on the
FortiManager compared to the FortiGate.
Figure 35: FortiGate configuration and installation status widget
The Configuration Change Status indicates when the FortiGate configuration on

FortiManager has changed and requires update to the FortiGate unit. Select Install Now to
synchronize the changes. Select Installation Preview to review the changes, in CLI format,
that will be uploaded to the FortiGate unit.
Global objects
If you are maintaining a number of FortiGate units within a network, many of the policies
and configuration elements will be the same across the corporation. In these instances,
the adding and editing of many of the same policies will be come a tedious and
error-prone activity. With FortiManager global objects, this level of configuration is
simplified.
A global object is an object that is not associated specifically with one device or group.
Global objects includes firewall policies, a DNS server, VPN, and IP pools.
The Global Objects window is where you can configure global objects and copy the
configurations to the FortiManager device database for a selected device or a group of
devices. You can also import configurations from the FortiManager device database for a
selected device and modify the configuration as required.
When configuring or creating a global policy object the interface, prompts, and fields are
the same as creating the same object on a FortiGate unit using the FortiGate web-based
manager.
Firmware updates
FortiManager can also be the source where firmware updates are performed for multiple
FortiGate units, saving time rather than upgrading each FortiGate unit individually.
The FortiManager unit stores local copies of firmware images by either downloading these
images from the Fortinet Distribution Network (FDN) or by accepting firmware images that
you upload from your management computer.

01-420-99686-20101026 361
FortiGuard Centralized management
If you are using the FortiManager unit to download firmware images from the FDN,
FortiManager units first validate device licenses. The FDN validates support contracts and
provides a list of currently available firmware images. For devices with valid Fortinet
Technical Support contracts, you can download new firmware images from the FDN,
including release notes.
After firmware images have been either downloaded from the FDN or imported to the
firmware list, you can either schedule or immediately upgrade/downgrade a device or
group’s firmware.
See the FortiManager Administration Guide for more information on updating the
FortiGate firmware using the FortiManager central management.
FortiGuard
FortiManager can also connect to the FortiGuard Distribution Network to receive push
updates for IPS signatures and antivirus definitions. These updates can then be used to
update multiple FortiGate units throughout an organization. By the FortiManager as the
host for updates, bandwidth use is minimized by downloading to one source instead of
many.
To receive IPS and antivirus updates from FortiManager, indicate an alternate IP address
on the FortiGate unit.
To configure updates from FortiManager

2 Select AntiVirus and IPS Options to expand the options.
3 Select the checkbox next to Use override server address and enter the IP address of
the FortiManager unit.
4 Select Apply.
Backup and restore configurations

FortiManager can also store configuration files for backup and restore purposes.
FortiManager also enables you to save revisions of configuration files. For example, if you
are trying new firmware or rolling out new configurations of firewall policies and so on, you
can save various iterations of the configuration. Should a configuration fail, you can
quickly load an earlier configuration that is known to be stable until corrections can be
made.
FortiManager also enables you to view differences between different configurations to
view where changes have been made.
Administrative domains
FortiManager administrative domains enable the admin administrator to create groupings
of devices for configured administrators to monitor and manage. FortiManager can
manage a large number of Fortinet appliances. This enables administrators to maintain
managed devices specific to their geographic location or business division. This also
includes FortiGate units with multiple configured VDOMs.

362 01-420-99686-20101026
Centralized management Administrative domains
Each administrator is tied to an administrative domain (ADOM). When that particular

administrator logs in, they see only those devices or VDOMs configured for that
administrator and ADOM. The one exception is the admin administrator account which
can see and maintain all administrative domains and the devices within those domains.
Administrative domains are not enabled by default, and enabling and configuring the
domains can only be performed by the admin administrator. The maximum number of
administrative domains you can add depends on the FortiManager system model.
See the FortiManager Administration Guide for information on the maximums for each
model.

01-420-99686-20101026 363
Administrative domains Centralized management

364 01-420-99686-20101026
Using the CLI
The command line interface (CLI) is an alternative configuration tool to the web-based
manager.
Both can be used to configure the FortiGate unit. While the configuration, in the web-
based manager, a point-and-click method, the CLI, would require typing commands, or
upload batches of commands from a text file, like a configuration script.
If you are new to Fortinet products, or if you are new to the CLI, this section can help you
to become familiar.
• Connecting to the CLI
• Command syntax
• Sub-commands
• Permissions
• Tips
Connecting to the CLI

You can access the CLI in two ways:
• Locally — Connect your computer directly to the FortiGate unit’s console port.
• Through the network — Connect your computer through any network attached to one
of the FortiGate unit’s network ports. The network interface must have enabled Telnet
or SSH administrative access if you will connect using an SSH/Telnet client, or
HTTP/HTTPS administrative access if you will connect using the CLI Console widget in
the web-based manager.
Local access is required in some cases.
• If you are installing your FortiGate unit for the first time and it is not yet configured to
connect to your network, unless you reconfigure your computer’s network settings for a
peer connection, you may only be able to connect to the CLI using a local serial
console connection. For more information, see “Connecting to the CLI” on page 334.
• Restoring the firmware utilizes a boot interrupt. Network access to the CLI is not
available until after the boot process has completed, and therefore local CLI access is
the only viable option.
Before you can access the CLI through the network, you usually must enable SSH and/or
Telnet on the network interface through which you will access the CLI.
Connecting to the CLI using a local console

Local console connections to the CLI are formed by directly connecting your management
computer or console to the FortiGate unit, using its DB-9 or RJ-45 console port. To
connect to the local console you need:
• a computer with an available serial communications (COM) port
• the RJ-45-to-DB-9 or null modem cable included in your FortiGate package
• terminal emulation software such as HyperTerminal for Microsoft Windows

01-420-99686-20101026 365
Connecting to the CLI Using the CLI
Note: The following procedure describes connection using Microsoft HyperTerminal

software; steps may vary with other terminal emulators.
To connect to the CLI using a local serial console connection

1 Using the null modem or RJ-45-to-DB-9 cable, connect the FortiGate unit’s console
port to the serial communications (COM) port on your management computer.
2 On your management computer, start HyperTerminal.
3 For the Connection Description, enter a Name for the connection, and select OK.
4 On the Connect using drop-down list box, select the communications (COM) port on
your management computer you are using to connect to the FortiGate unit.
5 Select OK.
6 Select the following Port settings and select OK.
Bits per second 9600

Data bits 8
Parity None
Stop bits 1
Flow control None
7 Press Enter or Return on your keyboard to connect to the CLI.

8 Type a valid administrator account name (such as admin) and press Enter.
9 Type the password for that administrator account and press Enter. (In its default state,
there is no password for the admin account.)
The CLI displays the following text:
Welcome!
Type ? to list available commands.
You can now enter CLI commands, including configuring access to the CLI through
SSH or Telnet. For details, see “Enabling access to the CLI through the network (SSH
or Telnet)” on page 366.
Enabling access to the CLI through the network (SSH or Telnet)

SSH or Telnet access to the CLI is accomplished by connecting your computer to the
FortiGate unit using one of its RJ-45 network ports. You can either connect directly, using
a peer connection between the two, or through any intermediary network.
Note: If you do not want to use an SSH/Telnet client and you have access to the webbiest
manager, you can alternatively access the CLI through the network using the CLI Console
widget in the web-based manager.
You must enable SSH and/or Telnet on the network interface associated with that physical
network port. If your computer is not connected directly or through a switch, you must also
configure the FortiGate unit with a static route to a router that can forward packets from
the FortiGate unit to your computer.
You can do this using either:
• a local console connection
• the web-based manager

366 01-420-99686-20101026
Using the CLI Connecting to the CLI
Requirements
• a computer with an available serial communications (COM) port and RJ-45 port
• terminal emulation software such as HyperTerminal for Microsoft Windows
• the RJ-45-to-DB-9 or null modem cable included in your FortiGate package
• a network cable
• prior configuration of the operating mode, network interface, and static route (for
details, see)
To enable SSH or Telnet access to the CLI using a local console connection
1 Using the network cable, connect the FortiGate unit’s network port either directly to
your computer’s network port, or to a network through which your computer can reach
the FortiGate unit.
2 Note the number of the physical network port.
3 Using a local console connection, connect and log into the CLI. For details, see
“Connecting to the CLI using a local console” on page 365.
4 Enter the following command:
edit <interface_str>
set allowaccess <protocols_list>
next
end
where:
• <interface_str> is the name of the network interface associated with the
physical network port and containing its number, such as port1
• <protocols_list> is the complete, space-delimited list of permitted
administrative access protocols, such as https ssh telnet
For example, to exclude HTTP, HTTPS, SNMP, and PING, and allow only SSH and
Telnet administrative access on port1:
set system interface port1 config allowaccess ssh telnet
Caution: Telnet is not a secure access method. SSH should be used to access the CLI
from the Internet or any other untrusted network.
5 To confirm the configuration, enter the command to display the network interface’s
settings.
get system interface <interface_str>
The CLI displays the settings, including the allowed administrative access protocols,
for the network interfaces.
To connect to the CLI through the network interface, see “Connecting to the CLI using
SSH” on page 367 or “Connecting to the CLI using Telnet” on page 368.
Connecting to the CLI using SSH

Once the FortiGate unit is configured to accept SSH connections, you can use an SSH
client on your management computer to connect to the CLI.
Secure Shell (SSH) provides both secure authentication and secure communications to
the CLI.

01-420-99686-20101026 367
Connecting to the CLI Using the CLI
Note: FortiGate units support 3DES and Blowfish encryption algorithms for SSH.
Before you can connect to the CLI using SSH, you must first configure a network interface
to accept SSH connections. For details, see “Enabling access to the CLI through the
network (SSH or Telnet)” on page 366.
Note: The following procedure uses PuTTY. Steps may vary with other SSH clients.
To connect to the CLI using SSH

1 On your management computer, start an SSH client.
2 In Host Name (or IP Address), enter the IP address of a network interface on which
you have enabled SSH administrative access.
3 In Port, enter 22.
4 For the Connection type, select SSH.
5 Select Open.
The SSH client connects to the FortiGate unit.
The SSH client may display a warning if this is the first time you are connecting to the
FortiGate unit and its SSH key is not yet recognized by your SSH client, or if you have
previously connected to the FortiGate unit but it used a different IP address or SSH
key. If your management computer is directly connected to the FortiGate unit with no
network hosts between them, this is normal.
6 Click Yes to verify the fingerprint and accept the FortiGate unit’s SSH key. You will not
be able to log in until you have accepted the key.
The CLI displays a login prompt.
8 Type the password for this administrator account and press Enter.
Note: If three incorrect login or password attempts occur in a row, you will be disconnected.
Wait one minute, then reconnect to attempt the login again.
The FortiGate unit displays a command prompt (its host name followed by a #).
You can now enter CLI commands.
Connecting to the CLI using Telnet

Once the FortiGate unit is configured to accept Telnet connections, you can use a Telnet
client on your management computer to connect to the CLI.
Caution: Telnet is not a secure access method. SSH should be used to access the CLI
from the Internet or any other untrusted network.
Before you can connect to the CLI using Telnet, you must first configure a network
interface to accept SSH connections. For details, see “Enabling access to the CLI through
the network (SSH or Telnet)” on page 366.

368 01-420-99686-20101026
Using the CLI Command syntax
To connect to the CLI using Telnet

1 On your management computer, start a Telnet client.
2 Connect to a FortiGate network interface on which you have enabled Telnet.
4 Type the password for this administrator account and press Enter.
Note: If three incorrect login or password attempts occur in a row, you will be disconnected.
Wait one minute, then reconnect to attempt the login again.
The FortiGate unit displays a command prompt (its host name followed by a #).
You can now enter CLI commands.
Command syntax
When entering a command, the command line interface (CLI) requires that you use valid
syntax, and conform to expected input constraints. It will reject invalid commands.
Fortinet documentation uses the following conventions to describe valid command syntax
Terminology
Each command line consists of a command word that is usually followed by words for the
configuration data or other specific item that the command uses or affects:
get system admin
To describe the function of each word in the command line, especially if that nature has
changed between firmware versions, Fortinet uses terms with the following definitions.
Figure 36: Command syntax terminology
Command Subcommand Object
config system interface Table

edit <port_name> Option
set status {up | down}
set ip <interface_ipv4mask>
next
end Field Value
• command — A word that begins the command line and indicates an action that the
FortiGate unit should perform on a part of the configuration or host on the network,
such as config or execute. Together with other words, such as fields or values, that
end when you press the Enter key, it forms a command line. Exceptions include
multiline command lines, which can be entered using an escape sequence. (See
“Shortcuts and key commands” on page 377.)
Valid command lines must be unambiguous if abbreviated. (See “Command
abbreviation” on page 377.) Optional words or other command line permutations are
indicated by syntax notation. (See “Notation” on page 370.)

01-420-99686-20101026 369
Command syntax Using the CLI
• sub-command — A kind of command that is available only when nested within the
scope of another command. After entering a command, its applicable sub-commands
are available to you until you exit the scope of the command, or until you descend an
additional level into another sub-command. Indentation is used to indicate levels of
nested commands. (See “Indentation” on page 370.)
Not all top-level commands have sub-commands. Available sub-commands vary by
their containing scope. (See “Sub-commands” on page 371.)
• object — A part of the configuration that contains tables and/or fields. Valid command
lines must be specific enough to indicate an individual object.
• table — A set of fields that is one of possibly multiple similar sets which each have a
name or number, such as an administrator account, policy, or network interface. These
named or numbered sets are sometimes referenced by other parts of the configuration
that use them. (See “Notation” on page 370.)
• field — The name of a setting, such as ip or hostname. Fields in some tables must
be configured with values. Failure to configure a required field will result in an invalid
object configuration error message, and the FortiGate unit will discard the invalid table.
• value — A number, letter, IP address, or other type of input that is usually your
configuration setting held by a field. Some commands, however, require multiple input
values which may not be named but are simply entered in sequential order in the same
command line. Valid input types are indicated by constraint notation. (See “Notation”
on page 370.)
• option — A kind of value that must be one or more words from of a fixed set of options.
(See “Notation” on page 370.)
Indentation
Indentation indicates levels of nested commands, which indicate what other
subcommittees are available from within the scope. For example, the edit sub-command
is available only within a command that affects tables, and the next sub-command is
available only from within the edit sub-command:
edit port1
set status up
next
end
For information about available sub-commands, see “Sub-commands” on page 371.
Notation
Brackets, braces, and pipes are used to denote valid permutations of the syntax.
Constraint notations, such as <address_ipv4>, indicate which data types or string
patterns are acceptable value input.
Square brackets [ ] A non-required word or series of words. For example:
[verbose {1 | 2 | 3}]
indicates that you may either omit or type both the verbose word and its
accompanying option, such as verbose 3.

370 01-420-99686-20101026
Using the CLI Sub-commands

Angle brackets < > A word constrained by data type. The angled brackets contain a
descriptive name followed by an underscore ( _ ) and suffix that indicates
the valid data type. For example, <retries_int>, indicates that you
should enter a number of retries, such as 5.
Data types include:
• <xxx_name>: A name referring to another part of the configuration,
such as policy_A.
• <xxx_index>: An index number referring to another part of the
configuration, such as 0 for the first static route.
• <xxx_pattern>: A regular expression or word with wild cards that
matches possible variations, such as *@example.com to match all
email addresses ending in @example.com.
• <xxx_fqdn>: A fully qualified domain name (FQDN), such as
mail.example.com.
• <xxx_email>: An email address, such as admin@example.com.
• <xxx_ipv4>: An IPv4 address, such as 192.168.1.99.
• <xxx_v4mask>: A dotted decimal IPv4 netmask, such as
255.255.255.0.
separated by a space, such as 192.168.1.99 255.255.255.0.
• <xxx_ipv4/mask>: A dotted decimal IPv4 address and CIDR-
notation netmask separated by a slash, such as 192.168.1.1/24.
• <xxx_ipv4range>: A hyphen ( - )-delimited inclusive range of IPv4
addresses, such as 192.168.1.1-192.168.1.255.
• <xxx_ipv6>: A colon( : )-delimited hexadecimal IPv6 address, such
as 3f2e:6a8b:78a3:0d82:1725:6a2f:0370:6234.
• <xxx_v6mask>: An IPv6 netmask, such as /96.
separated by a space.
• <xxx_str>: A string of characters that is not another data type, such
as P@ssw0rd. Strings containing spaces or special characters must be
surrounded in quotes or use escape sequences. See “Special
characters” on page 378.
• <xxx_int>: An integer number that is not another data type, such as
15 for the number of minutes.
Curly braces { } A word or series of words that is constrained to a set of options delimited
by either vertical bars or spaces. You must enter at least one of the
options, unless the set of options is surrounded by square brackets [ ].
Options Mutually exclusive options. For example:
delimited by {enable | disable}
vertical bars | indicates that you must enter either enable or disable, but must not
enter both.
Options Non-mutually exclusive options. For example:
delimited by {http https ping snmp ssh telnet}
spaces indicates that you may enter all or a subset of those options, in any order,
in a space-delimited list, such as:
ping https ssh
Note: To change the options, you must re-type the entire list. For example,
to add snmp to the previous example, you would type:
ping https snmp ssh
If the option adds to or subtracts from the existing list of options, instead of
replacing it, or if the list is comma-delimited, the exception will be noted.
Sub-commands
Each command line consists of a command word that is usually followed by words for the
configuration data or other specific item that the command uses or affects:
get system admin

01-420-99686-20101026 371
Sub-commands Using the CLI
Sub-commands are available from within the scope of some commands.When you enter a
sub-command level, the command prompt changes to indicate the name of the current
command scope. For example, after entering:
config system admin
the command prompt becomes:
(admin)#
Applicable sub-commands are available to you until you exit the scope of the command,
or until you descend an additional level into another sub-command.
For example, the edit sub-command is available only within a command that affects
tables; the next sub-command is available only from within the edit sub-command:
edit port1
set status up
next
end
Note: Sub-command scope is indicated in this System Administration by indentation. See

“Indentation” on page 370.
Available sub-commands vary by command.From a command prompt within config, two

types of sub-commands might become available:
• commands affecting fields
• commands affecting tables
Table 30: Commands for tables
clone <table> Clone (or make a copy of) a table from the current object.
For example, in config firewall policy, you could enter the following
command to clone firewall policy 27 to create firewall policy 30:
clone 27 to 39
In config antivirus profile, you could enter the following command
to clone an antivirus profile named av_pro_1 to create a new antivirus
profile named av_pro_2:
clone av_pro_1 to av_pro_2
clone may not be available for all tables.
delete <table> Remove a table from the current object.
For example, in config system admin, you could delete an administrator
account named newadmin by typing delete newadmin and pressing
Enter. This deletes newadmin and all its fields, such as newadmin’s
first-name and email-address.
delete is only available within objects containing tables.
edit <table> Create or edit a table in the current object.
For example, in config system admin:
• edit the settings for the default admin administrator account by typing
edit admin.
• add a new administrator account with the name newadmin and edit
newadmin‘s settings by typing edit newadmin.
edit is an interactive sub-command: further sub-commands are available
from within edit.
edit changes the prompt to reflect the table you are currently editing.
edit is only available within objects containing tables.
In objects such as firewall policies, <table> is a sequence number. To
create a new entry without the risk of overwriting an existing one, enter edit
0. The CLI initially confirms the creation of entry 0, but assigns the next
unused number after you finish editing and enter end.

372 01-420-99686-20101026
Using the CLI Sub-commands
Table 30: Commands for tables

end Save the changes to the current object and exit the config command. This
returns you to the top-level command prompt.
get List the configuration of the current object or table.
• In objects, get lists the table names (if present), or fields and their
values.
• In a table, get lists the fields and their values.
For more information on get commands, see the CLI Reference.
purge Remove all tables in the current object.
For example, in config forensic user, you could type get to see the
list of user names, then type purge and then y to confirm that you want to
delete all users.
purge is only available for objects containing tables.
Caution: Back up the FortiGate unit before performing a purge. purge
cannot be undone. To restore purged tables, the configuration must be
restored from a backup.
Caution: Do not purge system interface or system admin tables.
purge does not provide default tables. This can result in being unable to
connect or log in, requiring the FortiGate unit to be formatted and restored.
rename <table> Rename a table.
to <table> For example, in config system admin, you could rename admin3 to
fwadmin by typing rename admin3 to fwadmin.
rename is only available within objects containing tables.
show Display changes to the default configuration. Changes are listed in the form
of configuration commands.
Example of table commands

From within the system admin object, you might enter:
edit admin_1
The CLI acknowledges the new table, and changes the command prompt to show that you
are now within the admin_1 table:
new entry 'admin_1' added
(admin_1)#
Table 31: Commands for fields
abort Exit both the edit and/or config commands without saving the fields.
end Save the changes made to the current table or object fields, and exit the config
command. (To exit without saving, use abort instead.)
get List the configuration of the current object or table.
• In objects, get lists the table names (if present), or fields and their values.
• In a table, get lists the fields and their values.
next Save the changes you have made in the current table’s fields, and exit the edit
command to the object prompt. (To save and exit completely to the root prompt,
use end instead.)
next is useful when you want to create or edit several tables in the same object,
without leaving and re-entering the config command each time.
next is only available from a table prompt; it is not available from an object
prompt.

01-420-99686-20101026 373
Permissions Using the CLI
Table 31: Commands for fields

set <field> Set a field’s value.
<value> For example, in config system admin, after typing edit admin, you could
type set password newpass to change the password of the admin
administrator to newpass.
Note: When using set to change a field containing a space-delimited list, type
the whole new list. For example, set <field> <new-value> will replace the
list with the <new-value> rather than appending <new-value> to the list.
show Display changes to the default configuration. Changes are listed in the form of
configuration commands.
unset Reset the table or object’s fields to default values.
<field> For example, in config system admin, after typing edit admin, typing
unset password resets the password of the admin administrator account to
the default (in this case, no password).
Example of field commands

From within the admin_1 table, you might enter:
set password my1stExamplePassword
to assign the value my1stExamplePassword to the password field. You might then
enter the next command to save the changes and edit the next administrator’s table.
Permissions
Depending on the account that you use to log in to the FortiGate unit, you may not have
complete access to all CLI commands.
Access profiles control which CLI commands an administrator account can access.
Access profiles assign either read, write, or no access to each area of the FortiGate
software. To view configurations, you must have read access. To make changes, you must
have write access.
Table 32: Areas of control in access profiles
Access control area name Grants access to

In the web-based In the CLI (For each config command, there is an equivalent
get/show command, unless otherwise noted.
manager
config access requires write permission.
get/show access requires read permission.)
Admin Users admingrp System > Admin
config system admin
config system accprofile
Auth Users authgrp User
config imp2p aim-user
config imp2p icq-user
config imp2p msn-user
config imp2p yahoo-user
config user
Endpoint NAC endpoint- Endpoint NAC
control-grp
config endpoint-control
Firewall Configuration fwgrp Firewall

374 01-420-99686-20101026
Using the CLI Permissions

config firewall
config gui topology
execute fsae refresh
FortiGuard Update updategrp System > Maintenance > FortiGuard
config system autoupdate
execute update-ase
execute update-av
execute update-ips
execute update-now
Log & Report loggrp Log&Report
cconfig alertemail
config log
config system alertemail
config system fortianalyzer1/2/3
execute formatlogdisk
execute fortiguard-log
execute log
Maintenance mntgrp System > Maintenance
diagnose sys ...
execute backup ...
execute batch
execute central-mgmt
execute factoryreset
execute reboot
execute restore
execute shutdown
execute usb-disk
Network Configuration netgrp System > Network > Interface
Router Configuration routegrp Router
config router ...
execute mrouter
execute router

01-420-99686-20101026 375
Permissions Using the CLI

System Configuration sysgrp System > Status (all), System > Network > Options,
System > Network > DNS Database,
System > Config (all),
System > Admin > Central Management,
System > Admin > Settings, Wireless Controller
config gui console
config system auto-install, bug report,
central-management, console, dns,
dns-database, fips-cc, fortiguard,
fortiguard-log, global, ha, ipv6-tunnel,
modem, ntp, password-policy, replacemsg,
session-helper, session-sync, session-ttl,
settings, sit-tunnel, snmp,
switch-interface, tos-based-priority, wccp
config wireless-controller ...
execute cfg, cli, date,
disconnect-admin-session, enter,
factoryreset, fortiguard-log, ha, modem,
ping, ping-options, ping6, ping6-options,
reboot, send-fds-statistics,
set-next-reboot, shutdown, ssh, telnet, time,
traceroute
get gui console
get ipsec tunnel
get system central-mgmt, cmdb,
fdp-fortianalyzer,
fortianalyzer-connectivity,
fortiguard-log-service,
fortiguard-service, info, performance,
session
get wireless-controller
UTM Configuration utmgrp UTM
config antivirus
config application
config imp2p old-version
config imp2p policy
config ips
config spamfilter
config webfilter
VPN Configuration vpngrp VPN
config vpn
execute vpn
Unlike other administrator accounts, the administrator account named admin exists by
default and cannot be deleted. The admin administrator account is similar to a root
administrator account. This administrator account always has full permission to view and
change all FortiGate configuration options, including viewing and changing all other
administrator accounts. Its name and permissions cannot be changed. It is the only
administrator account that can reset another administrator’s password without being
required to enter that administrator’s existing password.
Caution: Set a strong password for the admin administrator account, and change the
password regularly. By default, this administrator account has no password. Failure to
maintain the password of the admin administrator account could compromise the security
of your FortiGate unit.

376 01-420-99686-20101026
Using the CLI Tips
For complete access to all commands, you must log in with the administrator account
named admin.
Tips
Basic features and characteristics of the CLI environment provide support and ease of use
for many CLI tasks.
Help
To display brief help during command entry, press the question mark (?) key.
• Press the question mark (?) key at the command prompt to display a list of the
commands available and a description of each command.
• Type a word or part of a word, then press the question mark (?) key to display a list of
valid word completions or subsequent words, and to display a description of each.
Shortcuts and key commands
Table 33: Shortcuts and key commands
Action Keys
List valid word completions or subsequent words. ?
If multiple words could complete your entry, display all possible completions with
helpful descriptions of each.
Complete the word with the next available match. Tab
Press the key multiple times to cycle through available matches.
Recall the previous command. Up arrow, or
Command memory is limited to the current session. Ctrl + P
Recall the next command. Down arrow, or
Ctrl + N
Move the cursor left or right within the command line. Left or Right
arrow
Move the cursor to the beginning of the command line. Ctrl + A
Move the cursor to the end of the command line. Ctrl + E
Move the cursor backwards one word. Ctrl + B
Move the cursor forwards one word. Ctrl + F
Delete the current character. Ctrl + D
Abort current interactive commands, such as when entering multiple lines. Ctrl + C
If you are not currently within an interactive command such as config or edit,
this closes the CLI connection.
Continue typing a command on the next line for a multi-line command. \ then Enter
For each line that you want to continue, terminate it with a backslash ( \ ). To
complete the command line, terminate it by pressing the spacebar and then the
Enter key, without an immediately preceding backslash.
Command abbreviation
You can abbreviate words in the command line to their smallest number of non-ambiguous
characters.
For example, the command get system status could be abbreviated to g sy st.

01-420-99686-20101026 377
Tips Using the CLI
Environment variables
The CLI supports the following environment variables. Variable names are case-sensitive.
$USERFROM The management access type (ssh, telnet, jsconsole for the CLI Console
widget in the web-based manager, and so on) and the IP address of the
administrator that configured the item.
$USERNAME The account name of the administrator that configured the item.
$SerialNum The serial number of the FortiGate unit.
For example, the FortiGate unit’s host name can be set to its serial number.
set hostname $SerialNum
end
As another example, you could log in as admin1, then configure a restricted secondary
administrator account for yourself named admin2, whose first-name is admin1 to
indicate that it is another of your accounts:
config system admin
edit admin2
set first-name $USERNAME
Special characters
The characters <, >, (,), #, ', and “ are not permitted in most CLI fields. These characters
are special characters, sometimes also called reserved characters.
You may be able to enter special character as part of a string’s value by using a special
command, enclosing it in quotes, or preceding it with an escape sequence — in this case,
a backslash ( \ ) character.
Table 34: Entering special characters
Character Keys
? Ctrl + V then ?
Tab Ctrl + V then Tab
Space Enclose the string in quotation marks: "Security Administrator".
(to be interpreted as Enclose the string in single quotes: 'Security Administrator'.
part of a string value, Precede the space with a backslash: Security\ Administrator.
not to end the string)
' \'
(to be interpreted as
part of a string value,
" \"
(to be interpreted as
part of a string value,
\ \\
If you need to add configuration via CLI that requires ? as part of config, you need to input
CTRL-V first. If you enter the question mark (?) without first using CTRL-V, the question
mark has a different meaning in CLI: it will show available command options in that
section.
For example, if you enter ? without CTRL-V:

378 01-420-99686-20101026
Using the CLI Tips
edit "*.xe
token line: Unmatched double quote.
If you enter ? with CTRL-V:
edit "*.xe?"
new entry '*.xe?' added
Using grep to filter get and show command output

In many cases the get and show (and diagnose) commands may produce a large
amount of output. If you are looking for specific information in a large get or show
command output you can use the grep command to filter the output to only display what
you are looking for. The grep command is based on the standard UNIX grep, used for
searching text output based on regular expressions.
Information about how to use grep and regular expressions is available on the Internet,
just to a search for grep. For example, see
http://www.opengroup.org/onlinepubs/009695399/utilities/grep.html.
Examples
Use the following command to display the MAC address of the FortiGate unit internal
interface:
get hardware nic internal | grep Current_HWaddr
Current_HWaddr 00:09:0f:cb:c2:75
Use the following command to display all TCP sessions in the session list and include the
session list line number in the output
get system session list | grep -n tcp
Use the following command to display all lines in HTTP replacement message commands
that contain URL (upper or lower case):
show system replacemsg http | grep -i url
Language support and regular expressions

Characters such as ñ, é, symbols, and ideographs are sometimes acceptable input.
Support varies by the nature of the item being configured. CLI commands, objects, field
names, and options must use their exact ASCII characters, but some items with arbitrary
names or values may be input using your language of choice.
For example, the host name must not contain special characters, and so the web-based
manager and CLI will not accept most symbols and other non-ASCII encoded characters
as input when configuring the host name. This means that languages other than English
often are not supported. However, some configuration items, such as names and
comments, may be able to use the language of your choice.
To use other languages in those cases, you must use the correct encoding.
Input is stored using Unicode UTF-8 encoding, but is not normalized from other encodings
into UTF-8 before it is stored. If your input method encodes some characters differently
than in UTF-8, your configured items may not display or operate as expected.
Regular expressions are especially impacted. Matching uses the UTF-8 character
values. If you enter a regular expression using another encoding, or if an HTTP
client sends a request in an encoding other than UTF-8, matches may not be what
you expect.

01-420-99686-20101026 379
Tips Using the CLI
For example, with Shift-JIS, backslashes ( \ ) could be inadvertently interpreted as yen

symbols ( ¥ ) and vice versa. A regular expression intended to match HTTP requests
containing money values with a yen symbol therefore may not work it if the symbol is
entered using the wrong encoding.
For best results, you should:
• use UTF-8 encoding, or
• use only the characters whose numerically encoded values are the same in UTF-8,
such as the US-ASCII characters that are also encoded using the same values in
ISO 8859-1, Windows code page 1252, Shift-JIS and other encodings, or
• for regular expressions that must match HTTP requests, use the same encoding as
your HTTP clients
Note: HTTP clients may send requests in encodings other than UTF-8. Encodings usually
vary by the client’s operating system or input language. If you cannot predict the client’s
encoding, you may only be able to match any parts of the request that are in English,
because regardless of the encoding, the values for English characters tend to be encoded
identically. For example, English words may be legible regardless of interpreting a web
page as either ISO 8859-1 or as GB2312, whereas simplified Chinese characters might
only be legible if the page is interpreted as GB2312.
It configure your FortiGate unit using other encodings, you may need to switch language
settings on your management computer, including for your web browser or Telnet/SSH
client. For instructions on how to configure your management computer’s operating
system language, locale, or input method, see its documentation.
Note: If you choose to configure parts of the FortiGate unit using non-ASCII characters,
verify that all systems interacting with the FortiGate unit also support the same encodings.
You should also use the same encoding throughout the configuration if possible in order to
avoid needing to switch the language settings of the web-based manager and your web
browser or Telnet/SSH client while you work.
Similarly to input, your web browser or CLI client should usually interpret display output as
encoded using UTF-8. If it does not, your configured items may not display correctly in the
web-based manager or CLI. Exceptions include items such as regular expressions that
you may have configured using other encodings in order to match the encoding of HTTP
requests that the FortiGate unit receives.
To enter non-ASCII characters in the CLI Console widget

1 On your management computer, start your web browser and go to the URL for the
FortiGate unit’s web-based manager.
2 Configure your web browser to interpret the page as UTF-8 encoded.
5 In title bar of the CLI Console widget, click Edit (the pencil icon).
6 Enable Use external command input box.
7 Select OK.
The Command field appears below the usual input and display area of the CLI Console
widget.
8 In Command, type a command.

380 01-420-99686-20101026
Using the CLI Tips
Figure 37: Entering encoded characters (CLI Console widget)
9 Press Enter.
In the display area, the CLI Console widget displays your previous command
interpreted into its character code equivalent, such as:
edit \743\601\613\743\601\652
and the command’s output.
To enter non-ASCII characters in a Telnet/SSH client

1 On your management computer, start your Telnet or SSH client.
2 Configure your Telnet or SSH client to send and receive characters using UTF-8
encoding.
Support for sending and receiving international characters varies by each Telnet/SSH
client. Consult the documentation for your Telnet/SSH client.
4 At the command prompt, type your command and press Enter.
Figure 38: Entering encoded characters (PuTTY)
You may need to surround words that use encoded characters with single quotes ( ' ).
Depending on your Telnet/SSH client’s support for your language’s input methods and
for sending international characters, you may need to interpret them into character
codes before pressing Enter.
For example, you might need to enter:
edit '\743\601\613\743\601\652'
5 The CLI displays your previous command and its output.

01-420-99686-20101026 381
Tips Using the CLI
Screen paging
You can configure the CLI to, when displaying multiple pages’ worth of output, pause after
displaying each page’s worth of text. When the display pauses, the last line displays
--More--. You can then either:
• press the spacebar to display the next page.
• type Q to truncate the output and return to the command prompt.
This may be useful when displaying lengthy output, such as the list of possible matching
commands for command completion, or a long list of settings. Rather than scrolling
through or possibly exceeding the buffer of your terminal emulator, you can simply display
one page at a time.
To configure the CLI display to pause when the screen is full:
config system console
set output more
end
Baud rate
You can change the default baud rate of the local console connection.
To change the baud rate enter the following commands:
set baudrate {115200 | 19200 | 38400 | 57600 | 9600}
end
Editing the configuration file on an external host

You can edit the FortiGate configuration on an external host by first backing up the
configuration file to a TFTP server. Then edit the configuration file and restore it to the
FortiGate unit.
Editing the configuration on an external host can be time-saving if you have many
changes to make, especially if your plain text editor provides advanced features such as
batch changes.
To edit the configuration on your computer

1 Use execute backup to download the configuration file to a TFTP server, such as
your management computer.
2 Edit the configuration file using a plain text editor that supports Unix-style line endings.
Caution: Do not edit the first line. The first line(s) of the configuration file (preceded by a #
character) contains information about the firmware version and FortiGate model. If you
change the model number, the FortiGate unit will reject the configuration file when you
attempt to restore it.
3 Use execute restore to upload the modified configuration file back to the
FortiGate unit.
The FortiGate unit downloads the configuration file and checks that the model
information is correct. If it is, the FortiGate unit loads the configuration file and checks
each command for errors.If a command is invalid, the FortiGate unit ignores the
command. If the configuration file is valid, the FortiGate unit restarts and loads the new
configuration.

382 01-420-99686-20101026
Using the CLI Tips
Using Perl regular expressions

Some FortiGate features, such as spam filtering and web content filtering can use either
wildcards or Perl regular expressions.
See http://perldoc.perl.org/perlretut.html for detailed information about using Perl regular
expressions.
Differences between regular expression and wildcard pattern matching

In Perl regular expressions, the period (‘.’) character refers to any single character. It is
similar to the question mark (‘?’) character in wildcard pattern matching. As a result:
• fortinet.com not only matches fortinet.com but also matches
fortinetacom, fortinetbcom, fortinetccom and so on.
To match a special character such as the period ('.') and the asterisk (‘*’), regular
expressions use the slash (‘\’) escape character. For example:
• To match fortinet.com, the regular expression should be fortinet\.com.
In Perl regular expressions, the asterisk (‘*’) means match 0 or more times of the
character before it, not 0 or more times of any character. For example:
• forti*\.com matches fortiiii.com but does not match fortinet.com.
To match any character 0 or more times, use ‘.*’ where ‘.’ means any character and the ‘*’
means 0 or more times. For example:
• the wildcard match pattern forti*.com is equivalent to the regular expression
forti.*\.com.
Word boundary
In Perl regular expressions, the pattern does not have an implicit word boundary. For
example, the regular expression “test” not only matches the word “test” but also matches
any word that contains the word “test” such as “atest”, “mytest”, “testimony”, “atestb”. The
notation “\b” specifies the word boundary. To match exactly the word “test”, the expression
should be \btest\b.
Case sensitivity
Regular expression pattern matching is case sensitive in the Web and Spam filters. To
make a word or phrase case insensitive, use the regular expression /i. For example,
/bad language/i will block all instances of “bad language” regardless of case.
Table 35: Perl regular expression examples
Expression Matches
abc abc (that exact character sequence, but anywhere in the string)
âbc abc at the beginning of the string
abc$ abc at the end of the string
a|b either of a and b
âbc|abc$ the string abc at the beginning or at the end of the string
ab{2,4}c an a followed by two, three or four b's followed by a c
ab{2,}c an a followed by at least two b's followed by a c
ab*c an a followed by any number (zero or more) of b's followed by a c
ab+c an a followed by one or more b's followed by a c
ab?c an a followed by an optional b followed by a c; that is, either abc or ac

01-420-99686-20101026 383
Tips Using the CLI
Table 35: Perl regular expression examples

a.c an a followed by any single character (not newline) followed by a c
a\.c a.c exactly
[abc] any one of a, b and c
[Aa]bc either of Abc and abc
[abc]+ any (nonempty) string of a's, b's and c's (such as a, abba, acbabcacaa)
[âbc]+ any (nonempty) string which does not contain any of a, b and c (such as
defg)
\d\d any two decimal digits, such as 42; same as \d{2}
/i makes the pattern case insensitive. For example, /bad language/i
blocks any instance of “bad language” regardless of case.
\w+ a "word": a nonempty sequence of alphanumeric characters and low lines
(underscores), such as foo and 12bar8 and foo_1
100\s*mk the strings 100 and mk optionally separated by any amount of white space
(spaces, tabs, newlines)
abc\b abc when followed by a word boundary (e.g. in abc! but not in abcd)
perl\B perl when not followed by a word boundary (e.g. in perlert but not in perl
stuff)
\x tells the regular expression parser to ignore white space that is neither
backslashed nor within a character class. You can use this to break up your
regular expression into (slightly) more readable parts.

384 01-420-99686-20101026
Tightening security
The FortiGate unit protects the network. There are additional configurations you can do in
FortiOS to more effectively hide the FortiGate unit from would-be hackers on the Internet.
This chapter describes some options to better cloak your network.
These security steps are focused on limiting administrative access on management
computers and within FortiOS. For physical security, the FortiGate unit should be housed
in a server room with limited access and locks requiring access codes or swipe cards.
• Administrators
• Administrative ports
• Rejecting PING requests
• Opening TCP 113
Administrators
One point of security breach is at the management computer. Administrators who leave
their workstations for a prolonged amount of time while staying logged into the web-based
manager or CLI (whether on purpose or not), leave the firewall open to malicious intent.
Idle time-out
To avoid the possibility of an administrator walking away from the management computer
and leaving it exposed to unauthorized personnel, you can add an idle time-out. That is, if
the web-based manager is not used for a specified amount of time, the FortiGate unit will
automatically log the user out. To continue their work, they must log in to the device again.
The time-out can be set as high as 480 minutes, or eight hours, although this is not
recommend.
To set the idle time out - web-based manager

2 In the Timeout Settings, enter the amount of time the Administrator login can remain
idol, or inactive before automatically logging the administrator out.
3 Select Apply.
To set the idle time out - CLI

set admintimeout <minutes>
end
Administrator lockout
By default, the FortiGate unit includes set number of password retries. That is, the
administrator has a maximum of three attempts to log into their account before they are
locked out for a set amount of time. The number of attempts can be set to an alternate
value.

01-420-99686-20101026 385
Administrative ports Tightening security
As well, the default wait time before the administrator can try to enter a password again is
60 seconds. You can also change this to further sway would-be hackers. Both settings are
configured only in the CLI
To configure the lockout options use the following commands:
set admin-lockout-threshold <failed_attempts>
set admin-lockout-duration <seconds>
end
For example, to set the lockout threshold to one attempt and a five minute duration before
the administrator can try again to log in enter the commands”
set admin-lockout-threshold 1
set admin-lockout-duration 300
end
Change the admin username

The default super administrator user name, admin, is a very standard default administrator
name. Leaving this as is, is one half of the key to the FortiGate unit being compromised.
The name can be changed.
To do this, you need to create another super user with full access and log in as that user.
Then go to System > Admin > Administrator, select the admin account and select Edit to
change the user name.
Disable admin services

On untrusted networks, turn off the weak administrative services such as TLENET and
HTTP. With these services, passwords are passed in the clear, not encrypted.
These services can be disabled by going to System > Network > Interface and deselecting
the required checkboxes.
Segregated administrative roles

To minimize the affect of an administrator doing complete harm to the FortiGate
configuration and possibly jeopardize the network, create individual administrative roles
where none of the administrators have super-admin permissions.
For example, and admin solely to create firewall policies, another for users and groups,
another for VPN and so on.
Administrative ports
You can set the web-based manager access as through HTTP, HTTPS, SSH and Telnet.
In these cases, the default ports for these protocols are 80, 443, 22 and 23 respectively.
You can change the ports used for network administration to a different, unused port to
further limit potential hackers.
Note: Ensure the port you select is not a port you will be using for other applications. For a
list of assigned port numbers see http://www.iana.org/assignments/port-numbers.

386 01-420-99686-20101026
Tightening security Interface settings
To change the administrative ports - web-based manager

2 In the Web Administration Ports section, change the port numbers.
3 Select Apply
To change the administrative ports - CLI

set admin-port <http_port_number>
set admin-sport <https_port_number>
set admin-ssh-port <ssh_port_number>
set admin-telnet-port <telnet_port_number>
end
When logging into the FortiGate unit, by default FortiOS will automatically use the default
ports. That is, when logging into the FortiGate IP address, you only need to enter the
address, for example:
https://192.168.1.1
When you change the administrative port number, the port number must be added to the
url. For example, if the port number for https access is 2112, the administrator must enter
the following address:
https://192.168.1.1:2112
Interface settings
Within FortiOS there are a few options you can set to limit unauthorized access.
Remove admin access

If any interfaces do not require access from an administrator, disable the admin access
options for it, even PING to restrict anyone sniffing for available ports.
To remove all admin access

2 Select the interface and select Edit.
3 Clear any checkboxes in the Administrative Access section.
4 Select OK.
Within the CLI, you cannot completely clear all the admin access options; one must be
selected. It is best to either do this from the web-based manager.
Disable interfaces
If any of the interfaces on the FortiGate unit are not being used, disable traffic on that
interface. This avoids someone plugging in network cables and potentially causing
network bypass or loop issues.
To disable an interface - web-based manager

2 Select the interface from the list and select Edit.
3 For Administrative Access, select Down.
4 Select OK.

01-420-99686-20101026 387
Rejecting PING requests Tightening security
To disable an interface - CLI

edit <inerface_name>
set status down
end
Rejecting PING requests

The factory default configuration of your FortiGate unit allows the default public interface
to respond to ping requests. The default public interface, or the external interface, is the
interface the FortiGate unit typically connects to the Internet. Depending on the model of
your FortiGate unit the actual name of this interface will vary.
For the most secure operation, you should change the configuration of the external
interface so that it does not respond to ping requests. Not responding to ping requests
makes it more difficult for a potential attacker to detect your FortiGate unit from the
Internet. One such potential threat are Denial of Service (DoS) attacks.
A FortiGate unit responds to ping requests if ping administrative access is enabled for that
interface. Use the following procedures to disable ping access for the external, or any,
interface of a FortiGate unit.
To disable ping administrative access - web-based manager

2 Choose the external interface and select Edit.
3 Clear the Ping Administrative Access check box.
4 Select OK.
In the CLI, when setting the allowaccess settings, by selecting the access types and not
including the PING option, that option is then not selected. In this example, only HTTPS is
selected.
To disable ping administrative access - CLI

edit external
set allowaccess https
end
Opening TCP 113

Although seemingly contrary to conventional wisdom of closing ports from hackers, this
port, which is used for ident requests, should be opened.
Port 113 initially was used as an authentication port, and later defined as an identification
port (see RFC 1413). Some servers may still use this port to help in identifying users or
other servers and establish a connection. Because port 113 receives a lot of unsolicited
traffic, many routers, including on the FortiGate unit, close this port.
The issue arises in that unsolicited requests are stopped by the FortiGate unit, which will
send a response saying that the port is closed. In doing so, it also lets the requesting
server know there is a device at the given address, and thus announcing its presence. By
enabling traffic on port 113, requests will travel to this port, and will most likely, be ignored
and never responded to.

388 01-420-99686-20101026
Tightening security Obfuscate HTTP headers
By default, the ident port is closed. To open it, use the following CLI commands:
edit <port_name>
set inden_accept enable
end
You could also further use port forwarding to send the traffic to a non-existent IP address
and thus never have a response packet sent.
Obfuscate HTTP headers

The FortiGate unit can obfuscate the HTTP header information being sent to external web
servers to better cloak the source. By default this option is not enabled. To obfuscate
HTTP headers, use the following CLI command:
set http-obfucate {none | header-only | modified | no-error}
end
Where:
none — do not hide the FortiGate web server identity.
header-only — hides the HTTP server banner.
modified — provides modified error responses.
no-error — suppresses error responses.

01-420-99686-20101026 389
Obfuscate HTTP headers Tightening security

390 01-420-99686-20101026
Best Practices
The FortiGate unit is installed, and traffic is flowing. With your network sufficiently
protected, you can now fine tune the firewall for the best performance and efficiently. This
chapter describes configuration options that can ensure your FortiGate unit is running at
its best performance.
This chapter includes best practices and suggestions for:
• Hardware
• Performance
• Firewall
• Intrusion protection
• Antivirus
• Web filtering
• Antispam
Hardware
Environmental specifications
Keep the following environmental specifications in mind when installing and setting up
• Operating temperature: 32 to 104°F (0 to 40°C)
• If you install the FortiGate unit in a closed or multi-unit rack assembly, the operating
ambient temperature of the rack environment may be greater than room ambient
temperature. Therefore, make sure to install the equipment in an environment
compatible with the manufacturer's maximum rated ambient temperature.
• Storage temperature: -13 to 158°F (-25 to 70°C)
• Humidity: 5 to 90% non-condensing
• Air flow - For rack installation, make sure that the amount of air flow required for safe
operation of the equipment is not compromised.
• For free-standing installation, make sure that the appliance has at least 1.5 in.
(3.75 cm) of clearance on each side to allow for adequate air flow and cooling.
This device complies with part FCC Class A, Part 15, UL/CUL, C Tick, CE and VCCI.
Operation is subject to the following two conditions:
• This device may not cause harmful interference, and
• This device must accept any interference received, including interference that may
cause undesired operation.
This equipment has been tested and found to comply with the limits for a Class B digital
device, pursuant to part 15 of the FCC Rules. These limits are designed to provide
reasonable protection against harmful interference in a residential installation. This
equipment generates, uses and can radiate radio frequency energy and, if not installed
and used in accordance with the instructions, may cause harmful interference to radio

01-420-99686-20101026 391
Hardware Best Practices
communications. However, there is no guarantee that interference will not occur in a

particular installation. If this equipment does cause harmful interference to radio or
television reception, which can be determined by turning the equipment off and on, the
user is encouraged to try to correct the interference by one or more of the following
measures:
• Reorient or relocate the receiving antenna.
• Increase the separation between the equipment and receiver.
• Connect the equipment into an outlet on a circuit different from that to which the
receiver is connected.
• Consult the dealer or an experienced radio/TV technician for help.
The equipment compliance with FCC radiation exposure limit set forth for uncontrolled
Environment.
Caution: Risk of Explosion if battery is replaced by an incorrect type. Dispose of used

batteries according to the instructions
Caution: To reduce the risk of fire, use only No. 26 AWG or larger UL Listed or CSA
Certified Telecommunication Line Cord.
Grounding
• Ensure the FortiGate unit is connected and properly grounded to a lightning and surge
protector. WAN or LAN connections that enter the premises from outside the building
should be connected to an Ethernet CAT5 (10/100 Mb/s) surge protector.
• Shielded Twisted Pair (STP) Ethernet cables should be used whenever possible rather
than Unshielded Twisted Pair (UTP).
• Do not connect or disconnect cables during lightning activity to avoid damage to the
FortiGate unit or personal injury.
Rack mount instructions

Elevated Operating Ambient - If installed in a closed or multi-unit rack assembly, the
operating ambient temperature of the rack environment may be greater than room
ambient. Therefore, consideration should be given to installing the equipment in an
environment compatible with the maximum ambient temperature (Tma) specified by the
manufacturer.
Reduced Air Flow - Installation of the equipment in a rack should be such that the
amount of air flow required for safe operation of the equipment is not compromised.
Mechanical Loading - Mounting of the equipment in the rack should be such that a
hazardous condition is not achieved due to uneven mechanical loading.
Circuit Overloading - Consideration should be given to the connection of the equipment
to the supply circuit and the effect that overloading of the circuits might have on
overcurrent protection and supply wiring. Appropriate consideration of equipment
nameplate ratings should be used when addressing this concern.
Reliable Earthing - Reliable earthing of rack-mounted equipment should be maintained.
Particular attention should be given to supply connections other than direct connections to
the branch circuit (e.g. use of power strips).

392 01-420-99686-20101026
Best Practices Shutting down
Shutting down
Always shut down the FortiGate operating system properly before turning off the power
switch to avoid potential hardware problems.
To power off the FortiGate unit - web-based manager

2 In the Unit Operation display, select Shutdown.
To power off the FortiGate unit

execute shutdown
Once completing this step you can safely disconnect the power cables from the power
supply.
Performance
• Disable any management features you do not need. If you don’t need SSH or SNMP
disable them. SSH also provides another possibility for would-be hackers to infiltrate
• Put the most used firewall rules to the top of the interface list.
• Log only necessary traffic. The writing of logs, especially if to an internal hard disk,
slows down performance.
• Enable only the required application inspections.
• Keep alert systems to a minimum. If you send logs to a syslog server, you may not
need SNMP or email alerts, making for redundant processing.
• Establish scheduled FortiGuard updates at a reasonable rate. Daily every 4-5 hours for
most situations, or in more heavy-traffic situations, in the evening when more
bandwidth can be available.
• Keep UTM profiles to a minimum. If you do not need a profile on a firewall rule, do not
include it.
• Keep VDOMs to a minimum. On low-end FortiGate units, avoid using them if possible.
• Avoid traffic shaping if you need maximum performance. Traffic shaping, by definition,
slows down traffic.
Firewall
• Avoid using the All selection for the source and destination addresses. Use addresses
or address groups.
• Avoid using Any for the services.
• Use logging on a policy only when necessary. For example, you may want to log all
dropped connections but be aware of the performance impact. However, use this
sparingly to sample traffic data rather than have it continually storing log information
you may not use.
• Use the comment field to input management data; who requested the rule, who
authorized it, etc.
• Avoid FQDN addresses if possible. It can cause a performance impact on DNS queries
and security impact from DNS spoofing.

01-420-99686-20101026 393
Intrusion protection Best Practices
• If possible, avoid port ranges on services for security reasons.

• Use groups whenever possible.
Intrusion protection
• Create and use UTM profiles with specific signatures and anomalies you need
per-interface and per-rule.
• Do not use predefined or generic profiles. While convenient to supply immediate
protection, you should create profiles to suit your network environment.
• If you do use the default profiles, reduce the IPS signatures/anomalies enabled in the
profile to conserver processing time and memory.
• If you are going to enable anomalies, make sure you tune thresholds according to your
environment.
• If you need protection, but not audit information, disable the logging option.
• Tune the IP-protocol parameter accordingly.
Antivirus
• Enable only the protocols you need to scan. If you have antivirus scans occurring on
the SMTP server, or using FortiMail, it is redundant to have it occur on the FortiGate
unit as well.
• Reduce the maximum file size to be scanned. Viruses travel usually in small files of
around 1 to 2 megabytes.
• Antivirus scanning within an HA cluster can impact performance.
• Enable grayware scanning on UTM profiles tied to internet browsing.
• Do not quarantine files unless you regularly monitor and review them. This is otherwise
a waste of space and impacts performance.
• Use file patterns to avoid scanning where it is not required.
• Enable heuristics from the CLI if high security is required using the command
config antivirus heuristic.
Web filtering
• Web filtering within an HA cluster impacts performance.
• Always review the DNS settings to ensure the servers are fast.
• Content block may cause performance overhead.
• Local URL filter is faster than FortiGuard web filter, because the filter list is local and
the FortiGate unit does not need to go out to the Internet to get the information from a
FortiGuard web server.
Antispam
• If possible use, a FortiMail unit. The antispam engines are more robust.
• Use fast DNS servers.
• Use specific UTM profiles for the rule that will use antispam.

394 01-420-99686-20101026
Best Practices Security
• DNS checks may cause false positive with HELO DNS lookup.
• Content analysis (banned words) may impose performance overhead.
Security
• Use NTP to synchronize time on the FortiGate and the core network systems such as
email servers, web servers and logging services.
• Enable log rules to match corporate policy. For example, log administration
authentication events and access to systems from untrusted interfaces.
• Minimize adhoc changes to live systems if possible to minimize interruptions to the
network.
• When not possible, create backup configurations and implement sound audit systems
using FortiAnalyzer and FortiManager.
• If you only need to allow access to a system on a specific port, limit the access by
creating the strictest rule possible.

01-420-99686-20101026 395
Security Best Practices

396 01-420-99686-20101026
Monitoring
With network administration, the first step is installing and configuring the FortiGate unit to
be the protector of the internal network. Once the system is running efficiently, the next
step is to monitor the system and network traffic, to tweak leaks and abusers as well as
the overall health of the FortiGate unit(s) that provide that protection.
This chapter discusses the various methods of monitoring both the FortiGate unit and the
network traffic through a range of different tools available within FortiOS.
This chapter includes the topics:
• Dashboard
• sFlow
• Logging
• Alert email
• SNMP
• SNMP get command syntax
• Fortinet and FortiGate MIB fields
Dashboard
The FortiOS dashboard provides a location to view real-time system information. By
default, the dashboard displays the key statistics of the FortiGate unit itself, providing the
memory and CPU status, as well as the health of the ports, whether they are up or down
and their throughput.
Widgets
Within the dashboard is a number of smaller windows, called widgets, that provide this
status information. Beyond what is visible by default, you can add a number of other
widgets that display other key traffic information including application use, traffic per IP
address, top attacks, traffic history and logging statistics.
You will see when you log into the FortiGate unit, there are two separate dashboards. You
can add multiple dashboards to reflect what data you want to monitor, and add the widgets
accordingly. Dashboard configuration is only available through the web-based
manager.Administrators must have read and write privileges to customize and add
widgets when in either menu. Administrators must have read privileges if they want to view
the information.
To add a dashboard and widgets

1 Go to System > Dashboard.
2 Select the Dashboard menu at the top of the window and select Add Dashboard.
3 Enter a name such as Monitoring.
4 Select the Widget menu at the top of the window.
5 From the screen, select the type of information you want to add.
6 When done, select the X in the top right of the widget.

01-420-99686-20101026 397
sFlow Monitoring
Tip: You can position widgets within the dashboard frame by clicking and dragging it to a
different location.
sFlow
sFlow is a method of monitoring the traffic on your network to identify areas on the network
that may impact performance and throughput. sFlow is described in http://www.sflow.org.
FortiOS implements sFlow version 5. sFlow uses packet sampling to monitor network
traffic. That is, an sFlow Agent captures packet information at defined intervals and sends
them to an sFlow Collector for analysis, providing real-time data analysis. The information
sent is only a sampling of the data for minimal impact on network throughput and
performance.
The sFlow Agent is embedded in the FortiGate unit. Once configured, the FortiGate unit
sends sFlow datagrams of the sampled traffic to the sFlow Collector, also called an sFlow
Analyzer. The sFlow Collector receives the datagrams, and provides real-time analysis
and graphing to indicate where potential traffic issues are occurring. sFlow Collector
software is available from a number of third party software vendors.
sFlow data captures only a sampling of network traffic, not all traffic like the traffic logs on
the FortiGate unit. Sampling works by the sFlow Agent looking at traffic packets when they
arrive on an interface. A decision is made whether the packet is dropped, and sent on to
its destination, or a copy is forwarded to the sFlow Collector. The sample used and its
frequency are determined during configuration.
The sFlow datagram sent to the Collector contains the following information:
Packet header (e.g. MAC,IPv4,IPv6,IPX,AppleTalk,TCP,UDP, ICMP)
Sample process parameters (rate, pool etc.)
Input/output ports
• Priority (802.1p and TOS)
• VLAN (802.1Q)
• Source/destination prefix
• Next hop address
• Source AS, Source Peer AS
• Destination AS Path
• Communities, local preference
• User IDs (TACACS/RADIUS) for source/destination
• URL associated with source/destination
• Interface statistics (RFC 1573, RFC 2233, and RFC 2358)
sFlow agents can be added to any type of FortiGate interface. sFlow isn't supported on
some virtual interfaces such as VDOM link, IPSec, gre, and ssl.<vdom>.
For more information on sFlow, Collector software and sFlow MIBs, visit www.sflow.org.
Configuration
sFlow configuration is available only from the CLI. Configuration requires two steps:
enabling the sFlow Agent, and configuring the interface for the sampling information.

398 01-420-99686-20101026
Monitoring Logging
Enable sFlow
config system sflow
set collector-ip <ip_address>
set collector-port <port_number>
end
The default port for sFlow is UDP 6343. To configure in VDOM, use the following
commands:
config system vdom-sflow
set vdom-sflow enable
set collector-ip <ip_address>
set collector-port <port_number>
end
Configure sFlow agents per interface.
set sflow-sampler enable
set sample-rate <every_n_packets>
set sample-direction [tx | rx | both]
set polling-interval <seconds>
end
Logging
FortiOS provides a robust logging environment that enables you to monitor, store and
report traffic information and FortiGate events including attempted log ins and hardware
status. Depending on your requirements, you can log to a number of different hosts.
To configure logging in the web-based manager, go to Log & Report > Log Config > Log
Setting.
To configure logging in the CLI use the commands config log <log_location>.
For details on configuring logging see the accompanying FortiOS documentation and
FortiAnalyzer Administration Guide.
FortiGate memory
Inexpensive yet volatile, for basic event logs or verifying traffic, AV or spam patterns,
logging to memory is a simple option. However, because logs are stored in the limited
space of the internal memory, only a small amount is available for logs. As such logs can
fill up and be overridden with new entries, negating the use of recursive data. This is
especially true for traffic logs. Also, should the FortiGate unit be shut down or rebooted, all
log information will be lost.
FortiGate hard disk

For those FortiGate units with an internal hard disk, you can store logs to this location.
Efficient and local, the hard disk provides a convenient storage location. If you choose to
store logs in this manner, remember to backup the log data regularly. Typically there is
only one hard disk, and as such no RAID options are available.

01-420-99686-20101026 399
Alert email Monitoring
Syslog server
An industry standard for collecting log messages, for off site storage. In the web-based
manager, you are able to send logs to a single syslog server, however in the CLI you can
configure up to three syslog servers where you can also use multiple configuration
options. For example, send traffic logs to one server, antivirus logs to another.
FortiGuard Analysis and Management service

The FortiGuard Analysis and Management Service is a subscription based hosted service.
With this service, you can have centralized management, logging, and reporting
capabilities found in FortiAnalyzer and FortiManager platforms, without any additional
hardware to buy, install or maintain.
This service includes a full range of reporting, analysis and logging, firmware
management and configuration revision history. It is hosted within Fortinet's global
FortiGuard Network for maximum reliability and performance, and includes reporting, and
drill-down analysis widgets makes it easy to develop custom views of network and security
events.
FortiAnalyzer
The FortiAnalyzer family of logging, analyzing, and reporting appliances securely
aggregate log data from Fortinet devices and other syslog-compatible devices. Using a
comprehensive suite of easily-customized reports, users can filter and review records,
including traffic, event, virus, attack, Web content, and email data, mining the data to
determine your security stance and assure regulatory compliance. FortiAnalyzer also
provides advanced security management functions such as quarantined file archiving,
event correlation, vulnerability assessments, traffic analysis, and archiving of email, Web
access, instant messaging and file transfer content.
Alert email
As an administrator, you want to be certain you can respond quickly to issues occurring on
your network or on the FortiGate unit. Alert email provides an efficient and direct method
of notifying an administrator of events. By configuring alert messages, you can define the
threshold when a problem becomes critical and needs attention. When this threshold is
reached, the FortiGate unit will send an email to one or more individuals notifying them of
the issue.
In the following example, the FortiGate unit is configured to send email to two
administrators (admin1 and admin2) when multiple intrusions are detected every two
minutes. The FortiGate unit has its own email address on the mail server.

400 01-420-99686-20101026
Monitoring SNMP
To configure alert email - web-based manager

1 Go to Log&Report > Log Config > Alert E-mail.
2 Enter the following information.
SMTP Server Enter the address or name of the email server. For example,
smtp.example.com.
Email from fortigate@example.com
Email to admin1@example.com
admin2@example.com
Authentication Enable authentication if required by the email server.
SMTP User FortiGate
Password *********************
Interval Time 2
3 For the Interval Time, enter 2.

4 Select Intrusion Detected.
5 Select Apply.
To configure alert email - CLI

config system alert email
set port 25
set server smtp.example.com
set authenticate enable
set username FortiGate
set password *************
end
config alertemail setting
set username fortigate@example.com
set mailto1 admin1@example.com
set mailto2 admin2@example.com
set filter category
set IPS-logs enable
end
SNMP
Simple Network Management Protocol (SNMP) enables you to monitor hardware on your
network. You can configure the hardware, such as the FortiGate SNMP agent, to report
system information and send traps (alarms or event messages) to SNMP managers. An
SNMP manager, or host, is a typically a computer running an application that can read the
incoming trap and event messages from the agent and send out SNMP queries to the
SNMP agents. A FortiManager unit can act as an SNMP manager, or host, to one or more
FortiGate units.
By using an SNMP manager, you can access SNMP traps and data from any FortiGate
interface or VLAN subinterface configured for SNMP management access. Part of
configuring an SNMP manager is to list it as a host in a community on the FortiGate unit it
will be monitoring. Otherwise the SNMP monitor will not receive any traps from that
FortiGate unit, or be able to query that unit.

01-420-99686-20101026 401
SNMP Monitoring
The FortiGate SNMP implementation is read-only. SNMP v1, v2c, and v3 compliant SNMP
managers have read-only access to FortiGate system information through queries and
can receive trap messages from the FortiGate unit.
To monitor FortiGate system information and receive FortiGate traps, you must first
compile the Fortinet and FortiGate Management Information Base (MIB) files. A MIB is a
text file that describes a list of SNMP data objects that are used by the SNMP manager.
These MIBs provide information the SNMP manager needs to interpret the SNMP trap,
event, and query messages sent by the FortiGate unit SNMP agent. FortiGate core MIB
files are available on the Customer Support website.
The Fortinet implementation of SNMP includes support for most of RFC 2665
(Ethernet-like MIB) and most of RFC 1213 (MIB II). For more information, see “Fortinet
MIBs” on page 404. RFC support for SNMP v3 includes Architecture for SNMP
Frameworks (RFC 3411), and partial support of User-based Security Model (RFC 3414).
SNMP traps alert you to events that occur such as an a full log disk or a virus detected.
For more information about SNMP traps, see “Fortinet and FortiGate traps” on page 406.
SNMP fields contain information about the FortiGate unit, such as CPU usage percentage
or the number of sessions. This information is useful for monitoring the condition of the
unit on an ongoing basis and to provide more information when a trap occurs. For more
information about SNMP fields, see “Fortinet and FortiGate MIB fields” on page 409.
The FortiGate SNMP v3 implementation includes support for queries, traps,
authentication, and privacy. Authentication and encryption are configured in the CLI. See
the system snmp user command in the FortiGate CLI Reference.
SNMP agent
You need to first enter information and enable the FortiGate SNMP Agent. Enter
information about the FortiGate unit to identify it so that when your SNMP manager
receives traps from the FortiGate unit, you will know which unit sent the information.
To configure the SNMP agent - web-based manager

1 Go to System > Config > SNMP v1/v2c.
2 Select Enable for the SNMP Agent.
3 Enter a descriptive name for the agent.
4 Enter the location of the FortiGate unit.
5 Enter a contact or administrator for the SNMP Agent or FortiGate unit.
6 Select Apply.
To configure SNMP agent - CLI

config system snmp sysinfo
set status enable
set contact-info <contact_information>
set description <description_of_FortiGate>
set location <FortiGate_location>
end

402 01-420-99686-20101026
Monitoring SNMP
SNMP community
An SNMP community is a grouping of devices for network administration purposes. Within
that SNMP community, devices can communicate by sending and receiving traps and
other information. One device can belong to multiple communities, such as one
administrator terminal monitoring both a firewall SNMP community and a printer SNMP
community.
Add SNMP communities to your FortiGate unit so that SNMP managers can connect to
view system information and receive SNMP traps.
You can add up to three SNMP communities. Each community can have a different
configuration for SNMP queries and traps. Each community can be configured to monitor
the FortiGate unit for a different set of events. You can also add the IP addresses of up to
8 SNMP managers to each community.
Note: When the FortiGate unit is in virtual domain mode, SNMP traps can only be sent on
interfaces in the management virtual domain. Traps cannot be sent over other interfaces.
To add an SNMP community - web-based manager

2 Select Create New and enter a name.
3 Enter the IP address and Identify the SNMP managers that can use the settings in this
SNMP community to monitor the FortiGate unit.
4 Select the interface if the SNMP manager is not on the same subnet as the FortiGate
unit.
5 Enter the Port number that the SNMP managers in this community use for SNMP v1
and SNMP v2c queries to receive configuration information from the FortiGate unit.
Select the Enable check box to activate queries for each SNMP version.
6 Enter the Local and Remote port numbers that the FortiGate unit uses to send SNMP
v1 and SNMP v2c traps to the SNMP managers in this community.
7 Select the Enable check box to activate traps for each SNMP version.
8 Select OK.
To add an SNMP community - CLI

config system snmp community
edit <index_number>
set events <events_list>
set name <community_name>
set query-v1-port <port_number>
set query-v1-status {enable | disable}
set query-v2c-port <port_number>
set query-v2c-status {enable | disable}
set trap-v1-lport <port_number>
set trap-v1-rport <port_number>
set trap-v1-status {enable | disable}
set trap-v2c-lport <port_number>
set trap-v2c-rport <port_number>
set trap-v2c-status {enable | disable}
end

01-420-99686-20101026 403
SNMP Monitoring
Enabling on the interface

Before a remote SNMP manager can connect to the FortiGate agent, you must configure
one or more FortiGate interfaces to accept SNMP connections.
To configure SNMP access - web-based manager

2 Choose an interface that an SNMP manager connects to and select Edit.
3 In Administrative Access, select SNMP.
4 Select OK.
To configure SNMP access - CLI

set allowaccess snmp
end
Note: When using the allowaccess command to add SNMP, you need to also include any
other access for the interface. This command will only use what is entered. That is, if you
had HTTPS and SSH enabled before, these will be disabled if only the above command is
used. In this case, for the allow access command, enter
set allowaccess https ssh snmp.
Fortinet MIBs
The FortiGate SNMP agent supports Fortinet proprietary MIBs as well as standard RFC
1213 and RFC 2665 MIBs. RFC support includes support for the parts of RFC 2665
(Ethernet-like MIB) and the parts of RFC 1213 (MIB II) that apply to FortiGate unit
configuration.
There are two MIB files for FortiGate units - the Fortinet MIB, and the FortiGate MIB. The
Fortinet MIB contains traps, fields and information that is common to all Fortinet products.
The FortiGate MIB contains traps, fields and information that is specific to FortiGate units.
Each Fortinet product has its own MIB—if you use other Fortinet products you will need to
download their MIB files as well.
The Fortinet MIB and FortiGate MIB along with the two RFC MIBs are listed in tables in
this section. You can download the two FortiGate MIB files from Fortinet Customer
Support. The Fortinet MIB contains information for Fortinet products in general. the
Fortinet FortiGate MIB includes the system information for The FortiGate unit and version
of FortiOS. Both files are required for proper SNMP data collection.
To download the MIB files

1 Login to the Customer Support web site at support.fortinet.com.
2 Go to Download > Firmware Images.
3 Select FortiGate > v4.00 > Core MIB.
4 Select and download the Fortinet core MIB file.
5 Move up one directory level.
6 Select the firmware version, revision and patch (if applicable).
7 Select the MIB directory.
8 Select and download the Fortinet FortiGate MIB file.

404 01-420-99686-20101026
Monitoring SNMP get command syntax
Your SNMP manager may already include standard and private MIBs in a compiled
database that is ready to use. You must add the Fortinet proprietary MIB to this database
to have access to the Fortinet specific information.
Note: There were major changes to the MIB files between v3.0 and v4.0. You need to use
the new MIBs for v4.0 or you may mistakenly access the wrong traps and fields.
MIB files are updated for each version of FortiOS. When upgrading the firmware ensure
that you updated the Fortinet FortiGate MIB file as well.
Table 36: Fortinet MIBs
MIB file name or RFC Description

FORTINET-CORE-MIB.mib The Fortinet MIB includes all system configuration information
and trap information that is common to all Fortinet products.
Your SNMP manager requires this information to monitor
FortiGate unit configuration settings and receive traps from
the FortiGate SNMP agent. For more information, see
“Fortinet and FortiGate traps” on page 406 and “Fortinet and
FortiGate MIB fields” on page 409.
FORTINET-FORTIGATE-MIB.mib The FortiGate MIB includes all system configuration
information and trap information that is specific to FortiGate
units.
Your SNMP manager requires this information to monitor
FortiGate configuration settings and receive traps from the
FortiGate SNMP agent. FortiManager systems require this
MIB to monitor FortiGate units.
For more information, see “Fortinet and FortiGate traps” on
page 406 and “Fortinet and FortiGate MIB fields” on
page 409.
RFC-1213 (MIB II) The FortiGate SNMP agent supports MIB II groups with the
following exceptions.
• No support for the EGP group from MIB II (RFC 1213,
section 3.11 and 6.10).
• Protocol statistics returned for MIB II groups
(IP/ICMP/TCP/UDP/etc.) do not accurately capture all
FortiGate traffic activity. More accurate information can be
obtained from the information reported by the Fortinet
MIB.
RFC-2665 (Ethernet-like MIB) The FortiGate SNMP agent supports Ethernet-like MIB
information with the following exception.
No support for the dot3Tests and dot3Errors groups.
SNMP get command syntax

Normally, to get configuration and status information for a FortiGate unit, an SNMP
manager would use an SNMP get commands to get the information in a MIB field. The
SNMP get command syntax would be similar to the following:
snmpget -v2c -c <community_name> <address_ipv4> {<OID> |
<MIB_field>}
…where…
<community_name> is an SNMP community name added to the FortiGate configuration.
You can add more than one community name to a FortiGate SNMP configuration. The
most commonly used community name is public.
<address_ipv4> is the IP address of the FortiGate interface that the SNMP manager
connects to.

01-420-99686-20101026 405
SNMP get command syntax Monitoring
{<OID> | <MIB_field>} is the object identifier (OID) for the MIB field or the MIB field
name itself.
The following SNMP get command gets firmware version running on the FortiGate unit.
The community name is public. The IP address of the interface configured for SNMP
management access is 10.10.10.1. The firmware version MIB field is fgSysVersion
and the OID for this MIB field is 1.3.6.1.4.1.12356.101.4.1.1 The first command
uses the MIB field name and the second uses the OID:
snmpget -v2c -c public 10.10.10.1 fgSysVersion
snmpget -v2c -c public 10.10.10.1 1.3.6.1.4.1.12356.101.4.1.1
Fortinet and FortiGate traps

An SNMP manager can request information from the Fortinet device’s SNMP agent, or
that agent can send traps when an event occurs. Traps are a method used to inform the
SNMP manager that something has happened or changed on the Fortinet device.
To receive FortiGate device SNMP traps, you must load and compile the
FORTINET-CORE-MIB and FORTINET-FORTIGATE-MIB files into your SNMP manager.
Traps sent include the trap message as well as the FortiGate unit serial number
(fnSysSerial) and hostname (sysName).
The tables in this section include information about SNMP traps and variables. These
tables have been included to help you locate the object identifier number (OID), trap
message, and trap description of the Fortinet trap or variable you need.
The name of the table indicates if the trap is found in the Fortinet MIB or the FortiGate
MIB. The Trap Message column includes the message included with the trap as well as
the SNMP MIB field name to help locate the information about the trap. Traps starting with
fn such as fnTrapCpuThreshold are defined in the Fortinet MIB. Traps starting with fg
such as fgTrapAvVirus are defined in the FortiGate MIB.
The object identifier (OID) is made up of the number at the top of the table with the index
added to the end. For example if the OID is 1.3.6.1.4.1.12356.101.2.0 and the index is 4,
the full OID is 1.3.6.1.4.1.12356.101.2.0.4. The OID and the name of the object are how
SNMP managers refer to fields and traps from the Fortinet and FortiGate MIBs.
Indented rows are fields that are part of the message or table associated with the
preceding row.
The following tables include:
• Generic Fortinet traps (OID 1.3.6.1.4.1.12356.101.3.0)
• System traps (OID1.3.6.1.4.1.12356.1.3.0)
• FortiGate VPN traps (OID1.3.6.1.4.1.12356.1.3.0)
• FortiGate IPS traps (OID1.3.6.1.4.1.12356.1.3.0)
• FortiGate antivirus traps (OID1.3.6.1.4.1.12356.1.3.0)
• FortiGate HA traps (OID1.3.6.1.4.1.12356.1.3.0)
Table 37: Generic Fortinet traps (OID 1.3.6.1.4.1.12356.101.3.0)
Index Trap message Description

.1 ColdStart Standard traps as described in RFC 1215.
.2 WarmStart
.3 LinkUp
.4 LinkDown

406 01-420-99686-20101026
Monitoring SNMP get command syntax
Table 38: System traps (OID1.3.6.1.4.1.12356.1.3.0)

.101 CPU usage high CPU usage exceeds 80%. This threshold can be set in the
(fnTrapCpuThreshold) CLI using config system snmp sysinfo, set
trap-high-cpu-threshold.
.102 Memory low Memory usage exceeds 90%. This threshold can be set in
(fnTrapMemThreshold) the CLI using config system snmp sysinfo, set
trap-low-memory-threshold.
.103 Log disk too full Log disk usage has exceeded the configured threshold.
(fnTrapLogDiskThreshold) Only available on devices with log disks. This threshold can
be set in the CLI using config system snmp sysinfo,
set trap-log-full-threshold.
.104 Temperature too high A temperature sensor on the device has exceeded its
(fnTrapTempHigh) threshold. Not all devices have thermal sensors. See
manual for specifications.
.105 Voltage outside acceptable Power levels have fluctuated outside of normal levels. Not
range all devices have voltage monitoring instrumentation.
(fnTrapVoltageOutOfRange)
.106 Power supply failure Power supply failure detected. Not available on all models.
(fnTrapPowerSupplyFailure) Available on some devices which support redundant power
supplies.
.201 Interface IP change The IP address for an interface has changed.
(fnTrapIpChange) The trap message includes the name of the interface, the
new IP address and the serial number of the Fortinet unit.
You can use this trap to track interface IP address changes
for interfaces with dynamic IP addresses set using DHCP
or PPPoE.
.999 Diagnostic trap This trap is sent for diagnostic purposes.
(fnTrapTest) It has an OID index of .999.
Table 39: FortiGate VPN traps (OID1.3.6.1.4.1.12356.1.3.0)

.301 VPN tunnel is up An IPSec VPN tunnel has started.
(fgTrapVpnTunUp)
.302 VPN tunnel down An IPSec VPN tunnel has shut down.
(fgTrapVpnTunDown)
Local gateway address Address of the local side of the VPN tunnel.
(fgVpnTrapLocalGateway) This information is associated with both of the VPN
tunnel traps.
(OID1.3.6.1.4.1.12356.101.12.3.2)
Remote gateway address Address of remote side of the VPN tunnel.
(fgVpnTrapRemoteGateway) This information is associated with both of the VPN
tunnel traps.
(OID1.3.6.1.4.1.12356.101.12.3.2)
Table 40: FortiGate IPS traps (OID1.3.6.1.4.1.12356.1.3.0)

.503 IPS Signature IPS signature detected.
(fgTrapIpsSignature)
.504 IPS Anomaly IPS anomaly detected.
(fgTrapIpsAnomaly)
.505 IPS Package Update The IPS signature database has been updated.
(fgTrapIpsPkgUpdate)

01-420-99686-20101026 407
SNMP get command syntax Monitoring
Table 40: FortiGate IPS traps (OID1.3.6.1.4.1.12356.1.3.0)

(fgIpsTrapSigId) ID of IPS signature identified in trap.
(OID 1.3.6.1.4.1.12356.101.9.3.1)
(fgIpsTrapSrcIp) IP Address of the IPS signature trigger.
(OID 1.3.6.1.4.1.12356.101.9.3.2)
(fgIpsTrapSigMsg) Message associated with IPS event.
(OID 1.3.6.1.4.1.12356.101.9.3.3)
Table 41: FortiGate antivirus traps (OID1.3.6.1.4.1.12356.1.3.0)

.601 Virus detected The antivirus engine detected a virus in an infected file
(fgTrapAvVirus) from an HTTP or FTP download or from an email
message.
.602 Oversize file/email detected The antivirus scanner detected an oversized file.
(fgTrapAvOversize)
.603 Filename block detected The antivirus scanner blocked a file that matched a
(fgTrapAvPattern) known virus pattern.
.604 Fragmented file detected The antivirus scanner detected a fragmented file or
(fgTrapAvFragmented) attachment.
.605 (fgTrapAvEnterConserve) The AV engine entered conservation mode due to low
memory conditions.
.606 (fgTrapAvBypass) The AV scanner has been bypassed due to conservation
mode.
.607 (fgTrapAvOversizePass) An oversized file has been detected, but has been
passed due to configuration.
.608 (fgTrapAvOversizeBlock) An oversized file has been detected, and has been
blocked.
(fgAvTrapVirName) The virus name that triggered the event.
(OID1.3.6.1.4.1.12356.101.8.3.1)
Table 42: FortiGate HA traps (OID1.3.6.1.4.1.12356.1.3.0)

.401 HA switch The specified cluster member has switched from a slave
(fgTrapHaSwitch) role to a master role.
.402 HA State Change The trap sent when the HA cluster member changes its
(fgTrapHaStateChange) state.
.403 HA Heartbeat Failure The heartbeat failure count has exceeded the configured
(fgTrapHaHBFail) threshold.
.404 HA Member Unavailable An HA member becomes unavailable to the cluster.
(fgTrapHaMemberDown)
.405 HA Member Available An HA member becomes available to the cluster.
(fgTrapHaMemberUp)
(fgHaTrapMemberSerial) Serial number of an HA cluster member. Used to identify
the origin of a trap when a cluster is configured.
(OID1.3.6.1.4.1.12356.101.13.3.1)

408 01-420-99686-20101026
Monitoring Fortinet and FortiGate MIB fields
Fortinet and FortiGate MIB fields

The FortiGate MIB contains fields reporting the current FortiGate unit status information.
The following tables list the names of the MIB fields and describe the status information
available for each one. You can view more details about the information available from all
Fortinet and FortiGate MIB fields by compiling the FORTINET-CORE-MIB.mib and
FORTINET-FORTIGATE-MIB.mib files into your SNMP manager and browsing the MIB
fields on your computer.
To help locate a field, the object identifier (OID) number for each table of fields has been
included. The OID number for a field is that field’s position within the table, starting at 0.
For example fnSysVersion has an OID of 1.3.6.1.4.1.12356.2.
Fortinet MIB
Table 43: OIDs for the Fortinet-Core-MIB
MIB Field OID Description

fnSystem 1.3.6.1.4.1.12356.100.1.1
fnSysSerial 1.3.6.1.4.1.12356.100.1.1.1 Device serial number. This is
the same serial number as
given in the ENTITY-MIB
tables for the base entity.
fnMgmt .3.6.1.4.1.12356.100.1.2
fnMgmtLanguage 1.3.6.1.4.1.12356.100.1.2.1 Language used for
administration interfaces.
fnAdmin 1.3.6.1.4.1.12356.100.1.2.100
fnAdminNumber 1.3.6.1.4.1.12356.100.1.2.100.1 The number of admin
accounts in fnAdminTable.
fnAdminTable 1.3.6.1.4.1.12356.100.1.2.100.2 A table of administrator
accounts on the device. This
table is intended to be
extended with platform specific
information.
fnAdminEntry 1.3.6.1.4.1.12356.100.1.2.100.2.1 An entry containing
information applicable to a
particular admin account.
fnAdminIndex 1.3.6.1.4.1.12356.100.1.2.100.2.1.1 An index uniquely defining an
administrator account within
the fnAdminTable.
fmAdminName 1.3.6.1.4.1.12356.100.1.2.100.2.1.2 The user-name of the
specified administrator
account.
fnAddminAddrType 1.3.6.1.4.1.12356.100.1.2.100.2.1.3 The type of address stored in
fnAdminAddr, in compliance
with INET-ADDRESS-MIB
fnAdminAddr 1.3.6.1.4.1.12356.100.1.2.100.2.1.4 The address prefix identifying
where the administrator
account can be used from,
typically an IPv4 address. The
address type/format is
determined by
fnAdminAddrType.

01-420-99686-20101026 409
Fortinet and FortiGate MIB fields Monitoring

fnAdminMask 1.3.6.1.4.1.12356.100.1.2.100.2.1.5 The address prefix length (or
network mask) applied to the
fgAdminAddr to determine the
subnet or host the
administrator can access the
device from.
fnTraps 1.3.6.1.4.1.12356.100.1.3
fnTrapsPrefix 1.3.6.1.4.1.12356.100.1.3.0
fnTrapCpuThreshold 1.3.6.1.4.1.12356.100.1.3.0.101 Indicates that the CPU usage
has exceeded the configured
threshold.
fnTrapMemThreshold 1.3.6.1.4.1.12356.100.1.3.0.102 Indicates memory usage has
exceeded the configured
threshold.
fnTrapLogDiskThreshold 1.3.6.1.4.1.12356.100.1.3.0.103 Log disk usage has exceeded
the configured threshold. Only
available on devices with log
disks.
fnTrapTempHigh 1.3.6.1.4.1.12356.100.1.3.0.104 A temperature sensor on the
device has exceeded its
threshold. Not all devices have
thermal sensors. See manual
for specifications.
fnTrapVoltageOutOfRange 1.3.6.1.4.1.12356.100.1.3.0.105 Power levels have fluctuated
outside of normal levels. Not
all devices have voltage
monitoring instrumentation.
See manual for specifications.
fnTrapPowerSupplyFailure 1.3.6.1.4.1.12356.100.1.3.0.106 Power supply failure detected.
Not available on all models.
Available on some devices
which support redundant
power supplies. See manual
for specifications.
fnTrapIpChange 1.3.6.1.4.1.12356.100.1.3.0.201 Indicates that the IP address
of the specified interface has
been changed.
fnTrapTest 1.3.6.1.4.1.12356.100.1.3.0.999 Trap sent for diagnostic
purposes by an administrator.
fnTrapObjects 1.3.6.1.4.1.12356.100.1.3.1
fnGenTrapMsg 1.3.6.1.4.1.12356.100.1.3.1.1 Generic message associated
with an event. The content will
depend on the nature of the
trap.
fnMIBConformance 1.3.6.1.4.1.12356.100.10
fnSystemComplianceGroup 1.3.6.1.4.1.12356.100.10.1 Objects relating to the physical
device.
fnMgmtComplianceGroup 1.3.6.1.4.1.12356.100.10.2 Objects relating the
management of a device.
fnAdmincomplianceGroup 1.3.6.1.4.1.12356.100.10.3 Administration access control
objects.
fnTrapsComplianceGroup 1.3.6.1.4.1.12356.100.10.4 Event notifications.

410 01-420-99686-20101026

fnNotifObjectsComplianceG 1.3.6.1.4.1.12356.100.10.5 Object identifiers used in
roup notifications.
fnMIBCompliance 1.3.6.1.4.1.12356.100.10.100 Object identifiers used in
notifications. Objects are
required if their containing trap
is implemented.
FortiGate MIB
Table 44: OIDs for the Fortinet-FortiGate-MIB

fgModel 1.3.6.1.4.1.12356.101.1
fgTraps 1.3.6.1.4.1.12356.101.2
fgTrapPrefix 1.3.6.1.4.1.12356.101.2.0
fgTrapVpnTunup 1.3.6.1.4.1.12356.101.2.0.301 Indicates that the specified
VPN tunnel has been
brought up.
fgTrapVpnTunDown 1.3.6.1.4.1.12356.101.2.0.302 The specified VPN tunnel
has been brought down.
fgTrapHaSwitch 1.3.6.1.4.1.12356.101.2.0.401 The specified cluster
member has transitioned
from a slave role to a master
role.
fgTrapHaStateChange 1.3.6.1.4.1.12356.101.2.0.402 Trap being sent when the HA
cluster member changes its
state.
fgTrapHaBFail 1.3.6.1.4.1.12356.101.2.0.403 The heartbeat device failure
count has exceeded the
configured threshold.
fgTrapHaMemberDown 1.3.6.1.4.1.12356.101.2.0.404 The specified device (by
serial number) is moving to a
down state.
fgTrapHaMemberUp 1.3.6.1.4.1.12356.101.2.0.405 A new cluster member has
joined the cluster.
fgTrapIpsSignature 1.3.6.1.4.1.12356.101.2.0.503 An IPS signature has been
triggered.
fgTrapIpsAnomaly 1.3.6.1.4.1.12356.101.2.0.504 An IPS anomaly has been
detected.
fgTrapIpsPkgUpdate 1.3.6.1.4.1.12356.101.2.0.505 The IPS signature database
has been updated.
fgTrapAvVirus 1.3.6.1.4.1.12356.101.2.0.601 A virus has been detected by
the antivirus engine.
fgTrapAvOversize 1.3.6.1.4.1.12356.101.2.0.602 An oversized file has been
detected by the antivirus
engine.
fgTrapAvPattern 1.3.6.1.4.1.12356.101.2.0.603 The antivirus engine has
blocked a file because it
matched a configured
pattern.
fgTrapAvFragmented 1.3.6.1.4.1.12356.101.2.0.604 The antivirus engine has
detected a fragmented file.

01-420-99686-20101026 411

fgTrapAvEnterConserve 1.3.6.1.4.1.12356.101.2.0.605 The antivirus engine has
entered conservation mode
due to low memory
conditions.
fgTrapAvBypass 1.3.6.1.4.1.12356.101.2.0.606 The antivirus engine has
been bypassed due to
conservation mode.
fgTrapAvOversizePass 1.3.6.1.4.1.12356.101.2.0.607 An oversized file has been
detected, but has been
passed due to configuration.
fgTrapAvOversizeBlock 1.3.6.1.4.1.12356.101.2.0.608 An oversized file has been
detected and has been
blocked.
fgTrapFazDisconnect 1.3.6.1.4.1.12356.101.2.0.701 The device has been
disconnected from the
FortiAnalyzer.
Virtual Domains
fgVirtualDomain 1.3.6.1.4.1.12356.101.3
fgVdInfo 1.3.6.1.4.1.12356.101.3.1
fgVdNumber 1.3.6.1.4.1.12356.101.3.1.1 The number of virtual
domains in vdTable.
fgVdMaxVdoms 1.3.6.1.4.1.12356.101.3.1.2 The maximum number of
virtual domains allowed on
the device as allowed by
hardware and/or licensing.
fgVdEnabled 1.3.6.1.4.1.12356.101.3.1.3 Whether virtual domains are
enabled on this device.
fgVdTables 1.3.6.1.4.1.12356.101.3.2
fgVdTable 1.3.6.1.4.1.12356.101.3.2.1
fgVdEntry 1.3.6.1.4.1.12356.101.3.2.1.1 An entry containing
particular virtual domain.
fgVdEntIndex 1.3.6.1.4.1.12356.101.3.2.1.1.1 Internal virtual domain index
used to uniquely identify
rows in this table. This index
is also used by other tables
referencing a virtual domain.
fgVdEntName 1.3.6.1.4.1.12356.101.3.2.1.1.2 The name of the virtual
domain.
fgVdEntOpMode 1.3.6.1.4.1.12356.101.3.2.1.1.3 Operation mode of the
virtual domain (NAT or
Transparent).
fgVdTpTable 1.3.6.1.4.1.12356.101.3.2.2 A table of virtual domains in
transparent operation mode.
This table has a dependent
relationship with fgVdTable.
fgVdTpEntry 1.3.6.1.4.1.12356.101.3.2.2.1 An entry containing
particular virtual domain in
transparent mode.
fgVdTpMgmtAddrType 1.3.6.1.4.1.12356.101.3.2.2.1.1 The type of address stored
in fgVdTpMgmtAddr, in
compliance with INET-
ADDRESS-MIB.

412 01-420-99686-20101026

fgVdTpMgmtAddr 1.3.6.1.4.1.12356.101.3.2.2.1.2 The management IP
address of the virtual domain
in transparent mode,
typically an IPv4
address.The address
type/format is determined by
fgVdTpMgmtAddrType.
fgVdTpMgmtMask 1.3.6.1.4.1.12356.101.3.2.2.1.3 The address prefix length (or
network mask) applied to the
fgVdTpMgmtAddr.
System
fgSystem 1.3.6.1.4.1.12356.101.4
fgSystemInfo 1.3.6.1.4.1.12356.101.4.1
fgSysVersion 1.3.6.1.4.1.12356.101.4.1.1 Firmware version.
fgSysMgmtVdom 1.3.6.1.4.1.12356.101.4.1.2 Index that identifies the
management virtual domain.
This index corresponds to
the index used by fgVdTable.
fgSysCpuUsage 1.3.6.1.4.1.12356.101.4.1.3 Current CPU usage
(percentage).
fgSysMemUsage 1.3.6.1.4.1.12356.101.4.1.4 Current memory usage
(percentage).
fgSysMemCapacity 1.3.6.1.4.1.12356.101.4.1.5 Total physical RA installed
(KB)
fgSysDiskUsage 1.3.6.1.4.1.12356.101.4.1.6 Current hard disk usage
(MB), if disk is present.
fgSysDiskCapacity 1.3.6.1.4.1.12356.101.4.1.7 Total hard disk capacity
(MB), if disk is present.
fgSysSesCount 1.3.6.1.4.1.12356.101.4.1.8 Number of active sessions
on the device.
fgSysLowMemUsage 1.3.6.1.4.1.12356.101.4.1.9 Current lowmem utilization
(percentage). Lowmem is
memory available for the
kernel's own data structures
and kernel specific tables.
The system can get into a
bad state if it runs out of
lowmem.
fgSysLowMemCapacity 1.3.6.1.4.1.12356.101.4.1.10 Total lowmem capacity (KB).
Firewall
fgFirewal 1.3.6.1.4.1.12356.101.5
fgFwPolicies 1.3.6.1.4.1.12356.101.5.1
fgFwPolInfo 1.3.6.1.4.1.12356.101.5.1.1
fgFwPolTables 1.3.6.1.4.1.12356.101.5.1.2
fgFwPolStatsTable 1.3.6.1.4.1.12356.101.5.1.2.1 Firewall policy statistics
table. This table has a
dependent expansion
Only virtual domains with
enabled policies are present
in this table.
fgFwPolStatsEntry 1.3.6.1.4.1.12356.101.5.1.2.1.1 Firewall policy statistics on a
virtual domain.

01-420-99686-20101026 413

fgFwPolID 1.3.6.1.4.1.12356.101.5.1.2.1.1.1 Firewall policy ID. Only
enabled policies are present
in this table. Policy IDs are
only unique within a virtual
domain.
fgFwPolPktCount 1.3.6.1.4.1.12356.101.5.1.2.1.1.2 Number of packets matched
to policy (passed or blocked,
depending on policy action).
Count is from the time the
policy became active.
fgFwPolByteCount 1.3.6.1.4.1.12356.101.5.1.2.1.1.3 Number of bytes in packets
matching the policy. See
fgFwPolPktCount.
fgFwUsers 1.3.6.1.4.1.12356.101.5.2
fgFwUserInfo 1.3.6.1.4.1.12356.101.5.2.1
fgFwUserNumber 1.3.6.1.4.1.12356.101.5.2.1.1 The number of user
accounts in fgFwUserTable.
fgFwUserAuthTimeout 1.3.6.1.4.1.12356.101.5.2.1.2 Idle period after which a
firewall-authentication user's
session is automatically
expired.
fgFwUserTables 1.3.6.1.4.1.12356.101.5.2.2
fgFwUserTable 1.3.6.1.4.1.12356.101.5.2.2.1 A list of local and proxy
(Radius server) user
accounts for use with firewall
user authentication.
fgFwUserEntry 1.3.6.1.4.1.12356.101.5.2.2.1.1 An entry containing
particular user account.
fgFwUserIndex 1.3.6.1.4.1.12356.101.5.2.2.1.1.1 An index for uniquely
identifying the users in
fgFwUserTable.
fgFwUserName 1.3.6.1.4.1.12356.101.5.2.2.1.1.2 User name of the specified
account.
fgFwUserAuth 1.3.6.1.4.1.12356.101.5.2.2.1.1.3 Type of authentication the
account uses (local,
RADIUS, LDAP, etc.).
fgFwUserState 1.3.6.1.4.1.12356.101.5.2.2.1.1.4 Status of the user account
(enabled/disabled).
fgFwUserVdom 1.3.6.1.4.1.12356.101.5.2.2.1.1.5 Virtual domain the user
account exists in. This index
corresponds to the index
used in fgVdTable.
FortiManager and Administration
fgMgmt 1.3.6.1.4.1.12356.101.6
fgFmTrapPrefix 1.3.6.1.4.1.12356.101.6.0
fgFmTrapDeployComplete 1.3.6.1.4.1.12356.101.6.0.1000 Indicates when deployment
of a new configuration has
been completed. Used for
verification by FortiManager.
fgFmTrapDeployInProgress 1.3.6.1.4.1.12356.101.6.0.1002 Indicates that a configuration
change was not immediate
and that the change is
currently in progress. Used
for verification by
FortiManager.

414 01-420-99686-20101026

fgFmTrapConfChange 1.3.6.1.4.1.12356.101.6.0.1003 The device configuration has
been changed by something
other than the managing
FortiManager unit.
fgFmTrapIfChange 1.3.6.1.4.1.12356.101.6.0.1004 Trap is sent to the managing
FortiManager if an interface
IP is changed.
fgAdmin 1.3.6.1.4.1.12356.101.6.1
fgAdminOptions 1.3.6.1.4.1.12356.101.6.1.1
fgAdminIdleTimeout 1.3.6.1.4.1.12356.101.6.1.1.1 Idle period after which an
administrator is
automatically logged out of
the system.
fgAdminLcdProtection 1.3.6.1.4.1.12356.101.6.1.1.2 Status of the LCD protection
(enabled/disabled).
fgAdminTables 1.3.6.1.4.1.12356.101.6.1.2
fgAdminTable 1.3.6.1.4.1.12356.101.6.1.2.1 A table of administrator
accounts on the device.
fgAdminEntry 1.3.6.1.4.1.12356.101.6.1.2.1.1 An entry containing
particular admin account.
fgAdminVdom 1.3.6.1.4.1.12356.101.6.1.2.1.1.1 The virtual domain the
administrator belongs to.
fgMgmtTrapObjects 1.3.6.1.4.1.12356.101.6.2
fgManIfIp 1.3.6.1.4.1.12356.101.6.2.1 IP address of the interface
listed in the trap.
fgManIfMask 1.3.6.1.4.1.12356.101.6.2.2 Mask of subnet the interface
belongs to.
Antivirus
fgAntivirus 1.3.6.1.4.1.12356.101.8
fgAvInfo 1.3.6.1.4.1.12356.101.8.1
fgAvTables 1.3.6.1.4.1.12356.101.8.2
fgAvStatsTable 1.3.6.1.4.1.12356.101.8.2.1 A table of Antivirus statistics
per virtual domain.
fgAvStatsEntry 1.3.6.1.4.1.12356.101.8.2.1.1 Antivirus statistics for a
fgAvVirusDetected 1.3.6.1.4.1.12356.101.8.2.1.1.1 Number of virus
transmissions detected in
the virtual domain since start
up.
fgAvVirusBlocked 1.3.6.1.4.1.12356.101.8.2.1.1.2 Number of virus
transmissions blocked in the
virtual domain since start up.
fgAvHTTPVirusDetected 1.3.6.1.4.1.12356.101.8.2.1.1.3 Number of virus
transmissions over HTTP
detected in the virtual
domain since start up.
fgAvHTTPVirusBlocked 1.3.6.1.4.1.12356.101.8.2.1.1.4 Number of virus
transmissions over HTTP
blocked in the virtual domain
since start up.

01-420-99686-20101026 415

fgAvSMTPVirusDetected 1.3.6.1.4.1.12356.101.8.2.1.1.5 Number of virus
transmissions over SMTP
fgAvSMTPVirusBlocked 1.3.6.1.4.1.12356.101.8.2.1.1.6 Number of virus
transmissions over SMTP
since start up.
fgAvPOP3VirusDetected 1.3.6.1.4.1.12356.101.8.2.1.1.7 Number of virus
transmissions over POP3
fgAvPOP3VirusBlocked 1.3.6.1.4.1.12356.101.8.2.1.1.8 Number of virus
transmissions over POP3
since start up.
fgAvIMAPVirusDetected 1.3.6.1.4.1.12356.101.8.2.1.1.9 Number of virus
transmissions over IMAP
fgAvIMAPVirusBlocked 1.3.6.1.4.1.12356.101.8.2.1.1.10 Number of virus
transmissions over IMAP
since start up.
fgAvFTPVirusDetected 1.3.6.1.4.1.12356.101.8.2.1.1.11 Number of virus
transmissions over FTP
fgAvFTPVirusBlocked 1.3.6.1.4.1.12356.101.8.2.1.1.12 Number of virus
transmissions over FTP
since start up.
fgAvIMVirusDetected 1.3.6.1.4.1.12356.101.8.2.1.1.13 Number of virus
transmissions over IM
protocols detected in the
fgAvIMVirusBlocked 1.3.6.1.4.1.12356.101.8.2.1.1.14 Number of virus
transmissions over IM
protocols blocked in the
fgAvNNTPVirusDetected 1.3.6.1.4.1.12356.101.8.2.1.1.15 Number of virus
transmissions over NNTP
fgAvNNTPVirusBlocked 1.3.6.1.4.1.12356.101.8.2.1.1.16 Number of virus
transmissions over NNTP
since start up.
fgAvOversizedDetected 1.3.6.1.4.1.12356.101.8.2.1.1.17 Number of over-sized file
transmissions detected in
the virtual domain since start
up.
fgAvOversizedBlocked 1.3.6.1.4.1.12356.101.8.2.1.1.18 Number of over-sized file
transmissions blocked in the
fgAvTrapObjects 1.3.6.1.4.1.12356.101.8.3
fgAvTrapVirName 1.3.6.1.4.1.12356.101.8.3.1 Virus name that triggered
event.
IPS
416 01-420-99686-20101026

fgIps 1.3.6.1.4.1.12356.101.9
fgIpsInfo 1.3.6.1.4.1.12356.101.9.1
fgIpsTables 1.3.6.1.4.1.12356.101.9.2
fgIpsStatsTable 1.3.6.1.4.1.12356.101.9.2.1 A table of IPS/IDS statistics
per virtual domain.
fgIpsStatsEntry 1.3.6.1.4.1.12356.101.9.2.1.1 IPS/IDS statistics for a
fgIpsIntrusionDetected 1.3.6.1.4.1.12356.101.9.2.1.1.1 Number of intrusions
detected since start up in
this virtual domain.
fgIpsIntrusionBlocked 1.3.6.1.4.1.12356.101.9.2.1.1.2 Number of intrusions
blocked since start up in this
virtual domain.
fgIpsCritSevDetections 1.3.6.1.4.1.12356.101.9.2.1.1.3 Number of critical severity
intrusions detected since
start up in this virtual
domain.
fgIpsHighSevDetections 1.3.6.1.4.1.12356.101.9.2.1.1.4 Number of high severity
domain.
fgIpsMedSevDetections 1.3.6.1.4.1.12356.101.9.2.1.1.5 Number of medium severity
domain.
fgIpsLowSevDetections 1.3.6.1.4.1.12356.101.9.2.1.1.6 Number of low severity
domain.
fgIpsInfoSevDetections 1.3.6.1.4.1.12356.101.9.2.1.1.7 Number of informational
severity intrusions detected
since start up in this virtual
domain.
fgIpsSignatureDetections 1.3.6.1.4.1.12356.101.9.2.1.1.8 Number of intrusions
detected by signature since
domain.
fgIpsAnomalyDetections 1.3.6.1.4.1.12356.101.9.2.1.1.9 Number of intrusions
detected as anomalies since
domain.
fgIpsTrapObjects 1.3.6.1.4.1.12356.101.9.3
fgIpsTrapSigId 1.3.6.1.4.1.12356.101.9.3.1 ID of IPS signature identified
in trap.
fgIpsTrapSrcIp 1.3.6.1.4.1.12356.101.9.3.2 Source IP Address of the
IPS signature trigger.
fgIpsTrapSigMsg 1.3.6.1.4.1.12356.101.9.3.3 Message associated with
IPS event.
Application Control
fgApplications 1.3.6.1.4.1.12356.101.10
fgWebfilter 1.3.6.1.4.1.12356.101.10.1
fgWebfilterInfo 1.3.6.1.4.1.12356.101.10.1.1
fgWebfilterTables 1.3.6.1.4.1.12356.101.10.1.2

01-420-99686-20101026 417

fgWebfilterStatsTable 1.3.6.1.4.1.12356.101.10.1.2.1 A table of Web filter statistics
per virtual domain.
fgWebfilterStatsEntry 1.3.6.1.4.1.12356.101.10.1.2.1.1 Web filter statistics for a
fgWfHTTPBlocked 1.3.6.1.4.1.12356.101.10.1.2.1.1.1 Number of HTTP sessions
blocked by Web filter since
start up.
fgWfHTTPSBlocked 1.3.6.1.4.1.12356.101.10.1.2.1.1.2 Number of HTTPS sessions
start up.
fgWfHTTPURLBlocked 1.3.6.1.4.1.12356.101.10.1.2.1.1.3 Number of HTTP URLs
start up.
fgWfHTTPSURLBlocked 1.3.6.1.4.1.12356.101.10.1.2.1.1.4 Number of HTTPS URLs
start up.
fgWfActiveXBlocked 1.3.6.1.4.1.12356.101.10.1.2.1.1.5 Number of ActiveX
downloads blocked by Web
filter since start up.
fgWfCookieBlocked 1.3.6.1.4.1.12356.101.10.1.2.1.1.6 Number of HTTP Cookies
start up.
fgWfAppletBlocked 1.3.6.1.4.1.12356.101.10.1.2.1.1.7 Number of Applets blocked
by Web-filter since start up.
fgFortiGuardStatsTable 1.3.6.1.4.1.12356.101.10.1.2.2 A table of FortiGuard
statistics per virtual domain.
fgFortiGuardStatsEntry 1.3.6.1.4.1.12356.101.10.1.2.2.1 FortiGuard statistics for a
fgFgWfHTTPExamined 1.3.6.1.4.1.12356.101.10.1.2.2.1.1 Number of HTTP requests
examined using FortiGuard
since start up.
fgFgWfHTTPSExamined 1.3.6.1.4.1.12356.101.10.1.2.2.1.2 Number of HTTPS requests
examined using FortiGuard
since start up.
fgFgWfHTTPAllowed 1.3.6.1.4.1.12356.101.10.1.2.2.1.3 Number of HTTP requests
allowed to proceed using
FortiGuard since start up.
fgFgWfHTTPSAllowed 1.3.6.1.4.1.12356.101.10.1.2.2.1.4 Number of HTTPS requests
allowed to proceed using
FortiGuard since start up.
fgFgWfHTTPBlocked 1.3.6.1.4.1.12356.101.10.1.2.2.1.5 Number of HTTP requests
blocked using FortiGuard
since start up.
fgFgWfHTTPSBlocked 1.3.6.1.4.1.12356.101.10.1.2.2.1.6 Number of HTTPS requests
blocked using FortiGuard
since start up.
fgFgWfHTTPLogged 1.3.6.1.4.1.12356.101.10.1.2.2.1.7 Number of HTTP requests
logged using FortiGuard
since start up.
fgFgWfHTTPSLogged 1.3.6.1.4.1.12356.101.10.1.2.2.1.8 Number of HTTPS requests
logged using FortiGuard
since start up.
fgFgWfHTTPOverridden 1.3.6.1.4.1.12356.101.10.1.2.2.1.9 Number of HTTP requests
overridden using FortiGuard
since start up.

418 01-420-99686-20101026

fgFgWfHTTPSOverridden 1.3.6.1.4.1.12356.101.10.1.2.2.1.10 Number of HTTPS requests
overridden using FortiGuard
since start up.
fgAppProxyHTTP 1.3.6.1.4.1.12356.101.10.100
fgApHTTPUpTime 1.3.6.1.4.1.12356.101.10.100.1 HTTP proxy up-time,
in seconds.
fgApHTTPMemUsage 1.3.6.1.4.1.12356.101.10.100.2 HTTP proxy memory usage
(percentage of system total).
fgApHTTPStatsTable 1.3.6.1.4.1.12356.101.10.100.3 A table of HTTP Proxy
fgApHTTPStatsEntry 1.3.6.1.4.1.12356.101.10.100.3.1 HTTP Proxy statistics for a
fgApHRRPReqProcessed 1.3.6.1.4.1.12356.101.10.100.3.1.1 Number of HTTP requests in
this virtual domain
processed by the HTTP
proxy since start up.
fgApHTTPConnections 1.3.6.1.4.1.12356.101.10.100.4 HTTP proxy current
connections.
fgAppProxySMTP 1.3.6.1.4.1.12356.101.10.101
fgApSMTPUpTime 1.3.6.1.4.1.12356.101.10.101.1 SMTP Proxy up-time, in
seconds.
fgAPSMTPMemUsage 1.3.6.1.4.1.12356.101.10.101.2 SMTP Proxy memory
utilization (percentage of
system total).
fgApSMTPStatsTable 1.3.6.1.4.1.12356.101.10.101.3 A table of SMTP proxy
fgApSMTPStatsEntry 1.3.6.1.4.1.12356.101.10.101.3.1 SMTP Proxy statistics for a
fgApSMTPReqProcessed 1.3.6.1.4.1.12356.101.10.101.3.1.1 Number of requests in this
virtual domain processed by
the SMTP proxy since
start up.
fgApSMTPSpamDetected 1.3.6.1.4.1.12356.101.10.101.3.1.2 Number of spam detected in
this virtual domain by the
SMTP proxy since start up.
fgApSMTPConnections 1.3.6.1.4.1.12356.101.10.101.4 SMTP proxy current
connections.
fgAppProxyPOP3 1.3.6.1.4.1.12356.101.10.102
fgApPOP3UpTime 1.3.6.1.4.1.12356.101.10.102.1 Up time of the POP3 proxy,
in seconds.
fgApPOP3MemUsage 1.3.6.1.4.1.12356.101.10.102.2 Memory usage of the POP3
Proxy (percentage of system
total).
fgApPOP3StatsTable 1.3.6.1.4.1.12356.101.10.102.3 A table of POP3 proxy
fgApPOP3StatsEntry 1.3.6.1.4.1.12356.101.10.102.3.1 Proxy pop3 statistics for a
fgApPOP3ReqProcessed 1.3.6.1.4.1.12356.101.10.102.3.1.1 Number of requests in this
the POP3 proxy since
start up.
fgApPOP3SpamDetected 1.3.6.1.4.1.12356.101.10.102.3.1.2 Number of spam detected in
POP3 Proxy since start up.

01-420-99686-20101026 419

fgApPOP3Connections 1.3.6.1.4.1.12356.101.10.102.4 POP3 proxy current
connections.
fgAppProxyIMAP 1.3.6.1.4.1.12356.101.10.103
fgApIMAPUpTime 1.3.6.1.4.1.12356.101.10.103.1 Up time of the IMAP proxy, in
seconds.
fgapIMAPMemUsage 1.3.6.1.4.1.12356.101.10.103.2 Memory utilization of the
IMAP Proxy (as a
percentage of the system
total).
fgApIMAPStatsTable 1.3.6.1.4.1.12356.101.10.103.3 A table of IMAP proxy
fgApIMAPStatsEntry 1.3.6.1.4.1.12356.101.10.103.3.1 IMAP Proxy statistics for a
fgApIMAPReqProcessed 1.3.6.1.4.1.12356.101.10.103.3.1.1 Number of requests in this
the IMAP proxy since start
up.
fgApIMAPSpamDetected 1.3.6.1.4.1.12356.101.10.103.3.1.2 Number of spam detected in
IMAP proxy since start up.
fgApIMAPConnections 1.3.6.1.4.1.12356.101.10.103.4 IMAP proxy current
connections.
fgAppProxyNNTP 1.3.6.1.4.1.12356.101.10.104
fgApNNTPUpTime 1.3.6.1.4.1.12356.101.10.104.1 Up time of the NNTP proxy,
in seconds.
fgApNNTPMemUsage 1.3.6.1.4.1.12356.101.10.104.2 Memory utilization of the
NNTP proxy, as a
percentage of the system
total.
fgApNNTPStatsTable 1.3.6.1.4.1.12356.101.10.104.3 A table of NNTP proxy
fgApNNTPStatsEntry 1.3.6.1.4.1.12356.101.10.104.3.1 NNTP Proxy statistics for a
fgApNNTPReqProcessed 1.3.6.1.4.1.12356.101.10.104.3.1.1 Number of requests in the
the NNTP proxy since
start up.
fgApNNTPConnections 1.3.6.1.4.1.12356.101.10.104.4 NNTP proxy current
connections.
fgAppProxyIM 1.3.6.1.4.1.12356.101.10.105
fgApIMUpTime 1.3.6.1.4.1.12356.101.10.105.1 Up time of the IM proxy, in
seconds.
fgApIMMemUsage 1.3.6.1.4.1.12356.101.10.105.2 IM Proxy memory usage, as
a percentage of the system
total.
fgApIMStatsTable 1.3.6.1.4.1.12356.101.10.105.3 A table of IM proxy statistics
per virtual domain.
fgApIMStatsEntry 1.3.6.1.4.1.12356.101.10.105.3.1 IM Proxy statistics for a
fgApIMReqProcessed 1.3.6.1.4.1.12356.101.10.105.3.1.1 Number of requests in this
the IM proxy since start up.
fgAppProxySIP 1.3.6.1.4.1.12356.101.10.106

420 01-420-99686-20101026

fgApSIPUpTime 1.3.6.1.4.1.12356.101.10.106.1 Up time of the SIP Proxy, in
seconds.
fgApSIPMemUsage 1.3.6.1.4.1.12356.101.10.106.2 SIP Proxy memory
utilization, as a percentage
of the system total.
fgApSIPStatsTable 1.3.6.1.4.1.12356.101.10.106.3 A table of SIP proxy
fgApSIPStatsEntry 1.3.6.1.4.1.12356.101.10.106.3.1 SIP Proxy statistics for a
fgApSIPClientReg 1.3.6.1.4.1.12356.101.10.106.3.1.1 Number of client registration
requests (Register and
Options) in this virtual
domain processed by the
SIP proxy since start up.
fgApSIPCallHandling 1.3.6.1.4.1.12356.101.10.106.3.1.2 Number of call handling
requests (Invite, Ack, Bye,
Cancel and Refer) in this
the SIP proxy since start up.
fgApSIPServices 1.3.6.1.4.1.12356.101.10.106.3.1.3 Number of service requests
(Subscribe, notify and
Message) in this virtual
domain processed by the
SIP proxy since start up.
fgApSIPOtherReq 1.3.6.1.4.1.12356.101.10.106.3.1.4 Number of other sip requests
in this virtual domain
processed by the SIP proxy
since start up.
fgAppScanUnit 1.3.6.1.4.1.12356.101.10.107
fgAppSuNumber 1.3.6.1.4.1.12356.101.10.107.1 The number of scan units in
the fgAppSuStatsTable.
fgAppSuStatsTable 1.3.6.1.4.1.12356.101.10.107.2 A table of scan unit statistics.
fgAppSuStatsEntry 1.3.6.1.4.1.12356.101.10.107.2.1 Statistics entry for a
particular scan unit.
fgAppSuIndex 1.3.6.1.4.1.12356.101.10.107.2.1.1 Index that uniquely identifies
a scan unit in the
fgAppSuStatsTable.
fgAppSuFileScanned 1.3.6.1.4.1.12356.101.10.107.2.1.2 Number of files scanned by
this scan unit.
fgAppVoIP 1.3.6.1.4.1.12356.101.10.108
fgAppVoIPStatsTable 1.3.6.1.4.1.12356.101.10.108.1 A table of VoIP related
fgAppVoPStatsEntry 1.3.6.1.4.1.12356.101.10.108.1.1 VoIP statistics for a particular
virtual domain.
fgAppVoIPConn 1.3.6.1.4.1.12356.101.10.108.1.1.1 The current number of VoIP
connections on the virtual
domain.
fgAppVoIPCallBlocked 1.3.6.1.4.1.12356.101.10.108.1.1.2 Number of VoIP calls
blocked (SIP Invites blocked
and SCCP calls blocked) in
this virtual domain.
fgAppP2P 1.3.6.1.4.1.12356.101.10.109
fgAppP2PStatsTable 1.3.6.1.4.1.12356.101.10.109.1 A table of P2P protocol
related statistics per virtual
domain.

01-420-99686-20101026 421

fgAppP2PStatsEntry 1.3.6.1.4.1.12356.101.10.109.1.1 P2P statistics for a particular
virtual domain.
fgAppP2PConnBlocked 1.3.6.1.4.1.12356.101.10.109.1.1.1 Number of P2P connections
blocked in this virtual
domain.
fgAppP2PProtoTable 1.3.6.1.4.1.12356.101.10.109.2 A table of peer to peer
statistics per virtual domain
per protocol. This table has a
dependent expansion
fgAppP2PProtoEntry 1.3.6.1.4.1.12356.101.10.109.2.1 P2P statistics for a particular
virtual domain and protocol.
fgAppP2PProtoEntProto 1.3.6.1.4.1.12356.101.10.109.2.1.1 P2P protocol this row of
statistics is for, within the
specified virtual domain.
fgAppP2PProtoEntBytes 1.3.6.1.4.1.12356.101.10.109.2.1.2 Number of bytes transferred
through this virtual domain
on this P2P protocol since
last reset.
fgAppP2PProtoEntLastReset 1.3.6.1.4.1.12356.101.10.109.2.1.3 Time elapsed since the
corresponding
fgAppP2PProtEntBytes was
last reset to 0.
fgAppIM 1.3.6.1.4.1.12356.101.10.110
fgAppIMStatsTable 1.3.6.1.4.1.12356.101.10.110.1 A table of instant messaging
fgAppIMStatsEntry 1.3.6.1.4.1.12356.101.10.110.1.1 IM statistics for a particular
virtual domain.
fgAppIMMessages 1.3.6.1.4.1.12356.101.10.110.1.1.1 Total number of IM
messages processed in this
virtual domain.
fgAppIMFileTransfered 1.3.6.1.4.1.12356.101.10.110.1.1.2 Number of files transferred
through this virtual domain.
fgAppIMFileTxBlocked 1.3.6.1.4.1.12356.101.10.110.1.1.3 Number of blocked file
transfers in this virtual
domain.
fgAppIMConnBlocked 1.3.6.1.4.1.12356.101.10.110.1.1.4 Number of connections
blocked in this virtual
domain.
fgAppProxyFTP 1.3.6.1.4.1.12356.101.10.111
fgApFTPUpTime 1.3.6.1.4.1.12356.101.10.111.1 Up time of the FTP proxy, in
seconds.
fgApFTPMemUsage 1.3.6.1.4.1.12356.101.10.111.2 FTP Proxy memory
utilization, as a percentage
of the system total.
fgApFTPStatsTable 1.3.6.1.4.1.12356.101.10.111.3 A table of FTP proxy
fgApFTPStatsEntry 1.3.6.1.4.1.12356.101.10.111.3.1 FTP Proxy statistics for a
fgApFTPReqProcessed 1.3.6.1.4.1.12356.101.10.111.3.1.1 Number of requests in this
the FTP proxy since start up.
fgApFTPConnections 1.3.6.1.4.1.12356.101.10.111.4 FTP proxy current
connections.
Protocol and Session Table

422 01-420-99686-20101026

fgInetProto 1.3.6.1.4.1.12356.101.11
fgInetProtoInfo 1.3.6.1.4.1.12356.101.11.1
fgInetProtoTables 1.3.6.1.4.1.12356.101.11.2
fgIpSessTable 1.3.6.1.4.1.12356.101.11.2.1
fgIpSessEntry 1.3.6.1.4.1.12356.101.11.2.1.1 Information on a specific
session, including source
and destination.
fgIpSessIndex 1.3.6.1.4.1.12356.101.11.2.1.1.1 An index value that uniquely
identifies an IP session
within the fgIpSessTable.
fgIpSessProto 1.3.6.1.4.1.12356.101.11.2.1.1.2 The protocol the session is
using (IP, TCP, UDP, etc.).
fgIpSessFromAddr 1.3.6.1.4.1.12356.101.11.2.1.1.3 Source IP address (IPv4
only) of the session.
fgIpSessFromPort 1.3.6.1.4.1.12356.101.11.2.1.1.4 Source port number (UDP
and TCP only) of the
session.
fgIpSessToAddr 1.3.6.1.4.1.12356.101.11.2.1.1.5 Destination IP address (IPv4
only) of the session.
fgIpSessToPort 1.3.6.1.4.1.12356.101.11.2.1.1.6 Destination Port number
(UDP and TCP only) of the
session.
fgIpSessExp 1.3.6.1.4.1.12356.101.11.2.1.1.7 Number of seconds
remaining before the session
expires (if idle).
fgIpSessVdom 1.3.6.1.4.1.12356.101.11.2.1.1.8 Virtual domain the session is
part of. This index
used by fgVdTable.
fgIpSessStatsTable 1.3.6.1.4.1.12356.101.11.2.2 IP session statistics table.
fgIpSessStatsEntry 1.3.6.1.4.1.12356.101.11.2.2.1 IP session statistics on a
virtual domain.
fgIpSessNumber 1.3.6.1.4.1.12356.101.11.2.2.1.1 Current number of sessions
on the virtual domain.
VPN
fgVPN 1.3.6.1.4.1.12356.101.12
fgVpnInfo 1.3.6.1.4.1.12356.101.12.1
fgVpnTables 1.3.6.1.4.1.12356.101.12.2
fgVpnDialupTable 1.3.6.1.4.1.12356.101.12.2.1 Dial-up VPN peers
information.
fgVpnDialupEntry 1.3.6.1.4.1.12356.101.12.2.1.1 Dial-up VPN peer info.
fgVpnDialupIndex 1.3.6.1.4.1.12356.101.12.2.1.1.1 An index value that uniquely
identifies an VPN dial-up
peer within the
fgVpnDialupTable.
fgVpnDialupGateway 1.3.6.1.4.1.12356.101.12.2.1.1.2 Remote gateway IP address
of the tunnel.
fgVpnDialupLifetime 1.3.6.1.4.1.12356.101.12.2.1.1.3 Tunnel life time (seconds) of
the tunnel.
fgVpnDialupTimeout 1.3.6.1.4.1.12356.101.12.2.1.1.4 Time before the next key
exchange (seconds) of the
tunnel.

01-420-99686-20101026 423

fgVpnDialupSrcBegin 1.3.6.1.4.1.12356.101.12.2.1.1.5 Remote subnet address of
the tunnel.
fgVpnDialupSrcEnd 1.3.6.1.4.1.12356.101.12.2.1.1.6 Remote subnet mask of the
tunnel.
fgVpnDialupDstAddr 1.3.6.1.4.1.12356.101.12.2.1.1.7 Local subnet address of the
tunnel.
fgVpnDialupVdom 1.3.6.1.4.1.12356.101.12.2.1.1.8 Virtual domain tunnel is part
of. This index corresponds to
fgVpnDialupInOctets 1.3.6.1.4.1.12356.101.12.2.1.1.9 Number of bytes received on
tunnel since instantiation.
fgVpnDialupOutOctets 1.3.6.1.4.1.12356.101.12.2.1.1.10 Number of bytes sent on
tunnel since instantiation.
fgVpnTunTable 1.3.6.1.4.1.12356.101.12.2.2 Table of non-dial-up VPN
tunnels.
fgVpnTunEntry 1.3.6.1.4.1.12356.101.12.2.2.1 Tunnel VPN peer info.
fgVpnTunEntIndex 1.3.6.1.4.1.12356.101.12.2.2.1.1 An index value that uniquely
identifies a VPN tunnel
within the fgVpnTunTable.
fgVpnTunEntPhase1Name 1.3.6.1.4.1.12356.101.12.2.2.1.2 Descriptive name of phase1
configuration for the tunnel.
fgVpnTunentPhase2Name 1.3.6.1.4.1.12356.101.12.2.2.1.3 Descriptive name of phase2
configuration for the tunnel.
fgVpnTunEntRemGwyIp 1.3.6.1.4.1.12356.101.12.2.2.1.4 IP of remote gateway used
by the tunnel.
fgVpnTunEntRemGwyPort 1.3.6.1.4.1.12356.101.12.2.2.1.5 Port of remote gateway used
by tunnel, if UDP.
fgVpnTunEntLocGwyIp 1.3.6.1.4.1.12356.101.12.2.2.1.6 IP of local gateway used by
the tunnel.
fgVpnTunEntLocGwyPort 1.3.6.1.4.1.12356.101.12.2.2.1.7 Port of local gateway used
by tunnel, if UDP.
fgVpnTunEntSelectorSrcBegi 1.3.6.1.4.1.12356.101.12.2.2.1.8 Beginning of address range
nIP of source selector.
fgVpnTunEntSelectorSrcEndI 1.3.6.1.4.1.12356.101.12.2.2.1.9 End of address range of
p source selector.
fgVpnTunentSelectorSrcPort 1.3.6.1.4.1.12356.101.12.2.2.1.10 Source selector port.
fgVonTunEntSelectorDstBegi 1.3.6.1.4.1.12356.101.12.2.2.1.11 Beginning of address range
nIp of destination selector.
fgVpnTunEntSelectorDstEndI 1.3.6.1.4.1.12356.101.12.2.2.1.12 End of address range of
p destination selector.
fgVpnTunEntSelectorDstPort 1.3.6.1.4.1.12356.101.12.2.2.1.13 Destination selector port.
fgVpnTunEntSelectorProto 1.3.6.1.4.1.12356.101.12.2.2.1.14 Protocol number for selector.
fgVpnTunEntLifeSecs 1.3.6.1.4.1.12356.101.12.2.2.1.15 Lifetime of tunnel in
seconds, if time based
lifetime used.
fgVpnTunEntLifeBytes 1.3.6.1.4.1.12356.101.12.2.2.1.16 Lifetime of tunnel in bytes, if
byte transfer based lifetime
used.
fgVpnTunEntTimeout 1.3.6.1.4.1.12356.101.12.2.2.1.17 Timeout of tunnel in
seconds.
fgVpnTunEntInOctets 1.3.6.1.4.1.12356.101.12.2.2.1.18 Number of bytes received on
tunnel.

424 01-420-99686-20101026

fgVpnTunEntOutOctets 1.3.6.1.4.1.12356.101.12.2.2.1.19 Number of bytes sent out on
tunnel.
fgVpnTunEntStatus 1.3.6.1.4.1.12356.101.12.2.2.1.20 Current status of tunnel (up
or down).
fgVpnTunEntVdom 1.3.6.1.4.1.12356.101.12.2.2.1.21 Virtual domain the tunnel is
part of. This index
used by fgVdTable.
fgVpnSslStatsTable 1.3.6.1.4.1.12356.101.12.2.3 SSL VPN statistics table.
ffVpnSslStatsEntry 1.3.6.1.4.1.12356.101.12.2.3.1 SSL VPN statistics for a
given virtual domain.
fgVpnSslState 1.3.6.1.4.1.12356.101.12.2.3.1.1 Whether SSL-VPN is
enabled on this virtual
domain.
fgVpnSslStatsLoginUsers 1.3.6.1.4.1.12356.101.12.2.3.1.2 The current number of users
logged in through SSL-VPN
tunnels in the virtual domain.
fgVpnSslStatsMaxUsers 1.3.6.1.4.1.12356.101.12.2.3.1.3 The maximum number of
total users that can be
logged in at any one time on
the virtual domain.
fgVpnSslStatsActiveWebSess 1.3.6.1.4.1.12356.101.12.2.3.1.4 The current number of active
ions SSL web sessions in the
virtual domain.
fgVpnSslStatsMaxWebSessio 1.3.6.1.4.1.12356.101.12.2.3.1.5 The maximum number of
ns active SSL web sessions at
any one time within the
virtual domain.
fgVpnSslStatsActiveTunnels 1.3.6.1.4.1.12356.101.12.2.3.1.6 The current number of active
SSL tunnels in the virtual
domain.
fgVpnSslStatsMaxTunnels 1.3.6.1.4.1.12356.101.12.2.3.1.7 The maximum number of
active SSL tunnels at any
one time in the virtual
domain.
fgVpnSslTunnelTable 1.3.6.1.4.1.12356.101.12.2.4 A list of active SSL VPN
tunnel entries.
fgVpnSslTunnelEntry 1.3.6.1.4.1.12356.101.12.2.4.1 An SSL VPN tunnel entry
containing connection
information and traffic
statistics.
fgVpnSslTunnelIndex 1.3.6.1.4.1.12356.101.12.2.4.1.1 An index value that uniquely
identifies an active SSL VPN
tunnel within the
fgVpnSslTunnelTable.
fgVpnSslTunnelVdom 1.3.6.1.4.1.12356.101.12.2.4.1.2 The index of the virtual
domain this tunnel belongs
to. This index corresponds to
fgVpnSslTunnelUserName 1.3.6.1.4.1.12356.101.12.2.4.1.3 The user name used to
authenticate the tunnel.
fgVpnbSslTunnelSrcIp 1.3.6.1.4.1.12356.101.12.2.4.1.4 The source IP address of
this tunnel.
fgVpnSslTunnelIp 1.3.6.1.4.1.12356.101.12.2.4.1.5 The connection IP address
of this tunnel.
fgVpnSslTunnelUpTime 1.3.6.1.4.1.12356.101.12.2.4.1.6 The up-time of this tunnel in
seconds.
01-420-99686-20101026 425

fgVpnSslTunnelBytesIn 1.3.6.1.4.1.12356.101.12.2.4.1.7 The number of incoming
bytes of L2 traffic through
this tunnel since it was
established.
fgVpnSslTunnelBytesOut 1.3.6.1.4.1.12356.101.12.2.4.1.8 The number of outgoing
bytes of L2 traffic through
this tunnel since it was
established.
fgVpnTrapObjects 1.3.6.1.4.1.12356.101.12.3
fgVpnTrapLocalGateway 1.3.6.1.4.1.12356.101.12.3.2 Local gateway IP address.
Used in VPN related traps.
fgVpnTrapRemoteGateway 1.3.6.1.4.1.12356.101.12.3.3 Remote gateway IP address.
Used in VPN related traps.
High Availability
fgHighAvailability 1.3.6.1.4.1.12356.101.13
fgHaInfo 1.3.6.1.4.1.12356.101.13.1
fgHaSystemMode 1.3.6.1.4.1.12356.101.13.1.1 High-availability mode
(Standalone, A-A or A-P).
fgHaGroupId 1.3.6.1.4.1.12356.101.13.1.2 HA cluster group ID device is
configured for.
fgHaPriority 1.3.6.1.4.1.12356.101.13.1.3 HA clustering priority of the
device (default = 127).
fgHaOverride 1.3.6.1.4.1.12356.101.13.1.4 Status of a master override
flag.
fgHaAutoSync 1.3.6.1.4.1.12356.101.13.1.5 Configuration of an
automatic configuration
synchronization (enabled or
disabled).
fgHaSchedule 1.3.6.1.4.1.12356.101.13.1.6 Load-balancing schedule of
cluster (in A-A mode).
fgHaGroupName 1.3.6.1.4.1.12356.101.13.1.7 Ha cluster group name.
fgHaTables 1.3.6.1.4.1.12356.101.13.2
fgHaStatsTable 1.3.6.1.4.1.12356.101.13.2.1 Some useful statistics for all
members of a cluster. This
table is also available in
standalone mode.
fgHaStatsEntry 1.3.6.1.4.1.12356.101.13.2.1.1 Statistics for a particular HA
cluster's unit.
fgHaStatsIndex 1.3.6.1.4.1.12356.101.13.2.1.1.1 An index value that uniquely
identifies an unit in the HA
Cluster.
fgHaStatsSerial 1.3.6.1.4.1.12356.101.13.2.1.1.2 Serial number of the HA
cluster member for this row.
fgHaStatsCpuUsage 1.3.6.1.4.1.12356.101.13.2.1.1.3 CPU usage of the specified
cluster member
(percentage).
fgHaStatsMemUsage 1.3.6.1.4.1.12356.101.13.2.1.1.4 Memory usage of the
specified cluster member
(percentage).
fgHaStatsNetUsage 1.3.6.1.4.1.12356.101.13.2.1.1.5 Network bandwidth usage of
specified cluster member
(kbps).
fgHaStatsSesCount 1.3.6.1.4.1.12356.101.13.2.1.1.6 Current session count of
specified cluster member.
426 01-420-99686-20101026

fgHaStatsPktCount 1.3.6.1.4.1.12356.101.13.2.1.1.7 Number of packets
processed by the specified
cluster member since start
up.
fgHaStatsByteCount 1.3.6.1.4.1.12356.101.13.2.1.1.8 Number of bytes processed
by the specified cluster
member since start up.
fgHaStatsIdsCount 1.3.6.1.4.1.12356.101.13.2.1.1.9 Number of IDS/IPS events
triggered on the specified
up.
fgHaStatsAvCount 1.3.6.1.4.1.12356.101.13.2.1.1.10 Number of anti-virus events
triggered on the specified
up.
fgHaStatsHostname 1.3.6.1.4.1.12356.101.13.2.1.1.11 Host name of the specified
cluster member.
fgHaTrapObjects 1.3.6.1.4.1.12356.101.13.3
fgHaTrapMemberSerial 1.3.6.1.4.1.12356.101.13.3.1 Serial number of an HA
cluster member. Used to
identify the origin of a trap
when a cluster is configured.
fgFmTrapGroup 1.3.6.1.4.1.12356.101.100.1 Traps are intended for use in

conjunction with a
FortiManager.
fgFmTrapObjectGroup 1.3.6.1.4.1.12356.101.100.2 These objects support the
traps in the fgFmTrapGroup.
fgAdminObjectGroup 1.3.6.1.4.1.12356.101.100.3 Objects pertaining to
administration of the device.
fgSystemObjectGroup 1.3.6.1.4.1.12356.101.100.4 Objects pertaining to the
system status of the device.
fgSoftwareObjectGroup 1.3.6.1.4.1.12356.101.100.5 Objects pertaining to
software running on the
device.
fgHwSensorsObjectGroup 1.3.6.1.4.1.12356.101.100.6 Object pertaining to
hardware sensors on the
device.
fgHighAvailabilityObjectGroup 1.3.6.1.4.1.12356.101.100.7 Objects pertaining to High
Availability clustering of
FortiGate devices.
fgVpnObjectGroup 1.3.6.1.4.1.12356.101.100.8 Objects pertaining to Virtual
Private Networking on
FortiGate devices.
fgFirewallObjectGroup 1.3.6.1.4.1.12356.101.100.9 Objects pertaining to
Firewall functionality on
FortiGate devices.
fgAppServicesObjectGroup 1.3.6.1.4.1.12356.101.100.10 Objects pertaining to
application proxy and
filtering services on
FortiGate devices.
fgAntivirusObjectGroup 1.3.6.1.4.1.12356.101.100.11 Objects pertaining to
Antivirus services on
FortiGate devices.

01-420-99686-20101026 427

fgIntrusionPrevtObjectGroup 1.3.6.1.4.1.12356.101.100.12 Objects pertaining to
Intrusion Detection and
Prevention services on
FortiGate devices.
fgWebFilterObjectGroup 1.3.6.1.4.1.12356.101.100.13 Objects pertaining to
FortiGate and FortiGuard
based Web Filtering services
on FortiGate devices.
fgVirtualDomainObjectGroup 1.3.6.1.4.1.12356.101.100.14 Objects pertaining to Virtual
Firewall Domain services on
FortiGate devices.
fgAdministrationObjectGroup 1.3.6.1.4.1.12356.101.100.15 Objects pertaining to the
administration of FortiGate
device.
fgIntfObjectGroup 1.3.6.1.4.1.12356.101.100.16 Objects pertaining to the
interface table of FortiGate
device.
fgProcessorsObjectGroup 1.3.6.1.4.1.12356.101.100.17 Objects pertaining to the
processors table of
FortiGate device.
fgNotificationGropu 1.3.6.1.4.1.12356.101.100.18 Notifications that can be
generated from a FortiGate
device.
fgObsoleteNotificationsGroup 1.3.6.1.4.1.12356.101.100.19 Notifications that have been
deprecated, but may still be
generated by older models.
fgMIBCompliance 1.3.6.1.4.1.12356.101.100.100 Model and feature specific.

428 01-420-99686-20101026
Multicast forwarding
Multicasting (also called IP multicasting) consists of using a single multicast source to
send data to many receivers. Multicasting can be used to send data to many receivers
simultaneously while conserving bandwidth and reducing network traffic. Multicasting can
be used for one-way delivery of media streams to multiple receivers and for one-way data
transmission for news feeds, financial information, and so on. Also RIPv2 uses
multicasting to share routing table information.
A multicast network typically consists of one or more multicast sources and one or more
multicast receivers. Multicast sources send multicast packets and multicast receivers
receive multicast packets. Usually there are various network components in between the
sources and the receivers. These network components may just forward multicast packets
or they may route multicast packets. Network components that route multicast packets are
multicast routers.
Using a multicast router means that the source only needs to transmit a single stream of
data to the multicast router. The multicast router routes the data to the receivers. The
receivers can be single receivers or can be part off a multicast group. The multicast router
makes decisions about how to route the packets to receivers and multicast groups.
Typically the multicast router makes routing decisions based on the source and
destination addresses of the multicast packets. The multicast router can also apply
network address translation (NAT) to multicast packets.
This chapter describes configuring FortiGate units to forward multicast traffic and contains
the following sections:
• Multicast IP addresses
• Multicast forwarding and FortiGate units
• Configuring FortiGate multicast forwarding
FortiGate units operating in NAT/Route mode can also be configured as multicast routers.
You can configure a FortiGate unit to be a Protocol Independent Multicast (PIM) router
operating in Sparse Mode (SM) or Dense Mode (DM).
Multicast IP addresses
Multicast uses the Class D address space. The 224.0.0.0 to 239.255.255.255 IP address
range is reserved for multicast groups. The multicast address range applies to multicast
groups, not to the originators of multicast packets. Table 45 lists reserved multicast
address ranges and describes what they are reserved for:

01-420-99686-20101026 429
Multicast forwarding and FortiGate units Multicast forwarding
Table 45: Reserved Multicast address ranges
Reserved Use Notes

Address Range
224.0.0.0 to Used for network protocols on local In this range, packets are not forwarded
224.0.0.255 networks. For more information, see by the router but remain on the local
RFC 1700. network. They have a Time to Live
(TTL) of 1. These addresses are used
for communicating routing information.
224.0.1.0 to Global addresses used for Some of these addresses are reserved,
238.255.255.255 multicasting data between for example, 224.0.1.1 is used for
organizations and across the Network Time Protocol (NTP).
Internet. For more information, see
RFC 1700.
239.0.0.0 to Limited scope addresses used for Routers are configured with filters to
239.255.255.255 local groups and organizations. For prevent multicasts to these addresses
more information, see RFC 2365. from leaving the local system.
Multicast forwarding and FortiGate units

In both Transparent mode and NAT/Route mode you can configure FortiGate units to
forward multicast traffic.
For a FortiGate unit to forward multicast traffic you must add FortiGate multicast firewall
policies. Basic multicast firewall policies accept any multicast packets at one FortiGate
interface and forward the packets out another FortiGate interface. You can also use
multicast firewall policies to be selective about the multicast traffic that is accepted based
on source and destination address, and to perform NAT on multicast packets.
In the example shown in Figure 39, a multicast source on the Marketing network with IP
address 192.168.5.18 sends multicast packets to the members of network 239.168.4.0. At
the FortiGate unit, the source IP address for multicast packets originating from workstation
192.168.5.18 is translated to 192.168.18.10. In this example, the FortiGate unit is not
acting as a multicast router.
Multicast forwarding and RIPv2

RIPv2 uses multicast to share routing table information. If your FortiGate unit is installed
on a network that includes RIPv2 routers, you must configure the FortiGate unit to forward
multicast packets so that RIPv2 devices can share routing data through the FortiGate unit.
No special FortiGate configuration is required to share RIPv2 data, you can simply use the
information in the following sections to configure the FortiGate unit to forward multicast
packets.
Note: RIPv1 uses broadcasting to share routing table information. To allow RIPv1 packets
through a FortiGate unit you can add standard firewall policies. Firewall policies to accept
RIPv1 packets can use the ANY predefined firewall service or the RIP predefined firewall
service.

430 01-420-99686-20101026
Multicast forwarding Configuring FortiGate multicast forwarding
Figure 39: Example multicast network including a FortiGate unit that forwards multicast
packets
of
b ers oup
m r
Me ast G4.0
ic 68. 4
l t
Mu39.1 er_
r_3 ce
iv
2 e ive Re
c
Re
r_2
e ive
c
Re
r_1
e ive
R ec
Fo
r
int tiGat
ern e-
ex al 800
te I
DM rnal P: 19
Z I IP: 2.1
Multicast Forwarding Enabled P: 17 68
Source address: 192.168.5.18 19 2.2 .5.1
2.1 0.
Source interface: internal 68 20.
.6. 10
1
Destination address: 239.168.4.0
Destination interface: external
NAT IP: 192.168.18.10
D 2.1
ev 6
19
el 8.6
op .
m 0/2
ss ing
en 4
M 16
19
ar 8.
re et
t
2.
dd rk
ke 5.
9. dr sts .18 a a
tin 0/2
23 ad a .5 t IP e M
g 4
IP ult 16 a th
m 2. or on
19 tw er
d
8. ss o
ne en
16 e t
8
S
0
c
4.
i
Configuring FortiGate multicast forwarding

You configure FortiGate multicast forwarding from the Command Line Interface (CLI). Two
steps are required:
• Adding multicast firewall policies
• Enabling multicast forwarding
This second step is only required if your FortiGate unit is operating in NAT mode. If
your FortiGate unit is operating in Transparent mode, adding a multicast policy enables
multicast forwarding.

01-420-99686-20101026 431
Configuring FortiGate multicast forwarding Multicast forwarding
Adding multicast firewall policies

You need to add firewall policies to allow packets to pass from one interface to another.
Multicast packets require multicast firewall policies. You add multicast firewall policies
from the CLI using the config firewall multicast-policy command. As with
unicast firewall policies, you specify the source and destination interfaces and optionally
the allowed address ranges for the source and destination addresses of the packets.
You can also use multicast firewall policies to configure source NAT and destination NAT
for multicast packets. For full details on the config firewall multicast-policy command, see
the FortiGate CLI Reference.
Keep the following in mind when configuring multicast firewall policies:
• The matched forwarded (outgoing) IP multicast source IP address is changed to the
configured IP address.
• Source and Destination interfaces are optional. If left blank, then the multicast will be
forwarded to ALL interfaces.
• Source and Destination addresses are optional. If left un set, then it will mean ALL
addresses.
• The nat keyword is optional. Use it when source address translation is needed.
Enabling multicast forwarding

Multicast forwarding is disabled by default. In NAT mode you must use the multicast-
forward keyword of the system settings CLI command to enable multicast
forwarding. When multicast-forward is enabled, the FortiGate unit forwards any
multicast IP packets in which the TTL is 2 or higher to all interfaces and VLAN interfaces
except the receiving interface. The TTL in the IP header will be reduced by 1. Even though
the multicast packets are forwarded to all interfaces, you must add firewall policies to
actually allow multicast packets through the FortiGate. In our example, the firewall policy
allows multicast packets received by the internal interface to exit to the external interface.
Note: Enabling multicast forwarding is only required if your FortiGate unit is operating in
NAT mode. If your FortiGate unit is operating in Transparent mode, adding a multicast
policy enables multicast forwarding.
Enter the following CLI command to enable multicast forwarding:

set multicast-forward enable
end
If multicast forwarding is disabled and the FortiGate unit drops packets that have multicast
source or destination addresses.
You can also use the multicast-ttl-notchange keyword of the system settings
command so that the FortiGate unit does not increase the TTL value for forwarded
multicast packets. You should use this option only if packets are expiring before reaching
the multicast router.
set multicast-ttl-notchange enable
end
In Transparent mode, the FortiGate unit does not forward frames with multicast
destination addresses. Multicast traffic such as the one used by routing protocols or
streaming media may need to traverse the FortiGate unit, and should not be interfere with
the communication. To avoid any issues during transmission, you can set up multicast
firewall policies. These types of firewall policies can only be enabled using the CLI.

432 01-420-99686-20101026
Multicast forwarding Configuring FortiGate multicast forwarding
Note: The CLI parameter multicast-skip-policy must be disabled when using multicast
firewall policies. To disable enter the command
set multicast-skip-policy disable
end
In this simple example, no check is performed on the source or destination interfaces. A

multicast packet received on an interface is flooded unconditionally to all interfaces on the
forwarding domain, except the incoming interface.
To enable the multicast policy

config firewall multicast-policy
edit 1
set action accept
end
In this example, the multicast policy only applies to the source port of WAN1 and the
destination port of Internal.
To enable the restrictive multicast policy

edit 1
set srcintf wan1
set dstinf internal
set action accept
end
In this example, packets are allowed to flow from WAN1 to Internal, and sourced by the
address 172.20.120.129.
To enable the restrictive multicast policy

edit 1
set srcintf wan1
set srcaddr 172.20.120.129 255.255.255.255
set dstinf internal
set action accept
end
This example shows how to configure the multicast firewall policy required for the
configuration shown in Figure 39 on page 431. This policy accepts multicast packets that
are sent from a PC with IP address 192.168.5.18 to destination address range
239.168.4.0. The policy allows the multicast packets to enter the internal interface and
then exit the external interface. When the packets leave the external interface their source
address is translated to 192.168.18.10
edit 5
set srcaddr 192.168.5.18 255.255.255.255
set destaddr 239.168.4.0 255.255.255.0
set dstintf external
set nat 192.168.18.10
end

01-420-99686-20101026 433
Multicast routing examples Multicast forwarding
This example shows how to configure a multicast firewall policy so that the FortiGate unit
forwards multicast packets from a multicast Server with an IP 10.10.10.10 is broadcasting
to address 225.1.1.1. This Server is on the network connected to the FortiGate DMZ
interface.
edit 1
set srcintf DMZ
set srcaddr 10.10.10.10 255.255.255.255
set dstintf Internal
set dstaddr 225.1.1.1 255.255.255.255
set action accept
edit 2
set action deny
end
Multicast routing examples

This section contains the following multicast routing configuration examples and
information:
• Example FortiGate PIM-SM configuration using a static RP
• FortiGate PIM-SM debugging examples
• Example multicast destination NAT (DNAT) configuration
• Example PIM configuration that uses BSR to find the RP
Figure 40: Example FortiGate PIM-SM topology
.x
ter 00
ou 4.2
_ 1 r 3.23 ck0)
0 23 ba
75 op
_3 p
i s co grou 0.1 lo
C for .10
RP 9.254
0)
25
(16
(.
23
0/
E
F
16
9.2
54
.82
.0/
24
10
.31
M 9. 25
Cis VL .138.
ul 25 4.
16 3.
tic 4 20
co AN 0/2
23
as .8 0.
_3
t S 2.1 1
75 13 4
ou
0_ 8
rc
2r
e
ou
1)
ter
(.
10
24
.31
0/
E
VL .130.
F
Fo AN 0/2
rtiG
0)
13 4
25
ate
(.
-8 8
23
00
0/
3)
E
F
25
(.
al
rn
Cis 10
te
co .31
ex
_3 .12
1)
75
(.
0_ 8.1
al
28
rn
3r /30
te
ou
in
0)
ter
25
(.
24
0/
E
F
0)
13
(.
23
0/
E
F
1
4. 9)
0.
25 12
20
3. r (.
23 ve
i
up ce
ro e
G R

434 01-420-99686-20101026
Multicast forwarding Multicast routing examples
Example FortiGate PIM-SM configuration using a static RP

The example Protocol Independent Multicast Sparse Mode (PIM-SM) configuration shown
in Figure 40 has been tested for multicast interoperability using PIM-SM between Cisco
3750 switches running 12.2 and a FortiGate-800 running FortiOS v3.0 MR5 patch 1. In
this configuration, the receiver receives the multicast stream when it joins the group
233.254.200.1.
The configuration uses a statically configured rendezvous point (RP) which resides on the
Cisco_3750_1. Using a bootstrap router (BSR) was not tested in this example. See
“Example PIM configuration that uses BSR to find the RP” on page 447 for an example
that uses a BSR.
Configuration steps
The following procedures show how to configure the multicast configuration settings for
the devices in the example configuration.
• Cisco_3750_1 router configuration
• To configure the FortiGate-800 unit
Cisco_3750_1 router configuration

version 12.2
!
hostname Cisco-3750-1
!
switch 1 provision ws-c3750-24ts
ip subnet-zero
ip routing
!
ip multicast-routing distributed
!
spanning-tree mode pvst
no spanning-tree optimize bpdu transmission
spanning-tree extend system-id
!
interface Loopback0
ip address 169.254.100.1 255.255.255.255
!
interface FastEthernet1/0/23
switchport access vlan 182
switchport mode access
!
!
interface Vlan172
ip address 10.31.138.1 255.255.255.0
ip pim sparse-mode
ip igmp query-interval 125
ip mroute-cache distributed
!

01-420-99686-20101026 435
interface Vlan182
ip address 169.254.82.250 255.255.255.0
ip pim sparse-mode
!
ip classless
ip route 0.0.0.0 0.0.0.0 169.254.82.1
ip http server
ip pim rp-address 169.254.100.1 Source-RP
!
ip access-list standard Source-RP
permit 233.254.200.0 0.0.0.255

version 12.2
!
!
ip subnet-zero
ip routing
!
!
!
!
witchport mode access
!
interface Vlan138
ip address 10.31.138.250 255.255.255.0
ip pim sparse-mode
!
interface Vlan182
ip address 169.254.82.1 255.255.255.0
ip pim sparse-mode
!
ip classless
ip route 0.0.0.0 0.0.0.0 10.31.138.253
ip route 169.254.100.1 255.255.255.255 169.254.82.250
ip http server
!
!

436 01-420-99686-20101026

permit 233.254.200.0 0.0.0.255
To configure the FortiGate-800 unit

1 Configure the internal and external interfaces.
edit internal
set vdom root
set ip 10.31.130.1 255.255.255.0
set allowaccess ping https
set type physical
next
edit external
set vdom root
set ip 10.31.138.253 255.255.255.0
set type physical
end
end
2 Add a firewall address for the RP.
edit RP
set subnet 169.254.100.1/32
end
3 Add standard firewall policies to allow traffic to reach the RP.
edit 1
set srcaddr all
set dstaddr RP
set action accept
set schedule always
set service ANY
next
edit 2
set srcintf external
set dstintf internal
set srcaddr RP
set dstaddr all
set action accept
set schedule always
set service ANY
end
4 Add the multicast firewall policy.
edit 1
set dstaddr 233.254.200.0 255.255.255.0
set srcaddr 169.254.82.0 255.255.255.0
set srcintf external
end

01-420-99686-20101026 437
5 Add an access list.

config router access-list
edit Source-RP
config rule
edit 1
set prefix 233.254.200.0 255.255.255.0
set exact-match disable
next
end
6 Add some static routes.
edit 1
set device internal
next
edit 2
set device external
set dst 169.254.0.0 255.255.0.0
next
7 Configure multicast routing.
config router multicast
config interface
edit internal
set pim-mode sparse-mode
config igmp
set version 2
end
next
edit external
config igmp
set version 2
end
next
end
set multicast-routing enable
config pim-sm-global
config rp-address
edit 1
set ip-address 169.254.100.1
set group Source-RP
next

version 12.2
!
!
ip subnet-zero
ip routing

438 01-420-99686-20101026
!
!
!
!
!
interface Vlan128
ip address 10.31.128.130 255.255.255.252
ip pim sparse-mode
!
interface Vlan130
ip address 10.31.130.250 255.255.255.0
ip pim sparse-mode
!
ip classless
ip route 0.0.0.0 0.0.0.0 10.31.130.1
ip http server
!
!
permit 233.254.200.0 0.0.0.255
FortiGate PIM-SM debugging examples

Using the example topology shown in Figure 41 you can trace the multicast streams and
states within the three FortiGate units (FGT-1, FGT-2, and FGT-3) using the debug
commands described in this section. The command output in this section is taken from
FortiGate unit running FortiOS v3.0 MR5 patch 1 when the multicast stream is flowing
correctly from source to receiver.

01-420-99686-20101026 439
Figure 41: PIM-SM debugging topology
10
.16
6.0
.0/
24
M 9.
ul 25
23
tic 5
10
as .2
.13
t S 55
0.0
ou .1
.0/
rc
e
24
(.
11
)
al
rn
te
In
10
7)
.13
l
na
23
2.0
er
(.
xt
1
.0/
T-
E
24
G
F
al
rn
te
In
10
.16
l
7.0
32
na
1/
er
.0/
ck 68 )
ba .1 56
) .1.
xt
24
op 92 (.1
E
(lo 1 -2
R T
G
F
P
2
rt
po
6)
3
22
rt
po
(.
3
T-
G
F
)
62
(.
r
ve
ei
ec
R
Checking that the receiver has joined the required group
From the last hop router, FGT-3, you can use the following command to check that the
receiver has correctly joined the required group.
FGT-3 # get router info multicast igmp groups
IGMP Connected Group Membership
Group Address Interface Uptime Expires Last
Reporter
239.255.255.1 port3 00:31:15 00:04:02
10.167.0.62
Only 1 receiver is displayed for a particular group, this is the device that responded to the
IGMP query request from the FGT-3. If a receiver is active the expire time should drop to
approximately 2 minutes before being refreshed.
Checking the PIM-SM neighbors

Next the PIM-SM neighbors should be checked. A PIM router becomes a neighbor when
the PIM router receives a PIM hello. Use the following command to display the PIM-SM
neighbors of FGT-3.
FGT-3 # get router info multicast pim sparse-mode neighbour
Neighbor Interface Uptime/Expires Ver DR
Address
Priority/Mode
10.132.0.156 port2 01:57:12/00:01:33 v2 1 /
Checking that the PIM router can reach the RP

The rendezvous point (RP) must be reachable for the PIM router (FGT-3) to be able to
send the *,G join to request the stream. This can be checked for FGT-3 using the
following command:

440 01-420-99686-20101026
FGT-3 # get router info multicast pim sparse-mode rp-mapping

PIM Group-to-RP Mappings
Group(s): 224.0.0.0/4, Static
RP: 192.168.1.1
Uptime: 07:23:00
Viewing the multicast routing table (FGT-3)

The FGT-3 unicast routing table can be used to determine the path taken to reach the RP
at 192.168.1.1. You can then check the stream state entries using the following
commands:
FGT-3 # get router info multicast pim sparse-mode table
IP Multicast Routing Table
(*,*,RP) Entries: 0
(*,G) Entries: 1
(S,G) Entries: 1
(S,G,rpt) Entries: 1
FCR Entries: 0
(*,*,RP) This state may be reached by general joins for all groups served by a
Entries specified RP.
(*,G) Entries State that maintains the RP tree for a given group.
(S,G) Entries State that maintains a source-specific tree for source S and group G.
(S,G,rpt) State that maintains source-specific information about source s on the RP
Entries tree for G. For example, if a source is being received on the source-specific
tree, it will normally have been pruned off the RP tree.
FCR The FCR state entries are for tracking the sources in the <*, G> when <S, G>
is not available for any reason, the stream would typically be flowing when
this state exists.
Breaking down each entry in detail:

(*, 239.255.255.1)
RP: 192.168.1.1
RPF nbr: 10.132.0.156
RPF idx: port2
Upstream State: JOINED
Local:
port3
Joined:
Asserted:
FCR:
The RP will always be listed in a *,G entry, the RPF neighbor and interface index will also
be shown. In this topology these are the same in all downstream PIM routers. The state is
active so the upstream state is joined.
In this case FGT-3 is the last hop router so the IGMP join is received locally on port3.
There is no PIM outgoing interface listed for this entry as it is used for the upstream PIM
join.
(10.166.0.11, 239.255.255.1)
RPF nbr: 10.132.0.156
RPF idx: port2
SPT bit: 1
Local:

01-420-99686-20101026 441
Joined:
Asserted:
Outgoing:
port3
This is the entry for the SPT, no RP IS listed. The S,G stream will be forwarded out of the
stated outgoing interface.
(10.166.0.11, 239.255.255.1, rpt)
RP: 192.168.1.1
RPF nbr: 10.132.0.156
RPF idx: port2
Upstream State: NOT PRUNED
Local:
Pruned:
Outgoing:
The above S,G,RPT state is created for all streams that have both a S,G and a *,G entry
on the router. This is not pruned in this case because of the topology, the RP and source
are reachable over the same interface.
Although not seen in this scenario, assert states may be seen when multiple PIM routers
exist on the same LAN which can lead to more than one upstream router having a valid
forwarding state. Assert messages are used to elect a single forwarder from the upstream
devices.
Viewing the PIM next-hop table

The PIM next-hop table is also very useful for checking the various states, it can be used
to quickly identify the states of multiple multicast streams
FGT-3 # get router info multicast pim sparse-mode next-hop
Flags: N = New, R = RP, S = Source, U = Unreachable
Destination Type Nexthop Nexthop Nexthop Metric Pref
Refcnt
Num Addr Ifindex
_________________________________________________________________
10.166.0.11 ..S. 1 10.132.0.156 9 21 110 3
192.168.1.1 .R.. 1 10.132.0.156 9 111 110 2
Viewing the PIM multicast forwarding table

Also you can check the multicast forwarding table showing the ingress and egress ports of
the multicast stream.
FGT-3 # get router info multicast table

Flags: I - Immediate Stat, T - Timed Stat, F - Forwarder installed
Timers: Uptime/Stat Expiry
Interface State: Interface (TTL threshold)
(10.166.0.11, 239.255.255.1), uptime 04:02:55, stat expires

00:02:25
Owner PIM-SM, Flags: TF
Incoming interface: port2
Outgoing interface list:
port3 (TTL threshold 1)

442 01-420-99686-20101026
Viewing the kernel forwarding table

Also the kernel forwarding table can be verified, however this should give similar
information to the above command:
FGT-3 # diag ip multicast mroute
grp=239.255.255.1 src=10.166.0.11 intf=9 flags=(0x10000000)[ ]
status=resolved
last_assert=2615136 bytes=1192116 pkt=14538 wrong_if=0
num_ifs=1
index(ttl)=[6(1),]

If you check the output on FGT-2 there are some small differences:
FGT-2 # get router info multicast pim sparse-mode table
(*,*,RP) Entries: 0
(*,G) Entries: 1
(S,G) Entries: 1
FCR Entries: 0
(*, 239.255.255.1)
RP: 192.168.1.1
RPF nbr: 0.0.0.0
RPF idx: None
Local:
Joined:
external
Asserted:
FCR:
The *,G entry now has a joined interface rather than local because it has received a PIM
join from FGT-3 rather than a local IGMP join.
(10.166.0.11, 239.255.255.1)
RPF nbr: 10.130.0.237
RPF idx: internal
SPT bit: 1
Local:
Joined:
external
Asserted:
Outgoing:
external
The S,G entry shows that we have received a join on the external interface and the stream
is being forwarded out of this interface.
(10.166.0.11, 239.255.255.1, rpt)
RP: 192.168.1.1
RPF nbr: 0.0.0.0
RPF idx: None
Upstream State: PRUNED

01-420-99686-20101026 443
Local:
Pruned:
Outgoing:
External
The S,G,RPT is different from FGT-3 because FGT-2 is the RP, it has pruned back the
SPT for the RP to the first hop router.

FGT-1 again has some differences with regard to the PIM-SM states, there is no *,G entry
because it is not in the path of a receiver and the RP.
FGT-1_master # get router info multicast pim sparse-mode table
(*,*,RP) Entries: 0
(*,G) Entries: 0
(S,G) Entries: 1
FCR Entries: 0
Below the S,G is the SPT termination because this FortiGate unit is the first hop router,
the RPF neighbor always shows as 0.0.0.0 because the source is local to this device. Both
the joined and outgoing fields show as external because the PIM join and the stream is
egressing on this interface.
(10.166.0.11, 239.255.255.1)
RPF nbr: 0.0.0.0
RPF idx: None
SPT bit: 1
Local:
Joined:
external
Asserted:
Outgoing:
external
The stream has been pruned back from the RP because the end-to-end SPT is flowing,
there is no requirement for the stream to be sent to the RP in this case.
(10.166.0.11, 239.255.255.1, rpt)
RP: 0.0.0.0
RPF nbr: 10.130.0.156
RPF idx: external
Upstream State: RPT NOT JOINED
Local:
Pruned:
Outgoing:
Example multicast destination NAT (DNAT) configuration

The example topology shown in Figure 42 and described below shows how to configure
destination NAT (DNAT) for two multicast streams. Both of these streams originate from
the same source IP address, which is 10.166.0.11. The example configuration keeps the
streams separate by creating 2 multicast NAT policies.
In this example the FortiGate units in Figure 42 have the following roles:
• FGT-1 is the RP for dirty networks, 233.0.0.0/8.

444 01-420-99686-20101026
• FGT-2 performs all firewall and DNAT translations.

• FGT-3 is the RP for the clean networks, 239.254.0.0/16.
• FGT-1 and FGT-3 are functioning as PM enabled routers and could be replaced can be
any PIM enabled router.
This example only describes the configuration of FGT-2.
FGT-2 performs NAT so that the receivers connected to FGT-3 receive the following
translated multicast streams.
• If the multicast source sends multicast packets with a source and destination IP of
10.166.0.11 and 233.2.2.1; FGT-3 translates the source and destination IPs to
192.168.20.1 and 239.254.1.1
• If the multicast source sends multicast packets with a source and destination IP of
10.166.0.11 and 233.3.3.1; FGT-3 translates the source and destination IPs to
192.168.20.10 and 239.254.3.1
Figure 42: Example multicast DNAT topology

10
.16
6.0
.0/
24
.3 11
.1
33 .0.
.3
:2 6
IP 16
n 0.
M 10 p 233
io 1
ul .1 23 .3
IP rou p
at P:
tic 6 3 .
10
tin e I
G rou
T
as 6. .2. 3.1
.12
54 10
es rc
G
t S 0.1 2. 1
.1
D ou
5.0
.2 0.
.3
ou 1/
39 8.2
S
.0/
rc 24
:2 6
e
24
IP .1
n 92
1
io 1
at P:
tin e I
es rc
D ou
S
10
.12
8 s
0/ p
6.0
0. ou
.0/
23 f -1
0. gr
R T
24
3. or
G
8
F
P
6
rt
po
10
.12
7.0
7
23 n 4 e
.0/
rt
p co /2 fac
po
2. ed
24
ou in 0.1 er
fo tat 16 ck )
S 2. ba (FW
2. ur
gr jo 2 t
r ic 8. in
3. fig
1
19 p -2
Lo T
G
F
o
.2 11
.1
33 .0.
.2
:2 6
IP 16
up
n 0.
io 1
ro
at P:
g
T
tin e I
16 r
A
0/ fo
.1
54 1
es rc
.2 0.
0. P
.1
D ou
4. R
39 8.2
S
23 SR -3
25 nd
:2 6
B T
IP .1
9. a
G
n 92
F
io 1
at P:
tin e I
9. 25 /2 er
es rc
23 9. .62 iv
D ou
25 4. 4
e
up 2 .0 c
4. 1.1
S
ro p 27 Re
1
3.
G rou .1 st
G 10 ica
IP ult
3
M
To configure FGT-2 for DNAT multicast

1 Add a loopback interface. In the example, the loopback interface is named loopback.
edit loopback
set vdom root
set ip 192.168.20.1 255.255.255.0
set type loopback
next
end
2 Add PIM and add a unicast routing protocol to the loopback interface as if it was a
normal routed interface. Also add static joins to the loopback interface for any groups
to be translated.

01-420-99686-20101026 445
config interface
edit loopback
config join-group
edit 233.2.2.1
next
edit 233.3.3.1
next
end
next
3 In this example, to add firewall multicast policies, different source IP addresses are
required so you must first add an IP pool:
edit Multicast_source
set endip 192.168.20.20
set interface port6
next
end
4 Add the translation firewall policies.
Policy 2, which is the source NAT policy, uses the actual IP address of port6. Policy 1,
the DNAT policy, uses an address from the IP pool.
edit 1
set dnat 239.254.3.1
set dstaddr 233.3.3.1 255.255.255.255
set dstintf loopback
set nat 192.168.20.10
set srcaddr 10.166.0.11 255.255.255.255
set srcintf port6
next
edit 2
set dnat 239.254.1.1
set dstaddr 233.2.2.1 255.255.255.255
set dstintf loopback
set nat 192.168.20.1
set srcaddr 10.166.0.11 255.255.255.255
set srcintf port6
next
5 Add a firewall multicast policy to forward the stream from the loopback interface to the
physical outbound interface.
This example is an any/any policy that makes sure traffic accepted by the other
multicast policies can exit the FortiGate unit.
edit 3
set dstintf port7
set srcintf loopback
next

446 01-420-99686-20101026
Example PIM configuration that uses BSR to find the RP

This example shows how to configure a multicast routing network for a network consisting
of four FortiGate-500A units (FortiGate-500A_1 to FortiGate-550A_4, see Figure 43). A
multicast sender is connected to FortiGate-500A_2. FortiGate-500A_2 forwards multicast
packets in two directions to reach Receiver 1 and Receiver 2.
The configuration uses a Boot Start Router (BSR) to find the Rendezvous Points (RPs)
instead of using static RPs. Under interface configuration, the loopback interface lo0
must join the 236.1.1.1 group (source).
This example describes:
• Commands used in this example
• Configuration steps
• Example debug commands
Figure 43: PIM network topology using BSR to find the RP
11
26
i s co er
C out
r
0
55
c o3
Cis witch
s
1
r
ve
ei
ec
R
Fo
rtiG
F P 23 .1
or fo 7. .1
ate
tiG r 1. .1
R
-50
at 237 1.1
e- .1
0A
50 .1
_
23
2
0A .1
8
_1
F RP rio
or
tiG fo ity
a t r o 25
er 40
e- th 6
P
ut 6
50 er
ro o 3
0A s
r
c
_3
is
C
F RP Pr
or
tiG fo rit
at r o y 1
S
e - th
en
50 er
de
io
0A s
r
_4
2
r
ve
ei
ec
R
Commands used in this example

This example uses CLI commands for the following configuration settings:
• Adding a loopback interface (lo0)
• Defining the multicast routing
• Adding the NAT multicast policy

01-420-99686-20101026 447
Adding a loopback interface (lo0)

Where required, the following command is used to define a loopback interface named
lo0.
edit lo0
set vdom root
set ip 1.4.50.4 255.255.255.255
set allowaccess ping https ssh snmp http telnet
set type loopback
next
end
Defining the multicast routing

In this example, the following command syntax is used to define multicast routing. The
example uses a Boot Start Router (BSR) to find the Rendezvous Points (RPs) instead
of using static RPs. Under interface configuration, the loopback interface lo0 must join
the 236.1.1.1 group (source).
config interface
edit port6
next
edit port1
next
edit lo0
set rp-candidate enable
config join-group
edit 236.1.1.1
next
end
set rp-candidate-priority 1
next
end
set bsr-allow-quick-refresh enable
set bsr-candidate enable
set bsr-interface lo0
set bsr-priority 200
end
end
Adding the NAT multicast policy

In this example, the incoming multicast policy does the address translation. The NAT
address should be the same as the IP address of the of loopback interface. The DNAT
address is the translated address, which should be a new group.
edit 1
set dstintf port6
set srcintf lo0

448 01-420-99686-20101026
next
edit 2
set dnat 238.1.1.1
set dstintf lo0
set nat 1.4.50.4
set srcintf port1
next
Configuration steps
In this sample, FortiGate-500A_1 is the RP for the group 228.1.1.1, 237.1.1.1, 238.1.1.1,
and FortiGate-500A_4 is the RP for the other group which has a priority of1. OSPF is used
in this example to distribute routes including the loopback interface. All firewalls have full
mesh firewall policies to allow any to any.
• In the FortiGate-500A_1 configuration, the NAT policy translates source address
236.1.1.1 to 237.1.1.1
• In the FortiGate-500A_4, configuration, the NAT policy translates source 236.1.1.1 to
238.1.1.1
• Source 236.1.1.1 is injected into network as well.
The following procedures include the CLI commands for configuring each of the FortiGate
units in the example configuration.
To configure FortiGate-500A_1
config interface
edit port5
next
edit port4
next
edit lan
next
edit port1
next
edit lo999
next
edit lo0
set rp-candidate-group 1
next
end
end
end

01-420-99686-20101026 449
2 Add multicast firewall policies.

edit 1
set dstintf port5
set srcintf port4
next
edit 2
set dstintf port4
set srcintf port5
next
edit 3
next
end
3 Add router access lists.
config router access-list
edit 1
config rule
edit 1
set prefix 228.1.1.1 255.255.255.255
set exact-match enable
next
edit 2
set prefix 237.1.1.1 255.255.255.255
next
edit 3
set prefix 238.1.1.1 255.255.255.255
next
end
next
end
config interface
edit "lan"
next
edit "port5"
next
edit "port2"
next
edit "port4"
next
edit "lo_5"
config join-group
edit 236.1.1.1

450 01-420-99686-20101026
next
end
next
end
end
edit 1
set dstintf lan
set srcintf port5
next
edit 2
set dstintf port5
set srcintf lan
next
edit 4
set dstintf lan
set srcintf port2
next
edit 5
set dstintf port2
set srcintf lan
next
edit 7
set dstintf port1
set srcintf port2
next
edit 8
set dstintf port2
set srcintf port1
next
edit 9
set dstintf port5
set srcintf port2
next
edit 10
set dstintf port2
set srcintf port5
next
edit 11
set dnat 237.1.1.1
set dstintf lo_5
set nat 5.5.5.5
set srcintf port2
next
edit 12
set dstintf lan
set srcintf lo_5
next
edit 13
set dstintf port1
set srcintf lo_5

01-420-99686-20101026 451
next
edit 14
set dstintf port5
set srcintf lo_5
next
edit 15
set dstintf port2
set srcintf lo_5
next
edit 16
next
end
config interface
edit port5
next
edit port6
next
edit lo0
next
edit lan
next
end
end
end
edit 1
set dstintf port5
set srcintf port6
next
edit 2
set dstintf port6
set srcintf port5
next
edit 3
set dstintf port6
set srcintf lan
next
edit 4

452 01-420-99686-20101026
set dstintf lan

set srcintf port6
next
edit 5
set dstintf port5
set srcintf lan
next
edit 6
set dstintf lan
set srcintf port5
next
end
config interface
edit port6
next
edit lan
next
edit port1
next
edit lo0
config join-group
edit 236.1.1.1
next
end
next
end
set bsr-allow-quick-refresh enable
set bsr-priority 1
end
end
edit 1
set srcintf lan
set dstintf port6
set srcaddr all
set dstaddr all
set action accept
set schedule always

01-420-99686-20101026 453
set service ANY

next
edit 2
set srcintf port6
set dstintf lan
set srcaddr all
set dstaddr all
set action accept
set schedule always
set service ANY
next
edit 3
set srcintf port1
set dstintf port6
set srcaddr all
set dstaddr all
set action accept
set schedule always
set service ANY
next
edit 4
set srcintf port6
set dstintf port1
set srcaddr all
set dstaddr all
set action accept
set schedule always
set service ANY
next
edit 5
set srcintf port1
set dstintf lan
set srcaddr all
set dstaddr all
set action accept
set schedule always
set service ANY
next
edit 6
set srcintf lan
set dstintf port1
set srcaddr all
set dstaddr all
set action accept
set schedule always
set service ANY
next
edit 7
set srcintf port1
set dstintf port1
set srcaddr all
set dstaddr all
set action accept
set schedule always

454 01-420-99686-20101026
set service ANY

next
edit 8
set srcintf port6
set dstintf lo0
set srcaddr all
set dstaddr all
set action accept
set schedule always
set service ANY
next
edit 9
set srcintf port1
set dstintf lo0
set srcaddr all
set dstaddr all
set action accept
set schedule always
set service ANY
next
edit 10
set srcintf lan
set dstintf lo0
set srcaddr all
set dstaddr all
set action accept
set schedule always
set service ANY
next
end
Example debug commands

You can use the following CLI commands to view information about and status of the
multicast configuration. This section includes get and diagnose commands and some
sample output.
get router info multicast pim sparse-mode table 236.1.1.1
get router info multicast pim sparse-mode neighbour
Neighbor Interface Uptime/Expires Ver DR
Address Priority/
Mode
83.97.1.2 port6 02:22:01/00:01:44 v2 1 / DR
diagnose ip multicast mroute

status=resolved
num_ifs=2
index(ttl)=[6(1),10(1),]
status=resolved
last_assert=834864 bytes=4416 pkt=138 wrong_if=0 num_ifs=2
index(ttl)=[7(1),6(1),]

01-420-99686-20101026 455
status=resolved
num_ifs=1
index(ttl)=[7(1),]
get router info multicast igmp groups

IGMP Connected Group Membership
Group Address Interface Uptime Expires Last
Reporter
236.1.1.1 lan 00:45:48 00:03:21 10.4.1.1
236.1.1.1 lo0 02:19:31 00:03:23 1.4.50.4
get router info multicast pim sparse-mode interface

Address Interface VIFindex Ver/ Nbr DR DR
Mode Count Prior
10.4.1.2 lan 2 v2/S 0 1 10.4.1.2
83.97.1.1 port6 0 v2/S 1 1 83.97.1.2
1.4.50.4 lo0 3 v2/S 0 1 1.4.50.4
get router info multicast pim sparse-mode rp-mapping

PIM Group-to-RP Mappings
This system is the Bootstrap Router (v2)
Group(s): 224.0.0.0/4
RP: 1.4.50.4
Info source: 1.4.50.4, via bootstrap, priority 1
Uptime: 02:20:32, expires: 00:01:58
RP: 1.4.50.3
Uptime: 02:20:07, expires: 00:02:24
Group(s): 228.1.1.1/32
RP: 1.4.50.1
Uptime: 02:18:24, expires: 00:02:06
Group(s): 237.1.1.1/32
RP: 1.4.50.1
Uptime: 02:18:24, expires: 00:02:06
Group(s): 238.1.1.1/32
RP: 1.4.50.1
Uptime: 02:18:24, expires: 00:02:06
get router info multicast pim sparse-mode bsr-info

PIMv2 Bootstrap information
This system is the Bootstrap Router (BSR)
BSR address: 1.4.50.4
Uptime: 02:23:08, BSR Priority: 1, Hash mask length: 10
Next bootstrap message in 00:00:18
Role: Candidate BSR
State: Elected BSR
Candidate RP: 1.4.50.4(lo0)

Advertisement interval 60 seconds
Next Cand_RP_advertisement in 00:00:54

456 01-420-99686-20101026

01-420-99686-20101026 457

458 01-420-99686-20101026
IPv6
Internet Protocol version 6 (IPv6) is an Internet Layer protocol for packet-switched
internetworks that has been designed to provide several advantages over Internet
Protocol version 4 (IPv4). The Internet Engineering Task Force (IETF) has designated
IPv6 as the successor of IPv4 for general use on the Internet. Both IPv6 and IPv4 define
network layer protocols (how data is sent from one computer to another over
packet-switched networks), however IPv6 has a much larger address space than IPv4. It
can provide billions of unique IP addresses.
A major transition period from IPv4 to IPv6 is under way. For a lengthy period networks will
have to support both IPv4 and IPv6. The transition will not happen over night, simply
because of the time required to convert equipment and applications to IPv6. In addition
some legacy equipment and applications may never support IPv6 and will have to either
be replaced or will require ongoing support as IT budgets permit.
During this transition period, it will not be possible to operate an IPv6 network without also
supporting IPv4. Most networks will become mixed networks that have to understand and
route both IPv6 addresses and IPv4 addresses.
To be able to support both IPv4 and IPv6, FortiOS implements a dual stack architecture
that recognizes and separately routes both IPv4 and IPv6. In addition to routing, most vital
FortiOS network and content protection security features now fully support for IPv6.
This section includes:
• IPv6 overview
• FortiGate IPv6 configuration
• Transition from IPv4 to IPv6
• Configuring FortiOS to connect to an IPv6 tunnel provider
• IPv6 troubleshooting
• Additional IPv6 resources
IPv6 overview
IP version 6 handles issues that weren't around decades ago when IPv4 was created such
as running out of IP addresses, fair distributing of IP addresses, built-in quality of service
(QoS) features, better multimedia support, and improved handling of fragmentation. A
bigger address space, bigger default packet size, and more optional header extensions
provide these features with flexibility to customize them to any needs.
IPv6 has 128-bit addresses compared to IPv4's 32-bit addresses, effectively eliminating
address exhaustion. This new very large address space will likely reduce the need for
network address translation (NAT) since IPv6 provides more than a billion IP addresses
for each person on Earth. All hardware and software network components must support
this new address size, an upgrade that may take a while to complete and will force IPv6
and IPv4 to work side-by-side during the transition period. During that time FortiOS
supports IPv4 and IPv6 will ensure a smooth transition for networks.

01-420-99686-20101026 459
IPv6 overview IPv6
Differences between IPv6 and IPv4
Larger address IPv4 addresses are 32 bits long while IPv6 addresses are 128 bits
space long. This increase supports 2128 addresses, or more than ten billion
billion billion times as many addresses as IPv4 (232). IPv6 enables
more levels of addressing hierarchy and simplifies auto-configuration
of IP addresses. The IPv6 addressing scheme eliminates the need for
Network Address Translation (NAT) that causes networking problems
due to the end-to-end nature of the Internet, such as hiding multiple
hosts behind a pool of IP addresses.
Simplified The IPv6 header format either drops or makes optional certain IPv4
header formats header fields. This limits the bandwidth cost of the IPv6 header, even
though the IPv6 addresses are four times longer than the IPv4
addresses, the IPv6 header is only twice the size of the IPv4 header.
Improved Changes in the way IP header options are encoded and allows for
support for IP more efficient forwarding and less stringent limits on the length of
header options options. The changes also provide greater flexibility for introducing
new options in the future.
Prioritization of The IPv6 packet header contains a new Flow Label field that allows
packet delivery the sender to request special handling, such as “real-time service” or
using flow non-default quality of service. The Flow Label field replaces Service
labeling Type field in IPv4.
Supported IPv6 extensions support authentication, data integrity, and (optional)
authentication data confidentiality.
IPv6 addresses are assigned to interfaces rather than nodes, thereby recognizing that a
node can have more than one interface, and you can assign more than one IPv6 address
to an interface. In addition, the larger address space in IPv6 addresses allows flexibility in
allocating addresses and routing traffic, and simplifies some aspects of address
assignment and renumbering when changing Internet service providers.
With IPv4, complex Classless Inter-Domain Routing (CIDR) techniques were developed to
make the best use of the small address space. CIDR facilitates routing by allowing blocks
of addresses to be grouped together into a single routing table entry. With IPv4,
renumbering an existing network for a new connectivity provider with different routing
prefixes is a major effort (see RFC 2071, Network Renumbering Overview: Why would I
want it and what is it anyway? and RFC 2072, Router Renumbering Guide). With IPv6,
however, it is possible to renumber an entire network ad hoc by changing the prefix in a
few routers, as the host identifiers are decoupled from the subnet identifiers and the
network provider's routing prefix.
The size of each subnet in IPv6 is 264 addresses (64 bits), which is the square of the size
of the entire IPv4 Internet. The actual address space utilized by IPv6 applications will most
likely be small in IPv6, but both network management and routing will be more efficient.
IPv6 MTU
Maximum Transmission Unit (MTU) refers to the size (in bytes) of the largest packet or
frame that a given layer of a communications protocol can pass onwards. A higher MTU
brings higher bandwidth efficiency. IPv6 requires an MTU of at least 1280 bytes. With
encapsulations (for example, tunneling), an MTU of 1500 or more is recommended.

460 01-420-99686-20101026
IPv6 IPv6 overview
IPv6 address format

The IPv6 address is 128 bits long and consists of eight, 16-bit fields. Each field is
separated by a colon and must contain a hexadecimal number. In Figure 44, an X
represents each field.
The IPv6 address is made up of two logical parts:
• 64-bit (sub)network prefix
• 64-bit host
The (sub)network prefix part contains the site prefix (first three fields, 48 bits) and the
subnet ID (next two fields, 16-bits), for a total of 64-bits. The information contained in
these fields is used for routing IPv6 packets. The (sub)network prefix defines the site
topology to a router by specifying the specific link to which the subnet has been assigned.
The site prefix details the public topology allocated (usually by an Internet Service
Provider, ISP) to your site. The subnet ID details the private topology (or site topology) to a
router that you assign to your site when you configure your IPv6 network.
The host part consists of the interface ID (or token) which is 64-bits in length and must be
unique within the subnet. The length of the interface ID allows for the mapping of existing
48-bit MAC addresses currently used by many local area network (LAN) technologies
such as Ethernet, and the mapping of 64-bit MAC addresses of IEEE 1394 (FireWire) and
other future LAN technologies. The host is either configured automatically from the MAC
address of the interface, or is manually configured.
Figure 44: IPv6 Address Format
IP address notation
IPv6 addresses are normally written as eight groups of four hexadecimal digits each,
separated by a colon, for example:
2001:db8:3c4d:0d82:1725:6a2f:0370:6234
is a valid IPv6 address.
There are several ways to shorten the presentation of an IPv6 address. Most IPv6
addresses do not occupy all of the possible 128 bits. This results in fields that are
“padded” with zeros or contain only zeros. If a 4-digit group is 0000, it may be replaced
with two colons (::), for example:
2001:db8:3c4d:0000:1725:6a2f:0370:6234
is the same IPv6 address as:
2001:db8:3c4d::1725:6a2f:0370:6234
Leading zeroes in a group may be omitted, for example (in the address above):
2001:db8:3c4d::1725:6a2f:370:6234

01-420-99686-20101026 461
IPv6 overview IPv6
The double colon (::) must only be used once in an IP address, as multiple occurrences
lead to ambiguity in the address translation.
The following examples of shortened IP address presentations all resolve to the same
address.
19a4:0478:0000:0000:0000:0000:1a57:ac9e
19a4:0478:0000:0000:0000::1a57:ac9e
19a4:478:0:0:0:0:1a57:ac9e
19a4:478:0:0::1a57:ac9e
19a4:478::0:0:1a57:ac9e
19a4:478::1a57:ac9e
All of these address presentations are valid and represent the same address.
For IPv4-compatible or IPv4-mapped IPv6 addresses (see “Address types” on page 462),
you can enter the IPv4 portion using either hexadecimal or dotted decimal, but the
FortiGate CLI always shows the IPv4 portion in dotted decimal format. For all other IPv6
addresses, the CLI accepts and displays only hexadecimal.
Netmasks
As with IP addresses, hexadecimal notation replaces the dotted decimal notation of IPv4.
IPv4 Classless Inter-Domain Routing (CIDR) notation can also be used. This notation
appends a slash (“/”) to the IP address, followed by the number of bits in the network
portion of the address.
Table 46: IPv6 address notation
IP Address 3ffe:ffff:1011:f101:0210:a4ff:fee3:9566
Netmask ffff:ffff:ffff:ffff:0000:0000:0000:0000
Network 3ffe:ffff:1011:f101:0000:0000:0000:0000
CIDR IP/Netmask 3ffe:ffff:1011:f101:0210:a4ff:fee3:9566/64
Address scopes
Address scopes define the region where an address may be defined as a unique identifier
of an interface. The regions are: local link (link-local), site network (site-local), and global
network. Each IPv6 address can only belong to one zone that corresponds to its scope.
Address types
IPv6 addresses are classified into three groups - Unicast, Multicast, and Anycast.
Unicast
Identifies an interface of an individual node. Packets sent to a unicast address are sent to
that specific interface. Unicast IPv6 addresses can have a scope reflected in more specific
address names - global unicast address, link-local address, and unique local unicast
address. For more information, see “Global (Unicast)” on page 464, “Link-local (Unicast)”
on page 464, and “Site-local (Unicast)” on page 464.
Multicast
Multicast addresses are assigned to a group of interfaces that typically belong to different
nodes. A packet that is sent to a multicast address is delivered to all interfaces identified
by the address.

462 01-420-99686-20101026
IPv6 IPv6 overview
IPv6 multicast addresses are distinguished from unicast addresses by the value of the
high-order octet of the addresses. A value of 0xFF (binary 11111111) identifies an address
as a multicast address. Any other value identifies an address as a unicast address.
The four least significant bits of the second address octet identify the address scope or the
span over which the multicast address is propagated.
Anycast
Anycast addresses are assigned to a group of interfaces usually belonging to different
nodes. A packet sent to an anycast address is delivered to just one of the member
interfaces, typically the ‘nearest’ according to the router protocols’ choice of distance.
They cannot be identified easily as their structure is the same as a normal unicast
address, differ only by being injected into the routing protocol at multiple points in the
network. When a unicast address is assigned to more than one interface (making it an
anycast address), the address assigned to the nodes must be configured in such as way
as to indicate that it is an anycast address.
Interfaces configured for IPv6 must have at least one link-local unicast address and
additional ones for site-local or global addressing. Link-local addresses are often used in
network address autoconfiguration where no external source of network addressing
information is available.
Special addresses
The following are special IPv6 addresses:
• Unspecified
• Loopback
For more information about IPv6 addresses, see RFC 4921, IP Version 6 Addressing
Architecture
Table 47: IPv6 addresses with prefix information
Address Type IPv6 notation Details

Prefix/prefix length
Unspecified ::/128 Indicates the absence of an address, so must never be
assigned to any node. Must not be used as a source
address for IPv6 router, destination address of IPv6
packets, or in IPv6 routing headers.
Equivalent to 0.0.0.0 in IPv4.
Loopback ::1/128 Used as a node to send an IPv6 packet to itself. Seen as
link-local unicast address of a virtual interface (loopback
interface) to an imaginary link that goes nowhere. Must
never be assigned to a physical interface, or as the
source address of IPv6 packets that are sent outside of
the single node. IPv6 destination address of loopback
should not be sent outside a single node, and never
forwarded by an IPv6 router.
Equivalent to 127.0.0.1 in IPv4.
IPv4-compatible ::/96 Lowest 32 bits can be in IPv6 hexadecimal or IPv4 dotted
decimal format.
IPv4-mapped ::FFFF/96 Lowest 32 bits can be in IPv6 hexadecimal or IPv4 dotted
decimal format.
6to4 2002::/16 Used for communication between two nodes running both
IPv4 and IPv6 over the Internet. Formed by combining
the IPv6 prefix with the 32-bits of the public IPv4 address
of the node, creating a 48-bit address prefix.
Multicast ::FF00/8 For more information, see “Multicast” on page 462.

01-420-99686-20101026 463
IPv6 overview IPv6
Table 47: IPv6 addresses with prefix information
Address Type IPv6 notation Details

Prefix/prefix length
Anycast All prefixes except For more information, see “Anycast” on page 463.
those listed above
Link-local FE80::/10 Used for addressing on a single link for automatic
(Unicast) address configuration, neighbor discovery, or when no
routers are present.
Routers must not forward packets with link-local source
or destination addresses.
Site-local FEC0::/10 Used for addressing inside of a site without needing a
(Unicast) global prefix.
Routers must not forward packets with site-local source
or destination addresses outside of the site.
Global (Unicast) all other prefixes Equivalent to public IPv4 addresses. Globally routable
and reachable on the IPv6 internet. Addresses are
designed to be summarized or aggregated to create an
efficient router infrastructure.
IPv6 neighbor discovery

IPv6 Neighbor Discovery (ND) is a set of messages and processes that determine
relationships between neighboring nodes. Neighboring nodes are on the same link. The
IPv6 ND protocol replaces the IPv4 protocols Address Resolution Protocol (ARP), Internet
Control Message Protocol (ICMPv4), Router Discovery (RDISC), and ICMP Redirect, and
provides additional functionality. The IPv6 ND protocol facilitates the autoconfiguration of
IPv6 addresses. Autoconfiguration is the ability of an IPv6 host to automatically generate
its own IPv6 address, making address administration easier and less time-consuming.
Hosts use ND to:
• discover addresses, address prefixes, and other configuration parameters
• discover neighboring routers.
Routers use ND to:
• advertise their presence, host configuration parameters, and on-link prefixes
• inform hosts of ‘better’ next-hop address to forward packets for a specified destination.
Nodes use ND to:
• resolve link-layer address of a neighboring node to which an IPv6 packet is being
forwarded and determine whether the link-layer address of a neighboring node has
altered
• determine whether IPv6 packets can be sent to and received from a neighbor
• automatically configure IPv6 addresses for its interfaces.
To facilitate neighbor discovery, routers periodically send messages advertising their
availability. This communication includes lists of the address prefixes for destinations
available on each router’s interfaces.
ND defines five different Internet Control Message Protocol (ICMP) packet types: a pair of
Neighbor Solicitation and Neighbor Advertisement messages, a pair of Router Solicitation
and Router Advertisement messages, and a Redirect message.

464 01-420-99686-20101026
IPv6 FortiGate IPv6 configuration
A Neighbor Solicitation is sent by a node to determine the link-layer address of a neighbor,

or to verify that a neighbor is still reachable via a cached link-layer address. Also used for
Duplicate Address Detection (how a node determines that an address it wants to use is
not already in use by another node). The Neighbor Advertisement message is a response
to a Neighbor Solicitation message. A node may also announce a link-layer address
change by sending unsolicited Neighbor Advertisements.
A host may send a Router Solicitation when an interface becomes enabled, requesting
routers to generate a Router Advertisement immediately rather than at their next
scheduled time.
Routers advertise their presence together with various link and Internet parameters
according to a specific schedule or in response to a Router Solicitation message. A Router
Advertisement contains prefixes used for on-link determination and/or address
configuration, a suggested hop limit value, etc.
The Redirect message is used by routers to inform hosts of a better first-hop for a
destination.
For more information, see RFC 2461, Neighbor Discovery for IP Version 6 (IPv6).
FortiGate IPv6 configuration

FortiOS (4.0 MR2) supports the following FortiOS IPv6 features (all configurable from the
web-based manager or CLI):
• Static routing and dynamic routing
• Network interface addressing
• Routing access lists and prefix lists
• IPv6 tunnel over IPv4, IPv4 tunnel over IPv6
• Firewall policies
• IPv6 over SCTP
• Packet and network sniffing
• IPsec VPNs
• UTM protection including
• NAT/Route and Transparent mode
• Logging and reporting
• IPv6 specific troubleshooting such as ping6
UTM protection for IPv6 networks

FortiOS uses IPv6 firewall policies to provide UTM protection for IPv6 traffic. Antivirus,
web filtering, FortiGuard Web Filtering, email filtering, FortiGuard Email Filtering, data leak
prevention (DLP), and VoIP protection features can be enabled in IPv6 firewall policies
using normal FortiOS UTM profiles for each UTM feature.
Displaying IPv6 options on the web-based manager

Before configuring IPv6 using the web-based manager, you must first turn on IPv6 display
by going to System > Admin > Settings and selecting the IPv6 support option.Once turned
on, IPv6-related options and pages appear throughout the web-based manager. For
example, you can add IPv6 addresses to any FortiGate interface, you can add IPv6 DNS
server IP addresses, IPv6 firewall policies, IPv6 firewall addresses and so on.

01-420-99686-20101026 465
FortiGate IPv6 configuration IPv6
Configuring IPv6 interfaces

The dual stack architecture is most obvious when configuring IPv6 on interfaces on your
FortiGate unit.
IPv6 interfaces - web-based manager

In the Addressing mode section of the Create New or Edit screen, there are two fields
instead of one. Without IPv6 enabled, there is only the IP/Netmask field for IPv4
addresses. With IPv6 enabled, there is an additional field called IPv6 Address.
With both addresses configured for an interface, that interface will accept both IPv4 and
IPv6 traffic. Each protocol will be handled differently, depending on the firewall policies
and routing in place for it. This allows traffic from IPv6 to be sent to other IPv6 devices,
and IPv4 traffic to be sent only to other IPv4 devices. This separation of the traffic is
required because if IPv6 traffic is sent to devices that don’t support it, that traffic will not
reach its destination.
You should enable IPv6 Administrative Access to connect to the IPv6 address of an
interface for administration.
IPv6 interfaces - CLI

In the CLI, there are a number of IPv6 specific interface settings. These are found as part
of the config system interface command under config ipv6. In the CLI there
are many more settings available, although many are optional. The settings that are
required or recommended are highlighted.
edit <interface_string>
config ipv6
set ip6-address <ipv6_addr>
set ip6-allowaccess <http https ping ssh telnet>
set ip6-link-mtu <bytes_int>
set ip6-send-adv <enable | disable>
set autoconf <enable | disable>
set ip6-default-life <seconds_int>
set ip6-hop-limit <count_int>
set ip6-manage-flag <enable | disable>
set ip6-max-interval <integer>
set ip6-min-interval <integer>
set ip6-other-flag <enable | disable>
set ip6-reachable-time <integer>
set ip6-retrans-time <integer>
config ip6-extra-addr
edit <ipv6_addr>
end
config ip6-prefix-list
set autonomous-flag <enable | disable>
set onlink-flag <enable | disable>
set preferred-life-time <integer>
set valid-life-time <integer>
end
end
end

466 01-420-99686-20101026
Configuring IPv6 routing

IPv6 routing is supported in both static and dynamic routing. The main difference from a
configuration point of view is in the addresses.
Static routing
Static routing for IPv6 is essentially the same as with IPv4. From a configuration point of
view, the only difference is the type of addresses used. When both IPv4 and IPv6 static
routes are configured, they are displayed under two separate headings on the static
routing page - Route and IPv6 Route. Use the arrows next to each heading to expand or
minimize that list of routes.
To configure IPv6 static routes - web-based manager

2 Select arrow to expand the Create New menu.
3 Select IPv6 Route.
4 Enter Destination IP/Mask, Device, Gateway, Distance, and Priority as with normal
static routing using IPv6 addresses.
5 Select OK.
To configure IPv6 static routes - CLI

Use the following command to add an IPv6 static route:
config router static6
edit 1
set dst <ipv6_addr>
set gateway <ipv6_addr>
set device <interface>
set priority <integer>
end
Dynamic routing
As with static routing, the dynamic routing protocols all have IPv6 versions. Both IPv4 and
IPv6 dynamic routing can be running at the same time due to the dual stack architecture of
the FortiGate unit. IPv6 dynamic routing must be configured using CLI commands.
Table 48: Dynamic routing protocols, IPv6 versions, CLI command, and RFCs
Dynamic IPv6 CLI command IPv6 RFC

Routing
RIP RIP next generation (RIPng) config router ripng RFC 2080
BGP BGP4+ config router bgp RFC 2545 and
All parts of bgp that include IP RFC 2858
addresses have IPv4 and IPv6
versions.
OSPF OSPFv3 config rotuer ospf6 RFC 2740
Configuring IPv6 firewall policies

Configuring IPv6 firewall policies is similar to configuring IPv4 firewall policies. On the
web-based manager go to Firewall > IPv6 Policy. From the CLI use the command config
firewall policy6. You must also add IPv6 firewall addresses (Firewall > Address or
config firewall address6) and address groups (Firewall > Address > Group or
config firewall addgrp6).

01-420-99686-20101026 467
Configuring IPv6 DNS

Configuring DNS servers with IPv6 addresses is located in the same location as IPv4, by
going to System > Network > Options. There is a separate area for adding IPv6 addresses
for DNS. From the CLI, use the command config system dns, where additional
commands ip6-primary and ip6-secondary are available.
Configuring IPv6 over IPv4 tunneling

IPv6 over IPv4 tunneling can only be configured in the CLI using the config system
sit-tunnel command. When you configure an IPv6 over IPv4 tunnel, you are creating a
virtual interface that can be used in configurations just like any other virtual interface such
as VLANs.
The name of the command sit-tunnel comes from Simple Internet Transition (SIT)
tunneling. For the period while IPv6 hosts and routers co-exist with IPv4, a number of
transition mechanisms are needed to enable IPv6-only hosts to reach IPv4 services and to
allow isolated IPv6 hosts and networks to reach the IPv6 Internet over the IPv4
infrastructure.
These techniques, collectively called Simple Internet Transition, include:
• dual-stack IP implementations for interoperating hosts and routers
• embedding IPv4 addresses in IPv6 addresses
• IPv6-over-IPv4 tunneling mechanisms
• IPv4/IPv6 header translation
The syntax for the IPv6 over IPv4 tunneling CLI command is:
config system sit-tunnel
edit <name_string>
set destination <ipv4_addr>
set interface <interface_string>
set ip6 <ipv6_addr>
set source <ipv4_addr>
next
end
<name_string> This will be the name of the tunnel, and appear in the network
interface list. It should be descriptive such as my_ip6_tunnel.
The maximum length allowed is 15 characters.
destination This is the tunnel broker’s IPv4 server address. It is one of the two
<ipv4_addr> ends of the tunnel.
interface This interface is the interface the tunnel piggy backs on. Generally
<interface_string> this should be the external interface of the FortiGate unit.
This setting is optional if you don’t have a fixed IP address from
your ISP.
ip6 <ipv6_addr> The IPv6 address of the tunnel.
source <ipv4_addr> This is the FortiGate unit end of the tunnel. It is just like any other
FortiGate unit interface address.
If this address is DHCP-based, it will change. In that case you
should ensure the netmask covers the possible range of
addresses. It is possible to use 0.0.0.0 to cover all possible
addresses if you have a DDNS or PPoE connection where the
address changes.
For more configuration of tunnels see “Configuring FortiOS to connect to an IPv6 tunnel
provider” on page 471.

468 01-420-99686-20101026
Configuring IPv6 IPSec VPNs

The FortiGate unit supports route-based IPv6 IPsec, but not policy-based.
Where both the gateways and the protected networks use IPv6 addresses, sometimes
called IPv6 over IPv6, you can create either an auto-keyed or manually-keyed VPN. You
can combine IPv6 and IPv4 addressing in an auto-keyed VPN in the following ways:
IPv4 over IPv6 The VPN gateways have IPv6 addresses.

The protected networks have IPv4 addresses. The phase 2 configurations at
either end use IPv4 selectors.
The protected networks use IPv6 addresses. The phase 2 configurations at
Compared with IPv4 IPsec VPN functionality, there are some limitations:
• Except for IPv6 over IPv4, remote gateways with Dynamic DNS are not supported.
This is because FortiOS 3.0 does not support IPv6 DNS.
• You cannot use RSA certificates in which the common name (cn) is a domain name
that resolves to an IPv6 address. This is because FortiOS 3.0 does not support IPv6
DNS.
• DHCP over IPsec is not supported, because FortiOS 3.0 does not support IPv6 DHCP.
• Selectors cannot be firewall address names. Only IP address, address range and
subnet are supported.
• Redundant IPv6 tunnels are not supported.
Certificates
On a VPN with IPv6 phase 1 configuration, you can authenticate using VPN certificates in
which the common name (cn) is an IPv6 address. The cn-type keyword of the user
peer command has an option, ipv6, to support this.
Configuring IPv6 IPsec VPNs

Configuration of an IPv6 IPsec VPN follows the same sequence as for an IPv4
route-based VPN: phase 1 settings, phase 2 settings, firewall policies and routing.
To access IPv6 functionality through the web-based manager, go to System Admin >
Settings and enable IPv6 Support on GUI.
Phase 1 configuration
In the web-based manager, you define the Phase 1 as IPv6 in the Advanced settings.
Enable the IPv6 Version check box. You can then enter an IPv6 address for the remote
gateway.
In the CLI, you define an IPsec phase 1 configuration as IPv6 by setting ip-version
to 6. Its default value is 4. Then, the local-gw and remote-gw keywords are hidden
and the corresponding local-gw6 and remote-gw6 keywords are available. The values
for local-gw6 and remote-gw6 must be IPv6 addresses.

01-420-99686-20101026 469
For example:
config vpn ipsec phase1-interface
edit tunnel6
set ip-version 6
set remote-gw6 0:123:4567::1234
set interface port3
set proposal 3des-md5
end
To create an IPv6 IPsec phase 2 configuration in the web-based manager, you need to
define IPv6 selectors in the Advanced settings. Change the default 0.0.0.0/0 address
for Source address and Destination address to the IPv6 value ::/0. If needed, enter
specific IPv6 addresses, address ranges or subnet addresses in these fields.
In the CLI, set src-addr-type and dst-addr-type to ip6, range6 or subnet6 to
specify IPv6 selectors. By default, zero selectors are entered, ::/0 for the subnet6
address type, for example. The simplest IPv6 phase 2 configuration looks like the
following:
edit tunnel6_p2
set phase1name tunnel6
set src-addr-type subnet6
set dst-addr-type subnet6
end
Firewall policies
To complete the VPN configuration, you need a firewall policy in each direction to permit
traffic between the protected network’s port and the IPsec interface. You need IPv6
policies unless the VPN is IPv4 over IPv6.
Routing
Appropriate routing is needed for both the IPsec packets and the encapsulated traffic
within them. You need a route, which could be the default route, to the remote VPN
gateway via the appropriate interface. You also need a route to the remote protected
network via the IPsec interface.
To create a static route in the web-based manager, go to Router > Static > Static Route.
Select the drop-down arrow for Create New and select IPv6 Route. Enter the information
and select OK. In the CLI, use the router static6 command. For example, where the
remote network is fec0:0000:0000:0004::/64 and the IPsec interface is toB:
edit 1
set device port2
set dst 0::/0
next
edit 2
set device toB
set dst fec0:0000:0000:0004::/64
next
end

470 01-420-99686-20101026
IPv6 Transition from IPv4 to IPv6
If the VPN is IPV4 over IPv6, the route to the remote protected network is an IPv4 route. If
the VPN is IPv6 over IPv4, the route to the remote VPN gateway is an IPv4 route.
Transition from IPv4 to IPv6

If the Internet is to take full advantage of the benefits of IPv6, there must be a period of
transition to enable IPv6-only hosts to reach IPv4 services and to allow isolated IPv6 hosts
and networks to reach the IPv6 Internet over the IPv4 infrastructure.
RFC 2893, Transition Mechanisms for IPv6 Hosts and Routers and RFC 2185, Routing
Aspects of IPv6 Transition define several mechanisms to ensure that IPv6 hosts and
routers maintain interoperability with the existing IPv4 infrastructure, and facilitate a
gradual transition that does not impact the functionality of the Internet. The mechanisms,
known collectively as Simple Internet Transition (SIT), include:
• dual-stack IP implementations for hosts and routers that must interoperate between
IPv4 and IPv6
• embedding of IPv4 addresses in IPv6 addresses. IPv6 hosts are assigned addresses
that are interoperable with IPv4, and IPv4 host addresses are mapped to IPv6
• IPv6-over-IPv4 tunneling mechanisms to encapsulate IPv6 packets within IPv4
headers to carry them over IPv4 infrastructure
• IPv4/IPv6 header translation, used when implementation of IPv6 is well-advanced and
few IPv4 systems remain.
FortiGate units are dual IP layer IPv6/IPv4 nodes and they support IPv6 over IPv4
tunneling. For more information, see RFC 2893, Transition Mechanisms for IPv6 Hosts
and Routers and RFC 2185, Routing Aspects of IPv6 Transition.
Configuring FortiOS to connect to an IPv6 tunnel provider

If an organization with a mixed network uses an Internet service provider that does not
support IPv6, they can use an IPv6 tunnel broker to connect to IPv6 addresses on the
Internet. FortiOS supports IPv6 tunnelling over service provider IPv4 networks to tunnel
brokers. The tunnel broker extracts the IPv6 packets from the tunnel and routes them to
their IPv6 destination. The internal network is running IPv6. The FortiGate unit creates an
IPv6-over-IPv4 tunnel to the IPv6 tunnel broker. From the tunnel broker, your network can
access IPv6 addresses on the Internet.
In this example the internal network is small and directly connected to the FortiGate unit.
There is no need for routing on the internal network since everything is connected and on
the same subnet. For this example, consider the following:
• Before configuring your FortiGate unit for IPv6-over-IPv4 tunneling, you need to
choose an IPv6 tunnel broker and get their information.
• The addresses used in this example are for example use only.
• VDOMs are not enabled.
• The tunnel broker IPv4 address is 78.35.24.124.
• The tunnel broker IPv6 end of the tunnel is 2001:4dd0:ff00:15e::1/64.
• The FortiGate unit external IPv4 address is 172.20.120.17.
• The FortiGate unit IPv6 address of the tunnel is 2001:4dd0:ff00:15e::2/64.
• port1 of the FortiGate unit is connected to the internal network.
• port2 of the FortiGate unit is connected to the external network (Internet).

01-420-99686-20101026 471
Configuring FortiOS to connect to an IPv6 tunnel provider IPv6
Figure 45: Connecting to an IPv6 tunnel broker
v6
IP
IP b r
v6 ok
tu e r
IP 4
nn
v6 tu
el
IP
-o n n
v
ve el
r
IP Ne
v6 tw
In or
te k
rn
al
Steps to connect to an IPv6 tunnel broker
1 Create a SIT-Tunnel Interface
2 Create a static IPv6 Route into the Tunnel-Interface
3 Assign your IPv6 Network to your FortiGate
4 Create a Firewall-Policy to allow Traffic from LAN to the Tunnel-Interface
Create a SIT-tunnel interface

Creating the SIT-tunnel creates a virtual interface in the form of a tunnel, much like a VPN
interface. The end points of the tunnel are the FortiGate unit and the tunnel broker’s server
addresses.
In the example, the external address of the FortiGate unit is DHCP-based and may
change to any value on that subnet, so the source address allows for that.
config system sit-tunnel
edit HE_ip6_broker
set destination 78.35.24.124
set interface port2
set ip6 2001:4dd0:ff00:15e::2/64
set source 172.20.120.0
next
end

472 01-420-99686-20101026
IPv6 Configuring FortiOS to connect to an IPv6 tunnel provider
Now that the tunnel exists, some additional interface commands are required. Such as
enabling ping6 for troubleshooting and allow HTTPS and SSH administration connections
to the interface.
edit HE_ip6_broker
config ipv6
set ip6-allowaccess ping https ssh
end
next
end
Create a static IPv6 route into the tunnel-Interface

With the tunnel up and the firewall policies in place, all that remains is to add a default
route for IPv6 traffic to go over the tunnel. As there will only be one static routing entry,
there is no need for a priority. This may change in the future if other routes are added.
edit 1
set device HE_ip6_broker
next
end
Assign your IPv6 network to your FortiGate

This step assigns an IPv6 address to the internal interface on the FortiGate unit. That way
all IPv6 traffic entering on this interface will be routed to the tunnel. Systems with
addresses within this prefix are reachable on the subnet in question without help from a
router, so the onlink-flag is enabled. Hosts can create an address for themselves by
combining this prefix with an interface identifier, so the autonomous-flag is enabled.
edit port1
config ipv6
set ip6-address 2001:4dd0:ff42:72::1/64
set ip6-allowaccess ping https ssh
config ip6-prefix-list
edit 2001:4dd0:ff42:72::/64
set autonomous-flag enable
set onlink-flag enable
set preferred-life-time 3600
set ip6-send-adv enable
next
end
next
end
At this point any PCs on your internal network that are set to auto-configure, should have
their addresses. To test this you can ping6 from the PC to the FortiGate unit. See “IPv6
ping description” on page 475.
Create a firewall policy to allow traffic from port1 to the tunnel interface
With the tunnel configured, it will appear as an interface in the Network interface list. That
means the next step is to add a firewall policies to allow traffic to and from the tunnel.
config firewall policy6
edit 2

01-420-99686-20101026 473
IPv6 troubleshooting IPv6
set srcintf port1

set dstintf HE_ip6_broker
set srcaddr "::/0"
set dstaddr "::/0"
set action accept
set schedule "always"
set service "ANY"
next
end
Test the connection

To test the tunnel, try to connect to an external IPv6 address such as
http://ipv6.google.com.
If you want to see the path the IPv6 traffic takes, do a traceroute from a PC on the internal
network to an external address. You will see the traffic enter the FortiGate unit, enter the
tunnel, pass through the tunnel broker server, and on out over the Internet.
If you are entering an IPv6 address into your web browser, you have to type:
https://[2001:4dd0:ff42:72::1]. The square brackets are to discriminate
between the address part and a port, like in
https://[2001:4dd0:ff42:72::1]:8080
IPv6 troubleshooting
There are a number of troubleshooting methods that can be used with IPv6 issues.
ping6
The main method of troubleshooting IPv6 traffic is using the IPv6 version of ping.
You can use the IPv6 ping command to:
• send an ICMP echo request packet to the IPv6 address that you specify.
• specify a source interface other than the one from which the probe originates by using
the source interface keywords.
• specify a source IP address other than the one from which the probe originates by
using the source address keywords
You can specify the following options:

474 01-420-99686-20101026
IPv6 IPv6 troubleshooting
packetCount Number of packets to send to the destination IPv6 address. If you specify a zero,
echo requests packets are sent indefinitely.
data-pattern Sets the type of bits contained in the packet to all ones, all zeros, a random
mixture of ones and zeros, or a specific hexadecimal data pattern that can range
from 0x0 to 0xFFFFFFFF. The default is all zeros.
extended Set the interface type and specifier of a destination address on the system that is
header configured for external loopback; the command succeeds only if the specified
attributes interface is configured for external loopback.
sweep interval Specifies the change in the size of subsequent ping packets while sweeping
across a range of sizes. For example, you can configure the sweep interval to
sweep across the range of packets from 100 bytes to 1000 bytes in increments
specified by the sweep interval. By default, the system increments packets by
one byte; for example, it sends 100, 101, 102, 103, ... 1000. If the sweep interval
is 5, the system sends 100, 105, 110, 115, ... 1000.
sweep sizes Enables you to vary the sizes of the echo packets being sent. Used to determine
the minimum sizes of the MTUs configured on the nodes along the path to the
destination address. This reduces packet fragmentation, which contributes to
performance problems. The default is to not sweep (all packets are the same
size).
timeout Sets the number of seconds to wait for an ICMP echo reply packet before the
connection attempt times out.
hop limit Sets the time-to-live hop count in the range 1-255; the default is 255.
The following characters may appear in the display after the ping command is issued:
! - reply received
. - timed out while waiting for a reply
? - unknown packet type
A - admin unreachable
b - packet too big
H - host unreachable
N - network unreachable
P - port unreachable
p - parameter problem
S - source beyond scope
t - hop limit expired (TTL expired)
IPv6 ping description

Ping uses the ICMP protocol's mandatory ECHO_REQUEST datagram to elicit an ICMP
ECHO_RESPONSE from a host or gateway. ECHO_REQUEST datagrams (''pings'') have
an IP and ICMP header, followed by a struct timeval and then an arbitrary number of ''pad''
bytes used to fill out the packet.

01-420-99686-20101026 475
IPv6 ping options
-a Audible ping.
-A Adaptive ping. Interpacket interval adapts to round-trip time, so effectively no
more than one (or more, if preload is set) unanswered probe is present in the
network. Minimal interval is 200msec for any user other than administrator. On
networks with low rtt this mode is essentially equivalent to flood mode.
-b Allow pinging of a broadcast address.
-B Do not allow ping to change source address of probes. The address is bound to
one selected when the ping starts.
-c count Stop after sending count ECHO_REQUEST packets. With deadline option, ping
waits for count ECHO_REPLY packets, until the timeout expires.
-d Set the SO_DEBUG option on the socket being used.
This socket option is not used by a Linux kernel.
-F flow label Allocate and set 20 bit flow label on echo request packets (only ping6). If value is
zero, kernel allocates random flow label.
-f Flood ping. For every ECHO_REQUEST sent a period ''.'' is displayed, while for
ever ECHO_REPLY received a backspace is displayed. This provides a rapid
display of how many packets are being dropped. If interval is not specified, it is
set to zero and packets are output as fast as they come back or one hundred
times per second, whichever is faster. Only the administrator may use this option
with zero interval.
-i interval Wait a specified interval of seconds between sending each packet. The default is
1 second between each packet, or no wait in flood mode. Only an administrator
can set the interval to a value of less than 0.2 seconds.
-I interface Set source address to specified interface address. Argument may be numeric IP
address address or name of device. This option is required when you ping an IPv6
link-local address.
-l preload If preload is specified, ping sends this number of packets that are not waiting for
a reply. Only the administrator may select a preload of more than 3.
-L Suppress loopback of multicast packets. This flag only applies if the ping
destination is a multicast address.
-n Numeric output only. No attempt will be made to look up symbolic names for host
addresses.
-p pattern You may specify up to 16 ''pad'' bytes to fill out the packet you send. This is
useful for diagnosing data-dependent problems in a network. For example, -p ff
will cause the sent packet to be filled with all ones.
-Q tos Set Quality of Service -related bits in ICMP datagrams. tos can be either decimal
or hex number. Traditionally (RFC1349), these have been interpreted as: 0 for
reserved (currently being redefined as congestion control), 1-4 for Type of
Service and 5-7 for Precedence. Possible settings for Type of Service are:
minimal cost: 0x02, reliability: 0x04, throughput: 0x08, low delay: 0x10. Multiple
TOS bits should not be set simultaneously. Possible settings for special
Precedence range from priority (0x20) to net control (0xe0). You must be root
(CAP_NET_ADMIN capability) to use Critical or higher precedence value. You
cannot set bit 0x01 (reserved) unless ECN has been enabled in the kernel. In
RFC 2474, these fields has been redefined as 8-bit Differentiated Services (DS),
consisting of: bits 0-1 of separate data (ECN will be used, here), and bits 2-7 of
Differentiated Services Codepoint (DSCP).
-q Quiet output. Nothing is displayed except the summary lines at startup time and
when finished
-R Record route. (IPv4 only) Includes the RECORD_ROUTE option in the
ECHO_REQUEST packet and displays the route buffer on returned packets.
Note that the IP header is only large enough for nine such routes. Many hosts
ignore or discard this option.

476 01-420-99686-20101026
IPv6 IPv6 troubleshooting
-r Bypass the normal routing tables and send directly to a host on an attached
interface. If the host is not on a directly-attached network, an error is returned.
This option can be used to ping a local host through an interface that has no
route through it provided the option -I is also used.
-s packetsize Specifies the number of data bytes to be sent. The default is 56, which translates
into 64 ICMP data bytes when combined with the 8 bytes of ICMP header data.
-S sndbuf Set socket sndbuf (send buffer). If not specified, it is selected to buffer not more
than one packet.
-t ttl Set the IP Time to Live.
-T timestamp Set special IP timestamp options. May be either tsonly (only timestamps),
option tsandaddr (timestamps and addresses) or tsprespec host1 [host2 [host3 [host4]]]
(timestamp prespecified hops).
-M hint Select Path MTU Discovery strategy. hint may be either do (prohibit
fragmentation, even local one), want (do PMTU discovery, fragment locally when
packet size is large), or don’t (do not set DF flag).
-U Print full user-to-user latency (the old behavior). Normally ping prints network
round trip time, which can be different f.e. due to DNS failures.
-v Verbose output.
-V Show version and exit.
-w deadline Specify a timeout, in seconds, before ping exits regardless of how many packets
have been sent or received. In this case ping does not stop after count packet
are sent, it waits either for deadline expire or until count probes are answered or
for some error notification from network.
-W timeout Time to wait for a response, in seconds. The option affects only timeout in
absence of any responses, otherwise ping waits for two RTTs.
Examples
Ping a global V6 address with a 1400 byte packet from FortiGate CLI:
execute ping6 –s 1400 2001:480:332::10
Ping a multicast group using a ping6 command on FortiGate CLI ( -I and port name must
be specified for CLI ping6 command to ping v6 multicast group):
execute ping6 –I port1 ff02::1
Ping a localnet v6 address from FortiGate CLI:
execute ping6 FE80:0:0:0:213:e8ff:fe9e:ccf7
This address would normally be written as FE80::213:e8ff:fe9e:ccf7.
diagnose sniffer packet

The FortiOS built in packet sniffer also works with IPv6. The following are some examples
using an IPv6-over-IPv4 tunnel called test6.
diagnose sniffer packet test6 'none' 4
interfaces=[test6]
filters=[]
pcap_lookupnet: test6: no IPv4 address assigned
34.258651 test6 -- 2001:4dd0:ff00:15d::2 -> 2001:4dd0:ff00:15d::1:
icmp6: echo request seq 1
34.324658 test6 -- 2001:4dd0:ff00:15d::1 -> 2001:4dd0:ff00:15d::2:
icmp6: echo reply seq 1
35.268581 test6 -- 2001:4dd0:ff00:15d::2 -> 2001:4dd0:ff00:15d::1:
icmp6: echo request seq 2
35.334230 test6 -- 2001:4dd0:ff00:15d::1 -> 2001:4dd0:ff00:15d::2:
icmp6: echo reply seq

01-420-99686-20101026 477
diagnose sniffer packet any 'ip6 and tcp port 80' 4 10

interfaces=[any]
filters=[ip6 and tcp port 80]
1 LAN in 2001:4dd0:ff42:72:21b:63ff:fe08:e071.53037 ->
2a00:1450:8007::63.80: syn 2298823882
2 test6 out 2001:4dd0:ff42:72:21b:63ff:fe08:e071.53037 ->
2a00:1450:8007::63.80: syn 2298823882
3 test6 in 2a00:1450:8007::63.80 ->
2001:4dd0:ff42:72:21b:63ff:fe08:e071.53037: syn 4218782319
ack
4 LAN out 2a00:1450:8007::63.80 ->
2001:4dd0:ff42:72:21b:63ff:fe08:e071.53037: syn 4218782319
ack
5 LAN in 2001:4dd0:ff42:72:21b:63ff:fe08:e071.53037 ->
2a00:1450:8007::63.80: ack 4218782320
6 test6 out 2001:4dd0:ff42:72:21b:63ff:fe08:e071.53037 ->
2a00:1450:8007::63.80: ack 4218782320
diagnose debug flow

The diagnose debug flow CLI command is the same for IPv6 or IPv4. The output
format is the same, however the command is only slightly different in that it uses filter6
and an IPv6 address.
To enable diag debug flow for IPv6 - CLI

# diagnose debug enable
# diagnose debug flow show console enable
# diagnose debug flow show func enable
# diagnose debug flow filter6 addr 2001:4dd0:ff42:12::24
# diagnose debug flow trace start6
IPv6 specific diag commands

To list all the sit-tunnels that are configured:
diagnose ipv6 sit-tunnel list
total tunnel = 1:
devname=test6 devindex=4 ifindex=22 saddr=0.0.0.0
daddr=88.25.29.134 proto=41 vfid=0000 ref=2
To list all the IPv6 routes:
diagnose ipv6 route list
vf=0 type=02 protocol=unspec flag=00200001 oif=8(root)
dst:::1/128 gwy::: prio=0
dst:2001:4dd0:ff00:75d::2/128 gwy::: prio=0
vf=0 type=01 protocol=kernel flag=00240021 oif=22(sixxs)
dst:2001:4dd0:ff00:75d::/64 gwy::: prio=100
dst:2001:4dd0:ff42:68::1/128 gwy::: prio=0
vf=0 type=01 protocol=kernel flag=01040001 oif=19(LAN)
dst:2001:4dd0:ff42:68:225:ff:feee:5314/128
gwy:2001:4dd0:ff42:68:225:ff:feee:5314 prio=0
.....
Some other IPv6 diagnose commands include:

478 01-420-99686-20101026
IPv6 Additional IPv6 resources
diagnose ipv6 neighbor-cache Add, delete, flush, or list the IPv6 ARP table or table entry.
diagnose sys session6 Clear, filter, full-stat, list, stat IPv6 sessions.
tree diagnose ipv6 View all the diagnose IPv6 commands.
Additional IPv6 resources

There are many RFCs available regarding IPv6. The following table lists the major IPv6
articles and their Internet Engineering Task Force (IETF) web locations.
Table 49: Additional IPv6 resources
RFC Subject Location
RFC 1933, Transition Describes IPv4 compatibility http://www.ietf.org/rfc/rfc1933
Mechanisms for IPv6 Hosts mechanisms that can be implemented by
and Routers IPv6 hosts and routers
RFC 2185, Routing Provides an overview of the routing http://www.ietf.org/rfc/rfc2185
Aspects of IPv6 Transition aspects of the IPv6 transition
RFC 2373, IP Version 6 Defines the addressing architecture of http://www.ietf.org/rfc/rfc2373
Addressing Architecture the IP Version 6 protocol [IPV6]
RFC 2402, IP Describes functionality and http://www.ietf.org/rfc/rfc2402
Authentication Header implementation of IP Authentication
Headers (AH)
RFC 2460, Internet Describes functionality, configuration of http://www.ietf.org/rfc/rfc2460
Protocol, Version 6 (IPv6) IP version 6 (IPv6) and differences from
Specification IPv4.
RFC 2461, Neighbor Describes the features and functions of http://www.ietf.org/rfc/rfc2461
Discovery for IP Version 6 IPv6 Neighbor Discovery protocol
(IPv6)
RFC 2462, IPv6 Stateless Specifies the steps a host takes in http://www.ietf.org/rfc/rfc2462
Address Autoconfiguration deciding how to autoconfigure its
interfaces in IPv6
RFC 2893, Transition Specifies IPv4 compatibility mechanisms http://www.ietf.org/rfc/rfc2893
Mechanisms for IPv6 Hosts that can be implemented by IPv6 hosts
and Routers and routers
RFC 3306, Unicast-Prefix- Describes the format and types of Ipv6 http://www.ietf.org/rfc/rfc3306
Based IPv6 Multicast multicast addresses
Addresses
RFC 3484, Default Describes the algorithms used in IPv6 http://www.ietf.org/rfc/rfc3484
Address Selection for default address selection
Internet protocol version 6
(IPv6)
RFC 3513, Internet Contains details about the types of IPv6 http://www.ietf.org/rfc/rfc3513
Protocol version 6 (IPv6) addresses and includes examples
Addressing Architecture
RFC 3587, IPv6 Global Defines the standard format for IPv6 http://www.ietf.org/rfc/rfc3587
Unicast Address Format unicast addresses

01-420-99686-20101026 479
Additional IPv6 resources IPv6

480 01-420-99686-20101026
Virtual LANs
Virtual Local Area Networks (VLANs) multiply the capabilities of your FortiGate unit, and
can also provide added network security. Virtual LANs (VLANs) use ID tags to logically
separate devices on a network into smaller broadcast domains. These smaller domains
forward packets only to devices that are part of that VLAN domain. This reduces traffic and
increases network security.
A Local Area Network (LAN) is a group of connected computers and devices that are
arranged into network broadcast domains. A LAN broadcast domain includes all the
computers that receive a packet broadcast from any computer in that broadcast domain. A
switch will automatically forward the packets to all of its ports; in contrast, routers do not
automatically forward network broadcast packets. This means routers separate broadcast
domains. If a network has only switches and no routers, that network is considered one
broadcast domain, no matter how large or small it is. Smaller broadcast domains are more
efficient because fewer devices receive unnecessary packets. They are more secure as
well because a hacker reading traffic on the network will have access to only a small
portion of the network instead of the entire network’s traffic.
Virtual LANs (VLANs) use ID tags to logically separate a LAN into smaller broadcast
domains. Each VLAN is its own broadcast domain. Smaller broadcast domains reduce
traffic and increase network security. The IEEE 802.1Q standard defines VLANs. All
layer-2 and layer-3 devices along a route must be 802.1Q-compliant to support VLANs
along that route. For more information, see “VLAN switching and routing” on page 1234
and “VLAN layer-3 routing” on page 1236.
VLANs reduce the size of the broadcast domains by only forwarding packets to interfaces
that are part of that VLAN or part of a VLAN trunk link. Trunk links form switch-to-switch or
switch-to-router connections, and forward traffic for all VLANs. This enables a VLAN to
include devices that are part of the same broadcast domain, but physically distant from
each other.
VLAN ID tags consist of a 4-byte frame extension that switches and routers apply to every
packet sent and received in the VLAN. Workstations and desktop computers, which are
commonly originators or destinations of network traffic, are not an active part of the VLAN
process—all the VLAN tagging and tag removal is done after the packet has left the
computer. For more information, see “VLAN ID rules” on page 1234.
Any FortiGate unit without VDOMs enabled can have a maximum of 255 interfaces in
transparent operating mode. The same is true for any single VDOM. In NAT/Route
operating mode, the number can range from 255 to 8192 interfaces per VDOM, depending
on the FortiGate model. These numbers include VLANs, other virtual interfaces, and
physical interfaces. To have more than 255 interfaces configured in transparent operating
mode, you need to configure multiple VDOMs that enable you to divide the total number of
interfaces over all the VDOMs.
One example of an application of VLANs is a company’s accounting department.
Accounting computers may be located at both main and branch offices. However,
accounting computers need to communicate with each other frequently and require
increased security. VLANs allow the accounting network traffic to be sent only to
accounting computers and to connect accounting computers in different locations as if
they were on the same physical subnet.

01-420-99686-20101026 481
VLAN ID rules Virtual LANs
Note: This guide uses the term “packet” to refer to both layer-2 frames and layer-3 packets.
VLAN ID rules
Layer-2 switches and layer-3 devices add VLAN ID tags to the traffic as it arrives and
remove them before they deliver the traffic to its final destination. Devices such as PCs
and servers on the network do not require any special configuration for VLANs. Twelve
bits of the 4-byte VLAN tag are reserved for the VLAN ID number. Valid VLAN ID numbers
are from 1 to 4094, while 0 is used for high priority frames, and 4095 is reserved.
On a layer-2 switch, you can have only one VLAN subinterface per physical interface,
unless that interface is configured as a trunk link. Trunk links can transport traffic for
multiple VLANs to other parts of the network.
On a FortiGate unit, you can add multiple VLANs to the same physical interface. However,
VLAN subinterfaces added to the same physical interface cannot have the same VLAN ID
or have IP addresses on the same subnet. You can add VLAN subinterfaces with the
same VLAN ID to different physical interfaces.
Creating VLAN subinterfaces with the same VLAN ID does not create any internal
connection between them. For example a VLAN ID of 300 on port1 and VLAN ID of 300 on
port2 are allowed, but they are not connected. Their relationship is the same as between
any two FortiGate network interfaces.
VLAN switching and routing

VLAN switching takes place on the OSI model layer-2, just like other network switching.
VLAN routing takes place on the OSI model layer-3. The difference between them is that
during VLAN switching, VLAN packets are simply forwarded to their destination. This is
different from VLAN routing where devices can open the VLAN packets and change their
VLAN ID tags to route the packets to a new destination.
VLAN layer-2 switching

Ethernet switches are layer-2 devices, and generally are 802.1Q compliant. Layer 2 refers
to the second layer of the seven layer Open Systems Interconnect (OSI) basic networking
model—the Data Link layer. FortiGate units act as layer-2 switches or bridges when they
are in transparent mode. The units simply tag and forward the VLAN traffic or receive and
remove the tags from the packets. A layer-2 device does not inspect incoming packets or
change their contents; it only adds or removes tags and routes the packet.
A VLAN can have any number of physical interfaces assigned to it. Multiple VLANs can be
assigned to the same physical interface. Typically two or more physical interfaces are
assigned to a VLAN, one for incoming and one for outgoing traffic. Multiple VLANs can be
configured on one FortiGate unit, including trunk links.
Layer-2 VLAN example

To better understand VLAN operation, this example shows what happens to a data frame
on a network that uses VLANs.
The network topology consists of two 8-port switches that are configured to support
VLANs on a network. Both switches are connected through port 8 using an 802.1Q trunk
link. Subnet 1 is connected to switch A, and subnet 2 is connected to switch B. The ports
on the switches are configured as follows.

482 01-420-99686-20101026
Virtual LANs VLAN switching and routing
Table 50: How ports and VLANs are used on Switch A and B
Switch Ports VLAN

A 1-4 100
A 5-7 200
A&B 8 Trunk link
B 4-5 100
B 6 200
In this example, switch A is connected to the Branch Office and switch B to the Main
Office.
1 A computer on port 1 of switch A sends a data frame over the network.
0
N 10
LA e 00
V
O ffic N2
ch A
n VL
Bra
7
5-
0
P
10
ts
or
or
ts
P N
LA
1-
me
4
V
Fra
P
S
or .1Q
w
t8
80
itc
5
h
A
4,
ts
P
tr
or
or
un
P
t8
k
lin
k
0
20
S
N
w
LA
itc
h
V
B
fice
Of
in
Ma
2 Switch A tags the data frame with a VLAN 100 ID tag upon arrival because port 1 is
part of VLAN 100.
3 Switch A forwards the tagged data frame to the other VLAN 100 ports—ports 2 through
4. Switch A also forwards the data frame to the 802.1Q trunk link (port 8) so other parts
of the network that may contain VLAN 100 groups will receive VLAN 100 traffic.

01-420-99686-20101026 483
VLAN switching and routing Virtual LANs
This data frame is not forwarded to the other ports on switch A because they are not part
of VLAN 100. This increases security and decreases network traffic.
0
N 10 20
0
LA LA
N
V fice V
h Of
c
B ran
7
5-
0
P
10
ts
or
or
ts
N
P
LA
1-
me
4
V
Fra
P 2.1
S
or Q
w
t8
80
itc
5
h
A
4,
ts
P ink
tr
or
or
un
P
t8
k
l
00
N2
S
w
A
itc
VL
h
B
fice
Of
M ain
4 Switch B receives the data frame over the trunk link (port 8).
5 Because there are VLAN 100 ports on switch B (ports 4 and 5), the data frame is
forwarded to those ports. As with switch A, the data frame is not delivered to VLAN
200.
If there were no VLAN 100 ports on switch B, the switch would not forward the data frame
and it would stop there.
00 00
A N1 2
VL AN
fice VL
h Of
anc
Br

7
5-
0
P
10
ts
or
or
ts
N
P
A
1-
me VL
4
Fra
P
S
or .1Q
w
t8
80
itc
5
h
A
4,
ts
P
tr
or
or
un
P
t8
k
lin
k
0
20
S
N
w
LA
itc
h
V
B
e
fic
Of
in
Ma

484 01-420-99686-20101026
6 The switch removes the VLAN 100 ID tag before it forwards the data frame to an end
destination.
The sending and receiving computers are not aware of any VLAN tagging on the data
frames that are being transmitted. When any computer receives that data frame, it
appears as a normal data frame.
VLAN layer-3 routing

Routers are layer-3 devices. Layer 3 refers to the third layer of the OSI networking
model—the Network layer. FortiGate units in NAT/Route mode act as layer-3 devices. As
with layer 2, FortiGate units acting as layer-3 devices are 802.1Q-compliant.
The main difference between layer-2 and layer-3 devices is how they process VLAN tags.
Layer-2 switches just add, read and remove the tags. They do not alter the tags or do any
other high-level actions. Layer-3 routers not only add, read and remove tags but also
analyze the data frame and its contents. This analysis allows layer-3 routers to change the
VLAN tag if it is appropriate and send the data frame out on a different VLAN.
In a layer-3 environment, the 802.1Q-compliant router receives the data frame and
assigns a VLAN ID. The router then forwards the data frame to other members of the
same VLAN broadcast domain. The broadcast domain can include local ports, layer-2
devices and layer-3 devices such as routers and firewalls. When a layer-3 device receives
the data frame, the device removes the VLAN tag and examines its contents to decide
what to do with the data frame. The layer-3 device considers:
• source and destination addresses
• protocol
• port number.
The data frame may be forwarded to another VLAN, sent to a regular non-VLAN-tagged
network or just forwarded to the same VLAN as a layer-2 switch would do. Or, the data
frame may be discarded if the proper firewall policy has been configured to do so.
Layer-3 VLAN example

In this example, switch A is connected to the Branch Office subnet, the same as subnet 1
in the layer-2 example. In the Main Office subnet, VLAN 300 is on port 5 of switch B. The
FortiGate unit is connected to switch B on port 1 and the trunk link connects the FortiGate
unit’s port 3 to switch A. The other ports on switch B are unassigned.

01-420-99686-20101026 485
This example explains how traffic can change VLANs—originating on VLAN 100 and
arriving at a destination on VLAN 300. Layer-2 switches alone cannot accomplish this, but
a layer-3 router can.
1 The VLAN 100 computer at the Branch Office sends the data frame to switch A, where
the VLAN 100 tag is added.
00 00
A N1 N2
VL fice VL
A
h Of
nc
Bra
7
5-
P
ts
or
or
ts
P
1-
me
4
Fra
P
S
or .1Q
w
t8
80
itc
2
h
A
tr
un
k
lin
P
k
or
t3
rt 1
Po 300
t1
or
N fice
P
A
VL Of
in
Ma
P
S
or
w
t5
itc
h
B
0
N 30
V LA

486 01-420-99686-20101026
2 Switch A forwards the tagged data frame to the FortiGate unit over the 802.1Q trunk
link, and to the VLAN 100 interfaces on Switch A.
Up to this point everything is the same as in the layer-2 example.
0
10 00
LA
N
e A N2
V ffic VL
hO
nc
Bra
7
5-
P
ts
or
or
ts
P
1-
4
P 2.1
S
or Q
w
t8
80
me
itc
h
Fra
tr
un
k
li n
P
k
or
t3
rt 1
Po 3 0 0
t1
or
AN fice
P
VL Of
Main
P
S
or
w
t5
itc
h
B
0
30
AN
VL
3 The FortiGate unit removes the VLAN 100 tag, and inspects the content of the data
frame. The FortiGate unit uses the content to select the correct firewall policy and
routing options.

01-420-99686-20101026 487
4 The FortiGate unit’s firewall policy allows the data frame to go to VLAN 300 in this
example. The data frame will be sent to all VLAN 300 interfaces, but in the example
there is only one—port 1 on the FortiGate unit. Before the data frame leaves, the
FortiGate unit adds the VLAN ID 300 tag to the data frame.
This is the step that layer 2 cannot do. Only layer 3 can retag a data frame as a
different VLAN.
00 00
A N1 N2
VL ffic
e
VL
A
O
n ch
Bra
7
5-
P
ts
or
or
ts
P
1-
4
P 2.1
S
or Q
w
t8
80
itc
h
A
tr
un
k
lin
P
k
or
Fra
t3
me
rt 1
Po 3 0 0
t1
or
AN fice
P
VL Of
Main
P
S
or
w
t5
itc
h
B
0
30
AN
VL

488 01-420-99686-20101026
Virtual LANs VLANs in NAT/Route mode
5 Switch B receives the data frame, and removes the VLAN ID 300 tag, because this is
the last hop, and forwards the data frame to the computer on port 5.
0
10 00
AN N2
VL fice VL
A
h Of
nc
Bra
7
5-
P
ts
or
or
ts
P
1-
4
P 2.1
S
or Q
w
t8
80
me
itc
h
Fra
tr
un
k
li n
P
k
or
t3
rt 1
Po 300
t1
or
N e
fic
P
V LA Of
in
Ma
P
S
or
w
t5
itc
h
B me
Fra
00
A N3
VL
In this example, a data frame arrived at the FortiGate unit tagged as VLAN 100. After
checking its content, the FortiGate unit retagged the data frame for VLAN 300. It is this
change from VLAN 100 to VLAN 300 that requires a layer-3 routing device, in this case
the FortiGate unit. Layer-2 switches cannot perform this change.
VLANs in NAT/Route mode

In NAT/Route mode the FortiGate unit functions as a layer-3 device. In this mode, the
FortiGate unit controls the flow of packets between VLANs, but can also remove VLAN
tags from incoming VLAN packets. The FortiGate unit can also forward untagged packets
to other networks, such as the Internet.
In NAT/Route mode, the FortiGate unit supports VLAN trunk links with IEEE
802.1Q-compliant switches, or routers. The trunk link transports VLAN-tagged packets
between physical subnets or networks. When you add VLAN sub-interfaces to the
FortiGate unit physical interfaces, the VLANs have IDs that match the VLAN IDs of
packets on the trunk link. The FortiGate unit directs packets with VLAN IDs to
sub-interfaces with matching IDs.
You can define VLAN sub-interfaces on all FortiGate physical interfaces. However, if
multiple virtual domains are configured on the FortiGate unit, you will have access to only
the physical interfaces on your virtual domain. The FortiGate unit can tag packets leaving
on a VLAN subinterface. It can also remove VLAN tags from incoming packets and add a
different VLAN tag to outgoing packets.

01-420-99686-20101026 489
VLANs in NAT/Route mode Virtual LANs
Normally in VLAN configurations, the FortiGate unit's internal interface is connected to a

VLAN trunk, and the external interface connects to an Internet router that is not configured
for VLANs. In this configuration the FortiGate unit can apply different policies for traffic on
each VLAN interface connected to the internal interface, which results in less network
traffic and better security.
Adding VLAN subinterfaces

A VLAN subinterface, also called a VLAN, is a virtual interface on a physical interface. The
subinterface allows routing of VLAN tagged packets using that physical interface, but it is
separate from any other traffic on the physical interface.
Adding a VLAN subinterface includes configuring:
• Physical interface
• IP address and netmask
• VLAN ID
• VDOM
Physical interface
The term VLAN subinterface correctly implies the VLAN interface is not a complete
interface by itself. You add a VLAN subinterface to the physical interface that receives
VLAN-tagged packets. The physical interface can belong to a different VDOM than the
VLAN, but it must be connected to a network router that is configured for this VLAN.
Without that router, the VLAN will not be connected to the network, and VLAN traffic will
not be able to access this interface. The traffic on the VLAN is separate from any other
traffic on the physical interface.
When you are working with interfaces on your FortiGate unit, use the Column Settings on
the Interface display to make sure the information you need is displayed. When working
with VLANs, it is useful to position the VLAN ID column close to the IP address. If you are
working with VDOMs, including the Virtual Domain column as well will help you
troubleshoot problems more quickly.
To view the Interface display, go to System > Network > Interface.
IP address and netmask

FortiGate unit interfaces cannot have overlapping IP addresses. The IP addresses of all
interfaces must be on different subnets. This rule applies to both physical interfaces and to
virtual interfaces such as VLAN subinterfaces. Each VLAN subinterface must be
configured with its own IP address and netmask pair. This rule helps prevent a broadcast
storm or other similar network problems.
Note: If you are unable to change your existing configurations to prevent IP overlap, enter
the CLI command config system global and set ip-overlap enable to allow IP
address overlap. If you enter this command, multiple VLAN interfaces can have an IP
address that is part of a subnet used by another interface. This command is recommended
for advanced users only.
VLAN ID
The VLAN ID is part of the VLAN tag added to the packets by VLAN switches and routers.
The VLAN ID is a number between 1 and 4094 that allow groups of IP addresses with the
same VLAN ID to be associated together. VLAN ID 0 is used only for high priority frames,
and 4095 is reserved.

490 01-420-99686-20101026
Virtual LANs VLANs in NAT/Route mode
All devices along a route must support the VLAN ID of the traffic along that route.
Otherwise, the traffic will be discarded before reaching its destination. For example, if your
computer is part of VLAN_100 and a co-worker on a different floor of your building is also
on the same VLAN_100, you can communicate with each other over VLAN_100, only if all
the switches and routers support VLANs and are configured to pass along VLAN_100
traffic properly. Otherwise, any traffic you send your co-worker will be blocked or not
delivered.
VDOM
If VDOMs are enabled, each VLAN subinterface must belong to a VDOM. This rule also
applies for physical interfaces.
Note: Interface-related CLI commands require a VDOM to be specified, regardless of

whether the FortiGate unit has VDOMs enabled.
VLAN subinterfaces on separate VDOMs cannot communicate directly with each other. In
this situation, the VLAN traffic must exit the FortiGate unit and re-enter the unit again,
passing through firewalls in both directions. This situation is the same for physical
interfaces.
A VLAN subinterface can belong to a different VDOM than the physical interface it is part
of. This is because the traffic on the VLAN is handled separately from the other traffic on
that interface. This is one of the main strengths of VLANs.
The following procedure will add a VLAN subinterface called VLAN_100 to the FortiGate
internal interface with a VLAN ID of 100. It will have an IP address and netmask of
172.100.1.1/255.255.255.0, and allow HTTPS, PING, and TELNET administrative
access. Note that in the CLI, you must enter “set type vlan” before setting the vlanid,
and that the allowaccess protocols are lower case.
To add a VLAN subinterface in NAT/Route mode - web-based manager

1 If Current VDOM appears at the bottom left of the screen, select Global from the list of
VDOMs.
3 Select Create New to add a VLAN subinterface.
VLAN Name VLAN_100

Type VLAN
Interface internal
VLAN ID 100
Addressing Mode Manual
IP/Netmask 172.100.1.1/255.255.255.0
Administrative Access HTTPS, PING, TELNET
5 Select OK.
To view the new VLAN subinterface, select the expand arrow next to the parent physical
interface (the internal interface). This will expand the display to show all VLAN
subinterfaces on this physical interface. If there is no expand arrow displayed, there are no
subinterfaces configured on that physical interface.

01-420-99686-20101026 491
VLANs in NAT/Route mode Virtual LANs
For each VLAN, the list displays the name of the VLAN, and, depending on column
settings, its IP address, the Administrative access you selected for it, the VLAN ID
number, and which VDOM it belongs to if VDOMs are enabled.
To add a VLAN subinterface in NAT/Route mode - CLI

edit VLAN_100
set type vlan
set vlanid 100
set ip 172.100.1.1 255.255.255.0
set allowaccess https ping telnet
end
Configuring firewall policies and routing

Once you have created a VLAN subinterface on the FortiGate unit, you need to configure
firewall policies and routing for that VLAN. Without these, the FortiGate unit will not pass
VLAN traffic to its intended destination. Firewall policies direct traffic through the FortiGate
unit between interfaces. Routing directs traffic across the network.
Configuring firewall policies

Firewall policies permit communication between the FortiGate unit’s network interfaces
based on source and destination IP addresses. Interfaces that communicate with the
VLAN interface need firewall policies to permit traffic to pass between them and the VLAN
interface.
Each VLAN needs a firewall policy for each of the following connections the VLAN will be
using:
• from this VLAN to an external network
• from an external network to this VLAN
• from this VLAN to another VLAN in the same virtual domain on the FortiGate unit
• from another VLAN to this VLAN in the same virtual domain on the FortiGate unit.
The packets on each VLAN are subject to antivirus scans and other UTM measures as
they pass through the FortiGate unit.
Configuring routing
As a minimum, you need to configure a default static route to a gateway with access to an
external network for outbound packets. In more complex cases, you will have to configure
different static or dynamic routes based on packet source and destination addresses.
As with firewalls, you need to configure routes for VLAN traffic. VLANs need routing and a
gateway configured to send and receive packets outside their local subnet just as physical
interfaces do. The type of routing you configure, static or dynamic, will depend on the
routing used by the subnet and interfaces you are connecting to. Dynamic routing can be
routing information protocol (RIP), border gateway protocol (BGP), open shortest path first
(OSPF), or multicast.
If you enable SSH, PING, TELNET, HTTPS and HTTP on the VLAN, you can use those
protocols to troubleshoot your routing and test that it is properly configured. Enabling
logging on the interfaces and using CLI diagnose commands such as diagnose sniff
packet <interface_name> can also help locate any possible configuration or
hardware issues.

492 01-420-99686-20101026
Virtual LANs Example VLAN configuration in NAT mode
Example VLAN configuration in NAT mode

In this example two different internal VLAN networks share one interface on the FortiGate
unit, and share the connection to the Internet. This example shows that two networks can
have separate traffic streams while sharing a single interface. This configuration could
apply to two departments in a single company, or to different companies.
There are two different internal network VLANs in this example. VLAN_100 is on the
10.1.1.0/255.255.255.0 subnet, and VLAN_200 is on the 10.1.2.0/255.255.255.0 subnet.
These VLANs are connected to the VLAN switch, such as a Cisco 2950 Catalyst switch.
The FortiGate internal interface connects to the VLAN switch through an 802.1Q trunk.
The internal interface has an IP address of 192.168.110.126 and is configured with two
VLAN subinterfaces (VLAN_100 and VLAN_200). The external interface has an IP
address of 172.16.21.2 and connects to the Internet. The external interface has no VLAN
subinterfaces on it.
Figure 46: FortiGate unit with VLANs in NAT mode
Un
t
pa agge
ck d
ets
Ex
17 tern
2.1 al
6.2 0
1.2 20
A N
VL
802
19 Inte
2.1 rna
.1Q
68 l trun
.11
0.1
k
26 Fa
rk
/9
o
0/2 0
.0 w
Fa
.2 et
4
.1 N
10 00
2
N
LA
V
h
itc
00 0/3
w
N1
S
Fa
N
A
VL
LA
V
o rk
.0 w
.1 et
.1 N
10 00
1
N
LA
V
When the VLAN switch receives packets from VLAN_100 and VLAN_200, it applies VLAN
ID tags and forwards the packets of each VLAN both to local ports and to the FortiGate
unit across the trunk link. The FortiGate unit has policies that allow traffic to flow between
the VLANs, and from the VLANs to the external network.
This section describes how to configure a FortiGate-800 unit and a Cisco Catalyst 2950
switch for this example network topology. The Cisco configuration commands used in this
section are IOS commands.
It is assumed that both the FortiGate-800 and the Cisco 2950 switch are installed and
connected and that basic configuration has been completed. On the switch, you will need
to be able to access the CLI to enter commands. Refer to the manual for your FortiGate
model as well as the manual for the switch you select for more information.
It is also assumed that no VDOMs are enabled.

01-420-99686-20101026 493
Example VLAN configuration in NAT mode Virtual LANs
General configuration steps

The following steps provide an overview of configuring and testing the hardware used in
this example. For best results in this configuration, follow the procedures in the order
given. Also, note that if you perform any additional actions between procedures, your
configuration may have different results.
1 Configure the FortiGate unit
• Configure the external interface
• Add two VLAN subinterfaces to the internal network interface
• Add firewall addresses and address ranges for the internal and external networks
• Add firewall policies to allow:
• the VLAN networks to access each other
• the VLAN networks to access the external network.
2 Configure the VLAN switch
Configure the FortiGate unit

Configuring the FortiGate unit includes:
• Configuring the external interface
• Adding VLAN subinterfaces
• Adding the firewall addresses
• Adding the firewall policies
Configure the external interface

The FortiGate unit’s external interface will provide access to the Internet for all internal
networks, including the two VLANs.
To configure the external interface - web-based manager

2 Select Edit for the external interface.
3 Enter the following information and select OK:

IP/Netmask 172.16.21.2/255.255.255.0
To configure the external interface - CLI

edit external
set mode static
set ip 172.16.21.2 255.255.255.0
end
Add VLAN subinterfaces

This step creates the VLANs on the FortiGate unit internal physical interface. The IP
address of the internal interface does not matter to us, as long as it does not overlap with
the subnets of the VLAN subinterfaces we are configuring on it.

494 01-420-99686-20101026
The rest of this example shows how to configure the VLAN behavior on the FortiGate unit,
configure the switches to direct VLAN traffic the same as the FortiGate unit, and test that
the configuration is correct.
Adding VLAN subinterfaces can be completed through the web-based manager, or the
CLI.
To add VLAN subinterfaces - web-based manager

Name VLAN_100
Interface internal
VLAN ID 100
IP/Netmask 10.1.1.1/255.255.255.0
Administrative HTTPS, PING, TELNET
Access

Name VLAN_200
Interface internal
VLAN ID 200
IP/Netmask 10.1.2.1/255.255.255.0
Administrative HTTPS, PING, TELNET
Access
To add VLAN subinterfaces - CLI

edit VLAN_100
set vdom root
set type vlan
set vlanid 100
set mode static
set ip 10.1.1.1 255.255.255.0
next
edit VLAN_200
set vdom root
set type vlan
set vlanid 200
set mode static
set ip 10.1.2.1 255.255.255.0
end

01-420-99686-20101026 495
Add the firewall addresses

You need to define the addresses of the VLAN subnets for use in firewall policies. The
FortiGate unit provides one default address, “all”, that you can use when a firewall policy
applies to all addresses as a source or destination of a packet. However, using “all” is less
secure and should be avoided when possible.
In this example, the “_Net” part of the address name indicates a range of addresses
instead of a unique address. When choosing firewall address names, use informative and
unique names.
To add the firewall addresses - web-based manager

Address Name VLAN_100_Net

Subnet / IP Range 10.1.1.0/255.255.255.0

Address Name VLAN_200_Net

Subnet / IP Range 10.1.2.0/255.255.255.0
To add the firewall addresses - CLI

edit VLAN_100_Net
set type ipmask
set subnet 10.1.1.0 255.255.255.0
next
edit VLAN_200_Net
set type ipmask
set subnet 10.1.2.0 255.255.255.0
end
Add the firewall policies

Once you have assigned addresses to the VLANs, you need to configure firewall policies
for them to allow valid packets to pass from one VLAN to another and to the Internet.
Note: You can customize the Firewall Policy display by including some or all columns, and
customize the column order onscreen. Due to this feature, firewall policy screenshots may
not appear the same as on your screen.
If you do not want to allow all services on a VLAN, you can create a firewall policy for each
service you want to allow. This example allows all services.
To add the firewall policies - web-based manager


496 01-420-99686-20101026
Source Interface/Zone VLAN_100

Source Address VLAN_100_Net
Destination Interface/Zone VLAN_200
Destination Address VLAN_200_Net
Schedule Always
Service ANY
Action ACCEPT
Enable NAT Enable


Destination Interface/Zone VLAN_100
Destination Address VLAN_100_Net
Schedule Always
Service ANY
Action ACCEPT
Enable NAT Enable


Destination Interface/Zone external
Destination Address all
Schedule Always
Service ANY
Action ACCEPT
Enable NAT Enable


Destination Interface/Zone external
Schedule Always
Service ANY
Action ACCEPT
Enable NAT Enable

01-420-99686-20101026 497
To add the firewall policies - CLI

edit 1
set srcintf VLAN_100
set srcaddr VLAN_100_Net
set dstintf VLAN_200
set dstaddr VLAN_200_Net
set schedule always
set service ANY
set action accept
set nat enable
set status enable
next
edit 2
set dstintf VLAN_100
set dstaddr VLAN_100_Net
set schedule always
set service ANY
set action accept
set nat enable
set status enable
next
edit 3
set dstaddr all
set schedule always
set service ANY
set action accept
set nat enable
set status enable
next
edit 4
set dstaddr all
set schedule always
set service ANY
set action accept
set nat enable
set status enable
end
Configure the VLAN switch

On the Cisco Catalyst 2950 Catalyst VLAN switch, you need to define VLANs 100 and 200
in the VLAN database, and then add a configuration file to define the VLAN subinterfaces
and the 802.1Q trunk interface.

498 01-420-99686-20101026
One method to configure a Cisco switch is to connect over a serial connection to the
console port on the switch, and enter the commands at the CLI. Another method is to
designate one interface on the switch as the management interface and use a web
browser to connect to the switch’s graphical interface. For details on connecting and
configuring your Cisco switch, refer to the installation and configuration manuals for the
switch.
The switch used in this example is a Cisco Catalyst 2950 switch. The commands used are
IOS commands. Refer to the switch manual for help with these commands.
To configure the VLAN subinterfaces and the trunk interfaces

Add this file to the Cisco switch:
!
interface FastEthernet0/3
!
!
switchport trunk encapsulation dot1q
switchport mode trunk
!
The switch has the following configuration:
Port 0/3 VLAN ID 100

Port 0/24 802.1Q trunk
Note: To complete the setup, configure devices on VLAN_100 and VLAN_200 with default
gateways. The default gateway for VLAN_100 is the FortiGate VLAN_100 subinterface.
The default gateway for VLAN_200 is the FortiGate VLAN_200 subinterface.
Test the configuration

Use diagnostic commands, such as tracert, to test traffic routed through the FortiGate
unit and the Cisco switch.
Testing traffic from VLAN_100 to VLAN_200

In this example, a route is traced between the two internal networks. The route target is a
host on VLAN_200.
Access a command prompt on a Windows computer on the VLAN_100 network, and enter
the following command:
C:\>tracert 10.1.2.2
Tracing route to 10.1.2.2 over a maximum of 30 hops:
1 <10 ms <10 ms <10 ms 10.1.1.1
2 <10 ms <10 ms <10 ms 10.1.2.2
Trace complete.
Testing traffic from VLAN_200 to the external network

In this example, a route is traced from an internal network to the external network. The
route target is the external network interface of the FortiGate-800 unit.
From VLAN_200, access a command prompt and enter this command:

01-420-99686-20101026 499
VLANs in transparent mode Virtual LANs
C:\>tracert 172.16.21.2
1 <10 ms <10 ms <10 ms 10.1.2.1
2 <10 ms <10 ms <10 ms 172.16.21.2
Trace complete.
VLANs in transparent mode

In transparent mode, the FortiGate unit behaves like a layer-2 bridge but can still provide
services such as antivirus scanning, web filtering, spam filtering and intrusion protection to
traffic. There are some limitations in transparent mode in that you cannot use SSL VPN,
PPTP/L2TP VPN, DHCP server, or easily perform NAT on traffic. The limits in transparent
mode apply to IEEE 802.1Q VLAN trunks passing through the unit.
VLANs and transparent mode

You can insert the FortiGate unit operating in transparent mode into the VLAN trunk
without making changes to your network. In a typical configuration, the FortiGate unit
internal interface accepts VLAN packets on a VLAN trunk from a VLAN switch or router
connected to internal network VLANs. The FortiGate external interface forwards
VLAN-tagged packets through another VLAN trunk to an external VLAN switch or router
and on to external networks such as the Internet. You can configure the unit to apply
different policies for traffic on each VLAN in the trunk.
To pass VLAN traffic through the FortiGate unit, you add two VLAN subinterfaces with the
same VLAN ID, one to the internal interface and the other to the external interface. You
then create a firewall policy to permit packets to flow from the internal VLAN interface to
the external VLAN interface. If required, you create another firewall policy to permit
packets to flow from the external VLAN interface to the internal VLAN interface. Typically
in transparent mode, you do not permit packets to move between different VLANs.
Network protection features, such as spam filtering, web filtering and anti-virus scanning,
are applied through the UTM profiles specified in each firewall policy, enabling very
detailed control over traffic.
When the FortiGate unit receives a VLAN-tagged packet at a physical interface, it directs
the packet to the VLAN subinterface with the matching VLAN ID. The VLAN tag is
removed from the packet, and the FortiGate unit then applies firewall policies using the
same method it uses for non-VLAN packets. If the packet exits the FortiGate unit through
a VLAN subinterface, the VLAN ID for that subinterface is added to the packet and the
packet is sent to the corresponding physical interface. For a configuration example, see
“Example of VLANs in Transparent mode” on page 1252.
There are two essential steps to configure your FortiGate unit to work with VLANs in
transparent mode:
• Creating firewall policies.
You can also configure the protection profiles that manage antivirus scanning, web filtering
and spam filtering. For more information on UTM profiles, see “UTM Guide” on page 735.

The VLAN ID of each VLAN subinterface must match the VLAN ID added by the
IEEE 802.1Q-compliant router or switch. The VLAN ID can be any number between 1 and
4094, with 0 being used only for high priority frames and 4095 being reserved. You add
VLAN subinterfaces to the physical interface that receives VLAN-tagged packets.

500 01-420-99686-20101026
Virtual LANs VLANs in transparent mode
For this example, we are creating a VLAN called internal_v225 on the internal interface,
with a VLAN ID of 225. Administrative access is enabled for HTTPS and SSH. VDOMs are
not enabled.
To add VLAN subinterfaces in transparent mode - web-based manager

3 Enter the following information and select OK.
Name internal_v225
Type VLAN
Interface internal
VLAN ID 225
Ping Server not enabled
Administrative Enable HTTPS, and SSH. These are very secure
Access access methods.
Description VLAN 225 on internal interface
The FortiGate unit adds the new subinterface to the interface that you selected.
Repeat steps 2 and 3 to add additional VLANs. You will need to change the VLAN ID,
Name, and possibly Interface when adding additional VLANs.
To add VLAN subinterfaces in transparent mode - CLI

edit internal_v225
set vlanid 225
set allowaccess HTTPS SSH
set description “VLAN 225 on internal interface”
set vdom root
end
Create firewall policies

In transparent mode, the FortiGate unit performs antivirus and antispam scanning on each
VLAN’s packets as they pass through the unit. You need firewall policies to permit packets
to pass from the VLAN interface where they enter the unit to the VLAN interface where
they exit the unit. If there are no firewall policies configured, no packets will be allowed to
pass from one interface to another.
To add firewall policies for VLAN subinterfaces - web based manager

2 Select Create New to add firewall addresses that match the source and destination IP
addresses of VLAN packets.
5 From the Source Interface/Zone list, select the VLAN interface where packets enter the
unit.
6 From the Destination Interface/Zone list, select the VLAN interface where packets exit
the unit.

01-420-99686-20101026 501
7 Select the Source and Destination Address names that you added in step 2.
8 Select Protection Profile, and select the profile from the list.
9 Configure other settings as required.
10 Select OK.
To add firewall policies for VLAN subinterfaces - CLI

edit incoming_VLAN_address
set associated-interface <incoming_VLAN_interface>
set type ipmask
set subnet <IPv4_address_mask)
next
edit outgoing_VLAN_address
set associated-interface <outgoing_VLAN_interface>
set type ipmask
set subnet <IPv4_address_mask>
next
end
edit <unused_policy_number>
set srcintf <incoming_VLAN_interface>
set srcaddr incoming_VLAN_address
set destintf <outgoing_VLAN_interface>
set destaddr outgoing_VLAN_address
set service <protocol_to_allow_on VLAN>
set action ACCEPT
set profile <selected_profile>
next
end
end
Example of VLANs in transparent mode

In this example, the FortiGate unit is operating in transparent mode and is configured with
two VLANs: one with an ID of 100 and the other with ID 200. The internal and external
physical interfaces each have two VLAN subinterfaces, one for VLAN_100 and one for
VLAN_200.
The IP range for the internal VLAN_100 network is 10.100.0.0/255.255.0.0, and for the
internal VLAN_200 network is 10.200.0.0/255.255.0.0.
The internal networks are connected to a Cisco 2950 VLAN switch, which combines traffic
from the two VLANs onto one physical interface—the FortiGate unit internal interface. The
VLAN traffic leaves the FortiGate unit on the external network interface, goes on to the
VLAN switch, and on to the Internet. When the FortiGate units receives a tagged packet, it
directs it from the incoming VLAN subinterface to the outgoing VLAN subinterface for that
VLAN.
This section describes how to configure a FortiGate-800 unit, Cisco switch, and Cisco
router in the network topology shown in Figure 180.

502 01-420-99686-20101026
Figure 47: VLAN transparent network topology
10
.1
10 00.0
.20 .1
0.0
.1
V
LA
Ex
N
ter 0
ro
na 20
ut
l
er
AN
VL
802
.1
VLA Q trun
Int
e rn
al N1 k
,2
Fa
k
/9
r
.0 o
0/2 0
.0 t w
Fa
00 Ne
4
.2 0
10 20
N
LA
V
h
itc
0
10 0/3
w
S
AN Fa
N
VL
LA
V
r k
.0 o
.0 tw
00 Ne
.1 0
10 10
N
LA
V

The following steps summarize the configuration for this example. For best results, follow
the procedures in the order given. Also, note that if you perform any additional actions
between procedures, your configuration may have different results.
1 Configure the FortiGate unit which includes
• Adding the firewall policies
2 Configure the Cisco switch and router

The FortiGate unit must be configured with the VLAN subinterfaces and the proper firewall
policies to enable traffic to flow through the FortiGate unit.

For each VLAN, you need to create a VLAN subinterface on the internal interface and
another one on the external interface, both with the same VLAN ID.
To add VLAN subinterfaces - web-based manager


01-420-99686-20101026 503
Name VLAN_100_int
Interface internal
VLAN ID 100

Name VLAN_100_ext
Interface external
VLAN ID 100

Name VLAN_200_int
Interface internal
VLAN ID 200

Name VLAN_200_ext
Interface external
VLAN ID 200
To add VLAN subinterfaces - CLI

edit VLAN_100_int
set status down
set type vlan
set vlanid 100
next
edit VLAN_100_ext
set status down
set type vlan
set vlanid 100
next
edit VLAN_200_int
set status down
set type vlan
set vlanid 200
next
edit VLAN_200_ext
set status down
set type vlan
set vlanid 200

504 01-420-99686-20101026
end
Add the firewall policies

Firewall policies allow packets to travel between the VLAN_100_int interface and the
VLAN_100_ext interface. Two policies are required; one for each direction of traffic. The
same is required between the VLAN_200_int interface and the VLAN_200_ext interface,
for a total of four required firewall policies.
To add the firewall policies - web-based manager

Source Interface/Zone VLAN_100_int

Source Address all
Destination Interface/Zone VLAN_100_ext
Schedule Always
Service ANY
Action ACCEPT

Source Interface/Zone VLAN_100_ext

Source Address all
Destination Interface/Zone VLAN_100_int
Schedule Always
Service ANY
Action ACCEPT

Source Interface/Zone VLAN_200_int

Source Address all
Destination Interface/Zone VLAN_200_ext
Schedule Always
Service ANY
Action ACCEPT
Enable NAT enable


01-420-99686-20101026 505
Source Interface/Zone VLAN_200_ext

Source Address all
Destination Interface/Zone VLAN_200_int
Schedule Always
Service ANY
Action ACCEPT

edit 1
set srcintf VLAN_100_int
set srcaddr all
set dstintf VLAN_100_ext
set dstaddr all
set action accept
set schedule always
set service ANY
next
edit 2
set srcintf VLAN_100_ext
set srcaddr all
set dstintf VLAN_100_int
set dstaddr all
set action accept
set schedule always
set service ANY
next
edit 3
set srcintf VLAN_200_int
set srcaddr all
set dstintf VLAN_200_ext
set dstaddr all
set action accept
set schedule always
set service ANY
next
edit 4
set srcintf VLAN_200_ext
set srcaddr all
set dstintf VLAN_200_int
set dstaddr all
set action accept
set schedule always
set service ANY
end

506 01-420-99686-20101026
Configure the Cisco switch and router

This example includes configuration for the Cisco Catalyst 2900 ethernet switch, and for
the Cisco Multiservice 2620 ethernet router. If you have access to a different VLAN
enabled switch or VLAN router you can use them instead, however their configuration is
not included in this document.
Configure the Cisco switch

On the VLAN switch, you need to define VLAN_100 and VLAN_200 in the VLAN database
and then add a configuration file to define the VLAN subinterfaces and the 802.1Q trunk
interface.
Add this file to the Cisco switch:
!
!
switchport trunk encapsulation dot1q
switchport mode trunk
!
The switch has the following configuration:

Configure the Cisco router

You need to add a configuration file to the Cisco Multiservice 2620 ethernet router. The file
defines the VLAN subinterfaces and the 802.1Q trunk interface on the router. The 802.1Q
trunk is the physical interface on the router.
The IP address for each VLAN on the router is the gateway for that VLAN. For example,
all devices on the internal VLAN_100 network will have 10.100.0.1 as their gateway.
Add this file to the Cisco router:
!
!
interface FastEthernet0/0.1
encapsulation dot1Q 100
ip address 10.100.0.1 255.255.255.0
!
interface FastEthernet0/0.2
encapsulation dot1Q 200
ip address 10.200.0.1 255.255.255.0
!
The router has the following configuration:
Port 0/0.1 VLAN ID 100

Port 0/0.2 VLAN ID 200

01-420-99686-20101026 507
Troubleshooting VLAN issues Virtual LANs
Test the configuration

Use diagnostic network commands such as traceroute (tracert) and ping to test traffic
routed through the network.
Testing traffic from VLAN_100 to VLAN_200

In this example, a route is traced between the two internal networks. The route target is a
host on VLAN_200. The Windows traceroute command tracert is used.
From VLAN_100, access a Windows command prompt and enter this command:
C:\>tracert 10.1.2.2
1 <10 ms <10 ms <10 ms 10.1.1.1
2 <10 ms <10 ms <10 ms 10.1.2.2
Trace complete.
Troubleshooting VLAN issues

Several problems can occur with your VLANs. Since VLANs are interfaces with IP
addresses, they behave as interfaces and can have similar problems that you can
diagnose with tools such as ping, traceroute, packet sniffing, and diag debug. For more
information on these basic troubleshooting methods, see “Troubleshooting static routing”
on page 1216.
Asymmetric routing
You might discover unexpectedly that hosts on some networks are unable to reach certain
other networks. This occurs when request and response packets follow different paths. If
the FortiGate unit recognizes the response packets, but not the requests, it blocks the
packets as invalid. Also, if the FortiGate unit recognizes the same packets repeated on
multiple interfaces, it blocks the session as a potential attack.
This is asymmetric routing. By default, the FortiGate unit blocks packets or drops the
session when this happens. You can configure the FortiGate unit to permit asymmetric
routing by using the following CLI command:
config vdom
edit <vdom_name>
set asymroute enable
end
end
If VDOMs are enabled, this command is per VDOM. You must set it for each VDOM that
has the problem. If this solves your blocked traffic issue, you know that asymmetric routing
is the cause. But allowing asymmetric routing is not the best solution, because it reduces
the security of your network.
For a long-term solution, it is better to change your routing configuration or change how
your FortiGate unit connects to your network. The Asymmetric Routing and Other
FortiGate Layer-2 Installation Issues technical note provides detailed examples of
asymmetric routing situations and possible solutions.
Caution: If you enable asymmetric routing, antivirus and intrusion prevention systems will
not be effective. Your FortiGate unit will be unaware of connections and treat each packet
individually. It will become a stateless firewall.

508 01-420-99686-20101026
Virtual LANs Troubleshooting VLAN issues
Layer-2 and Arp traffic

By default, FortiGate units do not pass layer-2 traffic. If there are layer-2 protocols such as
IPX, PPTP or L2TP in use on your network, you need to configure your FortiGate unit
interfaces to pass these protocols without blocking. Another type of layer-2 traffic is ARP
traffic. For more information on ARP traffic, see “ARP traffic” on page 1259.
You can allow these layer-2 protocols using the CLI command:
config vdom
edit <vdom_name>
edit <name_str>
set l2forward enable
end
end
where <name_str> is the name of an interface.
If VDOMs are enabled, this command is per VDOM. You must set it for each VDOM that
has the problem. If you enable layer-2 traffic, you may experience a problem if packets are
allowed to repeatedly loop through the network. This repeated looping, very similar to a
broadcast storm, occurs when you have more than one layer-2 path to a destination.
Traffic may overflow and bring your network to a halt. You can break the loop by enabling
Spanning Tree Protocol (STP) on your network’s switches and routers. For more
information, see “STP forwarding” on page 1262.
ARP traffic
Address Resolution Protocol (ARP) packets are vital to communication on a network, and
ARP support is enabled on FortiGate unit interfaces by default. Normally you want ARP
packets to pass through the FortiGate unit, especially if it is sitting between a client and a
server or between a client and a router.
ARP traffic can cause problems, especially in transparent mode where ARP packets
arriving on one interface are sent to all other interfaces including VLAN subinterfaces.
Some layer-2 switches become unstable when they detect the same MAC address
originating on more than one switch interface or from more than one VLAN. This instability
can occur if the layer-2 switch does not maintain separate MAC address tables for each
VLAN. Unstable switches may reset and cause network traffic to slow down considerably.
Multiple VDOMs solution

By default, physical interfaces are in the root domain. If you do not configure any of your
VLANs in the root VDOM, it will not matter how many interfaces are in the root VDOM.
The multiple VDOMs solution is to configure multiple VDOMs on the FortiGate unit, one
for each VLAN. In this solution, you configure one inbound and one outbound VLAN
interface in each VDOM. ARP packets are not forwarded between VDOMs. This
configuration limits the VLANs in a VDOM and correspondingly reduces the administration
needed per VDOM.
As a result of this configuration, the switches do not receive multiple ARP packets with
duplicate MACs. Instead, the switches receive ARP packets with different VLAN IDs and
different MACs. Your switches are stable.

01-420-99686-20101026 509
However, you should not use the multiple VDOMs solution under any of the following
conditions:
• you have more VLANs than licensed VDOMs
• you do not have enough physical interfaces
Instead, use one of two possible solutions, depending on which operation mode you are
using:
• In NAT/Route mode, you can use the vlan forward CLI command.
• In transparent mode, you can use the forward-domain CLI command. But you still
need to be careful in some rare configurations.
Vlanforward solution
If you are using NAT/Route mode, the solution is to use the vlanforward CLI command
for the interface in question. By default, this command is enabled and will forward VLAN
traffic to all VLANs on this interface. When disabled, each VLAN on this physical interface
can send traffic only to the same VLAN—there is no ”cross-talk” between VLANs, and
ARP packets are forced to take one path along the network which prevents the multiple
paths problem.
In the following example, vlanforward is disabled on port1. All VLANs configured on
port1 will be separate and will not forward any traffic to each other.
edit port1
set vlanforward disable
end
Forward-domain solution
If you are using transparent mode, the solution is to use the forward-domain CLI
command. This command tags VLAN traffic as belonging to a particular collision group,
and only VLANs tagged as part of that collision group receive that traffic—it is like an
additional set of VLANs. By default, all interfaces and VLANs are part of forward-domain
collision group 0. The many benefits of this solution include reduced administration, the
need for fewer physical interfaces, and the availability of more flexible network solutions.
In the following example, forward-domain collision group 340 includes VLAN 340 traffic on
port1 and untagged traffic on port 2. Forward-domain collision group 341 includes VLAN
341 traffic on port 1 and untagged traffic on port 3. All other interfaces are part of
forward-domain collision group 0 by default. This configuration separates VLANs 340 and
341 from each other on port 1, and prevents the ARP packet problems from before.
Use these CLI commands:
edit port1
next
edit port2
set forward_domain 340
next
edit port3
next
edit port1-340
set interface port1
set vlanid 340

510 01-420-99686-20101026
Virtual LANs Troubleshooting VLAN issues
next
edit port1-341
set interface port1
set vlanid 341
end
You may experience connection issues with layer-2 traffic, such as ping, if your network
configuration has:
• packets going through the FortiGate unit in transparent mode more than once
• more than one forwarding domain (such as incoming on one forwarding domain and
outgoing on another)
• IPS and AV enabled.
Now IPS and AV is applied the first time packets go through the FortiGate unit, but not on
subsequent passes. Only applying IPS and AV to this first pass fixes the network layer-2
related connection issues.
NetBIOS
Computers running Microsoft Windows operating systems that are connected through a
network rely on a WINS server to resolve host names to IP addresses. The hosts
communicate with the WINS server by using the NetBIOS protocol.
To support this type of network, you need to enable the forwarding of NetBIOS requests to
a WINS server. The following example will forward NetBIOS requests on the internal
interface for the WINS server located at an IP address of 192.168.111.222.
edit internal
set netbios_forward enable
set wins-ip 192.168.111.222
end
These commands apply only in NAT/Route mode. If VDOMs are enabled, these
commands are per VDOM—you must set them for each VDOM that has the problem.
STP forwarding
The FortiGate unit does not participate in the Spanning Tree Protocol (STP). STP is an
IEEE 802.1 protocol that ensures there are no layer-2 loops on the network. Loops are
created when there is more than one route for traffic to take and that traffic is broadcast
back to the original switch. This loop floods the network with traffic, reducing available
bandwidth to nothing.
If you use your FortiGate unit in a network topology that relies on STP for network loop
protection, you need to make changes to your FortiGate configuration. Otherwise, STP
recognizes your FortiGate unit as a blocked link and forwards the data to another path. By
default, your FortiGate unit blocks STP as well as other non-IP protocol traffic.
Using the CLI, you can enable forwarding of STP and other layer-2 protocols through the
interface. In this example, layer-2 forwarding is enabled on the external interface:
edit external
set l2forward enable
set stpforward enable
end

01-420-99686-20101026 511
By substituting different commands for stpforward enable, you can also allow layer-2
protocols such as IPX, PPTP or L2TP to be used on the network. For more information,
see “Layer-2 and Arp traffic” on page 1259.
Too many VLAN interfaces

Any virtual domain can have a maximum of 255 interfaces in transparent mode. This
includes VLANs, other virtual interfaces, and physical interfaces. NAT/Route mode
supports from 255 to 8192 depending on the FortiGate model. This total number of
interfaces includes VLANs, other virtual interfaces, and physical interfaces.
Your FortiGate unit may allow you to configure more interfaces than this. However, if you
configure more than 255 interfaces, your system will become unstable and, over time, will
not work properly. As all interfaces are used, they will overflow the routing table that stores
the interface information, and connections will fail. When you try to add more interfaces,
an error message will state that the maximum limit has already been reached.
If you see this error message, chances are you already have too many VLANs on your
system and your routing has become unstable. To verify, delete a VLAN and try to add it
back. If you have too many, you will not be able to add it back on to the system. In this
case, you will need to remove enough interfaces (including VLANs) so that the total
number of interfaces drops to 255 or less. After doing this, you should also reboot your
FortiGate unit to clean up its memory and buffers, or you will continue to experience
unstable behavior.
To configure more than 255 interfaces on your FortiGate unit in transparent mode, you
have to configure multiple VDOMs, each with many VLANs. However, if you want to
create more than the default 10 VDOMs (or a maximum of 2550 interfaces), you must buy
a license for additional VDOMs. Only FortiGate models 3000 and higher support more
than 10 VDOMs.
With these extra licenses, you can configure up to 500 VDOMs, with each VDOM
containing up to 255 VLANs in transparent mode. This is a theoretical maximum of over
127 500 interfaces. However, system resources will quickly get used up before reaching
that theoretical maximum. To achieve the maximum number of VDOMs, you need to have
top-end hardware with the most resources possible.
In NAT/Route mode, if you have a top-end model, the maximum interfaces per VDOM can
be as high as 8192, enough for all the VLANs in your configuration.
Note: Your FortiGate unit has limited resources, such as CPU load and memory, that are
divided between all configured VDOMs. When running 250 or more VDOMs, you cannot
run Unified Threat Management (UTM) features such as proxies, web filtering, or
antivirus—your FortiGate unit can only provide basic firewall functionality.

512 01-420-99686-20101026
PPTP and L2TP
A virtual private network (VPN) is a way to use a public network, such as the Internet, as a
vehicle to provide remote offices or individual users with secure access to private
networks. FortiOS supports the Point-to-Point Tunneling Protocol (PPTP), which enables
interoperability between FortiGate units and Windows or Linux PPTP clients. Because
FortiGate units support industry standard PPTP VPN technologies, you can configure a
PPTP VPN between a FortiGate unit and most third-party PPTP VPN peers.
This section describes how to configure PPTP and L2TP VPNs as well as PPTP
passthrough. This section contains the following topics:
• How PPTP VPNs work
• FortiGate unit as a PPTP server
• Configuring the FortiGate unit for PPTP VPN
• Configuring the FortiGate unit for PPTP pass through
• Testing PPTP VPN connections
• Logging VPN events
• Configuring L2TP VPNs
• L2TP configuration overview
How PPTP VPNs work

The Point-to-Point Tunneling Protocol enables you to create a VPN between a remote
client and your internal network. Because it is a Microsoft Windows standard, PPTP does
not require third-party software on the client computer. As long as the ISP supports PPTP
on its servers, you can create a secure connection by making relatively simple
configuration changes to the client computer and the FortiGate unit.
PPTP uses Point-to-Point protocol (PPP) authentication protocols so that standard PPP
software can operate on tunneled PPP links. PPTP packages data in PPP packets and
then encapsulates the PPP packets within IP packets for transmission through a VPN
tunnel.
When the FortiGate unit acts as a PPTP server, a PPTP session and tunnel is created as
soon as the PPTP client connects to the FortiGate unit. More than one PPTP session can
be supported on the same tunnel. FortiGate units support PAP, CHAP, and plain text
authentication. PPTP clients are authenticated as members of a user group.
Traffic from one PPTP peer is encrypted using PPP before it is encapsulated using
Generic Routing Encapsulation (GRE) and routed to the other PPTP peer through an ISP
network. PPP packets from the remote client are addressed to a computer on the private
network behind the FortiGate unit. PPTP packets from the remote client are addressed to
the public interface of the FortiGate unit. See Figure 48 on page 514.

01-420-99686-20101026 513
How PPTP VPNs work PPTP and L2TP
Caution: PPTP control channel messages are not authenticated, and their integrity is not
protected. Furthermore, encapsulated PPP packets are not cryptographically protected and
may be read or modified unless appropriate encryption software such as Secure Shell
(SSH) or Secure File Transfer Protocol (SFTP) is used to transfer data after the tunnel has
been established.
As an alternative, you can use encryption software such as Microsoft
Point-to-Point Encryption (MPPE) to secure the channel. MPPE is built into
Microsoft Windows clients and can be installed on Linux clients. FortiGate units
support MPPE.
Figure 48: Packet encapsulation

n
tio
na
e sti .2
d 20
ffic 68.
Tra 92.1 1
1 3
2
1
3
2
de
P atio
st
P n
in
T 1
P 7
pa 2
ck .16
et .3
s 0.
1
1
3
2
.1
.30
de
P atio
.16
st
P n
in
T 1
2
P 7
17
pa 2
on
ck .16
ati
et .3
s 0.
tin
d es .2
ffic .20
1
Tra .168
2 1
19 3
2
In Figure 48, traffic from the remote client is addressed to a computer on the network
behind the FortiGate unit. When the PPTP tunnel is established, packets from the remote
client are encapsulated and addressed to the FortiGate unit. The FortiGate unit forwards
disassembled packets to the computer on the internal network.
When the remote PPTP client connects, the FortiGate unit assigns an IP address from a
reserved range of IP addresses to the client PPTP interface. The PPTP client uses the
assigned IP address as its source address for the duration of the connection.
When the FortiGate unit receives a PPTP packet, the unit disassembles the PPTP packet
and forwards the packet to the correct computer on the internal network. The firewall
policy and protection profiles on the FortiGate unit ensure that inbound traffic is screened
and processed securely.

514 01-420-99686-20101026
PPTP and L2TP FortiGate unit as a PPTP server
Note: PPTP clients must be authenticated before a tunnel is established. The

authentication process relies on FortiGate user group definitions, which can optionally use
established authentication mechanisms such as RADIUS or LDAP to authenticate PPTP
clients. All PPTP clients are challenged when a connection attempt is made.
FortiGate unit as a PPTP server

In the most common Internet scenario, the PPTP client connects to an ISP that offers PPP
connections with dynamically-assigned IP addresses. The ISP forwards PPTP packets to
the Internet, where they are routed to the FortiGate unit.
Figure 49: FortiGate unit as a PPTP server
ork
tw
l Ne
er na
Int
t_1
li en
_C
TP
PP
3
e nt_
Cli
T P_
PP
2
e nt_
_ Cli
TP
PP
If the FortiGate unit will act as a PPTP server, there are a number of steps to complete:
• Configure user authentication for PPTP clients.
• Enable PPTP.
• Specify the range of addresses that are assigned to PPTP clients when connecting
• Configure the firewall policy.
Configuring user authentication for PPTP clients

To enable authentication for PPTP clients, you must create user accounts and a user
group to identify the PPTP clients that need access to the network behind the FortiGate
unit. Within the user group, you must add a user for each PPTP client.
You can choose to use a plain text password for authentication or forward authentication
requests to an external RADIUS, LDAP, or TACACS+ server. If password protection will be
provided through a RADIUS, LDAP, or TACACS+ server, you must configure the FortiGate
unit to forward authentication requests to the authentication server.
This example creates a basic user/password combination.

01-420-99686-20101026 515
FortiGate unit as a PPTP server PPTP and L2TP
Configuring a user account

To add a local user - web-based manager
1 Go to User > User > User and select Create New
2 Enter a User Name.
3 Enter a Password for the user. The password should be at least six characters.
4 Select OK.
To add a local user - CLI

config user local
edit <username>
set type password
set passwd <password>
end
Configuring a user group

To ease configuration, create user groups that contain users in similar categories or
departments.
To create a user group - web-based manager

1 Go to User > User Group > User Group and select Create New.
2 Enter a Name for the group.
3 Select the Type of Firewall.
4 From the Available Users list, select the required users and select the right-facing
arrow to add them to the Members list.
5 Select OK.
To create a user group - CLI

config user group
edit <group_name>
set group-type firewall
set members <user_names>
end
Enabling PPTP and specifying the PPTP IP address range

The PPTP address range specifies the range of addresses reserved for remote PPTP
clients. When a PPTP client connects to the FortiGate unit, the client is assigned an IP
address from this range. Afterward, the FortiGate unit uses the assigned address to
communicate with the PPTP client.
The address range that you reserve can be associated with private or routable IP
addresses. If you specify a private address range that matches a network behind the
FortiGate unit, the assigned address will make the PPTP client appear to be part of the
internal network.

516 01-420-99686-20101026
PPTP and L2TP FortiGate unit as a PPTP server
PPTP requires two IP addresses, one for each end of the tunnel. The PPTP address
range is the range of addresses reserved for remote PPTP clients. When the remote
PPTP client establishes a connection, the FortiGate unit assigns an IP address from the
reserved range of IP addresses to the client PPTP interface or retrieves the assigned IP
address from the PPTP user group. If you use the PPTP user group, you must also define
the FortiGate end of the tunnel by entering the IP address of the unit in Local IP
(web-based manager) or local-ip (CLI). The PPTP client uses the assigned IP address
as its source address for the duration of the connection.
PPTP configuration is only available through the CLI. In the example below, PPTP is
enabled with the use of an IP range of 182.168.1.1 to 192.168.1.10 for addressing.
Note: The start and end IPs in the PPTP address range must be in the same 24-bit subnet,
e.g. 192.168.1.1 - 192.168.1.254.
config vpn pptp

set status enable
set ip-mode range
set eip 192.168.1.10
set sip 192.168.1.1
end
In this example, PPTP is enabled with the use of a user group for addressing, where the
IP address of the PPTP server is 192.168.1.2 and the user group is hr_admin.
config vpn pptp
set status enable
set ip-mode range
set local-ip 192.168.2.1
set usrgrp hr_admin
end
Adding the firewall policy

The firewall policy specifies the source and destination addresses that can generate traffic
inside the PPTP tunnel and defines the scope of services permitted through the tunnel. If a
selection of services are required, define a service group.
To configure the firewall for the PPTP tunnel - web-based manager

Source Interface/Zone The FortiGate interface connected to the Internet.

Source Address Select the name that corresponds to the range of addresses that
you reserved for PPTP clients
Destination The FortiGate interface connected to the internal network.
Interface/Zone
Destination Address Select the name that corresponds to the IP addresses behind the
FortiGate unit
Schedule always
Service ANY
Action ACCEPT

01-420-99686-20101026 517
Configuring the FortiGate unit for PPTP VPN PPTP and L2TP
Note: Do not select identity-based policy, as this will cause the PPTP access to fail.
Authentication is configured in the PPTP configuration setup.
To configure the firewall for the PPTP tunnel - CLI

edit 1
set srcintf <interface to internet>
set dstintf <interface to internal network>
set srcaddr <reserved_range>
set dstaddr <internal_addresses>
set action accept
set schedule always
set service ANY
end
Configuring the FortiGate unit for PPTP VPN

PPTP pass through configuration overview
To arrange for PPTP packets to pass through the FortiGate unit to an external PPTP
server, perform the following tasks in the order given:
• Configure user authentication for PPTP clients.
• Enable PPTP on the FortiGate unit and specify the range of addresses that can be
assigned to PPTP clients when they connect.
• Configure PPTP pass through on the FortiGate unit.
Configuring the FortiGate unit for PPTP pass through

To forward PPTP packets to a PPTP server on the network behind the FortiGate unit, you
need to perform the following configuration tasks on the FortiGate unit:
• Define a virtual IP address that points to the PPTP server.
• Create a firewall policy that allows incoming PPTP packets to pass through to the
PPTP server.
Note: The address range is the external (public) ip address range which requires access to
the internal PPTP server through the FortiGate virtual port-forwarding firewall.
IP addresses used in this document are fictional and follow the technical documentation
guidelines specific to Fortinet. Real external IP addresses are not used.
Configuring a virtual IP address

The virtual IP address will be the address of the PPTP server host.
To define a virtual IP for PPTP pass through - web-based manager

3 Enter the name of the VIP, for example, PPTP_Server.
4 Select the External Interface where the packets will be received for the PPTP server.
5 Enter the External IP Address for the VIP.

518 01-420-99686-20101026
PPTP and L2TP Configuring the FortiGate unit for PPTP pass through
6 Select Port Forwarding.

7 Set the Protocol to TCP.
8 Enter the External Service Port of 1723, the default for PPTP.
9 Enter the Map to Port to 1723.
10 Select OK.
To define a virtual IP for PPTP pass through - web-based manager

config firewall vip
edit PPTP_Server
set extinf <interface>
set extip <ip_address>
set protocol tcp
set extport 1723
set mappedport 1723
end
Configuring a port-forwarding firewall policy

To create a port-forwarding firewall policy for PPTP pass through you must first create an
address range reserved for the PPTP clients.
To create an address range - web-based manager

2 Enter a Name for the range, for example, External_PPTP.
3 Select a Type of Subnet/IP Range.
4 Enter the IP address range.
5 Select the Interface to the Internet.
6 Select OK.
To create an address range - CLI

edit External_PPTP
set iprange <ip_range>
set start-ip <ip_address>
set end-ip <ip_address>
set associated-interface <internet_interface>
end
With the address set, you can add the firewall policy.
To add the firewall policy - web-based manager

Source Interface/Zone The FortiGate interface connected to the Internet.

Source Address Select the address range created in the previous step.
Destination The FortiGate interface connected to the PPTP server.
Interface/Zone
Destination Address Select the VIP address created in the previous steps.

01-420-99686-20101026 519
Testing PPTP VPN connections PPTP and L2TP
Schedule always
Service PPTP
Action ACCEPT
To add the firewall policy - CLI

set srcintf <interface to internet>
set dstintf <interface to PPTP server>
set srcaddr <address_range>
set dstaddr <PPTP_server_address>
set action accept
set schedule always
set service PPTP
end
Testing PPTP VPN connections

To confirm that a PPTP 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 PPTP VPN tunnel initializes when the dialup client attempts to
connect.
Logging VPN events

PPTP VPN, activity is logged when enabling VPN logging. The FortiGate unit connection
events and tunnel status (up/down) are logged.
To log VPN events

1 Go to Log&Report > Log Config > Log Setting.
2 Enable the storage of log messages to one or more locations:
3 Select Apply.
To filter VPN events

1 Go to Log&Report > Log Config > Event Log.
2 Select Enable, and then select L2TP/PPTP/PPPoE service event.
3 Select Apply.
To view event logs

1 Go to Log&Report > Log Access > Memory.
2 If the option is available from the Log Type list, select the log file from disk or memory.
Configuring L2TP VPNs

This section describes how to configure a FortiGate unit to establish a Layer Two
Tunneling Protocol (L2TP) tunnel with a remote dialup client. The FortiGate
implementation of L2TP enables a remote dialup client to establish an L2TP tunnel with
the FortiGate unit directly.

520 01-420-99686-20101026
PPTP and L2TP Configuring L2TP VPNs
According to RFC 2661, an Access Concentrator (LAC) can establish an L2TP tunnel with
an L2TP Network Server (LNS). In a typical scenario, the LAC is managed by an ISP and
located on the ISP premises; the LNS is the gateway to a private network. When a remote
dialup client connects to the Internet through the ISP, the ISP uses a local database to
establish the identity of the caller and determine whether the caller needs access to an
LNS through an L2TP tunnel. If the services registered to the caller indicate that an L2TP
connection to the LNS is required, the ISP LAC attempts to establish an L2TP tunnel with
the LNS.
A FortiGate unit can be configured to act as an LNS. The FortiGate implementation of
L2TP enables a remote dialup client to establish an L2TP tunnel with the FortiGate unit
directly, bypassing any LAC managed by an ISP. The ISP must configure its network
access server to forward L2TP traffic from the remote client to the FortiGate unit directly
whenever the remote client requires an L2TP connection to the FortiGate unit.
When the FortiGate unit acts as an LNS, an L2TP session and tunnel is created as soon
as the remote client connects to the FortiGate unit. The FortiGate unit assigns an IP
address to the client from a reserved range of IP addresses. The remote client uses the
assigned IP address as its source address for the duration of the connection.
More than one L2TP session can be supported on the same tunnel. FortiGate units can be
configured to authenticate remote clients using a plain text user name and password, or
authentication can be forwarded to an external RADIUS or LDAP server. L2TP clients are
authenticated as members of a user group.
Caution: FortiGate units support L2TP with Microsoft Point-to-Point Encryption (MPPE)
encryption only. Later implementations of Microsoft L2TP for Windows use IPSec and
require certificates for authentication and encryption. If you want to use Microsoft L2TP with
IPSec to connect to a FortiGate unit, the IPSec and certificate elements must be disabled
on the remote client.
Traffic from the remote client must be encrypted using MPPE before it is encapsulated and
routed to the FortiGate unit. Packets originating at the remote client are addressed to a
computer on the private network behind the FortiGate unit. Encapsulated packets are
addressed to the public interface of the FortiGate unit. See Figure 50.
When the FortiGate unit receives an L2TP packet, the unit disassembles the packet and
forwards the packet to the correct computer on the internal network. The firewall policy
and protection profiles on the FortiGate unit ensure that inbound traffic is screened and
processed securely.

01-420-99686-20101026 521
Configuring L2TP VPNs PPTP and L2TP
Figure 50: L2TP encapsulation
on
ati
tin
d es 0.2
2
ffic 68.
Tra 92.1 1
1 3
2
1
3
2
de
L2 tio
st
in
T n
a
P 1
pa 72
ck .16
et .3
s 0
.1
1
3
2
0.1
de
6.3
L2 t i o
st
.1
in
T n
72
P 1
1
pa 7 2
on
ck .16
ti
et .3
na
s 0
sti
de 0.2
.1
i c
ff .2
Tra .168
2 1
19 3
2
Note: Fortinet units cannot deliver non-IP traffic such as Frame Relay or ATM frames
encapsulated in L2TP packets — FortiGate units support the IPv4 and IPv6 addressing
you cannot
schemes only.
Network topology
The remote client connects to an ISP that determines whether the client requires an L2TP
connection to the FortiGate unit. If an L2TP connection is required, the connection request
is forwarded to the FortiGate unit directly.

522 01-420-99686-20101026
PPTP and L2TP L2TP configuration overview
Figure 51: Example L2TP configuration
ork
tw
l Ne
e rna
Int
1
e nt_
Cli
o te_
R em
3
e nt_
_ Cli
m ote
Re
2
e nt_
_ Cli
m ote
Re
L2TP infrastructure requirements

• The FortiGate unit must be operating in NAT/Route mode and have a static public IP
address.
• The ISP must configure its network access server to forward L2TP traffic from remote
clients to the FortiGate unit directly.
• The remote client must not generate non-IP traffic (Frame Relay or ATM frames).
• The remote client includes L2TP support with MPPE encryption. If the remote client
includes Microsoft L2TP with IPSec, the IPSec and certificate components must be
disabled.
L2TP configuration overview

To configure a FortiGate unit to act as an LNS, you perform the following tasks on the
FortiGate unit:
• Create an L2TP user group containing one user for each remote client.
• Enable L2TP on the FortiGate unit and specify the range of addresses that can be
assigned to remote clients when they connect.
• Define firewall source and destination addresses to indicate where packets transported
through the L2TP tunnel will originate and be delivered.
• Create the firewall policy and define the scope of permitted services between the
source and destination addresses.
• Configure the remote clients.

01-420-99686-20101026 523
L2TP configuration overview PPTP and L2TP
Authenticating L2TP clients

L2TP clients must be authenticated before a tunnel is established. The authentication
process relies on FortiGate user group definitions, which can optionally use established
authentication mechanisms such as RADIUS or LDAP to authenticate L2TP clients. All
L2TP clients are challenged when a connection attempt is made.
To enable authentication, you must create user accounts and a user group to identify the
L2TP clients that need access to the network behind the FortiGate unit.
You can choose to use a plain text password for authentication or forward authentication
requests to an external RADIUS or LDAP server. If password protection will be provided
through a RADIUS or LDAP server, you must configure the FortiGate unit to forward
authentication requests to the authentication server.
Enabling L2TP and specifying an address range

The L2TP address range specifies the range of addresses reserved for remote clients.
When a remote client connects to the FortiGate unit, the client is assigned an IP address
from this range. Afterward, the FortiGate unit uses the assigned address to communicate
with the remote client.
The address range that you reserve can be associated with private or routable IP
addresses. If you specify a private address range that matches a network behind the
FortiGate unit, the assigned address will make the remote client appear to be part of the
internal network.
To enable L2TP and specify the L2TP address range, use the config vpn l2tp CLI
command.
The following example shows how to enable L2TP and set the L2TP address range using
a starting address of 192.168.10.80 and an ending address of 192.168.10.100 for
an existing group of L2TP users named L2TP_users:
config vpn l2tp
set sip 192.168.10.80
set eip 192.168.10.100
set status enable
set usrgrp L2TP_users
end
Defining firewall source and destination addresses

Before you define the firewall policy, you must define the source and destination
addresses of packets that are to be transported through the L2TP tunnel:
• For the source address, enter the range of addresses that you reserved for remote
L2TP clients (for example 192.168.10.[80-100]).
• For the destination address, enter the IP addresses of the computers that the L2TP
clients need to access on the private network behind the FortiGate unit (for example,
172.16.5.0/24 for a subnet, or 172.16.5.1 for a server or host, or
192.168.10.[10-15] for an IP address range).
To define the firewall source address

1 Go to Firewall > Address and select Create New.
2 In the Address Name field, type a name that represents the range of addresses that
you reserved for remote clients (for example, Ext_L2TPrange).
3 In Type, select Subnet / IP Range.
4 In the Subnet / IP Range field, type the corresponding IP address range.

524 01-420-99686-20101026
PPTP and L2TP Adding the firewall policy
5 In Interface, select the FortiGate interface that connects to the clients.

This is usually the interface that connects to the Internet.
6 Select OK.
To define the firewall destination address

1 Go to Firewall > Address and select Create New.
2 In the Address Name field, type a name that represents a range of IP addresses on the
network behind the FortiGate unit (for example, Int_L2TPaccess).
4 In the Subnet / IP Range field, type the corresponding IP address range.
5 In Interface, select the FortiGate interface that connects to the network behind the
FortiGate unit.
6 Select OK.
Adding the firewall policy

The firewall policy specifies the source and destination addresses that can generate traffic
inside the L2TP tunnel and defines the scope of services permitted through the tunnel. If a
selection of services are required, define a service group.
To define the traffic and services permitted inside the L2TP tunnel
1 Go to Firewall > Policy and select Create New.
2 Enter these settings in particular:
Source Interface/Zone Select the FortiGate interface to the Internet.

Source Address Select the name that corresponds to the range of addresses that
you reserved for L2TP clients (for example, Ext_L2TPrange).
Destination Interface/Zone Select the FortiGate interface to the internal (private) network.
Destination Address Select the name that corresponds to the IP addresses behind
the FortiGate unit (for example, Int_L2TPaccess).
Service Select ANY, or if selected services are required instead, select
the service group that you defined previously.
Action Select ACCEPT.
3 You may enable NAT, a protection profile, and/or event logging, or select Enable
Identity Based Policy to add authentication or shape traffic. For more information on
identity based policies, see the FortiGate Fundamentals chapter of the handbook.
4 Select OK.
Configuring a Linux client

The following procedure outlines how to install L2TP client software and run an L2TP
tunnel on a Linux computer. Obtain an L2TP client package that meets your requirements
(for example, rp-l2tp). If needed to encrypt traffic, obtain L2TP client software that
supports encryption using MPPE.
To establish an L2TP tunnel with a FortiGate unit that has been set up to accept L2TP
connections, you can obtain and install the client software following these general
guidelines:

01-420-99686-20101026 525
Adding the firewall policy PPTP and L2TP
1 If encryption is required but MPPE support is not already present in the kernel,
download and install an MPPE kernel module and reboot your computer.
2 Download and install the L2TP client package.
3 Configure an L2TP connection to run the L2TP program.
4 Configure routes to determine whether all or some of your network traffic will be sent
through the tunnel. You must define a route to the remote network over the L2TP link
and a host route to the FortiGate unit.
5 Run l2tpd to start the tunnel.
Follow the software supplier’s documentation to complete the steps.
To configure the system, you need to know the public IP address of the FortiGate unit, and
the user name and password that has been set up on the FortiGate unit to authenticate
L2TP clients. Contact the FortiGate administrator if required to obtain this information.
Monitoring L2TP sessions

You can display a list of all active sessions and view activity by port number. By default,
port 1701 is used for L2TP VPN-related communications. If required, active sessions can
be stopped from this view.
To view the list of active sessions

2 In the Top Sessions widget, select Details.
Testing L2TP VPN connections

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.
Logging L2TP VPN events

You can configure the FortiGate unit to log VPN events. For L2TP VPNs, connection
events and tunnel status (up/down) are logged.
To log VPN events - web-based manager

2 Enable the storage of log messages to one or more locations.
3 Select Apply.
5 Select Enable, and then select L2TP/PPTP/PPPoE service event.
6 Select Apply.
To log VPN events - CLI

config log memory setting
set diskfull overright
set status enable
end
config log eventfilter
set ppp
end

526 01-420-99686-20101026
Session helpers
The FortiOS firewall can analyze most TCP/IP protocol traffic by comparing packet header
information to firewall policies. This comparison determines whether to accept or deny the
packet and the session that the packet belongs to.
Some protocols include information in the packet body (or payload) that must be analyzed
to successfully process sessions for this protocol. For example, the SIP VoIP protocol
uses TCP control packets with a standard destination port to set up SIP calls. But the
packets that carry the actual conversation can use a variety of UDP protocols with a
variety of source and destination port numbers. The information about the protocols and
port numbers used for a SIP call is contained in the body of the SIP TCP control packets.
To successfully process SIP VoIP calls, FortiOS must be able to extract information from
the body of the SIP packet and use this information to allow the voice-carrying packets
FortiOS uses session helpers to analyze the data in the packet bodies of some protocols
and adjust the firewall to allow those protocols to send packets through the firewall.
This section describes:
• Viewing the session helper configuration
• Changing the session helper configuration
• DCE-RPC session helper (dcerpc)
• DNS session helpers (dns-tcp and dns-udp)
• File transfer protocol (FTP) session helper (ftp)
• H.245 session helpers (h245I and h245O)
• H.323 and RAS session helpers (h323 and ras)
• Media Gateway Controller Protocol (MGCP) session helper (mgcp)
• ONC-RPC portmapper session helper (pmap)
• PPTP session helper for PPTP traffic (pptp)
• Remote shell session helper (rsh)
• Real-Time Streaming Protocol (RTSP) session helper (rtsp)
• Session Initiation Protocol (SIP) session helper (sip)
• Trivial File Transfer Protocol (TFTP) session helper (tftp)
• Oracle TNS listener session helper (tns)

01-420-99686-20101026 527
Viewing the session helper configuration Session helpers
Viewing the session helper configuration

You can view the session helpers enabled on your FortiGate unit in the CLI using the
commands below. The following output shows the first two session helpers. The number
of session helpers can vary to around 20.
show system session-helper
config system session-helper
edit 1
set name pptp
set port 1723
set protocol 6
end
next
set name h323
set port 1720
set protocol 6
next
end
.
.
The configuration for each session helper includes the name of the session helper and the
port and protocol number on which the session helper listens for sessions. Session
helpers listed on protocol number 6 (TCP) or 17 (UDP). For a complete list of protocol
numbers see: Assigned Internet Protocol Numbers.
For example, the output above shows that FortiOS listens for PPTP packets on TCP port
1723 and H.323 packets on port TCP port 1720.
If a session helper listens on more than one port or protocol the more than one entry for
the session helper appears in the config system session-helper list. For example,
the pmap session helper appears twice because it listens on TCP port 111 and UDP port
111. The rsh session helper appears twice because it listens on TCP ports 514 and 512.
Changing the session helper configuration

Normally you will not need to change the configuration of the session helpers. However in
some cases you may need to change the protocol or port the session helper listens on.
Changing the protocol or port that a session helper listens on

Most session helpers are configured to listen for their sessions on the port and protocol
that they typically use. If your FortiGate unit receives sessions that should be handled by a
session helper on a non-standard port or protocol you can use the following procedure to
change the port and protocol used by a session helper. The following example shows how
to change the port that the pmap session helper listens on for Sun RPC portmapper TCP
sessions. By default pmap listens on TCP port 111.

528 01-420-99686-20101026
Session helpers Changing the session helper configuration
To change the port that the pmap session helper listens on to TCP port 112
1 Confirm that the TCP pmap session helper entry is 11 in the session-helper list:
show system session-helper 11
edit 11
set name pmap
set port 111
set protocol 6
next
end
2 Enter the following command to change the TCP port to 112.
edit 11
set port 112
end
3 The pmap session helper also listens on UDP port 111. Confirm that the UDP pmap
session helper entry is 12 in the session-helper list:
edit 12
set name pmap
set port 111
set protocol 17
next
end
4 Enter the following command to change the UDP port to 112.
edit 12
set port 112
end
end
Use the following command to set the h323 session helper to listen for ports on the UDP
protocol.
To change the protocol that the h323 session helper listens on

1 Confirm that the h323 session helper entry is 2 in the session-helper list:
edit 2
set name h323
set port 1720
set protocol 6
next
end
2 Enter the following command to change the protocol to UDP.
edit 2
set protocol 17
end
end

01-420-99686-20101026 529
Changing the session helper configuration Session helpers
If a session helper listens on more than one port or protocol, then multiple entries for the
session helper must be added to the session helper list, one for each port and protocol
combination. For example, the rtsp session helper listens on TCP ports 554, 7070, and
8554 so there are three rtsp entries in the session-helper list. If your FortiGate unit
receives rtsp packets on a different TCP port (for example, 6677) you can use the
following command to configure the rtsp session helper to listen on TCP port 6677.
To configure a session helper to listen on a new port and protocol

edit 0
set name rtsp
set port 6677
set protocol 6
end
Disabling a session helper

In some cases you may need to disable a session helper. Disabling a session helper just
means removing it from the session-helper list so that the session helper is not listening
on a port. You can completely disable a session helper by deleting all of its entries from
the session helper list. If there are multiple entries for a session helper on the list you can
delete one of the entries to prevent the session helper from listening on that port.
To disable the mgcp session helper from listening on UDP port 2427
1 Enter the following command to find the mgcp session helper entry that listens on UDP
port 2427:
.
.
.
edit 19
set name mgcp
set port 2427
set protocol 17
next
.
.
.
2 Enter the following command to delete session-helper list entry number 19 to disable
the mgcp session helper from listening on UDP port 2427:
delete 19
By default the mgcp session helper listens on UDP ports 2427 and 2727. The previous
procedure shows how to disable the mgcp protocol from listening on port 2427. The
following procedure completely disables the mgcp session helper by also disabling it from
listening on UDP port 2727.

530 01-420-99686-20101026
Session helpers DCE-RPC session helper (dcerpc)
To completely disable the mgcp session helper

1 Enter the following command to find the mgcp session helper entry that listens on UDP
port 2727:
.
.
.
edit 20
set name mgcp
set port 2727
set protocol 17
next
.
.
.
2 Enter the following command to delete session-helper list entry number 20 to disable
the mgcp session helper from listening on UDP port 2727:
delete 20
DCE-RPC session helper (dcerpc)

Distributed Computing Environment Remote Procedure Call (DCE-RPC) provides a way
for a program running on one host to call procedures in a program running on another
host. DCE-RPC (also called MS RPC for Microsoft RPC) is similar to ONC-RPC. Because
of the large number of RPC services, the transport address of an RPC service is
dynamically negotiated based on the service program's universal unique identifier (UUID).
The Endpoint Mapper (EPM) binding protocol in FortiOS maps the specific UUID to a
transport address.
To accept DCE-RPC sessions you must add a firewall policy with service set to any or to
the DEC-RPC pre-defined service (which listens on TCP and UDP ports 135). The dcerpc
session helper also listens on TCP and UDP ports 135.
The session allows FortiOS to handle DCE-RPC dynamic transport address negotiation
and to ensure UUID-based firewall policy enforcement. You can define a firewall policy to
permit all RPC requests or to permit by specific UUID number.
In addition, because a TCP segment in a DCE-RPC stream might be fragmented, it might
not include an intact RPC PDU. This fragmentation occurs in the RPC layer; so FortiOS
does not support parsing a fragmented packets.
DNS session helpers (dns-tcp and dns-udp)

FortiOS includes two DNS session helpers, dns-tcp, a session helper for DNS over TCP,
and dns-udp, a session helper for DNS over UDP. The DNS session helpers monitor DNS
query and reply packets and close sessions if the DNS flag indicates the packet is a reply
message.
To accept DNS sessions you must add a firewall policy with service set to any or to the
DNS pre-defined service (which listens on TCP and UDP ports 35). The dns-udp session
helper also listens on UDP port 53. By default the dns-tcp session helper is disabled. If
needed you can use the following command to enable the dns-tcp session helper to listen
for DNS sessions on TCP port 53:

01-420-99686-20101026 531
File transfer protocol (FTP) session helper (ftp) Session helpers

edit 0
set name dns-tcp
set port 53
set protocol 6
end
File transfer protocol (FTP) session helper (ftp)

The FTP session helper monitors PORT, PASV and 227 commands and NATs the IP
addresses and port numbers in the body of the FTP packets and opens ports on the
FortiGate unit as required.
To accept FTP sessions you must add a firewall policy with service set to any or to the
FTP, FTP_Put, and FTP_GET pre-defined services (which all listen on TCP port 21).
H.245 session helpers (h245I and h245O)

H.245 is a control channel protocol used for H.323 and other similar communication
sessions. H.245 sessions transmit non-telephone signals. H.245 sessions carry
information needed for multimedia communication, such as encryption, flow control jitter
management and others.
FortiOS includes two H.245 sessions helpers, h245I which is for H.245 call in and h245O
which is for H.245 call out sessions. There is no standard port for H.245. By default the
H.245 sessions helpers are disabled. You can enable them as you would any other
session helper. When you enable them, you should specify the port and protocol on which
the FortiGate unit receives H.245 sessions.
H.323 and RAS session helpers (h323 and ras)

The H.323 session helper supports secure H.323 voice over IP (VoIP) sessions between
terminal endpoints such as IP phones and multimedia devices. In H.323 VoIP networks,
gatekeeper devices manage call registration, admission, and call status for VoIP calls. The
FortiOS h323 session helper supports gatekeepers installed on two different networks or
on the same network.
To accept H.323 sessions you must add a firewall policy with service set to any or to the
H323 pre-defined service (which listens on TCP port numbers 1720 and 1503 and on UDP
port number 1719). The h323 session helper listens on TCP port 1720.
The ras session helper is used with the h323 session helper for H.323 Registration,
Admission, and Status (RAS) services. The ras session helper listens on UDP port 1719.
Alternate H.323 gatekeepers

The h323 session helper supports using H.323 alternate gatekeepers. All the H.323 end
points must register with a gatekeeper through the Registration, Admission, and Status
(RAS) protocol before they make calls. During the registration process, the primary
gatekeeper sends Gatekeeper Confirm (GCF) and Registration Confirm (RCF) messages
to the H.323 end points that contain the list of available alternate gatekeepers.

532 01-420-99686-20101026
Session helpers Media Gateway Controller Protocol (MGCP) session helper (mgcp)
The alternate gatekeeper provides redundancy and scalability for the H.323 end points. If
the primary gatekeeper fails the H.323 end points that have registered with that
gatekeeper are automatically registered with the alternate gatekeeper. To use the H.323
alternate gatekeeper, you need to configure firewall policies that allow H.323 end points to
reach the alternate gatekeeper.
Media Gateway Controller Protocol (MGCP) session helper (mgcp)

The Media Gateway Control Protocol (MGCP) is a text-based application layer protocol
used for VoIP call setup and control. MGCP uses a master-slave call control architecture
in which the media gateway controller uses a call agent to maintain call control
intelligence, while the media gateways perform the instructions of the call agent.
To accept MGCP sessions you must add a firewall policy with service set to any or to the
MGCP pre-defined service (which listens on UDP port numbers 2427 and 2727). The
h323 session helper also listens on UDP port numbers 2427 and 2727.
The MGCP session helper does the following:
• VoIP signalling payload inspection. The payload of the incoming VoIP signalling packet
is inspected and malformed packets are blocked.
• Signaling packet body inspection. The payload of the incoming MGCP signaling packet
is inspected according to RFC 3435. Malformed packets are blocked.
• Stateful processing of MGCP sessions. State machines are invoked to process the
parsed information. Any out-of-state or out-of-transaction packet is identified and
properly handled.
• MGCP Network Address Translation (NAT). Embedded IP addresses and ports in
packet bodies is properly translated based on current routing information and network
topology, and is replaced with the translated IP address and port number, if necessary.
• Manages pinholes for VoIP traffic. To keep the VoIP network secure, the IP address
and port information used for media or signalling is identified by the session helper,
and pinholes are dynamically created and closed during call setup.
ONC-RPC portmapper session helper (pmap)

Open Network Computing Remote Procedure Call (ONC-RPC) is a widely deployed
remote procedure call system. Also called Sun RPC, ONC-RPC allows a program running
on one host to call a program running on another. The transport address of an ONC-RPC
service is dynamically negotiated based on the service's program number and version
number. Several binding protocols are defined for mapping the RPC program number and
version number to a transport address.
To accept ONC-RPC sessions you must add a firewall policy with service set to any or to
the ONC-RPC pre-defined service (which listens on TCP and UDP port number 111). The
RPC portmapper session helper (called pmap) handles the dynamic transport address
negotiation mechanisms of ONC-RPC.

01-420-99686-20101026 533
PPTP session helper for PPTP traffic (pptp) Session helpers
PPTP session helper for PPTP traffic (pptp)

The PPTP session help supports port address translation (PAT) for PPTP traffic. PPTP
provides IP security at the Network Layer. PPTP consists of a control session and a data
tunnel. The control session runs over TCP and helps in establishing and disconnecting the
data tunnel. The data tunnel handles encapsulated Point-to-Point Protocol (PPP) packets
carried over IP.
To accept PPTP sessions that pass through the FortiGate unit you must add a firewall
policy with service set to any or to the PPTP pre-defined service (which listens on IP port
47 and TCP port 1723). The pptp session helper listens on TCP port 1723.
PPTP uses TCP port 1723 for control sessions and Generic Routing Encapsulation (GRE)
(IP protocol 47) for tunneling the encapsulated PPP data. The GRE traffic carries no port
number, making it difficult to distinguish between two clients with the same public IP
address. PPTP uses the source IP address and the Call ID field in the GRE header to
identify a tunnel. When multiple clients sharing the same IP address establish tunnels with
the same PPTP server, they may get the same Call ID. The call ID value can be translated
in both the control message and the data traffic, but only when the client is in a private
network and the server is in a public network.
PPTP clients can either directly connect to the Internet or dial into a network access server
to reach the Internet. A FortiGate unit that protects PPTP clients can translate the clients’
private IP addresses to a pool of public IP addresses using NAT port translation (NAT-PT).
Because the GRE traffic carries no port number for address translation, the pptp session
helper treats the Call ID field as a port number as a way of distinguishing multiple clients.
After the PPTP establishing a TCP connection with the PPTP server, the client sends a
start control connection request message to establish a control connection. The server
replies with a start control connection reply message. The client then sends a request to
establish a call and sends an outgoing call request message. FortiOS assigns a Call ID
(bytes 12-13 of the control message) that is unique to each PPTP tunnel. The server
replies with an outgoing call reply message that carries its own Call ID in bytes 12-13 and
the client’s call ID in bytes 14-15. The pptp session helper parses the control connection
messages for the Call ID to identify the call to which a specific PPP packet belongs. The
session helper also identifies an outgoing call request message using the control
message type field (bytes 8-9) with the value 7. When the session helper receives this
message, it parses the control message for the call ID field (bytes 12-13). FortiOS
translates the call ID so that it is unique across multiple calls from the same translated
client IP. After receiving outgoing call response message, the session helper holds this
message and opens a port that accepts GRE traffic that the PPTP server sends. An
outgoing call request message contains the following parts:
• The protocol used for the outgoing call request message (usually GRE)
• Source IP address (PPTP server IP)
• Destination IP address (translated client IP)
• Destination port number (translated client call ID)
The session helper identifies an outgoing call reply message using the control message
type field (bytes 8-9) with the value 8. The session helper parses these control messages
for the call ID field (bytes 12-13) and the client’s call ID (bytes 14-15). The session helper
then uses the client’s call ID value to find the mapping created for the other direction, and
then opens a pinhole to accept the GRE traffic that the client sends.

534 01-420-99686-20101026
Session helpers Remote shell session helper (rsh)
An outgoing call reply message contains the following parts:

• Protocol used for the outgoing call reply message (usually GRE)
• Source IP address (PPTP client IP)
• Destination IP address (PPTP server IP)
• Destination port number (PPTP server Call ID)
Each port that the session opens creates a session for data traffic arriving in that direction.
The session helper opens the following two data sessions for each tunnel:
• Traffic from the PPTP client to the server, using the server’s call ID as the destination
port
• Traffic from the PPTP server to the client, using the client’s translated call ID as the
destination port
The default timeout value of the control connection is 30 minutes. The session helper
closes the pinhole when the data session exceeds the timeout value or is idle for an
extended period.
Remote shell session helper (rsh)

Using the remote shell program (RSH), authenticated users can run shell commands on
remote hosts. RSH sessions most often use TCP port 514. To accept RSH sessions you
must add a firewall policy with service set to any or to the RSH pre-defined service (which
listens on TCP port number 514).
FortiOS automatically invokes the rsh session helper to process all RSH sessions on TCP
port 514. The rsh session helper opens ports required for the RSH service to operate
through a FortiGate unit running NAT/Route or Transparent and supports port translation
of RSH traffic.
Real-Time Streaming Protocol (RTSP) session helper (rtsp)

The Real-Time Streaming Protocol (RTSP) is an application layer protocol often used by
SIP to control the delivery of multiple synchronized multimedia streams, for example,
related audio and video streams. Although RTSP is capable of delivering the data streams
itself it is usually used like a network remote control for multimedia servers. The protocol is
intended for selecting delivery channels (like UDP, multicast UDP, and TCP) and for
selecting a delivery mechanism based on the Real-Time Protocol (RTP). RTSP may also
use the SIP Session Description Protocol (SDP) as a means of providing information to
clients for aggregate control of a presentation consisting of streams from one or more
servers, and non-aggregate control of a presentation consisting of multiple streams from a
single server.
To accept RTSP sessions you must add a firewall policy with service set to any or to the
RTSP pre-defined service (which listens on TCP ports 554, 770, and 8554 and on UDP
port 554). The rtsp session helper listens on TCP ports 554, 770, and 8554.
The rtsp session help is required because RTSP uses dynamically assigned port numbers
that are communicated in the packet body when end points establish a control connection.
The session helper keeps track of the port numbers and opens pinholes as required. In
Network Address Translation (NAT) mode, the session helper translates IP addresses and
port numbers as necessary.

01-420-99686-20101026 535
Session Initiation Protocol (SIP) session helper (sip) Session helpers
In a typical RTSP session the client starts the session (for example, when the user selects
the Play button on a media player application) and establishes a TCP connection to the
RTSP server on port 554. The client then sends an OPTIONS message to find out what
audio and video features the server supports. The server responds to the OPTIONS
message by specifying the name and version of the server, and a session identifier, for
example, 24256-1.
The client then sends the DESCRIBE message with the URL of the actual media file the
client wants to play. The server responds to the DESCRIBE message with a description of
the media in the form of SDP code. The client then sends the SETUP message, which
specifies the transport mechanisms acceptable to the client for streamed media, for
example RTP/RTCP or RDT, and the ports on which it receives the media.
In a NAT configuration the rtsp session helper keeps track of these ports and addresses
translates them as necessary. The server responds to the SETUP message and selects
one of the transport protocols. When both client and server agree on a mechanism for
media transport the client sends the PLAY message, and the server begins streaming the
media.
Session Initiation Protocol (SIP) session helper (sip)

The sip session helper is described in “The SIP session helper” on page 2052.
Trivial File Transfer Protocol (TFTP) session helper (tftp)

To accept TFTP sessions you must add a firewall policy with service set to any or to the
TFTP pre-defined service (which listens on UDP port number 69). The TFTP session
helper also listens on UTP port number 69.
TFTP initiates transfers on UDP port 69, but the actual data transfer ports are selected by
the server and client during initialization of the connection. The tftp session helper reads
the transfer ports selected by the TFTP client and server during negotiation and opens
these ports on the firewall so that the TFTP data transfer can be completed. When the
transfer is complete the tftp session helper closes the open ports.
Oracle TNS listener session helper (tns)

The Oracle Transparent Network Substrate (TNS) listener listens on port TCP port 1521
for network requests to be passed to a database instance. The Oracle TNS listener
session helper (tns) listens for TNS sessions on TCP port 1521. TNS is a foundation
technology built into the Oracle Net foundation layer and used by SQLNET.

536 01-420-99686-20101026
Advanced firewall concepts
This section delves into more detailed firewall information and examples.
• Session tables
• Adding NAT firewall policies in transparent mode
• Adding a static NAT virtual IP for a single IP address and port
• Double NAT: combining IP pool with virtual IP
• Using VIP range for Source NAT (SNAT) and static 1-to-1 mapping
Session tables
Firewall session tables include entries to record source and destination IP addresses and
port numbers. For each packet received by a FortiGate unit, it references the session table
for a match. Packets of an established session are checked against the session table
continually throughout the communication. The performance of depends on the
performance of processing session table.
Firewall sessions clear from the table based on the timeout, that is, Time-to-live (TTL)
setting. Equally, a completely inactive session with no FIN or RESET will be flushed by the
by the session TTL timer. Sessions are not closed based on FIN or a RESET. A FIN that is
acknowledged with a FIN ACK would slush the session.
Viewing session tables in the web-based manager

Firewall sessions are viewable in the web-based manager using the Top Sessions
widget.If this widget is not on the Dashboard, select the Widget link at the top of the
web-based manager and select it from the pop-up dialog box.
Figure 52: Top Sessions widget on the Dashboard
While this view shows a graph of the connecting users and IP addresses, selecting Details
at the bottom of the widget will display the complete session information.

01-420-99686-20101026 537
Session tables Advanced firewall concepts
Figure 53: Session tables in the Top Sessions widget
You can clear a session from the table by scrolling to the right and selecting the delete
icon for a given session.
Viewing session tables in the CLI

Session tables and information is also viewable from the CLI. More information on
sessions are available from the CLI where various diagnose commands reveal more
granular data. To view the session information enter the following CLI command:
diagnose sys session list
Output will look something similar to this:
session info: proto=17 proto_state=01 duration=121 expire=58
timeout=0 flags=00000000 sockflag=00000000 sockport=0
av_idx=0 use=4
origin-shaper=
reply-shaper=
per_ip_shaper=
ha_id=0 hakey=0
policy_dir=0 tunnel=/
state=may_dirty br
statistic(bytes/packets/allow_err): org=63/1/1 reply=133/1/1
tuples=2
orgin->sink: org pre->post, reply pre->post dev=6->2/2->6
gwy=0.0.0.0/0.0.0.0
hook=pre dir=org act=noop 172.20.120.85:51167-
>8.8.8.8:53(0.0.0.0:0)
hook=post dir=reply act=noop 8.8.8.8:53-
>172.20.120.85:51167(0.0.0.0:0)
misc=0 policy_id=3 id_policy_id=0 auth_info=0 chk_client_info=0
vd=0
serial=000171db tos=ff/ff app_list=0 app=0
dd_type=0 dd_rule_id=0
per_ip_bandwidth meter: addr=172.20.120.85, bps=1984
total session 189
To clear a session enter the following command:
diagnose sys session clear

538 01-420-99686-20101026
Advanced firewall concepts Session tables
Figure 54: State field in Session Tables
State Meaning
log Session is being logged
local Session is originating from, or destined for, a local stack.
may_dirty Session is created by a policy. For example, the session for FTP channel
control will have this state but the FTP data channel will not.
ndr Session will be checked by an IPS signature.
nds Session will be checked by an IPS anomaly.
br Session is being bridged, that is, in transparent mode.
npu Session will possibly be offloaded to NPU.
wccp Session is handled by WCCP.
Proto_state fields: TCP

The proto_state field value has two digits. This is because the FortiGate unit keeps track
of the original direction and the reply direction.
State Value Expire Timer Default (seconds)

NONE 0 10
ESTABLISHED 1 3600
SYN_SENT 2 120
SYN & SYN/ACK 3 60
FIN_WAIT 4 120
TIME_WAIT 5 120
CLOSE 6 10
CLOSE_WAIT 7 120
LAST_ACK 8 30
LISTEN 9 120
Proto_state fields: SCTP
State Value Expire Timer Default (seconds)

SCTP_S_NONE 0 60
SCTP_S_ESTABLISHED 1 3600
SCTP_S_CLOSED 2 10
SCTP_S_COOKIE_WAIT 3 5
SCTP_S_COOKIE_ECHOED 4 10
SCTP_S_SHUTDOWN_SENT 5 30
SCTP_S_SHUTDOWN_RECD 6 30
SCTP_S_ACK_SENT 7 3
SCTP_S_MAX 8 120

01-420-99686-20101026 539
Adding NAT firewall policies in transparent mode Advanced firewall concepts
Proto_state fields: UDP

UDP is a sessionless protocol, however the FortiGate unit still monitors two different
states:
• Reply Not Seen - 0
• Reply Seen - 1
In the example output below, a state of 00, the UDP packet has been seen and a session
will be created, but no reply packet has been seen:
use=3
In this example, the UDP packet has been seen and a session created. Reply packets
have also been seen:
use=3
Proto_state field for ICMP

There are no states for ICMP traffic; it will always appear as proto_state=00.
Adding NAT firewall policies in transparent mode

Similar to operating in NAT mode, when operating a FortiGate unit in Transparent mode
you can add firewall policies and:
• Enable NAT to translate the source addresses of packets as they pass through the
FortiGate unit.
• Add virtual IPs to translate destination addresses of packets as they pass through the
FortiGate unit.
• Add IP pools as required for source address translation
For NAT firewall policies to work in NAT mode you must have two interfaces on two
different networks with two different subnet addresses. Then you can create firewall
policies to translate source or destination addresses for packets as they are relayed by the
FortiGate unit from one interface to the other.
A FortiGate unit operating in Transparent mode normally has only one IP address, the
management IP. To support NAT in Transparent mode you can add a second
management IP. These two management IPs must be on different subnets. When you add
two management IP addresses, all FortiGate unit network interfaces will respond to
connections to both of these IP addresses.
In the example shown in Figure 55, all of the PCs on the internal network (subnet address
192.168.1.0/24) are configured with 192.168.1.99 as their default route. One of the
management IPs of the FortiGate unit is set to 192.168.1.99. This configuration results in
a typical NAT mode firewall. When a PC on the internal network attempts to connect to the
Internet, the PC's default route sends packets destined for the Internet to the FortiGate
unit internal interface. Similarly on the DMZ network (subnet address 10.1.1.0/24) all of
the PCs have a default route of 10.1.1.99.
This example describes adding an internal to WAN1 firewall policy to relay these packets
from the internal interface out the WAN1 interface to the Internet. Because the WAN1
interface does not have an IP address of its own, you must add an IP pool to the WAN1
interface that translates the source addresses of the outgoing packets to an IP address on
the network connected to the wan1 interface.

540 01-420-99686-20101026
Advanced firewall concepts Adding NAT firewall policies in transparent mode
The example describes adding an IP pool with a single IP address of 10.1.1.201. So all
packets sent by a PC on the internal network that are accepted by the Internal to WAN1
policy leave the WAN1 interface with their source address translated to 10.1.1.201. These
packets can now travel across the Internet to their destination. Reply packets return to the
WAN1 interface because they have a destination address of 10.1.1.201. The Internal to
WAN1 NAT policy translates the destination address of these return packets to the IP
address of the originating PC and sends them out the internal interface to the
originating PC.
Use the following steps to configure NAT in Transparent mode
• Add two management IPs
• Add an IP pool to the WAN1 interface
• Add an Internal to WAN1 firewall policy
Note: You can add the firewall policy from the web-based manager and then use the CLI to
enable NAT and add the IP Pool.
Figure 55: Example NAT in Transparent mode configuration
10 Tra
.1.
R
1.0 n
ou
sp
te
/24 are
r
10 nt m
.1. od
WA 1.9 e M
9,
N1 19 anag
2.1 em
68 en
.1. t I
99 Ps
Int :
ern
Z a l
DM
D 0.
M 1.
Z 1.
1
ne 0/
In 92
tw 24
te .1
or
rn 6 8
k
al .1
ne .0
tw /24
or
k
To add a source address translation NAT policy in Transparent mode

1 Enter the following command to add two management IPs.
The second management IP is the default gateway for the internal network.
set manageip 10.1.1.99/24 192.168.1.99/24
end

01-420-99686-20101026 541
Adding a static NAT virtual IP for a single IP address and port Advanced firewall concepts
2 Enter the following command to add an IP pool to the WAN1 interface:

edit nat-out
set interface "wan1"
set endip 10.1.1.201
end
3 Enter the following command to add an Internal to WAN1 firewall policy with NAT
enabled that also includes an IP pool:
edit 1
set srcintf "internal"
set dstintf "wan1"
set scraddr "all"
set dstaddr "all"
set action accept
set service "ANY"
set nat enable
set ippool enable
set poolname nat-out
end
Adding a static NAT virtual IP for a single IP address and port

In this example, the wan1 interface of the FortiGate unit is connected to the Internet and
the Internal interface is connected to the DMZ network. The IP address 192.168.37.4 on
port 80 on the Internet is mapped to 10.10.10.42 on port 8000 on the private network.
Attempts to communicate with 192.168.37.4 from the Internet are translated and sent to
10.10.10.42 by the FortiGate unit. The computers on the Internet are unaware of this
translation and see a single computer at 192.168.37.4 rather than a FortiGate unit with a
private network behind it.

542 01-420-99686-20101026
Advanced firewall concepts Adding a static NAT virtual IP for a single IP address and port
Figure 56: Static NAT virtual IP for a single IP address example
.2
0 .10 0.42
. 1 1
10 0.
e IP 10.1
ur c IP 1
So ation 3
2
n
sti
De NA
T wit
ha
vir
tua
l IP 1
3
S 10
2
.55
10
er .1
Int
ve 0 .
.37 37.4
.
e
10 rnal
r 42
8
IP
.10 IP .16 8.
.10 92 .16
.2 I P 1 192
e IP
urc n
V
19 irtua So inatio
2.1 l IP st
68 De
.37
.4
19
C 168
lie .
2.
nt 37
IP .55
To add a static NAT virtual IP for a single IP address and port - web-based manager
3 Complete the following and select OK.
.
Name static_NAT
Type Static NAT
External IP Address/Range 192.168.37.4.
Mapped IP Address/Range 10.10.10.42
Port Forwarding Selected
Protocol TCP
External Service Port 80
Map to Port 8000
To add a static NAT virtual IP for a single IP address and port - CLI
config firewall vip
edit static_NAT
set extintf wan1
set type static-nat
set extip 192.168.37.4
set extport 80
set mappedport 8000

01-420-99686-20101026 543
Double NAT: combining IP pool with virtual IP Advanced firewall concepts
end
Add a external to dmz1 firewall policy that uses the virtual IP so that when users on the
Internet attempt to connect to the web server IP address packets pass through the
FortiGate unit from the external interface to the dmz1 interface. The virtual IP translates
the destination address of these packets from the external IP to the DMZ network IP
address of the web server.
To add a static NAT virtual IP for a single IP address to a firewall policy - web-based
manager
2 Complete the following:
Source Interface/Zone wan1

Source Address All
Destination Address static_nat
Schedule always
Service HTTP
Action ACCEPT
3 Select NAT.
4 Select OK.
To add a static NAT virtual IP for a single IP address to a firewall policy - CLI
edit 1
set srcintf wan1
set srcaddr all
set dstaddr static_nat
set action accept
set schedule always
set service ANY
set nat enable
end
Double NAT: combining IP pool with virtual IP

In this example, a combination of virtual IPs, IP pools and firewall policies will allow the
local users to access the servers on the DMZ. The example uses a fixed port and IP pool
to allow more than one user connection while using virtual IP to translate the destination
port from 8080 to 80. The firewall policy uses both the IP pool and the virtual IP for double
IP and/or port translation.
For this example:
• Users in the 10.1.1.0/24 subnet use port 8080 to access server 172.20.120.1.
• The server’s listening port is 80.
• Fixed ports must be used.

544 01-420-99686-20101026
Advanced firewall concepts Double NAT: combining IP pool with virtual IP
Figure 57: Double NAT
In 10
In
te .1
10 terna
rn .1
al .0
.1. l
N /2
et 4
3.0
w
or
/16
k
WA
N 1
Z 2
DM120.
0 .
2.2
17
W 2.
eb 20
17
S .12
er 0
ve .1
r
To create an IP pool - web-based manager
1 Go to Firewall > Virtual IP > IP Pool.
3 Enter the Name pool-1.
4 Enter the IP Range/Subnet 10.1.3.1-10.1.3.254.
5 Select OK.
To create an IP pool - CLI

edit pool-1
set endip 10.1.3.254
end
Next, create the virtual IP with port translation to translate the user internal IP used by the
network users to the DMZ port and IP address of the server.
To create a Virtual IP with port translation - web-based manager

Name server-1
External Interface Internal
Type Static NAT
External IP Address/Range 172.20.120.1
Note this address is the same as the server address.
Mapped IP Address/Range 172.20.120.1
Port Forwarding Enable
Protocol TCP
External Service Port 8080
Map to Port 80

01-420-99686-20101026 545
Using VIP range for Source NAT (SNAT) and static 1-to-1 mapping Advanced firewall concepts
To create a Virtual IP with port translation - CLI

config firewall vip
edit server-1
set extintf internal
set type static-nat
set extip 172.20.120.1
set extport 80
set mappedport 8080
end
Add an internal to DMZ firewall policy that uses the virtual IP to translate the destination
port number and the IP pool to translate the source addresses.
To create the firewall policy - web-based manager

Source Interface/Zone internal

Source Address all
Destination dmz
Interface/Zone
Destination Address server-1
Schedule always
Service HTTP
Action ACCEPT
NAT Select
Dynamic IP Pool Select, and select the pool-1 IP pool.
To create the firewall policy - CLI

edit 1
set dstintf dmz1
set srcaddr all
set dstaddr server-1
set action accept
set schedule always
set service HTTP
set nat enable
set ippool enable
set poolname pool-1
end
Using VIP range for Source NAT (SNAT) and static 1-to-1 mapping
VIP addresses are typically used to map external (public) to internal (private) IP addresses
for Destination NAT (DNAT).

546 01-420-99686-20101026
Advanced firewall concepts Using VIP range for Source NAT (SNAT) and static 1-to-1 mapping
This example shows how to use VIP ranges to perform Source NAT (SNAT) with a static
1-to-1 mapping from internal to external IP addresses. This is similar to using an IP pool
with the advantage of having predictable and static 1-to-1 address mapping.
Figure 58: Network diagram
.42
0 .10
.1 h
10 roug .46
th .10
.10
In tw 10
te o
N
P
rn rk
e
10 ort 2
al
.10
.10
.2
P
VI ort 1
19 P ra
2.1 ng
6 e
t 8.
19 hrou 36.4
2.1 gh
68
.37
.8
This example will associate each internal IP address to one external IP address for the
Source NAT (SNAT) translation.
Using the diagram above, the translations will look like the following
Traffic from Source IP Translated to Source IP (SNAT)

10.10.10.42 192.168.37.4
10.10.10.43 192.168.37.5
... ...
10.10.10.46 192.168.37.8
First, configure the virtual IP.
To configure the virtual IP - web-based manager

2 Enter the Name of Static_NAT_1to1.
3 Select the External Interface of port 1 from the drop-down list.
4 Enter the External IP Address of 192.168.37.4.
5 Enter the Mapped IP Address range of 10.10.10.42 to 10.10.10.46.
6 Select OK.

01-420-99686-20101026 547
To configure the virtual IP - CLI

config firewall vip
edit "Static_NAT_1to1"
set extip 192.168.37.4
set extintf "port1"
set mappedip 10.10.10.42-10.10.10.46
next
end
Next, configure the firewall policies. Even if no connection needs to be initiated from external to
internal, a second firewall policy number is required to activate the VIP range. Otherwise the IP
address of the physical interface is used for NAT. In this example it is set as a “DENY” firewall policy
for security purpose.
To configure the firewall policies - web-based manager

Source Interface/Zone port2

Source Address all
Destination port1
Interface/Zone
Schedule always
Service ANY
Action ACCEPT
NAT Select
Source Interface/Zone port 1

Source Address all
Destination port 2
Interface/Zone
Destination Address Static_NAT_1to1
Schedule always
Service ALL
Action deny
Comments Used to activate static Source NAT 1-to-1
To configure the firewall policies - CLI

edit 1
set srcintf port2
set dstintf port1
set srcaddr all
set dstaddr all
set action accept
set schedule always
set service ANY

548 01-420-99686-20101026
Advanced firewall concepts Using VIP range for Source NAT (SNAT) and static 1-to-1 mapping
set nat enable

next
edit 2
set srcintf port1
set dstintf port2
set srcaddr all"
set dstaddr Static_NAT_1to1
set schedule always
set service ANY
set action deny
set comments Used to activate static Source NAT 1-to-1
next
end
end

01-420-99686-20101026 549

550 01-420-99686-20101026
Advanced concepts
This chapter provides configuration ideas and techniques to enhance your network
security.
• Central NAT table
• DHCP servers and relays
• Administration for schools
• Blocking port 25 to email server traffic
• Blocking HTTP access by IP
• Assigning IP address by MAC address
• Server load balancing and HTTP cookie persistence fields
• Stateful inspection of SCTP traffic
Central NAT table

The central NAT table enables you to define, and control with more granularity, the
address translation performed by the FortiGate unit. With the NAT table, you can define
the rules which dictate the source address or address group and which IP pool the
destination address uses.
While similar in functionality to IP pools, where a single address is translated to an
alternate address from a range of IP addresses, with IP pools there is no control over the
translated port. When using the IP pool for source NAT, you can define a fixed port to
guarantee the source port number is unchanged. If no fix port is defined, the port
translation is randomly chosen by the FortiGate unit. With the central NAT table, you have
full control over both the IP address and port translation.
The NAT table also functions in the same way as the firewall policy table. That is, the
FortiGate unit reads the NAT rules in a top-down methodology, until it hits a matching rule
for the incoming address. This enables you to create multiple NAT policies that dictate
which IP pool is used based on the source address. The NAT policies can be rearranged
within the policy list as well, the same way as firewall policies.
NAT policies are applied to network traffic after a firewall policy.
NAT policies are created in the web-based manager by going to Firewall > Policy >
Central NAT Table. The NAT policies are enabled when you configure the firewall policy by
selecting the Use Central NAT Table option.
NAT policies are created in the CLI by using the commands under config firewall
central-nat. To enable the policies use the commands
set central-nat enable
end

01-420-99686-20101026 551
DHCP servers and relays Advanced concepts
DHCP servers and relays

The DHCP protocol enables hosts to automatically obtain an IP address from a DHCP
server. Optionally, they can also obtain default gateway and DNS server settings. A
FortiGate interface or VLAN subinterface can provide the following DHCP services:
• Basic DHCP servers for non-IPSec IP networks
• IPSec DHCP servers for IPSec (VPN) connections
• DHCP relay for regular Ethernet or IPSec (VPN) connections
An interface cannot provide both a server and a relay for connections of the same type
(regular or IPSec). However, you can configure a Regular DHCP server on an interface
only if the interface is a physical interface with a static IP address. You can configure an
IPSec DHCP server on an interface that has either a static or a dynamic IP address.
You can configure one or more DHCP servers on any FortiGate interface. A DHCP server
dynamically assigns IP addresses to hosts on the network connected to the interface. The
host computers must be configured to obtain their IP addresses using DHCP.
If an interface is connected to multiple networks via routers, you can add a DHCP server
for each network. The IP range of each DHCP server must match the network address
range. The routers must be configured for DHCP relay.
You can configure a FortiGate interface as a DHCP relay. The interface forwards DHCP
requests from DHCP clients to an external DHCP server and returns the responses to the
DHCP clients. The DHCP server must have appropriate routing so that its response
packets to the DHCP clients arrive at the unit.
Service
On FortiGate 50 and 60 series units, a DHCP server is configured, by default, on the
Internal interface:
IP Range 192.168.1.110 to 192.168.1.210
Netmask 255.255.255.0
Default gateway 192.168.1.99
Lease time 7 days
DNS Server 1 192.168.1.99
You can disable or change this default DHCP Server configuration. However, you cannot
configure DHCP in Transparent mode. In Transparent mode DHCP requests pass through
the unit. An interface must have a static IP before you configure a DHCP server on it.
These settings are appropriate for the default Internal interface IP address of
192.168.1.99. If you change this address to a different network, you need to change the
DHCP server settings to match.
Reserving IP addresses for specific clients

You can reserve an IP address for a specific client identified by the client device MAC
address and the connection type, regular Ethernet or IPSec. The DHCP server always
assigns the reserved address to that client. You can assign up to 200 IP addresses as
reserved.
Use the config system dhcp reserved-address command to reserve IP address
for specific clients.

552 01-420-99686-20101026
Advanced concepts FortiGate DNS services
FortiGate DNS services

You can configure a unit to be the DNS server for any networks that can communicate with
a FortiGate interface. You set up the DNS configuration for each interface in one of three
ways:
• The interface relays DNS requests to the DNS servers configured for the unit by going
to System > Network > Options.
• The interface resolves DNS requests using a FortiGate DNS database. DNS requests
for host names not in the FortiGate DNS database are dropped.
• The interface resolves DNS requests using the FortiGate DNS database and relays
DNS requests for host names not in the FortiGate DNS database to the DNS servers
configured for the unit (System > Network > Options). This is called a split DNS
configuration.
If virtual domains are not enabled you can create one DNS database that is shared by all
FortiGate interfaces. If virtual domains are enabled, you create a DNS database in each
VDOM. All of the interfaces in a VDOM share the DNS database in that VDOM.
Split DNS
In a split DNS configuration you create a DNS database on the FortiGate unit, usually for
host names on an internal network or for a local domain. When users on the internal
network attempt to connect to these host names the IP addresses are provided by the
FortiGate DNS database. Host names that are not in the FortiGate DNS database are
resolved by relaying the DNS lookup to an external DNS server.
A split DNS configuration can be used to provide internal users access to resources on
your private network that can also be accessed from the Internet. For example, you could
have a public web server behind a FortiGate unit operating in NAT/Route mode. Users on
the Internet access this web server using a port forwarding virtual IP. So the web server
has a public IP address for internet users. But you may want users on your internal
network to access the server using its private IP address to keep traffic from internal users
off of the Internet.
To do this, you create a split DNS configuration on the unit and add the host name of the
server to the FortiGate DNS database, but include the internal IP address of server
instead of the external IP address. Because the unit checks the FortiGate DNS database
first, all DNS lookups for the server host name will return the internal IP address of the
server. For an example of how to configure split DNS, see “To configure a split DNS
To configure a DNS server

1 Go to System > Network > Options and add the IP addresses of a Primary and
Secondary DNS server.
These should be the DNS servers provided by your ISP or other public DNS servers.
The unit uses these DNS servers for its own DNS lookups and can be used to supply
DNS look ups for your internal networks.
2 Go to System > Network > Interface and edit the interface connected to a network that
you want the unit to be a DNS server for.

01-420-99686-20101026 553
FortiGate DNS services Advanced concepts
3 Select Enable DNS Query.

When you select Enable DNS Query, the unit relays all DNS queries received by this
interface to the DNS servers configured under System > Network > Options. Select
Recursive or Non-Recursive to control how this works.
Recursive looks up domain names in the FortiGate DNS database. If the entry is not
found, the request is replayed to the DNS servers configured in System > Network >
Options. This setting can be used to split DNS configuration.
Non-recursive looks up domain names in the FortiGate DNS database. This setting
does not relay the request to the DNS servers that are configured in System > Network
> Options.
4 Go to System > Network > DNS Server and configure the FortiGate DNS database.
Add zones and entries as required. See “Configuring the FortiGate DNS database” on
page 555.
5 Configure the hosts on the internal network to use the FortiGate interface as their DNS
server.
If you are also using a FortiGate DHCP server to configure the hosts on this network,
add the IP address of the FortiGate interface to the DNS Server IP address list.
Configure a FortiGate interface to relay DNS requests to the DNS servers configured for
the FortiGate unit under System > Network > Options.
To configure a FortiGate interface to relay DNS requests to external DNS servers

you want the unit to be a DNS server.
3 Select Enable DNS Query and select Recursive.
The interface is configured to look up domain names in the FortiGate DNS database.
and relay the requests for names not in the FortiGate DNS database to the DNS
servers configured under System > Network > Options. If you do not add entries to the
FortiGate DNS database all DNS requests are relayed to the DNS servers configured
under System > Network > Options.
server.
Configure a FortiGate interface to resolve DNS requests using the FortiGate DNS
database and to drop requests for host names that not in the FortiGate DNS database.
To configure a interface to resolve DNS requests using the FortiGate DNS database
The FortiGate unit uses these DNS servers for its own DNS lookups and can be used
to supply DNS look ups for your internal networks.

554 01-420-99686-20101026
Advanced concepts FortiGate DNS services
you want the FortiGate unit to be a DNS server.
3 Select Enable DNS Query and select Non-Recursive.
When you select Non-Recursive only the entries in the FortiGate DNS database are
used.
Add zones and entries as required. See “Configuring the FortiGate DNS database” on
page 555.
server.
Configure an interface to resolve DNS requests using the FortiGate DNS database and
relay DNS requests for host names not in the FortiGate DNS database to the DNS servers
configured under System > Network > Options. This is called a split DNS configuration.
See “Split DNS” on page 553.
To configure a split DNS configuration

you want the unit to be a DNS server for.
3 Select Enable DNS Query and select Recursive.
The interface is configured to look up domain names in the FortiGate DNS database.
and relay the requests for names not in the FortiGate DNS database to the DNS
servers configured under System > Network > Options. You can add entries to the
FortiGate DNS database for users on the internal network.
Add zones and entries as required for users on the internal network. See “Configuring
the FortiGate DNS database” on page 555.
server.
Configuring the FortiGate DNS database

The FortiGate DNS database must be configured so that DNS lookups from an internal
network are resolved by the FortiGate DNS database.
Each entry in the DNS database is a host name and the IP address it resolves to. You can
use entries as an IPv4 address (A), an IPv6 address (AAAA), a name server (NS), a
canonical name (CNAME), or a mail exchange (MX) name.

01-420-99686-20101026 555
Administration for schools Advanced concepts
To configure the FortiGate DNS database in the web-based manager, go to System >
Network > DNS Server.
To use the CLI use the commands:
conf system dns-database
edit <zone-string>
set domain <domain>
set ttl <int>
config dns-entry
edit <entry-id>
set canonical-name <canonical_name_string>
set hostname <hostname_string>
set ip <ip_address>
set ipv6 <ipv6_address>
set preference <preference_value>
set ttl <entry_ttl_value>
set type {A|AAAA|MX|NS|CNAME}
end
end
Administration for schools

For system administrator in the school system it is particularly difficult to maintain a
network and access to the Internet. There are potential legal liabilities if content is not
properly filtered and children are allowed to view pornography and other non-productive
and potentially dangerous content. For a school, too much filtering is better than too little.
This section describes some basic practices administrators can employ to help maintain
control without being too draconian for access to the internet.
Firewall policies
The default firewall policies in FortiOS allow all traffic on all ports and all IP addresses. Not
the most secure. While applying UTM profiles can help to block viruses, detect attacks and
prevent spam, this doesn’t provide a solid overall security option. The best approach is a
layered approach; the first layer being the firewall policy.
When creating outbound firewall policies, you need to know the answer to the question
“What are the students allowed to do?” The answer is surf the web, connect to FTP sites,
send/receive email, and so on.
Once you know what the students need to do, you can research the software used and
determine the ports the applications use. For example, if the students only require web
surfing, then there are only two ports (80 - HTTP and 443 - HTTPS) needed to complete
their tasks. Setting the firewall policies to only allow traffic through two ports (rather than
all 65,000), this will significantly lower any possible exploits. By restricting the ports to
known services, mean s stopping the use of proxy servers, as many of them operate on a
non-standard port to hide their traffic from URL filtering or HTTP inspection.
DNS
Students should not be allowed to use whatever DNS they want. this opens another port
for them to use and potentially smuggle traffic on. The best approach is to point to an
internal DNS server and only allow those devices out on port 53. Its the same approach
one would use for SMTP. Only allow the mail server to use port 25 since nothing else
should be sending email.

556 01-420-99686-20101026
Advanced concepts Administration for schools
If there is no internal DNS server, then the list of allowed DNS servers they can use should
be restrictive. One possible exploit would be for them to set up their own DNS server at
home that serves different IPs for known hosts, such as having Google.com sent back the
IP for playboy.com.
Encrypted traffic (HTTPS)

Generally speaking, students should not be allowed to access encrypted web sites.
Encrypted traffic cannot be sniffed, and therefore, cannot be monitored. HTTPS traffic
should only be allowed when necessary. Most web sites a student needs to access are
HTTP, not HTTPS. Due to the nature of HTTPS protocol, and the fact that encryption is an
inherent security risk to your network, its use should be restricted.
Adding a firewall policy that encompasses a list of allowed secure sites will ensure that
any HTTPS sites that are required are the only sites a student can go to.
FTP
For the most part, students should not be using FTP. FTP is not HTTP or HTTPS so you
cannot use URL flitting to restrict where they go. This can be controlled with destination
IPs in the firewall policy. With a policy that specifically outlines which FTP addresses are
allowed, all other will be blocked.
Example firewall policies

Given these requirements, an example set of firewall policies could look like the following
illustration. In a large setup, all the IPs for the students are treated by one of these four
policies.
Figure 59: Simple firewall policy setup
The last policy in the list, included by default, is a deny policy.This adds to the potential of
error that could end up allowing unwanted traffic to pass. The deny policy ensures that any
traffic making it to this point is stopped. It can also help in further troubleshooting by
viewing the logs for denied traffic.
With these policies in place, even before packet inspection occurs, the FortiGate, and the
network are fairly secure. Should any of the UTM profiles fail, there is still a basic level of
security.
UTM Profiles
In FortiOS 4.0 MR2, the protection profiles have been broken into individual profiles. Each
UTM feature is now its own component, which can make setting up network security
easier.

01-420-99686-20101026 557
Administration for schools Advanced concepts
Antivirus profiles
Antivirus screening should be enabled for any service you have enabled in the firewall
policies. In the case above, HTTP, FTP, as well as POP3 and SMTP (assuming there is
email access for students). There is not a virus scan option for HTTPS, because the
content is encrypted. Generally speaking, most of the network traffic will be students
surfing the web.
To configure antivirus profiles in the web-based manager, go to UTM > Antivirus > Profile,
or use the CLI commands under config antivirus profile.
Under the antivirus banner is also file filtering. While there should be no reason for a
student to download files - applications or otherwise - to the host PC, you can enable file
pattern matching to limit what can be downloaded. The most common file types are
available to enable for virus checking.
to configure file filtering in the web-based manager, go to UTM > Antivirus > File Filter, on
in the CLI under config antivirus filepattern.
Web filtering
The actual filtering of URLs - sites and content - should be performed by FortiGuard. It is
easier and web sites are constantly being monitored, and new ones reviewed and added
to the FortiGuard databases every day. The FortiGuard categories provide an extensive
list of offensive, and non-productive sites.
As well, there are additional settings to include in a web filtering profile to best contain a
student’s web browsing.
• Web URL filtering should be enabled to set up exemptions for web sites that are
blocked or reasons other than category filtering. It also prevents the us of IP addresses
to get around web filtering. For details on setting this up, see “Blocking HTTP access
by IP” on page 562.
• Block invalid URLs - HTTPS only. This option inspects the HTTPS certificate and looks
at the URL to ensure it’s valid. It is common for proxy sites to create an HTTPS
certificate with a garbage URL. If the site is legitimate, it should be set up correctly. If
the site approach to security is to ignore it, then their security policy puts your network
at risk and the site should be blocked.
Web filtering options are configured in the web-based manager by going to UTM > Web
filter > Profile, or in the CLI under config webfilter profile.
Advanced options
There are a few Advanced options to consider for a web filtering profile:
• Enable Provide details for blocked HTTP 4xx and 5xx errors. Under normal
circumstances there are exploits that can be used with 400 and 500 series messages
to access the web site. While most students probably won’t know how to do this, there
is no harm in being cautious. It only takes one.
• Enable Rate Images by URL. This option only works with Google images. It examines
the URL that the images is stored at to get a rating on it, then blocks or allows the
image based on the rating of the originating URL. It does not inspect the image
contents. Most image search engines to a prefect and pass the images directly to the
browser.
• Enable Block HTTP redirects by rating. An HTTP redirect is one method of getting
around ratings. Go to one web site that has an allowed rating, and it redirects to
another web site that may want blocked.

558 01-420-99686-20101026
Advanced concepts Administration for schools
Categories and Classifications

For the selection of what FortiGuard categories and classifications that should be blocked,
that is purely based on the school system and its Internet information policy. Some
categories that could be blocked include:
• Hacking
• Illegal or Unethical
• Racism and Hate
• Proxy Avoidance
• Plagiarism
• Adult Materials
• Nudity and Risque
• Pornography
• Tasteless
• Lingerie and Swimsuit
Email Filtering
Other than specific teacher-led email inboxes, there is no reason why a student should be
able to access, read or send personal email. Ports for POP3, SMTP and IMAP should not
be opened in a firewall policies.
IPS
The intrusion protection profiles should be used to ensure the student PCs are not
vulnerable to attacks, nor do you want students making attacks. As well, IPS can do more
than simple vulnerability scans. With a FortiGuard subscription, IPS signatures are
pushed to the FortiGate unit. New signatures are released constantly for various intrusions
as they are discovered.
FortiOS includes a number of predefined IPS sensors that you can enable by default.
Selecting the all_default signature is a good place to start as it includes the major
signatures.
To configure IPS sensors in the web-based manager, go to UTM > IPS > IPS Sensor, on
the CLI use commands under config ips sensor.
Application control
Application control uses IPS signatures to limit the use of instant messaging and peer-to-
peer applications which can lead to possible infections on a student’s PC. FortiOS
includes a number of pre-defined application categories. To configure and maintain
application control profiles in the web-based manager, go to UTM > Application Control >
Application Control List. In the CLI use commands under config application list.
Some applications to consider include proxies, botnets, toolbars and P2P applications.
Logging
Turn on all logging - every option in this section should be enabled. This is not where you
decide what you are going to log. It is simply defining what the UTM profiles can log.
Logging everything is a way to monitor traffic on the network, see what student’s are
utilizing the most, and locate any potential holes in your security plan. As well, keeping this
information may help to prove negligence later in necessary.

01-420-99686-20101026 559
Blocking port 25 to email server traffic Advanced concepts
Blocking port 25 to email server traffic

Port 25 is the default port for SMTP traffic. Certain types of malware can install themselves
on an unsuspecting user’s computer and send spam using its own email server. By
blocking port 25, this prevents a host system, and potentially your network or company,
from being deemed a spam source.
This does, however limit your corporation from using a web server. You have a few options
for this:
• if the email server is on a dedicated port, such as a DMZ port, firewall policies can
ensure no traffic goes out from this port except the email server.
• Block all traffic on port 25 except the specific address of the email server.
Dedicated traffic
This example show the steps to ensure only traffic exits from the DMZ where the email
server is connected. The internal port is connected to the internal network and the WAN1
port connects to the Internet.
First, create a firewall policy that will not allow any traffic through port 25 from the internal
interface, which connects to the internal network. Place this policy at the top of the firewall
policy list.
To block traffic on port 25 - web-based manager

2 Set the following options and select OK.
Source Interface Internal
Source Address ALL
Destination Interface WAN1
Destination Address ALL
Schedule ALWAYS
Service SMTP
Action DENY
Comments Prevent Malware spam.
You may also want to enable Log Violation Traffic to see if there is any potential malware
or other user sending email using the non-corporate email server.
To block traffic on port 25 - CLI

set srcintf Internal
set srcaddr all
set dstintf wan1
set dstaddr all
set schedule always
set service smtp
set action deny
set comment “Prevent Malware spam.”
end
Next, create a firewall policy for the email server, IP address 10.10.11.29 that only allows
SMTP traffic from the email server on port 25.

560 01-420-99686-20101026
Advanced concepts Blocking port 25 to email server traffic
To allow traffic on port 25 for the email server - web-based manager

Source Interface DMZ

Source Address 10.10.11.29
Schedule ALWAYS
Service SMTP
Action ACCEPT
To allow traffic on port 25 for the email server- CLI

set srcintf dmz
set dstintf wan1
set dstaddr all
set schedule always
set service smtp
set action allow
end
Restricting traffic on port 25

This example shows how to limit traffic on port 25 on the wan port to only traffic from the
email server. The web server’s address is 10.10.10.29.
To allow traffic on port 25 for the email server - web-based manager

Source Interface INTERNAL

Source Address 10.10.10.29
Schedule ALWAYS
Service SMTP
Action ACCEPT
To allow traffic on port 25 for the email server- CLI

set dstintf wan1
set dstaddr all
set schedule always

01-420-99686-20101026 561
Blocking HTTP access by IP Advanced concepts
set service smtp

set action allow
end
Next, add a deny firewall policy that blocks all SMTP traffic from the Internal port to the
WAN1 port. Ensure this policy is directly after the policy created above.
To block SMTP traffic on port 25 for the rest of the company - web-based manager
Source Interface INTERNAL

Source Address ALL
Schedule ALWAYS
Service SMTP
Action DENY
To block SMTP traffic on port 25 for the rest of the company - CLI
set srcaddr all
set dstintf wan1
set dstaddr all
set schedule always
set service smtp
set action deny
end
Blocking HTTP access by IP

To block a web site using the IP, create a URL filter entry, using the additional information
below. Note that this is only effective with HTTP or FortiGate units running Deep
Inspection.
You need to create two URL filter entries. The first filter only allowing a text string
containing two or more sets of text separated by a period. This is to match the various
domain possibilities for websites, for example:
• example.org
• www.example.com
• www.example.co.jp
The second filter blocks any IP address lookup.
To add the URL filter entries

2 Select Create New to add a filter group, give it a name and select OK.
3 Select Create New for a new filter.

562 01-420-99686-20101026
Advanced concepts Assigning IP address by MAC address
4 Enter the URL of ^([a-z0-9-]+\.){1,}[a-z]+

5 Set the Type to Regex.
6 Set the Action to Allow.
7 Select OK.
9 Enter the URL of [0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}
10 Set the Type to Regex.
11 Set the Action to Block.
12 Select OK.
Position these at the end of the URL filter list so that any exemptions or blocks before that
are still effective.
Both of these filter entries are required. If you only enter the second one, the FortiGate
unit will also catch a URL lookup as they both behave in a similar fashion after the URL is
resolved to an IP. The first entry is needed to break out of the URL filter and allow the
website before it does the second check if they entered text.
Assigning IP address by MAC address

To prevent users in the from changing their IP addresses and causing IP address conflicts
or unauthorized use of IP addresses, you can bind an IP address to a specific MAC
address using DHCP.
Use the CLI to reserve an IP address for a particular client identified by its device MAC
address and type of connection. The DHCP server then always assigns the reserved IP
address to the client. The number of reserved addresses that you can define ranges from
10 to 200 depending on the FortiGate model.
In the example below, the IP address 10.10.10.55 for User1 is assigned to MAC address
00:09:0F:30:CA:4F.
To assign an IP address to a specific MAC address

config system dhcp reserved-address
edit <User1>
set ip <10.10.10.55>
set mac <00:09:0F:30:CA:4F>
set type regular
end
Server load balancing and HTTP cookie persistence fields

The following options are available for the config firewall vip command when
type is set to server-load-balance, server-type is set to http or https and
persistence is set to http-cookie:
http-cookie-domain
http-cookie-path
http-cookie-generation
http-cookie-age
http-cookie-share
https-cookie-share (appears when server-type is set to https)

01-420-99686-20101026 563
Server load balancing and HTTP cookie persistence fields Advanced concepts
When HTTP cookie persistence is enabled the FortiGate unit inserts a header of the
following form into each HTTP response unless the corresponding HTTP request already
contains a FGTServer cookie:
Set-Cookie: FGTServer=E7D01637C4B08E89A6714213A9D85D9C7E4D8158;
Version=1; Max-Age=3600
The value of the FGTServer cookie encodes the server that traffic should be directed to.
The value is encoded so as to not leak information about the internal network.
Use http-cookie-domain to restrict the domain that the cookie should apply to. For
example, to restrict the cookie to.server.com, enter:
set http-cookie-domain .server.com
All generated cookies will have the following form:
Version=1; Domain=.server.com; Max-Age=3600
Use http-cookie-path to limit the cookies to a particular path. For example, to limit
cookies to the path /sales, enter:
set http-cookie-path /sales
Version=1; Domain=.server.com; Path=/sales; Max-Age=3600
Use http-cookie-age to change how long the browser caches the cookie. You can
enter an age in minutes or set the age to 0 to make the browser keep the cookie
indefinitely:
set http-cookie-age 0
Version=1; Domain=.server.com; Path=/sales
Use http-cookie-generation to invalidate all cookies that have already been
generated. The exact value of the generation is not important, only that it is different from
any generation that has already been used for cookies in this domain. The simplest
approach is to increment the generation by one each time invalidation is required. Since
the default is 0, enter the following to invalidate all existing cookies:
set http-cookie-generation 1
Use http-cookie-share {disable | same-ip} to control the sharing of cookies
across virtual servers in the same virtual domain. The default setting same-ip means that
any FGTServer cookie generated by one virtual server can be used by another virtual
server in the same virtual domain. For example, if you have an application that starts on
HTTP and then changes to HTTPS and you want to make sure that the same server is
used for the HTTP and HTTPS traffic then you can create two virtual servers, one for port
80 (for HTTP) and one for port 443 (for HTTPS). As long as you add the same real servers
to both of these virtual servers (and as long as both virtual servers have the same number
of real servers with the same IP addresses), then cookies generated by accessing the
HTTP server are reused when the application changes to the HTTPS server.
If for any reason you do not want this sharing to occur then select disable to make sure
that a cookie generated for a virtual server cannot be used by other virtual servers.
Use https-cookie-secure to enable or disable using secure cookies. Secure cookies
are disabled by default because secure cookies can interfere with cookie sharing across
HTTP and HTTPS virtual servers. If enabled, then the Secure tag is added to the cookie
inserted by the FortiGate unit:

564 01-420-99686-20101026
Advanced concepts Stateful inspection of SCTP traffic
Version=1; Max-Age=3600; Secure
For more information on load balancing, see the Load Balancing chapter of The
Handbook.
Stateful inspection of SCTP traffic

The Stream Control Transmission Protocol (SCTP) is a transport layer protocol similar to
TCP and UDP. SCTP is designed to provide reliable, in-sequence transport of messages
with congestion control. SCTP is defined in RFC 4960.
Some common applications of SCTP include supporting transmission of the following
protocols over IP networks:
• SCTP is important in 3G and 4G/LTE networks (for example, HomeNodeB =
FemtoCells)
• SS7 over IP (for example, for 3G mobile networks)
• SCTP is also defined and used for SIP over SCTP and H.248 over SCTP
• Transport of Public Switched Telephone Network (PSTN) signaling messages over IP
networks.
SCTP is a reliable transport protocol that runs on top of a connectionless packet network
(IP). SCTP provides the following services:
• Acknowledged error-free non-duplicated transfer of user data
• Data fragmentation to conform to discovered path MTU size
• Sequenced delivery of user messages within multiple streams, with an option for order-
of-arrival delivery of individual user messages
• Optional bundling of multiple user messages into a single SCTP packet
• network-level fault tolerance through supporting of multi-homing at either or both ends
of an association
• Congestion avoidance behavior and resistance to flooding and masquerade attacks
SCTP is effective as the transport protocol for applications that require monitoring and
session-loss detection. For such applications, the SCTP path and session failure-
detection mechanisms actively monitor the connectivity of the session. SCTP differs from
TCP in having multi-homing capabilities at either or both ends and several streams within
a connection, typically referred to as an association. A TCP stream represents a sequence
of bytes; an SCTP stream represents a sequence of messages.
Configuring FortiGate SCTP filtering

The FortiGate firewall can apply firewall policies to SCTP sessions in the same way as
TCP and UDP sessions. You can create firewall policies that accept or deny SCTP traffic
by setting the service to ANY. FortiOS does not include pre-defined SCTP services. To
configure firewall policies for traffic with specific SCTP source or destination ports you
must create custom firewall services for SCTP.
FortiGate units route SCTP traffic in the same way as TCP and UDP traffic. You can
configure policy routes specifically for routing SCTP traffic by setting the protocol number
to 132. SCTP policy routes can route SCTP traffic according to the destination port of the
traffic if you add a port range to the policy route.

01-420-99686-20101026 565
Stateful inspection of SCTP traffic Advanced concepts
You can configure a FortiGate unit to perform stateful inspection of different types of SCTP
traffic by creating custom SCTP services and defining the port numbers or port ranges
used by those services. FortiGate units support SCTP over IPv4. The FortiGate unit
performs the following checks on SCTP packets:
• Source and Destination Port and Verification Tag.
• Chunk Type, Chunk Flags and Chunk Length
• Verify that association exists
• Sequence of Chunk Types (INIT, INIT ACK, etc)
• Timer checking
• Four way handshake checking
• Heartbeat mechanism
• Protection against INIT/ACK flood DoS attacks, and long-INIT flooding
• Protection against association hijacking
FortiOS also supports SCTP sessions over IPsec VPN tunnels.
FortiOS also supports full traffic and event logging for SCTP sessions.
Adding an SCTP custom service

This example creates a custom SCTP service that accepts SCTP traffic using destination
port 2905. SCTP port number 2905 is used for SS7 Message Transfer Part 3 (MTP3) User
Adaptation Layer (M3UA) over IP.
To add the SCTP custom service - web-based manager

1 Go to Firewall > Service > Custom and select Create New.
2 Enter the following and select OK.
Name M3UA_service
Protocol SCTP
Source Port (Low) 1
Source Port (High) 65535
Destination Port (Low) 2905
Destination Port (High) 2905
To add the SCTP custom service - CLI

edit M3UA_service
set sctp-portrange 2905
end
Adding an SCTP policy route

You can add policy routes that route SCTP traffic based on the SCTP source and
destination port as well as other policy route criteria. The SCTP protocol number is 132.
The following example directs all SCTP traffic with SCTP destination port number 2905 to
the next hop gateway at IP address 1.1.1.1.

566 01-420-99686-20101026
Advanced concepts Stateful inspection of SCTP traffic
To add the policy route - web-based manager

1 Go to Router > Static > Policy Route.
Protocol 132
Incoming interface internal
Source address / mask 0.0.0.0 0.0.0.0
Destination address / mask 0.0.0.0 0.0.0.0
Force traffic to:
Outgoing interface external
Gateway Address 1.1.1.1
To add the policy route - CLI

config router policy
edit 1
set input-device internal
set src 0.0.0.0 0.0.0.0
set dst 0.0.0.0 0.0.0.0
set output-device external
set gateway 1.1.1.1
set protocol 132
set start-port 2905
set end-port 2905
end
Changing the session time to live for SCTP traffic

Use the following command to change the session timeout for SCTP protocol M3UA on
port 2905 to 3600 seconds.
config system session-ttl
config port
edit 1
set protocol 132
set start-port 2905
set end-port 2905
set timeout 3600
end
end
Adding an SCTP port forwarding virtual IP

This example shows how to add a static NAT port forwarding virtual IP that uses port
address translation to allow external access to a server on a private network. In this
example, the external IP address of the server 172.20.120.11 and the real IP address of
the web server on the internal network is 10.31.101.11.
config firewall vip
edit web_Server
set extintf port1

01-420-99686-20101026 567
Stateful inspection of SCTP traffic Advanced concepts
set extip 172.20.120.11

set extport 2905
set mappedport 2905
set protocol sctp
end

568 01-420-99686-20101026
Chapter 4 Logging and Reporting

Logging overview provides general information about logging. We recommend that you
begin with this chapter as it contains information for both beginners and advanced users
as well.
Log devices provides information about how to configure your chosen log device.
Configuring multiple FortiAnalyzer units or Syslog servers is also included.
Logging FortiGate activity provides information about the different log types and subtypes,
and how to enable logging of FortiGate features.
The SQL log database provides information about SQL statements as well as examples
that you can use to base your own custom datasets on.
Log message usage provides general information about log messages, such as what is a
log header. Detailed examples of each log type are discussed as well. For additional
information about all log messages recorded by a FortiGate unit running FortiOS 4.0 and
higher, see the FortiGate Log Message Reference.
Reports provides information about how to configure reports if you have logged to a
FortiAnalyzer unit, FortiGate system memory, or the FortiGate unit’s hard disk SQL
database.
FortiOS™ Handbook v2: Logging and Reporting

01-420-99686-20101026 569
Logging and Reporting for FortiOS 4.0 MR2
570 01-420-99686-20101026
Logging overview
This section explains what logging is in relation to your FortiGate unit, what a log message
is, and log management practices. These practices can help you to improve and grow
your logging requirements.
This section also includes information concerning log management practices that help you
to improve and grow your logging requirements.
• What is logging?
• How the FortiGate unit records log messages
• Log management practices
What is logging?
Logging records the traffic passing through the FortiGate unit to your network and what
action the FortiGate unit took during its scanning process of the traffic. This recorded
information is called a log message.
After a log message is recorded, it is stored within a log file which is then stored on a log
device. A log device is a central storage location for log messages. The FortiGate unit
supports several log devices, such as a FortiGuard Analysis server and the FortiAnalyzer
unit. A FortiGate unit’s system memory and local disk can also be configured to store logs,
and because of this, are also considered log devices.
Note: You must subscribe to the FortiGuard Analysis and Management Service so that you
can configure the FortiGate unit to send logs to a FortiGuard Analysis server.
This topic includes the following:

• What is a log message?
• Explanation of a log message
What is a log message?

Log messages are recorded information containing specific details about what is occurring
on your network. Within each log message there are fields. A field is two pieces of
information that explain a specific part of the log message. For example, the action field
contains login (action=login).
The fields within the log message are arranged into two groups; one group, which is first,
is called the log header, and the second group is the log body, which contains all other
fields. A log header appears as follows when viewed in the Raw format:
2010-08-03 12:55:06 log_id=0104032001 type=dlp subtype=dlp
pri=notice vd=root
The log body appears as follows when viewed in the Raw format:
policyid=1 identidx=0 serial=73855 src=“10.10.10.1” sport=1190
src_port=1190 srcint=internal dst=“192.168.1.122” dport=80
dst_port=80 dst_int=“wan1” service=“https” status=“detected”

01-420-99686-20101026 571
What is logging? Logging overview
hostname=“example.com” url=“/image/trees_pine_forest/” msg=“data

leak detected(Data Leak Prevention Rule matched)” rulename=“All-
HTTP” action=“log-only” severity=1
There are two viewing options, Format and Raw. When you view log messages in the Raw
format, you are viewing them as they would appear within the log file itself. Format is in a
more readable format, and you can easily filter information when viewing log messages
this way.
Within the log header, there is a type field, and this field indicates the type of log file the log
message is put into after it is recorded. Each log message is categorized and put into a
specific log file, which is explained in Table 51.
Table 51: Log Types based on network traffic
Log Type File name Description

Traffic tlog.log The traffic log records all traffic to and through the FortiGate
interface.
Event elog.log The event log records management and activity events. For
example, when an administrator logs in or logs out of the
web-based manager.
Antivirus vlog.log The antivirus log records virus incidents in Web, FTP, and email
traffic.
Web wlog.log The web filter log records HTTP FortiGate log rating errors
including web content blocking actions that the FortiGate unit
performs.
Attack alog.log The attack log records attacks that are detected and prevented by
the FortiGate unit.
Email Filter slog.log The email filter log records blocking of email address patterns and
content in SMTP, IMAP, and POP3 traffic.
Data Leak dlog.log The Data Leak Prevention log records log data that is considered
Prevention sensitive and that should not be made public. This log also records
data that a company does not want entering their network.
Application rlog.log The application control log records data detected by the FortiGate
Control unit and the action taken against the network traffic depending on
the application that is generating the traffic, for example, instant
messaging software, such as MSN Messenger.
DLP archive clog.log The DLP archive log, or clog.log, records the following log
messages:
• email messages (using protocols such as SMTP or POP3)
• FTP events
• quarantine
• IPS packet
• instant messaging
• VoIP
Netscan nlog.log The Network Vulnerability Scan log records vulnerabilities during
the scanning of the network.
The log header also contains the log_id field. The log_id field contains the ten-digit
identification number which includes the unique number that is associated with that
specific log message. For example, 0315012552:
• 03 – category number (web filtering log type)
• 15 – subtype number (URL filter block log subtype)
• 012552 – the unique number for that log message.
Table 53 explains which category number is associated with each log type, as well as the
subtype name and associated number. The last six digits, those designated as unique to
that log message, are not included in the table.

572 01-420-99686-20101026
Logging overview What is logging?
Note: When viewing log messages in the Raw format, in Memory, the ten-digit log ID
number is used; however, when viewing the same log messages, in Raw format, in Disk,
the five-digit log ID number is used (except for traffic logs which have only one-digit log
IDs). This five-digit log identification number is used because of log size reduction that
occurred in FortiOS 4.0 MR1.
Table 52: Log types and subtypes
Log Type Category Sub-Type Sub-Type

Number Number
traffic (Traffic allowed – Policy allowed traffic 21
Log) 00 violation – Policy violation traffic 22
Other 38
webcache – Web cache 23
wanopt – WAN optimization 29
event 01 system – System activity event 00
(Event Log) ipsec – IPSec negotiation event 01
dhcp – DHCP service event 02
ppp – L2TP/PPTP/PPPoE service event 03
admin – admin event 04
ha – HA activity event 05
auth – Firewall authentication event 06
pattern – Pattern update event 07
nac quarantine – Endpoint NAC 12
alertemail – Alert email notifications 23
sslvpn-user – SSL VPN user event 32
sslvpn-admin – SSL VPN administration event 33
sslvpn-session – SSL VPN session event 34
voip – VoIP 40
his-performance – performance statistics 43
GTP – (FortiOS Carrier only) GTP events 44
notification – Notification 45
radius – RADIUS 46
event-amc-inf-bypass – AMC events 58
mms-stats – (FortiOS Carrier only) MMS 61
wireless – Wireless 63
vipssl – VIP SSL events 41
ldb-monitor – LDB monitor events 42
wad - WAN opt events 53
dlp 09 dlp – Data Leak Prevention 54
(Data Leak
Prevention)
app-crtl 10 app-crtl-all – All application control 59
(Application
Control Log)

01-420-99686-20101026 573
What is logging? Logging overview
Table 52: (Continued)Log types and subtypes
Log Type Category Sub-Type Sub-Type

Number Number
DLP archive HTTP – Virus infected 24
(DLP Archive FTP – FTP content metadata 25
Log) 06 SMTP – SMTP content metadata 26
POP3 – POP3 content metadata 27
IMAP – IMAP content metadata 28
HTTPS – Virus infected 30
im-all – IM messages 31
NNTP – NNTP content metadata 39
VOIP – VoIP content metadata 40
MM1 (FortiOS Carrier only) 48
SMTPS – SMTPS content metadata 55
POP3S – POP3S content metadata 56
IMAPS – IMAPS content metadata 57
virus (Antivirus infected – Virus infected 11
Log) 02 filename – Filename blocked 12
oversize – File oversized 13
scanerror 62
webfilter (Web 03 content – content block 14
Filter Log) urlfilter – URL filter 15
ftgd_block – FortiGuard block 16
ftgd_allow – FortiGuard allowed 17
ftgd_err – FortiGuard error 18
ftgd_quota – FortiGuard quota 40
activexfilter – ActiveX script filter 35
cookiefilter – Cookie script filter 36
appletfilter – Applet script filter 37
ips (Attack Log) 04 signature – Attack signature 19
anomaly – Attack anomaly 20
emailfilter SMTP 08
(Spam Filter 05 POP3 09
Log) IMAP 10
carrier-endpoint-filter (FortiOS Carrier only) 47
Mass-MMS (FortiOS Carrier only) 52
network scan 16 discovery 00
vulnerability 01
The log header also contains information about the log severity level and is indicated in
the pri field. This information is important because the severity level indicates various
severities that are occurring. For example, if the pri field contains alert, you need to take
immediate action with regards to what occurred. There are six log severity levels.
You can define what severity level the FortiGate unit records logs at when configuring the
logging location. The FortiGate unit logs all messages at and above the logging severity
level you select. For example, if you select Error, the unit logs Error, Critical, Alert, and
Emergency level messages.

574 01-420-99686-20101026
Logging overview What is logging?
Table 53: Log severity levels
Levels Description
0 - Emergency The system has become unstable.
1 - Alert Immediate action is required.
2 - Critical Functionality is affected.
3 - Error An error condition exists and functionality could be
affected.
4 - Warning Functionality could be affected.
5 - Notification Information about normal events.
6 - Information General information about system operations.
The Debug severity level, not shown in Table 53, is rarely used. It is the lowest log severity
level and usually contains some firmware status information that is useful when the
FortiGate unit is not functioning properly. Debug log messages are only generated if the
log severity level is set to Debug. Debug log messages are generated by all types of
FortiGate activities.
Explanation of a log message

The following is a detailed explanation of the fields within a log message. It explains the
log header fields, as well as the log body fields of a DLP log message.
Log header:
2010-08-03 12:55:06 log_id=0104032001 type=dlp subtype=dlp
pri=notice vd=root
date=(2010-08-03) The year, month and day of when the event occurred in yyyy-mm-dd
format.
time=(12:55:06) The hour, minute and second of when the event occurred in the format
hh:mm:ss.
log_id A ten-digit number. The first two digits represent the log type and the
following two digits represent the log subtype. The last five digits are
the message ID.
type=(dlp) The section of system where the event occurred.
subtype=(dlp) The subtype category of the log message. See Table 53 on page 575.
pri=(notice) The severity level of the event. See Table 53 on page 575.
vd=(root) The name of the virtual domain where the action/event occurred in. If
no virtual domains exist, this field always contains root.
Log body:
policyid=1 identidx=0 serial=73855 src=“10.10.10.1” sport=1190
src_port=1190 srcint=internal dst=“192.168.1.122” dport=80
dst_port=80 dst_int=“wan1” service=“https” status=“detected”
hostname=“example.com” url=“/image/trees_pine_forest/” msg=“data
leak detected(Data Leak Prevention Rule matched)” rulename=“All-
HTTP” action=“log-only” severity=1

01-420-99686-20101026 575
How the FortiGate unit records log messages Logging overview
policyid=(1) The ID number of the firewall policy that applies to the session or
packet. Any policy that is automatically added by the FortiGate will
have an index number of zero.
identidx=(0) The identity-based policy identification number. This field displays
zero if the firewall policy does not use an identity-based policy;
otherwise, it displays the number of the identity-based policy entry
that the traffic matched. This number is not globally unique, it is only
locally unique within a given firewall policy.
serial=(73855) The serial number of the firewall session of which the event
happened.
src=(10.10.10.1) The source IP address.
sport=(1190) The source port number.
src_port=(1190) The source port number.
srcint=(internal) The source interface name.
dst=(192.168.1.122) The destination IP address.
dport=(80) The destination port number.
dst_port=(80) The destination port number.
dst_int=(wan1) The destination interface name.
service=(https) The IP network service that applies to the session or packet. The
services displayed correspond to the services configured in the
firewall policy.
status=(detected) The action the FortiGate unit took.
hostname=(example.com) The home page of the web site.
url=(/image/trees_pine_for The URL address of the web page that the user was viewing.
est/)
msg=(data leak Explains the FortiGate activity that was recorded. In this example,
detected(Data Leak the data leak that was detected matched the rule, All-HTTP, in the
Prevention Rule matched) DLP sensor.
rulename=(All-HTTP) The name of the DLP rule within the DLP sensor.
action=(log-only) The action that was specified within the rule. In some rules within
sensors, you can specify content archiving. If no action type is
specified, this field display log-only.
severity=(1) The level of severity for that specific rule.
How the FortiGate unit records log messages

The FortiGate unit records log messages in a specific order, storing them on a log device.
The order of how the FortiGate unit records log messages is as follows:
1 Incoming traffic is scanned
2 During the scanning process, the FortiGate unit performs necessary actions, and
simultaneously are recorded
3 Log messages are sent to the log device
Example: How the FortiGate unit records a DLP event

1 The FortiGate unit receives incoming traffic and scans for any matches associated
within its firewall policies containing a DLP sensor.

576 01-420-99686-20101026
Logging overview Log management practices
2 A match is found; the DLP sensor, dlp_sensor, had a rule within it called All-HTTP with
the action Exempt applied to the rule. The sensor also has Enable Logging selected,
which indicates to the FortiGate unit that the activity should be recorded and placed in
the DLP log file.
3 The FortiGate unit exempts the match, and places the recorded activity (the log
message) within the DLP log file.
4 According to the log settings that were configured, logs are stored on the FortiGate
unit’s local hard drive. The FortiGate unit places the DLP log file on the local hard drive.
Log management practices

When the FortiGate unit records FortiGate activity, valuable information is collected that
provides insight into how to better protect network traffic against attacks, including misuse
and abuse. There is a lot to consider before enabling logging on a FortiGate unit, such as
what FortiGate activities to enable and which log device is best suited for your network’s
logging needs. A plan can help you in deciding the FortiGate activities to log, a log device,
as well as a backup solution in the event the log device fails.
This plan should provide you with an outline, similar to the following:
• what FortiGate activities you want and/or need logged (for example, DLP archives)
• the logging device best suited for your network
• if you want or require archival of log files
• ensuring logs are not lost in the event a failure occurs.
After the plan is implemented, you need to manage the logs and be prepared to expand on
your log setup when the current logging requirements are outgrown. Good log
management practices help you with these tasks.
Log management practices help you to improve and manage logging requirements.
Logging is an ever-expanding tool that can seem to be a daunting task to manage. The
following management practices will help you when issues arise, or your logging setup
needs to be expanded.
1 Revisit your plan on a yearly basis to verify that your logging needs are being met by
your current log setup. For example, your company or organization may require
archival logging, but not at the very beginning. Archival logs are stored on either a
FortiGate unit’s local hard drive, a FortiAnalyzer unit, or a FortiGuard Analysis server.
2 Configure an alert message that will notify you of activities that are important to be
aware about. For example, a branch office does not have a FortiGate administrator so
you need to know, at all times, that the IPSec VPN tunnel is up and running. An alert
email notification message can be configured for sending only IPSec tunnel errors.
3 If your organization or company uses peer-to-peer programs, such as Skype or other
instant messaging software, use the IM usage widget or the Executive Summary’s
report widget, Top 10 Application Bandwidth Usage Per Hour Summary, to help you
view the usage of these types of instant messaging software. These widgets can help
you in determining how these applications are being used, including if there is any
misuse and abuse. Their information is taken from application log messages; however,
application log messages should be viewed as well since they contain the most
detailed information.
4 Ensure that your backup solution is up-to-date. If you have recently expanded your log
setup, you should also review your backup solution. The backup solution provides a
way to ensure that all logs are not lost in the event that the log device fails or issues
arise with the log device itself.

01-420-99686-20101026 577
Log management practices Logging overview

578 01-420-99686-20101026
The SQL log database
FortiGate units with hard disks support local SQLite database for storing log tables. These
tables are used when gathering log information for reports. Reports require database
(which are part of charts) and SQL knowledge is required when configuring these
datasets. You can configure datasets or customize existing datasets using SQL
statements that will query the database. These statements are based on SQLite3.
This section explains how to create the statements for use in datasets. This section also
includes examples of SQL statements that you can use to base your own custom datasets
on.
If you require more information, see the technical note SQL Log Database Query, which
includes information about SQL on the FortiAnalyzer unit.
• SQL overview
• SQL tables
• SQL statement examples
• Troubleshooting SQL issues
SQL overview
The syntax for SQL queries is based on the SQLite3 syntax (see
http://www.sqlite.org/lang.html for more information).
There is an additional convenience macro, F_TIMESTAMP, that allows you to easily
specify a time interval for the query. It takes this form:
F_TIMESTAMP(base_timestring, unit, relative value). For example,
F_TIMESTAMP('now','hour','-23') means “last 24 hours” or that the hour in the
timestamp is 23 less than now. The FortiGate unit will automatically translate the macro
into SQLite3 syntax.
You can use the following CLI commands to write SQL statements to query the SQLite
database.
config report dataset
edit <dataset_name>
set query <sql_statement>
next
end
For more information about specific examples that are used in creating custom datasets,
see the “SQL statement examples” on page 580.
SQL tables
The FortiGate unit creates a database table for each log type, when log data is recorded. If
the FortiGate unit is not recording log data, it does not create log tables for that device.
The command syntax, get report database schema, allows you to view all the
tables, column names and types that are available to use when creating SQL statements
for datasets.

01-420-99686-20101026 579
SQL statement examples The SQL log database
SQL statement examples

The following examples help to explain SQL statements and how they are configured
within a dataset. Datasets contain SQL statements which are used to query the SQL
database.
Distribution of Applications by Type in the last 24 hours

This dataset is created to show the distribution of the type of applications that were used,
and will use the application control logs to get this information.
CLI commands
edit "appctrl.Dist.Type.last24h"
set query "select app_type, count(*) as totalnum from
app_control_log where timestamp >=
F_TIMESTAMP('now','hour','-23') and (app_type is not null
and app_type!='N/A') group by app_type order by totalnum
desc"
next
Explanation about the parts of the statement

• edit "appctrl.Dist.Type.last24h" - creates a new dataset with descriptive
title.
• F_TIMESTAMP('now','hour','-23') - the F_TIMESTAMP macro covers the last
24 hours (from now until 23 hours ago).
• The application control module classifies each firewall session in app_type. One
firewall session may be classified to multiple app_types. For example, an HTTP
session can be classified to: HTTP and Facebook, as well as others.
• Some app/app_types may not be able to detected, then the ‘app_type’ field may be
null or ‘N/A’. These will be ignored by this query.
• The result is ordered by the total session number of the same app_type. The most
frequent app_types will appear first.
Top 10 Application Bandwidth Usage Per Hour Summary

This dataset is created to show the bandwidth used by the top ten applications.
Application control logs are used to gather this information.
CLI commands
edit "appctrl.Count.Bandwidth.Top10.Apps.last24h"
set query "select (timestamp-timestamp%3600) as hourstamp,
(CASE WHEN app!=\'N/A\' and app!=\'\' then app ELSE service
END) as appname, sum(sent+rcvd) as bandwidth from
traffic_log where timestamp >=
F_TIMESTAMP(\'now\',\'hour\',\'-23\') and (appname in
(select (CASE WHEN app!=\'N/A\' and app!=\'\' then app ELSE
service END) as appname from traffic_log where timestamp >=
F_TIMESTAMP(\'now\',\'hour\',\'-23\') group by appname
order by sum(sent+rcvd) desc limit 10)) group by hourstamp,
appname order by hourstamp desc"

580 01-420-99686-20101026
The SQL log database Troubleshooting SQL issues
next
Explanation about the parts of the statement

• (timestamp-timestamp%3600) as hourstamp - this calculates an "hourstamp"
to indicate bandwidth per hour.
• (CASE WHEN app!=\'N/A\' and app!=\'\' then app ELSE service END)
as appname - use the app as 'appname', or if it's undefined, use the service instead.
• appname in (select (CASE WHEN app!=\'N/A\' and app!=\'\' then
app ELSE service END) as appname from traffic_log where
timestamp >= F_TIMESTAMP(\'now\',\'hour\',\'-23\') group by
appname order by sum(sent+rcvd) desc limit 10) - selects the top 10
apps using most bandwidth
• order by hourstamp desc - this orders the results by descending hourstamp
• LIMIT 10 - this lists only the top 10 applications.
Troubleshooting SQL issues

If the query is unsuccessful, an error message appears in the results window indicating
the cause of the problem. The following are issues that may arise when creating
statements for datasets that query the SQL database.
SQL statement syntax errors

Here are some example error messages and possible causes:
You have an error in your SQL syntax (remote/MySQL) or ERROR: syntax
error at or near... (local/PostgreSQL)
• Verify that the SQL keywords are spelled correctly, and that the query is well-formed.
• Table and column names are demarked by grave accent (`) characters. Single (') and
double (") quotation marks will cause an error.
No data is covered.
• The query is correctly formed, but no data has been logged for the log type. Verify that
you have configured the FortiGate unit to save that log type. On the Log Settings page,
make sure that the log type is checked.
Connection problems
If well formed queries do not produce results, and logging is turned on for the log type,
there may be a database configuration problem with the remote database.
Ensure that:
• MySQL is running and using the default port 3306.

01-420-99686-20101026 581
Troubleshooting SQL issues The SQL log database
• You have created an empty database and a user who has read/write permissions for
the database.
Here is an example of creating a new MySQL database named fazlogs, and adding a
user for the database:
#Mysql –u root –p
mysql> Create database fazlogs;
mysql> Grant all privileges on fazlogs.* to ‘fazlogger’@’*’
identified by ‘fazpassword’;
mysql> Grant all privileges on fazlogs.* to
‘fazlogger’@’localhost’ identified by ‘fazpassword’;
SQL database error

You may encounter the following error message (Figure 60) after upgrading or
downgrading the FortiGate unit’s firmware image.
Figure 60: Example of an SQL database error message that appears after logging in to the
web-based manager
The error message indicates that the SQL database is corrupted and cannot be updated
with the SQL schemas any more. When you see this error message, you can do one of
the following:
• select Cancel and back up all log files; then select Rebuild to rebuild the database
• select Rebuild only after verifying that all log files are backed up to a safe location.
When you select Cancel, no logging is recorded by the FortiGate unit regardless of the log
settings that are configured on the unit. When you select Rebuild, all logs are lost because
the SQL database is erased and then rebuilt again. Logging resumes after the SQL
database is rebuilt.
If you want to view the database’s errors, use the diag debug sqldb-error-read
command in the CLI. This command indicates exactly what errors occurred, and what
tables contain those errors.
Log files are backed up using the execute log backup {alllogs | logs}
command in the CLI. You must use the text variable when backing up log files because the
text variable allows you to view the log files outside the FortiGate unit. When you back up
log files, you are really just copying the log files from the database to a specified location,
such as a TFTP server.

582 01-420-99686-20101026
Log devices
The FortiGate unit supports a variety of logging devices, including the FortiGuard Analysis
server. This provides great flexibility when choosing a log device for the first time, as well
as when logging requirements change.
This section explains how to configure your chosen log device, as well as how to configure
multiple FortiAnalyzer units or Syslog servers. This section also includes how to log to a
FortiGuard Analysis server, which is available if you subscribed to the FortiGuard Analysis
and Management Service.
• Selecting a log device
• Example: Setting up a log device and backup solution
• Configuring the FortiGate unit to store logs on a log device
• Troubleshooting connectivity problems
Note: You may need to reschedule uploading or rolling of log files because the size of logs
files is reduced in FortiOS 4.0 MR1 and higher. Reduction in size provides more storage
room for large amounts of log files on log devices.
Selecting a log device

When you have developed a plan that meets your logging needs and requirements, you
need to select the log device that is appropriate for that plan. A log device must be able to
store all the logs you need, and if you require archiving those logs, you must consider
what log devices support this option.
During this process of deciding what log device meets your needs and requirements, you
must also figure out how to provide a backup solution in the event the log device that the
FortiGate unit is sending logs to has become unavailable. A backup solution should be an
important part of your log setup because it helps you to maintain all logs and prevents lost
logs, or logs that are not sent to the log device. For example, a daily backup of log files to
the FortiAnalyzer unit occurs at 5 pm.
Log devices provide a central location for storing logs recorded by the FortiGate unit. The
following are log devices that the FortiGate unit supports:
• FortiGate system memory
• Hard disk or AMC
• SQL database (for FortiGate units that have a hard disk)
• FortiAnalyzer unit
• FortiGuard Analysis server (part of the FortiGuard Analysis and Management Service)
• Syslog server
• NetIQ WebTrends server
These logs devices, except for the FortiGate system memory and local hard disk, can also
be used as a backup solution. For example, you configure logging to the FortiGate unit’s
local disk, but also configure logging to a FortiGuard Analysis server and archive logs to
both the FortiGuard Analysis server and a FortiAnalyzer unit.

01-420-99686-20101026 583
Selecting a log device Log devices
Example: Setting up a log device and backup solution

The following is an example of how to set up a log device and backup solution when you
are integrating them into your network. This example does not include how to enable
FortiGate activities for logging.
Your company has received a FortiAnalyzer unit and three new Syslog server software
licenses. You install the FortiAnalyzer unit in as stated in its install guide, and you also
install the Syslog server software on three servers.
To setup a log device and backup solution

1 On the FortiGate unit, go to Log&Report > Log Config > Log Settings.
2 Select the check box beside Remote Logging & Archiving.
3 Select the check box beside FortiAnalyzer.
4 Enter the FortiAnalyzer unit’s IP address in the IP Address field.
5 Select Information from the Minimum log level drop-down list.
6 Select the check box beside Buffer to hard disk and upload and then select the time
period when the FortiGate unit uploads the logs to the FortiAnalyzer unit.
7 Select Overwrite oldest logs from the When log disk is full drop-down list.
8 Select Apply.
9 Select Test Connectivity to verify that the connection between the two units is
successful.
11 Enter the following commands for the first Syslog server:
config log syslogd setting
set status enable
set server 192.168.16.121
set reliable enable
set csv enable
set facility local1
set source-ip
end
12 Enter the following for the second Syslog server:
config log syslogd2 setting
set status enable
set server 192.168.17.125
set reliable enable
set csv enable
set facility local2
set source-ip
end
13 Enter the following for the third Syslog server:
set status enable
set server 192.168.16.121
set reliable enable
set csv enable
set facility local3
set source-ip
end

584 01-420-99686-20101026
Log devices Configuring the FortiGate unit to store logs on a log device
Figure 61: Example of an integrated FortiAnalyzer unit and Syslog servers in a network
Syslog servers
FortiAnalyzer 1U
Internal Network
FortiGate 1U
Configuring the FortiGate unit to store logs on a log device

After setting up and integrating your log device into the network, you can now configure
the log device’s settings for logging FortiGate activities. If you have multiple FortiAnalyzer
units or Syslog servers, you must configure them in the CLI. For more information, see
“Logging to multiple FortiAnalyzer units or Syslog servers” on page 591.
• Logging to the FortiGate unit’s system memory
• Logging to the FortiGate unit’s hard disk
• Logging to a FortiAnalyzer unit
• Logging to a FortiGuard Analysis server
• Logging to a Syslog server
• Logging to a WebTrends server
Logging to the FortiGate unit’s system memory

The FortiGate system memory can store most log messages, except for archives.
Archived logs are stored on a FortiGate unit’s hard disk, FortiAnalyzer unit, or FortiGuard
Analysis server.
The system memory displays recent log entries and stores most log types, including traffic
logs. The FortiGate system memory cannot store archive logs because of their size. When
the system memory is full, the FortiGate unit overwrites the oldest messages. All log
entries stored in system memory are cleared when the FortiGate unit restarts.
To configure the FortiGate unit to save logs in memory- web-based manager

2 Expand Local Logging & Archiving.
3 Select the check box beside Memory.

01-420-99686-20101026 585
Configuring the FortiGate unit to store logs on a log device Log devices
4 Select a log level from the Minimum log level drop-down list.
5 To enable logging of IPS packet archives, select the check box beside Enable IPS
Packet Archive.
6 Select Apply.
The FortiGate unit logs all messages at and above the logging severity level you select.
To configure the FortiGate unit to save logs in memory - CLI

2 Enter the following command syntax:
set diskfull <overwrite>
set ips-archive {enable | disable}
end
Logging to the FortiGate unit’s hard disk

If your FortiGate unit contains a hard disk, you can configure the FortiGate unit to store
logs on the disk. You can configure logging to the FortiGate unit’s hard disk from
Log&Report > Log Config > Log Settings. When you are configuring to log to a hard disk,
you can also configure a schedule to upload those logs to either a FortiAnalyzer unit, if the
hard disk is AMC.
To log to the hard disk on a FortiGate unit - web-based manager

1 Go to Log&Report > Log Config > Log Settings.
2 Expand Local Logging & Archiving to reveal the available options.
3 Select the check box beside Disk.
5 Select an action the FortiGate unit will take when the log disk is full from the When log
disk is full drop-down list.
6 To enable archiving of either DLP or IPS packet archives, (or both), select the check
box beside Enable DLP Archive for DLP archiving, or select the check box beside
Enable IPS Packet Archive.
If you do not select the check box beside Enable DLP Archive, no logs will be archived,
even if you have applied the DLP archive sensor to a firewall policy.
7 To enable SQL logging, select the log types that you want to log.
To log to the hard disk on a FortiGate unit - CLI

config log disk setting
set status enable
end
Use the config log disk filter command to disable the FortiGate features you do
not want to log. By default, most FortiGate features are enabled in the config log
disk filter command.
To log to an AMC hard disk and schedule uploading of logs to a FortiAnalyzer unit

586 01-420-99686-20101026
2 Enter the following command syntax. You need to choose fortianalyzer as the
destination for uploading files to:
config log disk setting
set upload {enable | disable}
set upload-destination {ftp-server | fortianalyzer}
set uploadip <class_ip>
set uploadtype {app-crtl | attack | dlp | dlp-archive | event
| spamfilter | traffic | virus | webfilter}
set uploadsched {enable | disable}
set uploadtime <time_integer>
end
Logging to a FortiAnalyzer unit

A FortiAnalyzer unit can log all FortiGate features that are available for logging, including
DLP archiving. The following procedure assumes that you have only one FortiAnalyzer
unit to configure. If you are configuring more than one, you must configuring the other
FortiAnalyzer units in the CLI. Use the procedures in “Configuring multiple FortiAnalyzer
units” on page 591 to configure multiple FortiAnalyzer units.
To send logs to a FortiAnalyzer unit - web-based manager

2 Expand Remote Logging & Archiving to reveal the available options.
3 Select the check box beside FortiAnalyzer.
When you select the check box beside FortiAnalyzer, the options for configuring your
FortiGate unit to send logs to a FortiAnalyzer unit, display.
4 In the IP Address field, enter either the IP address of the FortiAnalyzer unit.
6 To buffer the hard disk and schedule an upload of logs, select the check box beside
Buffer to hard disk and upload, select either Daily or Weekly from the drop-down list,
and then enter the time in hours and minutes.
7 If you selected Weekly, select the check box or boxes beside the days of the week.
8 Select Apply.
You must enable the gui-display command in the CLI to show the submenus for
Report Config and Report Access. These menus and their submenus are hidden by
default on the web-based manager.
To send logs to a FortiAnalyzer unit - CLI

set server <ip_address>
set use-hdd {enable | disable}
set roll-schedul {daily | weekly}
set roll-time <hh:mm>
set diskfull {nolog | overwrite}
end

01-420-99686-20101026 587
Testing the FortiAnalyzer configuration

After configuring FortiAnalyzer settings, you can test the connection between the
FortiGate unit and the FortiAnalyzer unit to ensure the connection is working properly. This
enables you to view the connection settings between the FortiGate unit and the
FortiAnalyzer unit.
To test the connection

2 Expand Remote Logging & Archiving, if not already expanded.
3 In the IP Address field row, select Test Connectivity.
When you select Test Connectivity, a window appears with general information about
the FortiAnalyzer unit, disk space available and used on the FortiAnalyzer unit, as well
as privileges that the FortiGate unit while connected to the FortiAnalyzer unit.
4 Select Close when you are done viewing the connection status and general
information.
Connecting to a FortiAnalyzer unit using Automatic Discovery

Automatic Discovery is a method of establishing a connection to a FortiAnalyzer unit by
using the FortiGate unit to find a FortiAnalyzer unit on the network. The Fortinet Discovery
Protocol (FDP) is used to locate the FortiAnalyzer unit. Both units must be on the same
subnet to use FDP, and they must also be able to connect using UDP.
When you select Automatic Discovery, the FortiGate unit uses HELLO packets to locate
any FortiAnalyzer units that are available on the network within the same subnet. When
the FortiGate unit discovers the FortiAnalyzer unit, the FortiGate unit automatically
enables logging to the FortiAnalyzer unit and begins sending log data.
To connect using automatic discovery

set gui-display {enable | disable}
set address-mode auto-discovery
end
If your FortiGate unit is in Transparent mode, the interface using the automatic discovery
feature will not carry traffic. For more information about how to enable the interface to also
carry traffic when using the automatic discovery feature, see the Fortinet Knowledge Base
article, Fortinet Discovery Protocol in Transparent mode.
Note: The FortiGate unit searches within the same subnet for a response from any
available FortiAnalyzer units.
Logging to a FortiGuard Analysis server

You can configure logging to a FortiGuard Analysis server after registering for the
FortiGuard Analysis and Management Service. The following procedure assumes that you
have already configured the service account ID in System > Maintenance > FortiGuard.

588 01-420-99686-20101026
To log to a FortiGuard Analysis server - web-based manager

2 Expand Remote Logging & Archiving to reveal the available options.
3 Select the check box beside FortiGuard Analysis & Management Service.
4 Enter the account ID in the Account ID field.
5 Select one of the following:
Overwrite oldest logs Deletes the oldest log entry and continues logging when the
maximum log disk space is reached.
Do not log Stops log messages going to the FortiGuard Analysis server when
the maximum log disk space is reached.
6 Select a severity level.

7 Select Apply.
To log to a FortiGuard Analysis server - CLI

config log fortiguard setting
set quotafull {nolog | overwrite}
end
Logging to a Syslog server

The Syslog server is a remote computer running syslog software. Syslog is a standard for
forwarding log messages in an IP network. Syslog servers capture log information
provided by network devices.
The following procedure configures one Syslog server. You can configure up to three
Syslog servers. Use the procedure in “Configuring multiple Syslog servers” on page 592 to
configure multiple Syslog servers.
To send logs to a syslog server - web-based manager

2 Select the check box beside Syslog.
After you select the check box, the Syslog options appear.
3 Enter the appropriate information for the following:
IP/FDQN Enter the domain name or IP address of the syslog server.
Port Enter the port number for communication with the syslog
server, usually port 514.
Minimum log level Select a log level the FortiGate unit will log all messages at and
above that logging severity level.
Facility Facility indicates to the syslog server the source of a log
message. By default, the FortiGate reports facility as local7.
You can change the Facility if you want to distinguish log
messages from different FortiGate units.
Enable CSV Format Select to have logs formatted in CSV format. When you enable
CSV format, the FortiGate unit produces the log in Comma
Separated Value (CSV) format. If you do not enable CSV
format, the FortiGate unit produces plain text files.
4 Select Apply.

01-420-99686-20101026 589
To log to a Syslog server - CLI

set server <address_ipv4>
set port <port_integer>
set csv {enable | disable}
set facility {alert | audit | auth | authpriv | clock | cron
| daemon | ftp | kernel | local0 | local1 | local2 |
local3 | local4 | local5 | local6 | local7 | lpr | mail |
news | ntp | syslog | user | uucp}
end
Enabling reliable syslog

The reliable syslog feature is based on RFC 3195. Reliable syslog logging uses TCP,
which ensures that connections are set up, including packets transmitted.
There are several profiles available for reliable syslog, but only the RAW profile is
currently supported on the FortiGate unit. The RAW profile is designed to provide a high-
performance, low-impact footprint using essentially the same format as the existing UDP-
based syslog service. The reliable syslog feature is available on FortiGate units running
FortiOS 4.0 MR1 or higher.
When you enable reliable syslog in the CLI, TCP is used. The default setting, disable,
uses UDP. TCP ensures that packets are transmitted easily, as well as connections are set
up.
The following procedure assumes that you have already configured the Syslog server.
To enable reliable syslog

set status enable
set reliable enable
end
Logging to a WebTrends server

A WebTrends server is a remote computer, similar to a Syslog server, running NetIQ
WebTrends firewall reporting server. FortiGate log formats comply with WebTrends
Enhanced Log Format (WELF) and are compatible with NetIQ WebTrends Security
Reporting Center and Firewall Suite 4.1.
To send logs to a WebTrends server, log in to the CLI and enter the following commands:
config log webtrends setting
set server <address_ip4>
end
Example
This example shows how to enable logging to and set an IP address for a remote NetIQ
WebTrends server.

590 01-420-99686-20101026
config log webtrends settings

set status enable
set server 172.25.82.145
end
Logging to multiple FortiAnalyzer units or Syslog servers

FortiOS 4.0 allows you to configure multiple FortiAnalyzer units or multiple Syslog servers,
ensuring that all logs are not lost in the event one of them fails.
You can configure multiple FortiAnalyzer units or Syslog servers within the CLI.
• Configuring multiple FortiAnalyzer units
• Configuring multiple Syslog servers
• Example of configuring multiple FortiAnalyzer units
Configuring multiple FortiAnalyzer units

Fortinet recommends that you contact a FortiAnalyzer administrator first, to verify that the
IP addresses of the FortiAnalyzer units you want to send logs to are correct and that all
FortiAnalyzer units are currently installed with FortiAnalyzer 4.0 firmware.
If VDOMs are enabled, you can configure multiple FortiAnalyzer units or Syslog servers
for each VDOM.
The following procedure does not contain how to enable logging of FortiGate features
within the CLI. Most FortiGate features are, by default, enabled within the log filter
command in the CLI. You should disable the FortiGate features that you do not want
logged within the log filter command.
To enable logging to multiple FortiAnalyzer units

2 Enter the following commands, using encrypt and psksecret if you want to encrypt
the connection:
set status enable
set server <faz_ip address>
set encrypt [disable | enable]
set psksecret <password>
set localid <identification_ipsectunnel>
set conn-timeout <value_seconds>
end
3 Enter the following commands for the second FortiAnalyzer unit, using encrypt and
psksecret if you want to encrypt the connection:
config log fortianalyzer2 setting
set server <fortianalyzer_ipv4>
set ver-1 {disable | enable}
end

01-420-99686-20101026 591
4 Enter the following commands for the last FortiAnalyzer unit, using encrypt and
psksecret if you want to encrypt the connection:
set status enable
set server <faz_ip address>
end
Configuring multiple Syslog servers

When configuring multiple Syslog servers (or one Syslog server), you can configure
reliable delivery of log messages from the Syslog server. Configuring of reliable delivery is
available only in the CLI.
If VDOMs are enabled, you can configure multiple FortiAnalyzer units or Syslog servers
for each VDOM.
The following procedure does not contain how to enable logging of FortiGate features
within the CLI. Most FortiGate features are, by default, enabled within the log filter
command in the CLI. You should disable the FortiGate features that you do not want
logged within the log filter command.
To enable logging to multiple Syslog servers

2 Enter the following commands:
set csv {disable | enable}
set facility <facility_name>
set reliable {disable | enable}
end
3 Enter the following commands to configure the second third Syslog server:
end
4 Enter the following commands to configure the third Syslog server:
end

592 01-420-99686-20101026
Example of configuring multiple FortiAnalyzer units

The IT department at your organization’s headquarters discovers that their one and only
FortiAnalyzer unit is not working properly; however, it is soon up and running again. When
it is working properly again, your department’s managers realize that two day’s worth of
logs are lost. Your IT manager asks you to install and configure two FortiAnalyzer units
onto the network so that logs are not lost again.
In this example, you have already installed and configured the two FortiAnalyzer units and
are now ready to configure sending logs from the FortiGate unit to the two FortiAnalyzer
units.
The three units are named as follows: FortiAnalyzer_Main (main log storage unit),
FortiAnalyzer_1 (first back up), and FortiAnalyzer_2 (second back up).
To configure logging to multiple FortiAnalyzer units

1 Verify that FortiAnalyzer_Main configuration is correct and communication between the
FortiGate unit and FortiAnalyzer_Main is working properly.
You can do this by using Test Connectivity from the FortiGate unit. See “Testing the
FortiAnalyzer configuration” on page 588.
2 Go to System > Dashboard > Status and locate the CLI console widget.
3 Log in to the CLI using the CLI Console widget on the Status page.
4 Enter the following command syntax for FortiAnalyzer_1:
set status enable
set server 10.10.20.125
set encrypt enable
set psksecret it123456
set localid ipsec_vpn1
set conn-timeout 1200
set max-buffer-size 800
end
5 Enter the following command syntax for FortiAnalyzer_2:
set status enable
set server 10.10.22.120
set encrypt enable
set psksecret it123456
set localid ipsec_vpn1
set conn-timeout 1200
set max-buffer-size 800
end
6 Enter the following command syntax to log the FortiGate features:
config log fortianalyzer2 filter
get log fortianalyzer filter
The get log fortianalyzer filter displays the FortiGate features that are
enabled by default.
7 Enter the following variables to disable the four FortiGate features that you do not
want:
set wanopt-traffic disable
set netscan disable
set vulnerability disable

01-420-99686-20101026 593
Troubleshooting connectivity problems Log devices
end
8 Repeat steps 6 and 7 for FortiAnalyzer_2.
Logs are now configured to go to multiple FortiAnalyzer units.
Troubleshooting connectivity problems

You may experience, at one time or another, connection problems between the FortiGate
unit and the log device. You can use the diag debug flow command in the CLI to verify
what connection problems are occurring.

594 01-420-99686-20101026
Logging FortiGate activity
The FortiGate unit, depending on its configuration, can have a lot of network activity
flowing through it. The FortiGate unit provides settings to record the activity, referred to in
this document as log settings.
This section explains the FortiGate activity that can be logged, as well as how to log
FortiGate activity. This section includes how to configure an alert notification email,
filtering and customizing the display of logs messages on the web-based manager, as well
as viewing quarantined files.
• Logs
• Configuring logging of FortiGate activity on your FortiGate unit
• Viewing log messages and quarantine files
• Customizing the display of log messages
• Alert email messages
Logs
Logs record FortiGate activity, providing detailed information about what is happening on
your network. This recorded activity is found in log files, which are stored on a log device.
However, logging FortiGate activity requires configuring certain settings so that the
FortiGate unit can record the activity. These settings are often referred to as log settings,
and are found in most UTM features, such as profiles, and include the event log settings,
found on the Event Log page.
Log settings provide the information that the FortiGate unit needs so that it knows what
activities to record. This topic explains what activity each log file records, as well as
additional information about the log file, which will help you determine what FortiGate
activity the FortiGate unit should record.
• Traffic
• Event
• Data Leak Prevention
• Application control
• Antivirus
• Web Filter
• IPS (attack)
• Packet logs
• Email filter
• Archives (DLP)
• Network scan

01-420-99686-20101026 595
Logs Logging FortiGate activity
Traffic
Traffic logs record the traffic that is flowing through your FortiGate unit. Since traffic needs
firewall policies to properly flow through the unit, this type of logging is also referred to as
firewall policy logging. Firewall policies control all traffic that attempts to pass through the
FortiGate unit, between FortiGate interfaces, zones and VLAN sub-interfaces.
Logging traffic works in the following way:
• firewall policy has logging enabled on it (Log Allowed Traffic or Log Violation Traffic)
• packet comes into an inbound interface
• a possible log packet is sent regarding a match in the firewall policy, such as URL filter
• traffic log packet is sent, per firewall policy
• packet passes and is sent out an interface
Traffic log messages are stored in the traffic log file. Traffic logs can be stored any log
device, even system memory.
Other Traffic
The traffic log also records interface traffic logging, which is referred to as other traffic.
Other traffic is enabled only in the CLI. When enabled, the FortiGate unit records traffic
activity on interfaces as well as firewall policies. Logging other traffic puts a significant
system load on the FortiGate unit and should be used only when necessary.
Logging other traffic works in the following way:
• firewall policy has logging enabled on it (Log Allowed Traffic or Log Violation Traffic)
and other-traffic
• packet comes into an interface
• interface log packet is sent to the traffic log that is enabled on that particular interface
• possible log packet is sent regarding a match in the firewall policy, such as URL filter
• interface log packet is sent to the traffic log if enabled on that particular interface
• packet passes and is sent out an interface
• interface log packet is sent to traffic (if enabled) on that particular interface
Event
The event log records administration management as well as FortiGate system activity,
such as when a configuration has changed, admin login, or high availability (HA) events
occur. Event logs are an important log file to record because they record FortiGate system
activity, which provides valuable information about how your FortiGate unit is performing.
Event logs help you in the following ways:
• keep track of configuration setting changes
• IPsec negotiation, SSL VPN and tunnel activity
• quarantine events, such as banned users
• system performance
• HA events and alerts
• firewall authentication events
• wireless events on models with WiFi capabilities
• activities concerning modem and internet protocols L2TP, PPP and PPPoE
• VIP activities

596 01-420-99686-20101026
Logging FortiGate activity Logs
• AMC disk’s bypass mode

• VoIP activities that include SIP and SCCP protocols.
The FortiGate unit records event logs only when events are enabled.
Data Leak Prevention

Data Leak Prevention logs, or DLP logs, provide valuable information about the sensitive
data trying to get through to your network as well as any unwanted data trying to get into
your network. The DLP rules within a DLP sensor can log the following traffic types:
• email (SMTP, POP3 or IMAP; if SSL content SMTPS, POP3S, and IMAPS)
• HTTP
• HTTPS
• FTP
• NNTP
• IM
A DLP sensor must have log settings enabled for each DLP rule and compound rule, as
well as applied to a firewall policy so that the FortiGate unit records this type of activity. A
DLP sensor can also contain archiving options, which these logs are then archived to the
log device.
NAC Quarantine
Within the DLP sensor, there is an option for enabling NAC Quarantine. The NAC
Quarantine option allows the FortiGate unit to record details of DLP operation that involve
the ban and quarantine actions, and sends these to the event log file. The NAC
Quarantine option must also be enabled within the Event Log settings.
Application control
Application control logs provide detailed information about the traffic that an application is
generating, such as Skype. The application control feature controls the flow of traffic from
a specific application, and the FortiGate unit examines this traffic for signatures that the
application generates.
The log messages that are recorded provide information such as the type of application
being used (for example P2P software), and what type of action the FortiGate unit took.
These log messages can also help you to determine the top ten applications that are
being used on your network. This feature is called application control monitoring and you
can view the information from a widget on the Executive Summary page.
The application control list that is used must have Enabled Logging selected within the list,
as well as logging enabled within each application entry. Each application entry can also
have packet logging enabled. Packet logging for application control records the packet
when an application type is identified, similar to IPS packet logging.
Logging of application control activity can only be recorded when an application control list
is applied to a firewall policy, regardless of whether or not logging is enabled within the
application control list.

01-420-99686-20101026 597
Logs Logging FortiGate activity
Antivirus
Antivirus logs are recorded when, during the antivirus scanning process, the FortiGate unit
finds a match within the antivirus profile, which includes the presence of a virus or
grayware signature. Antivirus logs provide a way to understand what viruses are trying to
get in, as well as additional information about the virus itself, without having to go to the
FortiGuard Center and do a search for the detected virus. The link is provided within the
log message itself.
These logs provide valuable information about:
• name of the detected virus
• name of the oversized file or infected file
• action the FortiGate unit took, for example, a file was blocked
• URL link to the FortiGuard Center which gives detailed information about the virus itself
The antivirus profile must have log settings enabled within it so that the FortiGate unit can
record this activity, as well as having the antivirus profile applied to a firewall policy.
Web Filter
Web filter logs record HTTP traffic activity. These log messages provide valuable and
detailed information about this particular traffic activity on your network. Web filtering
activity is important to log because it can inform you about:
• what types of web sites are employees accessing
• if users try to access a banned web site and how often this occurs
• network congestion due to employees accessing the Internet at the same time
• alerts you to web-based threats when users surf non-business-related web sites
Web Filter logs are an effective tool to help you determine if you need to update your web
filtering settings within a web filter profile due to unforeseen web-based threats, or network
congestion. These logs also inform you about web filtering quotas that were configured for
filtering HTTP traffic as well.
You must configure log settings within the web filter profile as well as apply it to a firewall
policy so that the FortiGate unit can record web filter logs.
IPS (attack)
IPS logs, also referred to as attack logs, record attacks that occurred against your
network. Attack logs contain detailed information about whether the FortiGate unit
protected the network using anomaly-based defense settings or signature-based defense
settings, as well as what the attack was.
The IPS or attack log file is especially useful because the log messages that are recorded
contain a link to the FortiGuard Center, where you can find more information about the
attack. This is similar to antivirus logs, where a link to the FortiGuard Center is provided as
well and informs you of the virus that was detected by the FortiGate unit.
An IPS sensor with log settings enabled must be applied to a firewall policy so that the
FortiGate unit can record the activity.

598 01-420-99686-20101026
Logging FortiGate activity Configuring logging of FortiGate activity on your FortiGate unit
Packet logs
When you enable packet logging within an IPS signature override or filter, the FortiGate
unit examines network packets, and if a match is found, saves them to the attack log.
Packet logging is designed to be used as a diagnostic tool that can focus on a narrow
scope of diagnostics, rather than a log that informs you of what is occurring on your
network.
You should use caution when enabling packet logging, especially within IPS filters. Filter
configuration that contains thousands of signatures could potentially cause a flood of
saved packets, which would take up a lot of storage space on the log device. This would
also take a great deal of time to sort through all the log messages, as well as consume
considerable system resources to process.
You can archive packets, however, you must enable this option on the Log Setting page. If
your log configuration includes multiple FortiAnalyzer units, packet logs are only sent to
the primary, or first FortiAnalyzer unit. Sending packet logs to the other FortiAnalyzer units
is not supported.
Email filter
Email filter logs, also referred to as spam filter logs, records information regarding the
content within email messages. For example, within an email filter profile, a match is found
that finds the email message to be considered spam.
Email filter logs are recorded when the FortiGate unit finds a match within the email filter
profile and logging settings are enabled within the profile.
Archives (DLP)
Recording DLP logs for network use is called DLP archiving. The DLP engine examines
email, FTP, IM, NNTP, and web traffic. Archived logs are usually saved for historical use
and can be accessed at any time. IPS packet logs can also be archived, within the Log
Settings page.
You can use the two default DLP sensors that were configured specifically for archiving
log data, Content_Archive and Content_Summary. They are available in UTM > Data Leak
Prevention > Sensor. Content_Archive provides full content archiving, while
Content_Summary provides summary archiving.
You must enable the setting Enable DLP Archive in Log&Report > Log Config > Log
Setting to log archives. Logs are not archived unless this setting is enabled, regardless of
whether or not the DLP sensor for archiving is applied to the firewall policy.
Network scan
Network scan logs are recorded when a scheduled scan of the network occurs. These log
messages provide detailed information about the network’s vulnerabilities regarding
software as well as the discovery of any vulnerabilities.
A scheduled scan must be configured, as well as logging enabled within the Event Log
settings, for the FortiGate unit to record these log messages.
Configuring logging of FortiGate activity on your FortiGate unit

There are many FortiGate activities that you can enable logging for on your FortiGate unit.
Most are configured in the UTM menu; however, there are some activities that require
configuration from other locations. For example, enabling events is done from Log&Report
> Log Config > Event Log.

01-420-99686-20101026 599
Configuring logging of FortiGate activity on your FortiGate unit Logging FortiGate activity
When you are ready to enable logging of the FortiGate activities you have chosen, you
must apply them to a firewall policy. When applied to a firewall policy, the FortiGate unit
determines whether to record the activity or event based on what is applied on the firewall
policy and configured within the Log Config page.
The following explains how to enable and configure logging on your FortiGate unit.
• Enabling logging within a firewall policy
• Enabling logging of events
• Configuring logging for the application control monitoring feature
• Configuring IPS packet logging
• Configuring NAC quarantine logging
Enabling logging within a firewall policy

You must enable logging within a firewall policy, as well as the options that are applied to a
firewall policy, such as UTM features. Event logs are enabled within the Event Log page.
To enable logging within an existing firewall policy

2 Expand to reveal the policy list of a policy.
3 Select the firewall policy you want to enable logging on and then select Edit.
4 To log all general firewall policy traffic, select the check box beside Log Allowed Traffic.
5 On the firewall policy’s page, select the check box beside UTM.
6 Select the protocol option list from the drop-down list beside Protocol Options.
By default, the Protocol Options check box is selected. You must choose a list from the
drop-down list.
7 For each row under UTM, select the check box beside each of the profiles and/or
sensors that you want applied to the policy; then select the profile or sensor from the
drop-down list as well.
8 To apply other options, such as application lists, repeat step 7 and choose the option
from the drop-down list.
9 Select OK.
Note: You need to set the logging severity level to Notification when configuring a logging
location to record traffic log messages.
Enabling logging of events

The event log records management and activity events, such as when a configuration has
changed, admin login, or high availability (HA) events occur.
When you are logged in to VDOMs, certain options may not be available, such as VIP ssl
event or CPU and memory usage events. You can enable event logs only when you are
logged in to a VDOM; you cannot enable event logs in the root VDOM.
To enable the event logs

2 Select the check box, Enable.

600 01-420-99686-20101026
Logging FortiGate activity Configuring logging of FortiGate activity on your FortiGate unit
3 Select one or more of the following:

System activity All system-related events, such as ping server failure and gateway
event status.
IPSec negotiation All IPSec negotiation events, such as process and error reports.
event
DHCP service event All DHCP-events, such as the request and response log.
L2TP/PPTP/PPPoE All protocol-related events, such as manager and socket create
service event processes.
HA activity event All high availability events, such as link, member, and stat
information.
Wireless activity All wireless controller activities, such as Rogue AP.
event
Firewall All firewall-related events, such as user authentication.
authentication event
AMC interface bypass All AMC interface bypass mode events that occur.
mode event
SSL VPN user All administrator events related to SSL VPN, such as SSL
authentication event configuration and CA certificate loading and removal.
SSL VPN All administration events related to SSL VPN, such as SSL
administration event configuration and CA certificate loading and removal.
SSL VPN session All session activity such as application launches and blocks,
event timeouts, verifications and so on.
VIP ssl event All server-load balancing events that are happening during SSL
session, especially details about handshaking.
VIP server health All related VIP server health monitor events that occur when the
monitor event VIP health monitor is configured, such as an interface failure.
CPU & memory usage Real-time CPU and memory events only, at 5-minute intervals.
(every 5 min)
VoIP event All VoIP activity, such as SIP and SCCP violations.
NAC Quarantine All endpoint activity that have quarantined hosts when Endpoint
event NAC is checking hosts.
4 Select Apply.
5 Select OK.
Configuring logging for the application control monitoring feature

You may want to monitor application control activities, such as finding out what
applications are being used the most. The application control list provides an option that
monitors the applications that are being used on your network.
To configure application control monitoring

2 Select the application control list that you want to enable monitoring on, and then
select Edit.
3 Select the check box beside Enable Monitoring.
4 If not already selected, select the check box beside Enable Logging.
You must have both Enable Monitoring and Enable Logging, as well as applying the
application control list to the firewall policy for the FortiGate unit to monitor
applications.

01-420-99686-20101026 601
Configuring logging of FortiGate activity on your FortiGate unit Logging FortiGate activity

6 Select +Add Widget.
7 In the Add New Widget to Report Summary window, add the widget
appctrl.Count.Bandwidth.Top10.Apps.last24h(Graph) and configure the rest of the
settings to how you what the widget to display the information.
8 Select OK.
As the FortiGate unit records application control log messages, the information it
records is displayed within the graph.
Configuring IPS packet logging

IPS packet log messages are recorded in the attack log file. You must enable packet
logging within the IPS sensor’s filter itself because the FortiGate unit will not log the IPS
packets with only logging enabled within the IPS sensor or the filter itself.
To configure IPS packet logging

1 Go to UTM > Intrusion Protection > IPS Sensor.
2 Select the IPS sensor that you want to enable IPS packet logging on, and then select
Edit.
3 Within the sensor, select the filter to enable IPS packet logging for and then select Edit.
4 In Signature Settings, select Enable all for Packet Logging.
5 Select OK.
6 Repeat steps 3 to 5 for each filter that you want IPS packet logging enabled for.
Configuring NAC quarantine logging

NAC quarantine logging is enabled within the Event Log settings page. However, you
must have a NAC profile applied to a firewall policy for the FortiGate unit to record these
log messages.
To configure NAC quarantine logging

2 If not enabled, select the check box beside Enable.
3 If not already enabled, select NAC Quarantine event.
4 Select Apply.
6 Select the firewall policy that you want to apply the NAC profile to, and then select Edit.
7 Within the UTM section, select the check box beside Enable Endpoint NAC and then
select the endpoint profile from the drop-down list.
8 To add a disclaimer, select the check box beside Enable Disclaimer, and then enter the
comment in the Comments (maximum 63 characters) field.
9 Select OK.

602 01-420-99686-20101026
Logging FortiGate activity Viewing log messages and quarantine files
Viewing log messages and quarantine files

When accessing log messages from a log device, such as the FortiAnalyzer unit, you can
view each log message from a table within the page. The table, which appears on the right
side of the page that contains log messages, provides a more clear view of each of the
fields that are within a log message. The table provides next and previous arrows, allowing
you to view each log message from the table.
This table appears when you select a row within the log messages’ page and is available
until you close the table.
If you want to view log messages in their Raw format, select Raw at the top of the page.
Raw format displays the log message as it would appear in the log file.
Note: When viewing log messages in the Raw format in Memory, the ten-digit log ID
number is used; however, when viewing the same log messages, in Raw format, in Disk,
the five-digit log ID number is used (except for traffic logs which have only one-digit log
IDs). This five-digit log identification number is used because of log size reduction that
occurred in FortiOS 4.0 MR1.
To view log messages using the log table

1 Go to Log&Report > Log Access.
2 Select the submenu that you want to access logs from.
For example, the Log Access > DLP.
3 From within the page, select inside the row of the log message that you want to view.
The log message row is highlighted and the log table appears, located on the right side
of the page.
4 To close the table, select Close.
5 To view the next log message from the table, select the next arrow, and to view a
previous log message from the table, select the previous arrow.
You do not have to view log messages from only the web-based manager. You can view
log messages from the CLI as well using the execute log display command. This
command allows you to see specific log messages that you already configured within the
execute log filter command. The execute log filter command configures what log
messages you will see, how many log messages you can view at one time (a maximum of
1000 lines of log messages), and the type of log messages you can view. For example,
log messages from the DLP log file.
To view log messages from the CLI

1 Enter the following to configure how the log messages will be displayed, as well as
what log messages you want to display:
execute log filter category <category_number>
execute log filter start-line <line_number>
execute log filter view-lines <lines_per_view>
2 Enter the following to display the logs messages within the CLI:
execute log display
3 Log messages appear and stop when the maximum number of view-lines is reached.
The following is an example of viewing DLP log messages from the CLI.
To view log messages from the CLI - example

1 Enter the following to configure the display of the DLP log messages:

01-420-99686-20101026 603
Viewing log messages and quarantine files Logging FortiGate activity
execute log filter category 9

execute log filter start-line 1
execute log filter view-lines 20
2 Enter the following to view DLP log messages:
execute log display
600 logs found
20 logs returned
The first 20 log messages from the DLP log file display.
Viewing quarantined files

You can view quarantined files from Log&Report > Archive Access > Quarantine Files.
You can also search through these files to find a specific quarantined file, or filter the
information you are currently viewing.
You must configure quarantine settings with UTM > Antivirus > Quarantine, before you can
view quarantine logs. For more information about quarantined files, see the UTM chapter
of the FortiOS Handbook.
The Quarantine page allows you to filter the information on the page as well as remove
files from the list.
Quarantine page
Lists all files that are considered quarantined by the FortiGate unit. On this page you can filter
information so that only specific files are displayed on the page.
Source Either FortiAnalyzer or Hard disk, depending where you configure to
quarantined files to be stored.
Sort by Sort the list. Choose from: Status, Service, File Name, Date, TTL, or Duplicate
Count. Select Apply to complete the sort.
Filter Filter the list. Choose either Status (infected, blocked, or heuristics) or Service
(IMAP, POP3, SMTP, FTP, HTTP, MM1, MM3, MM4, MM7, IM, or NNTP). Select
Apply to complete the filtering. Heuristics mode is configurable through the CLI
only.
If your FortiGate unit supports SSL content scanning and inspection service can
also be IMAPS, POP3S, SMTPS, or HTTPS. For more information, see the
UTM chapter of the FortiOS Handbook.
Apply Select to apply the sorting and filtering selections to the list of quarantined files.
Delete Select to delete the selected files.
Page Controls Use the controls to page through the list.
Remove All Removes all quarantined files from the local hard disk.
Entries This icon only appears when the files are quarantined to the hard disk.
File Name The file name of the quarantined file.
Date The date and time the file was quarantined, in the format dd/mm/yyyy hh:mm.
This value indicates the time that the first file was quarantined if duplicates are
quarantined.
Service The service from which the file was quarantined (HTTP, FTP, IMAP, POP3,
SMTP, MM1, MM3, MM4, MM7, IM, NNTP, IMAPS, POP3S, SMTPS, or
HTTPS).
Status The reason the file was quarantined: infected, heuristics, or blocked.
Status Specific information related to the status, for example, “File is infected with
Description “W32/Klez.h”” or “File was stopped by file block pattern.”
DC Duplicate count. A count of how many duplicates of the same file were
quarantined. A rapidly increasing number can indicate a virus outbreak.

604 01-420-99686-20101026
Logging FortiGate activity Customizing the display of log messages
TTL Time to live in the format hh:mm. When the TTL elapses, the FortiGate unit
labels the file as EXP under the TTL heading. In the case of duplicate files, each
duplicate found refreshes the TTL.
The TTL information is not available if the files are quarantined on a
FortiAnalyzer unit.
Upload status Y indicates the file has been uploaded to Fortinet for analysis, N indicates the
file has not been uploaded.
This option is available only if the FortiGate unit has a local hard disk.
Download Select to download the corresponding file in its original format.
Submit Select to upload a suspicious file to Fortinet for analysis.
Customizing the display of log messages

After the configuration is completed, and logging of FortiGate activities begins, you can
customize and filter the log messages you see in the Log Access menu. Filtering and
customizing the display provides a way to view specific log information without scrolling
through pages of log messages to find the information.
Filtering information is similar to customizing, however, filtering allows you to enter specific
information that indicates what should appear on the page. For example, including only
log messages that appeared on April 4 between the hours of 8:00 and 8:30 am.
Customizing log messages allows you to remove or add columns to the page, allowing
you to view certain information. The most columns represent the fields from within a log
message, for example, the user column represents the user field, as well as additional
information.
The following is an example of how to filter and customize the display of application
control log messages. Use the following example to help you to filter and customize the
display of log messages in the web-based manager.
Filtering and customizing application control log messages example

The following example displays only the HTTP.BROWSER application name, without the
columns Status, Profile Type, Profile Group Name, User, Group, and Profile Name
displayed.
To filter and customize log messages

1 Go to Log&Report > Log Access > Application Control.
2 On the page, select Column Settings.
3 In the Show these fields in this order:, remove each of the following by selecting the
column name and then using the <- arrow:
• Status
• Profile Type
• Profile Group Name
• User
• Group
• Profile Name
4 Select OK.
5 On the page, locate the column, Application Name.

01-420-99686-20101026 605
Alert email messages Logging FortiGate activity
6 Select the filter icon beside Application Name.

The Edit Filters window appears.
7 Select the check box beside Edit.
8 Enter the application name HTTP.BROWSER in the Text field.
9 Select OK.
Alert email messages

Alert email messages provide notification about activities or events logged. These email
messages also provide notification about log severities that are recorded, such as a
critical or emergency.
You can send alert email messages to up to three email addresses. Alert messages are
also logged and can be viewed from the Log Access menu. Alert messages are recorded
in the event-system log file.
• Configuring an alert email message
• Configuring an alert email for notification of FortiGuard license expiry
Configuring an alert email message

You can use the alert email feature to monitor logs for log messages, and to send email
notification about a specific activity or event logged. For example, if you require
notification about administrators logging in and out, you can configure an alert email that is
sent whenever an administrator logs in and out. You can also base alert email messages
on the severity levels of the logs.
Before configuring alert email, you must configure at least one DNS server if you are
configuring with an Fully Qualified Domain Server (FQDN). The FortiGate unit uses the
SMTP server name to connect to the mail server, and must look up this name on your
DNS server. You can also specify an IP address.
To configure an alert email message

1 Go to Log&Report > Log Config > Alert E-mail.
2 On the Alert E-mail page, enter the information for the SMTP server.
3 If the SMTP user requires authentication, enter the information after selecting the
check box beside Enable.
4 Select Apply to apply the SMTP server information.
5 To verify these settings are correct, select Test Connectivity.
6 To send an alert email message based on a log’s severity, select Send to alert email for
logs based on severity, and then select a severity from the Minimum log level drop-
down list.
7 To send an alert email message based on different activities, such as an administrator
logging in and out, select from the following options:
Interval Time Enter the minimum time interval between consecutive alert emails.
(1-9999 minutes) Use this to rate-limit the volume of alert emails.
Intrusion detected Select if you require an alert email message based on attempted
intrusion detection.
Virus detected Select if you require an alert email message based on virus
detection.

606 01-420-99686-20101026
Logging FortiGate activity Alert email messages
Web access blocked Select if you require an alert email message based on blocked
web sites that were accessed.
HA status changes Select if you require an alert email message based on HA status
changes.
Violation traffic Select if you require an alert email message based on violated
detected traffic that is detected by the FortiGate unit.
Firewall Select if you require an alert email message based on firewall
authentication failure authentication failures.
SSL VPN login failure Select if you require an alert email message based on any SSL
VPN logins that failed.
Administrator Select if you require an alert email message based on whether
login/logout administrators log in or out.
IPSec tunnel errors Select if you require an alert email message based on whether
there is an error in the IPSec tunnel configuration.
L2TP/PPTP/PPPoE Select if you require an alert email message based on errors that
errors occurred in L2TP, PPTP, or PPPoE.
Configuration Select if you require an alert email message based on any
changes changes made to the FortiGate configuration.
FortiGuard license Enter the number of days before the FortiGuard license expiry
expiry time (1-100 time notification is sent.
days)
FortiGuard log quota Select if you require an alert email message based on the
usage FortiGuard Analysis server log disk quota getting full.
8 Select Apply.
Note: The default minimum log severity level is Alert. If the FortiGate unit collects more
than one log message before an interval is reached, the FortiGate unit combines the
messages and sends out one alert email.
Configuring an alert email for notification of FortiGuard license expiry

You can configure an alert email to notify you prior to when the FortiGuard license will
actually expire. By sending this type of alert email, users are reminded sooner about their
license requiring renewal soon, rather than later.
To configure an alert email for notification of FortiGuard license expiry - web-based

manager
1 Go to Log&Report > Log Config > Alert Email.
2 Configure the SMTP server, email from and to fields, and if applicable, authentication.
3 Verify that Select Send Alert email is selected.
4 Select the check box beside FortiGuard license expiry time: n (1-100 days).
The default for the expiry time is 15 days. This means that 15 days before the actual
expiry date, an alert message is sent informing you that your license will expire in 15
days.
5 Enter a number for the number of days prior to the expiry date in the field provided.
For example, you want to be notified five days before the expiry date (December 31),
an email is sent to the specified email address on December 27, five days before
December 31.
6 Select Apply.

01-420-99686-20101026 607
Alert email messages Logging FortiGate activity
If you have configured FortiGate system memory as your log device, logging alert email
notifications for FortiGuard license expiry requires you to enable event and admin in the
log memory filter command. Use the following procedure when you want to log this event
and if your log device is system memory. If you have enabled system memory on a
FortiGate unit that has a local disk, you do not have to use the following procedure.
All other log devices, including the FortiGate unit’s local disk, log alert messages by
default. You can find the alert email logs within the event-system log file.
To configure logging of an alert email notification of FortiGuard license expiry

(memory only)- CLI
2 To enable logging of an alert email notification using system memory, enter the
following command syntax:
set status enable
end
config log memory filter
set event enable
set admin enable
end

608 01-420-99686-20101026
Log message usage
FortiGate log messages present detailed accounts of an event or activity that happened
on your network recorded by the FortiGate unit. These log messages provide valuable
information about your network that inform you about attacks, misuse and abuse, and
traffic activity that may provide useful when troubleshooting an issue, testing a
configuration setting, or verifying that a setting is working properly.
If you require information about specific log messages, such as log message 3200, see
the FortiGate Log Message Reference.
This section explains how to use logs when troubleshooting, as well as verify settings and
testing purposes.
• Using log messages when troubleshooting
• Using log messages to verify settings and for testing purposes
Using log messages when troubleshooting

You can use log messages to help you troubleshoot various issues, such as an SSL VPN
configuration not working properly. The following are a few troubleshooting issues that
may arise and how log messages help solve them, as well as an example.
HA log messages indicate lost neighbor information

When the FortiGate unit is in HA mode, you may notice the following log messages within
the event log:
2010-04-16 11:05: 34 device_id=FG50B11111111 log_id=0105035001 type=event
subtype=ha pri=critical vd=root msg= “HA slave heartbeat interface internal lost neighbor
information”
OR
2010-04-16 11:16 11:05: 40 device_id=FG50B11111111 log_id=0105035001 type=event
subtype=ha pri=critical vd=root msg= “Virtual cluster 1 of group 0 detected new joined HA
member”
OR
2010-04-16 11:16 11:05: 40 device_id=FG50B11111111 log_id=0105035001 type=event
subtype=ha pri=critical vd=root msg= “HA master heartbeat interface internal get peer
information”
The log messages occur within a given time, and indicate that the units within the cluster
are not aware of each other anymore. These log messages provide the information you
need to fix the problem.

01-420-99686-20101026 609
Using log messages to verify settings and for testing purposes Log message usage
Alert email test configuration issues example

You have just configured the settings for an alert email message that will be sent to your
inbox whenever web access is blocked, violation traffic is detected, and IPSec tunnel
errors. You select Test Connectivity to test the configuration; however, there is no test
email in your inbox.
You immediately go to the log messages to see what is going on.
1 Log&Report > Log Access > Event.
2 The following message appears in the Message field: Failed to send alert email from
mail.example.com.
Raw format of the log message:
2010-04-05 13:34:31 log_id=01000200003 type=event subtype=system
vd=root pri=notice user=system ui=system action=alert-email
status=failure count=5 msg=“Failed to send alert email from
mail.example.com to myemailaddress@example.com”
The above log message indicates that the alert email message could not be sent to
your inbox. You must verify the SMTP server, and if incorrect, enter the correct SMTP
server and try again.
3 If you get the following log message, it means that the address you entered in the
SMTP server field was not correct. You need to verify that it is the correct address.
2010-04-05 13:34:31 log_id=01000200003 type=event subtype=system
vd=root pri=notice user=“system” ui=“system” action=“unknown”
status=“failure” msg=“Can’t resolve the IP address of
mail.example.com” vd=root pri=notice
An alert email log message is not recorded if the alert email configuration is correct. If it is
correct, you should see a test alert email message in your inbox and no log messages
concerning alert email configuration settings, similar to those in this example.
Using log messages to verify settings and for testing purposes

You can use log message to verify settings, as well as for testing connections. The
following explains various situations where you can use log message to verify settings
within a feature, and also for testing
Verifying to see if a network scan was performed example

When you have configured an asset for a scan and a schedule for when to scan, you may
want to verify that the asset is working properly. The log file that records network scanning
is the netscan log.
You have just configured an asset to scan. You verify the scan by selecting Discover
Assets on the Asset page (Endpoint > Network Vulnerability Scan > Asset). After the scan
is complete, you view the netscan logs. The following four log messages appear:
4097
This log message indicates that the scanned was performed.
2010-04-05 13:34:31 log_id=1600004097 type=netscan
subtype=discovery pri=notice vd=root action=scan start=1275363661
end=1275363719 engine=1.053 plugin=1.098
4100

610 01-420-99686-20101026
Log message usage Using log messages to verify settings and for testing purposes
Both these log messages indicate that the scan discovered two separate service-detection
events.
subtype=discovery pri=notice vd=root action=service-detection
ip=10.10.20.3 service=microsoft-ds proto=tcp prot=445

subtype=discovery pri=notice vd=root action=service-detection
ip=10.10.20.3 service=netbios-ssn proto=tcp port=139
4099
This log message indicates that the scan discovered a host, and explains the host’s
operating system, family that the OS belongs to, the type of generation, and the vendor or
company that created the OS.
subtype=discovery pri=notice vd=root action=host-detection
ip=10.10.20.3 os=“Windows XP” os_family=“Windows”
os_gen=“NT/2K/XP” os_vendor=“Microsoft”
Testing for the FortiGuard license expiry log message example

You recently configured an alert message that would notify when the FortiGuard Analysis
service license expires. You know that the expiry date is 2010-08-30, but want to verify
that the alert message will notify you both by email and by log message, so you entered
100 days. You made sure that the log configuration includes logging alert messages as
well.
After a while, you receive an alert email message in your inbox stating the following:
Message meets Alert condition
date=2010-06-08 time=11:55:52 devname=FG50BH3G09601792
device_id=FG50BH3G09601792 log_id=0104032014 type=event
subtype=admin pri=warning vd=root msg="FortiGuard analysis
service license will expire in 82 day(s)"
You go to Log&Report > Log Access > Event to view the license expiry log message using
a filter on the Message column:
1 In Log&Report > Log Access > Event, select the filter icon beside the Message
column’s name.
2 In the Edit Filters window, select the check box beside Enable.
3 In the Text field, enter the sentence found in the alert email message: FortiGuard
analysis service license will expire in 82 day(s).
4 Select OK.
The following log message appears in the first line on the first page of the Event page
(Raw format):
2010-06-03 13:55:22 log_id=32014 type=event subtype=admin
pri=warning vd=root msg=“FortiGuard analysis service license
will expire in 82 day(s)”
Using diag log test to verify logs are sent to a log device
After setting up a log device, you may want to verify that everything is working properly,
including sending of logs to the log device. The diag log test command is used to create
various test logs.
diag log test

01-420-99686-20101026 611
Using log messages to verify settings and for testing purposes Log message usage
The command can also be used when a Syslog server is not receiving certain logs. When
the command is entered in the CLI, an output similar to the following appears below the
line:
generating a system event message with level – warning
generating an infected virus message with level – warning
generating a blocked virus message with level – warning
generating a URL block message with level – warning
generating a DLP message with level – warning
generating an attack detection message with level – warning
generating an application control IM message with level –
information
generating an antispam message with level – notification
generating an allowed traffic message with level – notice
generating a wanopt traffic log message with level – notification
generating a HA event message with level – warning
generating netscan log messages with level – notice
generating a VOIP event message with level – information
generating authentication event messages
These log messages can be viewed from the Log Access menu. The following is a test log
message that may be generated and recorded by the FortiGate unit. It is shown as it
would be displayed in Raw format in system memory.
2010-08-10 09:34:22 log_id=0508020480 type=emailfilter
subtype=smtp pri=notice policyid=12345 identidx=67890 serial=312
user=“user” group=“group” vd=”root” src=1.1.1.1 sport=2560
src_port=2560 src_int=”lo” dst=2.2.2.2 dport=5120 dst_port=5120
dst_int=“eth0” service=mm1 carrier_ep=“carrier endpoint”
profile=“N/A” profilegroup=“N/A” profiletype=“N/A” status=detected
from=“from@xxx.com” to=“to@xxx.com” tracker=“Tracker”
msg=“SpamEmail”

612 01-420-99686-20101026
Reports
Reports provide a way to analyze log data without manually going through a large amount
of logs to get to the information you need. There are three distinct reports you can
configured: a FortiOS report, a FortiAnalyzer report, and executive summary reports. This
section explains these reports and how to configure and view them.
• Report overview
• FortiOS reports
• FortiAnalyzer reports
• Executive Summary reports
• Viewing reports
• Report examples
Note: Configuring reports from other log devices, such as a Syslog server, are not
supported.
Report overview
Reports provide a clear, concise overview of what is happening on your network based on
log data, without manually going through large amounts of logs. Reports can be
configured and generated from the FortiGate unit, or from a FortiAnalyzer unit. There are
three distinct reports you can configured: a FortiOS report, a FortiAnalyzer report, and
executive summary reports.
A FortiOS report is a report configured and generated from the FortiGate unit. FortiOS
reports consist of charts, a theme, an image (or more), and a layout. The layout is used as
a template by the FortiGate unit to compile the log data and then generate the report. A
FortiOS report is usually configured in the following order:
1 Charts
2 Theme
3 Image
4 Layout
A report schedule is a FortiAnalyzer report configured on the FortiGate unit, and then
generated on the FortiAnalyzer unit. FortiAnalyzer report schedules can be configured on
the FortiGate unit, if logs are being stored on the FortiAnalyzer unit. The report schedule is
generated on the FortiAnalyzer unit and you can view the generated report from either the
FortiGate unit (in Log&Report > Report Access > FortiAnalyzer) or the FortiAnalyzer unit
itself.

01-420-99686-20101026 613
FortiOS reports Reports
An executive summary report is a collection of widgets, which are used to display the log
information in a graphical format are actually charts that are also used when configuring a
FortiOS report layout.. Executive summary reports are configured on the Executive
Summary page, in the Report Access menu. These widgets, or charts, use the log
information that is associated with them, for example, the appcrtl.Count.Bandwidth.Top10
.Apps.last24h(Graph), displays the top ten application control applications, with the
amount of bandwidth usage stated on the y axis of the graph chart.
When you are ready to configure reports, and your FortiGate unit is currently running
FortiOS 4.0 MR2, you may not be able to view the Report Config and Report Access
menus from the web-based manager. You must log in to the CLI and use the following
commands to enable these two menus within the web-based manager. These menus do
not appear regardless of whether your log storage location is the FortiGate unit or the
FortiAnalyzer unit.
set gui-display enable
end
FortiOS reports
FortiOS reports are configured from logs stored on the FortiGate unit’s hard drive. These
reports are generated by the FortiGate unit itself, providing a central location for not only
configuring reports, but also generating them.
FortiOS reports consist of multiple parts which are all configured separately and then
added within the layout. The parts of a report are:
• charts (including datasets within the charts themselves)
• themes (including styles which are within the themes themselves)
• images
• layouts
Charts are used to display the log information in a clear and concise way using graphs and
tables. Charts contain datasets, which are SQL queries and help the FortiGate unit to add
specific log information into the chart using the SQL logs that are stored on the FortiGate
unit’s local disk. If you want to configure a chart, you must configure the dataset first.
Datasets are required for each chart, and if there is no dataset included in a chart, the
chart will not be saved.
Themes provide a one-step style application for report layouts. Themes contain various
styles for the table of contents, headings, headers and footers, as well as the margins of
the report’s pages. Themes are applied to layouts. The styles that are applied to themes
are configured separately.
You can easily upload your company or organization’s logo to use within a report from the
Images menu. By uploading your company or organization’s own logo and applying it in a
report, you provide a personalized report that is recognizable as your company or
organization’s report. The image must be in JPEG, JPG or PNG format.
Layouts provide a way to incorporate the charts, image, and themes that are configured to
create a formatted report. A layout is used as a template by the FortiGate unit to compile
and then generate the report.
• Creating datasets for charts
• Configuring the charts for the report

614 01-420-99686-20101026
Reports FortiOS reports
• Configuring a theme for the report

• Customizing and creating styles for a theme
• Importing images for the report
• Configuring the layout for the report
Creating datasets for charts

You must configure datasets because they are required when configuring a chart. You can
use the default datasets that are available when configuring a chart. Datasets require
knowledge of SQL because the logs are stored in an SQL database. You can view the
SQL schema using the get report database schema CLI command syntax.
Note: If you are configuring a chart for a report, you must create a dataset for that chart.
The chart cannot be configured without a dataset. There are no default datasets.
Use the following to configure a dataset that will be applied to a chart.

edit <report_dataset>
set query <SQL_statement>
config field
edit <field_id>
set displayname <string>
set type {text | integer | date | ip}
next
end
end
If you need more information about queries required for datasets, see “The SQL log
database” on page 579.
Configuring the charts for the report

Charts are used to display the log information in a clear and concise way using either a
graph or table. The charts that display the log information as a graph use a bar, pie, or line
graph type format.
Before configuring a chart for a report, you may want to see the list of available default
charts in Log&Report > Report Config > Chart. You can create your own chart, however,
you must use either a default dataset or create your own dataset. SQL knowledge is
required when configuring a dataset. There are many default charts to choose from, along
with datasets, which can be found in the list on the Chart page.
You should verify that the datasets you want to use are configured and available before
configuring a chart because a chart cannot be configured without a dataset. Charts are
also used to configure executive summary reports.
To create a graph chart

1 Go to Log&Report > Report Config > Chart.
2 Select the down arrow beside Create New and then select Graph Chart.
3 On the Add Graph Report Chart page, enter a name for the chart in the Name field.
4 Use the drop-down lists in Dataset and Category to choose the dataset and category
that will be used.
5 If you want to add a description or comment, enter it in the Comments field.

01-420-99686-20101026 615
6 To include the chart in the Favorites category, select the check box beside Add to
Favorites.
7 Select the type of graph that you want displayed in the chart from the Graph Type drop-
down list.
8 In the X Series section, enter the information for the x axis part of the chart.
9 In the Y Series section, enter the information for the y axis part of the chart.
10 Select OK.
To create a table chart

1 Go to Log&Report > Report Config > Chart.
2 Select the down arrow beside Create New and then select Table Chart.
3 On the Add Table Report Chart page, enter the information you want to include in the
chart.
4 If you want to add this chart to the Favorites chart list, select the check box beside Add
to Favorites.
5 Select OK.
Configuring a theme for the report

When you are configuring a layout for a report, you can also add a theme. A theme is a
group of settings that create the general style of a report. For example, the styles that are
applied to the table of contents section of the report. Themes are configured only in the
CLI.
You may want to configure your own styles for a theme, such as the type of alignment for
the text. Styles are configured within the CLI, and you can also customize the default
styles as well.
Use the following procedure to configure a theme for a report, which can then be applied
to a report’s layout.
To configure a theme for a report

config report theme
edit <theme_name>
set column-count [ 1 | 2 | 3]
set default-html-style <string>
set default-pdf-style <string>
set graph-chart-style <string>
set hline-style <string>
set image-style <string>
set normal-text-style <string>
set page-footer-style <string>
set page-header-style <string>
set page-orient {landscape | portrait}
set page-style <string>
set report-subtitle-style <string>

616 01-420-99686-20101026
set report-title-style <string>

set table-chart-caption-style <string>
set table-chart-even-row-style <string>
set table-chart-head-style <string>
set table-chart-odd-row-style <string>
set table-chart-style <string>
set toc-heading1-style <string>
set toc-title-style <string>
end
3 To choose a style for any one of the above commands, except for column-count and
page-orient, enter ? to view the available choices.
4 To change the style of any one of the above commands, except for column-count
and page-orient, go to “Customizing and creating styles for a theme” on page 617.
Customizing and creating styles for a theme

You can customize the default styles or create your own styles for reports. There are
default styles and summary styles to choose from. Default styles use a default style
scheme, and the summary styles are for summary reports that contain one or two pages
with a small graph or table.
To customize an existing style

config report style
edit style <style_name>
For example default.graph.
3 To view a list of available styles, enter ? after entering edit.
To create a new style

config report style
edit <new_style_name>
set options {align | border | color | column | font | margin
| padding | size | text }
set align {center | justify | left | right}
set bg-color {colour_name1 | color_name2 | color_name3 | …}
set border-bottom <border width_pixels> <border_style_{solid
| dotted | dashed}> <border_color>
set border-left <border width_pixels> <border_style_{solid |
dotted | dashed}> <border_color>
set border-right <border width_pixels> <border_style_{solid
| dotted | dashed}> <border_color>
set border-top <border width_pixels> <border_style_{solid |
dotted | dashed}> <border_color>
set column-gap <pixels>
set column-span {all |none}

01-420-99686-20101026 617
set fg-color <color>

set font-family {Arial | Courier | Helvetica | Times |
Verdana}
set font-size {xx-small | x-small | small | medium | large |
x-large | xx-large | <pixels>}
set font-style {italic | normal}
set font-weight {bold | normal}
set height <pixels or percentage>
set line-height <pixels or percentage>
set margin-bottom <pixels>
set margin-left <pixels>
set margin-right <pixels>
set margin-top <pixels>
set padding-bottom <pixels>
set padding-left <pixels>
set padding-right <pixels>
set padding-top <pixels>
set width <pixels or percentage>
end
Example of a style for a theme

The following example shows how to configure a specific style that is then applied to a
theme.
config report style
edit style_1
set options align color font margin text
set align center
set bg-color navy
set fg-color white
set font-family Verdana
set font-size medium
set font-weight bold
set line-height 100
set margin-bottom 20
set margin-left 20
set margin-right 30
set margin-top 50
end
config report theme
edit theme_1
set column-count 2
set page-style style_1
end
Importing images for the report

Images can be imported for use in reports. The supported images are JPEG, JPG and
PNG.
To import images for the report

1 Go to Log&Report > Report Config > Image.
2 Select Import.

618 01-420-99686-20101026
3 On the Import Image File page, either enter the location of the image file or select
Browse to locate the image file.
4 Select OK.
Configuring the layout for the report

A layout, similar to the layout configured for a FortiAnalyzer report, contains settings for
including charts, images, and whether or not to schedule when the report will be
generated.
The Report Components section of the Add Report Layout page provides a place where
you can add and view what charts, sections and images you want included in the layout.
To configure a layout for the report

1 Go to Log&Report > Report Config > Layout.
3 On the Add Report Layout page, enter the information that you want included in the
report.
For example, you want to add a newly created theme to the report, so you select it from
the Report Theme drop-down list.
4 To schedule when a report is generated, select the Schedule options that suite the type
of schedule you want.
5 Select the plus sign beside Report Components to add each of the following
components to the layout:
Text A description that will appear in a Heading 1, 2, 3 or Normal format.
Chart Add a chart to the report, which can be either a default chart or a chart that you
created. You must add each chart separately; you cannot add multiple charts at
one time.
Image Add a specific image to the report. If you have uploaded an image or images,
they are also included in this list.
Misc Add a page break, column break, or horizontal line.
Note: You must add the report components one at a time to the report layout. Adding
multiple components at the same time is not supported.
6 After adding the report components, arrange them in the order you want them
presented in the report.
Cloning a layout
Cloning a layout allows you to reuse settings in a previously configured layout and apply
those settings along with new settings to a new layout.
To clone a layout
2 Highlight the report that you want to use, and then select the Clone icon.
3 Enter the name of the new report in the Name field.
4 Enter the information for the new report.
5 Select OK.

01-420-99686-20101026 619
FortiAnalyzer reports Reports
Generating a report at any time

You can generate a report at any time, regardless of whether or not it is scheduled. This is
often referred to as on-demand reports, because they are generated whenever they are
needed.
To generate a report at any time

2 Highlight the report you want immediately generated, and then select the Run icon.
Report On-Demand-<report layout title>-<yyyy>-<mm>-<dd>-
<time_seconds> has been queued; Please check its progress on
Report Access > Disk.
3 Select Return to return to the Layout page.
The length of time to generate a report depends on the report itself. A large report may
take a long time, while a simple and smaller report may take a few minutes.
4 Go to Log&Report > Report Access > Disk to view the on-demand report.
On-demand reports contain “On-Demand” in the report file’s title.
FortiAnalyzer reports
FortiAnalyzer reports are configured on a FortiAnalyzer unit; however, you can configure a
report schedule from the FortiGate unit in Log&Report > Report Config > Schedule. You
need to have a report layout when configuring a report schedule. Report layouts are
configured only on the FortiAnalyzer unit.
If you want to configure a report schedule based on another report schedule, you can
clone the report schedule. Cloning a report schedule produces a duplicate of the original
and then editing that duplicate to create a new schedule.
Configuring a FortiAnalyzer report schedule

You can configure only a FortiAnalyzer report schedule from the FortiGate unit. Before you
can configure a report schedule, a FortiAnalyzer report layout must also be configured.
Contact your FortiAnalyzer administrator verify the report layout is available for you to add
to the report schedule that you are configuring on the FortiGate unit. You should also
contact the FortiAnalyzer administrator if you want to include a FortiAnalyzer output
template to the schedule.
To configure a report schedule

1 Go to Log&Report > Report Config > FortiAnalyzer.
3 On the Create Schedule page, enter the information required for the schedule.
4 Select OK.
The report schedule may take time, depending on the amount of log data needed and if
there are other reports being generated on the FortiAnalyzer unit.
To clone a report schedule

1 Go to Log&Report > Report Config > FortiAnalyzer.

620 01-420-99686-20101026
Reports Executive Summary reports
2 Highlight the report and then select the Clone icon.

You are redirected to the Edit Schedule page.
3 On the Edit Schedule page, enter the new information that is required for the schedule.
4 Select OK.
Executive Summary reports

If you have configured logging to a FortiGate unit’s SQL database, you can create reports
from those logs. SQL database reports appear on the Executive Summary page and are
represented as widgets. You cannot customize the type of chart, such as bar or pie, but
you can customize what column the widget displays in, such as the second column.
These reports can be viewed in Log&Report > Report Access > Executive Summary.
To configure an executive summary report - web-based manager

1 Go to Log&Report > Report Access > Execute Summary.
2 Select + Add Widget.
3 In Add New Widgets to Report Summary, select a report widget from the Widgets list.
Certain report widgets only display a table and others only display a graph. You cannot
customize the type of graph that displays.
4 Select OK.
The report widget appears on the Execute Summary page.
5 Repeat steps 2 to 4 until all of the report widgets that you need on the Executive
Summary page are configured.
To configure an executive summary report - CLI

config report summary
edit <id_number>
set widget <chart_name>
set column {1 | 2 | 3}
set schedule {daily | weekly}
set day {sunday | monday | tuesday | wednesday | thursday
| friday | saturday}
set time <hh:mm>
end
3 Enter a day in set day only if you want to schedule a weekly refresh of the
information.
Viewing reports
You can view various reports from the Report Access menu, including Executive Summary
reports. When you are viewing FortiOS reports, you go to Log&Report > Report Access >
Disk. When you are viewing FortiAnalyzer reports, you go to Log&Report > Report Access
> FortiAnalyzer.
The following table explains the Disk page when you are viewing FortiOS reports.

01-420-99686-20101026 621
Report examples Reports
Disk page
Displays each generated report. Reports are removed using the Delete icon. You can view either
HTML reports or PDF reports directly from this page. A HTML report opens up in a separate window,
while a PDF report opens within the Disk page.
Delete Removes one, multiple or all reports from the list. If you select the check box in
the check box column, you can remove all reports from the list at one time.
Report File The name of the report file, which includes the date and time.
Note: To view a HTML report, select the name in this column. The HTML report
appears in a separate window.
Started The time when the report began generating. This format includes the date and is
displayed in this type of format, yyyy-mm-dd hh:mm:ss. The hour is in the 24
hour format.
Finished The time when the report stopped generating. This format includes the date and
is displayed in this type of format, yyyy-mm-dd hh:mm:ss. The hour is in the 24
hour format.
Size (bytes) The size of the report file, in bytes.
Other Formats Displays PDF formatted generated reports. Select the format in this column to
view the report in PDF.
The following table explains the FortiAnalyzer page, when you are viewing historical
FortiAnalyzer reports. The current FortiAnalyzer report displays when you go to
Log&Report > Report Access > FortiAnalyzer. If you want a hard copy of a FortiAnalyzer
report, select Print which appears when you are viewing a current report.
FortiAnalyzer page
Displays each historical report that was generated.
Report FIles The name of the report. Expand the report to view
Date The date and time of when the report was generated on. The date is in the
format <day_name> <month_name> <dd> <hh>:<mm>:<ss> <yyyy>. For
example, Thu Apr 22 04:05:55 2010.
Size(bytes) The size of the report file, in bytes.
Other Formats Displays other formats that the report has been formatted in, such as XML and
PDF. Select the format in this column to view the report in PDF.
Report examples
The following are examples of two specific reports, a simple traffic report, and a more
complicated network scan report.
Report for analyzing traffic on the network

The managers of all departments within your organization want to know how much traffic
has been coming in and out of the internal network within the month of April. You have a
look at the Traffic History widget to get an idea of what log information you need to include
for the report.
To configure a traffic report

3 Enter the name, Traffic Report, in the Name: field.
4 Select the summary report theme from the drop-down list in Report Theme.
5 Enter the report’s title, Traffic Report for April 2010, in the Title field.

622 01-420-99686-20101026
Reports Report examples
6 Select the check box beside HTML in Output Format.

7 Select the plus sign (+) beside Report Components.
8 In the Add Component window, select Chart.
9 Select Traffic from the Categories drop-down list.
10 To select the charts, you must select each one individually, as follows:
• In Available Charts, select traffic.Count.Network.Session.last2h, and then select
OK.
• Use the steps 7-10, and then select traffic.Dist.Network.Bandwidth.last24h.
11 Select OK.
12 On the Layout page, highlight Traffic Report and select the Run icon.
In Report Generation Status, the following appears:
Report On-Demand-Traffic Report-2010-04-20-172928 has been
queued; Please check its progress on Report Access -> Disk.
Report for application usage on the network

The CEO of your organization has personally asked the manager of your IT department to
gather information on the applications that are used on your network. The CEO wants to
know the top ten applications that are being used, their bandwidth usage, and the top
media downloads. The CEO plans on showcasing the report during a presentation with
the organization’s board of directors.
This report requires a specific layout, charts, and image. The image must be the
organization’s new corporate image, since the image will be presented during the
presentation.
This example assumes that all logs are stored on the FortiGate unit’s local disk.
Importing the image

The following procedure imports the organization’s image, which will be included in the
report, at the top of the cover page and as a footer.
To import the image

1 Go to Log&Report > Report Config > Image.
2 On the Image page, select Import.
3 On the Import Image File page, either enter the file path of the location of the new
corporate image, or select Browse and locate the image.
4 Select OK.
Configuring the style and theme

The organization wants to use their own style for the report. The following procedure
configures a style which is then applied to a theme. Styles and themes are configured only
in the CLI.
You need to configure the style as follows:
• font – Helvetica
• size of font – large
• style of font should be italics for headings, normal for text

01-420-99686-20101026 623
• border – thin, and appearing only at the bottom of each page s

• no columns
• alignment – only the report title and image should be centered; all other headings and
text should be left aligned
• margins – should be that left is 2.0 and right is 0.0
There should be a style for headings that also includes the table of contents headings. For
example, style_toc is applied to only the table of contents headings.
To configure the style and theme

2 Enter the following command syntax to configure the general PDF style:
config report style
edit org_pdf
set options font text margin align
set align left
set line-height 120%
set font-family Helvetica
set font-size large
set font-style normal
set font-weight normal
set margin-bottom 100px
set margin-top 100px
set margin-left 17px
set margin-right 10px
next
3 Enter the following command syntax to configure the title style:
config report style
edit org_title
set options font align
set align center
set font-size xx-large
set font-style italic
next
4 Enter the following command syntax to configure the style of headings 1, 2 and 3 as
well as the table of contents headings:
config report style
edit org_heading1
set align left
set font-size x-large
next
edit org_heading2
set align left

624 01-420-99686-20101026

next
edit org_heading3
set align left
set font-size small
next
edit org_toc_title
set align left
set font-size large
next
edit org_toc_heading1
set align left
next
edit org_toc_heading2
set align left
set font-size small
5 Enter the following command syntax to configure the chart style:
config report style
edit org_chart
set align center
set font-size large
end
6 Enter the command syntax to configure the footer that will be on each page:
config report style
edit org_footer
set options font align border color
set align right
set border-bottom 100px
set color red
set font-size xx-small

01-420-99686-20101026 625

end
7 Enter the following command syntax to apply the style to a theme:
config report theme
edit org_theme
set column-count
set default-pdf-style org_pdf
set graph-chart-style org_chart
set heading1-style org_heading1
set heading2-style
set heading3-style
set image-style logo_img
set normal-text-style org_pdf
set page-footer-style org_footer
set page-orient portrait
set report-title-style org_title
set page-orient portrait
set page-style org_pdf
set toc-heading1-style org_toc_heading1
set toc-heading2-style org_toc_heading2
end
Layout
The following procedure applies the image and theme to the report, as well as the charts
required and additional settings.
To configure a layout
3 On the Add Report Layout page, enter the name for the report, Network
application usage on our network, in the Name field.
4 Select org_theme from the Report Theme drop-down list.
5 Enter the title for the report, The Application usage on our network, in the
Title field.
6 In Option, select the check boxes beside HTML Navigation Bar and Auto Heading
Number.
This removes the HTML navigation bar and heading numbers from being included in
the report.
7 In Output Format, select HTML.
By selecting HTML, only PDF will be applied as the format to the report.
8 Select the plus sign beside Report Components to begin adding the additional
components, such as charts, to the layout.

626 01-420-99686-20101026
9 In the Add Component window, add the following charts. You must add each chart
individually:
• appcrtl.Dist.Type.last24h
• appcrtl.Users.Media.last24h
• appcrtl.Users.Web.last24h
• appcrtl.Top10.Apps.Used.last24h
• appcrtl.Top10.Media.Dest.last24h
• appcrtl.Top10.Media.Source.last24h
• appcrtl.Top10.Apps.Bandwidth.last24h
10 In Component Type, select Image, and then select the organization’s image.
11 After the layout is complete, on the Layout page, highlight the report and select Run.
Report On-Demand-Network application usage on our network-2010-
05-24-161931 has been queued; Please check its progress on
Report Access-> Disk.
13 Go to Log&Report > Report Access > Disk to view the status of the report.

01-420-99686-20101026 627

628 01-420-99686-20101026
Chapter 5 Troubleshooting
This handbook chapter describes concepts of troubleshooting and solving issues that may
occur with FortiGate units.
Troubleshooting process walks you through best practice concepts of FortiOS
troubleshooting.
Troubleshooting tools describes some of the basic commands and parts of FortiOS that
can help you with troubleshooting.
Technical Support Organization Overview describes how Fortinet Support operates, what
they will need from you if you contact them, and what you can expect in general.
Troubleshooting connectivity walks you through some troubleshooting methods that apply
to common issues you may have such as network connectivity problems.
Troubleshooting get commands provides a list of diagnostic commands that can help you
troubleshoot your FortiOS unit.
Troubleshooting bootup issues addresses some potential problems your unit may have
when booting up. The format is an easy to follow step by step question and answer format.
FortiOS™ Handbook v2: Troubleshooting

01-420-99686-20101026 629
Troubleshooting for FortiOS 4.0 MR2
630 01-420-99686-20101026
Troubleshooting process
Before you begin troubleshooting anything but the most minor issues, you need to
prepare. Doing so will shorten the time to solve your issue.
Before starting you need to:
• Establish a baseline
• Search for a solution
• Create a troubleshooting plan
• Obtain any required additional equipment
• Ensure you have administrator level access to required equipment
• Contact Fortinet Customer Support for assistance
Establish a baseline
Note that many of these questions are some form of comparing the current situation to
normal operation. For this reason it is recommended that you know what your normal
operating status is. This can easily be accomplished through logs, or regularly running
information gathering commands and saving the output. Then when there is a problem,
this regular operation data will enable you to determine what is different.
It is a good idea to backup the FortiOS configuration for your unit on a regular basis. Apart
from troubleshooting, if you accidently change something the backup can help you restore
normal operation quickly and easily.
Some simple commands that you can run to get normal operating data include:
get system status Displays versions of firmware and FortiGuard

engines, and other
diagnose firewall statistic show Displays the amount of network traffic broken down
into categories such as email, VoIP, TCP, UDP, etc.
get router info routing-table all Displays all the routes in the routing table including
their type, source, and other useful data.
get ips session Displays memory used and max available to IPS as
well and counts.
get webfilter ftgd-statistics Displays list of FortiGuard related counts of status,
errors, and other data.
These commands are just a sample. Feel free to include any extra information gathering
commands that apply to your system, for example if you regularly have active VPN
connections you should record information about them using the get vpn series of
commands. See “Troubleshooting get commands” on page 687.
Define the Problem

Before starting to troubleshooting a problem, ask the following questions:

01-420-99686-20101026 631
Define the Problem Troubleshooting process
• What is the problem?

Do not assume that the problem is being experienced is the actual problem. First
determine that the problem does not lie elsewhere before starting to troubleshoot the
FortiGate device.
• Has it ever worked before?
• Can the problem be reproduced at will or is it intermittent?
If the problem is intermittent, it may be dependent on system load.
• What has changed?
Do not assume that nothing has changed in the network. Use the FortiGate event log
to see if any configuration changes were made. The change could be in the operating
environment, for example, a gradual increase in load as more sites are forwarded
If something has changed, see what the effect is if the change is rolled back.
• After determining the scope of the problem and isolating it, what applications,
users, and/or operating systems does it effect?
Before you can solve a problem, you need to understand it. Often this step can be the
longest in this process.
Ask questions such as:
• What is not working? Be specific.
• Is there more than one thing not working?
• Is it partly working? If so, what parts are working?
• Is it a connectivity issue? or is there an application that isn’t reaching the
Internet?
Be as specific as possible with your answers, even if it takes awhile to find the answers.
These questions will help you define the problem. Once the problem is defined, you can
search for a solution and then create a plan on how to solve it.
Gathering Facts
Fact gathering is an important part of defining the problem.
Consider the following:
• Where did the problem occur?
• When did the problem occur and to whom?
• What components are involved?
• What is the affected application?
• Can the problem be traced using a packet sniffer?
• Can the problem be traced in the session table?
• Can log files be obtained that indicate a failure has occurred?
Answers to these questions will help you narrow down the problem, and what you have to
check during your troubleshooting. The more things you can eliminate, the fewer things
you need to check during troubleshooting.

632 01-420-99686-20101026
Troubleshooting process Search for a solution
Search for a solution

An administrator can save time and effort during the troubleshooting process by first
checking to see if the issue has been experienced before. Several resources are available
that can provide valuable information about technical issues, including:
Technical Documentation
Installation Guides, Administration Guides, Quick Start Guides, and other technical
documents are available online at the following URL:
http://docs.fortinet.com
Release Notes
Issues that are uncovered after the technical documentation has been published will often
be listed in the Release Notes that accompany the device.
Knowledge Center
The Fortinet Knowledge Center provides access to a variety of articles, white papers, and
other documentation providing technical insight into a range of Fortinet products. The
Knowledge Center is available online at the following URL:
http://kc.fortinet.com
Fortinet Technical Discussion Forums

An online technical forum allows administrators to contribute to discussions about issues
related to their Fortinet products. Searching the forum can help the administrator identify if
an issue has been experienced by another user. The support forums can be accessed at
the following URL:
http://support.fortinet.com/forum
Fortinet Training Services Online Campus

The Fortinet Training Services Online Campus hosts a collection of tutorials and training
materials which can be used to increase knowledge of the Fortinet products.
http://campus.training.fortinet.com
Create a troubleshooting plan

Once you have defined the problem, and searched for a solution you can create a plan to
solve that problem. Even if your search didn’t find a solution to your problem you may
have found some additional things to check to further define your problem.
The plan should list all the possible causes of the problem that you can think of, and how
to test for each possible cause.
The plan will act as a checklist so that you know what you have tried and what is left to
check. This is important to have if more than one person will be doing the troubleshooting.
Without a written plan, people will become easily confused and steps will be skipped. Also
if you have to hand over the problem to someone else, providing them with a detailed list
of what data has been gathered and what solutions have been already tried demonstrates
a good level of professionalism.

01-420-99686-20101026 633
Obtain any required additional equipment Troubleshooting process
Be ready to add to your plan as needed. After you are part way through, you may discover
that you forgot some tests or a test you performed discovered new information. This is
normal.
Also if you contact support, they will require information about your problem as well as
what you have already tried to fix the problem. This should all be part of your plan.
Providing Supporting Elements

If the Fortinet Technology Assistance Center (TAC) needs to be contacted to help you with
your issue, be prepared to provide the following information:
• The firmware build version (use the get system status command)
• A recent configuration file
• A recent debug log
• A network topology diagram
• Tell the support team what troubleshooting steps have already been performed and the
results.
For additional information about contacting Fortinet Customer Support, see “Technical
Support Organization Overview” on page 663.
All of this is your troubleshooting plan.
Obtain any required additional equipment

You may require additional networking equipment, computers, or other equipment to test
your solution.
Normally network administrators have additional networking equipment available either to
loan you, or a lab where you can bring the FortiGate unit to test.
If you do not have access to equipment, check for shareware applications that can
perform the same task. Often there are software solutions when hardware is too
expensive.
Ensure you have administrator level access to required equipment

Before troubleshooting your FortiGate unit, you will need administrator access to the
equipment. If you are a client on a FortiGate unit with virtual domains enabled, often you
can troubleshoot within your own VDOM. However, you should inform your FortiGate
unit’s super admin that you will be doing troubleshooting.
Also, you may need access to other networking equipment such as switches, routers, and
servers to help you test. If you do not normally have access to this equipment, contact
your network administrator for assistance.
Contact Fortinet Customer Support for assistance

You have defined your problem, researched a solution, put together a plan to find the
solution, and executed that plan. At this point if the problem has not been solved, its time
to contact Fortinet Customer Support for assistance.
For more information, see “Technical Support Organization Overview” on page 663.

634 01-420-99686-20101026
Troubleshooting tools
This section includes a number of tools you can use during troubleshooting, including:
• FortiOS Diagnostics
• FortiGate Ports
• FortiAnalyzer/FortiManager Ports
• FortiGuard Troubleshooting
FortiOS Diagnostics
A collection of diagnostic commands are available in FortiOS for troubleshooting and
performance monitoring.
Within the CLI commands, the two main groups of diagnostic commands are get and
diagnose commands. Both commands display information about system resources,
connections, and settings that enable you to locate and fix problems, or to monitor system
performance.
When you call Fortinet Customer Support, you will be asked to provide information about
your unit and its current state through the use of these CLI commands.
This section includes diagnostics commands to help with:
• Resource Usage
• Processes
• Proxy Operation
• Hardware NIC
• Conserve Mode
• Traffic Trace
• Session Table
• Finding Object Dependencies
• Flow Trace
• Packet Sniffer
• Debug Command
Additional diagnostic commands are covered in “Troubleshooting get commands” on
page 687, and commands related to specific features are covered in the chapter for that
specific feature. For example in-depth diagnostics for dynamic routing are covered in the
dynamic routing chapter.
Resource Usage
Monitor the CPU/memory usage of internal processes using the following command:
diag sys top <delay> <max_lines>
The data listed includes the name of the daemon, the process ID, whether the process is
sleeping or running, the CPU percentage being used, and the memory percentage being
used.

01-420-99686-20101026 635
FortiOS Diagnostics Troubleshooting tools
Processes
List information about processes running on the FortiGate unit using the following
command:
diag sys top
Sample output:
Run Time: 13 days, 13 hours and 58 minutes
0U, 0S, 98I; 123T, 25F, 32KF
newcli 903 R 0.5 5.5
sshd 901 S 0.5 4.0
Where the codes displayed on the second output line mean the following:
• U is % of user space applications using CPU. In the example, 0U means 0% of the user
space applications are using CPU.
• S is % of system processes (or kernel processes) using CPU. In the example, 0S
means 0% of the system processes are using the CPU.
• I is % of idle CPU. In the example, 98I means the CPU is 98% idle.
• T is the total FortiOS system memory in Mb. In the example, 123T means there are
123 Mb of system memory.
• F is free memory in Mb. In the example, 25F means there is 25 Mb of free memory.
• KF is the total shared memory pages used. In the example, 32KF means the system is
using 32 shared memory pages.

636 01-420-99686-20101026
Troubleshooting tools FortiOS Diagnostics
Each additional line of the command output displays information for each of the processes
running on the FortiGate unit. For example, the third line of the output is:
newcli 903 R 0.5 5.5
Where:
• newcli is the process name. Other process names can include ipsengine, sshd,
cmdbsrv, httpsd, scanunitd, and miglogd.
• 903 is the process ID. The process ID can be any number.
• R is the state in which the process is running. The process state can be:
R running.
S sleep.
Z zombie.
D disk sleep.
• 0.5 is the amount of CPU that the process is using. CPU usage can range from 0.0 for
a process that is sleeping to higher values for a process that is taking a lot of CPU time.
• 5.5 is the amount of memory that the process is using. Memory usage can range from
0.1 to 5.5 and higher.
Enter the following single-key commands when diagnose sys top is running:
• Press q to quit.
• Press p to sort the processes by the amount of CPU that the processes are using.
• Press m to sort the processes by the amount of memory that the processes are using.
Proxy Operation
Monitor proxy operations using the following command:
diag test application <application> <option>
The <application> value can include the following:
ftpd ftp proxy
http http proxy
im im proxy
imap imap proxy
ipsengine ips sensor
ipsmonitor ips monitor
pop3 pop3 proxy
smtp smtp proxy
urlfilter urlfilter daemon

01-420-99686-20101026 637
The <option> value for use with this command can include:
1 Dump Memory Usage
2 Drop all connections
4 Display connection state *
44 Display info per connection *
444 Display connections per state *
5 Toggle AV Bypass mode
6 Toggle Print Stat mode every ~40 seconds
7 Toggle Backlog Drop
8 Clear stats
88 Toggle statistic recording - stats cleared
9 Toggle Accounting info for display
99 Restart proxy
These commands, except for the ones identified with an “*”, should only be used under the
guidance of Fortinet Support.
Hardware NIC
Monitor hardware network operations using the following command:
diag hardware deviceinfo nic <interface>
The information displayed by this command is important as errors at the interface are
indicative of data link or physical layer issues which may impact the performance of the
FortiGate unit.
The following is sample output when <interface> = internal:
System_Device_Name port5
Current_HWaddr 00:09:0f:68:35:60
Permanent_HWaddr 00:09:0f:68:35:60
Link up
Speed 100
Duplex full
[……]
Rx_Packets=5685708
Tx_Packets=4107073
Rx_Bytes=617908014
Tx_Bytes=1269751248
Rx_Errors=0
Tx_Errors=0
Rx_Dropped=0
Tx_Dropped=0
[…..]

638 01-420-99686-20101026
Hardware Troubleshooting
Field Definition
Rx_Errors = rx error Bad frame was marked as error by PHY.
count
Rx_CRC_Errors + This error is only valid in 10/100M mode.
Rx_Length_Errors -
Rx_Align_Errors
Rx_Dropped or Running out of buffer space.
Rx_No_Buffer_Count
Rx_Missed_Errors Equals Rx_FIFO_Errors + CEXTERR (Carrier Extension Error Count).
Only valid in 1000M mode, whichis marked by PHY.
Tx_Errors = ECOL (Excessive Collisions Count). Only valid in half-duplex mode.
Tx_Aborted_Errors
Tx_Window_Errors LATECOL (Late Collisions Count). Late collisions are collisions that
occur after 64-byte time into the transmission of the packet while
working in 10 to100Mb/s data rate and 512-byte timeinto the
transmission of the packet while working in the 1000Mb/s data rate. This
register only increments if transmits are enabled and the device is in
half-duplex mode.
Rx_Dropped See Rx_Errors.
Tx_Dropped Not defined.
Collisions Total number of collisions experienced by the transmitter. Valid in half-
duplex mode.
Rx_Length_Errors Transmission length error.
Rx_Over_Errors Not defined.
Rx_CRC_Errors Frame CRC error.
Rx_Frame_Errors Same as Rx_Align_Errors. This error is only valid in 10/100M mode.
Rx_FIFO_Errors Same as Rx_Missed_Errors - a missed packet count.
Tx_Aborted_Errors See Tx_Errors.
Tx_Carrier_Errors The PHY should assert the internal carrier sense signal during every
transmission. Failure to do so may indicate that the link has failed or the
PHY has an incorrect link configuration. This register only increments if
transmits are enabled. This register is not valid in internal SerDes 1
mode (TBI mode for the 82544GC/EI) and is only valid when the
Ethernet controller is operating at full duplex.
Tx_FIFO_Errors Not defined.
Tx_Heartbeat_Errors Not defined.
Tx_Window_Errors See LATECOL.
Tx_Single_Collision_Fr Counts the number of times that a successfully transmitted packed
ames encountered a single collision. The value only increments if transmits
are enabled and the Ethernet controller is in half-duplex mode.
Tx_Multiple_Collision_ A Multiple Collision Count which counts the number of times that a
Frames transmit encountered more than one collision but less than 16. The
value only increments if transmits are enabled and the Ethernet
controller is in half-duplex mode.
Tx_Deferred Counts defer events. A defer event occurs when the transmitter cannot
immediately send a packet due to the medium being busy because
another device is transmitting, the IPG timer has not expired, half-duplex
deferral events are occurring, XOFF frames are being received, or the
link is not up. This register only increments if transmits are enabled. This
counter does not increment for streaming transmits that are deferred
due to TX IPG.
Rx_Frame_Too_Longs The Rx frame is over size.
Rx_Frame_Too_Shorts The Rx frame is too short.
Rx_Align_Errors This error is only valid in 10/100M mode.
Symbol Error Count Counts the number of symbol errors between reads - SYMERRS. The
count increases for every bad symbol received, whether or not a packet
is currently being received and whether or not the link is up. This register
only increments in internal SerDes mode.
Note: The counters displayed depend on the type of NIC interface. Please see the
following website for more information:
http://kc.forticare.com/default.asp?id=1979&Lang=1&SID=

01-420-99686-20101026 639
Conserve Mode
The FortiOS antivirus/IPS system operates in one of two modes, depending on the unit’s
available shared memory. If the shared memory utilization is below a defined upper
threshold, the system is in non-conserve mode. If the used shared memory goes beyond
this threshold, the system enters conserve mode and remains there until the shared
memory utilization drops below a second threshold, slightly lower than the original. These
thresholds are non-configurable; the threshold above which the system enters conserve
mode is 80%, the system will not go back to non-conserve mode until the shared memory
usage goes below 70%.
Conserve mode occurs under high usage and traffic conditions. It is expected to be a
temporary condition that is self-correcting when bursty traffic subsides.
When in conserve mode, any new sessions are ignored (no SYN-ACK from the FortiGate
unit) or passed without being scanned.
The following is sample output from the event log:
66 2008-04-16 14:01:31 critical The system has entered system
conserve mode

640 01-420-99686-20101026
Antivirus Failopen
Dealing with high traffic volume may cause the problem dealing with low memory
situations or when dealing with connection pool limits affecting a single proxy. If a
FortiGate unit is receiving large volumes of traffic on a specific proxy, it is possible that the
unit will exceed the connection pool limit. If the number of free connections within a proxy
connection pool reaches zero, problems may occur.
Antivirus failopen is a safeguard feature that determines the behavior of the FortiGate
antivirus system if it becomes overloaded in high traffic. The feature is configurable only
though the CLI.
config system global set av_failopen {off|one-shot|pass
|idledrop}
av-failopen-session controls the behavior when the proxy connection pool is
exhausted. Again in this case, the FortiGate unit does not send the SYN-ACK. Failopen is
only available on FortiGate models 300A and higher. On other lower FortiGate models, the
failopen action is configured to pass.
The set av-failopen command has the following four options:
• off
If the FortiGate unit enters conserve mode, the antivirus system will stop accepting
new AV sessions but will continue to process current active sessions.
• one-shot
If the FortiGate unit enters conserve mode, all subsequent connections bypass the
antivirus system but current active sessions will continue to be processed. One-shot is
similar to pass but will not automatically turn off once the condition causing av-failopen
has stopped.
• idledrop
When configured in this mode, the antivirus failopen mechanism will drop connections
based on the clients that have the most open connections.
• pass
Pass becomes the default setting when the av-failopen-session command has
been run. If the system enters conserve mode, connections bypass the antivirus
system until the system enters non-conserve mode again. Current active sessions will
continue to be processed.
Note: The one-shot and pass options do not content filter traffic. Therefore, the data
stream could contain malicious content.

01-420-99686-20101026 641
Traffic Trace
Traffic tracing allows a specific packet stream to be followed.
View the characteristics of a traffic session though specific firewall policies using:
diag sys session
Trace per-packet operations for flow tracing using:
diag debug flow
Trace per-Ethernet frame using:
diag sniffer packet
Session Table
The FortiGate session table can be viewed from either the CLI or Web Config. The most
useful troubleshooting data comes from the CLI. The session table in Web Config also
provides some useful summary information, particularly the current policy number that the
session is using.
In Web Config, click Add Content and select Top Sessions. In the Top Sessions pane, click
the Details link. (If there are not enough entries in the session table, try browsing to a
different web site and re-examine the table.) The Policy ID shows which firewall policy
matches the session. The sessions that do not have a Policy ID entry originate from the
FortiGate device.

642 01-420-99686-20101026
The session table output from the CLI (diag system session list) is very verbose,
so even on a system with a small load, displaying the session table will generate a large
amount of output. For this reason, filters are used to display only the session data of
interest.
Filter a column in Web Config by clicking the funnel icon on the column heading or from
the CLI by creating a filter.
An entry is placed in the session table for each traffic session passing through a firewall
policy. The following command will list the information for a session in the table:
diag sys session list
Sample Output:
flags=00000000 av_idx=0 use=3
bandwidth=204800/sec guaranteed_bandwidth=102400/sec
traffic=332/sec prio=0 logtype=session ha_id=0 hakey=4450
tunnel=/
state=log shape may_dirty
statistic(bytes/packets/err): org=3408/38/0 reply=3888/31/0
tuples=2
orgin->sink: org pre->post, reply pre->post oif=3/5
gwy=192.168.11.254/10.0.5.100
hook=post dir=org act=snat 10.0.5.100:1251-
>192.168.11.254:22(192.168.11.105:1251)
hook=pre dir=reply act=dnat 192.168.11.254:22-
>192.168.11.105:1251(10.0.5.100:1251)
pos/(before,after) 0/(0,0), 0/(0,0)
misc=0 domain_info=0 auth_info=0 ftgd_info=0 ids=0x0 vd=0
serial=00007c33 tos=ff/ff

01-420-99686-20101026 643
Since output can be verbose, the filter option allows specific information to be displayed,
for example:
diag sys session filter <option>
The <option> values available include the following:
clear clear session filter
dport dest port
dst destination IP address
policy policy ID
sport source port
src source IP address
vd index of virtual domain. -1 matches all
Even though UDP is a sessionless protocol, the FortiGate unit still keeps track of the
following two different states:
• UDP reply not seen with a value of 0
• UDP reply seen with a value of 1
The following illustrates FW session states from the session table:
State Meaning
log Session is being logged.
local Session is originated from or destined for local stack.
may_dirty Session is created by a policy. For example, the session for ftp
control channel will have this state but ftp data channel will
not. This is also seen when NAT is enabled.
ndr Session will be checked by IPS signature.
nds Session will be checked by IPS anomaly.
br Session is being bridged (TP) mode.

644 01-420-99686-20101026
Finding Object Dependencies

An administrator may not be permitted to delete a configuration object if there are other
configuration objects that depend on it. This command identifies other objects which
depend on or make reference to the configuration object in question. If an error is
displayed that an object is in use and cannot be deleted, this command can help identify
the source of the problem.
When running multiple VDOMs, this command is run in the Global configuration only and it
searches for the named object both in the Global and VDOM configuration most recently
used:
diag sys checkused <path.object.mkey>
For example, to verify which objects are referred to in a firewall policy with an ID of 1, enter
the command as follows:
diag sys checkused firewall.policy.policyid 1
To check what is referred to by interface port1, enter the following command:

diag sys checkused system.interface.name port1
To show all the dependencies for an interface, enter the command as follows:
diag sys checkused system.interface.name <interface name>
Sample Output:
entry used by table firewall.address:name '10.98.23.23_host’
entry used by table firewall.address:name 'NAS'
entry used by table firewall.address:name 'all'
entry used by table firewall.address:name 'fortinet.com'
entry used by table firewall.vip:name 'TORRENT_10.0.0.70:6883'
In this example, the interface has dependent objects, including four address objects, one
VIP, and three firewall policies.

01-420-99686-20101026 645
Flow Trace
To trace the flow of packets through the FortiGate unit, use the following command:
diag debug flow trace start
Follow packet flow by setting a flow filter using this command:

diag debug flow filter <option>
Filtering options include the following:

addr IP address
clear clear filter
daddr destination IP address
dport destination port
port port
saddr source IP address
sport source port
vd index of virtual domain, -1 matches all
Enable the output to be displayed to the CLI console using the following command:
diag debug flow show console
Start flow monitoring with a specific number of packets using this command:
diag debug flow trace start <N>
Stop flow tracing at any time using:

diag debug flow trace stop
The following is an example of the flow trace for the device at the following IP address:
203.160.224.97
diag debug enable
diag debug flow filter addr 203.160.224.97
diag debug flow show console enable
diag debug flow show function-name enable
diag debug flow trace start 100

646 01-420-99686-20101026
Flow Trace Output Example - HTTP

Connect to the web site at the following address to observe the debug flow trace. The
display may vary slightly:
http://www.fortinet.com
Comment: SYN packet received:

192.168.3.221:1487->203.160.224.97:80) from port5."
SYN sent and a new session is allocated:
msg="allocate a new session-00000e90"
Lookup for next-hop gateway address:
Source NAT, lookup next available port:
id=20085 trace_id=209 func=get_new_addr line=1219
msg="find SNAT: IP-192.168.11.59, port-31925"
direction“
Matched firewall policy. Check to see which policy this session matches:
id=20085 trace_id=209 func=fw_forward_handler line=317
msg="Allowed by Policy-3: SNAT"
Apply source NAT:
line=1502 msg="SNAT 192.168.3.221->192.168.11.59:31925"
SYN ACK received:
msg="vd-root received a packet(proto=6, 203.160.224.97:80-
>192.168.11.59:31925) from port6."
Found existing session ID. Identified as the reply direction:
msg="Find an existing session, id-00000e90, reply
direction"
line=1516 msg="DNAT 192.168.11.59:31925-
>192.168.3.221:1487"

01-420-99686-20101026 647
Lookup for next-hop gateway address for reply traffic:

ACK received:
192.168.3.221:1487->203.160.224.97:80) from port5."
msg="Find an existing session, id-00000e90, original
direction"
Apply source NAT:
line=1502 msg="SNAT 192.168.3.221->192.168.11.59:31925"
Receive data from client:
192.168.3.221:1487->203.160.224.97:80) from port5."
original direction"
Apply source NAT:
line=1502 msg="SNAT 192.168.3.221->192.168.11.59:31925"
Receive data from server:
203.160.224.97:80->192.168.11.59:31925) from port6."
Match existing session in reply direction:
reply direction"
line=1516 msg="DNAT 192.168.11.59:31925-
>192.168.3.221:1487"

648 01-420-99686-20101026
Flow Trace Output Example - IPSec (policy-based)

id=20085 trace_id=1 msg="vd-root received a packet(proto=1,
10.72.55.240:1->10.71.55.10:8) from internal."
id=20085 trace_id=1 msg="allocate a new session-00001cd3"
id=20085 trace_id=1 msg="find a route: gw-66.236.56.230 via
wan1"
id=20085 trace_id=1 msg="Allowed by Policy-2: encrypt"
id=20085 trace_id=1 msg="enter IPsec tunnel-RemotePhase1"
id=20085 trace_id=1 msg="encrypted, and send to 15.215.225.22
with source 66.236.56.226"
id=20085 trace_id=1 msg="send to 66.236.56.230 via intf-wan1“
id=20085 trace_id=2 msg="vd-root received a packet (proto=1,
10.72.55.240:1-1071.55.10:8) from internal."
id=20085 trace_id=2 msg="Find an existing session, id-00001cd3,
original direction"
id=20085 trace_id=2 msg="enter IPsec ="encrypted, and send to
15.215.225.22 with source 66.236.56.226“ tunnel-RemotePhase1"
id=20085 trace_id=2 msgid=20085 trace_id=2 msg="send to
66.236.56.230 via intf-wan1"

01-420-99686-20101026 649
Packet Sniffer
Details within packets passing through particular interfaces can be displayed using the
packet sniffer with the following command:
diag sniffer packet <interface> <filter> <verbose> <count>
The <interface> value can be any physical or virtual interface name. Use any for all
interfaces.
The <filter> value limits the display of packets using filters, including Berkeley Packet
Filtering (BPF) syntax.
'[[src|dst] host<host_name_or_IP1>] [[src|dst]
host<host_name_or_IP2>] [[arp|ip|gre|esp|udp|tcp] [port_no]]
[[arp|ip|gre|esp|udp|tcp] [port_no]]‘
If a second host is specified, only the traffic between the two hosts will be displayed.
Use flexible, logical filters for the packet sniffer or none. For example, to print UDP 1812
traffic between host1 and either host2 or host3, use the following:
'udp and port 1812 and host host1 and $ host2 or host3 $‘
The <verbose> option allows different levels of information to be displayed. The verbose
levels include:
1 Print header of packets
2 Print header and data from the IP header of the packets
3 Print header and data from the Ethernet header of the packets
4 Print header of packets with interface name
5 Print header and data from ip of packets with interface name
6 Print header and data from ethernet of packets with interface
The <count> value indicates the number of packets the sniffer needs before stopping.
A script to convert FortiGate sniffer output to the PCAP format is available from Fortinet at
the following address:
http://kc.forticare.com/default.asp?id=1186&SID=&Lang=1

650 01-420-99686-20101026
FA2 and NP2 Based Interfaces

Many Fortinet products contain network processors. Some of these products contain
FortiAccel (FA2) network processors while others contain NP2 network processors.
Network processor features, and therefore offloading requirements, vary by network
processor model.
When using the FA2- and NP2-based interfaces, only the initial session setup will be seen
through the diag debug flow command. If the session is correctly programmed into the
ASIC (fastpath), the debug flow command will no longer see the packets arriving at the
CPU. If the NP2 functionality is disabled, the CPU will see all the packets, however, this is
only recommended for troubleshooting purposes.
First, obtain the NP2 and port numbers with the following command:
diag npu np2 list
Sample Output:
ID PORTS
-- -----
0 port1
0 port2
0 port3
0 port4
ID PORTS
-- -----
1 port5
1 port6
1 port7
1 port8
ID PORTS
-- -----
2 port9
2 port10
2 port11
2 port12
ID PORTS
-- -----
3 port13
3 port14
3 port15
3 port16

01-420-99686-20101026 651
Run the following commands:

diag npu np2 fastpath disable 0
(where 0 is the NP2 number)
Then, run this command:
diag npu np2 fastpath-sniffer enable port1
Sample Output:
NP2 Fast Path Sniffer on port1 enabled
This will cause all traffic on port1 of NP2 0 to be sent to the CPU meaning a standard
sniffer trace can be taken and other diag commands should work if it was a standard CPU
driven port.
These commands are only for the newer NP2 interfaces. FA2 interfaces are more limited
as the sniffer will only capture the initial packets before the session is offloaded into HW
(FA2). The same holds true for the diag debug flow command as only the session
setup will be shown, however, this is usually enough for this command to be useful.

652 01-420-99686-20101026
Debug Command
Debug output provides continuous, real-time event information. Debugging output
continues until it is explicitly stopped or until the unit is rebooted. Debugging output can
affect system performance and will be continually generated even though output might not
be displayed in the CLI console.
Debug information displayed in the console will scroll in the console display and may
prevent CLI commands from being entered, for example, the command to disable the
debug display. To turn off debugging output as the display is scrolling by, press the Ç key
to recall the recent diag debug command, press backspace, and type “0”, followed by
Enter.
Debug output display is enabled using the following command:
diag debug enable
When finished examining the debug output, disable it using:
diag debug disable
Once enabled, indicate the debug information that is required using this command:
diag debug <option> <level>
Debug command options include the following:
application application
authd authentication daemon
cli debug cli
console console
crashlog crash log info
disable disable debug output
enable enable debug output
flow trace packet flow in kernel
haproxy haproxy
info show active debug level settings
kernel kernel
rating display rating info
report report for tech support
reset reset all debug level to default
The debug level can be set at the end of the command. Typical values are 2 and 3, for
example:
diag debug application DHCPS 2
diag debug application spamfilter 2
Fortinet support will advise which debugging level to use.
Timestamps can be enabled in the debug output using the following command:
diag debug console timestamp enable

01-420-99686-20101026 653
Debug Output Example

This example shows the IKE negotiation for a secure logging connection from a FortiGate
unit to a FortiAnalyzer system.
diag debug enable
diag debug application ike 3 <remote gateway IP address>
Sample Output:
FGh_FtiLog1: IPsec SA connect 0 192.168.11.2->192.168.10.201:500,
natt_mode=0 rekey=0 phase2=FGh_FtiLog1
FGh_FtiLog1: using existing connection, dpd_fail=0
FGh_FtiLog1: found phase2 FGh_FtiLog1
FGh_FtiLog1: IPsec SA connect 0 192.168.11.2 -> 192.168.10.201:500
negotiating
FGh_FtiLog1: overriding selector 225.30.5.8 with 192.168.11.2
FGh_FtiLog1: initiator quick-mode set pfs=1536...
FGh_FtiLog1: try to negotiate with 1800 life seconds.
FGh_FtiLog1: initiate an SA with selectors: 192.168.11.2/0.0.0.0-
>192.168.10.201, ports=0/0, protocol=0/0
Send IKE Packet(quick_outI1):192.168.11.2:500(if0) ->
192.168.10.201:500, len=348
Initiator: sent 192.168.10.201 quick mode message #1 (OK)
FGh_FtiLog1: set retransmit: st=168, timeout=6.
In this example:
192.168.11.2->192.168.10.201:500 Source and Destination gateway IP
address
dpd_fail=0 Found existing Phase 1
pfs=1536... Create new Phase 2 tunnel

654 01-420-99686-20101026
Other Commands
ARP Table
To view the ARP cache, use the following command:
get sys arp
To view the ARP cache in the system, use this command:

diag ip arp list
Sample Output:
index=14 ifname=internal 224.0.0.5 01:00:5e:00:00:05
state=00000040 use=72203 confirm=78203 update=72203 ref=1
index=13 ifname=dmz 192.168.3.100 state=00000020 use=1843
confirm=650179 update=644179 ref=2 ? VIP
index=13 ifname=dmz 192.168.3.109 02:09:0f:78:69:ff
index=14 ifname=internal 192.168.11.56 00:1c:23:10:f8:20
To remove the ARP cache, use this command:

execute clear system arp table
To remove a single ARP entry, use:

diag ip arp delete <interface name> <IP address>
To remove all entries associated with a particular interface, use this command:
diag ip arp flush <interface name>
To add static ARP entries, use the following command:

config system arp-table

01-420-99686-20101026 655
Time and Date Settings

Check time and date settings for log message timestamp synchronization (the Fortinet
support group may request this) and for certificates that have a time requirement to check
for validity. Use the following commands:
execute time
current time is: 12:40:48
last ntp sync:Thu Mar 16 12:00:21 2006
execute date
current date is: 2006-03-16
To force synchronization with an NTP server, toggle the following command:

set ntpsync enable/disable
If all devices have the same time, it helps to correlate log entries from different devices.
For more information on useful diagnostic commands, see “Troubleshooting get

commands” on page 687 and “Troubleshooting connectivity” on page 677.

656 01-420-99686-20101026
Troubleshooting tools FortiGate Ports
FortiGate Ports
In the TCP and UDP stacks, there are 65 535 ports available for applications to use when
communicating with each other. Many of these ports are commonly known to be
associated with specific applications or protocols. These known ports can be useful when
troubleshooting your network.
Use the following ports while troubleshooting the FortiGate device:
Port(s) Functionality
UDP 53 DNS lookup, RBL lookup
UDP 53 or UDP FortiGuard Antispam or Web Filtering rating lookup
8888
UDP 53 FDN Server List - source and destination port numbers vary by
(default) or UDP originating or reply traffic. See the article “How do I troubleshoot
8888 and UDP performance issues when FortiGuard Web Filtering is enabled?” in the
Knowledge Center.
1027 or UDP
1031
UDP 123 NTP Synchronization
UDP 162 SNMP Traps
UDP 514 Syslog - All FortiOS versions can use syslog to send log messages to
remote syslog servers. FortiOS v2.80 and v3.0 can also view logs
stored remotely on a FortiAnalyzer unit.
TCP 22 Configuration backup to FortiManager unit or FortiGuard Analysis and
Management Service.
TCP 25 SMTP alert email, encrypted virus sample auto-submit
TCP 389 or TCP LDAP or PKI authentication
636
TCP 443 FortiGuard Antivirus or IPS update - When requesting updates from a
FortiManager unit instead of directly from the FDN, this port must be
reconfigured as TCP 8890.
TCP 443 FortiGuard Analysis and Management Service
TCP 514 FortiGuard Analysis and Management Service log transmission (OFTP)
TCP 541 SSL Management Tunnel to FortiGuard Analysis and Management
Service (FortiOS v3.0 MR6 or later)
TCP 10151 FortiGuard Analysis and Management Service contract validation
TCP 514 Quarantine, remote access to logs and reports on a FortiAnalyzer unit,
device registration with FortiAnalyzer units (OFTP)
TCP 1812 RADIUS authentication

01-420-99686-20101026 657
Diagnostic Commands Troubleshooting tools
Diagnostic Commands

658 01-420-99686-20101026
Troubleshooting tools Diagnostic Commands
FortiAnalyzer/FortiManager Ports
If you have a FortiAnalyzer unit or FortiManager unit on your network you may need to use
the following ports for troubleshooting network traffic.
Functionality Port(s)
DNS lookup UDP 53
NTP synchronization UDP 123
Windows share UDP 137-138
SNMP traps UDP 162
Syslog, log forwarding UDP 514
Log and report upload TCP 21 or TCP 22
SMTP alert email TCP 25
User name LDAP queries for reports TCP 389 or TCP 636
RVS update TCP 443
RADIUS authentication TCP 1812
Log aggregation client TCP 3000
Note: For more information about FortiAnalyzer/FortiManager ports, see the Fortinet
Knowledge Center at the following address:
http://kc.forticare.com/default.asp?SID=&Lang=1&id=773.

01-420-99686-20101026 659
FortiGuard Troubleshooting Troubleshooting tools
FortiGuard Troubleshooting
The diag debug rating command shows the list of FDS servers the FortiGate unit is
using to send web filtering requests. Rating requests are only sent to the server on the top
of the list in normal operation. Each server is probed for RTT every two minutes.
diagnose debug rating
Sample Output:
Locale : english
License : Contract
Expiration : Thu Oct 9 02:00:00 2008
Hostname : a.b.c.d
-=- Server List (Mon Feb 18 12:55:48 2008) -=-
IP Weight RTT Flags TZ Packets CurrLost TotalLost

a.b.c.d. 0 1 DI 2 1926879 0 11176
g.h.u.y. 10 329 1 10263 0 633
r.h.g.t. 20 169 0 16105 0 80
e.b.a.u. 20 182 0 6741 0 776
x.c.v.b. 20 184 0 5249 0 987
q.w.e.r. 25 181 0 12072 0 178
Output Details
The following flags in diag debug rating indicate the server status:
• D - the server was found through the DNS lookup of the hostname. If the hostname
returns more than one IP address, all of them will be flagged with D and will be used
first for INIT requests before falling back to the other servers.
• I - the server to which the last INIT request was sent.
• F - the server has not responded to requests and is considered to have failed.
• T - the server is currently being timed.
Sorting the Server List

The server list is sorted first by weight. The server with the smallest RTT is put at the top
of the list, regardless of weight. When a packet is lost (there has been no response in 2
seconds), it will be resent to the next server in the list. Therefore, the top position in the list
is selected based on RTT while the other list positions are based on weight.
Calculating Weight
The weight for each server increases with failed packets and decreases with successful
packets. To lower the possibility of using a remote server, the weight is not allowed to dip
below a base weight, calculated as the difference in hours between the FortiGate unit and
the server times 10. The further away the server is, the higher its base weight and the
lower in the list it will appear.
Note: The output for the diag debug rating command will vary based on the state
of the FortiGate device.

660 01-420-99686-20101026
Troubleshooting tools FortiGuard Troubleshooting
The following output is from a FortiGate device that has no DNS resolution for
service.fortiguard.net.
If only three IP addresses appear with the D flag, it means that DNS is good but probably
the FortiGuard ports (53,8888) are blocked.
When the license is expired, an INIT request will be sent every 10 minutes for up to six
attempts. If a license is not found after this limit is reached, the INIT requests will be sent
every day.
A low source port number may appear which means that port 1024 and 1025 could be
blocked on the path to the FDS. Increase the source port on the FortiGate device with the
following commands:
config sys global
set ip-src-port-range <start-end> (Default 1024-25000)

01-420-99686-20101026 661
FortiGuard Troubleshooting Troubleshooting tools
FortiGuard URL Rating

The following commands can be used to troubleshoot issues with FortiGuard URL ratings:
diag debug enable
diag debug application urlfilter -1
Sample Output:
id=93000 msg="pid=57 urlfilter_main-723 in main.c received
pkt:count=91, a=/tmp/.thttp.socket/21" id=22009 msg="received
a request /tmp/.thttp.socket, addr_len=21: d=
="www.goodorg.org:80, id=12853, vfid=0, type=0,
client=192.168.3.90, url=/" id=99501 user="N/A"
src=192.168.3.90 sport=1321 dst=<dest_ip> dport=80
service="http" cat=43 cat_desc=“Organisation"
hostname="www.goodorg.org" url="/" status=blocked msg="URL
belongs to a denied category in policy"
Sample Output:
id=22009 msg="received a request /tmp/.thttp.socket,
addr_len=21: d=pt.dnstest.google.com:80, id=300, vfid=0,
type=0, client=192.168.3.12, url=/gen_204"
id=93003 user="N/A" src=192.168.3.12 sport=21715 dst=<dest_ip>
dport=80 service="http" cat=41 cat_desc="Search Engines"
hostname="pt.dnstest.google.com" url="/gen_204"
status=passthrough msg="URL belongs to an allowed category in
the policy"

662 01-420-99686-20101026
Technical Support Organization
Overview
Fortinet Global Customer Services Organization
The Fortinet Global Customer Services Organization is composed of three regional
Technical Assistance Centers (TAC):
• The Americas (AMER)
• Europe, Middle East, and Africa (EMEA)
• Asia Pacific (APAC)
The regional TACs are contacted through a global call center. Incoming service requests
are then routed to the appropriate TAC.
Each regional TAC delivers technical support to the customers in its regions during its
hours of operation. These TACs also combine to provide seamless, around-the-clock
support for all customers.
Regional TAC
· Focused Teams
APAC AMER · Technical Support
Corporate · RMA
CSS · Customer Services
· Remote Access Labs
AMEA
24x7
Regional TAC Global Call
Handling Layer

01-420-99686-20101026 663
Creating an Account Technical Support Organization Overview
Creating an Account
To receive technical support and service updates, Fortinet products in the organization
must be registered. The Product Registration Form on the support website will allow the
registration to be completed online.
Creating an account on the support website is the first step in registering products.
Once the account has been created, the Product Registration Form will be displayed and
the product details can be provided. Alternately, the product registration can be completed
at a later time.

664 01-420-99686-20101026
Technical Support Organization Overview Registering a Device
Registering a Device
Complete the following steps when registering a device for support purposes:
1 Log in using the Username and Password defined when the account was created.
2 Select Add Registration on the left-hand side.

01-420-99686-20101026 665
Registering a Device Technical Support Organization Overview
3 Select New Fortinet Product/License Registration.
4 Select the appropriate Product Model.

5 Enter the Serial Number.
6 Enter the Support Contract No. provided by Fortinet when the support contract was
purchased.
7 In the Product Description field, explain where this unit is physically located.
8 Click Next and accept the End User License Agreement (EULA) to complete the
registration.

666 01-420-99686-20101026
Technical Support Organization Overview Reporting Problems
Reporting Problems
Problems can be reported to a Fortinet Technical Assistance Center in the following ways:
• By logging an online ticket
• By phoning a technical support center
Logging Online Tickets

Problem reporting methods differ depending on the type of customer.
Fortinet Partners
Fortinet Partners are entitled to priority web-based technical support. This service is
designed for partners who provide initial support to their customers and who need to open
a support ticket with Fortinet on their behalf. We strongly encourage submission and
follow up of support tickets using this service.
The support ticket can be submitted after logging into the partner website using one of the
following links using FortiPartner account details:
http://partners.fortinet.com
This link will redirect to the general Partner Extranet website. Click Support > Online
Support Ticket.
https://www.forticare.com:1443/customersupport/login/partnerlog
in.aspx
This link redirects to the Partner Online Support Ticket section also known as FortiCare.
Note: The Partner Online Support Ticket section is accessed through HTTPS on port
1443. Ensure that the firewall allows external access this port. Also note that a
customer’s Fortinet device must have a valid support contract to be able submit the
support request as a Partner.

01-420-99686-20101026 667
Reporting Problems Technical Support Organization Overview
Fortinet Customers
Fortinet customers should complete the following steps to report a technical problem
online:
1 Log in to the support web site at the following address with the account credentials
used when the account was created:
http://support.fortinet.com
2 Click View Products.
3 In the Products List, select the product that is causing the problem.
4 Complete the Create Support Ticket fields.

668 01-420-99686-20101026

01-420-99686-20101026 669
Reporting Problems Technical Support Organization Overview
Following Up On Online Tickets

Perform the following steps to follow up on an existing issue.
Partners should log into the following web site:
http://partners.fortinet.com
Customer should log into the following site:
http://support.fortinet.com.
1 Login with the account credentials used when the account was created.
2 Click View Support Tickets on the left-hand side. Use the Search fields on the View
Tickets form to locate the tickets assigned to the account.
3 Select the appropriate ticket number. Closed tickets cannot be updated. A new ticket
must be submitted if it concerns the same problem.
4 Add a New Comment or Attachment.
5 Click Submit when complete.
Note: Every web ticket update triggers a notification to the ticket owner or ticket queue
supervisor.

670 01-420-99686-20101026
Telephoning a Technical Support Center

The Fortinet Technical Assistance Centers can also be contacted by phone.
Americas
• Telephone: 1-866-648-4638
• Hours: Monday to Friday 6:00 AM to 6:00 PM (Pacific Daylight Time)
EMEA
• Telephone: +33-4-898-0555
If a support call is placed outside of EMEA business hours (Monday to Friday 9:00 AM
to 6:00 PM (Central European Daylight Time)), priority 1 issues will be transferred to
another Fortinet Technical Solutions center according to the Follow the Sun policy,
meaning wherever it’s daylight, that TAC will be taking all support calls.
• Hours: Monday to Friday 9:00 AM to 6:00 PM (Central European Daylight Time)
APAC
• Telephone: +603-2711-7391
• Hours: Monday to Friday 9:00 AM to 6:00 PM (Malaysia Time)

01-420-99686-20101026 671
Assisting Technical Support Technical Support Organization Overview
Assisting Technical Support

The more information that can be provided to Fortinet technical support, the better they
can assist in resolving the issue. Every new support request should contain the following
information:
• A valid contact name, phone number, and email address.
• A clear and accurate problem description.
• A detailed network diagram with complete IP address schema.
• The configuration file, software version, and build number of the Fortinet device.
• Additional log files such as Antivirus log, Attack log, Event log, Debug log or similar
information to include in the ticket as an attachment. If a third-party product is involved,
for example, email server, FTP server, router, or switch, please provide the information
on its software revision version, configuration, and brand name.
The following Knowledge Center article provides an example of what type of technical
information and network diagram details should be submit to receive the quickest
resolution time to a problem:
http://kc.forticare.com/default.asp?id=1068&SID=&Lang=1

672 01-420-99686-20101026
Technical Support Organization Overview Support Priority Levels
Support Priority Levels

Fortinet technical support assigns the following priority levels to support cases:
Priority 1
This Critical priority is assigned to support cases in which:
• The network or system is down causing customers to experience a total loss of service.
• There are continuous or frequent instabilities affecting traffic-handling capability on a
significant portion of the network.
• There is a loss of connectivity or isolation to a significant portion of the network.
• This issue has created a hazard or an emergency.
Priority 2
This Major priority is assigned to support cases in which:
• The network or system event is causing intermittent impact to end customers.
• There is a loss of redundancy.
• There is a loss of routine administrative or diagnostic capability.
• There is an inability to deploy a key feature or function.
• There is a partial loss of service due to a failed hardware component.
Priority 3
This Medium priority is assigned to support cases in which:
• The network event is causing only limited impact to end customers.
• Issues seen in a test or pre-production environment exist that would normally cause
adverse impact to a production network.
• The customer is making time sensitive information requests.
• There is a successful workaround in place for a higher priority issue.
Priority 4
This Minor priority is assigned to support cases in which:
• The customer is making information requests and asking standard questions about the
configuration or functionality of equipment.
Customers must report Priority 1 and 2 issues by phone directly to the Fortinet EMEA
Support Center.
For lower priority issues, you may submit an assistance request (ticket) via the web
system.
The web ticket system also provides a global overview of all ongoing support requests.

01-420-99686-20101026 673
Return Material Authorization Process Technical Support Organization Overview
Return Material Authorization Process

In cases where hardware issues are being experiences and a replacement unit must be
sent. This is referred to as a Return Material Authorization (RMA). In the cases or RMAs,
the support contract must be moved to the new device. Customers can move the support
contract from the failing production unit to the new device through the support web site.
To start the process, log into the support web site with the credentials indicated when the
account was created.
From View Products, locate the serial number of the defective unit from the list of devices
displayed for the account.

674 01-420-99686-20101026
Technical Support Organization Overview Return Material Authorization Process
The Product Support Details for the selected device will be displayed.

01-420-99686-20101026 675
Return Material Authorization Process Technical Support Organization Overview
In the RMA Replacement section of the Product Support Details page, enter the serial
number of the replacement device and click RMA Replace.
This will transfer the support contract from the defective unit to the new unit with the serial
number provided.

676 01-420-99686-20101026
Troubleshooting connectivity
When there are connectivity problems it can be for a number of reasons - hardware
problems such as cabling or interfaces, routing problems, firewall problems, and so on.
These general troubleshooting tips provide a starting point for you to determine why your
network is behaving unexpectedly. This section includes general troubleshooting
methods. More in depth coverage of these topics, such as transparent mode and firewall
sessions, can be found in the Firewall Fundamentals section of this book.
The general troubleshooting tips include, and can help answer the following questions.
1 “Check hardware connections” on page 678
Are all the cables and interfaces connected properly?
2 “Run ping and traceroute” on page 678

Are you experiencing complete packet loss?
3 “Verify the contents of the routing table (in NAT mode)” on page 682
Are there routes in the routing table for default and static routes?
Do all connected subnets have a route in the routing table?
Does a route wrongly have a higher priority than it should?
4 “For Transparent mode, check the bridging information” on page 682

Are you having problems in transparent mode?
5 “Perform a sniffer trace” on page 683

Is traffic entering the FortiGate unit and does it arrive on the expected interface?
Is the ARP resolution correct for the next-hop destination?
Is the traffic exiting the FortiGate unit to the destination as expected?
Is the traffic being sent back to the originator?
6 “Debug the packet flow” on page 685

Is the traffic entering or leaving the FortiGate unit as expected?
7 “Examine the firewall session list” on page 686

Are there active firewall sessions?
In addition to these steps, you may find other diagnose commands useful. See “Other
diagnose commands” on page 686.

01-420-99686-20101026 677
Check hardware connections

If there is no traffic flowing from the FortiGate unit, it may be a hardware problem.
To check hardware connections

• ensure the network cables are properly plugged into the interfaces
• ensure there are connection lights for the network cables on the unit
• change the cable if the cable or its connector are damaged or you are unsure about the
cable’s type or quality—such as straight through or crossover, or possibly exposed
wires at the connector.
• connect the FortiGate unit to different hardware
• ensure the link status is set to Up for the interface, see Status > Network > Interface —
the link status is based on the physical connection and cannot be set in FortiOS
If any of these solve the problem, it was a hardware connection problem. You should still
perform some basic software connectivity tests to ensure complete connectivity. It might
also be that the interface is disabled, or have its Administrative Status set Down.
To enable an interface - web-based manager

1 Using the web-based management interface, go to System > Network > Interface.
2 Select and edit the interface to enable, such as port1.
3 Find Administrative Status at the bottom of the screen, and select Up.
4 Select Apply.
To enable an interface - CLI

edit port1
set status enable
next
end
Run ping and traceroute

Ping and traceroute are useful tools in network troubleshooting. Alone either one can
determine network connectivity between two points. However, ping can be used to
generate simple network traffic to view with diagnose commands on the FortiGate unit.
This combination can be a very powerful one in locating network problems.
In addition to their normal uses, ping and traceroute can tell you if your computer or
network device has access to a domain name server (DNS). While both tools can use IP
addresses alone, they can also use domain names for devices. This is an added
troubleshooting feature that can be useful in determining why particular services, such as
email or web browsing, may not be working properly.
Note: If ping does not work, you likely have it disabled on at least one of the interface
settings, and firewall policies for that interface.
Both ping and traceroute require particular ports to be open on firewalls, or they cannot
function. Since you typically use these tools to troubleshoot, you can allow them in the
firewall policies and on interfaces only when you need them, and otherwise keep the ports
disabled for added security.

678 01-420-99686-20101026
Ping
The ping command sends a very small packet to the destination, and waits for a response.
The response has a timer that may expire, indicating the destination is unreachable. The
behavior of ping is very much like a sonar ping from a submarine, where the command
gets its name.
Ping is part of Layer-3 on the OSI Networking Model. Ping sends Internet Control
Message Protocol (ICMP) “echo request” packets to the destination, and listens for “echo
response” packets in reply. However, many public networks block ICMP packets because
ping can be used in a denial of service (DoS) attack (such as Ping of Death or a smurf
attack), or by an attacker to find active locations on the network. By default, FortiGate units
have ping enabled and broadcast-forward is disabled on the external interface.
What ping can tell you

Beyond the basic connectivity information, ping can tell you the amount of packet loss (if
any), how long it takes the packet to make the round trip, and the variation in that time
from packet to packet.
If there is some packet loss detected, you should investigate:

• possible ECMP, split horizon, network loops
• cabling to ensure no loose connections
If there is total packet loss, you should investigate:

• hardware - ensure cabling is correct, and all equipment between the two locations is
accounted for
• addresses and routes - ensure all IP addresses and routing information along the route
is configured as expected
• firewalls - ensure all firewalls are set to allow PING to pass through
How to use ping

Ping syntax is the same for nearly every type of system on a network.
To ping from a Windows PC

1 Go to a DOS prompt. Typically you go to Start > Run, enter cmd and select OK.
2 Enter ping 10.11.101.100 to ping the default internal interface of the FortiGate unit
with four packets.
Other options include:
• -t to send packets until you press “Control-C”
• -a to resolve addresses to domain names where possible
• -n X to send X ping packets and stop
Output appears as:
C:\>ping 10.11.101.101
Pinging 10.11.101.101 with 32 bytes of data:

Reply from 10.11.101.101: bytes=32 time=10ms TTL=255
Reply from 10.11.101.101: bytes=32 time<1ms TTL=255

01-420-99686-20101026 679
Ping statistics for 10.11.101.101:

Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 10ms, Average = 3ms
To ping from a Linux PC

1 Go to a command line prompt.
2 Enter “/bin/etc/ping 10.11.101.101”.
Output appears as:
To ping from a FortiGate unit

1 Connect to the CLI either through telnet or through the CLI widget on the web-based
manager dashboard.
2 Enter exec ping 10.11.101.101 to send 5 ping packets to the destination. There
are no options.
Output appears as:
Head_Office_620b # exec ping 10.11.101.101
PING 10.11.101.101 (10.11.101.101): 56 data bytes
64 bytes from 10.11.101.101: icmp_seq=0 ttl=255 time=0.3 ms
--- 10.11.101.101 ping statistics ---

5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max = 0.2/0.2/0.3 ms
Traceroute
Where ping will only tell you if it reached its destination and came back successfully,
traceroute will show each step of its journey to its destination and how long each step
takes. If ping finds an outage between two points, traceroute can be used to locate exactly
where the problem is.
What is traceroute
Traceroute works by sending ICMP packets to test each hop along the route. It will send
out three packets, and then increase the time to live (TTL) setting by one each time. This
effectively allows the packets to go one hop farther along the route. This is the reason why
most traceroute commands display their maximum hop count before they start tracing the
route — that is the maximum number of steps it will take before declaring the destination
unreachable. Also the TTL setting may result in steps along the route timing out due to
slow responses. There are many possible reasons for this to occur.
Traceroute by default uses UDP datagrams with destination ports numbered from 33434
to 33534. The traceroute utility usually has an option to specify use of ICMP echo request
(type 8) instead, as used by the Windows tracert utility. If you have a firewall and if you
want traceroute to work from both machines (Unix-like systems and Windows) you will
need to allow both protocols inbound through your FortiGate firewall policies (UDP with
ports from 33434 to 33534 and ICMP type 8).

680 01-420-99686-20101026
How do you use traceroute

The traceroute command varies slightly between operating systems. Note that in MS
Windows the command name is shortened to “tracert”. Also note that your output will
list different domain names and IP addresses along your route.
To use traceroute on an MS Windows PC

1 Go to a DOS prompt. Typically you go to Start > Run, enter “cmd” and select OK.
2 Enter “tracert fortinet.com” to trace the route from the PC to the Fortinet
website.
Output will appear as:
C:\>tracert fortinet.com
Tracing route to fortinet.com [208.70.202.225]

over a maximum of 30 hops:
1 <1 ms <1 ms <1 ms 172.20.120.2
2 66 ms 24 ms 31 ms 209-87-254-xxx.storm.ca [209.87.254.221]
3 52 ms 22 ms 18 ms core-2-g0-0-1104.storm.ca [209.87.239.129]
4 43 ms 36 ms 27 ms core-3-g0-0-1185.storm.ca [209.87.239.222]
5 46 ms 21 ms 16 ms te3-x.1156.mpd01.cogentco.com [38.104.158.69]
6 25 ms 45 ms 53 ms te8-7.mpd01.cogentco.com [154.54.27.249]
7 89 ms 70 ms 36 ms te3-x.mpd01.cogentco.com [154.54.6.206]
8 55 ms 77 ms 58 ms sl-st30-chi-.sprintlink.net [144.232.9.69]
9 53 ms 58 ms 46 ms sl-0-3-3-x.sprintlink.net [144.232.19.181]
10 82 ms 90 ms 75 ms sl-x-12-0-1.sprintlink.net [144.232.20.61]
11 122 ms 123 ms 132 ms sl-0-x-0-3.sprintlink.net [144.232.18.150]
12 129 ms 119 ms 139 ms 144.232.20.7
13 172 ms 164 ms 243 ms sl-321313-0.sprintlink.net [144.223.243.58]
14 99 ms 94 ms 93 ms 203.78.181.18
15 108 ms 102 ms 89 ms 203.78.176.2
16 98 ms 95 ms 97 ms 208.70.202.225
Trace complete.
The first, or leftmost column, is the hop count, which cannot go over 30 hops.
The second, third, and fourth columns are how long each of the three packets takes to
reach this stage of the route. These values are in milliseconds and normally vary quite a
bit. Typically a value of “<1ms” indicates a local connection.
The fifth, or rightmost column, is the domain name of that device and its IP address or
possibly just the IP address.
To perform a traceroute on a Linux PC

2 Enter “/bin/etc/traceroute fortinet.com”.
The Linux traceroute output is very similar to the MS Windows tracert output.

01-420-99686-20101026 681
Verify the contents of the routing table (in NAT mode)

When you have some connectivity, or possibly none at all a good place to look for
information is the routing table.
The routing table is where all the currently used routes are stored for both static and
dynamic protocols. If a route is in the routing table, it saves the time and resources of a
lookup. If a route isn’t used for a while and a new route needs to be added, the oldest least
used route is bumped if the routing table is full. This ensures the most recently used routes
stay in the table. Note that if your FortiGate unit is in Transparent mode, you are unable to
perform this step.
If the FortiGate is running in NAT mode, verify that all desired routes are in the routing
table : local subnets, default routes, specific static routes, and dynamic routing protocols.
To check the routing table in the web-based manager, use the Routing Monitor — go to
System > Routing > Monitor. In the CLI, use the command get router routing-
table all.
For Transparent mode, check the bridging information

When FortiOS is in transparent mode, the unit acts like a bridge sending all incoming
traffic out on the other interfaces.
What checking the bridging information can tell you
How to check the bridging information

To list the existing bridge instance on the unit, use the following command:
diagnose netlink brctl (bridge control) list
Sample Output:
list bridge information
1. root.b fdb: size=256 used=6 num=7 depth=2
simple=no
Total 1 bridges
To display the forward domains, use the following command:

diagnose netlink brctl domain <name> <id>
Sample Output:
show bridge root.b ione forward domain.
id=101 dev=trunk_1 6
To list the existing bridge MAC table, use the following command:
diagnose netlink brctl name host <name>

682 01-420-99686-20101026
Sample Output:
show bridge control interface root.b host.
fdb: size=256, used=6, num=7, depth=2, simple=no
Bridge root.b host table
port no device devname mac addr ttl attributes
2 7 wan2 02:09:0f:78:69:00 0 Local Static
5 6 vlan_1 02:09:0f:78:69:01 0 Local Static
3 8 dmz 02:09:0f:78:69:01 0 Local Static
4 9 internal 02:09:0f:78:69:02 0 Local Static
3 8 dmz 00:80:c8:39:87:5a 194
4 9 internal 02:09:0f:78:67:68 8
1 3 wan1 00:09:0f:78:69:fe 0 Local Static
To list the existing bridge port list, use this command:

diagnose netlink brctl name port <name>
Sample Output:
show bridge root.b data port.
trunk_1 peer_dev=0
internal peer_dev=0
dmz peer_dev=0
wan2 peer_dev=0
wan1 peer_dev=0
Perform a sniffer trace

When troubleshooting networks and routing in particular, it helps to look inside the
headers of packets to determine if they are traveling along the route you expect that they
are. Packet sniffing can also be called a network tap, packet capture, or logic analyzing.
Note: If your FortiGate unit has NP2 interfaces that are offloading traffic, this will change
the sniffer trace. Before performing a trace on any NP2 interfaces, you should disable
offloading on those interfaces.
What can sniffing packets tell you

If you are running a constant traffic application such as ping, packet sniffing can tell you if
the traffic is reaching the destination, what the port of entry is on the FortiGate unit, if the
ARP resolution is correct, and if the traffic is being sent back to the source as expected.
Sniffing packets can also tell you if the Fortigate unit is silently dropping packets for
reasons such as RPF (Reverse Path Forwarding), also called Anti Spoofing, which
prevents an IP packet from being forwarded if its Source IP does not either belong to a
locally attached subnet (local interface), or be part of the routing between the FortiGate
and another source (static route, RIP, OSPF, BGP). Note that RPF can be disabled by
turning on asymmetric routing in the CLI (config system setting, set asymetric
enable), however this will disable stateful inspection on the FortiGate unit and cause
many features to be turned off.
Note If you configure virtual IP addresses on your Fortigate unit, it will use those
addresses in preference to the physical IP addresses. You will notice this when you are
sniffing packets because all the traffic will be using the virtual IP addresses. This is due to
the ARP update that is sent out when the VIP address is configured.

01-420-99686-20101026 683
How do you sniff packets

The general form of the internal FortiOS packet sniffer command is:
diag sniffer packet <interface_name> <‘filter’> <verbose>

<count>
To stop the sniffer, type CTRL+C.
<interface_name> The name of the interface to sniff, such as “port1” or “internal”.

This can also be “any” to sniff all interfaces.
<‘filter’> What to look for in the information the sniffer reads. “none”
indicates no filtering, and all packets will be displayed as the other
arguments indicate.
The filter must be inside single quotes (‘).
<verbose> The level of verbosity as one of:
1 - print header of packets
2 - print header and data from IP of packets
3 - print header and data from Ethernet of packets
<count> The number of packets the sniffer reads before stopping. If you
don’t put a number here, the sniffer will run forever unit you stop it
with <CTRL C>.
For a simple sniffing example, enter the CLI command diag sniffer packet port1
none 1 3. This will display the next 3 packets on the port1 interface using no filtering,
and using verbose level 1. At this verbosity level you can see the source IP and port, the
destination IP and port, action (such as ack), and sequence numbers.
In the output below, port 443 indicates these are HTTPS packets, and 172.20.120.17 is
both sending and receiving traffic.
Head_Office_620b # diag sniffer packet port1 none 1 3
interfaces=[port1]
filters=[none]
0.545306 172.20.120.17.52989 -> 172.20.120.141.443: psh
3177924955 ack 1854307757
0.545963 172.20.120.141.443 -> 172.20.120.17.52989: psh

1854307757 ack 3177925808
0.562409 172.20.120.17.52988 -> 172.20.120.141.443: psh

4225311614 ack 3314279933
For a more advanced example of packet sniffing, the following commands will report
packets on any interface travelling between a computer with the host name of “PC1” and
the computer with the host name of “PC2”. With verbosity 4 and above, the sniffer trace
will display the interface names where traffic enters or leaves the FortiGate unit.
Remember to stop the sniffer, type CTRL+C.
FGT# diagnose sniffer packet any "host <PC1> or host <PC2>" 4
or
FGT# diagnose sniffer packet any "(host <PC1> or host <PC2>) and
icmp" 4

684 01-420-99686-20101026
The following sniffer CLI command includes the ARP protocol in the filter which may be
useful to troubleshoot a failure in the ARP resolution (for instance PC2 may be down and
not responding to the FortiGate ARP requests).
FGT# diagnose sniffer packet any "host <PC1> or host <PC2> or

arp" 4
Debug the packet flow

Traffic should come in and leave the FortiGate. If you have determined that network traffic
is not entering and leaving the FortiGate unit as expected, debug the packet flow.
Debugging can only be performed using CLI commands. Debugging the packet flow
requires a number of debug commands to be entered as each one configures part of the
debug action, with the final command starting the debug.
Note: If your FortiGate unit has NP2 interfaces that are offloading traffic, this will change
the packet flow. Before performing the debug on any NP2 interfaces, you should disable
offloading on those interfaces.
The following configuration assumes that PC1 is connected to the internal interface of the
FortiGate unit and has an IP address of 10.11.101.200. PC1 is the host name of the
computer.
To debug the packet flow in the CLI, enter the following commands:
FGT# diag debug enable
FGT# diag debug flow filter add <PC1>
FGT# diag debug flow show console enable
FGT# diag debug flow trace start 100
FGT# diag debug enable
The start 100 argument in the above list of commands will limit the output to 100
packets from the flow. This is useful for looking at the flow without flooding your log or
display with too much information.
To stop all other debug activities, enter the command:

FGT# diag debug flow trace stop
The following is an example of debug flow output for traffic that has no matching Firewall
Policy, and is in turn blocked by the FortiGate unit. The denied message indicates the
traffic was blocked.
192.168.129.136:2854->192.168.96.153:1863) from port3."

msg="allocate a new session-013004ac"

id=20085 trace_id=319 func=fw_forward_handler line=248 msg="

Denied by forward policy check"

01-420-99686-20101026 685
Examine the firewall session list

One further step is to examine the firewall session. The firewall session can
When examining the firewall session list in the CLI, filters may be used to reduce the
output. In the web-based manager, the filters are part of the interface.
To examine the firewall session list in the web-based manager

1 Go to System > status > Dashboard > Top Sessions.
2 Select Detach, and then Details.
3 Expand the session window to full screen to display the information.
4 Change filters, view associated firewall policy, column ordering, and so on to analyze
the sessions in the table.
5 Select the delete icon to terminate the session.
To examine the firewall session list in the CLI

FGT# diag sys session filter src PC1
FGT# diag sys session list
or
FGT# diag sys session filter dst PC1
FGT# diag sys session list
To clear all sessions corresponding to a filter

FGT# diag sys session filter dst PC1
FGT# diag sys session clear
Other diagnose commands

Diagnose commands are a series of commands available on all FortiGate units. These
commands can help you troubleshoot network activity. The packet sniffer mentioned
earlier is only one of many useful diagnose commands.
For additional diagnostic commands, see “Troubleshooting get commands” on page 687.

686 01-420-99686-20101026
Troubleshooting get commands
This section lists the CLI get commands that you can use to troubleshoot problems with
exec tac report get system session-info full-stat

get firewall iprope list get system session-helper
get firewall iprope appctrl get system session-table list
get firewall proute get system session-table statistics
get hardware cpu get system session-info ttl
get hardware memory get system startup-error-log
get hardware nic get test application
get hardware npu ipsec-sa get test application urlfilter
get hardware npu list get vpn status ike config
get hardware npu performance get vpn status ike crypto
get hardware npu status get vpn status ike errors
get hardware status get vpn status ike status detailed
get ips session get vpn status ipsec
get router info kernel get vpn status ssl hw-acceleration-
get system arp status
get system auto-update version get vpn status ssl list
get system ha status get vpn status tunnel dialup-list
get system performance firewall get vpn status tunnel list
get system performance firewall get vpn status tunnel stat
packet-distribution get vpn status concentrator
get system performance status get webfilter ftgd-statistics
get system performance top get webfilter status
exec tac report

Displays all debugging information including hardware/software status and information,
configuration, and debug outputs.
Syntax
exec tac report
Parameters
None.
Usage/Remarks
Use this command to view the information required when calling customer support.
When you run this command, it will take up to a few minutes to collect and display all the
information.
Scope: Global and Vdom
Output Example
FGT # exec tac report
----------------------------------------------------------------
Serial Number: FGT5002803033313 Diagnose output

01-420-99686-20101026687
get firewall iprope listTroubleshooting get commands
----------------------------------------------------------------
Version: Fortigate-500 3.00,build0750,091009
Virus-DB: 8.00631(2008-01-15 14:27)
IPS-DB: 2.00461(2008-01-18 11:23)
Serial-Number: FGT5002803033313
BIOS version: 03000300
Log hard disk: Available
Hostname: FGT5002803033313
Operation Mode: NAT
Current virtual domain: root
Max number of virtual domains: 10
Virtual domains status: 2 in NAT mode, 1 in TP mode
Virtual domain configuration: enable
FIPS-CC mode: disable
Current HA mode: standalone
Distribution: International
Branch point: 750
MR/Patch Information: MR7 Patch 7
System time: Tue Dec 8 15:35:34 2009
get firewall iprope list

Displays the rules defined in the Policy Group defined in the parameter. If no parameter is
entered, all the rules of every Policy Group is displayed.
Syntax
get firewall iprope list <policy group number>
Parameters
<policy group > The number of the Policy Group as defined in the Web Config
menu Firewall > Policy > Policy tab.
Usage/Remarks
Use this command to view the view the rules defined for a Policy Group. This is useful to
understand the behavior of the Policy Group per protocol.
Scope: Vdom
Output Example
FGT # get firewall iprope list 1
policy flag (20): auth
flag2 (0): imflag: sockport: 0 action: accept index: 0
schedule() group=00000001 av=00000000 au=00000000 vip=00000000
host=0 misc=0 grp_info=0 seq=0 hash=0
tunnel=
zone(1): 0 ->zone(1): 0
source(1): 0.0.0.0-255.255.255.255,
dest(1): 0.0.0.0-255.255.255.255,
source wildcard(0):
destination wildcard(0):
service(1):
[17:0x0:0/(0,65535)->(53,53)]

68801-420-99686-20101026
Troubleshooting get commands get firewall iprope appctrl
nat(1): flag=0 base=0.0.0.0:53 0.0.0.0-0.0.0.0(53:53)

mms: 0 0
get firewall iprope appctrl

Displays the list of applications defined in the application control list.
Syntax
get firewall iprope appctrl list
get firewall iprope appctrl status
Parameters
Usage/Remarks
Use this command to view the view the rules defined for peer to peer, or the status of
those rules.
Scope: Vdom
Output Example
FGT # get firewall iprope appctrl list
app-id=17953 list-id=2004 action=Pass
FGT # get firewall iprope appctrl status

appctrl table 3 list 1 app 1083 shaper 0
Keyword/Variable Description
list Display all the application IDs, which list they are in by ID, and the action
taken for each application.
status Display the number of ipropes for application control tables, lists,
applications, and traffic shapers.
get firewall proute

Display configured policy routes.
Syntax
get firewall proute

01-420-99686-20101026689
get hardware cpuTroubleshooting get commands
Parameters
None.
Usage/Remarks
Use this command to view the policy routes configured on this unit’s current VDOM.
Scope: Vdom
Output Example
FGT # get firewall proute
list route policy info(vf=root):
iff=12 src=10.10.10.0/255.255.255.0 tos=0x00 tos_mask=0x00

dst=10.10.11.0/255.255.255.0 protocol=11 port=1:65535
oif=13 gwy=0.0.0.0
vf The current virtual domain (VDOM). All policy routes for this VDOM are
displayed.
iff Incoming interface
src The source IP and netmask for incoming traffic to be matched to the
policy
tos Type of service bit pattern in hexadecimal. This is matched and is good
for a specific TOS.
tos_mask Type of service bit mask in hexadecimal. Masks out unwanted bits. This
is good for matching multiple TOS values.
dst The destination IP and netmask for incoming traffic to be matched to the
policy.
protocol The protocol number to be matched.
port The range of ports to match for incoming traffic.
oif Outgoing interface where traffic is being directed to.
gwy Outgoing gateway where traffic is being directed to
get hardware cpu

Displays the CPU information.
Syntax
get hardware cpu
Parameters
Usage/Remarks
Use this command to view the specifications about all CPUs on the FortiGate unit.
Scope: Global

69001-420-99686-20101026
Troubleshooting get commands get hardware cpu
Output Example
FGT # get hardware cpu
Description sundance Ethernet driver1.01+LK1.21
chip_id 6
IRQ 5
System_Device_Name wan1
State up
Link up
Speed 100
Duplex full
Rx_Packets 52377
Tx_Packets 53098
Rx_Packets 47029877
Tx_Bytes 7199983
Collisions 0
Rx_Missed_Errors 0
Tx_Carrier_Errors 0
Description Name of the network driver.
chip_id Id of the chipset
IRQ IRQ
System_Device_Name Network device name (i.e. The physical interface name).
Current_HWaddr Current MAC address.
Permanent_HWaddr Permanent MAC address.
State Administrative status (up/down).
Link Link status (up/down).
Speed Negotiated or configured network speed.
Duplex Negotiator configured duplex mode.
Rx_Packets Packets' number received by the network device.
Tx_Packets Packets number transmitted by the network device.
Rx_Packets Amount of bytes received on the interface.
Tx_Bytes Amount of bytes sent from this interface.
Collisions Number of collisions usually due mostly to incorrect incorrect speed or
duplex settings.
Only valid in 1000M mode, which is marked by PHY.
transmission. Failure to do so may indicate that the link has failed, or
the PHY has an incorrect link configuration. This register only
increments if transmits are enabled. This register is not valid in internal
SerDes1 mode (TBI mode for the 82544GC/EI), and is only valid when
the Ethernet controller is operating at full duplex.

01-420-99686-20101026691
get hardware nicTroubleshooting get commands
get hardware nic

Displays information and statistics for the network interface card (NIC) specified.
Syntax
get hardware nic <interface>
Parameters
<interface> Enter the interface name. For example, internal, wan1, wan2.
Usage/Remarks
Use this command to view the interface information and statistics. This is useful when
debugging network problems on a particular interface, or providing Customer Support with
hardware information about your FortiGate unit.
Note that the output will be different for different NICs
Scope: Global
Output Example
FGT # get hardware nic wan1
Description sundance Ethernet driver1.01+LK1.21
chip_id 6
IRQ 5
System_Device_Name wan1
State up
Link up
Speed 100
Duplex full
FlowControl Tx off, Rx off
MTU_Size 1500
Rx_Packets 52377
Tx_Packets 53098
Rx_Packets 47029877
Tx_Bytes 7199983
Collisions 0
Rx_Missed_Errors 0
Tx_Carrier_Errors 0
Description Name of the network driver.
chip_id Id of the chipset
IRQ IRQ
System_Device_Name Network device name (i.e. The physical interface name).
Current_HWaddr Current MAC address.
Permanent_HWaddr Permanent MAC address.

69201-420-99686-20101026
Troubleshooting get commands get hardware cpu
State Administrative status (up/down).
Link Link status (up/down).
Speed Negotiated or configured network speed.
Duplex Negotiated or configured duplex mode.
Rx_Packets Packets' number received by the network device.
Tx_Packets Packets number transmitted by the network device.
Rx_Packets Amount of bytes received on the interface.
Tx_Bytes Amount of bytes sent from this interface.
Collisions Number of collisions usually due mostly to incorrect incorrect speed or
duplex settings.
Only valid in 1000M mode, which is marked by PHY.
transmission. Failure to do so may indicate that the link has failed, or
the PHY has an incorrect link configuration. This register only
increments if transmits are enabled. This register is not valid in internal
SerDes1 mode (TBI mode for the 82544GC/EI), and is only valid when
the Ethernet controller is operating at full duplex.
get hardware cpu

Displays the detailed information for all installed CPUs on this unit.
Syntax
get hardware cpu
Parameters
None.
Usage/Remarks
Use this command to view detailed information about all CPUs on this unit. They are
numbered starting from zero. This list includes the main CPU, any NPUs, and any other
CPUs.
In addition to the brand, family, model, model name, speed and cache of the CPUs you
can also view the flags that are set which may help with advanced debugging.
Scope: Global
Output Example
FGT # get hardware cpu
processor : 0
vendor_id : GenuineIntel
cpu_family : 6
model : 8
model name : Pentium III (Coppermine)
stepping : 10
cpu Mhz : 701.596
cache size : 256 KB
fdiv_bug : no

01-420-99686-20101026693
get hardware memoryTroubleshooting get commands
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception: yes
cpuid level : 2
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca
cmov pat pse36 mmx fxsr sse
bogomips : 1399.19
get hardware memory

Displays the status of the memory resources.
Syntax
get hardware memory
Parameters
None.
Usage/Remarks
Use this command to view the status of the memory resources. This is useful to confirm
and identify any potential memory leaks or even to simply confirm that reduced FortiOS
performance is due to a shortage of free memory.
Scope: Global
Output Example
FGT # get hardware memory
total: used: free: shared: buffers: cached: shm:

Mem: 261955584 97312768 164642816 0 217088 55382016 51322880
Swap: 0 0 0
MemTotal: 255816 kB
MemFree: 160784 kB
MemShared: 0 kB
Buffers: 212 kB
Cached: 54084 kB
SwapCached: 0 kB
Active: 22832 kB
Inactive: 31524 kB
HighTotal: 0 kB
HighFree: 0 kB
LowTotal: 255816 kB
LowFree: 160784 kB
SwapTotal: 0 kB
SwapFree: 0 kB

69401-420-99686-20101026
Troubleshooting get commands get hardware npu ipsec-sa
Mem Memory size.
Swap Amount of memory in the swap
MemTotal HighTotal + LowTotal = amount of memory available on the unit
MemFree Free memory on the unit
SwapCached Amount of memory out of the Swap but remaining in the cache
Active Amount of memory recently used
Inactive Amount of memory which has not been used for a while
HighTotal Amount of memory which belongs to the zone ZONE_HIGHMEM
LowFree Amount of Free memory available in the zone ZONE_NORMAL
get hardware npu ipsec-sa

Display the IPSec security association (SA) of the network processing unit (NPU).
To apply hardware accelerated encryption and decryption, the FortiGate unit’s main
processing resources must first perform Phase I negotiations to establish the security
association (SA). The SA includes cryptographic processing instructions required by the
network processor, such as which encryption algorithms must be applied to the tunnel.
After ISAKMP negotiations, the FortiGate unit’s main processing resources send the SA to
the network processor, enabling the network processor to apply the negotiated hardware
accelerated encryption or decryption to tunnel traffic.
Syntax
get hardware npu { npu1 | npu2 | npu4} ipsec-sa <dev_name>
Parameters
<dev-name>
Usage/Remarks
Use this command to view the security association for hardware acceleration.
Scope: Global
get hardware npu list

Displays the network processing unit (NPU) devices and paired interface names.
This is important to know because the paired interfaces can be offload their traffic from the
main CPU to their NPU. However this can only be accomplished with paired interfaces.
Syntax
get hardware npu { legacy | np1 | np2 | np4 } list
Parameters
{ legacy | np1 | Specify which level of NPU interfaces are to be displayed.

np2 | np4 }

01-420-99686-20101026695
get hardware npu listTroubleshooting get commands
Usage/Remarks
Use this command to view the NPU devices and port numbers. This is useful because
some FortiOS products contain contain network processors. Network processor features,
and therefore offloading requirements, vary by network processor model.
If the specified version of NPU is not present on this FortiOS unit, a message indicating
that will be displayed.
Scope: Global
Output Example
FGT # get hardware npu np1 list
ID Interface
0 port9 port10
FGT # get hardware npu np2 list

ID PORTS
-- -----
0 port1
0 port2
0 port3
0 port4
ID PORTS
-- -----
1 port5
1 port6
1 port7
1 port8
ID PORTS
-- -----
2 port9
2 port10
2 port11
2 port12
ID PORTS
-- -----
3 port13
3 port14
3 port15
3 port16
ID The ID of the NPU assigned to these ports.
Interface The names of the interfaces in the NPU’s paired group.
An NPU can handle either two or four ports. Any incoming traffic on this
group of ports that leaves the FortiOS unit on the same group of ports
can be handled by the NPU. Otherwise, the unit’s CPU will be involved.
PORTS The names of the ports in the NPU’s group.

69601-420-99686-20101026
Troubleshooting get commands get hardware npu performance
get hardware npu performance

Displays the NPU performance for ISCP2, messages, and NAT.
Syntax
get hardware npu { legacy | np1 | np2 | np4 }performance <dev_id>
Parameters

np2 | np4 }
<dev_id> NPU ID number. If you are unsure you can enter a “?” to get a list
of available valid NPU ID numbers.
Usage/Remarks
Use this command to view the performance numbers for NPU devices. This can be useful
when you are checking NPU traffic—either for specific problems or for network
optimization.
Network processor features, and therefore offloading requirements, vary by network
processor model.
The values displayed are generally counts for the stated values. For example BADCSUM
is the number of bad checksums encountered.
Scope: Global
Output Example
FGT # get hardware npu np2 performance 1
ISCP2 Performance:
Nr_int : 0x00000005 INTwoInd : 0x00000000 RXwoDone :
0x00000000
PKTwoEnd : 0x00000000 PKTCSErr : 0x00000000
PKTidErr : 0x00000000 PHYInt : 0x0/0x0/0x0/0x0
CSUMOFF : 0x00000000 BADCSUM : 0x00000000 MSGINT :
0x00000000
IPSEC : 0x00000000 IPSVLAN : 0x00000000 SESMISS :
0x00000000
TOTUP : 0x00000000 TCPPLTOT : 0x00000000 TCPPLBADCT:
0x00000000
TCPPLBADL: 0x00000000 TCPPLSESI : 0x00000000 TCPPLSESR :
0x00000000
TCPPLBD : 0x00000000 TXInt : 0x0/0x0/0x0/0x0 RxI : 0x0
BDEmpty : 0x0/0x0/0x0/0x0 Congest: 0x0/0x0/0x0/0x0
TMM_Busy : 0x0
Poll List: 0 0 0 0
MSG Performance:
TOTMSG : 0x00000000 BADMSG : 0x00000000 TOUTMSG :
0x00000000 MSGLostEvent : 0x00000000
QUERY : 0x00000000 TAE : 0x00000000
SAEXP-SN : 0x00000000 SAEXP-TRF : 0x00000000 OUTUPD :
0x00000000 INUPD : 0x00000000
NULLTK: 0x00000000
NAT Performance: BYPASS (Enable) BLOCK (Disable)

01-420-99686-20101026697
get hardware npu statusTroubleshooting get commands
IRQ :00000005 QFTL :00000000 DELF :00000000 FFTL :00000000

OVTH :00000005 QRYF :00000000 INSF :00000000 INVC :00000000
ALLO :00000005 FREE :00000005 ALLOF :00000000 BPENTR:00000000 B
KENTR:00000000
PBPENTR:00000000 PBKENTR:00000000 NOOP :00000000 THROT :0000000
0(0x002625a0)
SWITOT:00000000 SWDTOT:00000000 ITDB:00000000 OTDB:000000000
SPISES:00000000 FLUSH:00000021
ISCP2 Performance This section displays information about the ISCP2 performance.
MSG Performance This section displays information about message traffic performance.
NAT Performance This section displays information about NAT traffic performance.
If BYPASS is enabled many of the counters will be zero.
get hardware npu status

Displays the NPU device status.
Syntax
get hardware npu { legacy | np1 | np2 | np4 }status <dev_id>
Parameters
np2 | np4 }
<dev_id> NPU ID number. If you are unsure you can enter a “?” to get a list
of available valid NPU ID numbers.
Usage/Remarks
Use this command to display the status of the interfaces attached to the NPU. This can be
useful for advanced users to debug traffic on the NPU interfaces.
If you enter an NPU or device ID that doesn’t exist, an error message stating that it was na
invalid NPU ID will be displayed.
Scope: Global
Output Example
FGT # get hardware np2 status 1
NP2 Status
ISCP2 c2160000 (Neighbor f7940000) 1a29:0703 256MB Base f8a5a000

DBG 0x00000000
RX SW Done 0 MTP 0x0
desc_alloc = c2152000
desc_size = 0x2000 count = 0x100
nxt_to_u = 0x0 nxt_to_f = 0x0
Total Interfaces: 4 Total Ports: 4
Number of Interface In-Use: 4
Interface c2160100 netdev c22bb000 0 Name port5

69801-420-99686-20101026
Troubleshooting get commands get hardware status
PHY: Attached
LB Mode 0 LB IDX 0/1 LB Ports: c2160644, 00000000, 00000000,
00000000
Port c2160644 Id 0 Status Down ictr 4
desc = c2232000
nxt_to_u = 0x00000000 nxt_to_f = 0x00000000
Intf c2160100
Interface c2160250 netdev c2168c00 1 Name port6
PHY: Attached
LB Mode 0 LB IDX 0/1 LB Ports: c21606f8, 00000000, 00000000,
00000000
Port c21606f8 Id 1 Status Down ictr 0
desc = c2126000
nxt_to_u = 0x00000000 nxt_to_f = 0x00000000
Intf c2160250
Interface c21603a0 netdev c2168800 2 Name port7
PHY: Attached
LB Mode 0 LB IDX 0/1 LB Ports: c21607ac, 00000000, 00000000,
00000000
Port c21607ac Id 2 Status Down ictr 0
desc = c2123000
nxt_to_u = 0x00000000 nxt_to_f = 0x00000000
Intf c21603a0
Interface c21604f0 netdev c2168400 3 Name port8
PHY: Attached
LB Mode 0 LB IDX 0/1 LB Ports: c2160860, 00000000, 00000000,
00000000
Port c2160860 Id 3 Status Down ictr 0
desc = c2122000
nxt_to_u = 0x00000000 nxt_to_f = 0x00000000
Intf c21604f0
NAT Information:
cmdq_qw = 0x2000 cmdq = c2140000
head = 0x5 tail = 0x5
APS (Enabled) information:
Session Install when TMM TSE OOE: Disable
Session Install when TMM TAE OOE: Disable
IPS anomaly check policy: Follow config
MSG Base = c2130000 QL = 0x1000 H = 0x0
get hardware status

Displays basic hardware information about the unit.
Syntax
get hardware status

01-420-99686-20101026699
get ips sessionTroubleshooting get commands
Parameters
None.
Usage/Remarks
Use this command to get basic information about your unit’s hardware. This is a short list
that can be used to help guide troubleshooting efforts, especially by customer service. For
example if there is supposed to be compact flash memory available but this command
shows 0MB available, then you know there is a hardware problem with the memory.
Scope: Global
Output Example
FGT # get hardware status
Model name: Fortigate-3810A
ASIC version: CP6
ASIC SRAM: 64M
CPU: 02/21
RAM: 3532 MB
Compact Flash: 122 MB /dev/hda
USB Flash: not available
Network Card chipset: Broadcom 570x Tigon3 Ethernet Adapter
(rev.0x8003)
Network Card chipset: Intel(R) PRO/1000 Network Connection
(rev.0006)Related Commands
get ips session

Displays the IPS session status. An Intrusion prevention system (IPS) is a network
security device that monitors network and/or system activities for malicious or unwanted
behavior and can react, in real-time, to block or prevent those activities.
Syntax
get ips session
Parameters
None.
Usage/Remarks
Viewing the IPS session status allows you to see if traffic is checked by the IPS engine
and if the IPS engine is working as expected. You can see the type of traffic and how
many sessions are being processed by the IPS engine. You can also see how much
memory the IPS engine is using.
Scope: Vdom
Output Example
FGT # get ips session
SYSTEM:
memory capacity 73400320
memory used 3982780

70001-420-99686-20101026
Troubleshooting get commands get router info kernel
recent pps\bps 0\0K

session in-use 0
TCP: in-use\active\total 0\0\0
UDP: in-use\active\total 0\0\0
ICMP: in-use\active\total 0\0\0
memory capacity Total memory capacity in system.
memory used Used memory in system by IPS session.
recent pps\bps Recent IPS traffic in packets per second (pps) and bits per second
(bps).
session in-use Current IPS sessions in use.
TCP: in- The number of in use, active, and totalTransmission Control Protocol
use\active\total (TCP) messages.
UDP: in- The number of in use, active, and total User Datagram Protocol (UDP)
use\active\total messages.
ICMP: in- The number of in use, active and total Internet Control Message
use\active\total Protocol (ICMP) messages.
get router info kernel

Displays the kernel routing table.
Syntax
get router info kernel
Parameters
None.
Usage/Remarks
Use this command to view the kernel routing table. Almost all computers and network
devices connected to Internet use routing tables to compute the next hop for a packet. It is
electronic table that is stored in a router or a networked computer. The routing table stores
the routes to particular network destinations. This information contains the topology of the
network immediately around it. The construction of routing table is the primary goal of
routing protocols and static routes.
Scope: Vdom
Output Example
FGT # get router info kernel
tab=254 vf=2 scope=0 type=1 proto=11 prio=0 0.0.0.0/0.0.0.0/0-
>192.168.0.0/24 pref=0.0.0.0 gwy=9.1.1.1 dev=5(port1)
192.168.0.0/24 The destination network or destination host.
gwy=9.1.1.1 The gateway address for the next hop.
dev=5(port1) Interface to which packets for this route is sent.

01-420-99686-20101026701
get system arpTroubleshooting get commands
get system arp

Displays the IPv4 ARP table.
Syntax
get system arp
Parameters
None.
Usage/Remarks
This command is useful to view or alter the contents of the kernel's ARP tables. For
example when you suspect a duplicate Internet address is the cause for some intermittent
network problem.
This command is not available in multiple VDOM mode.
Scope: Vdom
Output Example
FGT # get system arp
Address Age(min) Hardware Addr Interface
172.20.120.16 0 00:0d:87:5c:ab:65 internal
172.20.120.138 0 00:08:9b:09:bb:01 internal
Address The IP address that is linked to the MAC address. The default is
0.0.0.0
Age Current duration of the ARP entry in minutes. The default is 0.
Hardware Addr The hardware, or MAC address, to link with this IP
address. The default is 00:00:00:00:00:00:
Interface The physical interface the address is on.
get system auto-update

Use this command to display information about the status FortiGuard updates on the
FortiGate unit.
Syntax
get system auto-update status
get system auto-update versions
Parameters
None.
Usage/Remarks
Use this command when you need to view the current antivirus and IPS status from the
FortiGate.

70201-420-99686-20101026
Troubleshooting get commands get system auto-update
The status command is used to test the current connectivity status, and can retrieve
configuration information, such as Push Updates, Update schedules, or other parameters
related to the FortiGuard service operation.
The versions command provides extended information about each FortiGuard component
and its version, build number, contract expiry date, last update attempts and results.
Note: Result: Connectivity failure indicates the connections to the FortiGuard

servers is not possible. This may be a serious problem that needs to be addressed. Until it
is solved, you may not receive any FortiGuard updates leaving your network vulnerable.
These commands also allow the user to check whether the FortiGate is running the latest
AV and IPS packages.
Scope: Global
Output Example
FGT # get system auto-update status
FDN availabilty: available at Mon May 26 20:16:43 2008
Push update: disable

Scheduled update: enable
Update every: 1 hours at 16 minutes after the hour
Virus definitions update: enable
IPS definitions updates: enable
Server override: disable
Push address override: disable
Web proxy tunneling: disable
FDN availabilty Specify availability status and last access time (access time
corresponds to the scheduled update settings).
Possible values are: available/unavailable.
Push update Specify wether push update method is enabled or disabled.
Possible values are: enable/disable
Scheduled update Specify wether scheduled update is enabled or disabled.
Possible values are: enable/disable.
Update every If scheduled update is enabled, specify the time defined to launch
the update.
IPS definitions updates Specify wether the IPS definitions update is enabled or disabled.
Server override Specify wether the use of another FDS server is enabled or
disabled.
If enabled a new line is displayed showing the FDS IP address
defined in the configuration.
For example:
Server override: enable
Server: 10.0.0.1

01-420-99686-20101026703
get system auto-updateTroubleshooting get commands
Push address override If push update is enabled, specify wether the Fortigate override
address feature is enabled or disabled.
If enabled, a new line is displayed showing the FDS IP address
and the TCP port (a.b.c.d:port) defined in the configuration.
Example:
Push address override: enable
Address: 10.0.0.2:9443
Web proxy tunneling Specify wether FortiGate device is using a proxy to retrieve AV
and IPS definitions updates.
If enabled, additional lines are displayed showing the proxy
settings.
Example:
Web proxy tunneling: enable
Proxy address: 10.0.0.3
Proxy port: 8890
Username: foo
Password: foo
FGT # get system auto-update versions

Last Update Attempt: Thu Sep 16 01:37:08 2010
Result: Connectivity failure
Attack Definitions
---------
Version: 2.00720
Contract Expiry Date: n/a
Last Updated using manual update on Tue Dec 1 17:55:00 2009
IPS Attack Engine

---------
Version: 1.00161
Last Updated using manual update on Tue Mar 23 15:21:00 2010
AS Rule Set
---------
Version: 1.00001
AS Engine
---------
Version: 1.00001
Build: 0111
Vulnerability Compliance and Mangement

70401-420-99686-20101026
Troubleshooting get commands get system auto-update version
---------
Version: 1.00098
Last Updated using manual update on Thu Feb 11 16:40:00 2010
Last Update Attempt: n/a
Result: Updates Installed
get system auto-update version

Displays antivirus and IPS engines and definitions, and license information.
Syntax
get system auto-update version
Parameters
None.
Usage/Remarks
Use this command to view the antivirus and IPS engines and definitions and license
information. This is useful in determining when the antivirus engine, virus definitions,
attack definitions, IPS attack definitions, AS Rule set, AS engine, and FDS address were
last updated, when their contracts expire, which version they are using, and the result of
the last update.
Scope: Global
Output Example
FGT # get system auto-update version
AV Engine
---------
Version: 3.003
Last Updated using manual update on Wed Jan 9 18:26:00 2008
Virus Definitions
---------
Version: 8.631
Last Updated using manual update on Tue Jan 15 14:27:00 2008
Attack Definitions
---------
Version: 2.461
Last Updated using manual update on Fri Jan 18 11:23:00 2008

01-420-99686-20101026705
get system ha statusTroubleshooting get commands
IPS Attack Engine

---------
Version: 1.091
Last Updated using manual update on Wed Jan 9 18:22:00 2008
FDS Address
---------
Version Version number of the engine or the definitions.
Contract Expiry Date The date the contract expires.
Last Updated using Date of the last manual update.
manual update on
Last Update Attempt The date when the last update was attempted.
Result The status of the last update.
get system ha status

Use this command to display information about an HA cluster. The command displays
general HA configuration settings. The command also displays information about how the
cluster unit that you have logged into is operating in the cluster.
Syntax
get system ha status
Parameters
None.
Usage/Remarks
Usually you would log into the primary unit CLI using SSH or telnet. In this case the
diagnose system ha status command displays information about the primary unit
first, and also displays the HA state of the primary unit (the primary unit operates in the
work state).
For a virtual cluster configuration, the diagnose system ha status command displays
information about how the cluster unit that you have logged into is operating in virtual
cluster 1 and virtual cluster 2. For example, if you connect to the cluster unit that is the
primary unit for virtual cluster 1 and the subordinate unit for virtual cluster 2, the output of
the diagnose system ha status command shows virtual cluster 1 in the work state and
virtual cluster 2 in the standby state. The diagnose system ha status command also
displays additional information about virtual cluster 1 and virtual cluster 2.
See the FortiGate CLI Reference Guide for more information.
Scope: Global

70601-420-99686-20101026
Troubleshooting get commands get system performance firewall
Output Example
FGT # get system ha status
Model: 5000
Mode: a-a
Group: 0
Debug: 0
ses_pickup: disable
load_balance: disable
schedule: round robin
Master:128 5001_Slot_4 FG50012204400045 1
Slave :100 5001_Slot_3 FG50012205400050 0
number of vcluster: 1
vcluster 1: work 10.0.0.2
Master:0 FG50012204400045
Slave :1 FG50012205400050
Model The FortiGate model number.
Mode The HA mode of the cluster: a-a or a-p.
Group The group ID of the cluster.
Debug The debug status of the cluster.
ses_pickup The status of session pickup: enable or disable.
load_balance The status of the load-balance-all keyword: enable or disable.
Relevant to active-active clusters only.
schedule The active-active load balancing schedule. Relevant to active-active
clusters only.
Master Master displays the device priority, host name, serial number, and
Slave cluster index of the primary (or master) unit.
Slave displays the device priority, host name, serial number, and cluster
index of the subordinate (or slave, or backup) unit or units.
The list of cluster units changes depending on how you log into the CLI.
Usually you would use SSH or telnet to log into the primary unit CLI. In
this case the primary unit would be at the top the list followed by the
other cluster units.
If you use execute ha manage or a console connection to log into a
subordinate unit CLI, and then enter diagnose system ha status the
subordinate unit that you have logged into appears at the top of the list
of cluster units.
number of vcluster The number of virtual clusters. If virtual domains are not enabled, the
cluster has one virtual cluster. If virtual domains are enabled the cluster
has two virtual clusters.
get system performance firewall

Displays the status of important software and hardware systems on your FortiGate unit.
Syntax
get system performance firewall packet-distribution
get system performance firewall statistics
Parameters
None

01-420-99686-20101026707
get system performance firewall packet-distributionTroubleshooting get commands
Usage/Remarks
Use this command to quickly see information about traffic through the firewall.
The Packet-distribution command divides network traffic into ten different packet sizes and
lists the number of packets in each category. This can help you spot hacking attempts or
optimize your network.
The Statistics command provides packet and byte counts for different major protocols and
packet types through the firewall. Packet types include TCP, UDP, ICMP, and IP.
Scope: All (Global and Vdom)
Output Example
FGT# get sys per firewall packet-distribution
getting packet distribution statistics...
0 bytes — 63 bytes: 3624747 packets
> 1500 bytes: 0 packets
FGT# get sys per firewall statistics

getting traffic statistics...
Browsing: 708624 packets, 408018318 bytes
DNS: 411789906583486464 packets, 0 bytes
E-Mail: 0 packets, 0 bytes
FTP: 0 packets, 0 bytes
Gaming: 0 packets, 0 bytes
IM: 0 packets, 0 bytes
Newsgroups: 0 packets, 0 bytes
P2P: 0 packets, 0 bytes
Streaming: 0 packets, 0 bytes
TFTP: 201239863725391872 packets, 56530359549952 bytes
VoIP: 3543070 packets, 25 bytes
Generic TCP: 55834574848 packets, 1786706395136 bytes
Generic UDP: 0 packets, 0 bytes
Generic ICMP: 0 packets, 0 bytes
Generic IP: 0 packets, 0 bytes

Displays the statistical data of the different size packets that go through the firewall.
Syntax
Parameters
None.

70801-420-99686-20101026
Troubleshooting get commands get system performance status
Usage/Remarks
Use this command to view the number of packets received in each of the listed sizes. This
can help find MTU related problems where larger packets are being split up or not
received properly.
Scope: Vdom
Output Example
FGT # get system performance firewall packet-distribution
getting packet distribution statistics...
> 1500 bytes: 0 packets
get system performance status

Displays the status of important software and hardware systems on your FortiGate unit.
Syntax
get system performance status
Parameters
Usage/Remarks
Use this command to quickly see important information about your FortiGate unit’s state.
Information includes CPU usage, memory usage, network usage, number of sessions,
viruses caught, IPS attacks blocked, and FortiGate unit uptime. These numbers provide a
quick look at how the FortiGate unit is doing. If any one number needs attention, you can
use other commands to get more information on that area.
Output Example
FGT# get sys performance status
CPU states: 0% user 0% system 0% nice 100% idle
Memory states: 10% used
Average network usage: 0 kbps in 1 minute, 0 kbps in 10 minutes,
13 kbps in 30 minutes
Average sessions: 31 sessions in 1 minute, 30 sessions in 10
minutes, 31 sessions in 30 minutes
Virus caught: 0 total in 1 minute
IPS attacks blocked: 0 total in 1 minute
Uptime: 44 days, 18 hours, 42 minutes

01-420-99686-20101026709
get system performance topTroubleshooting get commands
get system performance top

Displays the processes running on your FortiGate unit.
Syntax
get system performance top <delay> <max_lines>
Parameters
delay The amount of time, in seconds, in which the process information

is polled. The default is 5 seconds.
max_lines The maximum number of processes displayed in the output. The
default is 20 lines.
Usage/Remarks
Use this command when you need to view the processes running and the information
about each process. It displays as a static set of columns where the information changes
in place. To exit this display, press <Ctrl-C>.
Output Example
FGT # get system performance top 5 20
Run Time: 0 days, 1 hours and 53 minutes
1U, 1S, 97I; 248T, 99F, 73KF
newcli 113 S 1.0 2.1
sshd 107 S 0.7 1.9
newcli 114 R < 0.3 2.1
thttp 48 S 0.0 5.4
ipsengine 55 S < 0.0 5.2
ipsengine 50 S < 0.0 5.2
cmdbsvr 18 S 0.0 3.7
httpsd 71 S 0.0 3.3
httpsd 92 S 0.0 3.3
httpsd 37 S 0.0 2.8
scanunitd 90 S < 0.0 2.2
scanunitd 91 S < 0.0 2.1
merged_daemons 45 S 0.0 2.1
newcli 108 S 0.0 2.1
updated 59 S 0.0 2.0
newcli 112 S < 0.0 2.0
miglogd 35 S 0.0 1.9
nsm 28 S 0.0 1.9
imd 53 S 0.0 1.8
authd 52 S 0.0 1.7
Run Time Displays how long the FortiOS has been running as a string
U User CPU usage (%)
S System CPU usage (%)

71001-420-99686-20101026
Troubleshooting get commands get system session-info full-stat
I Idle CPU usage (%)
T Total memory
F Free memory
KF Kernel-free memory
Column 1 Process name
Column 2 Process identification (PID)
Column 3 One letter process status.
• S: sleeping process
• R: running process
• <: high priority
Column 4 CPU usage (%)
Column 5 Memory usage (%)
get system session-info full-stat

Displays the system’s full state session.
Syntax
get system session-info full-stat
Parameters
None.
Usage/Remarks
Use this command to display in-depth information session info about the system’s state.
This includes session table size, expected session table size, session count, firewall error
details, and more.
Scope: Global
Output Example
FGT # get system session-info full-stat
session table: table_size=131072 max_depth=1 used=50
expect session table: table_size=2048 max_depth=1 used=2
misc info: session_count=25 exp_count=2 clash=0
memory_tension_drop=0 ephemeral=0/32752 removeable=24
delete=0, flush=0, dev_down=4/16
firewall error stat:
error1=00000000
error2=00000000
error3=00000000
error4=00000000
tt=00000000
cont=00000000
ids_recv=00000000
url_recv=00000000
av_recv=00000000
fqdn_count=00000000

01-420-99686-20101026711
get system session-helperTroubleshooting get commands
tcp reset stat:

syncqf=0 acceptqf=0 no-listener=0 data=0 ses=0 ips=0
get system session-helper

Displays the session helper table IDs.
FortiGate units use session helpers to process sessions that have special requirements.
Session helpers function like proxies by getting information from the session and
performing support functions required by the session.
Syntax
get system session-helper
Parameters
None.
Usage/Remarks
Use this command to display if any of the pre-defined session-helpers are in use.
Scope: Global
Output Example
FGT # get system session-helper
== 1 ==
== 2 ==
== 3 ==
== 4 ==
== 5 ==
== 6 ==
== 7 ==
== 8 ==
== 9 ==
== 10 ==
== 11 ==
== 12 ==
== 13 ==
== 14 ==
== 15 ==
== 16 ==
== 17 ==
== 18 ==
== 19 ==
== 20 ==
1...20 If one of the pre-defined session helpers is in use, it will be listed here.
get system session-table list

Displays the session table for the current vdom .

71201-420-99686-20101026
Troubleshooting get commands get system session-table statistics
Syntax
get system session-table list
Parameters
None.
Usage/Remarks
Use this command to display information about the current session table. This can be a
quick and easy way to troubleshoot strange connectivity issues, such as some
applications working where others will not, or connectivity to one location but not another.
The session table tells you the protocol, IP addresses on both ends, and ports.
Scope: Global
Output Example
FGT # get system session-table list
PROTO EXPIRE SOURCE SOURCE-NAT DDESTINATION DESTINATION-
NAT
tcp 3600 172.16.200.254:46586 - 172.16.200.1:23 -
PROTO The protocol of the session—tcp or udp.
EXPIRE The number of seconds until the session expires.
SOURCE The source IP address and port.
SOURCE-NAT If the source IP is going through NAT, what the new address is.
DDESTINATION The destination IP address and port.
DESTINATION-NAT If the destination IP is going through NAT, what the new address is.
get system session-table statistics

Displays statistics related to the session table.
Syntax
get system session-table statistics
Parameters
None.
Usage/Remarks
Use this command to get more in depth information about the session table including
information about any errors.
Scope: Global
Output Example
FGT # diagnose system session-table statistics
misc info: session_count=1 exp_count=0 clash=0
memory_tension_drop=0 emphemeral=0/57344 removeable=1
delete=0, flush=0, dev_down=0/0
firewall error stat:

01-420-99686-20101026713
get system session-info ttlTroubleshooting get commands
error1=00000000
error2=00000000
error3=00000000
error4=00000000
tt=00000000
cont=00000000
ids_recv=00000000
url_recv=00000000
av_recv=00000000
fqdn_count=00000000
tcp reset stat:
syncqf=0 acceptqf=0 no-listener=4 data=0 ses=0 ips=0
global: ses_limit=0 ses6_limit=0 rt_limit=0 rt6_limit=0
get system session-info ttl

Displays the system session time to live (ttl) configuration.
Syntax
get system session-info ttl
Parameters
None.
Usage/Remarks
Use this command to tell you the default time to live setting for sessions All sessions
created will have this length of time before they expire and need to create a new session
table entry.
Scope: Vdom
Output Example
FGT # get system session-info ttl
default : 3600
port:
default The default is 1 hour.
port The session port.
get system startup-error-log

Displays the start-up configuration errors on the console.
Syntax
get system startup-error-log
Parameters
None.

71401-420-99686-20101026
Troubleshooting get commands get test application
Usage/Remarks
Use this command to view the start-up configuration errors on the console.
Output Example
FGT # get system startup-error-log
>>> config system replacemsg webproxy "http-err"
>>> set buffer "<html><head><title>%%HTTP_ERR_CODE%%
%%HTTP_ERR_DESC%%</title></head><body><font size=2><table
width=\"100%\"><tr><td bgcolor=#3300cc align=\"center\"
colspan=2><font color=#ffffff><b>%%HTTP_ERR_CODE%%
%%HTTP_ERR_DESC%%</b></font></td></tr></table><br><br>The
webserver for %%PROTOCOL%%%%URL%% reported that an error occurred
while trying to access the website. Please click <u><a
href=\"javascript:history.back()\">here</a></u> to return to the
previous page.<br><br><hr></font></body></html>"
>>> set header http
>>> set format html
get test application

Displays information statistics information, control proxies, and status.
Syntax
get test application <application> <level>

01-420-99686-20101026715
get test applicationTroubleshooting get commands
Parameters
<application> • acd — Aggregate Controller

• ddnscd — ddnscd daemon
• dhcprelay — dhcprelay
• dnsproxy — dns proxy
• ftpd — ftp proxy
• http — http proxy
• im — im proxy
• imap — imap proxy
• ipldbd — ipldbd daemon
• ipsengine — ips sensor
• ipsmonitor — ips monitor
• l2tpcd — l2tpcd
• nntp — nntp proxy
• pop3 — pop3 proxy
• pptpcd — pptp client
• proxyacceptor — proxy acceptor
• proxyworker — proxy worker
• scanunit — scanning unit
• sflowd — sflowd
• smtp — smtp proxy
• snmpd — snmpd daemon
• urlfilter — urlfilter daemon
• vs — virtual-server
• wad — wan optimization proxy
• wccpd -wccp daemon
<level> • 1: Dump Memory Usage
• 2: Drop all connections
• 22: Drop max idle connections
• 222: Drop all idle connections
• 4: Display connection stat
• 44: Display info per connection
• 444: Display connections per state
• 4444: Display per-VDOM statistics
• 44444: Display information about idle connections
• 5: Toggle AV Bypass mode. Toggle AV bypass mode. You
can use this level to diagnose AV scanning. When bypass
mode is activated, no AV scanning is done on traffic
handled by the proxy. Note: Antivirus scanning is
disabled.
• 6: Toggle Print Stat mode every ~40 seconds
• 7: Toggle Backlog Drop
• 8: Clear stats
• 88: Toggle statistic recording — stats cleared
• 9: Toggle Accounting info for display
• 99: Restart proxy. When you suspect a abnormal behavior
of the proxy, you can use this level value to restore it to its
normal state. Note: You will have a disruption in
services.
• 11: Display the SSL session ID cache statistics
• 12: Clear the SSL session ID cache statistics
• 13: Display the SSL session ID cache
• 14: Clear the SSL session ID cache
NOTE: Not all level numbers may be applicable to all

applications. Use the command diagnose test
application <application> 0 to see a list of valid
commands.

71601-420-99686-20101026
Troubleshooting get commands get test application
Usage/Remarks
Use this command to display information about advanced FortiOS applications such as
SSL, and VoIP.
Scope: Global
Output Examples
FGT # get test application ftpd 1
HTTP Proxy Test Usage
Fortigate-1000#
malloc memory usage
==================
pool buffer size: 2048 count: 2143 available: 2139
total memory used by buffer pools: 4286 (kB)
total allocated (malloc/realloc) memory: 0 (kB)
shm memory usage
==================
buffer pool not initialized
total allocated memory 0
FGT # get test application http 44

diagnose test application http 44
id=17 clt=914(r=1, w=0) srv=915(r=1, w=0) c:192.168.50.2:3608 ->
s:192.168.135.21:80 c2s/s2c=0/0
state=RESPONSE_PASS_STATE duration=0 expire=3590
Current connections = 1/2368
44 The first number is the counter of currently sessions in the connection
pool of the proxy. The second number is the maximum size of the proxy
connection pool table.
FG # get test application imap 4

Fortigate-1000# Running time (HH:MM:SS:usec) = 22:45:40:124613
Bytes sent = 65 (kb)
Bytes received = 2895 (kb)
Error Count (alloc) = 0
Error Count (accept) = 0
Error Count (bind) = 0
Error Count (connect) = 0
Error Count (read) = 0
Error Count (write) = 0
Error Count (poll) = 0
Last Error = 0

01-420-99686-20101026717
get test applicationTroubleshooting get commands
Scan Backlog drop = 0

Emails clean = 3
Emails detected = 2
Emails with scan errors = 0
Worms = 0
Blocked = 0
Virus = 2
Suspicious = 0
Fragmented emails = 0
Spam Detected = 0
Content Filtered emails = 0
Oversize Email Pass = 0
Oversize Email Blocked = 0
AV Bypass is off
Print is off
Drop on backlog is off
Account is on
setup_ok=7 setup_fail=0 poll_ok=2576/2576/1 sel_fail=0 conn_ok=0
conn_inp=7
step1=0 step2=0
scan=5 listen=7 cmdb=2 clt=2304 srv=258
FG # get test application ipsengine 7

FG # PACKET STATISTICS:
total packets 3487023
tcp packets 87
udp packets 0
icmp packets 2476747
discard packets 0
alert packets 45
log packets 0
pass packets 0
fragment packets 0
frag_trackers 0
rebuilt_frags 0
frag_incomplete 0
frag_timeout 0
rebuild_element 0
frag_mem_faults 0
tcp_stream_pkts 87
rebuilt_tcp 5
tcp_streams 4
rebuilt_segs 0
str_mem_faults 0
FG # get test application ipsmonitor 2

FG # enable ipsengine? no
FG # diagnose test application ipsmonitor 2
FG # enable ipsengine? Yes
FG # get test application pop3 444

FG # [OVERSIZE_STATE ] 1/1

71801-420-99686-20101026
Troubleshooting get commands get test application urlfilter
FG # get test application smtp 44

FG # id=0 clt=10(r=1, w=0) srv=11(r=1, w=0) c:192.168.200.2:60811
-> s:192.168.50.2:25 c2s/s2c=0/0
state=CONNECTED_STATE duration=0 expire=3581
get test application urlfilter

Displays statistics, clears the cached, increases the timeout values, and many other
functions for the URL filter engine.
Syntax
get test application urlfilter <number>
Parameters
<number> • 1 — -This menu

• 2 — Clear cache
• 3 — Display WF cache contents
• 4 — Display WF cache TTL list
• 5 — Display WF cache LRU list
• 6 — Display WF cache in tree format
• 7 — Toggle switch for dumping unrated packet
• 8 — Increase timeout for polling
• 9 — Decrease timeout for polling
• 10 — Print debug values
• 11 — Clear Spam Filter cache
• 12 — Clear AV Query cache
• 13 — Toggle switch for dumping expired license packets
• 14 — Show running timers (except request timers)
• 144 — Show running timers (including request timers)
• 15 — Send INIT requests
• 16 — Display WF cache contents of prefix type
• 99 — Restart the urlfilter daemon
Usage/Remarks
Use this command to troubleshoot and work with the URL filter engine.
Scope: Global
Output Example
FGT # get system application urlfilter 3
utree_stat: keylen=223 nodes=15 leaf=11
com.cisco.www cate = 52 len=13 ch=1
dhtml_pulldown/dropdownlib-100.js cate = 52 len=33 ch=0
niffer/snifflib-100.js cate = 52 len=22 ch=0
potlight/spotlightlib-120.js cate = 52 len=28 ch=0
offer/sp/cookie.js cate = 52 len=18 ch=0
cisco_detect.js cate = 52 len=15 ch=0
flyouts.js cate = 52 len=10 ch=0
global.js cate = 52 len=9 ch=0

01-420-99686-20101026719
get vpn status ike configTroubleshooting get commands
hbx.js cate = 52 len=6 ch=0

sitewide_tools.js cate = 52 len=17 ch=0
windowutil.vb cate = 52 len=13 ch=0
get vpn status ike config

Display the status of IKE VPN connections.
Syntax
get vpn status ike config
Parameters
None.
Usage/Remarks
Use this command to display all the IKE VPN configurations on your unit. It displays pretty
much all the information for them. This command can make it easy to quickly find a
particular IKE configuration you are looking for to verify a setting.
Scope: Vdom
Output Example
FGT # get vpn status ike config
vd: root/0
name: home1
serial: 3
version: 1
type: static
local: 0.0.0.0
remote: 220.100.65.98
mode: main
dpd: enable retry-count 3 interval 5000ms
auth: psk
dhgrp: 5
xauth: none
interface: external
phase2s:
home1_tunnel proto 0 src 0.0.0.0/0.0.0.0:0 dst 0.0.0.0/0.0.0.0:0
dhgrp 5
policies: any interface
get vpn status ike crypto

Display the cryptography used on IKE VPN.
Syntax
get vpn status ike crypto

72001-420-99686-20101026
Troubleshooting get commands get vpn status ike errors
Parameters
None.
Usage/Remarks
Use this command to confirm what cryptography is used by IKE VPN connections.
Customer service may ask for this information if they are helping you are troubleshooting
VPN issues.
Scope: Vdom
Output Example
FGT # get vpn status ike crypto
software.dh: 4 3221216544
hardware.dh: 141492682 1088762808
get vpn status ike errors

Display VPN IKE errors.
Syntax
get vpn status ike errors
Parameters
None.
Usage/Remarks
Use this command if you are having IKE VPN problems and you want to determine exactly
what the problems are. This command will list the number of each error. This may allow
you to see a larger pattern of errors.
Scope: Vdom
Output Example
FGT # get vpn status ike errors
limits.euthanized: 141660798
limits.blocked: 3221216504
in.truncated: 0
in.giant: 0
in.baby: 0
in.baby.float: 0
out.fail: 0
iskamp.truncated: 0
iskamp.embryonic.connection.killed: 0
iskamp.embryonic.sa.killed: 0
iskamp.established.sa.killed: 0
quick.bad-status: 0
quick.duplicate-payload: 0
quick.not-encrypted: 0
quick.decryption.fail: 632
info.truncated: 648

01-420-99686-20101026721
get vpn status ike status detailedTroubleshooting get commands
info.hash.missing: 2
info.hash.size: 16
info.hash.content: 1074795752
mem.fail: 3221216520 141490409 1088762548
get vpn status ike status detailed

Display detailed status about IKE VPN Connections
Syntax
get vpn status ike status detailed
Parameters
None.
Usage/Remarks
Use this command to see detailed information about IKE VPN connections. This can be
useful to quickly compare VPN connections when one or some may not be working while
the others are working without problem.
Scope: Vdom
Output Example
FGT # get vpn status ike status detailed
vd: root/0
name: home1
version: 1
ISAKMP SA: created 0/0
IPsec SA: created 0/0
get vpn status ipsec

Display information about the status of VPN IPSec devices in use.
Syntax
get vpn status ipsec
Parameters
None.
Usage/Remarks
Use this command to display which crypto devices are used with VPN such as 3DES,
SHA1, and so on. A zero indicates that type of crypto is not used with any VPN
connections.
Scope: Vdom

72201-420-99686-20101026
Troubleshooting get commands get vpn status ssl hw-acceleration-status
Output Example
FGT # get vpn status ipsec
All ipsec crypto devices in use:
CP4:
null: 0 0
des: 0 0
3des: 0 0
aes: 0 0
null: 0 0
md5: 0 0
sha1: 0 0
sha256: 0 0
SOFTWARE:
null: 0 0
des: 0 0
3des: 0 0
aes: 0 0
null: 0 0
md5: 0 0
sha1: 0 0
sha256: 0 0
get vpn status ssl hw-acceleration-status

Display the status of SSL hardware accelerated VPN connections.
Hardware acceleration can be accomplished a number of ways. Some FortiGate models
incorporate network processors (NPUs) in the main unit, others support the addition of
AMC (Advanced Mezzanine Card) modules. The FortiGate-5000 series supports rear
transition modules (RTMs) that incorporate network processors.
Syntax
get vpn status ssl hw-acceleration-status
Parameters
None.
Usage/Remarks
Use this command to display the status of SSL hardware accelerated VPN connections.
This is useful if you need to troubleshoot a VPN connection that should be accelerated but
is not.
Scope: Vdom
Output Example
FGT # get vpn status ssl hw-acceleration-status
Acceleration hardware detected: kxp=on cipher=on

01-420-99686-20101026723
get vpn status ssl listTroubleshooting get commands
get vpn status ssl list

Display the status of list of SSL VPN connections.
Syntax
get vpn status ssl list
Parameters
None.
Usage/Remarks
Use this command to display the status of SSL list of VPN connections.
Scope: Vdom
Output Example
FGT # diagnose vpn status ssl list
SSL VPN is disabled.
get vpn status tunnel dialup-list

Display the status of the VPN tunnel dialup list.
Syntax
get vpn status tunnel dialup-list <arg>
Parameters
<parameter>
Usage/Remarks
Use this command to display the status of the VPN tunnel dialup list.
Scope: Vdom
Output Example
FGT # get vpn status tunnel dialup-list <arg>
get vpn status tunnel list

Display the status of all VPN tunnels
Syntax
get vpn status tunnel list

72401-420-99686-20101026
Troubleshooting get commands get vpn status tunnel stat
Parameters
None.
Usage/Remarks
Use this command to display the status of all VPN tunnels.
Scope: Vdom
Output Example
FGT # diag vpn tunnel list
list all ipsec tunnel in vd 0
------------------------------------------------------
name=phase1 ver=1 serial=1 0.0.0.0:0->10.10.10.20:0 lgwy=dyn
tun=tunnel mode=auto bound_lf=24
prooxy_id=1 child_num=0 refcnt=4 ilast=406158 olast=406158
stat: rxp=0 txp=0 rxb=0 txb=0
dpd: mode=active on=0 idle=5000ms retry=3 count=0 seqno=0
natt: mode=none draft=0 interval=0 remote_port=0
proxyid=phase2 proto=0 sa=0 ref=1 auto_negotiate=0 serial=1
src: 0:0.0.0.0/0.0.0.0:0
dst: 0:0.0.0.0/0.0.0.0:0
------------------------------------------------------
name=phase12 ver=1 serial=2 10.10.10.20:0->10.10.11.125:0
lgwy=static tun=intf mode=auto bound_if=24
proxyid_num=0 child_num=0 refcnt=4 ilast=406158 olast=406158
stat: rxp=0 txp=0 rxb=0 txb=0
dpd: mode=active on=0 idle=5000ms retry=3 count=0 seqno=0
natt: mode=none draft=0 interval=0 remote_port=0
get vpn status tunnel stat

Display the status of any VPN tunnels.
Syntax
get vpn status tunnel stat
Parameters
None.
Usage/Remarks
Use this command to display the status of vpn tunnels—this is brief information, suitable
for a quick check on general VPN tunnel information. The information includes the device,
tunnel id, proxy id, and if the tunnel is up or down.
Scope: Vdom
Output Example
FGT # diagnose vpn status tunnel stat
dev=3 tunnel=1 proxyid=3 sa=0 conc=1 up=0

01-420-99686-20101026725
get vpn status concentratorTroubleshooting get commands
get vpn status concentrator

Display VPN concentrator status.
In a hub and spoke VPN configuration, the hub is the concentrator.
Syntax
get vpn status concentrator <name>
Parameters
<name> Display all ipsec tunnels for this concentrator name.

Can include multiple entries here.
Usage/Remarks
Use this command to troubleshoot any VPN concentrators. This will help you locate
problems in your hub and spoke VPN configuration.
Scope: Vdom
Output Example
FGT # get vpn status concentrator phase1 phase2
list all ipsec tunnels in phase1 in vd 0
list all ipsec tunnels in phase2 in vd 0
get webfilter ftgd-statistics

Displays the FortiGuard rating statistics.
Syntax
get webfilter fortiguard statistics list ?
Parameters
None.
Usage/Remarks
Use this command to display details about your FortiGuard statistics. These numbers can
be useful in determining the the source of a problem. For example DNS failures can reveal
the source of problems that may be widespread and hard to track back to the source.
Scope: Global
Output Example
FGT # get webfilter fortiguard statistics list
Rating Statistics:
=====================
DNS failures : 3
DNS lookups : 16
Data send failures : 876
Data read failures : 0
Wrong package type : 0

72601-420-99686-20101026
Troubleshooting get commands get webfilter ftgd-statistics
Hash table miss : 1

Unknown server : 0
Incorrect CRC : 0
Proxy request failures : 0
Request timeout : 292
Total requests : 0
Requests to FortiGuard servers : 0
Server errored responses : 11
Relayed rating : 0
Invalid profile : 0
Allowed : 0
Blocked : 0
Logged : 0
Errors : 0
Cache Statistics:
=====================
Maximum memory : 0
Memory usage : 0
Nodes : 0
Leaves : 0
Prefix nodes : 0
Exact nodes : 0
Requests : 0
Misses : 0
Hits : 0
Prefix hits : 0
Exact hits : 0
No cache directives : 0
Add after prefix : 0
Invalid DB put : 0
DB updates : 0
Percent full : 0%
Branches : 0%
Leaves : 0%
Prefix nodes : 0%
Exact nodes : 0%
Miss rate : 0%
Hit rate : 0%
Prefix hits : 0%
Exact hits : 0%
DNS lookups Number of DNS look-ups for the domain name of the requested URL.
Data send failures Number of non-responsive servers.

01-420-99686-20101026727
get webfilter statusTroubleshooting get commands
Request timeout NUmber of seconds for the request time-out. A FortiGate unit sends the
URL rating request every 2 seconds.
Total requests Total number of URL rating requests to cache and FortiGuard servers.
Requests to Total number of URL rating requests to FortiGuard servers.
FortiGuard servers
Relayed rating The number of times the master communicates with FortiGuard servers
and relays all URL rating requests from the slaves in a HA cluster.
Maximum memory Amount of memory assigned to FortiGuard cache. The default is 2%.
Memory usage The amount of memory used to store the URL tree.
Prefix nodes The number of prefixes used for a URL to increase the cache hit rate.
Exact nodes The number of exact matches used for a URL.
get webfilter status

Displays the webfilter information from FortiGuard.
Syntax
get webfilter status <refresh rate>
Parameters
<refresh rate> How often to refresh the server list(s).
Usage/Remarks
Use this command to display webfilter statistics and server information if the service is
enabled.
If the service is not enabled, this command displays the language of the locale and states
the service is not enabled.
Output Example
FGT # get webfilter status 4
Locale : english
License : Contract
Expiration : Wed Feb 11 02:00:00 2009
Hostname : service.fortiguard.net
-=- Server List (Mon May 26 22:36:34 2008) -=-
IP Weight RTT Flags TZ Packets Curr Lost Total Lost

212.95.252.121 10 77 0 83 0 8
62.209.40.73 0 86 1 83 0 8
62.209.40.72 0 92 DI 1 85 0 9
82.71.226.65 10 98 D 0 84 0 8
212.95.252.120 10 95 0 76 0 2
69.20.236.179 60 198 -5 84 0 9
66.117.56.42 60 189 -5 83 0 8
66.117.56.37 60 192 -5 83 0 8

72801-420-99686-20101026
Troubleshooting get commands get webfilter status
69.20.236.180 60 213 -5 83 0 8
209.52.128.90 60 268 -5 84 0 9
121.111.236.179 80 383 9 83 0 8
121.111.236.180 80 404 9 83 0 8
72.52.72.243 90 289 -8 83 0 8
218.106.244.81 90 455 -8 83 0 8
69.90.198.55 90 297 D -8 85 0 9
Locale Local environment language.
License The license status:
• Contract
• Expired
• Trial
Expiration The date and time the license expires.
Hostname The FortiGuard server the FortiGate connects to obtain the service. The
FortiGuard server will return the information to the FortiGate. The
default is service.fortiguard.net
IP The IP address of other FortiGuard servers.
Weight The priority value which the FortiGate uses to send the URL rating
request. The lower weight value takes higher preference. The weight is
calculated by time zone, packet round-trip time, and success rate.
RTT Flags The round-trip time between the URL rating request and the response
time from the FortiGuard server.
TZ Time zone of the FortiGuard server (Greenwich Mean Time +/- the
number).
Packets Total packets sent to the FortiGuard server.
Curr Lost The number of times the request is retried in a timeout period. The
default is 15 seconds.
Total Lost Total number of unresponsive requests.

01-420-99686-20101026729
get webfilter statusTroubleshooting get commands

73001-420-99686-20101026
Troubleshooting bootup issues
When powering on your FortiOS unit, you may experience problems. This section
addresses some problems you may experience in this area in rare cases. If you continue
to have problems, please contact customer support for assistance.
Bootup issues, while rare, can be very difficult to troubleshoot due to the lack of
information about your issue. When the unit not running, you do not have access to your
typical tools such as diagnose CLI commands. This section walks you through some
possible issues to give you direction in these situations.
To troubleshoot a bootup problem with your unit, go to the section that lists your problem.
If you have multiple problems, go the problem closest to the top of the list first, and work
your way down the list.
Note: It is rare that units experience any of the symptoms listed here. Fortinet hardware is reliable
with a long expected operation life.
The issues covered in this section all refer to various potential bootup issues including:
• A. You have text on the screen, but you have problems
• B. You don’t see the boot options menu
• C. You have problems with the console text
• D. You have visible power problems
• E. You have a suspected defective FortiOS unit
A. You have text on the screen, but you have problems

Solution
1 If the text on the screen is garbled, ensure your Console Communication parameters
are ok. Check your quickstart guide for your specific model settings.
2 If that fixes your problem, you are done.
3 If not, go to B. You don’t see the boot options menu
B. You don’t see the boot options menu

Solution
1 Ensure you serial communication parameters are set to no flow control, and the
proper baud rate and reboot the FortiGate unit by powering off and on.
Note: FortiOS units ship with a baud rate of 9600 by default. If you have access, verify this with the
CLI command config system console get , or parse an archived configuration file for the term
baudrate.
2 If that fixes your problem go to E. You have a suspected defective FortiOS unit.
3 If it doesn’t fix your problem, go to E. You have a suspected defective FortiOS unit.

01-420-99686-20101026 731
C. You have problems with the console text Troubleshooting bootup issues
C. You have problems with the console text

1 Do you have any console message?
• If Yes, go to D. You have visible power problems
• If No, continue.
2 Is there garbage onscreen ?
• If Yes, ensure Console Communication parameters are ok.
•If that fixes the problem, you are done.
3 If no, does the unit stop before the Press Any Key to Download Boot Image
prompt ?
• If Yes, go to E. You have a suspected defective FortiOS unit.
• If No, go to Step 4.
4 Console Message - Press any key to Download Boot Image
5 When pressing a key do you see one of the following messages?
[G] Get Firmware image from TFTP server
[F] Format boot device
[B] Boot with backup firmware and act as default
[Q] Quit menu and continue to boot with default firmware
[H] Display this list of options
• If Yes, go to E. You have a suspected defective FortiOS unit.
6 If No, ensure you serial communication parameters are set to no flow control, and
the proper baud rate and reboot the FortiOS unit by powering off and on.
Note: FortiOS units ship with a baud rate of 9600 by default. If you have access, parse an archived
configuration file for the term baudrate or verify this setting with the CLI command:
get
7 Did the reboot fix the problem?

• Go to E. You have a suspected defective FortiOS unit
D. You have visible power problems

1 Is there any LED on?
• If No, ensure power is on. If that fixes the problem you are done. If not, continue.
• If Yes, continue.
2 Do you have an external power adapter?
• If No, go to E. You have a suspected defective FortiOS unit.
• If Yes, try replacing the power adapter.
3 Is the power supply defective or you can’t determine one way or the other?
• If No, go to E. You have a suspected defective FortiOS unit.
• If Yes, go to A. You have text on the screen, but you have problems

732 01-420-99686-20101026
Troubleshooting bootup issues E. You have a suspected defective FortiOS unit
E. You have a suspected defective FortiOS unit

If you have followed these steps and determined there is a good chance your unit is
defective, follow these steps.
1 Open a support ticket through FortiCare at https://support.fortinet.com
2 In the ticket, document the problem or problems, and these steps that you have taken.
3 Provide all console messages and output.
4 Indicate if you have a suspected hard disk issue, and provide your evidence.
Fortinet Customer Support will contact you to help you with your ticket and issue.

01-420-99686-20101026 733
E. You have a suspected defective FortiOS unit Troubleshooting bootup issues

734 01-420-99686-20101026
Chapter 6 UTM Guide

UTM overview describes UTM components and their relation to firewall policies, as well as
SSL content scanning and inspection. We recommend starting with this section to become
familiar with the different features in your FortiGate unit.
Network defense explains basic denial of service (DoS) and distributed denial of service
(DDOS) concepts and provides an overview of the best practices to use with all the UTM
features to defend your network against infection and attack.
AntiVirus explains how the FortiGate unit scans files for viruses and describes how to
configure the antivirus options.
Email filter explains how the FortiGate unit filters email, describes how to configure the
filtering options and the action to take with email detected as spam.
Intrusion protection explains basic Intrusion Protection System (IPS) concepts and how to
configure IPS options; includes guidance and a detailed table for creating custom
signatures as well as several examples.
Web filter and FortiGuard Web Filter The first of these sections describes basic web
filtering concepts, the order in which the FortiGate unit performs web filtering, and
configuration. The second section describes enhanced features of the subscription-based
FortiGuard Web Filtering service and explains how to configure them. We recommend
reading both sections if you are using FortiGuard Web Filtering because settings you
configure in one feature may affect the other.
Data leak prevention describes the DLP features that allow you to prevent sensitive data
from leaving your network and explains how to configure the DLP rules, compound rules,
and sensors.
Application control describes how your FortiGate unit can detect and take action against
network traffic based on the application generating the traffic.
DoS policy describes how to use DoS policies to protect your network from DoS attacks.
Sniffer policy describes how to use your FortiGate unit as a one-armed intrusion detection
system (IDS) to report on attacks.
FortiOS™ Handbook v2: UTM Guide

01-420-99686-20101026 735
UTM Guide for FortiOS 4.0 MR2
736 01-420-99686-20101026
UTM overview
Ranging from the FortiGate®-30 series for small businesses to the FortiGate-5000 series
for large enterprises, service providers and carriers, the FortiGate line combines a number
of security features to protect your network from threats. As a whole, these features, when
included in a single Fortinet security appliance, are referred to as Unified Threat
Management (UTM). The UTM features your FortiGate model includes are:
• AntiVirus
• Intrusion Prevention System (IPS)
• Anomaly protection (DoS policies)
• One-armed IPS (Sniffer policies)
• Web filtering
• E-mail filtering, including protection against spam and grayware
• Data Leak Prevention (DLP)
• Application Control (for example, IM and P2P).
Firewall policies limit access, and while this and similar features are a vital part of securing
your network, they are not covered in this document.
• UTM components
• UTM profiles/lists/sensors
• UTM and Virtual domains (VDOMs)
• Conserve mode
• SSL content scanning and inspection
• Viewing and saving logged packets
• Using wildcards and Perl regular expressions
UTM components
AntiVirus
Your FortiGate unit stores a virus signature database that can identify more than 15,000
individual viruses. FortiGate models that support additional virus databases are able to
identify hundreds of thousands of viruses. With a FortiGuard AntiVirus subscription, the
signature databases are updated whenever a new threat is discovered.
AntiVirus also includes file filtering. When you specify files by type or by file name, the
FortiGate unit will stop the matching files from reaching your users.
FortiGate units with a hard drive or configured to use a FortiAnalyzer unit can store
infected and blocked files for that you can examine later.

01-420-99686-20101026 737
UTM components UTM overview
Intrusion Protection System (IPS)

The FortiGate Intrusion Protection System (IPS) protects your network against hacking
and other attempts to exploit vulnerabilities of your systems. More than 3,000 signatures
are able to detect exploits against various operating systems, host types, protocols, and
applications. These exploits can be stopped before they reach your internal network.
You can also write custom signatures, tailored to your network.
Anomaly protection (DoS policies)

A complement to the signature-based IPS, anomaly protection detects unusual network
traffic that can be used to attack your network. When you set thresholds for various types
of network operations, the FortiGate unit will block any attempt to exceed the thresholds
you have defined.
One-armed IDS (sniffer policies)

You can use sniffer policies on the FortiGate unit as a one-arm intrusion detection system
(IDS). The unit examines traffic for matches to the configured IPS sensor and application
control list. Matches are logged and then all received traffic is dropped. In this way, you
can configure a unit to sniff network traffic for attacks without actually processing the
packets.
The FortiGate unit can log all detected IPS signatures and anomalies in a traffic stream.
Web filtering
Web filtering includes a number of features you can use to protect or limit your users’
activity on the web.
FortiGuard Web Filtering is a subscription service that allows you to limit access to web
sites. More than 60 million web sites and two billion web pages are rated by category. You
can choose to allow or block each of the 77 categories.
URL filtering can block your network users from access to URLs that you specify.
Web content filtering can restrict access to web pages based on words and phrases
appearing on the web page itself. You can build lists of words and phrases, each with a
score. When a web content list is selected in a web filter profile, you can specify a
threshold. If a user attempts to load a web page and the score of the words on the page
exceeds the threshold, the web page is blocked.
Email filtering
FortiGuard AntiSpam is a subscription service that includes an IP address black list, a
URL black list, and an email checksum database. These resources are updated whenever
new spam messages are received, so you do not need to maintain any lists or databases
to ensure accurate spam detection.
You can use your own IP address lists and email address lists to allow or deny addresses,
based on your own needs and circumstances.
Data Leak Prevention (DLP)

Data leak prevention allows you to define the format of sensitive data. The FortiGate unit
can then monitor network traffic and stop sensitive information from leaving your network.
Rules for U.S. social security numbers, Canadian social insurance numbers, as well as
Visa, Mastercard, and American Express card numbers are included.

738 01-420-99686-20101026
UTM overview UTM profiles/lists/sensors
Application Control (for example, IM and P2P)

Although you can block the use of some applications by blocking the ports they use for
communications, many applications do not use standard ports to communicate.
Application control can detect the network traffic of more than 1000 applications,
improving your control over application communication.
UTM profiles/lists/sensors
A profile is a group of settings that you can apply to one or more firewall policies. Each
UTM feature is enabled and configured in a profile, list, or sensor. These are then selected
in a firewall policy and the settings apply to all traffic matching the policy. For example, if
you create an antivirus profile that enables antivirus scanning of HTTP traffic, and select
the antivirus profile in the firewall policy that allows your users to access the World Wide
Web, all of their web browsing traffic will be scanned for viruses.
Because you can use profiles in more than one firewall policy, you can configure one
profile for the traffic types handled by a set of firewall policies requiring identical protection
levels and types, rather than repeatedly configuring those same profile settings for each
individual firewall policy.
For example, while traffic between trusted and untrusted networks might need strict
protection, traffic between trusted internal addresses might need moderate protection. To
provide the different levels of protection, you might configure two separate sets of profiles:
one for traffic between trusted networks, and one for traffic between trusted and untrusted
networks.
The UTM profiles include:
• antivirus profile
• IPS sensor
• Web filter profile
• Email filter profile
• Data Leak Prevention profile
• Application Control list
• VoIP profile
Although they’re called profiles, sensors, and lists, they’re functionally equivalent. Each is
used to configure how the feature works.
UTM and Virtual domains (VDOMs)

If you enable virtual domains (VDOMs) on your FortiGate unit, all UTM configuration is
limited to the VDOM in which you configure it.
While configuration is not shared, the various databases used by UTM features are
shared. The FortiGuard antivirus and IPS databases and database updates are shared.
The FortiGuard web filter and spam filter features contact the FortiGuard distribution
network and access the same information when checking email for spam and web site
categories and classification.

01-420-99686-20101026 739
Conserve mode UTM overview
Conserve mode
FortiGate units perform all UTM processing in physical RAM. Since each model has a
limited amount of memory, conserve mode is activated when the remaining free memory
is nearly exhausted or the AV proxy has reached the maximum number of sessions it can
service. While conserve mode is active, the AV proxy does not accept new sessions.
The AV proxy
Most content inspection the FortiGate unit performs requires that the files, email
messages, URLs, and web pages be buffered and examined as a whole. The AV proxy
performs this function, and because it may be buffering many files at the same time, it
uses a significant amount of memory. Conserve mode is designed to prevent all the
component features of the FortiGate unit from trying to use more memory than it has.
Because the AV proxy uses so much memory, conserve mode effectively disables it in
most circumstances. As a result, the content inspection features that use the AV proxy are
also disabled in conserve mode.
All of the UTM features use the AV proxy with the exception of IPS, application control,
flow-based antivirus scanning, and DoS. These features continue to operate normally
when the FortiGate unit enters conserve mode.
Entering and exiting conserve mode

A FortiGate unit will enter conserve mode because it is nearly out of physical memory, or
because the AV proxy has reached the maximum number of sessions it can service. The
memory threshold that triggers conserve mode varies by model, but it is about 20% free
memory. When memory use rises to the point where less than 20% of the physical
memory is free, the FortiGate unit enters conserve mode.
The FortiGate unit will leave conserve mode only when the available physical memory
exceeds about 30%. When exiting conserve mode, all new sessions configured to be
scanned with features requiring the AV proxy will be scanned as normal, with the
exception of a unit configured with the one-shot option.
Conserve mode effects

What happens when the FortiGate unit enters conserve mode depends on how you have
av-failopen configured. There are four options:
off
The off setting forces the FortiGate unit to stop all traffic that is configured for content
inspection by UTM features that use the AV proxy. New sessions are not allowed but
current sessions continue to be processed normally unless they request more memory.
Sessions requesting more memory are terminated.
For example, if a firewall policy is configured to use antivirus scanning, the traffic it permits
is blocked while in conserve mode. A policy with IPS scanning enabled continues as
normal. A policy with both IPS and antivirus scanning is blocked because antivirus
scanning requires the AV proxy.
Use the off setting when security is more important than a loss of access while the
problem is rectified.

740 01-420-99686-20101026
UTM overview SSL content scanning and inspection
pass
The pass setting allows traffic to bypass the AV proxy and continue to its destination.
Since the traffic is bypassing the proxy, no UTM scanning that requires the AV proxy is
performed. UTM scanning that does not require the AV proxy continues normally.
Use the pass setting when access is more important than security while the problem is
rectified.
Pass is the default setting.
one-shot
The one-shot setting is similar to pass in that traffic is allowed when conserve mode is
active. The difference is that a system configured for one-shot will force new sessions to
bypass the AV proxy even after it leaves conserve mode. The FortiGate unit resumes use
of the AV proxy only when the av-failopen setting is changed or the unit is restarted.
idledrop
The idledrop setting will recover memory and session space by terminating all the
sessions associated with the host that has the most sessions open. The FortiGate may
force this session termination a number of times, until enough memory is available to
allow it to leave conserve mode.
The idledrop setting is primarily designed for situations in which malware may continue to
open sessions until the AV proxy cannot accept more new sessions, triggering conserve
mode. If your FortiGate unit is barely able to handle the traffic of your network, this setting
could cause the termination of valid sessions. Use this option with caution.
Configuring the av-failopen command

You can configure the av-failopen command using the CLI.
set av-failopen {off | pass | one-shot | idledrop}
end
The default setting is pass.
SSL content scanning and inspection

If your FortiGate model supports SSL content scanning and inspection, you can apply
antivirus scanning, web filtering, FortiGuard Web Filtering, and email filtering to encrypted
traffic. You can also apply DLP and DLP archiving to HTTPS, IMAPS, POP3S, and
SMTPS traffic. To perform SSL content scanning and inspection, the FortiGate unit does
the following:
• intercepts and decrypts HTTPS, IMAPS, POP3S, and SMTPS sessions between
clients and servers (FortiGate SSL acceleration speeds up decryption)
• applies content inspection to decrypted content, including:
• HTTPS, IMAPS, POP3S, and SMTPS Antivirus, DLP, and DLP archiving
• HTTPS web filtering and FortiGuard web filtering
• IMAPS, POP3S, and SMTPS email filtering
• encrypts the sessions and forwards them to their destinations.

01-420-99686-20101026 741
SSL content scanning and inspection UTM overview
Figure 62: FortiGate SSL content scanning and inspection packet flow
3 1
2
Decrypted
packets
Content scanning and Content scanning

4
inspection applied and inspection
(antivirus, web filtering,
spam filtering, DLP,
DLP archiving)
SSL decrypt/encrypt process Session encrypted

SSL Decrypt/
3 decrypts SSL sessions 5 using SSL session
Encrypt Process
using session certificate certificate and key
and key
UTM profiles includes

2 UTM profiles
SSL content scanning and
inspection
Encrypted 3
2
1 3
2
1
Encrypted
packets Firewall packets
HTTPS, IMAPS, POP3S or 6 HTTPS, IMAPS,

Client Starts 1 SMTPS encrypted packets ts Encrypted packets POP3S, or
HTTPS, IMAPS, accepted by firewall policy
cy forwarded to destination SMTPS Server
fo
POP3S or
SMTPS session
Setting up certificates to avoid client warnings

To use SSL content scanning and inspection, you need to set up and use a certificate that
supports it. FortiGate SSL content scanning and inspection intercepts the SSL keys that
are passed between clients and servers during SSL session handshakes and then
substitutes spoofed keys. Two encrypted SSL sessions are set up, one between the client
and the FortiGate unit, and a second one between the FortiGate unit and the server.
Inside the FortiGate unit the packets are decrypted.
While the SSL sessions are being set up, the client and server communicate in clear text
to exchange SSL session keys. The session keys are based on the client and server
certificates. The FortiGate SSL decrypt/encrypt process intercepts these keys and uses a
built-in signing CA certificate named Fortinet_CA_SSLProxy to create keys to send to the
client and the server. This signing CA certificate is used only by the SSL decrypt/encrypt
process. The SSL decrypt/encrypt process then sets up encrypted SSL sessions with the
client and server and uses these keys to decrypt the SSL traffic to apply content scanning
and inspection.
Some client programs (for example, web browsers) can detect this key replacement and
will display a security warning message. The traffic is still encrypted and secure, but the
security warning indicates that a key substitution has occurred.
You can stop these security warnings by importing the signing CA certificate used by the
server into the FortiGate unit SSL content scanning and inspection configuration. Then the
FortiGate unit creates keys that appear to come from the server and not the FortiGate unit.
Note: You can add one signing CA certificate for SSL content scanning and inspection. The
CA certificate key size must be 1024 or 2048 bits. 4096-bit keys are not supported for SSL
content scanning and encryption.

742 01-420-99686-20101026
UTM overview SSL content scanning and inspection
You can replace the default signing CA certificate, Fortinet_CA_SSLProxy, with another
signing CA certificate. To do this, you need the signing CA certificate file, the CA certificate
key file, and the CA certificate password.
All SSL content scanning and inspection uses the same signing CA certificate. If your
FortiGate unit is operating with virtual domains enabled, the same signing CA certificate is
used by all virtual domains.
To add a signing CA certificate for SSL content scanning and inspection

1 Obtain a copy of the signing CA certificate file, the CA certificate key file, and the
password for the CA certificate.
2 Go to System > Certificates > Local Certificates and select Import.
3 Set Type to Certificate.
4 For Certificate file, use the Browse button to select the signing CA certificate file.
5 For Key file, use the Browse button to select the CA certificate key file.
6 Enter the CA certificate Password.
7 Select OK.
The CA certificate is added to the Local Certificates list. In this example the signing CA
certificate name is Example_CA. This name comes from the certificate file and key file
name. If you want the certificate to have a different name, change these file names.
8 Add the imported signing CA certificate to the SSL content scanning and inspection
configuration. Use the following CLI command if the certificate name is Example_CA.
config firewall ssl setting
set caname Example_CA
end
The Example_CA signing CA certificate will now be used by SSL content scanning and
inspection for establishing encrypted SSL sessions.
SSL content scanning and inspection settings

If SSL content scanning and inspection is available on your FortiGate unit, you can
configure SSL settings. The following table provides an overview of the options available
and where to find further instruction:
Table 54: SSL content scanning and inspection settings
Setting Description
Predefined The IMAPS, POP3S and SMTPS predefined services. You can select these
firewall services services in a firewall policy and a DoS policy.
Protocol The TCP port numbers that the FortiGate unit inspects for HTTPS, IMAPS,
recognition POP3S, and SMTPS. Go to Firewall > Protocol Options. Add or edit a protocol
options profile, configure HTTPS, IMAPS, POP3S, and SMTPS.
Using Protocol Options, you can also configure the FortiGate unit to perform
URL filtering of HTTPS or to use SSL content scanning and inspection to
decrypt HTTPS so that the FortiGate unit can also apply antivirus and DLP
content inspection and DLP archiving to HTTPS. Using SSL content scanning
and inspection to decrypt HTTPS also allows you to apply more web filtering
and FortiGuard Web Filtering options to HTTPS.
To enable full SSL content scanning of web filtering, select Enable Deep
Scanning under HTTPS in the protocol options profile.
Antivirus Antivirus options including virus scanning and file filtering for HTTPS, IMAPS,
POP3S, and SMTPS.
Go to UTM AntiVirus > Profile. Add or edit a profile and configure Virus Scan for
HTTPS, IMAPS, POP3S, and SMTPS.

01-420-99686-20101026 743
SSL content scanning and inspection UTM overview
Table 54: SSL content scanning and inspection settings (Continued)
Setting Description
Antivirus Antivirus quarantine options to quarantine files in HTTPS, IMAPS, POP3S, and
quarantine SMTPS sessions.
Go to UTM > AntiVirus > Quarantine. You can quarantine infected files,
suspicious files, and blocked files found in HTTPS, IMAPS, POP3S, and
SMTPS sessions.
Web filtering Web filtering options for HTTPS:
• Web Content Filter
• Web URL Filter
• ActiveX Filter
• Cookie Filter
• Java Applet Filter
• Web Resume Download Block
• Block invalid URLs
Go to UTM > Web Filter > Profile. Add or edit a web filter profile and configure
web filtering for HTTPS.
FortiGuard Web FortiGuard Web Filtering options for HTTPS:
Filtering • Enable FortiGuard Web Filtering
• Enable FortiGuard Web Filtering Overrides
• Provide Details for Blocked HTTP 4xx and 5xx Errors
• Rate Images by URL (Blocked images will be replaced with blanks)
• Allow Websites When a Rating Error Occurs
• Strict Blocking
• Rate URLs by Domain and IP Address
• Block HTTP Redirects by Rating
Go to UTM > Web Filter > Profile. Add or edit a profile and configure FortiGuard
Web Filtering for HTTPS.
Email filtering Email filtering options for IMAPS, POP3S, and SMTPS:
• FortiGuard Email Filtering IP Address Check, URL check, E-mail Checksum
Check, and Spam Submission
• IP Address BWL Check
• E-mail Address BWL Check
• Return S-mail DNS Check
• Banned Word Check
• Spam Action
• Tag Location
• Tag Format
Go to UTM > Email Filter > Profile. Add or edit a profile and configure email
filtering for IMAPS, POP3S, and SMTPS.
Data Leak DLP for HTTPS, IMAPS, POP3S, and SMTPS. To apply DLP, follow the steps
Prevention below:
• Go to UTM > Data Leak Prevention > Rule to add DLP rules. For HTTPS,
add an HTTP rule and select HTTPS POST and HTTPS GET. For IMAPS,
POP3S, and SMTPS, add an Email rule and select IMAPS, POP3S, and
SMTPS.
• Go to UTM > Data Leak Prevention > Sensor, create a new DLP sensor or
edit an existing one and then add the DLP rules to a DLP sensor.
• Go to Firewall > Protocol Options. Add or edit a profile and select Enable
Deep Scan under HTTPS.
• Go to Firewall > Policy, edit the required policy, enable UTM, select Enable
DLP Sensor and select the DLP sensor.
• Go to Firewall > Policy, edit the required policy, enable Protocol Options and
select a profile that has Enable Deep Scan selected under HTTPS. Note: If
no protocol options profile is selected, or if Enable Deep Scan is not
selected within the protocol options profile, DLP rules cannot inspect
HTTPS.

744 01-420-99686-20101026
UTM overview Viewing and saving logged packets
Table 54: SSL content scanning and inspection settings (Continued)
Setting Description
DLP archiving DLP archiving for HTTPS, IMAPS, POP3S, and SMTPS. Add DLP Rules for the
protocol to be archived.
Monitor DLP DLP archive information on the Log and Archive Statistics widget on the system
content dashboard for HTTPS, IMAPS, POP3S, and SMTPS.
information on Go to Firewall > Protocol Options. Add or edit a profile. For each protocol you
the system want monitored on the dashboard, enable Monitor Content Information for
Dashboard.
dashboard
These options display meta-information on the Statistics dashboard widget.
Viewing and saving logged packets

The FortiGate unit supports packet logging for IPS and application control. The packets
that trigger a signature match for IPS or application recognition for application control are
saved for later viewing when packet logging is enabled.
For information on how to enable packet logging, see “Enable IPS packet logging” on
page 813 and “Application control packet logging” on page 877.
Once the FortiGate unit has logged packets, you can view or save them.
To view and save logged packets

1 Go to Log&Report > Log Access > Attack.
2 Depending on where the logs are configured to be stored, select the appropriate
option:
Memory Select if logs are stored in the FortiGate unit memory.

Disk Select if the FortiGate unit has an internal hard disk and logs are
stored there.
Remote Select if logs are sent to a FortiAnalyzer unit or to the FortiGuard
Analysis and Management Service.
3 Select the Packet Log icon of the log entry you want to view.
The IPS Packet Log Viewer window appears.
4 Select the packet to view the packet in binary and ASCII. Each table row represents a
captured packet.
5 Select Save to save the packet data in a PCAP formatted file.
PCAP files can be opened and examined in network analysis software such as Wireshark.
Configuring packet logging options

You can use a number of CLI commands to further configure packet logging.
Limiting memory use

When logging to memory, you can define the maximum amount of memory used to store
logged packets.
config ips settings
set packet-log-memory 256
end
The acceptable range is from 64 to 8192 kilobytes. This command affects only logging to
memory.

01-420-99686-20101026 745
Using wildcards and Perl regular expressions UTM overview
Limiting disk use

When logging to the FortiGate unit internal hard disk, you can define the maximum
amount of space used to store logged packets.
config ips settings
set ips-packet-quota 256
end
The acceptable range is from 0 to 4294967295 megabytes. This command affects only
logging to disk.
Configuring how many packets are captured

Since the packet containing the signature is sometimes not sufficient to troubleshoot a
problem, you can specify how many packets are captured before and after the packet
containing the IPS signature match.
config ips settings
packet-log-history
packet-log-post-attack
end
The packet-log-history command specifies how many packets are captured before
and including the one in which the IPS signature is detected. If the value is more than 1,
the packet containing the signature is saved in the packet log, as well as those preceding
it, with the total number of logged packets equalling the packet-log-history setting.
For example, if packet-log-history is set to 7, the FortiGate unit will save the packet
containing the IPS signature match and the six before it.
The acceptable range for packet-log-history is from 1 to 255. The default is 1.
Note: Setting packet-log-history to a value larger than 1 can affect the

performance of the FortiGate unit because network traffic must be buffered. The
performance penalty depends on the model, the setting, and the traffic load.
The packet-log-post-attack command specifies how many packets are logged after
the one in which the IPS signature is detected. For example, if packet-log-post-
attack is set to 10, the FortiGate unit will save the ten packets following the one
containing the IPS signature match.
The acceptable range for packet-log-post-attack is from 0 to 255. The default is 0.
Using wildcards and Perl regular expressions

Many UTM feature list entries can include wildcards or Perl regular expressions.
For more information about using Perl regular expressions, see
http://perldoc.perl.org/perlretut.html.
Regular expression vs. wildcard match pattern

A wildcard character is a special character that represents one or more other characters.
The most commonly used wildcard characters are the asterisk (*), which typically
represents zero or more characters in a string of characters, and the question mark (?),
which typically represents any one character.
In Perl regular expressions, the ‘.’ character refers to any single character. It is similar to
the ‘?’ character in wildcard match pattern. As a result:
• fortinet.com not only matches fortinet.com but also fortinetacom, fortinetbcom,
fortinetccom, and so on.

746 01-420-99686-20101026
UTM overview Using wildcards and Perl regular expressions
Note: To add a question mark (?) character to a regular expression from the FortiGate CLI,
enter Ctrl+V followed by ?. To add a single backslash character (\) to a regular expression
from the CLI you must add precede it with another backslash character. For example,
fortinet\\.com.
To match a special character such as '.' and ‘*’ use the escape character ‘\’. For example:
• To match fortinet.com, the regular expression should be: fortinet\.com
In Perl regular expressions, ‘*’ means match 0 or more times of the character before it, not
0 or more times of any character. For example:
• forti*.com matches fortiiii.com but does not match fortinet.com
To match any character 0 or more times, use ‘.*’ where ‘.’ means any character and the ‘*’
means 0 or more times. For example, the wildcard match pattern forti*.com should
therefore be fort.*\.com.
Word boundary
In Perl regular expressions, the pattern does not have an implicit word boundary. For
example, the regular expression “test” not only matches the word “test” but also any word
that contains “test” such as “atest”, “mytest”, “testimony”, “atestb”. The notation “\b”
specifies the word boundary. To match exactly the word “test”, the expression should be
\btest\b.
Case sensitivity
Regular expression pattern matching is case sensitive in the web and Email Filter filters.
To make a word or phrase case insensitive, use the regular expression /i. For example,
/bad language/i will block all instances of “bad language”, regardless of case.
Perl regular expression formats

Table 55 lists and describes some example Perl regular expressions.
Table 55: Perl regular expression formats
Expression Matches
abc “abc” (the exact character sequence, but anywhere in the string)
âbc “abc” at the beginning of the string
abc$ “abc” at the end of the string
a|b Either “a” or “b”
âbc|abc$ The string “abc” at the beginning or at the end of the string
ab{2,4}c “a” followed by two, three or four “b”s followed by a “c”
ab{2,}c “a” followed by at least two “b”s followed by a “c”
ab*c “a” followed by any number (zero or more) of “b”s followed by a “c”
ab+c “a” followed by one or more b's followed by a c
ab?c “a” followed by an optional “b” followed by a” c”; that is, either “abc” or
”ac”
a.c “a” followed by any single character (not newline) followed by a” c “
a\.c “a.c” exactly
[abc] Any one of “a”, “b” and “c”
[Aa]bc Either of “Abc” and “abc”

01-420-99686-20101026 747
Using wildcards and Perl regular expressions UTM overview
Table 55: Perl regular expression formats (Continued)

[abc]+ Any (nonempty) string of “a”s, “b”s and “c”s (such as “a”, “abba”,
”acbabcacaa”)
[âbc]+ Any (nonempty) string which does not contain any of “a”, “b”, and “c”
(such as “defg”)
\d\d Any two decimal digits, such as 42; same as \d{2}
/i Makes the pattern case insensitive. For example, /bad language/i
blocks any instance of bad language regardless of case.
\w+ A “word”: A nonempty sequence of alphanumeric characters and low
lines (underscores), such as foo and 12bar8 and foo_1
100\s*mk The strings “100” and “mk” optionally separated by any amount of white
space (spaces, tabs, newlines)
abc\b “abc” when followed by a word boundary (for example, in “abc!” but not in
“abcd”)
perl\B “perl” when not followed by a word boundary (for example, in “perlert” but
not in “perl stuff”)
\x Tells the regular expression parser to ignore white space that is neither
preceded by a backslash character nor within a character class. Use this
to break up a regular expression into (slightly) more readable parts.
/x Used to add regular expressions within other text. If the first character in
a pattern is forward slash '/', the '/' is treated as the delimiter. The pattern
must contain a second '/'. The pattern between ‘/’ will be taken as a
regular expressions, and anything after the second ‘/’ will be parsed as a
list of regular expression options ('i', 'x', etc). An error occurs if the
second '/' is missing. In regular expressions, the leading and trailing
space is treated as part of the regular expression.
Examples of regular expressions

Block any word in a phrase
/block|any|word/
Block purposely misspelled words
Spammers often insert other characters between the letters of a word to fool spam
blocking software.
/^.*v.*i.*a.*g.*r.*o.*$/i
/cr[eéèêë][\+\-\*=<>\.\,;!\?%&§@\^°\$£€\{\}()\[\]\|\\_01]dit/i
Block common spam phrases
The following phrases are some examples of common phrases found in spam messages.
/try it for free/i
/student loans/i
/you’re already approved/i
/special[\+\-\*=<>\.\,;!\?%&~#§@\^°\$£€\{\}()\[\]\|\\_1]offer/i

748 01-420-99686-20101026
Network defense
This section describes in general terms the means by which attackers can attempt to
compromise your network and steps you can take to protect it. The goal of an attack can
be as complex as gaining access to your network and the privileged information it
contains, or as simple as preventing customers from accessing your web server. Even
allowing a virus onto your network can cause damage, so you need to protect against
viruses and malware even if they are not specifically targeted at your network.
• Monitoring
• Blocking external probes
• Defending against DoS attacks
• Traffic inspection
• Content inspection and filtering
Monitoring
Monitoring, in the form of logging, alert email, and SNMP, does not directly protect your
network. But monitoring allows you to review the progress of an attack, whether
afterwards or while in progress. How the attack unfolds may reveal weaknesses in your
preparations. The packet archive and sniffer policy logs can reveal more details about the
attack. Depending on the detail in your logs, you may be able to determine the attackers
location and identity.
While log information is valuable, you must balance the log information with the resources
required to collect and store it.
Blocking external probes

Protection against attacks is important, but attackers often use vulnerabilities and network
tools to gather information about your network to plan an attack. It is often easier to
prevent an attacker from learning important details about your network than to defend
against an attack designed to exploit your particular network.
Attacks are often tailored to the hardware or operating system of the target, so
reconnaissance is often the first step. The IP addresses of the hosts, the open ports, and
the operating systems the hosts are running is invaluable information to an attacker.
Probing your network can be as simple as an attacker performing an address sweep or
port scan to a more involved operation like sending TCP packets with invalid combinations
of flags to see how your firewall reacts.
Address sweeps
An address sweep is a basic network scanning technique to determine which addresses in
an address range have active hosts. A typical address sweep involves sending an ICMP
ECHO request (a ping) to each address in an address range to attempt to get a response.
A response signifies that there is a host at this address that responded to the ping. It then
becomes a target for more detailed and potentially invasive attacks.

01-420-99686-20101026 749
Blocking external probes Network defense
Address sweeps do not always reveal all the hosts in an address range because some
systems may be configured to ignore ECHO requests and not respond, and some firewalls
and gateways may be configured to prevent ECHO requests from being transmitted to the
destination network. Despite this shortcoming, Address sweeps are still used because
they are simple to perform with software tools that automate the process.
Use the icmp_sweep anomaly in a DoS sensor to protect against address sweeps.
There are a number of IPS signatures to detect the use of ICMP probes that can gather
information about your network. These signatures include AddressMask, Traceroute,
ICMP.Invalid.Packet.Size, and ICMP.Oversized.Packet. Include ICMP
protocol signatures in your IPS sensors to protect against these probes/attacks.
Port scans
Potential attackers may run a port scan on one or more of your hosts. This involves trying
to establish a communication session to each port on a host. If the connection is
successful, a service may be available that the attacker can exploit.
Use the DoS sensor anomaly tcp_port_scan to limit the number of sessions (complete
and incomplete) from a single source IP address to the configured threshold. If the
number of sessions exceed the threshold, the configured action is taken.
Use the DoS sensor anomaly udp_scan to limit UDP sessions in the same way.
Probes using IP traffic options

Every TCP packet has space reserved for eight flags or control bits. They are used for
communicating various control messages. Although space in the packet is reserved for all
eight, there are various combinations of flags that should never happen in normal network
operation. For example, the SYN flag, used to initiate a session, and the FIN flag, used to
end a session, should never be set in the same packet.
Attackers may create packets with these invalid combinations to test how a host will react.
Various operating systems and hardware react in different ways, giving a potential
attackers clues about the components of your network.
The IPS signature TCP.Bad.Flags detects these invalid combinations. The default
action is pass though you can override the default and set it to Block in your IPS sensor.
Configure packet reply and TCP sequence checking

The anti-reply CLI command allows you to set the level of checking for packet replay and
TCP sequence checking (or TCP Sequence (SYN) number checking). All TCP packets
contain a Sequence Number (SYN) and an Acknowledgement Number (ACK). The TCP
protocol uses these numbers for error free end-to-end communications. TCP sequence
checking can also be used to validate individual packets.
FortiGate units use TCP sequence checking to make sure that a packet is part of a TCP
session. By default, if a packet is received with sequence numbers that fall out of the
expected range, the FortiGate unit drops the packet. This is normally a desired behavior,
since it means that the packet is invalid. But in some cases you may want to configure
different levels of anti-replay checking if some of your network equipment uses non-RFC
methods when sending packets.
Configure the anti-reply CLI command:
anti-reply {disable | loose | strict}
end

750 01-420-99686-20101026
Network defense Blocking external probes
You can set anti-replay protection to the following settings:

• disable — No anti-replay protection.
• loose — Perform packet sequence checking and ICMP anti-replay checking with the
following criteria:
• The SYN, FIN, and RST bit can not appear in the same packet.
• The FortiGate unit does not allow more than one ICMP error packet through before
it receives a normal TCP or UDP packet.
• If the FortiGate unit receives an RST packet, and check-reset-range is set to strict,
the FortiGate unit checks to determine if its sequence number in the RST is within
the un-ACKed data and drops the packet if the sequence number is incorrect.
• strict — Performs all of the loose checking but for each new session also checks to
determine of the TCP sequence number in a SYN packet has been calculated correctly
and started from the correct value for each new session. Strict anti-replay checking can
also help prevent SYN flooding.
If any packet fails a check it is dropped.
Configure ICMP error message verification

check-reset-range {disable | strict}
Enable ICMP error message verification to ensure an attacker can not send an invalid
ICMP error message.
check-reset-range {disable | strict}
end
• disable — the FortiGate unit does not validate ICMP error messages.
• strict — enable ICMP error message checking.
If the FortiGate unit receives an ICMP error packet that contains an embedded IP(A,B) |
TCP(C,D) header, then if FortiOS can locate the A:C->B:D session it checks to make sure
that the sequence number in the TCP header is within the range recorded in the session.
If the sequence number is not in range then the ICMP packet is dropped. Strict checking
also affects how the anti-replay option checks packets.
Protocol header checking

Select the level of checking performed on protocol headers.
check-protocol-header {loose | strict}
end
• loose — the FortiGate unit performs basic header checking to verify that a packet is
part of a session and should be processed. Basic header checking includes verifying
that the layer-4 protocol header length, the IP header length, the IP version, the IP
checksum, IP options are correct, etc.
• strict — the FortiGate unit does the same checking as above plus it verifies that
ESP packets have the correct sequence number, SPI, and data length.
If the packet fails header checking it is dropped by the FortiGate unit.

01-420-99686-20101026 751
Blocking external probes Network defense
Evasion techniques
Attackers employ a wide range of tactics to try to disguise their techniques. If an attacker
disguises a known attack in such a way that it is not recognized, the attack will evade your
security and possibly succeed. FortiGate security recognizes a wide variety of evasion
techniques and normalizes data traffic before inspecting it.
Packet fragmentation
Information sent across local networks and the Internet is encapsulated in packets. There
is a maximum allowable size for packets and this maximum size varies depending on
network configuration and equipment limitations. If a packet arrives at a switch or gateway
and it is too large, the data it carries is divided among two or more smaller packets before
being forwarded. This is called fragmentation.
When fragmented packets arrive at their destination, they are reassembled and read. If
the fragments do not arrive together, they must be held until all of the fragments arrive.
Reassembly of a packet requires all of the fragments.
The FortiGate unit automatically reassembles fragmented packets before processing
them because fragmented packets can evade security measures. Both IP packets and
TCP packets are reassembled by the IPS engine before examination.
For example, you have configured the FortiGate unit to block access to the example.org
web site. Any checks for example.com will fail if a fragmented packet arrives and one
fragment contains http://www.exa while the other contains mple.com/. Viruses and
malware can be fragmented and avoid detection in the same way. The FortiGate unit will
reassemble fragmented packets before examining network data to ensure that inadvertent
or deliberate packet fragmentation does not hide threats in network traffic.
Non-standard ports
Most traffic is sent on a standard port based on the traffic type. The FortiGate unit
recognizes most traffic by packet content rather than the TCP/UDP port and uses the
proper IPS signatures to examine it. Protocols recognized regardless of port include
DHCP, DNP3, FTP, HTTP, IMAP, MS RPC, NNTP, POP3, RSTP, SIP, SMTP, and SSL, as
well as the supported IM/P2P application protocols.
In this way, the FortiGate unit will recognize HTTP traffic being sent on port 25 as HTTP
rather than SMTP, for example. Because the protocol is correctly identified, the FortiGate
unit will examine the traffic for any enabled HTTP signatures.
Negotiation codes
Telnet and FTP servers and clients support the use of negotiation information to allow the
server to report what features it supports. This information has been used to exploit
vulnerable servers. To avoid this problem, the FortiGate unit removes negotiation codes
before IPS inspection.
HTTP URL obfuscation

Attackers encode HTML links using various formats to evade detection and bypass
security measures. For example, the URL www.example.com/cgi.bin could be encoded in
a number of ways to avoid detection but still work properly, and be interpreted the same, in
a web browser.
The FortiGate prevents the obfuscation by converting the URL to ASCII before inspection.

752 01-420-99686-20101026
Network defense Defending against DoS attacks
Table 56: HTTP URL obfuscation types
Encoding type Example

No encoding http://www.example.com/cgi.bin/
Decimal encoding http://www.example.com/cgi.bi&#110
;/
URL encoding http://www.example.com/%43%47%49%2E%42%49%4E%2F
ANSI encoding http://www.example.com/%u0063%u0067%u0069%u002E%u0062%u
0069%u006E/
Directory traversal http://www.example.com/cgi.bin/test/../
HTTP header obfuscation

The headers of HTTP requests or responses can be modified to make the discovery of
patterns and attacks more difficult. To prevent this, the FortiGate unit will:
• remove junk header lines
• reassemble an HTTP header that’s been folded onto multiple lines
• move request parameters to HTTP POST body from the URL
The message is scanned for any enabled HTTP IPS signatures once these problems are
corrected.
HTTP body obfuscation

The body content of HTTP traffic can be hidden in an attempt to circumvent security
scanning. HTTP content can be GZipped or deflated to prevent security inspection. The
FortiGate unit will uncompress the traffic before inspecting it.
Another way to hide the contents of HTTP traffic is to send the HTTP body in small pieces,
splitting signature matches across two separate pieces of the HTTP body. The FortiGate
unit reassembles these ‘chunked bodies’ before inspection.
Microsoft RPC evasion

Because of its complexity, the Microsoft Remote Procedure Call protocol suite is subject to
a number of known evasion techniques, including:
• SMB-level fragmentation
• DCERPC-level fragmentation
• DCERPC multi-part fragmentation
• DCERPC UDP fragmentation
• Multiple DCERPC fragments in one packet
The FortiGate unit reassembles the fragments into their original form before inspection.
Defending against DoS attacks

A denial of service is the result of an attacker sending an abnormally large amount of
network traffic to a target system. Having to deal with the traffic flood slows down or
disables the target system so that legitimate users can not use it for the duration of the
attack.

01-420-99686-20101026 753
Defending against DoS attacks Network defense
Any network traffic the target system receives has to be examined, and then accepted or
rejected. TCP, UDP, and ICMP traffic is most commonly used, but a particular type of TCP
traffic is the most effective. TCP packets with the SYN flag are the most efficient DoS
attack tool because of how communication sessions are started between systems.
The “three-way handshake”

Communication sessions between systems start with establishing a TCP/IP connection.
This is a simple three step process, sometimes called a “three-way handshake,” initiated
by the client attempting to open the connection.
1 The client sends a TCP packet with the SYN flag set. With the SYN packet, the client
informs the server of its intention to establish a connection.
2 If the server is able to accept the connection to the client, it sends a packet with the
SYN and the ACK flags set. This simultaneously acknowledges the SYN packet the
server has received, and informs the client that the server intends to establish a
connection.
3 To acknowledge receipt of the packet and establish the connection, the client sends an
ACK packet.
Figure 63: Establishing a TCP/IP connection
Connection initiation request: SYN
Request acknowledgement: SYN/ACK
Server Client
Connection initiated: ACK
The three-way handshake is a simple way for the server and client to each agree to
establish a connection and acknowledge the other party expressing its intent.
Unfortunately, the three-way handshake can be used to interfere with communication
rather than facilitate it.
SYN flood
When a client sends a SYN packet to a server, the server creates an entry in its session
table to keep track of the connection. The server then sends a SYN+ACK packet
expecting an ACK reply and the establishment of a connection.
An attacker intending to disrupt a server with a denial of service (DoS) attack can send a
flood of SYN packets and not respond to the SYN+ACK packets the server sends in
response. Networks can be slow and packets can get lost so the server will continue to
send SYN+ACK packets until it gives up, and removes the failed session from the session
table. If an attacker sends enough SYN packets to the server, the session table will fill
completely, and further connection attempts will be denied until the incomplete sessions
time out. Until this happens, the server is unavailable to service legitimate connection
requests.

754 01-420-99686-20101026
Network defense Defending against DoS attacks
Figure 64: A single client launches a SYN flood attack

Server Client
SYN floods are seldom launched from a single address so limiting the number of
connection attempts from a single IP address is not usually effective.
SYN spoofing
With a flood of SYN packets coming from a single attacker, you can limit the number of
connection attempts from the source IP address or block the attacker entirely. To prevent
this simple defense from working, or to disguise the source of the attack, the attacker may
spoof the source address and use a number of IP addresses to give the appearance of a
distributed denial of service (DDoS) attack. When the server receives the spoofed SYN
packets, the SYN+ACK replies will go to the spoofed source IP addresses which will either
be invalid, or the system receiving the reply will not know what to do with it.
Figure 65: A client launches a SYN spoof attack
Client
Server
DDoS SYN flood

The most severe form of SYN attack is the distributed SYN flood, one variety of distributed
denial of service attack (DDoS). Like the SYN flood, the target receives a flood of SYN
packets and the ACK+SYN replies are never answered. The attack is distributed across
multiple sources sending SYN packets in a coordinated attack.

01-420-99686-20101026 755
Defending against DoS attacks Network defense
Figure 66: Multiple attackers launch a distributed SYN flood

Server
The distributed SYN flood is more difficult to defend against because multiple clients are
capable of creating a larger volume of SYN packets than a single client. Even if the server
can cope, the volume of traffic may overwhelm a point in the network upstream of the
targeted server. The only defence against this is more bandwidth to prevent any
choke-points.
Configuring the SYN threshold to prevent SYN floods

The preferred primary defence against any type of SYN flood is the DoS sensor
tcp_syn_flood threshold. The threshold value sets an upper limit on the number of new
incomplete TCP connections allowed per second. If the number of incomplete connections
exceeds the threshold value, and the action is set to Pass, the FortiGate unit will allow the
SYN packets that exceed the threshold. If the action is set to Block, the FortiGate unit will
block the SYN packets that exceed the threshold, but it will allow SYN packets from clients
that send another SYN packet.
The tools attackers use to generate network traffic will not send a second SYN packet
when a SYN+ACK response is not received from the server. These tools will not “retry.”
Legitimate clients will retry when no response is received, and these retries are allowed
even if they exceed the threshold with the action set to Block.
For more information, see “Creating and configuring a DoS sensor” on page 881. For
recommendations on how to configure DoS policies, see “DoS policy recommendations”
on page 758.
SYN proxy
FortiGate units with Fortinet security processing modules installed offer a third action for
the tcp_syn_flood threshold when a module is installed. Instead of Block and Pass,
you can choose to Proxy the incomplete connections that exceed the threshold value.
When the tcp_syn_flood threshold action is set to Proxy, incomplete TCP connections
are allowed as normal as long as the configured threshold is not exceeded. If the
threshold is exceeded, the FortiGate unit will intercept incoming SYN packets from clients
and respond with a SYN+ACK packet. If the FortiGate unit receives an ACK response as
expected, it will “replay” this exchange to the server to establish a communication session
between the client and the server, and allow the communication to proceed.

756 01-420-99686-20101026
Network defense Traffic inspection
Other flood types

UDP and ICMP packets can also be used for DoS attacks, though they are less common.
TCP SYN packets are so effective because the target receives them and maintains a
session table entry for each until they time out. Attacks using UDP or ICMP packets do not
require the same level of attention from a target, rendering them less effective. The target
will usually drop the offending packets immediately, closing the session.
Use the udp_flood and icmp_flood thresholds to defend against these DoS attacks.
Traffic inspection
When the FortiGate unit examines network traffic one packet at a time for IPS signatures,
it is performing traffic analysis. This is unlike content analysis where the traffic is buffered
until files, email messages, web pages, and other files are assembled and examined as a
whole.
DoS policies use traffic analysis by keeping track of the type and quantity of packets, as
well as their source and destination addresses.
Application control uses traffic analysis to determine which application generated the
packet.
Although traffic inspection doesn’t involve taking packets and assembling files they are
carrying, the packets themselves can be split into fragments as they pass from network to
network. These fragments are reassembled by the FortiGate unit before examination.
No two networks are the same and few recommendations apply to all networks. This topic
offers suggestions on how you can use the FortiGate unit to help secure your network
against content threats.
IPS signatures
IPS signatures can detect malicious network traffic. For example, the Code Red worm
attacked a vulnerability in the Microsoft IIS web server. Your FortiGate’s IPS system can
detect traffic attempting to exploit this vulnerability. IPS may also detect when infected
systems communicate with servers to receive instructions.
IPS recommendations
• Enable IPS scanning at the network edge for all services.
• Use FortiClient endpoint IPS scanning for protection against threats that get into your
network.
• Subscribe to FortiGuard IPS Updates and configure your FortiGate unit to receive push
updates. This will ensure you receive new IPS signatures as soon as they are
available.
• Your FortiGate unit includes IPS signatures written to protect specific software titles
from DoS attacks. Enable the signatures for the software you have installed and set the
signature action to Block.
You can view these signatures by going to UTM > Intrusion Protection > Predefined
and sorting by, or applying a filter to, the Group column.
• Because it is critical to guard against attacks on services that you make available to the
public, configure IPS signatures to block matching signatures. For example, if you
have a web server, configure the action of web server signatures to Block.

01-420-99686-20101026 757
Traffic inspection Network defense
Suspicious traffic attributes

Network traffic itself can be used as an attack vector or a means to probe a network before
an attack. For example, SYN and FIN flags should never appear together in the same
TCP packet. The SYN flag is used to initiate a TCP session while the FIN flag indicates
the end of data transmission at the end of a TCP session.
The FortiGate unit has IPS signatures that recognize abnormal and suspicious traffic
attributes. The SYN/FIN combination is one of the suspicious flag combinations detected
in TCP traffic by the TCP.BAD.FLAGS signature.
The signatures that are created specifically to examine traffic options and settings, begin
with the name of the traffic type they are associated with. For example, signatures created
to examine TCP traffic have signature names starting with TCP.
DoS policies
DDoS attacks vary in nature and intensity. Attacks aimed at saturating the available
bandwidth upstream of your service can only be countered by adding more bandwidth.
DoS policies can help protect against DDoS attacks that aim to overwhelm your server
resources.
DoS policy recommendations

• Use and configure DoS policies to appropriate levels based on your network traffic and
topology. This will help drop traffic if an abnormal amount is received.
• It is important to set a good threshold. The threshold defines the maximum number of
sessions/packets per second of normal traffic. If the threshold is exceeded, the action
is triggered. Threshold defaults are general recommendations, although your network
may require very different values.
One way to find the correct values for your environment is to set the action to Pass and
enable logging. Observe the logs and adjust the threshold values until you can
determine the value at which normal traffic begins to generate attack reports. Set the
threshold above this value with the margin you want. Note that the smaller the margin,
the more protected your system will be from DoS attacks, but your system will also be
more likely to generate false alarms.
Application control
While applications can often be blocked by the ports they use, application control allows
convenient management of all supported applications, including those that do not use set
ports.
Application control recommendations

• Some applications behave in an unusual manner in regards to application control. For
more information, see “Application considerations” on page 878.
• By default, application control allows the applications not specified in the application
control list. For high security networks, you may want to change this behavior so that
only the explicitly allowed applications are permitted.

758 01-420-99686-20101026
Network defense Content inspection and filtering
Content inspection and filtering

When the FortiGate unit buffers the packets containing files, email messages, web pages,
and other similar files for reassembly before examining them, it is performing content
inspection. Traffic inspection, on the other hand, is accomplished by the FortiGate unit
examining individual packets of network traffic as they are received.
No two networks are the same and few recommendations apply to all networks. This topic
offers suggestions on how you can use the FortiGate unit to help secure your network
against content threats. Be sure to understand the effects of the changes before using the
suggestions.
AntiVirus
The FortiGate antivirus scanner can detect viruses and other malicious payloads used to
infect machines. The FortiGate unit performs deep content inspection. To prevent
attempts to disguise viruses, the antivirus scanner will reassemble fragmented files and
uncompress content that has been compressed. Patented Compact Pattern Recognition
Language (CPRL) allows further inspection for common patterns, increasing detection
rates of virus variations in the future.
AntiVirus recommendations
• Enable antivirus scanning at the network edge for all services.
• Use FortiClient endpoint antivirus scanning for protection against threats that get into
your network.
• Subscribe to FortiGuard AntiVirus Updates and configure your FortiGate unit to receive
push updates. This will ensure you receive new antivirus signatures as soon as they
are available.
• Enable the Extended Virus Database if your FortiGate unit supports it.
• Examine antivirus logs periodically. Take particular notice of repeated detections. For
example, repeated virus detection in SMTP traffic could indicate a system on your
network is infected and is attempting to contact other systems to spread the infection
using a mass mailer.
• The builtin-patterns file filter list contains nearly 20 file patterns. Many of the
represented files can be executed or opened with a double-click. If any of these file
patterns are not received as a part of your normal traffic, blocking them may help
protect your network. This also saves resources since files blocked in this way do not
need to be scanned for viruses.
• To conserve system resources, avoid scanning email messages twice. Scan messages
as they enter and leave your network or when clients send and retrieve them, rather
than both.
FortiGuard Web Filtering

The web is the most popular part of the Internet and, as a consequence, virtually every
computer connected to the Internet is able to communicate using port 80, HTTP. Botnet
communications take advantage of this open port and use it to communicate with infected
computers. FortiGuard Web Filtering can help stop infections from malware sites and help
prevent communication if an infection occurs.

01-420-99686-20101026 759
Content inspection and filtering Network defense
FortiGuard Web Filtering recommendations

• Enable FortiGuard Web Filtering at the network edge.
• Install the FortiClient application and use FortiGuard Web Filtering on any systems that
bypass your FortiGate unit.
• Block categories such as Pornography, Malware, Spyware, and Phishing. These
categories are more likely to be dangerous.
• In the email filter profile, enable IP Address Check in FortiGuard Email Filtering. Many
IP addresses used in spam messages lead to malicious sites; checking them will
protect your users and your network.
Email filter
Spam is a common means by which attacks are delivered. Users often open email
attachments they should not, and infect their own machine. The FortiGate email filter can
detect harmful spam and mark it, alerting the user to the potential danger.
Email filter recommendations

• Enable email filtering at the network edge for all types of email traffic.
• Use FortiClient endpoint scanning for protection against threats that get into your
network.
• Subscribe to the FortiGuard AntiSpam Service.
DLP
Most security features on the FortiGate unit are designed to keep unwanted traffic out of
your network while DLP can help you keep sensitive information from leaving your
network. For example, credit card numbers and social security numbers can be detected
by DLP sensors.
DLP recommendations
• Rules related to HTTP posts can be created, but if the requirement is to block all HTTP
posts, a better solution is to use application control or the HTTP POST Action option in
the web filter profile.
• While DLP can detect sensitive data, it is more efficient to block unnecessary
communication channels than to use DLP to examine it. If you don’t use instant
messaging or peer-to-peer communication in your organization, for example, use
application control to block them entirely.

760 01-420-99686-20101026
AntiVirus
This section describes how to configure the antivirus options. From an antivirus profile you
can configure the FortiGate unit to apply antivirus protection to HTTP, FTP, IMAP, POP3,
SMTP, IM, and NNTP sessions. If your FortiGate unit supports SSL content scanning and
inspection, you can also configure antivirus protection for HTTPS, IMAPS, POP3S, and
SMTPS sessions.
• Antivirus concepts
• Enable antivirus scanning
• Enable the file quarantine
• Enable file filtering
• Enable grayware scanning
• Testing your antivirus configuration
• Antivirus examples
Antivirus concepts
The word “antivirus” refers to a group of features that are designed to prevent unwanted
and potentially malicious files from entering your network. These features all work in
different ways, which include checking for a file size, name, or type, or for the presence of
a virus or grayware signature.
The antivirus scanning routines your FortiGate unit uses are designed to share access to
the network traffic. This way, each individual feature does not have to examine the
network traffic as a separate operation, and the overhead is reduced significantly. For
example, if you enable file filtering and virus scanning, the resources used to complete
these tasks are only slightly greater than enabling virus scanning alone. Two features do
not require twice the resources.
How antivirus scanning works

Antivirus scanning examines files for viruses, worms, trojans, and malware. The antivirus
scan engine has a database of virus signatures it uses to identify infections. If the scanner
finds a signature in a file, it determines that the file is infected and takes the appropriate
action.
The most thorough scan requires that the FortiGate unit have the whole file for the
scanning procedure. To achieve this, the antivirus proxy buffers the file as it arrives. Once
the transmission is complete, the virus scanner examines the file. If no infection is present,
it is sent to the destination. If an infection is present, a replacement message is set to the
destination.
During the buffering and scanning procedure, the client must wait. With a default
configuration, the file is released to the client only after it is scanned. You can enable client
comforting in the protocol options profile to feed the client a trickle of data to prevent them
from thinking the transfer is stalled, and possibly cancelling the download.

01-420-99686-20101026 761
Antivirus concepts AntiVirus
Buffering the entire file allows the FortiGate unit to eliminate the danger of missing an
infection due to fragmentation because the file is reassembled before examination.
Archives can also be expanded and the contents scanned, even if archives are nested.
Since the FortiGate unit has a limited amount of memory, files larger than a certain size do
not fit within the memory buffer. The default buffer size is 10 MB. You can use the
uncompsizelimit CLI command to adjust the size of this memory buffer.
Files larger than the buffer are passed to the destination without scanning. You can use
the Oversize File/Email setting to block files larger than the antivirus buffer if allowing files
that are too large to be scanned is an unacceptable security risk.
Flow-based antivirus scanning

If your FortiGate unit supports flow-based antivirus scanning, you can choose to select it
instead of proxy-based antivirus scanning. Flow-based antivirus scanning uses the
FortiGate IPS engine to examine network traffic for viruses, worms, trojans, and malware,
without the need to buffer the file being checked.
The advantages of flow-based scanning include faster scanning and no maximum file
size. Flow-based scanning doesn’t require the file be buffered so it is scanned as it passes
through the FortiGate unit, packet-by-packet. This eliminates the maximum file size limit
and the client begins receiving the file data immediately.
The trade-off for these advantages is that flow-based scans detect a smaller number of
infections. Viruses in documents, packed files, and some archives are less likely to be
detected because the scanner can only examine a small portion of the file at any moment.
Note however that your choice of flow-based or proxy-based scans only affects antivirus
scans. Although you enable file filtering in the antivirus profile, it requires that files be
proxied. Therefore, if you enable both flow-based antivirus scanning and file filtering, files
will not be proxied for antivirus scans, but they will be proxied for file filtering.
Note: Your choice of flow-based or proxy-based scanning affects only antivirus scans. File
filtering requires that files be proxied. If you enable both flow-based antivirus scanning and
file filtering, files will not be proxied for antivirus scans, but they will be proxied for file
filtering.
Antivirus scanning order

The antivirus scanning function includes various modules and engines that perform
separate tasks.
Proxy-based antivirus scanning order

Figure 67 on page 763 illustrates the antivirus scanning order when using proxy-based
scanning (i.e. the normal, extended, or extreme databases). The first check for oversized
files/email is to determine whether the file exceeds the configured size threshold. The
uncompsizelimit check is to determine if the file can be buffered for file type and
antivirus scanning. If the file is too large for the buffer, it is allowed to pass without being
scanned. For more information, see the config antivirus service command in the
FortiGate CLI Reference. The antivirus scan includes scanning for viruses, as well as for
grayware and heuristics if they are enabled.
Note: File filtering includes file pattern and file type scans which are applied at different
stages in the antivirus process.

762 01-420-99686-20101026
AntiVirus Antivirus concepts
Figure 67: Antivirus scanning order when using the normal, extended, or extreme database
File or message
Start
is buffered
FTP, NNTP, SMTP,
POP3, IMAP, or
HTTP traffic.
File/email Pass
Oversized
exceeds
file/email
oversized
Yes action
threshold
No
Block
File Matching File Yes Matching

Pattern Block Block
file pattern Pattern file pattern
Match? file/email file/email
Yes action Block Match? action Block
Allow No Allow
No
Yes
File/email File/email Antivirus

exceeds exceeds scan detects
uncompsizelimit uncompnestlimit infection?
No No
threshold threshold?
Yes No
Yes
Block
Matching Matching
File type Pass File type file type
Pass file type
match? file/email match? action
file/email No Yes action Block No Yes
Allow Allow
If a file fails any of the tasks of the antivirus scan, no further scans are performed. For
example, if the file fakefile.EXE is recognized as a blocked file pattern, the FortiGate
unit will send the end user a replacement message, and delete or quarantine the file. The
unit will not perform virus scan, grayware, heuristics, and file type scans because the
previous checks have already determined that the file is a threat and have dealt with it.
Flow-based antivirus scanning order

Figure 68 on page 764 illustrates the antivirus scanning order when using flow-based
scanning (i.e. the flow-based database). The antivirus scan takes place before any other
antivirus-related scan. If file filter is not enabled, the file is not buffered. The antivirus scan
includes scanning for viruses, as well as for grayware and heuristics if they are enabled.
Note: File filtering includes file pattern and file type scans which are applied at different
stages in the antivirus process.

01-420-99686-20101026 763
Antivirus concepts AntiVirus
Figure 68: Antivirus scanning order when using the flow-based database
File filter Antivirus

File or message Yes
enabled in scan detects
is buffered Start
antivirus No infection?
profile?
FTP, NNTP, SMTP,
POP3, IMAP, or
No HTTP traffic.
Yes
Pass
file/email
File/email
Oversized
exceeds
file/email
oversized
Yes action
threshold
Block
Pass
No
File Matching
Pattern Block
file pattern
Match? file/email
Yes action Block
Allow
No
Block
File/email
Matching
exceeds File type
file type
uncompsizelimit match?
No Yes action
threshold
Yes
Allow
No
Pass
file/email
Antivirus databases
The antivirus scanning engine relies on a database to detail the unique attributes of each
infection. The antivirus scan searches for these signatures, and when one is discovered,
the FortiGate unit determines the file is infected and takes action.
All FortiGate units have the normal antivirus signature database but some models have
additional databases you can select for use. Which you choose depends on your network
and security needs.
Normal Includes viruses currently spreading as determined by the FortiGuard Global

Security Research Team. These viruses are the greatest threat. The Normal
database is the default selection and it is available on every FortiGate unit.
Extended Includes the normal database in addition to recent viruses that are no-longer active.
These viruses may have been spreading within the last year but have since nearly or
completely disappeared.
Extreme Includes the extended database in addition to a large collection of ‘zoo’ viruses.
These are viruses that have not spread in a long time and are largely dormant today.
Some zoo viruses may rely on operating systems and hardware that are no longer
widely used.
Flow The flow-based database is a subset of the extreme database. Flow-based scans
can not detect polymorphic and packed-file viruses so those signatures and not
included in the flow-based database.
Note that flow-based scanning is not just another database, but a different type of
scanning. For more information, see “How antivirus scanning works” on page 761.

764 01-420-99686-20101026
AntiVirus Antivirus concepts
Antivirus techniques
The antivirus features work in sequence to efficiently scan incoming files and offer your
network optimum antivirus protection. The first four features have specific functions, the
fifth, heuristics, protects against any new, previously unknown virus threats. To ensure that
your system is providing the most protection available, all virus definitions and signatures
are updated regularly through the FortiGuard antivirus services. The features are
discussed in the order that they are applied, followed by FortiGuard antivirus.
File size
This task checks if files and email messages exceed configured size thresholds. You
enable this check by editing your protocol options profiles and setting the Oversized
File/Email option to Block for each protocol. The maximum size you can set varies by
model.
File pattern
Once a file is accepted, the FortiGate unit applies the file pattern recognition filter. The unit
will check the file name against the file pattern setting you have configured. If the file name
matches a blocked pattern, “.EXE” for example, then it is stopped and a replacement
message is sent to the end user. No other levels of protection are applied. If the file name
does not match a blocked pattern, the next level of protection is applied.
Virus scan
If the file passes the file pattern scan, the FortiGate unit applies a virus scan to it. The virus
definitions are kept up-to-date through the FortiGuard Distribution Network (FDN). For
more information, see “FortiGuard Antivirus” on page 766.
Grayware
If the file passes the virus scan, it will be checked for grayware. Grayware configurations
can be turned on and off as required and are kept up to date in the same manner as the
antivirus definitions. For more information, see “Enable grayware scanning” on page 775.
Heuristics
After an incoming file has passed the grayware scan, it is subjected to the heuristics scan.
The FortiGate heuristic antivirus engine, if enabled, performs tests on the file to detect
virus-like behavior or known virus indicators. In this way, heuristic scanning may detect
new viruses, but may also produce some false positive results.
Note: You can configure heuristics only through the CLI. See the FortiGate CLI Reference.
File type
Finally, the FortiGate unit applies the file type recognition filter. The FortiGate unit will
check the file against the file type setting you have configured. If the file is a blocked type,
then it is stopped and a replacement message is sent to the end user. No other levels of
protection are applied.

01-420-99686-20101026 765
Enable antivirus scanning AntiVirus
FortiGuard Antivirus
FortiGuard Antivirus services are an excellent resource which includes automatic updates
of virus and IPS (attack) engines and definitions, as well as the local spam DNS black list
(DNSBL), through the FDN. The FortiGuard Center web site also provides the FortiGuard
Antivirus virus and attack encyclopedia.
The connection between the FortiGate unit and FortiGuard Center is configured in
System > Maintenance > FortiGuard.
Enable antivirus scanning

Antivirus scanning is enabled in the antivirus profile. Once the antivirus profile is enabled
and selected in one or more firewall policies, all the traffic controlled by those firewall
policies will scanned according to your settings.
To enable antivirus scanning — web-based manager

1 Go to UTM > AntiVirus > Profile.
2 Select Create New to create a new antivirus profile, or select an existing antivirus
profile and choose Edit.
3 In the row labeled Virus Scan, select the check boxes associated with the traffic you
want scanned for viruses.
4 Select OK.
To enable antivirus scanning — CLI

You need to configure the scan option for each type of traffic you want scanned. In this
example, antivirus scanning of HTTP traffic is enabled in the profile.
edit my_av_profile
config http
set options scan
end
end
Viewing antivirus database information

The FortiGate antivirus scanner relies on up-to-date virus signatures to detect the newest
threats. To view the information about the FortiGate unit virus signatures, check the status
page or the Virus Database information page:
• Status page: Go to System > Dashboard > Dashboard. In the License Information
section under FortiGuard Services, the AV Definitions field shows the regular antivirus
database version as well as when it was last updated.
If your FortiGate unit supports extended and extreme virus database definitions, the
database versions and date they were last updated is displayed in the Extended set
and Extreme DB fields.
The flow-based virus database is distributed as part of the IPS signature database. Its
database version and date it was last updated is displayed in the IPS Definitions field.

766 01-420-99686-20101026
AntiVirus Enable antivirus scanning
• Virus Database: Go to UTM > AntiVirus > Virus Database. This page shows the
version number, number of included signatures, and a description of the regular virus
database.
If your FortiGate unit supports extended, extreme, or flow-based virus database
definitions, the version numbers, number of included signatures, and descriptions of
those databases are also displayed.
Changing the default antivirus database

If your FortiGate unit supports extended, extreme, or flow-based virus database
definitions, you can select the virus database most suited to your needs.
In most circumstances, the regular virus database provides sufficient protection. Viruses
known to be active are included in the regular virus database. The extended database
includes signatures of the viruses that have become rare within the last year in addition to
those in the normal database. The extreme database includes legacy viruses that have
not been seen in the wild in a long time in addition to those in the extended database.
The flow-based database contains a subset of the virus signatures in the extreme
database. Unlike the other databases, selecting the flow-based database also changes
the way the FortiGate unit scans your network traffic for viruses. Instead of the standard
proxy-based scan, network traffic is scanned as it streams thought the FortiGate unit. For
more information on the differences between flow-based and proxy-based antivirus
scanning, see “How antivirus scanning works” on page 761.
If you require the most comprehensive antivirus protection, enable the extended virus
database. The additional coverage comes at a cost, however, because the extra
processing requires additional resources.
To change the antivirus database — web-based manager

1 Go to UTM > AntiVirus > Virus Database.
2 Select the antivirus database the FortiGate unit will use as the default database to
perform antivirus scanning of your network traffic.
3 Select Apply.
To change the antivirus database — CLI

set default-db extended
end
Overriding the default antivirus database

The default antivirus database is used for all antivirus scanning. If you have a particular
policy or traffic type that requires scanning using a different antivirus database, you can
override the default database. Antivirus database overrides are applied to individual traffic
types in an antivirus profile. The override will affect only the traffic types to which the
override is applied for the traffic handled by the firewall policy the antivirus profile is
applied to. Antivirus database overrides can be set using only the CLI.
In this example, a database override is applied to HTTP traffic in a protocol options profile
named web_traffic. The flow-based database is specified.

01-420-99686-20101026 767
To override the default antivirus database — CLI

edit web-traffic
config http
set avdb flow-based
end
end
With this configuration, the flow-based database is used for antivirus scans on HTTP
traffic controlled by firewall policies in which this antivirus profile is selected. Other traffic
types will use the default database, as specified in UTM > AntiVirus > Virus Database.
Adding the antivirus profile to a firewall policy

This procedure is required only if your antivirus profile does not yet belong to a firewall
policy. You need to add the antivirus profile to a policy before any antivirus profile settings
can take effect.
To add the antivirus profile to a policy

2 Select Create New to add a new policy, or select the Edit icon of the firewall policy to
which you want to add the profile.
3 Enable UTM.
4 Select Enable AntiVirus and select the antivirus profile that contains the quarantine
configuration.
5 Select OK to save the firewall policy.
Configuring the scan buffer size

When checking files for viruses using the proxy-based scanning method, there is a
maximum file size that can be buffered. Files larger than this size are passed without
scanning. The default size for all FortiGate models is 10 megabytes.
Archived files are extracted and email attachments are decoded before the FortiGate unit
determines if they can fit in the scan buffer. For example, a 7 megabyte ZIP file containing
a 12 megabyte EXE file will be passed without scanning with the default buffer size.
Although the archive would fit within the buffer, the uncompressed file size will not.
In this example, the uncompsizelimit CLI command is used to change the scan buffer
size to 20 megabytes for files found in HTTP traffic:
config antivirus service http
set uncompsizelimit 20
end
The maximum buffer size varies by model. Enter set uncompsizelimit ? to display
the buffer size range for your FortiGate unit.
Note: Flow-based scanning does not use a buffer and therefore has no file-size limit. File
data is scanned as it passes through the FortiGate unit. The uncompsizelimit setting
has no effect for flow-based scanning.

768 01-420-99686-20101026
AntiVirus Enable antivirus scanning
Configuring archive scan depth

The antivirus scanner will open archives and scan the files inside. Archives within other
archives, or nested archives, are also scanned to a default depth of twelve nestings. You
can adjust the number of nested archives to which the FortiGate unit will scan with the
uncompnestlimit CLI command. Further, the limit is configured separately for each
traffic type.
For example, this CLI command sets the archive scan depth for SMTP traffic to 5. That is,
archives within archives will be scanned five levels deep.
config antivirus service smtp
set uncompnestlimit 5
end
You can set the nesting limit from 2 to 100.
Configuring a maximum allowed file size

The protocol option profile allows you to enforce a maximum allowed file size for each of
the network protocols in the profile. They are HTTP, FTP, IMAP, POP3, SMTP, IM, and
NNTP. If your FortiGate unit supports SSL content scanning and inspection, you can also
configure a maximum file size for HTTPS, IMAPS, POP3S, and SMTPS.
The action you set determines what the FortiGate unit does with a file that exceeds the
oversized file threshold. Two actions are available:
Block Files that exceed the oversize threshold are dropped and a
replacement message is sent to the user instead of the file.
Pass Files exceed the oversized threshold are allowed through the
FortiGate unit to their destination. Note that passed files are not
scanned for viruses. File Filtering, both file pattern and file type, are
applied, however.
You can also use the maximum file size to help secure your network. If you’re using a
proxy-based virus scan, the proxy scan buffer size limits the size of the files that can be
scanned for infection. Files larger than this limit are passed without scanning. If you
configure the maximum file size to block files larger than the scan buffer size, large
infected files will not by-pass antivirus scanning.
In this example, the maximum file size will be configured to block files larger than 10
megabytes, the largest file that can be antivirus scanned with the default settings. You will
need to configure a protocol options profile and add it to a firewall policy.
Create a protocol options profile to block files larger than 10 MB

1 Go to Firewall > Policy > Protocol Options.
3 Enter 10MB_Block for the protocol options policy name.
4 For the comment, enter Files larger than 10MB are blocked.
5 Expand each protocol listed and select Block for the Oversized File/Email setting. Also
confirm that the Threshold is set to 10.
6 Select OK.
The protocol options profile is configured, but to block files, you must select it in the
firewall profiles handling the traffic that contains the files you want blocked.

01-420-99686-20101026 769
To select the protocol options profile in a firewall policy

2 Select a firewall policy.
3 Select the Edit icon.
4 Enable UTM.
5 Select Protocol Options.
6 Select 10MB_Block from the Protocol Options list.
Once you complete these steps, any files in the traffic handled by this policy that are larger
than 10MB will be blocked. If you have multiple firewall policies, examine each to
determine if you want to apply similar file blocking the them as well.
Configuring client comforting

When proxy-based antivirus scanning is enabled, the FortiGate unit buffers files as they
are downloaded. Once the entire file is captured, the FortiGate unit scans it. If no infection
is found, the file is sent along to the client. The client initiates the file transfer and nothing
happens until the FortiGate finds the file clean, and releases it. Users can be impatient,
and if the file is large or the download slow, they may cancel the download, not realizing
that the transfer is in progress.
The client comforting feature solves this problem by allowing a trickle of data to flow to the
client so they can see the file is being transferred. The default client comforting transfer
rate sends one byte of data to the client every ten seconds. This slow transfer continues
while the FortiGate unit buffers the file and scans it. If the file is infection-free, it is released
and the client will receive the remainder of the transfer at full speed. If the file is infected,
the FortiGate unit caches the URL and drops the connection. The client does not receive
any notification of what happened because the download to the client had already started.
Instead, the download stops and the user is left with a partially downloaded file.
If the user tries to download the same file again within a short period of time, the cached
URL is matched and the download is blocked. The client receives the Infection cache
message replacement message as a notification that the download has been blocked.
The number of URLs in the cache is limited by the size of the cache.
Caution: Client comforting can send unscanned and therefore potentially infected content
to the client. You should only enable client comforting if you are prepared to accept this risk.
Keeping the client comforting interval high and the amount low will reduce the amount of
potentially infected data that is downloaded.
Client comforting is available for HTTP and FTP traffic. If your FortiGate unit supports SSL
content scanning and inspection, you can also configure client comforting for HTTPS
traffic.
Enable and configure client comforting

1 Go to Firewall > Policy > Protocol Options.
2 Select a protocol options profile and choose Edit, or select Create New to make a new
one.
3 Expand HTTP, FTP, and if your FortiGate unit supports SSL content scanning and
inspection, expand HTTPS as well.
4 To enable client comforting, select Comfort Clients for each of the protocols in which
you want it enabled.

770 01-420-99686-20101026
AntiVirus Enable the file quarantine
5 Select OK to save the changes.

6 Select this protocol options profile in any firewall policy for it to take effect on all traffic
handled by the policy.
The default values for Interval and Amount are 10 and 1, respectively. This means that
when client comforting takes effect, 1 byte of the file is sent to the client every 10 seconds.
You can change these values to vary the amount and frequency of the data transferred by
client comforting.
Enable the file quarantine

You can quarantine blocked and infected files if you have a FortiGate unit with a local hard
disk. You can view the file name and status information about the file in the Quarantined
Files list and submit specific files and add file patterns to the AutoSubmit list so they will
automatically be uploaded to the FortiGuard AntiVirus service for analysis.
FortiGate units can also quarantine blocked and infected files to a FortiAnalyzer unit. Files
stored on the FortiAnalyzer unit can also be viewed from the Quarantined Files list in the
FortiGate unit.

The following steps provide an overview of the file quarantine configuration. For best
results, follow the procedures in the order given. Note that if you perform any additional
actions between procedures, your configuration may have different results.
1 Go to UTM > AntiVirus > Quarantine to configure the quarantine service and
destination.
2 Go to UTM > AntiVirus > Profile and edit an existing antivirus profile or create a new
one. In the Quarantine row, select the check boxes of the protocols for which you want
the quarantine enabled. The Quarantine option only appears if your FortiGate unit has
a local disk or if your FortiGate unit is configured to use a FortiAnalyzer unit to
quarantine files.
Note: Antivirus profiles also have a configurable feature called Quarantine Virus Sender (to
Banned User List). This is a different feature unrelated to the Quarantine option.
3 If you have not previously done so, go to Firewall > Policy and add the antivirus profile
to a firewall policy.
Configuring the file quarantine

You can configure quarantine options for HTTP, FTP, IMAP, POP3, SMTP, IM, and NNTP
Traffic. If your FortiGate unit supports SSL content scanning and inspection you can also
quarantine blocked and infected files from HTTPS, IMAPS, POP3S, and SMTPS traffic.

01-420-99686-20101026 771
Enable the file quarantine AntiVirus
To configure the file quarantine

1 Go to UTM > AntiVirus > Quarantine.
2 In the options table, select the files to quarantine.
The options table lists three detection methods used to find potentially problematic
files, as well as the types of traffic scanned for these files. Select one or more check
boxes for the following traffic types to enable quarantine for detected files:
• Infected Files: files in which the FortiGate unit detects virus signatures
• Suspicious Files: files detected by the heuristics scanner
• Blocked Files: files matching patterns or types defined in a file filter.
3 In the Max Filesize to Quarantine field, enter the maximum file size to quarantine, in
megabytes. Files that exceed this size limit are not quarantined.
4 In the Age Limit field, enter the number of hours quarantined files will be saved. Files
older than the specified number of hours are deleted.
5 Select OK.
Viewing quarantined files

The Quarantined Files list displays information about each quarantined file. You can sort
the files by file name, date, service, status, duplicate count (DC), or time to live (TTL). You
can also filter the list to view only quarantined files from a specific service.
To view quarantined files, go to Log&Report > Quarantined Files.
Downloading quarantined files

You can download any non-expired file from the quarantine. You may want to do so if it
was quarantined as the result of a false positive or if you want to examine the contents.
To download a quarantined file

1 Go to Log&Report > Quarantined Files.
2 In the quarantine file list, find the file you want to download.
To find the file more quickly, use the Sort by function to change the sort order. Available
sort criteria include status, services, file name, date, TTL, and duplicate count. You can
also use the Filter function to display the files quarantined from an individual traffic
type.
3 Select the Download icon to save a copy of the quarantined file on your computer.

772 01-420-99686-20101026
AntiVirus Enable file filtering
Enable file filtering

File filtering is a feature that allows you to block files based on their file name or their type.
• File patterns are a means of filtering based purely on the names of files. They may
include wildcards (*). For example, blocking *.scr will stop all files with an scr file
extension, which is commonly used for Windows screen saver files. Files trying to pass
themselves off as Windows screen saver files by adopting the file-naming convention
will also be stopped.
Files can specify the full or partial file name, the full or partial file extension, or any
combination. File pattern entries are not case sensitive. For example, adding *.exe to
the file pattern list also blocks any files ending with .EXE.
Files are compared to the enabled file patterns from top to bottom, in list order.
In addition to the built-in patterns, you can specify more file patterns to block. For
details, see “Creating a file filter list” on page 773.
• File types are a means of filtering based on an examination of the file contents,
regardless of the file name. If you were to block the file type Archive (zip), all zip
archives would be blocked even if they were renamed to have a different file extension.
The FortiGate examines the file contents to determine what type of file it is and then
acts accordingly.
The FortiGate unit can take either of the following actions toward the files that match a
configured file pattern or type:
• Block: the file will be blocked and a replacement messages will be sent to the user. If
both file pattern filtering and virus scan are enabled, the FortiGate unit blocks files that
match the enabled file filter and does not scan these files for viruses.
• Allow: the file will be allowed to pass.
The FortiGate unit also writes a message to the virus log and sends an alert email
message if configured to do so.
Note: File filter does not detect files within archives. You can use file filter to block or allow
the archives themselves, but not the contents of the archives.

The following steps provide an overview of the file filtering configuration. For best results,
follow the procedures in the order given. Also, note that if you perform any additional
actions between procedures, your configuration may have different results.
1 Create a file filter list.
2 Create one or more file patterns or file types to populate the file filter list.
3 Enable the file filter list by adding it to a firewall policy.
Creating a file filter list

Before your FortiGate unit can filter files by pattern or type, you must create a file filter list.
To create a file filter list

1 Go to UTM > AntiVirus > File Filter.
3 Enter a Name for the new file filter list.
4 Select OK.

01-420-99686-20101026 773
Enable file filtering AntiVirus
The new list is created and the edit file filter list window appears. The new list is empty.
You need to populate it with one or more file patterns or file types.
Creating a file pattern

A file pattern allows you to block or allow files based on the file name. File patterns are
created within file filter lists.
To create a file pattern

2 Select a file filter list.
5 Select File Name Pattern as the Filter Type.
6 Enter the pattern in the Pattern field. The file pattern can be an exact file name or can
include wildcards (*). The file pattern is limited to a maximum of 80 characters.
7 Select the action the FortiGate unit will take when it discovers a matching file: Allow or
Block.
8 The filter is enabled by default. Clear the Enable check box if you want to disable the
filter.
9 Select OK.
Creating a file type

A file type allows you to block or allow files based on the kind of file. File types are created
within file filter lists.
To create a file type

2 Select the Edit icon of the file filter list to which you will add the file type.
4 Select File Type as the Filter Type.
5 Select the kind of file from the File Type list.
6 Select the action the FortiGate unit will take when it discovers a matching file: Allow or
Block.
7 The filter is enabled by default. Clear the Enable check box if you want to disable the
filter.
8 Select OK.
Enabling file filtering in a profile

You need to add a file filter list to an antivirus profile to enable file filtering.
To enable file filtering

2 Select Create New to add an antivirus profile or select the Edit icon of an existing one
for which you want to enable file filtering.
3 In the row labeled File Filter, select the check boxes associated with the traffic you
want scanned for files.

774 01-420-99686-20101026
AntiVirus Enable grayware scanning
4 At the end of the File Filter row, select the file filter list containing the file types and
patterns that the FortiGate unit will scan.
5 Select OK.
You also need to add the antivirus profile to a firewall policy for all settings to take effect.
For more information, see “Adding the antivirus profile to a firewall policy” on page 768.
Enable grayware scanning

Grayware programs are unsolicited software programs installed on computers, often
without the user’s consent or knowledge. Grayware programs are generally considered an
annoyance, but they can also cause system performance problems or be used for
malicious purposes.
To allow the FortiGate unit to scan for known grayware programs, you must enable both
antivirus scanning and grayware detection. By default, grayware detection is disabled. To
enable antivirus scanning, see “Enable antivirus scanning” on page 766.
To enable grayware detection — web-based manager

To enable grayware detection — CLI

set grayware enable
end
With grayware detection enabled, the FortiGate unit will scan for grayware any time it
checks for viruses.
Testing your antivirus configuration

You have configured your FortiGate unit to stop viruses, but you’d like to confirm your
settings are correct. Even if you have a real virus, it would be dangerous to use for this
purpose. An incorrect configuration will allow the virus to infect your network.
To solve this problem, the European Institute of Computer Anti-virus Research has
developed a test file that allows you to test your antivirus configuration. The EICAR test
file is not a virus. It can not infect computers, nor can it spread or cause any damage. It’s a
very small file that contains a sequence of characters. Your FortiGate unit recognizes the
EICAR test file as a virus so you can safely test your FortiGate unit antivirus configuration.
Go to http://www.fortiguard.com/antivirus/eicartest.html to download the test file
(eicar.com) or the test file in a ZIP archive (eicar.zip).
If the antivirus profile applied to the firewall policy that allows you access to the Web is
configured to scan HTTP traffic for viruses, any attempt to download the test file will be
blocked. This indicates that you are protected.
Antivirus examples
The following examples provide a sample antivirus configuration scenario for a fictitious
company.

01-420-99686-20101026 775
Antivirus examples AntiVirus
Configuring simple antivirus protection

Small offices, whether they are small companies, home offices, or satellite offices, often
have very simple needs. This example details how to enable antivirus protection on a
FortiGate unit located in a satellite office. The satellite office does not have an internal
email server. To send and retrieve email, the employees connect to an external mail
server.
Creating an antivirus profile

Most antivirus settings are configured in an antivirus profile. Antivirus profiles are selected
in firewall policies. This way, you can create multiple antivirus profiles, and tailor them to
the traffic controlled by the firewall policy in which they are selected. In this example, you
will create one antivirus profile.
To create an antivirus profile — web-based manager

3 In the Name field, enter basic_antivirus.
4 In the Comments field, enter Antivirus protection for web and email
traffic.
5 Select the Virus Scan check boxes for the HTTP, IMAP, POP3, and SMTP traffic types.
6 Select OK to save the antivirus profile.
To create an antivirus profile — CLI

edit basic_antivirus
set comment "Antivirus protection for web and email traffic"
config http
set options scan
end
config imap
set options scan
end
config pop3
set options scan
end
config smtp
set options scan
end
end
Selecting the antivirus profile in a firewall policy

An antivirus profile directs the FortiGate unit to scan network traffic only when it is selected
in a firewall policy. When an antivirus profile is selected in a firewall policy, its settings are
applied to all the traffic the firewall policy handles.
To select the antivirus profile in a firewall policy — web-based manager

2 Select a policy.

776 01-420-99686-20101026
AntiVirus Antivirus examples
4 Enable UTM.
5 Select default from the Protocol Options list.
UTM can not be enabled without selecting a protocol options profile. A default profile is
provided.
6 Select the Enable AntiVirus option.
7 Select the basic_antivirus profile from the list.
To select the antivirus profile in a firewall policy — CLI

edit 1
set av-profile basic_antivirus
end
HTTP, IMAP, POP3, and SMTP traffic handled by the firewall policy you modified will be
scanned for viruses. A small office may have only one firewall policy configured. If you
have multiple policies, consider enabling antivirus scanning for all of them.
Protecting your network against malicious email attachments

Viruses and grayware are commonly delivered by email or the web. The Example.com
corporation has been the victim of multiple virus infections in the past. Now that the
company has a FortiGate unit protecting its network, you (Example.com’s system
administrator) can configure the unit to scan email and web traffic to filter out harmful
attachments. Example.com’s FortiGate unit supports SSL content scanning and
inspection.
Enabling antivirus scanning in the antivirus profile

The primary means to avoid viruses is to configure the FortiGate unit to scan email and
web traffic for virus signatures. You enable virus scanning in the antivirus profile and then
select the antivirus profile in firewall policies that control email traffic.
To enable antivirus scanning in the antivirus profile

2 Select Create New to add a new antivirus profile, or select the Edit icon of an existing
antivirus profile.
3 Select the Virus Scan check box for HTTP to scan web traffic for viruses.
4 Select the Virus Scan check box for IMAP, POP3, and SMTP to scan all email
protocols for viruses.
5 Select OK to save the antivirus profile.

01-420-99686-20101026 777
Enabling grayware scanning

Grayware can also threaten Example.com’s network. Viruses, email messages and the
web are often the means by which grayware infections are delivered.
To enable grayware scanning

3 Select Apply.
When Enable Grayware Detection is selected, virus scanning will also include
grayware scanning. Any traffic scanned for viruses will also be scanned for grayware.
Configuring and enabling file filtering

Executable files are never sent or received at Example.com. Since many executable files
attached to spam messages install malware or infect the system with viruses,
Example.com decided to stop all executable files attached to email messages by using file
filters.
Creating the file filtering list

3 Enter a name for the new file filter list.
4 Optionally, enter a descriptive comment for the list.
5 Select OK to save the new list.
6 Select Create New to add an entry to the file pattern list.
7 For Filter Type, select File Type.
8 For File Type, select Executable (exe).
9 For Action, select Block.
10 Select OK to save the new file filter list entry.
11 Select OK to save the file filter list.
With the file filter list created, you must now enable file filtering in the antivirus profile and
select the list.
Enabling file filter

2 Select the antivirus profile in which you already enabled virus scanning and choose
Edit.
3 Select the File Filter check box for IMAP, POP3, and SMTP to scan all email protocols
for viruses.
4 At the end of the File Filter row, select the file filter list you created.
5 Select OK.
To complete the example, you also need to add the antivirus profile to a firewall policy for
all settings to take effect.

778 01-420-99686-20101026
AntiVirus Antivirus examples

To select the antivirus profile in a firewall policy

2 Select the policy that controls the network traffic controlling email traffic.
4 Enable UTM.
provided.
6 Select the Enable AntiVirus option.
7 Select the antivirus profile from the list.

01-420-99686-20101026 779

780 01-420-99686-20101026
Email filter
This section describes how to configure FortiGate email filtering for IMAP, POP3, and
SMTP email. Email filtering includes both spam filtering and filtering for any words or files
you want to disallow in email messages. If your FortiGate unit supports SSL content
scanning and inspection, you can also configure spam filtering for IMAPS, POP3S, and
SMTPS email traffic.
• Email filter concepts
• Enable email filter
• Configure the spam action
• Configure the tag location
• Configure the tag format
• Email filter examples
Email filter concepts

You can configure the FortiGate unit to manage unsolicited commercial email by detecting
and identifying spam messages from known or suspected spam servers.
The FortiGuard Antispam Service uses both a sender IP reputation database and a spam
signature database, along with sophisticated spam filtering tools, to detect and block a
wide range of spam messages. Using FortiGuard Antispam email filter profile settings, you
can enable IP address checking, URL checking, email checksum checking, and spam
submission. Updates to the IP reputation and spam signature databases are provided
continuously via the global FortiGuard Distribution Network.
From the FortiGuard Antispam Service page in the FortiGuard Center, you can find out
whether an IP address is blacklisted in the FortiGuard antispam IP reputation database, or
whether a URL or email address is in the signature database.
Email filter techniques

The FortiGate unit has a number of techniques available to help detect spam. Some use
the FortiGuard Antispam Service and require a subscription. The remainder use your DNS
servers or use lists that you must maintain.
FortiGuard IP address check

The FortiGate unit queries the FortiGuard Antispam Service to determine if the IP address
of the client delivering the email is blacklisted. A match will cause the FortiGate unit to
treat delivered messages as spam.
The default setting of the smtp-spamhdrip CLI command is disable. If enabled, the
FortiGate unit will check all the IP addresses in the header of SMTP email against the
FortiGuard Antispam Service. For more information, see the FortiGate CLI Reference.

01-420-99686-20101026 781
Email filter concepts Email filter
FortiGuard URL check

The FortiGate unit queries the FortiGuard Antispam service to determine if any URL in the
message body is associated with spam. If any URL is blacklisted, the FortiGate unit
determines that the email message is spam.
FortiGuard email checksum check

The FortiGate unit sends a hash of an email to the FortiGuard Antispam server, which
compares the hash to hashes of known spam messages stored in the FortiGuard
Antispam database. If the hash results match, the email is flagged as spam.
FortiGuard spam submission

Spam submission is a way you can inform the FortiGuard AntiSpam service of non-spam
messages incorrectly marked as spam. When you enable this setting, the FortiGate unit
adds a link to the end of every message marked as spam. You then select this link to
inform the FortiGuard AntiSpam service when a message is incorrectly marked.
IP address black/white list check

The FortiGate unit compares the IP address of the client delivering the email to the
addresses in the IP address black/white list specified in the email filter profile. If a match is
found, the FortiGate unit will take the action configured for the matching black/white list
entry against all delivered email.
The default setting of the smtp-spamhdrip CLI command is disable. If enabled, the
FortiGate unit will check all the IP addresses in the header of SMTP email against the
specified IP address black/white list. For more information, see the FortiGate CLI
Reference.
HELO DNS lookup

The FortiGate unit takes the domain name specified by the client in the HELO greeting
sent when starting the SMTP session and does a DNS lookup to determine if the domain
exists. If the lookup fails, the FortiGate unit determines that any messages delivered
during the SMTP session are spam.
Email address black/white list check

The FortiGate unit compares the sender email address, as shown in the message
envelope MAIL FROM, to the addresses in the email address black/white list specified in
the email filter profile. If a match is found, the FortiGate unit will take the action configured
for the matching black/white list entry.
Return email DNS check

The FortiGate unit performs a DNS lookup on the reply-to domain to see if there is an A or
MX record. If no such record exists, the message is treated as spam.
Banned word check

The FortiGate unit blocks email messages based on matching the content of the message
with the words or patterns in the selected spam filter banned word list.
Order of spam filtering

The FortiGate unit checks for spam using various filtering techniques. The order in which
the FortiGate unit uses these filters depends on the mail protocol used.

782 01-420-99686-20101026
Email filter Enable email filter
Filters requiring a query to a server and a reply (FortiGuard Antispam Service and
DNSBL/ORDBL) are run simultaneously. To avoid delays, queries are sent while other
filters are running. The first reply to trigger a spam action takes effect as soon as the reply
is received.
Each spam filter passes the email to the next if no matches or problems are found. If the
action in the filter is Mark as Spam, the FortiGate unit tags the email as spam according to
the settings in the email filter profile.
For SMTP and SMTPS, if the action is discard, the email message is discarded or
dropped.
If the action in the filter is Mark as Clear, the email is exempt from any remaining filters. If
the action in the filter is Mark as Reject, the email session is dropped. Rejected SMTP or
SMTPS email messages are substituted with a configurable replacement message.
Order of SMTP and SMTPS spam filtering

The FortiGate unit scans SMTP and SMTPS email for spam in the order given below.
SMTPS spam filtering is available on FortiGate units that support SSL content scanning
and inspection.
1 IP address black/white list (BWL) check on last hop IP
2 DNSBL & ORDBL check on last hop IP, FortiGuard Antispam IP check on last hop IP,
HELO DNS lookup
3 MIME headers check, E-mail address BWL check
4 Banned word check on email subject
5 IP address BWL check (for IPs extracted from “Received” headers)
6 Banned word check on email body
7 Return email DNS check, FortiGuard Antispam email checksum check, FortiGuard
Antispam URL check, DNSBL & ORDBL check on public IP extracted from header.
Order of IMAP, POP3, IMAPS and POP3S spam filtering

The FortiGate unit scans IMAP, POP3, IMAPS and POP3S email for spam in the order
given below. IMAPS and POP3S spam filtering is available on FortiGate units that support
SSL content scanning and inspection.
1 MIME headers check, E-mail address BWL check
2 Banned word check on email subject
3 IP BWL check
4 Banned word check on email body
5 Return email DNS check, FortiGuard Antispam email checksum check, FortiGuard
Antispam URL check, DNSBL & ORDBL check.
Enable email filter

Unlike antivirus protection, no single control enables all email filtering. Your FortiGate unit
uses many techniques to detect spam; some may not be appropriate for every situation.
To enable any of the email filtering options, however, you must allow the FortiGate unit to
inspect email traffic.

01-420-99686-20101026 783
Enable email filter Email filter
To enable email traffic inspection

1 Go to UTM > Email Filter > Profile.
2 Select the email filter profile in which you want to enable email traffic inspection and
choose Edit.
3 The top row lists each type of email traffic the FortiGate unit is capable of inspecting.
Select the check box for the traffic types you want the FortiGate unit to inspect.
4 Select OK.
Once you allow the FortiGate unit to examine one or more types of email traffic, you can
enable any of the individual email filtering techniques.
Enabling FortiGuard IP address checking

When you enable FortiGuard IP address checking, your FortiGate unit will submit the IP
address of the client to the FortiGuard service for checking. If the IP address exists in the
FortiGuard IP address black list, your FortiGate unit will treat the message as spam.
To enable FortiGuard IP address checking

2 Select the email filter profile in which you want to enable FortiGuard IP address
checking and choose Edit.
3 Under the heading FortiGuard Email Filtering, the IP Address Check row has check
boxes for each email traffic type. Select the types of traffic you want scanned.
4 Select OK.
Select the edited email filter profile in a firewall policy, and the traffic controlled by the
firewall policy will be scanned according to the settings you configured. You may select the
email filter profile in more than one firewall policy if required.
Enabling FortiGuard URL checking

When you enable FortiGuard IP address checking, your FortiGate unit will submit all URLs
appearing in the email message body to the FortiGuard service for checking. If a URL
exists in the FortiGuard URL black list, your FortiGate unit will treat the message as spam.
To enable FortiGuard URL checking

2 Select the email filter profile in which you want to enable FortiGuard URL checking and
choose Edit.
3 Under the heading FortiGuard Email Filtering, the URL Check row has check boxes for
each email traffic type. Select the types of traffic you want scanned.
4 Select OK.
Enabling FortiGuard email checksum checking

When you enable FortiGuard email checksum checking, your FortiGate unit will submit a
checksum of each email message to the FortiGuard service for checking. If a checksum
exists in the FortiGuard checksum black list, your FortiGate unit will treat the message as
spam.

784 01-420-99686-20101026
To enable FortiGuard checksum checking

2 Select the email filter profile in which you want to enable FortiGuard checksum
3 Under the heading FortiGuard Email Filtering, the E-mail Checksum Check row has
check boxes for each email traffic type. Select the types of traffic you want scanned.
4 Select OK.
Enabling FortiGuard spam submission

When you enable FortiGuard email checksum checking, your FortiGate unit will append a
link to the end of every message detected as spam. This link allows email users to
“correct” the FortiGuard service by informing it that the message is not spam.
Note: Carefully consider the use of the Spam submission option on email leaving your
network. Users not familiar with the feature may click the link on spam messages because
they are curious. This will reduce the accuracy of the feature.
To enable FortiGuard Spam submission

2 Select the email filter profile in which you want to enable FortiGuard spam submission
and choose Edit.
3 Under the heading FortiGuard Email Filtering, the Spam Submission row has check
boxes for each email traffic type. Select the types of traffic you want processed.
4 Select OK.
Enabling IP address black/white list checking

When you enable IP address black/white list checking, your FortiGate unit will compare
the client IP address with the IP address black/white list specified in the email filter profile.
If the client IP address exists, the FortiGate unit acts according to the action configured for
the IP address in the list: allow the message, reject it, or mark it as spam.
The next two topics describe adding and configuring the IP address black/white list that
you will need before you can enable the checking. If you already have this list, go to
“Enabling the IP address black/white list checking” on page 786.
Creating an IP address black/white list

Before you can enable IP address black/white list spam filtering in the email filter profile,
you must create an IP address black/white list.
To create an IP address black/white list

1 Go to UTM > Email Filter > IP Address.
3 Enter a name for the IP address list.

01-420-99686-20101026 785
4 Optionally, enter a description or comments about the list.

5 Select OK to save the IP address black/white list.
When a new IP address back/white list is created, it is empty. To perform any actions, you
must add IP addresses to the list.
Adding addresses to an IP address black/white list

Each IP address black/white list contains a number of IP addresses, each having a
specified action. When the FortiGate unit accepts mail from a client with an IP address on
the IP address black/white list specified in the active email filter profile, it performs the
action specified for the address.
To add an address to an IP address black/white list

1 Go to UTM > Email Filter > IP Address.
2 Select the list to which you want to add an address and choose Edit.
4 Enter the address or netmask in the IP/netmask field.
5 Select the action:
• Mark as Clear: Messages from clients with matching IP addresses will be allowed,
bypassing further email filtering.
• Mark as Reject: Messages from clients with matching IP addresses will be rejected.
The FortiGate unit will return a reject message to the client. Mark as Reject only
applies to mail delivered by SMTP. If an IP address black/white list is used with
POP3 or IMAP mail, addresses configured with the Mark as Reject action will be
marked as spam.
• Mark as Spam: Messages from clients with matching IP addresses will be treated as
spam, subject to the action configured in the applicable email filter profile. For more
information, see “Configure the spam action” on page 792.
6 By default, the address is enabled and the FortiGate unit will perform the action if the
address is detected. To disable checking for the address, clear the Enable check box.
7 Select OK.
Enabling the IP address black/white list checking

Once you have created a black/white list and added the IP addresses, you can enable the
checking.
To enable IP address black/white list checking

2 Select the email filter profile in which you want to enable IP address black/white list
3 The IP Address BWL Check row has check boxes for each email traffic type. Select the
types of traffic you want scanned.
4 Select the IP address black/white list to use from the drop-down list at the end of the
row.
5 Select OK.

786 01-420-99686-20101026
Enabling HELO DNS lookup

Whenever a client opens an SMTP session with a server, the client sends a HELO
command with the client domain name. When you enable HELO DNS lookup, your
FortiGate unit will take the domain the client submits as part of the HELO greeting and
send it to the configured DNS. If the domain does not exist, your FortiGate unit will treat all
messages the client delivers as spam.
The HELO DNS lookup is available only for SMTP traffic.
To enable HELO DNS lookup

2 Select the Edit icon of the email filter profile in which you want to enable HELO DNS
lookup.
3 The HELO DNS Lookup row has a check box for the SMTP traffic type. Select the
check box to enable HELO DNS lookup.
4 Select OK.
Enabling email address black/white list checking

When you enable email address black/white list checking, your FortiGate unit will compare
the sender email address with the email address black/white list specified in the email filter
profile. If the sender email address exists, the FortiGate unit acts according to the action
configured for the email address in the list: allow the message or mark it as spam.
The next two topics describe adding and configuring the email address black/white list that
you will need before you can enable the checking. If you already have this list, go to
“Enabling email address black/white list checking” on page 788.
Creating an email address black/white list

Before you can enable email address black/white list spam filtering in the email filter
profile, you must create an email address black/white list.
To create an email address black/white list

1 Go to UTM > Email Filter > E-mail Address.
3 Enter a name for the email address list.
5 Select OK to save the email address black/white list.
When a new IP address back/white list is created, it is empty. To perform any actions, you
must add email addresses to the list.
Adding addresses to an email address black/white list

Each email address black/white list may contain a number of email addresses, each
having a specified action. When the FortiGate unit accepts an email message from a client
with a reply-to address that appears in the email address black/white list specified in the
active email filter profile, it performs the action specified for the email message.

01-420-99686-20101026 787
To add an address to an email address black/white list

2 Select the Edit icon of the list to which you want to add an address.
4 Enter the email address in the Email Address field.
5 If you need to enter a pattern in the Email Address field, select whether to use
wildcards or regular expressions to specify the pattern.
Wildcard uses an asterisk (“*”) to match any number of any character. For example,
*@example.com will match all addresses ending in @example.com.
Regular expressions use Perl regular expression syntax. See
http://perldoc.perl.org/perlretut.html for detailed information about using Perl regular
expressions.
6 Select the action:
• Mark as Spam: Messages with matching reply-to email addresses will be treated as
spam, subject to the action configured in the applicable email filter profile. For more
information, see “Configure the spam action” on page 792.
• Mark as Clear: Messages with matching reply-to addresses will be allowed,
bypassing further email filtering.
7 By default, the address is enabled and the FortiGate unit will perform the action if the
address is detected. To disable checking for the address, clear the Enable check box.
8 Select OK to save the address.
Enabling email address black/white list checking

Once you have created a black/white list and added the email addresses, you can enable
the checking.
To enable email address black/white list checking

2 Select the email filter profile in which you want to enable email address black/white list
3 The E-mail Address BWL Check row has check boxes for each email traffic type.
Select the types of traffic you want scanned.
4 Select the email address black/white list to use from the drop-down list at the end of
the row.
5 Select OK.
Enabling return email DNS checking

When you enable return email DNS checking, your FortiGate unit will take the domain in
the reply-to email address and send it to the configured DNS. If the domain does not exist,
your FortiGate unit will treat the message as spam.

788 01-420-99686-20101026
To enable return email DNS check

2 Select the email filter profile in which you want to enable return email DNS checking
and choose Edit.
3 The Return E-mail DNS Check row has check boxes for each email traffic type. Select
the types of traffic you want checked.
4 Select OK.
Enabling banned word checking

When you enable banned word checking, your FortiGate unit will examine the email
message for words appearing in the banned word list specified in the email filter profile. If
the total score of the banned word discovered in the email message exceeds the threshold
value set in the email filter profile, your FortiGate unit will treat the message as spam.
When determining the banned word score total for an email message, each banned word
score is added once no matter how many times the word appears in the message.
The next two topics describe adding and configuring the banned word list that you will
need before you can enable the checking. If you already have this list, go to “Enabling
banned word checking” on page 791.
How content is evaluated

Every time the banned word filter detects a pattern in an email message, it adds the
pattern score to the sum of scores for the message. You set this score when you create a
new pattern to block content. The score can be any number from zero to 99999. Higher
scores indicate more offensive content. When the total score equals or exceeds the
threshold, the email message is considered as spam and treated according to the spam
action configured in the email filter profile. The score for each pattern is counted only
once, even if that pattern appears many times in the email message. The default score for
banned word patterns is 10 and the default threshold is 10. This means that by default, an
email message is blocked by a single match.
A pattern can be part of a word, a whole word, or a phrase. Multiple words entered as a
pattern are treated as a phrase. The phrase must appear as entered to match. You can
also use wildcards or regular expressions to have a pattern match multiple words or
phrases.
For example, the FortiGate unit scans an email message that contains only this sentence:
“The score for each word or phrase is counted only once, even if that word or phrase
appears many times in the email message.”

01-420-99686-20101026 789
Score
added to
Banned word Pattern Assigned the sum
Comment
pattern type score for the
entire
page
word Wildcard 20 20 The pattern appears twice but multiple

occurrences are only counted once.
word phrase Wildcard 20 0 Although each word in the phrase

appears in the message, the words do
not appear together as they do in the
pattern. There are no matches.
word*phrase Wildcard 20 20 The wildcard represents any number of

any character. A match occurs as long
as “word” appears before “phrase”
regardless of what is in between them.
mail*age Wildcard 20 20 Since the wildcard character can

represent any characters, this pattern is
a match because “email message”
appears in the message.
In this example, the message is treated as spam if the banned word threshold is set to 60
or less.
Creating a banned word list

Before you can enable IP address black/white list spam filtering in the email filter profile,
you must create an IP address black/white list.
To create an IP address black/white list

1 Go to UTM > Email Filter > Banned Word.
3 Enter a name for the banned word list.
5 Select OK to save the banned word list.
When a new banned word list is created, it is empty. To perform any actions, you must add
words to the list.
Adding words to a banned word list

Each banned word list contains a number of words, each having a score, and specifying
whether the email FortiGate unit will search for the word in the message subject, message
body, or both.
When the FortiGate unit accepts an email message containing one or more words in the
banned word list specified in the active email filter profile, it totals the scores of the banned
words in the email message. If the total is higher than the threshold set in the email filter
profile, the email message will be detected as spam. If the total score is lower than the
threshold, the message will be allowed to pass as normal.
The score of a banned word present in the message will be counted toward the score total
only once, regardless of how many times the word appears in the message.

790 01-420-99686-20101026
To add words to a banned word list

1 Go to UTM > Email Filter > Banned Word.
2 Select the Edit icon of the list to which you want to add a word.
4 Enter the word or the pattern in the Pattern field.
5 In the Pattern Type field, select whether you use wildcards or regular expressions.
Wildcard uses an asterisk (“*”) to match any number of any character. For example, re*
will match all words starting with “re”.
Regular expression uses Perl regular expression syntax. See
http://perldoc.perl.org/perlretut.html for detailed information about using Perl regular
expressions.
6 In the Language field, select the language.
7 Select where the FortiGate unit will check for the banned word. The options are Body,
Subject, or All, which combines the other two options.
8 Enter a score. If the word appears in the message as determined by the Where setting,
the score is added to the scores of all the other banned words appearing in the email
message. If the score total is higher than the threshold set in the email filter profile, the
email message will be detected as spam. If the total score is lower than the threshold,
the message will be allowed to pass as normal.
9 By default, the banned word is enabled and will appear in the list. To disable checking
for the banned word, clear the Enable check box.
10 Select OK to save the banned word.
Enabling banned word checking

Once you have created a black/white list and added the email addresses, you can enable
the checking.
To enable banned word checking

2 Select the email filter profile in which you want to enable banned word checking and
choose Edit.
3 The Banned Word Check row has check boxes for each email traffic type. Select the
types of traffic you want scanned.
4 Select the banned word list to use from the drop-down list at the end of the row.
5 Enter a threshold value. If the total score of the banned words appearing in the
message exceeds this threshold, the FortiGate unit treats the message as spam.
6 Select OK.

01-420-99686-20101026 791
Configure the spam action Email filter
Configure the spam action

When spam is detected, the FortiGate unit will deal with it according to the Spam Action
setting in the email filter profile. Note that POP3S, IMAPS and SMTPS spam filtering is
available only on FortiGate units that support SSL content scanning and inspection.
POP3, IMAP, POP3S and IMAPS mail can only be tagged. SMTP and SMTPS mail can be
set to Discard or Tagged:
• Discard: When the spam action is set to Discard, messages detected as spam are
deleted. No notification is sent to the sender or recipient.
• Tagged: When the spam action is set to Tagged, messages detected as spam are
labelled and delivered normally. The text used for the label is set in the Tag Format
field and the label is placed in the subject or the message header, as set with the
Tag Location option.
To configure the spam action

2 Select the email filter profile in which you want to configure the spam action and
choose Edit.
3 The Spam Action row has a drop-down selection under the SMTP and SMTPS traffic
type. Select Discard or Tagged.
No selection is available for POP3, IMAP, POP3S or IMAPS traffic. Tagged is the only
applicable action for those traffic types.
By default, the tag location for any traffic set to Tagged is Subject and the tag format is
Spam. If you want to change these settings, continue with “Configure the tag location”
on page 792 and “Configure the tag format” on page 793.
4 Select OK.
Configure the tag location

When the spam action is set to Tagged, the Tag Location setting determines where the tag
is applied in the message.
To configure the tag location

2 Select the email filter profile in which you want to configure the tag location action and
choose Edit.
3 The Tag Location row has two options for SMTP traffic. Select the tag location:
• Subject: The FortiGate unit inserts the tag at the beginning of the message subject.
For example, if the message subject is “Buy stuff!” and the tag is “[spam]”, the new
message subject is “[spam] Buy stuff!” if the message is detected as spam.
• MIME: The FortiGate unit inserts the tag into the message header. With most mail
readers and web-based mail services, the tag will not be visible. Despite this, you
can still set up a rule based on the presence or absence of the tag.
4 Select OK.

792 01-420-99686-20101026
Email filter Configure the tag format
Configure the tag format

When the spam action is set to Tagged, the Tag Format setting determines what text is
used as the tag applied to the message.
To configure the tag format

2 Select the email filter profile in which you want to configure the tag format and choose
Edit.
3 The Tag Format row has a field for each traffic type. Enter the text the FortiGate unit
will use as the tag for each traffic type.
4 Select OK.
Email filter examples

Configuring simple antispam protection
have very simple needs. This example details how to enable antispam protection on a
FortiGate unit located in a satellite office.
Creating an email filter profile

Most email filter settings are configured in an email filter profile. Email filter profiles are
selected in firewall policies. This way, you can create multiple email filter profiles, and
tailor them to the traffic controlled by the firewall policy in which they are selected. In this
example, you will create one email filter profile.
To create an email filter profile — web-based manager

3 In the Name field, enter basic_emailfilter.
4 Ensure that IMAP, POP3, and SMTP are selected in the header row.
These header row selections enable or disable examination of each email traffic type.
When disabled, the email traffic of that type is ignored by the FortiGate unit and no
email filtering options are available.
5 Under FortiGuard Email Filtering, enable IP Address Check for the IMAP, POP3, and
SMTP email traffic types.
6 Under FortiGuard Email Filtering, enable URL Check for the IMAP, POP3, and SMTP
email traffic types.
7 Under FortiGuard Email Filtering, enable E-mail Checksum Check for the IMAP, POP3,
and SMTP email traffic types.
8 Select OK to save the email filter profile.

01-420-99686-20101026 793
Email filter examples Email filter
To create an email filter profile — CLI

config spamfilter profile
edit basic_emailfilter
config imap
set options spamfsip spamfsurl spamfschksum
end
config pop3
end
config smtp
end
end
Selecting the email filter profile in a firewall policy

An email filter profile directs the FortiGate unit to scan network traffic only when it is
selected in a firewall policy. When an email filter profile is selected in a firewall policy, its
settings are applied to all the traffic the firewall policy handles.
To select the email filter profile in a firewall policy — web-based manager

2 Select a policy.
4 Enable UTM.
provided.
6 Select the Enable Email Filter option.
7 Select the basic_emailfilter profile from the list.
To select the email filter profile in a firewall policy — CLI

edit 1
set spamfilter-profile basic_emailfilter
end
IMAP, POP3, and SMTP email traffic handled by the firewall policy you modified will be
scanned for spam. Spam messages have the text “Spam” added to their subject lines. A
small office may have only one firewall policy configured. If you have multiple policies,
consider enabling spam scanning for all of them.
Blocking email from a user

Employees of the Example.com corporation have been receiving unwanted email
messages from a former client at a company called example.net. All ties between the
company and the client have been severed, but the messages continue. The FortiGate
unit can be configured to prevent these messages from being delivered.

794 01-420-99686-20101026
Email filter Email filter examples
To create the email address list

3 Enter a name for the new email address list.
4 Optionally, enter a descriptive comment for the email address list.
5 Select OK to create the list.
6 Select Create New to add a new entry to the email address list.
7 Enter *@example.net in the E-mail Address field.
8 Leave Pattern Type set to the default, Wildcard.
9 Leave Action as Mark as Spam to have the FortiGate unit mark all messages from
example.net as spam.
Now that the email address list is created, you must enable the email filter in the email
filter profile.
To enable Email Filter

2 Select the email filter profile that is used by the firewall policies handling email traffic
and choose Edit.
3 Select the check boxes labeled IMAP, POP3, and SMTP in the table header row
immediately above the FortiGuard Email Filtering heading.
4 In the row E-mail Address BWL Check, select all three check boxes.
5 At the end of the E-mail address BWL check row, select the email address list you
created in the previous procedure.
6 In the row Tag Location, select Subject for all three mail protocols.
7 In the row Tag Format, enter SPAM: in all three fields.
8 Select OK.
With these changes, the FortiGate unit will add “SPAM:” to the subject of any email
message from an address ending with @example.net. Recipients can ignore the message
or they can configure their email clients to automatically delete messages with “SPAM:” in
the subject.

01-420-99686-20101026 795
Email filter examples Email filter

796 01-420-99686-20101026
Intrusion protection
The FortiGate Intrusion Protection system combines signature detection and prevention
with low latency and excellent reliability. With intrusion protection, you can create multiple
IPS sensors, each containing a complete configuration based on signatures. Then, you
can apply any IPS sensor to any firewall policy.
This section describes how to configure the FortiGate Intrusion Protection settings.
If you enable virtual domains (VDOMs) on the FortiGate unit, intrusion protection is
configured separately for each virtual domain.
The following topics are included:
• IPS concepts
• Enable IPS scanning
• Configure IPS options
• Enable IPS packet logging
• IPS examples
IPS concepts
The FortiGate intrusion protection system protects your network from outside attacks.
Your FortiGate unit has two techniques to deal with these attacks: anomaly- and
signature-based defense.
Anomaly-based defense
Anomaly-based defense is used when network traffic itself is used as a weapon. A host
can be flooded with far more traffic than it can handle, making the host inaccessible. The
most common example is the denial of service (DoS) attack, in which an attacker directs a
large number of computers to attempt normal access of the target system. If enough
access attempts are made, the target is overwhelmed and unable to service genuine
users. The attacker does not gain access to the target system, but it is not accessible to
anyone else.
The FortiGate DoS feature will block traffic above a certain threshold from the attacker and
allow connections from other legitimate users.
Signature-based defense
Signature-based defense is used against known attacks or vulnerability exploits. These
often involve an attacker attempting to gain access to your network. The attacker must
communicate with the host in an attempt to gain access and this communication will
include particular commands or sequences of commands and variables. The IPS
signatures include these command sequences, allowing the FortiGate unit to detect and
stop the attack.

01-420-99686-20101026 797
IPS concepts Intrusion protection
Signatures
IPS signatures are the basis of signature-based intrusion protection. Every attack can be
reduced to a particular string of commands or a sequence of commands and variables.
Signatures include this information so your FortiGate unit knows what to look for in
network traffic.
Signatures also include characteristics about the attack they describe. These
characteristics include the network protocol in which the attack will appear, the vulnerable
operating system, and the vulnerable application.
To view the complete list of predefined signatures, go to UTM > Intrusion Protection >
Predefined.
Protocol decoders
Before examining network traffic for attacks, the IPS engine uses protocol decoders to
identify each protocol appearing in the traffic. Attacks are protocol-specific, so your
FortiGate unit conserves resources by looking for attacks only in the protocols used to
transmit them. For example, the FortiGate unit will only examine HTTP traffic for the
presence of a signature describing an HTTP attack.
To view the protocol decoders, go to UTM > Intrusion Protection > Protocol Decoder.
IPS engine
Once the protocol decoders separate the network traffic by protocol, the IPS engine
examines the network traffic for the attack signatures.
IPS sensors
The IPS engine does not examine network traffic for all signatures, however. You must
first create an IPS sensor and specify which signatures are included. You do not have to
choose each signature you want to include individually. Instead, filters are used to define
the included signatures.
To view the IPS sensors, go to UTM > Intrusion Protection > IPS Sensor.
IPS filters
IPS sensors contain one or more IPS filters. A filter is a collection of signature attributes
that you specify. The signatures that have all of the attributes specified in a filter are
included in the IPS signature.
For example, if your FortiGate unit protects a Linux server running the Apache web server
software, you could create a new filter to protect it. By setting OS to Linux, and Application
to Apache, the filter will include only the signatures that apply to both Linux and Apache. If
you wanted to scan for all the Linux signatures and all the Apache signatures, you would
create two filters, one for each.
To view the filters in an IPS sensor, go to UTM > Intrusion Protection > IPS Sensor, select
the IPS sensor containing the filters you want to view, and choose Edit.
Policies
To use an IPS sensor, you must select it in a firewall policy or an interface policy. An IPS
sensor that it not selected in a policy will have no effect on network traffic.
IPS is most often configured as part of a firewall policy. Unless stated otherwise,
discussion of IPS sensor use will be in regards to firewall policies in this document.

798 01-420-99686-20101026
Intrusion protection Enable IPS scanning
Enable IPS scanning

Enabling IPS scanning involves two separate parts of the FortiGate unit:
• The firewall policy allows certain network traffic based on the sender, receiver,
interface, traffic type, and time of day. Firewall policies can also be used to deny traffic,
but those policies do not apply to IPS scanning.
• The IPS sensor contains filters, overrides, or both. These specify which signatures are
included in the IPS sensor.
When IPS is enabled, an IPS sensor is selected in a firewall policy, and all network traffic
matching the policy will be checked for the signatures in the IPS sensor.

For best results in configuring IPS scanning, follow the procedures in the order given.
Also, note that if you perform any additional actions between procedures, your
configuration may have different results.
1 Create an IPS sensor.
2 Create filters and/or overrides in the IPS sensor. The filters and overrides specify which
signatures the IPS engine will look for in the network traffic.
3 Select a firewall policy or create a new one.
4 In the firewall policy, enable UTM protection and select Enable IPS and select the IPS
sensor from the list.
All the network traffic controlled by this firewall policy will be processed according to the
settings in the policy. These settings include the IPS sensor you specify in the policy.
Creating an IPS sensor

You need to create an IPS sensor and save it before configuring it with filters and override
settings.
To create a new IPS sensor

3 Enter the name of the new IPS sensor.
4 Optionally, you can also enter a comment. The comment will appear in the IPS sensor
list and can remind you of the details of the sensor.
5 Select OK.
The IPS sensor is created and the sensor configuration window appears. A newly created
sensor is empty and contains no filters or overrides. You need to create one or more filters
or overrides before the sensor can take effect.
Creating an IPS filter

Filters determine which signatures are included in an IPS sensor. Rather than choosing
each signature, you choose the characteristics of the signatures you want included in the
IPS sensor by configuring a filter. You can create multiple filters in an IPS sensor.
To create a new IPS filter

2 Select the Edit icon of the IPS sensor to which you want to add the filter.

01-420-99686-20101026 799
Enable IPS scanning Intrusion protection
3 Select Add Filter.

4 Enter the name of the new filter.
5 Configure the filter that you require. Signatures matching all of the characteristics you
specify in the filter will be included in the IPS sensor.
6 Select OK.
The filter is created and added to the filter list. The number of signatures included in the
filter is listed in the Count column. You can view a list of the included signatures by
selecting the View Rules icon.
Note: Signature overrides are checked before filters.
Updating predefined IPS signatures

The FortiGuard Service periodically updates the pre-defined signatures and adds new
signatures to counter emerging threats as they appear.
Because the signatures included in filters are defined by specifying signature attributes,
new signatures matching existing filter specifications will automatically be included in
those filters. For example, if you have a filter that includes all signatures for the Windows
operating system, your filter will automatically incorporate new Windows signatures as
they are added.
Creating an IPS signature override

Pre-defined and custom signature overrides are configured and work largely the same as
filters, except they define the behavior of only one signature.
You can use overrides in two ways:
• To change the behavior of a signature already included in a filter.
For example, to protect a web server, you can create a filter that includes and enables
all signatures related to servers. If you want to disable one of those signatures, the
simplest way is to create an override and mark the signature as disabled.
• To add an individual signature, not included in any filters, to an IPS sensor. This is the
only way to add custom signatures to IPS sensors.
When a pre-defined signature is specified in an override, the default status and action
attributes of the signature are ignored. These settings must be explicitly set when creating
the override.
Note: Before an override can affect network traffic, you must add it to a filter, and you must
select the filter in a firewall policy. An override does not have the ability to affect network
traffic until these steps are taken. For more information, see “Enable IPS scanning” on
page 799.
To create an IPS signature override

2 Select the IPS sensor to which you want to add the override and select the Edit icon.
3 Select either Add Pre-defined Override or Add Custom Override, depending on the
type of IPS signature override you require.
4 For the Action, select Pass, Block, or Reset. When the override is enabled, the action
determines what the FortiGate will do with traffic containing the specified signature.
5 Select Logging to log all occurrences of the signature.

800 01-420-99686-20101026
6 Select Packet Log to save the packets containing the specified signature. For more
information, see “Enable IPS packet logging” on page 813.
7 Select the Browse icon and choose the signature to include in the override.
8 Select Enable.
9 Select OK.
Creating a custom IPS signature

The FortiGate predefined signatures cover common attacks. If you use an unusual or
specialized application or an uncommon platform, add custom signatures based on the
security alerts released by the application and platform vendors.
You can add or edit custom signatures using the web-based manager or the CLI.
To create a custom signature

1 Go to UTM > Intrusion Protection > Custom.
2 Select Create New to add a new custom signature.
3 Enter a Name for the custom signature.
4 Enter the Signature. For information about completing this field, see “Custom signature
syntax and keywords”.
5 Select OK.
Custom signature syntax and keywords

All custom signatures follow a particular syntax. Each begins with a header and is followed
by one or more keywords. The syntax and keywords are detailed in the next two topics.
Custom signature syntax

A custom signature definition is limited to a maximum length of 512 characters. A
definition can be a single line or span multiple lines connected by a backslash (\) at the
end of each line.
A custom signature definition begins with a header, followed by a set of keyword/value
pairs enclosed by parenthesis [( )]. The keyword and value pairs are separated by a semi
colon (;) and consist of a keyword and a value separated by a space. The basic format of
a definition is HEADER (KEYWORD VALUE;)
You can use as many keyword/value pairs as required within the 512 character limit. To
configure a custom signature, go to UTM > Intrusion Protection > Signature > Custom and
enter the data directly into the Signature field, following the guidance in the next topics.
Table 57 shows the valid characters and basic structure. For details about each keyword
and its associated values, see “Custom signature keywords” on page 802.

01-420-99686-20101026 801
Table 57: Valid syntax for custom signature fields
Field Valid Characters Usage

HEADER F-SBID The header for an attack definition
signature. Each custom signature
must begin with this header.
KEYWORD Each keyword must start with a pair of The keyword is used to identify a
dashes (--), and consist of a string of 1 to parameter. See “Custom signature
19 characters. keywords” on page 802 for tables of
Normally, keywords are an English word supported keywords.
or English words connected by an
underscore (_). Keywords are case
insensitive.
VALUE Double quotes (") must be used around The value is set specifically for a
the value if it contains a space and/or a parameter identified by a keyword.
semicolon (;).
If the value is NULL, the space between
the KEYWORD and VALUE can be
omitted.
Values are case sensitive.
Note: If double quotes are used for
quoting the value, the double quotes are
not considered as part of the value string.
Custom signature keywords

Table 58: Information keywords
Keyword and value Description

--attack_id <id_int>; Use this optional value to identify the signature. It cannot be the
same value as any other custom rules. If an attack ID is not
specified, the FortiGate automatically assigns an attack ID to the
signature. If you are using VDOMs, custom signatures appear only
in the VDOM in which you create them. You can use the same attack
ID for signatures in different VDOMs.
An attack ID you assign must be between 1000 and 9999.
Example:
--attack_id 1234;
--name <name_str>; Enter the name of the rule. A rule name must be unique. If you are
using VDOMs, custom signatures appear only in the VDOM in which
you create them. You can use the same rule name for signatures in
different VDOMs.
The name you assign must be a string greater than 0 and less than
64 characters in length.
Example:
--name "Buffer_Overflow";

802 01-420-99686-20101026
Table 59: Session keywords

--flow Specify the traffic direction and state to be inspected. They can
{from_client[,reversed] | be used for all IP traffic.
from_server[,reversed] | Example:
bi_direction }; --src_port 41523; --flow bi_direction;
The signature checks traffic to and from port 41523.
If you enable “quarantine attacker”, the optional reversed
keyword allows you to change the side of the connection to be
quarantined when the signature is detected.
For example, a custom signature written to detect a brute-force
log in attack is triggered when “Login Failed” is detected
from_server more than 10 times in 5 seconds. If the
attacker is quarantined, it is the server that is quarantined in
this instance. Adding reversed corrects this problem and
quarantines the actual attacker.
Previous FortiOS versions used to_client and to_server
values. These are now deprecated, but still function for
backwards compatibility.
--service {HTTP | Specify the protocol type to be inspected.
TELNET | FTP | DNS | This keyword allows you to specify the traffic type by protocol
SMTP | POP3 | IMAP | rather than by port. If the decoder has the capability to identify
SNMP | RADIUS | LDAP | the protocol on any port, the signature can be used to detect
the attack no matter what port the service is running on.
MSSQL | RPC | SIP | Currently, HTTP, SIP, SSL, and SSH protocols can be
H323 | NBSS | DCERPC | identified on any port based on the content.
SSH | SSL};
Table 60: Content keywords

--byte_jump Use the byte_jump option to extract a number of bytes from
<bytes_to_convert>, a packet, convert them to their numeric representation, and
<offset>[, relative] jump the match reference up that many bytes (for further
pattern matching or byte testing). This keyword allows
[, big] [, little] relative pattern matches to take into account numerical
[, string] [, hex] [, dec] values found in network data.
[, oct] [, align]; The available keyword options include:
• <bytes_to_convert>: The number of bytes to
examine from the packet.
• <offset>: The number of bytes into the payload to start
processing.
• relative: Use an offset relative to last pattern match.
• big: Process the data as big endian (default).
• little: Process the data as little endian.
• string: The data is a string in the packet.
• hex: The converted string data is represented in
hexadecimal notation.
• dec: The converted string data is represented in decimal
notation.
• oct: The converted string data is represented in octal
notation.
• align: Round up the number of converted bytes to the
next 32-bit boundary.

01-420-99686-20101026 803
Table 60: Content keywords (Continued)

--byte_test Use the byte_test keyword to compare a byte field against
<bytes_to_convert>, a specific value (with operator). This keyword is capable of
<operator>, <value>, testing binary values or converting representative byte
strings to their binary equivalent and testing them.
<offset>[, relative]
The available keyword options include:
[, big] [, little]
• <bytes_to_convert>: The number of bytes to
[, string] [, hex] [, dec] compare.
[, oct]; • <operator>: The operation to perform when comparing
the value (<,>,=,!,&).
• <value>: The value to compare the converted value
against.
• <offset>: The number of bytes into the payload to start
processing.
• relative: Use an offset relative to last pattern match.
• big: Process the data as big endian (default).
• little: Process the data as little endian.
• string: The data is a string in the packet.
• hex: The converted string data is represented in
hexadecimal notation.
• dec: The converted string data is represented in decimal
notation.
• oct: The converted string data is represented in octal
notation.
--depth <depth_int>; Use the depth keyword to search for the contents within the
specified number of bytes after the starting point defined by
the offset keyword. If no offset is specified, the offset
is assumed to be equal to 0.
If the value of the depth keyword is smaller than the length
of the value of the content keyword, this signature will
never be matched.
The depth must be between 0 and 65535.
--distance <dist_int>; Use the distance keyword to search for the contents within
the specified number of bytes relative to the end of the
previously matched contents. If the within keyword is not
specified, continue looking for a match until the end of the
payload.
The distance must be between 0 and 65535.
--content Deprecated, see pattern and context keywords.
[!]"<content_str>"; Use the content keyword to search for the content string in
the packet payload. The content string must be enclosed in
double quotes.
To have the FortiGate search for a packet that does not
contain the specified context string, add an exclamation mark
(!) before the content string.
Multiple content items can be specified in one rule. The value
can contain mixed text and binary data. The binary data is
generally enclosed within the pipe (|) character.
The double quote ("), pipe sign(|) and colon(:) characters
must be escaped using a back slash if specified in a content
string.
If the value of the content keyword is greater than the
length of the value of the depth keyword, this signature will
never be matched.

804 01-420-99686-20101026

--context {uri | header | Specify the protocol field to look for the pattern. If context is
body | host}; not specified for a pattern, the FortiGate unit searches for the
pattern anywhere in the packet buffer. The available context
variables are:
• uri: Search for the pattern in the HTTP URI line.
• header: Search for the pattern in HTTP header lines or
SMTP/POP3/SMTP control messages.
• body: Search for the pattern in HTTP body or
SMTP/POP3/SMTP email body.
• host: Search for the pattern in HTTP HOST line.
Example:
--pattern "GET "
--context uri
--pattern "yahoo.com"
--context host
--no_case
--pcre "/DESCRIBE\s+\/\s+RTSP\//i"
--context header
--no_case; Use the no-case keyword to force the FortiGate unit to
perform a case-insensitive pattern match.
--offset <offset_int>; Use the offset keyword to look for the contents after the
specified number of bytes into the payload. The specified
number of bytes is an absolute value in the payload. Follow
the offset keyword with the depth keyword to stop looking
for a match after a specified number of bytes. If no depth is
specified, the FortiGate unit continues looking for a match
until the end of the payload.
The offset must be between 0 and 65535.
--pattern The FortiGate unit will search for the specified pattern.
[!]"<pattern_str>"; A pattern keyword normally is followed by a context
keyword to define where to look for the pattern in the packet.
If a context keyword is not present, the FortiGate unit looks
for the pattern anywhere in the packet buffer.
contain the specified URI, add an exclamation mark (!)
before the URI.
Example:
--pattern "/level/"
--pattern "|E8 D9FF FFFF|/bin/sh"
--pattern !"|20|RTSP/"

01-420-99686-20101026 805

--pcre Similarly to the pattern keyword, use the pcre keyword to
[!]"(/<regex>/|m<delim><re specify a pattern using Perl-compatible regular expressions
gex><delim>)[ismxAEGRUB]"; (PCRE). A pcre keyword can be followed by a context
keyword to define where to look for the pattern in the packet.
If no context keyword is present, the FortiGate unit looks
for the pattern anywhere in the packet buffer.
For more information about PCRE syntax, go to
http://www.pcre.org.
The switches include:
• i: Case insensitive.
• s: Include newlines in the dot metacharacter.
• m: By default, the string is treated as one big line of
characters. ^ and $ match at the beginning and ending of
the string. When m is set, ^ and $ match immediately
following or immediately before any newline in the buffer,
as well as the very start and very end of the buffer.
• x: White space data characters in the pattern are ignored
except when escaped or inside a character class.
• A: The pattern must match only at the start of the buffer
(same as ^ ).
• E: Set $ to match only at the end of the subject string.
Without E, $ also matches immediately before the final
character if it is a newline (but not before any other
newlines).
• G: Invert the “greediness” of the quantifiers so that they
are not greedy by default, but become greedy if followed
by ?.
• R: Match relative to the end of the last pattern match.
(Similar to distance:0;).
• U: Deprecated, see the context keyword. Match the
decoded URI buffers.
--uri [!]"<uri_str>"; Deprecated, see pattern and context keywords.
Use the uri keyword to search for the URI in the packet
payload. The URI must be enclosed in double quotes (").
To have the FortiGate unit search for a packet that does not
contain the specified URI, add an exclamation mark (!)
before the URI.
Multiple content items can be specified in one rule. The value
can contain mixed text and binary data. The binary data is
generally enclosed within the pipe (|) character.
The double quote ("), pipe sign (|) and colon (:) characters
must be escaped using a back slash (\) if specified in a URI
string.
--within <within_int>; Use this together with the distance keyword to search for
the contents within the specified number of bytes of the
payload.
The within value must be between 0 and 65535.

806 01-420-99686-20101026
Table 61: IP header keywords
Keyword and Value Description

--dst_addr [!]<ipv4>; Use the dst_addr keyword to search for the destination IP
address.
contain the specified address, add an exclamation mark (!)
before the IP address.
You can define up to 28 IP addresses or CIDR blocks.
Enclose the comma separated list in square brackets.
Example: dst_addr [172.20.0.0/16,
10.1.0.0/16,192.168.0.0/16]
--ip_id <field_int>; Check the IP ID field for the specified value.
--ip_option {rr | eol | nop Use the ip_option keyword to check various IP option
| ts | sec | lsrr | ssrr | settings. The available options include:
satid | any}; • rr: Check if IP RR (record route) option is present.
• eol: Check if IP EOL (end of list) option is present.
• nop: Check if IP NOP (no op) option is present.
• ts: Check if IP TS (time stamp) option is present.
• sec: Check if IP SEC (IP security) option is present.
• lsrr: Check if IP LSRR (loose source routing) option is
present.
• ssrr: Check if IP SSRR (strict source routing) option is
present.
• satid: Check if IP SATID (stream identifier) option is
present.
• any: Check if IP any option is present.
--ip_tos <field_int>; Check the IP TOS field for the specified value.
--ip_ttl [< | >] <ttl_int>; Check the IP time-to-live value against the specified value.
Optionally, you can check for an IP time-to-live greater-than
(>) or less-than (<) the specified value with the appropriate
symbol.
--protocol Check the IP protocol header.
{<protocol_int> | tcp | Example:
udp | icmp}; --protocol tcp;
--src_addr [!]<ipv4>; Use the src_addr keyword to search for the source IP
address.
To have the FortiGate unit search for a packet that does not
contain the specified address, add an exclamation mark (!)
before the IP address.
You can define up to 28 IP addresses or CIDR blocks.
Enclose the comma separated list in square brackets.
Example: src_addr 192.168.13.0/24

01-420-99686-20101026 807
Table 62: TCP header keywords

--ack <ack_int>; Check for the specified TCP acknowledge number.
--dst_port [!]{<port_int> | Use the dst_port keyword to specify the destination port
:<port_int> | <port_int>: | number.
<port_int>:<port_int>}; You can specify a single port or port range:
• <port_int> is a single port.
• :<port_int> includes the specified port and all lower
numbered ports.
• <port_int>: includes the specified port and all
higher numbered ports.
• <port_int>:<port_int> includes the two specified
ports and all ports in between.
--seq <seq_int>; Check for the specified TCP sequence number.
--src_port [!]{<port_int> | Use the src_port keyword to specify the source port
:<port_int> | <port_int>: | number.
<port_int>:<port_int>}; You can specify a single port or port range:
• <port_int> is a single port.
numbered ports.
--tcp_flags Specify the TCP flags to match in a packet.
<SAFRUP120>[!|*|+] • S: Match the SYN flag.
[,<SAFRUP120>]; • A: Match the ACK flag.
• F: Match the FIN flag.
• R: Match the RST flag.
• U: Match the URG flag.
• P: Match the PSH flag.
• 1: Match Reserved bit 1.
• 2: Match Reserved bit 2.
• 0: Match No TCP flags set.
• !: Match if the specified bits are not set.
• *: Match if any of the specified bits are set.
• +: Match on the specified bits, plus any others.
The first part if the value (<SAFRUP120>) defines the bits
that must be present for a successful match. For example:
--tcp_flags AP
only matches the case where both A and P bits are set.
The second part ([,<SAFRUP120>]) is optional, and
defines the additional bits that can be present for a match.
For example:
tcp_flags S,12
matches the following combinations of flags: S, S and 1, S
and 2, S and 1 and 2.
The modifiers !, * and + cannot be used in the second
part.
--window_size Check for the specified TCP window size.
[!]<window_int>; You can specify the window size as a hexadecimal or
decimal integer. A hexadecimal value must be preceded
by 0x.
To have the FortiGate search for the absence of the
specified window size, add an exclamation mark (!) before
the window size.

808 01-420-99686-20101026
Table 63: UDP header keywords

--dst_port [!]{<port_int> | Specify the destination port number.
:<port_int> | <port_int>: | You can specify a single port or port range:
<port_int>:<port_int>}; • <port_int> is a single port.
numbered ports.
--src_port [!]{<port_int> | Specify the source port number.
:<port_int> | <port_int>: | You can specify a single port or port range:
<port_int>:<port_int>}; • <port_int> is a single port.
numbered ports.
Table 64: ICMP keywords

Keyword and Value Usage
--icmp_code <code_int>; Specify the ICMP code to match.
--icmp_id <id_int>; Check for the specified ICMP ID value.
--icmp_seq <seq_int>; Check for the specified ICMP sequence value.
--icmp_type <type_int>; Specify the ICMP type to match.
Table 65: Other keywords

--data_size {<size_int> | Test the packet payload size. With data_size
<<size_int> | ><size_int> | specified, packet reassembly is turned off
<port_int><><port_int>}; automatically. So a signature with data_size and
only_stream values set is wrong.
• <size_int> is a particular packet size.
• <<size_int> is a packet smaller than the
specified size.
• ><size_int> is a packet larger than the
specified size.
• <size_int><><size_int> is a packet within
the range between the specified sizes.
--data_at <offset_int>[, Verify that the payload has data at a specified offset,
relative]; optionally looking for data relative to the end of the
previous content match.

01-420-99686-20101026 809
IPS processing in an HA cluster Intrusion protection
Table 65: Other keywords (Continued)

--rate <matches_int>,<time_int>; Instead of generating log entries every time the
signature is detected, use this keyword to generate
a log entry only if the signature is detected a
specified number of times within a specified time
period.
• <matches_int> is the number of times a
signature must be detected.
• <time_int> is the length of time in which the
signature must be detected, in seconds.
For example, if a custom signature detects a pattern,
a log entry will be created every time the signature is
detected. If --rate 100,10; is added to the
signature, a log entry will be created if the signature
is detected 100 times in the previous 10 seconds.
Use this command with --track to further limit log
entries to when the specified number of detections
occur within a certain time period involving the same
source or destination address rather than all
addresses.
--rpc_num <app_int>[, Check for RPC application, version, and procedure
<ver_int> | *][, numbers in SUNRPC CALL requests. The *
<proc_int> | *>]; wildcard can be used for version and procedure
numbers.
--same_ip; Check that the source and the destination have the
same IP addresses.
--track {src_ip | dst_ip | When used with --rate, this keyword narrows the
dhcp_client }; custom signature rate totals to individual addresses.
• src_ip has the FortiGate unit maintain a
separate count of signature matches for each
source address.
• dst_ip has the FortiGate unit maintain a
destination address.
• dhcp_client has the FortiGate unit maintain a
DHCP client.
For example, if --rate 100,10 is added to the
signature, a log entry will be created if the signature
is detected 100 times in the previous 10 seconds.
The FortiGate unit maintains a single total,
regardless of source and destination address.
If the same custom signature also includes
--track src_ip; matches are totalled separately
for each source address. A log entry is added when
the signature is detected 100 times in 10 seconds
within traffic from the same source address.
Use of the --track keyword is invalid without the
--rate keyword. The --rate keyword can be
used without --track, however.
IPS processing in an HA cluster

IPS processing in an HA cluster is no different than with a single FortiGate unit, from the
point of view of the network user. The difference appears when a secondary unit takes
over from the primary, and what happens depends on the HA mode.

810 01-420-99686-20101026
Intrusion protection Configure IPS options
Active-passive
In an active-passive HA cluster, the primary unit processes all traffic just as it would in a
stand-alone configuration. Should the primary unit fail, a secondary unit will assume the
role of the primary unit and begin to process network traffic. By default, the state of active
communication sessions are not shared with secondary units and will not survive the fail-
over condition. Once the sessions are reestablished however, traffic processing will
continue as normal.
If your network requires that active sessions are taken over by the new primary unit, select
Enable Session Pick-up in your HA configuration. Because session information must be
sent to all subordinate units on a regular basis, session pick-up is a resource-intensive
feature and is not enabled by default.
Active-active
The fail-over process in an active-active cluster is similar to an active-passive cluster.
When the primary unit fails, a secondary unit takes over and traffic processing continues.
The load-balancing schedule used to distribute sessions to the cluster members is used
by the new primary unit to redistribute sessions among the remaining subordinate units. If
session pick-up is not enabled, the sessions active on the failed primary are lost, and the
sessions redistributed among the secondary units may also be lost. If session pick-up is
enabled, all sessions are handled according to their last-known state.
For more information about HA options and settings, see “High Availability” on page 1533.
Configure IPS options

There are a number of CLI commands that influence how IPS functions.
Configuring the IPS engine algorithm

The IPS engine is able to search for signature matches in two ways. One method is faster
but uses more memory, the other uses less memory but is slower. Use the algorithm
CLI command to select one method:
config ips global
set algorithm {high | low | engine-pick}
end
Specify high to use the faster more memory intensive method or low for the slower
memory efficient method. The default setting is engine-pick, which allows the IPS
engine to choose the best method on the fly.
Configuring the IPS engine-count

FortiGate units with multiple processors can run more than one IPS engine concurrently.
The engine-count CLI command allows you to specify how many IPS engines are used
at the same time:
config ips global
set engine-count <int>
end
The recommended and default setting is 0, which allows the FortiGate unit to determine
the optimum number of IPS engines.

01-420-99686-20101026 811
Configure IPS options Intrusion protection
Configuring fail-open
If the IPS engine fails for any reason, it will fail open by default. This means that traffic
continues to flow without IPS scanning. If IPS protection is more important to your network
than the uninterrupted flow if network traffic, you can disable this behavior using the
fail-open CLI command:
config ips global
set fail-open {enable | disable}
end
The default setting is enable.
Configuring the session count accuracy

The IPS engine can keep track of the number of open session in two ways. An accurate
count uses more resources than a less accurate heuristic count.
config ips global
set session-limit-mode {accurate | heuristic}
end
The default is heuristic.
Configuring the IPS buffer size

Set the size of the IPS buffer.
config ips global
set socket-size <int>
end
The acceptable range is from 1 to 64 megabytes. The default size varies by model.
Configuring protocol decoders

The FortiGate Intrusion Protection system uses protocol decoders to identify the abnormal
traffic patterns that do not meet the protocol requirements and standards. For example,
the HTTP decoder monitors traffic to identify any HTTP packets that do not meet the
HTTP protocol standards.
To view the decoders and the port numbers that each protocol decoder monitors, go to
UTM > Intrusion Protection > Protocol Decoder. The port or ports monitored by each
decoder are listed. Many decoders are able to recognize traffic by type rather than by port.
These decoders have their port listed as auto because the traffic will be recognized
automatically, regardless of the port.
To change the ports a decoder examines, you must use the CLI. In this example, the ports
examined by the DNS decoder are changed from the default 53 to 100, 200, and 300.
config ips decoder dns_decoder
set port_list "100,200,300"
end
You cannot assign specific ports to decoders that are set to auto by default. These
decoders can detect their traffic on any port. Specifying individual ports is not necessary.

812 01-420-99686-20101026
Intrusion protection Enable IPS packet logging
Configuring security processing modules

FortiGate Security Processing Modules, such as the CE4, XE2, and FE8, can increase
overall system performance by accelerating some security and networking processing on
the interfaces they provide. They also allow the FortiGate unit to offload the processing to
the security module, thereby freeing up its own processor for other tasks. The security
module performs its own IPS and firewall processing, but you can configure it to favor IPS
in hostile high-traffic environments.
If you have a security processing module, use the following CLI commands to configure it
to devote more resources to IPS than firewall. This example shows the CLI commands
required to configure a security module in slot 1 for increased IPS performance.
config system amc-slot
edit sw1
set optimization-mode fw-ips
set ips-weight balanced
set ips-p2p disable
set ips-fail-open enable
set fp-disable none
set ipsec-inb-optimization enable
set syn-proxy-client-timer 3
set syn-proxy-server-timer 3
end
In addition to offloading IPS processing, security processing modules provide a hardware
accelerated SYN proxy to defend against SYN flood denial of service attacks. When using
a security module, configure your DoS sensor tcp_syn_flood anomaly with the Proxy
action. The Proxy action activates the hardware accelerated SYN proxy.
Note: Because DoS sensors are configured before being applied to an interface, you can
assign a DoS sensor with the Proxy action to an interface that does not have hardware
SYN proxy support. In this circumstance, the Proxy action is invalid and a Pass action will
be applied.
Enable IPS packet logging

Packet logging saves the network packets containing the traffic matching an IPS signature
to the attack log. The FortiGate unit will save the logged packets to wherever the logs are
configured to be stored, whether memory, internal hard drive, a FortiAnalyzer unit, or the
FortiGuard Analysis and Management Service.
You can enable packet logging only in signature overrides or in filters. Use caution in
enabling packet logging in a filter. Filters configured with few restrictions can contain
thousands of signatures, potentially resulting in a flood of saved packets. This would take
up a great deal of space, require time to sort through, and consume considerable system
resources to process. Packet logging is designed as a focused diagnostic tool and is best
used with a narrow scope.
Caution: Although logging to multiple FortiAnalyzer units is supported, packet logs are not
sent to the secondary and tertiary FortiAnalyzer units. Only the primary unit receives packet
logs.

01-420-99686-20101026 813
IPS examples Intrusion protection
To enable packet logging for a signature

1 Create either a pre-defined override or a custom override in an IPS sensor. For more
information, see “Creating an IPS signature override” on page 800.
2 Before saving the override, select Packet Log.
3 Select the IPS sensor in the firewall policy that allows the network traffic the FortiGate
unit will examine for the signature.
To enable packet logging for a filter

1 Create a filter in an IPS sensor. For more information, see “Creating an IPS filter” on
page 799.
2 Before saving the filter, select Enable All for Packet Logging.
3 Select the IPS sensor in the firewall policy that allows the network traffic the FortiGate
unit will examine for the signature.
For information on viewing and saving logged packets, see “Viewing and saving logged
packets” on page 745.
IPS examples
Configuring basic IPS protection
have very simple needs. This example details how to enable IPS protection on a FortiGate
unit located in a satellite office. The satellite office contains only Windows clients.

Most IPS settings are configured in an IPS sensor. IPS sensors are selected in firewall
policies. This way, you can create multiple IPS sensors, and tailor them to the traffic
controlled by the firewall policy in which they are selected. In this example, you will create
one IPS sensor.
To create an IPS sensor— web-based manager

3 In the Name field, enter basic_ips.
4 In the Comments field, enter IPS protection for Windows clients.
5 Select OK.
6 In the Filters section, select Create New.
7 In the Name field, enter windows_clients.
8 For Target, select Specify and Client.
9 For OS, select Specify and Windows.
10 Select OK to save the filter.
11 Select OK to save the IPS sensor.

814 01-420-99686-20101026
Intrusion protection IPS examples
To create an IPS sensor — CLI

config ips sensor
edit basic_ips
set comment "IPS protection for Windows clients"
config filter
edit windows_clients
set location client
set os windows
end
end

To select the IPS sensor in a firewall policy — web-based manager

2 Select a policy.
4 Enable UTM.
5 Select the Enable IPS option.
6 Select the basic_ips profile from the list.

edit 1
set ips-sensor basic_ips
end
All traffic handled by the firewall policy you modified will be scanned for attacks against
Windows clients. A small office may have only one firewall policy configured. If you have
multiple policies, consider enabling antivirus scanning for all of them.
Using IPS to protect your web server

Many companies have web servers and they must be protected from attack. Since web
servers must be accessible, protection is not as simple as blocking access. IPS is one tool
your FortiGate unit has to allow you to protect your network.
In this example, we will configure IPS to protect a web server. As shown in Figure 69 on
page 816, a FortiGate unit protects a web server and an internal network. The internal
network will have its own policies and configuration but we will concentrate on the web
server in this example.

01-420-99686-20101026 815
Figure 69: A simple network configuration
Internal Network
Po
rt 1
Po
rt 2
Ex
ter
na
l
Main Firewall
Web Server
The FortiGate unit is configured with:

• a virtual IP to give the web server a unique address accessible from the Internet.
• a firewall policy to allow access to the web server from the Internet using the virtual IP.
To protect the web server using intrusion protection, you need to create an IPS sensor,
populate it with filters, then enable IPS scanning in the firewall policy.
To create an IPS sensor

1 Go to UTM > Intrusion Protection > IPS Sensor and select Create New.
2 Enter web_server as the name of the new IPS sensor.
3 Select OK.
The new IPS sensor is created but it has no filters, and therefore no signatures are
included.
The web server operating system is Linux, so you need to create a filter for all Linux server
signatures.
To create the Linux server filter

1 Go to UTM > Intrusion Protection > IPS Sensor and select the web_server IPS
sensor and select the Edit icon.
3 Enter Linux Server as the name of the new filter.
4 For Target, select Specify and choose server.
5 For OS, select Specify and choose Linux.
6 Select OK.

816 01-420-99686-20101026
The filter is saved and the IPS sensor page reappears. In the filter list, find the Linux
Server filter and look at the value in the Count column. This shows how many signatures
match the current filter settings. You can select the View Rules icon to see a listing of the
included signatures.
The web server software is Apache, so you need to create a second filter for all Apache
signatures.
To create the Apache filter

1 Go to UTM > Intrusion Protection > IPS Sensor and select the web_server IPS
sensor and select the Edit icon.
3 Enter Apache as the name of the new filter.
4 For Application, select Specify and choose Apache from the Available list.
5 Select the right-arrow to move Apache to the Selected list.
6 Select OK.
The filter is saved and the IPS sensor page reappears.
It might seem that you can skip a step and create one filter that specifies both Linux server
and Apache signatures. However, this would include a smaller number of filters. It would
not include signatures to detect attacks against the operating system directly, for example.
You have created the IPS sensor and the two filters that include the signatures you need.
To have it start scanning traffic, you must edit the firewall policy.
To edit the firewall policy

1 Go to Firewall > Policy > Policy, select firewall policy that allows access to the web
server, and select the Edit icon.
2 Enable UTM.
3 Select the Enable IPS option and choose the web_server IPS sensor from the list.
4 Select OK.
Since IPS is enabled and the web_server IPS sensor is specified in the firewall policy
controlling the web server traffic, the IPS sensor examines the web server traffic for
matches to the signatures it contains.
Create and test a packet logging IPS sensor

In this example, you create a new IPS sensor and include a filter that detects the EICAR
test file and saves a packet log when it is found. This is an ideal first experience with
packet logging because the EICAR test file can cause no harm, and it is freely available
for testing purposes.
Create an IPS senor

3 Name the new IPS sensor EICAR test.
4 Select OK.
Create an Override
1 Select Add Pre-defined Override.
2 Select the signature browse icon.

01-420-99686-20101026 817
3 Rather than search through the signature list, use the name filter by selecting the filter
icon in the header of the Name column.
4 In the Filters list, select Name.
5 Select Enable.
6 In the Field selection, choose Contains.
7 Enter EICAR in the Text field.
8 Select OK.
9 Select the EICAR.AV.Test.File.Download signature.
10 Select OK.
11 Select Enable, Logging, and Packet Log.
12 Select OK.
13 Select Block as the Action.
You are returned to the IPS sensor list. The EICAR test sensor appears in the list.
Add the IPS sensor to the firewall policy allowing Internet access
2 Select the firewall policy that allows you to access the Internet.
4 Enable Log Allowed Traffic.
5 Enable UTM.
6 Select Enable IPS.
7 Choose EICAR test from the available IPS sensors.
8 Select OK.
With the IPS sensor configured and selected in the firewall policy, the FortiGate unit
should block any attempt to download the EICAR test file.
Test the IPS sensor

1 Using your web browser, go to http://www.eicar.org/anti_virus_test_file.htm.
2 Scroll to the bottom of the page and select eicar.com from the row labeled as using the
standard HTTP protocol.
3 The browser attempts to download the requested file and,
• If the file is successfully downloaded, the custom signature configuration failed at
some point. Check the custom signature, the IPS sensor, and the firewall profile.
• If the download is blocked with a high security alert message explaining that you’re
not permitted to download the file, the EICAR test file was blocked by the FortiGate
unit antivirus scanner before the IPS sensor could examine it. Disable antivirus
scanning and try to download the EICAR test file again.
• If no file is downloaded and the browser eventually times out, the custom signature
successfully detected the EICAR test file and blocked the download.

818 01-420-99686-20101026
Viewing the packet log

1 Go to Log&Report > Log Access > Attack.
2 Locate the log entry that recorded the blocking of the EICAR test file block. The
Message field data will be tools: EICAR.AV.Test.File.Download.
3 Select the View Packet Log icon in the Packet Log column.
4 The packet log viewer is displayed.
Creating a custom signature to block access to example.com

In this first example, you will create a custom signature to block access to the
example.com URL.
This example describes the use of the custom signature syntax to block access to a URL.
To create the custom signature entry in the FortiGate unit web-based manager, see
“Creating a custom IPS signature” on page 801.
1 Enter the custom signature basic format
All custom signatures have a header and at least one keyword/value pair. The header
is always the same:
F-SBID( )
The keyword/value pairs appear within the parentheses and each pair is followed by a
semicolon.
2 Choose a name for the custom signature
Every custom signature requires a name, so it is a good practice to assign a name
before adding any other keywords.
Use the --name keyword to assign the custom signature a name. The name value
follows the keyword after a space. Enclose the name value in double-quotes:
F-SBID( --name "Block.example.com"; )
The signature, as it appears here, will not do anything if you try to use it. It has a name,
but does not look for any patterns in network traffic. You must specify a pattern that the
FortiGate unit will search for.
3 Add a signature pattern
Use the --pattern keyword to specify what the FortiGate unit will search for:
F-SBID( --name "Block.example.com"; --pattern "example.com"; )
The signature will now detect the example.com URL appearing in network traffic. The
custom signature should only detect the URL in HTTP traffic, however. Any other traffic
with the URL should be allowed to pass. For example, an email message to or from
example.com should not be stopped.
4 Specify the service
Use the --service keyword to limit the effect of the custom signature to only the
HTTP protocol.
F-SBID( --name "Block.example.com"; --pattern "example.com";
--service HTTP; )
The FortiGate unit will limit its search for the pattern to the HTTP protocol. Even though
the HTTP protocol uses only TCP traffic, the FortiGate will search for HTTP protocol
communication in TCP, UDP, and ICMP traffic. This is a waste of system resources that
you can avoid by limiting the search further, as shown below.

01-420-99686-20101026 819
5 Specify the traffic type.

Use the --protocol tcp keyword to limit the effect of the custom signature to only
TCP traffic. This will save system resources by not unnecessarily scanning UDP and
ICMP traffic.
--service HTTP; --protocol tcp; )
The FortiGate unit will limit its search for the pattern to TCP traffic and ignore UDP and
ICMP network traffic.
6 Ignore case sensitivity
By default, patterns are case sensitive. If a user directed his or her browser to
Example.com, the custom signature would not recognize the URL as a match.
Use the --no_case keyword to make the pattern matching case insensitive.
--service HTTP; --no_case; )
Unlike all of the other keywords in this example, the --no_case keyword has no
value. Only the keyword is required.
7 Limit pattern scans to only traffic sent from the client
The --flow command can be used to further limit the network traffic being scanned
to only that send by the client or by the server.
--service HTTP; --no_case; --flow from_client; )
Web servers do not contact clients until clients first open a communication session.
Therefore, using the --flow from_client command will force the FortiGate to
ignore all traffic from the server. Since the majority of HTTP traffic flows from the server
to the client, this will save considerable system resources and still maintain protection.
8 Specify the context
When the client browser tries to contact example.com, a DNS is first consulted to get
the example.com server IP address. The IP address is then specified in the URL field
of the HTTP communication. The domain name will still appear in the host field, so this
custom signature will not function without the --context host keyword/value pair.
--service HTTP; --no_case; --flow from_client;
--context host; )
Creating a custom signature to block the SMTP “vrfy” command

The SMTP “vrfy” command can be used to verify the existence of a single email address
or to list all of the valid email accounts on an email server. A spammer could potentially
use this command to obtain a list of all valid email users and direct spam to their inboxes.
In this example, you will create a custom signature to block the use of the vrfy command.
Since the custom signature blocks the vrfy command from coming through the FortiGate
unit, the administrator can still use the command on the internal network.
This example describes the use of the custom signature syntax to block the vrfy
command. To create the custom signature entry in the FortiGate unit web-based manager,
see “Creating a custom IPS signature” on page 801.

820 01-420-99686-20101026
1 Enter the custom signature basic format

All custom signatures have a header and at least one keyword/value pair. The header
is always the same:
F-SBID( )
The keyword/value pairs appear within the parentheses and each pair is followed by a
semicolon.
2 Choose a name for the custom signature
Every custom signature requires a name, so it is a good practice to assign a name
before you add any other keywords.
Use the --name keyword to assign the custom signature a name. The name value
follows the keyword after a space. Enclose the name value in double-quotes:
F-SBID( --name "Block.SMTP.VRFY.CMD"; )
The signature, as it appears here, will not do anything if you try to use it. It has a name,
but does not look for any patterns in network traffic. You must specify a pattern that the
FortiGate unit will search for.
3 Add a signature pattern
Use the --pattern keyword to specify what the FortiGate unit will search for:
F-SBID( --name "Block.SMTP.VRFY.CMD"; --pattern "vrfy"; )
The signature will now detect the vrfy command appearing in network traffic. The
custom signature should only detect the command in SMTP traffic, however. Any other
traffic with the pattern should be allowed to pass. For example, an email message
discussing the vrfy command should not be stopped.
4 Specify the service
Use the --service keyword to limit the effect of the custom signature to only the
HTTP protocol.
F-SBID( --name "Block.SMTP.VRFY.CMD"; --pattern "vrfy";
--service SMTP; )
The FortiGate unit will limit its search for the pattern to the SMTP protocol.
Even though the SMTP protocol uses only TCP traffic, the FortiGate will search for
SMTP protocol communication in TCP, UDP, and ICMP traffic. This is a waste of
system resources that you can avoid by limiting the search further, as shown below.
5 Specify the traffic type.
Use the --protocol tcp keyword to limit the effect of the custom signature to only
TCP traffic. This will save system resources by not unnecessarily scanning UDP and
ICMP traffic.
--service SMTP; --protocol tcp; )
The FortiGate unit will limit its search for the pattern to TCP traffic and ignore the
pattern in UDP and ICMP network traffic.
6 Ignore case sensitivity
By default, patterns are case sensitive. If a user directed his or her browser to
Example.com, the custom signature would not recognize the URL as a match.
Use the --no_case keyword to make the pattern matching case insensitive.

01-420-99686-20101026 821

--service SMTP; --no_case; )
Unlike all of the other keywords in this example, the --no_case keyword has no
value. Only the keyword is required.
7 Specify the context
The SMTP vrfy command will appear in the SMTP header. The --context host
keyword/value pair allows you to limit the pattern search to only the header.
--service SMTP; --no_case; --context header; )
Configuring a Fortinet Security Processing module

The Example Corporation has a web site that is the target of SYN floods. While they
investigate the source of the attacks, it’s very important that the web site remain
accessible. To enhance the ability of the company’s FortiGate-620B to deal with SYN
floods, the administrator will install an ASM-CE4 Fortinet Security Processing module and
have all external access to the web server come though it.
The security processing modules not only accelerate and offload network traffic from the
FortiGate unit’s processor, but they also accelerate and offload security and content
scanning. The ability of the security module to accelerate IPS scanning and DoS
protection greatly enhances the defense capabilities of the FortiGate-620B.
Assumptions
As shown in other examples and network diagrams throughout this document, the
Example Corporation has a pair of FortiGate-620B units in an HA cluster. To simplify this
example, the cluster is replaced with a single FortiGate-620B.
An ASM-CE4 is installed in the FortiGate-620B.
The network is configured as shown in Figure 70.
Network configuration
The Example Corporation network needs minimal changes to incorporate the ASM-CE4.
Interface amc-sw1/1 of the ASM-CE4 is connected to the Internet and interface
amc-sw1/1 is connected to the web server.
Since the main office network is connected to port2 and the Internet is connected to port1,
a switch is installed to allow both port1 and amc-sw1/1 to be connected to the Internet.

822 01-420-99686-20101026
Figure 70: The FortiGate-620B network configuration
Internal network
Web server
10.11.201.120
port2: 10.11.101.100 amc-sw1/2: 10.11.201.100
port1: 172.20.120.141 amc-sw1/1: 172.20.120.212
Switch
Internet
The switch used to connect port1 and amc-sw1/1 to the Internet must be able to handle
any SYN flood, all of the legitimate traffic to the web site, and all of the traffic to and from
the Example Corporation internal network. If the switch can not handle the bandwidth, or if
the connection to the service provider can not provide the required bandwidth, traffic will
be lost.
Security module configuration

The Fortinet security modules come configured to give equal priority to content inspection
and firewall processing. The Example Corporation is using a ASM-CE4 module to defend
its web server against SYN flood attacks so firewall processing is a secondary
consideration.
Use these CLI commands to configure the security module in ASM slot 1 to devote more
resources to content processing, including DoS and IPS, than to firewall processing.
config system amc-slot
edit sw1
set optimization-mode fw-ips
set ips-weight balanced
set ips-p2p disable
set ips-fail-open enable
set fp-disable none
set ipsec-inb-optimization enable
set syn-proxy-client-timer 3
set syn-proxy-server-timer 3
end
These settings do not disable firewall processing. Rather, when the security module nears
its processing capacity, it will chose to service content inspection over firewall processing.
DoS sensor configuration

Defend against anomaly-based attacks using a DoS sensor. For the SYN floods launched
against the Example Corporation web site, the tcp_syn_flood anomaly is the best defense.

01-420-99686-20101026 823
Create a DoS sensor for SYN flood protection

1 Go to UTM > Intrusion Protection > DoS Sensor.
3 Enter Web site SYN protection for the DoS sensor name.
4 Select OK to create the sensor.
The default tcp_syn_flood threshold is 2000. This means that the configured action will be
triggered when the number of TCP packets with the SYN flag set exceeds 2000 per
second.
For some applications, this value will be too high, while for others it will be too low. One
way to find the correct values for your environment is to set the action to Pass and enable
logging. Observe the logs and adjust the threshold values until you can determine the
value at which normal traffic begins to generate attack reports. Set the threshold above
this value with the margin you want. Note that the smaller the margin, the more protected
your network will be from DoS attacks, but your network traffic will also be more likely to
generate false alarms.
Configure a DoS sensor for SYN flood protection

2 Select the Web site SYN protection sensor and select the Edit icon.
3 Select Enable and Logging for the tcp_syn_flood anomaly.
4 Select the Proxy action for the tcp_syn_flood anomaly.
5 Enter the threshold value for the tcp_syn_flood anomaly.
6 Select OK.
With the action configured as Proxy, TCP packets with the SYN flag set will be passed
until the threshold value is exceeded. At that point, TCP packets with the SYN flag set until
their numbers fall below the threshold value.
The ASM-CE4 security module will intercept the packet, and reply to the client with a TCP
packet that has the SYN and ACK flags set. If the connection request is legitimate, the
client will reply with a packet that has the ACK flag set. The ASM-CE4 will then ‘replay’ this
exchange to the server and allow the client and server to communicate directly.
If the client does not reply with the expected packet, the ASM-CE4 will close the
connection. Therefore, if the security module receives a flood of SYN packets, they will be
blocked. Only the legitimate connections will be allowed through to the server.
DoS policy configuration

Before the DoS sensor can begin examining network traffic, you must create and
configure a DoS policy and specify the DoS sensor.
Create a DoS policy

1 Go to Firewall > DoS Policy.
3 Select amc-sw1/1 for Source Interface/Zone.
4 Select all for Source Address.
5 Select all for Destination Address.
6 Select ANY for Service.

824 01-420-99686-20101026
7 Enable DoS Sensor and select the Web site SYN protection sensor from the list.
8 Select OK.
Virtual IP configuration
Traffic destined for the web server will arrive at the amc-sw1/1 interface. You must create
a virtual IP mapping to have the ASM-CE4 direct the traffic to the web server.
Create a virtual IP mapping

3 In the Name field, enter web_server.
4 Select amc-sw1/1 as the External Interface.
5 Enter 172.20.120.212 as the External IP Address/Range.
6 Enter 10.11.201.120 as the Mapped IP Address/Range.
7 Select OK.
Firewall policy configuration

A firewall policy is required to allow traffic through to the web server. Further, the firewall
policy must include the virtual IP so the traffic is directed to the web server.
Create a firewall policy

3 Select amc-sw1/1 for the Source Interface/Zone.
4 Select all for the Source Address.
5 Select amc-sw1/2 for the Destination Interface/Zone.
6 Select web_server for the Destination Address.
8 Select OK.
Attempts to connect to 172.20.120.212 will be forwarded to the web server with this
firewall policy in place.
View proxy statistics

With a FortiGate security module installed, a CLI command displays the current proxy
statistics.
At the CLI prompt, type execute npu-cli /dev/ce4_0 showsynproxy. The last
nine lines will list the proxy statistics:
Total Proxied TCP Connections: 434055223
Working Proxied TCP Connections: 515699
Retired TCP Connections: 433539524
Valid TCP Connections: 0
Attacks, No Ack From Client: 433539524
No SynAck From Server: 0
Rst By Server (service not supported): 0
Client timeout setting: 3 Seconds
Server timeout setting: 3 Seconds

01-420-99686-20101026 825
Total Proxied TCP Connections The number of proxied TCP connection attempts since
the FortiGate unit was restarted.
This value is the sum of the working and retired
connection totals.
Working Proxied TCP Connections The number of TCP connection attempts currently being
proxied.
Retired TCP Connections The number of proxied TCP connection attempts
dropped or allowed. These connection attempts are no-
longer being serviced.
This value is the sum of the valid and attacks totals.
Valid TCP Connections The number of valid proxied TCP connection attempts.
Attacks, No Ack From Client The number of proxied TCP connection attempts in
which the client did not reply. These are typically attacks.
No SynAck From Server The number of valid client connection attempts in which
the server does not reply.
Rst By Server (service not supported) The number of valid client connection attempts in which
the server resets the connection.
Client timeout setting The client time-out duration.
Server timeout setting The server time-out duration.

826 01-420-99686-20101026
Web filter
This section describes FortiGate web filtering for HTTP traffic. The three main parts of the
web filtering function, the Web Content Filter, the URL Filter, and the FortiGuard Web
Filtering Service interact with each other to provide maximum control over what the
Internet user can view as well as protection to your network from many Internet content
threats. Web Content Filter blocks web pages containing words or patterns that you
specify. URL filtering uses URLs and URL patterns to block or exempt web pages from
specific sources. FortiGuard Web Filtering provides many additional categories you can
use to filter web traffic.
This section describes the Web Content Filter and URL Filter functions. For information on
FortiGuard Web Filtering, see “FortiGuard Web Filter” on page 843.
• Web filter concepts
• Web content filter
• URL filter
• SafeSearch
• Advanced web filter configuration
• Web filtering example
Web filter concepts

Web filtering is a means of controlling the content that an Internet user is able to view.
With the popularity of web applications, the need to monitor and control web access is
becoming a key component of secure content management systems that employ
antivirus, web filtering, and messaging security. Important reasons for controlling web
content include:
• lost productivity because employees are accessing the web for non-business reasons
• network congestion — when valuable bandwidth is used for non-business purposes,
legitimate business applications suffer
• loss or exposure of confidential information through chat sites, non-approved email
systems, instant messaging, and peer-to-peer file sharing
• increased exposure to web-based threats as employees surf non-business-related
web sites
• legal liability when employees access/download inappropriate and offensive material
• copyright infringement caused by employees downloading and/or distributing
copyrighted material.
As the number and severity of threats increase on the World Wide Web, the risk potential
increases within a company's network as well. Casual non-business related web surfing
has caused many businesses countless hours of legal litigation as hostile environments
have been created by employees who download and view offensive content. Web-based
attacks and threats are also becoming increasingly sophisticated. Threats and web-based
applications that cause additional problems for corporations include:

01-420-99686-20101026 827
Web filter concepts Web filter
• spyware/grayware
• phishing
• pharming
• instant messaging
• peer-to-peer file sharing
• streaming media
• blended network attacks.
Spyware, also known as grayware, is a type of computer program that attaches itself to a
user’s operating system. It does this without the user’s consent or knowledge. It usually
ends up on a computer because of something the user does such as clicking on a button
in a pop-up window. Spyware can track the user’s Internet usage, cause unwanted pop-up
windows, and even direct the user to a host web site. For further information, visit the
FortiGuard Center.
Some of the most common ways of grayware infection include:
• downloading shareware, freeware, or other forms of file-sharing services
• clicking on pop-up advertising
• visiting legitimate web sites infected with grayware.
Phishing is the term used to describe attacks that use web technology to trick users into
revealing personal or financial information. Phishing attacks use web sites and email that
claim to be from legitimate financial institutions to trick the viewer into believing that they
are legitimate. Although phishing is initiated by spam email, getting the user to access the
attacker’s web site is always the next step.
Pharming is a next generation threat that is designed to identify and extract financial, and
other key pieces of information for identity theft. Pharming is much more dangerous than
phishing because it is designed to be completely hidden from the end user. Unlike
phishing attacks that send out spam email requiring the user to click to a fraudulent URL,
pharming attacks require no action from the user outside of their regular web surfing
activities. Pharming attacks succeed by redirecting users from legitimate web sites to
similar fraudulent web sites that have been created to look and feel like the authentic web
site.
Instant messaging presents a number of problems. Instant messaging can be used to
infect computers with spyware and viruses. Phishing attacks can be made using instant
messaging. There is also a danger that employees may use instant messaging to release
sensitive information to an outsider.
Peer-to-peer (P2P) networks are used for file sharing. Such files may contain viruses.
Peer-to-peer applications take up valuable network resources and may lower employee
productivity but also have legal implications with the downloading of copyrighted or
sensitive company material.
Streaming media is a method of delivering multimedia, usually in the form of audio or
video to Internet users. Viewing streaming media impacts legitimate business by using
valuable bandwidth.
Blended network threats are rising and the sophistication of network threats is
increasing with each new attack. Attackers learn from each previous successful attack and
enhance and update attack code to become more dangerous and fast spreading. Blended
attacks use a combination of methods to spread and cause damage. Using virus or
network worm techniques combined with known system vulnerabilities, blended threats

828 01-420-99686-20101026
Web filter Web content filter
can quickly spread through email, web sites, and Trojan applications. Examples of
blended threats include Nimda, Code Red, Slammer, and Blaster. Blended attacks can be
designed to perform different types of attacks, which include disrupting network services,
destroying or stealing information, and installing stealthy backdoor applications to grant
remote access.
Different ways of controlling access

The methods available for monitoring and controlling Internet access range from manual
and educational methods to fully automated systems designed to scan, inspect, rate and
control web activity.
Common web access control mechanisms include:
• establishing and implementing a well-written usage policy in the organization on proper
Internet, email, and computer conduct
• installing monitoring tools that record and report on Internet usage
• implementing policy-based tools that capture, rate, and block URLs.
The final method is the focus of this topic. The following information shows how the filters
interact and how to use them to your advantage.
Order of web filtering

The FortiGate unit applies web filters in a specific order:
1 URL filter
2 FortiGuard Web Filter
3 web content filter
4 web script filter
5 antivirus scanning.
If you have blocked a FortiGuard Web Filter category but want certain users to have
access to URLs within that pattern, you can use the Override within the FortiGuard Web
Filter. This will allow you to specify which users have access to which blocked URLs and
how long they have that access. For example, if you want a user to be able to access
www.example.com for one hour, you can use the override to set up the exemption. Any
user listed in an override must fill out an online authentication form that is presented when
they try to access a blocked URL before the FortiGate unit will grant access to it. For more
information, see “FortiGuard Web Filter” on page 843.
Web content filter

You can control web content by blocking access to web pages containing specific words or
patterns. This helps to prevent access to pages with questionable material. You can also
add words, phrases, patterns, wild cards and Perl regular expressions to match content on
web pages. You can add multiple web content filter lists and then select the best web
content filter list for each web filter profile.
Enabling web content filtering involves three separate parts of the FortiGate configuration.
• The firewall policy allows certain network traffic based on the sender, receiver,
interface, traffic type, and time of day.
• The web filter profile specifies what sort of web filtering is applied.
• The web content filter list contains blocked and exempt patterns.

01-420-99686-20101026 829
Web content filter Web filter
The web content filter feature scans the content of every web page that is accepted by a
firewall policy. The system administrator can specify banned words and phrases and
attach a numerical value, or score, to the importance of those words and phrases. When
the web content filter scan detects banned content, it adds the scores of banned words
and phrases in the page. If the sum is higher than a threshold set in the web filter profile,
the FortiGate unit blocks the page.

Follow the configuration procedures in the order given. Also, note that if you perform any
additional actions between procedures, your configuration may have different results.
1 Create a web content filter list.
2 Add patterns of words, phrases, wildcards, and regular expressions that match the
content to be blocked or exempted.
You can add the patterns in any order to the list. You need to add at least one pattern
that blocks content.
3 In a web filter profile, enable the web content filter and select a web content filter list
from the options list.
To complete the configuration, you need to select a firewall policy or create a new one.
Then, in the firewall policy, enable UTM and select the appropriate web filter profile from
the list.
Creating a web filter content list

You can create multiple content lists and then select the best one for each web filter
profile.
To create a web filter content list

1 Go to UTM > Web Filter > Web Content Filter.
3 Enter a Name for the new list.
4 Enter optional comments to identify the list.
5 Select OK.
Configuring a web content filter list

Once you have created the web filter content list, you need to add web content patterns to
it. There are two types of patterns: Wildcard and Regular Expression.
You use the Wildcard setting to block or exempt one word or text strings of up to 80
characters. You can also use the wildcard symbols, such as “*” or “?”, to represent one or
more characters. For example, as a wildcard expression, forti*.com will match fortinet.com
and forticare.com. The “*” represents any kind of character appearing any number of
times.
You use the Regular Expression setting to block or exempt patterns of Perl expressions,
which use some of the same symbols as wildcard expressions, but for different purposes.
The “*” represents the character before the symbol. For example, forti*.com will match
fortiii.com but not fortinet.com or fortiice.com. The symbol “*” represents “i” in this case,
appearing any number of times.
The maximum number of web content patterns in a list is 5000.

830 01-420-99686-20101026
Web filter Web content filter
To add a web content pattern

2 Select the web content filter list and choose Edit.
4 Select Block or Exempt, as required, from the Action list.
5 Enter the content Pattern.
6 Select a Pattern Type from the drop-down list.
7 Select a Language for the pattern from the drop-down list if you need to change the
default.
8 Enter a score for the banned pattern.
The score can be left at the default value or set to another value. For more information,
see “How content is evaluated” on page 831.
9 Select Enable.
10 Select OK.
How content is evaluated

Every time the web content filter detects banned content on a web page, it adds the score
for that content to the sum of scores for that web page. You set this score when you create
a new pattern to block the content. The score can be any number from zero to 99999.
Higher scores indicate more offensive content. When the sum of scores equals or exceeds
the threshold score, the web page is blocked. The default score for web content filter is 10
and the default threshold is 10. This means that by default a web page is blocked by a
single match. Blocked pages are replaced with a message indicating that the page is not
accessible according to the Internet usage policy.
Banned words or phrases are evaluated according to the following rules:
• The score for each word or phrase is counted only once, even if that word or phrase
appears many times in the web page.
• The score for any word in a phrase without quotation marks is counted.
• The score for a phrase in quotation marks is counted only if it appears exactly as
written.
The following table describes how these rules are applied to the contents of a web page.
Consider the following, a web page that contains only this sentence: “The score for each
word or phrase is counted only once, even if that word or phrase appears many times in
the web page.”

01-420-99686-20101026 831
URL filter Web filter
Table 66: Banned Pattern Rules
Score
added to
Banned Assigned the sum Threshold
Comment
pattern score for the score
entire
page
word 20 20 20 Appears twice but only counted

once. Web page is blocked.
word 20 40 20 Each word appears twice but only

phrase counted once giving a total score of
40. Web page is blocked
word 20 20 20 “word” appears twice, “sentence”

sentence does not appear, but since any word
in a phrase without quotation marks
is counted, the score for this pattern
is 20. Web page is blocked.
“word 20 0 20 “This phrase does not appear

sentence” exactly as written. Web page is
allowed.
“word or 20 20 20 This phrase appears twice but is

phrase” counted only once. Web page is
blocked.
Enabling the web content filter and setting the content threshold
When you enable the web content filter, the web filter will block any web pages when the
sum of scores for banned content on that page exceeds the content block threshold. The
threshold will be disregarded for any exemptions within the web filter list.
To enable the web content filter and set the content block threshold
2 Select Create New to add a new web filter profile or select an existing profile and
choose Edit.
3 Select Web Content Filter.
4 Select the web content list in the Option column.
5 Enter the threshold for the web content filter.
6 Select OK.
URL filter
You can allow or block access to specific URLs by adding them to the URL filter list. You
add the URLs by using patterns containing text and regular expressions. The FortiGate
unit allows or blocks web pages matching any specified URLs or patterns and displays a
replacement message instead.
Note: URL blocking does not block access to other services that users can access with a
web browser. For example, URL blocking does not block access to ftp:// ftp.example.com.
Instead, use firewall policies to deny ftp connections.

832 01-420-99686-20101026
Web filter URL filter
When adding a URL to the URL filter list, follow these rules:
• Type a top-level URL or IP address to control access to all pages on a web site. For
example, www.example.com or 192.168.144.155 controls access to all pages at
this web site.
• Enter a top-level URL followed by the path and file name to control access to a single
page on a web site. For example, www.example.com/news.html or
192.168.144.155/news.html controls access to the news page on this web site.
• To control access to all pages with a URL that ends with example.com, add
example.com to the filter list. For example, adding example.com controls access to
www.example.com, mail.example.com, www.finance.example.com, and so on.
• Control access to all URLs that match patterns using text and regular expressions (or
wildcard characters). For example, example.* matches example.com, example.org,
example.net and so on.
Note: URLs with an action set to exempt or pass are not scanned for viruses. If users on
the network download files through the FortiGate unit from a trusted web site, add the URL
of this web site to the URL filter list with an action to pass it so the FortiGate unit does not
virus scan files downloaded from this URL.
URL filter actions

You can select one of four actions for URL patterns you include in URL filter lists.
Block
Attempts to access any URLs matching the URL pattern are denied. The user will be
presented with a replacement message.
Allow
Any attempt to access a URL that matches a URL pattern with an allow action is
permitted. The traffic is passed to the remaining antivirus proxy operations, including
FortiGuard Web Filter, web content filter, web script filters, and antivirus scanning.
Allow is the default action. If a URL does not appear in the URL list, it is permitted.
Pass
Traffic to, and reply traffic from, sites matching a URL pattern with a pass action will
bypass all antivirus proxy operations, including FortiGuard Web Filter, web content filter,
web script filters, and antivirus scanning.
Make sure you trust the content of any site you pass.
Exempt
Exempt is similar to Pass in that it allows trusted traffic to bypass the antivirus proxy
operations, but it functions slightly differently. In general, if you’re not certain that you need
to use the Exempt action, use Pass.
HTTP 1.1 connections are persistent unless declared otherwise. This means the
connections will remain in place until closed or the connection times out. When a client
loads a web page, the client opens a connection to the web server. If the client follows a
link to another page on the same site before the connection times out, the same
connection is used to request and receive the page data.

01-420-99686-20101026 833
URL filter Web filter
When you add a URL pattern to a URL filter list and apply the Exempt action, traffic sent to
and replies traffic from sites matching the URL pattern will bypass all antivirus proxy
operations, as with the Pass action. The difference is that the connection itself inherits the
exemption. This means that all subsequent reuse of the existing connection will also
bypass all antivirus proxy operations. When the connection times out, the exemption is
cancelled.
For example, consider a URL filter list that includes example.com/files configured
with the Exempt action. A user opens a web browser and downloads a file from the URL
example.com/sample.zip. This URL does not match the URL pattern so it is scanned
for viruses. The user then downloads example.com/files/beautiful.exe and since
this URL does match the pattern, the connection itself inherits the exempt action. The user
then downloads example.com/virus.zip. Although this URL does not match the
exempt URL pattern, a previously visited URL did, and since the connection inherited the
exempt action and was re-used to download a file, the file is not scanned.
If the user next goes to an entirely different server, like example.org/photos, the
connection to the current server cannot be reused. A new connection to example.org is
established. This connection is not exempt. Unless the user goes back to example.com
before the connection to that server times out, the server will close the connection. If the
user returns after the connection is closed, a new connection to example.com is created
and it is not exempt until the user visits a URL that matches the URL pattern.
Web servers typically have short time-out periods. A browser will download multiple
components of a web page as quickly as possible by opening multiple connections. A web
page that includes three photos will load more quickly if the browser opens four
connections to the server and downloads the page and the three photos at the same time.
A short time-out period on the connections will close the connections faster, allowing the
server to avoid unnecessarily allocating resources for a long period. The HTTP session
time-out is set by the server and will vary with the server software, version, and
configuration.
Using the exempt action can have unintended consequences in certain circumstances.
You have a web site at example.com and since you control the site, you trust the contents
and configure example.com as exempt. But example.com is hosted on a shared server
with a dozen other different sites, each with a unique domain name. Because of the
shared hosting, they also share the same IP address. If you visit example.com, your
connection your site becomes exempt from any antivirus proxy operations. Visits to any of
the 12 other sites on the same server will reuse the same connection and the data you
receive is exempt from scanned.
Use of the exempt action is not suitable for configuration in which connections through the
FortiGate unit use an external proxy. For example, you use proxy.example.net for all
outgoing web access. Also, as in the first example, URL filter list that includes a URL
pattern of example.com/files configured with the Exempt action. Users are protected
by the antivirus protection of the FortiGate unit until a user visits a URL that matches the of
example.com/files URL pattern. The pattern is configured with the Exempt action so
the connection to the server inherits the exemption. With a proxy however, the connection
is from the user to the proxy. Therefore, the user is entirely unprotected until the
connection times out, no matter what site he visits.
Ensure you are aware of the network topology involving any URLs to which you apply the
Exempt action.
Examples using exempt and pass actions

These examples illustrate the differences between the exempt and pass actions.

834 01-420-99686-20101026
Web filter URL filter
The URL filter list in use has a single entry: www.example.com/files/content/

• With an exempt action, the user downloads the file
www.example.com/files/content/eicar.com. This URL matches the URL filter
list entry so the file is not scanned. Further, the connection itself inherits the exemption.
The user next downloads www.example.com/virus/eicar.com. Although this
does not match the URL filter list entry, the existing connection to example.com will be
used so the file is not scanned.
• With a pass action, the user downloads the file
www.example.com/files/content/eicar.com. This URL matches the URL filter
list entry so the file is not scanned. The user next downloads
www.example.com/virus/eicar.com. This does not match the URL filter entry so
it will be scanned. The pass action does not affect the connection and every URL the
user accesses is checked against the URL filter list.
The URL filter list in use has a single entry: www.domain.com/files/content/. The
user’s browser is configured to use an external web proxy. All user browsing takes
advantage of this proxy.
• With an exempt action, the user downloads
www.example.com/files/content/eicar.com through the proxy. This matches
the URL filter list entry so the file is not scanned. Further, the connection to the proxy
inherits the exemption. The user next downloads
www.eicar.org/virus/eicar.com through the proxy. Although this does not
match the URL filter list entry, the existing connection to the proxy will be used so the
file is not scanned. In fact, until the user stops browsing long enough for the connection
to time out, all the user web traffic is exempt and will not be scanned.
• With a pass action, the user downloads
www.example.com/files/content/eicar.com through the proxy. This matches
the URL filter list entry so the file is not scanned. The user next downloads
www.eicar.org/virus/eicar.com through the proxy. This does not match the
URL filter entry so it will be scanned. The pass action does not affect the connection
and every URL the user accesses is checked against the URL filter list.

1 Create a URL filter list.
2 Add URLs to the URL filter list.
3 Select a web filter profile or create a new one.
4 In the web filter profile, enable the Web URL Filter and select a URL filter list from the
drop-down list.
To complete the configuration, you need to select a firewall policy or create a new one.
Then, in the firewall policy, enable UTM and select the appropriate web filter profile from
the list.
Creating a URL filter list

To create a URL Filter list
3 Enter a Name for the new URL filter list.

01-420-99686-20101026 835
SafeSearch Web filter
4 Enter optional comments to describe it.

5 Select OK.
Configuring a URL filter list

Each URL filter list can have up to 5000 entries. For this example, the URL
www.example*.com will be used. You configure the list by adding one or more URLs to it.
To add a URL to a URL filter list

2 Select an existing list and choose Edit.
4 Enter the URL, without the “http”, for example: www.example*.com.
5 Select a Type: Simple, Wildcard or Regular Expression.
In this example, select Wildcard.
6 Select the Action to take against matching URLs: Exempt, Block, Allow, or Pass.
7 Select Enable.
8 Select OK.
SafeSearch
SafeSearch is a feature of popular search sites that prevents explicit web sites and
images from appearing in search results. Although SafeSearch is a useful tool, especially
in educational environments, the resourceful user may be able to simply turn it off.
Enabling SafeSearch for the supported search sites enforces its use by rewriting the
search URL to include the code to indicate the use of the SafeSearch feature.
Three search sites are supported:
Google Enforce the strict filtering level of safe search protection for Google search results by
adding &safe=on to search URL requests. Strict filtering removes both explicit text
and explicit images from the search results.
Yahoo! Enforce the strict filtering level of safe search protection for Yahoo! search results by
adding &vm=r to search URL requests. Strict filtering removed adult web, video, and
images from search results.
Bing Enforce the strict filtering level of safe search protection for Bing search results by
adding adlt=strict to search URL requests. Strict filtering removes explicit text,
images, and video from the search results.
Enabling SafeSearch — Web-based manager

2 Select the profile in which you want to enable SafeSearch and choose Edit.
3 Under the SafeSearch heading, select the check boxes for Google, Yahoo!, and Bing
in the Options column.
4 Select OK.
The CLI can also be used to enable SafeSearch in a web filter profile. In this example, the
safe_web web filter is configured to enable SafeSearch.

836 01-420-99686-20101026
Web filter Advanced web filter configuration
Enabling SafeSearch — CLI

edit safe_web
config web
set safe-search bing google yahoo
end
end
This enforces the use of SafeSearch in traffic controlled by the firewall policies using the
web filter you configure.
Advanced web filter configuration

The Advanced Filter section of the web filter profile provides a number of advanced
filtering options. The FortiGuard Web Filter options in the advance filter section are
detailed in the FortiGuard Web Filter section, in “Advanced FortiGuard Web Filter
ActiveX filter
Enable to filter ActiveX scripts from web traffic. Web sites using ActiveX may not function
properly with this filter enabled.
Cookie filter
Enable to filter cookies from web traffic. Web sites using cookies may not function properly
with this enabled.
Java applet filter

Enable to filter java applets from web traffic. Web sites using java applets may not function
properly with this filter enabled.
Web resume download block

Enable to prevent the resumption of a file download where it was previously interrupted.
With this filter enabled, any attempt to restart an aborted download will download the file
from the beginning rather than resuming from where it left off.
This prevents the unintentional download of viruses hidden in fragmented files.
Note that some types of files, such as PDF, fragment files to increase download speed and
enabling this option can cause download interruptions. Enabling this option may also
break certain applications that use the Range Header in the HTTP protocol, such as YUM,
a Linux update manager.
Block Invalid URLs

Select to block web sites when their SSL certificate CN field does not contain a valid
domain name.
FortiGate units always validate the CN field, regardless of whether this option is enabled.
However, if this option is not selected, the following behavior occurs:
• If the request is made directly to the web server, rather than a web server proxy, the
FortiGate unit queries for FortiGuard Web Filtering category or class ratings using the
IP address only, not the domain name.

01-420-99686-20101026 837
Web filtering example Web filter
• If the request is to a web server proxy, the real IP address of the web server is not
known. Therefore, rating queries by either or both the IP address and the domain
name is not reliable. In this case, the FortiGate unit does not perform FortiGuard Web
Filtering.
HTTP POST action

Select the action to take with HTTP POST traffic. HTTP POST is the command used by
your browser when you send information, such as a form you have filled-out or a file you
are uploading, to a web server.
The available actions include:
Normal Allow use of the HTTP POST command as normal.

Comfort Use client comforting to slowly send data to the web server as the FortiGate unit
scans the file. Use this option to prevent a server time-out when scanning or other
filtering is enabled for outgoing traffic.
The client comforting settings used are those defined in the protocol options profile
selected in the firewall policy. For more information, see “Configuring client
comforting” on page 770.
Block Block the HTTP POST command. This will limit users from sending information and
files to web sites.
When the post request is blocked, the FortiGate unit sends the http-post-block
replacement message to the web browser attempting to use the command.
Web filtering example

Web filtering is particularly important for protecting school-aged children. There are legal
issues associated with improper web filtering as well as a moral responsibility not to allow
children to view inappropriate material. The key is to design a web filtering system in such
a way that students and staff do not fall under the same web filter profile in the FortiGate
configuration. This is important because the staff may need to access websites that are
off-limits to the students.
School district
The background for this scenario is a school district with more than 2300 students and 500
faculty and staff in a preschool, three elementary schools, a middle school, a high school,
and a continuing education center. Each elementary school has a computer lab and the
high school has three computer labs with connections to the Internet. Such easy access to
the Internet ensures that every student touches a computer every day.
With such a diverse group of Internet users, it was not possible for the school district to set
different Internet access levels. This meant that faculty and staff were unable to view
websites that the school district had blocked. Another issue was the students’ use of proxy
sites to circumvent the previous web filtering system. A proxy server acts as a go-between
for users seeking to view web pages from another server. If the proxy server has not been
blocked by the school district, the students can access the blocked website.
When determining what websites are appropriate for each school, the district examined a
number of factors, such as community standards and different needs of each school
based on the age of the students.
The district decided to configure the FortiGate web filtering options to block content of an
inappropriate nature and to allow each individual school to modify the options to suit the
age of the students. This way, each individual school was able to add or remove blocked
sites almost immediately and have greater control over their students’ Internet usage.

838 01-420-99686-20101026
Web filter Web filtering example
In this simplified example of the scenario, the district wants to block any websites with the
word example on them, as well as the website www.example.com. The first task is to
create web content filter lists for the students and the teachers.
To create a web content filter list for the students

3 Enter the Name of the new list: Student Web Content List.
5 Select OK.
To create a web content filter list for the teachers

3 Enter the Name of the new list: Teacher Web Content List.
5 Select OK.
The next step is to configure the two web content filters that were just created. The first will
be the Student Web Content List.
To add a pattern to the student web content filter list

2 Select the Student Web Content List and choose Edit.
4 Enter the word example as the content block Pattern.
5 Leave the rest of the settings at their default values.
6 Select OK.
It might be more efficient if the Teacher Web Content List included the same blocked
content as the student list. From time to time a teacher might have to view a blocked page.
It would then be a matter of changing the Action from Block to Allow as the situation
required.
To change a pattern from Block to Exempt

2 Select the Teacher Web Content List and choose Edit.
3 Select example from the Pattern list and choose Edit.
4 Select Exempt from the Action list.
5 Ensure that Enable is selected.
6 Select OK.
URL filter lists with filters to block unwanted web sites must be created for the students
and teachers. For this example the URL www.example.com will be used.
To create a URL filter for the students


01-420-99686-20101026 839
3 Enter Student URL List as the URL filter Name.

4 Enter optional comments to describe the contents of the list.
5 Select OK.
The URL filter for the students has been created. Now it must be configured.
To configure the URL filter for the students

2 Select Student URL List and choose Edit.
4 Enter www.example.com in the URL field.
5 Select Simple from the Type list.
6 Select Block from the Action list.
7 Select Enable.
8 Select OK.
The teachers should be able to view the students’ blocked content, however, so an
addition URL filter is needed.
To create a URL filter for the teachers

3 Enter Teacher URL List as the URL filter Name.
4 Enter optional comments to describe the list.
5 Select OK.
To configure the URL filter for the teachers

2 Select Teachers URL List and choose Edit.
4 Enter www.example.com in the URL field.
5 Select Simple from the Type list.
6 Select Exempt from the Action list.
7 Select Enable.
8 Select OK.
A web filter profile must be created for the students and the teachers.
To create a web filter profile for the students

3 Enter Students as the Profile Name.
4 Enter optional comments to identify the profile.
5 Enable Web Content Filter and select Student Web Content List from the drop-down
list.
6 Enable Web URL Filter and select Student URL List from the drop-down list.

840 01-420-99686-20101026
Web filter Web filtering example
7 Expand the Advanced Filter section.

8 Enable Web Resume Download Block.
Selecting this setting will block downloading parts of a file that have already been
downloaded and prevent the unintentional download of virus files hidden in fragmented
files. Note that some types of files, such as PDFs, are fragmented to increase
download speed, and that selecting this option can cause download interruptions with
these types.
9 Select OK.
To create a firewall policy for the students

3 Enable UTM.
4 Select Enable Web Filter.
5 Select Students from the web filter drop-down list.
6 Enter optional comments.
7 Select OK.
To create a web filter profile for the teachers

3 Enter Teachers as the Profile Name.
4 Enter optional comments to identify the profile.
5 Enable Web Content Filter and select Teacher Web Content List from the list.
6 Enable Web URL Filter and select Teacher URL List from the list.
7 Expand the Advanced Filter section.
8 Enable Web Resume Download Block.
9 Select OK.
To create a firewall policy for Teachers

3 Enable UTM.
4 Select Enable Web Filter.
5 Select Teachers from the web filter drop-down list.
6 Enter optional comments.
7 Select OK.

01-420-99686-20101026 841

842 01-420-99686-20101026
FortiGuard Web Filter
This section describes FortiGuard Web Filter for HTTP and HTTPS traffic.
FortiGuard Web Filter is a managed web filtering solution available by subscription from
Fortinet. FortiGuard Web Filter enhances the web filtering features supplied with your
FortiGate unit by sorting billions of web pages into a wide range of categories users can
allow or block. The FortiGate unit accesses the nearest FortiGuard Web Filter Service
Point to determine the category of a requested web page, and then applies the firewall
policy configured for that user or interface.
FortiGuard Web Filter includes over 45 million individual ratings of web sites that apply to
more than two billion pages. Pages are sorted and rated into several dozen categories
administrators can allow or block. Categories may be added or updated as the Internet
evolves. To make configuration simpler, you can also choose to allow or block entire
groups of categories. Blocked pages are replaced with a message indicating that the page
is not accessible according to the Internet usage policy.
FortiGuard Web Filter ratings are performed by a combination of proprietary methods
including text analysis, exploitation of the web structure, and human raters. Users can
notify the FortiGuard Web Filter Service Points if they feel a web page is not categorized
correctly, so that the service can update the categories in a timely fashion.
The following topics are discussed in this section:
• Before you begin
• FortiGuard Web Filter and your FortiGate unit
• Enable FortiGuard Web Filter
• Advanced FortiGuard Web Filter configuration
• Add or change FortiGuard Web Filter ratings
• Create FortiGuard Web Filter overrides
• Customize categories and ratings
• FortiGuard Web Filter examples
Before you begin

Before you follow the instructions in this section, you should have a FortiGuard Web Filter
subscription and your FortiGate unit should be properly configured to communicate with
the FortiGuard servers. For more information about FortiGuard services, see the
FortiGuard Center web page. You should also have a look at “Web filter concepts” on
page 827.

01-420-99686-20101026 843
FortiGuard Web Filter and your FortiGate unit FortiGuard Web Filter
FortiGuard Web Filter and your FortiGate unit

When FortiGuard Web Filter is enabled in a web filter profile, the setting is applied to all
firewall policies that use this profile. When a request for a web page appears in traffic
controlled by one of these firewall policies, the URL is sent to the nearest FortiGuard
server. The URL category is returned. If the category is blocked, the FortiGate unit
provides a replacement message in place of the requested page. If the category is not
blocked, the page request is sent to the requested URL as normal.
Order of web filtering

The FortiGate unit applies web filters in a specific order:
1 URL filter
2 FortiGuard Web Filter
3 web content filter
4 web script filter
5 antivirus scanning.
The flowchart in Figure 71 on page 845 shows the steps involved in FortiGuard Web
Filtering. Most features are included but some of the advanced options, including
overrides, are not. The features appearing in the flowchart are described in this section.

844 01-420-99686-20101026
FortiGuard Web Filter FortiGuard Web Filter and your FortiGate unit
Figure 71: FortiGuard Web Filter sequence of events
Is the URL
Query FortiGuard Deny access to the classification set
Start
for URL category URL and stop any to block or
and classification running quota timer allow?
User attempts to Block Allow
load a URL
Block Yes
Is the URL Allow Is there a

Strict category set classification
Blocking? to block or for this URL?
Yes allow?
No
No
Is the URL Is
category set FortiGuard Quota Allow access
to block or exempt for the to the URL
allow? Category?
Allow Yes
Block
No
Allow
Is there a Is the URL Is Is there any Yes
classification classification set FortiGuard Quota time remaining Start the category
for this URL? to block or enabled for the for this category timer and allow
allow? Category? quota? access to the URL
Yes Yes
No Block No No
Deny access to the

URL and stop any
Deny access to the
running quota timer
URL and stop any
running quota timer Is
FortiGuard Quota
Allow access
exempt for the
to the URL
classification?
Yes
No
Is Is Is Yes
Is there any
Allow access to the FortiGuard Quota FortiGuard Quota FortiGuard Quota Start the classification
time remaining
URL and stop any enabled for the exempt for the enabled for the timer and allow
for this classification
running quota timer category group? category group? classification? access to the URL
No No No Yes quota?
Yes Yes No
Deny access to the

URL and stop any
Allow access running quota timer
to the URL
Is there any
time remaining
for this category
group quota?
No
Yes
Deny access to the Start the category

URL and stop any group timer and allow
running quota timer access to the URL

01-420-99686-20101026 845
Enable FortiGuard Web Filter FortiGuard Web Filter
Enable FortiGuard Web Filter

FortiGuard Web Filter is enabled and configured within web filter profiles. Overrides, local
categories, and local ratings are configured in UTM > Web Filter.

2 Select the Edit icon of the web filter profile in which you want to enable FortiGuard Web
Filter, or select Create New to add a new web filter profile.
3 Expand the FortiGuard Web Filtering section.
4 Under the FortiGuard Web Filtering heading, the Enable FortiGuard Web Filtering row
allows you to enable the feature for HTTP and HTTPS traffic. Select either or both
check boxes as required.
5 The category and classification tables allow you to block or allow access to general or
more specific web site categories. Configure access as required.
6 Select OK to save the web filter profile.
7 To complete the configuration, you need to select the firewall policy controlling the
network traffic you want to restrict. Then, in the firewall policy, enable UTM and select
Enable Web Filter and select the appropriate web filter profile from the list.
Configuring FortiGuard Web Filter settings

FortiGuard Web Filter includes a number of settings that allow you to determine various
aspects of the filtering behavior.
To configure FortiGuard Web Filter settings

2 Select the Edit icon of the web filter profile in which you want to enable FortiGuard Web
Filter, or select Create New to add a new web filter profile.
4 Select one or both of the HTTP and HTTPS check boxes in the row labeled FortiGuard
Web Filtering to enable FortiGuard Web Filter for HTTP and HTTPS web traffic.
At least one of these check boxes must be selected for FortiGuard Web Filter to
function for the protocol. Other web filter features, such as web content filter and URL
filter, will function as configured, however.
5 Select FortiGuard Web Filtering Overrides to enable the overrides configured in UTM >
Web Filter > Override. Select HTTP, HTTPS, or both to enable overrides. For more
information, see “Create FortiGuard Web Filter overrides” on page 852.
6 Select OK to save your changes to the web filter profile.
Configuring FortiGuard Web Filter categories

Categories are a means to describe the content of web sites. FortiGuard Web Filter
divides the web into dozens of categories in eight category groups.
Every URL and IP address is associated with one category. URLs and IP addresses that
have not been rated are placed in the Unrated category so you can still apply actions,
overrides, and quotas to them.

846 01-420-99686-20101026
FortiGuard Web Filter Enable FortiGuard Web Filter
To configure the FortiGuard Web Filter categories

2 Select Create New to add a new web filter profile, or select an existing web filter profile
and choose Edit to configure the FortiGuard Web Filter categories.
4 Under the FortiGuard Web Filtering heading, the category groups are listed in a table.
You can expand each category group to view and configure every category within the
group. If you change the setting of a category group, all categories within the group
inherit the change.
5 Select Allow to allow access to the sites within the category.
6 Select Block to restrict access to sites within the category. Users attempting to access
a blocked site will receive a replacement message explaining that access to the site is
blocked.
7 Select Log to record attempts to access sites in a category.
8 Select Allow Override to allow users to override blocked categories. For more
information, see “Understanding administrative and user overrides” on page 852.
Before you can allow an override, you must create it (see “Create FortiGuard Web
Filter overrides” on page 852) and then enable FortiGuard Web Filtering Overrides in
the web filter profile.
9 Select OK.
Configuring FortiGuard Web Filter classifications

Classifications are assigned based on characteristics of the site, not the topic of the site
content. For example, the cached content classification tells you the site caches content
from other sites. It tells you nothing about what the content is.
Unlike categories, not every rated URL and IP address has an assigned classification.
To configure the FortiGuard Web Filter classifications

2 Select Create New to add a new web filter profile or select the web filter profile in which
you want to configure the FortiGuard Web Filter categories and select Edit.
The classification table is listed below the category table.
4 Select Allow to allow access to the sites within the classification.
5 Select Block to restrict access to sites within the classification. Users attempting to
access a blocked site will receive a replacement message explaining that access to the
site is blocked.
6 Select Log to record attempts to access sites in a classification.
7 Select Allow Override to allow users to override blocked classifications.
This option is not available unless you also:
• select the Enable FortiGuard Web Filtering Overrides option that appears just
before the table
• create overrides in UTM > Web Filter > Override. For more information, see “Create
FortiGuard Web Filter overrides” on page 852.
8 Select OK.

01-420-99686-20101026 847
Enable FortiGuard Web Filter FortiGuard Web Filter
Configuring FortiGuard Web Filter usage quotas

In addition to using category and classification blocks and overrides to limit user access to
URLs, you can set a daily timed access quota by category, category group, or
classification. Quotas allow access for a specified length of time, calculated separately for
each user. Quotas are reset every day at midnight.
Users must authenticate with the FortiGate unit. The quota is applied to each user
individually so the FortiGate must be able to identify each user. One way to do this is to
configure a firewall policy using the identity based policy feature. Apply the web filter
profile in which you have configured FortiGuard Web Filter and FortiGuard Web Filter
quotas to such a firewall policy.
Caution: The use of FortiGuard Web Filter quotas requires that users authenticate to gain
web access. The quotas are ignored if applied to a firewall policy in which user
authentication is not required.
When a user first attempts to access a URL, they’re prompted to authenticate with the
FortiGate unit. When they provide their username and password, the FortiGate unit
recognizes them, determines their quota allowances, and monitors their web use. The
category and classification of each page they visit is checked and FortiGate unit adjusts
the user’s remaining available quota for the category or classification.
Note: Editing the web filter profile resets the quota timers for all users.
To configure the FortiGuard Web Filter categories

2 Select an existing web filter profile and choose Edit to configure the FortiGuard Web
Filter categories.
4 Under the FortiGuard Web Filtering heading, the category groups are listed in a table.
You can expand each category group to view and configure every category within the
group.
5 Under the FortiGuard Quota heading, select Enable to activate the quota for the
category, category group, or classification.
6 Select Hours, Minutes, or Seconds and enter the number of hours, minutes, or
seconds. This is the daily quota allowance for each user.
7 Select OK.
Apply the web filter profile to an identity-based firewall policy. All the users subject to that
policy are restricted by the quotas.
Quota hierarchy
You can apply quotas to categories, category groups, and classifications. Only one quota
per user can be active at any one time. The one used depends on how you configure the
FortiGuard Web Filter.

848 01-420-99686-20101026
FortiGuard Web Filter Enable FortiGuard Web Filter
When a user visits a URL, the FortiGate unit queries the FortiGuard servers for the
category and classification of the URL. From highest to lowest, the relative priority of the
quotas are:
1 Category
2 Classification
3 Category group
So for example, the Business Oriented category group contains the Information
Technology category. When a user visits a page in the Information Technology category,
the FortiGate unit will check for quotas in sequence:
• Is there is a quota set for the Information Technology category? If there is, the category
quota timer is started and the user is allowed access to the URL. If no time remains in
the category quota, the URL is blocked and the user cannot access it for the remainder
of the day.
• If there is no quota set for the Information Technology category, is there a quota set for
any classification that applies to the URL? If there is, the classification quota timer is
started and the user is allowed access to the URL. If no time remains in the
classification quota, the URL is blocked and the user cannot access it for the remainder
of the day.
• If no quota is set, or no classification exists for the URL, is there a quota set for the
Business Oriented category group? If there is, the category group quota timer is
started and the user is allowed access to the URL. If no time remains in the category
group quota, the URL is blocked and the user cannot access it for the remainder of the
day.
• If there is no category group quota, the user is allowed to access the URL. Getting to
this point means there are no quotas set for the page. The FortiGate unit will stop any
running quota timer because the current URL has no quota.
Only one quota timer can be running at any one time for a single user. Whenever a quota
timer is started or a page is blocked, the timer running, because of the previous URL
access, is stopped. Similarly, a URL with no quotas will stop a quota timer still running
because of the URL the user previously accessed.
Quota exempt
The quota checking sequence occurs for every URL the user accesses. This is true for
every web page, and every element of the web page that is loaded. For example, if a user
loads a web page, the quota is checked for the web page as soon as it is loaded. If there is
a photo on the page, it is also checked and the quota is adjusted accordingly.
This can cause unexpected behavior. For example, if the web page a user loads is in the
Information Technology category and it has a quota, the quota timer is started. The web
page includes a number of graphics, so as these are loaded, each is checked and the
appropriate quota is started. If they all share the same category rating, which they often
will, there is no problem. However, if the last graphic or page element loaded comes from
another site, the quota may not work as you expect. If the last graphic is an ad, loaded
from a site categorized as Advertising, the Information Technology category quota timer
will stop almost as soon as it is started because the FortiGate unit sees the ad URL and
finds that it belongs to the Advertising category. If Advertising has a quota, its timer will
start. If it is blocked or allowed, the Information Technology category quota timer is
stopped and the user can view the page without using the quota set to limit the Information
Technology category.

01-420-99686-20101026 849
Advanced FortiGuard Web Filter configuration FortiGuard Web Filter
To solve this problem, you can configure a category, category group, or classification as
exempt. This effectively allows the quota system to ignore it entirely. Any quota timer
running when an exempt URL is encountered continues to run. An exempt category,
category group, or classification can not have a quota. This may sound the same as
simply disabling the quota and setting the FortiGuard Web Filter action to allow, but there
is a difference. This difference is that the allow and block actions stop an already running
quota timer, while the exempt action does not.
The exempt action is generally used for commonly accessed web pages that load
elements from other sites that have different category ratings. Pages that load ads from
advertising sites are the most common example.
Checking quota usage

With quotas enabled, the FortiGate unit keeps track of quota usage for each user in each
web filter profile. You can check the amount of quota usage for each user and their
remaining time for each individual quota on the FortiGuard Quota page.
To view FortiGuard Web Filter quota usage

1 Go to UTM > Web Filter > FortiGuard Quota.
2 The table shows the users who have used some or all of their quota allowance. The
total time used is listed by web filter profile for each user.
3 Select the View icon in any row to view the remaining quota for each category,
category group, and classification. A category, category group, or classification
displayed in bold type indicates the quota currently in use.
Quotas are reset every day at midnight.
Advanced FortiGuard Web Filter configuration

The Advanced Filter section of the web filter profile provides a number of advanced filter
options. The web filter options in the advance filter section unrelated to FortiGuard Web
Filter are detailed in the web filter section, in “Advanced web filter configuration” on
page 837.
Provide Details for Blocked HTTP 4xx and 5xx Errors

Enable to have the FortiGate unit display its own replacement message for 400 and
500-series HTTP errors. If the server error is allowed through, malicious or objectionable
sites can use these common error pages to circumvent web filtering.
Rate Images by URL (blocked images will be replaced with blanks)

Enable to have the FortiGate retrieve ratings for individual images in addition to web sites.
Images in a blocked category are not displayed even if they are part of a site in an allowed
category.
Blocked images are replaced on the originating web pages with blank place-holders.
Rated image file types include GIF, JPEG, PNG, BMP, and TIFF.
Allow Websites When a Rating Error Occurs

Enable to allow access to web pages that return a rating error from the FortiGuard Web
Filter service.

850 01-420-99686-20101026
FortiGuard Web Filter Add or change FortiGuard Web Filter ratings
If your FortiGate unit cannot contact the FortiGuard service temporarily, this setting
determines what access the FortiGate unit allows until contact is re-established. If
enabled, users will have full unfiltered access to all web sites. If disabled, users will not be
allowed access to any web sites.
Strict Blocking
This setting determines when the FortiGate unit blocks a site. Enable strict blocking to
deny access to a site if any category or classification assigned to the site is set to Block.
Disable strict blocking to deny access to a site only if all categories and classifications
assigned to the site are set to Block.
All rated URLs are assigned one or more categories. URLs may also be assigned a
classification. If Rate URLs by domain and IP address is enabled, the site URL and IP
address each carry separately assigned categories and classifications. Depending on the
FortiGuard rating and the FortiGate configuration, a site could be assigned to at least two
categories and up to two classifications.
Rate URLs by Domain and IP Address

Enable to have the FortiGate unit request the rating of the site by URL and IP address
separately, providing additional security against attempts to bypass the FortiGuard Web
Filter.
Note: FortiGuard Web Filter ratings for IP addresses are not updated as quickly as ratings
for URLs. This can sometimes cause the FortiGate unit to allow access to sites that should
be blocked, or to block sites that should be allowed.
Block HTTP Redirects by Rating

Enable to block HTTP redirects.
Many web sites use HTTP redirects legitimately but in some cases, redirects may be
designed specifically to circumvent web filtering, as the initial web page could have a
different rating than the destination web page of the redirect.
This option is not supported for HTTPS.
Daily log of remaining quota

Enable to log daily quota use.
As part of the quota reset at midnight, the FortiGate unit will record a log entry for every
quota each user consumed during the day. These log entries are labeled with the sub-type
ftgd_quota. Each entry includes the VDOM, user name, web filter profile name,
category description, quota used (in seconds), and quota (in seconds). You can use log
filtering to quickly limit the displayed entries to those you want, and generate reports from
the logs.
Add or change FortiGuard Web Filter ratings

The FortiGuard Center web site allows you to check the current category assigned to any
URL.
To check the category assigned to a URL

1 Using your web browser, go to the FortiGuard Center Web Filter URL Lookup &
Submission page at http://www.fortiguard.com/webfiltering/webfiltering.html.
2 Enter the URL as directed.

01-420-99686-20101026 851
Create FortiGuard Web Filter overrides FortiGuard Web Filter
3 Select Search.
4 If the URL has been rated by the FortiGuard web filter team, the category is displayed.
If a URL has not been rated, or you believe it is incorrectly rated, you can suggest the
appropriate category and classification.
To add or change the category for a URL

1 Check the category assigned to the URL as described in the previous procedure.
2 Below the rating, select Check to submit the URL.
3 Enter your name, company, and email address.
4 Optionally, you may enter a comment.
5 Select the most appropriate category and classification for the URL.
6 Select Submit to send your submission to the FortiGuard web filter team.
Create FortiGuard Web Filter overrides

You can configure FortiGuard Web Filter to allow or deny access to web sites by category
and classification. You may want to block a category but allow your users temporary
access to one site within the blocked category. You may need to allow only some users to
temporarily access one site within a blocked category. Do these things by using
administrative and user overrides.
Understanding administrative and user overrides

The administrative overrides are backed up with the main configuration. The
administrative overrides are not deleted when they expire and you can reuse them by
extending their expiry dates. You can create administrative overrides either through the
CLI or the web-based manager.
The user overrides are not backed up as part of the main configuration. These overrides
are automatically deleted when they expire. You can only view and delete the user
override entries. Users create user overrides using the authentication form opened from
the block page when they attempt to access a blocked site, if override is enabled.
To create an administrative override

1 Go to UTM > Web Filter > Override.
2 Select Administrative Overrides and choose Edit.
4 Using the Type selection, choose the type of override to create:
• A Directory override will allow access to a particular directory on a blocked site.
• An Exact Domain override will allow access to a blocked domain.
• A Categories override will allow access to a blocked category.
5 If you select a directory or domain override, enter the directory or domain in the URL
field.
If you select a category override, select the categories and classifications you want to
allow.

852 01-420-99686-20101026
FortiGuard Web Filter Customize categories and ratings
6 Using the Scope selection, choose how the override will be applied:
• A User scope limits the override to a single user. Enter the user ID in the User field.
• A User Group scope limits the override to the users you have included in a user
group. Using the User Group selection, choose the user group.
• An IP scope limits the override to an IPv4 address. Enter the address in the IP field.
• An IPv6 scope limits the override to an IPv6 address. Enter the address in the IPv6
field.
7 Select whether to Allow or Deny content from Off-site URLs.
This option defines whether the web page that is displayed as the result of an override
will display the images and other contents from other blocked offsite URLs.
For example, if all FortiGuard categories are blocked, but you want to allow access to a
web site, you can create a domain override for the site and view the page. If the
images on the site are served from a different domain and Off-site URLs is set to Deny,
all the images on the page will appear broken because they come from a domain that
the existing override rule does not apply to. If Off-site URLs is set to Allow, the images
on the page will appear properly.
8 Select when the override expires by entering the exact time and date.
9 Select OK to save the override rule.
Customize categories and ratings

The FortiGuard Web Filter rating categories are general enough that virtually any web site
can be accurately categorized in one of them. However, the rigid structure of the
categories can create complications. For example, your company uses a web-based email
provider. If you select the Web-based Email category, all sites categorized as web-based
email providers, including the one your company uses, are blocked.
Local categories and local ratings allow you to assign sites to any category you choose.
You can even create new categories. These settings apply only to your FortiGate unit. The
changes you make are not sent to the FortiGuard Web Filter Service.
Creating local categories

Categories are labels that describe web site content. Creating your own category allows
you to customize how the FortiGuard Web Filter service works.
Local categories appear in the web filter profile, under the FortiGuard Web Filter category
list, in the Local Categories group. Local categories are empty when created. To populate
local categories with web sites, see “Customizing site ratings” on page 853.
To create a local category

1 Go to UTM > Web Filter > Local Categories.
2 Enter the name of the new local category in the field above the local category list.
3 Select Add.
The new local category is added to the list, but will remain empty until you add a web
site to it.
Customizing site ratings

You may find it convenient to change the rating of a site. For example, if you want to block
all the sites in a category except one, you can move the one site to a different category.

01-420-99686-20101026 853
FortiGuard Web Filter examples FortiGuard Web Filter
To customize a site rating

1 Go to UTM > Web Filter > Local Ratings.
3 In the URL field, enter the URL of the site you want to change.
4 In the Category Rating table, select the category or categories to apply to the site.
If you created any local categories, a Local Categories group will appear.
5 In the Classification Rating table, select a classification to apply to the site.
6 Select OK.
FortiGuard Web Filter examples

FortiGuard Web Filter can provide more powerful filtering to your network because you
can use it to restrict access to millions of sites by blocking the categories they belong to.
Configuring simple FortiGuard Web Filter protection

have very simple needs. This example details how to enable FortiGuard Web Filter
protection on a FortiGate unit located in a satellite office.
Creating a web filter profile

Most FortiGuard Web Filter settings are configured in a web filter profile. Web filter profiles
are selected in firewall policies. This way, you can create multiple web filter profiles, and
tailor them to the traffic controlled by the firewall policy in which they are selected. In this
example, you will create one web filter profile.
To create a web filter profile — web-based manager

3 In the Name field, enter basic_FGWF.
4 Select the FortiGuard Web Filtering check boxes for the HTTP and HTTPS traffic
types.
5 Select the FortiGuard Web Filtering expand arrow.
6 Select the Block action for the Potentially Liable, Controversial, and Potentially
Security Violating categories.

854 01-420-99686-20101026
FortiGuard Web Filter FortiGuard Web Filter examples
To create a web filter profile — CLI

edit basic_FGWF
config http
end
config https
end
config ftgd-wf
set deny g01 g02 g05
end
end
Applying the web filter profile to a firewall policy

A web filter profile directs the FortiGate unit to scan network traffic only when it is selected
in a firewall policy. When a web filter profile is selected in a firewall policy, its settings are
To select the web filter profile in a firewall policy — web-based manager

2 Select a policy and choose the Edit icon.
3 Enable UTM.
provided.
5 Select the Enable Web Filter option.
6 Select the basic_FGWF profile from the list.
To select the web filter profile in a firewall policy — CLI

edit 1
set webfilter-profile basic_FGWF
end
HTTP and HTTPS traffic handled by the firewall policy you modified will be monitored for
attempts to access to the blocked sites. A small office may have only one firewall policy
configured. If you have multiple policies, consider enabling web filter scanning for all
outgoing policies.
Note: If you have multiple policies, consider enabling web filter scanning for all outgoing
policies
School district
Continuing with the example in the Web filter section, you can use FortiGuard Web Filter
to protect students from inappropriate material. For the first part of this example, see “Web
filtering example” on page 838.

01-420-99686-20101026 855
FortiGuard Web Filter examples FortiGuard Web Filter
To enable FortiGuard Web Filter

2 Select the web filter profile named Students and choose Edit.
3 In the FortiGuard Web Filtering row, select both the HTTP and HTTPS options.
4 Select OK.
The Students web filter profile has FortiGuard Web Filter enabled, but all the categories
are set to Allow. With this configuration, no sites are blocked.
To configure the sites to block

2 Select the web filter profile named Students and choose Edit.
3 Expand the FortiGuard Web Filter section.
4 In the category table, select Block for these categories: Potentially Liable,
Controversial, and Potentially Non-productive.
The students will not be able to access any of the web sites in those three general
categories or the categories within them.

856 01-420-99686-20101026
Data leak prevention
The FortiGate data leak prevention (DLP) system allows you to prevent sensitive data
from leaving your network. When you define sensitive data patterns, data matching these
patterns will be blocked, logged, and archived, or any combination of these three actions,
when passing through the FortiGate unit. You configure the DLP system by creating
individual rules, combining the rules into DLP sensors, and then assigning a sensor to a
firewall policy.
Although the primary use of the DLP feature is to stop sensitive data from leaving your
network, it can also be used to prevent unwanted data from entering your network and to
archive some or all of the content passing through the FortiGate unit.
This section describes how to configure the DLP settings.
The following topics are included:
• Data leak prevention concepts
• Enable data leak prevention
• DLP archiving
• DLP examples
Data leak prevention concepts

Data leak prevention examines network traffic for data patterns you specify. You define
whatever patterns you want the FortiGate unit to look for in network traffic. The DLP
feature is broken down into a number of parts.
DLP sensor
A DLP sensor is a package of DLP rules and DLP compound rules. To use DLP you must
enable it in a firewall policy and select the DLP sensor to use. The traffic controlled by the
firewall policy will be searched for the patterns defined in the DLP sensor. Matching traffic
will be passed or blocked according to how you configured the DLP sensor and rules. You
can also log the matching traffic.
DLP rule
Each DLP rule includes a single condition and the type of traffic in which the condition is
expected to appear.
For example, the FortiGate DLP system includes a modifiable default rule consisting of a
regular expression that you can use to find messages matching U.S. Social Security
numbers (SSN). You can apply this sample DLP rule, called Email-US-SSN, to have the
FortiGate unit examine the Email protocols SMTP, IMAP, and POP3 for messages in
which the Body has Matches of the ASCII formatted Regular Expression of \b(?!000)([0-
6]\d{2}|7([0-6]\d|7[012]))([ -]?)(?!00) \d\d\3(?!0000)\d{4}(\b|\W).
DLP rules allow you to specify various conditions depending on the type of traffic for which
the rule is created. Table 67 on page 858 lists the available conditions by traffic type.

01-420-99686-20101026 857
Data leak prevention concepts Data leak prevention
Table 67: Conditions available by traffic type for DLP rules
Field Email HTTP HTTPS FTP NNTP IM

Always yes yes yes yes yes yes
Body yes yes - - yes -
Subject yes - - - - -
Sender yes - - - - yes
Receiver yes - - - - -
Attachment Size yes - - - - -
Attachment type yes - - - - -
Attachment text yes - - - - -
Transfer size yes yes - yes yes yes
Binary file pattern yes yes - yes yes yes
Authenticated User yes yes - yes yes yes
User group yes yes - yes yes yes
File is/is not encrypted yes yes - yes yes yes
URL - yes - - - -
Cookie - yes - - - -
CGI parameters - yes - - - -
HTTP header - yes - - - -
Hostname - yes - - - -
File type - yes - yes yes yes
File text - - - yes yes yes
Server - - - yes yes -
The HTTPS protocol is only available on FortiGate units that do not support SSL content
scanning and inspection. Units with SSL content scanning and inspection support include
HTTPS GET and HTTPS POST as options within the HTTP protocol.
DLP compound rule

Compound rules allow you to require that all the conditions specified in multiple DLP rules
are true before the action is taken. In this way, you can configure the FortiGate unit to
search for very specific conditions. For example, you can create a DLP sensor containing
two DLP rules, one that checks all email traffic for messages that have the word “credit” in
the subject, and one that checks all email traffic for messages from the sender
user43@example.com.
Multiple DLP rules in a DLP sensor are connected with a Boolean “or” operation. The
FortiGate unit will find a match in network traffic if the word “credit” appears in the
message subject, or if the message is from user43@example.com. If either condition is
true, a match is found.
If the same rules are added to a compound rule, and the compound rule is added to the
sensor, the rules in the compound are connected with a Boolean “and” operation. The
FortiGate unit will find a match in network traffic if the word “credit” appears in the
message subject and if the message is from user43@example.com. Both conditions must
be true before a match is found.

858 01-420-99686-20101026
Data leak prevention Enable data leak prevention
Enable data leak prevention

DLP examines your network traffic for data patterns you specify. You must configure DLP
in sequence.

1 Create one or more DLP rules.
DLP rules are the foundation of the data leak prevention feature. Each rule describes
the attributes of a type of sensitive data. The DLP feature uses this information to
detect sensitive data in network traffic.
2 Optionally, combine rules into compound rules.
When using individual rules, any matching rule triggers the action assigned to the rule.
Combining rules into a compound rule and using the compound rule changes their
behavior in that all the rules included in the compound rule must be true for the
assigned action to be triggered.
3 Create a DLP sensor.
New DLP sensors are empty. DLP sensors allow you to combine the DLP rules you’ve
created for different purposes.
4 Add one or more DLP rules and compound rules to the DLP sensor.
New sensors contain no rules and therefore will match no traffic. You must add one or
more rules and compound rules to a DLP sensor.
5 Add the DLP sensor to one or more firewall policies that control the traffic to be
examined.
Creating a DLP rule

The DLP rules define the data to be protected so the FortiGate unit can recognize it. For
example, the FortiGate default sensor rules include one that uses regular expressions to
describe the U.S. Social Security Number:
\b(?!000)([0-6]\d{2}|7([0-6]\d|7[012]))([ -]?)(?!00)
\d\d\3(?!0000)\d{4}(\b|\W)
Rather than having to list every possible Social Security Number, this regular expression
describes the structure of a Social Security Number. With the pattern, the FortiGate unit
recognizes any numbers that follow the pattern.
To create a DLP rule

1 Go to UTM > Data Leak Prevention > Rule.
3 In the Name field, enter the name of the new DLP rule.
4 Use the Protocol selection to choose the type of network traffic the FortiGate unit will
examine for the presence of the conditions in the DLP rule.
Changing the protocol can change the available sub-protocol and rule options.
If your FortiGate unit does not support SSL content scanning and inspection, HTTPS
will still be an available protocol selection. Although the contents of HTTPS traffic
cannot be examined, HTTPS traffic can be detected, allowed or denied, and logged. If

01-420-99686-20101026 859
Enable data leak prevention Data leak prevention
your FortiGate unit does support SSL content scanning and inspection, HTTPS POST
and HTTPS GET appear in the HTTP protocol. For more information, see “SSL content
scanning and inspection” on page 741.
5 Below the protocol selection, select the sub-protocols the FortiGate unit will examine
for the presence of the conditions in the DLP rule:
SMTP, IMAP, POP3 When you select the Email protocol, you can configure the rule to
apply to any or all of the supported email protocols (SMTP, IMAP,
and POP3).
SMTPS, IMAPS, POP3S When you select the Email protocol and your FortiGate unit
supports SSL content scanning and inspection, you can also
configure the rule to apply to SMTPS, IMAPS, POP3S or any
combination of these protocols.
HTTP POST, HTTP GET When you select the HTTP protocol, you can configure the rule to
apply to HTTP post traffic, HTTP get traffic, or both. traffic types.
HTTPS POST, HTTPS GET When you select the HTTP protocol and your FortiGate unit
supports SSL content scanning and inspection, you can also
configure the HTTP rule to apply to HTTPS get traffic, HTTPS post
traffic, or both traffic types.
To scan these encrypted traffic types, you must select Enable Deep
Scanning in the HTTPS section of the protocol options profile. If
Enable Deep Scanning is not selected, the DLP sensors will not
scan HTTPS content.
FTP PUT, FTP GET When you select the FTP protocol, you can configure the rule to
apply to FTP put traffic, FTP get traffic, or both traffic types.
AIM, ICQ, MSN, Yahoo! When you select the Instant Messaging protocol, you can configure
the rule to apply to file transfers using any or all of the supported IM
protocols (AIM, ICQ, MSN, and Yahoo!).
Only file transfers using the IM protocols are subject to DLP rules.
IM messages are not scanned.
6 If you select file or attachment rules in a protocol that supports it, you can select
various File options to configure how the DLP rule handles archive files, MS Word files,
and PDF files found in content traffic.
Scan archive contents When selected, files within archives are extracted and scanned in
the same way as files that are not archived.
Scan archive files whole When selected, archives are scanned as a whole. The files within
the archive are not extracted and scanned individually.
Scan MS-Word text When selected, the text contents of MS Word DOC documents are
extracted and scanned for a match. All metadata and binary
information is ignored.
Note: Office 2007/2008 DOCX files are not recognized as
MS-Word by the DLP scanner. To scan the contents of DOCX files,
select the Scan archive contents option.
Scan MS-Word file whole When selected, MS Word DOC files are scanned. All binary and
metadata information is included.
If you are scanning for text entered in a DOC file, use the
Scan MS-Word option. Binary formatting codes and file information
may appear within the text, causing text matches to fail.
Note: Office 2007/2008 DOCX files are not recognized as
MS-Word by the DLP scanner. To scan the contents of DOCX files,
select the Scan archive contents option.

860 01-420-99686-20101026
Scan PDF text When selected, the text contents of PDF documents are extracted
and scanned for a match. All metadata and binary information is
ignored.
Scan PDF file whole When selected, PDF files are scanned. All binary and metadata
information is included.
If you are scanning for text in PDF files, use the Scan PDF Text
option. Binary formatting codes and file information may appear
within the text, causing text matches to fail.
7 Select the Rule that defines the condition the FortiGate unit will search for.
Rule Description Protocol

Always This option will cause an automatic match of the Email, HTTP,
selected protocol and sub-protocols, regardless of HTTPS, FTP,
the contents of the network traffic itself. NNTP, IM,
Session Control
Attachment size Check the attachment file size. Email
Attachment text Search email attachments for the specified text. Email
Attachment type Search email attachments for file types or file Email
patterns as specified in the selected file filter.
Authenticated User Search for traffic from the specified authenticated Email, HTTP,
user. FTP, NNTP, IM
Binary file pattern Search for the specified binary string in network Email, HTTP,
traffic. FTP, NNTP, IM
Body Search for the specified string in the message or Email, HTTP,
page body. NNTP
CGI parameters Search for the specified CGI parameters in any HTTP
web page with CGI code.
Cookie Search the contents of cookies for the specified HTTP
text.
File is/not encrypted Check whether the file is or is not encrypted. Email, HTTP,
Encrypted files are archives and MS Word files FTP, NNTP, IM
protected with passwords. Because they are
password protected, the FortiGate unit cannot
scan their contents.
File text Search for the specified text in transferred text FTP, NNTP, IM
files.
File type Search for the specified file patterns and file HTTP, FTP,
types. The patterns and types are configured in NNTP, IM
file filter lists, and a list is selected in the DLP rule.
Hostname Search for the specified host name when HTTP
contacting an HTTP server.
HTTP header Search for the specified string in HTTP headers. HTTP
Receiver Search for the specified string in the message Email
recipient email address.
Sender Search for the specified string in the message Email, IM
sender user ID or email address.
For email, the sender is determined by the “From:”
address in the email header. For IM, all members
of an IM session are senders, and the senders are
determined by finding the IM user IDs in the
session.
Server Search for the server’s IP address in a specified FTP, NNTP
address range.
Subject Search for the specified string in the message Email
subject.

01-420-99686-20101026 861
Transfer size Check the total size of the information transfer. Email, HTTP,
For email traffic, for example, the transfer size FTP, NNTP, IM
includes the message header, body, and any
encoded attachment.
URL Search for the specified URL in HTTP traffic. HTTP
User group Search for traffic from any user in the specified Email, HTTP,
user group. FTP, NNTP, IM
8 Select the required rule operators, if applicable:
matches/does not match This operator specifies whether the FortiGate unit is searching for
the presence or absence of a specified string.
• Matches: The rule will be triggered if the specified string is
found in network traffic.
• Does not match: The rule will be triggered if the specified string
is not found in network traffic.
ASCII/UTF-8 Select the encoding used for text files and messages.
Regular Select the means by which patterns are defined.
Expression/Wildcard
is/is not This operator specifies if the rule is triggered when a condition is
true or not true.
• Is: The rule will be triggered if the rule is true.
• Is not: The rule will be triggered if the rule is not true.
For example, if a rule specifies that a file type is found within a
specified file type list, all matching files will trigger the rule.
Conversely, if the rule specifies that a file type is not found in a file
type list, only the file types not in the list would trigger the rule.
==/>=/<=/!= These operators allow you to compare the size of a transfer or
attached file to an entered value.
• == is equal to the entered value.
• >= is greater than or equal to the entered value.
• <= is less than or equal to the entered value.
• != is not equal to the entered value.
9 Enter the data pattern, if the rule type you selected requires it.
Most rules types end with a field or selection of the data pattern to be matched,
whether it is a file size, text string, email address, or file name.
10 Select OK.
Understanding the default DLP rules

A number of default DLP rules are provided with your FortiGate unit. You can use these as
provided, or modify them as required.
Note: These rules affect only unencrypted traffic types. If you are using a FortiGate unit that
can decrypt and examine encrypted traffic, you can enable those traffic types in these rules
to extend their functionality if required.
Caution: Before using the rules, examine them closely to ensure you understand how they
will affect the traffic on your network.

862 01-420-99686-20101026
All-Email, All-FTP, These rules will detect all email, FTP, HTTP, instant messaging, and
All-HTTP, All-IM, All-NNTP NNTP traffic.
Email-AmEx, These four rules detect American Express numbers, Canadian Social
Email-Canada-SIN, Insurance Numbers, U.S. Social Security Numbers, or Visa and
Email-US-SSN, Mastercard numbers within the message bodies of SMTP, POP3, and
IMAP email traffic.
Email-Visa-Mastercard
HTTP-AmEx, These four rules detect American Express numbers, Canadian Social
HTTP-Canada-SIN, Insurance Numbers, U.S. Social Security Numbers, or Visa and
HTTP-US-SSN, Mastercard numbers sent using the HTTP POST command. The
HTTP POST command is used to send information to a web server.
HTTP-Visa-Mastercard
As written, these rules are designed to detect data the user is sending
to web servers. This rule does not detect the data retrieved with the
HTTP GET command, which is used to retrieve web pages.
Large-Attachment This rule detects files larger than 5MB attached to SMTP, POP3, and
IMAP email messages.
Large-FTP-Put This rule detects files larger than 5MB sent using the FTP PUT
command. Files received using FTP GET are not examined.
Large-HTTP-Post This rule detects files larger than 5MB sent using the HTTP POST
command. Files received using HTTP GET are not examined.
Creating a compound DLP rule

DLP compound rules are groupings of DLP rules that also change the way they behave
when added to a DLP sensor. Individual rules can be configured with only a single
condition. When this condition is discovered in network traffic, the rule is activated.
Compound rules allow you to group individual rules to specify far more detailed activation
conditions. Each included rule is configured with a single condition, but the conditions of
every included rule must be detected before the compound rule is activated.
If only some of the conditions specified in the rules within a compound rule are detected,
the compound rule is not triggered.
To create a compound DLP rule

1 Go to UTM > Data Leak Prevention > Compound.
3 In the Name field, enter the name of the new DLP compound rule.
4 Use the Protocol selection to filter the available DLP rules based on their protocol
settings. For example, if you select the Email protocol, only the DLP rules configured
with the email protocol will appear for you to select.
5 Below the protocol selection, select the required sub-protocols to further restrict which
rules will appear for you to choose.
6 Select the first DLP rule to include in the compound rule from the Rule drop-down list.
7 Select the blue “plus” icon to add a second rule. Each subsequent rule will allow you to
add another so you can add as many DLP rules as you require. Similarly, the blue
“minus” icon allows you to delete the last added rule.
8 Select OK.
Creating a DLP sensor

DLP sensors are collections of DLP rules and DLP compound rules. You must also specify
an action for the rule or compound rule when you add it to a sensor. Once a DLP sensor is
configured, it can be selected in a firewall policy profile. Any traffic handled by the firewall
policy will be examined according to the DLP sensor configuration.

01-420-99686-20101026 863
To create a DLP sensor

1 Go to UTM > Data Leak Prevention > Sensor.
3 In the Name field, enter the name of the new DLP compound rule.
4 Optionally, you may also enter a comment. The comment appears in the DLP sensor
list and can remind you of the details of the sensor.
5 Select OK.
The DLP sensor is created and the sensor configuration window appears.
6 Select Enable Logging to have the FortiGate unit record details of DLP operation to the
DLP log.
7 Select Enable NAC Quarantine Logging to have the FortiGate unit record details of
DLP operation involving the ban and quarantine actions to the event log. This allows
you to be notified about NAC quarantine events by alert email if necessary. For this to
function correctly, the event log must be enabled with the NAC Quarantine event option
enabled.
8 Select OK.
A newly created sensor is empty, containing no rules or compound rules. Without rules,
the DLP sensor will do nothing.
Adding rules to a DLP sensor

Once you have created a DLP sensor, you need to add DLP rules.
To add rules to a DLP sensor

1 Go to UTM > Data Leak Prevention> Sensor.
2 Select the DLP sensor to which you want to add the rule and choose Edit.
4 Select the Action the FortiGate unit will take against network traffic matching the rule. A
number of actions are available:

864 01-420-99686-20101026
None The FortiGate unit will take no action on network traffic matching a
rule with this action. Other matching rules in the same sensor and
other sensors may still operate on matching traffic.
Block Traffic matching a rule with the block action will not be delivered. The
matching message or download is replaced with the data leak
prevention replacement message.
Exempt The exempt action prevents any DLP sensors from taking action on
matching traffic. This action overrides the action assigned to any
other matching sensors.
Ban If the user is authenticated, this action blocks all traffic to or from the
user using the protocol that triggered the rule and adds the user to
the Banned User list.
If the user is not authenticated, this action blocks all traffic of the
protocol that triggered the rule from the user’s IP address.
If the banned user is using HTTP, FTP, or NNTP (or HTTPS if the
FortiGate unit supports SSL content scanning and inspection) the
FortiGate unit displays the “Banned by data leak prevention”
replacement message for the protocol. If the user is using IM, the IM
and P2P “Banned by data leak prevention” message replaces the
banned IM message and this message is forwarded to the recipient.
If the user is using IMAP, POP3, or SMTP (or IMAPS, POP3S,
SMTPS if your FortiGate unit supports SSL content scanning and
inspection) the Mail “Banned by data leak prevention” message
replaces the banned email message and this message is forwarded
to the recipient. These replacement messages also replace all
subsequent communication attempts until the user is removed from
the banned user list.
Ban Sender This action blocks email or IM traffic from the sender of matching
email or IM messages and adds the sender to the Banned User list.
This action is available only for email and IM protocols. For email,
the sender is determined by the From: address in the email header.
For IM, all members of an IM session are senders and the senders
are determined by finding the IM user IDs in the session. Similar to
Ban, IM or Mail “Banned by data leak prevention” message replaces
the banned message and this message is forwarded to the recipient.
These replacement messages also replace all subsequent
communication attempts until the user is removed from the banned
user list.
Quarantine IP address This action blocks access for any IP address that sends traffic
matching a sensor with this action. The IP address is added to the
Banned User list. The FortiGate unit displays the “NAC Quarantine
DLP Message” replacement message for all connection attempts
from this IP address until the IP address is removed from the banned
user list.
Quarantine Interface This action blocks access to the network for all users connecting to
the interface that received traffic matching a sensor with this action.
The FortiGate unit displays the “NAC Quarantine DLP Message”
replacement message for all connection attempts to the interface
until the interface is removed from the banned user list.
Ban, Ban Sender, Quarantine IP, and Quarantine Interface provide functionality similar
to NAC quarantine. However, these DLP options block users and IP addresses at the
application layer while NAC quarantine blocks IP addresses and interfaces at the
network layer.
Caution: If you have configured DLP to block IP addresses and if the FortiGate unit
receives sessions that have passed through a NAT device, all traffic from that NAT
device—not just traffic from individual users—could be blocked. You can avoid this problem
by implementing authentication or, where possible, select Ban Sender.

01-420-99686-20101026 865
Tip: To view or modify the replacement message text, go to System > Config >
Replacement Message.
5 Select how traffic matching the rule will be archived.
Disable Do not archive network traffic matching the rule.

Summary Only Archive a summary of matching network traffic.
For example, if applied to a rule governing email, the information
archived includes the sender, recipient, message subject, message
size, and other details.
Full Archive the matching network traffic in addition to the summary
information. For example, full archiving of email traffic includes the
email messages and any attached files.
Note: Archiving requires a FortiAnalyzer device or a subscription to the FortiGuard Analysis

and Management Service.
6 If you selected one of the ban or quarantine actions, the Expires setting allows you to
choose how long the offending user/address/interface will remain on the banned user
list.
Select Indefinitely to keep the banned user entry in place until it is manually deleted.
Select After to enter the number of minutes, hours, or days, after which the banned
user entry is automatically deleted.
7 Choose the Severity rating to be attached to log entries created when network traffic
matches any rules in the sensor.
The severity setting has no effect on how DLP functions. It only affects DLP log entries
and the reports generated from the logs.
8 Select the type of rule you want to add to the DLP sensor using the Member type drop-
down list. You may choose either Rule or Compound rule, and the list below your
selection will display only the type you choose.
9 From the table, select the rule or compound rule to add to the DLP sensor.
10 Select OK.
The rule is added to the sensor. You may select Create New to add more rules, or select
OK to return to the DLP sensor list.
Understanding default DLP sensors

A number of default DLP sensors are provided with your FortiGate unit. You can use these
as provided, or modify them as you require.
Caution: Before use, examine the sensors and rules in the sensors closely to ensure you
understand how they will affect the traffic on your network.
Note: DLP prevents duplicate action. Even if more than one rule in a sensor matches some
content, DLP will not create more than one content archive entry, quarantine item, or ban
entry from the same content.

866 01-420-99686-20101026
Data leak prevention DLP archiving
Content_Archive All non-encrypted email, FTP, HTTP, IM, and NNTP traffic is archived
to a FortiAnalyzer unit or the FortiGuard Analysis & Management
Service. No blocking or quarantine is performed.
If you have a FortiGate unit that supports SSL content scanning and
inspection, you can modify this sensor to archive encrypted traffic as
well.
Content_Summary A summary of all non-encrypted email, FTP, HTTP, IM, and NNTP
traffic is saved to a FortiAnalyzer unit or the FortiGuard Analysis &
Management Service. No blocking or quarantine is performed.
If you have a FortiGate unit that supports SSL content scanning and
inspection, you can modify this sensor to archive a summary of
encrypted traffic as well.
Credit-Card The number formats used by American Express, Visa, and Mastercard
credit cards are detected in HTTP and email traffic.
As provided, the sensor is configured not to archive matching traffic
and an action of None is set. Configure the action and archive options
that you require.
Large-File Files larger than 5MB will be detected if attached to email messages or
if send using HTTP or FTP.
that you require.
SSN-Sensor The number formats used by U.S. Social Security and Canadian
Social Insurance numbers are detected in email and HTTP traffic.
that you require.
DLP archiving
DLP is typically used to prevent sensitive information from getting out of your company
network, but it can also be used to record network use. This is called DLP archiving. The
DLP engine examines email, FTP, IM, NNTP, and web traffic. Enabling archiving for rules
when you add them to sensors directs the FortiGate unit to record all occurrences of these
traffic types when they are detected by the sensor.
Since the archive setting is configured for each rule in a sensor, you can have a single
sensor that archives only the things you want.
DLP archiving comes in two forms: Summary Only, and Full.
Summary archiving records information about the supported traffic types. For example,
when an email message is detected, the sender, recipient, message subject, and total size
are recorded. When a user accesses the Web, every URL the user visits recorded. The
result is a summary of all activity the sensor detected.
For more detailed records, full archiving is necessary. When an email message is
detected, the message itself, including any attachments, is archived. When a user
accesses the Web, every page the user visits is archived. Far more detailed than a
summary, full DLP archives require more storage space and processing.
Because both types of DLP archiving require additional resources, DLP archives are
saved to a FortiAnalyzer unit or the FortiGuard Analysis and Management Service
(subscription required).
Two sample DLP sensors are provided with DLP archiving capabilities enabled. If you
select the Content_Summary sensor in a firewall policy, it will save a summary DLP
archive of all traffic the firewall policy handles. Similarly, the Content_Archive sensor
will save a full DLP archive of all traffic handled the firewall policy you apply it to. These
two sensors are configured to detect all traffic of the supported types and archive them.

01-420-99686-20101026 867
DLP examples Data leak prevention
DLP examples
Configuring DLP content archiving
This example details how to enable DLP content archiving on a FortiGate unit located in a
satellite office. With this DLP sensor selected in a firewall policy, all email, FTP, HTTP, IM,
and NNTP traffic controlled by the policy is saved to your FortiAnalyzer unit. This example
assumes the FortiGate unit is configured to send all logs to a FortiAnalyzer unit or to the
FortiGuard Analysis and Management Service.
Using the DLP content archive sensor

DLP sensors are created by selecting DLP rules. Each rule specifies a condition and an
action. When the condition is true, the action is taken.
Your FortiGate unit comes with a sample DLP sensor that generates a DLP content
archive of all email, FTP, HTTP, IM, and NNTP traffic.
Selecting the DLP sensor in a firewall policy

A DLP sensor directs the FortiGate unit to scan network traffic only when it is selected in a
firewall policy. When a DLP sensor is selected in a firewall policy, its settings are applied to
all the traffic the firewall policy handles.
To select the DLP content archive sensor in a firewall policy — web-based manager
2 Select a policy and choose the Edit icon.
3 Enable UTM.
4 Select the Enable DLP Sensor option.
DLP can not be enabled without selecting a protocol options profile. A default profile is
provided.
6 Select the Content_Archive sensor from the list.

edit 1
set dlp-sensor Content_Archive
end
All email, FTP, HTTP, IM, and NNTP traffic handled by the firewall policy you modified will
be archived. A small office may have only one firewall policy configured. If you have
multiple policies, select the Content_Archive sensor in every policy you want archived.
Blocking sensitive email messages

Someone in the Example.com corporation has been sending copies of the company
president’s monthly update email messages to the press. These messages have included
the full header. Rather than try to block them, the IT department at Example.com will find
out who is sending the messages using DLP.

868 01-420-99686-20101026
Data leak prevention DLP examples
All messages include the text From: president@example.com and Subject: XYZ
Monthly Update where XYZ is the month the update applies to.
You will create a rule for the email address and a rule for the subject, combine them in a
compound rule, and add the compound rule to a DLP sensor. You will then add the DLP
sensor to the firewall policy that controls outgoing email traffic.
To create the “address” rule

3 In the Name field, enter President address.
4 In the Comments field, enter Finds “president@example.com” in email.
5 For Protocol, select Email.
6 Select the SMTP, IMAP, and POP3 check boxes.
7 Select the Body rule.
8 For the three drop-down menus in the Body row, select, matches, ASCII, and Wildcard.
9 In the final field in the Body row, enter president@example.com
10 Select OK to save the rule.
To create the “subject rule”

3 In the Name field, enter President subject.
4 In the Comments field, enter Finds “XYZ Monthly Update” in email.
7 Select the Body rule.
8 For the three drop-down menus in the Body row, select, matches, ASCII, and Wildcard.
9 In the final field in the Body row, enter * Monthly Update
The asterisk (‘*’) can represent any characters so the rule will match any monthly
update.
10 Select OK to save the rule.
Adding these two rules to a DLP sensor may generate a large number of false positives
because any rule in a sensor will trigger the action. If the action were to log messages
matching the address and subject rules in this example, then left as individual rules, the
DLP sensor would log Monthly Updates from any employee and log all the president’s
email messages. In this case, you only want to know when both rules are true for a single
message. To do this, you must first add the rules to a compound rule.
To create the “president + subject” compound rule.

1 Go to UTM > Data Leak Prevention > Compound.
3 In the Name field, enter President + subject.

01-420-99686-20101026 869
DLP examples Data leak prevention
6 In the Rules drop-down menu, select President address.

7 Select the blue Add Rule button.
8 In the second Rules drop-down menu, select President subject.
9 Select OK to save this compound rule.
To create the “president” DLP sensor

1 Go to UTM > Data Leak Prevention > Sensor.
3 In the Name field, enter president.
4 In the Comments field, enter Finds “president@example.com” and “XYZ
Monthly Update” in email.
5 Select OK to save the new sensor.
6 Select Enable Logging so the activity of this sensor will be logged.
7 Select Create New to add a rule to the sensor.
8 Set the Action to None.
9 Set Member type to Compound rule.
10 Select the President + subject rule.
11 Select OK.
With the DLP sensor ready for use, you need to select it in the firewall policy.
To select the DLP sensor in the firewall policy

2 Select the firewall policy that controls outgoing email traffic.
4 Enable UTM.
provided.
6 Select the Enable DLP Sensor option.
7 Select the president sensor from the list.
With the DLP sensor specified in the correct firewall policy, any email message with both
president@example.com and Monthly Update in the message body will trigger the sensor
and a DLP log entry will be created. The sender IP address is recorded and this will
indicate which computer was used to send the message.

870 01-420-99686-20101026
Application control
Using the application control UTM feature, your FortiGate unit can detect and take action
against network traffic depending on the application generating the traffic. Based on
FortiGate Intrusion Protection protocol decoders, application control is a user-friendly and
powerful way to use Intrusion Protection features to log and manage the behavior of
application traffic passing through the FortiGate unit. Application control uses IPS protocol
decoders that can analyze network traffic to detect application traffic even if the traffic
uses non-standard ports or protocols.
The FortiGate unit can recognize the network traffic generated by a large number of
applications. You can create application control lists that specify the action to take with the
traffic of the applications you need to manage and the network on which they are active,
and then add application control lists to the firewall policies that control the network traffic
you need to monitor.
This section describes how to configure the application control settings.
If you enable virtual domains (VDOMs) on the Fortinet unit, you need to configure
application control separately for each virtual domain.
• Application control concepts
• Enable application control
• Application traffic shaping
• Application control monitor
• Application control packet logging
• Application considerations
• Application control examples
Application control concepts

You can control network traffic generally by the source or destination address, or by the
port, the quantity or similar attributes of the traffic itself in the firewall policy. If you want to
control the flow of traffic from a specific application, these methods may not be sufficient to
precisely define the traffic. To address this problem, the application control feature
examines the traffic itself for signatures unique to the application generating it. Application
control does not require knowledge of any server addresses or ports. The FortiGate unit
includes signatures for over 1000 applications, services, and protocols.
Updated and new application signatures are delivered to your FortiGate unit as part of
your FortiGuard Application Control Service subscription. Fortinet is constantly increasing
the number of applications that application control can detect by adding applications to the
FortiGuard Application Control Database. Because intrusion protection protocol decoders
are used for application control, the application control database is part of the FortiGuard
Intrusion Protection System Database and both of these databases have the same
version number.
To view the version of the application control database installed on your FortiGate unit, go
to the License Information dashboard widget and find the IPS Definitions version.

01-420-99686-20101026 871
Enable application control Application control
To see the complete list of applications supported by FortiGuard Application Control go to

the FortiGuard Application Control List. This web page lists all of the supported
applications. You can select any application name to see details about the application.
Enable application control

Application control examines your network traffic for traffic generated by the applications
you want it to control.

1 Create an application control list.
2 Configure the list to include the signatures for the application traffic you want the
FortiGate unit to detect. Configure each entry to allow or pass the traffic, and optionally
log the traffic.
3 Enable UTM and application control in a firewall policy and select the application
control list.
Creating an application control list

You need to create an application control list before you can enable application control.
To create an application control list

3 In the Name field, enter the name of the new application control list.
4 Optionally, you may also enter a comment.
5 Select OK.
The application control list is created and the list configuration window appears. A newly
created application control list is empty. Without applications, the application control list
will have no effect.
Adding applications to an application control list

Once you have created an application control list, you need to need to define the
applications that you want to control.
To add applications to an application control list

2 Select an application control list and choose Edit.
4 Using the Category selection, choose the type of application you want to add. For
example, if you want to add Facebook chat, choose im.
The Category selection displays only the options available in the Application selection.
If you want to see all the applications listed, leave Category set to All Categories.

872 01-420-99686-20101026
Application control Enable application control
5 Using the Application selection, choose the application you want to add.
The application available to you will be limited to those in the category you selected. If
you want to include all the applications in a category, leave Application set to
All Applications.
6 Select the Action the FortiGate unit will take when it detects network traffic from the
application:
• Block will stop all traffic from the application.
• Pass allows the application traffic to flow normally.
If you set the action to Pass, you have the option of enabling traffic shaping for the
application or applications specified in this application list entry. For more information
about application control traffic shaping, see “Application traffic shaping” on page 874
7 Enable Session TTL to specify a time-to-live value for the session, in seconds. If this
option is not enabled, the TTL defaults to the setting of the CLI command config
system session-ttl.
8 Select Enable Logging to have the FortiGate unit log the occurrence and action taken
when traffic from the application is detected.
9 Select Enable Packet Log to have the FortiGate unit save the packets that application
control used to determine the traffic came from the application.
10 Some applications have additional options:
IM Options (for example AIM)

Block Login Select to prevent users from logging in to the selected
IM system.
Block File Transfers Select to prevent the sending and receiving of files
using the selected IM system.
Block Audio Select to prevent audio communication using the
selected IM system.
Inspect Non-standard Port Select to allow the FortiGate unit to examine
nonstandard ports for the IM client traffic.
Display DLP meta-information on Select to include meta-information detected for the IM
the system dashboard system on the FortiGate unit dashboard.
Other Options
Command Some traffic types include a command option. These
include FTP.Command, NNTP.Command,
POP3.Command, and SMTP.Command. Specify a
command that appears in the traffic that you want to
block or pass.
For example, enter GET as a command in the
FTP.Command application to have the FortiGate unit
examine FTP traffic for the GET command. Multiple
commands can be entered.
Method A method option is available for HTTP, RTSP, and SIP
protocols. Specify a method that appears in the traffic
that you want to block or pass.
For example, enter POST as a method in the
HTTP.Method application to have the FortiGate unit
examine HTTP traffic for the POST method. Multiple
methods can be entered.
Program Number Enter the program number appearing in Sun Remote
Procedure Calls (RPC) that you want to block or pass.
Multiple program numbers can be entered.
UUID Enter the UUID appearing in Microsoft Remote
Procedure Calls (MSRPC) that you want to block or
pass. Multiple UUIDs can be entered.

01-420-99686-20101026 873
Application traffic shaping Application control
Understanding the default application control lists

A number of default application control lists are provided with your FortiGate unit. You can
use these as provided, or modify them as required.
Caution: Before using the default application control lists, examine them closely to ensure
you understand how they will affect the traffic on your network.
block-p2p This list blocks the applications in the P2P category and allow all other
application traffic.
monitor-all This list allows all application traffic and enables the application
control monitoring for all traffic. Only FortiGate units with a hard drive
support application monitoring.
monitor-p2p-and-media This list allows all application traffic, and enables the application
control monitoring for the applications in the P2P and media
categories. Only FortiGate units with a hard drive support application
monitoring.
Application traffic shaping

You can apply traffic shaping for application list entries you configure to pass. Traffic
shaping enables you to limit or guarantee the bandwidth available to the application or
applications specified in an application list entry. You can also prioritize traffic by using
traffic shaping.
When the action is set to Pass, two options appear: Traffic Shaping and Reverse Direction
Traffic Shaping. When enabled, you can select traffic shapers configured in Firewall >
Traffic Shaper.
You can create or edit traffic shapers by going to Firewall > Traffic Shaper > Shared.
Per-IP traffic shapers are not available for use in application control traffic shaping.
For more information about traffic shaping, see “Traffic shaping methods” on page 1821.
Enabling application control traffic shaping

Enabling traffic shaping in an application control list entry involves selecting the required
shaper. You can create or edit shapers in Firewall > Traffic Shaper > Shared.
To enable traffic shaping

2 Select the application control list and choose Edit.
3 Select the application control list entry and choose Edit.
4 Select Traffic Shaping and choose the required traffic shaper from the list.
If the action is set to Block, the traffic shaping option is not available. Only allowed
traffic can be shaped.
5 Select Reverse Direction Traffic Shaping and choose the required traffic shaper from
the list if traffic flowing in the opposite direction also requires shaping.
6 Select OK.
Any firewall policy with this application control list selected will shape application traffic
according to the applications specified in the list entry and the shaper configuration.

874 01-420-99686-20101026
Application control Application traffic shaping
Reverse direction traffic shaping

To enable traffic shaping, you must set the action to Pass, enable Traffic Shaping and then
choose the shaper. This will apply the shaper configuration to the application traffic
specified in the entry, but only in the direction as specified in the firewall policy in which the
application control list is selected. To shape traffic travelling in the opposite direction,
enable Reverse Direction Traffic Shaper.
For example, if you find that your network bandwidth is being overwhelmed by streaming
HTTP video, one solution is to limit the bandwidth by applying a traffic shaper to an
application control entry that allows the HTTP.Video application. Your users access the
Web using a firewall policy that allows HTTP traffic from the internal interface to the
external interface. Firewall policies are required to initiate communication so even though
web sites respond to requests, a policy to allow traffic from the external interface to the
internal interface is not required for your users to access the Web. The internal to external
policy allows them to open communication sessions to web servers, and the external
servers can reply using the existing session.
If you enable Traffic Shaping and select the shaper in an application control list specified
in the firewall policy, the problem will continue. The reason is the shaper you select for
Traffic Shaping is applied only to the application traffic moving in the direction stated in the
firewall policy. In this case, that is from the internal interface to the external interface. The
firewall policy allows the user to visit the web site and start the video, but the video itself is
streamed from the server to the user, or from the external interface to the internal
interface. This is the reverse of the direction specified in the firewall policy. To solve the
problem, you must enable Reverse Direction Traffic Shaping and select the shaper.
Shaper re-use
Shapers are created independently of firewall policies and application control lists so you
are free to reuse the same shapers in multiple list entries and policies. Shared shapers
can be configured to apply separately to each firewall policy or across all policies. This
means that if a shaper is configured to guaranteed 1000 KB/s bandwidth, each firewall
policy using the shaper will have its own 1000 KB/s reserved, or all of the policies using
the shaper will share a pool if 1000 KB/s, depending on how it is configured.
The same thing happens when a shaper is used in application control list entries. If an
application control list using a shaper is applied to two separate policies, how the
bandwidth is limited or guaranteed depends on whether the shaper is set to apply
separately to each policy or across all policies. In fact, if a shaper is applied directly to one
firewall policy, and it is also included in an application control list that is applied to another
firewall policy, the same issue occurs. How the bandwidth is limited or guaranteed
depends on the shaper configuration.
If a shaper is used more than once within a single application control list, all of the
applications using the shaper are restricted to the maximum bandwidth or share the same
guaranteed bandwidth.
For example, you want to limit the bandwidth used by Skype and Facebook chat to no
more than 100 KB/s. Create a shaper, enable Maximum Bandwidth, and enter 100. Then
create an application control list with and entry for Skype and another entry for Facebook
chat. Apply the shaper to each entry and select the application control list in the firewall
policy that allows your users to access both services.
This configuration uses the same shaper for each entry, so Skype and Facebook chat
traffic are limited to no more than 100 KB/s in total. That is, traffic from both applications is
added and the total is limited to 100 KB/s. If you want to limit Skype traffic to 100 KB/s and
Facebook chat traffic to 100 KB/s, you must use separate shapers for each application
control entry.

01-420-99686-20101026 875
Application control monitor Application control
Application control monitor

The application monitor enables you to gain an insight into the applications generating
traffic on your network. When monitor is enabled in an application control list entry and the
list is selected in a firewall policy, all the detected traffic required to populate the selected
charts is logged to the SQL database on the FortiGate unit hard drive. The charts are
available for display in the executive summary section of the log and report menu.
Note: Because the application monitor relies on a SQL database, the feature is
available only on FortiGate units with an internal hard drive.
While the monitor charts are similar to the top application usage dashboard widget, it
offers several advantages. The widget data is stored in memory so when you restart the
FortiGate unit, the data is cleared. Application monitor data is stored on the hard drive and
restarting the system does not affect old monitor data.
Application monitor allows you to choose to compile data for any or all of three charts: top
ten applications by bandwidth use, top ten media users by bandwidth, and top ten P2P
users by bandwidth. Further, there is a chart of each type for the traffic handled by each
firewall policy with application monitor enabled. The top application usage dashboard
widget shows only the bandwidth used by the top applications since the last system
restart.
Enabling application control monitor

Once you have configured and enabled application control, you can enable application
monitor. There are three steps, as detailed below: enabling application monitor in an
application control list, selecting the charts in the firewall policy, and displaying the charts
in the Executive Summary.
To enable application control monitor in an application control list

2 Select the application control list and choose Edit.
3 Select Enable Monitoring.
4 Select OK.
With application control monitoring enabled, the FortiGate unit begins collecting data for
the applications specified in the application control list from the traffic handled by all
policies using the list. If you require monitoring in other application control lists, follow the
same procedure to enable it in each list.
To configure the charts for which data is collected

2 Select the firewall policy in which the application control list is selected and choose
Edit. Note the firewall policy ID number.
3 Under UTM, the Enable Application Control selection has three new options, one for
each chart type. Select one or more chart types.
4 Select OK.
5 If you have the application control list specified in multiple firewall policies, repeat this
procedure for each policy.
For more information about executive summary charts, see “Executive Summary reports”
on page 621.

876 01-420-99686-20101026
Application control Application control packet logging
To display the application monitor charts

2 Select Add Widget.
3 Select the chart you want from the Widgets list.
The three application monitor charts correspond to the three chart selections in the
firewall policy. They are listed in the list as:
• top10-application-bw-X-0
• top10-media-user-X-0
• top10-p2p-user-bw-X-0
If you have application monitor enabled in multiple firewall policies, one chart of each
type per policy will be available for you to choose. The ‘X’ in the chart name is the
firewall policy number.
4 Select a Daily or Weekly schedule. The chart will display the data collected from only
the current day or current week, depending on the setting. The chart will be reset daily
on the hour specified, or weekly on the hour and day specified.
5 Select OK.
Application control packet logging

Packet logging saves the network packets that application control identifies application
traffic with. These packets can be used to trouble-shoot false positives or for forensic
investigation.The FortiGate unit saves the logged packets to the attack log, wherever the
logs are configured to be stored, whether memory, internal hard drive, a FortiAnalyzer
unit, or the FortiGuard Analysis and Management Service.
You can enable packet logging in individual application list entries. Use caution in enabling
packet logging. Application control list entries configured with few restrictions can contain
hundreds of applications, potentially resulting in a flood of saved packets. This would take
up a great deal of space, require time to sort through, and consume considerable system
resources to process. Packet logging is designed as a focused diagnostic tool and is best
used with a narrow scope.
Caution: Although logging to multiple FortiAnalyzer units is supported, packet logs are not
sent to the secondary and tertiary FortiAnalyzer units. Only the primary unit receives packet
logs.
To enable application control packet logging

1 Create an entry in an application control list. For more information, see “Adding
applications to an application control list” on page 872.
2 Before saving the entry, select Enable Packet Log.
3 Select the application control list in the firewall policy that allows the network traffic the
FortiGate unit will examine for the application or applications.
For information on viewing and saving logged packets, see “Viewing and saving logged
packets” on page 745.

01-420-99686-20101026 877
Application considerations Application control
Application considerations
Some applications behave differently from most others. You should be aware of these
differences before using application control to regulate their use.
IM applications
Application control regulates most instant messaging applications by preventing or
allowing user access to the service. Selecting Block Login will not disconnect users who
are logged in when the change is made. Once they log themselves out, however, they will
not be able to log in again.
Skype
Based on the NAT firewall type, Skype takes advantage of several NAT firewall traversal
methods, such as STUN (Simple Traversal of UDP through NAT), ICE (Interactive
Connectivity Establishment) and TURN (Traversal Using Relay NAT), to make the
connection.
The Skype client may try to log in with either UDP or TCP, on different ports, especially
well-known service ports, such as HTTP (80) and HTTPS (443), because these ports are
normally allowed in firewall settings. A client who has previously logged in successfully
could start with the known good approach, then fall back on another approach if the known
one fails.
The Skype client could also employ Connection Relay. This means if a reachable host is
already connected to the Skype network, other clients can connect through this host. This
makes any connected host not only a client but also a relay server.
Application control examples

Blocking all instant messaging
Instant messaging use is not permitted at the Example Corporation. Application control
helps enforce this policy.
First you will create an application control list with a single entry that includes all instant
messaging applications. You will set the list action to block.
To create the application control list

3 In the Name field, enter no IM for the application control list name.
4 Select OK.
5 Select Create New to add a new list entry.
6 For Category, select im.
7 For Action, select Block.
8 Select OK to save the new list entry.
9 Select OK to save the list.
Next you will enable application control and select the list.

878 01-420-99686-20101026
Application control Application control examples
To enable application control and select the application control list

2 Select the firewall policy that allows the network users to access the Internet and
choose Edit.
3 Enable UTM.
4 Select Enable Application Control.
5 Select the no IM application control list.
6 Select OK.
No IM use will be allowed by the firewall policy. If other firewall policies handle traffic that
users could use for IM, enable application control with the no IM list for those as well.
Allowing only software updates

Some departments at Example Corporation do not require access to the Internet to
perform their duties. Management therefore decided to block their Internet access.
Software updates quickly became an issue because automatic updates will not function
without Internet access and manual application of updates is time-consuming.
The solution is configuring application control to allow only automatic software updates to
access the Internet.
To create an application control list — web-based manager

3 In the Name field, enter Updates_Only as the application control list name.
4 Select OK.
6 Select update from the Category list.
7 Select Pass from the Action list.
8 Select OK to save the entry.
This application list entry will allow all software update application traffic.
9 Select the All Other Known Applications entry.
10 Select Edit.
12 Select OK.
This application list entry will block all traffic from recognized applications that are not
specified in this application control list.
13 Select the All Other Unknown Applications entry.
14 Select Edit.
16 Select OK.
This application list entry will block all traffic from applications that are not recognized
by the application control feature.
17 Select OK.
18 Select OK to save the application control list.

01-420-99686-20101026 879
Application control examples Application control
To create an application control list — CLI

config application list
edit Updates_Only
config entries
edit 1
set category 17
set action pass
end
set other-application-action block
set unknown-application-action block
end
Selecting the application control list in a firewall policy

An application control list directs the FortiGate unit to scan network traffic only when it is
selected in a firewall policy. When an application control list is selected in a firewall policy,
its settings are applied to all the traffic the firewall policy handles.
To select the application control list in a firewall policy — web-based manager

2 Select a policy.
4 Enable UTM.
5 Select the Enable Application Control option.
6 Select the Updates_only list.
Application control can not be enabled without selecting a protocol options profile. A
default profile is provided.
8 Select OK.
To select the application control list in a firewall policy — CLI

edit 1
set application-list Updates_Only
end
Traffic handled by the firewall policy you modified will be scanned for application traffic.
Software updates are permitted and all other application traffic is blocked.

880 01-420-99686-20101026
DoS policy
Denial of Service (DoS) policies are primarily used to apply DoS sensors to network traffic
based on the FortiGate interface it is entering as well as the source and destination
addresses. DoS sensors are a traffic anomaly detection feature to identify network traffic
that does not fit known or common traffic patterns and behavior. A common example of
anomalous traffic is the denial of service attack. A denial of service occurs when an
attacking system starts an abnormally large number of sessions with a target system. The
large number of sessions slows down or disables the target system, so that legitimate
users can no longer use it.
This section describes how to create and configure DoS sensors and policies to protect
the publicly accessible servers on your network.
• DoS policy concepts
• Enable DoS
• DoS example
DoS policy concepts

DoS policies are similar to firewall policies except that instead of defining the way traffic is
allowed to flow, they keep track of certain traffic patterns and attributes and will stop traffic
displaying those attributes. Further, DoS policies affect only incoming traffic on a single
interface. You can further limit a DoS policy by source address, destination address, and
service.
DoS policies examine network traffic very early in the sequence of protective measures
the FortiGate unit deploys to protect your network. Because of this early detection, DoS
policies are a very efficient defence that uses few resources. Denial of service attacks, for
example, are detected and its packets dropped before requiring firewall policy look-ups,
antivirus scans, and other protective but resource-intensive operations. For more
information about DoS attacks, see “Defending against DoS attacks” on page 753.
Enable DoS
A DoS policy examines network traffic arriving at an interface for anomalous patterns
usually indicating an attack. Enable DoS sensors to protect your FortiGate unit from
attack. To apply a DoS policy, you must follow the steps below in sequence:
1 Create a DoS sensor.
2 Create a DoS policy
3 Apply the DoS sensor to the DoS policy.
Creating and configuring a DoS sensor

Because an improperly configured DoS sensor can interfere with network traffic, no DoS
sensors are present on a factory default FortiGate unit. You must create your own and
then enable them before they will take effect. Thresholds for newly created sensors are
preset with recommended values that you can adjust to meet the needs of your network.

01-420-99686-20101026 881
Enable DoS DoS policy
Note: It is important to know normal and expected network traffic before changing the
default anomaly thresholds. Setting the thresholds too low could cause false positives, and
setting the thresholds too high could allow otherwise avoidable attacks.
To create a DoS sensor

3 In the Name field, enter the name of the DoS sensor.
4 Optionally, enter a description of the DoS sensor in the Comment field.
5 Select OK.
The DoS sensor is created and the sensor configuration window appears. However, a
newly created DoS sensor contains default values which may not be appropriate for your
network. You can adjust these values by configuring the DoS sensor thresholds.
To configure a DoS sensor

2 Select the DoS sensor you want to configure and choose Edit.
3 The DoS sensor configuration window appears.
The Anomalies Configuration table lists 12 types of network anomalies.
Anomaly Description
tcp_syn_flood If the SYN packet rate of new TCP connections, including
retransmission, to one destination IP address exceeds the configured
threshold value, the action is executed. The threshold is expressed in
packets per second.
tcp_port_scan If the SYN packet rate of new TCP connections, including
retransmission, from one source IP address exceeds the configured
packets per second.
tcp_src_session If the number of concurrent TCP connections from one source IP
address exceeds the configured threshold value, the action is executed.
tcp_dst_session If the number of concurrent TCP connections to one destination IP
udp_flood If the UDP traffic to one destination IP address exceeds the configured
packets per second.
udp_scan If the number of UDP sessions originating from one source IP address
exceeds the configured threshold value, the action is executed. The
threshold is expressed in packets per second.
udp_src_session If the number of concurrent UDP connections from one source IP
udp_dst_session If the number of concurrent UDP connections to one destination IP
icmp_flood If the number of ICMP packets sent to one destination IP address
icmp_sweep If the number of ICMP packets originating from one source IP address

882 01-420-99686-20101026
DoS policy Enable DoS
icmp_src_session If the number of concurrent ICMP connections from one source IP

icmp_dst_session If the number of concurrent ICMP connections to one destination IP
4 Select Enable to have the FortiGate unit examine traffic for the anomaly.
5 Select Logging to create an entry in the attack log if the anomaly is detected.
6 Select an Action for the anomaly. By default, the action is Pass, which allows the traffic
containing the anomaly to pass uninterrupted. If set to Block, the anomalous traffic is
blocked and will not flow through the FortiGate unit.
With a Fortinet security processing module installed, FortiGate units that support these
modules offer a third action for the tcp_syn_flood threshold. In addition to Block
and Pass, you can choose to Proxy connect attempts when their volume exceeds the
threshold value. When the tcp_syn_flood threshold action is set to Proxy,
incomplete TCP connections are allowed as normal as long as the configured
threshold is not exceeded. If the threshold is exceeded, the FortiGate unit will intercept
incoming SYN packets with a hardware accelerated SYN proxy to determine whether
the connection attempts are legitimate or a SYN flood attack. Legitimate connections
are allowed while an attack is blocked.
Note: Because DoS sensors are configured before being applied to an interface, you can
assign a DoS sensor with the Proxy action to an interface that does not have hardware
SYN proxy support. In this circumstance, the Proxy action is invalid and a Pass action will
be applied.
7 Set the Threshold value for the anomaly. See the table in step 3 for details about the
threshold values for each anomaly.
8 Select OK.
Creating a DoS policy

DoS policies examine network traffic entering an interface. The DoS sensor specified in
the DoS policy allows you to limit certain anomalous traffic to protect against attacks.
To create a DoS policy

1 Go to Firewall > Policy > DoS Policy and select Create New.
2 For Source Interface/Zone, select the interface on which the DoS policy will examine
incoming traffic.
3 For Source Address, select the address or address group that defines the source
addresses of the traffic the DoS policy will examine. Network traffic from addresses not
included in the selected address group is ignored by this DoS policy.
4 For Destination Address, select the address or address group that defines the
destination addresses of the traffic the DoS policy will examine. Network traffic to
addresses not included in the selected address group is ignored by this DoS policy.
5 For Service, select the type of network traffic the DoS policy will examine. Protocols not
included in the selected service or service group are ignored by this DoS policy.
6 Select the DoS Sensor check box and choose the required sensor from the list.
7 Select OK.

01-420-99686-20101026 883
DoS example DoS policy
Apply an IPS sensor to a DoS policy

Although IPS sensors are usually applied to firewall policies, you can also apply them to
DoS policies by using CLI commands. There are two reasons you might want to apply an
IPS sensor to a DoS policy:
• If you want to have all traffic coming into one FortiGate unit interface checked for the
signatures in an IPS sensor, it is simpler to apply the IPS sensor once to a DoS policy.
In a complex configuration, there could be many policies controlling the traffic coming
in on a single interface.
• The operations in a DoS policy occur much earlier in the sequence of operations
performed on incoming traffic. This means that IPS examination of traffic occurs much
sooner if the IPS sensor is applied to a DoS policy. Fewer system resources are used
because signatures set to block traffic will take effect before firewall policy checking
and all of the scans specified in the firewall policy.
The CLI command for configuring DoS policies is config firewall
interface-policy. The following command syntax shows how to add an example IPS
sensor called all_default_pass to a DoS policy with policy ID 5 that was previously
added from the web-based manager.
edit 5
set ips-sensor all_default_pass
end
DoS example
The Example.com corporation installed a web server and connected it to Port5 on its
FortiGate unit. To protect against denial of service attacks, you will configure and apply a
DoS sensor to protect the web server.
To create the DoS sensor

3 Enter Web Server in the Name field.
4 In the Anomalies Configuration table, select the Enable check box in the table heading.
This enables all the anomalies with a single selection.
5 Select OK to save the new DoS policy.
As suggested in “Defending against DoS attacks” on page 753, the IT administrators will
run the DoS policy with logging enabled and the anomaly actions set to Pass until they
determine the correct threshold values for each anomaly.
To create a DoS policy

1 Go to Firewall > Policy > DoS Policy.
3 In the Source Interface/Zone field, select Port1 which is the interface connected to the
Internet.
4 In the Source Address field, select all.

884 01-420-99686-20101026
DoS policy DoS example
5 In the Destination Address field, select all.

If there were more than one publicly accessible server connected to the FortiGate unit,
you would specify the address of the web server in this field.
6 In the Service field, select ANY.
7 Select the DoS Sensor check box and choose Web Server from the list.
8 Select OK to save the DoS policy.
The DoS policy will monitor all network traffic entering Port1 and log the violations if the
thresholds in the Web Server DoS sensor are exceeded.

01-420-99686-20101026 885
DoS example DoS policy

886 01-420-99686-20101026
Sniffer policy
Sniffer policies are used to configure a physical interface on the FortiGate unit as a one-
arm intrusion detection system (IDS). Traffic sent to the interface is examined for matches
to the configured IPS sensor and application control list. Matches are logged and then all
received traffic is dropped. Sniffing only reports on attacks. It does not deny or otherwise
influence traffic.
This section describes how to configure your network topology to use the FortiGate unit as
a one-arm intrusion detection system. It also describes how to configure and enable a
sniffer policy.
• Sniffer policy concepts
• Enable one-arm sniffing
• Sniffer example
Sniffer policy concepts

Using the one-arm intrusion detection system (IDS), you can configure a FortiGate unit to
operate as an IDS appliance by sniffing network traffic for attacks without actually
processing the packets.
To configure one-arm IDS, you enable sniffer mode on a FortiGate interface and connect
the interface to a hub or to the SPAN port of a switch that is processing network traffic.
Then you add DoS policies for that FortiGate interface, Each policy can include a DoS
sensor, an IPS sensor, and an application control list to detect attacks and application
traffic in the network traffic that the FortiGate interface receives from the hub or switch
SPAN port.
The sniffer policy list

The sniffer policy list shows all of the sniffer policies you have created. The policies are
listed by sniffer interface. This is important because multiple sniffer policies can be applied
to sniffer interfaces. Traffic entering a sniffer interface is checked against the sniffer
policies for matching source and destination addresses and for service. This check
against the policies occurs in listed order, from top to bottom. The first sniffer policy
matching all three attributes then examines the traffic. Once a policy matches the
attributes, checks for policy matches stop. If no sniffer policies match, the traffic is dropped
without being examined.
Once a policy match is detected, the matching policy compares the traffic to the contents
of the DoS sensor, IPS sensor, and application list specified in the policy. If any matches
are detected, the FortiGate unit creates an entry in the log of the matching sensor/list. If
the same traffic matches multiple sensors/lists, it is logged for each match. When this
comparison is complete, the network traffic is dropped.
Figure 72 illustrates this process.

01-420-99686-20101026 887
Before you begin Sniffer policy
Figure 72: How the intrusion detection system uses sniffer policies to examine traffic
Start
A packet arrives at
the sniffer interface
Does the Does this

packet source packet trigger
address, destination Accept the packet any threshold Log the violation
address, and type for examination violation in the Yes
Yes
match a sniffer specified DoS
policy? sensor?
No No
Does this
packet match any
Discard the packet Log the match signatures in the
Yes specified IPS
sensor?
No
End
Does this
packet come
from any application
Log the match
in the specified
application Yes
control list?
No
End Discard the packet
Before you begin

Traffic entering an interface in sniffer mode is examined for DoS sensor violations, IPS
sensor matches, and application control matches. After these checks, all network traffic is
dropped. To avoid losing data, you must direct a copy of the network traffic to the
FortiGate unit interface configured to sniff packets.
The easiest way to do this is to either use a hub or a switch with a SPAN port.
A hub is the easiest solution to implement but carries a downside. Connecting the
FortiGate unit interface configured with the sniffer policy to a hub will deliver all traffic
passing through the hub to the interface. However, if the network carries a heavy traffic
load, the hub could slow the network because every hub interface sends out all the traffic
the hub received on every interface.
A better solution is a switch with a SPAN port. Network switches receive traffic on all
interfaces but they only send traffic out on the interface connected to the destination.
Network slowdowns are less common when using switches instead of hubs.

888 01-420-99686-20101026
Sniffer policy Enable one-arm sniffing
Connecting the sniffer interface to a regular switch interface will not work because no
traffic is addressed to the sniffer interface. A SPAN port is a special-purpose interface that
mirrors all the traffic the switch receives. Traffic is handled normally on every other switch
interface, but the SPAN port sends a copy of everything. If you connect your FortiGate unit
sniffer interface to the switch SPAN port, all the network traffic will be examined without
any being lost because of the examination.
Figure 73: A network configured for intrusion detection using a sniffer policy
One-Armed
IPS Scanner
Internal Network
o
nt
Main Firewall e ctio ort
nn P
Co PAN
S
Switch
Enable one-arm sniffing

Sniffer policies examine network traffic for anomalous patterns that usually indicate an
attack. Since all traffic entering a sniffer interface is dropped, you need to first add a switch
or hub to your network as described in “Before you begin” on page 888. The following
steps are based on the assumption that you have added the switch or hub.

The interface first must be designated as the sniffer interface, then the sniffer policy can
be configured to use the sniffer interface.
1 Add a switch or hub to your network as described in “Before you begin” on page 888.
This configuration will send a copy of your network traffic to the sniffer interface.
Caution: When an interface is configured as a sniffer interface, all traffic received

by the interface is dropped after being examined by the sniffer policy.
2 Designate a physical interface as a sniffer interface.

3 Create a sniffer policy that specifies the sniffer interface.
4 Specify a DoS sensor, IPS sensor, application control list, or any combination of the
three to define the traffic you want logged.

01-420-99686-20101026 889
Enable one-arm sniffing Sniffer policy
Designating a sniffer interface

An interface must be designated as a sniffer interface before it can be used with a sniffer
policy. Once an interface is designated as a sniffer interface, if functions differently from a
regular network interface in two ways:
• A sniffer mode interface accepts all traffic and drops it. If a sniffer policy is configured to
use the sniffer interface, traffic matching the attributes configured in the policy will be
examined before it is dropped. No traffic entering a sniffer mode interface will exit the
FortiGate unit from any interface.
• A sniffer mode interface will be the only available selection in sniffer policies. The
sniffer interface will not appear in firewall policies, routing tables, or anywhere else
interfaces can be selected.
Designating a sniffer interface

2 Select the interface.
Caution: When an interface is configured as a sniffer interface, all traffic received

by the interface is dropped after being examined by the sniffer policy.
4 Select the Enable one-arm sniffer check box.

If the check box is not available, the interface is in use. Ensure that the interface is not
selected in any firewall policies, routes, virtual IPs or other features in which a physical
interface is specified.
5 Select OK.
Creating a sniffer policy

Sniffer interfaces accept all traffic. To examine the traffic before it is dropped, a sniffer
policy is required.
To create a sniffer policy

1 Go to Firewall > Policy > Sniffer Policy and select Create New.
2 For Source Interface/Zone, select the interface configured as the sniffer interface. If no
interfaces are available for selection, no interfaces have been defined as sniffer
interfaces. For more information, see “Designating a sniffer interface” on page 890.
3 For Source Address, select the address or address group that defines the source
addresses of the traffic the sniffer policy will examine. Network traffic from addresses
not included in the selected address group is ignored by this sniffer policy.
4 For Destination Address, select the address or address group that defines the
destination addresses of the traffic the sniffer policy will examine. Network traffic to
addresses not included in the selected address group is ignored by this sniffer policy.
5 For Service, select the type of network traffic the sniffer policy will examine. Protocols
not included in the selected service or service group are ignored by this sniffer policy.
6 To have the sniffer policy log violations specified in a DoS sensor, select the
DoS Sensor check box and choose the sensor from the list.
7 To have the sniffer policy log signatures appearing in an IPS sensor, select the
IPS Sensor check box and choose the sensor from the list.

890 01-420-99686-20101026
Sniffer policy Sniffer example
8 To have the sniffer policy log traffic from applications specified in an application control
list, select the Application Black/White List check box and choose the application
control list.
9 Select OK.
DoS sensors, IPS sensors, and application control lists all allow you to choose actions and
log traffic. When included in a sniffer sensor, these settings are ignored. Actions in these
other settings do not apply, and all matches are logged regardless of the logging setting.
Sniffer example
An IDS sniffer configuration
The Example.com Corporation uses a pair of FortiGate-620B units to secure the head
office network. To monitor network attacks and create complete log records of them, the
network administrator has received approval to install a FortiGate-82C to record all IPS
signature matches in incoming and outgoing network traffic using a sniffer policy. This
example details the set-up and execution of this network configuration.
Although this example uses a separate FortiGate unit for sniffer-mode operation, the
sniffer traffic can be sent to the FortiGate unit protecting the network. The switch must still
be configured to create a copy of the data because the sniffer interface drops all incoming
traffic. In this case, the administrator requested a FortiGate-82C for this purpose because
sniffer-mode operation is resource intensive, and using a separate FortiGate unit frees the
FortiGate-620B cluster from this task. The FortiGate-82C unit also has four internal hard
drives, making it ideal for storing large log files.
Configuring the network

Connect the Port1 interface of the FortiGate-82C to the Port8 interface of the switch.
You must configure your network to deliver a copy of the traffic to be examined to the
sniffer interface because all network traffic entering a sniffer interface is dropped after
examination.
Since the corporate network uses a pair of FortiGate units in an HA cluster, a switch is
already in place connecting the Internet to Port1 of both FortiGate units.
Figure 74: Switch configuration

FortiGate-82C
FortiGate-620B
HA Cluster
P nif
or fe
(s
t1 r
P
m
or
od
t1
e)
2
ort
P
8 r of P 3)
P
or
or
t
t1
r
t3
Po irro Port
(m nd
P
or
a
t2
P
or
t1
Switch

01-420-99686-20101026 891
Sniffer example Sniffer policy
The company Internet feed is connected to Port1 of the switch. The FortiGate units are
connected to Port2 and Port3 of the switch. Since they are configured as an HA cluster,
they must both have access to the Internet in the event of a failure.
To allow a FortiGate unit sniffer interface to examine the network traffic, the switch must be
configured to create a copy of all network traffic entering or leaving Port2 and Port3 and
send it out Port8. When configured this way, the switch port sending the duplicate traffic is
called a mirror port or a SPAN port.
Consult the switch documentation for instructions on how to configure a SPAN port.
Note: The traffic between Port1 and Port2/Port3 is not modified or diverted in any way by
the creation of a SPAN port. The traffic is duplicated with the copy being send out of the
SPAN port.
Configuring the FortiGate sniffer interface

No sniffer interfaces are included in the default configuration of any FortiGate unit. A copy
of all of the network traffic is being sent to Port1 of the FortiGate-82C so you must
configure Port1 as a sniffer-mode interface.
Caution: All network traffic entering a sniffer-mode interface is dropped after examination
and logging according to the configured sniffer policy.
To configure the sniffer mode interface — web-based manager

1 Log in to the FortiGate-82C web-based manager.
3 Select the Port1 interface.
4 Select Edit.
5 Select Enable one-arm sniffer.
6 Select OK.
To configure the sniffer mode interface — CLI

edit port1
set ips-sniffer-mode enable
end

A sniffer policy allows you to select an IPS sensor, a DOS sensor, and an application
control list. Any conditions these sensors and list are configured to detect and log are
saved to the appropriate log.
For this example, create an IPS sensor that detects and logs the occurrence of all the
predefined IPS signatures.
To create an IPS sensor — web-based manager

3 In the Name field, enter IPS_sniffer.
4 In the Comments field, enter IPS sensor for use in the sniffer policy.

892 01-420-99686-20101026
Sniffer policy Sniffer example
5 In the Filters section, select Create New.

6 In the name field, enter All signatures, logged.
7 For the Logging setting under Signatures Settings, select Enable all.
8 Select OK to save the filter.
9 Ensure Enable Logging is selected in the sensor.
To create an IPS sensor — CLI

config ips sensor
edit IPS_sniffer
set comment "IPS sensor for use in the sniffer policy."
config filter
edit "All signatures, logged"
set log enable
end
end
Creating the sniffer policy

The sniffer policy allows us to choose
To create the sniffer policy — web-based manager

1 Go to Firewall > Policy > Sniffer Policy.
3 Select Port1 for the Source Interface/Zone.
4 Enable IPS Sensor and select the IPS_sniffer sensor.
5 Select OK to save the sniffer policy.
To create the sniffer policy — web-based manager

config firewall sniff-interface-policy
edit 0
set interface port1
set srcaddr all
set dstaddr all
set service ANY
set ips-sensor IPS_sniffer
end
With this configuration, all traffic entering the sniffer port is checked for matching
signatures. Matches are logged and the traffic is dropped.
To examine the network traffic for more issues, you can create a DoS sensor and select it
in the sniffer policy to log traffic anomalies. You can also create an application list with the
specific application you’d like to check for and select it in the sniffer policy.

01-420-99686-20101026 893
Sniffer example Sniffer policy

894 01-420-99686-20101026
Chapter 7 User Authentication

Introduction to authentication describes some basic elements and concepts of
authentication.
Authentication servers describes external authentication servers and how to configure a
FortiGate unit to use them.
Users and user groups describes the different types of user accounts and user groups.
Authenticated access to resources is based on user identities and user groups.
Configuring authenticated access provides detailed procedures for setting up
authenticated access in firewall policies and authenticated access to VPNs.
FSAE for integration with Windows AD or Novell describes how to install and configure the
Fortinet Server Authentication Extension (FSAE) on network domain controllers and the
FortiGate unit. On the FortiGate unit, Windows AD or Novell network user groups can be
made members of Directory Services user groups. With FSAE, network users have single
sign-on access to resources through the FortiGate unit.
Certificate-based authentication describes authentication by means of X.509 certificates.
Monitoring authenticated users describes the FortiGate unit authenticated user monitoring
screens.
Example provides a configuration example in which Windows AD and other network users
are provided authenticated access to the Internet.
FortiOS™ Handbook v2: User Authentication

01-420-99686-20101026 895
User Authentication for FortiOS 4.0 MR2
896 01-420-99686-20101026
Introduction to authentication
Identifying users and other computers—authentication—is a key part of network security.
This section describes some basic elements and concepts of authentication.
• What is authentication?
• Means of authentication
• Types of authentication
• User’s view of authentication
• FortiGate administrator’s view of authentication
What is authentication?
Authentication is the act of confirming the identity of a person or other entity. In the context
of a private computer network, the identities of users or host computers must be
established to ensure that only authorized parties can access the network. The FortiGate
unit provides network access control and applies authentication to users of firewall
policies and VPN clients.
Means of authentication
FortiGate unit authentication is divided into two basic types: password authentication for
people and certificate authentication for hosts or endpoints. An exception to this is that
FortiGate units in an HA cluster and FortiManager units use password authentication.
Password authentication verifies individual user identities, but access to network
resources is based on membership in user groups. For example, a firewall policy can be
configured to permit access only to the members of one or more user groups. Any user
who attempts network access through that policy is then authenticated through a request
for their user name and password.
Local password authentication

The simplest authentication is based on user accounts stored locally on the FortiGate unit.
For each account, a user name and password is stored. The account also has a disable
option so that you can suspend the account without deleting it.
Local user accounts work well for a single-FortiGate installation. If your network has
multiple FortiGate units that will use the same accounts, the use of an external
authentication server can simplify account configuration and maintenance.
You create local user accounts in the web-based manager under User > User. This page is
also used to create accounts where an external authentication server stores and verifies
the password.
Server-based password authentication

Using external LDAP, RADIUS, or TACACS+ authentication servers is desirable when
multiple FortiGate units need to authenticate the same users, or where the FortiGate unit
is added to a network that already contains an authentication server.

01-420-99686-20101026 897
Means of authentication Introduction to authentication
When you use an external authentication server to authenticate users, the FortiGate unit
sends the user’s entered credentials to the external server. The password is encrypted.
The server’s response indicates whether the supplied credentials are valid or not.
You must configure the FortiGate unit to access the external authentication servers that
you want to use. The configuration includes the parameters that authenticate the
FortiGate unit to the authentication server.
You can use external authentication servers in two ways:
• Create user accounts on the FortiGate unit, but instead of storing each user’s
password, specify the server used to authenticate that user. As with accounts that
store the password locally, you add these users to appropriate user groups.
• Add the authentication server to user groups. Any user who has an account on the
server can be authenticated and have the access privileges of the FortiGate user
group. Optionally, when an LDAP server is a FortiGate user group member, you can
limit access to users who belong to specific groups defined on the LDAP server.
Single Sign On authentication using FSAE

“Single sign on” means that users logged on to a computer network are authenticated for
access to network resources through the FortiGate unit without having to enter their user
name and password again. The Fortinet Server Authentication Extension (FSAE) provides
Single Sign On capability for:
• Microsoft Windows networks using either Active Directory or NTLM authentication
• Novell networks, using eDirectory
FSAE monitors user logons and sends the FortiGate unit the user name, IP address, and
the list of Windows AD user groups to which the user belongs. When the user tries to
access network resources, the FortiGate unit selects the appropriate firewall policy for the
destination. If the user belongs to one of the permitted user groups, the connection is
allowed.
For detailed information about FSAE, see “FSAE for integration with Windows AD or
Novell” on page 933.
Certificate-based authentication
An RSA X.509 server certificate is a small file issued by a Certificate Authority (CA) that is
installed on a computer or FortiGate unit to authenticate itself to other devices on the
network. When one party on a network presents the certificate as authentication, the other
party can validate that the certificate was issued by the CA. The identification is therefore
as trustworthy as the Certificate Authority (CA) that issued the certificate.
To protect against compromised or misused certificates, CAs can revoke any certificate by
adding it to a Certificate Revocation List (CRL). Certificate status can also be checked
online using Online Certificate Status Protocol (OCSP).
RSA X.509 certificates are based on public-key cryptography, in which there are two keys:
the private key and the public key. Data encrypted with the private key can be decrypted
only with the public key and vice versa. As the names suggest, the private key is never
revealed to anyone and the public key can be freely distributed. Encryption with the
recipient’s public key creates a message that only the intended recipient can read.
Encryption with the sender’s private key creates a message whose authenticity is proven
because it can be decrypted only with the sender’s public key.
Server certificates contain a signature string encrypted with the CA’s private key. The CA’s
public key is contained in a CA root certificate. If the signature string can be decrypted with
the CA’s public key, the certificate is genuine.

898 01-420-99686-20101026
Introduction to authentication Types of authentication
Certificate authorities
A certificate authority can be:
• an organization, such as VeriSign Inc., that provides certificate services
• a software application, such as Microsoft Certificate Services or OpenSSH
For a company web portal or customer-facing SSL VPN, a third-party certificate service
has some advantages. The CA certificates are already included in popular web browsers
and customers trust the third-party. On the other hand, third-party services have a cost.
For administrators and for employee VPN users, the local CA based on a software
application provides the required security at low cost. You can generate and distribute
certificates as needed. If an employee leaves the organization, you can simply revoke
their certificate.
Certificates for users

FortiGate unit administrators and SSL VPN users can install certificates in their web
browsers to authenticate themselves. If the FortiGate unit uses a CA-issued certificate to
authenticate itself to the clients, the browser will also need the appropriate CA certificate.
FortiGate IPsec VPN users can install server and CA certificates according to the
instructions for their IPsec VPN client software. The FortiClient Endpoint Security
application, for example, can import and store the certificates required by VPN
connections.
FortiGate units are also compatible with some Public Key Infrastructure systems. For an
example of this type of system, see “RSA/ACE (SecurID) servers” on page 913.
Two-factor authentication
Optionally, you can require both a certificate and user name/password authentication.
Certificates are installed on the user’s computer. Also requiring a password protects
against unauthorized use of that computer. Two-factor authentication is available for PKI
users. For more information, see “Two-factor authentication” on page 918.
Types of authentication
Authentication applies to several FortiGate features:
• firewall policies (identity-based policies)
• VPNs
Firewall authentication (or Identity-based policies)

Firewall policies enable traffic to flow between network interfaces. If you want to limit
which users have access to particular resources, you create identity-based firewall
policies that allow access only to members of specific user groups. Authentication, a
request for user name and password, is triggered when a user attempts to access a
resource for which data must pass through an identity-based firewall policy.
The user’s authentication expires if the connection is idle for too long. The Authentication
Timeout setting is in User > Authentication. It has a default timeout of 30 minutes.

01-420-99686-20101026 899
Types of authentication Introduction to authentication
FortiGuard Web Filter override authentication

Optionally, users can be allowed the privilege of overriding FortiGuard Web Filtering to
view blocked web sites. Depending on the override settings, the override can apply to the
user who requested it, the entire user group to which the user belongs, or all users who
share the same web filter profile. As with other FortiGate features, access to FortiGuard
overrides is controlled through user groups. Firewall and Directory Services user groups
are eligible for the override privilege. For more information about web filtering and
overrides, see the UTM chapter of this FortiOS Handbook.
VPN authentication
In IPsec VPNs, there is authentication of the peer device and optionally of the peer user.
Authenticating IPsec VPN peers (devices)

The simplest way for IPsec VPN peers to authenticate each other is through the use of a
preshared key, sometimes also called a shared secret. The preshared key is a text string
used to encrypt the data exchanges that establish the VPN tunnel. The tunnel cannot be
established if the two peers do not use the same key. The disadvantage of preshared key
authentication is that it can be difficult to securely distribute and update the preshared
keys.
RSA X.509 certificates are a better way for VPN peers to authenticate each other. Each
peer offers a certificate signed by a Certificate Authority (CA) which the other peer can
validate with the appropriate CA root certificate. For more information about certificates,
see “Certificate-based authentication” on page 961.
You can supplement either preshared key or certificate authentication by requiring the
other peer to provide a specific peer ID value. The peer ID is a text string configured on
the peer device. On a FortiGate peer or FortiClient Endpoint Security peer, the peer ID
provided to the remote peer is called the Local ID.
Authenticating IPsec VPN users

An IPsec VPN can be configured to accept connections from multiple dynamically
addressed peers. You would do this to enable employees to connect to the corporate
network while traveling or from home. On a FortiGate unit, you create this configuration by
setting the Remote Gateway to Dialup User.
It is possible to have an IPsec VPN in which remote peer devices authenticate using a
common preshared key or a certificate, but there is no attempt to identify the user at the
remote peer. To add user authentication, you can do one of the following:
• require a unique preshared key for each peer
• require a unique peer ID for each peer
• require a unique peer certificate for each peer
• require additional user authentication (XAuth)
The peer ID is a text string configured on the peer device. On a FortiGate peer or
FortiClient Endpoint Security peer, the peer ID provided to the remote peer is called the
Local ID.
Authenticating SSL VPN users

SSL VPN users can be
• user accounts with passwords stored on the FortiGate unit
• user accounts authenticated by an external RADIUS, LDAP or TACACS+ server

900 01-420-99686-20101026
Introduction to authentication User’s view of authentication
• PKI users authenticated by certificate

You need to create a user group for your SSL VPN. Simply create a firewall user group,
enable SSL VPN access for the group, and select the web portal the users will access.
SSL VPN access requires an SSL VPN firewall policy that permits access to members of
your user group.
Authenticating PPTP and L2TP VPN users

PPTP and L2TP are older VPN tunneling protocols that do not provide authentication
themselves. FortiGate units restrict PPTP and L2TP access to users who belong to one
specified user group. Users authenticate themselves to the FortiGate unit by
username/password. You can configure PPTP and L2TP VPNs only in the CLI. Before you
configure the VPN, create a firewall user group and add to it the users who are permitted
to use the VPN. Users are authenticated when they attempt to connect to the VPN. For
more information about configuring PPTP or L2TP VPNs, see the FortiGate CLI
Reference.
User’s view of authentication

The user sees a request for authentication when they try to access a protected resource.
The way in which the request is presented to the user depends on the method of access to
that resource.
VPN authentication usually controls remote access to a private network.
Web-based user authentication

Firewall policies usually control browsing access to an external network that provides
connection to the Internet. In this case, the FortiGate unit requests authentication through
the web browser:
Figure 75: Authentication challenge through a web browser
The user types a user name and password and then selects Continue or Login. If the
credentials are incorrect, the authentication screen is redisplayed with blank fields so that
the user can try again. When the user enters valid credentials, they get access to the
required resource. In some cases, if a user tries to authenticate several times without
success, a message appears, such as: “Too many bad login attempts. Please try again in
a few minutes.”

01-420-99686-20101026 901
FortiGate administrator’s view of authentication Introduction to authentication
Note: After a defined period of user inactivity (the authentication timeout, defined by the
FortiGate administrator), the user’s access expires. The default is 5 minutes. To access the
resource, the user will have to authenticate again.
VPN client-based authentication

A VPN provides remote clients with access to a private network for a variety of services
that include web browsing, email, and file sharing. A client program such as FortiClient
negotiates the connection to the VPN and manages the user authentication challenge
from the FortiGate unit.
FortiClient can store the user name and password for a VPN as part of the configuration
for the VPN connection and pass them to the FortiGate unit as needed. Or, FortiClient can
request the user name and password from the user when the FortiGate unit requests
them.
Figure 76: FortiClient application request for user name and password
SSL VPN is a form of VPN that can be used with a standard Web browser. There are two
modes of SSL VPN operation (supported in NAT/Route mode only):
• web-only mode, for remote clients equipped with a web-browser only
• tunnel mode, for remote computers that run a variety of client and server applications.
Note: After a defined period of user inactivity on the VPN connection (the idle timeout,
defined by the FortiGate administrator), the user’s access expires. The default is 30
minutes. To access the resource, the user will have to authenticate again.
FortiGate administrator’s view of authentication

Authentication is based on user groups. The FortiGate administrator configures
authentication for firewall policies and VPN tunnels by specifying the user groups whose
members can use the resource. Some planning is required to determine how many
different user groups need to be created. Individual user accounts can belong to multiple
groups, making allocation of user privileges very flexible.
A member of a user group can be:
• a user whose user name and password are stored on the FortiGate unit
• a user whose name is stored on the FortiGate unit and whose password is stored on a
remote or external authentication server

902 01-420-99686-20101026
Introduction to authentication FortiGate administrator’s view of authentication
• a remote or external authentication server with a database that contains the user name
and password of each person who is permitted access
The general process of setting up authentication is as follows:
1 If remote or external authentication is needed, configure the required servers.
2 Configure local and peer (PKI) user identities. For each local user, you can choose
whether the FortiGate unit or a remote authentication server verifies the password.
Peer members can be included in user groups for use in firewall policies.
3 Create user groups.
Add local/peer user members to each user group as appropriate. You can also add an
authentication server to a user group. In this case, all users in the server’s database
can authenticate. You can only configure peer user groups through the CLI.
4 Configure firewall policies and VPN tunnels that require authenticated access.

01-420-99686-20101026 903
FortiGate administrator’s view of authentication Introduction to authentication

904 01-420-99686-20101026
Authentication servers
FortiGate units support the use of external authentication servers. An authentication
server can provide password checking for selected FortiGate users or it can be added as
a member of a FortiGate user group. If you are going to use authentication servers, you
must configure the servers before you configure FortiGate users or user groups that
require them.
• RADIUS servers
• LDAP servers
• TACACS+ servers
• Directory Service servers
• RSA/ACE (SecurID) servers
RADIUS servers
Remote Authentication and Dial-in User Service (RADIUS) servers provide authentication,
authorization, and accounting functions. FortiGate units use the authentication and
accounting functions of the RADIUS server.
Your RADIUS server listens on either port 1812 or port 1645 for authentication requests.
You must configure it to accept the FortiGate unit as a client.
The RADIUS server user database can be any combination of:
• user names and passwords defined in a configuration file
• an SQL database
• user account names and passwords configured on the computer where the RADIUS
server is installed.
The RADIUS server uses a “shared secret” key to encrypt information passed between it
and clients such as the FortiGate unit.
The FortiGate unit sends the following RADIUS attributes:
1. Acct-Session-ID
2. User Name
3. NAS-Identifier (FGT hostname)
4. Framed-IP-Address (IP address assigned to the client)
5. Fortinet-VSA (IP address client is connecting from)
6. Acct-Input-Octets
7. Acct-Output-Octets
Table 68 describes the supported authentication events and the RADIUS attributes that
are sent in the RADIUS accounting message.

01-420-99686-20101026 905
RADIUS servers Authentication servers
Table 68: RADIUS attributes sent in RADIUS accounting message
ATTRIBUTE
AUTHENTICATION METHOD 1 2 3 4 5 6 7
Web X X X X
XAuth of IPsec (without DHCP) X X X X
XAuth of IPsec (with DHCP) X X X X X
PPTP/L2TP (in PPP) X X X X X X X
SSL-VPN X X X X
In order to support vendor-specific attributes (VSA), the RADIUS server requires a

dictionary to define what the VSAs are.
Fortinet’s dictionary is configured this way:
##
Fortinet’s VSA’s
#
VENDOR fortinet 12356
BEGIN-VENDOR fortinet
ATTRIBUTE Fortinet-Group-Name 1 string
ATTRIBUTE Fortinet-Client-IP-Address 2 ipaddr
ATTRIBUTE Fortinet-Vdom-Name 3 string
#
# Integer Translations
#
END-VENDOR Fortinet
See the documentation provided with your RADIUS server for configuration details.
Configuring the FortiGate unit to use a RADIUS server

To configure the FortiGate unit to use a RADIUS server, you need to know the server’s
domain name or IP address and its shared secret key. The maximum number of remote
RADIUS servers that can be configured for authentication is 10.
On the FortiGate unit, the default port for RADIUS traffic is 1812. If your RADIUS server is
using port 1645, you can either:
• Reconfigure the RADIUS server to use port 1812. See your RADIUS server
documentation for more information.
or
• Change the FortiGate unit default RADIUS port to 1645 using the CLI:
set radius_port 1645
end
To configure the FortiGate unit for RADIUS authentication - web-based manager

1 Go to User > Remote > RADIUS and select Create New.
2 Enter a name for the RADIUS server.
3 In Primary Server Name/IP, enter the domain name or IP address of the RADIUS
server.

906 01-420-99686-20101026
Authentication servers LDAP servers
4 In Primary Server Secret, enter the server secret key.

5 Optionally, enter the information for a secondary RADIUS server in the
Secondary Server Name/IP and Secondary Server Secret fields.
6 Select the Authentication Scheme.
Use Default Authentication Scheme will usually work. Or, you can select
Specify Authentication Protocol and select the protocol your RADIUS server requires.
7 Select OK.
To configure the FortiGate unit for RADIUS authentication - CLI example

config user radius
edit ourRADIUS
set auth-type auto
set server 10.11.102.100
set secret aoewmntiasf
end
For more information about RADIUS server options, refer to the FortiGate CLI Reference.
LDAP servers
Lightweight Directory Access Protocol (LDAP) is an Internet protocol used to maintain
authentication data that may include departments, people, groups of people, passwords,
email addresses, and printers. An LDAP consists of a data-representation scheme, a set
of defined operations, and a request/response network.
The scale of LDAP servers ranges from big public servers such as BigFoot and Infospace,
to large organizational servers at universities and corporations, to small LDAP servers for
workgroups. This document focuses on the institutional and workgroup applications of
LDAP.
A directory is a set of objects with similar attributes organized in a logical and hierarchical
way. Generally, an LDAP directory tree reflects geographic and/or organizational
boundaries, with the Domain name system (DNS) names to structure the top level of the
hierarchy. The common name identifier for most LDAP servers is cn, however some
servers use other common name identifiers such as uid.
If you have configured LDAP support and a user is required to authenticate using an
LDAP server, the FortiGate unit contacts the LDAP server for authentication. To
authenticate with the FortiGate unit, the user enters a user name and password. The
FortiGate unit sends this user name and password to the LDAP server. If the LDAP server
can authenticate the user, the user is successfully authenticated with the FortiGate unit. If
the LDAP server cannot authenticate the user, the connection is refused by the FortiGate
unit.
Binding is the step where the LDAP server authenticates the user, and if the user is
successfully authenticated, allows the user access to the LDAP server based on that
user’s permissions.
The FortiGate unit can be configured to use one of three types of binding:
• anonymous - bind using anonymous user search
• regular - bind using user name/password and then search
• simple - bind using a simple password authentication without a search

01-420-99686-20101026 907
LDAP servers Authentication servers
You can use simple authentication if the user records all fall under one dn. If the users are
under more than one dn, use the anonymous or regular type, which can search the entire
LDAP database for the required user name.
If your LDAP server requires authentication to perform searches, use the regular type and
provide values for user name and password.
The FortiGate unit supports LDAP protocol functionality defined in RFC 2251: Lightweight
Directory Access Protocol v3, for looking up and validating user names and passwords.
FortiGate LDAP supports all LDAP servers compliant with LDAP v3. In addition, FortiGate
LDAP supports LDAP over SSL/TLS, which can be configured only in the CLI.
FortiGate LDAP does not support proprietary functionality, such as notification of
password expiration, which is available from some LDAP servers. FortiGate LDAP does
not supply information to the user about why authentication failed.
To configure your FortiGate unit to work with an LDAP server, you need to understand the
organization of the information on the server.
The top of the hierarchy is the organization itself. Usually this is defined as Domain
Component (DC), a DNS domain. If the name contains a dot, such as “example.com”, it is
written as two parts: “dc=example,dc=com”.
In this example, Common Name (CN) identifiers reside at the Organization Unit (OU)
level, just below DC. The Distinguished Name (DN) is ou=People,dc=example,dc=com.
Figure 77: LDAP object hierarchy
In addition to the DN, the FortiGate unit needs an identifier for the individual person.
Although the FortiGate unit GUI calls this the Common Name (CN), the identifier you use
is not necessarily CN. On some servers, CN is the full name of a person. It might be more
convenient to use the same identifier used on the local computer network. In this example,
User ID (UID) is used.
You need to determine the levels of the hierarchy from the top to the level that contains the
identifier you want to use. This defines the DN that the FortiGate unit uses to search the
LDAP database. Frequently used distinguished name elements include:
• pw (password)
• cn (common name)
• ou (organizational unit)
• o (organization)
• c (country)

908 01-420-99686-20101026
Authentication servers LDAP servers
One way to test this is with a text-based LDAP client program. For example, OpenLDAP
includes a client, ldapsearch, that you can use for this purpose.
Enter the following at the command line:
ldapsearch -x '(objectclass=*)'
The output is lengthy, but the information you need is in the first few lines:
version: 2
#
# filter: (objectclass=*)
# requesting: ALL
#
dn: dc=example,dc=com
dc: example
objectClass: top
objectClass: domain
dn: ou=People,dc=example,dc=com
ou: People
objectClass: top
objectClass: organizationalUnit
...
dn: uid=auser,ou=People,dc=example,dc=com
uid: auser
cn: Alex User
Configuring the FortiGate unit to use an LDAP server

After you determine the common name and distinguished name identifiers and the domain
name or IP address of the LDAP server, you can configure the server on the FortiGate
unit. The maximum number of remote LDAP servers that can be configured for
authentication is 10.
To configure the FortiGate unit for LDAP authentication - web-based manager

1 Go to User > Remote > LDAP and select Create New.
Figure 78: Configure FortiGate unit for LDAP authentication
2 Enter a name for the LDAP server.

3 In Server Name/IP enter the server’s FQDN or IP address.
4 If the server does not use port 389, enter the port number in the Server Port field.

01-420-99686-20101026 909
LDAP servers Authentication servers
5 Enter the Common Name Identifier (20 characters maximum).

cn is the default, and is used by most LDAP servers.
6 In the Distinguished Name field, enter the base distinguished name for the server using
the correct X.500 or LDAP format.
The FortiGate unit passes this distinguished name unchanged to the server. The
maximum number of characters is 512.
If you don’t know the distinguished name, leave the field blank and select the Query
icon to the right of the field. For more information, see the “Using the Query icon” on
page 29.
7 In Bind Type, select Regular.
8 In User DN, enter the LDAP administrator’s distinguished name.
9 In Password, enter the LDAP administrator’s password.
10 Select OK.
For detailed information about configuration options for LDAP servers, see the online Help
on your FortiGate unit.
To configure the FortiGate unit for LDAP authentication - CLI example

config user ldap
edit ourLDAPsrv
set server 10.11.101.160
set cnid cn
set dn cn=users,dc=office,dc=example,dc=com
set type regular
set username cn=administrator,cn=users,dc=office,dc=example,dc=com
set password w5AiGVMLkgyPQ
end
Using the Query icon

The LDAP Distinguished Name Query list displays the LDAP directory tree for the LDAP
server connected to the FortiGate unit. This helps you to determine the appropriate entry
for the DN field. To see the distinguished name associated with the Common Name
identifier, select the Expand icon next to the CN identifier. Select the DN from the list. The
DN you select is displayed in the Distinguished Name field. Select OK and the
Distinguished Name you selected will be saved in the Distinguished Name field of the
LDAP Server configuration.
To see the users within the LDAP Server user group for the selected Distinguished Name,
expand the Distinguished Name in the LDAP Distinguished Name Query tree.

910 01-420-99686-20101026
Authentication servers TACACS+ servers
Figure 79: LDAP server Distinguished Name Query tree
Common Name Identifier (CN)

Distinguished Name (DN)
TACACS+ servers
In recent years, remote network access has shifted from terminal access to LAN access.
Users are now connecting to their corporate network remotely with computers that utilize
complete network connections. Remote node technology allows users the same level of
access to the corporate network resources as they would have if they were physically in
the office. When users connect to their corporate network remotely, they do so through a
remote access server. As remote access technology has evolved, the need for network
access security has become increasingly important. This need can be filled using a
Terminal Access Controller Access-Control System (TACACS+) server.
Terminal Access Controller Access-Control System (TACACS+) is a remote authentication
protocol that provides access control for routers, network access servers, and other
networked computing devices via one or more centralized servers. TACACS+ allows a
client to accept a user name and password and send a query to a TACACS+
authentication server. The server host determines whether to accept or deny the request
and sends a response back that allows or denies network access to the user.

01-420-99686-20101026 911
TACACS+ servers Authentication servers
There are several different authentication protocols that TACACS+ can use during the
authentication process:
• ASCII
Machine-independent technique that uses representations of English characters.
Requires user to type a user name and password that are sent in clear text
(unencrypted) and matched with an entry in the user database stored in ASCII format.
• PAP (password authentication protocol)
Used to authenticate PPP connections. Transmits passwords and other user
information in clear text.
• CHAP (challenge-handshake authentication protocol)
Provides the same functionality as PAP, but is more secure as it does not send the
password and other user information over the network to the security server.
• MS-CHAP (Microsoft challenge-handshake authentication protocol v1)
Microsoft-specific version of CHAP.
The default protocol configuration, Auto, uses PAP, MS-CHAP, and CHAP, in that order.
Configuring the FortiGate unit to use a TACACS+ authentication server

The maximum number of remote TACACS+ servers that can be configured for
authentication is 10.
To configure the FortiGate unit for TACACS+ authentication - web-based manager

1 Go to User > Remote > TACACS+ and select Create New.
2 Enter the following information, and select OK.
Figure 80: TACACS+ server configuration
Name Enter the name of the TACACS+ server.

Server Name/IP Enter the server domain name or IP address of the
TACACS+ server.
Server Key Enter the key to access the TACACS+ server.
Authentication Type Select the authentication type to use for the TACACS+
server. Auto tries PAP, MSCHAP, and CHAP (in that order).
To configure the FortiGate unit for TACACS+ authentication - CLI

config user tacacs+
edit <server_name>
set auth-type {ascii | auto | chap | ms_chap | pap}
set key <server_key>
set tacacs+-port <tacacs+_port_num>
set server <domain>
end

912 01-420-99686-20101026
Authentication servers Directory Service servers
Directory Service servers

Novell and Microsoft Windows networks provide user authentication based on
directory services: eDirectory for Novell, Active Directory for Windows. Users can
log on at any computer in the domain and have access to resources as defined in
their user account. The Fortinet Server Authentication Extension (FSAE) enables
FortiGate units to authenticate these network users for firewall policy or VPN
access without asking them for their user name and password.
When a user logs in to the Windows or Novell domain, FSAE sends the FortiGate
unit the user’s IP address and the names of the user groups to which the user
belongs. The FortiGate unit uses this information to maintain a copy of the domain
controller user group database. Because the domain controller authenticates
users, the FortiGate unit does not perform authentication. It recognizes group
members by their IP address.
In the FortiGate Directory Services configuration, you specify the network
computers where the FSAE collector agent is installed. The FortiGate unit
retrieves the names of the Novell or Active Directory user groups. You cannot use
these groups directly. You must define FortiGate user groups of the Directory
Services type and then add the Novell or Active Directory user groups to them.
The Directory Services user groups that you created can used in firewall policies
and VPN configurations.
For more information about Directory Services and FSAE, see “FSAE for
integration with Windows AD or Novell” on page 933.
RSA/ACE (SecurID) servers

SecurID is a one-time password system. The user carries a small device, a
“token”, that generates and displays a password. The token is time-synchronized
with the SecurID authentication server and the password changes about once per
minute. To authenticate, users enter their User ID and the password currently
displayed on the token.
To use SecurID with a FortiGate unit, you need to:
• configure the RSA ACE/Server and the RADIUS server to work with each
other (refer to the RSA ACE/Server documentation)
• configure the FortiGate unit as an Agent Host within the RSA ACE/Server
database
• configure the FortiGate unit to access the RADIUS server
• create a FortiGate user group for SecurID users
The instructions provide here are based on RSA ACE/Server version 5.1.
To configure the FortiGate unit as an Agent Host on the RSA ACE/Server

1 On the RSA ACE/Server computer, go to Start > Programs > RSA ACE/Server,
and then Database Administration - Host Mode.
2 On the Agent Host menu, select Add Agent Host.
3 In the Name field, enter a name for the FortiGate unit.
4 In the Network address field, enter the FortiGate unit IP address.
5 Select Secondary Nodes and define all hostname/IP addresses that resolve to
the FortiGate unit.

01-420-99686-20101026 913
RSA/ACE (SecurID) servers Authentication servers
If needed, refer to the RSA ACE/Server documentation for more information.
To configure the FortiGate unit to use the RADIUS server

2 In the Name field, enter a name for the RADIUS server.
3 In the Primary Server Name/IP and Primary Server Secret fields, enter the appropriate
information about the RADIUS server you configured for use with SecurID.
4 Select OK.
To create a SecurID user group

1 Go to User > User Group.
3 In the Name field, enter a name for the group.
4 In the Available Users/Groups list, select the RADIUS server you configured for use
with SecurID.
5 Select the right arrow button to move the selected server to the Members list.
6 Select OK.
Using the SecurID user group for authentication

You can use the SecurID user group in several FortiGate features that authenticate by
user group:
Firewall policy
Select Enable Identity Based Policy and then select Add. Add the SecurID user group to
the Selected User Groups list. Set other options as desired and select OK.
IPsec VPN XAuth

In the Phase 1 Advanced settings, in the XAuth section, select Enable as Server and
choose the SecurID user group.
PPTP VPN
PPTP VPN is configured in the CLI. In the PPTP configuration (config vpn pptp), set
usrgrp to the SecurID user group.
SSL VPN
In the SecurID user group, select the appropriate web portal for these users. In the firewall
policy for the SSL VPN, include the SecurID user group in the list of selected user groups.

914 01-420-99686-20101026
Users and user groups
FortiGate authentication controls system access by user group. By assigning individual
users to the appropriate user groups you can control each user’s access to network
resources. The members of user groups are user accounts, of which there are several
types. Local users and peer users are defined on the FortiGate unit. User accounts can
also be defined on external authentication servers.
This section describes how to configure local users and peer users and then how to
configure user groups. For information about configuration of authentication servers see
“Authentication servers” on page 905.
• Users
• User groups
Users
A user is a user account consisting of user name, password, and in some cases other
information, configured on the FortiGate unit or on an external authentication server.
Users can access resources that require authentication only if they are members of an
allowed user group. There are several different types of user accounts with slightly
different methods of authentication:
Table 69: How the FortiGate unit authenticates different types of users
User type Authentication
Local user with password The user name and password must match a user account
stored on the FortiGate unit stored on the FortiGate unit.
Local user with password The user name must match a user account stored on the
stored on an authentication FortiGate unit and the user name and password must
server match a user account stored on the authentication server.
On the external authentication server, there may be user
groups to which users can be assigned. These groups exist
independently of FortiGate unit user groups.
Authentication server user A FortiGate user group can include user accounts that exist
on an external authentication server or particular user
groups on that server.
Any of the included users can authenticate and get access
to the resources permitted to the FortiGate user group.
Directory Services user By using the Fortinet Server Authentication Extension

(FSAE), users on a Microsoft Windows or Novell network
can use their network authentication to access resources
through the FortiGate unit.
Access is controlled through Directory Services user groups
which contain Windows or Novell user groups as their
members.
Peer user with certificate A peer user is a digital certificate holder that authenticates
authentication using a client certificate. No password is required, unless
two-factor authentication is enabled.

01-420-99686-20101026 915
Users Users and user groups
Creating local users

To define a local user you need:
• a user name
• a password or the name of the authentication server that contains the user account
If the user is authenticated externally, the user name on the FortiGate unit must be
identical to the user name on the authentication server.
To create a local user - web-based manager

1 Go to User > User and select Create New.
Figure 81: Creating new local user
2 Enter the user name in the User Name field.

3 Do one of the following:
• To authenticate this user locally, select Password and type a password.
The password should be at least six characters long.
• To authenticate this user using an external authentication server, select the
Match user option for the appropriate type of server and select the server name.
If you want to use an authentication server, you must configure access to it first. See
“Authentication servers” on page 905.
4 Select OK.
To create a local user - CLI examples

Locally authenticated user
config user local
edit user1
set type password
set passwd ljt_pj2gpepfdw
end
User authenticated on an LDAP server
config user local
edit user2
set type ldap
set ldap_server ourLDAPsrv
end
User authenticated on a RADIUS server
config user local
edit user3
set type radius

916 01-420-99686-20101026
Users and user groups Users
set radius_server ourRADIUSsrv

end
User authenticated on a TACACS+ server
config user local
edit user4
set type tacacs+
set tacacs+_server ourTACACS+srv
end
To remove a user from the FortiGate unit configuration - web-based manager

1 Go to User > User.
Figure 82: Local user list
2 Select the check box of the user that you want to remove.
3 Select Delete.
4 Select OK.
Note: You cannot remove a user that belongs to a user group. Remove the user from the
user group first.
To remove a user from the FortiGate unit configuration - CLI example

config user local
delete user4444
end
Creating PKI or peer users

A PKI or peer user is a digital certificate holder. A PKI user account on the FortiGate unit
contains the information required to determine which CA certificate to use to validate the
user’s certificate. Peer users can be included in firewall user groups or peer certificate
groups used in IPsec VPNs.
To define a peer user you need:
• a peer user name
• the text from the subject field of the user’s certificate, or the name of the CA certificate
used to validate the user’s certificate
Note: The configuration page for PKI users in the web-based manager is not available
unless there is at least one peer user defined. Follow the CLI-based instructions to create
the first peer user. Optionally, you can then log into the web-based manager to configure
additional PKI (peer) users.

01-420-99686-20101026 917
Users Users and user groups
To create a peer user for PKI authentication - CLI example

config user peer
edit peer1
set subject E=peer1@mail.example.com
set ca CA_Cert_1
end
Note: If you create a PKI user in the CLI with no values in subject or ca, you will not be
able to open the user’s record in the web-based manager. The CLI will prompt you to add a
value in Subject (subject) or CA (ca).
To create a peer user for PKI authentication - web-based manager

1 Go to User > PKI and select Create New.
Figure 83: PKI peer user configuration
2 Enter the user name.

3 Fill in at least one of the following fields:
Subject The text string that appears in the Subject field of the user’s certificate.
CA Select the CA certificate that must be used to authenticate this peer user.
4 Select OK.
There are other configuration settings that can be added or modified for PKI
authentication. For example, you can configure the use of an LDAP server to check
access rights for client certificates. For information about the detailed PKI configuration
settings only available through the CLI, see the FortiGate CLI Reference.
Two-factor authentication
You can increase security by requiring both certificate and password authentication for
PKI users. Certificates are installed on the user’s computer. Also requiring a password
protects against unauthorized use of that computer.
To create a peer user with two-factor authentication - web-based manager
While configuring a peer user (see Figure 83, above), select Require two-factor
authentication and enter a password.
To create a peer user with two-factor authentication - CLI example

config user peer
edit peer1
set subject E=peer1@mail.example.com
set ca CA_Cert_1

918 01-420-99686-20101026
Users and user groups User groups
set two-factor enable

set passwd fdktguefheygfe
end
User groups
A user group is a list of user identities. An identity can be:
• a local user account (user name/password) stored on the FortiGate unit
• a local user account with the password stored on a RADIUS, LDAP, or TACACS+
server
• a PKI user account with digital client authentication certificate stored on the FortiGate
unit
• a RADIUS, LDAP, or TACACS+ server, optionally specifying particular user groups on
that server
• a user group defined on a Directory Service server.
Identity-based firewall policies and some types of VPN configurations allow access only to
specified user groups.
In most cases, the FortiGate unit authenticates users by requesting their user name and
password. The FortiGate unit checks local user accounts first. If a match is not found, the
FortiGate unit checks the RADIUS, LDAP, or TACACS+ servers that belong to the user
group. Authentication succeeds when a matching user name and password are found.
There are two types of FortiGate user group: Firewall and Directory Services.
Firewall user groups

A firewall user group can contain any type of user identity except a Directory Services
group. When a user attempts to access resources controlled by an identity-based firewall
policy, the FortiGate unit requests authentication. If the user authenticates successfully
and is a member of one of the permitted groups, the user’s session is allowed to proceed.
SSL VPN access

In any firewall user group, you can enable SSL VPN access and select the web-portal that
the users can access. When the user connects to the FortiGate unit via HTTPS on the
SSL VPN port (default 10443), the FortiGate unit requests a user name and password.
SSL VPN access also requires an SSL VPN firewall policy (Action is SSL VPN) with an
identity-based rule enabling access for the user group. For more information, see the SSL
VPN chapter of the FortiOS Handbook.
IPsec VPN access

A firewall user group can provide access for dialup users of an IPsec VPN. In this case,
the IPsec VPN phase 1 configuration uses the Accept peer ID in dialup group peer option.
The user’s VPN client is configured with the user name as peer ID and the password as
pre-shared key. The user can connect successfully to the IPsec VPN only if the user name
is a member of the allowed user group and the password matches the one stored on the
FortiGate unit.
Note: A user group cannot be a dialup group if any member is authenticated using an
external authentication server.

01-420-99686-20101026 919
User groups Users and user groups
Configuring a firewall user group

A user group can contain:
• local users, whether authenticated by the FortiGate unit or an authentication server
• PKI users
• authentication servers, optionally specifying particular user groups on the server
To create a Firewall user group - web-based manager

1 Go to User > User Group and select Create New.
Figure 84: User group configuration - Firewall
2 Enter a name for the user group.

3 In Type, select Firewall.
4 From the Available Users/Groups list, select users and then select the right arrow
button to move the names to the Members list.
If you select an authentication server as a group member, by default all user accounts
on the authentication server are members of this FortiGate user group. Follow steps 5
through 8 if you want to include only specific user groups from the authentication
server. Otherwise, select OK.
5 Select Add.
6 From the Remote Server list, select the authentication server.
Only servers that are already members of this user group are available.
7 In the Group Name field, enter the group name in the appropriate format for the type of
server.
For example, an LDAP server requires LDAP format, such as:
cn=users,dn=office,dn=example,dn=com
8 Repeat steps 5 through 7 to add all the authentication server user groups that are
required.
9 Select OK.

920 01-420-99686-20101026
Users and user groups User groups
To create a firewall user group - CLI example

In this example, the members of group01 are User1 and all of the members of usergroup1
on RADIUSsrvr2.
config user group
edit group01
set member User1 RADIUSsrvr2
config match
edit 0
set server-name RADIUSsrvr2
set group-name usergroup1
end
end
Note: Matching user group names from an external authentication server might not work if
the list of group memberships for the user is longer than 8000 bytes. Group names beyond
this limit are ignored.
For more information about user group CLI commands, see the Fortinet CLI Guide.
Directory Service user groups

A Directory Service user group contains only Windows or Novell network user groups. No
other user types are permitted as members. Information about the Windows or Novell user
groups and the logon activities of their members is provided by the Fortinet Server
Authentication Extension (FSAE) which is installed on the network domain controllers.
You can specify Directory Service user groups in identity-based firewall policies in the
same way as you specify firewall user groups. Directory Service user groups cannot have
SSL VPN or dialup IPsec VPN access.
For information about configuring Directory Services user groups, see “Creating Directory
Service user groups” on page 957. For complete information about installing and
configuring FSAE, see “FSAE for integration with Windows AD or Novell” on page 933.
Configuring Peer user groups

Peer user groups can only be configured using the CLI. Peers are digital certificate
holders defined using the config user peer command. The peer groups you define
here are used in dialup IPsec VPN configurations that accept RSA certificate
authentication from members of a peer certificate group. For more information, see
“Authenticating IPsec VPN users with security certificates” on page 971.
To create a peer group - CLI example

config user peergrp
edit vpn_peergrp1
set member pki_user1 pki_user2 pki_user3
end

01-420-99686-20101026 921
User groups Users and user groups
Viewing, editing and deleting user groups

To view the list of FortiGate user groups, go to User > User Group.
Figure 85:Example User group list
To edit a user group - web-based manager

2 Select the check box for the user group that you want to edit.
3 Select the Edit button.
4 Modify the user group as needed.
5 Select OK.
To edit a user group - CLI example

This example adds user3 to Group1. Note that you must re-specify the full list of users:
config user group
edit Group1
set member user2 user4 user3
end
To remove a user group - web-based manager

2 Select the check box for the user group that you want to remove.
3 Select the Delete button.
4 Select OK.
To remove a user group - CLI example

config user group
delete Group2
end
Note: You cannot remove a user group that is part of a firewall policy. Remove it from the
firewall policy first.

922 01-420-99686-20101026
Configuring authenticated access
When you have configured authentication servers, users, and user groups, you are ready
to configure firewall policies and certain types of VPNs to require user authentication.
This section describes:
• Authentication timeout
• Authentication protocols
• Authentication in firewall policies
• VPN authentication
Authentication timeout
You set the firewall user authentication timeout to control how long an authenticated
connection can be idle before the user must authenticate again. The maximum timeout is
480 minutes (8 hours).
To set the firewall authentication timeout

1 Go to User > User > Authentication.
2 Enter the Authentication Timeout value in minutes.
The default authentication timeout is 5 minutes.
3 Select Apply.
You set the SSL VPN user authentication timeout (Idle Timeout) to control how long an
authenticated connection can be idle before the user must authenticate again. The
maximum timeout is 28800 seconds. The default timeout is 300 seconds.
To set the SSL VPN authentication timeout

1 Go to VPN > SSL > Config.
2 Enter the Idle Timeout value (seconds).
3 Select Apply.
Password policy
Password authentication is effective only if the password is sufficiently strong and is
changed periodically. By default, the FortiGate unit requires only that passwords be at
least eight characters in length. You can set a password policy to enforce higher standards
for both length and complexity of passwords. Password policies can apply to administrator
passwords or IPsec VPN preshared keys.
To set a password policy in the web-based manager, go to System > Admin > Settings.
In the CLI, use the config system password-policy command.
Password length
The default minimum password length on the FortiGate unit is eight characters, but up to
32 characters is permitted. Security experts suggest a minimum length of 14 characters.

01-420-99686-20101026 923
Authentication protocols Configuring authenticated access
Password complexity
Users usually create passwords composed of alphabetic characters and perhaps some
numbers. Password policy can require the inclusion of upper case letters, lower case
letters, numerals or punctuation characters.
Suggestions for users

In addition to length and complexity, there are security factors that cannot be enforced in a
policy but should be encouraged through guidelines issued to users:
Avoid:
• words found in a dictionary of any language
• numeric sequences, such as “12345”
• sequences of adjacent keyboard characters, such as “qwerty”
• repeated characters
• personal information, such as your name, birthday, or telephone number
Include:
• one or more upper case characters
• one or more of the numerals
• one or more non alpha-numeric characters, such as punctuation marks
Authentication protocols
When user authentication is enabled on a firewall policy, the authentication challenge is
normally issued for any of the four protocols, HTTP, HTTPS, FTP, and Telnet, which are
dependent on the connection protocol. By making selections in the Protocol Support list,
the user controls which protocols support the authentication challenge. The user must
connect with a supported protocol first, so that they can subsequently connect with other
protocols.
For example, if you have selected HTTP, FTP, or Telnet, a user name and password-
based authentication occurs. The FortiGate unit then prompts network users to input their
firewall user name and password. If you have selected HTTPS, certificate-based
authentication (HTTPS, or HTTP redirected to HTTPS only) occurs.
For certificate-based authentication, you must install customized certificates on the
FortiGate unit and on the browsers of network users. If you do not install certificates on the
network user’s web browser, the network users may see an SSL certificate warning
message and have to manually accept the default FortiGate certificate. The network
user’s web browser may deem the default certificate as invalid.
When you use certificate authentication, if you do not specify any certificate when you
create the firewall policy, the global settings are used. If you specify a certificate, the per-
policy setting will overwrite the global setting. For more information about the use of
certification authentication see “Certificate-based authentication” on page 961.
To set the authentication protocols

1 Go to User > User > Authentication.
2 In Protocol Support, select the required authentication protocols.
3 If using HTTPS protocol support, in Certificate, select a Local certificate from the drop-
down list.
4 Select Apply.

924 01-420-99686-20101026
Configuring authenticated access Authentication in firewall policies
Figure 86: Authentication Settings
Authentication in firewall policies

Firewall policies control traffic between FortiGate interfaces, both physical interfaces and
VLAN subinterfaces. Without authentication, a firewall policy enables access from one
network to another for all users on the source network. Authentication enables you to
allow access only for users who are members of selected user groups. To include
authentication in a firewall policy, you must create an identity-based policy.
The style of the authentication method varies by the authentication protocol. If you have
selected HTTP, FTP or Telnet, a user name and password-based authentication occurs.
The FortiGate unit prompts network users to input their firewall user name and password.
If you have selected HTTPS, certificate-based authentication (HTTPS or HTTP redirected
to HTTPS only) occurs. You must install customized certificates on the FortiGate unit and
on the browsers of network users, which the FortiGate unit matches.
Note: You can configure user authentication for firewall policies only when Action is set to
Accept.
Configuring authentication for a firewall policy

To include authentication in a firewall policy, you must create an identity-based policy.
To create an identity based firewall policy

1 Create users and one or more Firewall user groups.
For more information, see “Users and user groups” on page 915.
3 Select Create New to create a new policy or select an existing policy and the select the
Edit icon.
4 Make sure that the Action for the policy is ACCEPT.
5 Select Enable Identity Based Policy and then select Add.

01-420-99686-20101026 925
Authentication in firewall policies Configuring authenticated access
Figure 87: Adding an identity-based policy
6 In the Available User Groups list, select the user groups that will be allowed to use this
policy and then select the right arrow button to move them to the Selected User Groups
list.
7 From from the Available Services list, select the services users will be allowed to
access and then select the right arrow button to move them to the Selected Services
list.
To enable use of all services, select the ANY service.
8 Set other options as required and then select OK.
Figure 88: Identity Based Policy list and options in firewall policy
9 If users will use a certificate for authentication, from the Certificate list select the CA
certificate to use to validate the users’ certificates.

926 01-420-99686-20101026
Configuring authenticated access VPN authentication
10 To require the user to accept a disclaimer to connect to the destination, select Enable
Disclaimer. If the user is to be redirected after accepting the disclaimer, enter the URL
in the Redirect URL to field.
You can edit the User Authentication Disclaimer replacement message text in
System > Config > Replacement Messages.
11 Select OK.
Configuring authenticated access to the Internet

A policy for accessing the Internet is similar to a policy for accessing a specific network,
but the destination address is set to all. The destination interface is the one that connects
to the Internet service provider. For general purpose Internet access, the Service is set to
ANY.
Access to HTTP, HTTPS, FTP and Telnet sites may require access to a domain name
service. DNS requests do not trigger authentication. You must configure a policy to permit
unauthenticated access to the appropriate DNS server, and this policy must precede the
policy for Internet access.
VPN authentication
All VPN configurations require users to authenticate. Authentication based on user groups
applies to:
• SSL VPNs
• PPTP and L2TP VPNs
• an IPsec VPN that authenticates users using dialup groups
• a dialup IPsec VPN that uses XAUTH authentication (Phase 1)
You must create user accounts and user groups before performing the procedures in this
section. If you create a user group for dialup IPsec clients or peers that have unique peer
IDs, their user accounts must be stored locally on the FortiGate unit. You cannot
authenticate these types of users using a RADIUS or LDAP server.
Configuring authentication of SSL VPN users

The general procedure for authenticating SSL VPN users is:
1 Configure user accounts.
2 Create one or more firewall user groups for SSL VPN users.
See “Configuring user accounts and user groups for SSL VPN” in the SSL VPN
chapter of this FortiOS Handbook.
3 Enable SSL VPN.
4 Optionally, set inactivity and authentication timeouts.
5 Configure a firewall policy with SSL VPN action. Add an identity-based rule to allow
access for the user groups you created for SSL VPN users.
See “Configuring firewall policies” in the SSL VPN chapter of this FortiOS Handbook.
Configuring authentication timeout

By default, the SSL VPN authentication expires after 8 hours (28 800 seconds). You can
change it only in the CLI, and the time entered must be in seconds. For example, to
change the timeout to one hour, you would enter:

01-420-99686-20101026 927
VPN authentication Configuring authenticated access
set auth-timeout 3600

end
When you configure the timeout settings, if you set the authentication timeout
(auth-timeout) to 0, then the remote client does not have to re-authenticate again
unless they log out of the system. To fully take advantage of this setting, the value for
idle-timeout has to be set to 0 also, so that the client does not time out if the maximum
idle time is reached. If the idle-timeout is not set to the infinite value, the system will
log out if it reaches the limit set, regardless of the auth-timeout setting.
Configuring authentication of remote IPsec VPN users

An IPsec VPN on a FortiGate unit can authenticate remote users through a dialup group.
The user account name is the peer ID and the password is the pre-shared key.
Authentication through user groups is supported for groups containing only local users. To
authenticate users using a RADIUS or LDAP server, you must configure XAUTH settings.
See “Configuring XAuth authentication” on page 929.
To configure user group authentication for dialup IPsec - web-based manager

1 Configure the dialup users who are permitted to use this VPN. Create a user group
with Type:Firewall and add them to it.
2 Go to VPN > IPsec > Auto Key (IKE), select Create Phase 1 and enter the following
information.
Figure 89: Configure VPN IPsec dialup authentication
Name Name for group of dialup users using the VPN for authentication.
Remote Gateway List of the types of remote gateways for VPN. Select Dialup User.
Authentication Method List of authentication methods available for users. Select
Preshared Key and enter the preshared key.
Peer Options Select Accept peer ID in dialup group. Select the user group that is
to be allowed access to the VPN. The listed user groups contain
only users with passwords on the FortiGate unit.

928 01-420-99686-20101026
Note: The Accept peer ID in dialup group option does not support authentication of users
through an authentication server. The user accounts must exist on the FortiGate unit.
3 Select Advanced to reveal additional parameters and configure other VPN gateway
parameters as needed.
4 Select OK.
To configure user group authentication for dialup IPsec - CLI example

The peertype and usrgrp options configure user group based authentication.
edit office_vpn
set interface port1
set type dynamic
set psksecret yORRAzltNGhzgtV32jend
set proposal 3des-sha1 aes128-sha1
set peertype dialup
set usrgrp Group1
end
Configuring XAuth authentication

Extended Authentication (XAuth) increases security by requiring additional user
authentication information in a separate exchange at the end of the VPN Phase 1
negotiation. The FortiGate unit asks the user for a user name and password. It then
forwards the user’s credentials (the password is encrypted) to an external RADIUS or
LDAP server for verification.
XAuth can be used in addition to or in place of IPsec phase 1 peer options to provide
access security through an LDAP or RADIUS authentication server. You must configure a
dialup user group whose members are all externally authenticated. None of these users
can have their passwords stored on the FortiGate unit.
To configure authentication for a dialup IPsec VPN - web-based manager

1 Configure the users who are permitted to use this VPN. Create a user group and add
them to it.
3 Select Create Phase 1 and configure the basic VPN phase1 settings.
Remote Gateway must be Dialup User.
4 Select Advanced to reveal additional parameters and enter the following information.
XAuth Select Enable as Server.

Server Type Select PAP, CHAP, or AUTO. Use CHAP whenever possible. Use PAP
with all implementations of LDAP and with other authentication servers
that do not support CHAP, including some implementations of Microsoft
RADIUS. Use AUTO with the Fortinet Remote VPN Client and where
the authentication server supports CHAP but the XAuth client does not.
User Group Select the user group that is to have access to the VPN. The list of user
groups does not include any group that has members whose password
is stored on the FortiGate unit.
5 Select OK.

01-420-99686-20101026 929
For more information about XAUTH configuration, see the IPsec VPN chapter of this
FortiOS Handbook.
To configure authentication for a dialup IPsec VPN - CLI example

The xauthtype and authusrgrp fields configure XAuth authentication.
edit office_vpn
set interface port1
set type dynamic
set psksecret yORRAzltNGhzgtV32jend
set peertype dialup
set xauthtype pap
set authusrgrp Group1
end
Some parameters specific to setting up the VPN itself are not shown here. For detailed
information about configuring an IPsec VPN, see the IPsec VPN chapter of this FortiOS
Handbook.
Configuring authentication of PPTP VPN users and user groups

Configuration of a PPTP VPN is possible only through the CLI. You can configure user
groups and firewall policies using either CLI or web-based manager.
To configure authentication for a PPTP VPN

1 Configure the users who are permitted to use this VPN. Create a firewall user group
and add them to it.
2 Configure the PPTP VPN in the CLI as in this example.
config vpn pptp
set status enable
set sip 192.168.0.100
set eip 192.168.0.110
set usrgrp PPTP_Group
end
The sip and eip fields define a range of virtual IP addresses assigned to PPTP
clients.
3 Configure a firewall policy. The source interface is the one through which the clients will
connect. The source address is the PPTP virtual IP address range. The destination
interface and address depend on the network to which the clients will connect. The
policy action is ACCEPT.
Configuring authentication of L2TP VPN users/user groups

Configuration of a L2TP VPN is possible only through the CLI. You can configure user
groups and firewall policies using either CLI or web-based manager.
To configure authentication for a PPTP VPN

1 Configure the users who are permitted to use this VPN. Create a firewall user group
and add them to it.

930 01-420-99686-20101026
2 Configure the L2TP VPN in the CLI as in this example.

config vpn l2tp
set status enable
set sip 192.168.0.100
set eip 192.168.0.110
set usrgrp L2TP_Group
end
The sip and eip fields define a range of virtual IP addresses assigned to L2TP
clients.
3 Configure a firewall policy. The source interface is the one through which the clients will
connect. The source address is the L2TP virtual IP address range. The destination
interface and address depend on the network to which the clients will connect. The
policy action is ACCEPT.

01-420-99686-20101026 931

932 01-420-99686-20101026
FSAE for integration with Windows
AD or Novell
This chapter provides an overview of the Fortinet Server Authentication Extension
(FSAE). The following topics are included:
• Introduction to FSAE
• Installing FSAE
• Configuring FSAE on Windows AD
• Configuring FSAE on FortiGate units
• Testing the configuration
Introduction to FSAE
The Fortinet Server Authentication Extension (FSAE) provides seamless authentication
support for Microsoft Windows Active Directory and Novell eDirectory users in a FortiGate
environment.
On a Microsoft Windows or Novell network, users authenticate with the Active Directory or
Novell eDirectory at logon. It would be inconvenient if users then had to enter another user
name and password for network access through the FortiGate unit. FSAE provides
authentication information to the FortiGate unit so that users automatically get access to
permitted resources.
There are several mechanisms for passing user authentication information to the
FortiGate unit:
• FSAE software installed on a Novell network monitors user logons and sends the
required information to the FortiGate unit. The FSAE software can obtain information
from the Novell eDirectory using either the Novell API or LDAP.
• FSAE software installed on a Windows AD network monitors user logons and sends
the required information to the FortiGate unit. The FSAE software can obtain this
information by polling the domain controllers or by using an agent on each domain
controller that monitors user logons in real time. Optionally, a FortiGate unit running
FortiOS 3.0 MR6 or later can obtain group information directly from the AD using
Lightweight Directory Access Protocol (LDAP).
• On a Windows AD network, the FSAE software can also serve NTLM requests coming
from client browsers (forwarded by the FortiGate unit).
Using FSAE in a Windows AD environment

FSAE installed in a Windows AD environment can provide two kinds of services:
• Monitor user logon activity and send the information to FortiGate unit so that the
FortiGate unit can support Single Sign On (SSO).
• Provide NTLM authentication service for requests coming from FortiGate.

01-420-99686-20101026 933
Introduction to FSAE FSAE for integration with Windows AD or Novell
FSAE user logon monitoring

FSAE installed in a Windows Active Directory environment can monitor which user is
logged on to which workstation and pass that information to the FortiGate unit which can
use that information to apply its firewall policies.
When a Windows AD user logs in at a workstation, FSAE
• detects the logon event and records workstation name, domain, and user,
• resolves the workstation name to an IP address,
• uses Active Directory to determine which groups the user belongs to,
• sends the user logon information, including IP address and groups list, to the FortiGate
unit.
When the user tries to access network resources, the FortiGate unit selects the
appropriate firewall policy for the destination. If the user belongs to one of the permitted
user groups, the connection is allowed.
FSAE can use either of two different methods to monitor user logon activity: DC Agent
mode or Polling mode.
DC Agent mode
In DC Agent mode (see Figure 90), an agent is installed on each domain controller to
monitor user logon events and pass the information to the FSAE collector agent, which
forwards the information to the FortiGate unit.
Figure 90: FSAE in DC agent mode
l led
ith sta
e r w ent in
v
er ag
s s or
nit update d ow llect
a te u n
Wi E C
o
rti G A
Fo FS
update
ith
e r s wlled
l
ol ta
ntr ins
r
se
Co gent
U
nt
i n
lie
ma C a
C
Do E D
A
FS
DC Agent mode provides reliable user logon information, however you must install a DC
agent on every domain controller in the domain. A reboot is needed after the agent is
installed.

934 01-420-99686-20101026
FSAE for integration with Windows AD or Novell Introduction to FSAE
Polling mode
In Polling mode (see Figure 91), the FSAE collector agent polls each domain controller for
user logon information and forwards it to the FortiGate unit.
Figure 91: FSAE in Polling mode
lled
ith sta
e r w ent in
v
er ag
s s or
uni
t update d ow llect
n o
i G ate Wi E C
rt A
Fo FS
poll
rs
trolle
on
r
se
C
U
in
nt
ma
lie
Do
C
The polling mode provides logon information less reliably. For example, under heavy
system load a poll might miss some user logon events. However, you do not need to install
a DC agent on each domain controller.
NTLM authentication with FSAE

In a Windows AD network, FSAE can also provide NTLM authentication service to the
FortiGate unit (see Figure 92). When the user makes a request that requires
authentication, the FortiGate unit initiates NTLM negotiation with the client browser. The
FortiGate unit does not process the NTLM packets itself. Instead, it forwards all the NTLM
packets to the FSAE service to process.
If the NTLM authentication with the Windows AD network is successful, and the user
belongs to one of the groups permitted in the relevant firewall policy, the FortiGate unit
allows the connection. Fortinet has tested NTLM authentication on Internet Explorer and
Firefox browsers.

01-420-99686-20101026 935
Introduction to FSAE FSAE for integration with Windows AD or Novell
Figure 92: NTLM FSAE implementation
t
en
ag ver
c tor ser
lle D
Co er A
S AE emb
F m
a
on
unit
ate
ortiG
F
rs
olle
ntr
r
o
se
nC
U
i
nt
ma
lie
Do
C
Understanding the NTLM authentication process

1 The user attempts to connect to an external (internet) HTTP resource. The client
application (browser) on the user’s computer issues an unauthenticated request
2 The FortiGate is aware that this client has not authenticated previously, so responds
with a 401 Unauthenticated status code, and tells the client which authentication
method to reply with in the header: Proxy-Authenticated: NTLM. The session is
dismantled.
3 The client application connects again, and issues a GET-request, with a
Proxy-Authorization: NTLM <negotiate string> header.
<negotiate-string> is a base64-encoded NTLM Type 1 negotiation packet.
4 The FortiGate unit replies with a 401 “proxy auth required” status code, and a
Proxy-Authenticate: NTLM <challenge string> (a base 64-encoded NTLM
Type 2 challenge packet). In this packet is the challenge nonce, a random number
chosen for this negotiation that is used once and prevents replay attacks.
Note: The TCP connection must be kept alive, as all subsequent authentication-related
information is tied to the TCP connection. If it is dropped, the authentication process must
start again from the beginning.
5 The client sends a new GET-request with a header: Proxy-Authenticate: NTLM

<authenticate string>, where <authenticate string> is a NTLM Type 3
Authentication packet that contains:
• user name and domain
• the challenge nonce encoded with the client password (it may contain the challenge
nonce twice using different algorithms).

936 01-420-99686-20101026
FSAE for integration with Windows AD or Novell Installing FSAE
6 If the negotiation is successful and the user belongs to one of the groups permitted in
the firewall policy, the connection is allowed, Otherwise, the FortiGate unit denies the
authentication by issuing a 401 return code and prompts for a username and
password. Unless the TCP connection is broken, no further credentials are sent from
the client to the proxy.
Note: If the authentication policy reaches the authentication timeout period, a new NTLM
handshake occurs.
Using FSAE in a Novell eDirectory environment

FSAE in a Novell eDirectory environment works similar to the FSAE Polling mode in the
Windows AD environment. The FSAE eDirectory agent polls the eDirectory servers for
user logon information and forwards it to the FortiGate unit.
When a user logs on at a workstation, FSAE
• detects the logon event by polling the eDirectory server and records the IP address
and user ID,
• looks up in the eDirectory which groups this user belongs to,
• sends the IP address and user groups information to the FortiGate unit.
When the user tries to access network resources, the FortiGate unit selects the
appropriate firewall policy for the destination. If the user belongs to one of the permitted
user groups, the connection is allowed.
Operating system requirements

Consult the FortiOS v4.0 MR2 Release Notes for operating system compatibility
information.
Installing FSAE
The components you need to install depend on whether you are installing FSAE on
Windows AD or Novell eDirectory.
FSAE components for Windows AD

FSAE has two components to install on your network:
• the collector agent must be installed on at least one network computer
• the domain controller (DC) agent must be installed on every domain controller if you
will use DC Agent mode, but is not required if you use Polling mode.
The FSAE installer first installs the collector agent. You can then continue with installation
of the DC agent, or install it later by going to Start > Programs > Fortinet >
Fortinet Server Authentication Extension > Install DC Agent. The installer installs a DC
agent on the domain controllers of all of the trusted domains in your network.
If you install the collector agent on two or more computers, you can create a redundant
configuration on the FortiGate unit for greater reliability. If the current collector agent fails,
the FortiGate unit switches to the next one in its list of up to five collector agents.
You must install FSAE using an account that has administrator privileges. You can use the
default Administrator account, but then you must re-configure FSAE each time the
account password changes. Fortinet recommends that you create a dedicated account
with administrator privileges and a password that does not expire.

01-420-99686-20101026 937
Installing FSAE FSAE for integration with Windows AD or Novell
FSAE components for Novell eDirectory

For a Novell network, there is only one FSAE component to install, the FSAE eDirectory
agent. In some cases, you also need to install the Novell Client.
Installing FSAE for Windows AD

To install FSAE, you must obtain the FSAE Setup file from the Fortinet Support web site.
Perform the following installation procedure on the computer that will run the Collector
Agent. This can be any server or domain controller that is part of your network. The
procedure also installs the DC Agent on all of the domain controllers in your network.
To install the FSAE collector agent

1 Create an account with administrator privileges and a password that does not expire.
See Microsoft Advanced Server documentation for more information.
2 Log in to the account that you created in Step 1.
3 Double-click the FSAESetup.exe file.
The FSAE InstallShield Wizard starts.
4 Select Next. Optionally, you can change the FSAE installation location.
5 Select Next.
6 In the Password field, enter the password for the account listed in the User Name field.
This is the account you are logged into currently.
7 Select Next.
8 By default, FSAE authenticates users both by monitoring logons and by accepting
authentication requests using the NTLM protocol.
If you want to support only NTLM authentication
• Clear the Monitor user logon events and send the information to Fortinet check box.
• Select the Serve NTLM authentication requests coming from FortiGate check box.
If you do not want to support NTLM authentication
• Clear the Serve NTLM authentication requests coming from FortiGate check box.
• Select the Monitor user logon events and send the information to Fortinet check
box.
You can also change these options after installation.
9 Select the access method to use for Windows Directory:
• Select Standard to use Windows domain and user name credentials.
• Select Advanced if you will set up LDAP access to Windows Directory.
10 Select Next and then select Install.
11 For DC Agent mode, when the FSAE InstallShield Wizard completes FSAE collector
agent installation, ensure that Launch DC Agent Install Wizard is selected and then
select Finish.
To install the DC Agent

1 If you have just installed the FSAE collector agent, the FSAE - Install DC Agent wizard
starts automatically. Otherwise, go to Start > Programs > Fortinet > Fortinet Server
Authentication Extension > Install DC Agent.

938 01-420-99686-20101026
FSAE for integration with Windows AD or Novell Installing FSAE
2 Verify the Collector Agent IP address.

If the Collector Agent computer has multiple network interfaces, ensure that the one
that is listed is on your network. The listed Collector Agent listening port is the default.
You should change this only if the port is already used by some other service.
3 Select Next.
4 Select the domains to monitor and select Next.
If any of your required domains are not listed, cancel the wizard and set up the proper
trusted relationship with the domain controller. Then run the wizard again by going to
Start > Programs > Fortinet > Fortinet Server Authentication Extension >
Install DC Agent.
5 Optionally, select users that you do not want monitored. These users will not be able to
authenticate to FortiGate units using FSAE. You can also do this later. See
“Configuring FSAE on Windows AD” on page 940.
6 Select Next.
7 Optionally, clear the check boxes of domain controllers on which you do not want to
install the FSAE DC Agent.
8 Select the Working Mode: DC Agent Mode or Polling Mode. For more information, see
“DC Agent mode” on page 934 and “Polling mode” on page 935.
9 Select Next.
10 Select Yes when the wizard requests that you reboot the computer.
Note: If you reinstall the FSAE software on this computer, your FSAE configuration is
replaced with default settings.
If you want to create a redundant configuration, repeat the procedure “To install the FSAE
collector agent” on page 938 on at least one other Windows AD server.
Note: When you start to install a second collector agent, when the Install Wizard dialog
appears the second time, cancel it. From the configuration GUI, the monitored domain
controller list should show your domain controllers unselected. Select the ones you wish to
monitor with this collector agent, and click Apply.
Before you can use FSAE, you need to configure it on both Windows AD and on the
FortiGate units. See the next section, “Configuring FSAE on Windows AD”, and
“Configuring FSAE on FortiGate units” on page 952.
Installing FSAE for Novell

To install FSAE, you must obtain the FSAE_Setup_eDirectory file from the Fortinet
Support web site. Perform the following installation procedure on the computer that will
run the FSAE eDirectory agent. This can be any server or domain controller that is part of
your network.
To install the FSAE eDirectory agent

1 Create an account with administrator privileges and a password that does not expire.
See Novell documentation for more information.
2 Log in to the account that you created in Step 1.
3 Double-click the FSAE_Setup_edirectory.exe file.
The Fortinet eDirectory Agent InstallShield Wizard starts.

01-420-99686-20101026 939
Configuring FSAE on Windows AD FSAE for integration with Windows AD or Novell
4 Optionally, fill in the User Name and Organization fields.

5 Select the Anyone who uses this computer (all users) option.
6 Select Next.
7 Optionally, enter any of the following information:
You can also enter or modify this information after installation. See “Configuring FSAE
on Novell networks” on page 949.
eDirectory Server
Server Address Enter the IP address of the eDirectory server.
Use secure connection Select to connect to the eDirectory server
(SSL) using SSL security.
Search Base DN Enter the base Distinguished Name for the
user search.
eDirectory Authentication
User name Enter a user name that has access to the
eDirectory, using LDAP format.
User password Enter the password.
8 Select Next.
9 Select Install.
Configuring FSAE on Windows AD

On the FortiGate unit, firewall policies control access to network resources based on user
groups. Each FortiGate user group is associated with one or more Windows AD user
groups.
FSAE sends information about Windows user logons to FortiGate units. If there are many
users on your Windows AD domains, the large amount of information might affect the
performance of the FortiGate units. To avoid this problem, you can configure the FSAE
collector agent to send logon information only for groups named in the FortiGate unit’s
firewall policies.
On each computer that runs a collector agent, you need to configure
• Windows AD user groups
• collector agent settings, including the domain controllers to be monitored
• the collector agent Ignore User list
• the collector agent FortiGate Group Filter for each FortiGate unit
• LDAP access settings, if LDAP is used to obtain group information
Note: In some environments where user IP addresses change frequently, it might be

necessary to configure the alternate IP address tracking method. For more information, see
“Configuring alternate user IP address tracking” on page 946.
Configuring Windows AD server user groups

FortiGate units control access at the group level. All members of a group have the same
network access as defined in FortiGate firewall policies. You can use existing Windows AD
user groups for authentication to FortiGate units if you intend that all members within each
group have the same network access privileges. Otherwise, you need to create new user
groups for this purpose.

940 01-420-99686-20101026
FSAE for integration with Windows AD or Novell Configuring FSAE on Windows AD
If you change a user’s group membership, the change does not take effect until the user
logs off and then logs on again.
FSAE sends only Domain Local Security Group and Global Security Group information to
FortiGate units. You cannot use Distribution group types for FortiGate access. No
information is sent for empty groups.
Refer to Microsoft documentation for information about creating groups.
Configuring collector agent settings

You need to configure which domain controllers you use and which domains you monitor
for user logons. You can also alter default settings and settings you made during
installation.
To configure the FSAE collector agent

1 From the Start menu select Programs > Fortinet >
Fortinet Server Authentication Extension > Configure FSAE.
2 Enter the following information and then select Save&Close.
Monitoring user logon events Select to automatically authenticate users as they log on to
the Windows domain.
Support NTLM authentication Select to facilitate logon of users who are connected to a
domain that does not have the DC Agent installed.
Collector Agent Status Shows RUNNING when collector agent is active.
Listening ports You can change port numbers if necessary.
FortiGate TCP port for FortiGate units. Default 8000.
DC Agent UDP port that DC Agents use. Default 8002.
Logging
Log level Select the minimum severity level of logged messages.
Log file size limit (MB) Enter the maximum size for the log file in MB.
View Log View all FSAE logs.

01-420-99686-20101026 941
Log logon events in Record user login-related information separately from other
separate logs logs. The information in this log includes
• data received from DC agents
• user logon/logoff information
• workstation IP change information
• data sent to FortiGate units
View Logon Events If Log logon events in separate logs is enabled, you can
view user login-related information.
Authentication
Require authenticated Select to require the FortiGate unit to authenticate before
connection from FortiGate connecting to the Collector Agent.
Password Enter the password that FortiGate units must use to
authenticate. The maximum password length is 16
characters. The default password is “fortinetcanada”.
Timers
Workstation verify interval Enter the interval in minutes at which FSAE checks whether
(minutes) the user is still logged in. The default is every 5 minutes.
If ports 139 or 445 cannot be opened on your network, set
the interval to 0 to prevent checking. See “Configuring TCP
ports for FSAE on client computers” on page 946.
Dead entry timeout interval Enter the interval in minutes after which FSAE purges
information for user logons that it cannot verify. The default
is 480 minutes (8 hours).
Dead entries usually occur because the computer is
unreachable (in standby mode or disconnected, for
example) but the user has not logged off.
You can also prevent dead entry checking by setting the
interval to 0.
IP address change verify FSAE periodically checks the IP addresses of logged-in
interval users and updates the FortiGate unit when user IP
addresses change. This does not apply to users
authenticated through NTLM. Enter the verification interval
in seconds. IP address verification prevents users from
being locked out if they change IP addresses. You can enter
0 to prevent IP address checking if you use static IP
addresses.
Cache user group lookup result Enable caching.
Cache expire in (minutes) FSAE caches group information for logged-in users. Enter
the duration in minutes after which the cache entry expires.
If you enter 0, the cache never expires.
Clear Group Cache Clear group information of logged-in users.
Common Tasks
Show Service Status View information about the status of the collector agent and
connected FortiGate units. See “Viewing collector agent
status” on page 946.
Show Monitored DCs Shows detailed information about connected DC agents.
Use the Select DC to Monitor button to select domain
controllers to monitor and choose Working Mode. See
“Selecting Domain Controllers and working mode for
monitoring” on page 948.
Show Logon Users View a list of currently logged-in users. Select the column
headers to sort the list.
Select Domains to Monitor Select this button to remove domains that you do not want to
monitor. From the Domain Filter dialog box that displays,
clear check boxes for unwanted domains and select OK.
Set Directory Access See “Configuring Directory Access settings” on page 943.
Information

942 01-420-99686-20101026
Set Group Filters Configure group filtering for each FortiGate unit. See
“Configuring FortiGate group filters” on page 944.
Set Ignore User List Exclude users such as system accounts that do not
authenticate to any FortiGate unit. See “Configuring the
Ignore User List” on page 943.
Sync Configuration With Copy this collector agent's Ignore User List and Group
Other Agents Filters to the other collector agents to synchronize the
configuration. You are asked to confirm synchronization for
each collector agent.
Export Configuration Export FSAE configuration to a text file. The file is named
“saved_config.txt” and is saved in the FSAE program
directory.
Save & Close Save the modified settings and exit.
Apply Apply changes now.
Default Change all settings to the default values.
Help View the online Help.
Note: To view the version and build number information for your FSAE configuration,
click the Fortinet icon in the upper left corner of the Fortinet Collector Agent
Configuration screen and select “About FSAE configuration”
Configuring Directory Access settings

FSAE can access Windows Active Directory in one of two modes:
• Standard — FSAE receives group information from the collector agent in the form
domain\group. This is available on FortiOS 3.0 and later.
• Advanced — FSAE obtains user group information using LDAP. This is compatible with
FortiOS 3.0 MR6 and later. Group information is in LDAP format.
If you change AD access mode, you must reconfigure your group filters to ensure that the
group information is in the correct format.
To configure Directory Access settings

2 In the Common Tasks section, select Set Directory Access Information.
The Set Directory Access Information dialog box opens.
3 From the AD access mode list, select either Standard or Advanced.
4 If you selected Advanced AD access mode, select Advanced Setting and configure the
following settings and then select OK:
AD server address Enter the address of your network’s global catalog server.
AD server port The default AD server port is 3268. Change this only if your server
uses a different port.
BaseDN Enter the Base distinguished name for the global catalog.
User name If the global catalog accepts your FSAE agent’s credentials, you can
leave these fields blank. Otherwise, enter credentials for an account
Password that can access the global catalog.
Configuring the Ignore User List

The Ignore User List excludes users such as system accounts that do not authenticate to
any FortiGate unit. The logons of these users are not reported to FortiGate units.

01-420-99686-20101026 943
To configure the Ignore User List

2 In the Common Tasks section, select Set Ignore User List.
The current list of ignored users is displayed. You can expand each domain to view the
names of ignored users.
3 Do any of the following:
• To remove a user from the list, select the check box beside the user name and then
select Remove. The user’s login is no longer ignored.
• To add users to be ignored, select Add, select the check box beside each required
user name, and then select Add.
4 Select OK.
Configuring FortiGate group filters

FortiGate filters control the user logon information sent to each FortiGate unit. You need to
configure the list so that each FortiGate unit receives user logon information for the user
groups that are named in its firewall policies.
You do not need to configure a group filter on the collector agent if the FortiGate unit
retrieves group information from Windows AD using LDAP. In that case, the collector
agent uses as its filter the list of groups you selected on the FortiGate unit.
The filter list is initially empty. You need to configure filters for your FortiGate units using
the Add function. At minimum, you should create a default filter that applies to all FortiGate
units that do not have a specific filter defined for them.
Note: If no filter is defined for a FortiGate unit and there is no default filter, the collector
agent sends all Windows AD group and user logon events to the FortiGate unit. While this
normally is not a problem, limiting the amount of data sent to the FortiGate unit improves
performance by reducing the amount of memory the unit uses to store the group list.
To configure a FortiGate group filter

2 In the Common Tasks section, select Set Group Filters.
The FortiGate Filter List opens. It has the following columns:

944 01-420-99686-20101026
FortiGate SN The serial number of the FortiGate unit to which this filter applies.
Description An optional description of the role of this FortiGate unit.
Monitored The Windows AD user groups that are relevant to the firewall policies
Groups on this FortiGate unit.
Add Create a new filter.
Edit Modify the filter selected in the list.
Remove Remove the filter selected in the list.
OK Save the filter list and exit.
Cancel Cancel changes and exit.
3 Select Add to create a new filter. If you want to modify an existing filter, select it in the
list and then select Edit.
4 Enter the following information and then select OK.
Default filter Select to create the default filter. The default filter applies to any
FortiGate unit that does not have a specific filter defined in the list.
FortiGate Serial Enter the serial number of the FortiGate unit to which this filter applies.
Number This field is not available if Default is selected.
Description Enter a description of this FortiGate unit’s role in your network. For
example, you could list the resources accessed through this unit. This
field is not available if Default is selected.
Monitor the following The collector agent sends to the FortiGate unit the user logon
groups information for the Windows AD user groups in this list. Edit this list
using the Add, Advanced and Remove buttons.
Add In the preceding single-line field, enter the Windows AD domain name
and user group name, and then select Add. If you don’t know the exact
name, use the Advanced button instead.
The format of the entry depends on the AD access mode (see
“Configuring Directory Access settings” on page 943):
Standard: Domain\Group
Advanced: cn=group, ou=corp, dc=domain

01-420-99686-20101026 945
Advanced Select Advanced, select the user groups from the list, and then select
Add.
Remove Remove the user groups selected in the monitor list.
Configuring TCP ports for FSAE on client computers

Windows AD records when users log on but not when they log off. For best performance,
FSAE monitors when users log off. To do this, FSAE needs read-only access to each
client computer’s registry over TCP port 139 or 445. At least one of these ports should be
open and not blocked by firewall policies.
If it is not feasible or acceptable to open TCP port 139 or 445, you can turn off FSAE logoff
detection. To do this, set the collector agent workstation verify interval to 0. FSAE
assumes that the logged on computer remains logged on for the duration of the collector
agent dead entry timeout interval. By default this is eight hours. For more information
about both interval settings, see “Timers” on page 942.
Configuring ports on the collector agent computer

On the computer where you install the collector agent, you must make sure that the
firewall does not block the listening ports for the FortiGate unit and the DC Agent. By
default, these are TCP port 8000 and UDP port 8002. For more information about setting
these ports, see “To configure the FSAE collector agent” on page 941.
Configuring alternate user IP address tracking

In environments where user IP addresses change frequently, you can configure FSAE to
use an alternate method to track user IP address changes. Using this method, FSAE
responds more quickly to user IP address changes because it directly queries workstation
IP addresses to match users and IP addresses. You need to have FSAE version 3.5.27 or
later and FortiOS 3.0 MR7 or later.
To configure alternate user IP address tracking

1 On the computer where the collector agent is installed, go to Start > Run.
2 Enter regedit or regedt32 and select OK.
The Registry Editor opens.
3 Find the registry key
HKEY_LOCAL_MACHINE\SOFTWARE\Fortinet\FSAE\collectoragent.
4 Set the supportFSAEauth value (dword) to 00000001.
5 Close the Registry Editor.
7 Select Apply.
The FSAE service restarts with the updated registry settings.
Viewing collector agent status

Use the Show Service Status function to view your collector agents.
To view collector agent status


946 01-420-99686-20101026
2 In the Common Tasks section, select Show Service Status.

The FSAE Collector Agent Status window opens.
You can see which FortiGate units have a collector agent installed and how long the
agent has been connected.
Viewing DC agent status

Use the Show Monitored DCs function to view the status of DC agents.
To view domain controller agent status

2 In the Common Tasks section, select Show Monitored DCs.
For each DC Agent, you can view the IP address, number of logon events received,
the last logon event and when it was received.
3 If you want to change which DC agents are monitored or change the working mode for
logon event monitoring, select Select DC to Monitor. For more information see
“Selecting Domain Controllers and working mode for monitoring” on page 948.

01-420-99686-20101026 947
Selecting Domain Controllers and working mode for monitoring

You can change which DC agents are monitored or change the working mode for logon
event monitoring.
2 In the Common Tasks section, select Show Service Status.
3 Select Select DC to Monitor.
Working Mode
DC Agent mode — a Domain Controller agent monitors user logon events and
passes the information to the FSAE collector agent. This provides reliable user logon
information, however you must install a DC agent on every domain controller in the
domain.
Polling mode — the FSAE collector agent polls each domain controller for user
logon information. Under heavy system load this might provide information less
reliably, but you do not need to install a DC agent on each domain controller.

948 01-420-99686-20101026
FSAE for integration with Windows AD or Novell Configuring FSAE on Novell networks
Configuring FSAE on Novell networks

You need to configure the FSAE eDirectory agent to communicate with eDirectory servers.
You may have provided some of this information during installation.
To configure the eDirectory agent

1 From the Start menu select Programs > Fortinet > eDirectory Agent > eDirectory
Config Utility.
The eDirectory Agent Configuration Utility dialog opens.
eDirectory Authentication
User name Enter a user name that has access to the eDirectory, using
LDAP format.
Listening port Enter the TCP port on which FSAE listens for connections
from FortiGate units. The default is 8000. You can change the
port if necessary.
Refresh interval Enter the interval in seconds between polls of the eDirectory
server to check for new logins. The default is 30 seconds.
FortiGate Connection Authentication
Require authenticated Select to require the FortiGate unit to authenticate before
connection from FortiGate connecting to the eDirectory Agent.
Password Enter the password that FortiGate units must use to
authenticate. The maximum password length is 16 characters.
The default password is “FortinetCanada”.
User logon info search Select how the FSAE eDirectory agent accesses user logon
method information: LDAP or Native (Novell API). LDAP is the default.
If you select Native, you must also have the Novell Client
installed on the PC.
Logging
Log level Select Debug, Info, Warning or Error as the minimum severity
level of message to log or select None to disable logging.

01-420-99686-20101026 949
Configuring FSAE on Novell networks FSAE for integration with Windows AD or Novell
Log file size limit (MB) Enter the maximum size for the log file in MB.
View Log View the current log file.
Dump Session List the currently logged-on users in the log file. This can be
useful for troubleshooting.
eDirectory server list If you specified an eDirectory server during installation, it
appears in this list.
Add Add an eDirectory server. See “To add an eDirectory server”,
next.
Delete Delete the selected eDirectory server.
Edit Modify the settings for the selected server.
Group Filter Select the user groups whose user logons will be reported to
the FortiGate unit. This is used only if user groups are not
selected on the FortiGate unit. See “Configuring a group filter”
on page 951.
To add an eDirectory server

1 In the eDirectory Agent Configuration Utility dialog box (see the preceding procedure,
“To configure the eDirectory agent”), select Add.
The eDirectory Setup dialog box opens.
eDirectory Server Address Enter the IP address of the eDirectory server.

Port If the eDirectory server does not use the default port 389,
clear the Default check box and enter port number.
Use default credential Select to use the credentials specified in the eDirectory
Configuration Utility. See “To configure the eDirectory agent”
on page 949. Otherwise, leave the check box clear and enter
a User name and Password below.
User name Enter a user name that has access to the eDirectory, using
LDAP format.
Use secure connection (SSL) Select to connect to the eDirectory server using SSL security.
Search Base DN Enter the base Distinguished Name for the user search.

950 01-420-99686-20101026
FSAE for integration with Windows AD or Novell Configuring FSAE on Novell networks
Configuring a group filter

The FSAE eDirectory agent sends user logon information to the FortiGate unit for all user
groups unless you either
• configure an LDAP server entry for the eDirectory on the FortiGate unit and select the
groups that you want to monitor (see “Configuring LDAP server access” on page 952),
or
• configure the group filter on the eDirectory agent (see “To configure the group filter”,
below).
If both the FortiGate LDAP configuration and the FSAE eDirectory agent group filter are
present, the FortiGate user group selections are used.
To configure the group filter

1 From the Start menu select Programs > Fortinet > eDirectory Agent > eDirectory
Config Utility.
2 Select Group Filter.
• Enter group names, then select Add.
• Select Advanced, select groups, and then select Add.
4 Select OK.

01-420-99686-20101026 951
Configuring FSAE on FortiGate units FSAE for integration with Windows AD or Novell
Configuring FSAE on FortiGate units

To configure your FortiGate unit to operate with FSAE, you
• Configure LDAP access to the Novell eDirectory or Windows AD global catalog. Skip
this step if you are using FSAE Standard mode.
• Specify the FSAE collector agent or Novell eDirectory agent that will provide user logon
information.
• Add Active Directory user groups to FortiGate user groups,
• Create firewall policies for FSAE-authenticated groups,
• optionally, specify a guest protection profile to allow guest access.
Configuring LDAP server access

LDAP access is required if your network has a Novell eDirectory agent or a collector agent
using Advanced AD access mode. If you are using FSAE Standard mode, go to
“Specifying your collector agents or Novell eDirectory agents” on page 954.
The LDAP configuration on the FortiGate unit not only provides access to the LDAP
server, it sets up the retrieval of Windows AD user groups for you to select in Directory
Services. The LDAP Server configuration (in User > Remote > LDAP) includes a function
to preview the LDAP server’s response to your distinguished name query. If you already
know the appropriate Distinguished Name (DN) and User DN settings, you may be able to
skip some of the following steps.
2 Select the Query distinguished name button to the right of the Distinguished Name
field.
A new window opens, like this:
Figure 93: Result of initial DN query
If more than one name is listed, you might need to explore each name following the
steps below to determine which one is relevant to your needs.
3 Copy the name string to the Distinguished Name field and select OK.
This closes the window and copies the name string to the Distinguished Name field of
the LDAP Server configuration.
4 Set Bind Type to Regular.
5 In the User DN field, enter the administrative account name that you created for FSAE.
For example, if the account is FSAE_Admin, enter “cn=FSAE_Admin,cn=users”.
6 Make sure that the User DN entry ends with a comma and append the string from the
Distinguished Name field to the end of it.
Example: cn=FSAE_Admin,cn=users,dc=office,dc=example,dc=com
7 Enter the administrative account password in the Password field.

952 01-420-99686-20101026
FSAE for integration with Windows AD or Novell Configuring FSAE on FortiGate units
8 Select the Query distinguished name button again.

The LDAP Distinguished Name Query window opens again and looks like this:
Figure 94: Authenticated DN query
You can expand any of the DNs that contain entries. When you select an expandable
DN, the Distinguished Name field is updated. Look for the DN that contains the users
or groups whose logon you want to monitor.
9 Select the DN that you want to monitor and then select OK.
This closes the window and updates the Distinguished Name field of the LDAP Server
configuration.
10 Check the following fields and select OK:
Name Enter a name to identify the LDAP server.

Common Name The default common name identifier is cn. This is correct for most LDAP
Identifier servers. However some servers use other identifiers such as uid.
Secure Connection Do not select. The FSAE collector agent does not support secure
connection.
To configure LDAP for Directory Services - CLI example

config user ldap
edit "ADserver"
set server "10.11.101.160"
set cnid "cn"
set dn "cn=users,dc=office,dc=example,dc=com"
set type regular
set username
"cn=administrator,cn=users,dc=office,dc=example,dc=com"
set password set_a_secure_password
next
end

01-420-99686-20101026 953
Specifying your collector agents or Novell eDirectory agents

You need to configure the FortiGate unit to access at least one FSAE collector agent or
Novell eDirectory agent. You can specify up to five servers on which you have installed a
collector or eDirectory agent. The FortiGate unit accesses these servers in the order that
they appear in the list. If a server becomes unavailable, the unit accesses the next one in
the list.
To specify collector agents

1 Go to User > Directory Service and select Create New.
Figure 95: Directory Service server configuration
Name Enter a name for the Windows AD server. This name appears in the list of
Windows AD servers when you create user groups.
Enter the following information for up to five collector agents.
FSAE Collector Enter the IP address or the name of the server where this agent is
IP/Name installed. Maximum name length is 63 characters.
Port Enter the TCP port used for FSAE. This must be the same as the FortiGate
listening port specified in the Novell eDirectory or FSAE collector agent
configuration. See “Configuring collector agent settings” on page 941 or
“Configuring FSAE on Novell networks” on page 949.
Password Enter the password for the collector agent or eDirectory agent. For the
FSAE collector agent, this is required only if you configured the agent to
require authenticated access.
LDAP Server For Novell eDirectory, enable.
For Windows AD, enable if the collector agent is configured to use
Advanced AD access mode.
Select the LDAP server you configured previously. See “Configuring LDAP
server access” on page 952.
To specify the collector agent for Directory Services - CLI example

config user fsae
edit WinGroups
set ldap-server ADserver
set password ENC
G7GQV7NEqilCM9jKmVmJJFVvhQ2+wtNEe9T0iYA5Sa+EqT2J8zhOrbkJFD
r0RmY3c4LaoXdsoBczA1dONmcGfthTxxwGsigzGpbJdC71spFlQYtj
set server 10.11.101.160
end

954 01-420-99686-20101026
Selecting Windows user groups (LDAP only)

If the collector agent uses Advanced AD access mode, the FortiGate unit obtains user
group information using LDAP. You need to select the Windows user groups that you want
to monitor. These user group names are then available to add to FortiGate Directory
Service user groups.
To select Windows user groups

1 Go to User > Directory Service.
The list of Directory Service servers is displayed.
Figure 96: List of Directory Service servers
2 Select the Edit Users/Groups icon.

The FortiGate unit performs an LDAP query and displays the result.
Figure 97: Result of Directory Service LDAP query
3 Select the check boxes of the user groups that you want to monitor and then select OK.
You can also use the Add User/Group icon to select a group by entering its
distinguished name.
Viewing information imported from the Windows AD server

You can view the domain and group information that the FortiGate unit receives from the
AD Server. Go to User > Directory Service. The display differs for Standard and Advanced
AD access mode.

01-420-99686-20101026 955
Figure 98: List of groups from Active Directory server (Standard AD access mode)
Directory Service Server
Domain
Groups
Figure 99: List of monitored groups (Advanced AD access mode)
Directory Service Server
Domain
and
groups
in LDAP
format
Remove group
Create New Add a new Directory Service server.

Name
Server The name defined for the Directory Service server.
Domain Domain name imported from the Directory Service server.
Groups The group names imported from the Directory Service server.
FSAE Collector IP The IP address of the FSAE agent on the Directory Service server
Delete icon Delete this server definition.
Edit icon Edit this server definition.
Refresh icon Get user group information from the Directory Service server.
Add User/Group Add a user or group to the list. You must know the distinguished name for
the user or group. This is available for Windows AD in Advanced AD
access mode only.
Edit Users/Groups Select users and groups to add to the list. See “Selecting Windows user
groups (LDAP only)” on page 955. This is available in Advanced AD access
mode only.

956 01-420-99686-20101026
Creating Directory Service user groups

You cannot use Windows or Novell groups directly in FortiGate firewall policies. You must
create FortiGate user groups of the Directory Service type and add Windows or Novell
groups to them.
To create a user group for FSAE authentication

The New User Group dialog box opens.
Figure 100: Creating a new Directory Services user group
3 In the Name box, enter a name for the group, FSAE_Internet_users for example.
4 In Type, select Directory Service.
5 From the Available Members list, select the required Directory Service groups.
Using the CTRL or SHIFT keys, you can select multiple groups.
6 Select the green right arrow button to move the selected groups to the Members list.
7 Select OK.
To create the FSAE_Internet-users user group - CLI example

config user group
edit FSAE_Internet_users
set group-type directory-service
set member
CN=Engineering,cn=users,dc=office,dc=example,dc=com
CN=Sales,cn=users,dc=office,dc=example,dc=com
end
Creating firewall policies

Policies that require FSAE authentication are very similar to other firewall policies. Using
identity-based policies, you can configure access that depends on the Directory Service
user group.
To create a firewall policy for FSAE authentication


01-420-99686-20101026 957
Source interface and address as required

Destination interface and address as required
Action ACCEPT
NAT as needed

The New Authentication Rule window opens.
4 Select the required user group from the Available User Groups list and then select the
right arrow button to move the selected group to the Selected User Groups list.
You can select multiple groups using the CTRL or SHIFT keys.
5 Select the required service from the Available Services list and then select the right
arrow button to move the selected service to the Selected Services list.
You can select multiple services using the CTRL or SHIFT keys.
6 Select a Schedule from the list as needed.
7 Optionally, select UTM and enable UTM options.
8 Select OK to close the New Authentication Rule window.
9 Select Directory Service (FSAE).
10 Select OK.
To create a firewall policy for FSAE authentication - CLI example

edit 0
set srcintf port2
set dstintf port1
set srcaddr internal_net
set dstaddr all
set action accept
set nat enable
edit 1
set schedule always
set groups FSAE_Internet_users
set service ANY
end
end
Enabling guests to access FSAE policies

You can enable guest users to access FSAE firewall policies. Guests are users who are
unknown to the Windows AD or Novell network and servers that do not log on to a
Windows AD domain.
To enable guest access in your FSAE firewall policy, add an identity-based policy
assigned to the built-in user group FSAE_Guest_Users. Specify the services, schedule
and protection profile that apply to guest users. For more information, see “Creating
firewall policies” on page 957.

958 01-420-99686-20101026
FSAE for integration with Windows AD or Novell Testing the configuration
Testing the configuration

To verify that you have correctly configured FSAE on your network and on your FortiGate
units:
1 From a workstation on your network, log on to your domain using an account that
belongs to a group that is configured for authentication on the FortiGate unit.
2 Try to connect to the resource that is protected by the firewall policy requiring
authentication through FSAE.
You should be able to connect to the resource without being asked for user name or
password.
3 Log off and then log on using an account that does not belong to a group you have
configured for authentication on the FortiGate unit.
4 Try to connect to the resource that is protected by the firewall policy requiring
authentication through FSAE.
Your attempt to connect to the resource should fail.

01-420-99686-20101026 959
Testing the configuration FSAE for integration with Windows AD or Novell

960 01-420-99686-20101026
Certificate-based authentication
This section provides an overview of how the FortiGate unit verifies the identities of
administrators, SSL VPN users, or IPsec VPN peers using security certificates. The
FortiGate unit employs a variety of Internet protocols to secure access to the FortiGate
unit.
• Certificates overview
• Managing X.509 certificates
• Configuring certificate-based authentication
Certificates overview
Certificates always play a role in authentication of clients connecting via HTTPS, either as
administrators or SSL VPN users. Certificate authentication is optional for IPsec VPN
peers.
SSL, HTTPS, and certificates

The secure HTTP (HTTPS) protocol uses SSL security. Certificates are an integral part of
SSL. When a web browser connects to the FortiGate unit via HTTPS, a certificate is used
to verify the FortiGate unit’s identity to the client. Optionally, the FortiGate unit can require
the client to authenticate itself in return.
By default, the FortiGate unit uses a self-signed security certificate to authenticate itself to
HTTPS clients. When the certificate is offered, the client browser displays two security
messages.
• The first message prompts users to accept and optionally install the FortiGate unit’s
self-signed security certificate. If the user does not accept the certificate, the FortiGate
unit refuses the connection. When the user accepts the certificate, the FortiGate login
page is displayed, and the credentials entered by the user are encrypted before they
are sent to the FortiGate unit. If the user chooses to install the certificate, the prompt is
not displayed again.
• Just before the FortiGate login page is displayed, a second message informs users
that the FortiGate certificate distinguished name differs from the original request. This
message is displayed because the FortiGate unit redirects the connection (away from
the distinguished name recorded in the self-signed certificate) and can be ignored.
Optionally, you can install an X.509 server certificate issued by a certificate authority (CA)
on the FortiGate unit. You can then configure the FortiGate unit to identify itself using the
server certificate instead of the self-signed certificate.
This feature is supported for SSL VPN operation only and cannot be used to suppress the
two security messages during administrative log ins. For more information, see
“Authenticating SSL VPN users with security certificates” on page 970.
After successful certificate authentication, communication between the client browser and
the FortiGate unit is encrypted using SSL over the HTTPS link.

01-420-99686-20101026 961
Managing X.509 certificates Certificate-based authentication
IPsec VPNs and certificates

Certificate authentication is a more secure alternative to preshared key (shared secret)
authentication for IPsec VPN peers. Unlike administrators or SSL VPN users, IPsec peers
use HTTP to connect to the VPN gateway configured on the FortiGate unit. The VPN
gateway configuration can require certificate authentication before it permits an IPsec
tunnel to be established.
Managing X.509 certificates

The general process for handling certificates is as follows:
• Generate a certificate signing request on the FortiGate unit.
• Have the CA sign the server certificate.
• Install the server certificate on the device that must authenticate itself.
• Install the CA certificate and certificate revocation list (CRL) on the device that will
validate the certificate of the authenticating device.
This section provides procedures for generating certificate requests, installing signed
server certificates, and importing CA root certificates and CRLs at the FortiGate unit.
For information about how to install root certificates, CRLs, and personal or group
certificates on a remote client browser, refer to the browser documentation.
Generating a certificate signing request

Whether you create certificates locally with a software application or obtain them from an
external certificate service, you will need to generate a certificate signing request.
When you generate the request, a private and public key pair is created for the FortiGate
unit. The generated request includes the public key of the FortiGate unit and information
such as the FortiGate unit’s public static IP address, domain name, or email address. The
FortiGate unit’s private key remains confidential on the FortiGate unit.
After you submit the request to a CA, the CA will verify the information and register the
contact information on a digital certificate that contains a serial number, an expiration date,
and the public key of the CA. The CA will then sign the certificate. You then install the
certificate on the FortiGate unit.
To generate the certificate request

1 Go to System > Certificates > Local Certificates.

962 01-420-99686-20101026
Certificate-based authentication Managing X.509 certificates
2 Select Generate.
3 In the Certificate Name field, type a name for the certificate request. Typically, this
would be the name of the FortiGate unit.
Note: To enable the export of a signed certificate as a PKCS12 file later on if required, do
not include spaces in the name.
4 Enter values in the Subject Information area to identify the FortiGate unit:
• If the FortiGate unit has a static IP address, select Host IP and enter the public IP
address of the FortiGate unit. If the FortiGate unit does not have a public IP address,
use an email address (or domain name if available) instead.
• If the FortiGate unit has a static IP address and subscribes to a dynamic DNS service,
use a domain name if available to identify the FortiGate unit. If you select
Domain Name, enter the fully qualified domain name of the FortiGate unit. Do not
include the protocol specification (http://) or any port number or path names.
Note: If a domain name is not available and the FortiGate unit subscribes to a dynamic
DNS service, an “unable to verify certificate” type message may be displayed in the user’s
browser whenever the public IP address of the FortiGate unit changes.
• If you select E-Mail, enter the email address of the owner of the FortiGate unit.
5 Enter values in the Optional Information area to further identify the FortiGate unit.
Organization Unit Name of your department. You can enter a maximum of 5 Organization
Units. To add or remove a unit, use the plus (+) or minus (-) icon.
Organization Legal name of your company or organization.

01-420-99686-20101026 963
Locality (City) Name of the city or town where the FortiGate unit is installed.
State/Province Name of the state or province where the FortiGate unit is installed.
Country Select the country where the FortiGate unit is installed.
e-mail Contact email address.
6 From the Key Size list, select 1024 Bit, 1536 Bit or 2048 Bit. Larger keys are slower to
generate but more secure.
7 In Enrollment Method, you have two methods to choose from. Select File Based to
generate the certificate request, or Online SCEP to obtain a signed SCEP-based
certificate automatically over the network. For the SCEP method, enter the URL of the
SCEP server from which to retrieve the CA certificate, and the CA server challenge
password.
8 Select OK.
The request is generated and displayed in the Local Certificates list with a status of
PENDING.
9 Select the Download button to download the request to the management computer.
10 In the File Download dialog box, select Save and save the Certificate Signing Request
on the local file system of the management computer.
11 Name the file and save it on the local file system of the management computer.
Generating certificates with CA software

1 Install the CA software as a stand-alone root CA.
2 Provide identifying information for your self-administered CA
Server certificate
1 Generate a Certificate Signing Request (CSR) on the FortiGate unit.
2 Copy the CSR base-64 encoded text (PKCS#10 or PKCS#7) into the CA software and
generate the certificate.
3 Export the certificate as a X.509 DER encoded binary file with .CER extension
4 Upload the certificate file to the FortiGate unit Local Certificates page (type is
Certificate).
CA certificate
1 Retrieve the CA Certificate from the CA software as a DER encoded file.
2 Upload the CA certificate file to the FortiGate unit CA Certificates page.
PKI certificate
1 Generate a Certificate Signing Request (CSR) on the FortiGate unit.
2 Copy the CSR base-64 encoded text (PKCS#10 or PKCS#7) into the CA software and
generate the certificate.
3 Export the certificate as a X.509 DER encoded binary file with .CER extension.
4 Install the certificate in the user’s web browser or IPsec VPN client as needed.

964 01-420-99686-20101026
Obtaining a signed server certificate from an external CA

To obtain a signed server certificate for a FortiGate unit, you must send a request to a CA
that provides digital certificates that adhere to the X.509 standard. The FortiGate unit
provides a way for you to generate the request.
To submit the certificate signing request (file-based enrollment)

1 Using the web browser on the management computer, browse to the CA web site.
2 Follow the CA instructions for a base-64 encoded PKCS#10 certificate request and
upload your certificate request.
3 Follow the CA instructions to download their root certificate and CRL.
When you receive the signed server certificate from the CA, install the certificate on the
FortiGate unit. See “To install the signed server certificate” below.
To install the signed server certificate

1 On the FortiGate unit, go to System > Certificates > Local Certificates.
2 Select Import.
3 From Type, select Local Certificate.

4 Select Browse, browse to the location on the management computer where the
certificate was saved, select the certificate, and then select Open.
5 Select OK, and then select Return.
Installing a CA root certificate and CRL to authenticate remote clients

When you apply for a signed personal or group certificate to install on remote clients, you
can obtain the corresponding root certificate and CRL from the issuing CA. When you
receive the signed personal or group certificate, install the signed certificate on the remote
client(s) according to the browser documentation. Install the corresponding root certificate
(and CRL) from the issuing CA on the FortiGate unit according to the procedures given
below.
To install a CA root certificate

1 After you download the root certificate of the CA, save the certificate on the
management computer. Or, you can use online SCEP to retrieve the certificate.
2 On the FortiGate unit, go to System > Certificates > CA Certificates.
3 Select Import.

01-420-99686-20101026 965

• To import using SCEP, select SCEP. Enter the URL of the SCEP server from which
to retrieve the CA certificate. Optionally, enter identifying information of the CA, such
as the file name.
• To import from a file, select Local PC, then select Browse and find the location on
the management computer where the certificate has been saved. Select the
certificate, and then select Open.
The system assigns a unique name to each CA certificate. The names are numbered
consecutively (CA_Cert_1, CA_Cert_2, CA_Cert_3, and so on).
To import a certificate revocation list

A Certificate Revocation List (CRL) is a list of the CA certificate subscribers paired with
certificate status information. The list contains the revoked certificates and the reason(s)
for revocation. It also records the certificate issue dates and the CAs that issued them.
When configured to support SSL VPNs, the FortiGate unit uses the CRL to ensure that the
certificates belonging to the CA and remote peers or clients are valid. You must download
the CRL from the CA web site on a regular basis.
1 After you download the CRL from the CA web site, save the CRL on the management
computer.
2 Go to System > Certificates > CRL.
3 Select Import.

• To import using an HTTP server, select HTTP and enter the URL of the HTTP
server.
• To import using an LDAP server, select LDAP and select the LDAP server from the
list.
• To import using an SCEP server, select SCEP and select the Local Certificate from
the list. Enter the URL of the SCEP server from which the CRL can be retrieved.
• To import from a file, select Local PC, then select Browse and find the location on
the management computer where the CRL has been saved. Select the CRL and
then select Open.
Online updates to certificates and CRLs

If you obtained your local or CA certificate using SCEP, you can configure online renewal
of the certificate before it expires. Similarly, you can receive online updates to CRLs.

966 01-420-99686-20101026
Local certificates
In the config vpn certificate local command, you can specify automatic
certificate renewal. The relevant fields are:
scep-url <URL_str> The URL of the SCEP server. This can be HTTP or HTTPS.
scep-password The password for the SCEP server.
<password_str>
auto-regenerate-days How many days before expiry the FortiGate unit requests an
<days_int> updated local certificate. The default is 0, no auto-update.
auto-regenerate-days- How many days before local certificate expiry the FortiGate
warning <days_int> generates a warning message. The default is 0,no warning.
In this example, an updated certificate is requested three days before it expires.

config vpn certificate local
edit mycert
set scep-url http://scep.example.com/scep
set scep-server-password my_pass_123
set auto-regenerate-days 3
set auto-regenerate-days-warning 2
end
CA certificates
In the config vpn certificate ca command, you can specify automatic certificate
renewal. The relevant fields are:
scep-url <URL_str> The URL of the SCEP server. This can be HTTP or HTTPS.
auto-update-days How many days before expiry the FortiGate unit requests an
<days_int> updated CA certificate. The default is 0, no auto-update.
auto-update-days- How many days before CA certificate expiry the FortiGate
warning <days_int> generates a warning message. The default is 0,no warning.
In this example, an updated certificate is requested three days before it expires.

config vpn certificate ca
edit mycert
set scep-url http://scep.example.com/scep
set auto-update-days 3
set auto-update-days-warning 2
end
Certificate Revocation Lists

If you obtained your CRL using SCEP, you can configure online updates to the CRL using
the config vpn certificate crl command. The relevant fields are:
Variable Description
http-url URL of the server used for automatic CRL certificate updates. This can
<http_url> be HTTP or HTTPS.
scep-cert Local certificate used for SCEP communication for CRL auto-update.
<scep_certificate>

01-420-99686-20101026 967
scep-url URL of the SCEP CA server used for automatic CRL certificate updates.
<scep_url> This can be HTTP or HTTPS.
update-interval How frequently, in seconds, the FortiGate unit checks for an updated
<seconds> CRL. Enter 0 to update the CRL only when it expires.
update-vdom VDOM used to communicate with remote SCEP server for CRL auto-
<update_vdom> update.
In this example, an updated CRL is requested only when it expires.

config vpn certificate crl
edit cert_crl
set http-url http://scep.example.com/scep
set scep-cert my-scep-cert
set scep-url http://scep.ca.example.com/scep
set update-interval 0
set update-vdom root
end
Backing up and restoring local certificates

The FortiGate unit provides a way to export a server certificate and the FortiGate unit’s
personal key through the CLI. If required (to restore the FortiGate unit configuration), you
can import the exported file through the System > Certificates > Local Certificates page of
Note: As an alternative, you can back up and restore the entire FortiGate configuration
through the System > Maintenance > Backup & Restore page of the web-based manager.
The backup file is created in a FortiGate-proprietary format. For more information, see the
“System Maintenance” chapter of the FortiGate Administration Guide.
To export a server certificate and private key

This procedure exports a server (local) certificate and private key together as a password
protected PKCS12 file. The export file is created through a customer-supplied TFTP
server. Ensure that your TFTP server is running and accessible to the FortiGate unit
before you enter the command.
1 Connect to the FortiGate unit through the CLI.
2 Type the following command:
execute vpn certificate local export tftp <cert_name> <exp_filename>
<tftp_ip>
where:
• <cert_name> is the name of the server certificate; typing ? displays a list of installed
server certificates.
• <exp_filename> is a name for the output file.
• <tftp_ip> is the IP address assigned to the TFTP server host interface.
3 Move the output file from the TFTP server location to the management computer for
future reference.

968 01-420-99686-20101026
To import a previously exported server certificate and private key

1 Go to VPN > Certificates > Local Certificates and select Import.
2 In Type, select PKCS12 Certificate.

3 Select Browse. Browse to the location on the management computer where the
exported file has been saved, select the file, and then select Open.
4 In the Password field, type the password needed to upload the exported file.
To import separate server certificate and private key files

Use the following procedure to import a server certificate and the associated private key
file when the server certificate request and private key were not generated by the
FortiGate unit. The two files to import must be available on the management computer.
1 Go to VPN > Certificates > Local Certificates and select Import.
2 In Type, select Certificate.

3 Select the Browse button beside the Certificate file field. Browse to the location on the
management computer where the certificate file has been saved, select the file, and
then select Open.
4 Select the Browse button beside the Key file field. Browse to the location on the
management computer where the key file has been saved, select the file, and then
select Open.
5 If required, in the Password field, type the associated password, and then select OK.
6 Select Return.

01-420-99686-20101026 969
Configuring certificate-based authentication Certificate-based authentication
Configuring certificate-based authentication

You can configure certificate-based authentication for FortiGate administrators, SSL VPN
users, and IPsec VPN users.
Authenticating administrators with security certificates

You can install a certificate on the management computer to support strong authentication
for administrators. When a personal certificate is installed on the management computer,
the FortiGate unit processes the certificate after the administrator supplies a user name
and password.
To enable strong administrative authentication:
• Obtain a signed personal certificate for the administrator from a CA and load the
signed personal certificate into the web browser on the management computer
according to the browser documentation.
• Install the root certificate and the CRL from the issuing CA on the FortiGate unit (see
“Installing a CA root certificate and CRL to authenticate remote clients” on page 965).
• Create a PKI user account for the administrator.
• Add the PKI user account to a firewall user group dedicated to PKI-authenticated
administrators.
• In the administrator account configuration, select PKI as the account Type and select
the User Group to which the administrator belongs.
Authenticating SSL VPN users with security certificates

X.509 certificates can be used to authenticate IPsec VPN peers or clients, or SSL VPN
clients. When configured to authenticate a VPN peer or client, the FortiGate unit prompts
the VPN peer or client to authenticate itself using the X.509 certificate. The certificate
supplied by the VPN peer or client must be verifiable using the root CA certificate installed
on the FortiGate unit in order for a VPN tunnel to be established.
Note: The FortiGate unit is shipped with a self-signed certificate to authenticate itself to
SSL VPN clients. This causes two security messages to be displayed to SSL VPN users
when they log in. For more information, see “SSL, HTTPS, and certificates” on page 961.
Optionally, you can install a CA-issued server certificate on the FortiGate unit.
To enable certificate authentication for an SSL VPN user group

1 Install a signed server certificate on the FortiGate unit and install the corresponding
root certificate (and CRL) from the issuing CA on the remote peer or client.
2 Obtain a signed group certificate from a CA and load the signed group certificate into
the web browser used by each user. Follow the browser documentation to load the
certificates.
3 Install the root certificate and the CRL from the issuing CA on the FortiGate unit (see
“Installing a CA root certificate and CRL to authenticate remote clients” on page 965).
4 Create a PKI user for each SSL VPN user. For each user, specify the text string that
appears in the Subject field of the user’s certificate and then select the corresponding
CA certificate.
5 Use the config user peergrp CLI command to create a peer user group. Add to
this group all of the SSL VPN users who are authenticated by certificate.
7 Select Enable SSL-VPN.

970 01-420-99686-20101026
Certificate-based authentication Configuring certificate-based authentication
8 Select Require Client Certificate, and then select Apply.

10 Select the Edit icon in the row that corresponds to the SSL-VPN firewall policy for
traffic generated by holders of the group certificate.
11 Select SSL Client Certificate Restrictive.
12 Select OK.
Authenticating IPsec VPN users with security certificates

To require VPN peers to authenticate by means of a certificate, the FortiGate unit must
offer a certificate to authenticate itself to the peer.
To enable the FortiGate unit to authenticate itself with a certificate:

1 Install a signed server certificate on the FortiGate unit.
See “To install the signed server certificate” on page 965.
2 Install the corresponding CA root certificate on the remote peer or client. If the remote
peer is a FortiGate unit, see “To install a CA root certificate” on page 965.
3 Install the certificate revocation list (CRL) from the issuing CA on the remote peer or
client. If the remote peer is a FortiGate unit, see “To import a certificate revocation list”
on page 966.
4 In the VPN phase 1 configuration, set Authentication Method to RSA Signature and
from the Certificate Name list select the certificate that you installed in Step 1.
To authenticate a VPN peer using a certificate, you must install a signed server certificate
on the peer. Then, on the FortiGate unit, the configuration depends on whether there is
only one VPN peer or if this is a dialup VPN that can he multiple peers.
To configure certificate authentication of a single peer

1 Install the CA root certificate and CRL.
2 Create a PKI user to represent the peer. Specify the text string that appears in the
Subject field of the user’s certificate and then select the corresponding CA certificate.
3 In the VPN phase 1 Peer Options, select Accept this peer certificate only and select
the PKI user that you created.
To configure certificate authentication of multiple peers (dialup VPN)

1 Install the corresponding CA root certificate and CRL.
2 Create a PKI user for each remote VPN peer. For each user, specify the text string that
appears in the Subject field of the user’s certificate and then select the corresponding
CA certificate.
3 Use the config user peergrp CLI command to create a peer user group. Add to
this group all of the PKI users who will use the IPsec VPN.
4 In the VPN phase 1 Peer Options, select Accept this peer certificate group only and
select the peer group that you created.

01-420-99686-20101026 971
Configuring certificate-based authentication Certificate-based authentication

972 01-420-99686-20101026
Monitoring authenticated users
This section describes how to view lists of currently logged-in firewall and VPN users. It
also describes how to disconnect users.
• Monitoring firewall users
• Monitoring SSL VPN users
• Monitoring IPsec VPN users
Monitoring firewall users

Go to User > Monitor > Firewall to view current authenticated users.
Figure 101: Firewall users listed in monitor
You can de-authenticate a user by selecting their Delete icon.
Monitoring SSL VPN users

You can monitor web-mode and tunnel-mode SSL VPN users by user name and IP
address.
To monitor SSL VPN users - web-based manager

1 Go to VPN > SSL > Monitor.
2 To disconnect a user, selecting the user and then select the Delete icon.
Figure 102: Monitoring SSL VPN users
The first line, listing the user name and IP address, is present for a user with either a web-
mode or tunnel-mode connection. The Subsession line is present only if the user has a
tunnel mode connection. The Description column displays the virtual IP address assigned
to the user’s tunnel-mode connection.
To monitor SSL VPN users - CLI

To list all of the SSL VPN sessions and their index numbers:
execute vpn sslvpn list

01-420-99686-20101026 973
Monitoring IPsec VPN users Monitoring authenticated users
The output looks like this:

SSL-VPN Login Users:
Index User Auth Type Timeout From HTTPS in/out
0 user1 1 256 172.20.120.51 0/0
SSL-VPN sessions:
Index User Source IP Tunnel/Dest IP
0 user2 172.20.120.51 10.0.0.1
You can use the Index value in the following commands to disconnect user sessions:
To disconnect a tunnel-mode user

execute vpn sslvpn del-tunnel <index>
To disconnect a web-mode user

execute vpn sslvpn del-web <index>
You can also disconnect multiple users:
To disconnect all tunnel-mode SSL VPN users in this VDOM

execute vpn ssl del-all tunnel
To disconnect all SSL VPN users in this VDOM

execute vpn ssl del-all
Monitoring IPsec VPN users

To monitor IPsec VPN tunnels in the web-based manager, go to VPN > IPsec > Monitor.
User names are available only for users who authenticate with XAuth.
You can close a tunnel by selecting its Bring Down link in the Status column.
Figure 103: Monitoring dialup VPN users
For more information, see the IPsec VPN chapter of this Handbook.

974 01-420-99686-20101026
Example
This chapter provides an example of a FortiGate unit providing authenticated access to
the Internet for both Windows network users and local users.
• Firewall authentication example
Firewall authentication example

Figure 104: Example configuration
17 P
2.2 ort 1
0.1 _1
20
.1 ate
41 rtiG
Fo
Windows network 10 Por
.11 t 3
10.11.101.0/24 .10 Network_1
2.1
0 0 10.11.102.0/24
10 0
rt 2 1.
Po 1.10
. 1
10
in
ma
do AE
D S
s A ith F
ow
i nd ller w 60
W tro 1.1
n
co 1.10
.1
10
Overview
In this example, there is a Windows network connected to Port 2 on the FortiGate unit and
another LAN, Network_1, connected to Port 3.
All Windows network users authenticate when they log on to their network. Members of
the Engineering and Sales groups can access the Internet without entering their
authentication credentials again. The example assumes that the Fortinet Server
Authentication Extension (FSAE) has already been installed and configured on the
domain controller.
LAN users who belong to the Internet_users group can access the Internet after entering
their user name and password to authenticate. This example shows only two users, User1
is authenticated by a password stored on the FortiGate unit, User2 is authenticated on an
external authentication server. Both of these users are referred to as local users because
the user account is created on the FortiGate unit.

01-420-99686-20101026 975
Firewall authentication example Example
Creating a locally-authenticated user account

User1 is authenticated by a password stored on the FortiGate unit. It is very simple to
create this type of account.
To create a local user - web-based manager

2 Enter the following information: User name, Password.
User Name User1

Password hardtoguess
3 Select OK.
To create a local user - CLI

config user local
edit user1
set type password
set passwd hardtoguess
end
Creating a RADIUS-authenticated user account

To authenticate users using an external authentication server, you must first configure the
FortiGate unit to access the server.
To configure the remote authentication server - web-based manager

Name OurRADIUSsrv
Primary Server Name/IP 10.11.101.15
Primary Server Secret OurSecret
Authentication Scheme Select Use Default Authentication Scheme.
To configure the remote authentication server - CLI

config user radius
edit OurRADIUSsrv
set server 10.11.102.15
set secret OurSecret
set auth-type auto
end
Creation of the user account is similar to the locally-authenticated account, except that
you specify the RADIUS authentication server instead of the user’s password.
To configure a remote user - web-based manager

User Name User2

RADIUS Select Match user on RADIUS server and then select OurRADIUSsrv
from the list.

976 01-420-99686-20101026
Example Firewall authentication example
To configure a remote user - CLI

config user local
edit User2
set name User2
set type radius
set radius-server OurRADIUSsrv
end
Creating user groups

There are two user groups: a Directory Services user group for FSAE users and a firewall
user group for other users. It is not possible to combine these two types of users in the
same user group.
Creating the Directory Services user group

For this example, assume that FSAE has already been set up on the Windows network
and that it uses Advanced mode, meaning that it uses LDAP to access user group
information. You need to
• configure LDAP access to the Windows AD global catalog
• specify the collector agent that sends user logon information to the FortiGate unit
• select Windows user groups to monitor
• select and add the Engineering and Sales groups to a Directory Services user group
To configure LDAP for Directory Services - web-based manager

Name ADserver
Server Name / IP 10.11.101.160
Distinguished Name dc=office,dc=example,dc=com
Bind Type Regular
User DN cn=FSAE_Admin,cn=users,dc=office,dc=example,dc=com
Password set_a_secure_password
Leave other fields at their default values.

3 Select OK.
To configure LDAP for Directory Services - CLI

config user ldap
edit "ADserver"
set server "10.11.101.160"
set dn "cn=users,dc=office,dc=example,dc=com"
set type regular
set username
"cn=administrator,cn=users,dc=office,dc=example,dc=com"
set password set_a_secure_password
next
end

01-420-99686-20101026 977
To specify the collector agent for Directory Services - web-based manager

1 Go to User > Directory Service and select Create New.
Name WinGroups
Enter on one line
FSAE Collector 10.11.101.160
IP/Name
Port 8000
Password fortinet_canada
LDAP Server ADserver
To specify the collector agent for Directory Services - CLI

config user fsae
edit "WinGroups"
set ldap-server "ADserver"
set password ENC
G7GQV7NEqilCM9jKmVmJJFVvhQ2+wtNEe9T0iYA5Sa+EqT2J8zhOrbkJFD
r0RmY3c4LaoXdsoBczA1dONmcGfthTxxwGsigzGpbJdC71spFlQYtj
set server "10.11.101.160"
end
To select Windows user groups to monitor - web-based manager

1 Go to User > Directory Service.
2 Expand WinGroups, then select the Edit Users/Groups icon.
3 Select the Engineering and Sales groups and then select OK.
To create the FSAE_Internet-users user group - web-based manager

2 Enter the group name, FSAE_Internet_users.
3 Select Directory Service.
4 In the Available Members list, select the Engineering and Sales groups and then select
the right arrow button to move them to the Members list.
5 Select OK.
To create the FSAE_Internet-users user group - CLI

config user group
edit FSAE_Internet_users
set group-type directory-service
set member
CN=Engineering,cn=users,dc=office,dc=example,dc=com
CN=Sales,cn=users,dc=office,dc=example,dc=com
end

978 01-420-99686-20101026
Creating the Firewall user group

The non-FSAE users need a user group too. In this example, only two users are shown,
but additional members can be added easily.
To create the firewall user group - web-based manager

2 Enter the following information and then select OK:
Name Internet_users
Type Firewall
Members User1, User2
To create the firewall user group - CLI

config user group
edit Internet_users
set member User1 User2
end
Defining firewall addresses

Go to Firewall > Address and create the following addresses:
Address Name Internal_net

Subnet / IP Range 10.11.102.0/24
Interface Port 3
Address Name Windows_net

Interface Port 2
Creating firewall policies

Two firewall policies are needed: one for firewall group who connect through port3 and
one for FSAE group who connect through port2.
To create a firewall policy for FSAE authentication - web-based manager

Source interface Port2

Source address Windows_net
Destination interface Port1
Destination address all
Action ACCEPT
NAT Enable

01-420-99686-20101026 979

In the New Authentication Rule window, enter the following information, and then
select OK:
User Group FSAE_Internet_users

Service ANY
Schedule always
UTM Optionally, enable UTM options.
4 Select OK.
To create a firewall policy for FSAE authentication - CLI

edit 0
set srcintf port2
set dstintf port1
set srcaddr Windows_net
set dstaddr all
set action accept
set nat enable
edit 1
set schedule always
set groups FSAE_Internet_users
set service ANY
end
end
To create a firewall policy for local user authentication - web-based manager

Source interface Port3

Source address Internal_net
Destination interface Port1
Destination address all
Action ACCEPT
NAT Enable

In the New Authentication Rule window, enter the following information, and then
select OK:
User Group Internet_users

Service ANY
Schedule always
UTM Optionally, enable UTM options.
4 Select OK.

980 01-420-99686-20101026
To create a firewall policy for local user authentication - CLI

edit 0
set srcintf port3
set dstintf port1
set srcaddr internal_net
set dstaddr all
set action accept
set nat enable
edit 1
set schedule always
set groups Internet_users
set service ANY
end
end

01-420-99686-20101026 981

982 01-420-99686-20101026
Chapter 8 IPsec VPNs

IPsec VPN concepts explains the basic concepts that you need to understand about
virtual private networks (VPNs).
FortiGate IPsec VPN Overview provides a brief overview of IPsec technology and
includes general information about how to configure IPsec VPNs using this guide.
Gateway-to-gateway configurations explains how to set up a basic gateway-to-gateway
(site-to-site) IPsec VPN. In a gateway-to-gateway configuration, two FortiGate units create
a VPN tunnel between two separate private networks.
Hub-and-spoke configurations describes how to set up hub-and-spoke IPsec VPNs. In a
hub-and-spoke configuration, connections to a number of remote peers and/or clients
radiate from a single, central FortiGate hub.
Dynamic DNS configurations describes how to configure a site-to-site VPN, in which one
FortiGate unit has a static IP address and the other FortiGate unit has a static domain
name and a dynamic IP address.
FortiClient dialup-client configurations guides you through configuring a FortiClient dialup-
client IPsec VPN. In a FortiClient dialup-client configuration, the FortiGate unit acts as a
dialup server and VPN client functionality is provided by the FortiClient Endpoint Security
application installed on a remote host.
FortiGate dialup-client configurations explains how to set up a FortiGate dialup-client
IPsec VPN. In a FortiGate dialup-client configuration, a FortiGate unit with a static IP
address acts as a dialup server and a FortiGate unit having a dynamic IP address initiates
a VPN tunnel with the FortiGate dialup server.
Supporting IKE Mode config clients explains how to set up a FortiGate unit as either an
IKE Mode Config server or client. IKE Mode Config is an alternative to DHCP over IPsec.
Internet-browsing configuration explains how to support secure web browsing performed
by dialup VPN clients, and/or hosts behind a remote VPN peer. Remote users can access
the private network behind the local FortiGate unit and browse the Internet securely. All
traffic generated remotely is subject to the firewall policy that controls traffic on the private
network behind the local FortiGate unit.
Redundant VPN configurations discusses the options for supporting redundant and
partially redundant tunnels in an IPsec VPN configuration. A FortiGate unit can be
configured to support redundant tunnels to the same remote peer if the FortiGate unit has
more than one interface to the Internet.
Transparent mode VPNs describes transparent VPN configurations, in which two
FortiGate units create a VPN tunnel between two separate private networks transparently.
In Transparent mode, all interfaces of the FortiGate unit except the management interface
are invisible at the network layer.
FortiOS™ Handbook v2: IPsec VPNs

01-420-99686-20101026 983
Manual-key configurations explains how to manually define cryptographic keys to
establish an IPsec VPN tunnel. If one VPN peer uses specific authentication and
encryption keys to establish a tunnel, both VPN peers must be configured to use the same
encryption and authentication algorithms and keys.
IPv6 IPsec VPNs describes FortiGate unit VPN capabilities for networks based on IPv6
addressing. This includes IPv4-over-IPv6 and IPv6-over-IPv4 tunnelling configurations.
IPv6 IPsec VPNs are available in FortiOS 3.0 MR5 and later.
L2TP and IPsec (Microsoft VPN) configurations explains how to support Microsoft
Windows native VPN clients.
GRE over IPsec (Cisco VPN) configurations explains how to interoperate with Cisco VPNs
that use Generic Routing Encapsulation (GRE) protocol with IPsec.
Protecting OSPF with IPsec provides an example of protecting OSPF links with IPsec.
Auto Key phase 1 parameters provides detailed step-by-step procedures for configuring a
FortiGate unit to accept a connection from a remote peer or dialup client. The basic phase
1 parameters identify the remote peer or clients and support authentication through
preshared keys or digital certificates. You can increase VPN connection security further
using peer identifiers, certificate distinguished names, group names, or the FortiGate
extended authentication (XAuth) option for authentication purposes.
Phase 2 parameters provides detailed step-by-step procedures for configuring an IPsec
VPN tunnel. During phase 2, the specific IPsec security associations needed to implement
security services are selected and a tunnel is established.
Defining firewall policies explains how to specify the source and destination IP addresses
of traffic transmitted through an IPsec VPN tunnel, and how to define a firewall encryption
policy. Firewall policies control all IP traffic passing between a source address and a
destination address.
Hardware offloading and acceleration explains how to make use of FortiASIC network
processor IPsec accelerated processing capabilities.
Monitoring and troubleshooting VPNs provides some general monitoring and testing
procedures for VPNs.
IPsec VPNs for FortiOS 4.0 MR2

984 01-420-99686-20101026
IPsec VPN concepts
Virtual Private Network (VPN) technology enables users to connect to private networks in
a secure way. For example, an employee traveling or working from home can access the
office network through the Internet. The use of a VPN ensures that unauthorized parties
cannot access the office network and cannot intercept any of the information that is
exchanged with the employee. It is also common to use a VPN to connect the private
networks of two or more offices.
Fortinet offers VPN capabilities in the FortiGate Unified Threat Management appliance
and in the FortiClient Endpoint Security application. A FortiGate unit can be installed on a
private network, and FortiClient software is installed on the user’s computer. It is also
possible to use a FortiGate unit to connect to the private network instead of FortiClient
software.
This chapter discusses terms and concepts you are likely to encounter while working with
VPNs:
• IP packets
• VPN tunnels
• VPN gateways
• Clients, servers, and peers
• Encryption
• Authentication
• Phase 1 and Phase 2 settings
• Security Association
IP packets
In network terminology, data is sent in something called an IP packet. Packets have a
fixed size, typically about 1500 bytes. Larger amounts of data are sent and received as a
sequence of packets.
Figure 105: IP addresses can be compared to street addresses

01-420-99686-20101026 985
VPN tunnels IPsec VPN concepts
An IP packet contains data, a source address, and a destination address. Conceptually,

source and destination addresses can be compared to street and/or apartment addresses
(see Figure 105). When a letter is mailed, it is delivered to a street and/or apartment
address (destination address). The return address (source address) is printed on the
envelope.
The source address corresponds to the computer that sent the data, and the destination
address corresponds to the computer that will use the data. Computers use source and
destination addresses to determine where a packet came from and where it is going.
Figure 106 shows a network version of the street-address analogy.
Figure 106: Network version of street-address analogy
IP addresses can be static or dynamic. A static IP address is fixed, like the street address
of a home or business. Your Internet Service Provider (ISP) might provide a dynamic
address instead. In that case, you are assigned an IP address only when you connect to
the network. The address can be different each time you connect. Whether your IP
address is static or dynamic determines the types of VPN configurations that you can
support.
Packets exchanged over an insecure network can be intercepted. A VPN encrypts data to
secure it. Encryption transforms the data so that it appears random and meaningless to
anyone who does not have the correct key to decrypt it. See “Encryption” on page 989.
VPNs also address the issue of authentication. You want to ensure that only authorized
users can connect to your private network. See “Authentication” on page 990.
There are several types of VPN. This guide discusses only Internet Protocol Security
(IPsec) VPN technology.
VPN tunnels
The data path between a user’s computer and a private network through a VPN is often
referred to as a tunnel. Like a tunnel, the route is accessible only at the ends. In the
telecommuting scenario, the tunnel runs between the FortiClient application on the user’s
PC and the FortiGate unit that connects the office private network to the Internet.
What makes this possible is encapsulation. The IPsec packets that pass from one end of
the tunnel to the other contain the data packets that are exchanged between the remote
user and the private network. Encryption of the data packets ensures that any third-party
intercepting the IPsec packets has no access to the data. This idea is shown conceptually
in Figure 107.

986 01-420-99686-20101026
IPsec VPN concepts VPN gateways
Figure 107: Encoded data going through a VPN tunnel
You can create a VPN tunnel between:

• a PC equipped with the FortiClient application and a FortiGate unit
• two FortiGate units
It is also possible to create a VPN tunnel with some types of third-party VPN software or
hardware and either a FortiGate unit or the FortiClient application. The Fortinet
Knowledge Base contains articles on this topic.
VPN gateways
A gateway is a router that connects the local network to other networks. The default
gateway setting in your computer’s TCP/IP properties specifies the gateway for your local
network.
A VPN gateway functions as one end of a VPN tunnel. It receives incoming IPsec packets,
decrypts the encapsulated data packets and passes the data packets to the local network.
Also, it encrypts data packets destined for the other end of the VPN tunnel, encapsulates
them, and sends the IPsec packets to the other VPN gateway.
The IP address of a VPN gateway is usually the IP address of the network interface that
connects to the Internet. Optionally, you can define a secondary IP address for the
interface and use that address as the local VPN gateway address.
The following diagram shows a VPN between two private networks with FortiGate units
acting as the VPN gateways.
Figure 108: VPN tunnel between two private networks
y Sit
wa eB
ate (Fo VPN
P N g it) rtiG ga
V n
eA eu a.1.2.3 b.4.5.6 ate tew
Sit rtiGat un ay
(Fo it)
VPN tunnel
Sit Sit
e
10 A ne 19 e B n
.10 tw 2.1 et
.1. ork 68 wo
0/2 .10 rk
4 .0/
24

01-420-99686-20101026 987
VPN gateways IPsec VPN concepts
Although the IPsec traffic may actually pass through many Internet routers, you can think
of the VPN tunnel as a simple secure connection between the two FortiGate units.
Users on the two private networks do not need to be aware of the VPN tunnel. The
applications on their computers generate packets with the appropriate source and
destination addresses, as they normally do. The FortiGate units manage all the details of
encrypting, encapsulating and sending the packets to the remote VPN gateway.
The data is encapsulated in IPsec packets only in the VPN tunnel between the two VPN
gateways. Between the user’s computer and the gateway, the data is in regular IP
packets.
For example, User1 at Site A, IP address 10.10.1.7 sends packets with destination IP
address 192.168.10.8, the address of User2 at Site B. The Site A FortiGate unit is
configured to send packets with destinations on the 192.168.10.0 network through the
VPN, encrypted and encapsulated, of course. Similarly, the Site B FortiGate unit is
configured to send packets with destinations on the 10.10.1.0 network through the VPN
tunnel to the Site A VPN gateway.
In the site-to-site VPN shown in Figure 108, the FortiGate units have static (fixed) IP
addresses and either unit can initiate communication.
You can also create a VPN tunnel between an individual PC running the FortiClient
application and a FortiGate unit, as shown below:
Figure 109: VPN tunnel between a FortiClient PC and a FortiGate unit
t
uni Fo
rtiC
ate lien
o rtiG a.1.2.3 b.4.5.6
tP
e F C
Offic
VPN tunnel
Of
fic
10 e ne
.10 tw
.1. ork
0/2
4
On the PC, the FortiClient application acts as the local VPN gateway. Packets destined for
the office network are encrypted, encapsulated into IPsec packets, and sent through the
VPN tunnel to the FortiGate unit. Packets for other destinations are routed to the Internet
as usual. IPsec packets arriving through the tunnel are decrypted to recover the original IP
packets.

988 01-420-99686-20101026
IPsec VPN concepts Clients, servers, and peers
Clients, servers, and peers

A FortiGate unit in a VPN can have one of the following roles:
server responds to a request to establish a VPN tunnel

client contacts a remote VPN gateway and requests a VPN tunnel
peer brings up a VPN tunnel or responds to a request to do so
The site-to-site VPN shown in Figure 108 is a peer-to-peer relationship. Either FortiGate
unit VPN gateway can establish the tunnel and initiate communications. The FortiClient-
to-FortiGate VPN shown in Figure 109 is a client-server relationship. The FortiGate unit
establishes a tunnel when the FortiClient PC requests one.
A FortiGate unit cannot be a VPN server if it has a dynamically-assigned IP address. VPN
clients need to be configured with a static IP address for the server.
A FortiGate unit acts only as a server when the remote VPN gateway has a dynamic IP
address or is a client-only device or application, such as the FortiClient application.
As a VPN server, a FortiGate unit can also offer automatic configuration for FortiClient
PCs. The user needs to know only the IP address of the FortiGate VPN server and a valid
user name/password. The FortiClient application downloads the VPN configuration
settings from the FortiGate VPN server. For information about configuring a FortiGate unit
as a VPN server, see the FortiClient Administration Guide.
Encryption
Encryption mathematically transforms data to look like meaningless random numbers. The
original data is called plaintext and the encrypted data is called ciphertext. The opposite
process, called decryption, performs the inverse operation of recovering the original
plaintext from the ciphertext.
The process by which the plaintext is transformed to ciphertext and back again is called an
algorithm. All algorithms use a small piece of information, known as a key, in the arithmetic
process of converted plaintext to ciphertext, or vice-versa. IPsec uses symmetrical
algorithms, in which the same key is used to both encrypt and decrypt the data.
The security of an encryption algorithm is determined by the length of the key that it uses.
FortiGate IPsec VPNs offer the following encryption algorithms, in descending order of
security:
• AES256 — a 128-bit block algorithm that uses a 256-bit key.
• 3DES — Triple-DES, in which plain text is DES-encrypted three times by three keys.
• DES — Digital Encryption Standard, a 64-bit block algorithm that uses a 56-bit key.
The default encryption algorithms provided on FortiGate units make recovery of encrypted
data almost impossible without the proper encryption keys.
There is a human factor in the security of encryption. The key must be kept secret, known
only to the sender and receiver of the messages. Also, the key must not be something that
unauthorized parties might guess, such as the sender’s name or birthday or a simple
sequence like “123456”.

01-420-99686-20101026 989
Authentication IPsec VPN concepts
Authentication
In addition to protecting data through encryption, a VPN must ensure that only authorized
users can access the private network. You must use either a preshared key on both VPN
gateways or RSA X.509 security certificates. The examples in this guide use only
preshared key authentication.
Preshared keys
A preshared key contains at least 6 randomly chosen alphanumeric characters. Users of
the VPN must obtain the preshared key from the person who manages the VPN server
and add the preshared key to their VPN client configuration.
Although it looks like a password, the preshared key, also known as a shared secret, is
never sent by either gateway. The preshared key is used in the calculations at each end
that generate the encryption keys. As soon as the VPN peers attempt to exchange
encrypted data, preshared keys that do not match will cause the process to fail.
Additional authentication
To increase security, you can use require additional means of authentication:
• an identifier, called a peer ID or a local ID
• extended authentication (XAUTH) which imposes an additional user name/password
requirement
A Local ID is an alphanumeric value assigned in the Phase 1 configuration. The Local ID
of a peer is called a Peer ID.
Phase 1 and Phase 2 settings

A VPN tunnel is established in two phases: Phase 1 and Phase 2. Several parameters
determine how this is done. Except for IP addresses, the settings simply need to match at
both VPN gateways and there are defaults that are appropriate for most cases.
Note: The FortiClient application distinguishes between Phase 1 and Phase 2 only in the
VPN Advanced settings and uses different terms. Phase 1 is called the IKE Policy. Phase 2
is called the IPsec Policy.
Phase 1
In Phase 1, the two VPN gateways exchange information about the encryption algorithms
that they support and then establish a temporary secure connection to exchange
authentication information.
When you configure your FortiGate unit or FortiClient application, you must specify the
following settings for Phase 1:
Remote Gateway the remote VPN gateway’s address.

FortiGate units also have the option of operating only as a
server by selecting the “Dialup User” option.
Preshared key this must be the same at both ends. It is used to encrypt
phase 1 authentication information.
Local interface the network interface that connects to the other VPN
gateway. This applies on a FortiGate unit only.

990 01-420-99686-20101026
IPsec VPN concepts Security Association
All other Phase 1 settings have default values. These settings mainly configure the types
of encryption to be used. The default settings on FortiGate units and in the FortiClient
application are compatible. The examples in this guide use these defaults.
For more detailed information about Phase 1 settings, see the “Auto Key phase 1
parameters” chapter of the FortiGate IPsec VPN User Guide.
Phase 2
Similar to the Phase 1 process, the two VPN gateways exchange information about the
encryption algorithms that they support for Phase 2. Phase 1 and Phase 2 can use
different encryption. If both gateways have at least one encryption algorithm in common, a
VPN tunnel is established.
To configure default Phase 2 settings on a FortiGate unit, you need only select the name
of the corresponding Phase 1 configuration. In the FortiClient application, no action is
required to enable default Phase 2 settings.
For more detailed information about Phase 2 settings, see the “Phase 2 parameters”
chapter of the FortiGate IPsec VPN User Guide.
Security Association
The establishment of a Security Association (SA) is the successful outcome of Phase 1
negotiations. Each peer maintains a database of information about VPN connections. The
information in each SA can include cryptographic algorithms and keys, keylife, and the
current packet sequence number. This information is kept synchronized as the VPN
operates. Each SA has a Security Parameter Index (SPI) that is provided to the remote
peer at the time the SA is established. Subsequent IPsec packets from the peer always
reference the relevant SPI. It is possible for peers to have multiple VPNs active
simultaneously.

01-420-99686-20101026 991
Security Association IPsec VPN concepts

992 01-420-99686-20101026
FortiGate IPsec VPN Overview
This section provides a brief overview of IPsec technology and includes general
information about how to configure IPsec VPNs using this guide.
• About FortiGate VPNs
• Planning your VPN
• General preparation steps
• How to use this guide to configure an IPsec VPN
About FortiGate VPNs

VPN configurations interact with the firewall component of the FortiGate unit. There must
be a firewall policy in place to permit traffic to pass between the private network and the
VPN tunnel.
Firewall policies for VPNs specify:
• the FortiGate interface that provides the connection to the remote VPN gateway,
usually an interface connected to the Internet
• the FortiGate interface that connects to the private network
• the IP addresses associated with data that has to be encrypted and decrypted
• optionally, a schedule that restricts when the VPN can operate
• optionally, the services (types of data) that can be sent
When the first packet of data meeting all of the conditions of the policy arrives at the
FortiGate unit, a VPN tunnel may be initiated and the encryption/decryption of data is
performed automatically afterward.
FortiGate unit VPNs can be policy-based or route-based. There is little functional
difference between the two types. In both cases, you specify phase 1 and phase 2
settings, but there is a difference in implementation. A route-based VPN creates a virtual
IPsec network interface that applies encryption or decryption as needed to any traffic that
it carries. That is why route-based VPNs are also known as interface-based VPNs. A
policy-based VPN is implemented through a special firewall policy that applies the
encryption you specified in the phase 1 and phase 2 settings.
For a route-based VPN, you need to create two firewall policies between the virtual IPsec
interface and the interface that connects to the private network. In one policy the virtual
interface is the source. In the other policy the virtual interface is the destination. The
Action for both policies is Accept.
For a policy-based VPN, one firewall policy enables communication in both directions. You
must select IPSEC as the Action and then select the VPN tunnel you defined in the
phase 1 settings. You can then enable inbound and outbound traffic as needed.

01-420-99686-20101026 993
Planning your VPN FortiGate IPsec VPN Overview
Planning your VPN

To save time later and be ready to configure a VPN correctly, it is a good idea to plan the
VPN configuration ahead of time. All VPN configurations comprise a number of required
and optional parameters. Before you begin, you need to determine:
• where does the IP traffic originate, and where does it need to be delivered
• which hosts, servers, or networks to include in the VPN
• which VPN devices to include in the configuration
• through which interfaces the VPN devices communicate
• through which interfaces do private networks access the VPN gateways
Once you have this information, you can select a VPN topology that meets the
requirements of your situation. For more information, see “Network topologies” on
page 994.
Network topologies
The topology of your network will determine how remote peers and clients connect to the
VPN and how VPN traffic is routed. You can read about various network topologies and
find the high-level procedures needed to configure IPsec VPNs in one of these sections:
• Gateway-to-gateway configurations
• Hub-and-spoke configurations
• Dynamic DNS configurations
• FortiClient dialup-client configurations
• FortiGate dialup-client configurations
• Internet-browsing configuration
• Redundant VPN configurations
• Transparent mode VPNs
• Manual-key configurations
These sections contain high-level configuration guidelines with cross-references to
detailed configuration procedures. If you need more detail to complete a step, select the
cross-reference in the step to drill-down to more detail. Return to the original procedure to
complete the procedure. For a general overview of how to configure a VPN, see “General
preparation steps” below.
Choosing policy-based or route-based VPNs

There are two broad types of IPsec VPNs available on FortiGate units: policy-based and
route-based.
For both of these VPN types you create phase 1 and phase 2 configurations. The main
difference is in the firewall policy.
You create a policy-based VPN by defining an IPSEC firewall policy between two network
interfaces and associating it with the VPN tunnel (phase 1) configuration.
You create a route-based VPN by enabling IPsec interface mode in the VPN phase 1
configuration. This creates a virtual IPsec interface. You then define a regular ACCEPT
firewall policy to permit traffic to flow between the virtual IPsec interface and another
network interface.

994 01-420-99686-20101026
FortiGate IPsec VPN Overview General preparation steps
Where possible, create route-based VPNs. Generally, route-based VPNs are more flexible
and easier to configure than policy-based VPNs. However, the two types have different
requirements that limit where they can be used.
Table 70: Comparison of policy-based and route-based VPNs
Policy-based Route-based
Available in NAT/Route or Transparent mode Available only in NAT/Route mode
Requires a firewall policy with IPSEC action Requires only a simple firewall policy with
that specifies the VPN tunnel. One policy ACCEPT action. A separate policy is required for
controls connections in both directions. connections in each direction.
Supports L2TP-over-IPsec configuration Does not support L2TP-over-IPsec configuration
Doesn’t support GRE-over-IPsec configuration Supports GRE-over-IPsec configuration
General preparation steps

A VPN configuration defines relationships between the VPN devices and the private hosts,
servers, or networks making up the VPN. Configuring a VPN involves gathering and
recording the following information. You will need this information to configure the VPN.
• Identify the private IP address(es) of traffic generated by participating hosts, servers,
and/or networks. These IP addresses represent the source addresses of traffic that is
permitted to pass through the VPN. A IP source address can be an individual IP
address, an address range, or a subnet address.
• Identify the public IP addresses of the VPN end-point interfaces. The VPN devices
establish tunnels with each other through these interfaces.
• Identify the private IP address(es) associated with the VPN-device interfaces to the
private networks. Computers on the private network(s) behind the VPN gateways will
connect to their VPN gateways through these interfaces.
How to use this guide to configure an IPsec VPN

This guide uses a task-based approach to provide all of the procedures needed to create
different types of VPN configurations. Follow the step-by-step configuration procedures in
this guide to set up the VPN.
The following configuration procedures are common to all IPsec VPNs:
1 Define the phase 1 parameters that the FortiGate unit needs to authenticate remote
peers or clients and establish a secure a connection. See “Auto Key phase 1
parameters” on page 1135.
2 Define the phase 2 parameters that the FortiGate unit needs to create a VPN tunnel
with a remote peer or dialup client. See “Phase 2 parameters” on page 1151.
3 Specify the source and destination addresses of IP packets that are to be transported
through the VPN tunnel. See “Defining firewall addresses” on page 1157.
4 Create an IPsec firewall policy to define the scope of permitted services between the
IP source and destination addresses. See “Defining firewall policies” on page 1158.
Note: The steps given above assume that you will perform Steps 1 and 2 to have the
FortiGate unit generate unique IPsec encryption and authentication keys automatically. In
situations where a remote VPN peer or client requires a specific IPsec encryption and/or
authentication key, you must configure the FortiGate unit to use manual keys instead of
performing Steps 1 and 2. For more information, see “Manual-key configurations” on
page 1091.

01-420-99686-20101026 995
How to use this guide to configure an IPsec VPN FortiGate IPsec VPN Overview

996 01-420-99686-20101026
Gateway-to-gateway configurations
This section explains how to set up a basic gateway-to-gateway (site-to-site) IPsec VPN.
• Configuration overview
• General configuration steps
• Configure the VPN peers
• Configuration example
• How to work with overlapping subnets
Configuration overview
In a gateway-to-gateway configuration, two FortiGate units create a VPN tunnel between
two separate private networks. All traffic between the two networks is encrypted and
protected by FortiGate firewall policies.
Figure 110: Example gateway-to-gateway configuration
Fo
1 rtiG
te_ ate
r tiGa _2
Fo
Site_1 Site_2
Note: In some cases, computers on the private network behind one VPN peer may (by co-
incidence) have IP addresses that are already used by computers on the network behind
the other VPN peer. In this type of situation (ambiguous routing), conflicts may occur in one
or both of the FortiGate routing tables and traffic destined for the remote network through
the tunnel may not be sent. To resolve issues related to ambiguous routing, see “How to
work with overlapping subnets” on page 1006.
In other cases, computers on the private network behind one VPN peer may obtain IP
addresses from a local DHCP server. However, unless the local and remote networks use
different private network address spaces, unintended ambiguous routing and/or IP-address
overlap issues may arise. For a discussion of the related issues, see “FortiGate dialup-
client configurations” on page 1047.
You can set up a fully meshed or partially meshed configuration (see Figure 111 and
Figure 112).

01-420-99686-20101026 997
Configuration overview Gateway-to-gateway configurations
Figure 111: Fully meshed configuration
2 Fo
te_ rtiG
r tiGa ate
_3
Fo
Fo
rtiG
_1 ate
i G ate _4
r t
Fo
5
te_
rt iGa
Fo
In a fully meshed network, all VPN peers are connected to each other, with one hop
between peers. This topology is the most fault-tolerant: if one peer goes down, the rest of
the network is not affected. This topology is difficult to scale because it requires
connections between all peers. In addition, unnecessary communication can occur
between peers. We recommend a hub-and-spoke configuration instead (see “Hub-and-
spoke configurations” on page 1011).
Figure 112: Partially meshed configuration
Fo
_2 rtiG
i G ate ate
r t _3
Fo
Fo
rtiG
_1 ate
i Gate _4
rt
Fo
_5
i G ate
ort
F
A partially meshed network is similar to a fully meshed network, but instead of having
tunnels between all peers, tunnels are only configured between peers that communicate
with each other regularly.

998 01-420-99686-20101026
Gateway-to-gateway configurations General configuration steps
Gateway-to-gateway infrastructure requirements

• The FortiGate units at both ends of the tunnel must be operating in NAT/Route mode
and have static public IP addresses.

When a FortiGate unit receives a connection request from a remote VPN peer, it uses
IPsec phase 1 parameters to establish a secure connection and authenticate the VPN
peer. Then, if the firewall policy permits the connection, the FortiGate unit establishes the
tunnel using IPsec phase 2 parameters and applies the IPsec firewall policy. Key
management, authentication, and security services are negotiated dynamically through
the IKE protocol.
To support these functions, the following general configuration steps must be performed
both FortiGate units:
• Define the phase 1 parameters that the FortiGate unit needs to authenticate the
remote peer and establish a secure connection.
• Define the phase 2 parameters that the FortiGate unit needs to create a VPN tunnel
with the remote peer.
• Create firewall policies to control the permitted services and permitted direction of
traffic between the IP source and destination addresses.
For more information, see “Configure the VPN peers” below.
Configure the VPN peers

Configure the VPN peers as follows:
1 At the local FortiGate unit, define the phase 1 configuration needed to establish a
secure connection with the remote peer. See “Auto Key phase 1 parameters” on
page 1135. Enter these settings in particular:
Name Enter a name to identify the VPN tunnel. This name appears in phase 2
configurations, firewall policies and the VPN monitor.
Remote Gateway Select Static IP Address.
IP Address Type the IP address of the remote peer public interface.
Local Interface Select the FortiGate unit’s public interface.
Enable IPsec You must select Advanced to see this setting. If IPsec Interface Mode is
Interface Mode enabled, the FortiGate unit creates a virtual IPsec interface for a route-
based VPN. Disable this option if you want to create a policy-based
VPN. For more information, see “Choosing policy-based or route-based
VPNs” on page 994.
After you select OK to create the phase 1 configuration, you cannot
change this setting.
2 Define the phase 2 parameters needed to create a VPN tunnel with the remote peer.
See “Phase 2 parameters” on page 1151. Enter these settings in particular:
Name Enter a name to identify this phase 2 configuration.

Phase 1 Select the name of the phase 1 configuration that you defined.

01-420-99686-20101026 999
Configure the VPN peers Gateway-to-gateway configurations
3 Define names for the addresses or address ranges of the private networks that the
VPN links. These addresses are used in the firewall policies that permit communication
between the networks. For more information, see “Defining firewall addresses” on
page 1157.
Enter these settings in particular:
• Define an address name for the IP address and netmask of the private network behind
the local FortiGate unit.
• Define an address name for the IP address and netmask of the private network behind
the remote peer.
4 Define firewall policies to permit communication between the private networks through
the VPN tunnel. Route-based and policy-based VPNs require different firewall policies.
For detailed information about creating firewall policies, see “Defining firewall policies”
on page 1158.
Route-based VPN firewall policies
Define an ACCEPT firewall policy to permit communications between the source and
destination addresses. Enter these settings in particular:
Source Interface/Zone Select the interface that connects to the private network behind
this FortiGate unit.
Source Address Name Select the address name that you defined in Step 3 for the
private network behind this FortiGate unit.
Destination Interface/Zone Select the VPN Tunnel (IPsec Interface) you configured in
Step 1.
Destination Address Name Select the address name that you defined in Step 3 for the
private network behind the remote peer.
NAT Disable.
To permit the remote client to initiate communication, you need to define a firewall
policy for communication in that direction. Enter these settings in particular:
Source Interface/Zone Select the VPN Tunnel (IPsec Interface) you configured in
Step 1.
Destination Interface/Zone Select the interface that connects to the private network behind
NAT Disable.
Policy-based VPN firewall policy

Define an IPsec firewall policy to permit communications between the source and
Destination Interface/Zone Select the FortiGate unit’s public interface.

1000 01-420-99686-20101026
Gateway-to-gateway configurations Configuration example
Action Select IPSEC.
VPN Tunnel Select the name of the phase 1 configuration that you created
in Step 1.
Select Allow inbound to enable traffic from the remote network
to initiate the tunnel.
Select Allow outbound to enable traffic from the local network to
initiate the tunnel.
5 Place VPN policies in the policy list above any other policies having similar source and
destination addresses.
6 Repeat this procedure at the remote FortiGate unit.
Configuration example
The following example demonstrates how to set up a basic gateway-to-gateway IPsec
VPN that uses preshared keys to authenticate the two VPN peers.
Figure 113: Example gateway-to-gateway configuration
P
17 ort Fo
1 2.1 2 rtiG
te_ rt 2 0.1 6.3
r tiGa Po .16.2 0.1 ate
_2
Fo 1 7 2
Po
rt 1
rt 1
Po
Fin H
a 10 R ne
10 nce .31 tw
.21 ne .10 ork
.10 two 1.0
1.0 rk /24
/24
In this example, the network devices are assigned IP addresses as shown in Figure 113.
Define the phase 1 parameters on FortiGate_1

The phase 1 configuration defines the parameters that FortiGate_1 will use to authenticate
FortiGate_2 and establish a secure connection. For the purposes of this example, a
preshared key will be used to authenticate FortiGate_2. The same preshared key must be
specified at both FortiGate units.
Before you define the phase 1 parameters, you need to:
• Reserve a name for the remote gateway.
• Obtain the IP address of the public interface to the remote peer.
• Reserve a unique value for the preshared key.
The key must contain at least 6 printable characters and should only be known by network
administrators. For optimum protection against currently known attacks, the key should
consist of a minimum of 16 randomly chosen alphanumeric characters.

01-420-99686-20101026 1001
Configuration example Gateway-to-gateway configurations
To define the phase 1 parameters

1 Go to VPN > IPSEC > Auto Key.
2 Select Create Phase 1, enter the following information, and select OK:
Name Type a name to identify the VPN tunnel (for example,

FG1toFG2_Tunnel).
IP Address 172.16.30.1
Local Interface Port 2
Mode Main
Authentication Method Preshared Key
Pre-shared Key Enter the preshared key.
Peer Options Accept any peer ID
Advanced
Enable IPsec Enable to create a route-based VPN.
Interface Mode Disable to create a policy-based VPN.
This example shows both policy and route-based VPNs.
Define the phase 2 parameters on FortiGate_1

The basic phase 2 settings associate IPsec phase 2 parameters with the phase 1
configuration and specify the remote end point of the VPN tunnel. Before you define the
phase 2 parameters, you need to reserve a name for the tunnel.

2 Select Create Phase 2, enter the following information and select OK:
Name Enter a name for the phase 2 configuration

(for example, FG1toFG2_phase2).
Phase 1 Select the Phase 1 configuration that you defined previously
(for example, FG1toFG2_Tunnel).
Define the firewall policy on FortiGate_1

Firewall policies control all IP traffic passing between a source address and a destination
address.
An IPsec firewall policy is needed to allow the transmission of encrypted packets, specify
the permitted direction of VPN traffic, and select the VPN tunnel that will be subject to the
policy. A single policy is needed to control both inbound and outbound IP traffic through a
VPN tunnel.
Before you define firewall policies, you must first specify the IP source and destination
addresses. In a gateway-to-gateway configuration:
• The IP source address corresponds to the private network behind the local FortiGate
unit.
• The IP destination address refers to the private network behind the remote VPN peer.
To define the IP address of the network behind FortiGate_1

2 Select Create New, enter the following information, and select OK:

1002 01-420-99686-20101026
Address Name Enter an address name

(for example, Finance_Network).
Subnet/IP Range Enter the IP address of the private network behind FortiGate_1
(for example, 10.21.101.0/24).
To specify the address of the network behind FortiGate_2

Address Name Enter an address name (for example, HR_Network).

Subnet/IP Range Enter the IP address of the private network behind
FortiGate_2 (for example, 10.31.101.0/24).
To define the firewall policy for a policy-based VPN

Source Interface/Zone Port 1

Source Address Name Finance_Network
Destination Interface/Zone Port 2
Destination Address Name HR_Network
Schedule As required.
Service As required.
Action IPSEC
VPN Tunnel FG1toFG2_Tunnel
Allow Inbound Enable
Allow Outbound Enable
Inbound NAT Disable
3 Place the policy in the policy list above any other policies having similar source and
To define firewall policies for a route-based VPN


Destination Interface/Zone FG1toFG2_Tunnel
Action ACCEPT
NAT Disable

01-420-99686-20101026 1003
Configuration example Gateway-to-gateway configurations
Source Interface/Zone FG1toFG2_Tunnel

Source Address Name HR_Network
Destination Address Name Finance_Network
Action ACCEPT
NAT Disable
4 Place the policies in the policy list above any other policies having similar source and
To configure the route for a route-based VPN

2 Select Create New, enter the following information, and then select OK:
Destination IP / Mask 10.31.101.0/24

Device FG1toFG2_Tunnel
Gateway Leave as default: 0.0.0.0.
Distance Leave this at its default.
Configure FortiGate_2
The configuration of FortiGate_2 is similar to that of FortiGate_1. You must:
• Define the phase 1 parameters that FortiGate_2 needs to authenticate FortiGate_1
and establish a secure connection.
• Define the phase 2 parameters that FortiGate_2 needs to create a VPN tunnel with
FortiGate_1.
• Create the firewall policy and define the scope of permitted services between the IP

Name Type a name for the VPN tunnel (for example,

FG2toFG1_Tunnel).
Mode Main
Pre-shared Key Enter the preshared key. The value must be identical to the
preshared key that you specified previously in the FortiGate_1
configuration.

1004 01-420-99686-20101026
Advanced
Enable IPsec Enable to create a route-based VPN.
Interface Mode Disable to create a policy-based VPN.
This example shows both policy and route-based VPNs.

Name Enter a name for the phase 2 configuration (for example,

FG2toFG1_phase2).
Phase 1 Select the gateway that you defined previously (for example,
FG2toFG1_Tunnel).


Subnet/IP Range 10.31.101.0/24
This is the IP address of the private network behind
FortiGate_2.

Address Name Enter an address name (for example, Finance_Network).

Subnet/IP Range Enter the IP address of the private network behind
FortiGate_1 (for example, 10.21.101.0/24).
To define the firewall policy for a policy-based VPN


Action IPSEC
VPN Tunnel FG2toFG1_Tunnel
Inbound NAT Disable

01-420-99686-20101026 1005
How to work with overlapping subnets Gateway-to-gateway configurations
To define the firewall policies for a route-based VPN

2 Select Create New, enter the following information to create an outbound policy, and
then select OK:

Destination Interface/Zone FG2toFG1_Tunnel
Action ACCEPT
NAT Disable
3 Select Create New, enter the following information to create an inbound policy, and
then select OK:
Source Interface/Zone FG2toFG1_Tunnel

Action ACCEPT
NAT Disable
To configure the route for a route-based VPN

Destination IP / Mask 10.21.101.0/24

Device FG2toFG1_Tunnel
Distance Usually you can leave this at its default.
How to work with overlapping subnets

A site-to-site VPN configuration sometimes has the problem that the private subnet
addresses at each end are the same. You can resolve this problem by remapping the
private addresses using virtual IP addresses (VIP).

1006 01-420-99686-20101026
Gateway-to-gateway configurations How to work with overlapping subnets
Figure 114: Overlapped subnets example
P
17 ort Fo
2.1 2
at e_1 rt 2 0.1 6.3 rtiG
rtiG Po .16.2 0.1 ate
_2
Fo 17 2
Po
rt 1 rt 1
10 PC
Po .11 2
.10
1.1
0
1 1.10
Fin
a PC 1.10 H
1
1 nc
(V 0.11 e ne
10. 1 Rn
IP t (V 0.11 etw
10 .101 work IP o
10 .101 rk
.21 .0/ .31 .0/
.10 24 .10 24
1.0 1.0
/24) /24
)
After the tunnel is established, hosts on each side can communicate with hosts on the
other side using the mapped IP addresses. For example, PC1 can communicate with PC2
using IP address 10.31.101.10. FortiGate_2 maps connections for IP address
10.31.101.10 to IP address 10.11.101.10.
Solution for route-based VPN

You need to:
• Configure IPsec Phase 1 and Phase 2 as you usually would for a route-based VPN. In
this example, the resulting IPsec interface is named FG1toFG2.
• Configure virtual IP (VIP) mapping:
• the 10.21.101.0/24 network to the 10.11.101.0/24 network on FortiGate_1
• the 10.31.101.0/24 network to the 10.11.101.0/24 network on FortiGate_2
• Configure an outgoing firewall policy with ordinary source NAT.
• Configure an incoming firewall policy with the VIP as the destination.
• Configure a route to the remote private network over the IPsec interface.
To configure VIP mapping

Name Enter a name, for example, my-vip.

External Interface Select the IPsec interface: FG1toFG2
Type Static NAT
External IP Address/Range In the first field, enter:
10.21.101.1 on FortiGate_1
10.31.101.1 on FortiGate_2.
Mapped IP Address/Range Enter 10.11.101.1 and 10.11.101.254.
Port Forwarding Disable

01-420-99686-20101026 1007
To configure the outbound firewall policy


Source Address Name all
Destination Interface/Zone FG1toFG2
Destination Address Name all
Action ACCEPT
NAT Enable
To configure the inbound firewall policy

Source Interface/Zone FG1toFG2

Source Address Name all
Destination Address Name my-vip
Action ACCEPT
NAT Disable
To configure the route

Destination IP / Mask 10.31.101.0/24 on FortiGate_1

10.21.101.0/24 on FortiGate_2
Device FG1toFG2
Distance Usually you can leave this at its default.
Solution for policy-based VPN

As with the route-based solution, users contact hosts at the other end of the VPN using an
alternate subnet address. PC1 communicates with PC2 using IP address 10.31.101.10.
PC2 communicates with PC1 using IP address 10.21.101.10. In this solution however,
outbound NAT is used to translate the source address of packets from the 10.11.101.0/24
network to the alternate subnet address that hosts at the other end of the VPN use to
reply. Inbound packets from the remote end have their destination addresses translated
back to the 10.11.101.0/24 network.

1008 01-420-99686-20101026
Gateway-to-gateway configurations How to work with overlapping subnets
For example, PC1 uses the destination address 10.31.101.10 to contact PC2. Outbound
NAT on FortiGate_1 translates the PC1 source address to 10.21.101.10. At the
FortiGate_2 end of the tunnel, the outbound NAT configuration translates the destination
address to the actual PC2 address of 10.11.101.10. Similarly, PC2 replies to PC1 using
destination address 10.21.101.10, with the PC2 source address translated to
10.31.101.10. PC1 and PC2 can communicate over the VPN even though they both have
the same IP address.
You need to:
• Configure IPsec Phase 1 as you usually would for a policy-based VPN.
• Configure IPsec Phase 2 with the use-natip disable CLI option.
• Define a firewall address for the local private network, 10.11.101.0/24.
• Define a firewall address for the remote private network:
• define a firewall address for 10.31.101.0/24 on FortiGate_1
• define a firewall address for 10.21.101.0/24 on FortiGate_2
• Configure an outgoing IPsec firewall policy with outbound NAT to map 10.11.101.0/24
source addresses:
• to the 10.21.101.0/24 network on FortiGate_1
• to the 10.31.101.0/24 network on FortiGate_2
To configure IPsec Phase 2

In the CLI, enter the following commands:
edit "FG1FG2_p2"
set keepalive enable
set pfs enable
set phase1name FG1toFG2
set proposal 3des-sha1 3des-md5
set replay enable
set use-natip disable
end
In this example, your phase 1 definition is named FG1toFG2. Because use-natip is set
to disable, you can specify the source selector using the src-addr-type, src-
start-ip / src-end-ip or src-subnet keywords. This example leaves these
keywords at their default values, which specify the subnet 0.0.0.0/0.
To define the local private network firewall address

Address Name Enter a name, vpn-local, for example.

Subnet / IP Range 10.11.101.0 255.255.255.0
Interface Any
To define the remote private network firewall address

2 Select Create New, enter the following information and select OK:

01-420-99686-20101026 1009
Address Name Enter a name, vpn-remote, for example.

Subnet / IP Range 10.31.101.0 255.255.255.0 on FortiGate_1
10.21.101.0 255.255.255.0 on FortiGate_2
Interface Any
To configure the IPsec firewall policy

In the CLI, enter the following commands:
edit 1
set srcintf "port1"
set dstintf "port2"
set srcaddr "vpn-local"
set dstaddr "vpn-remote"
set action ipsec
set service "ANY"
set inbound enable
set outbound enable
set vpntunnel "FG1toFG2"
set natoutbound enable
set natip 10.21.101.0 255.255.255.0 (on FortiGate_1)
set natip 10.31.101.0 255.255.255.0 (on FortiGate_2)
end
Optionally, you can set everything except natip in the web-based manager and then use
the CLI to set natip.

1010 01-420-99686-20101026
Hub-and-spoke configurations
This section describes how to set up hub-and-spoke IPsec VPNs. The following topics are
included in this section:
• Configure the hub
• Configure the spokes
• Dynamic spokes configuration example
In a hub-and-spoke configuration, VPN connections radiate from a central FortiGate unit
(the hub) to a number of remote peers (the spokes). Traffic can pass between private
networks behind the hub and private networks behind the remote peers. Traffic can also
pass between remote peer private networks through the hub.
Figure 115: Example hub-and-spoke configuration
Site_1 Site_2
Sp
ok
e_ _2
1 oke
Sp
b
Hu
HR network Finance network
The actual implementation varies in complexity depending on

• whether the spokes are statically or dynamically addressed
• the addressing scheme of the protected subnets
• how peers are authenticated
This guide discusses the issues involved in configuring a hub-and-spoke VPN and
provides some basic configuration examples.

01-420-99686-20101026 1011
Configuration overview Hub-and-spoke configurations
Hub-and-spoke infrastructure requirements

• The FortiGate hub must be operating in NAT/Route mode and have a static public IP
address.
• Spokes may have static IP addresses, dynamic IP addresses (see “FortiGate dialup-
client configurations” on page 1047), or static domain names and dynamic IP
addresses (see “Dynamic DNS configurations” on page 1025).
Spoke gateway addressing

The public IP address of the spoke is the VPN remote gateway as seen from the hub.
Statically addressed spokes each require a separate VPN phase 1 configuration on the
hub. When there are many spokes, this becomes rather cumbersome.
Using dynamic addressing for spokes simplifies the VPN configuration because then the
hub requires only a single phase 1 configuration with “dialup user” as the remote gateway.
You can use this configuration even if the remote peers have static IP addresses. A
remote peer can establish a VPN connection regardless of its IP address if its traffic
selectors match and it can authenticate to the hub. See “Dynamic spokes configuration
example” on page 1020 for an example of this configuration.
Protected networks addressing

The addresses of the protected networks are needed to configure destination selectors
and sometimes for firewall policies and static routes. The larger the number of spokes, the
more addresses there are to manage. You can
• assign spoke subnets as part of a larger subnet, usually on a new network
or
• create address groups that contain all of the needed addresses
Using aggregated subnets

If you are creating a new network, where subnet IP addresses are not already assigned,
you can simplify the VPN configuration by assigning spoke subnets that are part of a large
subnet.
Figure 116: Aggregated subnets

large subnet
hub protected subnet: 10.1.0.0/24

spoke 1 protected subnet: 10.1.1.0/24
spoke 2 protected subnet: 10.1.2.0/24
spoke x protected subnet: 10.1.x.0/24
All spokes use the large subnet address, 10.1.0.0/16 for example, as
• the IPsec destination selector
• the destination of the firewall policy from the private subnet to the VPN (required for
policy-based VPN, optional for route-based VPN)
• the destination of the static route to the VPN (route-based)

1012 01-420-99686-20101026
Hub-and-spoke configurations Configure the hub
Each spoke uses the address of its own protected subnet as the IPsec source selector
and as the source address in its VPN firewall policy. The remote gateway is the public IP
address of the hub FortiGate unit.
Using an address group

If you want to create a hub-and-spoke VPN between existing private networks, the subnet
addressing usually does not fit the aggregated subnet model discussed earlier. All of the
spokes and the hub will need to include the addresses of all the protected networks in
their configuration.
On FortiGate units, you can define a named firewall address for each of the remote
protected networks and add these addresses to a firewall address group. For a policy-
based VPN, you can then use this address group as the destination of the VPN firewall
policy.
For a route-based VPN, the destination of the VPN firewall policy can be set to All. You
need to specify appropriate routes for each of the remote subnets.
Authentication
Authentication is by a common preshared key or by certificates. For simplicity, the
examples in this chapter assume that all spokes use the same preshared key.
Configure the hub

At the FortiGate unit that acts as the hub, you need to
• configure the VPN to each spoke
• configure communication between spokes
You configure communication between spokes differently for a policy-based VPN than for
a route-based VPN. For a policy-based VPN, you configure a VPN concentrator. For a
route-based VPN, you must either define firewall policies or group the IPsec interfaces
into a zone
Define the hub-spoke VPNs

Perform these steps at the FortiGate unit that will act as the hub. Although this procedure
assumes that the spokes are all FortiGate units, a spoke could also be VPN client
software, such as FortiClient Endpoint Security.
To configure the VPN hub

1 At the hub, define the phase 1 configuration for each spoke. See “Auto Key phase 1
parameters” on page 1135. Enter these settings in particular:

01-420-99686-20101026 1013
Configure the hub Hub-and-spoke configurations
Name Enter a name to identify the VPN in phase 2 configurations, firewall policies
and the VPN monitor.
Remote Gateway The remote gateway is the other end of the VPN tunnel. There are three
options:
Static IP Address — Enter the spoke’s public IP Address. You will need to
create a phase 1 configuration for each spoke. Either the hub or the spoke
can establish the VPN connection.
Dialup User — No additional information is needed. The hub accepts
connections from peers with appropriate encryption and authentication
settings. Only one phase 1 configuration is needed for multiple dialup
spokes. Only the spoke can establish the VPN tunnel.
Dynamic DNS — If the spoke subscribes to a dynamic DNS service, enter
the spoke’s Dynamic DNS domain name. Either the hub or the spoke can
establish the VPN connection. For more information, see “Dynamic DNS
configurations” on page 1025.
Local Interface Select the FortiGate interface that connects to the remote gateway. This is
usually the FortiGate unit’s public interface.
Enable IPsec You must select Advanced to see this setting. If IPsec Interface Mode is
Interface Mode enabled, the FortiGate unit creates a virtual IPsec interface for a route-
based VPN. Disable this option if you want to create a policy-based VPN.
For more information, see “Choosing policy-based or route-based VPNs”
on page 994.
After you select OK to create the phase 1 configuration, you cannot change
this setting.
2 Define the phase 2 parameters needed to create a VPN tunnel with each spoke. See
“Phase 2 parameters” on page 1151. Enter these settings in particular:
Name Enter a name to identify this spoke phase 2 configuration.

Phase 1 Select the name of the phase 1 configuration that you defined for this
spoke.
Define the hub-spoke firewall policies

1 Define a name for the address of the private network behind the hub. For more
information, see “Defining firewall addresses” on page 1157.
2 Define names for the addresses or address ranges of the private networks behind the
spokes. For more information, see “Defining firewall addresses” on page 1157.
3 Define the VPN concentrator. See “To define the VPN concentrator” on page 1015.
4 Define firewall policies to permit communication between the hub and the spokes. For
more information, see “Defining firewall policies” on page 1158.
Define ACCEPT firewall policies to permit communications between the hub and the
spoke. You need one policy for each direction. Enter these settings in particular:
Step 1.
Source Address Name Select the address name you defined in Step 2 for the
private network behind the spoke FortiGate unit.
Destination Interface/Zone Select the hub’s interface to the internal (private) network.
Destination Address Name Select the source address that you defined in Step 1.
NAT Enable.

1014 01-420-99686-20101026
Hub-and-spoke configurations Configure the hub
Source Interface/Zone Select the address name you defined in Step 2 for the
private network behind the spoke FortiGate units.
Source Address Name Select the VPN Tunnel (IPsec Interface) you configured in
Step 1.
Destination Interface/Zone Select the source address that you defined in Step 1.
Destination Address Name Select the hub’s interface to the internal (private) network.
NAT Enable.

Define an IPsec firewall policy to permit communications between the hub and the
spoke. Enter these settings in particular:
Source Interface/Zone Select the hub’s interface to the internal (private) network.
Source Address Name Select the source address that you defined in Step 1.
Destination Interface/Zone Select the hub’s public network interface.
Destination Address Name Select the address name you defined in Step 2 for the private
network behind the spoke FortiGate unit.
Action IPSEC
for the spoke in Step 1.
5 In the policy list, arrange the policies in the following order:

• IPsec policies that control traffic between the hub and the spokes first
• the default firewall policy last
Configuring communication between spokes (policy-based VPN)

For a policy-based hub-and-spoke VPN, you define a concentrator to enable
communication between the spokes.
To define the VPN concentrator

1 At the hub, go to VPN > IPSEC > Concentrator and select Create New.
2 In the Concentrator Name field, type a name to identify the concentrator.
3 From the Available Tunnels list, select a VPN tunnel and then select the right-pointing
arrow.
Note: To remove tunnels from the VPN concentrator, select the tunnel in the Members list
and select the left-pointing arrow.
4 Repeat Step 3 until all of the tunnels associated with the spokes are included in the
concentrator.
5 Select OK.

01-420-99686-20101026 1015
Configure the hub Hub-and-spoke configurations
Configuring communication between spokes (route-based VPN)

For a route-based hub-and-spoke VPN, there are several ways you can enable
communication between the spokes:
• put all of the IPsec interfaces into a zone and enable intra-zone traffic. This eliminates
the need for any firewall policy for the VPN, but you cannot apply UTM features to scan
the traffic for security threats.
• put all of the IPsec interfaces into a zone and create a single zone-to-zone firewall
policy
• create a firewall policy for each pair of spokes that are allowed to communicate with
each other. The number of policies required increases rapidly as the number of spokes
increases.
Using a zone as a concentrator

A simple way to provide communication among all of the spokes is to create a zone and
allow intra-zone communication. You cannot apply UTM features using this method.
1 Go to System > Network > Zone and select Create New.
2 In the Zone Name field, enter a name, such as Our_VPN_zone.
3 Clear Block intra-zone traffic.
4 In the Interface Members list, select the IPsec interfaces that are part of your VPN.
5 Select OK.
Using a zone with a policy as a concentrator

If you put all of the hub IPsec interfaces involved in the VPN into a zone, you can enable
communication among all of the spokes and apply UTM features with just one firewall
policy.
To create a zone for the VPN

3 Select Block intra-zone traffic.
4 In the Interface Members list, select the IPsec interfaces that are part of your VPN.
5 Select OK.
To create a firewall policy for the zone

1 Go to Firewall > Policy > Policy. Select Create New and enter these settings:
Source Interface/Zone Select the zone you created for your VPN.
Source Address Name Select All.
Destination Interface/Zone Select the zone you created for your VPN.
Destination Address Name Select All.
NAT Enable.
UTM If you want to apply UTM features to this traffic, select the
appropriate profiles.
2 Select OK.

1016 01-420-99686-20101026
Hub-and-spoke configurations Configure the spokes
Using firewall policies as a concentrator

To enable communication between two spokes, you need to define an ACCEPT firewall
policy for them. To allow either spoke to initiate communication, you must create a policy
for each direction. This procedure describes a firewall policy for communication from
Spoke 1 to Spoke 2. Others are similar.
1 Define names for the addresses or address ranges of the private networks behind
each spoke. For more information, see “Defining firewall addresses” on page 1157.
2 Go to Firewall > Policy > Policy. Select Create New and enter these settings in
particular:
Source Interface/Zone Select the IPsec interface that connects to Spoke 1.

Source Address Name Select the address of the private network behind Spoke 1.
Destination Interface/Zone Select the IPsec interface that connects to Spoke 2.
Destination Address Name Select the address of the private network behind Spoke 2.
NAT Enable.
UTM If you want to apply UTM features to this traffic, select the
appropriate profiles.
3 Select OK.
Configure the spokes

Although this procedure assumes that the spokes are all FortiGate units, a spoke could
also be VPN client software, such as FortiClient Endpoint Security.
Perform these steps at each FortiGate unit that will act as a spoke.
To create the phase 1 and phase_2 configurations

1 At the spoke, define the phase 1 parameters that the spoke will use to establish a
secure connection with the hub. See “Auto Key phase 1 parameters” on page 1135.

IP Address Type the IP address of the interface that connects to the hub.
Enable IPsec Enable if you are creating a route-based VPN.
Interface Mode Clear if you are creating a policy-based VPN.
2 Create the phase 2 tunnel definition. See “Phase 2 parameters” on page 1151. Enter
these settings in particular:
Phase 1 Select the set of phase 1 parameters that you defined for the hub.
You can select the name of the hub from the Static IP Address part
of the list.
Configuring firewall policies for hub-to-spoke communication

1 Create an address for this spoke. See “Defining firewall addresses” on page 1157.
Enter the IP address and netmask of the private network behind the spoke.
2 Create an address to represent the hub. See “Defining firewall addresses” on
page 1157. Enter the IP address and netmask of the private network behind the hub.

01-420-99686-20101026 1017
Configure the spokes Hub-and-spoke configurations
3 Define the firewall policy to enable communication with the hub.

Route-based VPN firewall policy
Define two firewall policies to permit communications to and from the hub. Enter these
settings in particular:
Source Interface/Zone Select the virtual IPsec interface you created.

Source Address Name Select the hub address you defined in Step 1.
Destination Interface/Zone Select the spoke’s interface to the internal (private) network.
Destination Address Name Select the spoke addresses you defined in Step 2.
Action Select ACCEPT
NAT Enable
Source Interface/Zone Select the spoke’s interface to the internal (private) network.
Source Address Name Select the spoke address you defined in Step 1.
Destination Interface/Zone Select the virtual IPsec interface you created.
Destination Address Name Select the hub destination addresses you defined in Step 2.
NAT Enable

Define an IPsec firewall policy to permit communications with the hub. See “Defining
firewall policies” on page 1158. Enter these settings in particular:
Source Address Name Select the spoke address you defined in Step 1.
Destination Interface/Zone Select the spoke’s interface to the external (public) network.
Destination Address Name Select the hub address you defined in Step 2.
Action Select IPSEC
VPN Tunnel Select the name of the phase 1 configuration you defined.
Select Allow outbound to enable traffic from the local network
Configuring firewall policies for spoke-to-spoke communication

Each spoke requires firewall policies to enable communication with the other spokes.
Instead of creating separate firewall policies for each spoke, you can create an address
group that contains the addresses of the networks behind the other spokes. The firewall
policy then applies to all of the spokes in the group.
1 Define destination addresses to represent the networks behind each of the other
spokes. Add these addresses to an address group. For more information, see
“Configuring Address Groups” section in the “Firewall Address” chapter of the
FortiGate Administration Guide.

1018 01-420-99686-20101026
Hub-and-spoke configurations Configure the spokes
2 Define the firewall policy to enable communication between this spoke and the spokes
in the address group you created.
Define an IPsec firewall policy to permit communications with the other spokes. See
“Defining firewall policies” on page 1158. Enter these settings in particular:
Define two firewall policies to permit communications to and from the other spokes.
Source Interface/Zone Select the virtual IPsec interface you created.

Source Address Name Select the spoke address group you defined in Step 1.
Destination Interface/Zone Select the spoke’s interface to the internal (private) network.
Destination Address Name Select this spoke’s address name.
NAT Enable
Source Address Name Select this spoke’s address name.
Destination Interface/Zone Select the virtual IPsec interface you created.
Destination Address Name Select the spoke address group you defined in Step 1.
NAT Enable
Source Interface/Zone Select this spoke’s internal (private) network interface.

Source Address Name Select this spoke’s source address.
Destination Interface/Zone Select the spoke’s interface to the external (public) network.
Destination Address Name Select the spoke address group you defined in Step 1.
Action Select IPSEC
VPN Tunnel Select the name of the phase 1 configuration you defined.
3 Place this policy or policies in the policy list above any other policies having similar

01-420-99686-20101026 1019
Dynamic spokes configuration example Hub-and-spoke configurations
Dynamic spokes configuration example

This example demonstrates how to set up a basic route-based hub-and-spoke IPsec VPN
that uses preshared keys to authenticate VPN peers.
Figure 117: Example hub-and-spoke configuration
Site_1 Site_2
10.1.1.0/24 10.1.2.0/24
Sp
ok
e_ _2
1 oke
Sp
1
ate_
rtiG
Fo b) 172.16.10.1
(Hu
HR network
10.1.0.0/24
In the example configuration, the protected networks 10.1.0.0/24, 10.1.1.0/24 and

10.1.2.0/24 are all part of the larger subnet 10.1.0.0/16. The steps for setting up the
example hub-and-spoke configuration create a VPN among Site 1, Site 2, and the HR
Network.
The spokes are dialup. Their addresses are not part of the configuration on the hub, so
only one spoke definition is required no matter the number of spokes. For simplicity, only
two spokes are shown.
Configure the hub (FortiGate_1)

The phase 1 configuration defines the parameters that FortiGate_1 will use to authenticate
spokes and establish secure connections.
For the purposes of this example, one preshared key will be used to authenticate all of the
spokes. Each key must contain at least 6 printable characters and should only be known
by network administrators. For optimum protection against currently known attacks, each
key should consist of a minimum of 16 randomly chosen alphanumeric characters.
Define the IPsec configuration

1 At FortiGate_1, go to VPN > IPSEC > Auto Key.
2 Define the phase 1 parameters that the hub will use to establish a secure connection to
the spokes. Select Create Phase 1, enter the following information, and select OK:

1020 01-420-99686-20101026
Hub-and-spoke configurations Dynamic spokes configuration example
Name Type a name (for example, toSpokes).

Remote Gateway Dialup user
Local Interface External
Mode Main
The basic phase 2 settings associate IPsec phase 2 parameters with the phase 1
configuration and specify the remote end points of the VPN tunnels.

2 Create a phase 2 tunnel definition for the spokes. Select Create Phase 2, enter the
following information, and select OK:
Name Enter a name for the phase 2 definition (for example, toSpokes_ph2).
Phase 1 Select the Phase 1 configuration that you defined previously (for example,
toSpokes).
Define the firewall policies

Firewall policies control all IP traffic passing between a source address and a destination
address. For a route-based VPN, the policies are simpler than for a policy-based VPN.
Instead of an IPSEC policy, you use an ACCEPT policy with the virtual IPsec interface as
the external interface.
Before you define firewall policies, you must first define firewall addresses to use in those
policies. You need addresses for:
• the HR network behind FortiGate_1
• the aggregate subnet address for the protected networks
To define the IP address of the HR network behind FortiGate_1


Subnet/IP Range Enter the IP address of the HR network behind FortiGate_1
(for example, 10.1.0.0/24).
To specify the IP address the aggregate protected subnet

Address Name Enter an address name (for example, Spoke_net).

Subnet/IP Range Enter the IP address of the aggregate protected network,
10.1.0.0/16
To define the firewall policy for traffic from the hub to the spokes

01-420-99686-20101026 1021
Source Interface/Zone Select the interface to the HR network, port 1.

Address Name HR_Network
Destination Interface/Zone Select the virtual IPsec interface that connects to the spokes,
toSpokes
Address Name Spoke_net
Action ACCEPT
Configure communication between spokes

Spokes communicate with each other through the hub. You need to configure the hub to
allow this communication. An easy way to do this is to create a zone containing the virtual
IPsec interfaces (even if there is only one) and create a zone-to-zone firewall policy.
To create a zone for the VPN

3 Select Block intra-zone traffic.
You could enable intra-zone traffic and then you would not need to create a firewall
policy. But, you would not be able to apply UTM features.
4 In Interface Members, select the virtual IPsec interface, toSpokes.
5 Select OK.
To create a firewall policy for the zone

1 Go to Firewall > Policy > Policy. Select Create New and enter these settings:
Source Interface/Zone Select Our_VPN_zone.

Destination Interface/Zone Select Our_VPN_zone.
NAT Enable.
UTM Select the appropriate UTM profiles.
2 Select OK.

1022 01-420-99686-20101026
Hub-and-spoke configurations Dynamic spokes configuration example
Configure the spokes

In this example, all spokes have nearly identical configuration, requiring the following:
• phase 1 authentication parameters to initiate a connection with the hub
• phase 2 tunnel creation parameters to establish a VPN tunnel with the hub
• a source address that represents the network behind the spoke. This is the only part of
the configuration that is different for each spoke.
• a destination address that represents the aggregate protected network
• a firewall policy to enable communications between the spoke and the aggregate
protected network
Define the IPsec configuration

At each spoke, create the following configuration.

1 At the spoke, go to VPN > IPSEC > Auto Key.
Name Type a name, for example, toHub).

Local Interface Port2
Mode Main
Pre-shared Key Enter the preshared key. The value must be identical to the
preshared key that you specified previously in the FortiGate_1
configuration.
Enable IPsec Interface Select Advanced to see this option. Enable the option to create a
Mode route-based VPN.

Name Enter a name for the tunnel (for example, toHub_ph2).

Phase 1 Select the name of the phase 1 configuration that you defined previously,
for example, toHub.
Advanced Select to show the following Quick Mode Selector settings.
Source Enter the address of the protected network at this spoke.
For spoke_1, this is 10.1.1.0/24.
Destination Enter the aggregate protected subnet address, 10.1.0.0/16.
Define the firewall policies

You need to define firewall addresses for the spokes and the aggregate protected network
and then create a firewall policy to enable communication between them.

01-420-99686-20101026 1023
To define the IP address of the network behind the spoke

Address Name Enter an address name (for example, LocalNet).

Subnet/IP Range Enter the IP address of the private network behind the spoke.
To specify the IP address of the aggregate protected network

Address Name Enter an address name (for example, Spoke_net).

Subnet/IP Range Enter the IP address of the aggregate protected network,
10.1.0.0/16.
To define the firewall policy

Source Interface/Zone Select the virtual IPsec interface, toHub.

Address Name Select the aggregate protected network address
Spoke_net
Destination Interface/Zone Select the interface to the internal (private) network, port1.
Address Name Select the address for this spoke’s protected network
LocalNet
Action ACCEPT
Source Interface/Zone Select the interface to the internal (private) network, port1.
Address Name Select the address for this spoke’s protected network, LocalNet
Destination Interface/Zone Select the virtual IPsec interface, toHub.
Address Name Select the aggregate protected network address, Spoke_net
Action ACCEPT
4 Place these policies in the policy list above any other policies having similar source
and destination addresses.

1024 01-420-99686-20101026
Dynamic DNS configurations
This section describes how to configure a site-to-site VPN, in which one FortiGate unit has
a static IP address and the other FortiGate unit has a static domain name and a dynamic
IP address.
• Configure the dynamically-addressed VPN peer
• Configure the fixed-address VPN peer
In this type of scenario, one of the FortiGate units in a gateway-to-gateway configuration
has a static domain name (for example, example.com) and a dynamic IP address. See
FortiGate_2 in Figure 118. Whenever that FortiGate unit connects to the Internet (and
possibly also at predefined intervals set by the ISP), the ISP may assign a different IP
address to the FortiGate unit. Therefore, remote peers have to locate the FortiGate unit
through DNS lookup.
Figure 118: Example dynamic DNS configuration
Site_1 Site_2
ver Sp
S ser ok
e_ _2
DN 1 oke
Sp
172.16.20.1 example.com
Dynamic DNS server
When a remote peer (such as FortiGate_1 in Figure 118) initiates a connection to the
domain name, a DNS server looks up and returns the IP address that matches the domain
name. The remote peer uses the retrieved IP address to establish a connection with the
FortiGate unit.

01-420-99686-20101026 1025
General configuration steps Dynamic DNS configurations
To ensure that DNS servers are able to discover the current IP address associated with a
FortiGate domain name, the FortiGate unit with the domain name subscribes to a dynamic
DNS service. A dynamic DNS service ensures that any changes to IP addresses are
propagated to all Internet DNS servers.
Whenever the FortiGate unit detects that its IP address has changed, it notifies the
dynamic DNS server and provides the new IP address to the server. The dynamic DNS
server makes the updated IP address available to all DNS servers and the new IP address
remains in effect until the FortiGate unit detects that its IP address has changed again.
A FortiGate unit that has static domain name and a dynamic IP address can initiate VPN
connections anytime—the remote peer replies to the FortiGate unit using the source IP
address that was sent in the packet header. However, changes to a dynamic IP address
must be resolved before a remote peer can establish a VPN connection to the domain
name—the remote peer must request a DNS lookup for the matching IP address before
initiating the connection.
Dynamic DNS infrastructure requirements

• A basic gateway-to-gateway configuration must be in place (see “Gateway-to-gateway
configurations” on page 997) except one of the FortiGate units has a static domain
name and a dynamic IP address instead of a static IP address.
• A DNS server must be available to VPN peers that initiate connections to the domain
name. For instructions about how to configure FortiGate units to look up the IP address
of a domain name, see the “System Network DNS” section of the FortiGate
• The FortiGate unit with the domain name must subscribe to one of the supported
dynamic DNS services. Contact one of the services to set up an account. For more
information and instructions about how to configure the FortiGate unit to push its
dynamic IP address to a dynamic DNS server, see the “System Network Interface”
section of the FortiGate Administration Guide.

When a FortiGate unit receives a connection request from a remote VPN peer, it uses
IPsec phase 1 parameters to establish a secure connection and authenticate the VPN
peer. Then, if the firewall policy permits the connection, the FortiGate unit establishes the
tunnel using IPsec phase 2 parameters and applies the firewall policy. Key management,
authentication, and security services are negotiated dynamically through the IKE protocol.
To support these functions, the following general configuration steps must be performed:
• Configure the FortiGate unit that has a domain name with a dynamic IP address. This
unit uses a Local ID string to identify itself to the remote peer. See “Configure the
dynamically-addressed VPN peer” on page 1027.
• Configure the fixed-address VPN peer. To initiate a VPN tunnel with the dynamically-
addressed peer, this unit must retrieve the IP address for the domain from the dynamic
DNS service. See “Configure the fixed-address VPN peer” on page 1029.

1026 01-420-99686-20101026
Dynamic DNS configurations Configure the dynamically-addressed VPN peer
Configure the dynamically-addressed VPN peer

Configure the FortiGate unit that has a domain name as follows:
1 Define the phase 1 parameters needed to establish a secure connection with the
remote peer. See “Auto Key phase 1 parameters” on page 1135. Select Advanced,
enter these settings and then select OK:
Name Enter a name to identify the VPN tunnel. This name appears in
phase 2 configurations, firewall policies and the VPN monitor.
IP Address Type the IP address of the public interface to the remote peer.
Mode Select Aggressive.
Enable IPsec Interface Enable for a route-based VPN.
Mode Disable for a policy-based VPN.
Local ID Type a character string that the local FortiGate unit can use to identify
itself to the remote peer (for example, you could type the fully qualified
domain name of the FortiGate unit, example.com). This value must
be identical to the value in the Accept this peer ID field of the phase 1
remote gateway configuration on the remote peer.

page 1157.
• Define an address name for the IP address and netmask of the private network
behind the local FortiGate unit.
behind the remote peer.
4 Define firewall policies to permit communications between the private networks
through the VPN tunnel. Route-based and policy-based VPNs require different firewall
policies. For detailed information about creating firewall policies, see “Defining firewall
policies” on page 1158.
Define ACCEPT firewall policies to permit communication between the private
networks. To define a policy to permit the local FortiGate unit to initiate communication,
enter these settings in particular:

01-420-99686-20101026 1027
Configure the dynamically-addressed VPN peer Dynamic DNS configurations
Source Interface/Zone Select the interface that connects to the private network
behind this FortiGate unit.
Step 1.
NAT Disable.
To permit the remote peer to initiate communication, you need to define a firewall
Source Interface/Zone Select the VPN Tunnel (IPsec Interface) that you configured
in Step 1.
Destination Interface/Zone Select the interface that connects to the private network
NAT Disable.

Define an IPsec policy to permit communication between the private networks. Enter
these settings in particular, and then select OK:
in Step 1.

1028 01-420-99686-20101026
Dynamic DNS configurations Configure the fixed-address VPN peer
Configure the fixed-address VPN peer

The fixed-address VPN peer needs to retrieve the IP address from the dynamic DNS
service to initiate communication with the dynamically-addressed peer that has domain
name. Configure the fixed-address peer as follows:
1 Define the phase 1 parameters needed to establish a secure connection with the
remote peer. For more information, see “Auto Key phase 1 parameters” on page 1135.
Select Advanced, enter these settings and then select OK:
Name Enter a name to identify the VPN tunnel. This name appears in phase 2
Remote Gateway Select Dynamic DNS.
Dynamic DNS Type the fully qualified domain name of the remote peer (for example,
example.com).
Mode Select Aggressive.
Peer Options Select Accept this peer ID, and type the identifier of the dynamically-
addressed FortiGate unit. This is the value you entered in the Local ID
field of the other unit’s phase 1 remote gateway configuration.
Enable IPsec Enable for a route-based VPN.
Interface Mode Disable for a policy-based VPN.

Phase 1 Select the name of the phase 1 configuration that you defined for the
remote peer. You can select the name of the remote gateway from the
Dynamic DNS part of the list.
VPN links. See “Defining firewall addresses” on page 1157. Enter these settings in
particular:
behind the local FortiGate unit.
behind the remote peer.
4 Define the firewall policies to permit communications between the source and
destination addresses. See “Defining firewall policies” on page 1158. Enter these
settings in particular and then select OK:

01-420-99686-20101026 1029
Configure the fixed-address VPN peer Dynamic DNS configurations
Step 1.
NAT Disable.
To permit the remote client to initiate communication, you need to define a firewall
Step 1.
NAT Disable.
in Step 1.

1030 01-420-99686-20101026
FortiClient dialup-client
configurations
The FortiClient Endpoint Security application is an IPsec VPN client with antivirus,
antispam and firewall capabilities. This section explains how to configure dialup VPN
connections between a FortiGate unit and one or more FortiClient Endpoint Security
applications.
FortiClient users are usually mobile or remote users who need to connect to a private
network behind a FortiGate unit. For example, the users might be employees who connect
to the office network while traveling or from their homes.
For greatest ease of use, the FortiClient application can download the VPN settings from
the FortiGate unit to configure itself automatically. This section covers both automatic and
manual configuration.
Note: The FortiClient configurations in this guide do not apply to the FortiClient Consumer
Edition, which does not include the IPsec VPN feature.

• FortiClient-to-FortiGate VPN configuration steps
• Configure the FortiGate unit
• Configure the FortiClient Endpoint Security application
• Adding XAuth authentication
• FortiClient dialup-client configuration example
Dialup users typically obtain dynamic IP addresses from an ISP through Dynamic Host
Configuration Protocol (DHCP) or Point-to-Point Protocol over Ethernet (PPPoE). Then,
the FortiClient Endpoint Security application initiates a connection to a FortiGate dialup
server.
By default the FortiClient dialup client has the same IP address as the host PC on which it
runs. If the host connects directly to the Internet, this is a public IP address. If the host is
behind a NAT device, such as a router, the IP address is a private IP address. The NAT
device must be NAT traversal (NAT-T) compatible to pass encrypted packets (see “NAT
traversal” on page 1147). The FortiClient application also can be configured to use a
virtual IP address (VIP). For the duration of the connection, the FortiClient application and
the FortiGate unit both use the VIP address as the IP address of the FortiClient dialup
client.
The FortiClient application sends its encrypted packets to the VPN remote gateway, which
is usually the public interface of the FortiGate unit. It also uses this interface to download
VPN settings from the FortiGate unit. See “Automatic configuration of FortiClient dialup
clients” on page 1032.

01-420-99686-20101026 1031
Configuration overview FortiClient dialup-client configurations
Figure 119: Example FortiClient dialup-client configuration
Dialup_1
1 Dialup_2
te_
r t iGa
Fo
Site_1 Dialup_3
Peer identification
The FortiClient application can establish an IPsec tunnel with a FortiGate unit configured
to act as a dialup server. When the FortiGate unit acts as a dialup server, it does not
identify the client using the phase 1 remote gateway address. The IPsec tunnel is
established if authentication is successful and the IPsec firewall policy associated with the
tunnel permits access. There are several different ways to authenticate dialup clients and
restrict access to private networks based on client credentials. For more information, see
“Authenticating remote peers and clients” on page 1139.
Automatic configuration of FortiClient dialup clients

The FortiClient application can obtain its VPN settings from the FortiGate VPN server.
FortiClient users need to know only the FortiGate VPN server IP address and their user
name and password on the FortiGate unit.
The FortiGate unit listens for VPN policy requests from clients on TCP port 8900. When
the dialup client connects:
• The client initiates a Secure Sockets Layer (SSL) connection to the FortiGate unit.
• The FortiGate unit requests a user name and password from the FortiClient user.
Using these credentials, it authenticates the client and determines which VPN policy
applies to the client.
• Provided that authentication is successful, the FortiGate unit downloads a VPN policy
to the client over the SSL connection. The information includes IPsec phase 1 and
phase 2 settings, and the IP addresses of the private networks that the client is
authorized to access.
• The client uses the VPN policy settings to establish an IPsec phase 1 connection and
phase 2 tunnel with the FortiGate unit.
How the FortiGate unit determines which settings to apply

The FortiGate unit follows these steps to determine the configuration information to send
to the FortiClient application:

1032 01-420-99686-20101026
FortiClient dialup-client configurations Configuration overview
1 Check the virtual domain associated with the connection to determine which VPN
policies might apply.
2 Select the VPN policy that matches the dialup client’s user group and determine which
tunnel (phase 1 configuration) is involved.
3 Check all IPsec firewall policies that use the specified tunnel to determine which
private network(s) the dialup clients may access.
4 Retrieve the rest of the VPN policy information from the existing IPsec phase 1 and
phase 2 parameters in the dialup-client configuration.
Using virtual IP addresses

When the FortiClient host PC is located behind a NAT device, unintended IP address
overlap issues may arise between the private networks at the two ends of the tunnel. For
example, the client’s host might receive a private IP address from a DHCP server on its
network that by co-incidence is the same as a private IP address on the network behind
the FortiGate unit. A conflict will occur in the host’s routing table and the FortiClient
Endpoint Security application will be unable to send traffic through the tunnel. Configuring
virtual IP (VIP) addresses for FortiClient applications prevents this problem.
Using VIPs ensures that client IP addresses are in a predictable range. You can then
define firewall policies that allow access only to that source address range. If you do not
use VIPs, the firewall policies must allow all source addresses because you cannot predict
the IP address for a remote mobile user.
The FortiClient application must not have the same IP address as any host on the private
network behind the FortiGate unit or any other connected FortiClient application. You can
ensure this by reserving a range of IP addresses on the private network for FortiClient
users. Or, you can assign FortiClient VIPs from an uncommonly used subnet such as
10.254.254.0/24 or 192.168.254.0/24.
You can reserve a VIP address for a particular client according to its device MAC address
and type of connection. The DHCP server then always assigns the reserved VIP address
to the client. For more information about this feature, see the “dhcp reserved-address”
section in the “system” chapter of the FortiGate CLI Reference.
Note: On the host computer, you can find out the VIP address that the FortiClient Endpoint
Security application is using. For example,
On Windows, type ipconfig /all at the Windows Command Prompt.
On Linux or Mac OS X, type ifconfig in a terminal window.
The output will also show the IP address that has been assigned to the host Network
Interface Card (NIC).
It is best to assign VIPs using DHCP over IPsec. The FortiGate dialup server can act as a
DHCP server or relay requests to an external DHCP server. You can also configure VIPs
manually on FortiClient applications, but it is more difficult to ensure that all clients use
unique addresses.
Note: If you assign a VIP on the private network behind the FortiGate unit and enable
DHCP-IPsec (a phase 2 advanced option), the FortiGate unit acts as a proxy on the local
private network for the FortiClient dialup client. Whenever a host on the network behind the
dialup server issues an ARP request for the device MAC address of the FortiClient host, the
FortiGate unit answers the ARP request on behalf of the FortiClient host and forwards the
associated traffic to the FortiClient host through the tunnel. For more information, see
“DHCP-IPsec” on page 1153.

01-420-99686-20101026 1033
Configuration overview FortiClient dialup-client configurations
Note: FortiGate units fully support RFC 3456. The FortiGate DHCP over IPsec feature can
be enabled to allocate VIP addresses to FortiClient dialup clients using a FortiGate DHCP
server.
Figure 120 shows an example of a FortiClient-to-FortiGate VPN where the FortiClient

application is assigned a VIP on an uncommonly used subnet. The diagram also shows
that while the destination for the information in the encrypted packets is the private
network behind the FortiGate unit, the destination of the IPsec packets themselves is the
public interface of the FortiGate unit that acts as the end of the VPN tunnel.
Figure 120: IP address assignments in a FortiClient dialup-client configuration
Traffic destination
10.11.101.2
Dialup client
3 1 3 1
2 2
VIP address
10.254.254.100
IPSec packets
Destination 172.20.120.141
IPSec packets
Destination 172.20.120.141
3 1
2
172.20.120.141
1 3
2 Fo
rtiG
ate
Traffic destination _1
10.11.101.2 10.11.101.2
Assigning VIPs by RADIUS user group

If you use XAuth authentication, you can assign users the virtual IP address stored in the
Framed-IP-Address field of their record on the RADIUS server. (See RFC 2865 and
RFC 2866 for more information about RADIUS fields.) To do this:
• Set the DHCP server IP Assignment Mode to User-group defined method. This is an
Advanced setting. See “To configure a DHCP server on the FortiGate unit” on
page 1038.
• Create a new firewall user group and add the RADIUS server to it.
• In your phase 1 settings, configure the FortiGate unit as an XAuth server and select
from User Group the new user group that you created. For more information, see
“Using the FortiGate unit as an XAuth server” on page 1148.
• Configure the FortiClient application to use XAuth. See “Adding XAuth authentication”
on page 1041.

1034 01-420-99686-20101026
FortiClient dialup-client configurations FortiClient-to-FortiGate VPN configuration steps
FortiClient dialup-client infrastructure requirements

• To support policy-based VPNs, the FortiGate dialup server may operate in either
NAT/Route mode or Transparent mode. NAT/Route mode is required if you want to
create a route-based VPN.
• If the FortiClient dialup clients will be configured to obtain VIP addresses through
FortiGate DHCP relay, a DHCP server must be available on the network behind the
FortiGate unit and the DHCP server must have a direct route to the FortiGate unit.
• If the FortiGate interface to the private network is not the default gateway, the private
network behind the FortiGate unit must be configured to route IP traffic destined for
dialup clients back (through an appropriate gateway) to the FortiGate interface to the
private network. As an alternative, you can configure the IPsec firewall policy on the
FortiGate unit to perform inbound NAT on IP packets. Inbound NAT translates the
source addresses of inbound decrypted packets into the IP address of the FortiGate
interface to the local private network.
FortiClient-to-FortiGate VPN configuration steps

Configuring dialup client capability for FortiClient dialup clients involves the following
general configuration steps:
1 If you will be using VIP addresses to identify dialup clients, determine which VIP
addresses to use. As a precaution, consider using VIP addresses that are not
commonly used.
2 Configure the FortiGate unit to act as a dialup server. See “Configure the FortiGate
unit” on page 1035.
3 If the dialup clients will be configured to obtain VIP addresses through DHCP over
IPsec, configure the FortiGate unit to act as a DHCP server or to relay DHCP requests
to an external DHCP server.
4 Configure the dialup clients. See “Configure the FortiClient Endpoint Security
application” on page 1040.
Note: When a FortiGate unit has been configured to accept connections from FortiClient
dialup-clients, you can optionally arrange to have an IPsec VPN configuration downloaded
to FortiClient dialup clients automatically. For more information, see “Configuring the
FortiGate unit as a VPN policy server” on page 1038.

Configuring the FortiGate unit to establish VPN connections with FortiClient Endpoint
Security users involves the following steps:
1 configure the VPN settings
2 if the dialup clients use automatic configuration, configure the FortiGate unit as a VPN
policy server
3 if the dialup clients obtain VIP addresses by DHCP over IPsec, configure an IPsec
DHCP server or relay
The procedures in this section cover basic setup of policy-based and route-based VPNs
compatible with FortiClient Endpoint Security. A route-based VPN is simpler to configure.

01-420-99686-20101026 1035
Configure the FortiGate unit FortiClient dialup-client configurations
Configuring FortiGate unit VPN settings

To configure FortiGate unit VPN settings to support FortiClient users, you need to:
• configure the FortiGate Phase 1 VPN settings
• configure the FortiGate Phase 2 VPN settings
• add the firewall policy
1 At the local FortiGate unit, define the phase 1 configuration needed to establish a
secure connection with the FortiClient peer. See “Auto Key phase 1 parameters” on
Remote Gateway Select Dialup User.
Local Interface Select the interface through which clients connect to the FortiGate
unit.
Mode Select Main (ID Protection).
Authentication Method Select Pre-shared Key.
Pre-shared Key Enter the pre-shared key. This must be the same preshared key
provided to the FortiClient users.
Peer option Select Accept any peer ID.
Enable IPsec Interface You must select Advanced to see this setting. If IPsec Interface
Mode Mode is enabled, the FortiGate unit creates a virtual IPsec
interface for a route-based VPN.
2 Define the phase 2 parameters needed to create a VPN tunnel with the FortiClient
peer. See “Phase 2 parameters” on page 1151. Enter these settings in particular:

Advanced Select to configure the following optional setting.
DHCP-IPsec Select if you provide virtual IP addresses to clients using DHCP.
page 1157.
• Define an address name for the individual address or the subnet address that the
dialup users access through the VPN.
• If FortiClient users are assigned VIP addresses, define an address name for the
subnet to which these VIPs belong.

1036 01-420-99686-20101026
FortiClient dialup-client configurations Configure the FortiGate unit
on page 1158.
Step 1.
NAT Disable.
If you want to allow hosts on the private network to initiate communications with the
FortiClient users after the tunnel is established, you need to define a firewall policy for
communication in that direction. Enter these settings in particular:
Step 1.
NAT Disable.

Destination Address Name If FortiClient users are assigned VIPs, select the address
name that you defined in Step 3 for the VIP subnet.
Otherwise, select All.
in Step 1.
Select Allow outbound if you want to allow hosts on the private
network to initiate communications with the FortiClient users
after the tunnel is established.
5 Place VPN policies in the policy list above any other policies having similar source and

01-420-99686-20101026 1037
Configure the FortiGate unit FortiClient dialup-client configurations
Configuring the FortiGate unit as a VPN policy server

When a FortiClient application set to automatic configuration connects to the FortiGate
unit, the FortiGate unit requests a user name and password. If the user supplies valid
credentials, the FortiGate unit downloads the VPN settings to the FortiClient application.
You must do the following to configure the FortiGate unit to work as a VPN policy server
for FortiClient automatic configuration:
1 Create user accounts for FortiClient users.
2 Create a user group for FortiClient users and the user accounts that you created in
step 1.
3 Connect to the FortiGate unit CLI and configure VPN policy distribution as follows:
config vpn ipsec forticlient
edit <policy_name>
set phase2name <tunnel_name>
set usergroupname <group_name>
set status enable
end
<tunnel_name> must be the Name you specified in the step 2 of “Configure the
FortiGate unit” on page 1035. <group_name> must be the name of the user group
your created for FortiClient users.
Configuring DHCP service on the FortiGate unit

If the FortiClient dialup clients are configured to obtain a VIP address using DHCP,
configure the FortiGate dialup server to either:
• relay DHCP requests to a DHCP server behind the FortiGate unit (see “To configure
DHCP relay on the FortiGate unit” below).
• act as a DHCP server (see “To configure a DHCP server on the FortiGate unit” on
page 1038).
To configure DHCP relay on the FortiGate unit

1 Go to System > DHCP Server > Service and select Create New.
2 In Interface Name, select the interface that connects to the Internet (for example,
external or wan1).
3 In Mode, select Relay.
4 In Type select IPsec.
5 In the DHCP Server IP field, type the IP address of the DHCP server.
6 Select OK.
7 If a router is installed between the FortiGate unit and the DHCP server, define a static
route to the DHCP server.
To configure a DHCP server on the FortiGate unit

2 In Interface Name, select the interface that connects to the Internet (for example,
external or wan1).
3 In Mode, select Server.
4 Select Enable.

1038 01-420-99686-20101026
FortiClient dialup-client configurations Configure the FortiGate unit
Type IPsec
IP Range Enter the range of VIP addresses that the DHCP server can
dynamically assign to dialup clients when they connect. As a
precaution, do not assign VIP addresses that match the private
network behind the FortiGate unit.
If you need to exclude specific IP addresses from the range, you can
define an exclusion range (see Advanced... below).
Note: If you will use a RADIUS server to assign VIP addresses, these
fields are not needed.
Network Mask Enter the network mask of the IP addresses that you specified in the IP
Range fields (for example, 255.255.255.0 for a class C network).
Default Gateway Enter the IP address of the default gateway that the DHCP server
assigns to DHCP clients.
DNS Service Select Use System DNS Setting.
If you want to use a different DNS server for VPN clients, select
Specify and enter an IP address in DNS Server 0.
Advanced... Select Advanced to configure any of the following options.
Domain If you want the FortiGate unit to assign a domain name to dialup clients
when they connect, enter the registered domain name.
Lease Time Specify a lease time:
• Select Unlimited to allow the dialup client to use the assigned IP
address for an unlimited amount of time (that is, until the client
disconnects).
• Enter the amount of time (in days, hours, and minutes) that the
dialup client may use the assigned IP address, after which the
dialup client must request new settings from the DHCP server. The
range is from 5 minutes to 100 days.
IP Assignment Mode Server IP Range — assign addresses from IP Range (default)
User-group defined method — assign addresses from user’s record on
RADIUS server. See “Assigning VIPs by RADIUS user group” on
page 1034.
WINS Server 0 Optionally, enter the IP addresses of one or two Windows Internet
WINS Server 1 Service (WINS) servers that dialup clients can access after the tunnel
has been established.
Options Optionally, you can send up to three DHCP options to the dialup client.
Select Options and enter the option code in the Code field, and if
applicable, type any associated data in the Options field. For more
information, see RFC 2132.
Exclude Ranges To specify any VIP addresses that must be excluded from the VIP
address range, select Exclude Ranges, select the + button and then
type the starting and ending IP addresses. You can add multiple
ranges to exclude.

01-420-99686-20101026 1039
Configure the FortiClient Endpoint Security application FortiClient dialup-client configurations
Configure the FortiClient Endpoint Security application

The following procedure explains how to configure the FortiClient Endpoint Security
application to communicate with a remote FortiGate dialup server using the VIP address
that you specify manually.
Configuring FortiClient to work with VPN policy distribution

If the remote FortiGate gateway is configured as a VPN policy server, you can configure
the FortiClient software to download the VPN settings from the FortiGate gateway.
Note: For VPNs with automatic configuration, only preshared keys are supported.
Certificates are not supported.
To add a VPN with automatic configuration on the FortiClient PC

2 Select Advanced and then select Add.
3 In the New Connection dialog box, enter a connection name.
4 For Configuration, select Automatic.
5 For Policy Server, enter the IP address or FQDN of the FortiGate gateway.
6 Select OK.
Configuring FortiClient manually

This procedure explains how to configure the FortiClient application manually using the
default IKE and IPsec settings. For more information, refer to the FortiClient Endpoint
Security User Guide.
This procedure includes instructions for configuring a virtual IP for the FortiClient
application, either manually or using DHCP over IPsec.
To create a FortiClient VPN configuration

2 Select Advanced and then select Add.
Connection Name Enter a descriptive name for the connection.

Configuration Select Manual
Remote Gateway Enter the IP address or the fully qualified domain name (FQDN)
of the remote gateway.
Remote Network Enter the IP address and netmask of the network behind the
FortiGate unit.
Pre-shared Key Enter the pre-shared key.
4 Follow the remaining steps only if you want to configure a VIP. Otherwise, select OK.
5 Select Advanced.
6 Enable Acquire a virtual IP address and then select the adjacent Config button.

1040 01-420-99686-20101026
FortiClient dialup-client configurations Adding XAuth authentication
Options Select one of these options:

DHCP Obtain virtual IP address from the FortiGate unit using DHCP over
IPsec.
Manually Set Assign the virtual IP address manually using the settings in the
Manual VIP section.
Manual VIP These settings are available only if you select Manually Set in the
Options section.
IP Enter the IP address that the FortiClient dialup client uses. This
address must not conflict with any IP address at either end of the VPN
tunnel.
Subnet Mask Enter the subnet for the private network.
DNS Server Optionally, enter the addresses of the DNS and WINS servers that the
WINS Server FortiClient user can access through the VPN.
8 Select OK twice to close the dialog boxes.

9 Repeat this procedure for each FortiClient dialup client.
Adding XAuth authentication

Extended Authentication (XAuth) increases security by requiring additional user
authentication in a separate exchange at the end of the VPN phase 1 negotiation. The
FortiGate unit challenges the user for a user name and password. It then forwards the
user’s credentials to an external RADIUS or LDAP server for verification.
Implementation of XAuth requires configuration at both the FortiGate unit and the
FortiClient application. For information about configuring a FortiGate unit as an XAuth
server, see “Using the FortiGate unit as an XAuth server” on page 1148. The following
procedure explains how to configure the FortiClient application.
Note: XAuth is not compatible with IKE version 2.
To configure the FortiClient Endpoint Security application

In the FortiClient Endpoint Security application, make the following changes to the VPN
configuration to enable XAuth authentication to the FortiGate unit.
1 Go to VPN > Connections, select the VPN connection you want to modify, and then
select Advanced > Edit.
2 Select Advanced.
3 Select the eXtended Authentication check box and then select the Config button to the
right of it.
4 In the Extended Authentication (XAuth) dialog box, either:
• Select Prompt to login. The FortiClient Endpoint Security application prompts the
user for a user name and password when it receives the XAuth challenge. This is
the default.
• Clear the Prompt to login check box and fill in the User Name and Password fields.
The FortiClient Endpoint Security application automatically responds to the XAuth
challenge with these values.
5 Select OK to close all dialog boxes.

01-420-99686-20101026 1041
FortiClient dialup-client configuration example FortiClient dialup-client configurations
FortiClient dialup-client configuration example

This example demonstrates how to set up a FortiClient dialup-client IPsec VPN that uses
preshared keys for authentication purposes. In the example configuration, the DHCP over
IPsec feature is enabled in the FortiClient Endpoint Security application so that the
FortiClient Endpoint Security application can acquire a VIP address through FortiGate
DHCP server. Both route-based and policy-based solutions are covered.
Figure 121: Example FortiClient dialup-client configuration
Dialup_1
VIP address
10.254.254.1
1
te_ Po
r t iGa 17 rt 1 Dialup_2
Fo 2.2
LAN 0.1
20.1
10.11.101.0/24 41
Po VIP address
rt 2
10.254.254.2
In the example configuration:

• VIP addresses that are not commonly used (in this case, 10.254.254.0/24) are
assigned to the FortiClient dialup clients using a DHCP server.
• The dialup clients are provided access to the LAN behind FortiGate_1.
• The other network devices are assigned IP addresses as shown in Figure 121.
Configuring FortiGate_1
When a FortiGate unit receives a connection request from a dialup client, it uses IPsec
phase 1 parameters to establish a secure connection and authenticate the client. Then, if
the firewall policy permits the connection, the FortiGate unit establishes the tunnel using
IPsec phase 2 parameters and applies the IPsec firewall policy. Key management,
authentication, and security services are negotiated dynamically through the IKE protocol.
To support these functions, the following general configuration steps must be performed at
the FortiGate unit:
• Define the phase 1 parameters that the FortiGate unit needs to authenticate the dialup
clients and establish a secure connection. See “To define the phase 1 parameters” on
page 1043.
• Define the phase 2 parameters that the FortiGate unit needs to create a VPN tunnel
and enable all dialup clients having VIP addresses on the 10.254.254.0/24 network to
connect using the same tunnel definition. See “To define the phase 2 parameters” on
page 1043.

1042 01-420-99686-20101026
FortiClient dialup-client configurations FortiClient dialup-client configuration example
• Create firewall policy to control the permitted services and permitted direction of traffic
between the IP source address and the dialup clients. See “To define the firewall
addresses” on page 1043.
• Configure the FortiGate unit to service DHCP requests from dialup clients. See “To
configure a DHCP server on the FortiGate unit” on page 1045.

Name todialups
Remote Gateway Dialup User
Mode Main
Pre-shared Key hardtoguess
Advanced Select
Enable IPsec Interface Mode Enable for route-based VPN.
Disable for policy-based VPN.

1 Go to VPN > IPSEC > Auto Key and select Create Phase 2.
2 Select Advanced, enter the following information, and select OK:
Name td_2
Phase 1 todialups
Advanced DHCP-IPsec
To define the firewall addresses

Address Name internal_net

Subnet/IP Range 10.11.101.0/24
Interface Port 2
Address Name dialups

Subnet/IP Range 10.254.254.[1-10]
Interface Route-based VPN: todialups
Policy-based VPN: Any
The firewall policies for route-based and policy-based VPNs are described in separate
sections below.

01-420-99686-20101026 1043
To define firewall policies - route-based VPN

Source Interface/Zone todialups

Source Address Name dialups
Destination Address Name internal_net
Action ACCEPT
NAT Disable

Source Address Name internal_net
Destination Interface/Zone todialups
Destination Address Name dialups
Action ACCEPT
NAT Disable
To define the firewall policy - policy-based VPN


Source Address Name internal_net
Destination Address Name dialups
Action IPSEC
VPN Tunnel todialups.
Allow Outbound Enable if you want to allow hosts on the private network
behind the FortiGate unit to initiate communications with the
FortiClient users after the tunnel is established.
Inbound NAT Disable
Outbound NAT Disable

1044 01-420-99686-20101026
FortiClient dialup-client configurations FortiClient dialup-client configuration example
To configure a DHCP server on the FortiGate unit

Interface Name Route-based VPN: select virtual IPsec interface. For example, todialups.
Policy-based VPN: select the public interface. For example, Port 1.
Mode Server
Type IPSEC.
IP Range 10.254.254.1 - 10.254.254.10
Network Mask 255.255.255.0
Default Gateway 172.20.120.2
Configuring the FortiClient Endpoint Security application

The following procedure explains how to configure the FortiClient Endpoint Security
application to connect to FortiGate_1 and broadcast a DHCP request. The dialup client
uses the VIP address acquired through FortiGate DHCP relay as its IP source address for
the duration of the connection.
To configure FortiClient
1 At the remote host, start FortiClient.
2 Go to VPN > Connections and select Advanced > Add.
Connection Name Office

VPN Type Manual IPsec
Remote Gateway 172.20.120.141
Remote Network 10.11.101.0 / 255.255.255.0
Preshared Key hardtoguess
4 Select Advanced.
5 In the Advanced Settings dialog box, select Acquire virtual IP address and then select
Config.
6 Verify that the Dynamic Host Configuration Protocol (DHCP) over IPsec option is
selected, and then select OK.
8 Exit FortiClient and repeat this procedure at all other remote hosts.

01-420-99686-20101026 1045

1046 01-420-99686-20101026
FortiGate dialup-client configurations
This section explains how to set up a FortiGate dialup-client IPsec VPN. In a FortiGate
dialup-client configuration, a FortiGate unit with a static IP address acts as a dialup server
and a FortiGate unit having a dynamic IP address initiates a VPN tunnel with the FortiGate
dialup server.
• FortiGate dialup-client configuration steps
• Configure the server to accept FortiGate dialup-client connections
• Configure the FortiGate dialup client
A dialup client can be a FortiGate unit—the FortiGate dialup client typically obtains a
dynamic IP address from an ISP through the Dynamic Host Configuration Protocol
(DHCP) or Point-to-Point Protocol over Ethernet (PPPoE) before initiating a connection to
a FortiGate dialup server.
Figure 122: Example FortiGate dialup-client configuration
1 FG
te_ _D
r t iGa ialu
Fo p
Site_1
Site_2
In a dialup-client configuration, the FortiGate dialup server does not rely on a phase 1
remote gateway address to establish an IPsec VPN connection with dialup clients. As long
as authentication is successful and the IPsec firewall policy associated with the tunnel
permits access, the tunnel is established.
Several different ways to authenticate dialup clients and restrict access to private
networks based on client credentials are available. To authenticate FortiGate dialup clients
and help to distinguish them from FortiClient dialup clients when multiple clients will be
connecting to the VPN through the same tunnel, we recommend that you assign a unique
identifier (local ID) to each FortiGate dialup client. For more information, see
“Authenticating remote peers and clients” on page 1139.

01-420-99686-20101026 1047
Configuration overview FortiGate dialup-client configurations
Note: Whenever you add a unique identifier (local ID) to a FortiGate dialup client for
identification purposes, you must select Aggressive mode on the FortiGate dialup server
and also specify the identifier as a peer ID on the FortiGate dialup server. For more
information, see “Enabling VPN access using user accounts and pre-shared keys” on
page 1143.
Users behind the FortiGate dialup server cannot initiate the tunnel because the FortiGate
dialup client does not have a static IP address. After the tunnel is initiated by users behind
the FortiGate dialup client, traffic from the private network behind the FortiGate dialup
server can be sent to the private network behind the FortiGate dialup client.
Encrypted packets from the FortiGate dialup client are addressed to the public interface of
the dialup server. Encrypted packets from the dialup server are addressed either to the
public IP address of the FortiGate dialup client (if the dialup client connects to the Internet
directly), or if the FortiGate dialup client is behind a NAT device, encrypted packets from
the dialup server are addressed to the public IP address of the NAT device.
Note: If a router with NAT capabilities is in front of the FortiGate dialup client, the router
must be NAT-T compatible for encrypted traffic to pass through the NAT device. For more
information, see “NAT traversal” on page 1147.
When the FortiGate dialup server decrypts a packet from the FortiGate dialup client, the
source address in the IP header may be one of the following values, depending on the
configuration of the network at the far end of the tunnel:
• If the FortiGate dialup client connects to the Internet directly, the source address will be
the private IP address of a host or server on the network behind the FortiGate dialup
client.
• If the FortiGate dialup client is behind a NAT device, the source address will be the
public IP address of the NAT device.
In some cases, computers on the private network behind the FortiGate dialup client may
(by co-incidence) have IP addresses that are already used by computers on the network
behind the FortiGate dialup server. In this type of situation (ambiguous routing), conflicts
may occur in one or both of the FortiGate routing tables and traffic destined for the remote
network through the tunnel may not be sent.
In many cases, computers on the private network behind the FortiGate dialup client will
most likely obtain IP addresses from a local DHCP server behind the FortiGate dialup
client. However, unless the local and remote networks use different private network
address spaces, unintended ambiguous routing and/or IP-address overlap issues may
arise.
To avoid these issues, you can configure FortiGate DHCP relay on the dialup client
instead of using a DHCP server on the network behind the dialup client. The FortiGate
dialup client can be configured to relay DHCP requests from the local private network to a
DHCP server that resides on the network behind the FortiGate dialup server (see
Figure 123 on page 1049). You configure the FortiGate dialup client to pass traffic from the
local private network to the remote network by enabling FortiGate DHCP relay on the
FortiGate dialup client interface that is connected to the local private network.

1048 01-420-99686-20101026
FortiGate dialup-client configurations Configuration overview
Figure 123: Preventing network overlap in a FortiGate dialup-client configuration
1 FG
te_ _D
r t iGa ialu
Fo p
Site_1 DHCP discovery

message initiates
tunnel
CP
DH er Site_2
r v
se
Afterward, when a computer on the network behind the dialup client broadcasts a DHCP
request, the dialup client relays the message through the tunnel to the remote DHCP
server. The remote DHCP server responds with a private IP address for the computer. To
avoid ambiguous routing and network overlap issues, the IP addresses assigned to
computers behind the dialup client cannot match the network address space used by the
private network behind the FortiGate dialup server.
When the DHCP server resides on the private network behind the FortiGate dialup server
as shown in Figure 123, the IP destination address specified in the IPsec firewall policy on
the FortiGate dialup client must refer to that network.
Note: If the DHCP server is not directly connected to the private network behind the
FortiGate dialup server (that is, its IP address does not match the IP address of the private
network), you must add (to the FortiGate dialup client’s routing table) a static route to the
DHCP server, and the IP destination address specified in the IPsec firewall policy on the
FortiGate dialup client must refer to the DHCP server address. In this case, the DHCP
server must be configured to assign IP addresses that do not belong to the network on
which the DHCP server resides. In addition, the IP addresses cannot match the network
address space used by the private network behind the FortiGate dialup server.
FortiGate dialup-client infrastructure requirements

• To support a policy-based VPN, the FortiGate dialup server may operate in either
NAT/Route mode or Transparent mode. NAT/Route mode is required if you want to
create a route-based VPN.
• The FortiGate dialup server has a static public IP address.
• Computers on the private network behind the FortiGate dialup client can obtain IP
addresses either from a DHCP server behind the FortiGate dialup client, or a DHCP
server behind the FortiGate dialup server.
• If the DHCP server resides on the network behind the dialup client, the DHCP
server must be configured to assign IP addresses that do not match the private
network behind the FortiGate dialup server.
• If the DHCP server resides on the network behind the FortiGate dialup server, the
DHCP server must be configured to assign IP addresses that do not match the
private network behind the FortiGate dialup client. In addition, the FortiGate dialup
client routing table must contain a static route to the DHCP server (see the “Router
Static” chapter of the FortiGate Administration Guide).

01-420-99686-20101026 1049
FortiGate dialup-client configuration steps FortiGate dialup-client configurations
FortiGate dialup-client configuration steps

The procedures in this section assume that computers on the private network behind the
FortiGate dialup client obtain IP addresses from a local DHCP server. The assigned IP
addresses do not match the private network behind the FortiGate dialup server.
Note: In situations where IP-address overlap between the local and remote private
networks is likely to occur, FortiGate DHCP relay can be configured on the FortiGate dialup
client to relay DHCP requests to a DHCP server behind the FortiGate dialup server. For
more information, see “To configure DHCP relay on the FortiGate unit” on page 1038.
Configuring dialup client capability for FortiGate dialup clients involves the following
general configuration steps:
• Determine which IP addresses to assign to the private network behind the FortiGate
dialup client, and add the IP addresses to the DHCP server behind the FortiGate dialup
client. Refer to the software supplier’s documentation to configure the DHCP server.
• Configure the FortiGate dialup server. See “Configure the server to accept FortiGate
dialup-client connections” on page 1050.
• Configure the FortiGate dialup client. See “Configure the FortiGate dialup client” on
page 1052.
Configure the server to accept FortiGate dialup-client connections

Before you begin, optionally reserve a unique identifier (peer ID) for the FortiGate dialup
client. The dialup client will supply this value to the FortiGate dialup server for
authentication purposes during the IPsec phase 1 exchange. In addition, the value will
enable you to distinguish FortiGate dialup-client connections from FortiClient dialup-client
connections. The same value must be specified on the dialup server and on the dialup
client.
1 At the FortiGate dialup server, define the phase 1 parameters needed to authenticate
the FortiGate dialup client and establish a secure connection. See “Auto Key phase 1
Name Enter a name to identify the VPN tunnel. This name appears in phase
2 configurations, firewall policies and the VPN monitor.
Remote Gateway Select Dialup User.
Local Interface Select the interface through which clients connect to the FortiGate
unit.
Mode If you will be assigning an ID to the FortiGate dialup client, select
Aggressive.
Peer Options If you will be assigning an ID to the FortiGate dialup client, select
Accept this peer ID and type the identifier that you reserved for the
FortiGate dialup client into the adjacent field.
Enable IPsec Interface You must select Advanced to see this setting. If IPsec Interface Mode
Mode is enabled, the FortiGate unit creates a virtual IPsec interface for a
route-based VPN. Disable this option if you want to create a policy-
based VPN.
After you select OK to create the phase 1 configuration, you cannot
change this setting.
2 Define the phase 2 parameters needed to create a VPN tunnel with the FortiGate
dialup client. See “Phase 2 parameters” on page 1151. Enter these settings in
particular:

1050 01-420-99686-20101026
FortiGate dialup-client configurations Configure the server to accept FortiGate dialup-client connections

particular:
• Define an address name for the server, host, or network behind the FortiGate dialup
server.
• Define an address name for the private network behind the FortiGate dialup client.
4 Define the firewall policies to permit communications between the private networks
through the VPN tunnel. Route-based and policy-based VPNs require different firewall
policies. For detailed information about creating firewall policies, see “Defining firewall
policies” on page 1158.
Define an ACCEPT firewall policy to permit communications between hosts on the
private network behind the FortiGate dialup client and the private network behind this
FortiGate dialup server. Because communication cannot be initiated in the opposite
direction, there is only one policy. Enter these settings in particular:
Source Interface/Zone Select the VPN tunnel (IPsec interface) created in Step 1.
NAT Disable

Define an IPsec firewall policy. Enter these settings in particular:
Destination Address Name Select the address name that you defined in Step 3.
in Step 1.
Clear Allow outbound to prevent traffic from the local network
from initiating the tunnel after the tunnel has been established.

01-420-99686-20101026 1051
Configure the FortiGate dialup client FortiGate dialup-client configurations
Configure the FortiGate dialup client

Configure the FortiGate dialup client as follows:
1 At the FortiGate dialup client, define the phase 1 parameters needed to authenticate
the dialup server and establish a secure connection. See “Auto Key phase 1
IP Address Type the IP address of the dialup server’s public interface.
Local Interface Select the interface that connects to the public network.
Mode Because the FortiGate dialup client has a dynamic IP address,
select Aggressive.
Advanced Select to view the following options.
Local ID If you defined a peer ID for the dialup client in the FortiGate dialup
server configuration, enter the identifier of the dialup client. The
value must be identical to the peer ID that you specified previously
in the FortiGate dialup server configuration.
Enable IPsec If IPsec Interface Mode is enabled, the FortiGate unit creates a
Interface Mode virtual IPsec interface for a route-based VPN. Disable this option if
you want to create a policy-based VPN.
After you select OK to create the phase 1 configuration, you
cannot change this setting.
2 Define the phase 2 parameters needed to create a VPN tunnel with the dialup server.

Phase 1 Select the set of phase 1 parameters that you defined in step 1.
particular:
• Define an address name for the server, host, or network behind the FortiGate dialup
server.
• Define an address name for the private network behind the FortiGate dialup client.
on page 1158.
Define an ACCEPT firewall policy to permit communications between hosts on the
private network behind this FortiGate dialup client and the private network behind the
FortiGate dialup server. Because communication cannot be initiated in the opposite
direction, there is only one policy. Enter these settings in particular:
Destination Interface/Zone Select the VPN tunnel (IPsec interface) created in Step 1.

1052 01-420-99686-20101026
FortiGate dialup-client configurations Configure the FortiGate dialup client

NAT Disable
private network behind the dialup server.
VPN Tunnel Select the name of the phase 1 configuration that you created in
Step 1.
Clear Allow inbound to prevent traffic from the remote network
from initiating the tunnel after the tunnel has been established.

01-420-99686-20101026 1053
Configure the FortiGate dialup client FortiGate dialup-client configurations

1054 01-420-99686-20101026
Supporting IKE Mode config clients
IKE Mode Config is an alternative to DHCP over IPsec. A FortiGate unit can be configured
as either an IKE Mode Config server or client. This chapter contains the following sections:
• Automatic configuration overview
• IKE Mode Config overview
• Configuring IKE Mode Config
• Example: FortiGate unit as IKE Mode Config server
• Example: FortiGate unit as IKE Mode Config client
Automatic configuration overview

VPN configuration for remote clients is simpler if it is automated. Several protocols support
automatic configuration:
• The Fortinet FortiClient Endpoint Security application can completely configure a VPN
connection with a suitably configured FortiGate unit given only the FortiGate unit’s
address. This protocol is exclusive to Fortinet. For more information, see the
“FortiClient dialup-client configurations” chapter.
• DHCP over IPsec can assign an IP address, Domain, DNS and WINS addresses. The
user must first configure IPsec parameters such as gateway address, encryption and
authentication algorithms.
• IKE Mode Config can configure host IP address, Domain, DNS and WINS addresses.
The user must first configure IPsec parameters such as gateway address, encryption
and authentication algorithms. Several network equipment vendors support IKE Mode
Config, which is described in the ISAKMP Configuration Method document draft-
dukes-ike-mode-cfg-02.txt.
This chapter describes how to configure a FortiGate unit as either an IKE Mode Config
server or client.
IKE Mode Config overview

Dialup VPN clients connect to a FortiGate unit that acts as a VPN server, providing the
client the necessary configuration information to establish a VPN tunnel. The configuration
information typically includes a virtual IP address, netmask, and DNS server address.
IKE Mode Config is available only for VPNs that are route-based, also known as
interface-based. A FortiGate unit can function as either an IKE Configuration Method
server or client. IKE Mode Config is configurable only in the CLI.
Configuring IKE Mode Config

IKE Mode Config is configured with the CLI command vpn ipsec phase1-interface.
The mode-cfg variable enables IKE Mode Config. The type field determines whether
you are creating an IKE Mode Config server or a client. Setting type to dynamic
creates a server configuration, otherwise the configuration is a client.

01-420-99686-20101026 1055
Configuring IKE Mode Config Supporting IKE Mode config clients
Configuring an IKE Mode Config client

If the FortiGate unit will connect as a dialup client to a remote gateway that supports IKE
Mode Config, the relevant vpn ipsec phase1-interface variables are as follows:
ike-version 1 IKE v1 is the default for FortiGate IPsec VPNs.
IKE Mode Config is not compatible with IKE v2.
mode-cfg enable Enable IKE Mode Config.
type {ddns | static} Set to ddns or static as needed. If you set type to
dynamic, an IKE Mode Config server is created.
assign-ip Enable to request an IP address from the server.
{enable | disable}
interface This is a regular IPsec VPN field. Specify the physical,
<interface_name> aggregate, or VLAN interface to which the IPsec tunnel will be
bound.
proposal This is a regular IPsec VPN field that determines the
<encryption_combination> encryption and authentication settings that the client will
accept. For more information, see “Defining IKE negotiation
mode-cfg-ip-version {4|6} Select whether an IKE Configuration Method client receives an
IPv4 or IPv6 IP address. The default is 4. This setting should
match the ip-version setting.
ip-version <4 | 6> This is a regular IPsec VPN field. By default, IPsec VPNs use
IPv4 addressing. You can set ip-version to 6 to create a
VPN with IPv6 addressing.
Configuring an IKE Mode Config server

If the FortiGate unit will accept connection requests from dialup clients that support IKE
Mode Config, the following vpn ipsec phase1-interface settings are required
before any other configuration is attempted:
ike-version 1 IKE v1 is the default for FortiGate IPsec VPNs.
IKE Mode Config is not compatible with IKE v2.
mode-cfg enable Enable IKE Mode Config.
type dynamic Any other setting creates an IKE Mode Config client.
interface This is a regular IPsec VPN field. Specify the physical,
<interface_name> aggregate, or VLAN interface to which the IPsec tunnel will be
bound.
proposal This is a regular IPsec VPN field that determines the
<encryption_combination> encryption and authentication settings that the server will
accept. For more information, see “Defining IKE negotiation
ip-version <4 | 6> This is a regular IPsec VPN field. By default, IPsec VPNs use
IPv4 addressing. You can set ip-version to 6 to create a
VPN with IPv6 addressing.
After you have enabled the basic configuration, you can configure:
• IP address assignment for clients
• DNS and WINS server assignment

1056 01-420-99686-20101026
Supporting IKE Mode config clients Example: FortiGate unit as IKE Mode Config server
IP address assignment
Usually you will want to assign IP addresses to clients. The simplest method is to assign
addresses from a specific range, similar to a DHCP server.
If your clients are authenticated by a RADIUS server, you can obtain the user’s IP address
assignment from the Framed-IP-Address attribute. The user must be authenticated using
XAuth.
To assign IP addresses from an address range

If your VPN uses IPv4 addresses,
edit vpn1
set mode-cfg-ipversion 4
set assign-ip enable
set assign-ip-type ip
set assign-ip-from range
set ipv4-start-ip <range_start>
set ipv4-end-ip <range_end>
set ipv4-netmask <netmask>
end
If your VPN uses IPv6 addresses,
edit vpn1
set ipv6-start-ip <range_start>
set ipv6-end-ip <range_end>
end
To assign IP addresses from a RADIUS server

The users must be authenticated by a RADIUS server and assigned to the FortiGate user
group <grpname>.
edit vpn1
set assign-ip-from usrgrp
set xauthtype auto
set authusrgrp <grpname>
end
Example: FortiGate unit as IKE Mode Config server

In this example, the FortiGate unit assigns IKE Mode Config clients addresses in the
range of 10.11.101.160 through 10.11.101.180. DNS and WINS server addresses are also
provided. The public interface of the FortiGate unit is Port 1.
The ipv4-split-include variable specifies a firewall address that represents the
networks to which the clients will have access. This destination IP address information is
sent to the clients.

01-420-99686-20101026 1057
Example: FortiGate unit as IKE Mode Config client Supporting IKE Mode config clients
Only the CLI fields required for IKE Mode Config are shown here. For detailed information
about these variables, see the FortiGate CLI Reference.
edit vpn1
set ip-version 4
set type dynamic
set interface port1
set mode-cfg enable
set ipv4-start-ip 10.11.101.160
set ipv4-end-ip 10.11.101.180
set ipv4-netmask 255.255.255.0
set dns-server1 10.11.101.199
set dns-server2 66.11.168.195
set wins-server1 10.11.101.191
set domain example
set ipv4-split-include OfficeLAN
end
Example: FortiGate unit as IKE Mode Config client

In this example, the FortiGate unit connects to a VPN gateway with a static IP address that
can be reached through Port 1. Only the port, gateway and proposal information needs to
be configured. All other configuration information will come from the IKE Mode Config
server.
edit vpn1
set ip-version 4
set type static
set remote-gw <gw_address>
set interface port 1
set mode-cfg enable
end

1058 01-420-99686-20101026
Internet-browsing configuration
This section explains how to support secure web browsing performed by dialup VPN
clients, and/or hosts behind a remote VPN peer. Remote users can access the private
network behind the local FortiGate unit and browse the Internet securely. All traffic
generated remotely is subject to the firewall policy that controls traffic on the private
network behind the local FortiGate unit.
• Creating an Internet browsing firewall policy
• Routing all remote traffic through the VPN tunnel
A VPN provides secure access to a private network behind the FortiGate unit. You can
also enable VPN clients to access the Internet securely. The FortiGate unit inspects and
processes all traffic between the VPN clients and hosts on the Internet according to the
Internet browsing policy. This is accomplished even though the same FortiGate interface
is used for both encrypted VPN client traffic and unencrypted Internet traffic.
In Figure 124, FortiGate_1 enables secure Internet browsing for FortiClient Endpoint
Security users such as Dialup_1 and users on the Site_2 network behind FortiGate_2,
which could be a VPN peer or a dialup client.
Figure 124: Example Internet-browsing configuration
_1
lup
Dia
FG
_D
_1 ial
ate up
_2
rtiG
Fo
Site_1 Site_2
We
bs
U
Users browse erv
internet through er
the VPN tunnel
You can adapt any of the following configurations to provide secure Internet browsing:
• a gateway-to-gateway configuration (see “Gateway-to-gateway configurations” on
page 997)
• a FortiClient dialup-client configuration (see “FortiClient dialup-client configurations” on
page 1031)

01-420-99686-20101026 1059
Creating an Internet browsing firewall policy Internet-browsing configuration
• a FortiGate dialup-client configuration (see “FortiGate dialup-client configurations” on

page 1047)
The procedures in this section assume that one of these configurations is in place, and
that it is operating properly.
To create an internet-browsing configuration based on an existing gateway-to-gateway
configuration, you must edit the gateway-to-gateway configuration as follows:
• On the FortiGate unit that will provide Internet access, create an Internet browsing
firewall policy. See “Creating an Internet browsing firewall policy”, below.
• Configure the remote peer or client to route all traffic through the VPN tunnel. You can
do this on a FortiGate unit or on a FortiClient Endpoint Security application. See
“Routing all remote traffic through the VPN tunnel” on page 1061.
Creating an Internet browsing firewall policy

On the FortiGate unit that acts as a VPN server and will provide secure access to the
Internet, you must create an Internet browsing firewall policy. This policy differs depending
on whether your gateway-to-gateway configuration is policy-based or route-based.
To create an Internet browsing policy - policy-based VPN

2 Select Create New, enter the following information and then select OK:
Source Interface The interface to which the VPN tunnel is bound.

Source Address Name All
Destination Interface The interface to which the VPN tunnel is bound.
Destination Address Name The internal range of address of the remote spoke site.
Action IPSEC
VPN Tunnel Select the tunnel that provides access to the private network
behind the FortiGate unit.
UTM Select the UTM feature profiles that you want to apply to
Internet access.
Inbound NAT Enable
Configure other settings as needed.
To create an Internet browsing policy - route-based VPN

Source Interface The IPsec VPN interface.

Destination Interface The interface that connects to the Internet. The virtual IPsec
interface is configured on this physical interface.
Destination Address Name All

1060 01-420-99686-20101026
Internet-browsing configuration Routing all remote traffic through the VPN tunnel
Action ACCEPT
NAT Enable
UTM Select the UTM features that you want to apply to Internet
access.
Configure other settings as needed.
The VPN clients must be configured to route all Internet traffic through the VPN tunnel.
Routing all remote traffic through the VPN tunnel

To make use of the Internet browsing configuration on the VPN server, the VPN peer or
client must route all traffic through the VPN tunnel. Usually, only the traffic destined for the
private network behind the FortiGate VPN server is sent through the tunnel.
The remote end of the VPN can be a FortiGate unit that acts as a peer in a gateway-to-
gateway configuration or a FortiClient Endpoint Security application that protects an
individual client such as a notebook PC.
• To configure a remote peer FortiGate unit for Internet browsing via VPN, see
“Configuring a FortiGate remote peer to support Internet browsing”.
• To configure a FortiClient Endpoint Security application for Internet browsing via VPN,
see “Configuring a FortiClient application to support Internet browsing” on page 1062.
These procedures assume that your VPN connection to the protected private network is
working and that you have configured the FortiGate VPN server for Internet browsing as
described in “Creating an Internet browsing firewall policy” on page 1060.
Configuring a FortiGate remote peer to support Internet browsing

The configuration changes to send all traffic through the VPN differ for policy-based and
route-based VPNs.
To route all traffic through a policy-based VPN

1 At the FortiGate dialup client, go to Firewall > Policy > Policy.
2 Select the IPsec firewall policy and then select Edit.
3 From the Destination Address list, select all.
4 Select OK.
All packets are routed through the VPN tunnel, not just packets destined for the protected
private network.
To route all traffic through a route-based VPN

1 At the FortiGate dialup client, go to Router > Static > Static Route.
2 Select the default route (destination IP 0.0.0.0) and then select Edit. If there is no
default route, select Create New. Enter the following information and select OK:
Destination IP/Mask 0.0.0.0/0.0.0.0

Device Select the IPsec virtual interface.
Distance Leave at default.
All packets are routed through the VPN tunnel, not just packets destined for the protected
private network.

01-420-99686-20101026 1061
Routing all remote traffic through the VPN tunnel Internet-browsing configuration
Configuring a FortiClient application to support Internet browsing

By default, the FortiClient application configures the PC so that traffic destined for the
remote protected network passes through the VPN tunnel but all other traffic is sent to the
default gateway. You need to modify the FortiClient settings so that it configures the PC to
route all outbound traffic through the VPN.
To route all traffic through VPN - FortiClient application

1 At the remote host, start FortiClient.
3 Select the definition that connects FortiClient to the FortiGate dialup server.
4 Select Advanced and then select Edit.
5 In the Edit Connection dialog box, select Advanced.
6 In the Remote Network group, select Add.
7 In the IP and Subnet Mask fields, type 0.0.0.0/0.0.0.0 and select OK.
The address is added to the Remote Network list. The first destination IP address in
the list establishes a VPN tunnel. The second destination address
(0.0.0.0/0.0.0.0 in this case) forces all other traffic through the VPN tunnel.

1062 01-420-99686-20101026
Redundant VPN configurations
This section discusses the options for supporting redundant and partially redundant IPsec
VPNs, using route-based approaches.
• Configure the VPN peers - route-based VPN
• Redundant route-based VPN configuration example
• Partially-redundant route-based VPN example
• Creating a backup IPsec interface
A FortiGate unit with two interfaces to the Internet can be configured to support redundant
VPNs to the same remote peer. If the primary connection fails, the FortiGate unit can
establish a VPN using the other connection.
A fully-redundant configuration requires redundant connections to the Internet on both
peers. Figure 125 on page 1064 shows an example of this. This is useful to create a
reliable connection between two FortiGate units with static IP addresses.
When only one peer has redundant connections, the configuration is partially-redundant.
For an example of this, see “Partially-redundant route-based VPN example” on
page 1077. This is useful to provide reliable service from a FortiGate unit with static IP
addresses that accepts connections from dialup IPsec VPN clients.
In a fully-redundant VPN configuration with two interfaces on each peer, four distinct paths
are possible for VPN traffic from end to end. Each interface on a peer can communicate
with both interfaces on the other peer. This ensures that a VPN will be available as long as
each peer has one working connection to the Internet.
You configure a VPN and an entry in the routing table for each of the four paths. All of
these VPNs are ready to carry data. You set different routing distances for each route and
only the shortest distance route is used. If this route fails, the route with the next shortest
distance is used.
The redundant configurations described in this chapter use route-based VPNs, otherwise
known as virtual IPsec interfaces. This means that the FortiGate unit must operate in
NAT/Route mode. You must use auto-keying. A VPN that is created using manual keys
(see “Manual-key configurations” on page 1091) cannot be included in a redundant-tunnel
configuration.
The configuration described here assumes that your redundant VPNs are essentially
equal in cost and capability. When the original VPN returns to service, traffic continues to
use the replacement VPN until the replacement VPN fails. If your redundant VPN uses
more expensive facilities, you want to use it only as a backup while the main VPN is down.
For information on how to do this, see “Creating a backup IPsec interface” on page 1083.

01-420-99686-20101026 1063
Configuration overview Redundant VPN configurations
Figure 125: Example redundant-tunnel configuration
Redundant tunnel Fo
rtiG
Primary tunnel ate
1
te_ _2
r tiGa
Fo
Site_1 Site_2
Note: A VPN that is created using manual keys (see “Manual-key configurations” on
page 1091) cannot be included in a redundant-tunnel configuration.

A redundant configuration at each VPN peer includes:
• one phase 1 configuration (virtual IPsec interface) for each path between the two
peers. In a fully-meshed redundant configuration, each network interface on one peer
can communicate with each network interface on the remote peer. If both peers have
two public interfaces, this means that each peer has four paths, for example.
• one phase 2 definition for each phase 1 configuration
• one static route for each IPsec interface, with different distance values to prioritize the
routes
• two Accept firewall policies per IPsec interface, one for each direction of traffic
• dead peer detection enabled in each phase 1 definition
The procedures in this section assume that two separate interfaces to the Internet are
available on each VPN peer.

1064 01-420-99686-20101026
Redundant VPN configurations Configure the VPN peers - route-based VPN
Configure the VPN peers - route-based VPN

Configure each VPN peer as follows:
1 Ensure that the interfaces used in the VPN have static IP addresses.
2 Create a phase 1 configuration for each of the paths between the peers. Enable IPsec
Interface mode so that this creates a virtual IPsec interface. Enable dead peer
detection so that one of the other paths is activated if this path fails.
Path 1

IP Address Type the IP address of the primary interface of the remote
peer.
Local Interface Select the primary public interface of this peer.
Enable IPsec Interface Mode Enable
Dead Peer Detection Enable
Other settings as required by VPN.
Path 2

IP Address Type the IP address of the secondary interface of the
remote peer.
Local Interface Select the primary public interface of this peer.
Path 3

IP Address Type the IP address of the primary interface of the remote
peer.
Local Interface Select the secondary public interface of this peer.
Path 4

IP Address Type the IP address of the secondary interface of the
remote peer.
Local Interface Select the secondary public interface of this peer.
For more information, see “Auto Key phase 1 parameters” on page 1135.

01-420-99686-20101026 1065
Redundant route-based VPN configuration example Redundant VPN configurations
3 Create a phase 2 definition for each path. See “Phase 2 parameters” on page 1151.
Phase 1 Select the phase 1 configuration (virtual IPsec interface) that you
defined for this path. You can select the name from the Static IP
Address part of the list.
4 Create a route for each path to the other peer. If there are two ports on each peer, there
are four possible paths between the peer devices.
Destination IP/Mask The IP address and netmask of the private network behind the remote
peer.
Device One of the virtual IPsec interfaces on the local peer.
Distance For each path, enter a different value to prioritize the paths.
5 Define the firewall policy for the local primary interface. See “Defining firewall policies”
on page 1158. You need to create two policies for each path to enable communication
in both directions. Enter these settings in particular:
Source Interface/Zone Select the local interface to the internal (private) network
Destination Interface/Zone Select one of the virtual IPsec interfaces you created in
Step 2.
Schedule Always
Service Any
Action ACCEPT
Source Interface/Zone Select one of the virtual IPsec interfaces you created in
Step 2.
Destination Interface/Zone Select the local interface to the internal (private) network.
Schedule Always
Service Any
Action ACCEPT
Redundant route-based VPN configuration example

This example demonstrates a fully redundant site-to-site VPN configuration using route-
based VPNs. At each site, the FortiGate unit has two interfaces connected to the Internet
through different ISPs. This means that there are four possible paths for communication
between the two units. In this example, these paths, listed in descending priority, are:
• FortiGate_1 WAN 1 to FortiGate_2 WAN 1

1066 01-420-99686-20101026
Redundant VPN configurations Redundant route-based VPN configuration example
Figure 126: Example redundant route-based VPN configuration
N2 2
17 W Redundant tunnel WA 6.30.
2.1 AN 2 .1
6.2 2 17
0.2 Primary tunnel
N1
WA .2
Finance network WA
8 . 20
10.21.101.0/24 19 N1 .16
2.1 192
68
.10
.2
FFortiGate_2
FFortiGate_1
tiG
iG
G t 1
HR network
10.31.101.0/24
For each path, VPN configuration, firewall policies and routing are defined. By specifying a
different routing distance for each path, the paths are prioritized. A VPN tunnel is
established on each path, but only the highest priority one is used. If the highest priority
path goes down, the traffic is automatically routed over the next highest priority path. You
could use dynamic routing, but to keep this example simple, static routing is used.
You must
• configure the interfaces involved in the VPN
• define the phase 1 configuration for each of the four possible paths, creating a virtual
IPsec interface for each one
• define the phase 2 configuration for each of the four possible paths
• configure routes for the four IPsec interfaces, assigning the appropriate priorities
• configure incoming and outgoing firewall policies between the internal interface and
each of the virtual IPsec interfaces
To configure the network interfaces

2 Select the Edit icon for the Internal interface, enter the following information and then
select OK:

IP/Netmask 10.21.101.0/255.255.255.0
3 Select the Edit icon for the WAN1 interface, enter the following information and then
select OK:

IP/Netmask 192.168.10.2/255.255.255.0
4 Select the Edit icon for the WAN2 interface, enter the following information and then
select OK:

01-420-99686-20101026 1067

IP/Netmask 172.16.20.2/255.255.255.0
To configure the IPsec interfaces (phase 1 configurations)

Name Site_1_A
IP Address 192.168.20.2
Local Interface WAN1
Mode Main
Advanced
Enable IPsec Interface Mode Select
Dead Peer Detection Select
Name Site_1_B
Mode Main
Advanced
Name Site_1_C
IP Address 192.168.20.2
Mode Main
Advanced

1068 01-420-99686-20101026

Name Site_1_D
Mode Main
Advanced
To define the phase 2 configurations for the four VPNs

Name Route_A.
Phase 1 Site_1_A
Name Route_B.
Phase 1 Site_1_B
Name Route_C.
Phase 1 Site_1_C
Name Route_D.
Phase 1 Site_1_D
To configure routes
2 Select Create New, enter the following default gateway information and then select
OK:

Device WAN1
Gateway 192.168.10.1
Distance 10

01-420-99686-20101026 1069

Device Site_1_A
Distance 1

Device Site_1_B
Distance 2

Device Site_1_C
Distance 3

Device Site_1_D
Distance 4
To configure firewall policies


Destination Interface/Zone Site_1_A
Schedule Always
Service Any
Action ACCEPT
Source Interface/Zone Site_1_A

Schedule Always
Service Any
Action ACCEPT

Destination Interface/Zone Site_1_B

1070 01-420-99686-20101026

Schedule Always
Service Any
Action ACCEPT
Source Interface/Zone Site_1_B

Schedule Always
Service Any
Action ACCEPT

Destination Interface/Zone Site_1_C
Schedule Always
Service Any
Action ACCEPT
Source Interface/Zone Site_1_C

Schedule Always
Service Any
Action ACCEPT

Destination Interface/Zone Site_1_D
Schedule Always
Service Any
Action ACCEPT

01-420-99686-20101026 1071
Source Interface/Zone Site_1_D

Schedule Always
Service Any
Action ACCEPT
The configuration for FortiGate_2 is very similar that of FortiGate_1. You must
• define the phase 1 configuration for each of the four possible paths, creating a virtual
• define the phase 2 configuration for each of the four possible paths
• configure routes for the four IPsec interfaces, assigning the appropriate priorities

2 Select the Internal interface and then select Edit. Enter the following information and
then select OK:

IP/Netmask 10.31.101.0/255.255.255.0
3 Select the WAN1 interface and then select Edit. Enter the following information and
then select OK:

IP/Netmask 192.168.20.2/255.255.255.0
then select OK:

IP/Netmask 172.16.30.2/255.255.255.0

Name Site_2_A
IP Address 192.168.10.2
Mode Main

1072 01-420-99686-20101026

Advanced
Name Site_2_B
Mode Main
Advanced
Name Site_2_C
IP Address 192.168.10.2
Mode Main
Advanced
Name Site_2_D
Mode Main
Advanced

01-420-99686-20101026 1073

To define the phase 2 configurations for the four VPNs

Name Route_A.
Phase 1 Site_2_A
Name Route_B.
Phase 1 Site_2_B
Name Route_C.
Phase 1 Site_2_C
Name Route_D.
Phase 1 Site_2_D
To configure routes
OK:

Device WAN1
Gateway 192.168.10.1
Distance 10

Device Site_2_A
Distance 1

Device Site_2_B
Distance 2

1074 01-420-99686-20101026
Device Site_2_C
Distance 3

Device Site_2_D
Distance 4


Schedule Always
Service Any
Action ACCEPT
Source Interface/Zone Site_2_A

Schedule Always
Service Any
Action ACCEPT

Schedule Always
Service Any
Action ACCEPT
Source Interface/Zone Site_2_B

Schedule Always

01-420-99686-20101026 1075
Service Any
Action ACCEPT

Destination Interface/Zone Site_2_C
Schedule Always
Service Any
Action ACCEPT
Source Interface/Zone Site_2_C

Schedule Always
Service Any
Action ACCEPT

Destination Interface/Zone Site_2_D
Schedule Always
Service Any
Action ACCEPT
Source Interface/Zone Site_2_D

Schedule Always
Service Any
Action ACCEPT

1076 01-420-99686-20101026
Redundant VPN configurations Partially-redundant route-based VPN example
Partially-redundant route-based VPN example

This example demonstrates how to set up a partially redundant IPsec VPN between a
local FortiGate unit and a remote VPN peer that receives a dynamic IP address from an
ISP before it connects to the FortiGate unit. For more information about FortiGate dialup-
client configurations, see “FortiGate dialup-client configurations” on page 1047.
When a FortiGate unit has more than one interface to the Internet (see FortiGate_1 in
Figure 127), you can configure redundant routes—if the primary connection fails, the
FortiGate unit can establish a VPN using the redundant connection.
In this case, FortiGate_2 has only one connection to the Internet. If the link to the ISP were
to go down, the connection to FortiGate_1 would be lost, and the tunnel would be taken
down. The tunnel is said to be partially redundant because FortiGate_2 does not support a
redundant connection.
In the configuration example:
• Both FortiGate units operate in NAT/Route mode.
• Two separate interfaces to the Internet (192.168.10.2 and 172.16.20.2) are available
on FortiGate_1. Each interface has a static public IP address.
• FortiGate_2 has a single connection to the Internet and obtains a dynamic public IP
address (for example, 172.16.30.1) when it connects to the Internet.
• FortiGate_2 forwards IP packets from the SOHO network (10.31.101.0/24) to the
corporate network (10.21.101.0/24) behind FortiGate_1 through a partially redundant
IPsec VPN. Encrypted packets from FortiGate_2 are addressed to the public interface
of FortiGate_1. Encrypted packets from FortiGate_1 are addressed to the public IP
address of FortiGate_2.
There are two possible paths for communication between the two units. In this example,
these paths, listed in descending priority, are:
For each path, VPN configuration, firewall policies and routing are defined. By specifying a
different routing distance for each path, the paths are prioritized. A VPN tunnel is
established on each path, but only the highest priority one is used. If the highest priority
path goes down, the traffic is automatically routed over the next highest priority path. You
could use dynamic routing, but to keep this example simple, static routing is used.

01-420-99686-20101026 1077
Partially-redundant route-based VPN example Redundant VPN configurations
Figure 127: Example partially redundant route-based configuration
17 W Redundant tunnel
2.1 AN
6.2 2 Primary tunnel
0.2
Corporate network WA
10.21.101.0/24 19 N1
2.1
68
.10 WA
.1
FFortiGate_1
tiG
iG
G t 1 17 N1
2.1
6.3
0.1
FFortiGate_2
iG 2
SOHO network
10.31.101.0/24
You must
• define the phase 1 configuration for each of the two possible paths, creating a virtual
• define the phase 2 configuration for each of the two possible paths

then select OK:

IP/Netmask 10.21.101.2/255.255.255.0
then select OK:

IP/Netmask 192.168.10.2/255.255.255.0
then select OK:

IP/Netmask 172.16.20.2/255.255.255.0

1078 01-420-99686-20101026

Name Site_1_A
Mode Main
Advanced
Name Site_1_B
Mode Main
Advanced
To define the phase 2 configurations for the two VPNs

Name Route_A.
Phase 1 Site_1_A
Name Route_B.
Phase 1 Site_1_B
To configure routes
OK:

01-420-99686-20101026 1079

Device WAN1
Gateway 192.168.10.1
Distance 10


Schedule Always
Service Any
Action ACCEPT

Schedule Always
Service Any
Action ACCEPT
The configuration for FortiGate_2 is similar to that of FortiGate_1. You must
• configure the interface involved in the VPN
• define the phase 1 configuration for the primary and redundant paths, creating a virtual
• define the phase 2 configurations for the primary and redundant paths, defining the
internal network as the source address so that FortiGate_1 can automatically configure
routing
• configure the routes for the two IPsec interfaces, assigning the appropriate priorities
• configure firewall policies between the internal interface and each of the virtual IPsec
interfaces

then select OK:

1080 01-420-99686-20101026

IP/Netmask 10.31.101.2/255.255.255.0
then select OK:
Addressing mode DHCP
To configure the two IPsec interfaces (phase 1 configurations)

Name Site_2_A
IP Address 192.168.10.2
Mode Main
Advanced
Name Site_2_B
Mode Main
Advanced
To define the phase 2 configurations for the two VPNs


01-420-99686-20101026 1081
Name Route_A.
Phase 1 Site_2_A
Advanced
Source Address 10.31.101.0/24
Name Route_B.
Phase 1 Site_2_B
Advanced
Source Address 10.31.101.0/24
To configure routes

Device Site_2_A
Distance 1

Device Site_2_B
Distance 2


Schedule Always
Service Any
Action ACCEPT

Schedule Always
Service Any
Action ACCEPT

1082 01-420-99686-20101026
Redundant VPN configurations Creating a backup IPsec interface
Creating a backup IPsec interface

Starting in FortiOS 3.0 MR4, you can configure a route-based VPN that acts as a backup
facility to another VPN. It is used only while your main VPN is out of service. This is
desirable when the redundant VPN uses a more expensive facility.
In FortiOS releases prior to 3.0 MR4, a backup VPN configuration is possible only if the
backup connection is a modem in a Redundant mode configuration.
You can configure a backup IPsec interface only in the CLI. The backup feature works
only on interfaces with static addresses that have dead peer detection enabled. The
monitor-phase1 option creates a backup VPN for the specified phase 1 configuration.
In the following example, backup_vpn is a backup for main_vpn.
edit main_vpn
set dpd on
set interface port1
set nattraversal enable
set psksecret "hard-to-guess"
set type static
end
edit backup_vpn
set dpd on
set interface port2
set monitor-phase1 main_vpn
set psksecret "hard-to-guess"
set type static
end

01-420-99686-20101026 1083
Creating a backup IPsec interface Redundant VPN configurations

1084 01-420-99686-20101026
Transparent mode VPNs
This section describes transparent VPN configurations, in which two FortiGate units
create a VPN tunnel between two separate private networks transparently.
• Configure the VPN peers
In Transparent mode, all interfaces of the FortiGate unit except the management interface
(which by default is assigned IP address 10.10.10.1/255.255.255.0) are invisible at the
network layer. Typically, when a FortiGate unit runs in Transparent mode, different network
segments are connected to the FortiGate interfaces. Figure 128 shows the management
station on the same subnet. The management station can connect to the FortiGate unit
directly through the web-based manager.
Figure 128: Management station on internal network
ou ter
ger
Ed
te_1
r tiGa e 10
Fo .10
.10
Ma .1
n
sta age
tio me
n nt
Site_1
10.10.10.0/24
An edge router typically provides a public connection to the Internet and one interface of
the FortiGate unit is connected to the router. If the FortiGate unit is managed from an
external address (see Figure 129 on page 1086), the router must translate (NAT) a
routable address to direct management traffic to the FortiGate management interface.

01-420-99686-20101026 1085
Configuration overview Transparent mode VPNs
Figure 129: Management station on external network
ter
e rou
g
Ed NAT
h 17
wit 2.1
6.1
0.1
00
e_1
t
r tiGa e 10
Fo .10
.10
.1
Ma
n
sta age
tio me
n nt
Site_1
10.10.10.0/24
In a transparent VPN configuration, two FortiGate units create a VPN tunnel between two
separate private networks transparently. All traffic between the two networks is encrypted
and protected by FortiGate firewall policies.
Both FortiGate units may be running in Transparent mode, or one could be running in
Transparent mode and the other running in NAT/Route mode. If the remote peer is running
in NAT/Route mode, it must have a static public IP address.
Note: VPNs between two FortiGate units running in Transparent mode do not support
inbound/outbound NAT (supported through CLI commands) within the tunnel. In addition, a
FortiGate unit running in Transparent mode cannot be used in a hub-and-spoke
configuration.
Encrypted packets from the remote VPN peer are addressed to the management interface
of the local FortiGate unit. If the local FortiGate unit can reach the VPN peer locally, a
static route to the VPN peer must be added to the routing table on the local FortiGate unit.
If the VPN peer connects through the Internet, encrypted packets from the local FortiGate
unit must be routed to the edge router instead. For information about how to add a static
route to the FortiGate routing table, see the “Router Static” chapter of the FortiGate
In the example configuration shown in Figure 129, Network Address Translation (NAT) is
enabled on the router. When an encrypted packet from the remote VPN peer arrives at the
router through the Internet, the router performs inbound NAT and forwards the packet to
the FortiGate unit. Refer to the software supplier’s documentation to configure the router.
If you want to configure a VPN between two FortiGate units running in Transparent mode,
each unit must have an independent connection to a router that acts as a gateway to the
Internet, and both units must be on separate networks that have a different address
space. When the two networks linked by the VPN tunnel have different address spaces
(see Figure 130 on page 1087), at least one router must separate the two FortiGate units,
unless the packets can be redirected using ICMP (see Figure 131 on page 1087).

1086 01-420-99686-20101026
Transparent mode VPNs Configuration overview
Figure 130: Link between two FortiGate units running in Transparent mode
r
ute
Ro
e_1 Fo
i Gate rtiG
Fort ate
_2
Network_1 Network_2
In Figure 131, interface C behind the router is the default gateway for both FortiGate units.
Packets that cannot be delivered on Network_1 are routed to interface C by default.
Similarly, packets that cannot be delivered on Network_2 are routed to interface C. In this
case, the router must be configured to redirect packets destined for Network_1 to interface
A and redirect packets destined for Network_2 to interface B.
Figure 131: ICMP redirecting packets to two FortiGate units running in Transparent mode
r
ute
Ro
C ICM
P
e_1 ICM P Fo
i G ate A B
rtiG
rt Network_3 ate
Fo _2
Network_1 Network_2

01-420-99686-20101026 1087
Configuration overview Transparent mode VPNs
If there are additional routers behind the FortiGate unit (see Figure 132 on page 1088)
and the destination IP address of an inbound packet is on a network behind one of those
routers, the FortiGate routing table must include routes to those networks. For example, in
Figure 132, the FortiGate unit must be configured with static routes to interfaces A and B
in order to forward packets to Network_1 and Network_2 respectively.
Figure 132: Destinations on remote networks behind internal routers
_1
i Gate
or t
F
1
uter_ A Network_3
Ro Ro
B ute
r_2
Network_1 Network_2
Transparent VPN infrastructure requirements

• The local FortiGate unit must be operating in Transparent mode.
• The management IP address of the local FortiGate unit specifies the local VPN
gateway. The management IP address is considered a static IP address for the local
VPN peer.
• If the local FortiGate unit is managed through the Internet, or if the VPN peer connects
through the Internet, the edge router must be configured to perform inbound NAT and
forward management traffic and/or encrypted packets to the FortiGate unit.
• If the remote peer is operating in NAT/Route mode, it must have a static public IP
address.
A FortiGate unit operating in Transparent mode requires the following basic configuration
to operate as a node on the IP network:
• The unit must have sufficient routing information to reach the management station.
• For any traffic to reach external destinations, a default static route to an edge router
that forwards packets to the Internet must be present in the FortiGate routing table.
• When all of the destinations are located on the external network, the FortiGate unit
may route packets using a single default static route. If the network topology is more
complex, one or more static routes in addition to the default static route may be
required in the FortiGate routing table.
Only policy-based VPN configurations are possible in Transparent mode.

1088 01-420-99686-20101026
Transparent mode VPNs Configure the VPN peers
Before you begin

An IPsec VPN definition links a gateway with a tunnel and an IPsec policy. If your network
topology includes more than one virtual domain, you must choose components that were
created in the same virtual domain. Therefore, before you define a transparent VPN
configuration, choose an appropriate virtual domain in which to create the required
interfaces, firewall policies, and VPN components. For more information, see the “Using
virtual domains” chapter of the FortiGate Administration Guide.
Configure the VPN peers

The following procedure assumes that the local VPN peer operates in Transparent mode.
The remote VPN peer may operate in NAT/Route mode or Transparent mode.
1 At the local FortiGate unit, define the phase 1 parameters needed to establish a secure
connection with the remote peer. See “Auto Key phase 1 parameters” on page 1135.
Select Advanced and enter these settings in particular:

IP Address Type the IP address of the public interface to the remote peer. If the
remote peer is a FortiGate unit running in Transparent mode, type the IP
address of the remote management interface.
Advanced Select Nat-traversal, and type a value into the Keepalive Frequency field.
These settings protect the headers of encrypted packets from being
altered by external NAT devices and ensure that NAT address mappings
do not change while the VPN tunnel is open. For more information, see
“NAT traversal” on page 1147 and “NAT keepalive frequency” on
page 1147.
Phase 1 Select the set of phase 1 parameters that you defined for the remote peer. The
name of the remote peer can be selected from the Static IP Address list.
3 Define the source and destination addresses of the IP packets that are to be
transported through the VPN tunnel. See “Defining firewall addresses” on page 1157.
• For the originating address (source address), enter the IP address of the local
management interface (for example, 10.10.10.1/32).
• For the remote address (destination address), enter the IP address and netmask of
the private network behind the remote peer (for example, 192.168.10.0/24). If
the remote peer is a FortiGate unit running in Transparent mode, enter the IP
address of the remote management interface instead.
4 Define an IPsec firewall policy to permit communications between the source and
destination addresses. See “Defining firewall policies” on page 1158. Enter these
settings in particular:
Source Interface/Zone Select the local interface to the internal (private) network.
Source Address Name Select the source address that you defined in Step 3.
Destination Interface/Zone Select the interface to the edge router. When you configure the
IPsec firewall policy on a remote peer that operates in
NAT/Route mode, you select the public interface to the external
(public) network instead.
Destination Address Name Select the destination address that you defined in Step 3.

01-420-99686-20101026 1089
For more information Transparent mode VPNs
Action IPSEC
VPN Tunnel Select the name of the phase 2 tunnel configuration that you
created in Step 2.
For more information

The FortiGate Transparent Mode Technical Guide provides examples and troubleshooting
information concerning several FortiGate features, including IPsec VPN.

1090 01-420-99686-20101026
Manual-key configurations
This section explains how to manually define cryptographic keys to establish an IPsec
VPN, either policy-based or route-based.
• Specify the manual keys for creating a tunnel
You can manually define cryptographic keys for the FortiGate unit to establish an IPsec
VPN.
You define manual keys where prior knowledge of the encryption and/or authentication
key is required (that is, one of the VPN peers requires a specific IPsec encryption and/or
authentication key). In this case, you do not specify IPsec phase 1 and phase 2
parameters; you define manual keys on the VPN > IPSEC > Manual Key tab instead.
If one VPN peer uses specific authentication and encryption keys to establish a tunnel,
both VPN peers must be configured to use the same encryption and authentication
algorithms and keys.
Note: It may not be safe or practical to define manual keys because network administrators
must be trusted to keep the keys confidential, and propagating changes to remote VPN
peers in a secure manner may be difficult.
It is essential that both VPN peers be configured with matching encryption and
authentication algorithms, matching authentication and encryption keys, and
complementary Security Parameter Index (SPI) settings.
You can define either the encryption or the authentication as NULL (disabled), but not
both.
Each SPI identifies a Security Association (SA). The value is placed in ESP datagrams to
link the datagrams to the SA. When an ESP datagram is received, the recipient refers to
the SPI to determine which SA applies to the datagram. An SPI must be specified
manually for each SA. Because an SA applies to communication in one direction only, you
must specify two SPIs per configuration (a local SPI and a remote SPI) to cover
bidirectional communications between two VPN peers.
Caution: If you are not familiar with the security policies, SAs, selectors, and SA databases
for your particular installation, do not attempt the following procedure without qualified
assistance.
Specify the manual keys for creating a tunnel

Specify the manual keys for creating a tunnel as follows:
1 Go to VPN > IPSEC > Manual Key and select Create New.
2 Include appropriate entries as follows:

01-420-99686-20101026 1091
Specify the manual keys for creating a tunnel Manual-key configurations
Name Type a name for the VPN tunnel.

Local SPI Type a hexadecimal number (up to 8 characters, 0-9, a-f) that
represents the SA that handles outbound traffic on the local
FortiGate unit. The valid range is from 0x100 to 0xffffffff. This
value must match the Remote SPI value in the manual key
configuration at the remote peer.
Remote SPI Type a hexadecimal number (up to 8 characters, 0-9, a-f) that
represents the SA that handles inbound traffic on the local FortiGate
unit. The valid range is from 0x100 to 0xffffffff. This value must
match the Local SPI value in the manual key configuration at the
remote peer.
Remote Gateway Type the IP address of the public interface to the remote peer. The
address identifies the recipient of ESP datagrams.
Local Interface Select the name of the physical, aggregate, or VLAN interface to
which the IPsec tunnel will be bound. The FortiGate unit obtains the
IP address of the interface from System > Network > Interface
settings. This is available in NAT/Route mode only.
Encryption Select one of the following symmetric-key encryption algorithms:
Algorithm • DES — Digital Encryption Standard, a 64-bit block algorithm that
uses a 56-bit key.
• 3DES — Triple-DES, in which plain text is encrypted three times
by three keys.
• AES128 — A 128-bit block algorithm that uses a 128-bit key.
Encryption Key If you selected:
• DES, type a 16-character hexadecimal number (0-9, a-f).
• 3DES, type a 48-character hexadecimal number (0-9, a-f)
separated into three segments of 16 characters.
• AES128, type a 32-character hexadecimal number (0-9, a-f)
separated into two segments of 16 characters.
separated into three segments of 16 characters.
separated into four segments of 16 characters.
Authentication Select one of the following message digests:

Algorithm • MD5 — Message Digest 5 algorithm, which produces a 128-
bit message digest.
• SHA1 — Secure Hash Algorithm 1, which produces a 160-bit
message digest.
Authentication Key If you selected:
• MD5, type a 32-character hexadecimal number (0-9, a-f)
separated into two segments of 16 characters.
• SHA1, type 40-character hexadecimal number (0-9, a-f)
separated into one segment of 16 characters and a second
segment of 24 characters.
IPsec Interface Mode Select to create a route-based VPN. A virtual IPsec interface is
created on the Local Interface that you selected. This option is
available only in NAT/Route mode.
3 Select OK.

1092 01-420-99686-20101026
IPv6 IPsec VPNs
This chapter describes how to configure your FortiGate unit’s IPv6 IPsec VPN
functionality. This feature is available starting in FortiOS 3.0 MR5.
• Overview of IPv6 IPsec support
• Configuring IPv6 IPsec VPNs
• Site-to-site IPv6 over IPv6 VPN example
Overview of IPv6 IPsec support

The FortiGate unit supports route-based IPv6 IPsec, but not policy-based. This section
describes only how IPv6 IPsec support differs from IPv4 IPsec support.
Where both the gateways and the protected networks use IPv6 addresses, sometimes
called IPv6 over IPv6, you can create either an auto-keyed or manually-keyed VPN. You
can combine IPv6 and IPv4 addressing in an auto-keyed VPN in the following ways:

The protected networks have IPv4 addresses. The phase 2 configurations at
The protected networks use IPv6 addresses. The phase 2 configurations at
Compared with IPv4 IPsec VPN functionality, there are some limitations:
• Except for IPv6 over IPv4, remote gateways with Dynamic DNS are not supported.
This is because FortiOS 3.0 does not support IPv6 DNS.
• You cannot use RSA certificates in which the common name (cn) is a domain name
that resolves to an IPv6 address. This is because FortiOS 3.0 does not support IPv6
DNS.
• DHCP over IPsec is not supported, because FortiOS 3.0 does not support IPv6 DHCP.
• Selectors cannot be firewall address names. Only IP address, address range and
subnet are supported.
• Redundant IPv6 tunnels are not supported.
Certificates
On a VPN with IPv6 phase 1 configuration, you can authenticate using VPN certificates in
which the common name (cn) is an IPv6 address. The cn-type keyword of the user
peer command has an option, ipv6, to support this.

01-420-99686-20101026 1093
Configuring IPv6 IPsec VPNs IPv6 IPsec VPNs
Configuring IPv6 IPsec VPNs

Configuration of an IPv6 IPsec VPN follows the same sequence as for an IPv4 route-
based VPN: phase 1 settings, phase 2 settings, firewall policies and routing.
To access IPv6 functionality through the web-based manager, go to System Admin >
Settings and enable IPv6 Support on GUI.
In the web-based manager, you define the Phase 1 as IPv6 in the Advanced settings.
Enable the IPv6 Version check box. You can then enter an IPv6 address for the remote
gateway.
In the CLI, you define an IPsec phase 1 configuration as IPv6 by setting ip-version
to 6. Its default value is 4. Then, the local-gw and remote-gw keywords are hidden
and the corresponding local-gw6 and remote-gw6 keywords are available. The values
for local-gw6 and remote-gw6 must be IPv6 addresses. For example:
edit tunnel6
set ip-version 6
set remote-gw6 0:123:4567::1234
set interface port3
end
To create an IPv6 IPsec phase 2 configuration in the web-based manager, you need to
define IPv6 selectors in the Advanced settings. Change the default “0.0.0.0/0” address for
Source address and Destination address to the IPv6 value “::/0”. If needed, enter specific
IPv6 addresses, address ranges or subnet addresses in these fields.
In the CLI, set src-addr-type and dst-addr-type to ip6, range6 or subnet6 to
specify IPv6 selectors. By default, zero selectors are entered, “::/0” for the subnet6
address type, for example. The simplest IPv6 phase 2 configuration looks like this:
edit tunnel6_p2
set phase1name tunnel6
end
Firewall policies
To complete the VPN configuration, you need a firewall policy in each direction to permit
traffic between the protected network’s port and the IPsec interface. You need IPv6
policies unless the VPN is IPv4 over IPv6.
Routing
Appropriate routing is needed for both the IPsec packets and the encapsulated traffic
within them. You need a route, which could be the default route, to the remote VPN
gateway via the appropriate interface. You also need a route to the remote protected
network via the IPsec interface.

1094 01-420-99686-20101026
IPv6 IPsec VPNs Site-to-site IPv6 over IPv6 VPN example
To create a static route in the web-based manager, go to Router > Static. Select the drop-
down arrow on the Create New button and select IPv6 Route. Enter the information and
select OK. In the CLI, use the router static6 command. For example, where the
remote network is fec0:0000:0000:0004::/64 and the IPsec interface is toB:
edit 1
set device port2
set dst 0::/0
next
edit 2
set device toB
set dst fec0:0000:0000:0004::/64
next
end
If the VPN is IPV4 over IPv6, the route to the remote protected network is an IPv4 route. If
the VPN is IPv6 over IPv4, the route to the remote VPN gateway is an IPv4 route.
Site-to-site IPv6 over IPv6 VPN example

In this example, computers on IPv6-addressed private networks communicate securely
over public IPv6 infrastructure.
Figure 133: Example IPv6-over-IPv6 VPN topology
fec 7
5c
0:0 3:2
00 e8
1:2 fff:f
09
:0f 0 9:0
ff:f
e8 Por rt 2 0 1:2
3:2 t 2 Poc0:00
5f2 fe
Po A Fo
rt 3 ate rtiG
Po
o rtiG ate rt 3
F B
fec fec
0:0 0:0
00 00
0:0 0:0
00 00
0:0 0:0
00 00
0:: 4::
/64 /64
Configure FortiGate A interfaces

Port 2 connects to the public network and port 3 connects to the local network.
edit port2
config ipv6
set ip6-address fec0::0001:209:0fff:fe83:25f2/64
end
next
edit port3
config ipv6

01-420-99686-20101026 1095
Site-to-site IPv6 over IPv6 VPN example IPv6 IPsec VPNs

end
next
end
Configure FortiGate A IPsec settings

The phase 1 configuration creates a virtual IPsec interface on port 2 and sets the remote
gateway to the public IP address FortiGate B. This configuration is the same as for an
IPv4 route-based VPN, except that ip-version is set to 6 and the remote-gw6
keyword is used to specify an IPv6 remote gateway address.
edit toB
set ip-version 6
set interface port2
set remote-gw6 fec0:0000:0000:0003:209:0fff:fe83:25c7
set dpd enable
set psksecret maryhadalittlelamb
set proposal 3des-md5 3des-sha1
end
By default, phase 2 selectors are set to accept all subnet addresses for source and
destination. The default setting for src-addr-type and dst-addr-type is subnet.
The IPv6 equivalent is subnet6. The default subnet addresses are 0.0.0.0/0 for IPv4,
::/0 for IPv6.
edit toB2
set phase1name toB
set pfs enable
set replay enable
end
Configure FortiGate A firewall policies

Firewall policies are required to allow traffic between port3 and the IPsec interface toB in
each direction. The address all6 must be defined using the firewall address6
command as ::/0.
edit 1
set srcintf port3
set dstintf toB
set srcaddr all6
set dstaddr all6
set action accept
set service ANY
set schedule always
next
edit 2
set srcintf toB
set dstintf port3
set srcaddr all6
set dstaddr all6

1096 01-420-99686-20101026
set action accept

set service ANY
set schedule always
end
Configure FortiGate A routing

This simple example requires just two static routes. Traffic to the protected network behind
FortiGate B is routed via the virtual IPsec interface toB. A default route sends all IPv6
traffic out on port2.
edit 1
set device port2
set dst 0::/0
next
edit 2
set device toB
set dst fec0:0000:0000:0004::/64
end
Configure FortiGate B
The configuration of FortiGate B is very similar to that of FortiGate A. A virtual IPsec
interface toA is configured on port2 and its remote gateway is the public IP address of
FortiGate A. Firewall policies enable traffic to pass between the private network and the
IPsec interface. Routing ensures traffic for the private network behind FortiGate A goes
through the VPN and that all IPv6 packets are routed to the public network.
edit port2
config ipv6
set ip6-address fec0::0003:209:0fff:fe83:25c7/64
end
next
edit port3
config ipv6
set ip6-address fec0::0004:209:0fff:fe83:2569/64
end
end
edit toA
set ip-version 6
set interface port2
set remote-gw6 fec0:0000:0000:0001:209:0fff:fe83:25f2
set dpd enable
end
edit toA2
set phase1name toA
set pfs enable
set replay enable

01-420-99686-20101026 1097
end
edit 1
set srcintf port3
set dstintf toA
set srcaddr all6
set dstaddr all6
set action accept
set service ANY
set schedule always
next
edit 2
set srcintf toA
set dstintf port3
set srcaddr all6
set dstaddr all6
set action accept
set service ANY
set schedule always
end
edit 1
set device port2
set dst 0::/0
next
edit 2
set device toA
set dst fec0:0000:0000:0000::/64
end

In this example, two private networks with IPv4 addressing communicate securely over
IPv6 infrastructure.
fec c7
0:0 3 :25
00
1:2 ff:fe8
09 9:0f
:0f :20
ff:f
e8 Por rt 2 01
3:2 t 2 Poc0:00
5f2 fe
Po Fo
rt 3 te A rtiG
rtiGa ate Po
rt 3
Fo B
19 19
2.1 2.1
68 68
.2. .3.
0/2 0/2
4 4

1098 01-420-99686-20101026

Port 2 connects to the IPv6 public network and port 3 connects to the IPv4 LAN.
edit port2
config ipv6
end
next
edit port3
set 192.168.2.1/24
end

The phase 1 configuration is the same as in the IPv6 over IPv6 example.
edit toB
set ip-version 6
set interface port2
set remote-gw6 fec0:0000:0000:0003:209:0fff:fe83:25c7
set dpd enable
end
The phase 2 configuration is the same as you would use for an IPv4 VPN. By default,
phase 2 selectors are set to accept all subnet addresses for source and destination.
edit toB2
set phase1name toB
set pfs enable
set replay enable
end

Firewall policies are required to allow traffic between port3 and the IPsec interface toB in
each direction. These are IPv4 firewall policies.
edit 1
set srcintf port3
set dstintf toB
set srcaddr all
set dstaddr all
set action accept
set service ANY
set schedule always
next
edit 2
set srcintf toB
set dstintf port3
set srcaddr all
set dstaddr all

01-420-99686-20101026 1099
set action accept

set service ANY
set schedule always
end

FortiGate B is routed via the virtual IPsec interface toB using an IPv4 static route. A
default route sends all IPv6 traffic, including the IPv6 IPsec packets, out on port2.
edit 1
set device port2
set dst 0::/0
next
edit 2
set device toB
set dst 192.168.3.0/24
end
interface toA is configured on port2 and its remote gateway is the public IP address of
FortiGate A. The IPsec phase 2 configuration has IPv4 selectors.
IPv4 firewall policies enable traffic to pass between the private network and the IPsec
interface. An IPv4 static route ensures traffic for the private network behind FortiGate A
goes through the VPN and an IPv6 static route ensures that all IPv6 packets are routed to
the public network.
edit port2
config ipv6
set ip6-address fec0::0003:fe83:25c7/64
end
next
edit port3
set 192.168.3.1/24
end
edit toA
set ip-version 6
set interface port2
set remote-gw6 fec0:0000:0000:0001:209:0fff:fe83:25f2
set dpd enable
end
edit toA2
set phase1name toA
set pfs enable
set replay enable
end

1100 01-420-99686-20101026

edit 1
set srcintf port3
set dstintf toA
set srcaddr all
set dstaddr all
set action accept
set service ANY
set schedule always
next
edit 2
set srcintf toA
set dstintf port3
set srcaddr all
set dstaddr all
set action accept
set service ANY
set schedule always
end
edit 1
set device port2
set dst 0::/0
next
edit 2
set device toA
set dst 192.168.2.0/24
end

In this example, IPv6-addressed private networks communicate securely over IPv4 public
infrastructure.
10 4
.0. Por rt 2 1/2
0.1 t 2 Po .0.1.
/24 10
Po A Fo
rt 3 ate rtiG
Po
o rtiG ate rt 3
F B
fec fec
0:0 0:0
00 00
0:0 0:0
00 00
0:0 0:0
00 00
0:: 4::
/64 /64

01-420-99686-20101026 1101

Port 2 connects to the IPv4 public network and port 3 connects to the IPv6 LAN.
edit port2
set 10.0.0.1/24
next
edit port3
config ipv6
end

The phase 1 configuration uses IPv4 addressing.
edit toB
set interface port2
set dpd enable
end
The phase 2 configuration uses IPv6 selectors. By default, phase 2 selectors are set to
accept all subnet addresses for source and destination. The default setting for src-
addr-type and dst-addr-type is subnet. The IPv6 equivalent is subnet6. The
default subnet addresses are 0.0.0.0/0 for IPv4, ::/0 for IPv6.
edit toB2
set phase1name toB
set pfs enable
set replay enable
end

IPv6 firewall policies are required to allow traffic between port3 and the IPsec interface toB
in each direction. The address all6 must be defined using the firewall address6
command as ::/0.
edit 1
set srcintf port3
set dstintf toB
set srcaddr all6
set dstaddr all6
set action accept
set service ANY
set schedule always
next
edit 2
set srcintf toB

1102 01-420-99686-20101026
set dstintf port3

set srcaddr all6
set dstaddr all6
set action accept
set service ANY
set schedule always
end

FortiGate B is routed via the virtual IPsec interface toB using an IPv6 static route. A
default route sends all IPv4 traffic, including the IPv4 IPsec packets, out on port2.
edit 1
set device toB
set dst fec0:0000:0000:0004::/64
end
edit 1
set device port2
set dst 0.0.0.0/0
end
interface toA is configured on port2 and its remote gateway is the IPv4 public IP address
of FortiGate A. The IPsec phase 2 configuration has IPv6 selectors.
IPv6 firewall policies enable traffic to pass between the private network and the IPsec
interface. An IPv6 static route ensures traffic for the private network behind FortiGate A
goes through the VPN and an IPv4 static route ensures that all IPv4 packets are routed to
the public network.
edit port2
set 10.0.1.1/24
next
edit port3
config ipv6
set ip6-address fec0::0004:209:0fff:fe83:2569/64
end
edit toA
set interface port2
set dpd enable
end
edit toA2
set phase1name toA

01-420-99686-20101026 1103
set pfs enable

set replay enable
end
edit 1
set srcintf port3
set dstintf toA
set srcaddr all6
set dstaddr all6
set action accept
set service ANY
set schedule always
next
edit 2
set srcintf toA
set dstintf port3
set srcaddr all6
set dstaddr all6
set action accept
set service ANY
set schedule always
end
edit 1
set device toA
set dst fec0:0000:0000:0000::/64
end
edit 1
set device port2
end

1104 01-420-99686-20101026
L2TP and IPsec (Microsoft VPN)
configurations
This section describes how to set up a VPN that is compatible with the Microsoft Windows
native VPN, which is L2TP with IPsec encryption.
• Overview
• Configuring the FortiGate unit
• Configuring the Windows PC
• Troubleshooting
Overview
The topology of a VPN for Microsoft Windows dialup clients is very similar to that for
FortiClient Endpoint Security clients.
Figure 136: Example FortiGate VPN configuration with Microsoft clients
t
lien
ote C
R em
17 Por
2.2 t 1
0.1
20 N
.1 41 LA /24
ice 1.0
lien
t Off 1.10
10 Por 1
te C .11 t 2 10.
mo .10
Re 1.1
00
_1 H .1
ate T 1.
10
iG T 1
ort P 0
/H 1.
T 12
F
T 0
P
D 11
S
10
N .1
S 0
.
S .
er 16
ve 0
F 11
r
10
T .1
P 0
.
S 1.
er 1
ve 0
r
S .1
am 1
7
10
ba 10
S .1
.
er 80
ve
1
For users, the difference is only that instead of installing and using the FortiClient
application, they configure a network connection using the software built into their
operating system. Starting in FortiOS 4.0 MR2, you can configure a FortiGate unit to work
with unmodified Microsoft VPN client software.

01-420-99686-20101026 1105
Configuring the FortiGate unit L2TP and IPsec (Microsoft VPN) configurations
Configuring the FortiGate unit

To configure the FortiGate unit, you need to:
• Configure L2TP users and a firewall user group.
• Configure the L2TP VPN, including the IP address range it assigns to clients.
• Configure an IPsec VPN with encryption and authentication settings that match the
Microsoft VPN client.
• Configure firewall policies.
Configuring users and user group

Remote users must be authenticated before they can request services and/or access
network resources through the VPN. The authentication process can use a password
defined on the FortiGate unit or an established external authentication mechanism such
as RADIUS or LDAP.
Creating user accounts

You need to create user accounts and then add these users to a firewall user group to be
used for L2TP authentication. The Microsoft VPN client can automatically send the user’s
Window network logon credentials. You might want to use these for their L2TP user name
and password.
To create a user account - web-based manager

1 Go to User > Local > Local and select Create New.
2 Enter the User Name.
• Select Password and enter the user’s assigned password.
• Select LDAP, RADIUS, or TACACS+ and select the authentication server from the
list. The authentication server must be already configured on the FortiGate unit.
4 Select OK.
To create a user account - CLI

If you want to create a user account, for example user1 with the password “123_user”, you
would enter:
config user local
edit user1
set type password
set passwd "123_user"
set status enable
end
Creating a user group

When clients connect using the L2TP-over-IPsec VPN, the FortiGate unit checks their
credentials against the user group you specify for L2TP authentication. You need to create
a firewall user group to use for this purpose.
To create a user group - web-based manager

1 Go to User > User Group > User Group, select Create New, and enter the following
information:

1106 01-420-99686-20101026
L2TP and IPsec (Microsoft VPN) configurations Configuring the FortiGate unit
Name Type or edit the user group name (for example, L2TP_group).
Type Select Firewall.
Available The list of Local users, RADIUS servers, LDAP servers, TACACS+ servers,
Users/Groups or PKI users that can be added to the user group. To add a member to this
list, select the name and then select the right arrow button.
Members The list of Local users, RADIUS servers, LDAP servers, TACACS+ servers,
or PKI users that belong to the user group. To remove a member, select the
name and then select the left arrow button.
2 Select OK.
To create a user group - CLI

To create the user group L2TP_group and add members User_1, User_2, and User_3,
you would enter:
config user group
edit L2TP_group
set member User_1 User_2 User_3
end
Configuring L2TP
You can configure L2TP settings only in the CLI. As well as enabling L2TP, you set the
range of IP address values that are assigned to L2TP clients and specify the user group
that can access the VPN. For example, to allow access to users in the L2TP_group and
assign them addresses in the range 192.168.0.50 to 192.168.0.59, you would enter
config vpn l2tp
set sip 192.168.0.50
set eip 192.168.0.59
set status enable
set usrgrp "L2TP_group"
end
One of the firewall policies for the L2TP over IPsec VPN uses the client address range, so
you need also need to create a firewall address for that range. For example,
edit L2TPclients
set type iprange
set end-ip 192.168.6.88
end
Alternatively, you could define this range in the web-based manager.
Configuring IPsec
The Microsoft VPN client uses IPsec for encryption. The configuration needed on the
FortiGate unit is substantially the same as for any other IPsec VPN except that
• transport mode is used instead of tunnel mode
• the encryption and authentication proposals must be compatible with the Microsoft
client
L2TP over IPsec is supported on the FortiGate unit using policy-based, not route-based
configurations.

01-420-99686-20101026 1107
Configuring phase 1 - web-based manager

1 Go to VPN > IPsec > Auto Key (IKE) and select Create Phase 1.
Name Enter a name for this VPN, dialup_p1 for example.

Local Interface Select the network interface that connects to the Internet. For
example, port1.
Pre-shared Key Enter the preshared key. This key must also be entered in the
Microsoft VPN client.
Advanced Select Advanced to enter the following information.
Enable IPsec Interface This must not be selected.
Mode
P1 Proposal Enter the following Encryption/Authentication pairs:
AES256-MD5, 3DES-SHA1, AES192-SHA1
DH Group 2
NAT Traversal Enable
Leave other settings at default values.
Configuring phase 1 - CLI

To create a phase 1 configuration called dialup_p1 on a FortiGate unit that has port1
connected to the Internet, you would enter:
edit dialup_p1
set type dynamic
set interface port1
set mode main
set psksecret ********
set proposal aes256-md5 3des-sha1 aes192-sha1
set dhgrp 2
set dpd enable
end
Configuring phase 2 - web-based manager

Name Enter a name for this phase 2 configuration.

Phase 1 Select the name of the phase 1 configuration.
Advanced Select Advanced to enter the following information.
P2 Proposal Enter the following Encryption/Authentication pairs:
AES256-MD5, 3DES-SHA1, AES192-SHA1
Enable replay detection Enable
Enable perfect forward Disable
secrecy (PFS)

1108 01-420-99686-20101026
L2TP and IPsec (Microsoft VPN) configurations Configuring the FortiGate unit
Keylife 3600 seconds

3 Make this a transport-mode VPN. You must use the CLI to do this. If your phase 2
name is dialup_p2, you would enter:
edit dialup_p2
set encapsulation transport-mode
end
Configuring phase 2 - CLI

To configure a phase 2 to work with your phase_1 configuration, you would enter:
edit dialup_p2
set phase1name dialup_p1
set proposal aes256-md5 3des-sha1 aes192-sha1
set replay enable
set pfs disable
set keylifeseconds 3600
end

The firewall policies required for L2TP over IPsec VPN are:
• an IPSEC policy, as you would create for any policy-based IPsec VPN
• a regular ACCEPT policy to allow traffic from the L2TP clients to access the protected
network
Configuring the IPSEC firewall policy - web-based manager

Source Select the interface that connects to the private network behind this
Interface/Zone FortiGate unit.
Source Address all
Destination Select the FortiGate unit’s public interface.
Interface/Zone
Action IPSEC
VPN Tunnel Select the name of the phase 1 configuration that you created. For
example, dialup_p1. See “Configuring IPsec” on page 1107.
Allow inbound Enable
Allow outbound Enable
UTM Optional settings for UTM features.

01-420-99686-20101026 1109
Configuring the IPSEC firewall policy - CLI

If your VPN tunnel (phase 1) is called dialup_p1, your protected network is on port2, and
your public interface is port1, you would enter:
edit 0
set srcintf port2
set dstintf port1
set srcaddr all
set dstaddr all
set action ipsec
set schedule always
set service ANY
set inbound enable
set outbound enable
set vpntunnel dialup_p1
end
Configuring the ACCEPT firewall policy - web-based manager

Source Select the FortiGate unit’s public interface.

Interface/Zone
Source Address Select the firewall address that you defined for the L2TP clients.
Destination Select the interface that connects to the private network behind this
Interface/Zone FortiGate unit.
Action ACCEPT
UTM Optionally, select UTM feature profiles.
Configuring the ACCEPT firewall policy - CLI

If your public interface is port1, your protected network is on port2, and L2TPclients is the
address range that L2TP clients use, you would enter:
edit 0
set srcintf port1
set dstintf port2
set srcaddr L2TPclients
set dstaddr all
set action accept
set schedule always
set service ANY
end

1110 01-420-99686-20101026
L2TP and IPsec (Microsoft VPN) configurations Configuring the Windows PC
Configuring the Windows PC

Configuration of the Windows PC for a VPN connection to the FortiGate unit consists of
the following:
• In Network Connections, configure a Virtual Private Network connection to the
FortiGate unit.
• Ensure that the IPSEC service is running.
• Ensure that IPsec has not been disabled for the VPN client. It may have been disabled
to make the Microsoft VPN compatible with an earlier version of FortiOS.
The instructions in this section are based on Windows XP SP3. Other versions of
Windows may vary slightly.
To configure the network connection

1 Open Network Connections.
This is available through the Control Panel.
2 Double-click New Connection Wizard.
3 Select Next.
4 Select Connect to the network at my workplace and then select Next.
5 Select Virtual Private Network connection and then select Next.
6 In the Company Name field, enter a name for the connection and then select Next.
7 Select Do not dial the initial connection and then select Next.
8 Enter the public IP address or FQDN of the FortiGate unit and then select Next.
9 Optionally, select Add a shortcut to this connection to my desktop.
10 Select Finish.
The Connect dialog opens on the desktop.
11 Select Properties and then select the Security tab.
12 Select IPSec Settings.
13 Select Use pre-shared key for authentication, enter the preshared key that you
configured for your VPN, and select OK.
14 Select OK.
To check that the IPSEC service is running

1 Open Administrative Tools.
This is available through the Control Panel.
2 Double-click Services.
3 Look for IPSEC Services. The Startup Type should be Automatic and Status should be
Started. If needed, double-click IPSEC Services to change the settings.
To check that IPsec has not been disabled

1 Select Start > Run.
2 Enter regedit and select OK.
3 Find the Registry key
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RasMan\Parameters
4 If there is a ProhibitIPSec value, it must be set to 0.

01-420-99686-20101026 1111
Troubleshooting L2TP and IPsec (Microsoft VPN) configurations
Troubleshooting
This section describes some checks and tools you can use to resolve issues with L2TP-
over-IPsec VPNs.
Quick checks
Here is a list of common L2TP over IPsec VPN problems and the likely solutions.
Problem What to check

IPsec tunnel does not come up. Check the logs to determine whether the failure is in
Phase 1 or Phase 2.
Check the settings, including encapsulation setting, which
must be transport-mode.
Check the user password.
Confirm that the user is a member of the user group
assigned to L2TP.
On the Windows PC, check that the IPsec service is running
and has not been disabled. See “Configuring the Windows
PC” on page 1111.
Tunnel connects, but there is no Did you create an ACCEPT firewall policy from the public
communication. network to the protected network for the L2TP clients? See
“Configuring firewall policies” on page 1109.
Setting up logging
To configure FortiGate logging for L2TP over IPsec
2 Select the Enable check box.
3 Select the L2TP/PPTP/PPPoE service event and IPsec negotiation event check boxes.
4 Select Apply.
To configure FortiGate logging level

2 Select the Local Logging & Archiving check box.
3 Select the Memory check box.
4 Set Minimum log level to Information.
5 Optionally, enable and configure disk logging.
6 Select Apply.
To view FortiGate logs

1 Go to Log&Report > Log Access > Event.
2 Select the Memory log type.
3 After each attempt to start the L2TP over IPsec VPN, select Refresh to view any
logged events.
Understanding the log messages

Successful startup of an L2TP over IPsec VPN follows a well-defined sequence. If you
compare your logs to the sequence shown in Table 71, you will be able to determine at
what stage your configuration is failing.

1112 01-420-99686-20101026
L2TP and IPsec (Microsoft VPN) configurations Troubleshooting
Table 71: Typical sequence of log messages for L2TP over IPsec VPN connection startup
ID Sub Type Action Message

1 37127 ipsec negotiate progress IPsec phase 1
6 37133 ipsec install_sa install IPsec SA
7 37139 ipsec phase2-up IPsec phase 2 status change
8 37138 ipsec tunnel-up IPsec connection status change
10 37122 ipsec negotiate negotiate IPsec phase 2
11 31008 ppp connect Client 172.20.120.151 control connection started
(id 743), assigned ip 192.168.6.85
12 29013 ppp
13 29002 ppp auth_success User 'user1' using l2tp with authentication protocol
MSCHAP_V2, succeeded
14 31101 ppp tunnel-up L2TP tunnel established
Note: This table lists messages in top down chronological order. In the web-based
manager log viewer, you need to read the messages from the bottom up. The newest
message appears at the top of that list.
In Table 71, messages 1 through 4 show the IKE phase 1 negotiation stages that result in
the creation of the Security Association (SA) shown in message 6. Phase 2 negotiation in
messages 5, 9, 10 produce the tunnel-up condition reported in message 8.
With IPsec communication established, the L2TP connection is established (message 11),
the pppd daemon starts (message 12), the user is authenticated (message 13), and the
L2TP tunnel is now ready to use.
Using the FortiGate unit debug commands

To view debug output for IKE and L2TP
1 Start an SSH or Telnet session to your FortiGate unit.
2 Enter the following CLI commands
diagnose debug application ike -1
diagnose debug application l2tp -1
diagnose debug enable
3 Attempt to use the VPN and note the debug output in the SSH or Telnet session.
4 Enter the following command to reset debug settings to default:
diagnose debug reset
To use the packet sniffer

1 Start an SSH or Telnet session to your FortiGate unit.
2 Enter the following CLI command
diagnose sniffer packet any icmp 4
3 Attempt to use the VPN and note the debug output.
4 Enter Ctrl-C to end sniffer operation.

01-420-99686-20101026 1113
Typical L2TP over IPsec session startup log entries - raw format
2010-01-11 16:39:58 log_id=0101037127 type=event subtype=ipsec pri=notice vd="root"
msg="progress IPsec phase 1" action="negotiate" rem_ip=172.20.120.151
loc_ip=172.20.120.141 rem_port=500 loc_port=500 out_intf="port1"
cookies="5f6da1c0e4bbf680/d6a1009eb1dde780" user="N/A" group="N/A"
xauth_user="N/A" xauth_group="N/A" vpn_tunnel="dialup_p1" status=success
init=remote mode=main dir=outbound stage=1 role=responder result=OK
init=remote mode=main dir=outbound stage=2 role=responder result=OK
init=remote mode=main dir=inbound stage=3 role=responder result=DONE
xauth_user="N/A" xauth_group="N/A" vpn_tunnel="dialup_p1_0" status=success
init=remote mode=main dir=outbound stage=3 role=responder result=DONE
init=remote mode=quick dir=outbound stage=1 role=responder result=OK
msg="install IPsec SA" action="install_sa" rem_ip=172.20.120.151
xauth_user="N/A" xauth_group="N/A" vpn_tunnel="dialup_p1_0" role=responder
in_spi=61100fe2 out_spi=bd70fca1
msg="IPsec phase 2 status change" action="phase2-up" rem_ip=172.20.120.151
xauth_user="N/A" xauth_group="N/A" vpn_tunnel="dialup_p1_0"
phase2_name=dialup_p2
msg="IPsec connection status change" action="tunnel-up" rem_ip=172.20.120.151
xauth_user="N/A" xauth_group="N/A" vpn_tunnel="dialup_p1_0"
tunnel_ip=172.20.120.151 tunnel_id=1552003005 tunnel_type=ipsec duration=0 sent=0
rcvd=0 next_stat=0 tunnel=dialup_p1_0

1114 01-420-99686-20101026
L2TP and IPsec (Microsoft VPN) configurations Troubleshooting

init=remote mode=quick dir=inbound stage=2 role=responder result=DONE
msg="negotiate IPsec phase 2" action="negotiate" rem_ip=172.20.120.151
role=responder esp_transform=ESP_3DES esp_auth=HMAC_SHA1
2010-01-11 16:39:58 log_id=0103031008 type=event subtype=ppp vd=root
pri=information action=connect status=success msg="Client 172.20.120.151 control
connection started (id 805), assigned ip 192.168.6.85"
2010-01-11 16:39:58 log_id=0103029013 type=event subtype=ppp vd=root pri=notice
pppd is started
2010-01-11 16:39:58 log_id=0103029002 type=event subtype=ppp vd=root pri=notice
user="user1" local=172.20.120.141 remote=172.20.120.151 assigned=192.168.6.85
action=auth_success msg="User 'user1' using l2tp with authentication protocol
MSCHAP_V2, succeeded"
2010-01-11 16:39:58 log_id=0103031101 type=event subtype=ppp vd=root
pri=information action=tunnel-up tunnel_id=1645784497 tunnel_type=l2tp
remote_ip=172.20.120.151 tunnel_ip=192.168.6.85 user="user1" group="L2TPusers"
msg="L2TP tunnel established"

01-420-99686-20101026 1115

1116 01-420-99686-20101026
GRE over IPsec (Cisco VPN)
configurations
This section describes how to configure a FortiGate VPN that is compatible with Cisco-
style VPNs that use GRE in an IPsec tunnel.
• Overview
• Configuring the Cisco router
• Troubleshooting
Overview
Cisco products that include VPN support often use Generic Routing Encapsulation (GRE)
protocol tunnel over IPsec encryption. This chapter describes how to configure a
FortiGate unit to work with this type of Cisco VPN.
Cisco VPNs can use either transport mode or tunnel mode IPsec. Before FortiOS 4.0
MR2, the FortiGate unit was compatible only with tunnel mode IPsec.
Figure 137: Example FortiGate to Cisco GRE-over-IPsec VPN
1 Cis
te .14
iGa rt 1 20 co
ort Po .20.1 13 rou
F 17 2 8.5.1 ter
.16
192
00
rt 2 1.1
Po 1.10
1
10.
10 LAN 10 LAN
.11 -1 .21 -2
.10 .10
1.0 1.0
/24 /24
In this example, users on LAN-1 are provided access to LAN-2.

01-420-99686-20101026 1117
Configuring the FortiGate unit GRE over IPsec (Cisco VPN) configurations

There are several steps to the GRE-over-IPsec configuration:
• Enable overlapping subnets. This is needed because the IPsec and GRE tunnels will
use the same addresses.
• Configure a route-based IPsec VPN on the external interface.
• Configure a GRE tunnel on the virtual IPsec interface. Set its local gateway and remote
gateway addresses to match the local and remote gateways of the IPsec tunnel.
• Configure firewall policies to allow traffic to pass in both directions between the GRE
virtual interface and the IPsec virtual interface.
• Configure firewall policies to allow traffic to pass in both directions between the
protected network interface and the GRE virtual interface.
• Configure a static route to direct traffic destined for the network behind the Cisco router
into the GRE-over-IPsec tunnel.
Enabling overlapping subnets

By default, each FortiGate unit network interface must be on a separate network. The
configuration described in this chapter assigns an IPsec tunnel end point and the external
interface to the same network. Enable subnet overlap as follows:
set allow-subnet-overlap enable
end
Configuring the IPsec VPN

A route-based VPN is required. It must use encryption and authentication algorithms
compatible with the Cisco equipment to which it connects. In this chapter, preshared key
authentication is shown.
To configure the IPsec VPN - web-based manager

1 Define the phase 1 configuration needed to establish a secure connection with the
remote Cisco device. Enter these settings in particular:

1118 01-420-99686-20101026
GRE over IPsec (Cisco VPN) configurations Configuring the FortiGate unit
Name Enter a name to identify the VPN tunnel, tocisco for example. This
is the name of the virtual IPsec interface. It appears in phase 2
IP Address Enter the IP address of the Cisco device public interface. For
example, 192.168.5.113
Local Interface Select the FortiGate unit’s public interface. For example,
172.20.120.141
Pre-shared Key Enter the preshared key. It must match the preshared key on the
Cisco device.
Advanced Select the Advanced button to see the following settings.
Enable IPsec Interface Enable.
Mode
P1 Proposal 3DES-MD5
At least one proposal must match the settings on the Cisco unit.
For more information about these settings, see “Auto Key phase 1 parameters” on
page 1135.
For compatibility with the Cisco router, Quick Mode Selectors must be entered, which
includes specifying protocol 47, the GRE protocol. Enter these settings in particular:

Phase 1 Select the name of the phase 1 configuration that you defined in
Step 1.
Advanced Select Advanced to view the following fields.
P2 Proposal 3DES-MD5
At least one proposal must match the settings on the Cisco unit.
Quick Mode Selector
Source Address Enter the GRE local tunnel end IP address.
For example 172.20.120.141
Source Port 0
Destination Address Enter the GRE remote tunnel end IP address.
For example 192.168.5.113
Destination Port 0
Protocol 47
For more information about these settings, see “Phase 2 parameters” on page 1151.
3 If the Cisco device is configured to use transport mode IPsec, you need to use
transport mode on the FortiGate VPN. You can configure this only in the CLI. In your
phase 2 configuration, set encapsulation to transport-mode (default is
tunnel-mode) as follows:
config vpn phase2-interface
edit to_cisco_p2
end

01-420-99686-20101026 1119
To configure the IPsec VPN - CLI

edit tocisco
set interface port1
set psksecret xxxxxxxxxxxxxxxx
end
edit tocisco_p2
set phase1name "tocisco"
set encapsulation tunnel-mode // if tunnel mode
set encapsulation transport-mode // if transport mode
set protocol 47
set src-addr-type ip
set dst-start-ip 192.168.5.113
set src-start-ip 172.20.120.141
end
Adding IPsec tunnel end addresses

The Cisco configuration requires an address for its end of the IPsec tunnel. The addresses
are set to match the GRE gateway addresses. Use the CLI to set the addresses, like this:
edit tocisco
set ip 172.20.120.141 255.255.255.255
set remote-ip 192.168.5.113
end
Configuring the GRE tunnel

The GRE tunnel runs between the virtual IPsec public interface on the FortiGate unit and
the Cisco router. You must use the CLI to configure a GRE tunnel. In the example, you
would enter:
config system gre-tunnel
edit gre1
set interface tocisco
set local-gw 172.20.120.141
end
interface is the virtual IPsec interface, local-gw is the FortiGate unit public IP
address, and remote-gw is the remote Cisco device public IP address
Adding GRE tunnel end addresses

You will also need to add tunnel end addresses. The Cisco router configuration requires
an address for its end of the GRE tunnel. Using the CLI, enter tunnel end addresses that
are not used elsewhere on the FortiGate unit, like this:
edit gre1
set ip 10.0.1.1 255.255.255.255
set remote-ip 10.0.1.2
end

1120 01-420-99686-20101026
GRE over IPsec (Cisco VPN) configurations Configuring the FortiGate unit

Two sets of firewall policies are required:
• policies to allow traffic to pass in both directions between the GRE virtual interface and
the IPsec virtual interface.
• policies to allow traffic to pass in both directions between the protected network
interface and the GRE virtual interface.
To configure firewall policies - web-based manager

1 Define an ACCEPT firewall policy to permit communications between the protected
network and the GRE tunnel:
Destination Interface/Zone Select the GRE tunnel virtual interface you configured.
Action ACCEPT
NAT Disable.
2 To permit the remote client to initiate communication, you need to define a firewall
policy for communication in that direction:
Source Interface/Zone Select the GRE tunnel virtual interface you configured.
Destination Interface/Zone Select the interface that connects to the private network behind
Action ACCEPT.
NAT Disable.
3 Define a pair of ACCEPT firewall policies to permit traffic to flow between the GRE
virtual interface and the IPsec virtual interface:
Source Interface/Zone Select the GRE virtual interface. See “Configuring the GRE
tunnel” on page 1120.
Destination Interface/Zone Select the virtual IPsec interface you created. See “Configuring
the IPsec VPN” on page 1118.
Action ACCEPT.
NAT Disable.
Source Interface/Zone Select the virtual IPsec interface you created. See “Configuring
the IPsec VPN” on page 1118.
Destination Interface/Zone Select the GRE virtual interface. See “Configuring the GRE
tunnel” on page 1120.
NAT Disable.

01-420-99686-20101026 1121
To configure firewall policies - CLI

edit 1 // LAN to GRE tunnel
set srcintf port2
set dstintf gre1
set srcaddr all
set dstaddr all
set action accept
set schedule always
set service ANY
next
edit 2 // GRE tunnel to LAN
set srcintf gre1
set dstintf port2
set srcaddr all
set dstaddr all
set action accept
set schedule always
set service ANY
next
edit 3 // GRE tunnel to IPsec interface
set srcintf "gre1"
set dstintf "tocisco"
set srcaddr "all"
set dstaddr "all"
set action accept
set service "ANY"
next
edit 4 // IPsec interface to GRE tunnel
set srcintf "tocisco"
set dstintf "gre1"
set srcaddr "all"
set dstaddr "all"
set action accept
set service "ANY"
end
Configuring routing
Traffic destined for the network behind the Cisco router must be routed to the GRE tunnel.
To do this, create a static route as follows:
Destination IP/Mask Enter the IP address and netmask for the network behind the Cisco
router. For example 10.21.101.0 255.255.255.0
Device Select the GRE virtual interface.
Distance Leave setting at default value.
In the CLI, using the example values, you would enter

edit 0
set device gre1
set dst 10.21.101.0 255.255.255.0

1122 01-420-99686-20101026
GRE over IPsec (Cisco VPN) configurations Configuring the Cisco router
end
Configuring the Cisco router

Using Cisco IOS, you would configure the Cisco router as follows, using the addresses
from the example:
config ter
crypto ipsec transform-set myset esp-3des esp-md5-hmac
no mode
exit
no ip access-list extended tunnel
ip access-list extended tunnel
permit gre host 192.168.5.113 host 172.20.120.141
exit
interface Tunnel1
ip address 10.0.1.2 255.255.255.0
tunnel source 192.168.5.113
tunnel destination 172.20.120.141
!
ip route 10.11.101.0 255.255.255.0 Tunnel1
end
clea crypto sa
clea crypto isakmp
For transport mode, change no mode to mode transport.
This is only the portion of the Cisco router configuration that applies to the GRE-over-
IPsec tunnel. For more information, refer to the Cisco documentation.
Troubleshooting
This section describes some checks and tools you can use to resolve issues with the
GRE-over-IPsec VPN.
Quick checks
Here is a list of common problems and what to verify.
Problem What to check

No communication with remote Use the execute ping command to ping the Cisco
network. device public interface.
Use the FortiGate VPN Monitor page to see whether the
IPsec tunnel is up or can be brought up.
IPsec tunnel does not come up. Check the logs to determine whether the failure is in
Phase 1 or Phase 2.
Check that the encryption and authentication settings
match those on the Cisco device.
Check the encapsulation setting: tunnel-mode or
transport-mode. Both devices must use the same mode.
Tunnel connects, but there is no Check the firewall policies. See “Configuring firewall
communication. policies” on page 1121.
Check routing. See “Configuring routing” on page 1122.

01-420-99686-20101026 1123
Troubleshooting GRE over IPsec (Cisco VPN) configurations
Setting up logging
To configure FortiGate logging for IPsec
2 Select the Enable check box.
3 Select the IPsec negotiation event check box.
4 Select Apply.
To configure FortiGate logging level

2 Select the Local Logging & Archiving check box.
3 Select the Memory check box.
4 Set Minimum log level to Information.
5 Optionally, enable and configure disk logging.
6 Select Apply.
To view FortiGate logs

1 Go to Log & Report > Log Access > Event.
2 Select the Memory log type.
3 Select Refresh to view any logged events.
Understanding the log messages

Successful startup of an IPsec VPN follows a well-defined sequence. If you compare your
logs to the sequence shown in Table 72, you will be able to determine at what stage your
configuration is failing.
Table 72: Typical sequence of log messages for IPsec VPN connection startup
ID Sub Type Action Message

6 37133 ipsec install_sa install IPsec SA
7 37139 ipsec phase2-up IPsec phase 2 status change
8 37138 ipsec tunnel-up IPsec connection status change
Note: This table lists messages in top down chronological order. In the web-based
manager log viewer, you need to read the messages from the bottom up. The newest
message appears at the top of that list.
Using diagnostic commands

There are some diagnostic commands that can provide useful information.
To use the packet sniffer

1 Enter the following CLI command:

1124 01-420-99686-20101026
GRE over IPsec (Cisco VPN) configurations Troubleshooting
diag sniff packet any icmp 4

2 Ping an address on the network behind the FortiGate unit from the network behind the
Cisco router.
The output should show packets coming in from the GRE interface going out of the
interface that connects to the protected network (LAN) and vice versa. For example:
114.124303 gre1 in 10.0.1.2 -> 10.11.101.10: icmp: echo request
114.124367 port2 out 10.0.1.2 -> 10.11.101.10: icmp: echo request
114.124466 port2 in 10.11.101.10 -> 10.0.1.2: icmp: echo reply
114.124476 gre1 out 10.11.101.10 -> 10.0.1.2: icmp: echo reply
3 Enter CTRL-C to stop the sniffer.
To view debug output for IKE

1 Enter the following CLI commands
diagnose debug application ike -1
diagnose debug enable
2 Attempt to use the VPN and note the debug output.
3 Enter the following command to reset debug settings to default:
diagnose debug reset

01-420-99686-20101026 1125
Troubleshooting GRE over IPsec (Cisco VPN) configurations

1126 01-420-99686-20101026
Protecting OSPF with IPsec
For enhanced security, OSPF dynamic routing can be carried over IPsec VPN links.
• Overview
• OSPF over IPsec configuration
• Creating a redundant configuration
Overview
This chapter shows an example of OSPF routing conducted over an IPsec tunnel between
two FortiGate units. The network shown in Figure 138 is a single OSPF area. FortiGate_1
is an Area border router that advertises a static route to 10.22.10.0/24 in OSPF.
FortiGate_2 advertises its local LAN as an OSPF internal route.
Figure 138: OSPF over an IPsec VPN tunnel
/24
.1 0.0
10.22
19
2.1 P
1 .141 68 ort Fo
rtiG
te_ rt 2 20 .0. 2
iGa Po .20.1 13
1 ate
F ort 172
_2
Po
rt 1
1 Port3 Port3
P ort
10.1.1.1 VPN tunnel 10.1.1.2
“tunnel_wan1”
OSPF cost 10
L
L 10 ocal
10 ocal 10.1.2.1 VPN tunnel 10.1.2.2 .31 LA
.21 LA “tunnel_wan2” .10 N
.10 N 1.0
1.0 OSPF cost 200 /24
/24
The section “OSPF over IPsec configuration” describes the configuration with only one
IPsec VPN tunnel, tunnel_wan1. Then, the section “Creating a redundant configuration”
on page 1133 describes how you can add a second tunnel to provide a redundant backup
path. This is shown in Figure 138 as VPN tunnel “tunnel_wan2”.
Only the parts of the configuration concerned with creating the IPsec tunnel and
integrating it into the OSPF network are described. It is assumed that firewall policies are
already in place to allow traffic to flow between the interfaces on each FortiGate unit.

01-420-99686-20101026 1127
OSPF over IPsec configuration Protecting OSPF with IPsec
OSPF over IPsec configuration

There are several steps to the OSPF-over-IPsec configuration:
• Configure a route-based IPsec VPN on an external interface. It will connect to a
corresponding interface on the other FortiGate unit. Define the two tunnel-end
addresses.
• Configure a static route to the other FortiGate unit.
• Configure the tunnel network as part of the OSPF network and define the virtual IPsec
interface as an OSPF interface.
This section describes the configuration with only one VPN, tunnel_wan1. The other VPN
is added in the section “Creating a redundant configuration” on page 1133.
Configuring the IPsec VPN

A route-based VPN is required. In this chapter, preshared key authentication is shown.
Certificate authentication is also possible. Both FortiGate units need this configuration.
To configure Phase 1
1 Define the phase 1 configuration needed to establish a secure connection with the
other FortiGate unit. For more information, see “Auto Key phase 1 parameters” on
Name Enter a name to identify the VPN tunnel, tunnel_wan1 for

example. This becomes the name of the virtual IPsec interface.
IP Address Enter the IP address of the other FortiGate unit’s public (Port 2)
interface.
Local Interface Select this FortiGate unit’s public (Port 2) interface.
Pre-shared Key Enter the preshared key. It must match the preshared key on the
other FortiGate unit.
Advanced Select Advanced.
Enable IPsec Interface Enable
Mode
To assign the tunnel end IP addresses

1 Go to System > Network > Interface and select the Edit icon for the virtual IPsec
interface that you just created on Port 2.
2 In the IP and Remote IP fields, enter the following tunnel end addresses:
FortiGate_1 FortiGate_2
IP 10.1.1.1 10.1.1.2
Remote_IP 10.1.1.2 10.1.1.1
These addresses are from a network that is not used for anything else.

1128 01-420-99686-20101026
Protecting OSPF with IPsec OSPF over IPsec configuration
To configure Phase 2
For more information, see “Phase 2 parameters” on page 1151. Enter these settings in
particular:
Name Enter a name to identify this phase 2 configuration, twan1_p2, for example.
Phase 1 Select the name of the phase 1 configuration that you defined in Step 1,
tunnel_wan1 for example.
Configuring static routing

You need to define the route for traffic leaving the external interface. Go to Router > Static
> Static Route, select Create New, and enter the following information.
Destination IP/Mask Leave as 0.0.0.0 0.0.0.0.

Device Select the external interface.
Gateway Enter the IP address of the next hop router.
Distance Leave setting at default value.
Configuring OSPF
This section does not attempt to explain OSPF router configuration. It focusses on the
integration of the IPsec tunnel into the OSPF network. This is accomplished by assigning
the tunnel as an OSPF interface, creating an OSPF route to the other FortiGate unit.
This configuration uses loopback interfaces to ease OSPF troubleshooting. The OSPF
router ID is set to the loopback interface address.The loopback interface ensures the
router is always up. Even though technically the router ID doesn’t have to match a valid IP
address on the FortiGate unit, having an IP that matches the router ID makes
troubleshooting a lot easier.
The two FortiGate units have slightly different configurations. FortiGate_1 is an AS border
router that advertises its static default route. FortiGate_2 advertises its local LAN as an
OSPF internal route.
Setting the router ID for each FortiGate unit to the lowest possible value is useful if you
want the FortiGate units to be the designated router (DR) for their respective ASes. This is
the router that broadcasts the updates for the AS.
Leaving the IP address on the OSPF interface at 0.0.0.0 indicates that all potential routes
will be advertised, and it will not be limited to any specific subnet. For example if this IP
address was 10.1.0.0, then only routes that match that subnet will be advertised through
this interface in OSPF.
FortiGate_1 OSPF configuration

When configuring FortiGate_1 for OSPF, the loopback interface is created, and then you
configure OSPF area networks and interfaces.
With the exception of creating the loopback interface, OSPF for this example can all be
configured in either the web-based manager or CLI.
To create the loopback interface

A loopback interface can be configured in the CLI only. For example, if the interface will
have an IP address of 10.0.0.1, you would enter:

01-420-99686-20101026 1129
edit lback1
set vdom root
set ip 10.0.0.1 255.255.255.255
set type loopback
end
The loopback addresses and corresponding router IDs on the two FortiGate units must be
different. For example, set the FortiGate 1 loopback to 10.0.0.1 and the FortiGate 2
loopback to 10.0.0.2.
To configure OSPF area, networks, and interfaces - web-based manager

1 On FortiGate_1, go to Router > Dynamic > OSPF and enter the following information to
define the router, area, and interface information.
Router ID Enter 10.0.0.1.

Select Apply before entering the remaining information.
Advanced Options
Redistribute Select the Connected and Static check boxes. Use their default metric
values.
Areas Select Create New, enter the Area and Type and then select OK.
Area 0.0.0.0
Type Regular
Interfaces
Name Enter a name for the OSPF interface, ospf_wan1 for example.
Interface Select the virtual IPsec interface, tunnel_wan1.
IP 0.0.0.0
2 For Networks, select Create New.

3 Enter the following information.
IP/Netmask 10.1.1.0/255.255.255.0.
Area 0.0.0.0

IP/Netmask 10.0.0.1/255.255.255.255
Area 0.0.0.0
6 Select Apply.
To configure OSPF area and interfaces - CLI

Your loopback interface is 10.0.0.1, your tunnel ends are on the 10.1.1.0/24 network, and
your virtual IPsec interface is named tunnel_wan1. Enter the following CLI commands:
config router ospf
set router-id 10.0.0.1
config area
edit 0.0.0.0
end
config network
edit 4
set prefix 10.1.1.0 255.255.255.0

1130 01-420-99686-20101026
Protecting OSPF with IPsec OSPF over IPsec configuration
next
edit 2
set prefix 10.0.0.1 255.255.255.255
end
config ospf-interface
edit ospf_wan1
set cost 10
set interface tunnel_wan1
set network-type point-to-point
end
config redistribute connected
set status enable
end
config redistribute static
set status enable
end
end
FortiGate_2 OSPF configuration

When configuring FortiGate_2 for OSPF, the loopback interface is created, and then you
configure OSPF area networks and interfaces.
Configuring FortiGate_2 differs from FortiGate_1 in that three interfaces are defined
instead of two. The third interface is the local LAN that will be advertised into OSPF.
With the exception of creating the loopback interface, OSPF for this example can all be
configured in either the web-based manager or CLI.
To create the loopback interface

A loopback interface can be configured in the CLI only. For example, if the interface will
have an IP address of 10.0.0.2, you would enter:
edit lback1
set vdom root
set ip 10.0.0.2 255.255.255.255
set type loopback
end
The loopback addresses on the two FortiGate units must be different. For example, set the
FortiGate 1 loopback to 10.0.0.1 and the FortiGate 2 loopback to 10.0.0.2.
To configure OSPF area and interfaces - web-based manager

1 On FortiGate_2, go to Router > Dynamic > OSPF.
2 For Router ID, enter 10.0.0.2.
Router ID 10.0.0.2
Areas Select Create New, enter the Area and Type and then select OK.
Area 0.0.0.0
Type Regular

01-420-99686-20101026 1131
Interfaces
Name Enter a name for the OSPF interface, ospf_wan1 for example.
Interface Select the virtual IPsec interface, tunnel_wan1
IP 0.0.0.0
4 Enter the following information for the loopback interface:
IP/Netmask 10.0.0.2/255.255.255.255
Area 0.0.0.0

6 Enter the following information for the tunnel interface:
IP/Netmask 10.1.1.0/255.255.255.0
Area 0.0.0.0

8 Enter the following information for the local LAN interface:
IP/Netmask 10.31.101.0/255.255.255.0
Area 0.0.0.0
9 Select Apply.
To configure OSPF area and interfaces - CLI

If for example, your loopback interface is 10.0.0.2, your tunnel ends are on the 10.1.1.0/24
network, your local LAN is 10.31.101.0/24, and your virtual IPsec interface is named
tunnel_wan1, you would enter:
config router ospf
config area
edit 0.0.0.0
end
config network
edit 1
set prefix 10.1.1.0 255.255.255.0
next
edit 2
set prefix 10.31.101.0 255.255.255.0
next
edit 2
set prefix 10.0.0.2 255.255.255.255
end
edit ospf_wan1
end
end

1132 01-420-99686-20101026
Protecting OSPF with IPsec Creating a redundant configuration
Creating a redundant configuration

You can improve the reliability of the OSPF over IPsec configuration described in the
previous section by adding a second IPsec tunnel to use if the default one goes down.
Redundancy in this case is not controlled by the IPsec VPN configuration but by the OSPF
routing protocol.
To do this you:
• Create a second route-based IPsec tunnel on a different interface and define tunnel
end addresses for it.
• Add the tunnel network as part of the OSPF network and define the virtual IPsec
interface as an additional OSPF interface.
• Set the OSPF cost for the added OSPF interface to be significantly higher than the cost
of the default route.
Adding the second IPsec tunnel

The configuration is the same as in “Configuring the IPsec VPN” on page 1128, but the
interface and addresses will be different. Ideally, the network interface you use is
connected to a different Internet service provider for added redundancy.
When adding the second tunnel to the OSPF network, choose another unused subnet for
the tunnel ends, 10.1.2.1 and 10.1.2.2 for example.
Adding the OSPF interface

OSPF uses the metric called cost when determining the best route, with lower costs being
preferred. Up to now in this example, only the default cost of 10 has been used. Cost can
be set only in the CLI.
The new IPsec tunnel will have its OSPF cost set higher than that of the default tunnel to
ensure that it is only used if the first tunnel goes down. The new tunnel could be set to a
cost of 200 compared to the default cost is 10. Such a large difference in cost will ensure
this new tunnel will only be used as a last resort.
If the new tunnel is called tunnel_wan2, you would enter the following on both FortiGate
units:
config router ospf
edit ospf_wan2
set cost 200
end
end

01-420-99686-20101026 1133
Creating a redundant configuration Protecting OSPF with IPsec

1134 01-420-99686-20101026
Auto Key phase 1 parameters
This chapter provides detailed step-by-step procedures for configuring a FortiGate unit to
accept a connection from a remote peer or dialup client. The phase 1 parameters identify
the remote peer or clients and support authentication through preshared keys or digital
certificates. You can increase access security further using peer identifiers, certificate
distinguished names, group names, or the FortiGate extended authentication (XAuth)
option for authentication purposes.
Note: The information and procedures in this section do not apply to VPN peers that
perform negotiations using manual keys. Refer to “Manual-key configurations” on
page 1091 instead.

• Overview
• Defining the tunnel ends
• Choosing main mode or aggressive mode
• Authenticating the FortiGate unit
• Authenticating remote peers and clients
• Defining IKE negotiation parameters
• Defining the remaining phase 1 options
• Using XAuth authentication
Overview
IPsec phase 1 settings define:
• the ends of the IPsec tunnel, remote and local
• whether the various phase 1 parameters are exchanged in multiple rounds with
encrypted authentication information (main mode) or in a single message with
authentication information that is not encrypted (aggressive mode)
• whether a preshared key or digital certificates will be used to authenticate the
FortiGate unit to the VPN peer or dialup client
• whether the VPN peer or dialup client is required to authenticate to the FortiGate unit.
A remote peer or dialup client can authenticate by peer ID or, if the FortiGate unit
authenticates by certificate, it can authenticate by peer certificate.
• the IKE negotiation proposals for encryption and authentication
• optional XAuth authentication, which requires the remote user to enter a user name
and password. A FortiGate VPN server can act as an XAuth server to authenticate
dialup users. A FortiGate unit that is a dialup client can also be configured as an XAuth
client to authenticate itself to the VPN server.

01-420-99686-20101026 1135
Defining the tunnel ends Auto Key phase 1 parameters
Defining the tunnel ends

To begin defining the phase 1 configuration, go to VPN > IPSEC > Auto Key (IKE) and
select Create Phase 1. Enter a descriptive name for the VPN tunnel. This is particularly
important if you will create several tunnels.
The phase 1 configuration mainly defines the ends of the IPsec tunnel. The remote end is
the remote gateway with which the FortiGate unit exchanges IPsec packets. The local end
is FortiGate interface that sends and receives IPsec packets.
The remote gateway can be:
• a static IP address
• a domain name with a dynamic IP address
• a dialup client
A statically addressed remote gateway is the simplest to configure. You specify the IP
address. Unless restricted in the firewall policy, either the remote peer or a peer on the
network behind the FortiGate unit can bring up the tunnel.
If the remote peer has a domain name and subscribes to a dynamic DNS service, you
need to specify only the domain name. The FortiGate unit performs a DNS query to
determine the appropriate IP address. Unless restricted in the firewall policy, either the
remote peer or a peer on the network behind the FortiGate unit can bring up the tunnel.
If the remote peer is a dialup client, only the dialup client can bring up the tunnel. The IP
address of the client is not known until it connects to the FortiGate unit. This configuration
is a typical way to provide a VPN for client PCs running VPN client software such as the
FortiClient Endpoint Security application.
The local end of the VPN tunnel, the Local Interface, is the FortiGate interface that sends
and receives the IPsec packets. This is usually the public interface of the FortiGate unit
that is connected to the Internet. Packets from this interface pass to the private network
through a firewall policy.
By default, the local VPN gateway is the IP address of the selected Local Interface. If you
are configuring an interface mode VPN, you can optionally specify a secondary IP address
of the Local Interface as the local gateway.
Choosing main mode or aggressive mode

The FortiGate unit and the remote peer or dialup client exchange phase 1 parameters in
either Main mode or Aggressive mode. This choice does not apply if you use IKE
version 2, which is available only for route-based configurations.
• In Main mode, the phase 1 parameters are exchanged in multiple rounds with
encrypted authentication information
• In Aggressive mode, the phase 1 parameters are exchanged in single message with
authentication information that is not encrypted.
Although Main mode is more secure, you must select Aggressive mode if there is more
than one dialup phase 1 configuration for the interface IP address, and the remote VPN
peer or client is authenticated using an identifier (local ID). Descriptions of the peer
options in this guide indicate whether Main or Aggressive mode is required.

1136 01-420-99686-20101026
Auto Key phase 1 parameters Choosing the IKE version
Choosing the IKE version

If you create a route-based VPN, you have the option of selecting the IKE version 2.
Otherwise, IKE version 1 is used.
IKEv2, defined in RFC 4306, simplifies the negotiation process that creates the security
association (SA).
If you select IKEv2:
• There is no choice in Phase 1 of Aggressive or Main mode.
• FortiOS does not support Peer Options or Local ID.
• Extended Authentication (XAUTH) is not available.
• You can select only one DH Group.
Authenticating the FortiGate unit

The FortiGate unit can authenticate itself to remote peers or dialup clients using either a
pre-shared key or an RSA Signature (certificate).
Authenticating the FortiGate unit with digital certificates

To authenticate the FortiGate unit using digital certificates, you must have the required
certificates installed on the remote peer and on the FortiGate unit. The signed server
certificate on one peer is validated by the presence of the root certificate installed on the
other peer. If you use certificates to authenticate the FortiGate unit, you can also require
the remote peers or dialup clients to authenticate using certificates.
For more information about obtaining and installing certificates, see the FortiGate
Certificate Management User Guide.
To authenticate the FortiGate unit using digital certificates

2 Create a new phase 1 configuration or edit an existing phase 1 configuration.
Name Enter a name that reflects the origination of the remote connection.
Remote Gateway Select the nature of the remote connection:
• Static IP Address
• Dialup User
• Dynamic DNS
For more information, see “Defining the tunnel ends” on page 1136.
Local Interface Select the interface that is the local end of the IPsec tunnel. For
more information, see “Defining the tunnel ends” on page 1136.

01-420-99686-20101026 1137
Authenticating the FortiGate unit Auto Key phase 1 parameters
Mode Select Main or Aggressive mode.

• In Main mode, the phase 1 parameters are exchanged in
multiple rounds with encrypted authentication information.
• In Aggressive mode, the phase 1 parameters are exchanged in
single message with authentication information that is not
encrypted.
When the remote VPN peer or client has a dynamic IP address, or
the remote VPN peer or client will be authenticated using an
identifier (local ID), you must select Aggressive mode if there is
more than one dialup phase 1 configuration for the interface IP
address.
For more information, see “Choosing main mode or aggressive
mode” on page 1136.
Authentication Method Select RSA Signature.
Certificate Name Select the name of the server certificate that the FortiGate unit will
use to authenticate itself to the remote peer or dialup client during
phase 1 negotiations. To obtain and load the required server
certificate, see the FortiGate Certificate Management User Guide.
Peer Options Peer options define the authentication requirements for remote
peers or dialup clients, not for the FortiGate unit itself. For more
information, see “Authenticating remote peers and clients” on
page 1139.
Advanced You can retain the default settings unless changes are needed to
meet your specific requirements. See “Defining IKE negotiation
4 If you are configuring authentication parameters for a dialup user group, optionally
define extended authentication (XAuth) parameters. See “Using the FortiGate unit as
an XAuth server” on page 1148.
5 Select OK.
Authenticating the FortiGate unit with a pre-shared key

The simplest way to authenticate a FortiGate unit to its remote peers or dialup clients is by
means of a pre-shared key. This is less secure than using certificates, especially if it used
alone, without requiring peer IDs or extended authentication (XAuth). Also, you need to
have a secure way to distribute the pre-shared key to the peers.
If you use pre-shared key authentication alone, all remote peers and dialup clients must
be configured with the same pre-shared key. Optionally, you can configure remote peers
and dialup clients with unique pre-shared keys. On the FortiGate unit, these are
configured in user accounts, not in the phase_1 settings. For more information, see
“Enabling VPN access using user accounts and pre-shared keys” on page 1143.
The pre-shared key must contain at least 6 printable characters and should be known only
to network administrators. For optimum protection against currently known attacks, the
key should consist of a minimum of 16 randomly chosen alphanumeric characters.
If you authenticate the FortiGate unit using a pre-shared key, you can require remote
peers or dialup clients to authenticate using peer IDs, but not client certificates.
To authenticate the FortiGate unit with a pre-shared key

2 Create a new phase 1 configuration or edit an existing phase 1 configuration.

1138 01-420-99686-20101026
Auto Key phase 1 parameters Authenticating remote peers and clients
Name Enter a name that reflects the origination of the remote

connection.
Remote Gateway Select the nature of the remote connection:
• Static IP Address.
• Dialup User.
• Dynamic DNS.
For more information, see “Defining the tunnel ends” on
page 1136.
Local Interface Select the interface that is the local end of the IPsec tunnel. For
more information, see “Defining the tunnel ends” on page 1136.
Mode Select Main or Aggressive mode.
• In Main mode, the phase 1 parameters are exchanged in
multiple rounds with encrypted authentication information.
• In Aggressive mode, the phase 1 parameters are exchanged
in single message with authentication information that is not
encrypted.
When the remote VPN peer or client has a dynamic IP address,
or the remote VPN peer or client will be authenticated using an
identifier (local ID), you must select Aggressive mode if there is
more than one dialup phase 1 configuration for the interface IP
address.
For more information, see “Choosing main mode or aggressive
mode” on page 1136.
Pre-shared Key Enter the preshared key that the FortiGate unit will use to
authenticate itself to the remote peer or dialup client during
phase 1 negotiations. You must define the same value at the
remote peer or client. The key must contain at least 6 printable
characters and should only be known by network administrators.
For optimum protection against currently known attacks, the key
should consist of a minimum of 16 randomly chosen
alphanumeric characters.
Peer options Peer options define the authentication requirements for remote
peers or dialup clients, not for the FortiGate unit itself. You can
require the use of peer IDs, but not client certificates. For more
information, see “Authenticating remote peers and clients” on
page 1139.
Advanced You can retain the default settings unless changes are needed to
meet your specific requirements. See “Defining IKE negotiation
4 If you are configuring authentication parameters for a dialup user group, optionally
define extended authentication (XAuth) parameters. See “Using the FortiGate unit as
an XAuth server” on page 1148.
5 Select OK.
Authenticating remote peers and clients

Certificates or pre-shared keys restrict who can access the VPN tunnel, but they do not
identify or authenticate the remote peers or dialup clients. You have the following options
for authentication:
• You can permit access only for remote peers or clients who use certificates that you
recognize. This is available only if the FortiGate unit authenticates using certificates.
See “Enabling VPN access for specific certificate holders” on page 1140.
• You can permit access only for remote peers or clients that have certain peer identifier
(local ID) value configured. This is available with both certificate and preshared key
authentication. See “Enabling VPN access by peer identifier” on page 1142.

01-420-99686-20101026 1139
Authenticating remote peers and clients Auto Key phase 1 parameters
• You can permit access to remote peers or dialup clients who each have a unique
preshared key. Each peer or client must have a user account on the FortiGate unit.
See “Enabling VPN access using user accounts and pre-shared keys” on page 1143.
• You can permit access to remote peers or dialup clients who each have a unique peer
ID and a unique preshared key. Each peer or client must have a user account on the
FortiGate unit. See “Enabling VPN access using user accounts and pre-shared keys”
on page 1143.
For authentication of users of the remote peer or dialup client device, see “Using XAuth
authentication” on page 1148.
Enabling VPN access for specific certificate holders

When a VPN peer or dialup client is configured to authenticate using digital certificates, it
sends the DN of its certificate to the FortiGate unit. This DN can be used to allow VPN
access for the certificate holder. That is, a FortiGate unit can be configured to deny
connections to all remote peers and dialup clients except the one having the specified DN.
Before you begin

The following procedures assume that you already have an existing phase 1 configuration
(see “Authenticating the FortiGate unit with digital certificates” on page 1137). Follow the
procedures below to add certificate-based authentication parameters to the existing
configuration.
Before you begin, you must obtain the certificate DN of the remote peer or dialup client. If
you are using the FortiClient Endpoint Security application as a dialup client, refer to
FortiClient online Help for information about how to view the certificate DN. To view the
certificate DN of a FortiGate unit, see “To view server certificate information and obtain the
local DN” on page 1141.
Use the config user peer CLI command to load the DN value into the FortiGate
configuration. For example, if a remote VPN peer uses server certificates issued by your
own organization, you would enter information similar to the following:
config user peer
edit DN_FG1000
set cn 192.168.2.160
set cn-type ipv4
end
The value that you specify to identify the entry (for example, DN_FG1000) is displayed in
the Accept this peer certificate only list in the IPsec phase 1 configuration when you return
to the web-based manager.
If the remote VPN peer has a CA-issued certificate to support a higher level of credibility,
you would enter information similar to the following:
config user peer
edit CA_FG1000
set ca CA_Cert_1
set subject FG1000_at_site1
end
The value that you specify to identify the entry (for example, CA_FG1000) is displayed in
the Accept this peer certificate only list in the IPsec phase 1 configuration when you return
to the web-based manager. For more information about these CLI commands, see the
“user” chapter of the FortiGate CLI Reference.

1140 01-420-99686-20101026
A group of certificate holders can be created based on existing user accounts for dialup
clients. To create the user accounts for dialup clients, see the “User” chapter of the
FortiGate Administration Guide. To create the certificate group afterward, use the config
user peergrp CLI command. See the “user” chapter of the FortiGate CLI Reference.
To view server certificate information and obtain the local DN

1 Go to System > Certificates > Local Certificates.
2 Note the CN value in the Subject field (for example, CN = 172.16.10.125,

CN = info@fortinet.com, or CN = www.example.com).
To view CA root certificate information and obtain the CA certificate name

1 Go to System > Certificates > CA Certificates.
2 Note the value in the Name column (for example, CA_Cert_1).
Configuring certificate authentication for a VPN

With peer certificates loaded, peer users and peer groups defined, you can configure your
VPN to authenticate users by certificate.
To enable access for a specific certificate holder or a group of certificate holders

1 At the FortiGate VPN server, go to VPN > IPSEC > Auto Key (IKE).
2 In the list of defined configurations, select the phase 1 configuration and edit it.
3 From the Authentication Method list, select RSA Signature.
4 From the Certificate Name list, select the name of the server certificate that the
FortiGate unit will use to authenticate itself to the remote peer or dialup client
5 Under Peer Options, select one of these options:
• To accept a specific certificate holder, select Accept this peer certificate only and
select the name of the certificate that belongs to the remote peer or dialup client.
The certificate DN must be added to the FortiGate configuration through CLI
commands before it can be selected here. See “Before you begin” on page 1140.
• To accept dialup clients who are members of a certificate group, select Accept this
peer certificate group only and select the name of the group. The group must be
added to the FortiGate configuration through CLI commands before it can be
selected here. See “Before you begin” on page 1140.
6 If you want the FortiGate VPN server to supply the DN of a local server certificate for
authentication purposes, select Advanced and then from the Local ID list, select the
DN of the certificate that the FortiGate VPN server is to use.
7 Select OK.

01-420-99686-20101026 1141
Authenticating remote peers and clients Auto Key phase 1 parameters
Enabling VPN access by peer identifier

Whether you use certificates or pre-shared keys to authenticate the FortiGate unit, you
can require that remote peers or clients have a particular peer ID. This adds another piece
of information that is required to gain access to the VPN. More than one
FortiGate/FortiClient dialup client may connect through the same VPN tunnel when the
dialup clients share a preshared key and assume the same identifier.
You cannot require a peer ID for a remote peer or client that uses a pre-shared key and
has a static IP address.
To authenticate remote peers or dialup clients using one peer ID

2 In the list, select a phase 1 configuration and edit its parameters.
3 Select Aggressive mode in any of the following cases:
• the FortiGate VPN server authenticates a FortiGate dialup client that uses a
dedicated tunnel
• a FortiGate unit has a dynamic IP address and subscribes to a dynamic DNS
service
• FortiGate/FortiClient dialup clients sharing the same preshared key and local ID
connect through the same VPN tunnel
4 Select Accept this peer ID and type the identifier into the corresponding field.
5 Select OK.
To assign an identifier (local ID) to a FortiGate unit

Use this procedure to assign a peer ID to a FortiGate unit that acts as a remote peer or
dialup client.
2 In the list, select a phase 1 configuration and edit its parameters.
3 Select Advanced.
4 In the Local ID field, type the identifier that the FortiGate unit will use to identify itself.
5 Set Mode to Aggressive if any of the following conditions apply:
• The FortiGate unit is a dialup client that will use a unique ID to connect to a
FortiGate dialup server through a dedicated tunnel.
• The FortiGate unit has a dynamic IP address, subscribes to a dynamic DNS service,
and will use a unique ID to connect to the remote VPN peer through a dedicated
tunnel.
• The FortiGate unit is a dialup client that shares the specified ID with multiple dialup
clients to connect to a FortiGate dialup server through the same tunnel.
6 Select OK.
To configure the FortiClient Endpoint Security application

Follow this procedure to add a peer ID to an existing FortiClient configuration:
1 Start the FortiClient Endpoint Security application.
2 Go to VPN > Connections, select the existing configuration
3 Select Advanced > Edit > Advanced.
4 Under Policy, select Config.

1142 01-420-99686-20101026
5 In the Local ID field, type the identifier that will be shared by all dialup clients. This
value must match the Accept this peer ID value that you specified previously in the
phase 1 gateway configuration on the FortiGate unit.
7 Configure all dialup clients the same way using the same preshared key and local ID.
Enabling VPN access using user accounts and pre-shared keys

You can permit access only to remote peers or dialup clients that have pre-shared keys
and/or peer IDs configured in user accounts on the FortiGate unit.
If you want two VPN peers (or a FortiGate unit and a dialup client) to accept reciprocal
connections based on peer IDs, you must enable the exchange of their identifiers when
you define the phase 1 parameters.
The following procedures assume that you already have an existing phase 1 configuration
(see “Authenticating the FortiGate unit with digital certificates” on page 1137). Follow the
procedures below to add ID checking to the existing configuration.
Before you begin, you must obtain the identifier (local ID) of the remote peer or dialup
client. If you are using the FortiClient Endpoint Security application as a dialup client, refer
to the Authenticating FortiClient Dialup Clients Technical Note to view or assign an
identifier. To assign an identifier to a FortiGate dialup client or a FortiGate unit that has a
dynamic IP address and subscribes to a dynamic DNS service, see “To assign an
identifier (local ID) to a FortiGate unit” on page 1142.
If required, a dialup user group can be created from existing user accounts for dialup
clients. To create the user accounts and user groups, see the “User” chapter of the
FortiGate Administration Guide.
The following procedure supports FortiGate/FortiClient dialup clients that use unique
preshared keys and/or peer IDs. The client must have an account on the FortiGate unit
and be a member of the dialup user group.
The dialup user group must be added to the FortiGate configuration before it can be
selected (see the “User” chapter of the FortiGate Administration Guide).
The FortiGate dialup server compares the local ID that you specify at each dialup client to
the FortiGate user-account user name. The dialup-client preshared key is compared to a
FortiGate user-account password.
To authenticate dialup clients using unique preshared keys and/or peer IDs
2 In the list, select the Edit icon of a phase 1 configuration to edit its parameters.
3 If the clients have unique peer IDs, set Mode to Aggressive.
4 Clear the Pre-shared Key field.
The user account password will be used as the preshared key.
5 Select Accept peer ID in dialup group and then select the group name from the list of
user groups.
6 Select OK.
Follow this procedure to add a unique pre-shared key and unique peer ID to an existing
FortiClient configuration.

01-420-99686-20101026 1143
Defining IKE negotiation parameters Auto Key phase 1 parameters
To configure FortiClient dialup clients - pre-shared key and peer ID

2 Go to VPN > Connections, select the existing configuration.
3 Select Advanced > Edit.
4 In the Preshared Key field, type the FortiGate password that belongs to the dialup
client (for example, 1234546).
The user account password will be used as the preshared key.
5 Select Advanced.
6 Under Policy, select Config.
7 In the Local ID field, type the FortiGate user name that you assigned previously to the
dialup client (for example, FortiC1ient1).
Configure all FortiClient dialup clients this way using unique preshared keys and local IDs.
Follow this procedure to add a unique pre-shared key to an existing FortiClient
configuration.
To configure FortiClient dialup clients - preshared key only

2 Go to VPN > Connections, select the existing configuration
3 Select Advanced > Edit.
4 In the Preshared Key field, type the user name, followed by a “+” sign, followed by the
password that you specified previously in the user account settings on the FortiGate
unit (for example, FC2+1FG6LK)
Configure all the FortiClient dialup clients this way using their unique peer ID and pre-
shared key values.
Defining IKE negotiation parameters

In phase 1, the two peers exchange keys to establish a secure communication channel
between them. As part of the phase 1 process, the two peers authenticate each other and
negotiate a way to encrypt further communications for the duration of the session. For
more information see “Authenticating remote peers and clients” on page 1139. The P1
Proposal parameters select the encryption and authentication algorithms that are used to
generate keys for protecting negotiations.
The IKE negotiation parameters determine:
• which encryption algorithms may be applied for converting messages into a form that
only the intended recipient can read
• which authentication hash may be used for creating a keyed hash from a preshared or
private key
• which Diffie-Hellman group will be used to generate a secret session key

1144 01-420-99686-20101026
Auto Key phase 1 parameters Defining IKE negotiation parameters
Phase 1 negotiations (in main mode or aggressive mode) begin as soon as a remote VPN
peer or client attempts to establish a connection with the FortiGate unit. Initially, the
remote peer or dialup client sends the FortiGate unit a list of potential cryptographic
parameters along with a session ID. The FortiGate unit compares those parameters to its
own list of advanced phase 1 parameters and responds with its choice of matching
parameters to use for authenticating and encrypting packets. The two peers handle the
exchange of encryption keys between them, and authenticate the exchange through a
preshared key or a digital signature.
Generating keys to authenticate an exchange

The FortiGate unit supports the generation of secret session keys automatically using a
Diffie-Hellman algorithm. The Keylife setting in the P1 Proposal area determines the
amount of time before the phase 1 key expires. Phase 1 negotiations are rekeyed
automatically when there is an active security association. See “Dead peer detection” on
page 1147.
Note: You can enable or disable automatic rekeying between IKE peers through the
phase1-rekey attribute of the config system global CLI command. For more
information, see the “system” chapter of the FortiGate CLI Reference.
When you use a preshared key (shared secret) to set up two-party authentication, the
remote VPN peer or client and the FortiGate unit must both be configured with the same
preshared key. Each party uses a session key derived from the Diffie-Hellman exchange
to create an authentication key, which is used to sign a known combination of inputs using
an authentication algorithm (such as HMAC-MD5 or HMAC-SHA-1). Each party signs a
different combination of inputs and the other party verifies that the same result can be
computed.
Note: When you use preshared keys to authenticate VPN peers or clients, you must
distribute matching information to all VPN peers and/or clients whenever the preshared key
changes.
As an alternative, the remote peer or dialup client and FortiGate unit can exchange digital
signatures to validate each other’s identity with respect to their public keys. In this case,
the required digital certificates must be installed on the remote peer and on the FortiGate
unit. By exchanging certificate DNs, the signed server certificate on one peer is validated
by the presence of the root certificate installed on the other peer. For more information see
the FortiGate Certificate Management User Guide.
The following procedure assumes that you already have a phase 1 definition that
describes how remote VPN peers and clients will be authenticated when they attempt to
connect to a local FortiGate unit. For information about the Local ID and XAuth options,
see “Enabling VPN access using user accounts and pre-shared keys” on page 1143 and
“Using the FortiGate unit as an XAuth server” on page 1148. Follow this procedure to add
IKE negotiation parameters to the existing definition.
Defining IKE negotiation parameters

2 In the list, select the Edit button to edit the phase 1 parameters for a particular remote
gateway.
3 Select Advanced and include appropriate entries as follows:

01-420-99686-20101026 1145
Defining the remaining phase 1 options Auto Key phase 1 parameters
P1 Proposal Select the encryption and authentication algorithms that will be used
to generate keys for protecting negotiations.
Add or delete encryption and authentication algorithms as required.
Select a minimum of one and a maximum of three combinations. The
remote peer must be configured to use at least one of the proposals
that you define.
You can select any of the following symmetric-key algorithms:
• DES-Digital Encryption Standard, a 64-bit block algorithm that
uses a 56-bit key.
• 3DES-Triple-DES, in which plain text is encrypted three times by
three keys.
• AES128-A 128-bit block algorithm that uses a 128-bit key.
You can select either of the following message digests to check the
authenticity of messages during phase 1 negotiations:
• MD5-Message Digest 5, the hash algorithm developed by RSA
Data Security.
• SHA1-Secure Hash Algorithm 1, which produces a 160-bit
message digest.
To specify a third combination, use the add button beside the fields for
the second combination.
DH Group Select one or more Diffie-Hellman groups from DH group 1, 2, and 5.
When using aggressive mode, DH groups cannot be negotiated.
• If both VPN peers (or a VPN server and its client) have static IP
addresses and use aggressive mode, select a single DH group.
The setting on the FortiGate unit must be identical to the setting on
the remote peer or dialup client.
• When the remote VPN peer or client has a dynamic IP address
and uses aggressive mode, select up to three DH groups on the
FortiGate unit and one DH group on the remote peer or dialup
client. The setting on the remote peer or dialup client must be
identical to one of the selections on the FortiGate unit.
• If the VPN peer or client employs main mode, you can select
multiple DH groups. At least one of the settings on the remote peer
or dialup client must be identical to the selections on the FortiGate
unit.
Keylife Type the amount of time (in seconds) that will be allowed to pass
before the IKE encryption key expires. When the key expires, a new
key is generated without interrupting service. The keylife can be from
120 to 172800 seconds.
Nat-traversal Enable this option if a NAT device exists between the local FortiGate
unit and the VPN peer or client. The local FortiGate unit and the VPN
peer or client must have the same NAT traversal setting (both selected
or both cleared).
Keepalive Frequency If you enabled NAT traversal, enter a keepalive frequency setting. The
value represents an interval from 0 to 900 seconds.
Dead Peer Detection Enable this option to reestablish VPN tunnels on idle connections and
clean up dead IKE peers if required.
4 Select OK.
Defining the remaining phase 1 options

Additional advanced phase 1 settings are available to ensure the smooth operation of
phase 1 negotiations:
• Nat-traversal—If outbound encrypted packets will be subjected to NAT, this option
determines whether the packet will be wrapped in a UDP IP header to protect the
encrypted packet from modification. See “NAT traversal” below.

1146 01-420-99686-20101026
Auto Key phase 1 parameters Defining the remaining phase 1 options
• Keepalive Frequency—If outbound encrypted packets will be subjected to NAT, this

option determines how frequently empty UDP packets will be sent through the NAT
device to prevent NAT address mapping from changing before the lifetime of a session
expires. See “NAT keepalive frequency” below.
• Dead Peer Detection—This option determines whether the FortiGate unit will detect
dead IKE peers and terminate a session between the time when a VPN connection
becomes idle and the phase 1 encryption key expires. See “Dead peer detection” on
page 1147.
NAT traversal
Network Address Translation (NAT) is a way to convert private IP addresses to publicly
routable Internet addresses and vise versa. When an IP packet passes through a NAT
device, the source or destination address in the IP header is modified. FortiGate units
support NAT version 1 (encapsulate on port 500 with non-IKE marker), version 3
(encapsulate on port 4500 with non-ESP marker), and compatible versions.
NAT cannot be performed on IPsec packets in ESP tunnel mode because the packets do
not contain a port number. As a result, the packets cannot be demultiplexed. To work
around this, the FortiGate unit provides a way to protect IPsec packet headers from NAT
modifications. When the Nat-traversal option is enabled, outbound encrypted packets are
wrapped inside a UDP IP header that contains a port number. This extra encapsulation
allows NAT devices to change the port number without modifying the IPsec packet directly.
To provide the extra layer of encapsulation on IPsec packets, the Nat-traversal option
must be enabled whenever a NAT device exists between two FortiGate VPN peers or a
FortiGate unit and a dialup client such as FortiClient. On the receiving end, the FortiGate
unit or FortiClient removes the extra layer of encapsulation before decrypting the packet.
NAT keepalive frequency

When a NAT device performs network address translation on a flow of packets, the NAT
device determines how long the new address will remain valid if the flow of traffic stops
(for example, the connected VPN peer may be idle). The device may reclaim and reuse a
NAT address when a connection remains idle for too long. To work around this, when you
enable NAT traversal, you can specify how often the FortiGate unit should send periodic
keepalive packets through the NAT device in order to ensure that the NAT address
mapping does not change during the lifetime of a session. The keepalive interval should
be smaller than the session lifetime value used by the NAT device.
Dead peer detection

Sometimes, due to routing issues or other difficulties, the communication link between a
FortiGate unit and a VPN peer or client may go down—packets could be lost if the
connection is left to time out on its own. The FortiGate unit provides a mechanism called
Dead Peer Detection (DPD) to prevent this situation and reestablish IKE negotiations
automatically before a connection times out: the active phase 1 security associations are
caught and renegotiated (rekeyed) before the phase 1 encryption key expires. By default,
DPD send probe messages every five seconds (see dpd-retryinterval in the FortiGate
CLI Reference).
In the web-based manager, the Dead Peer Detection option can be enabled when you
define advanced phase 1 options. The config vpn ipsec phase1 CLI command
supports additional options for specifying a retry count and a retry interval. For more
information about these CLI commands, see the FortiGate CLI Reference.

01-420-99686-20101026 1147
Using XAuth authentication Auto Key phase 1 parameters
Using XAuth authentication

Extended authentication (XAuth) increases security by requiring authentication of the user
of the remote dialup client in a separate exchange at the end of phase 1. XAuth draws on
existing FortiGate user group definitions and uses established authentication mechanisms
such as PAP, CHAP, RADIUS and LDAP to authenticate dialup clients. You can configure
a FortiGate unit to function either as an XAuth server or an XAuth client.
Using the FortiGate unit as an XAuth server

A FortiGate unit can act as an XAuth server for dialup clients. When the phase 1
negotiation completes, the FortiGate unit challenges the user for a user name and
password. It then forwards the user’s credentials to an external RADIUS or LDAP server
for verification.
If the user records on the RADIUS server have suitably configured Framed-IP-Address
fields, you can assign client virtual IP addresses by XAuth instead of from a DHCP
address range. See “Assigning VIPs by RADIUS user group” on page 1034.
The authentication protocol to use for XAuth depends on the capabilities of the
authentication server and the XAuth client:
• Select PAP whenever possible. Select CHAP instead if applicable.
• You must select PAP for all implementations of LDAP and some implementations of
Microsoft RADIUS.
• Select AUTO when the authentication server supports CHAP but the XAuth client does
not. The FortiGate unit will use PAP to communicate with the XAuth client and CHAP to
communicate with the authentication server.
To authenticate a dialup user group using XAuth settings

Before you begin, create user accounts and user groups to identify the dialup clients that
need to access the network behind the FortiGate dialup server. If password protection will
be provided through an external RADIUS or LDAP server, you must configure the
FortiGate dialup server to forward authentication requests to the authentication server. For
information about these topics, see the “User” chapter of the FortiGate Administration
Guide.
1 At the FortiGate dialup server, go to VPN > IPSEC > Auto Key (IKE).
2 In the list, select the Edit icon of a phase 1 configuration to edit its parameters for a
particular remote gateway.
3 Select Advanced.
4 Under XAuth, select Enable as Server.
5 The Server Type setting determines the type of encryption method to use between the
XAuth client, the FortiGate unit and the authentication server. Select one of the
following options:
• PAP—Password Authentication Protocol.
• CHAP— Challenge-Handshake Authentication Protocol.
• AUTO—Use PAP between the XAuth client and the FortiGate unit, and CHAP
between the FortiGate unit and the authentication server.
6 From the User Group list, select the user group that needs to access the private
network behind the FortiGate unit. The group must be added to the FortiGate
configuration before it can be selected here.
7 Select OK.

1148 01-420-99686-20101026
Auto Key phase 1 parameters Using XAuth authentication
Authenticating the FortiGate unit as a client with XAuth

If the FortiGate unit acts as a dialup client, the remote peer, acting as an XAuth server,
might require a user name and password. You can configure the FortiGate unit as an
XAuth client, with its own user name and password, which it provides when challenged.
To configure the FortiGate dialup client as an XAuth client

1 At the FortiGate dialup client, go to VPN > IPSEC > Auto Key (IKE).
2 In the list, select the Edit icon of a phase 1 configuration to edit its parameters for a
particular remote gateway.
3 Select Advanced.
4 Under XAuth, select Enable as Client.
5 In the Username field, type the FortiGate PAP, CHAP, RADIUS, or LDAP user name
that the FortiGate XAuth server will compare to its records when the FortiGate XAuth
client attempts to connect.
6 In the Password field, type the password to associate with the user name.
7 Select OK.

01-420-99686-20101026 1149
Using XAuth authentication Auto Key phase 1 parameters

1150 01-420-99686-20101026
Phase 2 parameters
This section describes the phase 2 parameters that are required to establish
communication through a VPN.
• Basic phase 2 settings
• Advanced phase 2 settings
• Configure the phase 2 parameters
Basic phase 2 settings

After phase 1 negotiations complete successfully, phase 2 begins. The phase 2
parameters define the algorithms that the FortiGate unit can use to encrypt and transfer
data for the remainder of the session. The basic phase 2 settings associate IPsec phase 2
parameters with a phase 1 configuration.
When you define phase 2 parameters, you can choose any set of phase 1 parameters to
set up a secure connection and authenticate the remote peer.
Figure 139: Basic Phase 2 settings (VPN > IPSEC > Auto Key (IKE) > Create Phase 2
The information and procedures in this section do not apply to VPN peers that perform
negotiations using manual keys. Refer to “Manual-key configurations” on page 1091
instead.
Advanced phase 2 settings

The following additional advanced phase 2 settings are available to enhance the operation
of the tunnel:
• P2 proposal
• Enable replay detection
• Enable perfect forward secrecy (PFS)
• Quick Mode Identities

01-420-99686-20101026 1151
Advanced phase 2 settings Phase 2 parameters
Figure 140: Advanced phase 2 settings
P2 Proposal
In phase 2, the FortiGate unit and the VPN peer or client exchange keys again to establish
a secure communication channel between them. The P2 Proposal parameters select the
encryption and authentication algorithms needed to generate keys for protecting the
implementation details of Security Associations (SAs). The keys are generated
automatically using a Diffie-Hellman algorithm.
Replay detection
IPsec tunnels can be vulnerable to replay attacks. Replay detection enables the FortiGate
unit to check all IPsec packets to see if they have been received before. If any encrypted
packets arrive out of order, the FortiGate unit discards them.
Perfect forward secrecy

By default, phase 2 keys are derived from the session key created in phase 1. Perfect
forward secrecy forces a new Diffie-Hellman exchange when the tunnel starts and
whenever the phase 2 keylife expires, causing a new key to be generated each time. This
exchange ensures that the keys created in phase 2 are unrelated to the phase 1 keys or
any other keys generated automatically in phase 2.
Keylife
The Keylife setting sets a limit on the length of time that a phase 2 key can be used.
Alternatively, you can set a limit on the number of kilobytes (KB) of processed data, or
both. If you select both, the key expires when either the time has passed or the number of
KB have been processed. When the phase 2 key expires, a new key is generated without
interrupting service.
Auto-negotiate
By default, the phase 2 security association (SA) is not negotiated until a peer attempts to
send data. The triggering packet and some subsequent packets are dropped until the SA
is established. Applications normally resend this data, so there is no loss, but there might
be a noticeable delay in response to the user.
Automatically establishing the SA can also be important on a dialup peer. This ensures
that the VPN tunnel is available for peers at the server end to initiate traffic to the dialup
peer. Otherwise, the VPN tunnel does not exist until the dialup peer initiates traffic.

1152 01-420-99686-20101026
Phase 2 parameters Advanced phase 2 settings
When enabled, auto-negotiate initiates the phase 2 SA negotiation automatically,

repeating every five seconds until the SA is established.
The auto-negotiate feature is available only through the Command Line Interface (CLI).
Use the following commands to enable it.
edit <phase2_name>
set auto-negotiate enable
end
If the tunnel ever goes down, the auto-negotiate feature will try to re-establish it. However,
the Autokey Keep Alive feature is a better way to keep your VPN up.
Autokey Keep Alive

The phase 2 security association (SA) has a fixed duration. If there is traffic on the VPN as
the SA nears expiry, a new SA is negotiated and the VPN switches to the new SA with no
interruption. If there is no traffic, the SA expires and the VPN tunnel goes down.
The Autokey Keep Alive option ensures that a new SA is negotiated even if there is no
traffic so that the VPN tunnel stays up.
DHCP-IPsec
Select this option if the FortiGate unit assigns VIP addresses to FortiClient dialup clients
through a DHCP server or relay. This option is available only if the Remote Gateway in the
phase 1 configuration is set to Dialup User and it works only on policy-based VPNs.
The DHCP-IPsec option causes the FortiGate dialup server to act as a proxy for
FortiClient dialup clients that have VIP addresses on the subnet of the private network
behind the FortiGate unit. In this case, the FortiGate dialup server acts as a proxy on the
local private network for the FortiClient dialup client. When a host on the network behind
the dialup server issues an ARP request that corresponds to the device MAC address of
the FortiClient host, the FortiGate unit answers the ARP request on behalf of the
FortiClient host and forwards the associated traffic to the FortiClient host through the
tunnel.
Quick mode selectors

The Quick Mode selectors determine who (which IP addresses) can perform IKE
negotiations to establish a tunnel. The default settings are as broad as possible: any IP
address, using any protocol, on any port. This enables configurations in which multiple
subnets at each end of the tunnel can communicate, limited only by the firewall policies at
each end.
There are some configurations that require specific selectors:
• the VPN peer is a third-party device that uses specific phase2 selectors
• the FortiGate unit connects as a dialup client to another FortiGate unit, in which case
you must specify a source IP address, IP address range or subnet
The quick mode selectors allow IKE negotiations only for peers that match the specified
configuration. This does not control traffic on the VPN. Access to IPsec VPN tunnels is
controlled through firewall policies.

01-420-99686-20101026 1153
Configure the phase 2 parameters Phase 2 parameters
Configure the phase 2 parameters

Follow this procedure to create an IPsec phase 2 definition.
Note: If you are creating a hub-and-spoke configuration or an Internet-browsing

configuration, you may have already started defining some of the required phase 2
parameters. If so, edit the existing definition to complete the configuration.
Specifying the phase 2 parameters

2 Select Create Phase 2 to add a new phase 2 configuration or select the Edit button
beside an existing phase 2 configuration.
Name Enter a name to identify the phase 2 configuration.

Phase 1 Select the phase 1 configuration that describes how remote peers or dialup
clients will be authenticated on this tunnel, and how the connection to the
remote peer or dialup client will be secured.
4 Select Advanced.
P2 Proposal Select the encryption and authentication algorithms that will be used to
change data into encrypted code.
Add or delete encryption and authentication algorithms as required. Select a
minimum of one and a maximum of three combinations. The remote peer
must be configured to use at least one of the proposals that you define.
It is invalid to set both Encryption and Authentication to null.
Encryption You can select any of the following symmetric-key algorithms:
• NULL — Do not use an encryption algorithm.
• DES — Digital Encryption Standard, a 64-bit block algorithm that uses a
56-bit key.
• 3DES — Triple-DES, in which plain text is encrypted three times by three
keys.
Authentication You can select either of the following message digests to check the
authenticity of messages during an encrypted session:
• NULL — Do not use a message digest.
• MD5 — Message Digest 5, the hash algorithm developed by RSA Data
Security.
• SHA1 — Secure Hash Algorithm 1, which produces a 160-bit message
digest.
To specify one combination only, set the Encryption and Authentication
options of the second combination to NULL. To specify a third combination,
use the Add button beside the fields for the second combination.
Enable replay Optionally enable or disable replay detection. Replay attacks occur when an
detection unauthorized party intercepts a series of IPsec packets and replays them
back into the tunnel.
Enable perfect Enable or disable PFS. Perfect forward secrecy (PFS) improves security by
forward secrecy forcing a new Diffie-Hellman exchange whenever keylife expires.
(PFS)
DH Group Select one Diffie-Hellman group (1, 2, 5, or 14). The remote peer or dialup
client must be configured to use the same group.

1154 01-420-99686-20101026
Phase 2 parameters Configure the phase 2 parameters
Keylife Select the method for determining when the phase 2 key expires: Seconds,
KBytes, or Both. If you select Both, the key expires when either the time has
passed or the number of KB have been processed. The range is from 120 to
172800 seconds, or from 5120 to 2147483648 KB.
Autokey Keep Enable the option if you want the tunnel to remain active when no data is
Alive being processed.
DHCP-IPsec Select Enable if the FortiGate unit acts as a dialup server and FortiGate
DHCP server or relay will be used to assign VIP addresses to FortiClient
dialup clients. The DHCP server or relay parameters must be configured
separately.
If the FortiGate unit acts as a dialup server and the FortiClient dialup client
VIP addresses match the network behind the dialup server, select Enable to
cause the FortiGate unit to act as a proxy for the dialup clients.
This is available only for phase 2 configurations associated with a dialup
phase 1 configuration. It works only on policy-based VPNs.
Quick Mode Optionally specify the source and destination IP addresses to be used as
Selector selectors for IKE negotiations. If the FortiGate unit is a dialup server, the
default value 0.0.0.0/0 should be kept unless you need to circumvent
problems caused by ambiguous IP addresses between one or more of the
private networks making up the VPN. You can specify a single host IP
address, an IP address range, or a network address. You may optionally
specify source and destination port numbers and/or a protocol number.
If you are editing an existing phase 2 configuration, the Source address and
Destination address fields are unavailable if the tunnel has been configured
to use firewall addresses as selectors. This option exists only in the CLI. See
the dst-addr-type, dst-name, src-addr-type and src-name
keywords for the vpn ipsec phase2 command in the FortiGate CLI
Reference.
Source If the FortiGate unit is a dialup server, type the source IP address that
address corresponds to the local sender(s) or network behind the local VPN peer (for
example, 172.16.5.0/24 or 172.16.5.0/255.255.255.0 for a subnet,
or 172.16.5.1/32 or 172.16.5.1/255.255.255.255 for a server or
host, or 192.168.10.[80-100] or 192.168.10.80-192.168.10.100
for an address range). A value of 0.0.0.0/0 means all IP addresses
behind the local VPN peer.
If the FortiGate unit is a dialup client, source address must refer to the
private network behind the FortiGate dialup client.
Source port Type the port number that the local VPN peer uses to transport traffic related
to the specified service (protocol number). The range is 0 to 65535. To
specify all ports, type 0.
Destination Type the destination IP address that corresponds to the recipient(s) or
address network behind the remote VPN peer (for example, 192.168.20.0/24 for
a subnet, or 172.16.5.1/32 for a server or host, or 192.168.10.[80-
100] for an address range). A value of 0.0.0.0/0 means all IP addresses
behind the remote VPN peer.
Destination Type the port number that the remote VPN peer uses to transport traffic
port related to the specified service (protocol number). The range is 0 to 65535.
To specify all ports, type 0.
Protocol Type the IP protocol number of the service. The range is 1 to 255. To specify
all services, type 0.
6 Select OK.

01-420-99686-20101026 1155
Configure the phase 2 parameters Phase 2 parameters

1156 01-420-99686-20101026
Defining firewall policies
This section explains how to specify the source and destination IP addresses of traffic
transmitted through an IPsec VPN, and how to define appropriate firewall policies.
• Defining firewall addresses
• Defining firewall policies
Defining firewall addresses

A VPN tunnel has two end points. These end points may be VPN peers such as two
FortiGate gateways. Encrypted packets are transmitted between the end points. At each
end of the VPN tunnel, a VPN peer intercepts encrypted packets, decrypts the packets,
and forwards the decrypted IP packets to the intended destination.
You need to define firewall addresses for the private networks behind each peer. You will
use these addresses as the source or destination address depending on the firewall
policy.
In general:
• In a gateway-to-gateway, hub-and-spoke, dynamic DNS, redundant-tunnel, or
transparent configuration, you need to define a firewall address for the private IP
address of the network behind the remote VPN peer (for example,
192.168.10.0/255.255.255.0 or 192.168.10.0/24).
• In a peer-to-peer configuration, you need to define a firewall address for the private IP
address of a server or host behind the remote VPN peer (for example,
172.16.5.1/255.255.255.255 or 172.16.5.1/32 or 172.16.5.1).
• For a FortiGate dialup server in a dialup-client or Internet-browsing configuration:
• If you are not using VIP addresses, or if the FortiGate dialup server assigns VIP
addresses to FortiClient dialup clients through FortiGate DHCP relay, select the
predefined destination address “all” in the firewall policy to refer to the dialup clients.
• If you assign VIP addresses to FortiClient dialup clients manually, you need to define a
firewall address for the VIP address assigned to the dialup client (for example,
10.254.254.1/32), or a subnet address from which the VIP addresses are assigned
(for example, 10.254.254.0/24 or 10.254.254.0/255.255.255.0).
• For a FortiGate dialup client in a dialup-client or Internet-browsing configuration, you
need to define a firewall address for the private IP address of a host, server, or network
behind the FortiGate dialup server.
To define an IP address
2 In the Address Name field, type a descriptive name that represents the network,
server(s), or host(s).

01-420-99686-20101026 1157
Defining firewall policies Defining firewall policies
4 In the Subnet/IP Range field, type the corresponding IP address and subnet mask (for
example, 172.16.5.0/24 or 172.16.5.0/255.255.255.0 for a subnet, or
172.16.5.1/32 for a server or host) or IP address range (for example,
192.168.10.[80-100] or 192.168.10.80-192.168.10.100).
5 Select OK.
Defining firewall policies

Firewall policies allow IP traffic to pass between interfaces on a FortiGate unit. You can
limit communication to particular traffic by specifying source address and destination
addresses.
Policy-based and route-based VPNs require different firewall policies.
• A policy-based VPN requires an IPsec firewall policy. You specify the interface to the
private network, the interface to the remote peer and the VPN tunnel. A single policy
can enable traffic inbound, outbound, or in both directions.
• A route-based VPN requires an Accept firewall policy for each direction. As source and
destination interfaces, you specify the interface to the private network and the virtual
IPsec interface (phase 1 configuration) of the VPN. The IPsec interface is the
destination interface for the outbound policy and the source interface for the inbound
policy.
There are examples of firewall policies for both policy-based and route-based VPNs
throughout this guide.
Defining an IPsec firewall policy for a policy-based VPN

An IPsec firewall policy enables the transmission and reception of encrypted packets,
specifies the permitted direction of VPN traffic, and selects the VPN tunnel. In most cases,
a single policy is needed to control both inbound and outbound IP traffic through a VPN
tunnel.
In addition to these operations, firewall policies specify which IP addresses can initiate a
tunnel. Traffic from computers on the local private network initiates the tunnel when the
Allow outbound option is selected. Traffic from a dialup client or computers on the remote
network initiates the tunnel when the Allow inbound option is selected.
When a FortiGate unit runs in NAT/Route mode, you can also enable inbound or outbound
NAT. Outbound NAT may be performed on outbound encrypted packets, or on IP packets
before they are sent through the tunnel. Inbound NAT is performed on IP packets
emerging from the tunnel. These options are not selected by default in firewall policies.
When used in conjunction with the natip CLI attribute (see the “config firewall” chapter of
the FortiGate CLI Reference), outbound NAT enables you to change the source
addresses of IP packets before they go into the tunnel. This feature is often used to
resolve ambiguous routing when two or more of the private networks making up a VPN
have the same or overlapping IP addresses. For examples of how to use these two
features together, see the FortiGate Outbound NAT for IPsec VIP Technical Note and the
FortiGate IPsec VPN Subnet-address Translation Technical Note.

1158 01-420-99686-20101026
When inbound NAT is enabled, inbound encrypted packets are intercepted and decrypted,
and the source IP addresses of the decrypted packets are translated into the IP address of
the FortiGate interface to the local private network before they are routed to the private
network. If the computers on the local private network can communicate only with devices
on the local private network (that is, the FortiGate interface to the private network is not
the default gateway) and the remote client (or remote private network) does not have an
IP address in the same network address space as the local private network, enable
inbound NAT.
Most firewall policies control outbound IP traffic. An outbound policy usually has a source
address originating on the private network behind the local FortiGate unit, and a
destination address belonging to a dialup VPN client or a network behind the remote VPN
peer. The source address that you choose for the firewall policy identifies from where
outbound cleartext IP packets may originate, and also defines the local IP address or
addresses that a remote server or client will be allowed to access through the VPN tunnel.
The destination address that you choose for the firewall policy identifies where IP packets
must be forwarded after they are decrypted at the far end of the tunnel, and determines
the IP address or addresses that the local network will be able to access at the far end of
the tunnel.
You can fine-tune a policy for services such as HTTP, FTP, and POP3; enable logging,
traffic shaping, antivirus protection, web filtering, email filtering, file transfer, and email
services throughout the VPN; and optionally allow connections according to a predefined
schedule. For more information, see the “Firewall Policy” chapter of the FortiGate
Note: As an option, differentiated services can be enabled in the firewall policy through CLI
commands. For more information, see the “firewall” chapter of the FortiGate CLI Reference.
When a remote server or client attempts to connect to the private network behind a
FortiGate gateway, the firewall policy intercepts the connection attempt and starts the VPN
tunnel. The FortiGate unit uses the remote gateway specified in its phase 1 tunnel
configuration to reply to the remote peer. When the remote peer receives a reply, it checks
its own firewall policy, including the tunnel configuration, to determine which
communications are permitted. As long as one or more services are allowed through the
VPN tunnel, the two peers begin to negotiate the tunnel.
Before you begin

Before you define the IPsec policy, you must:
• Define the IP source and destination addresses. See “Defining firewall addresses” on
page 1157.
• Specify the phase 1 authentication parameters. See “Auto Key phase 1 parameters” on
page 1135.
• Specify the phase 2 parameters. See “Phase 2 parameters” on page 1151.
To define an IPsec firewall policy

Source Interface/Zone Select the local interface to the internal (private) network.
Source Address Name Select the name that corresponds to the local network,
server(s), or host(s) from which IP packets may originate.

01-420-99686-20101026 1159
Destination Interface/Zone Select the local interface to the external (public) network.
Destination Address Name Select the name that corresponds to the remote network,
server(s), or host(s) to which IP packets may be delivered.
Schedule Keep the default setting (always) unless changes are needed
to meet specific requirements.
Service Keep the default setting (ANY) unless changes are needed to
meet your specific requirements.
VPN Tunnel Select the name of the phase 1 tunnel configuration to which
this policy will apply.
Allow Inbound Select if traffic from the remote network will be allowed to
Allow Outbound Select if traffic from the local network will be allowed to initiate
the tunnel.
Inbound NAT Select if you want to translate the source IP addresses of
inbound decrypted packets into the IP address of the FortiGate
interface to the local private network.
Outbound NAT Select in combination with a natip CLI value to translate the
source addresses of outbound cleartext packets into the IP
address that you specify. Do not select Outbound NAT unless
you specify a natip value through the CLI. When a natip
value is specified, the source addresses of outbound IP
packets are replaced before the packets are sent through the
tunnel. For more information, see the “firewall” chapter of the
FortiGate CLI Reference.
3 You may enable UTM features, and/or event logging, or select advanced settings to
authenticate a user group, or shape traffic. For more information, see the “Firewall
Policy” chapter of the FortiGate Administration Guide.
4 Select OK.
Defining multiple IPsec policies for the same tunnel

You must define at least one IPsec policy for each VPN tunnel. If the same remote server
or client requires access to more than one network behind a local FortiGate unit, the
FortiGate unit must be configured with an IPsec policy for each network. Multiple policies
may be required to configure redundant connections to a remote destination or control
access to different services at different times.
To ensure a secure connection, the FortiGate unit must evaluate IPSEC policies before
ACCEPT and DENY firewall policies. Because the FortiGate unit reads policies starting at
the top of the list, you must move all IPsec policies to the top of the list. When you define
multiple IPsec policies for the same tunnel, you must reorder the IPsec policies that apply
to the tunnel so that specific constraints can be evaluated before general constraints.
Note: Adding multiple IPsec policies for the same VPN tunnel can cause conflicts if the
policies specify similar source and destination addresses but have different settings for the
same service. When policies overlap in this manner, the system may apply the wrong IPsec
policy or the tunnel may fail.
For example, if you create two equivalent IPsec policies for two different tunnels, it does
not matter which one comes first in the list of IPsec policies—the system will select the
correct policy based on the specified source and destination addresses. If you create two
different IPsec policies for the same tunnel (that is, the two policies treat traffic differently
depending on the nature of the connection request), you might have to reorder the IPsec

1160 01-420-99686-20101026
policies to ensure that the system selects the correct IPsec policy. Reordering is especially
important when the source and destination addresses in both policies are similar (for
example, if one policy specifies a subset of the IP addresses in another policy). In this
case, place the IPsec policy having the most specific constraints at the top of the list so
that it can be evaluated first.
Defining firewall policies for a route-based VPN

When you define a route-based VPN, you create a virtual IPsec interface on the physical
interface that connects to the remote peer. You create ordinary Accept firewall policies to
enable traffic between the IPsec interface and the interface that connects to the private
network. This makes configuration simpler than for policy-based VPNs, which require
IPsec firewall policies.
To define firewall policies for a route-based VPN

1 Define an ACCEPT firewall policy to permit communications between the local private
network and the private network behind the remote peer. Enter these settings in
particular:
Source Address Name Select the address name that you defined for the private
network behind this FortiGate unit.
Destination Interface/Zone Select the IPsec Interface you configured.
Destination Address Name Select the address name that you defined for the private
network behind the remote peer.
NAT Disable.
2 To permit the remote client to initiate communication, you need to define a firewall
Source Interface/Zone Select the IPsec Interface you configured.

Source Address Name Select the address name that you defined for the private
network behind the remote peer.
Destination Address Name Select the address name that you defined for the private
network behind this FortiGate unit.
NAT Disable.

01-420-99686-20101026 1161

1162 01-420-99686-20101026
Hardware offloading and acceleration
FortiGate units incorporate proprietary FortiASIC NP2 network processors that can
provide accelerated processing for IPsec VPN traffic. This section describes how to
configure offloading and acceleration.
• Overview
• IPsec offloading configuration examples
Overview
Fortinet’s NP2 network processors contain features to improve IPsec tunnel performance.
For example, network processors can encrypt and decrypt packets, offloading
cryptographic load on the FortiGate unit’s main processing resources.
On FortiGate units with the appropriate hardware, you can configure offloading of both
IPsec sessions and HMAC checking.
IPsec session offloading requirements

Sessions must be fast path ready. Fast path ready session requirements are:
• Layer 2 type/length must be 0x0800 (IEEE 802.1q VLAN specification is supported);
link aggregation between any network interfaces sharing the same network
processor(s) may be used (IEEE 802.3ad specification is supported)
• Layer 3 protocol must be IPv4
• Layer 4 protocol must be UDP, TCP or ICMP
• Layer 3 / Layer 4 header or content modification must not require a session helper (for
example, SNAT, DNAT, and TTL reduction are supported, but application layer content
modification is not supported)
• FortiGate unit firewall policy must not require antivirus or IPS inspection, although
hardware accelerated anomaly checks are acceptable.
• The session must not use an aggregated link or require QoS, including rate limits and
bandwidth guarantees (NP1 processor only).
• Ingress and egress network interfaces are both attached to the same network
processor(s)
• In Phase I configuration, Local Gateway IP must be specified as an IP address of a
network interface attached to a network processor

01-420-99686-20101026 1163
Overview Hardware offloading and acceleration
• In Phase II configuration:
• encryption algorithm must be DES, 3DES, AES-128, AES-192, AES-256, or null
(for NP1 processor, only 3DES is supported)
• authentication must be MD5, SHA1, or null
(for NP1 processor, only MD5 is supported)
• if replay detection is enabled, encryption and decryption options must be enabled in
the CLI (see “IPsec encryption offloading”, below)
If the IPsec session meets the above requirements, the FortiGate unit sends the IPsec
security association (SA) and configured processing actions to the network processor(s).
Packet requirements
In addition to the session requirements, the packets themselves must meet fast-path
requirements:
• Incoming packets must not be fragmented.
• Outgoing packets must not require fragmentation to a size less than 385 bytes.
Because of this requirement, the configured MTU (Maximum Transmission Unit) for
network processors’ network interfaces must also meet or exceed the network
processors’ supported minimum MTU of 385 bytes.
If packet requirements are not met, an individual packet will use FortiGate unit main
processing resources, regardless of whether other packets in the session are offloaded to
the specialized network processor(s).
IPsec encryption offloading

Network processing unit (NPU) settings configure offloading behavior for IPsec VPNs.
Configured behavior applies to all network processors contained by the FortiGate unit
itself or any installed AMC modules.
If replay detection is not enabled (IPsec Phase 2 settings), encryption is always offloaded.
To enable offloading of encryption even when replay detection is enabled:
config system npu
set enc-offload-antireplay enable
end
To enable offloading of decryption even when replay detection is enabled:
config system npu
set dec-offload-antireplay {enable | disable}
end
HMAC check offloading

To enable HMAC check offloading, enter
configure system global
set ipsec-hmac-offload (enable|disable)
end

1164 01-420-99686-20101026
Hardware offloading and acceleration IPsec offloading configuration examples
IPsec offloading configuration examples

The following examples configure two FortiASIC NP2 accelerated VPNs, one route-
based, the other policy based. In both cases, the network topology is as shown in
Figure 141.
Figure 141: Hardware accelerated IPsec VPN topology
A
4 Po SM-F Fo
_1 FB c) rt 2 B
ate M- se 3.3 (IPs4
rtiG
rtiG AS t 2 (IP .3. ec ate
F o r
Po 3.1/2
4 2/2 ) _2
. 3 . 4
3
4 AS
FB M-
S M- P FB
A t1
r 4 2.2 ort 1 4
Po 1.0/2 .2.
. 0/2
1.1 4
Pro Pro
tec tec
ted ted
ne ne
two two
rk rk
Accelerated route-based VPN configuration

To configure FortiGate_1
2 Configure Phase 1 settings (name FGT_1_IPsec), plus
• Select Advanced.
• Select the Enable IPsec Interface Mode check box.
• In Local Gateway IP, select Specify and enter the VPN IP address 3.3.3.1, which is
the IP address of FortiGate_1’s FortiGate-ASM-FB4 module on port 2.
3 Select OK.
4 Select Create Phase 2 and configure Phase 2 settings, including
• Select the Enable replay detection check box.
• set enc-offload-antireplay to enable using the config system npu CLI
command.
6 Configure two policies (one for each direction) to apply the Phase 1 IPsec configuration
you configured in step 2 to traffic leaving from or arriving on FortiGate-ASM-FB4
module port 1.
8 Configure a static route to route traffic destined for FortiGate_2’s protected network to
the virtual IPsec interface, FGT_1_IPsec.
To add the static route from the CLI:
edit 2

01-420-99686-20101026 1165
IPsec offloading configuration examples Hardware offloading and acceleration
set device "FGT_1_IPsec"

set dst 2.2.2.0 255.255.255.0
end
3 Select OK.
command.
6 Configure two policies (one for each direction) to apply the Phase 1 IPsec configuration
you configured in step 2 to traffic leaving from or arriving on FortiGate-ASM-FB4
module port 1.
the virtual IPsec interface, FGT_2_IPsec.
edit 2
set device "FGT_2_IPsec"
set dst 1.1.1.0 255.255.255.0
end
To test the VPN

1 Activate the IPsec tunnel by sending traffic between the two protected networks.
2 To verify tunnel activation, go to VPN > IPSEC > Monitor.
Accelerated policy-based VPN configuration

• Ensure that the Enable IPsec Interface Mode check box is not selected.
3 Select OK.

1166 01-420-99686-20101026
Hardware offloading and acceleration IPsec offloading configuration examples

command.
6 Configure an IPSEC policy to apply the Phase 1 IPsec tunnel you configured in step 2
to traffic between FortiGate-ASM-FB4 module ports 1 and 2.
FortiGate_2’s VPN gateway, 3.3.3.2, through the FortiGate-ASM-FB4 module’s port 2
(device).
edit 0
set device "AMC-SW1/2"
set dst 2.2.2.0 255.255.255.0
set gateway 3.3.3.1
end
3 Select OK.
command.
6 Configure an IPSEC policy to apply the Phase 1 IPsec tunnel you configured in step 2
to traffic between FortiGate-ASM-FB4 module ports 1 and 2.
FortiGate_2’s VPN gateway, 3.3.3.2, through the FortiGate-ASM-FB4 module’s port 2
(device).
edit 0
set device "AMC-SW1/2"
set dst 1.1.1.0 255.255.255.0
set gateway 3.3.3.2
end

01-420-99686-20101026 1167
IPsec offloading configuration examples Hardware offloading and acceleration
To test the VPN

1 Activate the IPsec tunnel by sending traffic between the two protected networks.
2 To verify tunnel activation, go to VPN > IPSEC > Monitor.

1168 01-420-99686-20101026
Monitoring and troubleshooting VPNs
This section provides some general maintenance and monitoring procedures for VPNs.
• Monitoring VPN connections
• Monitoring IKE sessions
• Testing VPN connections
• Logging VPN events
• VPN troubleshooting tips
Monitoring VPN connections

You can use the monitor to view activity on IPsec VPN tunnels and to start or stop those
tunnels. The display provides a list of addresses, proxy IDs, and timeout information for all
active tunnels.
Monitoring connections to remote peers

The list of tunnels provides information about VPN connections to remote peers that have
static IP addresses or domain names. You can use this list to view status and IP
addressing information for each tunnel configuration. You can also start and stop
individual tunnels from the list.
To view the list of static-IP and dynamic-DNS tunnels

1 Go to VPN > IPSEC > Monitor.
Figure 142: List of static-IP and dynamic-DNS tunnels
Bring up tunnel
To establish or take down a VPN tunnel

2 In the list of tunnels, select Bring down tunnel or Bring up tunnel in the row that
corresponds to the tunnel that you want to bring down or up.
Monitoring dialup IPsec connections

The list of dialup tunnels provides information about the status of tunnels that have been
established for dialup clients. The list displays the IP addresses of dialup clients and the
names of all active tunnels. The number of tunnels shown in the list can change as dialup
clients connect and disconnect.

01-420-99686-20101026 1169
Monitoring VPN connections Monitoring and troubleshooting VPNs
To view the list of dialup tunnels

Figure 143: List of dialup tunnels
Note: If you take down an active tunnel while a dialup client such as FortiClient is still
connected, FortiClient will continue to show the tunnel connected and idle. The dialup client
must disconnect before another tunnel can be initiated.
The list of dialup tunnels displays the following statistics:

• The Name column displays the name of the tunnel.
• The meaning of the value in the Remote gateway column changes, depending on the
configuration of the network at the far end:
• When a FortiClient dialup client establishes a tunnel, the Remote gateway column
displays either the public IP address and UDP port of the remote host device (on
which the FortiClient Endpoint Security application is installed), or if a NAT device
exists in front of the remote host, the Remote gateway column displays the public IP
address and UDP port of the remote host.
• When a FortiGate dialup client establishes a tunnel, the Remote gateway column
displays the public IP address and UDP port of the FortiGate dialup client.
• The Username column displays the peer ID, certificate name, or XAuth user name of
the dialup client (if a peer ID, certificate name, or XAuth user name was assigned to
the dialup client for authentication purposes).
• The Timeout column displays the time before the next key exchange. The time is
calculated by subtracting the time elapsed since the last key exchange from the keylife.
• The Proxy ID Source column displays the IP addresses of the hosts, servers, or private
networks behind the FortiGate unit. A network range may be displayed if the source
address in the firewall encryption policy was expressed as a range of IP addresses.
• The meaning of the value in the Proxy ID Destination column changes, depending on
the configuration of the network at the far end:
• When a FortiClient dialup client establishes a tunnel:
• If VIP addresses are not used and the remote host connects to the Internet
directly, the Proxy ID Destination field displays the public IP address of the
Network Interface Card (NIC) in the remote host.
• If VIP addresses are not used and the remote host is behind a NAT device, the
Proxy ID Destination field displays the private IP address of the NIC in the
remote host.
• If VIP addresses were configured (manually or through FortiGate DHCP relay),
the Proxy ID Destination field displays either the VIP address belonging to a
FortiClient dialup client, or a subnet address from which VIP addresses were
assigned.
• When a FortiGate dialup client establishes a tunnel, the Proxy ID Destination field
displays the IP address of the remote private network.

1170 01-420-99686-20101026
Monitoring and troubleshooting VPNs Monitoring IKE sessions
Monitoring IKE sessions

You can display a list of all active sessions and view activity by port number. If required,
active sessions can be stopped from this view. For more information, see the “System
Status” chapter of the FortiGate Administration Guide.
To view the list of active sessions

1 Go to System > Dashboard > Dashboard.
2 In the Top Sessions widget, select Details on the Total Current Sessions line.
IPsec VPN-related sessions can be identified by the following port numbers:
• port numbers 500 and 4500 for IPsec IKE activity
• port number 4500 for NAT traversal activity
Figure 144: Session list
Testing VPN connections

To confirm whether a VPN 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. A VPN tunnel will be established automatically when the first data
packet destined for the remote network is intercepted by the FortiGate unit.
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.
Logging VPN events

You can configure the FortiGate unit to log VPN events. For IPsec VPNs, phase 1 and
phase 2 authentication and encryption events are logged. For information about how to
interpret log messages, see the FortiGate Log Message Reference.
To log VPN events

2 Enable the storage of log messages to one or more of the following locations:
• a FortiLog unit
• the FortiGate system memory
• a remote computer running a syslog server
Note: If available on your FortiGate unit, you can enable the storage of log messages to a
system hard disk. In addition, as an alternative to the options listed above, you may choose
to forward log messages to a remote computer running a WebTrends firewall reporting
server. For more information about enabling either of these options through CLI
commands, see the “log” chapter of the FortiGate CLI Reference.

01-420-99686-20101026 1171
Logging VPN events Monitoring and troubleshooting VPNs
3 If the options are concealed, select the blue arrow beside each option to reveal and
configure associated settings.
4 If logs will be written to system memory, from the Log Level list, select Information. For
more information, see the “Log&Report” chapter of the FortiGate Administration Guide.
5 Select Apply.
To filter VPN events

2 Verify that the IPsec negotiation event option is selected.
3 Select Apply.
To view event logs

1 Go to Log&Report > Log Access > Event.
2 If the option is available from the Type list, select the log file from disk or memory.
Entries similar to the following indicate that a tunnel has been established. The following
log messages concern a VPN tunnel called vpn_test on port2 interface in the root
VDOM. Pay attention to the status and msg values.
2005-03-31 15:38:29 log_id=0101023004 type=event subtype=ipsec pri=notice
vd=root loc_ip=172.16.62.10 loc_port=500 rem_ip=172.16.62.11 rem_port=500
out_if=port2 vpn_tunnel=vpn_test cookies=151c3a5c6dd93c54/0000000000000000
action=negotiate init=local mode=main stage=1 dir=outbound status=success
msg="Initiator: sent 172.16.62.11 main mode message #1 (OK)"
out_if=port2 vpn_tunnel=vpn_test cookies=151c3a5c6dd93c54/5ed26a81fb7a2d0c
action=negotiate init=local mode=main stage=3 dir=inbound status=success
msg="Initiator: parsed 172.16.62.11 main mode message #3 (DONE)"
action=negotiate init=local mode=quick stage=1 dir=outbound status=success
msg="Initiator: sent 172.16.62.11 quick mode message #1 (OK)"
action=install_sa in_spi=66867f2b out_spi=e22de275 msg="Initiator: tunnel
172.16.62.10/172.16.62.11 install ipsec sa"

1172 01-420-99686-20101026
Monitoring and troubleshooting VPNs VPN troubleshooting tips

action=negotiate init=local mode=quick stage=2 dir=outbound status=success
msg="Initiator: sent 172.16.62.11 quick mode message #2 (DONE)"
action=negotiate status=success msg="Initiator: tunnel 172.16.62.11,
transform=ESP_3DES, HMAC_SHA1"
Entries similar to the following indicate that phase 1 negotiations broke down because the
preshared keys belonging to the VPN peers were not identical. A tunnel was not
established. Pay attention to the status and msg values.
2005-03-31 16:06:39 log_id=0101023003 type=event subtype=ipsec pri=error vd=root
loc_ip=192.168.70.2 loc_port=500 rem_ip=192.168.80.2 rem_port=500 out_if=port2
vpn_tunnel=vpn_test2 cookies=3896343ae575f210/0a7ba199149e31e9
action=negotiate status=negotiate_error msg="Negotiate SA Error: probable pre-
shared secret mismatch"
For more information about how to interpret error log messages, see the FortiGate Log
Message Reference.
VPN 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. See “Testing
VPN connections” on page 1171.
2 Traceroute the remote network or client. If DNS is working, you can use domain
names. Otherwise use IP addresses.
3 Verify the configuration of the FortiGate unit and the remote peer. Check the following
IPsec parameters:
• The mode setting for ID protection (main or aggressive) on both VPN peers must be
identical.
• The authentication method (preshared keys or certificates) used by the client must
be supported on the FortiGate unit and configured properly.
• If preshared keys are being used for authentication purposes, both VPN peers must
have identical preshared keys.
• 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.
• Both VPN peers must have the same NAT traversal setting (enabled or disabled).
• 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.
• 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.
4 Refer to Table 73 on page 1174 to correct the problem.

01-420-99686-20101026 1173
VPN troubleshooting tips Monitoring and troubleshooting VPNs
Table 73: VPN trouble-shooting tips
Configuration problem Correction

Mode settings do not match. Select complementary mode settings. See “Choosing main
mode or aggressive mode” on page 1136.
Peer ID or certificate name of Check Phase 1 configuration. Depending on the Remote
the remote peer or dialup client Gateway and Authentication Method settings, you have a
is not recognized by FortiGate choice of options to authenticate FortiGate dialup clients or
VPN peers by ID or certificate name (see “Authenticating
VPN server. remote peers and clients” on page 1139).
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. See “Authenticating remote peers
and clients” on page 1139.
Phase 1 or phase 2 key Make sure that both VPN peers have at least one set of
exchange proposals are proposals in common for each phase. See “Defining IKE
mismatched. negotiation parameters” on page 1144 and “Configure the
phase 2 parameters” on page 1154.
NAT traversal settings are Select or clear both options as required. See “NAT traversal”
mismatched. on page 1147 and “NAT keepalive frequency” on page 1147.
SPI settings for manual key Enter complementary SPI settings. See “Manual-key
tunnels are mismatched. configurations” on page 1091.
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. For more information, see “NAT traversal” on
page 1147.

1174 01-420-99686-20101026
Chapter 9 SSL VPNs

Introduction to SSL VPN provides useful general information about VPN and SSL, how the
FortiGate unit implements them, and gives guidance on how to choose between SSL and
IPsec.
Setting up the FortiGate unit explains how to configure the FortiGate unit and the web
portal. Along with these configuration details, this chapter also explains how to grant
unique access permissions, configure the SSL virtual interface (ssl.root), and
describes the SSL VPN OS Patch Check feature that allows a client with a specific OS
patch to access SSL VPN services.
Working with the web portal explains how to use a web portal and its widgets. Access to
different network resource types, such as SMB, FTP, RDP is covered.
Using the SSL VPN tunnel client explains how to install and use the tunnel mode clients
for Windows, Linux, and Mac OS X.
Examples explores several configuration scenarios with step-by-step instructions. While
the information provided is enough to set up the described SSL VPN configurations, these
scenarios are not the only possible SSL VPN setups.
FortiOS™ Handbook v2: SSL VPNs

01-420-99686-20101026 1175
SSL VPNs for FortiOS 4.0 MR2
1176 01-420-99686-20101026
Introduction to SSL VPN
This section provides information about setting up the SSL VPN client for use in an SSL
VPN tunnel or web-mode operation.
• History
• What is a VPN?
• What is SSL?
• Choosing between SSL and IPsec VPN
• General topology
• SSL VPN modes of operation
• Single Sign-on (SSO)
History
Over the past several years, as organizations have grown and become more complex,
secure remote access to network resources has become critical for day-to-day operations.
In addition, businesses are expected to provide clients with efficient, convenient services
including knowledge bases and customer portals, and employees travelling across the
country or around the world require timely and comprehensive access to network
resources. Initial access to network resources used private networks and leased lines -
options that were inflexible and costly. As a result of the growing need for providing
remote/mobile clients with easy, cost-effective and secure access to a multitude of
resources, the concept of a Virtual Private Network was developed.
In the past, VPN tunneling was performed generally at the Network Layer (Layer 3) or
lower, as is the case with IPsec. To enable remote access, encrypted network connectivity
was established between a remote node and the internal network, thereby making the
remoteness of the connection invisible to all layers above Layer 4. The applications
functioned identically when users were in the office or when they were remote, except that
when requests filtered to the network level, they were relayed over the network connection
tied to the user’s specific location. These connections required the installation and
configuration of complicated client software on user’s computers.
SSL VPNs establish connectivity using SSL, which functions at Levels 4 - 5 (Transport
and Session). Information is encapsulated at Levels 6 - 7 (Presentation and Application),
and SSL VPNs communicate at the highest levels in the OSI model. SSL is not strictly a
web protocol - it is possible to use SSL to encrypt any application-level protocol.

01-420-99686-20101026 1177
What is a VPN? Introduction to SSL VPN
What is a VPN?
Virtual Private Network (VPN) technology allows clients to connect to remote networks in a
secure way. A VPN is a secure logical network created from physically separate networks.
VPNs use encryption and other security methods to ensure that only authorized users can
access the network. VPNs also ensure that the data transmitted between computers
cannot be intercepted by unauthorized users. When data is encoded and transmitted over
the Internet, the data is said to be sent through a “VPN tunnel”. A VPN tunnel is a non-
application oriented tunnel that allows the users and networks to exchange a wide range
of traffic regardless of application or protocol.
Figure 145: Encoded data going through a VPN tunnel
The advantages of a VPN over an actual physical private network are two-fold. Rather
than utilizing expensive leased lines or other infrastructure, you use the relatively
inexpensive, high-bandwidth Internet. Perhaps more important though is the universal
availability of the Internet - in most areas, access to the Internet is readily obtainable
without any special arrangements or long wait times.
What is SSL?
SSL (Secure Sockets Layer) as HTTPS is supported by most web browsers for
exchanging sensitive information securely between a web server and a client. SSL
establishes an encrypted link, ensuring that all data passed between the web server and
the browser remains private and secure. SSL protection is initiated automatically when a
user (client) connects to a web server that is SSL-enabled. Once the successful
connection is established, the browser encrypts all the information before it leaves the
computer. When the information reaches its destination, it is decrypted using a secret
(private) key. Any data sent back is first encrypted, and is decrypted when it reaches the
client.
Goals of SSL
SSL has four main goals:
1 Confidentiality of communications
2 Integrity of data
3 Authentication of server
4 Authentication of client (non-repudiation)
Good security for a VPN requires confirming the identity of all communicating parties. You
can ensure identity using password authentication (shared secrets) or digital certificates. A
shared secret is a passphrase or password that is the same on both ends of a tunnel. The
data is encrypted using a session key, which is derived from the shared secret. The
gateways can encrypt and decrypt the data correctly only if they share the same secret.

1178 01-420-99686-20101026
Introduction to SSL VPN What is SSL?
Digital certificates use public key-based cryptography to provide identification and

authentication of end gateways. Cryptography, the art of protecting information by
transforming it into an unreadable format, is an integral part of VPN technology. The basic
building blocks of cryptographic configurations are cryptographic primitives. Cryptographic
primitives are low-level cryptographic algorithms or routines that are used to configure
computer security systems, such as SSL, SSH, and TLS. Each primitive is designed to do
one very specific task, such as encryption of data or a digital signature on a set of data.
There are four cryptographic primitives that are specific to VPNs:
1 Symmetric ciphers (confidentiality) — Symmetric encryption uses a very fast block-
level algorithm to encrypt and decrypt data, and is the primary primitive used to protect
data confidentiality. Both sides of the tunnel will use the same encrypt/decrypt key,
which is the primary weakness of symmetric ciphers. A key is usually a large number
that is fed to a cryptographic algorithm to encrypt plaintext data into ciphertext or to
decrypt ciphertext data into plaintext.
2 Asymmetric ciphers (authenticity and non-repudiation) — To guarantee the identities
of both parties in a transaction, SSL VPN uses asymmetric encryption. This involves
the creation of a key pair for each party. The keys are related mathematically - data
encrypted with one key can be decrypted only with the other key in the pair, and vice
versa. One key is labeled the public key and can be freely distributed. The other key is
the private key and it must be kept secret. The SSL VPN authenticates each party by
checking that it has something that no other party should have - its private key.
If the SSL VPN can decrypt a message from a party using that party’s public key, the
message must have been encrypted with that party’s private key. As the private key is
known only to the sending party, the sender’s identity is proven. This proof of identity
also makes it impossible for the sending party to later repudiate (deny sending) the
message.
3 Message digests (integrity) — VPNs send sensitive data over the public Internet. To
make sure that what is sent is the same as what is received, and vice versa, SSL VPN
uses message digests. A message digest is an irreversible mathematical function that
takes a message of any size and encodes it as a fixed length block of cipher text. The
fixed length cipher is called the digest. It is essentially a cryptographic “summary” of
the message. Every message has only one digest and no two messages should ever
create the same digest — if only a single letter of our message is changed, the entire
message digest will be different.
4 Digital signatures (authenticity and non-repudiation) — A digital signature or digital
signature scheme is a type of asymmetric cryptography. For messages sent through an
insecure channel, a correctly implemented digital signature gives the receiver reason
to believe the message was sent by the claimed sender. The signer cannot claim they
did not sign a message, while also claiming their private key remains secret. In some
cases, a non-repudiation scheme offers a time stamp for the digital signature, so that
even if the private key is exposed, the signature is still valid.
In addition to identifying the user, authentication also defines the resources a user can
access. A user must present specified credentials before being allowed access to certain
locations on the network. Authentication can either take place through a firewall or through
an external authentication server such as Remote Authentication Dial-In User Service
(RADIUS). An authentication server is a trusted third party that provides authentication
services to other systems on a network.

01-420-99686-20101026 1179
Choosing between SSL and IPsec VPN Introduction to SSL VPN
SSL certificates
SSL certificates are a mechanism by which a web server can prove to users that the
public key that it offers them for use with the SSL is in fact the public key of the
organization with which the user intends to communicate. A trusted third-party signs the
certificate thereby assuring users that the public key contained within the certificate
belongs to the organization whose name appears in the certificate. Upon receiving a
certificate from Your Company, a user can know for sure that the key within the certificate
is Your Company’s key and it is safe to use to encrypt any communications related to
establishment of a session key. The web server transmits their public key to users at the
beginning of an SSL session using an SSL certificate.
Encryption level is determined by the length of the encryption key. The longer the key, the
stronger the encryption level, and the greater the security provided. Within a VPN, after
the end points on a tunnel agree upon an encryption scheme, the tunnel initiator encrypts
the packet and encapsulates it in an IP packet. The tunnel terminator recovers the packet,
removes the IP information, and then decrypts the packet.
Choosing the level of security for your SSL VPN tunnel

Performance and security requirements will dictate the level of encryption used in a
particular configuration. Stronger encryption provides a greater level of security but
impacts performance levels. For general-purpose tunnels, over which no sensitive data is
to be passed, base encryption provides adequate security with good performance. For
administrative and transactional connections, where exposure of data carries a high risk,
strong encryption is recommended.
Choosing between SSL and IPsec VPN

The FortiGate unit supports both SSL and IPsec VPN technologies. Each combines
encryption and VPN gateway functions to create private communication channels over the
Internet. Both enable you to define and deploy network access and firewall policies using
a single management tool. In addition, both support a simple client/user authentication
process (including optional X.509 security certificates). You have the freedom to use both
technologies; however, one may be better suited to the requirements of your situation.
In general, IPsec VPNs are a good choice for site-to-site connections where appliance-
based firewalls or routers are used to provide network protection, and
company-sanctioned client computers are issued to users. SSL VPNs are a good choice
for roaming users who depend on a wide variety of thin-client computers to access
enterprise applications and/or company resources from a remote location.
SSL and IPsec VPN tunnels may operate simultaneously on the same FortiGate unit.
Legacy versus web-enabled applications

IPsec is well suited to network-based legacy applications that are not web-based. As a
Layer 3 technology, IPsec creates a secure tunnel between two host devices. IP packets
are encapsulated by the VPN client and server software running on the hosts.
SSL is typically used for secure web transactions in order to take advantage of web-
enabled IP applications. After a secure HTTPS link has been established between the
web browser and web server, application data is transmitted directly between selected
client and server applications through the tunnel.

1180 01-420-99686-20101026
Introduction to SSL VPN Choosing between SSL and IPsec VPN
Authentication differences
IPsec is a well-established technology with robust features that support many legacy
products such as smart cards and biometrics.
SSL supports a web single sign-on to a web portal front-end, from which a number of
different enterprise applications may be accessed. The Fortinet implementation enables
you to assign a specific port for the web portal and to customize the login page if desired.
Connectivity considerations
IPsec supports multiple connections to the same VPN tunnel—a number of remote VPN
devices effectively become part of the same network.
SSL forms a connection between two end points such as a remote client and an enterprise
network. Transactions involving three (or more) parties are not supported because traffic
passes between client and server applications only.
Relative ease of use

Although managing IPsec VPNs has become easier, configuring SSL VPNs is simple in
comparison. IPsec protocols may be blocked or restricted by some companies, hotels,
and other public places, whereas the SSL protocol is usually unrestricted.
Client software requirements

Dedicated IPsec VPN software must be installed on all IPsec VPN peers and clients and
the software has to be configured with compatible settings.
To access server-side applications with SSL VPN, the remote user must have a web
browser (Internet Explorer, Netscape, or Mozilla/Firefox), and if Telnet//RDP are used, Sun
Java runtime environment. Tunnel-mode client computers must also have ActiveX (IE) or
Java Platform (Mozilla/Firefox) enabled.
Access control
IPsec VPNs provide secure network access only. Access to the network resources on a
corporate IPsec VPN can be enabled for specific IPsec peers and/or clients. The amount
of security that can be applied to users is limited.
SSL VPNs provide secure access to certain applications. Web-only mode provides remote
users with access to server applications from any thin client computer equipped with a
web browser. Tunnel-mode provides remote users with the ability to connect to the internal
network from laptop computers as well as airport kiosks, Internet cafes, and hotels.
Access to SSL VPN applications is controlled through user groups.
Session failover support

In a FortiGate high availability (HA) cluster with session pickup enabled, session failover is
supported for IPsec VPN tunnels. After an HA failover, IPsec VPN tunnel sessions will
continue with no loss of data.
Session failover is not supported by SSL VPN tunnels, however cookie failover is
supported for communication between the SSL VPN client and the FortiGate unit. This
means that after a failover, the SSL VPN client can re-establish the SSL VPN session
without having to authenticate again. However, all sessions inside the SSL VPN tunnel
with resources behind the FortiGate unit will stop, and will therefore have to be restarted.

01-420-99686-20101026 1181
General topology Introduction to SSL VPN
General topology
In the most common SSL VPN Internet scenario, the remote client connects to the Internet
through an ISP that offers connections with dynamically assigned IP addresses. The
client’s packets are routed to the public interface of the FortiGate unit. For example,
Figure 146 shows a FortiGate gateway that can be reached by a mobile user.
Figure 146: Example SSL VPN configuration
ent
Cli
mote
Re
17 Por
2.2 t 1
0.1
20
.1 41 rs
rve
10 Por Se
.11 t 2
.10
1.1
0 0
10 0
rt 3 1. te_
1
Po 1.20
H .1
T 1.
iGa
10
T 1
. 1
P 0
10 ort
/H 1.
T 2
F
T 0
P
D 11
S
10
N .1
1
S 0
.
S 1.
er 16
ve 0
F 1
r
10
T .1
P 0
.1
S 1.
er 1
ve 70
S 1.2
10
r
ub 0
S .1
.1
am 1
ne 1.0
10
ba 10
t_ /2
2 4
S .1
.
er 80
v
1
er
At the FortiGate unit, you configure a user group for SSL VPN authentication and define
firewall policies for each network resource that users are permitted to access.
You can easily expand the resources available to your users by adding or changing
firewall policies. If you want to provide different resource access to different users, you can
create multiple user groups.
The general infrastructure requirements are quite simple:
address.
• The ISP assigns IP addresses to remote clients before they connect to the FortiGate
unit.
SSL VPN modes of operation

When a remote client connects to the FortiGate unit, the FortiGate unit authenticates the
user based on user name, password, and authentication domain. A successful login
determines the access rights of remote users according to user group. The user group
settings specify whether the connection will operate in web-only mode (see “Web-only
mode” on page 1183) or tunnel mode (see “Tunnel mode” on page 1183).
You can enable a host integrity checker to scan the remote client. The integrity checker
probes the remote client computer to verify that it is safe before access is granted.
Security attributes recorded on the client computer (for example, in the Windows registry,
in specific files, or held in memory due to running processes) are examined and uploaded
to the FortiGate unit.

1182 01-420-99686-20101026
Introduction to SSL VPN SSL VPN modes of operation
You can enable a cache cleaner to remove any sensitive data that would otherwise remain
on the remote computer after the session ends. For example, all cache entries, browser
history, cookies, encrypted information related to user authentication, and any temporary
data generated during the session are removed from the remote computer. If the client’s
browser cannot install and run the cache cleaner, the user is not allowed to access the
SSL-VPN portal.
Web-only mode
Web-only mode provides remote users with a fast and efficient way to access server
applications from any thin client computer equipped with a web browser. Web-only mode
offers true clientless network access using any web browser that has built-in SSL
encryption and the Sun Java runtime environment.
Support for SSL VPN web-only mode is built into the FortiOS operating system. The
feature comprises an SSL daemon running on the FortiGate unit, and a web portal, which
provides users with access to network services and resources including HTTP/HTTPS,
telnet, FTP, SMB/CIFS, VNC, RDP and SSH.
In web-only mode, the FortiGate unit acts as a secure HTTP/HTTPS gateway and
authenticates remote users as members of a user group. After successful authentication,
the FortiGate unit redirects the web browser to the web portal home page and the user
can access the server applications behind the FortiGate unit.
When the FortiGate unit provides services in web-only mode, a secure connection
between the remote client and the FortiGate unit is established through the SSL VPN
security in the FortiGate unit and the SSL security in the web browser. After the
connection has been established, the FortiGate unit provides access to selected services
and network resources through a web portal.
FortiGate SSL VPN web portals have a 1- or 2-column page layout with selectable color
schemes. Portal functionality is provided through small applets called widgets. Widget
windows can be moved or minimized. The controls within each widget depend on its
function. There are pre-defined web portals and the administrator can create additional
portals.
Configuring the FortiGate unit involves enabling the SSL VPN feature and selecting the
appropriate web portal configuration in the user group settings. These configuration
settings determine which server applications can be accessed. SSL encryption is used to
ensure traffic confidentiality.
For information about client operating system and browser requirements, see the Release
Notes for your FortiGate firmware.
Tunnel mode
Tunnel mode offers remote users the freedom to connect to the internal network using the
traditional means of web-based access from laptop computers, as well as from airport
kiosks, hotel business centers, and Internet cafés. If the applications on the client
computers used by your user community vary greatly, you can deploy a dedicated SSL
VPN client to any remote client through its web browser. The SSL VPN client encrypts all
traffic from the remote client computer and sends it to the FortiGate unit through an SSL
VPN tunnel over the HTTPS link between the web browser and the FortiGate unit. Also
available is split tunneling, which ensures that only the traffic for the private network is
sent to the SSL VPN gateway. Internet traffic is sent through the usual unencrypted route.
This conserves bandwidth and alleviates bottlenecks.

01-420-99686-20101026 1183
Single Sign-on (SSO) Introduction to SSL VPN
In tunnel mode, remote clients connect to the FortiGate unit and the web portal login page
using Microsoft Internet Explorer, Mozilla Foundation/Firefox, Mac OS, or Linux. The
FortiGate unit acts as a secure HTTP/HTTPS gateway and authenticates remote users as
members of a user group. After successful authentication, the FortiGate unit redirects the
web browser to the web portal home page dictated by the user group settings. If the user
does not have the SSL VPN client installed, they will be prompted to download the SSL
VPN client (an ActiveX or Java plugin) and install it using controls provided through the
web portal. SSL VPN tunnel mode can also be initiated from a standalone application on
Windows, Mac OS, and Linux.
When the user initiates a VPN connection with the FortiGate unit through the SSL VPN
client, the FortiGate unit establishes a tunnel with the client and assigns the client a virtual
IP address from a range of reserved addresses. The client uses the assigned IP address
as its source address for the duration of the connection. After the tunnel has been
established, the user can access the network behind the FortiGate unit.
Configuring the FortiGate unit to establish a tunnel with remote clients involves enabling
the feature through SSL VPN configuration settings and selecting the appropriate web
portal configuration for tunnel-mode access in the user group settings. The firewall policy
and protection profiles on the FortiGate unit ensure that inbound traffic is screened and
processed securely.
Note: The user account used to install the SSL VPN client on the remote computer must
have administrator privileges.
Note: If you are using Windows Vista, you must disable UAC (User Account Control) before
installing the SSL VPN tunnel client. This UAC setting must be disabled before the SSL
VPN tunnel client is installed. IE7 in Windows Vista runs in Protected Mode by default. To
install SSL VPN client ActiveX, you need to launch IE7 by using 'Run as administrator'
(right-click the IE7 icon and select 'Run as administrator').
For information about client operating system requirements, see the Release Notes for
your FortiGate firmware.
Single Sign-on (SSO)

The web portal can provide bookmarks to connect to network resources. A web
(HTTP/HTTPS) bookmark can include login credentials so that the FortiGate unit
automatically logs the user into the web site. This means that the user logs into the SSL
VPN and then does not have to enter any more credentials to visit preconfigured web
sites.
Both the administrator and the end user can configure bookmarks, including SSO
bookmarks.
To add bookmarks as an administrator, see “Adding, editing, or deleting bookmarks” on
page 1203. To add bookmarks as a web portal user, see “Adding bookmarks” on
page 1230.

1184 01-420-99686-20101026
Setting up the FortiGate unit
This section describes how to configure the FortiGate unit as an SSL VPN server. The
following topics are included in this section:
• Configuring SSL VPN settings
• Configuring SSL VPN web portals
• Configuring user accounts and user groups for SSL VPN
• Configuring firewall policies
• Viewing SSL VPN logs
• Monitoring active SSL VPN sessions
• Troubleshooting
Before you begin

Before you begin, install your choice of HTTP/HTTPS, telnet, SSH, FTP, SMB/CIFS, VNC,
and/or RDP server applications on the internal network. As an alternative, these services
may be accessed remotely through the Internet. All services must be running to be
accessible. Users must have individual user accounts to access the servers (these user
accounts are not related to FortiGate user accounts or FortiGate user groups). For
information about creating such user accounts, refer to the documentation for the server
applications or Internet-based services.
You can configure and manage the FortiGate unit through a secure HTTP (HTTPS)
connection from any computer running a web browser. For information about how to
connect to the web-based manager, see “Connecting to the web-based manager” in the
FortiGate Installation Guide.
Note: As an alternative, you can connect the management computer to the Console
connector of the FortiGate unit directly using a serial cable and configure the FortiGate unit
through the Command Line Interface (CLI). The CLI can also be launched from within the
web-based manager. For more information, see “Connecting to the FortiGate console” in
Refer to the FortiGate Installation Guide and FortiGate Administration Guide to change the
password, configure the interfaces of the FortiGate unit, and assign basic operating
parameters, including a default gateway.
Refer also to the “Examples” chapter for example SSL VPN configurations.

01-420-99686-20101026 1185
General configuration steps Setting up the FortiGate unit

For best results in configuring FortiGate SSL VPN technology, follow the procedures in the
order given. Also, note that if you perform any additional actions between procedures,
your configuration may have different results.
1 Enable SSL VPN connections and set the basic options needed to support SSL VPN
configurations. See “Configuring SSL VPN settings” on page 1186.
2 Create a web portal to define user access to network resources. If you want to provide
different types of access to different groups of users, you need to create multiple web
portals. See “Configuring SSL VPN web portals” on page 1193.
3 Create user accounts for the remote clients. Create SSL VPN user groups and
associate them with the web portal or portals that you created. Assign users to the
appropriate SSL VPN user groups. See “Configuring user accounts and user groups
for SSL VPN” on page 1212.
4 Configure the firewall policies and the remaining parameters needed to support the
VPN mode of operation. See “Configuring firewall policies” on page 1214.
5 For tunnel-mode operation, add routing to ensure that client tunnel-mode packets
reach the SSL VPN interface. see “Configuring routing for tunnel mode” on page 1219.
6 Optionally, define SSL VPN event-logging parameters, and monitor active SSL VPN
sessions. See “Viewing SSL VPN logs” on page 1222, and “Monitoring active SSL
VPN sessions” on page 1224.
If you have problems during SSL VPN configuration in this chapter, see “Troubleshooting”
on page 1225 for assistance.
Configuring SSL VPN settings

To configure SSL VPN operation, you must at minimum perform the following procedures:
• “Enabling SSL VPN operation” on page 1187.
• “Specifying an IP address range for tunnel-mode clients” on page 1187
(required only for tunnel-mode).
As part of the SSL VPN configuration, you can also make the modifications described in
the following sections:
• “Adding WINS and DNS services for clients” on page 1188.
• “Setting the idle timeout setting” on page 1189.
• “Setting the client authentication timeout” on page 1189.
• “Specifying the cipher suite for SSL negotiations” on page 1189.
The cipher suite determines the level of data security, but it must be compatible with
the capabilities of the clients’ browsers.
• “Enabling strong authentication through X.509 security certificates” on page 1190.
• “Changing the port number for web portal connections” on page 1191.
By default, SSL VPN connections use port 10443.
• “Customizing the web portal login page” on page 1192.
Most of these settings are on the VPN > SSL > Config page in the web-based manager
and config vpn ssl settings in the CLI. You can configure multiple settings at the
same time.

1186 01-420-99686-20101026
Setting up the FortiGate unit Configuring SSL VPN settings
Figure 147: SSL VPN Settings
Enabling SSL VPN operation

You must enable SSL VPN operation so that the FortiGate unit will respond to SSL VPN
connection requests. Also, some elements of SSL VPN configuration are not available
unless SSL VPN is enabled. Selecting the default SSL VPN settings will be sufficient for
our purposes here.
To enable SSL VPN operation - web-based manager

3 Select Apply.
To enable SSL VPN operation - CLI

set sslvpn-enable enable
end
Specifying an IP address range for tunnel-mode clients

After the FortiGate unit authenticates a request for a tunnel-mode connection, the
FortiGate unit assigns the SSL VPN client an IP address that it uses for the session. The
address is assigned from an “IP Pool” which is a firewall address that defines an IP
address range.
You can specify tunnel-mode IP Pools in two places:
• The VPN > SSL > Config page IP Pools setting applies to all web portals that do not
specify their own IP Pools.
• The web portal Tunnel Mode widget IP Pools setting, if used, applies only to the web
portal and overrides the setting in VPN > SSL > Config. See “Configuring tunnel mode
settings” on page 1199.

01-420-99686-20101026 1187
Configuring SSL VPN settings Setting up the FortiGate unit
Caution: Take care to prevent overlapping IP addresses. Do not assign to clients any IP
addresses that are already in use on the private network. As a precaution, consider
assigning IP addresses from a network that is not commonly used (for example,
10.254.254.0/24).
To set tunnel-mode client IP address range - web-based manager

2 Enter an Address Name, for example, SSL_VPN_tunnel_range.
3 In the Subnet/IP Range field, enter the starting and ending IP addresses that you want
to assign to SSL VPN clients, for example 10.254.254.[80-100].
4 In Interface, select Any.
5 Select OK.
7 In IP Pools, select Edit.
Note: When you select Edit, a popup window will open. If your browser blocks popup
windows, you will have to unblock it to continue with the following steps.
8 In the Available list, select the address you created for the SSL VPN tunnel range and
then select the down arrow button to move it to the Selected list. Select OK.
9 Select Apply.
To set tunnel-mode client IP address range - CLI

If your SSL VPN tunnel range is for example 10.254.254.80 - 10.254.254.100, you could
enter
edit SSL_tunnel_users
set type iprange
set end-ip 10.254.254.100
set start-ip 10.254.254.80
end
end
set tunnel-ip-pools SSL_tunnel_users
end
Adding WINS and DNS services for clients

You can specify the WINS or DNS servers that are made available to SSL-VPN clients.
DNS servers provide the IP addresses that browsers need to access web sites. For
Internet sites, you can specify the DNS server that your FortiGate unit uses. If SSL VPN
users will access intranet sites using URLs, you need to provide them access to the
intranet’s DNS server. You specify a primary and a secondary DNS server.
A WINS server provides IP addresses for named servers in a Windows domain. If SSL
VPN users will access a Windows network, you need to provide them access to the
domain WINS server. You specify a primary and a secondary WINS server.
To specify WINS and DNS services for clients - web-based manager


1188 01-420-99686-20101026
2 Select the Expand Arrow to display the Advanced section.

3 Enter the IP addresses of DNS servers in the DNS Server fields as needed.
4 Enter the IP addresses of WINS servers in the WINS Server fields as needed.
5 Select Apply.
To specify WINS and DNS services for clients - CLI

set dns-server1 <address_ipv4>
set dns-server2 <address_ipv4>
set wins-server1 <address_ipv4>
set wins-server2 <address_ipv4>
end
Setting the idle timeout setting

The idle timeout setting controls how long the connection can remain idle before the
system forces the remote user to log in again. For security, keep the default value of 300
seconds or less.
To set the idle timeout - web-based manager

2 In the Idle Timeout field, enter the timeout value.
The valid range is from 10 to 28800 seconds.
3 Select Apply.
To set the idle timeout - CLI

set idle-timeout <seconds_int>
end
Setting the client authentication timeout

The client authentication timeout controls how long an authenticated connection will
remain connected. When this time expires, the system forces the remote client to
authenticate again. As with the idle timeout, a shorter period of time is more secure.
Note: The default value is 28800 seconds (8 hours). You can only modify this timeout value
in the CLI.
For example, to change the authentication timeout to 18 000 seconds, enter the following
commands:
set auth-timeout 18000
end
Specifying the cipher suite for SSL negotiations

The FortiGate unit supports a range of cryptographic cipher suites to match the
capabilities of various web browsers. The web browser and the FortiGate unit negotiate a
cipher suite before any information (for example, a user name and password) is
transmitted over the SSL link.

01-420-99686-20101026 1189
To set the encryption algorithm - web-based manager

2 In Encryption Key Algorithm, select one of the following options:
• If the web browser on the remote client is capable of matching a 128-bit or greater
cipher suite, select Default - RC4(128 bits) and higher.
• If the web browser on the remote client is capable of matching a high level of SSL
encryption, select High - AES(128/256 bits) and 3DES. This option enables cipher
suites that use more than 128 bits to encrypt data.
• If you are not sure which level of SSL encryption the remote client web browser
supports, select Low - RC4(64 bits), DES and higher. The web browser must at least
support a 64-bit cipher length.
3 Select Apply.
To set the encryption algorithm - CLI

set algorithm {default | high | low}
end
Enabling strong authentication through X.509 security certificates

The FortiGate unit supports strong (two-factor) authentication through X.509 security
certificates (version 1 or 3). The FortiGate unit can require clients to authenticate using a
certificate. Similarly, the client can require the FortiGate unit to authenticate using a
certificate.
For information about obtaining and installing certificates, see the FortiGate Certificate
Management User Guide.
Configuring the FortiGate unit to require strong client authentication

To require clients to authenticate using certificates, select the Require Client Certificate
option in SSL VPN settings. The client browser must have a local certificate installed, and
the FortiGate unit must have the corresponding CA certificate installed.
When the remote client initiates a connection, the FortiOS™ Handbook unit prompts the
client browser for its client-side certificate as part of the authentication process.
To require client authentication by security certificates - web-based manager

2 Select Require Client Certificate.
3 Select Apply.
To require client authentication by security certificates - CLI

set reqclientcert enable
end
Configuring the FortiGate unit to provide strong authentication

If your SSL VPN clients require strong authentication, the FortiGate unit must offer a
certificate for which the client browser has the CA certificate installed.

1190 01-420-99686-20101026
In the FortiGate unit SSL VPN settings, you can select which certificate the FortiGate
offers to authenticate itself. By default, the FortiOS™ Handbook unit offers its factory
installed (self-signed) certificate from Fortinet to remote clients when they connect.
To enable FortiGate unit authentication by certificate - web-based manager

2 From the Server Certificate list, select the certificate that the FortiGate unit uses to
identify itself to SSL VPN clients.
3 Select Apply.
To enable FortiGate unit authentication by certificate - CLI

For example, to use the example_cert certificate
set servercert example_cert
end
Changing the port number for web portal connections

You can optionally specify a different TCP port number for users to access the web portal
login page through the HTTPS link. By default, the port number is 10443 and users can
access the web portal login page using the following default URL:
https://<FortiGate_IP_address>:10443/remote/login
where <FortiGate_IP_address> is the IP address of the FortiGate interface that accepts
connections from remote users.
Note: If you change the TCP port number, remember to notify your SSL VPN clients. They
must use the new port number to connect to the FortiGate unit.
To change the SSL VPN port - web-based manager

1 If Current VDOM appears at the bottom left of the screen, select Global from the list of
VDOMs.
3 Type an unused port number in SSLVPN Login Port, and select Apply.
Note: Do not select port number 443 for user access to the web portal login page. Port
number 443 is reserved to support administrative connections to the FortiGate unit through
To change the SSL VPN port - CLI

This is a global setting. For example, to set the SSL VPN port to 10443, enter:
config global
set sslvpn-sport 10443
end

01-420-99686-20101026 1191
Customizing the web portal login page

The default web portal login page shows only the Name and Password fields and the
Login button, centred in the web browser window. You can customize the page with your
company name or other information.
Figure 148: Default SSL VPN web portal login page
The login page is a replacement message composed of HTML code, which you can
modify. Global replacement messages apply to all VDOMs by default, but individual
VDOMs can define their own messages.
To configure the SSL VPN login page - web-based manager

1 If you want to edit the global login page and Current VDOM appears at the bottom left
of the screen, select Global from the list of VDOMs.
2 Go to System > Config > Replacement Messages.
3 Expand the SSL VPN row and select the Edit icon for the SSL VPN login message.
Caution: Before you begin, copy the default web portal login page text to a separate
text file for safe-keeping. Afterward, if needed you can restore the text to the original
version.
4 Edit the HTML text, subject to the following restrictions:

• The login page must be an HTML page containing a form with
ACTION="%%SSL_ACT%%" and METHOD="%%SSL_METHOD%%"
• The form must contain the %%SSL_LOGIN%% tag to provide the login form.
• The form must contain the %%SSL_HIDDEN%% tag.

1192 01-420-99686-20101026
Setting up the FortiGate unit Configuring SSL VPN web portals
5 Select OK.
To configure the SSL VPN login page - CLI

Do one of the following:
• If VDOMs are enabled and you want to modify the global login page, enter:
config global
config system replacemsg sslvpn sslvpn-login
• If you want to modify the login page for a VDOM, enter:
config vdom
edit <vdom_name>
config system replacemsg-group
edit default
config sslvpn
edit sslvpn-login
To change the login page content, enter the modified page content as a string. In this
example, the page title is changed to “Secure Portal login” and headings are added above
the login dialog which say “example.com Secure Portal”:
set buffer "<html><head><title>Secure Portal login</title>
<meta http-equiv="Pragma" content="no-cache"><meta http-
equiv="cache-control" content="no-cache"> <meta http-
equiv="cache-control" content="must-revalidate"><link
href="/sslvpn/css/login.css" rel="stylesheet"
type="text/css"><script type="text/javascript">if (top &&
top.location != window.location) top.location =
top.location;if (window.opener && window.opener.top) {
window.opener.top.location = window.opener.top.location;
self.close(); }</script></head><body class="main">
<center><table width="100%" height="100%" align="center"
class="container" valign="middle" cellpadding="0"
cellspacing="0"><tr valign=top><td align=center>
<h1>example.com</h1><h3>Secure Portal</h3></td></tr><tr
valign=top><td><form action="%%SSL_ACT%%"
method="%%SSL_METHOD%%" name="f"><table class="list"
cellpadding=10 cellspacing=0 align=center width=400
height=180>%%SSL_LOGIN%%</table>%%SSL_HIDDEN%%</td></tr></
table></form></center></body><script>document.forms[0].use
rname.focus();</script></html>"
end
Your console application determines how the text wraps. It is easier to edit the code in a
separate text editor and then paste the finished code into the set buffer command. Be
sure to enclose the entire string in quotation (") marks.
Configuring SSL VPN web portals

A web portal defines SSL VPN user access to network resources, such as HTTP/HTTPS,
telnet, FTP, SMB/CIFS, VNC, RDP and SSH. The portal configuration determines what
SSL VPN users see when they log in to the FortiGate. Both the FortiGate administrator
and the SSL VPN user have the ability to customize the web portal.
At minimum, you need to set up one web portal. See “Configuring basic web portal
settings” on page 1196. For each portal, you can configure additional security features:

01-420-99686-20101026 1193
Configuring SSL VPN web portals Setting up the FortiGate unit
• “Configuring host checking” on page 1207

Check that client computers are running security software.
• “Configuring cache cleaning” on page 1209
Remove session information from the client’s computer after logout.
• “Configuring virtual desktop” on page 1209
Provide a separate Windows desktop environment while connected to the VPN.
Control which applications users can run on their virtual desktop using virtual desktop
application control.
• “Configuring client OS Check” on page 1211
Check that the client’s Windows operating system is up-to-date.
Before you begin

To begin configuring web portals, you need to know how many distinct sets of user access
privileges you need. For example, you might have users who are allowed only RDP
access to their desktop PCs, other users who have access to office file shares, and a third
category of users who will have both types of access. In this case, you need to create a
web portal for each of these access types. Later, you will create SSL VPN user groups that
assign the users to the appropriate portal.
One of the pre-defined web portals might meet your needs. See “Default web portal
configurations”. If needed, you can modify these portals using the procedures in this
section.
Default web portal configurations

There are three pre-defined default web portal configurations available:
• full-access: Includes all widgets available to the user - Session Information,
Connection Tool, Bookmarks, and Tunnel Mode.
• tunnel-access: Includes Session Information and Tunnel Mode widgets.
• web-access: Includes Session Information and Bookmarks widgets.

1194 01-420-99686-20101026
Figure 149: Default web portals
Default full-access web portal
Figure 150: Default tunnel-access web portal

01-420-99686-20101026 1195
Figure 151: Default web access web portal
You can modify a default portal or a portal that you have already defined. Select the Edit
icon next to the web portal in the Portal list. The SSL VPN web portal you select will open.
Configuring basic web portal settings

This section describes the basic configuration to enable users to access web resources
through the portal.
To configure basic web portal settings - web-based manager

1 Go to VPN > SSL > Portal and do one of the following:
• Select Create New.
• Select an existing portal, select Edit, then select Settings.
The web portal settings dialog box opens.
Figure 152: Web portal settings
Name Enter a name to identify this web portal.

Applications Select the applications that users can access through this web portal.
Portal Message Enter the text that will appear at the top of the web portal window.
Theme Select the color scheme for this web portal.
Page Layout Select either the single-column or two-column layout.
Redirect URL The web portal can display a second HTML page in a popup window
when the web portal home page is displayed. Enter the URL.
3 Optionally, you can select the Virtual Desktop tab to configure the Virtual Desktop
feature. See “Configuring virtual desktop” on page 1209. Or, you can leave this
configuration for later.

1196 01-420-99686-20101026
4 Optionally, you can select the Security Control tab to configure cache cleaning and
client check. Or, you can leave this configuration for later.
For information on these features, see “Configuring cache cleaning” on page 1209 and
“Configuring host checking” on page 1207.
5 Select OK.
The web portal is displayed.
6 Select Apply to save the settings.
To configure basic web portal settings - CLI

To use the orange theme with a two-column layout and allow users all types of access with
the full-access portal, you could enter:
config vpn ssl web portal
edit full-access
set allow-access ftp ping rdp smb ssh telnet vnc web
set heading "Welcome to the example.com web portal"
set theme orange
set page-layout double-column
end
In the config vpn ssl web portal command, you can also configure client check,
client OS check, cache cleaning, and virtual desktop. Or, you can leave this configuration
for later. These features are described later in this chapter.
Configuring the web portal page layout

You can determine which widgets are displayed on the web portal page and adjust the
layout.
Figure 153: Configuring the SSL VPN web portal page

Log out (for user only)
Help icon (for user only)
Edit Remove
Add Widget list

01-420-99686-20101026 1197
To configure the web portal page - web-based manager

On the web portal page itself, you, as administrator, can make several adjustments to the
appearance of the portal:
• Arrange widgets on the page by dragged them by their title bar.
• Add a widget by choosing a widget from the Add Widget list.
• Remove a widget by selecting the Remove icon in the widget title bar.
• Configure a widget by selecting the Edit icon in the widget title bar. For configuration
information about each widget type, see the following sections:
• “Configuring tunnel mode settings” on page 1199
• “Configuring the Session Information widget” on page 1202
• “Configuring the Connection Tool widget” on page 1206
• “Adding, editing, or deleting bookmarks” on page 1203
• To modify the color scheme and other basic settings, select the Settings button. See
“Configuring basic web portal settings” on page 1196. You can also configure several
advanced features. For more information, see
• “Configuring host checking” on page 1207
• “Configuring cache cleaning” on page 1209
• “Configuring virtual desktop” on page 1209
• “Configuring client OS Check” on page 1211 (CLI only)
When you have finished configuring the web portal page, select Apply to save the
modifications.
To configure the web portal page - CLI

You can also define a portal layout using CLI commands. Unlike configuring with the web-
based manager, a new portal created in the CLI has by default no heading and no widgets.
Also, the widgets do not have default names. You must specify all of this information.
For example, to create the portal layout shown in Figure 153 on page 1197, you would
enter:
set heading "Welcome to SSL VPN Service"
set page-layout double-column
set theme blue
edit myportal
config widget
edit 0
set type info
set name "Session Information"
set column one
next
edit 0
set type bookmark
set name "Bookmarks"
set column one
next
edit 0
set type tunnel
set name "Tunnel Mode"
set column two

1198 01-420-99686-20101026
next
edit 0
set type tool
set name "Connection Tool"
set column two
end
Note: When you use edit 0, as in this example, the CLI automatically assigns an unused
index value when you exit the edit shell by typing end.
Adding a custom caption to the web portal home page

You can add a custom caption (maximum 31 characters) to the top of the web portal home
page.
To add a custom web portal caption - web-based manager

1 Go to VPN > SSL > Portal.
2 Select the portal and then select Edit.
3 Select Settings.
4 Type the caption in the Portal Message field, and select OK.
To add a custom web portal caption - CLI

For example, to apply a custom caption to portal2, you could enter:
edit portal2
set heading "Welcome to the example.com portal"
end
Configuring tunnel mode settings

If your web portal provides tunnel mode access, you need to configure the Tunnel Mode
widget. These settings determine how tunnel mode clients are assigned IP addresses.
If this web portal will assign a different range of IP addresses to clients than the IP Pools
you specified on the VPN > SSL > Config page, you need to define a firewall address for
the IP address range that you want to use. You will then need to specify this address in the
Tunnel Mode widget IP Pools setting.
Optionally, you can enable a split tunneling configuration so that the VPN carries only the
traffic for the networks behind the FortiGate unit. The user’s other traffic follows its normal
route.
To configure tunnel mode settings - web-based manager

• Create a new web portal and complete the basic configuration. See “Configuring
basic web portal settings” on page 1196.
• Go to VPN > SSL > Portal and select an existing portal and then select Edit.
2 If the Tunnel Mode widget is missing, add it by selecting Tunnel Mode from the Add
Widget list in the top right corner of the window.
3 Select the Edit icon in the Tunnel Mode widget title bar.

01-420-99686-20101026 1199
Figure 154: Tunnel Mode widget - edit mode
Tunnel mode settings
Tunnel controls
(for users only)
Name Enter a name for the Tunnel Mode widget. The default is “Tunnel Mode”.
IP Mode Select the mode by which the IP address is assigned to the user.
Range The user IP address is allocated from the IP address ranges specified by
IP Pools.
User Group The user is assigned the IP address specified in the Framed-IP-Address
field of the user’s record on the RADIUS server. This option is valid only for
users authenticated by a RADIUS server.
IP Pools Leave this field empty to use the IP address range specified by the IP Pools
field on the VPN > SSL > Config page.
If you want to specify an IP address range for clients of this portal only,
select Edit. From the Available list, select the appropriate firewall address.
You must configure the desired IP address range as a firewall address
before you can select it here.
Split Tunneling Select to enable split tunneling. When enabled, only traffic that requires the
SSL VPN is sent through the tunnel. Other traffic follows the user’s regular
routing.
When split tunneling is disabled, all of the user’s traffic with other networks
passes through the tunnel. This does not affect traffic between the user’s
computer and hosts on the local network.
For enhanced security, some administrators prefer to force all traffic through
the SSL VPN tunnel, including traffic between the user and the user’s local
network. To do this, use the CLI tunnel mode settings to enable
exclusive-routing.
The remaining items in the widget are controls that are available to the user during an
SSL VPN session.
5 Select OK in the Tunnel Mode widget.
6 Select Apply.
To configure tunnel mode settings - CLI

To enable tunnel mode operation for portal2 portal users and assign them addresses from
the SSLVPN_TUNNEL_ADDR2 range, you would enter:
edit portal2
config widget
edit 0
set type tunnel
set tunnel-status enable
set ip-mode range
set ip-pools SSLVPN_TUNNEL_ADDR2

1200 01-420-99686-20101026
end
end
The preceding example applies to a web portal that does not already have a tunnel mode
widget. To modify the settings on an existing tunnel mode widget, you need to determine
the widget’s number. Enter:
edit portal1
config widget
show
In the output, you will see, for example,
edit 3
set name "Tunnel Mode"
set type tunnel
...
You can now enter edit 3 and modify the tunnel mode widget’s settings.
To force all traffic through the tunnel - CLI

If you disable split tunneling, all of the user’s traffic to other networks passes through the
SSL VPN tunnel. But, this does not apply to traffic between the user and the user’s local
network. For enhanced security, some administrators prefer to force all of the user’s traffic,
including traffic with the local network, to pass through the SSL VPN tunnel. To do this,
enable exclusive-routing in the tunnel widget settings. For example:
edit portal2
config widget
edit 0
set type tunnel
set ip-mode range
set ip-pools SSLVPN_TUNNEL_ADDR2
set split-tunneling disable
set set exclusive-routing enable
end
end

01-420-99686-20101026 1201
Configuring the Session Information widget

The Session Information widget displays the login name of the user, the amount of time
the user has been logged in, and the inbound and outbound traffic statistics of HTTP and
HTTPS. You can change the widget name.
To edit the session information, in the Session Information widget select Edit.
Figure 155: Session Information widget - Edit
Remove widget
Edit 1
Edit Select to edit the information in the widget.

Remove widget Select to close the widget and remove it from the web portal home
page.
OK Select to save the Session Information configuration.
Cancel Select to exit the Session Information widget without saving any
changes.
Name Enter a customized name for the Session Information widget.
To configure Session Information settings - CLI

To change the name of the web-access Session Information widget to “My Session”, you
would enter:
edit web-access
config widget
edit 4
set name "My Session"
end
Configuring the Bookmarks widget

Bookmarks are used as links to specific resources on the network. When a bookmark is
selected from a bookmark list, a pop-up window appears with the requested web page.
Telnet, VNC, and RDP all pop up a window that requires a browser plug-in. FTP and
Samba replace the bookmarks page with an HTML file-browser.

1202 01-420-99686-20101026
To configure the Bookmarks widget

• Go to VPN > SSL > Portal, select an existing portal and then select Edit.
2 If the Bookmarks widget is missing, add it by selecting Bookmarks from the Add Widget
list in the top right corner of the web portal window.
3 Select the Edit icon in the Bookmarks widget title bar.
Widget configuration
Bookmarks list
4 Optionally, you can change the Name of the Bookmarks widget.

5 Select the Applications check boxes for the types of bookmarks that you want to
support.
6 Select OK.
Adding, editing, or deleting bookmarks

You can add bookmarks to the Bookmarks widget. These bookmarks are available to
users of the SSL VPN web portal. If needed, you can also modify existing bookmarks.
To delete bookmarks
1 Open the web portal.
2 In the Bookmarks widget, select the Edit button.
Figure 156: Deleting bookmarks
Delete
3 Select the X to the right of the bookmark that you want to delete.
4 Select Done.
To add or edit bookmarks - web-based manager

1 Open the web portal.
2 In the Bookmarks widget, do one of the following:
• To add a bookmark, select Add.
• To edit an existing bookmark, select the Edit button and then select the bookmark.

01-420-99686-20101026 1203
3 Enter or edit the following information:
Adding
Editing
Name Enter a name for the bookmark.

Type Select the type of application to which the bookmark links. For example, select
HTTP/HTTPS for a web site.
Only the application types that you configured for this widget are in the list. You
can select Edit in the widget title bar to enable additional application types. See
“Configuring the Bookmarks widget” on page 1202.
Location Enter the destination of the bookmark.
For HTTP, enter the URL or just the hostname.
For HTTPS, enter the URL.
For RDP, VNC, Telnet or SSH, enter the hostname.
For FTP or SMB, enter hostname or //<hostname>/<path>.
Description Optionally, enter a descriptive tooltip for the bookmark.
SSO A Single Sign-On (SSO) bookmark automatically enters the login credentials
for the bookmark destination. Select one of:
Disabled — This is not an SSO bookmark.
Automatic — Use the user’s SSL VPN credentials for login.
Static — Use the login credentials defined below.
Single Sign-On settings available when SSO is Static
Field Name Enter a required login page field name, “User Name” for example.
Value Enter the value to enter in the field identified by Field Name.
If you are an administrator configuring a bookmark for users:
• Enter %usrname% to represent the user’s SSL VPN user name.
• Enter %passwd% to represent the user’s SSL VPN password.
Add Enter another Field Name / Value pair, for the password for example.
A new set of Field Name / Value fields is added. Fill them in.
4 Select OK.
5 If there is a Done button, you can select another bookmark to edit or select Done to
leave the edit mode.
6 Select Apply at the top of the web portal page to save the changes that you made.

1204 01-420-99686-20101026
To configure the Bookmarks widget and add/edit bookmarks - CLI

To allow only FTP and web connections on the web-access portal and to configure a
bookmark to example.com, you would enter:
edit web-access
config widget
edit 1
set type bookmark
set allow-apps ftp web
config bookmarks
edit "example"
set apptype web
set description "example bookmark"
set url "http://example.com"
end
end
end
To delete bookmarks - CLI

To delete the bookmark added above, you would enter:
edit web-access
config widget
edit 1
config bookmarks
delete example
end
end
end

01-420-99686-20101026 1205
Configuring the Connection Tool widget

The Connection Tool enables a user to connect to resources for which there are no
bookmarks.
To configure the Connection Tool widget

• Go to VPN > SSL > Portal, select an existing portal and then select Edit.
2 If the Connection Tool widget is missing, add it by selecting Connection Tool from the
Add Widget list in the top right corner of the web portal window.
3 Select the Edit icon in the Connection Tool widget title bar.
Widget configuration
Connection controls
(for user only)
4 Optionally, enter a new Name for the widget.

5 Select the types of Applications (protocols and services) that the Connection Tool is
enabled to access.
6 Select OK.
To configure the Connection Tool widget - CLI

To change, for example, the full-access portal Connection Tool widget to allow all
application types except Telnet, you would enter:
edit full-access
config widget
edit 3
set allow-apps ftp rdp smb ssh vnc web}
end
end
end

1206 01-420-99686-20101026
Configuring host checking

To increase the security of your network, you can require your SSL VPN clients to have
antivirus or firewall software installed on their computers. Only clients that meet the
requirements are permitted to log on.
To configure host checking - web-based manager

1 Go to VPN > SSL > Portal.
2 Select the web portal and then select Edit.
3 Select the Settings button.
4 Select the Security Control tab and enter the following information:
Host Check Select the type of host check to perform.

AV Check for a running antivirus application recognized by the Windows
Security Center.
FW Check for a running firewall application recognized by the Windows
Security Center.
AV-FW Check for both an antivirus application and a firewall application
recognized by the Windows Security Center.
Custom Check for security applications that you choose from the VPN > SSL >
Host Check page. See the Policy field.
None Select to disable host checking.
Interval Select how often to recheck the host. Range is every 120 seconds to
259 200 seconds. Enter 0 to not recheck the host during the session.
Policy This field is available if Host Check is Custom. It lists the acceptable
security applications for clients.
Select Edit to choose the acceptable security applications. Use the arrow
buttons to move applications between the Available and Selected lists.
Clients will be checked for the applications in the Selected list. Select OK.
The Available list contains the applications from VPN > SSL > Host Check
page. You can add or remove applications from the Host Check list. See
“Configuring the custom host check list” on page 1208.
5 Select OK.
To configure host checking - CLI

To configure the full-access portal to check for AV and firewall software on client Windows
computers, you would enter the following:
edit full-access
set host-check av-fw
end
To configure the full-access portal to perform a custom host check for FortiClient Host
Security AV and firewall software, you would enter the following:
edit full-access
set host-check custom
set host-check-policy FortiClient-AV FortiClient-FW
end

01-420-99686-20101026 1207
Configuring the custom host check list

If you configure a custom host check for your web portal (see “Configuring host checking”
on page 1207), you choose security applications from the list on the VPN > SSL >
Host Check page. The Host Check list includes default entries for many security software
products. You can add, remove, or modify entries in this list.
To add an entry to the Host Check list - web-based manager

1 Go to VPN > SSL > Host Check.
Name Enter a name for the application. The name does not need to match the
actual application name.
Type Select the type of security application. Can be AV for antivirus or FW for
firewall.
GUID Enter the Globally Unique IDentifier (GUID) for the host check application,
if known.
The GUID is usually in the form xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxx,
where each x is a hexadecimal digit. Windows uses GUIDs to identify
applications in the Windows Registry.
Version The version of the security application.
Add button If you do not know the GUID, add alternative checks for the application.
The security software is considered found only if all checks succeed.
Check Item entry These fields are available when you select the Add button.
Type Select how to check for the application:
• File — Look for a file. This could be the application’s executable file or
any other file that would confirm the presence of the application. In
File/Path, enter the full path to the file. Where applicable, you can use
environment variables enclosed in percent (%) marks. For example,
%ProgramFiles%\Fortinet\FortiClient\FortiClient.exe
• Process — Look for the application as a running process. In Process,
enter the application’s executable file name.
• Registry — Search for a Windows Registry entry. In Registry, enter a
registry item, for example
HKLM\SOFTWARE\Fortinet\FortiClient\Misc
Action Select one of
Require — If the item is found, the client meets the check item condition.
Deny — If the item is found, the client is considered to not meet the check
item condition. Use this option if it is necessary to prevent use of a
particular security product.
MD5 Signatures If Type is File or Process, enter one or more known MD5 signatures for
the application executable file.You can use a third-party utility to calculate
MD5 signatures or hashes for any file. You can enter multiple signatures
to match multiple versions of the application.
3 Select OK.
4 Select OK.

1208 01-420-99686-20101026
Configuring cache cleaning

When the SSL VPN session ends, the client browser cache may retain some information.
To enhance security, cache cleaning clears this information just before the SSL VPN
session ends.
Note: The cache cleaner is effective only if the session terminates normally. The cache is
not cleaned if the session ends due to a malfunction, such as a power failure.
To enable cache cleaning - web-based manager

1 Go to VPN > SSL > Portal, select the web portal and then select Edit.
3 Select the Security Control tab.
4 Select Clean Cache.
5 Select OK.
6 Select Apply.
To enable cache cleaning - CLI

To enable cache cleaning on the full-access portal, you would enter:
edit full-access
set cache-cleaner enable
end
Cache cleaning requires a browser plugin. If the user does not have the plugin, it is
automatically downloaded to the client computer.
Configuring virtual desktop

Available for Windows XP, Windows Vista, and Windows 7 client PCs, the virtual desktop
feature completely isolates the SSL VPN session from the client computer’s desktop
environment. All data is encrypted, including cached user credentials, browser history,
cookies, temporary files, and user files created during the session. When the SSL VPN
session ends normally, the files are deleted. If the session ends due to a malfunction, files
might remain, but they are encrypted, so the information is protected.
When the user starts an SSL VPN session which has virtual desktop enabled, the virtual
desktop replaces the user’s normal desktop. When the virtual desktop exits, the user’s
normal desktop is restored.
Virtual desktop requires the Fortinet cache cleaner plugin. If the plugin is not present, it is
automatically downloaded to the client computer.
To enable virtual desktop - web-based manager

1 Go to VPN > SSL > Portal, select the web portal and then select Edit.
3 Select the Virtual Desktop tab.
4 Select Enable Virtual Desktop.
5 Enable the other options as needed.
6 Optionally, select an Application Control List.
See “Configuring virtual desktop application control”.

01-420-99686-20101026 1209
7 Select OK.
8 Select Apply.
To enable virtual desktop - CLI

To enable virtual desktop on the full-access portal and apply the application control list
List1, for example, you would enter:
edit full-access
set virtual-desktop enable
set virtual-desktop-app-list List1
end
Configuring virtual desktop application control

You can control which applications users can run on their virtual desktop. To do this, you
create an Application Control List of either allowed or blocked applications. When you
configure the web portal, you select the list to use.
There are two types of application control list:
• allow the listed applications and block all others
or
• block the listed applications and allow all others.
You can create multiple application control lists, but each in web portal you can select only
one list to use.
To create an Application Control List - web-based manager

1 Go to VPN > SSL > Virtual Desktop Application Control and select Create New.
2 Enter a Name for the list.
3 Select one of the following:
• Allow the applications on this list and block all others
• Block the applications on this list and allow all others
4 Select Add.
5 Enter a Name for the application.
This can be any name and does not have to match the official name of the application.
6 Enter one or more known MD5 Signatures for the application executable file.
You can use a third-party utility to calculate MD5 signatures or hashes for any file. You
can enter multiple signatures to match multiple versions of the application.
7 Select OK.
8 Repeat steps 4 through 7 for each additional application.
9 Select OK.
To create an Application Control List - CLI

If, for example, you want to add BannedApp to List1, a list of blocked applications, you
would enter:
config vpn ssl web virtual-desktop-app-list
edit "List1"
set action block
config apps

1210 01-420-99686-20101026
edit "BannedApp"
set md5s "06321103A343B04DF9283B80D1E00F6B"
end
end
Configuring client OS Check

The SSLVPN client OS Check feature can determine if clients are running the
Windows 2000, Windows XP, Windows Vista or Windows 7 operating system. You can
configure the OS Check to do any of the following:
• allow the client access
• allow the client access only if the operating system has been updated to a specified
patch (service pack) version
• deny the client access
The OS Check has no effect on clients running other operating systems.
To configure OS Check - CLI

OS Check is configurable only in the CLI.
edit <portal_name>
set os-check enable
config os-check-list {windows-2000 | windows-xp
| windows-vista | windows-7}
set action {allow | check-up-to-date | deny}
set latest-patch-level {disable | 0 - 255}
set tolerance {tolerance_num}
end
end
Variable Description Default
set os-check Enable or disable SSL VPN OS patch level disable
{disable | enable} check. Default disable.
config os-check-list Configure the OS of the patch level check. No default.
{windows-2000 Available when os-check is set to enable.
| windows-xp
| windows-vista
| windows-7}
set action {allow | Specify how to perform the patch level check. allow
check-up-to-date | deny} • allow - any level is permitted
• check-up-to-date - some patch levels
are permitted. Make selections for latest-
patch-level and tolerance.
• deny - OS version is not permitted access
Available when os-check is set to enable.
set latest-patch-level Specify the latest allowed patch level. 2000: 4
{disable | 0 - 255} Available when action is XP, Vista: 2
check-up-to-date.
set tolerance Specify the allowable patch level tolerance. 0
{tolerance_num} Lowest acceptable patch level equals
latest-patch-level minus tolerance.
Available when action is set to
check-up-to-date.

01-420-99686-20101026 1211
Configuring user accounts and user groups for SSL VPN Setting up the FortiGate unit
Configuring user accounts and user groups for SSL VPN

Remote users must be authenticated before they can request services and/or access
network resources through the web portal. The authentication process can use a
password defined on the FortiGate unit or optionally use established external
authentication mechanisms such as RADIUS or LDAP.
You need to create a user account for each user and then add the users to an SSL VPN
user group. The user group specifies the web portal that users can access after they
authenticate.
Creating user accounts

The following procedure explains how to create a user account. To authenticate users, you
can use a plain text password on the FortiGate unit (Local domain), forward authentication
requests to an external RADIUS, LDAP or TACACS+ server, or utilize PKI certificates.
For information about how to create RADIUS, LDAP, TACACS+ or PKI user accounts, see
the “User” chapter of the FortiGate Administration Guide. For information about importing
certificates, see the “System Certificates” chapter of the FortiGate Administration Guide.
For information about certificate authentication, see the FortiGate Certificate Management
User Guide.
To create a user account - web-based manager

1 Go to User > User, select Create New, and enter the following information:
Figure 157: Creating a Local user
User Name Type or edit the remote user name (for example, User_1).
Disable Select to prevent this user from authenticating.
Password Select to authenticate this user using a password stored on the FortiGate unit,
and then enter the password. The password should be at least six characters
long.
LDAP Select to authenticate this user using a password stored on an LDAP server.
Select the LDAP server from the list. You can select only an LDAP server that
has been added to the FortiGate LDAP configuration.
RADIUS Select to authenticate this user using a password stored on a RADIUS server.
Select the RADIUS server from the list. You can select only a RADIUS server
that has been added to the FortiGate configuration.
TACACS+ Select to authenticate this user using a password stored on a TACACS+ server.
Select the TACACS+ server from the list. You can select only a TACACS+ server
that has been added to the FortiGate TACACS+ configuration.
2 Select OK.

1212 01-420-99686-20101026
Setting up the FortiGate unit Configuring user accounts and user groups for SSL VPN
To create a user account - CLI

If you want to create a user account, for example User_1 with the password “1_user”, you
would enter:
config user local
edit User_1
set passwd "1_User"
set status enable
set type password
end
Creating a user group for SSL VPN users

You must add users to a firewall user group. As part of configuring the user group, you
select the SSL VPN web portal that the members of this group access after authenticating.
To create an SSL VPN user group - web-based manager

1 Go to User > User Group > User Group, select Create New, and enter the following
information:
Figure 158: Configuring an SSL VPN user group
Name Type or edit the user group name (for example, Web-only_group).
Type Select Firewall.
Allow SSL-VPN Enable and select the SSL VPN web portal configuration to use with the
Access User Group. For more information, see “Configuring SSL VPN web portals”
on page 1193.
Available The list of Local users, RADIUS servers, LDAP servers, TACACS+ servers,
Users/Groups or PKI users that can be added to the user group. To add a member to this
list, select the name and then select the right arrow button.
Members The list of Local users, RADIUS servers, LDAP servers, TACACS+ servers,
or PKI users that belong to the user group. To remove a member, select the
name and then select the left arrow button.
2 Select OK.

01-420-99686-20101026 1213
Configuring firewall policies Setting up the FortiGate unit
To create an SSL VPN user group - CLI

To create the user group web_only associated with the web-access portal and add
members User_1, User_2, and User_3, you would enter:
config user group
edit web_only
set group-type sslvpn
set member User_1 User_2 User_3
set sslvpn-portal web-access
end

This section contains the procedures needed to configure firewall policies for web-only
mode operation and tunnel-mode operation. These procedures assume that you have
already completed the procedures outlined in “Configuring user accounts and user groups
for SSL VPN” on page 1212.
Firewall policies permit traffic to pass through the FortiGate unit. The FortiGate unit checks
incoming connection attempts against the list of firewall policies, looking to match:
• source and destination interfaces
• source and destination firewall addresses
• services
• time/schedule
If no policy matches, the connection is dropped. You should order the firewall policy list top
to bottom from most specific to most general. Only the first matching firewall policy is
applied to a connection, and you want the best match to occur first.
You will need at least one SSL VPN firewall policy. This is an identity-based policy that
authenticates users and enables them to access the SSL VPN web portal. The SSL VPN
user groups named in the policy determine who can authenticate and which web portal
they will use. From the web portal, users can access protected resources or download the
SSL VPN tunnel client application.
If you will provide tunnel mode access, you will need a second firewall policy — an
ACCEPT tunnel mode policy to permit traffic to flow between the SSL VPN tunnel and the
protected networks.
Figure 159: Example of firewall policies for SSL VPN
SSL VPN
policy
Internet browsing policy Tunnel mode policy

1214 01-420-99686-20101026
Setting up the FortiGate unit Configuring firewall policies
Configuring firewall addresses

Before you can create firewall policies, you need to define the firewall addresses you will
use in those policies. For both web-only and tunnel mode operation, you need to create
firewall addresses for all of the destination networks and servers to which the SSL VPN
client will be able to connect.
For tunnel mode, you will already have defined firewall addresses for the IP address
ranges that the FortiGate unit will assign to SSL VPN clients. See “Specifying an IP
address range for tunnel-mode clients” on page 1187.
The source address for your SSL VPN firewall policies will be the pre-defined “all”
address. If this address is missing, you can add it. Both the address and the netmask are
0.0.0.0. The “all” address is used because VPN clients will be connecting from various
addresses, not just one or two known networks. For improved security, if clients will be
connecting from one or two known locations you should configure firewall addresses for
those locations, instead of using the “all” address.
To create a firewall address

Figure 160: Firewall address
Address Name Enter a name to identify the firewall address. Addresses, address groups, and
virtual IPs must have unique names.
Type Select Subnet/IP Range.
Subnet / IP Enter the firewall IP address in any of the following formats:
Range • an IP address and a subnet mask, separated by a slash, for example
172.16.10.0/255.255.255.0
• a CIDR-format IP address with netmask, for example 172.16.10.0/24
• a single address, for example 172.16.10.3
• an IP address range, for example 172.16.10.[4-5]
Interface Select the interface, zone, or virtual domain (VDOM) link to which you want to
bind the IP address. Select Any if you want to bind the IP address to the
interface/zone when you create a firewall policy.
To create a firewall address - CLI

To create, for example, the address OfficeLAN for the protected network you would enter:
edit OfficeLAN
set type ipmask
set subnet 10.11.101.0/24
end

01-420-99686-20101026 1215
In the following example, there are firewall addresses defined for the protected network
OfficeLAN and the SSL VPN tunnel user IP address range SSL_tunnel_users. You can
also see the “all” preconfigured address.
Figure 161: Example firewall address list
Configuring the SSL VPN firewall policy

At minimum, you need one SSL VPN firewall policy to authenticate users and provide
access to the protected networks. You will need additional firewall policies only if you have
multiple web portals that provide access to different resources.
If you provide tunnel mode access, you will need a second firewall policy to permit traffic
between the SSL VPN tunnel and the protected networks. See “Configuring the tunnel
mode firewall policy” on page 1218.
The SSL VPN firewall policy is an identity-based policy that permits members of a
specified SSL VPN user group to access specified services according to a specified
schedule. The policy can also apply UTM features, traffic shaping and logging to SSL VPN
traffic.
The user group is associated with the web portal that the user sees after logging in. If you
have multiple portals, you will need multiple user groups. You can use one policy for
multiple groups, or multiple policies to handle differences between the groups such as
access to different services, or different schedules.
The SSL VPN firewall policy specifies:
• the source address that corresponds to the IP address of the remote user.
• the destination address that corresponds to the IP address or addresses that remote
clients need to access.
The destination address may correspond to an entire private network, a range of
private IP addresses, or the private IP address of a server or host.
Note: Do not use ALL as the destination address. If you do, you will see
the “Destination address of Split Tunneling policy is invalid” error when
you enable Split Tunneling.
• the level of SSL encryption to use and the authentication method

• which SSL VPN user groups can use the firewall policy
• the times (schedule) and types of services that users can access
• the UTM features and logging that are applied to the connection

1216 01-420-99686-20101026
To create an SSL-VPN firewall policy - web-based manager

Figure 162: Configuring a new SSL VPN firewall policy
Source Select the name of the FortiGate network interface to that connects to
Interface/Zone the Internet.
Source Address Select all.
Destination Select the FortiGate network interface that connects to the protected
Interface/Zone network.
Destination Address Select the firewall address you created that represents the networks and
servers to which the SSL VPN clients will connect.
If you want to associate multiple firewall addresses or address groups
with the Destination Interface/Zone, from Destination Address, select
Multiple. In the dialog box, move the firewall addresses or address
groups from the Available Addresses section to the Members section,
then select OK.
Action Select SSL-VPN. This option is available only if there is at least one
user group with SSL VPN access enabled.
SSL Client Certificate Allow access only to holders of a (shared) group certificate. The holders
Restrictive of the group certificate must be members of an SSL VPN user group,
and the name of that user group must be present in the Allowed field.
See “Enabling strong authentication through X.509 security certificates”
on page 1190.
Cipher Strength Select the bit level of SSL encryption. The web browser on the remote
client must be capable of matching the level that you select: Any,
High >= 164, or Medium >= 128.

01-420-99686-20101026 1217
Configure SSL-VPN A firewall policy for an SSL VPN is automatically an identity-based

Users policy.
Add Add a user group to the policy. The Edit Authentication Rule window
opens on top of the firewall policy. Enter the following information and
then select OK. You can select Add again to add more groups.
User Group Select user groups in the left list and use the right arrow button to move
them to the right list.
Service Select service in the left list and use the right arrow button to move them
to the right list. Select the ANY service to allow the user group access to
all services.
Schedule Optionally, select a Schedule for allowed access. The default is always.
Log Allowed Optionally log the traffic.
Traffic
UTM Optionally, apply UTM features to SSL VPN traffic for this user group.
Comments Optionally, add information about the policy. The maximum length is 63
characters.
3 Select OK.
Your identity-based policies are listed in the firewall policy table. The FortiGate unit
searches the table from the top down to find a policy to match the client’s user group.
Using the move icon in each row, you can change the order of the policies in the table
to ensure the best policy will be matched first. You can also use the icons to edit or
delete policies.
To create an SSL VPN firewall policy - CLI

To create the firewall policy shown in Figure 162 on page 1217, enter the following CLI
commands.
edit 0
set srcintf port1
set dstintf port2
set srcaddr all
set dstaddr OfficeLAN
set action ssl-vpn
set nat enable
edit 0
set groups SSL-VPN
set schedule always
set service ANY
end
end
Configuring the tunnel mode firewall policy

If your SSL VPN will provide tunnel mode operation, you need to create a firewall policy to
enable traffic to pass between the SSL VPN virtual interface and the protected networks.
This is in addition to the SSL VPN firewall policy that you created in the preceding section.
Similar to an IPsec virtual interface, the SSL VPN virtual interface is the FortiGate unit end
of the SSL tunnel that connects to the remote client. It is named ssl.<vdom_name>. In
the root VDOM, for example, it is named ssl.root. If VDOMs are not enabled on your
FortiGate unit, the SSL VPN virtual interface is also named ssl.root.

1218 01-420-99686-20101026
To configure the tunnel mode firewall policy - web-based manager

1 Go to Firewall > Policy> Policy and select Create New.
Source Interface/Zone Select the virtual SSL VPN interface, such as ssl.root.
Source Address Select the firewall address you created that represents the IP address
range assigned to SSL VPN clients, such as SSL_VPN_tunnel_users.
Destination Select the FortiGate network interface that connects to the protected
Interface/Zone network.
Destination Address Select the firewall address you created that represents the networks
and servers to which the SSL VPN clients will connect.
To select multiple firewall addresses or address groups, select
Multiple. In the dialog box, move the firewall addresses or address
groups from the Available Addresses section to the Members section,
then select OK.
Action Select Accept.
NAT Enable or disable Network Address Translation (NAT) of the source
address and port of packets accepted by the policy. When NAT is
enabled, you can also configure Dynamic IP Pool and Fixed Port.
If you select a virtual IP as the Destination Address, but do not select
the NAT option, the FortiGate unit performs destination NAT (DNAT)
rather than full NAT. Source NAT (SNAT) is not performed.
Enable NAT to use the IP address of the outgoing interface of the
FortiGate unit as the source address for new sessions started by SSL
VPN. Otherwise, disable NAT.
Comments Optionally, add information about the policy. The maximum length is 63
characters.
Leave other settings at their default values.
To configure the tunnel mode firewall policy - CLI

edit <id>
set srcintf ssl.root
set dstintf <dst_interface_name>
set srcaddr <tunnel_ip_address>
set dstaddr <protected_network_address_name>
set schedule always
set service ANY
set nat enable
end
This policy enables the SSL VPN client to initiate communication with hosts on the
protected network. If you want to enable hosts on the protected network to initiate
communication with the SSL VPN client, you should create another Accept policy like the
preceding one but with the source and destination settings reversed.
You must also add a static route for tunnel mode operation. See the following section.
Configuring routing for tunnel mode

If you your SSL VPN operates in tunnel mode, you must add a static route so that replies
from the protected network can reach the remote SSL VPN client.
To add the tunnel mode route - web-based manager

1 Go to Router > Static > Static Route and select Create New.

01-420-99686-20101026 1219
Destination IP/Mask Enter the Tunnel IP address range that you assigned to users of
the web portal. See “Configuring tunnel mode settings” on
page 1199.
Device Select the SSL VPN virtual interface, ssl.root for example.
Distance Optionally you can set the distance on the SSL VPN higher than
the default route to ensure only SSL VPN traffic uses this route.
To add the tunnel mode route - CLI

If you assigned 10.11.254.0/24 as the tunnel IP range, you would enter:
edit <id>
set device ssl.root
set dst 10.11.254.0/24
end
Adding an Internet browsing policy

With split tunneling disabled, all of the SSL VPN client’s requests are sent through the
SSL VPN tunnel. But the tunnel mode firewall policy provides access only to the protected
networks behind the FortiGate unit. Clients will receive no response if they attempt to
access Internet resources. Optionally, you can enable clients to connect to the Internet
To add an Internet browsing policy

Source Interface/Zone Select the virtual SSL VPN interface, ssl.root, for example.
Source Address Select the firewall address you created that represents the IP
address range assigned to SSL VPN clients.
Destination Select the FortiGate network interface that connects to the Internet.
Interface/Zone
Destination Address Select all.
Action Select Accept.
NAT Enable.
To configure the Internet browsing firewall policy - CLI

To enable browsing the Internet through port1, you would enter:
edit 0
set dstintf port1
set srcaddr SSL_tunne_users
set dstaddr all
set schedule always
set service ANY
set nat enable
end

1220 01-420-99686-20101026
Enabling connection to an IPsec VPN

You might want to provide your SSL VPN clients access to another network, such as a
branch office, that is connected by an IPsec VPN. To do this, you need only to add the
appropriate firewall policy. For information about route-based and policy-based IPsec
VPNs, see the IPsec VPN Guide.
To configure interconnection with a route-based IPsec VPN - web-based manager

Destination Select the virtual IPsec interface for your IPsec VPN.
Interface/Zone
Destination Address Select the address of the IPsec VPN remote protected subnet.
NAT Enable.
To configure interconnection with a route-based IPsec VPN - CLI

If, for example, you want to enable SSL VPN users to connect to the private network
(address name OfficeAnet) through the toOfficeA IPsec VPN, you would enter:
edit 0
set dstintf toOfficeA
set srcaddr SSL_tunnel_users
set dstaddr OfficeAnet
set action accept
set nat enable
set schedule always
set service ANY
end
To configure interconnection with a policy-based IPsec VPN - web-based manager

Destination Select the FortiGate network interface that connects to the Internet.
Interface/Zone
Destination Address Select the address of the IPsec VPN remote protected subnet.
VPN tunnel Select the Phase 1 configuration name of your IPsec VPN.
Allow inbound Enable
Allow outbound Enable

01-420-99686-20101026 1221
Viewing SSL VPN logs Setting up the FortiGate unit
NAT inbound Enable

To configure interconnection with a policy-based IPsec VPN - CLI

If, for example, you want to enable SSL VPN users to connect to the private network
(address name OfficeAnet) through the OfficeA IPsec VPN, you would enter:
edit 0
set dstintf port1
set dstaddr OfficeAnet
set action ipsec
set schedule always
set service ANY
set inbound enable
set outbound enable
set vpntunnel toOfficeA
end
In this example, port1 is connected to the Internet.
Viewing SSL VPN logs

You can view SSL VPN logs on your FortiGate unit. For information about how to interpret
log messages, see the FortiGate Log Message Reference.
To enable logging - web-based manager

2 Enable the storage of log messages to one or more of the following locations:
• a FortiAnalyzer unit
• the FortiGate system memory
• a remote computer running a syslog server
Note: If available on your FortiGate unit, you can enable the storage of log messages to a
system hard disk. In addition, as an alternative to the options listed above, you may choose
to forward log messages to a remote computer running a WebTrends firewall reporting
server. For more information about enabling either of these options through CLI commands,
see the “log” chapter of the FortiGate CLI Reference.
3 If the options are concealed, select the expand arrow beside each option to reveal and
configure associated settings.
4 If logs will be written to system memory, from the Log Level list, select Information. For
more information, see the “Log & Report” chapter of the FortiGate Administration
Guide.
5 Select Apply.

1222 01-420-99686-20101026
Setting up the FortiGate unit Viewing SSL VPN logs
To enable logging - CLI

config log {fortianalyzer | memory | syslog} setting
set status enable
end
For some log locations, there are additional options that you can set.
To enable logging of SSL VPN events - web-based manager

2 Select Enable, and then select one or more of the following options:
• SSL VPN user authentication event
• SSL VPN administration event
• SSL VPN session event
3 Select Apply.
To enable logging of SSL VPN events - CLI

config log {fortianalyzer | memory | syslog} filter
set event enable
set sslvpn-log-adm enable
set sslvpn-log-auth enable
set sslvpn-log-session enable
end
To enable logging of SSL VPN traffic - web-based manager

2 Select your SSL VPN policy and then select Edit.
3 For each identity-based policy, select its Edit icon, select Log Allowed Traffic and then
select OK.
4 Select OK.
5 Select the Edit icon for your tunnel-mode policy.
6 Select Log Allowed Traffic and then select OK.
To enable logging of SSL VPN traffic - CLI

Your SSL VPN firewall policy is number 2 with a single identity-based policy, and your
tunnel-mode policy is number 5, you would enable traffic logging by entering:
edit 2
edit 1
end
edit 5
end

01-420-99686-20101026 1223
Monitoring active SSL VPN sessions Setting up the FortiGate unit
To view SSL VPN logs - web-based manager

1 Go to Log&Report > Log Access and select the Memory or Disk tab.
2 From the Log Type list select Event Log or Traffic Log, as needed.
In event log entries look for the sub-types “sslvpn-session” and “sslvpn-user”.
In the traffic logs, look for the sub-type “allowed”. For web-mode traffic, the source is
the host IP address. For tunnel-mode traffic, the source is the address assigned to the
host from the SSL VPN address pool.
To view SSL VPN logs - CLI

execute log filter category {event | traffic}
execute log filter device {fortianalyzer | memory | syslog}
execute log display
The console displays the first 10 log messages. To view more messages, run the
command again. You can do this until you have seen all of the selected log messages.
To restart viewing the list from the beginning, use the command
execute log filter start-line 1
Monitoring active SSL VPN sessions

You can go to User > Monitor to view a list of active SSL VPN sessions. The list displays
the user name of the remote user, the IP address of the remote client, and the time the
connection was made. You can also see which services are being provided, and delete an
active web session from the FortiGate unit.
To monitor SSL VPNs - web-based manager

To view the list of active SSL VPN sessions, go to VPN > SSL > Monitor.
Figure 163: SSL VPN monitor list
No. The connection identifier.

User The user names of all connected remote users.
Source IP The IP addresses of the host devices connected to the FortiGate unit.
Begin Time The starting time of each connection.
Description Information about the services provided by an SSL VPN tunnel session.
Subsession
Tunnel IP: IP address that the FortiGate unit assigned to the remote client.
Delete icon: Delete current subsession.
When a tunnel-mode user is connected, the Description field displays the IP address that
the FortiGate unit assigned to the remote host (see Figure 164).

1224 01-420-99686-20101026
Setting up the FortiGate unit Troubleshooting
Figure 164: SSL VPN monitor list - Tunnel-mode user
If required, you can end a session/connection by selecting its check box and then
selecting the Delete icon.
To monitor SSL VPNs - CLI

To list all of the SSL VPN sessions and their index numbers:
get vpn ssl monitor
To delete tunnel-mode or web-mode sessions:
execute vpn sslvpn del-tunnel <index_int>
execute vpn sslvpn del-web <index_int>
Troubleshooting
Here is a list of common SSL VPN problems and the likely solutions.
No response from SSL VPN URL Check that SSL VPN is enabled.
Check SSL VPN port assignment (default 10443).
Check SSL VPN firewall policy.
Error: “The web page cannot be Check URL:
found.” https://<FortiGate_IP>:<SSLVPN_port>/remote/login
Tunnel connects, but there is no Check that there is a static route to direct packets
communication. destined for the tunnel users to the SSL VPN interface.
See “Configuring routing for tunnel mode” on page 1219.
Tunnel-mode connection shuts down This issue occurs when there are multiple interfaces
after a few seconds connected to the Internet, for example, a dual WAN
configuration. Upgrade the FortiGate unit firmware to at
least v3.0 MR4 or higher, then use the following CLI
command:
set route-source-interface enable
end
Error: “Destination address of Split The SSL VPN firewall policy uses the ALL address as its
Tunneling policy is invalid.” destination. Specify the address of the protected
network instead.

01-420-99686-20101026 1225
Troubleshooting Setting up the FortiGate unit

1226 01-420-99686-20101026
Working with the web portal
This section introduces the web portal features and explains how to configure them.
• Connecting to the FortiGate unit
• Web portal overview
• Using the Bookmarks widget
• Using the Connection Tool
• Tunnel-mode features
• Using the SSL VPN Virtual Desktop
Connecting to the FortiGate unit

You can connect to the FortiGate unit using a web browser. The URL of the FortiGate
interface may vary from one installation to the next. If required, ask your FortiGate
administrator for the URL of the FortiGate unit, and obtain a user name and password.
In addition, if you will be using a personal or group security (X.509) certificate to connect
to the FortiGate unit, your web browser may prompt you for the name of the certificate.
Your FortiGate administrator can tell you which certificate to select.
To log in to the FortiGate secure HTTP gateway

1 Using the web browser on your computer, browse to the URL of the FortiGate unit (for
example, https://<FortiGate_IP_address>:10443/remote/login).
The FortiGate unit may offer you a self-signed security certificate. If you are prompted
to proceed, select Yes.
A second message may be displayed to inform you that the FortiGate certificate
distinguished name differs from the original request. This message is displayed
because the FortiGate unit is attempting to redirect your web browser connection. You
can ignore the message.
2 When you are prompted for your user name and password:
• In the Name field, type your user name.
• In the Password field, type your password.
3 Select Login.
The FortiGate unit will redirect your web browser to the FortiGate SSL VPN web portal
home page automatically.

01-420-99686-20101026 1227
Web portal overview Working with the web portal
Web portal overview

After you log in, you see a web portal page like the following:
Figure 165: FortiGate SSL VPN web portal page

Logout
Help
Four “widgets” provide the web portal’s features:

• Session Information displays the elapsed time since login and the volume of HTTP and
HTTPS traffic, both inbound and outbound.
• Bookmarks provides links to network resources. You can use the administrator-defined
bookmarks and you can add your own bookmarks. See “Using the Bookmarks widget”
on page 1229.
• Connection Tool enables you to connect to network resources without using or creating
a bookmark.
• Tunnel Mode connects and disconnects the tunnel mode SSL connection to the
FortiGate unit. While the tunnel is active, the widget displays the amount of data that is
sent and received. For more information, see “Tunnel-mode features” on page 1237.
Tunnel mode requires a downloadable client application. If your computer is running
Microsoft Windows, the Tunnel Mode widget provides a download link if you need to
install the client on your computer. If you are using Macintosh or Linux, you can obtain
and install an appropriate client application from the Fortinet Support site. For more
information, see “Downloading the SSL VPN tunnel mode client” on page 1240.
Depending on the web portal configuration and user group settings, some widgets might
not be present. For example, the predefined web-access portal contains only the Session
Information and Bookmarks widgets.
While using the web portal, you can select the Help button to get information to assist you
in using the portal features. This information displays in a separate browser window.
When you have finished using the web portal, select the Logout button in the top right
corner of the portal window.
Note: After making any changes to the web portal configuration, be sure to select Apply.

1228 01-420-99686-20101026
Working with the web portal Using the Bookmarks widget
Applications available in the web portal

Depending on the web portal configuration and user group settings, one or more of the
following server applications are available to you through Bookmarks or the Connection
Tool:
• Ping enables you to test whether a particular server or host is reachable on the
network.
• HTTP/HTTPS accesses web pages.
• Telnet (Teletype Network emulation) enables you to use your computer as a virtual
text-only terminal to log in to a remote host.
• SSH (Secure Shell) enables you to exchange data between two computers using a
secure channel.
• FTP (File Transfer Protocol) enables you to transfer files between your computer and a
remote host.
• SMB/CIFS implements the Server Message Block (SMB) protocol to support file
sharing between your computer and a remote server host.
• VNC (Virtual Network Computing) enables you to remotely control another computer,
for example, accessing your work computer from your home computer.
• RDP (Remote Desktop Protocol), similar to VNC, enables you to remotely control a
computer running Microsoft Terminal Services.
Some server applications may prompt you for a user name and password. You must have
a user account created by the server administrator so that you can log in.
Note: Windows file sharing through SMB/CIFS is supported through shared directories.
Using the Bookmarks widget

The Bookmarks widget shows both administrator-configured and user-configured
bookmarks. Administrator bookmarks cannot be altered but you can add, edit or delete
user bookmarks.
Figure 166: Bookmarks widget
Administrator bookmarks
User bookmarks
The FortiGate unit forwards client requests to servers on the Internet or internal network.
To use the web-portal applications, you add the URL, IP address, or name of the server
application to the My Bookmarks list. For more information, see “Adding bookmarks”.
Note: If you want to access a web server or telnet server without first adding a bookmark to
the My Bookmarks list, use the Connection Tool instead. For more information, see “Using
the Connection Tool” on page 1231.

01-420-99686-20101026 1229
Using the Bookmarks widget Working with the web portal
Adding bookmarks
You can add frequently used connections as bookmarks. Afterward, select any hyperlink
from the Bookmarks list to initiate a session.
To add a bookmark
1 In the Bookmarks widget, select Add.
Name Enter the name to display in the Bookmarks list.

Type Select the abbreviated name of the server application or network service
from the drop-down list.
Location Enter the IP address or FQDN of the server application or network service.
For RDP connections, you can append some parameters to control screen
size and keyboard layout. See “To start an RDP session” on page 1234.
Description Optionally enter a short description. The description displays when you
pause the mouse pointer over the hyperlink.
SSO Single Sign On (SSO) is available for HTTP/HTTPS bookmarks only.
Disabled — This is not an SSO bookmark.
Automatic — Use your SSL VPN credentials or an alternate set. See the
SSO Credentials field.
Static — Supply credentials and other required information (such as an
account number) to a web site that uses an HTML form for authentication.
You provide a list of the form field names and the values to enter into them.
This method does not work for sites that use HTTP authentication, in which
the browser opens a pop-up dialog box requesting credentials.
SSO fields
SSO Credentials SSL VPN Login — Use your SSL VPN login credentials.
Alternative — Enter Username and Password below.
Username Alternative username. Available if SSO Credentials is Alternative.
Password Alternative password. Available if SSO Credentials is Alternative.
Static SSO fields These fields are available if SSO is Static.
Field Name Enter the field name, as it appears in the HTML form.
Value Enter the field value.
To use the values from SSO Credentials, enter %passwd% for password or
%username% for username.
Add Add another Field Name / Value pair.
3 Select OK and then select Done.

•

1230 01-420-99686-20101026
Working with the web portal Using the Connection Tool
Using the Connection Tool

You can connect to any type of server without adding a bookmark to the My Bookmarks
list. The fields in the Connection Tool enable you to specify the type of server and the URL
or IP address of the host computer.
See the following procedures:
• “To connect to a web server” on page 1231
• “To ping a host or server behind the FortiGate unit” on page 1231
• “To start a telnet session” on page 1231
• “To start an FTP session” on page 1232
• “To start an SMB/CIFS session” on page 1233
• “To start an SSH session” on page 1234
• “To start an RDP session” on page 1234
• “To start a VNC session” on page 1236
Except for ping, these services require that you have an account on the server to which
you connect.
Note: When you use the Connection Tool, the FortiGate unit may offer you its self-signed
security certificate. Select Yes to proceed. A second message may be displayed to inform
you of a host name mismatch. This message is displayed because the FortiGate unit is
attempting to redirect your web browser connection. Select Yes to proceed.
To connect to a web server

1 In Type, select HTTP/HTTPS.
2 In the Host field, type the URL of the web server.
For example: http://www.mywebexample.com or https://172.20.120.101
3 Select Go.
4 To end the session, close the browser window.
To ping a host or server behind the FortiGate unit

1 In Type, select Ping.
2 In the Host field, enter the IP address of the host or server that you want to reach.
For example: 10.11.101.22
3 Select Go.
A message stating whether the IP address can be reached or not is displayed.
To start a telnet session

1 In Type, select Telnet.
2 In the Host field, type the IP address of the telnet host.

01-420-99686-20101026 1231
Using the Connection Tool Working with the web portal
3 Select Go.
A Telnet window opens.
4 Select Connect.
5 A telnet session starts and you are prompted to log in to the remote host.
After you log in, you may enter any series of valid telnet commands at the system
prompt.
6 To end the session, select Disconnect (or type exit) and then close the TELNET
connection window.
To start an FTP session

1 In Type, select FTP.
2 In the Host field, type the IP address of the FTP server.
3 Select Go.
A login window opens.
4 Enter your user name and password and then select Login.
You must have a user account on the remote host to log in.
Figure 167: An FTP session

New Directory
Upload Logout
Up
Delete
Rename

1232 01-420-99686-20101026
5 Manipulate the files in any of the following ways:

• To download a file, select the file link in the Name column.
• To access a subdirectory (Type is Folder), select the link in the Name column.
• To create a subdirectory in the current directory, select New directory.
• To delete a file or subdirectory from the current directory, select its Delete icon.
• To rename a file in the current directory, select its Rename icon.
• To upload a file to the current directory from your client computer, select Upload.
• When the current directory is a subdirectory, you can select Up to access the parent
directory.
6 To end the FTP session, select Logout.
To start an SMB/CIFS session

1 In Type, select SMB/CIFS.
2 In the Host field, type the IP address of the SMB or CIFS server.
3 Select Go.
4 Enter your user name and password and then select Login.
New Directory
Upload Logout
Up
Delete
Rename
5 Manipulate the files in any of the following ways:

• To download a file, select the file link in the Name column.
• To access a subdirectory (Type is Folder), select the file link in the Name column.
• To create a subdirectory in the current directory, select New Directory.
• To delete a file or subdirectory from the current directory, select its Delete icon.
• To rename a file, select its Rename icon.
• To upload a file from your client computer to the current directory, select Upload.
• When the current directory is a subdirectory, you can select Up to access the parent
directory.
6 To end the SMB/CIFS session, select Logout and then close the SMB/CIFS window.

01-420-99686-20101026 1233
To start an SSH session

1 In Type, select SSH.
2 In the Host field, type the IP address of the SSH host.
3 Select Go.
4 Select Connect.
A SSH session starts and you are prompted to log in to the remote host. You must
have a user account to log in. After you log in, you may enter any series of valid
commands at the system prompt.
5 To end the session, select Disconnect (or type exit) and then close the SSH
connection window.
To start an RDP session

1 In Type, select RDP.
2 In the Host field, type the IP address of the RDP host.
3 Optionally, you can specify additional options for RDP by adding them to the Host field
following the host address. See “RDP options” on page 1235 for information about the
available options.
For example, to use a French language keyboard layout you would add the -m
parameter:
10.11.101.12 -m fr
4 Select Go.

1234 01-420-99686-20101026
5 When you see a screen configuration dialog, click OK.
The screen configuration dialog does not appear if you specified the screen resolution
with the host address.
6 When you are prompted to log in to the remote host, type your user name and
password. You must have a user account on the remote host to log in.
7 Select Login.
If you need to send Ctrl-Alt-Delete in your session, use Ctrl-Alt-End.
8 To end the RDP session, Log out of Windows or select Cancel from the Logon window.
RDP options
When you specify the RDP server address, you can also specify other options for your
remote desktop session.
Screen resolution -f Make RDP full-

Use this command to make the RDP screen.
window full screen or a specific the -g <width>x<height>
window size.
<width> and <height> are in pixels
Example: -g 800x600
Authentication -u <user name>
Use these options to send your -p <password>
authentication credentials with the -d <domain>
connection request, instead of
entering them after the connection is
established.

01-420-99686-20101026 1235
Locale/Keyboard -m <locale>
Use this option if the remote The supported values of <locale> are:
computer might not use the same
keyboard layout as your computer. ar Arabic it Italian
Select the locale code that matches da Danish ja Japanese
your computer. de German lt Lithuanian
de-ch Swiss German lv Latvian
en-gb British English mk Macedonian
en-uk UK English no Norwegian
en-us US English pl Polish
es Spanish pt Portuguese
fi Finnish pt-br Brazilian Portuguese
fr French ru Russian
fr-be Belgian French sl Slovenian
fr-ca Canadian French sv Sudanese
fr-ch Swiss French tk Turkmen
hr Croatian tr Turkish
hu Hungarian
To start a VNC session

1 In Type, select VNC.
2 In the Host field, type the IP address of the VNC host.
3 Select Go.
4 Type your user name and password when prompted to log in to the remote host.
5 Select OK.
If you need to send Ctrl-Alt-Delete in your session, press F8, then select
Send Ctrl-Alt-Delete from the pop-up menu.
6 To end the VNC session, close the VNC window.

1236 01-420-99686-20101026
Working with the web portal Tunnel-mode features
Tunnel-mode features
For Windows users, the web portal Tunnel Mode widget provides controls for your tunnel
mode connection and also provides status and statistics about its operation. You can also
control and monitor tunnel mode operation from the standalone client application. For
more information, see “Using the tunnel mode client” on page 1242.
Figure 168: Fortinet SSL VPN tunnel mode widget
Connect Initiate a session and establish an SSL VPN tunnel with the FortiGate unit.
Disconnect End the session and close the tunnel to the FortiGate unit.
Refresh Refresh the status and statistics immediately.
Link Status The state of the SSL VPN tunnel:
• Up — an SSL VPN tunnel with the FortiGate unit has been established.
• Down — a tunnel connection has not been initiated.
Bytes Sent The number of bytes of data transmitted from the client to the FortiGate unit
since the tunnel was established.
Bytes Received The number of bytes of data received by the client from the FortiGate unit
since the tunnel was established.
Using the SSL VPN Virtual Desktop

The virtual desktop feature is available for Windows only. When you start an SSL VPN
session, the virtual desktop replaces your normal desktop. When the virtual desktop exits,
your regular desktop is restored. Virtual desktop information is encrypted so that no
information from it remains available after your session ends.
To use the SSL VPN virtual desktop, simply log in to an SSL VPN that requires the use of
the virtual desktop. Wait for the virtual desktop to initialize and replace your desktop with
the SSL VPN desktop, which has a Fortinet SSL VPN logo as wallpaper. Your web
browser will open to the web portal page.
You can use the virtual desktop just as you use your regular desktop, subject to the
limitations that virtual desktop application control imposes. See “Configuring virtual
desktop application control” on page 1210.
If it is enabled in the web portal virtual desktop settings, you can switch between the virtual
desktop and your regular desktop. Right-click the SSL VPN Virtual Desktop icon in the
taskbar and select Switch Desktop.
To see the web portal virtual desktop settings, right-click the SSL VPN Virtual Desktop
icon in the taskbar and select Virtual Desktop Option.
When you have finished working with the virtual desktop, right-click the SSL VPN Virtual
Desktop icon in the taskbar and select Exit. Select Yes to confirm. The virtual desktop
closes and your regular desktop is restored.

01-420-99686-20101026 1237
Using the SSL VPN Virtual Desktop Working with the web portal

1238 01-420-99686-20101026
Using the SSL VPN tunnel client
This section provides information about installing and using the SSL VPN tunnel client for
Windows, Linux, and Mac OS X.
• Client configurations
• Downloading the SSL VPN tunnel mode client
• Installing the tunnel mode client
• Using the tunnel mode client
• Uninstalling the tunnel mode client
Client configurations
There are several configurations of SSL VPN applications available.
• web mode
• tunnel mode
• virtual desktop
Web mode
SSL VPN web mode requires nothing more than a web browser. Microsoft Internet
Explorer, Mozilla Firefox, and Apple Safari browsers are supported. For detailed
information about supported browsers see the Release Notes for your FortiOS firmware.
Tunnel mode
SSL VPN tunnel mode establishes a connection to the remote protected network that any
application can use. This requires a tunnel client application specific to your computer
operating system. The tunnel client application installs a network driver that sends and
receives data through the SSL VPN tunnel.
If your computer runs Microsoft Windows, you can download the tunnel mode client from
the web portal Tunnel Mode widget. After you install the client, you can start and stop
tunnel operation from the Tunnel Mode widget, or you can open the tunnel mode client as
a standalone application. You can find the tunnel mode client on the Start menu at
All Programs > FortiClient > FortiClient SSL VPN.
If your computer runs Linux or Mac OS X, you can obtain an appropriate tunnel mode
client application from the Fortinet Support web site. See the Release Notes for your
FortiOS firmware for the specific operating system versions that are supported. On Linux
and Mac OS X platforms, tunnel mode operation cannot be initiated from the web portal
Tunnel Mode widget. You must use the standalone tunnel client application.
When a system configuration must involve more secure disposal of cached data, the SSL
VPN Virtual Desktop should be used. (Available on Windows only).

01-420-99686-20101026 1239
Downloading the SSL VPN tunnel mode client Using the SSL VPN tunnel client
Virtual desktop application

The virtual desktop application creates a virtual desktop on a user's PC and monitors the
data read/write activity of the web browser running inside the virtual desktop. When the
application starts, it presents a ‘virtual desktop’ to the user. The user starts the web
browser from within the virtual desktop and connects to the SSL VPN web portal. The
browser file/directory operation is redirected to a new location, and the data is encrypted
before it is written to the local disk. When the virtual desktop application exits normally, all
the data written to the disk is removed. If the session terminates abnormally (power loss,
system failure), the data left behind is encrypted and unusable to the user. The next time
you start the virtual desktop, the encrypted data is removed.
Downloading the SSL VPN tunnel mode client

SSL VPN standalone tunnel client applications are available for Windows, Linux, and
Mac OS X systems (see the Release Notes for your FortiOS firmware for the specific
versions that are supported). There are separate download files for each operating
system.
Note: Windows users can also download the tunnel mode client from an SSL VPN web
portal that contains the Tunnel Mode widget.
The most recent version of the SSL VPN standalone client applications can be found at:
http://support.fortinet.com/
To download the SSL VPN tunnel client

1 Log in to Fortinet Support at http://support.fortinet.com/.
2 Select Firmware Images and then FortiGate.
The Support FTP site opens.
3 Select v4.00 and then select the latest firmware release, 4.0MR2, for example.
The list of firmware images opens.
4 Select SSL VPN Clients.
5 Select the appropriate client.
Windows: SslvpnClient.exe or SslvpnClient.msi
Linux: forticlientsslvpn_linux_<version>.tar.gz
Mac OS X: forticlientsslvpn_macosx_<version>.dmg
Note: The location of the SSL VPN tunnel client on the Support web site is subject to
change. If you have difficulty finding the appropriate file, contact Customer Support.

1240 01-420-99686-20101026
Using the SSL VPN tunnel client Installing the tunnel mode client
Installing the tunnel mode client

Follow the instructions for your operating system.
Windows
Double-click the SslvpnClient.exe or SslvpnClient.msi file and follow the on-
screen instructions.
Linux
1 Extract the forticlientsslvpn_linux_<version>.tar.gz package file to a folder
and run the client program forticlientsslvpn.
When you run the install program for the first time, you will have to set up system
parameters (root privileges) before you run the program or before other users without
administrator privileges can use the application.
2 In the First Run dialog, select OK.

The command line terminal window opens.
3 If you are asked for your password, enter it.
The License Agreement dialog appears in the command line terminal window.
4 Read the License Agreement and enter Yes to accept it.
The FortiClient SSL VPN tunnel client (Linux) opens. You can begin using the
application immediately or close it.
After this initial setup is complete, a user with a normal (non-administrator) account can
establish an SSL VPN tunnel session.
MAC OS client
1 Double-click on the forticlientsslvpn_macosx_<version>.dmg file.
The Mac mounts the disk image as forticlientsslvpn.
2 Double-click the forticlientsslvpn.pkg file inside the disk image and follow the
instructions.
The application installs the program forticlientsslvpn.app in the Applications
folder
3 Unmount the disk image by selecting the disk image file
forticlientsslvpn_macosx_<version>.dmg and dragging it into the Trash.

01-420-99686-20101026 1241
Using the tunnel mode client Using the SSL VPN tunnel client
Using the tunnel mode client

Follow the instructions for your operating system.
Windows client
To use the SSL VPN standalone tunnel client (Windows)
1 Go to Start > All Programs > FortiClient > FortiClient SSL VPN.
2 Enter the following information. Use the Connect and Disconnect buttons to control the
tunnel connection.
Connection Name If you have pre-configured the connection settings, select the
connection from the list and then select Connect. Otherwise, enter the
settings in the fields below.
To pre-configure connection settings, see “To configure tunnel client
settings (Windows)” on page 1243.
Server Address Enter the IP address or FQDN of the FortiGate unit that hosts the SSL
VPN.
Username Enter your user name.
Password Enter the password associated with your user account.
Client Certificate Use this field if the SSL VPN requires a certificate for authentication.
Select the required certificate from the drop-down list. The certificate
must be installed in the Internet Explorer certificate store.
Connection Status: Connected or Disconnected
Duration: Hours, minutes, seconds since session started
Bytes Sent / Bytes Received: amount of data transferred
Settings... Select to open the Settings dialog. See “To configure tunnel client
settings (Windows)” on page 1243.
Connect Start tunnel mode operation.
Disconnect Stop tunnel mode operation.
Exit Close the tunnel mode client application.

1242 01-420-99686-20101026
Using the SSL VPN tunnel client Using the tunnel mode client
To configure tunnel client settings (Windows)

1 Go to Start > All Programs > FortiClient > FortiClient SSL VPN.
2 Select Settings....
3 Select New Connection, or select an existing connection and then select Edit.
4 Enter the Connection Name.
5 Enter the connection information. You can also enter a Description. Select OK.
See “To use the SSL VPN standalone tunnel client (Windows)” on page 1242 for
information about the fields.
6 Optionally, select Keep connection alive until manually stopped to prevent tunnel
connections from closing due to inactivity.
7 Select OK.

01-420-99686-20101026 1243
Linux client
To use the SSL VPN standalone tunnel client (Linux)
1 Go to the folder where you installed the Linux tunnel client application and double-click
on ‘forticlientsslvpn’.
The FortiClient SSL VPN tunnel client opens.
2 Enter the following information. Use the Connect and Stop buttons to control the tunnel
connection.
Connection If you have pre-configured the connection settings, select the connection
from the list and then select Connect. Otherwise, enter the settings in the
fields below.
To pre-configure connection settings, see “To configure tunnel client settings
(Windows)” on page 1243.
Server Enter the IP address or FQDN of the FortiGate unit that hosts the SSL VPN.
In the smaller field, enter the SSL VPN port number (default 10443).
User Enter your user name.
Certificate Use this field if the SSL VPN requires a certificate for authentication.
Select the certificate file (PKCS#12) from the drop-down list, or select the
Browse (...) button and find it.
Password Enter the password required for the certificate file.
Settings... Select to open the Settings dialog. See “To configure tunnel client settings
(Linux)” on page 1245.
Stop Stop tunnel mode operation.

1244 01-420-99686-20101026
To configure tunnel client settings (Linux)

1 Go to the folder where you installed the Linux tunnel client application and double-click
forticlientsslvpn.
4 Optionally, select Start connection automatically. The next time the tunnel mode
application starts, it will start the last selected connection.
5 If you use a proxy, enter in Proxy the proxy server IP address and port. Enter proxy
authentication credentials immediately below in User and Password.
6 Select the + button to define a new connection, or select from the list an existing
connection to modify.
For a new connection, the Connection window opens. For an existing connection, the
current settings appear in the Settings window and you can modify them.
7 Enter the connection information. If you are creating a new connection, select Create
when you are finished.
See “To use the SSL VPN standalone tunnel client (Linux)” on page 1244 for
8 Select Done.

01-420-99686-20101026 1245
MAC OS X client
To use the SSL VPN standalone tunnel client (Mac OS X)
1 Go to the Applications folder and double-click on forticlientsslvpn.app.
The FortiClient SSL VPN tunnel client (Mac OS X) opens.
2 Enter the following information. Use the Connect and Stop buttons to control the tunnel
connection.
Connection If you have pre-configured the connection settings, select the

connection from the list and then select Connect. Otherwise, enter the
settings in the fields below.
To pre-configure connection settings, see “To configure tunnel client
settings (Mac OS X)” on page 1247.
Server Enter the IP address or FQDN of the FortiGate unit that hosts the SSL
VPN. In the smaller field, enter the SSL VPN port number
(default 10443).
User Enter your user name.
Certificate Use this field if the SSL VPN requires a certificate for authentication.
Select the certificate file (PKCS#12) from the drop-down list, or select
the Browse (...) button and find it.
Password Enter the password required for the certificate file.
Settings... Select to open the Settings dialog. See “To configure tunnel client
settings (Mac OS X)” on page 1247.
Stop Stop tunnel mode operation.

1246 01-420-99686-20101026
To configure tunnel client settings (Mac OS X)

1 Go to the Applications folder and double-click on forticlientsslvpn.app.
The FortiClient SSL VPN tunnel client (Mac OS X) opens.
4 Optionally, select Start connection automatically. The next time the tunnel mode
application starts, it will start the last selected connection.
5 If you use a proxy, enter in Proxy the proxy server IP address and port. Enter proxy
authentication credentials immediately below in User and Password.

01-420-99686-20101026 1247
Uninstalling the tunnel mode client Using the SSL VPN tunnel client
6 Select the + button to define a new connection, or select from the list an existing
connection to modify.
7 Enter the connection information. If you are creating a new connection, select Create
when you are finished.
See “To use the SSL VPN standalone tunnel client (Mac OS X)” on page 1246 for
8 Select Done.
Uninstalling the tunnel mode client

If you want to remove the tunnel mode client application, follow the instructions for your
operating system.
To uninstall from Windows

1 In the Control Panel, select Programs and Features (Add or Remove Programs in
Windows XP).
2 Select FortiClient SSL VPN and then Remove.
To uninstall from Linux

Remove/delete the folder containing all the SSL VPN client application files.
To uninstall from Mac OS X

In the Applications folder, select forticlientsslvpn.app and drag it into the Trash.
After you empty the Trash folder, the installed program is removed from the user
computer.

1248 01-420-99686-20101026
Examples
In the most common Internet scenario, the remote client connects to an ISP that offers
connections with dynamically assigned IP addresses. The ISP forwards packets from the
remote client to the Internet, where they are routed to the public interface of the FortiGate
unit.
At the FortiGate unit, you configure user groups and firewall policies to define the server
applications and IP address range or network that remote clients will be able to access
behind the FortiGate unit.
• Basic SSL VPN example
• Multiple user groups with different access permissions example
Basic SSL VPN example

A common application for an SSL VPN is to provide access to the office network for
employees traveling or working from home. For example, Figure 169 shows a FortiGate
gateway (FortiGate_1) that connects the office network to the Internet. Users on the office
network have access to the Internet, but access to the office network from the Internet is
available only to authenticated users of the SSL VPN.
Figure 169: Example SSL VPN configuration
ent
te Cli
mo
Re
17 Por
2.2 t 1
0.1
20 N
.1 41 LA /24
ice 1.0
Off 1.10
10 Por 1
.11 t 2 10.
.10
1.1
00
1
te_
H .1
T 1.
iGa
10
T 1
P 0
ort
/H 1.
T 12
F
T 0
P
D 11
S
10
N .1
S 0
.
S .
er 16
ve 0
F 11
r
10
T .1
P 0
.
S 1.
er 1
ve 0
r
S .1
am 1
7
10
ba 10
S .1
.
er 80
ve
1

01-420-99686-20101026 1249
Basic SSL VPN example Examples
Infrastructure requirements
address.
• The ISP assigns IP addresses to remote clients before they connect to the FortiGate
unit.
For information about client operating system and browser requirements, see the Release
Notes for your FortiGate firmware.

1 Create firewall addresses for
• the destination networks
• the IP address range that the FortiGate unit will assign to tunnel-mode clients
2 Create the web portal.
3 Create user accounts.
4 Create the SSL VPN user group and add the users. In the user group configuration,
you specify the web portal to which the users are directed.
5 Create the firewall policies:
• The SSL VPN firewall policy enables web mode access to the protected network.
• The tunnel-mode policy enables tunnel mode access to the protected network.
6 Create a static route to direct packets destined for tunnel users to the SSL VPN tunnel.
Creating the firewall addresses

In FortiOS 4.0, firewall policies do not accept direct entry of IP addresses and address
ranges. You must define firewall addresses in advance.
Creating the destination address

SSL VPN users in this example can access the office network on port 2. You need to
define a firewall address that represents the OfficeLAN subnet IP address.
To define destination addresses - web-based manager

Address Name OfficeLAN

Interface port2
To define destination addresses - CLI

edit OfficeLAN
set type ipmask
set subnet 10.11.101.0/24
end

1250 01-420-99686-20101026
Examples Basic SSL VPN example
Creating the tunnel client range address

In this example, all SSL-VPN users are assigned a single range of IP addresses. The
tunnel client addresses must not conflict with each other or with other addresses in your
network. The best way to accomplish this is to assign addresses from a subnet that is not
used elsewhere in your network.
To define tunnel client addresses - web-based manager
Address Name SSL_tunnel_users

Interface Any

edit SSL_tunnel_users
set type ipmask
set subnet 10.11.254.0/24
end
Enabling SSL VPN and setting the tunnel user IP address range
By default, SSL VPN is not enabled. At the same time as you enable SSL VPN, you can
define the IP address range from which SSL VPN tunnel-mode clients are assigned their
virtual IP addresses.
To enable SSL VPN and set tunnel address range - web-based manager
4 In the Available list, select SSL_tunnel_users and then select the down arrow button to
move the address to the Selected list. Select OK.
5 Select Apply.
To enable SSL VPN and set tunnel address range - CLI

set sslvpn-enable enable
set tunnel-ip-pools SSL_tunnel_users
end
Creating the web portal

You need to create one web portal, portal1, for example.
To create the portal1 web portal

1 Go to VPN > SSL > Portal and select Create New.
2 In the Name field, enter portal1.
3 In Applications, select the application types to permit.

01-420-99686-20101026 1251
4 Select OK, then select OK again.
To create the web portals - CLI

edit portal1
config widget
edit 0
set type tunnel
end
end
Creating the user account and user group

After enabling SSL VPN and creating the web portal, you need to create the user account
and then the user group for the SSL VPN users. In the user group configuration, you
select the web portal to which the users are directed.
To create the user account - web-based manager

2 In User Name, enter user1.
3 Select Password and enter the password in the field on the right.
4 Select OK.
To create the user account - CLI

config user local
edit user1
set type password
set password user1_pass
end
To create the user group - web-based manager

1 Go to User > User Group > User Group.
Name group1
Type SSL VPN
Portal portal1
3 From the Available list, select user1 and move it to the Members list by selecting the
right arrow button.
4 Select OK.
To create the user group - CLI

config user group
edit group1
set member user1
set sslvpn-portal portal1
end

1252 01-420-99686-20101026
Examples Basic SSL VPN example
Creating the firewall policies

You need to define firewall policies to permit your SSL VPN clients, web-mode or
tunnel-mode, to connect to the protected network behind the FortiGate unit. Before you
create the firewall policies, you must define the source and destination addresses to
include in the policy. See “Creating the firewall addresses” on page 1250.
Two types of firewall policy are required:
• An SSL VPN policy enables clients to authenticate and permits a web-mode
connection to the destination network.The authentication, ensures that only authorized
users access the destination network.
• A tunnel-mode policy is a regular ACCEPT firewall policy that enables traffic to flow
between the SSL VPN tunnel interface and the protected network. A tunnel-mode
policy is required if you want to provide a tunnel-mode connection for your clients.
To create the SSL VPN firewall policy - web-based manager


Source Address All
Destination Interface/Zone port2
Destination Address OfficeLAN
Action SSL-VPN
User Authentication Method Local
NAT Enable
3 Select Add and enter the following information:
User Group group1

Service Any
Schedule always
4 Select OK, and then select OK again.
To create the SSL VPN firewall policy - CLI

edit 0
set srcintf port1
set dstintf port2
set srcaddr all
set action ssl-vpn
set nat enable
edit 1
set groups group1
set schedule always
set service ANY
end
end

01-420-99686-20101026 1253
To create the tunnel-mode firewall policy - web-based manager

Source Interface/Zone sslvpn tunnel interface (ssl.root)

Source Address SSL_tunnel_users
Destination Address OfficeLAN
Schedule always
Service ANY
Action ACCEPT
NAT Enable
To create the tunnel-mode firewall policy - CLI

edit 0
set dstintf port2
set action accept
set schedule always
set service ANY
set nat enable
end
Add routing to tunnel mode clients

Reply packets destined for tunnel mode clients must pass through the SSL VPN tunnel.
You need to define a static route to accomplish this.
To add a route to SSL VPN tunnel mode clients - web-based manager

Destination IP/Mask 10.11.254.0/24

This is the IP address range that you assigned to users of the web
portal. See “Creating the tunnel client range address” on
page 1251.
To add a route to SSL VPN tunnel mode clients - CLI

edit 0
set device ssl.root
set dst 10.11.254.0/24
end

1254 01-420-99686-20101026
Examples Multiple user groups with different access permissions example
Multiple user groups with different access permissions example

You might need to provide access to several user groups with different access
permissions. Consider the following example topology in which users on the Internet have
controlled access to servers and workstations on private networks behind a FortiGate unit.
Figure 170: SSL VPN configuration for different access permissions by user group
er1
Us
er2
Us
17 Por
2.2 t 1
0.1
20
.1 41 t_1 /24
bne 1.0
Su 1.10
10 Por . 1
.11 t 2 10
.10
1.1
0 0
10 0
rt 3 1. te_
1
Po 1.20
H .1
T 1.
iGa
10
T 1
. 1
P 0
10 ort
/H 1.
T 2
F
T 0
P
D 11
S
10
N .1
1
S 0
.
S
er 16
ve 0
F 11
1.
r
10
T .1
P 0
.
S 1.
er 1
ve 70
S 1.2
10
r
ub 0
S .1
.1
am 1
ne 1.0
10
ba 10
t_ /2
2 4
S .1
.
er 80
ve
1
r
In this example configuration, there are two users:
• user1 can access the servers on Subnet_1
• user2 can access the workstation PCs on Subnet_2
You could easily add more users to either user group to provide them access to the user
group’s assigned web portal.

1 Create firewall addresses for
• the destination networks
• two non-overlapping tunnel IP address ranges that the FortiGate unit will assign to
tunnel clients in the two user groups
2 Create two web portals.
3 Create two user accounts, user1 and user2.
4 Create two user groups. For each group, add a user as a member and select a web
portal. In this example, user1 will belong to group1, which will be assigned to portal1.
5 Create firewall policies:
• two SSL VPN firewall policies, one to each destination
• two tunnel-mode policies to allow each group of users to reach its permitted
destination network
6 Create the static route to direct packets for the users to the tunnel.

01-420-99686-20101026 1255
Multiple user groups with different access permissions example Examples
Creating the firewall addresses

In FortiOS 4.0, firewall policies do not accept direct entry of IP addresses and address
ranges. You must define firewall addresses in advance.
Creating the destination addresses

SSL VPN users in this example can access either Subnet_1 or Subnet_2.
To define destination addresses - web-based manager

Address Name Subnet_1

Interface port2
3 Select Create New, enter the following information, and select OK.
Address Name Subnet_2

Interface port3

edit Subnet_1
set type ipmask
set subnet 10.11.101.0/24
next
edit Subnet_2
set type ipmask
set subnet 10.11.201.0/24
end
Creating the tunnel client range addresses

To accommodate the two groups of users, split an otherwise unused subnet into two
ranges. The tunnel client addresses must not conflict with each other or with other
addresses in your network.
To define tunnel client addresses - web-based manager
Address Name Tunnel_group1

Subnet / IP Range 10.11.254.[1-50]
Interface Any

1256 01-420-99686-20101026
3 Select Create New, enter the following information, and select OK.
Address Name Tunnel_group2

Subnet / IP Range 10.11.254.[51-100]
Interface Any
To define tunnel client addresses - CLI

edit Tunnel_group1
set type iprange
set end-ip 10.11.254.50
next
edit Tunnel_group2
set type iprange
set end-ip 10.11.254.100
end
Creating the web portals

To accommodate two different sets of access permissions, you need to create two web
portals, portal1 and portal2, for example. Later, you will create two SSL VPN user groups,
one to assign to portal1 and the other to assign to portal2.

2 Enter portal1 in the Name field and select OK.
3 In Applications, select all of the application types that the users can access.
4 Select the Edit icon on the Tunnel Mode widget.
6 In the Available list, select Tunnel_ group1 and then select the down arrow button.
Select OK.
8 Select OK.

2 Enter portal2 in the Name field and select OK.
3 In Applications, select all of the application types that the users can access.
4 Select the Edit icon on the Tunnel Mode widget.
6 In the Available list, select Tunnel_ group2 and then select the down arrow button.
Select OK.
8 Select OK.

01-420-99686-20101026 1257
To create the web portals - CLI

edit portal1
config widget
edit 0
set type tunnel
set ip-pools "Tunnel_group1"
end
next
edit portal2
config widget
edit 0
set type tunnel
set ip-pools "Tunnel_group2"
end
end
end
Later, you can configure these portals with bookmarks and enable connection tool
capabilities for the convenience of your users.
Creating the user accounts and user groups

After enabling SSL VPN and creating the web portals that you need, you need to create
the user accounts and then the user groups that require SSL VPN access.
Go to User > User and create user1 and user2 with password authentication. After you
create the users, create the SSL VPN user groups.
To create the user groups - web-based manager

1 Go to User > User Group > User Group.
Name group1
Type SSL VPN
Portal portal1
3 From the Available list, select user1 and move it to the Members list by selecting the
right arrow button.

1258 01-420-99686-20101026
Figure 171: group1 user group attributes
4 Select OK.
5 Repeat steps 2 through 4 to create group2, assigned to portal2, with user2 as its only
member.
To create the user groups - CLI

config user group
edit group1
set member user1
next
edit group2
set member user2
end
Creating the firewall policies

You need to define firewall policies to permit your SSL VPN clients, web-mode or tunnel-
mode, to connect to the protected networks behind the FortiGate unit. Before you create
the firewall policies, you must define the source and destination addresses to include in
the policy. See “Creating the firewall addresses” on page 1256.
Two types of firewall policy are required:
• An SSL VPN policy enables clients to authenticate and permits a web-mode
connection to the destination network. In this example, there are two destination
networks, so there will be two SSL VPN policies. The authentication, ensures that only
authorized users access the destination network.
• A tunnel-mode policy is a regular ACCEPT firewall policy that enables traffic to flow
between the SSL VPN tunnel interface and the protected network. Tunnel-mode
policies are required if you want to provide tunnel-mode connections for your clients. In
this example, there are two destination networks, so there will be two tunnel-mode
policies.

01-420-99686-20101026 1259
To create the SSL VPN firewall policies - web-based manager


Source Address All
Destination Address Subnet_1
Action SSL-VPN
User Group group1

Service Any


Source Address All
Action SSL-VPN
User Group group2

Service Any
To create the SSL VPN firewall policies - CLI

edit 0
set srcintf port1
set dstintf port2
set srcaddr all
set dstaddr Subnet_1
set action ssl-vpn
set nat enable
edit 1
set groups group1
set schedule always
set service ANY
end
next
edit 0
set srcintf port1
set dstintf port3
set srcaddr all

1260 01-420-99686-20101026
set action ssl-vpn

set nat enable
edit 1
set groups group2
set schedule always
set service ANY
end
end
To create the tunnel-mode firewall policies - web-based manager


Source Address Tunnel_group1
Action ACCEPT
NAT Enable

Source Address Tunnel_group2
Action ACCEPT
NAT Enable
To create the tunnel-mode firewall policies - CLI

edit 0
set dstintf port2
set srcaddr Tunnel_group1
set action accept
set schedule always
set service ANY
set nat enable
next
edit 0
set dstintf port3
set srcaddr Tunnel_group2
set action accept
set schedule always
set service ANY
set nat enable

01-420-99686-20101026 1261
end
end
Create the static route to tunnel mode clients

Reply packets destined for tunnel mode clients must pass through the SSL VPN tunnel.
You need to define a static route to accomplish this.
To add a route to SSL VPN tunnel mode clients - web-based manager


This IP address range covers both ranges that you assigned to
SSL VPN tunnel-mode users. See “Creating the tunnel client
range addresses” on page 1256.
To add a route to SSL VPN tunnel mode clients - CLI

edit 0
set device ssl.root
set dst 10.11.254.0/24
end
Enabling SSL VPN operation

By default, SSL VPN is not enabled.
To enable SSL VPN - web-based manager

2 Ensure that Enable SSL-VPN is selected.
3 Select Apply.
Note: In this example, the IP Pools field on the VPN > SSL > Config page is not used
because each web portal specifies its own tunnel IP address range.

1262 01-420-99686-20101026
Examples OS patch check example
OS patch check example

The following example shows how you would add an OS check to the g1portal web portal.
This OS check accepts all Windows XP users and Windows 2000 users running patch
level 2.
To specify the acceptable patch level, you set the latest-patch-level and the
tolerance. The lowest acceptable patch level is latest-patch-level minus
tolerance. In this case, latest-patch-level is 3 and tolerance is 1, so 2 is the
lowest acceptable patch level.
edit g1portal
set os-check enable
config os-check-list windows-2000
set action check-up-to-date
set latest-patch-level 3
set tolerance 1
end
config os-check-list windows-xp
set action allow
end
end

01-420-99686-20101026 1263
OS patch check example Examples

1264 01-420-99686-20101026
Chapter 10 Advanced Routing
This chapter describes advanced static routing concepts and how to implement dynamic
routing on FortiGate units.
Advanced Static routing explains routing concepts, equal cost multipath (ECMP) and load
balancing, policy routing, routing in transparent mode, and zones.
Dynamic Routing Overview provides some basic routing concepts needed to explain
dynamic routing, compares static and dynamic routing, and walks you through deciding
which dynamic routing protocol is best for you.
Routing Information Protocol (RIP), Border Gateway Protocol (BGP), and Open Shortest
Path First (OSPF) provide background on the protocol, explains the terms used, how the
protocol works, looks at some troubleshooting, and examples on configuring the protocols
in different situations.
FortiOS™ Handbook v2: Advanced Routing

01-420-99686-20101026 1265
Advanced Routing for FortiOS 4.0 MR2
1266 01-420-99686-20101026
Advanced Static routing
Advanced static routing includes features and concepts that are used in more complex
networks. Dynamic routing is not addressed in this section.
• Routing concepts
• ECMP route failover and load balancing
• Static routing tips
• Policy Routing
• Transparent mode static routing
• Zones
Routing concepts
Many routing concepts apply to static routing. However without first understanding these
basic concepts, it is difficult to understand the more complex dynamic routing.
• Routing in VDOMs
• Default route
• Routing table
• Building the routing table
• Static routing security
• Multipath routing and determining the best route
Routing in VDOMs
Routing on FortiGate units is configured per-VDOM. This means if VDOMs are enabled,
you must enter a VDOM to do any routing configuration. This allows each VDOM to
operate independently of each other, with their own default routes and routing
configuration.
In this guide, the procedures assume your FortiGate unit has VDOMs disabled. This is
stated in the assumptions for the examples. If you have VDOMs enabled you will need to
perform the following steps in addition to the procedure’s steps.

01-420-99686-20101026 1267
Routing concepts Advanced Static routing
To route in VDOMs - web-based manager

1 Look for the name of the current VDOM on the bottom of the left menu.
It will say “Current VDOM: root” or instead of root it will be the current VDOM.
2 If this is not the VDOM where you want to configure routing, you need to:
• Select << Global.
• Select System > VDOM.
• Select the Enter icon for your selected VDOM.
• Once in the VDOM, follow the procedures as normal.
To route in VDOMs - CLI

Before following any CLI routing procedures with VDOMs enabled, enter the following
commands. For this example, it is assumed you will be working in the root VDOM. Change
root to the name of your selected VDOM as needed.
config vdom
edit root
Following these commands, you can enter any routing CLI commands as normal.
Default route
The default route is used if either there are no other routes in the routing table or if none of
the other routes apply to a destination. Including the gateway in the default route gives all
traffic a next-hop address to use when leaving the local network. The gateway address is
normally another router on the edge of the local network.
All routers, including FortiGate units, are shipped with default routes in place. This allows
customers to set up and become operational more quickly. Beginner administrators can
use the default route settings until a more advanced configuration is warranted.
FortiGate units come with a default static route with an IPv4 address of 0.0.0.0, an
administration distance of 10, and a gateway IPv4 address.
Routing table
When two computers are directly connected, there is no need for routing because each
computer knows exactly where to find the other computer. They communicate directly.
Networking computers allows many computers to communicate with each other. This
requires each computer to have an IP address to identify its location to the other
computers. This is much like a mailing address - you will not receive your postal mail at
home if you do not have an address for people to send mail to. The routing table on a
computer is much like an address book used to mail letters to people in that the routing
table maintains a list of how to reach computers. Routing tables may also include
information about the quality of service (QoS) of the route, and the interface associated
with the route if the device has multiple interfaces.
Routing tables are also used in unicast reverse path forwarding (uRPF). In uRPF, the
router not only looks up the destination information, but also the source information to
ensure that it exists. If there is no source to be found, then that packet is dropped because
the router assumes it to be an error or an attack on the network.

1268 01-420-99686-20101026
Advanced Static routing Routing concepts
Looking at routing as delivering letters is more simple than reality. In reality, routers loose
power or have bad cabling, network equipment is moved without warning, and other such
events happen that prevent static routes from reaching their destinations. When any
changes such as these happen along a static route, traffic can no longer reach the
destination — the route goes down. Dynamic routing can address these changes to
ensure traffic still reaches its destination. The process of realizing there is a problem,
backtracking and finding a route that is operational is called convergence. If there is fast
convergence in a network, users won’t even know that re-routing is taking place.
The routing table for any device on the network has a limited size. For this reason, routes
that aren’t used are replaced by new routes. This method ensures the routing table is
always populated with the most current and most used routes—the routes that have the
best chance of being reused. Another method used to maintain the routing table’s size is if
a route in the table and a new route are to the same destination, one of the routes is
selected as the best route to that destination and the other route is discarded.
Routing tables are also used in unicast reverse path forwarding (uRPF). In uRPF, the
router not only looks up the destination information, but also the source information to
ensure that it exists. If there is no source to be found, then that packet is dropped because
the router assumes it to be an error or an attack on the network.
The routing table is used to store routes that are learned. The routing table for any device
on the network has a limited size. For this reason, routes that aren’t used are replaced by
new routes. This method ensures the routing table is always populated with the most
current and most used routes — the routes that have the best chance of being reused.
Another method used to maintain the routing table’s size is if a route in the table and a
new route are to the same destination, one of the routes is selected as the best route to
that destination and the other route is discarded.
Some actions you can perform on the routing table include:
• Viewing the routing table in the web-based manager
• Viewing the routing table in the CLI
• Viewing the routing table with diagnose commands
• Searching the routing table
Viewing the routing table in the web-based manager

By default, all routes are displayed in the Routing Monitor list. The default static route is
defined as 0.0.0.0/0, which matches the destination IP address of “any/all” packets.
To display the routes in the routing table, go to Router > Monitor > Routing Monitor.
Figure 172 shows the Routing Monitor list belonging to a FortiGate unit that has interfaces
named “port1”, “port4”, and “lan”. The names of the interfaces on your FortiGate unit may
be different.
Figure 173 shows the Routing Monitor list when IPv6 has been selected. Note that the
information available for IPv6 is limited.

01-420-99686-20101026 1269
Figure 172: Routing Monitor list - IPv4
Figure 173: Routing Monitor list - IPv6
IP version Select IPv4 or IPv6 routes. Fields displayed vary depending on which IP version is
selected.
Displayed only if IPv6 display is enabled on the web-based manager
Type Select one of the following route types to search the routing table and display routes
of the selected type only:
All — all routes recorded in the routing table.
Connected — all routes associated with direct connections to FortiGate unit
interfaces.
Static — the static routes that have been added to the routing table manually.
RIP — all routes learned through RIP. For more information see “Routing Information
Protocol (RIP)” on page 1309.
BGP — all routes learned through BGP. For more information see “Border Gateway
Protocol (BGP)” on page 1347.
OSPF — all routes learned through OSPF. For more information see “Open Shortest
Path First (OSPF)” on page 1385.
HA — RIP, OSPF, and BGP routes synchronized between the primary unit and the
subordinate units of a high availability (HA) cluster. HA routes are maintained on
subordinate units and are visible only if you are viewing the router monitor from a
virtual domain that is configured as a subordinate virtual domain in a virtual cluster.
Not displayed when IP version IPv6 is selected.
For details about HA routing synchronization, see the FortiGate HA User Guide.
Network Enter an IP address and netmask (for example, 172.16.14.0/24) to search the
routing table and display routes that match the specified network.
Gateway Enter an IP address and netmask (for example, 192.168.12.1/32) to search the
routing table and display routes that match the specified gateway.
Apply Filter Select to search the entries in the routing table based on the specified search criteria
and display any matching routes.
Type The type values assigned to FortiGate unit routes (Static, Connected, RIP, OSPF, or
BGP).

1270 01-420-99686-20101026
Subtype If applicable, the subtype classification assigned to OSPF routes.

An empty string implies an intra-area route. The destination is in an area to which the
FortiGate unit is connected.
OSPF inter area — the destination is in the OSPF AS, but the FortiGate unit is not
connected to that area.
External 1 — the destination is outside the OSPF AS. This is known as OSPF E1
type. The metric of a redistributed route is calculated by adding the external cost and
the OSPF cost together.
External 2 — the destination is outside the OSPF AS. This is known as OSPF E2
type. In this case, the metric of the redistributed route is equivalent to the external
cost only, expressed as an OSPF cost.
OSPF NSSA 1 — same as External 1, but the route was received through a not-so-
stubby area (NSSA).
OSPF NSSA 2 — same as External 2, but the route was received through a not-so-
stubby area.
For more information on OSPF subtypes, see “OSPF Background and concepts” on
page 1385.
Not displayed when IP version 6 is selected.
Network The IP addresses and network masks of destination networks that the FortiGate unit
can reach.
Distance The administrative distance associated with the route. A value of 0 means the route is
preferable compared to routes to the same destination.
Modifying this distance for dynamic routes is route distribution.
Metric The metric associated with the route type. The metric of a route influences how the
FortiGate unit dynamically adds it to the routing table. The following are types of
metrics and the protocols they are applied to.
Hop count — routes learned through RIP.
Relative cost — routes learned through OSPF.
Multi-Exit Discriminator (MED) — routes learned through BGP. However, several
attributes in addition to MED determine the best path to a destination network. For
more information on BGP attributes, see “BGP attributes” on page 1354.
Gateway The IP addresses of gateways to the destination networks.
Interface The interface through which packets are forwarded to the gateway of the destination
network.
Up Time The total accumulated amount of time that a route learned through RIP, OSPF, or
BGP has been reachable.
Viewing the routing table in the CLI

In the CLI, you can easily view the static routing table just as in the web-based manager or
you can view the full routing table.
When viewing the list of static routes using the CLI command get route static, it is
the configured static routes that are displayed. When viewing the routing table using the
CLI command get router info routing-table all, it is the entire routing table
information that is displayed including configured and learned routes of all types. The two
are different information in different formats.
Note: If VDOMs are enabled on your FortiGate unit, all routing related CLI commands must
be performed within a VDOM and not in the global context.
To view the routing table

# get router info routing-table all
Codes: K - kernel, C - connected, S - static, R - RIP, B - BGP
O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2

01-420-99686-20101026 1271
E1 - OSPF external type 1, E2 - OSPF external type 2

i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS
inter area
* - candidate default
S* 0.0.0.0/0 [10/0] via 192.168.183.254, port2

S 1.0.0.0/8 [10/0] via 192.168.183.254, port2
S 2.0.0.0/8 [10/0] via 192.168.183.254, port2
C 10.142.0.0/23 is directly connected, port3
B 10.160.0.0/23 [20/0] via 10.142.0.74, port3, 2d18h02m
C 192.168.182.0/23 is directly connected, port2
Examining an entry:
B 10.160.0.0/23 [20/0] via 10.142.0.74, port3, 2d18h02m
B BGP. The routing protocol used.
10.160.0.0/23 The destination of this route including netmask.
[20/0] 20 indicates and administrative distance of 20 out of a range of 0
to 255.
0 is an additional metric associated with this route, such as in
OSPF
10.142.0.74 The gateway, or next hop.
port3 The interface used by this route.
2d18h02m How old this route is, in this case almost three days old.
Viewing the routing table with diagnose commands

Diagnose commands can provide a wide variety of information about your FortiGate unit
that may otherwise be inaccessible. these commands generally provide extensive
information, but the output can be difficult to understand. You should only need to use
diagnose command when customer support tells you to do so during troubleshooting.
FortiOS documentation describes specific examples for using diagnose commands to
provide information that may be useful.
You can view the routing table using diagnostic commands. This has the benefits of being
able to be run from anywhere in the command line structure, and it is shorter. Also the
diagnose method will show localhost routes that the CLI and web-based methods will not
include.
To use diagnostic commands to view the routing table

# diag ip route list

>10.11.201.0/24 pref=10.11.201.4 gwy=0.0.0.0 dev=5(external1)

>172.20.120.0/24 pref=172.20.120.146 gwy=0.0.0.0 dev=6(internal)
The parts of the routing table entry are:
tab table number. This will be either 254 (unicast) or 255 (multicast).
vf virtual domain of the firewall. This is the vdom index number. If
vdoms are not enabled, this number will be 0.

1272 01-420-99686-20101026
type type of routing connection. Valid values include:

• 0 - unspecific
• 1 - unicast
• 2 - local
• 3 - broadcast
• 4 - anycast
• 5 - multicast
• 6 - blackhole
• 7 - unreachable
• 8 - prohibited
proto type of installation. This indicates where the route came from. Valid
values include:
• 0 - unspecific
• 2 - kernel
• 11 - ZebOS routing module
• 14 - FortiOS
• 15 - HA
• 16 - authentication based
• 17 - HA1
prio priority of the route. Lower priorities are preferred.
->10.11.201.0/24 the IP address and subnet mask of the destination
(->x.x.x.x/mask)
pref preferred next hop along this route
gwy gateway - the IPv4 address of the gateway this route will use
dev outgoing interface index. This number is associated with the
interface for this route, and if VDOMs are enabled the VDOM
will be included here as well. If an interface alias is set for this
interface it will also be displayed here.
Searching the routing table

You can apply a filter to search the routing table and display certain routes only. For
example, you can display one or more static routes, connected routes, routes learned
through RIP, OSPF, or BGP, and routes associated with the network or gateway that you
specify.
If you want to search the routing table by route type and further limit the display according
to network or gateway, all of the values that you specify as search criteria must match
corresponding values in the same routing table entry in order for that entry to be displayed
— an implicit AND condition is applied to all of the search parameters you specify.
For example, if the FortiGate unit is connected to network 172.16.14.0/24 and you want to
display all directly connected routes to network 172.16.14.0/24, you must select
Connected from the Type list, type 172.16.14.0/24 in the Network field, and then select
Apply Filter to display the associated routing table entry or entries. Any entry that contains
the word “Connected” in its Type field and the specified value in the Gateway field will be
displayed.
In this example, you will apply a filter to search for an entry for static route to
10.10.10.10/24
To search the FortiGate unit routing table in the web-based manager

1 Go to Router > Monitor > Routing Monitor.
2 From the Type list, select the type of route to display. In our example, select Static.
3 If you want to display routes to a specific network, type the IP address and netmask of
the network in the Networks field. In our example, enter 10.10.10.10/24.

01-420-99686-20101026 1273
4 If you want to display routes to a specific gateway, type the IP address of the gateway
in the Gateway field.
5 Select Apply Filter.
Note: All of the values that you specify as search criteria must match corresponding values
in the same routing table entry in order for that entry to be displayed.
To search the FortiGate unit routing table in the CLI

FGT # get router info routing-table details 10.10.10.10
Routing entry for 10.10.10.10/24
Known via "static", distance 10, metric 0, best
If there are multiple routes that match your filter, they will all be listed, with the best match
at the top of the list as indicated by the word best.
Building the routing table

In the factory default configuration, the FortiGate unit routing table contains a single static
default route. You can add routing information to the routing table by defining additional
static routes.
It is possible that the routing table is faced with several different routes to the same
destination — the IP addresses of the next-hop router specified in those routes or the
FortiGate interfaces associated with those routes may vary. In this situation, the “best”
route is selected from the table.
The FortiGate unit selects the “best” route for a packet by evaluating the information in the
routing table. The “best” route to a destination is typically associated with the shortest
distance between the FortiGate unit and the closest gateway, also known as a next-hop
router. In some cases, the next best route may be selected if the best route is unavailable.
The FortiGate unit installs the best available routes in the unit’s forwarding table, which is
a subset of the unit’s routing table. Packets are forwarded according to the information in
the forwarding table.
Static routing security

Securing the information on your company network is a top priority for network
administrators. Security is also required as the routing protocols used are internationally
known standards that typically provide little or no inherent security by themselves.
The two reasons for securing your network are the sensitive and proprietary information
on your network, and also your external bandwidth. Hackers not only can steal your
information, but they can also steal your bandwidth. Routing is a good low level way to
secure your network, even before UTM features are applied.
Routing provides security to your network in a number of ways including obscuring internal
network addresses with NAT and blackhole routing, using RPF to validate traffic sources,
and maintaining an access control list (ACL) to limit access to the network.
• Network Address Translation (NAT)
• Access Control List (ACL)
• Blackhole Route
• Reverse path lookup

1274 01-420-99686-20101026
Network Address Translation (NAT)

Network address translation (NAT) is a method of changing the address traffic appears to
originate from. This practice is used to hide the IP address on company’s internal
networks, and helps prevent malicious attacks that use those specific addresses.
This is accomplished by the router connected to that local network changing all the IP
addresses to its externally connected IP address before sending the traffic out to the other
networks, such as the Internet. Incoming traffic uses the established sessions to
determine which traffic goes to which internal IP address. This also has the benefit of
requiring only the router to be very secure against external attacks, instead of the whole
internal network as would be the case without NAT. Securing one computer is much
cheaper and easier to maintain.
Configuring NAT on your FortiGate unit includes the following steps.
1 Configure your internal network. For example use the 10.11.101.0 subnet.
2 Connect your internal subnet to an interface on your FortiGate unit. For example use
port1.
3 Connect your external connection, for example an ISP gateway of 172.20.120.2, to
another interface on your Fortigate unit, for example port2.
4 Configure firewall policies to allow traffic between port1 and port2 on your FortiGate
unit, ensuring that the NAT feature is enabled.
The above steps show that traffic from your internal network will originate on the
10.11.101.0 subnet and pass on to the 172.20.120.0 network. The FortiGate unit moves
the traffic to the proper subnet. In doing that, the traffic appears to originate from the
FortiGate unit interface on that subnet — it does not appear to originate from where it
actually came from.
NAT “hides” the internal network from the external network. This provides security through
obscurity. If a hacker tries to directly access your network, they will find the Fortigate unit,
but will not know about your internal network. The hacker would have to get past the
security-hardened FortiGate unit to gain access to your internal network. NAT will not
prevent hacking attempts that piggy back on valid connections between the internal
network and the outside world. However other UTM security measures can deal with
these attempts.
Another security aspect of NAT is that many programs and services have problems with
NAT. Consider if someone on the Internet tries to initiate a chat with someone on the
internal network. The outsider only can access the FortiGate unit’s external interface
unless the firewall policy allows the traffic through to the internal network. If allowed in, the
proper internal user would respond to the chat. However if its not allowed, the request to
chat will be refused or time-out. This is accomplished in the firewall policy by allowing or
denying different protocols.
Access Control List (ACL)

An access control list (ACL) is a table of addresses that have permission to send and
receive data over a router’s interface or interfaces. The router maintains an ACL, and
when traffic comes in on a particular interface it is buffered, while the router looks up in the
ACL if that traffic is allowed over that port or not. If it is allowed on that incoming interface,
then the next step is to check the ACL for the destination interface. If the traffic passes that
check as well the buffered traffic is delivered to its accentuation. If either of those steps fail
the ACL check, the traffic is dropped and an error message may be sent to the sender.

01-420-99686-20101026 1275
The ACL ensures that traffic follows expected paths, and any unexpected traffic is not
delivered. This stops many network attacks. However, to be effective the ACL must be
kept up to date —when employees or computers are removed from the internal network
their IP addresses must also be removed from the ACL. For more information on the ACL,
see the router chapter of the FortiGate CLI Reference.
Blackhole Route
A blackhole route is a route that drops all traffic sent to it. It is very much like /dev/null in
Linux programming.
Blackhole routes are used to dispose of packets instead of responding to suspicious
inquiries. This provides added security since the originator will not discover any
information from the target network.
Blackhole routes can also limit traffic on a subnet. If some subnet addresses are not in
use, traffic to those addresses (traffic which may be valid or malicious) can be directed to
a blackhole for added security and to reduce traffic on the subnet.
The loopback interface, a virtual interface that does not forward traffic, was added to
enable easier configuration of blackhole routing. Similar to a normal interface, this
loopback interface has fewer parameters to configure, and all traffic sent to it stops there.
Since it cannot have hardware connection or link status problems, it is always available,
making it useful for other dynamic routing roles. Once configured, you can use a loopback
interface in firewall policies, routing, and other places that refer to interfaces. You
configure this feature only from the CLI. For more information, see the system chapter of
Reverse path lookup

Whenever a packet arrives at one of the FortiGate unit’s interfaces, the unit determines
whether the packet was received on a legitimate interface by doing a reverse lookup using
the source IP address in the packet header. This is also called anti-spoofing. If the
FortiGate unit cannot communicate with the computer at the source IP address through
the interface on which the packet was received, the FortiGate unit drops the packet as it is
likely a hacking attempt.
If the destination address can be matched to a local address (and the local configuration
permits delivery), the FortiGate unit delivers the packet to the local network. If the packet
is destined for another network, the Fortigate unit forwards the packet to a next-hop router
according to a policy route and the information stored in the FortiGate forwarding table.
Multipath routing and determining the best route

Multipath routing occurs when more than one entry to the same destination is present in
the routing table. When multipath routing happens, the FortiGate unit may have several
possible destinations for an incoming packet, forcing the FortiGate unit to decide which
next-hop is the best one.
It should be noted that some IP addresses will be rejected by routing protocols. These are
called Martian addresses. They are typically IP addresses that are invalid and not routable
because they have been assigned an address by a misconfigured system, or are spoofed
addresses.
Two methods to manually resolve multiple routes to the same destination are to lower the
administrative distance of one route or to set the priority of both routes. For the FortiGate
unit to select a primary (preferred) route, manually lower the administrative distance
associated with one of the possible routes. Setting the priority on the routes is a FortiGate
unit feature and may not be supported by non-Fortinet routers.

1276 01-420-99686-20101026
Administrative distance is based on the expected reliability of a given route. It is

determined through a combination of the number of hops from the source and the protocol
used. A hop is when traffic moves from one router to the next. More hops from the source
means more possible points of failure. The administrative distance can be from 1 to 255,
with lower numbers being preferred. A distance of 255 is seen as infinite and will not be
installed in the routing table.
Here is an example to illustrate how administration distance works — if there are two
possible routes traffic can take between two destinations with administration distances of
5 (always up) and 31 (sometimes not available), the traffic will use the route with an
administrative distance of 5. If for some reasons the preferred route (admin distance of 5)
is not available, the other route will be used as a backup.
Different routing protocols have different default administrative distances. These different
administrative distances are based on a number of factors of each protocol such as
reliability, speed, and so on. The default administrative distances for any of these routing
protocols are configurable.
Table 74: Default administrative distances for routing protocols and connections
Routing Default administrative

protocol distance
Direct physical 1
connection
Static 10
EBGP 20
OSPF 110
RIP 120
IBGP 200
Another method to determine the best route is to manually change the priority of both
routes in question. If the next-hop administrative distances of two routes on the FortiGate
unit are equal, it may not be clear which route the packet will take. Manually configuring
the priority for each of those routes will make it clear which next-hop will be used in the
case of a tie. The priority for a route can only be set from the CLI. Lower priorities are
preferred. Priority is a Fortinet value that may or may not be present in other brands of
routers.
All entries in the routing table are associated with an administrative distance. If the routing
table contains several entries that point to the same destination (the entries may have
different gateways or interface associations), the FortiGate unit compares the
administrative distances of those entries first, selects the entries having the lowest
distances, and installs them as routes in the FortiGate unit forwarding table. As a result,
the FortiGate unit forwarding table contains only those routes having the lowest distances
to every possible destination. While only static routing uses administrative distance as its
routing metric, other routing protocols such as RIP can use metrics that are similar to
administrative distance.
Route priority
After the FortiGate unit selects static routes for the forwarding table based on their
administrative distances, the priority field of those routes determines routing preference.
Priority is a Fortinet value that may or may not be present in other brands of routers.
You can configure the priority field through the CLI or the web-based manager. Priority
values can range from 0 to 4 294 967 295. The route with the lowest value in the priority
field is considered the best route. It is also the primary route.

01-420-99686-20101026 1277
To change the priority of a route to 5 for a route - web-based manager

2 Select the route entry, and select Edit.
3 Enter 5 for Priority.
4 Select OK.
To change the priority of a route to 5 for a route - CLI

The following command changes the priority of a route to 5 for a route to the address
10.10.10.1 on the port1 interface.
edit 1
set device port1
set dst 10.10.10.1
set priority 5
end
If there are other routes set to priority 10, the route set to priority 5 will be preferred. If
there are routes set to priorities less than 5, those other routes will be preferred instead.
In summary, because you can use the CLI to specify which sequence numbers or priority
field settings to use when defining static routes, you can prioritize routes to the same
destination according to their priority field settings. For a static route to be the preferred
route, you must create the route using the config router static CLI command and
specify a low priority for the route. If two routes have the same administrative distance and
the same priority, then they are equal cost multipath (ECMP) routes.
Since this means there is more than one route to the same destination, it can be confusing
which route or routes to install and use. However, if you have enabled load balancing with
ECMP routes, then different sessions will resolve this problem by using different routes to
the same address.
Troubleshooting static routing

When there are problems with your network that you believe to be static routing related,
there are a few basic tools available to locate the problem.
These tools include:
• Ping
• Traceroute
• Examine routing table contents
Ping
Beyond the basic connectivity information, ping can tell you the amount of packet loss (if
any), how long it takes the packet to make the round trip, and the variation in that time
from packet to packet.
If there is no packet loss detected, your basic network connectivity is OK.
If there is some packet loss detected, you should investigate:
• possible ECMP, split horizon, network loops
• cabling to ensure no loose connections

1278 01-420-99686-20101026
If there is total packet loss, you should investigate:

• hardware - ensure cabling is correct, and all equipment between the two locations is
accounted for
• addresses and routes - ensure all IP addresses and routing information along the route
is configured as expected
• firewalls - ensure all firewalls are set to allow PING to pass through
To ping from a Windows PC

1 Go to a DOS prompt. Typically you go to Start > Run, enter cmd and select OK.
2 Enter ping 10.11.101.100 to ping the default internal interface of the FortiGate unit
with four packets.
To ping from a Linux PC

2 Enter “/bin/etc/ping 10.11.101.101”.
For more information on ping, see “Troubleshooting connectivity” on page 677.
Traceroute
Where ping will only tell you if it reached its destination and came back successfully,
traceroute will show each step of its journey to its destination and how long each step
takes. If ping finds an outage between two points, traceroute can be used to locate exactly
where the problem is.
To use traceroute on an MS Windows PC

1 Go to a DOS prompt. Typically you go to Start > Run, enter “cmd” and select OK.
2 Enter “tracert fortinet.com” to trace the route from the PC to the Fortinet
website.
To perform a traceroute on a Linux PC

2 Enter “/bin/etc/traceroute fortinet.com”.
The Linux traceroute output is very similar to the MS Windows traceroute output.
Examine routing table contents

The first place to look for information is the routing table.
The routing table is where all the currently used routes are stored for both static and
dynamic protocols. If a route is in the routing table, it saves the time and resources of a
lookup. If a route isn’t used for a while and a new route needs to be added, the oldest least
used route is bumped if the routing table is full. This ensures the most recently used routes
stay in the table. Note that if your FortiGate unit is in Transparent mode, you are unable to
perform this step.
If the FortiGate is running in NAT mode, verify that all desired routes are in the routing
table: local subnets, default routes, specific static routes, and dynamic routing protocols.
To check the routing table in the web-based manager, use the Routing Monitor — go to
System > Routing > Monitor. In the CLI, use the command get router routing-
table all.

01-420-99686-20101026 1279
ECMP route failover and load balancing Advanced Static routing
To examine the firewall session list in the web-based manager

1 Go to System > Status > Dashboard > Top Sessions.
2 Select Detach, and then Details.
3 Expand the session window to full screen to display the information.
4 Change filters, view associated firewall policy, column ordering, and so on to analyze
the sessions in the table.
5 Select the delete icon to terminate the session.
ECMP route failover and load balancing

Equal Cost Multi-Path (ECMP) load balancing, and failover are methods that extend the
basic static routing. They allow you to use your network bandwidth more effectively and
will less down time than if you just used basic static routing alone.
The concepts in this section include:
• Route priority
• Equal-Cost Multi-Path (ECMP)
• Configuring spill-over or usage-based ECMP
• Configuring weighted static route load balancing
Route priority
After the FortiGate unit selects static routes for the forwarding table based on their
administrative distances, the priority field of those routes determines routing preference.
Priority is a Fortinet value that may or may not be present in other brands of routers.
You can only configure the priority field through the CLI. Priority values can range from 0
to 255. The route with the lowest value in the priority field is considered the best route, and
it is also the primary route.
For example, use the following command to change the priority of a route to 5 for a route
to the address 10.10.10.1 on the port1 interface.
edit 1
set device port1
set dst 10.10.10.1
set priority 5
end
If there are other routes at priority 10, this route will be preferred. If there are routes at
priority less than 5, those other routes will be preferred instead.
In summary, because you can use the CLI to specify which sequence numbers or priority
field settings to use when defining static routes, you can prioritize routes to the same
destination according to their priority field settings. For a static route to be the preferred
route, you must create the route using the config router static CLI command and
specify a low priority for the route. If two routes have the same administrative distance and
the same priority, then they are equal cost multipath (ECMP) routes.
Since this means there is more than one route to the same destination, it can be confusing
which route or routes to install and use. However, if you have enabled load balancing with
ECMP routes, then different sessions will resolve this problem by using different routes to
the same address.

1280 01-420-99686-20101026
Advanced Static routing ECMP route failover and load balancing
Equal-Cost Multi-Path (ECMP)

FortiOS uses equal-cost multi-path (ECMP) to distribute traffic to the same destination
such as the Internet or another network. Using ECMP you can add multiple routes to the
destination and give each of those routes the same distance and priority.
Note: If multiple routes to the same destination have the same priority but different
distances, the route with the lowest distance is used. If multiple routes to the same
destination have the same distance but different priorities, the route with the lowest priority
is used. Distance takes precedence over priority. If multiple routes to the same destination
have different distances and different priorities, the route with the lowest distance is always
used even if it has the highest priority.
Using ECMP, if more than one ECMP route is available you can configure how the
FortiGate unit selects the route to be used for a communication session. If only one ECMP
route is available (for example, because an interface cannot process traffic because
interface status detection does not receive a reply from the configured server) then all
traffic uses this route.
Previous versions of FortiOS provided source IP-based load balancing for ECMP routes,
but now FortiOS includes three configuration options for ECMP route failover and load
balancing:
Source based (also The FortiGate unit load balances sessions among ECMP routes
called source IP based on the source IP address of the sessions to be load
based) balanced. This is the default load balancing method. No
configuration changes are required to support source IP load
balancing.
Weighted (also called The FortiGate unit load balances sessions among ECMP routes
weight-based) based on weights added to ECMP routes. More traffic is directed
to routes with higher weights.
After selecting weight-based you must add weights to static
routes.
Spill-over (also called The FortiGate unit distributes sessions among ECMP routes
usage-based) based on how busy the FortiGate interfaces added to the routes
are.
After selecting spill-over you add route Spillover Thresholds to
interfaces added to ECMP routes. The FortiGate unit sends all
ECMP-routed sessions to the lowest numbered interface until the
bandwidth being processed by this interface reaches its spillover
threshold. The FortiGate unit then spills additional sessions over
to the next lowest numbered interface.
The Spillover Thresholds range is 0-2097000 KBps.
You can configure only one of these ECMP route failover and load balancing methods in a
single VDOM. If your FortiGate unit is configured for multiple VDOM operation, each
VDOM can have its own ECMP route failover and load balancing configuration.
To configure the ECMP route failover and load balancing method from the
web-based manager
2 Set ECMP Route failover & Load Balance Method to source based, weighted, or
spill-over.
3 Select Apply.
To configure the ECMP route failover and load balancing method from the CLI
Enter the following command:

01-420-99686-20101026 1281
set v4-ecmp-mode {source-ip-based | usage-based |

weight-based}
end
ECMP routing of simultaneous sessions to the same destination IP

address
When the FortiGate unit selects an ECMP route for a session, a route cache is created
that matches the route with the destination IP address of the session. All new sessions to
the same destination IP address use the same route until the route is flushed from the
cache. Routes are flushed from the cache after a period of time when no new sessions to
the destination IP address are received.
The route cache improves FortiGate unit routing performance by reducing how often the
FortiGate unit looks up routes in the routing table.
If the FortiGate unit receives a large number of sessions with the same destination IP
address, because all of these sessions will be processed by the same route, it may appear
that sessions are not distributed according to the ECMP route failover and load balancing
configuration.
Configuring spill-over or usage-based ECMP

Spill-over or usage-based ECMP routes new sessions to interfaces that have not reached
a configured bandwidth limit (called the Spillover Threshold or a route-spillover threshold).
To configure spill-over or usage-based ECMP routing, you enable spill-over ECMP, add
ECMP routes, and add a Spillover Threshold to the interfaces used by the ECMP routes.
Set the Spillover Thresholds to limit the amount of bandwidth processed by each interface.
With spill-over ECMP routing configured, the FortiGate unit routes new sessions to an
interface used by an ECMP route until that interface reaches its Spillover Threshold. Then,
when the threshold of that interface is reached, new sessions are routed to one of the
other interfaces used by the ECMP routes.
To add Spillover Thresholds to interfaces from the web-based manager

Use the following steps to enable usage based ECMP routing, add Spillover Thresholds to
FortiGate interfaces port3 and port4, and then to configure EMCP routes with device set to
port3 and port4.
2 Set ECMP Route failover & Load Balance Method to usage-based.
4 Add ECMP routes for port3 and port4.

Device port3
Gateway 172.20.130.3
Distance 10

Device port4
Gateway 172.20.140.4
Distance 10

1282 01-420-99686-20101026
Advanced Static routing ECMP route failover and load balancing
6 Edit port3 and port4 and add the following spillover-thresholds:
Interface port3
Spillover Threshold (KBps) 100
Interface port4
Spillover Threshold (KBps) 200
Detailed description of how spill-over ECMP selects routes

When you add ECMP routes they are added to the routing table in the order displayed by
the routing monitor or by the get router info routing-table static command.
This order is independent of the configured bandwidth limit.
The FortiGate unit selects an ECMP route for a new session by finding the first route in the
routing table that sends the session out a FortiGate unit interface that is not processing
more traffic that its configured route spill-over limit.
Note: A new session to a destination IP address that already has an entry in the routing
cache is routed using the route already added to the cache for that destination address.
See “ECMP routing of simultaneous sessions to the same destination IP address” on
page 1282.
For example, consider a FortiGate unit with interfaces port3 and port4 both connected to
the Internet through different ISPs. ECMP routing is set to usage-based and route
spillover for to 100 KBps for port3 and 200 KBps for port4. Two ECMP default routes are
added, one for port3 and one for port4.
If the route to port3 is higher in the routing table than the route to port4, the FortiGate unit
sends all default route sessions out port3 until port3 is processing 10Mbps of data. When
port3 reaches its configured bandwidth limit, the FortiGate unit sends all default route
sessions out port4. When the bandwidth usage of port3 falls below 10Mbps, the FortiGate
again sends all default route sessions out port3.
New sessions to designating IP addresses that are already in the routing cache; however,
use the cached routes. This means that even of port3 is exceeding its bandwidth limit, new
sessions can continue to be sent out port3 if their destination addresses are already in the
routing cache. As a result, new sessions are sent out port4 only if port3 exceeds its
bandwidth limit and if the routing cache does not contain a route for the destination IP
address of the new session.
Also, the switch over to port4 does not occur as soon as port3 exceeds its bandwidth limit.
Bandwidth usage has to exceed the limit for a period of time before the switch over takes
place. If port3 bandwidth usage drops below the bandwidth limit during this time period,
sessions are not switched over to port4. This delay reduces route flapping.
FortiGate usage-based ECMP routing is not actually load balancing, since routes are not
distributed evenly among FortiGate interfaces. Depending on traffic volumes, most traffic
would usually be processed by the first interface with only spillover traffic being processed
by other interfaces.
If you are configuring usage-based ECMP in most cases you should add spillover
thresholds to all of the interfaces with ECMP routes. The default spillover threshold is 0
which means no bandwidth limiting. If any interface has a spillover threshold of 0, no
sessions will be routed to interfaces lower in the list unless the interface goes down or is
disconnected. An interface can go down if Detect interface status for Gateway Load
Balancing does not receive a response from the configured server.

01-420-99686-20101026 1283
Determining of an interface has exceeded its Spillover Threshold

You can use the diagnose netlink dstmac list CLI command to determine if an
interface is exceeding its Spillover Threshold. If the command displays over_bps=1 the
interface is exceeding its threshold. If over_bps=0 the interface has not exceeded its
threshold.
Configuring weighted static route load balancing

Configure weighted load balancing to control how the FortiGate unit distributes sessions
among ECMP routes by adding weights for each route. Add higher weights to routes that
you want to load balance more sessions to.
With the ECMP load balancing method set to weighted, the FortiGate unit distributes
sessions with different destination IPs by generating a random value to determine the
route to select. The probability of selecting one route over another is based on the weight
value of each route. Routes with higher weights are more likely to be selected.
Large numbers of sessions are evenly distributed among ECMP routes according to the
route weight values. If all weights are the same, sessions are distributed evenly. The
distribution of a small number of sessions; however, may not be even. For example, its
possible that if there are two ECMP routes with the same weight; two sessions to different
IP addresses could use the same route. On the other hand, 10,000 sessions with different
destination IPs should be load balanced evenly between two routes with equal rates. The
distribution could be 5000:5000 or 50001:4999. Also, 10 000 sessions with different
destination IP addresses should be load balanced as 3333:6667 if the weights for the two
routes are 100 and 200.
Weights only affect how routes are selected for sessions to new destination IP addresses.
New sessions to IP addresses already in the routing cache are routed using the route for
the session already in the cache. So in practice sessions will not always be distributed
according to the routing weight distribution.
To add weights to static routes from the web-based manager

2 Set ECMP Route failover & Load Balance Method to weighted.
4 Add new or edit static routes and add weights to them.
The following example shows two ECMP routes with weights added.

Device port1
Gateway 172.20.110.1
Distance 10
Weight 100

Device port2
Gateway 172.20.120.2
Distance 10
Weight 200

1284 01-420-99686-20101026
Advanced Static routing Static routing tips
Static routing tips

When your network goes beyond basic static routing, here are some tips to help you plan
and manage your static routing.
Always configure a default route

The first thing configured on a router on your network should be the default route. And
where possible the default routes should point to either one or very few gateways. This
makes it easier to locate and correct problems in the network. By comparison, if one router
uses a second router as its gateway which uses a fourth for its gateway and so on, one
failure in that chain will appear as an outage for all the devices downstream. By using one
or very few addresses as gateways, if there is an outage on the network it will either be
very localized or network-wide — either is easy to troubleshoot.
Have an updated network plan

A network plan lists different subnets, user groups, and different servers. Essentially is
puts all your resources on the network, and shows how the parts of your network are
connected. Keeping your plan updated will also help you troubleshoot problems more
quickly when they arise.
The Fortinet Technical Documentation team has an example network configuration that is
used for example networks in FortiOS documentation. See “Example Network
A network plan helps your static routing by eliminating potential bottlenecks, and helping
troubleshoot any routing problems that come up. Also you can use it to plan for the future
and act on any changes to your needs or resources more quickly.
Plan for expansion

No network remains the same size. At some time, all networks grow. If you take future
growth into account, there will be less disruption to your existing network when that growth
happens. For example allocating a block of addresses for servers can easily prevent
having to re-assign IP addresses to multiple servers due to a new server.
With static routing, if you group parts of your network properly you can easily use network
masks to address each part of your network separately. This will reduce the amount of
administration required both to maintain the routing, and to troubleshoot any problems.
Configure as much security as possible

Securing your network through static routing methods is a good low level method to
defend both your important information and your network bandwidth.
• Implement NAT to obscure your IP address is an excellent first step.
• Implement black hole routing to hide which IP addresses are in use or not on your local
network.
• Configure and use access control list (ACL) to help ensure you know only valid users
are using the network.
All three features limit access to the people who should be using your network, and
obscure your network information from the outside world and potential hackers.

01-420-99686-20101026 1285
Policy Routing Advanced Static routing
Policy Routing
Policy routing allows you to redirect traffic away from a static route. This can be useful if
you want to route certain types of network traffic differently. You can use incoming traffic’s
protocol, source address or interface, destination address, or port number to determine
where to send the traffic. For example, generally network traffic would go to the router of a
subnet, but you might want to direct SMTP or POP3 traffic directly to the mail server on
that subnet.
If you have configured the FortiGate unit with routing policies and a packet arrives at the
FortiGate unit, the FortiGate unit starts at the top of the Policy Route list and attempts to
match the packet with a policy. If a match is found and the policy contains enough
information to route the packet (a minimum of the IP address of the next-hop router and
the FortiGate interface for forwarding packets to it), the FortiGate unit routes the packet
using the information in the policy. If no policy route matches the packet, the FortiGate unit
routes the packet using the routing table.
Note: Most policy settings are optional, so a matching policy alone might not provide
enough information for forwarding the packet. The FortiGate unit may refer to the routing
table in an attempt to match the information in the packet header with a route in the routing
table. For example, if the outgoing interface is the only item in the policy, the FortiGate unit
looks up the IP address of the next-hop router in the routing table. This situation could
happen when the interfaces are dynamic (such as DHCP or PPPoE) and you do not want
or are unable to specify the IP address of the next-hop router.
Policy route options define which attributes of a incoming packet cause policy routing to
occur. If the attributes of a packet match all the specified conditions, the FortiGate unit
routes the packet through the specified interface to the specified gateway.
Table 75 shows the policy route list belonging to a FortiGate unit that has interfaces
named external and internal. The names of the interfaces on your FortiGate unit
may be different.
To edit an existing policy route, see “Adding a policy route” on page 1286.
Table 75: Policy Routing list fields
Create New Add a policy route. See “Adding a policy route” on page 1286.
# The ID numbers of configured route policies. These numbers are sequential
unless policies have been moved within the table.
Incoming The interfaces on which packets subjected to route policies are received.
Outgoing The interfaces through which policy routed packets are routed.
Source The IP source addresses and network masks that cause policy routing to occur.
Destination The IP destination addresses and network masks that cause policy routing to
occur.
Delete icon Delete a policy route.
Edit icon Edit a policy route.
Move To icon After selecting this icon, enter the destination position in the window that
appears, and select OK.
For more information, see “Moving a policy route” on page 1288.
Adding a policy route

To add a policy route, go to Router > Static > Policy Route and select Create New.
For more information on Type of Service, see “Type of Service” on page 1287.

1286 01-420-99686-20101026
Advanced Static routing Policy Routing
Table 76 shows the New Routing Policy dialog box belonging to a FortiGate unit that has
interfaces named external and internal. The names of the interfaces on your
FortiGate unit may be different.
Table 76: New Routing Policy fields
Protocol To perform policy routing based on the value in the protocol field of the
packet, enter the protocol number to match. The Internet Protocol Number is
found in the IP packet header. RFC 5237 describes protocol numbers and
you can find a list of the assigned protocol numbers here. The range is from 0
to 255. A value of 0 disables the feature.
Tip: Commonly used Protocol settings include 6 to route TCP sessions, 17
for UDP sessions, 1 for ICMP sessions, 47 for GRE sessions, and 92 for
multicast sessions.
For protocols other than 6 and 17, the port number is ignored.
Incoming Interface Select the name of the interface through which incoming packets subjected to
the policy are received.
Source Address / To perform policy routing based on the IP source address of the packet, type
Mask the source address and network mask to match. A value of
0.0.0.0/0.0.0.0 disables the feature.
Destination To perform policy routing based on the IP destination address of the packet,
Address / Mask type the destination address and network mask to match. A value of
0.0.0.0/0.0.0.0 disables the feature.
Destination Ports To perform policy routing based on the port on which the packet is received,
type the same port number in the From and To fields. To apply policy routing
to a range of ports, type the starting port number in the From field and the
ending port number in the To field. A value of 0 disables this feature.
The Destination Ports fields are only used for TCP and UDP protocols. The
ports are skipped over for all other protocols.
Type of Service Use a two digit hexadecimal bit pattern to match the service, or use a two digit
hexadecimal bit mask to mask out. For more information, see “Type of
Service” on page 1287.
Outgoing Interface Select the name of the interface through which packets affected by the policy
will be routed.
Gateway Address Type the IP address of the next-hop router that the FortiGate unit can access
through the specified interface. A value of 0.0.0.0 is not valid.
Example policy route

Configure the following policy route to send all FTP traffic received at port1 out the
port10 interface and to a next hop router at IP address 172.20.120.23. To route FTP
traffic set protocol to 6 (for TCP) and set both of the destination ports to 21, the FTP port.
Protocol 6
Incoming interface port1
Source address / mask 0.0.0.0/0.0.0.0
Destination address / mask 0.0.0.0/0.0.0.0
Type of Service bit pattern: 00 (hex) bit mask: 00 (hex)
Outgoing interface port10
Gateway Address 172.20.120.23
Type of Service
Type of service (TOS) is an 8-bit field in the IP header that enables you to determine how
the IP datagram should be delivered, with such qualities as delay, priority, reliability, and
minimum cost.

01-420-99686-20101026 1287
Policy Routing Advanced Static routing
Each quality helps gateways determine 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, the
highest is 7 - when bits 3, 4, and 5 are all set to 1. The router tries to match the TOS of the
datagram to the TOS on one of the possible routes to the destination. If there is no match,
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. For more information, see RFC 791 and RFC
1349.
Table 77: The role of each bit in the IP header TOS 8-bit field
bits 0, 1, 2 Precedence Some networks treat high precedence traffic as more important
traffic. Precedence should only be used within a network, and
can be used differently in each network. Typically you do not
care about these bits.
bit 3 Delay When set to 1, this bit indicates low delay is a priority. This is
useful for such services as VoIP where delays degrade the
quality of the sound.
bit 4 Throughput When set to 1, this bit indicates high throughput is a priority.
This is useful for services that require lots of bandwidth such
as video conferencing.
bit 5 Reliability When set to 1, this bit indicates high reliability is a priority. This
is useful when a service must always be available such as with
DNS servers.
bit 6 Cost When set to 1, this bit indicates low cost is a priority. Generally
there is a higher delivery cost associated with enabling bits 3,4,
or 5, and bit 6 indicates to use the lowest cost route.
bit 7 Reserved for Not used at this time.
future use
For example, if you want to assign low delay, and high reliability, say for a VoIP application
where delays are unacceptable, you would use a bit pattern of xxx1x1xx where an ‘x’
indicates that bit can be any value. Since all bits are not set, this is a good use for the bit
mask; if the mask is set to 0x14, it will match any TOS packets that are set to low delay
and high reliability.
Moving a policy route

A routing policy is added to the bottom of the routing table when it is created. If you prefer
to use one policy over another, you may want to move it to a different location in the
routing policy table.
The option to use one of two routes happens when both routes are a match, for example
172.20.0.0/255.255.0.0 and 172.20.120.0/255.255.255.0. If both of these
routes are in the policy table, both can match a route to 172.20.120.112 but you
consider the second one as a better match. In that case the best match route should be
positioned before the other route in the policy table.
In the case of two matches in the routing table, alternating sessions will use both routes in
a load balancing configuration. You can also manually assign priorities to routes. For two
matches in the routing table, the priority will determine which route is used. This feature is
available only through the CLI. For details, see the FortiGate CLI Reference.
To change the position of a policy route in the table, go to Router > Static > Policy Route
and select Move To for the policy route you want to move.

1288 01-420-99686-20101026
Advanced Static routing Transparent mode static routing
Before/After Select Before to place the selected Policy Route before the indicated route.
Select After to place it following the indicated route.
Policy route ID Enter the Policy route ID of the route in the Policy route table to move the
selected route before or after.
Transparent mode static routing

FortiOS operating modes allow you to change the configuration of your FortiGate unit
depending on the role it needs to fill in your network.
NAT/Route operating mode is the standard mode where all interfaces are accessed
individually, and traffic can be routed between ports to travel from one network to another.
In transparent operating mode, all physical interfaces act like one interface. The FortiGate
unit essentially becomes a bridge — traffic coming in over any interface is broadcast back
out over all the interfaces on the FortiGate unit.
In transparent mode, there is no entry for routing at the main level of the menu on the web-
based manager display as there is in NAT/Route mode. Routing is instead accessed
through the network menu option.
To view the routing table in transparent mode, go to Network > Routing Table.
When viewing or creating a static route entry in transparent mode there are only three
fields available.
Destination IP/Mask The destination of the traffic being routed. The first entry is
attempted first for a match, then the next, and so on until a match
is found or the last entry is reached. If no match is found, the traffic
will not be routed.
Use 0.0.0.0 to match all traffic destinations. This is the default
route.
Gateway Specifies the next hop for the traffic. Generally the gateway is the
address of a router on the edge of your network.
Priority The priority is used if there is more than one match for a route.
This allows multiple routes to be used, with one preferred. If the
preferred route is unavailable the other routes can be used
instead.
Valid range of priority can be from 0 to 4 294 967 295.
If more than one route matches and they have the same priority it
becomes an ECMP situation and traffic is shared among those
routes. See “Route priority” on page 1280.
When configuring routing on a FortiGate unit in transparent mode, remember that all
interfaces must be connected to the same subnet. That means all traffic will be coming
from and leaving on the same subnet. This is important because it limits your static routing
options to only the gateways attached to this subnet. For example, if you only have one
router connecting your network to the Internet then all static routing on the FortiGate unit
will use that gateway. For this reason static routing on FortiGate units in transparent mode
may be a bit different, but it is not as complex as routing in NAT/Route mode.
Zones
Zones allow you to group interfaces into zones to simplify firewall policy creation. By
grouping interfaces into a zone, you can add one set of firewall policies for the zone
instead of adding separate policies for each interface — what address groups do for
addresses in firewall policies, zones do for interfaces. Once you add interfaces to a zone
you cannot configure policies for the single interfaces, only for the entire zone.

01-420-99686-20101026 1289
Zones Advanced Static routing
You can add all types of interfaces to a zone (physical, VLAN, switch, and so on) and a
zone can consist of any combination of interface types. You can add zones, rename and
edit zones, and delete zones from the zone list. When you add a zone, you select the
names of the interfaces to add to the zone.
• Creating or editing a zone
• Blocking intra-zone traffic
• IP pools and zones
• Zones in VDOMs
• Zones in transparent mode
Creating or editing a zone

To view the zone list, go to Network > Zones. If VDOMs are enabled, ensure you are in the
correct VDOM first.
To create or edit a zone

1 If VDOMs are enabled, select the VDOM from the Current VDOM list.
Note: The VDOM must have at least two physical or virtual interfaces assigned to it.
2 Go to Network > Zone.
4 Enter the Zone Name, enable Block intra-zone traffic if desired, and select the
interfaces to include in this zone.
5 Select OK.
Blocking intra-zone traffic

Apart from grouping interfaces to allow them to be treated as one in a firewall policy, the
other feature of zones is the ability to block intra-zone traffic. This prevents traffic between
interfaces within the zone.
For example a FortiGate unit has an accounting department on one interface, sales
department on another interface, and marketing on a third interface. The office has a
common Internet policy, so all three interfaces can be grouped into a zone for easier
firewall policy management. However, the types of traffic for each department is very
different and it is potentially dangerous to the company for accounting information to be
accessed by other departments. In this case blocking intra-zone traffic would protect the
accounting data and not require extra firewall policies to accomplish it.
From this example you can see that blocking the intra-zone traffic can also be
accomplished with firewall policies. However, this method is much more complex and time
consuming especially if all traffic can be blocked. The firewall method must be used if
some traffic will be allowed but not other traffic.
The benefits of blocking intra-zone traffic are:
• it automatically applies to all interfaces in the zone
• you don’t have to update one or more firewall policies
• it offloads work from the firewall which saves resources

1290 01-420-99686-20101026
Advanced Static routing Zones
IP pools and zones

You cannot use IP pools when using zones. An IP pool can only be associated with an
interface.
Zones in VDOMs
Zones are configured in virtual domains (VDOMs). If you have added multiple VDOMs to
your FortiGate unit configuration, make sure you are configuring the correct VDOM before
adding or editing zones. Zones do not appear on the Global level Network menu.
Zones in transparent mode

Up to this point, everything about zones only applies to NAT/Route operating mode. In
NAT/Route mode there are many interfaces making it easy to create zones.
In Transparent mode, the FortiGate unit behaves like a layer-2 bridge but can still provide
services such as antivirus scanning, web filtering, spam filtering and intrusion protection to
traffic. There are some limitations in Transparent mode in that you cannot use SSL VPN,
PPTP/L2TP VPN, DHCP server, or easily perform NAT on traffic.
In transparent mode you can still select interfaces for a zone, but applying firewall policies
to them is problematic since all interfaces are on the same subnet, and any interfaces not
in the zone will spread the traffic the firewall policies would be trying to limit.
VLANs can still be grouped into zones so that firewall policies can be applied only to
VLANs. In Transparent mode, packets can not move between different VLANs — they are
limited to VLAN trunks which enter and leave the FortiGate unit with the same VLAN ID
tag.

01-420-99686-20101026 1291
Zones Advanced Static routing

1292 01-420-99686-20101026
Dynamic Routing Overview
This section provides an overview of dynamic routing, and how it compares to static
routing. For details on various dynamic routing protocols, see the following chapters for
detailed information.
• What is dynamic routing?
• Comparison of dynamic routing protocols
• Choosing a routing protocol
• Dynamic routing terminology
• IPv6 in dynamic routing
What is dynamic routing?

Dynamic routing uses a dynamic routing protocol to automatically select the best route to
put into the routing table. So instead of manually entering static routes in the routing table,
dynamic routing automatically receives routing updates, and dynamically decides which
routes are best to go into the routing table. Its this intelligent and hands-off approach that
makes dynamic routing so useful.
Dynamic routing protocols vary in many ways and this is reflected in the various
administrative distances assigned to routes learned from dynamic routing. These
variations take into account differences in reliability, speed of convergence, and other
similar factors. For more information on these administrative distances, see “Multipath
routing and determining the best route” on page 1276.
• Comparing static and dynamic routing
• Dynamic routing protocols
• Minimum configuration for dynamic routing
Comparing static and dynamic routing

A common term used to describe dynamic routing is convergence. Convergence is the
ability to work around a network problems and outages — for the routing to come together
despite obstacles. For example if the main router between two end points goes down,
convergence is the ability to find a way around that failed router and reach the destination.
Static routing has zero convergence beyond trying the next route in its limited local routing
table — if a network administrator doesn’t fix a routing problem manually, it will never be
fixed resulting in a downed network. Dynamic routing solves this problem by involving
routers along the route to the destination in decision making about the route, and using the
routing tables of these routes for potential routes around the outage. In general dynamic
routing has better scalability, robustness, and convergence. However, the cost of these
added benefits include more complexity and some overhead — bandwidth that is used by
the routing protocol for its own administration.

01-420-99686-20101026 1293
What is dynamic routing? Dynamic Routing Overview
Table 78: Comparing static and dynamic routing
Feature Static Routing Dynamic Routing

Hardware Supported by all routing hardware May require special, more expensive routers
support
Router Memory Minimal Can require considerable memory for larger
Required tables
Complexity Simple Complex
Overhead None Varying amounts of bandwidth used for
routing protocol updates
Scalability Limited to small networks Very scalable, better for larger networks
Robustness None - if a route fails it has to be Robust - traffic routed around failures
fixed manually automatically
Convergence None Varies from good to execellent
Dynamic routing protocols

A dynamic routing protocol is an agreed on method of routing that the sender, reciever,
and all routers along the path (route) support. Typically the routing protocol involves a
process running on all comptuers and routers along that route to enable each router to
handle routes in the same way as the others. The routing protocol determines how the
routing tables are populated along that route, how the data is formatted for transmission,
and what information about a route is included with that route. For example RIP, and BGP
use distance vector algorithms, where OSPF uses a shortest path first algorithm. Each
routing protocol has different strengths and weaknesses — one protocol may have fast
convergence, while another may be very reliable, and a third is very popular for certain
businesses like Internet Service Providers (ISPs).
Dynamic routing protocols are different from each other in a number of ways, such as:
• Classful versus classless routing protocols
• Interior versus exterior routing protocols
• Distance vector versus link-state protocols
Classful versus classless routing protocols

Classful or classless routing refers to how the routing protocol handes the IP addresses.
In classful addresses there is the specific address, and the host address of the server that
address is connected to. Classless addresses use a combination of IP address and
netmask.
Classless Inter-Domain Routing (CIDR) was introduced in 1993 (originally with RFC 1519
and most recently with RFC 4632) to keep routing tables from getting too large. With
Classful routing, each IP address requires its own entry in the routing table. With
Classless routing, a series of addresses can be combined into one entry potentially saving
vast amounts of space in routing tables.
Current routing protocols that support classless routing out of necessity include RIPv2,
BGP, IS-IS, and OSPF. Older protocols such as RIPv1 do not support CIDR addresses.

1294 01-420-99686-20101026
Dynamic Routing Overview What is dynamic routing?
Interior versus exterior routing protocols

The names interior and exterior are very descriptive. Interior routing protocols are
designed for use within a contained network of limited size, where exterior routing
protocols are designed to link multiple networks together. For example, only border
routers of a network run the exterior routing protocol, where all the routers on the network
run the interior protocol. This overlap is required for the exterior routers to communicate
with the interior routers — border routers almost always run multiple routing protocols.
Nearly all routing protocols are interior routing protocols. Only BGP is commonly used as
an exterior routing protocol.
You may see interior gateway protocol (IGP) used to refer to interior routing protocols, and
exterior gateway protocol (EGP) used to refer to interior routing protocols.
Distance vector versus link-state protocols

Every routing protocol determines the best route between two addresses using a different
method. However, there are two main algorithms for determining the best route —
Distance vector and Link-state.
Distance vector protocols

In distance vector protocols, routers are told about remote networks through neighboring
routers. The distance part refers to the number of hops to the destination, and in more
advanced routing protocols these hops can be weighted by factors such as available
bandwidth and delay. The vector part determines which router is the next step along the
path for this route. This information is passed along from neighboring routers with routing
update packets that keep the routing tables up to date. Using this method, an outage
along a route is reported back along to the start of that route, ideally before the outage is
encountered.
On distance vector protocols, RFC 1058 which defines RIP v1 states the following:
Distance vector algorithms are based on the exchange of only a small amount of
information. Each entity (gateway or host) that participates in the routing protocol is
assumed to keep information about all of the destinations within the system.
Generally, information about all entities connected to one network is summarized by a
single entry, which describes the route to all destinations on that network.
There are four main weaknesses inherent in the distance vector method. Firstly, the
routing information is not discovered by the router itself, but is instead reported information
that must be relied on to be accurate and up-to-date. The second weakness is that it can
take a while for the information to make its way to all the routers who need the information
— in other words it can have slow convergence. The third weakness is the amount of
overhead involved in passing these updates all the time. The number of updates between
routers in a larger network can significantly reduce the available bandwidth. The fourth
weakness is that distance vector protocols can end up with routing-loops. Routing loops
are when packets are routed for ever around a network, and often occur with slow
convergence. The bandwidth required by these infinite loops will slow your network to a
halt. There are methods of preventing these loops however, so this weakness is not as
serious as it may first appear.
Link-state protocols
Link-state protocols are also known as shortest path first protocols. Where distance vector
uses information passed along that may or may not be current and accurate, in link-state
protocols each router passes along only information about networks and devices directly
connected to it. This results in a more accurate picture of the network topology around
your router, allowing it to make better routing decisions. This information is passed

01-420-99686-20101026 1295
Comparison of dynamic routing protocols Dynamic Routing Overview
between routers using link-state advertisements (LSAs). To reduce the overhead, LSAs
are only sent out when information changes, compared to distance vector sending
updates at regular intervals even if no information has changed. The the more accurate
network picture in link-state protocols greatly speed up convergence and avoid problems
such as routing-loops.
Minimum configuration for dynamic routing

Dynamic routing protocols do not pay attention to routing updates from other sources,
unless you specifically configure them to do so using CLI redistribute commands within
each routing protocol.
The minimum configuration for any dynamic routing to function is dynamic routing
configured on one interface the FortiGate unit and one other router configured as well.
Some protocols require more
Table 79: Minimum configuration based on dynamic protocol
BGP RIP OSPF

Interface yes yes yes
Network yes yes yes
AS local and neighbor no yes
Neighbors at least one at least one at least one
Version no yes no
Router ID no no yes
Comparison of dynamic routing protocols

Each dynamic routing protocol was designed to meet a specific routing need. Each
protocol does some things well, and other things not so well. For this reason, choosing the
right dynamic routing protocol for your situation is not an easy task.
Features of dynamic routing protocols

Each protocol is better suited for some situations over others.
Choosing the best dynamic routing protocol depends on the size of your network, speed of
convergence required, the level of network maintenance resources available, what
protocols the networks you connect to are using, and so on. For more information on
these dynamic routing protocols, see “Routing Information Protocol (RIP)” on page 1309,
“Border Gateway Protocol (BGP)” on page 1347, or “Open Shortest Path First (OSPF)” on
page 1385.

1296 01-420-99686-20101026
Dynamic Routing Overview Comparison of dynamic routing protocols
Table 80: Comparing RIP, BGP, and OSPF dynamic routing protocols
Protocol RIP BGP OSPF

Routing Distance Vector, Distance Vector, advanced Link-state
algorithm basic
Common uses Small non-complex Network backbone, ties Common in large, complex
networks multinational offices enterprise networks
together
Strengths Fast and simple to Graceful restart Fast convergence
implement BFD support Robust
Near universal Only needed on border Little management
support routers overhead
Good when no Summarize routes No hop count limitation
redundant paths Scalable
Weakness Frequent updates Required full mesh in large Complex
can flood network networks can cause floods No support for unequal cost
Slow convergence Route flap multipath routing
Maximum 15 hops Load-balance multi-homed Route summary can require
may limit network networks network changes
configuration Not available on low end
routers
Authentication Optional authentication using text string or MD5 password.
(RIP v1 has no authentication)
IPv6 Support Only in RIPng Only in BGP4+ Only in OSPF6
Routing protocols
Routing Information Protocol (RIP) uses classful routing, as well as incorporating
various methods to stop incorrect route information from propagating, such as poisoned
horizon. However, on larger networks its frequent updates can flood the network and its
slow convergence can be a problem.
Border Gateway Protocol (BGP) has been the core Internet backbone routing protocol
since the mid 1990s, and is the most used interior gateway protocol (IGP). However, some
configurations require full mesh connections which flood the network, and there can be
route flap and load balancing issues for multihomed networks.
Open Shortest Path First (OSPF) is commonly used in large enterprise networks. It is
the protocol of choice mainly due to its fast convergence. However, it can be complicated
to setup properly.
Routing algorithm
Each protocol uses a slightly different algorithm for choosing the best route between two
addresses on the network. The algorithm is the “intelligent” part of a dynamic protocol
because the algorithm is responsible for deciding which route is best and should be added
to the local routing table. RIP and BGP use distance vector algorithms, where OSPF uses
link-state or a shortest path first algorithm.
Vector algorithms are essentially based on the number of hops between the originator and
the destination in a route, possibly weighting hops based on how reliable, fast, and error-
free they are.
The link-state algorithm used by OSPF is called the Dijkstra algorithm. Link-state treats
each interface as a link, and records information about the state of the interface. The
Dijkstra algorithm creates trees to find the shortest paths to the routes it needs based on
the total cost of the parts of the routes in the tree.

01-420-99686-20101026 1297
For more information on the routing algorithm used, see “Distance vector versus link-state
protocols” on page 1295.
Authentication
If an attacker gains access to your network, they can masquerade as a router on your
network to either gain information about your network or disrupt network traffic. If you have
a high quality firewall configured, it will help your network security and stop many of this
type of threat. However, the main method for protecting your routing information is to use
authentication in your routing protocol. Using authentication on your FortiGate unit and
other routers prevents access by attackers — all routers must authenticate with
passwords, such as MD5 hash passwords, to ensure they are legitimate routers.
When configuring authentication on your network, ensure you configure it the same on all
devices on the network. Failure to do so will create errors and outages as those forgotten
devices fail to connect to the rest of the network.
For example, to configure an MD5 key of 123 on an OSPF interface called ospf_test,
enter the following CLI command:
config router ospf
edit ospf_test
set authentication md5
set md5-key 123
end
end
Convergence
Convergence is the ability of a networking protocol to re-route around network outages.
Static routing cannot do this. Dynamic routing protocols can all converge, but take various
amounts of time to do this. Slow convergence can cause problems such as network loops
which degrade network performance.
You may also hear robustness and redundancy used to describe networking protocols. In
many ways they are the same thing as convergence. Robustness is the ability to keep
working even though there are problems, including configuration problems as well as
network outages. Redundancy involves having duplicate parts that can continue to
function in the event of some malfunction, error, or outage. It is relatively easy to configure
dynamic routing protocols to have backup routers and configurations that will continue to
function no matter the network problem short of a total network failure.
IPv6 Support
IPv4 addressing is in common use everywhere around the world. IPv6 has much larger
addresses and it is used by many large companies and government departments. IPv6 is
not as common as IPv4 yet, but more companies are adopting it.
If your network uses IPv6, your dynamic routing protocol must support it. None of the
dynamic routing protocols originally supported IPv6, but they all have additions,
expansions, or new versions that do support IPv6. For more information, see “RIP and
IPv6” on page 1310, “BGP and IPv6” on page 1348, or “OSPF and IPv6” on page 1386.

1298 01-420-99686-20101026
When to adopt dynamic routing

Static routing is more than enough to meet your networking needs when you have a small
network. However, as your network grows, the question you need to answer is at what
point do you adopt dynamic routing in your networking plan and start using it in your
network? The main factors in this decision are typically:
• Budget
• Current network size and topology
• Expected network growth
• Available resources for ongoing maintenance
Budget
When making any business decision, the budget must always be considered. Static
routing does not involve special hardware, fancy software, or expensive training courses.
Dynamic routing can include all of these extra expenses. Any new routing hardware such
as routers and switches need to support your chosen protocols. Network management
software to help configure and maintain your more complex network, and routing protocol
drivers may be necessary as well. If the network administrators are not well versed in
dynamic routing, either a training course or some hands on learning time must be
budgeted so they can administer the new network with confidence. Together, these factors
will use up your budget quickly.
Additionally people account for network starting costs in the budgets, but usually leave out
the ongoing cost of network maintenance. Any budget must provide for the hours that will
be spent on updating the network routing equipment, and fixing any problems. Without
that money in the budget, you may end up back at static routing before you know it.
Current network size and topology

As stated earlier static routing works well on small networks. At those networks get larger,
routing takes longer, routing tables get very large, and general performance isn’t what it
could be.
Topology is a concern as well. If all your computers are in one building, its much easier to
stay with static routing longer. However, connecting a number of locations will be easier
with the move to dynamic routing.
If you have a network of 20 computers, you can still likely use static routing. If those
computers are in two or three locations, static routing will still be a good choice for
connecting them. Also, if you just connect to your ISP and don’t worry about any special
routing to do that, you are likely safe with just static routing.
If you have a network of 100 computers in one location, you can use static routing but it
will be getting slower, more complex, and there won’t be much room for expansion. If
those 100 computers are spread across three or more locations, dynamic routing is the
way to go.
If you have 1000 comptuers, you definitely need to use dynamic routing no matter how
many locations you have.
Hopefully this section has given you an idea of what results you will likely experience from
different sized networks using different routing protocols. Your choice of which dynamic
routing protocol to use is partly determined by the network size, and topology.

01-420-99686-20101026 1299
Expected network growth

You may not be sure if your current network is ready for dynamic routing. However, if you
are expecting rapid growth in the near future, it is a good idea to start planning for that
growth now so you are ready for the coming expansion.
Static routing is very labor intensive. Each network device’s routing table needs to be
configured and maintained manually. If there is a large number of new computers being
added to the network, they each need to have the static routing table configured and
maintained. If devices are being moved around the network frequently, they must also be
updated each time.
Instead, consider putting dynamic routing in place before those new computers are
installed on the network. The installation issues can be worked out with a smaller and less
complex network, and when those new computers or routers are added to the network
there will be nowhere near the level of manual configuration required. Depending on the
level of growth, this labor savings can be significant. For example, in an emergency you
can drop a new router into a network or AS wait for it to receive the routing updates from
its neighbors, and then remove one of the neighbors. While the routes will not be the most
effective possible, this method is much less work than static routing in the same situation
with less chance of mistakes.
Also as your network grows and you add more routers, those new routers can help share
the load in most dynamic routing configurations. For example if you have 4 OSPF routers
and 20,000 external routes those few routers will be overwhelmed. But in a network with
15 OSPF routers they will better be able to handle that number of routes. Be aware though
that adding more routers to your network will increase the amount of updates sent
between the routers, which will take up some of your bandwidth.
Available resources for ongoing maintenance

As touched on in the budget section, there must be resources dedicated to ongoing
network maintenance, upgrades, and troubleshooting. These resources include
administrator hours to configure and maintain the network, training for the administrator if
needed, extra hardware and software as needed, and possible extra staff to help the
administrator in emergencies. Without these resources, you will quickly find the network
reverting to static routing out of necessity. This is because:
• Routing software updates will require time.
• Routing hardware updates will require time.
• Office reorganizations or significant personnel movement will require time from a
networking point of view.
• Networking problems that occur, such as failed hardware, require time to locate and fix
the problem.
If the resources to accomplish these tasks are not budgeted, they will either not happen or
not happen at the required level to continue operation. This will result in both the network
administration staff and the network users being very frustrated.
A lack of maintenance budget will also result in increasingly heavy reliance on static
routing as the network administrators are forced to use quick fixes for problems that come
up. This invariably involves going to static routing, and dropping the more complex and
time consuming dynamic routing.

1300 01-420-99686-20101026
Choosing a routing protocol

One of that hardest decisions in routing can be choosing which routing protocol to use on
your network. It can be easy to decide when static routing will not meet your needs, but
how can you tell which dynamic routing protocol is best for your network and situation?
Here is a brief look at the routing protocols including their strongest and weakest points.
The steps to choosing your routing protocol are:
1 Answer questions about your network
2 Dynamic routing terminology
3 Evaluate your chosen protocol
4 Implement your dynamic routing protocol
Answer questions about your network

Before you can decide what is best for your situation, you need to examine what the
details of your situation are such as what you have for budget, equipment, and users.
The following questions will help you form a clear idea of your routing needs:
How many computers or devices are on your network?
It matters if you only have a few computers, or if you have many and if they are all at one
location or not as well. All routing protocols can be run on any sized network, however it
can be inefficient to run some on very small networks. However, routers and network
hardware that support dynamic routing can be more expensive than more generic routers
for static routing.
What applications typically run over the network?
Finding out what application your users are running will help you determine their needs
and the needs of the network regarding bandwidth, quality of service, and other such
issues.
What level of service to the users expect from the network?
Different network users have different expectations of the network. Its not critical for
someone surfing the Internet to have 100% uptime, but it is required for a stock
exchange network or a hospital.
Is there network expansion in your near future?
You may have a small network now, but if it will be growing quickly, you should plan for
the expected size so you don’t have to chance technologies again down the road.
What routing protocols do your networks connect to?
This is most often how routing protocol decisions are made. You need to be able to
communicate easily with your service provider and neighbors, so often people simply
use what everyone else is using.
Is security a major concern?
Some routing protocols have levels of authentication and other security features built
in. Others do not. If security is important to you, be aware of this.
What is your budget — both initial and maintenance?
More robust and feature laden routing protocols generally mean more resources are
required to keep them working well. Also more secure configurations require still more
resources. This includes both set up costs, as well as ongoing maintenance costs.
Ignore these costs at the risk of having to drop the adoption of the new routing protocol
mid-change.

01-420-99686-20101026 1301
Dynamic routing terminology Dynamic Routing Overview
Evaluate your chosen protocol

Once you have examined the features of the routing protocols listed above and chosen
the one that best meets your needs, you can set up an evaluation or test install of that
protocol.
The test install is generally set up in a sandbox configuration so it will not affect critical
network traffic. The aim of the test install is to prove that it will work on a larger scale on
your network. So be sure that the test install mirrors your larger network well enough for
you to discover any problems. If its too simplistic, these problems may not appear.
If your chosen protocol does not meet your goals choose a different protocol and repeat
the evaluation process until either a protocol meets your needs, or you change your
criteria.
Implement your dynamic routing protocol

You have examined your needs, selected the best matching dynamic routing protocol,
tested it, and now you are ready to implement it with confidence.
This guide will help you configure your FortiGate unit to support your chosen dynamic
routing protocol. Refer to the various sections in this guide as needed during your
implementation to help ensure a smooth transition. Examples for each protocol have been
included to show proper configurations for different types of networks.
Dynamic routing terminology

Dynamic routing is a complex subject. There are many routers on different networks and
all can be configured differently. It become even more complicated when you add to this
each routing protocol having slightly different names for similar features, and many
configurable features for each protocol.
To better understand dynamic routing, here are some explanations of common dynamic
routing terms.
• Aggregated routes and addresses
• Autonomous system (AS)
• Area border router (ABR)
• Neighbor routers
• Route maps
• Access lists
• Bi-directional forwarding detection (BFD)
For more details on a term as it applies to a dynamic routing protocol, see one of “Border
Gateway Protocol (BGP)” on page 1347, “Routing Information Protocol (RIP)” on
page 1309, or “Open Shortest Path First (OSPF)” on page 1385.
Aggregated routes and addresses

Just as an aggregate interface combines multiple interfaces into one virtual interface, an
aggregate route combines multiple routes into one. This reduces the amount of space
those routes require in the routing tables of the routers along that route. The trade-off is a
small amount of processing to aggregate and de-aggregate the routes at either end.

1302 01-420-99686-20101026
Dynamic Routing Overview Dynamic routing terminology
The benefit of this method is that you can combine many addresses into one, potentially
reducing the routing table size immensely. The weakness of this method is if there are
holes in the address range you are aggregating you need to decide if its better to break it
into multiple ranges, or accept the possibility of failed routes to the missing addresses.
To manually aggregate the range of IP addresses from 192.168.1.100 to

192.168.1.103
1 Convert the addresses to binary
192.168.1.100 = 11000000 10101000 00000001 01100100
192.168.1.101 = 11000000 10101000 00000001 01100101
192.168.1.102 = 11000000 10101000 00000001 01100110
192.168.1.103 = 11000000 10101000 00000001 01100111
2 Determine the maximum number of matching bits common to the addresses.
There are 30-bits in common, with only the last 2-bits being different.
3 Record the common part of the address.
11000000 10101000 00000001 0110010X = 192.168.1.100
4 For the netmask, assume all the bits in the netmask are 1 except those that are
different which are 0.
11111111 11111111 11111111 11111100 = 255.255.255.252
5 Combine the common address bits and the netmask.
192.168.1.100/255.255.255.252
Alternately the IP mask may be written as a single number:
192.168.1.100/2
6 As required, set variables and attributes to declare the routes have been aggregated,
and what router did the aggregating.
Autonomous system (AS)

An Autonomous System (AS) is one or more connected networks that use the same
routing protocol, and appear to be a single unit to any externally connected networks. For
example an ISP may have a number of customer networks connected to it, but to any
networks connected externally to the ISP it appears as one system or AS. An AS may also
be referred to as a routing domain.
It should be noted that while OSPF routing takes place within one AS, the only part of
OSPF that deals with the AS is the AS border router (ASBR).
There are multiple types of AS defined by how they are connected to other ASes. A
multihomed AS is connected to at least two other ASes and has the benefit of redundancy
— if one of those ASes goes down, your AS can still reach the Internet through its other
connection. A stub AS only has one connection, and can be useful in specific
configurations where limited access is desirable.
Each AS has a number assigned to it, known as an ASN. In an internal network, you can
assign any ASN you like (a private AS number), but for networks connected to the Internet
(public AS) you need to have an officially registered ASN from Internet Assigned Numbers
Authority (IANA). ASNs are typically 16-bit numbers — ASNs from 1 - 64,511 are
designated for public use.

01-420-99686-20101026 1303
Note: As of January 2010, AS numbers will be 4-bytes long instead of the older 2-bytes.
RFC 4893 introduced 32-bit ASNs, which FortiGate units support.
Do you need your own AS?

The main factors in deciding if you need your own AS or if you should be part of someone
else’s are:
• exchanging external routing information
• many prefixes should exist in one AS as long as they use the same routing policy
• when you use a different routing protocol than your border gateway peers (for example
your ISP uses BGP, and you use OSPF)
• connected to multiple other AS (multi-homed)
You should not create an AS for each prefix on your network. Neither should you be forced
into an AS just so someone else can make AS-based policy decisions on your traffic.
There can be only one AS for any prefix on the Internet. This is to prevent routing issues.
What AS number to use?

In addition to overseeing IP address allocation and Domain Name Systems (DNS), the
Internet Assigned Numbers Authority (IANA) assigns public AS numbers. The public AS
numbers are from 1 to 64,511. The ASNs 0, 54272–64511, and 65535 are reserved by the
IANA. These ASNs should not be used.
ASNs are assigned in blocks by the Internet Assigned Numbers Authority (IANA) to
Regional Internet Registries (RIRs) who then assign ASNs to companies within that RIRs
geographic area. Usually these companies are ISPs, and to receive an ASN you must
complete the application process of the local RIR and be approved before being assigned
an ASN. The RIRs names and regions are:
AFRINIC Serves the African continent

APNIC Asia-Pacific including China, India, and Japan
ARIN American registry including Canada and United States
LACNIC Latin America, including Mexico, Caribbean, Central and South
America
RIPE NCC Europe, the Middle East, former USSR, and parts of Central Asia
AS numbers from 64512 to 65534 are reserved for private use. Private AS numbers can
be used for any internal networks with no outside connections to the Internet such as test
networks, classroom labs, or other internal-only networks that do not access the outside
world. You can also configure border routers to filter out any private ASNs before routing
traffic to the outside world. If you must use private ASNs with public networks, this is the
only way to configure them. However, it is risky because many other private networks
could be using the same ASNs and conflicts will happen. It would be very much like your
local 192.168.0.0 network being made public — the resulting problems would be
widespread.
In 1996, when RFC 1930 was written only 5,100 ASes had been allocated and a little
under 600 ASes were actively routed in the global Internet. Since that time many more
public ASNs have been assigned, leaving only a small number. For this reason 32-bit
ASNs (four-octet ASNs) were defined to provide more public ASNs. RFC 4893 defines 32-
bit ASNs, and FortiGate units support these larger ASNs as of FortiOS version 4.2

1304 01-420-99686-20101026
Dynamic Routing Overview Dynamic routing terminology
Area border router (ABR)

Routers within an AS advertise updates internally and only to each other. However,
routers on the edge of the AS must communicate both with routers inside their AS and
with routers external to their AS, often running a different routing protocol. These routers
are called Area Border Routers (ABRs) or edge routers. Often ABRs run multiple routing
protocols to be able to redistribute traffic between different ASes that are running different
protocols, such as the edge between an ISP’s IS-IS routing network and an large
company’s OSPF network.
OSPF defines ABRs differently from other routers. In OSPF, an ABR is an OSPF router
that connects another AS to the backbone AS, and is a member of all the areas it
connects to. An OSPF ABR maintains a LSA database for each area that it is connected
to. The concept of the edge router is present, but its the edge of the backbone instead of
the edge of the OSPF supported ASes.
Neighbor routers
Routing involves routers communicating with each other. To do this, routers need to know
information about each other. These routers are called neighbor routers, and are
configured in each routing protocol. Each neighbor has custom settings since some
routers may have functionality others routers lack. Neighbour routers are sometimes
called peers.
Generally neighbor routers must be configured, and discovered by the rest of the network
before they can be integrated to the routing calculations. This is a combination of the
network administrator configuring the new router with its neighbor router addresses, and
the routing network discovering the new router, such as the hello packets in OSPF. That
discovery initiates communication between the new router and the rest of the network.
Route maps
Route maps are a way for the FortiGate unit to evaluate optimum routes for forwarding
packets or suppressing the routing of packets to particular destinations. Compared to
access lists, route maps support enhanced packet-matching criteria. In addition, route
maps can be configured to permit or deny the addition of routes to the FortiGate unit
routing table and make changes to routing information dynamically as defined through
route-map rules.
Route maps can be used for limiting both received route updates, and sent route updates.
This can include the redistribution of routes learned from other types of routing. For
example if you don’t want to advertise local static routes to external networks, you could
use a route map to accomplish this.
The FortiGate unit compares the rules in a route map to the attributes of a route. The rules
are examined in ascending order until one or more of the rules in the route map are found
to match one or more of the route attributes.
As an administrator, route maps allow you to group a set of addresses together and assign
them a meaningful name. Then during your configuration, you can use these route-maps
to speed up configuration. The meaningful names ensure fewer mistakes during
configuration as well.
The default rule in the route map (which the FortiGate unit applies last) denies all routes.
For a route map to take effect, it must be called by a FortiGate unit routing process.

01-420-99686-20101026 1305
The syntax for route maps are:

config router route-map
edit <route_map_name>
set comments
config rule
edit <route_map_rule_id>
set action
set match-*
set set-*
The match-* commands allow you to match various parts of a route. The set-*
commands allow you to set routing information once a route is matched.
For an example of how route maps can be used to create receiving or sending “groups” in
routing, see “Redistributing and blocking routes in BGP” on page 1378.
Access lists
Use this command to add, edit, or delete access lists. Access lists are filters used by
FortiGate unit routing processes. For an access list to take effect, it must be called by a
FortiGate unit routing process (for example, a process that supports RIP or OSPF). Use
access-list6 for IPv6 routing.
Access lists can be used to filter which updates are passed between routers, or which
routes are redistributed to different networks and routing protocols. You can create lists of
rules that will match all routes for a specific router or group of routers.
Each rule in an access list consists of a prefix (IP address and netmask), the action to take
for this prefix (permit or deny), and whether to match the prefix exactly or to match the
prefix and any more specific prefix.
Note: If you are setting a prefix of 128.0.0.0, use the format 128.0.0.0/1. The default route,
0.0.0.0/0 can not be exactly matched with an access-list. A prefix-list must be used for this
purpose.
The FortiGate unit attempts to match a packet against the rules in an access list starting at
the top of the list. If it finds a match for the prefix, it takes the action specified for that
prefix. If no match is found the default action is deny.
The syntax for access lists is:
config router access-list, access-list6
edit <access_list_name>
set comments
config rule
edit <access_list_id>
set action
set exact-match
set prefix
set prefix6
set wildcard
For an example of how access lists can be used to create receiving or sending “groups” in
routing, see “Redistributing and blocking routes in BGP” on page 1378.
Bi-directional forwarding detection (BFD)

Bi-directional Forwarding Detection (BFD) is a protocol used to quickly locate hardware
failures in the network. Routers running BFD communicate with each other, and if a timer
runs out on a connection then that router is declared down. BFD then communicates this
information to the routing protocol and the routing information is updated.

1306 01-420-99686-20101026
Dynamic Routing Overview IPv6 in dynamic routing
The CLI commands associated with BFD include:

config router bgp
config neighbor
set bfd
config router ospf

set bfd
config system setting

set bfd
set bfd-desired-min-tx
set bfd-required-min-rx
set bfd-detect-mult
set bfd-dont-enforce-src-port
For more information about BFD in BGP, see “Bi-directional forwarding detection (BFD)”
on page 1363.
IPv6 in dynamic routing

Unless otherwise stated, routing protocols apply to IPv4 addressing. This is the standard
address format used. However, IPv6 is becoming popular and new versions of the
dynamic routing protocols have been introduced.
As of FortiOS v4.1, dynamic routing supports IPv6 on your FortiGate unit. The new
versions of these protocols and the corresponding RFCs are:
• BGP4+ — RFC 2545, and RFC 2858 Multiprotocol Extensions for IPv6 Inter-Domain
Routing, and Multiprotocol Extensions for BGP-4 (MP-BGP) respectively. See “BGP
and IPv6” on page 1348
• RIP next generation (RIPng) — RFC 2080 - Routing Information Protocol next generation
(RIPng). See “RIP and IPv6” on page 1310.
• OSPFv3 — RFC 2740 Open Shortest Path First version 3 (OSPFv3) for IPv6 support.
See “OSPF and IPv6” on page 1386.
As with most advanced routing features on your Fortigate unit, IPv6 settings for dynamic
routing protocols are CLI-only. To configure IPv6 for RIP, BGP, or OSPF protocols you
must use the CLI commands.

01-420-99686-20101026 1307
IPv6 in dynamic routing Dynamic Routing Overview

1308 01-420-99686-20101026
Routing Information Protocol (RIP)
This section describes the Routing Information Protocol (RIP).
• RIP background and concepts
• Troubleshooting RIP
• RIP routing examples
RIP background and concepts

This section contains:
• Background
• Parts and terminology of RIP
• How RIP works
Background
Routing Information Protocol (RIP) is a distance-vector routing protocol intended for small,
relatively homogeneous networks. Its widespread use started when an early version of
RIP was included with BSD v4.3 Linux as the routed daemon. The routing algorithm used
by RIP, the Bellman–Ford algorithm, first saw widespread use as the initial routing
algorithm of the ARPANET.
RIP benefits include being well suited to smaller networks, is in widespread use, near
universal support on routing hardware, quick to configure, and works well if there are no
redundant paths. However, RIP updates are sent out node-by-node so it can be slow to
find a path around network outages. RIP also lacks good authentication, can not choose
routes based on different quality of service methods, and can create network loops if you
are not careful.
The FortiGate implementation of RIP supports RIP version 1 (see RFC 1058), RIP version
2 (see RFC 2453), and the IPv6 version RIPng (see RFC 2080).
RIP v1
In 1988 RIP version 1, defined in RFC 1058, was released. The RFC even states that RIP
v1 is based on Linux routed due to it being a “defacto standard”.
It uses classful addressing and uses broadcasting to send out updates to router
neighbors. There is no subnet information included in the routing updates in classful
routing, and it does not support CIDR addressing — subnets must all be the same size.
Also, route summarization is not possible.
RIP v1 has no router authentication method, so it is vulnerable to attacks through packet
sniffing, and spoofing.
RIP v2
In 1993, RIP version 2 was developed to deal with the limitations of RIP v1. It was not
standardized until 1998. This new version supports classless routing, and subnets of
various sizes.

01-420-99686-20101026 1309
RIP background and concepts Routing Information Protocol (RIP)
Router authentication was added in RIP v2 — it supports MD5. MD5 hashes are an older
encryption method, but this is much improved over no security at all.
In RIP v2 the hop count remained at 15 to be backwards compatible with RIP v1.
RIP v2 uses multicasting to send the entire routing table to router neighbors, thereby
reducing the traffic for devices that are not participating in RIP routing.
Routing tags were added as well, which allow internal routes or redistributed routes to be
identified as such.
RIPng
RIPng, defined in RFC 2080, is an extension of RIP2 designed to support IPv6. However,
RIPng varies from RIPv2 in that it is not fully backwards compatible with RIPv1.
• RIPng does not support RIPv1 update authentication (it relies on IPsec)
• RIPng does not allow attaching tags to routes as in RIPv2
• RIPng requires specific encoding of the next hop for a set of route entries, unlike RIPv2
that encodes the next-hop into each route entry .
Parts and terminology of RIP

Before you can understand how RIP functions, you need to understand some of the main
concepts and parts of RIP.
• RIP and IPv6
• Default information originate option
• Garbage, timeout, and update timers
• Authentication and key-chain
• Access Lists
RIP and IPv6

RIP Next Generation (RIPng) is a new version of RIP was released that includes support
for IPv6.
The FortiGate unit command config router ripng is almost the same as config
router rip, except that IPv6 addresses are used. Also if you are going to use prefix or
access lists with RIPng, you must use the config router access-list6 or config
prefix-list6 versions of those commands.
If you want to troubleshoot RIPng, it is the same as with RIP but specify the different
protocol, and use IPv6 addresses. This applies to commands such as get router
info6 when you want to see the routing table, or other related information.
If you want to route IPv4 traffic over an IPv6 network, you can use the command config
system ip6-tunnel to configure the FortiGate unit to do this. The IPv6 interface is
configured under config system interface. All subnets between the source and
destination addresses must support IPv6. This command is not supported in Transparent
mode.

1310 01-420-99686-20101026
Routing Information Protocol (RIP) RIP background and concepts
For example, you want to set up a tunnel on the port1 interface starting at
2002:C0A8:3201:: on your local network and tunnel it to address 2002:A0A:A01:: where it
will need access to an IPv4 network again. Use the following command:
config system ipv6-tunnel
edit test_tunnel
set destination 2002:A0A:A01::
set interface port1
set source 2002:C0A8:3201::
end
end
The CLI commands associated with RIPng include:

config router ripng
config router access-list6
config router prefix-list6
config system ipv6-tunnel
get router info6 *
Default information originate option

This is the second advanced option for RIP in the web-based manager, right after metric.
Enabling default-information-originate will generate and advertise a default route into the
FortiGate unit’s RIP-enabled networks. The generated route may be based on routes
learned through a dynamic routing protocol, routes in the routing table, or both. RIP does
not create the default route unless you use the always option.
Select Disable if you experience any issues or if you wish to advertise your own static
routes into RIP updates.
The CLI commands associated with default information originate include:
config router rip
set default-information-originate
end
Garbage, timeout, and update timers

RIP uses various timers to regulate its performance including a garbage timer, timeout
timer, and update timer. The FortiGate unit default timer settings (30, 180, and 120
seconds respectively) are effective in most configurations — if you change these settings,
ensure that the new settings are compatible with local routers and access servers.
Note: The Timeout period should be at least three times longer than the Update period. If
the Update timer is smaller than Timeout or Garbage timers, you will experience an error.
The CLI commands associated with garbage, timeout, and update timers include:
config router rip
set garbage-timer
set timeout-timer
set update-timer
end

01-420-99686-20101026 1311
Garbage timer
The garbage timer is the amount of time (in seconds) that the FortiGate unit will advertise
a route as being unreachable before deleting the route from the routing table. If this timer
is shorter, it will keep more up to date routes in the routing table and remove old ones
faster. This will result in a smaller routing table which is useful if you have a very large
network, or if your network changes frequently.
Update timer
The update timer determines the interval between routing updates. Generally, this value is
set to 30 seconds. There is some randomness added to help prevent network traffic
congestion, which could result from all routers simultaneously attempting to update their
neighbors. The update timer should be at least three times smaller than the timeout timer,
otherwise you will experience an error.
If you are experiencing significant RIP traffic on your network, you can increase this
interval to send fewer updates per minute. However, ensure you increase the interval for
all the routers on your network or you will experience time outs that will degrade your
network speed.
Timeout timer
The timeout timer is the maximum amount of time (in seconds) that a route is considered
reachable while no updates are received for the route. This is the maximum time the
FortiGate unit will keep a reachable route in the routing table while no updates for that
route are received. If the FortiGate unit receives an update for the route before the timeout
period expires, the timer is restarted. The timeout period should be at least three times
longer than the depute period, otherwise you will experience an error.
If you are experiencing problems with routers not responding in time to updates, increase
this timer. However, remember that longer timeout intervals result in longer overall update
periods — it may be considerable time before the time the FortiGate unit is done waiting
for all the timers to expire on unresponsive routes.
Authentication and key-chain

RIP version 2 uses authentication keys to ensure that the routing information exchanged
between routers is reliable. RIP version 1 has no authentication. For authentication to
work both the sending and receiving routers must be set to use authentication, and must
be configured with the same keys.
The sending and receiving routers need to have their system dates and times
synchronized to ensure both ends are using the same keys at the proper times. However,
you can overlap the key lifetimes to ensure that a key is always available even if there is
some difference in the system times.
A key chain is a list of one or more authentication keys including the send and receive
lifetimes for each key. Keys are used for authenticating routing packets only during the
specified lifetimes. The FortiGate unit migrates from one key to the next according to the
scheduled send and receive lifetimes.
Key-chain is a CLI router command. You use this command to manage RIP version 2
authentication keys. You can add, edit or delete keys identified by the specified key
number.

1312 01-420-99686-20101026
This example shows how to configure a key-chain with two keys that are valid sequentially
in time. This example creates a key-chain called “rip_key” that has a password of
“fortinet”. The accepted and send lifetimes are both set to the same values — a start time
of 9:00am February 23, 2010 and an end time of 9:00am March 17, 2010. A second key is
configured with a password of “my_fortigate” that is valid from March 17, 2010 9:01am to
April 1 2010 9:00am. This “rip_key” keychain is then used on the port1 interface in RIP.
config router key-chain
edit "rip_key"
config key
edit 1
set accept-lifetime 09:00:00 23 02 2010 09:00:00 17 03 2010
set key-string "fortinet"
set send-lifetime 09:00:00 23 02 2010 09:00:00 17 03 2010
next
edit 2
set accept-lifetime 09:01:00 17 03 2010 09:00:00 1 04 2010
set key-string "my_fortigate"
set send-lifetime 09:01:00 17 03 2010 09:00:00 1 04 2010
next
end
end
config router rip
config interface
edit port1
set auth-keychain “rip_key”
end
end
The CLI commands associated with authentication keys include:

config router key-chain
config router rip

config interface
edit <interface>
set auth-keychain
set auth-mode
set auth-string
end
end
Access Lists
Access lists are filters used by FortiGate unit RIP and OSPF routing. An access list
provides a list of IP addresses and the action to take for them — essentially an access list
makes it easy to group addresses that will be treated the same into the same group,
independent of their subnets or other matching qualities. You add a rule for each address
or subnet that you want to include, specifying the action to take for it. For example if you
wanted all traffic from one department to be routed a particular way, even in different
buildings, you can add all the addresses to an access list and then handle that list all at
once.
Each rule in an access list consists of a prefix (IP address and netmask), the action to take
for this prefix (permit or deny), and whether to match the prefix exactly or to match the
prefix and any more specific prefix.

01-420-99686-20101026 1313
The FortiGate unit attempts to match a packet against the rules in an access list starting at
the top of the list. If it finds a match for the prefix, it takes the action specified for that
prefix. If no match is found the default action is deny.
Access lists greatly speed up configuration and network management. When there is a
problem, you can check each list instead of individual addresses. Also its easier to
troubleshoot since if all addresses on one list have problems, it eliminates many possible
causes right away.
If you are using the RIPng or OSPF+ IPv6 protocols you will need to use access-list6, the
IPv6 version of access list. The only difference is that access-list6 uses IPv6 addresses.
For example, if you want to create an access list called test_list that only allows an
exact match of 10.10.10.10 and 11.11.11.11, enter the command:
config access-list
edit test_list
config rule
edit 1
set prefix 10.10.10.10 255.255.255.255
set action allow
next
edit 2
set prefix 11.11.11.11 255.255.255.255
set action allow
end
end
Another example is if you want to deny ranges of addresses in IPv6 that start with the IPv6
equivalents of 10.10.10.10 and 11.11.11.11, enter the command access-list6 as follows:
config router access-list6
edit test_list_ip6
config rule
edit 1
set prefix6 2002:A0A:A0A:0:0:0:0:0:/48
set action deny
next
edit 2
set prefix6 2002:B0B:B0B:0:0:0:0:0/48
set action deny
end
end

1314 01-420-99686-20101026
To use an access_list, you must call it from a routing protocol such as RIP. The following
example uses the access_list from the earlier example called test_list to match routes
coming in on the port1 interface. When there is a match, it will add 3 to the hop count
metric for those routes to artificially increase . Enter the following command:
config router rip
config offset-list
edit 5
set access-list test_list
set direction in
set interface port1
set offset 3
set status enable
end
end
If you are setting a prefix of 128.0.0.0, use the format 128.0.0.0/1. The default route,
0.0.0.0/0 can not be exactly matched with an access-list. A prefix-list must be used for this
purpose
How RIP works

As one of the original modern dynamic routing protocols, RIP is straight forward. It’s
routing algorithm is not complex, there are some options to allow fine tuning, and its
straight forward to configure RIP on FortiGate units.
From RFC 1058:
Distance vector algorithms are based on the exchange of only a small amount of
information. Each entity (gateway or host) that participates in the routing protocol is
assumed to keep information about all of the destinations within the system.
Generally, information about all entities connected to one network is summarized by a
single entry, which describes the route to all destinations on that network.
• RIP versus static routing
• RIP metric — hop count
• The Bellman–Ford routing algorithm
• Passive versus active RIP interfaces
• RIP packet structure
RIP versus static routing

RIP was one of the earliest dynamic routing protocols to work with IP addresses. As such,
it is not as complex as more recent protocols. However, RIP is a big step forward from
simple static routing.
While RIP may be slow in response to network outages, static routing has zero response.
The same is true for convergence — static routing has zero convergence. Both RIP and
static routing have the limited hop count, so its not a strength or a weakness. Count to
infinity can be a problem, but typically can be fixed as it happens or is the result of a
network outage that would cause even worse problems on static routing network.
Overall, RIP is a large step forward when compared to static routing.

01-420-99686-20101026 1315
RIP metric — hop count

RIP uses hop count as the metric for choosing the best route. A hop count of 1 represents
a network that is connected directly to the FortiGate unit, while a hop count of 16
represents a network that cannot be reached. Each network that a packet travels through
to reach its destination usually counts as one hop. When the FortiGate unit compares two
routes to the same destination, it adds the route having the lowest hop count to the routing
table. As you can see in “RIP packet structure” on page 1319, the hop count is part of a
RIP v2 packet making it very important.
Similarly, when RIP is enabled on an interface, the FortiGate unit sends RIP responses to
neighboring routers on a regular basis. The updates provide information about the routes
in the FortiGate unit’s routing table, subject to the rules that you specify for advertising
those routes. You can specify how often the FortiGate unit sends updates, the period of
time a route can be kept in the routing table without being updated, and for routes that are
not updated regularly you can specify the period of time that the unit advertises a route as
unreachable before it is removed from the routing table.
If hops are weighted higher than one, it becomes very easy to reach the upper limit. This
higher weighting will effectively limit the size of your network depending on the numbers
used. Merely changing from the default of 1.0 to 1.5 will lower the effective hop count from
15 to 10. This is acceptable for smaller networks, but can be a problem as your network
expands over time.
In RIP, you can use the offset command to artificially increase the hop count of a route.
Doing this will make this route less preferred, and in turn it will get less traffic. Offsetting
routes is useful when you have network connections of different bandwidths, different
levels of reliability, or different costs. In each of these situations you still want the
redundancy of multiple route access, but you don’t want the bulk of your traffic using these
less preferred routes. For an example of RIP offset, see “Access Lists” on page 1313.
The Bellman–Ford routing algorithm

The routing algorithm used by RIP was first used in 1967 as the initial routing algorithm of
the ARPANET. The Bellman–Ford algorithm is distributed because it involves a number of
nodes (routers) within an Autonomous system, and consists of the following steps:
1 Each node calculates the distances between itself and all other nodes within the AS
and stores this information as a table.
2 Each node sends its table to all neighboring nodes.
3 When a node receives distance tables from its neighbors, it calculates the shortest
routes to all other nodes and updates its own table to reflect any changes.
To examine how this algorithm functions let’s look at a network with 4 routers — routers 1
through 4. The distance from router1 to router2 is 2 hops, 1 to 3 is 3 hops, and 2 to 3 is 4
hops. Router4 is only connected to routers 2 and 3, each distance being 2 hops.
1 Router1 finds all the distance to the other three routers — router 2 is 2, router 3 is 3.
Router1 doesn’t have a route to router 4.
2 Routers 2 through 4 do the same calculations from their point of views.
3 Once router 1 gets an update from router 2 or 3, it will get their route to router 4. At that
point it now has a route to router 4 and installs that in its local table.
4 If router1 gets an update from router3 first, it has a hop count of 5 to reach router4. But
when router2 sends its update, router1 will go with router2’s shorter 4 hops to reach
router4. Future updates don’t change this unless they are shorter than 4 hops, or the
routing table route goes down.

1316 01-420-99686-20101026
Figure 174: RIP algorithm example in 4 steps
Router4
Step 1. Router1 finds the distance

to other routers. It has no route to router4.
hop count = 2 hop count = 2
Router1 table: Router2

Router3
Distance to route2= 2 hops
Distance to router3 = 3 hops hop count = 2
hop count = 3
Router1
Router4
Step 2. All routers do the same as

router1, and send out updates with hop count = 2 hop count = 2
the table of routes.
Note that router1 and router4 do Router2 Router3
not update each other, but rely on

router2 and router3 to pass along hop count = 2
deputes. hop count = 3
Router1
Router4
Step 3. Each router looks at the

updates it receives, and adds any
new or shorter routes to its table.
Router3
Router2
hop count = 4
Router1 updated table:
Distance to router2 = 2 hops
Distance to router4 = 5 hops Router1
Router4
Step 4. The shortest route to router4

is installed, and the other routes to
router4 are removed from the table.
Router3
Router2
hop count = 4
Router1 updated table:
Router1

01-420-99686-20101026 1317
The good part about the Bellman-Ford algorithm in RIP is that the router only uses the
information it needs from the update. If there are no newer, better routes than the ones the
router already has in its routing table, there is no need to change its routing table. And no
change means no additional update, so less traffic. But even when there is update traffic,
the RIP packets are very small so it takes many updates to affect overall network
bandwidth. For more information about RIP packets, see “RIP packet structure” on
page 1319.
The main disadvantage of the Bellman–Ford algorithm in RIP is that it doesn’t take
weightings into consideration. While it is possible to assign different weights to routes in
RIP, doing so severely limits the effective network size by reducing the hop count limit.
Also other dynamic routing protocols can take route qualities, such as reliability or delay,
into consideration to provide not only the physically shortest but also the fastest or more
reliable routes as you choose.
Another disadvantage of the Bellman-Ford algorithm is due to the slow updates passed
from one RIP router to the next. This results in a slow response to changes in the network
topology, which in turn results in more attempts to use routes that are down which wastes
time and network resources.
Passive versus active RIP interfaces

Normally the FortiGate unit’s routing table is kept up to date by periodically asking the
neighbors for routes, and sending your routing updates out . This has the downside of
generating a lot of extra traffic for large networks. The solution to this problem is passive
interfaces.
An standard interface that supports RIP is active by default — it both sends and receives
updates by actively communicating with its neighbors. A passive RIP interface does not
send out updates — it just listens to the updates of other routers. This is useful in reducing
network traffic, and if there are redundant routers in the network that would be sending out
essentially the same updates all the time.
The following example shows how to create a passive RIP v2 interface on port1, using
MD5 authentication and a key-chain called passiveRIPv2 that has already been
configured. Note that in the CLI, you enable passive by disabling send-version2-
broadcast.
To create a passive RIP interface - web-based manager

1 Go to Router > Dynamic Routing > RIP.
2 Under Interfaces, select Create New.
3 Select port1 as the Interface.
4 Select 2 as both the Send Version and Receive Version.
5 Select MD5 for Authentication.
6 Select the passiveRIPv2 Key-chain.
7 Select Passive Interface.
8 Select OK to accept this configuration, and return to the main RIP display page.

1318 01-420-99686-20101026
To create a passive RIP v2 interface on port1 using MD5 authentication- CLI

config router rip
config interface
edit port1
set send-version2-broadcast disable
set auth-keychain “passiveRIPv2”
set auth-mode md5
set receive-version 2
set send-version 2
end
end
The CLI commands associated with RIPng include:

config router rip
config interface
edit <interface>
set send-version2-broadcast disable
RIP packet structure

It is hard to fully understand a routing protocol without knowing what information is carried
in its packets. Knowing what information is exchanged between routers and how will help
you better understand the RIP protocol, and better configure your network for it.
This section provides information on the contents of RIP 1 and RIP 2 packets.
RIP version 1
RIP version 1, or RIP IP packets are 24 bytes in length. The empty areas were left for
future expansion.
Table 81: RIP IP packets
1-byte command 1-byte version 2-byte zero field 2-byte AFI 2-byte zero field
4-byte IP address 4-byte zero field 4-byte zero field 4-byte metric
The following descriptions summarize the RIP version 1 packet fields.

Command — Indicates whether the packet is a request or a response. The request asks
that a router send all or part of its routing table. The response can be an unsolicited
regular routing update or a reply to a request. Responses contain routing table entries.
Multiple RIP packets are used to convey information from large routing tables.
Version — Specifies the RIP version used. This field can signal different potentially
incompatible versions.
Zero field — This field defaults to zero, and is not used by RFC 1058 RIP.
Address-family identifier (AFI) — Specifies the address family used. RIP is designed to
carry routing information for several different protocols. Each entry has an address-family
identifier to indicate the type of address being specified. The AFI for IP is 2.
IP Address — Specifies the IP address for the entry.
Metric — This is the number of hops or routers traversed along the route on its trip to the
destination. The metric is between 1 and 15 for that number of hops. If the route is
unreachable the metric is 16.

01-420-99686-20101026 1319
Troubleshooting RIP Routing Information Protocol (RIP)
RIP version 2
RIP version 2 has more features that RIP 1 and this is reflected in its packets. RIP 2
packets are similar in format to RIP 1, but carry more information. All but one of the empty
zero fields in RIP 1 packets now contain information.
Table 82: RIP 2 packets
1-byte 1-byte 2-byte 2-byte 2-byte 4-byte IP 4-byte 4-byte 4-byte

command version unused AFI route tag address subnet next hop metric
The following descriptions summarize the fields RIP 2 adds to the RIP IP header. The
other fields have been described above for RIP 1.
Unused — Has a value set to zero, and is intended for future use
Route tag — Provides a method for distinguishing between internal routes learned by RIP
and external routes learned from other protocols.
Subnet mask — Contains the subnet mask for the entry. If this field is zero, no subnet
mask has been specified for the entry.
Next hop — Indicates the IP address of the next hop to which packets for the entry should
be forwarded.
Troubleshooting RIP
This section is about troubleshooting RIP. For general troubleshooting information, see “”
on page 1307.
• Routing Loops
• Split horizon and Poison reverse updates
• Debugging IPv6 on RIPng
Routing Loops
Normally in routing, a path between two addresses is chosen and traffic is routed along
that path from one address to the other. When there is a routing loop, that normal path
doubles back on itself creating a loop. When there are loops, the network has problems.
A routing loop happens when a normally functioning network has an outage, and one or
more routers are offline. When packets encounter this, an alternate route is attempted to
maneuver around the outage. During this phase it is possible for a route to be attempted
that involves going back a hop, and trying a different hop forward. If that hop forward is
blocked by the outage as well, a hop back and possibly the original hop forward may be
selected. You can see if this continues, how it can consume not only network bandwidth
but also many resources on those routers affected. The worst part is this situation will
continue until the network administrator changes the router settings, or the downed
routers come back online.
Routing loops’ effect on the network

In addition to this “traffic jam” of routed packets, every time the routing table for a router
changes that router sends an update out to all of the RIP routers connected to it. In a
network loop, its possible for a router to change its routes very quickly as it tries and fails
along these new routes. This can quickly result in a flood of updates being sent out, which
can effectively grind the network to a halt until the problem is fixed.

1320 01-420-99686-20101026
Routing Information Protocol (RIP) Troubleshooting RIP
How can you spot a routing loop

Any time network traffic slows down, you will be asking yourself if it is a network loop or
not. Often slowdowns are normal, they are not a full stoppage, and normal traffic resumes
in a short period of time.
If the slow down is a full halt of traffic or a major slowdown does not return to normal
quickly, you need to do serious troubleshooting quickly.
Some methods to troubleshoot your outage include:
• Check your logs
• Use SNMP network monitoring
• Use dead gateway detection and e-mail alerts
• Look at the packet flow
If you aren’t running SNMP, dead gateway detection, or you have non-Fortinet routers in
your network, you can use networking tools such as ping and traceroute to define the
outage on your network and begin to fix it. Ping, traceroute, and other basic
troubleshooting tools are covered in “” on page 1307.
Check your logs

If your routers log events to a central location, it can be easy to check the logs for your
network for any outages.
On your FortiGate unit, go to Log & Report > Log Access. You will want to look at both
event logs and traffic logs. Events to look for will generally fall under CPU and memory
usage, interfaces going offline (due to dead gateway detection), and other similar system
events.
Once you have found and fixed your network problem, you can go back to the logs and
create a report to better see how things developed during the problem. This type of
forensics analysis can better help you prepare for next time.
Use SNMP network monitoring

If your network had no problems one minute and slows to a halt the next, chances are
something changed to cause that problem. Most of the time an offline router is the cause,
and once you find that router and bring it back online, things will return to normal.
If you can enable a hardware monitoring system such as SNMP or sFlow on your routers,
you can be notified of the outage and where it is exactly as soon as it happens.
Ideally you can configure SNMP on all your FortiGate routers and be alerted to all outages
as they occur.

01-420-99686-20101026 1321
Troubleshooting RIP Routing Information Protocol (RIP)
To use SNMP to detect potential routing loops

2 Select Enable SNMP, and Apply.
3 Optionally enter the Description, Location, and Contact information for this device for
easier location of the problem report.
5 Enter a name for the community, such as routing loop monitor.
6 Select the IP addresses and interfaces where you will be monitoring the FortiGate. you
can add up to 8 different addresses and interfaces.
7 Ensure that ports 161 and 162 (SNMP queries and traps) are allowed through your
firewall policies.
8 Select the events you want to be notified of. For routing loops this should include CPU
Overusage, Memory Low, and possibly Log disk space low. If there are
problems the log will be filling up quickly, and the FortiGate unit’s resources will be
overused.
9 Configure SNMP host (manager) software on your administration computer. This will
monitor the SNMP information sent out by the FortiGate unit. Typically you can
configure this software to alert you to outages or CPU spikes that may indicate a
routing loop.
Use dead gateway detection and e-mail alerts

Another tool available to you on FortiGate units is the dead gateway detection. This
feature allows the FortiGate unit to ping a gateway at regular intervals to ensure it is online
and working. When the gateway is not accessible, that interface is marked as down.
To detect possible routing loops with dead gateway detection and e-mail alerts
1 To configure dead gateway detection, go to System > Network > Options .
2 Set the detection interval (how often to send a ping), and fail-over detection (how many
lost pings before bringing the interface down). A smaller interval and smaller number of
lost pings will result in faster detection, but will create more traffic on your network.
3 To configure interface status change notification, go to Log&Report >Log Config > Alert
E-mail.
4 After you enter your email details, select the events you want to be alerted about — in
our case Configuration changes. You may also want to log CPU and Memory usage as
a network outage will cause your CPU activity to spike.
Note: If you have VDOMs configured, you will have to enter the basic SMTP server
information in the Global section, and the rest of the configuration within the VDOM that
includes this interface.
After this configuration, when this interface on the FortiGate unit cannot connect to the
next router, the FortiGate unit will bring down the interface and alert you with an email to
the outage.
Look at the packet flow

If you want to see what is happening on your network, look at the packets travelling on the
network. This is same idea as police pulling over a car and asking the driver where they
have been, and what the conditions were like.

1322 01-420-99686-20101026
Routing Information Protocol (RIP) Troubleshooting RIP
The method used in the troubleshooting sections “Debugging IPv6 on RIPng” on

page 1323 and on debugging the packet flow apply here as well. In this situation, you are
looking for routes that have metrics higher than 15 as that indicates they are unreachable.
Ideally if you debug the flow of the packets, and record the routes that are unreachable,
you can create an accurate picture of the network outage.
Action to take on discovering a routing loop

Once you have mapped the problem on your network, and determined it is in fact a routing
loop there are a number of steps to take in correcting it.
1 Get any offline routers back online. This may be a simple reboot, or you may have to
replace hardware. Often this first step will restore your network to its normal operation,
once the routing tables finish being updated.
2 Change your routing configuration on the edges of the outage. Even if step 1 brought
your network back online, you should consider making changes to improve your
network before the next outage occurs. These changes can include configuring
features like holddowns and triggers for updates, split horizon, and poison reverse
updates.
Split horizon and Poison reverse updates

Split horizon is best explained with an example. You have three routers linked serially, let’s
call them A, B, and C. A is only linked to B, C is only linked to B, and B is linked to both A
and C. To get to C, A must go through B. If the link to C goes down, it is possible that B will
try to use A’s route to get to C. This route is A-B-C, so it will not work. However, if B tries to
use it this begins an endless loop.
This situation is called a split horizon because from B’s point of view the horizon stretches
out in each direction, but in reality it only is on one side.
Poison reverse is the method used to prevent routes from running into split horizon
problems. Poison reverse “poisons” routes away from the destination that use the current
router in their route to the destination. This “poisoned” route is marked as unreachable for
routers that cannot use it. In RIP this means that route is marked with a distance of 16.
Debugging IPv6 on RIPng

The debug commands are very useful to see what is happening on the network at the
packet level. There are a few changes to debugging the packet flow when debugging
IPv6.
The following CLI commands specify both IPv6 and RIP, so only RIPng packets will be
reported. The output from these commands will show you the RIPng traffic on your
FortiGate unit including RECV, SEND, and UPDATE actions.
The addresses are in IPv6 format.
FGT# diagnose debug enable

FGT# diagnose ipv6 router rip level info
FGT# diagnose ipv6 router rip all enable

01-420-99686-20101026 1323
RIP routing examples Routing Information Protocol (RIP)
These three commands will:

• turn on debugging in general
• set the debug level to information, a verbose reporting level
• turn on all rip router settings
Part of the information displayed from the debugging is the metric (hop count). If the metric
is 16, then that destination is unreachable since the maximum hop count is 15.
In general, you should see an update announcement, followed by the routing table being
sent out, and a received reply in response.
For more information, see “Testing the IPv6 RIPng information” on page 1343
RIP routing examples

The following examples for RIP:
• Simple RIP example
• RIPng — RIP and IPv6
Simple RIP example

This is an example of a typical medium sized network configuration using RIP routing.
Your company has 3 small local networks, one for each department. These networks are
connected by RIP, and then connected to the Internet. Each subnet has more than one
route, for redundancy. There are two central routers that are both connected to the
internet, and to the other networks. If one of those routers goes down, the whole network
can continue to function normally.
The ISP is running RIP, so no importing or exporting routes is required on the side of the
network. However, since the internal networks have static networking running those will
need to be redistributed through the RIP network.
To keep the example simple, there will be no authentication of router traffic.
With RIP properly configured, if the device fails or temporarily goes offline, the routes will
change and traffic will continue to flow. RIP is good for a smaller network due to its lack of
complex configurations.
• Network layout and assumptions
• Configuring the FortiGate units system information
• Configuring other networking devices
• Testing network configuration
Network layout and assumptions
Basic network layout

Your company has 3 departments each with their own network — Sales, R&D, and
Accounting. Each network has routers that are not running RIP as well as FortiGate units
running RIP.

1324 01-420-99686-20101026
Routing Information Protocol (RIP) Simple RIP example
The R&D network has two RIP routers, and each is connected to both other departments
as well as being connected to the Internet through the ISP router. The links to the Internet
are indicated in black.
The three internal networks do not run RIP. They use static routing because they are small
networks. This means the FortiGate units have to redistribute any static routes they learn
so that the internal networks can communicate with each other.
Where possible in this example, the default values will be used or the most general
settings. This is intended to provide an easier configuration that will require less
troubleshooting.
In this example the routers, networks, interfaces used, and IP addresses are as follows.
Note that the Interfaces that connect Router2 and Router3 also connect to the R&D
network.
Table 83: Rip example network topology
Network Router Interface & Alias IP address

Sales Router1 port1 (internal) 10.11.101.101
port2 (router2) 10.11.201.101
port3 (router3) 10.11.202.101
R&D Router2 port1 (internal) 10.12.101.102
port2 (router1) 10.11.201.102
port3 (router4) 10.14.201.102
port4 (ISP) 172.20.120.102
Router3 port1 (internal) 10.12.101.103
port2 (router1) 10.11.201.103
port3 (router4) 10.14.202.103
port4 (ISP) 172.20.120.103
Accounting Router4 port1 (internal) 10.14.101.104
port2 (router2) 10.14.201.104
port3 (router3) 10.14.202.104

01-420-99686-20101026 1325
Simple RIP example Routing Information Protocol (RIP)
Figure 175: Network topology for the simple RIP example
ISP router
(172.20.120.5)
RIP Router2
uter2
RIP Router4
RIP Router1
uter1
R&D Network
Accounting
Network
RIP Router3
RI
Sales Network
Assumptions
The following assumptions have been made concerning this example.
• All FortiGate units have 4.0 MR1 firmware, and are running factory default settings.
• All CLI and web-based manager navigation assumes the unit is running in NAT/Route
operating mode, with VDOMs disabled.
• All FortiGate units have interfaces labelled port1 through port4 as required.
• All firewalls have been configured for each FortiGate unit to allow the required traffic to
flow across interfaces.
• Only FortiGate units are running RIP on the internal networks.
• Router2 and Router3 are connected through the internal network for R&D.
• Router2 and Router3 each have their own connection to the Internet, indicated in black
on Figure 175 on page 1326.

This example is very straight forward. The only steps involved are:
• Configuring FortiGate unit RIP router information
Configuring the FortiGate units system information

Each FortiGate unit needs their hostname, and interfaces configured.
For IP numbering, Router2 and Router3 use the other routers numbering where needed.

1326 01-420-99686-20101026
Router2 and Router3 have dead gateway detection enabled on the ISP interfaces using
Ping. Remember to contact the ISP and confirm their server has ping enabled.
Configure the hostname, interfaces, and default route

To configure Router1 system information - web-based manager
1 Go to System > Status > Dashboard > System Information.
2 Next to Host Name select Change, and enter “Router1”.
3 Go to Router > Static.
4 Edit the default route and enter the following information:

Device port2 (router2)
Gateway 172.20.120.5/255.255.255.0
Distance 40
5 Enter a second default route and enter the following information:

Gateway 172.20.120.5/255.255.255.0
Distance 40

7 Edit port1 (internal) interface.
8 Set the following information, and select OK.
Alias internal
IP/Netmask 10.11.101.101/255.255.255.0
Administrative Access HTTPS SSH PING
Description Internal sales network
Administrative Status Up
9 Edit port2 (router2) interface.

Alias router2
IP/Netmask 10.11.201.101/255.255.255.0
Description Link to R&D network & internet through Router2

01-420-99686-20101026 1327
Alias router3
IP/Netmask 10.11.202.101/255.255.255.0
Description Link to R&D network and internet through Router3
To configure Router1 system information - CLI

set hostname Router1
end

edit 1
set device "port2"
set distance 45
next
edit 2
set device “port3”
set distance 45
end
end

edit port1
set alias internal
set ip 10.11.101.101/255.255.255.0
set description “Internal sales network”
next
edit port2
set alias ISP
set ip 10.11.201.101/255.255.255.0
set description “Link to R&D network & internet through Router2”
next
edit port3
set alias router3
set ip 10.11.202.101/255.255.255.0
end
end


1328 01-420-99686-20101026

Device port4 (ISP)
Gateway 172.20.120.5/255.255.255.0
Distance 5

Alias internal
IP/Netmask 10.12.101.102/255.255.255.0
Description R&D internal network and Router3

Alias router1
IP/Netmask 10.12.201.102/255.255.255.0
Description Link to Router1 and the Sales network

Alias router4
IP/Netmask 10.12.301.102/255.255.255.0
Description Link to Router4 and the accounting network
12 Edit port4 (ISP) interface.

01-420-99686-20101026 1329
Alias ISP
IP/Netmask 172.20.120.102/255.255.255.0
Detect Interface Status enable
for Gateway Load
Balancing
Detect Server 172.20.120.5
Detect Protocol Ping
for Gateway Load
Balancing
Description Internet through ISP

end

edit 1
set device "port4"
set distance 5
end
end

edit port1
set alias internal
set ip 10.11.101.102/255.255.255.0
set description “Internal RnD network and Router3”
next
edit port2
set alias router1
set ip 10.11.201.102/255.255.255.0
set description “Link to Router1”
next
edit port3
set alias router3
set ip 10.14.202.102/255.255.255.0
next
edit port4
set alias ISP
set ip 172.20.120.102/255.255.255.0
set description “ISP and internet”
end

1330 01-420-99686-20101026
end


Device port4 (ISP)
Gateway 172.20.120.5/255.255.255.0
Distance 5

Alias internal
IP/Netmask 10.12.101.103/255.255.255.0
Description R&D internal network and Router2

Alias router1
IP/Netmask 10.13.201.103/255.255.255.0
Description Link to Router1 and Sales network

Alias router4
IP/Netmask 10.13.301.103/255.255.255.0
Description Link to Router4 and accounting network

01-420-99686-20101026 1331
Alias ISP
IP/Netmask 172.20.120.103/255.255.255.0
for Gateway Load
Balancing
Detect Server 172.20.120.5
Detect Protocol Ping
Description Internet and ISP

end

edit 1
set device "port4"
set distance 5
end
end

edit port1
set alias internal
set ip 10.12.101.103/255.255.255.0
set description “Internal RnD network and Router2”
next
edit port2
set alias ISP
set ip 10.11.201.103/255.255.255.0
next
edit port3
set alias router3
set ip 10.14.202.103/255.255.255.0
next
edit port4
set alias ISP
set ip 172.20.120.103/255.255.255.0
end
end

1332 01-420-99686-20101026


Gateway 172.20.120.5/255.255.255.0
Distance 40
5 Enter a second default route and enter the following information:

Gateway 172.20.120.5/255.255.255.0
Distance 40

7 Edit port 1 (internal) interface.
Alias internal
IP/Netmask 10.14.101.104/255.255.255.0
Description Internal accounting network
9 Edit port 2 (router2) interface.

Alias router2
IP/Netmask 10.14.201.104/255.255.255.0
Description Link to R&D network & internet through Router2
11 Edit port 3 (router3) interface.

Alias router3
IP/Netmask 10.14.301.104/255.255.255.0
Description Link to R&D network and internet through Router3

01-420-99686-20101026 1333

end

edit 1
set device "port2"
set distance 45
next
edit 2
set device “port3”
set distance 45
end
end

edit port1
set alias internal
set ip 10.14.101.104/255.255.255.0
set description “Internal sales network”
next
edit port2
set alias router2
set ip 10.14.201.104/255.255.255.0
next
edit port3
set alias router3
set ip 10.14.202.104/255.255.255.0
end
end
Configuring FortiGate unit RIP router information

With the interfaces configured, RIP can now be configured on the FortiGate units.
This includes the following steps:
• configure RIP version used
• redistribute static networks
• add networks serviced by RIP
• add interfaces that support RIP on the Fortigate unit
Router1 and Router4 are configured the same. Router2 and Router3 are configured the
same. These routers will be grouped accordingly for the following procedures — repeat
the procedures once for each FortiGate unit.

1334 01-420-99686-20101026
Configure RIP settings on Router1 and Router4 - web-based manager

1 Go to Router > Dynamic > RIP.
2 Select 2 for RIP Version.
3 In Advanced Options, under Redistribute enable Static.
4 Leave the other Advanced Options at default values.
5 Enter the following networks, and select Add after each:
• 10.11.0.0/255.255.0.0
• 10.12.0.0/255.255.0.0
• 10.14.0.0/255.255.0.0
• 172.20.120.0/255.255.255.0
6 For interface, select Create New and set the following information.
Interface port1 (internal)

Send Version Both
Receive Version Both
Authentication None
Passive Interface disabled
Interface port2 (router2)

Send Version Both
Authentication None

Send Version Both
Authentication None
Configure RIP settings on Router1 and Router4 - CLI

config router rip
set version 2
config interface
edit "port1"
set receive-version 1 2
set send-version 1 2
next
edit "port2"
next
edit "port3"

01-420-99686-20101026 1335
end
config network
edit 1
set prefix 10.11.0.0 255.255.0.0
next
edit 2
set prefix 10.12.0.0 255.255.0.0
next
edit 3
set prefix 10.14.0.0 255.255.0.0
next
edit 4
set prefix 172.20.120.0 255.255.255.0
end
config redistribute "static"
set status enable
end
end
Configure RIP settings on Router2 and Router3- web-based manager

1 Go to Router > Dynamic > RIP.
2 Select 2 for RIP Version.
3 In Advanced Options, under Redistribute enable Static.
4 Leave the other Advanced Options at default values.
5 Enter the following networks, and select Add after each:
• 10.11.0.0/255.255.0.0
• 10.12.0.0/255.255.0.0
• 10.14.0.0/255.255.0.0
• 172.20.120.0/255.255.255.0
Interface port1 (internal)

Send Version Both
Authentication None

Send Version Both
Authentication None

Send Version Both

1336 01-420-99686-20101026

Authentication None
Interface port4 (ISP)

Send Version Both
Authentication None
Configure RIP settings on Router2 and Router3- web-based manager

config router rip
set version 2
config interface
edit "port1"
next
edit "port2"
next
edit "port3"
end
edit "port4"
end
config network
edit 1
set prefix 10.11.0.0 255.255.0.0
next
edit 2
set prefix 10.12.0.0 255.255.0.0
next
edit 3
set prefix 10.14.0.0 255.255.0.0
next
edit 4
set prefix 172.20.120.0 255.255.255.0
end
config redistribute "static"
set status enable
end
end
Configuring other networking devices

In this example there are two groups of other devices on the the network — internal
devices, and the ISP.

01-420-99686-20101026 1337
RIPng — RIP and IPv6 Routing Information Protocol (RIP)
The first is the internal network devices on the Sales, R&D, and Accounting networks. This
includes simple static routers, computers, printers and other network devices. Once the
FortiGate units are configured, the internal static routers need to be configured using the
internal network IP addresses. Otherwise there should be no configuration required.
The second group of devices is the ISP. This consists of the RIP router the FortiGate
routers 2 and 3 connect to. You need to contact your ISP and ensure they have your
information for your network such as the IP addresses of the connecting RIP routers, what
version of RIP your network supports, and what authentication (if any) is used.
Testing network configuration

Once the network has been configured, you need to test that it works as expected.
The two series of tests you need to run are to test the internal networks can communicate
with each other, and that the internal networks can reach the internet.
Use ping, traceroute, and other networking tools to run these tests.
If you encounter problems, for troubleshooting help consult “Troubleshooting RIP” on
page 1320, and the general “” on page 1307.
RIPng — RIP and IPv6

RIP next generation, or RIPng, is the version of RIP that supports IPv6.
This is an example of a typical small network configuration using RIPng routing.
Your internal R&D network is working on a project for a large international telecom
company that uses IPv6. For this reason, you have to run IPv6 on your internal network
and you have decided to use only IPv6 addresses.
Your network has two FortiGate units running the RIPng dynamic routing protocol. Both
FortiGate units are connected to the ISP router and the internal network. This
configuration provides some redundancy for the R&D internal network enabling it to reach
the internet at all times..
Basic network layout

Your internal R&D network is working on a project for a large international telecom
company that uses IPv6. For this reason, you have to run IPv6 on your internal network
and you have decided to use only IPv6 addresses.
Your network has two FortiGate units running the RIPng dynamic routing protocol. Both
FortiGate units are connected to the ISP router and the internal network. This
configuration provides some redundancy for the R&D internal network enabling it to reach
the internet at all times.
All internal computers use RIP routing, so no static routing is required. And all internal
computers use IPv6 addresses.

1338 01-420-99686-20101026
Routing Information Protocol (RIP) RIPng — RIP and IPv6
Where possible in this example, the default values will be used or the most general
settings. This is intended to provide an easier configuration that will require less
troubleshooting.
In this example the routers, networks, interfaces used, and IP addresses are as follows.
Table 84: Rip example network topology
Network Router Interface & Alias IPv6 address

R&D Router1 port1 (internal) 2002:A0B:6565:0:0:0:0:0
port2 (ISP) 2002:AC14:7865:0:0:0:0:0
Router2 port1 (internal) 2002:A0B:6566:0:0:0:0:0
port2 (ISP) 2002:AC14:7866:0:0:0:0:0
Figure 176: Network topology for the IPV6 RIPng example
ISP router
(2002:AC14:7805::)
RIP Router1
r1 RIP Router2
R
R&D Internal
Network
Assumptions
The following assumptions have been made concerning this example.
• All FortiGate units have 4.0 MR1 firmware, and are running factory default settings.
• All CLI and web-based manager navigation assumes the unit is running in NAT/Route
operating mode, with VDOMs disabled.
• All FortiGate units have interfaces labelled port1 and port2 as required.
• All firewalls have been configured for each FortiGate unit to allow the required traffic to
flow across interfaces.
• All network devices are support IPv6 and are running RIPng.

01-420-99686-20101026 1339

This example is very straight forward. The only steps involved are:
• Configuring RIPng on FortiGate units
• Configuring other network devices
• Testing the configuration
Configuring the FortiGate units system information

Each FortiGate unit needs IPv6 enabled, a new hostname, and interfaces configured.
To configure system information on Router1 - web-based manager

1 Go to System > Status > Dashboard.
2 For Host name, select Change.
3 Enter “Router1”.
5 Enable IPv6 Support on GUI, and select Apply.
Alias internal
IP/Netmask 2002:A0B:6565::/0
Description Internal RnD network

Alias ISP
IP/Netmask 2002:AC14:7865::/0
Description ISP and internet

1340 01-420-99686-20101026
To configure system information on Router1 - CLI

set gui-ipv6 enable
end
edit port1
set alias internal
set allow_access https ping ssh
set description “Internal RnD network”
config ipv6
set ip6-address 2002:a0b:6565::/0
end
next
edit port2
set alias ISP
config ipv6
set ip6-address 2002:AC14:7865::
end
end
To configure system information on Router2 - web-based manager

1 Go to System > Status > Dashboard.
2 For Host name, select Change.
3 Enter “Router2”.
5 Enable IPv6 Support on GUI, and select Apply.
Alias internal
IP/Netmask 2002:A0B:6566::/0
Description Internal RnD network

Alias ISP
IP/Netmask 2002:AC14:7866::/0
Description ISP and internet

01-420-99686-20101026 1341
To configure system information on Router2 - CLI

set gui-ipv6 enable
end
edit port1
set alias internal
set description “Internal RnD network”
config ipv6
set ip6-address 2002:a0b:6566::/0
end
next
edit port2
set alias ISP
config ipv6
set ip6-address 2002:AC14:7866::
end
end
Configuring RIPng on FortiGate units

Now that the interfaces are configured, you can configure RIPng on the FortiGate units.
There are only two networks and two interfaces to include — the internal network, and the
ISP network. There is no redistribution, and no authentication. In RIPng there is no
specific command to include a subnet in the RIP broadcasts. There is also no information
required for the interfaces beyond including their name.
As this is a CLI only confirmation, configure the ISP router and the other FortiGate unit as
neighbors. This was not part of the previous example as this feature is not offered in the
web-based manager. Declaring neighbors in the configuration like this will reduce the
discovery traffic when the routers start up.
Since RIPng is not supported in the web-based manager, this section will only be entered
in the CLI.
To configure RIPng on Router1 - CLI

config router ripng
config interface
edit port1
next
edit port2
end
config neighbor
edit 1
set interface port1
set ipv6 2002:a0b:6566::/0
next
edit 2
set interface port2
set ipv6 2002:AC14:7805::/0
end

1342 01-420-99686-20101026
To configure RIPng on Router2 - CLI

config router ripng
config interface
edit port1
next
edit port2
end
config neighbor
edit 1
set interface port1
set ipv6 2002:a0b:6565::/0
next
edit 2
set interface port2
set ipv6 2002:AC14:7805::/0
end
Configuring other network devices

The other devices on the internal network all support IPv6, and are running RIPng where
applicable. They only need to know the internal interface network addresses of the
FortiGate units.
The ISP routers need to know the FortiGate unit information such as IPv6 addresses.
Testing the configuration

In addition to normal testing of your network configuration, you must also test the IPv6 part
of this example.
For troubleshooting problems with your network, see “” on page 1307.
For troubleshooting problems with RIP, see“Troubleshooting RIP” on page 1320.
Use the following section for testing and troubleshooting RIPng.
Testing the IPv6 RIPng information

There are some commands to use when checking that your RIPng information is correct
on your network. These are useful to check on your RIPng FortiGate units on your
network. Comparing the output between devices will help you understand your network
better, and also track down any problems.
FGT# diagnose ipv6 address list
View the local scope IPv6 addresses used as next-hops by RIPng on the FortiGate
unit.
FGT# diagnose ipv6 route list
View ipv6 addresses that are installed in the routing table.
FGT# get router info6 routing-table
View the routing table. This information is almost the same as the previous command
(diagnose ipv6 route list) however it is presented in an easier to read format.
FGT# get router info6 rip interface external
View brief output on the RIP information for the interface listed. The information
includes if the interface is up or down, what routing protocol is being used, if passive
interface or split horizon are enabled,

01-420-99686-20101026 1343
FGT# get router info6 neighbor-cache list

View the IPv6/MAC address mapping. This also displays the interface index and name
associated with the address.

1344 01-420-99686-20101026

1345 01-420-99686-20101026

1346 01-420-99686-20101026
Border Gateway Protocol (BGP)
This section describes Border Gateway Protocol (BGP).
• BGP background and concepts
• Troubleshooting BGP
• BGP routing examples
BGP background and concepts

The border gateway protocol contains two distinct subsets — internal BGP (iBGP) and
external BGP (eBGP). iBGP is intended for use within your own networks. eBGP is used
to connect many different networks together, and is the main routing protocol for the
Internet backbone. FortiGate units support iBGP, and eBGP only for communities.
• Background
• Parts and terminology of BGP
• How BGP works
Background
BGP was first used in 1989. The current version, BGP-4, was released in 1995 and is
defined in RFC 1771. That RFC has since been replaced by the more recent RFC 4271.
The main benefits of BGP-4 are classless inter-domain routing, and aggregate routes.
BGP is the only routing protocol to use TCP for a transport protocol. Other routing
protocols use UDP.
BGP makes routing decisions based on path, network policies and rulesets instead of the
hop-count metric as RIP does, or cost-factor metrics as OSPF does.
BGP-4+ supports IPv6. It was introduced in RFC 2858 and RFC 2545. BGP-4+ also
supports
BGP is the routing protocol used on the Internet. It was designed to replace the old
Exterior Gateway Protocol (EGP) which had been around since 1982, and was very
limited. In doing so, BGP enabled more networks to take part in the Internet backbone to
effectively decentralize it and make the Internet more robust, and less dependent on a
single ISP or backbone network.
Parts and terminology of BGP

In a BGP network, there are some terms that need to be explained before going ahead.
Some parts of BGP are not explained here as they are common to other dynamic routing
protocols as well. For more information on parts of BGP that are not listed here, see
“Dynamic routing terminology” on page 1302.

01-420-99686-20101026 1347
Parts and terminology of BGP Border Gateway Protocol (BGP)

• BGP and IPv6
• Roles of routers in BGP networks
• Network Layer Reachability Information (NLRI)
• BGP attributes
• Confederations
BGP and IPv6

FortiGate units support IPv6 over BGP using the same config router bgp command
as IPv4, but different subcommands.
The main CLI keywords have IPv6 equivalents that are identified by the “6” on the end of
the keyword, such as with config netowrk6 or set allowas-in6.
IPv6 BGP commands include:
config bgp
set allowas-in6 <max_num_AS_integer>
set allowas-in-enable6 {enable | disable}
set attribute-unchanged6 [as-path] [med] [next-hop]
set capability-default-originate6 {enable | disable}
set capability-graceful-restart6 {enable | disable}
set capability-orf6 {both | none | receive | send}
set default-originate-route-map6 <routemap_str>
set distribute-list-in6 <access-list-name_str>
set distribute-list-out6 <access-list-name_str>
set filter-list-in6 <aspath-list-name_str>
set filter-list-out6 <aspath-list-name_str>
set maximum-prefix6 <prefix_integer>
set maximum-prefix-threshold6 <percentage_integer>
set maximum-prefix-warning-only6 {enable | disable}
set next-hop-self6 {enable | disable}
set prefix-list-in6 <prefix-list-name_str>
set prefix-list-out6 <prefix-list-name_str>
set remove-private-as6 {enable | disable}
set route-map-in6 <routemap-name_str>
set route-map-out6 <routemap-name_str>
set route-reflector-client6 {enable | disable}
set route-server-client6 {enable | disable}
set send-community6 {both | disable | extended | standard}
set soft-reconfiguration6 {enable | disable}
set unsuppress-map6 <route-map-name_str>
config network6
config redistribute6
end

1348 01-420-99686-20101026
Border Gateway Protocol (BGP) Parts and terminology of BGP
Roles of routers in BGP networks

Dynamic routing has a number of different roles routers can fill such as those covered in
“Dynamic routing terminology” on page 1302. BGP has a number of custom roles that
routers can fill. These include:
• Speaker routers
• Peer routers or neighbors
• Route reflectors (RR)
Speaker routers
Any router configured for BGP is considered a BGP speaker. This means that a speaker
router advertises BGP routes to its peers.
Any routers on the network that are not speaker routers, are not treated as BGP routers.
Peer routers or neighbors

In a BGP network, all neighboring BGP routers or peer routers are routers that are
connected to your FortiGate unit. Your FortiGate unit learns about all other routers through
these peers.
You need to manually configure BGP peers on your FortiGate unit as neighbors.
Otherwise these routers will not be seen as peers, but instead as simply other routers on
the network that don’t support BGP. You can optionally use MD5 authentication to
password protect BGP sessions with those neighbors. (see RFC 2385).
You can configure up to 1000 BGP neighbors on your FortiGate unit. You can clear all or
some BGP neighbor connections (sessions) using the exec router clear bgp
command.
For example, if you have 10 routes in the BGP routing table and you want to clear the
specific route to IP address 10.10.10.1, enter the command:
FGT# exec router clear bgp ip 10.10.10.1
To remove all routes for AS number 650001, enter the command:
FGT# exec router clear bgp as 650001
To remove route flap dampening information for the 10.10.0.0/16 subnet, enter the
command:
FGT# exec router clear bgp dampening 10.10.0.0/16
In Figure 1, Router A is directly connected to five other routers in a network that contains
12 routers overall. These routers, the ones in the blue circle, are Router A’s peers or
neighbors.

01-420-99686-20101026 1349
Figure 177: Router A and its 5 peer routers
Border Router
Router A
Router A’s peer routers
As a minimum, when configuring BGP neighbors you must enter their IP address, and the
AS number (remote_as). This is all the information the web-based manager interface
allows you to enter for a neighbor.
The BGP commands related to neighbors are quite extensive and include:
config router bgp
config neighbor
edit <neighbor_address_ipv4>
set activate {enable | disable}
set advertisement-interval <seconds_integer>
set allowas-in <max_num_AS_integer>
set allowas-in-enable {enable | disable}
set attribute-unchanged [as-path] [med] [next-hop]
set bfd {enable | disable}
set capability-default-originate {enable | disable}
set capability-dynamic {enable | disable}
set capability-graceful-restart {enable | disable}
set capability-orf {both | none | recieve | send}
set capability-route-refresh {enable | disable}
set connect-timer <seconds_integer>
set description <text_str>
set distribute-list-in <access-list-name_str>
set distribute-list-out <access-list-name_str>
set dont-capability-negotiate {enable | disable}
set ebgp-enforce-multihop {enable | disable}
set ebgp-multihop {enable | disable}
set ebgp-multihop-ttl <seconds_integer>
set filter-list-in <aspath-list-name_str>
set filter-list-out <aspath-list-name_str>
set holdtime-timer <seconds_integer>
set interface <interface-name_str>
set keep-alive-timer <seconds_integer>
set maximum-prefix <prefix_integer>
set maximum-prefix-threshold <percentage_integer>
set maximum-prefix-warning-only {enable | disable}
set next-hop-self {enable | disable}

1350 01-420-99686-20101026
set override-capability {enable | disable}

set passive {enable | disable}
set password <string>
set prefix-list-in <prefix-list-name_str>
set prefix-list-out <prefix-list-name_str>
set remote-as <id_integer>
set remove-private-as {enable | disable}
set retain-stale-time <seconds_integer>
set route-map-in <routemap-name_str>
set route-map-out <routemap-name_str>
set route-reflector-client {enable | disable}
set route-server-client {enable | disable}
set send-community {both | disable | extended | standard}
set shutdown {enable | disable}
set soft-reconfiguration {enable | disable}
set strict-capability-match {enable | disable}
set unsuppress-map <route-map-name_str>
set update-source <interface-name_str>
set weight <weight_integer>
end
end
end
Route reflectors (RR)

Route reflectors in BGP concentrate route updates so other routers need only talk to the
route reflectors to get all the updates. This results in smaller routing tables, fewer
connections between routers, faster responses to network topology changes, and less
administration bandwidth. BGP route reflectors are defined in RFC 1966.
In a BGP route reflector configuration, the AS is divided into different clusters that each
include client and reflector routers. The client routers supply the reflector routers with the
client’s route updates. The reflectors pass this information along to other route reflectors
and border routers. Only the reflectors need to be configured, not the clients — the clients
will find the closest reflector and communicate with it automatically. The reflectors
communicate with each other as peers. FortiGate units can be configured as either
reflectors or clients.
Since route reflectors are processing more than the client routers, the reflectors should
have more resources to handle the extra workload.
Smaller networks running BGP typically don’t require route reflectors (RR). However, RR
is a useful feature for large companies, where their AS may include 100 routers or more.
For example, for a full mesh 20 router configuration within an AS there would have to be
190 unique BGP sessions — just for routing updates within the AS. The number of
sessions jumps to 435 sessions for just 30 routers, or 4950 sessions for 100 routers. From
these numbers, its plain that updating this many sessions will quickly consume the limited
bandwidth and processing resources of the routers involved.
The following diagram illustrates how route reflectors can improve the situation when only
six routers are involved. The AS without route reflectors requires 15 sessions between the
routers. In the AS with route reflectors, the two route reflectors receive route updates from
the reflector clients (unlabeled routers in the diagram) in their cluster as well as other route
reflectors and pass them on to the border router. The RR configuration only require six
sessions. This example shows a reduction of 60% in the number of required sessions.

01-420-99686-20101026 1351
Figure 178: Required sessions within an AS with and without route reflectors
Border Router Border Router
RR
RR
Cluster2
Cluster1
AS without Route Reflectors AS with Route Reflectors (RR)
The BGP commands related to route reflectors includes:

config router bgp
config neighbor
set route-reflector-client {enable | disable}
set route-server-client {enable | disable}
end
end
Confederations
Confederations were introduced to reduce the number of BGP advertisements on a
segment of the network, and reduce the size of the routing tables. Confederations
essentially break up an AS into smaller units. Confederations are defined in RFC 3065
and RFC 1965.
Within a confederation, all routers communicate with each other in a full mesh
arrangement. Communications between confederations is more like inter-AS
communications in that many of the attributes are changed as they would be for BGP
communications leaving the AS, or eBGP.
Confederations are useful when merging ASs. Each AS being merged can easily become
a confederation, requiring few changes. Any additional permanent changes can then be
implemented over time as required. The figure below shows the group of ASs before
merging, and the corresponding confederations afterward as part of the single AS with the
addition of a new border router. It should be noted that after merging if the border router
becomes a route reflector, then each confederation only needs to communicate with one
other router, instead of five others.

1352 01-420-99686-20101026
Figure 179: AS merging using confederations
AS 1
Confed1
Confed1
AS
AS 1 1 (was AS1)
(was AS1) Confed2
AS 2 (was AS2)
rder R
Border outter
Router
Border
B d R Router
t
Confed5 Confed3
AS 3 (was AS5) (was AS3)
AS 5 Confed4
AS 4 (was AS4)
Multiple ASes before merging Combined AS with confederations and new

FortiGate unit border router
Confederations and route reflectors perform similar functions — they both sub-divide large
ASes for more efficient operation. They differ in that route reflector clusters can include
routers that are not members of a cluster, where routers in a confederation must belong to
that confederation. Also, confederations place their confederation numbers in the
AS_PATH attribute making it easier to trace.
It is important to note that while confederations essentially create sub-ASs, all the
confederations within an AS appear as a single AS to external ASs.
Confederation related BGP commands include:
config router bgp
set confederation-identifier <peerid_integer>
end
Network Layer Reachability Information (NLRI)

Network Layer Reachability Information (NLRI) is unique to BGP-4. It is sent as part of the
update messages sent between BGP routers, and contains information necessary to
supernet, or aggregate route, information. The NLRI includes the length and prefix that
when combined are the address of the aggregated routes referred to.
There is only one NLRI entry per BGP update message.

01-420-99686-20101026 1353
BGP attributes
Each route in a BGP network has a set of attributes associated with it. These attributes
define the route, and are modified as required along the route.
BGP can work well with mostly default settings, but if you are going to change settings you
need to understand the roles of each attribute and how they affect those settings.
The BGP attributes include:
AS_PATH A list of ASes a route has passed through.

See “AS_PATH” on page 1354.
MULTI_EXIT_DESC Which router to use to exit an AS with more than one
(MED) external connection.
See “MULTI_EXIT_DESC (MED)” on page 1355.
COMMUNITY Used to apply attributes to a group of routes.
See “COMMUNITY” on page 1355.
NEXT_HOP Where the IP packets should be forwarded to, like a
gateway in static routing. See “NEXT_HOP” on page 1356.
ATOMIC_AGGREGATE Used when routes have been summarized to tell
downstream routers not to de-aggregate the route. See
“ATOMIC_AGGREGATE” on page 1356.
ORIGIN Used to determine if the route is from the local AS or not.
See“ORIGIN” on page 1356.
LOCAL_PREF Used only within an AS to select the best route to a location (like
MED)
Note: Inbound policies on FortiGate units can change the NEXT-HOP,LOCAL-PREF, MED
and AS-PATH attributes of an internal BGP (iBGP) route for its local route selection
purposes. However, outbound policies on the unit cannot affect these attributes.
AS_PATH
AS_PATH is the BGP attribute that keeps track of each AS a route advertisement has
passed through. AS_PATH is used by confederations and by exterior BGP (EBGP) to help
prevent routing loops. A router knows there is a loop if it receives an AS_PATH with that
routers AS in it. The figure below shows the route between router A and router B. The
AS_PATH from A to B would read 701,702,703 for each AS the route passes through.
As of the start of 2010, the industry is upgrading from 2-byte to 4-byte AS_PATHs. This
upgrade was due to the imminent exhaustion of 2-byte AS_PATH numbers.
Figure 180: AS_PATH of 701,702, 703 between routers A and B
Network AS702
A
B
Network AS701
Network AS703
3 1
2
Direction of traffic across the networks

1354 01-420-99686-20101026
The BGP commands related to AS_PATH include:

config router bgp
set bestpath-as-path-ignore {enable | disable}
end
MULTI_EXIT_DESC (MED)
BGP AS systems can have one or more routers that connect them to other ASes. For
ASes with more than one connecting router, the Multi-Exit Discriminator (MED) lists which
router is best to use when leaving the AS. The MED is based on attributes such as delay.
It is a recommendation only, as some networks may have different priorities.
BGP updates advertise the best path to a destination network. When the FortiGate unit
receives a BGP update, the FortiGate unit examines the Multi-Exit Discriminator (MED)
attribute of potential routes to determine the best path to a destination network before
recording the path in the local FortiGate unit routing table.
FortiGate units have the option to treat any routes without an MED attribute as the worst
possible routing choice. This can be useful because a lack of MED information is a lack of
routing information which can be suspicious — possibly a hacking attempt or an attack on
the network. At best it is an unreliable route to select.
The BGP commands related to MED include:
config router bgp
set always-compare-med {enable | disable}
set bestpath-med-confed {enable | disable}
set bestpath-med-missing-as-worst {enable | disable}
set deterministic-med {enable | disable}
config neighbor
end
end
COMMUNITY
A community is a group of routes that have the same routing policies applied to them. This
saves time and resources. A community is defined by the COMMUNITY attribute of a BGP
route.
The FortiGate unit can set the COMMUNITY attribute of a route to assign the route to
predefined paths (see RFC 1997). The FortiGate unit can examine the COMMUNITY
attribute of learned routes to perform local filtering and/or redistribution.
The BGP commands related to COMMUNITY include:
config router bgp
set send-community {both | disable | extended | standard}
end

01-420-99686-20101026 1355
NEXT_HOP
The NEXT_HOP attribute says what IP address the packets should be forwarded to next.
Each time the route is advertised, this value is updated. The NEXT_HOP attribute is much
like a gateway in static routing.
FortiGate units allow you to to change the advertising of the FortiGate unit’s IP address
(instead of the neighbor’s IP address) in the NEXT_HOP information that is sent to IBGP
peers. This is changed with the config neighbor, set next-hop-self command.
The BGP commands related to NEXT_HOP include:
config router bgp
config neighbor
set next-hop-self {enable | disable}
end
end
ATOMIC_AGGREGATE
The ATOMIC_AGGREGATE attribute is used when routes have been summarized. It
indicates which AS and which router summarize the routes. It also tells downstream
routers not to de-aggregate the route. Summarized routes are routes with similar
information that have been combined, or aggregated, into one route that is easier to send
in updates. When it reaches its destination, the summarized routes are split back up into
the individual routes.
Your FortiGate unit doesn’t specifically set this attribute in the BGP router command, but it
is used in the route map command.
The commands related to ATOMIC_AGGREGATE include:
config rule
set set-aggregator-as <id_integer>
set set-aggregator-ip <address_ipv4>
set set-atomic-aggregate {enable | disable}
end
end
end
ORIGIN
The ORIGIN attribute records where the route came from. The options can be IBGP,
EBGP, or incomplete. This information is important because internal routes (IBGP) are
higher priority than external routes (EBGP). However incomplete ORIGINs are the lowest
priority of the three.
The commands related to ORIGIN include:
set comments <string>
config rule
set match-origin {egp | igp | incomplete | none}
end
end
end

1356 01-420-99686-20101026
Border Gateway Protocol (BGP) How BGP works
How BGP works

BGP is a link-state routing protocol and keeps link-state information about the status of
each network link it has connected. A BGP router receives information from its peer
routers that have been defined as neighbors. BGP routers listen for updates from these
configured neighboring routers on TCP port 179.
A BGP router is a finite state machine with six various states for each connection. As two
BGP routers discover each other, and establish a connection they go from the idle state,
through the various states until they reach the established state. An error cancan cause
the connection to be dropped and the state of the router to be reset to either active or idle.
These errors can be caused by: TCP port 179 not being open, a random TCP port above
port 1023 not being open, the peer address being incorrect, or the AS number being
incorrect.
When BGP routers start a connection, they negotiate which (if any) optional features will
be used such as multiprotocol extensions that can include IPv6 and VPNs.
IBGP versus EBGP

When you read about BGP, often you see EBGP or IBGP mentioned. These are both BGP
routing, but BGP used in different roles. Exterior BGP (EBGP) involves packets crossing
multiple autonomous systems (ASes) where interior BGP (IBGP) involves packets that
stay within a single AS. For example the AS_PATH attribute is only useful for EBGP where
routes pass through multiple ASes.
These two modes are important because some features of BGP are only used for one of
EBGP or IBGP. For example confederations are used in EBGP, and route reflectors are
only used in IBGP. Also routes learned from IBGP have priority over EBGP learned routes.
FortiGate units have some commands specific to EBGP. These include:
• automatically resetting the session information to external peers if the connection goes
down — set fast-external-failover {enable | disable}
• setting an administrative distance for all routes learned from external peers (must also
configure local and internal distances if this is set) — set distance-external
<distance_integer>
• enforcing EBGP multihops and their TTL (number of hops) — set ebgp-enforce-
multihop {enable | disable} and set ebgp-multihop-ttl
<seconds_integer>
BGP path determination — which route to use

All learned routes and their attributes come into the BGP router in raw form. Before routes
are installed in the routing table or are advertised to other routers, three levels of decisions
must be made.
The three phases of BGP best path determination do not change. However, some
manufacturers have added more information to the process, such as Cisco’s WEIGHT
attribute to enable an administrator to force one route’s selection over another.
There is one Adj-RIB-IN and Adj-RIB-OUT for each configured neighbor. They are
updated when the FortiGate unit receives BGP updates, or when the FortiGate unit sends
out BGP updates.

01-420-99686-20101026 1357
How BGP works Border Gateway Protocol (BGP)
Figure 181: Three phases of BGP routing decision
Adj-RIB-IN
(new routes)
Calculate:
iBGP or eBGP?
Phase 1 - Calculate route
local route policies preferences on incoming
LOCAL_PREF routes.
3 9
Adj-RIB-IN
(with route 11 6
preferences) 2 5
22
Phase 2 - Install the best
3 routes into the local
Loc-RIB
(with new 5 6 routing RIB
routes)
9
11
route map out?

iBGP or eBGP?
Phase 3 - Determine which
LOCAL_PREF? MED? routes to advertise.
aggregation?
Adj-RIB-OUT
(with routes
to send)
Routes
sent in update
Decision phase 1
At this phase, the decision is to calculate how preferred each route and its NRLI are the
Adjacent Routing Information Base Incoming (Adj-RIBs-In) compared to the other routes.
For internal routes (IBGP), policy information or LOCAL_PREF is used. For external peer
learned routes, it is based strictly on policy. These rules set up a list of which routes are
most preferred going into Phase 2.

1358 01-420-99686-20101026
Border Gateway Protocol (BGP) How BGP works
Decision phase 2
Phase 2 involves installing the best route to each destination into the local Routing
Information Base (Loc-RIB). Effectively, the Loc-RIB is the master routing table. Each
route from Phase 1 has their NEXT_HOP checked to ensure the destination is reachable.
If it is reachable, the AS_PATH is checked for loops. After that, routes are installed based
on the following decision process:
• If there is only one route to a location, it is installed.
• If multiple routes to the same location, use the most preferred route from Level 1.
• If there is a tie, break the tie based on the following in descending order of importance:
shortest AS_PATH, smallest ORIGIN number, smallest MED, EBGP over IBGP,
smallest metric or cost for reaching the NEXT_HOP, BGP identifier, and lowest IP
address.
Note that the new routes that are installed into the Loc-RIB are in addition to any existing
routes in the table. Once Phase 2 is completed the Loc-RIB will consist of the best of both
the new and older routes.
Decision phase 3
Phase 3 is route distribution or dissemination. This is the process of deciding which routes
the router will advertise. If there is any route aggregation or summarizing, it happens here.
Also any route filtering from route maps happens here.
Once Phase 3 is complete, an update can be sent out to update the neighbor of new
routes.
Aggregate routes and addresses

BGP4 allows classless routing, which uses netmasks as well as IP addresses. This
classless routing enables the configuration of aggregate routes by stating the address bits
the aggregated addresses have in common. For more information, see “Aggregated
routes and addresses” on page 1302.
In BGP there is an ATOMIC_AGGREGATE attribute that when set informs routers that the
route has been aggregated, and should not be de-aggregated. An associated
AGGREGATOR attribute include the information about the router that did the aggregating
including its AS.
The BGP commands associated with aggregate routes and addresses are:
config router bgp
config aggregate-address
edit <aggr_addr_id>
set as-set {enable | disable}
set prefix <address_ipv4mask>
set summary-only {enable | disable}
end
config aggregate-address6
edit <aggr_addr_id>
set as-set {enable | disable}
set prefix6 <address_ipv6mask>
set summary-only {enable | disable}
end
end

01-420-99686-20101026 1359
Troubleshooting BGP Border Gateway Protocol (BGP)
Troubleshooting BGP
There are some features in BGP that are used to deal with problems that may arise.
Typically the problems with a BGP network that has been configured, involve routes going
offline frequently. This is called route flap and causes problems for the routers using that
route.
• Clearing routing table entries
• Route flap
Clearing routing table entries

To see if a new route is being properly added to the routing table, you can clear all or some
BGP neighbor connections (sessions) using the exec router clear bgp command.
For example, if you have 10 routes in the BGP routing table and you want to clear the
specific route to IP address 10.10.10.1, enter the command:
FGT# exec router clear bgp ip 10.10.10.1
To remove all routes for AS number 650001, enter the command:
FGT# exec router clear bgp as 650001
Route flap
When routers or hardware along a route go offline and back online that is called a route
flap. Flapping is the term if these outages continue, especially if they occur frequently.
Route flap is a problem in BGP because each time a peer or a route goes down, all the
peer routers that are connected to that out-of-service router advertise the change in their
routing tables which creates a lot of administration traffic on the network. And the same
traffic happens again when that router comes back online. If the problem is something like
a faulty network cable that wobbles on and offline every 10 seconds, there could easily be
overwhelming amounts of routing updates sent out unnecessarily.
Another possible reason for route flap occurs with multiple FortiGate units in HA mode.
When an HA cluster fails over to the secondary unit, other routers on the network may see
the HA cluster as being offline resulting in route flap. While this doesn’t occur often, or
more than once at a time, it can still result in an interruption in traffic which is unpleasant
for network users. The easy solution for this problem is to increase the timers on the HA
cluster, such as TTL timers, so they do not expire during the failover process. Also
configuring graceful restart on the HA cluster will help with a smooth failover.
The first method of dealing with router flap should be to check your hardware. If a cable is
loose or bad, it can easily be replaced and eliminate the problem. If an interface on the
router is bad, either don’t use that interface or swap in a good router. If the power source is
bad on a router either replace the power supply or use a power conditioning backup power
supply. These quick and easy fixes can save you from configuring more complex BGP
options. However if the route flap is from another source, configuring BGP to deal with the
outages will ensure your network users uninterrupted service.
Some methods of dealing with route flap in BGP include:
• Holddown timer
• Dampening
• Graceful restart

1360 01-420-99686-20101026
Border Gateway Protocol (BGP) Troubleshooting BGP
Holddown timer
The first line of defence to a flapping route is the hold down timer. This timer reduces how
frequently a route going down will cause a routing update to be broadcast.
Once activated, the holddown timer won’t allow the FortiGate unit to accept any changes
to that route for the duration of the timer. If the route flaps five times during the timer
period, only the first outage will be recognized by the FortiGate unit — for the duration of
the other outages there will be no changes because the Fortigate unit is essentially
treating this router as down. After the timer expires, if the route is still flapping it will
happen all over again.
Even if the route isn’t flapping — if it goes down, comes up, and stays back up — the timer
still counts down and the route is ignored for the duration of the timer. In this situation the
route will be seen as down longer than it really is, but there will be only the one set of route
updates. This is not a problem in normal operation because updates are not frequent.
Also the potential for a route to be treated as down when it is really up can be viewed as a
robustness feature. Typically you do not want most of your traffic being routed over an
unreliable route. So if there is route flap going on, it is best to avoid that route if you can.
This is enforced by the holddown timer.
How to configure the holddown timer

There are three different route flapping situations that can occur: the route goes up and
down frequently, the route goes down and back up once over a long period of time, or the
route goes down and stays down for a long period of time. These can all be handled using
the holddown timer.
For example, your network has two routes that you want to set the holddown timer for.
One is your main route ( to 10.12.101.4) that all your Internet traffic goes through, and it
can’t be down for long if its down. The second is a low speed connection to a custom
network that is used infrequently ( to 10.13.101.4). The holddown timer for the main route
should be fairly short, lets say 60 seconds instead of the default 180 seconds. The second
route timer can be left at the default or even longer since it is rarely used. In your BGP
configuration this looks like:
config router bgp
config neighbor
edit 10.12.101.4
set holddown-timer 60
next
edit 10.13.101.4
set holddown-timer 180
next
end
end

01-420-99686-20101026 1361
Troubleshooting BGP Border Gateway Protocol (BGP)
Dampening
Dampening is a method used to limit the amount of network problems due to flapping
routes. With dampening the flapping still occurs, but the peer routers pay less and less
attention to that route as it flaps more often. One flap doesn’t start dampening, but the
second starts a timer where the router will not use that route — it is considered unstable. If
the route flaps again before the timer expires, the timer continues to increase. There is a
period of time called the reachability half-life after which a route flap will only be
suppressed for half the time. This half-life comes into effect when a route has been stable
for a while but not long enough to clear all the dampening completely. For the flapping
route to be included in the routing table again, the suppression time must expire.
If the route flapping was temporary, you can clear the flapping or dampening from the
FortiGate units cache by using one of the execute router clear bgp commands:
execute router clear bgp dampening {ip_address | ip/netmask}
or
execute router clear bgp flap-statistics {ip_address |
ip/netmask}
For example, to remove route flap dampening information for the 10.10.0.0/16 subnet,
enter the command:
FGT# exec router clear bgp dampening 10.10.0.0/16
The BGP commands related to route dampening are:
config router bgp
set dampening {enable | disable}
set dampening-max-suppress-time <minutes_integer>
set dampening-reachability-half-life <minutes_integer>
set dampening-reuse <reuse_integer>
set dampening-route-map <routemap-name_str>
set dampening-suppress <limit_integer>
set dampening-unreachability-half-life <minutes_integer>end
end
Graceful restart
BGP4 has the capability to gracefully restart.
In some situations, route flap is caused by routers that appear to be offline but the
hardware portion of the router (control plane) can continue to function normally. One
example of this is when some software is restarting or being upgraded, but the hardware
can still function normally.
Graceful restart is best used for these situations where routing will not be interrupted, but
the router is unresponsive to routing update advertisements. Graceful restart does not
have to be supported by all routers in a network, but the network will benefit when more
routers support it.
Note: FortiGate HA clusters can benefit from graceful restart. When a failover takes place,
the HA cluster will advertise it is going offline, and will not appear as a route flap. It will also
enable the new HA main unit to come online with an updated and usable routing table — if
there is a flap the HA cluster routing table will be out of date.

1362 01-420-99686-20101026
Border Gateway Protocol (BGP) Troubleshooting BGP
Scheduled time offline

Graceful restart is a means for a router to advertise it is going to have a scheduled
shutdown for a very short period of time. When neighboring routers receive this notice,
they will not remove that router from their routing table until after a set time elapses.
During that time if the router comes back online, everything continues to function as
normal. If that router remains offline longer than expected, then the neighboring routers
will update their routing tables as they assume that router will be offline for a long time.
FortiGate units support both graceful restart of their own BGP routing software, and also
neighboring BGP routers.
For example, if a neighbor of your FortiGate unit, with an IP address of 172.20.120.120,
supports graceful restart, enter the command:
config router bgp
config neighbor
edit 172.20.120.120
set capapbility-graceful-restart enable
end
end
If you want to configure graceful restart on your FortiGate unit where you expect the
Fortigate unit to be offline for no more than 2 minutes, and after 3 minutes the BGP
network should consider the FortiGate unit offline, enter the command:
config router bgp
set graceful-restart enable
set graceful-restart-time 120
set graceful-stalepath-time 180
end
.
Note: You can configure graceful restarting and other advanced settings only through CLI
commands. For more information on advanced BGP settings, see the “router” chapter of
The BGP commands related to BGP graceful restart are:

config router bgp
set graceful-restart { disable| enable}
set graceful-restart-time <seconds_integer>
set graceful-stalepath-time <seconds_integer>
config neighbor
set capability-graceful-restart {enable | disable}
end
end
execute router restart
Bi-directional forwarding detection (BFD)

Bi-directional Forwarding Detection (BFD) is a protocol used to quickly locate hardware
failures in the network. Routers running BFD communicate with each other, and if a timer
runs out on a connection then that router is declared down. BFD then communicates this
information to the routing protocol and the routing information is updated.
While BGP can detect route failures, BFD can be configured to detect these failures more
quickly allowing faster responses and improved convergence. This can be balanced with
the bandwidth BFD uses in its frequent route checking.

01-420-99686-20101026 1363
BGP routing examples Border Gateway Protocol (BGP)
Configurable granularity
BFD can run on the entire FortiGate unit, selected interfaces, or on BGP for all configured
interfaces. The hierarchy allows each lower level to override the upper level’s BFD setting.
For example, if BFD was enabled for the FortiGate unit, it could be disabled only for a
single interface or for BGP. For information about FortiGate-wide BFD options, see config
system settings in the FortiGate CLI Reference.
BFD support was added in FortiOS v3.0 MR4, and can only be configured through the
CLI.
The BGP commands related to BFD are:
config router bgp
config neighbor
edit <neighbor_address_ipv4>
set bfd {enable | disable}
end
end
execute router clear bfd session <src_ipv4> <dst_ipv4>

<interface>
BGP routing examples

BGP is a complex dynamic routing protocol. There are many BGP configurations and
features that can benefit from in-depth examples.
• Dual-homed BGP example
• Redistributing and blocking routes in BGP
Dual-homed BGP example

This is an example of a small network that uses BGP routing connections to two ISPs.
This is a common configuration for companies that need redundant connections to the
Internet for their business.
This configuration is for a small company connected to two ISPs. The company has one
main office, the Head Office, and uses static routing for internal routing on that network.
Both ISPs use BGP routing, and connect to the Internet directly. They want the company
to connect to the ISP networks using BGP. They also use graceful restart to prevent
unneeded updates, and use smaller timer values to detect network failures faster.
As can be expected, the company wants to keep their BGP configuration relatively simple
and easy to manage. The current configuration has only 3 routers to worry about — the 2
ISP border routers, and the FortiGate unit. This means the FortiGate unit will only have
two neighbour routers to configure.
This configuration has the added benefit of being easy to expand if the Company wants to
add a remote office in the future.
To keep the configuration simple, the Company is allowing only HTTP, HTTPS, FTP, and
DNS traffic out of the local network. This will allow employees access to the Internet and
their web-mail.

1364 01-420-99686-20101026
Border Gateway Protocol (BGP) Dual-homed BGP example

• Testing this configuration
Why dual home?

Dual homing means having two separate independent connections to the Internet.
Servers in this configuration have also been called bastion hosts and can include DNS
servers which require multiple connections.
Benefits of dual homing can include:
• redundant Internet connection that essentially never fails
• faster connections through one ISP or the other for some destinations, such as other
clients of those ISPs
• load balancing traffic to your Company network
• easier to enable more traffic through two connections than upgrading one connection
to bigger bandwidth
• easier to create protection policies for different traffic through a specific ISP
Some companies require reliable internet access at all times as part of their business.
Consider a doctor operating remotely who has their Internet connection fail — the
consequences could easily be life or death.
Dual homing is extra expense for the second ISP connection, and more work to configure
and maintain the more complex network topology.
Potential dual homing issues

BGP comes with load balancing issues, and dual homing is the same category. BGP does
not inherently deal well with load balancing, or getting default routes through BGP. Ideally
one connect may be best for certain destinations, but it may not have that traffic routed to
it making the load balancing less than perfect. This kind of fine tuning can be very time
consuming, and usually results in a best effort situation.
When dual coming is not configured properly, your network may become a link between
your ISPs and result in very high traffic between the ISPs that does not originate from your
network. The problems with this situation are that your traffic may not have the bandwidth
it needs, and you will be paying for a large volume of traffic that is not yours. This problem
can be solved by not broadcasting or redistributing BGP routes between the ISPs.
If you learn your default routes from the ISPs in this example, you may run into an
asymmetric routing problem where your traffic loops out one ISP and back to you through
the other ISP. If you think this may be happening you can turn on asymmetric routing on
the FortiGate unit (config system settings, set asymmetric enable) to verify that really is
the problem. Turn this feature off once this is established since it disables many features
on the FortiGate by disabling stateful inspection. Solutions for this problem can include
using static routes for default routes instead of learning them through BGP, or configuring
VDOMs on your FortiGate unit to provide a slightly different path back that is not a true
loop.

01-420-99686-20101026 1365
Dual-homed BGP example Border Gateway Protocol (BGP)

• Network layout
• Assumptions
Network layout
The network layout for the basic BGP example involves the company network being
connected to both ISPs as shown below. In this configuration the FortiGate unit is the BGP
border router between the Company AS, ISP1’s AS, and ISP2’s AS.
The components of the layout include:
• The Company AS (AS number 1) is connected to ISP1 and ISP2 through the FortiGate
unit.
• The Company has one internal network — the Head Office network at 10.11.101.0/24.
• The FortiGate unit internal interface is on the the Company internal network with an IP
address of 10.11.101.110.
• The FortiGate unit external1 interface is connected to ISP1’s network with an IP
address of 172.21.111.5, an address supplied by the ISP.
• ISP1 AS has an AS number of 6501, and ISP2 has an AS number of 6502
• Both ISPs are connected to the Internet.
• The ISP1 border router is a neighbor (peer) of the FortiGate unit. It has an address of
172.21.111.4.
• The ISP2 border router is a neighbor (peer) of the FortiGate unit. It has an address of
172.22.222.4.
• Apart from graceful restart, and shorter timers (holdtimer, and keepalive) default
settings are to be used whenever possible.

1366 01-420-99686-20101026
Figure 182: Basic BGP network topology
ISP2 AS 650002
ISP1 AS 650001
ISP BGP
Border Routers
172.22.222.4
172.21.111.4
l1
external1 e
external2
172.20.111.55 1
172.20.222.5
all
internal
10.11.101.110 Head Office BGP Border Router
Company AS (ASN 1)
Head Office Network

10.11.101.0/24
Assumptions
The basic BGP configuration procedure follows these assumptions:
• ISP1 is the preferred route, and ISP2 is the secondary route
• all basic configuration can be completed in both GUI and CLI
• only one AS is used for the Company
For these reasons this example configuration does not include:
• Route maps
• Access lists
• changing redistribution defaults — make link when example is set up
• IPv6
For more information on these features, see the corresponding section.

In this basic example, only two routers need to be configured — the FortiGate unit, and
the ISP BGP router. After they are configured, the network configuration should be tested
to ensure its working as expected.
To configure a simple BGP network

1 Configuring the FortiGate unit
2 Configuring other networking devices
3 Testing this configuration

01-420-99686-20101026 1367

In this topology, the FortiGate unit is the link between the Company Network and the ISP
network. The FortiGate unit is the only BGP router on the Company Network, but there is
at least one other BGP router on the ISP Network — there may be more but we don’t have
that information.
As mentioned in the general configuration steps, the ISP must be notified of the
Company’s BGP router configuration when complete as it will need to add the FortiGate
BGP router as a neighbor router on its domain. This step is required for the FortiGate unit
to receive BGP routing updates from the ISP network and outside networks.
If the ISP has any special BGP features enabled such as graceful restart, or route
dampening that should be determined up front so those features can be enabled on the
FortiGate unit.
To configure the FortiGate unit as a BGP router

1 Configure interfaces and default routes
2 Configure firewall services, addresses, and policies
3 Set the FortiGate BGP information
4 Add the internal network to the AS
5 Additional FortiGate BGP configuration
Configure interfaces and default routes

The FortiGate unit is connected to three networks — Company Network on the internal
interface, ISP1 Network on external1interface, and ISP2 on external2 interface.
This example uses basic interface settings. Check with your ISP to determine if additional
settings are required such as setting the maximum MTU size, or if gateway detection is
supported.
High end FortiGate units do not have interfaces labeled Internal, or External. Instead, for
clarity’s sake, we are using the alias feature to name interfaces for these roles.
Default routes to both external interfaces are configured here as well. Both are needed in
case one goes offline. ISP1 is the primary connection and has a smaller administrative
distance so it will be preferred over ISP2. Both distances are set low so they will be
preferred over any learned routes.
To configure the FortiGate interfaces - web-based manager

1 Go to System > Network.
2 Edit port 1 (internal) interface.
Alias internal
IP/Netmask 10.11.101.110/255.255.255.0
Description Company internal network
4 Edit port 2 (external1) interface.

1368 01-420-99686-20101026
Alias external1
IP/Netmask 172.21.111.5/255.255.255.0
Description ISP1 External BGP network
6 Edit port 3 (external2) interface.

Alias external2
IP/Netmask 172.22.222.5/255.255.255.0
Description ISP2 External BGP network
To configure the FortiGate interfaces (CLI)

edit port1
set alias internal
set ip 10.11.101.110 255.255.255.0
set allowaccess http https ssh
set description “Company internal network”
set status up
next
edit port2
set alias external1
set ip 172.21.111.5 255.255.255.0
set description “ISP1 External BGP network”
set status up
next
edit port3
set alias external2
set ip 172.22.222.5 255.255.255.0
set description “ISP2 External BGP network”
set status up
next
end
To configure default routes for both ISPs - CLI

1 Go to System > Router.
2 Delete any existing routes with a IP/Mask of address of 0.0.0.0/0.0.0.0

01-420-99686-20101026 1369
3 Select Create New, and set the following information.

Device port2
Gateway 172.21.111.5
Distance 10
4 Select OK.

Device port3
Gateway 172.22.222.5
Distance 15
6 Select OK.
To configure default routes for both ISPs - CLI

edit 1
set device "port2"
set distance 10
next
edit 2
set device "port3"
set distance 15
next
end
Configure firewall services, addresses, and policies

To create the firewall policies, first you must create the firewall services group that will
include all the services that will be allowed, then you must define the addresses that will
be used in the firewall policies, and lastly you configure the firewall policies themselves.
To keep the configuration simple, the Company is allowing only HTTP traffic out of the
local network. This will allow employees access to the Internet and their web-mail. DNS
services will also be allowed through the firewall.
The firewall policies will allow HTTP traffic (port 80 and port 8080), HTTPS traffic (port
443) , FTP traffic (port 21), and DNS traffic (port 53 and port 953) in both directions. Also
BGP (port 179) may need access through the firewall.
Note: For added security, you may want to define a smaller range of addresses for the
internal network. For example if only 20 addresses are used, only allow those addresses in
the range.
In the interest of keeping things simple, a zone will be used to group the two ISP interfaces
together. This will allow using one firewall policy to apply to both ISPs at the same time.
Remember to block intra-zone traffic as this will help prevent one ISP sending traffic to the
other ISP through your FortiGate unit using your bandwidth. The zone keeps configuration
simple, and in the future if there is a need for separate policies for each ISP, they can be
created and the zone can be deleted.

1370 01-420-99686-20101026
The addresses that will be used are the addresses of the FortiGate unit internal and
external ports, and the internal network.
More policies or services can be added in the future as applications are added to the
network. For more information on firewall policies, see the firewall chapter of the FortiGate
Note: When configuring firewall policies always enable logging to help you track and debug
your traffic flow.
To create a firewall services group - web-based manager

1 Go to Firewall > Service > Group, and select Create New.
2 For Group Name, enter “Basic_Services”.
3 From Available Services, move the following six services over to the Member list —
BGP, FTP, FTP_GET, FTP_PUT, DNS, HTTP, and HTTPS.
4 Select OK.
To create a firewall services group - CLI

edit "Basic_Services"
set member "BGP" "DNS" "FTP" "FTP_GET" "FTP_PUT" "HTTP"
"HTTPS"
next
end
To create a zone for the ISP interfaces - web-based manager

1 Go to Status > Network > Zone.
Zone Name ISPs

Block Intra-zone traffic enable
interface members port2 port3
3 Select OK.
To create a zone for the ISP interfaces - CLI

config system zone
edit "ISPs"
set interface "dmz1" "dmz2"
set intrazone block
next
end

01-420-99686-20101026 1371
To add the firewall addresses - web-based manager

1 Go to Firewall > Address.
Address Name Internal_network

Subnet / IP Range 10.11.101.0 255.255.255.0
Interface port1
3 Select OK.
To add the firewall addresses - CLI

edit "Internal_network"
set associated-interface "port1"
set subnet 10.11.101.0 255.255.255.0
next
end
To add the HTTP and DNS firewall policies - web-based manager

1 Go to Firewall > Policy, and select Create New.
2 Set the following information.
Source port1(internal)
Interface/Zone
Source Address Internal_network
Destination ISPs
Interface/Zone
Schedule always
Service Basic_services
Action ACCEPT
NAT Enable
Protection Profile scan
Log Allowed Traffic enable
Comments ISP1 basic services out policy
3 Select OK.

1372 01-420-99686-20101026
4 Create new, and set the following information.
Source ISPs
Interface/Zone
Source Address all
Destination port1(internal)
Interface/Zone
Destination Address Internal_network
Schedule always
Service Basic_services
Action ACCEPT
NAT Enable
Protection Profile scan
Log Allowed Traffic enable
Comments ISP1 basic services in policy

edit 1
set srcintf "port1"
set srcaddr "Internal_network"
set dstintf "ISPs"
set dstaddr "all"
set service "Basic_services"
set action accept
set nat enable
set profile "scan"
set comments "ISP1 basic services out policy"
next
edit 2
set srcintf "ISPs"
set srcaddr "all"
set dstintf "port1"
set dstaddr "Internal_network"
set service "Basic_services"
set action accept
set nat enable
set profile "scan"
set comments "ISP1 basic services in policy"
next
end

01-420-99686-20101026 1373
Set the FortiGate BGP information

When using the default information, there are only two fields to set to configure the
FortiGate unit as a BGP router.
For this configuration the FortiGate unit will be in a stub area with one route out — the ISP
BGP router. Until you configure the ISP router as a neighbour, even that route out is not
available. So while after this part of the configuration is complete your FortiGate unit will
be running BGP, it won’t know about any other routers running BGP until the next part of
the configuration is complete.
To set the BGP router information - web-based mananger

1 Go to System > Router > Dynamic > BGP.
Local AS 1
Router ID 10.11.101.110
To set the BGP router information - CLI

config router BGP
set as 1
end
Add the internal network to the AS

The Company is one AS with the FortiGate unit configured as the BGP border router
connecting that AS to the two ISPs ASes. The internal network in the Company’s AS must
be defined. If there were other networks in the company such as regional offices, they
would be added here as well.
To set the networks in the AS - web-based manager

1 Go to System > Router > Dynamic > BGP.
2 Set the following information and select OK.
IP/Netmask 10.11.101.0 255.255.255.0
To set the networks in the AS (CLI)

config router bgp
config network
edit 1
set prefix 10.11.101.0 255.255.255.0
next
end
end

1374 01-420-99686-20101026
Additional FortiGate BGP configuration

At this point that is all the settings that can be done in both the web-based manger and the
CLI. The remaining configuration must be completed in the CLI.
These additional settings are mainly determined by your ISP requirements. They will
determine your timers such as keep alive timers, if extended features like BFD and
graceful restart are being used, and so on. For this example, some common simply
features are being used to promote faster detections of network failures which will result in
better service for the Company’s internal network users.
The ISPs do not require authentication between peer routers.
These commands will enable or modify the following features on the FortiGate unit, and
where possible on neighboring routers as well:
• bestpath-med-missing-as-worst — treats a route without an MED as the worst
possible available route due to expected unreliability
• fast-external-failover — immediately reset the session information associated
with BGP external peers if the link used to reach them goes down
• graceful_restart* — advertise reboots to neighbors so they do not see the router
as offline, wait before declaring them offline, and how long to wait when they reboot
before advertising updates. These commands applies to neighbors and are part of the
BGP capabilities. This prevents unneeded routing updates.
• holdtime-timer — how long the router will wait for a keepalive message before
declaring a router offline. A shorter time will find an offline router faster.
• keepalive-timer — how often the router sends out keepalive messages to
neighbor routers to maintain those sessions.
• log-neighbor-changes — log changes to neighbor routers’ status. This can be
useful for troubleshooting from both internal and external networks.
• connect-timer — how long in seconds the FortiGate unit will try to reach this
neighbor before declaring it offline.
• weight — used to prefer routes from one neighbor over the other. In this example
ISP1 is the primary connection so it is weighted higher than ISP2
To configure additional BGP options - CLI

config router bgp
set bestpath-med-missing-as-worst enable
set fast-external-failover enable
set graceful_restart enable
set graceful-restart-time 120
set graceful-stalepath-time 180
set graceful-update-delay 180
set holdtime-timer 120
set keepalive-timer 45
set log-neighbor-changes enable
config neighbor
edit 172.21.111.4
set connect-timer 60
set description “ISP1”
set weight 250
next

01-420-99686-20101026 1375
edit 172.22.222.4
set connect-timer 60
set description “ISP2”
set weight 100
next
end
end

There are two other networking devices that need to be configured both ISPs’ BGP
routers.
The ISPs’ routers must add the FortiGate unit as a neighbor so route updates can be sent
in both directions. Note that ISP1 is not directly connected to ISP2 that we are aware of.
Inform both of your ISPs of your FortiGate unit’s BGP information. Once they have
configured their router, you can test your BGP connection to the internet.
They will require your FortiGate unit’s:
• IP address of the connected interface
• Router ID
• your Company’s AS number
Testing this configuration

With the dual-homed BGP configuration in place, you should be able to send and receive
traffic, send and receive routes, and not have any routing loops. Testing the networks will
confirm things are working as expected.
In general for routing you need to look at the routing table on different routers to see what
routes are being installed. You also need to sniff packets to see how traffic is being routed
in real time. These two sources of information will normally tell you what you need to
know.
Basic networking tools and methods can be found in “” on page 1307.
Testing of this example’s network configuration should be completed in two parts:
• Testing network connectivity
• Verifying the FortiGate unit’s routing tables
• Verifying traffic routing
• Verifying the dual-homed side of the configuration
Testing network connectivity

A common first step in testing a new network topology is to test if you can reach the
internet and other locations as you expect you should. If not, you may be prevented be
cabling issues, software or other issues.
The easiest way to test connections is to use ping, once you ensure that all the FortiGate
unit’s interfaces and ISP routers have ping support enabled. Also ensure that the firewall
policies allow ping through the firewall.

1376 01-420-99686-20101026
Connections to test in this example are the internal network to ISP1’s router or the
internet, and the same for ISP2. If you can connect on the external side of the Fortinet
unit, try to ping the internal network. Those three tests should prove your basic network
connections are working.
Note: Once you have completed testing the network connectivity, turn off ping support on
the external interfaces for additional security.
Verifying the FortiGate unit’s routing tables

The FortiGate routing table contains the routes stored for future use. If you are expecting
certain routes to be there and they are not, that is a good indicator that your configuration
is not what you expected.
The CLI command get router info routing-table details will provide you with
every route’s routing protocol, destination address, gateway address, interface, weighting,
and if the address is directly connected or not.
If you want to limit the display to BGP routes only, use the CLI command get router
info routing-table bgp. If there are no BGP routes in the routing table, nothing will
be displayed. In the CLI command you can replace BGP with static, or other routing
protocols to only display those routes.
If you want to see the contents of the routing information database (RIB), use the CLI
command get router info routing-table database. This will display the
incoming routes that may or may not make it into the routing table.
Verifying traffic routing

Traffic may be reaching the internal network, but it may be using a different route than you
think to get there.
Use a browser to try and access the Internet.
If needed, allow traceroute and other diag ports to be opened until things are working
properly. Then remove access for them again.
Look for slow hops on the traceroute, or pings to a location, as they may indicate network
loops that need to be fixed.
Any locations that have an unresolved traceroute or ping must be examined and fixed.
Use network packet sniffing to ensure traffic is being routed as you expect.
Verifying the dual-homed side of the configuration

Since there are two connections to the internet in this example, theoretically you can pull
the plug on one of the ISP connections, and all traffic will go through the other connection.
Alternately, you may choose to remove a default route to one ISP, remove that ISP’s
neighbor settings, or change the weightings to prefer other other ISP. These alternate
ways to test dual-homing do not change physical cabling, which may be preferred in some
situations.
If this does not work as expected, things to check include:
• default static routes — if these are wrong or don’t exist, the traffic can’t get out.
• BGP neighbor information — If the ISP router information is incorrect, the FortiGate
unit won’t be able to talk to it.

01-420-99686-20101026 1377
Redistributing and blocking routes in BGP Border Gateway Protocol (BGP)
Redistributing and blocking routes in BGP

During normal BGP operation, peer routers redistribute routes from each other. However,
in some specific situations it may be best to not advertise routes from one peer for various
reasons. Some reasons may be the peer is redundant with another peer (they share the
same routes exactly), it might be unreliable in some way, or some other reason.
The FortiGate can also take routes it learns from other protocols and advertise them in
BGP, for example OSPF or RIP. If your Company hosts its own web or email servers,
external locations will require routes to your networks to reach those services.
In this example the Company has a internal networks in an OSPF area, and is connected
to a BGP AS and two BGP peers. Company goes through these two peers to reach the
Internet. However, Peer 1 routes will not be advertised to Peer 2. The Company internal
user and server networks are running OSPF, and will redistribute those routes to BGP so
external locations can reach the web and email servers.
• Testing this configuration

• Network layout
• Assumptions
Network layout
The network layout for the BGP redistributing routes example involves the company
network being connected to two BGP peers as shown below. In this configuration the
FortiGate unit is the BGP border router between the Company AS, and the peer routers.
The components of the layout include:
• There is only one BGP AS in this example — AS 65001, shared by the FortiGate unit
and both peers.
• The Company’s FortiGate unit connects to the Internet through two BGP peers.
• The Company internal networks on the dmz interface of the FortiGate unit with an IP of
10.11.201.0/24.
• The FortiGate units’ interfaces are connected as follows:
• port1 (dmz) has IP 10.11.201.110 and is the internal user and server network
• port2 (external1) has IP 172.21.111.4 and is connected to Peer 1’s network
• port3 (external2) has IP 172.22.222.4 and is connected to Peer 2’s network
• Peer 1 has IP 172.21.111.5, and Peer 2 has IP 172.22.222.5.
• OSPF Area 1 is configured on the dmz interface of the FortiGate unit, and is the routing
protocol used by the internal users and servers.

1378 01-420-99686-20101026
Border Gateway Protocol (BGP) Redistributing and blocking routes in BGP
Figure 183: BGP network topology
Peer 1 Peer 2
172.21.111.5 172.22.222.5
BGP
AS 65001
external1 external2
172.21.111.4 172.22.222.4
dm
dmz
10.11.201.110
OSPF
Area 1 http
email
Assumptions
The the BGP redistributing routes configuration procedure follows these assumptions:
• the FortiGate unit has been configured following the Install Guide
• interfaces port1, port2, and port 3 exist on the FortiGate unit
• we don’t know the router manufacturers of Peer 1 and Peer 2
• we don’t know what other devices are on the BGP AS or OSPF Area
• all basic configuration can be completed in both GUI and CLI
• access lists and route maps will only be configured in CLI
• VDOMs are not enabled on the FortiGate unit
General Configuration Steps

1 Configuring the FortiGate unit — networks and firewalls
2 Configuring the FortiGate unit - BGP
3 Configuring the FortiGate unit - OSPF
4 Configuring other networking devices
5 Testing network configuration
Configuring the FortiGate unit — networks and firewalls

The FortiGate unit has three interfaces connected to networks — two external and one
dmz.
Firewall policies must be in place to allow traffic to flow between these networks.

01-420-99686-20101026 1379
Firewall services will change depending on which routing protocol is being used on that
network — either BGP or OSPF. Beyond that, all services that are allowed will be allowed
in both directions due to the internal servers. The services allowed are web-server
services (DNS, HTTP, HTTPS, SSH, NTP, FTP*, SYSLOG, and MYSQL), email services
(POP3, IMAP, and SMTP), and general troubleshooting services (PING, TRACEROUTE).
Those last two can be removed once the network is up and working properly to increase
security. Other services can be added later as needed.
To configure the interfaces - GUI

1 Go to System > Network.
2 Edit port1 (dmz) interface.
Alias dmz
IP/Netmask 10.11.201.110/255.255.255.0
Description OSPF internal networks
4 Edit port2 (external1) interface.

Alias external1
IP/Netmask 172.21.111.4/255.255.255.0
Administrative Access HTTPS SSH
Description BGP external Peer 1
6 Edit port3 (external2) interface.

Alias external2
IP/Netmask 172.22.222.4/255.255.255.0
Administrative Access HTTPS SSH
Description BGP external2 Peer2
To configure the FortiGate interfaces (CLI)

edit port1
set alias dmz
set ip 10.11.101.110 255.255.255.0
set description “OSPF internal networks”
set status up
next
edit port2
set alias external1
set ip 172.22.222.5 255.255.255.0

1380 01-420-99686-20101026
set description “external1 Peer 1”

set status up
next
edit port3
set alias external2
set ip 172.22.222.5 255.255.255.0
set description “external2 Peer 2”
set status up
next
end
To configure the firewall addresses - GUI

1 Go to Firewall > Address.
Address Name Internal_networks

Subnet / IP Range 10.11.201.0 255.255.255.0
Interface port1
3 Select OK.
4 Select Create New, and enter the following information:
5 Select OK.
To configure the firewall addresses - CLI

edit "BGP_services"
To configure firewall service groups - GUI

1 Go to Firewall > Service > Group.
3 Name the group OSPF_Services.
4 Move the following services to the right list: DNS, FTP, FTP_GET, FTP_PUT, HTTP,
HTTPS, IMAP, MYSQL, NTP, OSPF, PING, POP3, SMTP, SSH, SYSLOG, and
TRACEROUTE.
5 Select OK.
7 Name the group BGP_Services.
8 Move the following services to the right list: BGP, DNS, FTP, FTP_GET, FTP_PUT,
HTTP, HTTPS, IMAP, MYSQL, NTP, PING, POP3, SMTP, SSH, SYSLOG, and
TRACEROUTE.
9 Select OK.

01-420-99686-20101026 1381
To configure firewall service groups - CLI

edit "BGP_services"
set member “BGP”, "DHCP" "DNS" "FTP" "FTP_GET" "FTP_PUT"
"HTTP" "HTTPS" "IMAP" "MYSQL" "NTP" "PING" "POP3" "SMTP"
"SSH" "TRACEROUTE" "SYSLOG"
next
edit "OSPF_services"
set member "DHCP" "DNS" "FTP" "FTP_GET" "FTP_PUT" "HTTP"
"HTTPS" "IMAP" "MYSQL" "NTP" "PING" "POP3" "SMTP" "SSH"
"TRACEROUTE" "SYSLOG" "OSPF"
next
end
Configuring the FortiGate unit - BGP

The only change from the standard BGP configuration for this example is configuring the
blocking Peer 1’s routes from being advertised to Peer 2. From the network topology you
can guess that both of these peers likely share many routes in common and it makes no
sense to advertise unneeded routes.
Blocking Peer 1’s routes to Peer 2 is done with distribute-list-out keyword. They allow you
to select which routes you will advertise to a neighbor using an access list. In this case we
will block all incoming routes from Peer 1 when we send updates to Peer 2. Otherwise
Peer 1 and Peer 2 are regular neighbors.
The FortiGate unit will redistribute routes learned from OSPF into BGP.
This is advanced configuration and the commands are only available in the CLI.
To create access list to block Peer 1 - CLI

config access-list
edit “block_peer1”
config rule
edit 1
set prefix 172.21.111.0 255.255.255.0
set action deny
end
end
end

1382 01-420-99686-20101026
To configure BGP on the FortiGate unit - CLI

config router bgp
set as 65001
config redistribute ospf
set status enable
end
config neighbor
edit 172.22.222.5
set remote_as 65001
set distribute-list-out “block_peer1”
next
edit 172.21.111.5
set remote_as 65001
end
end
Configuring the FortiGate unit - OSPF

This configuration involves only one OSPF Area, so all traffic will be intra-area. If there
were two or more areas with traffic going between them it would be inter-area traffic.
These two types are comparable to BGP’s traffic within one AS (iBGP) or between
multiple ASes (eBPG). Redistributing routes from OSPF to BGP is considered external
because either the start or end point is a different routing protocol.
The OSPF configuration is basic apart from redistributing BGP routes learned.
To configure OSPF on the FortiGate unit - web-based manager

1 Go to Router > Dynamic > OSPF.
2 For Router ID enter 10.11.201.110.
3 Under Advanced Options and Redistribute, select BGP and set BGP metric to 1.
4 For Areas, select Create New.
5 Enter 0.0.0.0 for the IP.
6 Select Regular area Type.
7 Select none for Authentication, and select OK.
9 Enter 10.11.201.0/255.255.255.0 for IP/Netmask, and select OK.
10 For Interfaces, select Create New.
11 Enter OSPF_dmz_network for Name.
12 Select port1(dmz) for Interface, and select OK.
To configure OSPF on the FortiGate unit - CLI

config router ospf
config area
edit 0.0.0.0
set type regular
set authentication none
end
config network
edit 1
set area 0.0.0.0

01-420-99686-20101026 1383
set prefix 10.11.201.0 255.255.255.0

end
config interface
edit “OSPF_dmz_network”
set interface port1(dmz)
set status enable
end
config redistribute bgp
set status enable
set metric 1
end
end

As with all BGP configurations, the peer routers will need to be updated with the FortiGate
unit’s BGP information including IP address, AS number, and what capabilities are being
used such as IPv6, graceful restart, BFD, and so on.
Testing network configuration

Testing this configuration involves the standard connectivity checks, but also ensuring that
routes are being passed between protocols as expected.
Check the routing table on the FortiGate unit to ensure that routes from both OSPF and
BGP are present.
Check the routing table on devices on the OSPF network for routes redistributed from
BGP. Also check those devices for connectivity to the Internet.
Check the routing table on Peer 2 to ensure no routes from Peer 1 are present, but routes
from the internal OSPF network are present.
For help with troubleshooting, see “” on page 1307, or “Troubleshooting BGP” on
page 1360.

1384 01-420-99686-20101026
Open Shortest Path First (OSPF)
This section describes how to . It also describes how to .
• OSPF Background and concepts
• Troubleshooting OSPF
• OSPF routing examples
OSPF Background and concepts

• Background
• The parts and terminology of OSPF
• How OSPF works
Background
OSPF is a link-state interior routing protocol, that is widely used in large enterprise
organizations. It only routes packets within a single autonomous system (AS). This is
different from BGP as BGP can communicate between ASes.
The main benefit of OSPF is that it detects link failures in the network quickly and within
seconds has converged network traffic successfully without any networking loops. Also
OSPF has many features to control which routes are propagated and which are not,
maintaining smaller routing tables. OSPF can also provide better load-balancing on
external links than other interior routing protocols.
OSPF version 2 was defined in 1998 in RFC 2328. OSPF was designed to support
classless IP addressing, and variable subnet masks. This was a shortcoming of the earlier
RIP protocols.
Updates to OSPF version 2 are included in OSPF version 3 defined in 2008 in RFC 5340.
OSPF3 includes support for IPv6 addressing where previously OSPF2 only supports IPv4
addressing.
The parts and terminology of OSPF

Parts and terminology of OSPF includes:
• OSPF and IPv6
• Router ID
• Adjacency
• Designated router (DR) and backup router (BDR)
• Area
• Authentication
• Hello and dead intervals

01-420-99686-20101026 1385
OSPF Background and concepts Open Shortest Path First (OSPF)
OSPF and IPv6

OSPF version 3 includes support for IPv6. Generally all IP addresses are in IPv6 format
instead of IPv4.
OSPF3 area numbers use the same 32-bit numbering system as OSPF2.
Router ID
In OSPF, each router has a unique 32-bit number called its Router ID. Often this 32-bit
number is written the same as a 32-bit IPv4 address would be written in dotted decimal
notation. However some brands of routers, such as Cisco routers, support a router ID
entered as an integer instead of an IP address.
It is a good idea to not use IP address in use on the router for the router ID number. The
router ID does not have to be a particular IP address on the router. By choosing a different
number, it will be harder to get confused which number you are looking at. A good idea
can be to use the as much of the area's number as possible. For example if you have 15
routers in area 0.0.0.0 they could be numbered from 0.0.0.1 to 0.0.0.15. If you have an
area 1.1.1.1, then routers in that area could start at 1.1.1.10 for example.
You can manually set the router ID on your FortiGate unit.
To manually set an OSPF router ID of 0.0.1.1 - web-based manager

1 Go to Router > Dynamic > OSPF.
2 For Router ID, enter 0.0.1.1.
3 Select OK.
To manually set an OSPF router ID of 0.0.1.1 - CLI

config router ospf
end
Adjacency
In an OSPF routing network, when an OSPF router boots up it sends out OSPF Hello
packets to find any neighbors, or routers that have access to the same network as the
router booting up. Once neighbors are discovered and Hello packets are exchanged,
updates are sent, and the Link State databases of both neighbors are synchronized. At
this point these neighbors are said to be adjacent.
For two OSPF routers to become neighbors, the following conditions must be met.
• The subnet mask used on both routers must be the same subnet.
• The subnet number derived using the subnet mask and each router's interface IP
address must match.
• The Hello interval & The Dead interval must match.
• The routers must have the same OSPF area ID. If they are in different areas, they are
not neighbors.
• If authentication is used, they must pass authentication checks.
If any of these parameters are different between the two routers, the routers do not
become OSPF neighbors and cannot be adjacent. If the routers become neighbors, they
are adjacent.

1386 01-420-99686-20101026
Open Shortest Path First (OSPF) OSPF Background and concepts
Adjacency and neighbors

Neighbor routers can be in a Two-Way state, and not be adjacent. Adjacent routers
normally have a neighbour state of FULL. Neighbors only exchange Hello packets, and do
not exchange routing updates. Adjacent routers exchange LSAs (LSDB information) as
well as Hello packets. A good example of an adjacent pair of routers is the DR and BDR.
You can check on the state of an OSPF neighbor using the CLI command get router
info ospf neighbor all. See “Checking the state of OSPF neighbors” on
page 1396.
Why adjacency is important

It is important to have adjacent pairs of routers in the OSPF routing domain because
routing protocol packets are only passed between adjacent routers. This means adjacency
is required for two OSPF routers to exchange routes. If there is no adjacency between two
routers, such as one on the 172.20.120.0 network and another on the 10.11.101.0
network, the routers do not exchange routes. This makes sense because if all OSPF
routers on the OSPF domain exchanged updates it would flood the network. Also its better
for updates to progress through adjacent routers to ensure there are no outages along the
way. Otherwise updates could skip over routers that are potentially offline, causing longer
routing outages and delays while the OSPF domain learns of this outage later on.
If the OSPF network has multiple border routers and multiple connections to external
networks, the designated router (DR) determines which router pairs become adjacent.
The DR can accomplish this because it maintains the complete topology of the OSPF
domain, including which router pairs are adjacent. The BDR also has this information in
case the DR goes offline.
Designated router (DR) and backup router (BDR)

In OSPF a router can have a number of different roles to play.
A designated router (DR) is the designated broadcasting router interface for an AS. It
looks after all the initial contact and other routing administration traffic. Having only one
router do all this greatly reduces the network traffic and collisions.
If something happens and the designated router goes offline, the backup designated
router (BDR) takes over. An OSPF FortiGate unit interface can become either a DR or
BDR. Both the DR and the BDR cover the same area, and are elected at the same time.
The election process doesn’t have many rules, but the exceptions can become complex.
Benefits
The OSPF concept of the designated router is a big step above RIP. With all RIP routers
doing their own updates all the time, RIP suffers from frequent and sometimes
unnecessary updates that can slow down your network. With OSPF, not only do routing
changes only happen when a link-state changes instead of any tiny change to the routing
table, but the designated router reduces this overhead traffic even more.
However, smaller network topologies may only have a couple routers besides the
designated router. This may seem excessive, but it maintains the proper OSPF form and it
will still reduce the administration traffic but to a lesser extent than on a large network.
Also your network topology is ready for when you expand your network.

01-420-99686-20101026 1387
DR and BDR election

An election chooses the DR and BDR from all the available routers. The election is
primarily based on the priority setting of the routers—the highest priority becomes the DR,
and the second highest becomes BDR. To resolve any ties, the router with the highest
router ID wins. For example 192.168.0.1 would win over 10.1.1.2.
The router priority can vary from 0 to 255, but at 0 a router will never become a DR or
BDR. If a router with a higher priority comes on line after the election, it must wait until
after the DR and BDR go offline before it would become the DR.
If the original DR goes offline, but then is available when the BDR goes offline later on, the
original DR will be promoted back to DR without an election leaving the new BDR as it is.
With your FortiGate unit, to configure the port1 interface to be a potential OSPF
designated router or backup designed router called ospf_DR on the network, you need to
raise the priority of the router to a very high number such as 250 out of 255. This will
ensure the interface has a chance to be a DR, but will not guarantee that it will be one.
Give the interface a low numbered IP address—such as 10.1.1.1 instead of 192.168.1.1—
to help ensure it becomes a DR, but that is not part of this example. Enter the following
command:
config router ospf
edit “ospf_DR”
set priority 250
end
end
Area
An OSPF area is a smaller part of the larger OSPF AS. Areas are used to limit the link-
state updates that are sent out. The flooding used for these updates would overwhelm a
large network, so it is divided into these smaller areas for manageability.
Within an area if there are two or more routers that are viable, there will always be a
designated router (DR) and a backup DR (BDR). For more on these router roles, see
“Designated router (DR) and backup router (BDR)” on page 1387.
Defining a private OSPF area, involves:
• assigning a 32-bit number to the area that is unique on your network
• defining the characteristics of one or more OSPF areas
• creating associations between the OSPF areas that you defined and the local networks
to include in the OSPF area
• if required, adjusting the settings of OSPF-enabled interfaces.
Note: IPv6 OSPF area numbers use the same 32-bit number notation as IPv4 OSPF.
If you are using the web-based manager to perform these tasks, follow the procedures
summarized below.

1388 01-420-99686-20101026
FortiGate units support the four main types of OSPF area:

• Backbone area
• NSSA
• Stub area
• Regular area
Backbone area
Every OSPF network has at least one AS, and every OSPF network has a backbone area.
The backbone is the main area, or possibly the only area. All other OSPF areas are
connected to a backbone area. This means if two areas want to pass routing information
back and forth, that routing information will go through the backbone on its way between
those areas. For this reason the backbone not only has to connect to all other areas in the
network, but also be uninterrupted to be able to pass traffic to all points of the network.
The backbone area is referred to as area 0 because it has an IP address of 0.0.0.0.
Stub area
A stub area is an OSPF area that receives no outside routes advertised into it, and all
routing in it is based on a default route. This essentially isolates it from outside areas.
Stub areas are useful for small networks that are part of a larger organization, especially if
the networking equipment can’t handle routing large amounts of traffic passing through, or
there are other reasons to prevent outside traffic, such as security. For example most
organizations don’t want their accounting department to be the center of their network with
everyone’s traffic passing through there. It would increase the security risks, slow down
their network, and it generally doesn’t make sense.
A variation on the stub area is the totally stubby area. It is a stub area that does not allow
summarized routes.
NSSA
A not-so-stubby-area (NSSA) is a stub area that allows for external routes to be injected
into it. While it still does not allow routes from external areas, it is not limited to only using
he default route for internal routing.
Regular area
A regular area is what all the other ASes are, all the non-backbone, non-stub, non-NSSA
areas. A regular area generally has a connection to the backbone, does receive
advertisements of outside routes, and does not have an area number of 0.0.0.0.
Authentication
In the OSPF packet header are two authentication related fields —AuType, and
Authentication.
All OSPF packet traffic is authenticated. Multiple types of authentication are supported in
OSPFv2. However in OSPFv3, there is no authentication built-in but it is assumed that
IPSec will be used for authentication instead.
Packets that fail authentication are discarded.
Null authentication
Null authentication indicates there is no authentication being used. In this case the 16-byte
Authentication field is not checked, and can be any value. However checksumming is still
used to locate errors. On your FortiGate this is the none option for authentication.

01-420-99686-20101026 1389
Simple Password authentication

Simple password refers to a standard plain text string of characters. The same password
is used for all transactions on a network. The main use of this type of authentication is to
prevent routers from accidently joining the network. Simple password authentication is
vulnerable to many forms of attack, and is not recommended as a secure form of
authentication.
Cryptographic authentication
Cryptographic authentication involves the use of a shared secret key to authenticate all
router traffic on a network. The key is never sent over the network in the clear—a packet is
sent and a condensed and encrypted form of the packet is appended to the end of the
packet. A non-repeating sequence number is included in the OSPF packet to protect
against replay attacks that could try to use already sent packets to disrupt the network.
When a packet is accepted as authentic the authentication sequence number is set to the
packet sequence number. If a replay attack is attempted, the packet sent will be out of
sequence and ignored.
Your FortiGate unit supports all three levels of authentication through the authentication
keyword associated with creating an OSPF interface .
For example to create an OSPF interface called Accounting on the port1 interface that
is a broadcast interface, has a hello interval of 10 seconds, has a dead interval of 40
seconds, uses text authentication (simple password) with a password of “ospf_test”, enter
the command:
config router ospf
edit Accounting
set interface port1
set network_type broadcast
set hello_interval 10
set dead_interval 40
set authentication text
set authentication-key “ospf_test”
end
end
Hello and dead intervals

The OSPF Hello protocol is used to discover and maintain communications with
neighboring routers.
Hello packets are sent out at a regular interval for this purpose. The DR sends out the
Hello packets. In a broadcast network, the multicast address of 224.0.0.5 is used to send
out Hello packets. New routers on the network listen for and reply to these packets to join
the OSPF area. If a new router never receives a Hello packet, other routers will not know it
is there and will not communicate with it. However, once a new router is discovered the
DR adds it to the list of routers in that area and it is integrated into the routing calculations.
Dead interval is the time it takes when a router doesn’t respond before it is declared dead,
or offline. If this interval is too short routers will be declared offline when they aren’t and
the link-state updates will happen more than they need to. If the dead interval is too long, it
will slow down network traffic while that router it attempted to be contacted when it is
already offline.

1390 01-420-99686-20101026
How OSPF works

An OSPF network one or more areas. An OSPF area is typically divided into logical areas
linked by Area Border Routers. A group of contiguous networks form an area. An Area
Border Router (ABR) links one or more areas to the OSPF network backbone (area ID 0).
See “Area border router (ABR)” on page 1305.
OSPF is an interior routing protocol. It includes a backbone AS, and possibly additional
ASes. The DR and BDR are elected from potential routers with the highest priorities. The
DR handles much of the administration to lower the network traffic required. New routers
are discovered through hello packets sent from the DR using the multicast address of
224.0.0.5. If the DR goes offline at any time, the BDR has a complete table of routes that
is uses when it takes over as the DR router.
OSPF does not use UDP or TCP, but is encapsulated directly in IP datagrams as protocol
89. This is in contrast to RIP, or BGP. OSPF handles its own error detection and correction
functions.
The OSPF protocol, when running on IPv4, can operate securely between routers,
optionally using a variety of authentication methods to allow only trusted routers to
participate in routing. OSPFv3, running on IPv6, no longer supports protocol-internal
authentication. Instead, it relies on IPv6 protocol security (IPsec).
Other important parts of how OSPF works includes:
• OSPF router discovery
• How OSPF works on FortiGate units
• External routes
• Link-state Database (LSDB) and route updates
• OSPF packets
OSPF router discovery

OSPF-enabled routers generate Link-State Advertisements (LSA) and send them to their
neighbors whenever the status of a neighbor changes or a new neighbor comes online. As
long as the OSPF network is stable, LSAs between OSPF neighbors do not occur. An LSA
identifies the interfaces of all OSPF-enabled routers in an area, and provides information
that enables OSPF-enabled routers to select the shortest path to a destination. All LSA
exchanges between OSPF-enabled routers are authenticated.
When a network of OSPF routers comes online, the follow steps occur.
1 When OSPF routers come online, they send out Hello packets to find other OSPF
routers on their network segment.
2 When they discover other routers on their network segment, generally they become
adjacent. Adjacent routers can exchange routing updates. See “Adjacency” on
page 1386.
3 A DR and BDR are elected from the available routers using priority settings, and router
ID. See “Designated router (DR) and backup router (BDR)” on page 1387, and “DR
and BDR election issues” on page 1398.
4 Link state updates are sent between adjacent routers to map the topology of the OSPF
area.
5 Once complete, the DR floods the network with the updates to ensure all OSPF routers
in the area have the same OSPF route database. After the initial update, there are very
few required updates if the network is stable..

01-420-99686-20101026 1391
How OSPF works on FortiGate units

When a FortiGate unit interface is connected to an OSPF area, that unit can participate in
OSPF communications. FortiGate units use the OSPF Hello protocol to acquire neighbors
in an area. A neighbor is any router that is directly connected to the same area as the
FortiGate unit, and ideally is adjacent with a state of Full. After initial contact, the FortiGate
unit exchanges Hello packets with its OSPF neighbors regularly to confirm that the
neighbors can be reached.
The number of routes that a FortiGate unit can learn through OSPF depends on the
network topology. A single unit can support tens of thousands of routes if the OSPF
network is configured properly.
External routes
OSPF is an internal routing protocol. OSPF external routes are routes with the destination
of the connection using a routing protocol other than OSPF. OSPF handles external routes
by adjusting the cost of the route to include the cost of the other routing protocol. There
are two methods of calculating this cost, used for OSPF E1 and OSPF E2.
OSPF external1 (E1)

In OSPF E1 the destination is outside of the OSPF domain. This requires a different metric
to be used beyond the normal OSPF metrics. The new metric of a redistributed route is
calculated by adding the external cost and the OSPF cost together.
OSPF external2 (E2)

OSPF E2 is the default external type when routes are redistributed outside of OSPF.
OSPF E2 is similar to E1, except in this case, the metric of the redistributed route is
equivalent to the external cost only, expressed as an OSPF cost. Dropping the OSPF
portion can be useful in a number of situations, on border routers that have no OSPF
portion for example or where the OSPF routing cost is negligible compared to the external
routing cost.
Comparing E1 and E2
The best way to understand OSPF E1 and E2 routes is to check routing tables on OSPF
routers. If you look at the routes on an OSPF border router, the redistributed routes will
have an associated cost that represents only the external route, as there is no OSPF cost
to the route due to it already being on the edge of the OSPF domain. However, if you look
at that same route on a different OSPF router inside the OSPF routing domain, it will have
a higher associated cost - essentially the external cost plus the cost over the OSPF
domain to that border router. The border router uses OSPF E2, where the internal OSPF
router uses OSPF E2 for the same route.
Viewing external routes

When you are trying to determine the costs for routes in your network to predict how traffic
will be routed, you need to see the external OSPF routes and their associated costs. On
your FortiGate unit, you find this information through your CLI.
To view external routes - CLI

You can view the whole routing table using get router info routing-table
all to see all the routes including the OSPF external routes, or for a shorter list you
can use the command get router info routing-table ospf. The letter at the
left will be either E1 or E2 for external OSPF routes. The output of will look similar to
the following, depending on what routes are in your routing table.

1392 01-420-99686-20101026
FGT620B# get router info routing-table all

Codes: K - kernel, C - connected, S - static, R - RIP, B - BGP
O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS
inter area
* - candidate default
O*E2 0.0.0.0/0 [110/10] via 10.1.1.3, tunnel_wan2, 00:02:11

O 10.0.0.1/32 [110/300] via 10.1.1.3, tunnel_wan2, 00:02:11
S 0.0.0.0/0 [10/0] via 192.168.183.254, port2
S 1.0.0.0/8 [10/0] via 192.168.183.254, port2
Link-state Database (LSDB) and route updates

OSPF is based on links. The links between adjacent neighbor routers allow updates to be
passed along the network. Network links allow the DR to flood the area with Link-state
database (LSDB) updates. External links allow the OSPF area to connect to destinations
outside the OSPF autonomous system. Information about these links is passed
throughout the OSPF network as link-state updates.
The LSDB contains the information that defines the complete OSPF area, but the LSDB is
not the routing table. It contains the information from all the link-state updates passed
along the network. When there are no more changes required, and the network is stable
then the LSDB on each router in the network will be the same. The DR will flood the LSDB
to the area to ensure each router has the same LSDB.
To calculate the best route (shortest path) to a destination, the FortiGate unit applies the
Shortest Path First (SPF) algorithm — based on Dijkstra’s algorithm — to the accumulated
link-state information. OSPF uses relative path cost metric for choosing the best route.
The path cost can be any metric, but is typically the bandwidth of the path—how fast traffic
will get from one point to another.
The path cost, similar to “distance” for RIP, imposes a penalty on the outgoing direction of
a FortiGate unit interface. The path cost of a route is calculated by adding together all of
the costs associated with the outgoing interfaces along the path to the destination. The
lowest overall path cost indicates the best route, and generally the fastest route. Some
brands of OSPF routers, such as Cisco, implement cost as a direct result of bandwidth
between the routers. Generally this is a good cost metric because larger bandwidth means
more traffic can travel without slowing down. To achieve this type of cost metric on
FortiGate units, you need to set the cost for each interface manually in the CLI.
Note: The inter-area routes may not be calculated when a Cisco type ABR has no fully
adjacent neighbor in the backbone area. In this situation, the router considers summary-
LSAs from all Actively summary-LSAs from all Actively Attached areas (RFC 3509).

01-420-99686-20101026 1393
The FortiGate unit dynamically updates its routing table based on the results of the SPF
calculation to ensure that an OSPF packet will be routed using the shortest path to its
destination. Depending on the network topology, the entries in the FortiGate unit routing
table may include:
• the addresses of networks in the local OSPF area (to which packets are sent directly)
• routes to OSPF area border routers (to which packets destined for another area are
sent)
• if the network contains OSPF areas and non-OSPF domains, routes to area boundary
routers, which reside on the OSPF network backbone and are configured to forward
packets to destinations outside the OSPF AS.
OSPF Route updates

Once the OSPF domain is established, there should be few updates required on a stable
network. When updates occur and a decision is required concerning a new route, this is
the general procedure.
1 Our router gets a new route, and needs to decide if it should go in the routing table.
2 The router has an up to date LSDB of the entire area, containing information about
each router, the next hop to it, and most importantly the cost to get there.
3 Our router, turns the LSDB into a shortest path first (SPF) tree using Dijkstra’s
algorithm. It doesn’t matter if there is more than one path to a router on the network,
the SPF tree only cares about the shortest path to that router.
4 Once the SPF tree has been created, and shows the shortest paths to all the OSPF
routers on the network, the work is done. If the new route is the best route, it will be
part of that tree. If it is not the shortest route, it will not be included in the LSDB.
5 If there has been a change from the initial LSDB to the new SPF tree, a link state
update will be sent out to let the other routers know about the change so they can
update their LSDBs as well. This is vital since all routers on the OSPF area must have
the same LSDB.
6 If there was no change between the LSDB and the SPF tree, no action is taken.
OSPF packets
Every OSPF packet starts with a standard 24-byte header, and another 24 bytes of
information or more. The header contains all the information necessary to determine
whether the packet should be accepted for further processing.
Table 85: OSPF packet
1-byte Version field 1-byte Type field 2-byte Packet length 3-byte Router ID
4-byte Area ID 2-byte Checksum 2-byte Auth Type 8-byte Authentication
4-byte Network Mask 2-bye Hello interval 1-byte Options field 1-byte Router Priority
4-byte Dead Router 4-byte DR field 4-byte BDR field 4-byte Neighbor ID

Fortios Handbook 40 Mr2

Enviado por

Dados do documento

Descrição original:

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Fortios Handbook 40 Mr2

Enviado por

Direitos autorais:

Formatos disponíveis

FortiOS™ Handbook v2

for FortiOS 4.0 MR2

Chapter 1 What’s New 99

Chapter 2 FortiGate Fundamentals 175

Chapter 3 System Administration 331

Chapter 4 Logging and Reporting 569

Chapter 5 Troubleshooting 629

for FortiOS 4.0 MR2

Chapter 6 UTM Guide 735

Chapter 7 User Authentication 895

Chapter 8 IPsec VPNs 983

Chapter 9 SSL VPNs 1175

Chapter 10 Advanced Routing 1265

for FortiOS 4.0 MR2

Chapter 11 Virtual Domains 1423

Chapter 12 High Availability 1533

Chapter 13 Endpoint 1783

Chapter 14 Traffic Shaping 1809

Chapter 15 FortiOS Carrier 1845

Chapter 16 Deploying Wireless Networks 1977

Chapter 17 VoIP Solutions: SIP 2035

for FortiOS 4.0 MR2

Chapter 19 Load Balancing 2251

Chapter 20 Hardware 2291

Chapter 21 Certifications and Compliances 2365

Index ................................................................................................... 2403

for FortiOS 4.0 MR2

Chapter 1 What’s New 99

Firmware upgrade practices 103

Web-based manager 109

FortiOS software enhancements 115

FortiOS 4.0 MR2

SIP features available on all FortiGate models . . . . . . . . . . . . . . . . . . . . . 118

High availability 135

FortiOS 4.0 MR2

WAN Opt. & Cache 159

FortiOS Carrier 161

Logging and reporting 167

Chapter 2 FortiGate Fundamentals 175

The Purpose of a Firewall 177

Life of a Packet 189

Proxy inspection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191

Firewall components 201

FortiOS 4.0 MR2

Firewall Policies 231

Firewall policy examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244

Configuration Examples 261

Concept Example: Small Office Network Protection 263

FortiOS 4.0 MR2

Configuring settings for Finance and Engineering departments . . . . . . . . . . . . 272

Concept Example: Library Network Protection 299

Configuring the main office . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304

Chapter 3 System Administration 331

Basic setup 333

FortiOS 4.0 MR2

Configuring NAT mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334

Centralized management 359

Using the CLI 365

Tightening security 385

FortiOS 4.0 MR2

Best Practices 391

Multicast forwarding 429

FortiOS 4.0 MR2