Before proceeding, it should be made clear that
 moving a configuration file from one model to another is
not officially supported by Fortinet.

That being said, there are a few gray areas where circumstances can force the issue. This article is intended to color in those gray areas with some information you may find useful.

If you are replacing a FortiGate of one model with different model it is considered best practices to start with a clean install of the firmware and build the configuration from scratch. However, there are some circumstances where the replacement for a FortiGate with a different model was not part of a well organized plan and the configuration is complex enough that you will want to give moving the existing configuration a try. 99.9 % of the time it is not possible to seamlessly use a configuration file from one model on another but because the configuration file is a text file to be read by the firmware each time the unit boots up it is theoretically possible to use another model’s configuration file as the basis for the configuration of a different model. The file needs to be edited, sometimes extensively, preferably by someone comfortable with the syntax of these configuration files.

Overview

For those brave enough to attempt this sort of thing the usual approach is as follows:

1. Install a fresh copy of the firmware on the new device. The firmware has to be the exact same version as the one that was used to back up the configuration of the source device.
2. Execute factoryreset in the CLI to verify that there is a clean configuration file.
3. Set up the Interfaces and modes as close as possible to the source device, using the same names and addresses.
4. Use the backup copy of the source device to cut and paste sections into the destination device through the Command Line Interface. The CLI will check for syntax errors as the commands are entered.
5. Run a diagnostic error check to see if there are any errors
   The reality is that unless you are very knowledgeable and comfortable playing in the configuration file, it is easier and faster to build the new configuration from the ground up.

Useful Tools

TFTP server – This will direct you to a free Windows software utility that will perform the function of TFTP Server. If it does not appear to work, make sure that no other service or application is using port 69.
Whenever using the TFTP server it is also important to turn off any software firewalls running on the computer acting as the server.

SSH/Telnet client – This will direct you to a download for Putty.exe, a commonly used client.

Text editor – This will direct you to a free download for Notepad++, a source code editor. The beauty of a source code editor like Notepad++ — rather than Notepad — is that it shows the indents you make in the code, which is more intuitive and makes things much easier.

File comparison software – This will direct you to a free download of WinMerge, a tool for data comparison and merging of text-like files.

If after the warnings and caveats you are still determined to try, follow the steps below…

On the Original Device

Step #1 – Get Started!

Verify that you have a working configuration that performs its functions properly.

Step #2 – Version verification

Verify the Version, the MR level, the Patch Level and the build number of the firmware of the original device.

Using the top line of the Configuration file:

If you can read the top line of the configuration file with a code editor or even a text editor, you will get a line similar to the one in this example:

#config-version=FGT60C-4.00-FW-build328-110715:opmode=0:vdom=0:user=admin

Right after the model number, “FGT60C-" is the version number, in this case 4.00. We now know the version number. The build number can be used to narrow it down to a MR number and patch number.

Using the Web Based Interface:

• In version 4.3.x or later:

Go to System > Dashboard > System > Information widget
The line “Firmware Version” should look similar to:

v4.0,build0656,130211 (MR3 Patch 12) [Update] [Details]

Using the Command Line Interface:

Run the command:

get system status

There are more lines of output than are seen here but the relevant ones are:

• In Version 4 MR 3 and later:

Version: FortiWiFi-80CM v4.0,build0458,110627 (MR3 Patch 1)
Branch point: 458
Release Version Information: MR3 Patch 1

• In Version 4 MR 2 and earlier:

Version: Fortigate-60C v4.0,build5840,110715 (MR2)
Branch point: 328
Release Version Information: MR2

The difference being that starting in MR3, the patch number is included as well as the MR version and the build number is consistent with the branch point.

If you need to know which Branch point corresponds with which Firmware image you can check the Upgrade Path document here, or log into a Support Chat session and ask an on duty technician.

Step #3 – Backup the working configuration file

There are a number of ways, but the simplest is through the Web Based Manager:

1. Go to System > Dashboard > System > Information widget
2. Go to the line: System Configuration
3. Click on [Backup]
4. Save the file to your local PC

On the New Device

Step #4 – Install the same firmware on the device as is on the original device

Upgrades can be done afterwards but during the transition, in order to minimize the possibility of syntax errors it is important that the devices match in terms of firmware. If the new device came from the factory with a more recent version of the firmware there are two options:

1. Upgrade the original device to the same level as the new device, or
2. Install the same version being used by the original device on the new device using a console cable and a TFTP server.

Process for installing firmware via console cable:

Ideally, you want to do this using a console cable, a SSH/Telnet client, and a TFTP server:

1. Connect the Console cable
   Using the console cable, connect the computer running the TFTP server to the FortiGate unit.
2. Connect Ethernet Cable
   Connect an Ethernet cable from the Fortinet Device to either the computer or a network that is on the same subnet as the computer hosting the TFTP server. The port on the Fortinet device that you would connect the Ethernet cable to is usually the Internal port 1.
3. Log in to the Fortinet device with your SSH/Telnet client:
   Connect to the device using the following settings:
   

   Speed	9600
   Data Bits	8
   Parity	N
   Stop Bits	1
   Flow Control	No Hardware Flow Control

4. Reboot / power cycle the Fortinet Device and bring up the menu
   As the console displays text as it boots up, it will eventually display the following line:

Press any key to display configuration menu..."

Press the space bar or any other key.

 5.  Format the boot device:
       If the menu includes:

Format boot device [F] 

Press F and wait for the device formatting to complete.

 6.  Download the firmware:

Press G to start firmware download.

The console displays:

Enter TFTP server address [192.168.1.168]: 

Type the IP address of the computer running the TFTP server and press Enter. The console displays:

Enter Local Address [192.168.1.188]: 

Type an unused IP address that is on the same subnet as the TFTP server and press Enter.

The console displays:

Enter File Name [image.out]: 

Type the firmware image file name and press Enter.

The console periodically displays a “#” (pound or hash symbol) to show the download progress. When the download completes, the console displays a message similar to:

Save as Default firmware/Run image without saving: [D/R] Press D. 

The FortiGate unit installs the new firmware image and restarts. The installation may take a few minutes to complete.

Step #5 – Set to Factory Default

This will clear away all previous settings and configurations.
Using the command line interface, enter the command:

execute factoryreset

Once entered, you should have a clean, default configuration file installed on your new device

Step #6 – The Interfaces

Set up the interfaces of the new device as closely as possible to match the original devices.

• To log into the clean system you will likely use the default IP address of 192.168.1.99 on the internal ports.
• Make sure the mode of the internal ports matches, i.e. interface mode, switch mode, or hub mode.
• Make sure the names of the interfaces match.
• Make sure that the IP addresses used on the interfaces.
• Make sure that any DHCP servers or DNS servers match.

Step #7 – Add configuration components to the baseline configuration

This section should be prefaced with the warning that you should not copy over anything that relates directly to the configuration of the interfaces, as you could “break” the device if the configuration does not match the hardware. In terms of best practice, you should only copy and paste sections of the configuration where you understand the purpose of the lines of code that you are moving over — at least in a general sense.

You will need a text editor or a source code editor that can read the configuration file in a user-friendly fashion. Notepad++ is a good choice, but it is always best to use what you are comfortable with.

You will probably also want a SSH client to connect to the Fortigate rather than use the widget in the Dashboard window. It is possible to use the widget but using a separate client will allow you to expand the window so you aren’t feeling cramped on the screen. Putty is a commonly used client.

Rather than using the GUI to go through all the steps or typing in all of the commands through the CLI, you should copy from the configuration file as displayed in the source code editor and paste it into the CLI.

The CLI will catch any syntax errors and most logical errors.

You should be able to copy and paste in sections; this will save a lot of time. The thing to remember is to do it in the correct sections. The code editor should show the lines of the configuration with indents from the left, depending on how nested the CLI command is. You want to copy entire nested sections that can be entered from the “root” command prompt. In other words, from a line that has no indent to the next line that has no indent. For instance, in the example below, you would copy and paste the entire group from the line starting with “config” to the line containing “end”. The command structure of the CLI is context sensitive. If you tried to copy from the line starting with “edit” we would have to first manually enter the command “config system accprofile”, otherwise errors will occur.

config system accprofile
  edit "prof_admin"
    set admingrp read-write
    set authgrp read-write
    set endpoint-control-grp read-write
    set fwgrp read-write
    set loggrp read-write
    set mntgrp read-write
    set netgrp read-write
    set routegrp read-write
    set sysgrp read-write
    set updategrp read-write
    set utmgrp read-write
    set vpngrp read-write
  next
end

The copying from the source code editor is straight forward enough: select the text you want to copy and right click | select copy or use the hot keys CTRL+C. To paste into the CLI with Putty, just make sure that you are already logged in through Putty and that you are at the “root” prompt. Use the left mouse button to select the Putty window and then right click anywhere within the window. This will paste the commands in the right order into the CLI. If you get any errors the CLI will immediately give you error messages and you can deal with them right there where you know the error is occurring. This is why you want to do the copying in discrete, controllable batches.

For those who are more familiar with the configuration, you may want to skip sections that are likely to be common to all configurations such as the replacement messages.
Continue copying and pasting until you reach the end of the configuration file.

Step #8 – Backup

Make a copy (backup) of the current configuration file. Same as in Step 3

Step #9 – Test

Test to make sure the unit is operating as desired.

Step #10 – Compare files

Compare the original configuration file to the current one for differences.
(Optional) Use a product like WinMerge to make the comparison of files easier. The files will never be completely the same, but by running the comparison you can check for obvious discrepancies.

 Troubleshooting

After you have completed entering the configuration settings, you can do a final check of the configuration by running from the CLI:

diagnose debug config-error-log read

If there are any configuration issues in the new file, this command will give as an output the line where the configuration stops working, according to its diagnostic rules.

The post Transferring a configuration file from one model to another appeared first on Fortinet Cookbook.

If you appear to have configured your HA settings correctly but after trying to implement the HA cluster everything is still in stand-alone mode the issue could be with the interfaces.

When setting up an HA cluster it is important to make sure that none of the interfaces are configured to get their IP addresses from a DHCP server. Each interface should bestatically assigned. If any of the interfaces in an HA cluster are set to obtain dynamically assigned addresses the cluster will not work. This includes addresses from PPPoE as well as DHCP.

Some FortiGate units have DHCP as the default addressing method for some of the interfaces, so it pays to take a few extra moments to check. Setting the interface addressing mode.

In the Web Based Manager:

1. Go to System > Network > Interface
2. Select the interface to edit, for example: wan1
3. Set the Addressing mode to “Manual”
4. Enter the IP address and mask in either the:

• IP/Network Mask field
• IPv6 Address field

If you prefer to work in the CLI…

Open up a terminal window and log in to the FortiGate unit.
Use the following commands:

config system interface
  edit wan1
    set mode static

For IPv4 addresses:

set ip <include address and mask>

For IPv6 addresses:

config ipv6
set ip6-address <IPv6 address>

Scope of issue

This issue affects FortiOS version 5.0 but not 5.2. The limitation that causes the issue was removed in 5.2 for FGCP (FortiGate Clustering Protocol).

The post Check addressing mode if HA cluster not setting up properly appeared first on Fortinet Cookbook.

The following is, if not common, a plausible scenario:

You have a FortiGate unit that you have upgraded from version 4.3.10 to 5.0.1. You want to make it part of an HA cluster so you bring in a new unit of the exact same model and install a fresh copy of the exact same 5.0.1 build of the firmware. You try to join the new machine to the cluster and instead of the hoped for notification that everything went exactly as planned you get a message similar to this:

HA cannot be formed because the internal ports of 
box-FG100D3G12801021 is in different mode with this box. 
In order to form HA, please make them in the same mode first.

In the 4.3 firmware the default name for the internal interface was “internal” and it’s type is set to “physical”. In version 5.0.1 or later this interface’s default name has been changed to “lan” and the device type is “hard-switch”. When you upgrade a unit the settings follow through the upgrade but when you either do a fresh install or do a factory reset the settings are set to the default values which are going to be different than those of the unit that has been upgraded.

Solution:

The solution to this error is to change the configuration of the one of the FortiGate units to match the other. Which unit to change to match the other is up to you. One thing that would make sense to consider is which is more likely to be added to the cluster in the future:

1. A FortiGate that has been upgraded from 4.3 to a current version
2. A FortiGate unit that has a fresh new install of the 5.0.1 or later version of the firmware on it.

If the new install is more likely it would make sense to reconfigure the upgraded unit so that you don’t have to remember to edit the new join to the cluster later on.

The post Potential HA upgrade error due to changes in FortiOS appeared first on Fortinet Cookbook.

At some point you will want to block traffic based on the type of service or protocol that is being used. This is a fairly straightforward exercise if you are blocking all traffic using that service but it becomes subtler when trying to block it under specific circumstances or if you wish to block specific content in all circumstances. For the purposes of this explanation we will use FTP as an example, but the principles apply to many of the standard services.

Blocking all FTP traffic

In a policy, when the Service variable is set to a specific service and the firewall is set to DENY, what is happening is that it is blocking the port that is assigned to those Service names. In the case of FTP, FTP_GET, or FTP_PUT the firewall is blocking TCP port 21. Because you likely have some control over any FTP servers on your network this can be effective regarding incoming traffic but the situation changes when we start discussing outgoing traffic. If you could guarantee that all FTP traffic used the standard port then denying by service is an acceptable approach, but if someone has set up an FTP server out on the Internet that answers on a different port number, such as 60021, then denying traffic to the “FTP” service in the policy will not block the traffic. It will continue on to the next policy until finding one that applies to it, potentially finding a policy that has the service set to “ALL”.

In the case of port number 60021 there are two approaches you could take. You could create a new service in the Firewall Objects section and assign the port number 60021 and deny by that. This only works if you know the port number being used out on the Internet. You could take the more effective approach and use an Application Control Profile to block all FTP traffic regardless of which port is being used.

Setting the UTM Proxy Option

Another thing that can be done to make the scanning of FTP more comprehensive than just looking for a specific port number is to edit the UTM Proxy Options. In the Protocol Port Mapping section of a profile the Inspection Port can be changed from a specific port to “Any” port. By doing this for the FTP protocol any traffic that is analyzed by a UTM Security Profile will check the traffic based on the FTP protocol not just the traffic going over the specific port currently assigned to FTP. Make sure that any policy that is analyzing with a UTM Profile uses a UTM Proxy Option profile that has FTP configured to inspect any port.

It is not just with FTP that you can do this. You can also set the FortiGate to check any port, not just the specified one, for the following protocols:

• HTTP
• SMTP
• POP3
• IMAP
• NNTP
• IM is already set to scan any port

Allowing FTP only to specific sites

One situation that does come up on a regular basis is the requirement for people of one organization to have the ability to use a specific FTP server out on the Internet, usually run by a partner organization. This can be allowed through the use of policies.

1. Obtain the IP address or FQDN of the approved FTP server.
2. From that address, create an address object in the Firewall Object section.
3. Make sure that existing policies do not allow FTP traffic to the other side of the FortiGate unit¹.
4. Create an Address policy that allows FTP traffic to the address created in Step 2 and place the policy early in the sequence before any policy that might DENY or block FTP.
5. Verify that it works.

Allowing FTP only for specified users

Any time you are referring to specific users you will likely end up using an Identity based policy. The two most common approaches to this are:

1. Those that can vs. those that can’t
   1. Create a user group of those that is made up of users allowed to access FTP on the other side of the FortiGate unit.
   2. Create a user group of those that is made up of users not allowed to access FTP on the other side of the FortiGate unit.
   3. Make sure that existing policies do not allow FTP traffic to the other side of the FortiGate unit¹.
   4. Create a User Identity policy that allows traffic from the “allowed group” to go through the firewall and denies traffic from the “not allowed” group and place the policy early in the sequence before any policy that might DENY or block FTP.
   5. Verify that it works.

The disadvantage of this approach is that it can require more administrative overhead to make sure that the correct users are in the correct group.

2. Those that can vs. everybody else
   1. Create a user group that includes the accounts of those users allowed to access FTP on the other side of the FortiGate unit.
   2. Make sure that existing policies do not allow FTP traffic to the other side of the FortiGate unit¹.
   3. Create a User Identity policy that allows traffic from the “allowed group” to go through the firewall and place the policy early in the sequence before any policy that might DENY or block FTP.
   4. Verify that it works.

The advantage is that you only have to worry about the keeping the “allowed” users in the group. Everyone else is taken care of automatically.

Allowing FTP only for specified machines

Some organizations limit the use of some types of access to specific devices. If the organization uses static IP addresses then a regular Address policy can be used. The two approaches used are:

1. Using Address policies
   1. In the Firewall Objects section create address objects for any of the devices allowed to use FTP.
   2. Create an address group of addresses that make up devices allowed access.
   3. Make sure that existing policies do not allow FTP traffic to the other side of the FortiGate unit¹.
   4. Create a policy with the address group from Step ii. as a Source Address that allows the FTP traffic and place the policy early in the sequence before any policy that might DENY or block FTP.
   5. Verify that it works.

The disadvantage with this method is that if the addresses of the systems change the permissions will break down. The advantage is that it is simpler to set up.

2. Using Device Identity policies 
   1. In the User & Device section, define the devices that will be allowed to access FTP servers on the other side of the firewall.
   2. Add the devices from Step i. to a Device Group that is specifically for allowed FTP access.
   3. Make sure that existing policies do not allow FTP traffic to the other side of the FortiGate unit¹.
   4. Create a Device Identity policy giving the group defined in Step ii the permission to use the FTP service to and place the policy early in the sequence before any policy that might DENY or block FTP.
   5. Verify that it works.

This works almost exactly the same as allowing access by User Identity except that you would use a Device Identity policy instead of a User Identity policy.

The advantage is that unless the network interface adapter hardware is changed on the computer you don’t have to worry about changing addresses. This is handy in an environment where DHCP is used to assign addresses.

Allowing FTP except for specific content

If the objective is to block specific content from getting out but otherwise allow the use of FTP than the best approach is to use Data Leak Prevention (DLP). In this case it is very important to set the UTM Proxy Options to inspect any port. When the blocking of specific content is done, it is often done for legal or compliance reasons so you have to make sure the content is blocked no matter which port it goes out on. If the content gets past the firewall there can be legal and/or financial consequences.

In setting up the DLP restriction, the assumption will be made that anyone can use FTP, it’s just that they are not allow to send out certain confidential files.

1. Configure the UTM Proxy Option so that FTP scans any port.
2. Configure the DLP profile to scan for the content you wish to prevent leaving the network. You will be able choose from filtering options such as:

• File size
• Naming patterns using wild cards
• Naming patterns using regular expressions
• File types
• File Finger Prints
• Watermarks
• Whether it is encrypted

3. Assign the action Block or Quarantine to the filters relating to the content.
4. Open any policy that the targeted content could go through, the closer to the beginning of the sequence the better.
5. Enable the use of the DLP profile that will block the content.
6. Make sure that the UTM profile referred to in Step 1 is chosen.
7. Include any other UTM details that are needed by the profile.
8. Verify that it works.

These strategies are not just for FTP. They can be used for a number of protocols that you may need to block selectively or pervasively. Also, these strategies were all fairly basic in their requirements. By combining the techniques listed here with each other or with other firewall techniques you can customize the restrictions imposed on your FortiGate to closely match your requirements.

^{1 The implicit policy or Policy 0 denies all traffic to all locations and this can be counted on to deny FTP traffic as long as there is not a policy before it that will allow the traffic.}

The post Strategies for blocking traffic by a service or protocol appeared first on Fortinet Cookbook.

ses-denied-traffic

block-session-timer

config sys settings 
  set ses-denied-traffic enable
  end
config system global 
  set block-session-timer 60
  end

Caveat

It is worth noting that this feature’s primary function is to mitigate stress on the FortiGate’s resources from sessions that have been classified as “unwanted”, for lack of a better term. The scope of what the setting can handle does not include a full on assault by a Denial of Service type of attack. Protection from that sort of malicious attack is provided by DoS policies.

The post Adding denied sessions to session table appeared first on Fortinet Cookbook.

The new VPN Creation Wizard makes life easier for users that are unfamiliar with the creation of IPsec VPNs. However, not all of the meanings of the fields are intuitive and there are some limitations and requirements that users should be aware of.

Limitations

Types of VPN tunnels

Currently:

• The wizard is only for creating dial up VPN connection tunnels.
• The remote users need one of the following:
  • FortiClient software (version 5)
  • The Cisco client that is included in the Apple iOS software.

Creating Policies

While the wizard does simplify tunnel configuration, such as building both phases 1 and 2 of the tunnel, it does not do everything. For example, policies still have to be created so the tunnel can pass data back and forth.

Requirements

When using the wizard, there are a few pieces of information that you are going to want at your fingertips, or have configured before starting the wizard.

• Know the type of VPN clients are your remote users using.
• If you are using a certificate for authentication, it needs to be installed.
• The User Group that your users belong to. You can create one within the wizard, but it is preferable to take the time to configure it properly before starting the wizard so that there are fewer chances of making mistakes.
• The interface/port to which users will connect.
• Your company’s security policy on allowing split tunnel connections to your internal network.

Tour of the VPN Creation Wizard

Section 1 – VPN Setup

Name

Every VPN tunnel needs a unique name that policies can use as a reference.  After the tunnel has been completed this name will show up in the drop down menu that lists all of the Interfaces on the FortiGate. The normal best practices approach applies here.

• Don’t make the name too long. The field is limited to 15 characters.
• Don’t include spaces in the name.

VPN Type

• Dial Up – FortiClient Windows, Mac, and Android

Use this option when the remote users will be connecting with the FortiClient software that is installed on their device.

• Dial Up – iPhone / iPad Native IPsec Client

Use this option when the remote users will be connecting with the VPN client that is designed by Cisco. While the setting specifically mentions iOS devices, the Cisco VPN client on a Mac also works.

Section 2 – Authentication

Authentication Method

Pre-shared Key

If the Pre-Shared Key option is chosen, the next field will be called Pre-Shared Key. In this case, you could think of it in the same way as a password. It can be a word, a phrase, or even random characters. Just don’t make it easy to guess.

RSA Signature

If the RSA Signature option is chosen, the next field will be called Certificate Name. A certificate is more secure than a Pre-Shared Key, but more effort to configure.

User Group

This user group refers to the group to which  the users logging into the VPN belong. Each tunnel can only be assigned one user group, so if the users are currently spread across multiple groups or are not part of any group, the options are either to create a group that consists of all the users accessing a single tunnel or to create a tunnel for each of the groups. Remember that everyone in the group will have the credentials to access the tunnel.

Section 3 – Network

Local Outgoing Interface

This will be the interface port on your FortiGate with which you want to associate this tunnel. For instance, if the remote user wants to use the Public IP address used on your WAN port when they are connecting, then that is the interface that gets assigned here.

Address Range

The address range is a pool of IP addresses that will be assigned to any device connecting to the VPN. This range does not have to be a proper subnet range and it can stop and start at any point. For example both 192.168.1.1 – 192.168.1.255 or 192.168.1.3 – 192.168.1.17 would be valid ranges.

These addresses are not assigned to the visiting computers in the way that a DHCP server assigns addresses. These addresses are what the NATed addresses will be. The reason for NATing is that most connections will be from private networks and it is common for people to use standard private IP address ranges. If the remote computer is on a 192.168.1.0 subnet and your network uses the same address range on one of its networks, then the routing could become confusing. Avoid this confusion by assigning remote computers to an address range that you know isn’t part of your existing internal network.

Subnet Mask

The subnet mask is for the addresses that are being assigned to the remote devices. By having a subnet, the device knows when it needs to go to a gateway to reach an address.

DNS Server

Use System DNS

The remote device can be assigned the same DNS server that the FortiGate uses.

Specify

The remote device can be assigned a specific DNS server, by IP address. The requirement is that the address be reachable by the computer while connected to the tunnel. If split tunneling is not enabled and the IP address is not reachable from the FortiGate the DNS server will be useless.

Enable IPv4 Split Tunnel

Split tunneling allows the remote computer to use both the VPN connection to the networks controlled by the FortiGate (provided it is allowed by policy) and networks allowed by its regular network connections. If split tunneling were not allowed, all network traffic would have to go through the VPN tunnel.
[Default setting: enabled]

Accessible Networks

This option defines which addresses the remote computer can access through the FortiGate. The drop down menu lists addresses that have been defined in the FortiGate’s Addresses section. When split tunneling is enabled, this can be used to restrict the access to only those network addresses in your network that you want the remote users to access. If split tunneling is disabled, because all of the remote users’ traffic goes through the FortiGate, you could also control which sites on the Internet the remote user can access.

Allow Endpoint Registration

When enabled, this setting makes the FortiGate unit send a request to the FortiClient on the remote computer. The FortiGate unit must receive the correct registration key as a response before it can establish the tunnel. To enable and set the registration key on the FortiGate unit go to System > Config > Advanced.
[Default setting: enabled]

Section 4 – Client Options

The Client Options window only shows up when the FortiClient variation of the Dial up tunnel has been chosen. If the iPhone / iPad version is chosen, only the first three windows of the wizard are available. Because the software at both ends of the connection are written by Fortinet, more detailed information can be communicated back and forth. This gives the administrator more control over the various aspects of the network including those temporary remote nodes that are created when a VPN connection is created. When properly applied, more control can mean more security.

The common factors for all three of these settings are increased convenience for the user and potential security vulnerability. If the computer falls into the control of someone other than its intended user it takes little or no effort to establish a connection.

Save Password

When enabled, this setting allows the FortiClient software on the remote computer to store the password for the user so that it doesn’t have to be typed in each time a connection is made.
[Default setting: disabled]

Auto Connect

When enabled, this setting allows the FortiClient software on the remote computer to be configured so that whenever the FortiClient software is running it will attempt to connect to the VPN tunnel.
[Default setting: disabled]

Always Up (Keep Alive)

When enabled, this setting allows FortiClient software on the remote computer to keep the connection from timing out due to inactivity.
[Default setting: disabled]

The post Behind the scenes of the VPN Creation Wizard appeared first on Fortinet Cookbook.

To avoid single points of failure some networks use multiple ISPs. This allows for multiple routes or paths for the traffic to reach the Internet. By changing 3 variables different approaches can be used to manage the bandwidth and traffic flow. The variables involved are:

These variables work like a top down filter. If the values for the interfaces are the same for the first variable the check drops down the second variable. If the values for the interfaces are the same for the second variable the check drops down to the third. Once a variable is reached with a difference between the values that variable is the basis for how routing is determined.

The Values

While it may seem counter intuitive, in Distance and Priority, the higher number values are given lower priority in these settings. For instance, a value of 5 has precedence over a value of 10. The closer a number is to Zero (0), the greater priority it gives. If it helps, think of the values as placing in a race. 1st place is better than 2nd and so on.

The Weight values do not follow this line of thinking. The value for the Weight variable is the number of parts of the total in the ratio. For instance if one interface is 5 and the other 10 that would mean 5 out of 15 and 10 out of 15 respectively and 10/15, as a ratio, is more bandwidth.

Order of Application

The values associated with route preference are handled in the following order:

Distance

• If Distance is not equal, path is based on distance only
• If Distance is equal, basis of the path falls to Priority

Priority

• If Priority is not equal, path is based on Priority only
• If Priority is equal, basis of the path falls to Weight

Weight

• If Weight is equal, traffic from even addresses goes out one interface; traffic from odd addresses goes out the other
• If Weigh is not equal, path distribution is treated as a ratio
• Values must be integers

Location

The location for the 3 values above has changed through the versions of the firmware but as of in Version 5 the locations are as follows:

Distance:

Router > Static > Static Routes

Priority:

Router > Static > Static Routes

Weight:

Router > Static > Settings

>>ECMP Load Balancing Method = Weighted Load Balance

Examples

Using only WAN1, but able to fail over to WAN2

All of the traffic will go out WAN1 unless the system determines that WAN1 is down in which case all traffic will go out WAN2.

Set Distances as:

• WAN1 Distance = Same as WAN2 (example: 10)
• WAN2 Distance = Same as WAN1 (example: 10)

Set Priorities as:

• WAN1 Priority = Lower Integer Value than WAN2 (example: 5)
• WAN2 Priority = Higher Integer Value than WAN1 (example: 10)

Set Weights as:

• WAN1 Weight = Not applicable, it doesn’t get to this point
• WAN2 Weight = Not applicable,it doesn’t get to this point

Using WAN1 and WAN2 equally:

Traffic divided equally between the routes. A good set up if both interfaces have equal bandwidth capability.

Set Distances as:

• WAN1 Distance = Same as WAN2 (example: 10)
• WAN2 Distance = Same as WAN1 (example: 10)

Set Priorities as:

• WAN1 Priority = Same as WAN1 (example: 5)
• WAN2 Priority = Same as WAN1 (example: 5)
  (5 used as example because that is the default for DHCP assigned interfaces)

Set Weights as:

• WAN1 Weight = Same as WAN2 (example: 1)
• WAN2 Weight = Same as WAN1 (example: 1)

Using WAN1 and WAN2 in a weighted Ratio:

More traffic will use the route with the larger ratio assigned to it. Good if both interfaces are to be used constantly but have different levels of bandwidth capability.

Set Distances as:

• WAN1 Distance = Same as WAN2 (example: 10)
• WAN2 Distance = Same as WAN1 (example: 10)

Set Priorities as:

• WAN1 Priority = Same as WAN1 (example: 5)
• WAN2 Priority = Same as WAN1 (example: 5)

You would now need to determine the Ratio

Example of Ratio:

Because the finale values must be integers, multiply the bandwidth of all of the interfaces by a number that will make them all an integer.

Wan1 = T1 = 1.5 MB (x2) = 3
Wan2 = Cable = 10 MB (x2) = 20

Set Weights as:

• WAN1 Weight = 3, 3/23 of the traffic will go out wan1
• WAN2 Weight = 20, 20/23 of the traffic will go out wan2

Note: Any ratio can be used. This ratio was used because it closely matches the actual bandwidth available and would therefore optimize the performance of the network.

The post Multipath Routing Basics appeared first on Fortinet Cookbook.

It doesn’t happen often, though always more than we’d like, but sometimes we have to work in our FortiGate unit’s BIOS. You should know in advance the capabilities of the BIOS. There is also the issue that there is more than one BIOS interface that you may be dealing with. This can be problematic if you are familiar with the features of one of them and expect to be able to do the same things in another BIOS. The purpose of this document is to point out what the differences in BIOS features and capabilities.

The Different BIOS versions

There are a number of BIOS version numbers but for the most part they don’t change. Currently, a BIOS version can be placed in one of two categories:

The Old BIOS

This BIOS is currently on the bulk of the models. The TFTP setup is created from scratch each time it was used.

The New BIOS

The new BIOS started with a few models in 2013. The major change here is that the TFTP set up can be statically set to a default and the BIOS has the ability to connect to a TFTP server that is on a different subnet.

There can be some confusion with some models, as depending on when the unit was built the same model could have either the older BIOS or the newer one. Currently, models that use the new BIOS include:

• FortiGate / FortiWiFi 30D-PoE BIOS version greater than 04000002
• FortiGate / FortiWiFi 60D BIOS version greater than 04000020
• FortiGate / FortiWiFi 90D BIOS version greater than 04000016
• FortiGate / FortiWiFi 90D-PoE BIOS version greater than 04000006

The BIOS Menus

The quickest way to tell whether or not you are dealing with an old or new BIOS is the initial menu display. You will notice that the new BIOS has a different list of options than the old BIOS.

The Initial Menu: Old BIOS

[G]: Get firmware image from TFTP server
[F]: Format boot device.
[I]:Configuration and information.
[B]:Boot with backup firmware and set as default.
[Q]:Quit menu and continue to boot.
[H]:Display this list of options.

Enter: G,F,I,B,Q,or H:

The Initial Menu: New BIOS

[C]: Configure TFTP parameters.
[R]: Review TFTP parameters.
[T]: Initiate TFTP firmware transfer.
[F]: Format boot device.
[I]: System information.
[B]: Boot with backup firmware and set as default.
[Q]: Quit menu and continue to boot.
[H]: Display this list of options.

Enter C,R,T,F,I,B,Q,or H:

The Differences

Difference #1

“[G]: Get firmware image from TFTP server” has been replaced by the following 3 menu items:

[C]: Configure TFTP parameters.
[R]: Review TFTP parameters.
[T]: Initiate TFTP firmware transfer.

Difference #2

“[I]: Configuration and information.” has been replaced by:

[I]: System information.

Tips for the Interface:

• When using the bracketed single letter options, the input is case insensitive.
• Be careful as to what you enter. There is no error checking for invalid input.
• [H] will re-display the menu that you are in.
• [Q] will return you out of the existing menu to the previous one, but not back out of a setting configuration. The exception is [Q] in the main menu. There the command will exit from the BIOS menu and continue with the boot process.
• If a new value is given for most settings there is a short pause followed by the CLI displaying the message:

...done

• Pressing the Enter key without typing in a value will cause the system to use the default value in the square brackets.
• After the BIOS finishes an instruction the CLI will display the available options. For example:

Enter P,D,I,S,G,V,T,F,R,N,Q,or H:

• Be careful about the selection entries. There are non-displayed options that are intended for Fortinet technicians. You don’t want to get into a menu that could have unintended consequences if you enter the wrong input.

The BIOS Features and Settings

[G]: Get firmware image from TFTP server. (Old version)

Please connect TFTP server to Ethernet port ‘WAN1’.

Enter TFTP server address [192.168.1.145]:
Enter local address [192.168.1.188]:
Enter firmware imagefile name [image.out]:

[C]: Configure TFTP parameters.(New version)

Unlike the [G] from the old version, selecting [C] presents an additional menu listing:

[P]: Set firmware download port.

The options listed will vary from model to model due to the different port variations but the objective is the same; you can control which of the ports to connect the Ethernet cable to. This eliminates the need for sophisticated routing tables so the TFTP client software in the BIOS only needs to monitor one interface. Also, you don’t have to alter existing connections to perform the TFTP download.

[0]: Any of port 1 - 7
[1]: WAN1
[2]: WAN2
Enter image download port number [WAN1]:

[D]: Set DHCP mode.

Enabling the DHCP client mode will all the FortiGate to acquire IP address information from a DHCP server running on the same subnet as the FortiGate unit.

Current Setting: <The Factory Default value will be Disabled>
Please select DHCP setting
[1]: Enable DHCP
[2]: Disable DHCP

After enabling the DHCP client a review of the TFTP settings will indicate:

Local IP address:   N/A
Local subnet mask:  N/A
Local gateway:      N/A

This is because the DHCP request has not been sent out at this point. The DHCP request goes out when the ‘Initiate TFTP firmware transfer’ command has been given.

[I]: Set local IP address.

Statically assigns the IP address on the download interface of the FortiGate. The IP address will be in the standard IPv4 format.

Enter local IP address [192.168.1.188]:

[S]: Set local subnet mask.

Statically assigns the subnet mask on the download interface of the FortiGate.

Enter local subnet mask [255.255.252.0]:

[G]: Set local gateway.

Statically assigns the IP address to be used as the default gateway on the download interface of the FortiGate. This allows the FortiGate to access a TFTP server on a different subnet than it is currently connected to.

[V]: Set local VLAN ID.

Statically assigns the VLAN ID to be used when in an environment that uses VLANs.

Enter local VLAN ID(- 1 to set it none) [<NULL>]:

[T]: Set remote TFTP server IP address.

Statically assigns the IP address of the computer being used as a TFTP server. The IP address will be in the standard Ipv4 format. This allows the FortiGate to maintain an IP address for the server rather than entering it from scratch every time a firmware upgrade takes place.

Enter remote TFTP server IP address [192.168.1.145]:

[F]: Set firmware file name.

Statically assign the name of the image file to be downloaded from the TFTP server. There are two basic approaches to take with the image file:

1. Select a name for this option that is consistent and easy to remember, such as image.out, then change the name of the image file on the TFTP server to match. This requires a certain amount of administrative overhead on the TFTP server such as keeping a pool of firmware images in reserve and copying the one that is needed over to the TFTP server to rename and deleting it once it is downloaded as the next time a firmware image is needed it will be difficult to tell which firmware image to use based on the name of the file.
2. Change this entry every time a new image file has to be downloaded from the server.

Enter firmware file name [image.out]:

[E]: Reset TFTP parameters to factory defaults.

This will erase all the current TFTP parameters and replace them with the factory default values.

Perform the TFTP parameters factory reset? [Y/N]:

• If [Y] is chosen there is a short pause followed by the CLI displaying the message:…done
• If [N] is chosen the option quits and returns to the previous menu.

[R]: Review TFTP parameters.

Image download port: Any of port 1 - 7
DHCP status: Disabled
Local VLAN ID: <NULL>
Local IP address: 192.168.1.1
Local subnet mask: 255.255.255.0
Local gateway: 192.168.1.254
TFTP server IP address: 192.168.1.100
Firmware file name: image.out

[N]: Diagnose networking(ping).

[1]: Ping remote TFTP server.
[2]: Ping gateway.
[3]: Ping specified IP address.
[Q]: Quit this menu.
[H]: Display this list of options.

Enter 1,2,3,Q,or H:

Example: Press [1] to ping TFTP server:

Ping#1: Host 192.168.1.100 is reachable.
Ping#2: Host 192.168.1.100 is reachable.
Ping#3: Host 192.168.1.100 is reachable.
Ping#4: Host 192.168.1.100 is reachable.

[R]: Review TFTP parameters.(New version)

See above

[T]: Initiate TFTP firmware transfer.(New version)

Please connect TFTP server to Ethernet port 'Any of port 1 - 7'.

MAC: 00:09:0f:b5:55:28

Connect to tftp server 192.168.1.145 ...
##########################################################
Image Received.
Checking image... OK
Save as Default firmware/Backup firmware/Run image without saving:[D/B/R]?

Option [D] (default firmware)

Programming the boot device now.
................................................................
................................................................
.
Booting OS...
Reading boot image... 1239838 bytes

Depending on the status of the partition where the firmware will be stored, you may also get this message:

The system must reformat the boot device to install this firmware.
The default and backup firmware will be lost.
Continue:[Y/N]?Y

Option [B] (Backup firmware)

Programming the boot device now.
................................................................
................................................................
.
Booting OS...
Reading boot image... 1239838 bytes

Option [R] (Run image without saving)

Booting OS...
Reading boot image... 1239838 bytes
Followed a few seconds later by the FortiGate unit coming up and being ready.

[F]: Format boot device.(Both versions)

It will erase data in boot device. Continue? [yes/no]:

The response must be in one of the two forms indicated. To format the device type ‘yes’ in full and in lower case, then press Enter. If everything worked correctly, the CLI displays the following message:

Formatting . . . . . . . Done.

[I]: Configuration and information.(Old version)

[S]: Set serial port baudrate(will take effect on next boot).

Statically assigns one of five standard speeds to the serial connection of the console port.

0: 9600
1: 19200
2: 38400
3: 57600
4: 115200
Enter baudrate option [9600]:

To set the value type the index value shown on the left rather than the actual baud rate shown on the right. If the wrong value is entered there is no error message. The value just fails to change. This setting will only set the data transmission speed of the serial connection.

[T]: Set image download port (will take effect now and on next boot).

This will temporarily assign an Ethernet port for the TFTP server to download the image file. After a second boot of the device the port will revert back to the default port.

The port options listed will vary from model to model due to the different port variations but the objective is the same; you can control which of the ports to connect the Ethernet cable to. This eliminates the need for sophisticated routing tables, so the TFTP client software in the BIOS only needs to monitor one interface. In addition it is not necessary to alter existing connections to perform the TFTP download.

[0]: Any of port 1 - 7
[1]: WAN1
[2]: WAN2
Enter image download port number [WAN1]:

[C]:Set DHCP enable (will take effect now and on next boot).

[1]: Enable DHCP
[2]: Disable DHCP
Enter DHCP setting [Disabled]:

[I]: Display hardware information.

Vendor ID : Fortinet
CPU family : ARM9
CPU model : arm926ejs 
CPU MHz : 800 MHz
Cache size : 64 KB
Memory : DDR SDRAM 2GB 1066MHz
Platform ID : FGT60D
Serial number: FGT60D4613001043
BIOS Build : FortiGate-60D (15:09-08.12.2013)
BIOS Ver : 04000022

[I]: System information.

[S]: Set serial port baudrate(will take effect on next boot).

Same as old BIOS. See above.

[I]: Display hardware information.

Same as old BIOS. See above.

[B]: Boot with backup firmware and set as default. (Both versions)

If there is no firmware image set as the backup firmware the following message will be displayed:

Failed to mount filesystem. . .
Mount back up partition failed.
Back up image open failed.
Press ‘Y’ or ‘y’ to boot default image.

[Q]: Quit menu and continue to boot.(Both versions)

This option will exit the BIOS menu and continue with the boot process.

[H]: Display this list of options.(Both versions)

This option will redisplay the options of the current menu.

Upgrading BIOS

While upgrading the BIOS of a FortiGate device is possible, the risk commonly outweighs the potential gain. If anything goes wrong in the upgrade process there is a strong possibility of rendering your device unusable. This will likely require you to RMA your device, leaving your network with this important piece of hardware.

If, for some reason, there is a compelling reason to perform an upgrade it should not be done without the assistance of an experienced TAC technician, preferable L2 or above.

The post Navigating the FortiGate BIOS appeared first on Fortinet Cookbook.

Some FortiGate models are shipped without the standard RJ-45 or RS-232 serial console port that a lot of users are familiar with. In its place is a USB port that is designed to work with FortiExplorer and a USB cable instead of the Terminal session and console cable.

There are other models that work with FortiExplorer, but those models use a USB port that is part of the FortiGate in addition to the console port. In those units, accessing the FortiGate through FortiExplorer at the BIOS level is not possible. The firmware has to be up and running before a CLI interface is available.

Because of the limitation in those models there has been some concern about how to manage certain scenarios with the USB MGMT Console port only models:

1. Formatting and installing a fresh copy of the firmware on a unit.
2. Accessing the unit in the case of firmware corruption.
3. Resetting the Admin password.

There are some FortiGate models with only the USB MGMT Console port, that have a BIOS that allows access through the USB connection to the BIOS.

USB Connection Requirements

Connecting to a FortiGate unit that does not have an RJ-45 or serial console port requires the following:

1. USB cable (USB-A to Mini-USB).
2. Ethernet cable if you are going to be setting up a TFTP session.
3. FortiExplorer software, installed.

Initial setup

1. Use the USB cable to connect the computer to the USB MGMT Console port.
2. Open FortiExplorer.
3. Connect the FortiGate to a power supply.

Getting to the BIOS

Once the physical connection between the computer and the FortiGate is set up, use one of the following methods to start the login process. Each method involves having FortiExplorer up and running, and the CLI console open.

1. If the firmware is operational, log in to the unit and run the execute reboot command through the CLI.
2. If the firmware is not functioning properly, leave FortiExplorer running in the CLI mode and power cycle the FortiGate unit. Unplug the unit and wait approximately 10 seconds, then plug the unit back in.

Example: Using the USB MGMT port and TFTP to install fresh firmware on a FortiGate 60D

In this example, the following assumptions are made:

1. The firmware is functional.
2. TFTP server software is installed on the computer.
3. The firmware that you wish to install has been downloaded from the support site and is located in a directory accessible by the TFTP server software.

Step #1

Statically assign an address to your computer. Common practice is to use something in the 192.168.1.x subnet. To make it simple, use the default address that the FortiGate will suggest in Step #4 (192.168.1.145) and set the subnet mask to 255.255.255.0.

Step #2

In the CLI Console of FortiExplorer, type execute reboot.

After a minute or two the CLI displays the following message:

Press any key to display configuration menu....

Step #3

As soon as this message appears, follow the instructions. After a few seconds, the boot process continues and you will have to start over to get the option again. The configuration menu lists the following options:

[G]: Get firmware image from TFTP server.
[F]: Format boot device.
[I]: Configuration and information.
[B]: Boot with backup firmware and set as default.
[Q]: Quit menu and continue to boot.
[H]: Display this list of options.
Enter G, F, I, B, Q, or H:

Type G (this is case insensitive).

Step #4

The CLI displays the following:

Please connect TFTP server to Ethernet port 'WAN1'.
Enter TFTP server address [192.168.1.145]:

Use an Ethernet cable to connect from the Ethernet port of the computer to the Ethernet port listed in the instruction. For the 60D model it is WAN1, but other models might list different ports.

The TFTP server address is the one statically assigned to your computer, which is serving as the TFTP server. Press the Enter key to use the default address shown or enter the IP address of the computer. You do not need to enter the subnet mask, as it is assumed to be 255.255.255.0.

Once you have entered the TFTP server’s address the CLI displays the following:

Enter local address [192.168.1.188]:

This IP address refers to the FortiGate unit. It is a temporary address only and will not be held past the next reboot. Ensure that it is on the same subnet as the TFTP server. The subnet mask is automatically set to 255.255.255.0. Press the Enter key to use the displayed default address.

Step #5

The CLI displays the following:

Enter firmware image file name [image.out]:

The firmware image should have an “.out” extension.

Example: FGT_60D-v500-build0208-FORTINET.out

The CLI displays the following:

MAC: 00:09:0f:b5:55:28
Connect to tftp server 192.168.1.145 ...
#########################

A series of #s is a good sign that the file is transferring.

After the image file is finished transferring the CLI displays the following:

Image Received.
Checking image... OK

Step #6

The CLI displays the following:

Save as Default firmware/Backup firmware/Run image without saving:[D/B/R]?

You will need to choose one of the following:

• D    = Default firmware

Firmware that is loaded by default when the system is booted

• B    = Backup firmware

A backup copy of firmware to be used incase there are issues with the default firmware

• R    = Run image without saving

Unit will use this firmware once but revert to default after the first reboot after using the installed firmware.

To make the new firmware image the one used after every reboot, choose D.

Once you have chosen, the CLI displays the following:

Programming the boot device now.
......................................................
Initializing

The FortiGate unit will then boot with the freshly installed firmware.

FortiExplorer

The FortiExplorer software is available from two locations:

• The Service and Support site:

https://support.fortinet.com/

• The Product site:

http://www.fortinet.com/resource_center/fortiexplorer_product_download.html

If you download the software from the Service and Support site, choose the FortiExplorer_OnlineInstaller file, either the ‘.exe’ for Windows or the ‘.dmg’ file for Mac. These are the files that download from the Product site. These files, once installed, will connect to a Fortinet server and download the latest version of the software.

The TFTP example described, will work with the 2.2.x versions of FortiExplorer for Windows, but not with the Mac software of the same version. To install via TFTP using a Mac make sure that you have a current copy of the software. It has been tested successfully with version 2.3.1052.

When working with FortiExplorer, there may be some points where the CLI window will disappear from the interface, such as during a reboot. When the CLI is available again the widget will either reappear on its own or the menu options to start the CLI will appear.

Resetting the Admin Password

Normally, when you use a console session to reset the admin password, there is a point where the CLI session displays the message:

Initializing firewall…
System is started.
Login:

As soon as the system starts, you have approximately 15 seconds to enter the maintainer account credentials.

A small sampling of tests indicates that the use of the Admin reset feature is not available through FortiExplorer and the USB MGMT connection. It has been tested with version 2.3.1052 of both Windows and Mac software and was unsuccessful.

When using FortiExplorer, as soon as the unit starts reading the boot image file and initializing the firewall the terminal window disappears. When it is available again, approximately one minute later, the CLI displays the message:

Login:

Apparently, the 15 second window to enter the credentials runs out before the access to the CLI returns. I tried several times to enter the credentials, but the resulting message was always:

Login incorrect

If the password is lost, a fresh install of the firmware will reset the password to the default setting where the password is <null>. The configuration will be lost so this could be considered extra motivation to create and store frequent backups of the configuration.

Systems Tested on

The BIOS of models, especially the newer models, changes periodically, so even it the model is been previously tested unsuccessfully it makes sense to attempt connecting in case you are dealing with a newer BIOS that does allow connection.

The post Using the USB MGMT Console port appeared first on Fortinet Cookbook.

Mozilla has introduced a new feature in the latest release of its popular web browser, Firefox Version 32. The feature is SSL Public Key Pinning and is designed to help prevent “Man in the Middle”(MITM) attacks. For those who are worried that this feature might cause issues in a FortiGate firewall protected environment, there is little reason for concern. Any incompatibility issues are slight and easily corrected.

The basic premise of Pinning is that it enables the web browser to recognize or verify a specific selection of Certificate Authorities as the correct issuers of certificates for websites that are part of the Pinning feature. For example, one of the first websites that includes this feature is Twitter. If you are using Firefox version 32 or later and you go to a Twitter website that uses SSL, Firefox not only checks to make sure that the website has an SSL certificate associated with the URL to which you connect, but it also verifies that the certificate is issued by a particular Certificate Authority that is known to issue certificates to Twitter. This prevents “Man in the Middle” attacks by malicious agents providing false certificates that give the impression that everything is safe and secure, when the certificate is not actually issued to Twitter.

There are 4 levels of Pinning you can use in Firefox version 32:

0 – Pinning is disabled.
1 – Allow User MITM (Pinning is not enforced if the trust anchor is a user inserted CA, default).
2 – Strict mode. Pinning is always enforced.
3 – Enforce test mode.

According to Mozilla’s Public Key Pinning wiki, Firefox version 32 currently includes Pinning only for Twitter and Mozilla websites. However, Firefox plans to implement Pinning on the following websites in the near future:

• Google
• Firefox
• TOR
• Dropbox
• Additional Mozilla websites
• Additional Twitter websites

Website operators interested in utilizing Firefox’s Pinning feature for their websites can visit Mozilla’s Public Key Pinning Implementation wiki for more information.

Now that we have a basic understanding of Pinning, we need to determine how it affects a Fortinet environment. Unless you are visiting one of the websites on Firefox’s “pinned” list, a Fortinet environment shouldn’t be affected at all. The point at which Pinning becomes problematic is when a Firefox user goes through a FortiGate’s firewall policy that includes SSL inspection to one of the websites on Firefox’s “pinned” list. The problem is that in order to execute deep SSL inspection, the FortiGate performs the same actions that occur during a “Man in the Middle” attack, which is exactly what Firefox’s Pinning feature is designed to prevent.

If this Pinning feature causes a conflict in your FortiGate protected environment you have a few options:

On the Firefox browser

Add certificates to the browser.

The default level setting for Pinning is: “1. Allow User MITM (Pinning is not enforced if the trust anchor is a user inserted CA, default)” This means that if the certificate is added to Firefox’s list of trusted certificates you should be good to go.

Disable Pinning in Firefox version 32 and later

Disable the Pinning feature in Firefox version 32 and later. While it is enabled by default, it can be disabled. If you wish, it can also be made stricter.

To change the Pinning level:

1. In the Firefox browser, enter the URL: about:config
2. Scroll down to the Preference Name: security.cert_pinning.enforcement_level
3. Double click the row with the value you intend to change.
4. Change the Level to: 0 — Note: Changing the Level to 0 disables Pinning. Change the Level to 2 to make the feature stricter.
5. Select OK.

On the FortiGate firewall

Configure FortiGate firewall policies to use SSL Certificate Inspection

When setting up an SSL/SSH inspection profile, two Inspection method options are available. You can either use ‘Full SSL Inspection’ or ‘SSL Certificate Inspection’. The ‘SSL Certificate Inspection’ method looks only at the header of the packets to make sure that there is a proper certificate included and does not actually decrypt the contents of the packets. Decrypting and re-encrypting the contents of the packets triggers an untrusted website warning from Firefox because it receives a FortiGate certificate, rather than the original. This level of inspection ensures that you are connected to the correct website, but will not inspect the content for malware or other content that you may be filtering.

Configure additional FortiGate firewall policies

Create a policy for websites in the “pinned” list and do not implement deep inspection on that traffic. This would mean using either ‘SSL Certificate Inspection’ (in FortiOS 5.2) or no SSL inspection. Depending on how seriously you wish to scan the contents of SSL traffic, you can create separate policies for websites that are affected by Pinning and use your existing policies for all other traffic. The drawback of this strategy is that there is increased administrative overhead to remain up-to-date with the changes.

Final thoughts

The Pinning feature is something relatively new to the Internet environment, so you can expect a few growing pains initially. In fact, Google’s Chrome browser has already been doing this for Google websites for some time. The difference with the Firefox implementation is that eventually a significantly larger number of websites will be involved. Pinning is fairly straightforward, and since Fortinet has made accommodations for the possible inconveniences associated with SSL deep scanning in FortiOS 5.2, this feature can be used without any overt drawbacks.

The post SSL Public Key Pinning – Bulletin appeared first on Fortinet Cookbook.

Practically everyone who works in a corporate environment will try this trick at least once. Compressing or zipping a file is a common method of circumventing security measures to get past a firewall filter. Maybe you just wanted to see if you could out-smart the firewall, or more likely because you “knew” that your judgment was better than that of the firewall policy in a particular instance.

A common scenario is that a user may wish to run a simple little utility on their desktop that they’ve used thousands of times on their home computer, but forgot to bring the file to work. Not to worry, it’s barely over a hundred Kilobytes and they can probably download it in a matter of minutes. That’s when the user gets frustrated, because Network Administrators at work have placed a filter on downloaded material that blocks executable files. So the user rationalizes, surely they couldn’t mean my harmless and very useful app that thousands of other people have downloaded from a website hosting free downloads! In fact, the website is so accommodating that it gives users the option to download the 750 Kb program in a compressed file format to save valuable bandwidth. Six months later, the legal department is trying to figure out what the company’s responsibilities are to customers and shareholders with regard to the data loss of an unknown number of confidential documents due to a rampant Trojan horse attack that breached the company network.

Sometimes, the most important job for IT personnel is to protect people from their own actions. In the scenario above, the decision to filter executable files was made fora good reason. If the filtering can be bypassed simply by selecting a different download option, its effectiveness is somewhat questionable at best. For this reason some firewalls include the capability to decompress archive files and scan the content in compressed file formats. The ability to scan the content of a compressed file is only one tool in what should be a large and multifaceted toolkit.

Archive and compression file formats

Archive and compression files have been around for decades. There are many types of utilities — free, commercial and shareware — and all with their own specific algorithms. A quick look at Wikipedia shows a large list of formats, including:

• Archiving only formats
• Compression only formats
• Archiving and compression format

This leads to the next logical progression; that choosing one of the formats that the firewall cannot decompress or un-archive is more likely to get by a firewall’s filter policy. Therefore, the more formats your firewall can open the more secure your network is.

Not all Engines are the same

While it may seem a forgone conclusion that every firewall and every AV engine would open every format possible there are differences and limitations. In versions of FortiOS 5.0 and earlier, the two different inspection modes (Proxy-based and Flow-based) use different engines to do the scanning. Because of the way the Flow-based mode works in earlier versions of FortiOS, it opens a more limited number of compression and/or archive formats. Now that both inspection modes use the same improved AV engine in FortiOS 5.2, all of the formats listed below can be opened in both Proxy-based and Flow-based AV modes.

Different products also take different approaches to which formats will be targeted. For instance,some firewalls only check ZIP and GZIP formats. Others may check a few more popular formats, but nowhere near all of the wide variety formats available. In order to check other file formats, they have to proxy the entire file to scan it.

What can a FortiGate do?

The FortiGate AV engine, that looks to filter content on the incoming files, can open the following:

Archive/Compression formats

• ZIP
• ZIPX(BZIP2, INFLATE64, LZMA, LZMA2)
• JAR
• RAR
• 7Z
• BZIP2
• CAB
• TAR
• GZIP
• ARJ
• LZH
• MSC (Microsoft Compress)
• SIS (Symbian Installer Package)
• SISX (Symbian Installer Package for 9.x)
• SWF
• NSIS (Nullsoft Installer Package)
• E32Image(Symbian 9.x, compressed with custom LZW algorithm)
• XZ (starting with AV engine v4.3)
• CPIO (starting with AV engine v4.3)
• AutoIt (starting with AV engine 5.0)
• TNEF (starting with AV engine 5.1)

Self Extracting formats

• SFX ZIP
• SFX RAR
• SFX LZH
• SFX ARJ
• SFX CAB
• SFX 7Z

Static Packers

• UPX
• ASPACK
• PETITE
• FSG

Generic/Custom Packers

The engine supports most custom packers with emulator, including:

• UPACK
• Mew
• PECompact
• ASProtect
• PecBundle
• PEncrypt
• ACProtect

Document formats

Text files are straight forward and easily readable by most editors, but there are some text files that require an editor specifically configured to read these proprietary formats. The following file formats can be read by a FortiGate:

• PDF
• MS OFFICE
• RTF
• WORDML
• MIME

Misc

With anything a diverse as file formats there has to be a miscellaneous section for these that don’t really fit in any of the other groupings.

• UNICODE

Levels of compression or archiving

Individuals who attempt to confound the scanning process by compressing a file multiple times will be defeated by the FortiGate’s ability to scan through multiple levels of compression. By default,a FortiGate will go through 12 nested levels of compression to find the original file and this setting can be increased to 100 levels.

Before changing the setting to 100, remember that it is unlikely that the file sender will go through the effort to compress a file beyond the default, and the file receiver is even less likely to want to decompress the file that many times. It takes system resources to go through decompressing a file, so it might be simpler to drop any files that are nested that many times.

The post Supported compression formats appeared first on Fortinet Cookbook.

System administrator’s are constantly trying to optimize the performance of their networks. Rather than continue to process attempts that are consistently failing, the administrator will block access to devices that repeatedly break the rules. One area this can be done is multiple bad attempts to use a policy that requires user authentication.

It’s a straight forward setting, but there is a potential “gotcha” when using it.

The syntax of the setting is as follows:

config user setting
  set auth-lockout-threshold <int>
end

The integer value in the setting is the number of times in a minute that a user can make an unsuccessful attempt to go through a firewall policy that requires device or user authentication. Once the threshold is passed, the IP address of the device is blocked and the address is blacklisted. All further traffic from the device will be dropped.

The  symptom that most people will see that indicates a problem with the setup is that a computer will be denied access through a firewall policy because of too many failed login attempts even though the user has not even tried to go on the Internet. This will frustrate the logical analysis part of the troubleshooting process. If the user has made no attempts, how could they have too many failed logins? The problem is we often make the assumption that the attempts have to be made by a user. It’s right there in the name of the setting. We often forget that software will try to contact the Internet on its own. Most of the time, when the FortiGate doesn’t let software go out on the Internet unsupervised it’s a good thing. It is a security device and that’s one of the FortiGate’s jobs.

The most common cause of the inexplicable blacklisting is due to an automated process on a computer sending traffic to the Internet and there is no option to create an interactive login scenario.

A common example of this is the automated Microsoft Windows update process. Windows determines that it hasn’t been updated in a while and sends a request to one of the Microsoft servers. It tries repeatedly to connect but can’t because it needs to authenticate first to go through the firewall policy. After about 1 minute the computer is blacklisted because it exceeded the number of failed attempts set in the auth-lockout-threshold setting.

To stop this blacklisting behavior, the device or user needs to authenticate before accessing the Internet. Once authenticated, the traffic should flow without issue.  A possible work around is to determine what’s causing the failed authentication attempts and add a policy that accepts this traffic. In this policy you can choose to allow or deny the traffic. In the case of Windows updates, you might want to create a policy that allows access to Windows Update servers with no requirement for authentication.

Information on what is needed to configure a firewall for Windows updates can be found here.

Other traffic causing this issue would have to be addressed on a case by case basis as the firewall parameters are likely to be different in each situation.

The post Windows updates may cause denial of access to Internet appeared first on Fortinet Cookbook.

The Ultrasurf software isn’t inherently a good thing, or a bad thing. Like many other tools, it all depends on how you use it.

According to Ultrasurf’s own website, it was originally created to help Internet users “find security and freedom online”. This is their way of saying that, by using this tool, you could go on the Internet, search for and read about things that someone didn’t want you to see, and not get caught doing it. Its intended purpose is to allow people to get past censorship in a context where people believe that the users are being denied a basic right. Some people agree, some people don’t. Some people voice the opinion that any kind of censorship or restriction of information to anybody is a bad idea and it infringes upon their basic human rights. These are generally noble and idealistic people that believe humanity is, at its heart, virtuous; that nobody has ulterior motives, and that there is nothing on the Internet that shouldn’t be available to everybody all of the time.

Wouldn’t it be nice if it were true?

The same tool used to circumvent the censorship of an oppressive environment can also be used to bypass the legitimate restrictions of a business environment. The specifics of what kind of content is blocked can vary as much as the justification for blocking it. It can be a school blocking adult content or a business blocking social media, but whether you agree with it or not, it boils down to a simple rule: the owners of the network get to decide what is allowed on the network.

Once you get into the business or organization environments, depending on who you ask,  things are a little less black and white and the reasons for limited censorship and what is being censored is more varied, but it is something that SysAdmins are likely to come across and have to deal with. The reality is that if the policy of the organization that a system administrator works for states that certain sites or types of sites are not to be accessed, then it is up to the SysAdmin to do their best to make sure that it does not occur.

Products like Ultrasurf are designed to make that difficult. The people at Ultrasurf are good at what they do. They are constantly improving their product. However, the people at Fortinet are good at what they do as well.

Neutralizing Ultrasurf

Regardless of whatever well intended purpose Ultrasurf was created for, it is sometimes our job to neutralize it. Let’s look at how we can go about it.

Stopping downloads

One way in which FortiGates can prevent the use of Ultrasurf is by preventing its download in the first place. If an Antivirus profile is applied to a policy, it should prevent the downloading of the Ultrasurf executable file. The result should be an Alert page letting the person know that the Ultrasurf file is considered a virus.

This doesn’t stop people from downloading the software somewhere else and bringing it in on a USB drive but it does serve two purposes:

1. It makes it more inconvenient to get the software on the computer.
2. It lets the user know that this software shouldn’t be coming into this network.

If you happen to be in an environment that doesn’t allow USB drives and/or has a whitelist for all of the software allowed on your computers, you may be able to rest easy at this point, but most places aren’t quite as strict as that. In most cases, a determined person may get the software on their computer. We will continue with some more steps on the assumption that it is somewhere on your network.

Preventing Ultrasurf from being usable

These are the basic steps needed to block Ultrasurf from the Internet. One thing that should be mentioned up front is that the main ingredient to get it all to work is the Application Control feature. If your package does not include this, talk to Fortinet’s Customer Service department or your re-seller to see if you can get it.

We may come up with some cookbook recipes that are specific to firmware versions, but the following information should be enough to get someone reasonably comfortable with the firmware through the process.

Step #1 – Current Firmware

There are usually two versions of the firmware that are currently in development. You will need at least FortiOS 5.0 to block Ultrasurf. That is when the Full SSL Inspection mode was added that can properly scan for Ultrasurf traffic using SSL.

As improvements are made to the firmware, the capabilities of the IPS engine can improve and by extension the definitions that it can use. Currently, it appears the IPS engines from the initial appearances of the current firmware versions are handling Ultrasurf, but what is true today may not be true tomorrow. It is just one more reason to make sure that you are up-to-date with your firmware. Right now that means that whether you are running 5.0 or 5.2, make sure that you have your firmware’s latest update.

Step #2 – Current IPS definitions

Without the most up-to-date version of the signature to recognize Ultrasurf traffic, the likelihood of a recent version of Ultrasurf not being blocked from the Internet increases. Make sure that you have the very latest IPS update.

At the time of this writing, the IPS definition version number is 6.682 and is successfully blocking Ultrasurf release 15.0.2.

In order to find out what is the latest version of the IPS update, go to http://www.fortiguard.com/updates/ips on the Fortinet Support Site.

To get the update, use the CLI to run the command:

execute update-ips

or if you want to update both IPS and antivirus, run the command:

execute update-now

While you should manually verify what your IPS update version is periodically just to be sure, you can also set up your FortiGate to automatically update the IPS definitions on a regular schedule.

Step #3 – Application Control list

Now that you have the latest signatures, it’s time to put them to use. Create a new Application Control profile or edit an existing one to include the appropriate signatures.

To target Ultrasurf, add these signatures to the security profile:

• Ultrasurf
• Ultrasurf_9.6+
• Freegate.Searching

If you want to include all proxy applications, you can choose the Proxy category.

Step #4 – SSL inspection

Proxy applications can use SSL and port 443, or any other port they want, to communicate with the associated servers so that they can, in effect, use the security of the system against itself. The Ultrasurf protocol mimics legitimate SSL handshake behaviour and can produce false positives if the actual session is not inspected.

Make sure that Full SSL inspection is in effect on the firewall policies or if you prefer the term, Deep Inspection. This is normally set in the configuration window found at Policy & Objects > Policy > SSL/SSH Inspection. The location may change in various firmware versions but you should be able to find it.

Step #5 – Apply Application Control profile to firewall policies

Make sure that your firewall policies are using the Application profile that targets Ultrasurf. It makes no sense to go to all the trouble of building the profile if you’re not going to use it. If you are going to have some policies for special situations that are not going to block Ultrasurf, make sure that those policies are specific enough and in the correct sequence so that only the intended computers match the policy.

Step #6  DNS queries

One of the things that the signatures do is to detect DNS queries to the Ultrasurf servers. This means that the Application control profile has to be between the computers and the DNS servers. If you happen to be running internal DNS servers, this can sometimes be a little tricky. If they are on a separate subnet like a DMZ it is easier to make sure that you can apply the security profile to the traffic but if the DNS server is on the same subnet as the computer, you may have to verify that the DNS addresses of the Ultrasurf servers are not cached on the DNS server.

If you have a computer that has been running Ultrasurf, it may have cache one or more of the Ultrasurf server IP addresses. You can clean this up by deleting the following:

• Temp folder “utmp” in the Ultrasurf folder
• Ultrasurf temporary files in "C:\Documents and Settings\<your windows account>\Local Settings\Temp"
• In Windows 7 systems, the files may be located in  “C:\users\<your windows account>\Appdata\Local\Temp\“

The temp file names are random. If you don’t know which are Ultrasurf temp files, it is advisable to delete all files in the folder.

Note: In fact, this step may be considered optional due to Ultrasurf automatically clearing the cache after about 24 to 48 hours. When testing to see if everything is working you probably want to manually delete the files so that you don’t have to wait that long for the results.

Step # 7 – Kill Ultrasurf

Admit it. You liked the heading of this step. What it means is to kill the Ultrasurf process on  computers running Ultrasurf. You may not be able to get them all, but you should definitely make sure you kill the process on the computer you are using to test with. You could wait until a normal reboot, but some users leave their computers on for long periods of time.

Step #8 – Flush the DNS

Make sure that there are no cached references to Ultrasurf servers by flushing the DNS cache of the computers where Ultrasurf may have been used. Use the command:

ipconfig /flushdns

Step #9 – Test

If you don’t test, how will you know for your own peace of mind that it is actually working? To test to make sure that the procedure is working

The ongoing struggle between Fortinet and Ultrasurf and other proxy services

In this area, the goals of Ultrasurf (and similar applications) and Fortinet are mutually opposed. Ultrasoft is developing software to bypass technology that limits a users ability to go to any website, while the IPS team at Fortinet is working on technology that is intended to block users from going to certain sites. Any time you have a struggle like this with smart people on both sides, there are going to be times when one side temporarily pulls into the lead. Because Fortinet is in the position where it has to react to a new tactic employed by Ultrasurf, there is likely to be times when Ultrasurf will successfully bypass the protection of a FortiGate. This is usually short lived, because as soon as Fortinet is aware of the change in status, work begins on correcting the situation. For this reason, maintenance is the key.

Make sure that:

• Your firmware is current
• Your IPS definitions are up to date
• You perform periodic tests

If the status changes inform Fortinet. One point of contact to let Fortinet know that there is a change in the effectiveness of the IPS definitions is to email vulnwatch@fortinet.com.

The post Ultrasurf – tool for freedom or a pain in a SysAdmin’s … appeared first on Fortinet Cookbook.

In these days of heightened security awareness it makes sense to understand what is protecting your passwords from prying eyes. For anyone that has seen the configuration file of a FortiGate device, you are aware that there are some passwords stored in this plain text file. With the processing power of computers getting faster some people are concerned that if someone can access this string of characters that a password can be decrypted. This information is to help relieve that concern.

The string of characters in place of the password in the configuration file is an encrypted hash of the password. The encryption hash used for admin account passwords is SHA256/SHA1. The value that is seen in the configuration file is the Base64 encoded hash value. Any size discrepancy between the actual size and the size that might be expected is probably because the actual size includes a 3-byte value to identify the type of password (four types are supported) and a 12-byte IV.

In the case of the password field in a config user local entry, in the PSK field in a config VPN IPsec phase1, and for every other use of password/PSK in FortiOS then the fields are not stored as a hash of the password. Instead the plain text password is stored. What is seen in the configuration file is an encoded version of the password. The encoding consists of encrypting it with a fixed key using DES (AES in FIPS mode) and then Base64 encoding the result.

There is often no alternative to storing the (DES/AES encoded) plain text password. For example, the PSK in a config VPN IPsec phase1 is defined by IKE to be the key in a HMAC calculation that is used to derive the actual key that will be used to secure the IKE messages. Since neither the PSK or a hash of it are sent on the wire in the IKE handshake it requires that both sides have the plain text PSK. Thus storing a hash of the password is not feasible in that case.

The post Encryption hash used by FortiOS for local pwd/psk appeared first on Fortinet Cookbook.

Most of us are familiar with Hypertext Transfer Protocol Secure (HTTPS) and how it protects a variety of activities on the Internet by applying Secure Sockets Layer (SSL) encryption to the web traffic. 

The benefits of HTTPS are obvious, as encryption keeps your private data safe from prying eyes. However, there are risks associated with its use, since encrypted traffic can be used to get around your normal defenses. 

For example, you might download a file containing a virus during an e-commerce session.  Or you could receive a phishing email containing a seemingly harmless downloader file that, when launched, creates an encrypted session to a command and control (C&C) server and downloads malware onto your computer. Because the sessions in these attacks are encrypted, they might get past your network’s security measures.

To protect your network from these threats, SSL inspection is the key your FortiGate uses to unlock encrypted sessions, see into encrypted packets, find threats, and block them. SSL inspection not only protects you from attacks that use HTTPS, but also from other commonly used SSL-encrypted protocols, such as SMTPS, POP3S, IMAPS, and FTPS.

Full SSL inspection

To make sure that all SSL encrypted content is inspected, you must use full SSL inspection (also known as deep inspection). When full SSL inspection is used, the FortiGate impersonates the recipient of the originating SSL session, then decrypts and inspects the content. The FortiGate then re-encrypts the content, creates a new SSL session between the FortiGate and the recipient by impersonating the sender, and sends the content to the sender.

When the FortiGate re-encrypts the content it uses a certificate stored on the FortiGate. The client must trust this certificate to avoid certificate errors. Whether or not this trust exists depends on the client, which can be the computer’s OS, a browser, or some other application, which will likely maintain it’s own certificate repository. For more information about this, see the recipe Preventing certificate warnings.

There are two deployment methods for full SSL inspection:

1. Multiple Clients Connecting to Multiple Servers:

• Uses a CA certificate (which can be uploaded using the Certificates menu).
• Typically applied to outbound policies where destinations are unknown (i.e. normal web traffic).
• Address and web category whitelists can be configured to bypass SSL inspection.

2. Protecting SSL Server

• Uses a server certificate (which can be uploaded using the Certificates menu) to protect a single server.
• Typically used on inbound policies to protect servers available externally through Virtual IPs
• Since this is typically deployed “outside-in” (clients on the Internet accessing server(s) on the internal side of the FortiGate), server certificates using the public FQDN of the server are often purchased from a commercial Certificate Authority and uploaded to the FortiGate. This avoids client applications generating SSL certificate errors due to certificate mismatch.

More detail is available in the FortiOS Handbook. Also, check the Fortinet Knowledge Base for these technical notes:

• How to Enable SSL inspection from the CLI and Apply it to a Policy
• How to block web-based chat on Gmail webmail using App Sensor + SSL inspection

SSL certificate inspection

FortiGates also supports a second type of SSL inspection, called SSL certificate inspection. When certificate inspection is used, the FortiGate only inspects the header information of the packets.

Certificate inspection is used to verify the identity of web servers and can be used to make sure that HTTPS protocol isn’t used as a workaround to access sites you have blocked using web filtering.

The only security feature that can be applied using SSL certificate inspection mode is web filtering. However, since only the packet is inspected, this method does not introduce certificate errors and can be a useful alternative to full SSL inspection when web filtering is used.

When certificate inspection is used, web filtering is done in flow-based mode, even if the web filter profile or VDOM has been configured to use proxy mode.

Troubleshooting

The most common problem with SSL inspection is users receiving SSL errors when the CA certificate is not trusted. This is because by default the FortiGate uses a certificate that is not trusted by the client. There are two ways to fix this:

1. All users must import the FortiGate’s default certificate into their client applications as a trusted certificate.
2. Configure the FortiGate to use a certificate that is already trusted by your clients. For example, a certification signed by a CA that your clients already trust.

The first method can be more labor intensive because you have to distribute a certification to all clients. This can also be an ongoing problem as new clients are added to your network. The second method is usually less work but may require paying for a CA. Both of these methods are covered in the recipe Preventing Certificate Warnings.

If you choose to install the certificate on client applications, this can be done with greater ease in a Microsoft Active Directory domain environment by using Group Policy Objects to install the certificate on domain members. Check that the Group Policy has propagated to all computers by opening Internet Explorer on a workstation PC, opening Tools > Internet Options > Content > Certificates >Trusted Root Certification Authorities, and ensuring that the FortiGate’s certificate is present.  

For corporate-owned mobile devices, MDM solutions like AirWatch, MobileIron, or Fiberlink, use Simple Certificate Enrollment Protocol (SCEP) to ease certificate enrollment.

Best practices

Because all traffic needs to be decrypted, inspected, and re-encrypted, using SSL inspection can reduce overall performance of your FortiGate. To make sure you aren’t using too many resources for SSL inspection, do the following:

• Know your traffic – Know how much traffic is expected and what percent of the traffic is encrypted. You can also limit the number of policies that allow encrypted traffic.
• Be selective – Use white lists or trim your policy to apply SSL inspection only where it is needed.
• Use hardware acceleration – FortiGate models with either the CP6 or CPU processor have an SSL/TLS protocol processor for SSL content scanning and SSL acceleration. For more information about this, see the Hardware Acceleration handbook.
• Test real-world SSL inspection performance yourself – Use the flexibility of FortiGate’s security policy to gradually deploy SSL inspection, rather than enabling it all at once.

The post Why you should use SSL inspection appeared first on Fortinet Cookbook.

This article shows how to view the most recent version of the supported modem list for FortiGate or FortiExtender.

These lists depend on the modem database version, not the version of FortiOS used. The examples shown in this article use screenshots from FortiOS 5.4, but they are also accurate for FortiOS 5.2. Any differences are listed with an asterisk, like this:

You can find a list of supported modems in our Fortinet reference manuals:

• FortiGate Modem Compatibility Matrix
• FortiExtender Modem Compatibility Matrix

You can also view the modem lists in the FortiGate interface by enabling either the modem interface or FortiExtender.

Method 1: Viewing the FortiGate/FortiExtender Modem List

A FortiGate 100D running 5.4 (Interim build) was used in this example.

1. Enabling the FortiGate modem interface
The modem configuration is hidden in the FortiGate GUI by default. Enter the CLI commands shown on the right to enable it.  Log in and out to refresh the GUI page.	config system modem set status enable end
2. Viewing the supported modem lists
Go to Network > Modem and select Configure Modem.
Click the FortiGuard button to get the latest version of the supported modem lists, and then select the plus button to expand either list.

Method 2: Viewing the FortiExtender Modem List

After connecting the FortiExtender to the FortiGate using a QuickStart guide, follow the example below. 

A FortiExtender 100B and a FortiGate 100D running a 5.4 (Interim build) were used in this example.

1. Enabling the FortiGate to show FortiExtender configurations
Enable the Control And Provisioning of Wireless Access Points (CAPWAP) on the port which the FortiExtender is connected to. This allows the FortiExtender to communicate with the FortiGate using CAPWAP. Enter the following CLI commands:	config system interface edit [port] append allowaccess capwap end
The FortiExtender configuration is hidden in the FortiGate GUI by default. Enter the following CLI commands to enable it:	config system global set fortiextender enable set wireless-controller enable end
Go to System > Feature Select and enable FortiExtender features.
2. Authorizing the FortiExtender
Go to Network > FortiExtender and set the Interface Name to the port the FortiExtender is connected to. Select Authorize.
3. Viewing the supported modem lists
Go to Network > FortiExtender select Configure Settings.
Select Supported Modems to go to the supported modem lists.
Click the FortiGuard button to get the latest version of the supported modem lists, and then select the plus button to expand either list.

For further reading, check out Modem in the FortiOS 5.2 Handbook.

The post Viewing the FortiGate or FortiExtender Modem List appeared first on Fortinet Cookbook.

This traffic shaping document describes Priority Queueing (PRIQ), Type of Service (ToS) priority, and Quality of Service (QoS). It also explains the following:

• Why traffic shaping only occurs when traffic approaches the configured capacity on a given interface.
• Why you should configure the FortiGate unit to preemptively drop excess packets.
• How priority queues work on the FortiGate.
• The difference between ToS-based priority and global ToS priority.
• Why you must enable traffic shaping for ALL firewall policies to get expected results.
• How firewall policy priorities and ToS policies affect each other.
• Why traffic shaper priorities only effect per port egress queueing.

Any CLI commands and GUI references in this article have been tested for both FortiOS 5.2.5 and FortiOS 5.4, and any differences between versions will be documented.

How traffic shaping really works

One of the most common misconceptions with traffic shaping on your FortiGate is that setting a “priority” will ensure that high priority traffic will download faster than low priority traffic. This perfectly reasonable expectation does not fully encapsulate what “priority” means in FortiOS, which needs to be taken into consideration. Traffic shaping will only begin to take effect when an interface with traffic shaping configured reaches its capacity. Until this threshold is reached all traffic is treated equally. As the interface experiences high traffic levels that reach its threshold, you will begin to notice a variation in traffic flow or download speeds.

Figure 1: A screenshot of a shaper at capacity in the FortiView > Traffic Shaping section (FortiOS 5.4).

Before you begin

There are a few things you need to know about Traffic Shaping and priority queueing before we begin:

• Packets are prioritized based on their priority value.
• The priority value is based on whether you have configured Type of Service (ToS) priority and/or Firewall policy priority.
• The total priority value then determines which queue the packet is placed in, out of six queue options.

• Also, remember that only per port egress queueing works!

Other considerations that affect which queue is used include:

• Whether the traffic is through traffic or originates on the FortiGate.
• Whether traffic shaping is enabled in all your firewall policies.

Traffic shaping methods

When deciding how to configure QoS techniques, it can be helpful to know when FortiGate units employ each technique in the overall traffic processing flow, and the considerations that follow.

Dropping excess packets early on

As traffic arrives (ingress) and departs (egress) on an interface, the FortiGate unit begins to process the traffic. In later phases of network processing — such as enforcing maximum bandwidth on sessions handled by a security policy — if the current rate for the destination interface or traffic regulated by that policy is too high, the FortiGate unit may drop the packet. Time spent on prior processing — like web filtering, decryption, or IPS — is wasted on these dropped packets.

You can prevent wasted effort on ingress by configuring the FortiGate unit to preemptively drop excess packets when they are received at the source interface, before most other traffic processing is performed:

config system interface
  edit <interface_name>
    set inbandwidth <rate_int>
    set outbandwidth <rate_int>
  next
end

Where <rate_int> is set to the bandwidth limit in Kb/s, excess packets will be dropped. If the inbandwidth <rate_int> is set to 0, then the rate is not limited.

As with ingress, if you set the rate to 0 (zero) that means you are setting the rate to unlimited. Rate limiting traffic accepted by the interface enables you to restrict incoming traffic to rates that, while no longer the full capacity of the interface, at the traffic shaping point in the processing are more likely to result in acceptable rates of outgoing traffic per destination interface or all security policies. This conserves FortiGate processing resources for those packets likely to be viable (to the point of egress).

Figure 2: This diagram shows how excess packets going from LAN to WAN 1 can be intercepted and dropped at the source interface. 

How priority queuing works

After packet acceptance, the FortiGate unit classifies traffic and may apply traffic policing at additional points during processing. It may also apply QoS techniques, such as prioritization and traffic shaping. Traffic shaping consists of a mixture of traffic policing to enforce bandwidth limits, and priority queue adjustment to assist packets in achieving the guaranteed rate.

If you have configured prioritization, the FortiGate unit prioritizes egressing packets by distributing them among FIFO (first in, first out) queues associated with each possible priority number. Each physical interface has six priority queues. Virtual interfaces use the priority queues of the physical interface to which they are bound.

Each physical interface’s six queues are queue 0 to queue 5, where queue 0 is the highest priority queue. However, you may observe that your traffic uses only a subset of those six queues. For example, some traffic may always use a certain queue number. Queuing may also vary by the packet rate or mixture of services. Some queue numbers may only be used by through traffic for which you have configured traffic shaping in the security policy that applies to that traffic session. 

Figure 3: This diagram illustrates the description below.

• Administrative access traffic will always use queue 0.
• Traffic matching security policies without traffic shaping may use queue 0, queue 1, or queue 2. The queue is selected based on the priority value you have configured for packets with that ToS (Type of Service) bit value, if you have configured ToS-based priorities.
• Traffic matching security policies with traffic shaping enabled in the policy may use any queue. The queue is selected based on whether the packet rate is currently below the guaranteed bandwidth (queue 0), or above the guaranteed bandwidth. Packets at rates greater than the maximum bandwidth limit are dropped.
• If the global tos-based-priority is low (3) and the priority in a traffic-shaper is medium (2), when a packet flows through a policy that refers to the shaper, the packet will be assigned the priority defined by the shaper. In this case, medium (2).

Types of priority

Prioritization and traffic shaping behavior vary based on the configuration, service type, traffic volume, and whether the traffic is through traffic or originates at the FortiGate unit itself.

Packets can be assigned a priority in one of three ways:

• On entering ingress – for packets flowing through the firewall.
• Upon generation – for packets generated by the firewall (including packets generated due to AV proxying).
• On passing through a firewall policy – for packets passing through a firewall policy that has a traffic shaper defined.

Ingress priority and priority for generated packets is controlled via two different CLI settings:

config system global
  set traffic-priority-level {high|medium|low}
end

config system tos-based-priority
  edit 1
    set tos [0-15]
    set priority (high|medium|low)
  next
end

Type of Service (ToS) priority

Type of Service is an 8-bit field in the IP header that allows you to determine how the IP datagram should be delivered, using the following criteria: Delay, Throughput, Priority, Reliability, and Cost. The criteria help gateways pick the best way to route datagrams.

A router maintains a ToS value for each route in its routing table. The lowest priority ToS is 0, and the highest is 7 (when bits 3, 4, and 5 are all set to 1). There are four other bits that are seldom used or reserved that are not included here.

Together these bits are the tos variable of the tos-based-priority command. The router tries to match the ToS of the datagram to the ToS on one of the available routes to the destination. If there is no match, then the datagram is sent over a zero ToS route. Using increased quality may increase the cost of delivery, because better performance may consume limited network resources.

Each bit represents the priority as per RFC 1349:

• 1000 – minimize delay
• 0100 – maximize throughput
• 0010 – maximize reliability
• 0001 – minimize monetary cost

The tos value is set in the CLI using the commands:

config system tos-based-priority
  edit <sequence_number>
    set tos [0-15]
    set priority [high | medium | low]
end

Where tos is the value of the type of service bit in the IP datagram header with a value between 0 and 15, and priority is the priority of this type of service. 

These priority levels conform to the firewall traffic shaping priorities, as defined in RFC 1349.

Firewall policy priority

All traffic shapers are enabled within a security policy, including the Application Control shapers. As such, the shapers take effect after any DoS detection policies, and before any routing or packet scanning occurs.

The shaper you select for the security policy (shared shaper) will affect the traffic in the direction defined in the policy. For example, if the source port is lan and the destination is wan 1, the shaping affects the flow in this direction only — affecting the upload speed of the outbound traffic. 

By selecting Shared Traffic Shaper Reverse Direction, you can define the traffic shaper for the policy in the opposite direction to affect the download speed of the inbound traffic. In this example, from wan 1 to lan.

config firewall policy
  edit <policy_number>
  ...
    set traffic-shaper <shaper_name>
    set per-ip-shaper <shaper_name>
    set traffic-shaper-reverse <shaper_name>
end

In a firewall policy you can enable traffic shaping and set the firewall priority to high, medium, or low:

Since all security policies are set to “high” priority by default, it is necessary to set some traffic at a lower priority to get results. When you enable traffic shaping, and change the priority to medium or low it will override the default setting.

To have proper QoS using the FortiGate, the firewall policy you create between your incoming interface and outgoing interface should include two interfaces. For example, a LAN to WAN 1 policy. 

Important: Make sure that ALL the firewall policies that use these two interfaces for communication have traffic shaping enabled!

In versions of FortiOS 5.2 and earlier, you must enable traffic shaping at the policy level for each individual policy:

Figure 4: A screenshot of a FortiOS 5.2 Security Policy with all types of traffic shaping enabled, under Policy & Objects > Policy > IPv4.

This is no longer necessary in FortiOS 5.4, as the new Traffic Shaping Policies allow you to apply traffic shaping globally to any traffic matching your criteria. The criteria must specify a source, a destination, a service, and the outgoing interface:

Figure 5: A screenshot of a FortiOS 5.4 traffic shaping policy, under Policy & Objects > Traffic Shaping Policy.

How do these priorities affect each other?

The global or ingress ToS-based priority value is combined with the firewall policy priority value:

Global priority (0, 1, 2) + policy priority (1, 2, 3) = total priority (queue number).

Let’s take a look at some examples:

• If we assume a default ingress priority of low (2) and a firewall policy priority of low (3), then the resulting priority is 5.
• If the packet flowing through results in a rate that is less than the guaranteed bandwidth, then the priority is set to 0 regardless of the priority in the firewall policy.
• If the packet flowing through results in a rate that’s above the maximum bandwidth, then the packet is dropped.
• If the packet flowing through results in a rate that is between the guaranteed and the maximum bandwidth, then the packet priority is increased by the priority from the policy. Therefore, assuming a default ingress priority of high (0) and a firewall policy of high (1), then the resulting priority is 1.
• When a packet is sent to the egress device, it is attached to a queue based on the packet priority. For example, priority 0 is attached to queue 1, and so on. If the queue is full, then the packet is dropped.

Important: Shaper priority only affects per port egress queueing. Thus, if there are two streams of traffic — with one egressing over port 1 and one egressing over port 2 — then the priority has no effect whatsoever. Both streams will continue to run at full speed.

Traffic passing through the FortiGate

The method a FortiGate unit uses to determine the priority queue for traffic passing through the FortiGate unit depends on whether you have enabled Traffic Shaping. Packets may or may not use a priority queue directly or indirectly derived from the type of service (ToS) bit — sometimes used instead with differentiated services — in the packet’s IP header.

If Traffic Shaping is not enabled in the security policy, the FortiGate unit neither limits nor guarantees bandwidth. Traffic shaping for that session uses the priority queue determined by matching the ToS bit in its header with your configured values:

config system global
  set traffic-priority-level {high | medium | low}
end

or, if you have configured a priority specifically for that TOS bit value:

config system tos-based-priority
  edit <id_int>
    set tos [0-15]
    set priority {high | medium | low}
  next
end

Where tos is the value of the ToS bit in the packet’s IP header, and high has a value of 0 and low is 2. Priority values configured in the second location will override the global ToS-based priority. In other words, packet priority = ToS-based priority.

For example, you might specify that packets with a ToS bit value of 2 should use queue 0, the highest priority queue: 

config system tos-based-priority
  edit 15
    set tos 2
    set priority high
  next
end

If Traffic Shaping is enabled in the security policy using shared traffic shapers, the FortiGate unit may instead or also subject packets to traffic policing or priority queue increases in an effort to meet bandwidth guarantees configured in the shaper:

config firewall shaper traffic-shaper
  edit <shaper_name>
  ...
    set priority {high | medium | low }
    set maximum bandwidth <rate>
    set guaranteed-bandwidth <rate>
end

Where high has a priority value of 1 and low is 3, and <rate> is the bandwidth limit in kilobits per second.

Figure 6: Traffic queueing as as the packet rate increases.

• If the current packet rate is less than the guaranteed bandwidth, packets use priority queue 0. In other words, packet priority = 0.
• If the current packet rate is greater than the guaranteed bandwidth, but less than maximum bandwidth, the FortiGate unit assigns a priority queue by adding the numerical value of the security policy-based priority, where high has a priority value of 0 and low is 2. Because the two values are added, depending on the configured ToS-based priorities, packets in this category could use queues from queue 1 to queue 5. In other words, packet priority = ToS-based priority + security policy-based priority. For example, if you have enabled Traffic Shaping in the security policy, and the security policy’s Traffic Priority is Low (value 3), and the priority normally applied to packets with that ToS bit is medium (value 1), then packets have a total packet priority of 4, and use priority queue 4.
• If the current packet rate exceeds the maximum bandwidth, excess packets are dropped.

Traffic originating at the FortiGate 

Security policies do not apply to administrative access traffic to the FortiGate through HTTPS or SSH, or IPsec tunnel negotiations. Consequently, FortiGates do not apply traffic shaping to these types of traffic. These types of traffic use the highest priority queue, queue 0. In other words, packet priority = 0.

Exceptions to this rule include traffic types with connections that are related to a session governed by a security policy. For example, if you have enabled FortiGuard AntiVirus scanning, traffic from the sender technically terminates at the FortiGate proxy that scans that traffic type; the FortiGate unit initiates a second connection that transmits scanned content to its destination. Because the second connection’s traffic is technically originating from the FortiGate proxy, and therefore the FortiGate unit itself, it uses the highest priority queue, queue 0. However, this connection is logically associated with through traffic, and is therefore subject to possible bandwidth enforcement and guarantees in its governing security policy. In this way, it behaves partly like other through traffic.

Egress queueing

Shaper priority only affects per port egress queueing, so if you have two streams of traffic — like one egressing over Port1 and one egressing over Port2 — then priority has no effect whatsoever. Both streams will continue to run at full speed.

[Source: Stevan Bevan -Tracking No. 227414)]

To make any difference to the order in which packets egress the interface, there must be packets of a lower priority queued on the egress interface. This usually happens when there is an imbalance between the packet rates on the interfaces.

For example, if the LAN is 1Gb, but the WAN is only 100MB. In this scenario the priority of the traffic egressing the WAN is very important, but the traffic egressing the LAN is rendered irrelevant (as it would take 10 WAN links to drive traffic at a high enough rate to cause queuing interference on the LAN interface).

This was tested by performing a debug on the kernel to determine when priority would take effect. In this case, by counting how many times the egress interface had more than one packet in the queue. Two simultaneous 500MB downloads via HTTP were performed, with one policy set to a high priority and one set to a low priority. Results showed that there was more than one packet in the egress queue only 23 times. With over 600,000 packets egressing over that interface, altering the priority of 23 does not make a practical difference to the relative speed of downloads.

Resources

In the FortiOS Handbook, you may be interested in checking out the following Traffic Shaping sections:

• Important Considerations for more information.
• Troubleshooting for diagnose commands.
• Traffic Shaper Monitor for how to view traffic shaping results.

The post Traffic Shaping Priority Queueing (PRIQ) 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 the default configuration for FortiOS 5.2, several FortiGuard categories and firewall addresses appear in the Exempt from SSL Inspection list. However, if you upgrade your FortiGate to 5.2 from an earlier version, these addresses are not added to your configuration unless you perform a factory reset.

If you would like to manually add some or all of these exemptions to your configuration, the screenshots below show the complete list of the exemptions and information about the firewall addresses.

The exemption list

This image shows the Exempt from SSL Inspection list from the default 5.2 configuration.

Default firewall addresses

This image shows the Firewall Address list from the default 5.2 configuration. This includes addresses that are not part of the exemption list, such as the default addresses for SSL VPN users.

CLI syntax

The following CLI commands can be used to add the firewall addresses to your FortiGate, then set them as exceptions in the deep-inspection profile.

config firewall address
  edit "adobe"
    set type wildcard-fqdn
    set wildcard-fqdn "*.adobe.com"
  next
  edit "Adobe Login"
    set type wildcard-fqdn
    set wildcard-fqdn "*.adobelogin.com"
  next
  edit "android"
    set type wildcard-fqdn
    set wildcard-fqdn "*.android.com"
  next
  edit "apple"
    set type wildcard-fqdn
    set wildcard-fqdn "*.apple.com"
  next
  edit "appstore"
    set type wildcard-fqdn
    set wildcard-fqdn "*.appstore.com"
  next
  edit "auth.gfx.ms"
    set type fqdn
    set fqdn "auth.gfx.ms"
  next
  edit "autoupdate.opera.com"
    set type fqdn
    set fqdn "autoupdate.opera.com"
  next
  edit "citrix"
    set type wildcard-fqdn
    set wildcard-fqdn "*.citrixonline.com"
  next
  edit "dropbox.com"
    set type wildcard-fqdn
    set wildcard-fqdn "*.dropbox.com"
  next
  edit "eease"
    set type wildcard-fqdn
    set wildcard-fqdn "*.eease.com"
  next
  edit "firefox update server"
    set type wildcard-fqdn
    set wildcard-fqdn "aus*.mozilla.org"
  next
  edit "fortinet"
    set type wildcard-fqdn
    set wildcard-fqdn "*.fortinet.com"
  next
  edit "google-drive"
    set type wildcard-fqdn
    set wildcard-fqdn "*drive.google.com"
  next
  edit "google-play"
    set type fqdn
    set fqdn "play.google.com"
  next
  edit "google-play2"
    set type wildcard-fqdn
    set wildcard-fqdn "*.ggpht.com"
  next
  edit "google-play3"
    set type wildcard-fqdn
    set wildcard-fqdn "*.books.google.com"
  next
  edit "googleapis.com"
    set type wildcard-fqdn
    set wildcard-fqdn "*.googleapis.com"
  next
  edit "Gotomeeting"
    set type wildcard-fqdn
    set wildcard-fqdn "*.gotomeeting.com"
  next
  edit "icloud"
    set type wildcard-fqdn
    set wildcard-fqdn "*.icloud.com"
  next
  edit "itunes"
    set type wildcard-fqdn
    set wildcard-fqdn "*itunes.apple.com"
  next
  edit "microsoft"
    set type wildcard-fqdn
    set wildcard-fqdn "*.microsoft.com"
  next
  edit "skype"
    set type wildcard-fqdn
    set wildcard-fqdn "*.messenger.live.com"
  next
  edit "softwareupdate.vmware.com"
    set type fqdn
    set fqdn "softwareupdate.vmware.com"
  next
  edit "swscan.apple.com"
    set type fqdn
    set fqdn "swscan.apple.com"
  next
  edit "update.microsoft.com"
    set type fqdn
    set fqdn "update.microsoft.com"
  next
  edit "verisign"
    set type wildcard-fqdn
    set wildcard-fqdn "*.verisign.com"
  next
  edit "Windows update 2"
    set type wildcard-fqdn
    set wildcard-fqdn "*.windowsupdate.com"
  end
end

config firewall ssl-ssh-profile
  edit deep-inspection
    config ssl-exempt
      edit 0
        set type address
        set address "adobe"
      next
      edit 0
        set type address
        set address "Adobe Login"
      next      
      edit 0
        set type address
        set address "android"
      next
      edit 0
        set type address
        set address "apple"
      next
      edit 0
        set type address
        set address "appstore"
      next
      edit 0
        set type address
        set address "auth.gfx.ms"
      next
      edit 0
        set type address
        set address "autoupdate.opera.com"
      next
      edit 0
        set type address
        set address "citrix"
      next
      edit 0
        set type address
        set address "dropbox.com"
      next
      edit 0
        set type address
        set address "eease"
      next
      edit 0
        set type address
        set address "firefox update server"
      end
      edit 0
        set type address
        set address "fortinet"
      next
      edit 0
        set type address
        set address "google-drive"
      next
      edit 0
        set type address
        set address "google-play"
      next
      edit 0
        set type address
        set address "google-play2"
      next
      edit 0
        set type address
        set address "google-play3"
      next
      edit 0
        set type address
        set address "googleapis.com"
      next
      edit 0
        set type address
        set address "Gotomeeting"
      next
      edit 0
        set type address
        set address "icloud"
      next
      edit 0
        set type address
        set address "itunes"
      next
      edit 0
        set type address
        set address "microsoft"
      next
      edit 0
        set type address
        set address "skype"
      next
      edit 0
        set type address
        set address "softwareupdate.vmware.com"
      next
      edit 0
        set type address
        set address "swscan.apple.com"
      next
      edit 0
        set type address
        set address "update.microsoft.com"
      next
      edit 0
        set type address
        set address "verisign"
      next
      edit 0
        set type address
        set address "Windows update 2"
      next
    end
  end

For more information about exemptions to SSL inspection, see Exempting Google from SSL inspection.

The post Default exemptions in the SSL deep-inspection profile appeared first on Fortinet Cookbook.

As you may expect, we here in the Technical Documentation team get asked a lot of questions. Sometimes we even get asked the same question more than once. I strongly suspect that this repetitive intrusion upon some poor subject matter expert in the past brought into being the concept of documentation in the first place. Therefore we are continuing the time honored tradition of having an FAQ page. 

The FAQ can be found by going to http://cookbook.fortinet.com/sysadmins-notebook/frequently-asked-questions/ or by going to the Cookbook site, selecting Resources and then selecting FAQ.

Being the lazy efficient folks that we are, rather than answering a similar question a number of different times with differing levels of depth we are going to come up with a single answer once, and possibly add improvements later.

The criteria for inclusion in the FAQ is going to be questions that we have been asked multiple times and/or we can safely assume will be asked again.

The subjects of the questions will generally be those that don’t really fit into the context of one of our existing documents/pages/posts or we believe that the answer to a fairly common and straightforward question will lost amidst all of the other information on the topic.

Occasionally we may include topics/questions that were the result of a post of their own. This will usually happen when the amount of content is fairly small and we want to make sure that it maintains a certain amount of visibility. Once a post that we think warrants inclusion gets pushed back far enough in the display sequence we will move its content to the FAQ.

Of course the best part of all this (for our readers), is that readers are in position to help drive the course of the content for the site.

To submit a question you think should be in the FAQ:

• Post a comment on the FAQ page
• Post a comment on this post
• Send an email to techdocs@fortinet.com

The post New FAQ page appeared first on Fortinet Cookbook.