No subject

Daniel Lenski dlenski at gmail.com
Fri Apr 26 15:56:00 PDT 2024


On Sat, Apr 20, 2024 at 12:35 PM Peter Tulpen <ptulpen at emailn.de> wrote:
> Hello,we want to use openconnect to connect to our company network and having like 2 modes:
> - always have a connection to our management server based on a client certificate, so the management server can scan him: basic connection
> - when a user needs resources, let him login via 2FA : user connection
>
> This could be done with 2 tunnels, but is there a more elegant way, like always having the basic connection switch to the "user connection" on demand (and falling back to the basic connection when the "user connection" is gone)

What exactly is wrong with 2 tunnels? This would almost certainly be
the most reliable, straightforward, and composable way to implement
what you want.

Without explicit support for this "mode-switching" IN THE VPN SERVER,
the graceful transition and fallback between the 2 tunnels would
likely be VERY difficult to implement.

Within the OpenConnect client, we have enough trouble ensuring
graceful fallback between TLS- and ESP/DTLS-based tunnels of a single
ALREADY-AUTHENTICATED logical client session. We regularly discover
new quirks and inconsistencies within the supported VPN protocols that
make this a challenge.

On Mon, Apr 22, 2024 at 6:31 AM Peter Tulpen <ptulpen at emailn.de> wrote:
> the server is a  palo alto prisma

I wrote [almost all of] the support for the Palo Alto / GlobalProtect
protocol in the OpenConnect *client*
(https://www.infradead.org/openconnect/globalprotect.html). However, I
know ABSOLUTELY NOTHING about how GlobalProtect *servers* work, or how
they're configured… other than what I can infer from the numerous
bugs, security holes, and inconsistencies that I've encountered over
the years. 😬

> To avoid the issue of having a connection in a connection I hope split tunneling and clever routing rules should be sufficient

Yes, I think you're on the right track here. Setup 2 separate tunnels,
and ensure that the routes they require don't overlap or interfere
with each other.


Daniel



More information about the openconnect-devel mailing list