VPN_vpnAdvancedView

VPN > Advanced

The VPN > Advanced page includes optional settings that affect all VPN policies.

Advanced VPN Settings

•

Enable IKE Dead Peer Detection - Select if you want inactive VPN tunnels to be dropped by the SonicWALL.

–

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 SonicWALL security appliance. The SonicWALL security appliance 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 SonicWALL security appliance 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 SonicWALL 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.

•

Preserve IKE Port for Pass-Through Connections - Preserves UDP 500/4500 source port and IP address information for pass-through VPN connections.

•

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 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.

•

Send IKEv2 Cookie Notify - Sends cookies to IKEv2 peers as an authentication tool.

•

Use RADIUS in - When using RADUIS to authenticate VPN client users, RADIUS will be used in its MSCHAP (or MSCHAPv2) mode. The primary reason for choosing to do this would be so that VPN client users can make use of the MSCHAP feature to allow them to change expired passwords at login time.

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 will allow password updates, then password updates for VPN client users will be done using MSCHAP-mode RADIUS after using LDAP to authenticate the user.

Note

Password updates can only be done by LDAP when using Active Directory with TLS and binding to it using an administrative account, or when using Novell eDirectory.

•

IKEv2 Dynamic Client Proposal - SonicOS Enhanced firmware versions 4.0 and higher provide 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 window.

Previously, only the default settings were supported: Diffie-Hellman (DH) Group 2, the 3DES encryption algorithm, and the SHA1 authentication method. SonicOS now allows the following IKE Proposal settings:

–

DH Group : 1, 2, 5, or 14

–

Encryption : DES, 3DES, AES-128, AES-192, AES-256

–

Authentication : MD5, SHA1

However, if a VPN Policy with IKEv2 exchange mode and a 0.0.0.0 IPSec gateway is defined, 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 Security Appliances

Online Certificate Status Protocol (OCSP) allows you to check VPN certificate status without CRLs. This allows timely updates regarding the status of the certificates used on your SonicWALL.

About OCSP

OCSP is designed to augment or replace Certificate Revocation Lists (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/ocspd/ . 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 SonicWALL.

Step 1

On the System -> Certificates page, click on the Import button. This will bring up the Import Certificate page.

Step 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 SonicWALL 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.

Step 1

Select the radio button next to Enable OCSP Checking .

Step 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.