Remote Access

KoolSpan: Bridging The Secure Access Gap

Part 1: The Tools —continued

But several important topology and addressing considerations did come into play later. Some are not as thoroughly explained by documentation as we'd like. For example:

• Manager PCs can be located anywhere on the internal network, but must be able to send TCP/6969 traffic to the Lock's LAN port. In our case, that required a port-forward rule on the D-Link router to reach the Lock through the router's public IP. The catch: our Lock got its LAN IP dynamically via DHCP, so the port-forward rule didn't work reliably until we configured the router's DHCP server with a static IP assignment for the Lock.
  
  
• Upon receipt, our Lock's last-configured WAN and LAN IPs were on the same subnet. We had trouble connecting the Manager and scoured documentation to learn that LAN and WAN IPs must be on different subnets. As KoolSpan Director of Customer Solutions Fred Radford explained, "They should never be on the same subnet because, when the Lock receives a packet, it needs to make a decision where to send it. If [both IPs] are on the same subnet, [the Lock] sends all packets out the [WAN] port." KoolSpan plans to change this default route to the LAN port, which we agree is more sensible.
  
  
• Remote Clients connect to an offsite LAN, then authenticate to the Lock's LAN port by routing through KoolSpan's virtual adapter. But the Lock's routable IP can depend upon the Client's location. For example, Clients in our Internal Net used the D-Link router's public IP, while Clients on the Public Internet used our firewall's public IP. On the plus side, a remote Lock's address is the only network parameter that users ever configure.
  
  
• Local Clients activate an Ethernet or Wi-Fi connection, authenticate to the Lock's WAN port through that physical adapter, then get a local IP address from a DHCP server upstream from the Lock. But any device WITHOUT a SecurEdge Key can't pass LAN packets through the Lock. As a result, APs or switches or other non-XP/W2K devices on the External Net must have static IPs and be managed by another device on the Lock's WAN side.

These considerations are very important for network design and permanent deployment. But, as we found, these details are not necessary to get Clients tunneling through a Lock.

Turning the Key
The SE Kit comes with a 6-step Quick Start Guide that explains how to cable the Lock into your network and install the Client Key and associated Software. A one-page "read me first" documents each pre-provisioned parameter, like a unique network ID (burned into the Lock and Keys), initial Master Key PIN, default Client Key PIN, and PIN attempts (i.e., number of failed logins before a Key must be administratively reset).

These simple handouts gave sufficient guidance to install our pre-provisioned Lock (running v1.14 firmware). Customers who purchase a self-provisioned kit will need to consult the 39-page SecurEdge Manager and Lock User Guide for further instructions. KoolSpan offers 802.3af Power over Ethernet as a no-cost option, simplifying Lock installation in WLANs where APs already use PoE, but our Lock did not include this option.

For end users, there's a brief "how to" index card (User Quick Reference Guide) and a 19-page manual (SecurEdge Client User Guide). We had no trouble using the Quick Reference to install Clients on several Windows XP (SP1 and SP2) PCs. We later installed the latest Client (v3.11) on a Windows 2000 Pro PC, a newly-supported OS not mentioned in older Guides.

Companies with non-Windows clients will find this list too limited, but those with XP and 2000 will easily meet other host requirements: one USB port and one LAN adapter. Due to its MAC-level architecture, SecurEdge access over dial-up (PPP/SLIP) is not supported. These days, most travelers do prefer Ethernet or Wi-Fi LANs for high-speed Internet access at hotels, business centers, Internet cafés, conferences, and airport hotspots. SecurEdge just isn't a good fit for road warriors who fall back to v.90 dial where high-speed isn't available, or those using 3G WWAN services like EV-DO.

SecurEdge Client software is installed from CD, using a typical set-up wizard that requires no parameter entry. When the user first inserts his or her Client Key into the PC's USB port, Windows automatically installs a new hardware device using eGate drivers copied during Client setup.

Thereafter, a SecurEdge Client icon appears in the PC's system tray, used to report status and open the Client's GUI. The Client GUI prompts the user to choose an adapter from the PC's list of installed and enabled LAN connections (shown at right).

For example, we ran the SecurEdge Client on a Dell X200 laptop with on-board Intel Ethernet and Dell (Agere) Wi-Fi NICs. Initially, we used the Agere NIC to tunnel over wireless, through the Netgear AP, to the local Lock. Later, from the same laptop over hotel broadband, we used the Intel NIC to tunnel over the Internet, to a remote Lock.

From the user's perspective, the same Client software and Key work with any LAN adapter. Under the covers, remote (but not local) connections use a KoolSpan Virtual Adapter, added to Network Connections during Client install.

That Virtual Adapter needs no configuration, but users will notice a "not connected" LAN icon in their system tray and must not disable it. (The LAN icon can be hidden when active during a remote session.)

We encountered one install hiccup: because some driver code is unsigned, the user must temporarily disable signature checking during Client installation, remembering to re-enable it when done (shown at right). Unsigned code is all too common, but we'd prefer that a security product use only signed code.

—End