Remote access VPN security considerations

  • Article

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2

Remote access VPN security considerations

You can enhance remote access VPN security through:

  • L2TP connections

  • Strong authentication

  • Data encryption

  • PPTP or L2TP/IPSec packet filtering

  • Firewall packet filtering

  • Multi-use VPN servers

  • Preventing traffic routed from remote access clients

  • Remote access policy profile packet filtering

For more information, see Remote access VPN connection.

Note

  • On Windows Server 2003, Web Edition, and Windows Server 2003, Standard Edition, you can create up to 1,000 Point-to-Point Tunneling protocol (PPTP) ports, and you can create up to 1,000 Layer Two Tunneling protocol (L2TP) ports. However, Windows Server 2003, Web Edition, can accept only one virtual private network (VPN) connection at a time. Windows Server 2003, Standard Edition, can accept up to 1,000 concurrent VPN connections. If 1,000 VPN clients are connected, further connection attempts are denied until the number of connections falls below 1,000.

L2TP connections

A VPN server running Windows Server 2003 provides support for both Point-to-Point Tunneling Protocol (PPTP) and Layer Two Tunneling Protocol (L2TP). By using encryption, PPTP-based VPN connections provide data confidentiality (captured packets cannot be interpreted without the encryption key). PPTP-based VPN connections, however, 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). By using Internet Protocol Security (IPSec), L2TP/IPSec VPN connections provide data confidentiality, data integrity, and data origin authentication. However, L2TP can only be used with Windows 2000 and Windows XP clients.

L2TP/IPSec connections can use the following methods to authenticate the IPSec security association:

  • A computer certificate

    Computer certificates are the recommended method of authentication as they provide strong authentication and are very difficult to impersonate or compromise. Computer certificate authentication requires a public key infrastructure (PKI) to issue computer certificates to the VPN server computer and all VPN client computers.

  • A preshared key

    A preshared key is a string of text that is configured on both the VPN client and VPN server. Preshared key is a relatively weak authentication method, therefore it is only recommended that you use preshared key authentication while your PKI is being deployed or when preshared key is required by the VPN server to which your VPN clients are connecting.

Strong user authentication

For user authentication, use the strongest authentication scheme that is possible for your remote access VPN configuration. The strongest authentication scheme is the use of EAP-TLS with certificates. For more information, see Deploying Certificate-based Authentication for VPN Connections and Network access authentication and certificates.

Otherwise, use MS-CHAP version 2 authentication and enforce the use of strong passwords on your network. For more information, see MS-CHAP version 2.

Data encryption

For encryption, you can use either link encryption or end-to-end encryption with link encryption:

  • Link encryption encrypts the data only on the link between the VPN client and the VPN server. For PPTP connections, you must use Microsoft Point-to-Point Encryption (MPPE) in conjunction with either MS-CHAP, MS-CHAP v2, or EAP-TLS authentication. For L2TP/IPSec connections, IPSec provides encryption on the link between the VPN client and the VPN server.

  • End-to-end encryption encrypts the data between the source host and its final destination. You can use IPSec after the VPN connection is made to encrypt data from the source host to the destination host.

To require encryption, select the appropriate encryption strengths on the Encryption tab of the remote access policy profile that is used by your remote access VPN clients. For more information, see Configure encryption.

Encryption on client computers is configured in the properties of the network connection.

PPTP or L2TP/IPSec filtering

To secure the VPN server from sending or receiving any traffic on its Internet interface except VPN traffic, you need to ensure that PPTP or L2TP/IPSec input and output filters are configured on the interface that corresponds to the connection to the Internet. For more information about PPTP filters, see Add PPTP Filters. For more information about L2TP/IPSec filters, see Add L2TP over IPSec Filters.

Because IP routing is enabled on the Internet interface, if PPTP or L2TP/IPSec filters are not configured on the Internet interface, then any traffic received on the Internet interface is routed, which may forward unwanted Internet traffic to your intranet.

Firewall packet filtering

It is a common practice to provide protection to intranet hosts, such as a VPN server, from Internet hosts using a firewall. If you have a firewall, you must configure packet filters on the firewall to allow traffic to and from VPN clients on the Internet and the VPN server. For more information, see VPN servers and firewall configuration.

Multi-use VPN servers

Due to the way in which routes are created on VPN remote access clients, it is possible for the VPN client to send some unencrypted traffic to the VPN server rather than through the encrypted tunnel of the VPN connection. For example, the VPN client might connect to other services running on the VPN server without routing traffic across the VPN connection. Only traffic that is destined to the public IP address of the VPN server is sent in the clear. If traffic from the client uses the internal or private interface IP address of the VPN server, however, it will be encrypted.

When a remote access VPN client creates a VPN connection with a VPN server, it creates a series of routes in the IP routing table on the VPN client:

  • Default route that uses the VPN connection

    The new default route for the VPN connection effectively replaces the existing default route for the duration of the connection. After the connection is made, all traffic that does not match an address on the directly connected network or the address of the VPN server is sent in an encrypted form over the VPN connection.

  • Host route to the VPN server that uses the local network connection

    The host route for the address of the VPN server is created so that the VPN server is reachable using the locally attached network. If the host route is not present, VPN traffic to the VPN server cannot be sent.

The result of having the host route for the VPN server is that all traffic that is sent to applications running on the VPN server is not sent across the VPN connection, but is instead sent in an unencrypted form across the network between the VPN client and VPN server.

For example, when a remote access VPN client creates a VPN connection with a VPN server and then accesses a shared file on the VPN server computer, that traffic is not sent using the VPN connection. The file sharing traffic is sent in plaintext over the network between the VPN client and VPN server.

Additionally, if packet filters are configured on the VPN server that only allow VPN connection traffic, all other traffic sent to the VPN server is discarded. In this situation, all attempts to connect to services running on the VPN server will fail because traffic attempting to connect to those services are not sent over the VPN connection.

The key to which address is used by the VPN client to access services running on the VPN server lies in the way that the name of the VPN server is resolved. Typical users and applications refer to network resources using names, rather than IP addresses. The name must be resolved to an IP address using either DNS or WINS. If the intranet DNS and WINS infrastructures never contain a record mapping the name of the VPN server to the public IP address of the VPN server, traffic to services running on the VPN server is always sent across the VPN connection.

To prevent the VPN server from dynamically registering the public IP address of its Internet interface in the intranet DNS, obtain properties of the Internet Protocol (TCP/IP) component of the Internet connection in the Network Connections folder. Click Advanced. In the Advanced TCP/IP Settings dialog box, click the DNS tab, and then clear the Register this connection's addresses in DNS check box.

To prevent the VPN server from registering the public IP address of its Internet interface with intranet WINS servers, obtain properties of the Internet Protocol (TCP/IP) component of the Internet connection in the Network Connections folder. Click Advanced. In the Advanced TCP/IP Settings dialog box, click the WINS tab, and then click Disable NetBIOS over TCP/IP.

Before the VPN connection is made, the VPN client uses the Internet DNS infrastructure to resolve the name of the VPN server computer to its public IP addresses. After the VPN connection is made, assuming that intranet DNS and WINS servers are configured either during the PPP connection process or through the relaying of the DHCPInform message, the VPN client uses the intranet DNS and WINS infrastructures to resolve the name of the VPN server computer to its intranet IP addresses.

Preventing traffic routed through remote access clients

Once a remote access client successfully establishes a PPTP or L2TP connection, by default any packet sent over the connection is received by the VPN server and forwarded. Packets sent over the connection can include:

  • Packets originated from the remote access client computer.

  • Packets sent to the remote access client computer by other computers.

When the remote access client computer makes the VPN connection, by default it creates a default route so that all traffic that matches the default route is sent over the VPN connection. If other computers are forwarding traffic to the remote access VPN client, treating the remote access client computer as a router, then that traffic may also be forwarded across the VPN connection. This is a security problem because the computer that is sending traffic to the remote access VPN client has not been authenticated by the VPN server. The computer sending traffic to the remote access VPN client computer has physical network access to the same resources as the authenticated remote access VPN client computer.

To prevent the VPN server from sending traffic across the VPN connection for computers other than authenticated remote access VPN client computers, configure the following remote access policy packet filters on the remote access policy that is used for your VPN connections:

  • From client filter:

    Filter action set to Deny all traffic except those listed below.

    IP Packet Filter Field Setting

    Source Address

    User's address

    Source Network Mask

    User's mask

    Destination Address

    Any

    Destination Network Mask

    Any

    Protocol

    Any

  • To client filter:

    Filter action set to Deny all traffic except those listed below.

    IP Packet Filter Field Setting

    Source Address

    Any

    Source Network Mask

    Any

    Destination Address

    User's address

    Destination Network Mask

    User's mask

    Protocol

    Any

This set of IP packet filters will cause the VPN server to discard all traffic sent across the VPN connection except those that either originated from or is sent to authenticated remote access VPN clients.

Remote access policy profile packet filtering

To define the specific types of IP traffic that are allowed for remote access VPN connections, you need to configure IP packet filters on the profile for the remote access policy that is used for your remote access VPN connections. With profile packet filters, you can configure the IP traffic that is allowed from remote access clients (From client filters) or to remote access clients (To client filters) on an exception basis: either all traffic except traffic specified by filters or no traffic except traffic specified by filters. Remote access policy profile filtering applies to all remote access connections that match the remote access policy. For more information, see Elements of a remote access policy and Configure IP options.