CHAPTER 6 (I)

CHAPTER 6

Understanding and Troubleshooting Remote Access Connections

As an enterprise support technician, you might be called on to help remote users who have trouble connecting to the corporate network. The most common way that users access a corporate network remotely is through a virtual private network (VPN), but with Windows Server 2008 R2 and Windows 7, Microsoft has introduced Direct Access, a much-improved alternative to VPNs. To resolve remote access issues, you need to understand the components that make up a VPN and Direct Access infrastructure and how these components work together when a user initiates a remote access connection.

Exam objective in this chapter:

■ Identify and resolve remote access issues.

Lessons in this chapter:

■ Lesson 1: Understanding VPN Client Connections 223

■ Lesson 2: Understanding Direct Access Client Connections 251

Before You Begin

To perform the exercises in this chapter, you need:

■ A domain controller running Windows Server 2008 R2

■ A client running Windows 7 Enterprise that is a member of the domain

■ A basic understanding of IPv6

REAL WORLD

J.C. Mackin

Direct Access, introduced with Windows 7 and Windows Server 2008 R2, is the first major feature of Windows built exclusively on IPv6 and that lacks any failback to IPv4.  You should view the arrival of this feature as something of a wake-up call. To this point, many IT professionals have considered IPv6 a topic they can worry about tomorrow, and many even have been disabling IPv6 in the mistaken belief that it somehow degrades network performance (it doesn’t). That many have been living in IPv6 denial is perhaps not surprising: IPv6 has always been a technology of the future. However, that future is now rapidly approaching. The Internet Assigned Numbers Authority (IANA), the body that governs the distribution of IP addresses, has predicted that new IPv4 addresses will be depleted as soon as 2011. Starting very soon, then, IPv6 will become and remain a key cornerstone networking technology. I recommend that you take this topic seriously and become familiar with the IPv6 addressing as soon as possible. For a good introduction to IPv6 in Windows networks, I recommend Understanding IPv6, Second Edition (Microsoft Press, 2008), by Joseph Davies.

Lesson 1: Understanding VPN Client Connections

The most common way for remote users to access a corporate network is through a VPN, so troubleshooting remote access typically requires you to understand how VPNs work. However, achieving this familiarity is not easy. The successful negotiation of a VPN depends on many factors, including the proper configuration of the VPN infrastructure, the user and/or computer authentication, and user authorization. Besides the complexity of the VPN connection process in general, Windows 7 and Windows Server 2008 R2 also offer different VPN types, each with particular requirements, advantages, and disadvantages.

This lesson begins with an overview of VPNs and then describes the components that make up a VPN connection. Next, it provides a summary of the various VPN types and explains the steps in establishing a remote access VPN connection. Finally, it concludes with a general checklist for troubleshooting remote access VPNs.

After this lesson, you will be able to:

■ Describe the elements of a VPN infrastructure

■ Describe the advantages and disadvantages of the VPN types offered in Windows networks

■ Describe the VPN connection process

■ Troubleshoot VPN connectivity

Estimated lesson time: 120 minutes

Understanding VPNs

A VPN is a private, encrypted network connection that crosses the public Internet. Typically, a VPN is used either to connect two office sites or to enable remote computers to access a single office network. In the case of a site-to-site VPN (shown in Figure 6-1), no special configuration  is required for the clients. The negotiation of the private connection for these VPNs is performed by the VPN servers at each office, and clients in opposite branches communicate with each other as they would communicate with clients in their own branch.

In a remote access VPN, however, the client running Windows 7 must be configured to negotiate a connection to the VPN server. For this reason, it is only the remote access VPN

that is covered on the 70-685 exam. A remote access VPN is shown in Figure 6-2.

FIGURE 6-1 A site-to-site VPN

FIGURE 6-2 A remote access VPN

Understanding VPN Encapsulation and Tunneling

A VPN works by taking the communication exchanges that computers would use if they were located on the same network, encrypting these exchanges, and then encapsulating

the information with the additional networking data needed to cross the Internet. As a result of this encapsulation, the physical network through which private data is sent

becomes transparent to the two endpoints of communication, as shown in Figure 6-3. In the illustration, two computers, Computer1 and Computer2, are connected physically only

through the Internet, but the transparency of the physical link is revealed in the results of the Tracert command run at each computer. Although many hops separate the two

computers, each appears to the other as only one hop away through the VPN connection. Communication occurs between the two private IP addresses, each within the 192.168.10.0/24 subnet, as if the computers were both located on the same network segment.

FIGURE 6-3 A VPN connection makes remote computers appear local.

The term used to describe this process of encapsulating private data within public data is tunneling. A VPN tunneling protocol creates a secure channel between two VPN servers or between a VPN server and a VPN client. Within a VPN tunnel, encryption is used to protect data as it crosses the public network. Private data is encrypted before the data is sent out onto the tunnel and then decrypted when it reaches the end of the tunnel.

Data authentication is also performed by most VPN tunneling protocols to validate the data in two ways. First, tunneling protocols can perform data integrity checking, which ensures that the data remains untouched from its original version. Second, they can perform data origin authentication, which ensures that the data is truly sent from the party that claims to be sending it.

Understanding Remote Access VPN Infrastructure

To provide remote access to VPN clients, a Windows-based network must include a number of features, as shown in Figure 6-4. At a minimum, these features include the VPN client and client software (or network connection in Windows), a VPN server running Routing and Remote Access Services (RRAS), and an internal DNS server. Typically, however, a VPN infrastructure will also include a domain controller, a certificate server, and a DHCP server. Finally, a Network Policy Server (NPS) might also be used. The role of these VPN infrastructure components is described in the following section.

FIGURE 6-4 A VPN infrastructure

VPN CLIENT AND CLIENT SOFTWARE

For a computer running Windows 7 to act as a VPN client, Windows needs to be configured with a VPN client. Generally speaking, VPN clients can be any of three types: a Windows 7 VPN connection, a Connection Manager (CM) client, or a third-party client.

First, in Windows 7, you can configure a VPN connection in the Network and Sharing Center by first clicking Set Up A New Connection Or Network, as shown in Figure 6-5.

FIGURE 6-5 Creating a VPN connection in Windows 7

This step opens the Set Up A Connection Or Network wizard. To create a VPN connection, select Connect To A Workplace, as shown in Figure 6-6, and then follow the prompts to complete the wizard.

FIGURE 6-6 Using the Set Up A Connection Or Network wizard

Once you have completed the wizard, Windows 7 displays the new VPN connection in Network Connections, which you can open by clicking Change Adapter Settings in the Network And Sharing Center. A Windows 7 VPN connection is shown in Figure 6-7.

 

FIGURE 6-7 A VPN connection

Although this first type of VPN client is easy to create and configure on a single machine, no method built into Windows allows you to create many such VPN clients in a large network. As an alternative, many administrators use the Connection Manager Administration Toolkit (CMAK) to create client connection profiles that can be distributed and installed as CM clients. The advantage of this method is that users can create and install VPN clients from the profile without needing any technical knowledge. As a third option, third-party VPN client software can also be deployed to client desktops through Group Policy or another means.

NOTE

WHAT ARE CM AND THE CMAK?

CM is a client network connection tool that allows a user to connect to a remote network, such as a corporate network protected by a VPN server.

Feature Wizard. It allows you to automate for remote users the creation of predefined connections to remote servers and networks. To create and  ustomize a CM client for your users, you use the CMAK wizard. The CMAK wizard allows you to automate many aspects of a connection (such as the IP address of

the VPN server) so that users do not need to handle any technical details manually. VPN SERVER

The VPN server in a Windows VPN infrastructure runs RRAS, which in Windows Server 2008 is a role service of the Network Policy and Access Service server role. Servers configured with RRAS can receive requests from remote access users located on the Internet, authenticate these users, authorize the connection requests, and finally either block the requests or route the connections to private internal network segments.

NOTE

REMOTE ACCESS AUTHENTICATION VS. AUTHORIZATION

Authentication is the process of validating—through verification of a password or of alternative credentials such as a certificate or smart card—that the user is in fact the person

he or she claims to be. Whereas authentication refers to the process of validating user credentials, authorization   refers to the process of allowing users access to resources. After remote access authentication occurs, the remote access connection is authorized only if the proper permissions are configured both on the Dial-in tab of the user account    properties dialog box (discussed in the section entitled “Domain Controller” later in this lesson) and in the network policy that applies to the connection. For authentication, RRAS can be configured to forward the authentication request to a RADIUS (NPS) server or to use Windows authentication. When configured to use Windows authentication and the local VPN server is not a member of a domain, RRAS authenticates users by checking the received credentials against those stored in its local security account manager (SAM) database. When configured to use Windows authentication and the local VPN server is a member of a domain, RRAS passes user credentials to an available domain controller.

NOTE

REMOTE ACCESS AUTHENTICATION IS SEPARATE FROM DOMAIN LOGON AUTHENTICATION

Remote access authentication precedes domain logon authentication; if a VPN user is attempting to log on to a domain remotely, the VPN connection must be authenticated, authorized, and established before normal domain logon occurs.

After the credentials submitted with the remote access connection are authenticated, the connection must be authorized. Remote access authorization consists of two steps: first, verification of the dial-in properties of the user account submitted by the VPN connection, and second, application of the first matching network policy defined on the VPN server (or NPS server if RRAS is configured for RADIUS authentication).

NOTE

WHAT ARE NETWORK POLICIES?

Network policies define various connection types by specific conditions such as Windows group membership, health policies, or operating system, and then either allow or deny

requests that match those conditions. Network policies can be defined in RRAS or in NPS.

Network policies are shown in Figure 6-8.

FIGURE 6-8 Network policies are used to authorize connection requests.

DNS SERVER

VPN clients that connect to a private network must be configured with the address of an internal DNS server that can resolve the names of resources on that private network. Usually, the domain controller that authenticates the remote access user also acts as the DNS server.

DOMAIN CONTROLLER

In a VPN infrastructure, a domain controller is most often used to authenticate and authorize users who attempt to connect to the corporate network through the VPN.

Besides authenticating the user credentials, a domain controller is also used to authorize the user account for remote access. For a user account to be authorized for remote access, the account must be configured with either the Allow Access or the Control Access Through NPS Network Policy network access permission.

You can configure the network access permission for an individual user on the Dial-in tab of that user’s Properties dialog box in the Active Directory Users And Computers console, as shown in Figure 6-9. By default, domain user accounts are configured with the Control Access Through NPS Network Policy setting.

FIGURE 6-9 The Network Access Permission setting of a user account

CERTIFICATE SERVER

Many VPNs use a form of encryption that relies on public key cryptography and a public key infrastructure (PKI). In a PKI, certificates are used both to validate the certificate holder’s identity and to encrypt or decrypt data. Each certificate is associated with a key pair, made up of a public key (which is attached to the public certificate and presented freely to the world) and a private key (which is generated locally and never sent over the network). If the private key is used to encrypt data, the associated public key is used to decrypt that data. If the public key is used to encrypt data, the associated private key is used to decrypt that data. In a typical scenario, a sender uses the receiver’s public key to encrypt a message sent to that receiver. Only the receiver then has access to the private key needed to decrypt the message. In a PKI, certificates are created and issued by a certification authority (CA), such as a computer running Windows Server 2008 and configured with the Active Directory Certificate Services server role.

DHCP SERVER

An internal DHCP server normally is used to provide VPN clients with an IP address. When such a DHCP server is used for this purpose, the external adapter of the VPN server must be configured with a DHCP Relay Agent that can respond to the DHCP requests from external VPN clients. Alternatively, the VPN server itself can be configured to assign addresses to VPN clients without the help of the DHCP server on the corporate network.

NPS SERVER

NPS is the Microsoft implementation of a RADIUS server and proxy. You can use NPS to manage authentication, authorization, and health policy centrally for VPN connections,

dial-up connections, 802.11 wireless connections, and 802.1x connections. NPS can also act as a health evaluation server for Network Access Protection (NAP). Like RRAS, NPS is a role service of the Network Policy and Access Service server role in Windows Server 2008.

Figure 6-10 shows an example of how NPS can be used as a central authentication and authorization point for network access. In the illustration, NPS acts as a RADIUS server for

a variety of access clients. For user credential authentication, NPS uses a domain controller.

FIGURE 6-10 An NPS server can be used to manage authentication and authorization centrally.

NOTE

NPS AND INTERNET AUTHENTICATION SERVICE (IAS)

NPS is the replacement for Internet Authentication Service (IAS) in Windows Server 2003.

Understanding Windows 7 VPN Tunneling Protocols

Windows 7 supports four tunneling protocols for remote access VPN connections to corporate networks. Each of these is used in different remote access scenarios, and each

has different requirements for the operating system, configuration, and infrastructure. The following section introduces these four VPN protocols in more detail.

Understanding IKEv2

New in Windows 7 and Windows Server 2008 R2, Internet Key Exchange version 2 (IKEv2) is a tunneling protocol that uses Internet Protocol Security (IPSec) for encryption. An important performance advantage of an IKEv2-based VPN is its support of VPN Reconnect (also called Mobility). VPN Reconnect is a feature that enables VPN connections to be

maintained when a VPN client moves between wireless hotspots or switches from a wireless to a wired connection. Another important advantage of IKEv2 is that, like Secure Socket Tunneling Protocol (SSTP) and Point-to-Point Tunneling Protocol (PPTP) VPNs (and unlike those based on the Layer 2 Tunneling Protocol [L2TP]), client computers do not need to provide authentication through a machine certificate or a pre-shared key. Finally, compared to the other VPN type that is based on IPSec encryption (L2TP), IKEv2 offers improved performance in that the connectivity is established more quickly.

EXAM TIP

For the 70-685 exam, you have to know what VPN Reconnect is, and that only IKEv2 VPNs

support this feature.

IKEv2 VPNs require a PKI. In an IKEv2 VPN, the server must present a server authentication certificate to the client, and the client needs to be able to validate this certificate. To perform this validation, the root certificate for the CA that has issued the server authentication certificate must be installed on the client computer in the Trusted Root Certification

Authorities certificate store. From the standpoint of performance and security, IKEv2 is the preferred VPN type and should be deployed when operating system requirements for such a VPN are met. Those requirements are Windows 7 for the VPN client and Windows Server 2008 R2 on the VPN server.

Understanding SSTP

SSTP VPNs were introduced in Windows Server 2008 and can be used by clients running Windows Vista SP1 or later. This type of VPN is based on the same HTTP-over-SSL protocol used for secure Web sites. The most important feature of an SSTP-type VPN is that it uses only TCP port 443 for communication, a port left open on most firewalls for secure Web traffic. The fact that most firewalls do not need to be reconfigured for SSTP communication enables SSTP VPN clients to connect through most Network Address Translation (NAT) devices, firewalls, and Web proxies. Other VPN types often cannot traverse these network features. An SSTP VPN is therefore an unusually flexible type of remote access VPN that can be implemented in more network scenarios than other VPNs can. Like IKEv2 and PPTP VPNs, and unlike L2TP-based VPNs, SSTP VPNs do not require client computer authentication by default (though they can be configured to require it). However, as with a secure Web server, the SSTP VPN server must present a computer certificate to the requesting client at the beginning of the communication session. The VPN client must then be able to validate the server’s computer certificate. For this to occur, the root certificate of the CA that has issued the VPN server’s computer certificate must be installed in the Trusted Root Certification Authorities certificate store on the VPN client computer.

NOTE

CERTIFICATE CHECKING IN SSTP VPNs

In a PKI, an administrator may revoke a certificate previously issued to a user, computer, or service. A CA publishes the lists of revoked certificates in an official certificate revocation list (CRL). For SSTP VPN connections, by default, the client must be able to confirm that the VPN  server’s computer certificate has not been revoked by checking the server identified in the certificate as hosting the CRL. If the server hosting the CRL cannot be contacted, then the validation fails, and the VPN connection is dropped. To prevent this failure, you must either publish the CRL on a server that is accessible on the Internet or configure the client not to require CRL checking. To disable CRL checking, create a registry setting at the following location:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Sstpsvc\parameters

The setting must be a DWORD value named NoCertRevocationCheck. Set the value to 1.

Understanding L2TP

L2TP is an industry-standard tunneling protocol designed to run natively over IP networks. Security for L2TP VPN connections is provided by IPSec, which performs the data authentication and encryption needed to ensure that L2TP tunnels are protected. The combination of L2TP with IPSec for tunneling purposes is usually referred to as L2TP over

IPSec or L2TP/IPSec. L2TP/IPSec VPNs have certain drawbacks compared to IKEv2 and SSTP VPNs. First, besides requiring user authentication as all VPN protocols do, L2TP/IPSec requires client computer authentication. Because of this requirement, all VPN client computers from which a user might connect must be configured either with a computer certificate or a pre-shared key specific to the VPN server. Therefore, L2TP/IPSec prevents a user from establishing a VPN connection from public terminals or from any computer that has not been specially configured for the VPN.

To configure a VPN client connection running Windows 7 to use either a computer certificate or a pre-shared key for L2TP/IPSec authentication, open the Properties dialog box

of the VPN connection, click the Security tab, and then click Advanced Settings. This step opens the Advanced Properties dialog box, as shown in Figure 6-11. By default, certificate authentication is selected. To obtain a client authentication certificate to use with this setting, you typically need to submit a request to the CA on the corporate network and then install the certificate after the request is approved. If you change the setting to Use Pre-shared Key For Authentication, you need to supply the key in the area provided.

Besides the requirement of client computer authentication, another limitation of L2TP/IPSec VPNs is that they do not natively support the traversal of NAT devices. However, you can enable L2TP/IPSec to cross a NAT device if you change a particular registry value on both the VPN client computer and the VPN server.

 FIGURE 6-11 Configuring VPN client authentication for L2TP/IPSec