Deploying Virtual Private Networks with Microsoft Windows Server 2003 (Technical Reference)

2017-07-07 02:10:07

The network infrastructure of the intranet is an important element of VPN design. Without proper design, VPN clients are unable to obtain proper IP addresses and resolve intranet names, and packets cannot be forwarded between VPN clients and intranet resources. Without proper access to and testing of these internal resources, connections from the server to the client will be completed but the clients will not be able to access any resources on the intranet.

Name Resolution

If you use DNS to resolve intranet host names or WINS to resolve intranet NetBIOS names, ensure that the VPN server is configured with the IP addresses of the appropriate internal DNS and WINS servers. To ensure proper name resolution for resources outside of the intranet, configure the internal DNS and WINS servers to query external ISP servers. This is an important design point—if you don’t do this, the VPN clients will not function properly. The VPN server should be configured with DNS and WINS servers manually. As part of the PPP negotiation process, the VPN clients receive the IP addresses of DNS and WINS servers. By default, the VPN clients inherit the DNS and WINS server addresses configured on the VPN server.

After the PPP connection negotiation is complete, Windows XP and Windows 2000 VPN clients send a DHCPInform message to the VPN server. The response is relayed back to the VPN client and contains a DNS domain name, additional DNS server addresses for DNS servers that were checked before the DNS server is configured through the PPP negotiation, and WINS server addresses that replace the WINS server addresses configured through the PPP negotiation. This communication is facilitated by the DHCP Relay Agent routing protocol component of the Routing And Remote Access service, which is automatically added by the Routing And Remote Access Server Setup Wizard.

If the VPN server is a DHCP client (that is, the VPN server is using DHCP to configure its intranet interfaces), the VPN server relays the DHCPInform messages to the DHCP server that was in use when the Routing And Remote Access Server Wizard was run. If the VPN server has a manual TCP/IP configuration on its intranet interface (the recommended option), the DHCP Relay Agent routing protocol component must be configured with the IP address of at least one DHCP server on your intranet. You can add DHCP server IP addresses to the DHCP Relay Agent routing protocol component on the General tab from the properties of the DHCP Relay Agent object under IP Routing in the Routing And Remote Access snap-in.

Design Point: Name Resolution by VPN Clients for Intranet Resources

Consider the following when configuring name resolution for remote access VPN clients:

Using the Ping and Net tools, test DNS and WINS name resolution for intranet resources from the VPN server computer. If name resolution does not work from the VPN server, it will not work for VPN clients. Troubleshoot and fix all name resolution problems of the VPN server before testing VPN connections.

If the VPN server is a DHCP client (that is, the VPN server is using DHCP to configure its intranet interfaces), no other configuration is necessary. The DNS and WINS servers assigned to the VPN server are also assigned to the VPN clients. The default configuration of the Routing And Remote Access Server Setup Wizard adds the DHCP Relay Agent routing protocol component and configures it with the IP address of the VPN server’s DHCP server. It does this so that DHCPInform messages sent by VPN clients running Windows XP and Windows 2000 (and the responses to these messages) are properly relayed between the VPN client and the DHCP server of the VPN server.

However, configuring the VPN server as a DHCP client is not recommended because of issues with configuring the VPN server’s default gateway. Therefore, we recommend that you manually configure the TCP/IP configuration of the VPN server’s intranet interfaces and manually configure the DHCP Relay Agent routing protocol component with the IP address of one or more of your DHCP servers.

If the VPN server is manually configured with a TCP/IP configuration, verify the DNS and WINS server addresses. In this configuration, the Routing And Remote Access Server Setup Wizard cannot automatically configure the DHCP Relay Agent routing protocol component. You must manually add the IP address of at least one DHCP server on your intranet for DHCPInform messages to be relayed between VPN clients running Windows XP and Windows 2000 and the DHCP server. If you do not, DHCPInform messages sent by VPN clients running Windows XP and Windows 2000 are discarded and the VPN clients do not receive the updated DNS and WINS server addresses or the DNS domain name.

If you have a single-subnet small office/home office (SOHO) with no DHCP, DNS, or WINS server, you must either configure a DNS server or WINS server to resolve names for both computers on the SOHO subnet and VPN clients or enable NetBIOS broadcast name resolution, which enables NetBIOS-over-TCP/IP name resolution between connected VPN clients and computers on the SOHO network. NetBIOS broadcast name resolution can be enabled from the IP tab in the properties of a VPN server in the Routing And Remote Access snap-in.

Routing

By its very nature and purpose, the VPN server is an IP router. This is because it connects two or more network subnets—in this case, the Internet and the intranet—and, as such, must be properly configured with the set of routes that makes all locations reachable. Specifically, the VPN server needs the following:

On the Internet-attached interface, a default route that points to a firewall or router directly connected to the Internet. This route makes all locations on the Internet reachable.

One or more routes that summarize the addresses used on your intranet that point to a neighboring intranet router. These routes make all locations on your intranet reachable from the VPN server. Without these routes, all intranet hosts not connected to the same subnet as the VPN server are unreachable.

To add a default route that points to the Internet, configure the Internet interface with a default gateway and then manually configure the intranet interface without a default gateway.

To add intranet routes to the routing table of the VPN server, you can:

Add static routes using the Routing And Remote Access snap-in. You do not have to add a route for each subnet in your intranet. At a minimum, you need to add the routes that summarize all the possible addresses in your intranet. For example, if your intranet uses portions of the private address space 10.0.0.0/8 to number its subnets and hosts, you do not have to add a route for each subnet. Just add a route for 10.0.0.0 with the subnet mask 255.0.0.0 that points to a neighboring router on the intranet subnet to which your VPN server is attached. It is a common mistake to configure a default gateway on an intranet interface. Doing this will make either the Internet or your intranet unreachable. The only default route on the VPN server should point to the Internet. Use explicit routing entries to make all intranet locations reachable.

For complex intranets with multiple subnets, you can use dynamic routing protocols. If you are using the Routing Information Protocol (RIP) or the Open Shortest Path First (OSPF) routing protocol in your intranet, you can add and configure the RIP or OSPF routing protocol components of the Routing And Remote Access service so that the VPN server participates in the propagation of routing information as a dynamic router. Turn on dynamic routing only if your company already has a dynamic protocol running for routing control and has multiple internal subnets that the VPN server needs to know about. If your intranet has only a single subnet, no further configuration is required.

Ensuring the reachability of VPN clients from the intranet depends on how you configure the VPN server to obtain IP addresses for VPN clients. The IP addresses assigned to VPN clients as they connect can be from:

An on-subnet address range, which is an address range of the intranet subnet to which the VPN server is attached. An on-subnet address range is used whenever the VPN server is configured to use DHCP to obtain IP addresses for VPN clients and when the manually configured pool or pools of IP addresses are within the range of addresses of the attached subnet.

An off-subnet address range, which is an address range that represents a different subnet that is logically attached to the VPN server. An off-subnet address range is used whenever the VPN server is manually configured with a pool or pools of IP addresses for a separate subnet.

If you are using an on-subnet address range, no additional routing configuration is required, as the VPN server acts as a proxy for all packets destined for VPN clients. Routers and hosts on the VPN server subnet forward packets destined to VPN clients to the VPN server, and the VPN server relays them to the appropriate VPN client.

If you are using an off-subnet address range, you must add the routes that summarize the off-subnet address range to the intranet routing infrastructure so that traffic destined to VPN clients is forwarded to the VPN server and then sent by the VPN server to the appropriate VPN client. To provide the best summarization of address ranges for routes, choose address ranges that can be expressed using a single prefix and subnet mask. For more information, see the topic “Expressing an IP Address Range with a Mask” in Help And Support Center for Windows Server 2003.

You can add the routes that summarize the off-subnet address range to the routing infrastructure of the intranet using the following methods:

Add static routes to the neighboring router for the off-subnet address range that point to the VPN server’s intranet interface. Configure the neighboring router to propagate these static routes to other routers in the intranet, using the dynamic routing protocol used in your intranet.

If the VPN server is using OSPF and participating as a dynamic router, the VPN server must be configured as an autonomous system boundary router (ASBR) so that the static routes of the off-subnet address range are propagated to the other OSPF routers in the intranet. For more in-depth information on OSPF configurations on Windows Server 2003, see the topic titled “OSPF design considerations” in Windows Server 2003 Help and Support.

If your intranet consists of a single subnet, you must either configure each intranet host for persistent routes of the off-subnet address range that point to the VPN server’s intranet interface or configure each intranet host with the VPN server as its default gateway. Therefore, we recommend that you use an on-subnet address pool for a SOHO network consisting of a single subnet.

VPN Client Routing and Simultaneous Intranet and Internet Access

By default, when a Windows-based VPN client makes a VPN connection, it automatically adds a new default route for the VPN connection and modifies the existing default route to have a higher metric, thus making the new default route the prevalent and preferred one. Adding the new default route means that all Internet locations (except the IP address of the tunnel server and locations based on other routes) become unreachable for the duration of the VPN connection.

To prevent the default route from being created, go to the Properties sheet for the Internet Protocol (TCP/IP) component of the VPN connection. Click Advanced. In the Advanced TCP/IP Settings dialog box, click the General tab, and then clear the Use Default Gateway On Remote Network check box. When the Use Default Gateway On Remote Network check box is cleared, a default route is not created; however, a route corresponding to the Internet address class of the assigned IP address is created. For example, if the address assigned during the connection process is 10.0.12.119, the Windows 2000 or Windows XP VPN client creates a route for the class-based network ID 10.0.0.0 with the subnet mask 255.0.0.0.

Based on the Use Default Gateway On Remote Network setting, one of the following occurs when the VPN connection is active:

Internet locations are reachable and intranet locations are not reachable, except those matching the address class of the assigned IP address. (The Use Default Gateway On Remote Network check box is cleared.)

All intranet locations are reachable and Internet locations are not reachable, except the address of the VPN server and locations available through other routes. (The Use Default Gateway On Remote Network check box is selected.)

For most Internet-connected VPN clients, this behavior does not represent a problem because they are typically engaged in either intranet or Internet communication, not both.

For VPN clients who want concurrent access to intranet and Internet resources when the VPN connection is active, you can do one of the following:

Select the Use Default Gateway On Remote Network check box (the default setting) and allow Internet access through the organization intranet. Internet traffic between the VPN client and Internet hosts would pass though firewalls or proxy servers as if the VPN client is physically connected to the organization intranet. Although it has an impact on performance, this method allows Internet access to be filtered and monitored according to the organization’s network policies while the VPN client is connected to the organization network.

If the addressing within your intranet is based on a single class-based network ID, clear the Use Default Gateway On Remote Network check box. The best example is when your intranet is using the private IP address space 10.0.0.0/8.

If the addressing within your intranet is not based on a single class-based network ID, you can use one of the following solutions:

The DHCPInform message sent by Windows XP clients includes the requesting of the DHCP Classless Static Routes DHCP option. If configured on a Windows Server 2003 DHCP server, the Classless Static Routes DHCP option contains a set of routes representing the address space of your intranet that are automatically added to the routing table of the requesting client.

The CMAK for Windows Server 2003 allows you to configure specific routes as part of the CM profile distributed to VPN users. You can also specify a Uniform Resource Locator (URL) that contains the current set of organization intranet routes or additional routes beyond those configured in the profile.

Clear the Use Default Gateway On Remote Network check box, and use the route add command set on the VPN client to add static routes for the network IDs of your intranet. The intranet static routes should point to the IP address that was assigned to the client by the VPN gateway as the next routed hop. That way, all unknown traffic will flow to the VPN tunnel for resolution.

Tip

Using one of the preceding methods is a practice known as split-tunneling, which means that there are active routes from the client to the insecure Internet and the company’s intranet. Usually, split-tunneling is not a good idea because it creates a security breach from the connected VPN clients to the user’s home network. If a client that has IP routing enabled is compromised by a hacker and the VPN connection was made with split-tunneling enabled, the entire corporate network can be compromised. Most security policies do not allow split-tunneling as a default policy.

From the client computer, you can determine your assigned IP address from the display of the Ipconfig command or by double-clicking the VPN connection in the Network Connections folder when the VPN connection is active. In the resulting Status dialog box, click the Details tab. The VPN client’s assigned IP address is listed as Client IP Address.

Design Point: Routing Infrastructure

Consider the following when configuring the routing infrastructure for remote access VPN connections:

Configure the Internet interface of the VPN server with a default gateway. Do not configure the intranet interface of the VPN server with a default gateway.

Add static IP routes to the VPN server that summarize the addresses used in your intranet. Alternatively, if you use either RIP or OSPF for your dynamic routing protocol, configure and enable RIP or OSPF on the VPN server. If you are using a Cisco proprietary routing protocol such as Interior Gateway Routing Protocol (IGRP) or Extended IGRP (EIGRP) instead of industry-standard routing protocols such as RIP or OSPF, you might configure the VPN server’s neighboring Cisco intranet router for RIP or OSPF on the interface connected to the subnet to which the VPN server is attached and IGRP on all other interfaces. You would then redistribute the IGRP routes into the RIP or OSPF routing tables. Refer to your Cisco router documentation to get more information on route redistribution.

Configure the VPN server with an on-subnet address range by obtaining IP addresses through DHCP or by manually configuring on-subnet address pools.

Quarantine Resources

Network Access Quarantine Control, a new feature in the Windows Server 2003 family, delays normal remote access to a private network until the configuration of the remote access computer has been examined and validated by an administrator- provided script. When a remote access computer initiates a connection to a remote access server, the user is authenticated and the remote access computer is assigned an IP address. However, the connection is placed in quarantine mode, in which network access is limited. The administrator-provided script is run on the remote access computer. When the script notifies the remote access server that it has successfully run and the remote access computer complies with current network policies, quarantine mode is removed and the remote access computer is granted normal remote access. If the client computer does not pass quarantine, the server will drop the connection.

Quarantine resources consist of servers that a remote access client in quarantine mode can access to perform name resolution (DNS servers), to obtain the latest version of the script (file servers with anonymous access allowed), or to get instructions and components needed to make the remote access client comply with network policies (Web servers with anonymous access allowed).

For more information about deploying Network Access Quarantine Control, see Chapter 6.