Fortigate Fundamentals 40 mr2

FortiGate Fundamentals
FortiOS™ Handbook v2
for FortiOS 4.0 MR2
FortiOS™ Handbook: FortiGate Fundamentals
v2
13 October 2010
01-40002-112804-20101008
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
Introduction 11
Before you begin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
How this guide is organized . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Document conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
IP addresses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Example Network configuration . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Cautions, Notes and Tips . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Typographical conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
CLI command syntax conventions . . . . . . . . . . . . . . . . . . . . . . . . . 16
Entering FortiOS configuration data . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Entering text strings (names). . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Entering numeric values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Selecting options from a list . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Enabling or disabling options. . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Registering your Fortinet product. . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Fortinet products End User License Agreement . . . . . . . . . . . . . . . . . . . . 20
Training . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Fortinet Tools and Documentation CD . . . . . . . . . . . . . . . . . . . . . . . 20
Fortinet Knowledge Base. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Comments on Fortinet technical documentation . . . . . . . . . . . . . . . . . 20
Customer service and technical support . . . . . . . . . . . . . . . . . . . . . . . . 20
The Purpose of a Firewall 23

Firewall features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Antivirus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Web Filtering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Spyware/Grayware. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Phishing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Pharming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Instant messaging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Peer-to-peer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Streaming media . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Blended network attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Antispam/Email Filter. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Email filter techniques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Intrusion Protection. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Traffic Shaping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
FortiOS™ Handbook v2: FortiGate Fundamentals

01-40002-112804-20101015 3
http://docs.fortinet.com/ • Feedback
Contents
NAT vs. Transparent Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

NAT mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
How address translation works . . . . . . . . . . . . . . . . . . . . . . . . 30
Central NAT table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Transparent mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Operating mode differences . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Life of a Packet 35
Stateful inspection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Flow inspection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Proxy inspection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
FortiOS functions and security layers . . . . . . . . . . . . . . . . . . . . . . . . . 37
Packet flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Packet inspection (Ingress) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
DoS sensor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
IP integrity header checking . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
IPsec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Destination NAT (DNAT) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Policy lookup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Session tracking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
User authentication. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Management traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
SSL VPN traffic. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Session helpers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Flow-based inspection engine . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Proxy-based inspection engine. . . . . . . . . . . . . . . . . . . . . . . . . . . 41
IPsec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Source NAT (SNAT) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Egress . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Transparent mode routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Example 1: client/server connection . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Example 2: Routing table update . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Example 3: Dialup IPsec with application control. . . . . . . . . . . . . . . . . . . . 45
Firewall components 49
Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Physical . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Administrative access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Wireless . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Aggregate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
FortiGate Fundamentals for FortiOS 4.0 MR2

4 01-40002-112804-20101015
Contents
Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Virtual domains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Virtual LANs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Zones. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Addressing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Wildcard firewall addresses . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Adding a firewall wildcard address . . . . . . . . . . . . . . . . . . . . . . . 61
Fully Qualified Domain Name addresses . . . . . . . . . . . . . . . . . . . . . 61
Virtual IPs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
Inbound connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
Outbound connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Virtual IP, load balance virtual server / real server limitations . . . . . . . . . 66
Address groups. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
DHCP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
IP pools. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
IP Pools for firewall policies that use fixed ports . . . . . . . . . . . . . . . . . . 70
Source IP address and IP pool address matching . . . . . . . . . . . . . . . . . 70
IPv6. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
The routing table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
How routing decisions are made . . . . . . . . . . . . . . . . . . . . . . . . . 73
Multipath routing and determining the best route . . . . . . . . . . . . . . . . . 73
Route priority . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
Static route . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
Default route and default gateway . . . . . . . . . . . . . . . . . . . . . . . . . 74
Changing the gateway for the default route . . . . . . . . . . . . . . . . . . 76
Adding a static route . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Policy Route . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Type of Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
Originating traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
Receiving traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
Closing specific ports to traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

01-40002-112804-20101015 5
Contents
Port 113 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
Port 541 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
Custom service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
Schedules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
Schedule groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
UTM profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
Profiles and sensors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
Firewall Policies 89
Policy order . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
Denial of Service policies. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
Rearranging policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
Firewall policy 0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
Firewall policy list details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
Creating basic policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
Using an interface of “any” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
Basic accept policy example . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
Basic deny policy example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
Basic VPN policy example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
DoS Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
Basic DoS policy example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
Sniffer Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
Basic one-armed sniffer policy example . . . . . . . . . . . . . . . . . . . . . . 97
Identity-based Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
Identity-based policy example . . . . . . . . . . . . . . . . . . . . . . . . . 99
Identity-based policy positioning . . . . . . . . . . . . . . . . . . . . . . . . . . 100
Identity-based sub-policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
ICMP packet processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
Firewall policy examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
Blocking an IP address . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
Add an Address . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
Add a Firewall Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
Scheduled access policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
Configuring the schedules . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
Configuring the IP addresses . . . . . . . . . . . . . . . . . . . . . . . . . 104
Configuring the firewall policies . . . . . . . . . . . . . . . . . . . . . . . . 105

6 01-40002-112804-20101015
Contents
Troubleshooting 109
Basic policy checking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
Default gateway . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
Verifying traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
Using log messages to view violation traffic . . . . . . . . . . . . . . . . . . . . . . 110
Traffic trace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
Session table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
Sample output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
Finding object dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
Sample output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
Flow trace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
Sample output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
Flow trace output example - HTTP . . . . . . . . . . . . . . . . . . . . . . . . . 114
Packet sniffer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
Simple trace example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
Simple trace example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
Verbose levels 2 and 3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
Trace with filters example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
Configuration Examples 119

Exempted URLs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
Create a local category. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
Add URLs to the category . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
Enable the category in web filtering . . . . . . . . . . . . . . . . . . . . . . . . 120
Test it . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
Concept Example: Small Office Network Protection 121

Example small office network. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
Network management and protection requirements . . . . . . . . . . . . . . . . 122
Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
Features used in this example . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
First steps. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
Configuring FortiGate network interfaces . . . . . . . . . . . . . . . . . . . . . 124
Adding the default route . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
. . . . . . . . . . . . . . . . . . . . . . . . Removing the default firewall policy 126
Configuring DNS forwarding . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
Setting the time and date. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
Registering the FortiGate unit . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
Scheduling automatic antivirus and attack definition updates . . . . . . . . . . . 128
Configuring administrative access and passwords. . . . . . . . . . . . . . . . . 128

01-40002-112804-20101015 7
Contents
Configuring settings for Finance and Engineering departments . . . . . . . . . . . . 130

Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
Adding the Finance and Engineering department addresses . . . . . . . . . . . 130
Configuring web category block settings . . . . . . . . . . . . . . . . . . . . . . 131
Configuring FortiGuard spam filter settings . . . . . . . . . . . . . . . . . . . . 131
Configuring antivirus grayware settings . . . . . . . . . . . . . . . . . . . . . . 132
Configuring a corporate set of UTM profiles . . . . . . . . . . . . . . . . . . . . 132
Antivirus UTM profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
Web filter UTM profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
Email filter UTM profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
Configuring firewall policies for Finance and Engineering . . . . . . . . . . . . . 134
Important points for firewall policy configuration . . . . . . . . . . . . . . . . 134
Configuring settings for the Help Desk department . . . . . . . . . . . . . . . . . . 135
Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
Adding the Help Desk department address . . . . . . . . . . . . . . . . . . . . 136
Creating and Configuring URL filters . . . . . . . . . . . . . . . . . . . . . . . . 136
Web filter UTM profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
Ordering the filtered URLs . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
Application control or IM and P2P . . . . . . . . . . . . . . . . . . . . . . . 139
Creating a recurring schedule . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
Configuring firewall policies for help desk . . . . . . . . . . . . . . . . . . . . . 140
Configuring remote access VPN tunnels . . . . . . . . . . . . . . . . . . . . . . . . 142
Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
Adding addresses for home-based workers . . . . . . . . . . . . . . . . . . . . 142
Configuring the FortiGate end of the IPSec VPN tunnels . . . . . . . . . . . . . 143
Configuring firewall policies for the VPN tunnels . . . . . . . . . . . . . . . . . . 145
Configuring the FortiClient end of the IPSec VPN tunnels . . . . . . . . . . . . . 147
Configuring the web server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
Configuring the FortiGate unit with a virtual IP . . . . . . . . . . . . . . . . . . . 148
Adding the web server address . . . . . . . . . . . . . . . . . . . . . . . . . . 148
Configuring firewall policies for the web server . . . . . . . . . . . . . . . . . . 149
wan1 -> dmz1 policies. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
dmz1 -> wan1 policies. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
dmz1 -> internal policies . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
internal -> dmz1 policies . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
Configuring the email server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
Configuring the FortiGate unit with a virtual IP . . . . . . . . . . . . . . . . . . . 151
Adding the email server address . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
Configuring firewall policies for the email server . . . . . . . . . . . . . . . . . . 152
dmz1 -> wan1 policies. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
wan1 -> dmz1 policies. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
dmz1 -> internal policies . . . . . . . . . . . . . . . . . . . . . . . . . . . 154

8 01-40002-112804-20101015
Contents
internal -> dmz1 policies . . . . . . . . . . . . . . . . . . . . . . . . . . . 154

ISP web site and email hosting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
The Example Corporation internal network configuration . . . . . . . . . . . . . . . 156
Other features and products for SOHO. . . . . . . . . . . . . . . . . . . . . . . . . 156
Concept Example: Library Network Protection 159

Current topology and security concerns . . . . . . . . . . . . . . . . . . . . . . . . 159
Library requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
The library’s decision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
Proposed topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
Features used in this example . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
Network addressing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
Configuring the main office . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
High Availability (HA) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
Configuring HA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
FortiGuard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
IPsec VPN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
Configuring IPsec VPNs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
IP Pools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
Configuring IP pools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
User Disclaimer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
Configuring the user disclaimer . . . . . . . . . . . . . . . . . . . . . . . . 170
Protection Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
Staff access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
Creating firewall policy for staff members . . . . . . . . . . . . . . . . . . . 174
Catalog terminals. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
Creating firewall policies for catalog terminals . . . . . . . . . . . . . . . . . 176
Public access terminals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
Creating firewall policies for public access terminals . . . . . . . . . . . . . 177
Wireless access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
Security considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
Creating schedules for wireless access . . . . . . . . . . . . . . . . . . . . 178
Creating firewall policies for WiFi access . . . . . . . . . . . . . . . . . . . 180
Mail and web servers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
Creating a virtual IP for the web server . . . . . . . . . . . . . . . . . . . . 181
Creating a virtual IP for the email server . . . . . . . . . . . . . . . . . . . . 182
Creating a server service group . . . . . . . . . . . . . . . . . . . . . . . . 183
Creating firewall policies to protect email and web servers . . . . . . . . . . 183
The FortiWiFi-80CM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
Configuring the main office FortiWiFi-80CM. . . . . . . . . . . . . . . . . . 184

01-40002-112804-20101015 9
Contents
Configuring branch offices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185

Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
Staff access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
Catalog terminals. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
Wireless/public access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
Mail and web servers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
IPsec VPN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
Branch Firewall Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
Creating firewall policy for the branch office . . . . . . . . . . . . . . . . . . 188
Traffic shaping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
Priorities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
The future. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
Decentralization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
Staff WiFi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
Further redundancy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
Index 193

10 01-40002-112804-20101015
Introduction
Welcome and thank you for selecting Fortinet products for your network protection.
The firewall policies are the key component of FortiOS that allows, or disallows, traffic to
and from your network. It is through the firewall policies you define who, what and when
traffic goes between networks and the Internet.
This guide describes the firewall functionality of FortiOS 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 guide also describes both simple how to steps to configure the basic components,
and some more involved examples to demonstrate how firewall policies can be employed
within FortiOS. Finally, this guide also provides some troubleshooting advice should
problems arise when creating firewall policies.
Because of the magnitude of features, this guide will only touch the surface of traffic
shaping, Universal Threat Management (UTM) and profile information. Other guides are
available with more in depth content. For basic configuration to install the FortiGate unit on
the network, see the System Administration Guide.
This chapter contains the following topics:
• Before you begin
• Document conventions
• Registering your Fortinet product
• Fortinet products End User License Agreement
• Training
• Documentation
• Customer service and technical support
Before you begin

Before you begin ensure that:
• You have administrative access to the web-based manager and/or CLI.
• The FortiGate unit is integrated into your network.
• The operation mode has been configured.
• The system time, DNS settings, administrator password, and network interfaces have
been configured. For more information, see the Basic Setup chapter of the System
Administration Guide.
• Firmware, FortiGuard Antivirus and FortiGuard Antispam updates are completed.

01-40002-112804-20101015 11
Before you begin Introduction
How this guide is organized

This document describes firewall components, and how to implement firewall policies on
FortiGate units operating in both NAT/Route, and Transparent mode.
This guide contains the following chapters:
• 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.

12 01-40002-112804-20101015
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™ Handbook v2: Traffic Shaping

01-402-120097-201001008 9
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
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.
Traffic Shaping for FortiOS 4.0 MR2

10 01-402-120097-201001008
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 .1
T 1.1
10
FortiWiFi-80CM
01
.1
01
Windows PC
10.11.101.10
Internal network
10
.1
1.
P 10
10
or 2
1.
t2
P 2.2
P .11
or 0
or .
17
t 1 .1
10
t 2 10
(s 20
10
ni .1
Switch
.1
ff e 4 1
FortiGate-82C
1.
P .10
1
rm
FortiAnalyzer-100B
10
.1
or 0
30
od
t2
e)
10
.1
1.
P .11
10
or 0
t1
1
P 2.2
or 0
3)
17
t 1 .1
d
an
2
rts
2
0.
FortiGate-620B
po
14
of
1
irr 8
HA cluster
(m rt
or
P nd
o
P
or 3
FortiMail-100C
t2
a
t1
or
P
Switch
H
ea
d
of
fic
e
P .21
or .
10
t 1 10
FortiGate-3810A
1.
10
Linux PC
1
17
10.21.101.10
2.
20
B
W .12
.1
ra
A 2
20
N
B
nc
1
ra
h
nc
of
h
fic
of
e
fic
In .31
te .1
10
e
rn 0
al 1.
FortiGate-51B
10
0
60
.1
1
.2 1
10
10 ort
1.
P
Windows PC
10.31.101.10
FortiManager-3000B
10 4
1. rt
10 Po
0
2.
Cluster
.2
10
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

01-402-120097-201001008 11
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.
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.

12 01-402-120097-201001008
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
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-402-120097-201001008 13
Entering FortiOS configuration data
Table 3: Command syntax notation (Continued)
Convention Description
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.

14 01-402-120097-201001008
Registering your Fortinet product
config firewall address

tree
-- [address] --*name (64)
|- subnet
|- type
|- start-ip
|- end-ip
|- 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.

01-402-120097-201001008 15
Fortinet products End User License Agreement
Fortinet products End User License Agreement

See the Fortinet products End User License Agreement.
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.

16 01-402-120097-201001008

17 01-402-120097-201001008

18 01-402-120097-201001008
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-40002-112804-20101015 23
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 Guide.
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

24 01-40002-112804-20101015
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-40002-112804-20101015 25
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 Guide.
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.

26 01-40002-112804-20101015
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 Guide.
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-40002-112804-20101015 27
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 Guide.
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.

28 01-40002-112804-20101015
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 FortiGate Traffic Shaping Guide.
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-40002-112804-20101015 29
NAT vs. Transparent Mode The Purpose of a Firewall
Figure 2: FortiGate unit in NAT mode
172
.20 WA
traf NAT .12 N 1
fic po 0.1
ext betw licies 29
P
ern ee 192 ort 1
al n n in contr
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 2, 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.

30 01-40002-112804-20101015
Figure 3: 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.

01-40002-112804-20101015 31
Figure 4: 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
3 e c e et ew
2 R ck 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 7 2
n: .5
l
10 0.
.1 20
0. .2
10 0
.2
WA 1
N 1 nt
3
2 Se et
c k
Pa
D So
es u
tin rce
at :
io 17
n: 2
17 .50
2. .2
20 0.
.1 20
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.
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 the System Admnistration Guide .
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.

32 01-40002-112804-20101015
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 5, 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.
Figure 5: 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 p
ext betw olicies
l
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.

01-40002-112804-20101015 33
To enable Transparent mode - CLI

config system settings
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 the System
Administration Guide .
Note: This guide and its examples are constructed with the FortiGate unit running in NAT
mode, unless otherwise noted.
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

34 01-40002-112804-20101015
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.
This chapter includes the following topics:
• Stateful inspection
• Flow inspection
• Proxy inspection
• FortiOS functions and security layers
• Packet flow
• Transparent mode routing
• Example 1: client/server connection
• Example 2: Routing table update
• Example 3: Dialup IPsec with application control
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-40002-112804-20101015 35
Flow inspection Life of a Packet
Figure 6: 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 7: 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.

36 01-40002-112804-20101015
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 8: 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 4: 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-40002-112804-20101015 37
Packet flow Life of a Packet
Table 4: 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 9 on page 39 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 9 on page 39, 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

38 01-40002-112804-20101015
Life of a Packet Packet flow
Figure 9: 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-40002-112804-20101015 39
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 30.
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.

40 01-40002-112804-20101015
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-40002-112804-20101015 41
Transparent mode routing 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.
Transparent mode routing

In transparent mode, the FortiGate unit acts as an IP forwarding bridge between
interfaces. All IP packets are handed off to the firewall module, which controls packet
forwarding. If a firewall policy accepts a packet, the packet is forwarded to the destination
interface specified in the firewall policy.
You can add firewall policies to accept IP packets and multicast packets. All other packets,
for example, IPX, Appletalk, and DecNet and so on, are blocked unless interface
configurations are changed to forward these types of packets.
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

42 01-40002-112804-20101015
Life of a Packet Example 1: client/server connection
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
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

01-40002-112804-20101015 43
Example 2: Routing table update Life of a Packet
Figure 10: 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
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

44 01-40002-112804-20101015
Life of a Packet Example 3: Dialup IPsec with application control
Figure 11: 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
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

01-40002-112804-20101015 45
Example 3: Dialup IPsec with application control Life of a Packet
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
Figure 12: 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

46 01-40002-112804-20101015

47 01-40002-112804-20101015

48 01-40002-112804-20101015
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.
The following topics are included in this section:
• Interfaces
• Addressing
• Routing
• 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 13: FortiGate-100A physical interfaces
4 3 2 1
DC+12V
Console Internal DMZ 2 DMZ 1 WAN 2 WAN 1

USB

01-40002-112804-20101015 49
Interfaces Firewall components
Figure 14: FortiGate-100A interfaces on the Dashboard
Figure 15: 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 16: FortiGate-3810A AMC card port naming

50 01-40002-112804-20101015
Firewall components Interfaces
For more information on configuring physical ports, see “Addressing” on page 57.
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

config system interface
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-40002-112804-20101015 51
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.

52 01-40002-112804-20101015
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-40002-112804-20101015 53
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 VODMs, the
FortiGate unit will log you out.
To enable VDOMs - web-based manager

1 Go to System > Dashboard > Status.
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

config system global
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

54 01-40002-112804-20101015
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-40002-112804-20101015 55
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 17: 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.

56 01-40002-112804-20101015
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-40002-112804-20101015 57
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.

58 01-40002-112804-20101015
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 firewall addresses

You can use wildcard firewall addresses to identify ranges of IP addresses, allowing you to
reduce the number of firewall addresses and policies required to match some of the traffic
on your network.
Wildcard firewall addresses are an advanced feature usually only required for more
complex networks with complex firewall filtering requirements. For example, a network
may have multiple class C subnets (such as 192,168.1.0, 192.168.2.0, 192.168.3.0 and so
on) and may require the same firewall policy for similar addresses on each of these
subnets. To do this you could create multiple firewall addresses for each of the subnets
and then group these firewall addresses into address groups and then add the address
groups to firewall policies. Or, you could create a wildcard firewall address that matches
multiple addresses on multiple subnets and add this single address to a firewall policy.
A wildcard firewall address consists of an IP address and a wildcard netmask (for
example, 192.168.0.56 255.255.0.255). In this example the IP address is 192.168.0.56
and the wildcard netmask is 255.255.0.255. The IP address defines the networks to match
and the wildcard netmask defines the specific addresses to match on these networks.
In a wildcard netmask, 0 means ignore the value of the octet in the IP address, which
means the wildcard firewall address matches any number in this address octet. This also
means that the number included in this octet of IP address is ignored and can be any
number. Usually if the octet in the wildcard netmask is 0 the corresponding octet in the IP
address is also 0.
In a wildcard netmask, a number means match addresses according to how the numbers
translate into binary addresses. For example, if the wildcard netmask is 255 the wildcard
firewall address will only match addresses with the value for this octet that is in the IP
address part of the wildcard address. For example, if the first octet of the IP address is 192
and the first octet of the wildcard netmask is 255 the firewall wildcard address will only
match addresses with 192 in the first octet.
So the firewall wildcard address 192.168.0.56 255.255.0.255 would match the following IP
addresses:
192.168.0.56, 192.168.1.56, 192.168.2.56, ..., 192.168.255.56
The firewall wildcard addresses 192.168.0.56 255.255.0.255 and 192.168.1.56
255.255.0.255 define the same thing since the 0 in the wildcard mask means to match any
address in the third octet.
Also, the firewall wildcard address 172.0.20.10 255.0.255.255 would match the following
IP addresses:
172.1.20.10, 72.2.20.10, 72.3.20.10, ..., 72.255.20.10
In a wildcard netmask, a number other than 255 matches multiple addresses for this octet.
And you can perform a binary conversion to calculate the addresses that would be
matched by a given value.

01-40002-112804-20101015 59
For example, to create the IP address and wildcard netmask to match the following
network addresses:
192.168.32.0/24
192.168.33.0/24
192.168.34.0/24
192.168.35.0/24
192.168.36.0/24
192.168.37.0/24
192.168.38.0/24
192.168.39.0/24
Table 5 shows how to write the third octet for these networks according to the octet bit
position and address value for each bit.
Table 5: Octet bit position and address value for each bit
Decimal 128 64 32 16 8 4 2 1
32 0 0 1 0 0 0 0 0
33 0 0 1 0 0 0 0 1
34 0 0 1 0 0 0 1 0
35 0 0 1 0 0 0 1 1
36 0 0 1 0 0 1 0 0
37 0 0 1 0 0 1 0 1
38 0 0 1 0 0 1 1 0
39 0 0 1 0 0 1 1 1
M M M M M D D D
Since the first five bits match, the networks can be summarized into one network
(192.168.32.0/21 or 192.168.32.0 255.255.248.0). All eight possible combinations of the
three low-order bits are relevant for the network ranges. The firewall wildcard address that
would match all of these subnet addresses can be written as 192.168.32.0 255.255.248.0.
Note: Wildcard firewall addresses are similar to routing access list wildcard masks. You
add routing access lists containing wildcard masks using the
config router access-list command. However, router access list wildcard masks
use the inverse of the masking system used for firewall wildcard addresses. For the router
access list wildcard masks, 0 means match all IP addresses and 1 means ignore all IP
addresses. So to match IP addresses 192.168.0.56, 192.268.1.56, 192.168.2.56, ...
192.168.255.56 you would use the following router access IP address prefix and wildcard
mask: 192.168.0.56 0.0.255.0.
The following example shows how firewall wildcard addresses can be applied to network
traffic. This example consists of a firewall policy where both the source and destination
addresses are firewall wildcard addresses.
Source Address: 10.129.5.0 255.127.7.0
Destination Address: 10.129.0.10 255.127.7.255

60 01-40002-112804-20101015
A firewall policy with these source and destination addresses would permit:
• A device with IP address 10.129.5.100 to connect through the FortiGate unit to IP
address 10.129.0.10
address 10.129.8.10
address 10.129.0.10
Adding a firewall wildcard address

Wildcard firewall addresses are only configured from the CLI.
edit example_wildcard_address
set type wildcard
set wildcard 192.168.0.56 255.255.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:
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.

01-40002-112804-20101015 61
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
Guide.
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
set mappedip 192.168.1.1
end
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.

62 01-40002-112804-20101015
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.
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.

01-40002-112804-20101015 63
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 18: 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 18: 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
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 19: 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
.55
8 .37 37.4
6 .
2.1 68
P 19 92.1
e I IP 1
o urc tion
S ina
st
De

64 01-40002-112804-20101015
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.
Figure 20: Example of packet address remapping during NAT from server to client
.42
0 .10 10.2
.1 .
10 .10
e IP P 10 1
I
urc n
So inatio 3
2
s t
De NA
T wit
ha
vir
tua
l IP 1
3
2
.4
8 .37 7.55
6 3
2.1 8.
P 19 2.16
e I 19
o urc on IP
S ati
n
e sti
D
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.

01-40002-112804-20101015 65
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.
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.

66 01-40002-112804-20101015
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.
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.

01-40002-112804-20101015 67
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
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 interface internal
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.

68 01-40002-112804-20101015
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.
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.

01-40002-112804-20101015 69
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.
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.

70 01-40002-112804-20101015
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
...... ......
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.

01-40002-112804-20101015 71
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 in the System Administration Guide.
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.
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

72 01-40002-112804-20101015
Firewall components Routing
Routing
A route provides the FortiGate unit with the information it needs to forward a packet to a
particular destination on the network. 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.
As a security device on the network, packets must pass through the FortiGate unit. You
need to understand a number of basic routing concepts to configure the FortiGate unit
appropriately.
The routing table

By default, the FortiOS routing table contains a single static default route. You can add
routing information to the routing table by defining additional static routes. The table may
include several different routes to the same destination. The IP addresses of the next-hop
router specified in those routes, or the FortiGate unit interfaces associated with those
routes, may vary.
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 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.
How routing decisions are made

Whenever a packet arrives at one of the FortiGate unit’s interfaces, the FortiGate 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. 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 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 occurs, 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.
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.
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. 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. For

01-40002-112804-20101015 73
Routing Firewall components
example, if there are two possible routes traffic can take between 2 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. Different routing protocols have different
default administrative distances. The default administrative distances for any of these
routing protocols are configurable.
Another method is to manually change the priority of both of the routes. 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. Configuring the priority for each of those routes will make
it clear which next-hop will be used in the case of a tie. You can set the priority for a route
only from the CLI. Lower priorities are preferred. For more information, see the FortiGate
CLI Reference.
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, selects the entries having the lowest distances,
and adds them as routes in the FortiGate forwarding table. As a result, the FortiGate
forwarding table contains only those routes having the lowest distances to every possible
destination.
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.
You configure the priority through the CLI. The route with the lowest value in the priority
field is considered the best route, and it is also the primary route. The command to set the
priority field is: set priority <integer> under the config route static
command. For more information, see the FortiGate CLI Reference.
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.
Static route
You configure static routes by defining the destination IP address and netmask of packets
that you intend the FortiGate unit to intercept, and by specifying a gateway IP address for
those packets. The gateway address specifies the next-hop router to which traffic will be
routed. When you add a static route to the Static Route list, the FortiGate unit performs a
check to determine whether a matching route and destination already exist in the
FortiGate routing table. If no match is found, the FortiGate unit adds the route to the
routing table.
Default route and default gateway

In the 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.

74 01-40002-112804-20101015
To prevent this you must either edit the factory configured static default route to specify a
different default gateway for the FortiGate unit, or delete the factory configured route and
specify your own static default route that points to the default gateway for the FortiGate
unit.
For example, Figure 21 shows a FortiGate unit connected to a router. To ensure that all
outbound packets destined to any network beyond the router are routed to the correct
destination, you must edit the default configuration and make the router the default
gateway for the FortiGate unit.
Figure 21: Making a router the default gateway
Ga
te
Ro way
ute
r
19
2.
ex
16
ter
8.
10
na
.1
int
ern
a l
In 2.
te 16
19
rn 8
al .2
ne 0.0
tw /2
or 4
k
To route outbound packets from the internal network to destinations that are not on
network 192.168.20.0/24, you need to edit the default route by going to Router > Static >
Static Route, select Edit for the default route and include the following settings:
Destination IP/mask: 0.0.0.0/0.0.0.0
Gateway: 192.168.10.1
Device: The interface connected to network 192.168.10.0/24, for example “external”.
Distance: 10
The Gateway setting specifies the IP address of the next-hop router interface to the
FortiGate external interface. The interface behind the router (192.168.10.1) is the default
gateway for the FortiGate unit.
In some cases, there may be routers behind the FortiGate unit. If the destination IP
address of a packet is not on the local network but is on a network behind one of those
routers, the FortiGate routing table must include a static route to that network. For
example, in Figure 22, the FortiGate unit must be configured with static routes to
interfaces 192.168.10.1 and 192.168.11.1 in order to forward packets to Network_1 and
Network_2 respectively.

01-40002-112804-20101015 75
Figure 22: Destinations on networks behind internal routers
ay
ew
Gat ter_2
Rou
.1
16 Z
11
2. DM
8.
19
ay
.1
8. a l
ew
16 rn
10
Gat ter_1
2. te
19 In
19
N 16
et 8.
2.
w 30
Rou
or .
k_ 0/2
2 4
19
N 16
et 8.
2.
w 20
or .
k_ 0/2
1 4
To route packets from Network_1 to Network_2, Router_1 must be configured to use the
FortiGate internal interface as its default gateway. On the FortiGate unit, you would create
a new static route with these settings:
Destination IP/mask: 192.168.30.0/24
Gateway: 192.168.11.1
Device: dmz
Distance: 10
To route packets from Network_2 to Network_1, Router_2 must be configured to use the
FortiGate dmz interface as its default gateway. On the FortiGate unit, you would create a
new static route with these settings:
Destination IP/mask: 192.168.20.0/24
Gateway: 192.168.10.1
Device: internal
Distance: 10
Changing the gateway for the default route

The default gateway determines where packets matching the default route will be
forwarded. In this example, the gateway IP address is 192.168.21.12 on port 1 with an
administrative distance of 10.
To change the gateway for the default route - web-based manager

1 Go to Router > Static > Static Route.
2 Select the only route entry and select Edit.
3 Select the interface of port 1 from the Device list.

76 01-40002-112804-20101015
4 In the Gateway field, enter the IP address of 192.168.21.12.

5 In the Distance field, enter the value of 10.
6 Select OK.
To change the gateway for the default route - CLI

config router static
edit 1
set device port1
set distance 10
end
Adding a static route

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. Static routes are configured 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. For this example, the internal port
address is 172.20.120.129, the gateway of 182.168.21.12 and a distance of 10.
To add a static route - web-based manager

2 Select Create New.
3 Enter the IP address of 172.20.120.129.
4 Select the Device port of internal.
5 Enter the Gateway IP address of 192.168.21.12.
6 Enter the Distance of 10.
7 Select OK.
To add a static route - CLI

edit 2
set det 172.20.120.129
set device internal
set distance 10
end
Policy Route
A routing policy enables 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 addressed to that
subnet directly to the mail server.

01-40002-112804-20101015 77
If you have configured the FortiGate unit with routing policies and a packet arrives at the,
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, 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.
To add a policy route - web-based manager

1 Go to Router > Static > Policy Route and select Create New.
2 Complete the following and select OK:
Protocol Enter a protocol number. The Internet Protocol Number is found in the IP
packet header, and RFC 5237 includes a list of the assigned protocol
numbers. A value of 0 disables the setting.
Incoming Interface Select the name of the interface for the incoming packets.
Source Address / Enter the source address and network mask. A value of 0.0.0.0/0.0.0.0
Mask disables the setting.
Destination Enter the destination address and network mask. A value of
Address / Mask 0.0.0.0/0.0.0.0 disables the setting.
Destination Ports To perform policy routing based a port or range of ports, enter the port
numbers. A value of 0 disables this setting.
The Destination Ports fields are only used for TCP and UDP 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 79.
Outgoing Interface Select the name of the interface where 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.
To add a policy route - CLI

config router policy
edit 1
set input-device <incoming_interface>
set src <source_IP>
set dst <destination_IP>
set protocol <protocol>
set gateway <gateway_IP>
set output-device <outgoing_interface>
set tos <tos_bit_pattern>set
tos-mask <tos_bit_mask>
end

78 01-40002-112804-20101015
Firewall components Ports
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.
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 6: 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.
For more information on ToS, see the Traffic Shaping Guide.
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

01-40002-112804-20101015 79
Ports Firewall components
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
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.

80 01-40002-112804-20101015
Firewall components Ports
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
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.

01-40002-112804-20101015 81
Services Firewall components
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
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 Type TCP/UDP/SCTP
Protocol TCP
Source Port
Low 9620
Hi 9620
Destination Port
Low 4545
High 4550
3 Select OK.

82 01-40002-112804-20101015
Firewall components Schedules
To create a custom service - CLI

config firewall service custom
edit Widget
set protocol TCP/UDP/SCTP
set tcp-portrange 9620:4545-4550
end
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

01-40002-112804-20101015 83
Schedules Firewall components
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.
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.

84 01-40002-112804-20101015
Firewall components UTM profiles
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.
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.

01-40002-112804-20101015 85
UTM profiles Firewall components
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.
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.

86 01-40002-112804-20101015
Firewall components UTM profiles
To create a antivirus profile for email - CLI

config webfilter profile
edit activex_java
config http
set options activexfilter
end
config http
set options javafilter
end
end

01-40002-112804-20101015 87
UTM profiles Firewall components

88 01-40002-112804-20101015
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-40002-112804-20101015 89
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 98.

90 01-40002-112804-20101015
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 23: 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 24: 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 96.
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-40002-112804-20101015 91
Policy order Firewall Policies
To move a policy in the policy list

1 Go to Firewall > Policy > Policy.
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.

92 01-40002-112804-20101015
Firewall Policies Creating basic policies
Figure 25: 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-40002-112804-20101015 93
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

94 01-40002-112804-20101015
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-40002-112804-20101015 95
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 Guide.
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

96 01-40002-112804-20101015
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-40002-112804-20101015 97
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

config firewall interface-policy
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.
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.
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.

98 01-40002-112804-20101015
Firewall Policies Identity-based Policies
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 > User 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.

edit 1
set dstintf wan1
set dstaddr 172.20.120.141
set action accept
set schedule always

01-40002-112804-20101015 99
Identity-based Policies Firewall Policies
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.

100 01-40002-112804-20101015
Firewall Policies ICMP packet processing
Figure 26: 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 90). 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-40002-112804-20101015 101
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

102 01-40002-112804-20101015
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 82.
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-40002-112804-20101015 103
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.

104 01-40002-112804-20101015
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-40002-112804-20101015 105

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

106 01-40002-112804-20101015
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-40002-112804-20101015 107

108 01-40002-112804-20101015
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.
If, after attempting to troubleshoot your connection issues, you are still having difficulites,
contact Technical Support for further assistance. For more information on contacting
Technical Support, see “Customer service and technical support” on page 20.
This chapter includes the topics:
• Basic policy checking
• Default gateway
• 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 90.
• 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.
Default gateway

01-40002-112804-20101015 109
Verifying traffic Troubleshooting
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.
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

2 Enter the following:

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

110 01-40002-112804-20101015
Troubleshooting Traffic trace
4 Select OK.

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

1 Go to System > Dashboard > Status.
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

01-40002-112804-20101015 111
Traffic trace Troubleshooting
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.
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

112 01-40002-112804-20101015
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.
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>

01-40002-112804-20101015 113
Traffic trace Troubleshooting
Filtering options include:

addr IP address
clear clear filter
daddr destination IP address
dport destination port
negate inverse filter
port port
proto protocol number
saddr source IP address
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“

114 01-40002-112804-20101015
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."
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:
id=20085 trace_id=210 func=vf_ip4_route_input line=1543
msg="find a route: gw-192.168.3.221 via port5"
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:
id=20085 trace_id=212
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."
Match existing session in the
original direction:

01-40002-112804-20101015 115
Packet sniffer Troubleshooting

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:
line=2700 msg="vd-root received a packet(proto=6,
203.160.224.97:80->192.168.11.59:31925) from port6."
Match existing session in reply direction:
line=2727 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"
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 interfce, 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

116 01-40002-112804-20101015
Troubleshooting Packet sniffer
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.
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

01-40002-112804-20101015 117
Packet sniffer Troubleshooting
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:
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.

118 01-40002-112804-20101015
Configuration Examples Exempted URLs
Configuration Examples
This chapter 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 chapter 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.
3 Enter the URL, for example www.fortinet.com.

01-40002-112804-20101015 119
Exempted URLs Configuration Examples
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.

120 01-40002-112804-20101015
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-40002-112804-20101015 121
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 7 describes the company’s goals and the FortiGate options that meet them.
Table 7: 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 142.
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 147.
Block access by all employees to Enable FortiGuard web content filtering solution.
potentially offensive web content. See “Configuring web category block settings” on
page 131.
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 135.
Topology
Figure 27 shows the The Example Corporation network configuration after installation of
the FortiGate-100A.

122 01-40002-112804-20101015
Concept Example: Small Office Network Protection Example small office network
Figure 27: 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 10 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
ri n 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-40002-112804-20101015 123
First steps Concept Example: Small Office Network Protection
System • “Configuring FortiGate network interfaces” on page 124

• “Configuring DNS forwarding” on page 126
• “Scheduling automatic antivirus and attack definition updates” on page 128
• “Setting the time and date” on page 127
• “Configuring administrative access and passwords” on page 128
• “Registering the FortiGate unit” on page 127
Router • “Adding the default route” on page 125
Firewall • “Removing the default firewall policy” on page 126
• Adding firewall policies for different addresses and address groups, see
“Configuring firewall policies for Finance and Engineering” on page 134,
“Configuring firewall policies for help desk” on page 140, and “Configuring
firewall policies for the VPN tunnels” on page 145
• Adding addresses and address groups, see “Adding the Finance and
Engineering department addresses” on page 130, “Adding the Help Desk
department address” on page 136, “Adding addresses for home-based
workers” on page 142, “Adding the web server address” on page 148, and
“Adding the email server address” on page 152
• “Creating a recurring schedule” on page 140
VPN • “Configuring remote access VPN tunnels” on page 142 (IPSec)
IPS • “Scheduling automatic antivirus and attack definition updates” on page 128
Antivirus • “Configuring antivirus grayware settings” on page 132
• enabling virus scanning (see Configuring protection profiles)
• “Scheduling automatic antivirus and attack definition updates” on page 128
Web Filter • “Configuring web category block settings” on page 131 (FortiGuard)
• “Creating and Configuring URL filters” on page 136
Spam Filter • “Configuring FortiGuard spam filter settings” on page 131
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.

124 01-40002-112804-20101015
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
set allowaccess ping
end
Adding the default route

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

2 Select Create New and enter the following information:

01-40002-112804-20101015 125
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

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

126 01-40002-112804-20101015
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

config system global
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-40002-112804-20101015 127
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:

128 01-40002-112804-20101015
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

1 Go to System > Admin >
Administrators.
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

01-40002-112804-20101015 129
Configuring settings for Finance and Engineering departments Concept Example: Small Office Network Protection
edit admin
set password <psswrd>
end
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

130 01-40002-112804-20101015
Concept Example: Small Office Network Protection Configuring settings for Finance and Engineering departments
To include the Finance and Eng addresses in an address group - web-based

manager
1 Go to Firewall > Address > Group.
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.

01-40002-112804-20101015 131
3 Select Enable CacheTTL and enter 3600 in the field.

4 Select Apply.
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
1 Go to UTM > Antivirus > Profile.
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

config antivirus profile

132 01-40002-112804-20101015
Concept Example: Small Office Network Protection Configuring settings for Finance and Engineering departments
edit standard_profile
config http
set options scan
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

1 Go to UTM > Web Filter > Profile.
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

01-40002-112804-20101015 133
end
config http
set options fortiguard-wf
end
end
Email filter UTM profile

To create and configure a email filter profile - web-based manager
1 Go to UTM > Antivirus > Profile.
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.

134 01-40002-112804-20101015
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 utm-status 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-40002-112804-20101015 135
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

config webfilter urlfilter

136 01-40002-112804-20101015
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.
4 Enter the following settings:
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-40002-112804-20101015 137
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

1 Go to UTM > Web Filter > Profile.
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

138 01-40002-112804-20101015
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-40002-112804-20101015 139
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 134.
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


140 01-40002-112804-20101015

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-40002-112804-20101015 141
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 profile-status enable
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


142 01-40002-112804-20101015
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-40002-112804-20101015 143
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
Mode Main (ID protection)
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

144 01-40002-112804-20101015
Concept Example: Small Office Network Protection Configuring remote access VPN tunnels
To configure IPSec phase 2

1 Go to VPN > IPSEC > Auto Key (IKE).
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-40002-112804-20101015 145

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

146 01-40002-112804-20101015
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 natinbound 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-40002-112804-20101015 147
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 155.
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.

148 01-40002-112804-20101015
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-40002-112804-20101015 149
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.

150 01-40002-112804-20101015
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 155.
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

1 Go to Firewall > Virtual IP > Virtual IP.
Name Email_Server_VIP
External Interface wan1
Type Static NAT
External IP Address/ Range 172.20.120.141
Mapped IP address/ Range 10.20.10.2
3 Select OK.

01-40002-112804-20101015 151
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

152 01-40002-112804-20101015
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-40002-112804-20101015 153
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

154 01-40002-112804-20101015
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-40002-112804-20101015 155
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 27 on page 123)
• 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

156 01-40002-112804-20101015
Other features and products for SOHO Concept Example: Small Office Network Protection

157 01-40002-112804-20101015
Other features and products for SOHO Concept Example: Small Office Network Protection

158 01-40002-112804-20101015
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-40002-112804-20101015 159
Current topology and security concerns Concept Example: Library Network Protection
Figure 28: 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
al l
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:

160 01-40002-112804-20101015
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 29 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-40002-112804-20101015 161
Current topology and security concerns Concept Example: Library Network Protection
Figure 29: Proposed library system network topology

CM
B .1.
Int
ra 2.
10
80
nc [2
e
54 ls
10 rnal Fi-
-2 ina
h -25
Wi
st 4
Z
]
.1.
.[2 m
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 8 on page 162 details the allowed connectivity between different parts of the
network.
Table 8: 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.

162 01-40002-112804-20101015
Concept Example: Library Network Protection Current topology and security concerns
Features used in this example
Table 9: 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 168 and the main office is encrypted.
WiFi access for mobile clients. “Wireless access” on The FortiWiFi-80CM provides WiFi
page 178 access.
Strict separation of public access “Topology” on Traffic is permitted between
terminals from staff computers. page 165 network interfaces only when
policies explicitly allow it.
An automatically maintained and “FortiGuard” on The FortiGuard Subscription
updated system for stopping viruses page 167 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 174 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 172 or blocked.
Public access traffic originates from a “IP Pools” on IP pools can have traffic controlled
different address than staff and server page 169 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 181 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 170 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 165 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-40002-112804-20101015 163
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 30: 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.

164 01-40002-112804-20101015
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 8 on page 162 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 31: 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 M Z
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-40002-112804-20101015 165
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 32.
3 Connect the heartbeat interface of the both FortiGate-800 units using a crossover
cable, or normal cables connected to a switch.
Figure 32: 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 32 on page 166
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.

166 01-40002-112804-20101015
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-40002-112804-20101015 167
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.

168 01-40002-112804-20101015
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
1 Go to VPN > IPsec > Auto Key (IKE).
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-40002-112804-20101015 169
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

config firewall ippool
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.

170 01-40002-112804-20101015
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 10: 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-40002-112804-20101015 171
Table 11: 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 12: 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 13: 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

172 01-40002-112804-20101015
Table 13: 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 14: 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 15: 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-40002-112804-20101015 173
Table 16: 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.

174 01-40002-112804-20101015
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 17.
Table 17: 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-40002-112804-20101015 175
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 18 on page 176.
For complete policy construction steps, see the FortiGate Administration Guide.
Table 18: 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.

176 01-40002-112804-20101015
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 19: 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-40002-112804-20101015 177
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.

178 01-40002-112804-20101015
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-40002-112804-20101015 179
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 20: 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.

180 01-40002-112804-20101015
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 21 on page 181.
Table 21: 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-40002-112804-20101015 181
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

182 01-40002-112804-20101015
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 22 on
page 183.
Table 22: 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-40002-112804-20101015 183
Table 22: 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 31 on page 165.
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

config system settings
set opmode transparent
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

184 01-40002-112804-20101015
Concept Example: Library Network Protection Configuring branch offices
Table 23: 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 8 on page 162 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-40002-112804-20101015 185
Configuring branch offices Concept Example: Library Network Protection
Figure 33: Branch office network topology
B .1.
C
ra 2.
10 Int -80
nc [2
54 ls
ern i
-2 ina
h -25
10 al Wi F
st 4
Z
]
.[2 m
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
.8
C
9
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.

186 01-40002-112804-20101015
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-40002-112804-20101015 187
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 24: 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.

188 01-40002-112804-20101015
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 25: 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-40002-112804-20101015 189
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.

190 01-40002-112804-20101015

191 01-40002-112804-20101015

192 01-40002-112804-20101015
Index
Numerics DHCP, 67
diagnose
802.3ad, 52 flow trace, 113
session list, 111
A sniffer packet, 116
sys checkused, 113
accept, 90
DNAT
accept policy, 94
virtual IPs, 63, 65
adding, configuring or defining
DNS
gateway for default route, 76
TTL, 61
static route, adding to routing table, 77
document conventions
address, 57
CLI syntax, 16
CIDR format, 57
DHCP, 67 documentation, 20
FDQN, 61 commenting on, 20
groups, 66 conventions, 13
IP pool, 69 DoS
IP range, 57 policies, 91, 96
IPv6, 71 sensors, 96
matching, IP pool, 70
administrative access, 51 E
administrative distance, 73 email filter
aggregate interfaces, 52 techniques, 26
allow access, 51 email filter, about, 26
antispam, about, 26 example
antivirus, about, 23 blocking IP address, 102
scheduled access, 103
B exempted URLs, 119
blended network attacks, about, 26
F
C FAQ, 20
FDQN, 61
central NAT, 32
firewall policies, 92
certification, 20
accept, 90
CLI basic accept, 94
syntax conventions, 16 basic deny, 94
column settings, firewall policies, 92 basic VPN, 95
comments, documentation, 20 checking, 109
conventions, 13 column settings, 92, 110
Cross-Site Scripting (XSS), 18 denial of service, 91, 96
custom services, 82 deny, 90
customer service, 20 ICMP packets, 101
identity-based, 98
D IPsec, 90
log messages, 110
default gateway, 74 one-armed sniffer, 97
default route, 74 policy order, 90
denial of service rearrange, 91
policies, 91, 96 schedule example, 103
deny, 90 ssl-vpn policies, 90
deny policy, 94, 110 verify traffic, 110
destination network address translation (DNAT) firewall policy
virtual IPs, 63, 65 sniffer, 97
details, firewall policies, 92 fixed ports, IP pools, 70

01-40002-112804-20101015 193
Index
flow inspection, 36, 37 L

flow trace, 113
FortiGate documentation life of a packet, 35
commenting on, 20 local category, 119
FortiGuard, 119 log messages, 110
Antivirus, 19
services, 19 N
Fortinet NAT, 32
Knowledge Base, 20 symmetric, 66
Technical Documentation, 20
NAT mode
Technical Documentation, conventions, 13
about, 29
Technical Support, 20
Technical Support, registering with, 19 network address translation (NAT), 63
Technical Support, web site, 19
Training Services, 20 O
Fortinet customer service, 20 one-armed sniffer policy, 97
G P
glossary, 20 P2P, about, 25
grayware, about, 25 packet
groups, addressing, 66 flow, 38
ICMP, 101
H life of, 35
sniffer, 116
how-to, 20
PAT
virtual IPs, 63
I peer-to-peer, about, 25
ICMP processing, 101 pharming, about, 25
identity-based policy, 98 phishing, about, 25
position, 100 policies, 90, 91
inspection basic accept, 94
flow, 36, 37 basic deny, 94
proxy, 37 basic VPN, 95
security layers, 37 checking, 109
stateful, 35 column settings, 92
instant messaging, about, 25 denial of service, 91, 96
interfaces ICMP packets, 101
aggregate, 52 identity-based, 98
AMC card, 50 log messages, 110
ANY, ANY interface option, 93 one-armed sniffer, 97
physical, 49 order, 90
virtual domains, 53 sniffer, 97
virtual LANs, 55 verify traffic, 110
wireless, 52 policy 0, 92
zones, 56 policy-based routing, 77
intrusion protection, about, 27 port address translation
IP address virtual IPs, 63
private network, 13 port forwarding, 63
IP addresses ports
blocking, 102 closing to traffic, 81
IP pool, 69 default system, 79
address matching, 70 originating traffic, 79
policies and fixed ports, 70 receiving traffic, 80
IP range, 57 services, 82
IPsec, 90 TCP 113, 81
TCP 541, 81
IPv6, 71
position
identity-based policy, 100
K product registration, 19
Knowledge Base, 20 profiles, UTM, 85
proxy inspection, 37

194 01-40002-112804-20101015
Index
R technical support, 20
traffic count, 110
rearrange, 91 traffic shaping
registering about, 28
with Fortinet Technical Support, 19 traffic trace, 111
RFC Training Services, 20
1918, 13
transparent mode
RFC 5237, 78 about, 32
routing feature differences, 34
administrative distance, 73 switching to, 33
routing policy troubleshooting
protocol number, 78 flow trace, 113
log messages, 110
S packet sniffer, 116
policies, 109
schedule
session table, 111
automatic updates, 128
veryify traffic, 110
schedules
example, 103
group, 84 U
one time, 83 UTM
recurring, 83 profiles, 85
security layers, 37 profiles and sensors, 85
sensors, UTM, 85
services, 82 V
custom, 82
list, 82 verify traffic, 110
session helper, 41 violation traffic, 110
session list, diagnose, 111 virtual domains, 53
session table, 111 virtual IP
SNAT destination network address translation (DNAT), 63, 65
virtual IPs, 63 NAT, 63
PAT, 63
sniffer
port address translation, 63
one-armed policy, 97
SNAT, 63
packet, 111
source network address translation, 63
policy, 97
virtual LANs, 55
spyware, about, 25
VPN
ssl-vpn, 90
policy, 95
stateful inspection, 35
static route
adding, 77
W
administrative distance, 73 web filter, 119
default gateway, 74 web filtering, about, 24
default route, 74 wireless, 52
policy, 77
selecting, 73
table priority, 74
X
table sequence, 74 XSS, 18
streaming media, about, 25
Z
T zones, 56
technical
documentation, 20
documentation conventions, 13
notes, 20
support, 20

01-40002-112804-20101015 195
Index

196 01-40002-112804-20101015
Index

01-40002-112804-20101015 197
Index

198 01-40002-112804-20101015

Fortigate Fundamentals 40 mr2

Uploaded by

Copyright:

Available Formats

Fortigate Fundamentals 40 mr2

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Fortigate Fundamentals 40 mr2

Uploaded by

Copyright:

Available Formats

FortiGate Fundamentals

The Purpose of a Firewall 23

FortiOS™ Handbook v2: FortiGate Fundamentals

NAT vs. Transparent Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

FortiGate Fundamentals for FortiOS 4.0 MR2

FortiOS™ Handbook v2: FortiGate Fundamentals

FortiGate Fundamentals for FortiOS 4.0 MR2

Configuration Examples 119

Concept Example: Small Office Network Protection 121

FortiOS™ Handbook v2: FortiGate Fundamentals

Configuring settings for Finance and Engineering departments . . . . . . . . . . . . 130

FortiGate Fundamentals for FortiOS 4.0 MR2

internal -> dmz1 policies . . . . . . . . . . . . . . . . . . . . . . . . . . . 154

Concept Example: Library Network Protection 159

FortiOS™ Handbook v2: FortiGate Fundamentals

Configuring branch offices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185

FortiGate Fundamentals for FortiOS 4.0 MR2

Before you begin

FortiOS™ Handbook v2: FortiGate Fundamentals

How this guide is organized

FortiGate Fundamentals for FortiOS 4.0 MR2

FortiOS™ Handbook v2: Traffic Shaping

Table 1: Examples of the IP numbering

Location and device Internal Dmz External

Example Network configuration

Traffic Shaping for FortiOS 4.0 MR2

Figure 1: Example network configuration

FortiOS™ Handbook v2: Traffic Shaping

Cautions, Notes and Tips

CLI command syntax conventions

Traffic Shaping for FortiOS 4.0 MR2

Table 3: Command syntax notation

FortiOS™ Handbook v2: Traffic Shaping

Table 3: Command syntax notation (Continued)

Entering FortiOS configuration data

Entering text strings (names)

Traffic Shaping for FortiOS 4.0 MR2

config firewall address

Entering numeric values

Selecting options from a list

Enabling or disabling options

Registering your Fortinet product

FortiOS™ Handbook v2: Traffic Shaping

Fortinet products End User License Agreement

Fortinet Tools and Documentation CD

Fortinet Knowledge Base

Comments on Fortinet technical documentation

Customer service and technical support

Traffic Shaping for FortiOS 4.0 MR2

Traffic Shaping for FortiOS 4.0 MR2

Traffic Shaping for FortiOS 4.0 MR2

FortiOS™ Handbook v2: FortiGate Fundamentals

FortiGate Fundamentals for FortiOS 4.0 MR2

FortiOS™ Handbook v2: FortiGate Fundamentals

Blended network attacks

Email filter techniques

FortiGate Fundamentals for FortiOS 4.0 MR2

FortiOS™ Handbook v2: FortiGate Fundamentals

FortiGate Fundamentals for FortiOS 4.0 MR2