D-Link DFL-1600 - Security Appliance, User Manual

Page: 399 / 552

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 initially agree a shared secret
between the two parties in the negotiation and to derive keys for encryption.
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 2, another negotiation is performed, detailing the parameters for the IPsec connection.
During phase 2 we will also extract new keying material from the Diffie-Hellman key exchange in
phase 1 in order to provide session keys to use in protecting the VPN data flow.
If Perfect Forwarding Secrecy (PFS) 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 traffic to
pass through it.
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
strongly recommended, since it is of great importance that both endpoints are able to agree on all of
these parameters.
With two NetDefend Firewalls as VPN endpoints, the matching process is greatly simplified since
the default NetDefendOS configuration parameters will be the same at either end. However, it may
not be as straightforward when equipment from different vendors is involved in establishing the
VPN tunnel.
Endpoint Identification The Local ID is a piece of data representing the identity of the
VPN tunnel endpoint. With Pre-Shared Keys this is a unique
piece of data uniquely identifying the endpoint.
Authentication using Pre-Shared Keys is based on the
Diffie-Hellman algorithm.
Local and Remote
Networks/Hosts These are the subnets or hosts between which IP traffic will
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
9.3.2. Internet Key Exchange (IKE) Chapter 9. VPN
399