IPv6 IPsec VPNs

This chapter describes how to configure your FortiGate unit’s IPv6 IPsec VPN functionality.

By default IPv6 configurations to not appear on the Web-based Manager. You need to enable the feature first.

To enable IPv6

1. Go to System > Feature Visibility.
2. Enable IPv6.
3. Select Apply.

The following topics are included in this section: Configuration examples

IPv6 IPsec support

FortiOS supports route-based IPv6 IPsec, but not policy-based. This section describes how IPv6 IPsec support differs from IPv4 IPsec support. FortiOS 4.0 MR3 is IPv6 Ready Logo Program Phase 2 certified.

Where both the gateways and the protected networks use IPv6 addresses, sometimes called IPv6 over IPv6, you can create either an auto-keyed or manually-keyed VPN. You can combine IPv6 and IPv4 addressing in an autokeyed VPN in the following ways:

IPv4 over IPv6	The VPN gateways have IPv6 addresses. The protected networks have IPv4 addresses. The Phase 2 configurations at either end use IPv4 selectors.
IPv6 over IPv4	The VPN gateways have IPv4 addresses. The protected networks use IPv6 addresses. The Phase 2 configurations at either end use IPv6 selectors.

Compared with IPv4 IPsec VPN functionality, there are some limitations:

l Except for IPv6 over IPv4, remote gateways with Dynamic DNS are not supported. l Selectors cannot be firewall address names. Only IP address, address range and subnet are supported. l Redundant IPv6 tunnels are not supported.

Certificates

On a VPN with IPv6 Phase 1 configuration, you can authenticate using VPN certificates in which the common name (cn) is an IPv6 address. The cn-type keyword of the user peer command has an option, ipv6, to support this.

Configuration examples

This section consists of the following configuration examples:

l Site-to-site IPv6 over IPv6 VPN example l Site-to-site IPv6 over IPv4 VPN example l Site-to-site IPv4 over IPv6 VPN example

Site-to-site IPv6 over IPv6 VPN example

In this example, computers on IPv6-addressed private networks communicate securely over public IPv6 infrastructure.

By default IPv6 configurations to not appear on the Web-based Manager. You need to enable the feature first.

                                    To enable IPv6

1. Go to System > Feature Visibility.
2. Enable IPv6.
3. Select Apply.

Example IPv6-over-IPv6 VPN topology

Configure FortiGate A interfaces

Port 2 connects to the public network and port 3 connects to the local network.

config system interface edit port2 config ipv6 set ip6-address fec0::0001:209:0fff:fe83:25f2/64

end

next edit port3 config ipv6 set ip6-address fec0::0000:209:0fff:fe83:25f3/64

end

next

end

Configure FortiGate A IPsec settings

The Phase 1 configuration creates a virtual IPsec interface on port 2 and sets the remote gateway to the public IP address FortiGate B. This configuration is the same as for an IPv4 route-based VPN, except that ip-version is set to 6 and the remote-gw6 keyword is used to specify an IPv6 remote gateway address.

config vpn ipsec phase1-interface edit toB set ip-version 6 set interface port2

set remote-gw6 fec0:0000:0000:0003:209:0fff:fe83:25c7

set dpd [disable | on-idle | on-demand] set psksecret maryhadalittlelamb set proposal 3des-md5 3des-sha1

end

By default, Phase 2 selectors are set to accept all subnet addresses for source and destination. The default setting for src-addr-type and dst-addr-type is subnet. The IPv6 equivalent is subnet6. The default subnet addresses are 0.0.0.0/0 for IPv4, ::/0 for IPv6.

config vpn ipsec phase2-interface edit toB2 set phase1name toB set proposal 3des-md5 3des-sha1 set pfs enable set replay enable set src-addr-type subnet6 set dst-addr-type subnet6

end

Configure FortiGate A security policies

Security policies are required to allow traffic between port3 and the IPsec interface toB in each direction. The address all6 must be defined using the firewall address6 command as ::/0.

config firewall policy6 edit 1 set srcintf port3 set dstintf toB set srcaddr all6

set dstaddr all6 set action accept set service ANY set schedule always

next edit 2 set srcintf toB set dstintf port3 set srcaddr all6 set dstaddr all6 set action accept set service ANY set schedule always

end

Configure FortiGate A routing

This simple example requires just two static routes. Traffic to the protected network behind FortiGate B is routed via the virtual IPsec interface toB. A default route sends all IPv6 traffic out on port2.

config router static6 edit 1 set device port2 set dst 0::/0

next edit 2 set device toB

set dst fec0:0000:0000:0004::/64

end

Configure FortiGate B

The configuration of FortiGate B is very similar to that of FortiGate A. A virtual IPsec interface toA is configured on port2 and its remote gateway is the public IP address of FortiGate A. Security policies enable traffic to pass between the private network and the IPsec interface. Routing ensures traffic for the private network behind FortiGate A goes through the VPN and that all IPv6 packets are routed to the public network.

config system interface edit port2 config ipv6 set ip6-address fec0::0003:209:0fff:fe83:25c7/64

end

next edit port3 config ipv6 set ip6-address fec0::0004:209:0fff:fe83:2569/64

end

end

config vpn ipsec phase1-interface edit toA set ip-version 6 set interface port2

set remote-gw6 fec0:0000:0000:0001:209:0fff:fe83:25f2

set dpd [disable | on-idle | on-demand] set psksecret maryhadalittlelamb set proposal 3des-md5 3des-sha1

end config vpn ipsec phase2-interface edit toA2 set phase1name toA set proposal 3des-md5 3des-sha1 set pfs enable set replay enable set src-addr-type subnet6 set dst-addr-type subnet6

end

config firewall policy6 edit 1 set srcintf port3 set dstintf toA set srcaddr all6 set dstaddr all6 set action accept set service ANY set schedule always

next edit 2

set srcintf toA set dstintf port3 set srcaddr all6 set dstaddr all6 set action accept set service ANY set schedule always

end

config router static6 edit 1 set device port2 set dst 0::/0

next edit 2

set device toA

set dst fec0:0000:0000:0000::/64

end

Site-to-site IPv6 over IPv4 VPN example

In this example, IPv6-addressed private networks communicate securely over IPv4 public infrastructure.

Example IPv6-over-IPv4 VPN topology

Configure FortiGate A interfaces

Port 2 connects to the IPv4 public network and port 3 connects to the IPv6 LAN.

config system interface edit port2 set 10.0.0.1/24 next edit port3 config ipv6

set ip6-address fec0::0001:209:0fff:fe83:25f3/64

end

Configure FortiGate A IPsec settings

The Phase 1 configuration uses IPv4 addressing.

config vpn ipsec phase1-interface

edit toB

set interface port2 set remote-gw 10.0.1.1 set dpd [disable | on-idle | on-demand] set psksecret maryhadalittlelamb set proposal 3des-md5 3des-sha1 end

The Phase 2 configuration uses IPv6 selectors. By default, Phase 2 selectors are set to accept all subnet addresses for source and destination. The default setting for src-addr-type and dst-addr-type is subnet. The IPv6 equivalent is subnet6. The default subnet addresses are 0.0.0.0/0 for IPv4, ::/0 for IPv6.

config vpn ipsec phase2-interface edit toB2 set phase1name toB set proposal 3des-md5 3des-sha1 set pfs enable set replay enable set src-addr-type subnet6 set dst-addr-type subnet6

end

Configure FortiGate A security policies

IPv6 security policies are required to allow traffic between port3 and the IPsec interface toB in each direction.

Define the address all6 using the firewall address6 command as ::/0.

config firewall policy6 edit 1 set srcintf port3 set dstintf toB set srcaddr all6 set dstaddr all6 set action accept set service ANY set schedule always

next edit 2 set srcintf toB set dstintf port3 set srcaddr all6 set dstaddr all6 set action accept set service ANY set schedule always

end

Configure FortiGate A routing

This simple example requires just two static routes. Traffic to the protected network behind FortiGate B is routed via the virtual IPsec interface toB using an IPv6 static route. A default route sends all IPv4 traffic, including the IPv4 IPsec packets, out on port2.

config router static6 edit 1 set device toB

set dst fec0:0000:0000:0004::/64

end

config router static edit 1 set device port2 set dst 0.0.0.0/0 set gateway 10.0.0.254 end

Configure FortiGate B

The configuration of FortiGate B is very similar to that of FortiGate A. A virtual IPsec interface toA is configured on port2 and its remote gateway is the IPv4 public IP address of FortiGate A. The IPsec Phase 2 configuration has IPv6 selectors.

IPv6 security policies enable traffic to pass between the private network and the IPsec interface. An IPv6 static route ensures traffic for the private network behind FortiGate A goes through the VPN and an IPv4 static route ensures that all IPv4 packets are routed to the public network.

config system interface edit port2 set 10.0.1.1/24

next edit port3 config ipv6 set ip6-address fec0::0004:209:0fff:fe83:2569/64

end

config vpn ipsec phase1-interface edit toA set interface port2 set remote-gw 10.0.0.1 set dpd [disable | on-idle | on-demand] set psksecret maryhadalittlelamb set proposal 3des-md5 3des-sha1

end

config vpn ipsec phase2-interface edit toA2 set phase1name toA set proposal 3des-md5 3des-sha1 set pfs enable set replay enable set src-addr-type subnet6 set dst-addr-type subnet6

end

config firewall policy6 edit 1 set srcintf port3 set dstintf toA set srcaddr all6 set dstaddr all6 set action accept set service ANY set schedule always

next edit 2 set srcintf toA set dstintf port3 set srcaddr all6 set dstaddr all6 set action accept set service ANY set schedule always

end

config router static6 edit 1

set device toA

set dst fec0:0000:0000:0000::/64

end

config router static edit 1 set device port2 set gateway 10.0.1.254

end

Site-to-site IPv4 over IPv6 VPN example

In this example, two private networks with IPv4 addressing communicate securely over IPv6 infrastructure.

Example IPv4-over-IPv6 VPN topology

Configure FortiGate A interfaces

Port 2 connects to the IPv6 public network and port 3 connects to the IPv4 LAN.

config system interface edit port2 config ipv6 set ip6-address fec0::0001:209:0fff:fe83:25f2/64

end

next edit port3 set 192.168.2.1/24 end

Configure FortiGate A IPsec settings

The Phase 1 configuration is the same as in the IPv6 over IPv6 example.

config vpn ipsec phase1-interface edit toB set ip-version 6 set interface port2

set remote-gw6 fec0:0000:0000:0003:209:0fff:fe83:25c7

set dpd [disable | on-idle | on-demand] set psksecret maryhadalittlelamb set proposal 3des-md5 3des-sha1

end

The Phase 2 configuration is the same as you would use for an IPv4 VPN. By default, Phase 2 selectors are set to accept all subnet addresses for source and destination.

config vpn ipsec phase2-interface edit toB2 set phase1name toB set proposal 3des-md5 3des-sha1 set pfs enable set replay enable

end

Configure FortiGate A security policies

Security policies are required to allow traffic between port3 and the IPsec interface toB in each direction. These are IPv4 security policies.

config firewall policy edit 1 set srcintf port3 set dstintf toB set srcaddr all set dstaddr all set action accept set service ANY set schedule always

next edit 2 set srcintf toB set dstintf port3 set srcaddr all set dstaddr all set action accept set service ANY set schedule always

end

Configure FortiGate A routing

This simple example requires just two static routes. Traffic to the protected network behind FortiGate B is routed via the virtual IPsec interface toB using an IPv4 static route. A default route sends all IPv6 traffic, including the IPv6 IPsec packets, out on port2. config router static6

edit 1 set device port2 set dst 0::/0

next edit 2 set device toB set dst 192.168.3.0/24

end

Configure FortiGate B

The configuration of FortiGate B is very similar to that of FortiGate A. A virtual IPsec interface toA is configured on port2 and its remote gateway is the public IP address of FortiGate A. The IPsec Phase 2 configuration has IPv4 selectors.

IPv4 security policies enable traffic to pass between the private network and the IPsec interface. An IPv4 static route ensures traffic for the private network behind FortiGate A goes through the VPN and an IPv6 static route ensures that all IPv6 packets are routed to the public network.

config system interface edit port2 config ipv6 set ip6-address fec0::0003:fe83:25c7/64

end

next edit port3 set 192.168.3.1/24

end

config vpn ipsec phase1-interface edit toA set ip-version 6 set interface port2

set remote-gw6 fec0:0000:0000:0001:209:0fff:fe83:25f2

set dpd [disable | on-idle | on-demand] set psksecret maryhadalittlelamb set proposal 3des-md5 3des-sha1

end

config vpn ipsec phase2-interface edit toA2 set phase1name toA set proposal 3des-md5 3des-sha1 set pfs enable set replay enable

end

config firewall policy edit 1 set srcintf port3 set dstintf toA set srcaddr all set dstaddr all set action accept set service ANY set schedule always

next edit 2 set srcintf toA set dstintf port3 set srcaddr all set dstaddr all set action accept set service ANY set schedule always

end

config router static6 edit 1

set device port2 set dst 0::/0

next edit 2

set device toA set dst 192.168.2.0/24 end

 

Redundant VPN configurations

This section discusses the options for supporting redundant and partially redundant IPsec VPNs, using routebased approaches.

The following topics are included in this section:

Configuration overview

IPsec VPN tunnel aggregate interfaces

Configuration overview

A FortiGate unit with two interfaces connected to the Internet can be configured to support redundant VPNs to the same remote peer. If the primary connection fails, the FortiGate unit can establish a VPN using the other connection.

Redundant tunnels do not support Tunnel Mode or manual keys. You must use Interface Mode.

A fully-redundant configuration requires redundant connections to the Internet on both peers. The figure below shows an example of this. This is useful to create a reliable connection between two FortiGate units with static IP addresses.

When only one peer has redundant connections, the configuration is partially-redundant. For an example of this, see Configuration overview on page 155. This is useful to provide reliable service from a FortiGate unit with static IP addresses that accepts connections from dialup IPsec VPN clients.

In a fully-redundant VPN configuration with two interfaces on each peer, four distinct paths are possible for VPN traffic from end to end. Each interface on a peer can communicate with both interfaces on the other peer. This ensures that a VPN will be available as long as each peer has one working connection to the Internet.

You configure a VPN and an entry in the routing table for each of the four paths. All of these VPNs are ready to carry data. You set different routing distances for each route and only the shortest distance route is used. If this route fails, the route with the next shortest distance is used.

The redundant configurations described in this chapter use route-based VPNs, otherwise known as virtual IPsec interfaces. This means that the FortiGate unit must operate in NAT mode. You must use auto-keying. A VPN that is created using manual keys cannot be included in a redundant-tunnel configuration.

The configuration described here assumes that your redundant VPNs are essentially equal in cost and capability. When the original VPN returns to service, traffic continues to use the replacement VPN until the replacement VPN fails. If your redundant VPN uses more expensive facilities, you want to use it only as a backup while the main VPN is down. For information on how to do this, see Configuration overview on page 155.

Example redundant-tunnel configuration

A VPN that is created using manual keys cannot be included in a redundant-tunnel configuration.

General configuration steps

A redundant configuration at each VPN peer includes:

• One Phase 1 configuration (virtual IPsec interface) for each path between the two peers. In a fully-meshed redundant configuration, each network interface on one peer can communicate with each network interface on the remote peer. If both peers have two public interfaces, this means that each peer has four paths, for example.
• One Phase 2 definition for each Phase 1 configuration. l One static route for each IPsec interface, with different distance values to prioritize the routes. l Two Accept security policies per IPsec interface, one for each direction of traffic. l Dead peer detection enabled in each Phase 1 definition.

The procedures in this section assume that two separate interfaces to the Internet are available on each VPN peer.

Configuring the VPN peers – route-based VPN

VPN peers are configured using Interface Mode for redundant tunnels.

Configure each VPN peer as follows:

1. Ensure that the interfaces used in the VPN have static IP addresses.
2. Create a Phase 1 configuration for each of the paths between the peers.
3. Enable dead peer detection so that one of the other paths is activated if this path fails.
4. Enter these settings in particular, and any other VPN settings as required:

Path 1

Remote Gateway	Select Static IP Address.
IP Address	Type the IP address of the primary interface of the remote peer.
Local Interface	Select the primary public interface of this peer.
Dead Peer Detection	Enable

Path 2

Remote Gateway	Select Static IP Address.
IP Address	Type the IP address of the secondary interface of the remote peer.
Local Interface	Select the primary public interface of this peer.
Dead Peer Detection	Enable

Path 3

Remote Gateway	Select Static IP Address.
IP Address	Type the IP address of the primary interface of the remote peer.
Local Interface	Select the secondary public interface of this peer.
Dead Peer Detection	Enable

Path 4

Remote Gateway	Select Static IP Address.
IP Address	Type the IP address of the secondary interface of the remote peer.
Local Interface	Select the secondary public interface of this peer.
Dead Peer Detection	Enable

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

Configuration overview

5. Create a Phase 2 definition for each path. See Phase 2 parameters on page 66. Select the Phase 1 configuration (virtual IPsec interface) that you defined for this path. You can select the name from the Static IP Address part of the list.
6. Create a route for each path to the other peer. If there are two ports on each peer, there are four possible paths between the peer devices.

Destination IP/Mask	The IP address and netmask of the private network behind the remote peer.
Device	One of the virtual IPsec interfaces on the local peer.
Distance	For each path, enter a different value to prioritize the paths.

7. Define the security policy for the local primary interface. See Defining VPN security policies on page 1. You need to create two policies for each path to enable communication in both directions. Enter these settings in particular:

Incoming Interface	Select the local interface to the internal (private) network.
Source Address	All
Outgoing Interface	Select one of the virtual IPsec interfaces you created in Step 2.
Destination Address	All
Schedule	Always
Service	Any
Action	ACCEPT

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

Incoming Interface	Select one of the virtual IPsec interfaces you created in Step 2.
Source Address	All
Outgoing Interface	Select the local interface to the internal (private) network.
Destination Address	All
Schedule	Always
Service	Any
Action	ACCEPT

9. Place the policy in the policy list above any other policies having similar source and destination addresses.
10. Repeat this procedure at the remote FortiGate unit.

Creating a backup IPsec interface

You can configure a route-based VPN that acts as a backup facility to another VPN. It is used only while your main VPN is out of service. This is desirable when the redundant VPN uses a more expensive facility.

You can configure a backup IPsec interface only in the CLI. The backup feature works only on interfaces with static addresses that have dead peer detection enabled. The monitor option creates a backup VPN for the specified Phase 1 configuration.

In the following example, backup_vpn is a backup for main_vpn.

config vpn ipsec phase1-interface edit main_vpn set dpd on set interface port1 set nattraversal enable set psksecret “hard-to-guess” set remote-gw 192.168.10.8 set type static

end edit backup_vpn set dpd on set interface port2 set monitor main_vpn set nattraversal enable set psksecret “hard-to-guess” set remote-gw 192.168.10.8 set type static

end

IPsec VPN tunnel aggregate interfaces

This feature allows per-packet routing decisions to be made over two or more IPsec tunnel interfaces, which is usually configured to allow WAN connections to terminate at a data center so that redundancy and load-sharing can be built into this new interface.

The new virtual interface can bond/aggregate IPsec devices and have the new device do round-robin distribution, among other algorithms.

Syntax

config vpn ipsec phase1-interface edit <name> set interface wan1 set gateway …

… next edit <name> set interface wan2 set gateway …

…

next

end

config vpn ipsec phase2-interface

IPsec VPN tunnel aggregate interfaces

… end config system interface edit ipsec-bond

set type tun-agg set member isp1 isp2

next

end config router static edit <value>

set dst <address> set device ipsec-bond

next end

 

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

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) l A FortiClient dialup-client configuration (see FortiClient dialup-client configurations on page 1) l 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 151, below. l 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 151.

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.

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

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 153.
• To configure a FortiClient Endpoint Security application for Internet browsing via VPN, see Configuring a FortiClient application to support Internet browsing on page 154.

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

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:

 

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 46.
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.
ipv4-split-exclude ipv6-split-exclude	This command allows the administrator to specify that default traffic flows over the IPsec tunnel except for specified subnets. This is the opposite of the supported split-include feature which allows the administrator to specify that default traffic should not flow over the IPsec tunnel except for specified subnets.

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

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

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

Split-exclude in IKEv1 mode-cfg

This feature allows the administrator to specify when using IKEv1 Configuration Method that default traffic flows over the IPsec tunnel except for specified subnets. This is the opposite of the supported split-include feature which allows the administrator to specify that default traffic should not flow over the IPsec tunnel except for specified subnets.

The split-include and split-exclude options can both be specified at the same time. Whether a client does the right thing when both are specified depends on the client.

Syntax

config vpn ipsec {phase1 | phase1-interface} edit <name> set ike-version 1 set type dynamic set mode-cfg enable set ipv4-split-exclude {all | none | address} set ipv6-split-exclude {all | none | address}

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

 

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

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

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. l NAT mode is required if you want to create a route-based VPN. l 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. l 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 137. l Configure the FortiGate dialup client. See Configuration overview on page 137.

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

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 66. 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.
7. 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 137 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 46.

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 66. 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.
8. 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 137 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.

IPsec dial-up interface sharing

It is possible to use a single interface for all instances that spawn via a given phase1. In this case, instead of creating an interface per instance, all traffic will run over the single interface and any routes that need creating will be created on that single interface.

The CLI option “net-device[enable|disable]” is available in the phase1-interface command sets. Under the new single-interface scheme, instead of relying on routing to guide traffic to the specific instance, all traffic will flow to the specific device and IPsec will need to take care of locating the correct instance for outbound traffic. For this purpose, the CLI option “tunnel-search” is provided. The option is only available when the above “netdevice” option is “disable”.

There are two options for “tunnel-search”, corresponding to the two ways to select the tunnel for outbound traffic. One is “selectors”, meaning selecting a peer using the IPsec selectors (proxy-ids). The other is “nexthop” where all the peers use the same default selectors (0/0) while using some routing protocols such as BGP, OSPF, RIPng, etc to resolve the routing. The default for “tunnel-search” is “selectors”.

Syntax

config vpn ipsec phase1-interface edit xxx set net-device [enable|disable] Enable to create a kernel device for every dialup instance

next

end

config vpn ipsec phase1-interface edit xxx set net-device disable

set tunnel-search [selectors|nexthop] Search for tunnel in selectors or using nexthops

next end

 

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

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

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 135. l 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 46. l Configure the FortiClient application to use XAuth. See Configuration overview on page 128. 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 l If the dialup clients use automatic configuration, configure the FortiGate unit as a VPN policy server l 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 l Configure the FortiGate Phase 2 VPN settings l 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 46.

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

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

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

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.

135

5. Open the .. menu and set Mode to Server.
6. Select OK.

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

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

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 115 and Dynamic DNS configuration on page 115.

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.

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.