feedback after latest improvements about pan-globalprotect-okta

[arthepsy]

@cardonator I commited Python3 fixes and new feature (to support newer openconnect version). Is everything working as expected now? P.S. Please check modified .conf.

[cardonator]

Thanks. I will take a look. For something like the csd wrapper, should I put that in the openconnect args?

[arthepsy]

Yes, that's correct.

[gunslingerfry]

Getting

Traceback (most recent call last):
  File "./gp-okta.py", line 964, in <module>
    sys.exit(main())
  File "./gp-okta.py", line 886, in main
    _, userauthcookie, gateways = paloalto_getconfig(conf, s, saml_username, prelogin_cookie)
  File "./gp-okta.py", line 745, in paloalto_getconfig
    conf.add_cert(cert)
  File "./gp-okta.py", line 228, in add_cert
    self.certs_fh.write(cert)
  File "/usr/lib/python3.8/tempfile.py", line 474, in func_wrapper
    return func(*args, **kwargs)

After an SMS or an interactive TOTP. I put my gateway in the same as before. gateway = gw.xyz.com

Also, I tried doing the initial TOTP secret for okta and it doesn't seem to work. I'm guessing it's the f=xxxxxxxxxxxxxxxxxxxx argument in the QR code.

Manjaro + Openconnect 8.05, python 3.8.2, no unbound

This worked with the previous version.

[cardonator]

What is the actual exception you got? It should be right after the traceback.

[arthepsy]

@gunslingerfry error doesn't seem to be related to config or anything You described. seems like a general issue. It fails when trying to write certificate to temporary file or file You specified in configuration. But, yes, I would need to see a full error message.

[gunslingerfry]

Whoops. Not sure how I missed that.
TypeError: a bytes-like object is required, not 'str'

[arthepsy]

@gunslingerfry could You try latest-commit and see if that works? If not, please, provide a full error.

[coldcoff]

Thanks for merging my changes and improving it even further! Wonderful that we are now reducing the variety of forks!

I am just trying to use your new, consolidated version and to abandon my own.

I saw that in commit 9eea095 you reworked the certificate parts.

Now we have a vpn_cli_cert and a okta_cli_cert.

From reading the code I see that you use the okta_cli_cert in all of the python parts and vpn_cli_cert (only) for the final openconnect call.

This is confusing.

The python part is connecting to the vpn_url (portal & Gateway) and also to the okta_url (3rd Party service).

Especially in my case only vpn_url is really using and checking client certificates, okta does not know anything about our CA, But I now need to set okta_cli_cert to present my certificate to the gateway?

Is Okta really checking anyones client certificates? Is that a feature? At least for me they never asked for any client certificates.

If you would like to keep the newliy introduced separation I would suggest to rename
vpn_cli_cert and a okta_cli_cert to
vpn_cli_cert -> openconnect_cli_cert
okta_cli_cert -> ??? (maybe gp-okta_cli_cert?)
Maybe you have some idea?

At least having to set okta_cli_cert to present it to vpn_url seems not intuitive?

[coldcoff]

One more, sorry ...

That here:

is not working for me. for some reason it is no separate command?
My openconnect complains that it does not know anything about a "-f"

Commenting out the two lines makes openconnect start & connect!
Can you please rework the deletion?

It seems to be needed now as the file is not automagically deleted anymore:

and was introduced in commit 9eea095

[coldcoff]

Just to document:

What I needed to do to make your merged version work for me is:

1. move my openconnect_certs = xxx option to certs = xxx in my conf

2. set my former client_cert = yyy option as both vpn_cli_cert = yyy and okta_cli_cert = yyy in my conf (removing my old client_cert = yyy) [see my comment above]

3. add a new option gateway_url = zzz basically duplicating my old, existing gateway = zzz option, so now I have

    gateway = vpn-someplace.company.com
    gateway_url = https://vpn-someplace.company.com

4. comment out lines 927 and 928 [see comment above]

[arthepsy]

Thanks for merging my changes and improving it even further! Wonderful that we are now reducing the variety of forks!

I am just trying to use your new, consolidated version and to abandon my own.

Yes, I want to merge everything, improve it, get You guys test it, and release 1.00, so it can be referenced.

I saw that in commit 9eea095 you reworked the certificate parts.

Now we have a vpn_cli_cert and a okta_cli_cert.

From reading the code I see that you use the okta_cli_cert in all of the python parts and vpn_cli_cert (only) for the final openconnect call.

This is confusing.

I was going with comment from aclindsa#1 (comment) ... and trying to make it future-proof.

So, basically, we have a client certificate for connecting to OKTA (python requests). And other client certificate to which authenticate portal/gateway with (which is passed in command-line to openconnect). They are two different certificates, right?

The python part is connecting to the vpn_url (portal & Gateway) and also to the okta_url (3rd Party service).

Especially in my case only vpn_url is really using and checking client certificates, okta does not know anything about our CA, But I now need to set okta_cli_cert to present my certificate to the gateway?

Is Okta really checking anyones client certificates? Is that a feature? At least for me they never asked for any client certificates.

I see the issue now. We have 5 different connections:

1. to OKTA in Python script
2. to PORTAL in Python script
3. to GATEWAY in Python script
4. to PORTAL in command-line
5. to GATEWAY in command-line

If you would like to keep the newliy introduced separation I would suggest to rename
vpn_cli_cert and a okta_cli_cert to
vpn_cli_cert -> openconnect_cli_cert
okta_cli_cert -> ??? (maybe gp-okta_cli_cert?)
Maybe you have some idea?

At least having to set okta_cli_cert to present it to vpn_url seems not intuitive?

I was going with same naming scheme as _url.
So okta_url will be provided okta_cli_cert and vpn_url withh be provided vpn_cli_cert. Doesn't that seem sane?

Only thing seem to fix code, where to use each certificate. Currently it wrongly uses okta_cli_cert for communication with portal/gateway in Python script.

Do You agree?

[arthepsy]

One more, sorry ...

That here:

is not working for me. for some reason it is no separate command?
My openconnect complains that it does not know anything about a "-f"

Good point. Didn't test this part. Will check and issue fix.

Commenting out the two lines makes openconnect start & connect!
Can you please rework the deletion?

It seems to be needed now as the file is not automagically deleted anymore:

and was introduced in commit 9eea095

File is not deleted, because it is passed as command-line option (-cafile) to openconnect. How otherwise openconnect would use it, if it was deleted? Maybe if it's piping (printf ... | ./openconnect), then while pipe is open, all would be good. But if somebody wants to not use execute flag, and executes manually? File is gone. Therefore it mustn't be deleted. Don't You agree?

Unfortunately our VPN doesn't have client certificates and I can only go by pull request comments and sane ideas, but not able to test. Do You have client certificate VPN You can test with?

[arthepsy]

3. add a new option gateway_url = zzz basically duplicating my old, existing gateway = zzz option, so now I have

    gateway = vpn-someplace.company.com
    gateway_url = https://vpn-someplace.company.com

I don't even get this worked for You before. I commented my issues in pull request. Gateway is named and can be passed (I will rework it to be in such way) either in command-line as authgroup or in execution. But never as URL.

How did You execute it before and how did it work? If it connected directly to gateway (_url), fine, but then, when it passed in pipe, e.g., printf cookie|gateway_url ... that shouldn't have worked. Baffles me.

---

Edit: Ok, got it. You authenticated against gateway and therefore, passing anything after cookie is just ignored, be it gateway or any other garbage.

[gunslingerfry]

@arthepsy missed your reply. I'll try to check this today.

[arthepsy]

@coldcoff do You know what certificates are returned in "getconfig" request, where responding SAML could contain //root-ca/cert? I'm assuming it's only for gateways, but want to make sure.

[gunslingerfry]

Looks like you've got 'command' instead of the actual command at line 955.

  File "./gp-okta.py", line 992, in <module>
    sys.exit(main())
  File "./gp-okta.py", line 955, in main
    p  = subprocess.Popen(['command', '-v', openconnect_bin], stdin=subprocess.PIPE, stdout=fnull, stderr=subprocess.STDOUT)
  File "/usr/lib/python3.8/subprocess.py", line 854, in __init__
    self._execute_child(args, executable, preexec_fn, close_fds,
  File "/usr/lib/python3.8/subprocess.py", line 1702, in _execute_child
    raise child_exception_type(errno_num, err_msg, err_filename)
FileNotFoundError: [Errno 2] No such file or directory: 'command'```

[arthepsy]

Looks like you've got 'command' instead of the actual command at line 955.

  File "./gp-okta.py", line 992, in <module>
    sys.exit(main())
  File "./gp-okta.py", line 955, in main
    p  = subprocess.Popen(['command', '-v', openconnect_bin], stdin=subprocess.PIPE, stdout=fnull, stderr=subprocess.STDOUT)
  File "/usr/lib/python3.8/subprocess.py", line 854, in __init__
    self._execute_child(args, executable, preexec_fn, close_fds,
  File "/usr/lib/python3.8/subprocess.py", line 1702, in _execute_child
    raise child_exception_type(errno_num, err_msg, err_filename)
FileNotFoundError: [Errno 2] No such file or directory: 'command'```

Wow. You don't have command utility? Which OS and shell You're using, @gunslingerfry ? Can You test that in the shell:
command -v openconnect

[gunslingerfry]

I do have command it looks like. (Sorry, I've never used that utility before)

$ command -v openconnect
/usr/bin/openconnect

[gunslingerfry]

I'm slightly above the python experience level of 'knows what python is' but I tried os.system('command -v openconnect') and it works fine but subprocess.Popen doesn't.

[arthepsy]

@gunslingerfry seems interesting. Would like to reproduce such error. Can You share what is the shell, where You execute that script? Never seen such issue.

Anyhow, I will removed that part and re-worked it in a different way. Please, re-check.

[arthepsy]

@coldcoff @gunslingerfry @cardonator I've made another several rounds of improvements. Would be nice if You could check it out and give feedback. Trying to release 1.00 ;)

[coldcoff]

To #21 (comment)

They are two different certificates, right?

Yes. at least they could be. Or only one service uses certificates.

Do You agree?

Yes.

---

To #21 (comment)

File is not deleted, because it is passed as command-line option (-cafile) to openconnect. How otherwise openconnect would use it, if it was deleted?

In the previous code the temp file existed as long as the python object holding/referencing it existed (which is basically the runtime of gp-okta.py.) (see: https://docs.python.org/2/library/tempfile.html)
So it elegantly was also still there when python is calling the subcommand to start openconnect, because at that time the python script and the temp file object are still "alive".
You are right, this won't work in the execute = 0 case, this was an oversight. I did not realize, because I have a concrete file name (~/etc/openconnect/openconnect.certs) in my gp-okta.conf.

Do You have client certificate VPN You can test with?

Yes. Happy to test for you anytime!

---

To #21 (comment)

You know what certificates are returned in "getconfig" request, where responding SAML could contain //root-ca/cert? I'm assuming it's only for gateways, but want to make sure.

For me it's the certs that both, portal and gateway use. In fact no new content compared to what is already in vpn_url_cert. Our companies root ca and the digicert chain. I assume this is for the gateways, yes. But as portal & gateway is basically two modes of the same "product" probably there won't be differences. But (chicken & egg ...) you need to connect to the portal to issue the getconfig request :-)

---

#21 (comment)

command is a bash builtin to ensure that you call real "commands", no functions or aliases or such (see: help command). So when you use pythons subprocess.Popen then you don't need command, because that's what the Popen does.
It would work with subprocess.Popen(..., shell=True, ...) though, when you enforce the command to be executed in a shell. Best is to remove the command here and not assume anything about a users shell. If a user really needs a special prefix he can tune his openconnect_cmd.

---

#21 (comment)

@coldcoff... I've made another several rounds of improvements. Would be nice if You could check it out and give feedback. Trying to release 1.00 ;)

Will do.

[arthepsy]

File is not deleted, because it is passed as command-line option (-cafile) to openconnect. How otherwise openconnect would use it, if it was deleted?

In the previous code the temp file existed as long as the python object holding/referencing it existed (which is basically the runtime of gp-okta.py.) (see: https://docs.python.org/2/library/tempfile.html)
So it elegantly was also still there when python is calling the subcommand to start openconnect, because at that time the python script and the temp file object are still "alive".
You are right, this won't work in the execute = 0 case, this was an oversight. I did not realize, because I have a concrete file name (~/etc/openconnect/openconnect.certs) in my gp-okta.conf.

I reworked it to delete it automatically if execute=1, otherwise file is not deleted and rm -f command is outputted.

@coldcoff... I've made another several rounds of improvements. Would be nice if You could check it out and give feedback. Trying to release 1.00 ;)

Will do.

Would be awesome!

[coldcoff]

xxx_cli_cert -> could we probably rename that to xxx_client_cert ?

At least I always understand "cli" as "commandline", not "client" in my abbreviation 1st level cache.

[coldcoff]

gateway = vpn-someplace.company.com
gateway_url = https://vpn-someplace.company.com

I understand that for you thi rule does not apply, but could you probably add a shortcut that gateway_url can be automatically constructed from gateway if unset?

[coldcoff]

Note: I am still able to connect after all of your recent changes yesterday and today, using the current HEAD.

[arthepsy]

gateway = vpn-someplace.company.com
gateway_url = https://vpn-someplace.company.com

I understand that for you thi rule does not apply, but could you probably add a shortcut that gateway_url can be automatically constructed from gateway if unset?

That would not make sense. How would that work? For example, my gateway is named "FRANKFURT". What domain should I add? For others, also, that is only a name, not URL and in most cases, not even related to URL.

gateway is Gateway name (see openconnect --authgroup option). gateway_url is URL to direct connect to gateway.

By the way, in Your case, when You use gateway_url, You don't need gateway. That is the reason it worked for You before (where pull request wrongly reworked gateway only for that case).

[arthepsy]

xxx_cli_cert -> could we probably rename that to xxx_client_cert ?

At least I always understand "cli" as "commandline", not "client" in my abbreviation 1st level cache.

Heh, good note. Now when You mention it, I also have seen "cli' as "command-line", but in server/client context, usually I see "srv" and "cli. Anyway, I wanted to make config name in same lines as in _url_, i.e., 3-letter. Anyhow, it's documented in .conf, so it wouldn't make any confusion.

[arthepsy]

Note: I am still able to connect after all of your recent changes yesterday and today, using the current HEAD.

Does it work with certificate authentication and verification? If so, then all seems great and pretty much ready for release.

[arthepsy]

I was able to test 1) direct gateway config 2) simple portal config 3) second auth dance 4) cert verification. I am not able to test client certificates.

[coldcoff]

I corrupted my vpn_url_cert (copied okta_url_cert over it) to force a failure.

Bad: The connection is still established.
The get_verify just returns True for the prelogin request.

Please consider the following patch:

diff --git a/gp-okta.py b/gp-okta.py
index 4eb2467..a107fa1 100755
--- a/gp-okta.py
+++ b/gp-okta.py
@@ -260,8 +260,11 @@ class Conf(object):
                        return self._store['okta_url_cert']
                if name == 'portal' and 'vpn_url_cert' in self._store:
                        return self._store['vpn_url_cert']
-               if name == 'gateway' and self._ocerts:
-                       return self.certs
+               if name == 'gateway':
+                       if self._ocerts:
+                               return self.certs
+                       elif 'vpn_url_cert' in self._store:
+                               return self._store['vpn_url_cert']
                return default_verify
 
        def get_line(self, name):

otherwise a malicious gateway can inject arbitrary self._ocerts via a faked getconfig response.

Now it fails, as expected:

requests.exceptions.ConnectionError: HTTPSConnectionPool(host='vpn-someplace.company.com', port=443): Max retries exceeded with url: /ssl-vpn/prelogin.esp (Caused by SSLError(SSLError("bad handshake: Error([('SSL routines', 'ssl3_get_server_certificate', 'certificate verify failed')],)",),))

[arthepsy]

I corrupted my vpn_url_cert (copied okta_url_cert over it) to force a failure.

Bad: The connection is still established.
The get_verify just returns True for the prelogin request.

Please consider the following patch:

diff --git a/gp-okta.py b/gp-okta.py
index 4eb2467..a107fa1 100755
--- a/gp-okta.py
+++ b/gp-okta.py
@@ -260,8 +260,11 @@ class Conf(object):
                        return self._store['okta_url_cert']
                if name == 'portal' and 'vpn_url_cert' in self._store:
                        return self._store['vpn_url_cert']
-               if name == 'gateway' and self._ocerts:
-                       return self.certs
+               if name == 'gateway':
+                       if self._ocerts:
+                               return self.certs
+                       elif 'vpn_url_cert' in self._store:
+                               return self._store['vpn_url_cert']
                return default_verify
 
        def get_line(self, name):

otherwise a malicious gateway can inject arbitrary self._ocerts via a faked getconfig response.

Now it fails, as expected:

requests.exceptions.ConnectionError: HTTPSConnectionPool(host='vpn-someplace.company.com', port=443): Max retries exceeded with url: /ssl-vpn/prelogin.esp (Caused by SSLError(SSLError("bad handshake: Error([('SSL routines', 'ssl3_get_server_certificate', 'certificate verify failed')],)",),))

I don't understand Your description in context with patch. If You changed vpn_url_cert, then it is verified in line before:

                if name == 'portal' and 'vpn_url_cert' in self._store:
                        return self._store['vpn_url_cert']

[arthepsy]

Wait, do You expect vpn_url_cert to be verified, when You use gateway_url? It won't. It's written in configuration description. vpn_url_cert is verified only for vpn_url. If You want to verify gateway_url, then create any *_cert, e.g., my_super_gateway_cert=... and it will be verified.

When You use gateway_url, then vpn_url_cert is ignored at all.

[coldcoff]

My first (and only) contact is the gateway (due to my config)!

[INFO] load conf
[INFO] prelogin request [gateway_url]
[INFO] okta saml request [okta_url]
[INFO] okta auth request [okta_url]
[INFO] sessionToken: XXX
[INFO] okta redirect request 1 [okta_url]
[INFO] stateToken: YYY
[INFO] okta auth request [okta_url]
[INFO] mfa fido challenge request [okta_url]

!!! Touch the flashing U2F device to authenticate... !!!

[INFO] mfa fido signature request [okta_url]
[INFO] okta redirect request 2 [okta_url]
[INFO] okta redirect form request [gateway]
[INFO] portal-userauthcookie: None
[INFO] gateway: https://vpn-someplace.company.com
[INFO] saml-username: [email protected]
[INFO] prelogin-cookie: XYZ
...

[arthepsy]

@coldcoff check my comments before. You need other _cert defined and it will work.

[coldcoff]

OK, understood.

Well, I can't test really as I wanted - because the returned self.certs will contain the union of all certs, so it will not look for my corrupted my_super_gateway_cert alone.
But indeed, if I explicitely delete vpn_url_cert then it fails.

[coldcoff]

Ship it :-) If I advertise here locally, you will soon get ~ 20-30 users.
I'll need to write up some "How-to-Update" document for them (for the gp-okta.conf)

[coldcoff]

@lvml - could you please test as well and give your opinion?

[arthepsy]

Ship it :-) If I advertise here locally, you will soon get ~ 20-30 users.
I'll need to write up some "How-to-Update" document for them (for the gp-okta.conf)

Yay, would be great. Also, not keeping different forks. I'll test one feature (gpg) in Your pull request and then ship it.

[cardonator]

Just wanted to let you know that the latest version doesn't work with my portal at all now :)

[arthepsy]

Just wanted to let you know that the latest version doesn't work with my portal at all now :)

Oh, come on :) What's the issue? Can't imagine. Please, provide a error message and description.

[cardonator]

Haha! I was trying to figure out what's going on but this one keeps stumping me.

Basically, every time I try to connect I'm getting that 512 error again.

[INFO] gateway: https://gatewayurl
[INFO] saml-username: corp\myusername
[INFO] prelogin-cookie: <prelogin cookie>

POST https://gatewayurl/global-protect/prelogin.esp?tmp=tmp&clientVer=4100&clientos=Linux
Connected to <gatewayIP>
SSL negotiation with gatewayurl
Connected to HTTPS on gatewayurl
SAML login is required via POST to this URL:
        <html>
<body>
<form id="myform" method="POST" action="https://oktadomain/app/panw_globalprotect/oktatoken/sso/saml">
<input type="hidden" name="SAMLRequest" value="<samltoken>" />
<input type="hidden" name="RelayState" value="<relaytoken>" />
</form>
<script>
  document.getElementById('myform').submit();
</script>
</body>
</html>

Enter login credentials
POST https://gatewayurl/global-protect/getconfig.esp
Got HTTP response: HTTP/1.1 512 Custom error
Unexpected 512 result from server
SAML login is required via POST to this URL:
        <html>
<body>
<form id="myform" method="POST" action="https://oktadomain/app/panw_globalprotect/oktatoken/sso/saml">
<input type="hidden" name="SAMLRequest" value="<samltoken>" />
<input type="hidden" name="RelayState" value="<relaytoken>" />
</form>
<script>
  document.getElementById('myform').submit();
</script>
</body>
</html>

Enter login credentials
Username: portal-userauthcookie: 
fgets (stdin): Inappropriate ioctl for device

[cardonator]

For reference, if I switch back to coldcoff's master PR, I am able to connect without issue. I am also able to connect on the merge commit from #19. Something since then has broken my ability to connect.

[arthepsy]

@cardonator where is this error from? Seems packed from multiple sources. Doesn't look like either Python script or openconnect output. Could You reformat it a bit? What's the command-line and printf pipe contents?

Your description seems that it's somehow providing wrong cookie to portal or gateway (don't know Your config) for some reason. Can't think of reason, though. What's your config, i.e., are You connecting to portal, gateway, doing another dance, etc? Is another_dance or gateway_url configured?

[gunslingerfry]

@arthepsy Alright. I tested with the current head (b637ea9) with SMS, push, and TOTP entry and all work perfectly. THANKS!!!

The vpnc script is failing to set a route of some sort, the ip command returns Error: ipv4: Invalid values in header for route get request. then dumps the help for ip route. It doesn't seem to fail to connect or split and it has been like this since I started using this project.

[arthepsy]

@gunslingerfry awesome! I was thinking it should be pretty much perfect now.
Regarding vpnc script, that's a thing You should figure out, if interested. Don't recall such issues.

[cardonator]

@cardonator where is this error from? Seems packed from multiple sources. Doesn't look like either Python script or openconnect output. Could You reformat it a bit? What's the command-line and printf pipe contents?

This is literally every message that is printed out after finishing the Okta handshake. I can set execute to 0 to see what command it constructed. It might be helpful to note that I was also always getting this error on this repo without coldcoff changes prior to merge, so this is the same behavior I had over a week ago.

Your description seems that it's somehow providing wrong cookie to portal or gateway (don't know Your config) for some reason. Can't think of reason, though. What's your config, i.e., are You connecting to portal, gateway, doing another dance, etc? Is another_dance or gateway_url configured?

my config looks like this:

debug = 0

vpn_url = https://gatewayurl/
#vpn_url_cert = vpn_url.cert

okta_url = https://digicert.okta.com
#okta_url_cert = okta_url.cert

username = myusername
password = mypassword
#client_cert = path-to-myusers-client-cert-as-unencrypted-pem-file.pem

mfa_order = push
#sms.okta = 0
#totp.okta = ABCDEFGHIJKLMNOP
#totp.google = ABCDEFGHIJKLMNOP
#totp.symantec = ABCDEFGHIJKLMNOP

gateway = gatewayname   # optional hardcoded gateway

openconnect_cmd = "sudo openconnect"
#openconnect_certs = path-to-a-writeable-filename-in-which-the-script-will-collect-all-involved-server-certs-if-not-set-a-temp-file-is-used-instead
openconnect_args = "--csd-wrapper=hipreport.sh"  # optional arguments to openconnect
execute = 1                           # execute openconnect command
another_dance = 0                     # second round of authentication required
bug.nl = 0                            # newline work-around for openconnect
bug.username = 0                      # username work-around for openconnect

To clarify, this exact config works on coldcoff-master but not on actual master.

I am vaguely remembering something, though. I did have an issue at one point where the settings were making the cookie get passed as portal:portal-userauthcookie but my portal wanted gateway:prelogin-cookie instead. That went away on the coldcoff branch at some point, though. (I just tried forcing it both ways and it had no effect)

[gunslingerfry]

Ok, I'm wrong, it's not the vpnc script, I think openconnect is doing this. I'll check in at the openconnect repo to see if that's been reported.
I am getting this after shutting down though. Logout successful is what I'm used to seeing.

Invalid user name
Logout failed.

[arthepsy]

Ok, I'm wrong, it's not the vpnc script, I think openconnect is doing this. I'll check in at the openconnect repo to see if that's been reported.
I am getting this after shutting down though. Logout successful is what I'm used to seeing.

Invalid user name
Logout failed.

I would suggest creating simple vpnc scripts and figuring it out. Example:

#!/bin/sh
env

[cardonator]

Sorry to keep posting in here in real-time.......

I think the last paragraph of my previous message is on to something. Here are the two connect commands generated by the different versions:

coldcoff:

printf '<prelogin-cookie>\n<gatewayname>' | sudo openconnect --protocol=gp -u 'corp\myusername' --usergroup gateway:prelogin-cookie --passwd-on-stdin --csd-wrapper=hipreport.sh 'https://<gatewayurl>'

master:

printf '<portal-userauthcookie>\n<portal-userauthcookie>' | sudo openconnect --protocol=gp -u 'corp\myusername' --authgroup='<gatewayname>' --usergroup portal:portal-userauthcookie --cafile='/tmp/gpvpn_n812df_j' --passwd-on-stdin --csd-wrapper=hipreport.sh 'https://<gatewayurl>/'; rm -f '/tmp/gpvpn_n812df_j'

The top command connects fine, the bottom one fails with the message above every time.

[arthepsy]

@cardonator where is this error from? Seems packed from multiple sources. Doesn't look like either Python script or openconnect output. Could You reformat it a bit? What's the command-line and printf pipe contents?

This is literally every message that is printed out after finishing the Okta handshake. I can set execute to 0 to see what command it constructed. It might be helpful to note that I was also always getting this error on this repo without coldcoff changes prior to merge, so this is the same behavior I had over a week ago.

Interesting. I see something completely off:

[INFO] prelogin-cookie: <prelogin cookie>

POST https://gatewayurl/global-protect/prelogin.esp?tmp=tmp&clientVer=4100&clientos=Linux
Connected to <gatewayIP>

prelogin-cookie is provided to gateway, but You're connecting to gateway as it was portal, because it's using /global-protect/.

To clarify, this exact config works on coldcoff-master but not on actual master.

I am vaguely remembering something, though. I did have an issue at one point where the settings were making the cookie get passed as portal:portal-userauthcookie but my portal wanted gateway:prelogin-cookie instead. That went away on the coldcoff branch at some point, though. (I just tried forcing it both ways and it had no effect)

Yes, seem that You haven't updated Your config. Please, check current .conf file.
Also, I see that You're using vpn_url = https://gatewayurl/, which is wrong. vpn_url should always point to portal. This probably is the cause for errors.

If You want to directly connect to gateway, provide gateway_url in config with it's URL.

[arthepsy]

Sorry to keep posting in here in real-time.......

I think the last paragraph of my previous message is on to something. Here are the two connect commands generated by the different versions:

coldcoff:

printf '<prelogin-cookie>\n<gatewayname>' | sudo openconnect --protocol=gp -u 'corp\myusername' --usergroup gateway:prelogin-cookie --passwd-on-stdin --csd-wrapper=hipreport.sh 'https://<gatewayurl>'

master:

printf '<portal-userauthcookie>\n<portal-userauthcookie>' | sudo openconnect --protocol=gp -u 'corp\myusername' --authgroup='<gatewayname>' --usergroup portal:portal-userauthcookie --cafile='/tmp/gpvpn_n812df_j' --passwd-on-stdin --csd-wrapper=hipreport.sh 'https://<gatewayurl>/'; rm -f '/tmp/gpvpn_n812df_j'

The top command connects fine, the bottom one fails with the message above every time.

Yes, as You see, it's providing portal-userauthcookie, which is meant for PORTAL, but You're connecting to GATEWAY. Reason is, seems that You have configured gateway as portal URL as I described before. If You want to connect directly to gateway, then You must use gateway_url. Please check config file in master, it's documented.

[cardonator]

Hmm, yeah, I said gateway_url but that is actually the vpn_url...

[gunslingerfry]

Sorry to conflate two issues. No worries on the vpnc script/openconnect thing, just doing raw openconnect commands with no vpnc script will cause that error so it's definitely not anything you are doing.

The invalid user name and logout failed message is returned only when using the gp-okta script though. Raw openconnect commands work fine.

[arthepsy]

@cardonator there are types 3 connections:

1. if You have default config, script connects to vpn_url (portal) ... chooses gateway (name) and provides portal:userauthcookie to vpn_url (portal).
2. if You have default config with gateway_url (gateway), script connects to gateway_url and provides gateway:prelogin-cookie
3. if You have default config with another_dance=1, script connects vpn_url (portal), then to gateway and at the end provides gateway:prelogin-cookie

Please, check Your config file for correct URL and setting usage.

[cardonator]

You're right, @arthepsy I was being dumb 👍 I did need to define the gateway_url, was missing that in the new config because I was used to how it was originally implemented. Once I added that in, it worked just fine.

What I find weird in my config is that I can't auth with the portal and then connect to a gateway even though that's how the first party app works. But I guess I shouldn't look a gift horse in the mouth 😄

[arthepsy]

You're right, @arthepsy I was being dumb 👍 I did need to define the gateway_url, was missing that in the new config because I was used to how it was originally implemented. Once I added that in, it worked just fine.

What I find weird in my config is that I can't auth with the portal and then connect to a gateway even though that's how the first party app works. But I guess I shouldn't look a gift horse in the mouth 😄

Yes, you can. It's how it's working in default config mode. It's how it's working for me. Just provide vpn_url as portal URL. You probably have defined gateway as vpn_url and that is the issue.

[arthepsy]

Sorry to conflate two issues. No worries on the vpnc script/openconnect thing, just doing raw openconnect commands with no vpnc script will cause that error so it's definitely not anything you are doing.

The invalid user name and logout failed message is returned only when using the gp-okta script though. Raw openconnect commands work fine.

What do You mean by "raw openconnect commands"? Could You elaborate (go ahead and open another issue)? Maybe, just maybe, it's because You're using openconnect before 8.05 and providing cookie twice somehow affects vpnc script (it doesn't affect for me, though). If that's the case, fast workaround would be to use openconnect_fmt = <cookie>. But I would like to resolve this issue, if that's really an issue.

[arthepsy]

You're right, @arthepsy I was being dumb 👍 I did need to define the gateway_url, was missing that in the new config because I was used to how it was originally implemented. Once I added that in, it worked just fine.

Actually, somebody broke how everything should work (for everybody authenticating to portal), i.e., gateway was name for gateway (or authgroup in openconnect), not it's URL, but it got changed in forks and guys got used to it... probably, You, too. So it completely broke one of three method how to connect to VPN. I briefly explained all three methods in #21 (comment) ... and as it's actually URL, I had to rename gateway_url.

[cardonator]

That's exactly what happened. Unfortunately, my primary gateway name is also the URL for the portal so I don't know how that ends up confusing things. Adding the portal URL to the gateway_url config fixed it, but it is pretty confusing how I can't do the portal->gateway dance that the regular GP client does.

At any rate, I'm now ready to give my sign off on this release! 👍

[arthepsy]

That's exactly what happened. Unfortunately, my primary gateway name is also the URL for the portal so I don't know how that ends up confusing things. Adding the portal URL to the gateway_url config fixed it, but it is pretty confusing how I can't do the portal->gateway dance that the regular GP client does.

I feel like this is a config issue. Or very interesting edge case :) Would like to figure it out, either way. Is there some IM (irc, discord, etc) I could catch You to work this out?

At any rate, I'm now ready to give my sign off on this release! 👍

Thanks :)

[cardonator]

Sure, I'm on Discord. Sir_Brizz#5340.

[arthepsy]

Sir_Brizz#5340

Message from Discord: "Hm, didn't work. Double check that capitalization, spelling, any spaces, and numbers are correct."

[cardonator]

Weird. Oh apparently the whole left side is lowercase... maybe that will work?

[arthepsy]

Weird. Oh apparently the whole left side is lowercase... maybe that will work?

Worked. Pending friend request.

[cardonator]

What is your nick? for some reason I have 49 pending friend requests and it doesn't tell which ones are new.

[arthepsy]

@cardonator sorry, had a wisdom teeth removal, was a bit off. my nick is moo#2174.