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.
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.
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.
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.
