Remote Access

KoolSpan: Bridging The Secure Access Gap

Part 2: The Test

In Part 1 of this review, we described this novel secure access product's architecture, our test network configuration, and client installation. This week, we test the product in the office and on the road.

by Lisa Phifer VP Core Competence, Inc. [July 22, 2005]

Taking a test drive
We had our first pair of wireless PCs secured over KoolSpan within an hour of unpacking the SE kit. A new Client install takes less than 10 minutes, but learning to make best use of the Client takes a bit longer.

Local LAN connections have a slightly different "feel" when using KoolSpan. Consider a typical Wi-Fi connection: after the NIC is enabled, Windows XP Wireless Zero Config or a NIC-specific client like Cisco's Aironet Client Utility selects an AP with which to associate. An association is formed and an IP address is obtained via DHCP. This entire process requires one user interaction for automatic connections; two for manual connections where a preferred network must be selected.

SecurEdge adds at least one new user interaction to this process, because authentication occurs after association, before getting an IP. If the SecurEdge Client is already running, the user is prompted to enter his PIN after selecting an AP. Connection status is "limited or no connectivity" until DHCP times out or the right PIN is entered. But if the user doesn't respond fast enough, SecurEdge authentication fails. When authentication fails for any reason, KoolSpan recommends the Client be exited and restarted. This is good advice, as we found authentication after earlier failure somewhat hit or miss.

It doesn't take long, but a little practice is needed to learn a reliable connect sequence. In particular, the PIN prompt (shown at right) chooses between local and remote tunnels. But "Remote" is checked by default, and we stumbled more than once by forgetting to check "Local." According to Radford, this issue was noted when KoolSpan provided free secure Wi-Fi access at SecureWorld Expo, and will likely be modified in a future release.

We found remote connections more familiar and less timing-dependent. Many travelers are accustomed to launching a VPN Client after connecting to the Internet and responding to any requisite Internet access prompts (e.g., guest network portal login). From the user's perspective, launching a SecurEdge connection to a remote Lock is little different. Before connecting for the first time, the user configures the Lock's Network Name and public-facing IP address into the Client GUI (shown at right). Thereafter, the Client GUI simply prompts for the user's PIN (above) when launching remote connections.

During initial tests, we observed that remote connections routed all traffic through the Virtual Adapter. For example (see figure, below), a Client with Local IP 10.0.0.244 and Virtual IP 192.168.2.102 routes all traffic through the Lock at 192.168.2.1, except traffic to 10.0.0.0/24, which is dropped. KoolSpan later supplied a new Client (v3.12a) with a split tunnel that passed local LAN traffic in the clear, while encrypting all other traffic over the tunnel. To split or not to split is a policy decision that each company should be able to make for itself; we were thus pleased to see KoolSpan add this option. According to Radford, the next version of the SecurEdge Manager will let administrators choose between full tunneling, split tunneling to a single subnet, and split tunneling with a local subnet exception as described above.

Clients that roam between APs on the same Lock remain authenticated, but Clients that roam between APs connected to different Locks would not. As Radford explained, "Currently, Locks have no way of sharing the random number / AES session key information [used by each tunnel], so they have to set up a new encrypted session and therefore a new authentication." KoolSpan is developing an inter-Lock roaming solution, but only larger networks are likely to be impacted. Smaller networks, including those using VLANs to carry traffic from distributed APs to a single Lock, will have no trouble with intra-LAN roaming.

Go to page two: Tuning the engine >