On Sat, Apr 18, 2020 at 6:45 PM The Wanderer <wanderer@xxxxxxxxxxx> wrote: > 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? It seems plausible, but impossible to be sure. If the routing table gets mangled in a way such that new connections to the VPN portal actually go… over the VPN, you'll normally just get a connection that's hung/stuck, not one where messages appear to be getting through to the portal. The scripts you're describing seem fairly convoluted. I would recommend using vpn-slice (https://github.com/dlenski/vpn-slice). It's quite well-tested at this point, and it allows OpenConnect to call it as a standard vpnc-script to setup a split tunnel with access to named hosts or routes, without any further wrapper. I wrote it pretty much for this exact use case. _______________________________________________ openconnect-devel mailing list openconnect-devel@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/openconnect-devel
