en-US
search-icon

SonicOS 6.2 Admin Guide

VPN

Configuring VPN Policies

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. The VPN > Settings page also displays a table of currently active VPN tunnels.

Topics:  

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.

* 
NOTE: Besides VPN tunnel interfaces, SonicOS supports:
WLAN tunnel interfaces (for more information on configuring WLAN interfaces, see Configuring Wireless Interfaces).
IPv6-to-IPv4 tunnel interfaces (for more information on configuring these interfaces, see Configuring IPv6 Tunnel Interfaces).
Topics:  

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.
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 SRA/SMA appliance 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 SRA/SMA appliances you can use in concert with or independently of a SonicWall network security appliance running SonicOS.

For information on SonicWall SRA/SMA appliances, see the SonicWall Secure Mobile Access Products website.

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

IKE version 1 (IKEv1) 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

In IKEv1, 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
AES-128
3DES
AES-192

 

AES-256

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

http://www.faqs.org/rfcs/rfc2407.htmlThe Internet IP Security Domain of Interpretation for ISAKMP
http://www.faqs.org/rfcs/rfc2408.htmlRFC 2408 - Internet Security Association and Key Management Protocol (ISAKMP)
http://www.faqs.org/rfcs/rfc2409.htmlRFC 2409 - The Internet Key Exchange (IKE)
IKE version 2

IKE version 2 (IKEv2) is a newer protocol for negotiating and establishing security associations. IKEv2 features improved security, a simplified architecture, and enhanced support for remote users. Secondary gateways are supported with IKEv2.

IKEv2 is the default proposal type for new VPN policies.

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.

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 IKEv1 Main Mode, while being more secure and flexible than IKEv1 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 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.
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 IKEv2

This exchange consists of a single request/response pair, and was referred to as a phase 2 exchange in IKEv1. 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 IKEv2 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:

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.

VPN Auto Provisioning

The VPN Auto Provisioning feature greatly simplifies the provisioning of site‐to‐site VPNs between two SonicWall firewalls. Most of the configuration is done on one of the firewalls, while virtually no configuration is needed on the other unit. This is especially useful in large deployments with hub‐and‐spoke VPN configurations.

The obvious benefit of the VPN Auto Provisioning feature is ease of use. This is accomplished by hiding the complexity of initial configuration, similar to the provisioning process of the SonicWall Global VPN Client (GVC). An added advantage is that after the initial VPN auto provisioning, policy changes can be controlled at the central gateway and updated automatically at the spoke end.

For further information about VPN Auto Provisioning, see VPN Auto Provisioning.

VPN Settings and Displays

Topics:  

VPN Global Settings

The Global VPN Settings section of the VPN > Settings page displays the following information:

Enable VPN – Must be selected to allow VPN policies through the SonicWall security policies.
Unique Firewall Identifier - An identifier for this SonicWall appliance used for configuring VPN tunnels. The default value is the serial number of the firewall. You can change the Identifier to something meaningful to you.

VPN Policies

All existing VPN policies are displayed in the VPN Policies table. Each entry displays the following information:

Name – The default name or user-defined VPN policy name.
Gateway – The IP address of the remote firewall. If the wildcard IP address, 0.0.0.0, is used, it is displayed as the IP address.
Destinations – The IP addresses of the destination networks.
Crypto Suite – The type of encryption used for the VPN policy.
Enable – Whether the policy is enabled. Selecting the checkbox enables the VPN Policy. Clearing the checkbox disables it.
Configure
For all VPN policies, displays an Edit icon. Clicking the Edit icon allows you to edit the VPN policy.
For added VPN policies, a Delete icon. Clicking the Delete icon deletes the VPN policy. The predefined GroupVPN policies cannot be deleted, so the Delete icons are dimmed.
For GroupVPN policies, an Export icon. Clicking the Export icon exports the VPN policy configuration as a file for local installation by SonicWall Global VPN Clients.

Below the VPN Policies table are the following buttons:

Add - Accesses the VPN Policy window to configure site-to-site VPN policies.
Delete - Deletes the selected (checked box before the VPN policy name in the Name column). You cannot delete the GroupVPN policies.
Delete All - Deletes all VPN policies in the VPN Policies table except the default GroupVPN policies.

Also below the table, for both site-to-site and GroupVPN policies, is displayed the:

Number of VPN policies defined.
Number of policies enabled.
Maximum number of policies allowed.

You can define up to four GroupVPN policies, one for each zone. These GroupVPN policies are listed by default in the VPN Policies table as WAN GroupVPN, LAN GroupVPN, DMZ GroupVPN, and WLAN GroupVPN. Clicking on the Edit icon in the Configure column for the GroupVPN displays the VPN Policy dialog for configuring the GroupVPN policy.

* 
NOTE: A VPN Policy cannot have two different WAN interfaces if the VPN Gateway IP is the same.

Currently Active VPN Tunnels

A list of currently active VPN tunnels is displayed in this section.

Click the Renegotiate button to force the VPN Client to renegotiate the VPN tunnel.

Viewing VPN Tunnel Statistics

The Currently Active VPN Tunnels table displays these statistics for each tunnel:

Created – The date and time the tunnel came into existence.
Name – The name of the VPN Policy.
Local – The local LAN IP address of the tunnel.
Remote – The remote destination network IP address.
Gateway – The peer gateway IP address.
Statistics icon – When moused over, displays the VPN Tunnel Statistics pop-up balloon with the time stamps for the active tunnel and the number of packets/bytes/fragments sent into/out of the tunnel:

Left-arrow icon – When moused over, displays, for that particular active tunnel, the respective VPN policy in the middle of the VPN Policies table. If the VPN Policies table spans several pages, you can see the relevant VPN policy quickly rather than scrolling through the table to find the right one.

Configuring VPNs in SonicOS

SonicWall VPN, based on the industry-standard IPsec VPN implementation, provides a easy-to-setup, secure solution for connecting mobile users, telecommuters, remote offices and partners via the Internet. Mobile users, telecommuters, and other remote users with broadband (DSL or cable) or dialup Internet access can securely and easily access your network resources with the SonicWall Global VPN Client and GroupVPN on your firewall. Remote office networks can securely connect to your network using site-to-site VPN connections that enable network-to-network VPN connections.

The GroupVPN feature provides automatic VPN policy provisioning for Global VPN Clients. The GroupVPN feature on the SonicWall network security appliance and the Global VPN Client dramatically streamlines VPN deployment and management. Using the Client Policy Provisioning technology, you define the VPN policies for Global VPN Client users. This policy information downloads automatically from the firewall (VPN Gateway) to Global VPN Clients, saving remote users the burden of provisioning VPN connections.

You can configure GroupVPN or site-to-site VPN tunnels on the VPN > Settings page. The maximum number of policies you can add depends on your SonicWall model.

* 
NOTE: Remote users must be explicitly granted access to network resources on the Users > Local Users or Users > Local Groups page. When configuring local users or local groups, the VPN Access tab not only affects the ability of remote clients using GVC to connect to GroupVPN, but it also affects remote users using NetExtender and SSL VPN Virtual Office bookmarks to access network resources. To allow GVC, NetExtender, or Virtual Office users to access a network resource, the network address objects or groups must be added to the allow list on the VPN Access tab.
Topics:  

Configuring VPNs for IPv6

For complete information on the SonicOS implementation of IPv6, see IPv6.

IPSec VPNs can be configured for IPv6 in a similar manner to IPv4 VPNs after selecting the IPv6 option in the View IP Version radio button at the top right of the VPN Policies section.

There are certain VPN features that are currently not supported for IPv6, including:

IKEv2 is supported, while IKEv1 is currently not supported
GroupVPN is not supported
DHCP Over VPN is not supported.
L2TP Server is not supported.
Auto Provisioning is not supported.
Topics:  
General Tab

When configuring an IPv6 VPN policy, on the General tab, the gateways must be configured using IPv6 addresses. FQDN is not supported. When configuring IKE authentication, IPV6 addresses can be used for the local and peer IKE IDs.

* 
NOTE: DHCP Over VPN and L2TP Server are not supported for IPv6.
Network Tab

On the Network tab of the VPN policy, IPV6 address objects (or address groups that contain only IPv6 address objects) must be selected for the Local Networks and Remote Networks.

DHCP Over VPN is not supported, thus the DHCP options for protected network are not available.

The Any address option for Local Networks and the Tunnel All option for Remote Networks are removed. An all-zero IPv6 Network address object could be selected for the same functionality and behavior.

Proposals Tab

On the Proposals tab, the configuration is identical for IPv6 and IPv4, except IPv6 only supports IKEv2 mode.

Advanced Tab

The Advanced tab for IPv6 is similar to that of IPv4, with only these options being IP-version specific:

 

Advanced settings: Options available based on IP version

Option

IP Version

IPv4

IPv6

Enable Multicast

X

 

Enable Keep Alive

 

X

Permit Acceleration

X

 

Suppress automatic Access Rules creation for VPN Policy

 

X

Disable IPsec Anti-Replay

 

X

Using Primary IP Address

 

X

Specify the local gateway IP address

 

X

* 
NOTE: Because an interface may have multiple IPv6 address, sometimes the local address of the tunnel may vary periodically. If a user needs a consistent IP address, configure the VPN policy to be bound to an interface instead of a Zone, and then specify the address manually. The address must be one of the IPv6 addresses for that interface.

Configuring GroupVPN Policies

GroupVPN policies facilitate the set up and deployment of multiple Global VPN Clients by the firewall administrator. GroupVPN is only available for Global VPN Clients and it is recommended you use XAUTH/RADIUS or third party certificates in conjunction with the Group VPN for added security.

From the Network > Zones page, you can create GroupVPN policies for any zones. SonicOS provides two default GroupVPN policies for the WAN and WLAN zones, as these are generally the less trusted zones. These two default GroupVPN policies are listed in the VPN Policies panel on the VPN > Settings page:

WAN GroupVPN
WLAN GroupVPN

In the VPN Policy dialog, from the Authentication Method menu, you can choose either the IKE using Preshared Secret option or the IKE using 3rd Party Certificates option for your IPsec Keying Mode.

SonicOS supports the creation and management of IPsec VPNs.

* 
TIP: For information about Group VPN and Global VPN Client, see Types of Group VPN/Global VPN Client Scenarios and Configurations (SW7411).
Topics:  
Configuring GroupVPN with IKE using Preshared Secret on the WAN Zone
To configure the WAN GroupVPN:
1
Click the Edit icon for the WAN GroupVPN entry. The VPN Policy dialog displays.

In the General tab, IKE using Preshared Secret is the default setting for Authentication Method.

2
A Shared Secret is automatically generated by the firewall in the Shared Secret field. You can generate your own shared secret. Shared Secrets must be a minimum of four characters.

You cannot change the name of any GroupVPN policy.

3
Click the Proposals tab to continue the configuration process.

4
In the IKE (Phase 1) Proposal section, use the following settings:
Select the DH Group from the DH Group drop-down menu:
Group 1, Group 2 (default), Group 5, or Group 14 – Select Group 2 from the DH Group drop-down menu.
* 
NOTE: The Windows XP L2TP client only works with DH Group 2.
Select DES, 3DES (default), AES-128, AES-192, or AES-256 from the Encryption drop-down menu.
Select the desired authentication method from the Authentication drop-down menu: MD5, SHA1 (default), SHA256, SHA384, or SHA512.
Enter a value in the Life Time (seconds) field. The default setting of 28800 forces the tunnel to renegotiate and exchange keys every 8 hours.
5
In the IPsec (Phase 2) Proposal section, select the following settings:
Select the desired protocol from the Protocol drop-down menu. Currently, ESP is the only option.
Select 3DES (default), AES-128, AES-192, or AES-256 from the Encryption drop-down menu.
Select the desired authentication method from the Authentication drop-down menu: MD5, SHA1 (default), SHA256, SHA384, SHA512, AES-XCBX, or None.
Select Enable Perfect Forward Secrecy if you want an additional Diffie-Hellman key exchange as an added layer of security.
Enter a value in the Life Time (seconds) field. The default setting of 28800 forces the tunnel to renegotiate and exchange keys every 8 hours.
6
Click the Advanced tab.

7
Select any of the following optional settings you want to apply to your GroupVPN policy:
Advanced Settings
Disable IPsec Anti-Replay - Stops packets with duplicate sequence numbers from being dropped.
Enable Multicast - Enables IP multicasting traffic, such as streaming audio (including VoIP) and video applications, to pass through the VPN tunnel.
Accept Multiple Proposals for Clients - Allows multiple proposals for clients, such as the IKE (Phase 1) Proposal or the IKE (Phase 2) Proposal, to be accepted.
Enable IKE Mode Configuration – Allows SonicOS to assign internal IP address, DNS Server, or WINS Server to third-party clients, like iOS devices or Avaya IP pones.
Management via this SA: - If using the VPN policy to manage the firewall, select the management method, either HTTP, SSH, or HTTPS.
* 
NOTE: SSH is valid for IPv4 only.
Default Gateway - Allows you to specify the IP address of the default network route for incoming IPsec packets for this VPN policy. Incoming packets are decoded by the firewall and compared to static routes configured in the firewall. For maximum routes, see Maximum routes and NAT policies allowed per firewall model.

As packets can have any IP address destination, it is impossible to configure enough static routes to handle the traffic. For packets received via an IPsec tunnel, the firewall looks up a route. If no route is found, the security appliance checks for a Default Gateway. If a Default Gateway is detected, the packet is routed through the gateway. Otherwise, the packet is dropped.

Client Authentication
Require Authentication of VPN Clients via XAUTH - Requires that all inbound traffic on this VPN tunnel is from an authenticated user. Unauthenticated traffic is not allowed on the VPN tunnel. The Trusted users group is selected by default. You can select another user group or Everyone from User Group for XAUTH users from the User group for XAUTH users menu.
Allow Unauthenticated VPN Client Access - Allows you to enable unauthenticated VPN client access. If you clear Require Authentication of VPN Clients via XAUTH, the Allow Unauthenticated VPN Client Access menu is activated. Select an Address Object or Address Group from menu of predefined options, or select Create new address object or Create new address group to create a new one.
8
Click the Client tab.
9
Select any of the following settings you want to apply to your GroupVPN policy.

User Name and Password Caching
Cache XAUTH User Name and Password on Client - Allows the Global VPN Client to cache the user name and password:
Never - Global VPN Client is not allowed to cache the username and password. The user is prompted for a username and password when the connection is enabled and also every time there is an IKE Phase 1 rekey. This is the default.
Single Session - Global VPN Client user is prompted for username and password each time the connection is enabled and is valid until the connection is disabled. The username and password is used through IKE Phase 1 rekey.
Always - Global VPN Client user prompted for username and password only once when the connection is enabled. When prompted, the user is given the option of caching the username and password.
Client Connections
Virtual Adapter Settings - The use of the Virtual Adapter by the Global VPN Client (GVC) is dependent upon a DHCP server, either the internal SonicOS or a specified external DHCP server, to allocate addresses to the Virtual Adapter.

In instances where predictable addressing is a requirement, it is necessary to obtain the MAC address of the Virtual Adapter and to create a DHCP lease reservation. To reduce the administrative burden of providing predictable Virtual Adapter addressing, you can configure the GroupVPN to accept static addressing of the Virtual Adapter's IP configuration.

* 
NOTE: This feature requires the use of SonicWall GVC.
None - A Virtual Adapter is not used by this GroupVPN connection. This is the default.
DHCP Lease - The Virtual Adapter obtains its IP configuration from the DHCP Server only, as configured in the VPN > DHCP over VPN page.
DHCP Lease or Manual Configuration - When the GVC connects to the firewall, the policy from the firewall instructs the GVC to use a Virtual Adapter, but the DHCP messages are suppressed if the Virtual Adapter has been manually configured. The configured value is recorded by the firewall so it can proxy ARP for the manually assigned IP address. By design, there are currently no limitations on IP address assignments for the Virtual Adapter. Only duplicate static addresses are not permitted.
Allow Connections to - Client network traffic matching destination networks of each gateway is sent through the VPN tunnel of that specific gateway.
This Gateway Only - Allows a single connection to be enabled at a time. Traffic that matches the destination networks as specified in the policy of the gateway is sent through the VPN tunnel. If this option is selected:
Along with Set Default Route as this Gateway, then the internet traffic is also sent through the VPN tunnel.
Without selecting Set Default Route as this Gateway, then the Internet traffic is blocked.
All Secured Gateways - Allows one or more connections to be enabled at the same time. Traffic matching the destination networks of each gateway is sent through the VPN tunnel of that specific gateway. If this option is selected:
Along with Set Default Route as this Gateway, then Internet traffic is also sent through the VPN tunnel.
Without Set Default Route as this Gateway, then the internet traffic is blocked. Only one of the multiple gateways can have Set Default Route as this Gateway enabled.
Split Tunnels - Allows the VPN user to have both local internet connectivity and VPN connectivity. This is the default.
Set Default Route as this Gateway - Select this checkbox if all remote VPN connections access the internet through this VPN tunnel. You can only configure one VPN policy to use this setting. By default, this option is not enabled.
Apply VPN Access Control List – Select this checkbox to apply the VPN access control list. When this option is enabled, specified users can access only those networks configured for them (for more information, see Adding Local Users). This option is not enabled by default.
Client Initial Provisioning
Use Default Key for Simple Client Provisioning - Uses Aggressive mode for the initial exchange with the gateway, and VPN clients uses a default Preshared Key for authentication. This option is not enabled by default.
10
Click OK.
Configuring GroupVPN with IKE using 3rd Party Certificates
To configure GroupVPN with IKE using 3rd Party Certificates, follow these steps:
* 
CAUTION: Before configuring GroupVPN with IKE using 3rd Party Certificates, your certificates must be installed on the firewall.
1
In the VPN > Settings page, click the Edit icon under Configure. The VPN Policy dialog is displayed.
2
In the Security Policy section, select IKE using 3rd Party Certificates from the Authentication Method drop-down menu.

 
* 
NOTE: The VPN policy name is GroupVPN by default and cannot be changed.
3
Select a certificate for the firewall from the Gateway Certificate drop-down menu.
4
Select one of the following Peer ID types from the Peer ID Type drop-down menu:
Distinguished Name - This is based on the certificate’s Subject Distinguished Name field, which is contained in all certificates by default.

The format of any Subject Distinguished Name is determined by the issuing Certificate Authority. Common fields are Country (C=), Organization (O=), Organizational Unit (OU=), Common Name (CN=), Locality (L=), and vary with the issuing Certificate Authority. The actual Subject Distinguished Name field in an X.509 Certificate is a binary object which must be converted to a string for matching purposes. The fields are separated by the forward slash character, for example: /C=US/O=SonicWall, Inc./OU=TechPubs/CN=Joe Pub.

Up to three organizational units can be specified. The usage is c=*;o=*;ou=*;ou=*;ou=*;cn=*. The final entry does not need to contain a semi-colon. You must enter at least one entry, for example, c=us.

Email ID and Domain Name (default) - Both the Email ID and Domain Name types are based on the certificate's Subject Alternative Name field, which is not contained in all certificates by default. If the certificate does not contain a Subject Alternative Name field, this filter does not work.

The Email ID and Domain Name filters can contain a string or partial string identifying the acceptable range required. The strings entered are not case sensitive and can contain the wild card characters * (for more than 1 character) and ? (for a single character). For example, the string *@sonicwall.com when Email ID is selected allows anyone with an email address that ended in sonicwall.com to have access; the string *sv.us.sonicwall.com when Domain Name is selected allows anyone with a domain name that ended in sv.us.sonicwall.com to have access.

5
Enter the Peer ID filter in the Peer ID Filter field.
6
Check Allow Only Peer Certificates Signed by Gateway Issuer to specify that peer certificates must be signed by the issuer specified in the Gateway Certificate menu.
7
Click on the Proposals tab.

8
In the IKE (Phase 1) Proposal section, select the following settings:
Select the DH Group from the DH Group menu.
Group 1, Group 2, Group 5, or Group 14
* 
NOTE: The Windows XP L2TP client only works with DH Group 2.
Select 3DES (default), AES-128, AES-192, or AES-256 from the Encryption menu.
Select the desired authentication method from the Authentication menu: MD5, SHA1 (default), SHA256, SHA384, SHA512, AES-XCBX, or None.
Enter a value in the Life Time (seconds) field. The default setting of 28800 forces the tunnel to renegotiate and exchange keys every 8 hours.
9
In the IPsec (Phase 2) Proposal section, select the following settings:
Select the desired protocol from the Protocol menu. Currently, ESP is the only option.
Select 3DES (default), AES-128, AES-192, or AES-256 from the Encryption drop-down menu.
Select the desired authentication method from the Authentication drop-down menu: MD5, SHA1 (default), SHA256, SHA384, SHA512, AES-XCBX, or None.
Select Enable Perfect Forward Secrecy if you want an additional Diffie-Hellman key exchange as an added layer of security.
Enter a value in the Life Time (seconds) field. The default setting of 28800 forces the tunnel to renegotiate and exchange keys every 8 hours.
10
Click on the Advanced tab and select any of the following optional settings that you want to apply to your GroupVPN Policy:

Enable Windows Networking (NetBIOS) broadcast - Allows access to remote network resources by browsing the Windows Network Neighborhood.
Enable Multicast - Enables IP multicasting traffic, such as streaming audio (including VoIP) and video applications, to pass through the VPN tunnel.
Management via this SA - If using the VPN policy to manage the firewall, select the management method, either HTTP, SSH, or HTTPS.
* 
NOTE: SSH is valid for IPv4 only.
Default Gateway - Used at a central site in conjunction with a remote site using the Route all Internet traffic through this SA check box. Default LAN Gateway allows you to specify the IP address of the default LAN route for incoming IPsec packets for this SA.

Incoming packets are decoded by the firewall and compared to static routes configured in the firewall. Since packets can have any IP address destination, it is impossible to configure enough static routes to handle the traffic. For packets received via an IPsec tunnel, the firewall looks up a route for the LAN. If no route is found, the firewall checks for a Default LAN Gateway. If a Default LAN Gateway is detected, the packet is routed through the gateway. Otherwise, the packet is dropped.

Enable OCSP Checking and OCSP Responder URL - Enables use of Online Certificate Status Protocol (OCSP) to check VPN certificate status and specifies the URL where to check certificate status. See Using OCSP with SonicWall Network Security Appliances.
Require Authentication of VPN Clients via XAUTH - Requires that all inbound traffic on this VPN policy is from an authenticated user. Unauthenticated traffic is not allowed on the VPN tunnel.
User group for XAUTH users - Allows you to select a defined user group for authentication.
Allow Unauthenticated VPN Client Access - Allows you to specify network segments for unauthenticated Global VPN Client access.
11
Click on the Client tab and select any of the following boxes that you want to apply to Global VPN Client provisioning:

Cache XAUTH User Name and Password - Allows the Global VPN Client to cache the user name and password. Select from:
Never - Global VPN Client is not allowed to cache username and password. The user will be prompted for a username and password when the connection is enabled and also every time there is an IKE phase 1 rekey.
Single Session - The user will be prompted for username and password each time the connection is enabled and will be valid until the connection is disabled. This username and password is used through IKE phase 1 rekey.
Always - The user will be prompted for username and password only once when connection is enabled. When prompted, the user will be given the option of caching the username and password.
Virtual Adapter Settings - The use of the Virtual Adapter by the Global VPN Client (GVC) is dependent upon a DHCP server, either the internal SonicOS or a specified external DHCP server, to allocate addresses to the Virtual Adapter.

In instances where predictable addressing was a requirement, it is necessary to obtain the MAC address of the Virtual Adapter, and to create a DHCP lease reservation. To reduce the administrative burden of providing predictable Virtual Adapter addressing, you can configure the GroupVPN to accept static addressing of the Virtual Adapter's IP configuration. This feature requires the use of SonicWall GVC.

None - A Virtual Adapter will not be used by this GroupVPN connection.
DHCP Lease - The Virtual Adapter will obtain its IP configuration from the DHCP Server only, as configure in the VPN > DHCP over VPN page.
DHCP Lease or Manual Configuration - When the GVC connects to the firewall, the policy from the firewall instructs the GVC to use a Virtual Adapter, but the DHCP messages are suppressed if the Virtual Adapter has been manually configured. The configured value is recorded by the firewall so that it can proxy ARP for the manually assigned IP address. By design, there are currently no limitations on IP address assignments for the Virtual Adapter. Only duplicate static addresses are not permitted.
Allow Connections to - Client network traffic matching destination networks of each gateway is sent through the VPN tunnel of that specific gateway.
This Gateway Only - Allows a single connection to be enabled at a time. Traffic that matches the destination networks as specified in the policy of the gateway is sent through the VPN tunnel. If this option is selected along with Set Default Route as this Gateway, then the Internet traffic is also sent through the VPN tunnel. If this option is selected without selecting Set Default Route as this Gateway, then the Internet traffic is blocked.
All Secured Gateways - Allows one or more connections to be enabled at the same time. Traffic matching the destination networks of each gateway is sent through the VPN tunnel of that specific gateway.

If this option is selected along with Set Default Route as this Gateway, then Internet traffic is also sent through the VPN tunnel. If this option is selected without Set Default Route as this Gateway, then the Internet traffic is blocked.

* 
NOTE: Only one of the multiple gateways can have Set Default Route as this Gateway enabled.
Split Tunnels - Allows the VPN user to have both local Internet connectivity and VPN connectivity.
Set Default Route as this Gateway - Enable this check box if all remote VPN connections access the Internet through this SA. You can only configure one SA to use this setting.
Use Default Key for Simple Client Provisioning - Uses Aggressive mode for the initial exchange with the gateway and VPN clients uses a default Preshared Key for authentication.
12
Click OK.
Exporting a VPN Client Policy
* 
CAUTION: The GroupVPN SA must be enabled on the firewall to export a configuration file.
To export the Global VPN Client configuration settings to a file for users to import into their Global VPN Clients:
1
Click the Export icon in the Configure column for the GroupVPN entry in the VPN Policies table. The Export VPN Client Policy dialog appears.

2
rcf format is required for SonicWall Global VPN Clients is selected by default. Files saved in the rcf format can be password encrypted. The firewall provides a default file name for the configuration file, which you can change.
3
Click Yes. The VPN Policy Export dialog displays.

4
Select a VPN Access Networks from the Select the client Access Network(s) you wish to export drop-down menu.
5
Type a password in the Password field and reenter it in the Confirm Password field, if you want to encrypt the exported file. If you choose not to enter a password, the exported file is not encrypted.
6
Click Submit. If you did not enter a password, a message appears confirming your choice.
7
Click OK. You can change the configuration file before saving.
8
Save the file.
9
Click Close.

The file can be saved or sent electronically to remote users to configure their Global VPN Clients.

Site-to-Site VPN Configurations

* 
VIDEO: Informational videos with Site-to-Site VPN configuration examples are available online. For example, see How to Create a Site to Site VPN in Main Mode using Preshared Secret or How to Create Aggressive Mode Site to Site VPN using Preshared Secret.

Additional videos are available at: https://support.sonicwall.com/videos-product-select.

* 
TIP: See the knowledge base articles for information about Site to Site VPNs:

When designing VPN connections, be sure to document all pertinent IP addressing information and create a network diagram to use as a reference. A sample planning sheet is provided on the next page. The firewall must have a routable WAN IP address whether it is dynamic or static. In a VPN network with dynamic and static IP addresses, the VPN gateway with the dynamic address must initiate the VPN connection.

Site-to-Site VPN configurations can include the following options:

Branch Office (Gateway to Gateway) - A SonicWall is configured to connect to another SonicWall via a VPN tunnel. Or, a SonicWall is configured to connect via IPsec to another manufacturer’s firewall.
Hub and Spoke Design - All SonicWall VPN gateways are configured to connect to a central hub, such as a corporate firewall. The hub must have a static IP address, but the spokes can have dynamic IP addresses. If the spokes are dynamic, the hub must be a SonicWall network security appliance.
Mesh Design - All sites connect to all other sites. All sites must have static IP addresses.

Creating Site-to-Site VPN Policies

You can create or modify existing VPN policies using the VPN Policy window. Clicking the Add button under the VPN Policies table displays the VPN Policy window for configuring the following IPsec Keying mode VPN policies:

This section also contains information on configuring a static route to act as a failover in case the VPN tunnel goes down. See Configuring VPN Failover to a Static Route for more information.

* 
VIDEO: Informational videos with Site-to-Site VPN configuration examples are available online. For example, see How to Create a Site to Site VPN in Main Mode using Preshared Secret or How to Create Aggressive Mode Site to Site VPN using Preshared Secret.

Additional videos are available at: https://support.sonicwall.com/videos-product-select.

Configuring a VPN Policy with IKE using Preshared Secret
To configure a VPN Policy using Internet Key Exchange (IKE):
1
Go to the VPN > Settings page. The VPN Policy page is displayed.

2
Click the Add button. The VPN Policy dialog appears.

3
From the Policy Type drop-down menu on the General tab, select the type of policy that you want to create:
Site to Site
Tunnel Interface
* 
NOTE: If you select Tunnel Interface for the Policy Type, the IPsec Secondary Gateway Name or Address option and the Network tab are not available.
4
Select IKE using Preshared Secret from the Authentication Method drop-down menu.
5
Enter a name for the policy in the Name field.
6
Enter the host name or IP address of the remote connection in the IPsec Primary Gateway Name or Address field.
7
If the Remote VPN device supports more than one endpoint, you may optionally enter a second host name or IP address of the remote connection in the IPsec Secondary Gateway Name or Address field.
* 
NOTE: If you selected Tunnel Interface for the Policy Type, this option is not available.
8
In the IKE Authentication section, enter in the Shared Secret and Confirm Shared Secret fields a Shared Secret password to be used to setup the Security Association. The Shared Secret must be at least 4 characters long, and should comprise both numbers and letters.
9
By default, the Mask Shared Secret checkbox is selected, which causes the shared secret to be displayed as black circles in the Shared Secret and Confirm Shared Secret fields. To see the shared secret in both fields, deselect the checkbox.
10
Optionally, specify a Local IKE ID and Peer IKE ID for this Policy. By default, the IP Address (ID_IPv4_ADDR) is used for Main Mode negotiations, and the firewall Identifier (ID_USER_FQDN) is used for Aggressive Mode.

You can select from the following IDs:

IPv4 Address
Domain Name
E-mail Address
Firewall Identifier
Key Identifier

Then, enter the address, name, or ID in the field after the drop-down menu.

11
Click the Network tab.
* 
NOTE: If you selected Tunnel Interface for Policy Type on the General tab, the Network tab does not display. Go to Step 14.

12
Under Local Networks, select one of these
If a specific local network can access the VPN tunnel, select a local network from the Choose local network from list drop-down menu.
If traffic can originate from any local network, select Any Address. Use this option if a peer has Use this VPN tunnel as default route for all Internet traffic selected. Auto-added rules will be created between Trusted Zones and the VPN Zone.
* 
NOTE: DHCP over VPN is not supported with IKEv2.
13
Under Destination Networks, select one of these:
If traffic from any local user cannot leave the firewall unless it is encrypted, select Use this VPN Tunnel as default route for all Internet traffic.
* 
NOTE: You can only configure one SA to use this setting.
Alternatively, select Choose Destination network from list, and select the address object or group.
14
Click Proposals.

15
Under IKE (Phase 1) Proposal, select one of these from the Exchange menu:
Main Mode - Uses IKE Phase 1 proposals with IPsec Phase 2 proposals. Suite B cryptography options are available for the DH Group in IKE Phase 1 settings, and for Encryption in the IPsec Phase 2 settings.
Aggressive Mode – Generally used when WAN addressing is dynamically assigned. Uses IKE Phase 1 proposals with IPsec Phase 2 proposals. Suite B cryptography options are available for the DH Group in IKE Phase 1 settings, and for Encryption in the IPsec Phase 2 settings.
IKEv2 Mode – Causes all negotiation to happen via IKE v2 protocols, rather than using IKE Phase 1 and IPsec Phase 2.
* 
NOTE: If you select IKE v2 Mode, both ends of the VPN tunnel must use IKE v2.

If IKE v2 is selected, these options are dimmed: DH Group, Encryption, and Authentication.

16
Under IKE (Phase 1) Proposal, the default values for DH Group, Encryption, Authentication, and Life Time are acceptable for most VPN configurations.
* 
NOTE: Be sure the Phase 1 values on the opposite side of the tunnel are configured to match.
17
In Main Mode or Aggressive Mode, for the DH Group you can select from five Diffie Hellman groups that are included in Suite B cryptography:
256-bit Random ECP Group
384-bit Random ECP Group
521-bit Random ECP Group
192-bit Random ECP Group
224-bit Random ECP Group

You can also select Group 1, Group 2, Group 5, or Group 14 for DH Group.

18
If you selected Main Mode or Aggressive Mode, select one of 3DES, DES, AES-128, AES-192, or AES-256 from the Encryption drop-down list. 3DES is the default.
19
If you selected Main Mode or Aggressive Mode, for enhanced authentication security you can choose one of SHA-1, MD5, SHA256, SHA384, or SHA512 from the Authentication drop-down list. SHA1 is the default.
20
In the IPsec (Phase 2) Proposal section, the default values for Protocol, Encryption, Authentication, Enable Perfect Forward Secrecy, and Life Time (seconds) are acceptable for most VPN SA configurations.
* 
NOTE: Be sure the Phase 2 values on the opposite side of the tunnel are configured to match.
21
If you selected ESP in the Protocol field, then in the Encryption field you can select from six encryption algorithms that are included in Suite B cryptography:
AESGCM16-128
AESGCM16-192
AESGCM16-256
AESGMAC-128
AESGMAC-192
AESGMAC-256

You can also select DES, 3DES, AES-128, AES-192, or AES-256 for Encryption.

22
Click the Advanced tab and select any of the following optional settings you want to apply to your VPN policy. The options change depending on whether in the Proposals tab you selected
Main Mode or Aggressive Mode
IKEv2 Mode
Main Mode or Aggressive Mode Options

Select Enable Keep Alive to use heartbeat messages between peers on this VPN tunnel. If one end of the tunnel fails, using Keepalives will allow for the automatic renegotiation of the tunnel once both sides become available again without having to wait for the proposed Life Time to expire.
* 
NOTE: The Keep Alive option will be disabled when the VPN policy is configured as a central gateway for DHCP over VPN or with a primary gateway name or address 0.0.0.0.
The Suppress automatic Access Rules creation for VPN Policy setting is not enabled by default to allow the VPN traffic to traverse the appropriate zones.
Select Disable IPsec Anti-Replay to disable anti-replay, which is a form of partial sequence integrity that detects the arrival of duplicate IP datagrams (within a constrained window).
To require XAUTH authentication by users prior to allowing traffic to traverse this tunnel, select Require authentication of VPN client by XAUTH and then select a User group to specify allowed users from the now displayed User group for XAUTH drop-down menu.

Select Enable Windows Networking (NetBIOS) Broadcast to allow access to remote network resources by browsing the Windows® Network Neighborhood.
Select Enable Multicast to allow IP multicasting traffic, such as streaming audio (including VoIP) and video applications, to pass through the VPN tunnel.
Select Permit Acceleration to enable redirection of traffic matching this policy to the WAN Acceleration (WXA) appliance.
Select Apply NAT Policies if you want the firewall to translate the Local, Remote or both networks communicating via this VPN tunnel. Two drop-down menus display:

To perform Network Address Translation on the Local Network, select or create an Address Object in the Translated Local Network menu.
To translate the Remote Network, select or create an Address Object in the Translated Remote Network drop-down menu.
* 
NOTE: Generally, if NAT is required on a tunnel, either Local or Remote should be translated, but not both. Apply NAT Policies is particularly useful in cases where both sides of a tunnel use either the same or overlapping subnets.
To manage the local SonicWall through the VPN tunnel, select HTTPS from Management via this SA.
Select HTTP, HTTPS, or both in the User login via this SA to allow users to login using the SA.
* 
NOTE: HTTP user login is not allowed with remote authentication.
If you wish to use a router on the LAN for traffic entering this tunnel destined for an unknown subnet, for example, if you configured the other side to Use this VPN Tunnel as default route for all Internet traffic, you should enter the IP address of your router into the Default LAN Gateway (optional) field.
Select an interface or zone from the VPN Policy bound to drop-down menu. A Zone WAN is the preferred selection if you are using WAN Load Balancing and you wish to allow the VPN to use either WAN interface.
* 
IMPORTANT: Two different WAN interfaces cannot be selected from the VPN Policy bound to drop-down menu if the VPN Gateway IP address is the same for both.
IKEv2 Mode Options

When IKE2 Mode is selected on the Proposals tab, the Advanced tab has two sections:

Advanced Settings

The Advanced settings are the same as for Main Mode or Aggressive Mode Options with these exceptions:

The Enable Keep Alive option is dimmed.
The Require authentication of VPN clients by XAUTH option is not displayed.
IKEv2 Settings

The Do not send trigger packet during IKE SA negotiation checkbox is not selected by default and should be selected only when required for interoperability if the peer cannot handle trigger packets.

The term Trigger Packet refers to the use of initial Traffic Selector payloads populated with the IP addresses from the packet that caused SA negotiation to begin. It is recommended practice to include Trigger Packets to assist the IKEv2 Responder in selecting the correct protected IP address ranges from its Security Policy Database. Not all implementations support this feature, so it may be appropriate to disable the inclusion of Trigger Packets to some IKE peers.

Select one or both of the following two options for the IKEv2 VPN policy:
Accept Hash & URL Certificate Type
Send Hash & URL Certificate Type

Select these options if your devices can send and process hash and certificate URLs instead of the certificates themselves. Using these options reduces the size of the messages exchanged.

When the Accept Hash & URL Certificate Type option is selected, the firewall sends an HTTP_CERT_LOOKUP_SUPPORTED message to the peer device. If the peer device replies by sending a “Hash and URL of X.509c” certificate, the firewall can authenticate and establish a tunnel between the two devices.

When the Send Hash & URL Certificate Type option is selected, the firewall, on receiving an HTTP_CERT_LOOKUP_SUPPORTED message, sends a “Hash and URL of X.509c” certificate to the requestor.

In a VPN, two peer firewalls (FW1 and FW2) negotiate a tunnel. From the perspective of FW1, FW2 is the remote gateway and vice versa.

23
Click OK.
Configuring a VPN Policy using Manual Key
* 
NOTE: Using Manual Key for configuring a VPN Policy is not supported on the SuperMassive 9800.
To manually configure a VPN policy between two SonicWall appliances using Manual Key:
1
Click Add on the VPN > Settings page. The VPN Policy dialog displays.

2
In the General tab of the VPN Policy dialog, select Manual Key from the Authentication Method drop-down menu. The VPN Policy dialog displays only the Manual Key options.

3
Enter a name for the policy in the Name field.
4
Enter the host name or IP address of the remote connection in the IPsec Gateway Name or Address field.
5
Click the Network tab.

6
Under Local Networks, select one of these
If a specific local network can access the VPN tunnel, select a local network from the Choose local network from list drop-down menu.
If traffic can originate from any local network, select Any Address. Use this option if a peer has Use this VPN tunnel as default route for all Internet traffic selected. Auto-added rules will be created between Trusted Zones and the VPN Zone.
7
Under Destination Networks, select one of these:
If traffic from any local user cannot leave the firewall unless it is encrypted, select Use this VPN Tunnel as default route for all Internet traffic.
* 
NOTE: You can only configure one SA to use this setting.
Alternatively, select Choose Destination network from list, and select the address object or group.
8
Click on the Proposals tab.

9
Define an Incoming SPI and an Outgoing SPI. A Security Parameter Index (SPI) is hexadecimal (0123456789abcedf) and can range from 3 to 8 characters in length.
* 
CAUTION: Each Security Association must have unique SPIs; no two Security Associations can share the same SPIs. However, each Security Association Incoming SPI can be the same as the Outgoing SPI.
10
The default values for Protocol, Encryption, and Authentication are acceptable for most VPN SA configurations.
* 
NOTE: The values for Protocol, Encryption, and Authentication must match the values on the remote firewall.
11
Enter a 48-character hexadecimal encryption key in the Encryption Key field or use the default value. This encryption key is used to configure the remote SonicWall encryption key, therefore, write it down to use when configuring the firewall.
12
Enter a 40-character hexadecimal authentication key in the Authentication Key field or use the default value. Write down the key to use while configuring the firewall settings.
* 
TIP: Valid hexadecimal characters include 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, a, b, c, d, e, and f. 1234567890abcdef is an example of a valid DES or ARCFour encryption key. If you enter an incorrect encryption key, an error message is displayed at the bottom of the browser window.
13
Click the Advanced tab and select any of the following optional settings you want to apply to your VPN policy.

The Suppress automatic Access Rules creation for VPN Policy setting is not enabled by default to allow the VPN traffic to traverse the appropriate zones.
Select Enable Windows Networking (NetBIOS) broadcast to allow access to remote network resources by browsing the Windows® Network Neighborhood.
Select Permit Acceleration to enable redirection of traffic matching this policy to the WAN Acceleration (WXA) appliance.
Select Apply NAT Policies if you want the firewall to translate the Local, Remote or both networks communicating via this VPN tunnel. Two drop-down menus display:

To perform Network Address Translation on the Local Network, select or create an Address Object in the Translated Local Network menu.
To translate the Remote Network, select or create an Address Object in the Translated Remote Network drop-down menu.
* 
NOTE: Generally, if NAT is required on a tunnel, either Local or Remote should be translated, but not both. Apply NAT Policies is particularly useful in cases where both sides of a tunnel use either the same or overlapping subnets.
* 
TIP: Informational videos with interface configuration examples are available online. For example, see How to Configure NAT over VPN in a Site to Site VPN with Overlapping Networks.

Additional videos are available at: https://support.sonicwall.com/videos-product-select.

To manage the local SonicWall through the VPN tunnel, select HTTPS, SSH, SNMP, or any combination of these three from Management via this SA.
Select HTTP, HTTPS, or both in the User login via this SA to allow users to login using the SA.
* 
NOTE: HTTP user login is not allowed with remote authentication.
If you have an IP address for a gateway, enter it into the Default LAN Gateway (optional) field.
Select an interface from the VPN Policy bound to drop-down menu.
* 
IMPORTANT: Two different WAN interfaces cannot be selected from the VPN Policy bound to drop-down menu if the VPN Gateway IP address is the same for both.
14
Click OK.
15
Click Accept on the VPN > Settings page to update the VPN Policies.
Configuring the Remote SonicWall Network Security Appliance
1
Click Add on the VPN > Settings page. The VPN Policy dialog displays.

2
In the General tab, select Manual Key from the Authentication Method drop-down menu.
3
Enter a name for the SA in the Name field.
4
Enter the host name or IP address of the local connection in the IPsec Gateway Name or Address field.
5
Click the Network tab.

6
Under Local Networks, select one of these
If a specific local network can access the VPN tunnel, select a local network from the Choose local network from list drop-down menu.
If traffic can originate from any local network, select Any Address. Use this option if a peer has Use this VPN tunnel as default route for all Internet traffic selected. Auto-added rules will be created between Trusted Zones and the VPN Zone.
7
Under Destination Networks, select one of these:
If traffic from any local user cannot leave the firewall unless it is encrypted, select Use this VPN Tunnel as default route for all Internet traffic.
* 
NOTE: You can only configure one SA to use this setting.
Alternatively, select Choose Destination network from list, and select the address object or group.
8
Click the Proposals tab.

9
Define an Incoming SPI and an Outgoing SPI. The SPIs are hexadecimal (0123456789abcedf) and can range from 3 to 8 characters in length.
* 
CAUTION: Each Security Association must have unique SPIs; no two Security Associations can share the same SPIs. However, each Security Association Incoming SPI can be the same as the Outgoing SPI.
10
The default values for Protocol, Encryption, and Authentication are acceptable for most VPN SA configurations.
* 
NOTE: The values for Protocol, Encryption, and Authentication must match the values on the remote firewall.
11
Enter a 48-character hexadecimal encryption key in the Encryption Key field or use the default value. This encryption key is used to configure the remote SonicWall encryption key, therefore, write it down to use when configuring the remote SonicWall.
12
Enter a 40-character hexadecimal authentication key in the Authentication Key field or use the default value. Write down the key to use while configuring the remote SonicWall settings.
* 
TIP: Valid hexadecimal characters include 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, a, b, c, d, e, and f. 1234567890abcdef is an example of a valid DES or ARCFour encryption key. If you enter an incorrect encryption key, an error message is displayed at the bottom of the browser window.
13
Click the Advanced tab and select any of the following optional settings you want to apply to your VPN policy:

The Suppress automatic Access Rules creation for VPN Policy setting is not enabled by default to allow the VPN traffic to traverse the appropriate zones.
Select Enable Windows Networking (NetBIOS) broadcast to allow access to remote network resources by browsing the Windows® Network Neighborhood.
Select Permit Acceleration to enable redirection of traffic matching this policy to the WAN Acceleration (WXA) appliance.
Select Apply NAT Policies if you want the firewall to translate the Local, Remote or both networks communicating via this VPN tunnel. Two drop-down menus display:

To perform Network Address Translation on the Local Network, select or create an Address Object in the Translated Local Network menu.
To translate the Remote Network, select or create an Address Object in the Translated Remote Network drop-down menu.
* 
NOTE: Generally, if NAT is required on a tunnel, either Local or Remote should be translated, but not both. Apply NAT Policies is particularly useful in cases where both sides of a tunnel use either the same or overlapping subnets.
To manage the remote SonicWall through the VPN tunnel, select HTTP, SSH, SNMP, or any combination of these three from Management via this SA.
Select HTTP, HTTPS, or both in the User login via this SA to allow users to login using the SA.
* 
NOTE: HTTP user login is not allowed with remote authentication.
If you have an IP address for a gateway, enter it into the Default LAN Gateway (optional) field.
Select an interface from the VPN Policy bound to menu.
* 
IMPORTANT: Two different WAN interfaces cannot be selected from the VPN Policy bound to drop-down menu if the VPN Gateway IP address is the same for both.
14
Click OK.
15
Click Accept on the VPN > Settings page to update the VPN Policies.
* 
TIP: Since Window Networking (NetBIOS) has been enabled, users can view remote computers in their Windows Network Neighborhood. Users can also access resources on the remote LAN by entering servers’ or workstations’ remote IP addresses.
Configuring a VPN Policy with IKE using a Third Party Certificate
* 
NOTE: You must have a valid certificate from a third party Certificate Authority installed on your SonicWall before you can configure your VPN policy with IKE using a third party certificate.
To create a VPN SA using IKE and third party certificates:
1
In the VPN > Settings page, click Add. The VPN Policy window is displayed.

2
In the Authentication Method list in the General tab, select IKE using 3rd Party Certificates.The VPN Policy window displays the third-party certificate options in the IKE Authentication section.
3
Type a Name for the Security Association in the Name field.
4
Type the IP address or Fully Qualified Domain Name (FQDN) of the primary remote SonicWall in the IPsec Primary Gateway Name or Address field.
5
If you have a secondary remote SonicWall, enter the IP address or Fully Qualified Domain Name (FQDN) in the IPsec Secondary Gateway Name or Address field.
6
Under IKE Authentication, select a third-party certificate from the Local Certificate list. You must have imported local certificates before selecting this option.

7
Select one of the following Peer ID types from the Peer IKE ID Type menu:
Email ID (UserFQDN) and Domain Name (FQDN) - The Email ID (UserFQDN) and Domain Name (FQDN) types are based on the certificate's Subject Alternative Name field, which is not contained in all certificates by default. If the certificate contains a Subject Alternative Name, that value must be used. For site-to-site VPNs, wild card characters (such as * for more than one character or ? for a single character) cannot be used.

The full value of the Email ID or Domain Name must be entered. This is because site-to-site VPNs are expected to connect to a single peer, as opposed to Group VPNs, which expect to connect to multiple peers.

* 
NOTE: To find the certificate details (Subject Alternative Name, Distinguished Name, etc.), navigate to the System > Certificates page and click on the Export button for the certificate.
Distinguished Name (DN) - Based on the certificates Subject Distinguished Name field, which is contained in all certificates by default. As with the Email ID and Domain Name above, the entire Distinguished Name field must be entered for site-to-site VPNs. Wild card characters are not supported.

The format of any Subject Distinguished Name is determined by the issuing Certificate Authority. Common fields are Country (C=), Organization (O=), Organizational Unit (OU=), Common Name (CN=), Locality (L=), and vary with the issuing Certificate Authority. The actual Subject Distinguished Name field in an X.509 Certificate is a binary object which must be converted to a string for matching purposes. The fields are separated by the forward slash character, for example: /C=US/O=SonicWall, Inc./OU=TechPubs/CN=Joe Pub

IP Address (IPV4) - Based on the IPv4 IP address.
8
Type an ID string in the Peer IKE ID field.
9
Click on the Network tab.

10
Under Local Networks, select one of these
If a specific local network can access the VPN tunnel, select a local network from the Choose local network from list drop-down menu.
If traffic can originate from any local network, select Any Address. Use this option if a peer has Use this VPN tunnel as default route for all Internet traffic selected. Auto-added rules will be created between Trusted Zones and the VPN Zone.
11
Under Destination Networks, select one of these:
If traffic from any local user cannot leave the firewall unless it is encrypted, select Use this VPN Tunnel as default route for all Internet traffic.
* 
NOTE: You can only configure one SA to use this setting.
Alternatively, select Choose Destination network from list, and select the address object or group.
12
Click the Proposals tab.

13
In the IKE (Phase 1) Proposal section, select the following settings:
Select Main Mode or Aggressive Mode from the Exchange menu.
Select the desired DH Group from the DH Group menu:
Group 1, Group 2, Group 5, or Group 14
256-Bit Random ECP Group, 384-Bit Random ECP Group, 521-Bit Random ECP Group, 192-Bit Random ECP Group, or 224-Bit Random ECP Group
Select 3DES, AES-128, AES-192, or AES-256 from the Encryption menu.
Select the desired authentication method from the Authentication menu.
Enter a value in the Life Time (seconds) field. The default setting of 28800 forces the tunnel to renegotiate and exchange keys every 8 hours.
14
In the IPsec (Phase 2) Proposal section, select the following settings:
Select the desired protocol from the Protocol menu.
Select 3DES, AES-128, AES-192, or AES-256 from the Encryption menu.
Select the desired authentication method from the Authentication menu.
Select Enable Perfect Forward Secrecy if you want an additional Diffie-Hellman key exchange as an added layer of security. Select Group 2 from the DH Group menu.
Enter a value in the Life Time (seconds) field. The default setting of 28800 forces the tunnel to renegotiate and exchange keys every 8 hours.
15
Click the Advanced tab. Select any optional configuration options you want to apply to your VPN policy:

Select Enable Keep Alive to use heartbeat messages between peers on this VPN tunnel. If one end of the tunnel fails, using Keepalives will allow for the automatic renegotiation of the tunnel once both sides become available again without having to wait for the proposed Life Time to expire.
The Suppress automatic Access Rules creation for VPN Policy setting is not enabled by default to allow the VPN traffic to traverse the appropriate zones.
Select Disable IPsec Anti-Replay to disable anti-replay, which is a form of partial sequence integrity that detects the arrival of duplicate IP datagrams (within a constrained window).
To require XAUTH authentication by users prior to allowing traffic to traverse this tunnel, select Require authentication of VPN client by XAUTH, and select a User group to specify allowed users from the User group for XAUTH.
Select Enable Windows Networking (NetBIOS) Broadcast to allow access to remote network resources by browsing the Windows® Network Neighborhood.
Select Enable Multicast to allow multicast traffic through the VPN tunnel.
Select Permit Acceleration to enable redirection of traffic matching this policy to the WAN Acceleration (WXA) appliance
Select Apply NAT Policies if you want the firewall to translate the Local, Remote or both networks communicating via this VPN tunnel. Two drop-down menus display:

To perform Network Address Translation on the Local Network, select or create an Address Object in the Translated Local Network menu.
To translate the Remote Network, select or create an Address Object in the Translated Remote Network drop-down menu.
* 
NOTE: Generally, if NAT is required on a tunnel, either Local or Remote should be translated, but not both. Apply NAT Policies is particularly useful in cases where both sides of a tunnel use either the same or overlapping subnets.
Select Enable OCSP Checking to check VPN certificate status and specify the URL where to check certificate status. See Using OCSP with SonicWall Network Security Appliances.
To manage the remote SonicWall through the VPN tunnel, select HTTP, HTTPS, or both from Management via this SA. Select HTTP, SSH, HTTPS, or any combination of the three in the User login via this SA to allow users to login using the SA.
If you wish to use a router on the LAN for traffic entering this tunnel destined for an unknown subnet, for example, if you configured the other side to Use this VPN Tunnel as default route for all Internet traffic, you should enter the IP address of your router into the Default LAN Gateway (optional) field.
Select an interface or zone from the VPN Policy bound to menu. A zone is the preferred selection if you are using WAN Load Balancing and you wish to allow the VPN to use either WAN interface.
* 
IMPORTANT: Two different WAN interfaces cannot be selected from the VPN Policy bound to drop-down menu if the VPN Gateway IP address is the same for both.
Under IKEv2 Settings (visible only if you selected IKEv2 for Exchange on the Proposals tab), The Do not send trigger packet during IKE SA negotiation checkbox is cleared by default and should only be selected when required for interoperability.

The term Trigger Packet refers to the use of initial Traffic Selector payloads populated with the IP addresses from the packet that caused SA negotiation to begin. It is recommended practice to include Trigger Packets to assist the IKEv2 Responder in selecting the correct protected IP address ranges from its Security Policy Database. Not all implementations support this feature, so it may be appropriate to disable the inclusion of Trigger Packets to some IKE peers.

Select one or both of the following two options for the IKEv2 VPN policy:
Accept Hash & URL Certificate Type
Send Hash & URL Certificate Type

Select these options if your devices can send and process hash and certificate URLs instead of the certificates themselves. Using these options reduces the size of the messages exchanged.

When the Accept Hash & URL Certificate Type option is selected, the firewall sends an HTTP_CERT_LOOKUP_SUPPORTED message to the peer device. If the peer device replies by sending a “Hash and URL of X.509c” certificate, the firewall can authenticate and establish a tunnel between the two devices.

When the Send Hash & URL Certificate Type option is selected, the firewall, on receiving an HTTP_CERT_LOOKUP_SUPPORTED message, sends a “Hash and URL of X.509c” certificate to the requestor.

In a VPN, two peer firewalls (FW1 and FW2) negotiate a tunnel. From the perspective of FW1, FW2 is the remote gateway and vice versa.

16
Click OK.
Configuring VPN Failover to a Static Route

Optionally, you can configure a static route to be used as a secondary route in case the VPN tunnel goes down. The Allow VPN path to take precedence option allows you to create a secondary route for a VPN tunnel. By default, static routes have a metric of one and take precedence over VPN traffic. The Allow VPN path to take precedence option gives precedence over the route to VPN traffic to the same destination address object. This results in the following behavior:

When a VPN tunnel is active: static routes matching the destination address object of the VPN tunnel are automatically disabled if the Allow VPN path to take precedence option is enabled. All traffic is routed over the VPN tunnel to the destination address object.
When a VPN tunnel goes down: static routes matching the destination address object of the VPN tunnel are automatically enabled. All traffic to the destination address object is routed over the static routes.
To configure a static route as a VPN failover:
1
Navigate to the Network > Routing page.
2
Scroll to the bottom of the page and click on the Add button. The Add Route Policy dialog displays.

3
Select the appropriate Source, Destination, Service, Gateway, and Interface.
4
Ensure Metric is 1.
5
Enable the Allow VPN path to take precedence checkbox.
6
Click OK.

For more information on configuring static routes and Policy Based Routing, see Network > Routing.

Route-Based VPN with Tunnel Interface Policies

A policy-based approach forces the VPN policy configuration to include the network topology configuration. This makes it difficult to configure and maintain the VPN policy with a constantly changing network topology.

With the Route Based VPN approach, network topology configuration is removed from the VPN policy configuration. The VPN policy configuration creates an unnumbered Tunnel Interface between two end points. Static or Dynamic routes can then be added to the Tunnel Interface (for the maximum numbers of static and dynamic routes per firewall, seeMaximum routes and NAT policies allowed per firewall model). The Route Based VPN approach moves network configuration from the VPN policy configuration to Static or Dynamic Route configuration.

Not only does Route Based VPN make configuring and maintaining the VPN policy easier, a major advantage of the Route Based VPN feature is that it provides flexibility on how traffic is routed. With this feature, you can define multiple paths for overlapping networks over a clear or redundant VPN.

Topics:  

Terminology

VPN Tunnel Policy – A policy configured without a local/remote protected network. When sending a packet out, SonicOS does not need to look up any tunnel policy.
VPN Tunnel Interface – A numbered tunnel interface created on the Network > Interfaces page and bound to a tunnel policy. The interface is configured as the egress interface of a route entry or a SonicOS App that actively sends out packets such as Net Monitor Policy, Syslog policy. When SonicOS sends a packet out over the VPN Tunnel, logically it's the same as sending the packet over a physical interface, except the packet is encrypted.
Numbered/Unnumbered Tunnel Interface – A numbered tunnel interface has an IP address, while an unnumbered tunnel interface has none. A numbered tunnel interface is created on the Network > Interfaces page by adding a VPN Tunnel Interface. Functionally, the numbered tunnel interface is a superset of the unnumbered tunnel interface. You can configure a numbered tunnel interface in the same way as a standard interface, including settings for HTTPS, Ping, SNMP, and SSH management, HTTP and HTTPS user login, and fragmentation handling. You can use a numbered tunnel interface when configuring NAT policies, firewall access control lists, and routing policies including all types of dynamic routing (RIP, OSPF, BGP).

An unnumbered tunnel interface is created when you configure a VPN policy with a Policy Type of Tunnel Interface. By default, it is used for simple, route-based VPN and doesn’t require an IP address. If the Allow Advanced Routing option is enabled in the Advanced tab of the policy configuration dialog, an unnumbered tunnel interface can be used with RIP and OSPF dynamic routing. When configuring RIP or OSPF using an unnumbered tunnel interface, an IP address is borrowed for it from either a physical or logical (VLAN) interface.

Using Route Based VPN

Route Based VPN configuration is a two-step process:

1
Create a Tunnel Interface. The crypto suites used to secure the traffic between two end-points are defined in the Tunnel Interface.
2
Create a static or dynamic route using Tunnel Interface.

The Tunnel Interface is created when a Policy of type Tunnel Interface is added for the remote gateway. The Tunnel Interface must be bound to a physical interface and the IP address of that physical interface is used as the source address of the tunneled packet.

Topics:  
Adding a Tunnel Interface
To add a Tunnel Interface:
1
Navigate to VPN > Settings.
2
Under the VPN Policies table, click the Add button. The VPN Policy dialog displays.

3
On the General tab, select the policy type as Tunnel Interface.

The IPsec Secondary Gateway name or Address field on the General tab and the Network tab are removed.

4
Enter a friendly name in the Name field.
5
Click the Proposals tab.

6
Configure the IKE (Phase 1) Proposal and IPSec (Phase 2) Proposal options for the tunnel negotiation.
7
Click the Advanced tab to configure the advanced properties for the Tunnel Interface. By default, Enable Keep Alive is disabled.

8
The following advanced options can be configured (by default, none are selected):
Disable IPsec Anti-Replay - Disables anti-replay, which is a form of partial sequence integrity that detects the arrival of duplicate IP datagrams (within a constrained window).
Allow Advanced Routing – Adds this Tunnel Interface to the list of interfaces in the Routing Protocols table on the Network > Routing page.

This option must be selected if the Tunnel Interface is to be used for advanced routing (RIP, OSPF). Making this an optional setting avoids adding all Tunnel Interfaces to the Routing Protocols table, which helps streamline the routing configuration. For information on configuring RIP or OSPF advanced routing for the Tunnel Interface, see Configuring Advanced Routing for Tunnel Interfaces.

Enable Windows Networking (NetBIOS) Broadcast - Allows access to remote network resources by browsing the Windows® Network Neighborhood.
Enable Multicast - Allows multicast traffic through the VPN tunnel.
Permit Acceleration - Enables redirection of traffic matching this policy to the WAN Acceleration (WXA) appliance.
Display Suite B Compliant Algorithms Only – Displays only Suite B-compliant algorithms.
Allow SonicPointN Layer 3 Management – Allows Layer-3 management for SonicPointN.
Management via this SA - Allows remote users to log in to manage the firewall through the VPN tunnel. Select one or more: HTTPS, SSH, SNMP.
User login via this SA - Allows users to login using the SA. Select either or both: HTTP or HTTPS.
* 
NOTE: HTTP user login is not allowed with remote authentication.
VPN Policy bound to - Sets the interface the Tunnel Interface is bound to. This is Interface X1 by default.
* 
IMPORTANT: Two different WAN interfaces cannot be selected from the VPN Policy bound to drop-down menu if the VPN Gateway IP address is the same for both.
9
If IKEv2 Mode was selected on the Proposals tab, configure the IKEv2 Settings:
The Do not send trigger packet during IKE SA negotiation checkbox is not selected by default and should be selected only when required for interoperability if the peer cannot handle trigger packets.

The term Trigger Packet refers to the use of initial Traffic Selector payloads populated with the IP addresses from the packet that caused SA negotiation to begin. It is recommended practice to include Trigger Packets to assist the IKEv2 Responder in selecting the correct protected IP address ranges from its Security Policy Database. Not all implementations support this feature, so it may be appropriate to disable the inclusion of Trigger Packets to some IKE peers.

Select one or both of the following two options for the IKEv2 VPN policy:
Accept Hash & URL Certificate Type – The firewall sends an HTTP_CERT_LOOKUP_SUPPORTED message to the peer device. If the peer device replies by sending a Hash and URL of X.509c certificate, the firewall can authenticate and establish a tunnel between the two devices.
Send Hash & URL Certificate Type – The firewall, on receiving an HTTP_CERT_LOOKUP_SUPPORTED message, sends a Hash and URL of X.509c certificate to the requestor.

Select these options if your devices can send and process hash and certificate URLs instead of the certificates themselves. Using these options reduces the size of the messages exchanged.

In a VPN, two peer firewalls (FW1 and FW2) negotiate a tunnel. From the perspective of FW1, FW2 is the remote gateway and vice versa.

10
Click OK.
Creating a Static Route for Tunnel Interface

After you have successfully added a Tunnel Interface, you may then create a Static Route.

To create a Static Route for a Tunnel Interface:
1
Navigate to Network > Routing > Route Policies.
2
Click the Add button. The Add Route Policy dialogue appears for adding Static Route.
3
Select a tunnel interface from the Interface drop-down menu, which lists all available tunnel interfaces.
* 
NOTE: If the Auto-add Access Rule option is selected, firewall rules are automatically added and traffic is allowed between the configured networks using tunnel interface.
4
Configure the rest of the settings as necessary.
5
Click OK.

Route Entries for Different Network Segments

After a tunnel interface is created, multiple route entries can be configured to use the same tunnel interface for different networks. This provides a mechanism to modify the network topology without making any changes to the tunnel interface.

Redundant Static Routes for a Network

After more than one tunnel interface is configured, you can add multiple overlapping static routes; each static route uses a different tunnel interface to route the traffic. This provides routing redundancy for the traffic to reach the destination. If no redundant routes are available, you can add a static route to a drop tunnel interface to prevent VPN traffic from being sent out the default route. For more information, see Configuring a Drop Tunnel Interface.

VPN Auto-Added Access Rule Control

When adding VPN Policies, SonicOS auto-creates non-editable Access Rules to allow the traffic to traverse the appropriate zones. Consider the following VPN Policy, where the Local Network is set to Firewalled Subnets (in this case comprising the LAN and DMZ) and the Destination Network is set to Subnet 192.168.169.0.

While this is generally a tremendous convenience, there are some instances where is might be preferable to suppress the auto-creation of Access Rules in support of a VPN Policy. One such instance would be the case of a large hub-and-spoke VPN deployment where all the spoke sites are addresses using address spaces that can easily be supernetted. For example, to provide access to/from the LAN and DMZ at the hub site to one subnet at each of 2,000 remote sites, addressed as follows:

remoteSubnet0=Network 10.0.0.0/24 (mask 255.255.255.0, range 10.0.0.0-10.0.0.255)
remoteSubnet1=Network 10.0.1.0/24 (mask 255.255.255.0, range 10.0.1.0-10.0.1.255)
remoteSubnet2=Network 10.0.2.0/24 (mask 255.255.255.0, range 10.0.2.0-10.0.2.255)
remoteSubnet2000=10.7.207.0/24 (mask 255.255.255.0, range 10.7.207.0-10.7.207.255)

Creating VPN Policies for each of these remote sites would result in the requisite 2,000 VPN Policies, but would also create 8,000 Access Rules (LAN -> VPN, DMZ -> VPN, VPN -> LAN, and VPN -> DMZ for each site). However, all of these Access Rules could easily be handled with just four Access Rules to a supernetted or address range representation of the remote sites (more specific allow or deny Access Rules could be added as needed):

remoteSubnetAll=Network 10.0.0.0/13 (mask 255.248.0.0, range 10.0.0.0-10.7.255.255) or
remoteRangeAll=Range 10.0.0.0-10.7.207.255

To enable this level of aggregation, the Advanced tab of the VPN Policy dialog offers the option to Auto-Add Access Rules for VPN Policy setting. By default, the checkbox is selected, meaning the accompanying Access Rules are created automatically, as they've always been. By deselecting the checkbox upon creating the VPN Policy, you have the ability and need to create custom Access Rules for VPN traffic.

Configuring Auto Provisioning

 

Configuring Advanced VPN Settings

VPN > Advanced

The VPN > Advanced page has two panels with options that can be enabled:

Advanced VPN Settings
IKEv2 Settings

Topics:  

Configuring Advanced VPN Settings

Advanced VPN Settings globally affect all VPN policies. This section also provides solutions for Online Certificate Status Protocol (OCSP). OCSP allows you to check VPN certificate status without Certificate Revocation Lists (CRLs). This allows timely updates regarding the status of the certificates used on your firewall.

Enable IKE Dead Peer Detection - Select if you want inactive VPN tunnels to be dropped by the firewall.
Dead Peer Detection Interval - Enter the number of seconds between “heartbeats.” The default value is 60 seconds.
Failure Trigger Level (missed heartbeats) - Enter the number of missed heartbeats. The default value is 3. If the trigger level is reached, the VPN connection is dropped by the firewall. The firewall uses a UDP packet protected by Phase 1 Encryption as the heartbeat.
Enable Dead Peer Detection for Idle VPN Sessions - Select this setting if you want idle VPN connections to be dropped by the firewall after the time value defined in the Dead Peer Detection Interval for Idle VPN Sessions (seconds) field. The default value is 600 seconds (10 minutes).
Enable Fragmented Packet Handling - If the VPN log report shows the log message Fragmented IPsec packet dropped, select this feature. Do not select it until the VPN tunnel is established and in operation.
Ignore DF (Don't Fragment) Bit - Select this checkbox to ignore the DF bit in the packet header. Some applications can explicitly set the ‘Don’t Fragment’ option in a packet, which tells all security appliances to not fragment the packet. This option, when enabled, causes the firewall to ignore the option and fragment the packet regardless.
Enable NAT Traversal - Select this setting if a NAT device is located between your VPN endpoints. IPsec VPNs protect traffic exchanged between authenticated endpoints, but authenticated endpoints cannot be dynamically re-mapped mid-session for NAT traversal to work. Therefore, to preserve a dynamic NAT binding for the life of an IPsec session, a 1-byte UDP is designated as a “NAT Traversal keepalive” and acts as a “heartbeat” sent by the VPN device behind the NAT or NAPT device. The “keepalive” is silently discarded by the IPsec peer.
Clean up Active Tunnels when Peer Gateway DNS name resolves to a different IP address - Breaks down SAs associated with old IP addresses and reconnects to the peer gateway.
Enable OCSP Checking and OCSP Responder URL - Enables use of Online Certificate Status Protocol (OCSP) to check VPN certificate status and specifies the URL where to check certificate status. See Using OCSP with SonicWall Network Security Appliances.
Send VPN Tunnel Traps only when tunnel status changes - Reduces the number of VPN tunnel traps that are sent by only sending traps when the tunnel status changes.
Use RADIUS in - The primary reason for choosing this option is so that VPN client users can make use of the MSCHAP feature to allow them to change expired passwords at login time. When using RADUIS to authenticate VPN client users, select whether RADIUS is used in one of these modes:
MSCHAP
MSCHAPv2 mode for XAUTH (allows users to change expired passwords)

Also, if this is set and LDAP is selected as the Authentication method for login on the Users > Settings page, but LDAP is not configured in a way that allows password updates, then password updates for VPN client users are done using MSCHAP-mode RADIUS after using LDAP to authenticate the user.

* 
NOTE: Password updates can only be done by LDAP when using either:
Active Directory with TLS and binding to it using an administrative account
Novell eDirectory.
DNS and WINS Server Settings for VPN Client – To configure DNS and WINS server settings for Client, such as a third party VPN Client through GroupVPN, or a Mobile IKEv2 Client, click the Configure button. The Add VPN DNS And WINS Server dialog displays.
* 
NOTE: This option appears only for TZ appliances.

DNS Servers – Select whether to specify the DNS servers dynamically or manually:
Inherit DNS Settings Dynamically from the SonicWall’s DNS settings – The SonicWall appliance obtains the DNS server IP addresses automatically.
Specify Manually – Enter up to three DNS server IP addresses in the DNS Server 1/3 fields.
WINS Servers – Enter up to two WINS server IP address in the WINS Server 1/2 fields.

Configuring IKEv2 Settings

IKEv2 Settings affect IKE notifications and allow you to configure dynamic client support.

Send IKEv2 Cookie Notify - Sends cookies to IKEv2 peers as an authentication tool.
Send IKEv2 Invalid SPI Notify – Sends an invalid Security Parameter Index (SPI) notification to IKEv2 peers when an active IKE security association (SA) exists. This option is selected by default.
IKEv2 Dynamic Client Proposal - SonicOS provides IKEv2 Dynamic Client Support, which provides a way to configure the Internet Key Exchange (IKE) attributes rather than using the default settings.

Clicking the Configure button launches the Configure IKEv2 Dynamic Client Proposal dialog.

SonicOS supports these IKE Proposal settings:

DH Group: Group 1, Group 2 (default), Group 5, Group 14, and the following five Diffie Hellman groups that are included in Suite B cryptography:
256-bit Random ECP Group
384-bit Random ECP Group
521-bit Random ECP Group
192-bit Random ECP Group
224-bit Random ECP Group
Encryption: DES, 3DES (default), AES-128, AES-192, AES-256
Authentication: MD5, SHA1 (default), SHA256, SHA384, or SHA512

If a VPN Policy with IKEv2 exchange mode and a 0.0.0.0 IPSec gateway is defined, however, you cannot configure these IKE Proposal settings on an individual policy basis.

* 
NOTE: The VPN policy on the remote gateway must also be configured with the same settings.

Using OCSP with SonicWall Network Security Appliances

OCSP is designed to augment or replace CRL in your Public Key Infrastructure (PKI) or digital certificate system. The CRL is used to validate the digital certificates comprised by the PKI. This allows the Certificate Authority (CA) to revoke certificates before their scheduled expiration date and is useful in protecting the PKI system against stolen or invalid certificates.

The main disadvantage of Certificate Revocation Lists is the need for frequent updates to keep the CRL of every client current. These frequent updates greatly increase network traffic when the complete CRL is downloaded by every client. Depending on the frequency of the CRL updates, a period of time can exist when a certificate is revoked by the CRL but the client has not received the CRL update and permits the certificate to be used.

Online Certificate Status Protocol determines the current status of a digital certificate without using a CRL. OCSP enables the client or application to directly determine the status of an identified digital certificate. This provides more timely information about the certificate than is possible with CRLs. In addition, each client typically only checks a few certificates and does not incur the overhead of downloading an entire CRL for only a few entries. This greatly reduces the network traffic associated with certificate validation.

OCSP transports messages over HTTP for maximum compatibility with existing networks. This requires careful configuration of any caching servers in the network to avoid receiving a cached copy of an OCSP response that might be out of date.

The OCSP client communicates with an OCSP responder. The OCSP responder can be a CA server or another server that communicates with the CA server to determine the certificate status. The OCSP client issues a status request to an OCSP responder and suspends the acceptance of the certificate until the responder provides a response. The client request includes data such as protocol version, service request, target certificate identification and optional extensions. These optional extensions may or may not be acknowledged by the OCSP responder.

The OCSP responder receives the request from the client and checks that the message is properly formed and if the responder is able to respond to the service request. Then it checks if the request contains the correct information needed for the service desired. If all conditions are satisfied, the responder returns a definitive response to the OCSP client. The OCSP responder is required to provide a basic response of GOOD, REVOKED, or UNKNOWN. If both the OCSP client and responder support the optional extensions, other responses are possible. The GOOD state is the desired response as it indicates the certificate has not been revoked. The REVOKED state indicates that the certificate has been revoked. The UNKNOWN state indicates the responder does not have information about the certificate in question.

OCSP servers typically work with a CA server in push or pull setup. The CA server can be configured to push a CRL list (revocation list) to the OCSP server. Additionally the OCSP server can be configured to periodically download (pull) the CRL from the CA server. The OCSP server must also be configured with an OCSP response signing certificate issued by the CA server. The signing certificate must be properly formatted or the OCSP client will not accept the response from the OSCP server.

OpenCA OCSP Responder

Using OCSP requires the OpenCA (OpenSource Certificate Authority) OpenCA OCSP Responder as it is the only supported OCSP responder. OpenCA OCSP Responder is available at http://www.openca.org. The OpenCA OCSP Responder is an rfc2560 compliant OCSP responder that runs on a default port of 2560 in homage to being based on rfc2560.

Loading Certificates to Use with OCSP

For SonicOS to act as an OCSP client to a responder, the CA certificate must be loaded onto the firewall.

1
On the System -> Certificates page, click on the Import button. This will bring up the Import Certificate page.
2
Select the Import a CA certificate from a PKCS#7 (.p7b), PEM (.pem) or DER (.der or .cer) encoded file option and specify the location of the certificate.

Using OCSP with VPN Policies

The firewall OCSP settings can be configured on a policy level or globally. To configure OCSP checking for individual VPN policies, use the Advanced tab of the VPN Policy configuration page.

1
Select the radio button next to Enable OCSP Checking.
2
Specify the OCSP Responder URL of the OCSP server, for example http://192.168.168.220:2560 where 192.168.168.220 is the IP address of your OCSP server and 2560 is the default port of operation for the OpenCA OCSP responder service.

Configuring DHCP over VPN

VPN > DHCP over VPN

The VPN > DHCP over VPN page allows you to configure a firewall to obtain an IP address lease from a DHCP server at the other end of a VPN tunnel. In some network deployments, it is desirable to have all VPN networks on one logical IP subnet, and create the appearance of all VPN networks residing in one IP subnet address space. This facilitates IP address administration for the networks using VPN tunnels.

Topics:  

DHCP Relay Mode

The firewall at the remote and central sites are configured for VPN tunnels for initial DHCP traffic as well as subsequent IP traffic between the sites. The firewall at the remote site (Remote Gateway) passes DHCP broadcast packets through its VPN tunnel. The firewall at the central site (Central Gateway) relays DHCP packets from the client on the remote network to the DHCP server on the central site.

Configuring the Central Gateway for DHCP Over VPN

To configure DHCP over VPN for the Central Gateway:
1
Select VPN > DHCP over VPN.
2
Select Central Gateway from the DHCP over VPN drop-down menu.

3
Click Configure. The DHCP over VPN Configuration dialog is displayed.

4
Select one of the following
If you want to use the DHCP Server for global VPN clients or for a remote firewall or for both, select the Use Internal DHCP Server option.
a)
You can also select either or both of these:
To use the DHCP Server for global VPN clients, select the For Global VPN Clients option.
To use the DHCP Server for a remote firewall, select the Remote Firewall option.
If you want to send DHCP requests to specific servers, select Send DHCP requests to the server addresses listed below.
a)
Click Add. The Add DHCP Server dialog is displayed.

b)
Type the IP addresses of DHCP servers in the IP Address field.
c)
Click OK. The firewall now directs DHCP requests to the specified servers.
5
Type the IP address of a relay server in the Relay IP Address (Optional) field.

When set, this IP address is used as the DHCP Relay Agent IP address (giaddr) in place of this SonicWall’s LAN IP address. This address is only used when no Relay IP Address has been set on the Remote Gateway, and must be reserved in the DHCP scope on the DHCP server.

6
Click OK.

Configuring DHCP over VPN Remote Gateway

To configure DHCP over VPN Remote Gateway:
1
Select Remote Gateway from the DHCP over VPN drop-down menu.

2
Click Configure. The DHCP over VPN Configuration window is displayed.

 

3
In the General tab, the VPN policy name is automatically displayed in the Relay DHCP through this VPN Tunnel field if the VPN policy has the setting Local network obtains IP addresses using DHCP through this VPN Tunnel enabled.
* 
NOTE: Only VPN policies using IKE can be used as VPN tunnels for DHCP. The VPN tunnel must use IKE and the local network must be set appropriately. The local network obtains IP addresses using DHCP through this VPN Tunnel.
4
Select the interface the DHCP lease is bound from the DHCP lease bound to menu.
5
To accept DJCP requests from bridged WLAN interfaces, enable the Accept DJCP Request from bridged WLA interface checkbox.
6
If you enter an IP address in the Relay IP Address field, this IP address is used as the DHCP Relay Agent IP address (giaddr) in place of the Central Gateway’s address and must be reserved in the DHCP scope on the DHCP server. This address can also be used to manage this firewall remotely through the VPN tunnel from behind the Central Gateway.
* 
NOTE: The Relay IP address and Remote Management IP Address fields cannot be zero if management through the tunnel is required.
7
If you enter an IP address in the Remote Management IP Address field, this IP address is used to manage the firewall from behind the Central Gateway, and must be reserved in the DHCP scope on the DHCP server.
8
If you enable Block traffic through tunnel when IP spoof detected, the firewall blocks any traffic across the VPN tunnel that is spoofing an authenticated user’s IP address. If you have any static devices, however, you must ensure that the correct Ethernet address is typed for the device. The Ethernet address is used as part of the identification process, and an incorrect Ethernet address can cause the firewall to respond to IP spoofs.
9
If the VPN tunnel is disrupted, temporary DHCP leases can be obtained from the local DHCP server. Once the tunnel is again active, the local DHCP server stops issuing leases. Enable the Obtain temporary lease from local DHCP server if tunnel is down check box. By enabling this check box, you have a failover option in case the tunnel ceases to function.
10
If you want to allow temporary leases for a certain time period, type the number of minutes for the temporary lease in the Temporary Lease Time box. The default value is 2 minutes.
11
To configure devices on your LAN, click the Devices tab.

 

12
To configure Static Devices on the LAN, click Add to display the Add LAN Device Entry dialog.

 

13
Type the IP address of the device in the IP Address field and then type the Ethernet address of the device in the Ethernet Address field.

An example of a static device is a printer as it cannot obtain an IP lease dynamically. If you do not have Block traffic through tunnel when IP spoof detected enabled, it is not necessary to type the Ethernet address of a device. You must exclude the Static IP addresses from the pool of available IP addresses on the DHCP server so that the DHCP server does not assign these addresses to DHCP clients. You should also exclude the IP address used as the Relay IP Address. It is recommended to reserve a block of IP address to use as Relay IP addresses.

14
Click OK.
15
To exclude devices on your LAN, click Add to display the Add Excluded LAN Entry dialog.

16
Enter the MAC address of the device in the Ethernet Address field.
17
Click OK.
18
Click OK to exit the DHCP over VPN Configuration dialog.
* 
NOTE: You must configure the local DHCP server on the remote firewall to assign IP leases to these computers.
* 
NOTE: If a remote site has trouble connecting to a central gateway and obtaining a lease, verify that Deterministic Network Enhancer (DNE) is not enabled on the remote computer.
* 
TIP: If a static LAN IP address is outside of the DHCP scope, routing is possible to this IP, that is, two LANs.

Current DHCP over VPN Leases

The Current DHCP over VPN Leases table shows the details on the current bindings: IP Address, Host Name, Ethernet Address, Lease Time, and Tunnel Name. The last column in the table, Configure, enables you to configure or delete a table entry (binding): to

Edit a binding, click Edit.
Delete a binding, which frees the IP address in the DHCP server, select the binding from the list, and then click the Delete icon. The operation takes a few seconds to complete. When completed, a message confirming the update is displayed at the bottom of the Web browser window.
Delete all VPN leases, click Delete All.

Configuring L2TP Servers and VPN Client Access

VPN > L2TP Server

The SonicWall network security appliance can terminate L2TP-over-IPsec connections from incoming Microsoft Windows or Google Android clients. In situations where running the Global VPN Client is not possible, you can use the SonicWall L2TP Server to provide secure access to resources behind the firewall.

You can use Layer 2 Tunneling Protocol (L2TP) to create VPN over public networks such as the Internet. L2TP provides interoperability between different VPN vendors that protocols such as PPTP and L2F do not, although L2TP combines the best of both protocols and is an extension of them.

L2TP supports several of the authentication options supported by PPP, including Password Authentication Protocol (PAP), Challenge Handshake Authentication Protocol (CHAP), and Microsoft Challenge Handshake Authentication Protocol (MS-CHAP). You can use L2TP to authenticate the endpoints of a VPN tunnel to provide additional security, and you can implement it with IPsec to provide a secure, encrypted VPN solution.

Topics:  
* 
NOTE: For more complete information on configuring the L2TP Server, see the technote Configuring the L2TP Server on SonicOS located on the SonicWall support site: https://support.sonicwall.com/.

Configuring the L2TP Server

The VPN > L2TP Server page provides the settings for configuring the SonicWall network security appliance as a L2TP Server.

To configure the L2TP Server:
1
Select the Enable L2TP Server option.
2
Click Configure to display the L2TP Server Configuration dialog.
3
Select the L2TP Server tab.
4
Enter the number of seconds in the Keep alive time (secs) field to send special packets to keep the connection open. The default is 60 seconds.
5
Enter the IP address of your first DNS server in the DNS Server 1 field. If you have a second DNS server, type the IP address in the DNS Server 2 field.
6
Enter the IP address of your first WINS server in the WINS Server 1 field. If you have a second WINS server, type the IP address in the WINS Server 2 field.
7
Select the L2TP Users tab.

8
Select one of the following radio buttons for IP address settings:
If a RADIUS/LDAP server provides IP addressing information to the L2TP clients, select IP address provided by RADIUS/LDAP Server. By default, this option is not selected.
* 
NOTE: To use this option RADIUS or LDAP authentication must be selected on the User Settings page. If this option is selected, an informational message to this effect is displayed. click OK.

The Start IP and End IP fields become dimmed. Go to Step 10.

If the L2TP Server provides IP addresses, select Use the Local L2TP IP pool. This is the default IP address setting.
9
Enter the range of private IP addresses in the Start IP and End IP fields. The private IP addresses should be a range of IP addresses on the LAN.
10
If you have configured a specific user group defined for using L2TP, select it from the User Group for L2TP users menu or use Everyone.
11
Click OK.
PPP Tab

The PPP Settings panel under the PPP tab enables you to add or remove authentication protocols, or rearrange the preferred order of the authentication protocols with the Up and Down arrows.

Viewing Currently Active L2TP Sessions

The Active L2TP Sessions panel displays the currently active L2TP sessions.

The following information is displayed.

User Name - The user name assigned in the local user database or the RADIUS user database.
PPP IP - The source IP address of the connection.
Zone - The zone used by the L2TP client.
Interface - The interface used to access the L2TP Server, whether it is a VPN client or another firewall.
Authentication - Type of authentication used by the L2TP client.
Host Name - The name of the L2TP client connecting to the L2TP Server.

Configuring Microsoft Windows L2TP VPN Client Access

This section provides a configuration example for enabling L2TP client access to the WAN GroupVPN SA using the built-in L2TP Server and Microsoft's L2TP VPN Client.

* 
NOTE: SonicOS supports only X.509 certificates for L2TP clients; PKCS #7 encoded X.509 certificates are not supported in SonicOS for L2TP connections.
To enable Microsoft L2TP VPN Client access to the WAN GroupVPN SA:
1
Navigate to the VPN > Settings page.
2
For the WAN GroupVPN policy, click the Configure icon.
3
On the General tab, select IKE using Preshared Secret from the Authentication Method drop-down menu.
4
Enter a shared secret passphrase in the Shared Secret field to complete the client policy configuration.
5
Click the OK button.
6
Navigate to the VPN > L2TP Server page.
7
In the L2TP Server Settings section, click the Enable the L2TP Server checkbox.
8
Click the Configure button. The L2TP Server Settings dialog displays.

9
Provide the following L2TP server settings:
Keep alive time (secs): 60
DNS Server 1: 199.2.252.10 (or use your ISP’s DNS)
DNS Server 2: 4.2.2.2 (or use your ISP’s DNS)
DNS Server 3: 0.0.0.0 (or use your ISP’s DNS)
WINS Server 1: 0.0.0.0 (or use your WINS IP)
WINS Server 2: 0.0.0.0 (or use your WINS IP)
10
Provide the IP address settings:
Use the Local L2TP IP pool: Enabled (selected; the default)
Start IP: 10.20.0.1 (example)
End IP: 10.20.0.20 (example)
* 
NOTE: Use any unique private range.
11
In the L2TP Users section, select Trusted Users from the User group for L2TP users drop-down menu.
12
Navigate to the Users > Local Users page.
13
Click the Add User button. The Add User dialog displays.

14
Specify a user name and password in the Name, Password, and Confirm Password fields.
15
Click OK.
* 
NOTE: By editing the Firewall > Access Rules for the VPN LAN zone or another VPN zone, you can restrict network access for L2TP clients. To locate a rule to edit, select the All Rules view of the Access Rules table and look at the Source column. The address object in the Source column of applicable rows displays "L2TP IP Pool".
16
On your Microsoft Windows computer, complete the following L2TP VPN Client configuration to enable secure access:
Navigate to the Windows > Start > Control Panel > Network Connections.
Open the New Connection Wizard. Click Next.
Choose "Connect to the network at my workplace." Click Next.
Choose "Virtual Private Network Connection." Click Next.
Enter a name for your VPN connection. Click Next.
Enter the Public (WAN) IP address of the firewall. Alternatively, you can use a domain name that points to the firewall. Click Next, then click Finish. The connection window will appear. Click Properties.
Click the Security tab. Click on "IPSec Settings". Enable "Use pre-shared key for authentication". Enter your pre-shared secret. Click OK.
Click the Networking tab. Change "Type of VPN" from "Automatic" to "L2TP IPSec VPN". Click OK.
10) Enter your XAUTH username and password. Click Connect.
17
Verify your Microsoft Windows L2TP VPN device is connected by navigating to the VPN > Settings page. The VPN client is displayed in the Currently Active VPN Tunnels section.

Configuring Google Android L2TP VPN Client Access

This section provides a configuration example for enabling L2TP client access to WAN GroupVPN SA using the built-in L2TP Server and Google Android’s L2TP VPN Client.

To enable Google Android L2TP VPN Client access to WAN GroupVPN SA, perform the following steps:
1
Navigate to the VPN > Settings page.
2
For the WAN GroupVPN policy, click the Configure icon. The VPN Policy dialog displays.

3
Select IKE using Preshared Secret (default) from the Authentication Method drop-down menu.
4
Enter a shared secret passphrase in the Shared Secret field to complete the client policy configuration.
5
Click the Proposals tab.

6
Provide the following settings for IKE (Phase 1) Proposal:
DH Group: Group 2
Encryption: 3DES
Authentication: SHA1
Life Time (seconds): 28800
7
Provide the following settings for IPsec (Phase 2) Proposal:
Protocol: ESP
Encryption: DES
Authentication: SHA1
Enable Perfect Forward Secrecy: Enabled
Life Time (seconds): 28800
8
Click the Advanced tab.

9
Provide the following settings:
Enable Windows Networking (NetBIOS) Broadcast: Enabled
Enable Multicast: Disabled
Management via this SA: Disabled all
Default Gateway: 0.0.0.0
Require authentication of VPN clients by XAUTH: Enabled
User group for XAUTH users: Trusted Users
10
In the Client tab, provide the following settings:
Cache XAUTH User Name and Password on Client: Single Session or Always
Virtual Adapter setting: DHCP Lease
Allow Connections to: Split Tunnels
Set Default Route as this Gateway: Disabled
Use Default Key for Simple Client Provisioning: Enabled
11
Navigate to the VPN > L2TP Server page. In the L2TP Server Settings section, click the Enable the L2TP Server checkbox. And click the Configure button. The L2TP Server Settings configuration page displays.
12
Provide the following L2TP server settings:
Keep alive time (secs): 60
DNS Server 1: 199.2.252.10 (or use your ISPs DNS)
DNS Server 2: 4.2.2.2 (or use your ISPs DNS)
DNS Server 3: 0.0.0.0 (or use your ISPs DNS)
WINS Server 1: 0.0.0.0 (or use your WINS IP)
WINS Server 2: 0.0.0.0 (or use your WINS IP)
13
Provide the IP address settings:
IP address provided by RADIUS/LDAP Server: Disabled
Use the Local L2TP IP Pool: Enabled
Start IP: 10.20.0.1 (example)
End IP: 10.20.0.20 (example)
* 
NOTE: Use any unique private range.
14
In the L2TP Users section, select Trusted Users from the User Group for L2TP Users drop-down menu.
15
Navigate to the Users > Local Users page. Click the Add User button.
16
In the Settings tab, specify a user name and password.
17
In the VPN Access tab, add the desired network address object(s) that the L2TP clients to the access list networks.
* 
NOTE: At the minimum add the LAN Subnets, LAN Primary Subnet, and L2TP IP Pool address objects to the access list.
* 
NOTE: You have now completed the SonicOS configuration.
18
On your Google Android device, complete the following L2TP VPN Client configuration to enable secure access:
Navigate to the APP page, and select the Settings icon. From the Settings menu, select Wireless & networks.
Select VPN Settings, and click Add VPN.
Select Add L2TP/IPSec PSK VPN.
VPN Name: enter a VPN friendly name
Set VPN Server: enter the public IP address of firewall
Set IPSec pre-shared key: enter the passphrase for your WAN GroupVPN policy
L2TP secret: leave blank
LAN domain: optional setting
Enter your XAUTH username and password. Click Connect.
19
Verify your Google Android device is connected by navigating to the VPN > Settings page. The VPN client is displayed in the Currently Active VPN Tunnels section.