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
