Category Archives: FortiGate

Permissions – FortiOS 6.2

Permissions

Access profiles control which CLI commands an administrator account can access. Access profiles assign either read, write, or no access to each area of FortiOS. To view configurations, you must have read access. To make changes, you must have write access. So, depending on the account used to log in to the FortiGate, you may not have complete access to all CLI commands. For complete access to all commands, you must log in with an administrator account that has the super_admin access profile. By default the admin administrator account has the super_admin access profile.

Administrator accounts, with the super_admin access profile are similar to a root administrator account that always has full permission to view and change all FortiGate configuration options, including viewing and changing all other administrator accounts and including changing other administrator account passwords.

Increasing the security of administrator accounts

Set strong passwords for all administrator accounts (including the admin account) and change passwords regularly.

CLI Command syntax – FortiOS 6.2

Leave a reply

Command syntax

When entering a command, the CLI console requires that you use valid syntax and conform to expected input constraints. It will reject invalid commands.

Fortinet documentation uses the conventions below to describe valid command syntax.

Terminology

Each command line consists of a command word that is usually followed by configuration data or other specific item that the command uses or affects.

To describe the function of each word in the command line, especially if that nature has changed between firmware versions, Fortinet uses terms with the following definitions:

Command — A word that begins the command line and indicates an action that the FortiGate should perform on a part of the configuration or host on the network, such as config or execute. Together with other words, such as fields or values, that end when you press the Enter key, it forms a command line. Exceptions include multiline command lines, which can be entered using an escape sequence. Valid command lines must be unambiguous if abbreviated. Optional words or other command line permutations are indicated by syntax notation.
Sub-command — A config sub-command that is available only when nested within the scope of another command. After entering a command, its applicable sub-commands are available to you until you exit the scope of the command, or until you descend an additional level into another sub-command. Indentation is used to indicate levels of nested commands.Not all top-level commands have sub-commands. Available sub-commands vary by their containing scope.
Object — A part of the configuration that contains tables and /or fields. Valid command lines must be specific enough to indicate an individual object.
Table — A set of fields that is one of possibly multiple similar sets which each have a name or number, such as an administrator account, policy, or network interface. These named or numbered sets are sometimes referenced by other parts of the configuration that use them.
Field — The name of a setting, such as ip or hostname. Fields in some tables must be configured with values. Failure to configure a required field will result in an invalid object configuration error message, and the FortiGate will discard the invalid table.
Value — A number, letter, IP address, or other type of input that is usually your configuration setting held by a field. Some commands, however, require multiple input values which may not be named but are simply entered in sequential order in the same command line. Valid input types are indicated by constraint notation. l Option — A kind of value that must be one or more words from of a fixed set of options.

Indentation

Indentation indicates levels of nested commands, which indicate what other sub-commands are available from within the scope. The “next” and “end” lines are used to maintain a hierarchy and flow to CLI commands, especially helping to distinguish those commands with extensive sub-commands.

The “next” line is entered at the same indentation-level as the previous “edit”, to mark where you would like to finish that table entry and move on to the next table entry; doing so will not mean that you have “left” that sub-command.

next

Below is an example command, with a sub-command of entries:

After entering settings for <2> and entering next, the <2> table entry has been saved, and you be set back one level of indentation so you can continue to create more entries (if you wish).

This hierarchy is best indicated in the CLI console, as the example below is what displays in the console after entering

end

Below is the same command and sub-command, except end has been entered instead of next after the subcommand:

Entering end will save the <2> table entry, but bring you out of the sub-command entirely; in this example, you would enter this when you don’t wish to continue creating new entries.

Again, your hierarchy is best indicated by the CLI console. Below is what displays in the console after entering end:

Notation

Brackets, braces, and pipes are used to denote valid permutations of the syntax. Constraint notations, such as <address_ipv4>, indicate which data types or string patterns are acceptable value input.

All syntax uses the following conventions:

Convention Description
Square brackets [ ] An optional word or series of words. For example: [verbose {1 \| 2 \| 3}] indicates that you may either omit or type both the word verbose and its accompanying option/s, such as verbose 3. See Optional values and ranges below for more information.
Curly braces { } A word or series of words that is constrained to a set of options delimited by either vertical bars or spaces. You must enter at least one of the options, unless the set of options is surrounded by square brackets [ ].
Mutually exclusive options – Both mutually and non-mutually exclusive commands will use curly braces, as delimited by vertical bars \| they provide multiple options, however mutually exclusive commands will divide each option with a pipe. This indicates that you are permitted to enter one option or the other: {enable \| disable}
Convention	Description
Non-mutually exclusive options – delimited by spaces	Non-mutually exclusive commands do not use pipes to divide their options. In those circumstances, multiple options can be entered at once, as long as they are entered with a space separating each option: {http https ping snmp ssh telnet}
Angle brackets < >	A word constrained by data type. The angled brackets contain a descriptive name followed by an underscore ( _ ) and suffix that indicates the valid data type. For example, <retries_int>, indicates that you should enter a number of retries as an integer. Data types include: l <xxx_name>: A name referring to another part of the configuration, such as policy_A. l <xxx_index>: An index number referring to another part of the configuration, such as 0 for the first static route. l <xxx_pattern>: A regular expression or word with wild cards that matches possible variations, such as *@example.com to match all email addresses ending in @example.com. l <xxx_fqdn>: A fully qualified domain name (FQDN), such as mail.example.com. l <xxx_email>: An email address, such as admin@example.com. l <xxx_ipv4>: An IPv4 address, such as 192.168.1.99. l <xxx_v4mask>: A dotted decimal IPv4 netmask, such as 255.255.255.0. l <xxx_ipv4mask>: A dotted decimal IPv4 address and netmask separated by a space, such as 192.168.1.99 255.255.255.0. l <xxx_ipv4/mask>: A dotted decimal IPv4 address and CIDR-notation netmask separated by a slash, such as 192.168.1.1/24 l <xxx_ipv4range> : A hyphen ( – )-delimited inclusive range of IPv4 addresses, such as 192.168.1.1-192.168.1.255. l <xxx_ipv6>: A colon( : )-delimited hexadecimal IPv6 address, such as 3f2e:6a8b:78a3:0d82:1725:6a2f:0370:6234. l <xxx_v6mask>: An IPv6 netmask, such as /96. l <xxx_ipv6mask>: A dotted decimal IPv6 address and netmask separated by a space. l <xxx_str>: A string of characters that is not another data type, such as P@ssw0rd. Strings containing spaces or special characters must be surrounded in quotes or use escape sequences. l <xxx_int>: An integer number that represents a metric, minutes_int for the number of minutes.

Optional values and ranges

Any field that is optional will use square-brackets, such as set comment. This is because it doesn’t matter whether it’s set or not. The overall config command will still successfully be taken.

Another example of where square-brackets would be used is to show that multiple options can be set, even intermixed with ranges. The example below shows a field that can be set to either a specific value or range, or multiple instances:

config firewall service custom

set iprange <range1> [<range2> <range3> …]

end

Sub-commands

Each command line consists of a command word that is usually followed by configuration data or other specific item that the command uses or affects:

get system admin

Sub-commands are available from within the scope of some commands. When you enter a sub-command level, the command prompt changes to indicate the name of the current command scope. For example, after entering:

config system admin

the command prompt becomes:

(admin)#

Applicable sub-commands are available to you until you exit the scope of the command, or until you descend an additional level into another sub-command.

For example, the edit sub-command is available only within a command that affects tables; the next sub-command is available only from within the edit sub-command:

config system interface edit port1 set status up

next

end

Sub-command scope is indicated by indentation.

Available sub-commands vary by command. From a command prompt within config, two types of sub-commands might become available:

l commands affecting fields l commands affecting tables

Commands for tables

clone <table>	Clone (or make a copy of) a table from the current object. For example, in config firewall policy, you could enter the following command to clone security policy 27 to create security policy 30: clone 27 to 30 In config antivirus profile, you could enter the following command to clone an antivirus profile named av_pro_1 to create a new antivirus profile named av_pro_2: clone av_pro_1 to av_pro_2 clone may not be available for all tables.
delete <table>	Remove a table from the current object.
		For example, in config system admin, you could delete an administrator account named newadmin by typing delete newadmin and pressing Enter. This deletes newadmin and all its fields, such as newadmin’s first-name and email-address. delete is only available within objects containing tables.
edit <table>		Create or edit a table in the current object. For example, in config system admin: l edit the settings for the default admin administrator account by typing edit admin. l add a new administrator account with the name newadmin and edit newadmin‘s settings by typing edit newadmin. edit is an interactive sub-command: further sub-commands are available from within edit. edit changes the prompt to reflect the table you are currently editing. edit is only available within objects containing tables. In objects such as security policies, <table> is a sequence number. To create a new entry without the risk of overwriting an existing one, enter edit 0. The CLI initially confirms the creation of entry 0, but assigns the next unused number after you finish editing and enter end.
end		Save the changes to the current object and exit the config command. This returns you to the top-level command prompt.
get		List the configuration of the current object or table.• In objects, get lists the table names (if present), or fields and their values.• In a table, get lists the fields and their values.For more information on get commands, see the CLI Reference.
purge		Remove all tables in the current object. For example, in config user local, you could type get to see the list of user names, then type purge and then y to confirm that you want to delete all users.purge is only available for objects containing tables. Caution: Back up the FortiGate before performing a purge. purge cannot be undone. To restore purged tables, the configuration must be restored from a backup. Caution: Do not purge system interface or system admin tables. purge does not provide default tables. This can result in being unable to connect or log in, requiring the FortiGate to be formatted and restored.
rename <table> to <table>		Rename a table. For example, in config system admin, you could rename admin3 to fwadmin by typing rename admin3 to fwadmin.rename is only available within objects containing tables.
show		Display changes to the default configuration. Changes are listed in the form of configuration commands.

Example of table commands

From within the system admin object, you might enter:

edit admin_1

The CLI acknowledges the new table, and changes the command prompt to show that you are now within the admin_1 table:

new entry ‘admin_1’ added

(admin_1)#

Commands for fields

abort		Exit both the edit and/or config commands without saving the fields.
append		Add an option to an existing list.
end		Save the changes made to the current table or object fields, and exit the config command (to exit without saving, use abort instead).
get		List the configuration of the current object or table. l In objects, get lists the table names (if present), or fields and their values. l In a table, get lists the fields and their values.
move		Move an object within a list, when list order is important. For example, rearranging security policies within the policy list.
next		Save the changes you have made in the current table’s fields, and exit the edit command to the object prompt (to save and exit completely to the root prompt, use end instead). next is useful when you want to create or edit several tables in the same object, without leaving and re-entering the config command each time. next is only available from a table prompt; it is not available from an object prompt.
select		Clear all options except for those specified. For example, if a group contains members A, B, C, and D and you remove all users except for B, use the command select member B.
set <field> <value>		Set a field’s value. For example, in config system admin, after typing edit admin, you could type set password newpass to change the password of the admin administrator to newpass. Note: When using set to change a field containing a space-delimited list, type the whole new list. For example, set <field> <new-value> will replace the list with the <new-value> rather than appending <new-value> to the list.
show		Display changes to the default configuration. Changes are listed in the form of configuration commands.
unselect		Remove an option from an existing list.
unset <field>		Reset the table or object’s fields to default values. For example, in config system admin, after typing edit admin, typing unset password resets the password of the admin administrator account to the default (in this case, no password).

Example of field commands

To assign the value my1stExamplePassword to the password field, enter the following command from within the admin_1 table:

set password my1stExamplePassword

Next, to save the changes and edit the next administrator’s table, enter the next command.

CLI-only features – FortiOS 6.2

Leave a reply

CLI-only features

As you can see in the Feature / Platform Matrix, the entry level models have a number of features that are only available using the CLI, rather than appearing in the GUI.

You can open the CLI console so that it automatically opens to the object you wish to configure. For example, to edit a firewall policy, right-click on the policy in the policy list (Policy & Objects > IPv4 Policy) and select Edit in CLI. The CLI console will appear, with the commands to access this part of the configuration added automatically.

Once you have access to the CLI, you can enter instructions for specific tasks that can be found throughout the FortiOS Handbook. Options are also available at the top of the CLI Console to Clear console, Download, and Copy to clipboard.

Refer to the CLI Reference for a list of the available commands.

Connecting to the CLI – FortiOS 6.2

Leave a reply

Connecting to the CLI

You can access the CLI in three ways:

Local console — Connect your computer directly to the console port of your FortiGate. Local access is required in some cases:
If you are installing your FortiGate for the first time and it is not yet configured to connect to your network, you may only be able to connect to the CLI using a local serial console connection, unless you reconfigure your computer’s network settings for a peer connection.
Restoring the firmware utilizes a boot interrupt. Network access to the CLI is not available until after the boot process has completed, making local CLI access the only viable option.
SSH or Telnet access — Connect your computer through any network interface attached to one of the network ports on your FortiGate. The network interface must have enabled Telnet or SSH administrative access if you connect using an SSH/Telnet client, or HTTP/HTTPS administrative access if you connect by accessing the CLI Console in the GUI. The CLI console can be accessed from the upper-right hand corner of the screen and appears as a slide-out window. l — Use the FortiExplorer app on your iOS device to configure, manage, and monitor your FortiGate.

Local console

Local console connections to the CLI are formed by directly connecting your management computer or console to the FortiGate unit, using its DB-9 or RJ-45 console port. To connect to the local console you need:

A computer with an available serial communications (COM) port.
The RJ-45-to-DB-9 or null modem cable included in your FortiGate package.
Terminal emulation software such as HyperTerminal for Microsoft Windows.

The following procedure describes the connection using Microsoft HyperTerminal software; steps may vary with other terminal emulators.

To connect to the CLI using a local serial console connection

Using the null modem or RJ-45-to-DB-9 cable, connect the FortiGate unit’s console port to the serial communications (COM) port on your management computer.
On your management computer, start HyperTerminal.
For the Connection Description, enter a Name for the connection, and select OK.
On the Connect using drop-down, select the communications (COM) port on your management computer you are using to connect to the FortiGate unit.
Select OK.
Select the following Port settings and select OK.

Bits per second	9600
Data bits	8
Parity	None
Stop bits	1
Flow control	None

Press Enter or Return on your keyboard to connect to the CLI.
Type a valid administrator account name (such as admin) and press Enter.
Type the password for that administrator account and press Enter. (In its default state, there is no password for the admin )

The CLI displays the following text:

Welcome!

Type ? to list available commands.

You can now enter CLI commands, including configuring access to the CLI through SSH or Telnet.

SSH or Telnet access

SSH or Telnet access to the CLI is accomplished by connecting your computer to the FortiGate unit using one of its RJ-45 network ports. You can either connect directly, using a peer connection between the two, or through any intermediary network.

You must enable SSH and/or Telnet on the network interface associated with that physical network port. If your computer is not connected directly or through a switch, you must also configure the FortiGate unit with a static route to a router that can forward packets from the FortiGate unit to your computer. You can do this using either a local console connection or the GUI.

Requirements

l A computer with an available serial communications (COM) port and RJ-45 port l Terminal emulation software such as HyperTerminal for Microsoft Windows l The RJ-45-to-DB-9 or null modem cable included in your FortiGate package l A network cable l Prior configuration of the operating mode, network interface, and static route.

To enable SSH or Telnet access to the CLI using a local console connection

Using the network cable, connect the FortiGate unit’s network port either directly to your computer’s network port, or to a network through which your computer can reach the FortiGate unit.
Note the number of the physical network port.
Using a local console connection, connect and log into the CLI.
Enter the following command:

config system interface edit <interface_str> set allowaccess <protocols_list>

end

where:

<interface_str> is the name of the network interface associated with the physical network port and containing its number, such as port1.
<protocols_list> is the complete, space-delimited list of permitted administrative access protocols, such as https ssh telnet.

To confirm the configuration, enter the command to display the network interface’s settings:

show system interface <interface_str>

The CLI displays the settings, including the allowed administrative access protocols, for the network interfaces.

Connecting using SSH

Once the FortiGate unit is configured to accept SSH connections, you can use an SSH client on your management computer to connect to the CLI.

Secure Shell (SSH) provides both secure authentication and secure communications to the CLI. FortiGate units support 3DES and Blowfish encryption algorithms for SSH.

Before you can connect to the CLI using SSH, you must first configure a network interface to accept SSH connections. The following procedure uses PuTTY. Steps may vary with other SSH clients.

To connect to the CLI using SSH

On your management computer, start an SSH client.
In Host Name (or IP address), enter the IP address of a network interface on which you have enabled SSH administrative access.
Set Port to 22.
For the Connection type, select SSH.
Select Open. The SSH client connects to the FortiGate unit.

The SSH client may display a warning if this is the first time you are connecting to the FortiGate unit and its SSH key is not yet recognized by your SSH client, or if you have previously connected to the FortiGate unit but used a different IP address or SSH key. This is normal if your management computer is directly connected to the FortiGate unit with no network hosts between them.

Click Yes to verify the fingerprint and accept the FortiGate unit’s SSH key. You will not be able to log in until you have accepted the key.
The CLI displays a login prompt.
Type a valid administrator account name (such as admin) and press Enter.
Type the password for this administrator account and press Enter.

The FortiGate unit displays a command prompt (its hostname followed by a #). You can now enter CLI commands.

Connecting using Telnet

Once the FortiGate unit is configured to accept Telnet connections, you can use a Telnet client on your management computer to connect to the CLI.

Before you can connect to the CLI using Telnet, you must first configure a network interface to accept Telnet connections.

To connect to the CLI using Telnet

On your management computer, start a Telnet client.
Connect to a FortiGate network interface on which you have enabled Telnet.
Type a valid administrator account name (such as admin) and press Enter.
Type the password for this administrator account and press Enter. The FortiGate unit displays a command prompt (its hostname followed by a #). You can now enter CLI commands.

Text strings – FortiOS 6.2

Leave a reply

Text strings

The configuration of a FortiGate is stored in the FortiOS configuration database. To change the configuration, you can use the GUI or CLI to add, delete, or change configuration settings. These changes are stored in the database as you make them. Individual settings in the configuration database can be text strings, numeric values, selections from a list of allowed options, or on/off (enable/disable) settings.

Entering text strings (names)

Text strings are used to name entities in the configuration. For example, the name of a firewall address, the name of an administrative user, and so on. You can enter any character in a FortiGate configuration text string, except the following characters that present cross-site scripting (XSS) vulnerabilities: l “ (double quote) l & (ampersand) l ‘ (single quote) l < (less than) l > (greater than)

Most GUI text string fields make it easy to add an acceptable number of characters and prevent you from adding the XSS vulnerability characters.

You can also use the tree command in the CLI to view the number of characters allowed in a name field. For example, firewall address names can contain up to 64 characters. When you add a firewall address to the GUI, you are limited to entering 64 characters in the firewall address name field. From the CLI you can enter the following tree command to confirm that the firewall address name field allows 64 characters.

config firewall address tree

— [address] –*name (64)

|- uuid

|- subnet

|- type

|- start-ip

|- end-ip

|- fqdn (256)

|- country (3)

|- cache-ttl (0,86400)

|- wildcard

|- comment

|- visibility

|- associated-interface (36)

|- color (0,32)

|- [tags] –*name (65)

+- allow-routing

The tree command output also shows the number of characters allowed for other firewall address name settings. For example, the fully qualified domain name (fqdn) field can contain up to 256 characters.

Entering numeric values

Numeric values set various sizes, rates, addresses, and other numeric values (e.g. a static routing priority of 10, a port number of 8080, an IP address of 10.10.10.1). Numeric values can be entered as a series of digits without spaces or commas (for example, 10 or 64400), in dotted decimal format (for example the IP address 10.10.10.1) or, as in the case of MAC or IPv6 addresses, separated by colons (e.g. the MAC address 00:09:0F:B7:37:00). Most numeric values are standard base 10 numbers, but some fields, such as MAC addresses, require hexadecimal numbers.

Most GUI numeric value fields make it easy to add the acceptable number of digits within the allowed range. CLI help text includes information about allowed numeric value ranges. Both the GUI and the CLI prevent you from entering invalid numbers.

Dashboard – FortiOS 6.2

Leave a reply

Dashboard

The FortiOS Dashboard consists of a Network Operations Center (NOC) view with a focus on alerts. Widgets are interactive. By clicking or hovering over most widgets, the user can see additional information or follow links to other pages.

The dashboard and its widgets include:

Multiple dashboard support l VDOM and global dashboards l Widget resize control l Notifications on the top header bar

The following widgets are displayed by default:

Widget	Description
System Information	The System Information widget lists information relevant to the FortiGate system, including hostname, serial number, and firmware.
Security Fabric	The Security Fabric widget displays a visual summary of many of the devices in the Fortinet Security Fabric.
CPU	The real-time CPU usage is displayed for different time frames.
Widget		Description
Licenses		Hovering over the Licenses widget results in the display of status information (and, where applicable, database information) on the licenses for FortiCare Support, Firmware & General Updates, AntiVirus, Web Filtering, Security Rating, FortiClient, and FortiToken. Note that Mobile Malware is not a separate service in FortiOS 6.0.0. The Mobile Malware subscription is included with the AntiVirus subscription. Clicking in the Licenses widget provides you with links to other pages, such as System > FortiGuard or contract renewal pages.
FortiCloud		This widget displays FortiCloud status and provides a link to activate FortiCloud.
Administrators		This widget allows you to view: l which administrators are logged in and how many sessions are active (a link directs you to a page displaying active administrator sessions) l all connected administrators and the protocols used by each
Memory		Real-time memory usage is displayed for different time frames. Hovering over any point on the graph displays percentage of memory used along with a timestamp.
Sessions		Hovering over the Sessions widget allows you to view memory usage data over time. Click on the down arrow to change the timeframe displayed. Security processing unit, or SPU, percentage is displayed if your FortiGate includes an SPU. Likewise, nTurbo percentage is displayed if supported by your FortiGate.
Bandwidth		Hover over the Bandwidth widget to display bandwidth usage data over time. Click on the down arrow to change the timeframe displayed. Bandwidth is displayed for both incoming and outgoing traffic.
Virtual Machine		The VM widget (shown by default in the dashboard of a FortiOS VM device) includes: l License status and type l CPU allocation usage l License RAM usage l VMX license information (if the VM supports VMX) If the VM license specifies ‘unlimited’ the progress bar is blank. If the VM is in evaluation mode, it is yellow (warning style) and the dashboard shows the number of evaluation days used.

The following optional widgets are also available:

FortiView l Host Scan Summary
Vulnerabilities Summary l Botnet Activity l HA Status l Log Rate l Session Rate l Security Fabric Score l Advanced Threat Protection Statistics l Interface Bandwidth

Modifying dashboard widget titles

Dashboard widget titles can be modified so that widgets with different filters applied can be easily differentiated. The widget has a default title unless you set a new title.

Syntax

config system admin edit <name> config gui-dashboard config widget edit 9 set type fortiview …

set title “test source by bytes”

end

Menus – FortiOS 6.2

Leave a reply

Menus

If you believe your FortiGate model supports a menu that does not appear in the GUI as expected, go to System > Feature Visibility and ensure the feature is enabled. For more information, see Feature Visibility on page 18.

The GUI contains the following main menus, which provide access to configuration options for most FortiOS features:

Dashboard	The dashboard displays various widgets that display important system information and allow you to configure some system options. For more information, see Dashboard on page 16.
Security Fabric	Access the physical topology, logical topology, audit, and settings features of the Fortinet Security Fabric. For more information, see Security Fabric on page 72.
FortiView	A collection of dashboards and logs that give insight into network traffic, showing which users are creating the most traffic, what sort of traffic it is, when the traffic occurs, and what kind of threat the traffic may pose to the network.
Network	Options for networking, including configuring system interfaces and routing options. For more information, see Network Configurations on page 95.
System	Configure system settings, such as administrators, FortiGuard, and certificates. For more information, see System Configurations on page 150.
Policy & Objects	Configure firewall policies, protocol options, and supporting content for policies, including schedules, firewall addresses, and traffic shapers. For more information, see Policies and Objects on page 224.
Security Profiles		Configure your FortiGate’s security features, including AntiVirus, Web Filtering, and Application Control. For more information, see Security Profiles on page 280.
VPN		Configure options for IPsec and SSL virtual private networks (VPNs). For more information, see IPsec VPNs on page 412 and SSL VPN on page 571.
User & Device		Configure user accounts, groups, and authentication methods, including external authentication and single sign-on (SSO).
WiFi & Switch Controller		Configure the unit to act as a wireless network controller, managing the wireless Access Point (AP) functionality of FortiWiFi and FortiAP units. On certain FortiGate models, this menu has additional features allowing for FortiSwitch units to be managed by the FortiGate. For more information, see WiFi on page 639.
Log & Report		Configure logging and alert email as well as reports. For more information, see Log and Report on page 718.
Monitor		View a variety of monitors, including the Routing Monitor, VPN monitors for both IPsec and SSL, monitors relating to wireless networking, and more.

Troubleshooting IPSEC

Leave a reply

Troubleshooting

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

A VPN connection has multiple stages that can be confirmed to ensure the connection is working properly. It is easiest to see if the final stage is successful first since if it is successful the other stages will be working properly. Otherwise, you will need to work back through the stages to see where the problem is located.

When a VPN connection is properly established, traffic will flow from one end to the other as if both ends were physically in the same place. If you can determine the connection is working properly then any problems are likely problems with your applications.

On some FortiGate units, such as the FortiGate 94D, you cannot ping over the IPsec tunnel without first setting a source-IP. In this scenario, you must assign an IP address to the virtual IPsec VPN interface. Anything sourced from the FortiGate going over the VPN will use this IP address.

If the egress/outgoing interface (determined by kernel route) has an IP address, then use the IP address of the egress/outgoing interface. Otherwise, use the IP address of the first interface from the interface list (that has an IP address).

The first diagnostic command worth running, in any IPsec VPN troubleshooting situation, is the following: diagnose vpn tunnel list

This command is very useful for gathering statistical data such as the number of packets encrypted versus decrypted, the number of bytes sent versus received, the SPI identifier, etc. This kind of information in the resulting output can make all the difference in determining the issue with the VPN.

Another appropriate diagnostic command worth trying is: diagnose debug flow

This command will inform you of any lack of firewall policy, lack of forwarding route, and of policy ordering issues.

Common IPsec VPN problems

The most common IPsec VPN issues are listed below. Please read thoroughly and note that, although the list is extensive, it is not exhaustive.

This section includes support for the following:

l Failed VPN connection attempts l Debug output table l The options to configure policy-based IPsec VPN are unavailable l The VPN tunnel goes down frequently l The pre-shared key does not match (PSK mismatch error) l The SA proposals do not match (SA proposal mismatch) l Pre-existing IPsec VPN tunnels need to be cleared l Other potential VPN issues

Failed VPN connection attempts

If your VPN fails to connect, check the following:

Ensure that the pre-shared keys match exactly (see The pre-shared key does not match (PSK mismatch error) below).
Ensure that both ends use the same P1 and P2 proposal settings (seeThe SA proposals do not match (SA proposal mismatch) below).
Ensure that you have allowed inbound and outbound traffic for all necessary network services, especially if services such as DNS or DHCP are having problems. l Check that a static route has been configured properly to allow routing of VPN traffic.

If you are still unable to connect to the VPN tunnel, run the following diagnostic command in the CLI:

diagnose debug application ike -1 diagnose debug enable

The resulting output may indicate where the problem is occurring. When you are finished, disable the diagnostics by using the following command:

diagnose debug reset diagnose debug disable

View the table below for some assistance in analyzing the debug output.

Debug output table

Problem	Debug output	Common causes	Common solutions
Tunnel is not coming up	Error: negotiation failure	IPsec configuration mismatch	Check phase 1 and 2 settings
	Error: no SA proposal chosen	IPsec configuration mismatch	Check phase 1 and 2 settings
	FortiGate using the wrong VPN	Missing or wrong local ID	If there are more than one preshared key dial-up VPN with the same local gateway, use aggressive mode and different local IDs
	Error: connection expiring due to XAUTH failure	Wrong username, password, or user group	Check user credentials and user group configuration
	Error: peer has not completed XAUTH exchange	XAuth is disabled in the client	Fix the client’s XAuth configuration
Tunnel is bouncing	DPD packets lost	ISP issue	Check the ISP connection

Common IPsec VPN problems

Problem	Debug output	Common causes	Common solutions
Tunnel is up but traffic does not go through	Error: No matching IPsec selector, drop	Quick mode selector mismatch	Fix the quick mode selector
	Error: No matching IPsec selector, drop	NAT is enabled	Disable NAT in the firewall policy
	Traffic is not routed to the tunnel	Route or firewall policy misconfiguration	Route-based: traffic must be routed to IPsec virtual interface Policy-based: traffic must match a firewall policy with action set to IPSEC

The options to configure policy-based IPsec VPN are unavailable

Go to System > Feature Visibility. Select Show More and turn on Policy-based IPsec VPN.

The VPN tunnel goes down frequently

If your VPN tunnel goes down often, check the Phase 2 settings and either increase the Keylife value or enable Autokey Keep Alive.

The pre-shared key does not match (PSK mismatch error)

It is possible to identify a PSK mismatch using the following combination of CLI commands:

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

This will provide you with clues as to any PSK or other proposal issues. If it is a PSK mismatch, you should see something similar to the following output:

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

The SA proposals do not match (SA proposal mismatch)

The most common problem with IPsec VPN tunnels is a mismatch between the proposals offered between each party. Without a match and proposal agreement, Phase 1 can never establish. Use the following command to show the proposals presented by both parties. diag debug app ike -1 diag debug enable

The resulting output should include something similar to the following, where blue represents the remote VPN device, and green represents the local FortiGate.

responder received SA_INIT msg incoming proposal:

proposal id = 1:

protocol = IKEv2: encapsulation = IKEv2/none type=ENCR, val=AES_CBC (key_len = 256)

Common IPsec VPN problems

type=INTEGR, val=AUTH_HMAC_SHA_96 type=PRF, val=PRF_HMAC_SHA type=DH_GROUP, val=1536.

proposal id = 2:

protocol = IKEv2: encapsulation = IKEv2/none type=ENCR, val=3DES_CBC

type=INTEGR, val=AUTH_HMAC_SHA_2_256_128 type=PRF, val=PRF_HMAC_SHA2_256 type=DH_GROUP, val=1536.

proposal id = 1:

protocol = IKEv2: encapsulation = IKEv2/none type=ENCR, val=AES_CBC (key_len = 128) type=INTEGR, val=AUTH_HMAC_SHA_96 type=PRF, val=PRF_HMAC_SHA type=DH_GROUP, val=1536.

Pre-existing IPsec VPN tunnels need to be cleared

Should you need to clear an IKE gateway, use the following commands:

diagnose vpn ike restart diagnose vpn ike gateway clear

Other potential VPN issues

Ensure that your FortiGate unit is in NAT/Route mode, rather than Transparent.
Check your NAT settings, enabling NAT traversal in the Phase 1 configuration while disabling NAT in the security policy. You might need to pin the PAT/NAT session table, or use some of kind of NAT-T keepalive to avoid the expiration of your PAT/NAT translation.
Ensure that both ends of the VPN tunnel are using Main mode, unless multiple dial-up tunnels are being used.
Remove any Phase 1 or Phase 2 configurations that are not in use. If a duplicate instance of the VPN tunnel appears on the IPsec Monitor, reboot your FortiGate unit to try and clear the entry.
If you have multiple dial-up IPsec VPNs, ensure that the peer ID is configured properly on the FortiGate and that clients have specified the correct local ID. Furthermore, in circumstances where multiple remote dialup VPN tunnels exist, each tunnel must have a peer ID set.
If you are using FortiClient, ensure that your version is compatible with the FortiGate firmware by reading the FortiOS Release Notes. l If you are using Perfect Forward Secrecy (PFS), ensure that it is used on both peers. You can use the diagnose

vpn tunnel list command to troubleshoot this.

Ensure that the Quick Mode selectors are correctly configured. If part of the setup currently uses firewall addresses or address groups, try changing it to either specify the IP addresses or use an expanded address range. This is especially useful if the remote endpoint is not a FortiGate device.
If XAUTH is enabled, ensure that the settings are the same for both ends, and that the FortiGate unit is set to Enable as Server.
Check IPsec VPN Maximum Transmission Unit (MTU) size. A 1500 byte MTU is going to exceed the overhead of the ESP-header, including the additional ip_header,etc. You can use the diagnose vpn tunnel list command to troubleshoot this.

Troubleshooting connection issues

If your FortiGate unit is behind a NAT device, such as a router, configure port forwarding for UDP ports 500 and 4500.

Troubleshooting connection issues

The following section includes troubleshooting suggestions related to:

l LAN interface connection l Dialup connection l Troubleshooting VPN connections l Troubleshooting invalid ESP packets using Wireshark l Attempting hardware offloading beyond SHA1 l Check Phase 1 proposal settings l Check your routing l Try enabling XAuth

LAN interface connection

To confirm whether a VPN connection over LAN interfaces has been configured correctly, issue a ping or traceroute command on the network behind the FortiGate unit to test the connection to a computer on the remote network. If the connection is properly configured, a VPN tunnel will be established automatically when the first data packet destined for the remote network is intercepted by the FortiGate unit.

If the ping or traceroute fail, it indicates a connection problem between the two ends of the tunnel. This may or may not indicate problems with the VPN tunnel. You can confirm this by going to Monitor > IPsec Monitor where you will be able to see your connection. A green arrow means the tunnel is up and currently processing traffic. A red arrow means the tunnel is not processing traffic, and this VPN connection has a problem.

If the connection has problems, see Troubleshooting VPN connections on page 227.

Dialup connection

A dialup VPN connection has additional steps. To confirm that a VPN between a local network and a dialup client has been configured correctly, at the dialup client, issue a ping command to test the connection to the local network. The VPN tunnel initializes when the dialup client attempts to connect.

If the ping or traceroute fail, it indicates a connection problem between the two ends of the tunnel. This may or may not indicate problems with the VPN tunnel, or dialup client. As with the LAN connection, confirm the VPN tunnel is established by checking Monitor > IPsec Monitor.

Troubleshooting VPN connections

If you have determined that your VPN connection is not working properly through Troubleshooting on page 223, the next step is to verify that you have a phase2 connection.

If traffic is not passing through the FortiGate unit as you expect, ensure the traffic does not contain IPcomp packets (IP protocol 108, RFC 3173). FortiGate units do not allow IPcomp packets, they compress packet payload, preventing it from being scanned.

Testing Phase 1 and 2 connections is a bit more difficult than testing the working VPN. This is because they require diagnose CLI commands. These commands are typically used by Fortinet customer support to discover more information about your FortiGate unit and its current configuration.

Before you begin troubleshooting, you must:

Configure FortiGate units on both ends for interface VPN l Record the information in your VPN Phase 1 and Phase 2 configurations – for our example here the remote IP

address is 10.11.101.10 and the names of the phases are Phase 1 and Phase 2

Install a telnet or SSH client such as putty that allows logging of output l Ensure that the admin interface supports your chosen connection protocol so you can connect to your FortiGate unit admin interface.

For this example, default values were used unless stated otherwise.

Obtaining diagnose information for the VPN connection – CLI

Log into the CLI as admin with the output being logged to a file.
Stop any diagnose debug sessions that are currently running with the CLI command diagnose debug disable
Clear any existing log-filters by running

diagnose vpn ike log-filter clear

Set the log-filter to the IP address of the remote computer (10.11.101.10). This filters out all VPN connections except ones to the IP address we are concerned with. The command is diagnose vpn ike log-filter dst-addr4 10.11.101.10.
Set up the commands to output the VPN handshaking. The commands are:

diagnose debug app ike 255 diagnose debug enable

Have the remote FortiGate initiate the VPN connection in the web-based manager by going to VPN > IPsec Tunnels and selecting Bring up.

This makes the remote FortiGate the initiator and the local FortiGate becomes the responder. Establishing the connection in this manner means the local FortiGate will have its configuration information as well as the information the remote computer sends. Having both sets of information locally makes it easier to troubleshoot your VPN connection.

Watch the screen for output, and after roughly 15 seconds enter the following CLI command to stop the output.

diagnose debug disable

If needed, save the log file of this output to a file on your local computer. Saving the output to a file can make it easier to search for a particular phrase, and is useful for comparisons.

Troubleshooting a Phase 1 VPN connection

Using the output from Obtaining diagnose information for the VPN connection – CLI, search for the word proposal in the output. It may occur once indicating a successful connection, or it will occur two or more times for an unsuccessful connection — there will be one proposal listed for each end of the tunnel and each possible Troubleshooting connection issues

combination in their settings. For example if 10.11.101.10 selected both Diffie-Hellman Groups 1 and 5, that would be at least 2 proposals set.

A successful negotiation proposal will look similar to

IPsec SA connect 26 10.12.101.10->10.11.101.10:500 config found created connection: 0x2f55860 26 10.12.101.10->10.11.101.10:500 IPsec SA connect 26 10.12.101.10->10.11.101.10:500 negotiating no suitable ISAKMP SA, queuing quick-mode request and initiating ISAKMP SA negotiation initiator: main mode is sending 1st message…

cookie 3db6afe559e3df0f/0000000000000000 out [encryption]

sent IKE msg (ident-i1send): 10.12.101.10:500->10.11.101.10:500, len=264, id=3db6afe559e3df0f/0000000000000000

diaike 0: comes 10.12.101.1:500->10.11.101.1:500,ifindex=26….

Note the phrase “initiator: main mode is sending 1st message…” which shows you the

handshake between the ends of the tunnel is in progress. Initiator shows the remote unit is sending the first message.

Troubleshooting invalid ESP packets using Wireshark

The following section provides information to help debug an encryption key mismatch. The ESP packet invalid error is due to an encryption key mismatch after a VPN tunnel has been established. When an IPsec VPN tunnel is up, but traffic is not able to pass through the tunnel, Wireshark (or an equivalent program) can be used to determine whether there is an encryption mismatch. A mismatch could occur for many reasons, one of the most common is the instability of an ISP link (ADSL, Cable), or it could effectively be any device in the physical connection.

The following information is required to troubleshoot the problem.

Take a packet sniffer trace on both FortiGates.
Run the diag vpn tunnel list command a few times on both FortiGates when generating traffic that will pass through the tunnel.

In the following example, the error message was seen on the recipient FortiGate:

date=2010-12-28 time=18:19:35 devname=Kosad_VPN device_id=FG300B3910600118 log_ id=0101037132 type=event subtype=ipsec pri=critical vd=”root” msg=”IPsec ESP” action=”error” rem_ ip=180.87.33.2 loc_ip=121.133.8.18 rem_port=32528 loc_port=4500 out_intf=”port2″ cookies=”88d40f65d555ccaf/05464e20e4afc835″user=”N/A” group=”N/A” xauth_user=”N/A” xauth_ group=”N/A” vpn_tunnel=”fortinet_0″ status=esp_error error_num=Invalid ESP packet detected (HMAC validation failed). spi=c32b09f7 seq=00000012

This is the output of the command diag vpn tunnel list on the FortiGate:

inet ver=1 serial=2 192.168.1.205:4500->121.133.8.18:4500 lgwy=dyn tun=intf mode=auto bound_if=4 proxyid_num=1 child_num=0 refcnt=7 ilast=0 olast=0 stat: rxp=41 txp=56 rxb=4920 txb=3360 dpd: mode=active on=1 idle=5000ms retry=3 count=0 seqno=696 natt: mode=keepalive draft=32 interval=10 remote_port=4500 proxyid=P2_60C_Fortinet proto=0 sa=1 ref=2 auto_negotiate=0 serial=1 src:

0:182.40.101.0/255.255.255.0:0 dst: 0:100.100.100.0/255.255.255.0:0 connection issues

SA: ref=3 options=0000000d type=00 soft=0 mtu=1428 expire=1106 replaywin=0 seqno=15 life: type=01 bytes=0/0 timeout=1777/1800

dec: spi=29a26eb6 esp=3des key=24 bf25e69df90257f64c55dda4069f01834cd0382fe4866ff2 ah=sha1 key=20 38b2600170585d2dfa646caed5bc86d920aed7ff

enc: spi=c32b09f7 esp=3des key=24 0abd3c70032123c3369a6f225a385d30f0b2fb1cd9687ec8 ah=sha1 key=20 214d8e717306dffceec3760464b6e8edb436c6 This is the packet capture from the FortiGate:

How to verify if the original packet has been encrypted correctly

To verify, it is necessary to decrypt the ESP packet using Wireshark. Open the packet capture that is taken from initiator FortiGate using Wireshark. Go to Edit > Preferences, expand Protocol and look for ESP. Select “Attempt to detect/decode encrypted ESP payloads“, and fill in the information for the encryption algorithm and the keys. This information can be obtained from the output of the command diag vpn tunnel list.

If the packet was encrypted correctly using the correct key, then the decryption will be successful and it will be possible to see the original package as shown below:

Repeat the decryption process for the packet capture from the recipient firewall. If the decryption failed using the same key, the packet may be corrupted and the interface should then be checked for CRC or packet errors.

Attempting hardware offloading beyond SHA1

If you are trying to off-load VPN processing to a network processing unit (NPU), remember that only SHA1 authentication is supported. For high levels of authentication such as SHA256, SHA384, and SHA512 hardware offloading is not an option—all VPN processing must be done in software—unless using an NP6 (although the NP4lite variation also supports SHA256, SHA384, and SHA512).

Enable/disable IPsec ASIC-offloading

Much like NPU-offload in IKE phase1 configuration, you can enable or disable the usage of ASIC hardware for IPsec Diffie-Hellman key exchange and IPsec ESP traffic. By default hardware offloading is used. For debugging purposes, sometimes it is best for all the traffic to be processed by software.

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

Check Phase 1 proposal settings

Ensure that both sides have at least one Phase 1 proposal in common. Otherwise they will not connect. If there are many proposals in the list, this will slow down the negotiating of Phase 1. If its too slow, the connection may timeout before completing. If this happens, try removing some of the unused proposals.

NPU offloading is supported when the local gateway is a loopback interface.

Check your routing

If routing is not properly configured with an entry for the remote end of the VPN tunnel, traffic will not flow properly. You may need static routes on both ends of the tunnel. If routing is the problem, the proposal will likely setup properly but no traffic will flow.

Try enabling XAuth

If one end of an attempted VPN tunnel is using XAuth and the other end is not, the connection attempt will fail. The log messages for the attempted connection will not mention XAuth is the reason, but when connections are failing it is a good idea to ensure both ends have the same XAuth settings. If you do not know the other end’s settings enable or disable XAuth on your end to see if that is the problem.

General troubleshooting tips

Most connection failures are due to a configuration mismatch between the FortiGate unit and the remote peer. In general, begin troubleshooting an IPsec VPN connection failure as follows:

Ping the remote network or client to verify whether the connection is up. See General troubleshooting tips on page 231.
Traceroute the remote network or client. If DNS is working, you can use domain names. Otherwise use IP addresses.
Check the routing behind the dialup client. Routing problems may be affecting DHCP. If this appears to be the case, configure a DHCP relay service to enable DHCP requests to be relayed to a DHCP server on or behind the FortiGate server.
Verify the configuration of the FortiGate unit and the remote peer. Check the following IPsec parameters: l The mode setting for ID protection (main or aggressive) on both VPN peers must be identical.
- The authentication method (preshared keys or certificates) used by the client must be supported on the FortiGate unit and configured properly.
- If preshared keys are being used for authentication purposes, both VPN peers must have identical preshared keys.
- The remote client must have at least one set of Phase 1 encryption, authentication, and Diffie-Hellman settings that match corresponding settings on the FortiGate unit.
- Both VPN peers must have the same NAT traversal setting (enabled or disabled).
- The remote client must have at least one set of Phase 2 encryption and authentication algorithm settings that match the corresponding settings on the FortiGate unit.
- If you are using manual keys to establish a tunnel, the Remote SPI setting on the FortiGate unit must be identical to the Local SPI setting on the remote peer, and vise versa.

To correct the problem, see the following table.

VPN troubleshooting tips

Configuration problem	Correction
Mode settings do not match.	Select complementary mode settings. See Phase 1 parameters on page 46.
Peer ID or certificate name of the remote peer or dialup client is not recognized by FortiGate VPN server.	Check Phase 1 configuration. Depending on the Remote Gateway and Authentication Method settings, you have a choice of options to authenticate FortiGate dialup clients or VPN peers by ID or certificate name (see Phase 1 parameters on page 46). If you are configuring authentication parameters for FortiClient dialup clients, refer to the Authenticating FortiClient Dialup Clients Technical Note.
Preshared keys do not match.	Reenter the preshared key. See Phase 1 parameters on page 46.
Phase 1 or Phase 2 key exchange proposals are mismatched.	Make sure that both VPN peers have at least one set of proposals in common for each phase. See Phase 1 parameters on page 46 and Phase 2 parameters on page 66.
NAT traversal settings are mismatched.	Select or clear both options as required. See Phase 1 parameters on page 46 and Phase 1 parameters on page 46.

A word about NAT devices

When a device with NAT capabilities is located between two VPN peers or a VPN peer and a dialup client, that device must be NAT traversal (NAT-T) compatible for encrypted traffic to pass through the NAT device. For more information, see Phase 1 parameters on page 46.

Troubleshooting L2TP and IPsec

This section describes some checks and tools you can use to resolve issues with L2TP-over-IPsec VPNs.

This section includes:

Quick checks l Mac OS X and L2TP
Setting up logging
Using the FortiGate unit debug commands

Quick checks

The table below is a list of common L2TP over IPsec VPN problems and the possible solutions.

L2TP and

Problem

What to check

IPsec tunnel does not come up.

Check the logs to determine whether the failure is in Phase 1 or Phase 2.

Check the settings, including encapsulation setting, which must be transport-mode.

Check the user password.

Confirm that the user is a member of the user group assigned to L2TP.

On the Windows PC, check that the IPsec service is running and has not been disabled. See Troubleshooting L2TP and IPsec on page 232.

Tunnel connects, but there is no communication.

Did you create an ACCEPT security policy from the public network to the protected network for the L2TP clients? See Troubleshooting L2TP and IPsec on page 232.

Mac OS X and L2TP

FortiOS allows L2TP connections with empty AVP host names and therefore Mac OS X L2TP connections can connect to the FortiGate.

Prior to FortiOS 4.0 MR3, FortiOS refused L2TP connections with empty AVP host names in compliance with RFC 2661 and RFC 3931.

Setting up logging

L2TP logging must be enabled to record L2TP events. Alert email can be configured to report L2TP errors.

Configuring FortiGate logging for L2TP over IPsec

Go to Log & Report > Log Settings.
Select Event Log.
Select the VPN activity event check box.
Select Apply.

Viewing FortiGate logs

Go to Log & Report > VPN Events.
Select the Log location if required.
After each attempt to start the L2TP over IPsec VPN, select Refresh to view logged events.

Using the FortiGate unit debug commands

Viewing debug output for IKE and L2TP

Start an SSH or Telnet session to your FortiGate unit.
Enter the following CLI commands

L2TP and diagnose debug application ike -1 diagnose debug application l2tp -1 diagnose debug enable

Attempt to use the VPN and note the debug output in the SSH or Telnet session.
Enter the following command to reset debug settings to default:

diagnose debug reset

Using the packet sniffer

Start an SSH or Telnet session to your FortiGate unit.
Enter the following CLI command diagnose sniffer packet any icmp 4
Attempt to use the VPN and note the debug output.
Enter Ctrl-C to end sniffer operation.

Typical L2TP over IPsec session startup log entries – raw format

2010-01-11 16:39:58 log_id=0101037127 type=event subtype=ipsec pri=notice vd=”root” msg=”progress IPsec Phase 1″ action=”negotiate” rem_ip=172.20.120.151 loc_ip=172.20.120.141 rem_port=500 loc_port=500 out_ intf=”port1″ cookies=”5f6da1c0e4bbf680/d6a1009eb1dde780″ user=”N/A” group=”N/A” xauth_user=”N/A” xauth_ group=”N/A” vpn_tunnel=”dialup_p1″ status=success init=remote mode=main dir=outbound stage=1 role=responder result=OK

2010-01-11 16:39:58 log_id=0101037127 type=event subtype=ipsec pri=notice vd=”root” msg=”progress IPsec Phase 1″ action=”negotiate” rem_ip=172.20.120.151 loc_ip=172.20.120.141 rem_port=500 loc_port=500 out_ intf=”port1″ cookies=”5f6da1c0e4bbf680/d6a1009eb1dde780″ user=”N/A” group=”N/A” xauth_user=”N/A” xauth_ group=”N/A” vpn_tunnel=”dialup_p1_0″ status=success init=remote mode=main dir=outbound stage=3 role=responder result=DONE

2010-01-11 16:39:58 log_id=0101037129 type=event subtype=ipsec pri=notice vd=”root” msg=”progress IPsec Phase 2″ action=”negotiate” rem_ip=172.20.120.151 loc_ip=172.20.120.141 rem_port=500 loc_port=500 out_ intf=”port1″ cookies=”5f6da1c0e4bbf680/d6a1009eb1dde780″ user=”N/A” group=”N/A” xauth_user=”N/A” xauth_ group=”N/A” vpn_tunnel=”dialup_p1_0″ status=success init=remote mode=quick dir=outbound stage=1 role=responder result=OK

2010-01-11 16:39:58 log_id=0101037133 type=event subtype=ipsec pri=notice vd=”root” msg=”install IPsec SA” action=”install_sa” rem_ip=172.20.120.151 loc_ip=172.20.120.141 rem_port=500 loc_port=500 out_ intf=”port1″ cookies=”5f6da1c0e4bbf680/d6a1009eb1dde780″ user=”N/A” group=”N/A” xauth_user=”N/A” xauth_ group=”N/A” vpn_tunnel=”dialup_p1_0″ role=responder in_spi=61100fe2 out_spi=bd70fca1

2010-01-11 16:39:58 log_id=0101037139 type=event subtype=ipsec pri=notice vd=”root” msg=”IPsec Phase 2 status change” action=”phase2-up” rem_ip=172.20.120.151 loc_ip=172.20.120.141 rem_port=500 loc_port=500 out_intf=”port1″ cookies=”5f6da1c0e4bbf680/d6a1009eb1dde780″ user=”N/A” group=”N/A” xauth_user=”N/A” xauth_group=”N/A” vpn_tunnel=”dialup_p1_0″ phase2_name=dialup_p2

2010-01-11 16:39:58 log_id=0101037138 type=event subtype=ipsec pri=notice vd=”root” msg=”IPsec connection status change” action=”tunnel-up” rem_ip=172.20.120.151 loc_ip=172.20.120.141 rem_port=500 loc_port=500 out_intf=”port1″ cookies=”5f6da1c0e4bbf680/d6a1009eb1dde780″ user=”N/A” group=”N/A” xauth_ user=”N/A” xauth_group=”N/A” vpn_tunnel=”dialup_p1_0″ tunnel_ip=172.20.120.151 tunnel_id=1552003005 tunnel_type=ipsec duration=0 sent=0 rcvd=0 next_stat=0 tunnel=dialup_p1_0

GRE over

2010-01-11 16:39:58 log_id=0101037122 type=event subtype=ipsec pri=notice vd=”root” msg=”negotiate IPsec Phase 2″ action=”negotiate” rem_ip=172.20.120.151 loc_ip=172.20.120.141 rem_port=500 loc_port=500 out_ intf=”port1″ cookies=”5f6da1c0e4bbf680/d6a1009eb1dde780″ user=”N/A” group=”N/A” xauth_user=”N/A” xauth_ group=”N/A” vpn_tunnel=”dialup_p1_0″ status=success role=responder esp_transform=ESP_3DES esp_auth=HMAC_ SHA1

2010-01-11 16:39:58 log_id=0103031008 type=event subtype=ppp vd=root pri=information action=connect status=success msg=”Client 172.20.120.151 control connection started (id 805), assigned ip 192.168.0.50″

2010-01-11 16:39:58 log_id=0103029013 type=event subtype=ppp vd=root pri=notice pppd is started

2010-01-11 16:39:58 log_id=0103029002 type=event subtype=ppp vd=root pri=notice user=”user1″ local=172.20.120.141 remote=172.20.120.151 assigned=192.168.0.50 action=auth_success msg=”User ‘user1’ using l2tp with authentication protocol MSCHAP_V2, succeeded”

2010-01-11 16:39:58 log_id=0103031101 type=event subtype=ppp vd=root pri=information action=tunnel-up tunnel_id=1645784497 tunnel_type=l2tp remote_ip=172.20.120.151 tunnel_ip=192.168.0.50 user=”user1″ group=”L2TPusers” msg=”L2TP tunnel established”

Troubleshooting GRE over IPsec

This section describes some checks and tools you can use to resolve issues with the GRE-over-IPsec VPN.

Quick checks

Here is a list of common problems and what to verify.

Problem	What to check
No communication with remote network.	Use the execute ping command to ping the Cisco device public interface. Use the FortiGate VPN Monitor page to see whether the IPsec tunnel is up or can be brought up.
IPsec tunnel does not come up.	Check the logs to determine whether the failure is in Phase 1 or Phase 2. Check that the encryption and authentication settings match those on the Cisco device. Check the encapsulation setting: tunnel-mode or transport-mode. Both devices must use the same mode.
Tunnel connects, but there is no communication.	Check the security policies. See Troubleshooting GRE over IPsec on page 235. Check routing. See Troubleshooting GRE over IPsec on page 235.

Setting up logging

Configuring FortiGate logging for IPsec

Go to Log & Report > Log Settings.
Select the Event Logging.
Select VPN activity event.
Select Apply.

Viewing FortiGate logs

Go to Log & Report > VPN Events.
Select the log storage type.
Select Refresh to view any logged events.

GRE tunnel keepalives

In the event that each GRE tunnel endpoint has keepalive enabled, firewall policies allowing GRE are required in both directions. The policy should be configured as follows (where the IP addresses and interface names are for example purposes only):

config firewall policy edit < id >

set srcintf “gre” set dstintf “port1” set srcaddr “1.1.1.1” set dstaddr “2.2.2.2” set action accept set schedule “always” set service “GRE”

end

Cisco compatible keep-alive support for GRE

The FortiGate can send a GRE keepalive response to a Cisco device to detect a GRE tunnel. If it fails, it will remove any routes over the GRE interface.

Configuring keepalive query – CLI:

config system gre-tunnel edit <id> set keepalive-interval <value: 0-32767> set keepalive-failtimes <value: 1-255>

end

GRE tunnel with multicast traffic

If you want multicast traffic to traverse the GRE tunnel, you need to configure a multicast policy as well as enable multicast forwarding.

GRE over

To configure a multicast policy, use the config firewall multicast-policy
To enable multicast forwarding, use the following commands:

config system settings set multicast-forward enable

end

Using diagnostic commands

There are some diagnostic commands that can provide useful information. When using diagnostic commands, it is best practice that you connect to the CLI using a terminal program, such as puTTY, that allows you to save output to a file. This will allow you to review the data later on at your own speed without worry about missed data as the diag output scrolls by.

Using the packet sniffer – CLI:

Enter the following CLI command:

diag sniff packet any icmp 4

Ping an address on the network behind the FortiGate unit from the network behind the Cisco router.

The output will show packets coming in from the GRE interface going out of the interface that connects to the protected network (LAN) and vice versa. For example:

114.124303 gre1 in 10.0.1.2 -> 10.11.101.10: icmp: echo request

114.124367 port2 out 10.0.1.2 -> 10.11.101.10: icmp: echo request

114.124466 port2 in 10.11.101.10 -> 10.0.1.2: icmp: echo reply

114.124476 gre1 out 10.11.101.10 -> 10.0.1.2: icmp: echo reply

Enter CTRL-C to stop the sniffer.

Viewing debug output for IKE – CLI:

Enter the following CLI commands diagnose debug application ike -1 diagnose debug enable
Attempt to use the VPN or set up the VPN tunnel and note the debug output.
Enter CTRL-C to stop the debug output.
Enter the following command to reset debug settings to default:

diagnose debug reset