arthepsy / pan-globalprotect-okta

PaloAlto Networks GlobalProtect VPN (integrated with OKTA) command-line client
101 stars 42 forks source link

feedback after latest improvements #21

Open arthepsy opened 4 years ago

arthepsy commented 4 years ago

@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 commented 4 years ago

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

arthepsy commented 4 years ago

Yes, that's correct.

gunslingerfry commented 4 years ago

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 commented 4 years ago

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

arthepsy commented 4 years ago

@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 commented 4 years ago

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

arthepsy commented 4 years ago

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

coldcoff commented 4 years ago

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 9eea095bda5d5def53290b445e3ab30b9abd32ca 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 commented 4 years ago

One more, sorry ...

That here: image

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"

image

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: image and was introduced in commit 9eea095bda5d5def53290b445e3ab30b9abd32ca

coldcoff commented 4 years ago

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 commented 4 years ago

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 https://github.com/aclindsa/pan-globalprotect-okta/pull/1#issuecomment-499841729 ... 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 commented 4 years ago

One more, sorry ...

That here: image

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.

image

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: image 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 commented 4 years ago
  1. 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 commented 4 years ago

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

arthepsy commented 4 years ago

@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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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

$ command -v openconnect
/usr/bin/openconnect
gunslingerfry commented 4 years ago

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 commented 4 years ago

@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 commented 4 years ago

@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 commented 4 years ago

To https://github.com/arthepsy/pan-globalprotect-okta/issues/21#issuecomment-633650409

They are two different certificates, right?

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

Do You agree?

Yes.


To https://github.com/arthepsy/pan-globalprotect-okta/issues/21#issuecomment-633651647

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 https://github.com/arthepsy/pan-globalprotect-okta/issues/21#issuecomment-633680982

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 :-)


https://github.com/arthepsy/pan-globalprotect-okta/issues/21#issuecomment-633711325

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.


https://github.com/arthepsy/pan-globalprotect-okta/issues/21#issuecomment-633775197

@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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago
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 commented 4 years ago

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

arthepsy commented 4 years ago
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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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: coldcoff@company.com [INFO] prelogin-cookie: XYZ ...
arthepsy commented 4 years ago

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

coldcoff commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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

arthepsy commented 4 years ago

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 commented 4 years ago

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

arthepsy commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

@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 commented 4 years ago

@arthepsy Alright. I tested with the current head (b637ea902832e4d6d3b6f610456188207a832081) 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 commented 4 years ago

@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 commented 4 years ago

@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 commented 4 years ago

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 commented 4 years ago

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