Re: GlobalProtect connection loss

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

 



On 2020-04-18 at 21:29, The Wanderer wrote:

> The relevant messages from the terminal from one such session, starting
> from that point and continuing until exit, are:
> 
>>> [2020-04-15 14:25:56] ESP detected dead peer
>>> [2020-04-15 14:26:01] Failed to connect ESP tunnel; using HTTPS instead.
>>> [2020-04-15 14:26:01] Got inappropriate HTTP GET-tunnel response: HTTP/1.1 502 Bad Gateway
>>> [2020-04-15 14:26:01] Invalid user name
>>> [2020-04-15 14:26:01] Logout failed.
>>> RTNETLINK answers: No such process
>>> RTNETLINK answers: No such process
>>> [2020-04-15 14:26:01] Unknown error; exiting.

<snip>

> What I'm doing here is invoking a shell script (as ordinary user) from
> the command line, which runs
> 
> su - -c "~/bin/vpn-bar 2>&1 >>
> /home/ORIGINALUSER/tmp/vpn-bar-highverbosity.log"
> 
> and that command line in turn calls a shell script which sits under
> /root/bin/, gets run as root, and contains the actual invocation of
> openconnect - including
>   echo password | openconnect --passwd-on-stdin [other-options]
> and a custom routing script which adjusts the routing table so that only
> traffic which *needs* the VPN goes over it (that latter being why I need
> to run this as root, rather than pre-creating a tun* device node and
> telling openconnect to use it).

A thought has just occurred to me, which I don't *think* lines up with
the timing of events, but which I cannot immediately rule out.

I know that it is not possible to reach this VPN-portal address from
inside the network to which the VPN tunnel connects me. Is it possible
that what I'm doing with adjusting the routing table (which *should*
just be adding two routes so that the two ranges internal to that
network pass through tun0, and resetting the default gateway so that
traffic for all other ranges - including the VPN-portal address - goes
through eth0) may be leading some traffic which needs to go to this
address from outside attempting to go to it over the tunnel, and thus
somehow messing up this attempt to switch from ESP to HTTPS?

I *think* I remember having successfully used this routing-table
adjustment without this problem prior to the upgrade, and I certainly
remember having used it with what *looked* like success, but I cannot
testify to that with certainty.

It's faintly possible that one of those "internal" IP-address ranges may
actually be used by something external (Google lookup on the .0 address
at the bottom of that range shows that it appears to be allocated to
someone in North Carolina, where I am not), but if so I've never noticed
that causing access problems for anything in practice.

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