Unexpected and inconsistent login failures

[RobertLHarris]

Ok, My friend and I are both running OpenConnect to the same server. Only system differenes are He is running ubuntu, I'm running Kali, both on the latest with the latest openconnect build. Same environment files even.

I am executing this:
/usr/bin/cat /root/vpn.credentials.robert | /usr/bin/sudo /usr/local/sbin/openconnect --passwd-on-stdin --protocol=gp --pid-file=/tmp/openconnect.pid -u [email protected] gp.rdlg.net

Mine, which works, the Long/Verbose output is at: https://paste.debian.net/1060786/

He is doing the exact same thing except using his name for the User and credential file.

His output is at https://paste.debian.net/1060787/

Now, oddly enough if he includes "--usergroup=portal" in his, he works fine.

[RobertLHarris]

Misunderstanding, with the --usergroup, he still doesn't work

[dlenski]

Read your friend's log closely. From the end of it…

Enter login credentials
POST https://gp.rdlg.net/ssl-vpn/login.esp
Got HTTP response: HTTP/1.1 512 Custom error
…
Unexpected 512 result from server
Enter login credentials
Username: Password:
fgets (stdin): Inappropriate ioctl for device

The first login attempt failed, so openconnect is trying to prompt you to re-enter the password… which it can't do because standard input is piped in from a file.

Wrong password? 🙄

[RobertLHarris]

Just had him re-do seems we had some confusion.

Verified his password. Enabled "--usergroup=portal" and he's broken ( Mine works ) :
https://paste.debian.net/1060788/

Re-running it without the usergroup he's good ( I'm broken ):
https://paste.debian.net/1060789/

Here's the 'long' failed output:
https://paste.debian.net/1060790/

[dlenski]

The results you're showing really don't make any sense. ¯\_(ツ)_/¯

What happens if you just do openconnect --prot=gp vpn.company.com/portal and go through the login forms manually, retrying if you get a 512 bad username or password error? Does it work?

[RobertLHarris]

Yeah, I haven't found a reason either. He just left for lunch with his fiance, I can do some more debugging today.
( happy to contribute actually, I'm a fan, this keeps me from having to run windows on my laptop )

[dlenski]

It's possible that this is related to #86 or #116 (comment). GlobalProtect is known to give insane misleading errors (including "incorrect username or password") when it doesn't recognize your operating system.

Does spoofing Windows (--os=win) make any difference?

[RobertLHarris]

I don't think so, I can have him try. He did try "--os=linux", what will that break vs os=linux?

[dlenski]

Some GlobalProtect VPNs fail with misleading error messages with --os=win, and some others fail confusingly with --os=linux. Most don't seem to care what OS you specify.

I have no idea why they're broken in this way. You'll have to try both.

Read the commit notes for e2f574a for more details.

[RobertLHarris]

With os=win, the behavior changed so he can use the same one I can but no change for me ( aka, it didn't break ).

I ran a bunch of combinations and tests. I'm trying to upload the output to paste.debian.org but it's too long. These are straight text file output from starting the scripts 8 different ways, all with -v * 3. I 'labeled' the run with a line starting with ^Options:

VPN_Tests-linux.out.gz
VPN_Tests-win.out.gz

Robert

[dlenski]

With os=win, the behavior changed so he can use the same one I can but no change for me

In other words, --os=win works consistently, for all users?

If that's the case then… just do that and call this done. As I wrote in e2f574a, the misleading and inconsistent behavior of the GlobalProtect servers makes it more or less impossible to detect and workaround this issue automatically.