Troubleshooting Remote Access VPNs
Use the following checklist to troubleshoot remote access VPN connections:
Verify that on the
VPN server, enough ports have been configured in the Ports node for the
relevant VPN type needed (PPTP or L2TP) and that not all available
ports are currently being used.
Verify
that the Remote Access Server option is enabled on the server
properties General tab in the Routing And Remote Access console.
Verify
that the VPN connection has the appropriate permissions through dial-in
properties of the user account and remote access policies.
Verify
that the VPN client, the remote access server, and the remote access
policy are configured to use at least one common authentication
protocol.
Verify
that the VPN client, the remote access server, and the remote access
policy are configured to use at least one common encryption strength.
Verify
that the remote access server (or RADIUS server) computer is a member
of the RAS And IAS Servers security group in the local domain.
Verify that the settings of the remote access policy profile are not in conflict with properties of the remote access server.
Verify that, if MS-CHAP v1 is being used as the authentication protocol, the user password does not exceed 14 characters.
Troubleshooting Router-to-Router VPNs
Use the following checklist to troubleshoot router-to-router VPNs:
Verify that at
each end of the VPN connection, both the Router option and the LAN And
Demand-Dial Routing option are selected on the General tab of server
properties in the Routing And Remote Access console.
Verify
that on each remote access server, the Enable IP Routing option is
selected on the IP tab of server properties in the Routing And Remote
Access console.
Verify
that on each remote access server, enough ports have been configured in
the Ports node for the relevant VPN type needed (PPTP or L2TP).
Verify
that, for each demand-dial interface created for the VPN connection,
you selected the option in the Demand-Dial Interface Wizard to route IP
traffic over that demand-dial interface.
Verify
that you have created static routes on each remote access server so
that traffic destined for the opposite network is associated with the
appropriate VPN interface.
Verify
that on each remote access server, the dial-out credentials of the
locally configured demand-dial interface match the name of the remote
answering interface and also match a user account name and password in
the remote domain.
Verify
that each demand-dial (VPN) interface, answering remote access server,
and answering remote access policy are configured to use at least one
common authentication protocol and one common encryption strength.
Verify
that the remote access connection has the appropriate permissions
through dial-in properties of the user account (corresponding to the
name of the demand-dial interface) and through remote access policies.
Verify
that at each end of the VPN connection, the remote access server (or
RADIUS server) computer is a member of the RAS And IAS Servers security
group in the local domain.
Verify
that on each remote access server, the settings of the remote access
policy profile are not in conflict with properties of the remote access
server.
Configuring VPN Types
Windows Server 2003
includes support for two types of VPNs: PPTP and L2TP/IPSec. If you did
not originally specify a VPN remote access server role when you ran the
Routing And Remote Access Server Setup Wizard, Windows Server 2003
includes only five ports for each VPN type. Because each port enables a
single remote access connection, a typical Routing And Remote Access
installation by default allows only five simultaneous connections of
each type. These ports appear in the Routing And Remote Access console
when you select the Ports node, as shown in Figure 6.
However,
you can easily configure more ports for either type of VPN connection
and allow more simultaneous connections. To perform this task, open the
Ports Properties dialog box, select a port type, and click the Configure
button. This procedure opens the Configure Device dialog box, shown in Figure 7. To modify the number of simultaneous connections your VPN server allows, enter an appropriate value into Maximum Ports.
Windows Server 2003 can
handle up to 1000 simultaneous VPN connections. You can configure a
maximum of 1000 ports for PPTP connections and another 1000 ports for
L2TP connections.
Note
If
you originally specified a VPN remote access server role when you ran
the Routing And Remote Access Server Setup Wizard, 128 ports of each VPN
type will be configured by default. |
Tip
You
need to understand VPN ports for the exam. Expect to see questions
indicating that VPN access is blocked only because too few ports are
configured. Other questions will test your knowledge of how many ports
can be created and how many simultaneous connections Windows Server 2003
can handle. |
Using PPTP
In general, PPTP-type
VPN tunnels are easier to implement but less secure than those of the
certificate-based L2TP/IPSec type. Although PPTP-based VPN connections
do provide data confidentiality (captured packets cannot be interpreted
without the encryption key), they do not provide data integrity (proof
that the data was not modified in transit) or data origin authentication
(proof that the data was sent by the authorized user).
For
PPTP connections, encryption is provided by MPPE—which does not require
you to configure a PKI or to assign certificates to users or computers
at either end of the virtual private connection. However, you can use
PPTP with a certificate infrastructure if you choose EAP-TLS as the
authentication protocol.
Figure 8
illustrates PPTP-type encapsulation. The link between the two VPN
end-points is treated as a PPP connection, which is encrypted through
MPPE. The PPP frame is then wrapped with a Generic Routing Encapsulation
(GRE) header and an IP header.
Tip
For
the exam, if you see the protocol GRE mentioned in an answer choice,
remember that it is merely an indirect reference to PPTP. |
Configuring PPTP Connections on the VPN Server
To configure a
remote access policy that permits VPN connections, you might need to
create a policy condition that specifies VPN access through the
NAS-Port-Type condition of Virtual (VPN). As long as a matching policy
defined by Windows Group, NAS-Port-Type, or some other condition grants
permission to the connection, VPN access is allowed. Aside from defining
a remote access policy that matches the connection, you simply need to
verify that enough PPTP ports exist to handle the number of simultaneous
connections you want to support.
To deny PPTP
connections to the VPN server, first open the Configure Device - WAN
Miniport (PPTP) dialog box available by selecting Wan Miniport (PPTP)
and clicking Configure in the Ports Properties dialog box. Then clear
the Remote Access Connections (Inbound Only) check box and the
Demand-Dial Routing Connections (Inbound And Outbound) check box.
Note
The
only way to distinguish VPN connections from other connections in
remote access policies is through NAS-Port-Type. In remote access
policies, the NAS-Port-Type for VPN connections is known as Virtual
(VPN). Note also that there is no way to distinguish PPTP connections
from L2TP/IPSec connections in remote access policies. |
Configuring PPTP Connections on a VPN Client
To
configure a PPTP-type VPN connection on a client, run the New
Connection Wizard and specify a VPN connection. By default, VPN
connection types are set to Automatic. In this mode, the VPN connection
attempts communication first through L2TP over certificate-based IPSec,
and then, if unsuccessful, through PPTP. Therefore, VPN connections
default to the PPTP type when you have not deployed a certificate
infrastructure to support IPSec. In addition, you can also configure a
VPN connection to communicate only by means of the PPTP protocol by
opening the properties dialog box for a VPN connection, clicking the
Networking tab, and then selecting the PPTP VPN option in the Type Of
VPN drop-down list box. Figure 9 shows this option.
Off the Record
PPTP-type
VPNs have an undeservedly bad reputation for being insecure and,
because they are also so easy to configure, tend to be frowned upon by
would-be technical mavens as “VPNs for beginners.” In reality, PPTP is
not so much insecure as it is less secure than L2TP/IPSec, and PPTP is
simply a better option than L2TP/IPSec in some networking scenarios. For
example, if you need to support remote users who connect from public
computers such as those found in a library, the unfeasibility of using
computer certificates makes PPTP the only realistic VPN solution. |
Using L2TP/IPSec
For L2TP/IPSec-type
connections, the L2TP protocol provides VPN tunneling, and the
Encapsulation Security Payload (ESP) protocol (itself a feature of
IPSec) provides data encryption.
Figure 10 illustrates an L2TP/IPSec packet.
L2TP/IPSec
connections, unlike those of PPTP, require computer authentication in
addition to user authentication. Computer authentication is performed
first; this process occurs during all L2TP/IPSec connection attempts
between remote access clients and servers. After the tunnel endpoints
are authenticated and a secure channel is established between the client
and the server, user authentication follows. User authentication over
L2TP/IPSec VPN connections occurs by means of any of the same set of
authentication protocols that are used for PPTP and dial-up connections.
Once user authentication is complete, computer authorization follows.
Computer Certificates and L2TP/IPSec
For most L2TP-based VPN
connections, computer authentication is performed by means of a
certificate infrastructure. To successfully implement this type of VPN,
you must install computer certificates issued by the same certificate
authority (CA) on each VPN client and VPN server. If you are using a
Windows Server 2003 enterprise CA as an issuing CA, you should configure
your Active Directory domain for autoenrollment of computer
certificates by using the Computer Configuration group policy. Through
this method, each computer that is a member of the domain automatically
requests a computer certificate when the Computer Configuration group
policy is updated.
Certificates contain
enhanced key usage (EKU) extensions that define the purpose of the
certificate. The computer certificate that you assign to the L2TP/IPSec
client must contain either the Client Authentication purpose or the
IPSec purpose in the EKU extensions of the certificate. Meanwhile, the
VPN server must contain the Server Authentication purpose if it is
deployed as a remote access server, or it must contain both the Server
Authentication purpose and the Client Authentication purpose if it is
deployed in a router-to-router VPN. When two or more purposes are
required, they must be included in the extensions of the same
certificate.
Note
If
you are using EAP-TLS for user authentication, you must install a user
certificate on all VPN clients, and if the authenticating server is a
RADIUS server, you must install a computer certificate on the RADIUS
server. L2TP/IPSec VPNs do not require the use of EAP-TLS for user
authentication. |
Preshared Keys and L2TP/IPSec
The only case in
which certificates are not required for L2TP-based VPN connections is
when both the VPN client and the VPN server are running Windows Server
2003. In this case, you have the option to configure computer
authentication through the use of a preshared key:
a shared string of plaintext that is used to encrypt and decrypt IPSec
communication. Preshared keys are not considered a secure means of
authentication and are therefore recommended only in test or temporary
deployments.
Disabling L2TP/IPSec Connections
To disable VPN
access through L2TP connections, you merely need to set the maximum L2TP
ports to 0 in the Routing And Remote Access console. (Note that this
option is not available with PPTP.) To disable L2TP connections, open
the Ports Properties dialog box, select WAN Miniport (L2TP), and then
click the Configure button. In the Configure Device — WAN Miniport
(L2TP) dialog box, type 0 into Maximum Ports. Click Yes when prompted.
