Re: GlobalProtect connection loss

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

 



My first attempt at sending the below mail seems to have been held up in
moderation, because the attachment is slightly too large. While I wait
for it to be noticed and released (or bounced, so that I can try again,
with a compressed version if necessary), I want to at least make it
visible that I haven't dropped this.

On 2020-04-14 at 07:41, The Wanderer wrote:

> On 2020-04-13 at 22:21, Daniel Lenski wrote:
> 
>> On Mon, Apr 13, 2020 at 6:33 PM The Wanderer
>> <wanderer@xxxxxxxxxxx> wrote:
>> 
>>> Would a repeating ping over the VPN tunnel (one every 30
>>> seconds, more a keepalive than anything else) be enough to
>>> qualify as traffic for this purpose, or would I need to keep
>>> something else (e.g. the RDP session) going?
>> 
>> I don't really know what is used to detect an idle connection. Ping
>>  may or may not be enough. ¯\_(ツ)_/¯
> 
> It seems to have worked in this case. The session died at about
> twenty minutes past midnight; the final timestamp in the file is
> three hours, 24 seconds after the first one. The resulting file was a
> round 999K, and just over a million lines.

Correction: just over 151k lines. The "million" was the character count;
I misread the output of wc.

I've continued to collect these, over the course of the following work
days. Thus far it appears that the sessions produce logs of about 220MB
apiece.

> It actually looks like the rekey went through successfully, but 
> something odd happened afterwards. I suspect that the key
> information here is going to be in the last dozen or so lines.
> 
> There's what looks like the beginning of a client-initiated logout 
> attempt (although I certainly did not initiate any such logout; I
> was asleep at the time), followed by a received result which
> includes "Invalid user name", and then EOF - which I interpret to be
> the program exiting.
> 
> The credentials reported in that received result (which,
> appropriately, don't include a password) appear to match those used
> to authenticate before. My past experience indicates that when this
> type of disconnection happens, reconnecting immediately (as in,
> within seconds) with the exact same credentials works fine.
> 
> In hindsight I realize there was one thing I could have done
> differently on this session invocation to be more sure I didn't miss
> any stderr, etc., messages - but I didn't do it, so I'm not entirely
> positive there's nothing missing. I hope all the important stuff is
> there.
> 
>>> I hope it's OK if I process the resulting file to strip out 
>>> identifying information - organization names, not IP addresses
>>> et cetera; I'm not entirely sure what is and isn't OK to let
>>> out, here, but I know we're told not to share the GlobalProtect
>>> portal address and I can see that in the logs already.
>> 
>> Yep, you should see plenty of examples of how to obfuscate such 
>> things in the list archives. If you're unsure, you can send the
>> logs to "just one random guy on the Internet" (me) instead of "a
>> whole bunch of us."
> 
> I've looked at the recent archives, but I've only found one log 
> presented at all and it wasn't at all clear what about it had been 
> changed for obfuscatory purposes.
> 
> Rather than dig through an unknown amount of archives looking for
> enough examples to be able to determine what's good practice, I've
> just gone through (a copy of) the log and replaced not just the
> obvious things (recognizable names, passwords, the external IP
> address of the VPN portal) but anything that looked like it even
> might be a unique ID, down to in one case something that was reported
> as being an MD5 hash; the only apparent hex strings I left unchanged
> were the "ETag:" entries in what look like the HTTP traffic.
> 
> This is probably far more anonymization than is really necessary, not
> to mention far more manual effort, but I'm reasonably confident that
> it's sufficient.

I'd normally snip a lot (if not all) of that, but in this instance I'm
leaving it in case the previous send attempt doesn't end up going through.

-- 
   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