VPN_vpnSettingsView
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.
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.
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 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
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:
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 sends a list of cryptographic algorithms the initiator supports.
The responder replies with a list of supported cryptographic algorithms.
The initiator send a public key (part of a Diffie-Hellman public/private key pair) for the first mutually supported cryptographic algorithm.
The responder replies with the public key for the same cryptographic algorithm.
The initiator sends identity information (usually a certificate).
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:
The initiator proposes a cryptographic algorithm to use and sends its public key.
The responder replies with a public key and identity proof.
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:
IKE version 2 is a new protocol for negotiating and establishing SAs. IKEv2 features improved security, a simplified architecture, and enhanced support for remote users. In addition, 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.
IKEv2 is not compatible with IKE v1. If using IKEv2, all nodes in the VPN must use IKEv2 to establish the tunnels.
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.
Initialization and Authentication in IKEv2
IKEv2 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.
Initiator sends a list of supported cryptographic algorithms, public keys, and a nonce.
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.
Responder sends the matching identity proof and completes negotiation of a child SA.
Negotiating SAs in IKEv2
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.
Responder sends the accepted child SA offer and, if encryption information was included, a public key.
The IKEv2 configuration payload (CP) allows the VPN server to dynamically assign IP addresses to remote clients. The client and server exchange information, similar to a DHCP negotiation as if the client was directly connected to a LAN.
When IKEv2 is selected as the exchange method for the IKE phase 1 proposal, the administrator can choose to assign the client an IP address from the IKEv2 IP address pool.
IKEv2 configuration payloads are intended for relatively small-scale deployments.
When used with SonicWALL appliances, the Windows 7 IKEv2 client must use third party certificates as the authentication method. The certificates installed on the remote access server should have the following values:
Common Name (CN): This field must contain the fully qualified DNS name or IP address of the remote access server. If the server is located behind a network address translating (NAT) router, then the certificate must contain the fully qualified DNS name or IP address of the external connection of the NAT router (the address that the client computer sees as the address of the server).
EKU: This field must includes Server Authentication. If there is more than one server authentication certificate, additionally include the IP security IKE intermediate EKU. Only one certificate should have both EKU options, otherwise IPsec cannot determine which certificate to use, and might not pick the certificate you intended. For more information, see:
http://technet.microsoft.com/en-us/library/dd941612(WS.10).aspx
Note You can find more information about IKEv2 in the specification, RFC 4306, available on the Web at: http://www.ietf.org/rfc/rfc4306.txt