Information Element (IE) removal policy options

In some roaming scenarios, the unit is installed on the border of the PLMN and the GRX. In this configuration, the unit supports information element (IE) removal policies to remove any combination of R6 IEs (RAT, RAI, ULI, IMEI-SV and APN restrictions) from the types of messages described in “Advanced filtering options”, prior to forwarding the messages to the HGGSN (proxy mode).

Encapsulated IP traffic filtering options

You can use encapsulated IP traffic filtering to filter GTP sessions based on information contained in the data stream. to control data flows within your infrastructure. You can configure IP filtering rules to filter encapsulated IP traffic from mobile stations by identifying the source and destination policies. For more information, see When to use encapsulated IP traffic filtering.

Expand Encapsulated IP Traffic Filtering in the GTP profile to reveal the options.

Encapsulated non-IP end user traffic filtering options

Depending on the installed environment, it may be beneficial to detect GTP packets that encapsulate non-IP based protocols. You can configure the FortiOS Carrier firewall to permit a list of acceptable protocols, with all other protocols denied.

The encoded protocol is determined in the PDP Type Organization and PDP Type Number fields within the End User Address Information Element. The PDP Type Organization is a 4-bit field that determines if the protocol is part of the ETSI or IETF organizations. Values are zero and one, respectively. The PDP Type field is one byte long. Both GTP specifications list only PPP, with a PDP Type value of one, as a valid ETSI protocol. PDP Types for the IETF values are determined in the “Assigned PPP DLL Protocol Numbers” sections of RFC1700. The PDP types are compressed, meaning that the most significant byte is skipped, limiting the protocols listed from 0x00 to 0xFF.

Protocol Anomaly prevention options

Use protocol anomaly detection options to detect or deny protocol anomalies according to GTP standards and tunnel state. Protocol anomaly attacks involve malformed or corrupt packets that typically fall outside of the protocol specifications. Packets cannot pass through if they fail the sanity check.

Anti-Overbilling options

You can configure the FortiOS Carrier firewall to prevent over billing subscribers for traffic over the. To enable anti-overbilling, you must configure both the Gn/Gp firewall and the Gi firewall.

Expand Anti-Overbilling in the GTP profile to reveal these settings.

Log options

All the GTP logs are treated as a subtype of the event logs. To enable GTP logging, you must:

l configure the GTP log settings in a GTP profile

Specifying logging types

You can configure the unit to log GTP packets based on their status with GTP traffic logging.

The status of a GTP packet can be any of the following 5 states:

• Forwarded – a packet that the unit transmits because the GTP policy allows it l Prohibited – a packet that the unit drops because the GTP policy denies it l Rate-limited – a packet that the unit drops because it exceeds the maximum rate limit of the destination GSN l State-invalid – a packet that the unit drops because it failed stateful inspection l Tunnel-limited – a packet that the unit drops because the maximum limit of GTP tunnels for the destination GSN is reached.

The following information is contained in each log entry:

• Timestamp l Source IP address l Destination IP address l Tunnel Identifier (TID) or Tunnel Endpoint Identifier (TEID) l Message type
• Packet status: forwarded, prohibited, state-invalid, rate-limited, or tunnel-limited l Virtual domain ID or name l Reason to be denied if applicable.

Configuring GTP on FortiOS Carrier

Configuring GTP support on FortiOS Carrier involves configuring a number of areas of features.

GTP support on the Carrier-enabled FortiGate unit

The FortiCarrier unit needs to have access to all traffic entering and exiting the carrier network for scanning, filtering, and logging purposes. This promotes one of two configurations — hub and spoke, or bookend.

A hub and spoke configuration with the Carrier-enabled FortiGate unit at the hub and the other GPRS devices on the spokes is possible for smaller networks where a lower bandwidth allows you to divide one unit into multiple virtual domains to fill multiple roles on the carrier network. It can be difficult with a single FortiOS Carrier as the hub to ensure all possible entry points to the carrier network are properly protected from potential attacks such as relayed network attacks.

A bookend configuration uses two Carrier-enabled FortiGate units to protect the carrier network between them with high bandwidth traffic. One unit handles traffic from mobile stations, SGSNs, and foreign carriers. The other handles GGSN and data network traffic. Together they ensure the network is secure.

The Carrier-enabled FortiGate unit can access all traffic on the network. It can also verify traffic between devices, and verify that the proper GPRS interface is being used. For example there is no reason for a Gn interface to be used to communicate with a mobile station — the mobile station will not know what to do with the data — so that traffic is blocked.

When you are configuring your Carrier-enabled FortiGate unit’s GTP profile, you must first configure the APN. It is critical to GTP communications — no traffic will flow without the APN.

The Carrier-enabled FortiGate unit does more than just forward and route GTP packets over the network. It also performs:

l GTP support on the Carrier-enabled FortiGate unit l GTP support on the Carrier-enabled FortiGate unit l GTP support on the Carrier-enabled FortiGate unit l GTP support on the Carrier-enabled FortiGate unit l GTP support on the Carrier-enabled FortiGate unit

Packet sanity checking

The FortiOS Carrier firewall checks the following items to determine if a packet confirms to the UDP and GTP standards:

l GTP release version number — must be 0, 1, or 2 l Settings of predefined bits l Protocol type l UDP packet length

If the packet in question does not confirm to the standards, the FortiOS Carrier firewall drops the packet, so that the malformed or forged traffic will not be processed.

GTP stateful inspection

Apart from the static inspection (checking the packet header), the FortiOS Carrier firewall performs stateful inspection.

Stateful inspection provides enhanced security by keeping track of communications sessions and packets over a period of time. Both incoming and outgoing packets are examined. Outgoing packets that request specific types of incoming packets are tracked; only those incoming packets constituting a proper response are allowed through the firewall.

The FortiOS Carrier firewall can also index the GTP tunnels to keep track of them.

Using the enhanced Carrier traffic policy, the FortiOS Carrier firewall can block unwanted encapsulated traffic in GTP tunnels, such as infrastructure attacks. Infrastructure attacks involve attempts by an attacker to connect to restricted machines, such as GSN devices, network management systems, or mobile stations. If these attempts to connect are detected, they are to be flagged immediately by the firewall .

Protocol anomaly detection and prevention

The FortiOS Carrier firewall detects and optionally drops protocol anomalies according to GTP standards and specific tunnel states. Protocol anomaly attacks involve malformed or corrupt packets that typically fall outside of protocol specifications. These packets are not seen on a production network. Protocol anomaly attacks exploit poor programming practices when decoding packets, and are typically used to maliciously impair system performance or elevate privileges.

FortiOS Carrier also detects IP address spoofing inside GTP data channel.

See Protocol anomaly detection and prevention.

HA

FortiOS Carrier active-passive HA provides failover protection for the GTP tunnels. This means that an activepassive cluster can provide FortiOS Carrier firewall services even when one of the cluster units encounters a problem that would result in complete loss of connectivity for a stand-alone FortiOS Carrier firewall. This failover protection provides a backup mechanism that can be used to reduce the risk of unexpected downtime, especially for mission-critical environments.

FortiOS HA synchs TCP sessions by default, but UDP sessions are not synchronized by default. However synchronizing a session is only part of the solution if the goal is to continue GTP processing on a synchronized session after a HA switch. For that to be successful we also need to synch the GTP tunnel state. So, once the master completes tunnel setup then the GTP tunnel is synchronized to the slave.

GTP traffic will only flow without interruption on a HA switch if bidirectional GTP policies have been configured: an internal (GTP server) to external (all) UDP port GTP policy, and an external (all) to internal (GTP server) UDP port GTP policy. If either policy is missing then traffic may be interrupted until traffic flows in the opposite direction.

For more information on HA in FortiOS, see the High Availability (HA) Guide or the FortiOS Administration Guide.

Virtual domain support

FortiOS Carrier is suited to both large and smaller carriers. A single Carrier-enabled FortiGate unit can serve either one large carrier, or several smaller ones through virtual domains. As with any FortiGate unit, Carrierenabled units have the ability to split their resources into multiple virtual units. This allows smaller carriers to use just the resources that they need without wasting the extra. For more information on HA in FortiOS, see the Virtual Domains (VDOMs) Guide.

Configuring General Settings on the Carrier-enabled FortiGate unit

To configure the GTP General Settings, go to Security Profiles > GTP Profile, and edit a GTP profile. Expand General Settings to configure settings. See General settings options.

GTP Monitor Mode

The monitor-mode setting is part of the GTP profile. The setting shows on all GTP profiles and works for all GTP versions.

When this setting is enabled, if a GTP packet is to be dropped due to a GTP deny case such as: l GTP_DENY l GTP_RATE_LIMIT l GTP_STATE_INVALID l GTP_TUNNEL_LIMIT

instead of being dropped, it will be forwarded and logged with the original deny log message and a “-monitor” suffix (e.g., state-invalid-monitor).

This setting is found in the CLI.

config firewall gtp edit profile_name …

set monitor-mode [disable*|enable] …

end

end

Configuring Encapsulated Filtering in FortiOS Carrier

Encapsulated traffic on the GPRS network can come in a number of forms as it includes traffic that is “wrapped up” in another protocol. This detail is important for firewalls because it requires “unwrapping” to properly scan the data inside. If encapsulated packets are treated as regular packets, that inside layer will never be scanned and may allow malicious data into your network.

On Carrier-enabled FortiGate units, GTP related encapsulated filtering falls under encapsulated IP traffic filtering, and encapsulated non-IP end user address filtering.

Configuring Encapsulated IP Traffic Filtering

Generally there are a very limited number of IP addresses that are allowed to encapsulate GPRS traffic. For example GTP tunnels are a valid type of encapsulation when used properly. This is the GTP tunnel which uses the Gp or Gn interfaces between SGSNs and GGSNs. However, a GTP tunnel within a GTP tunnel is not accessible — FortiOS Carrier will either block or forward the traffic, but is not able to open it for inspection.

The ability to filter GTP sessions is based on information contained in the data stream and provides operators with a powerful mechanism to control data flows within their infrastructure. You can also configure IP filtering rules to filter encapsulated IP traffic from Mobile Stations.

To configure the Encapsulated IP Traffic Filtering, go to Security Profiles > GTP Profile, and edit a GTP profile. Expand Encapsulated IP Traffic Filtering to configure settings. See Encapsulated IP traffic filtering options.

When to use encapsulated IP traffic filtering

The following are the typical cases that need encapsulated IP traffic filtering:

Mobile station IP pools

In a well-designed network, best practices dictate that the mobile station address pool is to be completely separate from the GPRS network infrastructure range of addresses. Encapsulated IP packets originating from a mobile station will not contain source or destination addresses that fall within the address range of GPRS infrastructures. In addition, traffic originating from the users handset will not have destination/source IP addresses that fall within any Network Management System (NMS) or Charging Gateway (CG) networks.

Communication between mobile stations

Mobile stations on the same GPRS network are not able to communicate with other mobile stations. Best practices dictate that packets containing both source and destination addresses within the mobile station’s range of addresses are to be dropped.

Direct mobile device or internet attacks

It may be possible for attackers to wrap attack traffic in GTP protocols and submit the resulting GTP traffic directly to a GPRS network element from their mobile stations or a node on the Internet. It is possible that the receiving SGSN or GGSN would then strip off the GTP header and attempt to route the underlying attack. This underlying attack could have any destination address and would probably have a source address spoofed as if it were valid from that PLMN.

Relayed network attacks

Depending on the destination the attack could be directly routed, such as to another node of the PLMN, or re wrapped in GTP for transmission to any destination on the Internet outside the PLMN depending on the routing table of the GSN enlisted as the unwitting relay.

The relayed attack could have any source or destination addresses and could be any of numerous IP network attacks, such as an attack to hijack a PDP context, or a direct attack against a management interface of a GSN or other device within the PLMN. Best practices dictate that any IP traffic originating on the Internet or from an MS with a destination address within the PLMN is to be filtered.

Configuring Encapsulated Non-IP End User Address Filtering

Much of the traffic on the GPRS network is in the form of IP traffic. However some parts of the network do not used IP based addressing, so the Carrier-enabled FortiGate unit is unable to perform Encapsulated IP Traffic

Filtering.

Depending on the installed environment, it may be beneficial to detect GTP packets that encapsulate non-IP based protocols. You can configure the FortiOS Carrier firewall to permit a list of acceptable protocols, with all other protocols denied.

The encoded protocol is determined in the PDP Type Organization and PDP Type Number fields within the End User Address Information Element. The PDP Type Organization is a 4-bit field that determines if the protocol is part of the ETSI or IETF organizations. Values are zero and one, respectively. The PDP Type field is one byte long. Both GTP specifications only list PPP, with a PDP Type value of one, as a valid ETSI protocol. PDP Types for the IETF values are determined in the “Assigned PPP DLL Protocol Numbers” sections of RFC 1700. The PDP types are compressed, meaning that the most significant byte is skipped, limiting the protocols listed from 0x00 to 0xFF.

To configure the Encapsulated Non-IP End User Address Filtering, go to Security Profiles > GTP Profile, and edit a GTP profile. Expand Encapsulated Non-IP End User Address Filtering to configure settings. See Encapsulated non-IP end user traffic filtering options.

Configuring the Protocol Anomaly feature in FortiOS Carrier

When anomalies do happen, it is possible for the anomaly to interrupt network traffic or consume network resources — if precautions are not taken. Anomalies can be generated by accident or maliciously, but both methods can have the same results — degrading the performance of the carrier network, or worse.

To configure GTP protocol anomalies, go to Security Profiles > GTP Profile, and edit a GTP profile. Expand the Protocol Anomaly option. See Protocol Anomaly prevention options.

The following are some examples:

• The GTP header specifies the length of the packet excluding the mandatory GTP header. In GTP version 0 (GSM

09.60), the mandatory GTP header size is 20 bytes, whereas GTP version 1 (GSM 29.060) specifies that the

minimum length of the GTP header is 8 bytes. The GTP packet is composed of the header, followed by Information Elements typically presented in a Type-Length-Value format. It is possible for an attacker to create a GTP packet with a GTP header field length that is incompatible with the length of the necessary information elements.

• The same concepts are true for GTP version 2 headers even though there are different fields in them.
• It is similarly possible for an attacker to create a packet with an invalid IE length. Invalid lengths may cause protocol stacks to allocate incorrect amounts of memory, and thereby cause crashes or buffer overflows.

By default the FortiOS Carrier firewall detects these problems, as well as other protocol anomalies, and drops the packets. All protocol anomaly options are set to Deny by default. However, you can change the policy to allow them.

Configuring Anti-overbilling in FortiOS Carrier

GPRS over billing attacks can be prevented with a properly configured Carrier-enabled FortiGate unit.

Over billing can occur when a subscriber returns his IP address to the IP pool. Before the billing server closes it, the subscriber’s session is still open and vulnerable. If an attacker takes control of the subscriber’s IP address, he can send or receive data and the subscriber will be billed for the traffic.

Over billing can also occur when an available IP address is reassigned to a new mobile station (MS). Subsequent traffic by the previous MS may be forwarded to the new MS. The new MS would then be billed for traffic it did not initiate.

Anti-overbilling with FortiOS Carrier

The Carrier-enabled FortiGate unit can be configured to assist with anti-overbilling measures. These measures ensure that the customer is only billed for connection time and data transfer that they actually use.

Anti-overbilling on the Carrier-enabled FortiGate unit involves:

• the administrator configuring the over billing settings in the GTP profile to notify the Gi firewall when a GTP tunnel is deleted
• the unit clearing the sessions when the Gi firewall receives a notification from the Gn/Gp firewall about a GTP tunnel being deleted This way, the Gi firewall prevents over billing by blocking traffic initiated by other users.

The three locations to configure anti-overbilling options include:

• Network > Interface — Edit a specific interface. Towards the bottom of the Edit Interface page, in the Status section, you can toggle Gi Gatekeeper.
• System > Settings — In the Gi Gatekeeper Settings section, set the Context ID and Port that anti-overbilling will take place on.
• Security Profiles > GTP Profile — Edit a specific GTP Profile. In the Anti-Overbilling section, edit the Gi Firewall IP address, Port, Interface and Security Context ID, to use for anti-overbilling measures.

For detailed options, see Anti-Overbilling options.

Logging events on the Carrier-enabled FortiGate unit

Logging on the Carrier-enabled FortiGate unit is just like logging on any other FortiOS unit. The only difference with FortiOS Carrier is that there are a few additional events that you can log beyond the regular ones. These additional events are covered here.

To change FortiOS Carrier specific logging event settings, go to Security Profiles > GTP Profile and edit a GTP profile. Expand the Log section to change the settings. For detailed options, see Log options.

The following information is contained in each log entry:

An example of the above log message format is for a Tunnel deleted log entry. When a tunnel is deleted, the log entry contains the following information: l Timestamp

l Interface name (if applicable) l SGSN IP address (source IP) l GGSN IP address (destination IP) l Tunnel ID l Tunnel duration time in seconds l Number of messages sent to the SGSN l Number of messages sent to the GGSN

GTP message type filtering

FortiOS Carrier supports message filtering in GTP by the type of message.

This section includes:

Common message types on carrier networks

Carrier networks include many types of messages — some concern the network itself, others are content moving across the network, and still others deal with handshaking, billing, or other administration based issues.

GTP contains two major parts GTP for the control plane (GTP-C) and GTP for user data tunnelling (GTP-U). Outside of those areas there are only unknown message types.

GTP-C messages

GTP-C contains the networking layer messages. These address routing, versioning, and other similar low level issues.

When a subscriber requests a Packet Data Protocol (PDP) context, the SGSN will send a create PDP context request GTP-C message to the GGSN giving details of the subscriber’s request. The GGSN will then respond with a create PDP context response GTP-C message which will either give details of the PDP context actually activated or will indicate a failure and give a reason for that failure. This is a UDP message on port 212.

GTP-C message types include Path Management Messages, Location Management Messages, and Mobility Management Messages.

Path Management Messages

Path management is used by one GSN to detect if another GSN is alive, or if it has restarted after a failure.

The path management procedure checks if a given GSN is alive or has been restarted after a failure. In case of SGSN restart, all MM and PDP contexts are deleted in the SGSN, since the associated data is stored in a volatile memory. In the case of GGSN restart, all PDP contexts are deleted in the GGSN.

Tunnel Management Messages

The tunnel management procedures are used to create, update, and delete GTP tunnels in order to route IP PDUs between an MS and an external PDN via the GSNs.

The PDP context contains the subscriber’s session information when the subscriber has an active session. When a mobile wants to use GPRS, it must first attach and then activate a PDP context. This allocates a PDP context data structure in the SGSN that the subscriber is currently visiting and the GGSN serving the subscriber’s access point.

Tunnel management procedures are defined to create, update, and delete tunnels within the GPRS backbone network. A GTP tunnel is used to deliver packets between an SGSN and a GGSN. A GTP tunnel is identified in each GSN node by a TEID, an IP address, and a UDP port number.

Location Management Messages

The location-management procedure is performed during the network-requested PDP context activation procedure if the GGSN does not have an SS7 MAP interface (i.e., Gc interface). It is used to transfer location messages between the GGSN and a GTP-MAP protocol-converting GSN in the GPRS backbone network.

Location management subprocedures are used between a GGSN that does not support an SS7 MAP interface (i.e., Gc interface) and a GTP-MAP protocol-conversing GSN. This GSN supports both Gn and Gc interfaces and is able to perform a protocol conversing between GTP and MAP.

Mobility Management Messages

The MM procedures are used by a new SGSN in order to retrieve the IMSI and the authentication information or MM and PDP context information in an old SGSN. They are performed during the GPRS attach and the interSGSN routing update procedures.

The MM procedures are used between SGSNs at the GPRS-attach and inter-SGSN routing update procedures. An identity procedure has been defined to retrieve the IMSI and the authentication information in an old SGSN. This procedure may be performed at the GPRS attach. A recovery procedure enables information related to MM and PDP contexts in an old SGSN to be retrieved. This procedure is started by a new SGSN during an inter-SGSN RA update procedure.

GTP-U messages

GTP-U is focused on user related issues including tunneling, and billing. GTP-U message types include MBMS messages, and GTP-U and Charging Management Messages

MBMS messages

Multimedia Broadcast and Multicast Services (MBMS) have recently begun to be offered over GSM and UMTS networks on UTRAN and GERAN radio access technologies. MBMS is mainly used for mobile TV, using up to four GSM timeslots for one MBMS connection. One MBMS packet flow is replicated by GGSN, SGSN and RNCs.

MBMS is split into the MBMS Bearer Service and the MBMS User Service. The MBMS User Service is basically the MBMS Service Layer and offers a Streaming- and a Download Delivery Method. The Streaming Delivery method can be used for continuous transmissions like Mobile TV services. The Download Method is intended for “Download and Play” services.

GTP-U and Charging Management Messages

SGSNs and GGSNs listen for GTP-U messages on UDP port 2152.

GTP‘ (GTP prime) is used for billing messages. It uses the common GTP messages (GTP Version Not Supported, Echo Request and Echo Response) and adds additional messages related to billing procedures.

Unknown Action messages

If the system doesn’t know what type of message it is, it falls into this category. This is an important category of message because malformed messages may appear and need to be handled with security in mind.

Configuring message type filtering in FortiOS Carrier

GPRS Tunnelling Protocol (GTP) is a group of IP-based communications protocols used to carry General Packet

Radio Service (GPRS) traffic within Global System for Mobile Communications (GSM) and Universal Mobile Telecommunications System (UMTS) networks. It allows carriers to transport actual cellular packets over their network via tunneling.

In the CLI, there is a keyword for each type of GTP message for both message filtering, and for message rate limiting.

To configure GTP message type filtering – web-based manager

1. Go to Security Profiles > GTP Profile.
2. Select Create New.
3. Enter a name for this profile such as msg_type_filtering.
4. Select Message Type Filtering to expand it.
5. For each type of message in the list, select Allow or Deny. All messages are set to Allow by default.
6. Optionally select and configure any other GTP features for this profile, such as logging.
7. Select OK to save the profile.
8. Apply the msg_type_filtering profile a security policy configured for GTP tunnel traffic.

To configure GTP message filtering and block Unknown Message Action messages- CLI

config firewall gtp edit msg_type_filtering config message-filter set unknown-message-action deny

next

end

end

Message Type Fields

Each of the following message types can be allowed or denied by your Carrier-enabled FortiGate unit depending on your carrier network and GTP traffic.

Unknown Message Action

Set this message type to deny.

Many attempts to hack into a carrier network will result in this unknown message type and therefore it is denied for security reasons.

Path Management Messages

Tunnel Management Messages

Location Management Messages

Mobility Management Messages

MBMS messages

GTP-U and Charging Management Messages

GTP identity filtering

FortiOS Carrier supports a number of filtering methods based on subscriber identity such as APN filtering, IMSI filtering, and advanced filtering.

This section includes:

IMSI on carrier networks

The International Mobile Subscriber Identity (IMSI) number is central to identifying users on a carrier network. It is a unique number that is assigned to a cell phone or mobile device to identify it on the GMS or UTMS network.

Typical the IMSI number is stored on the SIM card of the mobile device and is sent to the network as required.

An IMSI number is 15 digits long, and includes the Mobile Country Code (MCC), Mobile Network Code (MNC), and Mobile Station Identification Number (MSIN).

IMSI codes

The Home Network Identity (HNI) is made up of the MCC and MNC. The HNI is used to fully identify a user’s home network. This is important because some large countries have more than one country code for a single carrier. For example a customer with a mobile carrier on the East Coast of the United States would have a different MCC than a customer on the West Coast with the same carrier because even through the MNC would be the same the MCC would be different — the United States uses MCCs 310 to 316 due to its size.

If an IMSI number is not from the local carrier’s network, IMSI analysis is performed to resolve the number into a Global Title which is used to access the user’s information remotely on their home carrier’s network for things like billing and international roaming.

Other identity and location based information elements

IMSI focuses on the user, their location, and carrier network. There are other numbers used to identify different user related Information Elements (IE).

These identity and location based elements include:

• Access Point Number (APN) l Mobile Subscriber Integrated Services Digital Network (MSISDN) l Radio Access Technology (RAT) type l User Location Information (ULI)
• Routing Area Identifier (RAI)
• International Mobile Equipment Identity (IMEI)

Access Point Number (APN)

The Access Point Number (APN) is used in GPRS networks to identify an IP packet data network that a user wants to communicate with. The Network Identifier describes the network and optionally the service on that network that the GGSN is connected to. The APN also includes the MCC and MCN, which together locate the network the GGSN belongs to. An example of an APN in the Barbados using Digicel as the carrier that is connecting to the Internet is internet.mcc342.mnc750.gprs.

When you are configuring your Carrier-enabled FortiGate unit’s GTP profiles, you must first configure the APN. It is critical to GTP communications and without it no traffic will flow.

The access point can then be used in a DNS query to a private DNS network. This process (called APN resolution) gives the IP address of the GGSN which serves the access point. At this point a PDP context can be activated.

Mobile Subscriber Integrated Services Digital Network (MSISDN)

This is a 15-digit number that, along with the IMSI, uniquely identifies a mobile user. Normally this number includes a 2-digit country code, a 3-digit national destination code, and a 10-digit subscriber number or the phone number of the mobile device, and because of that may change over time if the user changes their phone number. The MSISDN number follows the ITU-T E.164 numbering plan.

Radio Access Technology (RAT) type

The RAT type represents the radio technology used by the mobile device. This can be useful in determining what services or content can be sent to a specific mobile device. FortiOS Carrier supports:

• UMTS Terrestrial Radio Access Network (UTRAN), commonly referred to as 3G, routes many types of traffic including IP traffic. This is one of the faster types.
• GSM EDGE Radio Access Network (GERAN) is a key part of the GSM network which routes both phone calls and data.
• Wireless LAN (WLAN) is used but not as widely as the other types. It is possible for the mobile device to move from one WLAN to another such as from an internal WLAN to a commercial hot spot.
• Generic Access Network (GAN) can also be called unlicensed mobile access (UMA). It routes voice, data, and SIP over IP networks. GAN is commonly used for mobile devices that have a dual-mode and can hand-off between GSM and WLANs.
• High Speed Packet Access (HSPA) includes two other protocols High Speed Downlink and Uplink Packet Access protocols (HSDPA and HSUPA respectively). It improves on the older WCDMA protocols by better using the radio bandwidth between the mobile device and the radio tower. This results in an increased data transfer rate for the user.

RAT type is part of advanced filtering configuration. See Configuring advanced filtering in FortiOS Carrier.

User Location Information (ULI)

Gives Cell Global Identity/Service Area Identity (CGI/SAI) of where the mobile station is currently located. The ULI and the RAI are commonly used together to identify the location of the mobile device.

ULI is part of advanced filtering configuration. See Configuring advanced filtering in FortiOS Carrier.

Routing Area Identifier (RAI)

Routing Areas (RAs) divide the carrier network and each has its own identifier (RAI). When a mobile device moves from one routing area to another, the connection is handled by a different part of the network. There are normally multiple cells in a routing area. There is only one SSGN per routing area. The RAI and ULI are commonly used to determine a user’s location.

RAI is part of advanced filtering configuration. See Configuring advanced filtering in FortiOS Carrier.

International Mobile Equipment Identity (IMEI)

IMEI is a unique 15-digit number used to identify mobile devices on mobile networks. It is very much like the MAC address of a TCP/IP network card for a computer. It can be used to prevent network access by a stolen phone — the carrier knows the mobile phone’s IMEI, and when it is reported stolen that IMEI is blocked from accessing the carrier network no matter if it has the same SIM card as before or not. It is important to note that the IMEI stays with the mobile phone or device where the other information is either location based or stored on the removable SIM card.

IMEI type is part of advanced filtering configuration. See Configuring advanced filtering in FortiOS Carrier.

When to use APN, IMSI, or advanced filtering

At first glance APN, IMSI, and advanced filtering have parts in common. For example two can filter on APN, and another two can filter on IMSI. The difficulty is knowing when to use which type of filtering.

Identity filtering comparison

APN filtering is very specific — the only identifying information that is used to filter is the APN itself. This will always be present in GTP tunnel traffic, so all GTP traffic can be filtered using this value.

IMSI filtering can use a combination of the APN and MCC-MNC numbers. The MCC and MNC are part of the APN, however filtering on MCC-MNC separately allows you to filter based on country and carrier instead of just the destination of the GTP Tunnel.

Advanced filtering can go into much deeper detail covering PDP contexts, MSISDN, IMEI, and more not to mention APN, and IMSI as well. If you can’t find the information in APN or IMSI that you need to filter on, then use Advanced filtering.

Configuring APN filtering in FortiOS Carrier

To configure APN filtering go to Security Profiles > GTP Profile. Select a profile or create a new one, and expand APN filtering.

When you are configuring your Carrier-enabled FortiGate unit’s GTP profiles, you must first configure the APN. It is critical to GTP communications and without it no traffic will flow.

The Add APN button is not activated until you save the new GTP profile. When you edit that GTP profile, you will be able to add new APNs.

Configuring IMSI filtering in FortiOS Carrier

In many ways the IMSI on a GPRS network is similar to an IP address on a TCP/IP network. Different parts of the number provide different pieces of information. This concept is used in IMSI filtering on FortiOS Carrier.

To configure IMSI filtering go to Security Profiles > GTP Profile and expand IMSI filtering.

While both the APN and MCC-MCN fields are optional, without using one of these fields the IMSI entry will not be useful as there is no information for the filter to match.

Configuring advanced filtering in FortiOS Carrier

Compared to ADN or IMSI filtering, advanced filtering is well named. Advanced filtering can be viewed as a catchall filtering option — if ADN or IMSI filtering doesn’t do what you want, then advanced filtering will. The advanced filtering can use more information elements to provide considerably more granularity for your filtering.

SCTP Concepts

SCTP Concepts

As of FortiOS version 5.0, the FortiGate natively handles SCTP (Stream Control Transport Protocol) traffic, as an alternative to TCP and UDP for use in Carrier networks. The FortiGate handles SCTP as if it would any other traffic.

Overview

SCTP is a connection-oriented transport protocol that overcomes some of the limitations of both TCP and UDP that prevent reliable transfer of data over IP-based networks (such as those used by telephony systems and carrier networks). The ‘Stream’ in SCTP refers to the sequence of user messages or packets that are considered at the same time to be individual objects and also treated as a whole by networked systems. SCTP is less vulnerable to congestion and flooding due to more advanced error handling and flood protection built into the protocol.

SCTP features as compared to TCP and UDP

All of these features are built into the design of the Protocol, and the structure of SCTP packets and networks. The FortiGate unit interprets the traffic and provides the necessary support for maintenance and verification features, but the features are not FortiGate specific. These features are documented in greater detail below.

SCTP Concepts

State required at each endpoint

Constant back and forth acknowledgement and content verification messages are sent between all SCTP peer endpoints, and all endpoints’ state machine actions must be synchronized for traffic to flow.

Reliable data transfer

SCTP places data and control information (eg. source, destination, verification) into separate messages, both sharing the same header in the same SCTP packet. This allows for constant verification of the contained data at both ends and along the path, preventing data loss or fragmentation. As well, data is not sent in an interruptible stream as in TCP.

Congestion control and avoidance

Built-in, constantly updating path detection and monitoring automatically redirect packets along alternate paths in case of traffic congestion or inaccessible destinations. For deliberate/malicious congestion control, see the below section on Security cookie against SYN flood attack.

Message boundary conservation

SCTP is designed in such a way that no matter how messages are divided, redirected, or fragmented, the message boundaries will be maintained within the packets, and all messages cannot be appended without tripping verification mechanisms.

Path MTU discovery and message fragmentation

SCTP is capable of Path Maximum Transmission Unit discovery, as outlined in RFC4821. Two specific alterations have been made to how SCTP handles MTU. First, that endpoints will have separate MTU estimates for each possible multi-homed endpoint. Second, that bundled message fragments (as explained below) will be directed based on MTU calculations, so that retransmissions (if necessary) will be sent without delay to alternate addresses.

Message bundling

SCTP is a message-oriented protocol, which means that despite being a streaming data protocol, it transports a sequence of specific messages, rather than transporting a stream of bytes (like TCP). Since some data transmissions are small enough to not require a complete message’s worth of content, so multiple pieces of content will be transmitted simultaneously within the messages.

Multi-homed hosts support

SCTP supports multi-homing, which is a network structure in which one or multiple sources/destinations has more than one IP address. SCTP can adapt to multi-homing scenarios and redirect traffic to alternate IP addresses in case of failure.

Multi-stream support

Due to the message bundling feature allowing for multiple pieces of content to be sent in messages at once, SCTP can ‘multi-stream’ content, by deliberately dividing it among messages at a fixed rate, so that multiple types of content (eg. both images and text) can be loaded at once, at the same pace.

GTP                                                                                                                                           SCTP Concepts

Unordered data delivery

With control messages in every packet to provide verification of any packet’s data and its place in the stream, the data being transmitted can actually arrive in any order, and verify that all has arrived or that some is missing.

Security cookie against SYN flood attack

Since every packet contains verification of its place in the stream, it makes it easy for the protocol to detect when redundant, corrupted or malicious packets flood the path, and they are automatically dropped when necessary.

Built-in heartbeat (reachability check)

Endpoints automatically send specific control chunks among the other SCTP packet information to peer endpoints, to determine the reachability of the destination. Hearthbeat acknowledgement packets are returned if the destination is available.

SCTP Firewall

FortiGate stateful firewalls will protect and inspect SCTP traffic, according to RFC4960. SCTP over IPsec VPN is also supported. The FortiGate device is inserted as a router between SCTP endpoints. It checks SCTP Syntax for the following information:

• Source and destination port l Verification Tag l Chunk type, chunk flags, chunk length l Sequence of chunk types l Associations

The firewall also oversees and maintains several SCTP security mechanisms:

• SCTP four-way handshake l SCTP heartbeat l NAT over SCTP

The firewall has IPS DoS protection against known threats to SCTP traffic, including INIT/ACK flood attacks, and SCTP fuzzing.

Troubleshooting

This section offers troubleshooting options for Carrier-related issues.

This section includes:

FortiOS Carrier diagnose commands

Applying IPS signatures to IP packets within GTP-U tunnels

GTP packets are not moving along your network

FortiOS Carrier diagnose commands

This section includes diagnose commands specific to FortiOS Carrier features such as GTP.

GTP related diagnose commands

This CLI command allows you to gain information on GTP packets, logs, statistics, and other information.

diag firewall gtp <command>

Applying IPS signatures to IP packets within GTP-U tunnels

Applying IPS signatures to IP packets within GTP-U tunnels

GTP-U (GTP user data tunnelling) tunnels carry user data packets, signaling messages and error information. GTP-U uses UDP port 2152. Carrier-enabled FortiGate units can apply IPS intrusion protection and detection to GTP-U user data sessions.

To apply IPS to GTP-U user data sessions, add an IPS Sensor to a profile and add the profile to a security policy that accepts GTP-U tunnels. The security policy Service field must be set to GTP or ANY to accept GTP-U packets.

The Carrier-enabled FortiGate unit intercepts packets with destination port 2152, removes the GTP header and handles the packets as regular IP packets. Applying an IPS sensor to the IP packets, the Carrier-enabled FortiGate unit can log attacks and pass or drop packets depending on the configuration of the sensor.

If the packet is GTP-in-GTP, or a nested tunnel, the packets are passed or blocked without being inspected.

To apply an IPS sensor to GTP-U tunnels

1. Go to Security Profiles > Intrusion Protection and select Create New (+) to add an IPS Sensor.
2. Configure the IPS Sensor to detect attacks and log, drop, or pass attack packets. See the Intrusion Protection section of the FortiOS UTM Guide.
3. Go to Policy & Objects > IPv4 Policy and apply the IPS sensor to the security policy.
4. Go to Policy & Objects > IPv4 Policy and select Create New to add a security policy or select a security policy.
5. Configure the security policy to accept GTP traffic.

In the security policy configure the source and destination settings to match the GTP traffic. Service to GTP or ANY so that the security policy accepts GTP traffic.

6. Select the GTP profile within the security policy.
7. Configure any other required security policy settings.
8. Select OK to save the security policy.

GTP packets are not moving along your network

When GTP packets are not getting to their destination, this could be caused by any one of a number of issues. General troubleshooting principals apply here.

The following sections provide some suggestions on how to troubleshoot this issue:

• Attempt to identify the section of your network with the problem l Ensure you have an APN configured l Check the logs and adjust their settings if required l Check the routing table l Perform a sniffer trace
• Generate specific packets to test the network

Attempt to identify the section of your network with the problem

The first step is to determine how widespread this problem is. Does it affect the whole GPRS network, or just one or two devices?

If the entire network is has this problem, the solution is likely a more general one such as ensuring the security policies allow GTP traffic to pass, the GTP profile specifies SSGNs and GSGNs, or ensuring the GTP general settings are not overly limiting.

If one part of the network is affected, the problem is more likely centered around configurations with those network devices specified such as the handover group, or authorized SGSNs/GGSNs. It is also possible that small portions of the network may have hardware related issues such as cabling or faulty hardware. This section does not address those issues, and assumes hardware is not the problem.

The handover group is a white list of GTP addresses allowed to handle GTP messages. If a device’s address is not on this list, it will be denied.

GTP packets are not moving along your network

Ensure you have an APN configured

When you configure your GTP profile, ensure you first configure the APN. Without it, there will be no flow of traffic. The APN is used in nearly all GTP communications and without it, the Carrier-enabled FortiGate unit doesn’t have the information it needs.

Check the logs and adjust their settings if required

During normal operation, the log settings will show any problems on the network but may not provide the level of details required to fully troubleshoot the problem. The reason for this is that the level of detail required for troubleshooting would quickly overwhelm the daily logs without any real benefit.

GTP related events in the event log will have message IDs in the range 41216 to 41222. For more information on GTP log messages, see the Log Message Reference. For more information on logging in general, see the Logging and Reporting guide.

Once there is a problem to troubleshoot, check the logs to trace the traffic patterns and narrow down the possible sources of the problem. There may be enough detail for you to locate and fix the problem without changing the log settings.

Remember to set any changes you made to the log settings back to their original values when you are done troubleshooting. Otherwise, the amount of detail will overwhelm your logging.

However, if more detail is required you can change settings such as:

• Lower the Log Frequency number in GTP Profiles so fewer or no log messages are dropped. This will allow a more accurate picture of everything happening on the network, where you may have had only a partial picture before.
• Ensure all the GTP log events are enabled to provide you with a complete picture. l Ensure that all relevant event types are enabled under Log & Report > Log Config > Log Settings.

For more information on GTP related logging, see Logging events on the Carrier-enabled FortiGate unit.

General information to look for in the logs includes:

• Are all packets having problems or just certain types? l Are all devices on the network having problem, or just certain devices? l Is it just GTP traffic that is having problems or are all types of traffic having the same problem?

Check the routing table

On any network, the routing table determines how packets reach their destination. This is also true on a carrier network.

If the Carrier-enabled FortiGate unit is running in NAT mode, verify that all desired routes are in the routing table — local subnets, default routes, specific static routes, and dynamic routing protocols. For complete information, it is best to check the routing table in the CLI. This method provides more complete information.

To check the routing table using the CLI

# get router info routing-table all

Codes: K – kernel, C – connected, S – static, R – RIP, B – BGP

O – OSPF, IA – OSPF inter area

N1 – OSPF NSSA external type 1, N2 – OSPF NSSA external type 2 E1 – OSPF external type 1, E2 – OSPF external type 2

i – IS-IS, L1 – IS-IS level-1, L2 – IS-IS level-2, ia – IS-IS inter area * – candidate default

S* 0.0.0.0/0 [10/0] via 192.168.183.254, port2

S 1.0.0.0/8 [10/0] via 192.168.183.254, port2

S 2.0.0.0/8 [10/0] via 192.168.183.254, port2

C 10.142.0.0/23 is directly connected, port3

B 10.160.0.0/23 [20/0] via 10.142.0.74, port3, 2d18h02m C 192.168.182.0/23 is directly connected, port2

Examining an entry from the routing table above:

B 10.160.0.0/23 [20/0] via 10.142.0.74, port3, 2d18h02m

Perform a sniffer trace

When troubleshooting network traffic, it helps to look inside the headers of packets to determine if they are traveling along the route you expect. Packet sniffing can also be called a network tap, packet capture, or logic analyzing.

If your Carrier-enabled FortiGate unit has NP interfaces that are offloading traffic, this will change the sniffer trace. Before performing a trace on any NP interfaces, disable offloading on those interfaces.

What can sniffing packets tell you

If you are running a constant traffic application such as ping, packet sniffing can tell you if the traffic is reaching the destination, what the port of entry is on the Carrier-enabled FortiGate unit, if the ARP resolution is correct, and if the traffic is being sent back to the source as expected.

GTP packets are not moving along your network

Sniffing packets can also tell you if the Carrier-enabled FortiGate unit is silently dropping packets for reasons such as RPF (Reverse Path Forwarding), also called Anti Spoofing. This prevents an IP packet from being forwarded if its source IP address either does not belong to a locally attached subnet (local interface), or be a hop on the routing between the FortiOS Carrier and another source (static route, RIP, OSPF, BGP). Note that RPF can be disabled by turning on asymmetric routing in the CLI (config system setting, set asymmetric enable), however this will disable stateful inspection on the Carrier-enabled FortiGate unit and consequently cause many features to be turned off.

If you configure virtual IP addresses on your Carrier-enabled FortiGate unit, the unit will use those addresses in preference to the physical IP addresses. If not configured properly, secondary IP addresses can cause a broadcast storm. You will notice the secondary address being preferred when you are sniffing packets because all the traffic will be using the virtual IP addresses. This is due to the ARP update that is sent out when the VIP address is configured.

How to sniff packets

The general form of the internal FortiOS packet sniffer command is: diag sniffer packet <interface_name> <‘filter’> <verbose> <count>

To stop the sniffer, type CTRL+C.

For a simple sniffing example, enter the CLI command diag sniffer packet port1 none 1 3. This

will display the next 3 packets on the port1 interface using no filtering, and using verbose level 1. At this verbosity level you can see the source IP and port, the destination IP and port, action (such as ack), and sequence numbers.

In the output below, port 443 indicates these are HTTPS packets, and 172.20.120.17 is both sending and receiving traffic.

Head_Office_620b # diag sniffer packet port1 none 1 3 interfaces=[port1] filters=[none]

0.545306 172.20.120.17.52989 -> 172.20.120.141.443: psh 3177924955 ack 1854307757

0.545963 172.20.120.141.443 -> 172.20.120.17.52989: psh 1854307757 ack 3177925808

0.562409 172.20.120.17.52988 -> 172.20.120.141.443: psh 4225311614 ack 3314279933

Generate specific packets to test the network

If some packets are being delivered as expected while others are not, or after you believe you have fixed the problem, it is a good idea to generate specific traffic to test your network.

For example if you discover through log messages and packet sniffing that Create PDP Context Request messages are not being delivered between two SGSNs, you can generate those specific messages on your network to confirm they are the problem, and later that you have solved the problem and they are now being delivered as expected.

This step requires a third party traffic generation tool, either hardware or software. This is not be supported by Fortinet.

Introduction

This  FortiOS Handbook chapter contains the following sections:

IPsec VPN concepts explains the basic concepts that you need to understand about virtual private networks (VPNs).

IPsec VPN overview provides a brief overview of IPsec technology and includes general information about how to configure IPsec VPNs using this guide.

IPsec VPN in the web-based manager describes the IPsec VPN menu of the web-based manager interface.

Gateway-to-gateway configurations  explains how to set up a basic gateway-to-gateway (site-to-site) IPsec VPN. In a gateway-to-gateway configuration, two FortiGate units create a VPN tunnel between two separate private networks.

Hub-and-spoke configurations describes how to set up hub-and-spoke IPsec VPNs. In a hub-and-spoke configuration, connections to a number of remote peers and/or clients radiate from a single, central FortiGate hub.

Dynamic DNS configuration describes how to configure a site-to-site VPN, in which one FortiGate unit has a static IP address and the other FortiGate unit has a dynamic IP address and a domain name.

FortiClient dialup-client configurations guides you through configuring a FortiClient dialup-client IPsec VPN. In a FortiClient dialup-client configuration, the FortiGate unit acts as a dialup server and VPN client functionality is provided by the FortiClient Endpoint Security application installed on a remote host.

FortiGate dialup-client configurations  explains how to set up a FortiGate dialup-client IPsec VPN. In a FortiGate dialup-client configuration, a FortiGate unit with a static IP address acts as a dialup server and a FortiGate unit with a dynamic IP address initiates a VPN tunnel with the FortiGate dialup server.

Supporting IKE Mode config clients explains how to set up a FortiGate unit as either an IKE Mode Config server or client. IKE Mode Config is an alternative to DHCP over IPsec.

Internet-browsing configuration explains how to support secure web browsing performed by dialup VPN clients, and hosts behind a remote VPN peer. Remote users can access the private network behind the local FortiGate unit and browse the Internet securely. All traffic generated remotely is subject to the security policy that controls traffic on the private network behind the local FortiGate unit.

Redundant VPN configurations discusses the options for supporting redundant and partially redundant tunnels in an IPsec VPN configuration. A FortiGate unit can be configured to support redundant tunnels to the same remote peer if the FortiGate unit has more than one interface to the Internet.

Transparent mode VPNs describes two FortiGate units that create a VPN tunnel between two separate private networks transparently. In transparent mode, all FortiGate unit interfaces except the management interface are invisible at the network layer.

IPv6 IPsec VPNs describes FortiGate unit VPN capabilities for networks based on IPv6 addressing. This includes IPv4-over-IPv6 and IPv6-over-IPv4 tunnelling configurations. IPv6 IPsec VPNs are available in FortiOS 3.0 MR5 and later.

L2TP and IPsec (Microsoft VPN) explains how to support Microsoft Windows native VPN clients.

Introduction

GRE over IPsec (Cisco VPN) explains how to interoperate with Cisco VPNs that use Generic Routing Encapsulation (GRE) protocol with IPsec.

Protecting OSPF with IPsec provides an example of protecting OSPF links with IPsec.

Redundant OSPF routing over IPsec provides an example of  redundant secure communication between two remote networks using an OSPF VPN connection.

OSPF over dynamic IPsec provides an example of  how to create a dynamic IPsec VPN tunnel that allows OSPF.

BGP over dynamic IPsec provides an example of how to create a dynamic IPsec VPN tunnel that allows BGP.

Phase 1 parameters provides detailed step-by-step procedures for configuring a FortiGate unit to accept a connection from a remote peer or dialup client. The basic Phase 1 parameters identify the remote peer or clients and support authentication through preshared keys or digital certificates. You can increase VPN connection security further using methods such as extended authentication (XAuth).

Phase 2 parameters provides detailed step-by-step procedures for configuring an IPsec VPN tunnel. During Phase 2, the specific IPsec security associations needed to implement security services are selected and a tunnel is established.

Defining VPN security policies explains how to specify the source and destination IP addresses of traffic transmitted through an IPsec VPN tunnel, and how to define a security encryption policy. Security policies control all IP traffic passing between a source address and a destination address.

Logging and monitoring and Troubleshooting provide VPN monitoring and troubleshooting procedures.

What’s new in FortiOS 5.6

This chapter describes new IPsec VPN features added to FortiOS 5.6.0 and FortiOS 5.6.1.

FortiOS 5.6.1

These features first appeared in FortiOS 5.6.1.

Support for Brainpool curves specified in RFC 6954 for IKE (412795)

Added support for Brainpool curves specified in RFC 6954 (originally RFC 5639) for IKE. Four new values are added for VPN phase1 and phase2 DH groups.

The allocated transform IDs are 27, 28, 29, 30:

• 27 – Brainpool 224-Bit Curve
• 28 – Brainpool 256-Bit Curve
• 29 – Brainpool 384-Bit Curve
• 30 – Brainpool 512-Bit Curve

Syntax

config vpn ipsec phase1/phase1-interface edit <name> set dhgrp {1 | 2 | 5 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 27 | 28 | 29 | 30}

next

end

config vpn ipsec phase2/phase2-interface edit <name> set dhgrp {1 | 2 | 5 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 27 | 28 | 29 | 30}

next

end

Removed “exchange-interface-ip” option from “vpn ipsec phase1” (411981)

The command exchange-interface-ip only works for interface-based IPsec VPN (vpn ipsec phase1interface), and so it has been removed from policy-based IPsec VPN (vpn ipsec phase1).

IKEv2 ancillary RADIUS group authentication (406497)

This feature provides for the IDi information to be extracted from the IKEv2 AUTH exchange and sent to a RADIUS server, along with a fixed password configurable via CLI, to perform an additional group authentication step prior to tunnel establishment. The RADIUS server may return framed-IP-address, framed-ip-netmask, and dns-server attributes, which are then applied to the tunnel.

5.6.1

It should be noted, unlike Xauth or EAP, this feature does not perform individual user authentication, but rather treats all users on the gateway as a single group, and authenticates that group with RADIUS using a fixed password. This feature also works with RADIUS accounting, including the phase1 acct-verify option.

Syntax

config vpn ipsec phase1-interface edit <name> set mode-cfg enable set type dynamic set ike-version 2

set group-authentication {enable | disable} set group-authentication-secret <password>

next

end

IPsec mode-cfg can assign IPs from firewall address and sharing IP pools (393331)

This feature adds the ability for users to configure assign-IPs from firewall addresses/groups.

Previously, different policies accessing the same network needed to ensure that non-overlapping IP-ranges were assigned to policies to avoid the same IP address being assigned to multiple clients. With this feature, the address name is used to identify an IP pool and different policies can refer to the same IP pool to check for available IPs, thus simplifying the task of avoiding IP conflicts.

Syntax

config vpn ipsec phase1-interface edit <name> set mode-cfg enable set type dynamic

set assign-ip-from {range | dhcp | name} set ipv4-name <name> set ipv6-name <name>

next

end

Improve interface-based dynamic IPsec up/down time (379937)

This feature makes it possible to use a single interface for all instances that spawn via a given phase1. Instead of creating an interface per instance, all traffic will run over the single interface and any routes that need creating will be created on that single interface.

A new CLI option net-device is added in the phase1-interface command sets. The default is disable so that the new feature kicks in for all the new configurations. An upgrade feature will add a set net-device enable for all the existing configurations so that they will keep the old behavior.

Under the new single-interface scheme, instead of relying on routing to guide traffic to the specific instance, all traffic will flow to the specific device and IPsec will need to take care of locating the correct instance for outbound traffic. For this purpose, another new CLI option tunnel-search is created. The option is only available when the above net-device option is set to disable.

There are two options for tunnel-search, corresponding to the two ways to select the tunnel for outbound traffic. One is selectors, meaning selecting a peer using the IPsec selectors (proxy-ids). The other is

5.6.1

nexthop where all the peers use the same default selectors (0/0) while using some routing protocols such as BGP, OSPF, RIPng, etc. to resolve the routing. The default for tunnel-search is selectors.

Syntax

config vpn ipsec phase1-interface edit <name> set net-device {enable | disable} set tunnel-search {selectors | nexthop}

next

end

Hide psksecret option when peertype is dialup (415480)

In aggressive mode and IKEv2, when peertype is dialup, pre-shared key is per-user based. There is no need to configure the psksecret in the phase1 setup. Previously, if left unconfigured, CLI would output psksecret error and fail to create the phase1 profile.

To prevent psksecret length check running on the configuration end, the psksecret option will be hidden. Prior to Mantis 397712, the length check passed because it was incorrectly checking the legnth of encrypted password which is always 204 length long.

Peertype dialup option removed for main mode.

New enforce-ipsec option added to L2TP config (423988)

A new enforce-ipsec option is added in L2TP configuration to force the FortiGate L2TP server to accept only IPsec encrypted connections.

Syntax

config vpn l2tp set eip 50.0.0.100 set sip 50.0.0.1 set status enable

set enforce-ipsec-interface {disable | enable}      (default = disable) set usrgrp <group_name>

end

IPsec VPN Wizard improvements (368069)

Previously, when using wan-load-balance (WLB) feature, and when configuring an IPsec tunnel with the wizard, the setting ‘incoming interface’ list does not contain the wan-load-balance nor the wan2 interface. Disabling the WLB permits the configuration.

The solution in 5.6.1 is as follows:

• (368069) The IPsec VPN wizard now allows users to select members of virtual-wan-link (VWL) as IPsec phase1interface. Before saving, if the phase1 interface is a VWL member, then the Wizard automatically sets the virtualwan-link as the destination interface in the L2TP policy.
• (246552) List VPN tunnels for VWL members if VWL is set as the destination interface in policy-based IPsec VPN.

IPsec manual key support removed from GUI (436041)

The majority of customers are not using policy-based IPsec today, and beyond that, very few are using manual key VPN. As a result, the IPsec manual key feature is removed from the GUI; the feature store option is removed as well.

Added GUI support for local-gw when configuring custom IPsec tunnels (423786)

Previously, the local-gw option was not available on the GUI when configuring a custom IPsec tunnel. This feature adds the local-gw setting to the IPsec VPN Edit dialog. The user is able to choose the primary or secondary IP address from the currently selected interface, or specify an ip address manually. Both local-gw and local-gw6 are supported.

Moved the dn-format CLI option from phase1 config to vdom settings (435542)

Previous fix for dn-format didn’t take into account that, at the time isakmp_set_peer_identifier is used, we don’t have a connection and haven’t matched our gateway yet, so we can’t use that to determine the dn-format configuration setting.

The solution was to move the dn-format CLI option from phase1 config to vdom settings. It is renamed to ike-dn-format.

FGT IKE incorrect NAT detection causes ADVPN hub behind VIP to not generate shortcuts (416786)

When ADVPN NAT support was added, only spokes behind NAT was considered. No thought was given to a hub behind a VIP or the problems that occurred due to the way that FortiOS clients behind NAT enable NAT-T even when it is not required.

The solution in 5.6.1 is as follows:

• Moved shortcut determination out of the kernel and up to IKE. The shortcut message now contains the ID of both tunnels so that IKE can check the NAT condition of both.
• Added IKE debug to cover sending the initial shortcut query. The lack of this previously meant it could be awkard to determine if the offer had been converted into a query correctly.
• Added “nat:” output in diag vpn ike gateway list output to indicate whether this device or the peer is behind NAT.
• Tweaked the diag vpn tunnel list output so that the auto-discovery information now includes symbolic as well as numeric values, which makes it easier to see what type of auto-discovery was enabled.

FortiOS 5.6.0

These features first appeared in FortiOS 5.6.0.

5.6.0

Improvement to stats crypto command output (403995)

The CLI command get vpn ipsec stats crypto now has a better format for the information it shows in differentiating between NP6 lite and SOC3 (CP). To further avoid confusion, all engine’s encryption (encrypted/decrypted) and integrity (generated/validated) information is shown under the same heading, not separate headings.

Improved certificate key size control commands (397883)

Proxy will choose the same SSL key size as the HTTPS server. If the key size from the server is 512, the proxy will choose 1024. If the key size is bigger than 1024, the proxy will choose 2048.

As a result, the firewall ssl-ssh-profile commands certname-rsa, certname-dsa, and certname-ecdsa have been replaced with more specific key size control commands under vpn certificate setting.

CLI syntax

config vpn certificate setting set certname-rsa1024 <name> set certname-rsa2048 <name> set certname-dsa1024 <name> set certname-dsa2048 <name> set certname-ecdsa256 <name> set certname-ecdsa384 <name>

end

Support bit-based keys in IKE (397712)

As per FIPS-CC required standards, as well as RFC 4306, IKE supports pre-shared secrets to be entered as both ASCII string values and as hexadecimal encoded values. This feature parses hex encoded input (indicated by the leading characters 0x) and converts the input into binary data for storage.

With this change, the psksecret and psksecret-remote entries under the IPsec VPN CLI command config vpn ipsec-phase1-interface have been amended to differentiate user input as either ASCII string or hex encoded values.

IKEv2 asymmetric authentication (393073)

Support added for IKEv2 asymmetric authentication, allowing both sides of an authentication exchange to use different authentication methods, for example the initiator may be using a shared key, while the responder may have a public signature key and certificate.

A new command, authmethod-remote, has been added to config vpn ipsec phase1-interface.

For more detailed information on authentication of the IKE SA, see RFC 5996 – Internet Key Exchange Protocol Version 2 (IKEv2).

Allow mode-cfg with childless IKEv2 (391567)

An issue that prevented childless-ike from being enabled at the same time as mode-cfg has been resolved. Both options can now be enabled at once under config vpn ipsec phase1-interface.

IKEv2 Digital Signature Authentication support (389001)

FortiOS supports the use of Digital Signature authentication, which changes the format of the Authentication Data payload in order to support different signature methods.

Instead of just  containing a raw signature value calculated as defined in the original IKE RFCs,  the Auth Data now includes an ASN.1 formatted object that provides  details on how the signature was calculated, such as the signature type, hash algorithm, and signature padding method.

For more detailed information on IKEv2 Digital Signature authentication, see RFC 7427 – Signature Authentication in the Internet Key Exchange Version 2 (IKEv2).

Passive static IPsec VPN (387913)

New commands have been added to config vpn ipsec phase1-interface to prevent initiating

VPN connection. Static IPsec VPNs can be configured in tunnel mode, without initiating tunnel negotiation or rekey.

To allow a finer configuration of the tunnel, the rekey option is removed from config system global and added to config vpn ipsec phase1-interface.

CLI syntax

config vpn ipsec phase1-interface edit <example> set rekey {enable | disable} set passive-mode {enable | disable} set passive-tunnel-interface {enable | disable}

end

Phase 2 wizard simplified (387725)

Previously, for a site-to-site VPN, phase 2 selectors had their static routes created in the IPsec VPN wizard by adding IP addresses  in string format. Now, since addresses and address groups are already created for these addresses, the address group can be used in the route directly. This means that the route can be modified simply by modifying the address/groups that were created when the VPN was initially created.

With this change, the VPN wizard will create less objects internally, and reduce complexity.

In addition, a blackhole route route will be created by default with a higher distance-weight set than the default route. This is to prevent traffic from flowing out of another route if the VPN interface goes down. In these instances, the traffic will instead be silently discarded.

Unique IKE ID enforcement (383296)

All IPsec VPN peers now connect with unique IKE identifiers. To implement this, a new phase1 CLI command has been added (enforce-unique-id) which, when enabled, requires all IPsec VPN clients to use a unique identifier when connecting.

CLI syntax

config vpn ipsec phase1 edit <name>

5.6.0

set enforce-unique-id {keep-new | keep-old | disable} Default is disable. next

end

Use keep-new to replace the old connection if an ID collision is detected on the gateway. Use keep-old to reject the new connection if an ID collision is detected.

FortiView VPN tunnel map feature (382767)

A geospatial map has been added to FortiView to help visualize IPsec and SSL VPN connections to a FortiGate using Google Maps. Adds geographical-IP API service for resolving spatial locations from IP addresses.

This feature can be found under FortiView > VPN.

Childless IKEv2 initiation (381650)

As documented in RFC 6023, when both sides support the feature, no child IPsec SA is brought up during the initial AUTH of the IKEv2 negotiation. Support for this mode is not actually negotiated, but the responder indicates support for it by including a CHILDLESS_IKEV2_SUPPORTED Notify in the initial SA_INIT reply. The initiator is then free to send its AUTH without any SA or TS payloads if it also supports this extension.

CLI syntax

config vpn ipsec phase1-interface edit ike set ike-version 2 set childless-ike enable

next

end

Due to the way configuration payloads (IKEV2_PAYLOAD_CONFIG) are handled in the current code base, mode-cfg and childless-ike aren’t allowed to be enabled at the same time. Processing config payloads for mode-cfg requires a child ph2handle to be created, but with childless-ike we completely avoid creating the child ph2 in the first place which makes the two features incompatible. It may be possible to support both in the future, but a deeper rework of the config payload handling is required.

Allow peertype dialup for IKEv2 pre-shared key dynamic phase1 (378714)

Restored peertype dialup that was removed in a previous build (when IKEv2 PSK gateway re-validation was not yet supported).

If peertype is dialup, IKEv2 AUTH verify uses user password in the user group “usrgrp” of phase1. The “psksecret” in phase1 is ignored.

CLI syntax

config vpn ipsec phase1-interface edit “name” set type dynamic set interface “wan1” set ike-version 2 set peertype dialup

set usrgrp “local-group”

next

end

IPsec default phase1/phase1-interface peertype changed from ‘any’ to ‘peer’ (376340)

Previously, when authmethod was changed to signature, peertype automatically changed to peer and required a peer to be set. This change was done to try to provide a more secure initial configuration, while allowing the admin to set peertype back to any if that’s what they really wanted. The default value was kept at any in the CLI. However, this caused problems with copy/pasting configurations and with FMG because if peertype any wasn’t explicitly provided, the CLI was switched to peertype peer.

This patch changes the default peertype to peer now; peertype any is considered non-default and will be printed out on any config listing. Upgrade code has been written to ensure that any older build that was implicitly using set peertype any has this setting preserved.

IPsec GUI bug fixes (374326)

Accept type “Any peer ID” is available when creating IPsec tunnel with authmethod, pre-shared key, ikev1 main mode/aggressive mode, and ikev2.

Support for IKEv2 Message Fragmentation (371241)

Added support for IKEv2 Message Fragmentation, as described in RFC 7383.

Previously, when sending and IKE packets with IKEv1, the whole packet is sent once, and it is only fragmented if there is a retransmission. With IKEv2, because RFC 7383 requires each fragment to be individually encrypted and authenticated, we would have to keep a copy of the unencrypted payloads around for each outgoing packet, in case the original single packet was never answered and we wanted to retry with fragments. So with this implementation, if the IKE payloads are greater than a configured threshold, the IKE packets are preemptively fragmented and encrypted.

CLI syntax

config vpn ipsec phase1-interface edit ike set ike-version 2

set fragmentation [enable|disable] set fragmentation-mtu [500-16000]

next

end

IPsec monitoring pages now based on phase 1 proposals not phase 2 (304246)

The IPsec monitor, found under Monitor > IPsec Monitor, was in some instances showing random uptimes even if the tunnel was in fact down.

Tunnels are considered as “up” if at least one phase 2 selector is active. To avoid confusion, when a tunnel is down, IPsec Monitor will keep the Phase 2 Selectors column, but hide it by default and be replaced with Phase 1 status column.

IPsec VPN concepts

Virtual Private Network (VPN) technology enables remote users to connect to private computer networks to gain access to their resources in a secure way. For example, an employee traveling or working from home can use a VPN to securely access the office network through the Internet.

Instead of remotely logging on to a private network using an unencrypted and unsecure Internet connection, the use of a VPN ensures that unauthorized parties cannot access the office network and cannot intercept any of the information that is exchanged between the employee and the office. It is also common to use a VPN to connect the private networks of two or more offices.

Fortinet offers VPN capabilities in the FortiGate Unified Threat Management (UTM) appliance and in the

FortiClient Endpoint Security suite of applications. A FortiGate unit can be installed on a private network, and FortiClient software can be installed on the user’s computer. It is also possible to use a FortiGate unit to connect to the private network instead of using FortiClient software.

This chapter discusses VPN terms and concepts including:

VPN tunnels

VPN gateways

Clients, servers, and peers

Encryption

Authentication

Phase 1 and Phase 2 settings

IKE and IPsec packet processing

VPN tunnels

The data path between a user’s computer and a private network through a VPN is referred to as a tunnel. Like a physical tunnel, the data path is accessible only at both ends. In the telecommuting scenario, the tunnel runs between the FortiClient application on the user’s PC, or a FortiGate unit or other network device and the FortiGate unit on the office private network.

Encapsulation makes this possible. IPsec packets pass from one end of the tunnel to the other and contain data packets that are exchanged between the local user and the remote private network. Encryption of the data packets ensures that any third-party who intercepts the IPsec packets can not access the data.

VPN tunnels Encoded data going through a VPN tunnel

You can create a VPN tunnel between:

• A PC equipped with the FortiClient application and a FortiGate unit
• Two FortiGate units
• Third-party VPN software and a FortiGate unit

For more information on third-party VPN software, refer to the Fortinet Knowledge Base for more information.

Tunnel templates

Several tunnel templates are available in the IPsec VPN Wizard that cover a variety of different types of IPsec VPN. A list of these templates appear on the first page of the Wizard, located at VPN > IPsec Wizard. The tunnel template list follows.

IPsec VPN Wizard options

VPN gateways

VPN tunnel list

Once you create an IPsec VPN tunnel, it appears in the VPN tunnel list at VPN > IPsec Tunnels. By default, the tunnel list indicates the name of the tunnel, its interface binding, the tunnel template used, and the tunnel status. If you right-click on the table header row, you can include columns for comments, IKE version, mode (aggressive vs main), phase 2 proposals, and reference number. The tunnel list page also includes the option to create a new tunnel, as well as the options to edit or delete a highlighted tunnel.

FortiView VPN tunnel map

A geospatial map can be found under FortiView > VPN Map to help visualize IPsec (and SSL) VPN connections to a FortiGate using Google Maps. This feature adds a geographical-IP API service for resolving spatial locations from IP addresses.

VPN gateways

A gateway is a router that connects the local network to other networks. The default gateway setting in your computer’s TCP/IP properties specifies the gateway for your local network.

VPN gateways

A VPN gateway functions as one end of a VPN tunnel. It receives incoming IPsec packets, decrypts the encapsulated data packets and passes the data packets to the local network. Also, it encrypts data packets destined for the other end of the VPN tunnel, encapsulates them, and sends the IPsec packets to the other VPN gateway. The VPN gateway is a FortiGate unit because the private network behind it is protected, ensuring the security of the unencrypted VPN data. The gateway can also be FortiClient software running on a PC since the unencrypted data is secure on the PC.

The IP address of a VPN gateway is usually the IP address of the network interface that connects to the Internet. Optionally, you can define a secondary IP address for the interface and use that address as the local VPN gateway address. The benefit of doing this is that your existing setup is not affected by the VPN settings.

The following diagram shows a VPN connection between two private networks with FortiGate units acting as the VPN gateways. This configuration is commonly referred to as Gateway-to-Gateway IPsec VPN.

VPN tunnel between two private networks

Although the IPsec traffic may actually pass through many Internet routers, you can visualize the VPN tunnel as a simple secure connection between the two FortiGate units.

Users on the two private networks do not need to be aware of the VPN tunnel. The applications on their computers generate packets with the appropriate source and destination addresses, as they normally do. The FortiGate units manage all the details of encrypting, encapsulating, and sending the packets to the remote VPN gateway.

The data is encapsulated in IPsec packets only in the VPN tunnel between the two VPN gateways. Between the user’s computer and the gateway, the data is on the secure private network and it is in regular IP packets.

For example User1 on the Site  A network, at IP address 10.10.1.7, sends packets with destination IP address 192.168.10.8, the address of User2 on the Site B network. The Site A FortiGate unit is configured to send packets with destinations on the 192.168.10.0 network through the VPN, encrypted and encapsulated. Similarly, the Site Clients, servers, and peers

B FortiGate unit is configured to send packets with destinations on the 10.10.1.0 network through the VPN tunnel to the Site A VPN gateway.

In the site-to-site, or gateway-to-gateway VPN shown below, the FortiGate units have static (fixed) IP addresses and either unit can initiate communication.

You can also create a VPN tunnel between an individual PC running FortiClient and a FortiGate unit, as shown below. This is commonly referred to as Client-to-Gateway IPsec VPN.

VPN tunnel between a FortiClient PC and a FortiGate unit

On the PC, the FortiClient application acts as the local VPN gateway. Packets destined for the office network are encrypted, encapsulated into IPsec packets, and sent through the VPN tunnel to the FortiGate unit. Packets for other destinations are routed to the Internet as usual. IPsec packets arriving through the tunnel are decrypted to recover the original IP packets.

Clients, servers, and peers

A FortiGate unit in a VPN can have one of the following roles:

• Server — responds to a request to establish a VPN tunnel.
• Client — contacts a remote VPN gateway and requests a VPN tunnel. l Peer — brings up a VPN tunnel or responds to a request to do so.

The site-to-site VPN shown above is a peer-to-peer relationship. Either FortiGate unit VPN gateway can establish the tunnel and initiate communications. The FortiClient-to-FortiGate VPN shown below is a client-server relationship. The FortiGate unit establishes a tunnel when the FortiClient PC requests one.

Encryption

A FortiGate unit cannot be a VPN server if it has a dynamically-assigned IP address. VPN clients need to be configured with a static IP address for the server. A FortiGate unit acts as a server only when the remote VPN gateway has a dynamic IP address or is a client-only device or application, such as FortiClient.

As a VPN server, a FortiGate unit can also offer automatic configuration for FortiClient PCs. The user needs to know only the IP address of the FortiGate VPN server and a valid user name/password. FortiClient downloads the VPN configuration settings from the FortiGate VPN server. For information about configuring a FortiGate unit as a VPN server, see the FortiClient Administration Guide.

Encryption

Encryption mathematically transforms data to appear as meaningless random numbers. The original data is called plaintext and the encrypted data is called ciphertext. The opposite process, called decryption, performs the inverse operation to recover the original plaintext from the ciphertext.

The process by which the plaintext is transformed to ciphertext and back again is called an algorithm. All algorithms use a small piece of information, a key, in the arithmetic process of converted plaintext to ciphertext, or vice-versa. IPsec uses symmetrical algorithms, in which the same key is used to both encrypt and decrypt the data. The security of an encryption algorithm is determined by the length of the key that it uses. FortiGate IPsec VPNs offer the following encryption algorithms, in descending order of security:

The default encryption algorithms provided on FortiGate units make recovery of encrypted data almost impossible without the proper encryption keys.

There is a human factor in the security of encryption. The key must be kept secret, known only to the sender and receiver of the messages. Also, the key must not be something that unauthorized parties might easily guess, such as the sender’s name, birthday or simple sequence such as 123456.

Diffie-Hellman groups

FortiOS IPsec VPN supports the following Diffie-Hellman (DH) asymmetric key algorithms for public key cryptography.

Encryption

* When using aggressive mode, DH groups cannot be negotiated.

By default, DH group 14 is selected, to provide sufficient protection for stronger cipher suites that include AES and SHA2. If you select multiple DH groups, the order they appear in the configuration is the order in which they are negotiates.

If both VPN peers (or a VPN server and its client) have static IP addresses and use aggressive mode, select a single DH group. The setting on the FortiGate unit must be identical to the setting on the remote peer or dialup client.

When the remote VPN peer or client has a dynamic IP address and uses aggressive mode, select up to three DH groups on the FortiGate unit and one DH group on the remote peer or dialup client. The setting on the remote peer or dialup client must be identical to one of the selections on the FortiGate unit.

If the VPN peer or client employs main mode, you can select multiple DH groups. At least one of the settings on the remote peer or dialup client must be identical to the selections on the FortiGate unit.

Authentication

IPsec overheads

The FortiGate sets an IPsec tunnel Maximum Transmission Unit (MTU) of 1436 for 3DES/SHA1 and an MTU of 1412 for AES128/SHA1, as seen with diag vpn tunnel list. This indicates that the FortiGate allocates 64 bytes of overhead for 3DES/SHA1 and 88 bytes for AES128/SHA1, which is the difference if you subtract this MTU from a typical ethernet MTU of 1500 bytes.

During the encryption process, AES/DES operates using a specific size of data which is block size. If data is smaller than that, it will be padded for the operation. MD5/SHA-1 HMAC also operates using a specific block size.

The following table describes the potential maximum overhead for each IPsec encryption:

Authentication

To protect data via encryption, a VPN must ensure that only authorized users can access the private network. You must use either a preshared key on both VPN gateways or RSA X.509 security certificates. The examples in this guide use only preshared key authentication. Refer to the Fortinet Knowledge Base for articles on RSA X.509 security certificates.

Preshared keys

A preshared key contains at least six random alphanumeric characters. Users of the VPN must obtain the preshared key from the person who manages the VPN server and add the preshared key to their VPN client configuration.

Although it looks like a password, the preshared key, also known as a shared secret, is never sent by either gateway. The preshared key is used in the calculations at each end that generate the encryption keys. As soon as the VPN peers attempt to exchange encrypted data, preshared keys that do not match will cause the process to fail.

Additional authentication

To increase security, you can require additional means of authentication from users, such as:

Phase 1 and Phase 2 settings

• An identifier, called a peer ID or a local ID.
• Extended authentication (XAUTH) which imposes an additional user name/password requirement.

A Local ID is an alphanumeric value assigned in the Phase 1 configuration. The Local ID of a peer is called a Peer

ID.

In FortiOS 5.2, new authentication methods have been implemented for IKE: ECDSA-256, ECDSA-384, and ECDSA-521. However, AES-XCBC is not supported.

Phase 1 and Phase 2 settings

A VPN tunnel is established in two phases: Phase 1 and Phase 2. Several parameters determine how this is done. Except for IP addresses, the settings simply need to match at both VPN gateways. There are defaults that are appropriate for most cases.

FortiClient distinguishes between Phase 1 and Phase 2 only in the VPN Advanced settings and uses different terms. Phase 1 is called the IKE Policy. Phase 2 is called the IPsec Policy.

Phase 1

In Phase 1, the two VPN gateways exchange information about the encryption algorithms that they support and then establish a temporary secure connection to exchange authentication information.

When you configure your FortiGate unit or FortiClient application, you must specify the following settings for Phase 1:

All other Phase 1 settings have default values. These settings mainly configure the types of encryption to be used. The default settings on FortiGate units and in the FortiClient application are compatible. The examples in this guide use these defaults.

For more detailed information about Phase 1 settings, see Phase 1 parameters on page 52.

Phase 2

Similar to the Phase 1 process, the two VPN gateways exchange information about the encryption algorithms that they support for Phase 2. You may choose different encryption for Phase 1 and Phase 2. If both gateways have at least one encryption algorithm in common, a VPN tunnel can be established. Keep in mind that more algorithms each phase does not share with the other gateway, the longer negotiations will take. In extreme cases this may cause timeouts during negotiations.

To configure default Phase 2 settings on a FortiGate unit, you need only select the name of the corresponding Phase 1 configuration. In FortiClient, no action is required to enable default Phase 2 settings.

For more detailed information about Phase 2 settings, see Phase 2 parameters on page 72.

Security Association

The establishment of a Security Association (SA) is the successful outcome of Phase 1 negotiations. Each peer maintains a database of information about VPN connections. The information in each SA can include cryptographic algorithms and keys, keylife, and the current packet sequence number. This information is kept synchronized as the VPN operates. Each SA has a Security Parameter Index (SPI) that is provided to the remote peer at the time the SA is established. Subsequent IPsec packets from the peer always reference the relevant SPI. It is possible for peers to have multiple VPNs active simultaneously, and correspondingly multiple SPIs.

The IPsec SA connect message generated is used to install dynamic selectors. These selectors can be installed via the auto-negotiate mechanism. When phase 2 has auto-negotiate enabled, and phase 1 has mesh selectortype set to subnet, a new dynamic selector will be installed for each combination of source and destination subnets. Each dynamic selector will inherit the auto-negotiate option from the template selector and begin SA negotiation. Phase 2 selector sources from dial-up clients will all establish SAs without traffic being initiated from the client subnets to the hub.

Remote IP address change detection

SAs are stored in a hash table when keyed off the IPsec SA SPI value. This enables the FortiGate, for each inbound ESP packet received, to immediately look up the SA and compare the stored IP address against the one in the incoming packet. If the incoming and stored IP addresses differ, an IP address change can be made in the kernel SA, and an update event can be triggered for IKE.

IKE and IPsec packet processing

Internet Key Exchange (IKE) is the protocol used to set up SAs in IPsec negotiation. As described in Phase 1 parameters on page 52, you can optionally choose IKEv2 over IKEv1 if you configure a route-based IPsec VPN. IKEv2 simplifies the negotiation process, in that it provides no choice of Aggressive or Main mode in Phase 1. IKEv2 also uses less bandwidth.

The following sections identify how IKE versions 1 and 2 operate and differentiate.

IKEv1

Phase 1

A peer, identified in the IPsec policy configuration, begins the IKE negotiation process. This IKE Security Association (SA) agreement is known as Phase 1. The Phase 1 parameters identify the remote peer or clients and supports authentication through pre-shared key (PSK) or digital certificate. You can increase access security further using peer identifiers, certificate distinguished names, group names, or the FortiGate extended authentication (XAuth) option for authentication purposes. Basically, Phase 1 authenticates a remote peer and sets up a secure communication channel for establishing Phase 2, which negotiates the IPsec SA.

IKE and IPsec packet processing

IKE Phase 1 can occur in either Main mode or Aggressive mode. For more information, see  Phase 1 parameters on page 52.

IKE Phase 1 is successful only when the following are true:

• Each peer negotiates a matching IKE SA policy.
• Each peer is authenticated and their identities protected.
• The Diffie-Hellman exchange is authenticated (the pre-shared secret keys match).

For more information on Phase 1, see Phase 1 parameters on page 52.

Phase 2

Phase 2 parameters define the algorithms that the FortiGate unit can use to encrypt and transfer data for the remainder of the session in an IPsec SA. The basic Phase 2 settings associate IPsec Phase 2 parameters with a Phase 1 configuration.

In Phase 2, the VPN peer or client and the FortiGate unit exchange keys again to establish a more secure communication channel. The Phase 2 Proposal parameters select the encryption and authentication algorithms needed to generate keys for protecting the implementation details of the SA. The keys are generated automatically using a Diffie-Hellman algorithm.

In Phase 2, Quick mode selectors determine which IP addresses can perform IKE negotiations to establish a tunnel. By only allowing authorized IP addresses access to the VPN tunnel, the network is more secure. For more information, see Phase 2 parameters on page 72.

IKE Phase 2 is successful only when the following are true:

• The IPsec SA is established and protected by the IKE SA.
• The IPsec SA is configured to renegotiate after set durations (see Phase 2 parameters on page 72 and Phase 2 parameters on page 72).
• Optional: Replay Detection is enabled. Replay attacks occur when an unauthorized party intercepts a series of IPsec packets and replays them back into the tunnel. See Phase 2 parameters on page 72.
• Optional: Perfect Forward Secrecy (PFS) is enabled. PFS improves security by forcing a new Diffie-Hellman exchange whenever keylife expires. See Phase 2 parameters on page 72.

For more information on Phase 2, see Phase 2 parameters on page 72.

With Phase 2 established, the IPsec tunnel is fully negotiated and traffic between the peers is allowed until the SA terminates (for any number of reasons; time-out, interruption, disconnection, etc).

The entire IKEv1 process is demonstrated in the following diagram:

IKEv2

Phase 1

Unlike Phase 1 of IKEv1, IKEv2 does not provide options for Aggressive or Main mode. Furthermore, Phase 1 of IKEv2 begins immediately with an IKE SA initiation, consisting of only two packets (containing all the information typically contained in four packets for IKEv1), securing the channel such that all following transactions are encrypted (see Phase 1 parameters on page 52).

The encrypted transactions contain the IKE authentication, since remote peers have yet to be authenticated. This stage of IKE authentication in IKEv2 can loosely be called Phase 1.5.

Phase 1.5

As part of this phase, IKE authentication must occur. IKE authentication consists of the following:

• The authentication payloads and Internet Security Association and Key Management Protocol (ISAKMP) identifier.
• The authentication method (RSA, PSK, ECDSA, or EAP). l The IPsec SA parameters.

Due to the number of authentication methods potentially used, and SAs established, the overall IKEv2 negotiation can range from 4 packets (no EAP exchange at all) to many more.

At this point, both peers have a security association complete and ready to encrypt traffic.

IKE and IPsec packet processing

Phase 2

In IKEv1, Phase 2 uses Quick mode to negotiate an IPsec SA between peers. In IKEv2, since the IPsec SA is already established, Phase 2 is essentially only used to negotiate “child” SAs, or to re-key an IPsec SA. That said, there are only two packets for each exchange of this type, similar to the exchange at the outset of Phase 1.5.

The entire IKEv2 process is demonstrated in the following diagram:

Support for IKEv2 session resumption

If a gateway loses connectivity to the network, clients can attempt to re-establish the lost session by presenting the ticket to the gateway (as described in RFC 5723). As a result, sessions can be resumed much faster, as DH exchange that is necessary to establish a brand new connection is skipped. This feature implements “ticket-byvalue”, whereby all information necessary to restore the state of a particular IKE SA is stored in the ticket and sent to the client.

IKEv2 asymmetric authentication

Asymmetric authentication allows both sides of an authentication exchange to use different authentication methods, for example the initiator may be using a shared key, while the responder may have a public signature key and certificate.

The command authmethod-remote is avilable under config vpn ipsec phase1-interface.

For more detailed information on authentication of the IKE SA, see RFC 5996 – Internet Key Exchange Protocol Version 2 (IKEv2).

IKEv2 Digital Signature Authentication support

FortiOS supports the use of Digital Signature authentication, which changes the format of the Authentication Data payload in order to support different signature methods.

Instead of just  containing a raw signature value calculated as defined in the original IKE RFCs,  the Auth Data now includes an ASN.1 formatted object that provides  details on how the signature was calculated, such as the signature type, hash algorithm, and signature padding method.

For more detailed information on IKEv2 Digital Signature authentication, see RFC 7427 – Signature Authentication in the Internet Key Exchange Version 2 (IKEv2).

Unique IKE identifiers

When enabled, the following phase1 CLI command (enforce-unique-id) requires all IPsec VPN clients to use a unique identifer when connecting.

CLI syntax

config vpn ipsec phase1 edit <name> set enforce-unique-id {keep-new | keep-old | disable} Default is disable. next

end

Use keep-new to replace the old connnection if an ID collision is detected on the gateway. Use keep-old to reject the new connection if an ID collision is detected.

IKEv2 ancillary RADIUS group authentication

This feature provides for the IDi information to be extracted from the IKEv2 AUTH exchange and sent to a RADIUS server, along with a fixed password (configurable via CLI only), to perform an additional group authentication step prior to tunnel establishment. The RADIUS server may return framed-IP-address, framed-ipnetmask, and dns-server attributes, which are then applied to the tunnel.

It should be noted, unlike Xauth or EAP, this feature does not perform individual user authentication, but rather treats all users on the gateway as a single group, and authenticates that group with RADIUS using a fixed password. This feature also works with RADIUS accounting, including the phase1 acct-verify option.

Syntax

config vpn ipsec phase1-interface edit <name> set mode-cfg enable set type dynamic set ike-version 2

set group-authentication {enable | disable} set group-authentication-secret <password>

next end

IPsec VPN overview

This section provides a brief overview of IPsec technology and includes general information about how to configure IPsec VPNs using this guide.

The following topics are included in this section:

Types of VPNs

Planning your VPN

General preparation steps

How to use this guide to configure an IPsec VPN

VPN configurations interact with the firewall component of the FortiGate unit. There must be a security policy in place to permit traffic to pass between the private network and the VPN tunnel.

Security policies for VPNs specify:

• The FortiGate interface that provides the physical connection to the remote VPN gateway, usually an interface connected to the Internet
• The FortiGate interface that connects to the private network
• IP addresses associated with data that has to be encrypted and decrypted
• Optionally, a schedule that restricts when the VPN can operate
• Optionally, the services (types of data) that can be sent

When the first packet of data that meets all of the conditions of the security policy arrives at the FortiGate unit, a VPN tunnel may be initiated and the encryption or decryption of data is performed automatically afterward. For more information, see Defining VPN security policies on page 1.

Where possible, you should create route-based VPNs. Generally, route-based VPNs are more flexible and easier to configure than policy-based VPNs — by default they are treated as interfaces. However, these two VPN types have different requirements that limit where they can be used.

Types of VPNs

FortiGate unit VPNs can be policy-based or route-based. There is little difference between the two types. In both cases, you specify Phase 1 and Phase 2 settings. However there is a difference in implementation. A route-based VPN creates a virtual IPsec network interface that applies encryption or decryption as needed to any traffic that it carries. That is why route-based VPNs are also known as interface-based VPNs. A policy-based VPN is implemented through a special security policy that applies the encryption you specified in the Phase 1 and Phase 2 settings.

Route-based VPNs

For a route-based VPN, you create two security policies between the virtual IPsec interface and the interface that connects to the private network. In one policy, the virtual interface is the source. In the other policy, the virtual interface is the destination.  This creates bidirectional policies that ensure traffic will flow in both directions over the VPN.

A route-based VPN is also known as an interface-based VPN.

overview                                                                                                                       Types of VPNs

Each route-based IPsec VPN tunnel requires a virtual IPsec interface. As such, the amount of possible route-based IPsec VPNs is limited by the system.interface table size. The system.interface table size for most devices is 8192.

For a complete list of table sizes for all devices, refer to the Maximum Values table.

Policy-based VPNs

For a policy-based VPN, one security policy enables communication in both directions.  You enable inbound and outbound traffic as needed within that policy, or create multiple policies of this type to handle different types of traffic differently. For example HTTPS traffic may not require the same level of scanning as FTP traffic.

A policy-based VPN is also known as a tunnel-mode VPN.

Comparing policy-based or route-based VPNs

For both VPN types you create Phase 1 and Phase 2 configurations. Both types are handled in the stateful inspection security layer, assuming there is no IPS or AV. For more information on the three security layers, see the FortiOS Troubleshooting guide.

The main difference is in the security policy.

You create a policy-based VPN by defining an IPSEC security policy between two network interfaces and associating it with the VPN tunnel (Phase 1) configuration.

You create a route-based VPN by creating a virtual IPsec interface. You then define a regular ACCEPT security policy to permit traffic to flow between the virtual IPsec interface and another network interface. And lastly, configure a static route to allow traffic over the VPN.

Where possible, you should create route-based VPNs. Generally, route-based VPNs are more flexible and easier to configure than policy-based VPNs — by default they are treated as interfaces. However, these two VPN types have different requirements that limit where they can be used.

Comparison of policy-based and route-based VPNs

Planning your VPN                                                                                                                   IPsec VPN overview

Planning your VPN

It is a good idea to plan the VPN configuration ahead of time. This will save time later and help you configure your VPN correctly.

All VPN configurations are comprised of numerous required and optional parameters. Before you begin, you need to determine:

• Where the IP traffic originates and where it needs to be delivered
• Which hosts, servers, or networks to include in the VPN
• Which VPN devices to include in the configuration
• Through which interfaces the VPN devices communicate
• Through which interfaces do private networks access the VPN gateways

Once you have this information, you can select a VPN topology that suits the network environment.

Network topologies

The topology of your network will determine how remote peers and clients connect to the VPN and how VPN traffic is routed.

VPN network topologies and brief descriptions

overview                                                                                                       General preparation steps

These sections contain high-level configuration guidelines with cross-references to detailed configuration procedures. If you need more detail to complete a step, select the cross-reference in the step to drill-down to more detail. Return to the original procedure to complete the procedure. For a general overview of how to configure a VPN, see Planning your VPN .

General preparation steps

A VPN configuration defines relationships between the VPN devices and the private hosts, servers, or networks making up the VPN. Configuring a VPN involves gathering and recording the following information. You will need this information to configure the VPN.

• The private IP addresses of participating hosts, servers, and/or networks. These IP addresses represent the source addresses of traffic that is permitted to pass through the VPN. A IP source address can be an individual IP address, an address range, or a subnet address.
• The public IP addresses of the VPN end-point interfaces. The VPN devices establish tunnels with each other through these interfaces.
• The private IP addresses associated with the VPN-device interfaces to the private networks. Computers on the private networks behind the VPN gateways will connect to their VPN gateways through these interfaces.

How to use this guide to configure an IPsec VPN

This guide uses a task-based approach to provide all of the procedures needed to create different types of VPN configurations. Follow the step-by-step configuration procedures in this guide to set up the VPN. The following configuration procedures are common to all IPsec VPNs:

1. Define the Phase 1 parameters that the FortiGate unit needs to authenticate remote peers or clients and establish a secure a connection. See Phase 1 parameters on page 52.
2. Define the Phase 2 parameters that the FortiGate unit needs to create a VPN tunnel with a remote peer or dialup client. See Phase 2 parameters on page 72.
3. Specify the source and destination addresses of IP packets that are to be transported through the VPN tunnel. See Defining policy addresses on page 1.

How to use this guide to configure an IPsec VPN                                                                         IPsec VPN overview

4. Create an IPsec security policy to define the scope of permitted services between the IP source and destination addresses. See Defining VPN security policies on page 1.

These steps assume you configure the FortiGate unit to generate unique IPsec encryption and authentication keys automatically. In situations where a remote VPN peer or client requires a specific IPsec encryption and authentication key, you must configure the FortiGate unit to use manual keys instead of performing Steps 1 and 2.

IPsec VPN in the web-based manager

To configure an IPsec VPN, use the general procedure below. With these steps, your FortiGate unit will automatically generate unique IPsec encryption and authentication keys. If a remote VPN peer or client requires a specific IPsec encryption or authentication key, you must configure your FortiGate unit to use manual keys instead.

1. Define Phase 1 parameters to authenticate remote peers and clients for a secure connection. See IPsec VPN in the web-based manager on page 38.
2. Define Phase 2 parameters to create a VPN tunnel with a remote peer or dialup client. See IPsec VPN in the webbased manager on page 38.
3. Create a security policy to permit communication between your private network and the VPN. Policy-based VPNs have an action of IPSEC, where for interface-based VPNs the security policy action is ACCEPT. See Defining VPN security policies on page 1.

The FortiGate unit implements the Encapsulated Security Payload (ESP) protocol. Internet Key Exchange (IKE) is performed automatically based on pre-shared keys or X.509 digital certificates. Interface mode, supported in NAT mode only, creates a virtual interface for the local end of a VPN tunnel.

This chapter contains the following sections:

Phase 1 configuration

Phase 2 configuration

Concentrator

IPsec Monitor

Phase 1 configuration

To begin defining the Phase 1 configuration, go to VPN > IPsec Tunnels and select Create New. Enter a unique descriptive name for the VPN tunnel and follow the instructions in the VPN Creation Wizard.

The Phase 1 configuration mainly defines the ends of the IPsec tunnel. The remote end is the remote gateway with which the FortiGate unit exchanges IPsec packets. The local end is the FortiGate interface that sends and receives IPsec packets.

If you want to control how the IKE negotiation is processed when there is no traffic, as well as the length of time the FortiGate unit waits for negotiations to occur, you can use the negotiation-timeout and autonegotiate commands in the CLI.

For more information, refer to  Phase 2 parameters on page 72 and Phase 2 parameters on page 72.

Phase 1 advanced configuration settings

You can use the following advanced parameters to select the encryption and authentication algorithms that the FortiGate unit uses to generate keys for the IKE exchange. You can also use the following advanced parameters to ensure the smooth operation of Phase 1 negotiations.

These settings are mainly configured in the CLI, although some options are available after the tunnel is created using the VPN Creation Wizard (using the Convert to Custom Tunnel option).

If the FortiGate unit will act as a VPN client, and you are using security certificates for authentication, set the Local ID to the distinguished name (DN) of the local server certificate that the FortiGate unit will use for authentication purposes.

Note that, since FortiOS 5.4, an exact match is required to optimize IKE’s gateway search utilizing binary trees. However, it is also possible to have partial matching of ‘user.peer:cn’ to match peers to gateways by performing a secondary match. When IKE receives IDi of type ASN1.DN, the first search is done with the whole DN string. If none is found, IKE will extract just the CN attribute value and perform a second search.

IKEv1 fragmentation

UDP fragmentation can cause issues in IPsec when either the ISP or perimeter firewall(s) cannot pass or fragment the oversized UDP packets that occur when using a very large public security key (PSK). The result is that IPsec tunnels do not come up. The solution is IKE fragmentation.

For most configurations, enabling IKE fragmentation allows connections to automatically establish when they otherwise might have failed due to intermediate nodes dropping IKE messages containing large certificates, which typically push the packet size over 1500 bytes.

FortiOS will fragment a packet on sending if, and only if, all the following are true:

• Phase 1 contains “set fragmentation enable”.
• The packet is larger than the minimum MTU (576 for IPv4, 1280 for IPv6). l The packet is being re-transmitted.

By default, IKE fragmentation is enabled, but upon upgrading, any existing phase1-interface may have have “set fragmentation disable” added in order to preserve the existing behaviour of not supporting fragmentation.

Enabling or disabling IKE fragmentation – CLI

config vpn ipsec phase1-interface edit 1 set fragmentation [enable | disable]

next

end

IKEv2 fragmentation

With IKEv2, because RFC 7383 requires each fragment to be individually encrypted and authenticated, we would have to keep a copy of the unencrypted payloads around for each outgoing packet, in case the original single packet was never answered and we wanted to retry with fragments. With the following implementation, if the IKE payloads are greater than a configured threshold, the IKE packets are preemptively fragmented and encrypted.

CLI syntax

config vpn ipsec phase1-interface edit ike set ike-version 2

set fragmentation [enable|disable] set fragmentation-mtu [500-16000]

next

end

Phase 2 configuration

After IPsec Phase 1 negotiations end successfully, you begin Phase 2. You can configure the Phase 2 parameters to define the algorithms that the FortiGate unit may use to encrypt and transfer data for the remainder of the session. During Phase 2, you select specific IPsec security associations needed to implement security services and establish a tunnel.

The basic Phase 2 settings associate IPsec Phase 2 parameters with the Phase 1 configuration that specifies the remote end point of the VPN tunnel. In most cases, you need to configure only basic Phase 2 settings.

2

These settings are mainly configured in the CLI, although some options are available after the tunnel is created using the VPN Creation Wizard (using the Convert to Custom Tunnel option).

Phase 2 advanced configuration settings

In Phase 2, the FortiGate unit and the VPN peer or client exchange keys again to establish a secure communication channel between them. You select the encryption and authentication algorithms needed to generate keys for protecting the implementation details of Security Associations (SAs). These are called Phase 2 Proposal parameters. The keys are generated automatically using a Diffie-Hellman algorithm.

You can use a number of additional advanced Phase 2 settings to enhance the operation of the tunnel.

2

FortiClient VPN

Use the FortiClient VPN for OS X, Windows, and Android VPN Wizard option when configuring an IPsec VPN for remote users to connect to the VPN tunnel using FortiClient.

When configuring a FortiClient VPN connection, the settings for Phase 1 and Phase 2 settings are automatically configured by the FortiGate unit. They are set to:

• Remote Gateway — Dialup User
• Mode — Aggressive
• Default settings for Phase 1 and 2 Proposals
• XAUTH Enable as Server (Auto)
• IKE mode-config will be enabled
• Peer Option — “Any peer ID”

The remainder of the settings use the current FortiGate defaults. Note that FortiClient settings need to match these FortiGate defaults. If you need to configure advanced settings for the FortiClient VPN, you must do so using the CLI.

Concentrator

Concentrator

In a hub-and-spoke configuration, policy-based VPN connections to a number of remote peers radiate from a single, central FortiGate unit. Site-to-site connections between the remote peers do not exist; however, you can establish VPN tunnels between any two of the remote peers through the FortiGate unit’s “hub”.

In a hub-and-spoke network, all VPN tunnels terminate at the hub. The peers that connect to the hub are known as “spokes”. The hub functions as a concentrator on the network, managing all VPN connections between the spokes. VPN traffic passes from one tunnel to the other through the hub.

You define a concentrator to include spokes in the hub-and-spoke configuration. You create the concentrator in VPN > IPsec Concentrator and select Create New. A concentrator configuration specifies which spokes to include in an IPsec hub-and-spoke configuration.

IPsec Monitor

You can use the IPsec Monitor to view activity on IPsec VPN tunnels and start or stop those tunnels. The display provides a list of addresses, proxy IDs, and timeout information for all active tunnels, including tunnel mode and route-based (interface mode) tunnels.

To view the IPsec monitor, go to Monitor > IPsec Monitor.

Tunnels are considered as “up” if at least one phase 2 selector is active. To avoid confusion, when a tunnel is down, IPsec Monitor will keep the Phase 2 Selectors column, but hide it by default and be replaced with Phase 1 status column.

IPsec Monitor

For dialup VPNs, the list provides status information about the VPN tunnels established by dialup clients, and their IP addresses.

For static IP or dynamic DNS VPNs, the list provides status and IP addressing information about VPN tunnels, active or not, to remote peers that have static IP addresses or domain names. You can also start and stop individual tunnels from the list.

Introduction

This document provides the following information for FortiOS 5.4.6 build 1165:

l Special Notices l Upgrade Information l Product Integration and Support l Resolved Issues l Known Issues l Limitations

See the Fortinet Document Library for FortiOS documentation.

Supported models

FortiOS 5.4.6 supports the following models.

Introduction                                                                                                                              Supported models

Special branch supported models

The following models are released on a special branch of FortiOS 5.4.6. To confirm that you are running the correct build, run the CLI command get system status and check that the Branch point field shows 1165.

What’s new in FortiOS 5.4.6                                                                                                                Introduction

What’s new in FortiOS 5.4.6

For a detailed list of new features and enhancements that have been made in FortiOS 5.4.6, see the What’s New forFortiOS 5.4.6 document available in the Fortinet Document Library.

Special Notices

Built-In Certificate

FortiGate and FortiWiFi D-series and above have a built in Fortinet_Factory certificate with an RSA 2048-bit key; and FortiOS supports DH group 14 for key-exchange.

Default log setting change

For FG-5000 blades, log disk is disabled by default. It can only be enabled via CLI. For all 2U & 3U models (FG-3600/FG-3700/FG-3800), log disk is also disabled by default. For all 1U models and desktop models that supports SATA disk, log disk is enabled by default.

FortiAnalyzer Support

In version 5.4, encrypting logs between FortiGate and FortiAnalyzer is handled via SSL encryption. The IPsec option is no longer available and users should reconfigure in GUI or CLI to select the SSL encryption option as needed.

Removed SSL/HTTPS/SMTPS/IMAPS/POP3S

SSL/HTTPS/SMTPS/IMAPS/POP3S options were removed from server-load-balance on low end models below FG-100D except FG-80C and FG-80CM.

FortiGate and FortiWiFi-92D Hardware Limitation

FortiOS 5.4.0 reported an issue with the FG-92D model in the Special Notices > FG-92D High Availability in Interface Mode section of the release notes. Those issues, which were related to the use of port 1 through 14, include:

• PPPoE failing, HA failing to form l IPv6 packets being dropped l FortiSwitch devices failing to be discovered
• Spanning tree loops may result depending on the network topology

FG-92D and FWF-92D do not support STP. These issues have been improved in FortiOS 5.4.1, but with some side effects with the introduction of a new command, which is enabled by default:

config system global set hw-switch-ether-filter <enable | disable>

FG-900D and FG-1000D                                                                                                               Special Notices

When the command is enabled:

• ARP (0x0806), IPv4 (0x0800), and VLAN (0x8100) packets are allowed l BPDUs are dropped and therefore no STP loop results l PPPoE packets are dropped l IPv6 packets are dropped l FortiSwitch devices are not discovered l HA may fail to form depending the network topology

When the command is disabled:

• All packet types are allowed, but depending on the network topology, an STP loop may result

FG-900D and FG-1000D

CAPWAP traffic will not offload if the ingress and egress traffic ports are on different NP6 chips. It will only offload if both ingress and egress ports belong to the same NP6 chip.

FG-3700DX

CAPWAP Tunnel over the GRE tunnel (CAPWAP + TP2 card) is not supported.

FortiGate units managed by FortiManager 5.0 or 5.2

Any FortiGate unit managed by FortiManager 5.0.0 or 5.2.0 may report installation failures on newly created VDOMs, or after a factory reset of the FortiGate unit even after a retrieve and re-import policy.

FortiClient Support

Only FortiClient 5.4.1 and later is supported with FortiOS 5.4.1 and later. Upgrade managed FortiClients to 5.4.1 or later before upgrading FortiGate to 5.4.1 or later.

Consider the FortiClient license before upgrading. Full featured FortiClient 5.2 and 5.4 licenses will carry over into FortiOS 5.4.1 and later. Depending on your organization’s needs, you might need to purchase a FortiClient EMS license for endpoint provisioning. Contact your sales representative for guidance on the appropriate licensing for your organization.

The perpetual FortiClient 5.0 license (including the 5.2 limited feature upgrade) will not carry over into FortiOS 5.4.1 and later. You need to purchase a new license for either FortiClient EMS or FortiGate. A license is compatible with 5.4.1 and later if the SKU begins with FC-10-C010.

Special Notices                                                                                FortiClient (Mac OS X) SSL VPN Requirements

FortiClient (Mac OS X) SSL VPN Requirements

When using SSL VPN on Mac OS X 10.8, you must enable SSLv3 in FortiOS.

FortiGate-VM 5.4 for VMware ESXi

Upon upgrading to FortiOS 5.4.6, FortiGate-VM v5.4 for VMware ESXi (all models), no longer supports the VMXNET2 vNIC driver.

FortiClient Profile Changes

With introduction of the Cooperative Security Fabric in FortiOS, FortiClient profiles will be updated on FortiGate. FortiClient profiles and FortiGate are now primarily used for Endpoint Compliance, and FortiClient Enterprise Management Server (EMS) is now used for FortiClient deployment and provisioning.

In the FortiClient profile on FortiGate, when you set the Non-Compliance Action setting to Auto-Update, the

FortiClient profile supports limited provisioning for FortiClient features related to compliance, such as AntiVirus,

Web Filter, Vulnerability Scan, and Application Firewall. When you set the Non-Compliance Action setting to Block or Warn, you can also use FortiClient EMS to provision endpoints, if they require additional other features, such as VPN tunnels or other advanced options. For more information, see the FortiOS Handbook – Security

Profiles.

When you upgrade to FortiOS 5.4.1 and later, the FortiClient provisioning capability will no longer be available in FortiClient profiles on FortiGate. FortiGate will be used for endpoint compliance and Cooperative Security Fabric integration, and FortiClient Enterprise Management Server (EMS) should be used for creating custom FortiClient installers as well as deploying and provisioning FortiClient on endpoints. For more information on licensing of EMS, contact your sales representative.

FortiPresence

FortiPresence users must change the FortiGate web administration TLS version in order to allow the connections on all versions of TLS. Use the following CLI command.

config system global set admin-https-ssl-versions tlsv1-0 tlsv1-1 tlsv1-2

end

Log Disk Usage

Users are able to toggle disk usage between Logging and WAN Optimization for single disk FortiGates.

To view a list of supported FortiGate models, refer to the FortiOS 5.4.0 Feature Platform Matrix.

SSL VPN setting page                                                                                                                   Special Notices

SSL VPN setting page

The default server certificate has been changed to the Fortinet_Factory option. This excludes FortiGateVMs which remain at the self-signed option. For details on importing a CA signed certificate, please see the How to purchase and import a signed SSL certificate document.

FG-30E-3G4G and FWF-30E-3G4G MODEM Firmware Upgrade

The 3G4G MODEM firmware on the FG-30E-3G4G and FWF-30E-3G4G models may require updating. Upgrade instructions and the MODEM firmware have been uploaded to the Fortinet CustomerService & Support site.

Log in and go to Download > Firmware. In the Select Product list, select FortiGate, and click the Download tab. The upgrade instructions are in the following directory:

…/FortiGate/v5.00/5.4/Sierra-Wireless-3G4G-MODEM-Upgrade/

Use of dedicated management interfaces (mgmt1 and mgmt2)

For optimum stability, use management ports (mgmt1 and mgmt2) for management traffic only. Do not use management ports for general user traffic.

DLP, AV

In 5.2, Block page was sent to client with HTTP status code 200 by default. In 5.4 and later, Block page is sent to client with a clearer HTTP status code of 403 Forbidden.

Upgrade Information

Upgrading to FortiOS 5.4.6

FortiOS version 5.4.6 officially supports upgrading from version 5.4.4 and later, and 5.2.10 and later.

When upgrading from a firmware version beyond those mentioned in the Release Notes, a recommended guide for navigating the upgrade path can be found on the Fortinet documentation site.

There is a separate version of the guide describing the safest upgrade path to the latest patch of each of the supported versions of the firmware. To upgrade to this build, go to FortiOS 5.4 Supported Upgrade Paths.

Upgrading to FortiOS 5.6.0

Cooperative Security Fabric Upgrade

FortiOS 5.4.1 and later greatly increases the interoperability between other Fortinet products. This includes:

• FortiClient 5.4.1 and later l FortiClient EMS 1.0.1 and later l FortiAP 5.4.1 and later l FortiSwitch 3.4.2 and later

The upgrade of the firmware for each product must be completed in a precise order so the network connectivity is maintained without the need of manual steps. Customers must read the following two documents prior to upgrading any product in their network:

• Cooperative Security Fabric – Upgrade Guide
• FortiOS 5.4.x Upgrade Guide for Managed FortiSwitch Devices

This document is available in the Customer Support Firmware Images download directory for FortiSwitch 3.4.2.

FortiGate-VM 5.4 for VMware ESXi                                                                                          Upgrade Information

FortiGate-VM 5.4 for VMware ESXi

Upon upgrading to FortiOS 5.4.6, FortiGate-VM v5.4 for VMware ESXi (all models), no longer supports the VMXNET2 vNIC driver.

Downgrading to previous firmware versions

Downgrading to previous firmware versions results in configuration loss on all models. Only the following settings are retained:

l operation mode l interface IP/management IP l static route table l DNS settings l VDOM parameters/settings l admin user account l session helpers l system access profiles

When downgrading from 5.4 to 5.2, users will need to reformat the log disk.

Amazon AWS Enhanced Networking Compatibility Issue

Due to this new enhancement, there is a compatibility issue with older AWS VM versions. After downgrading a 5.4.1 or later image to an older version, network connectivity is lost. Since AWS does not provide console access, you cannot recover the downgraded image.

Downgrading to older versions from 5.4.1 or later running the enhanced nic driver is not allowed. The following AWS instances are affected:

• C3 l C4 l R3 l I2
• M4 l D2

Upgrade Information                                                                                                             FortiGate VM firmware

FortiGate VM firmware

Fortinet provides FortiGate VM firmware images for the following virtual environments:

Citrix XenServer and Open Source XenServer

• .out: Download the 64-bit firmware image to upgrade your existing FortiGate VM installation.
• .out.OpenXen.zip: Download the 64-bit package for a new FortiGate VM installation. This package contains the QCOW2 file for Open Source XenServer.
• .out.CitrixXen.zip: Download the 64-bit package for a new FortiGate VM installation. This package contains the Citrix XenServer Virtual Appliance (XVA), Virtual Hard Disk (VHD), and OVF files.

Linux KVM

• .out: Download the 64-bit firmware image to upgrade your existing FortiGate VM installation.
• .out.kvm.zip: Download the 64-bit package for a new FortiGate VM installation. This package contains QCOW2 that can be used by qemu.

Microsoft Hyper-V

• .out: Download the 64-bit firmware image to upgrade your existing FortiGate VM installation.
• .out.hyperv.zip: Download the 64-bit package for a new FortiGate VM installation. This package contains three folders that can be imported by Hyper-V Manager on Hyper-V 2012. It also contains the file vhd in the Virtual Hard Disks folder that can be manually added to the Hyper-V Manager.

VMware ESX and ESXi

• .out: Download either the 64-bit firmware image to upgrade your existing FortiGate VM installation.
• .ovf.zip: Download either the 64-bit package for a new FortiGate VM installation. This package contains Open Virtualization Format (OVF) files for VMware and two Virtual Machine Disk Format (VMDK) files used by the OVF file during deployment.

Firmware image checksums

The MD5 checksums for all Fortinet software and firmware releases are available at the Customer Service & Support portal, https://support.fortinet.com. After logging in select Download > Firmware Image Checksums, enter the image file name including the extension, and select Get Checksum Code.

Product Integration and Support

FortiOS 5.4.6 support

The following table lists 5.4.6 product integration and support information:

FortiOS 5.4.6

FortiOS 5.4.6 support                                                                                             Product Integration and Support

Language

Language support

The following table lists language support information.

Language support

SSL VPN support

SSL VPN standalone client

The following table lists SSL VPN tunnel client standalone installer for the following operating systems.

Operating system and installers

Other operating systems may function correctly, but are not supported by Fortinet.

SSL VPN support                                                                                                  Product Integration and Support

SSL VPN web mode

The following table lists the operating systems and web browsers supported by SSL VPN web mode.

Supported operating systems and web browsers

Other operating systems and web browsers may function correctly, but are not supported by Fortinet.

SSL VPN host compatibility list

It is recommended to verify the accuracy of the GUID for the software you are using for SSLVPN host check. The following Knowledge Base article at http://kb.fortinet.com/ describes how to identify the GUID for antivirus and firewall products: How to add non listed 3rd Party AntiVirus and Firewall product to the FortiGate SSL VPN Host check.

After verifying GUIDs, you can update GUIDs in FortiOS by using this command: config vpn ssl web host-check-software

SSL VPN

Following is an example of how to update the GUID for AVG Internet Security 2017 on Windows 7 and Windows 10 by using the FortiOS CLI.

To update GUIDs in FortiOS:

1. Use the config vpn ssl web host-check-software command to edit the AVG-InternetSecurity-AV variable to set the following GUID for AVG Internet Security 2017:

4D41356F-32AD-7C42-C820-63775EE4F413

2. Edit the AVG-Internet-Security-FW variable to set the following GUID: 757AB44A-78C2-7D1A-E37F-CA42A037B368

Resolved Issues

The following issues have been fixed in version 5.4.6. For inquires about a particular bug, please contact CustomerService & Support.

AntiVirus

DNS Filter

Firewall

FortiGate-60D

FortiGate-5001D

FortiGate and FortiWifi E Series

FortiSwitch

GUI

HA

IPS

IPsec VPN

Logging & Report

Router

Spam

SSL VPN

System

Upgrade

User and FSSO

VM

VoIP

Web Filter

WebProxy

WiFi

Common Vulnerabilities and Exposures

Known Issues

The following issues have been identified in version 5.4.6. For inquires about a particular bug or to report a bug, please contact CustomerService & Support.

AntiVirus

Endpoint Control

Firewall

FortiGate-3815D

FortiRugged-60D

Known

FortiSwitch-Controller/FortiLink

FortiView

GUI

Known Issues

Known

HA

IPsec

Router

SSL VPN

Known Issues

System

Upgrade

Visibility

VM

Limitations

Citrix XenServer limitations

The following limitations apply to Citrix XenServer installations:

• XenTools installation is not supported.
• FortiGate-VM can be imported or deployed in only the following three formats:
• XVA (recommended) l VHD l OVF
• The XVA format comes pre-configured with default configurations for VM name, virtual CPU, memory, and virtual NIC. Other formats will require manual configuration before the first power on process.

Open Source XenServer limitations

When using Linux Ubuntu version 11.10, XenServer version 4.1.0, and libvir version 0.9.2, importing issues may arise when using the QCOW2 format and existing HDA issues.

Phase 1 parameters

This chapter provides detailed step-by-step procedures for configuring a FortiGate unit to accept a connection from a remote peer or dialup client. The Phase 1 parameters identify the remote peer or clients and supports authentication through preshared keys or digital certificates. You can increase access security further using peer identifiers, certificate distinguished names, group names, or the FortiGate extended authentication (XAuth) option for authentication purposes.

For more information on Phase 1 parameters in the web-based manager, see IPsec VPN in the web-based manager on page 38.

The information and procedures in this section do not apply to VPN peers that perform negotiations using manual keys.

The following topics are included in this section:

Overview

Defining the tunnel ends

Choosing Main mode or Aggressive mode

Choosing the IKE version

Authenticating the FortiGate unit

Authenticating remote peers and clients

Defining IKE negotiation parameters

Using XAuth authentication

Dynamic IPsec route control

Overview

To configure IPsec Phase 1 settings, go to VPN > IPsec Tunnels and edit the Phase 1 Proposal (if it is not available, you may need to click the Convert to Custom Tunnel button).

IPsec Phase 1 settings define:

• The remote and local ends of the IPsec tunnel
• If Phase 1 parameters are exchanged in multiple rounds with encrypted authentication information (main mode) or in a single message with authentication information that is not encrypted (aggressive mode)
• If a preshared key or digital certificates will be used to authenticate the FortiGate unit to the VPN peer or dialup client
• If the VPN peer or dialup client is required to authenticate to the FortiGate unit. A remote peer or dialup client can authenticate by peer ID or, if the FortiGate unit authenticates by certificate, it can authenticate by peer certificate.
• The IKE negotiation proposals for encryption and authentication
• Optional XAuth authentication, which requires the remote user to enter a user name and password. A FortiGate VPN server can act as an XAuth server to authenticate dialup users. A FortiGate unit that is a dialup client can also be configured as an XAuth client to authenticate itself to the VPN server.

For all the Phase 1 web-based manager fields, see IPsec VPN in the web-based manager on page 38.

Defining the tunnel ends

If you want to control how IKE is negotiated when there is no traffic, as well as the length of time the unit waits for negotiations to occur, use the negotiation-timeout and auto-negotiate commands in the CLI.

Defining the tunnel ends

To begin defining the Phase 1 configuration, go to VPN > IPsec Tunnels and select Create New. Enter a unique descriptive name for the VPN tunnel and follow the instructions in the VPN Creation Wizard.

The Phase 1 configuration mainly defines the ends of the IPsec tunnel. The remote end is the remote gateway with which the FortiGate unit exchanges IPsec packets. The local end is the FortiGate interface that sends and receives IPsec packets.

The remote gateway can be:

• A static IP address
• A domain name with a dynamic IP address
• A dialup client

A statically addressed remote gateway is the simplest to configure. You specify the IP address. Unless restricted in the security policy, either the remote peer or a peer on the network behind the FortiGate unit can bring up the tunnel.

If the remote peer has a domain name and subscribes to a dynamic DNS service, you need to specify only the domain name. The FortiGate unit performs a DNS query to determine the appropriate IP address. Unless restricted in the security policy, either the remote peer or a peer on the network behind the FortiGate unit can bring up the tunnel.

If the remote peer is a dialup client, only the dialup client can bring up the tunnel. The IP address of the client is not known until it connects to the FortiGate unit. This configuration is a typical way to provide a VPN for client PCs running VPN client software such as the FortiClient Endpoint Security application.

The local end of the VPN tunnel, the Local Interface, is the FortiGate interface that sends and receives the IPsec packets. This is usually the public interface of the FortiGate unit that is connected to the Internet (typically the WAN1 port). Packets from this interface pass to the private network through a security policy.

By default, the local VPN gateway is the IP address of the selected Local Interface. If you are configuring an interface mode VPN, you can optionally use a secondary IP address of the Local Interface as the local gateway.

Choosing Main mode or Aggressive mode

The FortiGate unit and the remote peer or dialup client exchange Phase 1 parameters in either Main mode or Aggressive mode. This choice does not apply if you use IKE version 2, which is available only for route-based configurations.

• In Main mode, the Phase 1 parameters are exchanged in multiple rounds with encrypted authentication information
• In Aggressive mode, the Phase 1 parameters are exchanged in a single message with unencrypted authentication information.

Although Main mode is more secure, you must select Aggressive mode if there is more than one dialup Phase 1 configuration for the interface IP address, and the remote VPN peer or client is authenticated using an identifier local ID. Aggressive mode might not be as secure as Main mode, but the advantage to Aggressive mode is that it Choosing the IKE version

is faster than Main mode (since fewer packets are exchanged). Aggressive mode is typically used for remote access VPNs. But you would also use aggressive mode if one or both peers have dynamic external IP addresses. Descriptions of the peer options in this guide indicate whether Main or Aggressive mode is required.

Choosing the IKE version

If you create a route-based VPN, you have the option of selecting IKE version 2. Otherwise, IKE version 1 is used. IKEv2, defined in RFC 4306, simplifies the negotiation process that creates the security association (SA). If you select IKEv2:

• There is no choice in Phase 1 of Aggressive or Main mode. l FortiOS does not support Peer Options or Local ID.
• Extended Authentication (XAUTH) is not available. l You can select only one Diffie-Hellman Group.  l You can utilize EAP and MOBIKE.

Repeated authentication in IKEv2

This feature provides the option to control whether a device requires its peer to re-authenticate or whether re-key is sufficient. It does not influence the re-authentication or re-key behavior of the device itself, which is controlled by the peer (with the default being to re-key). This solution is in response to RFC 4478. As described by the IETF, “the purpose of this is to limit the time that security associations (SAs) can be used by a third party who has gained control of the IPsec peer”.

Syntax

config vpn ipsec phase1-interface edit p1 set reauth [enable | disable]

next

end

IKEv2 cookie notification for IKE_SA_INIT

IKEv2 offers an optional exchange within IKE_SA_INIT (the initial exchange between peers when establishing a secure tunnel) as a result of an inherent vulnerability in IPsec implementations, as described in RFC 5996.

Two expected attacks against IKE are state and CPU exhaustion, where the target is flooded with session initiation requests from forged IP addresses. These attacks can be made less effective if a responder uses minimal CPU and commits no state to an SA until it knows the initiator can receive packets at the address from which it claims to be sending them.

If the IKE_SA_INIT response includes the cookie notification, the initiator MUST then retry the IKE_SA_INIT request, and include the cookie notification containing the received data as the first payload, and all other payloads unchanged.

Upon detecting that the number of half-open IKEv2 SAs is above the threshold value, the VPN dialup server requires all future SA_INIT requests to include a valid cookie notification payload that the server sends back, in order to preserve CPU and memory resources.

the FortiGate unit

For most devices, the threshold value is set to 500, half of the maximum 1,000 connections.

This feature is enabled by default in FortiOS 5.4.

IKEv2 Quick Crash Detection

There is support for IKEv2 Quick Crash Detection (QCD) as described in RFC 6290.

RFC 6290 describes a method in which an IKE peer can quickly detect that the gateway peer that it has and established an IKE session with has rebooted, crashed, or otherwise lost IKE state. When the gateway receives IKE messages or ESP packets with unknown IKE or IPsec SPIs, the IKEv2 protocol allows the gateway to send the peer an unprotected IKE message containing INVALID_IKE_SPI or INVALID_SPI notification payloads.

RFC 6290 introduces the concept of a QCD token, which is generated from the IKE SPIs and a private QCD secret, and exchanged between peers during the protected IKE AUTH exchange.

Adding Quick Crash Detection – CLI Syntax

config system settings set ike-quick-crash-detect [enable | disable]

end

IKEv1 Quick Crash Detection

Based on the IKEv2 QCD feature described above, IKEv1 QCD is implemented using a new IKE vendor ID,

“Fortinet Quick Crash Detection”, and so both endpoints must be FortiGate devices. The QCD token is sent in the Phase 1 exchange and must be encrypted, so this is only implemented for IKEv1 in Main mode (Aggressive mode is not supported as there is no available AUTH message in which to include the token).

Otherwise, the feature works the same as in IKEv2 (RFC 6290).

Authenticating the FortiGate unit

The FortiGate unit can authenticate itself to remote peers or dialup clients using either a pre-shared key or an RSA Signature (certificate).

Authenticating the FortiGate unit with digital certificates

To authenticate the FortiGate unit using digital certificates, you must have the required certificates installed on the remote peer and on the FortiGate unit. The signed server certificate on one peer is validated by the presence of the root certificate installed on the other peer. If you use certificates to authenticate the FortiGate unit, you can also require the remote peers or dialup clients to authenticate using certificates.

For more information about obtaining and installing certificates, see the FortiOS User Authentication guide.

Authenticating the FortiGate unit using digital certificates

1. Go to VPN > IPsec Tunnels and create the new custom tunnel or edit an existing tunnel.
2. Edit the Phase 1 Proposal (if it is not available, you may need to click the Convert to Custom Tunnel button):

Authenticating the FortiGate unit

3. If you are configuring authentication parameters for a dialup user group, optionally define extended authentication (XAuth) parameters in the Advanced section. See Authenticating the FortiGate unit on page 55. Select OK.

the FortiGate unit

Authenticating the FortiGate unit with a pre-shared key

The simplest way to authenticate a FortiGate unit to its remote peers or dialup clients is by means of a pre-shared

key. This is less secure than using certificates, especially if it is used alone, without requiring peer IDs or extended authentication (XAuth). Also, you need to have a secure way to distribute the pre-shared key to the peers.

If you use pre-shared key authentication alone, all remote peers and dialup clients must be configured with the same pre-shared key. Optionally, you can configure remote peers and dialup clients with unique pre-shared keys. On the FortiGate unit, these are configured in user accounts, not in the phase_1 settings. For more information, see Authenticating the FortiGate unit on page 55.

The pre-shared key must contain at least 6 printable characters and best practices dictate that it be known only to network administrators. For optimum protection against currently known attacks, the key must consist of a minimum of 16 randomly chosen alphanumeric characters.

If you authenticate the FortiGate unit using a pre-shared key, you can require remote peers or dialup clients to authenticate using peer IDs, but not client certificates.

Authenticating the FortiGate unit with a pre-shared key

1. Go to VPN > IPsec Tunnels and create the new custom tunnel or edit an existing tunnel.
2. Edit the Phase 1 Proposal (if it is not available, you may need to click the Convert to Custom Tunnel button):

3. If you are configuring authentication parameters for a dialup user group, optionally define extended authentication (XAuth) parameters. See Authenticating the FortiGate unit on page 55.
4. Select OK.

Authenticating remote peers and clients

Certificates or pre-shared keys restrict who can access the VPN tunnel, but they do not identify or authenticate the remote peers or dialup clients. You have the following options for authentication:

Methods of authenticating remote VPN peers

remote peers and clients

Repeated Authentication in Internet Key Exchange (IKEv2) Protocol

This feature provides the option to control whether a device requires its peer to re-authenticate or whether re-key is sufficient. It does not influence the re-authentication or re-key behavior of the device itself, which is controlled by the peer (with the default being to re-key).

This solution is in response to RFC 4478. This solution is intended to limit the time that security associations (SAs) can be used by a third party who has gained control of the IPsec peer.

CLI Syntax:

config vpn ipsec phase1-interface edit p1 set reauth [enable | disable]

next

end

disable: Disable IKE SA re-authentication. enable: Enable IKE SA re-authentication.

Enabling VPN access for specific certificate holders

When a VPN peer or dialup client is configured to authenticate using digital certificates, it sends the Distinguished Name (DN) of its certificate to the FortiGate unit. This DN can be used to allow VPN access for the certificate holder. That is, a FortiGate unit can be configured to deny connections to all remote peers and dialup clients except the one having the specified DN.

Before you begin

The following procedures assume that you already have an existing Phase 1 configuration (see Authenticating remote peers and clients on page 58). Follow the procedures below to add certificate-based authentication parameters to the existing configuration.

Before you begin, you must obtain the certificate DN of the remote peer or dialup client. If you are using the FortiClient application as a dialup client, refer to FortiClient online help for information about how to view the certificate DN. To view the certificate DN of a FortiGate unit, see Viewing server  certificate information and obtaining the local DN  on page 60.

Use the config user peer CLI command to load the DN value into the FortiGate configuration. For example, if a remote VPN peer uses server certificates issued by your own organization, you would enter information similar to the following:

config user peer edit DN_FG1000 set cn 192.168.2.160 set cn-type ipv4

end

The value that you specify to identify the entry (for example, DN_FG1000) is displayed in the Accept this peer certificate only list in the IPsec Phase 1 configuration when you return to the web-based manager.

If the remote VPN peer has a CA-issued certificate to support a higher level of credibility, you would enter information similar to the following in the CLI:

config user peer edit CA_FG1000 set ca CA_Cert_1 set subject FG1000_at_site1

end

The value that you specify to identify the entry (for example, CA_FG1000) is displayed in the Accept this peer certificate only list in the IPsec Phase 1 configuration when you return to the web-based manager. For more information about these CLI commands, see the “user” chapter of the FortiGate CLI Reference.

A group of certificate holders can be created based on existing user accounts for dialup clients. To create the user accounts for dialup clients, see the “User” chapter of the FortiGate Administration Guide. To create the certificate group afterward, use the config user peergrp CLI command. See the “user” chapter of the FortiGate CLI Reference.

Viewing server  certificate information and obtaining the local DN

1. Go to System > Certificates.
2. Note the CN value in the Subject field (for example, CN = 172.16.10.125, CN = info@fortinet.com, or CN = www.example.com).

Viewing CA root certificate information and obtaining the CA certificate name

1. Go to System > Certificates > CA Certificates.
2. Note the value in the Name column (for example, CA_Cert_1).

Configuring certificate authentication for a VPN

With peer certificates loaded, peer users and peer groups defined, you can configure your VPN to authenticate users by certificate.

Enabling access for a specific certificate holder or a group of certificate holders

1. At the FortiGate VPN server, go to VPN > IPsec Tunnels and create the new custom tunnel or edit an existing tunnel.
2. Edit the Phase 1 Proposal (if it is not available, you may need to click the Convert to Custom Tunnel button).
3. From the Authentication Method list, select RSA Signature.
4. From the Certificate Name list, select the name of the server certificate that the FortiGate unit will use to authenticate itself to the remote peer or dialup client Under Peer Options, select one of these options:
   • To accept a specific certificate holder, select Accept this peer certificate only and select the name of the certificate that belongs to the remote peer or dialup client. The certificate DN must be added to the FortiGate configuration through CLI commands before it can be selected here. See Before you begin on page 59.
   • To accept dialup clients who are members of a certificate group, select Accept this peer certificate group only and select the name of the group. The group must be added to the FortiGate configuration through CLI commands before it can be selected here. See Before you begin on page 59.
5. If you want the FortiGate VPN server to supply the DN of a local server certificate for authentication purposes, select Advanced and then from the Local ID list, select the DN of the certificate that the FortiGate VPN server is to use.
6. Select OK.

remote peers and clients

Enabling VPN access by peer identifier

Whether you use certificates or pre-shared keys to authenticate the FortiGate unit, you can require that remote peers or clients have a particular peer ID. This adds another piece of information that is required to gain access to the VPN. More than one FortiGate/FortiClient dialup client may connect through the same VPN tunnel when the dialup clients share a preshared key and assume the same identifier.

A peer ID, also called local ID, can be up to 63 characters long containing standard regular expression characters. Local ID is set in phase1 Aggressive Mode configuration.

You cannot require a peer ID for a remote peer or client that uses a pre-shared key and has a static IP address.

Authenticating remote peers or dialup clients using one peer ID

1. At the FortiGate VPN server, go to VPN > IPsec Tunnels and create the new custom tunnel or edit an existing tunnel.
2. Edit the Phase 1 Proposal (if it is not available, you may need to click the Convert to Custom Tunnel button).
3. Select Aggressive mode in any of the following cases:
   • The FortiGate VPN server authenticates a FortiGate dialup client that uses a dedicated tunnel
   • A FortiGate unit has a dynamic IP address and subscribes to a dynamic DNS service
   • FortiGate/FortiClient dialup clients sharing the same preshared key and local ID connect through the same VPN tunnel
4. For the Peer Options, select This peer ID and type the identifier into the corresponding field.
5. Select OK.

Assigning an identifier (local ID) to a FortiGate unit

Use this procedure to assign a peer ID to a FortiGate unit that acts as a remote peer or dialup client.

1. Go to VPN > IPsec Tunnels and create the new custom tunnel or edit an existing tunnel.
2. Edit the Phase 1 Proposal (if it is not available, you may need to click the Convert to Custom Tunnel button).
3. Select Advanced.
4. In the Local ID field, type the identifier that the FortiGate unit will use to identify itself.
5. Set Mode to Aggressive if any of the following conditions apply:
   • The FortiGate unit is a dialup client that will use a unique ID to connect to a FortiGate dialup server through a dedicated tunnel.
   • The FortiGate unit has a dynamic IP address, subscribes to a dynamic DNS service, and will use a unique ID to connect to the remote VPN peer through a dedicated tunnel.
   • The FortiGate unit is a dialup client that shares the specified ID with multiple dialup clients to connect to a FortiGate dialup server through the same tunnel.
6. Select OK.

Configuring the FortiClient application

Follow this procedure to add a peer ID to an existing FortiClient configuration:

1. Start the FortiClient application.
2. Go to VPN > Connections, select the existing configuration.
3. Select Advanced > Edit > Advanced.
4. Under Policy, select Config.
5. In the Local ID field, type the identifier that will be shared by all dialup clients. This value must match the This peer ID value that you specified previously in the Phase 1 gateway configuration on the FortiGate unit.
6. Select OK to close all dialog boxes.
7. Configure all dialup clients the same way using the same preshared key and local ID.

Enabling VPN access with user accounts and pre-shared keys

You can permit access only to remote peers or dialup clients that have pre-shared keys and/or peer IDs configured in user accounts on the FortiGate unit.

If you want two VPN peers (or a FortiGate unit and a dialup client) to accept reciprocal connections based on peer IDs, you must enable the exchange of their identifiers when you define the Phase 1 parameters.

The following procedures assume that you already have an existing Phase 1 configuration (see Authenticating remote peers and clients on page 58). Follow the procedures below to add ID checking to the existing configuration.

Before you begin, you must obtain the identifier (local ID) of the remote peer or dialup client. If you are using the

FortiClient Endpoint Security application as a dialup client, refer to the Authenticating FortiClient Dialup Clients Technical Note to view or assign an identifier. To assign an identifier to a FortiGate dialup client or a FortiGate unit that has a dynamic IP address and subscribes to a dynamic DNS service, see Assigning an identifier (local ID) to a FortiGate unit  on page 61.

If required, a dialup user group can be created from existing user accounts for dialup clients. To create the user accounts and user groups, see the User Authentication handbook chapter.

The following procedure supports FortiGate/FortiClient dialup clients that use unique preshared keys and/or peer IDs. The client must have an account on the FortiGate unit and be a member of the dialup user group.

The dialup user group must be added to the FortiGate configuration before it can be selected. For more information, see the User Authentication handbook chapter.

The FortiGate dialup server compares the local ID that you specify at each dialup client to the FortiGate useraccount user name. The dialup-client preshared key is compared to a FortiGate user-account password.

Authenticating dialup clients using unique preshared keys and/or peer IDs

1. At the FortiGate VPN server, go to VPN > IPsec Tunnels and create the new custom tunnel or edit an existing tunnel.
2. Edit the Phase 1 Proposal (if it is not available, you may need to click the Convert to Custom Tunnel button).
3. If the clients have unique peer IDs, set Mode to Aggressive.
4. Clear the Pre-shared Key

The user account password will be used as the preshared key.

5. Select Peer ID from dialup group and then select the group name from the list of user groups. Select OK.

Follow this procedure to add a unique pre-shared key and unique peer ID to an existing FortiClient configuration.

Configuring FortiClient – pre-shared key and peer ID

1. Start the FortiClient Endpoint Security application.
2. Go to VPN > Connections, select the existing configuration. Select Advanced > Edit.
3. In the Preshared Key field, type the FortiGate password that belongs to the dialup client (for example,

1234546).

The user account password will be used as the preshared key.  5. Select Advanced.

6. Under Policy, select Config.
7. In the Local ID field, type the FortiGate user name that you assigned previously to the dialup client (for example, FortiC1ient1).
8. Select OK to close all dialog boxes.

Configure all FortiClient dialup clients this way using unique preshared keys and local IDs.

Follow this procedure to add a unique pre-shared key to an existing FortiClient configuration.

Configuring FortiClient – preshared key only

1. Start the FortiClient Endpoint Security application.
2. Go to VPN > Connections, select the existing configuration Select Advanced > Edit.
3. In the Preshared Key field, type the user name, followed by a “+” sign, followed by the password that you specified previously in the user account settings on the FortiGate unit (for example, FC2+1FG6LK) 5. Select OK to close all dialog boxes.

Configure all the FortiClient dialup clients this way using their unique peer ID and pre-shared key values.

Defining IKE negotiation parameters

In Phase 1, the two peers exchange keys to establish a secure communication channel between them. As part of the Phase 1 process, the two peers authenticate each other and negotiate a way to encrypt further communications for the duration of the session. For more information see Defining IKE negotiation parameters on page 63. The Phase 1 Proposal parameters select the encryption and authentication algorithms that are used to generate keys for protecting negotiations. The IKE negotiation parameters determine:

• Which encryption algorithms may be applied for converting messages into a form that only the intended recipient can read
• Which authentication hash may be used for creating a keyed hash from a preshared or private key
• Which Diffie-Hellman group (DH Group) will be used to generate a secret session key

Phase 1 negotiations (in main mode or aggressive mode) begin as soon as a remote VPN peer or client attempts to establish a connection with the FortiGate unit. Initially, the remote peer or dialup client sends the FortiGate unit a list of potential cryptographic parameters along with a session ID. The FortiGate unit compares those parameters to its own list of advanced Phase 1 parameters and responds with its choice of matching parameters 63

Defining IKE negotiation

to use for authenticating and encrypting packets. The two peers handle the exchange of encryption keys between them, and authenticate the exchange through a preshared key or a digital signature.

Generating keys to authenticate an exchange

The FortiGate unit supports the generation of secret session keys automatically using a Diffie-Hellman algorithm. These algorithms are defined in RFC 2409. The Keylife setting in the Phase 1 Proposal area determines the amount of time before the Phase 1 key expires. Phase 1 negotiations are re-keyed automatically when there is an active security association. See Dead Peer Detection  on page 67.

You can enable or disable automatic re-keying between IKE peers through the phase1-rekey attribute of the config system global CLI command. For more information, see the “System” chapter of the FortiGate CLI Reference.

When in FIPS-CC mode, the FortiGate unit requires DH key exchange to use values at least 3072 bits long. However most browsers need the key size set to 1024. You can set the minimum size of the DH keys in the CLI.

config system global    set dh-params 3072 end

When you use a preshared key (shared secret) to set up two-party authentication, the remote VPN peer or client and the FortiGate unit must both be configured with the same preshared key. Each party uses a session key derived from the Diffie-Hellman exchange to create an authentication key, which is used to sign a known combination of inputs using an authentication algorithm (such as HMAC-MD5, HMAC-SHA-1, or HMAC-SHA256). Hash-based Message Authentication Code (HMAC) is a method for calculating an authentication code using a hash function plus a secret key, and is defined in RFC 2104. Each party signs a different combination of inputs and the other party verifies that the same result can be computed.

When you use preshared keys to authenticate VPN peers or clients, you must distribute matching information to all VPN peers and/or clients whenever the preshared key changes.

As an alternative, the remote peer or dialup client and FortiGate unit can exchange digital signatures to validate each other’s identity with respect to their public keys. In this case, the required digital certificates must be installed on the remote peer and on the FortiGate unit. By exchanging certificate DNs, the signed server certificate on one peer is validated by the presence of the root certificate installed on the other peer.

The following procedure assumes that you already have a Phase 1 definition that describes how remote VPN peers and clients will be authenticated when they attempt to connect to a local FortiGate unit. For information about the Local ID and XAuth options, see Defining IKE negotiation parameters on page 63 and Defining IKE negotiation parameters on page 63. Follow this procedure to add IKE negotiation parameters to the existing definition.

Defining IKE negotiation parameters

1. Go to VPN > IPsec Tunnels and create the new custom tunnel or edit an existing tunnel.
2. Edit the Phase 1 Proposal (if it is not available, you may need to click the Convert to Custom Tunnel button).
3. Select Phase 1 Proposal and include the appropriate entries as follows:

Defining IKE negotiation

NAT traversal

Network Address Translation (NAT) is a way to convert private IP addresses to publicly routable Internet addresses and vise versa. When an IP packet passes through a NAT device, the source or destination address in the IP header is modified. FortiGate units support NAT version 1 (encapsulate on port 500 with non-IKE marker), version 3 (encapsulate on port 4500 with non-ESP marker), and compatible versions.

NAT cannot be performed on IPsec packets in ESP tunnel mode because the packets do not contain a port number. As a result, the packets cannot be demultiplexed. To work around this, the FortiGate unit provides a way to protect IPsec packet headers from NAT modifications. When the Nat-traversal option is enabled, outbound encrypted packets are wrapped inside a UDP IP header that contains a port number. This extra encapsulation allows NAT devices to change the port number without modifying the IPsec packet directly.

To provide the extra layer of encapsulation on IPsec packets, the Nat-traversal option must be enabled whenever a NAT device exists between two FortiGate VPN peers or a FortiGate unit and a dialup client such as FortiClient. On the receiving end, the FortiGate unit or FortiClient removes the extra layer of encapsulation before decrypting the packet.

Additionally, you can force IPsec to use NAT traversal. If NAT is set to Forced, the FortiGate will use a port value of zero when constructing the NAT discovery hash for the peer. This causes the peer to think it is behind a NAT device, and it will use UDP encapsulation for IPsec, even if no NAT is present. This approach maintains interoperability with any IPsec implementation that supports the NAT-T RFC.

NAT keepalive frequency

When a NAT device performs network address translation on a flow of packets, the NAT device determines how long the new address will remain valid if the flow of traffic stops (for example, the connected VPN peer may be idle). The device may reclaim and reuse a NAT address when a connection remains idle for too long.

To work around this, when you enable NAT traversal specify how often the FortiGate unit sends periodic keepalive packets through the NAT device in order to ensure that the NAT address mapping does not change during the lifetime of a session. To be effective, the keepalive interval must be smaller than the session lifetime value used by the NAT device.

The keepalive packet is a 138-byte ISAKMP exchange.

Dead Peer Detection

Sometimes, due to routing issues or other difficulties, the communication link between a FortiGate unit and a

VPN peer or client may go down. Packets could be lost if the connection is left to time out on its own. The FortiGate unit provides a mechanism called Dead Peer Detection (DPD), sometimes referred to as gateway detection or ping server, to prevent this situation and reestablish IKE negotiations automatically before a connection times out: the active Phase 1 security associations are caught and renegotiated (rekeyed) before the Phase 1 encryption key expires.

By default, Dead Peer Detection sends probe messages every five seconds by default (see dpdretryinterval in the FortiGate CLI Reference). If you are experiencing high network traffic, you can experiment with increasing the ping interval. However longer intervals will require more traffic to detect dead peers which will result in more traffic.

In the web-based manager, the Dead Peer Detection option can be enabled when you define advanced Phase 1 options. The config vpn ipsec phase1 CLI command supports additional options for specifying a retry count and a retry interval.

For more information about these commands and the related config router gwdetect CLI command, see the FortiGate CLI Reference.

For example, enter the following CLI commands to configure dead peer detection on the existing IPsec Phase 1 configuration called test to use 15 second intervals and to wait for 3 missed attempts before declaring the peer dead and taking action.

config vpn ipsec phase1-interface edit <value> set dpd [disable | on-idle | on-demand] set dpd-retryinveral 15 set dpd-retrycount 3

Using XAuth authentication

next

end

DPD Scalability

On a dial-up server, if a multitude of VPN connections are idle, the increased DPD exchange could negatively impact the performance/load of the daemon. For this reason, an option is available in the CLI to send DPD passively in a mode called “on-demand”.

• When there is no traffic and the last DPD-ACK had been received, IKE will not send DPDs periodically.
• IKE will only send out DPDs if there are outgoing packets to send but no inbound packets had since been received.

Syntax

Set DPD to on-demand to trigger DPD when IPsec traffic is sent but no reply is received from the peer.

config vpn ipsec phase1-interface edit <value> set dpd [disable | on-idle | on-demand]

next

end

Certificate key size control

Proxy will choose the same SSL key size as the HTTPS server. If the key size from the server is 512, the proxy will choose 1024. If the key size is bigger than 1024, the proxy will choose 2048.

As a result, the firewall ssl-ssh-profile commands certname-rsa, certname-dsa, and certname-ecdsa have been replaced with more specific key size control commands under vpn certificate setting.

CLI syntax

config vpn certificate setting set certname-rsa1024 <name> set certname-rsa2048 <name> set certname-dsa1024 <name> set certname-dsa2048 <name> set certname-ecdsa256 <name> set certname-ecdsa384 <name>

end

Using XAuth authentication

Extended authentication (XAuth) increases security by requiring the remote dialup client user to authenticate in a separate exchange at the end of Phase 1. XAuth draws on existing FortiGate user group definitions and uses established authentication mechanisms such as PAP, CHAP, RADIUS, and LDAP to authenticate dialup clients. You can configure a FortiGate unit to function either as an XAuth server or an XAuth client.If the server or client is Using XAuth authentication

attempting a connection using XAuth and the other end is not using XAuth, the failed connection attempts that are logged will not specify XAuth as the reason.

Using the FortiGate unit as an XAuth server

A FortiGate unit can act as an XAuth server for dialup clients. When the Phase 1 negotiation completes, the FortiGate unit challenges the user for a user name and password. It then forwards the user’s credentials to an external RADIUS or LDAP server for verification.

If the user records on the RADIUS server have suitably configured Framed-IP-Address fields, you can assign client virtual IP addresses by XAuth instead of from a DHCP address range. See Assigning VIPs by RADIUS user group on page 1.

The authentication protocol to use for XAuth depends on the capabilities of the authentication server and the XAuth client:

• Select PAP Server whenever possible.
• You must select PAP Server for all implementations of LDAP and some implementations of Microsoft RADIUS.
• Select Auto Server when the authentication server supports CHAP Server but the XAuth client does not. The FortiGate unit will use PAP to communicate with the XAuth client and CHAP to communicate with the authentication server. You can also use Auto Server to allows multiple source interfaces to be defined in an IPsec/IKE policy

Before you begin, create user accounts and user groups to identify the dialup clients that need to access the network behind the FortiGate dialup server. If password protection will be provided through an external RADIUS or LDAP server, you must configure the FortiGate dialup server to forward authentication requests to the authentication server. For information about these topics, see the FortiGate User Authentication Guide.

Authenticating a dialup user group using XAuth settings

1. At the FortiGate dialup server, go to VPN > IPsec Tunnels and create the new custom tunnel or edit an existing tunnel.
2. Select Convert To Custom Tunnel.
3. Edit XAUTH, select the Type setting, which determines the type of encryption method to use between the XAuth client, the FortiGate unit and the authentication server. Select one of the following options:
   • Disabled — Disables XAuth settings.
   • PAP Server — Password Authentication Protocol.
   • CHAP Server — Challenge-Handshake Authentication Protocol.
   • Auto Server — Use PAP between the XAuth client and the FortiGate unit, and CHAP between the FortiGate unit and the authentication server.
4. From the User Group list, select the user group that needs to access the private network behind the FortiGate unit. The group must be added to the FortiGate configuration before it can be selected here. For multiple user groups to be defined in the IPsec/IKE policy, select Inherit from policy.
5. Select OK.
6. Create as many policies as needed, specifying Source User(s) and Destination Address.

For example, one policy could have user1 have access to test_local_subnet_1, while user2 has access to test_ local_subnet_2.

Dynamic IPsec route control

As of FortiOS 5.4.1, when XAuth settings are enabled, Inherit from policy is only available under PAP Server and CHAP Server, not Auto Server. Because of this, only one user group may be defined for Auto Server.

Using the FortiGate unit as an XAuth client

If the FortiGate unit acts as a dialup client, the remote peer, acting as an XAuth server, might require a username and password. You can configure the FortiGate unit as an XAuth client, with its own username and password, which it provides when challenged.

Configuring the FortiGate dialup client as an XAuth client

1. At the FortiGate dialup client, go to VPN > IPsec Tunnels and create the new custom tunnel or edit an existing tunnel.
2. Edit the Phase 1 Proposal (if it is not available, you may need to click the Convert to Custom Tunnel button).
3. Under XAuth, select Enable as Client.
4. In the Username field, type the FortiGate PAP, CHAP, RADIUS, or LDAP user name that the FortiGate XAuth server will compare to its records when the FortiGate XAuth client attempts to connect.
5. In the Password field, type the password to associate with the user name.
6. Select OK.

Dynamic IPsec route control

You can add a route to a peer destination selector by using the add-route option, which is available for all dynamic IPsec Phases 1 and 2, for both policy-based and route-based IPsec VPNs. This option was previously only available when mode-cfg was enabled in Phase 1.

The add-route option adds a route to the FortiGate unit’s routing information base when the dynamic tunnel is negotiated. You can use the distance and priority options to set the distance and priority of this route. If this results in a route with the lowest distance, it is added to the FortiGate unit’s forwarding information base.

You can also enable add-route in any policy-based or route-based Phase 2 configuration that is associated with a dynamic (dialup) Phase 1. In Phase 2, add-route can be enabled, disabled, or set to use the same route as Phase 1.

The add-route feature is enabled by default and is configured in the CLI.

Syntax

Phase 1

config vpn ipsec edit <name> set type dynamic

set add-route {enable | disable}

end

end

Phase 2

Dynamic IPsec route control

config vpn ipsec {phase2 | phase2-interface} edit <name> set add-route {phase1 | enable | disable}

end

end

Blocking IPsec SA Negotiation

For interface-based IPsec, IPsec SA negotiation blocking can only be removed if the peer offers a wildcard selector. If a wildcard selector is offered then the wildcard route will be added to the routing table with the distance/priority value configured in Phase 1 and, if that is the route with the lowest distance, it is installed into the forwarding information base.

In cases where this occurs, it is important to ensure that the distance value configured on Phase 1 is set appropriately.

Phase 2 parameters

This section describes the Phase 2 parameters that are required to establish communication through a VPN. The following topics are included in this section:

Phase 2 settings

Configuring the Phase 2 parameters

Phase 2 settings

After IPsec VPN Phase 1 negotiations complete successfully, Phase 2 negotiation begins. Phase 2 parameters define the algorithms that the FortiGate unit can use to encrypt and transfer data for the remainder of the session. The basic Phase 2 settings associate IPsec Phase 2 parameters with a Phase 1 configuration.

When defining Phase 2 parameters, you can choose any set of Phase 1 parameters to set up a secure connection and authenticate the remote peer.

For more information on Phase 2 settings in the web-based manager, see IPsec VPN in the web-based manager on page 38.

The information and procedures in this section do not apply to VPN peers that perform negotiations using manual keys.

Phase 2 Proposals

In Phase 2, the VPN peer or client and the FortiGate unit exchange keys again to establish a secure communication channel. The Phase 2 Proposal parameters select the encryption and authentication algorithms needed to generate keys for protecting the implementation details of Security Associations (SAs). The keys are generated automatically using a Diffie-Hellman algorithm.

Replay Detection

IPsec tunnels can be vulnerable to replay attacks. Replay Detection enables the FortiGate unit to check all IPsec packets to see if they have been received before. If any encrypted packets arrive out of order, the FortiGate unit discards them.

IKE/IPsec Extended Sequence Number (ESN) support

64-bit Extended Sequence numbers (as described in RFC 4303, RFC 4304 as an addition to IKEv1, and RFC 5996 for IKEv2.) are supported for IPsec when Replay Detection is enabled.

Perfect Forward Secrecy (PFS)

By default, Phase 2 keys are derived from the session key created in Phase 1. Perfect Forward Secrecy (PFS) forces a new Diffie-Hellman exchange when the tunnel starts and whenever the Phase 2 keylife expires, causing a new key to be generated each time. This exchange ensures that the keys created in Phase 2 are unrelated to the Phase 1 keys or any other keys generated automatically in Phase 2.

Phase 2 settings

Keylife

The Keylife setting sets a limit on the length of time that a Phase 2 key can be used. The default units are seconds. Alternatively, you can set a limit on the number of kilobytes (KB) of processed data, or both. If you select both, the key expires when either the time has passed or the number of KB have been processed. When the Phase 2 key expires, a new key is generated without interrupting service.

Quick mode selectors

Quick mode selectors determine which IP addresses can perform IKE negotiations to establish a tunnel. By only allowing authorized IP addresses access to the VPN tunnel, the network is more secure.

The default settings are as broad as possible: any IP address or configured address object, using any protocol, on any port.

While the drop down menus for specifying an address also show address groups, the use of address groups may not be supported on a remote endpoint device that is not a FortiGate.

The address groups are at the bottom of the list to make it easy to distinguish between addresses and address groups.

When configuring Quick Mode selector Source address and Destination address, valid options include IPv4 and IPv6 single addresses, IPv4 subnet, or IPv6 subnet. For more information on IPv6 IPsec VPN, see Overview of IPv6 IPsec support on page 1.

There are some configurations that require specific selectors:

• The VPN peer is a third-party device that uses specific phase2 selectors.
• The FortiGate unit connects as a dialup client to another FortiGate unit, in which case (usually) you must specify a source IP address, IP address range, or subnet. However, this is not required if you are using dynamic routing and mode-cfg.

With FortiOS VPNs, your network has multiple layers of security, with quick mode selectors being an important line of defence.

• Routes guide traffic from one IP address to another.
• Phase 1 and Phase 2 connection settings ensure there is a valid remote end point for the VPN tunnel that agrees on the encryption and parameters.
• Quick mode selectors allow IKE negotiations only for allowed peers. l Security policies control which IP addresses can connect to the VPN.
• Security policies also control what protocols are allowed over the VPN along with any bandwidth limiting.

FortiOS is limited with IKEv2 selector matching. When using IKEv2 with a named traffic selector, no more than 32 subnets per traffic selector are added, since FortiOS doesn’t fully implement the IKEv2 selector matching rules.

The workaround is to use multiple Phase 2s. If the configuration is FGT <-> FGT, then the better alternative is to just use 0.0.0.0 <-> 0.0.0.0 and use the firewall policy for enforcement.

Phase 2 parameters                                                                                          Configuring the

Using the add-route option

Consider using the add-route option to add a route to a peer destination selector. Phase 2 includes the option of allowing the add-route to automatically match the settings in Phase 1. For more information, refer to Phase 1 parameters on page 52.

Syntax

Phase 2

config vpn ipsec {phase2 | phase2-interface} edit <name> set add-route {phase1 | enable | disable}

end

end

Configuring the Phase 2 parameters

If you are creating a hub-and-spoke configuration or an Internet-browsing configuration, you may have already started defining some of the required Phase 2 parameters. If so, edit the existing definition to complete the configuration.

Specifying the Phase 2 parameters

1. Go to VPN > IPsec Tunnels and create the new custom tunnel or edit an existing tunnel.
2. Open the Phase 2 Selectors panel (if it is not available, you may need to click the Convert to Custom Tunnel button).
3. Enter a Name for the Phase 2 configuration, and select a Phase 1 configuration from the drop-down list.
4. Select Advanced.
5. Include the appropriate entries as follows:

Configuring the Phase 2 parameters

Phase 2 parameters                                                                                          Configuring the

Autokey Keep Alive

The Phase 2 SA has a fixed duration. If there is traffic on the VPN as the SA nears expiry, a new SA is negotiated and the VPN switches to the new SA without interruption. If there is no traffic, however, the SA expires (by default) and the VPN tunnel goes down. A new SA will not be generated until there is traffic.

The Autokey Keep Alive option ensures that a new Phase 2 SA is negotiated, even if there is no traffic, so that the VPN tunnel stays up.

Auto-negotiate

By default, the Phase 2 security association (SA) is not negotiated until a peer attempts to send data. The triggering packet and some subsequent packets are dropped until the SA is established. Applications normally resend this data, so there is no loss, but there might be a noticeable delay in response to the user.

If the tunnel goes down, the auto-negotiate feature (when enabled) attempts to re-establish the tunnel. Autonegotiate initiates the Phase 2 SA negotiation automatically, repeating every five seconds until the SA is established.

Automatically establishing the SA can be important for a dialup peer. It ensures that the VPN tunnel is available for peers at the server end to initiate traffic to the dialup peer. Otherwise, the VPN tunnel does not exist until the dialup peer initiates traffic.

The auto-negotiate feature is available through the Command Line Interface (CLI) via the following commands:

config vpn ipsec phase2 edit <phase2_name> set auto-negotiate enable

end

Installing dynamic selectors via auto-negotiate

The IPsec SA connect message generated is used to install dynamic selectors. These selectors can now be installed via the auto-negotiate mechanism. When phase 2 has auto-negotiate enabled, and phase 1 has meshselector-type set to subnet, a new dynamic selector will be installed for each combination of source and destination subnets. Each dynamic selector will inherit the auto-negotiate option from the template selector and begin SA negotiation. Phase 2 selector sources from dial-up clients will all establish SAs without traffic being initiated from the client subnets to the hub.

Configuring the Phase 2 parameters

DHCP-IPsec

Select this option if the FortiGate unit assigns VIP addresses to FortiClient dialup clients through a DHCP server or relay. This option is available only if the Remote Gateway in the Phase 1 configuration is set to Dialup User and it works only on policy-based VPNs.

With the DHCP-IPsec option, the FortiGate dialup server acts as a proxy for FortiClient dialup clients that have VIP addresses on the subnet of the private network behind the FortiGate unit. In this case, the FortiGate dialup server acts as a proxy on the local private network for the FortiClient dialup client. When a host on the network behind the dialup server issues an ARP request that corresponds to the device MAC address of the FortiClient host (when a remote server sends an ARP to the local FortiClient dialup client), the FortiGate unit answers the ARP request on behalf of the FortiClient host and forwards the associated traffic to the FortiClient host through the tunnel.

This feature prevents the VIP address assigned to the FortiClient dialup client from causing possible arp broadcast problems — the normal and VIP addresses can confuse some network switches by two addresses having the same MAC address.