VPCom 2.5

Problems tarnish strong security product

IT departments need to provide end users with secure remote links to corporate network services. Such links are necessary for companies that have mobile sales forces, remote branch offices, telecommuters, or collaborative partnerships outside the organization. Yet many IT departments don't have the expertise or the dollars to assemble and manage fully functional, secure conduits for remote access to their private networks. Ashley Laurent markets VPCom 2.5 to fill this need.

VPCom Standard Edition is an integrated network security product for small to midsized businesses. VPCom bases its firewall functionality, intrusion detection, and VPN services on open IP Security (IPSec) standards. The VPCom Enterprise Edition adds bandwidth control and failover redundancy to the standard feature set. Ashley Laurent claims both versions support high-throughput connections up to and including T3, and the company also sells VPCom as a network appliance. For the Windows 2000 Magazine Lab test, I used the software version of VPCom Standard Edition.

Incomplete Documentation
VPCom arrived on a CD-ROM accompanied by two 120-page manuals, Reference Guide and Quick Start Guide. Neither manual was well organized, complete in topic treatment, or had an index, so I quickly became frustrated as I looked for setup and configuration information. Some chapters were incomplete, and other chapters were sketchy collections of narrative and screen shots. I visited Ashley Laurent's home page to check VPCom's Web-based support. The technical support pages were under construction and provided no helpful information. The Web site offered downloadable Portable Document Format (PDF) versions of the documents I was already struggling with. Ultimately, I relied heavily on Ashley Laurent's technical support staff to fill the gaps in the product's documentation. (Since I tested VPCom, Ashley Laurent has improved the Web site, but portions of the site remain under construction.)

I installed VPCom on a Dell Precision 410 WorkStation with 550MHz dual-Pentium III processors and 128MB of RAM. This setup exceeded Ashley Laurent's minimum hardware recommendation of a 333MHz Celeron processor and 128MB of RAM. VPCom requires two NICs that have only TCP/IP bound to them, so I added a 3Com 3C595 NIC to the Dell's existing LAN on Motherboard (LOM) 3Com 3C905B NIC. Following instructions from Ashley Laurent's support engineer, I made sure that the internal interface had a blank default gateway setting, that the external interface had a correct gateway setting, and that IP forwarding was off. My system ran Windows NT Server 4.0, but VPCom will also run on NT Workstation and Windows 9x. Ashley Laurent's support engineer recommended that I run Service Pack 5 (SP5) because of VPCom's sensitivity to the changes that Microsoft introduces to the TCP/IP protocol stack with every new service pack.

Installing VPCom Gateway
VPCom consists of VPCom Gateway, the server component that provides intrusion-detection, firewall, and VPN services; VPCom Console, the administrative interface, which can run locally or remotely; and VPCom Remote, VPCom's client component. I used the VPCom setup wizard to install VPCom Gateway. After I rebooted the machine, the only evidence that I had installed anything were three new services: a VPCom driver transport protocol and two VPCom virtual network adapters that matched each of my physical adapters.

VPCom Console took only a moment to install and required no reboot. The console readily provided access to frequently used interfaces (e.g., the Server Monitor, the activity monitor that shows user status), but it had an annoying tendency to snap windows into a cascaded pane when I attempted to move them. VPCom Console is optimized for 1024 * 768 resolution, and anything less makes the screen more difficult to read. The console is also one of VPCom's obstacles to scalability. Each console instance can support only one VPCom Gateway connection, so you must run multiple console instances to support multiple Gateway connections. This arrangement could quickly become cumbersome in an environment that has a large deployment of VPCom Gateways. Trying to work with several instances of the quirky VPCom Console on one PC would be difficult, and even a powerful PC would slow to a crawl under the console load.

The console provides an interface you can use to configure the firewall and VPN settings. I launched the interface and accepted the default administrator logon and password. The main console launched in the background, and a VPCom Server Monitor window opened in the foreground. Figure 1, page 127, shows the VPNServer console and the Server Monitor window. To connect the console to the server, I had to enter the IP address of the Gateway's internal or external NIC or use the loopback address at the local console. For remote connections, VPCom uses UDP ports 790 and 791. In a normal installation, those ports are open by default, but you can close them if you don't need remote access.

A Series of Setbacks
My initial attempt to configure the firewall and VPN settings was the first in a series of setbacks that resulted from VPCom's incompatibility with hardware and software drivers. Initially, VPCom didn't recognize the 3Com 3C595 NIC that I had installed. Although the NIC appeared on a list of tested NICs in VPCom's documentation, Ashley Laurent's support engineer said the list of supported NICs had shrunk to 4 from more than 20. Three of the remaining NICs on the list were models from Intel, and the other was a 3C905B. In addition, VPCom is particular about NIC drivers. Any NIC drivers that incorporate transport driver interface diagnostics can cause problems. I installed another 3C905B NIC, along with minimal NT drivers that Ashley Laurent sent to me.

Another problem caused the VPCom server to lock up when a remote client connected, forcing me to abandon the Dell WorkStation. I worked extensively with Ashley Laurent on this problem, and although we could duplicate it at will, we couldn't isolate the cause. To replace the Dell, I bought two new 3C905B NICs and set up a Digital workstation with a 300MHz Pentium II processor and 128MB of RAM.

Configuring VPCom
With VPCom running and stable on the Digital system, I resumed my attempts to configure the firewall and VPN settings. You can set up VPCom in various configurations depending on your environment. VPCom can reside behind an existing firewall, in which case you would employ only its VPN functionality. It can sit parallel to a firewall and provide its own access control, or it can act as a network's only firewall and provide VPN functionality. For testing, I configured VPCom Gateway to provide firewall and VPN functionality to a test network behind a Cisco 800 ISDN router. Figure 2 shows the test network.

Configuring the VPCom Gateway is a multistep process with several options. The process is involved but not complex, and the pitfalls I experienced were mainly a result of poor documentation. Tasks require configuring VPCom's Internet Key Exchange (IKE), Network Address Translation (NAT), and Intranet Name Space (INS).

The IKE configuration required me to give an authentication ID to the VPCom Gateway. This identifier is the VPCom Gateway's host ID that clients see when they establish a VPN connection. Another important setting in IKE configuration is a check box that enables dynamic tunnel information exchange, which lets you transfer configuration policies from the VPCom Gateway to clients. This feature helps you administer your remote users. IKE configuration is also necessary if your clients will obtain an IP address from a DHCP server on your intranet.

I used the NAT configuration applet to define the internal and external network interfaces. I assigned the external interface a globally routable IP address range. A mapping tab let me create one-to-one mappings of globally routable IP addresses to intranet hosts. I used a global IP address to access all my intranet hosts. To finish the configuration, I enabled NAT on the internal interface.

The VPCom INS assigns virtual IP address ranges to the internal adapter, provides for WINS and DNS server entries for remote users, and allows for flexible address aliases for remote users. Assigning intranet DNS and WINS servers involved typing their IP addresses in the correct fields. Setting up internal addressing was more complicated because you have several options. VPCom supports using an intranet DHCP server, although the address-negotiation process can be tedious on slow dial-up links. An alternative is to assign users an IP address range that clients will draw from when they connect using VPCom Remote. A problem with the alternative approach is that NT clients need to have administrator privileges on their local machines for VPCom's dynamic addressing to work. Windows DHCP can be slow, but it doesn't require an end user to have special privileges to obtain an IP address. Yet another alternative is to assign each VPCom Remote client a static IP address when you set up the client. If you're short on IP addresses for remote users, VPCom lets you assign a virtual address range in a separate subnet, which gives you more flexibility. The final configuration option for INS is to turn on IP forwarding. VPCom's IP forwarding supplants Microsoft's, so you need to activate IP forwarding under the INS configuration and disable it in NT.

VPCom's firewall relies on an intermediate driver that inserts itself into the TCP/IP stack. This driver acts as a relay agent within the stack and either passes or drops packets according to various VPCom configuration settings. By default, all TCP ports in the firewall are initially closed. Thus, you don't need to deal with the firewall immediately if your first task is to set up VPN functionality. When you want to open ports, you can apply one of several VPCom-provided templates to the intranet hosts. You can apply one global configuration to the external interface as well. VPCom's granular control over ports and protocols gives you flexibility in configuring the firewall. However, setting up outbound restrictions is cumbersome because the process requires you to create multiple policies if you want any level of granular control.

After I configured VPCom Gateway, I configured intranet hosts and remote users. The VPCom Console contains tabbed pages for managing hosts and users. To set up a host, I clicked the Intranet Host tab, right-clicked Intranet Security Policy Configuration, selected Add new intranet host, then entered the host's IP address and subnet mask. An entry can also define multiple hosts; multiple host entries can help you manage remote-user access.

To save all the configuration changes I made, I chose Save Configuration from the console's Configuration option. By default, VPCom saves its configuration database file (i.e., nsm.cfg) every two hours. If you plan to make large-scale changes to your VPCom configuration, you might want to save the original nsm.cfg file to another location and use that version if you need to restore a known good configuration.

To set up a remote user, go to the VPCom Console's Remote Users tab, right-click Security Policy Configuration for Remote Users, and add a new user in the resulting dialog box. You provide a user ID and preshared key, which is essentially a password. Other configuration options on the client side are secure relay tunneling of IPSec traffic and secure tunneling of outbound broadcast traffic. These options enable secure communication channels among clients and between clients and hosts so that the browsing and drive-sharing features of Windows networking will function among remote users. This type of functionality approaches a seamless implementation of VPN.

To enable remote users, you need to export a unique configuration file (i.e., .alf file) for each VPCom Remote user. These encrypted files reflect a summary of settings that VPCom Gateway defines. Each user needs an .alf file in the client directory to connect to the VPCom Gateway. You can create these files individually or use VPCom's batch export utility to generate a file for each user. Ashley Laurent provides a Web-based deployment tool to help distribute .alf files. Remote users register on a secure Web page, and their .alf files are automatically downloaded to their PCs. I copied the .alf files to a disk and transferred them to the clients when I installed VPCom Remote.

Installing VPCom Remote
To install the VPCom Remote client on PCs running NT, you need to have administrative rights. To make the client work on Win95 PCs, you must update the Winsock drivers. The Remote client's setup wizard installs a virtual adapter that you can find in the Network property sheet. I copied the .alf file for the user that I created into the VPCom client directory. After the client PC rebooted and I logged on, the VPCom Remote client automatically launched. The User field displayed the correct username, so I entered the preshared key and connected to the VPCom Gateway. I entered an Ipconfig command at a command prompt and saw that the VPCom virtual adapter had obtained an IP address from the pool that I assigned on the VPCom Gateway. Figure 3, page 129, shows the VPCom Security Agent, which is the VPCom Remote client interface, displaying the VPCom Gateway (i.e., DIGIT300) and some of the intranet hosts that the user can access. The ESP_DES icon in Figure 3 depicts a secure IPSec tunnel that uses Data Encryption Standard (DES).

After my remote client PC connected to the VPCom Gateway, the client had most of the functionality I would expect on the local network. I didn't configure the ability to browse the VPN, but I could map drives and use Uniform Naming Convention (UNC) names to connect to shares. FTP transfers were seamless, and usability and performance were what I expected on my ISDN LAN. DES encryption caused some processor overhead on the server and client when I moved large amounts of data, but system performance didn't suffer.

Valuable Features, But ...
VPCom has some solid basic functionality but needs further refinement. Improving the product's documentation should be a key goal for Ashley Laurent. The company's technical support staff was invaluable in helping me work through various problems I encountered, but the technical staff would have difficulty providing such extensive support to a large customer base.

Small and midsized businesses would value VPCom's features. VPCom didn't appear to have any security flaws; the product thwarted my attempts to bypass the firewall, and the remote clients couldn't stray beyond their assigned boundaries. VPCom's most appealing feature is that it employs a standards-based implementation of high-security encryption technology and incorporates that technology into a functional remote client.

However, VPCom is sensitive to hardware and drivers. I had enough problems with hardware to make me believe that companies deploying this product will probably have similar experiences. The VPCom Gateway crashed three times during testing. Ashley Laurent's technical support responded well to these incidents, but VPCom would benefit from further testing, debugging, and interface refinement. Ashley Laurent claims that VPCom 2.6 will resolve the problems I encountered. However, until I can verify that the manufacturer improves the product's stability and documentation and provides support across a wider range of hardware, I can't recommend VPCom.