Quantcast
Channel: IPsec VPN – Fortinet Cookbook
Viewing all 62 articles
Browse latest View live

IPsec VPN with the native Mac OS client

$
0
0

In this recipe, you will learn how to create an IPsec VPN on a FortiGate, and connect to it using the default client built into the Mac OS.

This VPN configuration allows Mac users to securely access an internal network as well as browse the Internet through the VPN tunnel.

This recipe was tested using Mac OS 10.10.2 (Yosemite).

1. Configuring the IPsec VPN using the IPsec VPN Wizard

Go to VPN > IPSec > Wizard.

Name the VPN connection and select Dial Up – Cisco Firewall and click Next.

Set the Incoming Interface to the internet-facing interface.

Select Pre-shared Key for the Authentication Method.

Enter a pre-shared key, select the appropriate User Group, then click Next.

Set Local Interface to an internal interface and set Local Address to the local LAN address.

Enter an IP address range for VPN users in the Client Address Range field then click Next.

The IPsec VPN Wizard finishes with a summary of created objects.
Go to Policy & Objects > Objects > Addresses and confirm that the wizard has created the IPsec VPN firewall address range.
Go to Policy & Objects > Policy > IPv4 and confirm that the wizard has created the policy from the VPN tunnel interface to the internal interface.

2. Creating a security policy for remote access to the Internet

Under Policy & Objects > Policy > IPv4, create a security policy 

allowing remote users to access the Internet securely through the FortiGate unit.

Set Incoming Interface to the tunnel interface and set Source Address to all.

Set Outgoing Interface to the Internet-facing interface and Destination Address to all.

Set Service to ALL and enable NAT.

The policy should appear in the policy list at Policy & Objects > Policy > IPv4.

3. Connecting to the IPsec VPN using the native Mac client

On the Mac, go to System Preferences > Network and click the Plus (+) button.
Set Interface to VPN, set VPN Type to Cisco IPSec, and click Create.
Set the Server Address to the FortiGate IP address, configure the network account details for the remote user, then click Authentication Settings.

Select Shared Secret and enter the pre-shared key you created above, then click OK.

4. Results

On the Mac, ensure that the VPN is selected and click Connect. The Status should change to Connected and you should be given an IP Address in the range specified above.

You should also be able to browse the Internet, protected by whichever profiles you applied to the security policy created in the above step.

On the FortiGate unit, go to VPN > Monitor > IPsec Monitor and verify that the tunnel Status is Up, and that there are Incoming and Outgoing Data.

For further reading, check out IPsec VPN in the web-based manager in the FortiOS 5.2 Handbook.

The recipe assumes that a “mac_users user group and a Local LAN firewall address have been created.
The native Mac OS client is a Cisco client, which is why you select Dialup – Cisco Firewall in the VPN Wizard.

The post IPsec VPN with the native Mac OS client appeared first on Fortinet Cookbook.


OSPF over dynamic IPsec VPN (Expert)

$
0
0

This example shows how to create a dynamic IPsec VPN tunnel and allowing OSPF through it.

1. Configuring IPsec in FortiGate 1

Go to System > Status to look for the CLI Console widget and create phase 1.

config vpn ipsec phase1-interface
    edit "dial-up"
        set type dynamic
        set interface "wan1"
        set mode-cfg enable
        set proposal 3des-sha1
        set add-route disable
        set ipv4-start-ip 10.10.101.0
        set ipv4-end-ip 10.10.101.255
        set psksecret
    next
end

Create phase 2.

config vpn ipsec phase2-interface
    edit "dial-up-p2"
        set phase1name "dial-up"
        set proposal 3des-sha1 aes128-sha1
    next
end

2. Configuring OSPF in FortiGate 1

Go to System > Status to look for the CLI Console widget and create OSPF route.

config router ospf
    set router-id 172.20.120.22
        config area
            edit 0.0.0.0
            next
        end
        config network
            edit 1
                set prefix 10.10.101.0 255.255.255.0
            next
        end
        config redistribute "connected"
            set status enable
        end
        config redistribute "static"
            set status enable
        end
end

 3. Adding policies in FortiGate 1

Go to Policy & Objects > Policy > IPv4 and create a policy allowing OSPF traffic from dial-up to port5.

 
 

Go to Policy & Objects > Policy > IPv4 and create a policy allowing OSPF traffic from port5 to dial-up interfaces.

 

4. Configuring IPSec in FortiGate 2

Go to System > Status to look for the CLI Console widget and create phase 1.

config vpn ipsec phase1-interface
    edit "dial-up-client"
        set interface "wan1"
        set mode-cfg enable
        set proposal 3des-sha1
        set add-route disable
        set remote-gw 172.20.120.22
        set psksecret
    next
end

Create phase 2.

config vpn ipsec phase2-interface
    edit "dial-up-client-p2"
        set phase1name "dial-up-client"
        set proposal 3des-sha1 aes128-sha1
        set auto-negotiate enable
    next
end

5. Configuring OSPF in FortiGate 2

Go to System > Status to look for the CLI Console widget and create OSPF route.

config router ospf
    set router-id 172.20.120.25
        config area
            edit 0.0.0.0
            next
        end
        config network
            edit 1
                set prefix 10.10.101.0 255.255.255.0
            next
        end
        config redistribute "connected"
            set status enable
        end
        config redistribute "static"
            set status enable
        end
end

6. Adding policies in FortiGate 2

Go to Policy & Objects > Policy > IPv4 and create a policy allowing OSPF traffic from dial-up-client to port5.

Go to Policy & Objects > Policy > IPv4 and create a policy allowing OSPF traffic from port5 to dial-up-client interfaces.

 

8. Verifying tunnel is up

Go to VPN > Monitor > IPsec Monitor to verify that the tunnel is Up.

 

 9. Results

From FortiGate 1, go to Router > Monitor > Routing Monitor and verify that routes from FortiGate 2 were successfully advertised to FortiGate 1 via OSPF.   
From FortiGate 1, go to System > Status to look for the CLI Console widget and type this command to verify OSPF neighbors.

get router info ospf neighbor

OSPF process 0:
Neighbor ID     Pri   State      Dead Time   Address         Interface
172.20.120.25     1   Full/ -    00:00:34    10.10.101.1     dial-up_0

From FortiGate 2, go to Router > Monitor > Routing Monitor and verify that routes from FortiGate 1 were successfully advertised to FortiGate 2 via OSPF.

 
From FortiGate 2, go to System > Status to look for the CLI Console widget and type this command to verify OSPF neighbors.

get router info ospf neighbor

OSPF process 0:
Neighbor ID     Pri   State   Dead Time   Address      Interface
172.20.120.22     1   Full/ - 00:00:30    10.10.101.2  dial-up-client

For further reading, check out IPsec VPN and Open Shortest Path First (OSPF) in the FortiOS 5.2 Handbook.

 

The post OSPF over dynamic IPsec VPN (Expert) appeared first on Fortinet Cookbook.

IPsec VPN with two-factor authentication

$
0
0

In this recipe, two-factor authentication is added to a user account to provide extra security when connecting to an IPsec VPN using FortiClient for Mac OS x.

Two-factor authentication requires a user to authenticate twice before being allowed to access the IPsec VPN. In this recipe the FortiToken Mobile app for iOS provides a one-time password (OTP) (a 6-digit number) that the you must enter at a second authentication prompt.

This recipe assumes that you have already activated FortiToken Mobile (see Two-factor authentication with FortiToken Mobile for details).

1. Creating a user and user group  

Go to User & Device > User > User Definition and create a new local user.  
Enter the user’s login credentials. This example simply creates a local user.

For Contact Info, select SMS and be sure to include a Phone Number without dashes or spaces.

This example uses SMS to send an activation code to the user so we included the user’s mobile phone number here. Even if your FortiGate cannot send SMS messages you need to include a phone number for the IPsec VPN wizard to work.

Do not add an email address.

Select the FortiToken assigned to this user.
The user list shows the FortiToken in the Two-factor Authentication column for the new user account. 

Go to User & Device > User > User Groups. Create a user group for remote users and add the new user.

2. Adding a firewall address for the LAN

 

Go to Policy & Objects > Objects > Addresses.

Create a firewall address for your LAN’s subnet.

3. Configuring the IPsec VPN using the IPsec VPN Wizard

Go to VPN > IPSec > Wizard.

Name the VPN connection and select the new user group.

Set Local Interface to an internal interface (in the example, port 1) and set Local Address to the LAN address.

Enter an IP range for VPN users in the Client Address Range field.

Select Client Options as desired.
 

4. Creating a security policy for access to the Internet

Go to Policy & Objects > Policy > IPv4. Create a security policy allowing remote users to access the Internet securely through the FortiGate unit.

Set Incoming Interface to the tunnel interface and set Source Address to all. Set the Source User(s) to the new user group. Set Outgoing Interface to your Internet-facing interface and Destination Address to all.

Ensure that you enable NAT.

5. Sending the FortiToken activation code to the user

If your FortiGate can send SMS messages, go to User & Device > User > User Definition and edit the new user account. Select Send Activation Code and send the code by SMS.
If your FortiGate cannot send SMS messages, go to System > Dashboard > Status and enter the following into the CLI Console, substituting the correct serial number: config user fortitoken
  edit
  show
The activation code will be shown in the output. This code must be given to the user.

6. Setting up FortiToken Mobile on an iOS device

Using your iOS device, download and install FortiToken Mobile.  

Open the app and add a new account. Select Enter Manually, then select Fortinet under FORTINET ACCT.

Enter the activation code into FortiToken Mobile.

 
FortiToken Mobile can now generate a token for use with the FortiGate.
(Optional) For additional security, set a PIN for FortiToken Mobile using the app’s Settings options.  

7. Configuring FortiClient for Mac OS X

Using your Mac OS X device, download and install FortiClient.
Open FortiClient, go to Remote Access and select Add a new connection.

Provide a Connection Name and set the Type to IPsec VPN.

Set Remote Gateway to the FortiGate’s IP address.

Set Authentication Method to Pre-Shared Key and enter the key for the IPsec VPN.

8. Results

Using FortiClient, select the IPsec VPN connection, enter the password, and click Connect.
You will be prompted to enter your code from FortiToken mobile.
After your code has been verified, a connection to the IPsec VPN is established.

 

 and select Dial Up – FortiClient (Windows, Mac OS, Android).  

Set the Incoming Interface to the internet-facing interface.

Select Pre-shared Key for the Authentication Method. Enter a pre-shared keyThe pre-shared key is a credential for the VPN and should differ from the user’s password.

The IP range you enter here prompts FortiOS to create a new firewall object for the VPN tunnel using the name of your tunnel followed by the _range suffix (in this case, ipsecvpn_range). 

In addition, FortiOS automatically creates a security policy to allow remote users to access the internal network.

The post IPsec VPN with two-factor authentication appeared first on Fortinet Cookbook.

Remote browsing with VPN (Video)

$
0
0

In this video, you will learn how to use remote IPsec and SSL VPN tunnels to bypass internet access restrictions.

A VPN tunnel is an encrypted traffic passage between two endpoints. In this example, the VPN tunnel is between a local user running FortiClient with restricted internet access, and a remote FortiGate with unrestricted internet access. Restricted internet access will be simulated with a Web Filtering Profile that blocks google.com. You can create an SSL VPN tunnel or an IPsec VPN tunnel to connect to the remote FortiGate unit, and you will be able to bypass the web filter and browse to google.com.

The recipe for this video is available here.

Watch more videos

The post Remote browsing with VPN (Video) appeared first on Fortinet Cookbook.

IPsec VPN with external DHCP service

$
0
0

In this recipe you’ll use an external DHCP server to assign IP addresses to your IPsec VPN clients, this scenario is commonly found on enterprises where all DHCP leases need to be centrally managed.

The DHCP server assigns IP addresses in the range of 172.16.6.100 to 172.16.6.120. The server is attached to port 4 of the FortiGate and has an IP address of 192.168.3.70.

1. Creating a user group for remote users

Go to User & Device > User > User Definition.

Create a new Local User with the User Creation Wizard.

Proceed through each step of the wizard, carefully entering the appropriate information.

 

Go to User & Device > User > User Groups.

Create a user group for remote users and add the user you created.

 

2. Adding a firewall address for the local network and IPsec VPN client range

Go to Policy & Objects > Objects > Addresses.

Add a firewall address for the Local LAN, including the subnet and local interface.

 

Add a firewall address for the IPsec VPN client range.

2b-address-ipsecvpn-range

3. Configuring the IPsec VPN using a Custom VPN Tunnel

Go to VPN > IPSec > Tunnels > Create New.

Name the VPN connection and select Custom VPN Tunnel (No Template) and click Next.

3a-vpn-custom

Configure the following parameters:

Set the Remote Gateway to Dialup User

Set the Interface to the internet-facing interface.

Enter a Pre-shared Key

Set the Mode to Aggressive

Set the XAUTH Type to Auto Server

Set the XAUTH User Group to the User Group created on step 1 and click OK to apply the configuration

3b-vpn-custom-parameters
Use the CLI to enable DHCP-IPsec inside the VPN Phase 2 settings.
config vpn ipsec phase2-interface
    edit "dhcp_vpn"
        set dhcp-ipsec enable
    next
end

4. Configuring the IPsec VPN Interface

Go to System > Network > Interfaces.

Edit the newly created IPsec VPN Interface

Set the IP to the same subnet that will be leased to VPN clients. This is the value that the DHCP Administrator must use for the DHCP Option 003 (Router). Set the Remote IP to the same value.

Enable DHCP Server, then expand Advanced and change the mode to Relay. Enter the external DHCP server IP address and change the Type to IPsec.

 

4a-interface-dhcp

5. Creating a security policy for access to the Local LAN Network

Go to Policy & Objects > Policy > IPv4.

Create a security policy allowing the VPN IPsec client IP address range to access the Local LAN network.

Set Incoming Interface to the tunnel interface and set Source Address to the VPN IPsec client range defined on step 2.

Set Outgoing Interface to port4 and Destination Address to Local LAN.

Set Service to ALL

5a-policy

6. Configuring FortiClient

Open FortiClient, go to Remote Access and Add a new connection.

 

Provide a Connection Name and set the Type to IPsec VPN.

Set Remote Gateway to the FortiGate external IP address.

Set Authentication Method to Pre-Shared Key and enter the key below.

 

Expand Advanced Settings and VPN Settings

Select DHCP over IPsec

6c-forticlient-dhcp

Select the new connection, enter the username and password, and click Connect.

 

7. Results

Once the connection is established, the external DHCP server assigns the user an IP address and FortiClient displays the status of the connection, including the IP address, connection duration, and
bytes sent and received.

 

On the FortiGate unit, go to VPN > Monitor > IPsec Monitor and verify that the tunnel Status is Up.

 

Go to Log & Report > Traffic Log > Forward Traffic to view the traffic.

Verify that the Sent/Received column displays traffic successfully flowing through the tunnel.

 

For further reading, check out IPsec VPN in the web-based manager in the FortiOS 5.2 Handbook.

The tunnel name may not have any spaces in it.
The pre-shared key is a credential for the VPN and should differ from the user’s password.

The post IPsec VPN with external DHCP service appeared first on Fortinet Cookbook.

Site-to-site IPsec VPN with overlapping subnets

$
0
0

This recipe describes how to construct a site-to-site IPsec VPN connection between two networks with overlapping subnets, such that traffic will be directed to the correct address on the correct network, using Virtual IP addresses and static routes.

1. Create the IPsec VPN tunnel on FGT_1

Go to VPN > IPsec > Wizard.

Select Site to Site – FortiGate. Give it an appropriate Name and click Next.

Set Remote Gateway to the IP address used by the Internet-facing interface of FGT_2. The Outgoing Interface will automatically populate.

Enter a Pre-shared key and click Next.

Set Local Interface to your Internet-facing interface. The Local Subnets will automatically populate. Set Remote Subnets to the VIP of the internal network for FGT_2 (10.31.101.0/24) and click Create.
The VPN Wizard automatically creates the required objects, policies, and static route required for the tunnel to function properly.
You can verify the policy creation under Policy & Objects > Policy > IPv4.

2. Add the Virtual IP Range on FGT_1

Go to Policy & Objects > Objects > Virtual IPs and create a Virtual IP range to redirect the traffic to the correct subnet.

Select Virtual IP from the Create New drop down menu. Select IPv4 for the VIP Type and give the VIP an appropriate name.

Set the Interface to the IPsec VPN Site to Site interface from the drop down menu.

Set External IP Address/Range to a range in the subnet you will be redirecting from (10.21.101.1 – 10.21.101.254) and Mapped IP Address/Range to the internal network range (192.168.1.1 – 192.168.1.254).

Select OK.

3. Create the IPsec VPN tunnel on FGT_2 

Go to VPN > IPsec > Wizard.

Select Site to Site – FortiGate. Give it an appropriate Name and click Next.

 

Set Remote Gateway to the IP address used by the Internet-facing interface of FGT_1. The Outgoing Interface will automatically populate.

Enter a Pre-shared key and click Next.

Set Local Interface to your Internet-facing interface. The Local Subnets will automatically populate. Set Remote Subnets to the VIP of the internal network for FGT_1 (10.21.101.0/24) and click Create.

The VPN Wizard automatically creates the required objects, policies, and static route required for the tunnel to function properly.

As before, you can verify the policy creation under Policy & Objects > Policy > IPv4.

4. Add the Virtual IP Range on FGT_2

Go to Policy & Objects > Objects > Virtual IPs and create a Virtual IP range to redirect the traffic to the correct subnet.

Select Virtual IP from the Create New drop down menu. Select IPv4 for the VIP Type and give the VIP an appropriate name.

Set Interface to the IPsec VPN Site to Site interface from the drop down menu.

Set External IP Address/Range to a range in the subnet you will be redirecting from (10.31.101.1 – 10.31.101.254) and Mapped IP Address/Range to the internal network range (192.168.1.1 – 192.168.1.254).

Select OK.

5. Results

Go to VPN > Monitor > IPsec Monitor. Right-click on the Site to Site VPN and select Bring Up.

You will be able to see Incoming and Outgoing Data in the IPsec Monitor.

 

 

The post Site-to-site IPsec VPN with overlapping subnets appeared first on Fortinet Cookbook.

Behind the scenes of the VPN Creation Wizard

$
0
0

The new VPN Creation Wizard makes life easier for users that are unfamiliar with the creation of IPsec VPNs. However, not all of the meanings of the fields are intuitive and there are some limitations and requirements that users should be aware of.

Limitations

Types of VPN tunnels

Currently:

  • The wizard is only for creating dial up VPN connection tunnels.
  • The remote users need one of the following:
    • FortiClient software (version 5)
    • The Cisco client that is included in the Apple iOS software.

Creating Policies

While the wizard does simplify tunnel configuration, such as building both phases 1 and 2 of the tunnel, it does not do everything. For example, policies still have to be created so the tunnel can pass data back and forth.

Requirements

When using the wizard, there are a few pieces of information that you are going to want at your fingertips, or have configured before starting the wizard.

  • Know the type of VPN clients are your remote users using.
  • If you are using a certificate for authentication, it needs to be installed.
  • The User Group that your users belong to. You can create one within the wizard, but it is preferable to take the time to configure it properly before starting the wizard so that there are fewer chances of making mistakes.
  • The interface/port to which users will connect.
  • Your company’s security policy on allowing split tunnel connections to your internal network.

Tour of the VPN Creation Wizard

Section 1 – VPN Setup

Name

Every VPN tunnel needs a unique name that policies can use as a reference.  After the tunnel has been completed this name will show up in the drop down menu that lists all of the Interfaces on the FortiGate. The normal best practices approach applies here.

  • Don’t make the name too long. The field is limited to 15 characters.
  • Don’t include spaces in the name.

VPN Type

  • Dial Up – FortiClient Windows, Mac, and Android

Use this option when the remote users will be connecting with the FortiClient software that is installed on their device.

  • Dial Up – iPhone / iPad Native IPsec Client

Use this option when the remote users will be connecting with the VPN client that is designed by Cisco. While the setting specifically mentions iOS devices, the Cisco VPN client on a Mac also works.

Section 2 – Authentication

Authentication Method

Pre-shared Key

If the Pre-Shared Key option is chosen, the next field will be called Pre-Shared Key. In this case, you could think of it in the same way as a password. It can be a word, a phrase, or even random characters. Just don’t make it easy to guess.

RSA Signature

If the RSA Signature option is chosen, the next field will be called Certificate Name. A certificate is more secure than a Pre-Shared Key, but more effort to configure.

User Group

This user group refers to the group to which  the users logging into the VPN belong. Each tunnel can only be assigned one user group, so if the users are currently spread across multiple groups or are not part of any group, the options are either to create a group that consists of all the users accessing a single tunnel or to create a tunnel for each of the groups. Remember that everyone in the group will have the credentials to access the tunnel.

Section 3 – Network

Local Outgoing Interface

This will be the interface port on your FortiGate with which you want to associate this tunnel. For instance, if the remote user wants to use the Public IP address used on your WAN port when they are connecting, then that is the interface that gets assigned here.

Address Range

The address range is a pool of IP addresses that will be assigned to any device connecting to the VPN. This range does not have to be a proper subnet range and it can stop and start at any point. For example both 192.168.1.1 – 192.168.1.255 or 192.168.1.3 – 192.168.1.17 would be valid ranges.

These addresses are not assigned to the visiting computers in the way that a DHCP server assigns addresses. These addresses are what the NATed addresses will be. The reason for NATing is that most connections will be from private networks and it is common for people to use standard private IP address ranges. If the remote computer is on a 192.168.1.0 subnet and your network uses the same address range on one of its networks, then the routing could become confusing. Avoid this confusion by assigning remote computers to an address range that you know isn’t part of your existing internal network.

Subnet Mask

The subnet mask is for the addresses that are being assigned to the remote devices. By having a subnet, the device knows when it needs to go to a gateway to reach an address.

DNS Server

Use System DNS

The remote device can be assigned the same DNS server that the FortiGate uses.

Specify

The remote device can be assigned a specific DNS server, by IP address. The requirement is that the address be reachable by the computer while connected to the tunnel. If split tunneling is not enabled and the IP address is not reachable from the FortiGate the DNS server will be useless.

Enable IPv4 Split Tunnel

Split tunneling allows the remote computer to use both the VPN connection to the networks controlled by the FortiGate (provided it is allowed by policy) and networks allowed by its regular network connections. If split tunneling were not allowed, all network traffic would have to go through the VPN tunnel.
[Default setting: enabled]

Accessible Networks

This option defines which addresses the remote computer can access through the FortiGate. The drop down menu lists addresses that have been defined in the FortiGate’s Addresses section. When split tunneling is enabled, this can be used to restrict the access to only those network addresses in your network that you want the remote users to access. If split tunneling is disabled, because all of the remote users’ traffic goes through the FortiGate, you could also control which sites on the Internet the remote user can access.

Allow Endpoint Registration

When enabled, this setting makes the FortiGate unit send a request to the FortiClient on the remote computer. The FortiGate unit must receive the correct registration key as a response before it can establish the tunnel. To enable and set the registration key on the FortiGate unit go to System > Config > Advanced.
[Default setting: enabled]

Section 4 – Client Options

The Client Options window only shows up when the FortiClient variation of the Dial up tunnel has been chosen. If the iPhone / iPad version is chosen, only the first three windows of the wizard are available. Because the software at both ends of the connection are written by Fortinet, more detailed information can be communicated back and forth. This gives the administrator more control over the various aspects of the network including those temporary remote nodes that are created when a VPN connection is created. When properly applied, more control can mean more security.

The common factors for all three of these settings are increased convenience for the user and potential security vulnerability. If the computer falls into the control of someone other than its intended user it takes little or no effort to establish a connection.

Save Password

When enabled, this setting allows the FortiClient software on the remote computer to store the password for the user so that it doesn’t have to be typed in each time a connection is made.
[Default setting: disabled]

Auto Connect

When enabled, this setting allows the FortiClient software on the remote computer to be configured so that whenever the FortiClient software is running it will attempt to connect to the VPN tunnel.
[Default setting: disabled]

Always Up (Keep Alive)

When enabled, this setting allows FortiClient software on the remote computer to keep the connection from timing out due to inactivity.
[Default setting: disabled]

The post Behind the scenes of the VPN Creation Wizard appeared first on Fortinet Cookbook.

Site-to-site IPsec VPN with Overlapping Subnets (Video)

$
0
0

In this video, you will learn how to construct a site-to-site IPsec VPN connection between two networks with overlapping subnets. Without the proper configuration, connecting two networks with overlapping subnets can lead to IP conflicts and traffic errors. With the proper configuration, the FortiGate will direct traffic to the correct address on the correct network, using Virtual IP addresses and static routes.

The recipe for this video is available here.

Watch more videos

The post Site-to-site IPsec VPN with Overlapping Subnets (Video) appeared first on Fortinet Cookbook.


IPsec VPN with Native OS X Client (Video)

$
0
0

In this video, you will learn how to set up IPsec VPN between a FortiGate and a MAC using the default MAC client.

This VPN configuration allows Mac users to securely access an internal network, and browse the Internet through the VPN tunnel. This configuration uses a pre-shared key but other authentication options are also supported. This video assumes that you have already created a user group called “mac_ users” and an Internal firewall address. You should also define the IP range for mac users and ensure that no other interfaces on the FortiGate use this range to avoid subnet overlaps.

We are using OS X Yosemite version 10.10.2.

The recipe for this video is available here.

Watch more videos

The post IPsec VPN with Native OS X Client (Video) appeared first on Fortinet Cookbook.

What’s New In FortiOS 5.4 (Video)

$
0
0

Hello! This is FortiOS Version 5.4. We’ve been working hard to get this new version ready, and this video will run you through some of the features and updates you can expect: a new interface, new tools for keeping an eye on your network, new features to protect against new threats, and thousands of updates and tweaks to make managing your firewall easier.

Watch more videos

The post What’s New In FortiOS 5.4 (Video) appeared first on Fortinet Cookbook.

IPsec VPN with FortiClient

$
0
0

In this example, you will allow remote users to access the corporate network using an IPsec VPN that they connect to using FortiClient for Mac OS X, Windows, or Android. Traffic to the Internet will also flow through the FortiGate, to apply security scanning.

In this example, FortiClient 5.4.0.493 for Mac OS X is used.

Watch the video

1. Creating a user group for remote users

Go to User & Device > User Definition. Create a local user account for an IPsec VPN user.

 
   
   
   
Go to User & Device > User Groups. Create a user group for IPsec VPN users and add the new user account.  

2. Adding a firewall address for the local network

Go to Policy & Objects > Addresses and create an address for the local network.

Set Type to IP/NetmaskSubnet/IP Range to the local subnet, and Interface to an internal port.

 

3. Configuring the IPsec VPN using the IPsec VPN Wizard

Go to VPN > IPsec Wizard and create a new tunnel using a pre-existing template.

Name the VPN connection. Set Template to Remote Access, and set Remote Device Type to FortiClient VPN for OS X, Windows, and Android.

 

Set the Incoming Interface to the internet-facing interface and Authentication Method to Pre-shared Key.

Enter a pre-shared key and select the new user group, then click Next.

 

Set Local Interface to an internal interface (in the example, lan) and set Local Address to the local LAN address.

Enter an Client Address Range for VPN users.

Make sure Enable IPv4 Split Tunnel is not selected, so that all Internet traffic will go through the FortiGate.

 

Select Client Options as desired.

 

After you create the tunnel, a summary page appears listing the objects which have been added to the FortiGate’s configuration by the wizard.

 

4. Creating a security policy for access to the Internet

The IPsec wizard automatically created a security policy allowing IPsec VPN users to access the internal network. However, since split tunneling is disabled, another policy must be created to allow users to access the Internet through the FortiGate.

Go to Policy & Objects > IPv4 Policies and create a new policy. Set a policy name that will identify what this policy is used for (in the example, IPsec-VPN-Internet)

Set Incoming Interface to the tunnel interface and Outgoing Interface to wan1. Set Source to the IPsec client address range, Destination Address to all, Service to ALL, and enable NAT.

Configure any remaining firewall and security options as desired.

 

5. Configuring FortiClient

Open FortiClient, go to Remote Access and Add a new connection.

 

Set the Type to IPsec VPN and Remote Gateway to the FortiGate IP address.

Set Authentication Method to Pre-Shared Key and enter the key below.

 

6. Results

On FortiClient, select the VPN, enter the username and password, and select Connect.

 

Once the connection is established, the FortiGate assigns the user an IP address and FortiClient displays the status of the connection, including the IP address, connection duration, and
bytes sent and received.

 

On the FortiGate unit, go to Monitor > IPsec Monitor and verify that the tunnel Status is Up.

Under Remote Gateway, the monitor shows the FortiClient user’s assigned gateway IP address.

 

Browse the Internet, then go to FortiView > Policies and select the now view. You can see traffic flowing through the IPsec-VPN-Internet policy.


 

Right-click on the policy, then select Drill Down to Details. You can see more information about the traffic.

Under Source, you can also see the IP address assigned to the FortiClient user (10.10.100.1).

 

Go to FortiView > VPN to see which users have connected to the VPN.

 

The tunnel name may not have any spaces in it and should not exceed 13 characters.
The pre-shared key is a credential for the VPN and should differ from the user’s password.
The IP range you enter here prompts FortiOS to create a new firewall object for the VPN tunnel using the name of your tunnel followed by the _range suffix (in the example, IPsec-FCT_range).
If you do select Enable Split Tunneling, traffic not intended for the corporate network will not flow through the FortiGate or be subject to the corporate security profiles.

The post IPsec VPN with FortiClient appeared first on Fortinet Cookbook.

Configuring ADVPN in FortiOS 5.4 (Expert)

$
0
0

In this recipe, we will explore a new VPN feature introduced in FortiOS 5.4.0: ADVPN.

ADVPN (Auto Discovery VPN) is an IPsec technology based on an IETF RFC draft (https://tools.ietf.org/html/draft-sathyanarayan-ipsecme-advpn-03). In simple terms, ADVPN allows a traditional hub and spoke VPN’s spokes to establish dynamic, on-demand direct tunnels between each other so as to avoid routing through the topology’s hub device. ADVPN requires the use of dynamic routing in order to function and FortiOS 5.4 supports both BGP and RIP. This recipe will focus on using BGP and its route-reflector mechanism as the dynamic routing solution to use with ADVPN.

ADVPN’s primary advantages is that it provides the full meshing capabilities to a standard hub and spoke topology, greatly reducing the provisioning effort required for full spoke to spoke low delay reachability and addressing the scalability issues associated with very large fully meshed VPN networks.

BGP (and specifically, iBGP) is a natural fit for ADVPN as its route reflector mechanism resides on the VPN hub device and mirrors routing information from each spoke peer to each other. Furthermore, dynamic group peers result in near zero-touch hub provisioning when a new spoke is introduced in the topology.

As pictured, while the static configuration will involve both spoke FortiGate units to connect to our circular hub FortiGate, Spoke A will be able to establish a dynamic on-demand shortcut IPSec tunnel to Spoke B (and vice versa) if a host behind either spoke attempts to reach a host behind the other spoke. We will complete the configuration below and our verification step below will include reachability from 192.168.2.1 (spoke A) to 192.168.3.1 (spoke B) over the dynamically created shortcut link.

This recipe is documented in CLI as configuration such as BGP and ADVPN are best done using the command line interface. We are assuming basic IP and default routing configuration has been completed on the devices.

1. Configure the Hub FortiGate

 

Using the CLI, configure phase 1 parameters.

The auto-discovery commands enable the sending and receiving of shortcut messages to spokes (the hub is responsible for lettings the spokes know that they should establish those tunnels).

Note: aggressive mode is not supported currently for ADVPN.

config vpn ipsec phase1-interface
    edit "ADVPN"
        set type dynamic
        set interface "wan1"
        set proposal aes128-sha1
        set add-route disable
        set dhgrp 2
        set auto-discovery-sender enable
        set psksecret fortinet
    next
end

Configure the phase2 parameters.

This is a standard phase 2 configuration.

config vpn ipsec phase2-interface
    edit "ADVPN-P2"
        set phase1name "ADVPN"
        set proposal aes128-sha1
    next
end

Configure the tunnel interface IP.

ADVPN requires that tunnel IPs be configured on each device connecting to the topology. Those IP addresses need to be unique for each peer. A particularity of the hub is that it needs to define a bogus remote-IP address (10.10.10.254 in our example). This address should be unused in the topology and it will not be actually considered as part of the configuration for the hub.

 
config system interface
    edit "ADVPN"
        set vdom "root"
        set ip 10.10.10.1 255.255.255.255
        set type tunnel
        set remote-ip 10.10.10.254
        set interface "wan1"
    next
end

 Configure iBGP and route-reflection.

iBGP will be our overlay protocol of choice for enabling ADVPN communications. We are using an arbitrary private AS number (65000) in our example, and configuring a dynamic client group to reduce provisioning requirements.

While we are advertising our LAN network directly (“config network” command), route redistribution is a perfectly valid alternative.

config router bgp
    set as 65000
    set router-id 10.10.10.1
    config neighbor-group
        edit "ADVPN-PEERS"
            set remote-as 65000
            set route-reflector-client enable
        next
    end
    config neighbor-range
        edit 1
            set prefix 10.10.10.0 255.255.255.0
            set neighbor-group "ADVPN-PEERS"
        next
    end
    config network
        edit 1
            set prefix 192.168.1.0 255.255.255.0
        next
    end
end

Configure basic policies to allow traffic to flow between the local network and the ADVPN VPN topology. As we generally desire traffic to be allowed between spokes in an ADVPN setup, we must remember to create a policy allowing spoke to spoke communications.

 
config firewall policy
    edit 0
        set name "OUT ADVPN"
        set srcintf "lan"
        set dstintf "ADVPN"
        set srcaddr "all"
        set dstaddr "all"
        set action accept
        set schedule "always"
        set service "ALL"
        set status enable
    next
    edit 0
        set name "IN ADVPN"
        set srcintf "ADVPN"
        set dstintf "lan"
        set srcaddr "all"
        set dstaddr "all"
        set action accept
        set schedule "always"
        set service "ALL"
        set status enable
    next
    edit 0
        set name "ADVPNtoADVPN"
        set srcintf "ADVPN"
        set dstintf "ADVPN"
        set srcaddr "all"
        set dstaddr "all"
        set action accept
        set schedule "always"
        set service "ALL"
        set status enable
    next
end

2. Configure the Spoke FortiGates

Using the CLI, configure phase 1 parameters.

Note that we are configuring only one of the spokes in this example – the parameters that need to change for each spoke are highlighted in red.

config vpn ipsec phase1-interface
 edit "ADVPN"
  set interface "wan1"
  set proposal aes128-sha1
  set add-route disable
  set dhgrp 2
  set auto-discovery-receiver enable
  set remote-gw 10.1.1.1
  set psksecret fortinet
 next
end

Configure the phase2 parameters.

config vpn ipsec phase2-interface
    edit "ADVPN-P2"
        set phase1name "ADVPN"
        set proposal aes128-sha1
	set auto-negotiate enable
    next
end

 

 Configure the tunnel interface IP.

Notice that on the spokes, the remote IP is actually used and points to the IP defined on the hub.

config system interface
    edit "ADVPN"
        set vdom "root"
        set ip 10.10.10.2 255.255.255.255
        set type tunnel
        set remote-ip 10.10.10.1
        set interface "wan1"
    next
end

Config iBGP.

This is a static standard configuration and as stated for the hub, redistribution could be used instead of explicit route advertisement.

config router bgp
    set as 65000
    set router-id 10.10.10.2
    config neighbor
        edit "10.10.10.1"
            set soft-reconfiguration enable
            set remote-as 65000
        next
    end
    config network
        edit 1
            set prefix 192.168.2.0 255.255.255.0
        next
    end
end

Configure a static route for the tunnel IP subnet.

This is an important special step for the spokes as they need a summary route that identifies all tunnel IP used over your topology to point towards the ADVPN interface. In our example, we use 10.10.10.0/24 (if our network planning expects less than 255 sites). Be sure to adequately plan this IP range as it needs to be hardcoded in the spokes.

config router static
    edit 3
        set dst 10.10.10.0 255.255.255.0
        set device "ADVPN"
    next
end

Configure policies.

config firewall policy
    edit 0
        set name "OUT ADVPN"
        set srcintf "lan"
        set dstintf "ADVPN"
        set srcaddr "all"
        set dstaddr "all"
        set action accept
        set schedule "always"
        set service "ALL"
        set status enable
    next
    edit 0
        set name "IN ADVPN"
        set srcintf "ADVPN"
        set dstintf "lan"
        set srcaddr "all"
        set dstaddr "all"
        set action accept
        set schedule "always"
        set service "ALL"
        set status enable
    next
end

Results

 

We can validate the behaviour of our configuration using a few commands. We are going to run these commands from SPOKE A.

get router info routing-table bgp will at a minimum display the learned routes from the topology. Note the recursive routing – a result of our spoke’s required static route. In this case, there has not been any traffic between our local subnet (192.168.2.0/24) and the other spoke’s subnet, as the routes are both going through the hub.

B       192.168.1.0/24 [200/0] via 10.0.0.1, ADVPN, 22:30:21
B       192.168.3.0/24 [200/0] via 10.0.0.3 (recursive via 10.0.0.1), 22:30:21

 

However once we initiate a ping between both spokes, we obtain a different display of routing information – routing now goes through a newly established dynamic tunnel directly through the remote spoke rather than through the hub. The ping hiccup that occurs is the tunnel rerouting through a newly negotiated tunnel to the other spoke.

Our routing information now displays the remote subnet as being available through the spoke directly, through interface ADVPN_0, a dynamically instantiated interface going to that spoke.

FG # exec ping-options source 192.168.2.1

FG # exec ping 192.168.3.1
PING 192.168.3.1 (192.168.3.1): 56 data bytes
64 bytes from 192.168.3.1: icmp_seq=0 ttl=254 time=38.3 ms
64 bytes from 192.168.3.1: icmp_seq=1 ttl=254 time=32.6 ms
Warning: Got ICMP 3 (Destination Unreachable)
64 bytes from 192.168.3.1: icmp_seq=2 ttl=255 time=43.0 ms
64 bytes from 192.168.3.1: icmp_seq=3 ttl=255 time=31.7 ms
64 bytes from 192.168.3.1: icmp_seq=4 ttl=255 time=31.2 ms

--- 192.168.3.1 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max = 31.2/35.3/43.0 ms

FG # get router info routing-table bgp 

B       192.168.1.0/24 [200/0] via 10.0.0.1, ADVPN, 22:34:13
B       192.168.3.0/24 [200/0] via 10.0.0.3, ADVPN_0, 00:02:28

 

Some additional data can be obtained using the very useful diag vpn tunnel list command. We are highlighting the aspects in the output which convey data specific to ADVPN, in this case the auto-discovery flag and the child-parent relationship of new instantiated dynamic tunnel interfaces.
FG # diag vpn tunnel list
list all ipsec tunnel in vd 0
------------------------------------------------------
name=ADVPN_0 ver=1 serial=a 10.1.1.2:0->10.1.1.3:0
bound_if=6 lgwy=static/1 tun=intf/0 mode=dial_inst/3 encap=none/0
 parent=ADVPN index=0
proxyid_num=1 child_num=0 refcnt=19 ilast=3 olast=604 auto-discovery=2
stat: rxp=7 txp=7 rxb=1064 txb=588
dpd: mode=on-demand on=1 idle=20000ms retry=3 count=0 seqno=0
natt: mode=none draft=0 interval=0 remote_port=0
proxyid=ADVPN-P2 proto=0 sa=1 ref=2 serial=1 auto-negotiate adr
  src: 0:0.0.0.0/0.0.0.0:0
  dst: 0:0.0.0.0/0.0.0.0:0
  SA: ref=3 options=2f type=00 soft=0 mtu=1438 expire=42680/0B replaywin=2048 seqno=8 esn=0
  life: type=01 bytes=0/0 timeout=43152/43200
  dec: spi=9a487db3 esp=aes key=16 55e53d9fbc8dbeaa6df1032fbc80c4f6
       ah=sha1 key=20 a1470452c6a444f26a070add087f0d970c18e3a7
  enc: spi=3c37fea7 esp=aes key=16 8fd62a6745a9ba4fda062d4504b76851
       ah=sha1 key=20 44c606f1ef1bf5739ba62f6572031aa956974d0a
  dec:pkts/bytes=7/588, enc:pkts/bytes=7/1064
------------------------------------------------------
name=ADVPN ver=1 serial=9 10.1.1.2:0->10.1.1.1:0
bound_if=6 lgwy=static/1 tun=intf/0 mode=auto/1 encap=none/0
proxyid_num=1 child_num=1 refcnt=22 ilast=8 olast=8 auto-discovery=2
stat: rxp=3120 txp=3120 rxb=399536 txb=191970
dpd: mode=on-demand on=1 idle=20000ms retry=3 count=0 seqno=12
natt: mode=none draft=0 interval=0 remote_port=0
proxyid=ADVPN-P2 proto=0 sa=1 ref=2 serial=1 auto-negotiate adr
  src: 0:0.0.0.0/0.0.0.0:0
  dst: 0:0.0.0.0/0.0.0.0:0
  SA: ref=3 options=2f type=00 soft=0 mtu=1438 expire=4833/0B replaywin=2048 seqno=5ba esn=0
  life: type=01 bytes=0/0 timeout=43148/43200
  dec: spi=9a487db2 esp=aes key=16 4f70d27edad656cfcacbae61b23d4b11
       ah=sha1 key=20 b19ea87c90dd92d1cab58cbf24ae8fe12ee927cb
  enc: spi=b3dde355 esp=aes key=16 efbb4440df75018610b4ba8f5756167d
       ah=sha1 key=20 81cc9cee3bee1c2dba0eb1e7ac66e9d34b67bde9
  dec:pkts/bytes=1465/90152, enc:pkts/bytes=1465/187560
------------------------------------------------------




 

 

The post Configuring ADVPN in FortiOS 5.4 (Expert) appeared first on Fortinet Cookbook.

Site-to-site IPsec VPN with two FortiGates

$
0
0

In this example, you will allow transparent communication between two networks that are located behind different FortiGates at different offices using route-based IPsec VPN. The VPN will be created on both FortiGates by using the VPN Wizard’s Site to Site – FortiGate template.

In this example, one office will be referred to as HQ and the other will be referred to as Branch.

Find this recipe for other FortiOS versions
5.2 | 5.4

1. Configuring the HQ IPsec VPN

On the HQ FortiGate, go to VPN > IPsec Wizard.

Select the Site to Site template, and select FortiGate.

In the Authentication step, set IP Address to the IP of the Branch FortiGate (in the example, 172.20.120.135). After you enter the gateway, an available interface will be assigned as the Outgoing Interface. If you wish to use a different interface, select it from the drop-down menu.

Set a secure Pre-shared Key.

In the Policy & Routing step, set the Local Interface. The Local Subnets will be added automatically. Set Remote Subnets to the Branch FortiGate’s local subnet (in the example, 5.5.5.5/24).

A summary page shows the configuration created by the wizard, including firewall addresses, firewall address groups, a static route, and security policies.

2. Configuring the Branch IPsec VPN

On the Branch FortiGate, go to VPN > IPsec Wizard.

Select the Site to Site template, and select FortiGate.

In the Authentication step, set IP Address to the IP of the HQ FortiGate (in the example, 172.20.121.92). After you enter the gateway, an available interface will be assigned as the Outgoing Interface. If you wish to use a different interface, select Change.

Set the same Pre-shared Key that was used for HQ’s VPN.

In the Policy & Routing step, set the Local Interface. The Local Subnets will be added automatically. Set Remote Subnets to the HQ FortiGate’s local subnet (in the example, 10.10.10.1/24).

A summary page shows the configuration created by the wizard, including firewall addresses, firewall address groups, a static route, and security policies.

3. Results

On either FortiGate, go to Monitor > IPsec Monitor to verify the status of the VPN tunnel. Right-click under Status and select Bring Up.

 

A user on either of the office networks should be able to connect to any address on the other office network transparently.

If you need to generate traffic to test the connection, ping the Branch FortiGate’s internal interface from the HQ’s internal network.

The post Site-to-site IPsec VPN with two FortiGates appeared first on Fortinet Cookbook.

IPsec VPN troubleshooting

$
0
0

This section contains tips to help you with some common challenges of IPsec VPNs.

A VPN connection has multiple stages that can be confirmed to ensure the connection is working properly. It is easiest to see if the final stage is successful first since if it is successful the other stages will be working properly. Otherwise, you will need to work back through the stages to see where the problem is located.

When a VPN connection is properly established, traffic will flow from one end to the other as if both ends were physically in the same place. If you can determine the connection is working properly then any problems are likely problems with your applications.

On some FortiGate units, such as the FortiGate 94D, you cannot ping over the IPsec tunnel without first setting a source-IP. In this scenario, you must assign an IP address to the virtual IPSEC VPN interface. Anything sourced from the FortiGate going over the VPN will use this IP address.

If the egress/outgoing interface (determined by kernel route) has an IP address, then use the IP address of the egress/outgoing interface. Otherwise, use the IP address of the first interface from the interface list (that has an IP address).

The first diagnostic command worth running, in any IPsec VPN troubleshooting situation, is the following:

diagnose vpn tunnel list

This command is very useful for gathering statistical data such as the number of packets encrypted versus decrypted, the number of bytes sent versus received, the SPI identifier, etc. This kind of information in the resulting output can make all the difference in determining the issue with the VPN.

Another appropriate diagnostic command worth trying is:

diagnose debug flow

This command will inform you of any lack of firewall policy, lack of forwarding route, and of policy ordering issues.

The following is a list of such potential issues. Bear in mind that the troubleshooting suggestions below are not exhaustive, and may not reflect your network topology.

 

The options to configure policy-based IPsec VPN are unavailable.

Go to System > Feature Select. Select Show More and turn on Policy-based IPsec VPN.

If your VPN fails to connect, check the following:

  • Ensure that the pre-shared keys match exactly (see The pre-shared key does not match (PSK mismatch error) below).
  • Ensure that both ends use the same P1 and P2 proposal settings (see The SA proposals do not match (SA proposal mismatch) below).
  • Ensure that you have allowed inbound and outbound traffic for all necessary network services, especially if services such as DNS or DHCP are having problems.
  • Check that a static route has been configured properly to allow routing of VPN traffic.
  • Ensure that your FortiGate unit is in NAT/Route mode, rather than Transparent.
  • Check your NAT settings, enabling NAT traversal in the Phase 1 configuration while disabling NAT in the security policy. You might need to pin the PAT/NAT session table, or use some of kind of NAT-T keepalive to avoid the expiration of your PAT/NAT translation.
  • Ensure that both ends of the VPN tunnel are using Main mode, unless multiple dial-up tunnels are being used.
  • If you have multiple dial-up IPsec VPNs, ensure that the Peer ID is configured properly on the
  • FortiGate and that clients have specified the correct Local ID.
  • If you are using FortiClient, ensure that your version is compatible with the FortiGate firmware by reading the FortiOS Release Notes.
  • If you are using Perfect Forward Secrecy (PFS), ensure that it is used on both peers. You can use the diagnose vpn tunnel list command to troubleshoot this.
  • Ensure that the Quick Mode selectors are correctly configured. If part of the setup currently uses firewall addresses or address groups, try changing it to either specify the IP addresses or use an expanded address range. This is especially useful if the remote endpoint is not a FortiGate device.
  • If XAUTH is enabled, ensure that the settings are the same for both ends, and that the FortiGate unit is set to Enable as Server.
  • Check IPsec VPN Maximum Transmission Unit (MTU) size. A 1500 byte MTU is going to exceed the overhead of the ESP-header, including the additional ip_header,etc. You can use the diagnose vpn tunnel list command to troubleshoot this.
  • If your FortiGate unit is behind a NAT device, such as a router, configure port forwarding for UDP ports 500 and 4500.
  • Remove any Phase 1 or Phase 2 configurations that are not in use. If a duplicate instance of the VPN tunnel appears on the IPsec Monitor, reboot your FortiGate unit to try and clear the entry.

If you are still unable to connect to the VPN tunnel, run the following diagnostic command in the CLI:

diagnose debug application ike -1
diagnose debug enable

The resulting output may indicate where the problem is occurring. When you are finished, disable the diagnostics by using the following command:

diagnose debug reset
diagnose debug disable

The VPN tunnel goes down frequently.

If your VPN tunnel goes down often, check the Phase 2 settings and either increase the Keylife value or enable Autokey Keep Alive.

The pre-shared key does not match (PSK mismatch error).

It is possible to identify a PSK mismatch using the following combination of CLI commands:

diag vpn ike log filter name <phase1-name> 
diag debug app ike -1
diag debug enable

This will provide you with clues as to any PSK or other proposal issues. If it is a PSK mismatch, you should see something similar to the following output:

ike 0:TRX:322: PSK auth failed: probable pre-shared key mismatch
ike Negotiate SA Error:

The SA proposals do not match (SA proposal mismatch).

The most common problem with IPsec VPN tunnels is a mismatch between the proposals offered between each party. Without a match and proposal agreement, Phase 1 can never establish. Use the following command to show the proposals presented by both parties.

diag debug app ike -1
diag debug enable

The resulting output should include something similar to the following, where blue represents the remote VPN device, and green represents the local FortiGate.

responder received SA_INIT msg
incoming proposal:
proposal id = 1:
   protocol = IKEv2:
      encapsulation = IKEv2/none
      type=ENCR, val=AES_CBC (key_len = 256)
      type=INTEGR, val=AUTH_HMAC_SHA_96
      type=PRF, val=PRF_HMAC_SHA
      type=DH_GROUP, val=1536.
proposal id = 2:
   protocol = IKEv2:
      encapsulation = IKEv2/none
      type=ENCR, val=3DES_CBC
      type=INTEGR, val=AUTH_HMAC_SHA_2_256_128
      type=PRF, val=PRF_HMAC_SHA2_256
      type=DH_GROUP, val=1536.
proposal id = 1:
   protocol = IKEv2:
      encapsulation = IKEv2/none
      type=ENCR, val=AES_CBC (key_len = 128)
      type=INTEGR, val=AUTH_HMAC_SHA_96
      type=PRF, val=PRF_HMAC_SHA
      type=DH_GROUP, val=1536.

Pre-existing IPsec VPN tunnels need to be cleared.

Should you need to clear an IKE gateway, use the following commands:

diagnose vpn ike restart
diagnose vpn ike gateway clear

LAN interface connection

To confirm whether a VPN connection over LAN interfaces has been configured correctly, issue a ping or traceroute command on the network behind the FortiGate unit to test the connection to a computer on the remote network. If the connection is properly configured, a VPN tunnel will be established automatically when the first data packet destined for the remote network is intercepted by the FortiGate unit.

If the ping or traceroute fail, it indicates a connection problem between the two ends of the tunnel. This may or may not indicate problems with the VPN tunnel. You can confirm this by going to Monitor > IPsec Monitor where you will be able to see your connection. A green arrow means the tunnel is up and currently processing traffic. A red arrow means the tunnel is not processing traffic, and this VPN connection has a problem.

Dialup connection

A dialup VPN connection has additional steps. To confirm that a VPN between a local network and a dialup client has been configured correctly, at the dialup client, issue a ping command to test the connection to the local network. The VPN tunnel initializes when the dialup client attempts to connect.

If the ping or traceroute fail, it indicates a connection problem between the two ends of the tunnel. This may or may not indicate problems with the VPN tunnel, or dialup client. As with the LAN connection, confirm the VPN tunnel is established by checking Monitor > IPsec Monitor.

Troubleshooting VPN connections

If you have determined that your VPN connection is not working properly through troubleshooting, the next step is to verify that you have a Phase2 connection.

If traffic is not passing through the FortiGate unit as you expect, ensure the traffic does not contain IPcomp packets (IP protocol 108, RFC 3173). FortiGate units do not allow IPcomp packets, they compress packet payload, preventing it from being scanned.

Testing Phase 1 and 2 connections is a bit more difficult than testing the working VPN. This is because they require diagnose CLI commands. These commands are typically used by Fortinet customer support to discover more information about your FortiGate unit and its current configuration.

Before you begin troubleshooting, you must:

  • Configure FortiGate units on both ends for interface VPN
  • Record the information in your VPN Phase 1 and Phase 2 configurations – for our example here the remote IP address is 10.11.101.10 and the names of the phases are Phase 1 and Phase 2
  • Install a telnet or SSH client such as putty that allows logging of output
  • Ensure that the admin interface supports your chosen connection protocol so you can connect to your FortiGate unit admin interface.

For this example, default values were used unless stated otherwise.

To get diagnose information for the VPN connection – CLI

  1. Log into the CLI as admin with the output being logged to a file.
  2. Stop any diagnose debug sessions that are currently running with the CLI command
diagnose debug disable
  1. Clear any existing log-filters by running
diagnose vpn ike log-filter clear
  1. Set the log-filter to the IP address of the remote computer (10.11.101.10). This filters out all VPN connections except ones to the IP address we are concerned with. The command is
diagnose vpn ike log-filter dst-addr4 10.11.101.10.
  1. Set up the commands to output the VPN handshaking. The commands are:
diagnose debug app ike 255
diagnose debug enable
  1. Have the remote FortiGate initiate the VPN connection in the web-based manager by going to VPN > IPsec Tunnels and selecting Bring up.
    This makes the remote FortiGate the initiator and the local FortiGate becomes the responder. Establishing the connection in this manner means the local FortiGate will have its configuration information as well as the information the remote computer sends. Having both sets of information locally makes it easier to troubleshoot your VPN connection.
  1. Watch the screen for output, and after roughly 15 seconds enter the following CLI command to stop the output.
diagnose debug disable
  1. If needed, save the log file of this output to a file on your local computer. Saving the output to a file can make it easier to search for a particular phrase, and is useful for comparisons.

To troubleshoot a phase1 VPN connection

Using the output from To get diagnose information for the VPN connection – CLI, search for the word proposal in the output. It may occur once indicating a successful connection, or it will occur two or more times for an unsuccessful connection — there will be one proposal listed for each end of the tunnel and each possible combination in their settings. For example if 10.11.101.10 selected both Diffie-Hellman Groups 1 and 5, that would be at least 2 proposals set.

A successful negotiation proposal will look similar to:

IPsec SA connect 26 10.12.101.10->10.11.101.10:500
config found
created connection: 0x2f55860 26 10.12.101.10->10.11.101.10:500
IPsec SA connect 26 10.12.101.10->10.11.101.10:500 negotiating
no suitable ISAKMP SA, queuing quick-mode request and initiating ISAKMP SA negotiation
initiator: main mode is sending 1st message...
cookie 3db6afe559e3df0f/0000000000000000
out [encryption]
sent IKE msg (ident-i1send): 10.12.101.10:500->10.11.101.10:500, len=264, id=3db6afe559e3df0f/0000000000000000
diaike 0: comes 10.12.101.1:500->10.11.101.1:500,ifindex=26....

Note the phrase “initiator: main mode is sending 1st message...” which shows you the handshake between the ends of the tunnel is in progress. Initiator shows the remote unit is sending the first message.

VPN troubleshooting tips

Attempting hardware offloading beyond SHA1

If you are trying to off-load VPN processing to a network processing unit (NPU), remember that only SHA1 authentication is supported. For high levels of authentication such as SHA256, SHA384, and SHA512 hardware offloading is not an option — all VPN processing must be done in software.

Enable/disable IPsec ASIC-offloading

Much like NPU-offload in IKE phase1 configuration, you can enable or disable the usage of ASIC hardware for IPsec Diffie-Hellman key exchange and IPsec ESP traffic. By default hardware offloading is used. For debugging purposes, sometimes it is best for all the traffic to be processed by software.

config sys global
   set ipsec-asic-offload [enable|disable]
end

Check Phase 1 proposal settings

Ensure that both sides have at least one Phase 1 proposal in common. Otherwise they will not connect. If there are many proposals in the list, this will slow down the negotiating of Phase 1. If its too slow, the connection may timeout before completing. If this happens, try removing some of the unused proposals.

NPU offloading is supported when the local gateway is a loopback interface.

Check your routing

If routing is not properly configured with an entry for the remote end of the VPN tunnel, traffic will not flow properly. You may need static routes on both ends of the tunnel. If routing is the problem, the proposal will likely setup properly but no traffic will flow.

Try enabling XAuth

If one end of an attempted VPN tunnel is using XAuth and the other end is not, the connection attempt will fail. The log messages for the attempted connection will not mention XAuth is the reason, but when connections are failing it is a good idea to ensure both ends have the same XAuth settings. If you do not know the other end’s settings enable or disable XAuth on your end to see if that is the problem.

General troubleshooting tips

Most connection failures are due to a configuration mismatch between the FortiGate unit and the remote peer. In general, begin troubleshooting an IPsec VPN connection failure as follows:

  1. Ping the remote network or client to verify whether the connection is up.
  2. Traceroute the remote network or client. If DNS is working, you can use domain names. Otherwise use IP addresses.
  3. Check the routing behind the dialup client. Routing problems may be affecting DHCP. If this appears to be the case, configure a DHCP relay service to enable DHCP requests to be relayed to a DHCP server on or behind the FortiGate server.
  4. Verify the configuration of the FortiGate unit and the remote peer. Check the following IPsec parameters:
  • The mode setting for ID protection (main or aggressive) on both VPN peers must be identical.
  • The authentication method (preshared keys or certificates) used by the client must be supported on the FortiGate unit and configured properly.
  • If preshared keys are being used for authentication purposes, both VPN peers must have identical preshared keys.
  • The remote client must have at least one set of Phase 1 encryption, authentication, and Diffie-Hellman settings that match corresponding settings on the FortiGate unit.
  • Both VPN peers must have the same NAT traversal setting (enabled or disabled).
  • The remote client must have at least one set of Phase 2 encryption and authentication algorithm settings that match the corresponding settings on the FortiGate unit.
  • If you are using manual keys to establish a tunnel, the Remote SPI setting on the FortiGate unit must be identical to the Local SPI setting on the remote peer, and vise versa.
  1. To correct the problem, see the following table.

VPN troubleshooting tips

Configuration problem

Correction
Mode settings do not match. Select complementary mode settings.
Peer ID or certificate name of the remote peer or dialup client is not recognized by FortiGate VPN server. Check Phase 1 configuration. Depending on the Remote Gateway and Authentication Method settings, you have a choice of options to authenticate FortiGate dialup clients or VPN peers by ID or certificate name.

If you are configuring authentication parameters for FortiClient dialup clients, refer to the Authenticating FortiClient Dialup Clients Technical Note.

Preshared keys do not match. Reenter the preshared key.
Phase 1 or Phase 2 key exchange proposals are mismatched. Make sure that both VPN peers have at least one set of proposals in common for each phase.
NAT traversal settings are mismatched. Select or clear both options as required.

A word about NAT devices

When a device with NAT capabilities is located between two VPN peers or a VPN peer and a dialup client, that device must be NAT traversal (NAT-T) compatible for encrypted traffic to pass through the NAT device.

The post IPsec VPN troubleshooting appeared first on Fortinet Cookbook.

IPsec VPN for Windows Phone 10

$
0
0

In this recipe, you will use the FortiGate IPsec VPN Wizard to set up an IPsec VPN between a FortiGate and a device running Windows Phone 10. The configuration will allow Windows Phone 10 users to securely connect to an internal network.

The IPsec VPN is a pre-shared key configuration that also requires users to authenticate with their own credentials to be able to connect to the VPN.

This recipe assumes that a user (dprince) and a user group (WinPhone_Users) have already been created on the FortiGate.

A Windows Phone 10 Lumia 930 running build 10581 was used for this configuration.

1. Configuring the IPsec VPN using the IPsec VPN Wizard

Go to VPN > IPSec Wizard.

Name the VPN connection (WinPhoneVPN).

Select the Remote Access template, select the Windows Native device type, and select Next.

Set the Incoming Interface to the Internet-facing interface (wan1).

Select the Pre-shared Key authentication method and enter a pre-shared key.

Select the WinPhone_Users user group and select Next.

Set Local Interface to the internal interface and set Local Address to all.

Enter an IP address range for VPN users in the Client Address Range field, enter a Subnet Mask, and select Create.

Make sure no other interfaces on the FortiGate are using the same address range.

A summary page shows the wizard’s configuration.

Go to Policy & Objects > IPv4 Policy and confirm that the wizard has created two policies: one policy for remote users to access the VPN, and one policy that has Service set to L2TP.

2. Connecting to the IPsec VPN from the Windows Phone 10

On the Windows Phone 10, go to Settings > Network & wireless > VPN and select Add a VPN connection.

Enter a Connection name and set the Server name or address to the FortiGate’s Internet-facing interface.

Set VPN type to Automatic and enter the pre-shared key — this key is the same one you added to the FortiGate.

Select Save.

3. Results

You will now connect to the IPsec VPN tunnel. From the VPN screen, select TheOffice.

Sign in and connect using dprince‘s credentials.

You should now be connected to the IPsec VPN.

To verify the connection, on the FortiGate, go to Log & Report > VPN Events.
You may also verify the user’s connection by going to FortiView > VPN.

The post IPsec VPN for Windows Phone 10 appeared first on Fortinet Cookbook.


IPsec VPN two-factor authentication with FortiToken-200

$
0
0

In this recipe, you will configure two-factor authentication using a FortiToken-200 for IPsec VPN connections.

This recipe assumes that you have already created a user (elainemarley) and a user group (FTK-users). You will add a FortiToken-200 to the FortiGate, assign the token to the user, and add the user to the group. You will then use the Wizard to create an IPsec VPN tunnel that allows FortiToken-200 users to securely access an internal network and the Internet. You will test the setup by having the user access the VPN from a remote device, using FortiClient.

Watch the video

1. Adding the FortiToken

Go to User & Device > FortiTokens and create a new FortiToken.

Set Type to Hard Token and enter the FortiToken’s Serial Number into the field provided.

2. Editing the user and assigning the FortiToken

Go to User & Device > User Definition and edit elainemarley.

Select Enable Two-factor Authentication and select the token.

Select Add this user to groups and add the user to FTK-users.

3. Configuring the IPsec VPN using the IPsec VPN Wizard

Go to VPN > IPSec Wizard and create a new IPsec VPN tunnel.

Name the VPN connection (in the example, FTKVPN).

Select the Remote Access template, set Remote Device Type to FortiClient VPN for OS X, Windows, and Android, and select Next.

 
Set the Incoming Interface to the Internet-facing interface (wan1).

Set Authentication Method to Pre-shared Key and enter a pre-shared key.

Select the user group created earlier (FTK-users) and select Next.

Set Local Interface to the internal interface and set Local Address to all.

Enter an IP address range for VPN users in the Client Address Range field.Subnet Mask should already be set.

Select Next.

Configure additional Client Options and select Create.
A summary page will appear showing the VPN’s configuration.

4. Connecting to the IPsec VPN

On your remote device, open the FortiClient application, go to Remote Access, and add a new connection.

Set VPN Type to IPsec VPN, and enter a Connection Name.

Set Remote Gateway to the IP address of the FortiGate, set Authentication Method to Pre-Shared Key, and enter a Pre-Shared Key.

The key must match the same key entered in the wizard on the FortiGate earlier.

When finished, select Add.

5. Results

Go to Remote Access and attempt to log into the VPN as elainemarley.
You will then be prompted to enter a FortiToken Code. Enter the code and select OK
The user is now successfully connected to the IPsec VPN FTK-VPN.
To verify the user’s connection, go to FortiView > VPN.
You can also go to Monitor > IPsec Monitor to view the tunnel’s status, and Monitor > FortiClient Monitor to view the user and device.

 

Note that the serial number, located on the back of the FortiToken device, is case sensitive and must not be in use elsewhere.
Make sure no other interfaces on the FortiGate are using the same address range.

The post IPsec VPN two-factor authentication with FortiToken-200 appeared first on Fortinet Cookbook.

Site-to-Site IPsec VPN Between a FortiGate and a Cisco ASA

$
0
0

In this recipe, we will configure a site-to-site IPsec VPN tunnel between a FortiGate 90D and a Cisco ASA 5505.

Using FortiOS 5.2 and Cisco ASDM 7.1, the example demonstrates how to configure the tunnel on each site, assuming that both devices are configured with appropriate internal (inside) and external (outside) interfaces.

Note that this example uses the default encryption and authentication (SA proposal) settings of the Cisco ASDM IPsec VPN wizard. These are not necessarily the recommended settings.

We will use the wizards to configure each end of the tunnel as it is much quicker. However, some customization will be required on the FortiGate to ensure that its SA proposal matches the Cisco ASA for each Phase. One of the most common reasons that tunnels between FortiGates and third-party products don’t work is because of mismatched settings.

1. Configuring the Cisco ASA using the IPsec VPN Wizard

In the Cisco ASDM, under the Wizard menu, select IPsec VPN Wizard.

Select Site-to-site, with VPN Tunnel Interface set to outside, and click Next.

In the Peer IP Address field, enter the IP address of the FortiGate unit.

Under Authentication Method, enter a secure Pre-Shared Key. You will use the same key when configuring the FortiGate.

Configure Phase 1 with 3DES Encryption and SHA Authentication. Set the Diffie-Hellman Group to 2.

Configure Phase 2 with 3DES Encryption and SHA Authentication. Set the Diffie-Hellman Group to 1.

Set the Local Networks and Remote Networks.

Review the configuration before you click Finish.

If prompted, Send the CLI commands to the device.

The tunnel configuration on the Cisco ASA is complete.

Next you must configure the FortiGate with identical settings, except for the remote gateway and internal network.

2. Configuring the FortiGate using the IPsec VPN Wizard

On the FortiGate, go to VPN > IPsec > Wizard.

Enter a Name for the tunnel and select the Site to Site – Cisco template.

Set Remote Gateway to the IP address of the outside interface on the Cisco ASA. The Outgoing Interface should automatically populate.

Enter the same Pre-shared Key used in the Cisco ASA configuration.

Set Local Interface to the internal interface. The Local Subnets will automatically populate.

Set Remote Subnets to the IP address range of the inside network on the Cisco ASA and click Create.

The IPsec VPN Wizard automatically creates the required objects, policies, and static routes required for the tunnel to function properly.

3. Matching the encryption and authentication settings

On the FortiGate, go to VPN > IPsec > Tunnels, and Edit the tunnel you just created.

Select Convert to Custom Tunnel.

Under Phase 1 Proposal, configure 3DES Encryption and SHA Authentication.

Set the Diffie-Hellman Group to 2.

Under Phase 2 Proposal > Advanced, configure 3DES Encryption and SHA Authentication.

Set the Diffie-Hellman Group to 1.

When you are certain that the tunnel settings match the Cisco ASA configuration, click OK.

OPTION

SETTING
Phase 1 Encryption 3DES
Phase 1 Authentication SHA1
Phase 1 DH Group 2
Phase 2 Encryption 3DES
Phase 2 Authentication SHA1
Phase 2 DH Group 1

4. Results

On the FortiGate, go to VPN > Monitor > IPsec Monitor. Right-click on the Site to Site – Cisco VPN and select Bring Up.

From one of the internal networks, you should be able to successfully ping the other internal network.

You will be able to see Incoming and Outgoing Data in the FortiGate IPsec Monitor.

Go to Log & Report > Event Log > VPN to view the status of the tunnel negotiation.
Highlight an entry to view the status in greater detail.

5. Troubleshooting

For complete troubleshooting information, refer to IPsec VPN Troubleshooting. Below are some troubleshooting tips.

IPsec VPN troubleshooting tips

Configuration problem

Correction
Mode settings do not match. Select complementary mode settings.
Peer ID or certificate name of the remote peer or dialup client is not recognized by FortiGate VPN server. Check Phase 1 configuration. Depending on the Remote Gateway and Authentication Method settings, you have a choice of options to authenticate FortiGate dialup clients or VPN peers by ID or certificate name.

If you are configuring authentication parameters for FortiClient dialup clients, refer to the Authenticating FortiClient Dialup Clients Technical Note.

Preshared keys do not match. Reenter the preshared key.
Phase 1 or Phase 2 key exchange proposals are mismatched. Make sure that both VPN peers have at least one set of proposals in common for each phase.
NAT traversal settings are mismatched. Select or clear both options as required.

 

Note that if you change the Tunnel Group Name, Aggressive Mode will be required. Refer to the FortiOS Handbook IPsec VPN chapter for more information.

The post Site-to-Site IPsec VPN Between a FortiGate and a Cisco ASA appeared first on Fortinet Cookbook.

IPsec VPN Two-Factor Authentication with FortiToken (Video)

$
0
0

In this video, you will configure two-factor authentication using FortiToken for IPsec VPN connections. You will add a FortiToken-200 to the FortiGate, assign the token to the user, and add the user to the group. You will then use the Wizard to create an IPsec VPN tunnel that allows FortiToken-200 users to securely access an internal network and the Internet. You will test the setup by having the user access the VPN from a remote device, using FortiClient.

The recipe for this video is available here.

Watch more videos

The post IPsec VPN Two-Factor Authentication with FortiToken (Video) appeared first on Fortinet Cookbook.

IPsec VPN with FortiClient (Video)

IPsec VPN for iOS 9

$
0
0

In this recipe, you will use the FortiGate IPsec VPN Wizard to set up an IPsec VPN between a FortiGate and a device running iOS 9. This configuration allows iPhone users to securely connect to an internal network.

The IPsec VPN is a pre-shared key configuration that also requires users to authenticate with their own credentials to be able to connect to the VPN.

This recipe assumes that a user (dbuchanan) and a user group (iphone-users) have already been created on the FortiGate.

An Apple iPhone SE running iOS 9.3.4 was used for this configuration.

1. Configuring the IPsec VPN using the IPsec VPN Wizard

On the FortiGate, go to VPN > IPsec Wizard.

Name the VPN connection (iPhoneVPN).

Select the Remote Access template, select the iOS Native device type, and select Next.

Set the Incoming Interface to the Internet-facing interface (wan1).

Select the Pre-shared Key authentication method and enter a pre-shared key.

Select the iphone-users user group and select Next.

Set Local Interface to the internal interface and set Local Address to all.

Enter an IP address range for VPN users in the Client Address Range field, enter a Subnet Mask, and select Create.

Make sure no other interfaces on the FortiGate are using the same address range.

A summary page shows the wizard’s configuration, including a remote-to-local access security policy.

2. Connecting to the IPsec VPN from iPhone

On the iPhone, go to Settings > General > VPN and select Add VPN Configuration.

Set Type to IPsec and enter a Description (required).

Set Server to the FortiGate’s Internet-facing interface, and enter the user’s name in Account.

Enter the user’s password, the pre-shared IPsec VPN secret, and select Done.

 

Make sure the IPsec VPN configuration is highlighted (indicated by the  icon), and select the button next to Not Connected.

The IPsec VPN will connect with the user’s credentials and secret. The status will change to Connected, and a VPN icon will appear at the top of the screen.

3. Results

To verify the connection, on the FortiGate, go to Log & Report > VPN Events. The user has been assigned an IP from the client address range.
You may also verify the user’s connection by going to FortiView > VPN.

The post IPsec VPN for iOS 9 appeared first on Fortinet Cookbook.

Viewing all 62 articles
Browse latest View live


<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>