Page 61 / 139 Scroll up to view Page 56 - 60
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.
Page 62 / 139
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.
Page 63 / 139
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
Page 64 / 139
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.
Page 65 / 139
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.

Rate

3.5 / 5 based on 2 votes.

Bookmark Our Site

Press Ctrl + D to add this site to your favorites!

Share
Top