Configure Routing and Remote Access

Configure VPN and routing

Part - 1

✓ Configure VPN and routing

• Install and configure the Remote Access role

• Implement Network Address Translation (NAT)

• Configure VPN settings

• Configure remote dial-in settings for users

• Configure routing

• Configure Web Application proxy in passthrough mode

✓ Configure DirectAccess

• Implement server requirements

• Implement client configuration

• Configure DNS for DirectAccess

• Configure certificates for DirectAccess

Let's start the blog Now that you understand how the routing works, it’s time to study how clients connect using remote access. Routing and Remote Access Services (RRAS) includes some security features necessary to provide remote access effectively. For example, you’ll probably want the ability to restrict user dial-up access by group membership, time of day, or other factors. You’ll also need a way to specify the various callback, authentication, and encryption options that the protocols support.

In this blog, you’ll learn about virtual private networks (VPNs), which provide remote access to private networks across public connections. That is, using the Internet, clients can dial into an Internet service provider (ISP) and connect to your private network. The main advantage of VPNs is reduced cost because it means that long-distance calls are unnecessary. VPNs are becoming more popular because of the increased popularity of high-speed Internet connections, such as cable and digital subscriber line (DSL) connections.

Many of the features included in Windows Server 2012 R2 are simply carried over from Windows Server 2008, with a few minor additions. This is the case with the Routing and Remote Access console.

Before I can get into the details of what these features do and how to configure them to provide remote access for your network, you need to understand some of the terms and concepts specific to RRAS. That’s where you’ll begin in this blog , and then you’ll move on to learning knowledge about the features and configuration settings that you need to understand to meet the exam objectives.

Overview of Dial-Up Networking

LANs provide relatively high-speed connectivity to attached machines, but where does that leave those of us who work from home, who travel, or who need to access data on a remote computer? Until wireless access is available worldwide, we have the option of using dial-up

networking in which the client computer uses a modem to dial in and connect to a remote

server. Once the connection is established, a variety of protocols and services make it

possible for us to view web pages, transfer files and email, and do pretty much anything we

could do with a hardwired LAN connection, albeit at a reduced speed.

In the following sections, you will learn more about what dial-up networking does and

how it works by examining the specific technologies and protocols associated with remote

access.

What DUN Does

At this point in the article, you should understand that Windows Server 2012 R2 network protocols are actually implemented as drivers. These drivers basically normally work with hardware network interfaces to get data from point A to point B. How do dial-up connections fit in? Many people may read this and say, “Who still uses dial-up?” Well, as a person who lives in New Hampshire, I can tell you that we still have many areas that can’t get broadband or even satellite access.

Think back to the OSI model. Each layer has its own function, and each layer serves as an intermediary between the layer above it and the one below it. By substituting one driver for another at some level in the stack, you can dramatically change how things work. That’s exactly what the Windows Server 2012 R2’s Dial-Up Networking (DUN) subsystem does. It makes the dial-up connection appear to be just another network adapter.

The DUN driver takes care of the task of making a slow asynchronous modem appear to work as a fast LAN interface. Applications and services that use TCP/IP on your DUN connection never know the difference. In fact, you can configure Windows Server 2012 R2 to use your primary connection first and then to pass traffic over a secondary connection (such as a dial-up link) if the primary connection is down. This does not affect the applications with which you’re working (except that they might run more slowly).

On the server-side, DUN allows you to host one or more network users who dial into your Windows Server 2012 R2 machine. Windows 8 and Windows 10 all allow up to 10 concurrent dial-up connections, and Windows Server 2012 R2 allows up to 255. (Be aware that by the time you allow 255 concurrent connections, you’ll probably be overloading your server.)

Overall depending on how we set up or configure the DUN server, users who dial in can see the complete network or only specific resources on the server. We also get to control who can log in when they can log in, and what they can access after they logged on. As far as Windows Server 2012 R2 is concerned, a user connected via DUN is no different from one using resources over your LAN, so all the access controls and permissions we apply remain in force for DUN users.

How DUN Works

A lot of pieces are required to complete a dial-up call successfully from your computer to a server at another physical location. Understanding what these pieces are, how they work, and what they do for you is important. The following sections will cover the DUN infrastructure, how the Point-to-Point Protocol (PPP) helps with this connection, the relationship between PPP and the network protocols, and how multilink can be used to increase the speed and efficiency of your remote connections.

The DUN Infrastructure

This section covers the physical layer that underlies voice and data calls. Most of the following material will be familiar to anyone who has ever used a modem, but you should still understand the details you may not have considered before.

Plain Old Telephone Service

Plain Old Telephone Service (POTS) connections offer a theoretical maximum speed of 56Kbps; in practice, many users routinely get connections at 51Kbps or 52Kbps.

The word modem is actually short for modulator-demodulator. The original Bell System modems took digital data and modulated it into screechy analog audio tones suitable for use on regular phone lines. Because phone lines are purposely designed to pass only the low end of the audible frequency range that most can hear, the amount of data was limited. However, in the early 1990s, an engineer discovered that you could communicate much faster when the path between the sender and receiver was all digital.

An all-digital path doesn’t have any analog components that induce signal loss, so it preserves the original signal quality faithfully. This in turn makes it possible to put more information into the original signal. As it happens, phone companies nationwide were in the process of making major upgrades to replace their analog equipment with newer and better digital equivalents. These upgrades made it possible for people in most areas to get almost 56Kbps speeds without changing any of the wirings in their homes or offices. The connection between the house and the phone office was still analog, but the connections between phone offices were digital, ensuring high-quality connections

Integrated Services Digital Network In the mid-1970s, Integrated Services Digital Network (ISDN) was designed. At the time, no one had any idea that you’d be able to get 56Kbps speeds out of an ordinary phone line. ISDN speeds of up to 128Kbps over a single pair of copper wires seemed pretty revolutionary. In addition, ISDN had features such as call forwarding, caller ID, and multiple directory numbers (so you could have more than one number, perhaps with different ringing patterns, associated with a single line)

Unfortunately, ISDN requires an all-digital signal path. It also requires special equipment on both ends of the connection. The phone companies were slow to promote ISDN as a faster alternative to regular dial-up service, so customers avoided it. ISDN still has some advantages, though. Because it’s all digital, call setup times are much shorter than they are for analog modems—it takes only about half a second to establish a new ISDN call. Modern ISDN adapters and ISDN-capable routers can seamlessly stitch together multiple ISDN channels to deliver bandwidth in 64Kbps increments. Because you can use ISDN lines for regular analog voice, data, and fax traffic, you can make a single ISDN act like two voice lines, a single 128Kbps data line, or a 64Kbps data line plus a voice line.

Other Connection Methods

Any other on-demand connection that’s established using the Point-to-Point Protocol can be thought of as a dial-up connection, and Windows Server 2012 R2 doesn’t make any distinction between POTS, ISDN, and other dial-ups—they’re all treated identically.

Connecting with PPP

The Point-to-Point Protocol enables any two devices to establish a TCP/IP connection over a serial link. That usually means a dial-up modem connection, but it could just as easily be a direct serial cable connection, an infrared connection, or any other type of serial connection. When one machine dials another, the machine that initiates the connection is referred to as a client, and the machine that receives the call is referred to as a server—even though PPP itself makes no such distinction.

PPP negotiation involves three phases that are required to establish a remote access connection. Actually, at least six distinct protocols run on top of PPP. Understanding what they do helps to make the actual PPP negotiation process clearer. These protocols are as follows:

The Links Control Protocol The Link Control Protocol (LCP) handles the details of establishing and configuring the lowest-level PPP link. In that regard, you can think of LCP as if it were almost part of the Physical layer. When one PPP device calls another, the devices use LCP to agree that they want to establish a PPP connection.

The Challenge Handshake Authentication Protocol

The Challenge Handshake Authentication Protocol (CHAP)—as well as MS-CHAPv2 and PAP—allow the client to authenticate itself to the server. This authentication functions much like a regular network logon; once the client presents its logon credentials, the server can figure out what access to grant.

The Callback Control Protocol

The Callback Control Protocol (CBCP) is used to negotiate whether a callback is required, whether it’s permitted, and when it happens. Once the client has authenticated itself, the server can decide whether it should hang up and call the client back. The client can also request a callback at the number it provides. Although this isn’t as secure as having the server place a call to a predetermined number, it provides some additional flexibility. If a callback occurs, the connection is reestablished and reauthenticated, but the CBCP stage is skipped.

The Compression Control Protocol

The Compression Control Protocol (CCP) allows the two sides of the connection to determine what kind of compression, if any, they want to use on the network data. Because PPP traffic actually consists of wrapped-up IP datagrams and because IP datagram headers tend to be fairly compressible, negotiating effective compression can significantly improve overall PPP throughput.

The IP Control Protocol

At this point in the call, the two sides have agreed to authentication, compression, and a callback. They haven’t yet agreed on what IP parameters to use for the connection. These parameters, which include the maximum packet size to be sent over the link (the maximum transmission unit, or MTU), have a great impact on the overall link performance, so the client and server use the IP Control Protocol (IPCP) to negotiate them based on the traffic they expect to be passed.

The Internet Protocol

Once the IPCP negotiation has been completed, each end has complete knowledge of how to communicate with its peer. That knowledge allows the two sides to begin exchanging Internet Protocol (IP) datagrams over the link, just as they would over a standard LAN connection.

The Relationship Between PPP and Network Protocols

Usually, when you hear about network communication, you hear about using TCP/IP on a hardwired LAN. How does this protocol fit in with PPP? In the case of TCP/IP, that’s an easy question to answer: The client routes all (or some) of its outgoing TCP/IP traffic to its PPP peer, which can then inspect the IP datagrams it gets back from the PPP stack to analyze and route them properly.

Windows Server 2012 R2 supports only TCP/IP, so consider what has to happen when a client using AppleTalk needs to connect via dial-up. Because the server will not use those other protocols, it will drop the call or cause the client to warn its user (that’s what Windows Server 2012 R2 does). After the other PPP setup steps are finished, the client and server can wrap other types of network traffic inside an IP datagram. This process, called encapsulation, allows the client to take a packet with some kind of private content, wrap it inside an IP datagram, and send it to the server. The server, in turn, processes the IP datagram, routing real datagrams normally and handling any encapsulated packets with the appropriate protocol. At that point, the client can communicate with the server without knowing that its non-TCP/IP packets are being encapsulated in any way—that detail is hidden deep in the layers of the OSI model.