Re: GlobalProtect connection loss

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

 



On 2020-04-20 at 21:47, Daniel Lenski wrote:

> On Mon, Apr 20, 2020 at 6:10 PM The Wanderer <wanderer@xxxxxxxxxxx> wrote:
>
>> On 2020-04-20 at 14:04, The Wanderer wrote:

>>> It did not; it terminated after just over three hours, as before.
>>> I already sent a mail with the results of that, albeit without
>>> any commentary on the fact that it terminated after 3 hours
>>> (because that's the currently expected result when using 8.08, in
>>> my environment, so I didn't think it needed mentioning).
> 
> Sorry, I missed that you sent two nearly-identically-named logs. To be
> absolutely certain that I understand.
> 
> vpn-3hours-nodisconnect-fullmanualinvocation-headtail-obfuscated.log:
> this one was generated by OpenConnect v8.05
> vpn-3hours-disconnect-fullmanualinvocation-headtail-obfuscated.log:
> this one was generated by OpenConnect v8.08

That should be correct, yes.

> Assuming I've got that right, additional things to double check:
> 
> 1) The command lines to OpenConnect were 100% precisely identical in
> both cases?

Except for the output log filename, yes. I have just looked at the shell
history to be certain.

> 2) I see errors about “Cannot find device "tun0"” in both logs. Not 
> sure why that is happening.

This is another side effect of the kludgy routing script, which I
haven't yet replaced (I'm probably going to get to that Friday, which is
my next day without a work shift). I know why it's happening, and I
don't expect it to be related. I can describe in detail if preferred,
but I think this is a dead-end trail.

> 3) Was the ONLY TRAFFIC to the VPN, in both cases, the keepalive 
> daemon you're running?

As far as I'm aware, yes.

Well - I believe I did run a DNS lookup to an internal-network server
name by FQDN, which would have had to go across the VPN to the internal
DNS server to get resolved; that was to test the connection, at the
start and (for the no-disconnection 8.05 case) at the end. That would be
the only exception, though.

> If that's the case… I see no potentially-meaningful differences
> between the two logs.
> 
> Actually, I see *one*, which does arise from a change between v8.05 and v8.08:
> 
> 1) You haven't specified a HIP report script with --csd-wrapper. That
> seems to be fine, because your VPN isn't *asking* for a HIP report
> submission.
> 2) One of the main changes between v8.05 and v8.08 is that we
> introduced intermittent/periodic HIP checking.
> 3) As a side effect of these changes, if you don't specify a HIP
> report script, OpenConnect no longer even *asks* the server if we
> should submit a HIP report on rekey/reconnection… it only does this
> once.
> 4) As a result, in your v8.08 log, we don't ping
> /ssl-vpn/hipreportcheck.esp when we rekey… but we do in the v8.05 log.
> 
> I haven't actually seen any server where this makes any difference at
> all, but it's *possible* that your server doesn't like us going three
> hours without asking for a /ssl-vpn/hipreportcheck.esp… even though
> the answer is going to be “no submission needed.”
> 
> Can you try one of the following?
> 
> 1) Easy: run v8.08 with `--csd-wrapper
> openconnect_src_directory/trojans/hipreport.sh`. The HIP report won't
> actually get submitted because the server isn't asking for one, but
> v8.08 will at least ping /ssl-vpn/hipreportcheck.esp at the
> server-requested interval (1 hour).

I don't have an OpenConnect source directory locally, but I do have
hipreport.sh installed as part of the Debian package. I'll try with
that, overnight, and let you know the result in the morning.

(I'm using '--csd-wrapper=/path/to/hipreport.sh', rather than the
version with a space instead of the = sign, because that's what I did
reflexively and the man page seems to back me up that it's accepted
syntax. If it's incorrect syntax in a way that means "gets silently
ignored", I'll have to run this again in the morning.)

> 2) Slightly harder: Apply the attached patch to v8.08, recompiling,
> and retest. With this modification, OpenConnect will still do the
> /ssl-vpn/hipreportcheck.esp at the interval requested by the server (1
> hour in your case), even when no --csd-wrapper is specified.

I can test with this later if needed / desired, e.g. for verification if
the above test shows success; it's an extra step that I don't want to
deal with at this hour tonight.

> If either of these makes a difference, then—hooray!—we've figured out
> a very subtle, strange, but apparently significant behavior of your
> server. If not, I am well and truly stumped.

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.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man.         -- George Bernard Shaw

Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
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