Last week, in the first part of our three part evaluation of Bluesocket's WG-1000 Wireless Gateway, we took a look at the difference between wireless and mobile security functions, as well as how to plug the unit into a LAN and configure role-based policies. This week we start by taking a look at how Bluesocket handles different VPNs.
How VPNs Help
Wireless APs can be seen and used by anyone within a few hundred feet and frames are vulnerable to eavesdropping, modification, and replay. Wired Equivalent Privacy (WEP) features in 802.11 products offer weak protection against these vulnerabilities. Emerging standards like 802.1X and TKIP are fixing the worst WEP flaws, but many companies have already abandoned WEP in favor of VPN tunneling.
VPN tunnels are widely used for authentication, confidentiality, integrity, and anti-replay between offices or remote users on the public Internet. Companies that have already deployed VPN clients on user laptops can leverage that same software to protect traffic over wireless systems. VPNs can provide much stronger security than WEP and produce a more consistent environment for security policy enforcement. But combining VPN with wireless can be challenging.
For one thing, VPN software may already be present on remote user laptops, but what about corporate desktops? What about PDAs and Pocket PCs? What about visitors to a corporate WLAN or public hotspots? Ideally, you'd like to mandate a security policy—not software installation.
Bluesocket VPN SecretsBluesocket minimizes this by supporting many different VPN clients. The WG operates as both a PPTP and IPsec server. It supports IPsec ESP tunnel mode with Data Encryption Standard (DES), 3DES, and 128/192/256-bit Advanced Encryption Standard (AES) encryption, SHA1 and MD5 message integrity, and Diffie-Hellman groups 1/2/5, with or without Perfect Forward Secrecy (PFS). The WG supports IKE authentication with preshared secrets or digital certificates, using Main Mode (IP IDs or X.500 DNs) or Aggressive Mode (User-FQDNs). Secrets can be defined for individual IPs or email addresses, or a group secret can be defined for a non-overlapping IP range (left). We successfully paired our WG with the following VPN clients:
* Microsoft PPTP clients on Windows 95/ME/XP/2K and Pocket PC 2002;
* Microsoft IPsec clients on Windows XP/2K (tested with fixed IP only);
* SafeNet SoftRemote Win32 OEMs from WatchGuard, NetScreen, and SonicWALL;
* SSH Communications Sentinel Win32 IPsec client; and
* Certicom movianVPN and Funk AdmitOne IPsec clients on PocketPC.
Bluesocket also supports CheckPoint and PGPNet (MacOS) clients. Bluesocket does not support L2TP or XAUTH. If you want legacy user authentication in your Bluesocket VPN, create a role that requires both IPsec and RADIUS/NTLM/LDAP authentication.
The VPN combinations we tested all worked well with preshared secrets and little or no debugging. We negotiated a variety of algorithms, including 128-bit AES with SSH and Funk clients. We found this interoperability quite remarkable—especially without ICSA certification. Nonetheless, every multi-vendor VPN presents challenges, and we were not surprised to encounter a few. For example:
( 1 ) We were unable to authenticate PPTP clients against our RADIUS database. This is a documented constraint: PPTP users must be in the WG's local database or an LDAP directory.
( 2 ) Using a PC with a static IP, we established an IPsec tunnel but did not see the connection on the GUI and were unable to authenticate the user. Apparently, the WG was silently dropping traffic because this PC was "unknown"—that is, not using DHCP or in the MAC list. The tunnel came up anyway because IPsec processing is performed before firewall rules are enforced.
( 3 ) To match movianVPN client features, we had to disable PFS in our WG VPN config. Because we were using one VPN config for all clients, we also disabled PFS in our SafeNet clients. To our surprise, SafeNet tunnels worked more reliably after making this change—with PFS enabled, Phase II re-keys had often failed.
( 4 ) Whenever a WG is rebooted, IPsec tunnels must be manually restarted by each user. Some IPsec implementations use "keep alives" to avoid this, but in Bluesocket's mix-and-match environment, one cannot rely on vendor extensions. PPTP clients do not have this problem—they detect TCP control connection failure automatically.
( 5 ) Using dynamic IPs with Windows XP/2K IPsec is awkward. Bluesocket does not support Microsoft's L2TP over transport-mode ESP for remote access. Microsoft's tunnel-Bluesocket Helper Toolmode ESP policies require static endpoint IPs. To update policies when dynamic IPs change, Bluesocket developed an XP/2K "helper tool" (left). This one-click tool makes the update much more palatable, but user initiation of a third-party executable is still not ideal. Companies that require only a predetermined set of NICs (MAC addresses) may find it easier to configure IPs assignments for XP/2K clients.
( 6 ) We were only able to use certificate authentication with Windows XP/2K clients. Bluesocket is still working on cert issues, including interoperability with other clients. While debugging our configuration with tech support, we learned that:
* The VPN entry accepting certs must be the first in the WG's table,
* there must be no local user or subnet VPN defined for client IPs using certs,
* certs cannot have been exported from SafeNet's Certificate Manager, and
* the WG accepts all certs issued by the configured CA. Clients using certs are identified by X.500 DN, but the WG cannot permit/deny individual DNs.
( 7 ) Due to limitations of our lab, we did not test the certificate enrollment feature. A client without a certificate can request one by selecting an option on the login page, logging in with a username, and installing the supplied personal certificate. To enable enrollment, the WG must have the CA's private key and the CA must have an online certificate server that lets the WG to request certificates on behalf of clients. This feature solves the chicken-and-egg problem where tunneling is required to gain protected network access, but the client does not yet possess the cert required to tunnel and cannot request a cert directly from the CA without network access.
Vluesocket VPN DebuggingVPN debugging would be much easier if the GUI included any VPN logging. On the Status/Active Connections page, the VPN associated with each connection is bold-faced when the tunnel is active. There is no other customer-visible VPN status or logging, although a debug log is available to channel partners through a hidden CLI (left). Bluesocket plans to enhance logging; IPsec would be the first thing we'd add. For now, VPN debugging must be accomplished using client-side logs, sniffers, and tech support.
http://www.isp-planet.com/fixed_wireless/technology/2002/bluesocket4.html
