Remote Access

KoolSpan: Bridging The Secure Access Gap

Part 2: The Test

Unlike network layer VPN tunnels, SecurEdge tunnels have no trouble passing through devices that perform NAT. Because encrypted payload rides inside regular UDP packets, there is no need for a "VPN pass-through" or IPsec NAT traversal. We used SecurEdge clients in half a dozen remote networks without a single case of NAT failure so often seen with IPsec VPN clients. We did however, run into one restrictive WLAN gateway, set up for web-only guest Internet access, that denied UDP/53248 outbound. The port used by SecurEdge does not appear to be configurable.

Like any VPN client, SecurEdge Clients should be protected with personal firewalls—for example, permitting only UDP/53248 on the (cleartext) physical adapter and anything on the (encrypted) virtual adapter. We also see opportunities for coupling SecurEdge tunnel and adapter state—for example, an option to automatically disable the physical connection if the SecurEdge tunnel goes down.

In fact, we encountered a few state-related gotchas. If the user disables a physical connection while the SecurEdge Client is authenticated and the Client is open, the GUI becomes non-responsive. If the user accidentally launches the wrong kind of connection and wants to abort authentication, there is no "Cancel" button (other than exiting the Client.) Laptops that enter Sleep/Hibernation mode may require Client restart on wake up. These caveats are described in release notes; while such kinks are not at all unusual in new products, we'd hope to see these worked out in future releases.

Tuning the engine
After getting a few Client test drives under our belt, we turned our attention to configuring the Lock through the SecurEdge Enterprise Manager. We installed Manager software (v3.1.90) on a pair of XP Pro PCs (SP1 and SP2), using the supplied Master Key and the Master Clone.

The Manager host must run XP Pro or Home and have two free USB ports: one to authenticate using the Master (or Clone) Key, the other for provisioning Client Keys. As previously noted, the Manager can be located anywhere on the Trusted / Internal side of the Lock. No management access is supported from the Untrusted / External side of the Lock, and the Manager PC cannot simultaneously run the SecurEdge Client.

Unlike many VPN gateways, a SecurEdge Lock cannot be configured over telnet, ssh, https, or snmp. SecurEdge Locks can only be provisioned through Manager software and KoolSpan's proprietary protocol, and only by someone who possesses the Master Key (or a backup copy of the key, called the Master Clone). This approach reduces vulnerability to common network attacks that plague standard protocols like ssh and snmp, but requires the admin to have access to a PC running XP and installed Win32 Manager software.

In practice, administrators will have relatively few occasions to use the Manager. For example, the Manager is required to add a new Lock or change an existing Lock's parameters—like setting a Lock's internal (LAN) or external (WAN) addresses or SYSLOG server destination address/port (see figure, below).

Locks on the same subnet are found by the Manager, using a proprietary discovery protocol (UDP/6000.) Otherwise, the administrator must supply the Lock's internal (LAN) IP address. Management sessions ride UDP/6969, starting with SmartCard-based Manager-Lock authentication, establishing an encrypted channel over which a few administrative operations can be performed.

Beyond Lock provisioning, the primary function of the Manager is to administer Client Keys. For example, the Manager can be used to change defaults used by new Client Keys, like PIN retries and remote Network Name / Lock IP. The Manager can add a new Client Key or reset an existing Client Key to default, but only when that Key is inserted in the Manager's USB port. Finally, the Manager can temporarily block access by a Client Key—for example, suspending a user that exhibits suspicious behavior during a virus outbreak—when the administrator does not possess the Client Key (see figure, below).

The Manager maintains a Client Key database. After any change is made, all Client Key records must be uploaded to the affected Lock before taking effect, optionally overwriting the Lock's copy in its entirety. This methodology is easy to understand and prevents the Lock and Manager from getting out of sync, but might become unwieldy in a large network with dozens of Locks and thousands of Client Keys.

We encountered just two problems when running the Manager.

1. As previously noted, we could not manage our Lock until we changed its internal (LAN) address to avoid the external (WAN) subnet. Since we couldn't manage the Lock, we had to modify our DHCP server to assign IPs from a different subnet, then change Lock IP addresses using the Manager. Clearly, admins must be careful when setting Lock parameters to avoid mistakes like this or (worse) a return trip to the factory.
   
   
2. Twice, we encountered an error where a legitimate Client Key could not be found in the Lock's database; reloading Client Keys from the Manager didn't help. After investigation, KoolSpan identified the likely culprit: Manager software running concurrently on the same PC as the SecurEdge Client. When we invoked the Manager, it warned us to first stop the Client, but invoking the Client while the Manager was running yielded no warning.
   
   KoolSpan believes we probably made this "operator error," resulting in driver confusion over which Key to use for authentication. We ruled out another possibility—far less likely—that the Key had been physically damaged. Unlike one-time-password generators, the eGate tokens used by SecurEdge do not have batteries and are rather difficult to damage, much less tamper with. In our case, we knew the Key hadn't been damaged because it worked again later.

—End