VPN Networking Over the Internet with DSL Connections

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.

Microsoft's VPN (PPTP and Windows NT 4.x)

http://msdn.microsoft.com/library/backgrnd/html/InstPPTP.htm is a good link providing the details on setting up Microsoft's PPTP.

Name Resolution and VPN

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.

Disconnection (dropped line) problems

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:

HKEY_LOCAL_MACHINE\System\CurrentConfiguration \Services\RASPPTPE\Parameters\Configuration\ EchoReplyTimeoutSeconds	REG_DWORD	0x168
HKEY_LOCAL_MACHINE\System\CurrentConfiguration \Services\RASPPTPE\Parameters\Configuration\ InactivityIdleSeconds	REG_DWORD	0x168

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.

Registry settings for tracing RRAS and PPTP actions:

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.