Internet-browsing configuration

This section explains how to support secure web browsing performed by dialup VPN clients, and/or 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.

The following topics are included in this section:

Configuration overview

Routing all remote traffic through the VPN tunnel

Configuration overview

A VPN provides secure access to a private network behind the FortiGate unit. You can also enable VPN clients to access the Internet securely. The FortiGate unit inspects and processes all traffic between the VPN clients and hosts on the Internet according to the Internet browsing policy. This is accomplished even though the same FortiGate interface is used for both encrypted VPN client traffic and unencrypted Internet traffic.

In the figure below, FortiGate_1 enables secure Internet browsing for FortiClient Endpoint Security users such as Dialup_1 and users on the Site_2 network behind FortiGate_2, which could be a VPN peer or a dialup client.

Example Internet-browsing configuration

Internet-browsing configuration                                                                                              Configuration overview

You can adapt any of the following configurations to provide secure Internet browsing:

• A gateway-to-gateway configuration (see Gateway-to-gateway configurations on page 1)
• A FortiClient dialup-client configuration (see FortiClient dialup-client configurations on page 1)
• A FortiGate dialup-client configuration (see FortiGate dialup-client configurations on page 1)

The procedures in this section assume that one of these configurations is in place, and that it is operating properly.

To create an internet-browsing configuration based on an existing gateway-to-gateway configuration, you must edit the gateway-to-gateway configuration as follows:

• On the FortiGate unit that will provide Internet access, create an Internet browsing security policy. See Configuration overview on page 153, below.
• Configure the remote peer or client to route all traffic through the VPN tunnel. You can do this on a FortiGate unit or on a FortiClient Endpoint Security application. See Configuration overview on page 153.

Creating an Internet browsing security policy

On the FortiGate unit that acts as a VPN server and will provide secure access to the Internet, you must create an Internet browsing security policy. This policy differs depending on whether your gateway-to-gateway configuration is policy-based or route-based.

Creating an Internet browsing policy – policy-based VPN

1. Go to Policy & Objects > IPv4 Policy and select Create New.
2. Enter the following information and then select OK:

Name	Enter an appropriate name for the policy.
Incoming Interface	The interface to which the VPN tunnel is bound.
Outgoing Interface	The interface to which the VPN tunnel is bound.
Source	The internal range address of the remote spoke site.
Destination Address	all
Action	Select IPsec. Under VPN Tunnel, select the tunnel that provides access to the private network behind the FortiGate unit. Select Allow traffic to be initiated from the remote site.
NAT	Enable NAT.

Creating an Internet browsing policy – route-based VPN

1. Go to Policy & Objects > IPv4 Policy and select Create New.
2. Enter the following information and then select OK:

Name

Enter an appropriate name for the policy.

Routing all remote traffic through the VPN tunnel                                                          Internet-browsing configuration

Incoming Interface	The IPsec VPN interface.
Outgoing Interface	The interface that connects to the Internet. The virtual IPsec interface is configured on this physical interface.
Source	The internal range address of the remote spoke site.
Destination Address	all
Action	ACCEPT
NAT	Enable NAT.

The VPN clients must be configured to route all Internet traffic through the VPN tunnel.

Routing all remote traffic through the VPN tunnel

To make use of the Internet browsing configuration on the VPN server, the VPN peer or client must route all traffic through the VPN tunnel. Usually, only the traffic destined for the private network behind the FortiGate VPN server is sent through the tunnel.

The remote end of the VPN can be a FortiGate unit that acts as a peer in a gateway-to-gateway configuration, or a FortiClient application that protects an individual client PC.

• To configure a remote peer FortiGate unit for Internet browsing via VPN, see Configuring a FortiGate remote peer to support Internet browsing on page 155.
• To configure a FortiClient Endpoint Security application for Internet browsing via VPN, see Configuring a FortiClient application to support Internet browsing on page 156.

These procedures assume that your VPN connection to the protected private network is working and that you have configured the FortiGate VPN server for Internet browsing as described in Configuration overview  on page 153.

Configuring a FortiGate remote peer to support Internet browsing

The configuration changes to send all traffic through the VPN differ for policy-based and route-based VPNs.

Routing all traffic through a policy-based VPN

1. At the FortiGate dialup client, go to Policy & Objects > IPv4 Policy.
2. Select the IPsec security policy and then select Edit.
3. From the Destination Address list, select all.
4. Select OK.

Packets are routed through the VPN tunnel, not just those destined for the protected private network.

Routing all traffic through a route-based VPN

1. At the FortiGate dialup client, go to Network > Static Routes.
2. Select the default route (destination IP 0.0.0.0) and then select Edit. If there is no default route, select Create New. Enter the following information and select OK:

155

 

Internet-browsing configuration                                                        Routing all remote traffic through the VPN tunnel

Destination IP/Mask	Set to Subnet and enter 0.0.0.0/0.0.0.0 in the field provided.
Device	Select the IPsec virtual interface.
Administrative Distance	Leave at default.

All packets are routed through the VPN tunnel, not just packets destined for the protected private network.

Configuring a FortiClient application to support Internet browsing

By default, the FortiClient application configures the PC so that traffic destined for the remote protected network passes through the VPN tunnel but all other traffic is sent to the default gateway. You need to modify the FortiClient settings so that it configures the PC to route all outbound traffic through the VPN.

Routing all traffic through VPN – FortiClient application

1. At the remote host, start FortiClient.
2. Go to Remote Access.
3. Select the definition that connects FortiClient to the FortiGate dialup server, select the Settings icon, and select Edit the selected connection.
4. In the Edit VPN Connection dialog box, select Advanced Settings.
5. In the Remote Network group, select Add.
6. In the IP and Subnet Mask fields, type 0.0.0/0.0.0.0 and select OK.

The address is added to the Remote Network list. The first destination IP address in the list establishes a VPN tunnel. The second destination address (0.0.0.0/0.0.0.0 in this case) forces all other traffic through the VPN tunnel.

7. Select OK.

Supporting IKE Mode Config clients

IKE Mode Config is an alternative to DHCP over IPsec. A FortiGate unit can be configured as either an IKE Mode Config server or client. This chapter contains the following sections:

IKE Mode Config overview

Automatic configuration overview

IKE Mode Config method

IKE Mode Config overview

Dialup VPN clients connect to a FortiGate unit that acts as a VPN server, providing the client the necessary configuration information to establish a VPN tunnel. The configuration information typically includes a virtual IP address, netmask, and DNS server address.

IKE Mode Config is available only for VPNs that are route-based, also known as interface-based. A FortiGate unit can function as either an IKE Configuration Method server or client. IKE Mode Config is configurable only in the CLI.

Automatic configuration overview

VPN configuration for remote clients is simpler if it is automated. Several protocols support automatic configuration:

• The Fortinet FortiClient Endpoint Security application can completely configure a VPN connection with a suitably configured FortiGate unit given only the FortiGate unit’s address. This protocol is exclusive to Fortinet. For more information, see FortiClient dialup-client configurations on page 1.
• DHCP over IPsec can assign an IP address, Domain, DNS and WINS addresses. The user must first configure IPsec parameters such as gateway address, encryption and authentication algorithms.
• IKE Mode Config can configure host IP address, Domain, DNS and WINS addresses. The user must first configure IPsec parameters such as gateway address, encryption and authentication algorithms. Several network equipment vendors support IKE Mode Config, which is described in the ISAKMP Configuration Method document draft-dukesike-mode-cfg-02.txt.

This chapter describes how to configure a FortiGate unit as either an IKE Mode Config server or client.

IKE Mode Config method

IKE Mode Config is configured with the CLI command config vpn ipsec phase1-interface. The mode-cfg variable enables IKE Mode Config. The type field determines whether you are creating an IKE Mode Config server or a client. Setting type to dynamic creates a server configuration, otherwise the configuration is a client.

Creating an IKE Mode Config client

If the FortiGate unit will connect as a dialup client to a remote gateway that supports IKE Mode Config, the relevant vpn ipsec phase1-interface variables are as follows:

Variable	Description
ike-version 1	IKE v1 is the default for FortiGate IPsec VPNs. IKE Mode Config is also compatible with IKE v2 (RFC 4306). Use syntax ike-version 2.
mode-cfg enable	Enable IKE Mode Config.
type {ddns | static}	If you set type to dynamic, an IKE Mode Config server is created.
assign-ip {enable | disable}	Enable to request an IP address from the server.
interface <interface_ name>	This is a regular IPsec VPN field. Specify the physical, aggregate, or VLAN interface to which the IPsec tunnel will be bound.
proposal <encryption_ combination>	This is a regular IPsec VPN field that determines the encryption and authentication settings that the client will accept. For more information, see Phase 1 parameters on page 52.
ip-version <4 | 6>	This is a regular IPsec VPN field. By default, IPsec VPNs use IPv4 addressing. You can set ip-version to 6 to create a VPN with IPv6 addressing.

For a complete list of available variables, see the CLI Reference.

IKE Mode Config client example – CLI

In this example, the FortiGate unit connects to a VPN gateway with a static IP address that can be reached through Port 1. Only the port, gateway and proposal information needs to be configured. All other configuration information will come from the IKE Mode Config server.

config vpn ipsec phase1-interface edit vpn1 set ip-version 4 set type static set remote-gw <gw_address> set interface port 1

set proposal 3des-sha1 aes128-sha1 set mode-cfg enable set assign-ip enable end

IKE Mode Config method                                                                                   Supporting IKE Mode Config clients

Creating an IKE Mode Config server

If the FortiGate unit will accept connection requests from dialup clients that support IKE Mode Config, the following vpn ipsec phase1-interface settings are required before any other configuration is attempted:

Variable	Description
ike-version 1	IKE v1 is the default for FortiGate IPsec VPNs. IKE Mode Config is also compatible with IKE v2 (RFC 4306). Use syntax ike-version 2.
mode-cfg enable	Enable IKE Mode Config.
type dynamic	Any other setting creates an IKE Mode Config client.
interface <interface_ name>	This is a regular IPsec VPN field. Specify the physical, aggregate, or VLAN interface to which the IPsec tunnel will be bound.
proposal <encryption_ combination>	This is a regular IPsec VPN field that determines the encryption and authentication settings that the server will accept. For more information, see Phase 1 parameters on page 52.
ip-version <4 | 6>	This is a regular IPsec VPN field. By default, IPsec VPNs use IPv4 addressing. You can set ip-version to 6 to create a VPN with IPv6 addressing.

IKE Mode Config server example – CLI

In this example, the FortiGate unit assigns IKE Mode Config clients addresses in the range of 10.11.101.160 through 10.11.101.180. DNS and WINS server addresses are also provided. The public interface of the FortiGate unit is Port 1.

When IKE Mode-Configuration is enabled, multiple server IPs can be defined in IPsec Phase 1.

The ipv4-split-include  variable specifies a firewall address that represents the networks to which the clients will have access. This destination IP address information is sent to the clients.

Only the CLI fields required for IKE Mode Config are shown here. For detailed information about these variables, see the FortiGate CLI Reference.

config vpn ipsec phase1-interface edit “vpn-p1” set type dynamic set interface “wan1” set xauthtype auto set mode aggressive set mode-cfg enable

set proposal 3des-sha1 aes128-sha1 set dpd disable set dhgrp 2

set xauthexpire on-rekey set authusrgrp “FG-Group1” set ipv4-start-ip 10.10.10.10 set ipv4-end-ip 10.10.10.20 set ipv4-dns-server1 1.1.1.1 set ipv4-dns-server2 2.2.2.2 set ipv4-dns-server3 3.3.3.3 set ipv4-wins-server1 4.4.4.4 set ipv4-wins-server2 5.5.5.5 set domain “fgt1c-domain” set banner “fgt111C-banner”

set backup-gateway “100.100.100.1” “host1.com” “host2” set ipv4-split-include OfficeLAN

end

 

IP address assignment

After you have enabled the basic configuration, you can configure IP address assignment for clients, as well as DNS and WINS server assignment. Usually you will want to assign IP addresses to clients.

The simplest method to assign IP addresses to clients is to assign addresses from a specific range, similar to a DHCP server.

If your clients are authenticated by a RADIUS server, you can obtain the user’s IP address assignment from the Framed-IP-Address attribute. The user must be authenticated using XAuth.

IKE Mode Config can also use a remote DHCP server to assign the client IP addresses. Up to eight addresses can be selected for either IPv4 or IPv6. After the DHCP proxy has been configured, the assign-ip-from command is used to assign IP addresses via DHCP.

Assigning IP addresses from an address range – CLI

If your VPN uses IPv4 addresses,

config vpn ipsec phase1-interface edit vpn1 set mode-cfg-ipversion 4 set assign-ip enable set assign-ip-type ip set assign-ip-from range set ipv4-start-ip <range_start> set ipv4-end-ip <range_end> set ipv4-netmask <netmask>

end

 

If your VPN uses IPv6 addresses,

config vpn ipsec phase1-interface edit vpn1 set mode-cfg-ipversion 6 set assign-ip enable set assign-ip-type ip set assign-ip-from range set ipv6-start-ip <range_start> set ipv6-end-ip <range_end> end

IKE Mode Config method                                                                                   Supporting IKE Mode Config clients

Assigning IP addresses from a RADIUS server – CLI

The users must be authenticated by a RADIUS server and assigned to the FortiGate user group <grpname>.

Since the IP address will not be static, type is set to dynamic, and mode-cfg is enabled. This is IKE

Configuration Method so that compatible clients can configure themselves with settings that the FortiGate unit provides.

config vpn ipsec phase1-interface edit vpn1 set type dynamic set mode-cfg enable set assign-ip enable set assign-ip-from usrgrp set xauthtype auto set authusrgrp <grpname>

end

Assigning IP address from DHCP – CLI

The DHCP proxy must first be enabled for IKE Mode Config to use DHCP to assign the VPN client IP address(es).

config system settings set dhcp-proxy enable set dhcp-server-ip [ipv4 address] set dhcp6-server-ip [ipv6-address]

 

(Up to eight server addresses can be configured)

end

config vpn ipsec phase1-interface edit vpn1 set mode-cfg enable set assign-ip-from dhcp

next

end

Assigning IP address from a named firewall address/group – CLI

config vpn ipsec phase1-interface edit <name>vpn1 set type dynamic set assign-ip-from name set ipv4-name <name> set ipv6-name <name>

next

end

Certificate groups

IKE certificate groups consisting of up to four RSA certificates can be used in IKE Phase 1. Since CA and local certificates are global, the IKE daemon loads them once for all VDOMs and indexes them into trees based on subject and public key hash (for CA certificates), or certificate name (for local certicates). Certifcates are linked together based on the issuer, and certificate chains are built by traversing these links. This reduces the need to keep multiple copies of certificates that could exist in multiple chains.

IKE certificate groups can be configured through the CLI.

Configuring the IKE local ID – CLI

config vpn certificate local edit <name>

set ike-localid <string> set ike-localid-type {asnldn | fqdn} end

 

FortiGate dialup-client configurations

This section 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 having a dynamic IP address initiates a VPN tunnel with the FortiGate dialup server.

The following topics are included in this section: Configuration overview

Configuration overview

A dialup client can be a FortiGate unit. The FortiGate dialup client typically obtains a dynamic IP address from an ISP through the Dynamic Host Configuration Protocol (DHCP) or Point-to-Point Protocol over Ethernet (PPPoE) before initiating a connection to a FortiGate dialup server.

Example FortiGate dialup-client configuration

In a dialup-client configuration, the FortiGate dialup server does not rely on a Phase 1 remote gateway address to establish an IPsec VPN connection with dialup clients. As long as authentication is successful and the IPsec security policy associated with the tunnel permits access, the tunnel is established.

Several different ways to authenticate dialup clients and restrict access to private networks based on client credentials are available. To authenticate FortiGate dialup clients and help to distinguish them from FortiClient dialup clients when multiple clients will be connecting to the VPN through the same tunnel, best practices dictate that you assign a unique identifier (local ID or peer ID) to each FortiGate dialup client. For more information, see Phase 1 parameters on page 52.

 

Whenever you add a unique identifier (local ID) to a FortiGate dialup client for identification purposes, you must select Aggressive mode on the FortiGate dialup server and also specify the identifier as a peer ID on the FortiGate dialup server. For more information, see Phase 1 parameters on page 52.

Users behind the FortiGate dialup server cannot initiate the tunnel because the FortiGate dialup client does not have a static IP address. After the tunnel is initiated by users behind the FortiGate dialup client, traffic from the private network behind the FortiGate dialup server can be sent to the private network behind the FortiGate dialup client.

Encrypted packets from the FortiGate dialup client are addressed to the public interface of the dialup server. Encrypted packets from the dialup server are addressed either to the public IP address of the FortiGate dialup client (if the dialup client connects to the Internet directly), or if the FortiGate dialup client is behind a NAT device, encrypted packets from the dialup server are addressed to the public IP address of the NAT device.

If a router with NAT capabilities is in front of the FortiGate dialup client, the router must be NAT-T compatible for encrypted traffic to pass through the NAT device. For more information, see Phase 1 parameters on page 52.

When the FortiGate dialup server decrypts a packet from the FortiGate dialup client, the source address in the IP header may be one of the following values, depending on the configuration of the network at the far end of the tunnel:

• If the FortiGate dialup client connects to the Internet directly, the source address will be the private IP address of a host or server on the network behind the FortiGate dialup client.
• If the FortiGate dialup client is behind a NAT device, the source address will be the public IP address of the NAT device.

In some cases, computers on the private network behind the FortiGate dialup client may (by co-incidence) have IP addresses that are already used by computers on the network behind the FortiGate dialup server. In this type of situation (ambiguous routing), conflicts may occur in one or both of the FortiGate routing tables and traffic destined for the remote network through the tunnel may not be sent.

In many cases, computers on the private network behind the FortiGate dialup client will most likely obtain IP addresses from a local DHCP server behind the FortiGate dialup client. However, unless the local and remote networks use different private network address spaces, unintended ambiguous routing and IP-address overlap issues may arise.

To avoid these issues, you can configure FortiGate DHCP relay on the dialup client instead of using a DHCP server on the network behind the dialup client. The FortiGate dialup client can be configured to relay DHCP requests from the local private network to a DHCP server that resides on the network behind the FortiGate dialup server. You configure the FortiGate dialup client to pass traffic from the local private network to the remote network by enabling FortiGate DHCP relay on the FortiGate dialup client interface that is connected to the local private network.

Afterward, when a computer on the network behind the dialup client broadcasts a DHCP request, the dialup client relays the message through the tunnel to the remote DHCP server. The remote DHCP server responds with a private IP address for the computer. To avoid ambiguous routing and network overlap issues, the IP addresses assigned to computers behind the dialup client cannot match the network address space used by the private network behind the FortiGate dialup server.

Preventing network overlap in a FortiGate dialup-client configuration

When the DHCP server resides on the private network behind the FortiGate dialup server, the IP destination address specified in the IPsec security policy on the FortiGate dialup client must refer to that network.

You must add a static route to the DHCP server FortiGate unit if it is not directly connected to the private network behind the FortiGate dialup server; its IP address does not match the IP address of the private network. Also, the destination address in the IPsec security policy on the FortiGate dialup client must refer to the DHCP server address. The DHCP server must be configured to assign a range of IP addresses different from the DHCP server’s local network, and also different from the private network addresses behind the FortiGate dialup server. See Routing on page 1.

FortiGate dialup-client infrastructure requirements

The requirements are:

• The FortiGate dialup server must have a static public IP address.
• NAT mode is required if you want to create a route-based VPN.
• The FortiGate dialup server may operate in either NAT mode or transparent mode to support a policy-based VPN.
• Computers on the private network behind the FortiGate dialup client can obtain IP addresses either from a DHCP server behind the FortiGate dialup client, or a DHCP server behind the FortiGate dialup server.
• If the DHCP server resides on the network behind the dialup client, the DHCP server must be configured to assign IP addresses that do not match the private network behind the FortiGate dialup server.
• If the DHCP server resides on the network behind the FortiGate dialup server, the DHCP server must be configured to assign IP addresses that do not match the private network behind the FortiGate dialup client.

Configuring the server to accept FortiGate dialup-client connections

The procedures in this section assume that computers on the private network behind the FortiGate dialup client obtain IP addresses from a local DHCP server. The assigned IP addresses do not match the private network behind the FortiGate dialup server.

In situations where IP-address overlap between the local and remote private networks is likely to occur, FortiGate DHCP relay can be configured on the FortiGate dialup client to relay DHCP requests to a DHCP server behind the FortiGate dialup server. For more information, see To configure DHCP relay on a FortiGate interface on page 1.

Configuring dialup client capability for FortiGate dialup clients involves the following general configuration steps:

• Determine which IP addresses to assign to the private network behind the FortiGate dialup client, and add the IP addresses to the DHCP server behind the FortiGate dialup client. Refer to the software supplier’s documentation to configure the DHCP server.
• Configure the FortiGate dialup server. See Configuration overview on page 139.  l Configure the FortiGate dialup client. See Configuration overview  on page 139.

Before you begin, optionally reserve a unique identifier (peer ID) for the FortiGate dialup client. The dialup client will supply this value to the FortiGate dialup server for authentication purposes during the IPsec Phase 1 exchange. In addition, the value will enable you to distinguish FortiGate dialup-client connections from FortiClient dialup-client connections. The same value must be specified on the dialup server and on the dialup client.

At the FortiGate dialup server, define the Phase 1 parameters needed to authenticate the FortiGate dialup client and establish a secure connection. See Phase 1 parameters on page 52.

1. Go to VPN > IPsec Tunnels and create the new custom tunnel or edit an existing tunnel.
2. Edit Network (full configuration options are only available once you click the Convert To Custom Tunnel button).
3. Enter these settings in particular:

Remote Gateway	Select Dialup User.
Interface	Select the interface through which clients connect to the FortiGate unit.

4. Edit Authentication and enter the following information:

Mode	If you will be assigning an ID to the FortiGate dialup client, select Aggressive.
Peer Options	If you will be assigning an ID to the FortiGate dialup client, set Accept Types to This peer ID and type the identifier that you reserved for the FortiGate dialup client into the adjacent field.

5. Define the Phase 2 parameters needed to create a VPN tunnel with the FortiGate dialup client. See Phase 2 parameters on page 72. Enter these settings in particular:

Name	Enter a name to identify this Phase 2 configuration.
Phase 1	Select the name of the Phase 1 configuration that you defined.

6. Define names for the addresses or address ranges of the private networks that the VPN links. See Defining policy addresses on page 1. Enter these settings in particular:

l Define an address name for the server, host, or network behind the FortiGate dialup server.  l Define an address name for the private network behind the FortiGate dialup client.

4. Define the security policies to permit communications between the private networks through the VPN tunnel. Route-based and policy-based VPNs require different security policies. For detailed information about creating security policies, see Defining VPN security policies on page 1.

Route-based VPN security policy

Define an ACCEPT security policy to permit communications between hosts on the private network behind the FortiGate dialup client and the private network behind this FortiGate dialup server. Because communication cannot be initiated in the opposite direction, there is only one policy.

1. Go to Policy & Objects > IPv4 Policy and select Create New.
2. Enter these settings in particular:

Name	Enter an appropriate name for the policy.
Incoming Interface	Select the VPN tunnel (IPsec interface) created in Step 1.
Outgoing Interface	Select the interface that connects to the private network behind this FortiGate unit.
Source	Select all.
Destination Address	Select all.
Action	Select ACCEPT.
NAT	Disable NAT.

Policy-based VPN security policy

1. Go to Policy & Objects > IPv4 Policy and select Create New.
2. Enter these settings in particular:

Name		Enter an appropriate name for the policy.
Incoming Interface		Select the interface that connects to the private network behind this FortiGate unit.
Outgoing Interface		Select the FortiGate unit’s public interface.
Source		Select the address name that you defined for the private network behind this FortiGate unit.
	Destination Address		Select the address name that you defined.
	Action		Select IPsec. Under VPN Tunnel, select the name of the Phase 1 configuration that you created in Step “Configuration overview ” on page 139 from the drop-down list. Select Allow traffic to be initiated from the remote site.

3. To prevent traffic from the local network from initiating the tunnel after the tunnel has been established, you need to disable the outbound VPN traffic in the CLI config firewall policy edit <policy_number> set outbound disable

end

Place the policy in the policy list above any other policies having similar source and destination addresses.

If configuring a route-based policy, configure a default route for VPN traffic on this interface.

Configuring the FortiGate dialup client

At the FortiGate dialup client, define the Phase 1 parameters needed to authenticate the dialup server and establish a secure connection. See Phase 1 parameters on page 52.

1. Go to VPN > IPsec Tunnels and create the new custom tunnel or edit an existing tunnel.
2. Edit Network (full configuration options are only available once you click the Convert To Custom Tunnel button).
3. Enter these settings in particular:

Remote Gateway	Select Static IP Address.
IP Address	Type the IP address of the dialup server’s public interface.
Interface	Select the interface that connects to the public network.
Mode	The FortiGate dialup client has a dynamic IP address, select Aggressive.
Advanced	Select to view the following options.
Local ID	If you defined a peer ID for the dialup client in the FortiGate dialup server configuration, enter the identifier of the dialup client. The value must be identical to the peer ID that you specified previously in the FortiGate dialup server configuration.

4. Edit Authentication and enter the following information:

Mode	The FortiGate dialup client has a dynamic IP address, select Aggressive.

5. Edit Phase 1 Proposal and enter the following information:

Local ID

If you defined a peer ID for the dialup client in the FortiGate dialup server configuration, enter the identifier of the dialup client. The value must be identical to the peer ID that you specified previously in the FortiGate dialup server configuration.

6. Define the Phase 2 parameters needed to create a VPN tunnel with the dialup server. See Phase 2 parameters on page 72. Enter these settings in particular:

Name	Enter a name to identify this Phase 2 configuration.
Phase 1	Select the name of the Phase 1 configuration that you defined.

7. Define names for the addresses or address ranges of the private networks that the VPN links. See Defining policy addresses on page 1. Enter these settings in particular:

l Define an address name for the server, host, or network behind the FortiGate dialup server.  l Define an address name for the private network behind the FortiGate dialup client.

4. Define security policies to permit communication between the private networks through the VPN tunnel. Routebased and policy-based VPNs require different security policies. For detailed information about creating security policies, see Defining VPN security policies on page 1.

Route-based VPN security policy

Define an ACCEPT security policy to permit communications between hosts on the private network behind this FortiGate dialup client and the private network behind the FortiGate dialup server. Because communication cannot be initiated in the opposite direction, there is only one policy.

1. Go to Policy & Objects > IPv4 Policy and select Create New.
2. Enter these settings in particular:

Name	Enter an appropriate name for the policy.
Incoming Interface	Select the interface that connects to the private network behind this FortiGate unit.
Outgoing Interface	Select the VPN tunnel (IPsec interface) created in Step 1.
Source	Select all.
Destination Address	Select all.
Action	Select ACCEPT.
NAT	Disable NAT.

Policy-based VPN security policy

Define an IPsec security policy to permit communications between the source and destination addresses.

1. Go to Policy & Objects > IPv4 Policy and select Create New.
2. Enter these settings in particular:

Incoming Interface	Select the interface that connects to the private network behind this FortiGate unit.
Outgoing Interface	Select the FortiGate unit’s public interface.
Source	Select the address name that you defined  for the private network behind this FortiGate unit.
Destination Address	Select the address name that you defined for the private network behind the dialup server.
Action	Select IPsec. Under VPN Tunnel, select the name of the Phase 1 configuration that you created in Step “Configuration overview ” on page 139 from the drop-down list. Clear Allow traffic to be initiated from the remote site to prevent traffic from the remote network from initiating the tunnel after the tunnel has been established.

Place the policy in the policy list above any other policies having similar source and destination addresses.

 

FortiClient dialup-client configuration

The FortiClient Endpoint Security application is an IPsec VPN client with antivirus, antispam and firewall capabilities. This section explains how to configure dialup VPN connections between a FortiGate unit and one or more FortiClient Endpoint Security applications.

FortiClient users are usually mobile or remote users who need to connect to a private network behind a FortiGate unit. For example, the users might be employees who connect to the office network while traveling or from their homes.

For greatest ease of use, the FortiClient application can download the VPN settings from the FortiGate unit to configure itself automatically.

The following topics are included in this section:

Configuration overview

 

Configuration overview

Dialup users typically obtain dynamic IP addresses from an ISP through Dynamic Host Configuration Protocol (DHCP) or Point-to-Point Protocol over Ethernet (PPPoE). Then, the FortiClient Endpoint Security application initiates a connection to a FortiGate dialup server.

By default the FortiClient dialup client has the same IP address as the host PC on which it runs. If the host connects directly to the Internet, this is a public IP address. If the host is behind a NAT device, such as a router, the IP address is a private IP address. The NAT device must be NAT traversal (NAT-T) compatible to pass encrypted packets (see Phase 1 parameters on page 52). The FortiClient application also can be configured to use a virtual IP address (VIP). For the duration of the connection, the FortiClient application and the FortiGate unit both use the VIP address as the IP address of the FortiClient dialup client.

The FortiClient application sends its encrypted packets to the VPN remote gateway, which is usually the public interface of the FortiGate unit. It also uses this interface to download VPN settings from the FortiGate unit. See Automatic configuration of FortiClient dialup clients on page 131.

Example FortiClient dialup-client configuration

Peer identification

The FortiClient application can establish an IPsec tunnel with a FortiGate unit configured to act as a dialup server. When the FortiGate unit acts as a dialup server, it does not identify the client using the Phase 1 remote gateway address. The IPsec tunnel is established if authentication is successful and the IPsec security policy associated with the tunnel permits access. If configured, the FortiGate unit could also require FortiClient registration, that is, the remote user would be required to have FortiClient installed before connection is completed.

Automatic configuration of FortiClient dialup clients

The FortiClient application can obtain its VPN settings from the FortiGate VPN server. FortiClient users need to know only the FortiGate VPN server IP address and their username and password on the FortiGate unit.

The FortiGate unit listens for VPN policy requests from clients on TCP port 8900. When the dialup client connects:

• The client initiates a Secure Sockets Layer (SSL) connection to the FortiGate unit.
• The FortiGate unit requests a user name and password from the FortiClient user. Using these credentials, it authenticates the client and determines which VPN policy applies to the client.
• Provided that authentication is successful, the FortiGate unit downloads a VPN policy to the client over the SSL connection. The information includes IPsec Phase 1 and Phase 2 settings, and the IP addresses of the private networks that the client is authorized to access.
• The client uses the VPN policy settings to establish an IPsec Phase 1 connection and Phase 2 tunnel with the FortiGate unit.

FortiClient-to-FortiGate VPN configuration steps

Configuring dialup client capability for FortiClient dialup clients involves the following general configuration steps:

1. If you will be using VIP addresses to identify dialup clients, determine which VIP addresses to use. As a precaution, consider using VIP addresses that are not commonly used.
2. Configure the FortiGate unit to act as a dialup server. See Configure the FortiGate unit on page 1.
3. If the dialup clients will be configured to obtain VIP addresses through DHCP over IPsec, configure the FortiGate unit to act as a DHCP server or to relay DHCP requests to an external DHCP server.
4. Configure the dialup clients. See Configure the FortiClient Endpoint Security application on page 1.

Using virtual IP addresses

When the FortiClient host PC is located behind a NAT device, unintended IP address overlap issues may arise between the private networks at the two ends of the tunnel. For example, the client’s host might receive a private IP address from a DHCP server on its network that by co-incidence is the same as a private IP address on the network behind the FortiGate unit. A conflict will occur in the host’s routing table and the FortiClient Endpoint Security application will be unable to send traffic through the tunnel. Configuring virtual IP (VIP) addresses for FortiClient applications prevents this problem.

Using VIPs ensures that client IP addresses are in a predictable range. You can then define security policies that allow access only to that source address range. If you do not use VIPs, the security policies must allow all source addresses because you cannot predict the IP address for a remote mobile user.

The FortiClient application must not have the same IP address as any host on the private network behind the FortiGate unit or any other connected FortiClient application. You can ensure this by reserving a range of IP addresses on the private network for FortiClient users. Or, you can assign FortiClient VIPs from an uncommonly used subnet such as 10.254.254.0/24 or 192.168.254.0/24.

You can reserve a VIP address for a particular client according to its device MAC address and type of connection. The DHCP server then always assigns the reserved VIP address to the client. For more information about this feature, see the “dhcp reserved-address” section in the “system” chapter of the FortiGate CLI Reference.

On the host computer, you can find out the VIP address that the FortiClient Endpoint Security application is using. For example, in Windows command prompt, type

ipconfig /all

On Linux or Mac OS X, type ifconfig in a terminal window. The output will also show the IP address that has been assigned to the host Network Interface Card (NIC).

It is best to assign VIPs using DHCP over IPsec. The FortiGate dialup server can act as a DHCP server or relay requests to an external DHCP server. You can also configure VIPs manually on FortiClient applications, but it is more difficult to ensure that all clients use unique addresses.

If you assign a VIP on the private network behind the FortiGate unit and enable DHCPIPsec (a Phase 2 advanced option), the FortiGate unit acts as a proxy on the local private network for the FortiClient dialup client. Whenever a host on the network behind the dialup server issues an ARP request for the device MAC address of the FortiClient host, the FortiGate unit answers the ARP request on behalf of the FortiClient host and forwards the associated traffic to the FortiClient host through the tunnel. For more information, see Phase 2 parameters on page 72.

FortiGate units fully support RFC 3456. The FortiGate DHCP over IPsec feature can be enabled to allocate VIP addresses to FortiClient dialup clients using a FortiGate DHCP server.

The figure below shows an example of a FortiClient-to-FortiGate VPN where the FortiClient application is assigned a VIP on an uncommonly used subnet. The diagram also shows that while the destination for the information in the encrypted packets is the private network behind the FortiGate unit, the destination of the IPsec packets themselves is the public interface of the FortiGate unit that acts as the end of the VPN tunnel.

IP address assignments in a FortiClient dialup-client configuration

Assigning VIPs by RADIUS user group

If you use XAuth authentication, you can assign users the virtual IP address stored in the Framed-IP-Address field of their record on the RADIUS server. (See RFC 2865 and RFC 2866 for more information about RADIUS fields.) To do this:

• Set the DHCP server IP Assignment Mode to User-group defined method. This is an Advanced setting. See Configuring a DHCP server on a FortiGate interface on page 137.
• Create a new firewall user group and add the RADIUS server to it.
• In your Phase 1 settings, configure the FortiGate unit as an XAuth server and select from User Group the new user group that you created. For more information, see Phase 1 parameters on page 52.
• Configure the FortiClient application to use XAuth. See Configuration overview on page 130.

FortiClient dialup-client infrastructure requirements

• To support policy-based VPNs, the FortiGate dialup server may operate in either NAT mode or transparent mode. NAT mode is required if you want to create a route-based VPN.
• If the FortiClient dialup clients will be configured to obtain VIP addresses through FortiGate DHCP relay, a DHCP server must be available on the network behind the FortiGate unit and the DHCP server must have a direct route to the FortiGate unit.
• If the FortiGate interface to the private network is not the default gateway, the private network behind the FortiGate unit must be configured to route IP traffic destined for dialup clients back (through an appropriate gateway) to the FortiGate interface to the private network. As an alternative, you can configure the IPsec security policy on the FortiGate unit to perform inbound NAT on IP packets. Inbound NAT translates the source addresses of inbound decrypted packets into the IP address of the FortiGate interface to the local private network.

Configuring the FortiGate unit

Configuring the FortiGate unit to establish VPN connections with FortiClient Endpoint Security users involves the following steps:

• Configure the VPN settings
• If the dialup clients use automatic configuration, configure the FortiGate unit as a VPN policy server
• If the dialup clients obtain VIP addresses by DHCP over IPsec, configure an IPsec DHCP server or relay

The procedures in this section cover basic setup of policy-based and route-based VPNs compatible with FortiClient Endpoint Security. A route-based VPN is simpler to configure.

To configure FortiGate unit VPN settings to support FortiClient users, you need to:

• Configure the FortiGate Phase 1 VPN settings
• Configure the FortiGate Phase 2 VPN settings
• Add the security policy

On the local FortiGate unit, define the Phase 1 configuration needed to establish a secure connection with the FortiClient peer. See Phase 1 parameters on page 52.

1. Go to VPN > IPsec Tunnels and create the new custom tunnel or edit an existing tunnel.
2. Edit Network (full configuration options are only available once you click the Convert To Custom Tunnel button).
3. Enter these settings in particular:

Remote Gateway	Select Dialup User.
IP Address	Enter the IP address of the remote peer.
Interface	Select the interface through which clients connect to the FortiGate unit.
Mode Config	When enabled, further options become available: l    Client Address Range l    Subnet Mask l    Use System DNS l    DNS Server l    Enable IPv4 Split Tunnel
Authentication Method	Select Pre-shared Key.
Pre-shared Key	Enter the pre-shared key. This must be the same preshared key provided to the FortiClient users.
Peer option	Select Any peer ID.

4. Edit Authentication and enter the following information:

	Method		Select Pre-shared Key.
Pre-shared Key				Enter the pre-shared key. This must be the same preshared key provided to the FortiClient users.
Peer Options				Set Accept Types to Any peer ID.

5. Define the Phase 2 parameters needed to create a VPN tunnel with the FortiClient peer. See Phase 2 parameters on page 72. Enter these settings in particular:

Name		Enter a name to identify this Phase 2 configuration.
Phase 1		Select the name of the Phase 1 configuration that you defined.
Advanced		Select to configure the following optional setting.
DHCP-IPsec		Select if you provide virtual IP addresses to clients using DHCP.

6. Define names for the addresses or address ranges of the private networks that the VPN links. These addresses are used in the security policies that permit communication between the networks. For more information, see Defining policy addresses on page 1.

Enter these settings in particular:

• Define an address name for the individual address or the subnet address that the dialup users access through the VPN.
• If FortiClient users are assigned VIP addresses, define an address name for the subnet to which these VIPs belong.

4. Define security policies to permit communication between the private networks through the VPN tunnel. Routebased and policy-based VPNs require different security policies. For detailed information about creating security policies, see Defining VPN security policies on page 1.

If the security policy, which grants the VPN Connection is limited to certain services, DHCP must be included, otherwise the client won’t be able to retrieve a lease from the FortiGate’s (IPsec) DHCP server, because the DHCP Request (coming out of the tunnel) will be blocked.

Route-based VPN security policies

Define an ACCEPT security policy to permit communications between the source and destination addresses.

1. Go to Policy & Objects > IPv4 Policy and select Create New.
2. Enter these settings in particular:

Name	Enter an appropriate name for the policy.
Incoming Interface	Select the VPN Tunnel (IPsec Interface) you configured in Step “Configuration overview” on page 130.
Outgoing Interface	Select the interface that connects to the private network behind this FortiGate unit.
Source	Select all.
Destination Address	Select all.
Action	Select ACCEPT.
NAT	Disable NAT.

If you want to allow hosts on the private network to initiate communications with the FortiClient users after the tunnel is established, you need to define a security policy for communication in that direction.

1. Go to Policy & Objects > IPv4 Policy and select Create New.
2. Enter these settings in particular:

Incoming Interface	Select the interface that connects to the private network behind this FortiGate unit.
Outgoing Interface	Select the interface that connects to the private network behind this FortiGate unit.
Source	Select all.
Destination Address	Select all.
Action	Select ACCEPT.
NAT	Disable NAT.

Policy-based VPN security policy

Define an IPsec security policy to permit communications between the source and destination addresses.

1. Go to Policy & Objects > IPv4 Policy and select Create New.
2. Enter these settings in particular:

Incoming Interface	Select the interface that connects to the private network behind this FortiGate unit.
Outgoing Interface	Select the FortiGate unit’s public interface.
Source	Select the address name that you defined in Step “Configuration overview” on page 130 for the private network behind this FortiGate unit.
Destination Address	If FortiClient users are assigned VIPs, select the address name that you defined for the VIP subnet. Otherwise, select all.
Action	Select IPsec. Under VPN Tunnel, select the name of the Phase 1 configuration that you created in Step “Configuration overview” on page 130 from the drop-down list. Select Allow traffic to be initiated from the remote site.

Place VPN policies in the policy list above any other policies having similar source and destination addresses.

Configuring the FortiGate unit as a VPN policy server

When a FortiClient application set to automatic configuration connects to the FortiGate unit, the FortiGate unit requests a user name and password. If the user supplies valid credentials, the FortiGate unit downloads the VPN

 

settings to the FortiClient application.

You must do the following to configure the FortiGate unit to work as a VPN policy server for FortiClient automatic configuration:

1. Create user accounts for FortiClient users.
2. Create a user group for FortiClient users and the user accounts that you created in step 1.
3. Connect to the FortiGate unit CLI and configure VPN policy distribution as follows:

config vpn ipsec forticlient edit <policy_name> set phase2name <tunnel_name> set usergroupname <group_name> set status enable

end

<tunnel_name> must be the Name you specified in the step 2 of Configuration overview on page 130. <group_name> must be the name of the user group your created for FortiClient users.

Configuring DHCP services on a FortiGate interface

If the FortiClient dialup clients are configured to obtain a VIP address using DHCP, configure the FortiGate dialup server to either:

• Relay DHCP requests to a DHCP server behind the FortiGate unit (see Configuring DHCP relay on a FortiGate interface on page 137 below).
• Act as a DHCP server (see Configuring a DHCP server on a FortiGate interface on page 137).

Note that DHCP services are typically configured during the interface creation stage, but you can return to an interface to modify DHCP settings if need be.

Configuring  DHCP relay on a FortiGate interface

1. Go to Network > Interfaces and select the interface that you want to relay DHCP.
2. Enable DHCP Server, and create a new DHCP Address Range and Netmask.
3. Open the .. menu and set Mode to Relay.
4. Enter the DHCP Server IP.
5. Select OK.

Configuring a DHCP server on a FortiGate interface

1. Go to Network > Interfaces and select the interface that you want to act as a DHCP server.
2. Enable DHCP Server, and create a new DHCP Address Range and Netmask.
3. Set Default Gateway to Specify, and enter the IP address of the default gateway that the DHCP server assigns to DHCP clients.
4. Set DNS Server to Same as System DNS. If you want to use a different DNS server for VPN clients, select Specify and enter an IP address in the available field.
5. Open the .. menu and set Mode to Server. 6. Select OK.

137

Configure the FortiClient Endpoint Security application

The following procedure explains how to configure the FortiClient Endpoint Security application to communicate with a remote FortiGate dialup server using the VIP address that you specify manually. These procedures are based on FortiClient 5.4.1.

Configuring FortiClient

This procedure explains how to configure the FortiClient application manually using the default IKE and IPsec settings. For more information, refer to the FortiClient Administration Guide.

1. Go to Remote Access and select the Settings
2. Select Add a new connection, set the new VPN connection to IPsec VPN, and complete following information:

Connection Name	Enter a descriptive name for the connection.
Remote Gateway	Enter the IP address or the fully qualified domain name (FQDN) of the remote gateway.
Authentication Method	Select Pre-shared Key and enter the pre-shared key in the field provided.
Authentication (XAuth)	Extended Authentication (XAuth) increases security by requiring additional user authentication in a separate exchange at the end of the VPN Phase 1 negotiation. The FortiGate unit challenges the user for a user name and password. It then forwards the user’s credentials to an external RADIUS or LDAP server for verification. Implementation of XAuth requires configuration at both the FortiGate unit and the FortiClient application.

3. Select OK.

Adding XAuth authentication

For information about configuring a FortiGate unit as an XAuth server, see Phase 1 parameters on page 52. The following procedure explains how to configure the FortiClient application.

Note that XAuth is not compatible with IKE version 2.

For more information on configuring XAuth authentication, see the FortiClient Administration Guide.

Dynamic DNS configuration

This section 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 domain name and a dynamic IP address.

The following topics are included in this section:

Dynamic DNS over VPN concepts

DDNS topology

Configuration overview

Dynamic DNS over VPN concepts

A typical computer has a static IP address and one or more DNS servers to resolve fully qualified domain names (FQDN) into IP addresses. A domain name assigned to this computer is resolved by any DNS server having an entry for the domain name and its static IP address. The IP address never changes or changes only rarely so the DNS server can reliably say it has the correct address for that domain all the time.

Dynamic DNS (DDNS)

It is different when a computer has a dynamic IP address, such as an IP address assigned dynamically by a DHCP server, and a domain name. Computers that want to contact this computer do not know what its current IP address is. To solve this problem there are dynamic DNS (DDNS) servers. These are public servers that store a DNS entry for your computer that includes its current IP address and associated domain name. These entries are kept up to date by your computer sending its current IP address to the DDNS  server to ensure its entry is always up to date. When other computers want to contact your domain, their DNS gets your IP address from your DDNS server. To use DDNS servers, you must subscribe to them and usually pay for their services.

When configuring DDNS on your FortiGate unit, go to Network > DNS and enable Enable FortiGuard DDNS. Then select the interface with the dynamic connection, which DDNS server you have an account with, your domain name, and account information. If your DDNS server is not on the list, there is a generic option where you can provide your DDNS server information.

Routing

When an interface has some form of changing IP address (DDNS, PPPoE, or DHCP assigned address), routing needs special attention. The standard static route cannot handle the changing IP address. The solution is to use the dynamic-gateway command in the CLI. Say for example you already have four static routes, and you have a PPPoE connection over the wan2 interface and you want to use that as your default route.

The route is configured on the dynamic address VPN peer trying to access the static address FortiGate unit.

Configuring dynamic gateway routing – CLI

config router static edit 5 set dst 0.0.0.0 0.0.0.0 set dynamic-gateway enable set device wan2

Dynamic DNS over VPN concepts

next

end

 

For more information on DDNS, see the System Administration handbook chapter.

DDNS over VPN

IPsec VPN expects an IP address for each end of the VPN tunnel. All configuration and communication with that tunnel depends on the IP addresses as reference points. However, when the interface the tunnel is on has DDNS enabled there is no set IP address. The remote end of the VPN tunnel now needs another way to reference your end of the VPN tunnel. This is accomplished using Local ID.

A FortiGate unit that has a domain name and a dynamic IP address can initiate VPN connections anytime. The remote peer can reply to the local FortiGate unit using the source IP address that was sent in the packet header because it is current. Without doing a DNS lookup first, the remote peer runs the risk of the dynamic IP changing before it attempts to connect. To avoid this, the remote peer must perform a DNS lookup for the domain name of to be sure of the dynamic IP address before initiating the connection.

Remote Gateway

When configuring the Phase 1 entry for a VPN tunnel, the Remote Gateway determines the addressing method the remote end of the tunnel uses as one of Static IP Address, Dialup User, or Dynamic DNS. There are different fields for each option.

When you select the Dynamic DNS VPN type there is a related field called Dynamic DNS. The Dynamic DNS field is asking for the FQDN of the remote end of the tunnel. It uses this information to look up the IP address of the remote end of the tunnel through the DDNS server associated with that domain name.

Local ID (peer ID)

The Local ID or peer ID can be used to uniquely identify one end of a VPN tunnel. This enables a more secure connection. Also if you have multiple VPN tunnels negotiating, this ensures the proper remote and local ends connect. When you configure it on your end, it is your Local ID. When the remote end connects to you, they see it as your peer ID.

If you are debugging a VPN connection, the Local ID is part of the VPN negotiations. You can use it to help troubleshoot connection problems.

Configuring your Local ID

1. Go to VPN > IPsec Wizard and create the new custom tunnel or go to VPN > IPsec Tunnels and edit an existing tunnel.
2. Edit the Phase 1 Proposal (if it is not available, you may need to click the Convert To Custom Tunnel button).
3. In the Phase 1 Proposal section, enter your Local ID.
4. Select OK.

The default configuration is to accept all local IDs (peer IDs). If you have Local ID set, the remote end of the tunnel must be configured to accept your local ID.

DDNS topology

Accepting a specific Peer ID

1. Go to VPN > IPsec Tunnels and create the new custom tunnel or edit an existing tunnel.
2. Edit Authentication (if it is not available, you may need to click the Convert To Custom Tunnel button).
3. Set Mode to Aggressive.
4. For Peer Options, select This peer ID. This option becomes visible only when Aggressive mode is selected.
5. In the Peer ID field, enter the string the other end of the tunnel used for its local ID.
6. Configure the rest of the Phase 1 entry as required.
7. Select OK.

Route-based or policy-based VPN

VPN over dynamic DNS can be configured with either route-based or policy-based VPN settings. Both are valid, but have differences in configuration. Choose the best method based on your requirements. For more information on route-based and policy-based, see IPsec VPN overview on page 33.

Route-based VPN configuration requires two security policies to be configured (one for each direction of traffic) to permit traffic over the VPN virtual interface, and you must also add a static route entry for that VPN interface or the VPN traffic will not reach its destination. See Dynamic DNS configuration on page 117 and Dynamic DNS configuration on page 117.

Policy-based VPN configuration uses more complex and often more IPsec security policies, but does not require a static route entry. It has the benefit of being able to configure multiple policies for handling multiple protocols in different ways, such as more scanning of less secure protocols or guaranteeing a minimum bandwidth for protocols such as VoIP. See Dynamic DNS configuration on page 117 and Dynamic DNS configuration on page 117.

DDNS topology

In this scenario, two branch offices each have a FortiGate unit and are connected in a gateway-to-gateway VPN configuration. One FortiGate unit has a domain name (example.com) with a dynamic IP address. See branch_ 2 in the figure below.

Whenever the branch_2 unit connects to the Internet (and possibly also at predefined intervals set by the ISP), the ISP may assign a different IP address to the FortiGate unit. The unit has its domain name registered with a dynamic DNS service. The branch_2 unit checks in with the DDNS server on a regular basis, and that server provides the DNS information for the domain name, updating the IP address from time to time. Remote peers have to locate the branch_2 FortiGate unit through a DNS lookup each time to ensure the address they get is current and correct.

 

Example dynamic DNS configuration

When a remote peer (such as the branch_1 FortiGate unit above) initiates a connection to example.com, the local DNS server looks up and returns the IP address that matches the domain name example.com. The remote peer uses the retrieved IP address to establish a VPN connection with the branch_2 FortiGate unit.

Assumptions

• You have administrator access to both FortiGate units.
• Both FortiGate units have interfaces named wan1 and internal. (If not, you can use the alias feature to assign these labels as “nicknames” to other interfaces to follow this example.)
• Both FortiGate units have the most recent firmware installed, have been configured for their networks, and are currently passing normal network traffic.
• The branch_2 FortiGate unit has its wan1 interface defined as a dynamic DNS interface with the domain name of com.
• A basic gateway-to-gateway configuration is in place (see Gateway-to-gateway configurations on page 1) except one of the FortiGate units has a static domain name and a dynamic IP address instead of a static IP address.
• The FortiGate unit with the domain name is subscribed to one of the supported dynamic DNS services. Contact one of the services to set up an account. For more information and instructions about how to configure the FortiGate unit to push its dynamic IP address to a dynamic DNS server, see the System Administration handbook chapter.

Configuration overview

When a FortiGate unit receives a connection request from a remote VPN peer, it uses IPsec Phase 1 parameters to establish a secure connection and authenticate the VPN peer. Then, if the security policy permits the connection, the FortiGate unit establishes the tunnel using IPsec Phase 2 parameters and applies the security policy. Key management, authentication, and security services are negotiated dynamically through the IKE protocol.

To support these functions, the following general configuration steps must be performed:

• Configure the branch_2 FortiGate unit with the dynamic IP address. This unit uses a Local ID string instead of an IP address to identify itself to the remote peer. See Configuring the dynamically-addressed VPN peer below, which is made up of configuring branch_2’s VPN tunnel settings and security policies.
• Configure the fixed-address VPN peer. To initiate a VPN tunnel with the dynamically-addressed peer, this unit must first retrieve the IP address for the domain from the dynamic DNS service. See Configuring the fixed-address VPN peer, which is made up of configuring branch_1’s VPN tunnel settings and security policies.

Configuring the dynamically-addressed VPN peer

It is assumed that this FortiGate unit (branch_2) has already had its public facing interface, for example the wan1, configured with the proper dynamic DNS configuration.

Configuring branch_2, the dynamic address side

Define the Phase 1 parameters needed to establish a secure connection with the remote peer. See Phase 1 parameters on page 52. During this procedure you need to choose if you will be using route-based or policy-based VPNs.

1. Go to VPN > IPsec Tunnels and create the new custom tunnel or edit an existing tunnel.
2. Edit Network (full configuration options are only available once you click the Convert To Custom Tunnel button).
3. Enter the following information:

	Remote Gateway		Select Static IP Address. The remote peer this FortiGate is connecting to has a static IP public address. If the remote interface is PPPoE do not select Retrieve default gateway from server.
	IP Address		Enter 172.16.20.1, the IP address of the public interface to the remote peer.
Interface		Select the Internet-facing interface wan1 (selected by default).
NAT Traversal		Select Enable (selected by default).
Keepalive Frequency		Enter a keepalive frequency (In seconds; set to 10 by default).
Dead Peer Detection		Select a dead peer detection option. On Idle will attempt to reestablish VPN tunnels when a connection becomes idle (the idle interval is not a negotiated value). Use of periodic dead peer detection incurs extra overhead. When communicating to large numbers of IKE peers, you should consider using On Demand. (set to On Demand by default).

4. Edit Authentication and complete the following:

Mode	Select Aggressive.

5. Edit Phase 1 Proposal and complete the following:

Local ID

Enter example.com. A character string used by the branch_2 FortiGate unit to identify itself to the remote peer. This value must be identical to the value in the This peer ID field of the Phase 1 remote gateway configuration on the branch_1 remote peer. See Configuration overview on page 120.

6. Open the Phase 2 Selectors

Define the Phase 2 parameters needed to create a VPN tunnel with the remote peer. For details on Phase 2, see Phase 2 parameters on page 72.

7. Enter the following information and select OK.

Name		Automatically entered as the name of the VPN tunnel.
Phase 1		Select branch_2. The name of the Phase 1 configuration that you defined earlier.

Define security policies to permit communications between the private networks through the VPN tunnel. Routebased and policy-based VPNs require different security policies. For detailed information about creating security policies, see Defining VPN security policies on page 1.

After defining the two address ranges, select one of Creating branch_2 route-ased security policies on page 123 or Creating branch_2 policy-based security policies on page 125 to configure the appropriate VPN policies.

Define VPN connection names for the address ranges of the private networks. These addresses are used in the security policies that permit communication between the networks. For more information, see Defining VPN security policies on page 1.

Define an address name for the IP address and netmask of the private network behind the local FortiGate unit.

1. Go to Policy & Objects > Addresses.
2. Select Create New.
3. Enter the following information, and select OK.

Name	Enter branch_2_internal. Enter a meaningful name.
Type	Select IP/Netmask.
Subnet / IP Range	Enter 10.10.10.0/24. Include the netmask or specify a specific range.
Interface	Select internal. The interface that will be handling the traffic from the internal network.

Define an address name for the IP address and netmask of the private network behind the remote peer.

4. Select Create New.
5. Enter the following information, and select OK.

Name	Enter branch_1_internal. A meaningful name for the private network at the remote end of the VPN tunnel.
Type	Select IP/Netmask.
Subnet / IP Range	Enter 192.168.1.0/24. Include the netmask. Optionally you can specify a range
Interface	Select any. The interface that will be handling the remote VPN traffic on this FortiGate unit. If you are unsure, or multiple interfaces may be handling this traffic use any.

Creating branch_2 route-ased security policies

Define ACCEPT security policies to permit communication between the branch_2 and branch_1 private networks. Once the route-based policy is configured a routing entry must be configured to route traffic over the VPN interface.

Define a policy to permit the branch_2 local FortiGate unit to initiate a VPN session with the branch_1 VPN peer.

1. Go to Policy & Objects > IPv4 Policy and select Create New. 2. Enter the following information, and select OK.

Name	Enter an appropriate name for the policy.
Incoming Interface		Select internal. The interface that connects to the private network behind this FortiGate unit.
Outgoing Interface		Select branch_2. The VPN Tunnel (IPsec Interface).
Source		Select branch_2_internal. Select the address name for the private network behind this FortiGate unit.
Destination Address		Select branch_1_internal. The address name the private network behind the remote peer.
Action		Select ACCEPT.
NAT		Disable NAT.
Comments		Route-based: Initiate a branch_2 to branch_1 VPN tunnel.

Define a policy to permit the branch_1 remote VPN peer to initiate VPN sessions.

3. Select Create New.
4. Enter the following information, and select OK.

Name	Enter an appropriate name for the policy.
Incoming Interface	Select branch_2. The VPN Tunnel (IPsec Interface).
Outgoing Interface	Select internal. The interface connecting the private network behind this FortiGate unit.
Source	Select branch_1_internal. The address name for the private network behind the remote peer.
Destination Address	Select branch_2_internal. The address name for the private network behind this FortiGate unit.
Action	Select ACCEPT.
NAT	Disable NAT.
Comments	Route-based: Initiate a branch_1 to branch_2 internal VPN tunnel.

5. Optionally configure any other security policy settings you require such as UTM or traffic shaping for this policy.
6. Place these policies in the policy list above any other policies having similar source and destination addresses. This will ensure VPN traffic is matched against the VPN policies before any other policies.

Creating routing entry for VPN interface – CLI

config router static edit 5 set dst 0.0.0.0 0.0.0.0

set dynamic-dateway enable set device wan1

next

end

This routing entry must be added in the CLI because the dynamic-gateway option is not available in the webbased manager.

Creating branch_2 policy-based security policies

Define an IPsec policy to permit VPN sessions between the private networks. Define an IPsec policy to permit the VPN sessions between the local branch_2 unit and the remote branch_1 unit.

1. Go to Policy & Objects > IPv4 Policy and select Create New. 2. Enter the following information, and select OK.

Name	Enter an appropriate name for the policy.
Incoming Interface	Select internal. The interface connecting the private network behind this FortiGate unit.
Outgoing Interface	Select wan1. The FortiGate unit’s public interface.
Source	Select branch_2_internal. The address name for the private network behind this local FortiGate unit.
Destination Address	Select branch_1_internal. The address name for the private network behind branch_1, the remote peer.
Action	Select IPsec. Under VPN Tunnel, select branch_2 from the drop-down list. The name of the Phase 1 tunnel. Select Allow traffic to be initiated from the remote site.
Comments	Policy-based: allows traffic in either direction to initiate the VPN tunnel.

3. Optionally configure any other security policy settings you require such as UTM or traffic shaping for this policy.
4. Place these policies in the policy list above any other policies having similar source and destination addresses. This will ensure VPN traffic is matched against the VPN policies before any other policies.

Configuring the fixed-address VPN peer

The fixed-address VPN peer, branch_1, needs to retrieve the IP address from the dynamic DNS service to initiate communication with the dynamically-addressed peer, branch_2. It also depends on the peer ID (local ID) to initiate the VPN tunnel with branch_2.

Define the Phase 1 parameters needed to establish a secure connection with the remote peer. For more information, see Phase 1 parameters on page 52.

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

Remote Gateway	Select Dynamic DNS. The remote peer this FortiGate is connecting to has a dynamic IP address.
Dynamic DNS	Type the fully qualified domain name of the remote peer (for example, example.com).
Interface	Select wan1. The public facing interface on the fixed-address FortiGate unit.
Mode Config	Select Aggressive.
Peer Options	Select This peer ID, and enter example.com. This option only appears when the mode is set to Aggressive. The identifier of the FortiGate unit with the dynamic address.

4. Edit Authentication, enter the following information and select OK.

Peer Options

Select This peer ID, and enter example.com. This option only appears when the authentication method is set to Signature. The identifier of the FortiGate unit with the dynamic address.

5. Define the Phase 2 parameters needed to create a VPN tunnel with the remote peer. See Phase 2 parameters on page 72. Enter these settings in particular:

Name			Enter branch_1_p2. A name to identify this Phase 2 configuration.
Phase 1				Select branch_1. The name of the Phase 1 configuration that you defined for the remote peer. You can select the name of the remote gateway from the Dynamic DNS part of the list.

The branch_1 FortiGate unit has a fixed IP address and will be connecting to the branch_2 FortiGate unit that has a dynamic IP address and a domain name of example.com. Remember if you are using route-based security policies that you must add a route for the VPN traffic.

Defining address ranges for branch_1 security policies

As with branch_2 previously, branch_1 needs address ranges defined as well. See Defining policy addresses on page 1.

1. Go to Policy & Objects > Addresses and select Create New > Address.
2. Enter the following information, and select OK.

Name	Enter branch_2_internal. A meaningful name for the private network behind the branch_2 FortiGate unit.
Type	Select IP/Netmask.
Subnet / IP Range	Enter 10.10.10.0/24. Include the netmask or specify a specific range.
Interface	Select internal. This is the interface on this FortiGate unit that will be handling with this traffic.

3. Define an address name for the IP address and netmask of the private network behind the remote peer. Create another address. Enter the following information, and select OK.

Name	Enter branch_1_internal. A meaningful name for the private network behind the branch_1 peer.
Type	Select IP/Netmask.
Subnet / IP Range	Enter 192.168.1.0/24. Include the netmask or specify a specific range.
Interface	Select any. The interface on this FortiGate unit that will be handling with this traffic. If you are unsure, or multiple interfaces may be handling this traffic use any.

Creating branch_1 route-based security policies

Define an ACCEPT security policy to permit communications between the source and destination addresses. See Defining VPN security policies on page 1.

1. Go to Policy & Objects > IPv4 Policy and select Create New. 2. Enter the following information, and select OK.

Name	Enter an appropriate name for the policy.
Incoming Interface	Select internal. The interface that connects to the private network behind the branch_1 FortiGate unit.
Outgoing Interface	Select branch_1. The VPN Tunnel (IPsec Interface) you configured earlier.
Source	Select branch_1_internal. The address name that you defined for the private network behind this FortiGate unit.
Destination Address	Select branch_2_internal. The address name that you defined for the private network behind the branch_2 peer.
Action	Select ACCEPT.
NAT	Disable NAT.
Comments	Internal -> branch2

To permit the remote client to initiate communication, you need to define a security policy for communication in that direction.

3. Select Create New.
4. Enter the following information, and select OK.

Name	Enter an appropriate name for the policy.
Incoming Interface	Select branch_1. The VPN Tunnel (IPsec Interface) you configured earlier.
Outgoing Interface	Select internal. The interface that connects to the private network behind this FortiGate unit.
Source	Select branch_2_internal. The address name that you defined for the private network behind the branch_2 remote peer.
Destination Address	Select branch_1_internal. The address name that you defined for the private network behind this FortiGate unit.
Action	Select ACCEPT.
NAT	Disable NAT.
Comments	branch_2 -> Internal

Creating branch_1 policy-based security policies

A policy-based security policy allows you the flexibility to allow inbound or outbound traffic or both through this single policy.

This policy-based IPsec VPN security policy allows both inbound and outbound traffic

1. Go to Policy & Objects > IPv4 Policy and select Create New. 2. Enter the following information, and select OK.

Incoming Interface	Select internal. The interface that connects to the private network behind this FortiGate unit.
Outgoing Interface	Select wan1. The FortiGate unit’s public interface.
Source	Select branch_1_internal. The address name that you defined for the private network behind this FortiGate unit.
Destination Address	Select branch_2_internal. The address name that you defined for the private network behind the remote peer.
Action	Select IPsec. Under VPN Tunnel, select branch_1 from the drop-down list. The name of the Phase 1 tunnel. Select Allow traffic to be initiated from the remote site.

3. Place this security policy in the policy list above any other policies having similar source and destination addresses.

Results

Once both ends are configured, you can test the VPN tunnel.

To test the VPN initiated by branch_2

1. On branch_2, go to Monitor > IPsec Monitor.

All IPsec VPN tunnels will be listed on this page, no matter if they are connected or disconnected.

2. Select the tunnel listed for branch_2, and select the status column for that entry.

The status will say Bring Up and remote port, incoming and outgoing data will all be zero. This indicates an inactive tunnel. When you right-click and select Bring Up, the FortiGate will try to set up a VPN session over this tunnel. If it is successful, Bring Up will change to Active, and the arrow icon will change to a green up arrow icon.

3. If this does not create a VPN tunnel with increasing values for incoming and outgoing data, you need to start troubleshooting:

To test the VPN initiated by branch_1

1. On branch_1, go to Monitor > IPsec Monitor.
2. Select the tunnel listed for branch_1, and select the status column.

The difference between branch_2 and branch_1 at this point is that the tunnel entry for branch-1 will not have a remote gateway IP address. It will be resolved when the VPN tunnel is started.

3. If this does not create a VPN tunnel with increasing values for incoming and outgoing data, you need to start troubleshooting.

Some troubleshooting ideas include:

• If there was no entry for the tunnel on the monitor page, check the Auto Key (IKE) page to verify the Phase 1 and Phase 2 entries exist.
• Check the security policy or policies, and ensure there is an outgoing policy as a minimum.
• Check that you entered a local ID in the Phase 1 configuration, and that branch_1 has the same local ID. l Ensure the local DNS server has an up-to-date DNS entry for exmaple.com.

For more information, see Troubleshooting on page 1.

 

Hub-and-spoke configurations

This section describes how to set up hub-and-spoke IPsec VPNs. The following topics are included in this section:

Configuration overview

Configure the hub

Configure the spokes

Dynamic spokes configuration example

Configuration overview

In a hub-and-spoke configuration, VPN connections radiate from a central FortiGate unit (the hub) to a number of remote peers (the spokes). Traffic can pass between private networks behind the hub and private networks behind the remote peers. Traffic can also pass between remote peer private networks through the hub.

Example hub-and-spoke configuration

The actual implementation varies in complexity depending on:

 

Configuration overview

• Whether the spokes are statically or dynamically addressed
• The addressing scheme of the protected subnets
• How peers are authenticated

This guide discusses the issues involved in configuring a hub-and-spoke VPN and provides some basic configuration examples.

Hub-and-spoke infrastructure requirements

• The FortiGate hub must be operating in NAT mode and have a static public IP address.
• Spokes may have static IP addresses, dynamic IP addresses (see FortiGate dialup-client configurations on page 1), or static domain names and dynamic IP addresses (see Dynamic DNS configuration on page 1).

Spoke gateway addressing

The public IP address of the spoke is the VPN remote gateway as seen from the hub. Statically addressed spokes each require a separate VPN Phase 1 configuration on the hub. When there are many spokes, this becomes rather cumbersome.

Using dynamic addressing for spokes simplifies the VPN configuration because then the hub requires only a single Phase 1 configuration with “dialup user” as the remote gateway. You can use this configuration even if the remote peers have static IP addresses. A remote peer can establish a VPN connection regardless of its IP address if its traffic selectors match and it can authenticate to the hub. See Configuration overview on page 100 for an example of this configuration.

Protected networks addressing

The addresses of the protected networks are needed to configure destination selectors and sometimes for security policies and static routes. The larger the number of spokes, the more addresses there are to manage. You can

• Assign spoke subnets as part of a larger subnet, usually on a new network or
• Create address groups that contain all of the needed addresses

Using aggregated subnets

If you are creating a new network, where subnet IP addresses are not already assigned, you can simplify the VPN configuration by assigning spoke subnets that are part of a large subnet.

Aggregated subnets

All spokes use the large subnet address, 10.1.0.0/16 for example, as:

• The IPsec destination selector
• The destination of the security policy from the private subnet to the VPN (required for policy-based VPN, optional for route-based VPN)
• The destination of the static route to the VPN (route-based)

Each spoke uses the address of its own protected subnet as the IPsec source selector and as the source address in its VPN security policy. The remote gateway is the public IP address of the hub FortiGate unit.

Using an address group

If you want to create a hub-and-spoke VPN between existing private networks, the subnet addressing usually does not fit the aggregated subnet model discussed earlier. All of the spokes and the hub will need to include the addresses of all the protected networks in their configuration.

On FortiGate units, you can define a named firewall address for each of the remote protected networks and add these addresses to a firewall address group. For a policy-based VPN, you can then use this address group as the destination of the VPN security policy.

For a route-based VPN, the destination of the VPN security policy can be set to All. You need to specify appropriate routes for each of the remote subnets.

Authentication

Authentication is by a common pre-shared key or by certificates. For simplicity, the examples in this chapter assume that all spokes use the same pre-shared key.

Configure the hub

At the FortiGate unit that acts as the hub, you need to:

hub

• Configure the VPN to each spoke
• Configure communication between spokes

You configure communication between spokes differently for a policy-based VPN than for a route-based VPN. For a policy-based VPN, you configure a VPN concentrator. For a route-based VPN, you must either define security policies or group the IPsec interfaces into a zone.

Define the hub-spoke VPNs

Perform these steps at the FortiGate unit that will act as the hub. Although this procedure assumes that the spokes are all FortiGate units, a spoke could also be VPN client software, such as FortiClient Endpoint Security.

Configuring the VPN hub

1. At the hub, define the Phase 1 configuration for each spoke. See Phase 1 parameters on page 52. Enter these settings in particular:

Name	Enter a name to identify the VPN in Phase 2 configurations, security policies and the VPN monitor.
Remote Gateway	The remote gateway is the other end of the VPN tunnel. There are three options: Static IP Address  — Enter the spoke’s public IP Address. You will need to create a Phase 1 configuration for each spoke. Either the hub or the spoke can establish the VPN connection. Dialup User — No additional information is needed. The hub accepts connections from peers with appropriate encryption and authentication settings. Only one Phase 1 configuration is needed for multiple dialup spokes. Only the spoke can establish the VPN tunnel. Dynamic DNS — If the spoke subscribes to a dynamic DNS service, enter the spoke’s Dynamic DNS domain name. Either the hub or the spoke can establish the VPN connection. For more information, see Dynamic DNS configuration on page 1.
Local Interface	Select the FortiGate interface that connects to the remote gateway. This is usually the FortiGate unit’s public interface.

2. Define the Phase 2 parameters needed to create a VPN tunnel with each spoke. See Phase 2 parameters on page
3. 72. Enter these settings in particular:

Name	Enter a name to identify this spoke Phase 2 configuration.
Phase 1	Select the name of the Phase 1 configuration that you defined for this spoke.

IPsec VPN in ADVPN hub-and-spoke

IPsec VPN traffic is allowed through a tunnel between an ADVPN hub-and-spoke.

CLI Syntax:

config vpn ipsec phase1-interface edit “int-fgtb” … set auto-discovery-sender [enable | disable] set auto-discovery-receiver [enable | disable] set auto-discovery-forwarder [enable | disable] …

next

end

config vpn ipsec phase2-interface edit “int-fgtb” …

set auto-discovery-sender phase1 [enable | disable] …

next

end

Define the hub-spoke security policies

1. Define a name for the address of the private network behind the hub. For more information, see Defining policy addresses on page 1.
2. Define names for the addresses or address ranges of the private networks behind the spokes. For more information, see Defining policy addresses on page 1.
3. Define the VPN concentrator. See To define the VPN concentrator on page 105.
4. Define security policies to permit communication between the hub and the spokes. For more information, see Defining VPN security policies on page 1.

Route-based VPN security policies

Define ACCEPT security policies to permit communications between the hub and the spoke. You need one policy for each direction.

Adding policies

1. Go to Policy & Objects > IPv4 Policy and select Create New.
2. Leave the Policy Type as Firewall and leave the Policy Subtype as Address.
3. Enter these settings in particular:

Incoming Interface	Select the VPN Tunnel (IPsec Interface) you configured in Step 1.
Source Address	Select the address name you defined in Step 2 for the private network behind the spoke FortiGate unit.
Outgoing Interface	Select the hub’s interface to the internal (private) network.
Destination Address	Select the source address that you defined in Step 1.
Action	Select ACCEPT.
Enable NAT	Enable.

 

hub

Incoming Interface	Select the VPN Tunnel (IPsec Interface) you configured inStep 1.
Source Address	Select the address name you defined in Step 2 for the private network behind the spoke FortiGate units.
Outgoing Interface	Select the source address that you defined in Step 1.
Destination Address	Select the hub’s interface to the internal (private) network.
Action	Select ACCEPT.
Enable NAT	Enable.

Policy-based VPN security policy

Define an IPsec security policy to permit communications between the hub and the spoke.

Adding policies

1. Go to Policy & Objects > IPv4 Policy and select Create New.
2. Enter these settings in particular:

Incoming Interface	Select the hub’s interface to the internal (private) network.
Source Address	Select the source address that you defined in Step 1.
Outgoing Interface	Select the hub’s public network interface.
Destination Address	Select the address name you defined in Step 2 for the private network behind the spoke FortiGate unit.
VPN Tunnel	Select Use Existing and select the name of the Phase 1 configuration that you created for the spoke in Step 1. Select Allow traffic to be initiated from the remote site to enable traffic from the remote network to initiate the tunnel.

In the policy list, arrange the policies in the following order:

l IPsec policies that control traffic between the hub and the spokes first  l The default security policy last

Configuring communication between spokes (policy-based VPN)

For a policy-based hub-and-spoke VPN, you define a concentrator to enable communication between the spokes.

To define the VPN concentrator

1. At the hub, go to VPN > IPsec Concentrator and select Create New.
2. In the Concentrator Name field, type a name to identify the concentrator.
3. From the Available Tunnels list, select a VPN tunnel and then select the right-pointing arrow.
4. Repeat Step 3 until all of the tunnels associated with the spokes are included in the concentrator.
5. Select OK.

Configuring communication between spokes (route-based VPN)

For a route-based hub-and-spoke VPN, there are several ways you can enable communication between the spokes:

• Put all of the IPsec interfaces into a zone and enable intra-zone traffic. This eliminates the need for any security policy for the VPN, but you cannot apply UTM features to scan the traffic for security threats.
• Put all of the IPsec interfaces into a zone and create a single zone-to-zone security policy
• Create a security policy for each pair of spokes that are allowed to communicate with each other. The number of policies required increases rapidly as the number of spokes increases.

Using a zone as a concentrator

A simple way to provide communication among all of the spokes is to create a zone and allow intra-zone communication. You cannot apply UTM features using this method.

1. Go to Network > Interfaces.
2. Select the down-arrow on the Create New button and select Zone.
3. In the Zone Name field, enter a name, such as Our_VPN_zone.
4. Clear Block intra-zone traffic.
5. In the Interface Members list, select the IPsec interfaces that are part of your VPN.
6. Select OK.

Using a zone with a policy as a concentrator

If you put all of the hub IPsec interfaces involved in the VPN into a zone, you can enable communication among all of the spokes and apply UTM features with just one security policy.

Creating a zone for the VPN

1. Go to Network > Interfaces.
2. Select the down-arrow on the Create New button and select Zone.
3. In the Zone Name field, enter a name, such as Our_VPN_zone.
4. Select Block intra-zone traffic.
5. In the Interface Members list, select the IPsec interfaces that are part of your VPN.
6. Select OK.

Creating a security policy for the zone

1. Go to Policy & Objects > IPv4 Policy and select Create New.
2. Leave the Policy Type as Firewall and leave the Policy Subtype as Address.
3. Enter the settings: and select OK.

Incoming Interface

Select the zone you created for your VPN.

spokes

Source Address	Select All.
Outgoing Interface	Select the zone you created for your VPN.
Destination Address	Select All.
Action	Select ACCEPT.
Enable NAT	Enable.

Using security policies as a concentrator

To enable communication between two spokes, you need to define an ACCEPT security policy for them. To allow either spoke to initiate communication, you must create a policy for each direction. This procedure describes a security policy for communication from Spoke 1 to Spoke 2. Others are similar.

1. Define names for the addresses or address ranges of the private networks behind each spoke. For more information, see Defining policy addresses on page 1.
2. Go to Policy & Objects > IPv4 Policy and select Create New.
3. Leave the Policy Type as Firewall and leave the Policy Subtype as Address.
4. Enter the settings and select OK.

Incoming Interface	Select the IPsec interface that connects to Spoke 1.
Source Address	Select the address of the private network behind Spoke 1.
Outgoing Interface	Select the IPsec interface that connects to Spoke 2.
Destination Address	Select the address of the private network behind Spoke 2.
Action	Select ACCEPT.
Enable NAT	Enable.

Configure the spokes

Although this procedure assumes that the spokes are all FortiGate units, a spoke could also be VPN client software, such as FortiClient Endpoint Security.

Perform these steps at each FortiGate unit that will act as a spoke.

Creating the Phase 1 and phase_2 configurations

1. At the spoke, define the Phase 1 parameters that the spoke will use to establish a secure connection with the hub. See Phase 1 parameters on page 52. Enter these settings:

Remote Gateway	Select Static IP Address.
IP Address	Type the IP address of the interface that connects to the hub.

 

Configure the spokes

2. Create the Phase 2 tunnel definition. See Phase 2 parameters on page 72. Select the set of Phase 1 parameters that you defined for the hub. You can select the name of the hub from the Static IP Address part of the list.

Configuring security policies for hub-to-spoke communication

1. Create an address for this spoke. See Defining policy addresses on page 1. Enter the IP address and netmask of the private network behind the spoke.
2. Create an address to represent the hub. See Defining policy addresses on page 1. Enter the IP address and netmask of the private network behind the hub.
3. Define the security policy to enable communication with the hub.

Route-based VPN security policy

Define two security policies to permit communications to and from the hub.

1. Go to Policy & Objects > IPv4 Policy and select Create New.
2. Leave the Policy Type as Firewall and leave the Policy Subtype as Address.
3. Enter these settings:

Incoming Interface	Select the virtual IPsec interface you created.
Source Address	Select the hub address you defined in Step 1.
Outgoing Interface	Select the spoke’s interface to the internal (private) network.
Destination Address	Select the spoke addresses you defined in Step 2.
Action	Select ACCEPT.
Enable NAT	Enable

 

Incoming Interface	Select the spoke’s interface to the internal (private) network.
Source Address	Select the spoke address you defined in Step 1.
Outgoing Interface	Select the virtual IPsec interface you created.
Destination Address	Select the hub destination addresses you defined in Step 2.
Action	Select ACCEPT.
Enable NAT	Enable

Policy-based VPN security policy

Define an IPsec security policy to permit communications with the hub. See Defining VPN security policies on page 1.

1. Go to Policy & Objects > IPv4 Policy and select Create New.
2. Enter these settings in particular:

spokes

Incoming Interface	Select the spoke’s interface to the internal (private) network.
Source Address	Select the spoke address you defined in Step 1.
Outgoing Interface	Select the spoke’s interface to the external (public) network.
Destination Address	Select the hub address you defined in Step 2.
VPN Tunnel	Select Use Existing and select the name of the Phase 1 configuration you defined. Select Allow traffic to be initiated from the remote site to enable traffic from the remote network to initiate the tunnel.

Configuring security policies for spoke-to-spoke communication

Each spoke requires security policies to enable communication with the other spokes. Instead of creating separate security policies for each spoke, you can create an address group that contains the addresses of the networks behind the other spokes. The security policy then applies to all of the spokes in the group.

1. Define destination addresses to represent the networks behind each of the other spokes. Add these addresses to an address group.
2. Define the security policy to enable communication between this spoke and the spokes in the address group you created.

Policy-based VPN security policy

Define an IPsec security policy to permit communications with the other spokes. See Defining VPN security policies on page 1. Enter these settings in particular:

Route-based VPN security policy

Define two security policies to permit communications to and from the other spokes.

1. Go to Policy & Objects > IPv4 Policy and select Create New.
2. Leave the Policy Type as Firewall and leave the Policy Subtype as Address. Enter these settings in particular:

Incoming Interface	Select the virtual IPsec interface you created.
Source Address	Select the spoke address group you defined in Step “Configure the spokes ” on page 107.
Outgoing Interface	Select the spoke’s interface to the internal (private) network.
Destination Address	Select this spoke’s address name.
Action	Select ACCEPT.
Enable NAT	Enable

4. Select Create New, leave the Policy Type as Firewall and leave the Policy Subtype as Address, and enter these settings:

Incoming Interface	Select the spoke’s interface to the internal (private) network.
Source Address	Select this spoke’s address name.
Outgoing Interface	Select the virtual IPsec interface you created.
Destination Address	Select the spoke address group you defined in Step 1.
Action	Select ACCEPT.
Enable NAT	Enable

Policy-based VPN security policy

1. Go to Policy & Objects > IPv4 Policy and select Create New.
2. Enter the following:

Incoming Interface	Select this spoke’s internal (private) network interface.
Source Address	Select this spoke’s source address.
Outgoing Interface	Select the spoke’s interface to the external (public) network.
Destination Address	Select the spoke address group you defined in Step 1.
VPN Tunnel	Select Use Existing and select the name of the Phase 1 configuration you defined. Select Allow traffic to be initiated from the remote site to enable traffic from the remote network to initiate the tunnel.

Place this policy or policies in the policy list above any other policies having similar source and destination addresses.

Dynamic spokes configuration example

This example demonstrates how to set up a basic route-based hub-and-spoke IPsec VPN that uses preshared keys to authenticate VPN peers.

 

Example hub-and-spoke configuration

In the example configuration, the protected networks 10.1.0.0/24, 10.1.1.0/24 and 10.1.2.0/24 are all part of the larger subnet 10.1.0.0/16. The steps for setting up the example hub-and-spoke configuration create a VPN among Site 1, Site 2, and the HR Network.

The spokes are dialup. Their addresses are not part of the configuration on the hub, so only one spoke definition is required no matter the number of spokes. For simplicity, only two spokes are shown.

In an ADVPN topology, any two pair of peers can create a shortcut, as long as one of the devices is not behind NAT.

The on-the-wire format of the ADVPN messages  use TLV encoding.  Because of this, this feature is not compatible with any previous ADVPN builds.

Configure the hub (FortiGate_1)

The Phase 1 configuration defines the parameters that FortiGate_1 will use to authenticate spokes and establish secure connections.

For the purposes of this example, one preshared key will be used to authenticate all of the spokes. Each key must contain at least 6 printable characters and best practices dictates that it only be known by network administrators. For optimum protection against currently known attacks, each key must consist of a minimum of 16 randomly chosen alphanumeric characters.

Define the IPsec configuration

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

Define the Phase 1 parameters that the hub will use to establish a secure connection to the spokes.

Name	Enter a name (for example, toSpokes).
Remote Gateway	Dialup user
Local Interface	External
Mode	Main
Authentication Method	Preshared Key
Pre-shared Key	Enter the preshared key.
Peer Options	Any peer ID

The basic Phase 2 settings associate IPsec Phase 2 parameters with the Phase 1 configuration and specify the remote end points of the VPN tunnels.

3. Open the Phase 2 Selectors panel (if it is not available, you may need to click the Convert to Custom Tunnel button).
4. Enter the following information, and select OK:

Name	Enter a name for the Phase 2 definition (for example, toSpokes_ph2).
Phase 1	Select the Phase 1 configuration that you defined previously (for example, toSpokes).

Define the security policies

security policies control all IP traffic passing between a source address and a destination address. For a routebased VPN, the policies are simpler than for a policy-based VPN. Instead of an IPSEC policy, you use an ACCEPT policy with the virtual IPsec interface as the external interface.

Before you define security policies, you must first define firewall addresses to use in those policies. You need addresses for:

• The HR network behind FortiGate_1
• The aggregate subnet address for the protected networks

Defining the IP address of the HR network behind FortiGate_1

1. Go to Policy & Objects > Addresses.
2. Select Create New, enter the following information, and select OK:

	Name		Enter an address name (for example, HR_Network).
	Type		Subnet
Subnet/IP Range				Enter the IP address of the HR network behind FortiGate_1 (for example, 10.1.0.0/24).

Specifying the IP address the aggregate protected subnet

1. Go to Policy & Objects > Addresses.
2. Select Create New, enter the following information, and select OK:

Address Name	Enter an address name (for example, Spoke_net).
Type	Subnet
Subnet/IP Range	Enter the IP address of the aggregate protected network, 10.1.0.0/16

Defining the security policy for traffic from the hub to the spokes  1. Go to Policy & Objects > IPv4 Policy and select Create New,

2. Leave the Policy Type as Firewall and leave the Policy Subtype as Address. 3. Enter the following information, and select OK:

Incoming Interface	Select the interface to the HR network, port 1.
Source Address	Select HR_Network.
Outgoing Interface	Select the virtual IPsec interface that connects to the spokes, toSpokes.
Destination Address	Select Spoke_net.
Action	Select ACCEPT.

Place the policy in the policy list above any other policies having similar source and destination addresses.

Configure communication between spokes

Spokes communicate with each other through the hub. You need to configure the hub to allow this

communication. An easy way to do this is to create a zone containing the virtual IPsec interfaces even if there is only one, and create a zone-to-zone security policy.

1. Go to Network > Interfaces.
2. Select the down-arrow on the Create New button and select Zone.
3. In the Zone Name field, enter a name, such as Our_VPN_zone.
4. Select Block intra-zone traffic.

You could enable intra-zone traffic and then you would not need to create a security policy. But, you would not be able to apply UTM features.

5. In Interface Members, select the virtual IPsec interface, toSpokes.
6. Select OK.

Creating a security policy for the zone

1. Go to Policy & Objects > IPv4 Policy and select Create New.
2. Leave the Policy Type as Firewall and leave the Policy Subtype as Address.
3. Enter these settings:

Incoming Interface	Select Our_VPN_zone.
Source Address	Select All.
Outgoing Interface	Select Our_VPN_zone.
Destination Address	Select All.
Action	Select ACCEPT.
Enable NAT	Enable.

4. Select OK.

Configure the spokes

In this example, all spokes have nearly identical configuration, requiring the following:

• Phase 1 authentication parameters to initiate a connection with the hub.
• Phase 2 tunnel creation parameters to establish a VPN tunnel with the hub.
• A source address that represents the network behind the spoke. This is the only part of the configuration that is different for each spoke.
• A destination address that represents the aggregate protected network.
• A security policy to ena.ble communications between the spoke and the aggregate protected network Define the IPsec configuration

At each spoke, create the following configuration.

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

Name	Type a name, for example, toHub.
Remote Gateway	Select Static IP Address.
IP Address	Enter 172.16.10.1.
Local Interface	Select Port2.
Mode	Main
Authentication Method	Preshared Key
Pre-shared Key	Enter the preshared key. The value must be identical to the preshared key that you specified previously in the FortiGate_1 configuration
Peer Options	Select Any peer ID.

1. Open the Phase 2 Selectors panel (if it is not available, you may need to click the Convert to Custom Tunnel button).
2. Enter the following information and select OK:

Name	Enter a name for the tunnel, for example, toHub_ph2.
Phase 1	Select the name of the Phase 1 configuration that you defined previously, for example, toHub.
Advanced	Select to show the following Quick Mode Selector settings.
Source	Enter the address of the protected network at this spoke. For spoke_1, this is 10.1.1.0/24. For spoke_2, this is 10.1.2.0/24.
Destination	Enter the aggregate protected subnet address, 10.1.0.0/16.

Define the security policies

You need to define firewall addresses for the spokes and the aggregate protected network and then create a security policy to enable communication between them.

Defining the IP address of the network behind the spoke

1. Go to Policy & Objects > Addresses.
2. Select Create New and enter the following information:

Address Name	Enter an address name, for example LocalNet.
Type	Subnet
Subnet/IP Range	Enter the IP address of the private network behind the spoke. For spoke_1, this is 10.1.1.0/24. For spoke_2, this is 10.1.2.0/24.

Specifying the IP address of the aggregate protected network

1. Go to Policy & Objects > Addresses.
2. Select Create New and enter the following information:

Address Name	Enter an address name, for example,  Spoke_net.
Type	Subnet
Subnet/IP Range	Enter the IP address of the aggregate protected network, 10.1.0.0/16.

Defining the security policy

1. Go to Policy & Objects > IPv4 Policy and select Create New.
2. Leave the Policy Type as Firewall and leave the Policy Subtype as Address.
3. Enter the following information:

Incoming Interface	Select the virtual IPsec interface, toHub.
Source Address	Select the aggregate protected network address Spoke_net.
Outgoing Interface	Select the interface to the internal (private) network, port1.
Destination Address	Select the address for this spoke’s protected network LocalNet.
Action	Select ACCEPT.

4. Select Create New.
5. Leave the Policy Type as Firewall and leave the Policy Subtype as Address. Enter the following information, and select OK:

Incoming Interface	Select the interface to the internal private network, port1.
Source Address	Select the address for this spoke’s protected network, LocalNet.
Outgoing Interface	Select the virtual IPsec interface, toHub.
Destination Address	Select the aggregate protected network address, Spoke_net.
Action	Select ACCEPT.

Place these policies in the policy list above any other policies having similar source and destination addresses.

 

Gateway-to-gateway

This section explains how to set up a basic gateway-to-gateway (site-to-site) IPsec VPN.

The following topics are included in this section:

Configuration overview

Gateway-to-gateway configuration

How to work with overlapping subnets Testing

Configuration overview

In a gateway-to-gateway configuration, two FortiGate units create a VPN tunnel between two separate private networks. All traffic between the two networks is encrypted and protected by FortiGate security policies.

Example gateway-to-gateway configuration

In some cases, computers on the private network behind one VPN peer may (by co-incidence) have IP addresses that are already used by computers on the network behind the other VPN peer. In this type of situation

(ambiguous routing), conflicts may occur in one or both of the FortiGate routing tables and traffic destined for the remote network through the tunnel may not be sent. To resolve issues related to ambiguous routing, see Configuration overview on page 84.

Configuration overview

In other cases, computers on the private network behind one VPN peer may obtain IP addresses from a local DHCP server. However, unless the local and remote networks use different private network address spaces, unintended ambiguous routing and/or IP-address overlap issues may arise. For a discussion of the related issues, see FortiGate dialup-client configurations  on page 1.

Configuration overview

You can set up a fully meshed or partially meshed configuration (see below).

Fully meshed configuration

In a fully meshed network, all VPN peers are connected to each other, with one hop between peers. This topology is the most fault-tolerant: if one peer goes down, the rest of the network is not affected. This topology is difficult to scale because it requires connections between all peers. In addition, unnecessary communication can occur between peers. Best practices dictates a hub-and-spoke configuration instead (see Hub-and-spoke configurations on page 1).

 

Partially meshed configuration

A partially meshed network is similar to a fully meshed network, but instead of having tunnels between all peers, tunnels are only configured between peers that communicate with each other regularly.

Gateway-to-gateway configuration

The FortiGate units at both ends of the tunnel must be operating in NAT mode and have static public IP addresses.

When a FortiGate unit receives a connection request from a remote VPN peer, it uses IPsec Phase 1 parameters to establish a secure connection and authenticate that VPN peer. Then, if the security policy permits the connection, the FortiGate unit establishes the tunnel using IPsec Phase 2 parameters and applies the IPsec security policy. Key management, authentication, and security services are negotiated dynamically through the IKE protocol.

To support these functions, the following general configuration steps must be performed by both FortiGate units:

• Define the Phase 1 parameters that the FortiGate unit needs to authenticate the remote peer and establish a secure connection.
• Define the Phase 2 parameters that the FortiGate unit needs to create a VPN tunnel with the remote peer.
• Create security policies to control the permitted services and permitted direction of traffic between the IP source and destination addresses.

Gateway-to-gateway configuration

Configuring Phase 1 and Phase 2 for both peers

This procedure applies to both peers. Repeat the procedure on each FortiGate unit, using the correct IP address for each. You may wish to vary the Phase 1 names but this is optional. Otherwise all steps are the same for each peer.

The Phase 1 configuration defines the parameters that FortiGate_1 will use to authenticate FortiGate_2 and establish a secure connection. For the purposes of this example, a preshared key will be used to authenticate FortiGate_2. The same preshared key must be specified at both FortiGate units. Before you define the Phase 1 parameters, you need to:

• Reserve a name for the remote gateway.
• Obtain the IP address of the public interface to the remote peer. l Reserve a unique value for the preshared key.

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

At the local FortiGate unit, define the Phase 1 configuration needed to establish a secure connection with the remote peer. See IPsec VPN in the web-based manager on page 38.

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

Name	Enter peer_1. A name to identify the VPN tunnel. This name appears in Phase 2 configurations, security policies and the VPN monitor.
Remote Gateway	Select Static IP Address.
IP Address	Enter 172.20.0.2 when configuring FortiGate_1. Enter 172.18.0.2 when configuring FortiGate_2. The IP address of the remote peer public interface.
Local Interface	Select wan1.

The basic Phase 2 settings associate IPsec Phase 2 parameters with the Phase 1 configuration and specify the remote end point of the VPN tunnel. Before you define the Phase 2 parameters, you need to reserve a name for the tunnel. See IPsec VPN in the web-based manager on page 38.

1. Open the Phase 2 Selectors panel (if it is not available, you may need to click the Convert to Custom Tunnel button).
2. Enter a Name of peer_1_p2.
3. Select peer_1 from the Phase 1 drop-down menu.

Creating security policies

Security policies control all IP traffic passing between a source address and a destination address.

An IPsec security policy is needed to allow the transmission of encrypted packets, specify the permitted direction of VPN traffic, and select the VPN tunnel that will be subject to the policy. A single policy is needed to control both inbound and outbound IP traffic through a VPN tunnel.

Before you define security policies, you must first specify the IP source and destination addresses. In a gatewayto-gateway configuration:

• The IP source address corresponds to the private network behind the local FortiGate unit. l The IP destination address refers to the private network behind the remote VPN peer.

When you are creating security policies, choose one of either route-based or policy-based methods and follow it for both VPN peers. DO NOT configure both route-based and policy-based policies on the same FortiGate unit for the same VPN tunnel.

The configuration of FortiGate_2 is similar to that of FortiGate_1. You must:

• Define the Phase 1 parameters that FortiGate_2 needs to authenticate FortiGate_1 and establish a secure connection.
• Define the Phase 2 parameters that FortiGate_2 needs to create a VPN tunnel with FortiGate_1.
• Create the security policy and define the scope of permitted services between the IP source and destination addresses.

When creating security policies it is good practice to include a comment describing what the policy does.

Creating firewall addresses

Define names for the addresses or address ranges of the private networks that the VPN links. These addresses are used in the security policies that permit communication between the networks.

To define the IP address of the network behind FortiGate_1

1. Go to Policy & Objects > Addresses and select Create New.
2. Enter the Name of Finance_network. Select a Type of Subnet.
3. Enter the Subnet of 21.101.0/24.
4. Select OK.

To specify the address of the network behind FortiGate_2

1. Go to Policy & Objects > Addresses and select Create New.
2. Enter the Name of HR_network.
3. Select a Type of Subnet.
4. Enter the Subnet/IP Range of 31.101.0/24. 5. Select OK.

Creating route-based VPN security policies

Define an ACCEPT security policy to permit communications between the source and destination addresses.

To create route-based VPN security policies  1. Go to Policy & Objects > IPv4 Policy and select Create New

2. Leave the Policy Type as Firewall and leave the Policy Subtype as Address.

Gateway-to-gateway configuration

3. Enter the following, and select OK.

Incoming Interface	Select internal. The interface that connects to the private network behind this FortiGate unit.
Source Address	Select Finance_network when configuring FortiGate_1. Select HR_network when configuring FortiGate_2. The address name for the private network behind this FortiGate unit.
Outgoing Interface	Select peer_1. The VPN Tunnel (IPsec Interface) you configured earlier.
Destination Address	Select HR_network when configuring FortiGate_1. Select Finance_network when configuring FortiGate_2. The address name that you defined for the private network behind the remote peer.
Action	Select ACCEPT.
Enable NAT	Disable.
Comments	Allow Internal to remote VPN network traffic.

4. Optionally, configure any additional features you may want, such as UTM or traffic shaping.
5. Select Create New to create another policy for the other direction.
6. Leave the Policy Type as Firewall and leave the Policy Subtype as Address.
7. Enter the following information, and select OK.

Incoming Interface	Select peer_1. The VPN Tunnel (IPsec Interface) you configured.
Source Address	Select HR_network when configuring FortiGate_1. Select Finance_Network when configuring FortiGate_2. The address name defined for the private network behind the remote peer.
Outgoing Interface	Select internal. The interface that connects to the private network behind this FortiGate unit.
Destination Address		Select Finance_Network when configuring FortiGate_1. Select HR_network when configuring FortiGate_2. The address name defined for the private network behind this FortiGate unit.
Action		Select ACCEPT.
Enable NAT		Disable.
Comments		Allow remote VPN network traffic to Internal.

8. Configure any additional features such as UTM or traffic shaping you may want. (optional).

All network traffic must have a static route to direct its traffic to the proper destination. Without a route, traffic will not flow even if the security policies are configured properly. You may need to create a static route entry for both directions of VPN traffic if your security policies allow bi-directional tunnel initiation.

To configure the route for a route-based VPN:

1. On FortiGate_2, go to Network > Static Routes and select Create New.
2. Enter the following information, and then select OK:

Destination IP / Mask	10.21.101.0/24
Device	FGT2_to_FGT1_Tunnel
Gateway	Leave as default: 0.0.0.0.
Distance (Advanced)	Leave this at its default. If there are other routes on this FortiGate unit, you may need to set the distance on this route so the VPN traffic will use it as the default route. However, this normally happens by default because this route is typically a better match than the generic default route.

Creating policy-based VPN security policy

Define an IPsec security policy to permit communications between the source and destination addresses.

1. Go to Policy & Objects > IPv4 Policy.
2. Complete the following:

Incoming Interface

Select internal. The interface that connects to the private network behind this FortiGate unit.

 

Source Address	Select Finance_network when configuring FortiGate_1. Select HR_network when configuring FortiGate_2. The address name defined for the private network behind this FortiGate unit.
Outgoing Interface	Select wan1. The FortiGate unit’s public interface.
Destination Address	Select HR_network when configuring FortiGate_1. Select Finance_network when configuring FortiGate_2.
VPN Tunnel	Select Use Existing and select peer_1 from the VPN Tunnel drop-down list. Select Allow traffic to be initiated from the remote site to enable traffic from the remote network to initiate the tunnel.
Comments	Bidirectional policy-based VPN policy.

Place VPN policies in the policy list above any other policies having similar source and destination addresses.

How to work with overlapping subnets

A site-to-site VPN configuration sometimes has the problem that the private subnet addresses at each end are the same. You can resolve this problem by remapping the private addresses using virtual IP addresses (VIP).

VIPs allow computers on those overlapping private subnets to each have another set of IP addresses that can be used without confusion. The FortiGate unit maps the VIP addresses to the original addresses. This means if PC1 starts a session with PC2 at 10.31.101.10, FortiGate_2 directs that session to 10.11.101.10 — the actual IP address of PC2.The figure below demonstrates this — Finance network VIP is 10.21.101.0/24 and the HR network is 10.31.101.0/24.

How to work with overlapping subnets

Overlapped subnets example

Solution for route-based VPN

You need to:

• Configure IPsec Phase 1 and Phase 2 as you usually would for a route-based VPN. In this example, the resulting IPsec interface is named FGT1_to_FGT2.
• Configure virtual IP (VIP) mapping:
• the 10.21.101.0/24 network mapped to the 10.11.101.0/24 network on FortiGate_1
• the 10.31.101.0/24 network mapped to the 10.11.101.0/24 network on FortiGate_2 l Configure an outgoing security policy with ordinary source NAT on both FortiGates.
• Configure an incoming security policy with the VIP as the destination on both FortiGates.
• Configure a route to the remote private network over the IPsec interface on both FortiGates.

To configure VIP mapping on both FortiGates

1. Go to Policy & Objects > Virtual IPs and create a new Virtual IP.
2. Enter the following information, and select OK:

	Name		Enter a name, for example, my_vip.
	External Interface		Select FGT1_to_FGT2. The IPsec interface.
VIP Type		Depending on both FortiGates, select one of the following options: l    IPv4: If both FortiGates use IPv4 (Static NAT). l    IPv6: If both FortiGates use IPv6 (Static NAT). l    NAT46: Maps the IPv4 address into an IPv6 prefix. l    NAT64: Maps the IPv6 address into an IPv4 prefix.
External IP Address/Range		For the External IP Address field enter: 10.21.101.1  when configuring FortiGate_1, or 10.31.101.1  when configuring FortiGate_2.
Mapped IP Address/Range		For the Mapped IP Address enter 10.11.101.1. For the Range enter 10.11.101.254.
Port Forwarding		Disable

3. Repeat this procedure on both FortiGate_1 and FortiGate_2.

To configure the outbound security policy on both FortiGates

1. Go to Policy & Objects > IPv4 Policy and select Create New.
2. Enter the following information, and select OK:

Incoming Interface	Select Port 1.
Outgoing Interface	Select FGT1_to_FGT2. The IPsec interface.
Source	Select all.
Destination Address	Select all.
Action	Select ACCEPT
NAT	Enable NAT.

3. Repeat this procedure on both FortiGate_1 and FortiGate_2.

To configure the inbound security policy on both FortiGates

1. Go to Policy & Objects > IPv4 Policy and select Create New.
2. Enter the following information, and then select OK:

Incoming Interface

Select FGT1_to_FGT2.

How to work with overlapping subnets

Outgoing Interface	Select Port 1. The IPsec interface.
Source	Select all.
Destination Address	Select my-vip.
Action	Select ACCEPT
NAT	Disable NAT.

3. Repeat this procedure on both FortiGate_1 and FortiGate_2.

To configure the static route for both FortiGates

1. Go to Network > Static Routes and create a new Route (or IPv6 Route as necessary).
2. Enter the following information, and then select OK:

Destination	Enter a subnet of 10.31.101.0/24 when configuring FortiGate_1. Enter a subnet of 10.21.101.0/24 when configuring FortiGate_2.
Device	Select FGT1_to_FGT2.
Gateway	Leave as default: 0.0.0.0.
Administrative Distance	Leave at default (10). If you have advanced routing on your network, you may have to change this value.
Advanced Options	If you have advanced routing on your network, enable Advanced Options and enter a Priority.

Solution for policy-based VPN

As with the route-based solution, users contact hosts at the other end of the VPN using an alternate subnet address. PC1 communicates with PC2 using IP address 10.31.101.10, and PC2 communicates with PC1 using IP address 10.21.101.10.

In this solution however, outbound NAT is used to translate the source address of packets from the

10.11.101.0/24 network to the alternate subnet address that hosts at the other end of the VPN use to reply. Inbound packets from the remote end have their destination addresses translated back to the 10.11.101.0/24 network.

For example, PC1 uses the destination address 10.31.101.10 to contact PC2. Outbound NAT on FortiGate_1 translates the PC1 source address to 10.21.101.10. At the FortiGate_2 end of the tunnel, the outbound NAT configuration translates the destination address to the actual PC2 address of 10.11.101.10. Similarly, PC2 replies to PC1 using destination address 10.21.101.10, with the PC2 source address translated to 10.31.101.10. PC1 and PC2 can communicate over the VPN even though they both have the same IP address.

You need to:

• Configure IPsec Phase 1 as you usually would for a policy-based VPN. l Configure IPsec Phase 2 with the use-natip disable CLI option.  l Define a firewall address for the local private network, 10.11.101.0/24.
• Define a firewall address for the remote private network:
• Define a firewall address for 10.31.101.0/24 on FortiGate_1
• Define a firewall address for 10.21.101.0/24 on FortiGate_2
• Configure an outgoing IPsec security policy with outbound NAT to map 10.11.101.0/24 source addresses:
• To the 10.21.101.0/24 network on FortiGate_1
• To the 10.31.101.0/24 network on FortiGate_2

To configure IPsec Phase 2 – CLI

config vpn ipsec phase2 edit “FGT1_FGT2_p2” set keepalive enable set pfs enable set phase1name FGT1_to_FGT2 set proposal 3des-sha1 3des-md5 set replay enable set use-natip disable

end

In this example, your Phase 1 definition is named FGT1_to_FGT2. use-natip is set to disable, so you can specify the source selector using the src-addr-type, src-start-ip / src-end-ip or src-subnet keywords. This example leaves these keywords at their default values, which specify the subnet 0.0.0.0/0.

The pfs keyword ensures that perfect forward secrecy (PFS) is used. This ensures that each Phase 2 key created is unrelated to any other keys in use.

To define the local private network firewall address

1. Go to Policy & Objects > Addresses and create a new Address. 2. Enter the following information and select OK.

Category	Set to Address.
Name	Enter vpn-local. A meaningful name for the local private network.
Type	Set to IP/Netmask.
Subnet / IP Range	10.11.101.0 255.255.255.0
Interface	Set to any.

To define the remote private network firewall address

1. Go to Policy & Objects > Addresses and create a new Address.
2. Enter the following information, and select OK:

Category

Set to Address.

Testing

Name	Enter vpn-remote. A meaningful name for the remote private network.
Type	Set to IP/Netmask.
Subnet / IP Range	10.31.101.0 255.255.255.0 on FortiGate_1. 10.21.101.0 255.255.255.0 on FortiGate_2.
Interface	Any

To configure the IPsec security policy

In the CLI on FortiGate_1, enter the commands:

config firewall policy edit 1 set srcintf “port1” set dstintf “port2” set srcaddr “vpn-local” set dstaddr “vpn-remote” set action ipsec set schedule “always” set service “ANY” set inbound enable set outbound enable set vpntunnel “FGT1_to_FGT2” set natoutbound enable

set natip 10.31.101.0 255.255.255.0

end

Optionally, you can set everything except natip in the web-based manager and then use the CLI to set natip.

Enter the same commands on FortiGate_2, but set natip be 10.21.101.0 255.255.255.0.

Testing

The best testing is to look at the packets both as the VPN tunnel is negotiated, and when the tunnel is up.

Determining what the other end of the VPN tunnel is proposing

1. Start a terminal program such as PuTTY and set it to log all output.

When necessary refer to the logs to locate information when output is verbose.

2. Logon to the FortiGate unit using a super_admin account.
3. Enter the following CLI commands.
4. Display all the possible IKE error types and the number of times they have occurred:

 

diag vpn ike errors

 

5. Check for existing debug sessions:

 

diag debug info

 

 

Testing

If a debug session is running, to halt it enter:

diag debug disable

 

6. Confirm your proposal settings:

 

diag vpn ike config list

 

7. If your proposal settings do not match what you expect, make a change to it and save it to force an update in memory. If that fixes the problem, stop here.
8. List the current vpn filter:

 

diag vpn ike filter

 

9. If all fields are set to any, there are no filters set and all VPN IKE packets will be displayed in the debug output. If your system has only a few VPNs, skip setting the filter.

If your system has many VPN connections this will result in very verbose output and make it very difficult to locate the correct connection attempt.

10. Set the VPN filter to display only information from the destination IP address for example 10.10.10.10:

 

diag vpn ike log-filter dst-addr4 10.10.10.10

To add more filter options, enter them one per line as above. Other filter options are:

clear	erase the current filter
dst-addr6	the IPv6 destination address range to filter by
dst-port	the destination port range to filter by
interface	interface that IKE connection is negotiated over
list	display the current filter
name	the phase1 name to filter by
negate	negate the specified filter parameter
src-addr4	the IPv4 source address range to filter by
src-addr6	the IPv6 source address range to filter by
src-port	the source port range to filter by
vd	index of virtual domain. 0 matches all

11. Start debugging:

diag debug app ike 255 diag debug enable

 

12. Have the remote end attempt a VPN connection.

If the remote end attempts the connection they become the initiator. This situation makes it easier to debug VPN tunnels because then you have the remote information and all of your local information. by initiate the connection, Testing

you will not see the other end’s information.

13. If possible go to the web-based manager on your FortiGate unit, go to the VPN monitor and try to bring the tunnel up.
14. Stop the debug output:

 

diag debug disable

 

15. Go back through the output to determine what proposal information the initiator is using, and how it is different from your VPN P1 proposal settings.

Things to look for in the debug output of attempted VPN connections are shown below.

Important terms to look for in VPN debug output

initiator	Starts the VPN attempt, in the above procedure that is the remote end
responder	Answers the initiator’s request
local ID	In aggressive mode, this is not encrypted
error no SA proposal chosen	There was no proposal match — there was no encryption-authentication pair in common, usually occurs after a long list of proposal attempts
R U THERE and R U THERE ack	dead peer detection (dpd), also known as dead gateway detection — after three failed attempts to contact the remote end it will be declared dead, no farther attempts will be made to contact it
negotiation result	lists the proposal settings that were agreed on
SA_life_soft and SA_life_ hard	negotiating a new key, and the key life
R U THERE	If you see this, it means Phase 1 was successful
tunnel up	the negotiation was successful, the VPN tunnel is operational

Defining VPN security policies

This section explains how to specify the source and destination IP addresses of traffic transmitted through an IPsec VPN, and how to define appropriate security policies.

The following topics are included in this section:

Defining policy addresses

Defining security policies for policy-based and route-based VPNs

Defining policy addresses

A VPN tunnel has two end points. These end points may be VPN peers such as two FortiGate gateways. Encrypted packets are transmitted between the end points. At each end of the VPN tunnel, a VPN peer intercepts encrypted packets, decrypts the packets, and forwards the decrypted IP packets to the intended destination.

You need to define firewall addresses for the private networks behind each peer. You will use these addresses as the source or destination address depending on the security policy.

policy addresses

Example topology for the following policies

In general:

• In a gateway-to-gateway, hub-and-spoke, dynamic DNS, redundant-tunnel, or transparent configuration, you need to define a policy address for the private IP address of the network behind the remote VPN peer (for example,

192.168.10.0/255.255.255.0 or 192.168.10.0/24).

• In a peer-to-peer configuration, you need to define a policy address for the private IP address of a server or host behind the remote VPN peer (for example, 16.5.1/255.255.255.255 or 172.16.5.1/32 or 172.16.5.1).

For a FortiGate dialup server in a dialup-client or Internet-browsing configuration:

• If you are not using VIP addresses, or if the FortiGate dialup server assigns VIP addresses to FortiClient dialup clients through FortiGate DHCP relay, select the predefined destination address “all” in the security policy to refer to the dialup clients.
• If you assign VIP addresses to FortiClient dialup clients manually, you need to define a policy address for the VIP address assigned to the dialup client (for example, 254.254.1/32), or a subnet address from which the VIP addresses are assigned (for example, 10.254.254.0/24 or 10.254.254.0/255.255.255.0).
• For a FortiGate dialup client in a dialup-client or Internet-browsing configuration, you need to define a policy address for the private IP address of a host, server, or network behind the FortiGate dialup server.

VPN security policies                                  Defining security policies for policy-based and route-based VPNs

Defining a security IP address

1. Go to Policy & Objects > Addresses and select Create New.
2. In the Name field, type a descriptive name that represents the network, server(s), or host(s).
3. In Type, select Subnet.
4. In the Subnet/IP Range field, type the corresponding IP address and subnet mask.

For a subnet you could use the format 172.16.5.0/24 or its equivalent 172.16.5.0/255.255.255.0. For a server or host it would likely be 172.16.5.1/32. Alternately you can use an IP address range such as

192.168.10.[80-100] or 192.168.10.80-192.168.10.100.

5. Select OK.

Defining security policies for policy-based and route-based VPNs

Security policies allow IP traffic to pass between interfaces on a FortiGate unit. You can limit communication to particular traffic by specifying source address and destination addresses. Then only traffic from those addresses will be allowed.

Policy-based and route-based VPNs require different security policies.

• A policy-based VPN requires an IPsec security policy. You specify the interface to the private network, the interface to the remote peer and the VPN tunnel. A single policy can enable traffic inbound, outbound, or in both directions.
• A route-based VPN requires an Accept security policy for each direction. As source and destination interfaces, you specify the interface to the private network and the virtual IPsec interface (Phase 1 configuration) of the VPN. The IPsec interface is the destination interface for the outbound policy and the source interface for the inbound policy. One security policy must be configured for each direction of each VPN interface.

There are examples of security policies for both policy-based and route-based VPNs throughout this guide. See Route-based or policy-based VPN on page 119.

If the security policy, which grants the VPN Connection is limited to certain services,

DHCP must be included, otherwise the client won’t be able to retrieve a lease from the FortiGate’s (IPsec) DHCP server, because the DHCP Request (coming out of the tunnel) will be blocked.

Policy-based VPN

An IPsec security policy enables the transmission and reception of encrypted packets, specifies the permitted direction of VPN traffic, and selects the VPN tunnel. In most cases, a single policy is needed to control both inbound and outbound IP traffic through a VPN tunnel. Be aware of the following considerations below before creating an IPsec security policy.

Allow traffic to be initiated from the remote site

Security policies specify which IP addresses can initiate a tunnel. By default, traffic from the local private network initiates the tunnel. When the Allow traffic to be initiated form the remote site option is selected, traffic from a dialup client, or a computer on a remote network, initiates the tunnel. Both can be enabled at the same time for bi-directional initiation of the tunnel.

security policies for policy-based and route-based VPNs

Outbound and inbound NAT

When a FortiGate unit operates in NAT mode, you can also enable inbound or outbound NAT. Outbound NAT may be performed on outbound encrypted packets or IP packets in order to change their source address before they are sent through the tunnel. Inbound NAT is performed to intercept and decrypt emerging IP packets from the tunnel.

By default, these options are not selected in security policies and can only be set through the CLI. For more information on this, see the “config firewall” chapter of the FortiGate CLI Reference.

Source and destination addresses

Most security policies control outbound IP traffic. A VPN outbound policy usually has a source address originating on the private network behind the local FortiGate unit, and a destination address belonging to a dialup VPN client or a network behind the remote VPN peer. The source address that you choose for the security policy identifies from where outbound cleartext IP packets may originate, and also defines the local IP address or addresses that a remote server or client will be allowed to access through the VPN tunnel. The destination address that you choose identifies where IP packets must be forwarded after they are decrypted at the far end of the tunnel, and determines the IP address or addresses that the local network will be able to access at the far end of the tunnel.

Enabling other policy features

You can fine-tune a policy for services such as HTTP, FTP, and POP3, enable logging, traffic shaping, antivirus protection, web filtering, email filtering, file transfer, email services, and optionally allow connections according to a predefined schedule.

As an option, differentiated services (diffserv or DSCP) for the security policy can be enabled through the CLI. For more information on this feature, see the Traffic Shaping handbook chapter,  or the “firewall” chapter of the FortiGate CLI Reference.

Before you begin

Before you define the IPsec policy, you must:

• Define the IP source and destination addresses. See Defining policy addresses on page 78.
• Specify the Phase 1 authentication parameters. See Phase 1 parameters on page 52.
• Specify the Phase 2 parameters. See Phase 2 parameters on page 72.

Defining an IPsec security policy

1. Go to Policy & Objects > IPv4 Policy.
2. Select Create New and set the following options:

Name	Enter a name for the security policy.
Incoming Interface	Select the local interface to the internal (private) network.
Outgoing Interface	Select the local interface to the external (public) network.
Source	Select the name that corresponds to the local network, server(s), or host(s) from which IP packets may originate.

VPN security policies                                  Defining security policies for policy-based and route-based VPNs

Destination Address	Select the name that corresponds to the remote network, server(s), or host (s) to which IP packets may be delivered.
Schedule	Keep the default setting (always) unless changes are needed to meet specific requirements.
Service	Keep the default setting (ANY) unless changes are needed to meet your specific requirements.
Action	For the purpose of this configuration, set Action to IPsec. Doing this will close Firewall / Network Options and open VPN Tunnel options. Select the VPN tunnel of your choice, and select Allow traffic to be initiated from the remote site, which will allow traffic from the remote network to initiate the tunnel.

3. You may enable UTM features, and/or event logging, or select advanced settings to authenticate a user group, or shape traffic. For more information, see the Firewall handbook chapter.
4. Select OK.
5. Place the policy in the policy list above any other policies having similar source and destination addresses.

Defining multiple IPsec policies for the same tunnel

You must define at least one IPsec policy for each VPN tunnel. If the same remote server or client requires access to more than one network behind a local FortiGate unit, the FortiGate unit must be configured with an IPsec policy for each network. Multiple policies may be required to configure redundant connections to a remote destination or control access to different services at different times.

To ensure a secure connection, the FortiGate unit must evaluate policies with Action set to IPsec  before

ACCEPT and DENY. Because the FortiGate unit reads policies starting at the top of the list, you must move all IPsec policies to the top of the list, and be sure to  reorder your multiple IPsec policies that apply to the tunnel so that specific constraints can be evaluated before general constraints.

Adding multiple IPsec policies for the same VPN tunnel can cause conflicts if the policies specify similar source and destination addresses, but have different settings for the same service. When policies overlap in this manner, the system may apply the wrong IPsec policy or the tunnel may fail.

For example, if you create two equivalent IPsec policies for two different tunnels, it does not matter which one comes first in the list of IPsec policies — the system will select the correct policy based on the specified source and destination addresses. If you create two different IPsec policies for the same tunnel (that is, the two policies treat traffic differently depending on the nature of the connection request), you might have to reorder the IPsec policies to ensure that the system selects the correct IPsec policy.

Route-based VPN

When you define a route-based VPN, you create a virtual IPsec interface on the physical interface that connects to the remote peer. You create ordinary Accept security policies to enable traffic between the IPsec interface and the interface that connects to the private network. This makes configuration simpler than for policy-based VPNs, which require IPsec security policies.

security policies for policy-based and route-based VPNs

Defining security policies for a route-based VPN

1. Go to Policy & Objects > IPv4 Policy.
2. Select Create New and define an ACCEPT security policy to permit communication between the local private network and the private network behind the remote peer. Enter these settings in particular:

Name	Enter a name for the security policy.
Incoming Interface	Select the interface that connects to the private network behind this FortiGate unit.
Outgoing Interface	Select the IPsec Interface you configured.
Source	Select the address name that you defined for the private network behind this FortiGate unit.
Destination Address	Select the address name that you defined for the private network behind the remote peer.
Action	Select ACCEPT.
NAT	Disable NAT.

To permit the remote client to initiate communication, you need to define a security policy for communication in that direction.

3. Select Create New and enter these settings in particular:

Name		Enter a name for the security policy.
Incoming Interface		Select the IPsec Interface you configured.
Outgoing Interface		Select the interface that connects to the private network behind this FortiGate unit.
Source		Select the address name that you defined for the private network behind the remote peer.
Destination Address		Select the address name that you defined for the private network behind this FortiGate unit.
Action		Select ACCEPT.
NAT		Disable NAT.