Category Archives: FortiOS 5.4 Handbook

The complete handbook for FortiOS 5.4

Protecting OSPF with IPsec

Leave a reply

Protecting OSPF with IPsec

For enhanced security, OSPF dynamic routing can be carried over IPsec VPN links. The following topics are included in this section:

  • Overview
  • OSPF over IPsec configuration
  • Creating a redundant configuration

 

Overview

This chapter shows an example of OSPF routing conducted over an IPsec tunnel between two FortiGate units. The network shown below is a single OSPF area. FortiGate_1 is an Area border router that advertises a static route to 10.22.10.0/24 in OSPF. FortiGate_2 advertises its local LAN as an OSPF internal route.

 

OSPF over an IPsec VPN tunnel

protecting-ospf-over-ipsec

The section Overview describes the configuration with only one IPsec VPN tunnel, tunnel_wan1. Then, the section Overview describes how you can add a second tunnel to provide a redundant backup path. This is shown above as VPN tunnel “tunnel_wan2”.

Only the parts of the configuration concerned with creating the IPsec tunnel and integrating it into the OSPF network are described. It is assumed that security policies are already in place to allow traffic to flow between the interfaces on each FortiGate unit.

 

OSPF over IPsec configuration

There are several steps to the OSPF-over-IPsec configuration:

  • Configure a route-based IPsec VPN on an external interface. It will connect to a corresponding interface on the other  FortiGate unit. Define the two tunnel-end addresses.
  • Configure a static route to the other FortiGate unit.
  • Configure the tunnel network as part of the OSPF network and define the virtual IPsec interface as an OSPF interface.

 

This section describes the configuration with only one VPN, tunnel_wan1. The other VPN is added in the section OSPF over IPsec configuration on page 1800.

 

Configuring the IPsec VPN

A route-based VPN is required. In this chapter, preshared key authentication is shown. Certificate authentication is also possible. Both FortiGate units need this configuration.

 

To configure Phase 1

1. Define the Phase 1 configuration needed to establish a secure connection with the other FortiGate unit. For more information, see Phase 1 parameters on page 1624.

Enter these settings in particular:

Name                                           Enter a name to identify the VPN tunnel, tunnel_wan1 for example. This becomes the name of the virtual IPsec interface.

Remote Gateway                       Select Static IP Address.

IP Address                                 Enter the IP address of the other FortiGate unit’s public (Port 2) interface.

Local Interface                          Select this FortiGate unit’s public (Port 2) interface.

Mode                                           Select Main (ID Protection).

Authentication Method            Preshared Key

Pre–shared Key                          Enter the preshared key. It must match the preshared key on the other FortiGate unit.

Advanced                                   Select Advanced.

 

To assign the tunnel end IP addresses

1. Go to Network > Interfaces, select the virtual IPsec interface that you just created on Port 2 and select Edit.

2. In the IP and Remote IP fields, enter the following tunnel end addresses:

 

  FortiGate_1 FortiGate_2
IP 10.1.1.1 10.1.1.2
Remote_IP 10.1.1.2 10.1.1.1

These addresses are from a network that is not used for anything else.

 

To configure Phase 2

1. Enter a name to identify this Phase 2 configuration, twan1_p2, for example.

2. Select the name of the Phase 1 configuration that you defined in Step “OSPF over IPsec configuration” on page 1800, tunnel_wan1 for example.

 

Configuring static routing

 

You need to define the route for traffic leaving the external interface.

1. Go to Network > Static Routes, select Create New.

2. Enter the following information.

Destination IP/Mask                 Leave as 0.0.0.0 0.0.0.0.

Device                                         Select the external interface.

Gateway                                     Enter the IP address of the next hop router.

 

Configuring OSPF

This section does not attempt to explain OSPF router configuration. It focusses on the integration of the IPsec tunnel into the OSPF network. This is accomplished by assigning the tunnel as an OSPF interface, creating an OSPF route to the other FortiGate unit.

This configuration uses loopback interfaces to ease OSPF troubleshooting. The OSPF router ID is set to the loopback interface address.The loopback interface ensures the router is always up. Even though technically the router ID doesn’t have to match a valid IP address on the FortiGate unit, having an IP that matches the router ID makes troubleshooting a lot easier.

The two FortiGate units have slightly different configurations. FortiGate_1 is an AS border router that advertises its static default route. FortiGate_2 advertises its local LAN as an OSPF internal route.

Setting the router ID for each FortiGate unit to the lowest possible value is useful if you want the FortiGate units to be the designated router (DR) for their respective ASes. This is the router that broadcasts the updates for the AS.

Leaving the IP address on the OSPF interface at 0.0.0.0 indicates that all potential routes will be advertised, and it will not be limited to any specific subnet. For example if this IP address was 10.1.0.0, then only routes that match that subnet will be advertised through this interface in OSPF.

 

FortiGate_1 OSPF configuration

When configuring FortiGate_1 for OSPF, the loopback interface is created, and then you configure OSPF area networks and interfaces.

With the exception of creating the loopback interface, OSPF for this example can all be configured in either the web-based manager or CLI.

 

To create the loopback interface

A loopback interface can be configured in the CLI only. For example, if the interface will have an IP address of 10.0.0.1, you would enter:

config system interface edit lback1

set vdom root

set ip 10.0.0.1 255.255.255.255 set type loopback

end

The loopback addresses and corresponding router IDs on the two FortiGate units must be different. For example, set the FortiGate 1 loopback to 10.0.0.1 and the FortiGate 2 loopback to 10.0.0.2.

 

To configure OSPF area, networks, and interfaces – web-based manager

1. On FortiGate_1, go to Network > OSPF.

2. Enter the following information to define the router, area, and interface information.

Router ID                                    Enter 10.0.0.1. Select Apply before entering the remaining inform- ation.

Advanced Options

Redistribute                               Select the Connected and Static check boxes. Use their default metric val- ues.

Areas                                          Select Create New, enter the Area and Type and then select OK.

Area                                            0.0.0.0

Type                                            Regular

Interfaces                                   Enter a name for the OSPF interface, ospf_wan1 for example.

Name

Interface                                     Select the virtual IPsec interface, tunnel_wan1.

IP                                                 0.0.0.0

3. For Networks, select Create New.

4. Enter the IP/Netmask of 1.1.0/255.255.255.0 and an Area of 0.0.0.0.

5. For Networks, select Create New.

6. Enter the IP/Netmask of 0.0.1/255.255.255.0 and an Area of 0.0.0.0.

7. Select Apply.

 

To configure OSPF area and interfaces – CLI

Your loopback interface is 10.0.0.1, your tunnel ends are on the 10.1.1.0/24 network, and your virtual IPsec interface is named tunnel_wan1. Enter the following CLI commands:

config router ospf

set router-id 10.0.0.1 config area

edit 0.0.0.0 end

config network edit 4

set prefix 10.1.1.0 255.255.255.0 next

edit 2

set prefix 10.0.0.1 255.255.255.255 end

config ospf-interface edit ospf_wan1

set cost 10

set interface tunnel_wan1

set network-type point-to-point end

config redistribute connected set status enable

end

config redistribute static set status enable

end end

 

FortiGate_2 OSPF configuration

When configuring FortiGate_2 for OSPF, the loopback interface is created, and then you configure OSPF area networks and interfaces.

Configuring FortiGate_2 differs from FortiGate_1 in that three interfaces are defined instead of two. The third interface is the local LAN that will be advertised into OSPF.

With the exception of creating the loopback interface, OSPF for this example can all be configured in either the web-based manager or CLI.

 

To create the loopback interface

A loopback interface can be configured in the CLI only. For example, if the interface will have an IP address of 10.0.0.2, you would enter:

config system interface edit lback1

set vdom root

set ip 10.0.0.2 255.255.255.255 set type loopback

end

The loopback addresses on the two FortiGate units must be different. For example, set the FortiGate 1 loopback to 10.0.0.1 and the FortiGate 2 loopback to 10.0.0.2.

 

To configure OSPF area and interfaces – web-based manager

1. On FortiGate_2, go to Network > OSPF.

2. Complete the following.

Router ID                                    10.0.0.2

Areas                                          Select Create New, enter the Area and Type and then select OK.

Area                                            0.0.0.0

Type                                            Regular

Interfaces

Name                                           Enter a name for the OSPF interface, ospf_wan1 for example.

Interface                                     Select the virtual IPsec interface, tunnel_wan1.

IP                                                 0.0.0.0

3. For Networks, select Create New.

4. Enter the following information for the loopback interface:

IP/Netmask                                 10.0.0.2/255.255.255.255

Area                                            0.0.0.0

5. For Networks, select Create New.

6. Enter the following information for the tunnel interface:

IP/Netmask                                 10.1.1.0/255.255.255.255

Area                                            0.0.0.0

7. For Networks, select Create New.

8. Enter the following information for the local LAN interface:

IP/Netmask                                 10.31.101.0/255.255.255.255

Area                                            0.0.0.0

9. Select Apply.

 

To configure OSPF area and interfaces – CLI

If for example, your loopback interface is 10.0.0.2, your tunnel ends are on the 10.1.1.0/24 network, your local LAN is 10.31.101.0/24, and your virtual IPsec interface is named tunnel_wan1, you would enter:

config router ospf

set router-id 10.0.0.2 config area

edit 0.0.0.0

end

config network edit 1

set prefix 10.1.1.0 255.255.255.0 next

edit 2

set prefix 10.31.101.0 255.255.255.0 next

edit 2

set prefix 10.0.0.2 255.255.255.255 end

config ospf-interface edit ospf_wan1

set interface tunnel_wan1

set network-type point-to-point end

end

 

Creating a redundant configuration

You can improve the reliability of the OSPF over IPsec configuration described in the previous section by adding a second IPsec tunnel to use if the default one goes down. Redundancy in this case is not controlled by the IPsec VPN configuration but by the OSPF routing protocol.

 

To do this you:

  • Create a second route-based IPsec tunnel on a different interface and define tunnel end addresses for it.
  • Add the tunnel network as part of the OSPF network and define the virtual IPsec interface as an additional OSPF interface.
  • Set the OSPF cost for the added OSPF interface to be significantly higher than the cost of the default route.

 

Adding the second IPsec tunnel

The configuration is the same as in Creating a redundant configuration on page 1805, but the interface and addresses will be different. Ideally, the network interface you use is connected to a different Internet service provider for added redundancy.

When adding the second tunnel to the OSPF network, choose another unused subnet for the tunnel ends, 10.1.2.1 and 10.1.2.2 for example.

 

Adding the OSPF interface

OSPF uses the metric called cost when determining the best route, with lower costs being preferred. Up to now in this example, only the default cost of 10 has been used. Cost can be set only in the CLI.

The new IPsec tunnel will have its OSPF cost set higher than that of the default tunnel to ensure that it is only used if the first tunnel goes down. The new tunnel could be set to a cost of 200 compared to the default cost is 10. Such a large difference in cost will ensure this new tunnel will only be used as a last resort. If the new tunnel is called tunnel_wan2, you would enter the following on both FortiGate units:

config router ospf

config ospf-interface edit ospf_wan2

set cost 200

set interface tunnel_wan2

set network-type point-to-point end

end

GRE over IPsec (Cisco VPN)

Leave a reply

GRE over IPsec (Cisco VPN)

This section describes how to configure a FortiGate VPN that is compatible with Cisco-style VPNs that use GRE in an IPsec tunnel.

The following topics are included in this section:

  • Overview
  • Configuring the FortiGate unit
  • Configuring the Cisco router
  • Troubleshooting

 

Overview

Cisco products that include VPN support often use Generic Routing Encapsulation (GRE) protocol tunnel over IPsec encryption. This chapter describes how to configure a FortiGate unit to work with this type of Cisco VPN.

Cisco VPNs can use either transport mode or tunnel mode IPsec. Before FortiOS 4.0 MR2, the FortiGate unit was compatible only with tunnel mode IPsec.

 

Example FortiGate to Cisco GRE-over-IPsec VPN

cisco-gre-over-ipsec

In this example, users on LAN1 are provided access to LAN2.

Pages: 1 2 3 4

L2TP and IPsec (Microsoft VPN)

7 Replies

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
  • Configuring the FortiGate unit Configuring the Windows PC Troubleshooting

 

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

example-fortigate-vpn-configuration

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:

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

 

Configuring the FortiGate unit

To configure the FortiGate unit, you must:

  • Configure LT2P users and firewall user group.
  • Configure the L2TP VPN, including the IP address range it assigns to clients.
  • Configure an IPsec VPN with encryption and authentication settings that match the Microsoft VPN client.
  • 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.

 

To create a user account – web-based manager

1. Go to User & Device > User Definition and select Create New.

2. Enter the User Name.

3. Do one of the following:

  • Select Password and enter the user’s assigned password.
  • 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.

 

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

 

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

 

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

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

Whether Transport mode is required depends on the configuration of the peer device (typically an old Windows device, since newer versions of Windows don’t require IPsec and L2TP—they can run IPsec natively).

When configuring L2TP, do not name the VPN “L2TP” as that will result in a conflict.

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

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

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.

 

To configure 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 tab.

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.

 

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

 

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

 

 

Troubleshooting

This section describes some checks and tools you can use to resolve issues with L2TP-over-IPsec VPNs. This section includes:

  • Quick checks
  • Mac OS X and L2TP
  • Setting up logging
  • Using the FortiGate unit debug commands

 

Quick checks

The table below is a list of common L2TP over IPsec VPN problems and the possible solutions.

 

Problem                                   What to check

IPsec tunnel does not come up.

Check the logs to determine whether the failure is in Phase 1 or Phase 2.

Check the settings, including encapsulation setting, which must be trans- port-mode.

Check the user password.

Confirm that the user is a member of the user group assigned to L2TP. On the Windows PC, check that the IPsec service is running and has not been disabled. See Troubleshooting on page 1786.

 

Tunnel connects, but there is no communication.

Did you create an ACCEPT security policy from the public network to the protected network for the L2TP clients? See Troubleshooting on page 1786.

 

Mac OS X and L2TP

FortiOS allows L2TP connections with empty AVP host names and therefore Mac OS X L2TP connections can connect to the FortiGate.

Prior to FortiOS 4.0 MR3, FortiOS refused L2TP connections with empty AVP host names in compliance with RFC 2661 and RFC 3931.

 

Setting up logging

L2TP logging must be enabled to record L2TP events. Alert email can be configured to report L2TP errors.

 

To configure FortiGate logging for L2TP over IPsec

1. Go to Log & Report > Log Settings.

2. Select Event Log.

3. Select the VPN activity event check box.

4. Select Apply.

 

To view FortiGate logs

1. Go to Log & Report > VPN Events.

2. Select the Log location if required.

3. After each attempt to start the L2TP over IPsec VPN, select Refresh to view logged events.

 

Using the FortiGate unit debug commands

 

To view debug output for IKE and L2TP

1. Start an SSH or Telnet session to your FortiGate unit.

2. Enter the following CLI commands

diagnose debug application ike -1 diagnose debug application l2tp -1 diagnose debug enable

3. Attempt to use the VPN and note the debug output in the SSH or Telnet session.

4. Enter the following command to reset debug settings to default:

diagnose debug reset

 

To use the packet sniffer

1. Start an SSH or Telnet session to your FortiGate unit.

2. Enter the following CLI command

diagnose sniffer packet any icmp 4

3. Attempt to use the VPN and note the debug output.

4. Enter Ctrl-C to end sniffer operation.

 

Typical L2TP over IPsec session startup log entries – raw format

2010-01-11 16:39:58 log_id=0101037127 type=event subtype=ipsec pri=notice vd=”root” msg=”progress IPsec Phase 1″ action=”negotiate” rem_ip=172.20.120.151 loc_ip=172.20.120.141 rem_port=500 loc_port=500 out_ intf=”port1″ cookies=”5f6da1c0e4bbf680/d6a1009eb1dde780″ user=”N/A” group=”N/A” xauth_user=”N/A” xauth_ group=”N/A” vpn_tunnel=”dialup_p1″ status=success init=remote mode=main dir=outbound stage=1 role=responder result=OK

2010-01-11 16:39:58 log_id=0101037127 type=event subtype=ipsec pri=notice vd=”root” msg=”progress IPsec Phase 1″ action=”negotiate” rem_ip=172.20.120.151 loc_ip=172.20.120.141 rem_port=500 loc_port=500 out_ intf=”port1″ cookies=”5f6da1c0e4bbf680/d6a1009eb1dde780″ user=”N/A” group=”N/A” xauth_user=”N/A” xauth_ group=”N/A” vpn_tunnel=”dialup_p1″ status=success init=remote mode=main dir=outbound stage=2 role=responder result=OK

2010-01-11 16:39:58 log_id=0101037127 type=event subtype=ipsec pri=notice vd=”root” msg=”progress IPsec Phase 1″ action=”negotiate” rem_ip=172.20.120.151 loc_ip=172.20.120.141 rem_port=500 loc_port=500 out_ intf=”port1″ cookies=”5f6da1c0e4bbf680/d6a1009eb1dde780″ user=”N/A” group=”N/A” xauth_user=”N/A” xauth_ group=”N/A” vpn_tunnel=”dialup_p1″ status=success init=remote mode=main dir=inbound stage=3 role=responder result=DONE

2010-01-11 16:39:58 log_id=0101037127 type=event subtype=ipsec pri=notice vd=”root” msg=”progress IPsec Phase 1″ action=”negotiate” rem_ip=172.20.120.151 loc_ip=172.20.120.141 rem_port=500 loc_port=500 out_ intf=”port1″ cookies=”5f6da1c0e4bbf680/d6a1009eb1dde780″ user=”N/A” group=”N/A” xauth_user=”N/A” xauth_ group=”N/A” vpn_tunnel=”dialup_p1_0″ status=success init=remote mode=main dir=outbound stage=3 role=responder result=DONE

2010-01-11 16:39:58 log_id=0101037129 type=event subtype=ipsec pri=notice vd=”root” msg=”progress IPsec Phase 2″ action=”negotiate” rem_ip=172.20.120.151 loc_ip=172.20.120.141 rem_port=500 loc_port=500 out_ intf=”port1″ cookies=”5f6da1c0e4bbf680/d6a1009eb1dde780″ user=”N/A” group=”N/A” xauth_user=”N/A” xauth_group=”N/A” vpn_tunnel=”dialup_p1_0″ status=success init=remote mode=quick dir=outbound stage=1 role=responder result=OK

2010-01-11 16:39:58 log_id=0101037133 type=event subtype=ipsec pri=notice vd=”root” msg=”install IPsec SA” action=”install_sa” rem_ip=172.20.120.151 loc_ip=172.20.120.141 rem_port=500 loc_port=500 out_ intf=”port1″ cookies=”5f6da1c0e4bbf680/d6a1009eb1dde780″ user=”N/A” group=”N/A” xauth_user=”N/A” xauth_ group=”N/A” vpn_tunnel=”dialup_p1_0″ role=responder in_spi=61100fe2 out_spi=bd70fca1

2010-01-11 16:39:58 log_id=0101037139 type=event subtype=ipsec pri=notice vd=”root” msg=”IPsec Phase 2 status change” action=”phase2-up” rem_ip=172.20.120.151 loc_ip=172.20.120.141 rem_port=500 loc_port=500 out_intf=”port1″ cookies=”5f6da1c0e4bbf680/d6a1009eb1dde780″ user=”N/A” group=”N/A” xauth_user=”N/A” xauth_group=”N/A” vpn_tunnel=”dialup_p1_0″ phase2_name=dialup_p2

2010-01-11 16:39:58 log_id=0101037138 type=event subtype=ipsec pri=notice vd=”root” msg=”IPsec connection status change” action=”tunnel-up” rem_ip=172.20.120.151 loc_ip=172.20.120.141 rem_port=500 loc_port=500 out_intf=”port1″ cookies=”5f6da1c0e4bbf680/d6a1009eb1dde780″ user=”N/A” group=”N/A” xauth_ user=”N/A” xauth_group=”N/A” vpn_tunnel=”dialup_p1_0″ tunnel_ip=172.20.120.151 tunnel_id=1552003005 tunnel_type=ipsec duration=0 sent=0 rcvd=0 next_stat=0 tunnel=dialup_p1_0

2010-01-11 16:39:58 log_id=0101037129 type=event subtype=ipsec pri=notice vd=”root” msg=”progress IPsec Phase 2″ action=”negotiate” rem_ip=172.20.120.151 loc_ip=172.20.120.141 rem_port=500 loc_port=500 out_ intf=”port1″ cookies=”5f6da1c0e4bbf680/d6a1009eb1dde780″ user=”N/A” group=”N/A” xauth_user=”N/A” xauth_ group=”N/A” vpn_tunnel=”dialup_p1_0″ status=success init=remote mode=quick dir=inbound stage=2 role=responder result=DONE

2010-01-11 16:39:58 log_id=0101037122 type=event subtype=ipsec pri=notice vd=”root” msg=”negotiate IPsec Phase 2″ action=”negotiate” rem_ip=172.20.120.151 loc_ip=172.20.120.141 rem_port=500 loc_port=500 out_ intf=”port1″ cookies=”5f6da1c0e4bbf680/d6a1009eb1dde780″ user=”N/A” group=”N/A” xauth_user=”N/A” xauth_ group=”N/A” vpn_tunnel=”dialup_p1_0″ status=success role=responder esp_transform=ESP_3DES esp_auth=HMAC_ SHA1

2010-01-11 16:39:58 log_id=0103031008 type=event subtype=ppp vd=root pri=information action=connect status=success msg=”Client 172.20.120.151 control connection started (id 805), assigned ip 192.168.0.50″ 2010-01-11 16:39:58 log_id=0103029013 type=event subtype=ppp vd=root pri=notice pppd is started

2010-01-11 16:39:58 log_id=0103029002 type=event subtype=ppp vd=root pri=notice user=”user1″ local=172.20.120.141 remote=172.20.120.151 assigned=192.168.0.50 action=auth_success msg=”User ‘user1’ using l2tp with authentication protocol MSCHAP_V2, succeeded”

2010-01-11 16:39:58 log_id=0103031101 type=event subtype=ppp vd=root pri=information action=tunnel-up tunnel_id=1645784497 tunnel_type=l2tp remote_ip=172.20.120.151 tunnel_ip=192.168.0.50 user=”user1″ group=”L2TPusers” msg=”L2TP tunnel established”

Site-to-site IPv6 over IPv4 VPN example

Leave a reply

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

ipv4-sitetosite

 

 

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

Leave a reply

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

10-230-2016

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

Configuring IPv6 IPsec VPNs

Leave a reply

Configuring IPv6 IPsec VPNs

Configuration of an IPv6 IPsec VPN follows the same sequence as for an IPv4 route-based VPN: Phase 1 settings, Phase 2 settings, security policies and routing.

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

2. Enable IPv6.

3. Select Apply.

 

Phase 1 configuration

In the web-based manager, you define the Phase 1 as IPv6 in the Advanced settings. Enable the IPv6 Version check box. You can then enter an IPv6 address for the remote gateway.

In the CLI, you define an IPsec Phase 1 configuration as IPv6 by setting ip-version to 6. Its default value is 4. Then, the local-gw and remote-gw keywords are hidden and the corresponding local-gw6 and remote- gw6 keywords are available. The values for local-gw6 and remote-gw6 must be IPv6 addresses. For example:

config vpn ipsec phase1-interface edit tunnel6

set ip-version 6

set remote-gw6 0:123:4567::1234 set interface port3

set proposal 3des-md5 end

 

Phase 2 configuration

To create an IPv6 IPsec Phase 2 configuration in the web-based manager, you need to define IPv6 selectors in the Advanced settings. Change the default “0.0.0.0/0” address for Source address and Destination address to the IPv6 value “::/0”. If needed, enter specific IPv6 addresses, address ranges, or subnet addresses in these fields.

In the CLI, set src-addr-type and dst-addr-type to ip6, range6 or subnet6 to specify IPv6 selectors. By default, zero selectors are entered, “::/0” for the subnet6 address type, for example. The simplest IPv6 Phase 2 configuration looks like this:

config vpn ipsec phase2-interface edit tunnel6_p2

set phase1name tunnel6 set proposal 3des-md5

set src-addr-type subnet6 set dst-addr-type subnet6

end

 

The management of static selector rules is performed by the IKE daemon, which allows named selectors to be reloaded if any named address or address groups are changed, without requiring the FortiGate unit to be rebooted before applying changes.

 

Security policies

To complete the VPN configuration, you need a security policy in each direction to permit traffic between the protected network’s port and the IPsec interface. You need IPv6 policies unless the VPN is IPv4 over IPv6.

 

Routing

Appropriate routing is needed for both the IPsec packets and the encapsulated traffic within them. You need a route, which could be the default route, to the remote VPN gateway via the appropriate interface. You also need a route to the remote protected network via the IPsec interface.

 

To create a static route in the web-based manager

1. Go to Network > Static Routes.

2. Select the drop-down arrow on the Create New button and select IPv6 Route.

3. Enter the information and select OK.

In the CLI, use the router static6 command. For example, where the remote network is fec0:0000:0000:0004::/64 and the IPsec interface is toB:

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 next

end

 

If the VPN is IPV4 over IPv6, the route to the remote protected network is an IPv4 route. If the VPN is IPv6 over IPv4, the route to the remote VPN gateway is an IPv4 route.

 

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

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

IPv6 IPsec VPNs

Leave a reply

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

2. Enable IPv6.

3. Select Apply.

 

The following topics are included in this section:

  • Overview of IPv6 IPsec support
  • Configuring IPv6 IPsec VPNs
  • Site-to-site IPv6 over IPv6 VPN example
  • Site-to-site IPv4 over IPv6 VPN example
  • Site-to-site IPv6 over IPv4 VPN example

 

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.

 

Overview of 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 auto- keyed 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:

  • Except for IPv6 over IPv4, remote gateways with Dynamic DNS are not supported.
  • Selectors cannot be firewall address names. Only IP address, address range and subnet are supported.
  • 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.

Transparent mode VPNs

Leave a reply

Transparent mode VPNs

This section describes transparent VPN configurations, in which two FortiGate units create a VPN tunnel between two separate private networks transparently.

The following topics are included in this section:

  • Configuration overview
  • Configure the VPN peers

Configuration overview

In transparent mode, all interfaces of the FortiGate unit except the management interface (which by default is assigned IP address 10.10.10.1/255.255.255.0) are invisible at the network layer. Typically, when a FortiGate unit runs in transparent mode, different network segments are connected to the FortiGate interfaces. The figure below shows the management station on the same subnet. The management station can connect to the FortiGate unit directly through the web-based manager.

 

Management station on internal network

An edge router typically provides a public connection to the Internet and one interface of the FortiGate unit is connected to the router. If the FortiGate unit is managed from an external address (see the figure below), the router must translate (NAT) a routable address to direct management traffic to the FortiGate management interface.

 

Management station on external network

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

Both FortiGate units may be running in transparent mode, or one could be running in transparent mode and the other running in NAT mode. If the remote peer is running in NAT mode, it must have a static public IP address.

VPNs between two FortiGate units running in transparent mode do not support inbound/outbound NAT (supported through CLI commands) within the tunnel. In addi- tion, a FortiGate unit running in transparent mode cannot be used in a hub-and-spoke configuration.

Encrypted packets from the remote VPN peer are addressed to the management interface of the local FortiGate unit. If the local FortiGate unit can reach the VPN peer locally, a static route to the VPN peer must be added to the routing table on the local FortiGate unit. If the VPN peer connects through the Internet, encrypted packets from the local FortiGate unit must be routed to the edge router instead. For information about how to add a static route to the FortiGate routing table, see the Advanced Routing Guide.

In the example configuration shown above, Network Address Translation (NAT) is enabled on the router. When an encrypted packet from the remote VPN peer arrives at the router through the Internet, the router performs inbound NAT and forwards the packet to the FortiGate unit. Refer to the software supplier’s documentation to configure the router.

If you want to configure a VPN between two FortiGate units running in transparent mode, each unit must have an independent connection to a router that acts as a gateway to the Internet, and both units must be on separate networks that have a different address space. When the two networks linked by the VPN tunnel have different address spaces (see the figure below), at least one router must separate the two FortiGate units, unless the packets can be redirected using ICMP (as shown in the following figure).

 

Link between two FortiGate units in transparent mode

In the figure below, interface C behind the router is the default gateway for both FortiGate units. Packets that cannot be delivered on Network_1 are routed to interface C by default. Similarly, packets that cannot be delivered on Network_2 are routed to interface C. In this case, the router must be configured to redirect packets destined for Network_1 to interface A and redirect packets destined for Network_2 to interface B.

 

ICMP redirecting packets to two FortiGate units in transparent mode

If there are additional routers behind the FortiGate unit (see the figure below) and the destination IP address of an inbound packet is on a network behind one of those routers, the FortiGate routing table must include routes to those networks. For example, in the following figure, the FortiGate unit must be configured with static routes to interfaces A and B in order to forward packets to Network_1 and Network_2 respectively.

 

Destinations on remote networks behind internal routers

 

Transparent VPN infrastructure requirements

  • The local FortiGate unit must be operating in transparent mode.
  • The management IP address of the local FortiGate unit specifies the local VPN gateway. The management IP address is considered a static IP address for the local VPN peer.
  • If the local FortiGate unit is managed through the Internet, or if the VPN peer connects through the Internet, the edge router must be configured to perform inbound NAT and forward management traffic and/or encrypted packets to the FortiGate unit.
  • If the remote peer is operating in NAT mode, it must have a static public IP address.

 

A FortiGate unit operating in transparent mode requires the following basic configuration to operate as a node on the IP network:

  • The unit must have sufficient routing information to reach the management station.
  • For any traffic to reach external destinations, a default static route to an edge router that forwards packets to the Internet must be present in the FortiGate routing table.
  • When all of the destinations are located on the external network, the FortiGate unit may route packets using a single default static route. If the network topology is more complex, one or more static routes in addition to the default static route may be required in the FortiGate routing table.

 

Only policy-based VPN configurations are possible in transparent mode.

 

Before you begin

An IPsec VPN definition links a gateway with a tunnel and an IPsec policy. If your network topology includes more than one virtual domain, you must choose components that were created in the same virtual domain. Therefore, before you define a transparent VPN configuration, choose an appropriate virtual domain in which to create the required interfaces, security policies, and VPN components. For more information, see the Virtual Domains guide.

 

 

Configure the VPN peers

1. The local VPN peer need to operate in transparent mode.

To determine if your FortiGate unit is in transparent mode, go to the Dashboard > System Information widget. Select [change]. Select transparent for the Operation Mode. Two new fields will appear to enter the Management IP/Netmask, and the Default Gateway.

In transparent mode, the FortiGate unit is invisible to the network. All of its interfaces are on the same subnet and share the same IP address. You only have to configure a management IP address so that you can make configuration changes.

The remote VPN peer may operate in NAT mode or transparent mode.

2. At the local FortiGate unit, define the Phase 1 parameters needed to establish a secure connection with the remote peer. See Phase 1 parameters on page 1624. Select Advanced and enter these settings in particular:

Remote Gateway                       Select Static IP Address.

IP Address                                 Type the IP address of the public interface to the remote peer. If the remote peer is a FortiGate unit running in transparent mode, type the IP address of the remote management interface.

Advanced                                   Select Nat-traversal, and type a value into the Keepalive Frequency field. These settings protect the headers of encrypted packets from being altered by external NAT devices and ensure that NAT address mappings do not change while the VPN tunnel is open. For more information, see Phase 1 parameters on page 1624 and Phase 1 parameters on page 1624.

3. Define the Phase 2 parameters needed to create a VPN tunnel with the remote peer. See Phase 2 parameters on page 1642. Select the set of Phase 1 parameters that you defined for the remote peer. The name of the remote peer can be selected from the Static IP Address list.

4. Define the source and destination addresses of the IP packets that are to be transported through the VPN tunnel.

See Defining VPN security policies on page 1648. Enter these settings in particular:

  • For the originating address (source address), enter the IP address and netmask of the private network behind the local peer network. for the management interface, for example, 10.10.10.0/24. This address needs to be a range to allow traffic from your network through the tunnel. Optionally select any for this address.
  • For the remote address (destination address), enter the IP address and netmask of the private network behind the remote peer (for example, 192.168.10.0/24). If the remote peer is a FortiGate unit running in transparent mode, enter the IP address of the remote management interface instead.

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

Defining VPN security policies on page 1648. Enter these settings in particular:

Incoming Interface                   Select the local interface to the internal (private) network.

Source Address                        Select the source address that you defined in Step 4.

Outgoing Interface                   Select the interface to the edge router. When you configure the IPsec secur- ity policy on a remote peer that operates in NAT mode, you select the pub- lic interface to the external (public) network instead.

Destination Address                 Select the destination address that you defined in Step 4.

VPN Tunnel                                Select Use Existing and select the name of the Phase 2 tunnel con- figuration that you created in Step 3 from the drop-down list.

Select Allow traffic to be initiated from the remote site to enable traffic from the remote network to initiate the tunnel.

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

7. Define another IPsec security policy to permit communications between the source and destination addresses in the opposite direction. This security policy and the previous one form a bi-directional policy pair. See Defining VPN security policies on page 1648. Enter these settings in particular:

Incoming Interface                   Select the interface to the edge router. When you configure the IPsec secur- ity policy on a remote peer that operates in NAT mode, you select the pub- lic interface to the external (public) network instead.

Source Address                        Select the destination address that you defined in Step 4..

Outgoing Interface                   Select the local interface to the internal (private) network.

Destination Address                 Select the source address that you defined in Step 4.

VPN Tunnel                                Select Use Existing and select the name of the Phase 2 tunnel con- figuration that you created in Step 3 from the drop-down list.

Select Allow traffic to be initiated from the remote site to enable traffic from the remote network to initiate the tunnel.

8. Repeat this procedure at the remote FortiGate unit to create bidirectional security policies. Use the local interface and address information local to the remote FortiGate unit.

For more information on transparent mode, see the System Administration Guide.