Remote Access

KoolSpan: Bridging The Secure Access Gap

Part 3: Under the Hood

KoolSpan recommends that 802.11 security be disabled on APs in a SecurEdge deployment. This does avoid unnecessary duplication—both 802.11 and SecurEdge provide link-layer packet encryption. However, there is also the practical matter that APs can't originate packets through the Lock, because APs are not SecurEdge Clients. Thus, an AP can't forward 802.1X/EAP requests to a RADIUS server on the internal network—or for that matter, send SNMP traps or SYSLOG messages.

For AP management and monitoring, Radford recommends running SecurEdge Client software on the monitoring PC(s), authenticating them to an additional Lock, deployed to face the APs. In other words, APs could be given a different (protected) route out of the external subnet. Other L2 controls could be used to support multiple WLAN security domains—for example, applying SSID-based VLAN tags at APs to send guest packets to the Internet, while directing employee packets to the VLAN's SecurEdge Lock.

Ultimately, KoolSpan's security protocol depends on the Network Keys, which never leave SmartCards and are used only for authentication. Since risk of Network Key compromise is low, KoolSpan does not provide an admin interface to refresh the factory-set Network Keys. Although we did not test it, each SecurEdge Client Key can actually be provisioned for up to 16 networks. "Each Key would have to be provisioned by the Manager for that network," said Fascenda, "But when you inserted your Client Key, you'd have access to any of those networks, one at a time."

Tracking your mileage
Logging is a relatively recent (and welcome) addition to the SecurEdge Lock. Anyone who has worked with failed VPN tunnels knows that visibility is crucial to debugging. Because SecurEdge offers few configurable parameters, and faces no multi-vendor interoperability challenges, debugging needs are modest. But when problems do occur, logging is still essential. Furthermore, every remote access solution should provide hooks for usage monitoring and security auditing.

SecurEdge Locks can be configured to forward event records to any SYSLOG server on the internal network. The configured IP can be a multi-cast address, so that any server listening to that address would record event records, enabling backup / redundant log storage. The SYSLOG records we recorded during our tests (see figure, below) included basic Client Key authentication success and failure records (useful for accounting) and significant Lock events like reboot, DHCP address acquisition, and Manager-initiated database uploads (useful for auditing).

Lock logging is an all or nothing affair. Although we found record detail fine for routine monitoring, we'd like an option to configure SYSLOG level for (infrequent) debugging.

During our tests, we encountered one problem we simply couldn't diagnose, given available information. When we installed the SecurEdge Client on a Windows 2000 PC, using a Cisco Aironet WLAN card and Cisco ACU, we had complete success with remote (AP on internal) connections, but no success with local (AP on external) connections. Remote connections were logged ("received authentication request, successfully authenticated"), but local attempts did not appear in the log at all. Using Ethereal to watch the Client's (associated) NIC, we saw only LAN broadcast packets.

At KoolSpan's request, we logged Client activity with a process debugger. They believe the problem is unique to Windows 2000 and our version of Cisco ACU, and did confirm successful W2K / Cisco local connections in their own lab. Our conclusion: SecurEdge may be far easier to configure than traditional VPNs or 802.1X, but it's not immune to occasional buggy PC / cranky NIC issues that Windows admins know all too well.