Just setting up a VPN with Routing and Remote Access Server (RRAS) is not enough when working in an enterprise-level environment. For ultimate speed and security, you need to optimise 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 optimising inbound VPN client connections. From the server side, there are several services, such as WINS, DNS, and DHCP, that 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 function as if they were directly connected to the internal network via an Ethernet cable (although the VPN connections may not be as fast). Ultimately, that means you'll get a lot fewer support calls from your VPN users. Here, I will explain how you can optimise WINS, DNS, DHCP, and the routing table and addressing infrastructure to improve your VPN clients' speed and security. WINS
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 relies 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 client note
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. DNS
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 hostname resolution. Although DNS doesn't populate the browser list, it performs a number of other valuable functions for your VPN clients. 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.

---