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 but 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 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 is 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 that is 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.
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. Summary
The Windows 2000 Routing and Remote Access Service may make it easier to create a VPN server, but 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 show you 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.
Have your say instantly in the Tech Update forum.
Find out what's where in the new Tech Update with our Guided Tour.
Let the editors know what you think in the Mailroom.
Talkback
I came across this article as I'm trying to resolve (pardon the pun) the issue of whether or not I need WINS (for performance).
I take issue with the statement that a WINS server is required on the network to do browsing.
I am currently running a VPN into a Windows 2003 based network, with an XP client, and as long as I configure (via network connection properties, which in turn can be configured by the DHCP server) advanced DNS settings with mydomainname.local in the DNS suffix, browsing the domain works fine - and not a WINS server to be found.
any tips on using the vpn with cadd file networking?
H. E.