VPN and netbios problems - more info

[Donkin, Richard]

> > >   I suspect that the fact that the link between the two subnets is
> > > a VPN is irrelevant (correct me if I'm wrong) and that we need to
> > > get hold of another mailing list.
> >
> > It *should* be irrelevant.
>
>   It should be, but unfortunately that may not mean that it is.
>
>   What I seem to be seeing, on both our point-to-point and dial-up VPN
> links, is that a momentary packet loss at the IP transport
> level seems to
> translate into a loss of IPSEC tunnel connectivity of 3-30 seconds.  A
> congested router with a 5% reported packet loss may lead to a
> tunnel that is
> only able to pass pings half the time.
>   It gets worse.  Large transmissions -- specific reported
> examples include
> "email messages with attachments" and "segment browse lists"
> (relevance to
> this thread!) seem to *provoke* packet loss at such congestion points,
> producing classic abort/restart/abort/restart/abort/restart/abort/fail
> cycles; the message simply never gets through the tunnel.

Very strange - can you put a protocol analyser, or tcpdump equivalent, onto
the points where you are having packet loss, so you can see exactly what
sort of packets are being lost?

If you find that large packets never get through at all, you may have an MTU
problem - Path MTU Discovery frequently doesn't work through tunnelling
mechanisms, e.g. with IPSec tunnels, so it may be necessary to play with the
MTUs manually on both hosts.  However, MTU problems would be consistent i.e.
all packets above a certain length would fail, whereas yours seem to be
intermittent.

The long delay in restarting almost sounds like you are going through IKE
again - perhaps you have a very short rekeying interval or there is some
interoperability problem at the IKE level that forces keys to be
renegotiated?  Just an idea...

>
>   The two alternatives we've identified so far are:
>
> 1.  Move to a single national/international ISP to minimize
> transition of
> overloaded carrier-to-carrier gateways.
>
> 2.  Move to Frame Relay, ATM, leased lines, or other ~private
> services to
> avoid the Internet.
>
>   Neither of these answers is wholly satisfactory, especially for our
> dial-up user community.  Other suggestions, anyone?

I think you need to spend more time diagnosing the problem to see why the
IPSec gateways are reacting so badly to packet loss.

Richard

VPN is sponsored by SecurityFocus.COM