Tatsächlich führt die von user2000606 nicht gegebene Antwort zum Erfolg.
Die an den ASA gesendeten HTTP-Nachrichten unterscheiden sich, je nachdem, wie Sie eine Gruppe auswählen, und VPN-Gateways können diesbezüglich wählerisch sein.
Dies ist mein grundlegender Aufruf an openconnect
openconnect -v --printcookie --dump-http-traffic \
--passwd-on-stdin \
-u johnsmith \
vpn.ssl.mydomain.tld
Das Ausgeben dieses Befehls und das Bereitstellen der gewünschten VPN-Gruppe nach Aufforderung führt zu folgendem HTTP-Chat (ich habe nur die scheinbar relevanten Teile der XML-Dokumente eingeschlossen):
[Certificate error, I tell openconnect to continue]
Me >> ASA: POST / HTTP/1.1
[...]<group-access>https://vpn.ssl.mydomain.tld</group-access>
ASA << ME: HTTP/1.1 200 OK
Me >> ASA: POST / HTTP/1.1
[...]<group-access>https://vpn.ssl.mydomain.tld/</group-access><group-select>AnyConnect-MyGroup</group-select>
ASA << ME: HTTP/1.1 200 OK
Me >> ASA: POST / HTTP/1.1
[...]<auth><username>johnsmith</username><password>secret</password></auth><group-select>AnyConnect-MyGroup</group-select>
ASA << ME: HTTP/1.1 200 OK
Beachten Sie die group-select
-groups und dass alle Anforderungen sind POST / HTTP/1.1
. Das gleiche Ergebnis wird --authgroup AnyConnect-MyGroup
mit dem Basisaufruf an erzielt openconnect
.
Bei der Verwendung passiert -g AnyConnect-MyGroup
anstelle von --authgroup AnyConnect-MyGroup
:
Me >> ASA: POST /AnyConnect-MyGroup HTTP/1.1
[...]<group-access>https://vpn.ssl.mydomain.tld/AnyConnect-MyGroup</group-access>
ASA << ME: HTTP/1.1 200 OK
[...] <error id="91" param1="" param2="">Invalid host entry. Please re-enter.</error>
Beachten Sie, dass wir diesmal den Server nicht informieren, group-select
sondern einfach unseren Gruppennamen mit group-access
und die HTTP-Anfrage eingeben. Das gleiche negative Ergebnis wird hervorgerufen, wenn der Gruppenname zur Gateway-Adresse hinzugefügt wird, dh vpn.ssl.mydomain.tld/AnyConnect-MyGroup
als letzte Zeile des Basisaufrufs verwendet wird openconnect
.