VPN

VPN RFP Lab Eval: NetScreen Products As Tested The Platforms Building The Network Firewall Policies

by Lisa Phifer VP Core Competence, Inc. [December 6, 2001]

Several months ago, ISP-Planet issued a Request For Proposal (RFP) for Virtual Private Network (VPN) appliances suitable for Internet Service Providers' (ISPs) deployment to broadband-enabled businesses of 10-200 employees. Using vendor RFP responses to build our short-list, we invited four contenders to submit their solutions to our lab for hands-on evaluation. In previous installments, we evaluated the solutions proposed by SonicWALL and RapidStream.

Here, we publish our third installment, evaluating Customer Premise Equipment (CPE) manufactured by NetScreen Technologies. The NetScreen-100 is a firewall/VPN/traffic management appliance for collocation facilities and medium-to-large enterprises. The NetScreen-5XP is an entry-level Internet appliance for small offices and teleworkers. Both can be provisioned and monitored from a NOC with NetScreen's Global Manager or Global PRO.

The Platforms
The tested products represent NetScreen's solution for RFP scenario #3: a distributed business with 200 employees (100 at headquarters, 4 branch offices, 50 mobile users). We evaluated the following configuration:

At our "headquarters," we installed a redundant pair of NetScreen-100's ($9,995 each), configured for high-availability. These 1U rack-mountable units are based on NetScreen's GigaScreen, a custom Application Specific Integrated Circuit (ASIC) designed to accelerate firewall, VPN, and Public Key Infrastructure (PKI) processing. The NetScreen-100 includes a GigaScreen ASIC, a Central Processing Unit (CPU) running ScreenOS, and three 10/100 Ethernet ports. This appliance supports up to 128,000 concurrent Transmission Control Protocol (TCP) sessions and 1000 VPN tunnels.

At each "branch office" and "teleworker" node, we installed a NetScreen-5XP Elite ($995). The Elite does not limit the number of LAN users; the entry-level 5XP ($495) allows up to 10 concurrent users. This one-pound metal enclosure, smaller than a paperback, contains a GigaScreen ASIC, a CPU running ScreenOS, 4 MB flash memory, and two 10Base-T ports. Both 5XP models support up to 2000 concurrent TCP sessions and 10 VPN tunnels.

According to NetScreen, the NetScreen-100 operates at line speed, firewalling up to 200 Mbps (cleartext) or 190 Mbps (1600 byte packets, 3DES-encrypted). The NetScreen-5XP handles symmetric 10 Mbps, cleartext or encrypted. Test reports for these products are available from the Tolly Group. But remember that VPN performance is affected by many factors. According to NetScreen's RFP response, throughput drops to 30 Mbps (NS-100) and 2 Mbps (NS-5XP) when encrypting short 64-byte packets. On the other hand, NetScreen's peak throughput is symmetric; some other products do their best only if traffic is asymmetric. These examples illustrate why buyers should always calibrate performance expectations in the target network, using actual customer workloads.

(Back to Top)

Building The Network
We connected NetScreen "untrusted" interfaces to a shared hub with Internet access, assigning each a static public Internet Protocol (IP) address. "Trusted" interfaces were initially connected to non-overlapping private subnets, hidden behind Network Address Translation (NAT). We should note that our lab test also reconfigured 5XPs with overlapping private subnets; see Policy-Based NAT. The configuration of standby and active NetScreen-100's were identical, except that each had another unique IP address for management.

We placed our public web server on the HQ private subnet because DMZ ports were dedicated to synchronization between the High Availability (HA) pair. We tapped two local Remote Authentication Dial-In User Service (RADIUS) servers -- Interlink AAA Engine and Funk Steel-Belted RADIUS -- for user authentication. Digital certificates were issued and signed by a private Microsoft CA, located offsite at OpusOne.

On our "traveler" laptop, we installed NetScreen-Remote v5.1.3b4, an Original Equipment Manufacturer (OEM) of SafeNet's VPN client for Win32. Client licenses are not included with appliances; they are priced by volume, ranging from 10 clients for $95 ($9.50 each) to an unlimited-use license ($1995). We tested NetScreen-Remote over Ethernet and analog dial, using "vanilla" IPsec and layer two tunneling protocol (L2TP) over IP security (IPsec).

On our "manager" station, we installed NetScreen's Global Manager ($4,995 for 10 devices, upgradeable to 100 devices). Global Manager requires Windows 2000 or NT4 SP4+, 64 MB RAM (128 recommended), 3 MB software storage, and 5 MB log storage per managed device. Due to lab limitations, we did not test NetScreen-Global PRO, the management solution recommended for large ISPs and carriers. Global PRO for NT or Solaris starts at $49,995 plus $4,995 for each Solaris Data Collector. Installation and Administration NetScreen setup can be accomplished through the console port or by browsing the default IP 192.168.1.1. Using the Command Line Interface (CLI) or Graphical User Interface (GUI), configure IP addresses and masks, select a mode of operation -- either route, NAT, or transparent (above left), and reboot.

Choose NAT mode to permit outbound connections from private Local Area Network (LAN) addresses to untrusted public destinations. For heavy bi-directional or incoming connections, consider using the NetScreen to route without address hiding. In these modes, the appliance is inserted between two separately addressed subnets. Installation in an existing subnet requires some renumbering - for example, using your default gateway's IP as the NetScreen's trusted IP.

In transparent mode, the NetScreen bridges two halves of an existing subnet, avoiding renumbering. Bridge interfaces do not have IP addresses, but the NetScreen must still be given one address for management. Transparent mode is a fit for small- or home-offices (SOHOs) where an access router is already providing NATed Internet access and a simple "drop in" firewall is desired. Transparent mode is an easy way to firewall existing server farm without address impact. However, the NetScreen cannot function as a VPN gateway in transparent mode.

The NetScreen-5XP can also be initialized via NetScreen's QuickStart program (shown right). QuickStart discovers factory-fresh 5XPs on a PC's local subnet - an entry-level setup aid. Unfortunately, the CLI "unset all" command did not return our 5XPs to factory defaults, so were unable to test drive QuickStart.

NetScreen appliances can be administered through a variety of management interfaces. The CLI can be accessed from the console port (locally or remotely), Telnet, or SSHv1. The Java-based GUI - called the WebUI - can be accessed via hypertext transfer protocol (HTTP) or secure socket layer (SSL). NetScreen-Global administration uses a proprietary protocol, with or without VPN protection. Each of these protocols is individually enabled/disabled for each interface. After you get them working, we recommend using only encrypted administration - that is, secure shell (SSH), SSL, or Global-over-VPN. SSL administration requires a browser with 128-bit encryption and a device certificate, SSH requires third-party client software, and Global-over-VPN requires NetScreen-Remote and a working IPsec policy.

Administrative access is controlled by username/password. By default, "netscreen/netscreen" has full read-write privileges. Additional accounts can be granted read or read-write privileges, authenticated from a local list or a RADIUS server (shown left). Access can be narrowed to specific IPs, and default HTTP/SSL listening ports can be modified. Mutual authentication can be added by administering the NetScreen over IPsec tunnels. However, we found that the NetScreen itself is unreachable via L2TP-over-IPsec.

In release 2.6.1, an "asset recovery" option was added, letting the NetScreen-5XP be reset to default via console port without a password. This is much more convenient than returning the unit for lost password recovery, but should be used with caution in places without physical access control - like teleworker residences.

Overall, these admin interfaces are more flexible and secure than most. Experienced network administrators will find the CLI, WebUI, and NetScreen-Global consistent and easy to use. However, the WebUI does not provide any "hand holding" for novices. In particular, on-line help cannot be viewed when NetScreen's Web site is unreachable - as well it might be during setup. Newbies can browse the WebUI and consult .pdf manuals to construct basic firewall policies after using QuickStart. Managed service providers may prefer to deliver these appliances with pre-configured IPs and firewall policies enabling secure remote administration.

(Back to Top)

Firewall Policies
NetScreen appliances are certified by the International Computer Security Association (ICSA) in accordance with stateful inspection firewalls. To boost performance, arriving packets are classified and handled in hardware; only session establishment is performed in software. NetScreen subscribes to that security best practice: "That which is not explicitly permitted is denied." To pass anything, you must create Inbound and Outbound policies to permit, deny, authenticate, or tunnel traffic.

At minimum, each policy specifies a source, destination, service, schedule, and action. When operating in NAT mode, address translation can be applied to policies. Password authentication can be required for new sessions. IPsec and/or L2TP tunneling can be mandated for traffic between a source and destination (see Site-to-Site VPN). Prioritized bandwidth can be allocated to all sessions under a given policy. In short, policies classify new sessions, dictating the translation, authentication, tunneling, traffic shaping, and log/alarm actions applied to them. (These actions will be further discussed in Part 2 of this report.)

NetScreen policies refer to Address and Service "lists" instead of raw addresses or ports. Addresses are individual IPs or subnets; they can be combined into Address Groups (shown above). Services are tuples identifying protocol and source/dest port range. Many common Services are predefined; custom Services and Service Groups can be added (shown left). These Groups make it easy to represent concepts like CompanyNet and ProtocolsAllowedOut. It would be nice if interface IPs were represented by predefined Address objects, promoting policy consistency after update. Due to a "disappearing ports" WebUI bug that we encountered, we recommend using the CLI for custom Service definitions.

Policy parameters and relative order are easily eyeballed from Inbound or Outbound policy tabs. For example, this snapshot shows our Outbound policy of last resort, permitting InsideAny (traffic from the trusted LAN) to reach OutsideAny (the untrusted LAN), masked by NAT (shown right). Other policies allow authenticated Telnet sessions to one untrusted address and require IPsec tunnels on sessions between our trusted subnet (CompanyNet) and branch office and teleworker subnets. Arriving packets that do not match a policy are dropped. Firewall Features Other noteworthy features include the ability to enable/disable ping on each interface, a local cache of DNS-resolved addresses with scheduled refresh, NTP synchronization, and strong DHCP support. NetScreens can serve IPs to trusted LAN hosts or operate as a DHCP relay agent. The NetScreen-5XP can use DHCP or PPPoE to obtain an untrusted interface IP. While they can be configured with static routes, NetScreens do not speak or listen to any routing protocols.

NetScreen firewalls can also detect port scans, address sweeps, Ping of Death, WinNuke, Land, and Tear Drop attacks (shown left). Configurable thresholds can block Internet Control Message Protocol (ICMP), User Datagram Protocol (UDP), and TCP SYN floods. In addition, ScreenOS 2.6.1r2 added malicious Uniform Resource Locater (URL) detection, letting the firewall discard HTTP intended to exploit web servers infected with the CodeRed Worm.

For example, we configured our NetScreen-5XP to trigger UDP flood protection at 200 packets per second. Then we used Foundstone's UDP Flood tool to hammer a server on the trusted LAN. After the generated rate hit 199, attack alarms appeared every few seconds. Packets above this threshold are dropped, but arriving packets still eat untrusted interface bandwidth. When using traffic management for WAN shaping, be sure to set untrusted interface capacity higher than flood thresholds to prevent floods from choking out valid traffic.

—End Part One—