Fixed Wireless Technology

(Part II) Taming Wireless Security Blues with Bluesocket—continued

VPNs vs. Mobility
After setup, VPNs should operate transparently, providing robust security without user intervention. With a single AP, this is no problem. With multiple APs, this is harder to accomplish. Bluesocket "secure mobility" works to overcome these hurdles.

When an 802.11 card is enabled, the station associates with a nearby AP. Some stations are configured to use one specific AP, but most choose the AP with strongest signal for a given SSID. If the station finds a stronger signal later, it may roam or deassociate from the original AP and reassociate with a new AP. For example, when the original AP is reset, something interferes with signal from the original AP, or a new AP "appears" as the station moves.

DHCP leases must usually be renewed when roaming, since the new AP may occupy a different subnet. Windows clients renew automatically when Media Sense notes a link status change. Users without Media Sense must manually /release and /renew leased IPs. Renumbering is necessary to restore network connectivity, but it disrupts traffic, TCP connections, and VPN tunnels. Tunnel re-establishment can take noticeable time or require manual intervention, burdening VPN gateways, frustrating end users, and inhibiting usability.

One way to avoid renumbering is to share the same subnet and DHCP scope across APs. This is feasible for a couple of co-located APs. Alternatively, VLAN tagging can create one virtual subnet from several physically distributed APs. But VLANs scale only so far, and tags may be used for other reasons, like prioritizing organizational traffic inside your Intranet. Bluesocket uses another methodology to avoid mobile client renumbering with less administrative overhead and greater user/VPN transparency.

In a Bluesocket mesh with secure mobility enabled, each client continues to use the IP leased through the first AP it encountered. When a client reassociates with another AP, all traffic is relayed by the visited WG to the original WG over GRE. This is not an encrypted VPN tunnel—traffic is merely encapsulated between WGs.

We tested two WGs on the same protected-side subnet and saw no performance degradation when tunneling between them. Clients continuously pinging the Internet usually lost one or two pings during AP reassociation, but file transfers and telnet sessions continued without interruption or noticeable change in latency/throughput. More importantly, existing VPN tunnels remained active, and clients were not required to reauthenticate to the new WG. As long as they remained logically "connected" to the old WG, clients moved freely between the APs connected to both WGs.

Because every OS and 802.11 card behaves slightly differently, we tested this with a variety of client devices and adapters, including Agere, Cisco, Linksys, Proxim, and Symbol on Windows 95/ME/NT/2K/XP and Pocket PC. We were generally pleased with results, but learned a few lessons along the way. For example:

• Network and radio connectivity must be maintained at all times—as previously noted, secure mobility does not provide session suspend/resume. In many circumstances, we found our clients could lose radio contact for tens of seconds before being disconnected from the WG. Once disconnected, clients must /release and /renew and then reauthenticate through the next AP contacted.
• This interval is configurable. By default, the original WG pings the client over GRE every 60 seconds, assuming disconnection after three failures. We kept hitting this on one client that would successfully roam for about two minutes, and then get disconnected. Tech support clued us into the ping, which lead us to the culprit. This client ran WatchGuard MUVPN with an integrated ZoneAlarm firewall, and the firewall was blocking ping. Corporate laptops with personal firewalls cannot roam uninterrupted unless configured to either trust the WG or respond to pings.
• This methodology depends on avoiding DHCP lease renewal, which in turn depends on avoiding Media Sense. This was not a problem on any PC we tested, with the exception of one running Windows XP. There, secure mobility did not work until we updated our registry to disable Media Sense. Corporate end users that don't have permission to update their Windows registry will need help with this one.
• Hotspot clients may want to tunnel to distant company VPNs. In route mode, the WG can let IPsec and/or PPTP pass through to upstream gateways. In NAT mode, a VPN client with UDP encapsulation is required. We had no trouble accomplishing this with a Nortel Contivity client. Note that visiting clients can roam across subnets without realizing that these WGs even exist.
• Local clients that roam may need to be configured with multiple VPN gateways. Consider a VPN client tunneled into the master WG. When that client roams, it stays tunneled into the master until disconnected. If that client later (re)connects to a slave subnet, it must tunnel into the slave WG. Connected clients can move freely, but getting connected means tunneling to the nearest WG. Enabling "redundant VPN gateways" depends on your VPN client. We configured our SafeNet clients to try our master WG first, using our slave as an alternate (right).