SonicOS 7.1 IPSec VPN
- SonicOS 7.1
- About SonicOS
- IPSec VPN Overview
- Site to Site VPNs
- VPN Auto Provisioning
- Rules and Settings
- Advanced
- DHCP over VPN
- L2TP Servers and VPN Client Access
- AWS VPN
- SonicWall Support
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:
IKE version 1 (IKEv1) | Uses a two phase process to secure the VPN tunnel. First, the two nodes authenticate each other and then they negotiate the methods of encryption. |
You can find more information about IKEv1 in the three specifications that initially define IKE: RFC 2407, RFC 2408, and RFC 2409. They are available on the web at:
|
|
IKE version 2 (IKEv2) | Is the default type for new VPN policies because of improved security, simplified architecture, and enhanced support for remote users. A VPN tunnel is initiated with a pair of message exchanges. The first pair of messages negotiate cryptographic algorithms, exchange nonces (random values generated and sent to guard against repeated messages), and perform a public key exchange. The second pair of messages authenticates the previous messages, exchange identities and certificates, and establish the first CHILD_SA (security association). Parts of these messages are encrypted and integrity protected with keys established through the first exchange, so the identities are hidden from eavesdroppers and all fields in all the messages are authenticated. |
You can find more information about IKEv2 in the specification, RFC 4306, available on the Web at: http://www.ietf.org/rfc/rfc4306.txt. |
IKEv2 is not compatible with IKEv1. When using IKEv2, all nodes in the VPN must use IKEv2 to establish the tunnels.
DHCP over VPN is not supported in IKEv2.
For more VPN security information, see:
- About IKEv1
- About IKEv2
- Mobility and Multi-homing Protocol for IKEv2 (MOBIKE)
- About IPsec (Phase 2) Proposal
- About Suite B Cryptography
Was This Article Helpful?
Help us to improve our support portal