Demonstration: https://youtu.be/sDLS-jPG2S4

Мда. A phonecam video bugreport, now I think I've seen it all.

bz1960763 might be relevant. The summary is roughly:
1) crypto-policies routinely disallows old and insecure protocols to be used, system-wide,
   which is totally intended and is, actually, the primary purpose of its existence
2) openconnect uses gnutls, which is controlled by crypto-policies
3) openconnect folks really like their old protocols and are enabling them back
   despite whatever crypto-policies considers secure or not
4) gnutls algorithm selection mechanism in Fedora has been switched
   to a finer-grained, hard-blocking one quite a while ago
   (which, IMO, wasn't a good idea overall for more than just this reason.
    an allowlisting mechanism free of this limitation is in the works)
5) openconnect folks didn't like that, like, at all, and the last time, I think,
   decided to completely opt out of crypto-policies until it becomes soft-blocking.
   their choice, I can just hope they'll exercise it wisely
   and make users opt-in into unsafe algorithms then


The gnutls-related diff of DEFAULT between the versions is:

--- 1.config    2021-08-04 10:03:24.951000000 +0000
+++ 2.config    2021-08-04 10:04:17.682000000 +0000
@@ -38,10 +38,11 @@
 tls-disabled-cipher = GOST28147-TC26Z-CNT
 tls-disabled-kx = DHE-DSS
 tls-disabled-kx = VKO-GOST-12
-disabled-version = SSL3.0
-disabled-version = TLS1.0
 disabled-version = TLS1.1
+disabled-version = TLS1.0
+disabled-version = SSL3.0
 disabled-version = DTLS1.0
+disabled-version = DTLS0.9
 min-verification-profile = medium

 [priorities]

I'd speculate that your setup used DTLS0.9, a patently terrible idea in 2021,
and the version of openconnect you have in your system doesn't opt out of this totally sensible restriction yet.
Some openconnect logs could've confirmed or refuted that.


One possible workaround to consider among the others is writing a subpolicy with `protocol@gnutls = DTLS0.9+`.
Though openconnect-side workarounds should be narrower in scope, and thus preferred.

connection log with crypto-policies-20210213-1.git5c710c0.fc35:
Aug 05 18:31:50 10-176-129-236.dev-vpn.corp.tensor.ru openconnect[194503]: Connected to 91.213.144.15:501
Aug 05 18:31:50 10-176-129-236.dev-vpn.corp.tensor.ru openconnect[194503]: SSL negotiation with 91.213.144.15
Aug 05 18:31:50 10-176-129-236.dev-vpn.corp.tensor.ru openconnect[194503]: Server certificate verify failed: signer not found
Aug 05 18:31:50 10-176-129-236.dev-vpn.corp.tensor.ru openconnect[194503]: Connected to HTTPS on 91.213.144.15 with ciphersuite (TLS1.2)-(ECDHE-SECP256R1)-(RSA-SHA512)-(AES-256-GCM)
Aug 05 18:31:50 10-176-129-236.dev-vpn.corp.tensor.ru openconnect[194503]: Got CONNECT response: HTTP/1.1 200 OK
Aug 05 18:31:50 10-176-129-236.dev-vpn.corp.tensor.ru openconnect[194503]: CSTP connected. DPD 30, Keepalive 20
Aug 05 18:31:50 10-176-129-236.dev-vpn.corp.tensor.ru openconnect[194503]: Connected as 10.176.130.95, using SSL, with DTLS in progress
Aug 05 18:31:51 10-176-129-236.dev-vpn.corp.tensor.ru openconnect[194503]: Established DTLS connection (using GnuTLS). Ciphersuite (DTLS0.9)-(RSA)-(AES-128-CBC)-(SHA1).
Aug 05 18:31:52 10-176-129-236.dev-vpn.corp.tensor.ru openconnect[194503]: SIOCSIFMTU: Operation not permitted

connection log with crypto-policies-20210615-1.giteed6c85.fc35:
Aug 05 18:39:37 10-176-130-95.dev-vpn.corp.tensor.ru openconnect[197385]: Connected to 91.213.144.15:501
Aug 05 18:39:37 10-176-130-95.dev-vpn.corp.tensor.ru openconnect[197385]: SSL negotiation with 91.213.144.15
Aug 05 18:39:37 10-176-130-95.dev-vpn.corp.tensor.ru openconnect[197385]: Server certificate verify failed: signer not found
Aug 05 18:39:37 10-176-130-95.dev-vpn.corp.tensor.ru openconnect[197385]: Connected to HTTPS on 91.213.144.15 with ciphersuite (TLS1.2)-(ECDHE-SECP256R1)-(RSA-SHA512)-(AES-256-GCM)
Aug 05 18:39:37 10-176-130-95.dev-vpn.corp.tensor.ru openconnect[197385]: Got CONNECT response: HTTP/1.1 200 OK
Aug 05 18:39:37 10-176-130-95.dev-vpn.corp.tensor.ru openconnect[197385]: CSTP connected. DPD 30, Keepalive 20
Aug 05 18:39:37 10-176-130-95.dev-vpn.corp.tensor.ru openconnect[197385]: Failed to set DTLS priority: 'NONE:+VERS-DTLS0.9:+COMP-NULL:+AES-128-CBC:+SHA1:+RSA:%COMPAT': No or insufficient priorities were set.
Aug 05 18:39:37 10-176-130-95.dev-vpn.corp.tensor.ru openconnect[197385]: Connected as 10.176.132.111, using SSL, with DTLS disabled
Aug 05 18:39:37 10-176-130-95.dev-vpn.corp.tensor.ru openconnect[197385]: SIOCSIFMTU: Operation not permitted

So you are right indeed.
Commenting line `disabled-version = DTLS0.9` in `/usr/share/crypto-policies/back-ends/DEFAULT/gnutls.config` solved the issue.
I am not an expert on the capabilities of hardware routers Cisco 5585-X and I am not a router-side administrator but looks like they probably have nothing else to offer.

Glad to hear my title-based guess turned out to be the correct one.
For your future reports, please consider
sticking to the standard template offered in the description field
and providing logs upfront;
that makes tickets much more readily actionable,
not to mention indexable, self-contained and Ъ-friendly.

Please be aware that commenting out this line directly
isn't guaranteed to persist across package updates.

For the Fedora 35 timespan, I'm afraid workarounds like
GNUTLS_SYSTEM_PRIORITY_FILE=/dev/null on openconnect or a custom subpolicy
are the only available solutions I envision.
For subsequent releases, I hope soft-disabling will solve it.

*** This bug has been marked as a duplicate of bug 1960763 ***

Related: crypto-policies-20210819-1.gitd0fdcfb.fc35 / crypto-policies-20210819-1.gitd0fdcfb.fc36 revert DTLS 0.9 hard-disablement introduced earlier in F35.