VPN > Settings

The VPN > Settings page provides the features for configuring your VPN policies. You can configure site-to-site VPN policies and GroupVPN policies from this page.

Topics:

•	VPN Overview

•	Configuring VPNs in SonicOS

•	Configuring VPNs for IPv6

•	Configuring GroupVPN Policies

•	Site-to-Site VPN Configurations

•	Creating Site-to-Site VPN Policies

•	Route Based VPN

•	Redundant Static Routes for a Network

•	Drop Tunnel Interface

•	VPN Auto-Added Access Rule Control

VPN Overview

A Virtual Private Network (VPN) provides a secure connection between two or more computers or protected networks over the public Internet. It provides authentication to ensure that the information is going to and from the correct parties. It provides security to protect the information from viewing or tampering en route.

Prior to the invention of Internet Protocol Security (IPsec) and Secure Socket Layer (SSL), secure connections between remote computers or networks required a dedicated line or satellite link. This was both inflexible and expensive.

A VPN creates a connection with similar reliability and security by establishing a secure tunnel through the Internet. Because this tunnel is not a physical connection, it is more flexible--you can change it at any time to add more nodes, change the nodes, or remove it altogether. It is also far less costly, because it uses the existing Internet infrastructure.

Topics:

•

VPN Types

•	VPN Security

VPN Types

There are two main types of VPN in popular use today:

•	IPsec VPN: IPsec is a set of protocols for security at the packet processing layer of network communication. An advantage of IPsec is that security arrangements can be handled without requiring changes to individual user computers. SonicOS supports the creation and management of IPsec VPNs.

IPsec provides two choices of security service: Authentication Header (AH), which essentially allows authentication of the sender of data, and Encapsulating Security Payload (ESP), which supports both authentication of the sender and encryption of data as well. The specific information associated with each of these services is inserted into the packet in a header that follows the IP packet header.

•

SSL VPN: Secure Socket Layer (SSL) is a protocol for managing the security of a message transmission on the Internet, usually by HTTPS. SSL uses a program layer located between the Internet's Hypertext Transfer Protocol (HTTP) and Transport Control Protocol (TCP) layers. SSL uses the public-and-private key encryption system from RSA, which also includes the use of a digital certificate. An SSL VPN uses SSL to secure the VPN tunnel.

One advantage of SSL VPN is that SSL is built into most Web Browsers. No special VPN client software or hardware is required.

NOTE: Dell SonicWALL makes SSL VPN devices that you can use in concert with or independently of a Dell SonicWALL network security appliance running SonicOS. For information on Dell SonicWALL SSL VPN appliances, see the Dell SonicWALL Website: http://www.sonicwall.com/us/products.html.

VPN Security

IPsec VPN traffic is secured in two stages:

•	Authentication: The first phase establishes the authenticity of the sender and receiver of the traffic using an exchange of the public key portion of a public-private key pair. This phase must be successful before the VPN tunnel can be established.

•	Encryption: The traffic in the VPN tunnel is encrypted, using an encryption algorithm such as AES or 3DES.

Unless you use a manual key (which must be typed identically into each node in the VPN) The exchange of information to authenticate the members of the VPN and encrypt/decrypt the data uses the Internet Key Exchange (IKE) protocol for exchanging authentication information (keys) and establishing the VPN tunnel. SonicOS supports two versions of IKE, version 1 and version 2.

Topics:

•	IKE version 1

•	IKE version 2

IKE version 1

IKE version 1 uses a two phase process to secure the VPN tunnel.

•	IKE Phase 1 is the authentication phase. The nodes or gateways on either end of the tunnel authenticate with each other, exchange encryption/decryption keys, and establish the secure tunnel.

•

IKE Phase 2 is the negotiation phase. Once authenticated, the two nodes or gateways negotiate the methods of encryption and data verification (using a hash function) to be used on the data passed through the VPN and negotiate the number of secure associations (SAs) in the tunnel and their lifetime before requiring renegotiation of the encryption/decryption keys.

Topics:

•	IKE Phase 1

•	IKE Phase 2

IKE Phase 1

In IKE v1, there are two modes of exchanging authentication information:

•	Main Mode: The node or gateway initiating the VPN queries the node or gateway on the receiving end, and they exchange authentication methods, public keys, and identity information. This usually requires six messages back and forth. The order of authentication messages in Main Mode is:

1	The initiator sends a list of cryptographic algorithms the initiator supports.

2	The responder replies with a list of supported cryptographic algorithms.

3	The initiator send a public key (part of a Diffie-Hellman public/private key pair) for the first mutually supported cryptographic algorithm.

4	The responder replies with the public key for the same cryptographic algorithm.

5	The initiator sends identity information (usually a certificate).

6	The responder replies with identity information.

•	Aggressive Mode: To reduce the number of messages exchanged during authentication by half, the negotiation of which cryptographic algorithm to use is eliminated. The initiator proposes one algorithm and the responder replies if it supports that algorithm:

1	The initiator proposes a cryptographic algorithm to use and sends its public key.

2	The responder replies with a public key and identity proof.

3	The initiator sends an identification proof. After authenticating, the VPN tunnel is established with two SAs, one from each node to the other.

IKE Phase 2

In IKE phase 2, the two parties negotiate the type of security to use, which encryption methods to use for the traffic through the tunnel (if needed), and negotiate the lifetime of the tunnel before re-keying is needed.

The two types of security for individual packets are:

•	Encryption Secured Payload (ESP), in which the data portion of each packet is encrypted using a protocol negotiated between the parties.

•	Authentication Header (AH), in which the header of each packet contains authentication information to ensure the information is authenticated and has not been tampered with. No encryption is used for the data with AH.

SonicOS supports the following encryption methods for Traffic through the VPN.

•

DES

•

3DES

•

AES-128

•

AES-192

•

AES-256

You can find more information about IKE v1 in the three specifications that define initially define IKE, RFC 2407, RFC 2408, and RFC 2409, available on the Web at:

•	http://www.faqs.org/rfcs/rfc2407.html

•	http://www.faqs.org/rfcs/rfc2408.html

•	http://www.faqs.org/rfcs/rfc2409.html

IKE version 2

IKE version 2 is a newer protocol for negotiating and establishing security associations. IKEv2 features improved security, a simplified architecture, and enhanced support for remote users.

IKEv2 is the default proposal type for new VPN policies.

Secondary gateways are supported with IKEv2.

IKEv2 is not compatible with IKE v1. When using IKEv2, all nodes in the VPN must use IKEv2 to establish the tunnels.

DHCP over VPN is not supported in IKEv2.

IKEv2 has the following advantages over IKEv1:

•	More secure

•	More reliable

•

Simpler

•

Faster

•	Extensible

•	Fewer message exchanges to establish connections

•	EAP Authentication support

•	MOBIKE support

•	Built-in NAT traversal

•	Keep Alive is enabled as default

IKEv2 supports IP address allocation and EAP to enable different authentication methods and remote access scenarios. Using IKEv2 greatly reduces the number of message exchanges needed to establish an SA over IKE v1 Main Mode, while being more secure and flexible than IKE v1 Aggressive Mode. This reduces the delays during re-keying. As VPNS grow to include more and more tunnels between multiple nodes or gateways, IKEv2 reduces the number of SAs required per tunnel, thus reducing required bandwidth and housekeeping overhead.

SAs in IKEv2 are called Child SAs and can be created, modified, and deleted independently at any time during the life of the VPN tunnel.

Topics:

•	Initialization and Authentication in IKE v2

•	Negotiating SAs in IKE v2

•	IKEv2 Mobility and Multi-homing Protocol

Initialization and Authentication in IKE v2

IKE v2 initializes a VPN tunnel with a pair of message exchanges (two message/response pairs).

•	Initialize communication: The first pair of messages (IKE_SA_INIT) negotiate cryptographic algorithms, exchange nonces (random values generated and sent to guard against repeated messages), and perform a public key exchange.

a	Initiator sends a list of supported cryptographic algorithms, public keys, and a nonce.

b	Responder sends the selected cryptographic algorithm, the public key, a nonce, and an authentication request.

•

Authenticate: The second pair of messages (IKE_AUTH) authenticate the previous messages, exchange identities and certificates, and establish the first CHILD_SA. Parts of these messages are encrypted and integrity protected with keys established through the IKE_SA_INIT exchange, so the identities are hidden from eavesdroppers and all fields in all the messages are authenticated.

a	Initiator sends identity proof, such as a shared secret or a certificate, and a request to establish a child SA.

b	Responder sends the matching identity proof and completes negotiation of a child SA.

Negotiating SAs in IKE v2

This exchange consists of a single request/response pair, and was referred to as a phase 2 exchange in IKE v1. It may be initiated by either end of the SA after the initial exchanges are completed.

All messages following the initial exchange are cryptographically protected using the cryptographic algorithms and keys negotiated in the first two messages of the IKE exchange.

Either endpoint may initiate a CREATE_CHILD_SA exchange, so in this section the term “initiator” refers to the endpoint initiating this exchange.

1	Initiator sends a child SA offer and, if the data is to be encrypted, the encryption method and the public key.

2	Responder sends the accepted child SA offer and, if encryption information was included, a public key.

NOTE: You can find more information about IKE v2 in the specification, RFC 4306, available on the Web at: http://www.ietf.org/rfc/rfc4306.txt.

For information on configuring VPNs in SonicOS, see:

•	Configuring VPNs in SonicOS

•	Configuring VPNs for IPv6

•	Configuring GroupVPN Policies

•	Site-to-Site VPN Configurations

•	Creating Site-to-Site VPN Policies

•	VPN Auto-Added Access Rule Control

IKEv2 Mobility and Multi-homing Protocol

The IKEv2 Mobility and Multi-homing Protocol (MOBIKE) provides the ability for maintaining a VPN session when a user moves from one IP address to another without the need for reestablishing IKE security associations with the gateway. For example, a user could establish a VPN tunnel while using a fixed Ethernet connection in the office. MOBIKE allows the user to disconnect the laptop and move to the office's wireless LAN without interrupting the VPN session.

MOBIKE operation is transparent and does not require any extra configuration by you or consideration by users.