Configure Routing and Remote Access Part 2
Updated: May 30
Part 2 Understanding the Benefits of Multilink
Many parts of the world don’t have high-speed broadband access yet. In fact, many places don’t have ISDN or even phone lines that support 56Kbps modems. The multilink extensions to the Point-to-Point Protocol provide a way to take several independent PPP connections and make them look like one line so that they act as a single connection. For example, if you use two phone lines and modems to place a two-line multilink call to your ISP, instead of getting the usual 48Kbps connection, you would end up with an apparent bandwidth of 96Kbps. The multilink PPP software on your Windows Server 2012 R2 machine and on the ISP’s router takes care of stringing all of the packets together to make this process seamless. Windows Server 2012’s RRAS supports multilink PPP for inbound and outbound calls.
Overview of Virtual Private Networks
Private networks offer superior security. You own the wires, so you have control over what they’re used for, who can use them, and what kind of data passes over them. However, they’re not very flexible because they require you to configure and manage costly leased lines between remote locations. To make things worse, most private networks face a dilemma: Implementing enough capacity to handle peak loads almost guarantees that much of that capacity will remain idle much of the time, even though it still has to be paid for.
One way to work around this problem is to maintain private dial-up services. Such services allow, for example, a field rep in Chicago to dial into the home office in Boston. But dial-ups are expensive, and they have the same excess capacity problem as truly private networks. As an added detriment, someone has to pay long-distance or toll-free number charges.
Virtual private networks (VPNs) offer a solution. You get the security of a true private network with the flexibility, ubiquity, and low cost of the Internet. In the following sections, I will cover VPNs, including what they are used for and how they work (in general and with Windows Server 2012).
What VPNs Do
At any time, two parties can create a connection over the Internet. The idea behind a VPN is that you can use these connections to let two parties establish an encrypted tunnel between them using the Internet as a transportation medium. The VPN software on each end takes care of encrypting the VPN packets as they go; when the packets leave one end of the tunnel, their payloads are encrypted and encapsulated inside regular IP packets that cause them to be delivered to the remote machine. Figure 13.1 shows one way to conceptualize this process.
FIGURE 13.1 Drilling a tunnel through the Internet
As an example, let’s say you’re in the field at a client site. As long as you’re somewhere that your ISP serves, you can dial into the client’s local point of presence and get connected to the Internet. At that point, you can open a VPN connection back to the servers at your office and do whatever you could do when sitting in front of a regular desktop machine.
VPNs and Windows Server 2012 R2 Windows Server 2012 R2
includes support for Microsoft’s proprietary Point-to-Point Tunneling Protocol and Layer 2 Tunneling Protocol. Layer 2 Tunneling Protocol (L2TP) provides a more generic tunneling mechanism than PPTP, and when combined with IPsec, L2TP also allows you to establish VPNs using a wide range of Microsoft or non-Microsoft hardware and software products, including routers and access devices from companies such as Cisco, Red Creek, and Nortel.
Windows Server 2012 R2’s VPN support includes the following worthwhile features:
You can set up account lockout policies for dial-up and VPN users. This capacity has existed for network and console users for some time.
The Extensible Authentication Protocol (EAP) allows Microsoft or third parties to write modules that implement new authentication methods and retrofit them to servers. One example is the EAP-TLS module, which implements access control based on smart cards and certificates for VPN and dial-up users.
How you enable VPN support on your Windows Server 2012 R2 machine depends on whether you’re using a server or a client (Windows XP, Windows Vista, Windows 7, Windows 8, and so on). The client configuration is easy. Just install the Dial-Up Networking service and then use the Make New Connection Wizard to create a new VPN connection. On the server side, you’ll need to install and configure RRAS and then enable it to accept incoming VPN connections.
How VPNs Work
The VPN client assumes that the VPN server is already connected to the Internet in some way. Here’s how the VPN connection process works
The client establishes a connection to the Internet. Dial-up networking or any other connection method can be used for this connection. The client must be able to send packets to the Internet.
The client sends a VPN connection request to the server. The exact format of the request varies, depending on whether the VPN is using PPTP, L2TP, or SSTP. 3.
The client authenticates itself to the server. Again, the exact process varies according to the VPN protocol in use. If the client can’t provide valid credentials, the connection is terminated.
The client and server negotiate parameters for the VPN session. This negotiation allows the two ends to agree on an encryption algorithm and strength. 5.
The client and server go through the PPP negotiation process because both L2TP and PPTP depend on the lower-level PPP.
Because the contents of data passed around in step 2 and step 3 vary according to the tunneling protocol in use, I’ll explain the differences. First, though, you should understand encapsulation and how VPNs use it to wrap one kind of data inside another.
An Encapsulation Primer Most of yesterday’s networks could carry only one kind of data. Each network vendor had its own protocol, and most of the time there was no way to intermingle data using different protocols on the same line. Over time, vendors began to find ways to allow a single network to carry many different types of traffic, resulting in the current assortment of traffic types found on most large networks. However, the Internet works only with IP, which is why it’s called Internet Protocol. If you need to send other types of traffic, such as AppleTalk, across the Internet, you can encapsulate it within IP.
How does encapsulation work? Software at each level of the OSI model has to see header information to figure out where a packet is coming from and where it’s going. However, the payload contents aren’t important to most of those components, and the payload is what’s encapsulated. By fabricating the right kind of header and prepending it for whatever you want in the payload, you can route foreign traffic types through IP networks with no trouble.
VPNs depend on encapsulation because their security method depends on being able to keep the payload information encrypted. The following steps demonstrate what happens to a typical packet as it goes from being a regular IP datagram to a PPTP packet.
The encapsulation process
An application creates a block of data-bound for a remote host. In this case, it’s a web browser.
The client-side IP stack takes the application’s data and turns it into an IP packet, first by adding a TCP header and then by adding an IP header. This is called the IP datagram because it contains all of the necessary addressing information to be delivered by IP
The client is connected via PPP, so it adds a PPP header to the IP datagram. This PPP+IP combination is called a PPP frame.
If you are using PPP instead of a VPN protocol, the packet goes across the PPP link without further modification. When you are using a VPN (as in this example), the next step is for the VPN to encrypt the PPP frame, turning it into unreadable information to be transported over the Intern
A Generic Routing Encapsulation (GRE) header is combined with the encrypted payload. GRE really is generic; in this case, the protocol ID field in the GRE header says that this is an encapsulated PPTP packet.
Now that there is a tag to tell you what’s in the payload, the PPTP stack can add an IP header (specifying the destination address of the VPN server) and a PPP header
Now the packet can be sent out over your PPP connection. The IP header specifies that it should be routed to the VPN server.
When the packet arrives at the VPN server, the server reverses steps 1 through 6 to extract the payload.
Encapsulation allows the use of VPN data inside ordinary-looking IP datagrams, which is part of what makes VPNs so powerful—you don’t have to change any of your applications, routers, or network components (unless they have to be configured to recognize and pass GRE packets).
PPTP is a pretty straightforward protocol. It works by encapsulating packets using the mechanism described in the previous section, “An Encapsulation Primer,” and performs encryption (step 4) using the Microsoft Point-to-Point Encryption (MPPE) algorithm. The encryption keys used to encrypt the packets are generated dynamically for each connection; in fact, the keys can be changed periodically during the connection.
When the client and server have successfully established a PPTP tunnel, the authorization process begins. This process is an exchange of credentials that allows the server to decide whether the client is permitted to connect:
The server sends a challenge message to the client.
The server sends a challenge message to the client.
The server checks the response to see whether the answer is right. The challenge-response process allows the server to determine which account is trying to make a connection.
The server determines whether the user account is authorized to make a connection.
If the account is authorized, the server accepts the inbound connection; any access controls or remote access restrictions still apply.
L2TP is much more flexible than PPTP, but it’s also more complicated. It was designed to be a general-purpose tunneling protocol not limited to VPN use.
L2TP itself doesn’t offer any kind of security. When you use L2TP, you’re setting up an unencrypted, unauthenticated tunnel. Using L2TP by itself over the Internet, therefore, would be dangerous because anyone who wanted to could read your traffic.
The overall flow of an L2TP/IPsec tunnel session looks a little different from that of a PPTP session because IPsec security is different. Here’s how the L2TP/IPsec combination works:
The client and server establish an IPsec security association using the ISAKMP and Oakley protocols. At this point, the two machines have an encrypted channel between them.
The client builds a new L2TP tunnel to the server. Because this happens after the channel has been encrypted, there’s no security risk.
The server sends an authentication challenge to the client.
The client encrypts its answer to the challenge and returns it to the server.
The server checks the challenge response to see whether it’s valid; if so, the server can determine which account is connecting. At this point, the server can accept the inbound connection, subject to whatever access policies you’ve put in place.
Note that steps 3 through 5 mirror the steps described for PPTP tunneling. This is because the authorization process is a function of the remote access server, not the VPN stack. All the VPN does is to provide a secure communications channel, and something else has to decide who gets to use it.
The Secure Sockets Tunneling Protocol (SSTS) is a secure way to make a VPN connection using the Secure Sockets Layer v.3 (SSL) port 443. The following steps show how SSTP operates and functions:
The client connects to the server through the Internet using port 443.
During the TCP session, SSL negotiation takes place.
During the SSL authentication phase, the client machine receives the server certificate.
The client machine will send HTTPS requests on top of the encrypted SSL session.
The client machine will then also send SSTP control packets on top of the HTTPS session.
PPP negotiation now takes place on both ends of the connection.
After PPP is finished, both ends are ready to send IP packets to each other.