Re: GlobalProtect connection loss

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Apr 21, 2020 at 5:11 AM The Wanderer <wanderer@xxxxxxxxxxx> wrote:
>
> On 2020-04-20 at 22:26, Daniel Lenski wrote:
>
> > On Mon, Apr 20, 2020 at 7:20 PM The Wanderer <wanderer@xxxxxxxxxxx>
> > wrote:
> >
> >> If no difference is made, then barring any further lightbulbs, I'll
> >> bite the bullet and bisect. I think this is a promising lead,
> >> though, and I do thank you for investigating this far.
> >
> > Sounds good. I am very cautiously optimistic that running with the
> > hipreport.sh script specified will fix it, and if that's the case
> > then I am very confident that the patch will make OpenConnect do the
> > Right Thing even when no HIP script is specified. And apparently the
> > Right Thing is to ask the server a question where we already know
> > the answer, over and over and over…
>
> I am pleased to report that when I woke up this morning, the tunnel was
> still up, and the ping was still running with no signs of a problem.
>
> I killed the ping, and was able to separately ping a different address
> which happens to be across the VPN.

Hooray!

> The log (about 1.3MB; I'm not planning to obfuscate it for sharing
> unless necessary) contains what looks like seven HIP-report check-ins,
> with three rekeys, and stretches from 22:17 last night to 7:55 this
> morning (EST).
>
> There *was* one snag; /etc/resolv.conf had reverted to my non-VPN form,
> so I couldn't do DNS lookups on any trans-VPN systems, I had to ping
> them by known IP address. However, I suspect that that's a side effect
> of my misunderstanding the requirements of what the routing-etcetera
> script needs to look like and do, and will be resolved when I get that
> replaced; unless it persists past that point, I don't think we need to
> investigate it here.

Yep, likely a problem with vpnc-script or NetworkManager. Has nothing
to do with the tunnel staying up.

> My guess as to why the server behaves this way is that just because the
> answer is "no HIP report needed" once, doesn't mean it will *always* be
> that, so it wants the client to keep checking in case the answer has
> changed. Since the official client and server come from the same people,
> I can very easily imagine the server being coded such that it assumes
> the client will always do this check (because the client in their
> control always does) and doesn't know what to do if that assumption is
> violated.

Yep, that's basically my conjecture as well. Thanks for helping
elucidate this very obscure and hard-to-test corner of the GP
protocol.

> Thanks very much again for tracking this down this far. I'll test the
> patched version once it's available (I may or may not build it myself,
> since cleaning it back out of the system once installed would be a pain
> unless the build-and-install method was a Debian package), and let you
> know about any further issues, but it looks like this did in fact solve
> the problem.

https://gitlab.com/openconnect/openconnect/-/merge_requests/95

We'll get this into a release; for the time being you have a
workaround at least.

Dan

_______________________________________________
openconnect-devel mailing list
openconnect-devel@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/openconnect-devel




[Index of Archives]     [Linux Samsung SoC]     [Linux Rockchip SoC]     [Linux Actions SoC]     [Linux for Synopsys ARC Processors]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]


  Powered by Linux