L2TP and IPsec (Microsoft VPN)

This section describes how to set up a VPN that is compatible with the Microsoft Windows native VPN, which is Layer 2 Tunneling Protocol (L2TP) with IPsec encryption.

The following topics are included in this section:

Overview

Assumptions

Configuration overview

For troubleshooting information, refer to Troubleshooting L2TP and IPsec.

Overview

The topology of a VPN for Microsoft Windows dialup clients is very similar to the topology for FortiClient Endpoint Security clients.

Example FortiGate VPN configuration with Microsoft clients

Assumptions

For users, the difference is that instead of installing and using the FortiClient application, they configure a network connection using the software built into the Microsoft Windows operating system. Starting in FortiOS 4.0 MR2, you can configure a FortiGate unit to work with unmodified Microsoft VPN client software.

Layer 2 Tunneling Protocol (L2TP)

L2TP is a tunneling protocol published in 1999 that is used with VPNs, as the name suggests. Microsoft Windows operating system has a built-in L2TP client starting since Windows 2000. Mac OS X 10.3 system and higher also have a built-in client.

L2TP provides no encryption and used UDP port 1701. IPsec is used to secure L2TP packets. The initiator of the L2TP tunnel is called the L2TP Access Concentrator (LAC).

L2TP and IPsec is supported for native Windows XP, Windows Vista and Mac OSX native VPN clients. However, in Mac OSX (OSX 10.6.3, including patch releases) the L2TP feature does not work properly on the Mac OS side.

Assumptions

The following assumptions have been made for this example:

l L2TP protocol traffic is allowed through network firewalls (TCP and UDP port 1701) l User has Microsoft Windows 2000 or higher — a Windows version that supports L2TP

Configuration overview

The following section consists of configuring the FortiGate unit and configuring the Windows PC.

Configuring the FortiGate unit

To configure the FortiGate unit, you must:

l Configure LT2P users and firewall user group. l Configure the L2TP VPN, including the IP address range it assigns to clients. l Configure an IPsec VPN with encryption and authentication settings that match the Microsoft VPN client. l Configure security policies.

Configuring LT2P users and firewall user group

Remote users must be authenticated before they can request services and/or access network resources through the VPN. The authentication process can use a password defined on the FortiGate unit or an established external authentication mechanism such as RADIUS or LDAP.

Creating user accounts

You need to create user accounts and then add these users to a firewall user group to be used for L2TP authentication. The Microsoft VPN client can automatically send the user’s Window network logon credentials.

You might want to use these for their L2TP user name and password.

Creating a user account – web-based manager

1. Go to User & Device > User Definitionand select Create New.
2. Enter the User Name.
3. Do one of the following:

l Select Password and enter the user’s assigned password.

l Select Match user on LDAP server, Match user on RADIUS server, or Match user onTACACS+

server and select the authentication server from the list. The authentication server must be already configured on the FortiGate unit.

4. Select OK.

Creating a user account – CLI

To create a user account called user1 with the password 123_user, enter:

config user local edit user1 set type password set passwd “123_user” set status enable

end

Creating a user group

When clients connect using the L2TP-over-IPsec VPN, the FortiGate unit checks their credentials against the user group you specify for L2TP authentication. You need to create a firewall user group to use for this purpose.

Creating a user group – web-based manager

1. Go to User & Device > User Groups, select Create New, and enter the following:

Name	Type or edit the user group name (for example, L2TP_group).
Type	Select Firewall.
Available Users/Groups	The list of Local users, RADIUS servers, LDAP servers, TACACS+ servers, or PKI users that can be added to the user group. To add a member to this list, select the name and then select the right arrow button.
Members	The list of Local users, RADIUS servers, LDAP servers, TACACS+ servers, or PKI users that belong to the user group. To remove a member, select the name and then select the left arrow button.

2. Select OK.

Creating a user group – CLI

To create the user group L2TP_group and add members User_1, User_2, and User_3, enter:

config user group edit L2TP_group set group-type firewall set member User_1 User_2 User_3

 

end

Configuring L2TP

You can only configure L2TP settings in the CLI. As well as enabling L2TP, you set the range of IP address values that are assigned to L2TP clients and specify the user group that can access the VPN. For example, to allow access to users in the L2TP_group and assign them addresses in the range 192.168.0.50 to 192.168.0.59, enter:

config vpn l2tp set sip 192.168.0.50 set eip 192.168.0.59 set status enable set usrgrp “L2TP_group”

end

One of the security policies for the L2TP over IPsec VPN uses the client address range, so you need also need to create a firewall address for that range. For example,

config firewall address edit L2TPclients set type iprange set start-ip 192.168.0.50 set end-ip 192.168.0.59

end

Alternatively, you could define this range in the web-based manager.

Configuring IPsec

The Microsoft VPN client uses IPsec for encryption. The configuration needed on the FortiGate unit is the same as for any other IPsec VPN with the following exceptions.

l Transport mode is used instead of tunnel mode. l The encryption and authentication proposals must be compatible with the Microsoft client.

L2TP over IPsec is supported on the FortiGate unit for both policy-based and route-based configurations, but the following example is policy-based.

Configuring Phase 1 – web-based manager

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

Name	Enter a name for this VPN, dialup_p1 for example.
Remote Gateway	Dialup User
Local Interface	Select the network interface that connects to the Internet. For example, port1.
Mode	Main (ID protection)
Authentication Method	Preshared Key
Pre-shared Key	Enter the preshared key. This key must also be entered in the Microsoft VPN client.
Advanced	Select Advanced to enter the following information.
Phase 1 Proposal	Enter the following Encryption/Authentication pairs: AES256-MD5, 3DES-SHA1, AES192-SHA1
Diffie-Hellman Group	2
NAT Traversal	Enable
Dead Peer Detection	Enable

Configuring Phase 1 – CLI

To create a Phase 1 configuration called dialup_p1 on a FortiGate unit that has port1 connected to the Internet, you would enter:

config vpn ipsec phase1 edit dialup_p1 set type dynamic set interface port1 set mode main set psksecret ********

set proposal aes256-md5 3des-sha1 aes192-sha1

set dhgrp 2 set nattraversal enable set dpd [disable | on-idle | on-demand]

end

It is worth noting here that the command config vpn ipsec phase1 is used rather than config vpn ipsec phase1-interface because this configuration is policy-based and not route-based.

Configuring Phase 2 – web-based manager

1. Open the Phase 2 Selectors
2. Enter the following information and then select OK.

Phase 2 Proposal	Enter the following Encryption/Authentication pairs: AES256-MD5, 3DES-SHA1, AES192-SHA1
Enable replay detection	Enable
Enable perfect forward secrecy (PFS)	Disable
Keylife	3600 seconds

3. Make this a transport-mode VPN. You must use the CLI to do this. If your Phase 2 name is dialup_p2, you would enter:

config vpn ipsec phase2 edit dialup_p2 set encapsulation transport-mode

end

Configuring Phase 2 – CLI

To configure a Phase 2 to work with your phase_1 configuration, you would enter:

config vpn ipsec phase2 edit dialup_p2 set phase1name dialup_p1

set proposal aes256-md5 3des-sha1 aes192-sha1 set replay enable set pfs disable set keylifeseconds 3600 set encapsulation transport-mode

end

Once again, note here that the command config vpn ipsec phase2 is used rather than config vpn ipsec phase2-interface because this configuration is policy-based and not route-based.

Configuring security policies

The security policies required for L2TP over IPsec VPN are:

• An IPsec policy, as you would create for any policy-based IPsec VPN
• A regular ACCEPT policy to allow traffic from the L2TP clients to access the protected network

Configuring the IPsec security policy – web-based manager

1. Go to System > Feature Visibility and enable Policy-based IPsec VPN.
2. Go to Policy & Objects > IPv4 Policy and select Create New.
3. Set the Action to IPsec and enter the following information:

Incoming Interface	Select the interface that connects to the private network behind this FortiGate unit.
Source Address		All
Outgoing Interface		Select the FortiGate unit’s public interface.
Destination Address		All
VPN Tunnel		Select Use Existing and select the name of the Phase 1 configuration that you created. For example, dialup_p1. See Configuring IPsec on page 181.
Allow traffic to be initiated from the remote site		enable

4. Select OK.

Configuring the IPsec security policy – CLI

If your VPN tunnel (Phase 1) is called dialup_p1, your protected network is on port2, and your public interface is port1, you would enter:

config firewall policy edit 0 set srcintf port2 set dstintf port1 set srcaddr all set dstaddr all set action ipsec set schedule always set service all set inbound enable set vpntunnel dialup_p1

end

Configuring the ACCEPT security policy – web-based manager

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 FortiGate unit’s public interface.
Source Address	Select the firewall address that you defined for the L2TP clients.
Outgoing Interface	Select the interface that connects to the private network behind this FortiGate unit.
Destination Address	All
Action	ACCEPT

Configuring the ACCEPT security policy – CLI

If your public interface is port1, your protected network is on port2, and L2TPclients is the address range that L2TP clients use, you would enter: config firewall policy

edit 1 set srcintf port1 set dstintf port2 set srcaddr L2TPclients set dstaddr all set action accept set schedule always set service all

end

Configuring the Windows PC

Configuration of the Windows PC for a VPN connection to the FortiGate unit consists of the following:

1. In Network Connections, configure a Virtual Private Network connection to the FortiGate unit.
2. Ensure that the IPSEC service is running.
3. Ensure that IPsec has not been disabled for the VPN client. It may have been disabled to make the Microsoft VPN compatible with an earlier version of FortiOS.

The instructions in this section are based on Windows XP. Other versions of Windows may vary slightly.

Configuring the network connection

1. Open Network Connections.

This is available through the Control Panel.

2. Double-click New Connection Wizard and Select Next.
3. Select Connect to the network at my workplace.
4. Select Next.
5. Select Virtual Private Network connection and select Next.
6. In the Company Name field, enter a name for the connection and select Next.
7. Select Do not dial the initial connection and then select Next.
8. Enter the public IP address or FQDN of the FortiGate unit and select Next.
9. Optionally, select Add a shortcut to this connection to my desktop.
10. Select Finish.

The Connect dialog opens on the desktop.

11. Select Properties and then select the Security
12. Select IPsec Settings.
13. Select Use pre-shared key for authentication, enter the preshared key that you configured for your VPN, and select OK.
14. Select OK.

Checking that the IPsec service is running

1. Open Administrative Tools through the Control Panel.
2. Double-click Services.
3. Look for IPSEC Services. Confirm that the Startup Type is Automatic and Status is set to Started. If needed, double-click IPsec Services to change these settings.

Checking that IPsec has not been disabled

1. Select Start > Run.
2. Enter regedit and select OK.
3. Find the Registry key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RasMan\Parameters
4. If there is a ProhibitIPsec value, it must be set to 0.

Enforcing IPsec in L2TP configuration

An enforce-ipsec option is available in L2TP configuration to force the FortiGate L2TP server to accept only IPsec encrypted connections.

Syntax

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

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

 

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