[NCLUG] VPN problems

Bob Proulx bob at proulx.com
Tue Nov 6 17:47:14 MST 2007


Matt Rosing wrote:
> I need help getting my wife's VPN connection to work. She connects
> to HP's vpn from our house

Is this the Nortel Extranet Client?  Or something else?

For the group listening, it uses IPSEC.  IPSEC uses ESP which is IP
protocol 50 with a key exchange on UDP port 500.  IP protocol 50 is
neither TCP nor UDP.  It is IP protocol 50.  TCP is IP protocol 6.
UDP is IP protocol 17.  :-)

> and it seems to drop her after a few minutes.

The fact that you can connect says that the basic connectivity is
okay.  But dropouts after a period of time might mean several
different things.  It might mean UDP port 500 virtual circuit problems
through a NAT.  For example if there were two VPNs trying to key
exchange in near time, such as from two employees trying to connect
with two different laptops to the same company VPN.  The NAT tables
get confused and the packets don't route to the right machines but
instead to the last one to originate an outgoing packet.  Workaround
this by using different company server IPs.

Or it may be other things.  A painful situation no matter what the
root cause of the problem.

> On her old computer this would only happen if she was connected to
> our home network via an ethernet cable, wifi was fine.

You see, observations such as that lend weight to catagorizing this
software as "flakey" because a wired network should almost certainly
be more reliable than a radio wireless network!  But I believe your
observation concerning this client.  My own experience with it was
that it was flakey.

> She has a new computer and now the wifi is a problem. I'm not sure
> if it's my firewall (but we could get it to work before) or just a
> bad connection. What kinds of things could cause a VPN to drop every
> 5 to 10 minutes?

Personal experience indicates that this particular vpn software seems
to have very short keepalive/makedead intervals and seems intolerant
of any unreliability in the network.  That is to say that if there is
any glitch that causes a packet to be dropped along the way that its
idea of retries and timouts appears to be very short.  A 20 second
cable unplug and then plug back in would certainly cause the vpn to
drop in my experience with it.

A subjective and without-data observation is that it has always seemed
flakey, quick to anger, and will drop out at the most inconvenient
times.  By comparision most tcp connections would otherwise typically
continue over a two minute span without fatal error.  Using SSH at the
same time I would almost never notice a problem because SSH uses TCP
and longer timeouts and more retries.

Therefore I suspect that you are seeing mid-stream connection glitches
that are very short in time but long enough to cause the vpn to
timeout and drop.  I would ping between you and the server IP to check
the connection latency.  A nice steady sub-second value is good.  But
if you see radical variations with some ping packets taking many
seconds then that would be bad.

I would try turning the KeepAlives option off.  That is about the only
thing that I can suggest.

As far as firewalls are concerned it has been known to work very well
behind most commercial blue-box types of firewall/cable-modems and
also work quite well behind Linux kernel based firewalls without any
special configuration.  That is assuming that the firewall is in a
typical default-type of configuration.  I would be concerned if NAT
timeouts for UDP traffic were being heavily customized or things like
that since the key exchange has historically be a very problematic
part of IPSEC.  It is still a problem and prevents multiple remote
clients to the same server through the same NAT for example.  But if
you have not customized things there then you are probably okay there.

Bob



More information about the NCLUG mailing list