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

Connecting multiple networks to a FortiGate interface using virtual LANs (VLANs)

Fh


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


IP/Netmask 192.168.20.1

Name Sales-net

Type VLAN

Interface internal

FortiGate Unitin NAT/Route mode

Engineeringnetwork

192.168.10.0VLAN ID 10

Marketingnetwork

192.168.20.0VLAN ID 20

Salesnetwork

192.168.30.0VLAN ID 30

VLANSwitch

FortiGaattttteee UUnit

V

Nchhhh

internal

wan1

einte

ortiOS 4.0 MR3 75 ttp://docs.fortinet.com/

http://docs.fortinet.com/


Add DHCP servers to each VLAN interface

1 Go to System > Network > DHCP Server and select Create New to add a DHCP server for the marketing network:

2 Select Create New to add a DHCP server for the engineering network:

3 Select Create New to add a DHCP server for the sales network:

4 Configure the devices on the networks to get their addresses using DHCP.

5 For devices with manual IP configurations, make sure their default routes point to the correct FortiGate VLAN interface.

VLAN ID 30


IP/Netmask 192.168.30.1

Interface Name Marketing-net

Mode Server

Type Regular

IP 192.168.10.100 - 192.168.10.200

Network Mask 255.255.255.0

Default Gateway 192.168.10.1

DNS Service Use System DNS Setting

Interface Name Engineering-net

Mode Server

Type Regular

IP 192.168.20.100 - 192.168.20.200




Interface Name Sales-net

Mode Server

Type Regular

IP 192.168.30.100 - 192.168.30.200




76 FortiGate Cookbook http://docs.fortinet.com/



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



Schedule Always

Service ANY

Action ACCEPT

Source Interface/Zone Sales-net

Source 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


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:

For company A:

For company B:

Name VDOM-A

Enable Select

Operation Mode NAT

Name VDOM-B

Enable Select

Operation Mode NAT

FortiGate Unitwith two Virtual

Domains

GatewayRouter

172.20.120.2

Company A192.168.10.0

Company B192.168.20.0

port1

172.20.120.10

port3

172.20.120.20

port2192.168.10.1

port4192.168.20.1

VDOM-A

VDOM-B




Fh

3 Go to System > Network > Interface and Edit port1 and add it to VDOM-A.

Edit port2 and add it to VDOM-A:

Edit port3 and add it to VDOM-B:

Edit port4 and add it to VDOM-B:

4 Go to System > Admin > Administrators and select Create New to add an administrator for VDOM-A.

Name port1

Virtual Domain VDOM-A

Addressing Mode Manual

IP/Netmask 172.20.120.10/255.255.255.0

Name port2



IP/Netmask 192.168.10.1/255.255.255.0

Administrative Access HTTPS, PING, SSH

Name port3

Virtual Domain VDOM-B


IP/Netmask 172.20.120.20/255.255.255.0

Name port4



IP/Netmask 192.168.20.1/255.255.255.0

Administrative Access HTTPS, PING, SSH

Administrator a-admin

Type Regular

Password passw0rda

Confirm Password passw0rda

Admin Profile prof_admin





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.

Administrator b-admin

Type Regular

Password passw0rdb

Confirm Password passw0rdb

Admin Profile prof_admin


Destination IP/Mask 0.0.0.0/0.0.0.0

Device port1

Gateway 172.20.120.2

Interface Name port2

Mode Server

Type Regular

IP 192.168.10.100-192.168.10.200



Source Interface/Zone port2

Source Address all

Destination Interface/Zone port1




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.


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.

Destination IP/Mask 0.0.0.0/0.0.0.0

Device port3

Gateway 172.20.120.2

Interface Name port4

Mode Server

Type Regular

IP 192.168.20.100-192.168.20.200






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.



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



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


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.

FortiGate Unit

DHCP Server

Internal Network

admin_profile

administrators maint_monitor

administrator




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.

Type Master

View Shadow

DNS Zone Internal

Domain Name company.com

Type Address (A)

Hostname info

IP Address 192.168.1.2

Interface Internal

Mode Recursive

FortiGateDNS DatabaseDN

Internal DNSQueries

Internal servername: info.company.comIP: 192.168.1.2

FortiGate Unit

Internal Network


Assigning IP addresses according to a MAC address using DHCP


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.

FortiGate Unit

DHCP Server

Internal Network

RESERVED ReservedIP: 10.10.10.18MAC: 00:13:72:38:6a:39


Setting up the FortiGate unit to send SNMP traps

Fh


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.

Description Company FortiGate unit

Location Head Office, server room

Contact [email protected]

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.

FortiGateSNMP AgentSN

?SNMPTraps

SNMPManagerIP: 192.168.1.10

FortiGate Unit

Internal Network



http://support.fortinet.com


Local-in policies

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:

config firewall addressedit local-address-rangeset associated-interface internalset type iprangeset start-ip 172.20.120.100set end-ip 172.20.120.110

endconfig firewall local-in-policyedit 0set intf internalset srcaddr local-address-rangeset dstaddr allset action acceptset service SNMPset schedule always

end

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.


http://eicar.org


Troubleshooting by sniffing packets (packet capture)

Fh


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:

diag sniffer packet {<interface> | any} {‘filter_str’| none } {1 | 2 | 3 | 4 | 5 | 6} <pkt_count>

Interface and filter arguments are required. To stop the sniffer, press Ctrl+C.

{ <interface> | any }The name of the FortiGate unit interface to sniff, such as “port1” or “internal” or “VLAN18”.

Alternatively use “any” to sniff all interfaces.




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.




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 example shows how to sniff one udp packet on any network of the FortiGate unit at verbosity level 6 to show the packet contents and interface.

# diag sniffer packet any 'udp' 6 1interfaces=[any]filters=[udp]1.865746 wan1 out 172.20.120.136.60718 -> 8.8.8.8.53: udp 350x0000 0000 0000 0000 0009 0f30 ca51 0800 4500.........0.Q..E.0x0010 003f cee2 0000 4011 771f ac14 7888 [email protected] 0808 ed2e 0035 002b c997 db37 0100 0001.....5.+...7....0x0030 0000 0000 0000 0361 7273 056f 7363 6172.......ars.exmpl0x0040 0361 6f6c 0363 6f6d 0000 0100 01 .aol.com.....

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.




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)


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

• specify a certain byte in a packet

The default format of the filter syntax is:

[[src|dst] host <host_name_or_IP1>] [[arp|ip|gre|esp|udp|tcp|icmp] [port_no]] [and | or] [..]

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.

diag sniffer packet any 'icmp and src host 172.20.120.136'interfaces=[any]filters=[icmp and src host 172.20.120.136]0.319302 172.20.120.136 -> 172.20.120.17: icmp: echo reply1.348780 172.20.120.136 -> 172.20.120.17: icmp: echo reply2.355177 172.20.120.136 -> 172.20.120.17: icmp: echo reply3.356008 172.20.120.136 -> 172.20.120.17: icmp: echo reply

4 packets received by filter0 packets dropped by kernel




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”




# diag sniffer packet any 'arp' 1 5interfaces=[any]filters=[arp]1.187291 arp who-has 192.168.100.1 tell 192.168.100.992.187125 arp who-has 192.168.100.1 tell 192.168.100.992.858334 arp who-has 172.20.120.228 tell 172.20.120.2242.889542 arp who-has 172.20.120.224 tell 172.20.120.2284.187019 arp who-has 192.168.100.1 tell 192.168.100.99

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:

# diagnose sniffer packet internal "(ether[26:4]=0xc0a80102)"

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.




Fh

# diagnose sniffer packet internal "tcp[13] & 4 != 0"

If you want to match packets with the SYN flag set:

# diagnose sniffer packet internal "tcp[13] & 2 != 0"

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)


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

Interface internal

Max Packets to Capture 100

Source Address 192.168.1.0/24

Source Port(s)

Destination Address 66.171.121.34/24

Destination Port 80

Protocol TCP

Include IPv6 Packets Disable

Capture Non-IP Packets Disable

110100011

01101000111

1001101011 110100011

01101000111

1001101011

???


http://www.tcpdump.org/

http://www.wireshark.org/



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.

Interface any

Max Packets to Capture 100

Static source NAT

between the

internal network

and the Internetinternal

192.168.1.99

wan1

172.20.120.14

Internal Network

192.168.1.0/255.255.255.0

312

src IP: 192.168.1.[1-255]

src port: [any]

dst IP: 172.20.120.101

dst port: 80

312

src IP: 172.20.120.14

src port: [any]

dst IP: 172.20.120.101

dst port: 80




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.



Debugging FortiGate configurations

Fh


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 infodiagnose debug <software-system> <debug-level>diagnose debug enablediagnose debug disable

The following debug commands are also useful:

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

312

32 1




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:

diagnose debug application authd -1diagnose debug enable

You can view all the debug options by entering diagnose debug ? or diagnose debug application ?




Fh

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:

#diag debug disable#diag debug application urlfilter -1#diag debug enable

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:

msg="received a request /tmp/.proxyworker000_0_0.url.socket, addr_len=38: d=www.example.ro:80, id=22, vfid=0, type=0, client=10.10.80.110, url=/favicon.ico"

Checking urlfilter list 4Url filter deny action

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.



Quick reference to common diagnose commands


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.

diagnose debug enablediagnose debug flow show console enablediagnose debug flow filter add 10.10.20.30diagnose debug flow trace start 100

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.

312

32 1


http://docs.fortinet.com/fgt/handbook/40mr3/fortigate-troubleshooting-40-mr3.pdf

http://docs.fortinet.com/fgt/handbook/40mr3/fortigate-troubleshooting-40-mr3.pdf



Fh

hardware deviceinfo disk

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.






Fh

WiFi Networking

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

• Authenticating WiFi users with Windows AD



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.

Interface Name wifi

IP/Netmask 10.10.10.1/255.255.255.0

SSID our_wifi

Address Range 10.10.10.10-10.10.10.19

Netmask 255.255.255.0

Default Gateway Same as Interface IP

DNS Server Same as System DNS

Security Mode WPA/WPA2-Personal

Data Encryption AES

Pre-shared Key justforus

FortiWiFi UnitFortiWiFi Uniitttt

Wirelessnetwork

Internal network




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.


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



Schedule always

Service ANY

Action ACCEPT


Source 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


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




4 Select OK.

Interface Name wifi

IP/Netmask 10.10.10.1/255.255.255.0

SSID our_wifi

Address Range 10.10.10.10-10.10.10.19

Netmask 255.255.255.0




Data Encryption AES


FortiGate Unit

Wirelessnetwork

Internal network

port3FortiA

P unit

internal

F tiG t UU it

port3p




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.


2 Select Create New to add a WiFi-to-Internet policy that allows WiFi users to access the Interne.


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 Address all



Schedule always

Service ANY

Action ACCEPT


Source Address all



Schedule always

Service ANY

Action ACCEPT


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.




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.


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.




Fh

Multicast WiFi controller discovery request:

port3 -- 192.168.8.2.5246 -> 224.0.1.140.5246: udp

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.

Broadcast WiFi controller discovery request:

port3 -- 192.168.8.2.5246 -> 255.255.255.255.5246: udp

This request on the CAPWAP control port 5246 should get a response from the WiFi controller at 192.168.8.1 on port 5246.

ARP request packet and response packets:

port3 -- arp who-has 192.168.8.2 tell 192.168.8.1port3 -- arp reply 192.168.8.2 is-at 0:9:f:d6:b9:71

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:

port3 -- 192.168.8.2.5246 -> 192.168.8.1.5246: udpport3 -- 192.168.8.1.5246 -> 192.168.8.2.5246: udp



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.



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.

Interface Name wifi

IP/Netmask 10.10.10.1/255.255.255.0

SSID our_wifi

FortiWiFi Unit

Internal network




Fh



4 Select OK.

5 Go to WiFi Controller > Managed Access Points > Local WiFi Radio and select Enable WiFi Radio.


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.



Address Range 10.10.10.10-10.10.10.100

Netmask 255.255.255.0



Security Mode WPA/WPA2-Enterprise

Data Encryption AES

Authentication Usergroup

Usergroup wifi_users


Source Address all



Schedule always

Service ANY

Action ACCEPT


Source Address all



Schedule always





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.


Service ANY

Action ACCEPT



Setting up secure WiFi with a captive portal

Fh


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.



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.

Interface Name wifi

IP/Netmask 10.10.10.1/255.255.255.0

SSID our_wifi

FortiGate Unit

Wirelessnetwork

Internal network

port3FortiA

P unit

internal

F tiG t UU it

port3p






4 Select OK.

5 Go to WiFi Controller > Managed Access Points > Local WiFi Radio and select Enable WiFi Radio.

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.


2 Select Create New to add a WiFi-to-Internet policy that allows WiFi users to access the Internet.


Address Range 10.10.10.10-10.10.10.210

Netmask 255.255.255.0



Security Mode Captive Portal

User Groups wifi_users


Source Address all



Schedule always

Service ANY

Action ACCEPT


Source Address all



Schedule always

Service ANY

Action ACCEPT




Fh

4 Select OK.

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.


In User > Monitor > Firewall, you can see the authenticated captive portal user:



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.


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.


4 Select OK to save the SSID.


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.


Data Encryption AES


You can extend the coverage area by connecting FortiAP units and adding the our_wifi SSID to them.

Name combo_lan

Type Software Switch

Physical Interface Members

wifi

port1

FortiWiFi Unit

Softwareswitch interface

combo_lan1010.10.1

Software switchnetwork

1010.10.0255.255.255.0

wifi

Internal network

FortiWiFi Unit

port1




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.


1 Go to Policy > Policy > Policy to create the security policy that enables users connected to the software switch to connect to the Internet.



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.


IP/Netmask 10.10.10.1/255.255.255.0

Interface Name combo_lan

Mode Server

Enable Selected

Type Regular

IP 10.10.10.2-10.10.10.199




Source Interface/Zone combo_lan

Source Address all



Schedule always

Service ANY

Action ACCEPT





You can also go to System > Monitor > DHCP Monitor to view information about all the address leases for both wired and wireless clients.



Setting up a WiFi network with an external DHCP server

Fh


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.



2 Clear the Enable DHCP checkbox to disable DHCP.


4 Select OK.


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.

Interface Name wifi

IP/Netmask 10.10.10.1/255.255.255.0

SSID our_wifi


Data Encryption AES


Interface Name wifi

Mode Relay

Type Regular

DHCP Server IP 192.168.1.101

FortiWiFi Unit

Internal network

DHCP server

192.168.1.101 Wirelessnetwork





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:




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.



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


Source Address all



Schedule always

Service ANY

Action ACCEPT




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.



Authenticating WiFi users with Windows AD


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.

FortiWiFi Unit

port1

wan1

wifi

Wirelessnetwork

WIndows AD

domain controller

172.20.120.32

Internal network




Fh

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.

6 Select OK.

Enable this RADIUS client Selected

Friendly name FortiWiFi_1

Address (IP or DNS) 172.20.120.32

Shared secret secure_value




Configure a connection request policy for the FortiWiFi unit

1 Open the Network Policy Server.

2 In the left pane, expand Policies.

3 Select Connection Request Policies. Right-click the default policy and select Delete.

4 In the left pane, right-click Connection Request Policies and select New. Enter the following information:

5 Select Next. Select Add.

6 Double-click NAS IPv4 Address and add the FortiWiFi unit’s IP Address: 172.20.120.32.

7 Select Next. Make sure that Authenticate Requests on this server is selected and then select Next.

8 Select Override network policy authentication settings.

9 Select Add, Select Microsoft: Protected EAP (PEAP), and then select OK.

10 Select the PEAP option in EAP Types and then select Edit.

11 Check that Certificate Issued has the appropriate CA certificate selected.

12 Ensure that Enforce Network Access Protection is selected. Select OK.

13 Select Next. Select Next again. Select Finish.

Configure Windows Security Health Validator

1 In the Server Manager left pane, go to Roles > Network Policy and Access > NPS (Local) > Network Access Protection > System Health Validators.

2 In the right pane, select Windows Security Health Validator. Select Settings. Double-click Default Configuration.

3 Ensure that only A firewall is enabled for all network connections is enabled. Select OK.

To configure health policies

1 In the Network Policy Server, expand Policies, right-click Health Policies, and select New.

2 Enter the following information and select OK:

3 In the left pane, right-click Health Policies, and select New.

4 Enter the following information and select OK:

Policy name FortiWiFi_1_policy

Type of network access server Unspecified

Policy name WiFi_compliant

Client SHV checks Client passes all SHV checks

SHVs used in this health policy Select Windows Security Health Validator

Policy name WiFi_noncompliant

Client SHV checks Client fails one or more SHV checks

SHVs used in this health policy Select Windows Security Health Validator




Fh

Configure network policies

1 In the Network Policy Server, expand Policies, right-click Network Policies, and select New.

2 In Policy name, enter NAP_WiFi_compliant and then select Next.

3 Select Add. Double-click Windows Groups. Add the WiFi_users group and select OK.

4 Select Add. Double-click NAS IPv4 Address. Add the FortiWiFi unit IP address and select OK.

5 Select Add. Double-click Health Policy. Add the WiFi_compliant policy and select OK.

6 Select Next. Ensure that Access Granted is selected. Select Next three times.

7 On the Configure Settings page, select Vendor Specific.

8 In the Attributes list, select Vendor-Specific and then select Add.

9 Select Add. Select Enter Vendor Code. Enter the Fortinet vendor code 12356.

10 Select Yes. It conforms.

11 Select Configure Attribute, enter the following information, and then select OK:

12 Select OK. Select Close. Select Next. Select Finish.

Configure the FortiWiFi unit

You need to:

• Add the NPS server.

• Configure the WiFi SSID, including security settings.

• Configure firewall addresses for the networks.

• Configure security policies.

• Enable the WiFi hardware.

Add the RADIUS (NPS) server to the FortiWiFi unit configuration

1 Go to User > Remote > RADIUS. Select Create New, enter the following information and then select OK:

Vendor-assigned attribute number 1

Attribute format String

Attribute value WiFi_users

Name Win_NPS

Type Query

Primary Server Name/IP 172.20.120.2

Primary Server Secret secure_value

Authentication Scheme Use Default Authentication Scheme




Configure your WiFi network SSID

1 Go to WiFi Controller > WiFi Network > SSID and select Create New to define your wireless network like this:



4 Go to Policy > Policy > Policy to create the security policies that enable WiFi users to connect to the office network and to the Internet.

WiFi-to-Office network policy

WiFi-to-Internet policy

Interface Name wifi

IP/Netmask 10.10.10.1/255.255.255.0

SSID our_wifi

Address Range 10.10.10.10-10.10.10.210

Netmask 255.255.255.0



Security Mode WPA/WPA2-Enterprise

Data Encryption AES

Authentication RADIUS Server, select Win_NPS


Source Address all



Enable NAT Selected


Source Address all



Enable NAT Selected




Fh


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.



Fh

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.

Static source NAT

between the

internal network

and the Internetinternal

192.168.1.99

wan1

172.20.120.14

Internal Network

192.168.1.0/255.255.255.0

312

src IP: 192.168.1.[1-255]

src port: [any]

dst IP: 172.20.120.101

dst port: 80

312

src IP: 172.20.120.14

src port: [any]

dst IP: 172.20.120.101

dst port: 80




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.




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



Restricting employees’ Internet access

Fh


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:


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

Start TimeHour 12

Minute 00

Stop TimeHour 14

Minute 00

Source Interface/Zone internal

Source Address all



Schedule lunch break

Service ANY

Action ACCEPT

Accessallowed

Internal network

AccessBlocked

wiki.example.com

svn.example.com

172.20.120.101

172.16.100.154

internal

wan1




Creating the security policy to allow unlimited access to selected Internet sites

1 Go to Firewall Objects > Address > Address and select Create New to add the wiki.example.net FQDN firewall address:

2 Select Create New to add the svn.example.com FQDN firewall address:

3 Select Create New to add the 172.20.120.101 firewall address:

4 Select Create New to add the 172.16.100.154 firewall address:

5 Select Create New to add the firewall address of a DNS server on the Internet. This example uses the Google DNS server 8.8.8.8:

Address Name wiki

Type FQDN

FQDN wiki.example.net

Interface wan1

Address Name svn

Type FQDN

FQDN svn.example.com

Interface wan1

Address Name 101 server

Type Subnet / IP Range

Subnet / IP Range 172.20.120.101/255.255.255.255

Interface wan1

Address Name 154 server


Subnet / IP Range 172.16.100.154/255.255.255.255

Interface wan1

Address Name dns server


Subnet / IP Range 8.8.8.8/255.255.255.255

Interface wan1




Fh

6 Go to Firewall Objects > Address > Group and select Create New to add a firewall address group:

7 Select OK.

8 Go to Policy > Policy > Policy and select Create New and add a security policy that allows unlimited access to selected addresses on the Internet.


10 Select OK.

Results If you have followed steps in order, your internal to wan1 policy list could look similar to the following:

• Policy 1 (the default policy available on many FortiGate units) to allow all traffic to access the Internet is at the top of the list.

• Policy 2 to allow access to the Internet between 12 and 2 is second.

• Policy 3 to allow access to a selected Internet addresses is third.

Use the following steps to test this configuration.

1 Disable or delete policy 1.

Otherwise all traffic will be accepted by this policy.

2 If possible, temporarily disable other policies.

Group Name Allowed addresses

Members

wiki

svn

101 server

154 server

dns server

You can add and remove addresses from this address group at any time to change the Internet addresses with unlimited access.


Source Address all


Destination Address Allowed addresses

Schedule always

Service ANY

Action ACCEPT




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.




Fh

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.





• 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"



Restricting Internet access per IP address

Fh


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


Subnet / IP Range 10.10.20.[100-150]

Interface internal

Address Name marketing


Subnet / IP Range 10.10.20.[30-50]

Interface internal

Name engineering-restrict

Day of Week Monday, Tuesday, Wednesday, Thursday, Friday

Start Time 12:00

Stop Time 14:00

Engineering

10.10.20.100-150

Marketing

10.10.20.3-50

Restrictingtraffic




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:


3 Select Create New to create the security policy for engineering:


5 Select OK.

Name marketing-all

Day of Week Monday, Tuesday, Wednesday, Thursday, Friday

Start Time 08:00

Stop Time 18:00


Source Address marketing



Schedule marketing-all

Service ANY

Action ACCEPT


Source Address engineering



Schedule engineering-restrict

Service ANY

Action ACCEPT




Fh

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


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.

Engineering

10.10.20.100-150

Marketing

10.10.20.3-50

Restrictingtraffic




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.




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




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.





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"




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.





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"



Ordering security policies


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.


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 Address All


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.

Address Name Blocked address


Subnet / IP Range 192.168.1.110/255.255.255.255

Interface internal


Source Address Blocked address

Internal network

192.168.1.0

255.255.255.0 Accessallowed

192.168.1.110Access

denied




Fh


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.



Schedule always

Service ANY

Action DENY




Packet flow

The following command sequence displays packet flow for packets from IP address 192.168.1.110 that are blocked by the deny policy.





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.





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


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.


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 Address All


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.

Address Name Approved dns server


Subnet/IP Range 208.91.112.53/255.255.255.255

Interface wan1

Appreoved DNS

Server

208.91.112.53

Internal network




6 Go to Policy > Policy > Policy and select Create New to add a policy that allows DNS sessions to access the approved DNS server:


8 Select OK.

9 Select Create New to add a policy to block all DNS sessions to the Internet:

If you completed the steps in order the internal to wan1 policy list should look similar to the following:

10 Select policy 2 and select Move To.

11 Move policy 2 Before policy 1.

12 Select policy 3 and select Move To.

13 Move policy 3 After policy 2.


Source Address all


Destination Address Approved dns server

Service DNS

Action ACCEPT


Source Address all



Service DNS

Action DENY




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.





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.





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


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.

Name VoIP

Apply Shaper Per Policy

Traffic Priority High

Maximum Bandwidth 16776000

Guaranteed Bandwidth 2000000

Name Daily_Traffic

Apply Shaper Per Policy

Traffic Priority Medium

Maximum Bandwidth 1000000

Address Name IP Phone net


Internal IP phone

networkInternal

network




Fh

2 Select Create New to add the marketing address range:

Create the security policies that include the traffic shapers

1 Go to Policy > Policy > Policy and select Create New and add a security policy for VoIP/SIP traffic:


3 Select Traffic Shaping and select the VoIP shaper for both directions:

4 Select OK.

5 Select Create New and add a security policy for other traffic from the Internal network to the Internet:

Subnet / IP Range 10.10.10.[10-50]

Interface internal

Address Name Internal net


Subnet / IP Range 10.10.10.[100-200]

Interface internal


Source address IP Phone net



Schedule always

Service SIP

Action ACCEPT

Shared Traffic Shaper VoIP

Shared Traffic Shaper Reverse Direction VoIP


Source address Internal net



Schedule always

Service ANY

Action ACCEPT





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.




Fh

Viewing the detailed information for a SIP log messages, the shaper name appears in the Sent Shaper Name field.



Using geographic addresses


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.



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.



14 Go to Firewall Objects > Schedule > Group and group these three schedules.

Branch office 1 - Ireland

172.16.144.15-155

Headquarters

172.26.120.1-155

Branch office 2 - Brazil

192.168.110.1-122

Branch office 3 - China

10.10.20.1-25




Fh

Applying the addresses and schedules to a policy

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.



Documents

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