Fortigate Fundamentals 40 Mr3

FortiGate Fundamentals

FortiOS™ Handbook v3for FortiOS 4.0 MR3

FortiOS™ Handbook: FortiGate Fundamentalsv324 June 201101-431-112804-20110624for FortiOS 4.0 MR3© Copyright 2011 Fortinet, Inc. All rights reserved. No part of this publication including text, examples, diagrams or illustrations may be reproduced, transmitted, or translated in any form or by any means, electronic, mechanical, manual, optical or otherwise, for any purpose, without prior written permission of Fortinet, Inc.

TrademarksThe symbols ® and ™ denote respectively federally registered trademarks and unregistered trademarks of Fortinet, Inc., its subsidiaries and affiliates including, but not limited to, the following names: Fortinet, FortiGate, FortiOS, FortiASIC, FortiAnalyser, FortiSwitch, FortiBIOS, FortiLog, FortiVoIP, FortiResponse, FortiManager, FortiWiFi, FortiGuard, FortiReporter, FortiClient, FortiLog, APSecure, ABACAS. Other trademarks belong to their respective owners.

F0h

ContentsThe Purpose of a Firewall 9Firewall features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

Antivirus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9Web Filtering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

Data leak prevention . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11Application control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11Spyware/Grayware. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11Phishing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11Pharming. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12Instant messaging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12Peer-to-peer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12Streaming media . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12Blended network attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

Antispam/Email Filter. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12Email filter techniques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

Intrusion Protection. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14Traffic Shaping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

NAT vs. Transparent Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16NAT mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

How address translation works . . . . . . . . . . . . . . . . . . . . . . . . 17Central NAT table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

Transparent mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18Operating mode differences . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

Life of a Packet 21Stateful inspection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

Flow inspection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

Proxy inspection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

FortiOS functions and security layers . . . . . . . . . . . . . . . . . . . . . . . . . 23

ortiOS™ Handbook v3: FortiGate Fundamentals1-431-112804-20110624 3ttp://docs.fortinet.com/ • Feedback

http://docs.fortinet.com/

http://docs.fortinet.com/surveyredirect.html

Contents

Packet flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24Packet inspection (Ingress) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25DoS sensor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25IP integrity header checking . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25IPsec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26Destination NAT (DNAT) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26Policy lookup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26Session tracking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26User authentication. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27Management traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27SSL VPN traffic. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27Session helpers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27Flow-based inspection engine . . . . . . . . . . . . . . . . . . . . . . . . . . . 27Proxy-based inspection engine. . . . . . . . . . . . . . . . . . . . . . . . . . . 27IPsec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28Source NAT (SNAT) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28Egress . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

Example 1: client/server connection . . . . . . . . . . . . . . . . . . . . . . . . . . 28

Example 2: Routing table update . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

Example 3: Dialup IPsec with application control. . . . . . . . . . . . . . . . . . . . 30

Firewall components 33Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

Physical . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33Administrative access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35Wireless . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36Virtual domains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37Virtual LANs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38Zones. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

Addressing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

Geography based addressing . . . . . . . . . . . . . . . . . . . . . . . . . . . 42Wildcard masks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43Fully Qualified Domain Name addresses . . . . . . . . . . . . . . . . . . . . . 43Address groups. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44DHCP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

FortiGate Fundamentals for FortiOS 4.0 MR34 01-431-112804-20110624

http://docs.fortinet.com/ • Feedback



Contents

F0h

DHCP options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47IP reservation with DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

IP pools. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

IP Pools for security policies that use fixed ports . . . . . . . . . . . . . . . . . 49Source IP address and IP pool address matching . . . . . . . . . . . . . . . . . 49IPv6. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51Originating traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52Receiving traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52Closing specific ports to traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

Port 113 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53Port 541 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

Using virtual IPs for port forwarding and destination NAT . . . . . . . . . . . . . . . 54Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

Inbound connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55DNAT and virtual IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55Virtual IP options for port forwarding and DNAT . . . . . . . . . . . . . . . . . . 56

Outbound connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58Virtual IP, load balance virtual server / real server limitations . . . . . . . . . 59

Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59Custom service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

Schedules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

Schedule groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

Schedule expiry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62Identity-based policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

UTM profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63Profiles and sensors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

Security Policies 65Policy order . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66




Contents

Creating basic policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67Using an interface of “any” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68Basic accept policy example . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68Basic deny policy example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68Basic VPN policy example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

Security policy examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70Blocking an IP address . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

Add an Address . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70Add a Security Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

Scheduled access policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71Configuring the schedules . . . . . . . . . . . . . . . . . . . . . . . . . . . 72Configuring the IP addresses . . . . . . . . . . . . . . . . . . . . . . . . . 73Configuring the security policies . . . . . . . . . . . . . . . . . . . . . . . . 73

Troubleshooting 77Basic policy checking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

Verifying traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

Using log messages to view violation traffic . . . . . . . . . . . . . . . . . . . . . . 78

Traffic trace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79Session table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

Sample output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80Finding object dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

Sample output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81Flow trace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

Sample output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82Flow trace output example - HTTP. . . . . . . . . . . . . . . . . . . . . . . . . 82

Packet sniffer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84Simple trace example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84Simple trace example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

Verbose levels 2 and 3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85Trace with filters example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

Index 87





v0h

Chapter 1 FortiGate Fundamentals

This document describes firewall components, and how to implement security policies on FortiGate units operating in both NAT/Route, and Transparent mode.This FortiOS Handbook chapter contains the following sections:The Purpose of a Firewall provides an overview of the FortiGate firewall and its traffic controlling options.Life of a Packet describes how a FortiGate unit processes incoming and outgoing network traffic through its interfaces and security policies.Firewall components describes the FortiGate interfaces, addressing, services and user configuration that goes into creating a security policy.Security Policies describes what policies are, the types of security policies and how to configure and arrange them to ensure proper traffic management.Troubleshooting describes some common problems and solutions when setting up security policies to manage network traffic.Concept Example: Small Office Network Protection walks through a small office configuration of security policies.Concept Example: Library Network Protection walks through an enterprise network configuration of security policies.

3 FortiGate Fundamentals1-431-112804-20110624 7ttp://docs.fortinet.com/ • Feedback



v3 FortiGate Fundamentals8 01-431-112804-20110624




v0h

The Purpose of a FirewallRanging 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 security policies.Security 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 security policy matching the packet.Security 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 security policies that are the instructions for the FortiGate unit.

Firewall featuresThe FortiGate unit provides unified threat management by including a rich feature set to protect your network from unwanted attacks. This section provides an overview of what the FortiGate unit can protect against. Each of these elements are configured and added to security policies as a means of instructing the FortiGate unit what to do when encountering an security threat.

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




Firewall features The Purpose of a Firewall

Antivirus scanning function includes various modules and engines that perform separate tasks. The FortiGate unit performs antivirus processing in the following order:• File size• File pattern• File type• Virus scan• Grayware• HeuristicsIf a file fails any of the tasks of the antivirus scan, no further scans are performed. For example, if the file “fakefile.exe” is recognized as a blocked pattern, the FortiGate unit will send the recipient a message informing them that the original message had a virus, and the file will be deleted or quarantined. The virus scan, grayware, heuristics, and file type scans will not be performed as the file is already been determined to be a threat and has been dealt with.For more information on FortiGate antivirus processes, features and configuration, see the UTM chapter.

Web FilteringWeb filtering is a means of controlling the content that an Internet user is able to view. With the popularity of web applications, the need to monitor and control web access is becoming a key component of Secure Content Management systems that employ antivirus, web filtering, and messaging security. Important reasons for controlling web content include:• Lost productivity because employees are accessing the web for non-business reasons.• Network Congestion - valuable bandwidth is being used for non-business purposes

and legitimate business applications suffer.• Loss or exposure of confidential information through chat sites, non-approved email

systems, instant messaging, and peer-to-peer file sharing.• Increased exposure to web-based threats as employees surf non-business related web

sites.• Legal liability when employees access/download inappropriate and offensive material.• Copyright infringement caused by employees downloading and/or distributing

copyrighted material.As the number and severity of threats increase on the web, the risk potential is increasing within a company's network as well. Casual non-business related web surfing has caused many businesses countless hours of legal litigation as hostile environments have been created by employees who download and view offensive content.web-based attacks and threats are also becoming increasingly sophisticated. New threats and web-based applications that are causing additional problems for corporations include:• Spyware/Grayware• Phishing• Instant Messaging• Peer-to-Peer File Sharing• Streaming Media• Blended Network Attacks





The Purpose of a Firewall Firewall features

v0h

Data leak preventionThe FortiGate data leak prevention (DLP) system allows you to prevent sensitive data from leaving your network. When you define sensitive data patterns, data matching these patterns will be blocked, logged, and archived, or any combination of these three actions, when passing through the FortiGate unit. You configure the DLP system by creating individual rules, combining the rules into DLP sensors, and then assigning a sensor to a security policy.Although the primary use of the DLP feature is to stop sensitive data from leaving your network, it can also be used to prevent unwanted data from entering your network and to archive some or all of the content passing through the FortiGate unit.DLP examines network traffic for data patterns you specify. You define whatever patterns you want the FortiGate unit to look for in network traffic. The DLP feature is broken down into a number of parts.

Application controlUsing the application control UTM feature, your FortiGate unit can detect and take action against network traffic depending on the application generating the traffic. Application control is a user-friendly and powerful way to use Intrusion Protection features to log and manage the behavior of application traffic passing through the FortiGate unit. Application control uses IPS protocol decoders that can analyze network traffic to detect application traffic even if the traffic uses non-standard ports or protocols.The FortiGate unit can recognize the network traffic generated by a large number of applications. You can create application control lists that specify the action to take with the traffic of the applications you need to manage and the network on which they are active, and then add application control lists to the security policies that control the network traffic you need to monitor.

Spyware/GraywareSpyware 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

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





PharmingPharming 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 messagingInstant 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-peerPeer-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 mediaStreaming media is a method of delivering multimedia, usually in the form of audio or video to Internet users. The viewing of streaming media has increased greatly in the past few years. The problem with this is the way it impacts legitimate business.

Blended network attacksBlended network threats are rising and the sophistication of network threats is increasing with each new attack. Attackers are learning from each previous successful attack and are enhancing and updating attack code to become more dangerous and fast spreading. Blended attacks use a combination of methods to spread and cause damage. Using virus or network worm techniques combined with known system vulnerabilities, blended threats can quickly spread through email, web sites, and Trojan applications. Blended attacks can be designed to perform different types of attacks - from disrupting network services to destroying or stealing information to installing stealthy back door applications to grant remote access.For more information on FortiGate web filter processes, features and configuration, see the UTM chapter.

Antispam/Email FilterThe 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.






v0h

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 techniquesThe 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 spamThe FortiGate unit sends a hash of an email to the FortiGuard Antispam server which compares the hash to hashes of known spam messages stored in the FortiGuard Antispam database. If the hash results match, the email is flagged as spam.The FortiGate unit compares the IP address of the client delivering the email to the addresses in the IP address black/white list specified in the protection profile. If a match is found, the FortiGate unit will take the action configured for the matching black/white list entry against all delivered email.The FortiGate unit takes the domain name specified by the client in the HELO greeting sent when starting the SMTP session, and does a DNS lookup to determine if the domain exists. If the lookup fails, the FortiGate unit determines that any messages delivered during the SMTP session are spam.The FortiGate unit compares the sender email address, as shown in the message envelope MAIL FROM, to the addresses in the email address black/white list specified in the protection profile. If a match is found, the FortiGate unit will take the action configured for the matching black/white list entry.The FortiGate unit performs a DNS lookup on the reply-to domain to see if there is an A or MX record. If no such record exists, the message is treated as spam.The FortiGate unit will block email messages based on matching the content of the message with the words or patterns in the selected spam filter banned word list.For more information on FortiGate antispam processes, features and configuration, see the UTM chapter.





Intrusion ProtectionThe FortiGate Intrusion Protection system combines signature detection and prevention with low latency and excellent reliability. With intrusion Protection, you can create multiple IPS sensors, each containing a complete configuration based on signatures. Then, you can apply any IPS sensor to each protection profile. The FortiGate intrusion protection system protects your network from outside attacks. Your FortiGate unit has two techniques to deal with these attacks.Anomaly-based defense is used when network traffic itself is used as a weapon. A host can be flooded with far more traffic than it can handle, making the host inaccessible. The most common example is the denial of service attack, in which an attacker directs a large number of computers to attempt normal access of the target system. If enough access attempts are made, the target is overwhelmed and unable to service genuine users. The attacker does not gain access to the target system, but it is not accessible to anyone else. The FortiGate unit DoS feature will block traffic over a certain threshold from the attacker, allowing connections from other legitimate users.Signature-based defense is used against known attacks or vulnerability exploits. These often involve an attacker attempting to gain access to your network. The attacker must communicate with the host in an attempt to gain access, and this communication will include particular commands or sequences of commands and variables. The IPS signatures include these command sequences, allowing the FortiGate unit to detect and stop the attack.The basis of signature-based intrusion protection are the IPS signatures, themselves. Every attack can be reduced to a particular string of commands or a sequence of commands and variables. Signatures include this information so your FortiGate unit knows what to look for in network traffic.Signatures also include characteristics about the attack it describes. These characteristics include the network protocol in which it will appear, the vulnerable operating system, and the vulnerable application.Before examining network traffic for attacks, the FortiGate will identify each protocol appearing in the traffic. Attacks are protocol-specific so your FortiGate unit conserves resources by looking for attacks only in the protocols used to transmit them. For example, the FortiGate unit will only examine HTTP traffic for the presence of a signature describing an HTTP attack.Once the protocol decoders separate the network traffic by protocol, the IPS engine examines the network traffic for the attack signatures.The IPS engine does not examine network traffic for all signatures, however. You must first create an IPS sensor and specify which signatures are included. You do not have to choose each signature you want to include individually, however. Instead, filters are used to define the included signatures.IPS sensors contain one or more IPS filters. A filter is simply a collection of signature attributes you specify. The signatures that have all of the attributes specified in a filter are included in the IPS signature.For example, if your FortiGate unit protects a Linux server running the Apache web server software, you could create a new filter to protect it. Set OS to Linux, and Application to Apache and the filter will include only the signatures applicable to both Linux and Apache. If you wanted to scan for all the Linux signatures and all the Apache signatures, you would create two filters, one for each.For more information on FortiGate IPS processes, features and configuration, see the UTM chapter.






v0h

Traffic ShapingTraffic shaping, when included in a security 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 security policies whose Action is ACCEPT, IPSEC, or SSLVPN. It is also available for all supported services, including H.323, TCP, UDP, ICMP, and ESPTraffic 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 security 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 addressTraffic shaping attempts to “normalize” traffic peaks/bursts to prioritize certain flows over others. But there is a physical limitation to the amount of data which can be buffered and to the length of time. Once these thresholds have been surpassed, frames and packets will be dropped, and sessions will be affected in other ways. For example, incorrect traffic shaping configurations may actually further degrade certain network flows, since the excessive discarding of packets can create additional overhead at the upper layers that may be attempting to recover from these errors.A basic traffic shaping approach is to prioritize certain traffic flows over other traffic whose potential discarding is less advantageous. This would mean that you accept sacrificing certain performance and stability on low-priority traffic, in order to increase or guarantee performance and stability to high-priority traffic.If, for example, you are applying bandwidth limitations to certain flows, you must accept the fact that these sessions can be limited and therefore negatively impacted. Traffic shaping applied to a security 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.




NAT vs. Transparent Mode The Purpose of a Firewall

Note that traffic shaping is effective for normal IP traffic at normal traffic rates. Traffic shaping is not effective during periods when traffic exceeds the capacity of the FortiGate unit. Since packets must be received by the FortiGate unit before they are subject to traffic shaping, if the FortiGate unit cannot process all of the traffic it receives, then dropped packets, delays, and latency are likely to occur.For more information on traffic shaping, see the Traffic Shaping chapter.

NAT vs. Transparent ModeThe 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, security policies define how traffic moves, or is prevented, from moving within the local network or to an external network or the Internet.

NAT modeIn 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. Security policies control communications through the FortiGate unit to both the Internet and between internal networks. In NAT mode, the FortiGate unit performs network address translation before IP packets are sent to the destination network. For example, a company has a FortiGate unit as their interface to the Internet. The FortiGate unit also acts as a router to multiple sub-networks within the company.

Figure 1: FortiGate unit in NAT mode

Port 1192.168.1.1

WAN1

172.20.120.129

Port 210.10.10.1 Policies controlling

traffic between

internal networks.

19

PoPoPPoPoPoPoPoPPoPortrtrttttrtrtrtrtrtrt 2222222210 1

299

NAT policies controlling

traffic between internal and

external networks.

Internal Netw

ork

10.10.10.0/24

Internal Netw

ork

192.168.1.0/24





The Purpose of a Firewall NAT vs. Transparent Mode

v0h

In this situation, as shown in Figure 1, the FortiGate unit is set to NAT mode. Using this mode, the FortiGate unit can have a designated port for the Internet, in this example, wan1 with an address of 172.20.120.129, which is the public IP address. The internal network segments are behind the FortiGate unit and invisible to the public access, for example port 2 with an address of 10.10.10.1. The FortiGate unit translates IP addresses passing through it to route the traffic to the correct subnet or the Internet.

How address translation worksIn NAT mode, security 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 security policies to determine where the request should go, in this case, out the external interface.The FortiGate unit changes the packet information of the return address to its external interface, while keeping track of the originating user request, and the originating PC address. Once modified, the FortiGate unit sends the packet information to the web server.

Figure 2: Sender’s IP internal address translated to the FortiGate unit’s external address

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

3

12

Destination: 172.50.20.20

Source: 10.10.10.2

Received

Packet

Web Server

172.50.20.20

Client PC

10.10.10.2


Source: 172.20.120.129

Internal

WAN1 31

2

31

2

al

Firewall PolicyNAT enabled

Sent

Packet





Figure 3: Web server sends to FortiGate external address and translated to internal address

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 tableThe 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 security 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 security policies.NAT policies are applied to network traffic after a security policy. For more information on central NAT tables, see “Central NAT table” on page 274.

Transparent modeIn 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. To configure the FortiGate unit for your network, all you have to do is configure a management IP address and a default route.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. Security policies control communications through the FortiGate unit to the Internet and internal network. No traffic can pass through the FortiGate unit until you add security policies.

3

12


Source: 172.50.20.20

Received

Packet

Web Server

172.50.20.20

Client PC

10.10.10.2


Source: 172.50.20.20

Internal

WAN1 31

2

31

2

al

WW

Firewall PolicyNAT enabled

Sent

Packet





The Purpose of a Firewall NAT vs. Transparent Mode

v0h

For example, the company has a router or other firewall in place. The network is simple enough that all users are on the same internal network. They need the FortiGate unit to perform antispam, antivirus and intrusion protection and similar traffic scanning. In this situation, as shown in Figure 4, the FortiGate unit is set to transparent mode. The traffic passing through the FortiGate unit does not change the addressing from the router to the internal network. Security policies and protection profiles define the type of scanning the FortiGate unit performs on traffic entering the network.

Figure 4: FortiGate unit in transparent mode

By default when shipped, the FortiGate unit operates in NAT mode. To use the FortiGate unit in Transparent mode, you need to switch its mode. When switched to a different mode, the FortiGate unit does not need to be restarted; the change is automatic.In the following example, the steps change the FortiGate unit to Transparent mode with an IP of 10.11.101.10, netmask of 255.255.255.0 and a default gateway of 10.11.101.1

To enable Transparent mode - web-based manager1 Go to System > Dashboard > Status.2 Select the [Change] link for Operation Mode and select Transparent from the drop-

down list.3 Enter the Management IP address and netmask 10.11.101.10 255.255.255.0.4 Enter the Default Gateway address of 10.11.101.1.5 Select Apply.

To enable Transparent mode - CLIconfig system settingsset opmode transparentset manageip 10.11.101.10 255.255.255.0set gateway 10.11.101.1

end

204.23.1.5

10.10.10.2WAN1

InternalIIIInIntter

AN11

Gateway to public

network

NAT policies controlling

traffic between internal and

external networks.





For information on unique Transparent mode firewall configurations, see “Advanced firewall concepts” on page 247.

Operating mode differencesThe FortiGate unit, running in either NAT or Transparent mode have essentially the same feature set. Due to the differences in the modes, however, some features are not available in Transparent mode. The list below outlines the key features not available in Transparent mode:• Network > DNS Databases• DHCP• Router (basic routing is available by going to Network > Routing Table)• Virtual IP• Load Balance• IPSec Concentrator (Transparent mode supports policy-based configurations)• SSL VPN• WCCP cache engine

Note: This guide and its examples are constructed with the FortiGate unit running in NAT mode, unless otherwise noted.





v0h

Life of a PacketDirected by security policies, a FortiGate unit screens network traffic from the IP layer up through the application layer of the TCP/IP stack. This chapter provides a general, high-level description of what happens to a packet as it travels through a FortiGate security system.

The FortiGate unit performs three types of security inspection:• stateful inspection, that provides individual packet-based security within a basic

session state• flow-based inspection, that buffers packets and uses pattern matching to identify

security threats• proxy-based inspection, that reconstructs content passing through the FortiGate unit

and inspects the content for security threats.Each inspection component plays a role in the processing of a packet as it traverses the FortiGate unit en route to its destination. To understand these inspections is the first step to understanding the flow of the packet.

Stateful inspectionWith 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.




Flow inspection Life of a Packet

Figure 5: Stateful inspection of packets through the FortiGate unit

Flow inspectionWith flow inspection, the FortiGate unit samples multiple packets in a session and multiple sessions, and uses a pattern matching engine to determine the kind of activity that the session is performing and to identify possible attacks or viruses. For example, if application control is operating, flow inspection can sample network traffic and identify the application that is generating the activity. Flow-based antivirus can sample network traffic and determine if the content of the traffic contains a virus, IPS can sample network traffic and determine if the traffic constitutes an attack. The security inspection occurs as the data is passing from its source to its destination. Flow inspection identifies and blocks security threats in real time as they are identified.

Figure 6: Flow inspection of packets through the FortiGate unit

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.

3

12

Received

Packet

31

2

SYN, IP, TCP

Sent

Packet

31

2

2

Received

Packet

3

22

IPS, Flow-AV,App Control

Sent

Packet

1222





Life of a Packet Proxy inspection

v0h

Proxy inspectionWith flow inspection, the FortiGate unit will pass all the packets between the source and destination, and keeps a copy of the packets in its memory. It then uses a reconstruction engine to build the content of the original traffic. The security inspection occurs after the data has passed from its source to its destination.Proxy inspection examines the content contained a content protocol session for security threats. Content protocols include the HTTP, FTP, and email protocols. Security threats can be found in files and other content downloaded using these protocols. With proxy inspection, the FortiGate unit downloads the entire payload of a content protocol sessions and re-constructs it. For example, proxy inspection can reconstruct an email message and its attachments. After a satisfactory inspection the FortiGate unit passes the content on to the client. If proxy inspection detects a security threat in the content, the content is removed from the communication stream before the it reaches its destination. For example, if proxy inspection detects a virus in an email attachment, the attachment is removed from the email message before its sent to the client. Proxy inspection is the most thorough inspection of all, although it requires more processing power, and this may result in lower performance.If you enable ICAP in a security policy, HTTP traffic intercepted by the policy is transferred to the ICAP servers in the ICAP profile added to the policy. The FortiGate unit is the surrogate, or “middle-man”, and carries the ICAP responses from the ICAP server to the ICAP client; the ICAP client then responds back, and the FortiGate unit determines the action that should be taken with these ICAP responses and requests.

Figure 7: Proxy inspection of packets through the FortiGate unit

FortiOS functions and security layersWithin 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.

Received

Packet

31

2

Email filter, webfilter, DLP, AV

Sent

Packet

31

2

31

2




Packet flow Life of a Packet

Packet flowAfter 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 security policy and UTM profile configuration. The diagram in Figure 8 on page 25 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 8 on page 25, in the first set of steps (ingress), a number of header checks take place to ensure the packet is valid and contains the necessary information to reach its destination. This includes:• Packet verification - during the IP integrity stage, verification is performed to ensure

that the layer 4 protocol header is the correct length. If not, the packet is dropped.• Session creation - the FortiGate unit attempts to create a session for the incoming data• IP stack validation for routing - the firewall performs IP header length, version and

checksum verifications in preparation for routing the packet.• Verifications of IP options - the FortiGate unit validates the rouging information

Table 1: FortiOS security functions and security layers

Security Function Stateful Flow ProxyFirewall IPsec VPN Traffic Shaping User Authentication Management Traffic SSL VPN Intrusion Prevention Flow-based Antivirus Application Control VoIP inspection Proxy Antivirus Email Filtering Web Filtering (Antispam) Data Leak Prevention





Life of a Packet Packet flow

v0h

Figure 8: Packet flow

InterfaceIngress 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 sensorDoS 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 checkingThe 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.

Interface(Link layer)

Interface

DoSSensor IPsec

IPsec

NAT(DNAT)

NAT(SNAT)

Routing

Routing

SessionTracking

TrafficShaping

UserAuthenticationSSL VPNManagement

TrafficSessionHelpers

IP IntegrityHeader checking

3 12

Packet

Packet flow: Ingress

3 12

Packet

StatefulInspection

Engine

IPSApplicationControl

Flow-basedAntivirus

VoIPInspection

Flow-based Inspection Engine

UTMNo (Fast Path)

No

Yes

Yes

Antivirus ICAPWeb FilterEmail FilterData LeakPrevention

Proxy-basedInspection

Engine

AdditionalProxy

InspectionRequired

PolicyLookup

Packet flow: Egress




Packet flow Life of a Packet

IPsecIf 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 17.DNAT must take place before routing so that the FortiGate unit can route packets to the correct destination.

RoutingThe 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 security policy engine to accept or deny the packet.

Policy lookupThe policy look up is where the FortiGate unit reviews the list of security 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 trackingPart 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.





Life of a Packet Packet flow

v0h

User authenticationUser authentication added to security 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 security 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 trafficThis 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 trafficFor 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 helpersSome 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 engineFlow-based inspection is responsible for IPS, application control, flow-based antivirus scanning and VoIP inspection. Packets are sent to flow-based inspection if the security policy that accepts the packets includes one or more of these UTM features.

Once the packet has passed the flow-based engine, it can be sent to the proxy inspection engine or egress.

Proxy-based inspection engineThe 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.

Note: Flow-based antivirus scanning is only available on some FortiGate models.




Example 1: client/server connection Life of a Packet

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

RoutingThe final routing step determines the outgoing interface to be used by the packet as it leaves the FortiGate unit.

EgressUpon completion of the scanning at the IP level, the packet exits the FortiGate unit.

Example 1: client/server connectionThe 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 server1 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 route6 Policy lookup7 User authentication8 Proxy inspection

8.1 Web Filtering 8.2 FortiGuard Web Filtering URL lookup8.3 Antivirus scanning

9 Source NAT10 Routing11 Interface transmission to network12 Packet forwarded to web server





Life of a Packet Example 1: client/server connection

v0h

Response from web server1 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 Tracking8 Next hop route9 Interface transmission to network10 Packet returns to client

Figure 9: Client/server connection

SessionTracking

PolicyLookup

UserAuthentication



DoSSensor

DoSSensor

NAT(SNAT)

Routing

Routing


NAT(SNAT)

Routing



NAT(DNAT)

3 12

FortiGate Unit

Web Filter FortiGuardWeb FilteringAntivirus

Antivirus

ProxyInspection

Engine

Proxy InspectionEngine

StatefulPolicyEngine

Stateful PolicyEngine

PacketExits

PacketEnters

Client sends packetto web server

FortiGuard

Web Server


3 12

SessionTracking

Packet exits andreturns to client

Internet




Example 2: Routing table update Life of a Packet

Example 2: Routing table updateThis example includes the following steps:1 FortiGate unit receives routing update packet2 Packet intercepted by FortiGate unit interface



4 IP integrity header checking, verifying the IP header length, version and checksums.5 Stateful policy engine

5.1 Management traffic (local traffic)6 Routing module

6.1 Update routing table

Figure 10: Routing table update

Example 3: Dialup IPsec with application controlThis example includes the following steps:1 FortiGate unit receives IPsec packet from Internet2 Packet intercepted by FortiGate unit interface



4 IP integrity header checking, verifying the IP header length, version and checksums.5 IPsec

5.1 Determines that packet matched IPsec phase 1 configuration5.2 Unencrypted packet

6 Next hop route7 Stateful policy engine

7.1 Session tracking


RoutingModule

ManagementTraffic


3 12

Packet

StatefulPolicyEngine

Update routing table

FortiGate Unit

Routingupdatepacket

DoSSensor

Routing Table





Life of a Packet Example 3: Dialup IPsec with application control

v0h

8 Flow inspection engine8.1 IPS8.2 Application control

9 Source NAT10 Routing11 Interface transmission to network12 Packet forwarded to internal server

Response from server1 Server sends response packet2 Packet intercepted by FortiGate unit interface

2.1 Link level CRC and packet size checking3 IP integrity header checking.4 DoS sensor5 Flow inspection engine

5.1 IPS5.2 Application control

6 Stateful policy engine6.1 Session tracking

7 Next hop route8 IPsec

8.1 Encrypts packet9 Routing10 Interface transmission to network11 Encrypted Packet returns to internet




Example 3: Dialup IPsec with application control Life of a Packet

Figure 11: Dialup IPsec with application control



IPsec

SourceNAT

Next HopRoute

Routing

Routing

SessionTracking

Encrypted orencapsulated packet

Response Packet

3 12

3 12

InternalServer

Encrypted orencapsulated packet

3 12

3 12

Stateful Policy Engine

Stateful Policy Engine

IPSApplication

Control

Flow Inspection Engine

Flow Inspection Engine


DoSSensor


DestintionNAT

Packet decryption

Packet encryption

Next HopRoute

SessionTrackingIPS

ApplicationControl

Packet Exits

PacketExits and returnsto source

IPsec packetreceived from Internet

Packet Enters


DoSSensor

IP IntegrityHeader checking IPsec NAT

FortiGate Unit





v0h

Firewall componentsThe 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 security 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 security policy uses similar components. This section briefly describes these components.The following topics are included in this section:• Interfaces• Addressing• Ports• Services• Schedules• UTM profiles

InterfacesInterfaces, 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.

PhysicalFortiGate units have a number of physical ports where you connect Ethernet or optical cables. Depending on the model, they can have anywhere from four to 40 physical ports. Some units have a grouping of ports labelled as internal, providing a built-in switch functionality.In FortiOS, the port names, as labeled on the FortiGate unit, appear in the web-based manager in the Unit Operation the Dashboard. They also appear when you are configuring the interfaces, by going to System > Network > Interface. As shown below, the FortiGate-60C has eight interfaces

Figure 12: FortiGate-60C physical interfaces




Interfaces Firewall components

Figure 13: FortiGate-60C interfaces on the Dashboard

Figure 14: Configuring the FortiGate-60C ports

Normally the internal interface is configured as a single interface shared by all physical interface connections - a switch. The switch mode feature has two states - switch mode and interface mode. Switch mode is the default mode with only one interface and one address for the entire internal switch. Interface mode allows you to configure each of the internal switch physical interface connections separately. This enables you to assign different subnets and netmasks to each of the internal physical interface connections.The larger FortiGate units can also include Advanced Mezzanine Cards (AMC), which can provide additional interfaces (ethernet or optical), with throughput enhancements for more efficient handling of specialized traffic. These interfaces appear in FortiOS as port amc/sw1, amc/sw2 and so on. In the following illustration, the FortiGate-3810A has three AMC cards installed: two single-width (amc/sw1, amc/sw2) and one double-width (amc/dw).





Firewall components Interfaces

v0h

Figure 15: FortiGate-3810A AMC card port naming

For more information on configuring physical ports, see “Addressing” on page 40.

Administrative accessInterfaces, 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• SNMPYou can select as many, or as few, even none, that are accessible by an administrator.

ExampleThis 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 manager1 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 - CLIconfig system interfaceedit wan1set ip 172.20.120.100/24set allowaccess https ssh

end

WirelessA wireless interface is similar to a physical interface only it does not include a physical connection. The FortiWiFi units enables you to add multiple wireless interfaces that can be available at the same time (the FortiWiFi-30B can only have one wireless interface). On FortiWiFi units, you can configure the device to be either an access point, or a wireless client. As an access point, the FortiWiFi unit can have up to four separate SSIDs, each on their own subnet for wireless access. In client mode, the FortiWiFi only has one SSID, and is used as a receiver, to enable remote users to connect to the existing network using wireless protocols.Wireless interfaces also require additional security measures to ensure the signal does not get hijacked and data tampered or stolen.

Virtual domainsVirtual 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.

VDOMs provide separate security domains that allow separate zones, user authentication, security 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, security policies, routing settings, and VPN settings.When a packet enters a VDOM, it is confined to that VDOM. In a VDOM, you can create security 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.

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

Note: Some smaller FortiGate units do not support virtual domains.






v0h

ExampleThis example shows how to enable VDOMs on the FortiGate unit and the basic and create a VDOM accounting on the DMZ2 port and assign an administrator to maintain the VDOM. First enable Virtual Domains on the FortiGate unit. When you enable VDOMs, the FortiGate unit will log you out.

To enable VDOMs - web-based manager1 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 - CLIconfig system globalset vdom-admin enable

end

Next, add the VDOM called accounting.

To add a VDOM - web-based manager1 Go to System > VDOM > VDOM, and select Create New.2 Enter the VDOM name accounting.3 Select OK.To add a VDOM - CLI

config vdomedit <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 manager1 Go to System > Network > Interface.2 Select the DMZ2 port row and select Edit.3 For the Virtual Domain drop-down list, select accounting.4 Select the Addressing Mode of Manual.5 Enter the IP address for the port of 10.13.101.100/24.6 Set the Administrative Access to HTTPS and SSH.7 Select OK.

To assign physical interface to the accounting Virtual Domain - CLIconfig globalconfig system interfaceedit dmz2set vdom accountingset ip 10.13.101.100/24set allowaccess https ssh

nextend





Virtual LANsThe 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.

ExampleThis 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 manager1 Go to System > Network > Interface and select Create New.

The Type is by default set to VLAN.2 Enter a name for the VLAN to vlan_accounting.3 Select the Internal interface.4 Enter the VLAN ID.

The VLAN ID is a number between 1 and 4094 that allow groups of IP addresses with the same VLAN ID to be associated together.

5 Select the Addressing Mode of Manual.6 Enter the IP address for the port of 10.13.101.101/24.7 Set the Administrative Access to HTTPS and SSH.8 Select OK.

To add a VLAN - CLIconfig system interfaceedit VLAN_1set interface internalset type vlanset vlanid 100set ip 10.13.101.101/24set allowaccess https ssh

nextend






v0h

ZonesZones are a group of one or more FortiGate interfaces, both physical and virtual, that you can apply security policies to control inbound and outbound traffic. Grouping interfaces and VLAN subinterfaces into zones simplifies the creation of security policies where a number of network segments can use the same policy settings and protection profiles. When you add a zone, you select the names of the interfaces and VLAN subinterfaces to add to the zone. Each interface still has its own address and routing is still done between interfaces, that is, routing is not affected by zones. Security policies can also be created to control the flow of intra-zone traffic.For example, in the illustration below, the network includes three separate groups of users representing different entities on the company network. While each group has its own set of port and VLANs, in each area, they can all use the same security policy and protection profiles to access the Internet. Rather than the administrator making nine separate security policies, he can add the required interfaces to a zone, and create three policies, making administration simpler.

Figure 16: Network zones

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 security policy to go between zone 1 and zone 3, but not between WAN2 and WAN1, or WAN1 and DMZ1.

Zone 1 policies

Zone 2 policies

Zone 3 policies

Zone 1

WAN1, DMZ1,VLAN 1, 2, 4

Zone 2

Internalports 1, 2, 3

Zone 3

WAN2, DMZ2,VLAN 3




Addressing Firewall components

ExampleThis 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 manager1 Go to System > Network > Interface.2 Select the arrow on the Create New button and select Zone.3 Enter a zone name of Zone_1.4 Select the Internal interface and the virtual LAN interface vlan_accounting from the

previous section.5 Select OK.

To create a zone - CLIconfig system zoneedit Zone_1set interface internal VLAN_1

end

AddressingFirewall addresses and address groups define network addresses that you can use when configuring a security policies’ source and destination address fields. The FortiGate unit compares the IP addresses contained in packet headers with security policy source and destination addresses to determine if the security policy matches the traffic. Addressing in security 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 addressThe 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.0Valid 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





Firewall components Addressing

v0h

When representing hosts by an IP Range, the range indicates hosts with continuous IP addresses in a subnet, such as 192.168.1.[2-10], or 192.168.1.* to indicate the complete range of hosts on that subnet. Valid IP Range formats include:• x.x.x.x-x.x.x.x, such as 192.168.110.100-192.168.110.120• x.x.x.[x-x], such as 192.168.110.[100-120]• x.x.x.*, such as 192.168.110.*When representing hosts by a FQDN, the domain name can be a subdomain, such as mail.example.com. A single FQDN firewall address may be used to apply a security 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>

ExampleThis 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 manager1 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- CLIconfig firewall addressedit Guestset type ipmaskset subnet 10.13.101.100/24set associated-interface port1

end

Note: An IP address 0.0.0.0 with netmask 255.255.255.255 is not a valid firewall address.

Caution: Be cautious when employing FQDN firewall addresses. Using a fully qualified domain name in a security policy, while convenient, does present some security risks, because policy matching then relies on a trusted DNS server. Should the DNS server be compromised, security policies requiring domain name resolution may no longer function properly.





ExampleThis 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 manager1 Go to Firewall > Address > Address and select Create New.2 For the Address Name, enter Guest.3 Leave the Type as Subnet/IP Range.4 Enter the IP address range of 10.13.101.[100-110].5 For the Interface, select Any.6 Select OK.

To add a firewall IP address to the port1 interface - CLIconfig firewall addressedit Guestset type iprangeset start-ip 10.13.101.100set end-ip 10.13.101.110

end

Geography based addressingAn option is available to add a geography-based address scheme. With this type of addressing, you indicate the geographic region, or country. The FortiGate unit includes an internal list of countries and IP addresses based on historical data from the FortiGuard network.When used in security policies, traffic originating or going to a particular country can be logged, blocked or specific filtering applied.In the following examples, an geographic-based address for China is added for the WAN1 port.

To add a geography-based address - web-based manager1 Go to Firewall > Address > Address and select Create New.2 Enter the Name of China3 For the Type, select Geography.4 From the Country list, select China.5 Select the Interface of WAN1.6 Select OK.

To add a geography-based address - CLIconfig firewall addressedit Chinaset type geographyset country CNset interface wan1

end






v0h

You can use a diagnose command to view more information about geography-based addressing. The command displays country and address information for the countries that have been added to firewall addresses.

diagnose firewall ipgeo {country-list | ip-list | ip2country}

Where:• country-list shows all of the countries that have been added to a firewall address.• ip-list shows the IP addresses of a specified country or all of the countries added

to firewall addresses.• ip2country shows the country of origin for a specified IP address. The address must

be assigned to one of the countries that has been added to a firewall address.

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

config firewall addressset type wildcardset wildcard 1.1.1.0/0.0.0.255

end

Fully Qualified Domain Name addressesUsing Fully Qualified Domain Name (FQDN) addresses in security 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 security 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 security policies for networks configured with dynamic addresses using DHCP.





You specify the TTL time in the CLI only. For example, to set the TTL for 30 minutes on an FQDN of www.example.com on port 1, enter the following commands:

config firewall addressedit FQDN_exampleset type fdqnset associated-interface port 1set fqdn www.example.comset cache-ttl 1800

end

Address groupsSimilar to zones, if you have a number of addresses or address ranges that require the same security policies, you can put them into address groups, rather than creating multiple similar policies. Because security 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 security 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.

ExampleThis example creates an address group accounting, where addresses for User_1 and User_2 have port association of Any. It is recommended to add the addresses you want to add to the group before setting up the address group.

To create an address group - web-based manager1 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 - CLIconfig firewall addrgrpedit accountingset member User_1set member User_2

Caution: Be cautious when employing FQDN firewall addresses. Using a fully qualified domain name in a security policy, while convenient, does present some security risks, because policy matching then relies on a trusted DNS server. Should the DNS server be compromised, security policies requiring domain name resolution may no longer function properly.






v0h

end

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

On FortiGate 30B, 50 and 60 series units, a DHCP server is configured, by default, on the Internal interface, as follows:

A FortiGate interface can provide the following DHCP services:• Basic DHCP servers with up to three IP address ranges per server• IPSec DHCP servers for IPSec (VPN) connections• DHCP relay for regular Ethernet or IPSec (VPN) connectionsAn interface cannot provide both a server and a relay for connections of the same type.You can configure one or more DHCP servers on any FortiGate interface. A DHCP server dynamically assigns IP addresses to hosts on the network connected to the interface. The host computers must be configured to obtain their IP addresses using DHCP. The IP range of each DHCP server must match the network address range. The routers must be configured for DHCP relay.

DHCP optionsWhen adding a DHCP server, you have the ability to include DHCP codes and options. The DHCP options are BOOTP vendor information fields that provide additional vendor-independent configuration parameters to manage the DHCP server. For example, you may need to configure a FortiGate DHCP server that gives out a separate option as well as an IP address. For example, an environment that needs to support PXE boot with Windows images.The option numbers and codes are specific to the particular application. The documentation for the application will indicate the values to use. Option codes are represented in a option value/HEX value pairs. The option is a value 1 and 255.You can add up to three DHCP code/option pairs per DHCP server.To configure option 252 with value http://192.168.1.1/wpad.dat - web-based manager1 Go to System > Network > DHCP Server and select Create New.2 Select a Mode of Server.3 Select the blue arrow to expand the Advanced options.4 Select Options.5 Enter a Code of 252.

Note: DHCP is not available when the FortiGate unit is operating in Transparent mode.

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





6 Enter the Options of 687474703a2f2f3139322e3136382e312e312f777061642e646174.

In the CLI, use the commands:config system dhcp serveredit <dhcp_server_number>set option1 252

687474703a2f2f3139322e3136382e312e312f777061642e646174end

For detailed information about DHCP options, see RFC 2132, DHCP Options and BOOTP Vendor Extensions.

ExampleThis 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 manager1 Go to Go to System > Network > DHCP Server and select Create New.2 Select the Interface of Internal.3 Select the Mode of Server.4 Enter the IP Range of 10.13.101.100 to 10.13.101.110.5 Enter a Netmask of 255.255.255.0.6 Enter a Default Gateway of 10.10.101.2.7 Select the blue arrow to expand the Advanced options.8 Set a Lease Time of five days.9 Select OK.

To configure a DHCP server on the internal interface - CLIconfig system dhcp serveredit 1config ip-rangeedit 1set start-ip 10.13.101.100set end-ip 10.13.101.105

endset server-type regularset interface internalset netmask 255.255.255.0set default-gateway 10.13.101.2set 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.





http://tools.ietf.org/html/rfc2132


v0h

ExampleThis 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 manager1 Go to System > Network > DHCP Server and select Create New.2 Select the internal interface and select the Mode of Relay.3 Select the Type of Regular.4 Enter the DHCP Server IP address of 172.20.120.55.5 Select OK.

To configure a DHCP relay on the internal interface - CLIconfig system interfaceedit internalset dhcp-relay-service enableset dhcp-relay-type regularset dhcp-relay-ip 172.20.120.55

end

IP reservation with DHCPWithin the DHCP pool of addresses, you can ensure certain computers will always have the same address. This can be to ensure certain users always have an IP address when connecting to the network, or if you want a device that connects occasionally to have the same address for monitoring its activity or use.In the example below, the IP address 172.20.19.69 will be matched to MAC address 00:1f:5c:b8:03:57.

To configure IP reservation - web-based manager1 Go to System > Network > DHCP Server.2 Select the DHCP server from the list.3 Select IP Reservation and select Create New.4 Enter an IP address of 172.20.19.695 Enter the MAC address of 00:1f:5c:b8:03:57.6 Select OK.

To configure IP reservation - CLIconfig sys dhcp serveredit 1config reserved-addressedit 1set ip 172.20.19.69set mac 00:1f:5c:b8:03:57

endend

Alternatively, an administrator can manually select an IP address from the assigned address list and set it to be linked to that MAC address automatically.





To reserve an IP from an assigned list1 Go to System > Network > DHCP Server.2 Select the DHCP server from the list.3 Select IP Reservation and select Add from DHCP Client List.4 When the DHCP Client List window appears, select the check boxes beside the IP

addresses and select Add to Reserved.

IP poolsAn 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.40The 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.20The port2 interface overlap IP range with IP_pool_2 is:• (2.2.2.0-2.2.2.255) & (2.2.2.10-2.2.2.20) = 2.2.2.10-2.2.2.20The port2 interface overlap IP range with IP_pool_3 is:• (2.2.2.0-2.2.2.255) & (2.2.2.30-2.2.2.40) = 2.2.2.30-2.2.2.40And the result is:• The port1 interface answers ARP requests for 1.1.1.10-1.1.1.20• The port2 interface answers ARP requests for 2.2.2.10-2.2.2.20 and for 2.2.2.30-

2.2.2.40Select NAT in a security policy and then select Dynamic IP Pool. Select an IP pool to translate the source address of packets leaving the FortiGate unit to an address randomly selected from the IP pool.IP pools cannot be set up for a zone. IP pools are connected to individual interfaces.

ExampleThis 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 manager1 Go to Firewall > Virtual IP > IP Pool and select Create New.2 Enter the Name of Guest.






v0h

3 Enter the IP Range/Subnet of 10.13.101.100-10.13.101.110.4 Select OK.

To configure an IP Pool - CLIconfig firewall ippooledit Guestset startip 10.13.101.100set endip 10.13.101.110

end

IP Pools for security policies that use fixed portsSome 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 security policy for NAT policies to prevent source port translation.

config firewall policyedit 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 matchingWhen 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 addressesIn this case, the FortiGate unit always matches the IP addressed one to one. If you enable fixedport in such a case, the FortiGate unit preserves the original source port. This may cause conflicts if more than one security policy uses the same IP pool, or the same IP addresses are used in more than one IP pool.

Scenario 2: The number of source addresses is more than that of IP pool addressesIn this case, the FortiGate unit translates IP addresses using a wrap-around mechanism.

Original address Change to192.168.1.1 172.16.30.1

192.168.1.2 172.16.30.2

...... ......

192.168.1.254 172.16.30.254





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.

Scenario 3: The number of source addresses is fewer than that of IP pool addressesIn this case, some of the IP pool addresses are used and the rest of them are not be used.

IPv6Internet Protocol version 6 (IPv6) is the next-generation version of IP addressing, to eventually replace IPv4. IPv6 was developed because there is a concern that in the near future, the available addresses for the IPv4 infrastructure will be exhausted. The IPv6 infrastructure will supplement, and eventually, replace the IPv4 standard.Where IPv4 uses 32 bit addressing, IPv6 uses 128 bit addressing, effectively providing trillions upon trillions of unique addresses, whereas IPv4 can have a a little over 4 billion. With this larger address space, allocating addresses and routing traffic becomes easier, and network address translation (NAT) becomes virtually unnecessary.Where IPv4 addresses are written numerals separated by a decimal, the IPv6 address is written with hexadecimal digits separated by a colon. For example, fe80:218:8bff:fe84:4223.By default, the FortiGate unit is not enabled to use IPv6 addressing. To enable this feature, go to System > Admin > Settings and select IPv6 Support on GUI. When enabled you can use IPv6 addressing on any of the address-dependant components of the FortiGate unit, including security policies, interface addressing, DNS servers. IPv6 addressing can be configured on the web-based manager and in the CLI.For further information on IPV6 in FortiOS, see “IPv6” on page 167.


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

...... ......


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





Firewall components Ports

v0h

ExampleThis 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 manager1 Go to System > Network > Interface.2 Select WAN1 row and select Edit.3 Select the Addressing Mode of Manual.4 Enter the IPv6 Address of 2001:db8:0:1234:0:567:1:1.5 For Administrative Access select HTTPS and SSH.6 Select OK.

To create IP address for the WAN1 interface - CLIconfig system interfaceedit wan1config ipv6set ip6-address 2001:db8:0:1234:0:567:1:1set ip6-allowaccess https ssh

endend

ExampleThis 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 manager1 Go to Firewall > Address > Address.2 On the Create New button, click the down arrow on the right.

If there is no arrow, ensure you have enabled IPv6 by going to System > Admin > Settings and select IPv6 Support on GUI.

3 Select IPv6 Address.4 For the Address Name, enter Guest.5 Enter the IP address of 2001:db8:0:1234:0:567:1:1/128.6 Select OK.

To add a firewall IPv6 address - CLIconfig firewall address6edit Guestset ip6 2001:db8:0:1234:0:567:1:1/128

end

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




Ports Firewall components

Originating traffic

Receiving trafficWhen 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)DNS lookup; RBL lookup UDP 53

FortiGuard Antispam or Web Filtering rating lookup UDP 53 or UDP 8888

FDN server listSource 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

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

UDP 514

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 updateWhen requesting updates from a FortiManager unit instead of directly from the FDN, this port must be reconfigured as TCP 8890.

TCP 443

FortiGuard Analysis and Management Service TCP 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

Function Port(s)FortiGuard Antivirus and IPS update pushThe 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 management from a FortiManager unit; user authentication for policy override

TCP 443





Firewall components Ports

v0h

Closing specific ports to trafficBy 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 security 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 113TCP 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 security policies, and thereby close this port. For each network interface that should not respond to ident requests on TCP port 113, enter the following CLI commands:

config system interfaceedit <port_name>set ident-accept enable

end

For example, to disable ident responses on a network interface names port1, enter the following commands:

config system interfaceedit port1set ident-accept enable

end

SSL management tunnel from FortiGuard Analysis and Management Service (FortiOS v3.0 MR6 or later)

TCP 541

HA heartbeat (FGCP L2) TCP 703

User authentication keep alive and logout for policy override (default value of port for HTTP traffic)This port is closed until enabled by the auth-keepalive command.

TCP 1000

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 portalThis feature is available on FortiGate-1000A, FortiGate-3600A, andFortiGate-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)




Using virtual IPs for port forwarding and destination NAT Firewall components

Port 541By default, FortiGate units use this port to initiate an SSL-secured management tunnel connection to centralized device managers such as the FortiGuard Analysis and Management Service.If you do not use centralized management you can make your FortiGate unit less visible to probes. You can disable the management tunnel feature, and thereby close this port using the following CLI command:

config sys central-management set status disable

end

Using virtual IPs for port forwarding and destination NATVirtual IP addresses (VIPs) can be used when configuring security policies to translate IP addresses and ports of packets received by a network interface. When the FortiGate unit receives inbound packets matching a security 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. Translating IP address using virtual IPs is also called destination NAT, or DNAT. Translating ports is also called port forwarding.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 security policy.

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.

ExampleThis simple example adds a virtual IP of 10.13.100.1 that allows users on the Internet to connect to a web server on the DMZ IP address of 192.168.1.1. In the example, the wan1 interface of the FortiGate unit is connected to the Internet and the dmz1 interface is connected to the DMZ network.

To add a static NAT virtual IP for a single IP address - web-based manager1 Go to Firewall > Virtual IP > Virtual IP and select Create New.2 For the Name, enter Static_NAT.3 Select the External interface of wan14 Enter the External IP Address of 10.13.100.1.5 Enter the Mapped IP Address of 192.168.1.1.6 Select OK.

Note: In Transparent mode, from the CLI, you can configure NAT security policies that include Virtual IPs and IP pools. For more information, see the System Administration chapter of The Handbook.





Firewall components Using virtual IPs for port forwarding and destination NAT

v0h

To add a static NAT virtual IP for a single IP address - CLIconfig firewall vipedit Static_NATset extintf wan1set extip 10.13.100.1set mappedip 192.168.1.1

end

Inbound connectionsVirtual IPs can be used in conjunction with security policies whose Action is not DENY to apply bidirectional NAT, also known as inbound NAT.When comparing packets with the security policy list to locate a matching policy, if a security policy’s Destination Address is a virtual IP, FortiGate units compare a packets’ destination address to the virtual IP’s external IP address. If they match, the FortiGate unit applies the virtual IP’s inbound NAT mapping, which specifies how the FortiGate unit translates network addresses and/or port numbers of packets from the receiving (external) network interface to the network interface connected to the destination (mapped) IP address or IP address range.In addition to specifying IP address and port mappings between interfaces, virtual IP configurations can optionally bind an additional IP address or IP address range to the receiving network interface. By binding an additional IP address, you can configure a separate set of mappings that the FortiGate unit can apply to packets whose destination matches that bound IP address, rather than the IP address already configured for the network interface.

DNAT and virtual IPIf the NAT check box is not selected when building the security 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.You can define alternate IP addresses for the reply traffic. When configuring the VIP addresses, you can define alternate source addresses for the return traffic. When configuring the VIP, select the Source Address Filter option and enter the IP address or address range.The CLI command is:

config firewall vipedit local-vipset src-filter 172.20.120.129/24, 172.20.120.3-172.20.120.10set extip x.x.x.xset mappedip y.y.y.yset port-forward enable

...end

This enables packets from different sources to be translated to different VIP (or ports). By default, the source filter is set to 0.0.0.0, or all source IPs.





Virtual IP options for port forwarding and DNATThe following table describes combinations of PAT and/or NAT that are possible when configuring a security policy with a virtual IP.Depending on your configuration of the virtual IP, its mapping may involve port address translation (PAT), also known as port forwarding or network address port translation (NAPT), and/or network address translation (NAT) of IP addresses.If you configure NAT in the virtual IP and security 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)

A typical example of static NAT is to allow client access from a public network to a web server on a private network that is protected by a FortiGate unit. Reduced to its essence, this example involves only three hosts, as shown in Figure 17: the web server on a private network, the client computer on another network, such as the Internet, and the FortiGate unit connecting the two networks.When a client computer attempts to contact the web server, it uses the virtual IP on the FortiGate 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.

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 Port Forwarding

Static, one-to-one NAT mapping with port forwarding: an external IP address is 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 Balancing with Port Forwarding

Dynamic, one-to-many NAT mapping with port forwarding: 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.





Firewall components Using virtual IPs for port forwarding and destination NAT

v0h

Figure 17: A simple static NAT virtual IP example

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 security policy for the virtual IP. The virtual IP settings map 192.168.37.4 to 10.10.10.42, so the FortiGate unit changes the packets’ addresses. The source address is changed to 10.10.10.2 and the destination is changed to 10.10.10.42. The FortiGate unit makes a note of this translation in the firewall session table it maintains internally. The packets are then sent on to the web server.

Figure 18: Example of packet address remapping during NAT from client to server

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.

Client IP

192.168.37.55

Server IP10.10.10.42

Virtual IP192.168.37.4

Internal IP10.10.10.2

Source IP 10.10.10.2

Destination IP 10.10.10.42

31

2

NAT with a virtual IP

Source IP 192.168.37.55


31

2





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 19: Example of packet address remapping during NAT from server to client

In the previous example, the NAT check box is checked when configuring the security policy. If the NAT check box is not selected when building the security policy, the resulting policy does not perform full NAT; instead, it performs destination network address translation (DNAT).For inbound traffic, DNAT translates packets’ destination address to the mapped private IP address, but does not translate the source address. The web server would be aware of the client’s IP address. For reply traffic, the FortiGate unit translates packets’ private network source IP address to match the destination address of the originating packets, which is maintained in the session table.

Outbound connectionsVirtual IPs can also affect outbound NAT, even though they are not selected in an outbound security 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.

Source IP 10.10.10.42


31

2

NAT with a virtual IP

Source IP 192.168.37.4


31

2





Firewall components Services

v0h

Virtual IP, load balance virtual server / real server limitationsThe 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.

ServicesServices 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. Security policies use service definitions to match session types. You can organize related services into service groups to simplify your security 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 serviceShould 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.

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

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.




Schedules Firewall components

To create a custom service - web-based manager1 Go to Firewall > Service > Custom and select Create New.2 Enter the following and select Add:

3 Select OK.

To create a custom service - CLIconfig firewall service customedit Widgetset protocol TCP/UDP/SCTPset tcp-portrange 9620:4545-4550

end

SchedulesWhen you add security 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.

ExampleThis 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 security 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 manager1 Go to Firewall > Schedule > Recurring, and select Create New.2 Enter the schedule Name of Lunch-Surfing.

Name Widget

Protocol Type TCP/UDP/SCTP

Protocol TCP

Source PortLow 9620

Hi 9620

Destination PortLow 4545

High 4550





Firewall components Schedules

v0h

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 - CLIconfig firewall schedule recurringedit Lunch-Surfing

set day monday tuesday wednesday thursday fridayset start 12:00set end 1:00

end

ExampleThis example creates a one-time schedule for a security 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 security 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 manager1 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.

To create a firewall schedule - CLIconfig firewall schedule onetimeedit Xmas-Shutdown

set start 00:00 2009/12/25set end 23:00 2010/01/01

end

/StartYear 2009

Month 12

Day 25

Hour 00

Minute 00

StopYear 2010

Month 01

Day 01

Hour 23

Minute 00




Schedules Firewall components

Schedule groupsYou can organize multiple firewall schedules into a schedule group to simplify your security 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 security policy.Schedule groups can contain both recurring and one-time schedules. Schedule groups cannot contain other schedule groups.

ExampleThis example creates a schedule group for the schedules created in the previous schedule examples. The schedule group enables you to have one security policy that covers both schedules, rather than creating two separate policies.

To create a firewall schedule group - web-based manager1 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 - CLIconfig firewall schedule groupedit Schedulesset member Lunch-Surfing Xmas-Shutdown

end

Schedule expiryThe schedule in a security policy enables certain aspects of network traffic to occur for a specific length of time. What it does not do however, is police that time. That is, the policy is active for a given time frame, and as long as the session is open, traffic can continue to flow.For example, in an office environment, Skype use is allowed between noon and 1pm. During that hour, any Skype traffic continues. As long as that session is open, after the 1pm end time, the Skype conversations can continue, yet new sessions will be blocked. Ideally, the Skype session should close at 1pm.Using a CLI command you can set the schedule to terminate all sessions when the end time of the schedule is reached. Within the config firewall command enter the command:

set schedule-timeout enable

By default, this is set to disable.

Identity-based policiesIt is important to note that this setting is similar to the termination time of an identity-based policy, also known as an authentication policy. These can be used together. If user authentication is used, FortiOS will use the Hard Timeout option. With a combination of the schedule timeout and the authentication timeout, FortiOS will use whichever time is shorter.





Firewall components UTM profiles

v0h

For example, Example.com has a schedule policy to use P2P applications between 12:00 and 1:00, and a user authentication timeout of 30 minutes.With user authentication, if a user logs in at 12:15, their authentication time will log them off at 12:45 (30 minutes later). If they log in at 12:45, the firewall schedule will log them out at 1:00 (15 minutes later).Equally, if no authentication is used, and a user logs in at 12:45, the schedule will log them out at 1:00 (45 minutes later). If they log in at 12:55, they will also be logged out at 1:00 (5 minutes later). The following table illustrates this point:

For more information on authentication policies, see the System Administration Guide chapter of The Handbook.

UTM profilesWhere security 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 security policy. You can configure sets of UTM profiles for the traffic types handled by a set of security policies that require identical protection levels and types, rather than repeatedly configuring those same UTM profile settings for each individual security 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 security policy by selecting the UTM profile type.

Profiles and sensorsThe 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.

Authentication Session Start Session endYes 12:15 30 minutes (expire at 12:45 - authentication timeout of 30

minutes)

12:45 15 minutes (expire at 1:00 - end of the firewall schedule)

No 12:15 45 minutes (expire at 1:00 - end of firewall schedule)

12:55 5 minutes (expire at 1:00 - end of firewall schedule)




UTM profiles Firewall components

For both categories, you create a unique set of criteria for the profile or sensor and select it for the security 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.

ExampleThis 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 manager1 Go to UTM Profiles > AntiVirus > Profile and select the plus sign in the upper right

corner of the window.2 Enter the Name of email_scan.3 For the Virus Scan row, select IMAP, POP3 and SMTP.4 Select OK.

To create a antivirus profile for email - CLIconfig antivirus profileedit email_scanconfig imapset options scan

endconfig smtpset options scan

endconfig pop3set options scan

endend





v0h

Security PoliciesSecurity policies control all traffic attempting to pass through the FortiGate unit, between FortiGate interfaces, zones, and VLAN subinterfaces.Security 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 security policy matching the packet.Security 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 security 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• Security policy examplesYou configure security 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 security 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 security policy, the FortiGate unit performs the configured Action and any other configured options on all packets in the session.Packet handling actions can be ACCEPT, DENY, IPSEC or SSL-VPN.




Policy order Security Policies

• ACCEPT policy actions permit communication sessions, and may optionally include other packet processing instructions, such as requiring authentication to use the policy, or specifying one or more UTM profiles to apply features such as virus scanning to packets in the session. An ACCEPT policy can also apply interface-mode IPSec VPN traffic if either the selected source or destination interface is an IPSec virtual interface.

• DENY policy actions block communication sessions, and you can optionally log the denied traffic. If no security policy matches the traffic, the packets are dropped, therefore it is not required to configure a DENY security policy in the last position to block the unauthorized traffic. A DENY security 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 security 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 orderEach time a FortiGate unit receives a connection attempting to pass through one of its interfaces, the unit searches its security policy list for a matching security 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 security 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 security policies. Matching security policies are determined by comparing the security 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 security 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 security policy is applied to a connection. Subsequent possible matches are not considered or applied. Ordering policies from most specific to most general prevents policies that match a wide range of traffic from superseding and effectively masking policies that match exceptions.For example, you might have a general policy that allows all connections from the internal network to the Internet, but want to make an exception that blocks FTP. In this case, you would add a policy that denies FTP connections above the general policy.





Security Policies Creating basic policies

v0h

Figure 20: Example: Blocking FTP — Correct policy order

FTP connections would immediately match the deny policy, blocking the connection. Other kinds of services do not match the FTP policy, and so policy evaluation would continue until reaching the matching general policy. This policy order has the intended effect. But if you reversed the order of the two policies, positioning the general policy before the policy to block FTP, all connections, including FTP, would immediately match the general policy, and the policy to block FTP would never be applied. This policy order would not have the intended effect.

Figure 21: Example: Blocking FTP — Incorrect policy order

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.

You can arrange the security 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 security policy will be applied to the traffic session.

Creating basic policiesThis section describes how to configure basic security 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.

}Exception}General

}Exception}General

Note: A default security 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 security 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.

Source interface/Zone Internal

Source address 10.13.20.22

Destination interface/Zone WAN1

Destination address 172.20.120.141




Creating basic policies Security Policies

Using an interface of “any”When adding a security policy with Source interface/zone or Destination interface/zone set to ANY, that the security policy list can only be displayed in Global View. This is because a security 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 security policy with any as the source or destination interface is only clear on the global policy list.

Basic accept policy exampleWith this basic accept policy example, the security 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 manager1 Go to Policy > Policy > Policy and select Create New.2 Enter the following and select OK:

To create a basic accept policy for HTTP - CLIconfig firewall policyedit 1set srcintf internalset scraddr 10.13.20.22set dstintf wan1set dstaddr allset action acceptset schedule alwaysset service http

end

Basic deny policy exampleWith this basic deny policy example, the security 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.




Destination address ALL

Schedule always

Service HTTP

Action ALLOW





Security Policies Creating basic policies

v0h

To create a basic deny policy for FTP - web-based manager1 Go to Policy > Policy > Policy and select Create New.2 Enter the following and select OK:

To create a basic accept policy for FTP - CLIconfig firewall policyedit 1set srcintf internalset srcaddr 10.13.20.22set dstintf wan1set dstaddr 172.20.120.141set action denyset schedule alwaysset service ftp

end

Basic VPN policy exampleWith this basic VPN policy example, the security 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 security policy would be configured on the Branch office FortiGate unit.

To create a basic VPN policy - web-based manager1 Go to Policy > Policy > Policy and select Create New.2 Enter the following and select OK:





Schedule always

Service FTP

Action DENY





Schedule always

Service any

Action IPSEC

VPN Tunnel Select Head_Office from the configured list of VPN tunnels.




Security policy examples Security Policies

To create a basic VPN tunnel - CLIconfig firewall policyedit 1set srcintf internalset srcaddr 10.13.20.22set dstintf wan1set dstaddr 172.20.120.141set action allowset schedule alwaysset service anyset vpntunnel Head_Office

end

Security policy examplesThis section provides some simple, real-world, examples of security policies you can use as a starting point when creating policies for your network.

Blocking an IP addressThis example describes how to create a security 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 security policy to block the address.

Add an AddressFirst 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 manager1 Go to Firewall Objects > Address > Address and select Create New.2 Enter a Name of Blocked_IP.3 Enter the IP address and subnet of 172.20.120.29/255.255.255.255.

The subnet is set to 255.255.255.255 to block the specific address. If you wanted to block the entire subnet enter 172.20.120.0/255.255.255.0.

To add an address entry - web-based CLIconfig firewall addressedit Blocked_IPset subnet 172.20.120.29/32

end

Add a Security PolicyWith the address added, you can now create the DENY security 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.





Security Policies Security policy examples

v0h

To add a security policy - web-based manager1 Go to Policy > Policy > Policy and select Create New.2 Complete the following and select OK:

3 Move the security policy to the top of the policy list.

To add a security policy - web-based CLIconfig firewall policyedit 1set srcintf wan1set srcaddr Blocked_IPset dstintf Internalset dstaddr allset action denyset schedule alwaysset service any

end

Scheduled access policiesFirewall 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 59.This example describes security 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 weekendIt should be noted that a security 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.

Source Interface/Zone WAN1

Source Address Blocked_IP

Destination Interface/Zone Internal

Destination Address All

Schedule Always

Service ALL

Action DENY





Configuring the schedulesBegin by adding the schedule time when the security policies take affect.

To configure schedules - web-based manager1 Go to Firewall Objects > 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 New6 Enter the schedule Name of lunch-time.7 Select the days of the week this schedule is employed. In this case, Monday through

Friday.8 Select the Start Hour of 12.9 Select the Stop Hour of 14.10 Select OK.11 Select Create New12 Enter the schedule Name of late evening early morning.13 Select the days of the week this schedule is employed. In this case, Monday through

Friday.14 Select the Start Hour of 18.15 Select the Stop Hour of 08.16 Select OK.

To configure schedules - web-based managerconfig firewall schedule recurringedit week-endset day sunday saturday

nextedit lunch-timeset day monday tuesday wednesday thursday fridayset end 14:00set start 12:00

nextedit late evening to early morningset day monday tuesday wednesday thursday fridayset end 08:00set start 18:00

nextend

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.






v0h

Configuring the IP addressesConfigure 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 manager1 Go to Firewall Objects > Address > Address and select Create New.2 Enter a Name of Admin_PCs.3 Enter the Subnet/IP Range of 192.168.1.200-192.168.1.254.4 Select OK.5 Select Create New.6 Enter the Name of example.com7 Select the Type of FQDN.8 Enter the FQDN of www.example.com.9 Select OK.10 Select Create New.11 Enter the Name example2.com12 Select the Type of FQDN.13 Enter the FQDN of www.example2.com.14 Select OK.

To configure addresses and web sites - CLIconfig firewall addressedit Admin_PCsset type iprangeset end-ip 192.168.1.254set start-ip 192.168.1.200

nextedit example.comset type fqdnset fqdn www.example.com

nextedit example2.xomset type fqdnset fqdn www.example2.com

nextend

Configuring the security policiesWith the key components, the schedules and addresses, create the security 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 security policies - web-based manager1 Go to Firewall Objects > Policy > Policy and select Create New.2 Complete the following for the weekend access policy and select OK:





3 Select Create New.4 Complete the following for the administrator access policy and select OK:

5 Select Create New.6 Complete the following for the lunch-time surfing policy and select OK:

7 Select Create New.8 Complete the following for the overnight policy and select OK:

Source Interface/Zone Internal

Source Address All

Destination Interface/Zone WAN1


Schedule week-end

Service ALL

Action Accept

NAT Select to Enable.

Comments Week-end policy.


Source Address Admin_PCs



Schedule Always

Service ALL

Action Accept


Comments Admin PCs no restriction.


Source Address All



Schedule lunch-time

Service ALL

Action Accept


Comments Lunch-time policy.


Source Address All



Schedule late_eveing_early_morning

Service ALL

Action Accept






v0h

9 Select Create New.10 Complete the following for the web site access policy and select OK:

To create the security policies - CLIconfig firewall policyedit 1set srcintf internalset dstintf wan1set srcaddr allset dstaddr allset action acceptset comments week-end policyset schedule week-endset service ANYset nat enable

nextedit 2set srcintf internalset dstintf wan1set srcaddr Admin_PCsset dstaddr allset action acceptset comments Admin PCs no restrictionset schedule alwaysset service ANYset nat enable

nextedit 3set srcintf internalset dstintf wan1set srcaddr allset dstaddr allset action acceptset comments lunch time policyset schedule lunch-timeset service ANYset nat enable

next


Comments Late evening to early morning policy.


Source Address All

Destination Interface/Zone example.com and example2.com


Schedule Always

Service ALL

Action Accept


Comments Access to the example.com websites policy.





edit 4set srcintf internalset dstintf wan1set srcaddr allset dstaddr allset action acceptset comments “late evening to early morning policy”set schedule “late evening to early morning”set service ANYset nat enable

nextedit 5set srcintf internalset dstintf wan1set srcaddr allset dstaddr example.com example2.comset action acceptset schedule alwaysset service ANYset nat enable

nextend





v0h

TroubleshootingWhen the security 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 security policies. This chapter outlines some troubleshooting tips and steps to diagnose where the traffic is not getting through, or letting too much traffic through. For more troubleshooting options and methods, see the Troubleshooting Guide chapter of The Handbook.This chapter includes the topics:• Basic policy checking• Verifying traffic• Using log messages to view violation traffic• Traffic trace• Packet sniffer

Basic policy checkingBefore going into a deep troubleshooting session, first verify a few simple settings in the security policy configuration to ensure everything is setup correctly.For example:• Verify the policy position. The FortiGate unit evaluates each policy in the security 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 security policies. Is the order of the policies affecting traffic flow? For more information see “Policy order” on page 66.

• 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 security policy list (Firewall > Policy > Policy), the Status column indicates whether a security policy is enabled or not. To be enabled, the check box must be selected.

Verifying trafficWith many security 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 security policy table. These steps are only available in the web-based manager.




Using log messages to view violation traffic Troubleshooting

To view the traffic count on security policies1 Go to Policy > Policy > Policy.2 Select Column Settings in the upper right of the window.3 From Available fields list, select Count.4 Select the right-facing arrow to add it to the Show these fields column.5 Select OK.As packets hit this policy, the count will appear in the column in kilobytes.

Using log messages to view violation trafficSecurity 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 security policy matching the packet. If no Security Policy is matching the traffic, the packets are dropped. Because of this, you do not need to configure a DENY Security 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 security 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 security policy and enable logging. In this example, the security 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 manager1 Go to Policy > Policy > Policy and select Create New.2 Enter the following:

3 Select Log Violation Traffic.4 Select OK.

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.





Schedule always

Service HTTP

Action DENY





Troubleshooting Traffic trace

v0h

To create a basic accept policy for FTP - CLIconfig firewall policyedit 1set srcintf internalset srcaddr 10.13.20.22set dstintf wan1set dstaddr 172.20.120.141set action denyset schedule alwaysset service httpset 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 traceTraffic tracing enables you to follow a specific packet stream. View the characteristics of a traffic session though specific security 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 tableThe 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 manager1 Go to System > Dashboard > Status.2 Select Add Content > Top Sessions.3 In the Top Sessions pane, select Details.The Policy ID displays which security 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 CLIdiagnose sys session list

The session table output using the CLI is very verbose. You can use filters to display only the session data of interest. An entry is placed in the session table for each traffic session passing through a security policy.




Traffic trace Troubleshooting

Sample outputsession info: proto=6 proto_state=05 expire=89 timeout=3600

flags=00000000 av_idx=0 use=3bandwidth=204800/sec guaranteed_bandwidth=102400/sec

traffic=332/sec prio=0 logtype=session ha_id=0 hakey=4450tunnel=/state=log shape may_dirty statistic(bytes/packets/err): org=3408/38/0 reply=3888/31/0

tuples=2orgin->sink: org pre->post, reply pre->post oif=3/5

gwy=192.168.11.254/10.0.5.100hook=post dir=org act=snat 10.0.5.100:1251-

>192.168.11.254:22(192.168.11.105:1251)hook=pre dir=reply act=dnat 192.168.11.254:22-

>192.168.11.105:1251(10.0.5.100:1251)pos/(before,after) 0/(0,0), 0/(0,0)misc=0 domain_info=0 auth_info=0 ftgd_info=0 ids=0x0 vd=0

serial=00007c33 tos=ff/ff

Filter options enable you to view specific information from this command:

diagnose sys session filter <option>

The <option> values available include the following:

clear clear session filter

dport dest port

dst destination IP address

negate inverse filter

policy policy ID

proto protocol number

sport source port

src source IP address

vd index of virtual domain. -1 matches all

Even though UDP is a sessionless protocol, the FortiGate unit still keeps track of the following two different states:• UDP reply not seen with a value of 0• UDP reply seen with a value of 1The table below shows the firewall session states from the session table:State Meaninglog 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.






v0h

Finding object dependenciesAn 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 security 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 security 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 outputentry used by table firewall.address:name '10.98.23.23_host’entry used by table firewall.address:name 'NAS'entry used by table firewall.address:name 'all'entry used by table firewall.address:name 'fortinet.com'entry used by table firewall.vip:name 'TORRENT_10.0.0.70:6883'entry used by table firewall.policy:policyid '21'entry used by table firewall.policy:policyid '14'entry used by table firewall.policy:policyid '19'

In this example, the interface has dependent objects, including four address objects, one VIP, and three security policies.

Flow traceTo trace the flow of packets through the FortiGate unit, use the command

diagnose debug flow trace start

Follow the packet flow by setting a flow filter using the command:diagnose debug flow filter <option>

Filtering options include:

addr IP address

clear clear filter

daddr destination IP address

dport destination port

negate inverse filter

port port

proto protocol number

saddr source IP address




Traffic trace Troubleshooting

sport source port

vd index of virtual domain, -1 matches all

Enable the output to in the console:diagnose debug flow show console enable

Start flow monitoring with a specific number of packets using the command:diagnose debug flow trace start <N>

Stop flow tracing at any time using:diagnose debug flow trace stop

Sample outputThis an example shows the flow trace for the device at the IP address 203.160.224.97.

diag debug enablediag debug flow filter addr 203.160.224.97diag debug flow show console enablediag debug flow show function-name enablediag debug flow trace start 100

Flow trace output example - HTTPConnect 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_fastline=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=2799msg="allocate a new session-00000e90"

Lookup for next-hop gateway address:id=20085 trace_id=209 func=vf_ip4_route_input line=1543msg="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=1219msg="find SNAT: IP-192.168.11.59, port-31925"direction“

Matched security policy. Check to see which policy this session matches:id=20085 trace_id=209 func=fw_forward_handler line=317msg="Allowed by Policy-3: SNAT"

Apply source NAT:id=20085 trace_id=209 func=__ip_session_run_tupleline=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=2700msg="vd-root received a packet(proto=6, 203.160.224.97:80->192.168.11.59:31925) from port6."






v0h

Found existing session ID. Identified as the reply direction:id=20085 trace_id=210 func=resolve_ip_tuple_fast line=2727msg="Find an existing session, id-00000e90, replydirection"

Apply destination NAT to inverse source NAT action:id=20085 trace_id=210 func=__ip_session_run_tupleline=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=1543msg="find a route: gw-192.168.3.221 via port5"

ACK received:id=20085 trace_id=211 func=resolve_ip_tuple_fast line=2700msg="vd-root received a packet(proto=6,192.168.3.221:1487->203.160.224.97:80) from port5."

Match existing session in the original direction:id=20085 trace_id=211 func=resolve_ip_tuple_fast line=2727msg="Find an existing session, id-00000e90, originaldirection"


Receive data from client:id=20085 trace_id=212 func=resolve_ip_tuple_fastline=2700 msg="vd-root received a packet(proto=6,192.168.3.221:1487->203.160.224.97:80) from port5."

Match existing session in the original direction:id=20085 trace_id=212 func=resolve_ip_tuple_fastline=2727 msg="Find an existing session, id-00000e90,original direction"


Receive data from server:id=20085 trace_id=213 func=resolve_ip_tuple_fastline=2700 msg="vd-root received a packet(proto=6,203.160.224.97:80->192.168.11.59:31925) from port6."

Match existing session in reply direction:id=20085 trace_id=213 func=resolve_ip_tuple_fastline=2727 msg="Find an existing session, id-00000e90,reply direction"

Apply destination NAT to inverse source NAT action:id=20085 trace_id=213 func=__ip_session_run_tupleline=1516 msg="DNAT 192.168.11.59:31925->192.168.3.221:1487"




Packet sniffer Troubleshooting

Packet snifferThe 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 interfaceAll Packet sniffing commands are in the format:

diagnose sniffer packet <interface> <'filter'> <verbose> <count>

... where...

Simple trace exampleIn this example, the packet sniffer sniffs three packets of all traffic with verbose level 1 on internal interface

diagnose sniffer packet internal “none” 1 3

The none variable means no filter applies, 1 means verbose level 1 and 3 means catch 3 packets and stop. The resulting output is192.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 exampleIn this example, the packet sniffer sniff 3 packets of all traffic with verbose 1evel 1 on internal interface

diagnose sniffer packet internal “none” 1 3

The none variable means no filter applies, 1 means verbose level 1 and 3 means catch 3 packets and stop. The resulting output is192.168.0.30.1156 -> 192.168.0.1.80: syn 2164883624192.168.0.1.80 -> 192.168.0.30.1156: syn 3792179542 ack 2164883625192.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.

<interface> can be an Interface name or “any” for all Interfaces. An interface can be physical, VLAN, IPsec interface, Link aggregated or redundant.

<verbose> the level of verbosity as described above.<count> the number of packets the sniffer reads before stopping.<'filter'> is a very powerful filter functionality which will be described below.





Troubleshooting Packet sniffer

v0h

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.

Verbose levels 2 and 3Verbose level 2 contains much more information; the IP header as with verbose level 1 and the payload of the IP packet itself.The output of verbose 2 is:diagnose sniffer packet internal “none” 2 1192.168.0.1.22 -> 192.168.0.30.1144: psh 2867817048 ack 19510619330x0000 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 exampleIn this example, use the filter option of the sniffer to see the traffic information between two PCs or a PC and a FortiGate unit. Using the following command:

diagnose sniffer packet internal 'src host 192.168.0.130 and dst host 192.168.0.1' 1

The resulting output is:192.168.0.130.3426 -> 192.168.0.1.80: syn 1325244087192.168.0.1.80 -> 192.168.0.130.3426: syn 3483111189 ack 1325244088�192.168.0.130.3426 -> 192.168.0.1.80: ack 3483111190192.168.0.130.3426 -> 192.168.0.1.80: psh 1325244088 ack 3483111190192.168.0.1.80 -> 192.168.0.130.3426: ack 1325244686192.168.0.130.1035 -> 192.168.0.1.53: udp 26192.168.0.130.1035 -> 192.168.0.1.53: udp 42�192.168.0.130.1035 -> 192.168.0.1.53: udp 42192.168.0.130 -> 192.168.0.1: icmp: echo request�192.168.0.130.3426 -> 192.168.0.1.80: psh 1325244686 ack 3483111190192.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:

Note: If you do not enter a <count> value, for example as above, 3, the sniffer will continue to run until you stop it.




http://kb.fortinet.com/kb/microsites/search.do?cmd=displayKC&docType=kc&externalId=11186&sliceId=1&docTypeID=DT_KCARTICLE_1_1&dialogID=2490940&stateId=0%200%202492934

Packet sniffer Troubleshooting

diagnose sniffer packet internal 'src host 192.168.0.130 and dst host 192.168.0.1 and tcp' 1�

The resulting output would be:192.168.0.130.3569 -> 192.168.0.1.23: syn 1802541497192.168.0.1.23 -> 192.168.0.130.3569: syn 4238146022 ack 1802541498192.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.





F0h

IndexAaccept, 66accept policy, 68address, 40

CIDR format, 40DHCP, 45FDQN, 43geography-based, 42groups, 44inverse mask, 43IP pool, 48IP range, 41IPv6, 50matching, IP pool, 49

administrative access, 35aidentity-based policy

timeout, 62allow access, 35antispam, about, 12antivirus, about, 9authentication

policies, 62

Bbinary, 43blended network attacks, about, 12

Ccentral NAT, 18custom services, 59

Ddata leak prevention, 11deny, 66deny policy, 68, 78destination NAT, 54destination network address translation (DNAT)

virtual IPs, 55, 58DHCP, 45

IP reservation, 47diagnose

flow trace, 81session list, 79sniffer packet, 84sys checkused, 81

DLP, 11DNAT, 54

virtual IPs, 55, 58DNS

TTL, 43

Eemail filter

techniques, 13email filter, about, 12example

blocking IP address, 70scheduled access, 71

FFDQN, 43firewall policies, see security policies, 65fixed ports, IP pools, 49flow inspection, 22, 23flow trace, 81forwarding, port, 54

Ggeography-based addressing, 42grayware, about, 11groups, addressing, 44

IICAP, 23identity-based policy

timeout schedule, 62inspection

flow, 22, 23proxy, 23security layers, 23stateful, 21

instant messaging, about, 12interfaces

AMC card, 34ANY, ANY interface option, 68physical, 33virtual domains, 36virtual LANs, 38wireless, 36zones, 39

intrusion protection, about, 14inverse mask, 43IP addresses

blocking, 70IP pool, 48

address matching, 49policies and fixed ports, 49

IP range, 41IP reservation, 47IPsec, 66IPv6, 50




Index

Llife of a packet, 21log messages, 78

NNAT, 18

symmetric, 58NAT mode

about, 16NAT, destination, 54network address translation (NAT), 56

PP2P, about, 12packet

flow, 24life of, 21sniffer, 84

PATvirtual IPs, 56

peer-to-peer, about, 12pharming, about, 12phishing, about, 11policies, 66

basic accept, 68basic deny, 68basic VPN, 69checking, 77expiry, 62identity-based policy timeout, 62log messages, 78order, 66timeout, 62verify traffic, 77

port address translationvirtual IPs, 56

port forwarding, 54, 56ports

closing to traffic, 53default system, 51originating traffic, 51receiving traffic, 52services, 59TCP 113, 53TCP 541, 54

profiles, UTM, 63proxy inspection, 23

Rreserving addresses, 47

Sschedule

timeout, 62

schedulesexample, 71expiry, 62group, 62identity-based policy timeout, 62one time, 60recurring, 60

schedule-timeout command, 62security layers, 23security policies

accept, 66basic accept, 68basic deny, 68basic VPN, 69checking, 77column settings, 77deny, 66IPsec, 66log messages, 78policy order, 66schedule example, 71ssl-vpn policies, 66verify traffic, 77

sensors, UTM, 63services, 59

custom, 59list, 59

session helper, 27session list, diagnose, 79session table, 79SNAT

virtual IPs, 55sniffer

packet, 79spyware, about, 11ssl-vpn, 66stateful inspection, 21streaming media, about, 12

Ttraffic count, 77traffic shaping

about, 15traffic trace, 79transparent mode

about, 18feature differences, 20switching to, 19

troubleshootingflow trace, 81log messages, 78packet sniffer, 84policies, 77session table, 79verify traffic, 77

UUTM

profiles, 63profiles and sensors, 63





Index

F0h

Vverify traffic, 77violation traffic, 78virtual domains, 36virtual IP

destination network address translation (DNAT), 55, 58NAT, 56PAT, 56port address translation, 56SNAT, 55source network address translation, 55

virtual LANs, 38VPN

policy, 69

Wweb filtering, about, 10wildcard mask, 43wireless, 36

Zzones, 39




Index





Index

F0h




Index





Documents

Fortigate Fundamentals 40 Mr3