Connecting multiple networks to a FortiGate interface using virtual LANs (VLANs) FortiOS 4.0 MR3 75 http://docs.fortinet.com/ Connecting multiple networks to a FortiGate interface using virtual LANs (VLANs) Problem Connecting three internal networks to the FortiGate internal interface using VLANs to keep the three networks separate. Solution This solution uses VLANs to connect three networks to the FortiGate internal interface in the following way: • Packets from each network pass through a VLAN switch before reaching the FortiGate unit. The VLAN switch adds different VLAN tags to packets from each network. • To handle VLANs on the FortiGate unit, add VLAN interfaces to the internal interface for each network • Add a DHCP server to each VLAN interface. • Create security policies to allow each network to access the Internet. This solution assumes you have configured a VLAN switch to tag packets from the three networks. Add VLAN interfaces 1 Go to System > Network > Interface and select Create New to add a VLAN interface for the engineering network: 2 Select Create New to add a VLAN interface for the marketing network: 3 Select Create New to add a VLAN interface for the sales network: Name Engineering-net Type VLAN Interface internal VLAN ID 10 Addressing mode Manual IP/Netmask 192.168.10.1 Name Marketing-net Type VLAN Interface internal VLAN ID 20 Addressing mode Manual IP/Netmask 192.168.20.1 Name Sales-net Type VLAN Interface internal FortiGate Unit in NAT/Route mode Engineering network 192.168.10.0 VLAN ID 10 Marketing network 192.168.20.0 VLAN ID 20 Sales network 192.168.30.0 VLAN ID 30 VLAN Switch FortiGa at t t t te e e U Unit V N ch h h h internal wan1 e inte
85
Embed
Connecting multiple networks to a FortiGate interface using … · 2012-01-20 · Name Marketing-net Type VLAN Interface internal VLAN ID 20 Addressing mode Manual IP/Netmask 192.168.20.1
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Connecting multiple networks to a FortiGate interface using virtual LANs (VLANs)
Fh
Connecting multiple networks to a FortiGate interface using virtual LANs (VLANs)
Problem Connecting three internal networks to the FortiGate internal interface using VLANs to keep the three networks separate.
Solution This solution uses VLANs to connect three networks to the FortiGate internal interface in the following way:
• Packets from each network pass through a VLAN switch before reaching the FortiGate unit. The VLAN switch adds different VLAN tags to packets from each network.
• To handle VLANs on the FortiGate unit, add VLAN interfaces to the internal interface for each network
• Add a DHCP server to each VLAN interface.
• Create security policies to allow each network to access the Internet.
This solution assumes you have configured a VLAN switch to tag packets from the three networks.
Add VLAN interfaces
1 Go to System > Network > Interface and select Create New to add a VLAN interface for the engineering network:
2 Select Create New to add a VLAN interface for the marketing network:
3 Select Create New to add a VLAN interface for the sales network:
Connecting multiple networks to a FortiGate interface using virtual LANs (VLANs)
Fh
Add security policies to allow each network to access the Internet
1 Go to Policy > Policy > Policy and select Create New to add a security policy that allows users on the engineering network to connect to the Internet.
2 Select Create New to add a security policy that allows users on the marketing network to connect to the Internet.
3 Select Create New to add a security policy that allows users on the sales network to connect to the Internet.
Results Users from any of the networks should be able to connect to the Internet. Go to Policy > Monitor > Policy Monitor to view information about sessions through the FortiGate unit.
Source Interface/Zone Engineering-net
Source Address all
Destination Interface/Zone wan1
Destination Address all
Schedule Always
Service ANY
Action ACCEPT
Source Interface/Zone Marketing-net
Source Address all
Destination Interface/Zone wan1
Destination Address all
Schedule Always
Service ANY
Action ACCEPT
Source Interface/Zone Sales-net
Source Address all
Destination Interface/Zone wan1
Destination Address all
Schedule Always
Service ANY
Action ACCEPT
If users on the networks cannot connect to the Internet, re-check your FortiGate configuration. You can also try the steps described in “Troubleshooting NAT/Route mode installations” on page 20.
Using Virtual Domains to host more than one FortiOS instance on a single FortiGate unit
Using Virtual Domains to host more than one FortiOS instance on a single FortiGate unit
Problem Providing Internet connectivity and security for two private networks with a single FortiGate unit.
Solution Use Virtual domains (VDOMs) to divide the FortiGate unit into two or more virtual instances of FortiOS that function similar to two independent FortiGate units. Each VDOM has its own physical interfaces, routing configuration, and security policies.
This example simulates an ISP that provides Company A and Company B with Internet services. Each company would have its own Internet IP address and internal network. This configuration requires:
• Two VDOMs: VDOM-A and VDOM-B each operating in NAT/Route mode with two interfaces, one for a connection to the Internet and one for a connection to the internal network.
• The routing configuration of the example is simplified to only require a default static route from each VDOM to an Internet gateway router.
Create VDOM-A and VDOM-B
Enable multiple VDOM mode, create the VDOMS, configure interfaces and add them to their VDOMs.
1 Connect to the FortiGate web-based manager and from the Dashboard System Information widget select Enable beside Virtual Domain.
2 Go to System > VDOM > VDOM and select Create New to create two VDOMs with the following configuration:
Using Virtual Domains to host more than one FortiOS instance on a single FortiGate unit
5 Go to System > Admin > Administrators and select Create New to add an administrator for VDOM-B.
Create a basic configuration for VDOM-A
Add a default route, a DHCP server, and security policy to allow company-A users to get their IP configuration from the FortiGate unit, and connect to the Internet.
1 Beside Current VDOM select VDOM-A.
2 Go to Router > Static > Static Route and select Create New to add the default route for VDOM_A.
3 Go to System > Network > DHCP Server and select Create New to add a DHCP server.
4 Configure the DNS Service as required for the network.
5 Select OK to save the port2 DHCP server.
6 Connect a PC to the port2 interface and configure it to get an IP address automatically using DHCP.
7 Log in to VDOM-A by browsing to https://192.168.10.1 and entering a-admin as the Name and passw0rda as the Password.
8 Go to Policy > Policy > Policy and select Create New to create a security policy that allows users on the company A internal network to connect to the Internet.
Using Virtual Domains to host more than one FortiOS instance on a single FortiGate unit
Fh
9 Select Enable NAT and Use Destination Interface Address.
10 Select OK to save the security policy.
11 Test the configuration by connecting to the Internet from the PC.
12 Configure the computers on the company A network to get their IP configuration automatically using DHCP.
Create a basic configuration for VDOM-B
Add a default route, a DHCP server, and security policy to allow company-B users to get their IP configuration from the FortiGate unit, and connect to the Internet.
1 Log in to the FortiGate unit as the admin administrator (or any administrator with the super_admin profile).
1 Beside Current VDOM select VDOM-B.
2 Go to Router > Static > Static Route and select Create New to add the default route for VDOM_A.
3 Go to System > Network > DHCP Server and select Create New to add a DHCP server.
4 Configure the DNS Service as required for the network.
5 Select OK to save the port4 DHCP server.
6 Connect a PC to the port4 interface and configure it to get an IP address automatically using DHCP.
7 Log in to VDOM-B by browsing to https://192.168.20.1 and entering b-admin as the Name and passw0rdb as the Password.
Destination Address all
Schedule always
Service ANY
Action ACCEPT
You should be able to connect to the Internet, if not check the configuration or use the steps described in “Troubleshooting NAT/Route mode installations” on page 20 to find the problem.
Using Virtual Domains to host more than one FortiOS instance on a single FortiGate unit
8 Go to Policy > Policy > Policy and select Create New to create a security policy that allows users on the company B internal network to connect to the Internet.
9 Select Enable NAT and Use Destination Interface Address.
10 Select OK to save the security policy.
11 Test the configuration by connecting to the Internet from the PC.
12 Configure the computers on the company B network to get their IP configuration automatically using DHCP.
Results Connect to the Internet from the company A and company B networks. From either VDOM, go to Policy > Monitor > Policy Monitor and confirm that the policies that you added are allowing traffic through the individual VDOMs.
You can use the packet sniffer to verify that traffic is staying in a VDOM. For example, enter the following command from the FortiGate CLI and then ping from one of the internal networks to an address on the Internet.
diagnose sniffer packet any 'icmp' 4 10interfaces=[any]filters=[icmp]10.728968 port4 in 192.168.20.100 -> 66.171.121.34: icmp: echo request10.729158 port3 out 172.20.120.20 -> 66.171.121.34: icmp: echo request10.821152 port3 in 66.171.121.34 -> 172.20.120.20: icmp: echo reply10.821288 port4 out 66.171.121.34 -> 192.168.20.100: icmp: echo reply11.729230 port4 in 192.168.20.100 -> 66.171.121.34: icmp: echo request11.729431 port3 out 172.20.120.20 -> 66.171.121.34: icmp: echo request11.821349 port3 in 66.171.121.34 -> 172.20.120.20: icmp: echo reply11.821481 port4 out 66.171.121.34 -> 192.168.20.100: icmp: echo reply
The command output shows sessions only uses the port4 and port3 interfaces, both of which are in VDOM-B.
Source Interface/Zone port4
Source Address all
Destination Interface/Zone port3
Destination Address all
Schedule always
Service ANY
Action ACCEPT
You should be able to connect to the Internet, if not check the configuration or use the steps described in “Troubleshooting NAT/Route mode installations” on page 20 to find the problem.
If you log in as an administrator with the super_admin profile, you can sniff any interface. If you log in as a-admin or b-admin (an administrator for a single VDOM), you can only sniff interfaces in the administrator’s VDOM. To access the packet sniffer, you must log in to a VDOM, you cannot access the packet sniffer from the global configuration.
Setting up an administrator account for monitoring firewall activity and basic maintenance
Fh
Setting up an administrator account for monitoring firewall activity and basic maintenance
Problem You want to add a login for an administrator to be responsible for system maintenance, firmware updates and general monitoring and logging of the FortiGate unit for reporting purposes, but don’t want them to have full configuration access.
Solution Create a new admin profile that only allows the administrator to view and maintain configuration options, and viewing and configuring log information and reports. Create an administrative user, Terry White, with the monitoring profile.
1 Go to System > Admin > Admin Profile and select Create New.
2 Enter the Profile Name of maint_monitor and set the following settings to Read-Write:
• FortiGuard Update
• Maintenance
• Log & Report
3 Go to System > Admin > Administrators and select Create New to add the following administrator:
Results Log in to the FortiGate using the user name of Terry_White and the password of password. When logged in, the web-based manager menus and sub-menus related to the access control you configured appear. The OK or Apply buttons will not appear in settings that may be editable on a Read-Write page.
Administrator Terry_White
Type Regular
Password password
Confirm Password password
Admin Profile maint_monitor
The admin profile dictates what of the FortiGate configuration the administrator can see and configure from web-based manager and CLI. You can add multiple profiles and assign users and administrators different profiles depending on what they are tasked to do with the FortiGate unit.
Setting up an administrator account for monitoring firewall activity and basic maintenance
To confirm that Terry White has logged in successfully, from the FortiGate web-based manager go to Log&Report > Event Log to see the login message in the Action column.
Select the log entry to view the detailed information, which indicates the admin user connected. The Message row indicates that Terry White connected successfully from 192.168.1.1. The Profile Name row also indicates the admin profile in use.
Go to System > Dashboard > Status, and look at the System Information widget. In the Current Administrator row, it will indicate the number of administrators logged in.
Selecting Details shows the information of Terry White logged in as an administrator.
Creating a local DNS server listing for internal web sites and servers
FortiOS 4.0 MR3 85 http://docs.fortinet.com/
Creating a local DNS server listing for internal web sites and servers
Problem Keeping DNS traffic for company server lookups off of the Internet and on the internal network.
Solution On a FortiGate unit, enable DNS databases, create an internal DNS database with the IPs/names/URLs of internal sites, and enable the DNS server on the FortiGate internal interface. Configure the internal network to use the FortiGate internal interface as the authoritative DNS server. This way, when internal users request a URL, the FortiGate unit will look to its internal DNS. To lookup external names, the FortiGate unit forwards DNS requests to external DNS servers.
1 Go to System > Admin > Settings, select DNS Database and select Apply.
2 Go to System > Network > DNS Server and select Create New to add a new DNS Database:
3 Select OK to save this DNS database.
4 To add DNS Entries, select Create New and enter the name and IP address of an internal site:
5 Select OK to save this DNS database.
6 Go to System > Network > DNS Server and select Create New under DNS Service on Interface to configure the mode for queries to the DNS database received at the Internal interface.
7 Select OK to save the DNS service mode for the internal interface.Results To verify that the DNS database is being used, go to System > Network > DNS and
temporarily remove the primary and secondary DNS server settings. That is, leave them empty, and browse to the http://info.company.com web site. The web site will appear, while surfing to any other site will not work. This shows that the FortiGate unit is using its internal DNS database to resolve the configured web site.
The DNS server setting on the devices on the internal network must use the FortiGate internal interface as their DNS server.
Assigning IP addresses according to a MAC address using DHCP
86 FortiGate Cookbook http://docs.fortinet.com/
Assigning IP addresses according to a MAC address using DHCP
Problem Ensure that certain users or PCs always have the same IP address when the FortiGate unit assigns addresses using DHCP.
This feature can be used to ensure that certain users can always connect to the network, or to track Internet usage by IP address even if IP addresses are assigned automatically by the FortiGate DHCP server.
Solution If you have an existing DHCP server enabled on the FortiGate unit, enable IP reservation within the DHCP service settings and then add the MAC addresses of PCs that you want to always get the same IP address.
1 Go to System > Network > DHCP Server and Edit the DHCP server.
2 Select IP Reservation and select Create New and add a MAC IP address pair:
Results The PC will always acquire the reserved IP address from the FortiGate DHCP server.
Verify that the PC has acquired the correct IP address by viewing its IP configuration or status. For example, from a command prompt, you may be able to enter the command ipconfig/all.
From the FortiGate web-based manager, go to System > Monitor > DHCP Monitor to view the list of PCs that are using the DHCP server to acquire IP addresses. The PC with the reserved address will appear with an “R” next to the address.
IP 10.10.10.18
MAC Address 00:13:72:38:6a:39
The IP address must be within the range defined by the DHCP server.
If the PC is already connected and has acquired an IP address from the DHCP server, you can set get its MAC address and IP address by selecting Add from DHCP Client List. When the list appears, select the PC from the list and select Add To Reserved.
If you do not see the PC in the DHCP Monitor or if the “R” icon is not visible, you may need to either restart the PC, or renew its IP configuration.
Problem You want to receive SNMP traps (or event notifications) when a FortiGate unit experiences system events, like high CPU usage, low log disk space, or UTM events such as a virus being detected, IPS detecting an attack and so on.
Solution Enable SNMP to collect SNMP v1/2c traps for the status of the FortiGate unit.
1 Go to System > Config > SNMP and select Enable to enable the FortiGate SNMP agent.
2 Configure the agent as follows:
3 Select Apply to save the configuration and start the FortiGate SNMP agent.
4 Select Create New for SNMP v1/c2c.
5 Enter the Community Name of Example Company.
6 Add the IP address of a Host that can receive SNMP traps by selecting Add under Hosts.
7 Set the IP Address/Netmask to 192.168.1.10/255.255.255.0 and the Interface to internal.
How do I get FortiGate MIBs?
There are two MIB files for FortiGate units - the Fortinet MIB, and the FortiGate MIB. The Fortinet MIB contains traps, fields and information that is common to all Fortinet products. The FortiGate MIB contains traps, fields and information that is specific to FortiGate units.
The two FortiGate MIB files are available on the Fortinet Customer Support web site. The Fortinet MIB contains information for Fortinet products in general. the Fortinet FortiGate MIB includes the system information for FortiGate unit and version of FortiOS. Both files are required for proper SNMP data collection.
1 Login to the Customer Support web site at https://support.fortinet.com.
2 Go to Download > Firmware Images.
3 Log in using your Fortinet account.
4 Select FortiGate > v4.00 > Core MIB.
5 Select and download the FORTINET-CORE-MIB.mib file.
6 Move up one directory level.
7 Select the firmware version, revision and patch (if applicable).
8 Select the MIB directory.
9 Select and download the FORTINET-FORTIGATE-MIB.mib file.
You can also set the IP address/Netmask to 0.0.0.0/0.0.0.0 and the Interface to ANY so that any SNMP manager at any network connected to the FortiGate unit can use this SNMP community and receive traps from the FortiGate unit.
You can also use local-in policies to provide further access control for all management traffic, including SNMP traffic. For example, you could use the following local-in policy to allow SNMP access to the internal interface from the address range 172.20.120.100 - 172.20.120.110:
Results Configure the SNMP manager at 192.168.1.10 to receive traps from the FortiGate unit. The do something to trigger a trap, for example, change the IP address of a FortiGate interface. Verify that the SNMP manager receives the trap.
You can also send a trap by enabling antivirus in a security policy and try downloading an eicar test file from http://eicar.org. This will trigger a Virus detected event, sending a trap. You can also view the UTM log by going to Log&Report > Log & Archive Access > UTM Log.
Troubleshooting by sniffing packets (packet capture)
Fh
Troubleshooting by sniffing packets (packet capture)
Problem I hear packet sniffing is used for troubleshooting network problems, but I don’t know how.
Solution When troubleshooting networks, it helps to look inside the header of the packets. This helps to determine if the packets, route, and destination are all what you expect. Packet sniffing can also be called a network tap, packet capture, or logic analyzing.
When to use packet sniffing
Packet sniffing tells you what is happening on the network at a low level. This can be very useful for troubleshooting problems, such as:
• finding missing traffic
• seeing if sessions are setting up properly
• locating ARP problems such as broadcast storm sources and causes
• confirming which address a computer is using on the network if they have multiple addresses or are on multiple networks
• confirming routing is working as you expect
• wireless client connection problems
• intermittent missing PING packets
• a particular type of packet is having problems, such as UDP, which is commonly used for streaming video
What sniffing packets can tell you
If you are running a constant traffic application such as ping, packet sniffing can tell you if the traffic is reaching the destination, how the port enters and exits the FortiGate unit, if the ARP resolution is correct, and if the traffic is returning to the source as expected. You can also use packet switching to verify that NAT or other configuration is translating addresses or routing traffic the way that you want it to.
Before you start sniffing packets, you need to have a good idea of what you are looking for. Sniffing is used to confirm or deny your ideas about what is happening on the network. If you try sniffing without a plan to narrow your search, you could end up with too much data to effectively analyze. On the other hand, you need to sniff enough packets to really understand all of the patterns and behavior that you are looking for.
You can find more examples of packet sniffing throughout this document.
How to sniff packets
The sniffer command is CLI-only. and the syntax is:
Troubleshooting by sniffing packets (packet capture)
Sniffer output description for TCP packets
A simple example:
# diag sniffer packet internal none 4 3
This command looks for all packets on the internal interface and returns the packet headers with interface names attached for first three packets. Three packets was selected for this example so the output would not overwhelm you. During normal troubleshooting, you will want to capture a larger number of packets to get a better picture of the network. Also note that if you run this command you will not see the same three packets listed here, but they will have similar information displayed.
internal in 192.168.0.1.22 -> 192.168.0.30.1144: psh 2859918764 ack 1949135261internal in 192.168.0.1.22 -> 192.168.0.30.1144: psh 2859918816 ack 1949135261internal out 192.168.0.30.1144 -> 192.168.0.1.22: ack 2859918884
From the look of these packets they are part of a TCP SSH exchange. Let’s look at the first packet sniffed:
internal in 192.168.0.1.22 -> 192.168.0.30.1144: psh 2859918764 ack 1949135261
The sniffer displayed the following info about the first packet:
• internal the FortiGate interface where the packet was found.
• in the direction of the packet at the interface for inbound.
• 192.168.0.1.22 the IP address with port number of the packet source (a source IP of 192.168.0.1 with the source port number 22, which is generally associated with SSH).
• 192.168.0.30.1144 the IP address with port number of the packet destination (a destination IP of 192.168.0.30 with the destination port number 1144).
• psh one of the nine flags from TCP headers (ns, cwr, ece, urg, ack, psh, rst, syn, fin). psh stands for push function, which asks to push the buffered data to the receiving application.
• 2859918764 the TCP sequence number. The sequence number, which starts with 285, is incrementing by small amounts over the three sniffed packets.
• ack the acknowledgement flag is set.
{ ‘filter_str’ | none }
Only packets that include the text in the filter will be displayed. The filter can include logical statements such as and or or.
none indicates no filtering, and all packets will be displayed as the other arguments indicate.
The filter must be inside single quotes (‘).
{1 | 2 | 3 | 4 | 5 | 6}
The level of verbosity.
1 - header of packets
2 - header and data from IP of packets
3 - header and data from Ethernet of packets
4 - header packets with interface name
5 - header and data from IP of packets with interface name
6 - header and data from Ethernet packets with interface name.
The default level of verbosity is 1.
< pkt_count >The number of packets the sniffer displays before stopping.
If you do not put a number here, the sniffer will run forever until you stop it by pressing Ctrl+C.
Troubleshooting by sniffing packets (packet capture)
Fh
• 1949135261 the acknowledgement number. If ACK is set, this is the next sequence number the receiver is expecting, in effect acknowledging all prior bytes.
You will notice from this description that, after the IP and port information, all the information is TCP specific. This information will change, depending on the type of packet (tcp, arp, udp, ip, gre, etc.). Regardless of how in-depth you need the information to give you, you need to be familiar with the packet header structure for your type of packets.
Sniffing icmp (ping) packets
This example sets up a computer to ping the internal interface of the FortiGate unit non-stop and sniff for icmp packets on the internal interface.
From any computer run a continuous ping to IP address 172.20.120.136 and on the FortiGate CLI enter the following command:
# diag sniffer packet internal 'icmp' 4 5interfaces=[any]filters=[icmp]16.776272 internal in 172.20.120.17 -> 172.20.120.136: icmp: echo request16.776462 internal out 172.20.120.136 -> 172.20.120.17: icmp: echo reply17.777280 internal in 172.20.120.17 -> 172.20.120.136: icmp: echo request17.777360 internal out 172.20.120.136 -> 172.20.120.17: icmp: echo reply18.778176 internal in 172.20.120.17 -> 172.20.120.136: icmp: echo request
This output captured the 16th, 17th, and 18th ping echo requests that were sent out from 172.20.120.17, and the 16th and 17th replies from the FortiGate unit. You can tell this from the number at the start of each line — the 16, 17, or 18, which indicates the packet number and sequence. It is useful to check this number to see if you are dropping packets. The echo or echo reply tells you which direction the packet is travelling without the IP address. Note that there is no other information displayed because icmp packets carry very little information.
Verbosity level on a random UDP packet
So far, the verbosity level has only determined if interface information is shown or not. However, it can also be used to display the content or payload of the packets. This is useful if you have packets with headers inside packets, or other specific plain text information you can read from the packets.
The TCP flag and sequence information is displayed because verbosity level 4 was selected. This information can be useful to ensure that all the traffic for a session is reaching its destination, and that the session was properly established.
Ensure that ping administrative access is enabled on the internal interface; otherwise, you will not be able to see the output shown below.
If you have icmp packets from other sources showing up in your sniffing, you can add a basic filter to select only packets to or from 172.20.120.17. To do this, the sniffer command would become: diag sniffer packet any ‘icmp and host 172.20.120.17’ 4 5. Filtering is described in more detail in “Advanced troubleshooting by sniffing packets (packet capture)” on page 94.
This packet is going out on the wan1 interface, using port 60718. Its destination is 8.8.8.8 using port 53. All six lines of output are for a single packet, and this is a small packet. TCP packets are much larger. The IP address 8.8.8.8 is Google’s public DNS address. UDP port 53 is used for DNS lookups, and FortiGuard communications. In this case, it seems safe to say its a DNS lookup. If we look at the payload for the packet, we can see the address ars.exmpl.aol.com, which appears to be a domain name to be resolved.
Examining DNAT HTTP packets
Here is a practical example to show how this all comes together. Sniffing can show you what NAT is taking place instead of you guessing. Test destination NAT by browsing to http://172.20.120.14 from the Internet. The session passes through the FortiGate unit to the web server which sends a response. Use the following packet sniffer command to see the results.
diagnose sniffer packet any 'port 80' 4 4interfaces=[any]filters=[port 80]6.150356 wan1 in 172.20.120.12.51439 -> 172.20.120.14.80: syn 15893888 6.150637 internal out 172.20.120.12.51439 -> 192.168.1.110.80: syn 15893888 6.150803 internal in 192.168.1.110.80 -> 172.20.120.12.51439: syn 553485227
ack 15893889 6.150974 wan1 out 172.20.120.14.80 -> 172.20.120.12.51439: syn 553485227 ack
15893889
The first output line shows a packet from a client device with IP address 172.20.120.12 was received by the wan1 interface with destination address 172.20.120.14 and destination port 80.
The second output line shows that when the packet exits the internal interface the destination address is changed to 192.168.1.110 and the destination port is still 80.
The third output line shows the response from the web server.
The fourth output line shows the response from the web server being returned to the client device. The source address has been changed back to 172.20.120.14.
In this example, the source port is not changed.
Best Practices
Here are some tips that will improve your troubleshooting when using the sniffer.
• Always log output to a file that you can search, sort, and process later. You can also send the output log to Fortinet support to assist them in solving your issue.
• Visualize the path you expect the packets in question are using. It will help you write your sniffer command more accurately and reduce your troubleshooting.
• If you are not getting the results you expect, broaden your search parameters. Its possible things are behaving differently than you expect.
Troubleshooting by sniffing packets (packet capture)
Fh
• You need to know the details about the packet type you are sniffing to maximize the benefits. Otherwise there will be useful information you do not understand in the sniffing results.
• Keep your connection method in mind when sniffing packets. If you are web browsing to the FortiGate unit, web protocol packets may be affected. If you are using Telnet to connect, those packets will affect the sniffing results.
• If you are sniffing VLAN packets, any configured filter will stop VLAN tags from being displayed.
Advanced troubleshooting by sniffing packets (packet capture)
Advanced troubleshooting by sniffing packets (packet capture)
Problem How do I use filters for sniffing? They are really confusing.
Solution You can perform some basic packet sniffing and network troubleshooting without using packet sniffing filters. However, with filters, you can fine tune your troubleshooting to the point of being able to find a specific ping packet on a busy network.
When packet sniffing, the filter field is very flexible. By using the filter option, you can:
• match the source hostname or IP address
• match the type of packet (arp, ip, gre, esp, udp, tcp, icmp)
• match the port number
• logically AND or OR parts of the filter with each other
Let’s look at each of the different parts to the filter. Keep in mind that in addition to these formats, you can also search for individual words using the filter. The following are examples.
IP matching with filters
Let’s look at the hostname and IP matching — [[src|dst] host <host_name_or_IP1>]. It allows you to specify either the source or destination host. For example if you want to sniff packets coming from IP address 192.168.1.27 you would set the filter to ’src host 192.168.1.27’. If you want to sniff packets going to a computer called my_laptop, the filter would be ’dst host my_laptop’. This host name is resolved using DNS.
In each case, when the sniffer finds packets from that computer, the packets will match the filter and be displayed. You can enter two or more different computers using this format and join them with logical ANDs or ORs. For example, you could specify one source and two destinations.
In the following example, let’s assume a computer on the network is pinging the FortiGate unit. We will only be looking for ping packets with a source of 172.20.120.136 which is the FortiGate unit.
Advanced troubleshooting by sniffing packets (packet capture)
Fh
The result displays four packets, all ping (icmp) packets, originating from the FortiGate unit and going to 172.20.120.17. This time there was no verbosity level indicated or number of packets. A default verbosity level 1 is used, and the sniffing continues until you press Ctrl-C to stop it. Note that the last two lines tell you how many packets were sniffed and if the FortiGate kernel dropped any packets during this time.
Sniffing a port and specifying multiple hosts using AND and OR operators
When a TCP session is created, the destination port is set to a known port number — for example, port 80 is commonly used for HTTP sessions. But the source port is randomly assigned. The unknown source port can make troubleshooting difficult. However, the FortiGate packet sniffer can match the known port if it is the source or destination port — you do not need to know which port.
Let’s check HTTP packets going between IP 172.20.120.18 (the FortiGate) and on either 10.10.80.110 (wifi interface called Star) or 10.10.10.100 (internal LAN interface).
diag sniffer packet any "port 80 and host 172.20.120.18 and (host 10.10.80.110 or host 10.10.10.100)" 4
interfaces=[any]filters=[port 80 and host 172.20.120.18 and (host 10.10.10.100 or host 10.10.80.110)]5.036340 internal in 10.10.10.100.58753 -> 172.20.120.18.80: syn 4189154 5.036664 internal out 172.20.120.18.80 -> 10.10.10.100.58753: syn 1354149395 ack 4189155 6.464015 Star out 172.20.120.18.80 -> 10.10.80.110.56791: syn 2000204115 ack 571678006 6.471966 Star in 10.10.80.110.56791 -> 172.20.120.18.80: ack 2000204116 6.474720 Star in 10.10.80.110.56791 -> 172.20.120.18.80: psh 571678006 ack 2000204116 5.036837 internal in 10.10.10.100.58753 -> 172.20.120.18.80: ack 1354149396 5.037023 internal in 10.10.10.100.58753 -> 172.20.120.18.80: psh 4189155 ack 1354149396 6.463686 Star in 10.10.80.110.56791 -> 172.20.120.18.80: syn 571678005
Since either the source or destination will be using port 80, all HTML traffic between those two computers will match the filter and be displayed. SSH and HTTPS traffic uses different ports, so that traffic will not be displayed. The first number of each line of output will vary between sources and is a good way to quickly determine which IP addresses are in that session.
Packet type filters
Let’s look at the packet type — [arp|ip|gre|esp|udp|tcp]. This determines what type of packets to look for. In addition to the common ICMP, IP, TCP, and UDP you can look for ARP (address resolution protocol), GRE (generic routing encapsulation), and ESP (encapsulating security payload) packets.
Let’s sniff some ARP packets from a gateway on the network at IP address 172.20.120.2. For this we don’t care about the interface, and five packets will be enough to see what is happening.
When the sniffing has ended, if you see anything but zero packets dropped, you may have a problem. Packets dropped indicates the FortiGate unit was not able to sniff and display all the packets that were coming in. If you were looking for all the packets in a sequence, there may well be packets missing. For this reason, you should consider possible reasons for those dropped packets, attempt to fix the problem so all packets are captured, and run the sniffer again. Keep in mind that the sniffer can take up to 25% of the CPU resources on smaller FortiGate units.
If the protocol you want isn’t listed here you can specify it if you know the ethernet protocol number for it. For example to specify ARP packets on the internal interface with this method: diag packet sniffer internal “ether proto 0x0806”
From this output, we can see ARP requests from a computer with IP address 192.168.100.99 that is looking for the MAC address of a computer with the IP address 192.168.100.1. In the ARP protocol, the who-has request is broadcast and includes the link layer address of where to send the reply. The expected response, when a computer has the 192.168.100.1 IP address, will be in the format arp reply 192.168.100.1 is at 00:26:b9:00:0f:9c. Since there is no such reply in the sniffed packets, we can either sniff more packets or assume there is no computer on the network with the IP address 192.168.100.1. This may be important if a computer is supposed to be using that IP address and is not. It could imply DHCP problems, or that the computer was physically moved to a different part of the network.
Miscellaneous advanced filters
There are some non-standard filters you can use to match traffic with the packet sniffer. These advanced filters use logical symbols to match specific bits within packet headers. Some examples are:
If you want to match TTL = 1 in the packet headers on port2:
# diagnose sniffer packet port2 “ip[8:1] = 0x01”
If you want to match packets with a source IP address of 192.168.1.2 in the header:
The source and destination information are stored in different places in the packet headers. If you want to match packets with a source MAC address of 00:09:0f:89:10:ea on the internal interface
# diagnose sniffer packet internal "(ether[6:4]=0x00090f89) and (ether[10:2]=0x10ea)"
where matching packets with the same MAC address as a destination MAC on the internal interface is
# diagnose sniffer packet internal "(ether[0:4]=0x00090f89) and (ether[4:2]=0x10ea)"
You can also target specific types of packets, such as addressing the TCP or UDP flags.
If you want to match packets with RST flag set:
ARP packets can be the source of problems if there is a network loop. As mentioned above, ARP tries to match a single MAC address to a single IP address. If the request results in two or more replies with the same IP address, or different IP addresses have the same MAC address, as may happen with virtual networking solutions, the loop or asymmetric routing is created. Essentially, all traffic will go to and from both computers. This will appear as a network slowdown or halt. You can see this happening if you are sniffing ARP packets and seeing the double replies or double MAC addresses. To confirm that this is the issue, enter the CLI command config system settings, set asymroute enable, end. This will turn on asymmetric routing, stop these ARP problems, and disable stateful inspection. Disabling stateful inspection will compromise security, so in most cases you should only use this command to confirm a problem. Once the problem is confirmed, use the sniffer output to find and fix the source and then disable asymmetric routing.
If you want to match packets with the SYN-ACK flag set:
# diagnose sniffer packet internal "tcp[13] = 18"
Best practices
Here are some tips that will improve your troubleshooting using the packet sniffer.
• Enabling the sniffer will consume additional CPU resources. This can be as high as an additional 25
• percent of CPU usage on low-end models. Therefore, enabling this on a unit that is experiencing excessively high CPU usage, can only render the situation worse. If you must perform a sniff, keep the sniffing sessions short and keep the filter specific.
• Try to always include ICMP in the sniffer filter. You may capture an ICMP error message that can help identify the cause of the problem. For example:diag sniff packet interface wan1 'tcp port 3389 or icmp' 3
• Use the “any” interface to sniff all FortiGate unit interfaces. You can use the "any" interface if you want to confirm that a specific packet is sent and received by different FortiGate interfaces. The any interface is also useful if you are not sure which interface will send or receive the packet. An example using the “any” interface:diag sniff packet any 'tcp port 3389' 3
• The FortiGate unit may not display all packets if too much information is requested. When this occurs, the FortiGate unit will log the following message once the trace is terminated:
12151 packets received by filter
3264 packets dropped by kernel
When this occurs, it is possible that what you were attempting to capture, was not actually captured. In order to avoid this, try to make the filters more specific, reduce the verbosity level, or run the sniffer during a lower traffic period.
• The packet timestamps, as displayed by the sniffer, may become skewed or delayed under high load conditions. This may occur even if no packets were dropped. Therefore, it is not recommended that you rely on these values in order to troubleshoot or measure performance issues that require absolute precise timing.
• Short Ethernet frames sent by the FortiGate unit may appear to be under the minimum length of 64 bytes (also known as runts) and will not be displayed by the sniffer. This is because the sniffer does not display any Ethernet Trailer/Padding information, although it is sent over the network.
• The Ethernet source and/or destination MAC addresses may be incorrect when using the "any" interface. They may be displayed as all zeros (00:00:00:00:00:00) or 00:00:00:00:00:01.
• Try to always include ICMP in the sniffer filter. You may capture an ICMP error message that can help identify the cause of the problem. For example, diag sniff packet interface wan1 'tcp port 3389 or icmp' 3
• If you are sniffing VLAN packets, you cannot have any filter configured if you want to see the VLAN tags. For example diag sniffer packet wan1 “icmp” will not show the tags where diag sniffer packet wan1 will.
If your FortiGate unit has NP2 interfaces that are offloading traffic, this will change the sniffer trace. Before performing a trace on any NP2 interfaces, you should disable offloading on those interfaces.
Creating, saving, and using packet capture filters (sniffing packets from the web-based manager)
Creating, saving, and using packet capture filters (sniffing packets from the web-based manager)
Problem To capture, download, and analyze packets received or sent by a FortiGate unit.
Solution Packet capturing or packet sniffing through the web-based manager is a new feature for FortiOS 4.0 MR3 Patch 2. From the web-based manager you can go to System > Configure > Advanced and under Packet Capture select Create New to create and save packet capture filters. Packet capture filters contain saved packet sniffer settings that define the packets to capture.
You can start a packet capture filter any time when you want to capture the packets defined in the filter. Results of running a packet capture filter can be download to your computer for viewing and analysis as a pcap file. The pcap file contains complete details about the packets captured, including packet content. To read a pcap file, open it with an application that can read pcap files, for example, tcpdump or Wireshark.
Capturing HTTP packets on the Internal interface
The following filter captures 100 HTTP packets (destination port 80) received at the FortiGate internal interface with destination address 66.171.121.34, from any source address on the 192.168.1.0/24 network, and with any source port.
1 Go to System > Config > Advanced > Packet Capture, select Create New and create a packet capture filter to capture HTTP packets sent and received by the internal interface from and IP address on the 192.168.1.0 network to IP address 66.171.121.34:
2 Select OK.
3 Start capturing packets by selecting the packet capture filter and selecting Start.
You can also Edit the packet capture filter and select Start Capture.
4 From a PC with an IP address on the 192.168.1.0/24 network browse to 66.171.121.34.
You can view the packet capture progress, which stops when 100 packets are captured. You can also Stop capturing packets at any time. If you select Start to restart capturing packets, the packet count is reset, so packets previously saved are lost.
5 To download captured packets, stop packet capture if its still running, select the packet capture filter, select Download, and open or save the downloaded sniffer-internal.pcap file. (The filename includes the interface name specified in the filter.)
Creating, saving, and using packet capture filters (sniffing packets from the web-based manager)
Fh
6 View the downloaded pcap file with a pcap file viewer.
The output below shows packets with source address 192.168.1.120 and destination address 66.101.121.34 and destination port 80 received by the FortiGate internal interface.
Capturing packets to show static source NAT
As described in “Providing Internet access for your private network users (static source NAT)” on page 160 you can use the packet sniffer to verify your NAT configuration. This example shows how to create a packet capture filter to verify basic source NAT in the same way as entering the command diagnose sniffer packet any 'port 80' 4 4.
1 Go to System > Config > Advanced.
2 Under Packet Capture, select Create New and create a packet capture filter to capture all HTTP packets sent or received by any interface:
The packets in the pcap file do not include the FortiGate interface name. In this example all of the packets are received and sent by the internal interface. If you set the Interface to ANY; however, the pcap file will contain packets from any FortiGate interface. You can use the hardware address to determine which FortiGate interface received or sent the packet.
Creating, saving, and using packet capture filters (sniffing packets from the web-based manager)
3 Select OK.
4 Start capturing packets by selecting the packet capture filter and selecting Start.
You can also Edit the packet capture filter and select Start Capture.
5 From a PC with on the internal network browse to any Internet address.
You can view the packet capture progress, which stops when 100 packets are captured.
6 To download captured packets, stop packet capture if its still running, select the packet capture filter, select Download, and open or save the downloaded sniffer-any.pcap file.
7 View the downloaded pcap file with a pcap file viewer such as Wireshark.
The first line below shows a packets with source address 192.168.1.110 and destination address 172.20.120.101 sent by a PC. The second line shows the same packet with source address changed to 172.20.120.14 exiting the FortiGate wan1 interface.
Source Address 0.0.0.0/0.0.0.0
Source Port(s)
Destination Address 0.0.0.0/0.0.0.0
Destination Port 23
Protocol ALL
Include IPv6 Packets Disable
Capture Non-IP Packets Disable
This packet capture filter may capture many more packets than the ones you are looking for. You reduce the number of packets captured by specifying the source and destination addresses of the packets that you are interested in.
Problem I’m having problems configuring my FortiGate unit. I’ve heard of debug commands, how do I use them?
Solution FortiGate units have built-in diagnose debug commands that can be used to debug the operation of any FortiGate software system by displaying debug messages on the CLI console as the system operates. When you find the problem you can correct the configuration and run the diagnose debug command again to verify that the system now operates correctly.
To use the diagnose debug commands you must check the current debug configuration, enable debugging, select a software system for which to display debugging information, collect and analyze the results, and stop displaying debugging information. In general you can follow this command sequence:
• diagnose debug reset to reset the debug configuration to a default state.
• diagnose debug report Fortinet support may ask you to run this command and send them the output.
Example diagnose debug procedure for an SSL VPN portal
This procedure describes typical steps for displaying debug information for the SSL VPN configuration described in “Setting up remote web browsing for internal sites through SSL VPN” on page 214. You can use similar steps to display debug info for many other software systems.
1 Verify the current debug configuration by entering the following command:diagnose debug info debug output: disableconsole timestamp: disableconsole no user log message: disableCLI debug level: 3
Before performing any debugging, you should connect to the FortiGate CLI with a terminal program that supports storing the output to a file for later reference. If you do not save the output to a file, you will miss valuable debugging information.
Keep in mind that debugging consumes system resources and may affect performance. In most cases this will not be a problem, but if your FortiGate unit is running at 100 percent resource usage already, it is likely that running the debug application will cause the FortiGate unit to drop more packets or sessions, and generally increase its overloaded behavior. The worst is when you are sniffing packets, which can use 10 percent or more of the system resources.
This is an exhaustive report that runs many different diagnose commands to gather a large amount of information. It may take up to 20 minutes to run on a FortiGate unit with a complex configuration and may temporarily affect system performance.
This is a good command to run first, so you know what filters are in place and so on; otherwise, you may start debugging and wonder why the output is not what you expected. This output above indicates that debug output is disabled so debug messages are not displayed. The output also indicates that debugging has not been enabled for any software systems.
2 Enter the following command to display debug messages for SSL VPN. diagnose debug application sslvpn -1
This command enables debugging of SSL VPN with a debug level of -1. The -1 debug level produces detailed results.
3 Enter the following command to verify the debug configuration:diagnose debug info debug output: disableconsole timestamp: disableconsole no user log message: disablesslvpn debug level: -1 (0xffffffff)CLI debug level: 3
This output verifies that SSL VPN debugging is enabled with a debug level of -1.
4 Enable displaying debug messages by entering the following command:diagnose debug enable
5 Log into the SSL VPN portal. The CLI displays debug messages similar to the following. diagnose debug enable
FGT60C3G10002814 # [282:root]SSL state:before/accept initialization (172.20.120.12)[282:root]SSL state:SSLv3 read client hello A (172.20.120.12)[282:root]SSL state:SSLv3 write server hello A (172.20.120.12)[282:root]SSL state:SSLv3 write change cipher spec A (172.20.120.12)[282:root]SSL state:SSLv3 write finished B (172.20.120.12)[282:root]SSL state:SSLv3 flush data (172.20.120.12)[282:root]SSL state:SSLv3 read finished A:system lib(172.20.120.12)[282:root]SSL state:SSLv3 read finished A (172.20.120.12)[282:root]SSL state:SSL negotiation finished successfully (172.20.120.12)[282:root]SSL established: DHE-RSA-AES256-SHA SSLv3 Kx=DH Au=RSA Enc=AES(256)
Mac=SHA1
Just the first few messages are shown for an SSL VPN user connecting to the portal from IP address 172.20.120.12. The messages show the connection being accepted and SSL VPN negotiation taking place.
You can view and analyze the debug messages or save them to a text file using your terminal program.
6 Enter the following command to stop displaying debug messages:diagnose debug disable
If there is a lot of output scrolling by quickly, you may not be able to see the command as you enter it.
Debugging authentication
Any time a FortiGate unit authenticates a user, the authd daemon is responsible. This is true if the user is logging in through SSL VPN, connecting over IPsec VPN from FortiClient, and even if certificates are involved. You can use the following command to debug authentication:
authd_http.c:1910 authd_http_connect: calledauthd_http.c:3071 authd_http_change_state: calledchange state to: 3authd_http.c:1112 authd_http_read: calledauthd_http.c:2383 authd_http_wait_req: calledauthd_http.c:2443 authd_http_read_req: calledauthd_http_common.c:276 authd_http_read_http_message: calledauthd_http_common.c:229 authd_http_is_full_http_message: calledauthd_http.c:4899 authd_http_on_method_get: calledauthd_http.c:2098 authd_http_check_auth_action: calledauthd_http.c:3071 authd_http_change_state: calledchange state to: 2
The output shows the messages the authentication daemon is receiving and the resulting state changes. This authentication session was between a FortiGate unit and FortiClient during an IPsec VPN session setup.
Debugging IPsec VPN
You can use the diag debug application ike -1 command to display all the VPN related traffic, especially for initial negotiations. By doing this, it will give you the information to find and fix errors that you would only be guessing at, otherwise. You can find more details about this command and its output in “My IPsec VPN tunnel isn’t working” on page 249.
Debugging URL filtering
Have you tried to set up URL filters only to have the URLs still come through? The diag debug information can help you determine what is going on “under the hood”, such as “Blocking all web sites except those you specify using a whitelist” on page 197.
For example, if one user at 172.20.120.18 is complaining the URL filter is not working for them you can enter the command:
This is very useful if you want to test some new URL filter patterns. The following sample output from this set of commands for a group of URLs that you have included in the UTM Web Filtering Advanced Filtering list, such as *.ro, would appear as:
This output shows one attempt to browse to http://www.example.ro, which is a match to the blocked *.ro sites. From this output, we can see the URL, who was going there (the client IP address of 10.10.80.110), and the action - URL filter deny action. It is good to note that the ID number will increment by one for each message matched like this. From this information, we now know the *.ro URL filter is working properly for a client on the 10.10.80.0 subnet.
Debugging packet flow
You can use the diag debug flow command to show packet flow through the FortiGate unit. As packets are received, you can view debug messages to show how the FortiGate unit processes them. For more information, see “Verifying that traffic is accepted a security policy” on page 144.
FortiOS diagnose commands, commonly called diag commands, are powerful CLI commands that allow you to see what is happening at a low level. You can find more information about diag and get commands in the Troubleshooting chapter of the FortiOS Handbook.
To find out more information about diagnose command options, enter the command followed by a ?, for example, diagnose debug application ?
debug application
Display detailed debugging information for FortiGate software systems. For example:
diagnose debug application ike -1For debugging IPsec VPN, see “My IPsec VPN tunnel isn’t working” on page 249.
diagnose debug application sslvpn -1For debugging IPsec VPN, see “Debugging FortiGate configurations” on page 101.
diagnose debug application urlfilter -1For debugging URL filtering, see “Debugging FortiGate configurations” on page 101.
debug flow Show packet flow through the FortiGate unit. As packets are received you can view debug messages to show how the FortiGate unit processes them. The following commands will send 100 packets of output to the console of the packet flow including the IP address.
See “Verifying that traffic is accepted a security policy” on page 144.
debug info Display information about how debug is currently configured on your FortiGate unit. Run this before doing a series of diag debug commands, so you know what filters are in place. Otherwise, your output may not what you expected. See “Debugging FortiGate configurations” on page 101.
firewall statistic show
Display throughput information for the firewall broken down by both packets and bytes. Categories include common applications such as DNS, FTP, IM, P2P, and VoIP and also includes the lower level protocols — TCP, UDP, ICMP, and IP.
fortitoken drift
Display the drift for each configured FortiToken registered on the FortiGate unit.
hardware certificate
Verify all FortiGate unit certificates. For each certificate the name, test performed and the results are listed.
Display all disks in the FortiGate unit. This includes hard disks, and SSD disks. The information includes partitions, size, type, and available space.
hardware deviceinfo nic eth0
Display information about the network card attached to the interface. The information displayed varies by the type of NIC. It will include the VLAN id, state, link, speed, counts for received and transmitted packets and bytes. The MAC for this NIC is Current_HWaddr and Permant_HWaddr, and this is only place you can see both the old and new MAC when it is changed.
ips urlfilter status
Display statistics for URL filters. This includes number of requests, responses, pending responses, errors, timeouts, blocked, and allowed.
netlink brctl list
Display the information from the bridging table in the FortiGate unit. This is useful when troubleshooting transparent mode. Once you have the bridge names, you can check their forwarding domain using diag netlink brctl domain <bridge_name>.
sniffer packet any “port 80” 4
Capture packets on any FortiGate interface that are on port 80, commonly used by HTTP. Verbosity level 4 displays packet header information and interface names. You can use this information to test security policies, network connections, or find where missing packets are going. See “Troubleshooting by sniffing packets (packet capture)” on page 89.
sys session full-stat
Display details about the session table including its size, the sessions in each state, errors, and other statistics.
test log Generate default log messages. This allows you to test logging features such as remote log server connections. See “Creating a backup log solution” on page 275
test update info
Display information about the update daemon including the last set of messages from the update daemon, the current object versions, the next scheduled updates, and counters for various updates for pass, fail, and retry.
vpn tunnel list Display all configured IPsec VPN tunnels in the current VDOM. This is useful to compare settings on both ends of a tunnel that is having problems.
FortiOS WiFi networking provides a wide range of capabilities for integrating wireless networks into your organization’s network architecture. Each WiFi network or SSID is represented by a virtual network interface to which you apply security policies, UTM features, traffic shaping, and so on, in the same way as for physical wired networks.
You can create multiple WiFi networks to serve different groups of users. For example, you might want one network for your employees and another for guests or customers. Also, with the increase in use of smartphones, tablets and other mobile devices that use WiFi technology, wireless networks are becoming busier than ever and have to accommodate a broad range of wireless client devices each with their own strengths and limitations. You may also want to accommodate these devices and technologies on multiple overlapping wireless networks. These networks could differ greatly in the access they provide to other networks, as well as the authentication, access control, and UTM features they apply.
A network that requires only one WiFi access point is easily created with a FortiWiFi unit operating as a single thick AP. A thick AP such as a FortiWiFi unit contains the WiFi radio facility as well as access control and authentication functionality.
A thin AP, such as a FortiAP unit contains only the radio facility and a microcontroller that receives commands and exchanges data with a WiFi controller. If you already have a FortiGate unit, adding a FortiAP unit as a thin AP managed by the FortiGate unit operating as a WiFi controller is a cost-effective solution for adding WiFi to your network.
The FortiOS WiFi controller feature is available on both FortiGate and FortiWiFi units. A FortiWiFi unit’s WiFi controller also controls the unit’s internal (Local WiFi) radio facility, treating it much like a built-in thin AP. Whenever multiple APs are required, a single FortiGate or FortiWiFi unit controlling multiple FortiAP units is best. A network of multiple thick APs would be more expensive and more complex to manage.
This chapter includes the following WiFi networking examples:
• Setting up secure WiFi access on your FortiWiFi unit
• Setting up secure WiFi on your FortiGate unit using a FortiAP unit
• Improving WiFi security with WPA-Enterprise security
• Setting up secure WiFi with a captive portal
• Sharing the same subnet for WiFi and wired clients
• Setting up a WiFi network with an external DHCP server
Setting up secure WiFi access on your FortiWiFi unit
Setting up secure WiFi access on your FortiWiFi unit
Problem Your small office wired network is configured using a FortiWiFi unit, but employees also use laptops, and other mobile devices. These devices need secure WiFi access to both the office network and the Internet.
Solution Configure a WiFi network on your FortiWiFi unit. Use DHCP to assign up to 10 IP addresses to office WiFi users, as most mobile devices are preconfigured to use DHCP. Use WPA2 security. As there is no authentication in place for the wired network and this is a small team in one place, WPA2-Personal security is appropriate.
There will be one preshared key that users must know to access the WiFi network. Create security policies to enable the WiFi network to access both the office network and the Internet.
Create the SSID and enable the WiFi radio
1 Go to WiFi Controller > WiFi Network > SSID and select Create New to define your wireless network:
2 Enable DHCP with the following settings:
3 Configure the security settings as follows:
4 Select OK.
5 Go to WiFi Controller > Managed Access_Points > Local WiFi Radio and select Enable WiFi Radio.
This solution assumes an area that can be covered by a single FortiWiFi. You can extend the coverage area by connecting FortiAP units and adding the our_wifi SSID to them.
Setting up secure WiFi access on your FortiWiFi unit
Fh
Create firewall addresses and security policies
1 Go to Policy > Policy > Policy and select Create New to add a WiFi-to-Office network security policy that allows WiFi users to access to the office network.
Source NAT is not required for this policy since the WiFi and internal networks are visible to each other.
2 Select Create New to add a WiFi-to-Internet security policy that allows WiFi users to access the Internet.
3 Select Enable NAT and Use Destination Interface Address.
4 Select OK.
Results On your laptop or mobile device, look for the our_wifi SSID and attempt to connect. Enter the “justforus” preshared key when prompted. Verify that you can connect to servers on your office network. Verify that you can connect to the Internet.
You can go to WiFi Controller > Monitor > Client Monitor to view information about the clients that are connected to your WiFi network.
Source Interface/Zone wifi
Source Address all
Destination Interface/Zone port1
Destination Address all
Schedule always
Service ANY
Action ACCEPT
Source Interface/Zone wifi
Source Address all
Destination Interface/Zone wan1
Destination Address all
Schedule always
Service ANY
Action ACCEPT
If you want a more secure authentication method, see “Improving WiFi security with WPA-Enterprise security” on page 114 that requires users to logon instead of using the preshared key.
Setting up secure WiFi on your FortiGate unit using a FortiAP unit
Setting up secure WiFi on your FortiGate unit using a FortiAP unit
Problem A FortiGate unit provides your office with wired networking, but employees also use laptops and mobile devices. These devices need secure WiFi access to both the office network and the Internet. What is a good solution for a small number of users with no access to Windows Active Directory?
Solution Set up a WiFi network with WPA-Personal authentication.
Using the WiFi Controller feature on your FortiGate unit, configure a WiFi network. Then connect a FortiAP unit and authorize it to carry your WiFi network.
On your WiFi network, use DHCP to assign IP addresses to WiFi users, as most mobile devices are preconfigured to use DHCP. Use WPA2 security. As there is no authentication in place for the wired network and this is a small team in one place, WPA2-Personal security is appropriate. There will be one preshared key that users must know to access the WiFi network. Create security policies to enable the WiFi network to access both the office network and the Internet.
Configure port3, an unused network interface on the FortiGate unit, to connect to the FortiAP unit. Connect the FortiAP unit to the port3 interface and wait for it to be discovered. Authorize the FortiAP unit.
Create the SSID
1 Go to WiFi Controller > WiFi Network > SSID and select Create New to define your wireless network:
Setting up secure WiFi on your FortiGate unit using a FortiAP unit
Fh
Create firewall and security policy settings
1 Go to Policy > Policy > Policy and select Create New to add a WiFi-to-Office network policy that allows WiFi users to access to the office network.
Source NAT is not required for this policy since the WiFi and internal networks are visible to each other.
2 Select Create New to add a WiFi-to-Internet policy that allows WiFi users to access the Interne.
3 Select Enable NAT and Use Destination Interface Address.
4 Select OK.
Configure a FortiGate interface to connect to the FortiAP unit and connect the devices
1 Go to System > Network > Interface and Edit the port3 interface:
2 Select Dedicate this interface to FortiAP connection.
3 Use an Ethernet cable to connect port0 (also the ETH port) on the FortiAP unit to port3 on the FortiGate unit and power up the FortiAP unit.
Source Interface/Zone wifi
Source Address all
Destination Interface/Zone port1
Destination Address all
Schedule always
Service ANY
Action ACCEPT
Source Interface/Zone wifi
Source Address all
Destination Interface/Zone wan1
Destination Address all
Schedule always
Service ANY
Action ACCEPT
Addressing Mode Manual
IP/Netmask 192.168.8.1/255.255.255.0
Reserve IP addresses for FortiAP connection 192.168.8.2 - 192.168.8.9
The Reserve IP for FortiAP connection setting automatically configures a DHCP server to assign an IP address to the FortiAP unit. The FortiGate unit uses these IP addresses to communicate with the FortiAP unit.
Setting up secure WiFi on your FortiGate unit using a FortiAP unit
4 On the FortiGate web-based manager, go to WiFi Controller > Managed Access_Points > Managed FortiAP. Select Refresh every ten seconds or so until the FortiAP unit is listed.
5 When the FortiAP unit appears, select it and select Edit.
6 Enter the Name FortiAP1.
7 Select Authorize.
8 Ensure that Enable WiFi Radio is selected and then select OK.
Results On your laptop or mobile device, look for the our_wifi SSID and attempt to connect. Enter the “justforus” preshared key when prompted. Verify that you can connect to servers on your office network. Verify that you can connect to the Internet.
You can go to WiFi Controller > Monitor > Client Monitor to view information about the clients that are connected to your WiFi network.
Using the FortiGate packet sniffer to view the FortiAP discovery process
The FortiGate unit’s built-in packet sniffer can help you to view the discovery process if you experience difficulty in getting the FortiGate unit to recognize the FortiAP unit. Use the CLI command diagnose sniffer packet port3 none 4 to capture packets entering or leaving the FortiGate port3 interface to which the FortiAP unit is connected. Packet headers will be shown. For more information about using the sniffer, see “Troubleshooting by sniffing packets (packet capture)” on page 89.
The FortiAP unit uses several methods to find a WiFi controller. Here are some examples of the request packets you should see, possibly repeated several times before a response is received and processed:
Broadcast DHCP request:
port3 -- 0.0.0.0.68 -> 255.255.255.255.67: udp
This DCHP client request should reach the DHCP server configured on port3. The server response looks like this:
port3 -- 192.168.8.1.67 -> 192.168.8.2.68: udp
The FortiAP unit is assigned the IP address 192.168.8.2. It will then communicate with the WiFi controller on 192.168.8.1 using the CAPWAP control port 5246.
Discovery of the FortiAP unit can take up to two minutes.
If the FortiAP is not listed under Managed FortiAP after two minutes:
• Check that port0 (ETH) on the FortiAP unit is connected to port3 on the FortiGate unit.
• Power cycle the FortiAP unit.
• On the FortiGate unit, go to System > Monitor > DHCP Monitor to see whether the FortiAP unit is assigned an IP address lease.
• See also “Using the FortiGate packet sniffer to view the FortiAP discovery process” in the Results section.
This solution assumes an area that can be covered by a single FortiAP. You can extend the coverage area by connecting and authorizing additional FortiAP units and adding the our_wifi SSID to them.
Note that this request is on the CAPWAP control port, 5246. The multicast IP address on the FortiAP unit and the WiFi controller is reconfigurable and must agree. The WiFi controller responds directly to the FortiAP unit in unicast on port 5246.
ARP who-has packets occur frequently. The ARP reply packet containing your FortiAP unit’s wired MAC address confirms that the unit has successfully obtained an IP address.
Ongoing communication between FortiAP unit and WiFi controller:
The discovery process should be complete now, with the FortiAP unit listed in the Managed FortiAP list, ready for you to authorize. Routine control channel communications back and forth look like this:
Improving WiFi security with WPA-Enterprise security
Improving WiFi security with WPA-Enterprise security
Problem You set up a WiFi network with WPA-Personal security, but now you want better security with individual authentication for your users.
Solution Create user accounts and a wifi_users user group on the FortiWiFi unit. Modify your SSID to use WPA/WPA2-Enterprise security and authenticate users who belong to the wifi_users group. There is no longer a pre-shared key that could fall into the wrong hands or would need to be changed if someone left the group. Each user has an individual user name and password. Accounts can be added or removed as needed.
Create WiFi network user accounts
1 Go to User > User > User and select Create New to create a user account:
2 Create additional user accounts as needed, one for each employee.
3 Go to User > User Group > User Group and select Create New to create a user group:
4 Select OK.
Create the SSID and enable the WiFi radio
1 Go to WiFi Controller > WiFi Network > SSID and select Create New to define your wireless network:
User Name wloman
Password my_secure_pwd
If your employees already have user accounts on the FortiWiFi or FortiGate unit, you can skip this step and use the existing accounts.
Name wifi_users
Type Firewall
MembersAdd wloman and the other employee accounts to the Members list.
Improving WiFi security with WPA-Enterprise security
Fh
2 Enable DHCP with the following settings:
3 Configure the security settings as follows:
4 Select OK.
5 Go to WiFi Controller > Managed Access Points > Local WiFi Radio and select Enable WiFi Radio.
Create firewall addresses and security policies
1 Go to Policy > Policy > Policy to and select Create New to add a WiFi-to-Office network security policy that allows WiFi users to access to the office network.
Source NAT is not required for this policy since the WiFi and internal networks are visible to each other.
2 Select Create New to add a WiFi-to-Internet security policy that allows WiFi users to access the Internet.
Improving WiFi security with WPA-Enterprise security
3 Select Enable NAT and Use Destination Interface Address.
4 Select OK.
Results On your laptop or mobile device, look for the our_wifi SSID and attempt to connect. Unlike WPA/WPA2-Personal you will be prompted to enter your user name and password. Enter wloman as the user name and my_secure_pwd as the password. Once you have been authenticated, verify that you can connect to servers and other resources on your office network. Also verify that you can connect to the Internet.
You can go to WiFi Controller > Monitor > Client Monitor to view information about the clients that are connected to your WiFi network.
Problem A FortiGate unit provides your office with wired networking, but employees also use laptops and mobile devices. These devices need secure WiFi access to both the office network and the Internet. The employees use web applications and are most comfortable authenticating through the web browser.
Solution Set up a captive portal configuration that intercepts connections to the wireless network and displays a portal on wireless clients’ devices. User’s must authenticate with the portal to get access to the wireless network.
To configure the portal you must Create a user group with a user account for each employee. Create a WiFi network with captive portal authentication. A captive portal appears to be an open WiFi access point, allowing any WiFi device to connect. On the first attempt to connect to a web site, the captive portal presents a web page that requests the user’s logon credentials which must match credentials in the user group.
Create WiFi network user accounts
1 Go to User > User > User and select Create New to create a user account:
2 Create additional user accounts as needed, one for each employee.
3 Go to User > User Group > User Group and select Create New to create a user group:
4 Select OK.
Create the SSID and enable the WiFi radio
1 Go to WiFi Controller > WiFi Network > SSID and select Create New to define your wireless network:
User Name wloman
Password my_secure_pwd
If your employees already have user accounts on the FortiWiFi or FortiGate unit, you can skip this step and use the existing accounts.
Name wifi_users
Type Firewall
MembersAdd wloman and the other employee accounts to the Members list.
Results On your laptop or mobile device, look for the our_wifi SSID and attempt to connect. Your device should connect quickly because no password is required at this stage.
Some mobile devices display the Fortinet Terms and Disclaimer Agreement portal as soon as you connect to the SSID. Some devices only display the portal when you open a web browser and attempt to connect to an Internet destination. Select the I accept... check box below the Agreement text to indicate that you agree. Enter wloman as Username and my_secure_pwd as Password, then select Continue. Your requested web site should then be displayed and you can otherwise use the WiFi network. You can continue browsing until your authentication times out. Then, you will have to accept the disclaimer and re-enter your logon credentials again.
You can go to WiFi Controller > Monitor > Client Monitor to view information about the clients that are connected to your WiFi network.
In User > Monitor > Firewall, you can see the authenticated captive portal user:
Sharing the same subnet for WiFi and wired clients
Sharing the same subnet for WiFi and wired clients
Problem You want to put your WiFi users on the same network segment (or subnet) as your wired LAN users, but the FortiGate unit requires each network interface to have a single unique network segment.
Solution Create a software switch interface with the internal LAN interface and WiFi network virtual interfaces as members.
Create the SSID and enable the WiFi radio
1 Go to WiFi Controller > WiFi Network > SSID and select Create New to add the SSID to be added to the software switch:
2 Clear the Enable DHCP checkbox.
3 Configure the security settings as follows:
4 Select OK to save the SSID.
5 Go to WiFi Controller > Managed Access_Points > Local WiFi Radio and select Enable WiFi Radio.
Create the software switch
1 Go to System > Network > Interface and select Create New to add the software switch:
A software switch interface can only include physical and WiFi interfaces. Before adding an interface to a software switch interface you must delete all configuration objects that use that interface. This includes factory default security policies and DHCP server configurations.
Interface Name wifi
SSID our_wifi
There is no need to specify an IP address for the SSID because the IP address of the software switch interface will be used. Also, you should disable the DHCP server for the SSID since you will add one later for the software switch interface.
Security Mode WPA/WPA2-Personal
Data Encryption AES
Pre-shared Key justforus
You can extend the coverage area by connecting FortiAP units and adding the our_wifi SSID to them.
Sharing the same subnet for WiFi and wired clients
Fh
2 Go to System > Network > DHCP Server and select Create New to add a DHCP server for the devices on the wired and wireless networks connected to the software switch:
3 Select OK.
Create firewall addresses and security policies
1 Go to Policy > Policy > Policy to create the security policy that enables users connected to the software switch to connect to the Internet.
2 Select Enable NAT and Use Destination Interface Address.
3 Select OK to save the security policy.
Results Configure the devices on the internal network to get their IP addresses using DHCP and renew their leases if required. They should all have IP addresses on the 10.10.10.0/255.255.255.0 network.
On your laptop or mobile device, look for the our_wifi SSID and attempt to connect. Enter the “justforus” preshared key when prompted. Wireless devices should also acquire IP addresses in the 10.10.10.0/255.255.255.0 network.
Verify that you can connect to servers on your office network from mobile devices and verify that you can connect to the Internet.
Setting up a WiFi network with an external DHCP server
Fh
Setting up a WiFi network with an external DHCP server
Problem You want to set up a small WiFi network for your team’s laptops and mobile devices and use the company’s DHCP server instead of a DHCP server configured on the WiFi interface.
Solution When you configure the SSID (WiFi network) don’t configure a DHCP server. On the WiFi interface, specify a DHCP relay to the company’s DCHP server. Check your security policies to ensure that DHCP packets can pass through the FortiGate unit from the WiFi network to the LAN where the DHCP server resides.
Create the SSID and enable the WiFi radio
1 Go to WiFi Controller > WiFi Network > SSID and select Create New to define your wireless network:
2 Clear the Enable DHCP checkbox to disable DHCP.
3 Configure the security settings as follows:
4 Select OK.
5 Go to WiFi Controller > Managed Access_Points > Local WiFi Radio and select Enable WiFi Radio.
Configure the WiFi interface to support DHCP relay
1 Go to System > Network > DHCP Server, select Create New and enter the following settings to configure the WiFi interface to support DHCP relay:
This example shows a FortiWiFi-based network with WPA/WPA2-Personal security. You can also apply this DHCP configuration to WiFi networks with other security settings and to WiFi networks based on FortiAP units.
Setting up a WiFi network with an external DHCP server
Create firewall addresses and security policies
1 Go to Policy > Policy > Policy and select Create New to add a WiFi-to-Office network security policy that allows WiFi users to access to the office network:
Source NAT is not required for this policy since the WiFi and internal networks are visible to each other.
2 Select Create New to add a WiFi-to-Internet security policy that allows WiFi users to access the Internet.
3 Select Enable NAT and Use Destination Interface Address.
4 Select OK.
Results On your mobile device, look for the our_wifi SSID and attempt to connect. Enter the “justforus” preshared key when prompted. Once you are connected, verify that you can connect to servers on your office network, and to the Internet.
You can go to WiFi Controller > Monitor > Client Monitor to view information about the clients that are connected to your WiFi network.
Source Interface/Zone wifi
Source Address all
Destination Interface/Zone port1
Destination Address all
Schedule always
Service ANY
Action ACCEPT
The default ANY service accepts DHCP sessions. If you make a more restrictive policy, make sure that DHCP sessions are allowed.
If the DHCP server that you will use is not on the office network, you will also need a policy to allow DHCP traffic to pass from the DHCP server’s network to the WiFi network.
Setting up a WiFi network with an external DHCP server
Fh
If the Auth column shows Pass, but the IP column shows 0.0.0.0, the DHCP Relay configuration isn’t working. Check the following:
• Is the mobile device configured to obtain an IP address automatically using DHCP?
• Does the wifi-to-wan1 policy allow DHCP service to pass? (ANY service includes DHCP.)
• Does the DHCP server have a route to the WiFi network? To check this, add a temporary wan1-to-wifi policy and ping the WiFi network gateway from the DHCP server.
• Is the DHCP server configured to provide IP addresses for your WiFi network’s subnet? A complete configuration includes the default route and DNS server addresses.
The normal DHCP sequence as seen in the server’s log messages looks like this:
dhcpd: DHCPDISCOVER from 00:23:4e:52:fd:6f via 10.10.10.1dhcpd: DHCPOFFER on 10.10.10.10 to 00:23:4e:52:fd:6f (user1-AOA150) via 10.10.10.1dhcpd: DHCPREQUEST for 10.10.10.10 (192.168.1.101) from 00:23:4e:52:fd:6f (user1-AOA150) via 10.10.10.1dhcpd: DHCPACK on 10.10.10.10 to 00:23:4e:52:fd:6f (user1-AOA150) via 10.10.10.1
Repeated DHCPDISCOVER and DHCPOFFER messages with no DHCPACK response suggest that these messages are not reaching the client.
It is also normal to see a DCHCPREQUEST message for an IP address that was not offered in a prior DHCPOFFER message. Many clients automatically request the IP address that they used previously. If this IP address is acceptable to the server, it will issue a DHCPACK message immediately.
Problem You want WiFi users to authenticate using their Windows Active Directory credentials. You are using Windows Active Directory (Windows AD) running on Windows Server 2008.
Solution Configure a RADIUS server (Network Policy Server) in Windows Active Directory (AD). Configure the your WiFi network with WPA-Enterprise to authenticate users with this Windows RADIUS (NPS) server.
Configuring the Windows AD domain controller
You need to:
• Configure the Network Policy Server.
• Install a certificate for PEAP authentication.
• Install the CA certificate.
• Add the FortiWiFi unit as a RADIUS client.
• Configure a connection request policy for the FortiWiFi unit.
• Configure the Security Health Validator.
• Configure health policies.
• Configure network policies.
Configure the Network Policy Server
1 In Windows AD, go to Start > Administrative Tools > Network Policy Server.
2 In the left pane expand Policies right-click Network Policies and select New.
3 On the Specify Network Policy Name and Connection Type screen, for Policy name enter FortinetWiFi. Leave the Type of network access server as Unspecified and select Next.
4 On the Specify Conditions screen, select Add. Select Windows Groups and select Add.
5 In the Windows Groups dialog, select Add Groups.
6 In the Select Group dialog, enter WiFi_users. Select Check Names to verify your entry, then select OK.
7 In the Windows Groups dialog, select OK.
8 In the Specify Conditions window, select Next.
9 In the Specify Access Permission window, select Access Granted, then select Next.
This example assumes that
• You have a Windows AD network which currently uses a RADIUS (NPS) server for authentication.
• The server to which the FortiWiFi unit connects is a domain controller with a DNS server, NPS server (same domain), and a CA Authority installed.
• WiFi users have been added to a group called WiFi_users. Determine the IP address of the RADIUS server before you begin.
10 In the Configure Authentication Methods window, use the Add button to add PEAP and EAP-MSCHAP v2 to the EAP Types list. Select MS-CHAP-v2 and PAP methods, then select Next.
11 Select Next until you reach the Completing New Network Policy page, then select Finish.
Install a certificate for PEAP authentication
1 Go to Start > Run. In Open, type mmc, and then select OK.
If there is no Certificates item in the left pane, you need to install the Certificates snap-in.
2 In the mmc left pane, expand Certificates, right-click Personal, select All Tasks > Request New Certificate.
3 In the Certificate Enrollment window, select Next.
4 Select Computer, then select Enroll.
5 Verify that Succeeded is displayed and then select Finish.
6 Close the Console1 window. Do not save the console settings.
Install the Root CA
1 Open the Server Manager.
2 In the left pane, select Roles.
3 Select Action > Add Roles.
4 If the Before you Begin wizard appears, select Next.
5 In the list of available server roles, select the Active Directory Certificate Services and select Next twice.
6 Make sure that Certification Authority is selected, and select Next.
7 Select Enterprise and select Next.
8 Specify Root CA and select Next. (Selection must match type of CA you are changing from.)
9 On the Set Up Private Key page, select Next. Keep selecting Next until the Install button is available, then select Install.
10 When installation completes, select Close.
Add the FortiWiFi unit to Windows AD as a RADIUS client
1 Open the Network Policy Server.
2 In the left pane, expand RADIUS Clients and Servers. Right-click RADIUS Clients and select New. Enter the following information:
3 Select the Advanced tab.
4 Select Access-Request must contain the Message Authenticator attribute.
5 Make sure that RADIUS client is NAP-capable is not selected.
5 Go to WiFi Controller > Managed Access_Points > Local WiFi Radio and select Enable WiFi Radio.
Results Verify that WiFi users can authenticate and have access to both the office LAN and the Internet.
This solution assumes an area that can be covered by a single FortiWiFi. You can extend the coverage area by connecting FortiAP units and adding the our_wifi SSID to them.
Using security policies and firewall objects to control traffic
Most commonly, FortiGate units are used to control access between the Internet and a network, typically allowing users on the network (such as an office network) to connect to the Internet while protecting the network from unwanted access from the Internet. So a FortiGate unit has to know what access should be allowed and what should be blocked. This is what security policies are for, controlling all network traffic attempting to pass through a FortiGate unit. No traffic can pass through a FortiGate unit unless specifically allowed to by a security policy.
Once traffic is allowed, virtually all FortiGate features are applied to allowed traffic through security policies. From a security policy, you can control address translation, control the addresses and services used by the traffic, and apply features such as UTM, authentication, and VPNs.
Most of the examples in this cookbook at some point involve the creation of security policies to allow traffic and then apply a feature to it. This chapter focuses more on firewall features and how to configure policies to apply them. Topics include using security policies to restrict access, how to order policies correctly, using geographic addresses, applying traffic shaping and configuring some common forms or source network address translation (S-NAT) and destination address translation (DNAT).
Security policies
It is simple to set up a FortiGate unit to allow users on a network to access the Internet while blocking traffic from the Internet from accessing the protected network. All that is required is a single security policy that allows traffic from the Internal network to connect to the Internet. As long as you do not add a security policy to allow traffic from the Internet onto your internal network, your network is protected.
When a user connects to the Internet, they expect a reply (for example, when you connect to a web site you expect to see a web page). The same security policy that allows you to connect to the Internet also allows servers you contact to respond to you. In effect, a single policy allows two-way traffic, but the incoming traffic is only allowed in response to requests sent by you.
Using security policies and firewall objects to control traffic
Fh
Even though there is no risk of unwanted traffic originating from the Internet getting onto your internal network, users are connecting to the Internet and downloading data. These downloads can sometimes include unwanted items, such as viruses. that make their way through to FortiGate unit to your network. To protect your network from this problem, security policies are also the way to turn on all FortiGate UTM features. For example, users may download a virus when browsing the web or retrieving email. You can protect your network from this danger by adding virus scanning to security polices that allow users to connect to the Internet. All traffic in either direction that is controlled by a security policy that includes virus scanning will be scanned for viruses. The benefit of this approach is that you can apply security features directly to allowed traffic. This also means that you can apply custom security features to each security policy and to each type of traffic allowed through the FortiGate unit. Security features are applied using UTM objects and profiles. You can create as many profiles as you need and mix and match them in a security policy as required.
For example, it might be acceptable to you to apply only web filtering to the security policy that allows users on the protected internal network to access web sites on the Internet. If you have a separate security policy that allows users on the internal network to download and send email, you could apply virus scanning to this traffic to make sure users cannot download email attachments containing viruses. In addition you could apply data leak protection to the email traffic to prevent users from sending confidential email to the Internet.
All of these security features can be added to security policies as you create them. Or once you have security policies that control traffic patterns you can edit them to add or change security features as you build up your security requirements or as those requirements change.
Defining Firewall objects
Firewall objects include addresses, services, and schedules that are used in security policies to control the traffic accepted or blocked by a security policy. Addresses are matched with the source and destination address of packets received by the FortiGate unit. Firewall addresses can be IPv4 or IPv6 addresses that define a single device or a network. You can also add domain names instead of numeric addresses and use geographic addressing to specify all of the IP addresses of traffic originating from a specific country. These powerful address tools allow you to customize addresses for any security policy requirement. The all address matches a security policy with traffic to or from any IP address.
FortiGate units include a wide range of pre-defined network services that can be added to security policies. For example, you can add a security policy that intercepts all HTTP traffic just by adding the HTTP service to a security policy. Pre-defined services include basic network services such as HTTP, FTP, TCP, SMTP and more specialized services such as H323 (used for VoIP and media), MMS (the multimedia messaging service used by mobile phones) and so on. You can also easily create custom services if your network uses network services that are not in the FortiGate pre-defined services list. You must add at least one service to a security policy. You can also add multiple services to a single security policy if you want to policy to multiple traffic types. The ANY pre-defined service accepts traffic using any network service.
Firewall schedules control when security policies are active. The default always schedule does not restrict when a policy is active. You can limit when a policy is active by adding schedules defining the time for which the policy is active. You can create recurring schedules that take effect repeatedly at specified times of specified days of the week (for example, a schedule that is active during office hours: weekdays between 9am and 5 pm). You can also create one-time schedules that take effect only once for the period of time (for example, for a week in September 2020).
Firewall objects also include traffic shapers, used to normalize traffic peaks and bursts to prioritize certain flows over others. A wide variety of traffic shaping options are available, allowing you to customize traffic shaping according to your networks requirements and apply custom traffic shaping to any security policy.
The Virtual IP firewall objects are added to security policies to perform various forms of destination network address translation (D-NAT) including destination IP address and destination port translation and port forwarding.
Using security policies and firewall objects to control traffic
The final firewall object is load balancing, which is an extension of virtual IPs to load balance traffic passing through the FortiGate unit to multiple servers. FortiGate load balancing supports various load balancing schedules, real server health monitoring, persistence, and SSL acceleration.
This chapter includes the following security policy and firewall object examples:
• Restricting employees’ Internet access
• Restricting Internet access per IP address
• Verifying that traffic is accepted a security policy
• Ordering security policies
• Allowing DNS queries to only one approved DNS server
• Ensuring sufficient and consistent bandwidth for VoIP traffic
• Using geographic addresses
• Providing Internet access for your private network users (static source NAT)
• Providing Internet access for a private network with multiple Internet addresses (dynamic source NAT)
• Dynamic source NAT without changing the source port (one-to-one source NAT)
• Dynamic source NAT using the central NAT table
• Allowing access to a web server on an internal network when you only have one Internet IP address
• Allowing Internet access to a web server on a protected network when you only have one Internet IP address, using port translation
• Allowing Internet access to a web server on a protected network when you have an IP address for the web server
• Configuring port forwarding to open ports on a FortiGate unit
• Dynamic destination NAT for a range of IP addresses
Problem You want to limit general Internet access to between 12 noon and 2 pm. You also want to allow unlimited access to a select few Internet web sites at all times.
Solution Create a firewall schedule that restricts access to between 12 and 2. Add this schedule to a security policy that allows access to the Internet.
Add FQDN and subnet/IP range firewall addresses for Internet web sites that should be allowed unlimited access (wiki.example.net, svn.example.com, 172.20.120.101, and 172.16.100.154). Add these firewall addresses to a second security policy that allows unlimited access to these addresses.
Creating the security policy that limits Internet access to between 12 noon and 2 pm
1 Go to Firewall Objects > Schedule > Recurring and select Create New to add a schedule to allow access between 12 and 2 on weekdays:
2 Select OK.
3 Go to Policy > Policy > Policy and select Create New to add the security policy that restricts Internet access to between 12 and 2:
4 Select Enable NAT and Use Destination Interface Address.
5 Select OK.
Depending on the network configuration, users on the internal network may always need access to a DNS server on the Internet. There are a number of ways you can allow access to such a DNS server. This example adds the DNS server to the address group. You could also add another security policy that only allows access to the DNS servers on the Internet.
Name lunch break
Day of the Week Monday, Tuesday, Wednesday, Thursday, Friday
3 Before 12 or after 2, attempt to access any site on the Internet (other than the allowed sites).
Access should be blocked because policy 2 only allows access to the Internet between 12 and 2.
4 Before 12 or after 2, attempt to access any of the addresses added to the Allowed addresses address group.
Access should be allowed. The Count column for policy 3 should show that this policy has been accepting sessions.
Sessions accepted by policy 3 should also appear when you go to Policy > Monitor > Policy Monitor to view active sessions by policy.
5 Between 12 or after 2, attempt to access any site on the Internet (including the sites added to the Allowed addresses address group).
All Internet traffic is allowed by policy 2, so the Count for policy 2 should increase. No sessions are accepted by policy 3 so its count should not increase.
As well, Policy > Monitor > Policy Monitor should only show sessions for policy 2.
To test a new security policy configuration it can be useful to temporarily disable other policies, attempt to connect through the FortiGate unit as users would, and verify the results. Once you get a configuration working with other policies disabled you can enable the other policies and re-test the configuration. Note that disabling policies will interrupt traffic through the FortiGate unit.
Firewall schedules reference the FortiGate unit’s system time. Make sure the FortiGate system time is correct or schedules will produce unexpected results. You can check and adjust the FortiGate system time from the System Information dashboard widget.
Using diagnose debug flow to show traffic hitting the policies before 12
You can use the diagnose debug flow command to show packet flow through the FortiGate unit. As packets are received you can view debug messages to show how the FortiGate unit processes them. The following command sequence displays packet flow for packets from IP address 192.168.1.110 before 12 when policy 2 is not active.
diagnose debug enable
diagnose debug flow show console enableshow trace messages on console
diagnose debug flow filter add 192.168.1.110
diagnose debug flow trace start 100
• The first six output lines show a packet received at the Internal interface with destination address 172.16.100.148. This matches the IP address of wiki.example.net so the packet is routed, SNATed and allowed by security policy 3.
id=36871 trace_id=1 msg="vd-root received a packet(proto=6, 192.168.1.110:3152- >172.16.100.148:80) from internal."id=36871 trace_id=1 msg="allocate a new session-0000724b"id=36871 trace_id=1 msg="find a route: gw-172.20.120.2 via wan1"id=36871 trace_id=1 msg="find SNAT: IP-172.20.120.11, port-40156"id=36871 trace_id=1 msg="Allowed by Policy-3: SNAT"id=36871 trace_id=1 msg="SNAT 192.168.1.110->172.20.120.11:40156"
• The next three output lines show another packet that is part of the same session.id=36871 trace_id=2 msg="vd-root received a packet(proto=6, 192.168.1.110:3152- >172.16.100.148:80) from internal."id=36871 trace_id=2 msg="Find an existing session, id-0000724b, original direction"id=36871 trace_id=2 msg="SNAT 192.168.1.110->172.20.120.11:40156"
• The next seven output lines show DNS packet accepted by policy number 3 and show the DNS session helper being used.
id=36871 trace_id=7 msg="vd-root received a packet(proto=17, 192.168.1.110:3884->8.8.8.8:53) from internal."id=36871 trace_id=7 msg="allocate a new session-00007262"id=36871 trace_id=7 msg="find a route: gw-172.20.120.2 via wan1"id=36871 trace_id=7 msg="find SNAT: IP-172.20.120.11, port-40864"id=36871 trace_id=7 msg="Allowed by Policy-3: SNAT"id=36871 trace_id=7 msg="SNAT 192.168.1.110->172.20.120.11:40864"id=36871 trace_id=7 msg="run helper-dns-udp(dir=original)"
• The next four output lines show a packet destined for another Internet address being denied.
id=36871 trace_id=9 msg="vd-root received a packet(proto=6, 192.168.1.110:3155- >72.32.40.232:80) from internal."id=36871 trace_id=9 msg="allocate a new session-00007272"id=36871 trace_id=9 msg="find a route: gw-172.20.120.2 via wan1"id=36871 trace_id=9 msg="Denied by forward policy check"
Using diagnose debug flow to show traffic hitting the policies between 12 and 2
The following command sequence displays packet flow for packets from IP address 192.168.1.110 between 12 and 2 when policy 2 is active.
diagnose debug enable
diagnose debug flow show console enableshow trace messages on console
diagnose debug flow filter add 192.168.1.110
diagnose debug flow trace start 100
• The following output lines show a packet received at the Internal interface with destination address 172.16.100.148. This matches the IP address of wiki.example.net but because security policy 2 is active it is accepted by this policy instead of security policy 3.
id=36871 trace_id=201 msg="vd-root received a packet(proto=6, 192.168.1.110:3518- >172.16.100.148:80) from internal."id=36871 trace_id=201 msg="allocate a new session-00007adc"id=36871 trace_id=201 msg="find a route: gw-172.20.120.2 via wan1"id=36871 trace_id=201 msg="find SNAT: IP-172.20.120.11, port-48434"id=36871 trace_id=201 msg="Allowed by Policy-2: SNAT"id=36871 trace_id=201 msg="SNAT 192.168.1.110->172.20.120.11:48434"
Problem How do I use security policies to restrict access to the Internet based on IP addresses of users on an internal network?
Solution Identify groups of users according to their IP addresses and add firewall addresses for these groups.
Two user groups are identified:
• Engineering users with IP addresses in the range 10.10.20.100 - 10.10.20.150
• Marketing users with IP addresses in the range 10.10.20.30 - 10.10.20.50
The solution shows how to allow marketing access to the Internet during office hours (between 8:00 am and 6:00 pm) but restricting engineering to only being able to access the Internet between 12:00 noon and 2:00 pm.
Creating the firewall addresses for each user group
1 Go to Firewall Objects > Address > Address and select Create New to add the engineering address range:
2 Select Create New to add the marketing address range:
Creating the firewall schedules
1 Go to Firewall Objects > Schedule > Recurring and select Create New to add a schedule for engineering:
Address Name engineering
Type Subnet / IP Range
Subnet / IP Range 10.10.20.[100-150]
Interface internal
Address Name marketing
Type Subnet / IP Range
Subnet / IP Range 10.10.20.[30-50]
Interface internal
Name engineering-restrict
Day of Week Monday, Tuesday, Wednesday, Thursday, Friday
2 Select Create New to configure the schedule for marketing:
3 Select OK.
Configuring security policies
Disable or delete any existing security policies before proceeding. This allows the FortiGate unit to skip the other policies and concentrate on the following two policies, eliminating any sequencing conflicts. Once you have the following scenario working you can reorder any other policies that you have, enable them, and then test the firewall configuration to make sure it works as expected.
1 Go to Policy > Policy > Policy and select Create New to create the security policy for marketing:
2 Select Enable NAT and Use Destination Interface Address.
3 Select Create New to create the security policy for engineering:
4 Select Enable NAT and Use Destination Interface Address.
5 Select OK.
Name marketing-all
Day of Week Monday, Tuesday, Wednesday, Thursday, Friday
Results The marketing department should be able to connect to the Internet immediately and the engineering department should not be able to connect to the Internet until the specified time in the schedule. You should also see packets in the Count column in the marketing policy, but nothing in the engineering policy.
To test that things are correct, try accessing web sites on the Internet from the engineering department. All access should be denied. Try accessing web sites from the marketing department. All access should be allowed.
To test that the engineering department policy is correct, change the time frame in the engineering-restrict firewall schedule to the current time, and then try accessing web sites from the engineering department. You should be seeing packets in the Count column in the engineering policy as well as in the marketing policy.
Change the time range back to the original time in the engineering-restrict firewall schedule, and all packets should stop and the Count for this policy should not increase.
Verifying that traffic is accepted a security policy
Verifying that traffic is accepted a security policy
Problem How can I verify that traffic is being accepted by (or hitting) a security policy?
Solution Use the security policy list Count column and the policy monitors. The Count column and the policy monitors provide a visual verification that packets are hitting a policy.
This solution uses the security policies created in “Restricting Internet access per IP address” on page 141.
1 Go to Policy > Policy > Policy and locate the engineering-restrict and marketing-all policies.
The Count column in the following example shows that there are currently no packets hitting the engineering-restrict policy, but packets are hitting the marketing-all policy.
2 Go to Policy > Monitor > Policy Monitor to view the marketing-all policy sessions.
In the list, you should be seeing that the policy ID, in this case ID number 5, is the marketing-all policy that is accepting these sessions. You can verify this by selecting Refresh to see the byte and packet count increase.
Verifying that traffic is accepted a security policy
Fh
3 You can drill down to see a graph of the individual sessions accepted by the policy by source or destination address or destination port.
4 You can drill down one more level to see a detailed list of the sessions currently accepted by the policy.
5 Go to the engineering-restrict schedule and change the original time to current time so that you can verify that traffic is hitting that policy.
6 On both the policy list and Policy Monitor, you can verify that traffic is now hitting both policies.
Results You can use these web-based manager tools to verify that traffic is hitting the expected security policies. More advanced tools for verifying that traffic is hitting the expected policy are available from the CLI.
Verifying that traffic is accepted a security policy
Using diagnose debug flow to show traffic hitting a policy
You can use the diagnose debug flow command to show packet flow through the FortiGate unit. As packets are received you can view debug messages to show how the FortiGate unit processes them. The following command sequence displays packet flow for packets with IP address 10.10.20.30.
The command output is extracted from actual command output and shows what happens after one packet is received:
• a new session is allocated,
• a route is found for the packet,
• its source NAT IP and port number are selected,
• It is matched with a policy (in this case policy ID 5),
• Source is performed and the packet is forwarded.diagnose debug enable
diagnose debug flow show console enableshow trace messages on console
diagnose debug flow filter add 10.10.20.30
diagnose debug flow trace start 100
id=36871 trace_id=1132 msg="vd-root received a packet(proto=17, 10.10.20.30:1029->192.168.110.11:161) from internal."id=36871 trace_id=1132 msg="allocate a new session-00012042"id=36871 trace_id=1132 msg="find a route: gw-172.20.120.2 via wan1"id=36871 trace_id=1132 msg="find SNAT: IP-172.20.120.230, port-54409"id=36871 trace_id=1132 msg="Allowed by Policy-5: SNAT"id=36871 trace_id=1132 msg="SNAT 10.10.20.30->172.20.120.230:54409"
The following command sequence and output shows what happens when you do a debug trace for packets that contain IP address 172.20.120.2 and then ping from 10.10.20.30 to 172.20.120.2 through the FortiGate unit. The first six output lines shows the ping packet received from 10.10.20.30 and being accepted by the security policy ID 5. The final four lines show how the reply from 172.20.120.2 is received by an existing session and passed through the FortiGate unit to the source.
diagnose debug enable
diagnose debug flow show console enableshow trace messages on console
diagnose debug flow filter add 172.20.120.2
diagnose debug flow trace start 100
id=36871 trace_id=1147 msg="vd-root received a packet(proto=1, 10.10.20.30:512->172.20.120.2:8) from internal."id=36871 trace_id=1147 msg="allocate a new session-00012259"id=36871 trace_id=1147 msg="find a route: gw-172.20.120.2 via wan1"id=36871 trace_id=1147 msg="find SNAT: IP-172.20.120.230, port-59532"id=36871 trace_id=1147 msg="Allowed by Policy-5: SNAT"id=36871 trace_id=1147 msg="SNAT 10.10.20.30->172.20.120.230:59532"id=36871 trace_id=1148 msg="vd-root received a packet(proto=1, 172.20.120.2:59532->172.20.120.230:0) from wan1."id=36871 trace_id=1148 msg="Find an existing session, id-00012259, reply direction"id=36871 trace_id=1148 msg="DNAT 172.20.120.230:0->10.10.20.30:512"id=36871 trace_id=1148 msg="find a route: gw-10.10.20.30 via internal"
Verifying that traffic is accepted a security policy
Fh
Using diagnose debug flow to show traffic hitting a DENY policy
Change a policy that accepts traffic to one that denies traffic and use the diagnose debug flow commands to view the results. For example, change the policy ID 5 to a DENY, enter the debug flow commands and then ping from 10.10.20.30 to 172.20.120.2 through the FortiGate unit. The output lines show a ping packet being received, a session allocated, a route found and then the packet being denied. Note that the output does not indicate which security policy denied the packet.
Note also that traffic hitting a DENY policy does not appear on the Policy Monitor.
diagnose debug enable
diagnose debug flow show console enableshow trace messages on console
diagnose debug flow filter add 172.20.120.2
diagnose debug flow trace start 100
id=36871 trace_id=126 msg="vd-root received a packet(proto=1, 10.10.20.30:512->172.20.120.2:8) from internal."id=36871 trace_id=126 msg="allocate a new session-00000d37"id=36871 trace_id=126 msg="find a route: gw-172.20.120.2 via wan1"id=36871 trace_id=126 msg="Denied by forward policy check"
Problem I want to add a security policy that blocks access to the Internet for one source address. Should I arrange it above or below a general policy that allows access to the Internet from any source address?
Solution More specific security policies should be placed in the security policy list above more general policies. In this case the specific policy that blocks one source address should be placed above the general policy that allows access from any source address.
1 Go to Policy > Policy > Policy and select Create New to add a security policy to allow all users on the internal network to access the Internet.
2 Select Enable NAT and Use Destination Interface Address.
3 Select OK.
4 Go to Firewall Objects > Address > Address and select Create New to add the specific address to be blocked:
5 Select OK.
6 Go Policy > Policy > Policy and select Create New to add a security policy to deny access for sessions from the source address 192.161.1.110:
Source Interface/Zone internal
Source Address All
Destination Interface/Zone wan1
Destination Address All
Schedule always
Service ANY
Action ACCEPT
Some FortiGate models include this security policy in the default configuration. If you have one of these models, this step has already been done for you.
Results New security policies are always added to the bottom of the policy list so this specific policy is added below the general policy that allows access.
1 Test the configuration by attempting to connect to the Internet from a PC with IP address 192.168.1.110.
Access should be allowed. If you go to Policy > Policy > Policy, the Count column should show that the general policy is accepting packets.
2 Select the specific policy and select Move to and move this policy Before policy 1.
3 Test this new configuration by attempting to connect to the Internet from a PC with IP address 192.168.1.110.
Access should be denied. If you go to Policy > Policy > Policy the Count column should show that the deny policy is blocking packets.
The following command sequence displays packet flow for packets from IP address 192.168.1.110 that are blocked by the deny policy.
diagnose debug enable
diagnose debug flow show console enableshow trace messages on console
diagnose debug flow filter add 192.168.1.110
diagnose debug flow trace start 100
id=36871 trace_id=301 msg="vd-root received a packet(proto=6, 192.168.1.110:3858- >172.16.100.148:80) from internal."id=36871 trace_id=301 msg="allocate a new session-0000876e"id=36871 trace_id=301 msg="find a route: gw-172.20.120.2 via wan1"id=36871 trace_id=301 msg="Denied by forward policy check"
The following command sequence displays packet flow for packets from IP address 192.168.1.120 that are allowed by policy 1.
diagnose debug enable
diagnose debug flow show console enableshow trace messages on console
diagnose debug flow filter add 192.168.1.120
diagnose debug flow trace start 100
id=36871 trace_id=310 msg="vd-root received a packet(proto=6, 192.168.1.120:3907- >172.16.100.148:80) from internal."id=36871 trace_id=310 msg="allocate a new session-000088a8"id=36871 trace_id=310 msg="find a route: gw-172.20.120.2 via wan1"id=36871 trace_id=310 msg="find SNAT: IP-172.20.120.11, port-53199"id=36871 trace_id=310 msg="Allowed by Policy-1: SNAT"
Allowing DNS queries to only one approved DNS server
Fh
Allowing DNS queries to only one approved DNS server
Problem How do I restrict all DNS queries to an approved DNS server on the Internet?
Solution Block all DNS sessions except for sessions to the approved DNS server.
To do this, create a firewall address for the approved DNS server and then add it to a security policy that uses the DNS service and allows access to the Internet. Create another security policy that blocks all DNS sessions.
Arrange the allow DNS policy above the more general deny DNS policy. Arrange both of these policies above any general policies that allow access to the Internet.
Make sure the devices on the internal network are configured to use the approved DNS server.
1 Go to Policy > Policy > Policy and select Create New to add a security policy to allow all users on the internal network to access the Internet.
2 Select Enable NAT and Use Destination Interface Address.
3 Select OK.
4 Go to Firewall Objects > Address > Address and select Create New and add a firewall address for the approved DNS server:
5 Select OK.
Source Interface/Zone internal
Source Address All
Destination Interface/Zone wan1
Destination Address All
Schedule always
Service ANY
Action ACCEPT
Some FortiGate models include this security policy in the default configuration. If you have one of these models, this step has already been done for you.
Allowing DNS queries to only one approved DNS server
Fh
Results Use the following steps to test the configuration.
1 Configure a PC on the internal network to use the 208.91.112.53 DNS server.
2 Attempt to browse the web from this PC.
You should be able to browse the web.
3 Go to Policy > Policy > Policy view the Count column for the security policies.
The policy 2 Count column should show that it is processing traffic. The policy monitor (at Policy > Monitor > Policy Monitor) should show that all sessions accepted by policy 2 are DNS sessions with a destination address of 208.91.112.53.
4 Enter the following command to verify DNS sessions from a PC with IP address 192.168.1.110 to IP address 208.91.112.53 are accepted by policy 2.
diagnose debug enable
diagnose debug flow show console enableshow trace messages on console
diagnose debug flow filter add 192.168.1.110
diagnose debug flow trace start 100
id=36871 trace_id=459 msg="vd-root received a packet(proto=17, 192.168.1.120:1207- >208.91.112.53:53) from internal."id=36871 trace_id=459 msg="allocate a new session-00009c6f"id=36871 trace_id=459 msg="find a route: gw-172.20.120.2 via wan1"id=36871 trace_id=459 msg="find SNAT: IP-172.20.120.11, port-42043"id=36871 trace_id=459 msg="Allowed by Policy-2: SNAT"id=36871 trace_id=459 msg="SNAT 192.168.1.120->172.20.120.11:42043"id=36871 trace_id=459 msg="run helper-dns-udp(dir=original)"
5 Change the PC to use a different but still valid DNS server on the Internet.
6 Attempt to browse the web.
Web browsing will not work because DNS lookups are blocked.
The policy 3 Count column should show that it is denying traffic.
7 Enter the following command to verify that DNS sessions from a PC with IP address 192.168.1.110 to a different DNS server are blocked.
diagnose debug enable
diagnose debug flow show console enableshow trace messages on console
diagnose debug flow filter add 192.168.1.110
diagnose debug flow trace start 100
id=36871 trace_id=409 msg="vd-root received a packet(proto=17, 192.168.1.120:1051->8.8.8.8:53) from internal."id=36871 trace_id=409 msg="allocate a new session-00009c09"id=36871 trace_id=409 msg="find a route: gw-172.20.120.2 via wan1"id=36871 trace_id=409 msg="Denied by forward policy check"
Ensuring sufficient and consistent bandwidth for VoIP traffic
Ensuring sufficient and consistent bandwidth for VoIP traffic
Problem You want to make sure that enough bandwidth is reserved through the FortiGate unit to adequately support the use of IP phones in the office.
Solution Using traffic shaping, you can configure shared shapers that ensure a consistent amount of bandwidth is reserved for VoIP/SIP communications and still maintain bandwidth for other Internet traffic such as email and web browsing. For this solution, 200000 kbits/s is guaranteed to be available for VoIP and VoIP traffic is given higher priority than other traffic. Other traffic is limited to a maximum bandwidth of 100000 kbits/s.
In this configuration, the internal IP phone network and internal network both connect to the FortiGate internal interface.
Create traffic shapers for VoIP traffic and for other traffic
1 Go to Firewall Objects > Traffic Shaper > Shared and select Create New to add a shared shaper for IP phone traffic:
2 Select OK.
3 Select Create New and add a shared shaper for other traffic:
Creating the firewall addresses for the IP phone and internal networks
1 Go to Firewall Objects > Address > Address and select Create New to add the engineering address range:
When creating a traffic shaper, you must include a data value for the Maximum Bandwidth and/or the Guaranteed Bandwidth as well as selecting the Traffic Priority.
Ensuring sufficient and consistent bandwidth for VoIP traffic
6 Select Enable NAT and Use Destination Interface Address.
7 Select Traffic Shaping and select the daily traffic shaper for both directions:
Results Phone usage has a guaranteed bandwidth and a higher priority than other standard Internet usage. As such, telephony use will not be degraded by other traffic between the internal network and the Internet.
Go to Firewall Objects > Monitor > Traffic Shaper Monitor and select Current Bandwidth to view the current bandwidth being used by active traffic shapers. If standard traffic volume is high enough, it will top out at the maximum bandwidth defined in each shaper,
To ensure that the shaper is in use, go to Log&Report > Log & Archive Access > Traffic Log. Filter the Service by SIP to see the telephony traffic.
Shared Traffic Shaper Daily_Traffic
Shared Traffic Shaper Reverse Direction Daily_Traffic
To monitor the data passing through the FortiGate unit for troubleshooting, remember to enable Log Allowed Traffic in both policies.
Problem You need to restrict employee access to the subversion servers at branch offices, located in Ireland, Brazil and Egypt, so that scheduled backups at these locations are uninterrupted.
Solution Create schedules for each branch office, as well as addresses with the geographic-based address feature.
The geographic-based addresses allow you to indicate the country, and the traffic originating or going to this country is logged, blocked or specific filtering is applied. The schedules, in this case, will block employee access to the servers at specified times.
For this solution, we are using Eastern Time zone (GMT -5:00) as the time zone for the location of the schedules and addresses.
Creating the geographic addresses
1 Go to Firewall Objects > Address > Address and create a new address.
2 Enter the name, branch_office_1 for the Address Name.
3 Select Geography from the Type list.
4 From the Country list, select Ireland.
5 Select wan1 from the Interface list.
6 Select OK.
7 Create the other two addresses using steps 2 to 6; use the names branch_office_2 for Brazil, and branch_office_3 for Egypt.
8 Go to Firewall Objects > Address > Group and create a group of the three addresses.
Creating the firewall schedules
1 Go to Firewall Objects > Schedule > Recurring.
2 Create a new schedule for the Ireland branch, and enter branch_office1 for the Name of the schedule.
3 Select Monday, Wednesday and Friday for the Day of Week.
4 Select 11:00 as the Start Time and 13:00 as the Stop Time.
5 Select OK to save the schedule.
6 Create a new schedule for Brazil and enter branch_office1 for the Name of the schedule.
7 For Day of Week, select Monday and Friday.
8 Select 16:00 as the Start Time and 18:00 as the Stop Time.
9 Select OK to save the schedule.
10 Create a new schedule for Egypt and enter branch_office3 for the Name of the schedule.
11 For Day of Week, select Tuesday and Saturday.
12 Select 11:00 as the Start Time and 13:00 as the Stop Time.
13 Select OK to save the schedule.
14 Go to Firewall Objects > Schedule > Group and group these three schedules.
Go to Policy > Policy > Policy, and apply both groups to a security policy.
Results Employee access to these servers should be blocked during the times specified in the firewall schedules. You can test this by trying to access a server in Ireland at 11:00 am your time; you should not be able to access the server.