Routing and Remote Access

The Routing and Remote Access service in Windows Server® 2008 supports remote user or site-to-site connectivity by using virtual private network (VPN) or dial-up connections. Routing and Remote Access consists of the following components:

Remote Access

The remote access feature provides VPN services so that users can access corporate networks over the Internet as if they were directly connected. Remote access also enables remote or mobile workers who use dial-up communication links to access corporate networks.

Routing

Routing and Remote Access is a full-featured software router and an open platform for routing and networking. It offers routing services to businesses in local area network (LAN) and wide area network (WAN) environments or over the Internet by using secure VPN connections. Routing is used for multiprotocol LAN-to-LAN, LAN-to-WAN, VPN, and network address translation (NAT) routing services


Overview of Routing and Remote Access

  • What Is Routing and Remote Access?

  • What's New in Routing and Remote Access

  • Common Remote Access Configurations

  • Common Routing Scenarios


What Is Routing and Remote Access?

Routing

A router is a device that manages the flow of data between network segments, or subnets. A router directs incoming and outgoing packets based on the information it holds about the state of its own network interfaces and a list of possible sources and destinations for network traffic. By projecting network traffic and routing needs based on the number and types of hardware devices and applications used in your environment, you can better decide whether to use a dedicated hardware router, a software-based router, or a combination of both. Generally, dedicated hardware routers handle heavier routing demands best, and less expensive software-based routers are sufficient to handle lighter routing loads.

A software-based routing solution, such as the Routing and Remote Access service in Windows Server® 2008, can be ideal on a small, segmented network with relatively light traffic between subnets. Conversely, enterprise network environments that have a large number of network segments and a wide range of performance requirements might need a variety of hardware-based routers to perform different roles throughout the network.

Remote access

By configuring Routing and Remote Access to act as a remote access server, you can connect remote or mobile workers to your organization's networks. Remote users can work as if their computers are physically connected to the network.

All services typically available to a LAN-connected user (including file and print sharing, Web server access, and messaging) are enabled by means of the remote access connection. For example, on a server running Routing and Remote Access, clients can use Windows Explorer to make drive connections and to connect to printers. Because drive letters and universal naming convention (UNC) names are fully supported by remote access, most commercial and custom applications work without modification.

A server running Routing and Remote Access provides two different types of remote access connectivity:

  • Virtual private networking (VPN)

    VPN is the creation of secured, point-to-point connections across a private network or a public network such as the Internet. A VPN client uses special TCP/IP-based protocols called tunneling protocols to make a virtual call to a virtual port on a VPN server. The best example of virtual private networking is that of a VPN client that makes a VPN connection to a remote access server that is connected to the Internet. The remote access server answers the virtual call, authenticates the caller, and transfers data between the VPN client and the corporate network.

    In contrast to dial-up networking, VPN is always a logical, indirect connection between the VPN client and the VPN server over a public network, such as the Internet. To ensure privacy, you must encrypt data sent over the connection.

    For more information, see What Is VPN?.

  • Dial-up networking

    In dial-up networking, a remote access client makes a nonpermanent, dial-up connection to a physical port on a remote access server by using the service of a telecommunications provider, such as analog phone or ISDN. The best example of dial-up networking is that of a dial-up networking client that dials the phone number of one of the ports of a remote access server.

    Dial-up networking over an analog phone or ISDN is a direct physical connection between the dial-up networking client and the dial-up networking server. You can encrypt data sent over the connection, but it is not required.

    For more information, see What Is Dial-Up Networking?.

Additional references

  • Common Remote Access Configurations


What's New in Routing and Remote Access

Windows Server® 2008 includes several new features designed to enhance security and manageability of Routing and Remote Access. This topic describes the new features and other significant changes made to Routing and Remote Access in Windows Server 2008.

New Features

Server Manager

SSTP tunneling protocol

VPN enforcement for Network Access Protection

IPv6 support

New cryptographic support

Removed technologies

Server Manager

Server Manager is a new feature designed to guide information technology (IT) administrators through the process of installing, configuring, and managing server roles and features that are part of Windows Server 2008. Server Manager is started automatically after the administrator completes the tasks listed in Initial Configuration Tasks. After that, it is started automatically when an administrator logs on to the server.

Use the following steps to install Routing and Remote Access using Server Manager:

To install Routing and Remote Access

  1. Install Windows Server 2008.

  2. Click Start, Administrative Tools, Server Manager.

  3. Under Roles Summary, click Add roles.

  4. Click Next. Select the Network Access Services role, and then click Next.

  5. Click Next. Select the Routing and Remote Access Services role service, and then click Next.

    Note

    This will select all three Routing and Remote Access services.

  6. Click Install. When the Installation Results dialog box appears, click Close.

Use the following steps to configure and enable the Routing and Remote Access service:

To configure and enable the Routing and Remote Access service

  1. Click Start, Administrative Tools, Routing and Remote Access.

  2. By default, the local computer is listed as a server. Right-click the server, and then click Configure and Enable Routing and Remote Access.

  3. Click Next. Click Custom configuration, and then click Next.

  4. Select all the services except NAT, click Next, and then click Finish.

  5. Click OK, click Start service, and then click Finish.

SSTP tunneling protocol

Secure Socket Tunneling Protocol (SSTP) is a new form of virtual private networking (VPN) tunnel with features that allow traffic to pass through firewalls that block PPTP and L2TP/IPsec traffic. SSTP provides a mechanism to encapsulate PPP traffic over the SSL channel of the HTTPS protocol. The use of PPP allows support for strong authentication methods, such as EAP-TLS. The use of HTTPS means traffic will flow through TCP port 443, a port commonly used for Web access. Secure Sockets Layer (SSL) provides transport-level security with enhanced key negotiation, encryption, and integrity checking.

VPN enforcement for Network Access Protection

Network Access Protection (NAP) is a client health policy creation, enforcement, and remediation technology that is included in Windows Vista® client operating system and in the Windows Server 2008 operating system. With NAP, system administrators can establish and automatically enforce health policies, which can include software requirements, security update requirements, required computer configurations, and other settings.

When making VPN connections, client computers that are not in compliance with health policy can be provided with restricted network access until their configuration is updated and brought into compliance with policy. Depending on how you choose to deploy NAP, noncompliant clients can be automatically updated so that users can quickly regain full network access without manually updating or reconfiguring their computers.

VPN enforcement provides strong limited network access for all computers accessing the network through a VPN connection. VPN enforcement with NAP is similar in function to Network Access Quarantine Control, a feature in Windows Server 2003, but it is easier to deploy.

Remote access policy configuration

You must use Network Policy Server to create and configure remote access policies. Use the following steps to set the remote access policy to grant user access:

To configure the remote access policy

  1. Open Routing and Remote Access.

  2. Right-click Remote Access Logging & Policies, and then click Launch NPS.

  3. Click Network Policies.

  4. Double-click Connections to Microsoft Routing and Remote Access server.

  5. On the Overview tab, under Access Permission, click Grant access, and then click OK.

IPv6 support

Windows Server 2008 and Windows Vista support the following enhancements to Internet Protocol version 6 (IPv6):

  • Protocols

    • PPPv6. Native IPv6 traffic can now be sent over PPP-based connections. (RFC 2472). For example, PPPv6 support allows you to connect with an IPv6-based Internet service provider (ISP) through dial-up or PPP over Ethernet (PPPoE)-based connections that might be used for broadband Internet access.

    • PPPv6 over dial-up/Ethernet as well as VPN tunnels

    • L2TP over IPv6

    • DHCPv6 Relay Agent

  • Stateless filtering, based on the following parameters:

    • Source IPv6 address/prefix

    • Destination IPv6 address/prefix

    • Next hop type (IP protocol type)

    • Source Port number (TCP/UDP)

    • Destination Port number (TCP/UDP)

  • RADIUS over IPv6 transport

IPv6 configuration

By default, Routing and Remote Access is configured to accept only Internet Protocol version 4 (IPv4) connections. In Windows Server 2008, you can use the Routing and Remote Access Microsoft Management Console (MMC) to configure IPv6 routing and connections. Use the following steps to configure Routing and Remote Access to accept IPv6 and IPv4 connections.

To enable IPv6 connections

  1. In the Routing and Remote Access MMC, right-click the server, and then click Properties.

  2. Click the IPv6 tab.

  3. Enter an IPv6 prefix (for example: 3ffe::).

  4. Click the General tab.

  5. Click IPv6 Router, and then click IPv6 Remote access server.

  6. Click OK, and then click Yes to restart the Routing and Remote Access service.

New cryptographic support

In response to governmental security requirements and trends in the security industry to support stronger cryptography, Windows Server 2008 and Windows Vista support the following encryption algorithms for PPTP and L2TP VPN connections.

PPTP
  • Only 128-bit RC4 encryption algorithm is supported.

  • 40 and 56-bit RC4 support is removed, but can be added (not recommended) by changing a registry key.

L2TP/IPsec

Data Encryption Standard (DES) encryption algorithm with Message Digest 5 (MD5) integrity check support is removed, but can be added (not recommended) by changing a registry key.

IKE Main Mode will support:

  • Advanced Encryption Standard (AES) 256 (new), AES 192 (new), AES 128 (new), and 3DES encryption algorithms.

  • Secure Hash Algorithm 1 (SHA1) integrity check algorithm.

  • Diffie-Hellman (DH) groups 19 (new) and 20 (new) for Main Mode negotiation.

IKE Quick Mode will support:

  • AES 256 (new), AES 192 (new), AES 128 (new), and 3DES encryption algorithms.

  • SHA1 integrity check algorithm.

Removed technologies

Support for the following technologies has been removed from Windows Server 2008 and Windows Vista:

  • Bandwidth Allocation Protocol (BAP). Removed from Windows Vista. Disabled in Windows Server 2008.

  • X.25.

  • Serial Line Interface Protocol (SLIP). SLIP-based connections will automatically be updated to PPP-based connections.

  • Asynchronous Transfer Mode (ATM).

  • IP over IEEE 1394.

  • NWLink IPX/SPX/NetBIOS Compatible Transport Protocol.

  • Services for Macintosh.

  • Open Shortest Path First (OSPF) routing protocol component in Routing and Remote Access.

  • Basic Firewall in Routing and Remote Access (replaced with Windows Firewall).

  • Static IP filter application programming interfaces (APIs) for Routing and Remote Access (replaced with Windows Filtering Platform APIs).

  • The SPAP, EAP-MD5-CHAP, and MS-CHAP authentication protocols for PPP-based connections.

Additional references

  • New Networking Features in Windows Server 2008 and Windows Vista (http://go.microsoft.com/fwlink/?LinkId=71606)


Common Remote Access Configurations

When you run the Routing and Remote Access Server Setup Wizard, the wizard prompts you to choose the configuration path that most closely resembles the remote access solution that you want to deploy. If none of the wizard configuration paths meets your needs exactly, you can further configure your server after the wizard finishes, or you can choose the custom configuration path. However, if you choose the custom configuration path, you must manually configure all elements of Routing and Remote Access. The most common remote access solutions include virtual private network (VPN) connections, dial-up connections, and secure connections between two private networks.

Remote access (VPN)

Remote access (VPN)

If you choose this path, the server running Routing and Remote Access is configured to allow remote access clients to connect to the private network across the Internet. To configure this type of server in the wizard, click Remote Access, select the VPN check box, and follow the steps. After the wizard completes the steps, you can configure additional options. For example, you can configure how the server verifies which VPN clients have permission to connect to the private network and whether the server routes network traffic between VPN clients and the private network.

Remote access (dial-up)

Remote access (dial-up)

If you choose this path, the server running Routing and Remote Access is configured to allow remote access clients to connect to the private network by dialing into a modem bank or other dial-up equipment. To configure this type of server in the wizard, click Remote Access, select the Dial-up check box, and follow the steps. After the wizard completes the steps, you can configure additional options. For example, you can configure how the server answers the call, how the server verifies which remote access clients have permission to connect to the private network, and whether the server routes network traffic between remote access clients and the private network.

Network address translation

Network address translation (NAT)

If you choose this path, the server running Routing and Remote Access is configured to share an Internet connection with computers on the private network and to translate traffic between its public address and the private network. Computers on the Internet will not be able to determine the IP addresses of computers on the private network. To configure this type of server in the wizard, click Network address translation (NAT), and follow the steps. After the wizard completes the steps, you can configure additional options. For example, you can configure packet filters and choose which services to allow on the public interface.

VPN and NAT

If you choose this path, the server running Routing and Remote Access is configured to provide NAT for the private network and to accept VPN connections. Computers on the Internet will not be able to determine the IP addresses of computers on the private network. However, VPN clients will be able to connect to computers on the private network as if they were physically attached to the same network. To configure this type of server in the wizard, click Virtual Private Network (VPN) access and NAT, and follow the steps.

Secure connection between two private networks

Secure connection between two private networks

If you choose this path, two servers running Routing and Remote Access are configured to send private data securely across the Internet. You must choose this path when you run the Routing and Remote Access Server Setup Wizard on each server. The connection between the two servers can be persistent (always on) or on demand (demand-dial). To configure this type of server in the wizard, click Secure connection between two private networks, and follow the steps. After the wizard completes the steps, you can configure each server with additional options. For example, you can configure which routing protocols each server accepts and the way in which each server routes traffic between the two networks.


Common Routing Scenarios

You can use routers in many different topologies and network configurations. This topic describes three typical routing scenarios.

Simple routing scenario

The following illustration shows a simple network configuration with a server running Routing and Remote Access that connects two local area network (LAN) segments (Networks A and B). In this configuration, routing protocols are not required because the router is connected to all of the networks to which it needs to route packets.

Simple routing scenario

Multiple-router scenario

The following illustration shows a more complex router configuration.

Multiple router scenario

In this configuration, there are three networks (Networks A, B, and C) and two routers (Routers 1 and 2). Router 1 is on Networks A and B, and Router 2 is on Networks B and C. Router 1 must notify Router 2 that Network A can be reached through Router 1, and Router 2 must notify Router 1 that Network C can be reached through Router 2. This information is automatically communicated through the use of a routing protocol, such as RIP. When a user on Network A wants to communicate with a user on Network C, the user's computer on Network A forwards the packet to Router 1. Router 1 then forwards the packet to Router 2. Router 2 then forwards the packet to the user's computer on Network C.

Without the use of routing protocols, a network administrator must enter static routes into the routing tables of Router 1 and Router 2. Although static routes work, they do not scale well to larger networks or recover from changes in the network topology.

Demand-dial routing scenario

The following illustration shows a router configuration that uses demand-dialing.

Demand-dial routing scenario

Networks A and B are geographically separated and, for the amount of traffic that is transferred between the networks, a leased wide area network (WAN) link is not economical. Router 1 and Router 2 can connect over an analog phone line by using modems (or another type of connectivity, such as ISDN) on both ends. When a computer on Network A initiates communication with a computer on Network B, Router 1 establishes a phone connection with Router 2. The modem connection is maintained as long as there are packets going back and forth. When the connection is idle, Router 1 hangs up to reduce connection costs.


Install and Enable the Routing and Remote Access Service

The Routing and Remote Access service in the Windows Server® 2008 family provides:

  • Virtual private network (VPN) remote access and dial-up services.

  • Multiprotocol LAN-to-LAN, LAN-to-WAN, VPN, and network address translation (NAT) routing services.

You install the Routing and Remote Access service by using the Add Roles Wizard.

Membership in the local Administrators group, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477.

To install the Routing and Remote Access service

  1. In the Server Manager main window, under Roles Summary, click Add roles.

    -- OR --

    In the Initial Configuration Tasks window, under Customize This Server, click Add roles.

  2. In the Add Roles Wizard, click Next.

  3. In the list of server roles, select Network Policy and Access Services. Click Next twice.

  4. In the list of role services, select Routing and Remote Access Services to select all of the role services. You can also select individual server roles.

  5. Proceed through the steps in the Add Roles Wizard to complete the installation.
Note

After you complete the installation, the Routing and Remote Access service is installed in a disabled state. To enable and configure the remote access server, you must be logged on as a member of the Administrators group.

After installing the Routing and Remote Access service, you need to enable the service to configure your server for routing and remote access.

To enable the Routing and Remote Access service

  1. If this server is a member of an Active Directory® domain and you are not a domain administrator, instruct your domain administrator to add the computer account of this server to the RAS and IAS Servers security group in the domain of which this server is a member. The domain administrator can add the computer account to the RAS and IAS Servers security group by using Active Directory Users and Computers or by using the netsh ras add registeredserver command. If this server is using local authentication or is authenticating against a RADIUS server, skip this step.

  2. Open Routing and Remote Access.

  3. By default, the local computer is listed as a server.

    To add another server, in the console tree, right-click Server Status, and then click Add Server.

    In the Add Server dialog box, click the applicable option, and then click OK.

  4. In the console tree, right-click the server you want to enable, and then click Configure and Enable Routing and Remote Access.

  5. Follow the instructions in the Routing and Remote Access Server Setup Wizard.

Additional references

  • Configure a Remote Access VPN Server


Configure a Remote Access VPN Server

This topic explains the basic steps for configuring a remote access virtual private network (VPN) server using Server Manager, the Add Roles Wizard, and the Routing and Remote Access Server Setup Wizard. After you finish configuring a basic remote access VPN server, you can perform additional configuration tasks, depending on the way you want to use the remote access VPN server.

Before you begin

The following table lists the information that you need to know before you configure a remote access VPN server.

Before adding a remote access/VPN server role | Comments
Determine which network interface connects to the Internet and which network interface connects to your private network. | During configuration, you will be asked to choose which network interface connects to the Internet. If you specify the incorrect interface, your remote access VPN server will not operate correctly.
Determine whether remote clients will receive IP addresses from a Dynamic Host Configuration Protocol (DHCP) server on your private network or from the remote access VPN server that you are configuring. | If you have a DHCP server on your private network, the remote access VPN server can lease 10 addresses at a time from the DHCP server and assign those addresses to remote clients. If you do not have a DHCP server on your private network, the remote access VPN server can automatically generate and assign IP addresses to remote clients. If you want the remote access VPN server to assign IP addresses from a range that you specify, you must determine what that range should be.
Determine whether you want connection requests from VPN clients to be authenticated by a Remote Authentication Dial-In User Service (RADIUS) server or by the remote access VPN server that you are configuring. | Adding a RADIUS server is useful if you plan to install multiple remote access VPN servers, wireless access points, or other RADIUS clients to your private network. For more information, see Network Policy Server Help.
Determine whether VPN clients can send DHCP messages to the DHCP server on your private network. | If a DHCP server is on the same subnet as your remote access VPN server, DHCP messages from VPN clients will be able to reach the DHCP server after the VPN connection is established. If a DHCP server is on a different subnet from your remote access VPN server, make sure that the router between subnets can relay DHCP messages between clients and the server. If your router is running Windows Server® 2008, you can configure the DHCP Relay Agent service on the router to forward DHCP messages between subnets.
Verify that all users have user accounts that are configured for dial-up access. | Before users can connect to the network, they must have user accounts on the remote access VPN server or in Active Directory® Domain Services. Each user account on a stand-alone server or a domain controller contains properties that determine whether that user can connect. On a stand-alone server, you can set these properties by right-clicking the user account in Local Users and Groups and clicking Properties. On a domain controller, you can set these properties by right-clicking the user account in the Active Directory Users and Computers console and clicking Properties.

Configuring your remote access VPN server

To configure a remote access VPN server, start the Add Roles Wizard by doing either of the following:

  • In the Initial Configuration Tasks window, under Customize This Server, click Add roles. By default, Initial Configuration Tasks starts automatically when you log on.

  • Open Server Manager by clicking Start, Administrative Tools, and then click Server Manager. Then, under Roles Summary, click Add roles.

In the Add Roles Wizard, do the following:

  1. Click Next or click Select Server Roles.

  2. In the list of server roles, select Network Policy and Access Services. Click Next twice.

  3. In the list of role services, select Routing and Remote Access Services to select all the role services for Routing and Remote Access Services. You can also select individual server roles.

  4. Proceed through the steps in the Add Roles Wizard to complete the installation.

Completing additional tasks

After you complete the steps in the Add Roles Wizard and complete configuration in Routing and Remote Access, your server is ready for use as a remote access VPN server.

The following table lists additional tasks that you might want to perform on your remote access/VPN server.

Task | Purpose of task
Configure static packet filters. | To add static packet filters to better protect your network.
Configure services and ports. | To choose which services on your private network you want to make available for remote access users.
Adjust logging levels for routing protocols. | To configure the level of event details that you want to log. You can decide which information you want to track in your log files.
Configure the number of VPN ports. | To add or remove VPN ports.
Create a Connection Manager profile for your users. | To manage the client connection experience for your users and simplify troubleshooting client connections.
Add Active Directory Certificate Services (AD CS). | To configure and manage a certification authority (CA) on a server for use in a public key infrastructure (PKI).
Increase remote access security. | To protect your remote users and your private network by enforcing the use of secure authentication methods, requiring higher levels of data encryption, and more.
Increase VPN security. | To protect your remote users and your private network by requiring the use of secure routing and tunneling protocols, configuring account lockout, and more.

For more information about these tasks, see http://go.microsoft.com/fwlink/?LinkId=89010.

Removing the remote access VPN server role

If you need to reconfigure your server for a different role, you can remove existing server roles. When you remove the remote access VPN server role, your server will no longer provide dial-up or VPN access for remote access clients. Remote users will not be able to connect to your private network, and the computers on your private network might not be able to connect to the Internet.

To remove the remote access VPN server role, first restart the Add Roles Wizard by doing the following:

  • Open Server Manager by clicking Start, Administrative Tools, and then click Server Manager. Then, under Roles Summary, click Remove roles.

Then, in the Add Roles Wizard, remove the remote access VPN server role:

  • Advance to the Remove Server Roles page, click Network Policy and Access Services, click Next, click Remove, and then click Close. In the server restart confirmation dialog box, click Yes to restart your computer.

Additional references

  • Install and Enable the Routing and Remote Access Service


View Remote Access Server Properties

You can use the remote access server properties dialog box to view and modify routing, security, address assignment, logging, and other properties.

Membership in the local Administrators group, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477.

To view the properties of the remote access server

  1. Open Routing and Remote Access.

  2. Right-click the server name for which you want to view properties, and then click Properties.


Checklists: Routing and Remote Access

  • Checklist: Installing and Configuring the Remote Access Server

  • Checklists: VPN

  • Checklist: Installing and Configuring the Router

  • Checklist: Connecting Remote Sites

  • Checklist: Configuring Remote Access Behind a NAT-Enabled Router


Checklist: Installing and Configuring the Remote Access Server

Task | Reference
Review key concepts. | Remote Access
Install and configure modems. |
Enable and configure the Routing and Remote Access service. | Install and Enable the Routing and Remote Access Service
Configure dial-in properties and network policies for dial-in permission, authentication, and encryption settings. | See "Network Policies" in Network Policy Server Help.
(Optional) Configure the server running Routing and Remote Access as a RADIUS client to a Network Policy Server (NPS) for centralized network policy management. | See "RADIUS Clients" in Network Policy Server Help.

Additional references

  • For more information about installing and configuring the Remote Access Server, see http://go.microsoft.com/fwlink/?LinkId=89010.


Checklists: VPN

  • Checklist: Installing and Configuring a VPN Server

  • Checklist: Installing and Configuring a PPTP Server

  • Checklist: Installing and Configuring an L2TP Server

  • Checklist: Installing and Configuring an SSTP Server


Checklist: Installing and Configuring a VPN Server

Task | Reference
Review key concepts. | Virtual Private Networking
Install the Routing and Remote Access service and configure the server using the Routing and Remote Access Server Setup Wizard. | Install and Enable the Routing and Remote Access Service
Configure dial-in properties and network policies for dial-in permission, authentication, and encryption settings. | See "Checklist: Configure NPS for Dial-Up and VPN" in Network Policy Server Help.
Configure packet filters on your firewall. | For more information about VPN servers and firewall configuration, see VPN servers and firewall configuration (http://go.microsoft.com/fwlink/?linkid=89249). (This information describes how VPN servers and firewalls are configured in Windows Server 2003.)
(Optional) Configure the virtual private network (VPN) server as a RADIUS client. | See "RADIUS Clients" in Network Policy Server Help.

Additional references

  • For more information about installing and configuring a VPN server, see http://go.microsoft.com/fwlink/?LinkId=89010.


Checklist: Installing and Configuring a PPTP Server

Task | Reference
Review key concepts. | Virtual Private Networking
Install the Routing and Remote Access service and configure the server using the Routing and Remote Access Server Setup Wizard. | Install and Enable the Routing and Remote Access Service
Configure packet filters on your firewall. | For more information, see VPN servers and firewall configuration (http://go.microsoft.com/fwlink/?linkid=89249). (This information describes how VPN servers and firewalls are configured in Windows Server 2003.)
Configure dial-in properties and network policies for dial-in permission, authentication, and encryption settings. | See "Checklist: Configure NPS for Dial-Up and VPN" in Network Policy Server Help.

Additional references

  • For more information about installing and configuring a PPTP server, see http://go.microsoft.com/fwlink/?LinkId=89009.


Checklist: Installing and Configuring an L2TP Server

Step | Reference
Review key concepts. | Virtual Private Networking
Install the Routing and Remote Access service and configure the server using the Routing and Remote Access Server Setup Wizard. | Install and Enable the Routing and Remote Access Service
Configure packet filters on your firewall. | For more information, see VPN servers and firewall configuration (http://go.microsoft.com/fwlink/?linkid=89249). (This information describes how VPN servers and firewalls are configured in Windows Server 2003.)
Install computer certificates on the Layer Two Tunneling Protocol (L2TP) server computer and L2TP client computers. | For more information about deploying L2TP/IPsec-based remote access, see http://go.microsoft.com/fwlink/?LinkId=89009.
Configure dial-in properties and network policies for dial-in permission, authentication, and encryption settings. | See "Checklist: Configure NPS for Dial-Up and VPN" in Network Policy Server Help.

Additional references

  • For more information about installing and configuring an L2TP server, see http://go.microsoft.com/fwlink/?LinkId=89009.


Checklist: Installing and Configuring an SSTP Server

Step | Reference
Review key concepts. | Virtual Private Networking
Install the Routing and Remote Access service and configure the server using the Routing and Remote Access Server Setup Wizard. | Install and Enable the Routing and Remote Access Service
Configure packet filters on your firewall. | For more information, see VPN servers and firewall configuration (http://go.microsoft.com/fwlink/?linkid=89249). (This information describes how VPN servers and firewalls are configured in Windows Server 2003.)
Install a computer certificate on the Secure Socket Tunneling Protocol (SSTP) server and a root CA certificate on the SSTP VPN client computers. | For more information about deploying SSTP, see http://go.microsoft.com/fwlink/?LinkId=89009.
Configure dial-in properties and network policies for dial-in permission, authentication, and encryption settings. | See "Checklist: Configure NPS for Dial-Up and VPN" in Network Policy Server Help.

Additional references

For more information about installing and configuring an SSTP server, see http://go.microsoft.com/fwlink/?LinkId=89009.


Checklist: Installing and Configuring the Router

Task | Reference
Review key concepts. | Routing
For a new network, decide which protocols and routing features of Routing and Remote Access you want to use. For an existing network, determine which protocols and routing features of Routing and Remote Access you need to enable. | IPv4 Unicast Routing and IPv6 Routing
Enable and configure the Routing and Remote Access service. | Install and Enable the Routing and Remote Access Service
(Optional) Design and deploy static IP routing. | For more information, see Setting Up a Static Routed IP Internetwork (http://go.microsoft.com/fwlink/?LinkId=89351). (This information describes static IP routing as it is deployed in Windows Server 2003.)
(Optional) Design and deploy the RIP for IP routing protocol. | For more information, see Setting up a RIP-for-IP routed internetwork (http://go.microsoft.com/fwlink/?LinkId=89352). (This information describes RIP-for-IP as it is deployed in Windows Server 2003.)
(Optional) Add and configure the DHCP Relay Agent. | IPv4 - DHCP Relay Agent and IPv6 - DHCPv6 Relay Agent
(Optional) Configure IP multicast support. | What Is IPv4 Multicasting?
(Optional) Design and deploy network address translation (NAT). | Network Address Translation
(Optional) Configure the appropriate IP packet filters. | Packet Filtering
(Optional) Design and deploy demand-dial routing. | Demand-Dial Routing

Additional references

  • For more information about installing and configuring the router, see http://go.microsoft.com/fwlink/?LinkId=89009 and http://go.microsoft.com/fwlink/?LinkId=89010.


Checklist: Connecting Remote Sites

Task Reference

Choose remote site connection type:

  • Dial-up or virtual private network (VPN) connection.

  • On-demand or persistent connection.

  • One-way or two-way connection.

Choose security features:

  • Integrate the VPN server into a perimeter network.

  • Choose authentication provider.

  • Choose authentication method.

  • Choose Microsoft Point-to-Point Encryption (MPPE) or Internet Protocol security (IPsec) encryption.

  • Choose router user accounts and groups.

  • Choose remote access policy type.

Integrate the remote site connection into your network:

  • Design routing infrastructure.

  • Plan IP address assignment and name resolution.

  • Plan Active Directory® integration.

Deploy site-to-site connection.

Additional references

  • For more information, see Connecting Remote Sites http://go.microsoft.com/fwlink/?LinkId=89362 and http://go.microsoft.com/fwlink/?LinkId=89009.


Checklist: Configuring Remote Access Behind a NAT-Enabled Router

Task | Reference
Review key concepts. | What Is NAT? and Virtual Private Networking
Install the Routing and Remote Access service, and configure the server using the Routing and Remote Access Server Setup Wizard. | Install and Enable the Routing and Remote Access Service
Configure dial-in properties and network policies for dial-in permission, authentication, and encryption settings. | See "Checklist: Configure NPS for Dial-Up and VPN" in Network Policy Server Help.
Configure packet filters and Windows Firewall. | Filters and Remote Access Configurations and VPN servers and firewall configuration (http://go.microsoft.com/fwlink/?linkid=89249). (This information describes VPN and firewalls as they are configured in Windows Server 2003.)
Configure services to allow on the public interface. | IPv4 - NAT - Interface Properties - Services and Ports Tab
(Optional) Configure the virtual private network (VPN) server as a RADIUS client. | See "RADIUS Clients" in Network Policy Server Help.

Additional references

  • For more information about configuring remote access behind a NAT-enabled router, see http://go.microsoft.com/fwlink/?LinkId=89009 and http://go.microsoft.com/fwlink/?LinkId=89010.


Remote Access

Overview of remote access

By configuring Routing and Remote Access to act as a remote access server, you can connect remote or mobile workers to your organization's networks. Remote users can work as if their computers are physically connected to the network.

All services typically available to a LAN-connected user (including file and print sharing, Web server access, and messaging) are enabled by means of the remote access connection. Because drive letters and universal naming convention (UNC) names are fully supported by remote access, most commercial and custom applications work without modification.

A server running Routing and Remote Access provides two different types of remote access connectivity:

Virtual private networking

Virtual private networking (VPN) is the creation of secured, point-to-point connections across a private network or a public network such as the Internet. A VPN client uses special TCP/IP-based protocols called tunneling protocols to make a virtual call to a virtual port on a VPN server. The best example of virtual private networking is that of a VPN client who makes a VPN connection to a remote access server that is connected to the Internet. The remote access server answers the virtual call, authenticates the caller, and transfers data between the VPN client and the corporate network.

In contrast to dial-up networking, virtual private networking is always a logical, indirect connection between the VPN client and the VPN server over a public network, such as the Internet. To ensure privacy, you must encrypt data sent over the connection.

Dial-up networking

In dial-up networking, a remote access client makes a nonpermanent, dial-up connection to a physical port on a remote access server by using the service of a telecommunications provider, such as analog phone or ISDN. The best example of dial-up networking is that of a dial-up networking client that dials the phone number of one of the ports of a remote access server.

Dial-up networking over an analog phone or ISDN is a direct physical connection between the dial-up networking client and the dial-up networking server. You can encrypt data sent over the connection, but it is not required.


Virtual Private Networking

  • What Is VPN?

  • VPN Tunneling Protocols

  • VPN and Firewalls

  • Network Access Protection Enforcement for VPN

  • Configure a VPN Remote Access Server


What Is VPN?

Virtual private networks (VPNs) are point-to-point connections across a private or public network, such as the Internet. A VPN client uses special TCP/IP-based protocols, called tunneling protocols, to make a virtual call to a virtual port on a VPN server. In a typical VPN deployment, a client initiates a virtual point-to-point connection to a remote access server over the Internet. The remote access server answers the call, authenticates the caller, and transfers data between the VPN client and the organization’s private network.

To emulate a point-to-point link, data is encapsulated, or wrapped, with a header. The header provides routing information that enables the data to traverse the shared or public network to reach its endpoint. To emulate a private link, the data being sent is encrypted for confidentiality. Packets that are intercepted on the shared or public network are indecipherable without the encryption keys. The link in which the private data is encapsulated and encrypted is known as a VPN connection.

A VPN Connection

A VPN Connection

There are two types of VPN connections:

  • Remote access VPN

  • Site-to-site VPN

Remote access VPN

Remote access VPN connections enable users working at home or on the road to access a server on a private network using the infrastructure provided by a public network, such as the Internet. From the user’s perspective, the VPN is a point-to-point connection between the computer (the VPN client) and an organization’s server. The exact infrastructure of the shared or public network is irrelevant because it appears logically as if the data is sent over a dedicated private link.

Site-to-site VPN

Site-to-site VPN connections (also known as router-to-router VPN connections) enable organizations to have routed connections between separate offices or with other organizations over a public network while helping to maintain secure communications. A routed VPN connection across the Internet logically operates as a dedicated wide area network (WAN) link. When networks are connected over the Internet, as shown in the following figure, a router forwards packets to another router across a VPN connection. To the routers, the VPN connection operates as a data-link layer link.

A site-to-site VPN connection connects two portions of a private network. The VPN server provides a routed connection to the network to which the VPN server is attached. The calling router (the VPN client) authenticates itself to the answering router (the VPN server), and, for mutual authentication, the answering router authenticates itself to the calling router. In a site-to site VPN connection, the packets sent from either router across the VPN connection typically do not originate at the routers.

VPN Connecting Two Remote Sites Across the Internet

VPN Connecting Remote Sites Across the Internet

Properties of VPN connections

VPN connections that use PPTP, L2TP/IPsec, and SSTP have the following properties:

  • Encapsulation

  • Authentication

  • Data encryption

Encapsulation

With VPN technology, private data is encapsulated with a header that contains routing information that allows the data to traverse the transit network. For examples of encapsulation, see VPN Tunneling Protocols.

Authentication

Authentication for VPN connections takes three different forms:

  1. User-level authentication by using PPP authentication

    To establish the VPN connection, the VPN server authenticates the VPN client that is attempting the connection by using a Point-to-Point Protocol (PPP) user-level authentication method and verifies that the VPN client has the appropriate authorization. If mutual authentication is used, the VPN client also authenticates the VPN server, which provides protection against computers that are masquerading as VPN servers.

  2. Computer-level authentication by using Internet Key Exchange (IKE)

    To establish an Internet Protocol security (IPsec) security association, the VPN client and the VPN server use the IKE protocol to exchange either computer certificates or a preshared key. In either case, the VPN client and server authenticate each other at the computer level. Computer certificate authentication is highly recommended because it is a much stronger authentication method. Computer-level authentication is only performed for L2TP/IPsec connections.

  3. Data origin authentication and data integrity

    To verify that the data sent on the VPN connection originated at the other end of the connection and was not modified in transit, the data contains a cryptographic checksum based on an encryption key known only to the sender and the receiver. Data origin authentication and data integrity are only available for L2TP/IPsec connections.

Data encryption

To ensure confidentiality of the data as it traverses the shared or public transit network, the data is encrypted by the sender and decrypted by the receiver. The encryption and decryption processes depend on both the sender and the receiver using a common encryption key.

Intercepted packets sent along the VPN connection in the transit network are unintelligible to anyone who does not have the common encryption key. The length of the encryption key is an important security parameter. You can use computational techniques to determine the encryption key. However, such techniques require more computing power and computational time as the encryption keys get larger. Therefore, it is important to use the largest possible key size to ensure data confidentiality.


VPN Tunneling Protocols

Tunneling enables the encapsulation of a packet from one type of protocol within the datagram of a different protocol. For example, VPN uses PPTP to encapsulate IP packets over a public network, such as the Internet. A VPN solution based on Point-to-Point Tunneling Protocol (PPTP), Layer Two Tunneling Protocol (L2TP), or Secure Socket Tunneling Protocol (SSTP) can be configured.

PPTP, L2TP, and SSTP depend heavily on the features originally specified for Point-to-Point Protocol (PPP). PPP was designed to send data across dial-up or dedicated point-to-point connections. For IP, PPP encapsulates IP packets within PPP frames and then transmits the encapsulated PPP-packets across a point-to-point link. PPP was originally defined as the protocol to use between a dial-up client and a network access server.

PPTP

PPTP allows multiprotocol traffic to be encrypted and then encapsulated in an IP header to be sent across an IP network or a public IP network, such as the Internet. PPTP can be used for remote access and site-to-site VPN connections. When using the Internet as the public network for VPN, the PPTP server is a PPTP-enabled VPN server with one interface on the Internet and a second interface on the intranet.

Encapsulation

PPTP encapsulates PPP frames in IP datagrams for transmission over the network. PPTP uses a TCP connection for tunnel management and a modified version of Generic Routing Encapsulation (GRE) to encapsulate PPP frames for tunneled data. The payloads of the encapsulated PPP frames can be encrypted, compressed, or both. The following figure shows the structure of a PPTP packet containing an IP datagram.

Structure of a PPTP Packet Containing an IP Datagram

Structure of PPTP Packet Containing IP Datagram

Encryption

The PPP frame is encrypted with Microsoft Point-to-Point Encryption (MPPE) by using encryption keys generated from the MS-CHAP v2 or EAP-TLS authentication process. Virtual private networking clients must use the MS-CHAP v2 or EAP-TLS authentication protocol in order for the payloads of PPP frames to be encrypted. PPTP is taking advantage of the underlying PPP encryption and encapsulating a previously encrypted PPP frame.

L2TP

L2TP allows multiprotocol traffic to be encrypted and then sent over any medium that supports point-to-point datagram delivery, such as IP or asynchronous transfer mode (ATM). L2TP is a combination of PPTP and Layer 2 Forwarding (L2F), a technology developed by Cisco Systems, Inc. L2TP represents the best features of PPTP and L2F.

Unlike PPTP, the Microsoft implementation of L2TP does not use MPPE to encrypt PPP datagrams. L2TP relies on Internet Protocol security (IPsec) in Transport Mode for encryption services. The combination of L2TP and IPsec is known as L2TP/IPsec.

Both L2TP and IPsec must be supported by both the VPN client and the VPN server. Client support for L2TP is built in to the Windows Vista® and Windows XP remote access clients, and VPN server support for L2TP is built in to members of the Windows Server® 2008 and Windows Server 2003 family.

L2TP is installed with the TCP/IP protocol.

Encapsulation

Encapsulation for L2TP/IPsec packets consists of two layers:
First layer: L2TP encapsulation

A PPP frame (an IP datagram) is wrapped with an L2TP header and a UDP header.

Structure of an L2TP Packet Containing an IP Datagram

Structure of L2TP Packet Containing an IP Datagram
Second layer: IPsec encapsulation

The resulting L2TP message is then wrapped with an IPsec Encapsulating Security Payload (ESP) header and trailer, an IPsec Authentication trailer that provides message integrity and authentication, and a final IP header. In the IP header is the source and destination IP address that corresponds to the VPN client and VPN server.

Encryption of L2TP Traffic with IPsec ESP

Encryption of L2TP Traffic with IPsec ESP

Encryption

The L2TP message is encrypted with either Data Encryption Standard (DES) or Triple DES (3DES) by using encryption keys generated from the Internet Key Exchange (IKE) negotiation process.

SSTP

Secure Socket Tunneling Protocol (SSTP) is a new tunneling protocol that uses the HTTPS protocol over TCP port 443 to pass traffic through firewalls and Web proxies that might block PPTP and L2TP/IPsec traffic. SSTP provides a mechanism to encapsulate PPP traffic over the Secure Sockets Layer (SSL) channel of the HTTPS protocol. The use of PPP allows support for strong authentication methods, such as EAP-TLS. SSL provides transport-level security with enhanced key negotiation, encryption, and integrity checking.

When a client tries to establish a SSTP-based VPN connection, SSTP first establishes a bidirectional HTTPS layer with the SSTP server. Over this HTTPS layer, the protocol packets flow as the data payload.

Encapsulation

SSTP encapsulates PPP frames in IP datagrams for transmission over the network. SSTP uses a TCP connection (over port 443) for tunnel management as well as PPP data frames.

Encryption

The SSTP message is encrypted with the SSL channel of the HTTPS protocol.

Choosing between tunneling protocols

When choosing between PPTP, L2TP/IPsec, and SSTP remote access VPN solutions, consider the following:

  • PPTP can be used with a variety of Microsoft clients including Microsoft Windows 2000, Windows XP, Windows Vista, and Windows Server 2008. Unlike L2TP/IPsec, PPTP does not require the use of a public key infrastructure (PKI). By using encryption, PPTP-based VPN connections provide data confidentiality (captured packets cannot be interpreted without the encryption key). PPTP-based VPN connections, however, do not provide data integrity (proof that the data was not modified in transit) or data origin authentication (proof that the data was sent by the authorized user).

  • L2TP can only be used with client computers running Windows 2000, Windows XP, or Windows Vista. L2TP supports either computer certificates or a preshared key as the authentication method for IPsec. Computer certificate authentication, the recommended authentication method, requires a PKI to issue computer certificates to the VPN server computer and all VPN client computers. By using IPsec, L2TP/IPsec VPN connections provide data confidentiality, data integrity, and data authentication.

    Unlike PPTP and SSTP, L2TP/IPsec enables machine authentication at the IPsec layer and user level authentication at the PPP layer.

  • SSTP can only be used with client computers running Windows Vista Service Pack 1 (SP1) or Windows Server 2008. By using SSL, SSTP VPN connections provide data confidentiality, data integrity, and data authentication.

  • All three tunnel types carry PPP frames on top of the network protocol stack. Therefore, the common features of PPP, such as authentication schemes, Internet Protocol version 4 (IPv4) and Internet Protocol version 6 (IPV6) negotiation, and Network Access Protection (NAP), remain the same for the three tunnel types.

Additional references

  • PPTP is documented in RFC 2637 in the IETF RFC Database

  • L2TP is documented in RFC 2661 in the IETF RFC Database

  • L2TP/IPsec is documented in RFC 3193 in the IETF RFC Database


VPN and Firewalls

When designing a virtual private network (VPN) remote access solution, choose between the following two options for server placement. Each option has different design requirements.

  • VPN server behind the firewall. The firewall is attached to the Internet, with the VPN server between the firewall and the intranet. This is the placement used in a perimeter network configuration, in which one firewall is positioned between the VPN server and the intranet, with another between the VPN server and the Internet.

  • VPN server in front of the firewall. The VPN server is connected to the Internet, with the firewall between the VPN server and the intranet.

VPN server behind a firewall

In the configuration shown in the following figure, the firewall is connected to the Internet and the VPN server is another intranet resource connected to the perimeter network, also known as a screened subnet. The perimeter network is an IP network segment that typically contains resources available to Internet users, such as Web servers and FTP servers. The VPN server has an interface on the perimeter network and an interface on the intranet.

In this approach, the firewall must be configured with input and output filters on its Internet and perimeter network interfaces to allow the passing of tunnel maintenance traffic and tunneled data to the VPN server. Additional filters can allow the passing of traffic to Web servers, FTP servers, and other types of servers on the perimeter network. As an added layer of security, the VPN server should also be configured with PPTP, SSTP, or L2TP/IPsec packet filters on its perimeter network interface as described in “VPN server in front of a firewall” in this topic.

Because the firewall does not have the encryption keys for each VPN connection, it can only filter on the plaintext headers of the tunneled data, meaning that all tunneled data passes through the firewall. However, this is not a security concern because the VPN connection requires an authentication process that prevents unauthorized access beyond the VPN server.

VPN Server Behind the Firewall

VPN Server Behind the Firewall

Packet filters for a VPN server behind a firewall

If the VPN server is behind a firewall, packet filters must be configured for both an Internet interface and a perimeter network interface. In this scenario, the firewall is connected to the Internet, and the VPN server is an intranet resource that is connected to the perimeter network. The VPN server has an interface on both the perimeter network and the Internet.

PPTP connections for the Internet interface of the firewall

The following table shows the inbound and outbound PPTP filters on the Internet interface of the firewall.

Filter Type | Filter | Action
Inbound | Destination IP address = Perimeter network interface of VPN server TCP destination port = 1723 (0x6BB) | Allows PPTP tunnel maintenance traffic from the PPTP client to the PPTP server.
Inbound | Destination IP address = Perimeter network interface of VPN server IP Protocol ID = 47 (0x2F) | Allows tunneled PPTP data from the PPTP client to the PPTP server.
Inbound | Destination IP address = Perimeter network interface of VPN server TCP source port = 1723 (0x6BB) | Required only when the VPN server is acting as a VPN client (a calling router) in a site-to-site VPN connection. If all traffic from TCP port 1723 is allowed to reach the VPN server, network attacks can originate from sources on the Internet that use this port. Administrators should only use this filter in conjunction with the PPTP filters that are also configured on the VPN server.
Outbound | Source IP address = Perimeter network interface of VPN server TCP source port = 1723 (0x6BB) | Allows PPTP tunnel maintenance traffic from the PPTP server to the PPTP client.
Outbound | Source IP address = Perimeter network interface of VPN server IP Protocol ID = 47 (0x2F) | Allows tunneled PPTP data from the PPTP server to the PPTP client.
Outbound | Source IP address = Perimeter network interface of VPN server TCP destination port = 1723 (0x6BB) | Required only when the VPN server is acting as a VPN client (a calling router) in a site-to-site VPN connection. If all traffic from the VPN server is allowed to reach TCP port 1723, network attacks can originate from sources on the Internet using this port. Administrators should only use this filter in conjunction with the PPTP filters that are also configured on the VPN server.

PPTP connections for the perimeter network interface of the firewall

The following table shows the inbound and outbound PPTP filters on the perimeter network interface of the firewall.

Filter Type | Filter | Action
Inbound | Source IP address = Perimeter network interface of VPN server TCP source port = 1723 (0x6BB) | Allows PPTP tunnel maintenance traffic from the VPN server to the VPN client.
Inbound | Source IP address = Perimeter network interface of VPN server IP Protocol ID = 47 (0x2F) | Allows tunneled PPTP data from the VPN server to the VPN client.
Inbound | Source IP address = Perimeter network interface of VPN server TCP destination port = 1723 (0x6BB) | Required only when the VPN server is acting as a VPN client (a calling router) in a site-to-site VPN connection. If all traffic from TCP port 1723 is allowed to reach the VPN server, network attacks can originate from sources on the Internet using this port.
Outbound | Destination IP address = Perimeter network interface of VPN server TCP source port = 1723 (0x6BB) | Allows PPTP tunnel maintenance traffic from the PPTP client to the PPTP server.
Outbound | Destination IP address = Perimeter network interface of VPN server IP Protocol ID = 47 (0x2F) | Allows tunneled PPTP data from the PPTP client to the PPTP server.
Outbound | Destination IP address = Perimeter network interface of VPN server TCP source port = 1723 (0x6BB) | Required only when the VPN server is acting as a VPN client (a calling router) in a site-to-site VPN connection. If all traffic from the VPN server is allowed to reach TCP port 1723, network attacks can originate from sources on the Internet using this port.

SSTP connections for the Internet interface of the firewall

The following table shows the inbound and outbound SSTP filters on the Internet interface of the firewall.

Filter Type | Filter | Action
Inbound | Destination IP address = Perimeter network interface of VPN server TCP destination port = 443 (0x1BB) | Allows SSTP (HTTPS over SSL) traffic to the VPN server.
Outbound | Source IP address = Perimeter network interface of VPN server TCP source port = 443 (0x1BB) | Allows SSTP traffic from the VPN server.

SSTP connections for the perimeter network interface of the firewall

The following table shows the inbound and outbound SSTP filters on the perimeter network interface of the firewall.

Filter Type | Filter | Action
Inbound | Source IP address = Perimeter network interface of VPN server TCP source port = 443 (0x1BB) | Allows SSTP (HTTPS over SSL) traffic from the VPN server to the VPN client.
Outbound | Destination IP address = Perimeter network interface of VPN server TCP source port = 443 (0x1BB) | Allows SSTP traffic from the SSTP client to the SSTP server.

L2TP/IPsec connections for the Internet interface of the firewall

The following table shows the inbound and outbound L2TP/IPsec filters on the Internet interface of the firewall.

Filter Type | Filter | Action
Inbound | Destination IP address = Perimeter network interface of VPN server UDP destination port = 500 (0x1F4) | Allows IKE traffic to the VPN server.
Inbound | Destination IP address = Perimeter network interface of VPN server UDP destination port = 4500 (0x1194) | Allows IPsec NAT-T traffic to the VPN server.
Inbound | Destination IP address = Perimeter network interface of VPN server IP Protocol ID = 50 (0x32) | Allows IPsec ESP traffic to the VPN server.
Outbound | Source IP address = Perimeter network interface of VPN server UDP source port = 500 (0x1F4) | Allows IKE traffic from the VPN server.
Outbound | Source IP address = Perimeter network interface of VPN server UDP source port = 4500 (0x1194) | Allows IPsec NAT-T traffic from the VPN server.
Outbound | Source IP address = Perimeter network interface of VPN server IP Protocol ID = 50 (0x32) | Allows IPsec ESP traffic from the VPN server.

No filters are required for L2TP traffic at UDP port 1701. All L2TP traffic at the firewall, including tunnel maintenance and tunneled data, is encrypted with IPsec ESP.

L2TP/IPsec connections for the perimeter network interface of the firewall

The following table shows the inbound and outbound L2TP/IPsec filters on the perimeter network interface of the firewall.

Filter Type | Filter | Action
Inbound | Source IP address = Perimeter network interface of VPN server UDP source port = 500 (0x1F4) | Allows IKE traffic from the VPN server.
Inbound | Source IP address = Perimeter network interface of VPN server UDP source port = 4500 (0x1194) | Allows IPsec NAT-T traffic from the VPN server.
Inbound | Source IP address = Perimeter network interface of VPN server IP Protocol ID = 50 (0x32) | Allows IPsec ESP traffic from the VPN server.
Outbound | Destination IP address = Perimeter network interface of VPN server UDP destination port = 500 (0x1F4) | Allows IKE traffic to the VPN server.
Outbound | Destination IP address = Perimeter network interface of VPN server UDP destination port = 4500 (0x1194) | Allows IPsec NAT-T traffic to the VPN server.
Outbound | Destination IP address = Perimeter network interface of VPN server IP Protocol ID = 50 (0x32) | Allows IPsec ESP traffic to the VPN server.

VPN server in front of a firewall

With the VPN server in front of the firewall and connected to the Internet, as shown in the following figure, administrators need to add packet filters to the Internet interface that allow only VPN traffic to and from the IP address of the VPN server’s interface on the Internet.

For inbound traffic, when the tunneled data is decrypted by the VPN server, it is forwarded to the firewall, which uses its filters to allow the traffic to be forwarded to intranet resources. Because the only traffic that is crossing the VPN server is traffic generated by authenticated VPN clients, firewall filtering in this scenario can be used to prevent VPN users from accessing specified intranet resources.

Because the only Internet traffic allowed on the intranet must go through the VPN server, this approach also prevents the sharing of intranet resources with non-VPN Internet users.

VPN Server in Front of the Firewall

VPN Server in Front of the Firewall

Packet filters for a VPN server in front of a firewall

When a VPN server is in front of a firewall and connected to the Internet, inbound and outbound packet filters on the VPN server must be configured to allow only VPN traffic to and from the IP address of the VPN server’s Internet interface. Use this configuration if the VPN server is in a perimeter network, with one firewall positioned between the VPN server and the intranet and another between the VPN server and the Internet.

All of the following packet filters are configured, using the Routing and Remote Access snap-in, as IP packet filters on the Internet interface. Depending on the configuration decisions made during the running of the Routing and Remote Access Server Setup Wizard, these packet filters might already be configured.

PPTP connections for the inbound and outbound filters

The following table shows the VPN server’s inbound and outbound filters for PPTP.

Filter Type | Filter | Action
Inbound | Destination IP address = Internet interface of VPN server Subnet mask = 255.255.255.255 TCP destination port = 1723 | Allows PPTP tunnel maintenance to the VPN server.
Inbound | Destination IP address = Internet interface of VPN server Subnet mask = 255.255.255.255 IP Protocol ID = 47 | Allows tunneled PPTP data to the VPN server.
Inbound | Destination IP address = Internet interface of VPN server Subnet mask = 255.255.255.255 TCP (established) source port = 1723 | Required only when the VPN server is acting as a VPN client (a calling router) in a site-to-site VPN connection. Accepts TCP traffic only when a VPN server initiates the TCP connection.
Outbound | Source IP address = Internet interface of VPN server Subnet mask = 255.255.255.255 TCP source port = 1723 | Allows PPTP tunnel maintenance traffic from the VPN server.
Outbound | Source IP address = Internet interface of VPN server Subnet mask = 255.255.255.255 IP Protocol ID = 47 | Allows tunneled PPTP data from the VPN server.
Outbound | Source IP address = Internet interface of VPN server Subnet mask = 255.255.255.255 TCP (established) destination port = 1723 | Required only when the VPN server is acting as a VPN client (a calling router) in a site-to-site VPN connection. Sends TCP traffic only when a VPN server initiates the TCP connection.

SSTP connections

The following table shows the VPN server’s inbound and outbound filters for SSTP.

Filter Type | Filter | Action
Inbound | Destination IP address = Internet interface of VPN server Subnet mask = 255.255.255.255 TCP destination port = 443 | Allows SSTP (HTTPS over SSL) traffic to the VPN server.
Outbound | Source IP address = Internet interface of VPN server Subnet mask = 255.255.255.255 TCP source port = 443 | Allows SSTP traffic from the VPN server.

L2TP/IPsec connections

The following table shows the VPN server’s inbound and outbound filters for L2TP/IPsec.

Filter Type | Filter | Action
Inbound | Destination IP address = Internet interface of VPN server Subnet mask = 255.255.255.255 UDP destination port = 500 | Allows IKE traffic to the VPN server.
Inbound | Destination IP address = Internet interface of VPN server Subnet mask = 255.255.255.255 UDP destination port = 1701 | Allows L2TP traffic from the VPN client to the VPN server.
Inbound | Destination IP address = Internet interface of VPN server Subnet mask = 255.255.255.255 UDP destination port = 4500 | Allows IPsec NAT-T traffic from the VPN client to the VPN server.
Outbound | Source IP address = Internet interface of VPN server Subnet mask = 255.255.255.255 UDP source port = 500 | Allows IKE traffic from the VPN server.
Outbound | Source IP address = Internet interface of VPN server Subnet mask = 255.255.255.255 UDP source port = 1701 | Allows L2TP traffic from the VPN server to the VPN client.
Outbound | Source IP address = Internet interface of VPN server Subnet mask = 255.255.255.255 UDP source port = 4500 | Allows IPsec NAT-T traffic from the VPN server to the VPN client.

Additional references

  • Packet Filtering


Network Access Protection Enforcement for VPN

Network Access Protection (NAP) is a new technology introduced in Windows Vista® and Windows Server® 2008. NAP includes client components and server components that allow you to create and enforce health requirement policies that define the required software and system configurations for computers that connect to your network. NAP enforces health requirements by inspecting and assessing the health of client computers, limiting network access when client computers are deemed noncompliant, and remediating noncompliant client computers for unlimited network access. NAP enforces health requirements on client computers that are attempting to connect to a network. NAP also provides ongoing health compliance enforcement while a compliant client computer is connected to a network.

NAP enforcement occurs at the moment when client computers attempt to access the network through network access servers, such as a virtual private network (VPN) server running Routing and Remote Access, or when clients attempt to communicate with other network resources.

NAP enforcement for VPN

NAP enforcement for VPN is deployed with a VPN enforcement server component and a VPN enforcement client component. Using NAP enforcement for VPN, VPN servers can enforce health policy when client computers attempt to connect to the network using a VPN connection. VPN enforcement provides strong limited network access for all computers accessing the network through a VPN connection.

Note

VPN enforcement is different from Network Access Quarantine Control, which is a feature in Windows Server 2003 and Internet Security and Acceleration (ISA) Server 2004.

Requirements

To deploy NAP with VPN, you must configure the following:

  • Install and configure Routing and Remote Access service as a VPN server.

  • In NPS, configure VPN servers as RADIUS clients. Also configure connection request policy, network policy, and NAP health policy. You can configure these policies individually using the NPS console, or you can use the New Network Access Protection wizard.

  • Enable the NAP VPN enforcement client and the NAP service on NAP-capable client computers.

  • Configure the Windows Security Health Validator or install and configure other system health agents (SHAs) and system health validators (SHVs), depending on your NAP deployment.

  • If you are using PEAP-TLS or EAP-TLS with smartcards or certificates, deploy a public key infrastructure (PKI) with Active Directory® Certificate Services (AD CS).

  • If you are using PEAP-MS-CHAP v2, issue server certificates with either AD CS or purchase server certificates from a trusted root certification authority (CA).

If Routing and Remote Access service configured as a VPN server is not installed on the local computer, you must also configure the following:

  • Install Network Policy Server (NPS) on the computer that is running Routing and Remote Access Service configured as a VPN server.

  • Configure NPS on the remote Routing and Remote Access-NPS server as a RADIUS proxy to forward connection requests to the local NPS server.


Configure a VPN Remote Access Server

The configuration of a virtual private network (VPN) remote access server involves the following tasks:

  • Configure the Server as a VPN Remote Access Server

  • ConfigureTCP/IP on the VPN Server

  • Configure Name Resolution on a VPN Server


Configure the Server as a VPN Remote Access Server

For information about using Server Manager to install the Routing and Remote Access service, see Install and Enable the Routing and Remote Access Service. To configure the server as a virtual private network (VPN) remote access server, use the Routing and Remote Access Server Setup Wizard and select Remote access (dial-up or VPN).

Membership in the local Administrators group, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477.

Additional considerations


ConfigureTCP/IP on the VPN Server

After configuring the server as a remote access server, configure the TCP/IP settings for the Internet or perimeter network interface and for the intranet interface.

Note

Because of routing issues related to configuring TCP/IP automatically, it is recommended that you not configure a VPN server as a DHCP client. Instead, manually configure TCP/IP on the intranet interfaces of a VPN server.

Manually configure the Internet or perimeter network interface of the VPN server with a default gateway. Configure the TCP/IP settings with a public IP address, a subnet mask, and the default gateway of either the firewall (if the VPN server is connected to a perimeter network) or an ISP router (if the VPN server is connected directly to the Internet).

Configuring TCP/IP on the VPN server

Configuring the Internet interface

Configuring the intranet interface

To configure TCP/IP for the Internet or perimeter network interface

  1. In Control Panel, double-click Network Connections, and then double-click the network adapter for the Internet or perimeter network interface.

  2. In the network adapter status dialog box (for example, Local Area Connection Status), click Properties.

  3. Select Internet Protocol (TCP/IP), and then click Properties.

  4. On the General tab, configure the IP address, subnet mask, and default gateway.

    The IP address must be a public IP address assigned by an ISP. As an option, you can configure the VPN server with a private IP address but assign it a published static IP address by which it is known on the Internet. When packets are sent to and from the VPN server, a network address translation (NAT) device that is positioned between the Internet and the VPN server translates the published IP address to the private IP address.

    When you configure a VPN connection, give your VPN servers names that can be resolved to IP addresses using DNS.

  5. Click Advanced to display the Advanced TCP/IP Settings dialog box.

  6. To prevent the VPN server from dynamically registering the public IP address of its Internet interface with an intranet DNS server, on the DNS tab, clear the Register this connection’s addresses in DNS check box. This check box is cleared by default.

  7. To prevent the VPN server from registering the public IP address of its Internet interface with intranet WINS servers, on the WINS tab, select the Disable NetBIOS over TCP/IP check box. This check box is selected by default.

When you configure TCP/IP for the intranet interface of the VPN server, do not configure the default gateway on the intranet connection. This will prevent default route conflicts with the default route pointing to the Internet.

To configure TCP/IP for the intranet interface

  1. In Control Panel, double-click Network Connections, and then double-click the network adapter for intranet interface.

  2. In the network adapter status dialog box (for example, Local Area Connection 2 Status), click Properties.

  3. Select Internet Protocol (TCP/IP), and then click Properties.

  4. On the General tab, configure the IP address, subnet mask, and DNS server address.

  5. Click Advanced to display the Advanced TCP/IP Settings dialog box.

  6. On the WINS tab, configure the IP addresses of your WINS servers.


Configure Name Resolution on a VPN Server

If you use Domain Name System (DNS) to resolve intranet host names or Windows Internet Name Service (WINS) to resolve intranet NetBIOS names, manually configure the virtual private network (VPN) server with the IP addresses of the appropriate DNS and WINS servers.

During the Point-to-Point Protocol (PPP) connection setup process, VPN clients receive the IP addresses of DNS and WINS servers. By default, the VPN clients inherit the DNS and WINS server IP addresses configured on the VPN server. However, VPN clients that are capable of sending a DHCPINFORM message (computers running Windows Server® 2008, Windows Server 2003, Windows 2000, or Windows XP) get their DNS and WINS server IP addresses from the DHCP server.


Dial-Up Networking

  • What Is Dial-Up Networking?

  • Configure a Dial-Up Remote Access Server


What Is Dial-Up Networking?

What is dial-up remote access?

Dial-up remote access is a remote access technology that is available as part of Routing and Remote Access included in Windows Server® 2008.

Organizations require a simple solution that allows employees to remotely access their corporate e-mail accounts and shared files from home or from other locations outside the corporate network. Dial-up remote access provides the solution by enabling a remote access client to use the wide area network (WAN) infrastructure to connect to a remote access server.

Dial-up remote access vs. VPN

Windows Server 2008 remote access provides two different types of remote access connectivity: dial-up remote access and virtual private network (VPN) remote access.

  • With dial-up remote access, a remote access client uses the telecommunications infrastructure to create a temporary physical circuit or a virtual circuit to a port on a remote access server. After the physical or virtual circuit is created, the rest of the connection parameters can be negotiated.

  • With virtual private network remote access, a VPN client uses an IP network, such as the Internet, to create a virtual point-to-point connection with a remote access server acting as the VPN server. After the virtual point-to-point connection is created, the rest of the connection parameters can be negotiated.

Demand-dial routing

Demand-dial routing is not a technology, but a process by which packets are forwarded across a Point-to-Point Protocol (PPP) link. Demand-dial routing is used by remote access technologies—dial-up remote access and VPN, as well as routing technologies—unicast routing, multicast routing, and network address translation (NAT). For more information about demand-dial routing, see What Is Demand-Dial Routing?.

Components of a dial-up remote access connection

A dial-up remote access connection contains the following components:

  • Remote access client

  • Remote access server

  • WAN infrastructure

Components of a Dial-up Remote Access Connection

Components of a Dial-up Remote Access Connection

Remote access client

Remote access clients running Windows Server 2008, Windows Server 2003, Windows XP, Windows 2000, Windows NT 4.0, Windows Millennium Edition, and Windows 98 can connect to a remote access server running Windows Server 2008. Almost any PPP remote access client, including UNIX and Macintosh, can connect to a remote access server running Windows Server 2008.

Remote access server

The remote access server running Windows Server 2008 accepts dial-up connections and forwards packets between remote access clients and the network to which the remote access server is attached.

Dial-up equipment and the WAN infrastructure

The physical or logical connection between the remote access server and the remote access client is facilitated by dial-up equipment installed at the remote access client, the remote access server, and the WAN infrastructure. The nature of the dial-up equipment and WAN infrastructure varies, depending on the type of connection. The most common methods for dial-up remote access include:

  • Public Switched Telephone Network (PSTN)

  • Integrated Services Digital Network (ISDN)

PSTN

PSTN, also known as Plain Old Telephone Service (POTS) is the analog phone system designed to carry the minimum frequencies required to distinguish human voices.

Dial-up equipment consists of an analog modem at the remote access client and at least one analog modem at the remote access server. For large organizations, the remote access server is attached to a modem bank containing up to hundreds of modems. Because PSTN was not designed for data transmission, its transmission bit rate is limited compared to other connection methods.

Standard PSTN Connection

Standard PSTN Connection
Digital links and V.90

The maximum bit rate of PSTN depends on the range of frequencies being passed by PSTN switches and the signal-to-noise ratio of the connection. The modern-day analog phone system is only analog on the local loop, the set of wires that connect the customer to the central office (CO) PSTN switch. After the analog signal reaches the PSTN switch, it is converted to a digital signal. The analog-to-digital conversion introduces noise on the connection known as quantization noise.

When a remote access server is connected to a CO by using a digital switch based on T-Carrier or ISDN rather than an analog PSTN switch, there is no analog-to-digital conversion when the remote access server sends information to the remote access client. Because there is no quantization noise in the path back to the remote access client, there is a higher signal-to-noise ratio and, therefore, a higher maximum bit rate.

With this technology, called V.90, remote access clients can send data at 33.6 Kbps and receive data at 56 Kbps. In the United States, the maximum receive bit rate is 53 Kbps due to Federal Communications Commission (FCC) power rules.

To obtain V.90 speeds, the following must be true:

  • The remote access client must be using a V.90 modem.

  • The remote access server must be using a V.90 digital switch and be connected to PSTN using a digital link, such as T-Carrier or ISDN.

  • There cannot be any analog-to-digital conversions in the path from the remote access server to the remote access client.

PSTN Connection with V.90

PSTN Connection with V.90


Configure a Dial-Up Remote Access Server

You can use a server running Routing and Remote Access to provide dial-up access to your corporate intranet. If you want the remote access server to support multiple, dial-up networking TCP/IP-based connections, complete the following steps:

  • Configure the connection to the intranet.

  • Configure the connection to the dial-up networking clients.

  • Configure the dial-in ports.

  • Configure the remote access server.

  • Configure multicast support.

  • Configure network policies.

The following illustration shows the elements of a server running Routing and Remote Access that provides dial-up access to a corporate intranet.

Remote access server provides access to intranet

Additional references

  • For more information about configuring a dial-up remote access server, see http://go.microsoft.com/fwlink/?LinkId=89010.


Configure Ports for Remote Access

A server running Routing and Remote Access treats the installed networking equipment as a series of devices and ports.

  • A device represents hardware or software that can create physical or logical point-to-point connections.

  • A port is a communication channel that can support a single point-to-point connection.

Membership in the local Administrators group, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477.

To configure ports for remote access

  1. Open Routing and Remote Access.

  2. In the console tree, right-click Ports.

    Where?

    • Routing and Remote Access/server name/Ports

  3. Click Properties.

  4. In the Ports Properties dialog box, click a device, and then click Configure.

  5. In the Configure Device dialog box, do one or more of the following:

    • To enable remote access, select the Remote access connections (inbound only) check box.

    • To enable demand-dial routing, select the Demand-dial routing connections (inbound and outbound) check box.

Additional references

  • Devices and Ports


Create a Static IP Address Pool

You can configure the remote access server to use a static pool of IP addresses for allocation to TCP/IP-based remote access and demand-dial connections.

Membership in the local Administrators group, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477.

To create a static IP address pool

  1. Open Routing and Remote Access.

  2. Right-click the server name for which you want to create a static IP address pool, and then click Properties.

  3. On the IPv4 tab, click Static address pool, and then click Add.

  4. In Start IP address, type a starting IP address, and then either type an ending IP address for the range in End IP address, or type the number of IP addresses in the range in Number of addresses.

  5. Click OK, and then repeat steps 3 and 4 for as many ranges as you need to add.

Additional considerations

  • If the static IP address pool consists of ranges of IP addresses that are for a separate subnet, then you need to either enable an IP routing protocol on the remote access server computer or add static IP routes consisting of the {IP Address, Mask} of each range to the routers of the intranet. If the routes are not added, then remote access clients cannot receive traffic from resources on the intranet.


Using Routing and Remote Access Servers with DHCP

The DHCP Server service can be deployed along with the Routing and Remote Access service to provide remote access clients with a dynamically assigned IP address during connection. When these services are used together on the same server computer, the information provided during dynamic configuration is provided in a way that is different from typical DHCP configuration for LAN-based clients.

In local area network (LAN) environments, DHCP clients negotiate and receive the following configuration information, based entirely on settings configured in the DHCP console for the DHCP server:

  • A leased IP address provided from the available address pool of an active scope on the DHCP server. The DHCP server directly manages and distributes the address to the LAN-based DHCP client.

  • Additional parameters and other configuration information provided through assigned DHCP options in the address lease. The values and list of options correspond to option types configured and assigned on the DHCP server.

When a Routing and Remote Access server provides dynamic configuration for dial-up clients, it first performs the following steps:

  • When the server running Routing and Remote Access starts with the Use DHCP to assign remote TCP/IP addresses option, it instructs the DHCP client to obtain 10 IP addresses from a DHCP server.

  • The remote access server uses the first of these 10 IP addresses obtained from the DHCP server for the remote access server interface.

  • The remaining nine addresses are allocated to TCP/IP-based clients as they dial in to establish a session with the remote access server.

IP addresses that are freed when remote access clients disconnect are reused. When all 10 IP addresses are used, the remote access server obtains 10 more from a DHCP server. When the Routing and Remote Access service is stopped, all IP addresses obtained through DHCP are released.

When the Routing and Remote Access server uses this type of proactive caching of DHCP address leases for dial-up clients, it records the following information for each lease response it obtains from the DHCP server:

  • The IP address of the DHCP server.

  • The client leased IP address (for later distribution to the Routing and Remote Access client).

  • The time at which the lease was obtained.

  • The time at which the lease expires.

  • The duration of the lease.

All other DHCP option information returned by the DHCP server (such as server, scope, or reservation options) is discarded. When the client dials in to the server and requests an IP address (that is, when Server Assigned IP Address is selected), it uses a cached DHCP lease to provide the dial-up client with dynamic IP address configuration.

When the IP address is provided to the dial-up client, the client is unaware that the IP address has been obtained through this intermediate process between the DHCP server and the Routing and Remote Access server. The Routing and Remote Access server maintains the lease on behalf of the client. Therefore, the only information that the client receives from the DHCP server is the IP address lease.

In dial-up environments, DHCP clients negotiate and receive dynamic configuration using the following modified behavior:

  • A leased IP address from the Routing and Remote Access server cache of DHCP scope addresses. The Routing and Remote Access server obtains and renews its cached address pool with the DHCP server.

  • If additional parameters and other configuration information provided through assigned DHCP options in the address lease are normally provided by the DHCP server, this information is returned to the Routing and Remote Access client based on TCP/IP properties configured on the Routing and Remote Access server.

Additional considerations

  • DHCP servers running Windows Server® 2008 provide a predefined user class, the Default Routing and Remote Access Class, for assigning options that are provided only to Routing and Remote Access clients.


Remote Access Authentication Methods

  • Comparing Authentication Methods

  • EAP

  • MS-CHAP v2

  • CHAP

  • PAP

  • Unauthenticated Access


Comparing Authentication Methods

PPP Authentication Protocols

Remote access in Windows Server® 2008 supports the Point-to-Point Protocol (PPP) authentication protocols listed in the following table.

Protocol | Description | Security Level
PAP (Password Authentication Protocol) | Uses plaintext passwords. Typically used if the remote access client and remote access server cannot negotiate a more secure form of validation. | The least secure authentication protocol. Does not protect against replay attacks, remote client impersonation, or remote server impersonation.
CHAP (Challenge Handshake Authentication Protocol) | A challenge-response authentication protocol that uses the industry-standard Message Digest 5 (MD5) hashing scheme to encrypt the response. | An improvement over PAP in that the password is not sent over the PPP link. Requires a plaintext version of the password to validate the challenge response. Does not protect against remote server impersonation.
MS-CHAP v2 (Microsoft Challenge Handshake Authentication Protocol version 2) | An upgrade of MS-CHAP. Two-way authentication, also known as mutual authentication, is provided. The remote access client receives verification that the remote access server that it is dialing in to has access to the user’s password. | Provides stronger security than CHAP.
EAP (Extensible Authentication Protocol) | Allows for arbitrary authentication of a remote access connection through the use of authentication schemes, known as EAP types. | Offers the strongest security by providing the most flexibility in authentication variations.


EAP

With the Extensible Authentication Protocol (EAP), an arbitrary authentication mechanism authenticates a remote access connection. The exact authentication scheme to be used is negotiated by the remote access client and the authenticator (either the remote access server or the Remote Authentication Dial-In User Service [RADIUS] server). Routing and Remote Access includes support for EAP-TLS by default. You can plug in other EAP modules to the server running Routing and Remote Access to provide other EAP methods.

EAP allows for an open-ended conversation between the remote access client and the authenticator. The conversation consists of authenticator requests for authentication information and the responses from the remote access client. For example, when EAP is used with security token cards, the authenticator can separately query the remote access client for a name, PIN, and card token value. As each query is asked and answered, the remote access client passes through another level of authentication. When all questions have been answered satisfactorily, the remote access client is authenticated.

An EAP authentication scheme is known as an EAP type. Both the remote access client and the authenticator must support the same EAP type for successful authentication to occur.

EAP-TLS

EAP-Transport Level Security (EAP-TLS) is an EAP type that is used in certificate-based security environments. If you are using smart cards for remote access authentication, you must use the EAP-TLS authentication method. The EAP-TLS exchange of messages provides mutual authentication, negotiation of the encryption method, and encrypted key determination between the remote access client and the authenticator. EAP-TLS provides the strongest authentication and key determination method.

EAP-TLS is supported only on servers that are running Routing and Remote Access, that are configured to use Windows Authentication or RADIUS, and that are members of a domain. A remote access server running as a stand-alone server or a member of a workgroup does not support EAP-TLS.

EAP-RADIUS

EAP-RADIUS is not an EAP type, but the passing of EAP messages of any EAP type by an authenticator to a RADIUS server for authentication. For example, for a remote access server that is configured for RADIUS authentication, the EAP messages sent between the remote access client and remote access server are encapsulated and formatted as RADIUS messages between the remote access server and the RADIUS server.

EAP-RADIUS is used in environments where RADIUS is the authentication provider. An advantage of using EAP-RADIUS is that EAP types do not need to be installed at each remote access server, only at the RADIUS server. In the case of a server running Network Policy Server (NPS), you only need to install EAP types on the NPS server.

In a typical use of EAP-RADIUS, a server running Routing and Remote Access is configured to use EAP and to use an NPS server for authentication. When a connection is made, the remote access client negotiates the use of EAP with the remote access server. When the client sends an EAP message to the remote access server, the remote access server encapsulates the EAP message as a RADIUS message and sends it to its configured NPS server. The NPS server processes the EAP message and sends a RADIUS-encapsulated EAP message back to the remote access server. The remote access server then forwards the EAP message to the remote access client. In this configuration, the remote access server is only a pass-through device. All processing of EAP messages occurs at the remote access client and the NPS server.

Routing and Remote Access can be configured to authenticate locally, or to a RADIUS server. If Routing and Remote Access is configured to authenticate locally, all EAP methods will be authenticated locally. If Routing and Remote Access is configured to authenticate to a RADIUS server, all EAP messages will be forwarded to the RADIUS server with EAP-RADIUS.

Enabling EAP

To enable EAP-based authentication, you must do the following:

  1. Enable EAP as an authentication protocol on the remote access server.

  2. Enable EAP and, if required, configure the EAP type on the appropriate network policy.

  3. Enable and configure EAP on the remote access client.

Additional considerations

  • Make sure your network access server (NAS) supports EAP before you enable it on a network policy on an NPS server. For more information, see your NAS documentation.


MS-CHAP v2

Microsoft Challenge Handshake Authentication Protocol (MS-CHAP v2) is a one-way encrypted password, mutual authentication process that works as follows:

  1. The authenticator (the remote access server or the NPS server) sends a challenge to the remote access client that consists of a session identifier and an arbitrary challenge string.

  2. The remote access client sends a response that contains:

    • The user name.

    • An arbitrary peer challenge string.

    • A one-way encryption of the received challenge string, the peer challenge string, the session identifier, and the user password.

  3. The authenticator checks the response from the client and sends back a response containing:

    • An indication of the success or failure of the connection attempt.

    • An authenticated response based on the sent challenge string, the peer challenge string, the encrypted response of the client, and the user password.

  4. The remote access client verifies the authentication response and, if correct, uses the connection. If the authentication response is not correct, the remote access client terminates the connection.

Enabling MS-CHAP v2

To enable MS-CHAP v2-based authentication, you must do the following:

  1. Enable MS-CHAP v2 as an authentication protocol on the remote access server.

  2. Enable MS-CHAP v2 on the appropriate network policy. MS-CHAP v2 is enabled by default.

  3. Enable MS-CHAP v2 on the remote access client.

Additional considerations

  • MS-CHAP v2 is the only authentication protocol provided with the Windows Server® 2008 family that supports password change during the authentication process.

  • Make sure your network access server (NAS) supports MS-CHAP v2 before you enable it on a network policy on an NPS server. For more information, see your NAS documentation.


CHAP

The Challenge Handshake Authentication Protocol (CHAP) is a challenge-response authentication protocol that uses the industry-standard Message Digest 5 (MD5) hashing scheme to encrypt the response. CHAP is used by various vendors of network access servers and clients. A server running Routing and Remote Access supports CHAP so that remote access clients that require CHAP are authenticated. Because CHAP requires the use of a reversibly encrypted password, you should consider using another authentication protocol, such as MS-CHAP version 2.

To enable CHAP-based authentication, you must do the following:

  1. Enable CHAP as an authentication protocol on the remote access server. CHAP is disabled by default.

  2. Enable CHAP on the appropriate network policy.

  3. Enable storage of a reversibly encrypted form of the user password.

    You can enable storage of a reversibly encrypted form of the user password per user account or enable storage for all accounts in a domain.

  4. Force a reset of the user password so that the new password is in a reversibly encrypted form.

    When you enable passwords to be stored in a reversibly encrypted form, the current passwords are not in a reversibly encrypted form and are not automatically changed. You must either reset user passwords or set user passwords to be changed the next time each user logs on.

    If you set user passwords to be changed the next time a user logs on, the user must log on by using a local area network (LAN) connection and change the password before the user attempts to log on with a remote access connection by using CHAP. You cannot change passwords during the authentication process by using CHAP; the logon attempt fails. One workaround for the remote access user is to temporarily log on by using MS-CHAP to change the password.

  5. Enable CHAP on the remote access client.

Additional considerations

  • If your password expires, CHAP cannot change passwords during the authentication process.

  • Make sure your network access server (NAS) supports CHAP before you enable it on a network policy on an NPS server. For more information, see your NAS documentation.

  • You cannot use Microsoft Point-to-Point Encryption (MPPE) with CHAP.


PAP

Password Authentication Protocol (PAP) uses plaintext passwords and is the least secure authentication protocol. It is typically negotiated if the remote access client and remote access server cannot negotiate a more secure form of validation.

PAP is included in Windows Server® 2008 so that:

  • Remote access clients running Windows 32-bit operating systems can connect to older remote access servers that do not support a secure authentication protocol.

  • Remote access clients running Microsoft operating systems that do not support a secure remote access protocol can connect to remote access servers running Windows 32-bit operating systems.

To enable PAP-based authentication, you must do the following:

  1. Enable PAP as an authentication protocol on the remote access server. PAP is disabled by default.

  2. Enable PAP on the appropriate network policy. PAP is disabled by default.

  3. Enable PAP on the remote access client.

Important

When you enable PAP as an authentication protocol, user passwords are sent in plaintext form. Anyone capturing the packets of the authentication process can easily read the password and use it to gain unauthorized access to your intranet. The use of PAP is highly discouraged, especially for virtual private network (VPN) connections.

Additional considerations

  • By disabling the support for PAP on the remote access server, plaintext passwords are never sent by the dial-up client. Disabling support for PAP increases authentication security, but remote access clients who only support PAP cannot connect.

  • If your password expires, PAP cannot change passwords during the authentication process.

  • Make sure your network access server (NAS) supports PAP before you enable it on a network policy on a server running Network Policy Server (NPS). For more information, see your NAS documentation.

  • You cannot use Microsoft Point-to-Point Encryption (MPPE) with PAP.


Unauthenticated Access

The Windows Server® 2008 family supports unauthenticated access, which means that user credentials (a user name and password) are not required. There are some situations in which unauthenticated access is useful. For more information, see Unauthenticated access (http://go.microsoft.com/fwlink/?LinkId=73649). (This information describes unauthenticated access as it is supported in Windows Server 2003.)

Important
  • When you enable unauthenticated access, remote access users are connected without sending user credentials. An unauthenticated remote access client does not negotiate the use of a common authentication protocol during the connection establishment process and does not send a user name or password.
  • Unauthenticated access with remote access clients could occur when the authentication protocols configured by the remote access client do not match those configured on the remote access server. In this case, the use of a common authentication protocol is not negotiated and the remote access client does not send a user name and password.


Network Policies

  • Network policies, formerly known as remote access policies, are now administered from Network Policy Server (NPS). For more information, see http://go.microsoft.com/fwlink/?LinkId=69752.


IP Address Assignment

When a remote access client initiates a connection to the remote access server, the remote access client creates a temporary logical interface (also known as a virtual interface or a virtual network adapter) and requests that the remote access server assigns an IP address to this logical interface.

IP address assignment can occur in one of the following ways:

From a DHCP server

The remote access server obtains the IP address to assign to a remote client from a DHCP server on the intranet. This is the default method for IP address assignment. The remote access server behaves like a DHCP client to the DHCP server and obtains 10 IP addresses at a time. As the remote access clients connect to the remote access server, the IP addresses are assigned to the clients using Internet Protocol Control Protocol (IPCP). If no DHCP server is available, the router uses an address from the Automatic Private IP Addressing (APIPA) range 169.254.0.1–169.254.255.254.

From a specified range of addresses

The remote access server obtains the IP address from a static pool of addresses configured on the remote access server. If you configure a static address pool, be sure to use only IP addresses that are not in a range that your DHCP server might assign to another computer and that are not already assigned to computers. The pool can be ranges of addresses that are a subset of addresses from the IP network to which the server is attached or from a separate subnet. If the static IP address pool address ranges represent a different subnet, ensure that routes to the address ranges exist on the routers of your intranet so that traffic to the logical interface of a remote client is forwarded to the remote access server.

From a static address specified in the user account

You configure a static IP address on the Dial-in tab of the user account for the remote client or in network policy. When a remote client initiates a connection, creates a temporary logical interface, and requests that the remote access server assign an IP address to this logical interface, the remote access server assigns the IP address specified in the remote client's user account. This method is best suited for a small number of remote users.

Additional references

  • Using Routing and Remote Access Servers with DHCP


Filters and Remote Access Configurations

For the common Routing and Remote Access scenarios, you should consider securing traffic to and from the server running Routing and Remote Access and the network behind the server. Network traffic can be secured using IP packet filtering, Windows Firewall, or both. For more information, see Common Remote Access Configurations.

The following table describes the possible security methods for each scenario.

Scenario Security Location and Method

Virtual private network (VPN)

Network interface that connects to the Internet

  • Static filters. This is the recommended method. Select Enable security on the selected interface by setting up static packet filters in the Routing and Remote Access Setup Wizard.

Note

You will need to add ports for any service added, such as HTTP, after setting up static filters.

  • Windows Firewall. You will need to manually configure the VPN exception.

Important

Although you can configure both static filters and Windows Firewall on the same interface, this is not recommended for performance reasons. You must configure the same filter settings in both methods.

Network interface that connects to the LAN

Static filters. Configure on private, public, and demand-dial interfaces.

Network address translation (NAT)

Network interface that connects to the Internet

Windows Firewall.

Network interface that connects to the LAN

Static filters can be added to the private interface to protect against threats from internal clients.

VPN and NAT

Network interface that connects to the Internet

Windows Firewall. The filters to allow only VPN packets can be automatically added while using the Routing and Remote Access Setup Wizard.

Network interface that connects to the LAN

Static filters can be added to the private interface to protect against threats from internal clients.

Secure connection between two private networks (demand-dial, inbound)

Same as VPN scenario.

Secure connection between two private networks (demand-dial, inbound, and outbound)

Same as NAT scenario.


IPv6 Remote Access

Windows Server® 2008 and Windows Vista® support the following enhancements to Internet Protocol version 6 (IPv6):

  • Protocols

    • PPPv6. Native IPv6 traffic can now be sent over PPP-based connections, as described in RFC 2472. For example, PPPv6 support allows you to connect with an IPv6-based Internet service provider (ISP) through dial-up or PPP over Ethernet (PPPoE)-based connections that might be used for broadband Internet access.

    • PPPv6 over dialup/Ethernet as well as virtual private network (VPN) tunnels.

    • Layer Two Tunneling Protocol (L2TP) over IPv6.

    • DHCPv6 Relay Agent.

  • Stateless filtering, based on the following parameters:

    • Source IPv6 address/prefix.

    • Destination IPv6 address/prefix.

    • Next hop type (IP protocol type).

    • Source Port number (TCP/UDP).

    • Destination Port number (TCP/UDP).

  • Radius over IPv6 transport

Additional references

  • IPv6

  • For more information about IPv6 changes to Routing and Remote Access, see http://go.microsoft.com/fwlink/?LinkId=89012.


Routing

A router is a device that manages the flow of data between network segments, or subnets. A router directs incoming and outgoing packets based on the information it holds about the state of its own network interfaces and a list of possible sources and destinations for network traffic. By projecting network traffic and routing needs based on the number and types of hardware devices and applications used in your environment, you can better decide whether to use a dedicated hardware router, a software-based router, or a combination of both. Generally, dedicated hardware routers handle heavier routing demands best, and less expensive software-based routers are sufficient to handle lighter routing loads.

A software-based routing solution, such as the Routing and Remote Access service in Windows Server® 2008, can be ideal on a small, segmented network with relatively light traffic between subnets. Conversely, enterprise network environments that have a large number of network segments and a wide range of performance requirements might need a variety of hardware-based routers to perform different roles throughout the network.


Enable LAN and WAN Routing

Routing and Remote Access provides multiprotocol LAN-to-LAN, LAN-to-WAN, virtual private network (VPN), and network address translation (NAT) routing services. Routing and Remote Access is intended for use by system administrators who are already familiar with routing protocols and services.

Membership in the local Administrators group, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477.

To enable LAN and WAN routing

  1. Open Routing and Remote Access.

  2. Right-click the server name for which you want to enable routing, and then click Properties.

  3. On the General tab, select the Router check box, and then do one of the following:

    • For LAN routing, click Local area network (LAN) routing only.

    • For LAN and WAN routing, click LAN and demand-dial routing.


IPv4 Unicast Routing

  • What Is IPv4 Unicast Routing?

  • How IPv4 Unicast Routing Works

  • Manage the IPv4 Routing Table


What Is IPv4 Unicast Routing?

Unicast routing is the forwarding of traffic destined to a single location on a network from a source host to a destination host by using routers.

Today, the majority of network traffic worldwide is over Internet Protocol version 4 (IPv4) networks, and most user-initiated traffic across IPv4 networks is unicast traffic. Unicast IP routing occurs on all IP networks connected by routers, including:

  • An IP intranet not connected to the Internet.

  • The Internet.

  • Intranets that connect to the Internet or to each other through the Internet.

The major operating systems for which TCP/IP is the primary network protocol are Windows and UNIX.

Any Windows network supports unicast IP routing. These include networks that use only hardware routers, networks that use software-based routers such as the Routing and Remote Access service included in Windows Server® 2008, or networks that use a combination of hardware and software routers.

Windows Server 2008 also supports the next generation of IP, Internet Protocol version 6 (IPv6).


How IPv4 Unicast Routing Works

Unicast IPv4 routing network components

Unicast IP routing is the process of transferring data in the form of unicast IP packets across an IP network from a single source node (a computer or other network device) to a single destination node. An IP router is a node that forwards IP packets between interfaces (which can be physical network adapters or logical interfaces such as tunnels) based on information that it stores in a database called a routing table.

The following figure shows a simple IP network in which unicast IP routing takes place.

Simple IP network

The following table describes each of the routing components, as defined by the International Organization for Standardization (ISO), shown in the figure.

Network Component Description

End system

A network device that cannot forward IP packets. End systems are also known as hosts. A computer that is not acting as a router is an example of an end system. (Collectively, hosts and routers are known as nodes.)

Intermediate system

A network device that can forward IP packets that are not addressed to it. Bridges, switches, and routers are examples of intermediate systems.

Router

An intermediate system used to connect network segments (subnets) based on a common network layer protocol, such as IP. In the preceding figure, the intermediate system depicted is a router. Routers include:

  • Hardware routers. A device that performs routing as a dedicated function and is specifically designed and optimized for routing. For example, hardware routers made by Cisco Systems, Inc., are widely deployed in IP networks.

  • Software routers. A computer that performs routing as one of multiple processes running on the computer. For example, a computer running Windows Server® 2008 with the Routing and Remote Access service enabled is a software router.

A router can be configured to perform only static routing, only dynamic routing, or, more typically, primarily dynamic routing supplemented by some manually configured static routes.

Network

A portion of the networking infrastructure (repeaters, hubs, bridges, or Layer 2 switches) that is bounded by an intermediate system and whose computers and other network devices share a common network address called a network ID. Also referred to as a network segment or a subnet.

When a node on an IP network sends a unicast IP packet to a node on another network, it typically first forwards the packet to a router. The router examines the packet and uses the destination network address in the packet header to determine which of the router’s interfaces to use to forward the packet to its destination.

The network layer header of any IPv4 packet sent from a source node to a destination node on an IPv4 network includes the following:

  • A source IPv4 address, which contains a source network ID and a source host ID.

  • A destination IPv4 address, which contains a destination network ID and a destination host ID.

  • A Time-To-Live (TTL) value, which is used to prevent the packet from endlessly circulating on the network. The TTL starts at a maximum value and decreases by one for each link crossed; if zero is reached, the packet is discarded and a message is returned to the sending node from which the packet originated.

    Note

    The TTL link count (the number of Network Interface Layer links crossed to reach a given destination) is not the same as the hop count (the number of routers crossed to reach a destination). The link count, which equals the number of network segments, is the hop count plus one. For example, if two nodes are separated by five routers, the hop count is 5 but the TTL link count is 6.

How the IPv4 routing table works

On an IPv4 network, IP makes routing decisions by consulting a database of routes known as the IP routing table. Each IP node uses its own routing table to store information about routes usable for forwarding unicast IP packets to any reachable location. A node running Windows Server 2008 (or Windows Vista®) builds its routing table automatically, based on its current TCP/IP configuration, static routing table entries, information provided by dynamic routing protocols, and ICMP Redirect messages.

IPv4 routing table

Each entry in the routing table corresponds to one route. When an IP node needs to forward an IP packet, IP searches the routing table on the node for a route that most closely matches the destination IP address in the packet. Typically, the process is as follows:

  • For an IP host. A host can either send a packet directly to its destination, or it can send the packet en route to the destination through a default route {Network ID: 0.0.0.0, Subnet Mask: 0.0.0.0} that points to its default gateway. A default gateway is a router that connects separate IP network segments.

  • For an IP router. A router forwards a packet either by using an explicit static route for a specific network segment, a summarized route, a host route, or a default route.

Routing table example

An administrator or user can view the current state of the IP routing table on an IP node at any time. For example, consider a node configured as follows:

  • IP address: 157.54.27.90

  • Subnet mask: 255.255.240.0

  • Default gateway: 157.54.16.1

In network prefix length notation, the IP address and subnet mask pair {157.54.27.90, 255.255.240.0} for this node is expressed as 157.54.27.90/20. Typing route print at a command prompt on this node produces the output shown in the following table.

Example Routing Table

Network Destination      Netmask        Gateway      Interface   Metric
        0.0.0.0           0.0.0.0    157.54.16.1   157.54.27.90      20
      127.0.0.0         255.0.0.0      127.0.0.1      127.0.0.1       1
    157.54.16.0     255.255.240.0   157.54.27.90   157.54.27.90      20
   157.54.27.90   255.255.255.255      127.0.0.1      127.0.0.1      20
 157.54.255.255   255.255.255.255   157.54.27.90   157.54.27.90      20
      224.0.0.0         240.0.0.0   157.54.27.90   157.54.27.90      20
255.255.255.255   255.255.255.255   157.54.27.90   157.54.27.90       1

In the preceding output, the routing metric that is set to 20 for several rows is the metric that Windows Server 2008 or Windows Vista TCP/IP uses for a 100-Mbps Ethernet interface, for an 802.11g adapter, or for an 802.11a adapter. The following table lists the criteria that Windows Server 2008 or Windows Vista uses to assign metrics for routes that are bound to network interfaces of varying speeds.

Metrics Assigned by the Automatic Metric Feature

Link Speed | Metric
Greater than 200 Mbps | 10
Greater than 20 Mbps, and less than or equal to 200 Mbps | 20
Greater than 4 Mbps, and less than or equal to 20 Mbps | 30
Greater than 500 Kbps, and less than or equal to 4 Mbps | 40
Less than or equal to 500 Kbps | 50

The automatic metric feature is enabled by default through the Automatic metric check box on the IP Settings tab on Advanced TCP/IP Settings of the TCP/IP protocol. For DHCP-assigned default gateways, you can override the default behavior of automatically calculating a metric for the default route based on adapter speed by using the Microsoft-specific DHCP option called Default Router Metric Base.

Routing table vs. forwarding table

Many router implementations, including the Routing and Remote Access service in Windows Server 2008, use both a routing table and a forwarding table:

  • Routing table. Stores all routes from all possible sources. The command netsh ro ip sh rtmr (that is, netsh routing ip show rtmroutes) shows the routing table.

  • Forwarding table. Used by IP to forward packets. The commands route print or netsh ro ip sh rtmd (that is, netsh routing ip show rtmdestinations) show the IP forwarding table.

The Routing and Remote Access service on a Windows Server 2008 router maintains the IP routing table by using a component called Route Table Manager (abbreviated as rtm in rtmroutes and rtmdestinations in the commands shown earlier). Route Table Manager updates the IP forwarding table (which is contained within the TCP/IP protocol) based on incoming route information from multiple sources.

The contents of the routing table do not necessarily match the contents of the forwarding table.

Structure of the IPv4 routing table

Types of routes

The following table describes the types of routes stored in an IP routing table. For a description of each route in an actual routing table, see the table “Routes in an IP Routing Table” later in this topic.

Types of Routes Stored in an IP Routing Table

Route Type Description

Local network route

(Directly attached network route)

A route to a specific local network ID. This route identifies a network segment that is directly attached to the node.

For a local network route, the Gateway column (sometimes called Next Hop) might be blank or might contain the IP address of the interface on that network segment.

Remote network route

A route to a specific remote network ID. This route identifies a network segment that is not directly attached to the node but is available across one or more routers.

For a remote network route, the Gateway (Next Hop) column is the IP address of a local router located between the node and the remote network.

Host route

A route to an IP address (network ID + host ID) on the network. Instead of making a routing decision based on just the network ID, as is the case for either a local or a remote network route, the routing decision for a host route is based on the combination of network ID and host ID. For a host route, the Network Destination column is the IP address of the specified host, and the Netmask column is 255.255.255.255.

Typically, a host route is used to create a custom route to a host in order to control or optimize specific types of network traffic.

Default route

A route that is used when there are no other closer matching routes for the destination in the routing table. Including a default route in the routing table means that the routing table does not need to store routes for every network ID on the network. Using a default route, therefore, simplifies the configuration of hosts or routers.

Default gateways and default routes

Configuring a default gateway creates a default route in the IP routing table. For IP nodes, the default gateway (also called a default router) is a neighboring IP router that forwards unicast traffic for the node by providing a next-hop IP address (the Gateway column in the routing table) and interface (the Interface column in the routing table) for all destinations that are not located on the local subnet. The default gateway address is the IP address of a directly reachable IP router.

The default gateway on a computer running Windows Server 2008 or Windows Vista is configured by using one of the following methods:

  • TCP/IP properties General tab. If you want the node to obtain its IP address configuration by using manual configuration, the default gateway is the IP address located in the Default gateway field on the General tab on the TCP/IP properties page. Multiple default gateways can be configured by adding them on the IP Settings tab on the Advanced TCP/IP Settings page of TCP/IP properties.

  • TCP/IP properties Alternate Configuration tab. If you want the node to obtain its IP address configuration by using the user-configured alternate configuration option, the default gateway is the IP address located in the Default gateway field on the Alternate Configuration tab on the TCP/IP properties page. You can specify only a single default gateway. The TCP/IP alternate configuration feature lets a computer function in two or more networks — one configured with static IP addresses and another configured with DHCP — without reconfiguration of network adapter parameters. When no DHCP server is available, the connection uses the configuration specified on the Alternate Configuration tab.

  • DHCP. If you want the node to obtain its IP address configuration by using DHCP, the default gateway is the value of the first IP address in the Router DHCP option. The Router DHCP option specifies an ordered list of one or more default gateways. If you are using a Windows Server 2008 –based DHCP server, the Router option is located in the Details pane in the DHCP snap-in console tree under ServerName\ScopeName\Scope Options.

  • ICMP Router Discovery. If you want the node to automatically discover the best default gateway router available on a subnet, you can configure nodes on that subnet to use ICMP router discovery. ICMP Router Solicitation messages and Router Advertisement messages exchanged between routers and hosts enable hosts to dynamically discover which local routers are available, which routers are down, and which router is currently the best default gateway to use on a subnet. By using ICMP router discovery, a host can automatically switch to another default gateway if its current default gateway becomes unavailable.

Fields and records in the IP routing table database

As with any database, understanding the IP routing table requires understanding the relationship between the records (rows) and the fields (columns) that make up the IP routing table. This relationship is best understood by using an example. The following table shows the same information displayed in “Example Routing Table” earlier in this topic. It labels each row with the route type for that entry.

Example Information Stored in an IP Routing Table

Type | Network Destination | Netmask | Gateway | Interface | Metric
Default route | 0.0.0.0 | 0.0.0.0 | 157.54.16.1 | 157.54.27.90 | 20
Loopback network route | 127.0.0.0 | 255.0.0.0 | 127.0.0.1 | 127.0.0.1 | 1
Local network route (Directly attached network route) | 157.54.16.0 | 255.255.240.0 | 157.54.27.90 | 157.54.27.90 | 20
Local host route (Local IP address route) | 157.54.27.90 | 255.255.255.255 | 127.0.0.1 | 127.0.0.1 | 20
Network broadcast route (All-subnets-directed broadcast route) | 157.54.255.255 | 255.255.255.255 | 157.54.27.90 | 157.54.27.90 | 20
Multicast address route | 224.0.0.0 | 240.0.0.0 | 157.54.27.90 | 157.54.27.90 | 20
Limited broadcast route | 255.255.255.255 | 255.255.255.255 | 157.54.27.90 | 157.54.27.90 | 1
Routing table columns

The following table describes each field, or column, in the IP routing table.

Columns for Each Routing Table Entry

Column Description

Network Destination

Contains one of the following:

  • IP address. An IP address for a host route.

  • Network ID. A class-based, subnetted, or summarized network ID.

Netmask

(Subnet Mask)

Contains the subnet mask that IP applies to the destination IP address. If the destination and the subnet mask equal the network destination, the route is a match for the destination. The process is as follows:

  1. IP performs a bit-wise logical AND operation between the packet’s destination IP address and the value in the Netmask column.

  2. The result is compared to the value in the Network Destination column.

  3. When IP compares each bit in the destination IP address to the corresponding bit in the subnet mask, the bit-wise AND operation works as follows:

    • If both bits are 1, the resulting bit is 1.

    • If both bits are not 1, the resulting bit is 0.

Examples:

  • Default route. The netmask for the default route is 0.0.0.0, which translates to the binary value 00000000 00000000 00000000 00000000. When IP performs the AND operation between any destination IP address and this subnet mask, the result is all zeros. Therefore, no bits need to match, and any destination matches the default route.

  • Host route. The netmask for a host route (a route that matches a specific IP address) is 255.255.255.255, which translates to the binary value 11111111 11111111 11111111 11111111. When IP performs the AND operation between a host route and this subnet mask, only a destination IP address that is equal to the IP address of the host route matches this route.

  • Packet with IP address 157.54.16.48. When IP performs the AND operation between 157.54.16.48 and the netmask for the directly attached network route (in this example, 255.255.240.0), the result is 157.54.16.0. The subnet mask 255.255.240.0 requires that all eight bits in the first two octets and the first four bits in the third octet must match (240=11110000). Therefore, the closest match for this packet is the directly attached network (157.54.16.0/20).

Gateway

(Next Hop or Forwarding Address)

Contains either the IP address of a local network adapter for direct deliveries or the IP address of an IP router (such as a default gateway router) on the local network segment for indirect deliveries. This is the IP address that the local node uses to forward the IP packet.

Interface

Indicates the network interface (either a physical network adapter or a logical interface) that will be used to forward an IP packet.

Metric

Indicates the relative cost of routes so that the best route among possible multiple closest matching routes to the same destination can be selected. If there are multiple routes to the same destination with different metrics, the route with the lowest metric is selected.

Metrics can express the route preference in different ways:

  • Hop Count. Indicates the number of routers to cross to reach a destination network. A computer on the local subnet is one hop, and each router crossed after that is an additional hop.

  • Delay. Indicates the amount of time that the packet takes to reach the destination network. Delay refers to the speed (LAN links have a lower delay; WAN links have a higher delay) or congestion level of the path.

  • Throughput. Indicates the amount of data that can be sent along the path per second. Throughput does not necessarily indicate the bit rate of the link because a very busy Ethernet link might have a lower throughput than an unused 64 kilobits per second (Kbps) WAN link.

  • Reliability. Indicates a measure of the path constancy. Some types of links are more likely to fail than others. For example, leased-line WAN links are more reliable than dial-up lines.

RIP uses a hop count metric.

Routing table rows

The following table describes each record, or row, in the IP routing table. Each row represents a route. In the Description column, all references are to the output “Example Routing Table” shown earlier.

Routes in an IP Routing Table

Route Destination / Netmask (Network Prefix Length Notation) Description

Default route

0.0.0.0/0.0.0.0

(0.0.0.0/0, sometimes written as 0/0)

The route used if there are no other closer matching routes for the destination address in the IP packet. In the example, the IP packet is forwarded to 157.54.16.1 (the default gateway) by using interface 157.54.27.90 (the IP address of the node).

Loopback network route

127.0.0.0/255.0.0.0

(127.0.0.0/8)

The route used for any IP address of the form 127.x.y.z (127.0.0.0 through 127.255.255.255). In the example, as for any IP address in this range, the IP packet is forwarded to the special loopback address 127.0.0.1 by using the loopback interface.

Directly attached network route (Local network route)

varies/varies

The route used for an IP address on the locally attached subnet. The IP packet is forwarded directly to the destination IP address (not to an intermediate router). In the example, the IP packet is forwarded to its destination by using the interface assigned to 157.54.27.90 — that is, the Gateway and Interface columns contain an IP address of the node, indicating that the packet will be sent directly to its destination from a network adapter that is assigned an IP address on this node.

Local host route

(Local IP address route)

varies/255.255.255.255

(varies/32)

The route used if the IP address in the packet is the same as the IP address of the local host. The subnet mask 255.255.255.255 indicates that this is a host route. In the example, as for any IP address that matches the local host, the IP packet is forwarded to the loopback address 127.0.0.1 by using the loopback interface.

Network broadcast route

(All-subnets-directed broadcast route)

varies/255.255.255.255

(varies/32)

The route used for an IP address that matches the all-subnets-directed broadcast address. The subnet mask 255.255.255.255 indicates that this is a host route. The IP packet is forwarded as a MAC-level broadcast to hosts on all subnets of a subnetted IP network ID by using an interface that is assigned an IP address on the local node.

A network broadcast route exists only if the local network ID is subnetted from a class-based network ID.

Multicast address route

224.0.0.0/240.0.0.0

(224.0.0.0/4)

The route used for any of the class D IP addresses reserved for multicast traffic. The IP multicast packet is forwarded as a MAC-level multicast to the multicast group by using an interface that is assigned an IP address on the local node.

Limited broadcast route

255.255.255.255/

255.255.255.255

(255.255.255.255/32)

The route used for an IP address that matches the limited broadcast address. The subnet mask 255.255.255.255 indicates that this is a host route. The IP packet is forwarded as a MAC-level broadcast to all hosts on the same network segment by using an interface that is assigned an IP address on the local node.

The limited broadcast route is used during the DHCP configuration process, such as when a DHCP client uses the limited broadcast address to send all traffic while it waits for the DHCP server to acknowledge its lease of an IP address.

How IP consults the routing table

When an IP host or router needs to forward a packet to its destination, IP consults the routing table on that node to determine where to route the packet. This section provides a summary of how IP consults each row and column, and then provides a detailed description of the route determination process.

Synopsis of how IP consults the routing table

The following table summarizes how IP makes use of the IP routing table.

Overview of How IP Uses Routing Table Rows and Columns

Action Summary Steps

IP searches each row

IP checks each route in the table to find the closest matching route. Routes that match the destination vary from the most specific type of route to the least specific type of route. The closest matching routes have the following order:

  1. Host route.

  2. Route representing the network ID for a local or remote subnet.

  3. Route representing a summarized network ID.

  4. Default route.

Simultaneously, IP uses each column to assess each row

IP uses each column in every row as follows:

  1. Network Destination and Netmask. Used together to determine if the destination address in the IP packet matches the route.

  2. Metric. Used to determine which matching entry to select if two or more closest matching routes are found.

  3. Gateway and Interface. Used together to determine the next-hop address to which to send the packet and the next-hop interface over which to forward the packet.

Result

Three alternative routing decisions are possible:

  • Pass the packet to the loopback interface (if the destination of the packet is this computer or of the form 124.x.y.z).

  • Forward the packet by using one of the locally attached network adapters (if a closest matching route was found).

  • Discard the packet (if no matching route was found), and then (on a host) send an error message internally or (on a router) send an error message to the source host.

The next section describes in detail the process by which IP determines which routing decision to make.

Details of how IP makes the routing decision

IP determines the best route to a destination by comparing the destination IP address in the packet to each route currently present in the routing table. The detailed process is as follows:

  1. Determine whether the destination IP address of the packet matches one or more routes. For each entry in the routing table, IP on the node performs a bitwise logical AND operation between the destination IP address of the packet and the subnet mask listed in the Netmask column. IP compares the resulting value to the value in the Network Destination column:

    • Match. If one or more matching routes are found, IP compiles a list of the matching routes. IP determines if a route produces a match as follows:

      Host route. All 32 bits match the destination IP address. The route is to a single destination address.

      Route representing the network ID for a local or remote subnet. All of the bits in the network ID match the destination IP address. This route is either a route to a destination on the local subnet, or it is a route to a destination on a non-local network through a router.

      Route representing a summarized network ID. All of the bits in the summarized network ID match the destination IP address. The route is to a destination on the set of subnets summarized by this summary route.

      Default route. All destination IP addresses match the default route. This is the route used when there is no more specific match.

    • No match. If no route is found (including no default route), IP indicates an error condition. A “no match” condition cannot occur if a default route exists. If the node is a host, an IP routing error is sent internally to an upper layer protocol (such as TCP, UDP, or ICMP). If the node is a router, an ICMP Destination Unreachable-Host Unreachable message is sent to the source host.

    For examples illustrating the AND operation between a destination IP address and the value in the Netmask column, see the Netmask row in the table “Columns for Each Routing Table Entry” in “Structure of the IPv4 Routing Table” earlier in this topic.

  2. Determine the single route to use to send or forward the packet. The result of the route determination process is the choice of a single route in the routing table:

    • If one and only one route has the longest match — the longest match is the route with the highest number of bits set to 1 in the Netmask column (the longest prefix length) — that route is selected.

    • If multiple longest match routes are found (for example, multiple routes to the same network ID), IP selects the route with the lowest metric.

    • If multiple longest match routes with the same lowest metric exist, IP selects the route associated with the interface that is first in the binding order.

    Note

    If a computer has more than one interface (network adapter), the binding order is the order in which the interfaces are accessed by network services. This order reflects the order in which TCP/IP is bound to each of the interfaces. To change the relative binding order of interfaces on a computer running Windows Server 2008 or Windows Vista, open Network Connections, select the Advanced menu, select Advanced Settings, click the interface whose binding order you want to change, and then click the up arrow or the down arrow, as appropriate.

  3. Determine the next-hop address and interface. After a route is selected, IP determines from the routing table entry what the next-hop IP address is and which interface (physical network adapter or logical port) to use to forward the packet:

    • Direct delivery (to the destination node). If the destination is on a subnet directly connected to the host or router, IP delivers the packet to the destination node. In this case, the address in the Gateway column is the same as the address in the Interface column (or the Gateway column is blank), and the next-hop IP address is set to the destination IP address in the IP packet. The interface used is the one specified in the Interface column of the selected route.

      Again using the example shown in “Example Routing Table” described earlier, if traffic is sent to 157.54.16.48, the most specific route is the route for the directly attached network (157.54.16.0/20). The next-hop IP address is set to the destination IP address (157.54.16.48) and the interface used is the adapter card that has been assigned the IP address 157.54.27.90 (the interface on the local node).

    • Indirect delivery (to the next router). If the destination is not on a subnet directly connected to the node, IP delivers the packet to a neighboring router on a directly connected subnet for further routing. In this case, the address in the Gateway column is not the same as the address in the Interface column, and the next-hop IP address is set to the address in the Gateway column. The interface used is the one specified in the Interface column of the selected route.

      For example, if traffic is sent to 157.60.0.79, the most specific route is the default route (0.0.0.0/0). The next-hop IP address is set to the gateway address (157.54.16.1) and the interface used is, in this case again, the adapter card that has been assigned the IP address 157.54.27.90 (the interface on the local node).

  4. Hand off the packet to ARP. IP hands the packet, the next-hop IP address, and the next-hop interface to ARP. ARP resolves the next-hop IP address to its MAC address and forwards the packet, as appropriate, to the next hop, which is either the destination or the router that will forward it to its destination.


Manage the IPv4 Routing Table

On a computer running the Routing and Remote Access service on Windows Server® 2008, several methods for managing the IP routing table are available:

  • The route command-line tool, which is designed specifically to display and manage the IP routing table.

  • The Netsh routing IP context, which includes several commands for managing IP routes.

  • The Routing and Remote Access snap-in, which displays the routing table with an additional column that lists the source from which the route was obtained. View the routing table by right-clicking IP Routing\Static Routes in the console tree and then selecting Show IP Routing Table.

In addition to using the route print command to view the routing table, you can also use route to add, change, or delete routes. Because the IP routing table is stored in RAM and is rebuilt whenever a computer is restarted, one common practice is to use route add with the -p option to add a static route that is persistent, that is, a route that persists even after the computer is restarted. Persistent routes are stored in the registry.

The IP routing table that appears in the Routing and Remote Access snap-in includes one additional column that the route print command does not display. This is the Protocol column, which identifies how the router learned each route. For example, Local identifies a route on the local node; Static identifies a static route that the administrator configured manually; RIP identifies dynamic routes learned from routers configured to use this routing protocol.

The following displays the IP routing table on a Windows Server 2008 Routing and Remote Access router.

Routing and remote access snap-in IP routing table


What Is IPv4 Multicasting?

IP multicasting overview

Unicasting is the sending of network traffic to an endpoint. Multicasting is the sending of network traffic to a group of endpoints. Only those members in the group of endpoints that are listening for the multicast traffic (the multicast group) process the multicast traffic. All other nodes ignore the multicast traffic.

The concept of group membership is central to IP multicasting. IP multicast datagrams are sent to a group, and only members of the group receive the datagrams. A group is identified by a single IP multicast address, which is an IP address in the Class D range of 224.0.0.0 to 239.255.255.255 (designated as 224.0.0.0/4 in classless interdomain routing (CIDR) notation). These Class D addresses are known as group addresses. A source host sends multicast datagrams to a group address. Destination hosts inform a local router that they need to join the group.

In an IP multicast-enabled intranet, any host can send IP multicast datagrams to any group address, and any host can receive IP multicast datagrams from any group address regardless of its location. To facilitate this capability, the hosts and routers on the intranet must support IP multicasting. Hosts use the Internet Group Management Protocol (IGMP) for establishing group membership. Routers use multicast routing protocols for forwarding multicast data.

The following figure illustrates a multicast-enabled intranet.

In this illustration, the hosts and routers are multicast-enabled so that the following can occur:

  • The sending host sends multicast datagrams to a designated group address.

  • The routers forward the multicast datagrams to any network segments that include group members. Routers can forward multicast traffic across a network, between networks, and across the Internet.

  • The receiving hosts inform a local router to join the group, and then they receive all subsequent datagrams sent to the group address.

  • If a receiving host leaves the group and detects that it might be the last group member on the subnet, it can contact the local router to leave the group, informing the router to stop forwarding the multicast datagrams to that subnet.

Benefits of IP multicasting

Multicasting provides an efficient way to support high-bandwidth, one-to-many applications on a network:

  • Multicasting can dramatically reduce network traffic by sending a single copy of the data.

  • Hosts can be configured for multicasting without hardware upgrades.

  • Because newer routers already support multicast forwarding and multicast routing protocols, enabling multicasting on a network is practical and cost-effective.

Multicasting is useful for many types of one-to-many applications, such as the following:

  • Multimedia, such as video conferencing and collaborative computing.

  • Automatic discovery of resources in a network (in Windows Server® 2008 for example, TCP/IP router discovery uses multicasting by default, and WINS uses multicasting during automatic discovery of replication partners).

  • Datacasting, such as file distribution or database synchronization.

  • Mobile computer support, such as remote address book updating.

  • Distribution of organizational publications.

IP multicasting with Routing and Remote Access

Windows Server 2008 does not provide multicast routing protocols, such as Distance Vector Multicast Routing Protocol (DVMRP), Multicast Extensions to Open Shortest Path First (MOSPF), and Protocol Independent Multicast (PIM), although Routing and Remote Access does support multicast routing protocols developed by independent software vendors (ISVs).

As an alternative, you can use the Routing and Remote Access service to forward multicast traffic. In this case, the Routing and Remote Access service uses IGMP as an IP routing protocol component. Router interfaces are configured in one of two operating modes: IGMP router mode or IGMP proxy mode. The purpose of IGMP router mode is to forward multicast traffic in a single-router intranet. The purpose of IGMP proxy mode is to connect a single-router intranet to a multicast-capable intranet or the Internet.

Although Routing and Remote Access uses IGMP in a limited way to enable multicast forwarding on an intranet, it is not the equivalent of a true multicast routing protocol. The Routing and Remote Access IGMP routing protocol component supports multicast forwarding for several network topologies.


IPv6 Routing

IPv6 routing

Routing is the process of forwarding packets between connected network segments. For IPv6-based networks, routing is the part of Internet Protocol version 6 (IPv6) that provides forwarding capabilities between hosts that are located on separate segments within a larger IPv6-based network.

IPv6 is the mailroom in which IPv6 data sorting and delivery occur. Each incoming or outgoing packet is called an IPv6 packet. An IPv6 packet contains both the source address of the sending host and the destination address of the receiving host. Unlike link-layer addresses, IPv6 addresses in the IPv6 header typically remain the same as the packet travels across an IPv6 network.

Routing is the primary function of IPv6. IPv6 packets are exchanged and processed on each host by using IPv6 at the Internet layer.

Above the IPv6 layer, transport services on the source host pass data in the form of TCP segments or UDP messages down to the IPv6 layer. The IPv6 layer creates IPv6 packets with source and destination address information that is used to route the data through the network. The IPv6 layer then passes packets down to the link layer, where IPv6 packets are converted into frames for transmission over network-specific media on a physical network. This process occurs in reverse order on the destination host.

IPv6 layer services on each sending host examine the destination address of each packet, compare this address to a locally maintained routing table, and then determine what additional forwarding is required. IPv6 routers are attached to two or more IPv6 network segments that are enabled to forward packets between them.

IPv6 routers

IPv6 network segments, also known as links or subnets, are connected by IPv6 routers, which are devices that pass IPv6 packets from one network segment to another. This process is known as IPv6 routing and is shown in the following illustration.

IPv6 routers provide the primary means for joining together two or more physically separated IPv6 network segments. All IPv6 routers have the following characteristics:

  • IPv6 routers are physically multihomed hosts.

    A physically multihomed host is a network host that uses two or more network connection interfaces to connect to each physically separated network segment.

  • IPv6 routers provide packet forwarding for other IPv6 hosts.

    IPv6 routers are distinct from other hosts that use multihoming. An IPv6 router must be able to forward IPv6-based communication between networks for other IPv6 network hosts.

You can implement IPv6 routers by using a variety of hardware and software products, including a computer running a member of the Windows Server® 2008 family with the IPv6 protocol. Routers that are dedicated hardware devices running specialized software are common. Regardless of the type of IPv6 routers that you use, all IPv6 routing relies on a routing table to communicate between network segments.

IPv6 routing table

Every computer that runs IPv6 determines how to forward packets based on the contents of the IPv6 routing table. To display the IPv6 routing table, type netsh interface ipv6 show routes at the command prompt.

Entries in the IPv6 routing table include:

  • An address prefix.

  • The interface over which packets matching the address prefix are sent.

  • A forwarding or next-hop address.

  • A preference value used to select between multiple routes with the same prefix.

  • The lifetime of the route.

  • The specification of whether the route is published (advertised in a Routing Advertisement).

  • The specification of how the route is aged.

  • The route type.

The IPv6 routing table is built automatically, based on the current IPv6 configuration of your computer. When forwarding IPv6 packets, the routing table is searched by your computer for an entry that is the most specific match to the destination IPv6 address. A route for the link-local prefix (FE80::/64) is not displayed.

The default route (a route with a prefix of ::/0) is typically used to forward an IPv6 packet to a default router on the local link. Because the router that corresponds to the default router contains information about the network prefixes of the other IPv6 subnets within the larger IPv6 network, it forwards the packet to other routers until it is eventually delivered to the destination.

Additional references

  • IPv6

  • For more information about IPv6 changes to Routing and Remote Access, see http://go.microsoft.com/fwlink/?LinkId=89012.

  • For more information about PPPv6 changes to Routing and Remote Access, see http://go.microsoft.com/fwlink/?LinkId=90639.


Network Address Translation

  • Enable NAT

  • What Is NAT?

  • NAT Example

  • Internet Private Addresses

  • Using NAT and VPN

  • How NAT Differs from ICS


Enable NAT

Membership in the local Administrators group, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477.

To enable network address translation addressing

  1. Open Routing and Remote Access.

  2. In the console tree, click NAT.

    Where?

    • Routing and Remote Access/server name/[IPv4 or IPv6]/NAT

  3. Right-click NAT, and then click Properties.

  4. On the Address Assignment tab, select the Automatically assign IP addresses by using the DHCP allocator check box.

  5. (Optional) To allocate to DHCP clients on the private network, in IP address and Mask, configure the range of IP addresses.

  6. (Optional) To exclude addresses from allocation to DHCP clients on the private network, click Exclude, click Add, and then configure the addresses.


What Is NAT?

Network address translation (NAT) provides a method for translating the Internet Protocol version 4 (IPv4) addresses of computers on one network into IPv4 addresses of computers on a different network. A NAT-enabled IP router deployed at the boundary where a private network, such as a corporate network, meets a public network, such as the Internet, allows computers on the private network to access computers on the public network by providing this translation service.

NAT technology was developed to provide a temporary solution to the IPv4 address-depletion problem. The number of available globally unique (public) IPv4 addresses is far too few to accommodate the rapidly increasing number of computers that need access to the Internet. Although the long-term solution — the development of Internet Protocol version 6 (IPv6) addresses — exists, IPv6 is not yet widely adopted. NAT technology lets computers on any network use reusable private addresses to connect to computers with globally unique public addresses on the Internet.

In Windows Server® 2008, the Routing and Remote Access service supports a NAT solution by allowing the optional configuration of a routing protocol component that provides network address translation. Computers on a private network can access a public network by means of a NAT-enabled router that runs the Routing and Remote Access service. All traffic leaving, or entering, the private network must travel by way of the NAT-enabled router.

NAT consists of the following components:

Component | Description
Translation | The server running Routing and Remote Access on which NAT is enabled translates the IP addresses and TCP/UDP port numbers of packets that are forwarded between the private network and the Internet.
Addressing | The network address translation computer provides IP address configuration information to the other computers on the home network. The addressing component is a simplified DHCP server that allocates an IP address, a subnet mask, a default gateway, and the IP address of a DNS server. You must configure computers on the home network as DHCP clients in order to receive the IP configuration automatically.
Name resolution | The network address translation computer becomes the DNS server for the other computers on the home network. When name resolution requests are received by the network address translation computer, it forwards the name-resolution requests to the Internet-based DNS server for which it is configured and returns the responses to the home network computer.

Additional considerations

Because NAT includes addressing and name resolution components that provide DHCP and DNS services for hosts on the private network, you cannot run:

  • The DHCP service or the DHCP Relay Agent if NAT addressing is enabled.

  • The DNS service if NAT TCP/IP networking name resolution is enabled.


NAT Example

If a small business is using the 192.168.0.0 network ID for its intranet and has been granted the public address of w1.x1.y1.z1 by its Internet service provider (ISP), then network address translation (NAT) maps all private addresses on 192.168.0.0 to the IP address of w1.x1.y1.z1. If multiple private addresses are mapped to a single public address, NAT uses dynamically chosen TCP and UDP ports to distinguish one intranet location from another.

Note

The use of w1.x1.y1.z1 and w2.x2.y2.z2 is intended to represent valid public IP addresses as allocated by the Internet Assigned Numbers Authority (IANA) or an ISP.

The following illustration shows an example of the use of NAT to transparently connect an intranet to the Internet.

Example of NAT use

If a private user at 192.168.0.10 uses a Web browser to connect to the Web server at w2.x2.y2.z2, the user's computer creates an IP packet with the following information:

  • Destination IP address: w2.x2.y2.z2

  • Source IP address: 192.168.0.10

  • Destination port: TCP port 80

  • Source port: TCP port 1025

This IP packet is then forwarded to the NAT protocol, which translates the addresses of the outgoing packet to the following:

  • Destination IP address: w2.x2.y2.z2

  • Source IP address: w1.x1.y1.z1

  • Destination port: TCP port 80

  • Source port: TCP port 5000

The NAT protocol keeps the mapping of {192.168.0.10, TCP 5000} to {w1.x1.y1.z1, TCP 1025} in a table.

The translated IP packet is sent over the Internet. The response is sent back and received by the NAT protocol. When received, the packet contains the following public address information:

  • Destination IP address: w1.x1.y1.z1

  • Source IP address: w2.x2.y2.z2

  • Destination port: TCP port 1025

  • Source port: TCP port 80

The NAT protocol checks its translation table and maps the public addresses to private addresses and forwards the packet to the computer at 192.168.0.10. The forwarded packet contains the following address information:

  • Destination IP address: 192.168.0.10

  • Source IP address: w2.x2.y2.z2

  • Destination port: TCP port 5000

  • Source port: TCP port 80

For outgoing packets from the NAT protocol, the source IP address (a private address) is mapped to the ISP allocated address (a public address), and the TCP/UDP port numbers are mapped to a different TCP/UDP port number.

For incoming packets to the NAT protocol, the destination IP address (a public address) is mapped to the original intranet address (a private address), and the TCP/UDP port numbers are mapped back to their original TCP/UDP port numbers.

Note

Packets that contain the IP address only in the IP header are properly translated by NAT. Packets that contain the IP address within the IP payload might not be properly translated by NAT.


Internet Private Addresses

To communicate on the Internet, you must use addresses that have been allocated by the Internet Assigned Numbers Authority (IANA). Addresses allocated by IANA can receive traffic from Internet locations and are known as public addresses. A typical small business or home office is allocated a public address (or addresses) from its Internet service provider (ISP), who has received a range of public addresses.

To allow multiple computers in the small office or home office to communicate on the Internet, each computer must have its own public address. This requirement creates great demand for public addresses, which are finite in number.

To satisfy this demand, IANA has provided for an address reuse scheme by reserving network IDs for private networks. The private network IDs include:

  • 10.0.0.0 with the subnet mask 255.0.0.0

  • 172.16.0.0 with the subnet mask 255.240.0.0

  • 192.168.0.0 with the subnet mask 255.255.0.0

For more information about portions of the IP address space that are reserved for private intranets, see RFC 1918, "Address Allocation for Private Internets." All addresses in these ranges are known as private addresses.

Private addresses cannot receive traffic from Internet locations. Therefore, if an intranet is using private addresses and communicating with Internet locations, the private address must be translated to a public address. A network address translator is placed between an intranet that uses private addresses and the Internet, which uses public addresses. Outgoing packets from the intranet have their private addresses translated by network address translation (NAT) into public addresses. Incoming packets from the Internet have their public addresses translated by NAT into private addresses.


Using NAT and VPN

A common deployment option is to use network address translation (NAT) on one or both sides of a connection that links offices in different geographical locations. The Routing and Remote Access service in Windows Server® 2008 provides two types of virtual private network (VPN) site-to-site connections. The following table describes the circumstances in which you can use a NAT in conjunction with a VPN connection.

Type of VPN Site-to-Site Connection | Can You Use NAT? | Description
PPTP VPN | Yes | In most cases, you can locate PPTP–based calling routers behind a NAT-enabled router (or configure one computer as both the calling router and the NAT-enabled router) in order to allow computers with private addresses in a small office or home office network to share a single connection to the Internet. With a VPN connection, the site-to-site connection from the small office to the main office is “tunneled” through the Internet. NAT in the Routing and Remote Access service in Windows Server 2008 includes a NAT editor that can accurately translate PPTP-tunneled data.
L2TP/IPsec VPN | Yes, but only if you use the IPsec NAT Traversal (NAT-T) feature | With Windows Server 2008 –based calling or answering routers, you can use the Internet Protocol security (IPsec) feature called NAT traversal (NAT-T) to create L2TP/IPsec connections across NATs. Using NAT-T requires running Windows Server 2008 on both the calling and answering routers (or appropriately configured Cisco routers). With NAT-T, computers with private addresses that are hidden behind a NAT can use IPsec to connect to a remote site if these computers have the NAT-T update installed (for computers running Windows Vista® or Windows XP Professional Service Pack 1). No NAT editor exists for L2TP/IPsec, so the only way to use NAT is by implementing IPsec NAT-T.
SSTP | Yes | SSTP-based VPN clients and VPN servers can be located behind a NAT-enabled router.


How NAT Differs from ICS

Internet Connection Sharing (ICS) provides a network translation capability that is an alternative option to that provided by NAT in Routing and Remote Access. ICS is typically used by networks that have two to ten computers. Because ICS and Routing and Remote Access NAT share common drivers, they cannot coexist on the same network.

To connect a small office or home office (SOHO) network to the Internet, you can use one of two methods:

  1. Routed connection

    For a routed connection, the server running Routing and Remote Access acts as an IP router that forwards packets between SOHO hosts and Internet hosts. While conceptually simple, a routed connection requires knowledge of IP address and routing configuration for SOHO hosts and the server running Routing and Remote Access. However, routed connections allow all IP traffic between SOHO hosts and Internet hosts.

  2. Translated connection

    For a translated connection, the server running Routing and Remote Access acts as a network address translator: an IP router that translates addresses for packets being forwarded between SOHO hosts and Internet hosts. This is called network address translation (NAT). Translated connections that use a server running Routing and Remote Access require less knowledge of IP addressing and routing and provide a simplified configuration for SOHO hosts. However, translated connections might not allow all IP traffic between SOHO hosts and Internet hosts.

You can configure a translated connection to the Internet by using one of the following methods.

  • You can use the Internet Connection Sharing feature of Network Connections.

  • You can use the Network Address Translation (NAT) routing protocol provided with the Routing and Remote Access snap-in on servers running Windows Server® 2008 and Routing and Remote Access.

Both Internet Connection Sharing and NAT provide translation, addressing, and name resolution services to SOHO hosts.

Internet Connection Sharing is designed to provide a single step of configuration (a single check box) in order to provide a translated connection to the Internet for all of the computers on the SOHO network. However, when enabled, Internet Connection Sharing does not allow configuration beyond the configuration of services and ports on the SOHO network. For example, Internet Connection Sharing is designed for a single IP address obtained from an Internet service provider (ISP) and does not allow you to change the range of IP addresses allocated to SOHO hosts.

The NAT routing protocol component is designed to provide maximum flexibility in the configuration of the server running Routing and Remote Access to provide a translated connection to Internet. The NAT routing protocol component requires more configuration steps; however, each step of the configuration can be customized. Most of the configuration can be accomplished using the Routing and Remote Access Server Setup Wizard. The NAT routing protocol component allows for ranges of IP addresses from an ISP and the configuration of the range of IP addresses allocated to SOHO hosts.

The following table summarizes the features and capabilities of Internet Connection Sharing and the NAT routing protocol component.

Internet Connection Sharing | Network address translation
Single check box configuration | Manual configuration
Single public IP address | Multiple public IP addresses
Fixed address range for SOHO hosts | Configurable address range for SOHO hosts
Single SOHO interface | Multiple SOHO interfaces
Note

Internet Connection Sharing is a feature designed to connect SOHO networks to the Internet. The NAT routing protocol component is designed to connect small to medium business networks to the Internet. Neither Internet Connection Sharing nor the NAT routing protocol component is designed to:

  • Directly connect SOHO networks.

  • Connect networks within an intranet.

  • Directly connect branch office networks to a corporate network.

  • Connect branch office networks to a corporate network over the Internet.


Demand-Dial Routing

  • Add a Demand-Dial Interface

  • What Is Demand-Dial Routing?

  • Demand-Dial Routing Example

  • Demand-Dial Connection Process


Add a Demand-Dial Interface

Demand-dial interfaces connect routers on either public or private networks. A demand-dial interface can be either on-demand (activated only when needed) or persistent (always connected) and initiate one-way or two-way connections.

Membership in the local Administrators group, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477.

To add a demand-dial interface

  1. Open Routing and Remote Access.

  2. In the console tree, click Network Interfaces.

    Where?

    • Routing and Remote Access/server name/Network Interfaces

  3. Right-click Network Interfaces, and then click New Demand-dial Interface.

  4. Follow the instructions in the Demand-Dial Interface wizard.


What Is Demand-Dial Routing?

Demand-dial routing is the forwarding of packets between networks and over Point-to-Point Protocol (PPP) links, such as analog phone lines and Integrated Services Digital Network (ISDN).

Demand-dial routing vs. remote access

Demand-dial routing is not the same as remote access. Remote access connects a single user to a network. Demand-dial routing connects networks together. However, both remote access and demand-dial routing use PPP to negotiate and authenticate the connection and encapsulate data sent on the connection. As implemented in Routing and Remote Access for Windows Server® 2008, both remote access and demand-dial connections can be enabled separately but share the same:

  • Behavior of the dial-in properties of user accounts.

  • Security, including authentication protocols and encryption.

  • Use of network policies.

  • Use of Windows or Remote Authentication Dial-In User Service (RADIUS) as authentication providers.

  • IP address allocation configuration.

  • Use of PPP features, such as Microsoft Point-to-Point Compression (MPPC), Multilink Protocol (MP), and Bandwidth Allocation Protocol (BAP).

  • Troubleshooting facilities, including event logging, Windows or RADIUS authentication and accounting, logging, and tracing.

Remote access clients and routers

Because the routing service and remote access coexist on a server running Routing and Remote Access, both routers and remote access clients can call the same phone number. The server running Routing and Remote Access that answers the call must be able to distinguish a remote access client from a router that is calling to create a demand-dial connection. To differentiate a remote access client from a demand-dial router, the user name in the authentication credentials sent by the calling router must exactly match the name of a demand-dial interface on the answering router. Otherwise, the incoming connection is assumed to be a remote access connection.

Components of a demand-dial connection

A demand-dial connection contains the following components:

  • Calling router, which initiates the demand-dial connection.

  • Answering router, which accepts the demand-dial connection initiated by the calling router.

  • Connection medium, which is either a physical medium or a tunnel medium. For more information about connection media, see “Connection Medium” later in this topic.

Components of a Demand-Dial Connection

Components of a Demand-Dial Connection

Common components for routers

The following components are common to both the calling router and the answering router:

  • Routing and Remote Access

  • Port

Routing and Remote Access

Routing and Remote Access on the calling router must be configured as a local area network (LAN) and wide area network (WAN) router and configured for IP address allocation and authentication methods. IP addresses can be allocated either by using Dynamic Host Configuration Protocol (DHCP) or a static address pool.

Port

A port is a logical or physical communications channel that can support a single PPP connection. Physical ports are based on equipment installed in the calling router. VPN ports are logical ports.

Calling router components

In addition to Routing and Remote Access and a port, the calling router contains the following components:

  • Demand-dial interface

  • Route

Demand-dial interface

A demand-dial interface configured on the calling router represents the PPP connection and contains configuration information, such as the port to use, the addressing used to create the connection (such as a phone number), authentication and encryption methods, and authentication credentials.

Route

An IP route in the routing tables of the calling router is configured to use a demand-dial interface to forward traffic.

Answering router components

In addition to Routing and Remote Access and a port, the answering router contains the following components:

  • User account

  • Demand-dial interface

  • Route

Note

Two-way initiated and one-way initiated connections require different configurations for the answering router. For more information about two-way initiated and one-way initiated connections, see “Types of Demand-Dial Connections” later in this topic.

User account

To authenticate the calling router, the credentials of the calling router must be verified by the properties of a corresponding user account. A user account for the calling router must be either locally present or available through Windows Server 2008 security. If the answering router is configured for RADIUS authentication, then the RADIUS server must have access to the user account of the calling router.

The user account must have the following settings:

  • On the Dial-in tab, network access permission is set to either Allow access or Control access through NPS Network Policy.

  • On the General or Account tab, User must change password at next logon is disabled and Password never expires is enabled.

For a one-way initiated connection, configure static IP routes that are added to the routing table of the answering router when the demand-dial connection is made.

Demand-dial interface

For two-way initiated connections, a demand-dial interface configured on the answering router represents the PPP connection to the calling router. For a one-way initiated connection using static routes on the user account of the calling router, a demand-dial interface on the answering router does not need to be configured.

Route

For two-way initiated connections, an IP route in the routing tables of the calling router is configured to use a demand-dial interface to forward traffic.

For one-way initiated connections, you can configure the user account of the calling router with static IP routes.

Connection medium

The PPP link is established over either a physical medium or a tunnel medium. Physical media includes PSTN and ISDN. Tunnel media includes Point-to-Point Tunneling Protocol (PPTP) and Layer Two Tunneling Protocol (L2TP).

PPPoE

PPPoE is a method of encapsulating PPP frames so that they can be sent over an Ethernet network. Using PPPoE and a broadband modem, LAN clients can gain individual authenticated access to high-speed data networks.

Types of demand-dial connections

Demand-dial connections are characterized as either on-demand or persistent and as either two-way initiated or one-way initiated.

These characteristics determine the configuration of the demand-dial interface.

On-demand and persistent connections

Demand-dial connections are either on-demand or persistent.

On-demand connections

On-demand connections are used when the cost of using the communications link is time-sensitive. For example, the charges for long distance analog phone calls are on a per-minute basis. On-demand connections make the connection when traffic is forwarded and terminate the connection after a configured amount of idle time.

Idle disconnect behavior is configured on the calling router and the answering router.

  • On the calling router, the idle disconnect time is set on the General tab of the properties of the demand-dial interface.

  • On the answering router, the idle disconnect time is set in the network policy being used by the demand-dial connection on the server running Network Policy Server (NPS).

Persistent connections

Persistent connections use a dial-up WAN technology when the cost of the link is fixed and the connection can be active 24 hours a day. Examples of WAN technologies for persistent demand-dial connections include local calls that use analog phone lines, leased analog lines, and flat-rate ISDN. If a persistent connection is lost, the calling router immediately attempts to reestablish the connection.

Persistent connection behavior must be configured on the calling router and the answering router.

Two-way and one-way initiated connections

Demand-dial connections are either two-way initiated or one-way initiated.

Two-way initiated connections

With two-way initiated connections, either router can be the answering router or the calling router, depending on which router initiates the connection. Both routers must be configured to initiate and accept a demand-dial connection. You use two-way initiated connections when traffic from either router can create the demand-dial connection. Two-way initiated demand-dial connections require that:

  • Both routers are configured as LAN and WAN routers.

  • User accounts are added for both routers so that the authentication credentials of the calling router are accessed and validated by the answering router.

  • Demand-dial interfaces are fully configured on both routers and include the phone number of the answering router and user account credentials to authenticate the calling router.

  • Static routes are configured on both routers.

For two-way initiated demand-dial routing to work properly, the user account names of the calling routers on both sides of the connection must match the name of a demand-dial interface. The following table shows an example of this configuration.

Example of Two-Way Initiated Connection Configuration

Router | User Account Name | Demand-Dial Interface Name
Corporate office router | CorpHub | NewYorkRouter
Branch office router | NewYorkRouter | CorpHub

For a description of the two-way connection process, see Demand-Dial Connection Process.

One-way initiated connections

With one-way initiated connections, one router is always the answering router and the other router is always the calling router. In one-way initiated connections, the routing configuration is simplified because user accounts, demand-dial interfaces, and static IP routes do not need to be fully configured on both sides of the connection. Instead of configuring a demand-dial interface and static routes on the answering router, static routes are added to the dial-in properties of the user account of the calling router.

If your answering router is in a Windows Server 2008 or Windows Server 2003 mixed-mode domain, static routes on the user account are not available. In this case, one-way initiated connections require that:

  • Both routers are configured as LAN and WAN routers.

  • A user account is added for the authentication credentials of the calling router.

  • A demand-dial interface is configured at the calling router with the user credentials of the user account. A demand-dial interface is configured at the answering router with the same name as the user account that is used by the calling router. Because the demand-dial interface of the answering router is not used to dial out, it is not configured with the phone number of the calling router or with valid user credentials.


Demand-Dial Routing Example

The following illustration shows the configuration between two offices that want to use two-way initiated demand-dial IP routing.

The Seattle office has a server running Routing and Remote Access that acts as a remote access server and demand-dial router. All computers in the Seattle office are connected to the 172.16.1.0 network (subnet mask 255.255.255.0). The Seattle router (hereafter referred to as Router 1) has a modem connected to its COM1 port and the phone number of the modem is 555-0111.

The New York office has a server running Routing and Remote Access that acts as a remote access server and demand-dial router. All computers in the New York office are connected to the 172.16.2.0 network (subnet mask 255.255.255.0). The New York router (hereafter referred to as Router 2) has a modem connected to its COM2 port and the phone number of the modem is 555-0122.

The user on the computer with the IP address of 172.16.1.10 needs to be able to connect to the user on the computer with the IP address of 172.16.2.20, and vice versa.

Note

To configure demand-dial routing, use the Demand-dial Interface wizard, and do not skip the Add a Static Route dialog box. For more information, see Add a Demand-Dial Interface.

Configuring Router 1

The configuration for demand-dial routing on Router 1 consists of the following three steps:

  1. Create a demand-dial interface.

  2. Create a static route.

  3. Create an account that Router 2 uses when calling Router 1.

Creating a demand-dial interface

By using Routing and Remote Access with the Demand-dial Interface wizard, the administrator at Router 1 creates a demand-dial interface called DD_NewYork with the following configuration:

  • Equipment: Modem on COM1

  • Phone number: 555-0122

  • Protocols: TCP/IP

  • Authentication credentials: DD_Seattle with a password

Creating a static route

By using Routing and Remote Access, the Demand-dial Interface wizard will already have the name and destination of the static route with the following configuration:

  • Interface: DD_NewYork

  • Destination: 172.16.2.0

  • Network mask: 255.255.255.0

  • Metric: 1

Note

Because the demand-dial connection is a point-to-point connection, the gateway IP address cannot be configured.

Creating an account with dial-in permissions

By using Active Directory Users and Computers or Local Users and Groups, the administrator at Router 1 creates a user account with the following settings:

  • Account name: DD_NewYork with a password.

  • Account settings: Clear the User must change password at next logon check box and select the Password never expires check box.

The DD_NewYork account is granted dial-in permissions either through the dial-in properties of the user account or through network policies.

Configuring Router 2

The configuration for demand-dial routing on Router 2 consists of the following three steps:

  1. Create a demand-dial interface.

  2. Create a static route.

  3. Create an account that Router 1 uses when calling Router 2.

Creating a demand-dial interface

By using Routing and Remote Access, the administrator at Router 2 creates a demand-dial interface called DD_Seattle with the following configuration:

  • Equipment: Modem on COM2

  • Phone number: 555-0111

  • Protocols: TCP/IP

  • Authentication credentials: DD_NewYork with a password

Creating a static route

By using Routing and Remote Access, the Demand-dial Interface wizard will already have the name and destination of the static route with the following configuration:

  • Interface: DD_Seattle

  • Destination: 172.16.1.0

  • Network mask: 255.255.255.0

  • Metric: 1

Note

Because the demand-dial connection is a point-to-point connection, the gateway IP address cannot be configured.

Creating an account with dial-in permissions

By using Active Directory Users and Computers or Local Users and Groups, the administrator at Router 2 creates a user account with the following settings:

  • Account name: DD_Seattle with a password.

  • Account settings: Clear the User must change password at next logon check box and select the Password never expires check box.

The DD_Seattle account is granted dial-in permissions either through the dial-in properties of the user account or through network policies.

Resulting configuration

The following illustration shows the demand-dial interfaces, static routes, and user accounts for the routers for the Seattle and New York offices.

Demand-dial routing configuration
Note

In order for two-way initiated demand-dial routing to work properly, authentication credentials (such as user account name) for the demand-dial interface must be created on both servers running Routing and Remote Access. This example shows a proper configuration and is summarized in the following table.

Router | Demand-dial interface name | User account name
Router 1 | DD_NewYork | DD_Seattle
Router 2 | DD_Seattle | DD_NewYork


Demand-Dial Connection Process

For a description of the demand-dial network used in the following process, see Demand-Dial Routing Example.

When the user at 172.16.1.10 tries to connect to a resource at 172.16.2.20, the following events occur:

  1. Packets from 172.16.1.10 destined for 172.16.2.20 are forwarded to Router 1.

  2. Router 1 receives the packet from 172.16.1.10 and checks its routing table. A route to 172.16.2.20 is found that uses the DD_NewYork interface.

  3. Router 1 checks the state of the DD_NewYork interface and finds it is in a disconnected state.

  4. Router 1 retrieves the configuration of the DD_NewYork demand-dial interface.

  5. Based on the DD_NewYork configuration, Router 1 uses the modem on COM1 to dial the number 555-0122.

  6. Router 2 answers the incoming call.

  7. Router 2 requests authentication credentials from the incoming caller.

  8. Router 1 sends the user name DD_Seattle with its associated password.

  9. Upon receipt of the authentication credentials, Router 2 checks the user name and password against the security features of the Windows Server® 2008 family and verifies that Router 1 has dial-in permission through the dial-in properties of the DD_Seattle user account and the configured network policies.

  10. Router 2 must now determine whether the incoming caller is a dial-up networking client or a router that is creating a demand-dial connection. Router 2 looks in its list of demand-dial interfaces to find one that matches the user name sent by Router 1 as part of the authentication credentials. Router 2 finds a demand-dial interface DD_Seattle that matches the user name credential.

  11. Router 2 changes the state of the DD_Seattle demand-dial interface to a connected state.

  12. Router 1 forwards the packet from the computer at 172.16.1.10 across the demand-dial connection to Router 2.

  13. Router 2 receives the packet and forwards it to the computer at 172.16.2.20.

  14. The response to the connection request by the computer at 172.16.1.10 is forwarded to Router 2 by the computer at 172.16.2.20.

  15. Router 2 receives the packet destined for 172.16.1.10 and checks its routing table. A route to 172.16.1.10 is found by using the DD_Seattle interface.

  16. Router 2 checks the state of the DD_Seattle interface and finds it is in a connected state.

  17. Router 2 forwards the packet to Router 1.

  18. Router 1 forwards the packet to the computer at 172.16.1.10.

If the user name credential does not match the name of an appropriate demand-dial interface, the calling entity is identified as a remote access client, which can result in routing problems.

For example, if Router 1 uses DialUpRouter1 as its user name credential, then Router 1 is identified as a remote access client rather than a router (assuming DialUpRouter1 is a valid account with dial-in permissions). Packets are routed from the user at 172.16.1.10 to the user at 172.16.2.20, as described in the preceding process.

However, response packets from 172.16.2.20 to 172.16.1.10 are forwarded to Router 2 which, upon inspecting its routing table, determines that the interface to use is DD_Seattle. DD_Seattle is in a disconnected state. Based on the configuration for DD_Seattle, COM2 is to be used. However, COM2 is currently being used for a remote access client (Router 2). Router 2 then tries to locate another modem that is not being used. If found, Router 2 dials Router 1 and forwards the packet after the connection has been established. If another modem cannot be found, the response packets from 172.16.2.20 to 172.16.1.10 are dropped.


Packet Filtering

Packet filtering

Routing and Remote Access supports IP packet filtering, which specifies which type of traffic is allowed into and out of the router. The packet filtering feature is based on exceptions. You can set packet filters per interface and configure them to do one of the following:

  • Pass through all traffic except packets prohibited by filters.

  • Discard all traffic except packets allowed by filters.

Adding a packet filter

To add a packet filter

  1. Open Routing and Remote Access.

  2. In the console tree, click General.

    Where?

    • Routing and Remote Access/server name/[IPv4 or IPv6]/General

  3. In the details pane, right-click the interface on which you want to add a filter, and then click Properties.

  4. On the General tab, click either Inbound Filters or Outbound Filters.

  5. In the Inbound Filters or Outbound Filters dialog box, click New.

  6. In the Add IP Filter dialog box, type the settings for the filter, and then click OK.

  7. In Filter action, select the appropriate filter action, and then click OK.

For more information about packet filtering, see, http://go.microsoft.com/fwlink/?LinkId=89010.

Protocols and ports for packet filtering

The following table details some of the common ports and protocols that you might want to allow, depending on your remote access configuration. Not all ports listed here are required for your remote access server. For example, if you are allowing only Layer Two Tunneling Protocol (L2TP), you would not configure a filter for Point-to-Point Tunneling Protocol (PPTP). Similarly, this table might not contain all of the ports that your network needs.
Ports used for protocols

Protocol | Port | Used For
TCP | 25 | Simple Mail Transfer Protocol (SMTP)
TCP | 67 | Dynamic Host Control Protocol (DHCP) (if the remote access server uses an external DHCP server)
TCP | 80 | World Wide Web (HTTP)
TCP | 110 | Post Office Protocol, version 3 (POP3)
TCP | 443 | SSTP (HTTP over SSL)
TCP | 1701 | L2TP
TCP | 1723 | PPTP
TCP | 7250 | Network Access Quarantine Control (Remote Access Quarantine Client (RQC) messages from client computers)
UDP | 53 | Domain Name Service (DNS) (for name resolution of external Web sites)
UDP | 67 | DHCP (if the remote access server uses an external DHCP server)
UDP | 500 | Internet Protocol security (IPsec)
UDP | 1701 | L2TP
UDP | 1723 | PPTP
UDP | 4500 | IPsec with network address translation (NAT)
 | 47 | Generic Routing Encapsulation (GRE)
 | 50 | Encapsulating Security Payload (ESP) (for firewalls that use NAT traversal [NAT-T])
Note

To support Windows Update, you must allow TCP traffic to travel inbound and outbound on port 80 and UDP traffic to travel inbound and outbound on port 53. Depending on your network configuration, you might have to configure these filters on your remote access server, on your firewall, or both.

Static packet filters and Windows Firewall

It is recommended that you enable packet filtering or Windows Firewall, but not both. Conflicts between two sets of filter rules can result in desired traffic being unexpectedly blocked.


Troubleshoot Routing and Remote Access

  • Troubleshooting Remote Access

  • Troubleshooting Routing


Troubleshooting Remote Access

  • VPN Troubleshooting Tools

  • Troubleshoot Remote Access


VPN Troubleshooting Tools

You can use the following tools and commands to troubleshoot virtual private network (VPN) connections:

TCP/IP troubleshooting tools

The Ping, Tracert, and Pathping tools use ICMP Echo and Echo Reply messages to verify connectivity, display the path to a destination, and test path integrity. The route print command can be used to display the IP routing table. Alternatively, you can use the netsh routing ip show rtmroutes command or the Routing and Remote Access snap-in.

In addition to the TCP/IP tools, use the Netdiag tool to test and display your network configuration.

Unreachability reason

When a demand-dial interface fails to make a connection, the interface is left in an unreachable state and the Routing and Remote Access service records the reason the connection attempt failed. To view the unreachable reason in the Routing and Remote Access snap-in, click Network Interfaces. In the details pane, right-click the demand-dial interface, and then click Unreachability Reason.

Authentication and accounting Logging

You can log authentication and accounting information for remote access connections in local logging files using Network Policy Server (NPS). This logging is separate from the events recorded in the system event log and can be used to track remote access usage and authentication attempts. For more information, see "RADIUS accounting" in NPS Help.

Event Logging

On the Logging tab in the properties of a VPN router in the Routing and Remote Access snap-in, there are four levels of logging. Select Log all events, and then try the connection again. After the connection fails, check the system event log for events logged during the connection process. After you have viewed remote access events, select the Log errors and warnings option on the Logging tab to conserve system resources.

PPP logging

PPP logging records the series of programming functions and PPP control messages during a PPP connection and is a valuable source of information when you are troubleshooting the failure of a PPP connection. To enable PPP logging, select the Log additional Routing and Remote Access information option on the Logging tab on the properties of a remote access server.

Tracing

The Routing and Remote Access service in Windows Server® 2008 has an extensive tracing capability that you can use to troubleshoot complex network problems. You can enable the components in Windows Server 2008 to log tracing information to files using the Netsh command or through the registry.

Enabling tracing with Netsh

You can use the Netsh command to enable and disable tracing for specified components or for all components. To enable and disable tracing for a specific component, use the following syntax:

netsh ras set tracing Component enabled|disabled

where Component is a component in the list of Routing and Remote Access service components found in the registry under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Tracing. For example, to enable tracing for the RASAUTH component, the command is:

netsh ras set tracing rasauth enabled

To enable tracing for all components, use the following command:

netsh ras set tracing * enabled

Enabling tracing through the registry

You can also configure the tracing function by changing settings in the registry under:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Tracing

You can enable tracing for each Routing and Remote Access service component by setting the registry values described later. You can enable and disable tracing for components while the Routing and Remote Access service is running. Each component is capable of tracing and appears as a subkey under the preceding registry key.

To enable tracing for each component, you can configure the following registry entries for each protocol key:

EnableFileTracing REG_DWORD Flag

You can enable logging tracing information to a file by setting EnableFileTracing to 1. The default value is 0.

FileDirectory REG_EXPAND_SZ Path

You can change the default location of the tracing files by setting FileDirectory to the path you want. The file name for the log file is the name of the component for which tracing is enabled. By default, log files are placed in the SystemRoot\Tracing folder.

FileTracingMask REG_DWORD LevelOfTracingInformationLogged

FileTracingMask determines how much tracing information is logged to the file. The default value is 0xFFFF0000.

MaxFileSize REG_DWORD SizeOfLogFile

You can change the size of the log file by setting different values for MaxFileSize. The default value is 0x10000 (64K).

Note

Tracing consumes system resources and should be used sparingly to help identify network problems. After the trace is captured or the problem is identified, you should immediately disable tracing. Do not leave tracing enabled on multiprocessor computers. Tracing information can be complex and very detailed. Most of the time this information is useful only to Microsoft support professionals or to network administrators who are very experienced with the Routing and Remote Access service. Tracing information can be saved as files and sent to Microsoft support for analysis.

Oakley logging

You can use the Oakley log to view details about the Internet Protocol security (IPsec) security association (SA) negotiation process. The Oakley log is enabled in the registry. It is not enabled by default. To enable the Oakley log, set the HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\PolicyAgent\Oakley\EnableLogging registry setting to 1. The Oakley key does not exist by default and must be created.

After it is enabled, the Oakley log, which is stored in the SystemRoot\Debug folder, records all IPsec SA negotiations. A new Oakley.log file is created each time the IPsec Policy Agent is started and the previous version of the Oakley.log file is saved as Oakley.log.sav.

To activate the new EnableLogging registry setting after modifying its value, stop and start the IPsec Policy Agent and related IPsec services by running the following sequence of commands:

  1. Stop the Routing and Remote Access service using the net stop remoteaccess command.

  2. Stop the IPsec services using the net stop policyagent command.

  3. Start the IPsec services using the net start policyagent command.

  4. Start the Routing and Remote Access service using the net start remoteaccess command.

Network Monitor

Use Network Monitor, a packet capture and analysis tool supplied with Windows Server 2008, to capture and view the traffic sent between VPN routers during the VPN connection process and during data transfer. You cannot interpret the encrypted portions of VPN traffic with Network Monitor. Download and install Network Monitor from the Microsoft Download Center (http://go.microsoft.com/fwlink/?LinkID=92844).

Interpretation of the VPN traffic with Network Monitor requires an in-depth understanding of PPP, PPTP, IPsec, and other protocols. Network Monitor captures can be saved as files and sent to Microsoft support for analysis.


Troubleshoot Remote Access

This topic lists a few common issues you might encounter when using Windows Server® 2008 remote access. For the most up-to-date troubleshooting information, see http://go.microsoft.com/fwlink/?LinkId=89011.

What problem are you having?

  • I received error 800, which says the VPN server is unreachable

  • I received error 721, which says the remote computer is not responding

  • I received error 741/742, which says there is an encryption mismatch error

  • I am unable to establish a remote access VPN connection

  • L2TP/IPsec authentication issues

  • EAP-TLS Authentication Issues

  • Connection attempt is accepted when it should be rejected

  • VPN clients are unable to access resources beyond the VPN server

  • Unable to establish tunnel

I received error 800, which says the VPN server is unreachable.
  • Cause: PPTP/L2TP packets from the VPN client cannot reach the VPN server.

  • Solution:

    • Assuming ping is allowed (that is, not blocked) between the VPN client and the VPN server, ping the VPN server. Confirm that you have network connectivity and that packet filters configured on the VPN server are not preventing communication.

    • By default, when you configure the Routing and Remote Access service for the VPN server role, only PPTP and L2TP/IPsec packets are allowed on the Internet interface of the VPN server. Internet Control Message Protocol (ICMP) packets used by the ping command are filtered out. To enable ping on the VPN server, add an input filter and an output filter that allow ICMP traffic.

    • To allow PPTP traffic, configure the network firewall to open TCP port 1723 and to forward IP protocol 47 for Generic Routing Encapsulation (GRE) traffic to the VPN server. Some firewalls refer to IP protocol 47 as VPN or PPTP pass-through. Not all firewalls support IP protocol 47. You might need to upgrade the firmware.

    • To allow L2TP traffic, configure the network firewall to open UDP port 1701 and to allow Internet Protocol security (IPsec) ESP formatted packets (IP protocol 50).

    • Check that the VPN server is listening for PPTP traffic on TCP port 1723 and is listening for L2TP traffic on UDP port 1701. On the VPN server, from the command line, type:

      netstat -aon

      You should see the following:

      TCP

      0.0.0.0:1723

      0.0.0.0:0

      LISTENING

      UDP

      0.0.0.0:1701

      *:*

    • You can use the Portqry command-line tool to determine if PPTP and L2TP packets are being dropped between the VPN client and VPN server. For more information, see Description of the Portqry.exe command-line utility (http://go.microsoft.com/fwlink/?LinkId=71609).

      To query the PPTP port, use the following command: portqry.exe -n <server_IP_address> -e 1723

      To query the L2TP port, use the following command: portqry.exe -n <server_IP_address> -e 1701 -p UDP

      If the query output includes "NOT LISTENING/FILTERED," check the port configuration on the server running Routing and Remote Access.

I received error 721, which says the remote computer is not responding.
  • Cause: This issue can occur if the network firewall does not permit GRE traffic (IP protocol 47). PPTP uses GRE for tunneled data.

  • Solution: Configure the network firewall between the VPN client and the server to permit GRE. In addition, make sure that the network firewall permits TCP traffic on port 1723. Both of these conditions must be met to establish VPN connectivity by using PPTP. For more information, see article 888201, "You receive an "Error 721" error message when you try to establish a VPN connection through your Windows Server-based remote access server" (http://go.microsoft.com/fwlink/?LinkId=71610).

Note

The firewall might be on or in front of the VPN client or in front of the VPN server.

I received error 741/742, which says there is an encryption mismatch error.
  • Cause: These errors occur if the VPN client requests an invalid encryption level or if the VPN server does not support an encryption type requested by the client.

  • Solution:

    • Check the properties (Security tab) of the VPN connection on the VPN client. If Require data encryption (disconnect if none) is selected, clear the selection and retry the connection.

    • If you are using Network Policy Server (NPS), check the encryption level in the network policy in the NPS console or policies on other RADIUS servers. Ensure that the encryption level requested by the VPN client is selected on the VPN server.

I am unable to establish a remote access VPN connection
  • Using the ping command, verify that the host name is being resolved to its correct IP address. The ping itself might not be successful due to packet filtering that is preventing the delivery of ICMP messages to and from the VPN server.

  • Verify that the credentials of the VPN client, which consist of user name, password, and domain name, are correct and can be validated by the VPN server.

  • Verify that the user account of the VPN client is not locked out, expired, disabled, or that the time the connection is being made does not correspond to the configured logon hours. If the password on the account has expired, verify that the remote access VPN client is using MS-CHAP v2. MS-CHAP v2 is the only authentication protocol provided with Windows Server 2008 that allows you to change an expired password during the connection process.

    For an administrator-level account whose password has expired, reset the password using another administrator-level account.

  • Verify that the user account has not been locked out due to remote access account lockout.

  • Verify that the Routing and Remote Access service is running on the VPN server.

  • Verify that the VPN server is enabled for remote access from the General tab on the properties of a VPN server in the Routing and Remote Access snap-in.

  • Verify that the WAN Miniport (PPTP) and WAN Miniport (L2TP) devices are enabled for inbound remote access from the properties of the Ports object in the Routing and Remote Access snap-in.

  • Verify that the VPN client, the VPN server, and the network policy corresponding to VPN connections are configured to use at least one common authentication method.

  • Verify that the VPN client and the network policy corresponding to VPN connections are configured to use at least one common encryption strength.

  • Verify that the parameters of the connection have permission through network policies.

    In order for the connection to be accepted, the parameters of the connection attempt must:

    • Match all of the conditions of at least one network policy.

    • Be granted network access permission through the user account (set to Allow access), or if the user account has the Control access through NPS Network Policy option selected, the network access permission of the matching network policy must have the Grant network access permission option selected.

    • Match all the settings of the profile.

    • Match all the settings of the dial-in properties of the user account.

    To obtain the name of the network policy that rejected the connection attempt, scan the accounting log for the entry corresponding to the connection attempt for the policy name. If NPS is being used as a RADIUS server, check the System event log for an entry for the connection attempt.

  • If you are logged on using an account with domain administrator permissions when you run the Routing and Remote Access Server Setup Wizard, it automatically adds the computer account of the RAS and IAS Servers domain-local security group. This group membership allows the VPN server computer to access user account information. If the VPN server is unable to access user account information, verify that:

    • The computer account of the VPN server computer is a member of the RAS and IAS Servers security group for all the domains that contain user accounts for which the VPN server is authenticating remote access. You can use the netsh ras show registeredserver command at the command prompt to view the current registration. You can use the netsh ras add registeredserver command to register the server in a domain in which the VPN server is a member or other domains. Alternatively, you or your domain administrator can add the computer account of the VPN server computer to the RAS and IAS Servers security group of all the domains that contain user accounts for which the VPN server is authenticating remote access.

    • If you add or remove the VPN server computer to the RAS and IAS Servers security group, the change does not take effect immediately (due to the way in which Windows Server 2008 caches Active Directory information). For the change to take effect immediately, you must restart the VPN server computer.

  • For a VPN server that is a member server in a mixed-mode or native-mode Active Directory® domain that is configured for Windows authentication, verify that:

    • The RAS and IAS Servers security group exists. If not, then create the group and set the group type to Security and the group scope to Domain local.

    • The RAS and IAS Servers security group has Read permission to the RAS and IAS Servers Access Check object.

  • Verify that IP is enabled for remote access on the VPN server.

  • Verify that all of the PPTP or L2TP ports on the VPN server are not already being used. If necessary, change the number of PPTP to L2TP ports from the properties of the Ports object in the Routing and Remote Access snap-in to allow more concurrent connections.

  • Verify that the VPN server supports the tunneling protocol of the VPN client.

    By default, Windows 2000 remote access VPN clients have the Automatic server type option selected, which means that they try to establish an L2TP/IPsec-based VPN connection first, then they try a PPTP-based VPN connection. If either the Point to Point Tunneling Protocol (PPTP) or Layer-2 Tunneling Protocol (L2TP) server type option is selected, verify that the selected tunneling protocol is supported by the VPN server.

    By default, Windows XP remote access VPN clients have the Automatic VPN type option selected, which means that they try to establish a PPTP -based VPN connection first, and then they try an L2TP/IPsec-based VPN connection. If either the PPTP VPN or L2TP IPsec VPN type is selected, verify that the VPN server supports the selected tunneling protocol.

    Depending on your selections when running the Routing and Remote Access Server Setup Wizard, a Windows Server 2008 computer running the Routing and Remote Access service is a PPTP and L2TP server with five or 128 L2TP ports and five or 128 PPTP ports. To create a PPTP-only server, set the number of L2TP ports to zero. To create an L2TP-only server, set the number of PPTP ports to 1 and disable remote access inbound connections and demand-dial connections for the WAN Miniport (PPTP) device from the properties of the Ports object in the Routing and Remote Access snap-in.

  • For L2TP/IPsec connections, verify that computer certificates, also known as machine certificates, are installed on the VPN client and the VPN server.

  • If the VPN server is configured with static IP address pools, verify that there are enough addresses. If all of the addresses in the static pools have been allocated to connected VPN clients, the VPN server is unable to allocate an IP address for TCP/IP-based connections, and the connection attempt is rejected.

  • Verify the configuration of the authentication provider. The VPN server can be configured to use either Windows or RADIUS to authenticate the credentials of the VPN client.

    • For RADIUS authentication, verify that the VPN server computer can communicate with the RADIUS server.

    • For a VPN server that is a member of a native-mode domain, verify that the VPN server has joined the domain.

  • For PPTP connections using MS-CHAP and attempting to negotiate 40-bit MPPE encryption, verify that the user's password is not longer than 14 characters.

L2TP/IPsec authentication issues

The following are the most common reasons that L2TP/IPsec connections fail:

  • No certificate

    By default, L2TP/IPsec connections require that the remote access server and remote access client exchange computer certificates for IPsec peer authentication. Check the Local Computer certificate stores of both the remote access client and remote access server using the Certificates snap-in to ensure that a suitable certificate exists.

  • Incorrect certificate

    If certificates exist, they must be verifiable. Unlike manually configuring IPsec rules, the list of certification authorities (CAs) for L2TP/IPsec connections cannot be configured. Instead, each computer in the L2TP connection sends a list of root CAs to its IPsec peer from which it accepts a certificate for authentication. The root CAs in this list correspond to the root CAs that issued computer certificates to the computer. For example, if Computer A was issued computer certificates by root CAs CertAuth1 and CertAuth2, it notifies its IPsec peer during main mode negotiation that it will accept certificates for authentication from only CertAuth1 and CertAuth2. If the IPsec peer, Computer B, does not have a valid computer certificate issued from either CertAuth1 or CertAuth2, IPsec security negotiation fails.

    The VPN client must have a valid computer certificate installed that was issued by a CA that follows a valid certificate chain from the issuing CA up to a root CA that the VPN server trusts. Additionally, the VPN server must have a valid computer certificate installed that was issued by a CA that follows a valid certificate chain from the issuing CA up to a root CA that the VPN client trusts.

    By default, L2TP/IPsec connections require that the remote access server and remote access client exchange computer certificates for IPsec peer authentication. Check the Local Computer certificate stores of both the remote access client and remote access server using the Certificates snap-in to ensure that a suitable certificate exists.

  • A NAT between the remote access client and remote access server

    If there is a NAT between a Windows 2000, Windows Server 2003, or Windows XP-based L2TP/IPsec client and a Windows Server 2008 L2TP/IPsec server, you cannot establish an L2TP/IPsec connection unless both the client and server support IPsec NAT-T.

  • A firewall between the remote access client and remote access server

    If there is a firewall between a Windows L2TP/IPsec client and a Windows Server 2008 L2TP/IPsec server and you cannot establish an L2TP/IPsec connection, verify that the firewall allows L2TP/IPsec traffic to be forwarded.

One of the best tools for troubleshooting IPsec authentication issues is the Oakley log. For more information, see VPN Troubleshooting Tools.

EAP-TLS authentication issues

When EAP-TLS is used for authentication, the VPN client submits a user certificate and the authenticating server (the VPN server or the RADIUS server) submits a computer certificate.

In order for the authenticating server to validate the certificate of the VPN client, the following must be true for each certificate in the certificate chain sent by the VPN client:

  • The current date must be within the validity dates of the certificate.

    When certificates are issued, they are issued with a range of valid dates, before which they cannot be used and after which they are considered expired.

  • The certificate has not been revoked.

    Issued certificates can be revoked at any time. Each issuing CA maintains a list of certificates that should no longer be considered valid by publishing an up-to-date certificate revocation list (CRL). By default, the authenticating server checks all the certificates in the certificate chain of the VPN clients (the series of certificates from the VPN client certificate to the root CA) for revocation. If any of the certificates in the chain have been revoked, certificate validation fails. This behavior can be modified with registry settings described later in this topic.

    To view the CRL distribution points for a certificate in the Certificates snap-in, obtain the certificate properties, click the Details tab, and then click the CRL Distribution Points field.

    The certificate revocation validation only works as well as the CRL publishing and distribution system. If the CRL in a certificate is not updated often, a certificate that has been revoked can still be used and considered valid because the published CRL that the authenticating server is checking is out of date.

  • The certificate has a valid digital signature.

    CAs digitally sign certificates they issue. The authenticating server verifies the digital signature of each certificate in the chain, with the exception of the root CA certificate, by obtaining the public key from the certificates' issuing CA and mathematically validating the digital signature.

The VPN client certificate must also have the Client Authentication certificate purpose (also known as Enhanced Key Usage [EKU]) (Object identifier 1.3.6.1.5.5.7.3.2) and must either contain a UPN of a valid user account or FQDN of valid computer account for the Subject Alternative Name property of the certificate.

To view the EKU for a certificate in the Certificates snap-in, double-click the certificate, click the Details tab, and then click the Enhanced Key Usage field. To view the subject alternative name property for a certificate in the Certificates snap-in, double-click the certificate, click the Details tab, and then click the Subject Alternative Name field.

Finally, to trust the certificate chain offered by the VPN client, the authenticating server must have the root CA certificate of the issuing CA of the VPN client certificate installed in its Trusted Root Certification Authorities store.

Additionally, the authenticating server verifies that the identity sent in the EAP-Response/Identity message is the same as the name in the Subject Alternative Name property of the certificate. This prevents a malicious user from masquerading as a different user from the one specified in the EAP-Response/Identity message.

In order for the VPN client to validate the certificate of the authenticating server for either EAP-TLS authentication, the following must be true for each certificate in the certificate chain sent by the authenticating server:

  • The current date must be within the validity dates of the certificate.

    When certificates are issued, they are issued with a range of valid dates, before which they cannot be used and after which they are considered expired.

  • The certificate has a valid digital signature.

    CAs digitally sign certificates they issue. The VPN client verifies the digital signature of each certificate in the chain, with the exception of the root CA certificate, by obtaining the public key from the certificates' issuing CA and mathematically validating the digital signature.

Additionally, the authenticating server computer certificate must have the Server Authentication EKU (Object identifier 1.3.6.1.5.5.7.3.1). To view the EKU for a certificate in the Certificates snap-in, double-click the certificate, click the Details tab, and then click the Enhanced Key Usage field.

Finally, to trust the certificate chain offered by the authenticating server, the VPN client must have the root CA certificate of the issuing CA of the authenticating server certificate installed in its Trusted Root Certification Authorities store.

Notice that the VPN client does not perform certificate revocation checking for the certificates in the certificate chain of the authenticating server's computer certificate. The assumption is that the VPN client does not yet have a connection to the network, and therefore cannot access a Web page or other resource to check for certificate revocation.

Connection attempt is accepted when it should be rejected
  • Verify that the network access permission on the user account is set to either Deny access or Control access through NPS Network Policy. If set to the latter, verify that the first matching network policy's network access permission is set to Deny Access. Deny access if the connection request matches this policy To obtain the name of the network policy that accepted the connection attempt, scan the accounting log for the entry corresponding to the connection attempt for the policy name.

  • If you have created a network policy to explicitly reject all connections, verify the policy conditions, network access permission, and profile settings.

VPN clients are unable to access resources beyond the VPN server
  • Verify that either the protocol is enabled for routing or that dial-in clients are allowed to access the entire network for LAN protocols being used by the VPN clients.

  • Verify the IP address pools of the VPN server.

    If the VPN server is configured to use a static IP address pool, verify that the routes to the range of addresses defined by the static IP address pools can be reached by the hosts and routers of the intranet. If not, then an IP route consisting of the VPN server static IP address pools, as defined by the IP address and mask of the range, must be added to the routers of the intranet or enable the routing protocol of your routed infrastructure on the VPN server. If the routes to the remote access VPN client subnets are not present, remote access VPN clients cannot receive traffic from locations on the intranet. Routes for the subnets are implemented either through static routing entries or through a routing protocol, such as Routing Information Protocol (RIP).

    If the VPN server is configured to use DHCP for IP address allocation and no DHCP server is available, the VPN server assigns addresses from the Automatic Private IP Addressing (APIPA) address range from 169.254.0.1 through 169.254.255.254. Allocating APIPA addresses for remote access clients works only if the network to which the VPN server is attached is also using APIPA addresses.

    If the VPN server is using APIPA addresses when a DHCP server is available, verify that the proper adapter is selected from which to obtain DHCP-allocated IP addresses. The Routing and Remote Access Server Setup Wizard assigns the default adapter automatically. You can manually choose a LAN adapter from the Adapter list on the IP tab on the properties of a VPN server in the Routing and Remote Access snap-in.

    If the static IP address pools are a range of IP addresses that are a subset of the range of IP addresses for the network to which the VPN server is attached, verify that the range of IP addresses in the static IP address pool are not assigned to other TCP/IP nodes, either through static configuration or through DHCP.

  • Verify that there are no packet filters on the profile properties of the network policy corresponding to VPN connections that are preventing the sending or receiving of traffic.

Unable to establish tunnel
  • Verify that packet filtering on a router interface between the VPN client and the VPN server is not preventing the forwarding of tunneling protocol traffic.

    On a VPN server running Windows Server 2008, IP packet filtering can be separately configured from the advanced TCP/IP properties and from the Routing and Remote Access snap-in. Check both places for filters that might be excluding VPN connection traffic.

  • Verify that the Winsock Proxy client is not currently running on the VPN client.

    When the Winsock Proxy client is active, Winsock API calls, such as those used to create tunnels and send tunneled data, are intercepted and forwarded to a configured proxy server.

    A proxy server-based computer allows an organization to access specific types of Internet resources (typically, Web and FTP) without directly connecting that organization to the Internet. The organization can instead use private IP network IDs (such as 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16).

    Proxy servers are typically used so that private users in an organization can have access to public Internet resources as if they were directly attached to the Internet. VPN connections are typically used so that authorized public Internet users can gain access to private organization resources as if they were directly attached to the private network. A single computer can act as a proxy server (for private users) and a VPN server (for authorized Internet users) to facilitate both exchanges of information.

Additional references

  • VPN and Firewalls

  • VPN Troubleshooting Tools


Troubleshooting Routing

  • Determine Whether the Router Is Receiving Routes

  • Understanding the IP Routing Table

  • View the Routing Table


Determine Whether the Router Is Receiving Routes

To troubleshoot routing problems, you should examine the routing table to determine if the router is receiving routes. If the Protocol column shows anything other than Local, the router is receiving routes.

Membership in the local Administrators group, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477.

To determine whether the router is receiving routes

  1. Open Routing and Remote Access.

  2. In the console tree, right-click Static Routes.

    Where?

    • Routing and Remote Access/server name/[IPv4 or IPv6]/Static Routes

  3. Click Show IP routing table.


Understanding the IP Routing Table

To troubleshoot routing problems, you must understand the routing table. Every computer that runs TCP/IP makes routing decisions that are determined by the IP routing table.

For information about displaying the IP routing table, see View the Routing Table.

The following illustration shows an example of a routing table.

The IP routing table

The IP routing table contains information in the following columns:

  • Destination

    The destination is the destination host, subnet address, network address, or default route. The destination for a default route is 0.0.0.0.

  • Network mask

    The network mask is used in conjunction with the destination to determine when a route is used. For example, a host route has a mask of 255.255.255.255, a default route has a mask of 0.0.0.0, and a subnet or network route has a mask between these two extremes.

    A mask of 255.255.255.255 means that only an exact match of the destination uses this route. A mask of 0.0.0.0 means that any destination can use this route. When a mask is written in binary, a 1 is significant (must match) and a 0 is insignificant (does not need to match).

    For example, a destination of 172.16.8.0 has a network mask of 255.255.248.0. This network mask means that the first two octets must match exactly, the first five bits of the third octet must match (248=11111000), and the last octet does not matter. The third octet of 172.16.8.0 (that is, 8) equals 00001000 in binary. Without changing the first 5 bits (the masked-off portion shown in bold), you can go up to 15, or 00001111 in binary. So a route with a destination of 172.16.8.0 and a mask of 255.255.248.0 applies to all packets destined for 172.16.8.0 through 172.16.15.255.

  • Gateway

    The gateway is the IP address of the next router where a packet must be sent. On a local area network (LAN) link (such as Ethernet or token ring), the gateway must be directly reachable by this router by using the interface indicated in the Interface column. On a LAN link, both the gateway and interface determine how the traffic is being forwarded by the router. For a demand-dial interface, the gateway address cannot be configured. On a point-to-point link, the interface determines how the traffic is being forwarded by the router.

  • Interface

    The interface indicates the LAN or demand-dial interface that is to be used to reach the next router.

  • Metric

    The metric indicates the relative cost of using the route to reach the destination. A typical metric is hops, or the number of routers to cross to reach the destination. If there are multiple routes with the same destination, the route with the lowest metric is the best route.

  • Protocol

    The protocol shows how the route was learned. If the Protocol column lists RIP, or anything other than Local, then the router is receiving routes.

Additional references

  • How IPv4 Unicast Routing Works


View the Routing Table

Every computer that runs TCP/IP makes routing decisions. These decisions are controlled by the IP routing table. The routing table is a series of entries called routes that contain information about other IP networks and IP hosts.

Membership in the local Administrators group, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477.

To view the routing table

  1. Open Routing and Remote Access.

  2. In the console tree, right-click Static Routes.

    Where?

    • Routing and Remote Access/server name/[IPv4 or IPv6]/Static Routes

  3. Click Show IP Routing Table.

The following table shows the detail views that are available in Routing and Remote Access by right-clicking the component.

Component | Views
[IPv4 or IPv6]/General | TCP/IP information
 | Multicast forwarding table
 | Multicast statistics
[IPv4 or IPv6]/General/Interface | TCP/IP information
 | Address translations
 | IP addresses
 | IP routing table
 | TCP connections
 | UDP listener ports
[IPv4 or IPv6]/Static Routes | IP routing table
[IPv4 or IPv6]/RIP | Neighbors
IP Routing/NAT | DHCP Allocator information
 | DNS Proxy information
[IPv4 or IPv6]/NAT/Interface | Mappings
[IPv4 or IPv6]/IGMP | Group table
[IPv4 or IPv6]/IGMP/Interface | Interface group table


Using the Ping Command

The ping command helps to verify IP-level connectivity. When troubleshooting, you can use ping to send an ICMP echo request to a target host name or IP address. Use ping whenever you need to verify that a host computer can connect to the TCP/IP network and network resources. You can also use ping to isolate network hardware problems and incompatible configurations.

Follow this sequence to diagnose network connectivity:

  1. Ping the loopback address to verify that TCP/IP is configured correctly on the local computer.

    ping 127.0.0.1

  2. Ping the IP address of the local computer to verify that it was added to the network correctly.

    ping IP_address_of_local_host

  3. Ping the IP address of the default gateway to verify that the default gateway is functioning and that you can communicate with a local host on the local network.

    ping IP_address_of_default_gateway

  4. Ping the IP address of a remote host to verify that you can communicate through a router.

    ping IP_address_of_remote_host

The following table shows some useful ping command options.

Option | Use
-n Count | Determines the number of echo requests to send. The default is 4 requests.
-w Timeout | Enables you to adjust the timeout (in milliseconds). The default is 1,000 (a 1-second timeout).
-l Size | Enables you to adjust the size of the ping packet. The default size is 32 bytes.
-f | Sets the Do Not Fragment bit on the ping packet. By default, the ping packet allows fragmentation.
/? | Provides command Help.

The following example illustrates how to send two pings, each 1,450 bytes in size, to IP address 131.107.8.1:

C:\>ping -n 2 -l 1450 131.107.8.1
Pinging 131.107.8.1 with 1450 bytes of data:

Reply from 131.107.8.1: bytes=1450 time<10ms TTL=32
Reply from 131.107.8.1: bytes=1450 time<10ms TTL=32

Ping statistics for 131.107.8.1:
    Packets: Sent = 2, Received = 2, Lost = 0 (0% loss),
Approximate roundtrip times in milliseconds:
    Minimum = 0ms, Maximum =  10ms, Average =  2ms

By default, ping waits 4,000 milliseconds (4 seconds) for each response to be returned before displaying the "Request Timed Out" message. If the remote system being pinged is across a high-delay link, such as a satellite link, responses might take longer to be returned. You can use the -w (wait) option to specify a longer timeout.

A response of "Destination net unreachable" means there was no route to the destination. You need to check the routing table on the router listed in the "Reply from" address in the "Destination net unreachable" message. For more information about the routing table, see Manage the IPv4 Routing Table.

A response of "Request timed out" means that there was no response to the ping in the default time period (1 second). You can check for the following:

  • The ping command is blocked at the corporate or personal firewall level.

    Configure the corporate firewall to allow the ping command network access. Configure the personal firewall to allow ICMP Echo and Echo Reply packets.

  • A router is down.

    To check the routers in the path between the source and the destination, use the tracert command.

  • The destination host is down.

    Physically verify that the host is running or check connectivity through another protocol.

  • There is no route back to your computer.

    If the host is running, you can check for a return route by viewing the default gateway and local routing table on the destination host.

  • The latency of the response is more than one second.

    Use the -w option on the ping command to increase the timeout. For example, to allow responses within 5 seconds, use ping -w 5000.

The ping command uses Windows Sockets-style name resolution to resolve a computer name to an IP address, so if pinging by address succeeds, but pinging by name fails, then the problem lies in address or name resolution, not network connectivity.


Resources for Routing and Remote Access

  • For more information about Routing and Remote Access, VPN, and routing, see http://go.microsoft.com/fwlink/?LinkId=48552.


User Interface: Routing and Remote Access

No content is currently available for this topic.


Demand-Dial Interface Wizard - Connection Type

For dial-up networking access, the dial-up server must have at least one modem or a multiport adapter, and analog telephone lines or other WAN connections.

Dialog box element | Description
Connect using a modem, ISDN adapter, or other physical device. | A dial-up connection connects you to a network or the Internet by using a device that utilizes the telephone network. This device can be a modem that uses a standard phone line, an ISDN adapter with a high-speed ISDN line, DSL, broadband, or a cable modem.
Connect using a virtual private network (VPN) | A virtual private network (VPN) extends the capabilities of a private network to encompass links across shared or public networks such as the Internet. With a VPN, you can send data between two computers across a shared or public network in a manner that emulates a point-to-point link on a private network.
Connect using PPP over Ethernet (PPPoE) | Using Point-to-Point Protocol over Ethernet (PPPoE) and a broadband modem, LAN clients can gain individual authenticated access to high-speed data networks. By combining Ethernet and Point-to-Point Protocol (PPP), PPPoE provides an efficient way to create a separate connection to a remote server for each user. Access, billing, and choice of service are managed on a per-user basis, rather than a per-site basis. Clients can create both dial-up and dial-on-demand connections using PPPoE.


Demand-Dial Interface Wizard - Protocols and Security

Dialog box element | Description
Route IP packets on this interface. | Specifies whether IP routing, the forwarding of IP packets from one routing interface to another, is enabled on this interface. You must enable IP routing in order for LAN and demand-dial routing to occur.
Add a user account so a remote router can dial in. | Anyone calling the server running Routing and Remote Access must be authenticated and authorized. Authentication is based on the caller's set of credentials that are passed during the connection establishment process. The credentials that are passed must correspond to a user account. Authorization is granted based on the dial-in permission of the user account and network policies.
Send a plain-text password if that is the only way to connect. | Use this option if the remote router doesn’t support encryption or the type of encryption supported by the local router.
Use scripting to complete the connection with the remote router. | Scripts can be used to automate the logon process and other connection tasks.


Devices and Ports

A server running Routing and Remote Access views the installed networking equipment as a series of devices and ports.

Membership in the local Administrators group, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477.

Device

A device is the hardware or software that provides ports that remote access connections can use to establish point-to-point connections. Devices are physical, such as a modem, or virtual, such as virtual private network (VPN) protocols. Devices can support a single port, such as a modem, or multiple ports, such as modem bank hardware that can terminate 64 different incoming analog phone calls. Point-to-Point Tunneling Protocol (PPTP) and Layer Two Tunneling Protocol (L2TP) are examples of virtual multiport devices. Each of these tunneling protocols supports multiple VPN connections.

To see the installed devices, you can view the properties of Ports in Routing and Remote Access.

Port

A port is a channel of a device that can support a single point-to-point connection. For single-port devices such as modems, the device and the port are indistinguishable. For multiport devices, the port is the subdivision of the device over which a separate point-to-point connection is possible. For example, Primary Rate Interface (PRI) ISDN adapters support two separate channels called B channels. The ISDN adapter is a device. Each B channel is a port because a separate point-to-point connection can occur over each B channel.

You can view the dial-up ports by clicking Ports in Routing and Remote Access.


IPv4

IPv4 addressing

For IP version 4, each TCP/IP host is identified by a logical IP address. The IP address is a Network layer address and has no dependence on the Data-Link layer address (such as a MAC address of a network adapter). A unique IP address is required for each host and network component that communicates using TCP/IP and can be assigned manually or by using Dynamic Host Configuration Protocol (DHCP).

The IP address identifies a system’s location on the network in the same way a street address identifies a house on a city block. Just as a street address must identify a unique residence, an IP address must be globally unique to the network and have a uniform format.

Each IP address includes a network ID and a host ID.

  • The network ID (also known as a network address) identifies the systems that are located on the same physical network bounded by IP routers. All systems on the same physical network must have the same network ID. The network ID must be unique to the network.

  • The host ID (also known as a host address) identifies a workstation, server, router, or other TCP/IP host within a network. The host address must be unique to the network ID.

IPv4 address syntax

An IP address consists of 32 bits. Instead of expressing IPv4 addresses 32 bits at a time using binary notation (Base2), it is standard practice to segment the 32 bits of an IPv4 address into four 8-bit fields called octets. Each octet is converted to a decimal number (base 10) from 0–255 and separated by a period (a dot). This format is called dotted decimal notation. The following table provides an example of an IP address in binary and dotted decimal formats.

An IP Address in Binary and Dotted Decimal Formats

Binary Format | Dotted Decimal Notation
11000000 10101000 00000011 00011000 | 192.168.3.24

For example, the IPv4 address of 11000000101010000000001100011000 is:

  • Segmented into 8-bit blocks: 11000000 10101000 00000011 00011000.

  • Each block is converted to decimal: 192 168 3 24

  • The adjacent octets are separated by a period: 192.168.3.24.

The notation w.x.y.z is used when referring to a generalized IP address, and is shown the following figure.

IP Address

Types of IPv4 addresses

The Internet standards define the following types of IPv4 addresses:

  • Unicast. Assigned to a single network interface located on a specific subnet on the network and used for one-to-one communications.

  • Multicast. Assigned to one or more network interfaces located on various subnets on the network and used for one-to-many communications.

  • Broadcast. Assigned to all network interfaces located on a subnet on the network and used for one-to-everyone-on-a-subnet communications.

The following sections describe these types of addresses in detail.

IPv4 unicast addresses

The IPv4 unicast address identifies an interface’s location on the network in the same way a street address identifies a house on a city block. Just as a street address must identify a unique residence, an IPv4 unicast address must be globally unique to the network and have a uniform format.

Each IPv4 unicast address includes a network ID and a host ID.

  • The network ID (also known as a network address) is the fixed portion of an IPv4 unicast address that identifies the set of interfaces that are located on the same physical or logical network segment as bounded by IPv4 routers. A network segment on TCP/IP networks is also known as a subnet. All systems on the same physical or logical subnet must use the same network ID and the network ID must be unique to the entire TCP/IP network.

  • The host ID (also known as a host address) is the variable portion of an IPv4 unicast address that is used to identify a network node’s interface on a subnet. The host ID must be unique to the network ID.

If the network ID is unique to the TCP/IP network and the host ID is unique to the network ID, then the entire IPv4 unicast address consisting of the network ID and host ID is unique to the entire TCP/IP network.

IPv4 multicast addresses

IPv4 multicast addresses are used for single-packet one-to-many delivery. On an IPv4 multicast-enabled intranet, an IPv4 packet addressed to an IPv4 multicast address is forwarded by routers to the subnets on which there are hosts listening to the traffic sent to the IPv4 multicast address. IPv4 multicast provides an efficient one-to-many delivery service for many types of communication.

IPv4 multicast addresses are defined by the class D Internet address class: 224.0.0.0/4. IPv4 multicast addresses range from 224.0.0.0 through 239.255.255.255. IPv4 multicast addresses for the 224.0.0.0/24 address prefix (224.0.0.0 through 224.0.0.255) are reserved for local subnet multicast traffic.

IPv4 broadcast addresses

IPv4 uses a set of broadcast addresses to provide a one-to-everyone on the subnet delivery service. Packets sent to IPv4 broadcast addresses are processed by all the interfaces on the subnet. The following are the different types of IPv4 broadcast addresses:

  • Network broadcast. Formed by setting all the host bits to 1 for a classful address prefix. An example of a network broadcast address for the classful network ID 131.107.0.0/16 is 131.107.255.255. Network broadcasts are used to send packets to all interfaces of a classful network. IPv4 routers do not forward network broadcast packets.

  • Subnet broadcast. Formed by setting all the host bits to 1 for a classless address prefix. An example of a network broadcast address for the classless network ID 131.107.26.0/24 is 131.107.26.255. Subnet broadcasts are used to send packets to all hosts of a classless network. IPv4 routers do not forward subnet broadcast packets. For a classful address prefix, there is no subnet broadcast address, only a network broadcast address. For a classless address prefix, there is no network broadcast address, only a subnet broadcast address.

  • All-subnets-directed broadcast. Formed by setting all the original classful network ID host bits to 1 for a classless address prefix. A packet addressed to the all-subnets-directed broadcast was defined to reach all hosts on all of the subnets of a subnetted class-based network ID. An example of an all-subnets-directed broadcast address for the subnetted network ID 131.107.26.0/24 is 131.107.255.255. The all-subnets-directed broadcast is the network broadcast address of the original classful network ID. IPv4 routers can forward all-subnets directed broadcast packets, however the use of the all-subnets-directed broadcast address is deprecated in RFC 1812.

  • Limited broadcast. Formed by setting all 32 bits of the IPv4 address to 1 (255.255.255.255). The limited broadcast address is used for one-to-everyone delivery on the local subnet when the local network ID is unknown. IPv4 nodes typically only use the limited broadcast address during an automated configuration process such as Boot Protocol (BOOTP) or DHCP. For example, with DHCP, a DHCP client must use the limited broadcast address for all traffic sent until the DHCP server acknowledges the use of the offered IPv4 address configuration. IPv4 routers do not forward limited broadcast packets.


IPv4 - DHCP Relay Agent

The DHCP Relay Agent component is a Bootstrap Protocol (BOOTP) relay agent that relays Dynamic Host Configuration Protocol (DHCP) messages between DHCP clients and DHCP servers on different IP networks. The DHCP Relay Agent is compliant with RFC 1542, "Clarifications and Extensions for the Bootstrap Protocol." For each IP network segment that contains DHCP clients, either a DHCP server or a computer acting as a DHCP Relay Agent is required.

Note

  • You cannot use the DHCP Relay Agent component on a computer running the DHCP service, the network address translation (NAT) routing protocol component with automatic addressing enabled, or Internet Connection Sharing (ICS).


IPv4 - DHCP Relay Agent Interface Properties - General Tab

Dialog box element Description

Relay DHCP packets

Specifies whether DHCP messages are relayed between DHCP clients on the subnet to which this interface is attached and DHCP servers.

After you select this check box, you must configure the DHCP server addresses in the DHCP Relay Agent Properties dialog box.

Hop-count threshold

The maximum number of DHCP relay agents that will handle DHCP relayed traffic. You can also click the arrows to select a new setting. The default value is 4 hops. The maximum value is 16 hops.

Boot threshold (seconds)

The number of seconds the relay agent waits before forwarding DHCP messages. You can also click the arrows to select a new setting. The default value is 4 seconds.

This option is useful when you want a local DHCP server to respond first, but if the local DHCP server does not respond, you want to forward messages to a remote DHCP server.


IPv4 - DHCP Relay Agent Properties - General Tab

Dialog box element Description

Server address

The IP address of the DHCP server you want to add.

Server address list

Lists the IP addresses of DHCP servers on the network. The router acts as a DHCP relay agent by relaying DHCP messages between DHCP clients and the DHCP servers specified in this list. You must add at least one address to be a relay agent.

For the DHCP relay agent to work, you must select the Relay DHCP packets check box on at least one interface that has been added to the DHCP Relay Agent routing protocol.


IPv4 - General

Routing interface

The server running Routing and Remote Access uses a routing interface to forward unicast IP and multicast IP packets. There are two types of routing interfaces:

  • LAN interfaces

    A LAN interface is a physical interface that typically represents a local area connection that uses local area networking technology such as Ethernet or token ring. A LAN interface reflects an installed network adapter. An installed WAN adapter is sometimes represented as a LAN interface. For example, some Frame Relay adapters create a separate logical LAN interface for each configured virtual circuit. LAN interfaces are always active and typically do not require an authentication process to become active.

  • Demand-dial interfaces

    A demand-dial interface is a logical interface that represents a point-to-point connection. The point-to-point connection is based on either a physical connection, such as two routers connected over an analog phone line that uses modems, or a logical connection, such as two routers connected over a virtual private network connection that uses the Internet. Demand-dial connections are either on-demand (the point-to-point connection is only established when needed) or persistent (the point-to-point connection is established and then remains in a connected state). Demand-dial interfaces typically require an authentication process to become connected. The equipment needed by a demand-dial interface is a port on a device.


IPv4 - General - Interface Properties - General Tab

IP Interface

Dialog box element | Description
Enable IP router manager | Specifies whether TCP/IP is enabled on this interface. Select this check box to set the Administrative Status of the interface to Up. Clear this check box to set the Administrative Status of the interface to Down.
Enable router discovery advertisements | Specifies whether Internet Control Message Protocol (ICMP) router discovery advertisements are enabled over this interface. Router discovery clients use these messages to dynamically configure their default gateways. Router discovery is implemented by using multicast ICMP router advertisement messages.
Advertisement lifetime (minutes) | The number of minutes that a router discovery advertisement from this router and this interface is valid. The default is 30 minutes.
Level of preference | The preference level of using this interface as the default gateway. A higher number means that this gateway is more preferred by router discovery clients as the default gateway.
Minimum time (minutes) | The minimum number of minutes between router discovery advertisement packets. The default is 7 minutes. The router advertisement is sent at a random interval between the minimum time and the maximum time.
Maximum time (minutes) | The maximum number of minutes between router discovery advertisement packets. The default is 10 minutes. The router advertisement is sent at a random interval between the minimum time and the maximum time.
Enable fragmentation checking | Specifies whether the router discards all fragmented IP packets that do not correspond with traffic allowed by the filters configured for this interface.

Inbound and Outbound Filters

Dialog box element Description

Receive all packets except those that meet the criteria below

For inbound filters: Specifies that all incoming packets that match the filters listed are discarded. All incoming packets are compared to the filters listed. If a packet matches a filter, the packet is dropped. If the packet does not match a filter, the packet is accepted.

For outbound filters: Specifies that all outgoing packets that match the filters listed are discarded. All outgoing packets are compared to the filters listed. If a packet matches a filter, the packet is dropped. If the packet does not match a filter, the packet is transmitted.

This option applies to all the filters that you have added. You cannot change this option for individual filters.

You can only configure this option after you have added at least one filter.

Drop all packets except those that meet the criteria below

For inbound filters: Specifies that all incoming packets that match the filters listed are accepted. All incoming packets are compared to the filters listed. If a packet matches a filter, the packet is accepted. If the packet does not match a filter, the packet is dropped.

For outbound filters: Specifies that all outgoing packets that match the filters listed are transmitted. All outgoing packets are compared to the filters listed. If a packet matches a filter, the packet is transmitted. If the packet does not match a filter, the packet is dropped.

This option applies to all the filters that you have added. You cannot change this option for individual filters.

You can only configure this option after you have added at least one filter.

New

Click to add a filter. You can set filters based on where the packet is coming from (the source), where the packet is going (the destination), or what protocol the packet is using. You can set all three of these values for a filter or set any one or combination of the three, depending on the level of control that you want.

Add IP Filter

Dialog box element | Description
Source network | Specifies whether the filter checks the network from which the packet is coming. After selecting this check box, you must specify a network IP address and subnet mask.
Destination network | Specifies whether the filter checks the network to which the packet is going. After selecting this check box, you must specify a network address and subnet mask.
IP address | The IP address of the network from which the packet was sent or to which the packet is going. You must also specify a subnet mask.
Subnet mask | The subnet mask that corresponds to the network IP address.
Protocol | Lists the available protocol types that you can base a filter on. The default is Any protocol. If you select Other, you must type a protocol identifier in Protocol number.
Source port | For TCP, TCP (established), and UDP protocols, provides a space for you to type the port number specified by the source to be used by the filter. Some applications use well-known ports to send and receive packets. You can set a filter for one of these ports if you know what numbers the application uses for the protocol specified in Protocol. For example, you can try to block FTP traffic or allow only PPTP traffic.
Destination port | For TCP, TCP (established), and UDP protocols, type the port number used by the destination for the packet.
ICMP type | The ICMP type.
ICMP code | The ICMP code.
Protocol number | The IP protocol number.


IPv4 - General - Interface Properties - Multicast Boundaries Tab

Dialog box element | Description
Scope | Lists the available multicast scopes that are configured on the Multicast Scopes tab in the properties of IP Routing-General. A multicast scope is a named range of IP multicast addresses that is defined by an IP address and mask.
Scope Name | Lists the scopes for the multicast traffic that will not be forwarded out this interface.
Activate TTL boundary | Specifies whether the router performs Time-to-Live (TTL) scoping to prevent the forwarding of IP multicast traffic out this interface with a TTL less than a specified value. TTL scoping applies to all multicast packets regardless of the multicast group.
TTL value | The maximum TTL for multicast traffic that is forwarded out this interface.
Rate limit (KBps) | The maximum rate (in kilobytes per second) for all multicast traffic forwarded by this interface.

See Also

  • What Is IPv4 Multicasting?


IPv4 - General - Interface Properties - Multicast Heartbeat Tab

Dialog box element | Description
Enable multicast heartbeat detection | Specifies whether the router listens for a regular multicast notification that is sent to a configured IP multicast group address to verify that IP multicast connectivity is available on the network. Multicast heartbeat listens for a periodic multicast announcement to a specific group address. If the announcement is not received by the quiet time, the router sets the multicast heartbeat status on the configured interface to inactive. The multicast heartbeat status for the interface can be polled by a program to provide notification that the multicast heartbeat is no longer present.
Multicast heartbeat group | The IP address (in dotted decimal notation) of the multicast group.
Quiet time before alerting (minutes) | The number of minutes the router waits before setting the multicast heartbeat status on the interface to inactive.

See Also

  • What Is IPv4 Multicasting?


IPv4 - General Properties - Logging Tab

Dialog box element | Description
Log errors only | Specifies that only errors are logged in the System Log in Event Viewer.
Log errors and warnings | Specifies that errors and warnings are logged in the System Log in Event Viewer.
Log all events | Specifies that the maximum amount of information is logged in the System Log in Event Viewer.
Disable event logging | Specifies that no events are logged in the System Log in Event Viewer.

See Also

  • Troubleshoot Routing and Remote Access


IPv4 - General Properties - Multicast Scopes Tab

Multicast Scopes

Dialog box element | Description
Scope Name | Lists the configured multicast scopes. A multicast scope is a named range of IP multicast addresses that is expressed with an IP address and mask. Once multicast scopes are configured, you can use them to create scope-based multicast boundaries in the properties of an IP routing interface.

Add Scoped Boundary

Dialog box element | Description
Scope name | The name of the scope to use when configuring multicast boundaries. A scope is a range of multicast IP addresses.
IP address | The IP address for the administrative multicast scope (in dotted decimal notation). Valid administrative, nonlocal, multicast scopes must be in the range 239.0.0.0 through 239.254.255.255.
Mask | The mask for the scope (in dotted decimal notation).

See Also

  • What Is IPv4 Multicasting?


IPv4 - General Properties - Preference Levels Tab

Dialog box element | Description
Route Source | Lists the preference level of the route sources. If two routes exist to the same destination, the route learned by the route source with a higher preference is preferred regardless of the route metric.
Move Up | Raises the preference level for a selected route source by increasing its rank number.
Move Down | Lowers the preference level for a selected route source by decreasing its rank number.


IPv4 - IGMP

Internet Group Management Protocol (IGMP) is a protocol that manages host membership in IP multicast groups on a network segment. An IP multicast group, also known as a host group, is a set of hosts that listen for IP traffic destined for a specific IP multicast address. IP multicast traffic is sent to a single MAC address but processed by multiple IP hosts. A specific host listens on a specific IP multicast address and receives all packets to that IP address.

The following are some of the additional aspects of IP multicasting:

  • Host group membership is dynamic, hosts can join and leave the group at any time.

  • A host group can be of any size.

  • Members of a host group can span IP routers across multiple networks. This situation requires IP multicast support on the IP routers and the ability for hosts to register their group membership with local routers. Host registration is accomplished using IGMP.

  • A host can send traffic to an IP multicast address without belonging to the corresponding host group.

For a host to receive IP multicasts, an application must inform IP that it will receive multicasts at a specified IP multicast address. If the network technology supports hardware-based multicasting, the network interface is told to pass up packets for a specific IP multicast address. In the case of Ethernet, the network adapter is programmed to respond to a multicast MAC address corresponding to the specified IP multicast address.

A host supports IP multicast at one of the following levels:

  • Level 0: No support to send or receive IP multicast traffic.

  • Level 1: Support exists to send but not receive IP multicast traffic.

  • Level 2: Support exists to both send and receive IP multicast traffic. Windows Server® 2008, Windows Server 2003, Windows 2000, Microsoft Windows NT version 3.5 and later, and TCP/IP support level 2 IP multicasting.

The protocol to register host group information is IGMP, which is required on all hosts that support level 2 IP multicasting. IGMP packets are sent using an IP header.

The protocol to register host group information is IGMP, which is required on all hosts that support level 2 IP multicasting. IGMP packets are sent using an IP header.

IGMP messages take three forms.

  • Host Membership Report. When a host joins a host group, it sends an IGMP Host Membership Report message to the all-hosts IP multicast address (224.0.0.1) or to the specified IP multicast address declaring its membership in a specific host group by referencing the IP multicast address. A host can also specify the specific sources from which multicast traffic is needed.

  • Host Membership Query. When a router polls a network to ensure that there are members of a specific host group, it sends an IGMP Host Membership Query message to the all-hosts IP multicast address. If no responses to the poll are received after several polls, the router assumes no membership in that group for that network and stops advertising that multicast group information to other routers.

  • Group Leave. When a host is no longer interested in receiving multicast traffic sent to a specific IP multicast address and it sent the last IGMP Host Membership Report message in response to an IGMP Host Membership Query, it sends an IGMP Group Leave message to the specific IP multicast address. Local routers verify that the host sending the IGMP Group Leave message is the last group member for that multicast address on that subnet. If no responses to the poll are received after several polls, the router assumes no membership in that group for that subnet and stops advertising that multicast group information to other routers.

IGMP messages are encapsulated and sent within IP datagrams as shown in the following illustration.

IGMP encapsulation in an IP datagram

For IP multicasting to span routers across an network, multicast routing protocols are used by routers to communicate host group information so that each router supporting multicast forwarding is aware of which networks contain members of which host groups. IGMP is defined in RFCs 1112 and 2236.


IPv4 - IGMP Interface Properties - General Tab

Dialog box element | Description
Enable IGMP | Specifies whether the Internet Group Management Protocol (IGMP) is enabled for multicast forwarding on this interface. IGMP is used by hosts to register membership in IP multicast groups. Enabling IGMP on this interface allows the router to either listen for IGMP messages sent by hosts or forward IGMP messages received on other interfaces.
IGMP router | Specifies that IGMP router mode is enabled on this interface. An interface in IGMP router mode listens for IGMP messages from hosts and updates the TCP/IP multicast forwarding table.
IGMP proxy | Specifies that IGMP proxy mode is enabled on this interface. An interface in IGMP proxy mode acts as a host, forwarding IGMP host membership messages for all IGMP host membership messages received on all other interfaces on which IGMP router mode is enabled. Additionally, all nonlocal multicast traffic received on all other interfaces (on which IGMP router mode is enabled) is forwarded over the IGMP proxy mode interface.
IGMP protocol version | Lists the version of IGMP supported on this interface.


IPv4 - IGMP Interface Properties - Router Tab

Dialog box element Description

Robustness variable

The robustness variable is a way of indicating the lossy nature of the subnet to which this interface is attached. IGMP can recover from lost IGMP packets (robustness variable is set to 1). You should set the robustness variable to a value of 2 or greater. The default robustness variable is 2.

Query interval (seconds)

The query interval is the amount of time in seconds between IGMP General Query messages sent by the router (if the router is the querier on this subnet). The default query interval is 125 seconds.

Query response interval (seconds)

The query response interval is the maximum amount of time in seconds that the IGMP router waits to receive a response to a General Query message. The default query response interval is 10 seconds and must be less than the query interval.

Last member query interval (milliseconds)

The last member query interval is the amount of time in milliseconds that the IGMP router waits to receive a response to a Group-Specific Query message. The last member query interval is also the amount of time in seconds between successive Group-Specific Query messages. The default last member query interval is 1 second.

Startup query interval (seconds)

The startup query interval is the amount of time in seconds between successive General Query messages sent by a querier during startup. The default startup query interval is ¼ of the query interval.

Startup query count

The startup query count is the number of general query messages sent at startup.

Last member query count

The last member query count is the number of Group-Specific Query messages sent before the router assumes there are no members of the host group being queried on this interface. The default last member query count is 2.

Automatically recalculate defaults

Specifies whether the values in Startup query interval, Startup query count, and Last member query count are calculated automatically based on the following:

  • The startup query interval is ¼ of the value for the query interval.

  • The startup query count is the same value as the robustness variable.

  • The last member query count is the same value as the robustness variable.

Group membership interval (seconds)

Displays the calculated group membership interval. The group membership interval is the number of seconds that must pass before a multicast router determines that there are no more members of a host group on a subnet. The group membership interval is (robustness variable) * (query interval) + (query response interval).

Other querier present interval

Displays the calculated other querier present interval. The other querier present interval is the number of seconds that must pass before a multicast router determines that there is no other multicast router that should be the querier. The other querier present interval is (robustness variable) * (query interval) + (query response interval)/2.


IPv4 - IGMP Properties - General Tab

Dialog box element | Description
Log errors only | Specifies that only errors are logged in the System Log in Event Viewer.
Log errors and warnings | Specifies that errors and warnings are logged in the System Log in Event Viewer.
Log all events | Specifies that the maximum amount of information is logged in the System Log in Event Viewer.
Disable event logging | Specifies that no events are logged in the System Log in Event Viewer.

See Also

  • Troubleshoot Routing and Remote Access


IPv4 - NAT - Interface Properties - Address Pool Tab

Note

After selecting the network interface, the Address Pool tab will appear when Public interface connected to the Internet is selected on the NAT tab.

Address Pool

Dialog box element | Description
Address list | Lists the configured ranges of public IP addresses assigned to you. The address ranges are typically obtained from your Internet service provider.
Reservations | Click to reserve specific public IP addresses from the configured ranges that cannot be used for address translation. Reserved public IP addresses can be used for Internet Web servers that are placed on the private network. You cannot configure a reservation until you configure at least one IP address pool.

Add Address Pool

Dialog box element | Description
Start address | The IP address (in dotted decimal notation) of the starting number of your public address pool.
Mask | The subnet mask (in dotted decimal notation) for your public address pool.
End address | The IP address (in dotted decimal notation) of the ending number of your public address pool.

Reserve Address

Dialog box element | Description
Address list | Lists the configured reservations. Each reservation maps a specific public IP address from the public address pool to a specific private address. Reserved public IP addresses are not used for dynamically mapped traffic.

Add Reservation

Dialog box element | Description
Reserve this public IP address | The IP address in the public address pool that is being reserved.
For this computer on the private network | The IP address of the private network computer that you want to make available to public network users.
Allow incoming sessions to this address | Specifies whether sessions from the public network are allowed. If you are setting up a server, such as a Web server, and you want to make it accessible for Internet users, select this check box. Normally, the only traffic that is allowed from the public network is traffic sent in response to sessions initiated from the private network.


IPv4 - NAT - Interface Properties - NAT Tab

Dialog box element | Description
Private interface connected to private network | Specifies that this interface is a private interface that is connected to the private network.
Public interface connected to the Internet | Specifies that this interface is the public interface that is connected to the Internet.
Enable NAT on this interface | Specifies whether the router performs TCP port and UDP port translation in addition to IP address translation. If you only have a single public IP address, you must select this check box. Otherwise, network traffic from hosts on the private network cannot be properly translated to Internet traffic.

See Also

  • Network Address Translation


IPv4 - NAT - Interface Properties - Services and Ports Tab

Note

After selecting the network interface, the Services and Ports tab will appear when Public interface connected to the Internet is selected on the NAT tab.

Add/Edit Service

Dialog box element | Description
On this interface | Specifies that the incoming IP address is the public IP address that is assigned to this interface.
On this address pool entry | Specifies that the incoming IP address is from the public address pool. Type the appropriate public IP address (in dotted decimal notation) from the public address pool.
Protocol | Specifies the protocol used for data reception and transmission.
Incoming port | The destination port number of incoming public traffic. For example, for a Web server on your private network, the incoming port number is 80.
Private address | The IP address (in dotted decimal notation) for the private network computer.
Outgoing port | The destination port number of the private traffic. For example, for a Web server on your private network, the outgoing port number is 80.


IPv4 - NAT Properties - Address Assignment Tab

Dialog box element | Description
Automatically assign IP addresses by using the DHCP allocator | Specifies whether the router provides DHCP-based address assignment to DHCP clients on the private network.
IP address | Provides a space for you to type an Internet Protocol (IP) address that corresponds to the range of addresses to be assigned to DHCP clients on the private network. The network you configure here should be a private network or a subnet of a private network. The private networks are 10.0.0.0 with a subnet mask of 255.0.0.0, 172.16.0.0 with a subnet mask of 255.240.0.0, and 192.168.0.0 with a subnet mask of 255.255.0.0. The default IP network is 192.168.0.0.
Mask | Provides a space for you to type the subnet mask that corresponds to the range of addresses to be assigned to hosts on the private network. The default subnet mask is 255.255.255.0.
Exclude | Click to specify any addresses within the configured range of addresses that should not be assigned to DHCP clients on the private network because they are already in use.

See Also

  • Internet Private Addresses


IPv4 - NAT Properties - General Tab

Dialog box element | Description
Log errors only | Specifies that only errors are logged in the System Log in Event Viewer.
Log errors and warnings | Specifies that errors and warnings are logged in the System Log in Event Viewer.
Log all events | Specifies that the maximum amount of information is logged in the System Log in Event Viewer.
Disable event logging | Specifies that no events are logged in the System Log in Event Viewer.

See Also

  • Troubleshoot Routing and Remote Access


IPv4 - NAT Properties - Name Resolution Tab

Dialog box element | Description
Clients using Domain Name System (DNS) | Specifies whether the router relays Domain Name System (DNS) name resolution requests from hosts on the private network to the configured DNS server for the router.
Connect to the public network when a name needs to be resolved | Specifies whether a connection is attempted by using the selected demand-dial interface when a Domain Name System (DNS) name resolution request is received by a host on the private network.
Demand-dial interface | Lists the demand-dial interfaces that are configured on the router.


IPv4 - NAT Properties - Translation Tab

Dialog box element | Description
Remove TCP mapping after (minutes) | The number of minutes that a dynamic mapping for a TCP session remains in the translation table for the router. You can also click the arrows to select a new setting. The default value for TCP sessions is 1,440 minutes (24 hours).
Remove UDP mapping after (minutes) | The number of minutes that a dynamic mapping for a UDP message remains in the translation table for the router. You can also click the arrows to select a new setting. The default value for UDP messages is 1 minute.
Reset Defaults | Sets the time-out values for dynamic mappings for TCP traffic to 1,440 minutes (24 hours) and UDP traffic to 1 minute.


IPv4 - RIP

In dynamic IP routing environments, IP routing information is propagated by using IP routing protocols. The Routing Information Protocol (RIP) is designed for exchanging routing information within a small to medium-size network.

The biggest advantage of RIP is that it is extremely simple to configure and deploy. The biggest disadvantage of RIP is its inability to scale to large or very large networks. The maximum hop count used by RIP routers is 15. Networks that are 16 hops or more away are considered unreachable. As networks grow larger in size, the periodic announcements by each RIP router can cause excessive traffic. Another disadvantage of RIP is its high recovery time. When the network topology changes, it may take several minutes before the RIP routers reconfigure themselves to the new network topology. While the work reconfigures itself, routing loops may form that result in lost or undeliverable data.

Initially, the routing table for each router includes only the networks that are physically connected. A RIP router periodically sends announcements that contain its routing table entries to inform other local RIP routers of the networks it can reach. RIP version 1 uses IP broadcast packets for its announcements. RIP version 2 uses multicast or broadcast packets for its announcements.

RIP routers can also communicate routing information through triggered updates. Triggered updates occur when the network topology changes and updated routing information is sent that reflects those changes. With triggered updates, the update is sent immediately rather than waiting for the next periodic announcement. For example, when a router detects a link or router failure, it updates its own routing table and sends updated routes. Each router that receives the triggered update modifies its own routing table and propagates the change.

Routing and Remote Access supports RIP versions 1 and 2. RIP version 2 supports multicast announcements, simple password authentication, and more flexibility in subnetted and Classless InterDomain Routing (CIDR) environments.

The Windows Server® 2008 implementation of RIP has the following features:

  • Selection of which RIP version to run on each interface for incoming and outgoing packets.

  • Split-horizon, poison-reverse, and triggered-update algorithms that are used to avoid routing loops and speed recovery of the network when topology changes occur.

  • Route filters for choosing which networks to announce or accept.

  • Peer filters for choosing which router's announcements are accepted.

  • Configurable announcement and route aging timers.

  • Simple password authentication support.

  • The ability to disable subnet summarization.

Note

If you are using multiple IP routing protocols, configure only a single routing protocol per interface.


IPv4 - RIP - Interface Properties - Advanced Tab

Dialog box element | Description
Periodic announcement interval | The number of seconds between periodic RIP announcements. You can also click the arrows to select a new setting. The default value is 30 seconds. You can set this value from 15 seconds through 86,400 seconds (24 hours). This option is valid only if you have selected Periodic update mode as the Operation mode on the General tab.
Time before routes expire | The lifetime (in seconds) of a route that is learned through RIP. You can also click the arrows to select a new setting. The default value is 180 seconds. You can set this value from 15 seconds through 259,200 seconds (72 hours). If a route is not updated with another RIP announcement within the time set, the route expires and is marked as an invalid route. This option is valid only if you have selected Periodic update mode as the Operation mode on the General tab.
Time before route is removed | The amount of time (in seconds) after which a RIP-learned route that has expired is removed from the routing table. You can also click the arrows to select a new setting. The default value is 120 seconds. You can set this value from 15 seconds through 259,200 seconds (72 hours). This option is valid only if you have selected Periodic update mode as the Operation mode on the General tab.
Enable split-horizon processing | Specifies whether routes learned on a network are not announced in RIP announcements sent on that network. If this check box is not selected, routes learned on a network are announced on the same network. By default, split horizon is enabled.
Enable poison-reverse processing | Specifies whether routes learned on a network are announced with a metric of 16 (unreachable) in RIP announcements sent on that network. By default, poison reverse is enabled. The poison-reverse option is available only after split horizon is enabled.
Enable triggered updates | Specifies whether new routes and metric changes trigger an immediate update that includes only the changes. This is called a triggered update. The maximum time between triggered updates depends on the value of Minimum seconds between triggered updates, which you set on the General tab in the RIP dialog box.
Send clean-up updates when stopping | Specifies whether, if RIP is stopping on this interface, RIP sends an announcement with all routes that are marked with a metric of 15. This enables neighboring routers to immediately update their routing tables to indicate that the routes available through the router that is stopping are no longer reachable. If this check box is selected, when the router is stopped, the router advertises all of the routes that it makes available as being unreachable on all of its interfaces. By default, this check box is enabled.
Process host routes in received announcements | Specifies whether host routes in received RIP announcements are accepted. By default, host routes are ignored.
Include host routes in sent announcements | Specifies whether host routes are included in RIP announcements. By default, host routes are not included.
Process default routes in received announcements | Specifies whether default routes in received RIP announcements are accepted. By default, default routes are ignored.
Include default routes in sent announcements | Specifies whether default routes are included in RIP announcements. By default, default routes are not included.
Disable subnet summarization | Specifies that subnet routes are not summarized in the form of the class-based network ID when announced on a network that is not a subnet of the class-based network ID. By default, subnet summarization is disabled. This option is only available if the Outgoing packet protocol on the General tab is set to either RIP version 2 broadcast or RIP version 2 multicast.


IPv4 - RIP - Interface Properties - General Tab

Dialog box element Description

Operation mode

Lists the available operation modes. You can select one of two operation modes: auto-static update mode or periodic update mode.

Auto-static update mode sends out RIP announcements only when other routers request an update. Routes learned over RIP while in auto-static mode are marked as static routes when they are stored in the routing table. If you start and stop the router or if RIP is disabled, these routes remain in the routing table until they are manually deleted.

Auto-static update mode is the default for demand-dial interfaces.

Periodic update mode sends out RIP announcements periodically, as specified in Periodic announcement interval on the Advanced tab. Routes learned over RIP while in periodic mode are marked as RIP routes and are removed if the router is stopped and restarted.

Periodic update mode is the default for LAN interfaces.

Outgoing packet protocol

Lists the available protocols for outgoing RIP announcements. You can use the following protocols to send route announcements over the interface:

RIP version 1 broadcast: RIP version 1 announcements are sent as broadcasts.

RIP version 2 broadcast: RIP version 2 announcements are sent as broadcasts. If you have a mixed environment with RIP versions 1 and 2, select this protocol.

RIP version 2 multicast: RIP version 2 announcements are sent as multicasts. Select this protocol only if all the neighboring RIP routers on the network that is connected to this interface are also RIP version 2 routers that are configured for RIP version 2. A RIP version 1 router cannot process a RIP version 2 multicast announcement.

Silent RIP: Disables outgoing RIP announcements on this interface. In silent mode, the computer listens to RIP announcements and updates its routing table but does not announce its own routes.

Incoming packet protocol

Lists the available protocols for incoming RIP announcements. You can use the following protocols to receive RIP packets from other routers:

Ignore incoming packets: Ignores announcements. If you want a router that only announces routes, select this option.

RIP version 1 and 2: Accepts announcements of both types.

RIP version 1 only: Accepts only RIP version 1 announcements.

RIP version 2 only: Accepts only RIP version 2 announcements.

Added cost for routes

The cost associated with sending packets over this interface. You can also click the arrows to select a new setting. When routes are added to the routing table, this number is added to the hop count as advertised in the RIP message. By default, this value is 1 to indicate the additional hop as created by the receiving router. If you want to associate a higher cost with the route, set a higher cost (for example, if you have a heavily trafficked route that you do not want used unless other routes are unavailable). The accumulated costs/hops for the farthest nodes on the IP network must not exceed 15.

Tag for announced routes

A tag number for the routes advertised on this interface. You should use this option if you want all packets sent over this interface to include a tag in RIP version 2 announcements.

Activate authentication

Specifies whether you want to enable authentication by using a plaintext password for RIP version 2 announcements over this interface. All incoming and outgoing RIP version 2 packets must contain the same plaintext password. Therefore, you must enable this option and configure the same password for all routers that are connected to this interface. This option is a form of identification. It is not a security option.

Password

A password between 1 and 16 characters long. This password is sent as plaintext in the RIP version 2 message for authentication between neighboring RIP version 2 routers.


IPv4 - RIP - Interface Properties - Neighbors Tab

Dialog box element | Description
Use broadcast or multicast only | Specifies that all RIP announcements are sent by using the outgoing packet protocol specified on the General tab.
Use neighbors in addition to broadcast or multicast | Specifies that RIP announcements are unicasted to specific neighboring routers in addition to the outgoing packet protocol specified on the General tab.
Use neighbors instead of broadcast or multicast | Specifies that RIP announcements are only unicasted to the specified neighboring routers. RIP announcements are not sent according to the outgoing packet protocol specified on the General tab. If you have nonbroadcast networks such as Frame Relay and want to enable RIP between specific routers, you should select this option.
IP address | The IP address of the neighboring RIP router.
List | Lists the configured RIP neighbor IP addresses.


IPv4 - RIP - Interface Properties - Security Tab

Dialog box element Description

Action

Lists the available security options for RIP for IP. You can set security for how you accept routes and how you announce routes. All of the options on this tab are specific to the security option you selected. To set security for accepting routes, click For incoming routes and configure the security options. Then, to set security for announcing routes, click For outgoing routes and reconfigure the security options.

Accept all routes

For incoming routes:

Specifies that the router looks at every route entry in an incoming RIP announcement to determine whether to update its routing table.

For outgoing routes:

Specifies that the router includes all appropriate route entries in outgoing RIP announcements.

Accept all routes in the ranges listed

For incoming routes:

Specifies that the router looks at each route entry in an incoming RIP announcement and processes the route only if the route falls between one of the ranges listed.

For outgoing routes:

Specifies that the router includes a route in the outgoing RIP announcement only if the route falls into one of the ranges listed.

Ignore all routes in the ranges listed

For incoming routes:

Specifies that the router looks at each route entry in an incoming RIP announcement and discards the route if it falls into one of the ranges listed.

For outgoing routes:

Specifies that the router excludes a route from the outgoing RIP announcement if the route falls into one of the ranges listed.

From

The IP address for the lower end of the range. For example, if you want to exclude all routes to the private network ID 10.0.0.0, you type 10.0.0.0 in From.

To

The IP address for the higher end of the range. For example, if you want to exclude all routes to the private network ID 10.0.0.0, you type 10.255.255.255 in To.

List

For incoming routes:

Lists the route ranges to filter in the incoming RIP announcements.

For outgoing routes:

Lists the route ranges to filter in the outgoing RIP announcements.


IPv4 - RIP Properties - General Tab

Dialog box element | Description
Maximum delay | The interval between triggered updates. Triggered updates are sent when the entries in a routing table change. The default is 5 seconds.
Log errors only | Specifies that only errors are logged in the System Log in Event Viewer.
Log errors and warnings | Specifies that errors and warnings are logged in the System Log in Event Viewer.
Log the maximum amount of information | Specifies that the maximum amount of information is logged in the System Log in Event Viewer.
Disable event logging | Specifies that no events are logged in the System Log in Event Viewer.

See Also

  • Troubleshoot Routing and Remote Access


IPv4 - RIP Properties - Security Tab

Dialog box element | Description
Accept announcements from all routers | Specifies that announcements from all routers are accepted. This is the default.
Accept announcements from listed routers only | Specifies that only announcements from the routers listed are accepted. Any announcements from routers that are not on the list are ignored. This option is useful if you want to accept RIP announcements only from specific RIP routers.
Ignore announcements from all listed routers | Specifies that announcements from the routers listed are ignored. Announcements from all other routers are accepted. This option is useful if you want to exclude the announcements of specific RIP routers.
Router IP address | The IP address of the router.
List | Lists the IP addresses of the RIP routers that you have added.


IPv4 - Static Routes

A static routed IP network does not use routing protocols such as RIP for IP to communicate routing information between routers. All of the routing information is stored in a static routing table on each router. You need to ensure that each router has the appropriate routes in its routing table so that traffic can be exchanged between any two endpoints on the IP network.

The static routed environment

A static routed IP environment is best suited to a small, single-path, static IP network:

  • A small network is defined as 2 to 10 networks.

  • Single-path means that there is only a single path for packets to travel between any two endpoints on the network.

  • Static means that the topology of the network does not change over time.

The disadvantages of static routing are:

  • No fault tolerance

    If a router or link goes down, static routers do not sense the fault and inform other routers of the fault. While this is a concern on large, corporate networks, a small office (with two routers and three networks based on LAN links) does not go down often enough to justify deploying a multipath topology and a routing protocol.

  • Administrative overhead

    If a new network is added or removed from the network, routes to the new network must be manually added or removed. If a new router is added, it must be properly configured for the routes of the network.

Deploying static routing

If static routing is appropriate for your IP network, you can perform the following steps to deploy static routing:

  1. Draw a map of the topology of your IP network that shows the separate networks and the placement of routers and hosts (nonrouter computers that run TCP/IP).

  2. For each IP network (a cabling system bounded by one or more routers), assign a unique IP network ID (also known as an IP network address).

  3. Assign IP addresses to each router interface. It is a common industry practice to assign the first IP addresses of a given IP network to router interfaces. For example, for an IP network ID of 192.168.100.0 with a subnet mask of 255.255.255.0, the router interface is assigned the IP address of 192.168.100.1.

  4. For peripheral routers, configure a default route on the interface that has a neighboring router. The use of default routes on peripheral routers is optional.

  5. For each nonperipheral router, compile a list of routes that need to be added as static routes to the routing table for that router. Each route consists of a destination network ID, a subnet mask, a gateway (or forwarding) IP address, a metric (number of router hops to reach the network), and the interface to be used to reach the network.

  6. For nonperipheral routers, add the static routes compiled in step 5 to each router. You can add static routes by using Routing and Remote Access.

  7. When your configuration is complete, use the ping and tracert commands to test connectivity between host computers so that all routing paths are checked.


IPv4 - Static Routes - New Static Route

Dialog box element Description

Interface

Lists the available LAN or demand-dial interfaces to be used to forward the IP packet if this route is selected.

Destination

A destination for the route. The destination can be a host address, subnet address, network address, or the destination for the default route (0.0.0.0).

Network mask

The network mask for the static route. The network mask number is used in conjunction with the destination to determine when the route is used. For example, a host route has a mask of 255.255.255.255, a default route has a mask of 0.0.0.0, and a subnet or network route has a mask somewhere in between these two extremes. The mask of 255.255.255.255 means that only an exact match of the destination number can use this route. The mask of 0.0.0.0 means that any destination can use this route.

When converted to binary, the destination cannot have bits set to 1 where there are 0’s in the network mask. In other words, the destination cannot be more specific that the network mask.

Gateway

The forwarding IP address for this route. For LAN interfaces, the gateway address must be configured and must be a directly reachable IP address for the network segment of the selected interface. For demand-dial interfaces, the gateway address is not configured or used.

Metric

The metric which is the cost associated with this route to reach the destination. The metric is commonly used to indicate the number of routers (hops) to the destination. When deciding between multiple routes to the same destination, the route with the lowest metric is selected as the best route.

Use this route to initiate demand-dial connections

Specifies whether the router initiates a demand-dial connection when this route is selected for packets being forwarded. This check box is only available when a demand-dial interface is selected in Interface.


IPv6

IPv6 address syntax

IPv4 addresses are represented in dotted-decimal format. These 32-bit addresses are divided along 8-bit boundaries. Each set of 8 bits is converted to its decimal equivalent and separated from the other sets by periods. For IPv6, the 128-bit address is divided along 16-bit boundaries. Each 16-bit block is converted to a 4-digit hexadecimal number and separated by colons. The resulting representation is known as colon-hexadecimal.

The following is an IPv6 address in binary form:

0010000111011010000000001101001100000000000000000010111100111011
0000001010101010000000001111111111111110001010001001110001011010

The 128-bit address is divided along 16-bit boundaries:

0010000111011010   0000000011010011   0000000000000000   0010111100111011  0000001010101010   0000000011111111   1111111000101000   1001110001011010

Each 16-bit block is converted to hexadecimal and delimited with colons. The result is:

21DA:00D3:0000:2F3B:02AA:00FF:FE28:9C5A

IPv6 representation can be further simplified by removing the leading zeros within each 16-bit block. However, each block must have at least a single digit. With leading zero suppression, the address representation becomes:

21DA:D3:0:2F3B:2AA:FF:FE28:9C5A

Compressing zeros

Some types of addresses contain long sequences of zeros. To further simplify the representation of IPv6 addresses, a contiguous sequence of 16-bit blocks set to 0 in the colon-hexadecimal format can be compressed to “::,” known as double-colon.

For example, the link-local address of FE80:0:0:0:2AA:FF:FE9A:4CA2 can be compressed to FE80::2AA:FF:FE9A:4CA2. The multicast address FF02:0:0:0:0:0:0:2 can be compressed to FF02::2.

Zero compression can be used to compress only a single contiguous series of 16-bit blocks expressed in colon-hexadecimal notation. You cannot use zero compression to include part of a 16-bit block. For example, you cannot express FF02:30:0:0:0:0:0:5 as FF02:3::5.

To determine how many 0 bits are represented by the double colon, you can count the number of blocks in the compressed address, subtract this number from 8, and then multiply the result by 16. For example, the address FF02::2 has two blocks (the “FF02” block and the “2” block.) The number of 0 bits expressed by the double colon is 96 (96 = (8 – 2)×16).

Zero compression can be used only once in a given address. Otherwise, you could not determine the number of 0 bits represented by each double colon.

IPv6 prefixes

The prefix is the part of the address that indicates which bits have fixed values or reflect the subnet identifier. Prefixes for IPv6 subnet identifiers and routes are expressed in the same way as Classless Inter-Domain Routing (CIDR) notation for IPv4, that is, in address/prefix-length notation. For example, 21DA:D3::/48 is a route prefix and 21DA:D3:0:2F3B::/64 is a subnet prefix.

Note

  • IPv4 implementations commonly use a dotted decimal representation of the network prefix known as the subnet mask. IPv6 does not support subnet masks. IPv6 supports only the prefix-length notation.

Types of IPv6 addresses

IPv6 supports three types of addresses:

  • Unicast

    A unicast address identifies a single interface within the scope of the type of unicast address. With the appropriate unicast routing topology, packets addressed to a unicast address are delivered to a single interface. To accommodate load-balancing systems, RFC 3513 allows multiple interfaces to use the same address as long as they appear as a single interface to the IPv6 implementation on the host.

  • Multicast

    A multicast address identifies multiple interfaces. With the appropriate multicast routing topology, packets addressed to a multicast address are delivered to all interfaces that are identified by the address. A multicast address is used for one-to-many communication, with delivery to multiple interfaces.

  • Anycast

    An anycast address identifies multiple interfaces. With the appropriate routing topology, packets addressed to an anycast address are delivered to a single interface, the nearest interface that is identified by the address. The nearest interface is defined as being closest in terms of routing distance. An anycast address is used for one-to-one-of-many communication, with delivery to a single interface.

IPv6 addresses always identify interfaces, not nodes. A node is identified by any unicast address that is assigned to one of its interfaces.

Note

  • RFC 3513 does not define a broadcast address. All types of IPv4 broadcast addressing are performed in IPv6 using multicast addresses. For example, the subnet and limited broadcast addresses from IPv4 are replaced with the link-local scope all-nodes multicast address of FF02::1.

Unicast IPv6 addresses

Unicast IPv6 addresses fall into one of five types:

  • Global unicast addresses

  • Link-local addresses

  • Site-local addresses

  • Special addresses

  • Compatibility addresses
Global unicast addresses

Global unicast addresses are equivalent to public IPv4 addresses. They are globally routable and reachable on the IPv6 Internet.

Unlike the current IPv4-based Internet, which is a mixture of both flat and hierarchical routing, the IPv6-based Internet has been designed from its foundation to support efficient, hierarchical addressing and routing. The scope (that is, the region of the IPv6 network over which the address is unique) of a global unicast address is the entire IPv6 Internet.

The following figure shows the structure of a global unicast address as defined in RFC 3587.

The Global Unicast Address

The Global Unicast Address

Global unicast addresses contain four fields.

  • The three high-order bits are set to 001. The address prefix for currently assigned global addresses is 2000::/3.

  • The Global Routing Prefix indicates the global routing prefix for a specific organization’s site. The combination of the three fixed bits and the 45-bit Global Routing Prefix creates a 48-bit site prefix, which is assigned to an individual site of an organization. After this prefix is assigned, routers on the IPv6 Internet forward IPv6 traffic matching the 48-bit prefix to the routers of the organization’s site.

  • The Subnet ID is used within an organization’s site to identify subnets. This field is 16 bits long. The organization’s site can use these 16 bits within its site to create 65,536 subnets or multiple levels of addressing hierarchy and an efficient routing infrastructure.

  • The Interface ID indicates the interface on a specific subnet within the site. This field is 64 bits long.

The following figure shows how fields within the global unicast address create a three-level structure.

The Three-level Structure of the Global Unicast Address

Three-level Structure of Global Unicast Address

The public topology is the collection of larger and smaller ISPs that provide access to the IPv6 Internet. The site topology is the collection of subnets within an organization’s site. The interface identifier identifies a specific interface on a subnet within an organization’s site. For more information about global unicast addresses, see RFC 3587 in the IETF RFC Database.

Local-use unicast addresses

Local-use unicast addresses fall into one of two types:

  • Link-local addresses are used between on-link neighbors and for Neighbor Discovery processes.

  • Site-local addresses are used between nodes in the same site.

Link-local addresses

Nodes use link-local addresses when communicating with neighboring nodes on the same link. For example, on a single-link IPv6 network with no router, hosts use link-local addresses to communicate with other hosts on the link. Link-local addresses are equivalent to Automatic Private IP Addressing (APIPA) IPv4 addresses autoconfigured on computers that are running Windows. APIPA addresses use the 169.254.0.0/16 prefix. The scope of a link-local address is the local link.

A link-local address is required for Neighbor Discovery processes and is always automatically configured, even in the absence of all other unicast addresses.

The following figure shows the structure of the link-local address.

The Link-Local Address

Link-local addresses always begin with FE80. With the 64-bit interface identifier, the prefix for link-local addresses is always FE80::/64. An IPv6 router never forwards link-local traffic beyond the link.

Site-local addresses

Site-local addresses are equivalent to the IPv4 private address space (10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16). For example, private intranets that do not have a direct, routed connection to the IPv6 Internet can use site-local addresses without conflicting with global addresses. Site-local addresses are not reachable from other sites, and routers must not forward site-local traffic outside the site. Site-local addresses can be used in addition to global addresses. The scope of a site-local address is the site.

Unlike link-local addresses, site-local addresses are not automatically configured and must be assigned through either stateless or stateful address configuration.

The following figure shows the structure of the site-local address.

The Site-Local Address

The first 10 bits are always fixed for site-local addresses, beginning with FEC0::/10. After the 10 fixed bits is a 54-bit subnet identifier (Subnet ID field) that provides 54 bits with which you can create a hierarchical and summarizable routing infrastructure within the site. After the Subnet ID field is a 64-bit Interface ID field that identifies a specific interface on a subnet.

Note

RFC 3879 formally deprecates the use of site-local addresses for future IPv6 implementations. Existing implementations of IPv6 can continue to use site-local addresses until a replacement has been standardized. A new version of the "Internet Protocol Version 6 (IPv6) Addressing Architecture" standard is now published as an Internet draft (draft-ietf-ipv6-addr-arch-v4-0x.txt) and includes the deprecation of site-local addresses. This new Internet draft of the standard for IPv6 addressing is destined to obsolete RFC 3513.

Special IPv6 addresses

The following are special IPv6 addresses:

  • Unspecified address

    The unspecified address (0:0:0:0:0:0:0:0 or ::) indicates the absence of an address. It is equivalent to the IPv4 unspecified address of 0.0.0.0. The unspecified address is typically used as a source address for packets attempting to verify the uniqueness of a tentative address. The unspecified address is never assigned to an interface or used as a destination address.

  • Loopback address

    The loopback address (0:0:0:0:0:0:0:1 or ::1) is used to identify a loopback interface, enabling a node to send packets to itself. It is equivalent to the IPv4 loopback address of 127.0.0.1. Packets addressed to the loopback address must never be sent on a link or forwarded by a router.

Compatibility addresses

To aid in the migration from IPv4 to IPv6 and the coexistence of both types of hosts, the following addresses are defined:

  • IPv4-compatible address

    The IPv4-compatible address, 0:0:0:0:0:0:w.x.y.z or ::w.x.y.z (where w.x.y.z is the dotted decimal representation of a public IPv4 address), is used by IPv6/IPv4 nodes that are communicating using IPv6. IPv6/IPv4 nodes support both IPv4 and IPv6 protocols. When an IPv4-compatible address is used as an IPv6 destination, the IPv6 traffic is automatically encapsulated with an IPv4 header and sent to the destination using the IPv4 infrastructure.

  • IPv4-mapped address

    The IPv4-mapped address, 0:0:0:0:0:FFFF:w.x.y.z or ::FFFF:w.x.y.z, is used to represent an IPv4-only node to an IPv6 node. It is used only for internal representation. The IPv4-mapped address is never used as a source or destination address of an IPv6 packet.

  • 6to4 address

    The 6to4 address is used for communicating between two nodes running both IPv4 and IPv6 over an IPv4 routing infrastructure. The 6to4 address is formed by combining the prefix 2002::/16 with the 32 bits of a public IPv4 address of the node, forming a 48-bit prefix. 6to4 is a tunneling technique described in RFC 3056.

  • ISATAP address

    The Internet draft titled “Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)” defines ISATAP addresses used between two nodes running both IPv4 and IPv6 over an IPv4 routing infrastructure. ISATAP addresses use the locally administered interface ID ::0:5EFE:w.x.y.z where w.x.y.z is any unicast IPv4 address, which includes both public and private addresses.

    The ISATAP interface ID can be combined with any 64-bit prefix that is valid for IPv6 unicast addresses. This includes the link-local address prefix (FE80::/64), site-local prefixes, and global prefixes.

  • Teredo address

    Teredo addresses use the prefix 3FFE:831F::/32. Beyond the first 32 bits, Teredo addresses are used to encode the IPv4 address of a Teredo server, flags, and the encoded version of the external address and port of a Teredo client. An example of a Teredo address is 3FFE:831F:CE49:7601:8000:EFFF:62C3:FFFE. Teredo addresses are used to represent a host when using the automatic tunneling mechanism defined in the Internet draft titled “Teredo: Tunneling IPv6 over UDP through NATs.”

Multicast IPv6 addresses

In IPv6, multicast traffic operates in the same way that it does in IPv4. Arbitrarily located IPv6 nodes can listen for multicast traffic on arbitrary IPv6 multicast addresses. IPv6 nodes can listen to multiple multicast addresses at the same time. Nodes can join or leave a multicast group at any time.

IPv6 multicast addresses have the first 8 bits set to 1111 1111. An IPv6 address is easy to classify as multicast because it always begins with “FF.” Multicast addresses cannot be used as source addresses or as intermediate destinations in a Routing header.

Beyond the first 8 bits, multicast addresses include additional structure to identify their flags, scope, and multicast group. The following figure shows the structure of the IPv6 multicast address.

The IPv6 Multicast Address

IPv6 Multicast Address

The fields in the multicast address are:

  • Flags

    Indicates flags set on the multicast address. The size of this field is 4 bits. As of RFC 3513, the only flag defined is the Transient (T) flag. The T flag uses the low-order bit of the Flags field. When set to 0, the T flag indicates that the multicast address is a well-known multicast address that has been permanently assigned by the Internet Assigned Numbers Authority (IANA). When set to 1, the T flag indicates that the multicast address is a transient multicast address that IANA has not permanently assigned.

  • Scope

    Indicates the scope of the IPv6 network for which the multicast traffic is intended. The size of this field is 4 bits. In addition to using information provided by multicast routing protocols, routers use the multicast scope to determine whether they can forward multicast traffic. The most prevalent values for the Scope field are 1 (interface-local scope), 2 (link-local scope), and 5 (site-local scope).

    For example, traffic with the multicast address of FF02::2 has a link-local scope. An IPv6 router never forwards this traffic beyond the local link.

  • Group ID

    Identifies the multicast group and is unique within the scope. The size of this field is 112 bits. Permanently assigned group IDs are independent of the scope. Transient group IDs are relevant only to a specific scope. Multicast addresses from FF01:: through FF0F:: are reserved, well-known addresses.

To identify all nodes for the interface-local and link-local scopes, the following addresses are defined:

  • FF01::1 (interface-local scope all-nodes multicast address)

  • FF02::1 (link-local scope all-nodes multicast address)

To identify all routers for the interface-local, link-local, and site-local scopes, the following addresses are defined:

  • FF01::2 (interface-local scope all-routers multicast address)

  • FF02::2 (link-local scope all-routers multicast address)

  • FF05::2 (site-local scope all-routers multicast address)

With 112 bits for the group ID, it is possible to have 2112 group IDs. However, because of the way in which IPv6 multicast addresses are mapped to Ethernet multicast media access control (MAC) addresses, RFC 3513 recommends assigning the group ID from the low-order 32 bits of the IPv6 multicast address and setting the remaining original group ID bits to 0. By using only the low-order 32 bits, each group ID maps to a unique Ethernet multicast MAC address. The following figure shows the recommended IPv6 multicast address.

The Recommended IPv6 Multicast Address Using a 32-Bit Group ID

IPv6 Multicast Address Using 32-bit Group ID

Solicited-node address

The solicited-node address facilitates the efficient querying of network nodes during address resolution. In IPv4, the ARP Request frame is sent to the MAC-level broadcast, disturbing all nodes on the network segment, including those that are not running IPv4. IPv6 uses the Neighbor Solicitation message to perform address resolution. However, instead of using the local-link scope all-nodes multicast address as the Neighbor Solicitation message destination, which would disturb all IPv6 nodes on the local link, the solicited-node multicast address is used. The following figure shows how the solicited-node multicast address comprises the prefix FF02::1:FF00:0/104 and the last 24-bits of the IPv6 address that is being resolved.

Mapping Unicast IPv6 Addresses to Solicited Node IPv6 Addresses

Mapping Unicast IPv6 Addresses to Solicited Node

For example, for the node with the link-local IPv6 address of FE80::2AA:FF:FE28:9C5A, the corresponding solicited-node address is FF02::1:FF28:9C5A. This node is listening for multicast traffic at the solicited-node address of FF02::1:FF28:9C5A and, for interfaces that correspond to a physical network adapter, has registered the corresponding multicast address with the network adapter. To resolve the address of FE80::2AA:FF:FE28:9C5A to its link-layer address, a neighboring node sends a Neighbor Solicitation to the solicited-node address of FF02::1:FF28:9C5A.

The result of using the solicited-node multicast address is that address resolutions, a common occurrence on a link, are not required to use a mechanism that disturbs all network nodes. By using the solicited-node address, address resolution disturbs very few nodes. In practice, due to the relationship between the Ethernet MAC address, the IPv6 interface ID, and the solicited-node address, the solicited-node address acts as a pseudo-unicast address for very efficient address resolution.

Anycast IPv6 addresses

An anycast address is assigned to multiple interfaces. The routing infrastructure forwards packets that are addressed to an anycast address to the nearest interface to which the anycast address is assigned. To facilitate delivery, the routing infrastructure must track the interfaces that have been assigned anycast addresses and their distance in terms of routing metrics. At present, anycast addresses are used only as destination addresses and are assigned only to routers. Anycast addresses are assigned out of the unicast address space, and the scope of an anycast address is the scope of the type of unicast address from which the anycast address is assigned.

The Subnet-Router anycast address is predefined and required. It is created from the subnet prefix for a given interface. To construct the Subnet-Router anycast address, the bits in the subnet prefix are fixed at their appropriate values, and the remaining bits are set to 0. All router interfaces attached to a subnet are assigned the Subnet-Router anycast address for that subnet. The Subnet-Router anycast address is used to communicate with one of multiple routers attached to a remote subnet.

IPv6 addresses for a host

An IPv4 host with a single network adapter typically has a single IPv4 address assigned to that adapter. An IPv6 host, however, usually has multiple IPv6 addresses — even with a single interface. An IPv6 host is assigned the following unicast addresses:

  • A link-local address for each interface.

  • Unicast addresses for each interface (which could be a site-local address and one or multiple global unicast addresses).

  • The loopback address (::1) for the loopback interface.

Typical IPv6 hosts are logically multi-homed because they have at least two addresses with which they can receive packets — a link-local address for local link traffic and a routable site-local or global address.

Additionally, each host is listening for traffic on the following multicast addresses:

  • The interface-local scope all-nodes multicast address (FF01::1).

  • The link-local scope all-nodes multicast address (FF02::1).

  • The solicited-node address for each unicast address on each interface.

  • The multicast addresses of joined groups on each interface.

IPv6 addresses for a router

An IPv6 router is assigned the following unicast addresses:

  • A link-local address for each interface.

  • Unicast addresses for each interface (which could be a site-local address and one or multiple global unicast addresses).

  • A Subnet-Router anycast address.

  • Additional anycast addresses (optional).

  • The loopback address (::1) for the loopback interface.

Additionally, each router is listening for traffic on the following multicast addresses:

  • The interface-local scope all-nodes multicast address (FF01::1).

  • The interface-local scope all-routers multicast address (FF01::2).

  • The link-local scope all-nodes multicast address (FF02::1).

  • The link-local scope all-routers multicast address (FF02::2).

  • The site-local scope all-routers multicast address (FF05::2).

  • The solicited-node address for each unicast address on each interface.

  • The multicast addresses of joined groups on each interface.

Additional references

  • For more information about IPv6, see http://go.microsoft.com/fwlink/?LinkId=6878.


IPv6 - DHCPv6 Relay Agent

The DHCPv6 Relay Agent component is a Bootstrap Protocol (BOOTP) relay agent that relays Dynamic Host Configuration Protocol (DHCP) messages between DHCPv6 clients and DHCPv6 servers on different IPv6 networks. For each IPv6 network segment that contains DHCPv6 clients, either a DHCPv6 server or a computer acting as a DHCPv6 Relay Agent is required.

Note

You cannot use the DHCPv6 Relay Agent component on a computer running the DHCPv6 service, the network address translation (NAT) routing protocol component with automatic addressing enabled, or Internet Connection Sharing (ICS).


IPv6 - DHCPv6 Relay Agent Interface Properties - General Tab

DHCPv6 Relay Properties

Dialog box element Description

Relay DHCP packets

Specifies whether DHCPv6 messages are relayed between DHCPv6 clients on the subnet to which this interface is attached and DHCPv6 servers.

After you select this check box, you must configure the DHCPv6 server addresses in the DHCPv6 Relay Agent Properties dialog box.

Hop-count threshold

Type a value for the maximum number of DHCPv6 relay agents that will handle DHCPv6 relayed traffic. You can also click the arrows to select a new setting. The default value is 4 hops. The maximum value is 16 hops.

Elapsed-time threshold (centi-seconds)

Type the number of seconds the relay agent waits before forwarding DHCPv6 messages. You can also click the arrows to select a new setting. The default value is 3200 centi-seconds.

This option is useful when you want a local DHCPv6 server to respond first, but if the local DHCPv6 server does not respond, you want to forward messages to a remote DHCPv6 server.


IPv6 - DHCPv6 Relay Agent Properties - General Tab

Dialog box element | Description
Log errors only | Specifies that only errors are logged in the System Log in Event Viewer.
Log errors and warnings | Specifies that errors and warnings are logged in the System Log in Event Viewer.
Log the maximum amount of information | Specifies that the maximum amount of information is logged in the System Log in Event Viewer.
Disable event logging | Specifies that no events are logged in the System Log in Event Viewer.


IPv6 - DHCPv6 Relay Agent Properties - Servers Tab

Dialog box element Description

Server address

Type the IPv6 address of the DHCPv6 server you want to add.

Server address list

Lists the IPv6 addresses of DHCPv6 servers on the network. The router acts as a DHCPv6 relay agent by relaying DHCPv6 messages between DHCPv6 clients and the DHCPv6 servers specified in this list. You must add at least one address to be a relay agent.

For the DHCPv6 relay agent to work, you must select the Relay DHCP packets check box on at least one interface that has been added to the DHCPv6 Relay Agent routing protocol.


IPv6 - General

Routing interface

The server running Routing and Remote Access uses a routing interface to forward unicast IP and multicast IP packets. There are two types of routing interfaces:

  • LAN interfaces

    A LAN interface is a physical interface that typically represents a local area connection that uses local area networking technology such as Ethernet or token ring. A LAN interface reflects an installed network adapter. An installed WAN adapter is sometimes represented as a LAN interface. For example, some Frame Relay adapters create a separate logical LAN interface for each configured virtual circuit. LAN interfaces are always active and typically do not require an authentication process to become active.

  • Demand-dial interfaces

    A demand-dial interface is a logical interface that represents a point-to-point connection. The point-to-point connection is based on either a physical connection, such as two routers connected over an analog phone line that uses modems, or a logical connection, such as two routers connected over a virtual private network connection that uses the Internet. Demand-dial connections are either on-demand (the point-to-point connection is only established when needed) or persistent (the point-to-point connection is established and then remains in a connected state). Demand-dial interfaces typically require an authentication process to become connected. The equipment needed by a demand-dial interface is a port on a device.


IPv6 - General - Interface Properties - General Tab

IP Interface

Dialog box element | Description
Enable IPv6 router manager | Specifies whether TCP/IP is enabled on this interface. Select this check box to set the Administrative Status of the interface to Up. Clear this check box to set the Administrative Status of the interface to Down.

Inbound and Outbound Filters

Dialog box element Description

Receive all packets except those that meet the criteria below

For input filters: Specifies that all incoming packets that match the filters listed are discarded. All incoming packets are compared to the filters listed. If a packet matches a filter, the packet is dropped. If the packet does not match a filter, the packet is accepted.

For output filters: Specifies that all outgoing packets that match the filters listed are discarded. All outgoing packets are compared to the filters listed. If a packet matches a filter, the packet is dropped. If the packet does not match a filter, the packet is transmitted.

This option applies to all the filters that you have added. You cannot change this option for individual filters.

You can only configure this option after you have added at least one filter.

Drop all packets except those that meet the criteria below

For input filters: Specifies that all incoming packets that match the filters listed are accepted. All incoming packets are compared to the filters listed. If a packet matches a filter, the packet is accepted. If the packet does not match a filter, the packet is dropped.

For output filters: Specifies that all outgoing packets that match the filters listed are transmitted. All outgoing packets are compared to the filters listed. If a packet matches a filter, the packet is transmitted. If the packet does not match a filter, the packet is dropped.

This option applies to all the filters that you have added. You cannot change this option for individual filters.

You can only configure this option after you have added at least one filter.

New

Click to add a filter. You can set filters based on where the packet is coming from (the source), where the packet is going (the destination), or what protocol the packet is using. You can set all three of these values for a filter or set any one or combination of the three, depending on the level of control that you want.

Add IPv6 Filter

Dialog box element | Description
Source network | Specifies whether the filter checks the network from which the packet is coming. After selecting this check box, you must specify a network address and prefix length.
Destination network | Specifies whether the filter checks the network to which the packet is going. After selecting this check box, you must specify a network address and prefix length.
IPv6 address | Type the IP address of the network from which the packet was sent or to which the packet is going.
Prefix length | Type the prefix length. The prefix is the part of the address that indicates the bits that have fixed values or are the bits of the network identifier. Prefixes for IPv6 routes and subnet identifiers are expressed in the same way as Classless Inter-Domain Routing (CIDR) notation for IPv4. An IPv6 prefix is written in address/prefix-length notation. For example, 21DA:D3::/48 is a route prefix and 21DA:D3:0:2F3B::/64 is a subnet prefix.
Protocol | Lists the available protocol types that you can base a filter on. The default is Any protocol. If you select Other, you must type a protocol identifier in Protocol number.
Source port | For TCP, TCP (established), and UDP protocols, type the port number specified by the source to be used by the filter. Some applications use well-known ports to send and receive packets. You can set a filter for one of these ports if you know what numbers the application uses for the protocol specified in Protocol. For example, you can try to block FTP traffic or allow only PPTP traffic.
Destination port | For TCP, TCP (established), and UDP protocols, type the port number used by the destination for the packet.
ICMP type | For the ICMP protocol, type the ICMP type.
ICMP code | For the ICMP protocol, type the ICMP code.
Protocol number | For the Other protocol, type the IP protocol number.


IPv6 - General Properties - Logging Tab

Dialog box element | Description
Log errors only | Specifies that only errors are logged in the System Log in Event Viewer.
Log errors and warnings | Specifies that errors and warnings are logged in the System Log in Event Viewer.
Log the maximum amount of information | Specifies that the maximum amount of information is logged in the System Log in Event Viewer.
Disable event logging | Specifies that no events are logged in the System Log in Event Viewer.


IPv6 - Static Routes

A static routed IP network does not use routing protocols such as RIP for IP to communicate routing information between routers. All of the routing information is stored in a static routing table on each router. You need to ensure that each router has the appropriate routes in its routing table so that traffic can be exchanged between any two endpoints on the IP network.

The static routed environment

A static routed IP environment is best suited to a small, single-path, static IP network:

  • A small network is defined as 2 to 10 networks.

  • Single-path means that there is only a single path for packets to travel between any two endpoints on the network.

  • Static means that the topology of the network does not change over time.

The disadvantages of static routing are:

  • No fault tolerance

    If a router or link goes down, static routers do not sense the fault and inform other routers of the fault. While this is a concern on large, corporate networks, a small office (with two routers and three networks based on LAN links) does not go down often enough to justify deploying a multipath topology and a routing protocol.

  • Administrative overhead

    If a new network is added or removed from the network, routes to the new network must be manually added or removed. If a new router is added, it must be properly configured for the routes of the network.

Deploying static routing

If static routing is appropriate for your IP network, you can perform the following steps to deploy static routing:

  1. Draw a map of the topology of your IP network that shows the separate networks and the placement of routers and hosts (nonrouter computers that run TCP/IP).

  2. For each IP network (a cabling system bounded by one or more routers), assign a unique IP network ID (also known as an IP network address).

  3. Assign IP addresses to each router interface.

  4. For peripheral routers, configure a default route on the interface that has a neighboring router. The use of default routes on peripheral routers is optional.

  5. For each nonperipheral router, compile a list of routes that need to be added as static routes to the routing table for that router. Each route consists of a destination network ID, a subnet mask, a gateway (or forwarding) IP address, a metric (number of router hops to reach the network), and the interface to be used to reach the network.

  6. For nonperipheral routers, add the static routes compiled in step 5 to each router. You can add static routes by using Routing and Remote Access.

When your configuration is complete, use the ping and tracert commands to test connectivity between host computers so that all routing paths are checked.


IPv6 - Static Routes - New Static Routes

Dialog box element | Description
Interface | Lists the available LAN or demand-dial interfaces to be used to forward the IP packet if this route is selected.
Destination | Type a destination for the route. The destination can be a host address, subnet address, network address, or the destination for the default route.
Prefix length | Type the prefix length. The prefix is the part of the address that indicates the bits that have fixed values or are the bits of the network identifier. Prefixes for IPv6 routes and subnet identifiers are expressed in the same way as Classless Inter-Domain Routing (CIDR) notation for IPv4. An IPv6 prefix is written in address/prefix-length notation. For example, 21DA:D3::/48 is a route prefix and 21DA:D3:0:2F3B::/64 is a subnet prefix.
Gateway | Type the forwarding IP address for this route. For LAN interfaces, the gateway address must be configured and must be a directly reachable IP address for the network segment of the selected interface. For demand-dial interfaces, the gateway address is not configured or used.
Metric | Type the metric, which is the cost associated with this route to reach the destination. The metric is commonly used to indicate the number of routers (hops) to the destination. When deciding between multiple routes to the same destination, the route with the lowest metric is selected as the best route.
Use this route to initiate demand-dial connections | Specifies whether the router initiates a demand-dial connection when this route is selected for packets being forwarded. This check box is only available when a demand-dial interface is selected in Interface.


Network Interfaces - Demand-dial - General Tab

Dialog box element | Description
Host name or IP address of destination | Type the address or name of the computer you are tunneling to. If you enter an IPv4 address, VPN over IPv4 is selected. If you enter an IPv6 address, VPN over IPv6 is selected.


Network Interfaces - Demand-dial - Options Tab

Dialog box element | Description
Demand dial | Specifies that an idle time disconnect setting is used for nonpermanent dial-up connections.
Idle time before hanging up | Lists the available time periods for the idle time setting. The remote router that is called also has an idle time setting, which may be smaller than the setting here. In that case, the remote router will disconnect an idle connection before the time you set here.
Persistent connection | Specifies that the demand-dial connection is always in a connected state. The connection is established when the Routing and Remote Access service is started and is never disconnected by the calling router.
Redial attempts | Type the number of times to automatically redial the phone number. You can also click the arrows to select the number of redial attempts.
Average redial intervals | Lists the available time periods to wait between redial attempts.
Callback | Click to configure callback settings.

PPP Settings

Dialog box element Description

Enable LCP extensions

Specifies whether Link Control Protocol (LCP) extensions are enabled. LCP extensions may cause problems when you call servers with older PPP software. If consistent problems occur, clear the check box.

If you clear the check box, LCP cannot send Time-Remaining and Identification packets and request callback during the LCP negotiation of PPP.

Enable software compression

Specifies whether software compression is enabled.

Network Connections offers software data compression in addition to support for modem compression. Therefore, you do not have to turn on modem compression to benefit from faster throughput.

Negotiate multi-link for single link connections

Specifies whether Multilink negotiation is enabled for a single link connection. If your remote access server supports this feature, you may notice improved audio quality. If you enable this option, you may not be able to connect to other remote access servers.


Network Interfaces - Demand-dial - Security Tab

Dialog box element Description

Typical

Specifies that a predefined set of authentication methods and encryption requirements are negotiated with the server during a PPP exchange. If you select this option, you can view the settings by clicking Advanced (custom settings), and then clicking Settings.

Verify my identity as follows

Lists the available identity authentication settings that you can use.

Require data encryption

Specifies whether to require the use of data encryption. If you select this option, and data encryption is not used by the connecting server, the connection disconnects. If you do not select this option, encryption is attempted, but the connection is made even if encryption is not used. If you want to prevent encryption, click Advanced (custom settings), click Settings, and in Data encryption, click No encryption allowed (disconnect if server requires encryption).

Advanced

Specifies that authentication methods and encryption requirements are individually enabled, configured, and disabled. This requires a knowledge of security protocols.

If you select this option, you can view the settings by clicking Advanced (custom settings), and then clicking Settings. If you click Advanced (custom settings), and then you click Typical (recommended settings), authentication and encryption settings are reset to their default values.

Settings

Click to individually enable, configure, and disable authentication methods and encryption requirements.


Network Interfaces - Demand-dial - Networking Tab

Dialog box element Description

Type of VPN

Lists the available remote access server types you can call. Choices vary, depending on the type of connection.

If a host name or Internet Protocol version 4 (IPv4) address is entered in the General tab, the type of VPN allowed is: Automatic, PPTP VPN, or L2TP IPsec.

If an Internet Protocol version 6 (IPv6) address is entered in the General tab, the type of VPN allowed is: L2TP IPsec.

For a virtual private network (VPN) connection, if you are not sure which type to select, click Automatic. PPTP is attempted first, and then L2TP. If you are sure that your VPN server is a PPTP server or an L2TP server, select the appropriate server type.

In order to connect to an L2TP server, the Trusted Root Certification Authorities certificate store on your computer must contain the certificate of the root authority for the certification authority that issued your computer certificate and the certificate for the L2TP server.

This connection uses the following items

Lists the available network components that your connection can use. Network components are the clients, services, and protocols you use to communicate with servers on your network once you are connected to a server.

To enable the use of a network component, click the check box next to the name of the component. To disable the use of a network component, clear the check box next to the name of the component.

More than one network protocol may be listed.

IPsec Settings

Dialog box element Description

Use preshared key for authentication

Specifies whether the preshared key method of authentication is enabled for the Internet Key Exchange (IKE). This method uses a secret set of characters (the key) that has been agreed upon by two users.

The use of preshared key authentication is not recommended because it is a relatively weak authentication method. Preshared key authentication creates a master key that is less secure (that might produce a weaker form of encryption) than certificates or the Kerberos V5 protocol. In addition, preshared keys are stored in plaintext in the registry. In Active Directory, preshared keys are stored in readable hexadecimal format.

Preshared key authentication is provided for interoperability purposes and to adhere to IPsec standards. It is recommended that you use preshared keys only for testing and that you use certificates or Kerberos V5 instead in a production environment.

Key

Type your preshared key. This option is available only if the Use preshared key for authentication check box has been selected.

Use certificate for authentication

Specifies whether the certificate method of authentication is enabled for the Internet Key Exchange (IKE). This method uses a certificate issued from a specified certification authority (CA).

Verify the Name and Usage attributes of the server's certificate

Specifies whether the server verifies the validity of the certificate used for IKE with the CA certificate the server has in its certificate store.


Network Interfaces - Demand-dial - Set IP Demand-dial Filters

Dialog box element Description

Only for the following traffic

Specifies that a demand-dial connection is initiated only when IP packets forwarded over this demand-dial interface match one of the filters listed. When the demand-dial interface is in a disconnected state, all packets forwarded by using the demand-dial interface are compared to the filters listed. If a packet matches a filter, the demand-dial connection is initiated and the packet is forwarded across the demand-dial connection. If the packet does not match a filter, the demand-dial connection is not initiated and the packet is discarded.

This option applies to all the filters that you have added. You cannot change this option for individual filters.

You can only configure this option after you have added at least one filter.

For all traffic except

Specifies that a demand-dial connection is not initiated for IP packets forwarded over this demand-dial interface that match one of the filters listed. When the demand-dial interface is in a disconnected state, all packets forwarded by using the demand-dial interface are compared to the filters listed. If the packet matches a filter, the demand-dial connection is not initiated and the packet is discarded. If a packet does not match a filter, the demand-dial connection is initiated and the packet is forwarded across the demand-dial connection.

This option applies to all the filters that you have added. You cannot change this option for individual filters.

You can only configure this option after you have added at least one filter.

New

Click to add a filter. You can set filters based on where the packet is coming from (the source), where the packet is going (the destination), or what protocol the packet is using. You can set all three of these values for a filter or set any one or combination of the three, depending on the level of control that you want.

Edit

Click to modify the settings for a selected filter.

Delete

Removes a selected filter from the list.

Add IP Filter

Dialog box element | Description
Source network | Specifies whether the filter checks the network from which the packet is coming. After selecting this check box, you must specify a network IP address and subnet mask.
Destination network | Specifies whether the filter checks the network to which the packet is going. After selecting this check box, you must specify a network address and subnet mask.
IP address | The IP address of the network from which the packet was sent or to which the packet is going. You must also specify a subnet mask.
Subnet mask | The subnet mask that corresponds to the network IP address.
Protocol | Lists the available protocol types that you can base a filter on. The default is Any protocol. If you select Other, you must type a protocol identifier in Protocol number.
Source port | For TCP, TCP (established), and UDP protocols, provides a space for you to type the port number specified by the source to be used by the filter. Some applications use well-known ports to send and receive packets. You can set a filter for one of these ports if you know what numbers the application uses for the protocol specified in Protocol. For example, you can try to block FTP traffic or allow only PPTP traffic.
Destination port | For TCP, TCP (established), and UDP protocols, type the port number used by the destination for the packet.
ICMP type | The ICMP type.
ICMP code | The ICMP code.
Protocol number | The IP protocol number.


Network Interfaces - Demand-dial - Set IPv6 Demand-dial Filters

Dialog box element Description

Only for the following traffic

Specifies that a demand-dial connection is initiated only when IP packets forwarded over this demand-dial interface match one of the filters listed. When the demand-dial interface is in a disconnected state, all packets forwarded by using the demand-dial interface are compared to the filters listed. If a packet matches a filter, the demand-dial connection is initiated and the packet is forwarded across the demand-dial connection. If the packet does not match a filter, the demand-dial connection is not initiated and the packet is discarded.

This option applies to all the filters that you have added. You cannot change this option for individual filters.

You can only configure this option after you have added at least one filter.

For all traffic except

Specifies that a demand-dial connection is not initiated for IP packets forwarded over this demand-dial interface that match one of the filters listed. When the demand-dial interface is in a disconnected state, all packets forwarded by using the demand-dial interface are compared to the filters listed. If the packet matches a filter, the demand-dial connection is not initiated and the packet is discarded. If a packet does not match a filter, the demand-dial connection is initiated and the packet is forwarded across the demand-dial connection.

This option applies to all the filters that you have added. You cannot change this option for individual filters.

You can only configure this option after you have added at least one filter.

New

Click to add a filter. You can set filters based on where the packet is coming from (the source), where the packet is going (the destination), or what protocol the packet is using. You can set all three of these values for a filter or set any one or combination of the three, depending on the level of control that you want.

Edit

Click to modify the settings for a selected filter.

Delete

Removes a selected filter from the list.

Add IPv6 Filter

Dialog box element | Description
Source network | Specifies whether the filter checks the network from which the packet is coming. After selecting this check box, you must specify a network address and prefix length.
Destination network | Specifies whether the filter checks the network to which the packet is going. After selecting this check box, you must specify a network address and prefix length.
IPv6 address | Type the IP address of the network from which the packet was sent or to which the packet is going.
Prefix length | Type the prefix length. The prefix is the part of the address that indicates the bits that have fixed values or are the bits of the network identifier. Prefixes for IPv6 routes and subnet identifiers are expressed in the same way as Classless Inter-Domain Routing (CIDR) notation for IPv4. An IPv6 prefix is written in address/prefix-length notation. For example, 21DA:D3::/48 is a route prefix and 21DA:D3:0:2F3B::/64 is a subnet prefix.
Protocol | Lists the available protocol types that you can base a filter on. The default is Any protocol. If you select Other, you must type a protocol identifier in Protocol number.
Source port | For TCP, TCP (established), and UDP protocols, type the port number specified by the source to be used by the filter. Some applications use well-known ports to send and receive packets. You can set a filter for one of these ports if you know what numbers the application uses for the protocol specified in Protocol. For example, you can try to block FTP traffic or allow only PPTP traffic.
Destination port | For TCP, TCP (established), and UDP protocols, type the port number used by the destination for the packet.
ICMP type | For the ICMP protocol, type the ICMP type.
ICMP code | For the ICMP protocol, type the ICMP code.
Protocol number | For the Other protocol, type the IP protocol number.


Network Interfaces - Demand-dial - Security Tab - Advanced Settings

Dialog box element Description

Data Encryption

Lists the available levels of data encryption that you can enforce. You can prohibit encryption, allow users to connect even if their data is not encrypted, or require encryption.

Use Extensible Authentication Protocol (EAP)

Specifies that Extensible Authentication Protocol (EAP) is used with this connection. EAP authenticates remote access users in conjunction with other security devices. These devices include smart cards and certificates.

Lists the Extensible Authentication Protocol (EAP) authentication types that are installed on your computer. If the EAP type that you need is not on the list, then you must install it.

Unencrypted password (PAP)

Specifies whether to use the Password Authentication Protocol (PAP). PAP uses plaintext passwords and is the least secure authentication protocol. PAP is typically used if your connection and the server cannot negotiate a more secure form of validation. You may need to use this protocol if you are calling a server that is not running Windows.

Challenge Handshake Authentication Protocol (CHAP)

Specifies whether to use the Challenge Handshake Authentication Protocol (CHAP). CHAP negotiates a secure form of encrypted authentication. Message Digest 5 (MD5), an industry standard, transforms data (for example, a password) in such a way that the result is unique and cannot be changed back to its original form. CHAP uses challenge-response with one-way MD5 hashing on the response. In this way, you can prove to the server that you know your password without actually sending the password over the network. By supporting CHAP, Network Connections is able to securely connect to almost all other PPP servers.

Microsoft CHAP Version 2 (MS-CHAP v2)

Specifies whether to use a new version of the Microsoft Challenge Handshake Authentication Protocol (MS-CHAP v2). This protocol provides mutual authentication, stronger initial data encryption keys, and different encryption keys for sending and receiving. To minimize the risk of password compromise during MS-CHAP exchanges, MS-CHAP v2 drops support for the MS-CHAP password change and does not transmit the encoded password.

For VPN connections, MS-CHAP v2 is offered before the legacy MS-CHAP. Updated Windows clients accept MS-CHAP v2 when it is offered. Dial-up connections are not affected.

Smart Card or other Certificate Properties

Dialog box element Description

Use my smart card

Specifies that the certificate that resides on your smart card is presented to your server for authentication.

Use a certificate on this computer

Specifies that the certificate that resides in the certificate store on your computer is presented to your server for authentication.

Use simple certificate selection

Simplifies certificate selection for the user by grouping certificates with the same subject and selecting the most recently issued certificate in each group. If only one group exists, then the most recent certificate in this group is automatically selected for authentication.

Validate server certificate

Specifies whether to verify that the server certificate presented to your computer has not expired and is still valid. In the certificate authentication process, your computer presents its certificate to the server, and the server presents its certificate to your computer.

Connect to these servers

Specifies the server or servers to which your computer will automatically connect. The server name specified must exactly match the server name on the certificate. You can specify multiple server names, but you must separate them with semicolons.

Type the name of the server as it appears in the certificate properties. This could be a short name or a fully qualified domain name (FQDN), for example, server.microsoft.com.

Trusted Root Certification Authorities

Lists the available trusted root certification authorities. Trusted root certification authorities have passed through multiple layers of verification and are considered the most secure.

Use a different user name for the connection

Specifies whether to use a different user name when the user name in the smart card or certificate is not the same as the user name in the domain that you are logging on to.

Do not prompt user to authorize new servers or trusted certification authorities

Specifies whether to notify that the server certificate presented to your computer is not trusted. Untrusted certificate authentication attempts will silently fail.


Ports - Status

This dialog box enables you to view information about the selected device such as port condition, line speed, call duration, network statistics, errors, and the network protocols being used. For more information about devices and ports, see Devices and Ports.

Dialog box element | Description
Device | Select the device for which to display status information.
Refresh | Refreshes the display of port statistics and port errors.
Reset | Sets all port statistics and port errors to zero.
Disconnect | Ends the active connection on the selected port.


Ports Properties - Configure Button

Dialog box element Description

Remote access connections (inbound only)

Specifies whether inbound remote access connections are allowed for the ports of this device.

Demand-dial routing connections (inbound and outbound)

Specifies whether inbound or outbound demand-dial connections are allowed for the ports of this device.

Demand-dial routing connections (outbound only)

Specifies whether only outbound demand-dial connections are allowed for the ports of this device.

Phone number for this device

The phone number of this device. The phone number is used as the Called Station ID and in Bandwidth Allocation Protocol (BAP)-enabled connections. When a BAP-enabled remote access client requests another connection, the remote access server sends back a message that contains the phone number to dial for the new connection.

For the Called Station ID, you need to manually configure the called number if:

  1. You are using the Called-Station-Id attribute in a network policy.

  2. Your phone line, dial-up hardware, and driver for your dial-up hardware do not support the identification of the called number.

The number typed here must match the number typed in the Called-Station-Id attribute of the network policy. Otherwise, the connection is rejected. If your phone line, dial-up hardware, and driver for your dial-up hardware do support the identification of the called number, then the number typed here is ignored.

For L2TP or PPTP ports, the number you type here is the IP address (in dotted decimal notation) that is assigned to the interface of the VPN server on which VPN connections are received.

Maximum ports

The maximum number of ports for this device. You can also click the arrows to select a new setting. You can only configure this option on devices that support a variable number of ports.


Remote Access Clients

  • View Connected Remote Access Clients

  • Disconnect a Remote Access Client


View Connected Remote Access Clients

Membership in the local Administrators group, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477.

To view connected remote access clients

  1. Open Routing and Remote Access.

  2. In the console tree, click Remote Access Clients.

    Where?

    • Routing and Remote Access/server name/Remote Access Clients

  3. In the details pane, right-click a user name, and then click Status.


Disconnect a Remote Access Client

Membership in the local Administrators group, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477.

To disconnect a remote access client

  1. Open Routing and Remote Access.

  2. In the console tree, click Remote Access Clients.

    Where?

    • Routing and Remote Access/server name/Remote Access Clients

  3. In the details pane, right-click a user name, and then click Disconnect.


Remote Access Logging & Policies

Remote Access logging and policy configuration is now performed through Network Policy Server (NPS). For more information, see the Network Policy Server Help.


Server Properties - General Tab

Dialog box element | Description
IPv4 Router | Specifies whether this computer is enabled as a router. A router can forward network packets from one network segment to another.
Local area network (LAN) routing only | Specifies that this computer is a LAN-only router and does not require demand-dial or virtual private network (VPN) connections.
LAN and demand-dial routing | Specifies that this computer is a LAN and demand-dial router and supports virtual private network (VPN) connections.
IPv6 Router | Specifies whether this computer is enabled as a router for IPv6 traffic. A router can forward network packets from one network segment to another.
Local area network (LAN) routing only | Specifies that this computer is a LAN-only router for IPv6 traffic and does not require demand-dial or virtual private network (VPN) connections.
LAN and demand-dial routing | Specifies that this computer is a LAN and demand-dial router for IPv6 traffic and supports virtual private network (VPN) connections.
IPv4 Remote access server | Specifies whether this computer is enabled as a remote access server, which supports either dial-up or virtual private network (VPN) connections.
IPv6 Remote access server | Specifies whether this computer is enabled as a remote access server for IPv6 traffic, which supports either dial-up or virtual private network (VPN) connections.


Server Properties - IPv4 Tab

Dialog box element | Description
Enable IPv4 Forwarding | Specifies whether IP routing, the forwarding of IP packets from one routing interface to another, is enabled on this server. You must enable IP routing in order for LAN and demand-dial routing to occur. If you want IP-based remote access clients to access the entire network to which this server is attached, enable IP routing. If you want IP-based remote access clients to access this server only, disable IP routing.
Dynamic Host Configuration Protocol (DHCP) | Specifies that the server uses DHCP to obtain IP addresses assigned to TCP/IP-based remote access and demand-dial connections.
Static address pool | Specifies that the server uses a configured static pool of IP addresses for allocation to TCP/IP-based remote access and demand-dial connections.
Enable broadcast name resolution | Enables or disables the broadcast name resolution service. When enabled, this service allows remote access clients to resolve TCP/IP names on a single subnet LAN without the use of local Windows Internet Name Service (WINS) or Domain Name System (DNS) servers.
Adapter | Lists the available adapters. The selected adapter is used to obtain the IP addresses for allocation (if configured to use DHCP) and the IP addresses of DNS and WINS servers for assignment to remote access clients and demand-dial routers. By default, Allow RAS to select adapter is selected, which means that the server randomly selects an adapter when the Routing and Remote Access service is started.


Server Properties - IPv6 Tab

Dialog box element | Description
Enable IPv6 Forwarding | Specifies whether IP routing, the forwarding of IP packets from one routing interface to another, is enabled on this server. You must enable IP routing in order for LAN and demand-dial routing to occur. If you want IP-based remote access clients to access the entire network to which this server is attached, enable IP routing. If you want IP-based remote access clients to access this server only, disable IP routing.
Enable Default Route Advertisement | Specifies whether a default route is advertised on this server. A default route is a route for the zero-length prefix. A computer running a member of the Windows Server® 2008 family that is being used as an IPv6 router will not advertise itself as a default router unless it is configured with a default route (::/0) that is configured to be published.
IPv6 prefix assignment | Type the IPv6 prefix that will be assigned to all remote access clients.


Server Properties - Logging Tab

Dialog box element | Description
Log errors only | Specifies that only errors are logged in the System Log in Event Viewer.
Log errors and warnings | Specifies that errors and warnings are logged in the System Log in Event Viewer.
Log all events | Specifies that the maximum amount of information is logged in the System Log in Event Viewer.
Do not log any events | Specifies that no events are logged in the System Log in Event Viewer.
Log additional Routing and Remote Access information | Specifies whether the events in the Point-to-Point Protocol (PPP) connection establishment process for remote access and demand-dial routing connections are written to the PPP.LOG file stored in the systemroot\Tracing folder (the default location).

See Also

  • Troubleshoot Routing and Remote Access


Server Properties - PPP Tab

Dialog box element | Description
Multilink connections | Specifies whether the server uses the PPP Multilink Protocol (MP), which allows remote access clients and demand-dial routers to combine multiple physical connections into a single logical connection.
Dynamic bandwidth control using BAP or BACP | Specifies whether the server uses the Bandwidth Allocation Protocol (BAP) and Bandwidth Allocation Control Protocol (BACP) to negotiate the dynamic addition or deletion of multiple physical connections for remote access clients and demand-dial routers.
Link control protocol (LCP) extensions | Specifies whether the server uses Link Control Protocol (LCP) extensions. Clearing this check box prevents LCP from sending Time-Remaining and Identification packets and requesting callback during LCP negotiation.
Software compression | Specifies whether the server uses the Microsoft Point-to-Point Compression Protocol (MPPC) to compress data sent on the remote access or demand-dial connection.


Server Properties - Security Tab

Dialog box element Description

Authentication provider

Lists the available authentication providers for remote access or demand-dial authentication.

Windows Authentication: The server uses either a local account database, or a domain account database to authenticate remote access or demand-dial connection credentials. Domain account databases can be either an Active Directory database or a Windows NT 4.0 domain account database. The server logs connection authentication information in log files that are configured in the properties of the Remote Access Logging folder.

RADIUS Authentication: The remote access server uses a Remote Authentication Dial-In User Service (RADIUS) server to authenticate remote access or demand-dial connection credentials.

Configure

Click to configure the selected authentication provider.

Authentication Methods

Click to configure the authentication methods supported by this server for remote access and demand-dial connections.

Accounting provider

Lists the available accounting providers for remote access or demand-dial connections.

Windows Accounting: The server logs connection accounting information in log files that are configured in the properties of the Remote Access Logging folder.

RADIUS Accounting: The server sends connection accounting information to a Remote Authentication Dial-In User Service (RADIUS) server.

Configure

Click to configure the selected accounting provider.

Allow custom IPsec policy for L2TP connection

Specifies whether an L2TP connection can use a custom IPsec policy. If you select this check box, you must specify a pre-shared key for use by all connections that use this custom IPsec policy.

Pre-shared Key

A pre-shared key for use with a custom IPsec policy. This pre-shared key must be configured on each client computer that will connect using this policy.

Additional considerations

If Network Policy Server (NPS) is installed on this server, the preceding dialog box elements will not appear, except for authentication methods and custom IPsec policy configuration. Instead, you use NPS to configure authentication and accounting providers by creating or modifying authentication policies.

See Also

  • Setup Wizard - Remote Access - VPN - Managing Multiple Remote Access Servers


Server Properties - Security Tab - Accounting - Add RADIUS Server

Dialog box element Description

Server name

Type the DNS name or IP address of the Remote Authentication Dial-In User Service (RADIUS) server. IP addresses must be typed in dotted decimal notation.

Shared secret

Displays the obscured shared secret that is used for secure communications between the remote access server and the RADIUS server. You must configure the same shared secret on both the remote access server and the RADIUS server for successful RADIUS communications to occur. The shared secret is case-sensitive.

Time-out (seconds)

Type the amount of time (in seconds) that the remote access server tries to obtain responses from the RADIUS server before trying another RADIUS server. You can also click the arrows to select a new setting.

Initial score

Type the initial responsiveness score of the RADIUS server. You can also click the arrows to select a new setting. The score increases or decreases based on the ongoing responsiveness of the RADIUS server.

Port

For RADIUS Authentication:

Type the UDP port that is used by the RADIUS server for incoming RADIUS authentication requests. The default value of 1812 is based on RFC 2138. For older RADIUS servers, set the port value to 1645.

For RADIUS Accounting:

Type the UDP port that is used by the RADIUS server for incoming RADIUS accounting messages. The default value of 1813 is based on RFC 2139. For older RADIUS servers, set the port to 1646.

Send RADIUS Accounting On and Accounting Off messages

Specifies whether RADIUS Accounting-On and Accounting-Off messages are sent to the RADIUS server when the Routing and Remote Access service starts up and shuts down. You should verify that the RADIUS server supports these messages before selecting this check box.


Server Properties - Security Tab - Authentication - Add RADIUS Server

Dialog box element Description

Server name

The DNS name or IP address of the Remote Authentication Dial-In User Service (RADIUS) server. IP addresses must be typed in dotted decimal notation.

Shared secret

Displays the obscured shared secret that is used for secure communications between the remote access server and the RADIUS server. You must configure the same shared secret on both the remote access server and the RADIUS server for successful RADIUS communications to occur. The shared secret is case-sensitive.

Time-out (seconds)

The amount of time (in seconds) that the remote access server tries to obtain responses from the RADIUS server before trying another RADIUS server. You can also click the arrows to select a new setting.

Initial score

The initial responsiveness score of the RADIUS server. You can also click the arrows to select a new setting. The score increases or decreases based on the ongoing responsiveness of the RADIUS server.

Port

For RADIUS Authentication:

The UDP port that is used by the RADIUS server for incoming RADIUS authentication requests. The default value of 1812 is based on RFC 2138. For older RADIUS servers, set the port value to 1645.

For RADIUS Accounting:

The UDP port that is used by the RADIUS server for incoming RADIUS accounting messages. The default value of 1813 is based on RFC 2139. For older RADIUS servers, set the port to 1646.

Always use message authenticator

Specifies whether a message authenticator based on the shared secret is sent with each RADIUS message. Extensible Authentication Protocol (EAP) messages are always sent with a message authenticator. Make sure that your RADIUS servers are capable of and configured to receive message authenticators.

You must select this option if your RADIUS server is running Network Policy Server (NPS) and the RADIUS client that is configured for this server has the Request must contain the Message Authenticator attribute option selected.


Server Properties - Security Tab - Authentication Methods

Dialog box element | Description
Extensible authentication protocol (EAP) | Specifies whether the server uses the Extensible Authentication Protocol (EAP) to authenticate remote access and demand-dial connections.
EAP Methods… | Click to view the installed EAP methods.
Microsoft encrypted authentication version 2 (MS-CHAP v2) | Specifies whether the server uses Microsoft Challenge Handshake Authentication Protocol (MS-CHAP) version 2 to authenticate remote access and demand-dial connections. MS-CHAP v2 provides mutual authentication and stronger encryption and is required for encrypted Point-to-Point (PPP) or Point-to-Point Tunneling Protocol (PPTP) connections.
Encrypted authentication (CHAP) | Specifies whether the server uses the Message Digest 5 (MD-5) Challenge Handshake Authentication Protocol (CHAP) to authenticate remote access and demand-dial connections.
Unencrypted password (PAP) | Specifies whether the server uses the Password Authentication Protocol (PAP) to authenticate remote access and demand-dial connections. During a PAP authentication, passwords are sent in plaintext, or unencrypted, form. You should use this authentication protocol only if you must support PAP remote access clients.
Allow remote systems to connect without authentication | Specifies whether the server allows unauthenticated connections. Unauthenticated connections do not require a user name or password.

See Also

  • Remote Access Authentication Methods


Server Properties - Security Tab - Authentication Methods - EAP Methods

PEAP

Protected Extensible Authentication Protocol (PEAP) is a new member of the family of Extensible Authentication Protocol (EAP) protocols. PEAP uses Transport Level Security (TLS) to create an encrypted channel between an authenticating PEAP client, such as a wireless computer, and a PEAP authenticator, such as a Network Policy Server (NPS) or Remote Authentication Dial-In User Service (RADIUS) server. PEAP does not specify an authentication method, but provides additional security for other EAP authentication protocols, such as EAP-MSCHAPv2, that can operate through the TLS encrypted channel provided by PEAP. PEAP is used as an authentication method for 802.11 wireless client computers, but is not supported for virtual private network (VPN) or other remote access clients.

To enhance both the EAP protocols and network security, PEAP provides:

  • Protection for the EAP method negotiation that occurs between client and server through a TLS channel. This helps prevent an attacker from injecting packets between the client and the network access server (NAS) to cause the negotiation of a less secure EAP method. The encrypted TLS channel also helps prevent denial of service attacks against the NPS server.

  • Support for the fragmentation and reassembly of messages, allowing the use of EAP types that do not provide this.

  • Wireless clients with the ability to authenticate the NPS or RADIUS server. Because the server also authenticates the client, mutual authentication occurs.

  • Protection against the deployment of an unauthorized wireless access point (WAP) when the EAP client authenticates the certificate provided by the NPS server. In addition, the TLS master secret created by the PEAP authenticator and client is not shared with the access point. Because of this, the access point cannot decrypt the messages protected by PEAP.

  • PEAP fast reconnect, which reduces the delay in time between an authentication request by a client and the response by the NPS or RADIUS server, and allows wireless clients to move between access points without repeated requests for authentication. This reduces resource requirements for both client and server.

Note

  • PEAP does not support guest authentication, which has a blank user name and password.

  • When you deploy both PEAP and EAP unprotected by PEAP, do not use the same EAP authentication type with and without PEAP. For example, if you deploy PEAP with EAP-TLS (PEAP-EAP-TLS), do not also deploy EAP-TLS without PEAP. Deploying authentication methods with the same type -- one with and the other without the protection of PEAP -- creates a security vulnerability.

Using smart cards for remote access

The use of smart cards for user authentication is the strongest form of authentication in the Windows Server® 2008 family. For remote access connections, you must use the Extensible Authentication Protocol (EAP) with the Smart card or other certificate (TLS) EAP type, also known as EAP-Transport Level Security (EAP-TLS). To use smart cards for remote access authentication, you must do the following:

  • Configure remote access on the remote access server.

  • Install a computer certificate on the remote access server computer.

  • Configure the Smart card or other certificate (TLS) EAP type in network policies.

  • Enable smart card authentication on the dial-up or VPN connection on the remote access client.


Setup Wizard - Custom Configuration

Dialog box element | Description
VPN access | Select this option to configure the server running Routing and Remote Access to allow remote access clients to connect to the private network across the Internet. For more information, see What Is VPN?
Dial-up access | Select this option to configure the server running Routing and Remote Access to allow remote access clients to connect to the private network by dialing into a modem bank or other dial-up equipment. For more information, see What Is Dial-Up Networking?
Demand-dial connections (used for branch office routing) | Select this option to configure the server running Routing and Remote Access to initiate and receive demand-dial connections. For more information, see What Is Demand-Dial Routing?
NAT | Select this option to configure the server running Routing and Remote Access to share an Internet connection with computers on the private network and to translate traffic between its public address and the private network. For more information, see What Is NAT?
LAN routing | Select this option to configure the server running Routing and Remote Access to forward network packets from one LAN network segment to another. For more information, see Routing.

See Also

  • Common Remote Access Configurations


Setup Wizard - Network Interfaces

Network interfaces

Network interfaces enable any server running Routing and Remote Access to communicate with other computers over private or public networks. Network interfaces have two aspects that relate to Routing and Remote Access: the physical hardware, such as a network adapter, and the network interface configuration.

Physical hardware

Network interface hardware, commonly called network adapters, can be any adapter that plugs into the system bus of a computer and allows that computer to connect to a network. Most servers running Routing and Remote Access have at least two network adapters. This is required if the server running Routing and Remote Access is acting as a router between two network segments. A server that has two or more network adapters connecting to separate networks is called multihomed.

Important

  • Because multihomed servers are accessible from more than one network, they have more security requirements than a server that is connected to a single network. Each network interface must be configured correctly in order to protect the server and the private networks to which the server connects.

The server running Routing and Remote Access usually detects all network adapters automatically when the Routing and Remote Access Server Setup Wizard is run. If you install an additional network adapter after the wizard has been run, you can add and configure the interface using Routing and Remote Access.

Network interface configuration

In Routing and Remote Access, network interfaces fall into the following categories:

  • Private interface. A private interface is a network adapter that is physically connected to a private network. Most private networks are configured with a private network IP address range, and the private interface is also configured with a private address. Because a private network is, in theory, composed of known users and computers, you generally have fewer security considerations for a private interface than for a public interface. For more information, see Internet Private Addresses.

  • Public interface. A public interface is a network adapter that is physically connected to a public network, such as the Internet. The public interface is configured with a public IP address. You can configure a public interface to perform network address translation (NAT). Because a public interface is theoretically accessible by anyone on the public network, security considerations are generally higher for a public interface than for a private interface. For more information, see Network Address Translation.

  • Demand-dial interface. Demand-dial interfaces connect specific routers on either public or private networks. A demand-dial interface can be either on-demand (activated only when needed) or persistent (always connected). For more information, see Demand-Dial Routing.

See Also

  • Filters and Remote Access Configurations


Setup Wizard - Remote Access

For more information, see:

  • What Is VPN?

  • What Is Dial-Up Networking?


Setup Wizard - Remote Access - Dial-up - Network Selection

To provide dial-up clients access to your organization's intranet, you must have a network interface installed and connected to your intranet. If you have multiple network adapters installed, you must select the adapter connected to the network to which the server provides access.


Setup Wizard - Remote Access - VPN - Managing Multiple Remote Access Servers

The remote access server can be configured to use either Routing and Remote Access or RADIUS as an authentication provider.

If Routing and Remote Access is selected as the authentication provider, the user credentials sent by users attempting connections are authenticated using typical Windows authentication mechanisms, and the connection attempt is authorized using the remote client’s user account properties and network policies. The remote access server must be joined to a domain to authenticate with Active Directory.

If RADIUS is selected and configured as the authentication provider on the remote access server, user credentials and parameters of the connection request are sent as RADIUS request messages to a RADIUS server. The RADIUS server receives a user-connection request from the remote access server and authenticates and authorizes the connection attempt. The RADIUS server must be joined to a domain to authenticate with Active Directory.

Using RADIUS

If you have more than one remote access server, rather than administer the network policies of all the remote access servers separately, you can configure a single server with the Network Policy Server (NPS) as a Remote Authentication Dial-In User Service (RADIUS) server and configure the remote access servers as RADIUS clients. The NPS server provides centralized remote access authentication, authorization, accounting, and auditing.

For more information about NPS, see Network Policy Server Help.


Setup Wizard - User Accounts

After a remote access server is installed, you must specify from which users the remote access server can accept a connection. For a server running Routing and Remote Access, authorization is determined by the dial-in properties on the user account, the network policies, or both. For more information, see Network Policies.

You do not need to create user accounts just for remote access users. Remote access servers use the user accounts specified in the available user accounts databases.

How security works at connection

The following steps describe what happens during a call from a remote access client to a server running Routing and Remote Access that is configured to use Windows Authentication:

  1. A remote access client dials a remote access server.

  2. The server sends a challenge to the client.

  3. The client sends an encrypted response to the server that consists of a user name, a domain name, and a password.

  4. The server checks the response against the appropriate user accounts database.

  5. If the account is valid and the authentication credentials are correct, the server uses the dial-in properties of the user account and network policies to authorize the connection.

If callback is enabled, the server hangs up the connection, calls the client back, and continues the connection negotiation process.

Note

  • Steps 2 and 3 assume that the remote access client and the remote access server use the MS-CHAP v2 or CHAP authentication protocols. The sending of client credentials may vary for other authentication protocols.

  • If the remote access server is a member of domain and the user response does not contain a domain name, then the domain name of the remote access server is used. If you want to use a different domain name than that of the remote access server, set the following registry value on the remote access client to the name of the domain that you want to use:

    HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\RasMan\PPP\ControlProtocols\BuiltIn\DefaultDomain

Caution

Incorrectly editing the registry might severely damage your system. Before making changes to the registry, you should back up any valued data on the computer.

Security after the connection is made

Credentials used for remote access only provide a communication channel to the target network. The client does not log on to the network as a result of a remote access connection. Each time the client attempts to access a network resource, it will be challenged for credentials. If it does not respond to the challenge with acceptable credentials, the access attempt will fail. Windows Vista® and the Windows Server® 2008 family adds a feature to simplify remote access. After a successful connection, Windows Vista and Windows Server 2008 family remote access clients will cache these credentials as default credentials for the duration of the remote access connection. When a network resource challenges the remote access client, the client provides the cached credentials without requiring the user to enter them again.