The Remote Access Conundrum Part 3:
Dynamic Addressing

Creating a secured virtual private network is like pulling a rabbit out of a hat—just like an experienced magician can perform the illusion to the amazement of an audience, so too must your ISP make remote access authentication seamlessly appear—as if it came out of nowhere.

Lisa Phifer VP Core Competence, Inc. [February 8, 2001]

Deploying a remote access VPN offers many challenges. In previous columns, we discussed using IP Security (IPsec) and the Layer Two Tunneling Protocol (L2TP) to enable secure remote access. By examining legacy user authentication and multi-protocol issues, we have shown how essential—and difficult—integration with existing corporate networks can be.

Providing each remote access client a "virtual presence" on the corporate network is also essential. The purpose of a remote access VPN is to make the teleworker or traveler feel as though he or she were directly connected to the corporate LAN. This requirement may seem obvious, but satisfying it can be a challenge.

Migrating from traditional remote access
Companies that operate their own direct-dial remote access servers assign each client an IP address from the corporate network. In most cases, dynamic addresses are allocated from a pool, enabling reuse and simplifying address administration. Access servers typically use PPP IP Control Protocol (IPCP, RFC 1332) to communicate dynamic addresses to remote clients.

By receiving addresses from the corporate block, remote clients gain a "presence" on the corporate network. These addresses are internally routable and resolvable. They can receive LAN broadcasts and pass through IP filters designed to block outsider access.

Virtual private networks replace the physical connection between remote client and access server by a logical connection—a tunnel over a public network. Depending upon the approach used, this indirection can also limit the corporate network services extended to the remote client. For example, if the client cannot receive broadcasts, the user may not be able to browse the corporate "network neighborhood". When using a foreign address, corporate servers may not be accessible and new routes may be required to direct return traffic.

When migrating from traditional remote access to VPN, any loss of functionality is going to create unhappy users. The trick is to identify and circumvent potential problems before deployment. To do so, one must carefully consider client-side addressing.

Extending PPP across the VPN
Compulsory-mode L2TP involves tunneling from an L2TP access concentrator (LAC) at the ISP POP to an L2TP network server (LNS) at the edge of the corporate network. The ISP provides call termination and proxies PPP from remote clients to the LNS.

Voluntary-mode L2TP extends the tunnel end-to-end, from remote client to LNS. The ISP provides call termination and network connectivity, but LAC functions are performed by client software—for example, the L2TP client in Windows 2000.

In either mode, because PPP flows end-to-end, the LNS can use IPCP to supply dynamic address assignments to remote clients. Extending PPP across the VPN automatically preserves the remote client's "presence" on the corporate network.

Unfortunately, L2TP does not provide the level of security afforded by IPsec. Limitations identified by the IETF's IPSRA working group (above) include weak tunnel endpoint authentication, inadequate encryption services, and inability to protect data integrity. As discussed in previous columns, some companies will be satisfied with L2TP. However, those who require strong authentication and confidentiality may require IPsec or L2TP over IPsec.

Go to page 2: Without End-to-End PPP >