VPN_vpnSettingsView
VPN > Settings
The VPN > Settings page provides the SonicWALL features for configuring your VPN policies. You can configure site-to-site VPN policies and GroupVPN policies from this page.
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.
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.
|
|
|
SonicWALL makes SSL VPN devices that you can use in concert with or independently of a SonicWALL UTM appliance running SonicOS. For information on SonicWALL SSL VPN appliances, see the SonicWALL Website: http://www.sonicwall.com/us/products/Secure_Remote_Access.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 Enhanced supports two versions of IKE, version 1 and 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. |
IKE Phase 1
In IKE v1, there are two modes of exchanging authentication information: Main Mode and Aggressive Mode.
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:
|
|
The initiator send a public key (part of a Diffie-Hellman public/private key pair) for the first mutually supported cryptographic algorithm. |
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:
|
|
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:
IKEv2
IKE version 2 is a new protocol for negotiating and establishing SAs. IKE v2 features improved security, a simplified architecture, and enhanced support for remote users. In addition, IKE v2 supports IP address allocation and EAP to enable different authentication methods and remote access scenarios. Using IKE V2 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, IKE v2 reduces the number of SAs required per tunnel, thus reducing required bandwidth and housekeeping overhead.
IKE v2 is not compatible with IKE v1. If using IKE v2, all nodes in the VPN must use IKE v2 to establish the tunnels.
SAs in IKE v2 are called Child SAs and can be created, modified, and deleted independently at any time during the life of the VPN tunnel.
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. |
|
|
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. |
|
|
Initiator sends identity proof, such as a shared secret or a certificate, and a request to establish 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.
|
|
Initiator sends a child SA offer and, if the data is to be encrypted, the encryption method and the public key. |