On Fri, 2020-05-01 at 18:39 +0100, Dave Love wrote: > David Woodhouse <dwmw2@xxxxxxxxxxxxx> writes: > > > The three secrets it's looking for there are the *result* of > > authentication. Whatever you have to do with certificates, passwords, > > SAML and 2FA aren't relevant; it just wants three things: > > > > • The host you ended up authenticating to (after redirects, etc.). > > • Hash of *its* SSL certificate. > > • The 'cookie' that was the result of successful authentication. > > Thanks, rather late, for this. Should that have been obvious from the > doc somewhere I didn't find? I don't think so. I try to be quite good at documenting OpenConnect itself, but documentation on the NetworkManager-openconnect interaction has been somewhat lacking. Users *mostly* shouldn't have to care about that. > > Those are the things you get if you run 'openconnect --authenticate'. > > > > Here's a script which will provide them to NetworkManager for you: > > I adapted that, using "--protocol gp -q --usergroup=gateway" in the > authN step and extracting the gateway from the named VPN config. It > brings up the VPN, so I'm happy, but somewhat uncleanly. First, the > authentication command produces > > GlobalProtect login returned unexpected argument value arg[19]=4 > Please report 1 unexpected values above (of which 0 fatal) to <openconnect-devel@xxxxxxxxxxxxxxxxxxx> I think Dan's seen a few of those, and is on the verge of making not print that message for that particular argument. > Then nmcli produces > > Connected to HTTPS on *** > Got HTTP response: HTTP/1.1 502 Bad Gateway > Unexpected 502 result from server > Failed to obtain WebVPN cookie > Error: openconnect failed with status 1 > Connection successfully activated (D-Bus active path: /org/freedesktop/NetworkManager/ActiveConnection/18) > > Obviously I can take suggestions to investigate if it's useful. Hm, it does that and then connects successfully? That's interesting; probably worth filing a bug with NetworkManager. It shouldn't be doing that if it was *given* the secrets it needs. > > The COPR has been unreliable recently. Broken versions of http-parser, > > ocserv, wine in Fedora updates have been a pain, and recently a lot of > > builds seem to die when running out of disk space. > > OK. I think I concluded that ocserv just wouldn't run in copr for some > reason -- as opposed to koji and maybe plain mock. > > > But there is a build of 8.09 for both el6 and el7. > > https://copr-be.cloud.fedoraproject.org/results/dwmw2/openconnect/epel-6-x86_64/01356430-openconnect/ > > https://copr-be.cloud.fedoraproject.org/results/dwmw2/openconnect/epel-7-x86_64/01356430-openconnect/ > > Apologies. I don't know how I missed them, apart from the builds in > copr being confusing. Is there a good reason not just to update the > EPEL7 package (rhbz #1765111)? No, I don't think there is a good reason. We should probably update the EPEL packages. > > > The rpms and dpkgs are built with the trojan in the same > > > place for ease of documentation rather than using the dwmw2 PPA, but > > > that make contravene Debian rules which I'm not up-to-date with. The > > > PPA also doesn't have a recent enough network-manager-openconnect.) > > > > Hm, is that just for EPEL or also for Fedora? Let's fix that in my COPR > > too. What's missing? > > If you mean fix the location, I think I just modified just the dpkg > trojan location to agree with the rpm's for ease of local documentation > as I was rebuilding, and that might be wrong for Debian, though I think > it was in an arch-specific directory as just a script. I don't think > anything needs changing in your copr as I see it's now gained an EPEL7 > NetworkManager-openconnect 1.2.6, and mine can be scrapped. Yeah, I pulled in your build fix for the 'without libnm-glib' thing and pushed it to the main Fedora repository so that the latest will also build on EPEL7. That isn't always the right thing to do, but where it's trivial enough, we might as well. Thanks.
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ openconnect-devel mailing list openconnect-devel@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/openconnect-devel
