FortiClient VPN

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 Preshared 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. Dis- able 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 con- nected to the FortiGate VPN tunnel. When enabled, a check box for the cor- responding 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 pass- word 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.

Endpoint Registration              When selected, the FortiGate unit requests a registration key from FortiCli- ent 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.


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!

Phase 2 configuration

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 con- figuring Phase 1, see Phase 1 configuration on page 1611. The Phase 1 configuration describes how remote VPN peers or clients will be authen- ticated 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 estab- lish 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 authen- ticity 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 com- bination, 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.

 

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

 

Autonegotiate                           Enable the option if you want the tunnel to be automatically renegotiated when the tunnel expires.

 

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

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 mak- ing 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 des- tination 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 con- figured 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 cor- responds 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.80-192.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 net- work 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.


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 in the web-based manager

IPsec VPN in the web-based manager

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

1. Define Phase 1 parameters to authenticate remote peers and clients for a secure connection. See IPsec VPN in the web-based manager on page 1611.

2. Define Phase 2 parameters to create a VPN tunnel with a remote peer or dialup client. See IPsec VPN in the web- based manager on page 1611.

3. Create a security policy to permit communication between your private network and the VPN. Policy-based VPNs have an action of IPSEC, where for interface-based VPNs the security policy action is ACCEPT. See Defining VPN security policies on page 1648.

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 auto- negotiate commands in the CLI.

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

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 con- nection originates. For a route-based tunnel, the FortiGate unit also uses the name for the virtual IPsec interface that it creates automatically.

Select the category of the remote connection:

Remote Gateway

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 sub-scribes 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 inter- face that you selected.

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.

Mode

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 con- figurations use different proposals.

Authentication Method            Select Preshared Key or RSA Signature.

Preshared Key

If you selected Preshared Key, enter the pre-shared key that the FortiGate unit will use to authenticate itself to the remote peer or dialup cli- ent 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 con- sist of a minimum of 16 randomly chosen alphanumeric 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 Authentic- ation 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 option is available when Aggressive Mode is enabled. Enter the iden- tifier that is used to authenticate the remote peer. This identifier must match the Local ID that the remote peer’s administrator has configured.

 

This peer ID

If the remote peer is a FortiGate unit, the identifier is specified in the LocaID 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.

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

VXLAN over IPsec                  Packets with VXLAN header are encapsulated within IPsec tunnel mode.

New attributes in IPsec phase1 settings have been added.

To configure VXLAN over IPsec – CLI:

config vpn ipsec phase1-interface/phase1 edit ipsec

set interface <name>

set encapsulation vxlan/gre (new)

set encapsulation-address ike/ipv4/ipv6 (New)

set encap-local-gw4 xxx.xxx.xxx.xxx (New)

set encap-remote-gw xxx.xxx.xxx.xxx (New)

next end

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.

 

IPsec tunnel idle timer

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 inter- face IP addresses.

Specify an IP address for the local end of the VPN tunnel. Select one of the following:

Local Gateway IP

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 com- binations. 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 authen- ticity 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 com- bination, use the Add button beside the fields for the second combination.

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

KeylifEnter 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 sup- ply to the VPN server during the Phase 1 exchange.

If the FortiGate unit will act as a VPN client, and you are using security cer- tificates for authentication, select the distinguished name (DN) of the local server certificate that the FortiGate unit will use for authentication pur- poses.

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

This option supports the authentication of dialup clients. It is available for IKE v1 only.

XAutDisable — 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 imple- mentation that supports the NAT-T RFC.

Keepalive Frequency               If you enabled NATtraversal, 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 noti- fication whenever a tunnel goes up or down, or to keep the tunnel con- nection 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.

 

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

 

To enable or disable IKE fragmentation – CLI

config vpn ipsec phase1-interface edit 1

set fragmentation [enable | disable]

next end

 


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

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

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.

 

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

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.

 

Policybased VPNs

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

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

 

Comparing policy-based or route-based VPNs

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

The main difference is in the security policy.

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

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

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

 

Comparison of policy-based and route-based VPNs

 

Features Policy-based Route-based
 

Both NAT and transparent modes available

 

Yes

 

NAT mode only

 

L2TPoverIPsec supported

 

Yes

 

No

 

GREoverIPsec 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

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 con- figurations

Standard one-to-one VPN between two FortiGate units. See Gateway-to- gateway configurations on page 1655.

Hub-and-spoke configurations     One central FortiGate unit has multiple VPNs to other remote FortiGate units. See Hub-and-spoke configurations on page 1671.

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 estab- lishing a tunnel. See Dynamic DNS configuration on page 1688.

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

Similar to FortiClient dialup-client configurations but with more gateway-to- gateway settings such as unique user authentication for multiple users on a single VPN tunnel. See FortiGate dialup-client configurations on page 1716.

Secure web browsing performed by dialup VPN clients, and/or hosts behind a remote VPN peer. See Internet-browsing configuration on page 1729.

 

Topology                                 Description

Redundant VPN con- figurations

Options for supporting redundant and partially redundant IPsec VPNs, using route-based approaches. See Redundant VPN configurations on page 1734.

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

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

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.

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 concepts

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

Security Association

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.

 

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

  • This site is behind NAT
  • The remote site is behind NAT

Static tunnel between this FortiGate and a remote FortiGate.

 

Cisco

  • No NAT between sites
  • This site is behind NAT
  • The remote site is behind NAT

Static tunnel between this FortiGate and a remote Cisco firewall.

 

VPN Type                Remote Device Type               NAT Options                   Description
 

Remote Access

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Custom

 

FortiClient VPN for OS X,         N/A                                     On-demand tunnel for

Windows, and Android                                                        users using the FortiCli- ent software.

 

iOS Native                                  N/A                                     On-demand tunnel for iPhone/iPad users using the native iOS IPsec cli- ent.

 

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 Client                               N/A                                     On-demand tunnel for users using the Cisco IPsec client.

 

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.

 

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.

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

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:

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

 

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)

ESPAES (256, 192, or 128),ESP-SHA-HMAC, or MD5               73

ESPAES (256, 192, or 128)                                                           61

 

IPsec Transform Set IPsec Overhead (Max. bytes)
 

ESP3DES, ESP-DES

 

45

 

ESP-(DES or 3DES), ESP-SHA-HMAC, or MD5

 

57

 

ESPNull, ESP-SHA-HMAC, or MD5

 

45

 

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

  • 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 select- ing the “Dialup User” option.

Preshared key                           This must be the same at both ends. It is used to encrypt Phase 1 authen- tication 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 1624.

 

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

 

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.

 

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 1624, 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.
  • Does not support Peer Options or Local ID.
  • Does not allow Extended Authentication (XAUTH).
  • Allows you to select only one Diffie-Hellman Group.
  • Uses less bandwidth.

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

 

IKEv1

Phase 1

A peer, identifed 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 preshared keys or digital certificates. You can increase access security further using peer identifiers, certificate distinguished names, group names, or the FortiGate extended authentication (XAuth) option for authentication purposes. Basically, Phase 1 authenticates a remote peer and sets up a secure communication channel for establishing Phase 2, which negotiates the IPsec SA.

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

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

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

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 1642 and Phase 2 parameters on page 1642).
  • 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 1642.
  • 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 1642.

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

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

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

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

 

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.

 

Support for IKEv2 session resumption described in RFC 5723

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 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-by-value”, whereby all information necessary to restore the state of a particular IKE SA is stored in the ticket and sent to the client.

 


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!

Chapter 14 – IPsec VPN

Chapter 14 – IPsec VPN

 

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.

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


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!

Configuring FGSP HA

Configuring FGSP HA

You configure FGSP HA separately for each virtual domain to be synchronized. If virtual domain configuration is not enabled, you configure FGSP HA for the root virtual domain. When virtual domain configuration is enabled and you have added virtual domains you configure FGSP HA for each virtual domain to be synchronized. You don’t have to synchronize all virtual domains.

You must configure FGSP HA and network settings on both peers. Once you establish the initial configuration, the configurations of both FortiGate units are synchronized so when you change the configuration of one, the changes are synchronized to the other.

On each FortiGate unit, configuring FGSP HA consists of selecting the virtual domains to be synchronized using the syncvd field, selecting the virtual domain on the other peer that receives the synchronization packets using the peervd field, and setting the IP address of the interface in the peer unit that receives the synchronization packets using the peerip field. The interface with the peerip must be in the peervd virtual domain.

The syncvd and peervd settings must be the same on both peers. However, the peerip settings will be different because the peerip setting on the first peer includes the IP address of an interface on the second peer. And the peerip setting on the second peer includes the IP address of an interface on the first peer.

For FGSP HA to work properly all synchronized virtual domains must be added to both peers. The names of the matching interfaces in each virtual domain must also be the same; this includes the names of matching VLAN interfaces. Note that the index numbers of the matching interfaces and VLAN interfaces can be different. Also the VLAN IDs of the matching VLAN interfaces can be different.

 

Configuring the session synchronization link

When FGSP HA is operating, the peers share session information over an Ethernet link between the peers similar to an HA heartbeat link. Usually you would use the same interface on each peer for session synchronization. You should connect the session synchronization interfaces directly without using a switch or other networking equipment. For FortiGate-5000 systems you can use a backplane interface as the session synchronization link.

You can use different interfaces on each peer for session synchronization links. Also, if you have multiple sessions synchronization configurations, you can have multiple links between the peers. In fact if you are synchronizing a lot of sessions, you may want to configure and connect multiple session synchronization links to distribute session synchronization traffic to these multiple links.

You cannot configure backup session synchronization links. Each configuration only includes one session synchronization link.

The session synchronization link should always be maintained. If session synchronization communication is interrupted and a failure occurs, sessions will not failover and data could be lost.

Session synchronization traffic can use a considerable amount of network bandwidth. If possible, session synchronization link interfaces should only be used for session synchronization traffic and not for data traffic.

 

Basic example configuration

The following configuration example shows how to configure basic FGSP HA for the two peer FortiGate units shown below. The host names of peers are peer_1 and peer_2. Both peers are configured with two virtual domains: root and vdom_1. All sessions processed by vdom_1 are synchronized. The synchronization link interface is port3 which is in the root virtual domain. The IP address of port3 on peer_1 is 10.10.10.1. The IP address of port3 on peer_2 is 10.10.10.2.

Also on both peers, port1 and port2 are added to vdom_1. On peer_1 the IP address of port1 is set to 192.168.20.1 and the IP address of port2 is set to 172.110.20.1. On peer_2 the IP address of port1 is set to 192.168.20.2 and the IP address of port2 is set to 172.110.20.2.

 

Example FGSP HA network configuration

example-fgsp-ha-network-config

 

To configure FGSP HA

1. Configure the load balancer or router to send all sessions to peer_1.

2. Configure the load balancer or router to send all traffic to peer_2 if peer_1 fails.

3. Use normal FortiGate configuration steps on peer_1:

  • Enable virtual domain configuration.
  • Add the vdom_1 virtual domain.
  • Add port1 and port2 to the vdom_1 virtual domain and configure these interfaces.
  • Set the IP address of port1 to 192.168.20.1. l  Set the IP address of port2 to 172.110.20.1. l  Set the IP address of port3 to 10.10.10.1.
  • Add route mode security policies between port1 and port2 to vdom_1.

4. Enter the following commands to configure session synchronization for peer_1

config system cluster-sync edit 1

set peerip 10.10.10.2 set peervd root

set syncvd vdom_1

end

5. Use normal FortiGate configuration steps on peer_2:

  • Enable virtual domain configuration.
  • Add the vdom_1 virtual domain.
  • Add port1 and port2 to the vdom_1 virtual domain and configure these interfaces.
  • Set the IP address of port1 to 192.168.20.2. l  Set the IP address of port2 to 172.110.20.2. l  Set the IP address of port3 to 10.10.10.1.
  • Add route mode security policies between port1 and port2 to vdom_1.

6. Enter the following command to configure session synchronization for peer_1

config system cluster-sync edit 1

set peerip 10.10.10.1 set peervd root

set syncvd vdom_1

end

Now that the FortiGate units are connected and configured their configurations are synchronized, so when you make a configuration change on one FortiGate unit it is synchronized to the other one.

 

To add filters

You can add a filter to this basic configuration if you only want to synchronize some TCP sessions. For example you can enter the following command to add a filter so that only HTTP sessions are synchronized:

config system cluster-sync edit 1

config filter

set service HTTP

end

end

You can also add a filter to control the source and destination addresses of the IPv4 packets that are synchronized. For example you can enter the following command to add a filter so that only sessions with source addresses in the range 10.10.10.100 to 10.10.10.200 are synchronized.

config system cluster-sync edit 1

config filter

set srcaddr 10.10.10.100 10.10.10.200 end

end

You can also add a filter to control the source and destination addresses of the IPv6 packets that are synchronized. For example you can enter the following command to add a filter so that only sessions with destination addresses in the range 2001:db8:0:2::/64 are synchronized.

config system cluster-sync edit 1

config filter

set dstaddr6 2001:db8:0:2::/64 end

end

 

To synchronize UDP and ICMP sessions

You enter the following command to add synchronization of UDP and ICMP sessions to this configuration:

config system ha

set session-pickup enable

set session-pickup-connectionless enable end

 

To synchronize the configuration

Enter the following command to enable configuration synchronization.

config system ha

set standalone-config-sync enable end

 

Verifying FGSP configuration and synchronization

You can use the following diagnose commands to verify that the FGSP and its synchronization functions are operating correctly.

 

FGSP configuration summary and status

Enter the following command to display a summary of the FGSP configuration and synchronization status:

diagnose sys session sync

sync_ctx: sync_started=1, sync_tcp=1, sync_others=1, sync_expectation=1, sync_redir=0, sync_nat=1, stdalone_sessync=0. sync: create=12:0, update=0, delete=0:0, query=14

recv: create=14:0, update=0, delete=0:0, query=12

ses pkts: send=0, alloc_fail=0, recv=0, recv_err=0 sz_err=0 nCfg_sess_sync_num=5, mtu=16000

sync_filter:

1: vd=0, szone=0, dzone=0, saddr=0.0.0.0:0.0.0.0, daddr=0.0.0.0:0.0.0.0,

sync_started=1 shows that synchronization is working. If this is set to 0 then something is not correct with session synchronization and synchronization has not been able to start because of it.

sync_tcp=1, sync_others=1, sync_expectation=1, and sync_nat=1 show that the FGSP has been configured to synchronize TCP, connectionless, asymmetric, and NAT sessions.

sync: create=12:0 and recv: create=14:0 show that this FortiGate has synchronized 12 sessions to its peer and has received 14 sessions from its peer.

sync_filter shows the configured FGSP filter. In this case no filter has been created so all sessions are synchronized.

vd=0 indicates that root VDOM sessions are synchronized.

 

Verifying that sessions are synchronized

Enter the command diagnose sys session list to display information about the sessions being processed by the FortiGate. In the command output look for sessions that should be synchronized and make sure they contain output lines that include synced for example, state=log may_dirty ndr synced) to confirm that they are being synchronized by the FGSP.

 

diagnose sys session list

session info: proto=6 proto_state=05 duration=469 expire=0 timeout=3600 flags=00000000 sockflag=00000000 sockport=21 av_idx=0 use=4

origin-shaper= reply-shaper= per_ip_shaper=

ha_id=0 policy_dir=0 tunnel=/

state=log may_dirty ndr synced

statistic(bytes/packets/allow_err): org=544/9/1 reply=621/7/0 tuples=2 orgin->sink: org pre->post, reply pre->post dev=46->45/45->46 gwy=10.2.2.1/10.1.1.1

hook=pre dir=org act=noop 192.168.1.50:45327->172.16.1.100:21(0.0.0.0:0) hook=post dir=reply act=noop 172.16.1.100:21->192.168.1.50:45327(0.0.0.0:0) pos/(before,after) 0/(0,0), 0/(0,0)

misc=0 policy_id=1 id_policy_id=0 auth_info=0 chk_client_info=0 vd=0 serial=00002deb tos=ff/ff ips_view=1 app_list=2000 app=16427 dd_type=0 dd_mode=0

per_ip_bandwidth meter: addr=192.168.1.50, bps=633

 


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!

FortiGate Session Life Support Protocol (FGSP)

FortiGate Session Life Support Protocol (FGSP)

In a network that already includes load balancing (either with load balancers or routers) for traffic redundancy, two identical FortiGate units can be integrated into the load balancing configuration using the FortiGate Session Life Support Protocol (FGSP). The external load balancers or routers can distribute sessions among the FortiGate units and the FGSP performs session synchronization of IPv4 and IPv6 TCP, UDP, ICMP, expectation, and NAT sessions and IPsec tunnels to keep the session tables of both FortiGate units synchronized.

You can use the config system cluster-sync command to configure the FortiGate Session Life Support Protocol (FGSP) (previously called TCP session synchronization or standalone session synchronization) between two FortiGate units. The two FortiGate units must be the same model. The FGSP synchronizes both IPv4 and IPv6 TCP, UDP, ICMP, expectation, and NAT sessions and IPsec tunnels. You can use this feature with external routers or load balancers configured to distribute or load balance sessions between two peer FortiGate units. If one of the peers fails, session failover occurs and active sessions fail over to the peer that is still operating. This failover occurs without any loss of data. As well, the external routers or load balancers will detect the failover and re-distribute all sessions to the peer that is still operating.

In previous versions of FortiOS the FGSP was called TCP session synchronization or standalone session synchronization. However, the FGSP has been expanded to include configuration synchronization and session synchronization of connectionless sessions, expectation sessions, and NAT sessions and IPsec tunnels.

You cannot configure FGSP HA when FGCP HA is enabled. However FGSP HA is com- patible with VRRP.

FGSP or standalone session synchronization is not supported if the FortiGate units are running different firmware versions.

The FGSP can be used instead of FGCP HA to provide session synchronization between two peer FortiGate units. If the external load balancers direct all sessions to one peer the affect is similar to active-passive FGCP HA. If external load balancers or routers load balance traffic to both peers, the effect is similar to active-active FGCP HA. The load balancers should be configured so that all of the packets for any given session are processed by the same peer. This includes return packets.

 

FGSP HA

fgsp-ha

 

 

 

By default, FGSP synchronizes all IPv4 and IPv6 TCP sessions, IPsec tunnels, and also synchronizes the configuration of the FortiGate units.

You can optionally enable session pickup to synchronize connectionless (UDP and ICMP) sessions, expectation sessions, and NAT sessions. If you do not enable session pickup, the FGSP does not share session tables for the particular session type and sessions do not resume after a failover. All sessions that are interrupted by the failover and must be re-established at the application level. Many protocols can successfully restart sessions with little, or no, loss of data. Others may not recover easily. Enable session pickup for sessions that may be difficult to reestablish. Since session pickup requires FortiGate resources, only enable this feature for sessions that you need to have synchronized.

You can also optionally add filters to control which sessions are synchronized. You can add filters to only synchronize packets from specified source and destination addresses, specified source and destination interfaces, and specified services.

Load balancing and session failover is done by external routers or load balancers instead of by the FGSP. The FortiGate units just perform session synchronization to support session failover.

 

Synchronizing the configuration

The FGSP also includes configuration synchronization, allowing you to make configuration changes once for both FortiGate units instead of requiring you to make duplicate configuration changes on each FortiGate unit. Settings that identify the FortiGate unit to the network, for example, interface IP addresses and BGP neighbor settings, are not synchronized so each FortiGate unit maintains its identity on the network.

By default configuration synchronization is disabled. You can use the following command to enable it.

config system ha

set standalone-config-sync enable end

 

IPsec tunnel synchronization

When you use the config system cluster-sync command to enable FGSP, IPsec keys and other runtime data (but not actual tunnel sessions) are synchronized between cluster units . This means that if one of the cluster units goes down the cluster unit that is still operating can quickly get IPsec tunnels re-established without re-negotiating them. However, after a failover all existing tunnel sessions on the failed FortiGate have to be restarted on the still operating FortiGate.

IPsec tunnel sync only supports dialup IPsec. The interfaces on both FortiGates that are tunnel endpoints must have the same IP addresses and external routers must be configured to load balance IPsec tunnel sessions to the FortiGates in the cluster.

 

Synchronizing UDP and ICMP (connectionless) sessions

In many configurations, due to their non-stateful nature, UDP and ICMP sessions don’t need to be synchronized to naturally failover. However, if its required you can configure the FGSP to synchronize UDP and ICMP sessions by entering the following command:

config system ha

set session-pickup enable

set session-pickup-connectionless enable end

 

Synchronizing NAT sessions

By default, NAT session are not synchronized. However, the FGSP can synchronize NAT session if you enter the following command:

config system ha

set session-pickup enable

set session-pickup-nat enable end

However, if you want NAT sessions to resume after a failover you should not configure NAT to use the destination interface IP address since the FGSP FortiGate units have different IP addresses. With this configuration, after a failover all sessions that include the IP addresses of interfaces on the failed FortiGate unit will have nowhere to go since the IP addresses of the failed FortiGate unit will no longer be on the network.

Instead, in an FGSP configuration, if you want NAT sessions to failover you should use IP pools with the type set to overload (which is the default IP pool type). For example:

config firewall ippool edit FGSP-pool

set type overload

set startip 172.20.120.10 set endip 172.20.120.20

end

Then when you configure NAT firewall policies, turn on NAT and select to use dynamic IP pool and select the IP Pool that you added. Add the same IP pools and firewall policies to both FortiGate units.

 

Synchronizing expectation (asymmetric) sessions

By default, expectation sessions (or asymmetric sessions) are not synchronized. Normally, session synchronization cannot be asymmetric because it is stateful. So all of the packets of a given session must be processed on the same peer. This includes return packets.

However, if you have an asymmetric routing configuration, you can enter the following command to synchronize asymmetric sessions by dynamically detecting asymmetric sessions and disabling anti-reply for these sessions.

config system ha

set session-pickup enable

set session-pickup-expectation enable end

The FGSP enforces firewall policies for asymmetric traffic, including cases where the TCP 3-way handshake is split between two FortiGates. For example, FGT-A receives the TCP-SYN, FGT-B receives the TCP-SYN-ACK, and FGT-A receives the TCP-ACK. Under normal conditions a firewall will drop this connection since the 3-way handshake was not seen by the same firewall. However two FortiGates with FGSP configured will be able to properly pass this traffic since the firewall sessions are synchronized.

If traffic will be highly asymmetric, as described above, the following command must be enabled on both FortiGates.

config system ha

set session-pickup enable

set session-pickup-expectation enable end

This asymmetric function can also work with connectionless UDP and ICMP traffic. The following command needs to enabled on both FortiGates.

 

config system ha

set session-pickup enable

set session-pickup-connectionless enable end

Synchronizing asymmetric traffic can be very useful in situations where multiple Internet connections from different ISPs are spread across two FortiGates. Since it is typically not possible to guarantee Internet bound traffic leaving via an ISP will return using the exact same ISP, the FGSP provides critical firewall functions in this situation.

The FGSP also has applications in virtualized computing environments where virtualized hosts move between data centers. The firewall session synchronization features of FGSP allow for more flexibility than in traditional firewalling functions.

 

Security profile flow-based inspection and asymmetric traffic

Security profile inspection (flow or proxy based) for a session is not expected to work properly if the traffic in the session is balanced across more than one FortiGate in either direction. Flow-based inspection should be used in FGSP deployments.

For an environment where traffic is symmetric, security profile inspection can be used with the following limitations:

  • No session synchronization for the sessions inspected using proxy-based inspection. Sessions will drop and need to be reestablished after data path failover.
  • Sessions with flow-based inspection will failover; however, inspection of failed over sessions after the failover may not work.

A single FortiGate must see both the request and reply traffic for security profile inspection to function correctly. For environments where asymmetric traffic is expected, security profile inspection should not be used.

 

Notes and limitations

FGSP HA has the following limitations:

  • The FGSP is a global configuration option. As a result you can only add one service to a filter configuration. You cannot add custom services or service groups even if virtual domains are not enabled.
  • You can only add one filter configuration to a given FGSP configuration. However, you can add multiple filters by adding multiple identical FGSP configurations, each one with a different filter configuration.
  • Sessions accepted by security policies with security profiles configured are not synchronized.
  • FGSP HA is configured from the CLI.
  • FGSP HA is available for FortiGate units or virtual domains operating in NAT/Route or Transparent mode. NAT sessions are not synchronized in either mode (unless NAT synchronization is enabled as described in Synchronizing NAT sessions on page 1581). In NAT/Route mode, only sessions for route mode security policies are synchronized. In Transparent mode, only sessions for normal Transparent mode policies are synchronized.
  • FGSP HA is supported for traffic on physical interfaces, VLAN interfaces, zones, aggregate interfaces, and NPx (NP4, NP6 etc.) accelerated interfaces. The FGSP has not been tested for inter-vdom links, between HA clusters, and for redundant interfaces.
  • The names of the matching interfaces, including VLAN interfaces, aggregate interfaces and so on, must be the same on both peers.

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!