1. Configuring the FortiAuthenticator
Go to Fortinet SSO Methods > SSO > General and configure these general settings.
Go to Fortinet SSO Methods > SSO > Domain Controllers and add the Windows DC to the FortiAuthenticator.
Go to Authentication > Remote Auth. Servers > LDAP to set the Windows AD as an LDAP server. This will be useful to import SSO Filtering Objects from Windows AD to the FortiAuthenticator.
Go to Fortinet SSO Methods > SSO > FortiGate Filtering and create a new FortiGate Filter. Under Fortinet Single Sign-On (FSSO), enable Forward FSSO information for users from the following subset of users/groups/containers only. Under SSO Filtering Objects, select Import. In the Remote LDAP Server field, select the LDAP server created in the previous step (WinLDAP in this example) and select Apply. Next, select groups or containers to be imported, controlled, and monitored by the FortiAuthenticator. In this example, the “FortiOS Writers” user group is selected.
2. Configuring SSO on the FortiGate
Go to User & Device > Single Sign-On and create a new SSO server. In the Type field, select Fortinet Single-Sign-On Agent and set the Name, the Primary Agent IP/Name, the Password and select Apply & Refresh. When selecting the Users/Groups field, the SSO user groups initially polled by the FortiAuthenticator from the Domain Controller appear. In this example, only the “FortiOS Writers” group appears because of the FortiGate Filtering configuration in the previous step.
3. Creating a user group on the FortiGate
Go to User & Device > User Groups and create a new Fortinet Single Sign-On (FSSO) user group. Under Members, select the user group to be monitored. In this example only “FortiOS Writers” appears because of the FortiGate Filtering configured earlier.
4. Adding a policy on the FortiGate
Go to Policy & Objects > IPv4 Policy and create a policy allowing  “FortiOS_writers” to navigate the Internet with appropriate security profiles. The default Web Filter security profile is used in this example.
5. Results from the FortiAuthenticator
Go to Monitor > SSO > Domains to verify monitored domains. In this example “techdoc.local” is monitored by the FortiAuthenticator.
Have users log on to the domain. Go to Monitor > SSO > SSO Sessions to verify SSO sessions.
Go to Logging > Log Access > Logs to verify logs.
Select an entry for details.
You can also verify FSSO users in the User Inventory widget under System > Dashboard > Status.
6. Results from the FortiGate
Upon successful authentication, go to Monitor > Firewall User Monitor and verify FSSO Logons.
Have authenticated users navigate the Internet. Security profiles will be applied accordingly.  Go to Log & Report > Forward Traffic to verify the log.
Select an entry for details.

The post SSO using a FortiGate, FortiAuthenticator, and DC Polling (Expert) appeared first on Fortinet Cookbook.

FortiToken Mobile lets you use FortiToken tokens for two-factor authentication, as well as third-party tokens used by Amazon, Dropbox, Google, and Microsoft. Two-factor authentication with FortiToken Mobile affords you the convenience and enhanced security of dynamically generated virtual passcodes.

In this recipe, you will enable Google’s 2-Step Verification and add the third-party token to FortiToken Mobile on your device. You will then be able to use the FortiToken Mobile third-party token to authenticate to your Google account, such as Gmail and YouTube.

You can download the latest FortiToken Mobile for Android on the Google Play store and for iOS on the iTunes app store.

1. Configure Google 2-Step Verification on the browser
Open a browser and log in to your Google account at https://myaccount.google.com. Select Sign-in & security.
Under Signing in to Google, select 2-Step Verification (re-enter your password if necessary) and select Start setup.
Enter your phone number, select to have your code sent to you by Text message (SMS), and select Send code. Shortly afterwards you will receive an SMS text message with a 6-digit verification code.
Enter the verification code in your browser and select Verify.
Elect to Trust this computer and select Next.
To confirm the 2-Step Verification set up, select Confirm.
You will be redirected to your Google 2-Step Verification page. Select Switch to app.
Select your phone type (Android, iPhone, or Blackberry) and select Continue.
2. Add Google 2-Step Verification to FortiToken
Open FortiToken Mobile on your phone and enter your 4-digit PIN. Select Add account.
Select Scan Barcode or Enter Manually. If you choose to Enter Manually, make sure to select 3rd Party Accounts > Other. The account name will be the email address of the user.
Scan the barcode presented in the Google Authenticator set up window, or select Can’t scan the barcode? to view and enter the secret key into FortiToken Mobile manually.
FortiToken Mobile will begin producing Google authentication codes.
In the Google Authenticator set up window, enter the 6-digit code presented in FortiToken Mobile and select Verify and Save.
3. Results
When attempting to log in to a Google account (Gmail or YouTube for example), the user will be prompted to enter their verification code. Enter the code displayed in FortiToken Mobile and select Done.

The post Configuring third-party authentication with FortiToken Mobile appeared first on Fortinet Cookbook.

In this recipe, you will use a Web Application Firewall profile to protect web applications, such as Internet browsers, from being attacked. In this example, the default profile will be targeted to block SQL injection attempts, as well as generic attacks.

Web Application Firewall is only available when Inspection Mode is Proxy-based.

1. Enabling Web Application Firewall
Go to System > Features and enable Web Application Firewall. Select Show More and enable Multiple Security Profiles. Apply your changes.
2. Editing the default Web Application Firewall profile
Web Application Firewall profiles are created with a variety of options, called Signatures and Constraints. Once these options are enabled, Action can be set to Allow, Monitor, or Block, and Severity can be set to High, Medium, or Low. You can also use a Web Application Firewall profile to enforce an HTTP method policy, which controls the HTTP method allowed when accessing websites that match the specified pattern.
Go to Security Profiles > Web Application Firewall and edit the default profile. In this example, the signatures for SQL Injection (Extended) and Generic Attacks (Extended) have been enabled, with the Action set to Block and Severity set to High.
3. Applying the profile to a security policy
Go to Policy & Objects > IPv4 Policies and edit the policy that allows connections from the internal network to the Internet. Under Security Profiles, enable Web Application Firewall and set it to use the default profile. Set the appropriate Proxy Option and set SSL/SSH Inspection to use the deep-inspection profile.
4. Results
Long URLs, such as this link, can be used to simulate an attack on your web browser. After selecting one of these links, a replacement message will appear, stating that the transfer has been blocked by the Web Application Firewall.
Go to Log & Report > Web Application Firewall and filter for Action: block to view information about blocked traffic.
5. Offloading to a FortiWeb
If you have a FortiWeb, you may be able to offload the functions of the Web Application Control to your FortiWeb. To find out if this option is available, refer to the FortiOS or FortiWeb Release Notes for information about device compatibility.
Go to System > External Security Devices and enable HTTP Service. Enter your FortiWeb’s IP address. If necessary, enable Authentication and enter the FortiWeb’s password.

The post Protecting web applications appeared first on Fortinet Cookbook.

A PDF of the complete FortiGate Cookbook 5.4 is now available here.

The post Complete FortiGate Cookbook 5.4 available in PDF appeared first on Fortinet Cookbook.

For those who follow security news, you are probably aware of an issue in the glibc library called CVE-2015-0235 (making this issue sound even scarier, it is also referred to as GHOST). A number of Fortinet products use this library; however, the impact on these Fortinet products is not as frightening as the name of the vulnerability implies.

For a complete explanation, Fortinet has put out an advisory at http://www.fortiguard.com/advisory/2015-01-28-cve-2015-0235-ghost-vulnerability

For more information on GHOST, here are some useful links to check out:

• https://access.redhat.com/articles/1332213
• https://isc.sans.edu/forums/diary/New+Critical+GLibc+Vulnerability+CVE20150235+aka+GHOST/19237/
• http://www.symantec.com/connect/blogs/linux-ghost-vulnerability-cve-2015-0235-not-scary-it-looks
• https://nakedsecurity.sophos.com/2015/01/29/the-ghost-vulnerability-what-you-need-to-know/

The post Fortinet and the GHOST Vulnerability appeared first on Fortinet Cookbook.

In this recipe, you will configure the FortiGate for captive portal access so users can log on to your WiFi network.

You will create a user account (rgreen), add it to a user group (employees), create a captive portal SSID (example-staff), and configure a FortiAP unit. When the user attempts to browse the Internet, they will be redirected to the captive portal login page and asked to enter their username and password.

1. Creating the user
Go to User & Device > User Definition and create a Local user (rgreen). Create additional users if needed, and assign any authentication methods.
2. Creating the user group
Go to User & Device > User Groups and create a user group (employees). Add rgreen to the group.
3. Creating the SSID
Go to WiFi Controller > SSID and configure the wireless network. Enter an Interface Name (example-wifi) and IP/Network Mask.
An address range under DHCP Server will be automatically configured.
Under WiFi Settings, enter an SSID name (example-staff), set Security Mode to Captive Portal, and add the employees user group.
4. Creating the security policy
Go to Policy & Objects > Addresses and create a new address for the SSID (example-wifi-net). Set Subnet/IP Range to the same range set on the DHCP server in the previous step. Set Interface to the SSID interface.
Go to Policy & Objects > IPv4 Policy and create a new policy for WiFi users to connect to the Internet. Add both the example-wifi-net address and employees user group to Source.
5. Connecting and authorizing the FortiAP
Go to Network > Interfaces and edit an available interface. Configure the interface so it is dedicated to extension devices, and assign it an IP address.
Connect the FortiAP unit to the configured interface, then go to WiFi Controller > Managed FortiAPs. The FortiAP is listed, but its State shows a greyed-out question mark — this is because it is waiting for authorization. Highlight the FortiAP and select Authorize.
The question mark is now replaced by a red down-arrow — this is because it is authorized, but still offline.
Go to WiFi Controller > FortiAP Profiles and edit the profile. For each radio, enable Radio Resource Provision and select your SSID.
Go back to WiFi Controller > Managed FortiAPs to verify that the FortiAP unit is online.
6. Results
When a user attempts to connect to the wireless network, they will be redirected to the captive portal login screen. Members of the employees group must enter their Username and Password. The user will then be redirected to the URL originally requested.
On the FortiGate, go to Monitor > WiFi Client Monitor to verify that the user is authenticated.

The post Captive portal WiFi access control appeared first on Fortinet Cookbook.

This page contains information to help you troubleshoot wireless network issues.

In the following sections, you will learn basic troubleshooting techniques for a secure Fortinet wireless LAN including:

• strategies for troubleshooting Fortinet wireless devices
• how to avoid common misconfigurations
• solutions to connectivity issues
• capturing and analyzing wireless traffic
• wireless debug commands

The goal is to provide you with practical knowledge that you can use to troubleshoot the FortiOS wireless controller and FortiAP devices. This includes how to use tools and apply CLI commands for maintenance and troubleshooting of your wireless network infrastructure, analyze problems per OSI layer, explore diagnostics for commissioning issues regarding at-client and access point connectivity problems, and understand the packet sniffer technique as a strong troubleshooting tool.

Note that the GUI paths mentioned are for FortiOS 5.4 and may differ from earlier FortiOS versions. Likewise, some CLI may be slightly different, unless otherwise indicated.

Signal strength issues

Poor signal strength is possibly the most common customer complaint. Below you will learn where to begin identifying and troubleshooting poor signal strength, and learn what information you can obtain from the customer to help resolve signal strength issues.

Asymmetric power issue

Asymmetric power issues are a typical problem. Wireless is two-way communication; high power access points (APs) can usually transmit a long distance, however, the client’s ability to transmit is usually not equal to that of the AP and, as such, cannot return transmission if the distance is too far.

Measuring signal strength in both directions

To solve an asymmetric power issue, measure the signal strength in both directions. APs usually have enough power to transmit long distances, but sometimes battery-powered clients have a reply signal that has less power, and therefore the AP cannot detect their signal.

It is recommended that you match the transmission power of the AP to the least powerful wireless client—around 10 decibels per milliwatt (dBm) for iPhones and 14dBm for most laptops.

Even if the signal is strong enough, other devices may be emitting radiation as well, causing interference. To identify the difference, read the client Rx strength from the FortiGate GUI (under Monitor > WiFi Client Monitor) or CLI.

The Signal Strength/Noise value provides the received signal strength indicator (RSSI) of the wireless client. For example, A value of -85dBm to -95dBm is equal to about 10dB levels; this is not a desirable signal strength. In the following screenshot, one of the clients is at 18dB, which is getting close to the perimeter of its range.

Note: The Signal Strength/Noise value received from the FortiAP  by clients, and vice versa, should be within the range of -20dBm to -65dBm.

You can also confirm the transmission (Tx) power of the controller on the AP profile (wtp-profile) and the FortiAP (iwconfig), and check the power management (auto-Tx) options.

Controller configured transmitting power – CLI:

config wireless-controller wtp-profile
  config <radio>
    show
    (the following output is limited to power levels)
      auto-power-level : enable
      auto-power-high : 17
      auto-power-low : 10

Actual FortiAP transmitting power – CLI:

iwconfig wlan00

Result:
wlan00      IEEE 802.11ng   ESSID:"signal-check"
Mode:Master Frequency:2.412 GHz    Access Point:<MAC add>
Bit Rate:130 Mb/s   Tx-Power=28 dBm

Using FortiPlanner PRO with a site survey

The most thorough method to solve signal strength issues is to perform a site survey. To this end, Fortinet offers the FortiPlanner, downloadable at http://www.fortinet.com/resource_center/product_downloads.html.

Sample depiction of a site survey using FortiPlanner

The site survey provides you with optimal placement for your APs based on the variables in your environment. You must provide the site survey detailed information including a floor plan (to scale), structural materials, and more. It will allow you to place the APs on the map and adjust the radio bands and power levels while providing you with visual wireless coverage.

Below is a list of mechanisms for gathering further information on the client for Rx strength. The goal is to see how well the client is receiving the signal from the AP. You can also verify FortiAP signal strength on the client using WiFi client utilities, or third party utilities such as InSSIDer or MetaGeek Chanalyzer. You can get similar tools from the app stores on Android and iOS devices.

• Professional Site Survey software (Ekahau, Airmagnet survey Pro, FortiPlanner)
• InSSIDer
• On Windows: “netsh wlan show networks mode=bssid” (look for the BSSID, it’s in % not in dBm!)
• On MacOS: Use the “airport” command:
  “/System/Library/PrivateFrameworks/Apple80211.framework/Versions/A/Resources/airport” airport –s | grep <the_bssid> (live scan each time)
• On Droid: WiFiFoFum

Frequency interference

If the wireless signal seems to be strong but then periodically drops, this may be a symptom of frequency interference. Frequency interference is when another device also emits radio frequency using the same channel, co-channel, or adjacent channel, thereby overpowering or corrputing your signal. This is a common problem on a 2.4GHz network.

There are two types of interference: coherent and non-coherent.

• Coherent interference: a result of another device using the same channel as your AP, or poor planning of a wireless infrastructure (perhaps the other nearby APs are using the same channel or the signal strength is too high).
• Non-coherent interference: a result of other radio signals such as bluetooth, microwave, cordless phone, or (as in medical environments) x-ray machines.

Most common and simple solution for frequency interference is to change your operation channel. Typically, the channel can be set from 1 to 11 for the broadcast frequency, although you should always use channels 1, 6, and 11 on the 2.4GHz band.

Another solution, if it’s appropriate for your location, is to use the 5GHz band instead.

MetaGeek Chanalyzer

You can perform a site survey using spectrum analysis at various points in your environment looking for signal versus interference/noise. MetaGeek Chanalyzer is an example of a third party utility which shows a noise threshold.

Note that a signal of -95dBm or less will be ignored by Fortinet wireless adapters.

Throughput issues

Sometimes communication issues can be caused by low performance.

Testing the link

You can identify delays or lost packets by sending ping packets from your wireless client. If there is more than 10ms of delay, there may be a problem with your wireless deployment, such as:

• a weak transmit signal from the client (the host does not reach the AP)
• the AP utilization is too high (your AP could be saturated with connected clients)
• interference (third party signal could degrade your AP or client’s ability to detect signals between them)
• weak transmit power from the AP (the AP does not reach the host) — not common in a properly deployed network, unless the client is too far away

Keep in mind that water will also cause a reduction in radio signal strength for those making use out of outdoor APs or wireless on a boat.

Performance testing

If the FortiAP gives bad throughput to the client, the link may drop. The throughput or performance can be measured on your smartphone with third party applications tool such as iPerf and jPerf.

Measuring file transfer speed

Another way to get a sense of your throughput issues is to measure the speed of a file transfer on your network. Create a test file at a specific size and measure the speed at which Windows measures the transfer. The command below will create a 50MB file.

• fsutil file createnew test.txt 52428800

The following image shows a network transfer speed of just over 24Mbps. The theoretical speed of 802.11g is 54Mbps, which is what this client is using. A wireless client is never likely to see the theoretical speed.

TKIP limitation

If you find that throughput is a problem, avoid WPA security encrypted with Temporal Key Integrity Protocol (TKIP) as it supports communications only at 54Mbps. Use WPA-2 AES instead.

Speeds are very much based on what the client computer can handle as well. The maximum client connection rate of 130Mbps is for 2.4GHz on a 2×2, or 300Mbps for 5Ghz on a 2×2 (using shortguard and channel bonding enabled).

If you want to get more than 54Mbps with 802.11n, do not use legacy TKIP, use CCMP instead. This is standard for legacy compatibility.

Preventing IP fragmentation in CAPWAP

TKIP is not the only possible source of decreased throughput. When a wireless client sends jumbo frames using a CAPWAP tunnel, it can result in data loss, jitter, and decreased throughput.

Using the following commands you can customize the uplink rates and downlink rates in the CAPWAP tunnel to prevent fragmentation and avoid data loss.

config wireless-controller wtp
  edit new-wtp
  (in 5.2, you must enable the override profile: set override-profile enable)
  (in 5.4, you must enable override-ip-fragment: set override-ip-fragment enable)
    set ip-fragment-preventing [tcp-mss-adjust | icmp-unreachable]
    set tun-mtu-uplink [0 | 576 | 1500]
    set tun-mtu-downlink [0 | 576 | 1500]
  end
end

The default value is 0, however the recommended value will depend on the type of traffic. For example, IPsec in tunnel mode has 52 bytes of overhead, so you might use 1400 or less for uplink and downlink.

Slowness in the DTLS response

It’s important to know all the elements involved in the CAPWAP association:

• Request
• Response
• DTLS
• Join
• Configuration

All of these are bidirectional. So if the DTLS response is slow, this might be the result of a configuration error. This issue can also be caused by a certificate during discovery response. You can read more about this in RFC 5416.

Connection issues

If the client has a connectivity issue that is not due to signal strength, the solution varies by the symptom.

Client connection issues

1. If client is unable to connect to FortiAP:

   •  Make sure the client’s security and authentication settings match with FortiAP and check the certificates as well.
   •  Try upgrading the Wi-Fi adapter driver and FortiGate/FortiAP firmware.
   If other clients can connect, it could be interoperability; run debug commands and sniffer packets.
   •  Look for rogue suppression by sniffing the wireless traffic and looking for the disconnect in the output (using the AP or wireless packet sniffer).
   •  Try changing the IEEE protocol from 802.11n to 802.11bg or 802.11a only.

2. If the client drops and reconnects:

   •  The client might be de-authenticating periodically. Check the sleep mode on the client.
   •  The issue could be related to power-saver settings. The client may need to udpate drivers.
   •  The issue could also be caused by flapping between APs. Check the roaming sensitivity settings on the client or the preferred wireless network settings on the client—if another WiFi network is available, the client may connect to it if it is a preferred network. Also, check the DHCP configuration as it may be an IP conflict.

3. If the client drops and never connects:

   •  It could have roamed to another SSID, so check the standby and sleep modes.
   •  You may need to bring the interface up and down.

4. If the client connects, but no IP address is acquired by the client:

   •  Check the DHCP configuration and the network.
   •  It could be a broadcast issue, so check the WEP encryption key and set a static IP address and VLANs.

Debug

You should also enable client debug on the controller for problematic clients to see the stage at which the client fails to connect. Try to connect from the problematic client and run the following debug command, which allows you to see the four-way handshake of the client association:

diagnose wireless-controller wlac sta_filter <client MAC address> 2

Example of a successful client connection:

The following is a sample debug output for the above command, with successful association/DHCP phases and PSK key exchange (identified in color):

FG600B3909600253 #
91155.197 <ih> IEEE 802.11 mgmt::assoc_req <== 30:46:9a:f9:fa:34 vap signal-check rId 0 wId 0 00:09:0f:f3:20:45
91155.197 <ih> IEEE 802.11 mgmt::assoc_resp ==> 30:46:9a:f9:fa:34 vap signal-check rId 0 wId 0 00:09:0f:f3:20:45 resp 0
91155.197 <cc> STA_CFG_REQ(15) sta 30:46:9a:f9:fa:34 add ==> ws (0-192.168.35.1:5246) rId 0 wId 0
91155.197 <dc> STA add 30:46:9a:f9:fa:34 vap signal-check ws (0-192.168.35.1:5246) rId 0 wId 0 bssid 00:09:0f:f3:20:45 NON-AUTH
91155.197 <cc> STA add 30:46:9a:f9:fa:34 vap signal-check ws (0-192.168.35.1:5246) rId 0 wId 0 00:09:0f:f3:20:45 sec WPA2 AUTO auth 0
91155.199 <cc> STA_CFG_RESP(15) 30:46:9a:f9:fa:34 <== ws (0-192.168.35.1:5246) rc 0 (Success)
91155.199 <eh> send 1/4 msg of 4-Way Handshake
91155.199 <eh> send IEEE 802.1X ver=1 type=3 (EAPOL_KEY) data len=95 replay cnt 1
91155.199 <eh> IEEE 802.1X (EAPOL 99B) ==> 30:46:9a:f9:fa:34 ws (0-192.168.35.1:5246) rId 0 wId 0 00:09:0f:f3:20:45
91155.217 <eh> IEEE 802.1X (EAPOL 121B) <== 30:46:9a:f9:fa:34 ws (0-192.168.35.1:5246) rId 0 wId 0 00:09:0f:f3:20:45
91155.217 <eh> recv IEEE 802.1X ver=1 type=3 (EAPOL_KEY) data len=117
91155.217 <eh> recv EAPOL-Key 2/4 Pairwise replay cnt 1
91155.218 <eh> send 3/4 msg of 4-Way Handshake
91155.218 <eh> send IEEE 802.1X ver=1 type=3 (EAPOL_KEY) data len=175 replay cnt 2
91155.218 <eh> IEEE 802.1X (EAPOL 179B) ==> 30:46:9a:f9:fa:34 ws (0-192.168.35.1:5246) rId 0 wId 0 00:09:0f:f3:20:45
91155.223 <eh> IEEE 802.1X (EAPOL 99B) <== 30:46:9a:f9:fa:34 ws (0-192.168.35.1:5246) rId 0 wId 0 00:09:0f:f3:20:45
91155.223 <eh> recv IEEE 802.1X ver=1 type=3 (EAPOL_KEY) data len=95
91155.223 <eh> recv EAPOL-Key 4/4 Pairwise replay cnt 2
91155.223 <dc> STA chg 30:46:9a:f9:fa:34 vap signal-check ws (0-192.168.35.1:5246) rId 0 wId 0 bssid 00:09:0f:f3:20:45 AUTH
91155.224 <cc> STA chg 30:46:9a:f9:fa:34 vap signal-check ws (0-192.168.35.1:5246) rId 0 wId 0 00:09:0f:f3:20:45 sec WPA2 AUTO auth 1
91155.224 <cc> STA_CFG_REQ(16) sta 30:46:9a:f9:fa:34 add key (len=16) ==> ws (0-192.168.35.1:5246) rId 0 wId 0
91155.226 <cc> STA_CFG_RESP(16) 30:46:9a:f9:fa:34 <== ws (0-192.168.35.1:5246) rc 0 (Success)
91155.226 <eh> ***pairwise key handshake completed*** (RSN)
91155.257 <dc> DHCP Request server 0.0.0.0 <== host ADMINFO-FD4I2HK mac 30:46:9a:f9:fa:34 ip 172.16.1.16
91155.258 <dc> DHCP Ack server 172.16.1.1 ==> host mac 30:46:9a:f9:fa:34 ip 172.16.1.16 mask 255.255.255.0 gw 172.16.1.1

where:

• orange represents the association phase,
• blue represents the PSK exchange,
• and green represents the DHCP phase.

It is important to note the messages for a correct association phase, four-way handshake, and DHCP phase.

FortiAP connection issues

Clients are not the only device that can fail to connect, of course. A communication problem could arise from the FortiAP.

Some examples include:

• The FortiAP is not connecting to the wireless controller.
• One FortiAP intermittently disconnects and re-connects.
• All FortiAPs intermittently disconnect and re-connect.
• Unable to Telnet to FortiAP from controller/administrator workstation.

In the above cases:

• Check networking on the distribution system for all related FortiAPs.
• Check the authorization status of managed APs from the wireless controller.
• Restart the cw_acd process (Note: All APs will drop if you do this, and you may be troubleshooting just one AP).
• Check the controller crash log for any wireless controller daemon crash using the following command:

  diagnose debug crashlog read

Debug

For a quick assessment of the association communication between the controller and the FortiAP, run the following sniffer command to see if you can verify that the AP is communicating to the controller by identifying the CAPWAP communication:

diagnose sniff packet <interface_name> “port 5246” 4 

If you do not see this communication, then you can investigate the network or the settings on the AP to see why it is not reaching the controller.

The following command allows you to collect verbose output from the sniff that can be converted to a PCAP and viewed in Wireshark.

diagnose sniff packet <interface_name> “port 5246” 6 o l

The image below shows the beginning of the AP’s association to the controller. You can see the discovery Request and Response at the top.

Throughout debugging it is recommended to:

• Enable Telnet login to the FortiAP device so that you can log in and issue local debugging commands:

config wireless-controller wtp
  edit "<FortiAP_serial_number>"
    set override-allowaccess {disable|enable}
    set allowaccess {telnet|http}
  end

• Try to connect to the wireless controller from the problematic FortiAP to verify routes exist.
• Enable wtp (FortiAP) debugging on the wireless controller for problematic FortiAPs to determine the point at which the FortiAP fails to connect:

diag wireless-controller wlac wtp_filter FP112B3X13000193 0-192.168.6.8:5246 2
(replace the serial number and IP address of the FortiAP)
di de console timestamp en
di de application cw_acd 0x7ff
di de en

Example of a successful AP and controller association:

The previous debug command provides similar output to the sample debug message below for a successful association between the FortiAP and the wireless controller. This includes the elements of the CAPWAP protocol; the Request, Response, DTLS, Join, and Configuration (identified in color). All of these are bi-directional, so if the DTLS response is slow, it may be an example of a configuration error.

56704.575 <msg> DISCOVERY_REQ (12) <== ws (0-192.168.35.1:5246)
56704.575 <msg> DISCOVERY_RESP (12) ==> ws (0-192.168.35.1:5246)
56707.575 <msg> DISCOVERY_REQ (13) <== ws (0-192.168.35.1:5246)
56707.575 <msg> DISCOVERY_RESP (13) ==> ws (0-192.168.35.1:5246)
56709.577 <aev> - CWAE_INIT_COMPLETE ws (0-192.168.35.1:5246)
56709.577 <aev> - CWAE_LISTENER_THREAD_READY ws (0-192.168.35.1:5246)
56709.577 <fsm> old CWAS_START(0) ev CWAE_INIT_COMPLETE(0) new CWAS_IDLE(1)
56709.577 <fsm> old CWAS_IDLE(1) ev CWAE_LISTENER_THREAD_READY(1) new CWAS_DTLS_SETUP(4)
56709.623 <aev> - CWAE_DTLS_PEER_ID_RECV ws (0-192.168.35.1:5246)
56709.623 <aev> - CWAE_DTLS_AUTH_PASS ws (0-192.168.35.1:5246)
56709.623 <aev> - CWAE_DTLS_ESTABLISHED ws (0-192.168.35.1:5246)
56709.623 <fsm> old CWAS_DTLS_SETUP(4) ev CWAE_DTLS_PEER_ID_RECV(7) new CWAS_DTLS_AUTHORIZE(2)
56709.623 <fsm> old CWAS_DTLS_AUTHORIZE(2) ev CWAE_DTLS_AUTH_PASS(3) new CWAS_DTLS_CONN(5)
56709.623 <fsm> old CWAS_DTLS_CONN(5) ev CWAE_DTLS_ESTABLISHED(8) new CWAS_JOIN(7)
56709.625 <msg> JOIN_REQ (14) <== ws (0-192.168.35.1:5246)
56709.625 <aev> - CWAE_JOIN_REQ_RECV ws (0-192.168.35.1:5246)
56709.626 <fsm> old CWAS_JOIN(7) ev CWAE_JOIN_REQ_RECV(12) new CWAS_JOIN(7)
56709.629 <msg> CFG_STATUS (15) <== ws (0-192.168.35.1:5246)
56709.629 <aev> - CWAE_CFG_STATUS_REQ ws (0-192.168.35.1:5246)
56709.629 <fsm> old CWAS_JOIN(7) ev CWAE_CFG_STATUS_REQ(13) new CWAS_CONFIG(8)
56710.178 <msg> CHG_STATE_EVENT_REQ (16) <== ws (0-192.168.35.1:5246)
56710.178 <aev> - CWAE_CHG_STATE_EVENT_REQ_RECV ws (0-192.168.35.1:5246)
56710.178 <fsm> old CWAS_CONFIG(8) ev CWAE_CHG_STATE_EVENT_REQ_RECV(23) new CWAS_DATA_CHAN_SETUP(10)
56710.220 <aev> - CWAE_DATA_CHAN_CONNECTED ws (0-192.168.35.1:5246)
56710.220 <msg> DATA_CHAN_KEEP_ALIVE <== ws (0-192.168.35.1:5246)
56710.220 <aev> - CWAE_DATA_CHAN_KEEP_ALIVE_RECV ws (0-192.168.35.1:5246)
56710.220 <msg> DATA_CHAN_KEEP_ALIVE ==> ws (0-192.168.35.1:5246)
56710.220 <fsm> old CWAS_DATA_CHAN_SETUP(10) ev CWAE_DATA_CHAN_CONNECTED(32) new CWAS_DATA_CHECK(11)
56710.220 <aev> - CWAE_DATA_CHAN_VERIFIED ws (0-192.168.35.1:5246)
56710.220 <fsm> old CWAS_DATA_CHECK(11) ev CWAE_DATA_CHAN_KEEP_ALIVE_RECV(35) new CWAS_DATA_CHECK(11)
56710.220 <fsm> old CWAS_DATA_CHECK(11) ev CWAE_DATA_CHAN_VERIFIED(36) new CWAS_RUN(12)
56710.228 <msg> WTP_EVENT_REQ (17) <== ws (0-192.168.35.1:5246)
56710.228 <aev> - CWAE_WTP_EVENT_REQ_RECV ws (0-192.168.35.1:5246)
56710.228 <fsm> old CWAS_RUN(12) ev CWAE_WTP_EVENT_REQ_RECV(42) new CWAS_RUN(12)
56710.230 <msg> CFG_UPDATE_RESP (1) <== ws (0-192.168.35.1:5246) rc 0 (Success)
56710.230 <aev> - CWAE_CFG_UPDATE_RESP_RECV ws (0-192.168.35.1:5246)
56710.230 <msg> WTP_EVENT_REQ (18) <== ws (0-192.168.35.1:5246)
56710.230 <aev> - CWAE_WTP_EVENT_REQ_RECV ws (0-192.168.35.1:5246)
56710.230 <fsm> old CWAS_RUN(12) ev CWAE_CFG_UPDATE_RESP_RECV(37) new CWAS_RUN(12)
56710.230 <fsm> old CWAS_RUN(12) ev CWAE_WTP_EVENT_REQ_RECV(42) new CWAS_RUN(12)
56710.231 <msg> WTP_EVENT_REQ (19) <== ws (0-192.168.35.1:5246)
56710.231 <aev> - CWAE_WTP_EVENT_REQ_RECV ws (0-192.168.35.1:5246)
56710.231 <fsm> old CWAS_RUN(12) ev CWAE_WTP_EVENT_REQ_RECV(42) new CWAS_RUN(12)
56710.232 <msg> CFG_UPDATE_RESP (2) <== ws (0-192.168.35.1:5246) rc 0 (Success)
56710.232 <aev> - CWAE_CFG_UPDATE_RESP_RECV ws (0-192.168.35.1:5246)
56710.232 <fsm> old CWAS_RUN(12) ev CWAE_CFG_UPDATE_RESP_RECV(37) new CWAS_RUN(12)
56710.233 <msg> WTP_EVENT_REQ (20) <== ws (0-192.168.35.1:5246)
56710.233 <aev> - CWAE_WTP_EVENT_REQ_RECV ws (0-192.168.35.1:5246)
56710.233 <fsm> old CWAS_RUN(12) ev CWAE_WTP_EVENT_REQ_RECV(42) new CWAS_RUN(12)
56712.253 < . > AC (2) -> WTP (0-192.168.35.1:5246) State: CWAS_RUN (12) accept 3 live 3 dbg 00000000 pkts 12493 0
56715.253 < . > AC (2) -> WTP (0-192.168.35.1:5246) State: CWAS_RUN (12) accept 3 live 6 dbg 00000000 pkts 12493 0
56718.253 < . > AC (2) -> WTP (0-192.168.35.1:5246) State: CWAS_RUN (12) accept 3 live 9 dbg 00000000 pkts 12493 0
56719.253 <aev> - CWAE_AC_ECHO_INTV_TMR_EXPIRE ws (0-192.168.35.1:5246)
56719.253 <fsm> old CWAS_RUN(12) ev CWAE_AC_ECHO_INTV_TMR_EXPIRE(39) new CWAS_RUN(12)
56719.576 <msg> ECHO_REQ (21) <== ws (0-192.168.35.1:5246)
56719.576 <aev> - CWAE_ECHO_REQ_RECV ws (0-192.168.35.1:5246)
56719.577 <fsm> old CWAS_RUN(12) ev CWAE_ECHO_REQ_RECV(27) new CWAS_RUN(12)

where:

• orange represents the Discovery phase,
• blue indicates that the control channels have been established using DTLS,
• green represents the access point Discovery and Join phase,
• purple represents the Clear Text channel,
• and pink indicates that the FortiAP successfully connected to the wireless controller.

General problems

Not all WiFi problems are related to signal strength, interference, or misconfiguration. The following OSI model identifies some of the more common issues per layer.

Best practices for troubleshooting vary depending on the affected layer (see below).

Common sources of wireless issues

Best practices for Layer 1

Common physical layer issues include:

• Weak received signal,
• WiFi capability: 802.11b, 1×1, 2×2,
• Co-channel WiFi interference,
• Side band WiFi interference,
• Non 802.11 noise (microwave ovens…).

To avoid physical layer issues:

• Determine RST (Receiver Sensitivity Threshold) for your device, or use -70dBm as a rule of thumb.
• Match AP TX output power to the client TX output power.
  Note: iPhone TX power is only 10dBm.
• Use DFS (Dynamic Frequency Selection) for high performance data 20/40 MHz.
• Use 5GHz UNII-1 & 3 (Non-DFS) bands with static channel assignment for latency-sensitive applications.
• Do not use 40MHz channels in 2.4 GHz band (channel bonding is not allowed in FortiOS).

Best practices for Layer 2

Common data link (MAC) layer issues include:

• Too many clients on a single channel (CSMA/CA) backoff,
• Too many high-priority traffic clients (WMM),
• Incorrect password or encryption settings,
• Too many beacons (in dense installs).

To avoid data link layer issues:

• Only use CCMP/AES (WPA2) encryption (not TKIP).
• In high density deployments, turn off SSID broadcast or turn down SSID rates. Review and possibly reduce the beacon interval.
• Determine the best cell size for applications:
  • For few users and low bandwidth latency sensitive applications, use high transmit power to create larger cells.
  • For high performance/high capacity installations, use lower transmit power to create smaller cells (set FortiPlanner at 10dBm TX power), but bear in mind that this will require more roaming.

Cells and co-channel interference

In high density deployments, multiple APs are used, and each one services an area called a cell. However, these cells can cause interference with each other. This is a common problem. The radio signal from one AP interferes with, or cancels out, the radio signal from another AP.

In the following diagram, note the interference zone created by one radio, causing interference on its neighbouring APs.

The interference zone can be twice the radius of the signal, and the signal at its edge can be -67dBm.

Reducing co-channel interference

For best results, use a ‘honeycomb’ pattern as a deployment strategy. The idea is to stagger repeated channels furthest from each other to avoid interference.

Best practices for Layer 3 and above

For TCP/IP layers and above, a common source of latency, or slowness in the wireless traffic, is too many broadcasts or multicasts. These types of issues can result from non-business and/or unwanted traffic.

To resolve issues at the TCP/IP layer and above:

• Identify business-critical applications.
• Use Application Control, Web Filtering, Traffic Shaping, and QoS to prioritize applications.
  • Identify unwanted traffic, high-bandwidth web-related traffic, and use Security Profiles.
  • Use the traffic shaper on a policy to rate-limit this traffic

These configurations are performed directly on the FortiGate.

Packet sniffer

Capturing the traffic between the controller and the FortiAP can help you identify most FortiAP and client connection issues.

This section describes the following recommended packet sniffing techniques:

• CAPWAP packet sniffer
• Wireless traffic packet sniffer

CAPWAP packet sniffer

The first recommended technique consists of sniffing the CAPWAP traffic.

• Enable plain control on the controller and on the FortiAP to capture clear control traffic on UDP port 5246.
  • On the controller:

diagnose wireless-controller wlac plain-ctl <FortiAP_serial_number> 1
 
Result:
WTP 0-FortiAP2223X11000107 Plain Control: enabled
 

• On the FortiAP:

cw_diag plain-ctl 1
 
Result:
Current Plain Control: enabled
 

Note that some issues are related to the keep-alive for control and data channel.

• Data traffic on UDP port 5247 is not encrypted. The data itself is encrypted by the wireless security mechanism.
  Data traffic is helpful to troubleshoot most of the issues related to station association, EAP authentication, WPA key exchange, roaming, and FortiAP configuration.

You can also set up a host or server to which you can forward the CAPWAP traffic:

1. Configure the host/server to which CAPWAP traffic is forwarded:

diagnose wireless-controller wlac sniff-cfg <Host_IP_address> 88888
 
Result:
Current Sniff Server: 192.168.25.41, 23352

2. Choose which traffic to capture, the interface to which the FortiAP is connected, and the FortiAP’s serial number:

diagnose wireless-controller  wlac sniff <interface_name> <FortiAP_serial_number> 2

Result:
WTP 0-FortiAP2223X11000107 Sniff: intf port2 enabled (control and data message)

In the above syntax, the ‘2’ captures the control and data message—’1′ would capture only the control message, and ‘0’ would disable it.

3. Run Wireshark on the host/server to capture CAPWAP traffic from the controller.

   •  Decode the traffic as IP to check inner CAPWAP traffic.

Example CAPWAP packet capture

The following image shows an example of a CAPWAP packet capture, where you can see: the Layer 2 header; the sniffed traffic encapsulated into Internet Protocol for transport; CAPWAP encapsulated into UDP for sniffer purpose and encapsulated into IP; CAPWAP control traffic on UDP port 5246; and CAPWAP payload.

Wireless traffic packet sniffer

The second recommended technique consists of sniffing the wireless traffic directly ‘on the air’ using your FortiAP.

Wireless traffic packet capture

Packet captures are useful for troubleshooting all wireless client related issues because you can verify data rate and 802.11 parameters, such as radio capabilities, and determine issues with wireless signal strength, interference, or congestion on the network.

A radio can only capture one frequency at a time; one of the radios is set to sniffer mode depending on the traffic or channel required. You must use two FortiAPs to capture both frequencies at the same time.

• Set a radio on the FortiAP to monitor mode.

iwconfig wlan10

Result:
wlan10    IEEE 802.11na     ESSID:""
Mode:Monitor  Frequency:5.18 GHz  Access Point: Not-Associated

• The capture file is stored under the temp directory as wl_sniff.pcap
  /tmp/wl_sniff.cap
  • Remember that the capture file is only stored temporarily. If you want to save it, upload it to a TFTP server before rebooting or changing the radio settings.
  • The command cp wl_sniff.cap newname.pcap allows you to rename the file.
  • Rather than TFTP the file, you can also log in to the AP and retrive the file via the web interface. Move the file using the command: mv name /usr/www
    You can verify the file was moved using the command cd/usr/www and then browsing to: <fortiAP_IP>/filename

Syntax

The following syntax demonstrates how to set the radio to sniffer mode (configurable from the CLI only). Sniffer mode provides options to filter for specific traffic to capture. Notice that you can determine the buffer size, which channel to sniff, the AP’s MAC address, and select if you want to sniff the beacons, probes, controls, and data channels.

configure wireless-controller wtp-profile
  edit <profile_name>
    configure <radio>
      set mode sniffer
      set ap-sniffer-bufsize 32
      set ap-sniffer-chan 1
      set ap-sniffer-addr 00:00:00:00:00:00
      set ap-sniffer-mgmt-beacon enable
      set ap-sniffer-mgmt-probe enable
      set ap-sniffer-mgmt-other enable
      set ap-sniffer-ctl enable
      set ap-sniffer-data enable
    end
end

Once you’ve performed the previous CLI configuration, you’ll be able to see the packet sniffer mode selected in the GUI dashboard under WiFi & Switch Controller > FortiAP Profiles and WiFi & Switch Controller > Managed FortiAPs. Bear in mind that if you change the mode from the GUI, you’ll have to return to the CLI to re-enable the Sniffer mode.

To disable the sniffer profile in the CLI, use the following commands:

config wireless-controller wtp-profile
  edit <profile_name>
    config <radio>
      set ap-sniffer-mgmt-beacon disable
      set ap-sniffer-mgmt-probe disable
      set ap-sniffer-mgmt-other disable
      set ap-sniffer-ctl disable
      set ap-sniffer-data disable
    end
end

Caution: If you change the radio mode before sending the file wl_sniff.cap to an external TFTP, the file will be deleted and you will lose your packet capture.

Example AP packet capture

The following image shows an example of the AP packet capture. Note the capture header showing channel 36; the beacon frame; the source, destination, and BSSID of the beacon frame; and the SSID of the beacon frame.

Useful debugging commands

For a comprehensive list of useful debug options you can use the following help commands on the controller:

diagnose wireless-controller wlac help
(this command lists the options available that pertain to the wireless controller)

diagnose wireless-controller wlwtp help
(this command lists the options available that pertain to the AP)

Sample outputs

Syntax

diagnose wireless-controller wlac -c vap
(this command lists the information about the virtual access point, including its MAC address, the BSSID, its SSID, the interface name, and the IP address of the APs that are broadcasting it)
 
Result:
bssid             ssid   intf      vfid:ip-port rId wId
00:09:0f:d6:cb:12 Office Office    ws (0-192.168.3.33:5246) 0 0
00:09:0f:e6:6b:12 Office Office    ws (0-192.168.1.61:5246) 0 0
06:0e:8e:27:dc:48 Office Office    ws (0-192.168.3.36:5246) 0 0
0a:09:0f:d6:cb:12 public publicAP  ws (0-192.168.3.33:5246) 0 1

Syntax

diagnose wireless-controller wlac -c darrp
(this command lists the information pertaining to the radio resource provisioning statistics, including the AP serial number, the number of channels set to choose from, and the operation channel. Note that the 5GHz band is not available on these APs listed)
 
Result:
wtp_id           rId  base_mac          index  nr_chan vfid 5G oper_chan age
FAP22A3U10600400 0    00:09:0f:d6:cb:12 0      3       0    No 1         87588
FW80CM3910601176 0    06:0e:8e:27:dc:48 1      3       0    No 6         822

The post WiFi Network Troubleshooting appeared first on Fortinet Cookbook.

In this recipe, you will enforce two-factor authentication for WiFi users who have physical FortiToken-200s through a captive portal. FortiToken-200 users who attempt to browse the Internet will be redirected to the captive portal login page and asked to enter their username, password, and token code.

This recipe assumes that you already have a FortiAP unit connected and authorized to the FortiGate, and that the SSID has been set up and configured to use Captive Portal. For a recipe on how to set up a wireless network through a captive portal, see Captive portal WiFi access control.

This recipe is designed for a FortiToken-200 physical key generator. See step 3 for information about using FortiToken Mobile.

1. Adding the FortiToken
Go to User & Device > FortiTokens and create a new FortiToken. Set Type to Hard Token and enter the FortiToken’s Serial Number into the field provided.
2. Editing the user and assigning the FortiToken
Go to User & Device > User Definition and edit the user (rgreen). Select Enable Two-factor Authentication and select the token created earlier. Select Add this user to groups and add the user to the captive portal user group (employees).
This recipe is designed for a FortiToken-200 physical key generator. If the user has FortiToken Mobile, the user’s contact information must be included so that the FortiToken code can be set to the user via Email or SMS.
3. Results
When a user attempts to browse the Internet, they will be redirected to the captive portal login screen.
Members of the FortiToken group must enter their Username and Password, but will then be redirected to a screen requiring the user to enter their Token Code. Once the code is successfully entered, the user will be redirected to the URL originally requested.
On the FortiGate, go to Monitor > WiFi Client Monitor to verify that the user is authenticated.

The post Captive portal WiFi access with a FortiToken-200 appeared first on Fortinet Cookbook.

This recipe explains how to use a static URL filter to block access to Facebook and its subdomains.

By using SSL inspection, you ensure that Facebook and its subdomains are also blocked when accessed through HTTPS protocol.

_{Find this recipe for other [glossary_exclude]FortiOS[/glossary_exclude] versions:
5.2 | 5.4}

1. Enabling Web Filtering
Go to System > Feature Select to enable the Web Filter feature.
2. Editing the default Web Filter profile
Go to Security Profiles > Web Filter and edit the default Web Filter profile. To block Facebook, go to Static URL filter, select Enable URL Filter, and then click Create.
Set URL to *facebook.com. Set Type to Wildcard, set Action to Block, and set Status to Enable.
3. Creating the Web filtering security policy
Go to Policy & Objects > IPv4 Policy, and click Create New. Give the policy a name that identifies its use. Set Incoming Interface to the internal network and set Outgoing Interface to the Internet-facing interface. Enable NAT.
Under Security Profiles, enable Web Filter and select the default web filter profile.
Enable SSL/SSH Inspection and select certificate-inspection from the dropdown menu. This allows the FortiGate to inspect and apply web filtering to HTTPS traffic.
After creating your new policy, make sure that it is at the top of the policy list. To move a policy up or down, click and drag the far left column of the policy.
4. Results
Visit the following sites to verify that your web filter is blocking websites ending in facebook.com: facebook.com attachments.facebook.com A FortiGuard Web Page Blocked! page should appear.
Visit https://www.facebook.com to verify that HTTPS protocol is also blocked.

For further reading, check out Static URL Filter in the FortiOS 5.4 Handbook.

The post Blocking Facebook with Web Filtering appeared first on Fortinet Cookbook.

In this video, you will learn how to create and order multiple security policies in the policy table, to control and limit different types of network traffic.

You will create three policies: a basic Internet access policy, which allows users in the internal network to access the internet; a restrictive Mobile policy, allowing users to access the internet with mobile devices; and an Admin access policy, allowing system administrators full unrestricted access from their PCs.

The recipe for this video is available here.

Watch more videos

The post Basic Firewall Policies (Video) appeared first on Fortinet Cookbook.

In this recipe, you will set up FortiAuthenticator to function as a RADIUS server to allow SSL VPN users to authenticate with a FortiToken-200.

You will configure a user (gthreepwood), FortiToken-200, and the RADIUS client on the FortiAuthenticator, create the SSL VPN tunnel, and configure the FortiGate to use the FortiAuthenticator as a RADIUS server.

1. Adding the FortiToken to FortiAuthenticator
On the FortiAuthenticator, go to Authentication > User Management > FortiToken, and select Create New. Make sure Token type is set to FortiToken 200, and enter the FortiToken’s serial number into the field provided.
2. Adding the FortiToken user to FortiAuthenticator
On the FortiAuthenticator, go to Authentication > User Management > Local Users, and select Create New. Enter a Username (gthreepwood), enter and confirm a password, and make sure that Allow RADIUS authentication is enabled. Select OK to access additional settings.
Enable Token-based authentication, select to deliver the token code by FortiToken, and select the FortiToken added earlier from the FortiToken 200 dropdown menu.
Next, go to Authentication > User Management > User Groups, create a user group (RemoteFortiTokenUsers), and add gthreepwood to the group.
3. Creating the RADIUS Client on FortiAuthenticator
On the FortiAuthenticator, go to Authentication > RADIUS Service > Clients, and select Create New. Enter a name (OfficeServer), set Client name/IP to the IP of the FortiGate, and set a Secret. The secret is a pre-shared, secure password that the FortiGate will use to authenticate to the FortiAuthenticator.
Set Authentication method to Enforce two-factor authentication, set Realms to local | Local users, and add RemoteFortiTokenUsers to the Groups filter. Note the Username input format. This is the format that the user must use to enter their username in the web portal.
4. Connecting the FortiGate to the RADIUS Server
On the FortiGate, go to User & Device > RADIUS Servers, and select Create New. Enter a Name (OfficeRADIUS), set Primary Server IP/Name to the IP of the FortiAuthenticator, and enter the Secret created before. Test the connectivity and enter the credentials for gthreepwood. The test should come back with a successful connection. The FortiGate can now log into the RADIUS client added earlier to the FortiAuthenticator.
On the FortiGate, go to User & Device > User Groups, and select Create New. Enter a Name (SSLVPNGroup), and under Remote groups, select Create New. Select OfficeRADIUS under the Remote Server dropdown menu.
5. Configuring the SSL VPN on FortiGate
On the FortiGate, go to VPN > SSL-VPN Portals, and edit the full-access portal. Disable Split Tunneling.
Go to VPN > SSL-VPN Settings. Under Connection Settings set Listen on Port to 10443. Under Tunnel Mode Client Settings, select Specify custom IP ranges and set it to SSLVPN_TUNNEL_ADDR1. Under Authentication/Portal Mapping, select Create New. Assign the SSLVPNGroup user group to the full-access portal, and assign All Other Users/Groups to web-access — this will grant all other users access to the web portal only.
Go to Policy & Objects > IPv4 Policy and create a new SSL-VPN policy. Set Incoming Interface to the SSL-VPN tunnel interface and set Outgoing Interface to the Internet-facing interface. Set Source to the SSLVPNGroup user group and set Destination Address to all. Set Schedule to always, Service to ALL, and enable NAT.
6. Results
From a remote device, open a web browser and navigate to the SSL VPN web portal (https://FortiGate-IP:10443). Enter gthreepwood‘s credentials and select Login. Note that the username has to be entered in the format ‘realm\username‘, as per the client configuration on the FortiAuthenticator (in this example, local\gthreepwood).
The user will then be prompted to enter their FortiToken code.
Once the code is successfully entered, gthreepwood will successfully log into the SSL VPN Portal.
On the FortiGate, go to Monitor > SSL-VPN Monitor to confirm the user’s connection.

The post FortiToken two-factor authentication with RADIUS on a FortiAuthenticator appeared first on Fortinet Cookbook.

This section contains tips to help you with some common challenges of IPsec VPNs.

diagnose vpn tunnel list

diagnose debug flow

diagnose debug application ike -1
diagnose debug enable

diagnose debug reset
diagnose debug disable

diag vpn ike log filter name <phase1-name> 
diag debug app ike -1
diag debug enable

ike 0:TRX:322: PSK auth failed: probable pre-shared key mismatch
ike Negotiate SA Error:

diag debug app ike -1
diag debug enable

responder received SA_INIT msg
incoming proposal:
proposal id = 1:
   protocol = IKEv2:
      encapsulation = IKEv2/none
      type=ENCR, val=AES_CBC (key_len = 256)
      type=INTEGR, val=AUTH_HMAC_SHA_96
      type=PRF, val=PRF_HMAC_SHA
      type=DH_GROUP, val=1536.
proposal id = 2:
   protocol = IKEv2:
      encapsulation = IKEv2/none
      type=ENCR, val=3DES_CBC
      type=INTEGR, val=AUTH_HMAC_SHA_2_256_128
      type=PRF, val=PRF_HMAC_SHA2_256
      type=DH_GROUP, val=1536.
proposal id = 1:
   protocol = IKEv2:
      encapsulation = IKEv2/none
      type=ENCR, val=AES_CBC (key_len = 128)
      type=INTEGR, val=AUTH_HMAC_SHA_96
      type=PRF, val=PRF_HMAC_SHA
      type=DH_GROUP, val=1536.

diagnose vpn ike restart
diagnose vpn ike gateway clear

diagnose debug disable

diagnose vpn ike log-filter clear

diagnose vpn ike log-filter dst-addr4 10.11.101.10.

diagnose debug app ike 255
diagnose debug enable

diagnose debug disable

IPsec SA connect 26 10.12.101.10->10.11.101.10:500
config found
created connection: 0x2f55860 26 10.12.101.10->10.11.101.10:500
IPsec SA connect 26 10.12.101.10->10.11.101.10:500 negotiating
no suitable ISAKMP SA, queuing quick-mode request and initiating ISAKMP SA negotiation
initiator: main mode is sending 1st message...
cookie 3db6afe559e3df0f/0000000000000000
out [encryption]
sent IKE msg (ident-i1send): 10.12.101.10:500->10.11.101.10:500, len=264, id=3db6afe559e3df0f/0000000000000000
diaike 0: comes 10.12.101.1:500->10.11.101.1:500,ifindex=26....

config sys global
   set ipsec-asic-offload [enable|disable]
end

The post IPsec VPN troubleshooting appeared first on Fortinet Cookbook.

This page contains tips to help you with some common challenges for SSL VPN.

• Enter the following 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.

• Enter the following command to verify the debug configuration:

diagnose debug info
debug output: disable
console timestamp: disable
console no user log message: disable
sslvpn debug level: -1 (0xffffffff)
CLI debug level: 3

This output verifies that SSL VPN debugging is enabled with a debug level of -1, and shows what filters are in place. The 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.

• Enter the following to enable displaying debug messages:

diagnose debug enable

To view the debug messages, log into the SSL VPN portal. The CLI displays debug output similar to the following:

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

• Enter the following to stop displaying debug messages:

diagnose debug disable

The following is a list of potential issues. The suggestions below are not exhaustive, and may not reflect your network topology.

There is no response from the SSL VPN URL.

• Go to VPN > SSL-VPN Settings and check the SSL VPN port assignment. Also, verify that the SSL VPN policy is configured correctly.
• Check the URL you are attempting to connect to. It should follow this pattern:

https://<FortiGate IP>:<Port>/remote/login

• Ensure that you are using the correct port number in the URL.

FortiClient cannot connect.

Read the Release Notes to ensure that the version of FortiClient you are using is compatible with your version of FortiOS.

Tunnel-mode connection shuts down after a few seconds.

This issue can occur when there are multiple interfaces connected to the Internet (for example, a dual WAN). Upgrade to the latest firmware then use the following CLI command:

config vpn ssl settings
   set route-source-interface enable
end

When you attempt to connect using FortiClient or in Web mode, you are returned to the login page, or you receive the following error message: “Unable to logon to the server. Your user name or password may not be configured properly for this connection. (-12).”

• Ensure that cookies are enabled in your browser.
• If you are using a remote authentication server, ensure that the FortiGate is able to communicate with it.
• Access to the web portal or tunnel will fail if Internet Explorer has the privacy Internet Options set to High. If set to High, Internet Explorer will block cookies that do not have a compact privacy policy, and that use personally identifiable information without your explicit consent.

You receive an error message stating: “Destination address of Split Tunneling policy is invalid.“

The SSL VPN security policy uses the ALL address as its destination. Change the address to that of the protected network instead.

The tunnel connects but there is no communication.

Go to Network > Static Routes and ensure that there is a static route to direct packets destined for the tunnel users to the SSL VPN interface.

You can connect remotely to the VPN tunnel but are unable to access the network resources.

Go to Policy & Objects > IPv4 Policy and examine the policy allowing VPN access to the local network. If the destination address is set to all, create a firewall address for the internal network. Change the destination address and attempt to connect remotely again.

Users are unable to download the SSL VPN plugin.

Go to VPN > SSL-VPN Portals to make sure that the option to Limit Users to One SSL-VPN Connection at a Time is disabled. This allows users to connect to the resources on the portal page while also connecting to the VPN through FortiClient.

Users are being assigned to the wrong IP range.

Ensure that the same IP Pool is used in VPN Portal and VPN Settings to avoid conflicts. If there is a conflict, the portal settings will be used.

Sending tunnel statistics to FortiAnalyzer

By default, logged events include tunnel-up and tunnel-down status events. Other events, by default, will appear in the FortiAnalyzer report as “No Data Available”. More accurate results require logs with action=tunnel-stats, which is used in generating reports on the FortiAnalyzer (rather than the tunnel-up and tunnel-down event logs). The FortiGate does not, by default, send tunnel-stats information.

To allow VPN tunnel-stats to be sent to FortiAnalyzer, configure the FortiGate unit as follows using the CLI:

config system settings
   set vpn-stats-log ipsec ssl
   set vpn-stats-period 300
end

The post SSL VPN troubleshooting appeared first on Fortinet Cookbook.

In this recipe, you will learn how to create an IPsec VPN on a FortiGate, and securely connect to an internal network using a Windows Phone 10.

Using the IPsec Wizard, you will create an IPsec VPN tunnel that allows users of Windows devices to securely access an internal network. You will then add a VPN connection using valid user credentials on a Windows Phone 10, and connect to the IPsec VPN.

This recipe assumes that a user (dprince) and a user group (WinPhone_Users) have already been created. Access to the VPN is controlled by a pre-shared key, and requires users to supply a user name and password.

A Windows Phone 10 Lumia 930 running build 10581 was used for this configuration.

1. Configuring the IPsec VPN using the IPsec VPN Wizard
Go to VPN > IPSec Wizard. Name the VPN connection (WinPhoneVPN). Select the Remote Access template, select the Windows Native device type, and select Next.
Set the Incoming Interface to the Internet-facing interface (wan1). Select the Pre-shared Key authentication method and enter a pre-shared key. Select the user group created earlier and select Next.
Set Local Interface to the internal interface and set Local Address to all. Enter an IP address range for VPN users in the Client Address Range field, enter a Subnet Mask, and select Create. Make sure no other interfaces on the FortiGate are using the same address range.
A summary page shows the wizard’s configuration.
Go to Policy & Objects > IPv4 Policy and confirm that the wizard has created two policies: one policy for remote users to access the VPN, and one policy that has Service set to L2TP.
2. Connecting to the IPsec VPN from the Windows 10 Phone
On the Windows Phone 10, go to Settings > Network & wireless > VPN and select Add a VPN connection.
Enter a Connection name and set the Server name or address to the FortiGate’s Internet-facing interface. Set VPN type to Automatic and enter the pre-shared key — this key is the same one you added to the FortiGate. Select Save.
3. Results
You will now connect to the IPsec VPN tunnel. From the VPN screen, select TheOffice. Sign in and connect using dprince‘s credentials.
You should now be connected to the IPsec VPN.
To verify the connection, on the FortiGate, go to Log & Report > VPN Events.
You may also verify the user’s connection by going to FortiView > VPN.

The post IPsec VPN for Windows Phone 10 appeared first on Fortinet Cookbook.

When a customer dials an organization’s support line they are commonly greeted with an automated attendant that transfers the customer’s call to a specific department based on the number the customer selects.

This recipe guides you through the process of configuring FortiVoice Enterprise (FVE) to transfer customer calls to the most qualified agent.

Creating Skill Sets
First you need to create custom skill sets for different departments. For example, you may want to create a Sales and Shipping department. On the FVE web UI, go to Call Center > Configuration > Skill Set. Select New. Enter a name and description of your skill set.  Select Create.
Configuring the Skill Levels
Once you have your skill sets created you will need to set their individual skill levels. Go to Call Center > Configuration > Skill Level. Create new levels by selecting New or select Edit to edit existing levels. Go To Extension > Extensions > IP Extensions. Select an agent’s extension and then select Edit.  Select Enable from the Call Center section and then select Configure.  Select New in the Skill Sets section. Select the appropriate Skill and Level from the dropdown menus. Select Create and then OK.  Repeat steps 4-8 for the agents with the configured skill sets.	Creating or editing skill levels Editing an agents extension Creating a new skill set
Configuring the Call Queue
Now you will need to establish how calls will be handled based on the set skills.  Go to Call Center > Call Queue > Call Queue. Create a new Call queue by selecting New or edit an existing one by selecting the Que and then Edit. Select Skill Based from the Distribution policy in the Call Distribution section. Select Skill Based Routing and choose a routing option: Lowest level first: the call transfers to the agent with the lowest skill level score first and then moves up the ranks to the first available agent Highest level first: the call transfers to the agent with the highest skill level score first and then moves down in rank to the first available agent. Select a call Distribution policy. This option only applies to the situation when you have agents with the same skill level in a queue. In such cases, calls are distributed to these agents according to this policy. Select OK.
Configuring Call Handling
Now you will need to establish how calls are handled. Go to Extensions > Virtual Number > Virtual Number. Select New to configure the Call Handling option to route the skill-based calls. Two actions are needed. One is to tag the call with a skill so that it is processed as a skill-based call. Another action is to route calls to queues where the agents with configured skill levels belong to. Select New under the Call Handling section. Select Call queue skill tag from the Action dropdown menu. Select one of your previously created skills from the Skill dropdown menu and then select Create. Select New under the Call Handling section. Select Call Queue from the Action dropdown menu. Select the location where you want to route the calls to from the Call queue dropdown menu and then select Create. Select Ok.	Creating a virtual number

The post Skill-Based Routing in FortiVoice Enterprise appeared first on Fortinet Cookbook.

2015 was the first full year of the Cookbook website being in operation. To mark this occasion, a report was written about the website’s performance during the year. This way we can look back on the successes and challenges of 2015, as well as set a benchmark to measure the website in the future.

The post Cookbook Website Activity Report for 2015 appeared first on Fortinet Cookbook.

In this video, you will learn how to create a virtual wire pair, to make it easier to protect a web server behind a FortiGate that is acting as an Internal Segmentation Firewall, or ISFW.

A virtual wire pair is two dedicated interfaces that have no IP addresses, with all traffic received by one interface being forwarded out the other, controlled by your firewall policies. Since the interfaces have no IP addresses, you can add a virtual wire pair to any network without making any significant changes. In this example, users on the internal network will access the web server through the ISFW over the virtual wire pair.
In FortiOS 5.4, the virtual wire pair replaces the Port Pairing feature from earlier versions. Unlike port pairing, a virtual wire pair is compatible with a FortiGate in NAT/Route mode, as well as Transparent mode.

The recipe for this video is available here.

Watch more videos

The post Virtual Wire Pair (Video) appeared first on Fortinet Cookbook.

In this recipe, you will use Application Control to monitor application traffic on your network and then selectively block unwanted traffic. Peer-to-peer (P2P) traffic is blocked in this example.

1. Enabling Application Control and Multiple Security Profiles
Go to System > Feature Select and ensure that Application Control and Multiple Security Profiles are enabled.
2. Using the default Application Control profile to monitor network traffic
The default Application Control profile is set to monitor all applications except for Unknown Applications. You will use this profile to monitor traffic and identify any applications that should be blocked.
Go to Security Profiles > Application Control and view the default profile. Confirm that all Categories are set to Monitor with the exception of Unknown Applications.
3. Editing the security policy for outgoing traffic
Go to Policy & Objects > IPv4 Policy and edit the policy that allows connections from the internal network to the Internet. Under Security Profiles, turn on Application Control and use the default profile. To inspect all traffic, SSL/SSH inspection must be set to deep-inspection profile.
4. Reviewing the FortiView dashboards
Go to FortiView > Applications and select the now view to display network traffic flowing through your FortiGate listed by application. You can see P2P traffic occurring in your network.
Double-click any application to view drilldown information, including traffic sources, traffic destinations, and information about individual sessions.
5. Creating an application profile to block P2P applications
In step 4, Application Control detected traffic from BitTorrent, a P2P downloading application. In this step, you create an Application Control profile to block all P2P applications.
Go to Security Profiles > Application Control and create a new profile. Set the P2P category to Block.
6. Adding the blocking profile to a security policy
Go to Policy & Objects > IPv4 Policy and edit the policy that allows connections from the internal network to the Internet. Set Application Control to use the new profile.
7. Results
Attempt to visit the BitTorrent site. A FortiGuard warning message will appear, stating that the application was blocked.
Test the P2P blocking by attempting to use the BitTorrent application. Traffic blocked. To view information about the blocked traffic, go to FortiView > Applications, select the 5 minutes view, and filter the traffic by Security Action: Blocked.

For further reading, check out Application control in the FortiOS 5.4 Handbook.

The post Monitoring and blocking P2P traffic appeared first on Fortinet Cookbook.

In this recipe, you will configure two-factor authentication using a FortiToken 200 for IPsec VPN connections.

This recipe assumes that you have already created a user (elainemarley) and a user group (FTK-users). You will add a FortiToken 200 to the FortiGate, assign the token to the user, and add the user to the group. You will then use the Wizard to create an IPsec VPN tunnel that allows FortiToken 200 users to securely access an internal network and the Internet. You will test the setup by having the user access the VPN from a remote device, using FortiClient.

1. Adding the FortiToken
Go to User & Device > FortiTokens and create a new FortiToken. Set Type to Hard Token and enter the FortiToken’s Serial Number into the field provided.
2. Editing the user and assigning the FortiToken
Go to User & Device > User Definition and edit elainemarley. Select Enable Two-factor Authentication and select the token. Select Add this user to groups and add the user to FTK-users.
3. Configuring the IPsec VPN using the IPsec VPN Wizard
Go to VPN > IPSec Wizard and create a new IPsec VPN tunnel. Name the VPN connection (in the example, FTK–VPN). Select the Remote Access template, set Remote Device Type to FortiClient VPN for OS X, Windows, and Android, and select Next.
Set the Incoming Interface to the Internet-facing interface (wan1). Set Authentication Method to Pre-shared Key and enter a pre-shared key. Select the user group created earlier (FTK-users) and select Next.
Set Local Interface to the internal interface and set Local Address to all. Enter an IP address range for VPN users in the Client Address Range field. A Subnet Mask should already be set. Select Next.
Configure additional Client Options and select Create.
A summary page will appear showing the VPN’s configuration.
4. Connecting to the IPsec VPN
On your remote device, open the FortiClient application, go to Remote Access, and add a new connection. Set VPN Type to IPsec VPN, and enter a Connection Name. Set Remote Gateway to the IP address of the FortiGate, set Authentication Method to Pre-Shared Key, and enter a Pre-Shared Key. The key must match the same key entered in the wizard on the FortiGate earlier. When finished, select Add.
5. Results
Go to Remote Access and attempt to log into the VPN as elainemarley.
You will then be prompted to enter a FortiToken Code. Enter the code and select OK.
The user is now successfully connected to the IPsec VPN FTK-VPN.
To verify the user’s connection, go to FortiView > VPN.
You can also go to Monitor > IPsec Monitor to view the tunnel’s status, and Monitor > FortiClient Monitor to view the user and device.

The post IPsec VPN two-factor authentication with FortiToken 200 appeared first on Fortinet Cookbook.

In this recipe, you will keep files containing sensitive information from leaving your network. To do this, criteria for retaining files are created and applied in a Data Leak Prevention (DLP) security profile. This example applies DLP to retain executable files and files matching a specific file name pattern.

1. Enabling DLP and Multiple Security Profiles
Go to System > Feature Select and confirm that DLP and Multiple Security Profiles are enabled.
2. Creating a DLP profile
Go to Security Profiles > Data Leak Prevention. In the Filter list, select Create New.
Set the filter to look for Files. Select Specify File Types and set File Types to Executable (exe). Set Examine the Following Services to all the services required by your network. Set Action to Block.
Create a second filter. Set the filter to look for Files. Select Specify File Types. In the File Name Patterns field, enter the pattern you wish to match. If desired, use a wildcard character in the pattern. Set Action to Block.
Both filters now appear in the Filter list.
3. Adding the profile to a security policy
Go to Policy & Objects > IPv4 Policy and edit your Internet-access policy. Under Security Profiles, enable DLP Sensor and set it to use the new profile. SSL Inspection is automatically enabled. Set it to use the deep-inspection profile to ensure that DLP is applied to encrypted traffic. Under Logging Options, enable Log Allowed Traffic and select Security Events.
4. Results
Attempt to send either an .exe file or a file that fits the file naming pattern blocked in step 2. Use a protocol that the DLP filter is set to examine. Depending on which protocol is used, the attempt will either be blocked by the FortiGate or it will timeout.
Go to FortiView > All Sessions and select the 24 hours view for information about the blocked session.

For further reading, check out Data leak prevention in the FortiOS 5.4 Handbook.

The post Preventing data leaks appeared first on Fortinet Cookbook.