Operation of L2TP Voluntary/Client-Initiated Tunnel Mode
Operation of L2TP Voluntary Client Initiated Tunnel Mode
Voluntary tunnel mode can be implemented in one of two basic configurations:
- L2TP with PPP user authentication (without IPsec protection) In this case, users are authenticated by the LNS using PPP authentication protocols such as Password Authentication Protocol (PAP) and Challenge Handshake Authentication Protocol (CHAP, Data traffic transported over the L2TP tunnel is not encrypted (unless MPPE is negotiated for PPP payload encryption), and so communication is vulnerable to packet-capture tools such as network sniffers.
Figure 8-2 illustrates L2TP with PPP user authentication (without IPsec protection).
Figure 8-2. L2TP with PPP User Authentication (Without IPsec Protection)
In Figure 8-2, remote access user john@mjlnet.com connects to a VPN gateway (LNS) over an L2TP tunnel without IPsec protection. Security consists of only PPP authentication of the user himself (there is no authentication of the machine the user uses to connect to the VPN gateway).
- L2TP over IPsec (L2TP/IPsec) with PPP user authentication In this case, IPsec can be used to both authenticate and encrypt L2TP tunnel traffic. Users connecting to the LNS over the tunnel are authenticated using PPP authentication protocols such as PAP and CHAP. This option is considered to be (depending on the specific configuration of IPsec) much more secure than L2TP without IPsec.
Figure 8-3 shows L2TP over IPsec (L2TP/IPsec) with PPP user authentication.
Figure 8-3. L2TP over IPsec with PPP User Authentication
When remote access user john@mjlnet.com connects to the VPN gateway (LNS) over an IPsec-protected L2TP tunnel (L2TP/IPsec), the machine that the user is using is authenticated using preshared keys or digital signatures (digital certificates) during IKE (phase 1) negotiation, and user john@mjlnet.com himself is authenticated during PPP negotiation (PPP authentication).
Even when using L2TP/IPsec, it is important to ensure that users themselves are authenticated in addition to the machine that they are using. This is because if the user is not authenticated, someone who steals a VPN user's machine could easily establish connectivity to a VPN gateway.
L2TPv2 Message Formats and Message Types
To understand L2TP tunnel setup, it is important to understand the L2TP message format and message types. Figure 8-4 shows the L2TPv2 message header format.
Figure 8-4. L2TPv2 Message Header Format
The fields in the L2TPv2 message header have the following functions:
- The Type (T) bit indicates the type of L2TPv2 message0=data message, and 1=control message. Data session messages carry user data (PPP frames) and control messages are used to set up, maintain, and tear down the L2TP tunnel or session.
- The Length (L) bit indicates whether the Length field is present in this L2TPv2 message header. The L bit must be set to 1 (and the Length field must be present) for control messages.
- The Sequence (S) bit dictates whether the Next Sent (Ns) and Next Received (Nr) fields are present in this L2TPv2 message header.
- The Offset (O) is used to specify whether the Offset Size field is present (1=Offset Size field is present). The O bit must be set to 0, and the Offset field must not be present for control messages.
- The Priority (P) bit specifies whether this L2TPv2 message should be prioritized. When this bit is set to 1, the L2TPv2 message should be prioritized.
- The Version (Ver) field indicates the version of L2TP. This must be set to 2 to indicate L2TPv2.
- The Length field, if present, specifies the total length of the L2TPv2 message in octets.
- The Tunnel ID is a unique, locally significant identifier of a tunnel or control connection between L2TPv2 peers (a LAC and an LNS).
- The Session ID is a unique, locally significant identifier for a data session between L2TPv2 peers (a LAC and an LNS). A data session carries user data (PPP frames).
Note that in voluntary tunnel mode there is one data session (PPP connection) per tunnel; in compulsory tunnel mode, however, there are usually many data sessions per L2TPv2 tunnel.
- The Ns and Nr fields, if present, carry the packet sequencing information.
- The Offset Size field, if present, dictates the number of octets in the Offset Pad.
- The Offset Pad field is used to pad the L2TPv2 message up to the beginning of the L2TPv2 message payload.
Figure 8-5 shows the overall format of L2TPv2 messages.
Figure 8-5. Overall Format of L2TPv2 Messages
As shown in Figure 8-5, the overall L2TPv2 message format consists of an IP header, followed by a UDP header (with its destination port set to be 1701), followed by the L2TPv2 message header (shown in Figure 8-4) and a payload. If this is a data message (T bit=0), the payload contains a PPP frame. If this is a control message (T bit=1), the payload contains a number of AVPs, which indicate the specific type of control message, as well as carrying other information relevant to the control message.
Note that one type of L2TPv2 message, called a Zero-Length-Body Ack (ZLB Ack), does not include a payload.
Now that you know how L2TPv2 messages are constructed, it is time to take a look at specific L2TPv2 control message types as described in Table 8-1.
|
Message Type Value |
Message |
Description |
|---|---|---|
|
1 |
Start-Control-Connection-Request (SCCRQ) |
Initiates control connection establishment |
|
2 |
Start-Control-Connection-Reply (SCCRP) |
Control connection establishment |
|
3 |
Start-Control-Connection-Connected (SCCCN) |
Completes control connection establishment |
|
4 |
Stop-Control-Connection-Notification (StopCCN) |
Control connection teardown |
|
5 |
(Reserved) |
(Reserved) |
|
6 |
Hello (HELLO) |
Control connection keepalive |
|
7 |
Outgoing-Call-Request (OCRQ) |
Initiates data session establishment (outgoing call) |
|
8 |
Outgoing-Call-Reply (OCRP) |
Data session establishment (outgoing call) |
|
9 |
Outgoing-Call-Connected (OCCN) |
Completes data session (outgoing call) |
|
10 |
Incoming-Call-Request (ICRQ) |
Initiates data session establishment (incoming call) |
|
11 |
Incoming-Call-Reply (ICRP) |
Data session establishment (incoming call) |
|
12 |
Incoming-Call-Connected (ICCN) |
Completes data session (incoming call) |
|
13 |
(Reserved) |
(Reserved) |
|
14 |
Call-Disconnect-Notify (CDN) |
Data session teardown |
|
15 |
WAN-Error-Notify (WEN) |
Error reporting |
|
16 |
Set-Link-Info |
PPP session control |
L2TP/IPsec Remote Access VPN Setup (Voluntary/Client-Initiated Tunnel Mode)
Figure 8-6 shows how L2TP/IPsec remote access VPNs are set up.
Figure 8-6. L2TP/IPsec Remote Access VPN Setup
In Figure 8-6, you can see that the first stage in the setup of an L2TP/IPsec remote access VPN is the negotiation of IKE between the remote access client and the VPN gateway (Steps 1 and 2). Internet Key Exchange (IKE) is used to negotiate cryptographic parameters and algorithms, exchange keying material, and authenticate IPsec peers. For more information on IKE, see Chapter 6, "Deploying Site-to-Site IPsec VPNs."
Note
Obviously, if IPsec is not configured to protect the L2TP tunnel, IKE negotiation (Steps 1 and 2 in Figure 8-6) does not take place.
Note that Windows L2TP/IPsec clients initiate IKEv1 main mode (rather than aggressive mode) phase 1 negotiation, followed by phase 2 quick mode negotiation.
After IKE negotiation has completed successfully, L2TP tunnel setup begins (Step 3). This consists of the exchange of SCCRQ, SCCRP, and SCCCN messages (see Table 8-1).
Following L2TP tunnel setup is L2TP session setup (Step 4). This comprises the exchange of ICRQ, ICRP, and ICCN messages.
Finally, PPP negotiation takes place (Steps 5, 6, and 7). PPP negotiation begins with Link Control Protocol (LCP) negotiation, followed by PPP authentication, and then Network Control Protocol (NCP) negotiation.
LCP is used to negotiate link parameters such as Maximum Receive Unit (MRU), compression, and authentication protocol. PPP authentication is used to authenticate the remote access user (rather than the machine, which is authenticated during IKE negotiation).
During NCP negotiation, network protocols, and any parameters associated with network protocols can be negotiated. The most commonly negotiated NCP is the IP Control Protocol (IPCP), which facilitates the negotiation of IP transport over PPP as well as associated parameters such as IP addresses, IP compression, and DNS/WINS server addresses.
Okay, so that's the theory. Now it is time to take a look at L2TP/IPsec remote access VPN setup in practiceas demonstrated in Examples 8-1 to 8-3 from a VPN gateway's perspective. Note that only the relevant portion of the command output is shown.
Example 8-1. L2TP/IPsec Remote Access VPN Setup: IKE Negotiation (Steps 1 and 2 in Figure 8-6)
|
mjlnet.VPN.Gateway.03#debug crypto isakmp Crypto ISAKMP debugging is on mjlnet.VPN.Gateway.03#debug vpdn l2x-events L2X protocol events debugging is on mjlnet.VPN.Gateway.03#debug ppp negotiation PPP protocol negotiation debugging is on mjlnet.VPN.Gateway.03# *Jun 5 19:49:06.291: ISAKMP (0:0): received packet from 192.168.1.1 dport 500 sport 500 Global (N) NEW SA *Jun 5 19:49:06.291: ISAKMP:(0:0:N/A:0):Input = IKE_MESG_FROM_PEER, IKE_MM_EXCH *Jun 5 19:49:06.291: ISAKMP:(0:0:N/A:0):Old State = IKE_READY New State = IKE_R_MM1 (line 1) *Jun 5 19:49:06.291: ISAKMP:(0:0:N/A:0): processing SA payload. message ID = 0 *Jun 5 19:49:06.291: ISAKMP:(0:0:N/A:0): processing vendor id payload *Jun 5 19:49:06.291: ISAKMP:(0:0:N/A:0): vendor ID seems Unity/DPD but major 228 mismatch *Jun 5 19:49:06.291: ISAKMP:(0:0:N/A:0): processing vendor id payload *Jun 5 19:49:06.291: ISAKMP:(0:0:N/A:0): vendor ID seems Unity/DPD but major 194 mismatch *Jun 5 19:49:06.291: ISAKMP:(0:0:N/A:0): processing vendor id payload *Jun 5 19:49:06.291: ISAKMP:(0:0:N/A:0): vendor ID seems Unity/DPD but major 123 mismatch *Jun 5 19:49:06.291: ISAKMP:(0:0:N/A:0): vendor ID is NAT-T v2 *Jun 5 19:49:06.291: ISAKMP:(0:0:N/A:0): processing vendor id payload *Jun 5 19:49:06.291: ISAKMP:(0:0:N/A:0): vendor ID seems Unity/DPD but major 184 mismatch *Jun 5 19:49:06.291: ISAKMP: Looking for a matching key for 192.168.1.1 in default : success *Jun 5 19:49:06.291: ISAKMP:(0:0:N/A:0):found peer pre-shared key matching 192.168.1.1 *Jun 5 19:49:06.291: ISAKMP:(0:0:N/A:0): local preshared key found *Jun 5 19:49:06.295: ISAKMP:(0:0:N/A:0):Checking ISAKMP transform 4 against priority 1 policy *Jun 5 19:49:06.295: ISAKMP: encryption DES-CBC *Jun 5 19:49:06.295: ISAKMP: hash SHA *Jun 5 19:49:06.295: ISAKMP: default group 1 *Jun 5 19:49:06.295: ISAKMP: auth pre-share *Jun 5 19:49:06.295: ISAKMP: life type in seconds *Jun 5 19:49:06.295: ISAKMP: life duration (VPI) of 0x0 0x0 0x70 0x80 *Jun 5 19:49:06.295: ISAKMP:(0:0:N/A:0):atts are acceptable. Next payload is 3 *Jun 5 19:49:06.323: ISAKMP:(0:1:SW:1): sending packet to 192.168.1.1 my_port 500 peer_port 500 (R) MM_SA_SETUP *Jun 5 19:49:06.323: ISAKMP:(0:1:SW:1):Input = IKE_MESG_INTERNAL, IKE_PROCESS_COMPLETE *Jun 5 19:49:06.323: ISAKMP:(0:1:SW:1):Old State = IKE_R_MM1 New State = IKE_R_MM2 (line 2) *Jun 5 19:49:06.371: ISAKMP (0:134217729): received packet from 192.168.1.1 dport 500 sport 500 Global (R) MM_SA_SETUP *Jun 5 19:49:06.371: ISAKMP:(0:1:SW:1):Input = IKE_MESG_FROM_PEER, IKE_MM_EXCH *Jun 5 19:49:06.371: ISAKMP:(0:1:SW:1):Old State = IKE_R_MM2 New State = IKE_R_MM3 (line 3) *Jun 5 19:49:06.371: ISAKMP:(0:1:SW:1): processing KE payload. message ID = 0 *Jun 5 19:49:06.403: ISAKMP:(0:1:SW:1): processing NONCE payload. message ID = 0 *Jun 5 19:49:06.403: ISAKMP: Looking for a matching key for 192.168.1.1 in default : success *Jun 5 19:49:06.403: ISAKMP:(0:1:SW:1):found peer pre-shared key matching 192.168.1.1 *Jun 5 19:49:06.407: ISAKMP:(0:1:SW:1):SKEYID state generated *Jun 5 19:49:06.407: ISAKMP:received payload type 17 *Jun 5 19:49:06.407: ISAKMP:received payload type 17 *Jun 5 19:49:06.407: ISAKMP:(0:1:SW:1):Input = IKE_MESG_INTERNAL, IKE_PROCESS_MAIN_MODE *Jun 5 19:49:06.407: ISAKMP:(0:1:SW:1):Old State = IKE_R_MM3 New State = IKE_R_MM3 *Jun 5 19:49:06.407: ISAKMP:(0:1:SW:1): sending packet to 192.168.1.1 my_port 500 peer_port 500 (R) MM_KEY_EXCH *Jun 5 19:49:06.407: ISAKMP:(0:1:SW:1):Input = IKE_MESG_INTERNAL, IKE_PROCESS_COMPLETE *Jun 5 19:49:06.407: ISAKMP:(0:1:SW:1):Old State = IKE_R_MM3 New State = IKE_R_MM4 (line 4) *Jun 5 19:49:06.423: ISAKMP (0:134217729): received packet from 192.168.1.1 dport 500 sport 500 Global (R) MM_KEY_EXCH *Jun 5 19:49:06.423: ISAKMP:(0:1:SW:1):Input = IKE_MESG_FROM_PEER, IKE_MM_EXCH *Jun 5 19:49:06.423: ISAKMP:(0:1:SW:1):Old State = IKE_R_MM4 New State = IKE_R_MM5 (line 5) *Jun 5 19:49:06.423: ISAKMP:(0:1:SW:1): processing ID payload. message ID = 0 *Jun 5 19:49:06.423: ISAKMP (0:134217729): ID payload next-payload : 8 type : 1 address : 192.168.1.1 protocol : 0 port : 0 length : 12 *Jun 5 19:49:06.423: ISAKMP:(0:1:SW:1):: peer matches *none* of the profiles *Jun 5 19:49:06.423: ISAKMP:(0:1:SW:1): processing HASH payload. message ID = 0 *Jun 5 19:49:06.423: ISAKMP:(0:1:SW:1):SA authentication status: authenticated *Jun 5 19:49:06.423: ISAKMP:(0:1:SW:1):SA has been authenticated with 192.168.1.1 *Jun 5 19:49:06.423: ISAKMP: Trying to insert a peer 10.40.10.1/192.168.1.1/500/, and inserted successfully. *Jun 5 19:49:06.423: ISAKMP:(0:1:SW:1):Input = IKE_MESG_INTERNAL, IKE_PROCESS_MAIN_MODE *Jun 5 19:49:06.423: ISAKMP:(0:1:SW:1):Old State = IKE_R_MM5 New State = IKE_R_MM5 *Jun 5 19:49:06.423: ISAKMP:(0:1:SW:1):SA is doing pre-shared key authentication using id type ID_IPV4_ADDR *Jun 5 19:49:06.423: ISAKMP (0:134217729): ID payload next-payload : 8 type : 1 address : 10.40.10.1 protocol : 17 port : 500 length : 12 *Jun 5 19:49:06.423: ISAKMP:(0:1:SW:1):Total payload length: 12 *Jun 5 19:49:06.427: ISAKMP:(0:1:SW:1): sending packet to 192.168.1.1 my_port 500 peer_port 500 (R) MM_KEY_EXCH *Jun 5 19:49:06.427: ISAKMP:(0:1:SW:1):Input = IKE_MESG_INTERNAL, IKE_PROCESS_COMPLETE *Jun 5 19:49:06.427: ISAKMP:(0:1:SW:1):Old State = IKE_R_MM5 New State = IKE_P1_COMPLETE (line 6) *Jun 5 19:49:06.427: ISAKMP:(0:1:SW:1):Input = IKE_MESG_INTERNAL, IKE_PHASE1_COMPLETE *Jun 5 19:49:06.427: ISAKMP:(0:1:SW:1):Old State = IKE_P1_COMPLETE New State = IKE_P1_COMPLETE (line 7) *Jun 5 19:49:06.451: ISAKMP (0:134217729): received packet from 192.168.1.1 dport 500 sport 500 Global (R) QM_IDLE *Jun 5 19:49:06.451: ISAKMP: set new node -1715998770 to QM_IDLE (line 7) *Jun 5 19:49:06.451: ISAKMP:(0:1:SW:1): processing HASH payload. message ID = - 1715998770 *Jun 5 19:49:06.451: ISAKMP:(0:1:SW:1): processing SA payload. message ID = - 1715998770 *Jun 5 19:49:06.451: ISAKMP:(0:1:SW:1):Checking IPSec proposal 1 *Jun 5 19:49:06.451: ISAKMP: transform 1, ESP_3DES *Jun 5 19:49:06.451: ISAKMP: attributes in transform: *Jun 5 19:49:06.451: ISAKMP: SA life type in seconds *Jun 5 19:49:06.451: ISAKMP: SA life duration (VPI) of 0x0 0x0 0xE 0x10 *Jun 5 19:49:06.451: ISAKMP: SA life type in kilobytes *Jun 5 19:49:06.451: ISAKMP: SA life duration (VPI) of 0x0 0x3 0xD0 0x90 *Jun 5 19:49:06.451: ISAKMP: encaps is 2 (Transport) *Jun 5 19:49:06.455: ISAKMP: authenticator is HMAC-MD5 *Jun 5 19:49:06.455: ISAKMP:(0:1:SW:1):atts are acceptable. *Jun 5 19:49:06.707: ISAKMP:(0:1:SW:1): Creating IPSec SAs *Jun 5 19:49:06.707: inbound SA from 192.168.1.1 to 10.40.10.1 (f/i) 0/0 (proxy 192.168.1.1 to 10.40.10.1) *Jun 5 19:49:06.707: has spi 0xCAB64693 and conn_id 2000 and flags 4 *Jun 5 19:49:06.707: lifetime of 3600 seconds *Jun 5 19:49:06.707: lifetime of 250000 kilobytes *Jun 5 19:49:06.707: has client flags 0x0 *Jun 5 19:49:06.707: outbound SA from 10.40.10.1 to 192.168.1.1 (f/i) 0/0 (proxy 10.40.10.1 to 192.168.1.1) *Jun 5 19:49:06.707: has spi -1967707474 and conn_id 2001 and flags C *Jun 5 19:49:06.707: lifetime of 3600 seconds *Jun 5 19:49:06.707: lifetime of 250000 kilobytes *Jun 5 19:49:06.707: has client flags 0x0 *Jun 5 19:49:06.707: ISAKMP:(0:1:SW:1): sending packet to 192.168.1.1 my_port 500 peer_port 500 (R) QM_IDLE *Jun 5 19:49:06.707: ISAKMP:(0:1:SW:1):Node -1715998770, Input = IKE_MESG_FROM_IPSEC, IKE_SPI_REPLY *Jun 5 19:49:06.707: ISAKMP:(0:1:SW:1):Old State = IKE_QM_SPI_STARVE New State = IKE_QM_R_QM2 (line 8) *Jun 5 19:49:06.715: ISAKMP (0:134217729): received packet from 192.168.1.1 dport 500 sport 500 Global (R) QM_IDLE *Jun 5 19:49:06.715: ISAKMP:(0:1:SW:1):deleting node -1715998770 error FALSE reason "QM done (await)" *Jun 5 19:49:06.715: ISAKMP:(0:1:SW:1):Node -1715998770, Input = IKE_MESG_FROM_PEER, IKE_QM_EXCH *Jun 5 19:49:06.715: ISAKMP:(0:1:SW:1):Old State = IKE_QM_R_QM2 New State = IKE_QM_PHASE2_COMPLETE (line 9) |
Highlighted lines 1 and 2 indicate that the remote access VPN client and the VPN gateway have exchanged the first two messages in the IKE main mode exchange (states MM1 and MM2). The purpose of these two messages is to agree on an IKE policy (cryptographic parameters and algorithms).
Now that an IKE policy has been negotiated, the remote access VPN client and VPN gateway exchange the third and fourth messages in the IKE main mode exchange (indicated by the MM3 and MM4 states in highlighted lines 3 and 4). These messages are used to exchange keying material.
Highlighted lines 5 and 6 indicate that the fifth and sixth main mode messages have been exchanged (states MM5 and MM6). These messages are used to authenticate the IPsec peers. Note that during the exchange of messages 5 and 6, the remote access VPN client machine (but not the user of the machine) is authenticated by the VPN gateway (and vice versa).
Highlighted line 7 shows that IKE phase 1 is complete. IKE phase 2 (quick mode) is about to begin.
Highlighted lines 8, 9, and 10 indicate that the remote access VPN client and VPN gateway have exchanged three quick mode (IKE phase 2) messages. During this quick mode exchange, the peers negotiate the IPsec policy (cryptographic parameters and algorithms) that will be used to protect L2TP.
L2TPv2 tunnel and session setup (Steps 3 and 4 in Figure 8-6) can begin (see Example 8-2).
Example 8-2. L2TP/IPsec Remote Access VPN Setup: L2TP Tunnel and Session Setup (Steps 3 and 4 in Figure 8-6)
|
*Jun 5 19:49:06.731: L2TP: I SCCRQ from markxp1 tnl 3 (line 1) *Jun 5 19:49:06.731: Tnl 12726 L2TP: Tunnel Authorization started for host markxp1 *Jun 5 19:49:06.731: Tnl 12726 L2TP: New tunnel created for remote markxp1, address 192.168.1.1 *Jun 5 19:49:06.731: L2X: Requested security for socket, UDP socket info: local 10.40.10.1(1701), remote 192.168.1.1(1701) *Jun 5 19:49:06.731: Tnl 12726 L2TP: O SCCRP to markxp1 tnlid 3 (line 2) *Jun 5 19:49:06.731: Tnl 12726 L2TP: Control channel retransmit delay set to 1 seconds *Jun 5 19:49:06.735: Tnl 12726 L2TP: Tunnel state change from idle to wait-ctl-reply *Jun 5 19:49:06.735: Tnl 12726 L2TP: Socket MTU changed to 1462 *Jun 5 19:49:06.735: Tnl 12726 L2TP: Secure socket up event *Jun 5 19:49:06.743: Tnl 12726 L2TP: I SCCCN from markxp1 tnl 3 (line 3) *Jun 5 19:49:06.743: Tnl 12726 L2TP: Tunnel state change from wait-ctl-reply to established *Jun 5 19:49:06.743: Tnl 12726 L2TP: SM State established *Jun 5 19:49:06.743: Tnl 12726 L2TP: I ICRQ from markxp1 tnl 3 (line 4) *Jun 5 19:49:06.743: Tnl/Sn 12726/3 L2TP: Session state change from idle to wait-connect *Jun 5 19:49:06.743: Tnl/Sn 12726/3 L2TP: Accepted ICRQ, new session created *Jun 5 19:49:06.743: uid:2 Tnl/Sn 12726/3 L2TP: O ICRP to markxp1 3/1 (line 5) *Jun 5 19:49:06.743: Tnl 12726 L2TP: Control channel retransmit delay set to 1 seconds *Jun 5 19:49:06.767: uid:2 Tnl/Sn 12726/3 L2TP: I ICCN from markxp1 tnl 3, cl 1 (line 6) *Jun 5 19:49:06.767: uid:2 Tnl/Sn 12726/3 L2TP: Session state change from wait-connect to wait-for-service-selection-iccn |
Highlighted lines 1 to 3 show the exchange of SCCRQ, SCCRP, and SCCCN messages between the remote access VPN client and the VPN gateway. L2TPv2 control connection establishment has been completed.
By the way, you might notice the machine name (as distinct from the username) of the remote access VPN client in the highlighted lines (markxp1).
ICRQ, ICRP, and ICCN messages are then exchanged in highlighted lines 4 to 6. These messages comprise L2TPv2 session setup.
The L2TPv2 tunnel and session have now both been established, and in Example 8-3, PPP negotiation between the remote access VPN client and the VPN gateway begins (Steps 5 to 7 in Figure 8-6).
Example 8-3. L2TP/IPsec Remote Access VPN Setup: PPP Negotiation (Steps 5 to 7 in Figure 8-6)
|
*Jun 5 19:49:06.767: ppp2 PPP: Using vpn set call direction *Jun 5 19:49:06.767: ppp2 PPP: Treating connection as a callin *Jun 5 19:49:06.767: ppp2 PPP: Phase is ESTABLISHING, Passive Open (line 1) *Jun 5 19:49:06.767: ppp2 LCP: State is Listen *Jun 5 19:49:06.895: ppp2 LCP: I CONFREQ [Listen] id 0 len 21 *Jun 5 19:49:06.895: ppp2 LCP: MRU 1400 (0x01040578) *Jun 5 19:49:06.895: ppp2 LCP: MagicNumber 0x1B24034B (0x05061B24034B) *Jun 5 19:49:06.895: ppp2 LCP: PFC (0x0702) *Jun 5 19:49:06.895: ppp2 LCP: ACFC (0x0802) *Jun 5 19:49:06.895: ppp2 LCP: Callback 6 (0x0D0306) *Jun 5 19:49:06.919: ppp2 LCP: State is Open *Jun 5 19:49:06.919: ppp2 PPP: Phase is AUTHENTICATING, by this end (line 2) *Jun 5 19:49:06.919: ppp2 CHAP: O CHALLENGE id 1 len 42 from "mjlnet.VPN.Gateway.03" *Jun 5 19:49:06.923: ppp2 LCP: I IDENTIFY [Open] id 4 len 18 magic 0x1B24034B MSRASV5.10 *Jun 5 19:49:06.927: ppp2 LCP: I IDENTIFY [Open] id 5 len 23 magic 0x1B24034B MSRAS- 0-MARKXP1 *Jun 5 19:49:06.927: ppp2 CHAP: I RESPONSE id 1 len 25 from "mark@mjlnet.com" (line 3) *Jun 5 19:49:06.927: ppp2 PPP: Phase is FORWARDING, Attempting Forward *Jun 5 19:49:06.927: ppp2 PPP: Phase is AUTHENTICATING, Unauthenticated User *Jun 5 19:49:06.931: ppp2 PPP: Phase is FORWARDING, Attempting Forward *Jun 5 19:49:06.931: Vi2.1 Tnl/Sn 12726/3 L2TP: Session state change from wait-for-service-selection-iccn to established *Jun 5 19:49:06.931: Vi2.1 PPP: Phase is AUTHENTICATING, Authenticated User *Jun 5 19:49:06.931: Vi2.1 CHAP: O SUCCESS id 1 len 4 *Jun 5 19:49:06.931: Vi2.1 PPP: Phase is UP (line 4) *Jun 5 19:49:06.931: Vi2.1 IPCP: O CONFREQ [Closed] id 1 len 10 *Jun 5 19:49:06.935: Vi2.1 IPCP: Address 10.40.10.1 (0x03060A0A0A48) *Jun 5 19:49:06.935: Vi2.1 PPP: Process pending ncp packets *Jun 5 19:49:06.959: Vi2.1 CCP: I CONFREQ [Not negotiated] id 6 len 10 *Jun 5 19:49:06.959: Vi2.1 CCP: MS-PPC supported bits 0x01000001 (0x120601000001) *Jun 5 19:49:06.959: Vi2.1 LCP: O PROTREJ [Open] id 2 len 16 protocol CCP (0x80FD0106000A120601000001) *Jun 5 19:49:06.959: Vi2.1 IPCP: I CONFREQ [REQsent] id 7 len 34 *Jun 5 19:49:06.959: Vi2.1 IPCP: Address 0.0.0.0 (0x030600000000) *Jun 5 19:49:06.959: Vi2.1 IPCP: PrimaryDNS 0.0.0.0 (0x810600000000) *Jun 5 19:49:06.963: Vi2.1 IPCP: PrimaryWINS 0.0.0.0 (0x820600000000) *Jun 5 19:49:06.963: Vi2.1 IPCP: SecondaryDNS 0.0.0.0 (0x830600000000) *Jun 5 19:49:06.963: Vi2.1 IPCP: SecondaryWINS 0.0.0.0 (0x840600000000) *Jun 5 19:49:06.963: Vi2.1 AAA/AUTHOR/IPCP: Start. Her address 0.0.0.0, we want 0.0.0.0 *Jun 5 19:49:06.963: Vi2.1 AAA/AUTHOR/IPCP: Done. Her address 0.0.0.0, we want 0.0.0.0 *Jun 5 19:49:06.963: Vi2.1 IPCP: Pool returned 10.20.10.1 *Jun 5 19:49:06.979: Vi2.1 IPCP: State is Open (line 5) *Jun 5 19:49:06.979: Vi2.1 IPCP: Install route to 10.20.10.1 *Jun 5 19:49:06.979: Vi2.1 IPCP: Add link info for cef entry 10.20.10.1 mjlnet.VPN.Gateway.03# |
Highlighted line 1 shows that the PPP phase is ESTABLISHINGLCP negotiation is about to begin. Then, in highlighted line 2, the LCP negotiation is complete, and the PPP phase changes to AUTHENTICATING. PPP authentication is next.
If you take a look at the remote access VPN client's CHAP response in highlighted line 3, you can see the remote access VPN client's username (rather than machine name) is mark@mjlnet.com.
The PPP phase changes to UP in highlighted line 4. This indicates that user authentication has completed successfully, and NCP is ready to start.
Highlighted line 5 shows that the IPCP state has changed to OPENIPCP negotiation has completed successfully, and IP communication can begin between the remote access VPN client and the VPN gateway.
You might be interesting to note the type of remote access VPN client involved in the VPN setup shown in Examples 8-1 to 8-3. There is a hint to its type between highlighted lines 2 and 3 in Example 8-3there is an LCP Identification (IDENTIFY) message, which shows MSRASV5.10. This is a fairly hefty hint, and in fact, the remote access VPN client is a Windows XP workstation.