--protocol=pulse fails fast; nc fails pretty fast

[RossBoylan]

Generally, I've been unable to get a connection that stays open for > 15 minutes for quite awhile. Thinking this might be cured by shifting to newer protocols, I used pulse instead of the default nc as my --protocol. Leading to the main topic of this report

protocol=pulse can't negotiate connection

I've tried a couple of times with --debug --verbose. Because of possible security issues, I'm reluctant to post the full transcript. But the key part comes after Duo authentication and connection via HTTPS

Got HTTP response: HTTP/1.1 101 Switching Protocols
Unexpected IF-T/TLS packet when expecting configuration.
DEBUG: Removing file: /root/.config/ucsf-vpn/tmp.OFTlycxlLG-ipinfo.json
DEBUG: OpenConnect standard error:                                                                                                   
DEBUG: Enter user credentials:                                                                                                       
Enter secondary credentials:                                                                                                         
Secondary password:                                                                                                                  
Invalid ESP setup                                                                                                                    
Insufficient configuration found                                                                                                     
Creating SSL connection failed                                                                                                       
DEBUG: PID file does not exists: /root/.config/ucsf-vpn/openconnect.pid                                                              
DEBUG: pid=-1 

At the end there are no tunnels or routing changes.

Environment

ucsf-vpn 5.5.1: the .1 is for local modifications to use the .netrc for my regular user and switch the default to
protocol=${UCSF_VPN_PROTOCOL:-pulse}
Debian GNU/Linux 11/stable/bullseye, amd64 architecture (with some i386 installed)
openconnect 8.10-2+b1
DSL connection
going through deco router
running from a shell session that already sudo'd to root.

This is a more vanilla setting than my previous reports, in which I overrode the default script* for network routing setup so that only traffic for UCSF went through the tunnel. Also unlike my previous reports there is no nameserver running on the machine, though it does have resolvconf installed. One consequence is that the list of nameservers that end up in /run/resolvconf/resolv.conf always includes one entry from before the tunnel went up.

The software is generally newer than in my previous reports; in particular, openconnect is now at 8.10.

*This is the --script argument to openconnect; it defaults to /usr/share/vpnc-scripts/vpnc-script on Debian.

History

My main disk died about 6 weeks ago, and the problems appeared, or at least intensified, after I got back up. As partly noted above, they key things that changed were

1. Debian 11 instead of Debian 10. Newer software, esp openconnect.
2. Most routing and name service provided by a Deco router, which in turn uses my ISP for DNS. Previously my machine connected directly to the ISP, ran a DNS domain, did firewalling, DHCP ....
3. ?Changes on the UCSF side.
4. Custom script to setup routes disabled.
5. Newer versions of ucsf-vpn. For most of the time I was using 5.4.

2 and 4 are simplifications; I will likely move back to my previous setup with time and/or recovery of the configuration files.

Theories

1. This may well be an openconnect bug I referenced in another report:
   The Changelog has some interesting items. For the post 8.10 code it has

Fix a subtle bug which has prevented ESP rekey and ESP-to-TLS fallback from working reliably with the Juniper/oNCP protocol since v8.04. (#322, !293).

2. Maybe Debian has blocked TLS 1.2, which the exchange uses, as insecure? But as far as I know, only 1.0 and 1.1 are insecure and blocked.
3. I keep suspecting the reference to my ISP's nameserver is screwing things up, since any ucsf domains that resolve through it will get the external IP's. It is easy to imagine that breaking the connection. However, the documentation says the nameservers are tried in order, and the one from my ISP is 3rd on the list. So it seems unlikely it would ever be used. And I have tried manually editing it out of resolv.conf, and it hasn't helped that I can tell.

Alternatives

Without modification the program uses protocol=nc. I am able to connect with that; I'm just not able to stay connected for long: often only a few minutes, and usually not more than 15. That's why I tried protocol=pulse.

[HenrikBengtsson]

Can I close this one?