VPN Networking Over the Internet with DSL Connections
High speed DSL connections make a reasonable connection media for establishing a virtual private network (VPN) over the Internet. For those trying to set up a VPN, I provide a detailed description of a configuration I use. It should provide some idea of the possibilities for VPN configuration.
One configuration I use involves a VPN established between an NT 4 (SP5) RRAS server, using PPTP as the VPN protocol. The client host is an NT4 (SP5) machine, also using the RRAS service provided by Microsoft as part of NT. The client machine sits behind a Sygate NAT server. The Sygate host is connected to a Cisco 675 DSL modem, which is running in bridging mode and is connected to US West's Megabit service, with uswest.net as the ISP. The server machine is behind a Sonicwall firewall. The Sonicwall is running in NAT mode. The Sonicwall is connected to a Lucent ADSL modem, which is running in bridging mode and is connected to a non-national ISP. This setup is depicted in the following figure:
In this configuration, both the client and the server in the VPN setup are situated behind NAT/firewalls. The NAT server at the client end requires no special NAT port mapping configuration. The NAT server at the server end requires only two NAT port mapping entries, as specified in the figure.
The performance of this VPN arrangement (as of NT4, SP5) is significantly below the weak link in the communications chain. While transferring a large chunk of data from the client to the server, with a 272kbits/sec uplink limit on the client, file transfer performance was about 9 to 10 kbytes/sec, which corresponds to less than one third of the link's performance capabilities.
http://msdn.microsoft.com/library/backgrnd/html/InstPPTP.htm is a good link providing the details on setting up Microsoft's PPTP.
Oftentimes, once a VPN connection is successfully made, there are problems browsing or addressing resources on the remote network using NetBIOS name resolution. One mechanism for debugging name resolution problems is to use IP address directly to skip the name resolution issue: for example, in the above diagram the client could use the following command to browse the Server PC without a name resolution: "net view \\192.168.1.2" The "Windows File Sharing" page has more details about this technique and NetBIOS name resolution.
Unable to Resolve NetBIOS Names Through PPTP Connection is a Microsoft knowledge base article with some good information about NetBIOS name resolution problems through a PPTP VPN.
A long USENET discussion dives into the details of name resolution and VPN.
Using the configuration specified above, my VPN connection would consistently disconnect (drop the line) after a number of minutes of activity (anywhere from 3 to 30 minutes was common). The NT event log on the VPN server indicated that the line was dropped because of a client request to drop the line.
I was able to eliminate the dropped line problem by adding the following two registry entries to the client PC:
The EchoReplyTimeoutSeconds entry raises the time the client waits for a reply to an echo keepalive packet to 360 (168 Hex) seconds. The InactivityIdleSeconds entry raises the time the client waits during idle periods before sending an Echo keepalive packet to the server.
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tracing\EnableConsoleTracing, REG_DWORD = 1 to turn tracing on, 0 = tracing off. Tracing for individual components can then be configured as on or off by setting the EnableConsoleTracing value for each subkey under the Tracing service key. The Ras service must be restarted for changes in the tracing flags to take effect.
Copyright © 1999 Real Author
Last modified: março 13, 2002