Republished with permission from WatchGuard Technologies, Inc.

Security and xDSL Connections Part IV: Virtual Private Networking by Dave Piscitello In my previous three columns on security and xDSL connections, I discussed the technology of DSL and the vulnerabilities and issues that DSL connections present. I suggested policies and technologies administrators can use to control desktops, and explained the importance of firewalls in home and remote offices having broadband local access connections. Having accepted the risks and implemented the security solutions, and now that your remote workers are connecting via DSL, you will want to secure broadband local access communications using Virtual Private Networking (VPN). This last column in the series describes several VPN approaches. What Is Virtual Private Networking? A traditional private network is composed of dedicated or leased lines that interconnect routers. In a virtual network, tunnels replace dedicated lines, interconnecting sites and remote users over the public Internet logically. A virtual private network (VPN) adds authentication (trust), access control, confidentiality, and message integrity among the hosts participating in a virtual network so that the communications are as secure as the private network it replaces (or if implemented properly, more secure). When and Why You Need VPNs Organizations have successfully used ATM or Frame Relay to create virtual networks instead of building a mesh of expensive dedicated lines between its sites. Today, Internet access is commonplace, so why not use the Internet for virtual networking? Virtual networking over the Internet is straightforward, and is accomplished by using tunneling or encapsulation. Satisfying the private aspect of a Virtual Private Network is harder. The public Internet runs on IP, using the same technologies large enterprises use, and is generally understood to have the same vulnerabilities, especially with respect to interception of unprotected traffic. To maintain confidentiality over the public Internet, you must add encryption. Technology Choices for VPNs VPNs come in many flavors, and can be used for secure remote access (Remote User VPN) or site-to-site (Branch Office VPN) connectivity. I’ll briefly describe the following alternatives: Layer 2 Layer 3 Secure Shell (SSH) Secure Socket Layer (SSL) Transport Layer Security (TLS) (I’ve posted a chart summarizing the key features of all these VPN technologies at my Web site.) And in conclusion, I’ll list a few deployment scenarios and recommend which flavor of VPN may best suit each one. Layer 2 VPNs The Point-to-Point Protocol (PPP) supports dial-up Internet access and enterprise remote access between two endpoints, e.g., a mobile worker’s laptop and an organization’s remote access server. Layer 2 VPN protocols like the Layer 2 Tunneling Protocol (L2TP) move PPP packets between two endpoints over an IP-based internet (private or public) by creating a virtual "modem link" from a tele-worker’s PC to the corporate LAN. In one common L2TP scenario, a user dials up an ISP and establishes a connection. Based on his authentication credentials (e.g., Caller ID, user@domain name), the ISP recognizes this customer as being one who requires a tunnel to a corporate L2TP server. An L2TP access concentrator operated by the ISP handles authentication on behalf of the corporation. If authentication succeeds, the L2TP access concentrator passes or “proxies” the packets between the remote user L2TP client and the L2TP server at the corporate network. This scenario is referred to as compulsory tunneling. L2TP can also be used to support voluntary tunnels, similar to Microsoft’s Point-to-Point Tunneling Protocol (PPTP) a common implementation of a Layer 2 VPN. L2TP uses traditional dial authentication protocols (CHAP, PAP, etc.). It allows a tunnel server to enforce access controls at the point where the dial-up session connects to the corporate network. L2TP can encapsulate IP and non-IP protocols within PPP. Remember, L2TP only tunnels; it does not encrypt. L2TP can be carried over a Layer 3 VPN when message confidentiality and integrity are required. Layer 3 (IPsec) VPNs Layer 3 VPNs provide virtual connections using Internet standard IP Security extensions (IPsec). IP packets can be exchanged between IPsec-enabled tunnel endpoints—host computers, firewalls, security appliances, routers, or servers—over any IP network. The “security association” connecting IPsec endpoints is typically created using the Internet Key Exchange (IKE) protocol. Each IPsec endpoint authenticates the far end of the tunnel, negotiates protocols, encryption and authentication algorithms, and generates shared secret keys—essentially providing everything needed to enforce the security policy for the virtual connection. WatchGuard customers can use Mobile User VPN for secure remote access and IPsec Branch Office VPN for secure site-to-site communications. The most common form of IPsec is tunnel-mode, using the Encapsulating Security Payload (ESP). In this method, each original IP packet is encapsulated within another IP packet containing the addresses of the two tunnel endpoints. An ESP header is added to convey the IPsec parameters. The inner packet may be encrypted to ensure that the entire original IP packet’s content, even its source and destination, remain private as the packet traverses a public network. This prevents eavesdropping, and makes it more difficult to perform traffic analysis or denial of service attacks by sniffing IP packets. An ESP trailer is appended to the original (now encrypted) IP packet, for packet authentication (message integrity). There are other flavors of IPsec—for example, an Authentication Header (AH) that provides message integrity without encryption; and “transport-mode” IPsec, which protects packet payload end-to-end between hosts, without encapsulation. But these are deployed far less often than the tunnel-mode ESP I've described here. When using tunnel-mode IPsec, you can apply security policies to any IP packet entering or leaving a corporate network, much as you would apply packet filters at a firewall. Initial standards support IKE authentication via preshared secret, raw public key, or digital certificate — methods well-suited for site-to-site VPNs, but not easily applied to large remote access VPNs. Secure Application Streams The VPNs I’ve described thus far create a secure path for every application protocol, but their use might not be feasible in some circumstances. If all you need is to exchange e-mail or perform remote administrative functions securely, or if your business and e-business needs can be satisfied by securing all browser-accessible applications, you may be able to solve your privacy issues by securing individual application streams. Secure Shell, Secure Sockets Layer, and Transport Layer Security do just this. Secure Shell (SSH) is used to secure application streams, and is commonly seen in UNIX environments. You use an SSH client to initiate a TCP connection to an SSH server that sits at the edge of the protected network, serving as a gatekeeper between the untrusted and trusted networks. The SSH client and server create an encrypted session on top of TCP that can be used for host or user authentication. Once authenticated, additional application sessions (for example, POP3) can  be multiplexed over the SSH connection. A POP3 stream would be encrypted over the public (untrusted) Internet; then, once it reaches the SSH server gateway, can be forwarded as clear text to a private enterprise mail server located behind the SSH server. Secure Sockets Layer (SSL) is commonly used to secure Web traffic (HTTP). When you use a Web browser to secure a transaction, the browser's SSL client initiates an encrypted session on top of TCP. One of the many things you can do over an SSL connection is perform sub-authentication, where the client authenticates to the server. SSL sub-authentication at a proxy host is commonly used for single sign-on environments and for Web-based extranets. Since the SSL session itself is encrypted, anything else that you pass over the connection (e.g., user IDs, authentications to an ftp server) can be safely passed in clear, unencrypted text. The Transport Layer Security (TLS) protocol is another Internet standard like IPsec, but is based on SSL. As with SSH, you can use TLS to secure non-Web application protocols (POP3, SMTP, IMAP, Telnet). There are two ways you can use TLS to secure application streams. The first way is to assign a new port number used by TLS connections for each client/server application, e.g., mail. The existing "well known" port is used for unencrypted traffic, and encrypted traffic is sent through the new port. An alternative is to modify both the client and server software of an application so that they negotiate or upgrade to communicate using a secure TLS channel. SSH, SSL, and TLS operate end-to-end (client/server) or as proxies on firewalls or security appliances. They are useful alternatives when: changes to client desktop software cannot be imposed unilaterally across multiple enterprises; when a legacy authentication method is not supported by IPsec;  or when an IPsec site-to-site VPN doesn’t provide the ability to create affinity groups composed of trusted individuals from more than one enterprise. Deployment Scenarios at the Teleworker’s Small Office A VPN is the final element of securing DSL connections. In cases where your traffic travels over the public Internet, you should consider some form of VPN between a teleworker and the corporate network. If you are connecting a remote user’s single PC  to the corporate network, consider using a remote user IPsec (Layer 3) VPN to a Firebox firewall, or an IPsec capable router. However, if your teleworker requires multi-protocol support (that is, other than TCP or UDP IP), run L2TP over IPsec. Where your remote user shares a household (e.g., user has a roommate or spouse that works for a competitor), add additional security to the connection by requiring your user to authenticate. (Requiring authentication for a remote user in a shared household should also be applied with Branch Office VPNs.) If you take the IPsec route on Windows 2000 PCs, be sure to check for interoperability between your security gateway and the Windows 2000 IPsec/L2TP implementation . If your employees are using Windows 95/98, you will need either a third party or vendor-provided IPsec adapter (such as WatchGuard’s Mobile User VPN). One caveat: some clients can be troublesome to install on certain PCs and laptops, and are not compatible with all NIC and modem cards. If your remote user’s PC only requires browser access to corporate servers, you can take the current path of least resistance and use SSL. This (or a TLS-protected application like e-mail) may also be attractive if you must tackle both the problem of securing e-business transactions, and the problem of securing branch office remote access. Teleworker and small offices that employ SOHO firewall appliances, such as the WatchGuard SOHO, can operate IPsec site-to-site. I believe site-to-site (from teleworker firewall to a corporate firewall) is the simplest, most secure deployment you could ask for. Look for a teleworker firewall that supports IPsec and can be centrally administered through the same management interface as your corporate, IPsec-capable firewall. In this scenario, you can assert security policy uniformly and transparently across all teleworker DSL connections, and you avoid help desk issues for desktops in teleworker residences. Central administration of your VPN topology will quickly become a top priority when choosing a corporate VPN server. Look for products that provide effective means to administer pre-shared keys today, and that have a viable approach for managing digital certificates and any legacy authentication method you may have already implemented across your enterprise (e.g., 2-factor, token-based authentication). Closing Remarks on This Series Broadband local access forces IT administrators to consider on a much grander scale than before the security of systems, information, and communication outside an organization’s core networking environment. It also forces administrators to reconsider some existing security policies and practices for remote access in general. These are Good Things. You may wonder whether it’s necessary to implement all the suggested practices I’ve mentioned in this series. You may also wonder which of these solutions is best for your organization. The only way to answer these questions is to consider policy first, understand the risks broadband local access introduces, and assess which risks you can mitigate or reduce most effectively given available budget and expertise.