Chapter 9.

VPN
This chapter describes VPN usage with NetDefendOS.

• Overview, page 229

• VPN Quickstart Guide, page 231

• IPsec, page 240

• IPsec Tunnels, page 253

• PPTP/L2TP, page 260

9.1. Overview
9.1.1. The Need for VPNs
Most networks are connected to each other through the Internet. Business increasingly utilizes the
Internet since it offers efficient and inexpensive communication. A means is needed for data to
travel across the Internet to its intended recipient without another party being able to read or alter it.
It is equally important that the recipient can verify that no one is falsifying information, in other
words, pretending to be someone else. Virtual Private Networks (VPNs) meet this need, providing a
highly cost effective means of establishing secure links so that data can be exchanged in a secure
manner.

9.1.2. VPN Encryption

Cryptography provides the means to create VPNs across the Internet with no additional investments
in connectivity. Cryptography is an umbrella expression covering 3 techniques and benefits:

Confidentiality No one but the intended recipients is able to receive and

understand the communication. Confidentiality is
accomplished by encryption.

Authentication and Integrity Proof for the recipient that the communication was actually
sent by the expected sender, and that the data has not been
modified in transit. This is accomplished by authentication,
often by use of cryptographic keyed hashes.

Non-repudiation Proof that the sender actually sent the data; the sender cannot
later deny having sent it. Non-repudiation is usually a
side-effect of authentication.

VPNs are normally only concerned with confidentiality and authentication. Non-repudiation is
normally not handled at the network level but rather on a transaction (document-by-document)
basis.

9.1.3. VPN Planning

An attacker targeting a VPN connection will typically not attempt to crack the VPN encryption
since this requires enormous work. Rather, they will see VPN traffic as an indication that there is
something worth targeting at the other end of the connection. Typically, mobile clients and branch
offices are far more attractive targets than the main corporate networks. Once inside those, getting to
the corporate network becomes easier.

In designing a VPN there are many non-obvious issues that need to be addressed. This includes:

229
9.1.4. Key Distribution Chapter 9. VPN

• Protecting mobile and home computers

• Restricting access through the VPN to needed services only, since mobile computers are
vulnerable

• Creating DMZs for services that need to be shared with other companies through VPNs

• Adapting VPN access policies for different groups of users

• Creating key distribution policies

A common misconception is that VPN-connections are equivalents to the internal network from a
security standpoint and that they can be connected directly to it with no further precautions. It is
important to remember that although the VPN-connection itself may be secure, the total level of
security is only as high as the security of the tunnel endpoints.

It is becoming increasingly common for users on the move to connect directly to their company's
network via VPN from their laptops. However, the laptop itself is often not protected. In other
words, an intruder can gain access to the protected network through an unprotected laptop and
already-opened VPN connections.

A VPN connection should never be regarded as an integral part of a protected network. The VPN
firewall should instead be located in a special DMZ or outside a firewall dedicated to this task. By
doing this, you can restrict which services can be accessed via VPN and modem and ensure that
these services are well protected against intruders. In instances where the firewall features an
integrated VPN feature, it is usually possible to dictate the types of communication permitted. The
NetDefendOS VPN module features such a facility.

9.1.4. Key Distribution

Key distribution schemes are best planned in advance. Issues that need to be addressed include:

• How will keys be distributed? Email is not good. Phone conversations might be secure enough.

• How many different keys should be used? One key per user? One per group of users? One per
LAN-to-LAN connection? One key for all users and one key for all LAN-to-LAN connections?
It is probably better using more keys than is necessary today since it will be easier to adjust
access per user (group) in the future.

• Should the keys be changed? If so, how often? In cases where keys are shared by multiple users,
you may want to consider overlapping schemes, so that the old keys work for a short period of
time when new keys have been issued.

• What happens when an employee in possession of a key leaves the company? If several users are
using the same key, it should be changed.

• In cases where the key is not directly programmed into a network unit, such as a VPN firewall,
how should the key be stored? On a floppy? As a pass phrase to memorize? On a smart card? If
it is a physical token, how should it be handled?

230
9.2. VPN Quickstart Guide Chapter 9. VPN

9.2. VPN Quickstart Guide

Later sections in this chapter will explore VPN components in detail. To help put those later
sections in context, this section is a quickstart summary of the key steps in VPN setup.

It outlines the individual steps in setting up VPNs for the most common VPN scenarios. These are:

• IPsec LAN to LAN with Pre-shared Keys

• IPsec Roaming Clients with Pre-shared Keys

• IPsec Roaming Clients with Certificates

• L2TP Roaming Clients with Pre-Shared Keys

• L2TP Roaming Clients with Certificates

• PPTP Roaming Clients

9.2.1. IPsec LAN to LAN with Pre-shared Keys

1. Create a Pre-shared Key object.

2. Optionally create a new IKE Proposal List object and/or an IPsec Proposal List object if the
default list settings are not satisfactory. This will depend on the capabilities of the device at the
other side of the tunnel.

3. In Hosts & Networks create IP objects for:

• The remote VPN gateway which is the IP address of the network device at the other end of
the tunnel (let's call this object remote_gw).

• The remote network which lies behind the remote VPN gateway (let's call this object
remote_net).

• The local network behind the D-Link Firewall which will communicate across the tunnel.
Here we will assume that this is the pre-defined address lannet and this network is attached
to the NetDefendOS lan interface.

4. Create an IPsec Tunnel object (let's call this object ipsec_tunnel). Specify the following tunnel
parameters:

• Set Local Network to lannet.

• Set Remote Network to remote_net.

• Set Remote Gateway to remote_gw.

• Set Encapsulation mode to Tunnel.

• Choose the IKE and IPsec proposal lists to be used.

• For Authentication select the Pre-shared Key object defined in step (1) above.

The IPsec Tunnel object can be treated exactly like any NetDefendOS Interface object in later
steps.

5. Set up two IP rules in the IP rule set for the tunnel:

• An Allow rule for outbound traffic that has the previously defined ipsec_tunnel object as

231
9.2.2. IPsec Roaming Clients with Chapter 9. VPN
Pre-shared Keys

the Destination Interface. The rule's Destination Network is the remote network
remote_net.

• An Allow rule for inbound traffic that has the previously defined ipsec_tunnel object as the
Source Interface. The Source Network is remote_net.

Action Src Interface Src Network Dest Interface Dest Network Service
Allow lan lannet ipsec_tunnel remote_net All
Allow ipsec_tunnel remote_net lan lannet All

The Service used in these rules is All but it could be a predefined service.

6. Define a new NetDefendOS Route which specifies that the VPN Tunnel ipsec_tunnel is the
Interface to use for routing packets bound for the remote network at the other end of the tunnel.

Interface Network Gateway

ipsec_tunnel remote_net

9.2.2. IPsec Roaming Clients with Pre-shared Keys

This section details the setup with roaming clients connecting through an IPsec tunnel with
pre-shared keys. There are two types of roaming clients:

• A. The IP addresses of the clients is known beforehand.

• B. The IP address of clients is not known beforehand and must be handed out by NetDefendOS
as they connect.

A. IP addresses already allocated

The IP addresses may be known beforehand and pre-allocated to the roaming clients before they
connect. The client's IP address will be will be manually input into the VPN client software.

1. Set up user authentication. XAuth user authentication is not required with IPsec roaming clients
but is recommended (this step could initially be left out to simplify setup). The authentication
source can be one of the following:

• A Local User DB object which is internal to NetDefendOS.

• An external authentication server.

An internal user database is easier to set up and is assumed here. Changing this to an external
server is simple to do later.

To implement user authentication with an internal database:

• Define a Local User DB object (let's call this object TrustedUsers).

• Add individual users to TrustedUsers. This should consist of at least a username and
password combination.

The Group string for a user can be specified if its group's access is to be restricted to
certain source networks. Group can be specified (with the same text string) in the

232
9.2.2. IPsec Roaming Clients with Chapter 9. VPN
Pre-shared Keys

Authentication section of an IP object. If that IP object is then used as the Source

Network of a rule in the IP rule set, that rule will only apply to a user if their Group string
matches the Group string of the IP object. (note: Group has no meaning in
Authentication Rules).

• Create a new User Authentication Rule with the Authentication Source set to
TrustedUsers. The other parameters for the rule are:

Agent Auth Source Src Network Interface Client Source IP

XAUTH Local all-nets any all-nets (0.0.0.0/0)

2. The IPsec Tunnel object ipsec_tunnel should have the following parameters:

• Set Local Network to lannet.

• Set Remote Network to all-nets

• Set Remote Gateway to all-nets.

• Set Encapsulation mode to Tunnel.

• Set the IKE and IPsec proposal lists to match the capabilities of the clients.

• No routes can be predefined so the option Dynamically add route to the remote network
when tunnel established should be enabled for the tunnel object.

• Enable the option Require IKE XAuth user authentication for inbound IPsec tunnels.
This will enable a search for the first matching XAUTH rule in the authentication rules.

3. The IP rule set should contain the single rule:

Action Src Interface Src Network Dest Interface Dest Network Service
Allow ipsec_tunnel all-nets lan lannet All

Once an Allow rule permits the connection to be set up, bidirectional traffic flow is allowed which is
why only one rule is used here. Instead of all-nets being used in the above, a more secure defined IP
object could be used which specifies the exact range of the pre-allocated IP addresses.

B. IP addresses handed out by NetDefendOS

If the client IP addresses are not known then they must be handed out by NetDefendOS. To do this
the above must be modified with the following:

1. If a specific IP address range is to be used as a pool of available addresses then:

• Create a Config Mode Pool object (there can only be one associated with a NetDefendOS
installation) and in it specify the address range.

• Enable the IKE Config Mode option in the IPsec Tunnel object ipsec_tunnel.

2. If client IP addresses are to be retrieved through DHCP:

• Create an IP Pool object and in it specify the DHCP server to use. The DHCP server can be
specified as a simple IP address or alternatively as being accessible on a specific interface.
If an internal DHCP server is to be used then specify the loopback address 127.0.0.1 as the
DHCP server IP address.

233
9.2.3. IPsec Roaming Clients with Chapter 9. VPN
Certificates

• Create a Config Mode Pool object (there can only be one associated with a NetDefendOS
installation) and associate with it the IP Pool object defined in the previous step.

• Enable the IKE Config Mode option in the IPsec Tunnel object ipsec_tunnel.

Configuring the IPsec Client

In both cases (A) and (B) above the IPsec client will need to configured with the URL of the D-Link
Firewall as well as the pre-shared key.

9.2.3. IPsec Roaming Clients with Certificates

If certificates are used with IPsec roaming clients instead of pre-shared keys then no Pre-shared
Key object is needed and the other differences in the setup described above are:

1. Load a Gateway Certificate and Root Certificate into NetDefendOS.

2. When setting up the IPsec Tunnel object, specify the certificates to use under Authentication.
This is done by:

a. Enable the X.509 Certificate option.

b. Select the Gateway Certificate.

c. Add the Root Certificate to use.

3. The IPsec client software will need to appropriately configured with the certificates and remote
IP addresses.

The step to set up user authentication is optional since this is additional security to certificates.

9.2.4. L2TP Roaming Clients with Pre-Shared Keys

Due to the inbuilt L2TP client in Microsoft Windows, L2TP is a popular choice for roaming client
VPN scenarios. L2TP is usually encapsulated in IPsec to provide encryption with IPsec running in
transport mode instead of tunnel mode. The steps for L2TP over IPsec setup are:

1. Create an IP object (let's call it l2tp_pool) which defines the range of IP addresses which can be
handed out to clients. The range chosen could be of two types:

• A range taken from the internal network to which clients will connect. If the internal
network is 192.168.0.0/24 then we might use the address range 192.168.0.10 to
192.168.0.20. The danger here is that an IP address might be accidentally used on the
internal network and handed out to a client.

• Use a new address range that is totally different to any internal network. This prevents any
chance of an address in the range also being used on the internal network.

2. Define two other IP objects:

• ip_ext which is the external public IP address through which clients connect (let's assume
this is on the ext interface).

• ip_int which is the internal IP address of the interface to which the internal network is
connected (let's call this interface int).

234
9.2.4. L2TP Roaming Clients with Chapter 9. VPN
Pre-Shared Keys

3. Define a Pre-shared Key for the IPsec tunnel.

4. Define an IPsec Tunnel object (let's call this object ipsec_tunnel) with the following
parameters:

• Set Local Network to ip_ext (specify all-nets instead if NetDefendOS is behind a NATing
device).

• Set Remote Network to all-nets

• Set Remote Gateway to none

• For Authentication select the Pre-shared Key object defined in the first step.

• Set Encapsulation Mode to Transport.

• Select the IKE and IPsec proposal lists to be used.

• Enable the routing option Dynamically add route to the remote network when tunnel
established.

5. Define an PPTP/L2TP Server object (let's call this object l2tp_tunnel) with the following
parameters:

• Set Inner IP Address to ip_int

• Set Tunnel Protocol to L2TP

• Set Outer Interface Filter to ipsec_tunnel

• Set Outer Server IP to ip_ext

• Select the Microsoft Point-to-Point Encryption allowed. Since IPsec encryption is used
this can be set to be None only, otherwise double encryption will degrade throughput.

• Set IP Pool to l2tp_pool.

• Enable Proxy ARP on the int interface to which the internal network is connected.

• Make the interface a member of a specific routing table so that routes are automatically
added to that table. Normally the main table is selected.

6. For user authentication:

• Define a Local User DB object (let's call this object TrustedUsers).

• Add individual users to TrustedUsers. This should consist of at least a username and
password combination.

The Group string for a user can also be specified. This is explained in the same step in the
IPsec Roaming Clients section above.

• Define a User Authentication Rule:

Agent Auth Source Src Network Interface Client Source IP

PPP Local all-nets l2tp_tunnel all-nets (0.0.0.0/0)

7. To allow traffic through the L2TP tunnel the following rules should be defined in the IP rule
set:

235
9.2.5. L2TP Roaming Clients with Chapter 9. VPN
Certificates

Action Src Interface Src Network Dest Interface Dest Network Service
Allow l2tp_tunnel l2tp_pool any int_net All
NAT ipsec_tunnel l2tp_pool ext all-nets All

The second rule would be included to allow clients to surf the Internet via the ext interface on the
D-Link Firewall. The client will be allocated a private internal IP address which must be NATed if
connections are then made out to the public Internet via the D-Link Firewall.

8. Set up the client. Assuming Windows XP, the Create new connection option in Network
Connections should be selected to start the New Connection Wizard. The key information to
enter in this wizard is: the resolvable URL of the D-Link Firewall or alternatively its ip_ext IP
address.

Then choose Network > Properties. In the dialog that opens choose the L2TP Tunnel and
select Properties. In the new dialog that opens select the Networking tab and choose Force to
L2TP. Now go back to the L2TP Tunnel properties, select the Security tab and click on the
IPsec Settings button. Now enter the pre-shared key.

9.2.5. L2TP Roaming Clients with Certificates

If certificates are used with L2TP roaming clients instead of pre-shared keys then the differences in
the setup described above are:

1. Load a Gateway Certificate and Root Certificate into NetDefendOS.

2. When setting up the IPsec Tunnel object, specify the certificates to use under Authentication.
This is done by:

a. Enable the X.509 Certificate option.

b. Select the Gateway Certificate.

c. Add the Root Certificate to use.

3. If using the Windows XP L2TP client, the appropriate certificates need to be imported into
Windows before setting up the connection with the New Connection Wizard.

The step to set up user authentication is optional since this is additional security to certificates.

9.2.6. PPTP Roaming Clients

PPTP is simpler to set up than L2TP since IPsec is not used and instead relies on its own, less
strong, encryption.

A major secondary disadvantage is not being able to NAT PPTP connections through a tunnel so
multiple clients can use a single connection to the D-Link Firewall. If NATing is tried then only the
first client that tries to connect will succeed.

The steps for PPTP setup are as follows:

1. In Hosts & Networks define the following IP objects:

• A pptp_pool IP object which is the range of internal IP addresses that will be handed out
from an internal network.

236
9.2.7. VPN Troubleshooting Chapter 9. VPN

• An int_net object which is the internal network from which the addresses come.

• An ip_int object which is the internal IP address of the interface connected to the internal
network. let's assume this interface is int.

• An ip_ext object which is the external public address which clients will connect to (let's
assume this is on the ext interface).

2. Define a PPTP/L2TP object (let's call it pptp_tunnel) with the following parameters:

• Set Inner IP Address to ip_net.

• Set Tunnel Protocol to PPTP.

• Set Outer Interface Filter to ext.

• Set Outer server IP to ip_ext.

• For Microsoft Point-to-Point Encryption it is recommended to disable all options except

128 bit encryption.

• Set IP Pool to pptp_pool

• Enable Proxy ARP on the int interface.

• As in L2TP, enable the insertion of new routes automatically into the main routing table.

3. Define a User Authentication Rule, this is almost identical to L2TP:

Agent Auth Source Src Network Interface Client Source IP

PPP Local all-nets pptp_tunnel all-nets (0.0.0.0/0)

4. Now set up the IP rules in the IP rule set:

Action Src Interface Src Network Dest Interface Dest Network Service
Allow pptp_tunnel pptp_pool any int_net All
NAT pptp_tunnel pptp_pool ext all-nets All

As described for L2TP, the NAT rule lets the clients access the public Internet via the D-Link
Firewall.

5. Set up the client. For Windows XP, the procedure is exactly as described for L2TP above but
without entering the pre-shared key.

9.2.7. VPN Troubleshooting

General Troubleshooting
In all types of VPNs some basic troubleshooting checks can be made:

• Check that all IP addresses have been specified correctly.

• Check that all pre-shared keys and usernames/passwords are correctly entered.

237
9.2.7. VPN Troubleshooting Chapter 9. VPN

• If certificates have been used, check that the correct certificates have been used and that they
haven't expired.

• Use ICMP Ping to confirm that the tunnel is working. With roaming clients this is best done by
Pinging the internal IP address of the local network interface on the D-Link Firewall from a
client (in LAN to LAN setups pinging could be done in any direction). If NetDefendOS is to
able to respond to a Ping then the following rule must exist in the IP rule set.

Action Src Interface Src Network Dest Interface Dest Network Service
Allow vpn_tunnel all-nets core all-nets ICMP

• Ensure that another IPsec Tunnel definition isn't preventing the correct definition being
reached. The tunnel list is scanned from top to bottom and a tunnel in a higher position with the
Remote Network set to all-nets and the Remote Gateway set to none could prevent the correct
tunnel being reached. The symptom of this problem is often an Incorrect Pre-shared Key
message.

• Try and avoid duplication of IP addresses between the remote network being accessed by a
client and the internal network to which a roaming client belongs.

If a roaming client becomes temporarily part of a network such as a Wi-Fi network at an airport,
the client will get an IP address from the Wi-Fi network's DHCP server. If that IP also belongs
to the network behind the D-Link Firewall accessible through a tunnel, then Windows will still
continue to assume that the IP address is to be found on the client's local network. Windows
therefore won't correctly route packets bound for the remote network through the tunnel but
instead route them to the local network.

The solution to this problem of local/remote IP address duplication is to create a new route in the
client's Windows routing table that explicitly routes the IP address to the tunnel.

• If roaming client user authentication is not asking the users for their username/password then
ensure that the following advanced settings are enabled:

• IPsecBeforeRules for pure IPsec roaming clients.

• PPP_L2TPBeforeRules for L2TP roaming clients.

• PPP_PPTPBeforeRules for PPTP roaming clients.

These settings should be enabled by default and they ensure that user authentication traffic
between NetDefendOS and the client can bypass the IP rule set. If the appropriate setting is not
enabled then an explicit rule needs to be added to the IP rule set to allow the authentication
traffic to pass between roaming clients and NetDefendOS. This rule will have a destination
interface of core.

Troubleshooting IPsec Tunnels

A number of commands can be used to diagnose IPsec tunnels:

The ipsecstat console command

ipsecstat can be used to show that IPsec tunnels have correctly established. A representative
example of output is:

> ipsecstat
--- IPsec SAs:
Displaying one line per SA-bundle

238
9.2.7. VPN Troubleshooting Chapter 9. VPN

IPsec Tunnel Local Net Remote Net Remote GW

------------ -------------- ------------ -------------
L2TP_IPSec 214.237.225.43 84.13.193.179 84.13.193.179
IPsec_Tun1 192.168.0.0/24 172.16.1.0/24 82.242.91.203

To examine the first IKE negotiation phase of tunnel setup use:

> ipsecstat -ike

To get complete details of tunnel setup use:

> ipsecstat -u -v

The ikesnoop console command

A common problem with setting up IPsec is a proposal list that is unacceptable to the device at the
other end of the tunnel. The ikesnoop command can show up problems with the proposal list by
showing the details of the negotiations that take place.

ikesnoop verbose

Once this command is issued, an ICMP ping can be then sent to the D-Link Firewall from the other
end of the tunnel. This will cause ikesnoop verbose to output details of the tunnel setup.
Incompatibilities in the proposal lists for IKE and/or IPsec can often cause problems which show up
in this output.

If there are multiple tunnels in a setup or mutiple clients on a single tunnel then the output from
ikesnoop verbose can be overwhelming. It is therefore better to specify that the output come from a
single tunnel by specifying the client's IP address:

ikesnoop verbose <ip-address>

Management Interface Failure with VPN

If any VPN tunnel is set up and then the management interface no longer operates then it is likely to
be a problem with the management traffic being routed back through the VPN tunnel instead of the
correct interface.

This happens when a route is established in the main routing table which routes any traffic for
all-nets through the VPN tunnel. If the management interface is not reached by the VPN tunnel then
the administrator needs to create a specific route that routes management interface traffic leaving the
D-Link Firewall back to the management subnet.

When any VPN tunnel is defined, an all-nets route is automatically defined in the routing table so
the administrator should always set up a specific route for the management interface to be correctly
routed.

239
9.3. IPsec Chapter 9. VPN

9.3. IPsec
9.3.1. Overview
Internet Protocol Security (IPsec), is a set of protocols defined by the Internet Engineering Task
Force (IETF) to provide IP security at the network layer. An IPsec based VPN is made up by two
parts:

• Internet Key Exchange protocol (IKE)

• IPsec protocols (AH/ESP/both)

The first part, IKE, is the initial negotiation phase, where the two VPN endpoints agree on which
methods will be used to provide security for the underlying IP traffic. Furthermore, IKE is used to
manage connections, by defining a set of Security Associations, SAs, for each connection. SAs are
unidirectional, so there are usually at least two for each IPsec connection.

The second part is the actual IP data being transferred, using the encryption and authentication
methods agreed upon in the IKE negotiation. This can be accomplished in a number of ways; by
using IPsec protocols ESP, AH, or a combination of both.

The flow of events can be briefly described as follows:

• IKE negotiates how IKE should be protected

• IKE negotiates how IPsec should be protected

• IPsec moves data in the VPN

The following sections will describe each of these steps in detail.

9.3.2. Internet Key Exchange (IKE)

This section describes IKE, the Internet Key Exchange protocol, and the parameters that are used
with it.

Encrypting and authenticating data is fairly straightforward, the only things needed are encryption
and authentication algorithms, and the keys used with them. The Internet Key Exchange (IKE)
protocol, IKE, is used as a method of distributing these "session keys", as well as providing a way
for the VPN endpoints to agree on how the data should be protected.

IKE has three main tasks:

• Provide a means for the endpoints to authenticate each other

• Establish new IPsec connections (create SA pairs)

• Manage existing connections

IKE keeps track of connections by assigning a set of Security Associations, SAs, to each connection.
An SA describes all parameters associated with a particular connection, such as the IPsec protocol
used (ESP/AH/both) as well as the session keys used to encrypt/decrypt and/or authenticate/verify
the transmitted data. An SA is, by nature, unidirectional, thus the need for more than one SA per
connection. In most cases, where only one of ESP or AH is used, two SAs will be created for each
connection, one describing the incoming traffic, and the other the outgoing. In cases where ESP and
AH are used in conjunction, four SAs will be created.

240
9.3.2. Internet Key Exchange (IKE) Chapter 9. VPN

IKE Negotiation

The process of negotiating session parameters consists of a number of phases and modes. These are
described in detail in the below sections.

The flow of events can summarized as follows:

IKE Phase-1
• Negotiate how IKE should be protected

IKE Phase-2
• Negotiate how IPsec should be protected

• Derive some fresh keying material from the key exchange in phase-1, to
provide session keys to be used in the encryption and authentication of the
VPN data flow

IKE and IPsec Lifetimes

Both the IKE and the IPsec connections have limited lifetimes, described both in terms of time
(seconds), and data (kilobytes). These lifetimes prevent a connection from being used too long,
which is desirable from a crypto-analysis perspective.

The IPsec lifetime must be shorter than the IKE lifetime. The difference between the two must be a
minimum of 5 minutes. This allows for the IPsec connection to be re-keyed simply by performing
another phase-2 negotiation. There is no need to do another phase-1 negotiation until the IKE
lifetime has expired.

IKE Proposals

An IKE proposal is a suggestion of how to protect data. The VPN device initiating an IPsec
connection, the initiator, will send a list of proposals, a proposal-list, suggesting different methods
of how to protect the connection.

The connection being negotiated can be either an IPsec connection protecting the data flow through
the VPN, or it can be an IKE connection, protecting the IKE negotiation itself.

The responding VPN device, upon receiving this proposal-list, will choose the most suitable
proposal according to its own security policy, and respond by specifying which one of the proposal
it has chosen.

If no acceptable proposal can be found, it will respond by saying that no proposal could be accepted,
and possibly provide a reason why.

The proposals contain all parameters needed, such as algorithms used to encrypt and authenticate
the data, and other parameters as described in section IKE Parameters.

IKE Phase-1 - IKE Security Negotiation

An IKE negotiation is performed in two phases. The first phase, phase-1, is used to authenticate the
two VPN firewalls or VPN Clients to each other, by confirming that the remote device has a
matching Pre-Shared Key.

However, since we do not want to publish to much of the negotiation in plaintext, we first agree
upon a way of protecting the rest of the IKE negotiation. This is done, as described in the previous
section, by the initiator sending a proposal-list to the responder. When this has been done, and the
responder accepted one of the proposals, we try to authenticate the other end of the VPN to make
sure it is who we think it is, as well as proving to the remote device; that we are who we claim to be.
A technique known as a Diffie Hellman Key Exchange is used to intially agree a shared secret
between the two parties in the negotiation and to derive keys for encryption.

241
9.3.2. Internet Key Exchange (IKE) Chapter 9. VPN

Authentication can be accomplished through Pre-Shared Keys, certificates or public key encryption.
Pre-Shared Keys is the most common authentication method today. PSK and certificates are
supported by the NetDefendOS VPN module.

IKE Phase-2 - IPsec Security Negotiation

In phase two, another negotiation is performed, detailing the parameters for the IPsec connection.

In phase-2 we will also extract new keying material from the Diffie-Hellman key exchange in
phase-1, to provide session keys to use in protecting the VPN data flow.

If PFS, Perfect Forwarding Secrecy, is used, 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.

Once the phase-2 negotiation is finished, the VPN connection is established and ready for use.

IKE Parameters

There are a number of parameters used in the negotiation process.

Below is a summary of the configuration parameters needed to establish a VPN connection.

Understanding what these parameters do before attempting to configure the VPN endpoints is highly
recommended, since it is of great importance that both endpoints are able to agree on all of these
parameters.

When installing two D-Link Firewalls as VPN endpoints, this process is reduced to comparing fields
in two identical dialog boxes. However, it is not quite as easy when equipment from different
vendors is involved.

Endpoint Identification The Local ID is a piece of data representing the identity of the
VPN gateway. With Pre-Shared Keys this is a unique piece of
data uniquely identifying the tunnel endpoint.

Authentication using Pre-Shared Keys is based on the

Diffie-Hellman algorithm.

Local and Remote These are the subnets or hosts between which IP traffic will
Networks/Hosts be protected by the VPN. In a LAN-to-LAN connection, these
will be the network addresses of the respective LANs.

If roaming clients are used, the remote network will most

likely be set to all-nets, meaning that the roaming client may
connect from anywhere.

Tunnel / Transport Mode IPsec can be used in two modes, tunnel or transport.

Tunnel mode indicates that the traffic will be tunneled to a

remote device, which will decrypt/authenticate the data,
extract it from its tunnel and pass it on to its final destination.
This way, an eavesdropper will only see encrypted traffic
going from one of VPN endpoint to another.

In transport mode, the traffic will not be tunneled, and is

hence not applicable to VPN tunnels. It can be used to secure
a connection from a VPN client directly to the D-Link
Firewall, for example for IPsec protected remote
configuration.

This setting will typically be set to "tunnel" in most

242
9.3.2. Internet Key Exchange (IKE) Chapter 9. VPN

configurations.

Remote Gateway The remote gateway will be doing the

decryption/authentication and pass the data on to its final
destination. This field can also be set to "none", forcing the
D-Link VPN to treat the remote address as the remote
gateway. This is particularly useful in cases of roaming
access, where the IP addresses of the remote VPN clients are
not known beforehand. Setting this to "none" will allow
anyone coming from an IP address conforming to the "remote
network" address discussed above to open a VPN connection,
provided they can authenticate properly.

The remote gateway is not used in transport mode.

Main/Aggressive Mode The IKE negotiation has two modes of operation, main mode
and aggressive mode.

The difference between these two is that aggressive mode will

pass more information in fewer packets, with the benefit of
slightly faster connection establishment, at the cost of
transmitting the identities of the security firewalls in the clear.

When using aggressive mode, some configuration parameters,

such as Diffie-Hellman groups, and PFS, can not be
negotiated, resulting in a greater importance of having
"compatible" configurations on both ends.

IPsec Protocols The IPsec protocols describe how the data will be processed.
The two protocols to choose from are AH, Authentication
Header, and ESP, Encapsulating Security Payload.

ESP provides encryption, authentication, or both. However,

we do not recommend using encryption only, since it will
dramatically decrease security.

More on ESP in ESP (Encapsulating Security Payload).

AH only provides authentication. The difference from ESP

with authentication only is that AH also authenticates parts of
the outer IP header, for instance source and destination
addresses, making certain that the packet really came from
who the IP header claims it is from.

More on AH in AH (Authentication Header).

Note
D-Link Firewalls do not support AH.

IKE Encryption This specifies the encryption algorithm used in the IKE
negotiation, and depending on the algorithm, the size of the
encryption key used.

The algorithms supported by NetDefendOS IPsec are:

• AES

• Blowfish

• Twofish

243
9.3.2. Internet Key Exchange (IKE) Chapter 9. VPN

• Cast128

• 3DES

• DES

DES is only included to be interoperable with other older

VPN implementations. Use of DES should be avoided
whenever possible, since it is an old algorithm that is no
longer considered secure.

IKE Authentication This specifies the authentication algorithms used in the IKE
negotiation phase.

The algorithms supported by NetDefendOS IPsec are:

• SHA1

• MD5

IKE DH (Diffie-Hellman) Group This specifies the Diffie-Hellman group to use when doing
key exchanges in IKE.

The Diffie-Hellman groups supported by NetDefendOS are:

• DH group 1 (768-bit)

• DH group 2 (1024-bit)

• DH group 5 (1536-bit)

Security of the key exchanges increases as the DH group bit

become larger, as does the time taken for the exchanges.

IKE Lifetime This is the lifetime of the IKE connection.

It is specified in time (seconds) as well as data amount

(kilobytes). Whenever one of these expires, a new phase-1
exchange will be performed. If no data was transmitted in the
last "incarnation" of the IKE connection, no new connection
will be made until someone wants to use the VPN connection
again. This value must be set greater than the IPsec SA
lifetime.

PFS With PFS disabled, initial keying material is "created" during

the key exchange in phase-1 of the IKE negotiation. In
phase-2 of the IKE negotiation, encryption and authentication
session keys will be extracted from this initial keying
material. By using PFS, Perfect Forwarding Secrecy,
completely new keying material will always be created upon
re-key. Should one key be compromised, no other key can be
derived using that information.

PFS can be used in two modes, the first is PFS on keys, where
a new key exchange will be performed in every phase-2
negotiation. The other type is PFS on identities, where the
identities are also protected, by deleting the phase-1 SA every
time a phase-2 negotiation has been finished, making sure no
more than one phase-2 negotiation is encrypted using the
same key.

PFS is generally not needed, since it is very unlikely that any

encryption or authentication keys will be compromised.

244
9.3.3. IKE Authentication Chapter 9. VPN

PFS Group This specifies the PFS group to use with PFS.

The PFS groups supported by NetDefendOS are:

• 1 modp 768-bit

• 2 modp 1024-bit

• 5 modp 1536-bit

Security increases as the PFS group bits grow larger, as does

the time taken for the exchanges.

IPsec DH Group This is a Diffie-Hellman group much like the one for IKE.
However, this one is used solely for PFS.

IPsec Encryption The encryption algorithm to use on the protected traffic.

This is not needed when AH is used, or when ESP is used

without encryption.

The algorithms supported by D-Link Firewall VPNs are:

• AES

• Blowfish

• Twofish

• Cast128

• 3DES

• DES

IPsec Authentication This specifies the authentication algorithm used on the

protected traffic.

This is not used when ESP is used without authentication,

although it is not recommended to use ESP without
authentication.

The algorithms supported by D-Link Firewall VPNs are:

• SHA1

• MD5

IPsec Lifetime This is the lifetime of the VPN connection. It is specified in

both time (seconds) and data amount (kilobytes). Whenever
either of these values is exceeded, a re-key will be initiated,
providing new IPsec encryption and authentication session
keys. If the VPN connection has not been used during the last
re-key period, the connection will be terminated, and
re-opened from scratch when the connection is needed again.
This value must be set lower than the IKE lifetime.

9.3.3. IKE Authentication

Manual Keying

The "simplest" way of configuring a VPN is by using a method called "manual keying". This is a

245
9.3.3. IKE Authentication Chapter 9. VPN

method where IKE is not used at all; the encryption and authentication keys as well as some other
parameters are directly configured on both sides of the VPN tunnel.

Note
D-Link Firewalls do not support Manual Keying.

Manual Keying Advantages

Since it is very straightforward it will be quite interoperable. Most interoperability problems

encountered today are in IKE. Manual keying completely bypasses IKE and sets up its own set of
IPsec SAs.

Manual Keying Disadvantages

It is an old method, which was used before IKE came into use, and is thus lacking all the
functionality of IKE. This method therefore has a number of limitations, such as having to use the
same encryption/authentication key always, no anti-replay services, and it is not very flexible. There
is also no way of assuring that the remote host/firewall really is the one it says it is.

This type of connection is also vulnerable for something called "replay attacks", meaning a
malicious entity which has access to the encrypted traffic can record some packets, store them, and
send them to its destination at a later time. The destination VPN endpoint will have no way of
telling if this packet is a "replayed" packet or not. Using IKE eliminates this vulnerability.

PSK

Using a Pre-shared Key (PSK) is a method where the endpoints of the VPN "share" a secret key.
This is a service provided by IKE, and thus has all the advantages that come with it, making it far
more flexible than manual keying.

PSK Advantages

Pre-Shared Keying has a lot of advantages over manual keying. These include endpoint
authentication, which is what the PSKs are really for. It also includes all the benefits of using IKE.
Instead of using a fixed set of encryption keys, session keys will be used for a limited period of
time, where after a new set of session keys are used.

PSK Disadvantages

One thing that has to be considered when using Pre-Shared Keys is key distribution. How are the
Pre-Shared Keys distributed to remote VPN clients and firewalls? This is a major issue, since the
security of a PSK system is based on the PSKs being secret. Should one PSK be compromised, the
configuration will need to be changed to use a new PSK.

Certificates

Each VPN firewall has its own certificate, and one or more trusted root certificates.

The authentication is based on several things:

• That each endpoint has the private key corresponding to the public key found in its certificate,
and that nobody else has access to the private key.

• That the certificate has been signed by someone that the remote gateway trusts.

Certificate Advantages

Added flexibility. Many VPN clients, for instance, can be managed without having the same
pre-shared key configured on all of them, which is often the case when using pre-shared keys and

246
9.3.4. IPsec Protocols (ESP/AH) Chapter 9. VPN

roaming clients. Instead, should a client be compromised, the client's certificate can simply be
revoked. No need to reconfigure every client.

Certificate Disadvantages

Added complexity. Certificate-based authentication may be used as part of a larger public key
infrastructure, making all VPN clients and firewalls dependent on third parties. In other words, there
are more things that have to be configured, and there are more things that can go wrong.

9.3.4. IPsec Protocols (ESP/AH)

The IPsec protocols are the protocols used to protect the actual traffic being passed through the
VPN. The actual protocols used and the keys used with those protocols are negotiated by IKE.

There are two protocols associated with IPsec, AH and ESP. These are covered in the sections
below.

AH (Authentication Header)

AH is a protocol used for authenticating a data stream.

Figure 9.1. The AH protocol

AH uses a cryptographic hash function to produce a MAC from the data in the IP packet. This MAC
is then transmitted with the packet, allowing the remote gateway to verify the integrity of the
original IP packet, making sure the data has not been tampered with on its way through the Internet.
Apart from the IP packet data, AH also authenticates parts of the IP header.

The AH protocol inserts an AH header after the original IP header, and in tunnel mode, the AH
header is inserted after the outer header, but before the original, inner, IP header.

ESP (Encapsulating Security Payload)

The ESP protocol inserts an ESP header after the original IP header, in tunnel mode, the ESP header
is inserted after the outer header, but before the original, inner, IP header.

All data after the ESP header is encrypted and/or authenticated. The difference from AH is that ESP
also provides encryption of the IP packet. The authentication phase also differs in that ESP only
authenticates the data after the ESP header; thus the outer IP header is left unprotected.

The ESP protocol is used for both encryption and authentication of the IP packet. It can also be used
to do either encryption only, or authentication only.

Figure 9.2. The ESP protocol

247
9.3.5. NAT Traversal Chapter 9. VPN

9.3.5. NAT Traversal

Both IKE and IPsec protocols present a problem in the functioning of NAT. Both protocols were not
designed to work through NATs and because of this, a technique called "NAT traversal" has
evolved. NAT traversal is an add-on to the IKE and IPsec protocols that allows them to function
when being NATed. NetDefendOS supports the RFC3947 standard for NAT-Traversal with IKE.

NAT traversal is divided into two parts:

• Additions to IKE that lets IPsec peers tell each other that they support NAT traversal, and the
specific versions supported. NetDefendOS supports the RFC3947 standard for NAT-Traversal
with IKE.

• Changes to the ESP encapsulation. If NAT traversal is used, ESP is encapsulated in UDP, which
allows for more flexible NATing.

Below is a more detailed description of the changes made to the IKE and IPsec protocols.

NAT traversal is only used if both ends has support for it. For this purpose, NAT traversal aware
VPNs send out a special "vendor ID", telling the other end that it understand NAT traversal, and
which specific versions of the draft it supports.

NAT detection: Both IPsec peers send hashes of their own IP addresses along with the source UDP
port used in the IKE negotiations. This information is used to see whether the IP address and source
port each peer uses is the same as what the other peer sees. If the source address and port have not
changed, then the traffic has not been NATed along the way, and NAT traversal is not necessary. If
the source address and/or port has changed, then the traffic has been NATed, and NAT traversal is
used.

Once the IPsec peers have decided that NAT traversal is necessary, the IKE negotiation is moved
away from UDP port 500 to port 4500. This is necessary since certain NAT devices treat UDP
packet on port 500 differently from other UDP packets in an effort to work around the NAT
problems with IKE. The problem is that this special handling of IKE packets may in fact break the
IKE negotiations,which is why the UDP port used by IKE has changed.

Another problem NAT traversal resolves is that the ESP protocol is an IP protocol. There is no port
information like in TCP and UDP, which makes it impossible to have more than one NATed client
connected to the same remote gateway and the same time. Because of this, ESP packets are
encapsulated in UDP. The ESP-UDP traffic is sent on port 4500, the same port as IKE when NAT
traversal is used. Once the port has been changed all following IKE communications are done over
port 4500. Keepalive packets are also being sent periodically to keep the NAT mapping alive.

NAT Traversal Configuration

Most NAT traversal functionality is completely automatic and in the initiating firewall no special

248
9.3.6. Proposal Lists Chapter 9. VPN

configuration is needed. However, for responding firewalls two points should be noted:

• On responding firewalls, the Remote Gateway field is used as a filter on the source IP of
received IKE packets. This should be set to allow the NATed IP address of the initiator.

• When individual pre-shared keys are used with multiple tunnels connecting to one remote
firewall which are then NATed out through the same address, it is important to make sure the
Local ID is unique for every tunnel. The Local ID can be one of

• Auto - The local ID is taken as the IP address of the outgoing interface. This is the
recommended setting unless, in an unlikely event, the two firewalls have the same external
IP address.

• IP - An IP address can be manually entered

• DNS - A DNS address can be manually entered

• Email - An email address can be manually entered

9.3.6. 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 firewall 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 firewall one after another until a matching proposal
is found. Several proposal lists can be defined in NetDefendOS for different VPN scenarios. Two
IKE proposal lists and two IPsec proposal lists are defined by default in NetDefendOS.

The ike-roamingclients and esp-tn-roamingclients proposal lists are suitable for VPN tunnels that
are used for roaming VPN clients. These proposal lists are compatible with the default proposal lists
in the D-Link VPN Client.

As the name implies, the ike-lantolan and esp-tn-lantolan are suitable for LAN-to-LAN VPN
solutions. These proposal lists are trimmed to include only AES and 3DES based proposals.

Example 9.1. Using a Proposal List

This example shows how to create and use an IPsec Proposal List for use in the VPN tunnel. It will propose 3DES
and DES as encryption algorithms. The hash function SHA1 and MD5 will both be used in order to check if the
data packet is altered while being transmitted. Note that this example does not illustrate how to add the specific
IPsec tunnel object. It will also be used in a later example.

CLI
First create a list of IPsec Algorithms:

gw-world:/> add IPsecAlgorithms esp-l2tptunnel DESEnabled=Yes DES3Enabled=Yes

SHA1Enabled=Yes MD5Enabled=Yes

Then, apply the proposal list to the IPsec tunnel:

gw-world:/> set Interface IPsecTunnel MyIPsecTunnel IPsecAlgorithms=esp-l2tptunnel

Web Interface
First create a list of IPsec Algorithms:

249
9.3.7. Pre-shared Keys Chapter 9. VPN

1. Go to Objects > VPN Objects > IKE Algorithms > Add > IPsec Algorithms

2. Enter a name for the list eg. esp-l2tptunnel.

3. Now check the following:

• DES

• 3DES

• SHA1

• MD5

4. Click OK

Then, apply the proposal list to the IPsec tunnel:

1. Go to Interfaces > IPsec

2. In the grid control, click the target IPsec tunnel

3. Select the recently created esp-l2tptunnel in the IPsec Algorithms control.

4. Click OK

9.3.7. Pre-shared Keys

Pre-Shared Keys are used to authenticate VPN tunnels. The keys are secrets that are shared by the
communicating parties before communication takes place. To communicate, both parties prove that
they know the secret. The security of a shared secret depends on how "good" a passphrase is.
Passphrases that are common words are for instance extremely vulnerable to dictionary attacks.

Pre-shared Keys can be generated automatically through the WebUI but they can also be generated
through the CLI using the command pskgen (this command is fully documented in the CLI
Reference Guide).

Example 9.2. Using a Pre-Shared key

This example shows how to create a Pre-shared Key and apply it to a VPN tunnel. Since regular words and
phrases are vulnerable to dictionary attacks, they should not be used as secrets. Here the pre-shared key is a
randomly generated hexadecimal key. Note that this example does not illustrate how to add the specific IPsec
tunnel object.

CLI
First create a Pre-shared Key. To generate the key automatically with a 64 bit (the default) key, use:

gw-world:/> pskgen MyPSK

To have a longer, more secure 512 bit key the command would be:

gw-world:/> pskgen MyPSK -size=512

Or alternatively, to add the Pre-shared Key manually, use:

gw-world:/> add PSK MyPSK Type=HEX PSKHex=<enter the key here>

Now apply the Pre-shared Key to the IPsec tunnel:

gw-world:/> set Interface IPsecTunnel MyIPsecTunnel PSK=MyPSK

Web Interface

First create a Pre-shared Key:

250
9.3.8. Identification Lists Chapter 9. VPN

1. Go to Objects > Authentication Objects > Add > Pre-shared key

2. Enter a name for the pre-shared key eg. MyPSK

3. Choose Hexadecimal Key and click Generate Random Key to generate a key to the Passphrase textbox.

4. Click OK

Then, apply the pre-shared key to the IPsec tunnel:

1. Go to Interfaces > IPsec

2. In the grid control, click the target IPsec tunnel object

3. Under the Authentication tab, choose Pre-shared Key and select MyPSK

4. Click OK

9.3.8. Identification Lists

When X.509 certificates are used as authentication method for IPsec tunnels, the D-Link Firewall
will accept all remote firewalls or VPN clients that are capable of presenting a certificate signed by
any of the trusted Certificate Authorities. This can be a potential problem, especially when using
roaming clients.

Consider the scenario of travelling employees being given access to the internal corporate networks
using VPN clients. The organization administers their own Certificate Authority, and certificates
have been issued to the employees. Different groups of employees are likely to have access to
different parts of the internal networks. For instance, members of the sales force need access to
servers running the order system, while technical engineers need access to technical databases.

Since the IP addresses of the travelling employees VPN clients cannot be known beforehand, the
incoming VPN connections from the clients cannot be differentiated. This means that the firewall is
unable to control the access to various parts of the internal networks.

The concept of Identification Lists presents a solution to this problem. An identification list contains
one or more identities (IDs), where each identity corresponds to the subject field in an X.509
certificate. Identification lists can thus be used to regulate what X.509 certificates that are given
access to what IPsec tunnels.

Example 9.3. Using an Identity List

This example shows how to create and use an Identification List for use in the VPN tunnel. This Identification List
will contain one ID with the type DN, distinguished name, as the primary identifier. Note that this example does
not illustrate how to add the specific IPsec tunnel object.

CLI
First create an Identification List:

gw-world:/> add IDList MyIDList

Then, create an ID:

gw-world:/> cc IDList MyIDList

gw-world:/MyIDList> add ID JohnDoe Type=DistinguishedName

CommonName="John Doe" OrganizationName=D-Link
OrganizationalUnit=Support Country=Sweden
[email protected]

251
9.3.8. Identification Lists Chapter 9. VPN

gw-world:/MyIDList> cc

Finally, apply the Identification List to the IPsec tunnel:

gw-world:/> set Interface IPsecTunnel MyIPsecTunnel AuthMethod=Certificate

IDList=MyIDList RootCertificates=AdminCert GatewayCertificate=AdminCert

Web Interface
First create an Identification List:

1. Go to Objects > VPN Objects > ID List > Add > ID List

2. Enter a name for the identification list eg. MyIDList

3. Click OK

Then, create an ID:

1. Go to Objects > VPN Objects > ID List

2. In the grid control, click on MyIDList

3. Enter a name for the ID eg. JohnDoe

4. Select Distinguished name in the Type control

5. Now enter:

• Common Name: John Doe

• Organization Name:D-Link

• Organizational Unit: Support

• Country: Sweden

• Email Address: [email protected]

6. Click OK

Finally, apply the Identification List to the IPsec tunnel:

1. Go to Interfaces > IPsec

2. In the grid control, click on the IPsec tunnel object of interest

3. Under the Authentication tab, choose X.509 Certificate

4. Select the appropriate certificate in the Root Certificate(s) and Gateway Certificate controls.

5. Select MyIDList in the Identification List.

6. Click OK

252
9.4. IPsec Tunnels Chapter 9. VPN

9.4. IPsec Tunnels

9.4.1. Overview
An IPsec Tunnel defines an endpoint of an encrypted tunnel. Each IPsec Tunnel is interpreted as a
logical interface by NetDefendOS, with the same filtering, traffic shaping and configuration
capabilities as regular interfaces.

When another D-Link Firewall or D-Link VPN Client (or any IPsec compliant product) tries to
establish a IPsec VPN tunnel to the D-Link Firewall, the configured IPsec Tunnels are evaluated. If
a matching IPsec Tunnel definition is found, the IKE and IPsec negotiations then take place,
resulting in a IPsec VPN tunnel being established.

Note that an established IPsec tunnel does not automatically mean that all traffic from that IPsec
tunnel is trusted. On the contrary, network traffic that has been decrypted will be transferred to the
rule set for further evaluation. The source interface of the decrypted network traffic will be the name
of the associated IPsec Tunnel. Furthermore, a Route or an Access rule, in the case of a roaming
client, has to be defined to have the NetDefendOS accept certain source IP addresses from the IPsec
tunnel.

For network traffic going in the opposite direction, that is, going into a IPsec tunnel, a reverse
process takes place. First, the unencrypted traffic is evaluated by the rule set. If a rule and route
matches, NetDefendOS tries to find an established IPsec tunnel that matches the criteria. If not
found, NetDefendOS will try to establish a tunnel to the remote firewall specified by the matching
IPsec Tunnel definition.

Note
IKE and ESP/AH traffic are sent to the IPsec engine before the rule set is consulted.
Encrypted traffic to the firewall therefore does not need to be allowed in the rule set.
This behaviour can be changed in the IPsec Advanced Settings section.

9.4.2. LAN to LAN Tunnels with Pre-shared Keys

A VPN can allow geographically distributed Local Area Networks (LANs) to communicate securely
over the public Internet. In a corporate context this means LANs at geographically separate sites can
communicate with a level of security comparable to that existing if they communicated through a
dedicated, private link.

Secure communication is achieved through the use of IPsec tunneling, with the tunnel extending
from the VPN gateway at one location to the VPN gateway at another location. The D-Link Firewall
is therefore the implementor of the VPN, while at the same time applying normal security
surveillance of traffic passing through the tunnel. This section deals specifically with setting up Lan
to Lan tunnels created with a Pre-shared Key (PSK).

A number of steps are required to set up LAN to LAN tunnels with PSK:

• Set up a Pre-shared Key or secret for the VPN tunnel.

• Set up the VPN tunnel properties.

• Set up the Route .

• Set up the Rules (2-way tunnel requires 2 rules).

9.4.3. Roaming Clients

An employee who is on the move who needs to access a central corporate server from a notebook

253
9.4.3. Roaming Clients Chapter 9. VPN

computer from different locations is a typical example of a roaming client. Apart from the need for
secure VPN access, the other major issue with roaming clients is that the mobile user's IP address is
often not known beforehand. To handle the unknown IP address the NetDefendOS can dynamically
add routes to the routing table as tunnels are established.

Dealing with Unknown IP addresses

If the IP address of the client is not known before hand then the D-Link Firewall needs to create a
route in its routing table dynamically as each client connects. In the example below this is the case
and the IPsec tunnel is configured to dynamically add routes.

If clients are to be allowed to roam in from everywhere, irrespective of their IP address, then the
Remote Network needs to be set to all-nets (IP address: 0.0.0.0/0) which will allow all existing
IPv4-addresses to connect through the tunnel.

When configuring VPN tunnels for roaming clients it is usually not necessary to add to or modify
the proposal lists that are pre-configured in NetDefendOS.

9.4.3.1. PSK based client tunnels

Example 9.4. Setting up a PSK based VPN tunnel for roaming clients

This example describes how to configure an IPsec tunnel at the head office D-Link Firewall for roaming clients
that connect to the office to gain remote access. The head office network uses the 10.0.1.0/24 network span with
external firewall IP wan_ip.

Web Interface

A. Create a pre-shared key for IPsec authentication:

1. Go to Objects > Authentication Objects > Add > Pre-Shared Key

2. Now enter:

• Name: Enter a name for the pre-shared key, SecretKey for instance

• Shared Secret: Enter a secret passphrase

• Confirm Secret: Enter the secret passphrase again

3. Click OK

B. Configure the IPsec tunnel:

1. Go to Interfaces > IPsec > Add > IPsec Tunnel

2. Now enter:

• Name: RoamingIPsecTunnel

• Local Network: 10.0.1.0/24 (This is the local network that the roaming users will connect to)

• Remote Network: all-nets

• Remote Endpoint: (None)

• Encapsulation Mode: Tunnel

3. For Algorithms enter:

• IKE Algorithms: Medium or High

• IPsec Algorithms: Medium or High

4. For Authentication enter:

• Pre-Shared Key: Select the pre-shared key created earlier

254
9.4.3. Roaming Clients Chapter 9. VPN

5. Under the Routing tab:

• Enable the option: Dynamically add route to the remote network when a tunnel is established.

6. Click OK

C. Finally configure the IP rule set to allow traffic inside the tunnel.

9.4.3.2. Self-signed Certificate based client tunnels

Example 9.5. Setting up a Self-signed Certificate based VPN tunnel for roaming clients

This example describes how to configure an IPsec tunnel at the head office D-Link Firewall for roaming clients
that connect to the office to gain remote access. The head office network uses the 10.0.1.0/24 network span with
external firewall IP wan_ip.

Web Interface

A. Create a Self-signed Certificate for IPsec authentication:

The step to actually create self-signed certificates is performed outside the WebUI using a suitable software
product. The certificate should be in the PEM (Privacy Enhanced Mail) file format.

B. Upload all the client self-signed certificates:

1. Go to Objects > Authentication Objects > Add > Certificate

2. Enter a suitable name for the Certificate object.

3. Select the X.509 Certificate option

4. Click OK

C. Create Identification Lists:

1. Go to Objects > VPN Objects > ID List > Add > ID List

2. Enter a suitable name, eg. sales

3. Click OK

4. Go to Objects > VPN Objects > ID List > Sales > Add > ID

5. Enter the name for the client

6. Select Email as Type

7. In the Email address field, enter the email address selected when you created the certificate on the client

8. Create a new ID for every client that you want to grant access rights according to the instructions above

D. Configure the IPsec tunnel:

1. Go to Interfaces > IPsec > Add > IPsec Tunnel

2. Now enter:

• Name: RoamingIPsecTunnel

• Local Network: 10.0.1.0/24 (This is the local network that the roaming users will connect to)

• Remote Network: all-nets

• Remote Endpoint: (None)

• Encapsulation Mode: Tunnel

255
9.4.3. Roaming Clients Chapter 9. VPN

3. For Algorithms enter:

• IKE Algorithms: Medium or High

• IPsec Algorithms: Medium or High

4. For Authentication enter:

• Choose X.509 Certificate as authentication method

• Root Certificate(s): Select all your client certificates and add them to the Selected list

• Gateway Certificate: Choose your newly created firewall certificate

• Identification List: Select your ID List that you want to associate with your VPN Tunnel. In our case that
will be sales

5. Under the Routing tab:

• Enable the option: Dynamically add route to the remote network when a tunnel is established.

6. Click OK

E. Finally configure the IP rule set to allow traffic inside the tunnel.

9.4.3.3. CA Server issued Certificates based client tunnels

Setting up client tunnels using a Certification Authority issued X.509 certificate is largely the same
as using Self-Signed certificates with the exception of a couple of steps. Most importantly, it is the
responsibility of the administrator to aquire the appropriate certificate from an issuing authority.
With some systems, such as Windows 2000 Server, there is built-in access to a CA server (in
Windows 2000 Server this is found in Certificate Services). For more information on CA server
issued certificates see Section 3.7, “X.509 Certificates”.

It is the responsibility of the administrator to aquire the appropriate certificate from an issuing
authority for client tunnels. With some systems, such as Windows 2000 Server, there is built-in
access to a CA server (in Windows 2000 Server this is found in Certificate Services). For more
information on CA server issued certificates see Section 3.7, “X.509 Certificates”.

Example 9.6. Setting up a CA Server issued Certificate based VPN tunnel for roaming
clients

This example describes how to configure an IPsec tunnel at the head office D-Link Firewall for roaming clients
that connect to the office to gain remote access. The head office network uses the 10.0.1.0/24 network span with
external firewall IP wan_ip.

Web Interface

A. Upload all the client certificates:

1. Go to Objects > Authentication Objects > Add > Certificate

2. Enter a suitable name for the Certificate object.

3. Select the X.509 Certificate option

4. Click OK

B. Create Identification Lists:

1. Go to Objects > VPN Objects > ID List > Add > ID List

2. Enter a descriptive name, eg. sales.

256
9.4.3. Roaming Clients Chapter 9. VPN

3. Click OK

4. Go to Objects > VPN Objects > ID List > Sales > Add > ID

5. Enter the name for the client

6. Select Email as Type

7. In the Email address field, enter the email address selected when you created the certificate on the client

8. Create a new ID for every client that you want to grant access rights according to the instructions above

C. Configure the IPsec tunnel:

1. Go to Interfaces > IPsec > Add > IPsec Tunnel

2. Now enter:

• Name: RoamingIPsecTunnel

• Local Network: 10.0.1.0/24 (This is the local network that the roaming users will connect to)

• Remote Network: all-nets

• Remote Endpoint: (None)

• Encapsulation Mode: Tunnel

3. For Algorithms enter:

• IKE Algorithms: Medium or High

• IPsec Algorithms: Medium or High

4. For Authentication enter:

• Choose X.509 Certificate as authentication method

• Root Certificate(s): Select your CA server root certificate imported earlier and add it to the Selected list

• Gateway Certificate: Choose your newly created firewall certificate

• Identification List: Select your ID List that you want to associate with your VPN Tunnel. In our case that
will be sales

5. Under the Routing tab:

• Enable the option: Dynamically add route to the remote network when a tunnel is established

6. Click OK

D. Finally configure the IP rule set to allow traffic inside the tunnel.

9.4.3.4. Using Config Mode

IKE Configuration Mode (Config Mode) is an extension to IKE that allows NetDefendOS to
provide LAN configuration information to remote VPN clients. It is used to dynamically configure
IPsec clients with IP addresses and corresponding netmasks, and to exchange other types of
information associated with DHCP. The IP address provided to a client can be either be based on a
range of predefined static IP addresses defined for Config Mode or it can come from DHCP servers
associated with an IP Pool object.

An IP pool is a cache of IP addresses collected from DHCP servers and leases on these addresses are
automatically renewed when the lease time is about to expire. IP Pools also manage additional
information such as DNS and WINS/NBNS, just as an ordinary DHCP server would. (For detailed
information on pools see Section 5.5, “IP Pools”.)

Defining the Config Mode Object

257
9.4.3. Roaming Clients Chapter 9. VPN

Currently only one Config Mode object can be defined in NetDefendOS and this is referred to as the
Config Mode Pool object. The key parameters associated with it are as follows:

Use Pre-defined IP Pool Object The IP Pool object that provides the IP addresses.

Use a Static Pool As an alternative to using an IP Pool, a static set of IP

addresses can be defined.

DNS The IP address of the DNS used for URL resolution (already
provided by an IP Pool).

NBNS/WINS The IP address for NBNS/WINS resolution (already provided

by an IP Pool).

DHCP Instructs the host to send any internal DHCP requests to this
address.

Subnets A list of the subnets that the client can access.

Example 9.7. Setting Up Config Mode

In this example the Config Mode Pool object is enabled by associating with it an already configured IP Pool object
called ip_pool1

Web Interface

1. Go to Objects > VPN Objects > IKE Config Mode Pool

2. The Config Mode Pool object properties web page now appears

3. Select Use a pre-defined IPPool object

4. Choose the ip_pool1 object from the IP Pool drop-down list

5. Click OK

After defining the Config Mode object, the only remaining action is to enable Config Mode to be
used with the IPsec Tunnel.

Example 9.8. Using Config Mode with IPsec Tunnels

Assuming a predefined tunnel called vpn_tunnel1 this example shows how to enable Config Mode for that tunnel.

Web Interface

• Go to Interfaces > IPsec

• Select the tunnel vpn_tunnel1 for editing

• Select IKE Config Mode drop down list

• Click OK

IP Validation

NetDefendOS always checks if the source IP address of each packet inside an IPsec tunnel is the
same as the IP address assigned to the IPsec client with IKE Config Mode. If a mismatch is detected
the packet is always dropped and a log message generated with a severity level of Warning. This

258
9.4.4. Fetching CRLs from an alternate Chapter 9. VPN
LDAP server

message includes the two IP addresses as well as the client identity.

Optionally, the affected SA can be automatically deleted if validation fails by enabling the advanced
setting IPsecDeleteSAOnIPValidationFailure. The default value for this setting is Disabled.

9.4.4. Fetching CRLs from an alternate LDAP server

An X.509 root certificate usually includes the IP address or hostname of the Certificate Authority to
contact when certificates or Certificate Revocation Lists need to be downloaded to the D-Link
Firewall. Lightweight Directory Access Protocol (LDAP) is used for these downloads.

However, in some scenarios, this information is missing, or the administrator wishes to use another
LDAP server. The LDAP configuration section can then be used to manually specify alternate
LDAP servers.

Example 9.9. Setting up an LDAP server

This example shows how to manually setup and specify a LDAP server.

CLI

gw-world:/> add LDAPServer Host=192.168.101.146 Username=myusername

Password=mypassword Port=389

Web Interface

1. Go to Objects > VPN Objects > LDAP > Add > LDAP Server

2. Now enter:

• IP Address: 192.168.101.146

• Username: myusername

• Password: mypassword

• Confirm Password: mypassword

• Port: 389

3. Click OK

259
9.5. PPTP/L2TP Chapter 9. VPN

9.5. PPTP/L2TP
The access by a client using a modem link over dial-up public switched networks, possibly with an
unpredictable IP address, to protected networks via a VPN poses particular problems. Both the
PPTP and L2TP protocols provide two different means of achieving VPN access from remote
clients.

9.5.1. PPTP
Overview

Point to Point Tunneling Protocol (PPTP) is designed by the PPTP Forum, a consortium of
companies that includes Microsoft. It is an OSI layer 2 "data-link" protocol (see Appendix D, The
OSI Framework) and is an extension of the older Point to Point Protocol (PPP), used for dial-up
Internet access. It was one of the first protocols designed to offer VPN access to remote servers via
dial-up networks and is still widely used.

Implementation

PPTP can be used in the VPN context to tunnel different protocols across the Internet. Tunneling is
achieved by encapsulating PPP packets in IP datagrams using Generic Routing Encapsulation (GRE
- IP protocol 47). The client first establishes a connection to an ISP in the normal way using the PPP
protocol and then establishes a TCP/IP connection across the Internet to the D-Link Firewall, which
acts as the PPTP server (TCP port 1723 is used). The ISP is not aware of the VPN since the tunnel
extends from the PPTP server to the client. The PPTP standard does not define how data is
encrypted. Encryption is usually achieved using the Microsoft Point-to-Point Encryption (MPPE)
standard.

Deployment

PPTP offers a convenient solution to client access that is simple to deploy. PPTP doesn't require the
certificate infrastructure found in L2TP but instead relies on a username/password sequence to
establish trust between client and server. The level of security offered by a non-certificate based
solution is arguably one of PPTP's drawbacks. PPTP also presents some scalability issues with some
PPTP servers restricting the number of simultaneous PPTP clients. Since PPTP doesn't use IPsec,
PPTP connections can be NATed and NAT traversal is not required. PPTP has been bundled by
Microsoft in its operating systems since Windows95 and therefore has a large number of clients
with the software already installed.

Troubleshooting PPTP

A common problem with setting up PPTP is that a router and/or switch in a network is blocking
TCP port 1723 and/or IP protocol 47 before the PPTP connection can be made to the D-Link
Firewall. Examining the log can indicate if this problem occurred, with a log message of the
following form appearing:

Error PPP lcp_negotiation_stalled ppp_terminated

Example 9.10. Setting up a PPTP server

This example shows how to setup a PPTP Network Server. The example assumes that you have already created
certain address objects in the Address Book.

You will have to specify the IP address of the PPTP server interface, an outer IP address (that the PPTP server
should listen to) and an IP pool that the PPTP server will use to give out IP addresses to the clients from.

CLI

260
9.5.2. L2TP Chapter 9. VPN

gw-world:/> add Interface L2TPServer MyPPTPServer ServerIP=lan_ip Interface=any

IP=wan_ip IPPool=pp2p_Pool TunnelProtocol=PPTP AllowedRoutes=all-nets

Web Interface

1. Go to Interfaces > L2TP Servers > Add > L2TPServer

2. Enter a name for the PPTP Server eg. MyPPTPServer.

3. Now enter:

• Inner IP Address: lan_ip

• Tunnel Protocol: PPTP

• Outer Interface Filter: any

• Outer Server IP: wan_ip

4. Under the PPP Parameters tab, select pptp_Pool in the IP Pool control

5. Under the Add Route tab, select all_nets from Allowed Networks

6. Click OK

Use User Authentication Rules is enabled as default. To be able to authenticate the users using the PPTP
tunnel you also need to configure authentication rules, which will not be covered in this example.

9.5.2. L2TP
Layer 2 Tunneling protocol (L2TP) is an IETF open standard that overcomes many of the problems
of PPTP. Its design is a combination of Layer 2 Forwarding (L2F) protocol and PPTP, making use
of the best features of both. Since the L2TP standard does not implement encryption , it is usually
implemented with an IETF standard known as L2TP/IPsec, in which L2TP packets are encapsulated
by IPsec. The client communicates with a Local Access Concentrator (LAC) and the LAC
communicates across the Internet with a L2TP Network Server (LNS). The D-Link Firewall acts as
the LNS. The LAC is, in effect, tunneling data, such as a PPP session, using IPsec to the LNS across
the Internet. In most cases the client will itself act as the LAC.

L2TP is certificate based and therefore is simpler to administer with a large number of clients and
arguably offers better security than PPTP. Unlike PPTP, it is possible to set up multiple virtual
networks across a single tunnel. Being IPsec based, L2TP requires NAT traversal (NAT-T) to be
implemented on the LNS side of the tunnel.

Example 9.11. Setting up an L2TP server

This example shows how to setup a L2TP Network Server. The example presumes that you have created some
address objects in the Address Book. You will have to specify the IP address of the L2TP server interface, an
outer IP address (that the L2TP server should listen to) and an IP pool that the L2TP server will use to give out IP
addresses to the clients from. The interface that the L2TP server will accept connections on is a virtual IPsec
tunnel, not illustrated in this example.

CLI

gw-world:/> add Interface L2TPServer MyL2TPServer ServerIP=ip_l2tp

Interface=l2tp_ipsec IP=wan_ip IPPool=L2TP_Pool TunnelProtocol=L2TP
AllowedRoutes=all-nets

Web Interface

1. Go to Interfaces > L2TP Servers > Add > L2TPServer

2. Enter a suitable name for the L2TP Server, eg. MyL2TPServer

261
9.5.2. L2TP Chapter 9. VPN

3. Now enter:

• Inner IP Address: ip_l2tp

• Tunnel Protocol: L2TP

• Outer Interface Filter: l2tp_ipsec

• Outer Server IP: wan_ip

4. Under the PPP Parameters tab, select L2TP_Pool in the IP Pool control

5. Under the Add Route tab, select all_nets in the Allowed Networks control

6. Click OK

Use User Authentication Rules is enabled as default. To be able to authenticate the users using the PPTP
tunnel you also need to configure authentication rules, which is not covered in this example.

Example 9.12. Setting up an L2TP Tunnel

This example shows how to setup a fully working L2TP Tunnel and will cover many parts of basic VPN
configuration. Before starting, you need to configure some address objects, for example the network that is going
to be assigned to the L2TP clients. Proposal lists and PSK are needed as well. Here we will use the objects
created in previous examples.

To be able to authenticate the users using the L2TP tunnel a local user database will be used.

A. Start by preparing a new Local User Database:

CLI

gw-world:/> add LocalUserDatabase UserDB

gw-world:/> cc LocalUserDatabase UserDB

gw-world:/UserDB> add User testuser Password=mypassword

Web Interface

1. Go to User Authentication > Local User Databases > Add > Local User Database

2. Enter a suitable for the user database, for instance UserDB

3. Go to User Authentication > Local User Databases > UserDB > Add > User

4. Now enter:

• Username: testuser

• Password: mypassword

• Confirm Password: mypassword

5. Click OK

Now we will setup the IPsec Tunnel, which will later be used in the L2TP section. As we are going to use L2TP,
the Local Network is the same IP the L2TP tunnel will connect to, wan_ip. Furthermore, the IPsec tunnel needs to
be configured to dynamically add routes to the remote network when the tunnel is established.

B. Continue setting up the IPsec Tunnel:

CLI

gw-world:/> add Interface IPsecTunnel l2tp_ipsec LocalNetwork=wan_ip

RemoteNetwork=all-nets IKEAlgorithms=ike-roamingclients
IPsecAlgorithms=esp-l2tptunnel PSK=MyPSK EncapsulationMode=Transport

262
9.5.2. L2TP Chapter 9. VPN

DHCPOverIPsec=Yes AddRouteToRemoteNet=Yes IPsecLifeTimeKilobytes=250000

IPsecLifeTimeSeconds=3600

Web Interface

1. Go to Interfaces > IPsec > Add > IPsec Tunnel

2. Enter a name for the IPsec tunnel, eg. l2tp_ipsec

3. Now enter:

a. Local Network: wan_ip

b. Remote Network: all-nets

c. Remote Endpoint: none

d. Encapsulation Mode: Transport

e. IKE Proposal List: ike-roamingclients

f. IPsec Proposal List: esp-l2tptunnel

4. Enter 3600 in the IPsec Life Time seconds control

5. Enter 250000 in the IPsec Life Time kilobytes control

6. Under the Authentication tab, select Pre-shared Key

7. Select MyPSK in the Pre-shared Key control

8. Under the Routing tab, check the following controls:

• Allow DHCP over IPsec from single-host clients

• Dynamically add route to the remote network when a tunnel is established

9. Click OK

Now it is time to setup the L2TP Server. The inner IP address should be a part of the network which the clients
are assigned IP addresses from, in this lan_ip. The outer interface filter is the interface that the L2TP server will
accept connections on, this will be the earlier created l2tp_ipsec. Also a ProxyARP needs to be configured for the
IP's used by the L2TP Clients.

C. Setup the L2TP Tunnel:

CLI

gw-world:/> add Interface L2TPServer l2tp_tunnel IP=lan_ip Interface=l2tp_ipsec

ServerIP=wan_ip IPPool=l2tp_pool TunnelProtocol=L2TP
AllowedRoutes=all-nets ProxyARPInterfaces=lan

Web Interface

1. Go to Interfaces > L2TP Servers > Add > L2TPServer

2. Enter a name for the L2TP tunnel, eg. l2tp_tunnel

3. Now enter:

• Inner IP Address: lan_ip

• Tunnel Protocol: L2TP

• Outer Interface Filter: l2tp_ipsec

• Server IP: wan_ip

4. Under the PPP Parameters tab, check the Use User Authentication Rules control

5. Select l2tp_pool in the IP Pool control

6. Under the Add Route tab, select all-nets in the Allowed Networks control.

263
9.5.2. L2TP Chapter 9. VPN

7. In the ProxyARP control, select the lan interface.

8. Click OK

In order to authenticate the users using the L2TP tunnel, a user authentication rule needs to be configured.

D. Next will be setting up the authentication rules:

CLI

gw-world:/> add UserAuthRule AuthSource=Local Interface=l2tp_tunnel

OriginatorIP=all-nets LocalUserDB=UserDB agent=PPP TerminatorIP=wan_ip
name=L2TP_Auth

Web Interface

1. Go to User Authentication > User Authentication Rules > Add > UserAuthRule

2. Enter a suitable name for the rule, eg. L2TP_Auth

3. Now enter:

• Agent: PPP

• Authentication Source: Local

• Interface: l2tp_tunnel

• Originator IP: all-nets

• Terminator IP: wan_ip

4. Under the Authentication Options tab enter UserDB as the Local User DB

5. Click OK

When the other parts are done, all that is left is the rules. To let traffic through from the tunnel, two IP rules should
be added.

E. Finally, set up the rules:

CLI

gw-world:/> add IPRule action=Allow Service=all_services

SourceInterface=l2tp_tunnel SourceNetwork=l2tp_pool
DestinationInterface=any DestinationNetwork=all-nets name=AllowL2TP

gw-world:/> add IPRule action=NAT Service=all_services

SourceInterface=l2tp_tunnel SourceNetwork=l2tp_pool
DestinationInterface=any DestinationNetwork=all-nets name=NATL2TP

Web Interface

1. Go to Rules > IP Rules > Add > IPRule

2. Enter a name for the rule, eg. AllowL2TP

3. Now enter:

• Action: Allow

• Service: all_services

• Source Interface: l2tp_tunnel

• Source Network: l2tp_pool

• Destination Interface: any

• Destination Network: all-nets

264
9.5.2. L2TP Chapter 9. VPN

4. Click OK

5. Go to Rules > IP Rules > Add > IPRule

6. Enter a name for the rule, eg. NATL2TP

7. Now enter:

• Action: NAT

• Service: all_services

• Source Interface: l2tp_tunnel

• Source Network: l2tp_pool

• Destination Interface: any

• Destination Network: all-nets

8. Click OK

265
9.5.2. L2TP Chapter 9. VPN

266