Mentor Technologies is going to be offering the relatively new Cisco CMTD (Configuring, Managing, and Troubleshooting Cisco Dial-Up Services) course. The course is five (5) days of material and labs relating to dialup, using an emulator to simulate both analog and ISDN lines. Joking around, I told someone it stands for "Can't Manage to Dial-Up". At least that somewhat describes the troubleshooting portion of the course!
All of that means that dial-up access has been on my mental horizon. One of the topics I'd been meaning to look into in more depth is the Cisco L2F (Layer 2 Forwarding) technology. About the same time Cisco announced L2F, Microsoft announced PPTP (PPP Tunneling Protocol), which does roughly the same thing, except that the tunnel originates at an end node (PC) vice at the access server. Luckily for us -- the world has enough standards -- Cisco and Microsoft wisely decided to merge the proposed standards, and combined efforts on a fast-track IETF standard, L2TP (Layer 2 Tunneling Protocol). It looks like L2TP is getting pretty close, so it seems like time to take a look.
The intent of L2TP is to allow a user to dial-up one location (the local Internet Service Provider access point) and establish a PPP connection to another location (your company's PPP gateway). Logically, it's as if you'd made a local call and connected via PPP to a remote access server. This is accomplished by tunneling the PPP frames inside IP packets. UDP port 1701, since you asked.
Terminology (jargon): The ISP NAS is the LAC, L2TP Access Concentrator. The company gateway is referred to as the LNS, L2TP Network Server. So you call the LAC and get tunneled to the LNS. And that's called a VPDN, a Virtual Private Dialup Network.
Other means can also be used to connect from the LAC to the LNS: X.25, Frame Relay, or ATM.
Did I say multiprotocol? L2TP does support multiprotocol operation: the PPP tunnel can carry traffic for any protocol supported on top of PPP, and that includes IP, IPX, and AppleTalk.
L2TP (well, L2F) is used behind the scenes for Cisco IOS 11.2's Multichassis Multilink PPP, because the PPP might have gone through different NAS's at the Internet Service Provider (ISP). That can easily happen when you use one number to call any port in a rotary group at the ISP: you have no way to guarantee two calls will end up on the same NAS. The protocol, Stack Group Bidding Protocol, SGBP, is used to determine which router gets to re-assemble packets from the portions sent over the links. Then L2F is used to "project" the traffic to the bidding winner, so that one router can be used to do the packet reassembly.
For authentication, the user goes on using PAP, CHAP, Radius, or TACACS+ just as before. This is done with the corporate NAS, so the company and the ISP don't have to work together as closely to coordinate authorization and access (lower management costs, faster response).
Addressing is done by the corporate NAS, so that the firewall doesn't have to be opened up to addresses within the ISP's address space. In fact, the LNS can be inside the corporate firewall. This simplifies address management for both the corporation and the ISP. Private addressing can also be used.
Accounting can be done by both the ISP and the company.
The company needs only minimal sharing of routing information with the ISP: the ISP needs to be able to route to the LNS. All other routing information is kept internal to the company.
The ISP needs to figure out whether you're a regular customer, and require normal Internet access, or whether you need a VPDN tunnel to a company. To determine this, stuctured addressing (joe@somecorp.com) can be used. Or the ISDN DNIS (Dialer Number Information String) or CLID (Calling Line ID). If structured addressing is used, PAP or CHAP authentication gets the information from the user PC to the ISP.
The ISP next establishes a tunnel connection to the LNS at the company. A message is sent to UDP port 1701, and part of the negotiation is what UDP ports to shift to. The Cisco protocol L2F uses 1701 as well, but with a version number of 1, whereas L2TP uses 2. The tunnel is authenticated: both ends authenticate each other.
If a tunnel already exists between the current NAS and the LNS, a number (Multiplex ID, MID, in the Cisco documentation) is assigned so that multiple PPP sessions can share the same tunnel. This makes L2TP scale to large numbers better.
The tunnel establishment passes along any PPP authentication or LCP information, which the corporate LNS is free to ignore. The intent is to allow for complete transparency, with only one network login required. The ISP gets what it needs in the way of authentication, namely which company to tunnel to, and from there it's the company's problem. The company can use all its usual security and access control mechanisms, just as if the user were dialed directly into the LNS.
Once the user is authenticated, the LNS router creates a virtual interface for the user. The user PC speaks PPP with the LNS virtual interface. The LNS strips off the L2TP tunneling header, and treats what's left as PPP encapsulation on the virtual interface.
Tunnel endpoints may authenticate each other, in both directions. This is thought to be reasonably secure, and should prevent initial snooping.
A weak key is carried in subsequent packets, and a snooper may be able to take over the tunnel.
However, the protocol allows for use of the IPSec standard, for IP packet security.
When used over packet or cell switched networks (Frame Relay, ATM), there should be much lower security risk, so there is currently no provision for encrypted L2TP in such settings.
To obtain additional security, perform both compression and encryption at the PPP layer.
The client PC is "johndoe". The ISP NAS (LAC) is "isp1", and the corporate gateway (LNS) is "corp-gw", with corporate domain "bigcorp.com".
Name of NAS for CHAP: corp-gw
NAS CHAP password (secret): personalsecret
That is, the PC is set up to authenticate itself to corp-gw as johndoe@bigcorp.com, using CHAP secret personalsecret.
...
username isp1 password ispsecret
username corp-gw password corpsecret
!
vpdn enable
vpdn outgoing bigcorp.com isp1 ip 192.1.1.1
...
There are two passwords, because there is a two-way authentication in establishing
the tunnel. The ISP has to prove itself to the corporate gateway, and vice
versa. So we're not doing CHAP between ISP1 and CORP-GW.
The rest of this is about as simple as could be. It tells the NAS we're doing VPDN, and then says that for domain bigcorp.com to go via IP to 192.1.1.1 and identify the NAS as ISP1.
Other forms of user authentication (TACACS+) could be used instead.
...
username isp1 password ispsecret
username corp-gw password corpsecret
username johndoe@bigcorp.com password personalsecret
!
vpdn enable
vpdn incoming isp1 corp-gw virtual-template 10
!
interface virtual-template 10
ip unnumbered ethernet 0
encapsulation ppp
ppp authentication chap
...
vpdn force-local-chapallows us to force the gateway to issue its own CHAP challenge. The default is to not do so.
The command
show vpdnshows active tunnels, NAS (LAC) and gateway (LNS), and also MID's and user names.
If we're troubleshooting or testing, the command
clear vpdn tunnel nas_name gateway_namelets us shut down a tunnel.
http://www.cisco.com/warp/customer/728/General/vpdn_wp.htmVirtual Private Dialup Network (VPDN)
http://www.cisco.com/warp/customer/131/5.htmlVirtual Access PPP Features in Cisco IOS
http://www.cisco.com/warp/customer/131/4.htmlOther URL's of interest:
http://www.masinter.net/~l2tp/
http://www.wcmh.com/lantimes/96oct/610a046a.htmlThe draft standards document is very readable:
ftp://ftp.uu.net/inet/internet-drafts/draft-ietf-pppext-l2tp-03.txtEnjoy!
Dr. Peter J. Welcher (CCIE #1773, CCSI #94014) is a Senior Consultant with Chesapeake NetCraftsmen. NetCraftsmen is a high-end consulting firm and Cisco Premier Partner dedicated to quality consulting and knowledge transfer. NetCraftsmen has nine CCIE's, with expertise including large network high-availability routing/switching and design, VoIP, QoS, MPLS, network management, security, IP multicast, and other areas. See http://www.netcraftsmen.net for more information about NetCraftsmen. Pete's links start at http://www.netcraftsmen.net/welcher . New articles will be posted under the Articles link. Questions, suggestions for articles, etc. can be sent to pjw@netcraftsmen.net .