FortiGate Fundamentals - Fortinet Document Library

Transcription

FortiGate Fundamentals
FortiOS™ Handbook v2
for FortiOS 4.0 MR2
FortiOS™ Handbook: FortiGate Fundamentals
v2
13 October 2010
01-40002-112804-20101008
for FortiOS 4.0 MR2
© Copyright 2010 Fortinet, Inc. All rights reserved. No part of this publication including text, examples,
diagrams or illustrations may be reproduced, transmitted, or translated in any form or by any means,
electronic, mechanical, manual, optical or otherwise, for any purpose, without prior written permission of
Fortinet, Inc.
Trademarks
Dynamic Threat Prevention System (DTPS), APSecure, FortiASIC, FortiBIOS, FortiBridge, FortiClient,
FortiGate®, FortiGate Unified Threat Management System, FortiGuard®, FortiGuard-Antispam,
FortiGuard-Antivirus, FortiGuard-Intrusion, FortiGuard-Web, FortiLog, FortiAnalyzer, FortiManager,
Fortinet®, FortiOS, FortiPartner, FortiProtect, FortiReporter, FortiResponse, FortiShield, FortiVoIP, and
FortiWiFi are trademarks of Fortinet, Inc. in the United States and/or other countries. The names of actual
companies and products mentioned herein may be the trademarks of their respective owners.
Contents
Introduction
11
Before you begin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
How this guide is organized . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12
Document conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
IP addresses . . . . . . . . . . .
Example Network configuration .
Cautions, Notes and Tips . . . .
Typographical conventions . . . .
CLI command syntax conventions
.
.
.
.
.
13
14
16
16
16
Entering FortiOS configuration data . . . . . . . . . . . . . . . . . . . . . . . . . .
18
Entering text strings (names).
Entering numeric values . . .
Selecting options from a list .
Enabling or disabling options.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
18
19
19
19
Registering your Fortinet product. . . . . . . . . . . . . . . . . . . . . . . . . . . .
19
Fortinet products End User License Agreement . . . . . . . . . . . . . . . . . . . .
20
Training . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
20
Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
20
Fortinet Tools and Documentation CD . . . . . . . . . . . . . . . . . . . . . . .
Fortinet Knowledge Base. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Comments on Fortinet technical documentation . . . . . . . . . . . . . . . . .
20
20
20
Customer service and technical support . . . . . . . . . . . . . . . . . . . . . . . .
20
The Purpose of a Firewall
23
Firewall features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Antivirus . . . . . . . . . . .
Web Filtering . . . . . . . . .
Spyware/Grayware. . . .
Phishing . . . . . . . . .
Pharming . . . . . . . . .
Instant messaging . . . .
Peer-to-peer . . . . . . .
Streaming media . . . . .
Blended network attacks .
Antispam/Email Filter. . . . .
Email filter techniques . .
Intrusion Protection. . . . . .
Traffic Shaping . . . . . . . .
FortiOS™ Handbook v2: FortiGate Fundamentals
01-40002-112804-20101015
http://docs.fortinet.com/ • Feedback
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
23
23
24
25
25
25
25
25
25
26
26
26
27
28
3
Contents
NAT vs. Transparent Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
NAT mode . . . . . . . . . . . . .
How address translation works
Central NAT table . . . . . . .
Transparent mode . . . . . . . . .
Operating mode differences . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
29
30
32
32
34
Life of a Packet
35
Stateful inspection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
35
Flow inspection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
36
Proxy inspection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
37
FortiOS functions and security layers . . . . . . . . . . . . . . . . . . . . . . . . .
37
Packet flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
38
Packet inspection (Ingress) . .
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 . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
38
39
39
39
40
40
40
40
40
41
41
41
41
41
41
42
42
42
42
Transparent mode routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
42
Example 1: client/server connection . . . . . . . . . . . . . . . . . . . . . . . . . .
42
Example 2: Routing table update . . . . . . . . . . . . . . . . . . . . . . . . . . . .
44
Example 3: Dialup IPsec with application control. . . . . . . . . . . . . . . . . . . .
45
Firewall components
49
Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Physical . . . . . . .
Administrative access
Example . . . . .
Wireless . . . . . . .
Aggregate . . . . . .
4
29
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
49
49
51
51
52
52
FortiGate Fundamentals for FortiOS 4.0 MR2
01-40002-112804-20101015
Contents
Example . .
Virtual domains .
Example . .
Virtual LANs . .
Example . .
Zones. . . . . .
Example . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
53
53
54
55
55
56
56
Addressing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
57
Example . . . . . . . . . . . . . . . . . . . . . . . . . . .
Example . . . . . . . . . . . . . . . . . . . . . . . . . . .
Wildcard firewall addresses . . . . . . . . . . . . . . . . . . .
Adding a firewall wildcard address . . . . . . . . . . . . . .
Fully Qualified Domain Name addresses . . . . . . . . . . . .
Virtual IPs . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Example . . . . . . . . . . . . . . . . . . . . . . . . . . .
Inbound connections . . . . . . . . . . . . . . . . . . . . .
Outbound connections . . . . . . . . . . . . . . . . . . . .
Virtual IP, load balance virtual server / real server limitations
Address groups. . . . . . . . . . . . . . . . . . . . . . . . . .
Example . . . . . . . . . . . . . . . . . . . . . . . . . . .
DHCP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Example . . . . . . . . . . . . . . . . . . . . . . . . . . .
Example . . . . . . . . . . . . . . . . . . . . . . . . . . .
IP pools. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Example . . . . . . . . . . . . . . . . . . . . . . . . . . .
IP Pools for firewall policies that use fixed ports . . . . . . . . .
Source IP address and IP pool address matching . . . . . . . .
IPv6. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Example . . . . . . . . . . . . . . . . . . . . . . . . . . .
Example . . . . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
73
73
73
74
74
74
76
77
77
79
Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
79
Originating traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Receiving traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Closing specific ports to traffic . . . . . . . . . . . . . . . . . . . . . . . . . . .
79
80
81
01-40002-112804-20101015
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
73
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
58
58
59
61
61
61
62
62
66
66
66
67
67
68
68
69
70
70
70
71
72
72
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
The routing table . . . . . . . . . . . . . . . . .
How routing decisions are made . . . . . . . .
Multipath routing and determining the best route
Route priority . . . . . . . . . . . . . . . . . .
Static route . . . . . . . . . . . . . . . . . . . .
Default route and default gateway . . . . . . . .
Changing the gateway for the default route .
Adding a static route . . . . . . . . . . . . .
Policy Route . . . . . . . . . . . . . . . . . . .
Type of Service . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5
Contents
Port 113 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Port 541 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
81
81
Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
82
Custom service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
82
82
Schedules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
83
Example . .
Example . .
Schedule groups
Example . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
83
84
84
84
UTM profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
85
Profiles and sensors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
85
86
86
Firewall Policies
89
Policy order . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
90
Denial of Service policies.
Rearranging policies . . .
Firewall policy 0 . . . . .
Firewall policy list details .
.
.
.
.
.
.
.
.
.
.
.
.
91
91
92
92
Creating basic policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
93
Using an interface of “any” . .
Basic accept policy example .
Basic deny policy example . .
Basic VPN policy example . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
93
94
94
95
DoS Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
96
Basic DoS policy example . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
96
Sniffer Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
97
Basic one-armed sniffer policy example . . . . . . . . . . . . . . . . . . . . . .
97
Identity-based Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
98
Identity-based policy example . . . . . . . . . . . . . . . . . . . . . . . . . 99
Identity-based policy positioning . . . . . . . . . . . . . . . . . . . . . . . . . . 100
Identity-based sub-policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
ICMP packet processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
Firewall policy examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
Blocking an IP address . . . . . . .
Add an Address . . . . . . . .
Add a Firewall Policy . . . . . .
Scheduled access policies . . . . .
Configuring the schedules . . .
Configuring the IP addresses .
Configuring the firewall policies
6
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
102
102
102
103
103
104
105
01-40002-112804-20101015
Contents
Troubleshooting
109
Basic policy checking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
Default gateway . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
Verifying traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
Using log messages to view violation traffic . . . . . . . . . . . . . . . . . . . . . . 110
Traffic trace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
Session table . . . . . . . . . . . .
Sample output . . . . . . . . .
Finding object dependencies . . . .
Sample output . . . . . . . . .
Flow trace . . . . . . . . . . . . .
Sample output . . . . . . . . .
Flow trace output example - HTTP .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
111
112
113
113
113
114
114
Packet sniffer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
Simple trace example . . .
Simple trace example . . .
Verbose levels 2 and 3.
Trace with filters example .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Configuration Examples
116
117
117
117
119
Exempted URLs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
Create a local category. . . . . . .
Add URLs to the category . . . . .
Enable the category in web filtering
Test it . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Concept Example: Small Office Network Protection
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
119
119
120
120
121
Example small office network. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
Network management and protection requirements . . . . . . . . . . . . . . . . 122
Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
Features used in this example . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
First steps. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
Configuring FortiGate network interfaces . . . . . . . . . . . . . . . . . . . . . 124
Adding the default route . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
. . . . . . . . . . . . . . . . . . . . . . . . Removing the default firewall policy 126
Configuring DNS forwarding . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
Setting the time and date. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
Registering the FortiGate unit . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
Scheduling automatic antivirus and attack definition updates . . . . . . . . . . . 128
Configuring administrative access and passwords. . . . . . . . . . . . . . . . . 128
01-40002-112804-20101015
7
Contents
Configuring settings for Finance and Engineering departments . . . . . . . . . . . . 130
Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
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 . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
130
130
131
131
132
132
132
133
134
134
134
Configuring settings for the Help Desk department . . . . . . . . . . . . . . . . . . 135
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 .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
136
136
136
138
139
139
140
140
Configuring remote access VPN tunnels . . . . . . . . . . . . . . . . . . . . . . . . 142
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 .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
142
142
143
145
147
Configuring the web server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
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 . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
147
148
148
149
149
150
150
150
Configuring the email server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
Configuring the FortiGate unit with a virtual IP . . . . . . . . . . . . . . . . . . . 151
Adding the email server address . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
Configuring firewall policies for the email server .
dmz1 -> wan1 policies. . . . . . . . . . . .
wan1 -> dmz1 policies. . . . . . . . . . . .
dmz1 -> internal policies . . . . . . . . . .
8
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
152
152
153
154
01-40002-112804-20101015
Contents
internal -> dmz1 policies . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
ISP web site and email hosting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
The Example Corporation internal network configuration . . . . . . . . . . . . . . . 156
Other features and products for SOHO. . . . . . . . . . . . . . . . . . . . . . . . . 156
Concept Example: Library Network Protection
159
Current topology and security concerns . . . . . . . . . . . . . . . . . . . . . . . . 159
Library requirements . . . . .
The library’s decision . . . . .
Proposed topology . . . . . .
Features used in this example
Network addressing . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
160
160
161
163
163
Configuring the main office . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
High Availability (HA) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
Configuring HA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
FortiGuard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
IPsec VPN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
Configuring IPsec VPNs . . . . . . . . . . . . . . . . . . . .
IP Pools . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configuring IP pools . . . . . . . . . . . . . . . . . . . .
User Disclaimer . . . . . . . . . . . . . . . . . . . . . . . .
Configuring the user disclaimer . . . . . . . . . . . . . .
Protection 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 . . . . . . . . . .
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. . . . . . . .
01-40002-112804-20101015
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
168
169
170
170
170
171
174
174
176
176
176
177
178
178
178
180
181
181
182
183
183
184
184
9
Contents
Configuring branch offices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
Topology . . . . . . . . . . . . . . . . . . . . .
Staff access . . . . . . . . . . . . . . . . . . .
Catalog terminals. . . . . . . . . . . . . . . . .
Wireless/public access . . . . . . . . . . . . . .
Mail and web servers. . . . . . . . . . . . . . .
IPsec VPN . . . . . . . . . . . . . . . . . . . .
Branch Firewall Policy . . . . . . . . . . . . . .
Creating firewall policy for the branch office .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
185
186
186
186
186
187
187
188
Traffic shaping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
Priorities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
The future. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
Logging . . . . . . .
Decentralization . .
Staff WiFi . . . . . .
Further redundancy
Index
10
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
189
190
190
190
193
01-40002-112804-20101015
Introduction
Welcome and thank you for selecting Fortinet products for your network protection.
The firewall policies are the key component of FortiOS that allows, or disallows, traffic to
and from your network. It is through the firewall policies you define who, what and when
traffic goes between networks and the Internet.
This guide describes the firewall functionality of FortiOS on all FortiGate units. It includes
the purpose of the firewall, how traffic moves through the FortiGate unit, the components
involved in the firewall and its policies.
This guide also describes both simple how to steps to configure the basic components,
and some more involved examples to demonstrate how firewall policies can be employed
within FortiOS. Finally, this guide also provides some troubleshooting advice should
problems arise when creating firewall policies.
Because of the magnitude of features, this guide will only touch the surface of traffic
shaping, Universal Threat Management (UTM) and profile information. Other guides are
available with more in depth content. For basic configuration to install the FortiGate unit on
the network, see the System Administration Guide.
This chapter contains the following topics:
•
Before you begin
•
Document conventions
•
Registering your Fortinet product
•
Fortinet products End User License Agreement
•
Training
•
Documentation
•
Customer service and technical support
Before you begin
Before you begin ensure that:
•
You have administrative access to the web-based manager and/or CLI.
•
The FortiGate unit is integrated into your network.
•
The operation mode has been configured.
•
The system time, DNS settings, administrator password, and network interfaces have
been configured. For more information, see the Basic Setup chapter of the System
Administration Guide.
•
Firmware, FortiGuard Antivirus and FortiGuard Antispam updates are completed.
01-40002-112804-20101015
11
Before you begin
Introduction
How this guide is organized
This document describes firewall components, and how to implement firewall policies on
FortiGate units operating in both NAT/Route, and Transparent mode.
This guide contains the following chapters:
12
•
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.
01-40002-112804-20101015
Fortinet technical documentation uses the conventions described below.
IP addresses
To avoid publication of public IP addresses that belong to Fortinet or any other
organization, the IP addresses used in Fortinet technical documentation are fictional and
follow the documentation guidelines specific to Fortinet. The addresses used are from the
private IP address ranges defined in RFC 1918: Address Allocation for Private Internets,
available at http://ietf.org/rfc/rfc1918.txt?number-1918.
Most of the examples in this document use the following IP addressing:
•
IP addresses are made up of A.B.C.D
•
A - can be one of 192, 172, or 10 - the non-public addresses covered in RFC 1918.
•
B - 168, or the branch / device / virtual device number.
•
•
•
Branch number can be 0xx, 1xx, 2xx - 0 is Head office, 1 is remote, 2 is other.
•
Device or virtual device - allows multiple FortiGate units in this address space
(VDOMs).
•
Devices can be from x01 to x99.
C - interface - FortiGate units can have up to 40 interfaces, potentially more than one
on the same subnet
•
001 - 099- physical address ports, and non -virtual interfaces
•
100-255 - VLANs, tunnels, aggregate links, redundant links, vdom-links, etc.
D - usage based addresses, this part is determined by what device is doing
•
The following gives 16 reserved, 140 users, and 100 servers in the subnet.
•
001 - 009 - reserved for networking hardware, like routers, gateways, etc.
•
010 - 099 - DHCP range - users
•
100 - 109 - FortiGate devices - typically only use 100
•
110 - 199 - servers in general (see later for details)
•
200 - 249 - static range - users
•
250 - 255 - reserved (255 is broadcast, 000 not used)
•
The D segment servers can be farther broken down into:
•
110 - 119 - Email servers
•
120 - 129 - Web servers
•
130 - 139 - Syslog servers
•
140 - 149 - Authentication (RADIUS, LDAP, TACACS+, FSAE, etc)
•
150 - 159 - VoIP / SIP servers / managers
•
160 - 169 - FortiAnalyzers
•
170 - 179 - FortiManagers
•
180 - 189 - Other Fortinet products (FortiScan, FortiDB, etc.)
•
190 - 199 - Other non-Fortinet servers (NAS, SQL, DNS, DDNS, etc.)
•
Fortinet products, non-FortiGate, are found from 160 - 189.
FortiOS™ Handbook v2: Traffic Shaping
01-402-120097-201001008
9
The following table shows some examples of how to choose an IP number for a device
based on the information given. For internal and dmz, it is assumed in this case there is
only one interface being used.
Table 1: Examples of the IP numbering
Location and device
Internal
Dmz
External
Head Office, one FortiGate
10.011.101.100
10.011.201.100
172.20.120.191
Head Office, second FortiGate
10.012.101.100
10.012.201.100
172.20.120.192
Branch Office, one FortiGate
10.021.101.100
10.021.201.100
172.20.120.193
Office 7, one FortiGate with 9
VDOMs
10.079.101.100
10.079.101.100
172.20.120.194
Office 3, one FortiGate, web
server
n/a
10.031.201.110
n/a
Bob in accounting on the
corporate user network (dhcp)
at Head Office, one FortiGate
10.0.11.101.200
n/a
n/a
Router outside the FortiGate
n/a
n/a
172.20.120.195
Example Network configuration
The network configuration shown in Figure 1 or variations on it is used for many of the
examples in this document. In this example, the 172.20.120.0 network is equivalent to the
Internet. The network consists of a head office and two branch offices.
10
Traffic Shaping for FortiOS 4.0 MR2
01-402-120097-201001008
Figure 1: Example network configuration
WLAN: 10.12.101.100
SSID: example.com
Password: supermarine
DHCP range: 10.12.101.200-249
Linux PC
10.11.101.20
T 1.1
IN .1
10
01
.1
FortiWiFi-80CM
01
Windows PC
10.11.101.10
Internal network
10
10
1.
t2
or 2
P 10
1.
.1
od
rm
ff e 4 1
ni .1
(s 20
t 1 .1
or 0
P 2.2
17
10
1
t 2 10
or .
P .11
10
1.
.1
Switch
FortiGate-82C
30
e)
t2
or 0
P .10
1
10
.1
FortiAnalyzer-100B
10
1
P
o
(m rt
irr 8
or
of
14
po
0.
rts
2
an
d
17
3)
2
t 1 .1
or 0
P 2.2
t1
or 0
P .11
1
10
1.
.1
t2
or 3
P nd
a
FortiGate-620B
HA cluster
P
or
t1
FortiMail-100C
Switch
H
ea
d
of
fic
e
t 1 10
or .
P .21
10
1.
10
FortiGate-3810A
1
17
Linux PC
10.21.101.10
2.
.1
20
e
al 1.
rn 0
te .1
In .31
10
fic
e
of
fic
h
of
nc
h
ra
nc
B
ra
1
N
A 2
W .12
20
B
10
FortiGate-51B
P
10 ort
.2 1
1.
10
1
.1
60
0
Windows PC
10.31.101.10
10
.2
2.
10 Po
1. rt
10 4
0
FortiManager-3000B
Cluster
Port 1: 10.21.101.102
FortiGate-5005FA2
Port 1: 10.21.101.102
FortiGate-5005FA2
Port 1: 10.21.101.103
FortiSwitch-5003A
Port 1: 10.21.101.161
FortiGate-5050-SM
Port 1: 10.21.101.104
Engineering network
10.22.101.0
01-402-120097-201001008
11
Cautions, Notes and Tips
Fortinet technical documentation uses the following guidance and styles for cautions,
notes and tips.
Caution: Warns you about commands or procedures that could have unexpected or
undesirable results including loss of data or damage to equipment.
Note: Presents useful information, but usually focused on an alternative, optional method,
such as a shortcut, to perform a step.
Tip: Highlights useful additional information, often tailored to your workplace activity.
Typographical conventions
Fortinet documentation uses the following typographical conventions:
Table 2: Typographical conventions in Fortinet technical documentation
Convention
Example
Button, menu, text box, From Minimum log level, select Notification.
field, or check box label
CLI input
config system dns
set primary <address_ipv4>
end
CLI output
FGT-602803030703 # get system settings
comments
: (null)
opmode
: nat
Emphasis
HTTP connections are not secure and can be intercepted by a third
party.
File content
<HTML><HEAD><TITLE>Firewall
Authentication</TITLE></HEAD>
<BODY><H4>You must authenticate to use this
service.</H4>
Hyperlink
Visit the Fortinet Technical Support web site,
https://support.fortinet.com.
Keyboard entry
Type a name for the remote VPN peer or client, such as
Central_Office_1.
Navigation
Go to VPN > IPSEC > Auto Key (IKE).
Publication
For details, see the FortiOS Handbook.
CLI command syntax conventions
This guide uses the following conventions to describe the syntax to use when entering
commands in the Command Line Interface (CLI).
Brackets, braces, and pipes are used to denote valid permutations of the syntax.
Constraint notations, such as <address_ipv4>, indicate which data types or string
patterns are acceptable value input.
12
01-402-120097-201001008
Table 3: Command syntax notation
Convention
Description
Square brackets [ ]
A non-required word or series of words. For example:
[verbose {1 | 2 | 3}]
indicates that you may either omit or type both the verbose word and
its accompanying option, such as:
verbose 3
Angle brackets < >
A word constrained by data type.
To define acceptable input, the angled brackets contain a descriptive
name followed by an underscore ( _ ) and suffix that indicates the
valid data type. For example:
<retries_int>
indicates that you should enter a number of retries, such as 5.
Data types include:
• <xxx_name>: A name referring to another part of the
configuration, such as policy_A.
• <xxx_index>: An index number referring to another part of the
configuration, such as 0 for the first static route.
• <xxx_pattern>: A regular expression or word with wild cards
that matches possible variations, such as *@example.com to
match all email addresses ending in @example.com.
• <xxx_fqdn>: A fully qualified domain name (FQDN), such as
mail.example.com.
• <xxx_email>: An email address, such as
[email protected].
• <xxx_url>: A uniform resource locator (URL) and its associated
protocol and host name prefix, which together form a uniform
resource identifier (URI), such as
http://www.fortinet./com/.
• <xxx_ipv4>: An IPv4 address, such as 192.168.1.99.
• <xxx_v4mask>: A dotted decimal IPv4 netmask, such as
255.255.255.0.
• <xxx_ipv4mask>: A dotted decimal IPv4 address and netmask
separated by a space, such as
192.168.1.99 255.255.255.0.
• <xxx_ipv4/mask>: A dotted decimal IPv4 address and
CIDR-notation netmask separated by a slash, such as such as
192.168.1.99/24.
• <xxx_ipv6>: A colon( : )-delimited hexadecimal IPv6 address,
such as 3f2e:6a8b:78a3:0d82:1725:6a2f:0370:6234.
• <xxx_v6mask>: An IPv6 netmask, such as /96.
• <xxx_ipv6mask>: An IPv6 address and netmask separated by a
space.
• <xxx_str>: A string of characters that is not another data type,
such as P@ssw0rd. Strings containing spaces or special
characters must be surrounded in quotes or use escape
sequences.
• <xxx_int>: An integer number that is not another data type,
such as 15 for the number of minutes.
01-402-120097-201001008
13
Entering FortiOS configuration data
Table 3: Command syntax notation (Continued)
Convention
Description
Curly braces { }
A word or series of words that is constrained to a set of options
delimited by either vertical bars or spaces.
You must enter at least one of the options, unless the set of options is
surrounded by square brackets [ ].
Options
delimited by
vertical bars |
Mutually exclusive options. For example:
{enable | disable}
indicates that you must enter either enable or disable, but must
not enter both.
Options
delimited by
spaces
Non-mutually exclusive options. For example:
{http https ping snmp ssh telnet}
indicates that you may enter all or a subset of those options, in any
order, in a space-delimited list, such as:
ping https ssh
Note: To change the options, you must re-type the entire list. For
example, to add snmp to the previous example, you would type:
ping https snmp ssh
If the option adds to or subtracts from the existing list of options,
instead of replacing it, or if the list is comma-delimited, the exception
will be noted.
Entering FortiOS configuration data
The configuration of a FortiGate unit is stored as a series of configuration settings in the
FortiOS configuration database. To change the configuration you can use the web-based
manager or CLI to add, delete or change configuration settings. These configuration
changes are stored in the configuration database as they are made.
Individual settings in the configuration database can be text strings, numeric values,
selections from a list of allowed options, or on/off (enable/disable).
Entering text strings (names)
Text strings are used to name entities in the configuration. For example, the name of a
firewall address, administrative user, and so on. You can enter any character in a
FortiGate configuration text string except, to prevent Cross-Site Scripting (XSS)
vulnerabilities, text strings in FortiGate configuration names cannot include the following
characters:
" (double quote), & (ampersand), ' (single quote), < (less than) and < (greater than)
You can determine the limit to the number of characters that are allowed in a text string by
determining how many characters the web-based manager or CLI allows for a given name
field. From the CLI, you can also use the tree command to view the number of
characters that are allowed. For example, firewall address names can contain up to 64
characters. When you add a firewall address to the web-based manager you are limited to
entering 64 characters in the firewall address name field. From the CLI you can do the
following to confirm that the firewall address name field allows 64 characters.
14
01-402-120097-201001008
config firewall address
tree
-- [address] --*name (64)
|- subnet
|- type
|- start-ip
|- end-ip
|- fqdn (256)
|- cache-ttl (0,86400)
|- wildcard
|- comment (64 xss)
|- associated-interface (16)
+- color (0,32)
Note that the tree command output also shows the number of characters allowed for other
firewall address name settings. For example, the fully-qualified domain name (fqdn) field
can contain up to 256 characters.
Entering numeric values
Numeric values are used to configure various sizes, rates, numeric addresses, or other
numeric values. For example, a static routing priority of 10, a port number of 8080, or an
IP address of 10.10.10.1. Numeric values can be entered as a series of digits without
spaces or commas (for example, 10 or 64400), in dotted decimal format (for example the
IP address 10.10.10.1) or as in the case of MAC or IPv6 addresses separated by colons
(for example, the MAC address 00:09:0F:B7:37:00). Most numeric values are standard
base-10 numbers, but some fields (again such as MAC addresses) require hexadecimal
numbers.
Most web-based manager numeric value configuration fields limit the number of numeric
digits that you can add or contain extra information to make it easier to add the acceptable
number of digits and to add numbers in the allowed range. CLI help includes information
about allowed numeric value ranges. Both the web-based manager and the CLI prevent
you from entering invalid numbers.
Selecting options from a list
If a configuration field can only contain one of a number of selected options, the
web-based manager and CLI present you a list of acceptable options and you can select
one from the list. No other input is allowed. From the CLI you must spell the selection
name correctly.
Enabling or disabling options
If a configuration field can only be on or off (enabled or disabled) the web-based manager
presents a check box or other control that can only be enabled or disabled. From the CLI
you can set the option to enable or disable.
Before you begin configuring and customizing features, take a moment to register your
Fortinet product at the Fortinet Technical Support web site, https://support.fortinet.com.
Many Fortinet customer services, such as firmware updates, technical support, and
FortiGuard Antivirus and other FortiGuard services, require product registration.
For more information, see the Fortinet Knowledge Center article Registration Frequently
Asked Questions.
01-402-120097-201001008
15
See the Fortinet products End User License Agreement.
Training
Fortinet Training Services provides courses that orient you quickly to your new equipment,
and certifications to verify your knowledge level. Fortinet provides a variety of training
programs to serve the needs of our customers and partners world-wide.
To learn about the training services that Fortinet provides, visit the Fortinet Training
Services web site at http://campus.training.fortinet.com, or email [email protected].
Documentation
The Fortinet Technical Documentation web site, http://docs.fortinet.com, provides the
most up-to-date versions of Fortinet publications, as well as additional technical
documentation such as technical notes.
In addition to the Fortinet Technical Documentation web site, you can find Fortinet
technical documentation on the Fortinet Tools and Documentation CD, and on the Fortinet
Knowledge Center.
Fortinet Tools and Documentation CD
Many Fortinet publications are available on the Fortinet Tools and Documentation CD
shipped with your Fortinet product. The documents on this CD are current at shipping
time. For current versions of Fortinet documentation, visit the Fortinet Technical
Documentation web site, http://docs.fortinet.com.
Fortinet Knowledge Base
The Fortinet Knowledge Base provides additional Fortinet technical documentation, such
as troubleshooting and how-to-articles, examples, FAQs, technical notes, a glossary, and
more. Visit the Fortinet Knowledge Base at http://kb.fortinet.com.
Comments on Fortinet technical documentation
Please send information about any errors or omissions in this or any Fortinet technical
document to [email protected].
Fortinet Technical Support provides services designed to make sure that your Fortinet
products install quickly, configure easily, and operate reliably in your network.
To learn about the technical support services that Fortinet provides, visit the Fortinet
Technical Support web site at https://support.fortinet.com.
You can dramatically improve the time that it takes to resolve your technical support ticket
by providing your configuration file, a network diagram, and other specific information. For
a list of required information, see the Fortinet Knowledge Base article FortiGate
Troubleshooting Guide - Technical Support Requirements.
16
01-402-120097-201001008
17
01-402-120097-201001008
18
01-402-120097-201001008
Ranging from the FortiGate-30B series for small offices to the FortiGate-5000 series for
large enterprises, service providers and carriers, the FortiGate line combines the
FortiOS™ security operating system and latest hardware technologies to provide a
comprehensive and high-performance array of security and networking functions.
FortiGate platforms incorporate sophisticated networking features, such as high
availability for maximum network uptime, and virtual domain (VDOM) capabilities to
separate various networks requiring different security policies.
At the heart of these networking security functions, is the firewall policies.Firewall policies
control all traffic attempting to pass through the FortiGate unit, between FortiGate
interfaces, zones, and VLAN subinterfaces. They are instructions the FortiGate unit uses
to decide connection acceptance and packet processing for traffic attempting to pass
through. When the firewall receives a connection packet, it analyzes the packet’s source
address, destination address, and service (by port number), and attempts to locate a
firewall policy matching the packet.
Firewall policies can contain many instructions for the FortiGate unit to follow when it
receives matching packets. Some instructions are required, such as whether to drop or
accept and process the packets, while other instructions, such as logging and
authentication, are optional. It is through these policies that the FortiGate unit grants or
denies the packets and information in or out of the network, who gets priority (bandwidth)
over other users, and when the packets can come through.
This chapter describes the features of the FortiGate firewall that help to protect your
network, and the firewall policies that are the instructions for the FortiGate unit. The
following topics are included in this section:
•
Firewall features
•
NAT vs. Transparent Mode
Firewall features
The FortiGate unit includes a rich feature set to protect your network from unwanted
attacks. This section provides an overview of what the FortiGate unit can protect against.
Each of these elements are configured and added to firewall policies as a means of
instructing the FortiGate unit what to do when encountering an security threat.
Antivirus
Antivirus is a group of features that are designed to prevent unwanted and potentially
malicious files from entering your network. These features all work in different ways,
whether by checking for a file size, name, type, or the presence of a virus or grayware
signature.
The antivirus scanning routines used are designed to share access to the network traffic.
This way, each individual feature does not have to examine the network traffic as a
separate operation, reducing overhead significantly. For example, if you enable file
filtering and virus scanning, the resources used to complete these tasks are only slightly
greater than enabling virus scanning alone. Two features do not require twice the
resources.
01-40002-112804-20101015
23
Firewall features
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:
24
•
Spyware/Grayware
•
Phishing
•
Instant Messaging
•
Peer-to-Peer File Sharing
•
Streaming Media
•
Blended Network Attacks
01-40002-112804-20101015
Firewall features
Spyware/Grayware
Spyware is also known as Grayware. Spyware is a type of computer program that
attaches itself to a user’s operating system. It does this without the user’s consent or
knowledge. It usually ends up on a computer because of something the user does such as
clicking on a button in a popup window. Spyware can do a number of things such as track
the user’s Internet usage, cause unwanted popup windows, and even direct the user to a
host web site. It is estimated that 80% of all personal computers are infected with
spyware. For further information, visit the FortiGuard Center.
Some of the most common ways of grayware infection include:
• Downloading shareware, freeware or other forms of file-sharing services
•
Clicking on pop-up advertising
•
Visiting legitimate web sites infected with grayware
Phishing
Phishing is the term used to describe social engineering attacks that use web technology
to trick users into revealing personal or financial information. Phishing attacks use web
sites and emails that claim to be from legitimate financial institutions to trick the viewer into
believing that they are legitimate. Although phishing is initiated by spam email, getting the
user to access the attacker’s web site is always the next step.
Pharming
Pharming is a next generation threat that is designed to identify, and extract financial, and
other key pieces of information for identity theft. Pharming is much more dangerous than
Phishing because it is designed to be completely hidden from the end user. Unlike
phishing attacks that send out spam email requiring the user to click to a fraudulent URL,
Pharming attacks require no action from the user outside of their regular web surfing
activities. Pharming attacks succeed by redirecting users from legitimate web sites to
similar fraudulent web sites that have been created to look and feel like the authentic web
site.
Instant messaging
Instant Messaging presents a number of problems. Instant Messaging can be used to
infect computers with spyware and viruses. Phishing attacks can be made using Instant
Messaging. There is also a danger that employees may use instant messaging to release
sensitive information to an outsider.
Peer-to-peer
Peer-to-Peer networks are used for file sharing. Such files may contain viruses.
Peer-to-Peer applications take up valuable network resources and lower employee
productivity but also has legal implications with the downloading of copyrighted material.
Peer-to-Peer file sharing and applications can also be used to expose company secrets.
Streaming media
Streaming media is a method of delivering multimedia, usually in the form of audio or
video to Internet users. The viewing of streaming media has increased greatly in the past
few years. The problem with this is the way it impacts legitimate business.
01-40002-112804-20101015
25
Firewall features
Blended network attacks
Blended network threats are rising and the sophistication of network threats is increasing
with each new attack. Attackers are learning from each previous successful attack and are
enhancing and updating attack code to become more dangerous and fast spreading.
Blended attacks use a combination of methods to spread and cause damage. Using virus
or network worm techniques combined with known system vulnerabilities, blended threats
can quickly spread through email, web sites, and Trojan applications. Blended attacks can
be designed to perform different types of attacks - from disrupting network services to
destroying or stealing information to installing stealthy back door applications to grant
remote access.
For more information on FortiGate web filter processes, features and configuration, see
the UTM Guide.
Antispam/Email Filter
The FortiGate unit performs email filtering (formerly called antispam) for IMAP, POP3, and
SMTP email. Email filtering includes both spam filtering and filtering for any words or files
you want to disallow in email messages. If your FortiGate unit supports SSL content
scanning and inspection you can also configure spam filtering for IMAPS, POP3S, and
SMTPS email traffic.
You can configure the FortiGate unit to manage unsolicited commercial email by detecting
and identifying spam messages from known or suspected spam servers. The FortiGuard
Antispam Service uses both a sender IP reputation database and a spam signature
database, along with sophisticated spam filtering tools, to detect and block a wide range of
spam messages. Using FortiGuard Antispam protection profile settings you can enable IP
address checking, URL checking, E-mail checksum check, and Spam submission.
Updates to the IP reputation and spam signature databases are provided continuously via
the global FortiGuard distribution network.
From the FortiGuard Antispam Service page in the FortiGuard center you can use IP and
signature lookup to check whether an IP address is blacklisted in the FortiGuard antispam
IP reputation database, or whether a URL or email address is in the signature database.
Email filter techniques
The FortiGate unit has a number of techniques available to help detect spam. Some use
the FortiGuard AntiSpam service, requiring a subscription. The remainder use your DNS
servers, or lists you must maintain.
The FortiGate unit queries the FortiGuard Antispam service to determine if the IP address
of the client delivering the email is blacklisted. A match will have the FortiGate unit treat
delivered messages as spam. If enabled, the FortiGate unit will check all the IP addresses
in the header of SMTP email against the FortiGuard Antispam service.
The FortiGate unit queries the FortiGuard Antispam service to determine if any URL in the
message body is associated with spam. If any URL is blacklisted, the FortiGate unit
determines that the email message is spam
The FortiGate unit sends a hash of an email to the FortiGuard Antispam server which
compares the hash to hashes of known spam messages stored in the FortiGuard
Antispam database. If the hash results match, the email is flagged as spam.
The FortiGate unit compares the IP address of the client delivering the email to the
addresses in the IP address black/white list specified in the protection profile. If a match is
found, the FortiGate unit will take the action configured for the matching black/white list
entry against all delivered email.
26
01-40002-112804-20101015
Firewall features
The FortiGate unit takes the domain name specified by the client in the HELO greeting
sent when starting the SMTP session, and does a DNS lookup to determine if the domain
exists. If the lookup fails, the FortiGate unit determines that any messages delivered
during the SMTP session are spam.
The FortiGate unit compares the sender email address, as shown in the message
envelope MAIL FROM, to the addresses in the email address black/white list specified in
the protection profile. If a match is found, the FortiGate unit will take the action configured
for the matching black/white list entry.
The FortiGate unit performs a DNS lookup on the reply-to domain to see if there is an A or
MX record. If no such record exists, the message is treated as spam.
The FortiGate unit will block email messages based on matching the content of the
message with the words or patterns in the selected spam filter banned word list.
For more information on FortiGate antispam processes, features and configuration, see
the UTM Guide.
Intrusion Protection
The FortiGate Intrusion Protection system combines signature detection and prevention
with low latency and excellent reliability. With intrusion Protection, you can create multiple
IPS sensors, each containing a complete configuration based on signatures. Then, you
can apply any IPS sensor to each protection profile. The FortiGate intrusion protection
system protects your network from outside attacks. Your FortiGate unit has two techniques
to deal with these attacks.
Anomaly-based defense is used when network traffic itself is used as a weapon. A host
can be flooded with far more traffic than it can handle, making the host inaccessible. The
most common example is the denial of service attack, in which an attacker directs a large
number of computers to attempt normal access of the target system. If enough access
attempts are made, the target is overwhelmed and unable to service genuine users. The
attacker does not gain access to the target system, but it is not accessible to anyone else.
The FortiGate unit DoS feature will block traffic over a certain threshold from the attacker,
allowing connections from other legitimate users.
Signature-based defense is used against known attacks or vulnerability exploits. These
often involve an attacker attempting to gain access to your network. The attacker must
communicate with the host in an attempt to gain access, and this communication will
include particular commands or sequences of commands and variables. The IPS
signatures include these command sequences, allowing the FortiGate unit to detect and
stop the attack.
The basis of signature-based intrusion protection are the IPS signatures, themselves.
Every attack can be reduced to a particular string of commands or a sequence of
commands and variables. Signatures include this information so your FortiGate unit
knows what to look for in network traffic.
Signatures also include characteristics about the attack it describes. These characteristics
include the network protocol in which it will appear, the vulnerable operating system, and
the vulnerable application.
Before examining network traffic for attacks, the FortiGate will identify each protocol
appearing in the traffic. Attacks are protocol-specific so your FortiGate unit conserves
resources by looking for attacks only in the protocols used to transmit them. For example,
the FortiGate unit will only examine HTTP traffic for the presence of a signature describing
an HTTP attack.
Once the protocol decoders separate the network traffic by protocol, the IPS engine
examines the network traffic for the attack signatures.
01-40002-112804-20101015
27
Firewall features
The IPS engine does not examine network traffic for all signatures, however. You must
first create an IPS sensor and specify which signatures are included. You do not have to
choose each signature you want to include individually, however. Instead, filters are used
to define the included signatures.
IPS sensors contain one or more IPS filters. A filter is simply a collection of signature
attributes you specify. The signatures that have all of the attributes specified in a filter are
included in the IPS signature.
For example, if your FortiGate unit protects a Linux server running the Apache web server
software, you could create a new filter to protect it. Set OS to Linux, and Application to
Apache and the filter will include only the signatures applicable to both Linux and Apache.
If you wanted to scan for all the Linux signatures and all the Apache signatures, you would
create two filters, one for each.
For more information on FortiGate IPS processes, features and configuration, see the
UTM Guide.
Traffic Shaping
Traffic shaping, when included in a firewall policy, controls the bandwidth available to, and
sets the priority of the traffic processed by, the policy. Traffic shaping makes it possible to
control which policies have the highest priority when large amounts of data are moving
through the FortiGate unit. For example, the policy for the corporate web server might be
given higher priority than the policies for most employees’ computers. An employee who
needs extra high speed Internet access could have a special outgoing policy set up with
higher bandwidth.
Traffic shaping is available for firewall policies whose Action is ACCEPT, IPSEC, or
SSLVPN. It is also available for all supported services, including H.323, TCP, UDP, ICMP,
and ESP
Traffic shaping cannot increase the total amount of bandwidth available, but you can use it
to improve the quality of bandwidth-intensive and sensitive traffic.
The bandwidth available for traffic set in a traffic shaper is used to control data sessions
for traffic in both directions. For example, if guaranteed bandwidth is applied to an internal
and an external FTP policy, and a user on an internal network uses FTP to put and get
files, both the put and get sessions share the bandwidth available to the traffic controlled
by the policy.
Once included in a firewall policy, the guaranteed and maximum bandwidth is the total
bandwidth available to all traffic controlled by the policy. If multiple users start multiple
communications session using the same policy, all of these communications sessions
must share from the bandwidth available for the policy.
However, bandwidth availability is not shared between multiple instances of using the
same service if these multiple instances are controlled by different policies. For example,
you can create one FTP policy to limit the amount of bandwidth available for FTP for one
network address and create another FTP policy with a different bandwidth availability for
another network address
Traffic shaping attempts to “normalize” traffic peaks/bursts to prioritize certain flows over
others. But there is a physical limitation to the amount of data which can be buffered and
to the length of time. Once these thresholds have been surpassed, frames and packets
will be dropped, and sessions will be affected in other ways. For example, incorrect traffic
shaping configurations may actually further degrade certain network flows, since the
excessive discarding of packets can create additional overhead at the upper layers that
may be attempting to recover from these errors.
28
01-40002-112804-20101015
A basic traffic shaping approach is to prioritize certain traffic flows over other traffic whose
potential discarding is less advantageous. This would mean that you accept sacrificing
certain performance and stability on low-priority traffic, in order to increase or guarantee
performance and stability to high-priority traffic.
If, for example, you are applying bandwidth limitations to certain flows, you must accept
the fact that these sessions can be limited and therefore negatively impacted. Traffic
shaping applied to a firewall policy is enforced for traffic which may flow in either direction.
Therefore a session which may be set up by an internal host to an external one, through
an Internal-to-External policy, will have traffic shaping applied even if the data stream
flows external to internal. One example may be an FTP “get” or a SMTP server connecting
to an external one, in order to retrieve email.
Note that traffic shaping is effective for normal IP traffic at normal traffic rates. Traffic
shaping is not effective during periods when traffic exceeds the capacity of the FortiGate
unit. Since packets must be received by the FortiGate unit before they are subject to traffic
shaping, if the FortiGate unit cannot process all of the traffic it receives, then dropped
packets, delays, and latency are likely to occur.
For more information on traffic shaping, see the FortiGate Traffic Shaping Guide.
The FortiGate unit can run in two modes: Network Address Translation (NAT) mode and
Transparent mode. Generally speaking, both modes function the same, with some minor
differences in feature availability due to the nature of the mode. With both modes,
however, firewall policies define how traffic moves, or is prevented, from moving within the
local network or to an external network or the Internet.
NAT mode
In NAT mode, the FortiGate unit is visible to the network that it is connected to. All of its
interfaces are on different subnets. Each interface that is connected to a network must be
configured with an IP address that is valid for that subnetwork.
You would typically use NAT mode when the FortiGate unit is deployed as a gateway
between private and public networks. In its default NAT mode configuration, the FortiGate
unit functions as a firewall. Firewall policies control communications through the FortiGate
unit to both the Internet and between internal networks. In NAT mode, the FortiGate unit
performs network address translation before IP packets are sent to the destination
network. For example, a company has a FortiGate unit as their interface to the Internet.
The FortiGate unit also acts as a router to multiple sub-networks within the company.
01-40002-112804-20101015
29
Figure 2: FortiGate unit in NAT mode
172
.20 WA
traf NAT
.12 N 1
fic po
0.1
29
ext betw licies
ern ee
al n n in contr
etw tern ollin
ork al a g
s.
nd
P
10. ort 2
10.
10.
P
192 ort 1
.16
8.1
.1
1
ng
li
ro
nt n .
co e s
s e rk
ie tw o
ic e tw
ol b e
P ffic al n
tra ern
t
in
k
or
w
t
Ne /24
al .1.0
n
er 8
Int 2.16
19
k
or
w
t
Ne 24
al 0.0/
n
er .1
Int .10
10
In this situation, as shown in Figure 2, the FortiGate unit is set to NAT mode. Using this
mode, the FortiGate unit can have a designated port for the Internet, in this example,
wan1 with an address of 172.20.120.129, which is the public IP address. The internal
network segments are behind the FortiGate unit and invisible to the public access, for
example port 2 with an address of 10.10.10.1. The FortiGate unit translates IP addresses
passing through it to route the traffic to the correct subnet or the Internet.
How address translation works
In NAT mode, firewall policies perform the address translation between the internal and
external interfaces. When a user accesses a web site, for example, the web site only
knows the request by the external interface of the FortiGate unit, in this example, wan1.
For example, a user surfs to a web server (IP address 172.50.20.20). The user’s PC has
an IP address of 10.10.10.2 on the Internal interface. The FortiGate unit receives the
request from the user to go to the web server. The external interface for the FortiGate unit
to send and receive information is want 1 (172.20.120.129). The FortiGate unit looks at
the firewall policies to determine where the request should go, in this case, out the
external interface.
The FortiGate unit changes the packet information of the return address to its external
interface, while keeping track of the originating user request, and the originating PC
address. Once modified, the FortiGate unit sends the packet information to the web
server.
30
01-40002-112804-20101015
Figure 3: Sender’s IP internal address translated to the FortiGate unit’s external address
C
tP
en .2
Cli 0.10
.1
10
3
1
2
20
0.
.2 2
5 0 0.
2. .1
17 .10
n: 0
io : 1
at ce
t i n ur
es o
D S
nt
Se et
ck
Pa
Inte
Fir
ew
N A all P
T e olic
nab y
1
led
2
3
rna
l
WA
N
1
3
1
2
20
0. 9
.2 12
50 0.
2. 12
17 0.
n: .2
io 72
at 1
tin e:
es rc
D ou
S
d
ive
c e et
e
R ck
Pa
r
rve
Se .20
b
0
We 50.2
2.
7
1
When the web server sends the response, it sends it to what it believes to be the
originating address, the FortiGate wan1 address, 172.20.120.129. When the FortiGate
unit receives the information, it determines where it should go by looking at its session
information. Using firewall policies, it determines that the information should be going to
the originating user at 10.10.10.2. The FortiGate changes the destination IP to the correct
user and delivers the packet.
01-40002-112804-20101015
31
Figure 4: Web server sends to FortiGate external address and translated to internal address
C
tP
en .2
Cli 0.10
.1
10
3
d
ive
c e et
e
R ck
Pa
1
2
.2
10 0
0. .2
.1 20
10 0.
n: .5
io 7 2
at 1
tin e:
es rc
D ou
S
Inte
Fir
ew
N A all P
T e olic
nab y
1
led
2
3
rna
l
WA
N
1
3
1
2
.1
20
.1 20
20 0.
2. .2
17 .50
n: 2
io 17
at :
tin rce
es u
D So
nt
Se et
k
c
Pa
er
erv 20
S
.
b 0
We 50.2
2.
7
1
Throughout this exchange, which occurs in nanoseconds, and because of network
address translation, the web server does not know that the originating address is really
10.10.10.2, but 172.20.120.129.
Central NAT table
The central NAT table enables you to define, and control with more granularity, the
address translation performed by the FortiGate unit. With the NAT table, you can define
the rules which dictate the source address or address group and which IP pool the
destination address uses.
The NAT table also functions in the same way as the firewall policy table. That is, the
FortiGate unit reads the NAT rules in a top-down methodology, until it hits a matching rule
for the incoming address. This enables you to create multiple NAT policies that dictate
which IP pool is used based on the source address. The NAT policies can be rearranged
within the policy list as well, the same way as firewall policies.
NAT policies are applied to network traffic after a firewall policy. For more information on
central NAT tables, see the System Admnistration Guide .
Transparent mode
In Transparent mode, the FortiGate unit is invisible to the network. All of its interfaces are
on the same subnet and share the same IP address. You only have to configure a
management IP address so that you can make configuration changes.
You would typically use the FortiGate unit in Transparent mode on a private network
behind an existing firewall or behind a router. In Transparent mode, the FortiGate unit also
functions as a firewall. Firewall policies control communications through the FortiGate unit
to the Internet and internal network. No traffic can pass through the FortiGate unit until you
add firewall policies.
32
01-40002-112804-20101015
For example, the company has a router or other firewall in place. The network is simple
enough that all users are on the same internal network. They need the FortiGate unit to
perform antispam, antivirus and intrusion protection and similar traffic scanning. In this
situation, as shown in Figure 5, the FortiGate unit is set to transparent mode. The traffic
passing through the FortiGate unit does not change the addressing from the router to the
internal network. Firewall policies and protection profiles define the type of scanning the
FortiGate unit performs on traffic entering the network.
Figure 5: FortiGate unit in transparent mode
20
4.2
Ga
3.1
.5
tew
10
net ay to
.10
wo pu
.10
rk
blic
.2
WA
N1
tra NAT
ffic p
ext betw olicies
ern ee
al n n in contr
etw tern ollin
ork al a g
s.
nd
Inte
rna
l
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 - webbased manager
1 Go to System > Config >
Operation.
2 Select Transparent for the
Operation Mode from the list
box.
3 Enter the Management IP
address and netmask
10.11.101.10
255.255.255.0.
4 Enter the Default Gateway address of 10.11.101.1.
5 Select Apply.
01-40002-112804-20101015
33
To enable Transparent mode - CLI
config system settings
set opmode transparent
set manageip 10.11.101.10 255.255.255.0
set gateway 10.11.101.1
end
For information on unique Transparent mode firewall configurations, see the System
Administration Guide .
Note: This guide and its examples are constructed with the FortiGate unit running in NAT
mode, unless otherwise noted.
Operating mode differences
The FortiGate unit, running in either NAT or Transparent mode have essentially the same
feature set. Due to the differences in the modes, however, some features are not available
in Transparent mode. The list below outlines the key features not available in Transparent
mode:
34
•
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
01-40002-112804-20101015
Life of a Packet
Directed by firewall policies, a FortiGate unit screens network traffic from the IP layer up
through the application layer of the TCP/IP stack. This chapter provides a general,
high-level description of what happens to a packet as it travels through a FortiGate
security system.
The FortiGate unit performs three types of security inspection:
•
stateful inspection, that provides individual packet-based security within a basic
session state
•
flow-based inspection, that buffers packets and uses pattern matching to identify
security threats
•
proxy-based inspection, that reconstructs content passing through the FortiGate unit
and inspects the content for security threats.
Each inspection component plays a role in the processing of a packet as it traverses the
FortiGate unit en route to its destination. To understand these inspections is the first step
to understanding the flow of the packet.
This chapter includes the following topics:
•
Stateful inspection
•
Flow inspection
•
Proxy inspection
•
FortiOS functions and security layers
•
Packet flow
•
Transparent mode routing
•
Example 1: client/server connection
•
Example 2: Routing table update
•
Example 3: Dialup IPsec with application control
Stateful inspection
With stateful inspection, the FortiGate unit looks at the first packet of a session to make a
security decision. Common fields inspected include TCP SYN and FIN flags to identity the
start and end of a session, the source/destination IP, source/destination port and protocol.
Other checks are also performed on the packed payload and sequence numbers to verify
it as a valid communication and that the data is not corrupted or poorly formed.
The FortiGate unit makes the decision to drop, pass or log a session based on what is
found in the first packet of the session. If the FortiGate unit decides to drop or block the
first packet of a session, then all subsequent packets in the same session are also
dropped or blocked without being inspected. If the FortiGate unit accepts the first packet of
a session, then all subsequent packets in the same session are also accepted without
being inspected.
01-40002-112804-20101015
35
Flow inspection
Life of a Packet
Figure 6: Stateful inspection of packets through the FortiGate unit
1
3
2
nt
Se et
ck
Pa
SY
N,
IP,
TC
1
P
2
3
1
3
2
ed
eiv t
c
Re cke
Pa
Flow inspection
With flow inspection, the FortiGate unit samples multiple packets in a session and multiple
sessions, and uses a pattern matching engine to determine the kind of activity that the
session is performing and to identify possible attacks or viruses. For example, if
application control is operating, flow inspection can sample network traffic and identify the
application that is generating the activity. Flow-based antivirus can sample network traffic
and determine if the content of the traffic contains a virus, IPS can sample network traffic
and determine if the traffic constitutes an attack. The security inspection occurs as the
data is passing from its source to its destination. Flow inspection identifies and blocks
security threats in real time as they are identified.
Figure 7: Flow inspection of packets through the FortiGate unit
3
2
nt
Se et
ck
Pa
IPS
,
Ap Flow
p C -AV
ont ,
rol
2
1
2
d
ive
ce et
e
R ck
Pa
Flow-based inspections typically require less processing than proxy-based inspection, and
therefore flow-based antivirus performance can be better than proxy-based antivirus
performance. However, some threats can only be detected when a complete copy of the
payload is obtained so, proxy-based inspection tends to be more accurate and complete
than flow-based inspection.
36
01-40002-112804-20101015
Life of a Packet
Proxy inspection
Proxy inspection
With flow inspection, the FortiGate unit will pass all the packets between the source and
destination, and keeps a copy of the packets in its memory. It then uses a reconstruction
engine to build the content of the original traffic. The security inspection occurs after the
data has passed from its source to its destination.
Proxy inspection examines the content contained a content protocol session for security
threats. Content protocols include the HTTP, FTP, and email protocols. Security threats
can be found in files and other content downloaded using these protocols. With proxy
inspection, the FortiGate unit downloads the entire payload of a content protocol sessions
and re-constructs it. For example, proxy inspection can reconstruct an email message and
its attachments. After a satisfactory inspection the FortiGate unit passes the content on to
the client. If proxy inspection detects a security threat in the content, the content is
removed from the communication stream before the it reaches its destination. For
example, if proxy inspection detects a virus in an email attachment, the attachment is
removed from the email message before its sent to the client. Proxy inspection is the most
thorough inspection of all, although it requires more processing power, and this may result
in lower performance.
Figure 8: Proxy inspection of packets through the FortiGate unit
Em
a
filteil filter
r, D , we
LP, b
AV
1
3
2
nt
Se et
ck
Pa
3
2
1
1
3
2
d
ive
ce et
e
R ck
Pa
FortiOS functions and security layers
Within these security inspection types, FortiOS functions map to different inspections. The
table below outlines when actions are taken as a packet progresses through its life within
a FortiGate unit.
Table 4: FortiOS security functions and security layers
Security Function
Firewall
IPsec VPN
Traffic Shaping
User Authentication
Management Traffic
01-40002-112804-20101015
Stateful
Flow
Proxy
9
9
9
9
9
37
Packet flow
Life of a Packet
Table 4: FortiOS security functions and security layers (Continued)
Security Function
SSL VPN
Intrusion Prevention
Flow-based Antivirus
Application Control
VoIP inspection
Proxy Antivirus
Email Filtering
Web Filtering (Antispam)
Data Leak Prevention
Stateful
Flow
Proxy
9
9
9
9
9
9
9
9
9
Packet flow
After the FortiGate unit’s external interface receives a packet, the packet proceeds
through a number of steps on its way to the internal interface, traversing each of the
inspection types, depending on the firewall policy and UTM profile configuration. The
diagram in Figure 9 on page 39 is a high level view of the packet’s journey.
The description following is a high-level description of these steps as a packet enters the
FortiGate unit towards its destination on the internal network. Similar steps occur for
outbound traffic.
Packet inspection (Ingress)
In the diagram in Figure 9 on page 39, in the first set of steps (ingress), a number of
header checks take place to ensure the packet is valid and contains the necessary
information to reach its destination. This includes:
38
•
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
01-40002-112804-20101015
Life of a Packet
Packet flow
Figure 9: Packet flow
3
1
2
Packet
Packet flow: Ingress
Interface
(Link layer)
Stateful
Inspection
Engine
DoS
Sensor
Session
Helpers
IP Integrity
Header checking
Management
Traffic
SSL VPN
NAT
(DNAT)
IPsec
User
Authentication
Traffic
Shaping
Routing
Session
Tracking
Policy
Lookup
No
UTM
Yes
No
Antivirus,
Web Filter,
Email Filter,
DLP
Flow-based
Antivirus
VoIP
Inspection
Application
Control
Flow-based
Inspection
Engine
IPS
Yes
IPsec
NAT
(SNAT)
Web Filter
(HTTP, HTTPS)
Email Filter
Antivirus
(HTTP(S), SMTP(S),
POP3(S), IMAP(S), FTP,
NNTP, IM)
3
Routing
Interface
Packet flow: Egress
Proxy-based
Inspection
Engine
1
2
Packet
Interface
Ingress packets are received by a FortiGate interface.The packet enters the system, and
the interface network device driver passes the packet to the Denial of Service (DoS)
sensors, if enabled, to determine whether this is a valid information request or not.
DoS sensor
DoS scans are handled very early in the life of the packet to determine whether the traffic
is valid or port of a DoS attack. Unlike signature-based IPS which inspects all the packets
within a certain traffic flow, the DoS module inspects all traffic flows but only tracks packets
that can be used for DoS attacks (for example TCP SYN packets), to ensure they are
within the permitted parameters. Suspected DoS attacks are blocked, other packets are
allowed.
IP integrity header checking
The FortiGate unit reads the packet headers to verify if the packet is a valid TCP, UDP,
ICMP,SCTP, or GRE packet. The only verification that is done at this step to ensure that
the protocol header is the correct length. If it is, the packet is allowed to carry on to the
next step. If not, the packet is dropped.
01-40002-112804-20101015
39
Packet flow
Life of a Packet
IPsec
If the packet is an IPsec packet, the IPsec engine attempts to decrypt it. The IPsec engine
applies the correct encryption keys to the IPSec packet and sends the unencrypted packet
to the next step. IPsec is bypassed when for non-IPSec traffic and for IPsec traffic that
cannot be decrypted by the FortiGate unit.
Destination NAT (DNAT)
The FortiGate unit checks the NAT table and determines the destination IP address for the
traffic. This step determines whether a route to the destination address actually exists.
For example, if a user’s browser on the internal network at IP address 192.168.1.1 visited
the web site www.example.com using NAT, after passing through the FortiGate unit the
source IP address becomes NATed to the FortiGate unit external interface IP address.
The destination address of the reply back from www.example.com is the IP address of the
FortiGate unit internal interface. For this reply packet to be returned to the user, the
destination IP address must be destination NATed to 192.168.1.1.
For more information on network address translation, see “How address translation works”
on page 30.
DNAT must take place before routing so that the FortiGate unit can route packets to the
correct destination.
Routing
The routing step determines the outgoing interface to be used by the packet as it leaves
the FortiGate unit. In the previous step, the FortiGate unit determined the real destination
address, so it can now refer to its routing table and decide where the packet must go next.
Routing also distinguishes between local traffic and forwarded traffic and selects the
source and destination interfaces used by the firewall policy engine to accept or deny the
packet.
Policy lookup
The policy look up is where the FortiGate unit reviews the list of firewall policies which
govern the flow of network traffic, from the first entry to the last, to find a match for the
source and destination IP addresses and port numbers. The decision to accept or deny a
packet, after being verified as a valid request within the stateful inspection, occurs here. A
denied packet is discarded. An accepted packet will have further actions taken. If IPS is
enabled, the packet will go to Flow-based inspection engine, otherwise it will go to the
Proxy-based inspection engine.
If no other UTM options are enabled, then the session was only subject to stateful
inspection. If the action is accept, the packet will go to Source NAT to be ready to leave
the FortiGate unit.
Session tracking
Part of the stateful inspection engine, session tracking maintains session tables that
maintain information about sessions that the stateful inspection module uses for
maintaining sessions, NAT, and other session related functions.
40
01-40002-112804-20101015
Life of a Packet
Packet flow
User authentication
User authentication added to firewall policies is handled by the stateful inspection engine,
which is why Firewall authentication is based on IP address. Authentication takes place
after policy lookup selects a firewall policy that includes authentication. This is also known
as identify-based policies. Authentication also takes place before UTM features are
applied to the packet.
Management traffic
This local traffic is delivered to the FortiGate unit TCP/IP stack and includes
communication with the web-based manager, the CLI, the FortiGuard network, log
messages sent to FortiAnalyzer or a remote syslog server, and so on. Management traffic
is processed by applications such as the web server which displays the FortiOS
web-based manager, the SSH server for the CLI or the FortiGuard server to handle local
FortiGuard database updates or FortiGuard Web Filtering URL lookups.
SSL VPN traffic
For local SSL VPN traffic, the internal packets are decrypted and are routed to a special
interface. This interface is typically called ssl.root for decryption. Once decrypted, the
packets goes to policy lookup.
Session helpers
Some protocols include information in the packet body (or payload) that must be analyzed
to successfully process sessions for this protocol. For example, the SIP VoIP protocol
uses TCP control packets with a standard destination port to set up SIP calls. To
successfully process SIP VoIP calls, FortiOS must be able to extract information from the
body of the SIP packet and use this information to allow the voice-carrying packets
through the firewall.
FortiOS uses session helpers to analyze the data in the packet bodies of some protocols
and adjust the firewall to allow those protocols to send packets through the firewall.
Flow-based inspection engine
Flow-based inspection is responsible for IPS, application control, flow-based antivirus
scanning and VoIP inspection. Packets are sent to flow-based inspection if the firewall
policy that accepts the packets includes one or more of these UTM features.
Note: Flow-based antivirus scanning is only available on some FortiGate models.
Once the packet has passed the flow-based engine, it can be sent to the proxy inspection
engine or egress.
Proxy-based inspection engine
The proxy inspection engine is responsible for carrying out antivirus protection, email
filtering (antispam), web filtering and data leak prevention. The proxy engine will process
multiple packets to generate content before it is able to make a decision for a specific
packet.
01-40002-112804-20101015
41
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.
In transparent mode, the FortiGate unit acts as an IP forwarding bridge between
interfaces. All IP packets are handed off to the firewall module, which controls packet
forwarding. If a firewall policy accepts a packet, the packet is forwarded to the destination
interface specified in the firewall policy.
You can add firewall policies to accept IP packets and multicast packets. All other packets,
for example, IPX, Appletalk, and DecNet and so on, are blocked unless interface
configurations are changed to forward these types of packets.
The following example illustrates the flow of a packet of a client/web server connection
with authentication and FortiGuard URL and antivirus filtering.
This example includes the following steps:
Initiating connection from client to web server
1 Client sends packet to web server.
2 Packet intercepted by FortiGate unit interface.
2.1 Link level CRC and packet size checking. If the size is correct, the packet
continues, otherwise it is dropped.
3 DoS sensor - checks are done to ensure the sender is valid and not attempting a denial
of service attack.
4 IP integrity header checking, verifying the IP header length, version and checksums.
5 Next hop route
6 Policy lookup
7 User authentication
42
01-40002-112804-20101015
Life of a Packet
8 Proxy inspection
7.1 Web Filtering
7.2 FortiGuard Web Filtering URL lookup
7.3 Antivirus scanning
9 Source NAT
10 Routing
11 Interface transmission to network
12 Packet forwarded to web server
Response from web server
1 Web Server sends response packet to client.
2 Packet intercepted by FortiGate unit interface
2.1 Link level CRC and packet size checking.
3 IP integrity header checking.
4 DoS sensor.
5 Proxy inspection
5.1 Antivirus scanning.
6 Source NAT.
7 Stateful Policy Engine
7.1 Session Tracking
8 Next hop route
10 Packet returns to client
01-40002-112804-20101015
43
Life of a Packet
Figure 10: Client/server connection
3
1
2
Client sends packet
to web server
Interface
(Link layer)
Stateful
Policy
Engine
Session
Tracking
Proxy
Inspection
Engine
DoS
Sensor
User
Authentication
Antivirus
FortiGate Unit
IP Integrity
Header checking
NAT
(DNAT)
Policy
Lookup
Routing
FortiGuard
Web Filtering
Web Filter
FortiGuard
NAT
(SNAT)
Interface
(Link layer)
Routing
Proxy Inspection
Engine
Packet
Exits
Internet
Web Server
Antivirus
DoS
Sensor
NAT
(SNAT)
Session
Tracking
Interface
(Link layer)
IP Integrity
Header checking
Packet
Enters
Routing
Stateful Policy
Engine
Interface
(Link layer)
3
1
2
Packet exits and
returns to client
1 FortiGate unit receives routing update packet
of service attack.
5 Stateful policy engine
4.1 Management traffic (local traffic)
6 Routing module
5.1 Update routing table
44
01-40002-112804-20101015
Life of a Packet
Figure 11: Routing table update
3
1
2
Routing
update
packet
Packet
FortiGate Unit
Interface
(Link layer)
IP Integrity
Header checking
DoS
Sensor
Routing Table
Management
Traffic
Stateful
Policy
Engine
Routing
Module
Update routing table
1 FortiGate unit receives IPsec packet from Internet
of service attack.
5 IPsec
5.1 Determines that packet matched IPsec phase 1 configuration
5.2 Unencrypted packet
6 Next hop route
7.1 Session tracking
8 Flow inspection engine
8.1 IPS
8.2 Application control
9 Source NAT
10 Routing
12 Packet forwarded to internal server
Response from server
1 Server sends response packet
2.1 Link level CRC and packet size checking
3 IP integrity header checking.
4 DoS sensor
01-40002-112804-20101015
45
Life of a Packet
5 Flow inspection engine
5.1 IPS
5.2 Application control
6.1 Session tracking
7 Next hop route
8 IPsec
8.1 Encrypts packet
9 Routing
11 Encrypted Packet returns to internet
Figure 12: Dialup IPsec with application control
3
1
2
IPsec packet
received from
Internet
Encrypted or
encapsulated packet
FortiGate Unit
Interface
(Link layer)
IP Integrity
Header checking
DoS
Sensor
IPsec
NAT
Packet decryption
Application
Control
Session
Tracking
IPS
Flow Inspection Engine
Next Hop
Route
Stateful Policy Engine
Packet Exits
Source
NAT
Routing
Interface
(Link layer)
3
1
2
Internal
Server
Destintion
NAT
IP Integrity
Header checking
DoS
Sensor
Interface
(Link layer)
3
1
2
Response Packet
Packet Enters
Application
Control
Session
Tracking
IPS
Next Hop
Route
Stateful Policy Engine
Flow Inspection Engine
Interface
(Link layer)
Routing
IPsec
Packet encryption
3
1
2
Packet
Exits and returns
to source
Encrypted or
encapsulated packet
46
01-40002-112804-20101015
47
Life of a Packet
01-40002-112804-20101015
48
Life of a Packet
01-40002-112804-20101015
Firewall components
The FortiGate unit’s primary purpose is to act as a firewall to protect your networks from
unwanted attacks and to control the flow of network traffic. The FortiGate unit does this
through the use of firewall policies. The policies you create review the traffic passing
through the device to determine if the traffic is allowed into or out of the network, if it is
normal network traffic or encrypted VPN or SSL VPN traffic, where it is going and how it
should be handled.
Every firewall policy uses similar components. This section briefly describes these
components.
The following topics are included in this section:
•
Interfaces
•
Addressing
•
Routing
•
Ports
•
Services
•
Schedules
•
UTM profiles
Interfaces
Interfaces, both physical and virtual, enable traffic to flow to and from the internal network,
and the Internet and between internal networks. The FortiGate unit has a number of
options for setting up interfaces and groupings of subnetworks that can scale to a
company’s growing requirements.
Physical
FortiGate units have a number of physical ports where you connect Ethernet or optical
cables. Depending on the model, they can have anywhere from four to 40 physical ports.
Some units have a grouping of ports labelled as internal, providing a built-in switch
functionality.
In FortiOS, the port names, as labeled on the FortiGate unit, appear in the web-based
manager in the Unit Operation the Dashboard. They also appear when you are configuring
the interfaces, by going to System > Network > Interface. As shown below, the
FortiGate-100A has eight interfaces
Figure 13: FortiGate-100A physical interfaces
4
DC+12V
Console
01-40002-112804-20101015
USB
3
2
Internal
1
DMZ 2
DMZ 1
WAN 2
WAN 1
49
Interfaces
Firewall components
Figure 14: FortiGate-100A interfaces on the Dashboard
Figure 15: Configuring the FortiGate-100A ports
Normally the internal interface is configured as a single interface shared by all physical
interface connections - a switch. The switch mode feature has two states - switch mode
and interface mode. Switch mode is the default mode with only one interface and one
address for the entire internal switch. Interface mode allows you to configure each of the
internal switch physical interface connections separately. This enables you to assign
different subnets and netmasks to each of the internal physical interface connections.
The larger FortiGate units can also include Advanced Mezzanine Cards (AMC), which can
provide additional interfaces (ethernet or optical), with throughput enhancements for more
efficient handling of specialized traffic. These interfaces appear in FortiOS as port
amc/sw1, amc/sw2 and so on. In the following illustration, the FortiGate-3810A has three
AMC cards installed: two single-width (amc/sw1, amc/sw2) and one double-width
(amc/dw).
Figure 16: FortiGate-3810A AMC card port naming
50
01-40002-112804-20101015
Firewall components
Interfaces
For more information on configuring physical ports, see “Addressing” on page 57.
Interfaces, especially the public-facing ports can be potentially accessed by those who
you may not want access to the FortiGate unit. When setting up the FortiGate unit, you
can set the type of protocol an administrator must use to access the FortiGate unit. The
options include:
•
HTTPS
•
HTTP
•
SSH
•
TELNET
•
PING
•
SNMP
You can select as many, or as few, even none, that are accessible by an administrator.
Example
This example adds an IPv4 address 172.20.120.100 to the WAN1 interface as well as the
administrative access to HTTPS and SSH. As a good practice, set the administrative
access when you are setting the IP address for the port.
To add an IP address on the WAN1 interface - web-based manager
1 Go to System > Network > Interface.
2 Select the WAN1 interface row and select Edit.
3 Select the Addressing Mode of Manual.
4 Enter the IP address for the port of 172.20.120.100/24.
5 For Administrative Access, select HTTPS and SSH.
6 Select OK.
To create IP address on the WAN1 interface - CLI
config system interface
edit wan1
set ip 172.20.120.100/24
set allowaccess https ssh
end
Note: When adding to, or removing a protocol, you must type the entire list again. For
example, if you have an access list of HTTPS and SSH, and you want to add PING, typing:
set allowaccess ping
...only PING will be set. In this case, you must type...
set allowaccess https ssh ping
01-40002-112804-20101015
51
Interfaces
Firewall components
Wireless
A wireless interface is similar to a physical interface only it does not include a physical
connection. The FortiWiFi units enables you to add multiple wireless interfaces that can be
available at the same time (the FortiWiFi-30B can only have one wireless interface). On
FortiWiFi units, you can configure the device to be either an access point, or a wireless
client. As an access point, the FortiWiFi unit can have up to four separate SSIDs, each on
their own subnet for wireless access. In client mode, the FortiWiFi only has one SSID, and
is used as a receiver, to enable remote users to connect to the existing network using
wireless protocols.
Wireless interfaces also require additional security measures to ensure the signal does
not get hijacked and data tampered or stolen.
Aggregate
Link aggregation (IEEE 802.3ad) enables you to bind two or more physical interfaces
together to form an aggregated (combined) link. This new link has the bandwidth of all the
links combined. If a link in the group fails, traffic is transferred automatically to the
remaining interfaces with the only noticeable effect being a reduced bandwidth.
This is similar to redundant interfaces with the major difference being that a redundant
interface group only uses one link at a time, where an aggregate link group uses the total
bandwidth of the functioning links in the group, up to eight.
Support of the IEEE standard 802.3ad for link aggregation is available on some models.
An interface is available to be an aggregate interface if:
•
it is a physical interface, not a VLAN interface or subinterface
•
it is not already part of an aggregate or redundant interface
•
it is in the same VDOM as the aggregated interface. Aggregate ports cannot span
multiple VDOMs.
•
it does not have a IP address and is not configured for DHCP or PPPoE
•
it is not referenced in any firewall policy, VIP, IP Pool or multicast policy
•
it is not an HA heartbeat interface
•
it is not one of the FortiGate-5000 series backplane interfaces
To see if a port is being used or has other dependencies, use the following diagnose
command:
diagnose sys system.interface.name <interface_name>
When an interface is included in an aggregate interface, it is not listed on the System >
Network > Interface page. Interfaces will still appear in the CLI, although configuration for
those interfaces will not take affect. You cannot configure the interface individually and it is
not available for inclusion in firewall policies, VIPs, IP pools, or routing.
You can add an accelerated interface (FA2, NP2 interfaces) to an aggregate link, but you
will lose the acceleration. For example, if you aggregate two accelerated interfaces you
will get slower throughput than if the two interfaces were separate.
52
01-40002-112804-20101015
Firewall components
Interfaces
Example
This example creates an aggregate interface on a FortiGate-3810A using ports 4-6 with
an internal IP address of 10.13.101.100, as well as the administrative access to HTTPS
and SSH.
To create an aggregate interface - web-based manager
1 Go to System > Network > Interface and select Create New.
2 Enter the Name as Aggregate.
3 For the Type, select 802.3ad Aggregate.
If this option does not appear, your FortiGate unit does not support aggregate
interfaces.
4 In the Available Interfaces list, select port 4, 5 and 6 and move it to the Selected
Interfaces list.
7 For Administrative Access select HTTPS and SSH.
8 Select OK.
To create aggregate interface - CLI
edit Aggregate
set type aggregate
set member port4 port5 port6
set vdom root
set ip 172.20.120.100/24
end
Virtual domains
Virtual domains (VDOMs) are a method of dividing a FortiGate unit into two or more virtual
units that function as multiple independent units. A single FortiGate unit is then flexible
enough to serve multiple departments of an organization, separate organizations, or to act
as the basis for a service provider’s managed security service.
Note: Some smaller FortiGate units do not support virtual domains.
VDOMs provide separate security domains that allow separate zones, user authentication,
firewall policies, routing, and VPN configurations. By default, each FortiGate unit has a
VDOM named root. This VDOM includes all of the FortiGate physical interfaces, modem,
VLAN subinterfaces, zones, firewall policies, routing settings, and VPN settings.
When a packet enters a VDOM, it is confined to that VDOM. In a VDOM, you can create
firewall policies for connections between Virtual LAN (VLAN) subinterfaces or zones in the
VDOM. Packets do not cross the virtual domain border internally. To travel between
VDOMs, a packet must pass through a firewall on a physical interface. The packet then
arrives at another VDOM on a different interface, but it must pass through another firewall
before entering the VDOM. Both VDOMs are on the same FortiGate unit. Inter-VDOMs
change this behavior in that they are internal interfaces; however their packets go through
all the same security measures as on physical interfaces.
01-40002-112804-20101015
53
Interfaces
Firewall components
Example
This example shows how to enable VDOMs on the FortiGate unit and the basic and create
a VDOM accounting on the DMZ2 port and assign an administrator to maintain the VDOM.
First enable Virtual Domains on the FortiGate unit. When you enable VODMs, the
FortiGate unit will log you out.
To enable VDOMs - web-based manager
1 Go to System > Dashboard > Status.
2 In the System Information widget, select Enable for Virtual Domain.
The FortiGate unit logs you out. Once you log back in, you will notice that the menu
structure has changed. This reflects the global settings for all Virtual Domains.
To enable VDOMs - CLI
config system global
set vdom-admin enable
end
Next, add the VDOM called accounting.
To add a VDOM - web-based manager
1 Go to System > VDOM > VDOM, and select Create New.
2 Enter the VDOM name accounting.
3 Select OK.
To add a VDOM - CLI
config vdom
edit <new_vdom_name>
end
With the Virtual Domain created, you can assign a physical interface to it, and assign it an
IP address.
To assign physical interface to the accounting Virtual Domain - web-based manager
2 Select the DMZ2 port row and select Edit.
3 For the Virtual Domain drop-down list, select accounting.
6 Set the Administrative Access to HTTPS and SSH.
7 Select OK.
To assign physical interface to the accounting Virtual Domain - CLI
config global
edit dmz2
set vdom accounting
set ip 10.13.101.100/24
next
end
54
01-40002-112804-20101015
Firewall components
Interfaces
Virtual LANs
The term VLAN subinterface correctly implies the VLAN interface is not a complete
interface by itself. You add a VLAN subinterface to the physical interface that receives
VLAN-tagged packets. The physical interface can belong to a different VDOM than the
VLAN, but it must be connected to a network route that is configured for this VLAN.
Without that route, the VLAN will not be connected to the network, and VLAN traffic will not
be able to access this interface.The traffic on the VLAN is separate from any other traffic
on the physical interface.
FortiGate unit interfaces cannot have overlapping IP addresses—the IP addresses of all
interfaces must be on different subnets. This rule applies to both physical interfaces and to
virtual interfaces such as VLAN subinterfaces. Each VLAN subinterface must be
configured with its own IP address and netmask. This rule helps prevent a broadcast
storm or other similar network problems.
Any FortiGate unit, with or without VDOMs enabled, can have a maximum of 255
interfaces in Transparent operating mode. In NAT/Route operating mode, the number can
range from 255 to 8192 interfaces per VDOM, depending on the FortiGate model. These
numbers include VLANs, other virtual interfaces, and physical interfaces. To have more
than 255 interfaces configured in Transparent operating mode, you need to configure
multiple VDOMs with many interfaces on each VDOM.
Example
This example shows how to add a VLAN, vlan_accounting on the FortiGate unit internal
interface with an IP address of 10.13.101.101.
To add a VLAN - web-based manager
1 Go to System > Network > Interface and select Create New.
The Type is by default set to VLAN.
2 Enter a name for the VLAN to vlan_accounting.
3 Select the Internal interface.
4 Enter the VLAN ID.
The VLAN ID is a number between 1 and 4094 that allow groups of IP addresses with
the same VLAN ID to be associated together.
7 Set the Administrative Access to HTTPS and SSH.
8 Select OK.
To add a VLAN - CLI
edit VLAN_1
set interface internal
set type vlan
set vlanid 100
set ip 10.13.101.101/24
next
end
01-40002-112804-20101015
55
Interfaces
Firewall components
Zones
Zones are a group of one or more FortiGate interfaces, both physical and virtual, that you
can apply firewall policies to control inbound and outbound traffic. Grouping interfaces and
VLAN subinterfaces into zones simplifies the creation of firewall policies where a number
of network segments can use the same policy settings and protection profiles. When you
add a zone, you select the names of the interfaces and VLAN subinterfaces to add to the
zone.
For example, in the illustration below, the network includes three separate groups of users
representing different entities on the company network. While each group has its own set
of port and VLANs, in each area, they can all use the same firewall policy and protection
profiles to access the Internet. Rather than the administrator making nine separate firewall
policies, he can add the required interfaces to a zone, and create three policies, making
administration simpler.
Figure 17: Network zones
Zone 1 policies
Zo
Zone 3
ne
2p
oli
cie
Zone 1
WAN1, DMZ1,
VLAN 1, 2, 4
s
policies
Zone 2
Internal
ports 1, 2, 3
Zone 3
WAN2, DMZ2,
VLAN 3
You can configure policies for connections to and from a zone, but not between interfaces
in a zone. Using the above example, you can create a firewall policy to go between zone 1
and zone 3, but not between WAN2 and WAN1, or WAN1 and DMZ1.
Example
This example explains how to set up a zone on the FortiGate unit to include the Internal
interface and a VLAN.
To create a zone - web-based manager
1 Go to System > Network > Zone, and select Create New.
2 Enter a zone name of Zone_1.
56
01-40002-112804-20101015
Firewall components
Addressing
3 Select the Internal interface and the virtual LAN interface vlan_accounting from the
previous section.
4 Select OK.
To create a zone - CLI
config system zone
edit Zone_1
set interface internal VLAN_1
end
Addressing
Firewall addresses and address groups define network addresses that you can use when
configuring a firewall policies’ source and destination address fields. The FortiGate unit
compares the IP addresses contained in packet headers with firewall policy source and
destination addresses to determine if the firewall policy matches the traffic. Addressing in
firewall policies can be IPv4 addresses and address ranges, IPv6 addresses, and fully
qualified domain names (FQDNs).
A firewall address can contain one or more network addresses. Network addresses can
be represented by an IP address with a netmask, an IP address range, or a fully qualified
domain name (FQDN).
When representing hosts by an IP address with a netmask, the IP address can represent
one or more hosts. For example, a firewall address can be:
•
a single computer, such as 192.45.46.45
•
a subnetwork, such as 192.168.1.0 for a class C subnet
•
0.0.0.0, which matches any IP address
The netmask corresponds to the subnet class of the address being added, and can be
represented in either dotted decimal or CIDR format. The FortiGate unit automatically
converts CIDR formatted netmasks to dotted decimal format. Example formats:
•
netmask for a single computer: 255.255.255.255, or /32
•
netmask for a class A subnet: 255.0.0.0, or /8
•
netmask for a class B subnet: 255.255.0.0, or /16
•
netmask for a class C subnet: 255.255.255.0, or /24
•
netmask including all IP addresses: 0.0.0.0
Valid IP address and netmask formats include:
•
x.x.x.x/x.x.x.x, such as 192.168.1.0/255.255.255.0
•
x.x.x.x/x, such as 192.168.1.0/24
Note: An IP address 0.0.0.0 with netmask 255.255.255.255 is not a valid firewall
address.
When representing hosts by an IP Range, the range indicates hosts with continuous IP
addresses in a subnet, such as 192.168.1.[2-10], or 192.168.1.* to indicate the
complete range of hosts on that subnet. Valid IP Range formats include:
•
x.x.x.x-x.x.x.x, such as 192.168.110.100-192.168.110.120
•
x.x.x.[x-x], such as 192.168.110.[100-120]
01-40002-112804-20101015
57
Addressing
Firewall components
•
x.x.x.*, such as 192.168.110.*
When representing hosts by a FQDN, the domain name can be a subdomain, such as
mail.example.com. A single FQDN firewall address may be used to apply a firewall policy
to multiple hosts, as in load balancing and high availability (HA) configurations. FortiGate
units automatically resolve and maintain a record of all addresses to which the FQDN
resolves. Valid FQDN formats include:
•
<host_name>.<second_level_domain_name>.<top_level_domain_name>, such as
mail.example.com
•
<host_name>.<top_level_domain_name>
Caution: Be cautious when employing FQDN firewall addresses. Using a fully qualified
domain name in a firewall policy, while convenient, does present some security risks,
because policy matching then relies on a trusted DNS server. Should the DNS server be
compromised, firewall policies requiring domain name resolution may no longer function
properly.
Example
This example adds an IPv4 firewall address for guest users of 10.13.101.100 address the
port1 interface.
To add a firewall IP address to the port1 interface - web-based manager
1 Go to Firewall > Address > Address and select Create New.
2 For the Address Name, enter Guest.
3 Leave the Type as Subnet/IP Range.
4 Enter the IP address of 10.13.101.100/24.
5 For the Interface, select port1.
6 Select OK.
To add a firewall IP address to the port1 interface- CLI
edit Guest
set type ipmask
set subnet 10.13.101.100/24
set associated-interface port1
end
Example
This example adds an IPv4 firewall address range for guest users with the range of
10.13.101.100 to 10.13.101.110 addresses on any interface. By setting the interface to
Any, the address range is not bound to a specific interface on the FortiGate unit.
To add a firewall IP address to the port1 interface - web-based manager
3 Leave the Type as Subnet/IP Range.
4 Enter the IP address range of 10.13.101.[100-110].
5 For the Interface, select Any.
6 Select OK.
58
01-40002-112804-20101015
Firewall components
Addressing
To add a firewall IP address to the port1 interface - CLI
edit Guest
set type iprange
set start-ip 10.13.101.100
set end-ip 10.13.101.110
end
Wildcard firewall addresses
You can use wildcard firewall addresses to identify ranges of IP addresses, allowing you to
reduce the number of firewall addresses and policies required to match some of the traffic
on your network.
Wildcard firewall addresses are an advanced feature usually only required for more
complex networks with complex firewall filtering requirements. For example, a network
may have multiple class C subnets (such as 192,168.1.0, 192.168.2.0, 192.168.3.0 and so
on) and may require the same firewall policy for similar addresses on each of these
subnets. To do this you could create multiple firewall addresses for each of the subnets
and then group these firewall addresses into address groups and then add the address
groups to firewall policies. Or, you could create a wildcard firewall address that matches
multiple addresses on multiple subnets and add this single address to a firewall policy.
A wildcard firewall address consists of an IP address and a wildcard netmask (for
example, 192.168.0.56 255.255.0.255). In this example the IP address is 192.168.0.56
and the wildcard netmask is 255.255.0.255. The IP address defines the networks to match
and the wildcard netmask defines the specific addresses to match on these networks.
In a wildcard netmask, 0 means ignore the value of the octet in the IP address, which
means the wildcard firewall address matches any number in this address octet. This also
means that the number included in this octet of IP address is ignored and can be any
number. Usually if the octet in the wildcard netmask is 0 the corresponding octet in the IP
address is also 0.
In a wildcard netmask, a number means match addresses according to how the numbers
translate into binary addresses. For example, if the wildcard netmask is 255 the wildcard
firewall address will only match addresses with the value for this octet that is in the IP
address part of the wildcard address. For example, if the first octet of the IP address is 192
and the first octet of the wildcard netmask is 255 the firewall wildcard address will only
match addresses with 192 in the first octet.
So the firewall wildcard address 192.168.0.56 255.255.0.255 would match the following IP
addresses:
192.168.0.56, 192.168.1.56, 192.168.2.56, ..., 192.168.255.56
The firewall wildcard addresses 192.168.0.56 255.255.0.255 and 192.168.1.56
255.255.0.255 define the same thing since the 0 in the wildcard mask means to match any
address in the third octet.
Also, the firewall wildcard address 172.0.20.10 255.0.255.255 would match the following
IP addresses:
172.1.20.10, 72.2.20.10, 72.3.20.10, ..., 72.255.20.10
In a wildcard netmask, a number other than 255 matches multiple addresses for this octet.
And you can perform a binary conversion to calculate the addresses that would be
matched by a given value.
01-40002-112804-20101015
59
Addressing
Firewall components
For example, to create the IP address and wildcard netmask to match the following
network addresses:
192.168.32.0/24
192.168.33.0/24
192.168.34.0/24
192.168.35.0/24
192.168.36.0/24
192.168.37.0/24
192.168.38.0/24
192.168.39.0/24
Table 5 shows how to write the third octet for these networks according to the octet bit
position and address value for each bit.
Table 5: Octet bit position and address value for each bit
Decimal
128
64
32
16
8
4
2
1
32
0
0
1
0
0
0
0
0
33
0
0
1
0
0
0
0
1
34
0
0
1
0
0
0
1
0
35
0
0
1
0
0
0
1
1
36
0
0
1
0
0
1
0
0
37
0
0
1
0
0
1
0
1
38
0
0
1
0
0
1
1
0
39
0
0
1
0
0
1
1
1
M
M
M
M
M
D
D
D
Since the first five bits match, the networks can be summarized into one network
(192.168.32.0/21 or 192.168.32.0 255.255.248.0). All eight possible combinations of the
three low-order bits are relevant for the network ranges. The firewall wildcard address that
would match all of these subnet addresses can be written as 192.168.32.0 255.255.248.0.
Note: Wildcard firewall addresses are similar to routing access list wildcard masks. You
add routing access lists containing wildcard masks using the
config router access-list command. However, router access list wildcard masks
use the inverse of the masking system used for firewall wildcard addresses. For the router
access list wildcard masks, 0 means match all IP addresses and 1 means ignore all IP
addresses. So to match IP addresses 192.168.0.56, 192.268.1.56, 192.168.2.56, ...
192.168.255.56 you would use the following router access IP address prefix and wildcard
mask: 192.168.0.56 0.0.255.0.
The following example shows how firewall wildcard addresses can be applied to network
traffic. This example consists of a firewall policy where both the source and destination
addresses are firewall wildcard addresses.
Source Address: 10.129.5.0 255.127.7.0
Destination Address: 10.129.0.10 255.127.7.255
60
01-40002-112804-20101015
Firewall components
Addressing
A firewall policy with these source and destination addresses would permit:
•
A device with IP address 10.129.5.100 to connect through the FortiGate unit to IP
address 10.129.0.10
•
address 10.129.8.10
•
address 10.129.0.10
Adding a firewall wildcard address
Wildcard firewall addresses are only configured from the CLI.
edit example_wildcard_address
set type wildcard
set wildcard 192.168.0.56 255.255.0.255
end
Fully Qualified Domain Name addresses
Using Fully Qualified Domain Name (FQDN) addresses in firewall policies has the
advantage of causing the FortiGate unit to keep track of DNS TTLs and adapt as records
change. As long as the FQDN address is used in a firewall policy, it stores the address in
the DNS cache. The FortiGate unit will query the DNS for an amount of time specified, in
seconds, and update the cache as required. This feature can reduce maintenance
requirements for changing firewall addresses for dynamic IP addresses. This also means
that you can create firewall policies for networks configured with dynamic addresses using
DHCP.
Caution: Be cautious when employing FQDN firewall addresses. Using a fully qualified
domain name in a firewall policy, while convenient, does present some security risks,
because policy matching then relies on a trusted DNS server. Should the DNS server be
compromised, firewall policies requiring domain name resolution may no longer function
properly.
You specify the TTL time in the CLI only. For example, to set the TTL for 30 minutes on an
FQDN of www.example.com on port 1, enter the following commands:
edit FQDN_example
set type fdqn
set associated-interface port 1
set fqdn www.example.com
set cache-ttl 1800
end
Virtual IPs
Virtual IP addresses (VIPs) can be used when configuring firewall policies to translate IP
addresses and ports of packets received by a network interface. When the FortiGate unit
receives inbound packets matching a firewall policy whose Destination Address field is a
virtual IP, the FortiGate unit applies NAT, replacing packets’ IP addresses with the virtual
IP’s mapped IP address.
01-40002-112804-20101015
61
Addressing
Firewall components
IP pools, similarly to virtual IPs, can be used to configure aspects of NAT; however, IP
pools configure dynamic translation of packets’ IP addresses based on the Destination
Interface/Zone, whereas virtual IPs configure dynamic or static translation of a packets’ IP
addresses based upon the Source Interface/Zone.
To implement the translation configured in the virtual IP or IP pool, you must add it to a
NAT firewall policy.
Note: In Transparent mode, from the CLI, you can configure NAT firewall policies that
include Virtual IPs and IP pools. For more information, see the System Administration
Guide.
Virtual IPs can specify translations of packets’ port numbers and/or IP addresses for both
inbound and outbound connections. In Transparent mode, virtual IPs are available from
the FortiGate CLI.
Example
This example adds a virtual IP of 10.13.100.1 that allows users on the Internet to connect
to a web server on the DMZ IP address of 192.168.1.1. In the example, the wan1 interface
of the FortiGate unit is connected to the Internet and the dmz1 interface is connected to
the DMZ network.
To add a static NAT virtual IP for a single IP address - web-based manager
1 Go to Firewall > Virtual IP > Virtual IP and select Create New.
2 For the Name, enter Static_NAT.
3 Select the External interface of wan1
4 Enter the External IP Address of 10.13.100.1.
5 Enter the Mapped IP Address of 192.168.1.1.
6 Select OK.
To add a static NAT virtual IP for a single IP address - CLI
config firewall vip
edit Static_NAT
set extintf wan1
set extip 10.13.100.1
set mappedip 192.168.1.1
end
Inbound connections
Virtual IPs can be used in conjunction with firewall policies whose Action is not DENY to
apply bidirectional NAT, also known as inbound NAT.
When comparing packets with the firewall policy list to locate a matching policy, if a firewall
policy’s Destination Address is a virtual IP, FortiGate units compares packets’ destination
address to the virtual IP’s external IP address. If they match, the FortiGate unit applies the
virtual IP’s inbound NAT mapping, which specifies how the FortiGate unit translates
network addresses and/or port numbers of packets from the receiving (external) network
interface to the network interface connected to the destination (mapped) IP address or IP
address range.
62
01-40002-112804-20101015
Firewall components
Addressing
In addition to specifying IP address and port mappings between interfaces, virtual IP
configurations can optionally bind an additional IP address or IP address range to the
receiving network interface. By binding an additional IP address, you can configure a
separate set of mappings that the FortiGate unit can apply to packets whose destination
matches that bound IP address, rather than the IP address already configured for the
network interface.
Depending on your configuration of the virtual IP, its mapping may involve port address
translation (PAT), also known as port forwarding or network address port translation
(NAPT), and/or network address translation (NAT) of IP addresses.
If you configure NAT in the virtual IP and firewall policy, the NAT behavior varies by your
selection of:
•
static vs. dynamic NAT mapping
•
the dynamic NAT’s load balancing style, if using dynamic NAT mapping
•
full NAT vs. destination NAT (DNAT)
The following table describes combinations of PAT and/or NAT that are possible when
configuring a firewall policy with a virtual IP.
Static NAT
Static, one-to-one NAT mapping: an external IP address is always translated to
the same mapped IP address.
If using IP address ranges, the external IP address range corresponds to a
mapped IP address range containing an equal number of IP addresses, and
each IP address in the external range is always translated to the same IP
address in the mapped range.
Static NAT with Static, one-to-one NAT mapping with port forwarding: an external IP address is
Port Forwarding always translated to the same mapped IP address, and an external port number
is always translated to the same mapped port number.
If using IP address ranges, the external IP address range corresponds to a
mapped IP address range containing an equal number of IP addresses, and
each IP address in the external range is always translated to the same IP
address in the mapped range. If using port number ranges, the external port
number range corresponds to a mapped port number range containing an equal
number of port numbers, and each port number in the external range is always
translated to the same port number in the mapped range.
Server Load
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.
Note: If the NAT check box is not selected when building the firewall policy, the resulting
policy does not perform full (source and destination) NAT; instead, it performs destination
network address translation (DNAT).
For inbound traffic, DNAT translates packets’ destination address to the mapped private IP
address, but does not translate the source address. The private network is aware of the
source’s public IP address. For reply traffic, the FortiGate unit translates packets’ private
network source IP address to match the destination address of the originating packets,
which is maintained in the session table.
01-40002-112804-20101015
63
Addressing
Firewall components
A typical example of static NAT is to allow client access from a public network to a web
server on a private network that is protected by a FortiGate unit. Reduced to its essence,
this example involves only three hosts, as shown in Figure 18: the web server on a private
network, the client computer on another network, such as the Internet, and the FortiGate
unit connecting the two networks.
When a client computer attempts to contact the web server, it uses the virtual IP on the
FortiGate unit’s external interface. The FortiGate unit receives the packets. The addresses
in the packets are translated to private network IP addresses, and the packet is forwarded
to the web server on the private network.
Figure 18: A simple static NAT virtual IP example
IP
r 42
ve 0.
er .1
S 10
.
10
Int
e
10 rnal
.10 IP
.10
.2
V
19 irtua
2.1 l IP
68
.37
.4
IP .55
nt 37
lie .
C 168
2.
19
The packets sent from the client computer have a source IP of 192.168.37.55 and a
destination IP of 192.168.37.4. The FortiGate unit receives these packets at its external
interface, and matches them to a firewall policy for the virtual IP. The virtual IP settings
map 192.168.37.4 to 10.10.10.42, so the FortiGate unit changes the packets’ addresses.
The source address is changed to 10.10.10.2 and the destination is changed to
10.10.10.42. The FortiGate unit makes a note of this translation in the firewall session
table it maintains internally. The packets are then sent on to the web server.
Figure 19: Example of packet address remapping during NAT from client to server
.2
.10 0.42
0
1
.
1
10 0.
IP 10.1
e
1
urc IP
3
So ation
2
n
sti
NA
De
Tw
ith
av
irtu
al
IP
1
3
2
.55
.37 37.4
8
6
.
2.1 68
19 92.1
P
e I IP 1
urc tion
o
S ina
st
De
64
01-40002-112804-20101015
Firewall components
Addressing
Note that the client computer’s address does not appear in the packets the server
receives. After the FortiGate unit translates the network addresses, there is no reference
to the client computer’s IP address, except in its session table. The web server has no
indication that another network exists. As far as the server can tell, all packets are sent by
the FortiGate unit.
When the web server replies to the client computer, address translation works similarly,
but in the opposite direction. The web server sends its response packets having a source
IP address of 10.10.10.42 and a destination IP address of 10.10.10.2. The FortiGate unit
receives these packets on its internal interface. This time, however, the session table is
used to recall the client computer’s IP address as the destination address for the address
translation. In the reply packets, the source address is changed to 192.168.37.4 and the
destination is changed to 192.168.37.55. The packets are then sent on to the client
computer.
The web server’s private IP address does not appear in the packets the client receives.
After the FortiGate unit translates the network addresses, there is no reference to the web
server’s network. The client has no indication that the web server’s IP address is not the
virtual IP. As far as the client is concerned, the FortiGate unit’s virtual IP is the web server.
Figure 20: Example of packet address remapping during NAT from server to client
.42
.10 10.2
0
.
.1
10 .10
IP P 10 1
e
I
urc n
3
So inatio
2
t
s
De
NA
T
wit
ha
vir
tua
l IP
1
3
2
.4
.37 7.55
8
6 3
2.1 8.
19 2.16
P
e I 19
urc on IP
o
S ati
n
sti
e
D
In the previous example, the NAT check box is checked when configuring the firewall
policy. If the NAT check box is not selected when building the firewall policy, the resulting
policy does not perform full NAT; instead, it performs destination network address
translation (DNAT).
For inbound traffic, DNAT translates packets’ destination address to the mapped private IP
address, but does not translate the source address. The web server would be aware of
the client’s IP address. For reply traffic, the FortiGate unit translates packets’ private
network source IP address to match the destination address of the originating packets,
which is maintained in the session table.
01-40002-112804-20101015
65
Addressing
Firewall components
Outbound connections
Virtual IPs can also affect outbound NAT, even though they are not selected in an
outbound firewall policy. If no virtual IPs are configured, FortiGate units apply traditional
outbound NAT to connections outbound from private network IP addresses to public
network IP addresses. However, if virtual IP configurations exist, FortiGate units use
virtual IPs’ inbound NAT mappings in reverse to apply outbound NAT, causing IP address
mappings for both inbound and outbound traffic to be symmetric.
For example, if a network interface’s IP address is 10.10.10.1, and its bound virtual IP’s
external IP is 10.10.10.2, mapping inbound traffic to the private network IP address
192.168.2.1, traffic outbound from 192.168.2.1 will be translated to 10.10.10.2, not
10.10.10.1.
Note: A virtual IP setting with port forwarding enabled does not translate the
source address of outbound traffic. If both virtual IP (without port forwarding) and
IP Pools are enabled, IP Pools is preferred for source address translation of
outbound traffic.
Virtual IP, load balance virtual server / real server limitations
The following limitations apply when adding virtual IPs, load balancing virtual servers, and
load balancing real servers. Load balancing virtual servers are actually server load
balancing virtual IPs. You can add server load balance virtual IPs from the CLI.
•
Virtual IP External IP Address/Range entries or ranges cannot overlap with each
other or with load balancing virtual server Virtual Server IP entries.
•
A virtual IP Mapped IP Address/Range cannot be 0.0.0.0 or 255.255.255.255.
•
A real server IP cannot be 0.0.0.0 or 255.255.255.255.
•
If a static NAT virtual IP External IP Address/Range is 0.0.0.0, the Mapped IP
Address/Range must be a single IP address.
•
If a load balance virtual IP External IP Address/Range is 0.0.0.0, the Mapped IP
Address/Range can be an address range.
•
When port forwarding, the count of mapped port numbers and external port
numbers must be the same. The web-based manager does this automatically but
the CLI does not.
Virtual IP and virtual server names must be different from firewall address or address
group names.
Address groups
Similar to zones, if you have a number of addresses or address ranges that require the
same firewall policies, you can put them into address groups, rather than creating multiple
similar policies. Because firewall policies require addresses with homogenous network
interfaces, address groups should contain only addresses bound to the same network
interface, or to Any — addresses whose selected interface is Any are bound to a network
interface during creation of a firewall policy, rather than during creation of the firewall
address.
For example, if address 1.1.1.1 is associated with port1, and address 2.2.2.2 is associated
with port2, they cannot be in the same group. However, if 1.1.1.1 and 2.2.2.2 are
configured with an interface of Any, they can be grouped, even if the addresses involve
different networks.
You cannot mix IPv4 firewall addresses and IPv6 firewall addresses in the same address
group.
66
01-40002-112804-20101015
Firewall components
Addressing
Example
This example creates an address group accounting, where addresses for User_1 and
User_2 have port association of Any. It is recommended to add the addresses you want to
add to the group before setting up the address group.
Setup
To create an address group - web-based manager
1 Go to Firewall > Address > Group, and select Create New.
2 Enter the Group Name of accounting.
3 From the Available Addresses list, select an address and select the down-arrow button
to move the address name to the Members list.
4 Repeat step three as many times as required. You can also hold the SHIFT key to
select a range of address names from the list.
5 Select OK.
To create an address group - CLI
config firewall addrgrp
edit accounting
set member User_1
set member User_2
end
DHCP
The Dynamic Host Configuration Protocol (DHCP) enables hosts to automatically obtain
an IP address from a DHCP server. Optionally, hosts can also obtain default gateway and
DNS server settings.
Note: DHCP is not available when the FortiGate unit is operating in Transparent mode.
On FortiGate 30B, 50 and 60 series units, a DHCP server is configured, by default, on the
Internal interface, as follows:
IP Range
192.168.1.110 to 192.168.1.210
Netmask
255.255.255.0
Default gateway
192.168.1.99
Lease time
7 days
DNS Server 1
192.168.1.99
A FortiGate interface can provide the following DHCP services:
•
Basic DHCP servers
•
IPSec DHCP servers for IPSec (VPN) connections
•
DHCP relay for regular Ethernet or IPSec (VPN) connections
An interface cannot provide both a server and a relay for connections of the same type.
01-40002-112804-20101015
67
Addressing
Firewall components
You can configure one or more DHCP servers on any FortiGate interface. A DHCP server
dynamically assigns IP addresses to hosts on the network connected to the interface. The
host computers must be configured to obtain their IP addresses using DHCP. The IP
range of each DHCP server must match the network address range. The routers must be
configured for DHCP relay.
Example
This example sets up a DHCP server on the Internal interface for guests with an IP range
of 10.13.101.100 to 10.13.101.110, a default gateway of 10.13.101.2 and address lease of
5 days.
To configure a DHCP server on the internal interface - web-based manager
1 Go to System > DHCP Server > Service.
2 For the internal interface, select the ‘plus’ sign for Servers and complete the following:
Name
Guest DHCP
Type
Regular
IP Range
10.13.101.100
10.13.101.110
Netmask
255.255.255.0
Default Gateway
10.13.101.2
Lease
5 days
3 Select OK.
To configure a DHCP server on the internal interface - CLI
config system dhcp server
edit guest_dhcp
set server-type regular
set interface internal
set start-ip 10.13.101.100
set end-ip 10.13.101.105
set netmask 255.255.255.0
set default-gateway 10.13.101.2
set lease-time 432000
end
A FortiGate interface can also be configured as a DHCP relay. The interface forwards
DHCP requests from DHCP clients to an external DHCP server and returns the responses
to the DHCP clients. The DHCP server must have appropriate routing so that its response
packets to the DHCP clients arrive at the FortiGate unit.
Example
This example sets up a DHCP relay on the internal interface from the DHCP server
located at 172.20.120.55. The FortiGate unit will send a request for an IP address from the
defined DHCP server and forward it to the requesting connection.
To configure a DHCP relay on the internal interface - web-based manager
1 Go to System > DHCP Server > Service.
2 Select the internal interface and select Edit for the Relay option.
3 Select Enable for the DHCP Relay Agent.
68
01-40002-112804-20101015
Firewall components
Addressing
4 Select the Type of Regular.
5 Enter the DHCP Server IP address of 172.20.120.55.
6 Select OK.
To configure a DHCP server on the internal interface - CLI
edit internal
set dhcp-relay-service enable
set dhcp-relay-type regular
set dhcp-relay-ip 172.20.120.55
end
IP pools
An IP pool defines a single IP address or a range of IP addresses. A single IP address in
an IP pool becomes a range of one IP address. For example, if you enter an IP pool as
1.1.1.1, the IP pool is actually the address range, 1.1.1.1 to 1.1.1.1. Use IP pools to add
NAT policies that translate source addresses to addresses randomly selected from the IP
pool, rather than the IP address assigned to that FortiGate interface.
If a FortiGate interface IP address overlaps with one or more IP pool address ranges, the
interface responds to ARP requests for all of the IP addresses in the overlapping IP pools.
For example, consider a FortiGate unit with the following IP addresses for the port1 and
port2 interfaces:
•
port1 IP address: 1.1.1.1/255.255.255.0 (range is 1.1.1.0-1.1.1.255)
•
port2 IP address: 2.2.2.2/255.255.255.0 (range is 2.2.2.0-2.2.2.255)
And the following IP pools:
•
IP_pool_1: 1.1.1.10-1.1.1.20
•
IP_pool_2: 2.2.2.10-2.2.2.20
•
IP_pool_3: 2.2.2.30-2.2.2.40
The port1 interface overlap IP range with IP_pool_1 is:
•
(1.1.1.0-1.1.1.255) and (1.1.1.10-1.1.1.20) = 1.1.1.10-1.1.1.20
•
(2.2.2.0-2.2.2.255) & (2.2.2.10-2.2.2.20) = 2.2.2.10-2.2.2.20
•
(2.2.2.0-2.2.2.255) & (2.2.2.30-2.2.2.40) = 2.2.2.30-2.2.2.40
And the result is:
•
The port1 interface answers ARP requests for 1.1.1.10-1.1.1.20
•
The port2 interface answers ARP requests for 2.2.2.10-2.2.2.20 and for 2.2.2.302.2.2.40
Select NAT in a firewall policy and then select Dynamic IP Pool. Select an IP pool to
translate the source address of packets leaving the FortiGate unit to an address randomly
selected from the IP pool.
01-40002-112804-20101015
69
Addressing
Firewall components
Example
This example sets up an IP Pool with an address range of 10.13.101.100 to 10.13.101.110
for guest accounts on the network.
To configure an IP Pool - web-based manager
1 Go to Firewall > Virtual IP > IP Pool and select Create New.
2 Enter the Name of Guest.
3 Enter the IP Range/Subnet of 10.13.101.100-10.13.101.110.
4 Select OK.
To configure an IP Pool - CLI
config firewall ippool
edit Guest
set startip 10.13.101.100
set endip 10.13.101.110
end
IP Pools for firewall policies that use fixed ports
Some network configurations do not operate correctly if a NAT policy translates the source
port of packets used by the connection. NAT translates source ports to keep track of
connections for a particular service.
From the CLI you can enable fixedport when configuring a firewall policy for NAT
policies to prevent source port translation.
config firewall policy
edit policy_name
...
set fixedport enable
...
end
However, enabling fixedport means that only one connection can be supported
through the firewall for this service. To be able to support multiple connections, add an IP
pool, and then select Dynamic IP pool in the policy. The firewall randomly selects an IP
address from the IP pool and assigns it to each connection. In this case, the number of
connections that the firewall can support is limited by the number of IP addresses in the IP
pool.
Source IP address and IP pool address matching
When the source addresses are translated to the IP pool addresses, one of the following
three cases may occur:
Scenario 1: The number of source addresses equals that of IP pool addresses
In this case, the FortiGate unit always matches the IP addressed one to one. If you enable
fixedport in such a case, the FortiGate unit preserves the original source port.
70
01-40002-112804-20101015
Firewall components
Addressing
This may cause conflicts if more than one firewall policy uses the same IP pool, or the
same IP addresses are used in more than one IP pool.
Original address
Change to
192.168.1.1
172.16.30.1
192.168.1.2
172.16.30.2
......
......
192.168.1.254
172.16.30.254
Scenario 2: The number of source addresses is more than that of IP pool addresses
In this case, the FortiGate unit translates IP addresses using a wrap-around mechanism.
If you enable fixedport in such a case, the FortiGate unit preserves the original source
port. But conflicts may occur since users may have different sessions using the same TCP
5 tuples.
Original address
Change to
192.168.1.1
172.16.30.10
192.168.1.2
172.16.30.11
......
......
192.168.1.10
172.16.30.19
192.168.1.11
172.16.30.10
192.168.1.12
172.16.30.11
192.168.1.13
172.16.30.12
......
......
Scenario 3: The number of source addresses is fewer than that of IP pool addresses
In this case, some of the IP pool addresses are used and the rest of them are not be used.
Original address
Change to
192.168.1.1
172.16.30.10
192.168.1.2
172.16.30.11
192.168.1.3
172.16.30.12
No more source addresses
172.16.30.13 and other addresses are not used
IPv6
Internet Protocol version 6 (IPv6) is the next-generation version of IP addressing, to
eventually replace IPv4. IPv6 was developed because there is a concern that in the near
future, the available addresses for the IPv4 infrastructure will be exhausted. The IPv6
infrastructure will supplement, and eventually, replace the IPv4 standard.
Where IPv4 uses 32 bit addressing, IPv6 uses 128 bit addressing, effectively providing
trillions upon trillions of unique addresses, whereas IPv4 can have a a little over 4 billion.
With this larger address space, allocating addresses and routing traffic becomes easier,
and network address translation (NAT) becomes virtually unnecessary.
Where IPv4 addresses are written numerals separated by a decimal, the IPv6 address is
written with hexadecimal digits separated by a colon. For example,
fe80:218:8bff:fe84:4223.
01-40002-112804-20101015
71
Addressing
Firewall components
By default, the FortiGate unit is not enabled to use IPv6 addressing. To enable this
feature, go to System > Admin > Settings and select IPv6 Support on GUI. When enabled
you can use IPv6 addressing on any of the address-dependant components of the
FortiGate unit, including firewall policies, interface addressing, DNS servers. IPv6
addressing can be configured on the web-based manager and in the CLI.
For further information on IPV6 in FortiOS, see IPV6 in the System Administration Guide.
Example
This example adds an IPv6 address 2001:db8:0:1234:0:567:1:1 for the WAN1 interface as
well as the administrative access to HTTPS and SSH. As a good practice, set the
administrative access when you are setting the IP address for the port.
To add an IP address for the WAN1 interface - web-based manager
2 Select WAN1 row and select Edit.
4 Enter the IPv6 Address of 2001:db8:0:1234:0:567:1:1.
5 For Administrative Access select HTTPS and SSH.
6 Select OK.
To create IP address for the WAN1 interface - CLI
edit wan1
config ipv6
set ip6-address 2001:db8:0:1234:0:567:1:1
set ip6-allowaccess https ssh
end
end
Example
This example adds an IPv6 firewall address for guest users of 2001:db8:0:1234:0:567:1:1.
To add a firewall IPv6 address - web-based manager
1 Go to Firewall > Address > Address.
2 On the Create New button, click the down arrow on the right.
If there is no arrow, ensure you have enabled IPv6 by going to System > Admin >
Settings and select IPv6 Support on GUI.
3 Select IPv6 Address.
5 Enter the IP address of 2001:db8:0:1234:0:567:1:1/128.
6 Select OK.
To add a firewall IPv6 address - CLI
config firewall address6
edit Guest
set ip6 2001:db8:0:1234:0:567:1:1/128
end
72
01-40002-112804-20101015
Firewall components
Routing
Routing
A route provides the FortiGate unit with the information it needs to forward a packet to a
particular destination on the network. A static route causes packets to be forwarded to a
destination other than the default gateway. You define static routes manually. Static routes
control traffic exiting the FortiGate unit. You can specify through which interface the packet
will leave and to which device the packet should be routed.
As a security device on the network, packets must pass through the FortiGate unit. You
need to understand a number of basic routing concepts to configure the FortiGate unit
appropriately.
The routing table
By default, the FortiOS routing table contains a single static default route. You can add
routing information to the routing table by defining additional static routes. The table may
include several different routes to the same destination. The IP addresses of the next-hop
router specified in those routes, or the FortiGate unit interfaces associated with those
routes, may vary.
The FortiGate unit selects the “best” route for a packet by evaluating the information in the
routing table. The best route to a destination is typically associated with the shortest
distance between the FortiGate unit and the closest next-hop router. In some cases, the
next best route may be selected if the best route is unavailable. The FortiGate unit installs
the best available routes in the unit’s forwarding table, which is a subset of the unit’s
routing table. Packets are forwarded according to the information in the forwarding table.
How routing decisions are made
Whenever a packet arrives at one of the FortiGate unit’s interfaces, the FortiGate unit
determines whether the packet was received on a legitimate interface by doing a reverse
lookup using the source IP address in the packet header. If the FortiGate unit cannot
communicate with the computer at the source IP address through the interface on which
the packet was received, the FortiGate unit drops the packet as it is likely a hacking
attempt.
If the destination address can be matched to a local address, and the local configuration
permits delivery, the FortiGate unit delivers the packet to the local network. If the packet is
destined for another network, the FortiGate unit forwards the packet to a next-hop router
according to a policy route and the information stored in the forwarding table.
Multipath routing and determining the best route
Multipath routing occurs when more than one entry to the same destination is present in
the routing table. When multipath routing occurs, the FortiGate unit may have several
possible destinations for an incoming packet, forcing the FortiGate unit to decide which
next-hop is the best one.
Two methods to manually resolve multiple routes to the same destination are to lower the
administrative distance of one route or to set the priority of both routes. For the FortiGate
unit to select a primary (preferred) route, manually lower the administrative distance
associated with one of the possible routes.
Administrative distance is based on the expected reliability of a given route. It is
determined through a combination of the number of hops from the source and the protocol
used. More hops from the source means more possible points of failure. The
administrative distance can be from 1 to 255, with lower numbers being preferred. A
distance of 255 is seen as infinite and will not be installed in the routing table. For
01-40002-112804-20101015
73
Routing
Firewall components
example, if there are two possible routes traffic can take between 2 destinations with
administration distances of 5 (always up) and 31 (sometimes not available), the traffic will
use the route with an administrative distance of 5. Different routing protocols have different
default administrative distances. The default administrative distances for any of these
routing protocols are configurable.
Another method is to manually change the priority of both of the routes. If the next-hop
administrative distances of two routes on the FortiGate unit are equal, it may not be clear
which route the packet will take. Configuring the priority for each of those routes will make
it clear which next-hop will be used in the case of a tie. You can set the priority for a route
only from the CLI. Lower priorities are preferred. For more information, see the FortiGate
CLI Reference.
All entries in the routing table are associated with an administrative distance. If the routing
table contains several entries that point to the same destination (the entries may have
different gateways or interface associations), the FortiGate unit compares the
administrative distances of those entries, selects the entries having the lowest distances,
and adds them as routes in the FortiGate forwarding table. As a result, the FortiGate
forwarding table contains only those routes having the lowest distances to every possible
destination.
Route priority
After the FortiGate unit selects static routes for the forwarding table based on their
administrative distances, the priority field of those routes determines routing preference.
You configure the priority through the CLI. The route with the lowest value in the priority
field is considered the best route, and it is also the primary route. The command to set the
priority field is: set priority <integer> under the config route static
command. For more information, see the FortiGate CLI Reference.
In summary, because you can use the CLI to specify which sequence numbers or priority
field settings to use when defining static routes, you can prioritize routes to the same
destination according to their priority field settings. For a static route to be the preferred
route, you must create the route using the config router static CLI command and
specify a low priority for the route. If two routes have the same administrative distance and
the same priority, then they are equal cost multipath (ECMP) routes.
Static route
You configure static routes by defining the destination IP address and netmask of packets
that you intend the FortiGate unit to intercept, and by specifying a gateway IP address for
those packets. The gateway address specifies the next-hop router to which traffic will be
routed. When you add a static route to the Static Route list, the FortiGate unit performs a
check to determine whether a matching route and destination already exist in the
FortiGate routing table. If no match is found, the FortiGate unit adds the route to the
routing table.
Default route and default gateway
In the default configuration, entry number 1 in the static route list is associated with a
destination address of 0.0.0.0/0.0.0.0, which means any/all destinations. This route is
called the “static default route”. If no other routes are present in the routing table and a
packet needs to be forwarded beyond the FortiGate unit, the factory configured static
default route causes the FortiGate unit to forward the packet to the default gateway.
74
01-40002-112804-20101015
Firewall components
Routing
To prevent this you must either edit the factory configured static default route to specify a
different default gateway for the FortiGate unit, or delete the factory configured route and
specify your own static default route that points to the default gateway for the FortiGate
unit.
For example, Figure 21 shows a FortiGate unit connected to a router. To ensure that all
outbound packets destined to any network beyond the router are routed to the correct
destination, you must edit the default configuration and make the router the default
gateway for the FortiGate unit.
Figure 21: Making a router the default gateway
Ga
te
Ro way
ute
r
19
2.
16
8.
10
ex
.1
ter
na
l
int
ern
a
l
k
or 4
tw /2
ne 0.0
al .2
rn 8
te 16
In 2.
19
To route outbound packets from the internal network to destinations that are not on
network 192.168.20.0/24, you need to edit the default route by going to Router > Static >
Static Route, select Edit for the default route and include the following settings:
Destination IP/mask: 0.0.0.0/0.0.0.0
Gateway: 192.168.10.1
Device: The interface connected to network 192.168.10.0/24, for example “external”.
Distance: 10
The Gateway setting specifies the IP address of the next-hop router interface to the
FortiGate external interface. The interface behind the router (192.168.10.1) is the default
gateway for the FortiGate unit.
In some cases, there may be routers behind the FortiGate unit. If the destination IP
address of a packet is not on the local network but is on a network behind one of those
routers, the FortiGate routing table must include a static route to that network. For
example, in Figure 22, the FortiGate unit must be configured with static routes to
interfaces 192.168.10.1 and 192.168.11.1 in order to forward packets to Network_1 and
Network_2 respectively.
01-40002-112804-20101015
75
Routing
Firewall components
Figure 22: Destinations on networks behind internal routers
2 4
k_ 0/2
or .
w 30
et 8.
N 16
2.
19
ay
ew
Gat ter_1
Rou
19 In
2. te
16 rn
8. a l
10
.1
19
2. DM
16 Z
8.
11
.1
ay
ew
Gat ter_2
Rou
1 4
k_ 0/2
or .
w 20
et 8.
N 16
2.
19
To route packets from Network_1 to Network_2, Router_1 must be configured to use the
FortiGate internal interface as its default gateway. On the FortiGate unit, you would create
a new static route with these settings:
Destination IP/mask: 192.168.30.0/24
Gateway: 192.168.11.1
Device: dmz
Distance: 10
To route packets from Network_2 to Network_1, Router_2 must be configured to use the
FortiGate dmz interface as its default gateway. On the FortiGate unit, you would create a
new static route with these settings:
Destination IP/mask: 192.168.20.0/24
Gateway: 192.168.10.1
Device: internal
Distance: 10
Changing the gateway for the default route
The default gateway determines where packets matching the default route will be
forwarded. In this example, the gateway IP address is 192.168.21.12 on port 1 with an
administrative distance of 10.
To change the gateway for the default route - web-based manager
1 Go to Router > Static > Static Route.
2 Select the only route entry and select Edit.
3 Select the interface of port 1 from the Device list.
76
01-40002-112804-20101015
Firewall components
Routing
4 In the Gateway field, enter the IP address of 192.168.21.12.
5 In the Distance field, enter the value of 10.
6 Select OK.
To change the gateway for the default route - CLI
config router static
edit 1
set device port1
set distance 10
end
Adding a static route
A route provides the FortiGate unit with the information it needs to forward a packet to a
particular destination. A static route causes packets to be forwarded to a destination other
than the default gateway. Static routes are configured manually. Static routes control traffic
exiting the FortiGate unit. You can specify through which interface the packet will leave
and to which device the packet should be routed. For this example, the internal port
address is 172.20.120.129, the gateway of 182.168.21.12 and a distance of 10.
To add a static route - web-based manager
2 Select Create New.
3 Enter the IP address of 172.20.120.129.
4 Select the Device port of internal.
5 Enter the Gateway IP address of 192.168.21.12.
6 Enter the Distance of 10.
7 Select OK.
To add a static route - CLI
edit 2
set det 172.20.120.129
set device internal
set distance 10
end
Policy Route
A routing policy enables you to redirect traffic away from a static route. This can be useful
if you want to route certain types of network traffic differently. You can use incoming
traffic’s protocol, source address or interface, destination address, or port number to
determine where to send the traffic. For example, generally network traffic would go to the
router of a subnet, but you might want to direct SMTP or POP3 traffic addressed to that
subnet directly to the mail server.
01-40002-112804-20101015
77
Routing
Firewall components
If you have configured the FortiGate unit with routing policies and a packet arrives at the,
the FortiGate unit starts at the top of the policy route list and attempts to match the packet
with a policy. If a match is found and the policy contains enough information to route the
packet, the FortiGate unit routes the packet using the information in the policy. If no policy
route matches the packet, the FortiGate unit routes the packet using the routing table.
Note: Most policy settings are optional, so a matching policy alone might not provide
enough information for forwarding the packet. The FortiGate unit may refer to the routing
table in an attempt to match the information in the packet header with a route in the routing
table. For example, if the outgoing interface is the only item in the policy, the FortiGate unit
looks up the IP address of the next-hop router in the routing table. This situation could
happen when the interfaces are dynamic (such as DHCP or PPPoE) and you do not want
or are unable to specify the IP address of the next-hop router.
Policy route options define which attributes of a incoming packet cause policy routing to
occur. If the attributes of a packet match all the specified conditions, the FortiGate unit
routes the packet through the specified interface to the specified gateway.
To add a policy route - web-based manager
1 Go to Router > Static > Policy Route and select Create New.
2 Complete the following and select OK:
Protocol
Enter a protocol number. The Internet Protocol Number is found in the IP
packet header, and RFC 5237 includes a list of the assigned protocol
numbers. A value of 0 disables the setting.
Incoming Interface Select the name of the interface for the incoming packets.
Source Address /
Mask
Enter the source address and network mask. A value of 0.0.0.0/0.0.0.0
disables the setting.
Destination
Address / Mask
Enter the destination address and network mask. A value of
0.0.0.0/0.0.0.0 disables the setting.
Destination Ports
To perform policy routing based a port or range of ports, enter the port
numbers. A value of 0 disables this setting.
The Destination Ports fields are only used for TCP and UDP protocols.
Type of Service
Use a two digit hexadecimal bit pattern to match the service, or use a two digit
hexadecimal bit mask to mask out. For more information, see “Type of
Service” on page 79.
Outgoing Interface Select the name of the interface where packets affected by the policy will be
routed.
Gateway Address
Type the IP address of the next-hop router that the FortiGate unit can access
through the specified interface. A value of 0.0.0.0 is not valid.
To add a policy route - CLI
config router policy
edit 1
set input-device <incoming_interface>
set src <source_IP>
set dst <destination_IP>
set protocol <protocol>
set gateway <gateway_IP>
set output-device <outgoing_interface>
set tos <tos_bit_pattern>set
tos-mask <tos_bit_mask>
end
78
01-40002-112804-20101015
Firewall components
Ports
Type of Service
Type of service (TOS) is an 8-bit field in the IP header that enables you to determine how
the IP datagram should be delivered, with such qualities as delay, priority, reliability, and
minimum cost.
Each quality helps gateways determine the best way to route datagrams. A router
maintains a ToS value for each route in its routing table.The lowest priority TOS is 0, the
highest is 7 - when bits 3, 4,and 5 are all set to 1. The router tries to match the TOS of the
datagram to the TOS on one of the possible routes to the destination. If there is no match,
the datagram is sent over a zero TOS route.
Using increased quality may increase the cost of delivery because better performance
may consume limited network resources. For more information, see RFC 791 and RFC
1349.
Table 6: The role of each bit in the IP header TOS 8-bit field
bits 0, 1, 2
Precedence
Some networks treat high precedence traffic as more important
traffic. Precedence should only be used within a network, and
can be used differently in each network. Typically you do not
care about these bits.
bit 3
Delay
When set to 1, this bit indicates low delay is a priority. This is
useful for such services as VoIP where delays degrade the
quality of the sound.
bit 4
Throughput
When set to 1, this bit indicates high throughput is a priority.
This is useful for services that require lots of bandwidth such
as video conferencing.
bit 5
Reliability
When set to 1, this bit indicates high reliability is a priority. This
is useful when a service must always be available such as with
DNS servers.
bit 6
Cost
When set to 1, this bit indicates low cost is a priority. Generally
there is a higher delivery cost associated with enabling bits 3,4,
or 5, and bit 6 indicates to use the lowest cost route.
bit 7
Reserved for
future use
Not used at this time.
For example, if you want to assign low delay, and high reliability, say for a VoIP application
where delays are unacceptable, you would use a bit pattern of xxx1x1xx where an ‘x’
indicates that bit can be any value. Since all bits are not set, this is a good use for the bit
mask; if the mask is set to 0x14, it will match any TOS packets that are set to low delay
and high reliability.
For more information on ToS, see the Traffic Shaping Guide.
Ports
A port is a type of address used by specific applications and processes. The FortiGate unit
uses a number of port assignments to send and receive information for basic system
operation and communication by default.
Originating traffic
Function
Port(s)
DNS lookup; RBL lookup
UDP 53
FortiGuard Antispam or Web Filtering rating lookup
UDP 53 or UDP
8888
01-40002-112804-20101015
79
Ports
Firewall components
FDN server list
Source and destination port numbers vary by originating or reply traffic.
UDP 53 (default) or
UDP 8888, and
UDP 1027 or UDP
1031
NTP synchronization
UDP 123
SNMP traps
UDP 162
Syslog
UDP 514
All FortiOS versions can use syslog to send log messages to remote syslog
servers.
Note: If a secure connection has been configured between a FortiGate and a
FortiAnalyzer, Syslog traffic will be sent into an IPSec tunnel. Data will be
exchanged over UDP 500/4500, Protocol IP/50.
Configuration backup to FortiManager unit or FortiGuard Analysis and
Management Service
TCP 22
SMTP alert email; encrypted virus sample auto-submit
TCP 25
LDAP or PKI authentication
TCP 389 or TCP
636
FortiGuard Antivirus or IPS update
TCP 443
When requesting updates from a FortiManager unit instead of directly from the
FDN, this port must be reconfigured as TCP 8890.
FortiGuard Analysis and Management Service
TCP 443
FortiGuard Analysis and Management Service log transmission (OFTP)
TCP 514
SSL management tunnel to FortiGuard Analysis and Management Service
TCP 541
FortiGuard Analysis and Management Service contract validation
TCP 10151
Quarantine, remote access to logs & reports on a FortiAnalyzer unit, device
registration with FortiAnalyzer units (OFTP)
TCP 514
RADIUS authentication
TCP 1812
Receiving traffic
When operating in the default configuration, FortiGate units do not accept TCP or UDP
connections on any port except the default internal interface, which accepts HTTPS
connections on TCP port 443.
Function
Port(s)
FortiGuard Antivirus and IPS update push
The FDN sends notice that an update is available. Update downloads then
occur on standard originating ports for updates.
UDP 9443
SSH administrative access to the CLI; remote management from a
FortiManager unit
TCP 22
Telnet administrative access to the CLI; HA synchronization (FGCP L2)
Changing the telnet administrative access port number also changes the HA
synchronization port number.
TCP 23
HTTP administrative access to the web-based manager
TCP 80
HTTPS administrative access to the web-based manager; remote
TCP 443
management from a FortiManager unit; user authentication for policy override
SSL management tunnel from FortiGuard Analysis and Management Service TCP 541
(FortiOS v3.0 MR6 or later)
HA heartbeat (FGCP L2)
TCP 703
User authentication keep alive and logout for policy override (default value of TCP 1000
port for HTTP traffic)
This port is closed until enabled by the auth-keepalive command.
80
01-40002-112804-20101015
Firewall components
Ports
User authentication keepalive and logout for policy override (default value of
port for HTTPS traffic)
This port is closed until enabled by the auth-keepalive command.
TCP 1003
Windows Active Directory (AD) Collector Agent
TCP 8000
User authentication for policy override of HTTP traffic
TCP 8008
FortiClient download portal
This feature is available on FortiGate-1000A, FortiGate-3600A, and
FortiGate-5005FA2.
TCP 8009
User authentication for policy override of HTTPS traffic
TCP 8010
VPN settings distribution to authenticated FortiClient installations
TCP 8900
SSL VPN
TCP 10443
HA
ETH 8890 (Layer 2)
Closing specific ports to traffic
By default, FortiGate units do not accept remote administrative access except by HTTPS
connections on TCP port 443 to the default internal network interface for some FortiGate
models. Restricting administrative access by default ensures that only you can change
your firewall policies and security configuration. It also improves security of the FortiGate
unit itself by reducing the number of ports that potential attackers can discover by network
probes and port scans, a common method of discovering open ports for denial of service
(DoS) attacks.
Port 113
TCP port 113 (Ident/Auth) is an exception to the above rule. By default, FortiGate units
receiving an IDENT request on this port respond with a TCP RST, which resets the
connection. This prevents delay that would normally occur if the requesting host were to
wait for the connection attempt to time out.
This port is less commonly used today. If you do not use this service, you can make your
FortiGate unit less visible to probes. You can disable TCP RST responses to IDENT
requests and subject those requests to firewall policies, and thereby close this port.
For each network interface that should not respond to ident requests on TCP port 113,
enter the following CLI commands:
edit <port_name>
set ident-accept enable
end
For example, to disable ident responses on a network interface names port1, enter the
following commands:
edit port1
set ident-accept enable
end
Port 541
By default, FortiGate units use this port to initiate an SSL-secured management tunnel
connection to centralized device managers such as the FortiGuard Analysis and
Management Service.
01-40002-112804-20101015
81
Services
Firewall components
If you do not use centralized management you can make your FortiGate unit less visible to
probes. You can disable the management tunnel feature, and thereby close this port using
the following CLI command:
config sys central-management
set status disable
end
Services
Services represent typical traffic types and application packets that pass through the
FortiGate unit. Firewall services define one or more protocols and port numbers
associated with each service. Firewall policies use service definitions to match session
types. You can organize related services into service groups to simplify your firewall
policy list.
Many well-known traffic types have been predefined in firewall services and protocols on
the FortiGate unit. These predefined services and protocols are defaults, and cannot be
edited or removed. However, if you require different services, you can create custom
services.
To view the predefined servers, go to Firewall > Service > Predefined.
Custom service
Should there be a service that does not appear on the list, or you have a unique service or
situation, you can create your own custom service. You need to know the port(s), IP
addresses or protocols the particular service or application uses to create the custom
service.
Example
This example creates a custom service for the “Widget” application, which communicates
on TCP port 9620 for source traffic and between ports 4545 and 4550 for destination
traffic.
To create a custom service - web-based manager
1 Go to Firewall > Service > Custom and select Create New.
2 Enter the following and select Add:
Name
Widget
Protocol Type
TCP/UDP/SCTP
Protocol
TCP
Source Port
Low
9620
Hi
9620
Destination Port
Low
4545
High
4550
3 Select OK.
82
01-40002-112804-20101015
Firewall components
Schedules
To create a custom service - CLI
config firewall service custom
edit Widget
set protocol TCP/UDP/SCTP
set tcp-portrange 9620:4545-4550
end
Schedules
When you add firewall policies on a FortiGate unit, those policies are always on, policing
the traffic through the device. Firewall schedules control when policies are in effect, that is,
when they are on. You can create one-time schedules which are schedules that are in
effect only once for the period of time specified in the schedule. You can also create
recurring schedules that are in effect repeatedly at specified times of specified days of the
week.
You can create a recurring schedule that activates a policy during a specified period of
time. For example, you might prevent game playing during office hours by creating a
recurring schedule that covers office hours.
If a recurring schedule has a stop time that is earlier than the start time, the schedule will take effect
at the start time but end at the stop time on the next day. You can use this technique to create
recurring schedules that run from one day to the next. For example, to prevent game playing except
at lunchtime, you might set the start time for a recurring schedule at 1:00 p.m. and the stop time at
12:00 noon. To create a recurring schedule that runs for 24 hours, set the start and stop times to 00.
Example
This example creates a schedule for surfing the Internet at lunch time. The company
restricts the amount of surfing on company time, but over lunch, the restrictions are lifted.
For this schedule, a firewall policy would be created to enable all services for a limited
amount of time. This example sets up the time frame.
To create a recurring firewall schedule - web-based manager
1 Go to Firewall > Schedule > Recurring, and select Create New.
2 Enter the schedule Name of Lunch-Surfing.
3 Select the days of the week this schedule is employed.
In this case, Monday through Friday.
4 Select the Start Hour of 12.
5 Select the Stop Hour of 01.
6 Select OK.
To create a recurring firewall schedule - CLI
config firewall schedule recurring
edit Lunch-Surfing
set day monday tuesday wednesday thursday friday
set start 12:00
set end 1:00
end
01-40002-112804-20101015
83
Schedules
Firewall components
Example
This example creates a one-time schedule for a firewall policy. In this example, a company
is shut down over the Christmas holidays. To prevent employees from coming to work to
use the internet connection, the company sets up a one-time firewall policy to block most
internet traffic during this time period. A schedule needs to be created to limit internet
traffic between December 25 and January 1.
To create a one-time firewall schedule - web-based manager
1 Go to Firewall > Schedule > One-time, and select Create New.
2 Enter the schedule Name of Xmas-Shutdown.
3 Enter the following and select OK.
/Start
Year
2009
Month
12
Day
25
Hour
00
Minute
00
Stop
Year
2010
Month
01
Day
01
Hour
23
Minute
00
To create a firewall schedule - CLI
config firewall schedule onetime
edit Xmas-Shutdown
set start 00:00 2009/12/25
set end 23:00 2010/01/01
end
Schedule groups
You can organize multiple firewall schedules into a schedule group to simplify your firewall
policy list. For example, instead of having five identical policies for five different but related
firewall schedules, you might combine the five schedules into a single schedule group that
is used by a single firewall policy.
Schedule groups can contain both recurring and one-time schedules. Schedule groups
cannot contain other schedule groups.
Example
This example creates a schedule group for the schedules created in the previous
schedule examples. The schedule group enables you to have one firewall policy that
covers both schedules, rather than creating two separate policies.
84
01-40002-112804-20101015
Firewall components
UTM profiles
To create a firewall schedule group - web-based manager
1 Go to Firewall > Schedule > Group, and select Create New.
2 Enter the group Name of Schedules.
3 From the Available Schedules list, select the Lunch-Surfing schedule and select the
down-arrow button to move the address name to the Members list.
4 From the Available Schedules list, select the Xmas-Shutdown schedule and select the
down-arrow button to move the address name to the Members list.
5 Select OK.
To create a recurring firewall schedule - CLI
config firewall schedule group
edit Schedules
set member Lunch-Surfing Xmas-Shutdown
end
UTM profiles
Where firewall policies provide the instructions to the FortiGate unit as to what traffic is
allowed through the device, the Unified Threat Management (UTM) profiles provide the
screening that filters the content coming and going on the network. The UTM profiles
enable you to instruct the FortiGate unit what to look for in the traffic that you don’t want, or
want to monitor, as it passes through the device.
A UTM profile is a group of options and filters that you can apply to one or more firewall
policies. UTM profiles can be used by more than one firewall policy. You can configure
sets of UTM profiles for the traffic types handled by a set of firewall policies that require
identical protection levels and types, rather than repeatedly configuring those same UTM
profile settings for each individual firewall policy.
For example, while traffic between trusted and untrusted networks might need strict
antivirus protection, traffic between trusted internal addresses might need moderate
antivirus protection. To provide the different levels of protection, you might configure two
separate protection profiles: one for traffic between trusted networks, and one for traffic
between trusted and untrusted networks.
UTM profiles are available for various unwanted traffic and network threats. Each are
configured separately and can be used in different groupings as needed. You configure
UTM profiles in the UTM menu and applied when creating a firewall policy by selecting the
UTM profile type.
Profiles and sensors
The UTM profiles can be identified by two categories: profiles (VoIP, antivirus, web filter
and email filter) and sensors (intrusion prevention, application control and data leak
prevention). Profiles are a group of identifiers to filter unwanted email such as spam, web
content and provide virus detection. Sensors are a grouping of common or custom
signature information that the FortiGate unit uses to identify, or sense, an intrusion or data
leak and prevent it from occurring. FortiOS includes a selection of common sensors, and
you can create custom ones as well.
01-40002-112804-20101015
85
UTM profiles
Firewall components
For both categories, you create a unique set of criteria for the profile or sensor and select
it for the firewall policy. When traffic passes through the FortiGate unit, the FortiGate unit
compares the traffic information to see if the policy is valid. If it is, it then applies the
profiles and sensors to the traffic to determine if the traffic is an attack, virus, spam or
unwanted web content and either blocks or allows the traffic through depending on how
the sensor or policy was configured.
FortiOS includes a selection default UTM profiles and sensors. The defaults provide
varying levels of security from very strict, monitoring or blocking everything, to very light
allowing most traffic through. You can use these default protection profiles as is to quickly
configure your network security or as the bases for creating your own.
Example
This example creates an antivirus profile that will scan all email traffic for viruses. The new
profile will be called email_scan.
To create a antivirus profile for email - web-based manager
1 Go to UTM > AntiVirus > Profile and select Create New.
2 Enter the Name of email_scan.
3 For the Virus Scan row, select IMAP, POP3 and SMTP.
4 Select OK.
To create a antivirus profile for email - CLI
config antivirus profile
edit email_scan
config imap
set options scan
end
config smtp
set options scan
end
config pop3
set options scan
end
end
Example
This example creates an web filter profile that prevents Active X and Java applets from
being downloaded in a web browser when a user visits a web site with these elements on
the page. The new profile will be called activex_java.
To create a antivirus profile for email - web-based manager
1 Go to UTM > Web Filter > Profile and select Create New.
2 Enter the schedule Name of activex_java
3 Select the blue arrow for the Advanced Filter to expand the options.
4 Select the check boxes for ActiveX Filter and Java Applet Filter.
5 Select OK.
86
01-40002-112804-20101015
Firewall components
UTM profiles
To create a antivirus profile for email - CLI
config webfilter profile
edit activex_java
config http
set options activexfilter
end
config http
set options javafilter
end
end
01-40002-112804-20101015
87
UTM profiles
88
Firewall components
01-40002-112804-20101015
Firewall Policies
Firewall policies control all traffic attempting to pass through the FortiGate unit, between
FortiGate interfaces, zones, and VLAN subinterfaces.
Firewall policies are instructions the FortiGate unit uses to decide connection acceptance
and packet processing for traffic attempting to pass through. When the firewall receives a
connection packet, it analyzes the packet’s source address, destination address, and
service (by port number), and attempts to locate a firewall policy matching the packet.
Firewall policies can contain many instructions for the FortiGate unit to follow when it
receives matching packets. Some instructions are required, such as whether to drop or
accept and process the packets, while other instructions, such as logging and
authentication, are optional.
Policy instructions may include network address translation (NAT), or port address
translation (PAT), or by using virtual IPs or IP pools to translate source and destination IP
addresses and port numbers.
Policy instructions may also include UTM profiles, which can specify application-layer
inspection and other protocol-specific protection and logging, as well as IPS inspection at
the transport layer.
This chapter describes what firewall policies are and how they affect all traffic to and from
your network. It also describes how to configure some key policies; these are basic
policies you can use as a building block to more complex policies, but they enable you to
get the FortiGate unit running on the network quickly.
This chapter contains the following topics:
•
Policy order
•
Creating basic policies
•
DoS Policies
•
Sniffer Policies
•
Identity-based Policies
•
ICMP packet processing
•
Firewall policy examples
You configure firewall policies to define which sessions will match the policy and what
actions the FortiGate unit will perform with packets from matching sessions.
Sessions are matched to a firewall policy by considering these features of both the packet
and policy:
•
Source Interface/Zone
•
Source Address
•
Destination Interface/Zone
•
Destination Address
•
Schedule and time of the session’s initiation
•
Service and the packet’s port numbers.
If the initial packet matches the firewall policy, the FortiGate unit performs the configured
Action and any other configured options on all packets in the session.
01-40002-112804-20101015
89
Policy order
Firewall Policies
Packet handling actions can be ACCEPT, DENY, IPSEC or SSL-VPN.
•
ACCEPT policy actions permit communication sessions, and may optionally include
other packet processing instructions, such as requiring authentication to use the policy,
or specifying one or more UTM profiles to apply features such as virus scanning to
packets in the session. An ACCEPT policy can also apply interface-mode IPSec VPN
traffic if either the selected source or destination interface is an IPSec virtual interface.
•
DENY policy actions block communication sessions, and you can optionally log the
denied traffic. If no firewall policy matches the traffic, the packets are dropped,
therefore it is not required to configure a DENY firewall policy in the last position to
block the unauthorized traffic. A DENY firewall policy is needed when it is required to
log the denied traffic, also called “violation traffic”.
•
IPSEC and SSL-VPN policy actions apply a tunnel mode IPSec VPN or SSL VPN
tunnel, respectively, and may optionally apply NAT and allow traffic for one or both
directions. If permitted by the firewall encryption policy, a tunnel may be initiated
automatically whenever a packet matching the policy arrives on the specified network
interface, destined for the local private network.
Create firewall policies based on traffic flow. For example, a policy for POP3, where the
email server is outside of the internal network, traffic should be from an internal interface
to an external interface rather than the other way around. It is typically the user on the
network requesting email content from the email server and thus the originator of the open
connection is on the internal port, not the external one of the email server. This is also
important to remember when view log messages as to where the source and destination
of the packets can seem backwards.
Policy order
Each time a FortiGate unit receives a connection attempting to pass through one of its
interfaces, the unit searches its firewall policy list for a matching firewall policy.
The search begins at the top of the policy list and progresses in order towards the bottom.
The FortiGate unit evaluates each policy in the firewall policy list for a match until a match
is found. When the FortiGate unit finds the first matching policy, it applies the matching
policy’s specified actions to the packet, and disregards subsequent firewall policies.
Matching firewall policies are determined by comparing the firewall policy and the
packet’s:
•
source and destination interfaces
•
source and destination firewall addresses
•
services
•
time/schedule.
If no policy matches, the connection is dropped.
As a general rule, you should order the firewall policy list from most specific to most
general because of the order in which policies are evaluated for a match, and because
only the first matching firewall policy is applied to a connection. Subsequent possible
matches are not considered or applied. Ordering policies from most specific to most
general prevents policies that match a wide range of traffic from superseding and
effectively masking policies that match exceptions.
Note: One slight variation on this is identity-based policies. For more information
see “Identity-based Policies” on page 98.
90
01-40002-112804-20101015
Firewall Policies
Policy order
For example, you might have a general policy that allows all connections from the internal
network to the Internet, but want to make an exception that blocks FTP. In this case, you
would add a policy that denies FTP connections above the general policy.
Figure 23: Example: Blocking FTP — Correct policy order
}Exception
}General
FTP connections would immediately match the deny policy, blocking the connection.
Other kinds of services do not match the FTP policy, and so policy evaluation would
continue until reaching the matching general policy. This policy order has the intended
effect. But if you reversed the order of the two policies, positioning the general policy
before the policy to block FTP, all connections, including FTP, would immediately match
the general policy, and the policy to block FTP would never be applied. This policy order
would not have the intended effect.
Figure 24: Example: Blocking FTP — Incorrect policy order
}General
}Exception
Similarly, if specific traffic requires authentication, IPSec VPN, or SSL VPN, you would
position those policies above other potential matches in the policy list. Otherwise, the
other matching policies would always take precedence, and the required authentication,
IPSec VPN, or SSL VPN might never occur.
Note: A default firewall policy may exist which accepts all connections. You can move,
disable or delete it. If you move the default policy to the bottom of the firewall policy list and
no other policy matches the packet, the connection will be accepted. If you disable or delete
the default policy and no other policy matches the packet, the connection will be dropped.
You can arrange the firewall policy list to influence the order in which policies are
evaluated for matches with incoming traffic. When more than one policy has been defined
for the same interface pair, the first matching firewall policy will be applied to the traffic
session.
Denial of Service policies
An exception to the above description is denial of service (DoS), also known as anomaly
thresholds, and sniffer firewall policies. These policies are created in a separate location in
the Firewall menu, and processed first before any other policy, yet in their own respective
order. This is done to determine early in the traffic processing if the traffic is valid traffic or
an unwanted attack, and therefore shutting it down before further processing of anti-spam
and anti-virus definitions. For more information on DoS policies, see “DoS Policies” on
page 96.
Rearranging policies
Moving a policy in the firewall policy list does not change its ID, which only indicates the
order in which the policy was created.
01-40002-112804-20101015
91
Policy order
Firewall Policies
To move a policy in the policy list
1 Go to Firewall > Policy > Policy.
2 In the firewall policy list, note the ID of a firewall policy that is before or after your
intended destination.
3 Select the row corresponding to the firewall policy you want to move and select Move.
4 Select Before or After, and enter the ID of the firewall policy that is before or after your
intended destination. This specifies the policy’s new position in the firewall policy list.
5 Select OK.
Firewall policy 0
FortiGate units create a firewall policy of 0 (zero) which can appear in the logs, but will
never appear in the firewall policy list, and therefore can never be repositioned in the list.
When viewing the FortiGate logs, you may find an entry indicating policyid=”0”.
For example:
2008-10-06 00:13:49 log_id=0022013001 type=traffic
subtype=violation pri=warning vd=root SN=179089 duration=0
user=N/A group=N/A rule=0 policyid=0 proto=17 service=137/udp
app_type=N/A status=deny src=10.181.77.73 srcname=10.181.77.73
dst=10.128.1.161 dstname=10.128.1.161 src_int=N/A
dst_int="Internal" sent=0 rcvd=0 src_port=137 dst_port=137 vpn=N/A
tran_ip=0.0.0.0 tran_port=0
Any firewall policy that is automatically added by the FortiGate unit has a policy ID number
of 0. The most common reasons the FortiGate unit creates this policy is
•
The IPsec policy for FortiAnalyzer (and FortiManager version 3.0) is automatically
added when an IPsec connection to the FortiAnalyzer unit or FortiManager is enabled.
•
The policy to allow FortiGuard servers to be automatically added has a policy ID
number of 0.
•
The (default) drop rule that is the last rule in the policy and that is automatically added
has a policy ID number of 0.
•
When a network zone is defined within a VDOM, the intra-zone traffic set to allow or
block is managed by policy 0 if it is not processed by a configured firewall policy.
Firewall policy list details
The firewall policy table includes by default a number of columns to display information
about the policy, for example, source, destination, service, and so on. You can add a
number of additional columns to the table to view more information about the policies and
what is in their configuration. By going to Firewall > Policy > Policy and selecting the
Column Settings link, you can add or remove a number of different columns of information
to the policy list, and arrange their placement within the table.
92
01-40002-112804-20101015
Firewall Policies
Figure 25: Firewall policy column selection
This section describes how to configure basic firewall policies based on the selectable
actions described above. The following criteria will be used for each policy for
internal/source and external/destination information. Single addresses are used for
simplification.
Source interface/Zone
Internal
Source address
10.13.20.22
Destination interface/Zone
WAN1
Destination address
172.20.120.141
Using an interface of “any”
When adding a firewall policy with Source interface/zone or Destination interface/zone set
to ANY, that the firewall policy list can only be displayed in Global View. This is because a
firewall policy with an ANY interface potentially applies to all interfaces, however it does
not accurately reflect the actual firewall configuration if all of the ANY interface policies
appears in every section in Section View.
The actual affect to policy matching of a firewall policy with any as the source or
destination interface is only clear on the global policy list.
01-40002-112804-20101015
93
Firewall Policies
Basic accept policy example
With this basic accept policy example, the firewall policy will accept all HTTP traffic
passing from the external interface (WAN1) to the internal interface (Internal) at all times.
This enables users to surf the internet using HTTP (port 80). Using this policy alone, no
other traffic (email, FTP and so on) to pass through the FortiGate unit. The policy allows a
session to be created that traverses the FortiGate unit from WAN1 (the source) to Internal
(the destination). That is the direction data is moving when an internal user views a web
page, but the incoming page data first has to be requested, and that happens by opening
a session from Internal to WAN1 first.
To create a basic accept policy for HTTP - web-based manager
1 Go to Firewall > Policy > Policy and select Create New.
2 Enter the following and select OK:
Internal
Source address
10.13.20.22
WAN1
Destination address
ALL
Schedule
always
Service
HTTP
Action
ALLOW
To create a basic accept policy for HTTP - CLI
edit 1
set srcintf internal
set scraddr 10.13.20.22
set dstintf wan1
set dstaddr all
set action accept
set schedule always
set service http
end
Basic deny policy example
With this basic deny policy example, the firewall policy will deny all FTP traffic passing
from the internal interface (Internal) to the external interface (WAN1) at all times. This
prevents users from uploading files to an FTP site. Ideally, this would not be the only policy
on the FortiGate unit.
To create a basic deny policy for FTP - web-based manager
94
Internal
Source address
10.13.20.22
WAN1
Destination address
172.20.120.141
Schedule
always
01-40002-112804-20101015
Firewall Policies
Service
FTP
Action
DENY
To create a basic accept policy for FTP - CLI
edit 1
set srcaddr 10.13.20.22
set dstintf wan1
set dstaddr 172.20.120.141
set action deny
set schedule always
set service ftp
end
Basic VPN policy example
With this basic VPN policy example, the firewall policy will allow VPN traffic between the
FortiGate unit in the branch office and the head office. For simplicity, the VPN
configuration has been completed. The Phase 1 name is Head_Office. This firewall policy
would be configured on the Branch office FortiGate unit.
To create a basic VPN policy - web-based manager
Internal
Source address
10.13.20.22
WAN1
Destination address
172.20.120.141
Schedule
always
Service
any
Action
IPSEC
VPN Tunnel
Select Head_Office from the configured list of VPN tunnels.
To create a basic VPN tunnel - CLI
edit 1
set dstintf wan1
set dstaddr 172.20.120.141
set action allow
set schedule always
set service any
set vpntunnel Head_Office
end
01-40002-112804-20101015
95
DoS Policies
Firewall Policies
DoS Policies
Denial of Service (DoS) policies, also known as anomaly thresholds, are primarily used to
apply DoS sensors to network traffic based on the FortiGate interface it is entering as well
as the source and destination addresses. DoS sensors are a traffic anomaly detection
feature to identify network traffic that does not fit known or common traffic patterns and
behavior. A denial of service attack occurs when an attacking system starts an abnormally
large number of sessions with a target system. The large number of sessions slows down
or disables the target system so legitimate users can no longer use it.
DoS policies examine network traffic very early in the sequence of protective measures
the FortiGate unit deploys to protect your network. Because of this, DoS policies are a
very efficient defence, using few resources. The previously mentioned denial of service
would be detected and its packets dropped before requiring firewall policy look-ups,
antivirus scans, and other protective but resource-intensive operations.
You can create DoS sensors to protect against variety of different attack patterns. By
default, the FortiGate unit includes two sensors; one to pass all traffic and one to block the
more common DoS attack patterns. To create your own DoS sensor, go to UTM >
Intrusion Protection > DoS Sensor and select Create New.
For more information on DoS sensor configuration, see the UTM Guide.
DoS sensor policies are stored separately in the FortiGate web-based manager and do
not appear in the firewall policy list. As traffic passes through the FortiGate interface, the
DoS policy is applied first to determine whether the traffic is genuine or an attack. If it is
genuine, the packets are forwarded to the normal firewall policies and applied as required.
If the FortiGate unit determines the traffic is a DoS attack, the policy is applied as
configured in the DoS sensor.
Basic DoS policy example
This example demonstrates setting up a simple DoS policy using the default sensor
block_flood to monitor HTTP traffic the WAN1 port for any addresses through that port.
The block_flood sensor monitors for flood attacks.
To create the DoS firewall policy - web-based manager
1 Go to Firewall > Policy > DoS Policy and select Create New.
2 Set the Source Interface/Zone to WAN1.
3 Set the Source Address to All.
4 Set the Destination Address to All
5 Set the Service to HTTP.
6 Select the check box for DoS Sensor, and select block_flood from the list.
7 Select OK.
To create the DoS firewall policy - CLI
config firewall interface-policy
edit 1
set interface wan1
set srcaddr all
set dstaddr all
set service http
set ips-DoS-status enable
set ips-DoS block_flood
96
01-40002-112804-20101015
Firewall Policies
Sniffer Policies
end
Sniffer Policies
Sniffer policies are used to configure a physical interface on the FortiGate unit as a
one-arm intrusion detection system (IDS). Traffic sent to the interface is examined for
matches to the configured IPS sensor and application control list. Matches are logged and
then all received traffic is dropped. Sniffing only reports on attacks. It does not deny or
otherwise influence traffic.
Sniffer policies are applied to sniffer interfaces. Traffic entering a sniffer interface is
checked against the sniffer policies for matching source and destination addresses and for
service. This check against the policies occurs in listed order, from top to bottom. The first
sniffer policy matching all three attributes then examines the traffic. Once a policy matches
the attributes, checks for policy matches stop. If no sniffer policies match, the traffic is
dropped without being examined.
Once a policy match is detected, the matching policy compares the traffic to the contents
of the DoS sensor, IPS sensor, and application control list specified in the policy. If any
matches are detected, the FortiGate unit creates an entry in the log of the matching
sensor/list. If the same traffic matches multiple sensors/lists, it is logged for each match.
Before creating the sniffer policy, you must setup the FortiGate unit to the network and
configure a port as a dedicated sniffer port.The easiest way to do this is to either use a hub
or a switch with a SPAN port. A SPAN port is a special-purpose interface that mirrors all
the traffic the switch receives. Traffic is handled normally on every other switch interface,
but the SPAN port sends a copy of everything. If you connect your FortiGate unit sniffer
interface to the switch SPAN port, all the network traffic will be examined without any being
lost because of the examination.
The FortiGate interface needs to be enabled for sniffing. In the example below, the WAN1
port is configured for one-armed sniffing.
To configure a FortiGate interface as a one-arm sniffer - web-based manager
2 and select the WAN1 interface row and select Edit.
3 Select the check box for Enable one-arm sniffer.
4 Note that the port that is set up in sniffer mode will not require an IP address.
5 Select OK.
To configure a FortiGate interface as a one-arm sniffer - CLI
edit wan1
set ips-sniffer-mode enable
end
Basic one-armed sniffer policy example
This example demonstrates setting up a simple one-armed sniffer policy using the default
DoS sensor block_flood and IPS sensor protect_email_server to monitor SMTP traffic the
WAN1 port for any addresses through that port. Note that the WAN1 port was enabled in
the previous steps to be used as a sniffer port.
01-40002-112804-20101015
97
Firewall Policies
To create the one-armed sniffer firewall policy - web-based manager
1 Go to Firewall > Policy > Sniffer Policy and select Create New.
2 Set the Source Interface/Zone to WAN1.
3 Set the Source Address to All.
4 Set the Destination Address to All
5 Set the Service to SMTP.
6 Select the check box for DoS Sensor, and select block_flood from the list.
7 Select the check box for IPS Sensor and select protect_email_server from the list.
8 Select OK.
To create the DoS firewall policy - CLI
config firewall interface-policy
edit 1
set interface wan1
set srcaddr all
set dstaddr all
set service smtp
set ips-sensor-status enable
set ips-sensor protect_email_server
set ips-DoS-status enable
set ips-DoS block_flood
end
If you enable Enable Identity Based Policy in a firewall policy, network users must send
traffic involving a supported firewall authentication protocol to trigger the firewall
authentication challenge, and successfully authenticate, before the FortiGate unit will
allow any other traffic matching the firewall policy.
The authentication style depends on which of these supported protocols you have
included in the selected firewall services group and which of those enabled protocols the
network user applies to trigger the authentication challenge. The authentication style will
be one of two types. For certificate-based (HTTPS or HTTP redirected to HTTPS only)
authentication, you must install customized certificates on the FortiGate unit and on the
browsers of network users, which the FortiGate unit matches. For user name and
password-based (HTTP, FTP, and Telnet) authentication, the FortiGate unit prompts
network users to input their firewall user name and password.
For example, if you want to require HTTPS certificate-based authentication before
allowing SMTP and POP3 traffic, you must select a firewall service (in the firewall policy)
that includes SMTP, POP3 and HTTPS services. Prior to using either POP3 or SMTP, the
network user would send traffic using the HTTPS service, which the FortiGate unit would
use to verify the network user’s certificate; upon successful certificate-based
authentication, the network user would then be able to access his or her email.
In most cases, you should ensure that users can use DNS through the FortiGate unit
without authentication. If DNS is not available, users will not be able to use a domain
name when using a supported authentication protocol to trigger the FortiGate unit’s
authentication challenge.
98
01-40002-112804-20101015
Firewall Policies
Note: If you do not install certificates on the network user’s web browser, the network users
may see an SSL certificate warning message and have to manually accept the default
FortiGate certificate, which the network users’ web browsers may then deem as invalid.
Note: When you use certificate authentication, if you do not specify any certificate when
you create a firewall policy, the FortiGate unit will use the default certificate from the global
settings. If you specify a certificate, the per-policy setting will override the global setting.
Authentication requires that Action is ACCEPT or SSL-VPN, and that you first create
users, assign them to a firewall user group, and assign UTM profiles to that user group.
Identity-based policy example
With this basic identity-based policy example, the firewall policy will allow HTTPS traffic
passing from the external interface (WAN1) to the internal interface (Internal) at all times,
as soon as the network user enters their username and password. For simplicity, the
policy will request the firewall authentication. This authentication can be set up for users
by going to User > User and their groupings by going to User > Groups. For this example,
the group “accounting” is used. When a user attempts to browse to a secure site, they will
be prompted for their log in credentials.
To create a identity-based policy - web-based manager
2 Enter the following:
Internal
Source address
10.13.20.22
WAN1
Destination address
172.20.120.141
Schedule
always
Action
ACCEPT
3 Select Enable Identity Based Policy.
4 Firewall authentication is enabled by default.
5 Select Add.
6 From the Available User Groups list, select the Accounting user group and select the
right arrow to move it to the Selected User Groups area.
7 From the Available Services list, select the HTTPS and select the right arrow to move it
to the Selected Services area.
8 For the Schedule, select Always.
9 Select OK.
edit 1
set dstintf wan1
set dstaddr 172.20.120.141
set action accept
set schedule always
01-40002-112804-20101015
99
Firewall Policies
set identity-based enable
config identity-based-policy
edit 1
set group accounting
set service HTTPS
set schedule always
end
end
Identity-based policy positioning
With identity-based firewall policies, positioning is extremely important. For a typical
firewall policy, the FortiGate unit matches the source, destination and service of the policy.
If matched, it acts on that policy. If not, the FortiGate unit moves to the next policy.
With identity-based policies, once the FortiGate unit matches the source and destination
addresses, it processes the identity sub-rules for the user groups and services. That is, it
acts on the authentication and completes the remainder of that policy and goes no further
in the policy list.
The way identity based policies work is that once src/dest are matched, it will process the
identity based sub-rules (for lack of a better term) around the user groups and services. It
will never process the rest of your rulebase. For this reason, unique firewall policies
should be placed before an identity-based policy.
For example, consider the following policies:
DNS traffic goes through successfully as does any HTTP traffic after being authenticated.
However, if there was FTP traffic, it would not get through. As the FortiGate unit processes
FTP traffic, it skips rule one since it’s matching the source, destination and service. When
it moves to rule two it matches the source and destination, it determines there is a match
and, sees there are also processes the group/service rules, which requires authentication
and acts on those rules. Once satisfied, the FortiGate unit will never go to rule three.
In this situation, where you would want FTP traffic to traverse the FortiGate unit, create a
firewall policy specific to the services you require and place it above the authentication
policy.
Identity-based sub-policies
When adding authentication to a firewall policy, you can add multiple authentication rules,
or sub-policies. Within these policies you can include additional UTM profiles, traffic
shaping and so on, to take affect on the selected services.
100
01-40002-112804-20101015
Firewall Policies
Figure 26: Authentication sub-policies
These sub-policies work on the same principle as normal firewall policies, that is, top
down until the criteria has been met (see “Policy order” on page 90). As such, if there is no
matching policy within the list, the packet can still be dropped even after authentication is
successful.
ICMP messages are used to relay feedback to the traffic source that the destination IP is
not reachable. ICMP message types are
•
ICMP_ECHO
•
ICMP_TIMESTAMP
•
ICMP_INFO_REQUEST
•
ICMP_ADDRESS
For ICMP error messages, only those reporting an error for an existing session can pass
through the firewall. The firewall policy will allow traffic to be routed, forwarded or denied.
If allowed, the ICMP packets will start a new session. Only ICMP error messages of a
corresponding firewall policy is available will be sent back to the source. Otherwise, the
packet is dropped. That is, only ICMP packets for a corresponding firewall policy can
traverse the FortiGate unit.
Common error messages include:
•
destination unreachable messages
•
time exceeded messages
•
redirect messages
For example, a firewall policy that allows TFTP traffic through the FortiGate unit. User1
(192.168.21.12) attempts to connect to the TFTP server (10.11.100.1), however, the UDP
port 69 has not been opened on the server. The corresponding sniffer trace occurs:
diagnose sniffer packet any “host 10.11.100.1 or icmp 4”
3.677808 internal in 192.168.21.12.1262 -> 10.11.100.1.69: udp 20
3.677960 wan1 out 192.168.21.12.1262 -> 10.11.100.1.69: udp 20
3.678465 wan1 in 10.11.100.1.132 -> 192.168.21.12: icmp: 10.11.100.1
udp port 69 unreachable
3.678519 internal out 10.11.100.1 -> 192.168.21.12: icmp:
192.168.182.132 udp port 69 unreachable
01-40002-112804-20101015
101
Firewall Policies
This section provides some simple, real-world, examples of firewall policies you can use
as a starting point when creating policies for your network.
Blocking an IP address
This example describes how to create a firewall policy to block a specific IP address. Any
traffic from the configured IP address will be dropped at the point of hitting the FortiGate
unit. To block an IP address, you need to create an address entry before creating a firewall
policy to block the address.
Add an Address
First create the address which the FortiGate will identify to be blocked. In this example, the
address will be 172.20.120.29 for the address name of Blocked_IP.
To add an address entry - web-based manager
2 Enter a Name of Blocked_IP.
3 Enter the IP address and subnet of 172.20.120.29/255.255.255.255.
The subnet is set to 255.255.255.255 to block the specific address. If you wanted to
block the entire subnet enter 172.20.120.0/255.255.255.0.
To add an address entry - web-based CLI
edit Blocked_IP
set subnet 172.20.120.29/32
end
Add a Firewall Policy
With the address added, you can now create the DENY firewall policy which will prevent
any traffic from this IP address from traversing the network. In this policy, the traffic will be
restricted from the IP of an outside source through the external interface, WAN1.
To add a firewall policy - web-based manager
2 Complete the following and select OK:
WAN1
Source Address
Blocked_IP
Internal
Destination Address
All
Schedule
Always
Service
ALL
Action
DENY
3 Move the firewall policy to the top of the policy list.
To add a firewall policy - web-based CLI
config firewall poliy
edit 1
102
01-40002-112804-20101015
Firewall Policies
set
set
set
set
set
set
set
srcintf wan1
srcaddr Blocked_IP
dstintf Internal
dstaddr all
action deny
schedule always
service any
end
Scheduled access policies
Firewall schedules control when policies are in effect, that is, when they are on. You can
create one-time schedules which are schedules that are in effect only once for the period
of time specified in the schedule. You can also create recurring schedules that are in effect
repeatedly at specified times of specified days of the week. For more information on
schedules, see “Services” on page 82.
This example describes firewall policy rules that:
•
On weekdays, allow all users to fully access the Internet during lunchtime and after
business hours
•
Allow full access to the Internet without any restriction for users from a specific IP
range, called Admin_PCs
•
During business hours, allow only access to www.example.com and
www.example2.com for the other users
•
No restriction during the weekend
It should be noted that a Firewall Policy is inactive outside of its schedule and that the
schedule relies upon the date/time that is configured on the FortiGate unit.
In this example all users are connected to the Internal interface and that the Internet
access is connected to WAN1.
Configuring the schedules
Begin by adding the schedule time when the firewall policies take affect.
Note: If the stop time is set earlier than the start time, the stop time will be
considered as the next day. If the start time is equal to the stop time, the schedule
will run for 24 hours.
To configure schedules - web-based manager
1 Go to Firewall > Schedule > Recurring, and select Create New.
2 Enter the schedule Name of week-end.
3 Select the days of the week this schedule is employed. In this case, Saturday and
Sunday.
4 Select OK.
5 Select Create New
6 Enter the schedule Name of lunch-time.
7 Select the days of the week this schedule is employed. In this case, Monday through
Friday.
01-40002-112804-20101015
103
Firewall Policies
10 Select OK.
11 Select Create New
12 Enter the schedule Name of late evening early morning.
13 Select the days of the week this schedule is employed. In this case, Monday through
Friday.
16 Select OK.
To configure schedules - web-based manager
edit week-end
set day sunday saturday
next
edit lunch-time
set end 14:00
set start 12:00
next
edit late evening to early morning
set end 08:00
set start 18:00
next
end
Configuring the IP addresses
Configure the addresses for the administrator computers and the web sites that can be
accessible during the scheduled times.
To configure addresses and web sites - web-based manager
2 Enter a Name of Admin_PCs.
3 Enter the Subnet/IP Range of 192.168.1.200-192.168.1.254.
4 Select OK.
6 Enter the Name of example.com
7 Select the Type of FQDN.
8 Enter the FQDN of www.example.com.
9 Select OK.
11 Enter the Name example2.com
12 Select the Type of FQDN.
13 Enter the FQDN of www.example2.com.
14 Select OK.
104
01-40002-112804-20101015
Firewall Policies
To configure addresses and web sites - CLI
edit Admin_PCs
set type iprange
set end-ip 192.168.1.254
set start-ip 192.168.1.200
next
edit example.com
set type fqdn
set fqdn www.example.com
next
edit example2.xom
set type fqdn
set fqdn www.example2.com
next
end
Configuring the firewall policies
With the key components, the schedules and addresses, create the firewall policies to
employ these components and set the schedules to drive what users can view during the
day. There are a total of five required for this example.
To create the firewall policies - web-based manager
2 Complete the following for the weekend access policy and select OK:
Internal
Source Address
All
Destination Interface/Zone WAN1
Destination Address
All
Schedule
week-end
Service
ALL
Action
Accept
NAT
Select to Enable.
Comments
Week-end policy.
4 Complete the following for the administrator access policy and select OK:
Internal
Source Address
Admin_PCs
Destination Address
All
Schedule
Always
Service
ALL
Action
Accept
NAT
Select to Enable.
Comments
Admin PCs no restriction.
01-40002-112804-20101015
105
Firewall Policies
6 Complete the following for the lunch-time surfing policy and select OK
:
Internal
Source Address
All
Destination Address
All
Schedule
lunch-time
Service
ALL
Action
Accept
NAT
Select to Enable.
Comments
Lunch-time policy.
8 Complete the following for the overnight policy and select OK
:
Internal
Source Address
All
Destination Address
All
Schedule
late_eveing_early_morning
Service
ALL
Action
Accept
NAT
Select to Enable.
Comments
Late evening to early morning policy.
10 Complete the following for the web site access policy and select OK
:
Internal
Source Address
All
Destination Interface/Zone example.com and example2.com
Destination Address
All
Schedule
Always
Service
ALL
Action
Accept
NAT
Select to Enable.
Comments
Access to the example.com websites policy.
To create the firewall policies - CLI
edit 1
set dstintf wan1
set srcaddr all
set dstaddr all
set action accept
set comments week-end policy
106
01-40002-112804-20101015
Firewall Policies
set schedule week-end
set service ANY
set nat enable
next
edit 2
set dstintf wan1
set srcaddr Admin_PCs
set dstaddr all
set action accept
set comments Admin PCs no restriction
set schedule always
set service ANY
set nat enable
next
edit 3
set dstintf wan1
set srcaddr all
set dstaddr all
set action accept
set comments lunch time policy
set schedule lunch-time
set service ANY
set nat enable
next
edit 4
set dstintf wan1
set srcaddr all
set dstaddr all
set action accept
set comments “late evening to early morning policy”
set schedule “late evening to early morning”
set service ANY
set nat enable
next
edit 5
set dstintf wan1
set srcaddr all
set dstaddr
example.com
example2.com
set action accept
set schedule always
set service ANY
set nat enable
next
end
01-40002-112804-20101015
107
108
Firewall Policies
01-40002-112804-20101015
Troubleshooting
When the firewall policies are in place and traffic is not flowing, or flowing more than it
should, there may be an issue with the one or more firewall policies. This chapter outlines
some troubleshooting tips and steps to diagnose where the traffic is not getting through, or
letting too much traffic through.
If, after attempting to troubleshoot your connection issues, you are still having difficulites,
contact Technical Support for further assistance. For more information on contacting
Technical Support, see “Customer service and technical support” on page 20.
This chapter includes the topics:
•
Basic policy checking
•
Default gateway
•
Verifying traffic
•
Using log messages to view violation traffic
•
Traffic trace
•
Packet sniffer
Basic policy checking
Before going into a deep troubleshooting session, first verify a few simple settings in the
firewall policy configuration to ensure everything is setup correctly.
For example:
•
Verify the policy position. The FortiGate unit evaluates each policy in the firewall policy
list for a match until a match is found. When the FortiGate unit finds the first matching
policy, it applies the matching policy’s specified actions to the packet, and disregards
subsequent firewall policies. Is the order of the policies affecting traffic flow? For more
information see “Policy order” on page 90.
•
Verify that the source and destination ports and their addresses (IP Pools and virtual
IPs) are selected correctly for the correct subdomain.
•
Ensure that the NAT check box is selected in the policy. If you selected a virtual IP as
the destination address, but did not select the NAT option, the FortiGate unit performs
destination NAT rather than full NAT.
•
Verify that the UTM profiles you selected are properly configured, and that any URLs or
IP addresses are entered correctly.
•
Verify that the policy is enabled. In the firewall policy list (Firewall > Policy > Policy), the
Status column indicates whether a firewall policy is enabled or not. To be enabled, the
check box must be selected.
Default gateway
01-40002-112804-20101015
109
Verifying traffic
Troubleshooting
Verifying traffic
With many firewall policies in place, you may want to verify that traffic is being affected by
the policy. There is a simple way to get a quick visual confirmation within the web-based
manager. This is done by adding a counter column to the firewall policy table. These steps
are only available in the web-based manager.
To view the traffic count on firewall policies
2 Select Column Settings in the upper right of the window.
3 From Available fields list, select Count.
4 Select the right-facing arrow to add it to the Show these fields column.
5 Select OK.
As packets hit this policy, the count will appear in the column in kilobytes.
Note: For accelerated traffic, NP2 ports the count does not reflect the real traffic count.
Only the start of a session packet will be counted. For non-accelerated traffic, all packets
are counted.
Using log messages to view violation traffic
Firewall policies are instructions the FortiGate unit uses to decide connection acceptance
and packet processing for traffic attempting to pass through. When the firewall receives a
connection packet, it analyzes the packet’s source address, destination address, and
service (by port number), and attempts to locate a firewall policy matching the packet. If no
Firewall Policy is matching the traffic, the packets are dropped. Because of this, you do not
need to configure a DENY Firewall Policy in the last position to block the unauthorized
traffic.
However, you may want to see what type of traffic is attempting to access the network. By
adding a DENY firewall policy, you can log the dropped traffic for analysis. Note that
storing and viewing the log for denied traffic requires a FortiAnalyzer, or a Syslog server,
or a FortiGate unit with a local hard disk.
To configure logging denied traffic you need to crate the DENY firewall policy and enable
logging. In this example, the firewall policy will deny all HTTP traffic passing from the
internal interface (Internal) to the external interface (WAN1) at all times.
To configure the logging of violation traffic - web-based manager
2 Enter the following:
Internal
Source address
10.13.20.22
WAN1
Destination address
172.20.120.141
Schedule
always
Service
HTTP
Action
DENY
3 Select Log Violation Traffic.
110
01-40002-112804-20101015
Troubleshooting
Traffic trace
4 Select OK.
edit 1
set dstintf wan1
set dstaddr 172.20.120.141
set action deny
set schedule always
set service http
set logtraffic enable
end
The following is a sample syslog message from a logged traffic violation.
Warning
10.160.0.110
date=2009-09-14 time=10:16:25
devname=FG300A3906550380 device_id=FG300A3906550380 log_id=0022000003
type=traffic subtype=violation pri=warning fwver=040000 status=deny
vd="root" src=10.160.1.10 srcname=10.160.1.10 src_port=0 dst=4.2.2.1
dstname=10.2.2.1 dst_port=0 service=8/icmp proto=1 app_type=N/A
duration=0 rule=3 policyid=1 sent=0 rcvd=0 vpn="N/A" src_int="port2"
dst_int="port1" SN=12215 user="N/A" group="N/A" carrier_ep="N/A"
Traffic trace
Traffic tracing enables you to follow a specific packet stream. View the characteristics of a
traffic session though specific firewall policies using the CLI command diagnose
system session, trace per-packet operations for flow tracing using diagnose debug
flow and trace per-Ethernet frame using diagnose sniffer packet.
Session table
The FortiGate session table can be viewed from the web-based manager or the CLI. The
most useful troubleshooting data comes from the CLI. The session table in web-based
manager also provides some useful summary information, particularly the current policy
number that the session is using.
Sessions only are appear if a session was established. If a packet is dropped, then no
session will appear in the table. Using the CLI command diagnose debug flow can be
used to identify why the packet was dropped.
To view the session table in the web-based manager
1 Go to System > Dashboard > Status.
2 Select Add Content > Top Sessions.
3 In the Top Sessions pane, select Details.
The Policy ID displays which firewall policy matches the session. The sessions that do not
have a Policy ID entry originate from the FortiGate unit.
To view the session table in the CLI
diagnose sys session list
01-40002-112804-20101015
111
Traffic trace
Troubleshooting
The session table output using the CLI is very verbose. You can use filters to display only
the session data of interest. An entry is placed in the session table for each traffic session
passing through a firewall policy.
Sample output
session info: proto=6 proto_state=05 expire=89 timeout=3600
flags=00000000 av_idx=0 use=3
bandwidth=204800/sec
guaranteed_bandwidth=102400/sec
traffic=332/sec prio=0 logtype=session ha_id=0 hakey=4450
tunnel=/
state=log shape may_dirty
statistic(bytes/packets/err): org=3408/38/0 reply=3888/31/0
tuples=2
orgin->sink: org pre->post, reply pre->post oif=3/5
gwy=192.168.11.254/10.0.5.100
hook=post dir=org act=snat 10.0.5.100:1251>192.168.11.254:22(192.168.11.105:1251)
hook=pre dir=reply act=dnat 192.168.11.254:22>192.168.11.105:1251(10.0.5.100:1251)
pos/(before,after) 0/(0,0), 0/(0,0)
misc=0 domain_info=0 auth_info=0 ftgd_info=0 ids=0x0 vd=0
serial=00007c33 tos=ff/ff
Filter options enable you to view specific information from this command:
diagnose sys session filter <option>
The <option> values available include the following:
clear
clear session filter
dport
dest port
dst
destination IP address
negate
inverse filter
policy
policy ID
proto
protocol number
sport
source port
src
source IP address
vd
index of virtual domain. -1 matches all
Even though UDP is a sessionless protocol, the FortiGate unit still keeps track of the
following two different states:
112
•
UDP reply not seen with a value of 0
•
UDP reply seen with a value of 1
01-40002-112804-20101015
Troubleshooting
Traffic trace
The table below shows the firewall session states from the session table:
State
Meaning
log
Session is being logged.
local
Session is originated from or destined for local stack.
ext
Session is created by a firewall session helper.
may_dirty
Session is created by a policy. For example, the session for ftp control
channel will have this state but ftp data channel will not. This is also seen
when NAT is enabled.
ndr
Session will be checked by IPS signature.
nds
Session will be checked by IPS anomaly.
br
Session is being bridged (TP) mode.
Finding object dependencies
An administrator may not be permitted to delete a configuration object if there are other
configuration objects that depend on it. For example, you may not be able to delete a user
group because that user group is connected with a firewall policy. This command identifies
other objects which depend on or make reference to the configuration object in question. If
a message appears that an object is in use and cannot be deleted, this command can help
identify where this is occurring.
When running multiple VDOMs, this command is run in the Global configuration only and it
searches for the named object both in the Global and VDOM configuration most recently
used:
diagnose sys checkused <path.object.mkey>
For example, to verify which objects are referred to in a firewall policy with an ID of 1, enter
the command:
diagnose sys checkused firewall.policy.policyid 1
To verify what is referred to by port1 interface, enter the command:
diagnose sys checkused system.interface.name port1
To show all the dependencies for the WAN1 interface, enter the command:
diag sys checkused system.interface.name wan1
Sample output
entry
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'
In this example, the interface has dependent objects, including four address objects, one
VIP, and three firewall policies.
Flow trace
To trace the flow of packets through the FortiGate unit, use the command
diagnose debug flow trace start
Follow the packet flow by setting a flow filter using the command:
diagnose debug flow filter <option>
01-40002-112804-20101015
113
Traffic trace
Troubleshooting
Filtering options include:
addr
IP address
clear
clear filter
daddr
destination IP address
dport
destination port
negate
inverse filter
port
port
proto
protocol number
saddr
source IP address
sport
source port
vd
index of virtual domain, -1 matches all
Enable the output to in the console:
diagnose debug flow show console enable
Start flow monitoring with a specific number of packets using the command:
diagnose debug flow trace start <N>
Stop flow tracing at any time using:
diagnose debug flow trace stop
Sample output
This an example shows the flow trace for the device at the IP address 203.160.224.97.
diag debug enable
diag debug flow filter addr 203.160.224.97
diag debug flow show console enable
diag debug flow show function-name enable
diag debug flow trace start 100
Flow trace output example - HTTP
Connect to the web site at the following address to observe the debug flow trace. The
display may vary slightly:
http://www.fortinet.com
Comment: SYN packet received:
id=20085 trace_id=209 func=resolve_ip_tuple_fast
line=2700 msg="vd-root received a packet(proto=6,
192.168.3.221:1487->203.160.224.97:80) from port5."
SYN sent and a new session is allocated:
id=20085 trace_id=209 func=resolve_ip_tuple line=2799
msg="allocate a new session-00000e90"
Lookup for next-hop gateway address:
id=20085 trace_id=209 func=vf_ip4_route_input line=1543
msg="find a route: gw-192.168.11.254 via port6"
Source NAT, lookup next available port:
id=20085 trace_id=209 func=get_new_addr line=1219
msg="find SNAT: IP-192.168.11.59, port-31925"
direction“
114
01-40002-112804-20101015
Troubleshooting
Traffic trace
Matched firewall policy. Check to see which policy this session matches:
id=20085 trace_id=209 func=fw_forward_handler line=317
msg="Allowed by Policy-3: SNAT"
Apply source NAT:
id=20085 trace_id=209 func=__ip_session_run_tuple
line=1502 msg="SNAT 192.168.3.221->192.168.11.59:31925"
SYN ACK received:
id=20085 trace_id=210 func=resolve_ip_tuple_fast line=2700
msg="vd-root received a packet(proto=6, 203.160.224.97:80>192.168.11.59:31925) from port6."
Found existing session ID. Identified as the reply direction:
msg="Find an existing session, id-00000e90, reply
direction"
Apply destination NAT to inverse source NAT action:
line=1516 msg="DNAT 192.168.11.59:31925>192.168.3.221:1487"
Lookup for next-hop gateway address for reply traffic:
id=20085 trace_id=210 func=vf_ip4_route_input line=1543
msg="find a route: gw-192.168.3.221 via port5"
ACK received:
msg="vd-root received a packet(proto=6,
192.168.3.221:1487->203.160.224.97:80) from port5."
Match existing session in the original direction:
msg="Find an existing session, id-00000e90, original
direction"
Apply source NAT:
line=1502 msg="SNAT 192.168.3.221->192.168.11.59:31925"
Receive data from client:
id=20085 trace_id=212
func=resolve_ip_tuple
_fast
line=2700 msg="vd-root
received a
packet(proto=6,
192.168.3.221:1487>203.160.224.97:80)
from port5."
Match existing session in the
original direction:
01-40002-112804-20101015
115
Packet sniffer
Troubleshooting
line=2727 msg="Find an existing session, id-00000e90,
original direction"
Apply source NAT:
line=1502 msg="SNAT 192.168.3.221->192.168.11.59:31925"
Receive data from server:
line=2700 msg="vd-root received a packet(proto=6,
203.160.224.97:80->192.168.11.59:31925) from port6."
Match existing session in reply direction:
line=2727 msg="Find an existing session, id-00000e90,
reply direction"
Apply destination NAT to inverse source NAT action:
line=1516 msg="DNAT 192.168.11.59:31925>192.168.3.221:1487"
Packet sniffer
The packet sniffer in the FortiGate unit can sniff traffic on a specific Interface or on all
Interfaces. There are 3 different Level of Information, a.k.a. Verbose Levels 1 to 3, where
verbose 1 shows less information and verbose 3 shows the most information.
Verbose levels in detail:
•
1Print header of packets
•
2Print header and data from the IP header of the packets
•
3Print header and data from the Ethernet header of the packets
•
4Print header of packets with interface name
•
5Print header and data from IP of packets with interface name
•
6Print header and data from ethernet of packets with interface
All Packet sniffing commands are in the format:
diagnose sniffer packet <interface> <'filter'> <verbose> <count>
... where...
<interface>
can be an Interface name or “any” for all Interfaces. An interface can be
physical, VLAN, IPsec interfce, Link aggregated or redundant.
<verbose>
the level of verbosity as described above.
<count>
the number of packets the sniffer reads before stopping.
<'filter'>
is a very powerful filter functionality which will be described below.
Simple trace example
In this example, the packet sniffer sniffs three packets of all traffic with verbose level 1 on
internal interface
diagnose sniffer packet internal “none” 1 3
116
01-40002-112804-20101015
Troubleshooting
Packet sniffer
The none variable means no filter applies, 1 means verbose level 1 and 3 means catch 3
packets and stop. The resulting output is
192.168.0.1.22 -> 192.168.0.30.1144: psh 2859918764 ack
1949135261?192.168.0.1.22 -> 192.168.0.30.1144: psh 2859918816 ack
1949135261?192.168.0.30.1144 -> 192.168.0.1.22: ack 2859918884
The sniffer has caught some packets in the middle of a communication. Because the
192.168.0.1 IP address uses port 22 (192.168.0.1.22) this particular sniff is from a SSH
Session.
Simple trace example
In this example, the packet sniffer sniff 3 packets of all traffic with verbose 1evel 1 on
internal interface
The none variable means no filter applies, 1 means verbose level 1 and 3 means catch 3
packets and stop. The resulting output is
192.168.0.30.1156 -> 192.168.0.1.80: syn 2164883624
192.168.0.1.80 -> 192.168.0.30.1156: syn 3792179542 ack 2164883625
192.168.0.30.1156 -> 192.168.0.1.80: ack 3792179543
In this example, the sniffer captures a TCP session being set up. 192.168.0.30 is
attempting to connect to 192.168.0.1 on Port 80 with a SYN and gets a SYN ACK
returned. The session is acknowledged and established after the 3-way TCP handshake.
With information level set to verbose 1, the source and destination IP address is visible, as
well as source and destination port. The corresponding Sequence numbers is also visible.
Note: If you do not enter a <count> value, for example as above, 3, the sniffer will
continue to run until you stop it.
Verbose levels 2 and 3
Verbose level 2 contains much more information; the IP header as with verbose level 1
and the payload of the IP packet itself.
The output of verbose 2 is:
192.168.0.1.22 -> 192.168.0.30.1144: psh 2867817048 ack 1951061933
0x0000
4510 005c 8eb1 4000 4006 2a6b c0a8 0001
E..\..@.@.*k....
0x0010
c0a8 001e 0016 0478 aaef 6a58 744a d7ad
.......x..jXtJ..
0x0020
5018 0b5c 8ab9 0000 9819 880b f465 62a8
P..\.........eb.
0x0030
3eaf 3804 3fee 2555 8deb 24da dd0d c684 >.8.
.%U..$.....
0x0040
08a9 7907 202d 5898 a85c facb 8c0a f9e5 ..y..-X..\......
0x0050
bd9c b649 5318 7fc5 c415 5a59
...IS.....ZY
Verbose level 3 includes the previous information as well as Ethernet (Ether Frame)
information. This is the format that technical support will usually request when attempting
to analyze a problem.
A script is available on the Fortinet Knowledge Base (fgt2eth.pl), which will convert a
captured verbose 3 output, into a file that can be read and decoded by Ethereal.
Trace with filters example
In this example, use the filter option of the sniffer to see the traffic information between two
PCs or a PC and a FortiGate unit. Using the following command:
diagnose sniffer packet internal 'src host 192.168.0.130 and dst
host 192.168.0.1' 1
01-40002-112804-20101015
117
Packet sniffer
Troubleshooting
The resulting output is:
192.168.0.130.3426 -> 192.168.0.1.80: syn 1325244087
192.168.0.1.80 -> 192.168.0.130.3426: syn 3483111189 ack
1325244088?192.168.0.130.3426 -> 192.168.0.1.80: ack 3483111190
192.168.0.130.3426 -> 192.168.0.1.80: psh 1325244088 ack 3483111190
192.168.0.1.80 -> 192.168.0.130.3426: ack 1325244686
192.168.0.130.1035 -> 192.168.0.1.53: udp 26
192.168.0.130.1035 -> 192.168.0.1.53: udp 42?192.168.0.130.1035 ->
192.168.0.1.53: udp 42
192.168.0.130 -> 192.168.0.1: icmp: echo request?192.168.0.130.3426 ->
192.168.0.1.80: psh 1325244686 ack 3483111190
192.168.0.1.80 ->
192.168.0.130.3426: ack 1325244735?192.168.0.130 -> 192.168.0.1: icmp:
echo request
Assuming there is a lot of traffic, this filter command will only display traffic (but all traffic)
from the source IP 192.168.0.130 to the destination IP 192.168.0.1. It will not show traffic
to 192.168.0.130 (for example the ICMP reply) because the command included:
'src host 192.168.0.130 and dst host 192.168.0.1'
Additional information such as ICMP or DNS queries from a PC are included. If you only
require a specific type of traffic, for example, TCP traffic only, you need to change the filter
command as below:
diagnose sniffer packet internal 'src host 192.168.0.130 and dst host
192.168.0.1 and tcp' 1?
The resulting output would be:
192.168.0.130.3569 -> 192.168.0.1.23: syn 1802541497
192.168.0.1.23 -> 192.168.0.130.3569: syn 4238146022 ack 1802541498
192.168.0.130.3569 -> 192.168.0.1.23: ack 4238146023
Though ICMP (ping) was also running, the trace only shows the TCP part. The destination
IP is 192.168.0.1.23, which is IP 192.168.0.1 on port 23 - a Telnet session.
118
01-40002-112804-20101015
Exempted URLs
This chapter describes small parcels of configurations on the FortiGate unit. The
configurations involve practical setups of various features within FortiOS that you can use
to apply to your network.
This chapter is also dynamic, in that it will continue to evolve and grow as configurations
are considered, tested and added.
The examples in this chapter include
•
Exempted URLs
Exempted URLs
With FortiGuard categories, you only need to select the particular categories you wish to
block. However, within those categories, there may be specific sites you still need or want
to access, or certain sites include sub-sites which cause blocks where you don’t need
them. For example, a particular web site may have advertising on it, and you have
enabled blocking of web ads. As such, the web site you want to visit is blocked.
By adding exempted URLs, you can include the site you want to visit to allow it to be
viewed. This is done through the use of local categories and local ratings. This example
describes the steps to create local ratings and local categories.
This configuration involves three steps:
•
Create a local category
•
Add the URLs to the category
•
Enable and set the option for the category in the web filter profile.
Create a local category
First, you need to create a local category. This will be the grouping of URLs that will be
exempted from being blocked by FortiGuard. For this example, add a local category called
“exemptions”.
To create a local category - web-based manager
1 Go to UTM > Web Filter > Local Categories.
2 Enter the category name of Exemptions and select Create New.
To create a local category - CLI
config webfilter ftgd-local-cat
edit exemptions
end
Add URLs to the category
Next, add the URLs that will be included in the new local category called exemptions.
To add web filter URLs for the local category - web-based manager
1 Go to UTM > Web Filter > Local Ratings.
3 Enter the URL, for example www.fortinet.com.
01-40002-112804-20101015
119
Exempted URLs
4 In the Local Categories list, select the blue arrow to expand the list.
5 Select the check box for the category Exemptions.
6 Select OK.
Repeat for each URL you want to include.
To add web filter URLs for the local category - CLI
config webfilter ftgd-local-rating
edit www.fortinet.com
set rating 140
end
Enable the category in web filtering
Note that for the rating, it is a value associated with the FortiGuard filters and categories.
You will need to scroll through the list until you find your custom local category.
With the category and ratings in place, you need to enable the category in the web filter
profile.
To enable the category in the web profile - web-based manager
1 Go to UTM > Profile.
2 Select Create New, or double-click an existing profile.
3 Select the blue arrow for FortiGuard Web Filtering to expand the options.
4 A new option appears in the list called Local Categories. Select the blue arrow to
expand the options.
5 Select the check box next to the newly created category, Exemptions.
6 Select OK.
To enable the category in the web profile - CLI
edit <profile_name>
config ftgd-wf
set enable 140
end
end
Test it
Go to the web site that before was blocked. It will now be available, while others within the
FortiGuard category are not.
120
01-40002-112804-20101015
Concept Example: Small Office
Network Protection
This document describes an example network and firewall configuration for a
small office-home office (SOHO) or a small- to medium-sized business (SMB).
SOHO and SMB networks, in this case, refer to
•
small offices
•
home offices
•
broadband telecommuter sites or large remote access populations
•
branch offices (small- to medium-sized)
•
retail stores
Note: IP addresses and domain names used in this document are examples and are not valid
outside of this example.
This document includes
•
Example small office network
•
First steps
•
Configuring settings for Finance and Engineering departments
•
Configuring settings for the Help Desk department
•
Configuring remote access VPN tunnels
•
Configuring the web server
•
Configuring the email server
•
ISP web site and email hosting
•
Other features and products for SOHO
The Example Corporation is a small software company performing development and
providing customer support. In addition to their internal network of 15 computers, they also
have several employees that work from home all or some of the time.
The Example Corporation requires secure connections for home-based workers. Like
many companies, they rely heavily on email and Internet access to conduct business.
They want a comprehensive security solution to detect and prevent network attacks, block
viruses, and decrease spam. They want to apply different protection settings for different
departments. They also want to integrate web and email servers into the security solution.
The Example Corporation network provides limited functionality for their needs, including:
•
a very basic router to manage the network traffic
•
an email server hosted by the Internet Service Provider (ISP)
•
a web server hosted by the ISP
01-40002-112804-20101015
121
•
client-based antivirus software with no reliable central distribution of updates
•
no secure method of providing remote connections for home-based workers
Network management and protection requirements
The Example Corporation established several goals for planning a network security
solution. Table 7 describes the company’s goals and the FortiGate options that meet them.
Table 7: Company security goals and FortiGate solutions
Security Policy/Goal
FortiGate solution
Protect the internal network from attacks, Enable IPS, antivirus, and spam filters.
intrusions, viruses, and spam.
Automate network protection as much as There are several features to make maintenance
possible to make management simpler
simpler:
• enable automatic daily updates of antivirus and
attack definitions
• enable automatic “push” updates so that Fortinet
updates the virus list when new threats occur
• enable FortiGuard web filtering so that web requests
are automatically filtered based on configured
policies, with no required maintenance
• enable FortiGuard Antispam, an IP address black list
and spam filter service that keeps track of known or
suspected spammers, to automatically block spam
with no required maintenance
Provide secure access for remote
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 142.
Serve the web site and email from a DMZ Place the web and email servers on the DMZ network
to further protect internal data.
and create appropriate policies.
See “Configuring the web server” on page 147.
Block access by all employees to
potentially offensive web content.
Enable FortiGuard web content filtering solution.
See “Configuring web category block settings” on
page 131.
Severely limit web access for certain
employees (help desk) during work
hours.
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 135.
Topology
Figure 27 shows the The Example Corporation network configuration after installation of
the FortiGate-100A.
122
01-40002-112804-20101015
VPN
el
Tun
n
el
n
Tun
VPN
H
19 om
2. e
16 Us
8. er
21 2
.1
2
H
19 om
2. e
16 Us
8. er
90 1
.1
2
Figure 27: SOHO network topology with FortiGate-100A
17 Exte
2.2 rn
0.1 al
20
.14
1
D
10 MZ
.20
.10
W
10 eb
.2 S
0. er
10 ve
.3 r
.1
rs
se
U g 51 0
ri n 1. 10
ee 10 1.
in 1. 10
ng .1 .
E 10 .11
10
rs
se
U k .21 0
es 1 5
D 0 1.
p .1 0
el 11 .1
H 0. .11
1 0
1
E
10 ma
.2 il S
0. e
10 rv
.2 er
rs
se U 10
. 0
ce 01 .2
an .1 01
in 1 1
F 1 1.
.
10 0.1
1
al
ern .1
Int 1.10
.1
10
The following table lists the FortiGate features implemented in the Example Corporation
example network.
01-40002-112804-20101015
123
First steps
System
•
•
•
•
•
•
“Configuring FortiGate network interfaces” on page 124
“Configuring DNS forwarding” on page 126
“Scheduling automatic antivirus and attack definition updates” on page 128
“Setting the time and date” on page 127
“Configuring administrative access and passwords” on page 128
“Registering the FortiGate unit” on page 127
Router
•
“Adding the default route” on page 125
Firewall
•
•
•
“Removing the default firewall policy” on page 126
Adding firewall policies for different addresses and address groups, see
“Configuring firewall policies for Finance and Engineering” on page 134,
“Configuring firewall policies for help desk” on page 140, and “Configuring
firewall policies for the VPN tunnels” on page 145
Adding addresses and address groups, see “Adding the Finance and
Engineering department addresses” on page 130, “Adding the Help Desk
department address” on page 136, “Adding addresses for home-based
workers” on page 142, “Adding the web server address” on page 148, and
“Adding the email server address” on page 152
“Creating a recurring schedule” on page 140
VPN
•
“Configuring remote access VPN tunnels” on page 142 (IPSec)
IPS
•
Antivirus
•
•
•
“Configuring antivirus grayware settings” on page 132
enabling virus scanning (see Configuring protection profiles)
Web Filter
•
•
“Configuring web category block settings” on page 131 (FortiGuard)
“Creating and Configuring URL filters” on page 136
Spam Filter
•
“Configuring FortiGuard spam filter settings” on page 131
•
First steps
First steps includes creating a network plan and configuring the basic FortiGate settings.
•
Configuring FortiGate network interfaces
•
Adding the default route
•
Removing the default firewall policy
•
Configuring DNS forwarding
•
Setting the time and date
•
Registering the FortiGate unit
•
Scheduling automatic antivirus and attack definition updates
•
Configuring administrative access and passwords
Configuring FortiGate network interfaces
The Example Corporation assigns IP addresses to the three FortiGate interfaces to
identify them on their respective networks. It is important to limit administrative access to
maintain security. The Example Corporation configures administrative access for each
interface as follows:
124
Interface
internal
HTTPS for web-based manager access from the internal network, PING for
connectivity troubleshooting, and SSH for secure access to the command line
interface (CLI) from the internal network.
01-40002-112804-20101015
First steps
wan1
HTTPS for remote access to the web-based manager from the Internet.
dmz1
PING access for troubleshooting.
To configure FortiGate network interfaces - web-based manager
2 Select the Internal interface row and select Edit:
Addressing mode
Manual
IP/Netmask
10.11.101.1/255.255.255.0
HTTPS, PING, SSH
3 Select OK.
4 Select the wan1 interface row and select Edit:
Addressing mode
Manual
IP/Netmask
172.20.120.141/255.255.255.0
HTTPS
5 Select OK.
6 Select the dmz1 interface row and select Edit:
Addressing mode
Manual
IP/Netmask
10.20.10.1/255.255.255.0
PING
7 Select OK.
To configure the FortiGate network interfaces - CLI
edit internal
set ip 10.22.101.1 255.255.255.0
set allowaccess ping https ssh
next
edit wan1
set ip 172.20.120.141 255.255.255.0
set allowaccess https
next
edit dmz1
set ip 10.20.10.1 255.255.255.0
set allowaccess ping
end
Adding the default route
The Example Corporation gets the default gateway address from their ISP.
To add the default route - web-based manager
2 Select Create New and enter the following information:
01-40002-112804-20101015
125
First steps
Destination IP/
Mask
0.0.0.0/0.0.0.0
Device
wan1
Gateway
172.20.120.39
Distance
10
3 Select OK.
Note: Entering 0.0.0.0 as the IP and mask represents any IP address.
To add the default route - CLI
edit 1
set device wan1
set distance 10
end
Removing the default firewall policy
The FortiGate-100A comes preconfigured with a default internal -> wan1 firewall policy
which allows any type of traffic from any internal source to connect to the Internet at any
time. Remove this policy to simplify policy configuration and increase security. By deleting
this policy you ensure that any traffic which does not match a configured policy is rejected,
rather than possibly matching the default policy and passing through the FortiGate unit.
To remove the default firewall policy
2 Expand the internal -> wan1 entry.
3 Select policy 1 (Source: All, Dest: All) and select Delete.
To remove the default firewall policy using the CLI
delete 1
end
Configuring DNS forwarding
After deleting the default firewall policy, configure DNS forwarding from the internal
interface to allow DNS requests and replies to pass through the firewall. DNS server
addresses are usually provided by the ISP.
To configure DNS forwarding - web-based manager
1 Go to System > Network > Options.
2 For DNS Settings, enter the primary and secondary DNS server addresses:
Primary DNS Server
239.120.20.1
Secondary DNS Server
239.10.30.31
3 Select OK
126
01-40002-112804-20101015
First steps
4 Got to Network > Interface.
5 Select the Internal interface row and select Edit.
6 Select Enable DNS Query and set it to Recursive.
7 Select OK.
To configure DNS forwarding - CLI
config system dns
set autosvr disable
set primary 239.120.20.1
set secondary 239.10.30.31
end
edit internal
set dns-query recursive
end
Setting the time and date
Time can be set manually or updated automatically using an NTP server. The Example
Corporation sets the time manually.
To set the time and date - web-based manager
1 Go to System > Status and select the Change link for the System Time.
2 Select the correct time zone for your location.
3 Select Set Time and set the current time and date.
4 Select OK.
To configure the time zone - CLI
config system global
set timezone 04
end
To configure the time and date - CLI
execute date <2010-03-31>
execute time <21:12:00>
Registering the FortiGate unit
The FortiGate-100A must be registered with Fortinet to receive automatic scheduled
updates and push updates. Enter the support contract number during the registration
process.
Begin by logging in to the web-based manager.
To register the FortiGate unit - web-based manager
1 Go to System > Status and get the product serial number from the Unit Information
section or check the label on the bottom of the FortiGate unit.
2 Go to http://support.fortinet.com and click Product Registration.
3 Fill in all the required fields including the product model and serial number.
4 Select Finish.
01-40002-112804-20101015
127
First steps
Scheduling automatic antivirus and attack definition updates
The Example Corporation schedules daily antivirus and attack definition updates at 5:30
am. They also enable push updates so that critical antivirus or attack definitions are
automatically delivered to the FortiGate-100A whenever a threat is imminent.
FortiProtect Distribution Network (FDN) services provide all antivirus and attack updates
and information. A virus encyclopedia and an attack encyclopedia with useful protection
suggestions, as well as a daily newsletter, are available on the web site at
http://www.fortiguard.com.
To check server access and enable daily and push updates - web-based manager
1 Go to System > Maintenance > FortiGuard.
2 Expand the Antivirus and IPS Options blue arrow.
3 Select Allow Push Update.
4 Select Scheduled Update.
5 Select Daily and select 5 for the hour.
6 Select Apply.
Note: If you want to set the update time to something other than the top of the hour, you
must use the CLI command.
To check server access and enable daily and push updates - CLI
config system autoupdate push-update
set status enable
end
config system autoupdate schedule
set frequency daily
set status enable
set time 05:30
end
Configuring administrative access and passwords
The Example Corporation adds an administrator account and password using a new readonly access profile. This read-only administrator monitors network activity and views
settings. They can notify the admin administrator if changes are required or a critical
situation occurs. The read-only administrator can only access the FortiGate web-based
manager from their own computer or the lab computer.
The admin administrator gets a new password (default is a blank password).
To configure a new access profile and administrator account - web-based manager
1 Go to System > Admin > Admin Profile.
3 Enter admin_monitor as the Profile Name.
4 Select Read Only.
5 Select OK.
6 Go to System > Admin > Administrators.
7 Select Create New and enter or select the following settings:
128
01-40002-112804-20101015
First steps
Administrator
admin_2
Password
<psswrd>
Confirm Password
<psswrd>
Trusted Host #1
10.11.101.60 / 255.255.255.255 (administrator’s computer)
Trusted Host #2
10.11.101.51 / 255.255.255.255 (lab computer)
Access Profile
admin_monitor
8 Select OK.
To configure a new access profile and administrator account - CLI
config system accprofile
edit admin_monitor
set admingrp read
set authgrp read
set avgrp read
set fwgrp read
set ipsgrp read
set loggrp read
set mntgrp read
set netgrp read
set routegrp read
set spamgrp read
set sysgrp read
set updategrp read
set vpngrp read
set webgrp read
end
config system admin
edit admin2
set accprofile admin_monitor
set password <psswrd>
set trusthost1 192.168.100.60 255.255.255.255
set trusthost2 192.168.100.51 255.255.255.255
end
To change the admin password - web-based manager
1 Go to System > Admin >
Administrators.
2 Select the admin name and
select Change Password.
3 Enter the new password and
enter it again to confirm.
4 Select OK.
To change the admin password CLI
config system admin
01-40002-112804-20101015
129
edit admin
set password <psswrd>
end
Goals
•
•
•
Provide control of web access. Tasks include:
•
•
Configuring web category block settings
Protect the network from spam and outside threats. Tasks include:
•
Configuring FortiGuard spam filter settings
•
Configuring a corporate set of UTM profiles
Control traffic and maintain security. Tasks include:
•
Configuring firewall policies for Finance and Engineering
Firewall addresses and address groups are used to configure connections to and through
the FortiGate-100A.Each address represents a component of the network that requires
configuration with policies.
The Example Corporation adds address ranges to the firewall for Finance and
Engineering so they can be included in firewall policies. The two address ranges are
included in an address group to further simplify policy configuration.
To add address ranges for Finance and Engineering - web-based manager
Address Name
Finance
Type
Subnet / IP Range
Subnet / IP Range
10.11.101.10 - 10.11.101.20
Interface
Internal
3 Select OK.
4 Repeat to add an address called Eng with the IP Range 10.11.101.51–10.11.101.99.
To add address ranges for Finance and Engineering - CLI
edit Finance
set type iprange
set start-ip 192.168.100.10
set end-ip 192.168.100.20
next
edit Eng
set type iprange
set start-ip 192.168.100.51
set end-ip 192.168.100.99
end
130
01-40002-112804-20101015
To include the Finance and Eng addresses in an address group - web-based
manager
1 Go to Firewall > Address > Group.
3 Enter FinEng as the Group Name.
4 Use the down arrow button to move the Finance and Eng addresses into the Members
box.
5 Select OK.
To include the Finance and Eng addresses in an address group - CLI
config firewall addrgrp
edit FinEng
set member Finance Eng
end
Configuring web category block settings
The Example Corporation employs the FortiGuard web filtering service to block access by
all employees to offensive web sites. After ordering the FortiGuard service, licensing
information is automatically obtained from the server.
To enable the FortiGuard web filtering service - web-based manager
2 Expand Web Filtering and Email Filtering Options.
3 Select Test Availability to ensure the FortiGate unit can access the FortiGuard server.
After a moment, the FDN Status should change from a red/yellow flashing indicator to a
solid green.
4 Select Enable CacheTTL and enter 3600 in the field.
5 Select Apply.
Note: Enabling cache means web site ratings are stored in memory so that the FortiGuard
server need not be contacted each time an often-accessed site is requested.
To enable FortiGuard web filtering - CLI
config system fortiguard
set webfilter-cache enable
set webfilter-cache-ttl 3600
end
Configuring FortiGuard spam filter settings
The Example Corporation configures spam blocking using FortiGuard, the IP address
black list and spam filtering service from Fortinet. FortiGuard works much the same as
real-time blackhole lists (RBLs). The FortiGate unit accesses the FortiGuard server,
compares addresses against the black list, applies proprietary filters for spam and tags,
passes or blocks potential spam messages.
To enable the FortiGuard spam filtering service - web-based manager
2 Expand Web Filtering and Email Filtering Options.
01-40002-112804-20101015
131
3 Select Enable CacheTTL and enter 3600 in the field.
4 Select Apply.
Note: Marking email as spam allows end-users to create custom filters to block tagged
spam using the keyword.
To configure the FortiGuard RBL spam filter settings - CLI
config system fortiguard
set antispam-cache enable
set antispam-cache-ttl 3600
end
Configuring antivirus grayware settings
The Example Corporation blocks known grayware programs from being downloaded by
employees. Grayware programs are unsolicited commercial software programs that get
installed on computers, often without the user’s consent or knowledge. The grayware
category list and contents are added and updated whenever the FortiGate unit receives a
virus update.
To enable grayware blocking - web-based manager
1 Go to UTM > Antivirus > Virus Database.
2 Select Enable Grayware Detection.
3 Select Apply.
To enable grayware blocking - CLI
config antivirus settings
set grayware enable
end
Configuring a corporate set of UTM profiles
The Example Corporation configures a set of firewall UTM profiles called standard_profile
to apply to the Finance and Engineering departments as well as the home-based workers.
For detailed information on creating and configuring UTM profiles, see the FortiGate UTM
Guide.
With UTM profiles, the Example Corporation configures each UTM profile for antivirus,
web filtering, email filtering and IPS protection
Antivirus UTM profile
To create and configure a antivirus profile - web-based manager
1 Go to UTM > Antivirus > Profile.
3 Enter standard_profile as the Profile Name.
4 For Virus Scan select HTTP, FTP, IMAP, POP3, and SMTP.
5 Select OK.
To create and configure a antivirus profile - CLI
config antivirus profile
132
01-40002-112804-20101015
edit standard_profile
config http
set options scan
end
config ftp
set options scan
end
config imap
set options scan
end
config pop3
set options scan
end
config smtp
set options scan
end
end
Web filter UTM profile
The Example Corporation orders FortiGuard for web filtering. FortiGuard gives
administrators the option of allowing, blocking, or monitoring web sites in 77 categories.
Categories are divided into groups to make configuration easier. By default, all categories
are set to allow. The Example Corporation configures selected categories as follows:
To create and configure a web filter profile - web-based manager
1 Go to UTM > Web Filter > Profile.
4 Select the HTTP option.
5 Select the following and select OK.
Potentially Liable
Block
Controversial
Adult Materials
Block
Extremist Groups
Block
Pornography
Block
Potentially Non-productive
Games
Block
Potential Bandwidth Consuming
Block
Potentially Security Violating
Block
General Interest
Job Search
Block
Social Networking
Block
Shopping and Auction
Block
To create and configure a web filter profile - CLI
config ftgd-wf
set deny g01 8 12 14 20 g04 g05 34 37 42
01-40002-112804-20101015
133
end
config http
set options fortiguard-wf
end
end
Email filter UTM profile
To create and configure a email filter profile - web-based manager
1 Go to UTM > Antivirus > Profile.
4 For the IP Address BWL select the SMTP check box.
5 For the Email Address BWL Check, select the SMTP check box.
6 Select OK.
To create and configure a email filter profile - CLI
config spamfilter profile
config smtp
set options spamemailbwl
set options spamipbwl
end
end
Configuring firewall policies for Finance and Engineering
By configuring firewall policies for specific users you can grant different levels of access to
different groups as required.
Important points for firewall policy configuration
•
Policies are organized according to the direction of traffic from the originator of a
request to the receiver of the request. For example, even though viruses may come
from the external interface, the request for email or a web page comes from the
internal interface. Therefore the policy protecting the network would be an internal ->
wan1 policy.
•
Policies are matched to traffic in the order they appear in the policy list (not by ID
number)
•
Policies should go from most exclusive to most inclusive so that the proper policies are
matched. As a simple example, a policy blocking internal to external HTTP access for
some employees should come before a policy that allows HTTP access for everyone.
•
Each interface can benefit from layered security created through multiple policies
Note: The following policy is an internal to wan1 policy which uses the standard_profile
protection profile to provide antivirus, web category blocking, and FortiGuard spam
filtering.
134
01-40002-112804-20101015
To configure the Finance and Engineering firewall policy - web-based manager
3 Enter or select the following settings:
Source Interface / Zone
internal
Source Address
FinEng
Destination Interface / Zone
wan1
Destination Address
All
Schedule
Always
Service
ANY
Action
ACCEPT
4 Select Enable NAT.
5 Select UTM and select the Protocol Options of default.
6 Select Enable Antivirus and select standard_profile.
7 Select Enable IPS and select all_default.
8 Select Enable Web Filter and select standard_profile.
9 Select Enable Email Filter and select standard_profile.
10 Select OK.
To configure the Finance and Engineering firewall policy - CLI
edit 1
set action accept
set dstaddr all
set dstintf wan1
set schedule always
set service ANY
set srcaddr FinEng
set nat enable
set utm-status enable
set profile-protocol-options default
set av-profile standard_profile
set ips-sensor all_default
set webfilter-profile standard_profile
set spamfilter-profile standard_profile
end
Because of a high turnover rate and a need for increased productivity in the Help Desk
department, The Example Corporation implements very strict web access settings. Help
desk employees can only access four web sites that they require for their work. During
lunch hours, help desk employees have greater access to the web but are still blocked
from using Instant Messaging and Peer-to-Peer programs and accessing objectionable
web sites.
01-40002-112804-20101015
135
Goals
•
•
Provide complete control of web access. Tasks include:
•
•
Creating and Configuring URL filters
Enable greater access at certain times. Tasks include:
•
•
Creating a recurring schedule
•
Configuring firewall policies for help desk
The Example Corporation adds an address range for the Help Desk department so it can
be included in a separate firewall policy.
To add the help desk department address - web-based manager
Address Name
Help_Desk
Type
Subnet / IP Range
Subnet / IP Range
10.11.101.21 - 10.11.101.50
Interface
Any
3 Select OK.
Adding the help desk department address - CLI
edit Help_Desk
set type iprange
set start-ip 10.11.101.21
set end-ip 10.11.101.50
end
Creating and Configuring URL filters
Antivirus, spam filter, and web filter are global settings previously configured for the
Finance and Engineering set up. In this step The Example Corporation adds additional
web filter settings to block web access with the exception of four required web sites. Web
URL filters are then enabled in the web URL policy for help desk employees.
Before you can configure filters, you must first create a list to place the filters in.
To create a filter list for blocked URLs - web-based manager
1 Go to UTM > Web Filter > URL Filter.
3 Enter Example_URL_Filter as the name.
4 Select OK.
To create a filter list for blocked URLs - CLI
config webfilter urlfilter
136
01-40002-112804-20101015
edit # (select any unused number)
set name Example_URL_Filter
end
To configure a URL block - web-based manager
2 Select Example_URL_Filter and select Edit.
4 Enter the following settings:
URL
.*
Type
Regex
Action
Block
5 Select Enable.
6 Select OK.
This pattern blocks all web sites.
To configure URL block - CLI
edit #
config entries
edit #
set action block
set type regex
set status enable
end
end
Note: The edit command will only accept a number. Type edit ? for a list of URL filter
lists and their corresponding number
To configure a filter to exempt URLs - web-based manager
2 Select Example_URL_Filter and select Edit.
4 Enter the following settings:
URL
www.example.com
Type
Simple
Action
Exempt
5 Select Enable.
6 Select OK.
7 Repeat for each of the following URLs:
• intranet.example.com
• www.dictionary.com
• www.ExampleReferenceSite.com
01-40002-112804-20101015
137
To configure URL exempt - CLI
edit #
config entries
edit www.example.com
set action exempt
set type simple
set status enable
next
edit intranet.example.com
set action exempt
set type simple
set status enable
next
edit www.dictionary.com
set action exempt
set type simple
set status enable
next
edit www.ExampleReferenceSite.com
set action exempt
set type simple
set status enable
end
Web filter UTM profile
With the URL filtered defined, add a web filter profile to be used in the firewall policies.
To create and configure a web filter profile - web-based manager
1 Go to UTM > Web Filter > Profile.
3 Enter help_desk_work as the Profile Name.
4 For Web URL Filter, select the HTTP option, and select the help_desk_work.
5 Select OK.
To create and configure a web filter profile - CLI
edit help_desk_work
config http
set options urlfilter
end
config web
set urlfilter-table 1
end
end
138
01-40002-112804-20101015
Ordering the filtered URLs
While the list includes all the exempt URLs the help desk needs with a global block filter,
there is a problem. Since the URL Filter list is parsed from top to bottom, and the block
filter appears first, every URL will match the block filter and parsing will stop. The exempt
URL statements that follow will never be referenced. To fix this problem, reorder the list to
put the global block filter at the end.
To order the filter URLs - web-based manager
1 Select the Move To icon for the “.*” URL.
2 Select After and type www.ExampleReferenceSite.com into the URL field.
3 Select OK.
To order the filtered URLs - CLI
move # after #
end
Note: The move command will only accept a number. Type move ? for a list of URL filter
lists and their corresponding numbers.
Application control or IM and P2P
By creating an application control profile, you can include the IM/P2P applications that
need to be blocked from the help desk users.
To configure the application control profile - web-based manager
1 Go to UTM > Application Control > Profile.
3 Enter the profile name of IM_P2P.
4 Select OK.
5 Select the new group name and select Edit.
7 In the Category list, select IM.
8 Set the Action to Block and Select OK.
9 Repeat the above steps to add an entry for P2P.
To configure the application control profile - CLI
config application list
edit IM_P2P
config entries
edit 1
set category 1
next
edit 2
set category 2
end
end
01-40002-112804-20101015
139
Creating a recurring schedule
The Example Corporation uses this schedule in a firewall policy for help desk employees
to allow greater web access during lunch hours. The schedule is in effect Monday through
Saturday from 11:45am to 2pm.
To create a recurring schedule - web-based manager
1 Go to Firewall > Schedule > Recurring.
3 Enter lunch as the name for the schedule.
4 Select the days Mon through Fri.
5 Set the Start time as 11:45 and set the Stop time as 14:00.
6 Select OK.
To create a recurring schedule - CLI
edit lunch
set start 11:45
set end 14:00
end
Configuring firewall policies for help desk
The Example Corporation configures two firewall policies for the help desk employees, to
implement the web block settings and use the schedule for lunch hour web access
created above. For tips on firewall policies see “Important points for firewall policy
configuration” on page 134.
The first policy is an internal -> wan1 policy which uses the help_desk protection profile to
block most web access during working hours. The second policy goes above the first
policy and uses the lunch schedule and the help_desk_lunch protection profile to allow
web access at lunch.
To create and insert a policy for the help desk - web-based manager
2 Expand the internal -> wan1 entry and select the Insert Policy before icon beside
policy 1.
internal
Source Address
Help_Desk
wan1
Destination Address
All
Schedule
Always
Service
ANY
Action
ACCEPT
140
01-40002-112804-20101015
10 Select Enable Application Control and select IM_P2P.
11 Select OK.
12 Select the policy and select Move.
13 Select Before and enter Policy ID 2.
Note: The FortiGate unit checks for matching policies in the order they appear in the list
(not by policy ID number). For the ‘lunch’ policy to work, it must go before the policy using
the help-desk protection profile (above).
internal
Source Address
Help_Desk
wan1
Destination Address
All
Schedule
lunch
Service
ANY
Action
ACCEPT
22 Select OK.
Configuring firewall policies for help desk - CLI
edit 2
set action accept
set dstaddr all
set dstintf wan1
set profile-status enable
set schedule always
set service ANY
set srcaddr Help_Desk
set nat enable
01-40002-112804-20101015
141
set application-list IM_P2P
next
edit 3
set action accept
set dstaddr all
set dstintf wan1
set profile-status enable
set schedule lunch
set service ANY
set srcaddr Help_Desk
set nat enable
next
move 2 before 1
move 3 before 2
end
Goals
•
•
Configure a secure connection for home-based workers. Tasks include:
•
Adding addresses for home-based workers
•
Configuring the FortiGate end of the IPSec VPN tunnels
•
Configuring firewall policies for the VPN tunnels
Adding addresses for home-based workers
To support VPN connections to the internal network, add a firewall address for the The
Example Corporation internal network.
To support a VPN connection for a home-based employee with a static IP address, add a
firewall address for this employee.
The Example Corporation uses a Dynamic Domain Name Server (DDNS) VPN
configuration for a home-based employee with a dynamic IP address. The DDNS VPN
uses the All firewall address.
To add address for home-based workers - web-based manager
142
Address Name
Example_Network
Type
Subnet / IP Range
01-40002-112804-20101015
Subnet / IP Range
192.168.100.0
Interface
Any
3 Select OK.
Address Name
Home_User_1
Type
Subnet / IP Range
Subnet / IP Range
220.100.65.98
Interface
Any
5 Select OK.
To add addresses for home-based workers - CLI
edit Example_Network
set subnet 192.168.100.0 255.255.255.0
next
edit Home_User_1
set subnet 220.100.65.98 255.255.255.0
end
Configuring the FortiGate end of the IPSec VPN tunnels
The Example Corporation uses AutoIKE preshared keys to establish IPSec VPN tunnels
between the internal network and the remote workers.
Home_User_1 has a static IP address with a straightforward configuration.
Home_User_2 has a dynamic IP address and therefore some preparation is required. The
Example Corporation will register this home-based worker with a domain name. The
DDNS servers remap the IP address to the domain name whenever Home_User_2 gets a
new IP address assigned by their ISP.
The Example Corporation home-based workers use FortiClient software for VPN
configuration.
To configure IPSec phase 1 - web-based manager
1 Go to VPN > IPSEC > Auto Key (IKE).
2 Select Create Phase 1.
3 Enter or select the following settings for Home_User_1:
Name
Home1 (The name for the peer that connects to the The Example
Corporation network.)
Remote Gateway
Static IP Address
IP Address
220.100.65.98
Local Interface
wan1
Mode
Main (ID protection)
Note: The VPN peers must use the same mode.
Authentication
Method
Preshared Key
01-40002-112804-20101015
143
Pre-shared Key
ke8S5hOqpG73Lz4
Note: The key must contain at least 6 printable characters and should only
be known by network administrators. For optimum protection against
currently known attacks, the key should consist of a minimum of 16
randomly chosen alphanumeric characters. The VPN peers must use the
same preshared key.
Peer options
Accept any peer ID
4 Select OK.
6 Enter or select the following settings for Home_User_2:
Name
Home2 (The name for the peer that connects to the The Example
Corporation network.)
Remote Gateway Dynamic DNS
Dynamic DNS
example.net
Local Interface
wan1
Mode
Main (ID protection)
Note: The VPN peers must use the same mode.
Authentication
Method
Preshared Key
Pre-shared Key
GT3wlf76FKN5f43U
Note: The key must contain at least 6 printable characters and should only
be known by network administrators. For optimum protection against
currently known attacks, the key should consist of a minimum of 16
randomly chosen alphanumeric characters. The VPN peers must use the
same preshared key.
Peer options
Accept any peer ID
7 Select OK.
Note: Both ends (peers) of the VPN tunnel must use the same mode and authentication
method.
To configure IPSec phase 1 - CLI
config vpn ipsec phase1
edit Home1
set type static
set interface wan1
set authmethod psk
set psksecret ke8S5hOqpG73Lz4
set remote-gw 220.100.65.98
set peertype any
next
edit Home2
set
set
set
set
set
set
type ddns
interface wan1
authmethod psk
psksecret GT3wlf76FKN5f43U
remotewgw-ddns example.net
peertype any
end
144
01-40002-112804-20101015
To configure IPSec phase 2
1 Go to VPN > IPSEC > Auto Key (IKE).
Name
Home1_Tunnel
Phase 1
Home1
4 Select OK.
Name
Home2_Tunnel
Phase 1
Home2
7 Select OK.
To configure IPSec phase 2 using the CLI
edit Home1_Tunnel
set phase1name Home1
next
edit Home2_Tunnel
set phase1name Home2
end
Configuring firewall policies for the VPN tunnels
The Example Corporation configures specific policies for each home-based worker to
ensure secure communication between the home-based worker and the internal network.
To configure firewall policies for the VPN tunnels - web-based manager
2 Select Create New and enter or select the following settings for Home_User_1:
internal
Source Address
Example_Network
wan1
Destination Address
Home_User_1
Schedule
Always
Service
ANY
Action
IPSEC
VPN Tunnel
Home1
Allow Inbound
yes
Allow outbound
yes
Inbound NAT
yes
Outbound NAT
no
01-40002-112804-20101015
145
8 Select OK
9 Select Create New and enter or select the following settings for Home_User_2:
internal
Source Address
Example_Network
wan1
Destination Address
All
Schedule
Always
Service
ANY
Action
IPSEC
VPN Tunnel
Home2_Tunnel
Allow Inbound
yes
Allow outbound
yes
Inbound NAT
yes
Outbound NAT
no
15 Select OK
To configure firewall policies for the VPN tunnels - CLI
edit 5
set dstintf wan1
set srcaddr Example_Network
set dstaddr Home_User_1
set action ipsec
set schedule Always
set service ANY
set inbound enable
set outbound enable
set natinbound enable
set vpntunnel Home1
next
edit 6
146
01-40002-112804-20101015
set
set
set
set
set
set
set
set
set
set
set
set
set
set
set
set
set
end
srcintf internal
dstintf wan1
srcaddr Example_Network
dstaddr All
action ipsec
schedule Always
service ANY
inbound enable
outbound enable
natinbound enable
vpntunnel Home2
utm-status enable
profile-protocol-options default
av-profile standard_profile
ips-sensor all_default
webfilter-profile standard_profile
spamfilter-profile standard_profile
Configuring the FortiClient end of the IPSec VPN tunnels
Fortinet has a complete range of network security products. FortiClient software is a
secure remote access client for Windows computers. Home-based workers can use
FortiClient to establish VPN connections with remote networks. For more information
about installing and configuring FortiClient please see the FortiClient Installation Guide.
Note: The specific configuration given in this example will only function with licensed copies
of the FortiClient software. The default encryption and authentication types on the FortiGate
unit are not available on the FortiClient Demo software.
To configure FortiClient for Home_User_1 and Home_User_2 - web-based manager
1 Open the FortiClient software on Home_User_1’s computer.
2 Go to VPN > Connections.
3 Select Add.
4 Enter the following information:
Connection Name
Home1_home (A descriptive name for the connection.)
VPN Type
Manual IPSec
Remote Gateway
172.10.120.141 (The FortiGate external interface IP address.)
Remote Network
10.11.101.0 / 255.255.255.0 The Example Corporation internal
network address and netmask.)
Authentication method Preshared Key
Preshared key
ke8S5hOqpG73Lz4 (The preshared key entered in phase 1.)
5 Select OK.
6 Repeat on Home_User_2’s computer for Home_User_2.
Goals
•
Host the web server on a separate but secure DMZ network
01-40002-112804-20101015
147
•
Hide the internal IP address of the web server. Tasks include:
•
•
Configuring the FortiGate unit with a virtual IP
•
Adding the web server address
•
Alternately, The Example Corporation could have their web server hosted by an ISP. See
“ISP web site and email hosting” on page 155.
With the web server located on the DMZ interface, The Example Corporation configures a
virtual IP (VIP) address so that incoming requests for the web site are routed correctly.
The virtual IP can be included later in wan1 -> dmz1 firewall policies.
To configure the FortiGate unit with a virtual IP - web-based manager
1 Go to Firewall > Virtual IP > Virtual IP.
Name
Web_Server_VIP
External Interface
wan1
Type
Static NAT
External IP Address/ Range
172.20.120.141
Mapped IP Address/ Range
10.20.10.3
3 Select OK.
To configure a virtual IP - CLI
config firewall vip
edit Web_Server_VIP
set extintf wan1
set extip 172.20.120.141
end
Adding the web server address
The Example Corporation adds the web server address to the firewall so it can be
included later in firewall policies.
To add the web server address - web-based manager
Address Name
Web_Server
Type
Subnet/ IP Range
Subnet/ IP Range
10.20.10.3/255.255.255.0
Interface
Any
3 Select OK.
148
01-40002-112804-20101015
To add the web server address - CLI
edit Web_Server
set subnet 10.20.10.3 255.255.255.0
end
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
wan1
Source Address
All
dmz1
Destination Address
Web_Server_VIP
Schedule
Always
Service
HTTP
Action
ACCEPT
8 Select OK.
To add a policy for web server access - CLI
edit 7
set action accept
set schedule always
set service HTTP
set srcaddr all
set srcintf wan1
set dstaddr Web_Server_VIP
set dstintf dmz1
end
01-40002-112804-20101015
149
dmz1 -> wan1 policies
The Example Corporation does not require any dmz1 -> wan1 policies since there is no
reason for the server to initiate requests to the external interface.
dmz1 -> internal policies
The Example Corporation does not require any dmz1 -> internal policies since there is no
reason for the server to initiate requests to the internal interface.
internal -> dmz1 policies
Add a policy for the web developer to upload updates web site to the web server using
FTP.
To add the web master address to the firewall - web-based manager
Address Name
Web_Master_J
Type
Subnet/ IP Range
Subnet/ IP Range
10.11.101.63/255.255.255.0
Interface
Any
3 Select OK.
To add the web master address to the firewall - CLI
edit Web_Master_J
set subnet 10.11.101.63 255.255.255.0
end
To add a policy for web master access to the web server - web-based manager
1 Go to Firewall > Policy.
internal
Source Address
Web_Master_J
dmz1
Destination Address
Web_Server
Schedule
Always
Service
FTP
Action
ACCEPT
8 Select OK.
150
01-40002-112804-20101015
To add a policy for web master access to the web server - CLI
edit 8
set action accept
set dstaddr Web_Server
set dstintf dmz1
set schedule always
set service FTP
set srcaddr Web_Master_J
end
Goals
•
Host the email server on a separate but secure network
•
Hide the internal IP addresses of the servers. Tasks include:
•
•
•
Adding the email server address
•
Configuring firewall policies for the email server
Alternately, The Example Corporation could have their email server hosted by an ISP. See
“ISP web site and email hosting” on page 155.
With the email server on the DMZ network, The Example Corporation uses a virtual IP
(VIP) address so that incoming email requests are routed correctly. The Example
Corporation uses the IP address of the FortiGate wan1 interface for email and any SMTP
or POP3 traffic is forwarded to the email server on the DMZ. The virtual IP can be included
later in wan1 -> dmz1 firewall policies.
To configure a virtual IP - web-based manager
1 Go to Firewall > Virtual IP > Virtual IP.
Name
Email_Server_VIP
External Interface
wan1
Type
Static NAT
External IP Address/ Range
172.20.120.141
Mapped IP address/ Range
10.20.10.2
3 Select OK.
01-40002-112804-20101015
151
To configure a virtual IP - CLI
config firewall vip
edit Email_Server_VIP
set extintf wan1
set extip 172.20.120.141
end
The Example Corporation adds the email server address to the firewall so it can be
included later in firewall policies.
To add the email server address to the firewall - web-based manager
Address Name
Email_Server
Type
Subnet/ IP Range
Subnet/ IP Range
10.10.10.3/255.255.255.0
Interface
Any
3 Select OK.
To add the email server address to the firewall - CLI
edit Email_Server
set subnet 10.20.10.3 255.255.255.0
end
Configuring firewall policies for the email server
Add and configure firewall policies to allow the email servers to properly handle emails.
dmz1 -> wan1 policies
Add a firewall policy to allow the email server to forward messages to external mail
servers.
To add a dmz1 -> wan1 firewall policy - web-based manager
152
dmz1
Source Address
Email_Server
wan1
Destination Address
All
Schedule
Always
Service
SMTP
Action
ACCEPT
01-40002-112804-20101015
8 Select OK.
To add a dmz1 -> wan1 firewall policy- CLI
edit 9
set action accept
set dstaddr all
set dstintf wan1
set schedule always
set service SMTP
set srcaddr Email_Server
set srcintf dmz1
end
wan1 -> dmz1 policies
Add a policy to allow Internet email servers to forward messages to the email server.
To add a wan1 -> dmz1 firewall policy - web-based manager
wan1
Source Address
All
dmz1
Destination Address
Email_Server_VIP
Schedule
Always
Service
SMTP
Action
ACCEPT
8 Select OK.
01-40002-112804-20101015
153
To add a wan1 -> dmz1 firewall policy - CLI
edit 10
set action accept
set srcintf wan1
set srcaddr all
set dstintf dmz1
set dstaddr Email_Server_VIP
set schedule always
set service SMTP
end
dmz1 -> internal policies
The Example Corporation does not require any dmz -> internal policies since there is no
reason for the server to initiate requests to the internal network.
internal -> dmz1 policies
The Example Corporation needs to add two internal -> dmz1 policies. One policy for
internal users to send outgoing messages to the server (SMTP) and a second policy for
internal users to read incoming mail (POP3).
To add internal -> dmz1 firewall policies - web-based manager
internal
Source Address
All
dmz1
Destination Address
Email_Server
Schedule
Always
Service
SMTP
Action
ACCEPT
8 Select OK.
154
internal
Source Address
All
01-40002-112804-20101015
dmz1
Destination Address
Email_Server
Schedule
Always
Service
POP3
Action
ACCEPT
15 Select OK.
To add internal -> dmz1 firewall policies - CLI
edit 11
set action accept
set dstaddr Email_Server
set dstintf dmz1
set schedule always
set service SMTP
set srcaddr all
set
set
set
set
set
set
utm-status enable
next
edit 12
set action accept
set dstaddr Email_Server
set dstintf dmz1
set schedule always
set service POP3
set srcaddr all
set
set
set
set
set
set
utm-status enable
end
Small companies such as The Example Corporation often find it more convenient and less
costly to have their email and web servers hosted by an ISP. This scenario would change
the The Example Corporation example in the following ways:
•
no need to set up a separate DMZ network
01-40002-112804-20101015
155
The Example Corporation internal network configuration
•
no need to create policies for external access to the web or email servers
•
add an internal -> wan1 firewall policy for the web master to upload web site updates
via FTP
•
add an internal -> wan1 POP3 firewall policy so that users can use POP3 to download
email
•
add an internal -> wan1 SMTP firewall policy so that users can use SMTP to send
email
The Example Corporation internal network configuration
The Example Corporation internal network only requires a few changes to individual
computers to route all traffic correctly through the FortiGate-100A.
•
set the IP addresses within the prescribed ranges for each computer on the network
(see Figure 27 on page 123)
•
set the default gateway to the IP address of the FortiGate internal interface for each
computer on the network
•
set the DNS server to the IP address of the FortiGate internal interface for each
computer on the network
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:
156
•
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
01-40002-112804-20101015
157
01-40002-112804-20101015
158
01-40002-112804-20101015
Concept Example: Library Network
Protection
Located in a large city, the library system is anchored by a main downtown location
serving most of the population, with a dozen branches spread throughout the city. Each
branch is wired to the Internet but none are linked with each other by dedicated
connections.
Current topology and security concerns
Each office connects to the Internet with no standard access policy or centralized
management and monitoring.
The library system does not log Internet traffic and does not have the means to do so on a
system-wide basis. In the event of legal action involving network activity, the library
system will need this information to protect itself.
The branches currently communicate with the main office through the Internet with no
encryption. This is of particular concern because all staff members access the central
email server in the main office. Email sent to or from branch office staff could be
intercepted.
Both the main and branch offices are protected from the Internet by firewalls. This
protection is limited to defending against unauthorized intrusion. No virus, worm, phishing,
or spyware defences protect the network, resulting in computer downtime when an
infection strikes.
Like the branches, the main office is protected by a single firewall device connected to the
Internet. Should this device fail, connectivity will be lost. The library system’s web page
and catalog are mission critical applications and access would be better protected by
redundant hardware.
The internal network at each location has staff computers and public access terminals
connected together. Concerns have been raised over possible vulnerabilities involving
staff computers and public terminals sharing the same network.
Budgetary constraints limit the number of public access terminals the library can provide.
With the popularity of wifi enabled laptops, the addition of a wireless access point is an
economical way to allow library patrons to access the Internet using their own equipment.
Efficient use of the library’s limited public access terminals and bandwidth can be
compromised by the installation and use of instant messaging and peer to peer file sharing
applications.
Use of library resources to browse inappropriate content is a problem. These activities are
prohibited by library policies, but there is no technical means of enforcement, leaving it to
the staff to monitor usage as best they can.
01-40002-112804-20101015
159
Figure 28: The library system’s current network topology
Branch configuration
(only one branch shown)
P
ub
lic
te
rm
in
h
nc
ra
B
al
s
f
af
st
Fir
ew
al l
C
at
al
og
ac
Main office configuration
ce
ss
te
rm
al
s
Z
lic
fic
of
al
f
af
in
st
rm
te
e
s
M
se a
rv i l
er
n
ub
ai
P
M
W
se e
rv b
er C
a
se ta
rv log
er
C
DM
at
a
te log
rm a
in cc
al es
s s
in
Fir
ew
al l
Library requirements
•
VPN to secure all traffic between main and branch offices.
•
Public wireless Internet access for mobile clients.
•
Strict separation of public access terminals from staff computers.
•
An automatically maintained and updated system for stopping viruses and intrusions at
the firewall.
•
Instant messaging is blocked for public Internet terminals and public wireless access,
but not for staff. Peer-to-peer downloads are blocked network-wide.
•
All Internet traffic from branch offices travels securely to the main office and then out
onto the Internet. Inbound traffic follows the reverse route. This allows a single point at
which all protection profiles and policies may be applied for simplified and consistent
management.
•
The ability to block specific web sites and whole categories of sites from those using
the public terminals and public wireless access if deemed necessary. Users granted
special permission should be allowed to bypass the restrictions.
•
Public access traffic originates from a different address than staff and server traffic.
•
DMZ for web and email server hosting in main office.
•
The library catalog is available on the library’s web page allowing public access from
anywhere.
•
Redundant hardware for main office firewall.
The library’s decision
Every model of the FortiGate Dynamic Threat Prevention System offers real time network
protection to detect and eliminate the most damaging, content-based threats from email
and Web traffic such as viruses, worms, intrusions, inappropriate Web content and more
in real time — without degrading network performance.
The library decided to standardize on the FortiGate-800 and the FortiWiFi-80CM:
160
01-40002-112804-20101015
•
Two FortiGate-800 units for main office. These enterprise-level devices have the
processing power and speed to handle the amount of traffic expected of a large busy
library system with public catalog searches, normal staff use, and on-site research
using the Internet as a resource. The two units are interconnected in HA (high
availability) mode to ensure uninterrupted service in the case of failure. A
FortiWiFi-80CM is also used to provide wireless access for patrons in main office.
•
A FortiWiFi-80CM for each branch office. In addition to being able to handle the
amount of traffic expected of a branch office, the FortiWiFi-80CM provides wireless
access for library patrons.
Proposed topology
Figure 29 shows the proposed network topology utilizing the FortiGate units. Only one
branch office is shown in the diagram although more than a dozen are configured in the
same way, including the VPN connection to the main office.
The VPN connections between the branch offices and the main office are a critical feature
securing communication between locations.
The two FortiGate-800 units in HA mode serve as the only point through which traffic flows
between the Internet and the library’s network, including the branch offices. VPN
connections between the main and branch offices provide the means to securely send
data in either direction.
Branch Internet browsing traffic is routed to the main office through the VPN by the
branch’s FortiWiFi-80CM. After reaching the FortiGate-800 at the main office, the traffic
continues out to the Internet. Inbound traffic follows the same path back to the branch
office.
With two FortiGate-800 units in HA mode serving as a single point of contact to the
Internet, only two FortiGuard subscriptions are required to protect the entire network.
Otherwise each branch would also need separate FortiGuard subscription. The
FortiGuard web filtering service can also be configured on the FortiGate-800 units,
ensuring consistent web filtering policies for all locations.
No provision is made for direct communication between branches.
01-40002-112804-20101015
161
Figure 29: Proposed library system network topology
80
N2
WA.3.1
1
.
10
CM
Z
DM4.1
.1.
10
C
at
19 WAN
2.1 1
68
.23
.8
Wi
Fi-
80
CM
V
P
N
n
Tu
19 Exte
2.1 rm
68 al
.14
7.3
ls
ne
a
in
rm
te 4]
ss 25
ce [2ac .3.
og .1
al 10
9
l
00
T-8 er
FG lust
C
HA
0
C
at
rt2
Po .3.1
00
al
1
.
ern 1
10
Int 0.2.
.10
10
rt4
Po .5.1
00
1
.
10
rt3
Po .4.1
0
.10
0
1
DM
10 Z
.10
0.1
.1
10 se a
.1 rv log
00 er
.1
.1
2
Fi-
P
10 ub
.1 lic
00 te
.4 rm
.[2 in
-2 als
54
]
Wi
P
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
Int
e
10 rnal
.1.
2.1
f
af
st 4]
e 25
fic 2of .[
n .2
ai 00
M .1
10
W
10 se e
.1 rv b
00 er
.1
.1
0
M
10 se a
.1 rv il
00 er
.1
.1
1
Ca
tal
10. og ac
100 ces
.3.[ s te
2-2 rm
54] ina
ls
Table 8 on page 162 details the allowed connectivity between different parts of the
network.
Table 8: Access permission between various parts of the network
Main Staff
Main Catalog
Main Public Access
Web Server
Mail Server
No
No
No
No
No
Yes
Yes Yes* Yes
No
No
No
No
Yes
No
Yes* Yes
No
No
No
Yes
No
Yes*
No
No
Yes
Yes Yes* Yes
No
Yes
No
Yes*
Yes
No
Yes* Yes
No
Yes
No
No
Yes
Catalog Server
Internet Access
Branch Catalog access
Connecting from:
Branch staff
Branch Public Access
Branch Staff
Connecting to:
Branch Public Access
No
Branch Catalog access
No
No
Main Staff
No
No
No
Main Catalog
No
No
No
No
Main Public Access
No
No
No
No
No
Web Server
No
No
No
No
No
No
Mail Server
No
No
No
No
No
No
No
Catalog Server
No
No
No
No
No
No
No
Internet
No
No
No
No
No
No
Yes Yes† Yes†
No
No
No
No
†Only SMTP connections are permitted from the Internet to the mail server.
* An indirect connection. Access to the catalog is through the library web page. Direct
connections to the catalog server are not permitted.
162
01-40002-112804-20101015
Table 9: Features used to fulfil requirements
Feature requirement
Location in this
example
Secure communication between each “IPsec VPN” on
branch and the main office.
page 168
Description
Traffic between the each branch
and the main office is encrypted.
WiFi access for mobile clients.
“Wireless access” on The FortiWiFi-80CM provides WiFi
page 178
access.
Strict separation of public access
terminals from staff computers.
“Topology” on
page 165
Traffic is permitted between
network interfaces only when
policies explicitly allow it.
An automatically maintained and
updated system for stopping viruses
and intrusions at the firewall.
“FortiGuard” on
page 167
The FortiGuard Subscription
service keeps antivirus and
intrusion prevention signatures up
to date. Also included is a spam
blacklist and a web filtering service.
Instant messaging blocked for public
access, and P2P blocked systemwide.
“Protection profiles,
Application Control”
on page 174
Since staff user traffic and public
access user traffic is controlled by
separate policies, different
protection profiles can be created
for each.
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 172
The FortiGuard Web Filtering
service breaks down web sites in to
56 categories. Each can be allowed
or blocked.
Public access traffic originates from a “IP Pools” on
different address than staff and server page 169
traffic in case of abuse.
IP pools can have traffic controlled
by one policy originate from an IP
address different than the physical
network interface.
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 181
of the main branch.
Virtual IP addresses allow a single
physical interface to share
additional IP addresses and route
traffic according to destination
address.
Before they’re allowed access, public
access users must agree that the
library takes no responsibility for what
they might see on the Internet.
“User Disclaimer” on Each policy can be set to require
page 170
authentication and/or agreement to
a disclaimer before access is
permitted.
Redundant hardware to ensure
availability.
“High Availability
(HA)” on page 165
Two FortiGate-800 units operate
together to ensure a minimum
interruption should a hardware
failure occur.
Network addressing
The IP addresses used on the library’s internal network follow a 10.x.y.z structure with a
255.255.255.0 subnet mask, where:
•
x is the branch number. The main office uses 100 while the branches are assigned
numbers starting with 1
01-40002-112804-20101015
163
Configuring the main office
•
•
y indicates the purpose of the attached devices in this range:
•
1 - servers and other infrastructure
•
2 - staff computers
•
3 - catalog terminals
•
4 - public access terminals
•
5 - public WiFi access
z is a range of individual machines
For example, 10.3.2.15 and 10.3.2.27 are two staff members' computers in the third library
branch.
Assigning IP addresses by location and purpose allows network administrators to define
addresses and address ranges to descriptive names on the FortiGate unit. These address
names then can also be incorporated into address groups for easy policy maintenance.
For example, the address range 10.1.2.[2-254] is assigned the name Branch_1_Staff on
the FortiGate-800 unit. Anytime a policy is required for traffic from the staff in branch 1,
this address name can be selected. Further, once an address name is specified for the
staff of each branch, all of those names can be combined into an address group named
Branch_Staff so all the branch staff can be referenced as a single entity.
Figure 30: IP address ranges are assigned names, and the names combined into address
groups.
IP Address Ranges
Address Names
10.1.2.[2-254]
Branch 1 Staff
10.2.2.[2-254]
Branch 2 Staff
10.3.2.[2-254]
Branch 3 Staff
10.100.2.[2-254]
Main Staff
Address Group
Branch 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.
164
01-40002-112804-20101015
Topology
The main office network layout is designed to keep the various parts of the network
separate. Computers on different segments of the network cannot contact each other
unless a FortiGate policy is created to allow the connection. Public terminals can access
the library’s web server for example, but they cannot access any machines belonging to
staff members. See Table 8 on page 162 for details on permitted access between different
parts of the library network.
Staff computers, email and web servers, public access terminals, and WiFi connected
systems are all protected by the FortiGuard service on the FortiGate-800 cluster. Push
updates ensure the FortiGate unit is up to date and prepared to block viruses, worms,
spyware, and attacks.
Figure 31: Main branch network topology
W
iFi
80
CM
V
P
ne
l
0
f
af
st 4]
e 25
fic 2of .[
n .2
ai 00
M .1
10
W
10 se e
.1 rv b
00 er
.1
.1
0
Ca
tal
10. og ac
100 ces
.3.[ s te
2-2 rm
54] ina
ls
M
10 se a
.1 rv il
00 er
.1
.1
1
C
at
rt2
Po .3.1
0
al
.10
ern 1
10
Int 0.2.
.10
10
rt4
Po .5.1
0
.10 t3
10
r
Po .4.1
0
0
.1
10
D
10 M Z
.10
0.1
.1
10 se a
.1 rv log
00 er
.1
.1
2
n
Tu
00
T-8 er
FG lust
C
HA
P
10 ub
.1 lic
00 te
.4 rm
.[2 in
-2 als
54
]
N
19 Exte
2.1 rm
68 al
.14
7.3
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, they’d also be isolated.
Active-active mode has the advantage of using the processing power of the subordinate
unit to increase the efficiency of antivirus scanning. The two FortiGate-800 units fulfil a
mission-critical role.
Configuring HA
Connect the cluster units to each other and to your network. You must connect all
matching interfaces in the cluster to the same hub or switch. Then you must connect these
interfaces to their networks using the same hub or switch.
01-40002-112804-20101015
165
To connect the cluster units
1 Connect the internal interfaces of each FortiGate-800 unit to a switch or hub connected
to your internal network.
2 Connect port2, port3, port4, external, and DMZ interfaces as described in step 1. See
Figure 32.
3 Connect the heartbeat interface of the both FortiGate-800 units using a crossover
cable, or normal cables connected to a switch.
Figure 32: HA Cluster Configuration with switches connecting redundant interfaces
INTERNAL
Esc
Enter
EXTERNAL
DMZ
HA
1
2
3
4
CONSOLE
USB
PWR
Heartbeat
8
External
192.168.147.30
Port3
10.100.4.1
Port2
DMZ
10.100.1.1
10.100.3.1
Internal
10.100.2.1
Port4
10.100.5.1
INTERNAL
Esc
Enter
EXTERNAL
DMZ
HA
1
2
3
4
CONSOLE
USB
PWR
8
To configure the primary unit - web-based manager
1 Power on one of the cluster units and log in to its web based interface.
2 Go to System > Config > HA and set the mode to Active-Active.
3 For the Group Name enter Library.
4 Enter a cluster password.
5 Select ha as the heartbeat interface.
6 Select OK.
7 Go to System > Network > Interface and set the interface IP addresses as indicated in
Figure 32 on page 166
To configure the primary unit - CLI
config system ha
set
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.
166
01-40002-112804-20101015
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.
01-40002-112804-20101015
167
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 they’re use differs significantly. Interface-mode VPNs appear as network
interfaces, like the DMZ, port2, and external network interfaces.
Network topology is easier to visualize because you no longer have a single interface
sending and receiving both encrypted VPN traffic and unencrypted regular traffic. Instead,
the physical interface handles the regular traffic, and the VPN interface handles the
encrypted traffic. Further, policies no longer need to specify whether traffic is IPsec
encrypted. If traffic is directed to a VPN interface, the FortiGate unit knows it is to be
encrypted.
Interface-mode VPNs are used in this configuration because they will require far fewer
policies. Policies for tunnel-mode VPNs require selection of a tunnel in the policy. Many
tunnels can connect to a single physical interface, so the policy needs to know what traffic
it is responsible for.
Since interface-mode VPNs are used as any other network interface, they can be
collected into a zone and treated as a single entity. Addressing names and groups
differentiate what type of user is generating the traffic, so what tunnel it comes out of isn’t
important in the library’s configuration. All branch offices are treated the same.
For example, using tunnel-mode VPNs, 12 branches would require twelve policies to allow
employees to connect directly to the email and web servers. The branch 1 policy would
allow the IP range defined for staff coming from the branch 1 tunnel access to the DMZ. A
second policy would allow the IP range defined for staff coming from the branch 2 tunnel
access to the DMZ, and so on. Since the tunnel must be specified, there must be one
policy for each tunnel, and this is just for branch staff to DMZ traffic. In the library’s network
configuration, there are nine traffic type/destination combinations using the VPN. This
would require 108 policies for 12 branches.
To simplify things we instead give names to the address ranges based on use and
location. IP address range 10.1.2.[2-255] is named Branch 1 Staff and 10.2.2.[2-255] is
named Branch 2 Staff. The same procedure is followed for the remainder of the branches
and all the resulting branch staff names are put into an address group called Branch Staff.
All branch staff computers can be referenced with a single name. Similarly, after all the
branch VPNs are created and named Branch 1, Branch 2, etc., they can be combined into
a single zone named Branches.
From here, it’s a simple matter to configure a single policy to handle staff traffic from all
branches to the email and web servers located on the main office DMZ rather than a policy
for each branch office. Should any branch require special treatment, its VPN interface can
be removed from the zone and separate policies tailored to it.
Configuring IPsec VPNs
The VPNs secure data exchanged between each branch and the main office.
To create the main office VPN connection to branch 1 - web-based manager
1 Go to VPN > IPsec > Auto Key (IKE).
3 Enter Branch 1 for the Name.
4 Select Static IP Address for Remote Gateway.
168
01-40002-112804-20101015
IPsec VPN
5 Enter 192.168.23.89 for the IP Address.
6 Select External for the Local Interface.
7 Select Main (ID Protection) for the Mode.
8 Select Preshared Key as the Authentication Method and enter the preshared key.
9 Select advanced and select Enable IPsec Interface Mode.
10 Select OK.
To create the main office VPN connection to branch 1 - CLI
edit Branch1
set remote-qw 192.168.23.89
set interface external
set mode main
set psksecret ########
end
Note: The preshared key is a string of alphanumeric characters and should be unique for
each branch. The preshared key entered at each end of the VPN connection must be
identical.
To configure the Phase 2 portion of the VPN connection to Branch 1 - web-based
manager
1 Go to VPN > IPsec > Auto Key (IKE).
3 Enter Main to Branch1 for the Name.
4 Select Branch 1 from the Phase 1 drop down list.
5 Select OK.
The advanced options can be left to their default values.
To configure the Phase 2 portion of the VPN connection to Branch 1 - CLI
edit Branch1
set phase1name Branch1
end
The configuration steps to create the VPN tunnel have to be repeated for each branch
office to be connected in this way. Additional branches use the same Phase 1 settings
except for Name, IP Address, and Preshared Key.
IP Pools
IP Pools allow the traffic leaving an interface to use an IP address different than the one
assigned to the interface itself. One use of IP pools is if the users receive a type of traffic
that cannot be mapped to different ports.Without IP pools, only one user at a time could
send and receive these traffic types.
In the library’s case, a single IP address will be put into an IP pool named
Public_Access_Address. All of the policies that allow traffic from the public access
terminals (including the WiFi access point) will be configured to use this IP pool. The result
is that any traffic from the public access terminals will appear to be coming from the IP
pool address rather than the external interface’s IP address. This is true even though the
public access traffic will flow out of the external interface.
01-40002-112804-20101015
169
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 library’s Internet service provider.
4 Select OK.
To add a new IP pool for public access users - CLI
config firewall ippool
edit Public_Access_Address
set startip 192.168.230.64
set endip 192.168.230.64
end
Note: Although IP pools are usually created with a range of addresses, an IP pool with a
single address is valid.
User Disclaimer
When using the public terminals or wireless access, the first time a web page external to
the library’s network is requested, a disclaimer will pop up. This is configured in policies
controlling access to the Internet. The user must agree to the stated conditions before they
can continue.
Configuring the user disclaimer
The disclaimer message is set in System > Config > Replacement Message >
Authentication > Disclaimer page. The default message is changed to reference the library
instead of the generic ‘network access provider’ as shown here:
You are about to access Internet content that is not under the control of the library. The
library is therefore not responsible for any of these sites, their content, or their privacy
policies. The library and its staff do not endorse or make any representations about these
sites, or any information, software, or other products or materials found there, or any
results that may be obtained from using them. If you decide to access any Internet
content, you do this entirely at your own risk and you are responsible for ensuring that any
accessed material does not infringe the laws governing, but not exhaustively covering,
copyright, trademarks, pornography, or any other material which is slanderous,
defamatory or might cause offence in any other way.
Do you agree to the above terms?
If the user decides not to agree to the disclaimer, a second message appears and they are
not allowed to communicate with any systems out on the Internet. This second disclaimer
message is set in System > Config > Replacement Message > Authentication > Declined
disclaimer page. The default text of this declined disclaimer is acceptable:
Sorry, network access cannot be granted unless you agree to the disclaimer.
170
01-40002-112804-20101015
IPsec VPN
The enabling this feature will be detailed in the policy configuration steps.
Protection Profiles
Policies control whether traffic flowing through a FortiGate unit from a given source is
allows to travel to a given destination. UTM profiles are selected in each policy and define
how the traffic is examined and what action may be taken based on the results of the
examination. But before they can be selected in a policy, UTM profiles have to be defined.
A brief overview is given for a typical protection profile, and the information required for all
protection profiles, in this example, follows in table form. For complete policy construction
steps, see the FortiGate Administration Guide.
UTM profiles are grouped based on the type of network threat, and added as needed to a
given firewall policy. UTM profiles include:
•
AntiVirus
•
Protocol Options
•
Intrusion Protection
•
Web Filter
•
Email Filter (antispam)
•
•
Application Control
•
VoIP
The following tables provide all the settings of all four UTM profiles used in the library
network example. Each table focuses on one section of the specific UTM profile settings.
Note: The settings in the tables listed below are for the library example only. For complete
UTM profile information see the FortiGate Administration Guide.
In this example, if a setting is to be left in the default setting, it is not expanded in the tables
below.
Table 10: UTM profiles, Name and Comments
Profile Name
Staff
Public
Servers
Web_Internal
Comment
(optional)
Use with all
policies for traffic
from staff
computers.
Use with all
policies for traffic
from the public
access or WiFi.
Use for policies
allowing the
public access to
the library web
server from the
Internet, or email
server
communication.
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.
01-40002-112804-20101015
171
IPsec VPN
Table 11: UTM profiles, Antivirus settings
Profile Name
Staff
Public
Servers
Web_Internal
Virus Scan
Enable for HTTP,
FTP, IMAP, POP3,
SMTP, IM and
NNTP, Logging
Enable for HTTP,
FTP, IMAP,
POP3, SMTP, IM
and NNTP,
Logging
Enable for HTTP, Disable
FTP, IMAP,
POP3, SMTP, IM
and NNTP,
Logging
File Filter
Disable
Disable
Disable
Quarantine
Enable for HTTP,
FTP, IMAP, POP3,
SMTP, IM and
NNTP
Enable for HTTP,
FTP, IMAP,
POP3, SMTP, IM
and NNTP
Enable for HTTP, Disable
FTP, IMAP,
POP3, SMTP, IM
and NNTP
Disable
Note: The FortiGate unit must have either an internal hard drive or a configured
FortiAnalyzer unit for the Quarantine option to appear.
Table 12: UTM profiles, Protocol Options settings
Profile Name
Staff
Public
Servers
Web_Internal
Pass Fragmented Enable for IMAP,
POP3, and SMTP
Emails
Enable for IMAP,
POP3, and
SMTP
Enable for IMAP,
POP3, and
SMTP
Disable
Comfort Clients
Enable for HTTP
and FTP
Enable for HTTP
and FTP
Disable
Disable
Interval
10
10
10
10
Amount
1
1
1
1
Oversized
File/Email
Pass
Pass
Pass
Pass
Threshold
Default
Default
Default
Default
Append Signature Disable
Disable
Disable
Disable
Table 13: Protection profiles, FortiGuard Web Filtering/Advanced Filter
172
Profile Name
Staff
Public
Servers
Web_Internal
Enable FortiGuard Web
Filtering
Disable
Enable HTTP*
Disable
Disable
Enable FortiGuard Web
Filtering Overrides
Disable
Disable
Disable
Disable
Provide details for
blocked HTTP 4xx and
5xx errors
Disable
Enable HTTP
Disable
Disable
Rate images by URL
(blocked images will be
replaced with blanks)
Disable
Enable HTTP
Disable
Disable
Allow websites when a
rating error occurs
Disable
Disable
Disable
Disable
01-40002-112804-20101015
IPsec VPN
Table 13: Protection profiles, FortiGuard Web Filtering/Advanced Filter
Profile Name
Staff
Public
Servers
Web_Internal
Strict Blocking
Enable HTTP
Enable HTTP
Enable HTTP
Enable HTTP
Enable HTTP
Disable
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 14: Protection profiles, Email Filtering
Profile Name
Staff
Public
Servers
Web_Internal
IP address check
Enable for IMAP,
POP3 and SMTP
Disable
Enable for IMAP,
POP3 and SMTP
Disable
URL check
Enable for IMAP,
POP3 and SMTP
Disable
Enable for IMAP,
POP3 and SMTP
Disable
E-mail checksum
check
Enable for IMAP,
POP3 and SMTP
Disable
Enable for IMAP,
POP3 and SMTP
Disable
Spam submission
Enable for IMAP,
POP3 and SMTP
Disable
Enable for IMAP,
POP3 and SMTP
Disable
IP address BWL
check
Disable
Disable
Disable
Disable
HELO DNS lookup
Disable
Disable
Disable
Disable
E-mail address BWL
check
Enable for IMAP,
POP3 and SMTP
Disable
Enable for IMAP,
POP3 and SMTP
Disable
Return e-mail DNS
check
Enable for IMAP,
POP3 and SMTP
Disable
Enable for IMAP,
POP3 and SMTP
Disable
Banned word check
Disable
Disable
Disable
Disable
Spam Action
Tagged
Disable
Tagged
Disable
Tag Location
Subject
Subject
Subject
Subject
Tag Format
[spam]
[spam]
Email is not scanned for spam using the Public protection profile. Users of the public
access terminals will use their own webmail accounts if checking mail, and WiFi
connected users will have their own spam solutions, if desired.
Table 15: Protection profiles, Intrusion Protection
Profile Name
Staff
Public
Servers
Web_Internal
Select all_default
Select
all_default
Select all_default
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 FortiGate Administration
Guide.
01-40002-112804-20101015
173
IPsec VPN
Table 16: Protection profiles, Application Control
Profile
Staff
Public
Servers
Web_Internal
Block IM
Disable for all IM
protocols
Enable for all IM
protocols
Disable for all IM
protocols
Disable for all
IM protocols
Block P2P
Block for all P2P
protocols
Block for all P2P
protocols
Block for all P2P
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 server’s virtual IP or fully qualified domain name, their request goes out over
the Internet, and returns through the FortiGate unit. This method will make their
transmission vulnerable to interception.
The web browsers on staff computers will be configured with the library web page as the
default start page. Staff members’ email software should be configured to use the email
server’s private network IP address rather than the virtual IP or fully qualified domain
name. These two steps will prevent staff from having to remember the servers’ IP
addresses.
Creating firewall policy for staff members
The first firewall policy for main office staff members allows full access to the Internet at all
times. A second policy will allow direct access to the DMZ for staff members. A second
pair of policies are required to allow branch staff members the same access.
The staff firewall policies will all use a protection profile configured specifically for staff
access. Enabled features include virus scanning, spam filtering, IPS, and blocking of all
P2P traffic. FortiGuard web filtering is also used to block advertising, malware, and
spyware sites.
A few users may need special web and catalog server access to update information on
those servers, depending on how they’re configured. Special access can be allowed
based on IP address or user.
A brief overview procedure is given for a typical policy, and the information required for all
staff policies follows in table form. For more detailed information see the FortiGate
Administration Guide.
Step-by-step policy creation example - web-based manager
1 To create a policy to allow main office staff to connect to the Internet, go to Firewall >
Policy > Policy and select Create New.
174
01-40002-112804-20101015
IPsec VPN
2 Fill in the following fields:
•
•
Source address
•
•
Schedule
•
Service
•
Action
•
Enable NAT
•
UTM Profile - enable all Staff profiles.
•
Log allowed traffic
•
Traffic shaping
•
User authentication disclaimer
•
Comments (optional)
3 Select OK.
The settings required for all staff policies are provided in Table 17.
Table 17: Library staff policies
Main office staff
connect to the
Internet
Main office staff
connect to library
servers
Branch office
staff connect to
the Internet
Branch office
staff connect to
library servers
Source
Interface/Zone
Internal
Internal
Branches
Branches
Source
Address
All
All
Branch_Staff
Branch_Staff
Destination
Interface/Zone
External
DMZ
External
DMZ
Destination
Address
All
Servers
All
Servers
Schedule
Always
Always
Always
Always
Service
All
All
All
All
Action
Accept
Accept
Accept
Accept
NAT
Enable
Enable
Enable
Enable
UTM Profiles
Enable and select
(all configured) Staff
Enable and select
Staff
Enable and select Enable and
Staff
select Staff
Log Allowed
Traffic
Enable
Enable
Enable
Enable
Authentication Disable
Disable
Disable
Disable
Traffic Shaping Disable
Disable
Disable
Disable
User
Disable
Authentication
Disclaimer
Disable
Disable
Disable
Comment
(optional)
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.
Main office: staff
computers
connecting to the
Internet.
01-40002-112804-20101015
175
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 server’s private network
address as the start page.
Creating firewall policies for catalog terminals
The policy used for the catalog access terminals only allows communication with the DMZ.
Create two new policies, one for main office access and another to allow access from the
branch offices.
The settings required for all catalog terminal policies in this example are provided in
Table 18 on page 176.
For complete policy construction steps, see the FortiGate Administration Guide.
Table 18: Catalog terminal policies
Main office catalog terminals
connect to web server
Branch office catalog
terminals connect to web
server
port2
Branches
Source Address
All
Branch_Catalog
DMZ
DMZ
Destination Address
Web_Server
Web_Server
Schedule
Always
Always
Service
HTTP
HTTP
Action
Accept
Accept
NAT
Enable
Enable
UTM Profiles
Disable
Disable
Log Allowed Traffic
Enable
Enable
Authentication
Disable
Disable
Traffic Shaping
Disable
Disable
User Authentication
Disclaimer
Disable
Disable
Comments (optional)
Main office: catalog terminals
connecting to the web server.
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.
176
01-40002-112804-20101015
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 library’s web page as the web browser’s default start page. The
address is the web server’s private network IP so the traffic between the terminal and the
web server remains on the library’s network.
The settings required for all public access terminal policies in this example are provided in
Table 19: Public access terminal policies
Main office Public Main office
access users
public access
connect to Internet users connect to
web server
Branch offices
public access
users connect to
Internet
Branch offices
public access
users connect
to web server
Source
Interface/Zone
Port3
Port3
Branches
Branches
Source Address
Main_Public
Main_Public
Branch_Public
Branch_Public
Destination
Interface/Zone
External
DMZ
External
DMZ
Destination
Address
All
Web_Server
All
Web_Server
Schedule
Always
Always
Always
Always
Service
All
HTTP
All
HTTP
Action
Accept
Accept
Accept
Accept
NAT
Enable NAT, enable Enable NAT.
Dynamic IP Pool
and select
Public_Access_Add
ress
UTM Profiles
Enable and select
Enable and select Enable and select Enable and
Public for each type. Web_Internal for Public for each
select
each type.
type.
Web_Internal
for each type.
Log Allowed
Traffic
Enable
Enable
Enable
Enable
Authentication
Disable
Disable
Disable
Disable
Traffic Shaping
Disable
Disable
Disable
Disable
User
Authentication
Disclaimer
Enable User
Authentication
Disclaimer and
leave Redirect URL
field blank.
Disable
Enable User
Authentication
Disclaimer and
leave Redirect
URL field blank.
Disable
Comments
(optional)
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
Internet.
Branch offices:
public access
terminals
connecting to
the library web
server.
01-40002-112804-20101015
Enable NAT,
Enable NAT.
enable Dynamic
IP Pool and select
Public_Access_A
ddress
177
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 office’s business hours.This decision will be
reviewed periodically, especially if public access is abused.
Wireless security is configured in System > Wireless > Settings.
The number of concurrent wireless users can be adjusted by reducing or expanding the
range of addresses the DHCP server on the WiFi port has available to assign. Using this
means of limiting users is only partially effective because some users may set a static
address in the same subnet and gain access. To prevent this, configure the IP range
specified in the address name used in the policy to have the same range the DHCP server
assigns. Users can still set a static IP, but the policy will not allow any access.
The wireless DHCP server is configured in System > Network > Interface. Select the edit
icon for the wlan interface.
Creating schedules for wireless access
Library users can access the Internet from the WiFi connection. The policies used for WiFi
incorporates a schedule to limit Internet access to only when the library is open to the
public.
The protection profile used for library users enables virus scanning, IPS, and blocking of
all P2P traffic and IM logins. Spam filtering is not enabled. FortiGuard web filtering is used
to block malware, and spyware sites. Additional categories can be blocked if required by
library policy.
The library hours are:
Mon-Thurs
10am - 9pm
Fri-Sat
10am - 6pm
Sun
1pm - 5pm
Because of the varying library hours through the week, three separate schedules are
required.
To create Monday to Thursday business hours schedule - web-based manager
1 Go to Firewall > Schedule > Recurring and select Create New.
2 Enter Mon-Thurs for the schedule name.
3 Select the check boxes for Monday, Tuesday, Wednesday, and Thursday.
4 Select 10 for the start hour and 00 for the start minute.
5 Select 21 for the end hour and 00 for the end minute.
6 Select OK.
178
01-40002-112804-20101015
IPsec VPN
To create Monday to Thursday business hours schedule - CLI
edit Mon-Thurs
set day monday tuesday wednesday thursday
set start 10:00
set end 21:00
end
To create Friday and Saturday business hours schedule - web-based manager
2 Enter Fri-Sat for the schedule name.
3 Select the check boxes for Friday, and Saturday.
6 Select OK.
To create Friday and Saturday business hours schedule - CLI
edit Fri-Sat
set day friday saturday
set start 10:00
set end 18:00
end
To create Sunday business hours schedule - web-based manager
2 Enter Sun for the schedule name.
3 Select the check box for Sunday.
6 Select OK.
To create Monday to Thursday business hours schedule - CLI
edit Sun
set sunday
set start 13:00
set end 17:00
end
For holidays, special one-time schedules can be created. These schedules allow
specifying the year, month, and day in addition to the hour and minute. Duplicate policies
can be created with one-time schedules to cover holidays. Policies are parsed from top to
bottom so position these special holiday policies above the regular recurring-schedule
policies, otherwise the holiday policies will never come into effect.
One-time schedules are configured in Firewall > Schedule > One-time in the web-based
manager and config firewall schedule onetime in the CLI.
Grouping schedules
01-40002-112804-20101015
179
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.
3 Enter WiFi_Schedule for the Name.
4 Select the schedules from the Available Schedules list.
5 Select the Down-arrow to add them to the Members list.
6 Select OK.
To create a schedule group - CLI
config firewall schedule
edit WiFi_Schedule
set member Mon-Thurs Fri-Sat Sun
end
Creating firewall policies for WiFi access
Two main office WiFi access policies are required. One incorporates the schedules to
cover the entire week and only allow access while the library is open to the public. The
fourth policy allows access to the library web server.
Table 20: Main office WiFi terminal policies
Main office WiFi users
connect to Internet
180
Main office WiFi users
connect to web library server
Port4
Port4
Source Address
Main_WiFi
Main_WiFi
External
DMZ
Destination Address
All
Web_Server
Schedule
Mon-Thurs
Always
Service
All
HTTP
Action
Accept
Accept
NAT
Enable NAT, enable Dynamic IP Enable NAT.
Pool and select
Public_Access_Address
UTM Profile
Enable and select Public for
each type.
Enable and select Web_Internal
for each type.
Log Allowed Traffic
Enable
Enable
Authentication
Disable
Disable
Traffic Shaping
Disable
Disable
User Authentication
Disclaimer
Enable User Authentication
Disclaimer and leave Redirect
URL field blank.
Disable
Comments (optional)
Main office: WiFi connecting to
the Internet (Mon-Thurs).
Main office: WiFi connecting to
the library web server.
01-40002-112804-20101015
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 21 on page 181.
Table 21: Branch office WiFi terminal policies
Branch office WiFi users
connect to Interne
Branch office WiFi users
connect to web library server
Branches
Branches
Source Address
Branch_WiFi
Branch_WiFi
Destination
Interface/Zone
External
DMZ
Destination Address
All
Web_Server
Schedule
Mon-Thurs
Always
Service
All
HTTP
Action
Accept
Accept
NAT
Enable NAT, enable Dynamic IP
Pool and select
Public_Access_Address
Enable NAT.
UTM Profile
Enable and select Public for each Enable and select Web_Internal
type.
for each type.
Log Allowed Traffic
Enable
Enable
Authentication
Disable
Disable
Traffic Shaping
Disable
Disable
User Authentication
Disclaimer
Enable User Authentication
Disclaimer and leave Redirect
URL field blank.
Disable
Comments (optional)
Branch offices: WiFi connecting to Branch offices: WiFi connecting to
the Internet (Fri-Sat).
the library web server.
Mail and web servers
Since the branch offices do not have their own email servers, all library staff email is sent
or received using the main office email server. Users in branch offices connect though
their VPN to the main office. Maintenance of a single server is more convenient and cost
effective than each branch office having their own email server.
Staff email software will be set up with the email server’s private network IP address.
Specifying the virtual IP address or domain name would cause the email traffic to loop out
to the Internet and return, allowing the information to be intercepted. Similarly, staff
computers will be pre-configured with the library web server’s internal network IP address
as the start page address.
Creating a virtual IP for the web server
The library has arranged for another external IP address which will be used for the
library’s Internet web presence. A virtual IP configured on the FortiGate will take any traffic
directed to 172.20.16.192 on the Internet and remap it to the web server at 10.100.1.10 on
the library’s network. The 172.20.16.192 address can be registered with the library’s
domain name so anyone on the Internet entering the URL will bring up the library’s page.
01-40002-112804-20101015
181
IPsec VPN
To create a virtual IP for the web server - web-based manager
2 Enter Web_Server_VIP for the Name.
3 Select External from the External Interface drop down.
4 Select Static NAT as the Type
5 Enter 172.20.16.192 as the External IP Address.
6 Enter 10.100.1.10 as the Mapped IP Address.
7 Disable Port Forwarding.
8 Select OK.
To create a virtual IP for the web server - CLI
config firewall vip
edit Web_Server_VIP
set extintf external
set nat-soruce-vip enable
set extip 172.20.16.192
set portforward diable
end
Creating a virtual IP for the email server
Similar to the web server, the library has another external IP address reserved for the
email server. A virtual IP configured on the FortiGate will take any traffic directed to
172.20.16.120 and remap it to the web server at 10.100.1.11 transparently.
To create a virtual IP for the email server - web-based manager
2 Enter Email_Server_VIP for the Name.
3 Select External from the External Interface drop down.
4 Select Static NAT as the Type
5 Enter 172.20.16.120 as the External IP Address.
6 Enter 10.100.1.11 as the Mapped IP Address.
7 Disable Port Forwarding.
8 Select OK.
To create a virtual IP for the email server - CLI
config firewall vip
edit Email_Server_VIP
set extintf external
set nat-soruce-vip enable
set extip 172.20.16.120
set portforward diable
end
182
01-40002-112804-20101015
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 22 on
page 183.
Table 22: Server policies
Inbound to web and email servers
Outbound from email
server
External
DMZ
Source Address
All
Servers
Destination
Interface/Zone
DMZ
External
Destination Address
Servers
All
Schedule
Always
Always
Service
Servers
SMTP
Action
Accept
Accept
NAT
Enable
Enable
UTM Profiles
Enable and select Servers for each
type.
Enable and select Servers
for each type.
01-40002-112804-20101015
183
IPsec VPN
Table 22: Server policies (Continued)
Inbound to web and email servers
Outbound from email
server
Log Allowed Traffic
Enable
Enable
Authentication
Disable
Disable
Traffic Shaping
Disable
Disable
User Authentication
Disclaimer
Disable
Disable
Comments (optional)
Incoming web connections and
Outbound email server
incoming email delivery from other mail connections.
servers.
The FortiWiFi-80CM
In the main office network, the FortiWiFi-80CM is used to provide WiFi access to main
library patrons with their own WiFi-capable laptops, and as a connection point to all the
main office public access terminals. Since all the policies and protection profiles are
configured on the FortiGate-800 cluster, the FortiWiFi-80CM only has to pass the traffic
along. For this reason, the FortiWiFi-80CM configuration is not complex.
Configuring the main office FortiWiFi-80CM.
The FortiWiFi-80CM is connected as shown in the main branch network topology diagram,
Figure 31 on page 165.
To Configure the operation mode - web-based manager
1 Go to System > Config > Operation and set the unit to Transparent Mode.
Since the FortiWiFi-80CM is within the library’s network, no address translation is
required.
2 Enter 10.100.1.99/255.255.255.0 as the Management IP/Netmask and
10.100.1.3 as the Default Gateway.
3 Select Apply.
You will be disconnected and will have to log in to the FortiWiFi-80CM using the
management IP address.
To Configure the operation mode - CLI
config system settings
set opmode transparent
set manageip 10.100.1.99 255.255.255.0
end
Since the FortiWiFi-80CM will not be examining the traffic for content, only a single simple
policy is required.
The settings required for all main office WiFi-80CM policies in this example are provided in
184
01-40002-112804-20101015
Configuring branch offices
Table 23: Main office FortiWiFi-80CM policies
WiFi
Wlan
Source Address
All
Wan1
Destination Address
All
Schedule
Always
Service
All
Action
Accept
UTM Profiles
Disable
Log Allowed Traffic
Disable
Authentication
Disable
Traffic Shaping
Disable
User Authentication Disclaimer
Disable
Comments (optional)
WiFi users connected to the main office FortiWiFi-80CM
Although the WiFi policy allows access at all times, the policies on the FortiGate-800
cluster restrict Internet access to library business hours.
The three sections of each branch’s network (staff computers, catalog terminals, and
public access terminals) are wired separately to different interfaces on the FortiWiFi-80CM
and cannot access each other.
All external communication is sent to the main office through the VPN by the 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 8 on page 162 for details on permitted access between different network
areas.
Staff computers, email and web servers, public access terminals, WiFi connected systems
are all protected by the FortiGuard service subscription on the FortiGate-800 cluster at the
main branch.
01-40002-112804-20101015
185
Figure 33: Branch office network topology
N2
WA.3.1
.1
10
u
10 bli
.1 c te
.4 r
.[2 m
-2 ina
54 ls
]
M
Z
DM4.1
.1.
10
P
f
af ]
st 4
h -25
nc [2
ra 2.
B .1.
10
C
Int
-80
i
ern
F
10 al Wi
.1.
2.1
C
at
19 WAN
2.1 1
68
.23
.8
V
P
N
n
Tu
ls
ne
a
in
rm
te 4]
ss 25
ce [2ac .3.
og .1
al 10
9
l
Staff access
All staff traffic is routed through the VPN to the main branch. Requests for the email or
web servers are routed to the main office DMZ while general Internet traffic is sent to the
main office then out of the library network to the Internet.
Catalog terminals
Dedicated computers are provided for library patrons to search for books and periodicals
in the library’s catalog. The catalog computers are configured so the only application
available is a web browser, and the only site it can access is the library web page which
includes access to the catalog. Requests are routed through the VPN to the web server in
the library’s main office.
Wireless/public access
Public access terminals and wireless access allow library patrons to access the Internet.
Profile settings deny all instant messaging and peer to peer connections. Also, main
branch library staff can block individual sites and entire site categories as deemed
necessary using FortiGuard web filtering.
Mail and web servers
Branch offices do not have their own email servers. When staff members send or receive
email, their email software connects to the email server in the main library location. This
connection is made through the VPN between the main and branch office. Email server
access is not available from the Internet at large.
186
01-40002-112804-20101015
IPsec VPN
Each branch will have a VPN connection to the main office.
To create the Phase 1 portion of the VPN to the main office - web-based manager
1 Go to VPN > IPsec > Auto Key (IKE) and Select Create Phase 1.
2 In the Name field, enter Main_Office.
3 Select Static IP for Remote Gateway.
4 Enter 192.168.147.30 in the IP Address field.
5 Select WAN1 for the Local Interface.
6 Select Main (ID Protection) for the Mode.
7 Select Preshared Key as the Authentication Method and enter the key in the Preshared
Key field.
8 Select Advanced and select Enable IPsec Interface Mode.
9 Select OK.
To create the Phase 1 portion of the VPN to the main office - CLI
edit Main_Office
set remote-qw 192.168.147.30
set interface WAN1
set mode main
set psksecret ########
end
Note: The preshared key is a string of alphanumeric characters and should be unique for
each branch. The preshared key entered at each end of the VPN connection must be
identical.
To create the Phase 2 portion of the VPN to the main office - web-based manager
2 Enter Branch 1 to Main_Office in the Name field.
3 Select Main_Office from the Phase 1 drop down.
4 Select OK.
To create the Phase 2 portion of the VPN to the main office - CLI
edit Main_Office
set phase1name Main_Office
end
The configuration steps to create the VPN tunnel have to be repeated for each branch
office to be connected in this way. Additional branches use the same Phase 1 settings
except for Name, IP Address, and Preshared Key.
Branch Firewall Policy
All traffic leaving the branch, whether destined for the main office or the Internet, is
controlled by a single policy. Additional policies and routing configured on the FortiGate800 cluster at the main office direct the traffic once it arrives there.
01-40002-112804-20101015
187
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, WLAN, and WAN2) are collected into a zone called Inside_Zone. This allows a
single policy to control all the traffic leaving the branch.
Policies are configured in Firewall > Policy > Policy. Interface zones are defined in System
> Network > Zone.
The settings required for all main office WiFi-80CM policies in this example are provided in
Table 24: Branch office FortiWiFi-80CM policies
Branch policy
Inside_Zone
Source Address
All
Main_Office
Destination Address
All
Schedule
Always
Service
All
Action
Accept
UTM Profiles
Disable
Log Allowed Traffic
Disable
Authentication
Disable
Traffic Shaping
Disable
User Authentication
Disclaimer
Disable
Comments (optional)
Policy to allow branch traffic to
main office.
Traffic shaping
Traffic shaping regulates and prioritizes traffic flow. Guaranteed bandwidth allows a
minimum bandwidth to be reserved for traffic controlled by a policy. Similarly, maximum
bandwidth caps the rate of traffic controlled by the policy. Finally, the traffic controlled by a
policy can be assigned a high, medium or low priority. If there is not enough bandwidth to
transmit all traffic, high priority traffic is processed before medium priority traffic, and
medium before low priority traffic.
Traffic shaping limits are applied only to traffic controlled by the policy they're applied to. If
you do not apply any traffic shaping rules to a policy, the policy is set to high priority by
default. Because of this, traffic shaping is of extremely limited use if applied to some
policies and not others. Enable traffic shaping on all firewall policies.
Because guaranteed bandwidth and maximum bandwidth settings are entirely dependant
on the maximum bandwidth available, the current traffic, and the relative priority of each
type of traffic, defining exact values for each policy is beyond the scope of this document
and traffic shaping is therefore disabled in the example policies.
188
01-40002-112804-20101015
The future
Priorities
Traffic can be assigned high, medium, or low priority depending on importance. Ideally,
traffic will be spread across all three priorities. If all traffic is assigned the same setting,
prioritizing traffic is effectively disabled.
On the library system’s network, there are four types of users accessing two services.
Table 25: Priority of traffic based on source and destination
To servers
From catalog terminals*
high
From Internet†
high
To Internet
From public terminals/WiFi*
high
low
From staff*
high
medium
* includes both branch and main office traffic
† includes both inbound and outbound mail server connections
On the library system’s network, the most important traffic is to and from the web and mail
servers. Locating research materials in the library’s collection is extremely difficult without
a working catalog. Email is important to staff members as they maintain important
communication using it.
Staff access to the Internet is of medium priority. Although staff members do need Internet
access, it’s rarely as time-critical as catalog access and email.
Public access to the Internet (both from provided terminals and WiFi connections) are of
the lowest priority.
Although most traffic appears to be of high importance, the most bandwidth is consumed
by Internet access, partly by staff but mostly by the public terminals/WiFi.
With this in mind, a maximum bandwidth value can also be set to limit the bandwidth
consumed by traffic controlled by the public policies. Since the rate entered for maximum
bandwidth applies only to the traffic the policy controls, care has to be taken because
public access traffic is controlled by four policies at any given time. There are branch and
main office policies for public terminals and WiFi connections. The maximum bandwidth
specified in each policy doesn’t take into account any of the others. If you wanted to limit
all public access to the Internet to no more than 200KB/s, you have to divide this value
among the four active policies.
The future
In the design of the example library network detailed in this document, decisions were
made about how it should function when initially installed. Assumptions on how the
network will be used may be incorrect, or usage may change over time. The network can
be modified to facilitate changing usage or new requirements. For example:
Logging
Should the library require detailed logging, a FortiAnalyzer unit can be added to the main
office network. The FortiGate-800 cluster could then be configured to send traffic and
event data to the FortiAnalyzer. Detailed reports can be generated to chart network
utilization, Internet use, and attack activity.
Should the library switch to a VoIP telephone system, reports can also be generated on
telephone usage.
01-40002-112804-20101015
189
The future
Decentralization
If a more decentralized approach is required, Internet access from branch offices could
bypass the main office entirely. Branch FortiGate units would still maintain VPN-encrypted
communication for secure access to the library servers. A FortiManager device would
minimize the administrative effort required to deploy, configure, monitor, and maintain the
security policies across all branch office FortiGate units.
Staff WiFi
The FortiWiFi-80CM supports the creation of virtual WiFi interfaces. If staff members
require WiFi connectivity, a virtual WiFi interface could be created to allow them full
access to staff network resources while maintaining the current limited access provided to
public access users.
Further redundancy
Although the FortiGate-800 cluster ensures minimal downtime with hardware redundancy,
adding another Internet connection from a different ISP can provide connection
redundancy to the main office.
The FortiWiFi-80CM used in the branch offices supports the same High-Availability
clustering as the FortiGate-800 so if needed, the branch offices could enjoy the same HA
protection as the main office without having to upgrade to higher models.
190
01-40002-112804-20101015
The future
191
01-40002-112804-20101015
The future
192
01-40002-112804-20101015
Index
Numerics
802.3ad, 52
A
accept, 90
accept policy, 94
adding, configuring or defining
gateway for default route, 76
static route, adding to routing table, 77
address, 57
CIDR format, 57
DHCP, 67
FDQN, 61
groups, 66
IP pool, 69
IP range, 57
IPv6, 71
matching, IP pool, 70
administrative access, 51
administrative distance, 73
aggregate interfaces, 52
allow access, 51
antispam, about, 26
antivirus, about, 23
B
DHCP, 67
diagnose
flow trace, 113
session list, 111
sniffer packet, 116
sys checkused, 113
DNAT
virtual IPs, 63, 65
DNS
TTL, 61
document conventions
CLI syntax, 16
documentation, 20
commenting on, 20
conventions, 13
DoS
policies, 91, 96
sensors, 96
E
email filter
techniques, 26
email filter, about, 26
example
blocking IP address, 102
scheduled access, 103
exempted URLs, 119
blended network attacks, about, 26
F
C
FAQ, 20
FDQN, 61
firewall policies, 92
accept, 90
basic accept, 94
basic deny, 94
basic VPN, 95
checking, 109
column settings, 92, 110
denial of service, 91, 96
deny, 90
ICMP packets, 101
identity-based, 98
IPsec, 90
log messages, 110
one-armed sniffer, 97
policy order, 90
rearrange, 91
schedule example, 103
ssl-vpn policies, 90
verify traffic, 110
firewall policy
sniffer, 97
fixed ports, IP pools, 70
central NAT, 32
certification, 20
CLI
syntax conventions, 16
column settings, firewall policies, 92
comments, documentation, 20
conventions, 13
Cross-Site Scripting (XSS), 18
custom services, 82
customer service, 20
D
default gateway, 74
default route, 74
denial of service
policies, 91, 96
deny, 90
deny policy, 94, 110
destination network address translation (DNAT)
virtual IPs, 63, 65
details, firewall policies, 92
01-40002-112804-20101015
193
Index
flow inspection, 36, 37
flow trace, 113
FortiGate documentation
commenting on, 20
FortiGuard, 119
Antivirus, 19
services, 19
Fortinet
Knowledge Base, 20
Technical Documentation, 20
Technical Documentation, conventions, 13
Technical Support, 20
Technical Support, registering with, 19
Technical Support, web site, 19
Training Services, 20
Fortinet customer service, 20
L
G
P
glossary, 20
grayware, about, 25
groups, addressing, 66
P2P, about, 25
packet
flow, 38
ICMP, 101
life of, 35
sniffer, 116
PAT
virtual IPs, 63
peer-to-peer, about, 25
pharming, about, 25
phishing, about, 25
policies, 90, 91
basic accept, 94
basic deny, 94
basic VPN, 95
checking, 109
column settings, 92
denial of service, 91, 96
ICMP packets, 101
identity-based, 98
log messages, 110
one-armed sniffer, 97
order, 90
sniffer, 97
verify traffic, 110
policy 0, 92
policy-based routing, 77
port address translation
virtual IPs, 63
port forwarding, 63
ports
closing to traffic, 81
default system, 79
originating traffic, 79
receiving traffic, 80
services, 82
TCP 113, 81
TCP 541, 81
position
identity-based policy, 100
product registration, 19
profiles, UTM, 85
proxy inspection, 37
H
how-to, 20
I
ICMP processing, 101
identity-based policy, 98
position, 100
inspection
flow, 36, 37
proxy, 37
security layers, 37
stateful, 35
instant messaging, about, 25
interfaces
aggregate, 52
AMC card, 50
ANY, ANY interface option, 93
physical, 49
virtual domains, 53
virtual LANs, 55
wireless, 52
zones, 56
intrusion protection, about, 27
IP address
private network, 13
IP addresses
blocking, 102
IP pool, 69
address matching, 70
policies and fixed ports, 70
IP range, 57
IPsec, 90
IPv6, 71
K
Knowledge Base, 20
194
life of a packet, 35
local category, 119
log messages, 110
N
NAT, 32
symmetric, 66
NAT mode
about, 29
network address translation (NAT), 63
O
one-armed sniffer policy, 97
01-40002-112804-20101015
Index
R
rearrange, 91
registering
with Fortinet Technical Support, 19
RFC
1918, 13
RFC 5237, 78
routing
routing policy
protocol number, 78
S
schedule
automatic updates, 128
schedules
example, 103
group, 84
one time, 83
recurring, 83
security layers, 37
sensors, UTM, 85
services, 82
custom, 82
list, 82
session helper, 41
session list, diagnose, 111
session table, 111
SNAT
virtual IPs, 63
sniffer
one-armed policy, 97
packet, 111
policy, 97
spyware, about, 25
ssl-vpn, 90
stateful inspection, 35
static route
adding, 77
default gateway, 74
default route, 74
policy, 77
selecting, 73
table priority, 74
table sequence, 74
streaming media, about, 25
T
technical
documentation, 20
documentation conventions, 13
notes, 20
support, 20
01-40002-112804-20101015
technical support, 20
traffic count, 110
traffic shaping
about, 28
traffic trace, 111
Training Services, 20
transparent mode
about, 32
feature differences, 34
switching to, 33
troubleshooting
flow trace, 113
log messages, 110
packet sniffer, 116
policies, 109
session table, 111
veryify traffic, 110
U
UTM
profiles, 85
profiles and sensors, 85
V
verify traffic, 110
violation traffic, 110
virtual domains, 53
virtual IP
destination network address translation (DNAT), 63, 65
NAT, 63
PAT, 63
port address translation, 63
SNAT, 63
source network address translation, 63
virtual LANs, 55
VPN
policy, 95
W
web filter, 119
web filtering, about, 24
wireless, 52
X
XSS, 18
Z
zones, 56
195
Index
196
01-40002-112804-20101015
Index
01-40002-112804-20101015
197
Index
198
01-40002-112804-20101015

FortiGate Fundamentals - Fortinet Document Library

Transcription

Similar documents

Yahoo! Japan

Analyzing your network traffic using a one

wooweb-pro v5

as PDF

10 Free Ways To Keep Your PC Safe

Clavister Virtual Core

2/e, by William Stallings and Lawrie Brown, Chapter 9

Quick Start Guide for Doppler Series 7000

Hacking Satellite TV receivers : Are those IoT devices

Bypass firewalls, application white lists, secure remote