Gpclient does not recognize vpnc-script as executable

[surfrock66]

Describe the bug When attempting to use a script with gpclient to utilize more nuanced vpn-slice, I get an error that "vpnc script is not executabe". The vpnc-script script is on the system, is executable, and has manually been added to the path as a double check.

It was installed to /usr/share/vpnc-scripts/

To exclude any issue with my specific script, I was able to recreate the issue with an empty script; specifying any script is triggering this error.

If I exclude the --script switch, the connection works just fine (albeit without my split tunnel configuration)

Expected behavior The client should prompt for authentication (or used cached authentication) and connect.

Screenshots Error run as root:

Error run as sudo:

Successful connection without --script:

Environment:

• OS: Ubuntu 24.04
• Desktop Environment: Mate
• Is remote SSH? No, Proxmox VM accessed by local console or VNC.

[surfrock66]

One more datapoint, here's the actual vpn-slice command, in this case I showed that the vpn-slice script is executable and it's referenced in the full path, but I get the same result:

The vpn-slice command is passing it's own tests:

[yuezk]

Hi @surfrock66, the --script parameter accepts an executable script file path. But it doesn't support passing a command.

So for your case, you can save the command as an executable file and pass that file to the --script parameter, for example.

A file named path/to/your/script.sh

#!/bin/bash

vpn-slice xxx.xxx.xxx.xxx/24

Then use the script parameter like: --script path/to/your/script.sh.

But it looks like the --script parameter can be improved to support passing a command.

Let me know if you have any questions. Thanks.

[surfrock66]

Ok perfect that worked; In researching vpn-slice a lot of the documentation has the script inline with openconnect commands which was confusing, supporting in-line scrips would be great but maybe more up-front documentation on it would be enough in case it's a bigger programming lift. https://github.com/dlenski/vpn-slice?tab=readme-ov-file#usage

[surfrock66]

Apologies, I may have closed this prematurely. I'm having a lot of trouble with routing and split tunnel. I've been through the documentation for vpn-slice and it shows that you can specify inverted subnets to exclude from going over the tunnel. https://github.com/dlenski/vpn-slice?tab=readme-ov-file#usage When I do that, I'm getting the following in my logs:

surfrock66@sr66-vdi-02:~$ sudo -E gpclient --fix-openssl connect --script "/home/surfrock66/.scripts/vpn-split-tunnel.sh" REDACTEDADDRESS
[sudo] password for surfrock66: 
[2024-05-09T16:27:59Z INFO  gpclient::cli] gpclient started: 2.1.2 (2024-03-29)
[2024-05-09T16:27:59Z INFO  gpapi::portal::prelogin] Prelogin with user_agent: PAN GlobalProtect
[2024-05-09T16:28:01Z INFO  gpauth::cli] gpauth started: 2.1.2 (2024-03-29)
[2024-05-09T16:28:01Z INFO  gpauth::cli] Fixing OpenSSL environment
[2024-05-09T16:28:01Z INFO  gpauth::auth_window] Open auth window, user_agent: PAN GlobalProtect

** (gpauth:12897): WARNING **: 09:28:01.452: webkit_settings_set_enable_offline_web_application_cache is deprecated and does nothing.
MESA: error: ZINK: failed to choose pdev
libEGL warning: egl: failed to create dri2 screen
[2024-05-09T16:28:01Z INFO  gpauth::auth_window] Auth window user agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/17.0 Safari/605.1.15
[2024-05-09T16:28:01Z INFO  gpauth::auth_window] Load the SAML request as URI...
[2024-05-09T16:28:02Z INFO  gpauth::auth_window] Loaded uri: https://l**********m/c9324e90-3192-4368-b40d-c16169c276de/saml2?SAMLRequest=h**********C&RelayState=0**********%3D
[2024-05-09T16:28:02Z INFO  gpauth::auth_window] Trying to read auth data from response headers...
[2024-05-09T16:28:02Z INFO  gpauth::auth_window] No saml-auth-status header found
[2024-05-09T16:28:02Z INFO  gpauth::auth_window] No auth data found in headers, trying to read from body...
[2024-05-09T16:28:02Z INFO  gpauth::auth_window] No auth data found in HTML
[2024-05-09T16:28:02Z INFO  gpauth::auth_window] No auth data found, it may not be the /SAML20/SP/ACS endpoint
[2024-05-09T16:28:02Z INFO  gpauth::auth_window] Raise window in 1 second(s)
[2024-05-09T16:28:02Z INFO  gpauth::auth_window] Raise window cancelled
[2024-05-09T16:28:02Z INFO  gpauth::auth_window] Loaded uri: https://v**********u/SAML20/SP/ACS
[2024-05-09T16:28:02Z INFO  gpauth::auth_window] Trying to read auth data from response headers...
[2024-05-09T16:28:02Z INFO  gpauth::auth_window] Got auth data from headers
[2024-05-09T16:28:02Z INFO  gpapi::portal::config] Portal config, user_agent: PAN GlobalProtect
[2024-05-09T16:28:02Z INFO  gpclient::connect] Connecting to the only available gateway: vpn (REDACTEDADDRESS)
[2024-05-09T16:28:02Z INFO  gpapi::gateway::login] Gateway login, user_agent: PAN GlobalProtect
[2024-05-09T16:28:02Z INFO  openconnect::ffi] openconnect version: v9.12-1build5
[2024-05-09T16:28:02Z INFO  openconnect::ffi] User agent: PAN GlobalProtect
[2024-05-09T16:28:02Z INFO  openconnect::ffi] VPNC script: /home/surfrock66/.scripts/vpn-split-tunnel.sh
[2024-05-09T16:28:02Z INFO  openconnect::ffi] OS: linux
[2024-05-09T16:28:02Z INFO  openconnect::ffi] CSD_USER: 1000
[2024-05-09T16:28:02Z INFO  openconnect::ffi] CSD_WRAPPER: (null)
[2024-05-09T16:28:02Z INFO  openconnect::ffi] MTU: 0
[2024-05-09T16:28:02Z INFO  openconnect::ffi] POST https://REDACTEDADDRESS/ssl-vpn/getconfig.esp
[2024-05-09T16:28:02Z INFO  openconnect::ffi] Connected to REDACTEDADDRESS:443
[2024-05-09T16:28:02Z INFO  openconnect::ffi] SSL negotiation with REDACTEDADDRESS
[2024-05-09T16:28:03Z INFO  openconnect::ffi] Connected to HTTPS on REDACTEDADDRESS with ciphersuite (TLS1.2)-(ECDHE-SECP256R1)-(RSA-SHA256)-(AES-256-GCM)
[2024-05-09T16:28:03Z INFO  openconnect::ffi] Tunnel timeout (rekey interval) is 180 minutes.
[2024-05-09T16:28:03Z INFO  openconnect::ffi] Idle timeout is 180 minutes.
[2024-05-09T16:28:03Z WARN  openconnect::ffi] No MTU received. Calculated 1422 for ESP tunnel
[2024-05-09T16:28:03Z INFO  openconnect::ffi] POST https://REDACTEDADDRESS/ssl-vpn/hipreportcheck.esp
[2024-05-09T16:28:03Z INFO  openconnect::ffi] ESP session established with server
[2024-05-09T16:28:03Z INFO  openconnect::ffi] ESP tunnel connected; exiting HTTPS mainloop.
Warning: /16 as prefix is invalid, only /32 (or none) is supported.
Warning: /16 as prefix is invalid, only /32 (or none) is supported.
Warning: /16 as prefix is invalid, only /32 (or none) is supported.
Warning: /16 as prefix is invalid, only /32 (or none) is supported.
Warning: /16 as prefix is invalid, only /32 (or none) is supported.
Warning: /16 as prefix is invalid, only /32 (or none) is supported.
[2024-05-09T16:28:03Z INFO  openconnect::ffi] Using vhost-net for tun acceleration, ring size 32
[2024-05-09T16:28:03Z INFO  openconnect::vpn] Connected to VPN, pipe_fd: 12
[2024-05-09T16:28:03Z INFO  gpclient::connect] Wrote PID 12891 to /var/run/gpclient.lock

Those warnings make no sense, but I'm not sure which component they're coming from, the routes get created. Looking at the routes on the system, I think it's 1) not replacing the default route (I can research that) and 2) it's adding the whitelisted routes (going through my local gateway named sr66-prosafe-00). Ultimately, I cannot ping VPN resources by IP:

surfrock66@sr66-vdi-02:~$ route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         sr66-prosafe-00 0.0.0.0         UG    100    0        0 ens18
10.2.0.0        sr66-prosafe-00 255.255.0.0     UG    0      0        0 ens18
10.3.0.0        sr66-prosafe-00 255.255.0.0     UG    0      0        0 ens18
10.4.0.0        0.0.0.0         255.255.0.0     U     0      0        0 ens18
10.4.0.0        0.0.0.0         255.255.0.0     U     100    0        0 ens18
10.5.0.0        sr66-prosafe-00 255.255.0.0     UG    0      0        0 ens18
10.6.0.0        sr66-prosafe-00 255.255.0.0     UG    0      0        0 ens18
dns0.tun0       0.0.0.0         255.255.255.255 UH    0      0        0 tun0
dns1.tun0       0.0.0.0         255.255.255.255 UH    0      0        0 tun0
10.99.0.0       sr66-prosafe-00 255.255.0.0     UG    0      0        0 ens18
mail.DOMAIN.TLD      10.4.1.254 255.255.255.255     UG    100      0        0 ens18

Turning off the VPN, these are my expected routes:

surfrock66@sr66-vdi-02:~$ route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         sr66-prosafe-00 0.0.0.0         UG    100    0        0 ens18
10.4.0.0        0.0.0.0         255.255.0.0     U     100    0        0 ens18

if I connect to the vpn without the script, I get this:

The redacted names are my domain controllers (and DNS servers), and the 172 is the correct IP for my VPN subnet.

I'm not sure where the issue is; is there something wrong with the way routes are handled when doing vpn-slice? I wouldn't think there would need to be additional default route commands in my script, but does the utilization of vpn-slice necessitate some other routing commands?

[yuezk]

Hi @surfrock66 sorry for the late reply.

It looks like a problem regarding the vpn-slice package. I'm not familiar with it, you may need to report it to dlenski/vpn-slice

The client should support passing a command as the --script parameter, which has been implemented in the dev branch. I will keep this issue open until I release it.

[yuezk]

Passing command as the --script is supported in 2.3.0, closing.