On Mon, Apr 20, 2020 at 12:08 PM <wynalgos@xxxxxxxxxxx> wrote: > > > > > I've used openconnect to connect to a PAN Global Protect VPN server, which worked fine. Recently this does not work anymore. > > > The server returns a 512 Custom Error: > > > > What changed “recently”? Did you change which version of OpenConnect > > you're using? Is it possible that anything changed on the server side? > > > Unfortunately I cannot tell you what changed. I guess it was on the server side. I used version 8.02 provided by Ubuntu but I also I build the latest version (master) myself. One thing that changed between v8.02 and v8.08/master is that we switched from connecting to the gateway interface (/ssl-vpn) by default, to connecting to the portal interface (/global-protect) by default, for greater compatibility with the official client software… even though the portal interface is mostly-but-not-entirely useless and obfuscatory. You didn't show the login URL in your original post (/ssl-vpn/login.esp, or /global-protect/getconfig.esp) so I have no idea if this is playing a role. > > > I compared the request sent by the Windows client and openconnect and they differ quite a bit. Is there a way to add more options to the request? > > > > There are a large number of fields which the Windows client sends, > > which I'm very confident are vestigial or useless based on testing > > across many, many GlobalProtect servers. > > > > If you want, you can modify the fields sent in the login.esp response > > here, if you want: > > https://gitlab.com/openconnect/openconnect/blob/HEAD/auth-globalprotect.c#L566-571 > > Is there no easier way to just provide the complete string of parameters via command line? If not I can just hack this in by myself. You should play around with https://github.com/dlenski/gp-saml-gui/blob/master/test-globalprotect-login.py. Run with --help to see all the options, including the ability to easily specify extra login query parameters. I created it for this specific purpose, while trying to figure out how GP SAML login works. > > If you find that adding additional fields is necessary to make the > > login works, we'll be extremely interested in that. > > I will do. Keep in mind that we're not just differing from the official clients “because we can.” If we learn of some other field that OpenConnect needs to include to make some VPNs login successfully… and which is easy to autogenerate with the correct value… we would just include it by default. All of the differences are due to either: 1) They're fields which aren't present in *any* version of the clients that we've MITM'ed (see https://github.com/dlenski/openconnect/blob/master/PAN_GlobalProtect_protocol_doc.md#login-request for all the ones I know about) 2) They're fields where it's unclear how to populate them in a way that's compatible with the official clients (e.g. how should we populate os-version="Microsoft Windows Server 2012, 64-bit" when running on Linux? how should we generate a "host-id"?) and where I've never seen a server that cares about their value. 3) They're fields which older official clients *didn't* send, but newer official clients *do* send, and where #2 also applies. This gives us a pretty high confidence that GP servers won't absolutely require these fields, because it they did they would break compatibility with older versions of their own clients. > > Based on past experience, the *most likely* cause for this that you > > need to pretend to your GlobalProtect server that you're running an > > officially-supported OS (try adding `--os=win` or `--os=mac-intel` or > > `--os=linux-64` to the OpenConnect command line) . > > I have already tried those without any success. I will try to send exactly the same information and see if this will work. Huh, interesting. test-globalprotect-login.py should help you test sending all the extra fields and seeing if it makes a difference. -Dan _______________________________________________ openconnect-devel mailing list openconnect-devel@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/openconnect-devel
