[NCLUG] VPN problems

DJ Eshelman djsbignews at gmail.com
Wed Nov 7 10:54:56 MST 2007


well, assuming you're not on Vista with this new PC...

I have had a lot of problems with Cisco based VPNs, mostly related (as
mentioned above) to the fact that the default UDP doesn't always work well.

If you can, and it's Cisco- force it to use TCP port 10000  Most Cisco
concentrators respond on both UDP and TCP ports.
You may still need to open up UDP ports 62515 and 4500

If it's a custom ipsec or lptp connection, your problem may be in key
lifetime timouts - I've had that problem once or twice with connecting over
satellite broadband; the latency times made it nearly impossible to keep it
alive; a bad wireless connection would behave much in the same manner.

On 11/6/07, Bob Proulx <bob at proulx.com> wrote:
>
> 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
> _______________________________________________
> NCLUG mailing list       NCLUG at nclug.org
>
> To unsubscribe, subscribe, or modify
> your settings, go to:
> http://www.nclug.org/mailman/listinfo/nclug
>



More information about the NCLUG mailing list