AW: Questions about OpenConnect with Pulse and a bug

[Schütz Dominik]

> 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.

When I block port 4500 and 500 for ESP on my client
# iptables -A OUTPUT -p udp --dport 4500 -j DROP
# iptables -A OUTPUT -p udp --dport 500 -j DROP
no VPN connection can be established with "protocol=pulse". I get an internal IP address, but I can't ping an internal server (by IP address).

Output from OpenConnect:
Configured as xxx.xxx.xxx.xxx, with SSL connected and ESP in progress
Session authentication will expire at Fri May  6 22:46:59 2022

The "protocol=nc" then works without problems. So the "pulse" protocol doesn't actually fall back to SSL? Only if I give it explicitly (--no-dtls) -> see output below (SSL connected and ESP disabled)?


> 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).

I'll look into this again the next time I have the problem of him not being able to establish an ESP session.

If I pass "--no-dtls", then the "protocol=pulse" really does change to SSL (SSL is half as slow on our system compared to ESP). But I get the following messages:
Configured as xxx.xxx.xxx.xxx, with SSL connected and ESP disabled
Session authentication will expire at Fri May 6 21:07:40 2022

Unknown Pulse packet
Unknown Pulse packet
Unknown Pulse packet
Unknown Pulse packet
Unknown Pulse packet
...

Where are the reports (unkown pulse packet) coming from?

Regards,
Dominik
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6003 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/openconnect-devel/attachments/20220506/808fed23/attachment-0001.p7s>