How Cisco AnyConnect Integrated with Windows Mobile 6.5

Integrating enterprise VPN clients like Cisco AnyConnect into Windows Mobile 6.5 required a hybrid architecture combining custom Windows CE network drivers with user-space connection software. Because Windows Mobile 6.5 natively offered limited VPN capabilities—primarily basic PPTP and L2TP/IPsec—third-party vendors could not rely solely on the built-in operating system tools. Instead, clients like Cisco AnyConnect integrated through proprietary NDIS intermediate miniport drivers, direct interaction with the Windows Mobile Connection Manager, and dedicated user-space services that handled authentication, SSL/DTLS encryption, and routing table modifications.

The Virtual Network Adapter (NDIS Driver)

The core of the integration occurred at the Network Driver Interface Specification (NDIS) layer. Windows Mobile 6.5 was built on the Windows CE 5.2 kernel, which supported NDIS 5.1.

To intercept and tunnel traffic, third-party VPN clients installed a custom NDIS intermediate driver or virtual miniport adapter. When an enterprise connection was initiated, this virtual adapter exposed itself to the OS network stack as a standard network interface. Outgoing IP traffic destined for the corporate network was routed through this virtual interface. The driver intercepted the raw IP packets, handed them to the VPN client engine to be encrypted, and encapsulated them into transport packets (typically SSL/TLS or DTLS in the case of AnyConnect). These encapsulated packets were then passed down to the active physical interface—such as a cellular (GPRS/EDGE/3G) radio or an 802.11 Wi-Fi adapter—for transmission.

Interfacing with the Connection Manager

Windows Mobile relied heavily on the Connection Manager (ConnMgr) subsystem to coordinate multi-homed networking and automatically route traffic through cellular connections or Wi-Fi.

Third-party clients interacted with ConnMgr using Windows CE Connection Manager APIs. Rather than completely replacing the subsystem, the VPN client registered itself as a specific network provider or used system hooks to monitor connectivity transitions. When the device roamed between Wi-Fi and mobile networks, the VPN client received state notifications from the Connection Manager, allowing the software to maintain the encrypted session or automatically trigger reconnection mechanisms without crashing the active network sessions of running applications.

User-Mode Services and Tunnel Negotiation

Above the driver layer, the VPN suite operated a set of background user-mode services along with a compact graphical user interface (GUI) designed for resistive touchscreens and stylus input.

  1. Authentication and Protocol Negotiation: The user-mode client initiated outgoing connections over standard HTTP/HTTPS ports (TCP 443) to establish the SSL tunnel, prompting the user for credentials, two-factor tokens, or authenticating via device-installed X.509 machine certificates stored in the Windows Mobile Certificate Store.
  2. Datagram Transport Layer Security (DTLS): Once authenticated, AnyConnect attempted to establish an opportunistic UDP-based DTLS tunnel for reduced latency and better performance over unreliable mobile data connections, falling back to TLS over TCP if UDP was blocked by intermediate carriers.
  3. Driver Communication: The user-mode engine communicated configuration parameters, encryption keys, and policy settings down to the NDIS virtual driver via standard Windows Input/Output Control (IOCTL) commands.

Routing Table Manipulation and DNS Handling

Once the tunnel was established, the VPN client dynamically modified the local device routing table and DNS settings.

For full-tunnel configurations, the default route was updated so that all mobile traffic was directed into the virtual adapter. For split-tunnel configurations, the client parsed network lists provided by the VPN gateway (such as a Cisco ASA appliance) and added specific subnet routes pointing exclusively to the VPN virtual adapter. Additionally, the client overrode the system's DNS resolution path, redirecting enterprise domain queries to corporate DNS servers reachable only through the secure tunnel while maintaining public DNS servers for external resolution.