Just setting up a VPN with RRAS is not enough when working in an enterprise-level environment. For ultimate speed and security, you need to optimize both the client-side and network-side services. For a review of methods that you can employ on the client side, check out my article on optimizing inbound VPN client connections.

From the server side, there are several services, such as WINS, DNS, and DHCP, you should configure on the internal network with your VPN clients in mind. Once you have these services set up correctly, your VPN client connections will work as if they were directly connected to the internal network via an Ethernet cable. Ultimately, that means you’ll get a lot fewer support calls from your VPN users.

Here, I will explain how you can optimize WINS, DNS, DHCP, and the routing table and addressing infrastructure to improve your VPN clients’ speed and security.

The Windows Internet (network) Naming Server (WINS) resolves NetBIOS names to IP addresses. I’ve heard people say that if you run a Windows 2000-only network, you don’t need a WINS server. This is only partially true. The fact is, you don’t need WINS if you run a Windows 2000 network that doesn’t require any NetBIOS services. Unfortunately, many popular network services are dependent on the NetBIOS interface and NetBIOS name resolution.

The most prominent NetBIOS-dependent service is the browser service. The browser service is responsible for populating the browser list, which appears as a list of network resources (computers) in the Network Neighborhood or the My Network Places application. Because the browser service is a NetBIOS-dependent service, it depends on local subnet broadcasts to communicate with other browser service participants.

This creates a problem when your VPN clients need to browse to resources on subnets outside of the broadcast range of the VPN interface on the VPN server. To solve the broadcast problem, you must install and configure a WINS server on the internal network. Also, all servers on the network need to be configured as WINS clients, especially servers that can act as master browsers on their local subnet. This also includes the PDC or PDC emulator for the network, because they collate and redistribute the browser list.

The VPN client obtains the WINS server address from the VPN server. This address is typically obtained from the internal interface of the VPN server. However, if you have multiple internal interfaces, you might need to manually select the interface that assigns name server addresses. Another option is to have a DHCP server assign name server addresses to the VPN client.

While the most common method of assigning IP address and name server information to VPN clients is via automatic assignment by the VPN server, you aren’t limited to this option. The VPN client software can be configured with static IP and name server addresses. VPN clients can also be assigned IP addresses on a per-user account basis. Note that you cannot assign name servers based on user account.

VPN clients never directly communicate with a DHCP server

Keep in mind that VPN clients are RAS clients, so they never directly communicate with a DHCP server—not even when you have configured the VPN server to obtain IP addresses from a DHCP server. However, your VPN clients can obtain DHCP options by configuring a DHCP relay agent on the VPN server itself. DHCP options such as WINS and DNS server addresses can be assigned this way. One thing you cannot assign to RAS clients via DHCP options is a default gateway. The VPN clients will always be assigned a default fault and host route to the IP address of the tunnel server’s virtual IP address.

The WINS server is even more useful for allowing clients to connect via a UNC path. The VPN client will query the internal network WINS server that was assigned to the VPN interface on the client, and the WINS server will return the IP address of the server on the internal network.

“Setting up WINS in Windows 2000”

For an in-depth look at how to set up a WINS server in Windows 2000, read this article by Ron Nutter.

If you construct your network well, you’ll have relatively little use for NetBIOS-dependent applications. The majority of applications used on current networks aren’t tied to the NetBIOS interface; they are native TCP/IP-based applications. These applications and services use DNS for host name resolution. Although DNS doesn’t populate the browser list, it performs a host of other valuable functions for your VPN clients.

Creating a DNS server

For more information on how to set up a DNS server on a Windows NT machine, take a look at this article by Brien Posey.

For VPN clients to access Web, FTP, e-mail, and news services on your internal network using FQDNs, you want to ensure that DNS is configured on the internal network. If you are running a Windows 2000 Active Directory network, you already have a DNS infrastructure in place. If you aren’t running Active Directory or DNS on your internal network, you’ll find that name resolution will proceed much faster and more reliably after installing DNS and configuring the VPN client to use the internal network DNS server.

Use Nslookup to confirm DNS functionality

When setting up your VPN clients to use the internal network DNS infrastructure, you should test the configuration before allowing your users to connect to the VPN. You can quickly test the VPN client DNS functionality using the Nslookup tool. Create a dial-up connection to the VPN server and then open a command prompt. Type nslookup and the fully qualified domain name of an internal network host, such as server1.internal.net. Nslookup should return the proper internal network address for server1.internal.net.

If you work on a network of any appreciable size, you probably already have a DHCP server providing IP addressing information to your internal network clients. That same DHCP server or servers can be used to assign IP addresses to your VPN clients. You can create custom scopes for your VPN clients to make it easier to control the IP address assignment to these machines.

A note about scopes

A scope is a collection of IP addresses that belong to a particular network ID. When a DHCP server is configured with a scope, it can service requests for IP addresses from clients on that network ID.

The DHCP server can be on the same network as the internal interface of the VPN server or on a remote network. If you need to use a DHCP server on a remote network, you must configure a DHCP Relay Agent, which acts as a router for DHCP messages. The VPN server will be able to obtain addresses for the DHCP clients by taking advantage of the DHCP message routing capabilities of the DHCP Relay Agent, which is why the DHCP Relay Agent is considered a routing protocol.

Installing and configuring the DHCP Relay Agent on the VPN server is easy. In the RRAS console, expand your server name and then expand the IP Routing node. Right-click the General node and select New Routing Protocol. In the New Routing Protocol dialog box, click on the DHCP Relay Agent entry and click OK.

The DHCP Relay Agent will appear in the left pane. Right-click the DHCP Relay Agent node and select New Interface. Click on Internal and OK. In the DHCP Relay Properties dialog box, leave the defaults—unless you want the DHCP packets to hop more than four routers—and click OK. Right-click the DHCP Relay Agent node and open its properties sheet. In the DHCP Relay Agent Properties dialog box, type in the IP address of the DHCP server and then click Add and OK. The DHCP Relay Agent will now forward DHCP messages to the DHCP server you entered in the Properties dialog box.

Note that if you place the DHCP server on a remote network, the server should have a NIC installed with an IP address for each network ID for which it has scopes. If you try to logically multihome the server, all the addresses will be served from the scope matching the primary IP address bound to the network interface. Each interface is connected to the same physical segment. The Relay Agent will allow assignment from the appropriate scope, but DHCP clients on the same physical segment as the multihomed DHCP server can receive addresses from any of the scopes.

Multihomed DHCP servers

You can multihome a DHCP server so that it supports scopes on multiple network IDs. However, the server must be physically, instead of logically, multihomed, because the DHCP server service will only bind the primary IP address on each interface. The primary IP address is the IP address on the top of the list of IP addresses found in the Advanced tab of the TCP/IP configuration for the interface.

Routing tables
When you have a single network segment on your internal network, you don’t have to worry about router issues. The VPN clients can be assigned IP addresses on the same network ID as the internal interface of the VPN server and reach all resources on the local network segment. However, problems arise when the internal network has multiple subnets.

If the internal network has multiple network IDs and VPN clients need to reach resources on these multiple network IDs, configure the routing table on the VPN server. The VPN clients take advantage of the router table on the VPN server to reach resources on remote networks.

If there are only a few internal subnets, and only a single path to each subnet, you can configure the routing table on the VPN server manually. The routing table can be configured using either the Route Add command or by using the Routing and Remote Access console. I recommend you use the RRAS console to create new routing table entries, as the GUI interface is easier to use and leads to fewer mistakes in configuration.

Large networks that allow multiple paths to internal network resources don’t lend themselves to static routing table entries. These networks require that you use a routing protocol. The Windows 2000 RRAS supports both the Routing Information Protocol version 2 (RIPv2) and Open Shortest Path First (OSPF). RIPv2 is the easiest to configure; it requires little or no configuration after it’s installed. RIPv2 supports Variable Length Subnet Masking (VLSM) and password protection for sharing routing information with its neighbors. OSPF is a more powerful routing protocol that provides a great array of routing options, but it is more complex to configure and shouldn’t be considered a “plug and play” routing protocol solution. While RIPv2 is much easier to set up and configure, it doesn’t scale well, because it’s a broadcast-based protocol.

Once the VPN server has routing table entries for all the subnets on the internal network, the VPN clients will be able to reach all segments on the internal network.

Protocols and routing tables

For more information, check out the following articles:
“Advanced RIP configuration”
“Getting to know Open Shortest Path First (OSPF)”
“Configuring Routing and Remote Access on your Windows 2000 server”

Gateway configuration on the VPN client
The default Microsoft VPN client configuration sets the client to use the default gateway on the remote network. When you select this option, a new default gateway is set on the VPN client, which represents a host-based route that sends all nonlocal packets through the VPN interface. The change in the default gateway on the client can cause some sticky issues.

For example, suppose the client is a laptop computer that isn’t connected to a network that establishes a link to the Internet using a dial-up modem interface. The modem creates a connection to the ISP, which creates a default route on the laptop so that all nonlocal packets are sent to the ISP’s router. When the user establishes the VPN link, a new gateway with a lower metric is created on the laptop’s local routing table. All nonlocal packets are routed through the VPN interface, which makes it impossible for the laptop to access the Internet and the internal network through the VPN interface at the same time.

This should be considered a good thing. It isn’t very wise to allow VPN clients to bridge their Internet and VPN connections because the client can act as a gateway for Internet intruders to access the corporate network. This is akin to allowing your corporate network users to attach modems to their desktops and connect to the Internet while still connected to the corporate network. You don’t let your internal network desktop users do this, and you shouldn’t allow it on your VPN clients either.

However, a workaround for this problem would be to manually create static routing table entries on the laptop computers after the VPN link is established. The reason for this is that if you use DHCP to assign IP address to the VPN clients, you never know what the gateway address will be for the client’s VPN connection. To get around the dynamic address assignment issues, you can assign a static IP address to a user’s account on the Dial-in tab of the user account properties. A far superior solution is to configure the VPN client machines to use the corporate Proxy/Firewall servers to access the Internet. Then, you force the VPN clients to conform to the corporate Internet security policy.

When a machine connected to the routed corporate network needs to create a VPN link to a VPN server on an external network—or even on the intranet if you are using VPNs to segregate your security zones—you may have another issue. The default gateway will change to the VPN interface and the machine will no longer be able to access remote subnets on the corporate network. The solution is to enter routing table entries for all the subnets on the machine connected to both the VPN and the corporate network. You can create static routing table entries; however, on a large network, this is unfeasible. A better solution is to enable a RIP listener on the machine.

To enable a RIP listener on a client machine, do the following:

  • Open Control Panel and click Add | Remove Programs.
  • Click Add | Remove Windows Components.
  • Click Networking Services.
  • Select the Rip Listener check box.
  • Click OK.

After the RIP listener is enabled, the machine will listen for RIP version 1 broadcasts. So if you’re using only RIPv2, the RIP listener will not use routing table entries. The Windows 2000 RRAS server can be configured to issue RIP v1 and v2 broadcasts to support machines configured as RIP listeners.

VPN clients cannot be configured as RIP listeners

Machines connected to the internal network can be configured as RIP listeners, because the RIP listener software listens on the physical interface. The RIP listener doesn’t listen on the virtual interface. Even if the RIP routing protocol is installed on the VPN server, it will not be able to share routing table information with VPN clients. The RIP listener isn’t an answer to the routing table problems that dial-up modem clients have when connecting to the VPN server over the Internet.

The Windows 2000 Routing and Remote Access Service may make it easier to create a VPN server; however, getting the internal network tuned up to support your VPN clients takes a bit more effort. The tips in this article should help you appreciate the importance of having WINS, DNS, and DHCP servers on the internal network to support the VPN clients, and how VPN clients handle routed internal networks. With this information, you’ll be ready to begin that VPN rollout that your boss has been bugging you to get started.