Questions about OpenConnect with Pulse and a bug

[David Woodhouse]

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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5965 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/openconnect-devel/attachments/20220505/d17bd6e5/attachment.p7s>