text:
Узнать больше о подписке Scribd
Откройте для себя все, что может предложить Scribd, включая книги и аудиокниги от крупных издательств.
FortiGate II Student Guide for FortiGate 5.4.1DO NOT REPRINT© FORTINET FortiGate II Student Guide for FortiGate 5.4.1 Last Updated: 3 August 2016
® ® ® Fortinet , FortiGate , and FortiGuard are registered trademarks of Fortinet, Inc., and other Fortinet names herein may also be trademarks, registered or otherwise, of Fortinet. All other product or company names may be trademarks of their respective owners. Copyright © 2002 - 2016 Fortinet, Inc. All rights reserved. Contents and terms are subject to change by Fortinet without prior notice. No part of this publication may be reproduced in any form or by any means or used to make any derivative such as translation, transformation, or adaptation without permission from Fortinet, Inc., as stipulated by the United States Copyright Act of 1976.DO NOT REPRINT© FORTINET Table of Contents
2 NAT64 .................................................................................................................................155DO NOT REPRINT© FORTINET 3 Using IPsec to Tunnel IPv6 Over an IPv4 Network............................................................157
1 Routing................................................................................................................................162
2 Virtual Domains...................................................................................................................206
4 High Availability...................................................................................................................263
10 Diagnostics........................................................................................................................470
11 Hardware Acceleration......................................................................................................503
12 IPv6 ...................................................................................................................................545DO NOT REPRINT Virtual Lab Basics
© FORTINET Virtual Lab Basics In this class, you will use a virtual lab for hands-on exercises. This section explains how to connect to the lab and its virtual machines. It also shows the topology of the virtual machines in the lab.
Note: If your trainer asks you to use a different lab, such as devices physically located in your classroom, please ignore this section. This applies only to the virtual lab accessed through the Internet. If you do not know which lab to use, please ask your trainer.
© FORTINET Network Topology port2 10.200.1.241
FortiManager FortiAnalyzer LOCAL-WINDOWS port1 port1 10.0.1.10 10.0.1.241 10.0.1.210
10.0.1.254/24 port3 port3 10.200.1.210
port310.0.1.254/2 4 LOCAL-FORTIGATE port2 port3 port1 10.200.2.1/24 10.200.1.1/24
LINUX 10.200.2.254 10.200.1.254 eth2 eth1 eth0
eth4 eth3 10.200.4.254 10.200.3.254
REMOTE-FORTIGATE 10.200.4.1/24 10.200.3.1/24 port5 port4
REMOTE-WINDOWS 10.0.2.10 port6 10.0.2.254/24
Logging In 1. Run the System Checker. This will fully verify both: compatibility with the virtual lab environment's software, and that your computer can connect. It can also diagnose problems with your Java Virtual Machine, firewall, or web proxy.
© FORTINET Use the URL for your location. North America/South America: https://remotelabs.training.fortinet.com/training/syscheck/?location=NAM-West Europe/Middle East/Africa: https://remotelabs.training.fortinet.com/training/syscheck/?location=Europe Asia/Pacific: https://remotelabs.training.fortinet.com/training/syscheck/?location=APAC If a security confirmation dialog appears, click Run.
If your computer successfully connects to the virtual lab, the result messages for the browser and network checks will each display a check mark icon. Continue to the next step. If a browser test fails, this will affect your ability to access the virtual lab environment. If a network test fails, this will affect the usability of the virtual lab environment. For solutions, either click the Support Knowledge Base link or ask your trainer. 2. With the user name and password from your trainer, log into the URL for the virtual lab. Either: https://remotelabs.training.fortinet.com/
3. If prompted, select the time zone for your location, and then click Update. This ensures that your class schedule is accurate. 4. Click Enter Lab.
A list of virtual machines that exist in your virtual lab should appear.
© FORTINET From this page, you can access the console or desktop of any of your virtual devices by either: clicking on the device's square, or selecting System > Open.
A new window should open within a few seconds. (Depending on your account's preferences, the window may be a Java applet. If that is the case, you may need change browser settings to allow Java to run on this web site.)
Connections to Windows and Linux machines will use a remote desktop-like GUI. You should automatically log in. After that, the desktop is displayed. Connections to Fortinet's VM use the VM console port, which you can use to enter command line interface (CLI) commands.
© FORTINET Disconnections/Timeouts If your computer's connection with the virtual machine times out or if you are accidentally disconnected, to regain access, return to the initial window/tab that contains your session's list of VMs and open the VM again. If that does not succeed, see Troubleshooting Tips.
When connecting to a VM, your browser should then open a display in a new applet window.
Screen Resolution Some Fortinet devices' user interfaces require a minimum screen size. In the HTML 5 client, to configure screen resolution, open the System menu.
© FORTINET In the Java client, to configure the screen resolution, click the arrow at the top of the window.
International Keyboards If characters in your language don't display correctly, keyboard mappings may not be correct. To solve this in the HTML 5 client, open the Keyboard menu at the top of the window. Choose to display the on-screen keyboard.
Troubleshooting Tips Do not connect to the virtual lab environment through Wi-Fi, 3G, VPN tunnels or other low- bandwidth or high-latency connections. For best performance, use a stable broadband connection such as a LAN. If disconnected unexpectedly from any of the virtual machines (or from the virtual lab portal), please attempt to reconnect. If unable to reconnect, please notify the instructor. If you can't connect to a VM, on the VM's icon, click System > Power Cycle. This fixes most problems by forcing VM startup and connection initiation. If that does not solve the problem, try System > Revert to Initial State. Note: Reverting to the VM's initial snapshot will undo all of your work. Try other solutions first.
execute update-now
© FORTINET LAB 1–Routing In this lab, you will configure the router settings and try scenarios to learn how FortiGate makes routing decisions.
Objectives Route traffic based on the destination IP address, as well as other criteria. Balance traffic among multiple paths. Implement route failover. Diagnose a routing problem.
Time to Complete Estimated: 45 minutes
Prerequisites Before beginning this lab, you must restore a configuration file to the Local-FortiGate.
© FORTINET 1 Route Failover and Link Health Monitor If there are multiple paths to the same destination – for example, if you have redundant ISP connections – you can use link health monitors to provide failover. To monitor the viability of each path to an upstream device, FortiGate can send probe signals and listen for the replies. Often, you'll configure FortiGate to use ICMP type 8 (ping) probes, but it also supports UDP echo, TCP echo, HTTP, and TWAMP. If the device fails to respond after a number of retries, then FortiGate removes the static routes associated with the respective gateway from its routing table. As indicated in the diagram for the lab network topology, the Local-FortiGate has two interfaces connected to the Internet: port1 and port2. During this exercise, you will configure the port1 connection as the primary Internet link, and the port2 connection as the backup Internet link. The port2 connection should be used only if the port1 connection is down. To achieve this objective, you will configure two default routes with different administrative distances and create two link health monitors.
5. Click OK.
Field Value
Destination Subnet 0.0.0.0/0.0.0.0
Device port2
Gateway 10.200.2.254
Administrative Distance 20
© FORTINET To check the routing table 1. In the Local-FortiGate GUI, go to Monitor > Routing Monitor. You will see that the default route you created is not there. 2. In the Local-Windows, open PuTTY and connect to the LOCAL-FORTIGATE saved session (connect over SSH). 3. Log in as admin and execute the following command to reconfirm the list of active routes in the routing table:
© FORTINET To configure link health monitors 1. Still connected to the Local-FortiGate CLI though PuTTY, enter the following commands to create a link health monitor for port1:
edit port1-monitor
end 2. Add the link health monitor for port2:
edit port2-monitor
© FORTINET To confirm port1 is the primary route 1. Still connected to the Local-FortiGate CLI though PuTTY, enable the sniffer:
Tip: The filter 'tcp[13]&2==2' matches packets with the SYN flag on, so the output will show all SYN packets to port 80 (HTTP).
2. From the Local-Windows VM, open a few tabs in your browser and access multiple HTTP websites, such as:
http://www.eicar.org 3. Go back to the Local-FortiGate CLI in PuTTY and press Ctrl-C to stop the sniffer. Analyze the output:
You will notice that all outgoing packets are being routed through port1. The FortiGate is not using the port2 route. The primary Internet link is the port1 connection. This is one of objectives of this exercise.
end 2. Wait a few seconds. As 10.200.1.13 is an invalid IP, the link health monitor will not receive replies from that address and it would assume that the port1's Internet connection is down. 3. Go back to the Local-FortiGate GUI and go to Monitor > Routing Monitor to check the routing table:
FortiGate has removed the port1 route from the routing table and the port2 route is now the active one.
http://www.eicar.org 3. Go back to the Local-FortiGate CLI in PuTTY and press Ctrl-C to stop the sniffer. Check the output:
The Internet traffic is taking the port2 route now. You have achieved the second objective of this exercise.
© FORTINET next
end 2. In the Local-FortiGate GUI go to Monitor > Routing Monitor. 3. Click Refresh. 4. Check that the port1 route is back to the routing table:
© FORTINET 2 Equal Cost Multipath and Policy Routing In this exercise, you'll configure the Local-FortiGate to balance the Internet traffic between port1 and port2. This is called equal cost multipath (ECMP). After that, you'll configure a policy route to route HTTPS traffic through port1 only.
© FORTINET config sys settings
http://www.eicar.org 3. Press Ctrl-C to stop the sniffer and check its output:
You will notice that all the outgoing packets are still being routed through port1. The FortiGate is not using the port2 route yet.
© FORTINET To configure the same priority 1. Go back to the FortiGate GUI and go to Network > Static Routes. 2. Edit the static route for the interface port2. 3. Click Advanced Options and change the Priority to 0. 4. Click OK.
http://www.eicar.org 3. Press Ctrl-C to stop the sniffer and check its output. You will now see some packets being routed through port1, and some through port2:
© FORTINET Field Value
Protocol TCP
Field Value
http://www.eicar.org 3. Press Crtrl-C to stop the sniffer and check its output. The FortiGate is indeed still balancing the HTTP traffic between the two outgoing interfaces (port1 and port2).
© FORTINET 2. From the Local-FortiGate CLI though PuTTY, run this sniffer one more time:
https://support.fortinet.com/ 4. Press Ctrl-C to stop the sniffer and check its output. The HTTPS traffic is being routed through port1 only:
© FORTINET 3 WAN Link Load Balancing In the previous exercise, you configured load balancing using two static routes with the same distance and priority. In this exercise, you will use WAN link load balancing instead.
3. Click Upload and browse to Desktop > Resources > FortiGate-II > Routing. Select local- routing-2.conf. 4. Click OK. 5. Click OK.
© FORTINET 3. Under WAN LLB, click Create New. 4. Add port1 with the Gateway 10.200.1.254. 5. Click Create New one more time. 6. Add port2 with the Gateway 10.200.2.254. 7. Select Source-Destination IP as the Load Balancing Algorithm. 8. Click Apply. Your configuration should look like this:
Destination Subnet 0.0.0.0/0.0.0.0
Device wan-load-balance
Administrative Distance 10
© FORTINET 4. Click OK.
Field Value
Name Internet
Source LOCAL_SUBNET
Schedule always
Services ALL
© FORTINET http://cve.mitre.org
http://www.eicar.org 4. Press Ctrl-C to stop the sniffer and check its output:
© FORTINET LAB 2–Virtual Domains In this lab, you will create one VDOM and configure an inter-VDOM link.
Objectives Use VDOMs to split a FortiGate into multiple virtual units. Create an administrative account with the access limited to one VDOM. Route traffic between VDOMs by using inter-VDOM links.
Time to Complete Estimated: 25 minutes
Topology The goal of the lab is to create the topology below. You will use VDOMs to logically split the Local- FortiGate into two virtual firewalls: the root VDOM and the customer VDOM. Both are in NAT mode. So, all Internet traffic coming from Local-Windows must transverse the customer VDOM first, then the root VDOM.
vlink0 port1 10.10.100.1/30 10.200.1.1/24
vlink1 LINUX 10.10.100.2/30 Local-FortiGate 10.200.1.254 root VDOM eth1
port3 Local-FortiGate 10.0.1.254/24 customer VDOM
Local-Windows Internet 10.0.1.10
Prerequisites Before beginning this lab, you must restore a configuration file to FortiGate.
© FORTINET To restore the FortiGate configuration file 1. From the Local-Windows VM, open a browser and log in as admin to the Local-FortiGate GUI at 10.0.1.254. 2. Go to Dashboard, and from the System Information widget click Restore.
© FORTINET 1 VDOMs and VDOM Objects During this exercise you will first add a new VDOM. Then you will create an inter-VDOM link between the VDOM you added and the root VDOM. You will also create an administrator account that will have access to only one VDOM.
Note: The configuration file for this exercise already has VDOMs enabled.
Creating a VDOM A FortiGate with VDOMs enabled always includes a root VDOM. Administrators can create additional VDOMs to split the physical FortiGate into multiple virtual firewalls. In the next steps, you will add a second VDOM.
To create a VDOM 1. From the Local-Windows VM, open a browser and log in as admin to the Local-FortiGate GUI at 10.0.1.254. You will notice that the FortiGate menu has changed. This is because VDOMs are enabled. There is now a drop-down list at the top of the menu. From there you can access either the global settings or the VDOM-specific settings for the root VDOM:
Field Value
5. Click OK. Notice that the drop-down list on the top of the menu shows a third option - the VDOM-specific settings for customer:
Password fortinet
4. Under Type, select Local User and configure the following settings:
5. Remove root from the Virtual Domains list, so that the new administrator can only access customer.
6. Click OK.
© FORTINET VDOM. So, move the port3 interface, which connects to the internal network, to the customer VDOM.
4. Click OK. Leave the port1 and port2 interfaces in the root VDOM.
Field Value
Interface port3
3. Click OK.
2. Log in again to the Local-FortiGate GUI, but this time use the administrator name customer- admin with password fortinet.
© FORTINET 3. Navigate through the GUI and examine what the VDOM administrator is allowed to control. Since the customer-admin administrator can access the customer VDOM only, the GUI does not display the Global configuration settings or the VDOM-specific settings for the root VDOM. 4. Log out from the Local-FortiGate GUI one more time and log in back as the admin user (blank password), which has access to the global settings and all VDOMs.
config vdom
edit customer
Note: Be careful when typing VDOM names with the edit command. VDOM names are case-sensitive, and the edit command can both modify and create. For example, if you enter edit Root, you will not enter the pre-existing root VDOM. Instead, you will create and enter a new VDOM named Root.
4. Now that you've specified the VDOM, try looking at the routing table again:
edit root 6. Now use the command for listing the routing table:
© FORTINET 2 Inter-VDOM Link In this exercise you will route traffic between both VDOMs using an inter-VDOM link.
Field Value
7. Click OK. After creating the inter-VDOM link, notice the two inter-VDOM sub-interfaces added within the root and customer VDOMs. These interfaces are named vlink0 and vlink1. They can be used to route traffic between both VDOMs.
9. Go to Network > Static Routes to specify a default route for the customer. 10. Click Create New. 11. Add this route:
Field Value
Destination Subnet 0.0.0.0/0
© FORTINET Device vlink1
Gateway 10.10.100.1
Field Value
Destination Subnet 10.0.1.0/24
Device vlink0
Gateway 10.10.100.2
Field Value
Name Internet
Source all
Schedule always
Service ALL
Action ACCEPT
NAT Disable
5. Click OK. 6. Go to the VDOM-specific settings for the root VDOM and go to Policy & Objects > IPv4 Policy. 7. Click Create New. 8. Configure the following policy:
Field Value
Name Internet
Source all
© FORTINET Destination Address all
Schedule always
Service ALL
Action ACCEPT
NAT Enable
9. Click OK.
http://www.eicar.org Traffic should be flowing through both VDOMs now. 2. Open a command prompt window in Local-Windows and execute a traceroute command to an Internet public IP address:
tracert –d 22.214.171.124 3. Check the output. The first hop IP address is 10.0.1.254, which is port3 in the customer VDOM. The second hop IP address is 10.10.100.1, which is the inter-VDOM link in the root VDOM. The third hop IP address is 10.200.1.254, which is the Linux server.
© FORTINET LAB 3–Transparent Mode In this lab, you will create a transparent mode VDOM. You will also configure an inter-VDOM link, this time between a transparent mode VDOM and a NAT mode VDOM.
Objectives Configure a transparent mode VDOM. Configure an inter-VDOM link.
Time to Complete Estimated: 20 minutes
Lab Topology The goal of the lab is to create the topology below. You will use VDOMs to logically split the Local- FortiGate into two virtual firewalls: the root VDOM and the inspect VDOM. The root VDOM is in NAT mode. The inspect VDOM is in transparent mode and will be inspecting the traffic for virus protection. So, all Internet traffic coming from Local-Windows must transverse first the root VDOM, then the inspect VDOM.
vlink1 port1 10.200.1.254/24
vlink0 LINUX Local-FortiGate 10.200.1.1/24 inspect VDOM Management IP 10.200.1.200/24 port3 Local-FortiGate 10.0.1.254/24 root VDOM
Local-Windows Internet 10.0.1.10/24
© FORTINET Before beginning this lab, you must restore a configuration file to the Local-FortiGate.
© FORTINET 1 Transparent Mode VDOM The configuration file for this exercise already has the setting VDOMs enabled. As such, in this exercise, you just need to create a transparent mode VDOM called inspect and then move the interface to the inspect VDOM.
Field Value
5. Click OK. 6. In Local-Windows, open PuTTY and connect to the LOCAL-FORTIGATE saved session (connect over SSH). 7. Log in as admin and execute the following command to change the inspect VDOM operation mode from the default NAT mode to transparent mode:
edit inspect
© FORTINET set opmode transparent
© FORTINET 2 Inter-VDOM Link In this exercise, you will create an inter-VDOM link. After that, you will create the firewall policies that allow Internet access across both VDOMs. Finally, you will configure and test antivirus inspection in the inspect VDOM.
Field Value
7. Click OK. You are returned to the Interfaces page. 8. Review the inter-VDOM link interfaces you just created:
Note that vlink0 and vlink1 are logical interfaces that can be used to route traffic between the root and inspect VDOMs. An IP address is only configurable on the NAT mode VDOM interface.
Field Value
Name Inspected_Internet
© FORTINET 6. Click OK. 7. Now select the VDOM-specific settings for the root VDOM. 8. Go to Policy & Objects > IPv4 Policy and click Create New. 9. Configure the following settings:
Field Value
Name Internet
Source all
Schedule always
Service ALL
Action ACCEPT
Field Value
Destination Subnet 0.0.0.0/0
Device vlink0
Gateway 10.200.1.254
4. Click OK.
© FORTINET Testing the Transparent Mode VDOM You will use the traceroute command to confirm that Internet traffic is crossing the inter-VDOM link. Then you will try to download a virus to confirm that antivirus inspection in the inspect VDOM is working.
tracert –d 10.200.3.1
http://www.eicar.org 4. Click Download Anti Malware Testfile and then click Download:
6. Confirm that the AV profile in the inspect VDOM blocks this action:
© FORTINET LAB 4 –High Availability In this lab, you will set up a high availability (HA) cluster of FortiGate devices. You will explore Active- Active HA mode and observe FortiGate HA behavior. You will also perform HA failover and use diagnostic commands to observe election of new primary in the cluster. You will also configure management port(s) on each FortiGate to reach each FortiGate individually for management purposes.
Objectives Set up an HA cluster using FortiGate devices Observe HA synchronization and interpret diagnostic output Performing HA failover Manage individual cluster members by configuring reserved management interface
Lab HA Topology After you upload the required configurations to each FortiGate, the logical topology will change to this.
© FORTINET REMOTE- FORTIGATE port3 port1
LINUX port2 10.200.1.254 eth1
port3 port1 10.0.1.254/24 10.200.1.1/24 LOCAL- LOCAL- FORTIGATE WINDOWS 10.0.1.10 Internet
Prerequisites Before beginning this lab, you must restore a configuration file to each FortiGate. Note: Make sure to restore the correct configuration in each FortiGate as per the steps below. Failure to restore proper configuration in each FortiGate will prevent you from doing the lab exercise.
© FORTINET 1 Configuring High Availability (HA) FortiGate HA uses FortiGate Clustering Protocol (FGCP) which uses heartbeat link for HA related communications to discover other FortiGates in same HA group, elect primary, synchronize configuration, and detect failed device in HA cluster. In this exercise, you will configure HA settings on both the FortiGate devices. You will observe the HA synchronize status and verify the configuration is in sync on both FortiGate devices using the diagnose commands.
Field Value
Mode Active-Active
Password Fortinet
Heartbeat Interface Enable Check the box for port2 Uncheck the box for port4
3. Click Apply.
© FORTINET 2. Login as admin.
config system ha
© FORTINET Wait 4 to 5 minutes for the FortiGate devices to synchronize. Once the FortiGate devices are synchronized, it will log out all admin users. 2. In the Remote-FortiGate console, again log in as admin. 3. To check the HA synchronize status, run the following command on the Remote-FortiGate console.
5. Log in as admin. 6. To check the HA synchronize status, run the following command on the Local-FortiGate console.
4. From the Local-Windows, open a browser and log in as admin to the Local-FortiGate GUI at 10.0.1.254.
© FORTINET 5. Go to the Dashboard >System Information widget, it will show the cluster members and their roles.
Viewing HA Statistics Now you will be viewing HA statistics from the GUI of primary FortiGate.
To view HA Statistics 1. In Local-Windows, open few web browser tabs and connect to a few websites. For example: https://www.fortinet.com www.yahoo.com www.bbc.com 2. Go back to the GUI of the cluster's primary FortiGate at 10.0.1.254. 3. Go to System > HA. 4. Click View HA Statistics. This will show you the status, uptime and session information of the cluster members.
Note: The primary FortiGate will have more active sessions than the secondary FortiGate. This is because all management traffic is with the primary; all non-TCP traffic is handled by the primary also. By default, only TCP sessions which are not handled by UTM proxy for inspection are load balanced between the primary and secondary FortiGate.
© FORTINET 2 High Availability Failover You have setup HA cluster. Now, you will be triggering HA failover and observe the renegotiation to elect new primary and redistribution of sessions.
ping 184.108.40.206 -t 4. Go to the Local-FortiGate console. 5. To trigger a failover, reboot the Local-FortiGate by entering the following command:
execute reboot 6. Press y to continue to reboot the FortiGate.
© FORTINET You should observe the Local-FortiGate rejoins the cluster as a secondary. It has lost its role of primary.
Note: By resetting the HA uptime, you are forcing the cluster to use the next value to determine which FortiGate has priority for becoming the primary. You will observe that the Local-FortiGate now has the primary role in the cluster.
3. To see the status of all cluster members, run the following command on any FortiGate console in the cluster:
© FORTINET 3. Go to the Remote-FortiGate console. 4. Reboot the Remote-FortiGate.
execute reboot 5. Press y to continue to reboot the FortiGate. 6. On the Local-FortiGate console, observe the output while the secondary reboots and starts communicating with the cluster.
It will show that the current primary FortiGate is sending heartbeat packets and trying to synchronize its configuration with the secondary FortiGate's. 7. To stop the debug output on the Local-FortiGate, press the Up-Arrow key twice, selecting the command before last (in this case diagnose debug application hasync 0), then press the Enter key.
© FORTINET 3 Configuring HA Management Interface In this exercise, you will configure a spare interface of the cluster to be a non-synchronizing management interface. This will allow both FortiGates to be reachable for SNMP and management purposes only. If management interface is not configured, you will have access to the GUI for only the primary FortiGate in the cluster. However, you can connect to the secondary FortiGate through the primary FortiGate's CLI.
4. Log in as admin. 5. Run the following command to get the status of the secondary FortiGate.
© FORTINET interface. This allows you to configure a different IP address for this interface for each FortiGate in the HA cluster.
4. Select Reserve Management Port for Cluster Member and choose port7. 5. Click Apply. Note: Port7 connects to the same LAN segment as port3.
To configure and verify access using the management interface for the primary FortiGate 1. Go to the Local-FortiGate console. 2. Log in as admin. 3. Configure the port7 as following:
edit port7
set ip 10.0.1.253/24
© FORTINET Note: Even though this address overlaps with port3, and would not be normally allowed (FortiGate does not allow overlapping subnets), it is allowed here because the interface now has a special purpose, and is excluded from the routing table.
4. From the Local-Windows, open a web browser and log in as admin to the Local-FortiGate GUI at 10.0.1.253. This will verify connectivity to port7.
To configure and verify access using the management interface for the secondary FortiGate 1. Go to the Remote-FortiGate console. 2. Log in as admin. 3. Verify that the non-synchronizing interface settings have been synced to the secondary.
show system ha Look for ha-mgmt-status and ha-mgmt-interface. These should be set. 4. In the Remote-FortiGate console, verify that port7 has no configuration by running the following command:
edit port7
set ip 10.0.1.252/24
end 6. From the Local-Windows, open a web browser and log in as admin to the Remote-FortiGate GUI at 10.0.1.252. This will verify connectivity to port7. Each device in the cluster now has its own management IP address for monitoring purposes.
© FORTINET To disconnect FortiGate from the cluster 1. From the Local-Windows, open a browser and log in as admin to the Local-FortiGate GUI at 10.0.1.254. 2. Go to System > HA. 3. For the Remote-FortiGate, click the Disconnect from cluster icon. This will remove the FortiGate from the HA cluster.
Note: Failure to do these steps will prevent you from doing the next exercise.
3. From your local PC (Local-Windows), click Upload and browse to Desktop > Resources > FortiGate-I > Introduction and select remote-initial.conf. 4. Click OK. 5. Click OK.
Note: Failure to do these steps will prevent you from doing the next exercises.
© FORTINET LAB 5–Advanced IPsec VPN In this lab, you will configure redundant VPN tunnels with failover capability between two FortiGates. You will also create a dial-up VPN between a FortiGate and FortiClient.
Objectives Deploy a dialup VPN between two FortiGates. Deploy a dialup VPN for FortiClient. Configure redundant VPNs between two FortiGates.
Time to Complete Estimated: 60 minutes
Prerequisites Before beginning this lab, you must restore configuration files to the Local-FortiGate and Remote- FortiGate.
© FORTINET 4. Browse to Desktop > Resources > FortiGate-II > Advanced-IPsec and select remote- advanced-ipsec.conf. 5. Click OK. 6. Click OK to reboot.
© FORTINET 1 Configure an IPsec VPN Between Two FortiGates In this exercise, you will configure one VPN between the Local-FortiGate and the Remote-FortiGate for redundancy.
IP Address 10.200.3.1
Interface port1
© FORTINET Local-FortiGate: Creating a Static Route for Route- based VPN The VPN was created as route-based. This means that it requires at least one route (static or dynamic) to forward the traffic through the tunnel. You will create a static route for that purpose.
Field Value
Destination Subnet 10.0.2.0/24
Device Remote_1
© FORTINET Field Value
Name Remote_out
Source LOCAL_SUBNET
Name Remote_in
© FORTINET Outgoing Interface port3
Source REMOTE_SUBNET
Service ALL
Action ACCEPT
Field Value
IP Address 10.200.1.1
Interface port4
© FORTINET 9. Leave the other settings with their default values. 10. Click OK.
Field Value
Destination Subnet 10.0.1.0/24
Device Local_1
© FORTINET Field Value
Name Local_out
Source REMOTE_SUBNET
Name Local_in
© FORTINET Outgoing Interface port6
Schedule Always
ping 10.0.2.10
Note: FortiGate may not have previously established the VPN. If so, the first few pings will fail while FortiGate negotiates and establishes the VPN.
© FORTINET 2 Configuring a Backup IPsec VPN In this exercise, you will create the second route-based VPN for redundancy. This time, configure the VPN from the Local-FortiGate port2 to the Remote-FortiGate port5.
Field Value
Destination Subnet 10.0.2.0/24
Device Remote_2
Administrative Distance 20
6. Click OK. 7. Go to Network > Interfaces. 8. Edit the zone VPN. 9. Add the interface Remote_2 to it. 10. Click OK.
© FORTINET 2. Repeat the configuration steps in Remote-FortiGate: Creating Phases 1 and 2 to create phases 1 and 2.Use Local_2 for the VPN name. 3. Go to Network > Static Routes. 4. Click Create New. 5. Add this static route:
Field Value
Destination 10.0.1.0/24
Device Local_2
6. Click OK. 7. Go to Network > Interfaces. 8. Edit the zone VPN. 9. Add the interface Local_2 to it. 10. Click OK.
ping –t 10.0.2.10 4. Check the sniffer output. It will show that the Local-FortiGate is routing the packets through the VPN Remote_1:
© FORTINET Now, let's simulate a failure in the VPN Remote_1 and observe how the FortiGate starts using the secondary VPN Remote_2. 5. From the Local-FortiGate GUI, go to Network > Interfaces. 6. Edit port1. 7. Set the Interface State to Disabled to bring down the tunnel Remote_1. 8. Click OK. 9. Wait a few minutes until FortiGate detects the failure in the VPN Remote_1 and reroutes the traffic through Remote_2. 10. Check the sniffer output again. You will observe that the VPN Remote_2 is being used now:
Note: Omitting these last steps will prevent you from doing the next exercise.
© FORTINET 3 IPsec VPN with FortiClient You will now create a dial-up VPN between a FortiGate and FortiClient.
Prerequisites Before beginning, you must restore the initial configuration files to the Local-FortiGate and Remote- FortiGate.
6. Click Next. 7. Configure these settings:
© FORTINET Field Value
8. Click Next. 9. Configure these other settings in the next wizard step:
Field Value
Subnet 255.255.255.0
Note: Although you have created a route-based IPsec tunnel, you do not need to add a static route because it is a dial-up VPN. FortiGate will dynamically add or remove appropriate routes to each dial-up peer, each time their VPNs are established or disconnected.
© FORTINET 2. Click the Configure VPN link. 3. Select IPsec VPN:
Field Value
Username student
5. Click Apply. 6. Click Close.
ipconfig /all 2. Analyze the output. You should observe an interface with an IP address in the 172.20.1.1 - 172.20.1.5 range. 3. Enter this other command to display the routing table information:
route print 4. Locate the 10.0.1.0/24 network entry in the output.
© FORTINET LAB 6–Intrusion Prevention System (IPS) In this lab, you will set up IPS profiles and denial of service (DoS) policies. You will also use a vulnerability scanner and packet crafting software to attempt to flood the FortiGates.
Objectives Protect your network against known attacks using IPS signatures. Mitigate and block network anomalies and DoS attacks. Write custom IPS signatures.
Time to Complete Estimated: 40 minutes
© FORTINET 3. Select to restore from Local PC and click Upload. 4. Browse to Desktop > FortiGate-I > Introduction and select local-initial.conf. 5. Click OK. 6. Click OK to reboot.
© FORTINET 1 Blocking Known Exploits During this exercise you will configure IPS inspection to block known attacks. You will test your configuration by generating an attack on the Linux server from the Local-Windows VM.
To configure IPS 1. From the Local-Windows VM, open a browser and log in as admin to the Local-FortiGate GUI at 10.0.1.254. 2. Go to Security Profiles > Intrusion Protection. 3. To create a new sensor, click the plus sign (+) in the upper-right corner:
4. Use the name LINUX_SERVER for the new sensor and click Add Filter:
© FORTINET 5. Click Add Filter. 6. Select Target: server. 7. Click Add Filter one more time. 8. Select OS: Linux. 9. Click Use Filters:
All the signatures matching the filter are added to the IPS sensor. 10. Right-click the entry in the IPS Filters table that was just added and select Packet Logging > Enable:
© FORTINET Applying an IPS Sensor to a Firewall Policy You will apply the new IPS sensor to the firewall policy that allows Internet access.
Note: The IPS logs section will not display if there are no IPS logs. FortiGate will show it after creating logs. After the attacks, if this menu item does not display, log out from the FortiGate GUI and log in again to refresh it.
3. Note that for some of the attacks discovered by the IPS, the Action column shows the value Detected. This indicates that a signature was matched, but that FortiGate was configured to allow traffic to pass. In the spaces below, write the signature names for two of those detected attacks that were not blocked. The signature name appears in the Attack Name column of the log.
Signature 1: ____________________________________
Signature 2: ____________________________________
© FORTINET Changing a Signature Action You took note of two attacks that were detected, but not blocked, because the default action for their signatures is Monitor. You will change the action for those two signatures to Block and test again.
© FORTINET 2 Mitigating a DoS Attack In this exercise you will configure the Local-FortiGate for DoS protection. After that, you will simulate a DoS attack by generating traffic from the Linux server.
7. Click OK.
© FORTINET Testing the DoS Policy You will generate a high number of ICMP packets per second from the Linux server to the Local- FortiGate. This will trigger the DoS policy.
ping -f 10.200.1.1 The command option -f causes the ping utility to run continuously and not wait for replies between ICMP echo requests. FortiGate will block pings when the amount of packets per second exceeds the configured threshold. Leave the Linux SSH connection open with the ping running. 4. Go back to the Local-FortiGate GUI and press Ctrl-F5 to refresh the browser (or log out and log in). 5. Go to Log & Report > Anomaly.
Note: The Anomaly logs section will not display if there are no anomaly logs. FortiGate will show it after creating logs. After the attacks, if this menu item does not display, log out from the FortiGate GUI and log in again to refresh it.
6. Examine the logs. Note that the ICMP flood has been blocked. This is indicated by the Action field entry clear_session:
7. Go back to the SSH connection to the Linux server and press Crtl-C to stop the ping.
© FORTINET 3 Creating Custom Signatures During this exercise you will create a custom signature to block RETR (GET) commands on FTP traffic.
edit "FTP_GET"
end 3. From the Local-Windows VM, open a browser and log in as admin to the Local-FortiGate GUI at 10.0.1.254. 4. Go to Security Profiles > Intrusion Protection. 5. Edit the LINUX_SERVER sensor created earlier. 6. Click Add Signature. 7. Search for the signature FTP_GET. Select it and click Use Selected Signatures. 8. Right-click the custom signature and change the action to Reset. 9. Click Apply.
© FORTINET To test the custom signature 1. Go back to the Local-FortiGate CLI and execute the following command to sniffer all FTP traffic:
Note: When FortiGate resets the TCP connection, FileZilla may show a notification pop- up a few times.
6. Go back to the Local-FortiGate CLI and examine the sniffer output to verify that the reset action was applied to the session. You should see a TCP reset sent out to the client on port3 and to the server on port1:
7. Alternately, go back to the Local-FortiGate GUI and go to Log & Report > Intrusion Protection. Locate the attack log entry to verify that the FortiGate reset the connection:
© FORTINET LAB 7–Fortinet Single Sign-On (FSSO) In this lab, you will configure FSSO. FSSO enables FortiGate to identify users by collecting user login activity on a Windows server set with active directory. This includes installing and configuring the domain controller agent and FSSO collector agent in order to monitor and consolidate the user logon events and send them to FortiGate. You will also configure the SSO option on FortiGate to enable communication with the collector agent, specifically to poll event log information.
Objectives Install and configure the Fortinet domain controller agent. Install and configure the FSSO collector agent. Configure SSO on FortiGate. Test the automatic user identification by generating user logon events. Monitor the SSO status and operation.
© FORTINET 1 FSSO Agents In order to configure FortiGate to identify users by polling their login events from the FSSO agents, you must to install and configure both agents: the collector and the domain controller.
Note: The FSSO agents are available from the Fortinet Support website (http://support.fortinet.com). The available agents are: DC agent Collector agent for Microsoft servers: FSSO_Setup Collector agent for Novell directories: FSSO_Setup_edirectory Controller agent for Citrix servers: TSAgent_Setup
3. Click Next. 4. Accept the license agreement and click Next.
© FORTINET User Name: .\Administrator Password: password The password is the administrative user password of the Local-Windows VM.
© FORTINET 5. Under the Working Mode section, ensure the following settings are selected in order to poll the login sessions from the domain controller and then click Next: Polling Mode Check Windows Security Event Logs
Note: You will use this password later when configuring FortiGate. This password allows the FortiGate to communicate and poll the logon events from the FSSO collector agent.
4. Click Show Monitored DCs in the right menu to specify the monitored domain controller. You will see a logon event for the IP address: 10.0.1.10.
7. Click Close. 8. Click Set Group Filters in the right menu to specify the monitored groups. 9. Click Add. 10. Enable the Default filter and click Advanced.
Your Monitored group is named: TRAININGAD/AD-users. FortiGate will now poll it. 13. Click OK. 14. Click OK.
© FORTINET 2 Single Sign-On (SSO) on FortiGate Now that the agents are set up, you must configure your FortiGate to communicate and poll information from the FSSO collector agent. You must then assign the polled user to a firewall user group and add the user group as a source on a firewall policy. Finally, you can verify the user logon event collected by FortiGate. This event is generated once a user logs onto the Windows active directory domain. Therefore, no firewall authentication is required.
Field Value
Name TrainingDomain
Password Fortinet Note: This is the password you specified while configuring the Fortinet Single Sign On Agent. This password allows the FortiGate to communicate and poll the logon events from the FSSO collector agent.
© FORTINET Stop and Think Under which conditions is the User/Group field is not automatically displayed after clicking Apply and Refresh?
Discussion Apply and Refresh allows FortiGate to communicate and poll information from the FSSO collector agent. If FortiGate does not properly refresh with the polled information, it could be a password mismatch. The agent IP password must be the same as the password you set up in the Authentication section during the FSSO collector agent configuration.
5. Click OK. A green checkmark in the Status column confirms that the communication with the FSSO collector agent is up.
Field Value
Name Training
Members TRAININGAD/AD-USERS
© FORTINET Note: The polled FSSO user is automatically listed in the drop-down list due to the selected group type: FSSO.
Testing FSSO Once a user logs into the Windows AD domain, the user is automatically IP-based identified and logged on. Hence, the FortiGate allows the user to access to network resources, as policy decisions are made. For the purposes of this lab, you will generate a user logon event and monitor FortiGate to observe how it identifies the user.
To monitor the communication between the FSSO collector agent and FortiGate 1. From the Local-Windows, open PuTTY and connect to the LOCAL-FORTIGATE saved session (connect over SSH). 2. Log in as admin and type the following command to monitor the communication between the FSSO collector agent and the FortiGate:
© FORTINET diagnose debug application authd 8256 You will return to this output after generating a logon event. 3. Continue to the next procedure.
4. Click Connect. 5. Select Use another account, and log in with the following credentials:
Field Value
Username aduser1 This user has been pre-created for you in Active Directory.
Password Training!
6. Click Yes. 7. Click OK. Ignore the error message indicating that the user is not authorized for remote login. 8. Return to the PuTTY CLI connection and observe the output of the diagnose command:
© FORTINET _process_logon[TrainingDomain]: ADUSER1(10.0.1.10) logged on with session id(0), port_range_sz=0
Note: You have generated a logon event using the Windows Remote Desktop Connection application and it has been captured by your DC agent, forwarded to your collector agent, and polled by FortiGate.
----FSSO logons----
Note: You may see two IP addresses because the Local-Windows VM has two NICs in your lab environment.
Note: The Event Log menu will not display the User Events option until FortiGate registers the user event logs. FortiGate will show this option after creating logs. So, if this menu item does not display after the user event log, log out from the FortiGate GUI and log in again to refresh it.
© FORTINET LAB 8–Certificate Operations In this lab, you will configure certificate authentication on FortiGate. This includes importing a CA certificate into FortiGate, configuring a PKI peer user, and importing the PKI peer user certificate into the personal certificate store on the user's computer (Local-Windows). You will then authenticate as the PKI peer user over SSL VPN. You will also configure SSL deep inspection using a self-signed SSL certificate on FortiGate, so you can inspect encrypted traffic.
Objectives Configure certificate authentication on FortiGate so that a PKI user can authenticate to the network with their certificate over SSL VPN. Configure and enable SSL deep inspection on FortiGate so you can inspect encrypted traffic.
© FORTINET 1 Certificate Authentication In order to configure FortiGate for certificate authentication, you must import the root CA certificate on FortiGate. The root CA generates and signs user certificates and is necessary to verify the validity of any user certificate being used to authenticate. You must then create a PKI peer user on FortiGate and add the PKI peer user to a firewall user group. Finally, you must install the PKI peer user's digital certificate in the personal certificate store of their computer (Local-Windows). Once configured, you can test certificate authentication by logging into SSL VPN.
Note: All certificates have been pre-generated for you by FortiAuthenticator—a user authentication and identity management appliance. Keep in mind that you can generate certificates using many different applications or purchase certificates from various certificate providers. As such, this lab focuses on importing certificates rather than certificate generation.
To import a CA certificate 1. From the Local-Windows VM, open a browser and log in as admin to the Local-FortiGate GUI at 10.0.1.254. 2. Go to System > Certificates. 3. Click Import and select CA Certificate from the drop-down menu.
4. From the Import CA Certificate dialog box, select Local PC and browse to Desktop > Resources > FortiGate-II > Certificates and select FortiAuthCA.crt.
5. Click OK. The CA certificate CA_Cert_1 (CN = FortiAuthCA) is added to the Certificates page under External CA Certificates.
Note: CA_Cert_1 is the name of the CA certificate you imported in the previous procedure. The common name of the certificate (cn) is FortiAuthCA.
3. Close PuTTY. 4. To confirm the PKI peer user you just created was added successfully in the FortiGate GUI, refresh your browser and go to User & Device > PKI. Remember, the PKI page appears only once you add your first PKI peer user through the CLI.
Note: You now have the option to create subsequent PKI peer users directly through the FortiGate GUI, as the PKI page is now visible. No additional users are required for this lab, however.
© FORTINET Generally, groups are used to more effectively manage individuals that have some kind of shared relationship.
Note: The PKI-users group was pre-configured for you. However, it needs to be modified to add the PKI peer user you created (aduser2).
Note: Configuring SSL-VPN is out of scope for this lab. As such, the SSL-VPN settings have been pre-configured for you. However, you still need to configure the SSL-VPN firewall policy and add the PKI-users group to it.
Field Value
© FORTINET Source LOCAL_SUBNET PKI-users (click the User tab to locate this group)
Schedule always
Service ALL
Action ACCEPT
3. Click OK. 4. Click OK. The SSL-VPN Settings page appears and provides the URL for the SSL Web mode access. You will use this URL later in testing.
Note: If using a browser other than Firefox, the user certificate would be stored in the personal certificate store of the user's computer.
Once the user certificate is stored in the Firefox browser, Firefox automatically accesses this location in order to locate the certificate, when prompted.
3. Click Advanced from the left menu, and then click the Certificates tab in the main window. 4. Click View Certificates.
© FORTINET To test certificate authentication 1. Open a new browser tab and go to the VPN Web mode access at https://10.0.1.254:10443. The site requests you identify yourself with a certificate. It automatically points to the aduser2 certificate stored in the personal certificate store on the Local-Windows VM.
2. Click OK. 3. If you receive an error that indicates your connection is not secure, click Advanced and then select Add Exception. The login screen appears with the username already prefilled. 4. Enter Training! as the password and click Login. You successfully logged in with a certificate.
5. From the top-right corner, log out of the SSL VPN portal. 6. Close the SSL VPN browser tab.
© FORTINET 2 SSL Full Inspection In this exercise, you will configure and enable SSL inspection on FortiGate and then test it. With SSL deep inspection, the firewall receives traffic on behalf of the client and opens up the encrypted traffic. Once it is finished, it re-encrypts the traffic and sends it on to its intended recipient. It is very similar to a man-in-the-middle (MITM) attack. By enabling this feature, FortiGate will filter on traffic that is using the SSL encrypted protocol.
Prerequisites Before beginning this lab, you must remove the Fortinet_CA_SSL certificate from the Firefox browser.
Note: The FortiGate II lab environment begins with the Fortinet_CA_SSL certificate installed in the Firefox browser by default. However, because this lab includes configuring FortiGate for SSL inspection and then testing SSL inspection--both with and without the SSL certificate installed--the SSL certificate must first be removed. .
3. Click Advanced from the left menu and then click the Certificates tab in the main window. 4. Click View Certificates.
5. Click the Authorities tab and from the certificate authorities in the list, scroll to the Fortinet section.
6. Select the certificate in the Fortinet section and click Delete or Distrust. 7. Click OK to verify. The FortiGate SSL certificate is removed from the Firefox browser. 8. Click OK to close the Certificate Manager dialog box. 9. Close the Options tab in the Firefox browser.
© FORTINET and deep-inspection. Since this exercise involves configuring FortiGate for SSL full inspection, you will configure the default deep-inspection security profile.
Field Value
CA Certificate Fortinet_CA_SSL
5. From the Exempt from SSL Inspection section, disable Reputable Websites. 6. From the Common Options section, enable the following: Allow Invalid SSL: Certificates Log Invalid Certificates 7. Click Apply.
© FORTINET enable SSL/SSH Inspection and select deep-inspection. 3. Under Logging Options, enable Log Allowed Traffic and select All Sessions. 4. Click OK.
3. In the Firefox browser, click the menu icon ( ) in the top-right corner and select Options. 4. Click Advanced from the left menu and then click the Certificates tab in the main window. 5. Click View Certificates.
The Fortinet_CA_SSL certificate is added to the list under the Authorities tab. 10. Click OK to exit the Certificate Manager. 11. Close the Options tab in your browser.
© FORTINET LAB 9–Data Leak Prevention In this lab, you will use data leak prevention (DLP) rules and sensors to block sensitive data from leaving the private network.
Objectives Configure DLP to block ZIP files. Read and interpret DLP log entries. Set up DLP banning and quarantining. Configure DLP fingerprinting.
Time to Complete Estimated: 30 minutes
Prerequisites Before beginning this lab, you must restore a configuration file to the FortiGate.
© FORTINET 4. Browse to Desktop > Resources > FortiGate-II > DLP and select local-dlp.conf. 5. Click OK. 6. Click OK to reboot.
© FORTINET 1 Blocking Files by File Type There are multiple ways that you can configure in DLP to block sensitive information leaving out of your network. In this exercise, you will configure the DLP to block files by file types and apply to firewall policy. Then, you will test the configuration and view the logs.
Enabling DLP DLP is not enabled in the GUI by default. You will enable DLP to be visible in the GUI.
To enable DLP 1. On the Local-Windows, open a browser and log in as admin to the Local-FortiGate GUI at 10.0.1.254. 2. Go to System > Feature Select. 3. Under Security Features, enable DLP. 4. Click Apply.
© FORTINET 5. Configure the following settings:
Field Value
Action Block
6. Click OK. 7. Click on Apply on the DLP sensor window.
Note: You can also block based upon a file name of *.zip, but it is not recommended. A person could circumvent that type of DLP by changing the filename to, for example, *.zp1, or *.txt. In comparison, file type identification works by analyzing the binary layout of the file.
© FORTINET Applying a DLP Sensor to a Firewall Policy Now that you have created a DLP sensor, you will be editing existing firewall policy to apply the DLP sensor to it.
Note: When selecting a DLP sensor, Proxy Options is automatically enabled. You cannot disable Proxy Options, but can select any pre-configured proxy options profile from the associated drop-down list.
6. Click OK. 7. Optionally, if you would like to see the default proxy options profile selected in the firewall policy, go to Security Profiles > Proxy Options. This profile determines how FortiGate's proxies pick up protocols. For example, the HTTP listening port is set to port 80.
© FORTINET To check the DLP logs 1. In the Local-FortiGate GUI, go to the Log & Report > Forward Traffic. 2. Find the log entry that has DLP in the Security Events column and a Result column with a Deny action for this attempted data leak. 3. Double click on that log entry to select it.
4. On the right-hand side, the Details column shows the forward traffic log information such as NAT translation, NAT IP, policy ID, and security action.
You can also view DLP logs under Log & Report > Data Leak Prevention.
Note: The DLP logs section will not display if there are no DLP logs. FortiGate will show it after creating logs. If this menu item does not display, log out from the FortiGate GUI and log in again to refresh it.
© FORTINET 2 Quarantining an IP Addresses You can also configure the action to quarantine IP addresses that are trying to leak the sensitive information. The quarantined IP address will be blocked from accessing the network so that you have time to investigate the issue proactively.
Quarantining an IP Address Now you will be modifying action of the previously configured DLP filter to quarantine the IP address.
To quarantine an IP address 1. On the Local-Windows, open a browser and log in as admin to the Local-FortiGate GUI at 10.0.1.254. 2. Go to Security Profiles > Data Leak Prevention. 3. Edit the No_ZIP_files DLP sensor by selecting it from right-hand dropdown menu.
6. Click OK. 7. Click Apply.
© FORTINET 6. Click DLP_Lab.Zip. 7. Click Open. 8. Click Submit the file. The DLP block message will appear. 9. In the Local-Windows VM, open a web browser and go to the few websites such as: http://www.bbc.com http://dailymotion.com
A replacement message should appear instead of the website. This occurs because the IP address that is sending the request has been quarantined and is not allowed through the firewall policy on the FortiGate.
© FORTINET 3 DLP Fingerprinting DLP fingerprinting is technique that uses content-based filtering and identifies specific files using one or more CRC checksums for the files in the configured network share.
edit No_ZIP_files
config filter
edit 2
© FORTINET Note: DLP fingerprinting filter can only be configured from the CLI. Once it is configured, it is visible in GUI.
© FORTINET Modifying a File in the Network Share Now you will modify a file in the network share.
6. Close Notepad++.
Note: Fingerprinting breaks the file into chunks and performs checksums on each part. By default, DLP will detect a match if any part's checksum from the fingerprint matches.
© FORTINET LAB 10–Diagnostics In this lab, you will run some diagnostic commands to learn about the current status of the FortiGate. You will also use the sniffer and debug flow tools to troubleshoot and fix a connectivity problem.
Objectives Identify your network's normal behavior. Monitor for abnormal behavior such as traffic spikes. Diagnose problems at the physical and network layers. Diagnose connectivity problems using the debug flow. Diagnose resource problems, such as high CPU or memory usage.
© FORTINET 3. Select to restore from Local PC and click Upload. 4. Browse to Desktop > Resources > FortiGate-II > Diagnostics and select local- diagnostics.conf. 5. Click OK. 6. Click OK to reboot.
© FORTINET 1 Knowing What is Happening Now During this exercise you will use CLI commands to get information about the FortiGate, such as traffic volume crossing the device, CPU usage, memory usage, and an ARP table.
Hostname: ______________________
Tip: Use the following CLI commands to find the information requested above:
© FORTINET get hardware nic port1
© FORTINET 2 Troubleshooting a Connectivity Problem During this exercise you will use the sniffer and debug flow to troubleshoot a network connectivity problem.
ping -t 10.200.1.254 The ping is failing. You will use the sniffer and debug flow tools in the Local-FortiGate to find out why. Do not close this window. Keep the ping running.
© FORTINET Using the Debug Flow Tool To get information about why the packets are being dropped, you will run the debug flow tool.
© FORTINET To fix the problem 1. On the Local-Windows, open a browser and log in as admin to the Local-FortiGate GUI at 10.0.1.254. 2. Go to Policy & Objects > IPv4 Policy. Look at the firewall policies. There is only one and it does not allow ICMP traffic (only HTTP). That explains why the FortiGate is dropping the ping packets. 3. Edit the policy. 4. Change the service from HTTP to ALL. 5. Click OK.
ping -t 10.200.1.254 6. Check the debug flow output. It is a bit different now. The error message is not displayed and you will see the a few new logs. Traffic is allowed by the firewall policy with the ID 1:
© FORTINET id=20085 trace_id=7 func=fw_forward_handler line=698 msg="Allowed by Policy-1: SNAT" FortiGate applies source NAT (SNAT):
Tip: The procedure in this exercise describes what you should usually do when troubleshooting connectivity problems with a FortiGate. Sniffer the traffic first to check that the packets are arriving to the FortiGate, and that the FortiGate is properly routing them out. If the sniffer shows that the traffic is being dropped by the FortiGate, use the debug flow tool to find out why.
© FORTINET LAB 11–IPv6 In this lab, you will perform initial IPv6 interface configuration, and add an IPv6 network prefix to your Local-FortiGate to advertise and automatically configure Local-Windows. Then, you will configure two IPv6 transition technologies: NAT64 and IPv6 over IPv4 IPsec. The IPsec tunnel will connect the two internal networks of your FortiGate devices. Remote-FortiGate is already configured, so you will only need to configure Local-FortiGate.
Objectives Show IPv6 options in the FortiOS GUI. Configure an IPv6 address and administrative protocols on an interface. Test IPv6 connectivity. Configure a FortiGate to automatically configure Windows and other hosts on the local network with an IPv6 address and prefix. Configure transition technologies including NAT64, and IPv6 over IPv4 IPsec.
Prerequisites Before beginning this lab, you must restore a configuration file to both the Local-FortiGate and Remote-FortiGate.
© FORTINET 1 IPv6 Interface and SLAAC Setup During this lab you will configure the Local-FortiGate to dynamically assign an IPv6 prefix to the Local- Windows VM using stateless auto-address configuration (SLAAC).
2001:db8:1::254/64 Notice, however, that this does not enable FortiGate to offer DHCPv6 or SLAAC on port3 yet. 7. Click OK.
Configuring SLAAC SLAAC configuration must be done via CLI.
To configure SLAAC 1. In the Local-Windows VM, open PuTTY and connect to the LOCAL-FORTIGATE saved session (connect over SSH). 2. Enter the following commands to configure port3 with an IPv6 prefix and enable SLAAC:
edit port3
config ipv6
config ip6-prefix-list
© FORTINET edit 2001:db8:1::/64
SetDHCP 2. Refresh the IPv6 address information, and then verify that it has auto-configured IPv6 settings from FortiGate. To do this, in the command prompt window, run the commands:
ipconfig /renew
ipconfig If SLAAC was successful, you should see an IP address in the 2001:db8:1::/64 range, such as:
© FORTINET ping 2001:db8:1::254 4. Open a web browser. Go to the GUI of the Local-FortiGate using its IPv6 address: http://[2001:db8:1::254]/
© FORTINET 2 NAT64 In this exercise you will configure the Local-FortiGate to translate IPv6 addresses to IPv4.
end 4. Create IPv6 firewall address objects for the IPv6 internal subnets on Local-FortiGate:
edit "LOCAL_INTERNAL6"
edit "REMOTE_INTERNAL6"
end 5. Create a firewall policy that applies NAT64 between port3 and port1 for HTTP and ICMP traffic. Remember that the source address is an IPv6 address; the destination address is an IPv4 address:
edit 0
© FORTINET set dstintf "port1"
To test NAT64 1. In the Local-Windows VM, open a command prompt window and test IPv6 connectivity to port4 on the Remote-FortiGate by entering this command:
ping 64:ff9b::ac8:301
© FORTINET 3 Using IPsec to Tunnel IPv6 Over an IPv4 Network During this exercise you will create an IPv4 IPsec tunnel between the Local-FortiGate and Remote- FortiGate to encapsulate IPv6 traffic between the local subnet (2001:db8:1::/64) and the remote subnet (2001:db8:2::/64). The Remote-FortiGate is already configured. Your task in this exercise is to configure the Local- FortiGate side.
edit "ipv4_to_ipv6"
end 3. Create an IPsec phase 2 object with the IPv6 source address of the Local-FortiGate and the destination IPv6 address of the Remote-FortiGate:
edit "ipv4_to_ipv6-P2"
© FORTINET set dst-subnet6 2001:db8:2::/64
© FORTINET set dstaddr "LOCAL_INTERNAL6"
ping 2001:db8:2::254 This IPv6 traffic is encapsulated and sent encrypted through an IPv4 network. 2. From the Local-FortiGate's CLI, execute the following commands to check the IPv6 routes, interface addresses, and the tunnel state, noting the selectors (proxy IDs) for the IPv6 subnets:
© FORTINET Appendix A: Additional Resources
Forums https://forum.fortinet.com/
© FORTINET Appendix B: Presentation Slides
In this lesson, we will talk about how to route traffic with FortiGate devices.
After completing this lesson, you will have the practical skills needed to implement routing using static and policy-based routes. You will also learn about traffic load balancing using ECMP and WAN link load balancing. This lesson will also briefly introduce the concept of dynamic routing.
Lab exercises can help you to test and reinforce your skills.
To start the lesson, we will talk about static and policy routing.
What is routing?
Routing decides where FortiGate in NAT mode will send the packets that it receives, and that it generates.
All network devices doing routing have a routing table. As we will see later, a routing table contains a series of rules. One or more rules for each destination subnet. Each rule specifies how a packet must be routed to reach its destination. For example, FortiGate checks the destination field of the packet's IP header. If routing rules match that destination, FortiGate can transmit the packet from port1 to port2, towards Router 1 based on the information.
If an allowed packet is not destined for the FortiGate itself — not administrative access, for example — FortiGate must relay the packet. FortiGate searches for matching active routes in the routing table that it can use to deliver the packet. FortiGate either delivers the packet directly to its final destination, or relays it to the next router along the path towards the final destination.
Usually, IP routing is done based on the destination IP address; however, as we'll discuss later, you can also route packets using more than a destination IP address.
Proper routing configuration is important. If the routing directions are misconfigured, packets will not reach their destination and will be lost.
One type of manually configured route is called a static route. In the routing table, its Type column is set to Static.
When you configure a static route, you are telling the FortiGate device, "When you see a packet whose destination is within this range of destination addresses, send it through this network interface, towards this router." We also configure the distance and priority so that FortiGate knows which is the best route to any destination. We will talk about distance and priority later.
For example, in simple home networks, DHCP automatically retrieves and configures one static route. Your modem then sends all outgoing traffic through your ISP's Internet router, which can relay packets to their destination.
When a destination is cabled directly to one of FortiGate's network interfaces, with no router in between, FortiGate will be aware of the destination. In the route table, its Type is Connected.
If you create a firewall address object with the type IP/Netmask, you can use that firewall address as the destination of one or more static routes. First, enable the setting Static Route Configuration inside the firewall address configuration. Once it is enabled, the firewall address object is displayed and can be selected from the destination drop-down list of any static route.
For large networks, manually configuring hundreds of static routes may not be practical.
Your FortiGate can help, by configuring routes automatically. FortiGate supports several dynamic routing protocols: RIP, OSPF, BGP, and IS-IS.
In dynamic routing, FortiGate communicates with nearby routers to discover their paths, and to advertise its own directly connected subnets. Discovered paths are automatically added to FortiGate's routing table. (So verify that your neighbor routers are trusted and secured!)
Larger networks also may need to balance routing load among multiple valid paths, and detect and avoid routers that are down. We'll discuss that later also.
The routing table monitor in the FortiGate GUI shows the active routes.
• Directly connected subnets – When a subnet is assigned to a FortiGate's interface, a route to the subnet is automatically added to the routing table. The FortiGate knows how to route those packets. • Dynamic routes – On larger networks, your FortiGate may receive routes from other routers, via protocols such as BGP. This is faster and more scalable than manually configuring many routers.
• Inactive routes – Only active routes (which are usually the best paths) are displayed. We will see later how the best path is elected when there are multiple routes to the same destination. • Policy routes – These are omitted, too. Why? By design, policy routes override the routing table. So, they have to be in a separate table.
Each of the routes listed in the routing table includes several settings with associated values. Those values are used to relay or deliver each matching packet.
Destination IP address and gateway IP address are self-explanatory. The device is the name of the outgoing interface to where the packet will be routed. But what about the distance, metric, and priority? How do they effect which routing path packets will use?
Distance, or administrative distance, is a number that estimates the reliability or quality of each routing protocol and static route. If there are two routes to the same destination, the one with the lower distance value is active and used for routing because it is considered to be more reliable. The routes with higher distances are inactive and not used for routing.
By default, routes learned through the RIP protocol have a higher distance value than routes learned through OSPF protocol. OSPF is considered to be more accurate than RIP.
In the case of routes learned through a dynamic routing protocol, the metric is another value that is used to determine the best route to a destination. If two routes have the same distance, the metric is used to break the tie. The route with the lowest metric is active and used for routing.
How the metric is measured depends on the routing protocol. RIP uses hop counts, which is the number of routers to reach the destination. OSPF uses cost, which is determined by how much bandwidth a link has.
When multiple static routes have the same distance value, the priority value is used to determine the best route. That is, FortiGate uses the route with the lowest priority setting.
Note that, unlike routes that have the same distance and metric settings, all routes with the same distance setting are active. However, only the route with the lowest priority setting is used to route the traffic. This, as we will see later, is an important concept to know when dealing with reverse forwarding path (RPF) check issues.
We saw how the distance, metric, and priority settings are used to determine the best route to a destination. So, what happens when two or more routes to the same destination share the same values for all of those settings?
If the routes are static, OSPF, or BGP; FortiGate balances the traffic among all the routes. This is called equal cost multi-path (ECMP).
Sessions can be balanced among equal routes depending on the source IP address, source and destination IP addresses, or interface weight. There is an additional method called usage-based (or spillover). In usage-based routing, FortiGate uses a primary route until a traffic volume threshold is reached; after that, it uses the next available route.
Link health monitor is a mechanism for detecting when a router along the path is down. It is often used where there are redundant routers onsite, such as for dual ISP links.
When configured, FortiGate periodically sends signals through one of the gateways to a server that acts as a beacon. The server can be any host that should normally be reachable through that path. Usually, it's best to choose a stable server with robust infrastructure, and to choose the protocol to which the server would normally respond.
If the FortiGate stops receiving a replay from the server, all the routes using that gateway will be removed from the routing table. Alternatively, you can configure the device to administratively bring down an interface, so all routes using that interface will be removed. While a server is unresponsive, FortiGate will continue to send link health monitor signals. As soon as FortiGate receives a reply, it will reinstate the routes.
It may be useful to choose a server that is indirectly attached, located 1 or 2 hops beyond the FortiGate's gateway. This does not exactly test availability of this one gateway, but rather the combination of gateways. That way, FortiGate will accurately indicate availability of services and subsequent hops.
Here is how you configure the link health monitor from the CLI.
You must set the egress interface, the IP address of the gateway router, and the IP address and protocol (HTTP, ICMP, UDP or TCP) of a beacon that is beyond that gateway.
You can configure multiple link health monitors, for example one for each ISP.
Static routes are simple and are often used in small networks. Policy-based routes, however, are more flexible. They can match more than just the destination IP address. An example? If you have two links – a slow one and a fast one – you can route packets from low-priority source IPs to the slow link.
Policy routes with the action Forward Traffic have precedence over static and dynamic routes. So, if a packet matches the policy route, FortiGate bypasses the routing table lookup.
Like static routes, policy routes must be valid: a destination and gateway are required, and disconnected (or down) interfaces can't be used. For policy routes, packets must also match all specified subnets, ToS bits, and port number. So, if you don't want a setting to be included in the matching criteria, leave it blank.
When a packet matches a policy route, FortiGate takes one of two actions. Either it routes the packet to the configured interface and gateway, bypassing the routing table, or it stops checking the policy routes, so the packet will be routed based on the routing table.
In this section, we will examine a concept related with routing: reverse path forwarding check.
RFP is a mechanism that protects FortiGate and the network from IP spoofing attacks. It checks if there is a route back to the packet's source.
This check is executed over the first packet of any new session. It is also executed after a route change, over the next packet in the original direction.
Incoming Internet traffic arriving at wan1 will be accepted, because the default route is a valid route back to the source.
However, there are two interfaces that will not route some incoming traffic: port1 and wan2.
port1 will not route traffic because the subnet for user C is 10.0.4.0/24. There is no active route for that subnet through port1. So, traffic coming from 10.0.4.0/24 to port1 will be dropped because that subnet cannot be routed back.
The other interface that will not route traffic is wan2. While wan2 is physically connected to the Internet, the only IP addresses that are valid as sources or destinations are those in the 10.0.2.0/24 subnet. So, incoming Internet traffic will not pass the RPF check and will be dropped.
The first problem is fixed by adding a static route to 10.0.4.0/24. Now, when FortiGate does the RPF check for user C packets, it finds an active route to that subnet through port1 and the packet is accepted.
The second problem is also fixed by adding a static route. In this case, the route acts as a default gateway for wan2. To become active, it needs to have the same distance as the default route for wan1. They both can have different priorities, but they must have the same distance to be active.
This is an example of when two routes with the same distance, but different priorities, are required. So, one route will be the best (the one with the lowest priority), but both will be active. The best route will be used for outbound traffic, but both can receive incoming connections without failing the RPF check.
If the priorities are also the same, this creates a situation similar to the one we talked about in the ECMP example. So, if the destination is the Internet, there are two possible paths: through wan1 or through wan2. Some sessions will exit from wan1, and others will exit from wan2.
In loose mode, the packet is accepted as long as there is one active route to the source IP through the incoming interface. It does not have to be the best route, just an active one.
In strict mode, FortiGate checks that the best route to the source IP address is through the incoming interface. The route not only has to be active (as in the case of loose mode), but it also has to be the best.
In the following slide, we will look at two sample network configurations to compare loose mode to strict mode.
Let's start with the loose mode example. In this example, 10.0.4.1 pings 10.0.1.2, but spoofs a source IP of 10.0.1.1. This makes the packet appear to be initiated from the internal network. Loose RPF allows this traffic because the route on wan1 is a default route (0.0.0.0/0) that is active.
What happens next is that 10.0.1.2 would send the SYN/ACK packet to the real device with the IP address 10.0.1.1.
But since 10.0.1.1 is not expecting SYN/ACK packets (as it has not previously sent any SYN packet to 10.0.1.2), it will reply with a TCP reset (RST) packet.
Let's see what happens in the same sample network when strict RPF is used.
Strict RPF drops the packet. The default route in wan1 is an active route to the subnet 10.0.4.0/24, but it's not the best route. The best route is through the internal interface.
Although strict RPF is more secure, it can backfire if you use dynamic routing. Dynamic routes can change quickly, and they could cause FortiGate to drop legitimate packets each time the preferred route changes. In general, it is recommended to use loose RPF in combination with firewall policies that block spoofed traffic, instead of using strict RPF for that purpose.
In this section, we'll examine two additional routing features in FortiGate: internet services and WAN link load balancing.
Internet services is a database that contains a list of IP addresses, IP protocols, and port numbers used by the most common Internet services. FortiGate periodically downloads the newest version of this database from FortiGuard. The information can be used to selectively route traffic to any of the listed Internet services though specific WAN interfaces.
What happens if you need to route traffic to a public Internet service (such as Dropbox or Facebook) through one specific route? Let's say that you have two ISPs and you want to route Netflix traffic through one ISP and all your other Internet traffic though the other ISP. To achieve this goal, you need to know the Netflix IP addresses and configure multiple static routes. After that, you would need to frequently check to make sure that none of the IP addresses have changed. Internet services helps make this type of routing easier and simpler.
You can use Internet services addresses as the destination for static routes. In this example, we are configuring FortiGate to route all Google DNS traffic through interface port1.
Static routes created using Internet services addresses (for example, static routes with either subnet or named addresses as the destination) are not added to the routing table; they are added to the policy routing table. These routes can be displayed using the CLI command diagnose firewall proute list . This command lists all the active routes in the policy routing table.
WAN link load balancing consists of a group of interfaces usually connected to multiple ISPs. FortiGate sees all those Internet interfaces as one single logical interface: the WAN load balancing interface. This simplifies the configuration because the administrator can configure a single set of routes and firewall policies that will be applied to all the ISPs.
There can be only one WAN load balancing interface per VDOM.
WAN link load balancing uses traffic distribution methods that are similar to ECMP; however, WAN link load balancing includes one more balancing method: volume.
• Source IP: Traffic from the same IP address uses the same link. • Source-destination IP: Traffic from the same pair of source and destination IP addresses uses the same link. • Spillover: Similar to the spillover method for ECMP. A link routes all the traffic until the volume reaches a threshold, after that another link is used. • Sessions: The interface weights define the proportion of sessions that each link should have. Sessions are distributed among the links based on the interface weights. • Volume: The interface weights define the proportion of traffic volume that each link should have. Sessions are balanced so that traffic volume is distributed based on the interface weights.
When configuring WAN link load balancing, you specify which interfaces are going to be members. In other words, which interfaces are connected to the Internet.
After you have configured WAN link load balancing, a logical interface with the name wan-load- balance is automatically added to the configuration. Next, you create the routes and firewall policies using this logical interface.
FortiGate can check the status (health) of each interface member of a WAN link load balancing group. After configuring a protocol, a server IP address, and a failure threshold, FortiGate periodically sends IP packets to the server through each of the links. If the number of consecutives packets with no reply in one link goes above the threshold, that member is removed from WAN link load balancing.
The WAN status checks also measure the quality of the links connected to each WAN interface. Three different criteria are used for this measurement: latency, jitter, and packet loss percentage. As we will see in the next slides, priority rules can be used to route traffic based on the link quality of each member.
Priority rules allow you to specify what traffic you want to route through which interface. You can use priority rules to route traffic through specific interfaces, or through the interface with the highest link quality. Routing rules can be based on any of the three criteria: latency, jitter, or packet loss percentage.
The priority rules are evaluated in the same way as the firewall policies: from top to bottom, using the first match. The following parameters can be used to match the traffic:
• Source IP address • Destination IP address • Destination port number • Internet service • Users and/or user groups • Type of service (ToS)
This offers great flexibility when configuring how FortiGate routes traffic. For example, you can route Facebook traffic from specific authenticated users through one ISP, while keeping your other Internet traffic through another ISP.
Similar to static routes with Internet services, priority rules are added as policy routes. Priority rules can be displayed using the CLI command diagnose firewall proute list.
In this example, we have created a rule to route Google DNS traffic through port1. The slide shows the partial output of the policy route added.
To finish this lesson, we will provide some commands and tools for troubleshooting routing problems.
The CLI command get router info routing-table all displays all the active routes in the routing table. The left column indicates the source for the route.
The second number is the metric. This command doesn't show inactive routes. For example, when two static routes to the same destination subnet have different distances, the one with the lowest distance is active. The one with the highest distance is inactive. So, this command displays only the one with the lowest distance (the active one).
If you want to display both the active and the inactive routes, use this CLI command: get router info routing-table database.
In this example, you can see that the command shows one inactive route. The route is inactive because it has a higher distance than the one below.
Packet captures, or sniffers, are one of the most useful sources of information for debugging network problems. FortiOS includes a built-in traffic sniffer tool. It can be used to check when packets arrive to the device, and which outgoing interfaces are used to route them out.
The built-in sniffer can be executed from either the GUI or the CLI. The syntax of the CLI command is diagnose sniffer packet <interface> <filter> <level>. The interface is the name of the physical or logical interface; if your account has the access profile super_admin, you can specify any to sniffer all the interfaces. The filters are similar to tcpdump on Linux.
The level specifies how much information you want to display. There are six different levels and this table shows which ones display the IP headers, IP payloads, Ethernet headers, and interface names.
We usually run verbosity 4 to take a quick look of how the traffic is flowing through FortiGate (if packets arrive and how FortiGate is routing them out.) The verbosity 4 can also be used to easily check if FortiGate is dropping packets.
Verbosities 3 and 6 provide the longest outputs. Both show the IP payloads and Ethernet headers. You can save their output and export it to a packet capture (pcap) file using a Perl script. The pcap file can then be opened with a packet analyzer, such as Wireshark, for further investigation. The Perl script that converts the sniffer output to pcap can be found on the Fortinet Knowledge Base website (kb.fortinet.com).
This slide shows two examples of packet sniffer outputs. The first sniffer captures all traffic to and from port 443. It uses verbosity 4, so the information is easy to read. It displays one line per packet, containing the incoming and outgoing interface, IP addresses, port numbers, and type of packet (SYN, SYN/ACK, and so on).
The second sniffer captures all ICMP traffic coming from or going to the host 192.168.1.254. In this case, the output is verbosity 3, which is longer and more difficult to read as it includes the IP payload of the packets. However, this is one of the two verbosity levels to use (6 being the other one) if you need to export the output to Wireshark.
If your model of FortiGate has internal storage, you can capture packets from the GUI. The options are similar as those for the CLI. To run a trace, specify a source interface and a filter.
What is the main advantage over the CLI? You download the output in a file format (pcap) that is ready to be open with Wireshark, without having to use a conversion script.
Regardless of which method you use (CLI or GUI), packet capture filters should be very specific. So, you will capture only the relevant packets and avoid writing large amounts of data to disk.
To review, in this lesson we talked about static and policy-based routing concepts and configuration, including the following topics:
In this lesson, we will show you how to configure virtual domains (VDOMs) and common usage examples. This lesson also covers VLANs configuration.
After completing this lesson, you should have the practical skills that you need to create VDOMs and VLANs. You will also learn to limit the resources allocated to each VDOM and create per-VDOM administrative accounts. The lesson also covers inter-VDOM connectivity.
VDOMs are a virtualization within FortiOS, providing virtual firewalls. Interfaces have VDOM membership. The interface that a packet arrives on determines which VDOM processes the traffic. Interfaces can be physical or logical; IEEE 802.1Q VLANs are logical interfaces commonly used in FortiGate devices.
VLANs split your physical LAN into multiple logical LANs. In NAT/Route mode, each VLAN forms a separate broadcast domain. Multiple VLANs can coexist in the same physical interface. In this way, a physical interface is split into two or more logical interfaces. A tag is added to each Ethernet frame to identify the VLAN to which it belongs.
This slide shows an Ethernet frame. The frame contains the destination and source MAC addresses, the type, the data payload, and a CRC code, to confirm that is not corrupted.
In the case of Ethernet frames with VLAN tagging, according to the 802.11q standard, four more bytes are inserted after the MAC addresses. They contain an ID number that identifies the VLAN.
An OSI Layer 2 device, such as a switch, can add or remove these tags from Ethernet frames, but it cannot change them.
A Layer 3 device, such as a router or a FortiGate, can change the VLAN tag before proceeding to route the packet. In this way, they can route traffic between VLANs.
When operating in NAT/route mode, FortiGate operates as an OSI Layer 3 router in its most basic configuration. In this mode, a VLAN is an interface on the device. VLAN tags may be added on egress, removed on ingress, or rewritten based on a routing decision.
In this example of NAT/route mode, a host on VLAN 100 sends a frame to a host on VLAN 300. Switch A receives the frame on the untagged VLAN 100 interface. After that, it adds the VLAN 100 tag on the tagged trunk link between switch A and the FortiGate. (click)
FortiGate receives the frame on the VLAN 100 interface. Then, it routes the traffic from VLAN 100 to VLAN 300, rewriting the VLAN ID to VLAN 300 in the process. (click)
Switch B receives the frame on the VLAN trunk interface and removes the VLAN tag before forwarding the frame to its destination on the untagged VLAN 300 interface.
To create a VLAN from the GUI, click Create New and select VLAN as the Type. You must specify the VLAN ID and the physical interface to which the VLAN will be bound. Frames that belong to interfaces of that type are always tagged. On the other hand, frames sent or received by the physical interface segment are never tagged. They belong to what is called the native VLAN.
What if more than segmenting your network, you want to subdivide policies and administrators into multiple security domains?
In that case, you can enable FortiGate VDOMs, which split your physical FortiGate into multiple logical devices. Each VDOM has independent security policies and routing tables. Also, and by default, traffic from one VDOM cannot go to a different VDOM. This means, for example, that two interfaces in different VDOMs can share the same IP address, without any overlapping subnet problems.
To enable VDOMs from the GUI, in the System Information widget on the dashboard, click Enable in the Virtual Domain field.
Alternatively, to enable VDOMs when you are logged into the CLI, enter the command: set vdom-admin enable
This won't reboot your FortiGate, but it will log you out; enabling VDOMs restructures both the GUI and CLI, which you will see when you log in again.
After enabling VDOMs, by default, only one VDOM exists: the root VDOM. It's the default management VDOM, which we will discuss later in the lesson.
You need to add a VDOM for each of your security domains. If you're an MSSP, for example, you might add one VDOM for each client company. If you are an enterprise business, you might add one VDOM for each division of your company.
The inspection mode (proxy or flow-based) is a per-VDOM setting that defines how traffic is inspected.
In a VDOM in proxy mode, FortiGate inspects the traffic acting as an implicit TCP proxy. The original client-to-server TCP session is actually split into two TCP sessions: one from the client to the FortiGate, and another one from the FortiGate to the server.
In a VDOM in flow-based mode, the traffic is scanned on a TCP flow basis as it passes through FortiGate. There is no implicit TCP proxy involved.
The operation mode is also a per-VDOM setting. You can combine transparent mode VDOMs with NAT/route mode VDOMs in the same physical FortiGate.
After adding the additional VDOMs, you can proceed to specify which interfaces belong to each VDOM. Each interface (physical or VLAN) can belong to only one VDOM.
Remember, VDOMs are a logical separation only – each VDOM shares physical resources with the others.
Unlike with FortiGate-VM, VDOMs are not allocated and balanced with weighted vCPU cores, vRAM, and other virtualized hardware.
To fine-tune performance, you can configure resource limits for each feature – IPsec tunnels, address objects, and so on – at both the global level and at each VDOM level. This controls the ratio of each VDOM's system resource usage to the total available resources.
For example, on this FortiGate, the hardware is powerful enough to handle up to 2000 IPsec VPN tunnels. The FortiGate is configured with three VDOMs.
vdom1 and vdom2 don't use IPsec VPN tunnels often. So, they are allowed to have up to 50 tunnels each. vdom3, however, uses VPN extensively. Therefore, this FortiGate will be configured to allow vdom3 to have up to 1900 tunnels. Additionally, 1000 of those tunnels will be guaranteed.
Configure your FortiGate with global limits for critical features such as sessions, policies, and others. Then configure each VDOM with its own quotas and minimums, within the global limits.
Global resource limits are an example of global settings. The firmware on your FortiGate and some settings, such as system time, apply to the entire appliance – they are not specific to each VDOM.
Most settings, however, can be configured to be different for each VDOM. Some examples are: firewall policies, firewall objects, static routes, protection profiles, and so on.
If you log in as most administrator accounts, you will enter your VDOM automatically.
But if you are logged in as the account named admin, you aren't assigned to any VDOM.
To enter a VDOM on the GUI, select the VDOM from the drop-down list on the top.
Inside each VDOM, the submenu should be familiar: it is essentially the same navigation menu that you had before you enabled VDOMs. However, the global settings are moved to the Global part of the menu.
To access the global configuration settings from the CLI, you must first type config global to enter into the global context. After that, you can execute global commands and change global configuration settings.
To access per-VDOM configuration settings from the CLI, you must first type config vdom, then type edit followed by the VDOM name. From the VDOM context you can execute VDOM-specific commands and change per-VDOM configuration settings.
Regardless of the context where you are (global or VDOM), you can use the sudo keyword to execute diagnostics commands in a context different than your current one. This allows you, for example, to execute global and per-VDOM commands without switching back and forth between the global and per-VDOM context.
If you want to grant access to all VDOMs and global settings, select super_admin as the access profile when configuring the administrator account. Similar to the account named admin, this account will be able to configure all VDOMs.
Best practice dictates that you should usually avoid unnecessary security holes, however. Do not provide super_admin access if possible. Instead, restrict each administrator to their relevant domain. That way, they cannot accidentally or maliciously impact other VDOMs, and any damage or mistakes will be limited in scope.
In most cases, you'll start by creating one administrator account per VDOM. That administrator will be chiefly responsible for that domain, including that VDOM's configuration backups. In larger organizations, you may need to make more VDOM administrators. Multiple administrators can be assigned to each VDOM. You can subdivide permissions using access profiles in order to follow best practices for segregation of duties.
The converse is also possible. If required, you can assign an administrator to multiple VDOMs.
To create new administrator accounts and assign them to a VDOM, go to the Global part of the menu.
To review, each VDOM behaves as it is on a separate FortiGate appliance. With separate FortiGates, you would normally connect a network cable and configure routing and policies between them. But VDOMs are on the same FortiGate. So how should you route traffic between them?
The solution is inter-VDOM links. With inter-VDOM links, you won't send traffic out through a physical cable or VLAN, and then back into the same FortiGate to reach another VDOM. Inter-VDOM links are a type of virtual interface.
Note that like with inter-VLAN routing, Layer 3 must be involved – you cannot create an inter-VDOM link between layer-2 transparent mode VDOMs. At least 1 of the VDOMs must be operating in NAT mode. This, among other benefits, prevents potential Layer 2 loops.
When creating inter-VDOM links, you'll need to create the virtual interfaces. You must also create a matching firewall policy, just as you would if the traffic were arriving on a network cable. Otherwise, FortiGate will block it.
Additionally, routes are required to properly route packets between two VDOMs.
In the menu, creating a network interface is located in the Global settings. To create the virtual interface, click Create New, then choose VDOM Link.
In the global section of the GUI, there is a VDOM monitor. It displays the CPU and memory usage for each VDOM.
Up until now, we've discussed traffic passing through FortiGate, from one VLAN or VDOM to another. What about traffic originating from your FortiGate itself?
Some system daemons, such as NTP and FortiGuard updates, generate this kind of traffic. One, and only one, of the VDOMs in a FortiGate device is assigned the role of being the management VDOM. Traffic from FortiGate to those global services is originated from the management VDOM. By default, the VDOM root acts as the management VDOM, but you can manually re-assign this task to a different VDOM.
Similar to a FortiGate without VDOMs, the administrative VDOM usually should have outgoing Internet access. Otherwise, features such as scheduled FortiGuard updates will fail.
There are a few ways you can arrange your VDOMs. In this topology, each network accesses the Internet through its own VDOM.
Notice that there are no inter-VDOM links. So, inter-VDOM traffic is not possible unless it physically leaves the FortiGate, towards the Internet, and is rerouted back. This is most suitable for multiple customers sharing a single FortiGate, each in their own VDOM, with physically separated ISPs, for example.
Like the previous topology, each network sends traffic through its VDOM. But after that, traffic is routed through the management VDOM – by default, named root. So, Internet-bound traffic flows through a single pipe in the root VDOM.
This could be suitable for multiple customers sharing a single FortiGate, each in their own VDOM. But in this case, the management VDOM could log and monitor traffic and/or provide standard services like antivirus scanning.
Note that this topology has inter-VDOM links, but peer VDOMs are only linked with the management VDOM, not with each other.
Inspection could be done by either the root or originating VDOM, depending on your requirements. Alternatively, you could split inspection so that some scans occur in the root VDOM – ensuring a common security baseline – while other more intensive scans occur in the originating VDOM.
Here, traffic again flows through a single pipe in the root VDOM towards the Internet. Traffic between VDOMs doesn't need to leave the FortiGate either.
However, now inter-VDOM traffic doesn't need to flow through the management VDOM. Inter-VDOM links between VDOMs allow more direct communication.
Like the previous example, inspection could be done by either the root or originating VDOM, depending on your requirements.
Due to the number of inter-VDOM links, this example is the most complex, requiring the most routes and firewall policies. Troubleshooting meshed VDOMs can also be more time-consuming.
However, meshed VDOMs also provide the most flexibility. For large businesses, inter-VDOM communication may be required. Also, inter-VDOM traffic performance may be better due to a shorter processing path which bypasses the management VDOM.
This is a review of what we covered: VLANs, VDOMs, Inter-VDOM links, and VDOM topologies.
In this lesson, you will learn how to do transparent mode and Layer 2 switching in a FortiGate.
After completing this lesson, you should have these practical skills that you can use to configure FortiGate for Layer 2 switching:
Traditional IPv4 firewalls and NAT mode FortiGates handle traffic as routers do. So, each interface has to be in different subnets and each forms different broadcast domains. FortiGate routes IP packets based on the IP header information, overwriting the source MAC address. So, if a client sends a packet to a server connected to a different FortiGate interface, the packet will arrive to the server with a FortiGate MAC address, instead of the client's MAC address.
In the case of transparent mode, FortiGate forwards frames without changing the MAC addresses. When the client receives a packet from a server connected to a different FortiGate interface, the frame contains the server's real MAC address – FortiGate doesn't rewrite the MAC header. The FortiGate is a Layer 2 bridge or switch. So, the interfaces do not have IP addresses and all belong (by default) to the same broadcast domain.
This means that a transparent mode FortiGate can be installed in a customer network without changing the customer's IP address plan. Some customers, especially large organizations, don't want to reconfigure thousands of devices to define a new internal vs. external network.
FortiGate has three connected ports, each with separate IP subnets. All interfaces on the FortiGate have IP addresses, and, in this case, NAT translates between networks. Firewall policies allow traffic to flow between networks.
FortiGate handles packets according to their routes, which are in most of the cases based on the destination IP address (at Layer 3 of the OSI model).
Clients on each subnet send frames that are destined for a FortiGate MAC address – not the real MAC address of the server.
Here is an example showing transparent mode. Firewall policies still scan, then allow or block traffic. But there are differences.
Notice that the physical interfaces on FortiGate have no IPs. So FortiGate won't respond to ARP requests. There are some exceptions although. For example, when changing to transparent mode, you must specify a management IP address to receive connections from your network administrators; and send log messages, SNMP traps, alert email, and so forth. This IP address is not assigned to any particular interface, but to the VDOM settings.
By default, a transparent FortiGate won't do NAT. Also, clients will send frames destined directly to the real router or server MAC address.
We have mentioned that a transparent mode FortiGate acts as a transparent bridge. What does that mean?
It means that FortiGate has a MAC address table that contains, among other things, the interface that must be used to reach each MAC address. FortiGate populates this table with information taken from the source MAC address of each frame.
FortiGate, as a transparent switch, splits the network into multiple collision domains, reducing the traffic in the network and improving the response time.
In transparent mode, by default, each VDOM forms a separate forward domain. Interfaces, though, don't. How does this affect the network?
Until you change the initial VDOM configuration, all interfaces, regardless of their VLAN ID, are part of the same broadcast domain. FortiGate will broadcast from every interface in the VDOM in order to find any unknown destination MAC address. On large networks, this could generate massive broadcast traffic and overwhelming replies – a broadcast storm.
Here's an illustration of the problem – a broadcast with all the interfaces on the forward domain 0 (default). One device sends an ARP request. It reaches FortiGate through one of the interfaces in the VDOM.
Because all interfaces belong to the same forward domain, FortiGate then re-broadcasts to all the other interfaces, even to interfaces that belong to different VLANs. This generates unnecessary traffic. After that, the ARP reply will still arrive on only one interface, and FortiGate will learn that the MAC is on that interface.
This example is the same network that we showed before, but here, different forward domain IDs are assigned to each VLAN.
Traffic arriving on one interface is only broadcast to interfaces that are in the same forward domain ID.
This debug command lists the MAC address table in a VDOM operating in transparent mode. The table, as we explained before, contains the outbound interfaces to reach each learned MAC address.
This section is about virtual wire pairing. As you will see, virtual wire pairing offers another way to create broadcast domains. With virtual wire pairing, you can also have interface pairs operating like transparent mode in a NAT/route VDOM.
You can use virtual wire pairing when only two physical interfaces need to be connected to the same broadcast domain. This is usually the case, for example, of a FortiGate connected between the internal network and the ISP's router.
When you configure virtual wire pairing, two ports are logically bound or linked, acting like a filtered cable or pipe. All the traffic that arrived to one port is forwarded to the other port. This avoids issues related with broadcast storms or MAC address flapping.
Here's an example where two virtual wire pairs are used in a FortiGate in transparent mode.
This FortiGate has four ports, each connected to different physical locations. But traffic is not allowed to flow between all four locations. Virtual wire pairing only allows traffic between ports in the same pair: between port1 and port2, and between port3 and wan1.
So, in this example, the network on port3 can reach the Internet through wan1. However, the networks on port2 and port1 can't reach the Internet. They can only reach each other.
This, on the other hand, is an example of a virtual wire pair in a FortiGate operating in NAT mode. In this example, IP packets ingressing interfaces wan1 and internal are routed using the IP header information. Those two interfaces have different IP addresses, and each one forms a separated broadcast domain.
Now, the case of interfaces wan2 and dmz is different. As they are configured as a virtual port pair, they don't have IP addresses assigned, and they form one single broadcast domain. Observe the IP addresses for the server and the router connected to wan2. They must both belong to the same subnet.
So, virtual wire pairing offers a way to mix NAT/route mode functionalities with some transparent mode functionalities into the same VDOM.
Creating a virtual wire pair requires selecting two physical interfaces, no more, no less.
After that, you create the virtual wire pair policies to inspect the traffic crossing the virtual wire pair. The Wildcard VLAN setting specifies how to apply those policies to the different VLANs whose traffic flows between the pair:
• If Wildcard VLAN is enabled, the virtual wire pair policies are applied equally to the physical interfaces and VLANs' traffic. • If Wildcard VLAN is disabled, the virtual wire pair policies are applied only to the physical interfaces. Traffic with any VLAN tag is denied.
The firewall policies for virtual wire pairing are created under a different menu section. This section is displayed as long as there is at least one virtual wire pair created.
In this section, we will explore software switches. A software switch adds a virtual Layer 2 switch to the FortiGate configuration.
A software switch groups multiple interfaces to form a virtual switch, which acts as a hardware Layer 2 switch. This means that all switch interfaces are part of the same broadcast domain.
Each software switch has a virtual interface associated with it. Its IP address is shared by all the physical switch interfaces. You use this virtual interface in the firewall policies and routing configuration.
In this example, the administrator grouped a wireless interface with port1 and port2 to form a software switch. These three interfaces are part of the same broadcast domain. All the devices connected to the switch interfaces belong to the same IP subnet 192.168.1.0/24. This allows FortiGate, for example, to forward broadcast traffic from the wireless clients to port1 and port2.
The software switch interface itself has an IP address, which is also in the same subnet 192.168.1.0/24. This is the default gateway IP address for all the devices connected to the software switch.
The server 10.0.1.1 is connected to an interface (dmz) that is not part of the software switch. So, it belongs to a different broadcast domain and IP subnet.
This section is about FortiGate devices in Layer 2 networks running spanning tree protocol.
Spanning tree protocol automatically ensures that there are no Layer 2 loops. By default, FortiGate does not participate in STP learning, nor forward BPDUs. But you can enable it. (You must still restrict broadcast domains so that they are not overwhelmingly large, though)
To enable FortiGate to participate in the STP tree, use the config system stp command in the CLI.
Note that this is only supported on models with physical switch interfaces, such as FortiGate 30D, 60C, 60D, 80C, and 90D.
For interfaces that are not physical switch interfaces, you can either forward or block STP BPDUs.
In this lesson, you'll learn the fundamentals of FortiGate high availability (HA) and how to configure it. FortiGate HA provides a solution for enhanced reliability and increased performance.
After completing this lesson, you should have the practical skills required to configure, operate, and monitor a FortiGate HA cluster.
In FortiGate HA, one FortiGate device acts as the primary appliance (also called the active FortiGate). It synchronizes its configuration to the other devices. The other FortiGates are called secondary or standby devices.
A heartbeat link between all the appliances is used to detect unresponsive devices.
What is synchronized between the devices? Are all FortiGate devices processing traffic? Does HA improve availability, or does it improve throughput?
The answers vary depending on the HA mode. There are currently two HA modes available: active- active and active-passive. Let's examine the differences.
First, let's take a look at active-passive mode. In either of the two HA operation modes, the configuration of the secondary FortiGates is synchronized with the configuration of the primary device. (click)
In active-passive mode, the primary FortiGate is the only FortiGate device that actively processes traffic. Secondary FortiGates remain in passive mode, monitoring the status of the primary device. (click)
If a problem is detected in the primary FortiGate, one of the secondary devices will take over the primary role. This event is what we call HA failover.
Like active-passive HA, in active-active HA, all FortiGates' configurations are synchronized. Also, if a problem is detected in the primary device, one of the secondaries will take over the role of the primary, to process the traffic.
However, one of the main differences in the active-passive mode is that in the active-active mode, all of the FortiGates are processing traffic. One of the tasks of a primary FortiGate in active-active mode is to balance some of the traffic among all the secondary devices.
FortiGate HA uses FGCP, the FortiGate clustering protocol, for HA-related communications. FGCP travels between the clustered FortiGate devices over the links that you have designated as the heartbeats.
A heartbeat link between the two FortiGate devices should be achieved using a regular RJ45 or crossover cable. If you have another device in between, such as a switch, ensure that it is dedicated and isolated from the rest of your network. In this way, critical FGCP traffic does not need to compete with the other traffic for bandwidth.
NAT mode cluster and transparent mode cluster use different Ethernet type values to discover and verify the status of other FortiGates in an operating cluster.
FortiGates in a cluster also use telnet sessions over TCP port 23 with Ethernet type 0x8893 over heartbeat links to synchronize the cluster configuration and to connect to the CLI of another FortiGate in a cluster.
First, at least two, but up to four, FortiGate devices with the same: • Firmware • Hardware model and VM license • Hard drive capacity and partitions • Operating mode (transparent or NAT)
Second, at least one link between the FortiGate devices for the HA communication, which is called heartbeat traffic. For redundancy, up to eight heartbeat interfaces can be used. If one link fails, HA will use the next one, as indicated by priority and position in the heartbeat interface list.
Third, the same interfaces on each FortiGate device have to be connected to the same switch or LAN segment. Notice that in the example shown in the slide, the FortiGate devices are redundant to mitigate failure. But, the switches and their links still are a single point of failure. As we will see later, you can also have redundancy in the network switches and links.
One important change in HA, is that now the cluster can include interfaces whose IP addresses are assigned dynamically, through either DHCP or PPPoE. Prior to FortiOS 5.2, an HA cluster could only contain interfaces with static IP addresses. As a best practice (and Fortinet recommendation), configure the FortiGate interfaces with static IP addresses when forming an HA cluster. Once an HA is formed, you can configure the DHCP or PPPoE addressing for an interface. If an interface is configured for DHCP or PPPoE, enabling HA may result in the interface receiving an incorrect address, or not being able to connect to the DHCP or PPPoE server correctly.
The process for electing the primary FortiGate depends on an HA setting called HA override. This slide shows the process and selection criteria that a cluster uses to elect the primary FortiGate when the HA override setting is disabled, which is the default behavior.
Note: The selection process stops at the first matching criteria that successfully selects a primary FortiGate in a cluster.
1. The cluster first compares the number of monitored interfaces whose statuses are up. The FortiGate device with the most available monitored interfaces becomes the primary.
2. The cluster compares the system uptimes. If the system uptime of a device is five minutes more than the system uptimes of the other FortiGates, it becomes the primary.
3. The FortiGate with the configured highest priority becomes the primary.
When HA override is disabled, the uptime has precedence over the priority setting. If for any reason you need to change which device is the current primary, you can manually force a failover event. When the override setting is disabled, the easiest way of doing this is by executing the CLI command diagnose sys ha reset-uptime in the primary FortiGate.
Note: The reset-uptime command resets the HA age internally and does not affect the up time displayed on the dashboard of a FortiGate. Also, if a monitored interface fails, or a FortiGate in a cluster reboots, the HA uptime for that FortiGate is reset to 0.
You can alter the order of the selection criteria that clusters consider when electing the primary FortiGate.
If the HA override setting is enabled, priority is considered before the system uptime.
The advantage of this method is that you can specify which device is the preferred primary every time (as long as it is up and running) by configuring it with the highest HA priority value. The disadvantage is that a failover event is triggered not only when the primary fails, but also when the primary is available again. When a primary becomes available again, it takes back its primary role from the secondary FortiGate that temporarily replaced it.
When override is enabled, the easiest way of triggering a failover is to change the HA priorities. For example, you can either increase the priority in one of the secondaries, or decrease the priority in the primary.
The override setting and device priority values are not synchronized to all cluster members. You must enable override and adjust device priority manually and separately for each cluster member.
It monitors the cluster by sending hello signals and listening for replies, to determine if each other FortiGate is alive and available. It also synchronizes its routing table and part of its configuration to the other devices.
You can optionally configure the primary FortiGate to synchronize some traffic session information to all the secondary devices. This allows a faster and seamless failover for some sessions. Some customers will not need to reestablish their sessions after a failure of a primary FortiGate. We will discuss which session information can be synchronized later in the lesson.
In active-active mode only, a primary FortiGate also distributes traffic among all the available devices in the cluster.
If the mode is active-passive, the secondaries will simply wait, receiving synchronization data but not actually processing any traffic. If the primary FortiGate fails, the secondaries will elect a new primary.
In active-active mode, the secondaries don't wait passively. They process all traffic assigned to them by the primary device.
You don't need to configure them. FGCP will automatically negotiate the heartbeat IP addresses based on each device's serial number. The IP address 169.254.0.1 is assigned to the device with the highest serial number. The IP address 169.254.0.2 is assigned to the device with the second highest serial number, and so on. The IP address assignment does not change when a failover happens. Regardless of the device role at any time (primary or secondary), its heartbeat virtual IP address remains the same.
A change in the heartbeat IP addresses might happen, when a FortiGate device joins or leaves the cluster. In those cases, the cluster renegotiates the heartbeat IP address assignment, this time taking into account the serial number of any new device, or removing the serial number of any device that left the cluster.
There are a few items that need to be considered when connecting heartbeat interfaces and configuring interface monitoring:
• Heartbeat ports contain sensitive information about cluster configuration and require a fair amount of bandwidth to make sure cluster configurations are in a synchronized state at all times. You must have atleast one port for the heartbeat traffic, preferably two.
Note: Heartbeat communication can be enabled for physical interfaces, but not for VLAN subinterfaces, IPsec VPN interfaces, redundant interfaces, 802.3ad aggregate interfaces, or FortiGate switch ports.
• You should configure interface monitoring only for those ports whose failure should trigger a device failover (for example, high-priority traffic ports). You should not configure port monitoring for dedicated heartbeat ports.
To prepare for a failover, an HA cluster keeps its configurations in sync. Let's take a look at that now.
When a new FortiGate is added to the cluster, the primary FortiGate compares its configuration checksum with the new secondary FortiGate configuration checksum. If the checksums don't match, the primary FortiGate uploads its complete configuration to the secondary FortiGate.
After the initial synchronization is complete, the primary will send any further configuration changes done by an administrator to all the secondaries. For example, if you create a firewall address object, the primary doesn't resend its complete configuration, it sends just the new object.
HA propagates more than just configuration details. Some runtime data, such as DHCP leases and routing tables, are also synchronized.
By default, the cluster checks every 60 seconds to ensure that all devices are synchronized. If any secondary is out of sync, the checksum of secondary devices is then checked every 15 seconds. If checksums don't match for five consecutives checks, a complete re-synchronization is done.
Not all the configuration settings are synchronized. There are a few that are not, such as:
• The system interface settings of the HA reserved management interface and the HA default route for the reserved management interface • HA override • HA device priority • The virtual cluster priority • The FortiGate host name • The HA priority setting for a ping server (or dead gateway detection) configuration
The primary FortiGate synchronizes all other configuration settings, including other configurations related to HA settings.
Session synchronization enables seamless failover for some traffic. The information of some sessions is synchronized, so when the primary fails, the new primary can take over those sessions where they were left and keep them open. Traffic might be interrupted for a few seconds, but the network applications don't need to reconnect the sessions again.
By default, once session synchronization is enabled, the device synchronizes TCP and IPsec VPN sessions that comply with one requirement: they are not handled by a UTM proxy, such as antivirus or web filtering.
You can optionally enable the synchronization of UDP and ICMP sessions. Although both protocols are session-less, entries are created in the FortiGate session table for each UDP and ICMP traffic flow. Usually, this synchronization is not required, because most of the network applications based on UDP or ICMP are able to keep the communication even when their session information is lost.
When a primary joins an HA cluster, each interface is given a virtual MAC address.
Through the heartbeats, the primary informs all secondaries about the assigned virtual MAC address.
Upon failover, a secondary adopts the same virtual MAC addresses for the equivalent interfaces.
The new primary broadcasts gratuitous ARP packets, notifying the network that each virtual MAC address is now reachable through a different switch port.
As already explained, if a primary fails, a new primary is elected. But what happens if a secondary FortiGate device fails? It depends on the HA mode.
In an active-passive cluster, the primary only updates its list of available secondary FortiGates. It also starts monitoring for the failed secondary, waiting for it to come online again.
In an active-active cluster though, all secondaries are handling traffic. So the primary (which tracks and assigns sessions to each secondary) must not only update its list of available secondary FortiGates, but it must also reassign sessions from the failed FortiGate device to a different secondary FortiGate.
The most common types of failovers are device failovers and link failovers.
A device failover is basically triggered when the primary FortiGate stops sending heartbeat traffic. When this happens, the secondaries renegotiate a new primary.
A link failover occurs when the link status of a monitored interface on the primary FortiGate goes down. You can configure an HA cluster to monitor the link status of some interfaces. If a monitored interface on the primary FortiGate is unplugged, or its link status goes down, a new primary FortiGate is elected.
There are multiple events that might trigger an HA failover, such as hardware or software failure in the primary FortiGate or an issue in one of the primary's interfaces. When a failover occurs, an event log is generated. Optionally, the device can also generate a SNMP trap and an alert email.
This is how the workload is distributed between roles, depending on the HA mode.
Notice that traffic workload is not distributed in active-passive mode, but it is in active-active mode.
First, the client side sends a SYN packet. It's always forwarded to the primary FortiGate using the internal interface's virtual MAC address as the destination. (click)
If the primary decides that the session is going to be inspected by a secondary, the primary forwards the SYN packet to the secondary that will do the inspections. In this example, the destination MAC address is the physical MAC address of the secondary FortiGate. (click)
The secondary responds with SYN/ACK to the client, and starts the connection with the server by directly sending a SYN packet.
Next, the client acknowledges the ACK. It's forwarded again to the primary using the virtual MAC address as the destination. (click)
The primary device forwards the packet to the secondary inspecting that session, using the secondary's physical MAC address.
When the server responds to the TCP SYN, again, the packet is sent to the primary using the external interface's virtual MAC address. (click)
The idea is not to load balance bandwidth. The traffic is always sent to the primary first. The main objective is to share CPU and memory among multiple FortiGates for traffic inspection.
So far, we've discussed HA clustering where each FortiGate device acts as a whole security domain.
But, if you have an HA cluster with multiple VDOMs, you can configure virtual clusters.
Virtual clusters allow you to have one device acting as the primary for one VDOM and as the secondary for a different VDOM. Each VDOM has a primary and a secondary FortiGate, and any device can act as the primary for some VDOMs, and as the secondary for the other VDOMs at the same time. Virtual clustering can be configured only in a cluster operating in the active-passive mode. Because traffic from different VDOMs can go to different primary FortiGates, you can use virtual clustering to manually distribute your traffic between the two cluster devices, and allow the failover mechanism for each VDOM between two FortiGates.
Note: You can configure virtual clustering between only two FortiGate devices with multiple VDOMs.
At the beginning of this lesson, we showed a simple HA topology. Now, let's look at a more robust topology. It is called full mesh HA.
The idea is to prevent any single point of failure, not only in the FortiGate devices, but also in the network switches and interfaces.
As you can see in the slide, you have two FortiGates for redundancy and each FortiGate is connected to two redundant switches, using two different interfaces.
A full mesh HA is more complicated to assemble and administer, but it can provide the availability required by critical installations. This solution is only available with higher-end FortiGate models because not all FortiGate models are capable of creating aggregated or redundant interfaces, which are required for building this type of topology.
As with a standalone device, when upgrading an HA cluster, each updating FortiGate device must reboot. As the uninterruptable upgrade is enabled by default, the cluster upgrades the secondary FortiGates first. Once all the secondary FortiGates are running the new firmware, a new primary is elected and the firmware in the original primary device is upgraded.
If the cluster is operating in active-active mode, traffic load balancing is temporally disabled while all devices are upgrading their firmware.
You can change the firmware upgrade process by disabling uninterruptable upgrade from the CLI under config system ha. This will result in all FortiGates in a cluster being upgraded at the same time. This takes less time, but interrupts the traffic flow.
If the HA cluster has formed successfully, the GUI displays all the FortiGates in the cluster, together with their hostnames, serial numbers, roles, and priorities.
You can also view the HA statistics, which shows the uptime, active sessions, and network utilization.
You can also disconnect a cluster member from the cluster and edit the HA configurations.
You can get more information about the status of the HA from the CLI. For example, the command diagnose sys ha status displays heartbeat traffic statistics, as well as the serial number and HA priority of each FortiGate. This command also shows the heartbeat interface IP address automatically assigned to the FortiGate with the highest serial number.
Remember, the heartbeat IP address assignment changes only when a FortiGate leaves or joins the cluster.
When troubleshooting a problem in an HA cluster, it is useful to know that you can connect to the CLI of any secondary FortiGate from the CLI of the primary FortiGate. You have to use the command execute ha manage with the secondary HA index for that purpose.
To get the list of secondary FortiGates with their HA indexes, you can use the question mark at the end of that same command.
If you want to be able to connect to each device directly, you can reserve an interface for HA management, so its configuration will not be synchronized, and each device can have different management IP addresses. The HA reserved management interface can also be used by each device to send SNMP traffic and logs independently.
Another indication of the health of an HA cluster is the status of the configuration synchronization. The diagnose sys ha checksum command tree provides many options to check or recalculate the HA checksum.
To check that all the secondary configurations are synchronized with the primary configuration: • Execute the diagnose sys ha checksum cluster command to view the checksums of all cluster members from any FortiGate in a cluster. • The diagnose sys ha checksum show command shows the checksum of the individual FortiGate from which this command is executed. • You can also run the diagnose sys ha checksum recalculate command from any cluster member to recalculate the HA checksums.
If a secondary FortiGate displays exactly the same sequence of numbers as the primary, its configuration is well synchronized with the primary FortiGate in the cluster. In this example, the diagnose sys ha checksum cluster command is executed to view the checksums of all cluster members. • global represents the checksum of the global configuration, such as administrators, admin profiles, global logging settings, and FortiGuard settings, to name a few. • root is the checksum for the root VDOM. If you have configured multiple VDOMs, you will see checksums of all configured VDOMs. • all is the checksum of the global configuration, plus all the VDOMs checksums.
In this lesson, we will show how to set up IPsec VPN topologies, such as partial mesh and full mesh – in other words, complex point-to-multipoint VPNs.
Although we'll quickly review it, you should already be familiar with site-to-site VPNs. Site-to-site VPNs are taught in the FortiGate I: Basic IPsec VPN lesson. This lesson also assumes you are familiar with:
After completing this lesson, you should have the practical skills that you need to deploy the right VPN topology for your needs, increase availability, and troubleshoot tunnels.
Unlike a simple static VPN – such as between two offices – VPNs between multiple dynamic peers require additional considerations.
As we saw in the lesson for basic IPsec VPNs, IPsec is a suite of protocols for authenticating and encrypting the traffic between two peers. The three most used protocols in the suite are:
• Internet Key Exchange (IKE), which does the handshake, tunnel maintenance, and disconnection • Encapsulation Security Payload (ESP), which ensures data integrity and encryption • Authentication Header (AH), which offers only data integrity – not encryption
FortiGate uses only ESP to transport the packet payload. AH is not used by FortiGate.
Since we'll expand first on IKE, let's review a little about the key exchange, which uses port UDP 500 (and, if NAT-T is enabled in a NAT scenario, UDP port 4500).
IKE establishes an IPsec VPN tunnel. FortiGate uses it to negotiate with the peer and determine the security association (SA). The SA defines the authentication, keys, and settings that will be used to encrypt and decrypt that peer's packets. It is based on the Internet Security Association and Key Management Protocol (ISAKMP).
As explained in the basic IPsec VPN lesson, IKE defines two phases. Each IPsec SA negotiated during the phase 2 is direction-specific. So in two-way traffic, there are two SAs per phase 2.
For phase 1, there are two possible negotiation modes: main mode and aggressive mode. Phase 2 only has quick mode. Main mode and aggressive mode have different considerations with dialup VPNs. So, let's examine the differences between main mode and aggressive mode.
First, the client initiates by proposing that the tunnel will use one or more security policies. The responder selects which security policy it agrees to use, and replies. Then, the initiator sends its key. The responder replies with its own key. Finally, the initiator sends its peer ID and hash payload, and the responder replies in the same way. (click)
In this case, the responder can identify the initiator only by the source IP address of the first packet. Nothing else. This is because the first packet does not contain the peer ID. That works well for point- to-point VPNs because the responder knows the IP address of each peer. So, the responder is aware of which security policies to propose for each case. It's also OK for a responder with only one dialup VPN. In that case, the responder does not need to identify the peer. There is only one set of security policies to use for all of them.
However, it is a problem for a responder with multiple dialup VPNs. If that case, the responder needs to identify the initiator with something different than the source IP address, as the peer IP addresses are unknown and can change. Without that information the responder does not know which dialup VPN each initiator belongs to, nor which security policies apply.
In comparison, let's show aggressive mode negotiation. Only 3 packets are exchanged:
First, the client initiates by suggesting a security policy, and providing its key and peer ID. The responder replies with the same information, plus a hash. Finally, the initiator sends its hash payload. (click)
Unlike main mode, the first packet contains the initiator's peer ID. Therefore, the responder can use this ID (and not only the source IP address) to identify who the peer is, and which security policy to use. This is the solution for responders with multiple dialup VPNs. But, because the peer ID is exposed in the initial, unsecured exchange, attackers could see it and use it to try a fraudulent connection. So, it's safer to pair this mode with extended authentication (xAuth).
Phase 1 supports two types of authentication: pre-shared keys and digital certificates. The XAuth extension to IPsec forces remote users to additionally authenticate with their credentials (user name and password). So, additional authentication packets are exchanged if you enable it.
There are two ways of configuring the list of users authorized to connect to the VPN. One is by selecting a specific user group that contains those users. With this method, you need to configure more than one dialup VPN if you want to apply different access policies, depending on the user group. As we saw before, that also means using aggressive mode and peer IDs.
The other way of configuring the list of authorized VPN users is by selecting the option Inherit from policy. With this setting, FortiGate authorizes all users that belong to any user group assigned to any of the firewall policies that allow the VPN traffic. In this example, there are two firewall policies for the VPN traffic. One allows the traffic from the user group Administrator. The other policy allows the traffic from the user group training. In this case, all users that belong to either Administrator or training can connect to the VPN.
The advantage of this method is that you can have different access policies for different user groups and keep only one dialup VPN in the configuration.
Let's talk about types of IPsec remote peers and VPN topologies.
When configuring a phase 1, we must specify the type of remote peer. There are three types:
• Static IP Address is used when the peer's IP address is known and will not change • Dynamic DNS is used when the peer's IP address is dynamic, but FortiGate can resolve it through a DNS query. This makes it – in effect – a static peer. For example, branch offices often use DHCP from an ISP. The IP address changes, but not often. So you could use Dynamic DNS to get a static DNS name that resolves to the dynamic IP. Then you would configure your FortiGate with the peer's DNS domain name, which your FortiGate will query to resolve whenever it needs to connect. • Dialup is used when the peer's IP address is dynamic, and there is no dynamic DNS. This is often true for branch offices and mobile VPN clients. As a peer with a dialup VPN does not know the other peers' IP addresses, it cannot initiate a VPN connection request.
Let's study the different topologies for VPN networks. There are five types:
• Point-to-point • Dialup • Hub-and-spoke • Full mesh • Partial mesh
Point-to-point VPNs are the simplest. Two peers communicate directly. This topology, and how to configure it, was covered in the FortiGate I: Basic IPsec VPN lesson. Now, let's look at the other four topologies.
First, let's look at a dialup VPN. It is used when you don't know where the remote peer will be connecting from, such as with travelling employees with FortiClient on their laptops.
Unlike site-to-site VPNs, one dialup VPN configuration on your FortiGate can be used for multiple IPsec tunnels from many remote offices or users; hence its other name, point-to-multipoint. (click)
Remember that, in dialup, the client's IP is dynamic, so FortiGate can't predict where it will be. That means that FortiGate cannot initiate the VPN, only the remote peer can.
One point-to-multipoint topology variation is called hub-and-spoke. Its name describes how all clients connect through a central hub, similar to how spokes connect to hubs on wheels.
In this example, the clients – spokes – are each branch office FortiGates. For any branch office to reach another, its traffic must pass through the hub.
An advantage of this topology is that the VPN configuration and firewall policies are easily managed. System requirements are also minimal for the branch office FortiGates, since each only needs to maintain one tunnel– two SAs. In this example, four tunnels – eight SAs – are required in the hub.
A disadvantage is that – especially if headquarters (HQ) is physically distant like it can be for global companies – communications between branch offices through HQ will be slower than with a direct connection. If your HQ is in Brazil and you have offices in Japan and Germany, latency can be very significant. For example, if the FortiGate at HQ fails, VPN failure will be company-wide. Also, the FortiGate at HQ must be much more powerful. It handles four tunnels simultaneously – eight SAs.
So what would a topology look like if some, or all, branch offices could bypass HQ, and connect directly to each other?
Full mesh connects every location to every other. Like the previous hub-and-spoke example, there are only five locations here. But to fully interconnect, every FortiGate requires four VPN tunnels – eight SAs – to the others. This is three more tunnels per spoke FortiGate. In total, 20 tunnels are required. If you expand to six locations, it would require 30 VPNs, seven locations would need 42, and so on.
This topology causes less latency and requires much less HQ bandwidth than hub-and-spoke. Its disadvantage? Every spoke FortiGate must be more powerful. (click)
Partial mesh attempts to compromise, minimizing required resources but also latency. Partial mesh can be appropriate if communication is not required between every location. However, each FortiGate's configuration is still more complex than hub-and-spoke. Routing especially may require extensive planning.
So generally, the more locations you have, hub-and-spoke will be cheaper (but slower) than a meshed topology. Mesh will place less strain on the central location, and be more fault-tolerant (but more expensive).
To review, here is a quick comparison. You should choose the topology that is most appropriate to your situation.
Auto discovery VPN (ADVPN) is a FortiGate feature that achieves the benefits of a full-meshed topology with the easier-to-configure and scalability benefits of the hub-and-spoke and partial-mesh topologies.
First, you add to the FortiGates the VPN configurations for building either a hub-and-spoke or a partial-mesh topology. After that, you enable ADVPN on the VPNs. ADVPN will dynamically negotiate tunnels between spokes (without having them pre-configured) to get the benefits of a full-mesh topology.
ADVPN requires the use of a dynamic routing protocol running over the IPsec tunnels, so that spokes can learn the routes to other spokes after the dynamic VPNs negotiate.
This is an example of how ADVPN works. An administrator configures IPsec VPNs in multiple FortiGate devices to form a VPN partial-mesh topology. There are two hubs. Hub 1 has three spokes. Hub 2 has two spokes.
The administrator also enables ADVPN in all the VPNs. To do that, you must enable the following IPsec phase 1 settings: • auto-discovery-receiver in the spokes' VPNs • auto-discovery-sender and auto-discovery-psk in the hubs' VPNs that go to each spoke • auto-discovery-forwarded in the hubs' VPNs that go to each other hub
The dynamic tunnels between spokes are created on demand. Let's say that a user in Boston sends traffic to London. Initially, the direct tunnel between Boston and London has not been negotiated yet. So, the first packets from Boston to London are routed through the hubs 1 and 2. When Hub 1 receives those packets, it notices that ADVPN is enabled in all the VPNs all the way to London. So, Hub 1 sends an IKE message to Boston informing that it can try to negotiate a direct connection to London. On receipt of this IKE message, Boston creates a FortiOS-specific IKE information message which contains its public IP address, its local subnet, the desired destination subnet (London's subnet), and an auto-generated PSK to use for securing the direct tunnel (alternatively digital certificate authentication can be used instead). This IKE message is sent to London through hubs 1 and 2. When London receives the IKE message from Boston, it stores the PSK and replies back with another IKE information message that contains London's public IP address. After the reply arrives to Boston, the dynamic tunnel is negotiated between both peers. The negotiation will succeed because London is expecting a connection attempt from Boston's public IP address.
We covered how to configure point-to-point VPNs in the Basic IPsec VPN lesson. This lesson covers dialup VPN configuration.
Before, we said that hub-and-spoke, full mesh, and partial mesh can be built using a combination of point-to-point (site-to-site) and point-to-multipoint VPNs. So let's configure point-to-multipoint, called Dialup VPN on the GUI.
Notice that the steps are the same. What is different? The settings. We must configure:
1. A phase 1 2. At least one phase 2 3. Firewall policies 4. If required, static routes or a dynamic routing protocol
Remember, there are two different ways of configuring VPNs on FortiGate: policy-based and route- based.
• For policy-based VPNs, additional routing entries are usually not required. Also firewall policies for policy-based VPNs are applied directionally. So, one policy is enough to allow the traffic initiated at either end. • For route-based VPNs, routing entries are required, and at least two firewall policies are needed to allow the traffic initiated at either side.
Let's start by configuring the phase 1 for the hub in a hub-and-spoke topology.
If the hub contains multiple dialup VPNs, Aggressive Mode and the use of peer IDs is required. (click)
To strengthen authentication, you can enable XAuth. The hub FortiGate will use the Enable as Server setting. (Each FortiClient or spoke FortiGate will use Enable as Client.)
Additionally, NAT Traversal should be enabled if your spokes are mobile dialup users, because they are usually behind NAT at airport terminals, home routers, and hotel firewalls.
If your spokes are mobile users, such as FortiClient users, you will probably enable and configure Mode Config on the hub's phase 1. This is for an IPsec extension called IKE mode configuration.
Why? It's usually not practical to allocate static IPs to each laptop and mobile phone. IKE mode configuration is an alternative.
Like DHCP for VPNs, Mode Config automatically configures the client's network settings. Like with DHCP, you define a range for the pool of VPN virtual IPs and the DNS settings.
First, specify whether the hub for this spoke is using a Static IP or Dynamic DNS. (click)
If the hub has multiple dialup VPNs, you must set the Mode to Aggressive. Then, in the Local ID, you must enter the name that this spoke will use to identify itself to the hub. This ID must match the one configured on the hub. (click)
If you enable XAuth on the hub, you must enable XAuth on the spoke, too, and configure the user name and password.
Usually the local (source) quick mode selector in the hub is set either to 0.0.0.0/0 or to the hub's subnet. The remote (destination) quick mode selector in the hub is usually set to 0.0.0.0/0 to match all spoke subnets.
In the case of the quick mode selectors in the spoke, the local address must be the spoke's subnet. For route-based VPNs, the hub will dynamically add a static route to this subnet, immediately after the VPN is established. (That way, you don't need to manually configure the hub FortiGate with all static routes for each spoke.)
The remote quick mode selector in the spoke is usually the hub's subnet. In this case, a static route to the hub's subnet is not dynamically added in the spoke when the tunnel comes up. This route must be added to the configuration.
Note that unlike with point-to-point VPNs, quick mode selectors for point-to-multipoint do not need to mirror each other.
If your clients are FortiClient, there's a simpler alternative to configure the hub. Use the VPN wizard. It will use route-based and enable IKE Mode Config, XAuth, and other appropriate settings.
You can create more than one VPN between two sites, for traffic sharing and/or redundancy purposes. Let's examine how to do it.
We mentioned briefly that hub-and-spoke is inherently not fault-tolerant: if something fails, then all VPN tunnels might go down. How can you make your hub-and-spoke or point-to-point VPN more resilient?
Provide a second ISP connection to your hub, and configure two route-based VPNs. If the primary VPN fails, another tunnel can be used instead.
• Partially redundant – On one peer (usually the hub, where a backup ISP is available if the main ISP is down), each VPN terminates on different physical ports. That way FortiGate can use an alternative VPN. But on the other peer, both VPNs terminate on the same physical port – so the spoke is not fault-tolerant. • Fully-redundant – Both peers terminate their VPNs on different physical ports. So they are both fault-tolerant.
First, create one route-based phase 1 for each path – one phase 1 for the primary VPN, and one for the backup. Enable dead peer detection (DPD). DPD is a method for IPsec gateways to detect when the VPN tunnel to its peer is down. (click)
Then, because these are route-based VPNs, you must add at least one static route for each VPN. Routes for the primary VPN must have a smaller distance (or smaller priority) than the backup. This causes FortiGate to use the primary VPN while it's available. If the primary VPN fails, then FortiGate automatically uses the backup route. Alternatively, we could use a dynamic routing protocol, such as OSPF or BGP. (click)
Finally, configure firewall policies to allow traffic through both the primary and the backup VPNs.
What do you do if, after creating a tunnel, it does not come up? Let's take a look at that in this section.
As you can see, IPsec VPN configuration can be complex. What is the best way to solve problems?
When troubleshooting a tunnel that does not negotiate, look for setting mismatches first. Most connection failures are due to misconfiguration.
If you do not see any configuration mismatch, run the IKE real-time debug. Its output is extensive as it shows the phase 1 and 2 negotiations step-by-step. If the negotiation fails, the IKE real-time debug shows messages that can guide you toward the problem resolution.
To enable the IKE real-time debug, first create a filter with the command diagnose vpn ike log- filter dst-addr4 and the IPsec peer's public IP address.
Then enable the debug with the commands diagnose debug application ike -1 and diagnose debug enable.
Try to bring the tunnel while the debug is running and capture all the output.
After that, remember to stop the debug with the commands diagnose debug reset and diagnose debug disable. It is not recommended to keep a real-time debug running on the background of a FortiGate for a long time.
This shows some output for a successful phase 1 negotiation using main mode.
The first line shows the arrival of an IPsec packet from the IP address 172.20.187.114. The third line indicates that the peer is using main mode.
A bit later, the debug shows that FortiGate accepted the SA proposal from the remote peer. It displays the name of the phase 1 that matches the proposal. In this case, it's the name Remote.
FortiGate replies to the first main mode packet. Then, the second main mode packet arrives.
FortiGate replies again, and the third main mode packet is received.
After finishing the negotiation, the output displays messages that indicate that the key exchange was successful, and the IKE SA was established.
Let's see what is displayed during the phase 2 negotiation. Again, the output is much longer than this. The slide only shows a sample of some parts of that output.
The first line announces the arrival of the first quick mode packet.
The second line shows the quick mode selector proposed by the remote peer. In this case, it's 0.0.0.0/0 for both the source and destination.
Some lines below, the debug displays the quick mode selector that was successfully negotiated between both peers.
The last two lines finally show that the tunnel is up and the IPsec SAs are established.
If there were any problem in the negotiation of either the phase 1 or 2, the output would show an error message.
We explained the differences between main mode and aggressive mode. We also covered extended authentication, VPN topologies, ADVPN, dialup VPNs, and redundant VPNs. Finally, we provided some troubleshooting tips.
In this lesson, you will learn how to use FortiGate to protect your network against intrusion and denial of service attacks.
After completing this lesson, you should have the practical skills required to detect and block known attacks and network anomalies using IPS, denial of service (DoS) policies, and web application firewall profiles.
Before we begin, it's important to understand the difference between an anomaly and an exploit. It's also important to know which FortiGate features offer protection against each of these two types of threats.
Exploits are known attacks, with known patterns that can be matched by IPS, web application firewall, or antivirus signatures.
Anomalies are unusual behaviors in the network, such as higher-than-usual CPU usage or network traffic. Anomalies must be detected and monitored (and, in some cases, blocked or mitigated) because they can be the symptoms of a new, never-seen-before attack. Anomalies are usually better detected by behavioral analysis, such as rate-based IPS signatures, DoS policies, and protocol constrains inspection.
Exploits of unknown vulnerabilities – called zero-day attacks – are sold for large amounts of money on the black market. Since these exploits aren't known to their vendors, or to security experts, there's no available patch or signature for detection. That's what makes them so dangerous.
Some companies and organizations, like Facebook and Google, have offered bounties for the responsible disclosure of these exploits, but there's a very profitable market for black hat hackers to sell these discoveries to everyone from covert government surveillance to organized crime syndicates.
If you detect a zero-day attack, your initial instinct may be to take the server offline immediately, then format it to remove all traces of malware. But by doing this, you'll alert the attacker, and destroy forensic evidence. This will only educate motivated attackers – their next attack will be harder to detect, and more sophisticated. Make sure your PSIRT team understands the most appropriate way to respond to each different type of intrusion.
Now we'll talk about the FortiGate features that protect your network against anomalies and exploits. Let's start with intrusion prevention system (IPS).
IPS uses signature databases to detect known attacks. IPS signatures can also be used to detect network errors and anomalies.
Like the AV signature databases, the IPS signature databases are also updated through FortiGuard.
The IPS engine is responsible for most of the features shown in this lesson: intrusion protection, protocol decoders, and more. It's also responsible for application control, flow-based antivirus protection, web filtering, email filtering, and DLP.
How does the IPS engine determine if a packet contains an attack or anomaly?
Protocol decoders parse each packet according to the protocol specifications. Some protocol decoders require a port number specification (configured in the CLI), but usually, the protocol is automatically detected. If the traffic doesn't conform to the specification – if, for example, it sends malformed or invalid commands to your servers – then the protocol decoder detects the error.
A default, initial set of IPS signatures is included in each FortiGate firmware release. FortiGuard IPS service updates the IPS signatures, sometimes daily, with new signatures. That way, IPS remains effective against new exploits. Unless a protocol specification or RFC changes (which is not very often), protocol decoders are rarely updated. The IPS engine itself changes more frequently, but still not often.
What part of IPS is updated most often? The IPS signatures. New signatures are identified and built by FortiGuard research teams, just like antivirus signatures. So, if your FortiGuard Services contract expires, you can still use IPS. However, just like with anti-virus scans, IPS scans will become increasingly ineffective the longer your signatures go without being updated – old signatures won't defend against new attacks.
The regular signature database contains signatures for common attacks whose signatures cause rare or no false positives. It's a smaller database, and its default action is to block the detected attack.
The extended signature database contains additional signatures for attacks that:
In fact, due to its size, the extended database is not available for FortiGate models with a smaller disk or RAM. But, for high security networks, you may be required to enable the extended signatures database.
When your FortiGate downloads a FortiGuard IPS package, new signatures might appear in the signature list. When configuring your FortiGate, you can change the Action setting for each sensor that uses a signature.
• Your software vendor releases a security patch. Continuing to scan for exploits will waste FortiGate resources. • Your network has a custom application with traffic that inadvertently triggers an IPS signature. You can disable the setting until you notify Fortinet so that FortiGuard can modify the signature to avoid false positives.
The severity level of each signature is also listed in the list of IPS signatures. What do the severity indicators mean?
The FortiGuard severity level is based on the CVSS 2 rating system. There are many contributing factors. For details, go to the first.org website.
Fortinet always marks remote code execution as high or critical severity, regardless of the CVSS rating. Details are explained on the FortiGuard website.
If you're not sure if you should enable an IPS signature on your FortiGate, you can search the encyclopedia on the FortiGuard website.
The encyclopedia contains useful information, such as affected systems and recommended corrective actions. So if you don't use that protocol or don't have a vulnerable system, you can safely disable the corresponding signature. But if you are vulnerable, the encyclopedia can provide information about how to protect yourself.
The FortiGuard encyclopedia only contains publicly disclosed vulnerabilities. It does not contain vulnerabilities that can't yet be responsibly disclosed, regardless of the reason.
In addition to using the FortiGuard predefined signatures, you can also create your own custom signatures. Before writing a custom signature, you should use packet capture to record packet samples. You can use packet samples to help you understand and avoid mismatches with normal packets on your network.
Remember, Fortinet does not provide support for problems created by misconfigured custom signatures. So, if possible, you should test your custom signatures in a lab.
After that, protocol-specific keywords define what part of the packet to search for a match, and what values comprise a match. Usually, a keyword is followed by a corresponding value that represents its setting, except for a few standalone keywords, such as --no_case. Each keyword-value pair ends with a semi-colon and a space. You can include multiple key-value pairs in a signature. The signature ends with a closing parenthesis.
A reference to syntax for custom IPS signatures can be found on the Fortinet documentation site. Supported keywords vary by the protocol decoders. For example, the SMTP protocol supports the VRFY command, and so there is a protocol decoder flag for it.
In this example, the first sample custom signature is called Ping.Death. It searches for ICMP traffic that exceeds about 32 KB.
The next sample custom signature is called Block.HTTP.POST. It searches for the pattern POST in a specific location inside the packet. In normal HTTP POST requests, the method should be in this specific location. Using a specific location in the signature prevents IPS from scanning the entire HTTP payload, which could contain a web page that accidentally matches the pattern (for example, the words POSTAL CODE). Your signature should be specific, but not too specific – extra comparisons reduce performance.
Once you have created your custom signature, pair it with an action within an IPS sensor, then reference that IPS sensor in a firewall policy.
The steps for configuring IPS sensors are the same, regardless of whether you want to use custom signatures or predefined signatures. A single IPS sensor can combine multiple predefined and custom signatures.
There are two ways of adding predefined signatures to an IPS sensor. One way is to select the signatures individually. When you use this method you can create an exemption list based on the source or destination IP address. Once a signature has been selected from the list, it is added to the sensor with its default action. After that, you can right-click the signature and change the action.
The second way to add a signature to a sensor is by using filters. FortiGate will add all the signatures that match the filters.
In this example we've created a filter to include all the signatures that protect Apache severs running over a Linux OS. The action is set to block all traffic that matches those signatures.
Each individual signature can include multiple tags, such as HTTP, Microsoft, IIS, and TCP. The more specific you can make your filter, the less resources will be used to scan your traffic. This is because the signature's parts will seldom match the traffic, so the IPS engine can quickly continue with the next comparison or scan.
If the signature that matches the traffic is both in the IPS Signature list and the IPS Filter list, the FortiGate applies the action specified in the former one.
Rate based signatures (previously called anomalies) block specific traffic when one of the thresholds is exceeded during the configured time period. Rate based signatures should be applied only to protocols you actually use. Then block malicious clients for extended periods. This saves system resources and can discourage a repeat attack: FortiGate will not track statistics for that client while it is temporarily blacklisted.
To apply an IPS sensor, you must enable IPS and then select the sensor in a firewall policy.
Let's talk about denial of service (DoS) attacks and DoS policies.
So far we've shown signatures that match illegal commands and invalid protocol implementations. Those are easy to confirm as an attack.
What about attacks that function by exploiting asymmetric processing, or bandwidth between clients and servers? There are many ways to make a DoS attack. For example, some DoS attacks exhaust limited server-side bandwidth or sockets. Unless you know what bandwidth is abnormal for your network, you may not be able to confirm an attack.
The goal of a DoS attack is to overwhelm the target – to consume resources until the target can't respond to legitimate traffic. This can be done in various ways. High bandwidth usage is only one type of DoS attack. Many sophisticated DoS attacks, such as Slowloris, don't require high bandwidth.
To block DoS attacks, apply a DoS policy on a FortiGate that sits between attackers and all the resources that you want to protect.
DoS protection can be applied to four protocols: TCP, UDP, ICMP and SCTP. Four different types of anomaly detection can be applied to each protocol:
• A flood sensor detects a high volume of that particular protocol, or signal in the protocol. • A sweep/scan detects attempts to map which of a host's ports respond and therefore may be vulnerable. • Source signatures look for large volumes of traffic originating from a single IP. • Destination signatures look for large volumes of traffic destined for a single IP.
If you do not have an accurate baseline for your network, when you implement DoS for the first time, be careful not to completely block network services. To prevent this, initially configure the DoS policy to log, but not block. Using the logs, you can analyze and determine normal and peak levels for each protocol. Then, adjust the thresholds to comfortably, but not loosely, allow the usual peaks.
Thresholds that are too high can allow your resources to be exhausted before the DoS policies trigger. Thresholds that are too low will cause FortiGate to drop normal traffic.
Now we'll take a look at some common types of DoS attacks. The first is called a SYN flood attack.
In TCP, the client sends a SYN signal to initiate a connection. The server must respond, then remember the start of the connection in RAM while it waits for the client to acknowledge (or ACK). Normal clients will ACK quickly and begin to transmit data. But malicious clients continue to send more SYN packets, half-opening more connections, until the server's table is full. Once the server's table is full, it can't accept more connections and begins to ignore all new clients.
To defend against this type of attack, FortiGate acts as a pseudo-proxy. It waits until the client has finished connection build-up to form the back-end connection. If the connection build-up doesn't complete quickly, FortiGate begins to drop the attacker's connection requests from the table.
Another type of anomaly, or attack, is an ICMP sweep. ICMP is used during troubleshooting: devices respond with success or error messages. But attackers can use ICMP to probe the network for valid routes and responsive hosts.
By doing an ICMP sweep, the attacker can gain information about your network before crafting more serious exploits.
An individual DoS attack is a flood of traffic coming from a single address. It can originate from the Internet, or even from your internal network. Typically, a single device makes many connections or sessions, and possibly uses much bandwidth to a connect to a single location.
All four protocols in the DoS profile (ICMP, TCP, UDP, SCTP) have an anomaly sensor for the source. These are built to examine the traffic that each IP is generating and compare that traffic to the threshold value.
A variation of this is the distributed denial of service attack or DDoS. It has many of the same characteristics as a single DoS attack, but the main difference is that multiple devices are all attacking one destination at the same time.
Some FortiGate features are meant to protect clients, not servers. For example, FortiGuard web filtering blocks requests based on the category of the server's web pages. Antivirus prevents clients from accidentally downloading spyware and worms. Neither protect an innocent server (which doesn't send requests – it receives them) from script kiddies or SQL injections.
Protecting web servers requires a different approach because they are subject to other kinds of attacks.
Let's look at some examples of attacks that specifically target web applications.
One type of attack is called cross-site scripting (XSS). If a web application doesn't sanitize its inputs and reject JavaScript, it ends up storing the XSS attack in its database. Then, when other clients request the page that re-uses that data, the JavaScript is now embedded in the page.
JavaScript can do many things with a page, including rewriting the whole page and making its own requests. This is the basic mechanism of AJAX apps. In this case, XSS causes innocent clients to transmit to a different server that is controlled by the attacker. This could, for example, transmit credit card information or passwords from an HTTP form to the attacker.
Another very common web attack is a SQL injection. Just like an XSS attack, the root cause of a SQL injection is that the web application does not sanitize input. If the attacker enters a SQL query into an input such as an HTML form, the web app simply accepts it, and passes it along to the database engine, which accidentally runs the query.
The SQL language can do anything to the data. It can, for example, download the table of users so that the attacker can run a password cracker. A query could add new entries for new administrator logins, or modify logins, blocking administrators from logging.
One component of a web application firewall profile is the WAF signatures. WAF signatures work in the same way as IPS signatures. FortiGate can take an action over the traffic that matches any of them.
Some WAF signatures are categorized as extended. They are more likely to cause false positives, but are sometimes required in high-security environments.
HTTP constraints can monitor and control the number, type, and length of many HTTP headers, which are also inputs. This prevents unexpected inputs that a malicious client could craft to compromise your server.
The limits can vary by your server's software, but also by its hardware. If a server has limited RAM, for example, then it is potentially easier to overload or crash with an excessive number of headers, since parsing the headers and storing them in buffers requires RAM.
Why do you need it? Doesn't FortiGate include web application firewall protection?
It's true. It does. But, for environments where the protection of the web services is critical, you can complement a FortiGate solution with a FortiWeb device.
FortiWeb offers a more complete HTTP protocol understanding and state attack protection. It can perform vulnerability scans and penetration tests. It can also rewrite the HTTP packets, and route traffic based on the HTTP content.
In most cases, FortiWeb is installed as a standalone device, usually located between FortiGate and the protected web servers. FortiWeb can be installed online (web traffic crossing the device), or offline (device is connected as a one-arm sniffer).
Alternatively, you can configure FortiGate to forward the web traffic to an external FortiWeb, where the WAF inspection happens. This is useful, for example, when you need to protect servers located in multiple sites with one single FortiWeb. In order to do this, you need first to configure each FortiGate with the FortiWeb IP address (authentication is optional). After that, you select External in the WAF profile, to instruct FortiGate to use FortiWeb.
If you've configured a FortiGate with an external FortiWeb IP address, when creating the WAF profile, you have the option to select where the WAF inspection will happen: either in FortiGate itself, or in the external FortiWeb. If you select FortiGate (or if there is no external FortiWeb), you must configure the different signatures and constraints to use. After that, the WAF profile is assigned to one or more firewall policies.
Everything we've shown so far is inline scanning: traffic passes through FortiGate from one interface to another. But, you can also deploy FortiGate outside of the direct path of packets, in a one-arm topology with a monitor-only mechanism. This is also called sniffer mode because it detects but does not block.
To do this, connect FortiGate to a switch's SPAN or mirroring port. The switch will send a duplicate of egressing packets to FortiGate for inspection. Notice that because FortiGate is inspecting a copy – not the original packet – it can't modify or block the connection.
Historically, when IPS scanning was first invented, it was slow. Old IPS could introduce high latency. So, one-arm deployment was common, but IPS on an inline firewall wasn't.
Now, hardware performance is much better, and one-arm sniffer has a significant limitation: cannot block traffic. Because it's on a mirrored port on the switch, not directly in between the attacker and your protected network, FortiGate isn't placed to intervene. So today, most people use one-arm sniffer only during testing or evaluation.
One-arm sniffer is enabled on a FortiGate's physical interface, not on a logical interface, such as a VLAN.
After you select One-Arm Sniffer on an interface, you can choose the security profiles.
In this lesson, you will learn about Fortinet Single Sign-On (FSSO). With this feature, your users don't need to log on each time they access a different network resource.
After completing this lesson, you should have these practical skills to configure the Fortinet SSO feature. This includes:
• Define SSO • Explore the FSSO methods • Detect user login events in Windows Active Directory using FSSO • Configure the Web-Initiated FSSO for NTLM authentication • Configure FortiGate and Collector Agent for FSSO • Basic FSSO troubleshooting
Single Sign-On (SSO) allows users to be automatically logged in to every application after being identified, regardless of the platform, technology, and domain.
Fortinet Single Sign-On (FSSO) software-agent enables FortiGate to identify network users for security policy or VPN access, without asking again for their username and password. When a user logs in to a directory service, the FSSO agent sends FortiGate the user's IP address and the names of the user groups to which the user belongs. FortiGate uses this information to maintain a copy of the domain controller user group database. Because the domain controller authenticates users, the FortiGate device does not perform authentication. It recognizes group members by their IP address.
FSSO is typically used with directory service networks such as Windows Active Directory (AD) or Novell eDirectory.
How you deploy and configure FSSO depends on the server that provides your directory services.
FSSO for Windows AD uses a collector agent. Domain controller (DC) agents may also be required, depending on the collector agent working mode. There are two working modes that monitor user sign- on activities in Windows: DC agent mode and polling mode.
There is another kind of DC agent exclusively for Citrix and Terminal Services environments – TS agents. TS agents require the AD's collector agent to collect and send the log events to FortiGate.
The eDirectory agent is installed on a Novell network to monitor user sign-ons and send the required information to FortiGate. It functions much like the collector agent on a Windows AD domain controller. The agent can obtain information from the Novell eDirectory using either the Novell API or LDAP.
In this section, we'll examine the available modes for Windows Active Directory: DC agent mode and polling. When looking at polling mode, we'll cover both collector-agent based polling mode and agentless polling mode.
Let's start with the DC agent mode, which is considered the standard mode for FSSO.
• One DC agent installed on each Windows domain controller. If you have multiple DCs, this means multiple DC agents. The DC agents monitor and forward user login events to the collector agents. • The collector agent. The collector agent is another FSSO component that's installed on a Windows server. It consolidates events received from the DC agents, then forwards them to FortiGate. The collector agent is responsible for group verification, workstation checks, and FortiGate updates of login records. The FSSO collector agent sends Domain Local Security Group, Organizational Units (OUs), and Global Security Group information to FortiGate devices. It can also be customized for DNS lookups.
Here we show the flow of information between DC agents, the collector agent, and a FortiGate configured for FSSO authentication. (click)
1. When users authenticate with the DC, they provide their credentials. (click)
2. The DC agent sees the login event, and forwards it to the collector agent. (click)
3. The collector agent aggregates all login events, then forwards that information to the FortiGate. The information sent by the collector agent contains the user name, host name, IP address, and user group(s). The collector agent communicates with the FortiGate over TCP port 8000 (default) and it listens on UDP port 8002 (default) for updates from the DC agents. The ports are customizable. (click)
4. Now that the collector agent has forwarded the user login information, the FortiGate knows who the user is, their IP address, and which Active Directory group permissions also apply. When a user tries to access the Internet, FortiGate compares the source IP address to its list of active FSSO users. Because the user in this case has already logged in and the FortiGate already has their information, FortiGate will not request the user to authenticate again.
Now let's look at polling mode. Polling mode can be collector agent-based or agentless.
First, let's look at the collector agent-based polling mode. Like DC agent mode, collector agent-based mode requires a collector agent to be installed on a Windows server, but it doesn't require DC agents to be installed in each DC. In collector agent-based polling mode, the collector agent must be more powerful than the collector agent in DC agent mode, and it will also generate unnecessary traffic when there have been no login events.
In this mode, the collector agent contacts periodically the windows DC to get its information directly.
Let's see an example of FSSO using the collector agent-based polling mode. Again we have a DC, a collector agent, and FortiGate. But the DC doesn't have an agent installed. (click)
2. The collector agent periodically (every few seconds) polls TCP port 445 of each DC directly, to ask if anyone has logged in. (click)
3. The collector agent sends the login information to FortiGate over TCP port 8000. This is the same information that is sent in the DC agent mode. (click)
4. When user traffic arrives at FortiGate, it already knows who is at what IP address, and no repeated authentication is required.
Collector agent-based polling mode has three methods (or options) for collecting login information:
• NetAPI: Polls temporary sessions created on the DC when a user logs in or logs off and calls the NetSessionEnum function on Windows. It's faster than the WinSec and WMI methods; however, it can miss some login events if a DC is under heavy system load. This is because sessions can be quickly created and purged from RAM, before the agent has a chance to poll and notify FortiGate.
• WinSecLog: Polls all the security event logs from the DC. It doesn't miss any login events, because events are not normally deleted from the logs. There can be some delay in FortiGate receiving events if the network is large and, therefore, writing to the logs is slow.
• WMI: A Windows API that gets system information from a Windows server. The DC returns all requested login events. The collector agent is a WMI client and sends WMI queries for user login events to the DC, which, in this case, is a WMI server. The collector agent doesn't need to search security event logs on the DC for user login events; instead, the DC returns all requested login events. This reduces network load between the collector agent and DC.
You can deploy FSSO without installing an agent. FortiGate polls the DCs directly, instead of receiving login information indirectly from a collector agent.
Because FortiGate collects all of the data itself, agentless polling mode requires greater system resources, and it doesn't scale as easily.
Agentless polling mode uses WinSecLog. Because there's no collector agent, the FortiGate uses SMB protocol to read the event viewer logs from DCs.
Also because the FortiGate does all of the polling, you will not have all the extra features, such as workstation checks, that are available with the external collector agent.
Now let's see how the communication flows without agents (There is no collector agent or DC agent). (click)
1. FortiGate polls the DC's TCP port 455 to get user login events. (click)
2. After the user authenticates with DC, FortiGate will register the login event during its next poll, obtaining the following information: the user name, the host name, the IP address, and the user group(s). (click)
3. When the user sends traffic, FortiGate already knows whose traffic it is. Thus, the user does not need to authenticate
This table summarizes the main differences between DC agent mode and polling mode.
DC agent mode is more complex. It requires not only a collector agent, but also a DC agent for each DC. However, it is also more scalable because the work of capturing logins is done by the DC agents who pass their information directly to the collector.
In polling mode, the collector needs to query every domain controller, every few seconds. So, with each DC that is added, the number of queries grows. If you want to add a second collector agent for redundancy in polling mode, both collector agents need to query every DC individually.
In DC agent mode, the DC agent just has to get the log once and send a copy of the necessary information to all the collector agents. In comparison, if you use polling mode, some login events might be missed or delayed, depending on the polling option used.
Regardless of the login collector method you choose, some FSSO requirements for your active directory network are the same:
• Microsoft Windows login events have the workstation name and username, but not the workstation IP address. When the collector agent gets a login event, it will query a DNS server to resolve the IP address of the workstation. So, FSSO requires that you have your own DNS server. If a workstation IP address changes, DNS records must be updated immediately.
• Collectors must have connectivity with all workstations. Because an event log is not generated on logoff, the collector agent (depending on the FSSO mode) must use a different method to verify whether users are still logged in. So, each user workstation is polled to see if users are still there.
In an active directory (AD) environment, FSSO can also work with NT LAN Manager (NTLM), which is a suite of Microsoft security protocols that provides authentication, integrity, and confidentiality to users. Let's take a look at how NTLM works and interacts with FSSO.
NTLM authentication does not require DC agents, but it is not fully invisible to users: they must enter their credentials during NTLM negotiation. NTLM authentication is a Microsoft-proprietary solution, so it can only be implemented in a Windows network.
NTLM is most useful when users log in to DCs that, for some reason, can't be monitored by the collector agent, or when there is a communication problem between the collector agent and one of the DCs' agents. In other words, NTLM authentication is best used as a backup to FSSO.
This example shows how messages flow during NTLM authentication in a simple domain configuration. (click)
1. When both FSSO and NTLM are enabled, NTLM will back up FSSO. When FortiGate receives traffic from an IP address that doesn't exist in the list of active FSSO users, NTLM is triggered. (click)
4. FortiGate receives the user credentials, then authenticates them with the collector agent over TCP port 8000. The FortiGate also receives the names of the groups that the user belongs to. (click)
5. If the credentials are correct, FortiGate authorizes access for the user. New NTLM requests are initiated when the browser is closed or the session is timed out.
Unlike full FSSO, NTLM authentication is not transparent to users. In most browsers, and by default in Internet Explorer, users must enter their credentials whenever the browser receives a NTLM authentication challenge.
However, Internet Explorer can be configured to automatically send the user's credentials each time it receives an NTLM challenge. To do this, in the Internet Options dialog, click Custom level. Then, in the Settings dialog, scroll to User Authentication login and select Automatic login with current user name and password.
In a multiple domain environment for NTLM, it's important to have a trust relationship between the domains. When multiple domains exist in an AD forest, a trust relationship is automatically created, so only one DC agent is required on one of the domain controllers. But, when multiple domains are not in an AD forest, you have two options: • create a trust relationship between the domains through AD settings, or • install one DC agent on each domain, then use security policies to configure server access.
If you decide to install one DC agent on each domain, the DC agents send login information to the collector agent. Let's see how this process flow works. (click)
Now, let's take a look at how to configure FSSO on FortiGate, and how to install the Fortinet collector agent.
If FortiGate is acting as a collector for agentless polling mode, you must select Poll Active Directory Server and configure the IP addresses and AD administrator credentials for each DC.
If you have external collector agents, either using the DC agent mode or the collector agent-based polling mode, you must select Fortinet Single-Sign-On Agent and configure the IP address and password for each collector agent.
The FSSO agents are available on the Fortinet Support website. There you will find the:
• the DC agent, • the collector agent for Microsoft servers: FSSO_Setup, • the collector agent for Novell directories: FSSO_Setup_edirectory, and • the controller agent for Citrix servers: TSAgent_Setup.
Also, for each agent, there are two versions available for download: the executable (.exe), or Microsoft Installer (.msi).
Once you've downloaded the collector agent, run the installation process as administrator, then follow these steps in the installation wizard:
This is the collector agent installed. From the FSSO Agent Configuration application, you can configure settings such as:
The FSSO collector agent timers are also very important to ensure proper operation. Let's take a look at each one and how they work.
• Workstation verify interval. This setting controls when the collector agent connects to individual workstations to verify if a user is still logged in to the same station. It changes the status of the user under Show login User, to not verified when it cannot connect to the workstation. If it does connect, it verifies the user and the status remains OK.
• Dead entry timeout interval. This setting applies only to entries with an unverified status. When an entry is not verified, the collector starts this timer. It's used to age out the entry. When the timer expires, the login is removed from the collector. From FortiGate's perspective, there is no difference between entries that are OK and entries that are not verified. Both are considered valid.
• IP address change verify interval. This setting checks the IP addresses of logged-in users and updates the FortiGate when user's IP addresses change. This timer is especially important in DHCP or dynamic environments to prevent users from being locked out if they change IP addresses.
• Cache user group lookup result. This setting caches the user group membership for a defined period of time. It is not updated, even if the user changes group membership in AD.
Another important FSSO setting is the AD access mode. You can set the AD access mode by clicking Set Directory Access Information. It specifies how the collector agent accesses and collects the user and user group information. There are two modes that can be used to access AD user information: standard and advanced.
The main difference in both modes include the naming convention used:
Also, advanced mode supports nested or inherited groups; that is, users can be members of subgroups that belong to monitored parent groups. Additionally, in advanced mode FortiGate can apply protection profiles to individual users, user groups, and organizational units (OUs).
In comparison, in standard mode, protection profiles can only be applied to user groups, not individual users.
In advanced mode, you can configure FortiGate as an LDAP client and configure the group filters on the FortiGate. You can also configure group filters on the collector agent.
If the LDAP on the collector agent fails, it doesn't matter what the LDAP on the FortiGate says, FSSO won't work. If the FortiGate LDAP fails, but the LDAP on the collector agent is still running, the FortiGate may not be able to collect logs, but the collector agent will still collect logs.
Fortinet strongly encourages users to create filters from the collector agent.
In AD settings, not all group types are supported. It only supports filtering groups from:
• security groups • universal groups • groups inside organizational units (OU), and • Local or universal groups that contain universal groups from child domains (only with Global Catalog).
All FortiGate configurations include a user group called SSO_guest_user. When only passive authentication is used, all the users that do not belong to any FSSO group are automatically included in this guest group.
This allows an administrator to configure limited network access to guest users that do not belong to the Windows AD domain.
However, if both passive and active authentication are enabled, the behavior is different. Users that do not belong to any FSSO group will be prompted to enter their credentials.
Depending on your network, you may need to configure advanced settings in your FSSO collector agent.
Citrix servers support FSSO. TS agent mode allows the server to monitor user logins in real time. The TS agent is like a DC agent, but it needs the collector agent to collect and send the login events to FortiGate. It then uses the same ports to report the logins back to the collector agent.
Citrix servers must be configured with VIP to allow the collector agent to collect user login events. The TS agent cannot forward logs directly to FortiGate, they first have to be gathered by a collector. This does not work with polling from FortiGate.
A RADIUS server configured as a RADIUS-based accounting system can interact in your network by sending accounting messages to the collector agent.
FSSO collector agent also supports monitoring a Microsoft Exchange Server, which is useful when users access their email using their domain account.
Finally, let's take a look at some of the FortiGate diagnostic commands that you can use to troubleshoot FSSO issues.
To display the list of FSSO users that are currently logged in, use the CLI command diagnose debug authd fsso list.
For each user, the user name, user group, IP address, and the name of the workstation from which they logged in are shown.
The Memberof section shows the group that was created on the firewall that you mapped the AD group to. The same group should be shown in the User group screen on the GUI.
Use exec fsso refresh to manually refresh user group information from any directory service servers connected to FortiGate using the collector agent.
To show the status of communication between the FortiGate and each collector agent, you can use the CLI command diagnose debug authd fsso server-status.
However, before you use that command, you must first run the command diagnose debug enable.
Also available under diagnose debug authd fsso are commands for clearing FortiGate's cache of all currently logged in users, filtering the display of the list of logged in users, and refreshing the login and user group information.
The command diagnose debug fsso-polling detail displays status information and some statistics related with the polls done by FortiGate on each DC.
The command diagnose debug fsso-polling refresh-user flushes the information about all active FSSO users.
In agentless polling mode, FortiGate frequently polls the event viewer to get the login events. You can sniffer this traffic on port 445.
Also, there is a specific FortiGate daemon that handles the polling mode. It is the fssod daemon. To enable agentless polling mode real-time debug, use the diagnose debug application fssod -1 command.
In this lesson, you learned about the methods for collecting user login information using FSSO; NTLM authentication and AD access modes; how to configure FortiGate and the collector agent for FSSO; and, finally, how to troubleshoot and monitor FSSO.
In this lesson, you will learn about public key infrastructure (PKI); how to manage certificates on FortiGate; how FortiGate can use certificate-based authentication for administrators, SSL VPN clients, and IPsec peers; how to use SSL certificates; and how to inspect the contents of encrypted traffic.
After completing this lesson, you should have these practical skills in certificate management. You should be able to describe PKI and cryptography; understand digital certificates and certificate authorities; manage digital certificates; configure certificate-based authentication; use SSL certificates; enable full SSL inspection; and use inline SSL inspection.
This section provides a brief overview of public key infrastructure and cryptography.
Public key infrastructure, or PKI, provides the framework for the fundamentals of security, such as authentication, confidentiality, integrity, non-repudiation, and access control. It is a comprehensive system of hardware, software, policies, and procedures that allows both users and computers to securely exchange data over networks, and verify the identity of the other party.
PKI has two core elements: public key cryptography and certification authorities (CA).
Before we get into the more specific public key cryptography—or asymmetric cryptography—used in PKI, let's examine the subject of cryptography in general. Cryptography is essentially about securing communications between two entities through the process of encryption and decryption: scrambling plaintext into cipher text (encryption) and then back into plaintext (decryption).
Some protocols, such as HTTP or SMTP, send data in plain or clear text. That means that anyone in the middle running a packet sniffer can see and understand exactly what is being transmitted. This is how private information, including passwords, can be captured by third parties.
In cryptography, data privacy is achieved with encryption. Encryption applies an algorithm and key to the data, making it unintelligible to a third party, before it travels across the network. Only the recipient with the right key can decrypt the data and access the information.
Data integrity ensures information is not altered in storage or transit. The recipient can verify that the information has not been modified. If a third-party device changes the data, the decryption fails and an error is generated.
There are several methods to verify data integrity. Many are checksums (CHKSUM), or one-way hashes, which generate a unique value from applying the hashing algorithm to the original clear text. First, the sender sends the cipher text and the hash. Next, the recipient recovers the plaintext and recalculates the hash. If the calculated hash is the same as the received value, then the message has not been modified in storage or transit.
Authentication allows the sender and receiver to confirm each other's identity. Since only the sender has the correct key to encrypt the data and only the recipient has the correct key to decrypt the data, they can verify each other's identity. The sender can be assured that only the correct recipient will be able to decrypt the data and the recipient can confirm the origin of the data as the trusted sender.
Non-repudiation ensures that an individual cannot deny the authenticity of their digital signature on a document or message. With cryptography, the identity of the sender is bound to the data being exchanged by a digital signature. As a result, the sender cannot deny participating in the transaction at a later date.
There are two different forms of cryptography: symmetric cryptography and asymmetric cryptography. Both use a key to mathematically scramble and unscramble data in a way that only the recipient can predict. However, there is a significant difference between the two forms.
Symmetric cryptography uses the same cryptographic key for both encryption and decryption. A secret key is used to change the content of a message, and as long as both the sender and recipient know the secret key, they can encrypt and decrypt all messages that use it. With symmetric cryptography, the problem is exchanging the secret keys over the Internet without getting intercepted.
A solution to this problem is asymmetric cryptography, also referred to as public key cryptography because it is used in PKI. With asymmetric cryptography, a key pair is used. There is a public key, which can be openly distributed, and a private key, which is kept secret by the owner. There is no concern about exchanging keys over the Internet, as the only one that is exchanged is the public key, which is supposed to be public. The key pairs are mathematically linked, and perform the inverse function of each other. For example, a message encrypted by the public key can be decrypted only by using the matching private key. Likewise, a message encrypted using the private key can only be decrypted using the matching public key. It is extremely difficult (or practically impossible) to get the private key from the public key.
Asymmetric cryptography achieves all four objectives previously discussed: data privacy, data integrity, authentication, and non-repudiation.
As just explained, asymmetric cryptography requires the use of key pairs. If the sender encrypts a message with their private key, only the matching public key can decrypt it. So how do recipients get the public key? Through digital certificates. This section will examine digital certificates and certificate authorities.
Digital certificates, also known as X.509 certificates, are used to exchange the public key between two entities. But they are also much more than that. They contain specific information that identifies both the entity and the certificate issuer.
The certificate issuer is a certificate authority (CA). A CA signs each certificate it issues in order to certify that the digital certificate and its contents are trusted and valid.
PKI uses the relationship trust model, and the CA is at the root of the hierarchy as the trusted third party: everything begins with the CA. A CA issues its own digital certificate—known as the root certificate—in order to establish this point of ultimate trust. Once the root certificate is established, the CA can generate digital certificates that are issued and signed by the root certificate. It can also issue a certificate to a subordinate CA, which issues certificates on its behalf.
When a CA issues and signs a digital certificate, they are essentially proclaiming "this is the entity who we say it is and we certify it". Accordingly, if users trust the CA and can verify the CA's signature as authentic, then they must trust that the public key does belong to the entity identified in the digital certificate.
This slide shows how asymmetric cryptography using digital certificates works.
1. Before starting the data transmission, the sender must send their certificate to the recipient. The sender's certificate includes the sender's public key. 2. Similarly, the recipient sends their certificate to the sender. This contains the recipient's public key. 3. The sender encrypts the message using the recipient's public key and sends it. 4. The recipient uses their matching private key to decrypt the message. Only the equivalent private key (which is held only by the recipient) can decrypt the data.
The same process applies to traffic travelling in the other way. That is, the side sending the data uses the other side's public key to encrypt the data.
There are many different types of certificates, each with different functions (and some certificates of the same function even have different names). A few common certificate types include:
• CA certificates (also called root or authority certificates). These certificates identify the certification authority and create the root of a CA hierarchy. As such, the certificate details have the same input for both the Issuer and Subject fields. These certificates are self-signed and contain the CA's public key needed to decrypt signatures in the signed certificates. • Web server certificates (also called local service certificates). These certificates identify Web servers and are used to secure communication to and from Web servers, such as an SSH server, HTTPS website, Web portals, or EAP 802.1X authentication servers. The certificate details usually have the DNS name of the server in the Subject field, though this can be the Web server IP address too. The public key of the Web server is included. • User certificates (also called client certificates). These certificates identify one person to another, a person to a device or gateway, or one device to another device. The certificate includes the public key associated with the identity.
Both user and Web server certificates fall under the category of end-entity certificates.
It is possible for a private key to become compromised. For example, if an employee leaves your organization or it is revealed the CA no longer considers the certificate holder trustworthy. When this occurs, the CA can revoke the certificate. One way to revoke a certificate is to list the serial number of the certificate on a remotely accessible certificate revocation list (CRL), which is updated and re- posted by the CA periodically. As such, any entities attempting to validate the certificate can see that is revoked, based on its presence on the CRL, and choose not to trust it.
Certificate-based user authentication uses a user certificate to identify the user. The user certificate contains their public key and also the signature of the CA that issued their certificate. The CA's signature is encrypted using the private key of the CA.
Accordingly, in order for an authentication server (for example, FortiGate) to authenticate a user through their user certificate, the authentication server must have the certificate of the CA that signed the user certificate. Why? Because the CA certificate contains the CA's public key, allowing the authentication server to decrypt and validate the user certificate, which is encrypted/signed by the CA's private key.
The authentication server also verifies that the certificate is still valid, has not expired, and is not on a CRL. If any of these verifications fail, the certificate-based user authentication would fail.
An HTTPS server (a website) identifies itself using a Web server certificate (also known as a local service certificate). When a user connects to the HTTPS website, the browser receives that Web server certificate. The Web server certificate is signed by the root CA that issued it.
In order for the browser to trust the website through its Web server certificate, the browser must have the CA certificate that issued the Web server certificate installed. Why? Because the CA certificate contains the CA's public key, and the public key is used to decrypt and validate the signature in the Web server certificate.
The most common browsers include the CA certificates of well-known public CAs (for example, Comodo, Entrust, GoDaddy, RSA, and Verisign). As such, installing the CA certificate is not required if signed by a well-known CA already pre-installed in the browser by default. However, if the Web server certificate is signed by a private CA, for example, you must install the CA certificate in the browser so that it can trust the Web server certificate the website is using to identify itself.
The browser also verifies that the certificate is still valid, has not expired, and is not on a CRL. If any of these verifications fail, the browser presents a certificate warning to the user, indicating something is not right with the website being visited.
This section examines how you can manage digital certificates on FortiGate. This includes how to get digital certificates (including SSL certificates); how to import certificate revocation lists (CRLs); and how to back up and restore certificates.
The process of getting a digital certificate for your FortiGate begins with creating a certificate signing request (CSR). The process is as follows:
1. Generate a certificate signing request for FortiGate. A private and public key pair is created for your FortiGate. The CSR is signed by the FortiGate's private key. 2. Submit the CSR to a CA. The CSR includes the FortiGate public key and specific information about the FortiGate itself (IP address, distinguished name, email address, and so on). Note that the private key remains confidential on FortiGate. 3. The CA verifies that the information in the CSR is valid and then creates a digital certificate for FortiGate. The certificate is digitally signed using the CA's private key. The CA also stores the certificate in a central repository and publishes the public key bound to FortiGate. 4. Install the certificate on your FortiGate.
You can create a CSR through the Certificates page of the GUI by clicking Generate. Fill out all the required information, such as the IP address (or FQDN) and company name. Ensure the key type and size fit your requirements. You can submit the CSR through two different methods:
• Select File Based to generate the CSR as a .cer file, which is then sent to the CA. • Select Online SCEP to submit the CSR to the CA online using the SCEP protocol. For example, if using FortiAuthenticator as your CA, you can enable and configure SCEP on FortiAuthenticator and use this method.
If using the file-based method, the CSR is added to your list of certificates on the Certificates page. Select the CSR and click Download. The administrator can now download the file (.cer), which is a PKCS#10 request (an unsigned copy of your certificate) and submit it to the CA. The CA uses this file to generate a signed certificate.
If using the online SCEP method, enter the CA server URL used for SCEP and the challenge password provided by the CA administrator. The CSR is automatically submitted online.
Once submitted through either method, FortiGate shows the certificate status as pending until the certificate has been validated and signed by the CA. At this point, the status changes to OK and the digital certificate can be used.
When you receive a signed digital certificate back from the CA, you must import it into FortiGate. This only applies if you used the file-based method to submit the CSR. With SCEP, the process occurs automatically online—no file import is required.
You can import the certificate from the Certificates page. Click Import and select Local Certificate. From the import certificate dialog box that appears, ensure Local Certificate is selected as the type and browse for the .cer file provided by the CA.
Once you import the certificate, the status changes from pending to OK.
Note that it is possible to add a certificate that FortiGate will use in SSL communications without generating and signing a CSR. The CA can create a certificate for your FortiGate without a CSR (though the CA is responsible for providing all the certificate details for your FortiGate). In this way, you can add a certificate using the following methods:
• Upload a PKCS#12 file, which is a single file that includes the signed certificate file and the key file. • Upload both a certificate file and the key file.
In order for FortiGate to trust only valid certificates, it is important to import and maintain CRLs. A certificate revocation list is a list that contains revoked certificates (or more specifically, the serial number of the certificates). When FortiGate is validating a certificate, it will check that the certificate's serial number is not listed in a CRL imported to the FortiGate. Administrators must manually keep all CRLs up-to-date.
You can import a CRL from the Certificates page by clicking Import > CRL. There are four different import options you can use: HTTP, LDAP, SCEP, and Local PC. The first three options point to external repositories and require you to connect to the repositories to upload the CRL to FortiGate. The last option, Local PC, requires you to have the CRL file locally stored before you can upload the CRL to FortiGate.
When you back up the FortiGate configuration, the keys and certificates are backed up as well.
FortiGate also provides the option to store digital certificates as a PKCS#12 file, which includes the private and public keys as well as the certificate. You can restore the PKCS#12 file to a FortiGate device of any model or firmware version, or to a non-FortiGate device.
You can perform the backup and restore from the CLI only and it requires the use of a TFTP server.
You can configure a CA and local certificate for a VDOM or globally. If you upload a certificate to a VDOM, it is only accessible inside that VDOM. If you upload a certificate globally, it is accessible to all VDOMs and global.
Global and VDOM-based certificate configuration includes view details, download, delete, and import certificate.
In the GUI, a global icon indicates that the certificate is global when VDOMs are enabled.
This section outlines how to configure FortiGate to use certificate-based authentication for administrators, SSL VPN clients, and IPsec VPN peers.
FortiGate supports certificate-based authentication of users. In FortiGate, users who authenticate with a certificate are referred to as PKI peer users. Before creating a PKI peer user on FortiGate, you must import the root CA certificate that issued and signed the user certificates on FortiGate. Once you have completed that, the process is as follows:
1. Create a PKI peer user account. You must create the first PKI user through the CLI config user peer command. After that, a new PKI page appears in the GUI under User & Device. You can create new PKI users from there. When creating the account, you must specify the CA that issued each user's certificate. 2. Create a firewall user group for PKI peer users. 3. Assign the PKI peer user to the user group.
You can add the user group with PKI peer users to your firewall policies. Note that in order for PKI peer users to authenticate with their certificates the user must install their certificate in the personal certificate store of their computer. If using the Mozilla Firefox browser, however, users must install the certificate in the Firefox browser certificate store, as Firefox uses its own certificate repository (unlike Internet Explorer and Google Chrome, which use the certificate repository of the OS).
FortiGate supports certificate-based authentication of administrators as well. When logging into the FortiGate GUI as a PKI administrator, FortiGate will use the certificate installed on the management computer to authenticate.
Similar to the process of creating a PKI peer user (as discussed on the previous slide), you must first install the root CA certificate on FortiGate and the administrator must have their digital certificate installed in the personal certificate store of their computer (or Firefox browser certificate repository if logging in through Firefox).
1. Create the PKI administrator. You need to create two user accounts on FortiGate: a PKI peer user account and an administrator account. These two accounts work together to form a single PKI administrator account. You do not need to give these accounts the same name, but because they refer to a single PKI administrative user, it might be helpful for maintenance purposes. 2. Add the PKI peer user account to a firewall user group dedicated to PKI administrators. 3. Configure the administrator account. Select Use public key infrastructure (PKI) group as the account type and select the PKI group to which the PKI peer user belongs.
FortiGate can also use certificates to authenticate SSL VPN clients and IPsec VPN peers. Both require that you install the root CA certificate on FortiGate. Configuration is more complex then creating PKI peer user accounts an PKI administrator accounts. Refer to the FortiOS Administration Guide for more details.
Any time you use certificate-based authentication, whether for users or administrators, you should always make sure you import the CRL into FortiGate and keep it updated.
SSL/TLS is primarily used to encrypt communications between a server and client, such as a Web server and Web browser. In order to establish secure communications, the server requires an SSL certificate and optionally one for the client for authentication purposes. This section outlines how FortiGate uses an SSL certificate to authenticate itself to HTTPS clients.
Secure Sockets Layer (SSL) is the cryptographic protocol used to secure transmissions over TCP. One common application of SSL is secure HTTP, or HTTPS. When a user attempts to connect to an HTTPS site, SSL/TLS is the protocol used between the Web server and the browser to authenticate and encrypt the data.
SSL uses both asymmetric and symmetric encryption as you will see on the following slide.
An SSL session starts with the SSL handshake. The handshake process is as follows: 1. The user enters an HTTPS URL into a browser. 2. The browser sends a Client Hello message to the Web server that includes information about which encryption and compression algorithms the browser supports, as well as a pseudo- random number. 3. The server replies with a Server Hello message that includes supported algorithms and a pseudo-random number. 4. The server sends its digital certificate to the browser, which contains its public key and the name of the server. 5. The browser verifies the contents of the digital certificate to ensure the name of the server matches the name the browser requested, and if valid, creates a symmetric session key using the two random values The symmetric session key is sent to the server as a message encrypted using the public key from the server's certificate. 6. The server decrypts the message with its private key. If the decryption is successful, it proves to the browser the authenticity of the server.
This handshake happens over two round-trips—though verifying the validity of certificates is optional in the second round. An abbreviated handshake can be used if a client has a previous session cached, which means only a single round trip is needed. The server and browser can now encrypt and decrypt all transmitted data with the symmetric session key. It is secure, because only the browser and server know the symmetric session key. The symmetric key is valid only for the length of the session. If the user closes the current session, that symmetric key is no longer valid and cannot be used again. When a new SSL session is created, a new symmetric key is created.
By default, FortiGate uses a self-signed security certificate to authenticate itself to HTTPS clients. These self-signed certificates encrypt data just as well as those purchased from any of the big vendors of SSL certificates, but self-signed certificates are not listed with an approved certificate authority (CA) and are therefore considered untrusted.
We just discussed the benefits of using HTTPS. However, there are risks associated with its use, since encrypted traffic can be used to get around your normal defenses. For example, if the session is encrypted when you download a file containing a virus, it might get past your network's security measures.
This section examines how you can use full SSL inspection, also known as deep inspection, to protect encrypted sessions.
Some FortiGate devices offer a mechanism to inspect and apply protection profiles over SSL encrypted traffic. It is called full SSL inspection. Without SSL inspection, encrypted traffic cannot be inspected, as the firewall does not have the key that is required to decrypt the data.
To configure, you must position your FortiGate in the middle of the communication between the user's browser and the website. When the browser connects to the site, the Web server sends its certificate, which contains its public key. Its certificate has been issued to the website by a CA.
The FortiGate intercepts the Web server certificate and generates a new one. The new certificate is also issued to the website, but this time it is issued by the CA installed on the FortiGate (which is a private CA). The FortiGate also generates a new pair of public and private keys. The new certificate contains the public key generated by FortiGate.
Now FortiGate uses the FortiGate public key—and not the Web server's public key—to start the encryption to the user's browser. On the other side, it uses the Web server's public key to start the encryption and establish the conversation with the server.
SSL inspection requires an SSL certificate that allows FortiGate to generate a new pair of keys and a new certificate. FortiGate must do this each time a user connects to a different site.
The certificate required for SSL inspection must have either the CA field equal to True, or the Key Usage to include KeyCertSign. The FortiGate models that support SSL inspection include an SSL certificate that you can use for full SSL inspection. It is called Fortinet_CA_SSL and is signed by a CA called FortiGate CA, which is not public.
Because self-signed SSL certificates are not trusted, the browser presents a certificate warning when you attempt to access an HTTPS site that uses an untrusted certificate. This warning does not necessarily indicate you are vulnerable to eavesdroppers—it just means the browser cannot verify the identity of the website. FortiGate has its own configuration setting on the SSL/SSH Inspection page that allows, blocks, or ignores untrusted SSL certificates.
When set to Allow, FortiGate continues its inspection of the secured site by using the FortiGate Untrusted CA certificate to re-sign/replace the server certificate when the server certificate is untrusted. The browser presents a warning, but the user can proceed to the site by adding an exception to the browser. The security rationale behind this setting is that it will generate certificate warnings to clients that are connecting to untrusted sites when doing deep SSL inspection. If the server certificate is trusted, a trusted FortiGate certificate is used to re-sign the server certificate.
When set to Block, FortiGate blocks the connection outright and the user cannot proceed. There is no option to add an exception.
When set to Ignore, FortiGate continues its inspection of the secured site by using the self-signed SSL certificate (Fortinet_CA_SSL) to re-sign/replace the server certificate, even when the server certificate is untrusted. This certificate can be trusted after installing the FortiGate root certificate, which can be downloaded from FortiGate. In this case, the browser presents a warning, but the user can proceed to the site by adding an exception to the browser. The Ignore setting is only configured through the CLI with the command displayed in the slide.
FortiGate provides a configuration setting that allows invalid SSL certificates. Invalid certificates produce certificate warnings as well, though as a result of problems with the certificate details itself (for example, the certificate is expired or the URL doesn't precisely match what you entered into the browser). You can allow invalid certificates by enabling the Allow Invalid SSL Certificates option. You can also log invalid certificates as well by enabling Log Invalid Certificates.
If you don't want to use FortiGate's self-signed certificate, you can install an X.509 certificate issued by a public or private CA, and configure FortiGate to identify itself using a server certificate instead.
If using an SSL certificate issued by a private CA, you must install your certificate in the list of trusted CAs. Failure to do this results in warning messages in Web browsers any time there is access to any HTTPS website. It may also result in encrypted communications failing, simply because the CA that issued and signed the certificate is untrusted.
Once you download the SSL certificate from FortiGate, you can install it into any Web browser or operating system. Not all browsers use the same certificate repository (for example, Firefox uses its own repository, while Internet Explorer stores certificates in a system wide repository). In order to avoid certificate warnings, you need to install the SSL certificate as a trusted root CA.
When installing the certificate, make sure that it is properly set up as a root authority. The process varies from one software to another.
When doing full SSL inspection using the FortiGate self-signed CA, your browser displays a certificate warning each time a user connects to a HTTPS site. This is because the browser is receiving certificates signed by FortiGate, which is a CA it does not know and trust. There are a few ways to avoid this warning:
• Download the Fortinet_CA_SSL certificate and install it in all the workstations as a public authority. The Allow option ensures that the client won't trust all connections with this certificate—including connections to sites that should normally prompt the warning. • Use a SSL certificate issued by a private CA. In this case, the certificate needs to be installed on FortiGate and the device configured to use that certificate for SSL inspection. The private CA may still need to be installed in all the workstations.
This is not a limitation in FortiGate, but a consequence of how digital certificates are designed to work. The only way for any vendor device to inspect encrypted traffic is to intercept the certificate coming from the server and generate a new one. In other words, FortiGate must do an authorized man-in-the- middle attack or have the private keys already installed.
It should be noted that there are some Web security policy mechanisms that prevent full SSL inspection, for example HTTP Public Key Pinning (HPKP).
HPKP is a security feature designed to prevent MITM attacks. In this case, the SSL certificate is deployed on a website and the client (browser) is instructed to pin the server's cryptographic identity (public key of one of the certificates in the chain) for a set period of time. An HTTP header provides the information about which public key belongs to the server. When an HPKP-enabled browser (such as Chrome and Firefox) connects to the site, it compares the public key hash presented by the server with the previously pinned information. If the server provides an unknown certificate, the Web client presents a trust dialog warning. Pinning the public key to a server prevents any attacks where fraudulent certificates are used, as the client can detect when the cryptographic identity has changed. HPKP does have its limitations, however, such as trust-on-first-use (before the browser receives the HTTP header value).
The options to work around the SSL certificate requirements of different servers and software are limited, especially the hardcoded Microsoft/Apple update. With HPKP, you can replace the SSL certificate with one that will satisfy the security settings. Another option is to disable the settings causing this. HPKP can be disabled in some browsers, but this is not an option in all environments. The last option is to bypass SSL inspection of that traffic or to manually install the intercepting CA as a trusted root CA.
Other servers or software can have their own requirements on the certificates that are used for SSL.
You can configure the full SSL inspection profile from the SSL/SSH Inspection page by selecting the deep-inspection profile.
The deep inspection profile allows you to enable SSL inspection of the following:
• Multiple Clients Connecting to Multiple Servers. Use this option for generic policies where the destination is unknown. • Protecting SSL Server. Use this option when setting up a profile customized for a specific SSL server with a specific certificate.
By default, the inspection method is set to Full SSL Inspection (all the traffic is inspected) and the CA certificate is the self-signed Fortinet_CA_SSL.
SSH Deep Scan is also enabled by default on this profile. SSH deep scan enables FortiGate to do man-in-the-middle for SSH traffic (which is based on SSL). A similar process occurs: FortiGate re- signs the certificate provided by the SSH server and starts inspecting the encrypted traffic. The SSH client will present a certificate warning if you do not install the root certificate. Note that SSH Deep Scan allows you to restrict the search for SSH protocol packets to TCP/IP port 22. This is not as comprehensive as searching all ports, but it is easier on the performance of the firewall. You can set the protocol actions for deep inspection.
Within the deep inspection profile, you can also specify which traffic, if any, you want to exempt from SSL inspection. You may need to exempt traffic from SSL inspection if it is causing problems with traffic or for legal reasons.
Performing SSL inspection on an HPKP-enabled site, for example, can cause problems with traffic. Remember the only way for any vendor device to inspect encrypted traffic is to intercept the certificate coming from the server and generate a new one. Once FortiGate presents its default SSL certificate— or any other SSL certificate—the browser refuses to proceed (no click-through option) if the issuing FortiGate CA is not loaded as a trusted root CA. The SSL inspection profile, therefore, allows you to exempt specific traffic.
Another reason it may be necessary to bypass SSL inspection is the law. In some countries it is illegal to do SSL inspection of banking related traffic, for example. Configuring an exemption for specific categories (like Finance and Banking) is simpler than setting up firewall policies for each individual bank. Become familiar with whatever local laws may apply to encrypted Internet traffic in your jurisdiction.
After you create and configure an SSL inspection profile, you must assign it to a firewall policy so FortiGate knows how to inspect encrypted traffic.
A security profile without an SSL inspection profile enabled results in encrypted protocols being ignored through that firewall policy. When an SSL inspection profile is enabled, it does not mean that traffic is subject to SSL inspection and man-in-the-middle decryption by FortiGate. Rather it defines how encrypted traffic is handled.
From the CLI, however, an SSL inspection profile is not required because this is a more advanced method of configuration.
With flow-based traffic, FortiGate can do inline SSL inspection. SSL decryption and encryption is done by the IPS engine, rather than the SSL proxy. The IPS engine is not a proxy, so it does not break communication on Layer 3 the way a proxy does. The key negotiation is modified so that the traffic is decrypted as needed.
To use inline inspection on FortiGate, you must enable SSL inspection and all security profiles must be flow-based (Antivirus, Web Filter, Application Control, Intrusion Protection, FortiClient Profiles, SSL Inspection). No explicit configuration is needed.
In this lesson, we will learn how to prevent crucial private data, such as bank account routing numbers and credit card numbers, from leaving your network, and from being inappropriately transmitted.
Data leak prevention is required by some compliance regimes, such as PCI DSS and HIPAA, but other networks may also find it useful to help prevent, for example, student cheating.
After this lesson, you should have the practical skills required to enforce data leak prevention (DLP). These skills include knowing when to use DLP, knowing how to monitor specific data types, and how to configure DLP filters and sensors.
FortiGate has other features, such as IPS and antivirus, that can detect and block files. What makes DLP different? Why should you use it?
Traditional firewalls and first-generation UTMs were designed to prevent attacks and nuisances from getting into your network. Web filtering is applied to only traffic coming in. Likewise, despite best practice to apply it in both directions, many people apply antivirus and email filtering to traffic coming in only.
Co-workers to often share sensitive documents inside your network. Sensitive information is also shared between servers that work together to host a single application. But, if sensitive data, such as financial information, becomes public, it can have serious effects. Stock prices, bank transactions, privacy, and password security can all be compromised.
DLP helps to ensure that your network follows the rules required by your real-world organization, and doesn't give out important information.
FortiGate scans traffic matching to your firewall policy for the DLP patterns that you specify.
When you configure a pattern, whether pre-defined or custom, DLP doesn't directly inspect traffic. Instead, it communicates the pattern to the proxy's or IPS engine's processes, which do the scanning. So, when you are troubleshooting, you may need to investigate traffic flow through modules that you didn't manually enable.
If the scan finds a match, it executes the filter's corresponding action. In the example shown here, the first two filters didn't match the file, but the third one did, so FortiGate performed its action.
Now that we've talked about DLP in general, let's look at some specifics, such as how to add filters in a DLP sensor. Initially, we'll use some default file filters and message patterns. Later, we'll show how to customize and expand them. Most DLP behavior is dependent on the filter type, and we will look at later, in depth. Right now, let's look at service inspection and action.
First, you need to change the GUI menu settings to show DLP (it's hidden by default). You can do this from the Feature Select page. Then, go to the DLP submenu available under Security Profiles to create a DLP sensor. Inside it, add a filter.
• match criteria • which protocols to scan, and • actions that FortiGate will apply when traffic matches.
In the Examine the Following Services area, choose which network protocols should be scanned. Like other security features, secure protocols aren't in the list of scannable network services. However, if you enabled SSL/SSH Inspection (specifically deep inspection), FortiGate will scan each protocol that you choose and its secure equivalent. For example, if you mark the check box for HTTP, FortiGate will scan HTTP as well as HTTPs. More information on deep inspection is available in the FGT II Certificate Operations lesson.
Note: FortiOS Carrier models also examine MMS services (MM1, MM3, MM4, MM7).
For each filter in the DLP sensor, you must select an action—what FortiGate should do if traffic matches.
The default setting is Log Only. If you're not sure which action to choose, the default setting can be useful, initially. While you study your network, use this action to see what sensitive information is being transmitted. Later you can fine-tune your sensor and select the most appropriate action to block sensitive files from the WAN.
Now let's return to the top of the filter, which is the more complex part of the configuration. Select the type: either Messages or Files. Most other available options depend on this initial choice.
Messages scans for words, credit card numbers, or other text-based patterns directly embedded in the protocol, not as a file. There are two preconfigured message filters available: Credit Card and SSN.
If the pre-defined DLP patterns don't match exactly what you're looking for, you can use the Regular Expression option to configure your own custom pattern. Use PCRE syntax. Supported expressions and performance with complex Turing complete expressions always vary by the regular expression engine. So, if you're looking for references, look specifically for PCRE, not others, such as the similarly-named Perl language.
File changes the available options to be appropriate for files, such as file size, fingerprinting, and watermarking.
In this example, we are blocking credit card numbers from leaving the network using a preconfigured message filter. The Block action stops the violation traffic, but it also generates a log, which you can view in the forward traffic logs. The logs provide information such as security event, result, and firewall policy. Select the log for more details.
The Details tab provides more information about the source, destination, and action, to name a few. The Security tab provides additional information, such as the filter type, filter category, and DLP filter index.
File name patterns are intuitive. If a file name either matches literally, or matches the pattern, then FortiGate will perform the action.
If an important file name varies (users often try to evade DLP by renaming files to a harmless- sounding name) then you should use patterns, not the literal file name. Configure FortiGate to match all intended file names, but no unintended file names. For example, browsers often rename downloads of duplicate file names to prevent accidentally overwriting an existing different, yet identically named, file. For example, they would add (2) before the file extension. Likewise, Windows renames copies of files so that they start with Copy of. So you should use a name pattern such as nice*.jpg, not the literal file name, nicepainting.jpg.
The example here shows which filters would match the file name, and which filters wouldn't.
But what if the file name doesn't match any pattern? What if the file name is radically different, and therefore a broad pattern would cause false positives? What if we want to block all executables regardless of name or platform, for example?
File name matching alone is often not enough for very sensitive data. You may want a more sophisticated filter. One alternative is to use file type matching.
File type matching behaves as you'd expect. FortiGate does not identify file types by their extension (for example, .doc). This is because users could circumvent DLP by simply renaming the extension. Instead, FortiGate identifies file types by scanning for matching binary patterns; that is, how that file type stores data in specific areas, in specific patterns of 1's and 0's. However, in order to use this accurate technology, FortiGate must have a corresponding decoder that understands the binary data source. Without a decoder, FortiGate cannot decipher the string of zeros and ones and, therefore cannot identify the file type.
If you choose a Files type for the filter, and select the Specify File Type option, File Types and File Name Patterns settings become available.
File Types scans file contents, regardless of the file name or extension. Even if the file is renamed with a different extension, DLP will still detect it. It has a corresponding drop-down menu where you can select for which file types to scan.
Here is an example file filter table that matches all Microsoft Office files. Notice that in order to do this, the table must contain sub-filters of both types. This is because:
• Older versions of Office use a binary file format, identifiable by a binary file type scan. • Office 2010 and newer files are not binary, but ZIP archives. They are actually XML files inside a ZIP archive. This is documented on the Microsoft website (see link in slide).
It's crucial to note that because Office 2010 and newer use a nested file type, if you use file type filters with them, the filters will match any ZIP file, not just Office files. This is a common DLP misconfiguration. So, to avoid false positives with Office 2010 and newer, the default profile matches by file extension instead. Note, however, that the tradeoff is possible false negatives.
Let's return to our DLP sensor's filter. When scanning files, types and names aren't our only option. On most networks, it's typically not an option to block all Microsoft Office files, and blocking by file name is not effective if users try to circumvent. So, what alternatives do we have?
FortiGate can use a content-based filter called document fingerprinting. Document fingerprinting identifies specific files using one or more CRC checksums. You can apply this content-based filter on many files at once, including large files.
How accurate is document fingerprinting? How many checksums will DLP calculate and store?
The file itself is not stored in FortiGate, only the checksums of chunks. Smaller chunks mean that more checksums will be calculated for each file and DLP will fingerprint more accurately. That is, even if someone changes a file in a few places, fingerprinting will still be able to identify it because the checksums of the other chunks will still match. The tradeoff is that more checksums require more storage space on FortiGate. So you must decide the best balance between performance and accuracy.
Note: The document fingerprint feature requires a FortiGate with internal storage.
Before you configure any fingerprint filters in a DLP sensor, consider whether you'd like to make custom sensitivity level tags. For example, you could make a custom sensitivity level named Finance. When configuring fingerprint filters, you can use the Finance sensitivity level to tag all money-related fingerprints.
Once you've defined any custom sensitivity levels, you're ready to define your fingerprints for network share documents.
Using the CLI, you can configure FortiGate to connect to a file share, either on a daily, weekly, or monthly basis. Each time it connects, FortiGate can automatically recreate checksums for all files in the share, or retain old fingerprints (in case an old version of the file is still circulating).
Fingerprinting through a file share allows you to add many files and update the fingerprint for each addition or change. While configuring, choose which sensitivity level FortiGate will use to tag those fingerprints.
After fingerprint sensitivity and the network share are configured, the next step is to configure the DLP sensor's filter.
The fingerprinting feature is enabled (configured) from the CLI as a filter in the DLP sensor, which allows you to choose the sensitivity level. Once you have configured a filter in your DLP sensor from the CLI by setting set filter-by fingerprint, the File Finger Print option appears in the GUI. From the File Finger Print drop-down menu, you can choose whether the filter will use Critical, Private, Warning, or your own custom group of fingerprints, according to their sensitivity level tag.
DLP will scan and inspect these rules (filters) for fingerprint matching, from top to bottom. As DLP stores the file checksum in chunks, it detects that the fingerprint file changed from the original file, and takes action as defined in the DLP sensor.
The diagnose test application dlpfingerprint CLI command provides many options to view stats, dump all chunks, or refresh all doc sources in all VDOMs.
So now we've configured a few filters in the DLP sensor. Continue with more filters until the sensor matches all traffic that it should, but doesn't match unintentionally. Finally, apply the DLP sensor by selecting it in a firewall policy.
Here is an example DLP sensor with a few filters. Each filter searches traffic for different types of sensitive information, such as a credit card number or fingerprint. If traffic matches a filter, FortiGate will apply that filter's action.
Remember, DLP filters are evaluated for a match sequentially, from top to bottom, and FortiGate uses the first matching filter. For example, let's say an email contains a credit card number (which filter sequence 1 says to block), but also has sensitive text (which filter sequence 5 says to log, but allow). FortiGate will only use the sequence 1 filter: the email will be blocked, not allowed.
Up until now, we've shown DLP blocking or monitoring sensitive data. What else can DLP do?
It can record traffic summaries – that is, logs – and, if enabled, the full files and messages that were contained in the traffic.
If you are familiar with content archiving on older versions of FortiOS, you will recognize summary archives and full archives here.
Summary archiving records a log message that summarizes the traffic, and therefore will vary by protocol. For example, with an email message, the summary archive would contain the sender's email address, the recipient's email address, and the size. When users access the Web, FortiGate logs would record every URL they visited.
Full archiving records the summary log, but a complete email message, including any attachments, is also archived. When a user accesses the Web, every page the user visits is archived.
This can be useful in forensic investigations; however, it's not meant for prolonged use. Depending on what you're archiving, full archiving can require large amounts of FortiGate's disk, CPU, and RAM resources, which decreases performance.
For example, if you fully DLP archive a 100 MB file, FortiGate will store more than just 100 MB. It stores the data plus Ethernet, IP, and other headers that were used during network transmission, plus the log message. So, it will require slightly more than 100 MB of storage. It will also require RAM and CPU until the FortiGate finishes writing the file to its hard disk. Full DLP archiving also consumes disk space that FortiGate may need for other UTM features.
So for performance reasons, it's better to use a FortiAnalyzer or external storage device.
If you need to inspect and archive email – especially for prolonged times – then FortiMail may be a better alternative. It has local archiving, plus antispam, secure messaging, and other in-depth features that FortiGate's SMTP proxy cannot support.
In this lesson, you will learn how to use some diagnose commands and tools.
After completing this lesson, you should have these practical skills required to determine your network baseline, read diagnostic output, troubleshoot the physical and network layers, trace packet flow through FortiGate processing, and find the root causes of abnormally high CPU or memory usage.
In order to define any problem, first you must know what your network's normal behavior is.
In the graph shown here, the range that indicates "normal" is in blue. What is exactly this blue line? It indicates the averages – our baseline. What is the thick black line? It's the behavior right now. When the current behavior (black line) leaves the normal range, an abnormal event is happening.
Normal is measured and defined in many ways. It can be performance: the expected CPU and memory utilization, bandwidth, and traffic volumes. But it can also be your network topology: which devices are normally connected at each node. It's behavior too: traffic flow directions, which protocols are blocked or proxied, and the distribution of protocols and applications used during specific times of the day, week, or year.
In this section, we'll look at some measurements – how you can determine if the network has a problem.
If you're starting a new network, many things may not work yet. Many problems are obvious, and normal behavior is, too.
But, in large or established networks, the difference between normal and broken may be subtle. How can you find what needs to be fixed or improved?
What is the first way to define what normal is for your network?
Topology. Flows and other specifications of normal behaviour are derived from this. So during troubleshooting, a network diagram is essential. If you create a ticket with Fortinet Technical Support, it should be the first thing you attach.
• Physical • Logical
A physical diagram shows how cables, ports, and devices are connected between buildings and cabinets. A logical diagram shows relationships (usually at OSI Layer 3) between virtual LANs, IP subnets, and routers. It can also show application protocols such as HTTP or DHCP.
Another way to define normal is to know the average performance range. On an ongoing basis, collect data that shows normal usage.
For example, if traffic processing is suddenly slow, and your FortiGate's CPU usage is 75%, what does that indicate? If CPU utilization is usually 60-69%, then 75% is probably still normal. But if normal is 12-15%, there may be a problem.
Get data on both typical maximum and minimum for the time and date: that is, on a workday or holiday, how many bits per second should ingress or egress each interface in your network diagrams?
If you find that something is not normal, what should you do?
How else can we get current statuses? First, let's look at CLI commands: you can use them through a local console, even if network issues make GUI access slow or impossible.
A few commands provide system statuses. The get system status command provides most general purpose information. Output shows:
• Model • Serial number • Firmware version • Host name • FortiGuard license status • System time • Version of the FortiGuard antivirus, IPS, and IP reputation databases, and others.
At the physical layer, troubleshooting analyzes which ports are plugged in, media capacity, and negotiated speed and duplex mode.
At the data link layer, diagnostics often analyze how many frames are being dropped due to CRC errors or collisions.
The output might vary depending on the model and NIC driver version. It all the cases, the output shows the physical MAC address, administrative status, and link status.
This command is available on FortiGate models with SFP/SFP+ interfaces. It provides the optical received signal strengths, which can be used to diagnose layer-1 optical issues.
If you suspect that there is an IP address conflict, or that an IP has been assigned to the wrong device, you may need to look at the ARP table. This command is used for that purpose. It shows the FortiGate interface, IP address, and associated MAC address. This command lists the information for all the external devices connected to the same LAN segments where FortiGate is connected. FortiGate's own IP and MAC addresses are not included.
Let's say that FortiGate can contact some hosts through port1, but not others. Is the problem in the physical or link layer? None of them. Connectivity has been proven with at least part of the network. Instead, you should check the network layer. To test this, like usual, we start with ping and traceroute.
The same commands exist for IPv6 too: execute ping becomes execute ping6, for example.
Remember: location matters. Tests will be accurate only if you use the same path as the traffic that you are troubleshooting. To test from FortiGate (to a FortiAnalyzer or FortiGuard, for example), use FortiGate's own execute ping and execute traceroute CLI commands. But to test the path through FortiGate, additionally use ping and tracert or traceroute from the endpoint – from the Windows, Linux, or Mac OS X computer; not only from the FortiGate CLI.
Due to NAT and routing, you may need to specify a different ping source IP address – the default is the IP of the outgoing interface. If there is no response, verify that the target is configured to reply to ICMP echo requests.
One of the most powerful troubleshooting tools in FortiGate is the debug flow. We will teach it in this section.
If FortiGate is dropping packets, can a packet capture (sniffer) be used to know the reason? To find the cause, you should use the debug (packet) flow.
The debug flow shows step-by-step how the CPU is handling each packet.
This is a sample of a debug flow output. Here we have captured the first packet of a TCP 3-way handshake, the SYN packet. It shows:
the packet arriving to the FortiGate, indicating the source and destination IP addresses, port numbers, and incoming interface the FortiGate creating a session, indicating the session ID finding the route to the destination, indicating the next-hop IP address and outgoing interface ID of the policy that matches and allows this traffic, and how the source NAT is applied.
the packet arrival, indicating again the source and destination IP addresses, port numbers, and incoming interface the ID of the existing session for this traffic. This number should match the ID of the session created during the SYN packet how the destination NAT is applied, and finding the route to the destination, indicating again the next-hop IP address and outgoing interface.
What is also important, if the packet is dropped by FortiGate, this output shows the reason for that action.
This tool is useful for many other troubleshooting cases, for example when you need to understand why a packet is taking a specific route, or why a specific NAT IP address is being applied.
We will now talk about some commands for CPU and memory diagnostics.
Not all problems are network connectivity failures. Sometimes, there might be resource problems in the devices.
What else could causes latency? Once you have discarded problems with the physical media and bandwidth usage, you should check the FortiGate resources usage: CPU and memory.
If usage is high, tools can find which feature is consuming the most. Additionally, you can troubleshoot faster if you know precisely which change (if any) corresponds with when the problem began. So it's a good idea to gradually enable features. Don't enable everything at once. If the CPU or RAM usage is too high, and you've just enabled many features, it will be more complex to determine how to lower the usage.
At the top, output shows that this FortiGate model has a multicore CPU: usage is shown for each core, CPU0 to CPU3. This is followed by the RAM usage.
Next, let's examine the output for diagnose sys top. It lists processes that use the most CPU or memory. Some common processes include:
To sort the list by highest CPU, press Shift-P. To sort by highest RAM usage, press Shift-M.
Previously, we showed that diagnose sys top has a column for the process state. This explains the relationship between the states.
Most of the time, the process state will be either R or S. This means the process is doing something (running), or waiting to be told to do something (sleeping).
Occasionally, and for short periods, you may also see processes in the D state while writing to a disk. If a process is staying in the D state for a long time, this could mean there is a reading or writing problem.
You should never see a process in a Z state. It's a zombie process and it means the OS has encountered an error it can't continue from.
The diagnose sys top-summary command is slightly different than the diagnose sys top command. The former is better for examining memory usage. Why?
It collects all memory being used by a process and its child processes, including any memory that is shared between the processes.
Let's compare the outputs of diagnose sys top and diagnose sys top-summary. They are different. In the diagnose sys top output, child processes are listed individually. But in the diagnose sys top-summary output, all child processes are listed together. The name is marked by an X, indicating how many times a process has forked.
Because RAM for all forks (children) is added together into a total, diagnose sys top-summary is better when you need to determine which feature to adjust in order to correct performance.
What is forking?
Forking is when the operating system makes multiple copies of a process in order to either subdivide processing load, or handle multiple similar tasks.
If diagnose sys top shows scanunitd running three times, diagnose sys top-summary would show one entry with an "x3", meaning it was forked 3 times. But diagnose sys top-summary shows that all scanunitd processes are using 12 MB of RAM, while diagnose sys top indicates that each scanunitd is using just under 2 MB. Why do they indicate different RAM usage?
The 10 MB anti-virus database isn't duplicated in RAM for each child process; it is loaded into shared memory, which isn't counted by diagnose sys top.
FortiOS doesn't allow different processes to communicate directly. So if memory wasn't shared, then FortiOS would be required to load a copy of the antivirus database for each scan process. Each individual process would be using around 11 MB; only three concurrent scans would require 33 MB. Performance would decrease.
To finish this lesson, we'll talk about firmware installations through the console port and hardware tests.
From the FortiGate BIOS, administrators can execute some operations over the flash memory and the firmware images. To access the BIOS menu you must reboot the device while connected to the console port. The booting process, at one point, shows the message:
Press any key while this prompt is displayed to interrupt the booting process and display the BIOS menu.
By pressing F from the BIOS menu you can format the flash memory.
This might be required if the firmware got corrupted, or if the administrator wants to do a clean installation of a new firmware. Keep in mind, though, that formatting the flash deletes any information stored on it, such as firmware images, configuration, and digital certificates.
After reformatting the flash, you will need to install the firmware image from the BIOS. Follow these steps:
The interface assigned as the TFTP install interface depends on the model. However, and in most cases, it is either the port1 or internal interface.
From the BIOS menu, select the option G to install a new firmware.
If everything is ok, you should see a series of pound signs, indicating that the device is downloading the image. The BIOS will then verify the integrity of the file and give you these three options:
If the firmware is going to be used in production, select the first option: Save it as the default firmware.
The last option (Run the image without saving it) allows you to run and test firmware without overwriting any existing firmware in the flash. Once you have finished the tests and are ready to roll back the change, you need to reboot the device, and the previously existing firmware will be used.
Like with any other electronic device, damage to RAM can cause intermittent crashes.
If you suspect hardware failure, you can run the hardware tests.
How do you run the hardware tests? It depends on the FortiGate model.
For some FortiGate E-series and D-Series models, you can run the hardware tests directly from the FortiOS CLI.
For other models, you must download special HQIP hardware testing images from the Fortinet Technical Support website.
The steps for uploading the hardware test image are the same as the ones used for uploading a firmware image. You can run the hardware test image without saving it in the flash, so any existing firmware image won't be overwritten.
For some E-series and D-series models, the command diagnose hardware test suite all runs the hardware tests from FortiOS. The hardware tests require user interaction while running. Users can skip some of the steps and some tests require connecting external devices (such as USB sticks) or network cables to the FortiGate.
Another area you may want to monitor, purely for diagnostics, are the crash logs. Crash logs are available through the CLI. Any time a process is closed for any reason, the crash log records this as a crash. Most of the logs in the crash log are normal. For example, any time the antivirus definitions package is updated, the scanunit process needs to close down in order to apply the new package. This is a normal shutdown.
Some logs in the crash log might indicate problems. For that reason, crash logs are frequently requested by Fortinet Technical Support for troubleshooting purposes. This slide shows the command you have to use to get a crash log.
During this lesson, we discussed how to measure the network, CPU, and memory usage. We covered physical and network layer troubleshooting. The lesson also included the debug flow, loading a firmware from the BIOS, hardware tests, and crash logs.
In this lesson, you will learn how FortiASIC chips and Fortinet's mezzanine cards accelerate FortiGate's performance.
After completing this lesson, you should have these practical skills that you can use to fine tune your configuration to enhance your network and security performance.
You will be able to describe Fortinet's chipset, identify IP sessions offloading, configure anomalies detection, accelerate flow-based inspection, and configure the TCP SYN proxy for SYN flood detection.
Let's start by looking at what's inside a FortiGate, and comparing the specialized hardware accelerator-FortiASIC types.
Like most security devices, FortiGate is built from a general purpose computer foundation. However, general purpose computer appliances are limited in network security performance. That's why Fortinet has included special add-on hardware acceleration components.
What does "hardware acceleration" mean? Hardware acceleration allows FortiGate to offload, or transfer, its processing load from its general purpose CPU to specialized processors.
Note that offloading frees up CPU cycles and offloaded tasks execute faster on specialized hardware than they do on general purpose CPUs. This process is similar to how your computer uses the GPU on its graphics card; that is, the GPU often has dedicated RAM of its own, and GPU circuits are designed to be more efficient at processing images.
ASICs are chips that are designed to perform a single set of functions with optimal efficiency, performance, and scalability.
The strength of an ASIC chip is in its specialization; therefore, Fortinet develops several key ASICs identified by their type (network processor or content processor) and version. Fortinet also develops security processors, which are not considered FortiASICs.
Note the convention name is the family abbreviation plus the revision number. Generally, newer versions have more features and better performance. This graphic illustrates the difference in performance between an older FortiGate that uses CPU-only gear compared to a newer, faster FortiGate with hardware acceleration.
ASICs are wired into the circuit board; therefore, they are not upgradable.
Now that we've briefly compared the types of FortiASIC chips, let's look at the evolution of each chip, and how to configure your FortiGate to use each ASIC for performance boosts. We'll also show how offloading changes expected output for diagnostics.
In this section, we will examine the features of CP chips, and which configurations can use them to achieve higher performance.
The CP is a co-processor for the CPU. It accelerates many common resource-intensive security- related processes.
Since the very first FortiGate model, Fortinet has included a CP in the design. The CP works at the system level. Those early FortiGate models are now out-of-date, so we will start by looking at the earliest, relevant CP: CP4.
CP4 processes IPsec. More specifically, it encrypts and decrypts DES, 3DES, and AES for IPsec Phase 2. It also generates pseudorandom numbers for cryptography, calculates SHA-1 and MD5 checksums for message authentication, and validates RSA public keys in PKCS#1 certificates.
CP5 added FIPS and RFC compliance, and improved IPsec offloading with support for IKE and RSA. Additionally, its random number generator is compliant with SSL, which would become especially relevant to the next generation, CP6.
CP6 included hardware support for SSL, which was required for performance given the growing popularity of SSL VPN and SSL inspection.
CP8 added support for an IPS engine for signature pattern-matching; extended cryptographic support to include ARC4 and SHA-256; and large public keys. Additionally, CP8 chips can be stacked for scalability.
You can disable CP offloading processes based on configured firewall security policies:
• IPv4 • IPv6 • Multicast
For each new session, the first packet always goes to the kernel on the CPU. However, if the NP doesn't support all of the features that you have configured FortiGate to apply to the session, the kernel must continue to process all of that session's packets on the slow path.
If the NP does support all features you've configured FortiGate to apply to that session, the kernel sends an instruction to the NP programing it to handle that session, and enable a fast path. The NP accelerates transmission.
Once FortiGate has processed the last packet – a TCP FIN (finish) or RST (reset) signal, for example, or if there are errors – then the NP returns the session to the CPU so it can tear down the session.
This diagram illustrates how FortiGate decides whether or not to accelerate packet forwarding and IP session handling.
This process may change according to NP version. Similar to CPs, there are also several NP revisions.
NP1 and NP2 were released many years ago, and can offload most types of IPv4 traffic.
The next generation, NP4, presented a significant performance increase over earlier versions.
NP6 doubles NP4 performance, and adds support for IPv6, CAPWAP traffic (for wireless control and provisioning), and multicast.
To find information about each of your FortiGate's network processors, use the CLI command get hardware npu.
The interfaces of platforms without integrated switch fabric (ISF) are connected directly to NPs. Therefore, it is particularly important to be aware of those direct mappings, especially when the platform has multiple NPs.
NP versions 1, 2, and 4 do not support traffic statistics (including logs). The only exception to this rule are the first and last packets in the IP session.
This exception occurs because the first and last packets are handled by the kernel, before the session information is passed to an ASIC. The ASIC chip processes all of the packets in between, so the kernel is not aware of any statistics that occur during that time. As well, NP1 through NP4 do not have the memory to keep their own statistics.
NP6 does support statistics. It also supports the SNMP Ethernet MIB, so it can answer queries about these statistics too.
To be eligible for offload, the traffic must match the ASIC chip's design criteria. For NP4, the criteria are:
• Layer 2 type/length must be set to 0X0800. IEEE 802.1q and 802.3ad traffic can also be offloaded. • Layer 3 must be unicast IPv4. (Multicast and IPv6 are not supported by NP4.) • Layer 4 must be UDP, TCP, SCTP, or ICMP. • Header or content must not require modification by a session helper. • Traffic must not be inspected by any kind of security profile, such as antivirus or web filtering. • Traffic must not have originated from the firewall. • Ingress and egress ports must be on the same NP4, unless there is an EEI bridge between two communicating NP4s.
The NP6 and NP4 criteria for offloading are the same, except that NP6 also supports IPv6, NAT64, NAT46, and others.
FortiGate models with NP6 are physically wired together with an ISF. The ISF wiring allows communication between all interfaces and the NP6 processors, without requiring the traffic to pass through the CPU. This means that offloading is possible, even if the ingress and egress ports are not on the same processor.
To verify if a session was offloaded, use the CLI command diagnose sys session list.
npu info indicates the sessions can be offloaded. The offload=x/y flag states this. In this example, all the sessions have been offloaded (offload=4/4). An output offload=0/0 indicates non accelerated sessions.
no_ofld_reason indicates the session was not offloaded, such as if the sessions were redirected to antivirus or IPS analysis.
The kernel is not aware of what is happening with a session while that session is being handled by an NP. This impacts logging. What else does it impact?
Packet capture involves FortiGate's kernel, which uses the CPU. NP chips do not send all of their data back to the CPU, since this would counteract acceleration. As a result, once a session is offloaded to an NP, the sniffer does not see the offloaded packets.
During troubleshooting, you often need to see the entire session. In order to do this, you may need to temporarily disable offloading. You can do this on a per-policy basis, in the CLI. Remember, this action also disables CP offloading.
NP does more than just IP layer packet forwarding. It also does the following:
Hardware acceleration of user traffic is decided by each individual FortiGate in the cluster. Generally, traffic is load balanced for content inspection purposes, so hardware acceleration does not apply. It is, however, the redirection of packets in the same session that is offloaded. This means that the network processor re-writes the MAC addresses, offloading the CPU from these interrupts.
If an IPsec tunnel uses encryption and hashing algorithms supported by the network processor, than the IPsec user data processing can be offloaded.
To verify if IPsec traffic is offloaded, use the CLI command diagnose vpn tunnel list.
This shows the status and statistics for each VPN tunnel. If it contains a line with npu_flag, the tunnel is being offloaded.
Remember that it is necessary to get initial packets from both directions first, before checking the npu_flag field. Otherwise, it is expected to be 0/0 – initially.
Network processors can also accelerate traffic for 802.3ad link aggregation – if all aggregated interfaces are associated with the same NP. (Depending on which vendors you're familiar with, link aggregation is also called NIC teaming, channeling, or link bonding.) To determine if the channel is offloaded, use the CLI command diagnose netlink aggregate.
Will all link aggregation-related processing be offloaded? No, offloading doesn't occur until the CPU establishes the session and sends it to the NP. So in the initial phase of hashing – which is how the kernel decides which interface in the aggregate will send the first frame – the CPU is still involved. Offloading occurs after link aggregate hashing.
Some network processors can also detect some anomalies and drop those packets. This occurs in hardware. It is independent from the IPS engine, and occurs before the IPS engine is involved. To do this, configure the interface with set fp-anomaly. For example, you can configure your NP processor to drop packets with an unknown protocol number.
Note that only limitations and prioritizations are supported, however guaranteed bandwidth cannot be offloaded and it is handled by the CPU.
NPs have limited shaper objects (NP6 has more shaping objects and packet flow improvements), therefore traffic shaping by the CPU is still common.
Now we will look at SPs, which are mezzanine cards that accelerate FortiGate's performance.
SPs provide an integrated, high-performance, fast-path multilayer solution for both intrusion protection and firewall functions.
The intrusion protection starts at an IPS hardware accelerated engine, which ensures that each packet is OK. Then, a set of interface-based packet anomaly protection, DDoS protection, policy-based intrusion protection, and firewall fast path are employed to prevent attacks.
SPs can also offload packet transmissions, such as multicast, IPv4, IPv6, and NAT64 traffic. It accelerates IPsec encryption and decryption. It can perform flow-based content inspection and provide SYN proxy functionalities.
The first revision can handle IPS and encrypted multicasting offload. This version is built in three expansion cards: FMC-XE2, FMC-FE8, FMC-CE4, which are all compatible with FortiGate's 3810A, 5001A,1240B, and 3016B.
The second revision added support for flow-based inspection. The mezzanine expansion card of this SP is FMC-XG2, which is compatible to FortiGates 3140B and 5001C.
And, the third revision has performance benefits built-in the FMC-XH0 card.
To determine the SP installed in your FortiGate model (if any), use the CLI command diagnose npu spm list.
In the example shown here, xh0 indicates that the FMC-XH0 model mezzanine expansion card is installed. This product family uses SP3.
Remember, SPs mostly accelerate security related features, an NP does not support these sessions.
SPs handle flow-based inspection, such as AV, IPS, and application control, providing significant throughput benefits.
To offload flow-based inspections, it is necessary that ingress and egress interfaces in firewall policies be bound to the same SP.
DoS policies, depending on the type, can also be offloaded to the security processor.
An interface on an SP can also act as a TCP SYN proxy, dropping all connections not completed by the client within the timeout period. This provides greater protection and performance for your back- end servers against SYN floods.
The TCP connection is not passed to the server until the client finishes the 3-way handshake. In this way, SYN flood attacks do not exhaust CPU resources.
The SYN proxy is configured in the DoS profile tcp_syn_flood setting, and applied to an interface with a security processor.
Finally, let's look at a type of ASIC that integrates two of the others: System on a Chip (SoC).
SoC combines a general purpose CPU with Fortinet's custom ASIC network, NPs, and CPs, into a single chip.
Usually, SoC modules are found in desktop or small office models, because it allows smaller form factors, but cannot handle a carrier grade computing load. The biggest benefit of SoC is greater cost and energy efficiency.
Did you note in previous sections we didn't mention anything about CP7 and NP3?
CP7 and NP3 (or NP4Lite as it's really known), were developed to be integrated in Fortinet's SoC processor. This integrated processor has three modules:
• VPN module (CP7 processor) includes the SSL, TLS, and IPsec engines, which handle the encryption and decryption of traffic and message authentication algorithms. • Firewall fast-path module (NP4Lite processor) is a light version (with fewer features) of an NP4 processor. It accelerates session handling. • The IPS deterministic finite automata (DFA) module is used to offload some IPS signature matching.
This table compares the performance for each specification in the most used FortiASICs, SoCs, and SPs.
In this lesson, we'll cover the fundamentals of IPv6, and how to configure it on your FortiGate. This lesson also includes examples of how to enable security features in an IPv6 environment.
After completing this lesson, you should have the practical skills necessary to configure IPv6 networks on FortiOS. You should also have a solid understanding of IPv6 routing and firewalling; transition technologies such as dual-stack, NAT64, and tunneling; and IPv6-compatible security profiles.
The first thing people usually ask is why they need IPv6 when IPv4 is still working. They feel that IPv6 is for the future, not now. But that question is old. The future is now. Most network devices are already IPv6-capable, although many administrators don't realize it. According to Google (http://www.google.ca/intl/en/ipv6/statistics.html), on January 5, 2016, 43% of requests from Belgium involved devices that supported IPv6 and adoption of IPv6 in the USA was 25%. Governments, such as those in USA and China, have guidelines and requirements for IPv6 compatibility. Aside from government organizations, some ISPs, such as Comcast and Verizon, have already begun putting clients on IPv6. That's because IPv4 address space exhaustion has already occurred at the top level and regional exhaustion is occurring now. (click)
But with hosts already on the IPv6 network, it's both a new favorite target and hiding place for attackers. (click)
So, even if your users don't need IPv6 connectivity internally, you need to be aware of IPv6 on the Internet, and its security effects.
Even if you don't implement IPv6 on your internal network, on the Internet, IPv6 usage is accelerating. Due to IPv4 address exhaustion, many of the hosts that are being added to the Internet, especially smartphones in rapidly growing countries, now have a public IPv6 address only. IPv6 adoption is doubling almost every year.
The presence of servers that offer native IPv6 is increasing rapidly to support IPv6-only clients. So, within the next few years, it is quite likely that your network security will need to support IPv6.
What many people aren't aware of is that IPv6 solves more than just the problem of IP address exhaustion. Many of the services and realities that we use today were actually added to work around IPv4 limitations. These include:
• NAT, • Secure communications, like VPN and SSL, and • DHCP.
When you implement IPv6, you may not need some of your old IPv4 services.
IPv4 was designed in 1980 and first deployed on ARPANET – a precursor to the Internet – in 1983. This was before smart phones and tablets, before security breaches became a daily occurrence, before VPNs for remote workers became commonplace, and before hardware existed for fast, strong encryption and decryption.
IPv6 was designed in 1998. So it's far from new, but new enough to factor in many of the changes in how we use networks. To ensure a graceful transition period, IPv6 design includes ways for legacy IPv4 to connect with IPv6 networks.
First, let's look at how you show the IPv6 settings on the FortiGate GUI. By default, they're hidden in the GUI, and only available in the CLI.
Whether you're running IPv6 on your network, or you simply want to secure yourself against attackers using IPv6, the good news is that Fortinet devices, like FortiGate, already support IPv6.
To keep the FortiGate GUI simple and the performance level high, not all features are initially shown in the GUI. You can show IPv6 features from the Feature Select page.
Like other advanced features, a few IPv6 settings are available in the CLI only.
Once you've turned IPv6 settings on in the GUI, two new policy types appear: IPv6 firewall policies, and IPv6 denial of service (DoS) policies.
Now that IPv6 settings are visible, what features are supported?
Obviously, IPv6 firewall policies are supported, as we just mentioned. Malware and application-layer threats are largely independent of the IP version, so security profiles are supported in the new IPv6 firewall policies.
Just like IPv4 public addresses, IPv6 addresses on the public Internet can be mapped to regions where the ISP routers are located, so there is a geographical database for that.
There are also some less obvious, but necessary, transition features. FortiOS is typically deployed with dual stack routing, where administrators assign both IPv4 and IPv6 addresses to interfaces.
Once you've enabled IPv6 settings, you need to know the answers to these questions:
You may not need to upgrade anything on your network. Many devices, including home Wi-Fi routers and Windows computers, have supported IPv6 for a long time. They'll work automatically. But, you should verify that they support, especially if you have older devices, VoIP, printers, or ISP modems. IPv6 is not backwards compatible with IPv4-only devices: the headers are too different. If you use a device that doesn't support IPv6, you can configure your FortiGate to use transition technologies. Transition technologies help by rewriting the IP header on packets that have to move between IPv4 and IPv6 along their path. Transition technologies include: • NAT64, • tunneling, and • dual stack.
So, what are the differences between IPv4 and IPv6 headers?
The first, obvious difference is the version number. Next? The address length. IPv6 addresses are much longer – 128 bits instead of 32 bits – and therefore have a new notation, which we'll explain soon.
Other parts of the header are the same, even though they may have a different name: the TOS/DSCP bits are now named traffic class, and the TTL is now named hop limit. Protocol, which indicates the next protocol layer in the packet, is called next header in IPv6. Why was the name changed? IPv6 may have chains of extension headers between the IP header and the next protocol with a payload. Let's look at how extension headers work.
It's easy to see that you need more bits for larger IP addresses. Other than that, why are IPv6 headers different?
One reason is to increase efficiency. Remember the next header field? IPv6 can abbreviate packets. Packets only use the headers they need. For example, a packet that does not need routing is not required to have the routing header. These optional headers between the IPv6 header and the payload are named extension headers. There are as many extension headers as there are protocols on IPv4, plus new headers. Example extension headers include:
• Hop by Hop (data to be processed by all the routers in the path of the packet) • ICMPv6 • TCP • UDP • Fragmentation • Routing • Destination Options (parameters/data that must be processed by the destination host only) • Authentication (AH, IPsec) • Encrypted (ESP, IPsec)
In IPv4, IPsec VPN was added on. In IPv6, it's an integral part of the IPv6 stack – it's part of the defined extension headers – and, therefore, available with any implementation. The specification defines protocols for the Authentication Header (AH) and the Encapsulating Security Payload (ESP) header.
The ESP header provides a mix of security services in IPv4 and IPv6. ESP may be applied alone. The ESP header is either inserted after the IP header and before the next layer protocol header (in transport mode), or before an encapsulated IP header (in tunnel mode).
ESP can be used to provide confidentiality, data origin authentication, connectionless integrity, an anti- replay service (a form of partial sequence integrity), and (limited) traffic flow confidentiality. The set of services provided depends on options selected at the time of Security Association (SA) establishment and on the location of the implementation in a network topology.
The header diagram shown here applies to both IPv4 and IPv6.
There are two fields in the IPv6 header that can be used for Quality of Service (QoS): Traffic Class and Flow Label.
The 8-bit Traffic Class field in the IPv6 header is available for use by routers and/or traffic sources to identify and distinguish between different classes or priorities of IPv6 packets. The Traffic Class field is specified in RFC 2474, and introduces the term DS field for the Traffic Class field. The goal of this specification is that DiffServ routers have a known set of DS routines, which are determined by the value in the DS field. The forwarding path behaviors include the differential treatment an individual packet receives, as implemented by queue service disciplines and/or queue management disciplines. These per-hop behaviors are useful and required in network nodes to deliver differentiated treatment of packets.
The 20-bit Flow Label field in the IPv6 header may be used by a traffic source to label sequences of packets that it wants IPv6 routers to handle in a special way, such as non-default quality of service or real-time service. The Flow Label field is specified in RFC 6437. Packet classifiers can use the triplet of Flow Label, Source Address, and Destination Address fields to identify the flow to which a particular packet belongs.
Most transport- and application-layer protocols are independent of IP addressing, so you don't need to upgrade or configure them for IPv6 support. Simply configure the server's IPv6 address.
For HTTP, colon characters (which are part of a normal IPv6 address) are also used to denote port numbers. So if you want to go to an IPv6 URI, to solve the ambiguity, enclose the IP address in square brackets ( [ ] ) so that the browser will correctly interpret the colon characters. For example, to go to this URI:
Relatedly, on your website's DNS server, you would need to add an AAAA record.
Most website certificates are based on their domain name, but if yours identifies the host by the server's public IPv4 address, add a certificate for the IPv6 address.
Now that we've seen the IPv6 packet structure, let's examine the new 128-bit source address and destination address fields.
The first thing that you might notice about IPv6 addresses is that they are big and include letters. Any IPv6 host (or node, in IPv6 terminology) can have many IPv6 addresses on the same network interface card (NIC). In IPv4, interfaces often need manual configuration, so the thought of typing in those large IPv6 addresses for each NIC might seem intimidating. But it's not as hard as it seems. In IPv4, DHCP evolved to ease administrative burden. IPv6 has a more advanced mechanism already built in. You won't be required to configure many IPv6 addresses at all. In fact, privacy extensions on Windows, Mac OS X, and others may make addresses ephemeral.
Even if you do need to type or write an address, you may be able to abbreviate it. Look at the first address shown in this example. Compare it with the second address. You can skip leading zeroes, in the same way that we usually write 1 instead of 0001. Now, compare that with the last, most abbreviated address: if the address has consecutive zeros in multiple 16-bit blocks, you can simply omit all of the zeros between two colon marks (::). Of course, when you input the address, devices must interpret it as the full length address. If multiple double colon abbreviations were allowed, a device would have to guess how to expand an address such as 2001::1::1.
Addressing would be uncertain. That's why each IPv6 address can only have one double colon abbreviation.
In IPv4, there are multiple types of address: broadcast, multicast, and so on. But, what about in IPv6?
In IPv6, there are three types of addresses: unicast, anycast, and multicast.
• Unicast identifies one interface or interface group. (For link load balancing, multiple interfaces may use the same address as long as they appear as one interface to the host's IPv6 implementation.) • Anycast identifies multiple interfaces, typically belonging to different nodes. A packet sent to an anycast address is delivered to one of the interfaces (the nearest one, according to the routing protocol's measure of distance). • Multicast also identifies multiple interfaces, but a packet sent to a multicast address is delivered to all interfaces identified by that address.
Technically, it's not needed. Broadcast is simply multicast that includes all addresses, not a subset. But, from an engineering perspective, IPv4 broadcast also proved problematic. Broadcast storms and performance problems related to large broadcast domains – which could be huge due to more addresses in IPv6 – may be better in the future by omitting broadcast from IPv6.
Like in IPv4, each network interface card has a unicast address. A unicast address is composed of a network ID (the first n bits, depending on the number of host addresses in the subnet) and an interface ID (the remaining bits).
On a network, the first bits in every IP address are the same and the last part of the address is specific to each interface. However, in IPv6, if the address is automatically generated, the address's interface ID may correspond to the network interface card's physical MAC address. It's also common to have multiple addresses: one for each scope of communications. And oddly, depending on the scope of the address, it is not guaranteed to be globally unique. It's extremely unlikely that two IPv6 interfaces have the same address due to the large number of addresses, but it is theoretically possible. However, within each scope, there are no duplicates, and IPv6 has built-in mechanisms (which we'll explain soon) to detect and avoid duplicate addresses – avoiding the classic IPv4 problem of IP address conflicts.
IPv6 subnets are defined like they are in IPv4, using the first bits in the IP address. In IPv6, it's called the prefix.
Unlike in IPv4, in IPv6, we only use classless inter-domain routing (CIDR) subnet notation, not dotted decimal. Why? CIDR is shorter. With 128-bit addresses, dotted decimal netmasks are impractically large.
In IPv6, the prefix is often automatically configured when the interface solicits the router. So, it can be easy for entire subnets to be reconfigured to a new location – even if there is no DHCP server.
In IPv6 there are some reserved and common subnets. What are they? Global unicast prefixes come from your ISP. Global addresses are like public IPv4 addresses: they're routable on the Internet. (Remember, IPv6 is designed to work without NAT as the divider between public and private, so the names are not the same.) The global address format is: 001 + global routing prefix from your ISP + subnet ID + interface ID
What's the equivalent for private network IPs? Unique-local addresses are equivalent to IPv4 private network addresses. They are not routable on the IPv6 Internet. Global address and unique local adresses have the same structure after the first 48 bits of the address: a unique-local address has the format: Prefix + randomly assigned global ID Therefore, the same subnet ID used for global addresses can also be used for local addresses. Link-local addresses are used by nodes when communicating with neighbors on the same link. This happens during auto-address configuration, neighbor discovery, and when no routers are present. Unlike unique-local addresses, routers don't forward any packets with link-local source or destination addresses to other links. IPv6 link-local addresses are similar to IPv4 link-local addresses that use the 169.254.0.0/16 prefix. Link-local addresses can be reused on each link. Because of this address reuse capability, link-local addresses are not determinate. To address this, hosts use a zone identifier that identifies the interface of the address or sending interface for a link-local destination. The syntax is address%zone_id. For example, a link-local address for interface ID 24 on a Windows host could be: Link-local IPv6 Address . . . . . : fe80::8002:b44b:ca9e:5e09%24
Like they did in IPv4, static routes in IPv6 have also become cumbersome to manage. Dynamic routing protocols help to ease this administrative burden.
Almost every IPv4 dynamic routing protocol has an IPv6 version or extension. There are still interior gateway protocols (IGPs) and exterior gateway protocols (EGPs), distance-vector-based, and link- state-based routing protocol algorithms.
An IPv6 anycast address is an address that's assigned to more than one interface (typically belonging to different nodes). A packet sent to an anycast address is routed to the nearest interface having that address, according to the routing protocol's measure of distance.
Anycast addresses are allocated from the unicast address space, so they can use any of the defined unicast addresses. What makes an anycast address different from unicast? It's configured on more than one interface. The nodes to which the address is assigned must be explicitly configured to know that the address is an anycast address.
An IPv6 multicast address identifies a group of nodes. A node may belong to any number of multicast groups.
In IPv6, multicast traffic operates like it does in IPv4. Multicast addresses have the FF00 prefix plus 112 bits in the group id. After the first 8 bits of the prefix (0xFF), the next four bits are the flags (the first 0x0 of the prefix) and indicate a permanent (0x0) or transient (0x1) address. The next four bits (the second 0x0 of the prefix) are the scope of the multicast group.
The meaning of a permanently-assigned multicast address is independent of the scope value. In the example shown here, the NTP servers group is assigned a permanent multicast address with a group ID of 101 (in hexadecimal).
Non-permanently-assigned multicast addresses are meaningful only within a given scope. For example, a group identified by the non-permanent, site-local multicast address FF15:0:0:0:0:0:0:101 at one site is unrelated to:
Multicast addresses must not be used as source addresses in IPv6 packets or appear in any routing header.
We mentioned that IPv6 has some auto-configuration mechanisms to help configure your network devices with IPv6 addresses, and to avoid conflicts within each address scope.
Within the link-local scope, hosts can use the Neighbor Discovery Protocol (NDP) to help configure their own IP. NDP replaces multiple things in IPv4:
• ARP • ICMPv4 router discovery • ICMPv4 redirect
Nodes (hosts and routers) use NDP to determine their neighbor nodes' link layer addresses – which neighbors are reachable and which are not, and which addresses have changed.
Hosts also use NDP to find neighboring routers. When a route — or the path to a router — fails, a host searches for functioning alternates.
Within the global/site scope, unicast addresses must be unique beyond the local link. There are three ways to do this:
• stateless address auto-configuration (SLAAC) (also called IPv6 auto-configuration, defined in RFC 4862) • dynamic host configuration protocol v6 (DHCPv6) • manually
You can use stateless auto-configuration, or SLAAC, when hosts don't need a specific predictable IP address, so long as it is unique and properly routable.
SLAAC automatically configures addresses by using NDP and the router. Unlike DHCPv6, SLAAC doesn't require any additional servers. Minimal (if any) configuration is required on the router. How?
The first group of steps describes the stateless autoconfiguration of the link-local address.
The second group of steps describes stateless autoconfiguration of the global unicast address.
In SLAAC, the host generates its own addresses using a combination of locally available information (its MAC address) and information advertised by routers (the global prefix). So if there is no router, a host can only generate link-local addresses. But if you have a small LAN, that may be enough: local devices can use their link-local addresses to communicate.
Note that SLAAC doesn't tell the host about any DNS servers, however. If hosts require DNS and you don't want to configure it manually, how can you solve this? Or, what if you need to assign specific IP addresses to hosts?
Like with IPv4, you can also use DHCP with IPv6.
DHCP for IPv6 (DHCPv6; RFC 3315) can be used when you need to assign a specific IP address to each host, or to provide DNS settings. (Although RFC 6106 defines DNS settings in RAs, this is not currently supported.) DHCPv6 can also provide other settings, query a node, or change its address.
Clients and servers exchange DHCPv6 messages using user datagram protocol (UDP). DHCP servers receive messages from clients using a reserved, link-scoped multicast address. A DHCP client transmits most messages to this reserved multicast address, so that you don't need to configure the DHCP server address.
To allow a DHCP client to send a message to a DHCP server that is not attached to the same link, you can use a DHCP relay.
Note: The stateless DHCPv6 can provide additional configuration information, such as DNS recursive name servers or SIP servers, to the hosts that obtained its IPv6 addresses through auto-configuration (SLAAC) or manual addressing.
Now that we understand how auto-configuration and manual addressing is possible in IPv6, let's see how to do that on FortiOS.
To get started, configure an interface with an IPv6 address and prefix. Remember: SLAAC, if you're using it, requires /64.
In the example CLI configuration shown here, an interface on FortiOS is configured manually. Also in this example, SLAAC is enabled for clients by defining a network prefix that connected hosts can use to create a global address. Because FortiOS in NAT/route mode is an OSI Layer 3 router, FortiOS sends out router announcements (RAs).
Your IPv6-enabled devices will use this during their own SLAAC auto-configuration, and for other settings based on RA. They include one or more 64-bit prefixes, each with the autonomous flag enabled, indicating the address is in autonomous (or stateless) address configuration, and the onlink flag enabled, indicating that the address is assigned to the interface this advertisement was received on.
Note that the interface IPv6 configuration is a sub-branch of the interface CLI. You can configure a dual stack implementation by configuring the IPv4 address and configuring an IPv6 address in the sub-branch.
FortiOS can provide a DHCPv6 server, or you can provide your own.
Hosts will send a DHCPv6 request to the link-scope multicast address. A host uses stateful auto- configuration when it receives a router advertisement without any prefix information and you've enabled managed address configuration (additional addresses) and/or other stateful configuration (additional configuration parameters) flags. The response allocates an address from the range, and other configuration settings such as DNS servers.
Although it's less common, FortiOS can also be a DHCPv6 or SLAAC client.
To make FortiOS a DHCPv6 client, configure the interface to receive its global IPv6 address.
To make FortiOS a SLAAC client, configure the interface with autoconf enabled and ip6-send- adv disabled.
Of course, once the interfaces are configured for IPv6, you can apply security profiles to IPv6 firewall polices in the same way as IPv4 firewall polices.
Once you've configured the network interfaces on your FortiGate, with IPv4 the next step is often to configure firewall policies that apply network address translation (NAT).
IPv6 does have NAT for interoperation with IPv4, but NAT is not required by pure IPv6.
NAT postponed IPv4 address exhaustion. Firewalls also arguably originated with NAT masquerading. But NAT broke end-to-end connectivity, which has required workarounds such as NAT traversal in IPsec VPN.
IPv6 was designed to restore one of the original design goals of IPv4: end-to-end connectivity. So you won't always need NAT. Let's take a look.
Today, most of the Internet uses IPv4, and there will be many IPv4 hosts for a long time. It's not realistic to instantly turn on IPv6 and turn off IPv4. We are in a transition period. During this time, we need technologies to interconnect IPv6 and IPv4 hosts.
One of the ways we can do that is with NAT. So although IPv6 itself does not require NAT, it's still useful.
NAT64 is a mechanism for IPv4-IPv6 transition and IPv4-IPv6 coexistence. Together with DNS64, these two mechanisms allow an IPv6-only client to initiate communications to an IPv4-only server. They also enable peer-to-peer communication between an IPv4 and an IPv6 node, where the communication is initiated when either end uses existing, NAT-traversal, peer-to-peer communication techniques, such as Interactive Connectivity Establishment (ICE).
Stateful NAT64 also supports IPv4-initiated communications to a subset of the IPv6 hosts, through statically configured bindings in the stateful NAT64, which could be achieved using VIP46 in FortiOS.
DNS64 is a mechanism for synthesizing AAAA resource records (RRs) from A RRs. The IPv6 address contained in the synthetic AAAA RR is algorithmically generated from the IPv4 address and the IPv6 prefix assigned to a NAT64 device.
This configuration example shows a sample NAT64 policy. The source interface is an IPv6-enabled interface and the destination interface is an IPv4-enabled interface.
NAT66 is a stateless IPv6-to-IPv6 network prefix translation (NPTv6) function, designed to provide address independence to the edge network. It is transport-agnostic with respect to transports that do not checksum the IP header. NAT66 provides a 1:1 relationship between addresses in the inside and outside prefixes, preserving end-to-end reachability at the network layer.
NAT66 is experimental and defined in RFC 6296. Note the IETF does not recommend the use of NAT technology for IPv6.
FortiOS implements several tunneling protocols that are part of the transition technologies, allowing IPv6 communication to tunnel across an IPv4 network. FortiOS implementation includes IPsec to secure IPv6 in IPv4 tunnels.
Once IPv6 connectivity is configured – especially between IPv4 and IPv6 networks – you can use IPv6 versions of your usual connectivity testing commands.
The diagnose command branch allows you to get status information and manually manipulate the IPv6 configuration.
In the neighbor-cache list, look for the auto-configuration address for both FortiOS and any host. Note how the MAC address is used in the auto-configuration addresses. Remember in IPv6 there is no ARP, the neighbor mechanism replaces this. From a Windows host you can view the neighbor-cache using the command netsh interface ipv6 show neighbors (or ip -6 neighbor show in Linux).
The packet sniffer supports IPv6. The following are example IPv6 filters:
ICMPv6 (Next Header value 58) is similar to ICMP for IPv4. It is used by IPv6 nodes to report errors encountered in processing packets and to perform other internet-layer functions, such as diagnostics (ICMPv6 ping).
ICMPv6 is integral to IPv6. This table shows common IPv6 types and codes. The Related Messages column indicates the message type. Its value determines the format of the remaining data. The code field depends on the message type.
ICMPv6 messages are of two types: error messages or informational messages. Error messages are identified by a zero in the high-order bit of their message Type field values. Thus, error messages have message types from 0 to 127; informational messages have message types from 128 to 255.
From a security perspective, we will focus on IPv6 tunneling over an IPv4 IPsec tunnel. To do this in FortiOS, create an IPsec interface mode tunnel, as with the regular site-to-site VPN configuration. Your Phase 2 selectors, routes, and firewall policies are all IPv6.
In this lesson, we've looked at how to configure FortiOS in an IPv6 environment and enable features such as transition technologies and security profiles. We've also reviewed common diagnostic commands and new commands for IPv6 networks.