Fortigate Fundamentals 40 Mr3

FortiGate Fundamentals
FortiOS Handbook v3 for FortiOS 4.0 MR3
FortiOS Handbook: FortiGate Fundamentals v3 28 February 2011 01-430-112804-20110228 for FortiOS 4.0 MR3 Copyright 2011 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
How this guide is organized . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
11
The Purpose of a Firewall

Firewall features . . . . . . . . . Antivirus . . . . . . . . . . . Web Filtering . . . . . . . . . Data leak prevention . . . Application control . . . . Spyware/Grayware. . . . Phishing . . . . . . . . . Pharming . . . . . . . . . Instant messaging . . . . Peer-to-peer . . . . . . . Streaming media . . . . . Blended network attacks . Antispam/Email Filter. . . . . Email filter techniques . . Intrusion Protection. . . . . . Traffic Shaping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
13 13 14 15 15 15 15 16 16 16 16 16 16 17 18 19 20 20 21 22 22 24
NAT vs. Transparent Mode . . . . . . . NAT mode . . . . . . . . . . . . . How address translation works Central NAT table . . . . . . . Transparent mode . . . . . . . . . Operating mode differences . . . .
Life of a Packet
Stateful inspection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Flow inspection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Proxy inspection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . FortiOS functions and security layers . . . . . . . . . . . . . . . . . . . . . . . . .
25
25 26 27 27
FortiOS Handbook v3: FortiGate Fundamentals 01-430-112804-20110228 http://docs.fortinet.com/ Feedback
Contents
Packet flow . . . . . . . . . . . . . Packet inspection (Ingress) . . Interface . . . . . . . . . . . . DoS sensor . . . . . . . . . . . IP integrity header checking . . IPsec . . . . . . . . . . . . . . Destination NAT (DNAT) . . . . Routing . . . . . . . . . . . . . Policy lookup . . . . . . . . . . Session tracking . . . . . . . . User authentication. . . . . . . Management traffic . . . . . . . SSL VPN traffic. . . . . . . . . Session helpers . . . . . . . . Flow-based inspection engine . Proxy-based inspection engine. IPsec . . . . . . . . . . . . . . Source NAT (SNAT) . . . . . . Routing . . . . . . . . . . . . . Egress . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
28 28 29 29 29 30 30 30 30 30 31 31 31 31 31 31 32 32 32 32 32 34 34
Example 1: client/server connection . . . . . . . . . . . . . . . . . . . . . . . . . . Example 2: Routing table update . . . . . . . . . . . . . . . . . . . . . . . . . . . . Example 3: Dialup IPsec with application control. . . . . . . . . . . . . . . . . . . .
Firewall components
Interfaces . . . . . . . . . Physical . . . . . . . Administrative access Example . . . . . Wireless . . . . . . . Virtual domains . . . . Example . . . . . Virtual LANs . . . . . Example . . . . . Zones. . . . . . . . . Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
37
37 37 39 39 40 40 41 42 42 43 44 44 45 46 46 47 47 48 48 48
Addressing . . . . . . . . . . . . . . . . . . Example . . . . . . . . . . . . . . . Example . . . . . . . . . . . . . . . Geography based addressing . . . . . . Wildcard masks . . . . . . . . . . . . . Fully Qualified Domain Name addresses Virtual IPs . . . . . . . . . . . . . . . . Example . . . . . . . . . . . . . . . Inbound connections . . . . . . . . .
FortiGate Fundamentals for FortiOS 4.0 MR3 01-430-112804-20110228 http://docs.fortinet.com/ Feedback
Contents
DNAT and virtual IP . . . . . . . . . . . . . . . . . . . . . Virtual IP options . . . . . . . . . . . . . . . . . . . . . . . . . Outbound connections . . . . . . . . . . . . . . . . . . . . Virtual IP, load balance virtual server / real server limitations Address groups. . . . . . . . . . . . . . . . . . . . . . . . . . Example . . . . . . . . . . . . . . . . . . . . . . . . . . . DHCP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . DHCP options . . . . . . . . . . . . . . . . . . . . . . . . Example . . . . . . . . . . . . . . . . . . . . . . . . . . . Example . . . . . . . . . . . . . . . . . . . . . . . . . . . IP reservation with DHCP . . . . . . . . . . . . . . . . . . IP pools. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Example . . . . . . . . . . . . . . . . . . . . . . . . . . . IP Pools for firewall policies that use fixed ports . . . . . . . . . Source IP address and IP pool address matching . . . . . . . . IPv6. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Example . . . . . . . . . . . . . . . . . . . . . . . . . . . Example . . . . . . . . . . . . . . . . . . . . . . . . . . . Ports . . . . . . . . . . . . . . . Originating traffic . . . . . . . Receiving traffic . . . . . . . Closing specific ports to traffic Port 113 . . . . . . . . . Port 541 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . .
49 49 52 53 53 53 54 54 55 56 56 57 58 58 59 59 60 60 61 61 62 62 62 63 63 63 63 64 64 65 66 66 66 66 67 67 68
Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Custom service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Schedules . . . . . . . . Example . . . . . Example . . . . . Schedule groups . . . Example . . . . . Schedule expiry . . . Identity-based policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
UTM profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Profiles and sensors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Firewall Policies
Policy order . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
69
70
Contents
Creating basic policies . . . . . . Using an interface of any . . Basic accept policy example . Basic deny policy example . . Basic VPN policy example . .
. . . . .
. . . . .
. . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
71 72 72 72 73 74 74 74 74 75 76 77 77
Firewall policy examples . . . . . . . . Blocking an IP address . . . . . . . Add an Address . . . . . . . . Add a Firewall Policy . . . . . . Scheduled access policies . . . . . Configuring the schedules . . . Configuring the IP addresses . Configuring the firewall policies
Troubleshooting
Basic policy checking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Verifying traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Using log messages to view violation traffic . . . . . . . . . . . . . . . . . . . . . . Traffic trace . . . . . . . . . . . . . . . Session table . . . . . . . . . . . . Sample output . . . . . . . . . Finding object dependencies . . . . Sample output . . . . . . . . . Flow trace . . . . . . . . . . . . . Sample output . . . . . . . . . Flow trace output example - HTTP . Packet sniffer . . . . . . . . . . Simple trace example . . . Simple trace example . . . Verbose levels 2 and 3. Trace with filters example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
81
81 81 82 83 83 84 85 85 85 86 86 88 88 88 89 89
Concept Example: Small Office Network Protection

Example small office network. . . . . . . . . . . . . . Network management and protection requirements Topology . . . . . . . . . . . . . . . . . . . . . . Features used in this example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
91
91 92 92 93
Contents
First steps. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 settings for Finance and Engineering departments . Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Adding the Finance and Engineering department addresses Configuring web category block settings . . . . . . . . . . . Configuring FortiGuard spam filter settings . . . . . . . . . Configuring antivirus grayware settings . . . . . . . . . . . Configuring a corporate set of UTM profiles . . . . . . . . . Antivirus UTM profile . . . . . . . . . . . . . . . . . . . Web filter UTM profile . . . . . . . . . . . . . . . . . . Email filter UTM profile . . . . . . . . . . . . . . . . . . Configuring firewall policies for Finance and Engineering . . Important points for firewall policy configuration . . . . . Configuring settings for the Help Desk department Goals . . . . . . . . . . . . . . . . . . . . . . Adding the Help Desk department address . . Creating and Configuring URL filters . . . . . . Web filter UTM profile . . . . . . . . . . . Ordering the filtered URLs . . . . . . . . . Application control or IM and P2P . . . . . Creating a recurring schedule . . . . . . . . . Configuring firewall policies for help desk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
94 94 95 96 96 97 97 97 98 100 100 100 101 101 102 102 102 103 104 105 105 106 106 106 107 109 109 109 110 110 113 113 113 114 116 118 118 118 118 119 119 119 120 120 120
Configuring remote access VPN tunnels . . . . . . . . . . . . Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . Adding addresses for home-based workers . . . . . . . . Configuring the FortiGate end of the IPSec VPN tunnels . Configuring firewall policies for the VPN tunnels . . . . . . Configuring the FortiClient end of the IPSec VPN tunnels . Configuring the web server . . . . . . . . . . . . . Goals . . . . . . . . . . . . . . . . . . . . . . Configuring the FortiGate unit with a virtual IP . Adding the web server address . . . . . . . . Configuring firewall policies for the web server wan1 -> dmz1 policies. . . . . . . . . . . dmz1 -> wan1 policies. . . . . . . . . . . dmz1 -> internal policies . . . . . . . . . internal -> dmz1 policies . . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
Contents
Configuring the email server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122 Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122 Configuring the FortiGate unit with a virtual IP . . . . . . . . . . . . . . . . . . . 122 Adding the email server address . . . . . . . . . . . Configuring firewall policies for the email server . dmz1 -> wan1 policies. . . . . . . . . . . . wan1 -> dmz1 policies. . . . . . . . . . . . dmz1 -> internal policies . . . . . . . . . . internal -> dmz1 policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122 123 123 124 125 125
ISP web site and email hosting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126 The Example Corporation internal network configuration . . . . . . . . . . . . . . . 127 Other features and products for SOHO. . . . . . . . . . . . . . . . . . . . . . . . . 127
Concept Example: Library Network Protection

Current topology and security concerns Library requirements . . . . . . . . The librarys decision . . . . . . . . Proposed topology . . . . . . . . . Features used in this example . . . Network addressing . . . . . . . . Configuring the main office . Topology . . . . . . . . High Availability (HA) . . Configuring HA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
129
129 130 130 131 133 133 134 135 135 135 138 138 139 140 140 140 141 144 144 146 146 146 147 148 148 148 150 151 151
FortiGuard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137 IPsec VPN . . . . . . . . . . . . . . . . . . . . . . . . . . Configuring IPsec VPNs . . . . . . . . . . . . . . . . . IP Pools . . . . . . . . . . . . . . . . . . . . . . . . . Configuring IP pools . . . . . . . . . . . . . . . . . User Disclaimer . . . . . . . . . . . . . . . . . . . . . Configuring the user disclaimer . . . . . . . . . . . UTM Profiles . . . . . . . . . . . . . . . . . . . . . . . Staff access . . . . . . . . . . . . . . . . . . . . . . . Creating firewall policy for staff members . . . . . . Catalog terminals. . . . . . . . . . . . . . . . . . . . . Creating firewall policies for catalog terminals . . . . Public access terminals . . . . . . . . . . . . . . . . . Creating firewall policies for public access terminals Wireless access . . . . . . . . . . . . . . . . . . . . . Security considerations . . . . . . . . . . . . . . . Creating schedules for wireless access . . . . . . . Creating firewall policies for WiFi access . . . . . . Mail and web servers. . . . . . . . . . . . . . . . . . . Creating a virtual IP for the web server . . . . . . .
Contents
Creating a virtual IP for the email server . . . . . . . . . . Creating a server service group . . . . . . . . . . . . . . Creating firewall policies to protect email and web servers The FortiWiFi-80CM . . . . . . . . . . . . . . . . . . . . . . Configuring the main office FortiWiFi-80CM. . . . . . . . Configuring branch offices . . . . . . . . . . . . . . Topology . . . . . . . . . . . . . . . . . . . . . Staff access . . . . . . . . . . . . . . . . . . . Catalog terminals. . . . . . . . . . . . . . . . . Wireless/public access . . . . . . . . . . . . . . Mail and web servers. . . . . . . . . . . . . . . IPsec VPN . . . . . . . . . . . . . . . . . . . . Branch Firewall Policy . . . . . . . . . . . . . . Creating firewall policy for the branch office . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
152 153 153 154 154 155 155 156 156 156 156 157 157 158
Traffic shaping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158 Priorities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159 The future. . . . . . . . Logging . . . . . . . Decentralization . . Staff WiFi . . . . . . Further redundancy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159 159 160 160 160
Index
161
Contents
10
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. 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.
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 FortiOS Handbook guide contains the following sections: The Purpose of a Firewall provides an overview of the FortiGate firewall and its traffic controlling options. Life of a Packet describes how a FortiGate unit processes incoming and outgoing network traffic through its interfaces and firewall policies. Firewall components describes the FortiGate interfaces, addressing, services and user configuration that goes into creating a firewall policy. Firewall Policies describes what policies are, the types of firewall policies and how to configure and arrange them to ensure proper traffic management. Troubleshooting describes some common problems and solutions when setting up firewall policies to manage network traffic. Concept Example: Small Office Network Protection walks through a small office configuration of firewall policies. Concept Example: Library Network Protection walks through an enterprise network configuration of firewall policies.
v3 FortiGate Fundamentals 01-430-112804-20110228 http://docs.fortinet.com/ Feedback
11
Introduction
12

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 packets 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.
Firewall features
The FortiGate unit provides unified threat management by including 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.
13
Firewall features
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
14
Firewall features
Data leak prevention

The FortiGate data leak prevention (DLP) system allows you to prevent sensitive data from leaving your network. When you define sensitive data patterns, data matching these patterns will be blocked, logged, and archived, or any combination of these three actions, when passing through the FortiGate unit. You configure the DLP system by creating individual rules, combining the rules into DLP sensors, and then assigning a sensor to a firewall policy. Although the primary use of the DLP feature is to stop sensitive data from leaving your network, it can also be used to prevent unwanted data from entering your network and to archive some or all of the content passing through the FortiGate unit. DLP examines network traffic for data patterns you specify. You define whatever patterns you want the FortiGate unit to look for in network traffic. The DLP feature is broken down into a number of parts.
Application control
Using the application control UTM feature, your FortiGate unit can detect and take action against network traffic depending on the application generating the traffic. Application control is a user-friendly and powerful way to use Intrusion Protection features to log and manage the behavior of application traffic passing through the FortiGate unit. Application control uses IPS protocol decoders that can analyze network traffic to detect application traffic even if the traffic uses non-standard ports or protocols. The FortiGate unit can recognize the network traffic generated by a large number of applications. You can create application control lists that specify the action to take with the traffic of the applications you need to manage and the network on which they are active, and then add application control lists to the firewall policies that control the network traffic you need to monitor.
Spyware/Grayware
Spyware is also known as Grayware. Spyware is a type of computer program that attaches itself to a users operating system. It does this without the users 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 users 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 attackers web site is always the next step.
15
Firewall features
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.
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.
16
Firewall features
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. 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.
17
Firewall features
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. 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.
18
Firewall features
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. 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.
19
NAT vs. Transparent Mode
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.

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.
Figure 1: FortiGate unit in NAT mode
172 .20 WA traf NAT .12 N 1 fic po 0.1 bet lici 29 ext ern wee es co al n n in ntr etw tern ollin ork al a g s. nd P 10. ort 2 10. 10.
P 192 ort 1 .16 8.1 .1
P tr olic inte affic ies c rna betw ontr l ne ee ollin two n g rks . rk o tw Ne /24 l na 0.0 ter 0.1 In .1 10
k or etw24 N / al .0 rn 8.1 e Int 2.16 9 1
20
In this situation, as shown in Figure 1, 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 users 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.
Figure 2: Senders IP internal address translated to the FortiGate units external address
PC nt lie .10.2 C 0 .1 10
nt Se et ck Pa Inte rna l
Fir ew N A all P T e olic nab y 1 led 2

3
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.
20 0. .2 2 50 0. 2. .1 17 .10 n: 0 io : 1 at ce tin ur es o D S
WA N
1 2
d ive ce Re cket Pa
20 0. 9 .2 12 50 0. 2. 12 17 0. n: .2 io 72 at 1 tin e: es rc D ou S
er erv 0 b S 20.2 We 50. 2. 17
21
Figure 3: Web server sends to FortiGate external address and translated to internal address
C tP en .2 Cli 0.10 .1 10 ed eiv ec ket R c Pa Inte rna l WA N
1 2
Fir ew N A all P T e olic nab y 1 led 2

3
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 Administration chapter of The Handbook.
.2 10 0 0. . 2 .1 20 10 0 . n: . 5 io 72 at 1 tin e: es r c D ou S
nt Se et ck Pa
.1 20 .1 20 20 0. 2. .2 17 .50 n: 2 io 17 at : tin rce es u D So
r rve Se .20 b 0 We 50.2 . 72 1
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.
22
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 4, 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 4: FortiGate unit in transparent mode
20
4.2
3.1
.5 10 .10
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 > Dashboard > Status. 2 Select the [Change] link for Operation Mode and select Transparent from the dropdown list. 3 Enter the Management IP address and netmask 10.11.101.10 255.255.255.0. 4 Enter the Default Gateway address of 10.11.101.1. 5 Select Apply. To enable Transparent mode - CLI config system settings set opmode transparent set manageip 10.11.101.10 255.255.255.0 set gateway 10.11.101.1 end
G ic bl pu to k ay or ew tw at ne
.10 .2 WA N 1 Inte rna
g llin nd ro l a nt na co r . s te ks ie in or lic en tw po twe l ne AT e a N ic b tern ff x tra e
23
For information on unique Transparent mode firewall configurations, see the System Administration Guide chapter of The Handbook.
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
24
Life of a Packet
Directed by firewall policies, a FortiGate unit screens network traffic from the IP layer up through the application layer of the TCP/IP stack. This chapter provides a general, high-level description of what happens to a packet as it travels through a FortiGate security system. The FortiGate unit performs three types of security inspection: stateful inspection, that provides individual packet-based security within a basic session state flow-based inspection, that buffers packets and uses pattern matching to identify security threats proxy-based inspection, that reconstructs content passing through the FortiGate unit and inspects the content for security threats.
Each inspection component plays a role in the processing of a packet as it traverses the FortiGate unit en route to its destination. To understand these inspections is the first step to understanding the flow of the packet.
Stateful inspection
With stateful inspection, the FortiGate unit looks at the first packet of a session to make a security decision. Common fields inspected include TCP SYN and FIN flags to identity the start and end of a session, the source/destination IP, source/destination port and protocol. Other checks are also performed on the packed payload and sequence numbers to verify it as a valid communication and that the data is not corrupted or poorly formed. The FortiGate unit makes the decision to drop, pass or log a session based on what is found in the first packet of the session. If the FortiGate unit decides to drop or block the first packet of a session, then all subsequent packets in the same session are also dropped or blocked without being inspected. If the FortiGate unit accepts the first packet of a session, then all subsequent packets in the same session are also accepted without being inspected.
25
Flow inspection
Life of a Packet
Figure 5: Stateful inspection of packets through the FortiGate unit
1 3 2
SY N, IP, TC 1 P 2
3
nt Se et ck Pa
1 3 2
d ive ce et Re ck 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 6: Flow inspection of packets through the FortiGate unit
3 2
nt Se et ck Pa
IPS , Ap Flow p C -AV ont , rol 2
1 2
ed eiv ec ket R c 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.
26
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. If you enable ICAP in a firewall policy, HTTP traffic intercepted by the policy is transferred to the ICAP servers in the ICAP profile added to the policy. The FortiGate unit is the surrogate, or middle-man, and carries the ICAP responses from the ICAP server to the ICAP client; the ICAP client then responds back, and the FortiGate unit determines the action that should be taken with these ICAP responses and requests.
Figure 7: Proxy inspection of packets through the FortiGate unit
1 3 2
nt Se et ck Pa
Em a filteil filter r, D , we LP, b AV

3 2 1
1 3 2
ed eiv ec ket R c 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.
27
Packet flow
Life of a Packet
Table 1: FortiOS security functions and security layers Security Function Firewall IPsec VPN Traffic Shaping User Authentication Management Traffic SSL VPN Intrusion Prevention Flow-based Antivirus Application Control VoIP inspection Proxy Antivirus Email Filtering Web Filtering (Antispam) Data Leak Prevention Stateful Flow Proxy
Packet flow
After the FortiGate units 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 8 on page 29 is a high level view of the packets 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 8 on page 29, 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
28
Life of a Packet
Packet flow
Figure 8: Packet flow

3 2 1
Packet
Packet flow: Ingress

Interface (Link layer) DoS Sensor IP Integrity Header checking IPsec NAT (DNAT) Routing
Stateful Inspection Engine
Session Helpers
Management Traffic
SSL VPN
User Authentication
Traffic Shaping
Session Tracking
Policy Lookup
No (Fast Path)
UTM
Yes
No
Additional Proxy Inspection Required
Flow-based Antivirus
Application Control
IPS
Flow-based Inspection Engine
Yes
VoIP Inspection Data Leak Prevention
Email Filter
Web Filter
Antivirus
ICAP
Proxy-based Inspection Engine
IPsec
NAT (SNAT)
3
Routing Interface
1 2
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.
29
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 users 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 21. 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.
30
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.
31
Example 1: client/server connection
Life of a Packet
IPsec
If the packet is transmitted through an IPsec tunnel, it is at this stage the encryption and required encapsulation is performed. For non-IPsec traffic (TCP/UDP) this step is bypassed.
Source NAT (SNAT)

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

The following example illustrates the flow of a packet of a client/web server connection with authentication and FortiGuard URL and antivirus filtering. This example includes the following steps: Initiating connection from client to web server 1 Client sends packet to web server. 2 Packet intercepted by FortiGate unit interface. 2.1 Link level CRC and packet size checking. If the size is correct, the packet continues, otherwise it is dropped. 3 DoS sensor - checks are done to ensure the sender is valid and not attempting a denial of service attack. 4 IP integrity header checking, verifying the IP header length, version and checksums. 5 Next hop route 6 Policy lookup 7 User authentication 8 Proxy inspection 8.1 Web Filtering 8.2 FortiGuard Web Filtering URL lookup 8.3 Antivirus scanning 9 Source NAT 10 Routing 11 Interface transmission to network 12 Packet forwarded to web server
32
Life of a Packet
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 9 Interface transmission to network 10 Packet returns to client
Figure 9: Client/server connection
3 2 1
Client sends packet to web server
FortiGate Unit
IP Integrity Header checking NAT (DNAT)
Interface (Link layer)
DoS Sensor
Stateful Policy Engine
Session Tracking
User Authentication
Policy Lookup
Routing
Proxy Inspection Engine
Antivirus
Web Filter
FortiGuard Web Filtering
FortiGuard
NAT (SNAT)
Routing
Packet Exits
Proxy Inspection Engine

Antivirus DoS Sensor IP Integrity Header checking Interface (Link layer)
Internet
Web Server
Packet Enters
NAT (SNAT)
Session Tracking
Routing

3 2
Packet exits and returns to client
33
Example 2: Routing table update
Life of a Packet
Example 2: Routing table update

This example includes the following steps: 1 FortiGate unit receives routing update packet 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 Stateful policy engine 5.1 Management traffic (local traffic) 6 Routing module 6.1 Update routing table
Figure 10: Routing table update
3 2 1
Routing update packet
Packet
FortiGate Unit
Interface (Link layer) DoS Sensor IP Integrity Header checking Management Traffic
Routing Table
Routing Module
Update routing table
Example 3: Dialup IPsec with application control

This example includes the following steps: 1 FortiGate unit receives IPsec packet from Internet 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 IPsec 5.1 Determines that packet matched IPsec phase 1 configuration 5.2 Unencrypted packet 6 Next hop route 7 Stateful policy engine 7.1 Session tracking
34
Life of a Packet
8 Flow inspection engine 8.1 IPS 8.2 Application control 9 Source NAT 10 Routing 11 Interface transmission to network 12 Packet forwarded to internal server Response from server 1 Server sends response packet 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 Flow inspection engine 5.1 IPS 5.2 Application control 6 Stateful policy engine 6.1 Session tracking 7 Next hop route 8 IPsec 8.1 Encrypts packet 9 Routing 10 Interface transmission to network 11 Encrypted Packet returns to internet
35
Life of a Packet
Figure 11: Dialup IPsec with application control

3 2 1
IPsec packet received from Internet
Encrypted or encapsulated packet
FortiGate Unit
Interface (Link layer) DoS Sensor IP Integrity Header checking IPsec NAT
Packet decryption
Application Control
IPS
Session Tracking
Next Hop Route
Flow Inspection Engine
Packet Exits
Source NAT Routing Interface (Link layer)
3 2 1
Internal Server
Destintion NAT DoS Sensor IP Integrity Header checking Interface (Link layer)
3 2 1
Response Packet
Packet Enters
Application Control IPS Session Tracking Next Hop Route
Flow Inspection Engine


Routing IPsec
Packet encryption
3 2
Packet Exits and returns to source
Encrypted or encapsulated packet
36
Firewall components
The FortiGate units 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 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 companys 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-60C has eight interfaces
Figure 12: FortiGate-60C physical interfaces
37
Interfaces
Firewall components
Figure 13: FortiGate-60C interfaces on the Dashboard
Figure 14: Configuring the FortiGate-60C 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).
38
Firewall components
Interfaces
Figure 15: FortiGate-3810A AMC card port naming
For more information on configuring physical ports, see Addressing on page 44.
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.
39
Interfaces
Firewall components
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
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.
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 providers 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.
40
Firewall components
Interfaces
Example
This example shows how to enable VDOMs on the FortiGate unit and the basic and create a VDOM accounting on the DMZ2 port and assign an administrator to maintain the VDOM. First enable Virtual Domains on the FortiGate unit. When you enable VDOMs, the FortiGate unit will log you out. To enable VDOMs - web-based manager 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 1 Go to System > Network > Interface. 2 Select the DMZ2 port row and select Edit. 3 For the Virtual Domain drop-down list, select accounting. 4 Select the Addressing Mode of Manual. 5 Enter the IP address for the port of 10.13.101.100/24. 6 Set the Administrative Access to HTTPS and SSH. 7 Select OK. To assign physical interface to the accounting Virtual Domain - CLI config global config system interface edit dmz2 set vdom accounting set ip 10.13.101.100/24 set allowaccess https ssh next end
41
Interfaces
Firewall components
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 addressesthe 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. 5 Select the Addressing Mode of Manual. 6 Enter the IP address for the port of 10.13.101.101/24. 7 Set the Administrative Access to HTTPS and SSH. 8 Select OK. To add a VLAN - CLI config system interface edit VLAN_1 set interface internal set type vlan set vlanid 100 set ip 10.13.101.101/24 set allowaccess https ssh next end
42
Firewall components
Interfaces
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. Each interface still has its own address and routing is still done between interfaces, that is, routing is not affected by zones. Firewall policies can also be created to control the flow of intra-zone traffic. 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 16: Network zones
Zone 1 policies
Zo
Zone 3
Zone 1 WAN1, DMZ1, VLAN 1, 2, 4
ne
2p
oli
cie
s
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.
policies
43
Addressing
Firewall components
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 > Interface. 2 Select the arrow on the Create New button and select Zone. 3 Enter a zone name of Zone_1. 4 Select the Internal interface and the virtual LAN interface vlan_accounting from the previous section. 5 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 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
Valid IP address and netmask formats include:
44
Firewall components
Addressing
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] 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 config firewall address edit Guest set type ipmask set subnet 10.13.101.100/24 set associated-interface port1 end
45
Addressing
Firewall components
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 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 range of 10.13.101.[100-110]. 5 For the Interface, select Any. 6 Select OK. To add a firewall IP address to the port1 interface - CLI config firewall address edit Guest set type iprange set start-ip 10.13.101.100 set end-ip 10.13.101.110 end
Geography based addressing

An option is available to add a geography-based address scheme. With this type of addressing, you indicated the geographic region, or country. The FortiGate unit includes an internal list of countries and IP addresses based on historical data from the FortiGuard network. When used in firewall policies, traffic originating or going to a particular country can be logged, blocked or specific filtering applied. In the following examples, an geographic-based address for China is added for the WAN1 port. To add a geography-based address - web-based manager 1 Go to Firewall > Address > Address and select Create New. 2 Enter the Name of China 3 For the Type, select Geography. 4 From the Country list, select China. 5 Select the Interface of WAN1. 6 Select OK. To add a geography-based address - CLI config firewall address edit China set type geography set country CN set interface wan1 end
46
Firewall components
Addressing
Wildcard masks
Wildcard masks, are common with OSPF and Cisco routers. The use of wildcard masks is most prevalent when building Access Control Lists (ACLs) on Cisco routers. ACLs are filters and make use of wildcard masks to define the scope of the address filter. Masks are used with IP addresses to specify what addresses are permitted and denied. To configure IP addresses on interfaces, the netmask starts with 255. For example, to filter a subnetwork 10.1.1.0 which has a Class C mask of 255.255.255.0, the ACL will require the scope of the addresses to be defined by a wildcard mask which, in this example is 0.0.0.255. When the value of the mask is shown in binary (0s and 1s), the results determine which address bits are the do and dont care bits for processing the traffic. A zero is the do care bit and the one is a dont care bit. This is also known as an inverse mask. For example, an address of 1.1.1.0, and a netmask of 0.0.0.255 would appear in binary as an address of 00000001.00000001.00000001.00000000 and a netmask of 00000000.00000000.00000000.11111111 Based on the binary mask, it can be seen that the first three octets of the address must match the given binary network address exactly (00000001.00000001.00000001). The last set of numbers is made of don't cares (all ones). As such, all traffic that begins with 1.1.1. matches since the last octet o the netmask is don't care. All IP addresses 1.1.1.1 through 1.1.1.255 are acceptable. Wildcard masks are configured in the CLI: config firewall address set type wildcard set wildcard 1.1.1.0/0.0.0.255 end
Fully Qualified Domain Name addresses

Using Fully Qualified Domain Name (FQDN) addresses in firewall policies has the advantage of causing the FortiGate unit to keep track of DNS TTLs and adapt as records change. As long as the FQDN address is used in a firewall policy, it stores the address in the DNS cache. The FortiGate unit will query the DNS for an amount of time specified, in seconds, and update the cache as required. This feature can reduce maintenance requirements for changing firewall addresses for dynamic IP addresses. This also means that you can create firewall policies for networks configured with dynamic addresses using DHCP.
Caution: Be cautious when employing FQDN firewall addresses. Using a fully qualified domain name in a firewall policy, while convenient, does present some security risks, because policy matching then relies on a trusted DNS server. Should the DNS server be compromised, firewall policies requiring domain name resolution may no longer function properly.
You specify the TTL time in the CLI only. For example, to set the TTL for 30 minutes on an FQDN of www.example.com on port 1, enter the following commands: config firewall address edit FQDN_example set type fdqn set associated-interface port 1 set fqdn www.example.com set cache-ttl 1800 end
47
Addressing
Firewall components
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 IPs mapped IP address. IP pools, similarly to virtual IPs, can be used to configure aspects of NAT; however, IP pools configure dynamic translation of packets IP addresses based on the Destination Interface/Zone, whereas virtual IPs configure dynamic or static translation of a packets IP addresses based upon the Source Interface/Zone. To implement the translation configured in the virtual IP or IP pool, you must add it to a NAT firewall policy.
Note: In Transparent mode, from the CLI, you can configure NAT firewall policies that include Virtual IPs and IP pools. For more information, see the System Administration 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 simple 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.
48
Firewall components
Addressing
When comparing packets with the firewall policy list to locate a matching policy, if a firewall policys Destination Address is a virtual IP, FortiGate units compare a packets destination address to the virtual IPs external IP address. If they match, the FortiGate unit applies the virtual IPs inbound NAT mapping, which specifies how the FortiGate unit translates network addresses and/or port numbers of packets from the receiving (external) network interface to the network interface connected to the destination (mapped) IP address or IP address range. In addition to specifying IP address and port mappings between interfaces, virtual IP configurations can optionally bind an additional IP address or IP address range to the receiving network interface. By binding an additional IP address, you can configure a separate set of mappings that the FortiGate unit can apply to packets whose destination matches that bound IP address, rather than the IP address already configured for the network interface.
DNAT and virtual IP

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 sources 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. You can define alternate IP addresses for the reply traffic. When configuring the VIP addresses, you can define alternate source addresses for the return traffic. When configuring the VIP, select the Source Address Filter option and enter the IP address or address range. The CLI command is: config firewall vip edit local-vip set src-filter 172.20.120.129/24, 172.20.120.3-172.20.120.10 set extip x.x.x.x set mappedip y.y.y.y set port-forward enable ... end This enables packets from different sources to be translated to different VIP (or ports). By default, the source filter is set to 0.0.0.0, or all source IPs.
Virtual IP options
The following table describes combinations of PAT and/or NAT that are possible when configuring a firewall policy with a virtual IP. 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 NATs load balancing style, if using dynamic NAT mapping full NAT vs. destination NAT (DNAT)
49
Addressing
Firewall components
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 Balancing Dynamic, one-to-many NAT mapping: an external IP address is translated to one 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.
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 17: 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 units 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.
50
Firewall components
Addressing
Figure 17: A simple static NAT virtual IP example
Int e 10 rnal .10 IP .10 .2 V 19 irtua 2.1 l IP 68 .37 .4

19 IP .55 nt 37 lie . C 168 2.
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 18: Example of packet address remapping during NAT from client to server .2 .10 .42 .10 0.10 10 IP 10.1 1 rce n IP u 3 So atio 2 n sti NA De T
Note that the client computers 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 computers 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.
IP r 42 ve 0 . er .1 S 10 .
10
wit
ha
vir
tua
l IP
1 3 2
5 7.5 4 8.3 .37. 6 2.1 68 19 92.1 IP 1 rce IP ou ation S in st De
51
Addressing
Firewall components
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 computers 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 servers 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 servers network. The client has no indication that the web servers IP address is not the virtual IP. As far as the client is concerned, the FortiGate units virtual IP is the web server.
Figure 19: Example of packet address remapping during NAT from server to client 2 0.4 2 0.1 .10. 0.1 10 P 1 0. e I IP 1 1 urc n 3 So inatio 2 st De NA T
wit
ha
vir
tua
l IP
1 3 2
7.4 5 8.3 37.5 .16 . 92 168 P 1 192. I rce IP ou tion S a tin es 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 clients IP address. For reply traffic, the FortiGate unit translates packets private network source IP address to match the destination address of the originating packets, which is maintained in the session table.
Outbound connections
Virtual IPs can also affect outbound NAT, even though they are not selected in an outbound firewall policy. If no virtual IPs are configured, FortiGate units apply traditional outbound NAT to connections outbound from private network IP addresses to public network IP addresses. However, if virtual IP configurations exist, FortiGate units use virtual IPs inbound NAT mappings in reverse to apply outbound NAT, causing IP address mappings for both inbound and outbound traffic to be symmetric. For example, if a network interfaces IP address is 10.10.10.1, and its bound virtual IPs 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.
52
Firewall components
Addressing
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.
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. 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.
53
Addressing
Firewall components
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 Netmask Default gateway Lease time DNS Server 1 192.168.1.110 to 192.168.1.210 255.255.255.0 192.168.1.99 7 days 192.168.1.99
A FortiGate interface can provide the following DHCP services: Basic DHCP servers with up to three IP address ranges per server IPSec DHCP servers for IPSec (VPN) connections DHCP relay for regular Ethernet or IPSec (VPN) connections
An interface cannot provide both a server and a relay for connections of the same type. You can configure one or more DHCP servers on any FortiGate interface. A DHCP server dynamically assigns IP addresses to hosts on the network connected to the interface. The host computers must be configured to obtain their IP addresses using DHCP. The IP range of each DHCP server must match the network address range. The routers must be configured for DHCP relay.
DHCP options
When adding a DHCP server, you have the ability to include DHCP codes and options. The DHCP options are BOOTP vendor information fields that provide additional vendor-independent configuration parameters to manage the DHCP server. For example, you may need to configure a FortiGate DHCP server that gives out a separate option as well as an IP address. For example, an environment that needs to support PXE boot with Windows images.
54
Firewall components
Addressing
The option numbers and codes are specific to the particular application. The documentation for the application will indicate the values to use. Option codes are represented in a option value/HEX value pairs. The option is a value 1 and 255. You can add up to three DHCP code/option pairs per DHCP server. To configure option 252 with value http://192.168.1.1/wpad.dat - web-based manager 1 Go to System > Network > DHCP Server and select Create New. 2 Select a Mode of Server. 3 Select the blue arrow to expand the Advanced options. 4 Select Options. 5 Enter a Code of 252. 6 Enter the Options of 687474703a2f2f3139322e3136382e312e312f777061642e646174. In the CLI, use the commands: config system dhcp server edit <dhcp_server_number> set option1 252 687474703a2f2f3139322e3136382e312e312f777061642e646174 end For detailed information about DHCP options, see RFC 2132, DHCP Options and BOOTP Vendor Extensions.
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 Go to System > Network > DHCP Server and select Create New. 2 Select the Interface of Internal. 3 Select the Mode of Server. 4 Enter the IP Range of 10.13.101.100 to 10.13.101.110. 5 Enter a Netmask of 255.255.255.0. 6 Enter a Default Gateway of 10.10.101.2. 7 Select the blue arrow to expand the Advanced options. 8 Set a Lease Time of five days. 9 Select OK.
55
Addressing
Firewall components
To configure a DHCP server on the internal interface - CLI config system dhcp server edit 1 config ip-range edit 1 set start-ip 10.13.101.100 set end-ip 10.13.101.105 end set server-type regular set interface internal 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 > Network > DHCP Server and select Create New. 2 Select the internal interface and select the Mode of Relay. 3 Select the Type of Regular. 4 Enter the DHCP Server IP address of 172.20.120.55. 5 Select OK. To configure a DHCP relay on the internal interface - CLI config system interface edit internal set dhcp-relay-service enable set dhcp-relay-type regular set dhcp-relay-ip 172.20.120.55 end
IP reservation with DHCP

Within the DHCP pool of addresses, you can ensure certain computers will always have the same address. This can be to ensure certain users always have an IP address when connecting to the network, or if you want a device that connects occasionally to have the same address for monitoring its activity or use. In the example below, the IP address 172.20.19.69 will be matched to MAC address 00:1f:5c:b8:03:57.
56
Firewall components
Addressing
To configure IP reservation - web-based manager 1 Go to System > Network > DHCP Server. 2 Select the DHCP server from the list. 3 Select IP Reservation and select Create New. 4 Enter an IP address of 172.20.19.69 5 Enter the MAC address of 00:1f:5c:b8:03:57. 6 Select OK. To configure IP reservation - CLI config sys dhcp server edit 1 config reserved-address edit 1 set ip 172.20.19.69 set mac 00:1f:5c:b8:03:57 end end Alternatively, an administrator can manually select an IP address from the assigned address list and set it to be linked to that MAC address automatically. To reserve an IP from an assigned list 1 Go to System > Network > DHCP Server. 2 Select the DHCP server from the list. 3 Select IP Reservation and select Add from DHCP Client List. 4 When the DHCP Client List window appears, select the check boxes beside the IP addresses and select Add to Reserved.
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) 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 (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
And the following IP pools:
The port1 interface overlap IP range with IP_pool_1 is: The port2 interface overlap IP range with IP_pool_2 is:
57
Addressing
Firewall components
(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 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.302.2.2.40
The port2 interface overlap IP range with IP_pool_3 is: And the result is:
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. IP pools cannot be set up for a zone. IP pools are connected to individual interfaces.
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.
58
Firewall components
Addressing
Source IP address and IP pool address matching

When the source addresses are translated to the IP pool addresses, one of the following three cases may occur: Scenario 1: The number of source addresses equals that of IP pool addresses In this case, the FortiGate unit always matches the IP addressed one to one. If you enable fixedport in such a case, the FortiGate unit preserves the original source port. This may cause conflicts if more than one firewall policy uses the same IP pool, or the same IP addresses are used in more than one IP pool.
Original address 192.168.1.1 192.168.1.2 ...... 192.168.1.254 Change to 172.16.30.1 172.16.30.2 ...... 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.
Original address 192.168.1.1 192.168.1.2 ...... 192.168.1.10 192.168.1.11 192.168.1.12 192.168.1.13 ...... Change to 172.16.30.10 172.16.30.11 ...... 172.16.30.19 172.16.30.10 172.16.30.11 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.
Original address 192.168.1.1 192.168.1.2 192.168.1.3 No more source addresses Change to 172.16.30.10 172.16.30.11 172.16.30.12 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.
59
Addressing
Firewall components
Where IPv4 uses 32 bit addressing, IPv6 uses 128 bit addressing, effectively providing trillions upon trillions of unique addresses, whereas IPv4 can have a a little over 4 billion. With this larger address space, allocating addresses and routing traffic becomes easier, and network address translation (NAT) becomes virtually unnecessary. Where IPv4 addresses are written numerals separated by a decimal, the IPv6 address is written with hexadecimal digits separated by a colon. For example, fe80:218:8bff:fe84:4223. By default, the FortiGate unit is not enabled to use IPv6 addressing. To enable this feature, go to System > Admin > Settings and select IPv6 Support on GUI. When enabled you can use IPv6 addressing on any of the address-dependant components of the FortiGate unit, including firewall policies, interface addressing, DNS servers. IPv6 addressing can be configured on the web-based manager and in the CLI. For further information on IPV6 in FortiOS, see IPV6 in the System Administration Guide chapter of The Handbook.
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 1 Go to System > Network > Interface. 2 Select WAN1 row and select Edit. 3 Select the Addressing Mode of Manual. 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 config system interface 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. 4 For the Address Name, enter Guest. 5 Enter the IP address of 2001:db8:0:1234:0:567:1:1/128.
60
Firewall components
Ports
6 Select OK. To add a firewall IPv6 address - CLI config firewall address6 edit Guest set ip6 2001:db8:0:1234:0:567:1:1/128 end
Ports
A port is a type of address used by specific applications and processes. The FortiGate unit uses a number of port assignments to send and receive information for basic system operation and communication by default.
Originating traffic
Function DNS lookup; RBL lookup FortiGuard Antispam or Web Filtering rating lookup FDN server list Source and destination port numbers vary by originating or reply traffic. NTP synchronization SNMP traps Port(s) UDP 53 UDP 53 or UDP 8888 UDP 53 (default) or UDP 8888, and UDP 1027 or UDP 1031 UDP 123 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 Management Service SMTP alert email; encrypted virus sample auto-submit LDAP or PKI authentication TCP 22 TCP 25 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 FortiGuard Analysis and Management Service log transmission (OFTP) SSL management tunnel to FortiGuard Analysis and Management Service FortiGuard Analysis and Management Service contract validation Quarantine, remote access to logs & reports on a FortiAnalyzer unit, device registration with FortiAnalyzer units (OFTP) RADIUS authentication TCP 443 TCP 514 TCP 541 TCP 10151 TCP 514 TCP 1812
61
Ports
Firewall components
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 FortiGuard Antivirus and IPS update push 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 FortiManager unit Telnet administrative access to the CLI; HA synchronization (FGCP L2) Changing the telnet administrative access port number also changes the HA synchronization port number. HTTP administrative access to the web-based manager Port(s) UDP 9443
TCP 22 TCP 23
TCP 80
HTTPS administrative access to the web-based manager; remote TCP 443 management from a FortiManager unit; user authentication for policy override SSL management tunnel from FortiGuard Analysis and Management Service TCP 541 (FortiOS v3.0 MR6 or later) HA heartbeat (FGCP L2) TCP 703 User authentication keep alive and logout for policy override (default value of TCP 1000 port for HTTP traffic) This port is closed until enabled by the auth-keepalive command. User authentication keepalive and logout for policy override (default value of port for HTTPS traffic) This port is closed until enabled by the auth-keepalive command. Windows Active Directory (AD) Collector Agent User authentication for policy override of HTTP traffic FortiClient download portal This feature is available on FortiGate-1000A, FortiGate-3600A, and FortiGate-5005FA2. User authentication for policy override of HTTPS traffic VPN settings distribution to authenticated FortiClient installations SSL VPN HA TCP 1003
TCP 8000 TCP 8008 TCP 8009
TCP 8010 TCP 8900 TCP 10443 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.
62
Firewall components
Services
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: config system interface edit <port_name> set ident-accept enable end For example, to disable ident responses on a network interface names port1, enter the following commands: config system interface edit port1 set ident-accept enable end
Port 541
By default, FortiGate units use this port to initiate an SSL-secured management tunnel connection to centralized device managers such as the FortiGuard Analysis and Management Service. If you do not use centralized management you can make your FortiGate unit less visible to probes. You can disable the management tunnel feature, and thereby close this port using the following CLI command: config sys central-management set status disable end
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.
63
Schedules
Firewall components
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 Protocol Type Protocol Source Port Low Hi Destination Port Low High 4545 4550 9620 9620 Widget TCP/UDP/SCTP TCP
3 Select OK. 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.
64
Firewall components
Schedules
3 Select the days of the week this schedule is employed. In this case, Monday through Friday. 4 Select the Start Hour of 12. 5 Select the Stop Hour of 01. 6 Select OK. To create a recurring firewall schedule - CLI config firewall schedule recurring edit Lunch-Surfing
set day monday tuesday wednesday thursday friday
set start 12:00 set end 1:00

end
Example
This example creates a one-time schedule for a firewall policy. In this example, a company is shut down over the Christmas holidays. To prevent employees from coming to work to use the internet connection, the company sets up a one-time firewall policy to block most internet traffic during this time period. A schedule needs to be created to limit internet traffic between December 25 and January 1. 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 Month Day Hour Minute Stop Year Month Day Hour Minute 2010 01 01 23 00 2009 12 25 00 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
65
Schedules
Firewall components
Schedule groups
You can organize multiple firewall schedules into a schedule group to simplify your firewall policy list. For example, instead of having five identical policies for five different but related firewall schedules, you might combine the five schedules into a single schedule group that is used by a single firewall policy. Schedule groups can contain both recurring and one-time schedules. Schedule groups cannot contain other schedule groups.
Example
This example creates a schedule group for the schedules created in the previous schedule examples. The schedule group enables you to have one firewall policy that covers both schedules, rather than creating two separate policies. To create a firewall schedule group - web-based manager 1 Go to Firewall > Schedule > Group, and select Create New. 2 Enter the group Name of Schedules. 3 From the Available Schedules list, select the Lunch-Surfing schedule and select the down-arrow button to move the address name to the Members list. 4 From the Available Schedules list, select the Xmas-Shutdown schedule and select the down-arrow button to move the address name to the Members list. 5 Select OK. To create a recurring firewall schedule - CLI config firewall schedule group edit Schedules set member Lunch-Surfing Xmas-Shutdown end
Schedule expiry
The schedule in a firewall policy enables certain aspects of network traffic to occur for a specific length of time. What it does not do however, is police that time. That is, the policy is active for a given time frame, and as long as the session is open, traffic can continue to flow. For example, in an office environment, Skype use is allowed between noon and 1pm. During that hour, any Skype traffic continues. As long as that session is open, after the 1pm end time, the Skype conversations can continue, yet new sessions will be blocked. Ideally, the Skype session should close at 1pm. Using a CLI command you can set the schedule to terminate all sessions when the end time of the schedule is reached. Within the config firewall command enter the command: set schedule-timeout enable By default, this is set to disable.
Identity-based policies
It is important to note that this setting is similar to the termination time of an identity-based policy, also known as an authentication policy. These can be used together. If user authentication is used, FortiOS will use the Hard Timeout option. With a combination of the schedule timeout and the authentication timeout, FortiOS will use whichever time is shorter.
66
Firewall components
UTM profiles
For example, Example.com has a schedule policy to use P2P applications between 12:00 and 1:00, and a user authentication timeout of 30 minutes. With user authentication, if a user logs in at 12:15, their authentication time will log them off at 12:45 (30 minutes later). If they log in at 12:45, the firewall schedule will log them out at 1:00 (15 minutes later). Equally, if no authentication is used, and a user logs in at 12:45, the schedule will log them out at 1:00 (45 minutes later). If they log in at 12:55, they will also be logged out at 1:00 (5 minutes later). The following table illustrates this point:
Authentication Yes Session Start 12:15 12:45 No 12:15 12:55 Session end 30 minutes (expire at 12:45 - authentication timeout of 30 minutes) 15 minutes (expire at 1:00 - end of the firewall schedule) 45 minutes (expire at 1:00 - end of firewall schedule) 5 minutes (expire at 1:00 - end of firewall schedule)
For more information on authentication policies, see the System Administration Guide chapter of The Handbook.
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 dont 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.
67
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 the plus sign in the upper right corner of the window. 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
68
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 packets 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 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 sessions initiation Service and the packets 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. Packet handling actions can be ACCEPT, DENY, IPSEC or SSL-VPN.
69
Policy order
Firewall Policies
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 policys specified actions to the packet, and disregards subsequent firewall policies. Matching firewall policies are determined by comparing the firewall policy and the packets: 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. 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.
70
Firewall Policies
Creating basic policies
Figure 20: 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 21: Example: Blocking FTP Incorrect policy order
}Exception
}General
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.

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 Source address Destination interface/Zone Destination address Internal 10.13.20.22 WAN1 172.20.120.141
71
Firewall Policies
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.
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:
Source interface/Zone Source address Destination interface/Zone Destination address Schedule Service Action Internal 10.13.20.22 WAN1 ALL always HTTP ALLOW
To create a basic accept policy for HTTP - CLI

config firewall policy
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.
72
Firewall Policies
To create a basic deny policy for FTP - web-based manager 1 Go to Firewall > Policy > Policy and select Create New. 2 Enter the following and select OK:
Source interface/Zone Source address Destination interface/Zone Destination address Schedule Service Action Internal 10.13.20.22 WAN1 172.20.120.141 always FTP DENY
To create a basic accept policy for FTP - CLI

edit 1 set srcintf internal 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 1 Go to Firewall > Policy > Policy and select Create New. 2 Enter the following and select OK:
Source interface/Zone Source address Destination interface/Zone Destination address Schedule Service Action VPN Tunnel Internal 10.13.20.22 WAN1 172.20.120.141 always any IPSEC Select Head_Office from the configured list of VPN tunnels.
73
Firewall policy examples
Firewall Policies
To create a basic VPN tunnel - CLI

edit 1 set srcintf internal set srcaddr 10.13.20.22 set dstintf wan1 set dstaddr 172.20.120.141 set action allow set schedule always set service any set vpntunnel Head_Office end

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 1 Go to Firewall > Address > Address and select Create New. 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 config firewall address 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.
74
Firewall Policies
To add a firewall policy - web-based manager 1 Go to Firewall > Policy > Policy and select Create New. 2 Complete the following and select OK:
Source Interface/Zone Source Address Destination Interface/Zone Destination Address Schedule Service Action WAN1 Blocked_IP Internal All Always ALL 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 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 63. 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.
75
Firewall Policies
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. 8 Select the Start Hour of 12. 9 Select the Stop Hour of 14. 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. 14 Select the Start Hour of 18. 15 Select the Stop Hour of 08. 16 Select OK. To configure schedules - web-based manager config firewall schedule recurring edit week-end set day sunday saturday next edit lunch-time set day monday tuesday wednesday thursday friday set end 14:00 set start 12:00 next edit late evening to early morning set day monday tuesday wednesday thursday friday set end 08:00 set start 18:00 next end
76
Firewall Policies
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 1 Go to Firewall > Address > Address and select Create New. 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. 5 Select Create New. 6 Enter the Name of example.com 7 Select the Type of FQDN. 8 Enter the FQDN of www.example.com. 9 Select OK. 10 Select Create New. 11 Enter the Name example2.com 12 Select the Type of FQDN. 13 Enter the FQDN of www.example2.com. 14 Select OK. To configure addresses and web sites - CLI config firewall address 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 1 Go to Firewall > Policy > Policy and select Create New. 2 Complete the following for the weekend access policy and select OK:
77
Firewall Policies
Source Interface/Zone Source Address Destination Address Schedule Service Action NAT Comments
Internal All All week-end ALL Accept Select to Enable. Week-end policy.
Destination Interface/Zone WAN1
3 Select Create New. 4 Complete the following for the administrator access policy and select OK:
Source Interface/Zone Source Address Destination Address Schedule Service Action NAT Comments Internal Admin_PCs All Always ALL Accept Select to Enable. Admin PCs no restriction.
5 Select Create New. 6 Complete the following for the lunch-time surfing policy and select OK
:
Internal All All lunch-time ALL Accept Select to Enable. Lunch-time policy.
7 Select Create New. 8 Complete the following for the overnight policy and select OK
:
Source Interface/Zone Source Address Destination Address Schedule Service Action
Internal All All late_eveing_early_morning ALL Accept
78
Firewall Policies
NAT Comments
Select to Enable. Late evening to early morning policy.
9 Select Create New. 10 Complete the following for the web site access policy and select OK
:
Internal All All Always ALL Accept Select to Enable. Access to the example.com websites policy.
Destination Interface/Zone example.com and example2.com
To create the firewall policies - CLI config firewall policy edit 1 set srcintf internal set dstintf wan1 set srcaddr all set dstaddr all set action accept set comments week-end policy set schedule week-end set service ANY set nat enable next edit 2 set srcintf internal 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 srcintf internal 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
79
Firewall Policies
edit 4 set srcintf internal 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 srcintf internal 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
80
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. For more troubleshooting options and methods, see the Troubleshooting Guide chapter of The Handbook. This chapter includes the topics: Basic policy checking Verifying traffic Using log messages to view violation traffic Traffic trace Packet sniffer
Basic policy checking

Before going into a deep troubleshooting session, first verify a few simple settings in the firewall policy configuration to ensure everything is setup correctly. For example: Verify the policy position. The FortiGate unit evaluates each policy in the firewall policy list for a match until a match is found. When the FortiGate unit finds the first matching policy, it applies the matching policys 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 70. Verify that the source and destination ports and their addresses (IP Pools and virtual IPs) are selected correctly for the correct subdomain. Ensure that the NAT check box is selected in the policy. If you selected a virtual IP as the destination address, but did not select the NAT option, the FortiGate unit performs destination NAT rather than full NAT. Verify that the UTM profiles you selected are properly configured, and that any URLs or IP addresses are entered correctly. Verify that the policy is enabled. In the firewall policy list (Firewall > Policy > Policy), the Status column indicates whether a firewall policy is enabled or not. To be enabled, the check box must be selected.
Verifying traffic
With many firewall policies in place, you may want to verify that traffic is being affected by the policy. There is a simple way to get a quick visual confirmation within the web-based manager. This is done by adding a counter column to the firewall policy table. These steps are only available in the web-based manager.
81
Using log messages to view violation traffic
Troubleshooting
To view the traffic count on firewall policies 1 Go to Firewall > Policy > Policy. 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 packets 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 1 Go to Firewall > Policy > Policy and select Create New. 2 Enter the following:
Source interface/Zone Source address Destination interface/Zone Destination address Schedule Service Action Internal 10.13.20.22 WAN1 172.20.120.141 always HTTP DENY
3 Select Log Violation Traffic. 4 Select OK.
82
Troubleshooting
Traffic trace
To create a basic accept policy for FTP - CLI

edit 1 set srcintf internal set srcaddr 10.13.20.22 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 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.
83
Traffic trace
Troubleshooting
Sample output
session info: proto=6 proto_state=05 expire=89 timeout=3600 flags=00000000 av_idx=0 use=3 bandwidth=204800/sec guaranteed_bandwidth=102400/sec traffic=332/sec prio=0 logtype=session ha_id=0 hakey=4450 tunnel=/ state=log shape may_dirty statistic(bytes/packets/err): org=3408/38/0 reply=3888/31/0 tuples=2 orgin->sink: org pre->post, reply pre->post oif=3/5 gwy=192.168.11.254/10.0.5.100 hook=post dir=org act=snat 10.0.5.100:1251>192.168.11.254:22(192.168.11.105:1251) hook=pre dir=reply act=dnat 192.168.11.254:22>192.168.11.105:1251(10.0.5.100:1251) pos/(before,after) 0/(0,0), 0/(0,0) misc=0 domain_info=0 auth_info=0 ftgd_info=0 ids=0x0 vd=0 serial=00007c33 tos=ff/ff Filter options enable you to view specific information from this command: diagnose sys session filter <option> The <option> values available include the following: clear dport dst negate policy proto sport src vd clear session filter dest port destination IP address inverse filter policy ID protocol number source port source IP address 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
Meaning Session is being logged. Session is originated from or destined for local stack. Session is created by a firewall session helper. 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. Session will be checked by IPS signature. Session will be checked by IPS anomaly. Session is being bridged (TP) mode.
The table below shows the firewall session states from the session table:
State log local ext may_dirty
ndr nds br
84
Troubleshooting
Traffic trace
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 entry entry entry entry entry entry entry used used used used used used used used by by by by by by by by table table table table table table table table firewall.address:name '10.98.23.23_host firewall.address:name 'NAS' firewall.address:name 'all' firewall.address:name 'fortinet.com' firewall.vip:name 'TORRENT_10.0.0.70:6883' firewall.policy:policyid '21' firewall.policy:policyid '14' firewall.policy:policyid '19'
In this example, the interface has dependent objects, including four address objects, one VIP, and three firewall policies.
Flow trace
To trace the flow of packets through the FortiGate unit, use the command diagnose debug flow trace start Follow the packet flow by setting a flow filter using the command: diagnose debug flow filter <option> Filtering options include: addr clear daddr dport negate port proto saddr IP address clear filter destination IP address destination port inverse filter port protocol number source IP address
85
Traffic trace
Troubleshooting
sport vd
source port index of virtual domain, -1 matches all
Enable the output to in the console: diagnose debug flow show console enable Start flow monitoring with a specific number of packets using the command: diagnose debug flow trace start <N> Stop flow tracing at any time using: diagnose debug flow trace stop
Sample output
This an example shows the flow trace for the device at the IP address 203.160.224.97. diag debug enable diag debug flow filter addr 203.160.224.97 diag debug flow show console enable diag debug flow show function-name enable diag debug flow trace start 100
Flow trace output example - HTTP

Connect to the web site at the following address to observe the debug flow trace. The display may vary slightly: http://www.fortinet.com Comment: SYN packet received: id=20085 trace_id=209 func=resolve_ip_tuple_fast line=2700 msg="vd-root received a packet(proto=6, 192.168.3.221:1487->203.160.224.97:80) from port5." SYN sent and a new session is allocated: id=20085 trace_id=209 func=resolve_ip_tuple line=2799 msg="allocate a new session-00000e90" Lookup for next-hop gateway address: id=20085 trace_id=209 func=vf_ip4_route_input line=1543 msg="find a route: gw-192.168.11.254 via port6" Source NAT, lookup next available port: id=20085 trace_id=209 func=get_new_addr line=1219 msg="find SNAT: IP-192.168.11.59, port-31925" direction Matched firewall policy. Check to see which policy this session matches: id=20085 trace_id=209 func=fw_forward_handler line=317 msg="Allowed by Policy-3: SNAT" Apply source NAT: id=20085 trace_id=209 func=__ip_session_run_tuple line=1502 msg="SNAT 192.168.3.221->192.168.11.59:31925" SYN ACK received: id=20085 trace_id=210 func=resolve_ip_tuple_fast line=2700 msg="vd-root received a packet(proto=6, 203.160.224.97:80>192.168.11.59:31925) from port6."
86
Troubleshooting
Traffic trace
Found existing session ID. Identified as the reply direction: id=20085 trace_id=210 func=resolve_ip_tuple_fast line=2727 msg="Find an existing session, id-00000e90, reply direction" Apply destination NAT to inverse source NAT action: id=20085 trace_id=210 func=__ip_session_run_tuple 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:
id=20085 trace_id=211 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: id=20085 trace_id=211 func=resolve_ip_tuple_fast line=2727 msg="Find an existing session, id-00000e90, original direction" Apply source NAT: id=20085 trace_id=211 func=__ip_session_run_tuple 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: id=20085 trace_id=212 func=resolve_ip_tuple_fast line=2727 msg="Find an existing session, id-00000e90, original direction" Apply source NAT: id=20085 trace_id=212 func=__ip_session_run_tuple line=1502 msg="SNAT 192.168.3.221->192.168.11.59:31925" Receive data from server: id=20085 trace_id=213 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." Match existing session in reply direction: id=20085 trace_id=213 func=resolve_ip_tuple_fast line=2727 msg="Find an existing session, id-00000e90, reply direction" Apply destination NAT to inverse source NAT action: id=20085 trace_id=213 func=__ip_session_run_tuple line=1516 msg="DNAT 192.168.11.59:31925>192.168.3.221:1487"
87
Packet sniffer
Troubleshooting
Packet sniffer
The packet sniffer in the FortiGate unit can sniff traffic on a specific Interface or on all Interfaces. There are 3 different Level of Information, a.k.a. Verbose Levels 1 to 3, where verbose 1 shows less information and verbose 3 shows the most information. Verbose levels in detail: 1Print header of packets 2Print header and data from the IP header of the packets 3Print header and data from the Ethernet header of the packets 4Print header of packets with interface name 5Print header and data from IP of packets with interface name 6Print header and data from ethernet of packets with interface
diagnose sniffer packet <interface> <'filter'> <verbose> <count>
All Packet sniffing commands are in the format: ... where... <interface> <verbose> <count> <'filter'> can be an Interface name or any for all Interfaces. An interface can be physical, VLAN, IPsec interface, Link aggregated or redundant. the level of verbosity as described above. the number of packets the sniffer reads before stopping. is a very powerful filter functionality which will be described below.
Simple trace example

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

In this example, the packet sniffer sniff 3 packets of all traffic with verbose 1evel 1 on internal interface diagnose sniffer packet internal none 1 3 The none variable means no filter applies, 1 means verbose level 1 and 3 means catch 3 packets and stop. The resulting output is
192.168.0.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.
88
Troubleshooting
Packet sniffer
With information level set to verbose 1, the source and destination IP address is visible, as well as source and destination port. The corresponding Sequence numbers is also visible.
Note: If you do not enter a <count> value, for example as above, 3, the sniffer will continue to run until you stop it.
Verbose levels 2 and 3

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

In this example, use the filter option of the sniffer to see the traffic information between two PCs or a PC and a FortiGate unit. Using the following command: diagnose sniffer packet internal 'src host 192.168.0.130 and dst host 192.168.0.1' 1 The resulting output is:
192.168.0.130.3426 -> 192.168.0.1.80: syn 1325244087 192.168.0.1.80 -> 192.168.0.130.3426: syn 3483111189 ack 1325244088 192.168.0.130.3426 -> 192.168.0.1.80: ack 3483111190 192.168.0.130.3426 -> 192.168.0.1.80: psh 1325244088 ack 3483111190 192.168.0.1.80 -> 192.168.0.130.3426: ack 1325244686 192.168.0.130.1035 -> 192.168.0.1.53: udp 26 192.168.0.130.1035 -> 192.168.0.1.53: udp 42 192.168.0.130.1035 -> 192.168.0.1.53: udp 42 192.168.0.130 -> 192.168.0.1: icmp: echo request 192.168.0.130.3426 -> 192.168.0.1.80: psh 1325244686 ack 3483111190 192.168.0.1.80 -> 192.168.0.130.3426: ack 1325244735 192.168.0.130 -> 192.168.0.1: icmp: echo request
Assuming there is a lot of traffic, this filter command will only display traffic (but all traffic) from the source IP 192.168.0.130 to the destination IP 192.168.0.1. It will not show traffic to 192.168.0.130 (for example the ICMP reply) because the command included: 'src host 192.168.0.130 and dst host 192.168.0.1' Additional information such as ICMP or DNS queries from a PC are included. If you only require a specific type of traffic, for example, TCP traffic only, you need to change the filter command as below:
89
Packet sniffer
Troubleshooting
diagnose sniffer packet internal 'src host 192.168.0.130 and dst host 192.168.0.1 and tcp' 1
The resulting output would be:

192.168.0.130.3569 -> 192.168.0.1.23: syn 1802541497 192.168.0.1.23 -> 192.168.0.130.3569: syn 4238146022 ack 1802541498 192.168.0.130.3569 -> 192.168.0.1.23: ack 4238146023
Though ICMP (ping) was also running, the trace only shows the TCP part. The destination IP is 192.168.0.1.23, which is IP 192.168.0.1 on port 23 - a Telnet session.
90

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
91
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 2 describes the companys goals and the FortiGate options that meet them.
Table 2: 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 workers with static or dynamic IP addresses. Use a secure VPN client solution. Configure secure IPSec VPN tunnels for remote access employees. Use Dynamic Domain Name Server (DDNS) VPN for users with dynamic IP addresses. Use 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 113.
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 118. Block access by all employees to potentially offensive web content. Severely limit web access for certain employees (help desk) during work hours. Enable FortiGuard web content filtering solution. See Configuring web category block settings on page 101. Create a schedule that covers business hours, create a custom web access solution, and include these in a firewall policy for specific addresses. See Configuring settings for the Help Desk department on page 106.
Topology
Figure 22 shows the The Example Corporation network configuration after installation of the FortiGate-100A.
92
Figure 22: SOHO network topology with FortiGate-100A
H 19 om 2. e 16 Us 8. er 90 1 .1 2
el
17 Exte 2.2 rn 0.1 al 20 .14 1 al ern .1 Int 1.10 .1 10 D 10 MZ .20 .10
H 19 om 2. e 16 Us 8. er 21 2 .1 2
VPN
Tun n
n Tun VPN
el
.1
Features used in this example

The following table lists the FortiGate features implemented in the Example Corporation example network.
E 10 ma .2 il S 0. e 10 rv .2 er
W 10 eb .2 S 0. er 10 ve .3 r rs se U g 51 0 rin 1. 10 ee 10 1. in 1. 10 ng .1 . E 10 .11 10
rs se U 10 . 0 ce 01 .2 an .1 01 in 1 1 F .1 1. 10 0.1 1 rs se U k .21 0 es 1 5 D 0 1. p .1 0 el 11 .1 H 0. .11 1 0 1
93
First steps
System
Configuring FortiGate network interfaces on page 94 Configuring DNS forwarding on page 96 Scheduling automatic antivirus and attack definition updates on page 97 Setting the time and date on page 97 Configuring administrative access and passwords on page 98 Registering the FortiGate unit on page 97 Adding the default route on page 95 Removing the default firewall policy on page 96 Adding firewall policies for different addresses and address groups, see Configuring firewall policies for Finance and Engineering on page 105, Configuring firewall policies for help desk on page 110, and Configuring firewall policies for the VPN tunnels on page 116 Adding addresses and address groups, see Adding the Finance and Engineering department addresses on page 100, Adding the Help Desk department address on page 106, Adding addresses for home-based workers on page 113, Adding the web server address on page 119, and Adding the email server address on page 122 Creating a recurring schedule on page 110 Configuring remote access VPN tunnels on page 113 (IPSec) Scheduling automatic antivirus and attack definition updates on page 97 Configuring antivirus grayware settings on page 102 enabling virus scanning (see Configuring protection profiles) Scheduling automatic antivirus and attack definition updates on page 97 Configuring web category block settings on page 101 (FortiGuard) Creating and Configuring URL filters on page 107 Configuring FortiGuard spam filter settings on page 101
Router Firewall
VPN IPS Antivirus
Web Filter Spam Filter
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 internal Administrative access 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.
94
First steps
wan1 dmz1
HTTPS for remote access to the web-based manager from the Internet. PING access for troubleshooting.
To configure FortiGate network interfaces - web-based manager 1 Go to System > Network > Interface. 2 Select the Internal interface row and select Edit:
Addressing mode IP/Netmask Administrative access Manual 10.11.101.1/255.255.255.0 HTTPS, PING, SSH
3 Select OK. 4 Select the wan1 interface row and select Edit:
Addressing mode IP/Netmask Administrative access Manual 172.20.120.141/255.255.255.0 HTTPS
5 Select OK. 6 Select the dmz1 interface row and select Edit:
Addressing mode IP/Netmask Administrative access Manual 10.20.10.1/255.255.255.0 PING
7 Select OK. To configure the FortiGate network interfaces - CLI config system interface 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 1 Go to Router > Static > Static Route. 2 Select the default route and enter the following information:
95
First steps
Destination IP/ Mask Device Gateway Distance
0.0.0.0/0.0.0.0 wan1 172.20.120.39 10
3 Select OK.
Note: Entering 0.0.0.0 as the IP and mask represents any IP address.
To add the default route - CLI config router static edit 1 set device wan1 set gateway 172.20.120.39 set distance 10 end
Removing the default firewall policy

The FortiGate-100A comes pre configured 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 1 Go to Firewall > Policy > 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 config firewall policy 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 Secondary DNS Server 239.120.20.1 239.10.30.31
3 Select OK.
96
First steps
To configure DNS forwarding - CLI config system dns set autosvr disable set primary 239.120.20.1 set secondary 239.10.30.31 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. 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.
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.
97
First steps
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. 2 Select Create New. 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:
Administrator Password Confirm Password Trusted Host #1 Trusted Host #2 Admin Profile admin_2 <psswrd> <psswrd> 10.11.101.60 / 255.255.255.255 (administrators computer) 10.11.101.51 / 255.255.255.255 (lab computer) admin_monitor
8 Select OK.
98
First steps
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 check box for the admin name and select Change Password. 3 Enter the new password and enter it again to confirm. 4 Select OK. To change the admin password - CLI config system admin edit <admin_name> set password <psswrd> end
99
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 Configuring FortiGuard spam filter settings Configuring a corporate set of UTM profiles Configuring firewall policies for Finance and Engineering
Protect the network from spam and outside threats. Tasks include:
Control traffic and maintain security. Tasks include:
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 1 Go to Firewall > Address > Address. 2 Select Create New and enter or select the following settings:
Address Name Type Subnet / IP Range Interface Finance Subnet / IP Range 10.11.101.10 - 10.11.101.20 Internal
3 Select OK. 4 Repeat to add an address called Eng with the IP Range 10.11.101.5110.11.101.99. To add address ranges for Finance and Engineering - CLI config firewall address 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
100
To include the Finance and Eng addresses in an address group - web-based manager 1 Go to Firewall > Address > Group. 2 Select Create New. 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 1 Go to System > Maintenance > FortiGuard. 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 1 Go to System > Maintenance > FortiGuard. 2 Expand Web Filtering and Email Filtering Options.
101
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 users 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. 2 Select the Create New icon in the upper corner of the screen. 3 Enter standard_profile as the Profile Name. 4 For Virus Scan select HTTP, FTP, IMAP, POP3, and SMTP. 5 Select OK.
102
To create and configure a antivirus profile - CLI

config antivirus profile 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. 2 Select Create New icon in the upper corner of the window. 3 Enter standard_profile as the Profile Name. 4 Select OK. 5 Select Add Filter. 6 Select the following:
Potentially Liable Controversial Adult Materials Extremist Groups Pornography Potentially Non-productive Games Potential Bandwidth Consuming Potentially Security Violating General Interest Job Search Social Networking Shopping and Auction
Select Block and then OK.
103
To create and configure a web filter profile - CLI

config webfilter profile
edit standard_profile config ftgd-wf set enable g01 8 12 14 20 g04 g05 34 37 42 end config http set options fortiguard-wf end end
Email filter UTM profile

The email filter profile contains banned word listings that the FortiGate will check against when sending email. Banned words are those keywords that The Example Company does not want sent onto the Internet. For brevity, the two words to block are naked and finances. To create a banned word list - web-based manager 1 Go to UTM > Email Filter > Banned Word. 2 Select Create New. 3 Enter a group Name of checked_terms and select OK. 4 Select Create New. 5 Enter the Pattern naked. 6 Set the Pattern Type to Regular Expression. 7 Select OK, and repeat for the word finances. To create a banned word list - CLI config spamfilter bword edit 1 set name checked_terms config entries edit id 1 set name naked end set id 2 set name finances end end end To create and configure a email filter profile - web-based manager 1 Go to UTM > Email Filter > Profile. 2 Select Create New icon in the upper corner of the window. 3 Enter standard_profile as the Profile Name. 4 Select Enable Spam Detection and Filtering. 5 Select the blue arrow for Local Spam Filtering to expand the options. 6 Select IP Address BWL Check and select the entry from the drop-down list. 7 Select OK.
104
To create and configure a email filter profile - CLI config spamfilter profile edit standard_profile config smtp set spam-ipbwl-table 1 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
To configure the Finance and Engineering firewall policy - web-based manager 1 Go to Firewall > Policy > Policy. 2 Select Create New. 3 Enter or select the following settings:
Source Interface / Zone Source Address Destination Interface / Zone Destination Address Schedule Service Action internal FinEng wan1 All Always ANY ACCEPT
4 Select Enable NAT. 5 Select UTM. 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.
105
Configuring settings for the Help Desk department
To configure the Finance and Engineering firewall policy - CLI config firewall policy edit 1 set action accept set dstaddr all set dstintf wan1 set schedule always set service ANY set srcaddr FinEng set srcintf internal 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

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.
Goals
Provide complete control of web access. Tasks include: Adding the Help Desk department address Creating and Configuring URL filters Creating a recurring schedule Configuring firewall policies for help desk
Enable greater access at certain times. Tasks include: Control traffic and maintain security. Tasks include:
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 1 Go to Firewall > Address > Address. 2 Select Create New and enter or select the following settings:
Address Name Type Subnet / IP Range Interface Help_Desk Subnet / IP Range 10.11.101.21 - 10.11.101.50 Any v3 FortiGate Fundamentals 01-430-112804-20110228 http://docs.fortinet.com/ Feedback
106
3 Select OK. Adding the help desk department address - CLI config firewall address 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. 2 Select Create New icon in the upper corner of the window. 3 Enter Example_URL_Filter as the name. 4 Select OK. To create a filter list for blocked URLs - CLI config webfilter urlfilter edit # (select any unused number) set name Example_URL_Filter end To configure a URL block - web-based manager 1 Go to UTM > Web Filter > URL Filter. 2 Select Example_URL_Filter and select Edit. 3 Select Create New. 4 Enter the following settings:
URL Type Action .* Regex Block
5 Select Enable. 6 Select OK. This pattern blocks all web sites. To configure URL block - CLI config webfilter urlfilter edit # config entries edit .* set action block
107
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 1 Go to UTM > Web Filter > URL Filter. 2 Select Example_URL_Filter and select Edit. 3 Select Create New. 4 Enter the following settings:
URL Type Action www.example.com Simple Exempt
5 Select Enable. 6 Select OK. 7 Repeat for each of the following URLs: intranet.example.com www.dictionary.com www.ExampleReferenceSite.com To configure URL exempt - CLI config webfilter urlfilter 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
108
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. 2 Select Create New icon in the upper corner of the window. 3 Enter help_desk_work as the Profile Name. 4 Select Add Filter. 5 For the Filter Type, select URL List. 6 For Web URL Filter, select help_desk_work. 7 Select OK, then Apply. To create and configure a web filter profile - CLI
config webfilter profile
edit help_desk_work config web set urlfilter-table 1 end end
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 config webfilter urlfilter 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. 2 Select Create New.
109
3 Enter the profile name of IM_P2P. 4 Select OK. 5 Select Create New. 6 In the Category list, select Specify, then select IM. 7 Set the Action to Block and Select OK. 8 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
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. 2 Select Create New. 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 config firewall schedule recurring edit Lunch set day monday tuesday wednesday thursday friday 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 105.
110
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 1 Go to Firewall > Policy > Policy. 2 Expand the internal -> wan1 entry and select the Insert Policy before icon beside policy 1. 3 Enter or select the following settings:
Source Interface / Zone Source Address Destination Interface / Zone Destination Address Schedule Service Action internal Help_Desk wan1 All Always ANY ACCEPT
4 Select Enable NAT. 5 Select UTM. 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 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).
14 Select Create New. 15 Enter or select the following settings:

Source Interface / Zone Source Address Destination Interface / Zone Destination Address Schedule Service Action internal Help_Desk wan1 All lunch ANY ACCEPT
16 Select Enable NAT. 17 Select UTM.
111
18 Select Enable Antivirus and select standard_profile. 19 Select Enable IPS and select all_default. 20 Select Enable Web Filter and select standard_profile. 21 Select Enable Email Filter and select standard_profile. 22 Select OK. Configuring firewall policies for help desk - CLI config firewall policy 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 srcintf internal 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 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 srcintf internal 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 next move 2 before 1 move 3 before 2 end
112
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
Control traffic and maintain security. Tasks include:
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 1 Go to Firewall > Address > Address. 2 Select Create New and enter or select the following settings:
Address Name Type Subnet / IP Range Interface Example_Network Subnet / IP Range 192.168.100.0 Any
3 Select OK. 4 Select Create New and enter or select the following settings:
Address Name Type Subnet / IP Range Interface Home_User_1 Subnet / IP Range 220.100.65.98 Any
5 Select OK. To add addresses for home-based workers - CLI config firewall address 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
113
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 Remote Gateway IP Address Local Interface Mode Authentication Method Pre-shared Key Home1 (The name for the peer that connects to the The Example Corporation network.) Static IP Address 220.100.65.98 wan1 Main (ID protection) Note: The VPN peers must use the same mode. Preshared 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. Accept any peer ID
Peer options
4 Select OK. 5 Select Create Phase 1. 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.) example.net wan1 Main (ID protection) Note: The VPN peers must use the same mode. Preshared Key
Remote Gateway Dynamic DNS Dynamic DNS Local Interface Mode Authentication Method
114
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. Accept any peer ID
Peer options
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 set set set set set end
type ddns interface wan1 authmethod psk psksecret GT3wlf76FKN5f43U remotewgw-ddns example.net peertype any
To configure IPSec phase 2 1 Go to VPN > IPSEC > Auto Key (IKE). 2 Select Create Phase 2. 3 Enter or select the following settings:
Name Phase 1 Home1_Tunnel Home1
4 Select OK. 5 Select Create Phase 2. 6 Enter or select the following settings:
Name Phase 1 Home2_Tunnel Home2
7 Select OK. To configure IPSec phase 2 using the CLI config vpn ipsec phase2 edit Home1_Tunnel set phase1name Home1
115
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 1 Go to Firewall > Policy > Policy. 2 Select Create New and enter or select the following settings for Home_User_1:
Source Interface / Zone Source Address Destination Interface / Zone Destination Address Schedule Service Action VPN Tunnel Allow Inbound Allow outbound Inbound NAT Outbound NAT internal Example_Network wan1 Home_User_1 Always ANY IPSEC Home1 yes yes yes no
3 Select UTM. 4 Select Enable Antivirus and select standard_profile. 5 Select Enable IPS and select all_default. 6 Select Enable Web Filter and select standard_profile. 7 Select Enable Email Filter and select standard_profile. 8 Select OK 9 Select Create New and enter or select the following settings for Home_User_2:
Source Interface / Zone Source Address Destination Interface / Zone Destination Address Schedule Service Action VPN Tunnel Allow Inbound Allow outbound Inbound NAT Outbound NAT internal Example_Network wan1 All Always ANY IPSEC Home2_Tunnel yes yes yes no
116
10 Select UTM. 11 Select Enable Antivirus and select standard_profile. 12 Select Enable IPS and select all_default. 13 Select Enable Web Filter and select standard_profile. 14 Select Enable Email Filter and select standard_profile. 15 Select OK To configure firewall policies for the VPN tunnels - CLI config firewall policy edit 5 set srcintf internal 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 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 next edit 6 set srcintf internal 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 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
117
Configuring the web server
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_1s computer. 2 Go to VPN > Connections. 3 Select Add. 4 Enter the following information:
Connection Name VPN Type Remote Gateway Remote Network Home1_home (A descriptive name for the connection.) Manual IPSec 172.10.120.141 (The FortiGate external interface IP address.) 10.11.101.0 / 255.255.255.0 The Example Corporation internal network address and netmask.) ke8S5hOqpG73Lz4 (The preshared key entered in phase 1.)
Authentication method Preshared Key Preshared key
5 Select OK. 6 Repeat on Home_User_2s computer for Home_User_2.

Goals
Host the web server on a separate but secure DMZ network 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 Control traffic and maintain security. Tasks include:
Alternately, The Example Corporation could have their web server hosted by an ISP. See ISP web site and email hosting on page 126.
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.
118
To configure the FortiGate unit with a virtual IP - web-based manager 1 Go to Firewall > Virtual IP > Virtual IP. 2 Select Create New and enter or select the following settings:
Name External Interface Type External IP Address/ Range Mapped IP Address/ Range Web_Server_VIP wan1 Static NAT 172.20.120.141 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 set mappedip 10.20.10.3 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 1 Go to Firewall > Address > Address. 2 Select Create New and enter or select the following settings:
Address Name Type Subnet/ IP Range Interface Web_Server Subnet/ IP Range 10.20.10.3/255.255.255.0 Any
3 Select OK. To add the web server address - CLI config firewall address 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 1 Go to Firewall > Policy > Policy. 2 Select Create New and enter or select the following settings:
119
Source Interface / Zone Source Address Destination Interface / Zone Destination Address Schedule Service Action
wan1 All dmz1 Web_Server_VIP Always HTTP ACCEPT
3 Select UTM. 4 Select Enable Antivirus and select standard_profile. 5 Select Enable IPS and select all_default. 6 Select Enable Web Filter and select standard_profile. 7 Select Enable Email Filter and select standard_profile. 8 Select OK. To add a policy for web server access - CLI config firewall policy 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 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
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 1 Go to Firewall > Address > Address. 2 Select Create New and enter or select the following settings:
120
Address Name Type Subnet/ IP Range Interface
Web_Master_J Subnet/ IP Range 10.11.101.63/255.255.255.0 Any
3 Select OK. To add the web master address to the firewall - CLI config firewall address 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 > Policy. 2 Select Create New and enter or select the following settings:
Source Interface / Zone Source Address Destination Interface / Zone Destination Address Schedule Service Action internal Web_Master_J dmz1 Web_Server Always FTP ACCEPT
3 Select UTM. 4 Select Enable Antivirus and select standard_profile. 5 Select Enable IPS and select all_default. 6 Select Enable Web Filter and select standard_profile. 7 Select Enable Email Filter and select standard_profile. 8 Select OK. To add a policy for web master access to the web server - CLI config firewall policy edit 8 set action accept set dstaddr Web_Server set dstintf dmz1 set schedule always set service FTP set srcaddr Web_Master_J set srcintf internal 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
121
Configuring the email server
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 Control traffic and maintain security. Tasks include:
Alternately, The Example Corporation could have their email server hosted by an ISP. See ISP web site and email hosting on page 126.
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. 2 Select Create New and enter or select the following settings:
Name External Interface Type External IP Address/ Range Mapped IP address/ Range Email_Server_VIP wan1 Static NAT 172.20.120.141 10.20.10.2
3 Select OK. To configure a virtual IP - CLI config firewall vip edit Email_Server_VIP set extintf wan1 set extip 172.20.120.141 set mappedip 10.20.10.2 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 1 Go to Firewall > Address > Address. 2 Select Create New and enter or select the following settings:
122
Address Name Type Subnet/ IP Range Interface
Email_Server Subnet/ IP Range 10.10.10.3/255.255.255.0 Any
3 Select OK. To add the email server address to the firewall - CLI config firewall address 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 1 Go to Firewall > Policy > Policy. 2 Select Create New and enter or select the following settings:
Source Interface / Zone Source Address Destination Interface / Zone Destination Address Schedule Service Action dmz1 Email_Server wan1 All Always SMTP ACCEPT
3 Select UTM. 4 Select Enable Antivirus and select standard_profile. 5 Select Enable IPS and select all_default. 6 Select Enable Web Filter and select standard_profile. 7 Select Enable Email Filter and select standard_profile. 8 Select OK. To add a dmz1 -> wan1 firewall policy- CLI config firewall policy edit 9 set action accept set dstaddr all set dstintf wan1 set schedule always set service SMTP set srcaddr Email_Server
123
set set set set set set set end
srcintf dmz1 utm-status enable profile-protocol-options default av-profile standard_profile ips-sensor all_default webfilter-profile standard_profile spamfilter-profile standard_profile
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 1 Go to Firewall > Policy > Policy. 2 Select Create New and enter or select the following settings:
Source Interface / Zone Source Address Destination Interface / Zone Destination Address Schedule Service Action wan1 All dmz1 Email_Server_VIP Always SMTP ACCEPT
3 Select UTM. 4 Select Enable Antivirus and select standard_profile. 5 Select Enable IPS and select all_default. 6 Select Enable Web Filter and select standard_profile. 7 Select Enable Email Filter and select standard_profile. 8 Select OK. To add a wan1 -> dmz1 firewall policy - CLI config firewall policy 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 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
124
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 1 Go to Firewall > Policy > Policy. 2 Select Create New and enter or select the following settings:
Source Interface / Zone Source Address Destination Interface / Zone Destination Address Schedule Service Action internal All dmz1 Email_Server Always SMTP ACCEPT
3 Select UTM. 4 Select Enable Antivirus and select standard_profile. 5 Select Enable IPS and select all_default. 6 Select Enable Web Filter and select standard_profile. 7 Select Enable Email Filter and select standard_profile. 8 Select OK. 9 Select Create New and enter or select the following settings:
Source Interface / Zone Source Address Destination Interface / Zone Destination Address Schedule Service Action internal All dmz1 Email_Server Always POP3 ACCEPT
10 Select UTM and select the Protocol Options of default. 11 Select Enable Antivirus and select standard_profile. 12 Select Enable IPS and select all_default. 13 Select Enable Web Filter and select standard_profile. 14 Select Enable Email Filter and select standard_profile. 15 Select OK.
125
ISP web site and email hosting
To add internal -> dmz1 firewall policies - CLI

config firewall policy edit 11 set action accept set dstaddr Email_Server set dstintf dmz1 set schedule always set service SMTP set srcaddr all set srcintf internal
set set set set set set
utm-status enable profile-protocol-options default av-profile standard_profile ips-sensor all_default webfilter-profile standard_profile spamfilter-profile standard_profile
next edit 12 set action accept set dstaddr Email_Server set dstintf dmz1 set schedule always set service POP3 set srcaddr all set srcintf internal
set set set set set set

end
utm-status enable profile-protocol-options default av-profile standard_profile ips-sensor all_default webfilter-profile standard_profile spamfilter-profile standard_profile
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 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
126
The Example Corporation internal network configuration
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 22 on page 93) 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
127
Other features and products for SOHO
128

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 systems 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 librarys 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.
129
Figure 23: The library systems current network topology

Branch configuration (only one branch shown)
P ub lic te rm
h nc ra B f af st
Fir ew a
in al s
ll
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 librarys web page allowing public access from anywhere. Redundant hardware for main office firewall.
The librarys 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:
130
M se a rv i l er
W se e rv b er C a se ta rv log er s
C M P ai ub n fic of l ic te e rm st in f af al
at a te log rm a in cc al es s s
C at al og ac ce ss te rm in al s
Main office configuration

Fir ew al l DM
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 24 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 librarys 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 branchs 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.
131
Figure 24: Proposed library system network topology

CM Z DM4.1 . 0.1 1 19 WAN 2.1 1 68 .23 .8
V
Wi
Fi-
N2 WA.3.1 .1 10
C at a in rm te 4] ss 25 ce [2ac .3. og .1 al 10
P u 10 bli .1 c te .4 r .[2 m -2 ina 54 ls ]
Table 3 on page 132 details the allowed connectivity between different parts of the network.
Table 3: Access permission between various parts of the network
Connecting to:
Branch Catalog access Branch Public Access Main Public Access
W 10 se e .1 rv b 00 er .1 .1 0
Branch staff Branch Public Access No No No No No No No No No
No No No No No No No No No
Yes Yes Yes Yes Yes Yes No No
Yes Yes* Yes No No No No No No Yes* Yes Yes* Yes* Yes No No No No Yes No
Connecting from:
Branch Catalog access Main Staff Main Catalog Main Public Access Web Server Mail Server Catalog Server Internet
Yes Yes* Yes Yes* Yes
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.
132
Internet Access
Catalog Server
Main Catalog
Branch Staff
Web Server
Mail Server
Main Staff
M 10 se a .1 rv il 00 er .1 .1 1
10 se a .1 rv log 00 er .1 .1 2
rt2 Po .3.1 0 al .10 ern 1 10 Int 0.2. .10 10

f af st 4] e 25 fic 2of .[ n .2 ai 00 M .1 10
at
P 10 ub .1 lic 00 te .4 rm .[2 in -2 als 54 ]
f af ] st 4 h -25 nc [2 ra 2. B .1. 10
Int e 10 rnal .1. 2.1
80
9 Wi
Fi-
80
CM
P N n Tu ne
19 Exte 2.1 rm 68 al .14 7.3
00 T-8 er FG lust C HA
rt4 Po .5.1 0 .10 t3 10 r Po .4.1 00 0.1 1 D 10 MZ .10 0.1 .1
ls
al in rm te 4] ss -25 ce .[2 ac 0.3 og 0 al .1 at 10
Features used in this example

Table 4: Features used to fulfil requirements Feature requirement Location in this example Description Traffic between the each branch and the main office is encrypted.
Secure communication between each IPsec VPN on branch and the main office. page 138 WiFi 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.
Wireless access on The FortiWiFi-80CM provides WiFi page 148 access. Topology on page 135 FortiGuard on page 137 Traffic is permitted between network interfaces only when policies explicitly allow it. The FortiGuard Subscription service keeps antivirus and intrusion prevention signatures up to date. Also included is a spam blacklist and a web filtering service. Since staff user traffic and public access user traffic is controlled by separate policies, different protection profiles can be created for each. The FortiGuard Web Filtering service breaks down web sites in to 56 categories. Each can be allowed or blocked. IP pools can have traffic controlled by one policy originate from an IP address different than the physical network interface. Virtual IP addresses allow a single physical interface to share additional IP addresses and route traffic according to destination address. Each policy can be set to require authentication and/or agreement to a disclaimer before access is permitted. Two FortiGate-800 units operate together to ensure a minimum interruption should a hardware failure occur.
Instant messaging blocked for public access, and P2P blocked systemwide.
Protection profiles, Application Control on page 144
The ability to block specific sites and whole categories of sites from the public access terminals and public WiFi.
Protection profiles, FortiGuard Web Filtering/Advanced Filter on page 142
Public access traffic originates from a IP Pools on different address than staff and server page 139 traffic in case of abuse. Mail and web server have their own IP Mail and web addresses, but share the same servers on connection to the Internet as the rest page 151 of the main branch. Before theyre allowed access, public User Disclaimer on access users must agree that the page 140 library takes no responsibility for what they might see on the Internet. Redundant hardware to ensure availability. High Availability (HA) on page 135
Network addressing
The IP addresses used on the librarys 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
133
Configuring the main office
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 25: IP address ranges are assigned names, and the names combined into address groups.
IP Address Ranges
10.1.2.[2-254] 10.2.2.[2-254] 10.3.2.[2-254] 10.100.2.[2-254]
Address Names
Branch 1 Staff Branch 2 Staff
Address Group
Branch Staff Branch 3 Staff 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.

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.
134
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 librarys web server for example, but they cannot access any machines belonging to staff members. See Table 3 on page 132 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 26: Main branch network topology
80 CM
iFi
High Availability (HA)

The two FortiGate-800 units will be connected in a high-availability (HA) cluster in activeactive 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, theyd 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.
W 10 se e .1 rv b 00 er .1 .1 0
M 10 se a .1 rv il 00 er .1 .1 1
10 se a .1 rv log 00 er .1 .1 2
rt2 Po .3.1 0 al .10 ern 1 10 Int 0.2. .10 10
C f af st 4] e 25 fic 2of .[ n .2 ai 00 M .1 10
at
P 10 ub .1 lic 00 te .4 rm .[2 in -2 als 54 ]
V P N n Tu ne l
19 Exte 2.1 rm 68 al .14 7.3 00 T-8 er FG lust C HA rt4 Po .5.1 0 .10 t3 10 r Po .4.1 00 .1 10 DM 10 Z .10 0.1 .1
al in rm te 4] ss -25 ce .[2 ac 0.3 og 0 al .1 at 10
135
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 27. 3 Connect the heartbeat interface of the both FortiGate-800 units using a crossover cable, or normal cables connected to a switch.
Figure 27: HA Cluster Configuration with switches connecting redundant interfaces
INTERNAL EXTERNAL DMZ HA 1 2 3 4 CONSOLE USB
Esc
Enter
PWR
External 192.168.147.30
Heartbeat
DMZ 10.100.1.1 Internal 10.100.2.1

INTERNAL EXTERNAL DMZ HA 1 2 3 4 CONSOLE USB
Port3 10.100.4.1 Port2 10.100.3.1 Port4 10.100.5.1

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 27 on page 136 To configure the primary unit - CLI
config system ha
set set set set end
mode a-a group-name library password ##### hbdev ha
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.
136
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 set set set set end
mode a-a priority 64 group-name library password ##### hbdev ha
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.
137
IPsec VPN
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 theyre 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 isnt important in the librarys 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 librarys 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, its 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). 2 Select Create Phase 1. 3 Enter Branch 1 for the Name. 4 Select Static IP Address for Remote Gateway.
138
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 config vpn ipsec phase1 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). 2 Select Create Phase 2. 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 config vpn ipsec phase2 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 librarys 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 interfaces IP address. This is true even though the public access traffic will flow out of the external interface.
139
IPsec VPN
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 librarys 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 librarys 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.
140
IPsec VPN
The enabling this feature will be detailed in the policy configuration steps.
UTM 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 more information on creating UTM profiles, see the UTM Guide chapter of The Handbook. 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 UTM Guide chapter of The Handbook. In this example, if a setting is to be left in the default setting, it is not expanded in the tables below.
Table 5: UTM profiles, Name and Comments Profile Name Comment (optional) Staff Use with all policies for traffic from staff computers. Public Use with all policies for traffic from the public access or WiFi. Servers Use for policies allowing the public access to the library web server from the Internet, or email server communication. Web_Internal Use for policies allowing access to the library web server from catalog terminals.
The comment field is optional, but recommended. With many profiles, the comment can be invaluable in quickly identifying profiles.
141
IPsec VPN
Table 6: UTM profiles, Antivirus settings Profile Name Virus Scan Staff Enable for HTTP, FTP, IMAP, POP3, SMTP, IM and NNTP, Logging Disable Enable for HTTP, FTP, IMAP, POP3, SMTP, IM and NNTP Public Enable for HTTP, FTP, IMAP, POP3, SMTP, IM and NNTP, Logging Disable Enable for HTTP, FTP, IMAP, POP3, SMTP, IM and NNTP Servers Web_Internal
Enable for HTTP, Disable FTP, IMAP, POP3, SMTP, IM and NNTP, Logging Disable Disable Enable for HTTP, Disable FTP, IMAP, POP3, SMTP, IM and NNTP
File Filter Quarantine
Note: The FortiGate unit must have either an internal hard drive or a configured FortiAnalyzer unit for the Quarantine option to appear.
Table 7: UTM profiles, Protocol Options settings Profile Name Staff Public Servers Web_Internal
Pass Fragmented Enable for IMAP, POP3, and SMTP Emails Comfort Clients Interval Amount Oversized File/Email Threshold Enable for HTTP and FTP 10 1 Pass Default
Enable for IMAP, Enable for IMAP, Disable POP3, and POP3, and SMTP SMTP Enable for HTTP and FTP 10 1 Pass Default Disable Disable 10 1 Pass Default Disable Disable 10 1 Pass Default Disable
Append Signature Disable
Table 8: Protection profiles, FortiGuard Web Filtering/Advanced Filter Profile Name Enable FortiGuard Web Filtering Enable FortiGuard Web Filtering Overrides Provide details for blocked HTTP 4xx and 5xx errors Rate images by URL (blocked images will be replaced with blanks) Allow websites when a rating error occurs Staff Disable Disable Disable Public Enable HTTP* Disable Enable HTTP Servers Disable Disable Disable Web_Internal Disable Disable Disable
Disable
Enable HTTP
Disable
Disable
Disable
Disable
Disable
Disable
142
IPsec VPN
Table 8: Protection profiles, FortiGuard Web Filtering/Advanced Filter Profile Name Strict Blocking Staff Enable HTTP Public Enable HTTP Enable HTTP Servers Enable HTTP Disable Web_Internal Enable HTTP Disable
Rate URLs by domain and 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 9: Protection profiles, Email Filtering Profile Name IP address check URL check E-mail checksum check Spam submission IP address BWL check HELO DNS lookup E-mail address BWL check Return e-mail DNS check Banned word check Spam Action Tag Location Tag Format Staff Enable for IMAP, POP3 and SMTP Enable for IMAP, POP3 and SMTP Enable for IMAP, POP3 and SMTP Enable for IMAP, POP3 and SMTP Disable Disable Enable for IMAP, POP3 and SMTP Enable for IMAP, POP3 and SMTP Disable Tagged Subject [spam] Public Disable Disable Disable Disable Disable Disable Disable Disable Disable Disable Subject Servers Enable for IMAP, POP3 and SMTP Enable for IMAP, POP3 and SMTP Enable for IMAP, POP3 and SMTP Enable for IMAP, POP3 and SMTP Disable Disable Enable for IMAP, POP3 and SMTP Enable for IMAP, POP3 and SMTP Disable Tagged Subject [spam] Web_Internal Disable Disable Disable Disable Disable Disable Disable Disable Disable Disable Subject
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 10: Protection profiles, Intrusion Protection Profile Name Staff Select all_default Public Select all_default Servers Select all_default Web_Internal Disable
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 see the UTM Guide chapter of The Handbook.
143
IPsec VPN
Table 11: Protection profiles, Application Control Profile Block IM Block P2P Staff Disable for all IM protocols Block for all P2P protocols Public Enable for all IM protocols Block for all P2P protocols Servers Disable for all IM protocols Block for all P2P protocols Web_Internal Disable for all IM protocols Block for all 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 servers 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 servers 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 theyre 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. 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.
144
IPsec VPN
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 12.
Table 12: Library staff policies Main office staff connect to the Internet Source Interface/Zone Source Address Destination Interface/Zone Destination Address Schedule Service Action NAT Internal All External All Always All Accept Enable Main office staff connect to library servers Internal All DMZ Servers Always All Accept Enable Enable and select Staff Enable Disable Disable Disable Branch office staff connect to the Internet Branches Branch_Staff External All Always All Accept Enable Branch office staff connect to library servers Branches Branch_Staff DMZ Servers Always All Accept Enable
UTM Profiles Enable and select (all configured) Staff Log Allowed Traffic Enable
Enable and select Enable and Staff select Staff Enable Disable Disable Disable Enable Disable Disable Disable
Authentication Disable Traffic Shaping Disable User Disable Authentication Disclaimer Comment (optional) Main office: staff computers connecting to the Internet.
Main office: staff computers connecting to the library servers.
Branch offices: staff computers connecting to the Internet.
Branch offices: staff computers connecting to the library servers.
145
IPsec VPN
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 servers 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 13 on page 146. For complete policy construction steps, see the FortiGate Online Help.
Table 13: Catalog terminal policies Main office catalog terminals connect to web server Source Interface/Zone Source Address Destination Interface/Zone Destination Address Schedule Service Action NAT UTM Profiles Log Allowed Traffic Authentication Traffic Shaping User Authentication Disclaimer Comments (optional) port2 All DMZ Web_Server Always HTTP Accept Enable Disable Enable Disable Disable Disable Main office: catalog terminals connecting to the web server. Branch office catalog terminals connect to web server Branches Branch_Catalog DMZ Web_Server Always HTTP Accept Enable Disable Enable Disable Disable Disable Branch offices: catalog 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.
146
IPsec VPN
Creating firewall policies for public access terminals

Library users can access the Internet from the public terminals. The public terminal machines have the librarys web page as the web browsers default start page. The address is the web servers private network IP so the traffic between the terminal and the web server remains on the librarys network. The settings required for all public access terminal policies in this example are provided in Table 14 on page 147. For complete policy construction steps, see the FortiGate Online Help.
Table 14: Public access terminal policies Main office Public Main office access users public access connect to Internet users connect to web server Source Interface/Zone Source Address Destination Interface/Zone Destination Address Schedule Service Action NAT Port3 Main_Public External All Always All Accept Port3 Main_Public DMZ Web_Server Always HTTP Accept Branch offices public access users connect to Internet Branches Branch_Public External All Always All Accept Branch offices public access users connect to web server Branches Branch_Public DMZ Web_Server Always HTTP Accept
Enable NAT, enable Enable NAT. Dynamic IP Pool and select Public_Access_Add ress
Enable NAT, Enable NAT. enable Dynamic IP Pool and select Public_Access_A 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. Enable Disable Disable Enable Disable Disable Enable Disable Disable Enable User Authentication Disclaimer and leave Redirect URL field blank. Branch offices: public access terminals connecting to the Internet. Enable Disable Disable Disable
Log Allowed Traffic Authentication Traffic Shaping User Authentication Disclaimer Comments (optional)
Enable User Disable Authentication Disclaimer and leave Redirect URL field blank. Main office: public access terminals connecting to the Internet. Main office: public access terminals connecting to the library web server.
Branch offices: public access terminals connecting to the library web server.
147
IPsec VPN
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 offices 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 wifi 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 Fri-Sat Sun 10am - 9pm 10am - 6pm 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.
148
IPsec VPN
To create Monday to Thursday business hours schedule - CLI config firewall schedule recurring edit Mon-Thurs
set day monday tuesday wednesday thursday

end
To create Friday and Saturday business hours schedule - web-based manager 1 Go to Firewall > Schedule > Recurring and select Create New. 2 Enter Fri-Sat for the schedule name. 3 Select the check boxes for Friday, and Saturday. 4 Select 10 for the start hour and 00 for the start minute. 5 Select 18 for the end hour and 00 for the end minute. 6 Select OK. To create Friday and Saturday business hours schedule - CLI config firewall schedule recurring edit Fri-Sat
set day friday saturday

end
To create Sunday business hours schedule - web-based manager 1 Go to Firewall > Schedule > Recurring and select Create New. 2 Enter Sun for the schedule name. 3 Select the check box for Sunday. 4 Select 13 for the start hour and 00 for the start minute. 5 Select 17 for the end hour and 00 for the end minute. 6 Select OK. To create Monday to Thursday business hours schedule - CLI config firewall schedule recurring edit Sun
set sunday

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
149
IPsec VPN
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. 2 Select Create New. 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. For complete policy construction steps, see the FortiGate Online Help.
Table 15: Main office WiFi terminal policies Main office WiFi users connect to Internet Source Interface/Zone Source Address Destination Interface/Zone Destination Address Schedule Service Action NAT Port4 Main_WiFi External All Mon-Thurs All Accept Main office WiFi users connect to web library server Port4 Main_WiFi DMZ Web_Server Always HTTP Accept
Enable NAT, enable Dynamic IP Enable NAT. Pool and select Public_Access_Address Enable and select Public for each type. Enable Disable Disable Enable User Authentication Disclaimer and leave Redirect URL field blank. Main office: WiFi connecting to the Internet (Mon-Thurs). Enable and select Web_Internal for each type. Enable Disable Disable Disable
UTM Profile Log Allowed Traffic Authentication Traffic Shaping User Authentication Disclaimer Comments (optional)
Main office: WiFi connecting to the library web server.
150
IPsec VPN
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 16 on page 151.
Table 16: Branch office WiFi terminal policies Branch office WiFi users connect to Interne Source Interface/Zone Source Address Destination Interface/Zone Destination Address Schedule Service Action NAT Branches Branch_WiFi External All Mon-Thurs All Accept Enable NAT, enable Dynamic IP Pool and select Public_Access_Address Branch office WiFi users connect to web library server Branches Branch_WiFi DMZ Web_Server Always HTTP Accept Enable NAT.
UTM Profile Log Allowed Traffic Authentication Traffic Shaping User Authentication Disclaimer Comments (optional)
Enable and select Public for each Enable and select Web_Internal type. for each type. Enable Disable Disable Enable User Authentication Disclaimer and leave Redirect URL field blank. Enable Disable Disable Disable
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 servers 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 servers 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 librarys 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 librarys network. The 172.20.16.192 address can be registered with the librarys domain name so anyone on the Internet entering the URL will bring up the librarys page.
151
IPsec VPN
To create a virtual IP for the web server - web-based manager 1 Go to Firewall > Virtual IP > Virtual IP and select Create New. 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 mappedip 10.100.1.10 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 1 Go to Firewall > Virtual IP > Virtual IP and select Create New. 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 mappedip 10.100.1.11 set portforward diable end
152
IPsec VPN
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 17 on page 153. For complete policy construction steps, see the FortiGate Online Help.
Table 17: Server policies Inbound to web and email servers Source Interface/Zone Source Address Destination Interface/Zone Destination Address Schedule Service Action NAT UTM Profiles External All DMZ Servers Always Servers Accept Enable Enable and select Servers for each type. Outbound from email server DMZ Servers External All Always SMTP Accept Enable Enable and select Servers for each type.
153
IPsec VPN
Table 17: Server policies (Continued) Inbound to web and email servers Log Allowed Traffic Authentication Traffic Shaping User Authentication Disclaimer Comments (optional) Enable Disable Disable Disable Outbound from email server Enable Disable Disable Disable
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 26 on page 135. To Configure the operation mode - web-based manager 1 Go to System > Dashboard > Status. 2 In the System Status widget, select the [Change] link for the Operation Mode, and set the unit to Transparent Mode. Since the FortiWiFi-80CM is within the librarys network, no address translation is required. 3 Enter 10.100.1.99/255.255.255.0 as the Management IP/Netmask and 10.100.1.3 as the Default Gateway. 4 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 set gateway 10.100.1.3 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 Table 18 on page 155. For complete policy construction steps, see the FortiGate Online Help.
154
Configuring branch offices
Table 18: Main office FortiWiFi-80CM policies WiFi Source Interface/Zone Source Address Destination Interface/Zone Destination Address Schedule Service Action UTM Profiles Log Allowed Traffic Authentication Traffic Shaping User Authentication Disclaimer Comments (optional) wifi All Wan1 All Always All Accept Disable Disable Disable Disable Disable 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.

The three sections of each branchs 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 FortiWiFi80CM. 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 3 on page 132 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.
155
Figure 28: Branch office network topology

M Z DM4.1 .1. 10 19 WAN 2.1 1 68 .23 .8
N2 WA.3.1 .1 10
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 librarys 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 librarys 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.
156
u 10 bli .1 c te .4 r .[2 m -2 ina 54 ls ]
f af ] st 4 h -25 nc [2 ra 2. B .1. 10 C at a in rm te 4] ss 25 ce [2ac .3. og .1 al 10
C Int 80 ern Fi10 al Wi .1. 2.1
V P N n Tu ne
ls
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 config vpn ipsec phase1 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 1 Select Create Phase 2. 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 config vpn ipsec phase2 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 FortiGate800 cluster at the main office direct the traffic once it arrives there.
157
Traffic shaping
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, wifi, 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 19 on page 158. For complete policy construction steps, see the FortiGate Online Help.
Table 19: Branch office FortiWiFi-80CM policies Branch policy Source Interface/Zone Source Address Destination Interface/Zone Destination Address Schedule Service Action UTM Profiles Log Allowed Traffic Authentication Traffic Shaping User Authentication Disclaimer Comments (optional) Inside_Zone All Main_Office All Always All Accept Disable Disable Disable Disable Disable 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.
158
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 systems network, there are four types of users accessing two services.
Table 20: Priority of traffic based on source and destination To servers From catalog terminals* From Internet From public terminals/WiFi* From staff* high high high high low medium To Internet
* includes both branch and main office traffic includes both inbound and outbound mail server connections
On the library systems network, the most important traffic is to and from the web and mail servers. Locating research materials in the librarys 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, its 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 doesnt 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.
159
The future
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.
160
Index
A
accept, 70 accept policy, 72 address, 44 CIDR format, 44 DHCP, 54 FDQN, 47 geography-based, 46 groups, 53 inverse mask, 47 IP pool, 57 IP range, 45 IPv6, 59 matching, IP pool, 59 administrative access, 39 aidentity-based policy timeout, 66 allow access, 39 antispam, about, 16 antivirus, about, 13 authentication policies, 66
E
email filter techniques, 17 email filter, about, 16 example blocking IP address, 74 scheduled access, 75
F
FDQN, 47 firewall policies accept, 70 basic accept, 72 basic deny, 72 basic VPN, 73 checking, 81 column settings, 81 deny, 70 IPsec, 70 log messages, 82 policy order, 70 schedule example, 75 ssl-vpn policies, 70 verify traffic, 81 fixed ports, IP pools, 58 flow inspection, 26, 27 flow trace, 85
B
binary, 47 blended network attacks, about, 16
C
central NAT, 22 custom services, 63
G
geography-based addressing, 46 grayware, about, 15 groups, addressing, 53
D
data leak prevention, 15 deny, 70 deny policy, 72, 82 destination network address translation (DNAT) virtual IPs, 49, 52 DHCP, 54 IP reservation, 56 diagnose flow trace, 85 session list, 83 sniffer packet, 88 sys checkused, 85 DLP, 15 DNAT virtual IPs, 49, 52 DNS TTL, 47
I
ICAP, 27 identity-based policy timeout schedule, 66 inspection flow, 26, 27 proxy, 27 security layers, 27 stateful, 25 instant messaging, about, 16 interfaces AMC card, 38 ANY, ANY interface option, 72 physical, 37 virtual domains, 40 virtual LANs, 42 wireless, 40 zones, 43 intrusion protection, about, 18
161
Index
inverse mask, 47 IP addresses blocking, 74 IP pool, 57 address matching, 59 policies and fixed ports, 58 IP range, 45 IP reservation, 56 IPsec, 70 IPv6, 59
R
reserving addresses, 56
S
schedule automatic updates, 98 timeout, 66 schedules example, 75 expiry, 66 group, 66 identity-based policy timeout, 66 one time, 64 recurring, 64 schedule-timeout command, 66 security layers, 27 sensors, UTM, 67 services, 63 custom, 63 list, 63 session helper, 31 session list, diagnose, 83 session table, 83 SNAT virtual IPs, 49 sniffer packet, 83 spyware, about, 15 ssl-vpn, 70 stateful inspection, 25 streaming media, about, 16
L
life of a packet, 25 log messages, 82
N
NAT, 22 symmetric, 52 NAT mode about, 20 network address translation (NAT), 49
P
P2P, about, 16 packet flow, 28 life of, 25 sniffer, 88 PAT virtual IPs, 49 peer-to-peer, about, 16 pharming, about, 16 phishing, about, 15 policies, 70 basic accept, 72 basic deny, 72 basic VPN, 73 checking, 81 expiry, 66 identity-based policy timeout, 66 log messages, 82 order, 70 timeout, 66 verify traffic, 81 port address translation virtual IPs, 49 port forwarding, 49 ports closing to traffic, 62 default system, 61 originating traffic, 61 receiving traffic, 62 services, 63 TCP 113, 62 TCP 541, 63 profiles, UTM, 67 proxy inspection, 27
T
traffic count, 81 traffic shaping about, 19 traffic trace, 83 transparent mode about, 22 feature differences, 24 switching to, 23 troubleshooting flow trace, 85 log messages, 82 packet sniffer, 88 policies, 81 session table, 83 verify traffic, 81
U
UTM profiles, 67 profiles and sensors, 67
V
verify traffic, 81 violation traffic, 82 virtual domains, 40
162
Index
virtual IP destination network address translation (DNAT), 49, 52 NAT, 49 PAT, 49 port address translation, 49 SNAT, 49 source network address translation, 49 virtual LANs, 42 VPN policy, 73
W
web filtering, about, 14 wildcard mask, 47 wireless, 40
Z
zones, 43
163
Index
164
Index
165
Index
166

Fortigate Fundamentals 40 Mr3

Uploaded by

Document Information

Original Description:

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 Mr3

Uploaded by

Copyright:

Available Formats

FortiGate Fundamentals

FortiOS Handbook v3 for FortiOS 4.0 MR3

The Purpose of a Firewall

FortiOS Handbook v3: FortiGate Fundamentals 01-430-112804-20110228 http://docs.fortinet.com/ Feedback

FortiGate Fundamentals for FortiOS 4.0 MR3 01-430-112804-20110228 http://docs.fortinet.com/ Feedback

UTM profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Profiles and sensors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

FortiOS Handbook v3: FortiGate Fundamentals 01-430-112804-20110228 http://docs.fortinet.com/ Feedback

Concept Example: Small Office Network Protection

FortiGate Fundamentals for FortiOS 4.0 MR3 01-430-112804-20110228 http://docs.fortinet.com/ Feedback

Concept Example: Library Network Protection

FortiGate Fundamentals for FortiOS 4.0 MR3 01-430-112804-20110228 http://docs.fortinet.com/ Feedback

FortiOS Handbook v3: FortiGate Fundamentals 01-430-112804-20110228 http://docs.fortinet.com/ Feedback

FortiGate Fundamentals for FortiOS 4.0 MR3 01-430-112804-20110228 http://docs.fortinet.com/ Feedback

How this guide is organized

v3 FortiGate Fundamentals 01-430-112804-20110228 http://docs.fortinet.com/ Feedback

v3 FortiGate Fundamentals 01-430-112804-20110228 http://docs.fortinet.com/ Feedback

The Purpose of a Firewall

v3 FortiGate Fundamentals 01-430-112804-20110228 http://docs.fortinet.com/ Feedback

The Purpose of a Firewall

v3 FortiGate Fundamentals 01-430-112804-20110228 http://docs.fortinet.com/ Feedback

The Purpose of a Firewall

Data leak prevention

v3 FortiGate Fundamentals 01-430-112804-20110228 http://docs.fortinet.com/ Feedback

The Purpose of a Firewall

Blended network attacks

v3 FortiGate Fundamentals 01-430-112804-20110228 http://docs.fortinet.com/ Feedback

The Purpose of a Firewall

Email filter techniques

v3 FortiGate Fundamentals 01-430-112804-20110228 http://docs.fortinet.com/ Feedback

The Purpose of a Firewall

v3 FortiGate Fundamentals 01-430-112804-20110228 http://docs.fortinet.com/ Feedback

The Purpose of a Firewall

v3 FortiGate Fundamentals 01-430-112804-20110228 http://docs.fortinet.com/ Feedback

NAT vs. Transparent Mode

The Purpose of a Firewall

NAT vs. Transparent Mode

P 192 ort 1 .16 8.1 .1

k or etw24 N / al .0 rn 8.1 e Int 2.16 9 1

v3 FortiGate Fundamentals 01-430-112804-20110228 http://docs.fortinet.com/ Feedback

The Purpose of a Firewall

NAT vs. Transparent Mode

How address translation works

Fir ew N A all P T e olic nab y 1 led 2

er erv 0 b S 20.2 We 50. 2. 17

v3 FortiGate Fundamentals 01-430-112804-20110228 http://docs.fortinet.com/ Feedback

NAT vs. Transparent Mode

The Purpose of a Firewall

Fir ew N A all P T e olic nab y 1 led 2

Central NAT table

.1 20 .1 20 20 0. 2. .2 17 .50 n: 2 io 17 at : tin rce es u D So

r rve Se .20 b 0 We 50.2 . 72 1

v3 FortiGate Fundamentals 01-430-112804-20110228 http://docs.fortinet.com/ Feedback

The Purpose of a Firewall

NAT vs. Transparent Mode

g llin nd ro l a nt na co r . s te ks ie in or lic en tw po twe l ne AT e a N ic b tern ff x tra e

NAT vs. Transparent Mode

The Purpose of a Firewall

Operating mode differences

v3 FortiGate Fundamentals 01-430-112804-20110228 http://docs.fortinet.com/ Feedback

v3 FortiGate Fundamentals 01-430-112804-20110228 http://docs.fortinet.com/ Feedback

Figure 5: Stateful inspection of packets through the FortiGate unit

IPS , Ap Flow p C -AV ont , rol 2

v3 FortiGate Fundamentals 01-430-112804-20110228 http://docs.fortinet.com/ Feedback