On Thu, 2022-05-05 at 18:07 +0000, Schütz Dominik wrote: > > > We would like to use OpenConnect (currently 9.01-0+9.1) productively > as a VPN client (under Ubuntu 20.04 and 22.04) with Pulse as the > backend (currently 9.1R14), but we still have the following open > questions: > > 1. Is "--protocol=nc" used for Pulse SSL VPN and "--protocol=pulse" > used for Pulse ESP (IPsec) VPN? >
The former is the older Juniper 'Network Connect' protocol. It's limited to Legacy IP and HMAC-SHA1 (as far as we can tell). The latter is their next generation protocol which supports IPv6, SHA256, etc. It's a horrid mess of nested binary protocols (IF-T/TLS, EAP, EAP-TTLS, some of their own devising). I believe it was eventually spun off from Juniper as a separate company, and is now called 'Pulse Secure SSL VPN'... no wait, they've been acquired and the branding of the VPN has changed again, but I think it's the same thing. The Pulse appliances seamlessly still support the old protocol, and it's hard to even find a setting to disable that. Last time I knew, the "pulse" client for Linux was actually still using the older NC protocol; we had to watch traffic from a Windows client to work out the pulse protocol. > 2. Does the "--protocol=pulse" fallback to SSL if the VPN connection > with ESP doesn't work? Yes. It will attempt to establish the ESP 'connection' by exchanging probe packets, and send packets over ESP where it *can*, but fall back to sending over SSL. There's a catch here: the Pulse applicance can generally accept packets in an ESP tunnel which match the protocol that the ESP is sent *ovER*. So... if your connection from client to the VPN appliance over the public Internet is IPv6, then you can tunnel IPv6 within ESP and all Legacy IP has to go over TCP. Conversely if your connection over the public Internet to the VPN appliance is Legacy IP, then you can only tunnel Legacy IP over ESP and all IPv6 has to go over TCP. > 3. Why can't OpenConnect always establish a VPN connection with " > --protocol=pulse"? > "Configured as xxx.xxx.xxx.xxx, with SSL connected and ESP in > progress" is then displayed here, but sometimes "ESP session > established with server" does not appear and consequently "ping > domain" does not work, although the client has a company-internal IP > address. > Here you have to disconnect the VPN connection and re-establish it > again until "ESP session established with server" is there, then the > VPN works with "--protocol=pulse" without any problems. > With "--protocl=nc" I don't have these problems, this is more > reliable than "--protocol=pulse". Can it be a bug? Sounds like more than one bug. Firstly... why doesn't the ESP session manage to establish sometimes? Would be useful if you could capture the traffic on the public wire (at both ends, even better) to compare good and bad cases. With enough `-v` on the command line, openconnect will dump the ESP keys that you need to put into a tool like Wireshark to decrypt that traffic. Are the probes making it through? Are you afflicted by NAT? Is there something different between the successful and failing cases? Secondly... if ESP isn't established, we ought to be passing data over the TCP/TLS session. Don't go straight to testing DNS; make sure you're attempting to ping a remote box on the VPN (that allows ICMP echo) by *number*. And bear in mind that IPv6 and Legacy IP *might* behave differently. Does it make any difference if you use --no-dtls? (Which is misnamed now, and means --no-udp but we didn't actually make that user interface change yet). > Thanks.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ openconnect-devel mailing list openconnect-devel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/openconnect-devel
