I have a fairly complex VPN issue that is dropping connections and I don't
know where to turn next. Any insights are greatly appreciated. Please
respond to the list rather than to me personally.
Short story: I can connect my two machines over a VPN, the connection will
only stay up for a short period of time (anywhere from 10 seconds, to 10
Machine A (VPN Client): Windows XP Home with wireless LAN card.
Machine B (VPN Server): Windows XP Pro with 100mb wired connection.
Machine A connects to a wireless linksys firewalled broadband router.
Firewalled router connects to Westall DSL Modem connected to the Verizon
Machine B connects to a 3COM 12 port hub.
3COM 12 port hub connects to linksys firewalled router.
linksys firewalled router connects to Westall DSL moden connected to the
Firewalled router has the port corresponding to PPTP opened. I have also
opened the SQL Server listenening port and the IPSec port.
Machine B has a VPN server side connection configured with 8 IP addresses
Machine B has a DNS entry maintained at DYNDNS.ORG that points to the IP
address of the Westall modem. So address resolution from a dynamic IP
address isn' a problem.
I have verified that the IP address is not changing when the drop occurs.
Machine A connects to Machine B just fine. I can map a drive using the
server machine VPN IP address. I can move small files between Machine A and
The connection will not stay up for more than a couple of minutes.
I have SQL Server running on machine B. I can run the client side on Machine
A after the connection is made and sucessfully open the data base.
Any major SQL update transaction fails with any number of timeout based
error messages. Any attemt to move a file of significant size fails with a
variety of file based error messages. In both instances, the connection is
always lost. Double clicking on the connection will always restore the
connection. However, subsequent operations will still fail.
I'm able to map a drive letter on Machine A to file share on machine B using
the \\ip_address\sharename convention where the ip_address is the ip_address
of the server side VPN connection.
I connect to the SQL database by specifying the ip_address of the server
side VPN connection.
If I use a different machine in the place of Machine A, I have a D-Link
wireless ethernet bridge connecting a 4 port hub to the wireless firewall
connection and have the same results.
Yet a 3rd machine at a different location is able to connect to the VPN
Server and maintain an active connection long enough to download a file,
however, if the application (Quickbooks) tries to work on the file over the
connection, it will drop the connection in the same manner as Machine A. In
this case the VPN client connects over Comcast Cable.
I've tried to simplify the entire configuration by just making the
connection and then pinging -t to the server side VPN IP_address and the
IP_address of the server side LAN IP_address.
I notice that the response time is generally in the 42ms range, however,
there is an occasional packet that has a reponse time of over 2000ms. These
happen about once every 10 seconds. About once every 30 seconds I get a
request timed out message, and about once every 3 minutes, the connection
just drops with a general failure message from ping.
Any ideas on how to proceed in debugging this drop issue? Verizon won't help
at all claiming that they don't support VPN unless you buya static IP and a
business account. I tried to point out that VPN is just a protocol running
over TCP/IP and that if they support TCP/IP and WindowsXP, then this is a
problem that they need to look at.
Is it possible that Verizon breaks the conection when they detect VPN
protocols on home accounts?
> Any ideas on how to proceed in debugging this drop issue? Verizon won't help
> at all claiming that they don't support VPN unless you buya static IP and a
> business account. I tried to point out that VPN is just a protocol running
> over TCP/IP and that if they support TCP/IP and WindowsXP, then this is a
> problem that they need to look at.
> Is it possible that Verizon breaks the conection when they detect VPN
> protocols on home accounts?
1 of 2 problems I can think of. MTU detection problem or packet loss.
1. The MTU autodetection on one of your routers is not working properly.
Try doing a ping test on both independently to one of the first few
routers along your path (use tracert to determine)
Try increasing the packet size of your ping packets and see if it gets
worse (it wont' get better), Start at 1000 bytes to verify it works,
Then try 1500 bytes which will fail, make sure you specify the do not
fragment flag. Move down by 50 bytes until it works and then try to
zero in on the exact packet size that your connection will tolerate. In
your router manually set the MTU size to the value you determined and
try your VPN tests again. If it works you can try increasing this value
on the router by 20 and do another VPN test, this should be the optimum
value because the 20 bytes would be overhead caused by the TCP header.
2. You are experiencing packet loss on one or both of your connections.
Using ping again do tests to your ISP's routers and try to determine if
there is any packet loss on your connection. Using larger packets will
help get more accurate results. In the MTU problem you will always get
a packet failure with the do not fragment flag set when you encounter a
network limit. With packet loss you will only get occasional failures
of some packets. Make sure you do this test with no other sources of
traffic running on the connection or they will invalidate your results.
Connect a PC directly to the modem for this test before calling the
ISP. You can start your testing with the router in place but once you
have determined that packet loss is present you must eliminate all of
your equipment that you can before the ISP will help you.
If you want to go to the last possible solution for fixing packet loss
on your end you would need to hookup your modem directly to the test
jack of your phone panel (if you have one) and completely disconnect all
the internal wiring and doing a test from there. This will eliminate
internal sources of electrical interference on your lines from being the
source of the problem. Also try different enthernet patch cords and
phone cords to the modem.
If you prove packet loss is present then call Verizon and report that
you have packet loss on your connection. This is something they are
responsible for fixing, you can tell them you are trying to use VPN if
you like but there is no reason for them to deny you support if you have
identified the cause to be on their network. I personally wouldn't even
mention it, a connection with packet loss is broken no matter what
application you are using it for.
WARNING! Email address has been altered for spam resistance.
Please remove the -deletethispart-. section before replying directly.
Mike Drechsler (mike-newsgroup@-deletethispart-.upcraft.com)