Partager via

New features for virtual private networks

  • Article

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

New features for virtual private networks

The Microsoft® Windows® Server 2003 family provides the following new features for virtual private networks (VPNs):

  • Network address translation (NAT) transparency

    VPN servers running Windows Server 2003 support Layer Two Tunneling Protocol over Internet Protocol security (L2TP/IPSec) traffic that originates from VPN clients behind NATs. For this feature to function properly, the client computer must support the following IPSec Protocol Working Group Internet drafts:

    • Negotiation of NAT-Traversal in the IKE (draft-ietf-ipsec-nat-t-ike-02.txt).

    • UDP Encapsulation of IPsec Packets (draft-ietf-ipsec-udp-encaps-02.txt).

Important

  • An IPSec NAT-T deployment for Windows that includes VPN servers that are located behind network address translators is not recommended. When a server is behind a network address translator, and the server uses IPSec NAT-T, unintended behavior might occur because of the way network address translators translate network traffic.

  • VPN deployment with Network Load Balancing

    VPN servers running Windows Server 2003 support VPN deployment in conjunction with Network Load Balancing to create high-availability VPN solutions. Support is included for Point-to-Point Tunneling Protocol (PPTP) and L2TP/IPSec VPN solutions with Network Load Balancing.

  • NetBIOS over TCP/IP (NetBT) name resolution proxy

    When a remote access VPN client connects to a VPN server, it relies on DNS or WINS servers on the target network for name resolution.

    DNS and WINS servers are common in organizations that use DNS for host name resolution or WINS for NetBIOS name resolution. However, in a small office or home office environment, these servers might not be present. In this case, the names of the computers to which communications are attempted need to be resolved by another means for successful communication to occur.

    NetBIOS names can be resolved, without the use of a WINS or DNS server, by a VPN server running Windows Server 2003 because Windows Server 2003 operating systems include the NetBT proxy. With NetBT proxy, connected VPN clients and the nodes on network segments to which the VPN server is attached can resolve each other's NetBIOS names, as follows:

    1. When a VPN client needs to resolve a name to an IP address without a configured DNS or WINS server, it sends a NetBIOS Name Query packet to the VPN server. When a node on a network segment that is attached to the VPN server needs to resolve a name to an IP address without a configured DNS or WINS server, it sends a NetBIOS Name Query packet as a broadcast on the network segment.

    2. The VPN server receives the NetBIOS Name Query packet, checks its local cache of resolved NetBIOS names and, if the name is not found, forwards the NetBIOS Name Query as a NetBIOS broadcast on all attached interfaces, except the logical interface that is connected to all VPN clients.

    3. The node that has registered the NetBIOS name sends a positive NetBIOS Name Query Response to the VPN server.

    4. The VPN server receives the positive NetBIOS Name Query Response and then forwards it on the interface from which the NetBIOS Name Query packet originated to the sending node.

    The result is that network nodes on network segments that are attached to the VPN server (and all connected VPN clients) can automatically resolve each other's names without a DNS or WINS server.

  • Preshared key configuration for L2TP connections

    The Windows Server 2003 family supports both computer certificates and a preshared key as authentication methods to establish an IPSec security association for L2TP connections. 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 recommended that you use preshared key authentication only while your public key infrastructure (PKI) is being deployed to obtain computer certificates or when a preshared key is required by VPN clients. You can enable the use of a preshared key for L2TP connections and specify the preshared key from the Security tab on the properties of a server running Routing and Remote Access. For more information, see View properties of the remote access server.

    Preshared key authentication is also supported by remote access VPN clients running Windows XP. You can enable preshared key authentication and configure a preshared key from IPSec settings on the Security tab on the properties of a VPN connection in Network Connections. For more information, see Configure a pre-shared key on a remote access client.

    Preshared key authentication is also supported for site-to-site VPN connections between computers running a Windows Server 2003 operating system. You can enable preshared key authentication and configure a preshared key for demand-dial interfaces from IPSec settings on the Security tab on the properties of a demand-dial interface in Routing and Remote Access. For more information, see Configure a pre-shared key for a demand-dial routing interface and Configure a pre-shared key on a remote access server.

The following features for virtual private networks were new in Windows 2000:

  • L2TP

    In addition to PPTP, the the Windows Server 2003 family includes the industry standard L2TP, which is used in conjunction with IPSec to create secure virtual private network connections. The use of L2TP and IPSec is referred to as L2TP/IPSec.

  • Remote access policies

    Remote access policies are a set of conditions and connection settings that allow network administrators more flexibility in setting remote access permissions and connection restraints. With remote access policies, you can force the use of strong authentication and encryption for VPN users and use a different set of authentication and encryption constraints for dial-up users.

    For more information, see Remote Access Policies.

  • MS-CHAP version 2

    Microsoft Challenge Handshake Authentication Protocol (MS-CHAP) version 2 significantly strengthens the security for the passing of security credentials and the generation of encryption keys during the negotiation of a remote access connection. MS-CHAP version 2 was specifically designed for authenticating VPN connections.

    For more information, see MS-CHAP version 2.

  • Extensible Authentication Protocol

    Extensible Authentication Protocol (EAP) allows new authentication methods to be used, a feature that is especially important for the deployment of security based on smart cards. EAP is an architecture that allows other authentication modules to plug into PPP in Windows 2000, Windows XP, and products in the Windows Server 2003 family. Both EAP-MD5 CHAP and EAP-TLS (used for smart card and certificate-based authentication) are supported. You can configure your VPN server to handle authentication, or the VPN server can be configured to forward authentication requests to RADIUS servers.

    For more information, see EAP and Internet Authentication Service.

  • Remote access account lockout

    Remote access account lockout is a security feature that denies access after a configured number of failed authentication attempts. Remote access account lockout is designed to help prevent dictionary attacks. A dictionary attack occurs when an unauthorized user attempts to log on by using a known user name and a list of common words as the password. Remote access account lockout is disabled by default.

    For more information, see Remote access account lockout.