SonicOS VPN Features

  Increased VPN Functionality with SonicOS

SonicOS and it's associated VPN Support is provided in 2 versions. SonicOS Standard is designed for Ease of Use and Rapid Deployment for typical networks. SonicOS Enhanced supports business continuity features and additional VPN functionality features to provide finer control over management of the business traffic and is designed for more complex networks

The following table describes the VPN features available in SonicOS and indicates the primary differences between feature availability in SonicOS 2.0 Standard and SonicOS 2.0 Enhanced.

VPN Feature	STD	ENH
Site-to-Site VPN Configurations 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 SonicWALL (hub), such as a corporate SonicWALL. 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. Mesh Design - All sites connect to all other sites. All sites must have static IP addresses.	Yes	Yes
Remote Access (Group VPN) Supports the use of SonicWALL's Global VPN Client for remote access	Yes	Yes
MD5/SHA1 authentication Supports MD5 and SHA1 hash algorithms as part of the Encapsulated Security Payload (ESP)	Yes	Yes
DES/3DES/ARC4/tunnel only Supports DES, 3DES and ARC4 encryption algorithms. DES is a symmetric encryption algorithm that uses a56 bit key. 3DES is a variation on DES that uses a 168-bit key. ARC4 is used for communications with secure Web sites using the SSL protocol and uses a 56 bit key.	Yes	Yes
AES Support for AES-128,192,256 Supports the AES encryption algorithm for IPSec phase 1 and phase 2. SonicOS supports AES-128, AES-192, and AES-256. The appliances onboard security processor performs all AES functions in hardware	Yes	Yes
Manual Key Specify the Encryption and Authentication keys as well as Incoming and Outgoing Security Parameter Indices (SPI).	Yes	Yes
Internet Key Exchange (IKE) using pre-shared secrets A predefined parameter is exchanged between the two sides of an IPSec negotiation.	Yes	Yes
Internet Key Exchange (IKE) using certificates A digital certificate is exchanged between the two sides of an IPSec negotiation.	Yes	Yes
XAUTH Authentication Requires that all inbound traffic on an SA is from an authenticated user. Unauthenticated traffic is not allowed on the VPN tunnel.	Yes	Yes
3rd Party Certificate Authority support A digital certificate is an electronic means to verify identity by a trusted third party known as a Certificate Authority (CA). SonicOS supports third party certificates.	Yes	Yes
Main mode Phase 1 of an IKE SA negotiation. Main Mode is used to negotiate keys when both sides of the IKE negotiation have static IPs	Yes	Yes
Aggressive mode Alternative to Main Mode for Phase 1 of an IKE SA negotiation. Aggressive Mode is used when one side of the IKE negotiation has a dynamic IP	Yes	Yes
NAT Traversal 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	Yes	Yes
Single Armed mode VPN Allows you to deploy a SonicWALL with single port (WAN) utilized as a VPN tunnel termination point. Clear text traffic is routed to the single interface and the data is encapsulated to the appropriate IPSec gateway.	Yes	Yes
DHCP Relay Allows a Host (DHCP Client) behind a SonicWALL 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.	Yes	Yes
RIPv2 advertising RIP is a routing protocol comprised of all the mechanisms by which individual routers, and groups of routers, discover, organize, and communicate network topologies. Routers running RIP periodically advertise their routes to adjacent routers about every 30 seconds. The RIPv2 advertisement is contained in a UDP packet with source and destination ports 520.	Yes	Yes
NetBIOS pass through Computers running Microsoft Windows communicate with one another through NetBIOS broadcast packets. SonicOS allows broadcasts from the LAN to the OPT/DMZ. and from the LAN to the WAN.	Yes	Yes
SNMP VPN MIB SNMP (Simple Network Management Protocol) is a network protocol used over User Datagram Protocol (UDP) that allows network administrators to monitor the status of the SonicWALL and receive notification of critical events as they occur on the network. SonicOS supports SNMP v1/v2c and all relevant Management Information Base II (MIB) groups except egp and at.	Yes	Yes
L2TP server Accept incoming L2TP connections from remote clients or remote peers.	Yes	Yes
Secondary IPSec Gateway/Redundant Peer GW Assures network continuity is maintained by allowing the user to deploy a back-up gateway appliance for site-to-site VPN connections. If a connection to the primary gateway is lost, the site-to-site connection is established using the back-up gateway.	Yes	Yes
Definable source & destination networks Define network address objects, group those objects together, and then assign those objects as the source and destination networks to exchange when a VPN tunnel is established. This feature allows the user to control exactly which subnets are exchanged with remote peers.	No	Yes
Definable IKE Identities Specify the firewall’s IKE identity and the expected remote peer IKE identity. This feature makes interoperating with certain manufacturers easier, as it is now possible to control what is sent and what is expected. Users can specify that the IKE Identities be an IP Address, or an Email Address, or a Domain Name (FQDN).	No	Yes
Group VPN Destination Objects When creating users and groups, the user can define which network objects are bound to a specific group or user. When a Global VPN Client attempts to make a connection to the SonicWALL, the firewall examines the user name that is passed to it during XAUTH authentication. It first checks the user’s group, then checks the user account to see if there are additional networks allowed.	No	Yes
NAT & Firewall rules for VPN traffic Drive all incoming and outgoing VPN traffic through the zone security policy and the NAT policy. This allows users to restrict traffic to and from VPN tunnels, and to perform NAT on traffic before it goes into a VPN tunnel, or after it leaves a VPN tunnel on the way to a zone.	No	Yes
Multiple interface binding Allows both WAN interfaces to initiate and respond to VPN tunnel requests. In previous versions of firmware, the VPN tunnels appeared to terminate on the WAN or WLAN ports, but in reality they were bound to the LAN port.	No	Yes
Per Tunnel Access Control using User Groups Users inherit settings (privileges and VPN client access networks) from all user groups to which they have direct membership, including the “Everyone” group.	No	Yes