Category Archives: FortiOS

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.

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

Name	Type a name for the Phase 1 definition. The maximum name length is 15 characters for an interface mode VPN, 35 characters for a policy-based VPN. If Remote Gateway is Dialup User, the maximum name length is further reduced depending on the number of dialup tunnels that can be established: by 2 for up to 9 tunnels, by 3 for up to 99 tunnels, 4 for up to 999 tunnels, and so on. For a tunnel mode VPN, the name normally reflects where the remote connection originates. For a route-based tunnel, the FortiGate unit also uses the name for the virtual IPsec interface that it creates automatically.
Remote Gateway	Select the category of the remote connection: Static IP Address — If the remote peer has a static IP address. Dialup User — If one or more FortiClient or FortiGate dialup clients with dynamic IP addresses will connect to the FortiGate unit. Dynamic DNS — If a remote peer that has a domain name and subscribes to a dynamic DNS service will connect to the FortiGate unit.
IP Address	If you selected Static IP Address, enter the IP address of the remote peer.
Dynamic DNS	If you selected *Dynamic DNS*, enter the domain name of the remote peer.
Local Interface	This option is available in NAT mode only. Select the name of the interface through which remote peers or dialup clients connect to the FortiGate unit. By default, the local VPN gateway IP address is the IP address of the interface that you selected.
Mode	Main mode — the Phase 1 parameters are exchanged in multiple rounds with encrypted authentication information. Aggressive mode — the Phase 1 parameters are exchanged in single message with authentication information that is not encrypted. When the remote VPN peer has a dynamic IP address and is authenticated by a pre-shared key, you must select Aggressive mode if there is more than one dialup phase1 configuration for the interface IP address. When the remote VPN peer has a dynamic IP address and is authenticated by a certificate, you must select Aggressive mode if there is more than one Phase 1 configuration for the interface IP address and these Phase 1 configurations use different proposals.
Authentication Method	Select Preshared Key or RSA Signature.

Pre-shared Key	If you selected Pre-shared Key, enter the pre-shared key that the FortiGate unit will use to authenticate itself to the remote peer or dialup client during Phase 1 negotiations. You must define the same key at the remote peer or client. The key must contain at least 6 printable characters. For optimum protection against currently known attacks, the key must consist of a minimum of 16 randomly chosen alphanumeric characters. The limit is 128 characters.
Certificate Name	If you selected RSA Signature, select the name of the server certificate that the FortiGate unit will use to authenticate itself to the remote peer or dialup client during Phase 1 negotiations. For information about obtaining and loading the required server certificate, see the FortiOS User Authentication guide.
Peer Options	Peer options are available to authenticate VPN peers or clients, depending on the Remote Gateway and Authentication Method settings.
Any peer ID	Accept the local ID of any remote VPN peer or client. The FortiGate unit does not check identifiers (local IDs). You can set Mode to Aggressive or Main. You can use this option with RSA Signature authentication. But, for highest security, configure a PKI user/group for the peer and set Peer Options to Accept this peer certificate only.
This peer ID	This option is available when Aggressive Mode is enabled. Enter the identifier that is used to authenticate the remote peer. This identifier must match the Local ID that the remote peer’s administrator has configured. If the remote peer is a FortiGate unit, the identifier is specified in the Local ID field of the Advanced Phase 1 configuration. If the remote peer is a FortiClient user, the identifier is specified in the Local ID field, accessed by selecting Config in the Policy section of the VPN connection’s Advanced Settings. In circumstances where multiple remote dialup VPN tunnels exist, each tunnel must have a peer ID set.
Peer ID from dialup group	Authenticate multiple FortiGate or FortiClient dialup clients that use unique identifiers and unique pre-shared keys (or unique pre-shared keys only) through the same VPN tunnel. You must create a dialup user group for authentication purposes. Select the group from the list next to the Peer ID from dialup group option. You must set Mode to Aggressive when the dialup clients use unique identifiers and unique pre-shared keys. If the dialup clients use unique preshared keys only, you can set Mode to Main if there is only one dialup Phase 1 configuration for this interface IP address.

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.

VXLAN over IPsec

Packets with VXLAN header are encapsulated within IPsec tunnel mode.

To configure VXLAN over IPsec – CLI:

config vpn ipsec phase1-interface/phase1 edit ipsec set interface <name> set encapsulation vxlan/gre

set encapsulation-address ike/ipv4/ipv6 set encap-local-gw4 xxx.xxx.xxx.xxx set encap-remote-gw xxx.xxx.xxx.xxx

next end

IPsec tunnel idle timer	You can define an idle timer for IPsec tunnels. When no traffic has passed through the tunnel for the configured idle-timeout value, the IPsec tunnel will be flushed. To configure IPsec tunnel idle timeout – CLI: config vpn ipsec phase1-interface edit p1 set idle-timeout [enable \| disable] set idle-timeoutinterval <integer> //IPsec tunnel idle timeout in minutes (10 – 43200). end end
IPv6 Version	Select if you want to use IPv6 addresses for the remote gateway and interface IP addresses.
Local Gateway IP	Specify an IP address for the local end of the VPN tunnel. Select one of the following: Main Interface IP — The FortiGate unit obtains the IP address of the interface from the network interface settings. Specify — Enter a secondary address of the interface selected in the Phase 1 Local Interface field. You cannot configure Interface mode in a transparent mode VDOM.
Phase 1 Proposal	Select the encryption and authentication algorithms used to generate keys for protecting negotiations and add encryption and authentication algorithms as required. You need to select a minimum of one and a maximum of three combinations. The remote peer or client must be configured to use at least one of the proposals that you define. Select one of the following symmetric-key encryption algorithms: DES — Digital Encryption Standard, a 64-bit block algorithm that uses a 56-bit key. 3DES — Triple-DES; plain text is encrypted three times by three keys. AES128 — A 128-bit block algorithm that uses a 128-bit key. AES192 — A 128-bit block algorithm that uses a 192-bit key. AES256 — A 128-bit block algorithm that uses a 256-bit key.

	You can select either of the following message digests to check the authenticity of messages during an encrypted session: MD5 — Message Digest 5. SHA1 — Secure Hash Algorithm 1 – a 160-bit message digest. To specify one combination only, set the Encryption and Authentication options of the second combination to NULL. To specify a third combination, use the Add button beside the fields for the second combination.
Diffie-Hellman Group	Select one or more Diffie-Hellman groups from DH groups 1, 2, 5, and 14 through 21. At least one of the Diffie-Hellman Group settings on the remote peer or client must match one the selections on the FortiGate unit. Failure to match one or more DH groups will result in failed negotiations.
Keylife	Enter the time (in seconds) that must pass before the IKE encryption key expires. When the key expires, a new key is generated without interrupting service. The keylife can be from 120 to 172 800 seconds.
Local ID	If the FortiGate unit will act as a VPN client and you are using peer IDs for authentication purposes, enter the identifier that the FortiGate unit will supply to the VPN server during the Phase 1 exchange. If the FortiGate unit will act as a VPN client, and you are using security certificates for authentication, select the distinguished name (DN) of the local server certificate that the FortiGate unit will use for authentication purposes. If the FortiGate unit is a dialup client and will not be sharing a tunnel with other dialup clients (that is, the tunnel will be dedicated to this Fortinet dialup client), set Mode to Aggressive. Note that this Local ID value must match the peer ID value given for the remote VPN peer’s Peer Options.

XAuth	This option supports the authentication of dialup clients. It is available for IKE v1 only. Disable — Select if you do not use XAuth. Enable as Client — If the FortiGate unit is a dialup client, enter the user name and password that the FortiGate unit will need to authenticate itself to the remote XAuth server. Enable as Server — This is available only if Remote Gateway is set to Dialup User. Dialup clients authenticate as members of a dialup user group. You must first create a user group for the dialup clients that need access to the network behind the FortiGate unit. You must also configure the FortiGate unit to forward authentication requests to an external RADIUS or LDAP authentication server. Select a Server Type setting to determine the type of encryption method to use between the FortiGate unit, the XAuth client and the external authentication server, and then select the user group from the User Group list.
Username	Enter the user name that is used for authentication.
Password	Enter the password that is used for authentication.
NAT Traversal	Select the check box if a NAT device exists between the local FortiGate unit and the VPN peer or client. The local FortiGate unit and the VPN peer or client must have the same NAT traversal setting (both selected or both cleared) to connect reliably. 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.
Keepalive Frequency	If you enabled NAT-traversal, enter a keepalive frequency setting.
Dead Peer Detection	Select this check box to reestablish VPN tunnels on idle connections and clean up dead IKE peers if required. You can use this option to receive notification whenever a tunnel goes up or down, or to keep the tunnel connection open when no traffic is being generated inside the tunnel. For example, in scenarios where a dialup client or dynamic DNS peer connects from an IP address that changes periodically, traffic may be suspended while the IP address changes. With Dead Peer Detection selected, you can use the config vpn ipsec phase1 (tunnel mode) or config vpn ipsec phase1- interface (interface mode) CLI command to optionally specify a retry count and a retry interval.

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]

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]

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.

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

Name	Type a name to identify the Phase 2 configuration.
Phase 1	Select the Phase 1 tunnel configuration. For more information on configuring Phase 1, see Phase 1 configuration on page 38. The Phase 1 configuration describes how remote VPN peers or clients will be authenticated on this tunnel, and how the connection to the remote peer or client will be secured.
Advanced	Define advanced Phase 2 parameters. For more information, see Phase 2 advanced configuration settings below.

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.

Phase 2 Proposal

Select the encryption and authentication algorithms that will be proposed to the remote VPN peer. You can specify up to three proposals. To establish a VPN connection, at least one of the proposals that you specify must match configuration on the remote peer.

Initially there are two proposals. Add and Delete icons are next to the second Authentication field.

It is invalid to set both Encryption and Authentication to NULL.

Encryption

Select a symmetric-key algorithms:

NULL — Do not use an encryption algorithm.

DES — Digital Encryption Standard, a 64-bit block algorithm that uses a 56-bit key.

3DES — Triple-DES; plain text is encrypted three times by three keys.

AES128 — A 128-bit block algorithm that uses a 128-bit key.

AES192 — A 128-bit block algorithm that uses a 192-bit key.

AES256 — A 128-bit block algorithm that uses a 256-bit key.

Authentication	You can select either of the following message digests to check the authenticity of messages during an encrypted session: NULL — Do not use a message digest. MD5 — Message Digest 5. SHA1 — Secure Hash Algorithm 1 – a 160-bit message digest. To specify one combination only, set the Encryption and Authentication options of the second combination to NULL. To specify a third combination, use the Add button beside the fields for the second combination.
Enable replay detection	Replay attacks occur when an unauthorized party intercepts a series of IPsec packets and replays them back into the tunnel.
Enable perfect forward secrecy (PFS)	Perfect forward secrecy (PFS) improves security by forcing a new Diffie-Hellman exchange whenever keylife expires.
Diffie-Hellman Group	Select one Diffie-Hellman group (1, 2, 5, or 14 through 21). This must match the DH Group that the remote peer or dialup client uses.
Keylife	Select the method for determining when the Phase 2 key expires: Seconds, KBytes, or Both. If you select Both, the key expires when either the time has passed or the number of KB have been processed.
Autokey Keep Alive	Select the check box if you want the tunnel to remain active when no data is being processed.
Auto-negotiate	Enable the option if you want the tunnel to be automatically renegotiated when the tunnel expires.
DHCP-IPsec	Provide IP addresses dynamically to VPN clients. This is available for Phase 2 configurations associated with a dialup Phase 1 configuration. You also need configure a DHCP server or relay on the private network interface. You must configure the DHCP parameters separately. If you configure the DHCP server to assign IP addresses based on RADIUS user group attributes, you must also set the Phase 1 Peer Options to Peer ID from dialup group and select the appropriate user group. See Phase 1 configuration on page 38. If the FortiGate unit acts as a dialup server and you manually assigned FortiClient dialup clients VIP addresses that match the network behind the dialup server, selecting the check box will cause the FortiGate unit to act as a proxy for the dialup clients.

Quick Mode Selector	Specify the source and destination IP addresses to be used as selectors for IKE negotiations. If the FortiGate unit is a dialup server, keep the default value of 0.0.0.0/0 unless you need to circumvent problems caused by ambiguous IP addresses between one or more of the private networks making up the VPN. You can specify a single host IP address, an IP address range, or a network address. You may optionally specify source and destination port numbers and a protocol number. If you are editing an existing Phase 2 configuration, the Source address and Destination address fields are unavailable if the tunnel has been configured to use firewall addresses as selectors. This option exists only in the CLI.
Source address	If the FortiGate unit is a dialup server, enter the source IP address that corresponds to the local senders or network behind the local VPN peer (for example, 172.16.5.0/24 or 172.16.5.0/255.255.255.0 for a subnet, or 172.16.5.1/32 or 172.16.5.1/255.255.255.255 for a server or host, or 192.168.10.[80-100] or 192.168.10.80192.168.10.100 for an address range). A value of 0.0.0.0/0 means all IP addresses behind the local VPN peer. If the FortiGate unit is a dialup client, source address must refer to the private network behind the Fortinet dialup client.
Source port	Enter the port number that the local VPN peer uses to transport traffic related to the specified service (protocol number). The range is from 0 to 65535. To specify all ports, type 0.
Destination address	Enter the destination IP address that corresponds to the recipients or network behind the remote VPN peer (for example, 192.168.20.0/24 for a subnet, or 172.16.5.1/32 for a server or host, or 192.168.10. [80-100] for an address range). A value of 0.0.0.0/0 means all IP addresses behind the remote VPN peer.
Destination port	Enter the port number that the remote VPN peer uses to transport traffic related to the specified service (protocol number). To specify all ports, enter 0.
Protocol	Enter the IP protocol number of the service. To specify all services, enter 0.

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.

Name		Enter a name for the FortiClient VPN.
Local Outgoing Interface		Select the local outgoing interface for the VPN.
Authentication Method		Select the type of authentication used when logging in to the VPN.
Preshared Key		If Pre-shared Key was selected in Authentication Method, enter the pre-shared key in the field provided.
User Group		Select a user group. You can also create a user group from the drop-down list by selecting Create New.
Address Range Start IP		Enter the start IP address for the DHCP address range for the client.
Address Range End IP		Enter the end IP address for the address range.
Subnet Mask		Enter the subnet mask.
Enable IPv4 Split Tunnel		Enabled by default, this option enables the FortiClient user to use the VPN to access internal resources while other Internet access is not sent over the VPN, alleviating potential traffic bottlenecks in the VPN connection. Disable this option to have all traffic sent through the VPN tunnel.
Accessible Networks		Select from a list of internal networks that the FortiClient user can access.
Client Options		These options affect how the FortiClient application behaves when connected to the FortiGate VPN tunnel. When enabled, a check box for the corresponding option appears on the VPN login screen in FortiClient, and is not enabled by default. Save Password – When enabled, if the user selects this option, their password is stored on the user’s computer and will automatically populate each time they connect to the VPN. Auto Connect – When enabled, if the user selects this option, when the FortiClient application is launched, for example after a reboot or system startup, FortiClient will automatically attempt to connect to the VPN tunnel. Always Up (Keep Alive) – When enabled, if the user selects this option, the FortiClient connection will not shut down. When not selected, during periods of inactivity, FortiClient will attempt to stay connected every three minutes for a maximum of 10 minutes.

Concentrator

Endpoint Registration

When selected, the FortiGate unit requests a registration key from FortiClient before a connection can be established. A registration key is defined by going to System > Advanced.

For more information on FortiClient VPN connections to a FortiGate unit, see the FortiClient Administration Guide.

DNS Server

Select which DNS server to use for this VPN:

Use System DNS — Use the same DNS servers as the FortiGate unit. These are configured at Network > DNS. This is the default option.

Specify — Specify the IP address of a different DNS server.

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.

Concentrator Name	Type a name for the concentrator.
Available Tunnels	A list of defined IPsec VPN tunnels. Select a tunnel from the list and then select the right arrow.
Members	A list of tunnels that are members of the concentrator. To remove a tunnel from the concentrator, select the tunnel and select the left arrow.

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.

Having trouble configuring your Fortinet hardware or have some questions you need answered? Check Out The Fortinet Guru Youtube Channel! Want someone else to deal with it for you? Get some consulting from Fortinet GURU!

IPsec VPN overview

Leave a reply

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.

Comparison of policy-based and route-based VPNs

Features	Policy-based	Route-based
Both NAT and transparent modes available	Yes	NAT mode only
L2TP-over-IPsec supported	Yes	Yes
GRE-over-IPsec supported	No	Yes
security policy requirements	Requires a security policy with IPSEC action that specifies the VPN tunnel	Requires only a simple security policy with ACCEPT action
Number of policies per VPN	One policy controls connections in both directions	A separate policy is required for connections in each direction

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

Topology	Description
Gateway-to-gateway configurations	Standard one-to-one VPN between two FortiGate units. See Gateway-togateway configurations on page 1.
Hub-and-spoke configurations	One central FortiGate unit has multiple VPNs to other remote FortiGate units. See Hub-and-spoke configurations on page 1.
Dynamic DNS configuration	One end of the VPN tunnel has a changing IP address and the other end must go to a dynamic DNS server for the current IP address before establishing a tunnel. See Dynamic DNS configuration on page 1.
FortiClient dialup-client configurations	Typically remote FortiClient dialup-clients use dynamic IP addresses through NAT devices. The FortiGate unit acts as a dialup server allowing dialup VPN connections from multiple sources. See FortiClient dialup-client configurations on page 1.
FortiGate dialup-client configurations	Similar to FortiClient dialup-client configurations but with more gateway-togateway settings such as unique user authentication for multiple users on a single VPN tunnel. See FortiGate dialup-client configurations on page 1.
Internet-browsing configuration	Secure web browsing performed by dialup VPN clients, and/or hosts behind a remote VPN peer. See Internet-browsing configuration on page 1.

overview General preparation steps

Topology	Description
Redundant VPN configurations	Options for supporting redundant and partially redundant IPsec VPNs, using route-based approaches. See Redundant VPN configurations on page 1.
Transparent mode VPNs	In transparent mode, the FortiGate acts as a bridge with all incoming traffic being broadcast back out on all other interfaces. Routing and NAT must be performed on external routers. See Transparent mode VPNs on page 1.
L2TP and IPsec (Microsoft VPN)	Configure VPN for Microsoft Windows dialup clients using the built in L2TP software. Users do not have to install any See L2TP and IPsec (Microsoft VPN) on page 1.

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:

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

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 concepts

1 Reply

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 Type

Remote Device Type

NAT Options

Description

Site to Site

FortiGate

l No NAT between sites

l This site is behind NAT

l The remote site is behind NAT

Static tunnel between this FortiGate and a remote FortiGate.

Cisco

l No NAT between sites

l This site is behind NAT

l The remote site is behind NAT

Static tunnel between this FortiGate and a remote Cisco firewall.

VPN gateways

VPN Type	Remote Device Type	NAT Options	Description
Remote Access	FortiClient VPN for OS X, Windows, and Android	N/A	On-demand tunnel for users using the FortiClient software.
	iOS Native	N/A	On-demand tunnel for iPhone/iPad users using the native iOS IPsec client.
	Android Native	N/A	On-demand tunnel for Android users using the native L2TP/IPsec client.
	Windows Native	N/A	On-demand tunnel for Android users using the native L2TP/IPsec client.
	Cisco AnyConnect	N/A	On-demand tunnel for users using the Cisco IPsec client.
Custom	N/A	N/A	No Template.

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:

Encryption	Description
AES-GCM	Galois/Counter Mode (GCM), a block cipher mode of operation providing both confidentiality and data origin authentication.
AES256	A 128-bit block algorithm that uses a 256-bit key.
AES192	A 128-bit block algorithm that uses a 192-bit key.
AES128	A 128-bit block algorithm that uses a 128-bit key.
3DES	Triple-DES, in which plain text is DES-encrypted three times by three keys.
DES	Digital Encryption Standard, a 64-bit block algorithm that uses a 56-bit key

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

DH Group	Description
1	More Modular Exponential (MODP) DH Group with a 768-bit modulus.
2	MODP with a 1024-bit modulus.
5	MODP with a 1536-bit modulus.
14	MODP with a 2048-bit modulus.
15	MODP with a 3027-bit modulus.
16	MODP with a 4096-bit modulus.
17	MODP with a 6144-bit modulus.
18	MODP with a 8192-bit modulus.
19	256-bit random elliptic curve group.
20	384-bit random elliptic curve group.
21	521-bit random elliptic curve group.
27	Brainpool 224-bit elliptic curve group.
28	Brainpool 256-bit elliptic curve group.
29	Brainpool 384-bit elliptic curve group.
30	Brainpool 512-bit elliptic curve group.

* 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:

IPsec Transform Set	IPsec Overhead (Max. bytes)
ESP-AES (256, 192, or 128),ESP-SHA-HMAC, or MD5	73
ESP-AES (256, 192, or 128)	61
ESP-3DES, ESP-DES	45
ESP-(DES or 3DES), ESP-SHA-HMAC, or MD5	57
ESP-Null, ESP-SHA-HMAC, or MD5	45
AH-SHA-HMAC or MD5	44

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:

Remote gateway

The remote VPN gateway’s address.

FortiGate units also have the option of operating only as a server by selecting the “Dialup User” option.

Preshared key

This must be the same at both ends. It is used to encrypt Phase 1 authentication information.

Local interface

The network interface that connects to the other VPN gateway. This applies on a FortiGate unit only.

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

What’s new in FortiOS 5.6 IPSec

1 Reply

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}

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}

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

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>

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>

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}

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.

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

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”

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]

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.

FortiOS 5.6 IPSec VPN Introduction

Leave a reply

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.

FortiCarrier MMS Concepts

Leave a reply

MMS Concepts

MMS background

MMS is a common method for mobile users to send and receive multimedia content. A Carrier network supports MMS across its network. This makes up the MMS Service Provider Network (MSPN).

Messages can be sent or received between the MMSC and a number of other services including the Internet, content providers, or other carriers. Each of these different service connections uses different MMS formats including MM1 and MM7 messages (essentially HTTP format), and MM3 and MM4 messages (SMTP formatted). These different formats reflect the different purposes and content for each type of MMS message.

MMS content interfaces

MMS messages are sent from devices and servers to other devices and servers using MMS content interfaces

There are eight interfaces defined for the MMS standard, referred to as MM1 through MM8. The most important of these interfaces for the transfer of data is the MM1 interface, as this defines how mobile users communicate from the mobile network to the Multimedia Message Service Center (MMSC). MMS content to be monitored and controlled comes from these mobile users and is going to the provider network.

Other MMS content interfaces that connect a service provider network to other external sources can pose threats as well. MM3 handles communication between the Internet and the MMSC and is a possible source of viruses and other content problems from the Internet. MM4 handles communication between different content provider MMSCs. Filtering MM4 content protects the service provider network from content sent from foreign service providers and their subscribers. Finally MM7 is used for communication between content providers and the MMSC. Filtering MM3 content can also keep harmful content off of the service provider network.

MMS content interfaces

Type	Transaction	Similar to
MM 1	Handset to MMSC	HTTP
MM 3	Between MMSC and Internet	SMTP
MM 4	Between Operator MMSCs	SMTP
MM 7	Content Providers to MMSC	HTTP and SOAP

How MMS content interfaces are applied

As shown below, the sender’s mobile device encodes the MMS content in a form similar to MIME email message (MMS MIME content formats are defined by the MMS Message Encapsulation specification). The encoded message is then forwarded to the service provider’s MMSC. Communication between the sending device and the MMSC uses the MM1 content interface. The MM1 content interface establishes a connection and sends an MM1 send request (m-send.req) message that contains the MMS message. The MMSC processes this request and sends back an MM1 send confirmation (m-send.conf) HTTP response indicating the status of the message — accepted or an error occurred, for example.

MM1 transactions between senders and receivers and the MMSC

If the recipient is on another carrier, the MMSC forwards the message to the recipient’s carrier. This forwarding uses the MM4 content interface for forwarding content between operator MMSCs (see the figure below).

Before the MMSC can forward the message to the final recipient, it must first determine if the receiver’s handset can receive MMS messages using the MM1 content interface. If the recipient can use the MM1 content interface, the content is extracted and sent to a temporary storage server with an HTTP front-end.

To retrieve the message, the receiver’s handset establishes a connection with the MMSC. An HTTP get request is then sent from the recipient to the MMSC. This message contains the URL where the content of the message is stored. The MMSC responds with a retrieve confirmation (m-retrieve.conf) HTTP response that contains the message.

MM4 messages sent between operator MMSCs

Receiving Operator

MMSC MMSC

This causes the receiver’s handset to retrieve the content from the embedded URL. Several messages are exchanged to indicate status of the delivery attempt. Before delivering content, some MMSCs also include a content adaptation service that attempts to modify the multimedia content into a format suitable for the recipient’s handset.

If the receiver’s handset is not MM1 capable, the message can be delivered to a web based service and the receiver can view the content from a normal Internet browser. The URL for the content can be sent to the receiver in an SMS text message. Using this method, non-MM1 capable recipients can still receive MMS content.

The method for determining whether a handset is MMS capable is not specified by the standards. A database is usually maintained by the operator, and in it each mobile phone number is marked as being associated with a legacy handset or not. It can be a bit hit and miss since customers can change their handset at will and this database is not usually updated dynamically.

Email and web-based gateways from MMSC to the Internet use the MM3 content interface. On the receiving side, the content servers can typically receive service requests both from WAP and normal HTTP browsers, so delivery via the web is simple. For sending from external sources to handsets, most carriers allow MIME encoded message to be sent to the receiver’s phone number with a special domain.

How FortiOS Carrier processes MMS messages

MMS messages can be vectors for propagating undesirable content such as spam and viruses. FortiOS Carrier can scan MMS messages sent using the MM1, MM3, MM4, and MM7 content interfaces. You can configure FortiOS Carrier to scan MMS messages for spam and viruses by configuring and adding MMS protection profiles and adding the MMS protection profiles to security policies. You can also use MMS protection profiles to apply content blocking, carrier endpoint filtering, MMS address translation, sending MMS notifications, DLP archiving of MMS messages, and logging of MMS message activity.

FortiOS Carrier MMS processing

FortiOS Carrier can send MMS messages to senders informing those senders that their devices are infected. FortiOS Carrier can also send MMS notifications to administrators to inform them of suspicious activity on their networks.

For message floods and duplicate messages, FortiOS Carrier does not send notifications to message senders but does send notifications to administrators and sends messages to sender handsets to complete MM1 and MM4 sessions.

Where MMS messaging uses the TCP/IP set of protocols, SMS text messaging uses the Signaling System Number 7 (SS7) set of protocols, which is not supported by FortiOS.

FortiOS Carrier and MMS content scanning

The following section applies to MMS content scanning, including virus scanning, file filtering, content spam filtering, carrier endpoint filtering, and MMS content checksum filtering.

MM1 Content Scanning

During MM1 content scanning a message is first transmitted from the sender, establishing a connection with the MMSC. FortiOS Carrier intercepts this connection and acts as the endpoint. FortiOS Carrier then establishes its own connection to the MMSC. Once connected, the client transmits its m-send.req HTTP post request to FortiOS Carrier which scans it according to the MMS protection profile settings. If the content is clean, the message is forwarded to the MMSC. The MMSC returns m-send.conf HTTP response through FortiOS Carrier to the sender.

If FortiOS Carrier blocks the message (for example because a virus was found, see the figure below), FortiOS Carrier resets the connection to the MMSC and sends m-send.conf HTTP response back to the sender. The response message can be customized using replacement messages. FortiOS Carrier then terminates the connection. Sending back an m-send.conf message prevents the sender from trying to send the message again.

MM1 message sent by sender (blocking m.send.req messages)

FortiOS Carrier also sends m-send.rec notifications messages to the MMSC that are then forwarded to the sender to notify them of blocked messages.

Filtering message retrieval

FortiOS Carrier intercepts the connection to the MMSC, and the m-retrieve.conf HTTP response from the MMSC is scanned according to the MMS content scanning settings. If the content is clean, the response is forwarded back to the client. If the content is blocked, FortiOS Carrier drops the connection to the MMSC. It then builds an m-retrieve.conf message from the associated replacement message and transmits this back to the client.

FortiOS Carrier also sends m-send.rec notifications messages to the MMSC that are then forwarded to the receiver to notify them of blocked messages.

MM1 received by receiver (blocking m.retrieve.conf messages)

Filtering MM3 and MM4 messages works in an similar way to MM1 (see the figures below). FortiOS Carrier intercepts connections to the MMSC, and scans messages as configured. When messages are blocked, FortiOS Carrier closes sessions as required, sends confirmation messages to the sender, notifies administrators, and notifies senders and receivers of messages.

MM3 from a sender on the Internet to an MMSC

Open TCP session
Send full email message
Content blocked
Send 550 Error and replacement message
MM3 notification message

Sent once per notification period, regardless of how many messages are blocked

MM4 between operator MMSCs

Open TCP session
Send full MM4-forward.req message
m-retrieve.conf mesage
Content blocked
Send 250 response

MM7 between a VASP and an MMSC

Sending VASP

FortiOS Carrier

Receiving

MMSC

FortiOS Carrier and MMS duplicate messages and message floods

FortiOS Carrier detects duplicate messages and message floods for the MM1 and MM4 interfaces. How FortiOS Carrier detects and responds to duplicate messages and message floods is different from how FortiOS Carrier detects and responds to viruses and other MMS scanning protection measures.

For message floods and duplicate messages, the sender does not receive notifications about floods or duplicate messages, as if the sender is an attacker they can gain useful information about flood and duplicate thresholds. Plus, duplicate messages and message floods are usually a result of a large amount of messaging activity and filtering of these messages is designed to reduce the amount of unwanted messaging traffic. Adding to the traffic by sending notifications to senders and receivers could result in an increase in message traffic.

You can create up to three thresholds for detecting duplicate messages and message floods. For each threshold you can configure the FortiOS Carrier unit to respond by logging the activity, archiving or quarantining the messages, notifying administrators of the activity, and by blocking the messages. In many cases you may only want to configure blocking for higher activity thresholds, and to just monitor and send administrator notifications at lower activity thresholds.

When a block threshold is reached for MM1 messages, FortiOS Carrier sends m-send.conf or m-retrieve.conf messages to the originator of the activity. These messages are sent to end the MM1 sessions, otherwise the originator would continue to re-send the blocked message. When a block threshold is reached for MM4, FortiOS Carrier sends a MM4-forward.res message to close the MM4 session. An MM4 message is sent only if initiated by the originating MM4-forward.req message.

MM1 message flood and duplicate message blocking of sent messages

MM1 message flood and duplicate message blocking of received messages

MMS protection

MM4 message flood and duplicate message blocking

Open TCP session
Send full MM4-forward.req message Without ‘.’ on single line

Reset TCP session

MMS protection profiles

An MMS protection profile is a group of settings that you can apply to an MMS session matched by a security policy.

MMS protection profiles are easy to configure and can be used by more than one security policy. You can configure a single MMS protection profile for the different traffic types handled by a set of security policies that require identical protection levels and types. This eliminates the need to repeatedly configure those same MMS protection profile settings for each individual security policy.

Bypassing MMS protection profile filtering based on carrier endpoints

For example, while traffic between trusted and untrusted networks might need strict protection, traffic between trusted internal addresses might need only moderate protection. You would configure two separate MMS protection profiles to provide the different levels of protection: one for traffic between trusted networks, and one for traffic between trusted and untrusted networks.

Once you have configured the MMS Protection Profile, you need to add it to a security policy to apply the profile to MMS traffic.

Bypassing MMS protection profile filtering based on carrier endpoints

You can use carrier endpoint filtering to exempt MMS sessions from MMS protection profile filtering. Carrier endpoint filtering matches carrier endpoints in MMS sessions with carrier endpoint patterns. If you add a carrier endpoint pattern to a filter list and set the action to exempt from all scanning, all messages from matching carrier endpoints bypass MMS protection profile filtering. See Bypassing message flood protection based on user’s carrier endpoints.

Applying MMS protection profiles to MMS traffic

To apply an MMS protection profile you must first create the MMS protection profile and then add the MMS protection profile to a security policy by enabling the Carrier security profile. The MMS protection profile then applies itself to the traffic accepted by that security policy.

MMS protection profiles can contain settings relevant to many different services. Each security policy uses the subset of the MMS protection profile settings that apply to the sessions accepted by the security policy. In this way, you might define just one MMS protection profile that can be used by many security policies, each policy using a different or overlapping subset of the MMS protection profile.

To add an MMS protection profile to a security policy

Go to Security Profiles > MMS Profile.
Select Create New to add an MMS protection profile.
Configure as needed, and save.
Go to Policy & Objects > IPv4 Policy.
Select Create New to add a security policy, or select an existing policy and Edit to add the MMS profile.
Configure the security policy as required.
Enable MMS Profile, and select the MMS profile to add to the security policy.
Select OK.

Overview of FortiOS Carrier features

Leave a reply

Overview of FortiOS Carrier features

FortiOS Carrier specific features include Multimedia messaging service (MMS) protection, and GPRS Tunneling Protocol (GTP) protection.

All FortiGate units, carrier-enabled or not, are capable of handling Stream Control Transmission Protocol (SCTP) traffic, which is a protocol designed for and primarily used in Carrier networks.

This section includes:

Overview

FortiOS Carrier provides all the features found on FortiGate units plus added features specific to carrier networks:

MMS and GTP.

MMS

MMS is a standard for sending messages that include multimedia content between mobile phones. MMS is also popular as a method of delivering news and entertainment content including videos, pictures, and text. Carrier networks include four different MMS types of messages — MM1, MM3, MM4, and MM7.

GTP

The GPRS Tunneling Protocol (GTP) runs on GPRS carrier networks. GPRS is a GSM packet radio standard. It provides more efficient usage of the radio interface so that mobile devices can share the same radio channel. FortiOS supports GTPv1 and GTPv2.

GPRS provides direct connections to the Internet (TCP/IP) and X.25 networks for point-to-point services (connection-less/connection oriented) and point-to-multipoint services (broadcast).

GPRS currently supports data rates from 9.6 kbps to more than 100 kbps, and it is best suited for burst forms of traffic. GPRS involves both radio and wired components. The mobile phone sends the message to a base station unit (radio based) that converts the message from radio to wired, and sends the message to the carrier network and eventually the Internet (wired carrier network). See GTP.

What’s New in FortiOS 5.6 for FortiCarrier

Leave a reply

What’s New in FortiOS 5.6

New features added in 5.6.1

GTP enhancement and GTP Performance Improvement. (423332)

The GTP changes in 5.6.1 take place in the following categories:

New GTP features and functionality enhancements.

GTP message filter enhancements, including: l Unknown message white list l GTPv1 and GTPv2 profile separation l Message adoption.
GTP IE white list.
Global APN rate limit, including: l sending back REJECT message with back-off timer l “APN congestion” cause value
GTP half-open, half-close configurable timer.

GTP performance improvements.

Implemented RCU on GTP-U running path. i.e, no locking needed to look up tunnel state when processing GTP-U.

Note the RCU is only applied on GTPv1 and GTPv2 tunnels. It is not used for GTPv0 tunnels, due to the fact that (1) GTPv0 traffic is relatively minor compared with GTPv1 and GTPv2, and (2) GTPv0 tunnel indexing is totally different from GTPv1 and GTPv2. GTPv0 tunnel is indexed by [IMSI, NSAPI]. GTPv1 and GTPv2 tunnel is indexed by [IP, TEID]

Localized CPU memory usage on GTP-U running path.
GTP-C: changed some GTP tables from RB tree to hash table, including l GTP request tables, and GTPv0 tunnel tables. l Testing showed, when handling millions of entries adding/deleting, hash table performance was much better.
3.2 Hash table is compatible with RCU API, so we can apply RCU on these GTP-C tables later for further performance improvements.
GTP-C, improved GTP path management logic, so that GTP path will time out sooner when there are no tunnels linked to it

CLI Changes:

New Diagnose commands: diagnose firewall gtp

New features added in 5.6.1 What’s New in FortiOS 5.6

Option	Description
hash-stat-tunnel	GTP tunnel hash statistics.
hash-stat-v0tunnel	GTPv0 tunnel hash statistics.
hash-stat-path	GTP path hash statistics.
hash-stat-req	GTP request hash statistics.
vd-apn-shaper	APN shaper on VDOM level.
ie-white-list-v0v1	IE white list for GTPv0 or v1.
ie-white-list-v2	IE white list for GTPv2.

diagnose firewall gtp vd-apn-shaper

Option	Description
list	List

diagnose firewall gtp ie-white-list-v0v1

Option	Description
list	List

diagnose firewall gtp ie-white-list-v2

Option	Description
list	List

config gtp apn-shaperapn-shaper

Option

Description

apn

APN to match. Leave empty to match ANY.

“apn” field can be empty, it matches ANY apn. when configured, it is used to set a limit for any apn which is not explicitly listed; Also, if configured, such an entry should be the last entry, as it is first-match rule.

rate-limit

Rate limit in packets/s (0 – 1000000, 0 means unlimited).

What’s New in FortiOS 5.6 New features added in 5.6.1

Option

Description

action

Action. [drop | reject]

There is no back-off timer in GTPv0, therefor the reject action is not available for V0

back-off-time

Back off time in seconds (10 – 360).

back-off-time visible when action is

“reject”

Changed commands:

Under command firewall gtp, config message-filter is replaced by set message-filterv0v1

Example:

config firewall gtp edit <name> set message-filter-v0v1

New fields have been added to the config firewall gtp command context

Option	Description
half-open-timeout	Half-open tunnel timeout (in seconds).
half-close-timeout	Half-close tunnel timeout (in seconds).

Example:

config firewall gtp edit <name> set half-open-timeout 10 set half-close-timeout 10 Models affected by change

l FortiGate 3700D l FortiGate 3700DX l FortiGate 3800D Overview Overview of FortiOS Carrier features