VPN

by Lisa Phifer VP Core Competence, Inc. [October 25, 2001]

Earlier this year, ISP-Planet launched a VPN Appliance Review Series, evaluating IPsec hardware devices suitable for ISP deployment to broadband-enabled businesses of 10 to 200 employees. We gathered four responses that appeared, at least on paper, to satisfy our RFP. Our next step—a lab evaluation. By digging into each vendor's proposed solution, we hoped to compare and contrast these offerings.

Here, we publish part two of the first set of results, describing our lab experience with SonicWALL PRO-VX, SOHO2, and TELE2 Internet appliances. These devices, designed for use in small-to-midsize networks, can be centrally provisioned through SGMS, SonicWALL's central policy manager. If you need a brief review of what we've accomplished so far, start with Part One.

Firewall Configuration
SonicWALLs are ICSA-certified stateful packet inspection firewalls. The default ruleset is typical—block incoming; allow outgoing (example left). The PRO-VX also allows anything between the DMZ and WAN. Network access at the interface level is superceded by service-level rules. For example, when you configure VPN, a service rule is added to permit incoming Internet Key Exchange (IKE). This over-rides the default network access settings that block incoming traffic.

Rules can apply to interfaces, subnets, contiguous ranges, or hosts. Rules refer to a named service, defined by protocol and port; common services are built-in, others can be added. Rules cannot refer to non-contiguous address groups, but services added with the same name can be referenced together in one rule. Unfortunately, each protocol/port number can only have one name. For example, we wanted to limit outgoing access to HTTP, FTP, POP, etc. But we also wanted to permit HTTP to/from the DMZ. To do this, we had to create three separate rules:

1. DMZ-HTTP
2. LAN-HTTP, and
3. LAN-AllowOut (our service group).

This is straightforward on a small scale, but verbose in complex rulesets.

Network access settings can forward incoming packets to "public" servers on the LAN behind the firewall. For example, HTTP sent to the firewall's WAN IP can be relayed to one web server on the LAN. To expose a group of servers, 1-to-1 NAT can map a block of public WAN IPs to a block of private LAN IPs (example right). You may prefer to put servers on the PRO-VX DMZ, but there's a catch—DMZ IPs must be valid on the WAN (they cannot be NAT'ed). This restriction can eat into your public IP block and complicate WAN-side routing. (Like many firewalls, the SonicWALL does not support dynamic routing.)

Other handy firewall features include an option to relay NetBIOS broadcasts to the DMZ or WAN, a "stealth mode" that makes the firewall non-pingable, and the ability to relay (proxy) outbound HTTP to a web cache.

SonicWALLs firewall with or without NAT (actually NAPT). When NAT is enabled, the firewall's WAN IP can be assigned by a PPPoE or DHCP server. This is useful for teleworkers without static IPs, but not that VPN gateways with dynamic IPs are limited to IKE Aggressive Mode (See Site-to-Site VPN below). Like many firewalls, the SonicWALL can serve DHCP to hosts on the LAN (example left). This DHCP server can bind IPs to MAC addresses, preventing rogue LAN use. However, it cannot assign VPN Client IPs or proxy DHCP across the VPN.

(Back to Top)

Site-to-Site VPN Setup
VPN setup on a SonicWALL is simpler—and less flexible—than many other products. SonicWALL supports standard IPsec in tunnel mode, including ESP and AH with mandatory HMAC (MD5, SHA1) and encryption (null, DES, 3DES) algorithms. A single pull-down menu lists all legal permutations, plus ESP ArcFour and "CheckPoint interoperability" alternatives (example below).

The transform chosen from this pull-down applies to both IKE and IPsec; this single proposal leaves no room for negotiation. Perfect forward secrecy (PFS) is available, but limited to Diffie-Hellman Group 1. Tunnel lifetime can be specified in seconds, but not bytes. By default, Identities are firewall serial numbers; IP addresses are also supported. IKE Phase 1 mode (Main or Aggressive) is determined by ID type. Eliminating uncommon options is a good way to simplify setup, but we'd like to see support for DH Group 2, separate control of IKE and IPsec lifetimes, and stronger tools for multi-vendor debugging (See Diagnostics and Logging).

SonicWALL gateways can authenticate each other by pre-shared secret (PSS) or digital certificate. Pre-shared secrets are alphanumeric passwords that should be hard to guess. SGMS generates random 10 hex-digit secrets; up to 128 characters are allowed. In a site-to-site VPN, every gateway must be configured with the ID and PSS of every peer gateway, but it's critical to keep these secrets … well, secret.

Certificate authentication is more secure and scales better because it eliminates the need to share secrets. Instead, every SonicWALL is configured with an Administrator Certificate by purchasing SonicWALL's Authentication Service (example left). Export the Admin Cert for safe keeping immediately; you'll need to import it after firmware wipe. There is no option to trust certificates issued by another Certificate Authority.

In our opinion, this solution is wonderfully turnkey but rather expensive and inflexible. Our RFP scenario illustrates both: by investing $2175 on certificates for our 5-node office, we get strong authentication without creating or maintaining a PKI. But issuing certs to TELE2's and VPN Clients could run up a big tab, so we'd like the option to use our own CA.

(Back to Top)

Site-to-Site Topologies
SonicWALL supports full-mesh and hub-and-spoke VPNs. Hub-and-spoke can be less efficient, but simplifies deployment. Teleworkers can reach any office using one tunnel to the hub. Branch offices can have direct Internet access - or they can relay Internet traffic through the hub. To configure hub-and-spoke, check the "forward packets" option on each hub policy. On each spoke policy, broaden subnets to include branch offices and/or use the "route Internet traffic" option. The hub GUI shows tunnels established on demand to relay packets between spokes (example below).

VPN topology limitations—branch office subnets cannot overlap, and DMZ nodes cannot be included in VPNs (recall that the DMZ uses WAN, not LAN, addresses). Handy VPN options—accepting fragments through tunnels—useful when encrypted packets exceed MTU and blocking Windows share announcements—NetBIOS broadcasts are a common teleworker "leak".

During site-to-site VPN tests, we experienced directional tunnel (re)initiation problems. Tunnels could be initiated by spokes, but not the hub and would not reopen after device reboot. The culprit was a corrupted IKE rule in our SOHO2 and TELE2. We never determined how this default rule got mangled in both units. Once it was fixed, tunnels could be (re)established from either end. Remaining hangups faded after upgrading to firmware 6.1.1.0b2—this new release adds "keep alives" that detect far-end failures.

(Back to Top)

Remote Access VPN
To enable VPN Client access, visit mysonicwall.com to activate the included "upgrade" (example left). This produces a license key for the gateway SonicWALL and URLs for downloading client software and documentation.

By default, every SonicWALL includes a disabled "VPN Group" policy that lets any client with any IP tunnel into the LAN using a group PSS. This policy should be enabled only after serious consideration. That PSS will be all that stands between your LAN and any client. If your secret is easily-guessed or accidentally/intentionally disclosed, your LAN may have unexpected visitors. Alternatives to replace or refine the default "VPN Group" policy include the following:

• It is uncommon, but clients with static IPs can be handled by address-specific policies. Another uncommon alternative is using manual keys instead of IKE.
• Use XAUTH to require extended user-level authentication. The client must enter a login and password, respond to a challenge, or enter a one-time token. Responses are authenticated by a RADIUS server, after PSS authentication.
• Clients can be authenticated by personal certificates, issued by VeriSign OnSite. This requires another SonicWALL Authentication Service upgrade, available in one, 10, 50, and 100 client increments.

The SonicWALL generates a VPN Client policy file for distribution, along with software, to remote users. Users run the SonicWALL (SafeNet) VPN Client installer, then import the policy file (example right). When using PSS or XAUTH, admins may want to "lock" the policy file, preventing changes.

(Back to Top)

VPN Client Policy Refinements
Locking the policy isn't practical when using certificates. A SonicWALL Admin generates a certificate request on the user's behalf (below left). The user receives email containing a PIN and URL to complete enrollment. Using Internet Explorer with 128-bit encryption, he visits the URL, enters the PIN, and responds to a challenge like "What is your SSN?" The user obtains a personal certificate and exports it, along with a key pair, to a password-protected file. He then launches the VPN Client's Certificate Manager to import the certificate. Finally, he launches the VPN Client's Policy Editor to apply the certificate to the SonicWALL-generated policy. This somewhat lengthy process leverages PKI features in existing desktop software (IE) to get the job done.

Policy edits are also needed to specify a virtual IP address (VIP). A VIP lets the client tunnel packets with a source address from the target LAN. The SonicWALL does not support dynamic VIPs. Instead, the administrator picks a static VIP, gives it to the user, and configures return routes using the SonicWALL's "Network" and "Intranet" GUI menus.

One case where VIPs are useful is hub-and-spoke VPNs. Clients can reach spoke subnets by tunneling to the hub. To do so, the client policy must be edited to include spoke subnets in the Remote Party Address. Packet forwarding must be enabled in the hub's "Group VPN" policy, and spoke policies must be expanded to allow packets from the VIP subnet(s).

During remote access VPN tests, we experienced two puzzling problems. First, we simply could not get XAUTH to work with HMAC-SHA1. (Combining HMAC-MD5 and XAUTH was fine.) Next, we tested XAUTH with our Interlink AAA Engine. Some RADIUS requests inexplicably failed; AAA logs showed the SonicWALL truncating login/password strings over 20 characters. Tech support confirmed both were bugs, to be fixed in a future release.

(Back to Top)

Global Management
A device-level GUI is fine for managing networks of the size described in our RFP scenarios. But an ISP offering managed VPN services may need to provision, monitor, and maintain hundreds of SonicWALLs. That's where the SonicWALL Global Management System (SGMS) comes in. We tested out SGMS 1.x with a 30-day demo license.

Start by deciding where to put SGMS. An Apache web server will be added to the host PC, even if IIS is already installed. Outgoing Internet access will be required to complete registration and download files from SonicWALL. SGMS will mail cleartext alerts and logs to an SMTP server, so think about how to secure that stream. Incoming access will be required to receive SYSLOG traffic; allow one KB of bandwidth per managed device.

Originally designed to run on the WAN, SGMS 1.x automatically installs a VPN Client and manual keys to tunnel to each managed device (example right). This fixed policy (MD5/DES) is far better than cleartext, but not as secure as it could be. We applied an update patch that let us re-install SGMS inside our HQ LAN, using site-to-site tunnels to protect SGMS traffic to branch office SonicWALLs. That setup is less turnkey, but more flexible—and perhaps more appropriate for the large customers likely to use SGMS.

For example, an ISP can pre-configure each SonicWALL with an Admin Certificate and a tunnel to the NOC gateway. The ISP adds the device to SGMS, entering a password and serial number, then ships it to the customer's location. When the customer powers up his new SonicWALL, it "phones home" over this strongly-authenticated tunnel. Thereafter, the SonicWALL can be managed securely from the NOC, using SGMS. This brings us to the classic "chicken and egg" problem—when SGMS tunnels to a managed device, it cannot safely update that tunnel. Once management tunnels are in place, don't touch them.

(Back to Top)

SGMS Console and Policy
SGMS has two main windows. A Console window is used to mail/view SGMS logs, configure task schedules and SYSLOG parameters, and apply software/license upgrades (examples left). A Policy window is used to manage three-tiered security policies, configured at Global, Group, and Device levels.

Configuring policy with SGMS schedules tasks that push changes to each affected device (examples right). For example, global tasks can reset all device passwords to random values, reboot all devices, or to add new routes to all devices. Task results are recorded in the SGMS log, viewed from the Console window. In the example shown here, we reconfigured our RADIUS server IP, port, and secret at the global level, accepting defaults for other parameters. Unfortunately, one SGMS-supplied default was invalid, causing all tasks to fail.

Groups are used to apply the same change to many devices—for example, applying the same initial configuration to each branch office SOHO2. Power tools like this are big time-savers that warrant caution. Widespread changes can be implemented with a few mouse clicks, but recovering from operator error can be more difficult. For example, we added a route that was good for every device—except one. That device promptly went AWOL, requiring manual intervention.

SGMS includes an easy-to-use "A-to-B" VPN configurator. If you enter all the details, SGMS can configure a tunnel to anywhere (example left). But when both gateways are managed by SGMS, just select the remote SonicWALL and encryption method. SGMS generates a random shared secret and complementary policies for both gateways. This short-cut avoids address-entry errors, making it easy to configure a full-mesh VPN.

SGMS releases inevitably lag SonicWALL firmware/GUI releases. For example, SGMS 1.1 was released before 5.0.0 firmware, so newer features like certificates and hub-and-spoke VPNs cannot be configured from the tested version of SGMS. Fortunately, SGMS also provides "cut through" access to the device GUI. The SGMS 1.1.1 patch added device-level synchronization, letting SGMS learn about updates made through the device GUI. In general, we found ourselves using SGMS for multi-device operations, cutting through to the device GUI for single box tasks.

After we finished testing SGMS 1.1.2, SonicWALL released a major SGMS overhaul. SGMS 2.0 introduces a two-tier architecture with separate consoles and agents to boost scalability tenfold and add fault tolerance. This new release adds multiple administrator logins with views that limit access to selected menus, groups, and devices. It also offers an API for exporting info to databases and other systems—for example, integrate SGMS 2.0 with a billing system to invoice by configured tunnel.

(Back to Top)

Logging and Diagnostics
SonicWALLs may have little or no CLI, but the GUI includes several handy diagnostic tools. In addition to DNS lookup and ping, Packet Trace monitors TCP connection establishment to a host—useful to assess connection blocking. Network Path displays routing, ARP, and reachability info for an IP—good for debugging link and network-level failures (example right). In addition, the VPN GUI shows active tunnels and makes it possible to rekey (but not disconnect) each tunnel.

SonicWALL logs can be viewed through the GUI, forwarded by email, or sent to a SYSLOG server. Settings control detail—for example, log dropped packets by application type—but we'd like to see more. For example, disabling "Dropped ICMP" logging eliminates redirect noise, but also hides pings. "Network Debug" logging lets you see IKE messages (example left), but not incoming or outgoing transform proposals. This can present a challenge during multi-vendor VPN setup—or when diagnosing a badly configured VPN Client.

We aimed port scanners and a WebTrends Security Analyzer at our PRO-VX, finding no vulnerabilities or open ports when the device was in "stealth mode". Our activity appeared in the log as a probable scan, with some probed ports flagged as trojans (example right). The good news—a scan is hard to miss. The bad news—"doorknob rattling" can fill the log with distracting messages. Log settings can enable/disable logging for dropped TCP/UDP, ping-of-death, spoof, or SYN flood attacks. A commercial analyzer like WebTrends can also be used to condense lengthy logs into more concise reports.

We had a few unexplained SOHO2/TELE2 reboots, under very light traffic. Faults and other undesirable events can be detected in three ways. First, SonicWALLs can be configured to send email alerts, controlled by three toggles—attacks, system errors, and blocked websites. Second, enterprises that use SNMP monitoring can listen to SonicWALL traps or poll standard MIB-II objects. These device-level hooks are fairly basic—in particular, we'd like to have more granular control over alerts that we'd mail to a pager.

The third way is to monitor device status is with the SGMS EVENTMON web page (example left). SGMS operates as a SYSLOG server, collecting logs from managed devices. However, SGMS is not a fault management system - for example, it does not try to track VPN tunnel status or alert on tunnel failure. SGMS is really focused on central provisioning.

In mid-August, SonicWALL released ViewPoint, a browser-based reporting tool that collects and analyzes SonicWALL logs, providing historical and real-time reports on web, ftp, and email usage, system events, and attacks for a single device. ViewPoint is free to PRO-VX owners. Unfortunately, ViewPoint cannot run concurrently with SGMS 1.x, because are SYSLOG servers. Basic web or bandwidth usage reports can also be obtained directly from the SonicWALL GUI, using stats collected by the device since last enable or reboot.

(Back to Top)

Additional Services
Our lab eval focused on managed VPN features, but some ISPs may want to the same platform to offer these "a la carte" services:

• Network Vulnerability Scan: Each device includes one free McAfee VScan that produces a baseline vulnerability report for the SonicWALL. This subscription service may be renewed to repeat VScan, either to verify that discovered holes have been closed or to periodically check for new holes in your perimeter defense.
• Network Anti-Virus Subscription: Each SonicWALL includes a 15-day trial to scan up to 5 hosts. After that, you'll need to purchase one VirusScan ASaP license per host. This service scans hosts on the LAN or DMZ, ensuring that A/V software on each is updated periodically or upon virus alert.
• Internet Content Filtering Service: Each SonicWALL can log or block access to a dozen categories, based on site lists that may be updated by purchasing an annual subscription. This feature can also be configured to block web traffic by keywords, ActiveX, Java, and cookies.
• High Availability: The PRO-VX can be deployed in a redundant pair. A "heartbeat" is exchanged over the LAN between primary and backup to detect device failure; this does not detect WAN connectivity failures. Configuration changes to the active PRO-VX are automatically synchronized to the backup. No additional software is required, but we could not test this feature because we received only one PRO-VX.

—End Part Two—