VPN between client and an internal network

In the following example users can connect to

the main office internal network from anywhere on

the Internet. Communication between the client and

the internal network takes place in an encrypted

VPN tunnel that connects the DFL and the roaming

users across the Internet.

The example shows a VPN between a roaming

VPN client and the internal network, but you can

also create a VPN tunnel that uses the DMZ network.

The networks at the ends of the VPN tunnel are

selected when you configure the VPN policy.

Creating a Roaming Users IPSec VPN Tunnel

Follow these steps to add a roaming users tunnel.

Step 1.

Go to Firewall and VPN and choose

Add new

in the IPSec tunnels section.

Step 2.

Enter a Name for the new tunnel in the name field. The name can contain

numbers (0-9) and upper and lower case letters (A-Z, a-z), and the special characters -

and _. No other special characters and spaces are allowed.

Step 3.

Specify your local network, or your side of the tunnel, for example

192.168.1.0/255.255.255.0, in the Local Net field. This is the network your roaming VPN

clients should be allowed to connect to.

Step 4.

Choose authentication type, either PSK (Pre-shared Key) or Certificate-based. If

you choose PSK make sure the clients use exactly the same PSK.

Step 5.

As Tunnel Type choose Roaming User.

Click the

Apply

button below to apply the change or click

Cancel

to discard changes.

62

Adding a L2TP/PPTP VPN Client

Follow these steps to add a L2TP or PPTP VPN Client configuration.

Step 1.

Go to Firewall and VPN and choose

Add new PPTP client

or

Add new L2TP

client

in the L2TP/PPTP Clients section.

Step 2.

Enter a Name for the new tunnel in the name field. The name can contain

numbers (0-9) and upper and lower case letters (A-Z, a-z), and the special characters -

and _. No other special characters and spaces are allowed.

Step 3.

Enter the username and password for the PPTP or L2TP Client.

Step 4.

Specifies if the IP should be received from the server or if one should be specified.

Should be left blank in most scenarios.

Step 5.

Specify the

Remote Gateway

; this should be the IP of the L2TP or PPTP Server

you are connecting to.

Step 6.

If you are using IPSec encryption for the L2TP or PPTP Client choose

authentication type, either PSK (Pre-shared Key) or Certificate-based.

Click the

Apply

button below to apply the change or click

Cancel

to discard changes.

Adding a L2TP/PPTP VPN Server

Follow these steps to add a L2TP or PPTP VPN Server configuration that listens on the WAN

IP.

Step 1.

Go to Firewall and VPN and choose

Add new PPTP server

or

Add new L2TP

server

in the L2TP/PPTP Server section.

Step 2.

Enter a Name for the new tunnel in the name field. The name can contain

numbers (0-9) and upper and lower case letters (A-Z, a-z), and the special characters -

and _. No other special characters and spaces are allowed.

Step 3.

Specify the

Client IP Pool

; this should be a range of unused IP’s on the LAN

interface that should be handed out to the L2TP or PPTP Clients.

Step 4.

If you are using IPSec encryption for the L2TP or PPTP Client choose

authentication type, either PSK (Pre-shared Key) or Certificate-based.

Click the

Apply

button below to apply the change or click

Cancel

to discard changes.

IPSec VPN – Advanced Settings

Advanced settings for a VPN tunnel is used when one need change some characteristics

of the tunnel when using for example trying to connect to a third party VPN Gateway.

The

different settings to set per tunnel is the following:

Limit MTU

Whit this setting it’s possible to limit the MTU (Max Transferable Unit) of the VPN tunnel.

IKE Mode

Specify if Main mode IKE or Aggressive Mode IKE should be used when establishing

outbound VPN Tunnels. Inbound main mode connections will always be allowed. Inbound

aggressive mode connections will only be allowed if this setting is set to aggressive mode.

IKE DH Group

Here it’s possible to configure the Diffie-Hellman group to 1 (modp 768-bit), 2 (modp 1024-

bit) or 5 (modp 1536-bit).

PFS – Perfect Forward Secrecy

If PFS, Perfect Forwarding Secrecy, is enabled, a new Diffie-Hellman exchange is

performed for each phase-2 negotiation. While this is slower, it makes sure that no keys are

dependent on any other previously used keys; no keys are extracted from the same initial

keying material. This is to make sure that, in the unlikely event that some key was

compromised; no subsequent keys can be derived.

NAT Traversal

Here it’s possible to configure how the NAT Traversal code should behave.

Disabled

- The firewall does not send the Vendor ID's that include NAT-T support when

setting up the tunnel.

On if supported and need NAT

- Will only use NAT-T if one of the VPN gateways is

NATed.

On if supported

- Always tries to use NAT-T when setting up the tunnel.

Keepalives

No keepalives

– Keep-alive is disabled.

Automatic keepalives

- The firewall will send ICMP pings to IP Addresses automatically

discovered from the VPN Tunnel settings.

Manually configured IP addresses

- Configure the source and destination IP addresses

used when sending the ICMP pings

64

Proposal Lists

To agree on the VPN connection parameters, a negotiation process is performed. As the

result of the negotiations, the IKE and IPSec security associations (SAs) are established. As

the name implies, a proposal is the starting point for the negotiation. A proposal defines

encryption parameters, for instance encryption algorithm, life times etc, that the VPN gateway

supports.

There are two types of proposals, IKE proposals and IPSec proposals. IKE proposals are

used during IKE Phase-1 (IKE Security Negotiation), while IPSec proposals are using during

IKE Phase-2 (IPSec Security Negotiation).

A Proposal List is used to group several proposals. During the negotiation process, the

proposals in the proposal list are offered to the remote VPN gateway one after another until a

matching proposal is found.

IKE Proposal List

Cipher

– Specifies the encryption algorithm used in this IKE proposal. Supported

algorithms are AES, 3DES, DES, Blowfish, Twofish and CAST128.

Hash

– Specifies the hash function used to calculate a check sum that reveals if the data

packet is altered while being transmitted. MD5 and SHA1 are supported algorithms.

Life Times

– Specifies in KB or seconds when the security associations for the VPN

tunnel need to be re-negotiated.

IPSec Proposal List

Cipher

– Specifies the encryption algorithm used in this IPSec proposal. Supported

algorithms are AES, 3DES, DES, Blowfish, Twofish and CAST128.

HMAC

– Specifies the hash function used to calculate a check sum that reveals if the data

packet is altered while being transmitted. MD5 and SHA1 are supported algorithms.

Life Times

– Specifies in KB or seconds when the security associations for the VPN

tunnel need to be re-negotiated.

Certificates

A certificate is a digital proof of identity. It links an identity to a public key in a trustworthy

manner. Certificates can be used to authenticate individual users or other entities. These

types of certificates are commonly called end-entity certificates.

Before a VPN tunnel with certificate based authentication can be set up, the firewall needs

a certificate of its own and that of the remote firewall. These certificates can either be self-

signed certificates, or issued by a CA.

Trusting Certificates

When setting up a VPN tunnel, the firewall has to be told whom it should trust. When using

pre-shared keys, this is simple. The firewall trusts anyone who has the same pre-shared key.

When using certificates, on the other hand, you tell the firewall that it can trust anyone

whose certificate is signed by a given CA. Before a certificate is accepted, the following steps

are taken to verify the validity of the certificate:

•

Construct a certification path up to the trusted root CA.

•

Verify the signatures of all certificates in the certification path.

•

Fetch the CRL for each certificate to verify that none of the certificates have been

revoked.

Local identities

This is a list of all the local identity certificates that can be used in VPN tunnels. A local

identity certificate is used by the firewall to prove its identity to the remote VPN peer.

To add a new local identity certificate, click Add new. The following pages will allow you to

specify a name for the local identity, and upload the certificate and private key files. This

certificate can be selected in the Local Identity field on the VPN page.

This list also includes a special certificate called Admin. This is the certificate used by the

web interface to provide HTTPS access.

Note: The certificate named Admin can only be replaced, not deleted or renamed. This is

used for HTTPS access to the DFL-1100.

Certificates of remote peers

This is a list of all certificates of individual remote peers.

To add a new remote peer certificate, click Add new. The following pages will allow you to

specify a name for the remote peer certificate and upload the certificate file. This certificate

can be selected in the Certificates field on the VPN page.

Certificate Authorities

This is a list of all CA certificates. To add a new Certificate Authority certificate, click Add

new. The following pages will allow you to specify a name for the CA certificate and upload

the certificate file. This certificate can be selected in the Certificates field on the VPN page.