Export (0) Print
Expand All

Remote access connection setup process

Published: January 15, 2003
On This Page

Step 1: Physical or logical link setup
Step 2: PPP connection setup
Step 3. Remote access client registration

The creation of a remote access connection for either a dial-up or VPN remote access connection occurs in the following three steps:

  1. Physical or logical link setup

    The physical or logical link setup creates the point-to-point link between the remote access client and the remote access server for the purposes of sending PPP protocol suite frames or PPP frames containing data. A physical link is used for a dial-up connection, in which the phone line is the physical link. A logical link is used for VPN connections, in which the VPN tunnel represents a logical point-to-point link. With the Windows 2000 remote access client, the message displayed to the user during the physical or logical link setup is "Connecting."

  2. PPP connection setup

    The PPP connection setup uses the suite of PPP protocols to negotiate the parameters of the PPP link, authenticate the credentials of the remote access user, perform callback, and negotiate the use of and the parameters for the protocols that will be operating over the PPP link. With the Windows 2000 remote access client, the message displayed to the user during the PPP connection setup is "Verifying user name and password."

  3. Remote access client registration

    During the remote access client registration, the remote access client obtains addition configuration parameters and registers itself for name resolution. With the Windows 2000 remote access client, the message displayed to the user during remote access client registration is "Registering your computer on the network."

Step 1: Physical or logical link setup

The process for the physical or logical link setup depends on whether the connection is a dial-up or a VPN connection.

Dial-up connection

For the dial-up connection, the following process occurs:

  1. The user of the remote access client computer initiates the dial-up connection. In Windows 2000, the user double-clicks the connection in the Network and Dial-up Connections folder.

  2. The modem picks up phone line and gets a dial tone.

  3. The modem then dials the phone number of the remote access server.

  4. The remote access server answers the incoming call.

  5. The modems of the remote access client and the remote access server use modem negotiation protocols to determine line speed and other modem communication parameters.

  6. The physical connection is established and the dial-up call is complete.

PPTP

For a PPTP-based VPN connection, the connection is established in the following two phases:

  • Phase 1

    A TCP connection is initiated from the remote access client using a dynamically allocated TCP port to the remote access server using TCP port 1723.

  • Phase 2

    The remote access client and the remote access server exchange a series of PPTP messages to negotiate the use of a PPTP tunnel and a specific call ID to identify the PPTP connection. For more information, see RFC 2637. The result of the negotiation is a call ID that is used when sending PPTP-encapsulated data using the PPTP Generic Routing Encapsulation (GRE) header.

    When the PPTP connection setup begins, the remote access client must already be connected to the Internet. If not, a dial-up connection to an Internet service provider can be made prior to initiating the PPTP connection.

L2TP/IPSec

For an L2TP/IPSec-based VPN connection, the connection is established in the following two phases:

  • Phase 1

    The IPSec security associations needed to protect IPSec-based communications and data are negotiated and created. IPSec uses the Internet Key Exchange (IKE) protocol to negotiate the IKE main mode and quick mode security associations (SAs). The main mode SA is used to protect IPSec negotiations. The quick mode SAs—one for inbound packets and one for outbound packets-are used to protect L2TP data using UDP port 1701. The main mode SA is authenticated using either certificates or a preshared key.

    For certificate authentication, the remote access server sends the remote access client a list of acceptable root certification authorities (CAs) from which a certificate will be accepted for authentication. The remote access client responds with a certificate chain (ending at a root CA certificate for a root CA from the list sent by the remote access server) and its own list of root CAs from which a certificate will be accepted for authentication. The remote access server verifies the certificate chain of the remote access client, and then sends a certificate chain (ending at a root CA certificate for a root CA from the list sent by the remote access client). The remote access client verifies the certificate chain of the remote access server.

    For preshared key authentication, both the remote access client and remote access server send a hash value that incorporates the preshared key. The hash value sent by the remote access client is verified by the remote access server and the hash value sent by the remote access server is verified by the remote access client.

    For more information about main mode and quick mode negotiations, see IKE Negotiation for IPSec Security Associations.

  • Phase 2

    The remote access client and the remote access server exchange a series of L2TP messages to negotiate the use of an L2TP tunnel and a specific call ID to identify a connection within the L2TP tunnel. For more information, see RFC 2661. The result of the negotiation is a tunnel ID and a call ID that is used when sending L2TP-encapsulated data using the L2TP header.

    When the L2TP/IPSec connection setup begins, the remote access client must already be connected to the Internet. If not, a dial-up connection to an Internet service provider can be made prior to initiating the L2TP/IPSec connection.

Step 2: PPP connection setup

The PPP connection process occurs in the following phases:

  1. Link negotiation

  2. Authentication

  3. Callback (dial-up only)

  4. Network protocol negotiation

PPP phase 1: Link negotiation

The remote access client and remote access server exchange the following series of Link Control Protocol (LCP) messages to negotiate the parameters of the PPP links:

  • The authentication protocol to use to verify the credentials of the remote access client, and for mutual authentication protocols, the remote access server, in the authentication phase.

  • The PPP maximum receive unit (MRU), the maximum number of bytes in a PPP frame.

  • Whether to use protocol and address and control field compression.

  • The use of callback.

PPP phase 2: Authentication

The remote access client and remote access server exchange a series of messages for the authentication protocol specified in the link negotiation phase. For PAP, SPAP, CHAP, MS-CHAP, and MS-CHAP v2, a fixed set of messages is exchanged. For EAP, an EAP type is negotiated and then a set of messages corresponding to the EAP type are exchanged. EAP negotiations can have a variable number of messages.

MS-CHAP v2 and EAP-TLS provide mutual authentication, in which the remote access client authenticates itself to the remote access server and the remote access server authenticates itself to the remote access client.

PPP phase 3: Callback (dial-up only)

If negotiated during the link negotiation phase, the dial-up remote access client and the remote access server use the Callback Control Protocol (CBCP) to determine the phone number at which the remote access client is to be called back. Based on the Callback Options settings on the Dial-in tab on the properties of the remote access client user account, either the callback number is specified or the user at the remote access client is either prompted for the callback number. In either case, the following actions occur:

  1. The remote access server hangs up.

  2. The remote access server calls the remote access client back at the determined phone number.

  3. The remote access connection proceeds to the next phase.

PPP phase 4: Network protocol negotiation

After authentication and callback, protocols known as Network Control Protocols (NCPs) are used to negotiate the use of and configuration for network protocols, such as TCP/IP and IPX. The following NCPs are used:

  • Internet Protocol Control Protocol (IPCP)

    Used to negotiate parameters for the TCP/IP protocol, including IP address, the use of IP compression, and the addresses of DNS and WINS servers.

  • IPX Control Protocol (IPXCP)

    Used to negotiate parameters for the IPX protocol, including the IPX network and node numbers.

  • AppleTalk Control Protocol (ATCP)

    Used to negotiate parameters for the AppleTalk protocol, including the AppleTalk network and node numbers.

  • NetBIOS Frames Control Protocol (NBFCP)

    Used to negotiate parameters for the NetBIOS Extended User Interface (NetBEUI) protocol.

  • Bandwidth Allocation Control Protocol (BACP)

    Used to negotiate parameters for the Bandwidth Allocation Protocol (BAP). BAP is used to dynamically add and remove links from a Multilink Protocol (MP) connection based on bandwidth needs. BAP only applies to dial-up connections.

  • Compression Control Protocol (CCP)

    For Microsoft remote access clients and servers, CCP is used to negotiate the use of Microsoft Point-to-Point Compression Protocol (MPPC) and the use of and encryption strength for Microsoft Point-to-Point Encryption (MPPE).

Step 3. Remote access client registration

Registration for remote access clients consists of using a DHCPInform message to obtain additional TCP/IP configuration parameters and performing name registration.

Using a DHCPInform message

The remote access client uses a DHCPInform message using the following process:

  1. The remote access client sends a DHCPInform message on the PPP link to the remote access server.

  2. The remote access server, configured with the DHCP Relay Agent and at least one address of a DHCP server, relays the DHCPInform message to the DHCP server.

  3. The DHCP server sends back a DHCPAck message, which contains the requested options that are configured on the DHCP server.

  4. The remote access server relays the DHCPAck to the remote access client.

The principal use of the DHCPInform message is to obtain TCP/IP configuration parameters that are not obtained using IPCP, such as the domain name assigned to the PPP connection. Only Windows 2000 and Windows XP remote access clients send the DHCPInform message.

Name registration

To allow nodes on the private network to resolve the names of remote access clients while they are connected, the names and IP addresses of the remote access clients must be registered in the DNS and NetBIOS namespaces of the private network. Because a remote access client is typically assigned a different IP address any time they connect, names in the namespaces should be dynamic, rather than static. To achieve dynamic registration of DNS and NetBIOS names for the private network, remote access client name registration consists of the following:

  1. The remote access client sends NetBIOS name registration messages to its configured WINS server to register its NetBIOS names.

  2. The remote access client sends dynamic DNS update messages to its configured DNS server to register its DNS names.

Was this page helpful?
(1500 characters remaining)
Thank you for your feedback
Show:
© 2014 Microsoft