Issue with "Connect Banner:" about vpn-slice HOT 19 CLOSED

I use ArchLinux. Also, above mikeoregan66 already stated he uses "Fedora Core 32", and that his friend used "Ubuntu" -- having exactly the same problem.

Output of -vv --dump is exactly the same for working 0.13 and non-working 0.14.
But, maybe, looking at the composition of variables you will have some insights.
All IPs are obfuscated on the mask boundary, to keep them more or less reasonable:

Called by /usr/bin/openconnect (PID 39566) with environment variables for vpnc-script:
  reason                  => reason=<reasons.connect: 2>
  VPNGATEWAY              => gateway=IPv4Address('11.11.222.11')
  TUNDEV                  => tundev='tun0'
  CISCO_DEF_DOMAIN        => domain=['city.company.com']
  CISCO_BANNER            => banner='Welcome to Company Network!\n\nThis service is restricted to authorized users. If unauthorized, please terminate access now.\n\nPlease be informed that Compliance checks are executed in case you connect from Windows OS based machines. The following will be checked at your workstation:\n\n- Status of OS updates\n- Status of Antivirus database updates\n\nBy clicking Accept, you accept the terms and agree to provide the above mentioned data. Any future login attempt indicates your acceptance of this information.\n'
  INTERNAL_IP4_ADDRESS    => myaddr=IPv4Address('172.33.66.55')
  INTERNAL_IP4_MTU        => mtu=1390
  INTERNAL_IP4_NETMASK    => netmask=IPv4Address('255.255.248.0')
  INTERNAL_IP4_NETMASKLEN => netmasklen=21
  INTERNAL_IP4_NETADDR    => network=IPv4Network('172.33.64.0/21')
  INTERNAL_IP4_DNS        => dns=[IPv4Address('172.30.18.12'), IPv4Address('172.30.137.40')]
  CISCO_SPLIT_INC         => nsplitinc=13
  IDLE_TIMEOUT            => idle_timeout=1800
  CISCO_*SPLIT_INC_*      => splitinc=[IPv4Network('72.111.2.85/32'),
    IPv4Network('172.24.0.0/16'), IPv4Network('10.169.118.192/26'),
    IPv4Network('10.249.134.0/23'), IPv4Network('10.28.0.0/23'),
    IPv4Network('10.2.200.0/23'), IPv4Network('10.101.193.0/25'),
    IPv4Network('172.11.0.0/16'), IPv4Network('172.16.0.0/16'),
    IPv4Network('172.35.0.0/16'), IPv4Network('172.47.0.0/16'),
    IPv4Network('172.40.0.0/15'), IPv4Network('172.20.0.0/15')]

If you know a way to run and record full line-tracing of Python program -- I can send you the results privately by mail, gpg-encrypted by your public key. In such traces I will only obfuscate username and password, but rest of network-layout info will be left intact.
Maybe such trace could help you determine at which point everything broke.

from vpn-slice.

Output of -vv --dump is exactly the same for working 0.13 and non-working 0.14.
But, maybe, looking at the composition of variables you will have some insights.
All IPs are obfuscated on the mask boundary, to keep them more or less reasonable:

Thank you. This is a helpful sanity check.

Long story short: pull the latest version, 9b1393e. (I force-repushed it with an earlier commit 7152903 right after the botched merge 8c6110b, in the hopes that it will prevent anyone from using an intermediary broken revision.)

As you observed above, that merge included an indentation mistake which caused a syntax error. However, that merge also included a second indentation mistake which did not cause a syntax error, but which caused vpn-slice to silently exit before doing any of the actual work. 🤦‍♂️

If anyone wants to write a unit and integration test framework to prevent me from repeating any of this, it'd be most welcome. 😎

from vpn-slice.

Hooray! It works now. I'm truly thankful for your patience on solving others' problems!

Not sure if we must wait on @mikeoregan66 testing results, considering he joined GitHub 6 days ago only to submit this issue...

P.S. About "integration test framework". Ha, you make it sound like something simple everybody can do, and you simply don't have time :D Isn't it misleading, considering you must mock networking outside openconnect, to truly test vpn-slice interaction inside openconnect. And that's only if you forget about kernel operations and sudo access... In general it requires very extensive docker setup with server and client containers, with both of them inside another container with correct setup of transport network and running test scenarious. However you look at that -- it's rather niche and requires "special" devops talents and much time for system fiddling :)

from vpn-slice.

this message seems to be swallowed by the script and disrupts behaviour.

Hmmm… don't think so. Not displaying the banner message does not affect the interaction with the server in any way. vpn-slice ignores that message, because it's pointless boilerplate… but you can make it show it if you really want with vpn-slice --banner.

To get more information about what's really going on in terms of the routing information sent from the server, add -v --dump to the command-line used to invoke vpn-slice, e.g. openconnect -s "vpn-slice -v --dump host1 host2 host3"

from vpn-slice.

Apologies, I'm pretty new to vpn-slice and didn't know about dump. And yes, you are completely correct it doesn't appear to be the banner. This was a red herring as it was the only difference I could see and as I said I am new to vpn-slice.

Below is the output from the dump but with all the ip addresses and company name slightly obfuscated.

command simplified to a single host.

sudo openconnect acmeremoteaccess.somecorporation.com -g ACMECONNECT2.0 -u [email protected] --no-dtls -s '/usr/local/bin/vpn-slice --verbose --banner --dump clarity.at.acme'

dump

POST https://acmeremoteaccess.somecorporation.com/ACMECONNECT2.0
Connected to 1.2.0.31:443
SSL negotiation with acmeremoteaccess.somecorporation.com
Connected to HTTPS on acmeremoteaccess.somecorporation.com with ciphersuite (TLS1.2)-(RSA)-(AES-128-CBC)-(SHA1)
XML POST enabled
Please enter your details.
Password:
POST https://acmeremoteaccess.somecorporation.com/
Got CONNECT response: HTTP/1.2.200 OK
CSTP connected. DPD 30, Keepalive 20
Connected as 1.2.135.161, using SSL, with DTLS disabled
Called by /usr/sbin/openconnect (PID 4377) with environment variables for vpnc-script:
reason => reason=<reasons.pre_init: 1>
VPNGATEWAY => gateway=IPv4Address('1.2.0.31')
CISCO_DEF_DOMAIN => domain=['somecorporation.com']
CISCO_BANNER => banner='Access to this device is limited to authorised personnel only. Unauthorised access or use of this device may be subject to civil or criminal prosecution.\n'
INTERNAL_IP4_ADDRESS => myaddr=IPv4Address('1.2.135.161')
INTERNAL_IP4_MTU => mtu=1379
INTERNAL_IP4_NETMASK => netmask=IPv4Address('1.2.224.0')
INTERNAL_IP4_NETMASKLEN => netmasklen=19
INTERNAL_IP4_NETADDR => network=IPv4Network('1.2.128.0/19')
INTERNAL_IP4_DNS => dns=[IPv4Address('1.2.5.23'), IPv4Address('1.2.212.78')]
INTERNAL_IP4_NBNS => nbns=[IPv4Address('1.2.5.23'), IPv4Address('1.2.216.76')]
CISCO_SPLIT_INC => nsplitinc=140
IDLE_TIMEOUT => idle_timeout=1800
CISCO_SPLIT_INC_* => splitinc=[IPv4Network('1.2.195.83/32'), IPv4Network('1.2.157.54/32'), IPv4Network('1.2.175.137/32'), IPv4Network('1.2.207.118/32'), IPv4Network('1.2.91.168/32'), IPv4Network('1.2.91.95/32'), IPv4Network('1.2.207.142/32'), IPv4Network('1.2.204.192/32'), IPv4Network('1.2.13.247/32'), IPv4Network('1.2.194.243/32'), IPv4Network('1.2.128.48/32'), IPv4Network('1.2.174.121/32'), IPv4Network('1.2.69.40/32'), IPv4Network('1.2.102.34/32'), IPv4Network('1.2.73.83/32'), IPv4Network('1.2.86.16/32'), IPv4Network('1.2.230.32/32'), IPv4Network('1.2.96.188/32'), IPv4Network('1.2.53.252/32'), IPv4Network('1.2.162.122/32'), IPv4Network('1.2.179.226/32'), IPv4Network('1.2.217.128/25'), IPv4Network('1.2.14.180/32'), IPv4Network('1.2.230.80/32'), IPv4Network('1.2.51.49/32'), IPv4Network('1.2.97.79/32'), IPv4Network('1.2.63.229/32'), IPv4Network('1.2.240.37/32'), IPv4Network('1.2.11.178/32'), IPv4Network('1.2.17.244/32'), IPv4Network('1.2.57.205/32'), IPv4Network('1.2.68.57/32'), IPv4Network('1.2.106.20/32'), IPv4Network('1.2.212.171/32'), IPv4Network('1.2.118.239/32'), IPv4Network('1.2.191.255/32'), IPv4Network('1.2.190.0/26'), IPv4Network('1.2.35.165/32'), IPv4Network('1.2.170.78/32'), IPv4Network('1.2.170.98/32'), IPv4Network('1.2.170.121/32'), IPv4Network('1.2.170.19/32'), IPv4Network('1.2.205.85/32'), IPv4Network('1.2.203.212/32'), IPv4Network('1.2.123.189/32'), IPv4Network('1.2.172.179/32'), IPv4Network('1.2.49.55/32'), IPv4Network('1.2.229.238/32'), IPv4Network('1.2.58.86/32'), IPv4Network('1.2.104.2/32'), IPv4Network('1.2.224.0/22'), IPv4Network('1.2.12.0/22'), IPv4Network('1.2.116.0/22'), IPv4Network('1.2.100.0/22'), IPv4Network('1.2.76.0/22'), IPv4Network('1.2.72.0/22'), IPv4Network('1.2.132.0/22'), IPv4Network('1.2.40.0/22'), IPv4Network('1.2.136.18/32'), IPv4Network('1.2.136.15/32'), IPv4Network('1.2.136.14/32'), IPv4Network('1.2.144.39/32'), IPv4Network('1.2.144.35/32'), IPv4Network('1.2.144.34/32'), IPv4Network('1.2.88.146/32'), IPv4Network('1.2.90.55/32'), IPv4Network('1.2.238.134/32'), IPv4Network('1.2.238.129/32'), IPv4Network('1.2.175.128/26'), IPv4Network('1.2.192.0/24'), IPv4Network('1.2.234.0/24'), IPv4Network('1.2.248.0/24'), IPv4Network('1.2.114.64/26'), IPv4Network('1.2.247.0/24'), IPv4Network('1.2.226.0/24'), IPv4Network('1.2.227.128/32'), IPv4Network('1.2.252.22/32'), IPv4Network('1.2.250.187/32'), IPv4Network('1.2.204.157/32'), IPv4Network('1.2.204.160/32'), IPv4Network('1.2.116.136/32'), IPv4Network('1.2.20.112/32'), IPv4Network('1.2.114.116/32'), IPv4Network('1.2.143.232/32'), IPv4Network('1.2.96.0/22'), IPv4Network('1.2.97.0/24'), IPv4Network('1.2.0.0/19'), IPv4Network('1.2.248.26/32'), IPv4Network('1.2.248.25/32'), IPv4Network('1.2.248.19/32'), IPv4Network('1.2.248.16/32'), IPv4Network('1.2.157.47/32'), IPv4Network('1.2.134.192/28'), IPv4Network('1.2.150.192/28'), IPv4Network('1.2.72.50/32'), IPv4Network('1.2.96.41/32'), IPv4Network('1.2.97.30/32'), IPv4Network('1.2.138.159/32'), IPv4Network('1.2.172.252/32'), IPv4Network('1.2.207.182/32'), IPv4Network('1.2.86.45/32'), IPv4Network('1.2.166.123/32'), IPv4Network('1.2.168.0/23'), IPv4Network('1.2.170.0/23'), IPv4Network('1.2.186.0/23'), IPv4Network('1.2.196.0/24'), IPv4Network('1.2.25.141/32'), IPv4Network('1.2.94.112/32'), IPv4Network('1.2.178.253/32'), IPv4Network('1.2.73.58/32'), IPv4Network('1.2.57.109/32'), IPv4Network('1.2.116.46/32'), IPv4Network('1.2.143.203/32'), IPv4Network('1.2.6.227/32'), IPv4Network('1.2.122.9/32'), IPv4Network('1.2.120.50/32'), IPv4Network('1.2.149.82/32'), IPv4Network('1.2.102.86/32'), IPv4Network('1.2.13.140/32'), IPv4Network('1.2.241.60/32'), IPv4Network('1.2.183.69/32'), IPv4Network('1.2.89.0/32'), IPv4Network('1.2.151.33/32'), IPv4Network('1.2.184.251/32'), IPv4Network('1.2.244.226/32'), IPv4Network('1.2.25.142/32'), IPv4Network('1.2.14.52/32'), IPv4Network('1.2.208.0/23'), IPv4Network('1.2.128.0/17'), IPv4Network('1.2.64.0/18'), IPv4Network('1.2.32.0/19'), IPv4Network('1.2.16.0/20'), IPv4Network('1.2.8.0/21'), IPv4Network('1.2.4.0/22'), IPv4Network('1.2.2.0/23'), IPv4Network('1.2.0.0/12'), IPv4Network('1.2.236.0/23'), IPv4Network('1.2.44.0/22'), IPv4Network('1.2.41.81/32'), IPv4Network('1.2.0.0/8')]
Called by /usr/sbin/openconnect (PID 4377) with environment variables for vpnc-script:
reason => reason=<reasons.connect: 2>
VPNGATEWAY => gateway=IPv4Address('1.2.0.31')
TUNDEV => tundev='tun0'
CISCO_DEF_DOMAIN => domain=['somecorporation.com']
CISCO_BANNER => banner='Access to this device is limited to authorised personnel only. Unauthorised access or use of this device may be subject to civil or criminal prosecution.\n'
INTERNAL_IP4_ADDRESS => myaddr=IPv4Address('1.2.135.161')
INTERNAL_IP4_MTU => mtu=1379
INTERNAL_IP4_NETMASK => netmask=IPv4Address('1.2.224.0')
INTERNAL_IP4_NETMASKLEN => netmasklen=19
INTERNAL_IP4_NETADDR => network=IPv4Network('1.2.128.0/19')
INTERNAL_IP4_DNS => dns=[IPv4Address('1.2.5.23'), IPv4Address('1.2.212.78')]
INTERNAL_IP4_NBNS => nbns=[IPv4Address('1.2.5.23'), IPv4Address('1.2.216.76')]
CISCO_SPLIT_INC => nsplitinc=140
IDLE_TIMEOUT => idle_timeout=1800
CISCO_SPLIT_INC_* => splitinc=[IPv4Network('1.2.195.83/32'), IPv4Network('1.2.157.54/32'), IPv4Network('1.2.175.137/32'), IPv4Network('1.2.207.118/32'), IPv4Network('1.2.91.168/32'), IPv4Network('1.2.91.95/32'), IPv4Network('1.2.207.142/32'), IPv4Network('1.2.204.192/32'), IPv4Network('1.2.13.247/32'), IPv4Network('1.2.194.243/32'), IPv4Network('1.2.128.48/32'), IPv4Network('1.2.174.121/32'), IPv4Network('1.2.69.40/32'), IPv4Network('1.2.102.34/32'), IPv4Network('1.2.73.83/32'), IPv4Network('1.2.86.16/32'), IPv4Network('1.2.230.32/32'), IPv4Network('1.2.96.188/32'), IPv4Network('1.2.53.252/32'), IPv4Network('1.2.162.122/32'), IPv4Network('1.2.179.226/32'), IPv4Network('1.2.217.128/25'), IPv4Network('1.2.14.180/32'), IPv4Network('1.2.230.80/32'), IPv4Network('1.2.51.49/32'), IPv4Network('1.2.97.79/32'), IPv4Network('1.2.63.229/32'), IPv4Network('1.2.240.37/32'), IPv4Network('1.2.11.178/32'), IPv4Network('1.2.17.244/32'), IPv4Network('1.2.57.205/32'), IPv4Network('1.2.68.57/32'), IPv4Network('1.2.106.20/32'), IPv4Network('1.2.212.171/32'), IPv4Network('1.2.118.239/32'), IPv4Network('1.2.191.255/32'), IPv4Network('1.2.190.0/26'), IPv4Network('1.2.35.165/32'), IPv4Network('1.2.170.78/32'), IPv4Network('1.2.170.98/32'), IPv4Network('1.2.170.121/32'), IPv4Network('1.2.170.19/32'), IPv4Network('1.2.205.85/32'), IPv4Network('1.2.203.212/32'), IPv4Network('1.2.123.189/32'), IPv4Network('1.2.172.179/32'), IPv4Network('1.2.49.55/32'), IPv4Network('1.2.229.238/32'), IPv4Network('1.2.58.86/32'), IPv4Network('1.2.104.2/32'), IPv4Network('1.2.224.0/22'), IPv4Network('1.2.12.0/22'), IPv4Network('1.2.116.0/22'), IPv4Network('1.2.100.0/22'), IPv4Network('1.2.76.0/22'), IPv4Network('1.2.72.0/22'), IPv4Network('1.2.132.0/22'), IPv4Network('1.2.40.0/22'), IPv4Network('1.2.136.18/32'), IPv4Network('1.2.136.15/32'), IPv4Network('1.2.136.14/32'), IPv4Network('1.2.144.39/32'), IPv4Network('1.2.144.35/32'), IPv4Network('1.2.144.34/32'), IPv4Network('1.2.88.146/32'), IPv4Network('1.2.90.55/32'), IPv4Network('1.2.238.134/32'), IPv4Network('1.2.238.129/32'), IPv4Network('1.2.175.128/26'), IPv4Network('1.2.192.0/24'), IPv4Network('1.2.234.0/24'), IPv4Network('1.2.248.0/24'), IPv4Network('1.2.114.64/26'), IPv4Network('1.2.247.0/24'), IPv4Network('1.2.226.0/24'), IPv4Network('1.2.227.128/32'), IPv4Network('1.2.252.22/32'), IPv4Network('1.2.250.187/32'), IPv4Network('1.2.204.157/32'), IPv4Network('1.2.204.160/32'), IPv4Network('1.2.116.136/32'), IPv4Network('1.2.20.112/32'), IPv4Network('1.2.114.116/32'), IPv4Network('1.2.143.232/32'), IPv4Network('1.2.96.0/22'), IPv4Network('1.2.97.0/24'), IPv4Network('1.2.0.0/19'), IPv4Network('1.2.248.26/32'), IPv4Network('1.2.248.25/32'), IPv4Network('1.2.248.19/32'), IPv4Network('1.2.248.16/32'), IPv4Network('1.2.157.47/32'), IPv4Network('1.2.134.192/28'), IPv4Network('1.2.150.192/28'), IPv4Network('1.2.72.50/32'), IPv4Network('1.2.96.41/32'), IPv4Network('1.2.97.30/32'), IPv4Network('1.2.138.159/32'), IPv4Network('1.2.172.252/32'), IPv4Network('1.2.207.182/32'), IPv4Network('1.2.86.45/32'), IPv4Network('1.2.166.123/32'), IPv4Network('1.2.168.0/23'), IPv4Network('1.2.170.0/23'), IPv4Network('1.2.186.0/23'), IPv4Network('1.2.196.0/24'), IPv4Network('1.2.25.141/32'), IPv4Network('1.2.94.112/32'), IPv4Network('1.2.178.253/32'), IPv4Network('1.2.73.58/32'), IPv4Network('1.2.57.109/32'), IPv4Network('1.2.116.46/32'), IPv4Network('1.2.143.203/32'), IPv4Network('1.2.6.227/32'), IPv4Network('1.2.122.9/32'), IPv4Network('1.2.120.50/32'), IPv4Network('1.2.149.82/32'), IPv4Network('1.2.102.86/32'), IPv4Network('1.2.13.140/32'), IPv4Network('1.2.241.60/32'), IPv4Network('1.2.183.69/32'), IPv4Network('1.2.89.0/32'), IPv4Network('1.2.151.33/32'), IPv4Network('1.2.184.251/32'), IPv4Network('1.2.244.226/32'), IPv4Network('1.2.25.142/32'), IPv4Network('1.2.14.52/32'), IPv4Network('1.2.208.0/23'), IPv4Network('1.2.128.0/17'), IPv4Network('1.2.64.0/18'), IPv4Network('1.2.32.0/19'), IPv4Network('1.2.16.0/20'), IPv4Network('1.2.8.0/21'), IPv4Network('1.2.4.0/22'), IPv4Network('1.2.2.0/23'), IPv4Network('1.2.0.0/12'), IPv4Network('1.2.236.0/23'), IPv4Network('1.2.44.0/22'), IPv4Network('1.2.41.81/32'), IPv4Network('1.2.0.0/8')]

from vpn-slice.

As I said this is Fedora Core 32, the various versions below.

$ openconnect --version
OpenConnect version v8.10
Using GnuTLS 3.6.13. Features present: TPM, TPMv2, PKCS#11, RSA software token, HOTP software token, TOTP software token, Yubikey OATH, System keys, DTLS, ESP
Supported protocols: anyconnect (default), nc, gp, pulse
$
$ vpn-slice --version
vpn-slice 0.14.1
$
$ python3 --version
Python 3.8.2
$

from vpn-slice.

command simplified to a single host.

sudo openconnect acmeremoteaccess.somecorporation.com -g ACMECONNECT2.0 -u [email protected] --no-dtls -s '/usr/local/bin/vpn-slice --verbose --banner --dump clarity.at.acme'

dump

Okay, the --dump -v output looks normal. You get an IP address, a netmask, DNS servers, and a huge number of routes.

Okay, well, that all looks normal and fine. What is it that you expect to be working which isn't working here?

You cut off the log right where it might get interesting. It should then print…

 Looking up 1 hosts using VPN DNS servers…
  my.acme.host = 1.2.3.4
Added hostnames and aliases for 3 hosts to /etc/hosts (<-- includes the DNS servers)

Does it?

Does the DNS lookup work? Does it add my.acme.host to /etc/hosts? Can you ping it?

from vpn-slice.

Hi and thanks for your time on this, I appreciate it and really like vpn-slice, so thanks for that too.

As to your question, no, that's exactly what I expected to see too but no, it does not output that it added any hosts to /etc/hosts. I did not cut the log off, that's all of it. What you describe is exactly what I used to see when I was on Fedora 30, before I upgraded to 32. I have a colleague who says the same thing happened to him recently when he upgraded to the latest Ubuntu.

I manually checked /etc/hosts and nothing has been added. I cannot reach those hosts/targets by ping or any other method (unless I remove vpn-slice when they work as expected obviously).

from vpn-slice.

As to your question, no, that's exactly what I expected to see too but no, it does not output that it added any hosts to /etc/hosts. I did not cut the log off, that's all of it.

Huh. I am guessing what has happened is that the DNS lookup is running in the background, and hanging, which is why the script never continues.

INTERNAL_IP4_DNS => dns=[IPv4Address('1.2.5.23'), IPv4Address('1.2.212.78')]

Can you verify that routes for the two DNS servers have been added, via ip route? You should see something like…

$ ip route
1.2.5.23/32 dev vpn0
1.2.212.78/32 dev vpn0

Assuming they have been added, can you ping the DNS servers by IP?

Also please check that the route for the external address of the VPN gateway has not been incorrectly routed through the VPN itself. The gateway address (VPNGATEWAY => gateway=IPv4Address('1.2.0.31')) should have a /32 route to your "real" network adapter, e.g. wlan0 or eth0 or whatever.

I manually checked /etc/hosts and nothing has been added. I cannot reach those hosts/targets by ping or any other method (unless I remove vpn-slice when they work as expected obviously).

Right, the hosts can't be added until they've been looked up on the VPN's DNS servers, and the DNS requests are evidently hanging.

from vpn-slice.

Huh. I am guessing what has happened is that the DNS lookup is running in the background, and hanging, which is why the script never continues.

INTERNAL_IP4_DNS => dns=[IPv4Address('1.2.5.23'), IPv4Address('1.2.212.78')]

Can you verify that routes for the two DNS servers have been added, via ip route? You should see something like…

$ ip route
1.2.5.23/32 dev vpn0
1.2.212.78/32 dev vpn0

It doesn't look like it. Only two routes are returned and both are locals (192.168. ...) as opposed to 147 routes when I start the vpn without vpn-slice

Assuming they have been added, can you ping the DNS servers by IP?

As I said I don't believe they've been added and pinging them gets 100% packet loss.

Also please check that the route for the external address of the VPN gateway has not been incorrectly routed through the VPN itself. The gateway address (VPNGATEWAY => gateway=IPv4Address('1.2.0.31')) should have a /32 route to your "real" network adapter, e.g. wlan0 or eth0 or whatever.

I manually checked /etc/hosts and nothing has been added. I cannot reach those hosts/targets by ping or any other method (unless I remove vpn-slice when they work as expected obviously).

Right, the hosts can't be added until they've been looked up on the VPN's DNS servers, and the DNS requests are evidently hanging.

Again, the route doesn't appear to be there at all.

from vpn-slice.

Same problem here. Tested with both openconnect 8.05 and 8.10.
Older "vpn-slice" 0.11 and 0.13 still work good, but latest 0.14.1.gabb6d2b is not.
Two-stage connection looks like this:

pass workvpn | openconnect --non-inter --passwd-on-stdin --user=myuser --authgroup=mygroup --pfs --no-system-trust --servercert="$fp" --authenticate workserver
export COOKIE='...'
sudo openconnect --non-inter --cookie-on-stdin --pfs --no-system-trust --servercert="$fp" \
  --disable-ipv6 --reconnect-timeout=60 --script='vpn-slice ${workpc_ip}/32 --no-host-names' workserver <<< "${COOKIE:?}"

As you can see, I never used IPv6, and I always expected DNS lookup to be disabled (due to --no-host-names), as I really need nothing beside single IP forwarded and prefer to minimize privacy/security exposure level.
So it does not look like #44 DNS problem, but something else changed in recent code.
My /etc/hosts is empty, my ip route don't have any tun0 routes, and I can't SSH to that IP.

from vpn-slice.

Same problem here. Tested with both openconnect 8.05 and 8.10.
Older "vpn-slice" 0.11 and 0.13 still work good, but latest 0.14.1.gabb6d2b is not.
Two-stage connection looks like this:

@amerlyq, what does adding --dump tell you about the variables incoming to vpn-slice? Do they contain the expected DNS servers?

(Same question for @mikeoregan66.)

As you can see, I never used IPv6, and I always expected DNS lookup to be disabled (due to --no-host-names), as I really need nothing beside single IP forwarded and prefer to minimize privacy/security exposure level.

That is indeed what should happen. You may know this already, but you can also add an /etc/hosts alias for ${workpc_ip} without doing any remote lookup simply by adding workpc=${workpc_ip}, or whatever you want to call it.

from vpn-slice.

In 2c10520, I made it so that specifying verbose twice (e.g. -vv) will make it print each route being added as it's added. Please run with this and cross-check the output against what route/ip route actually shows.

from vpn-slice.

I compared latest master with 0.13

• fixed indent error on __init__.py:417
• -vv / -vv --dump does nothing additional for me, dunno if that works
• ip route is empty as before, nothing to cross-check and compare
• yep, I can add alias to /etc/hosts to point IP to workpc, but the problem is not "/etc/hosts" aliases, but the routes which are not created
• INTERNAL_IP4_DNS contains expected addresses, but why you deem it critical I don't know -- because as I stated above, I don't need DNS and don't expect DNS to work with "--no-host-names".
• --dump output compared is totally identical for 0.13 and 0.14 (beside IP and PID)

I spotted name change for one of env vars in output -- maybe that's the reason nothing works anymore?
CISCO_SPLIT_INC_* => CISCO_*SPLIT_INC_* -- it could be you added IPv6 support and in the process of generalizing some vars were wrongly used/not-used?

from vpn-slice.

• fixed indent error on init.py:417

Yeah, not sure how I borked that. Fixed by force-pushing to 2c10520.

• -vv / -vv --dump does nothing additional for me, dunno if that works

You're telling me that adding --dump to the vpn-slice command line doesn't cause it to print the contents of all the environment variables at each invocation?

• ip route is empty as before, nothing to cross-check and compare

Right. We need to figure out why.

Probably by "nothing additional", you meant that the route-printing in 2c10520 appears to be having no effect… which would be consistent with no routes whatsoever being added.

• INTERNAL_IP4_DNS contains expected addresses, but why you deem it critical I don't know -- because as I stated above, I don't need DNS and don't expect DNS to work with "--no-host-names".

I'm asking because I'm double-checking for evidence that something may have changed on the server side, in the absence of a model for what's changed locally.

• --dump output compared is totally identical for 0.13 and 0.14 (beside IP and PID)

Can you show an (obfuscated as necessary) complete log of the output for reason=connect with --dump -vv?

I spotted name change for one of env vars in output -- maybe that's the reason nothing works anymore?
CISCO_SPLIT_INC_* => CISCO_SPLIT_INC_ -- it could be you added IPv6 support and in the process of generalizing some vars were wrongly used/not-used?

I don't think so. This was my initial thought as well, but I've reviewed these changes pretty carefully… there's nothing that would affect the basic routing setup.

from vpn-slice.

I also should check: @amerlyq and @mikeoregan66, what OSes are you running? I can only test on Linux.

from vpn-slice.

P.S. About "integration test framework". Ha, you make it sound like something simple everybody can do, and you simply don't have time :D

Indeed. The part about me not having time is true… the part about it being simple is not.

Isn't it misleading, considering you must mock networking outside openconnect, to truly test vpn-slice interaction inside openconnect.

I actually think that the mocking of the actual networking is not necessary, at least not to avoid the kind of bugs I appear to be good at introducing here. It should be sufficient to:

1. Mock the input to vpn-slice (via CLI and environment variables passed from OpenConnect)
2. Mock the vpn-slice provider objects (e.g. RouteProvider) to simply log what calls they make.
3. Compare the mocked input with expected output (e.g., if we set CISCO_IP4_ADDRESS=1.2.3.4, then we should get a call to RouteProvider.add_address(tundev, ip_address("1.2.3.4"))) in the logging output.

You are right that this will not get us coverage of the actual interaction with the networking system but it will get us coverage of everything that's within vpn-slice's own control.

If that seems doable and you want to take a crack at it… I'll help however I can :)

from vpn-slice.

Sorry to disappoint you, with my minimalism and absolute control tendencies, the more often something breaks and the deeper I must analyze to fix it -- the more probable I will replace it as whole by 5-line bash script containing only the necessary for me lines to e.g. run vpnc :)

It must be someone benefitting from the most of the features you provide to fit nicely that role of "create initial testframework" -- not even you yourself as developer may fit that role, if half of features were added as fleeting thoughts or when implementing somebody else requests from issues.

On the other hand, considering FOSS being social fenomenon (and sociopatic psychic deviation, not without it :D), your role as BDFL would be working with info pool and splitting tasks to smaller chunks. So that these smaller chunks could exactly fit the "painful necessity" of somebody -- for them to be able to fix/implement one step at a time, directly on top of whatever exists -- resolve their personal pain, gaining achievement. Not easy work at all. For small projects maybe even harder and more time consuming, than simply fixing everything yourself -- treating all issues simply like bugreports without obligation -- i.e. accept fork+PR and fix only if you like it :)

Again, outsourcing even only this part of BDFL workload to somebody else -- requires to find somebody interested in all the features you provide altogether, and therefore be interested to prepare basis for framework for others -- to resolve in this way his own pain of fixing ALL these features altogether and get better soft for himself :)

Maybe, you already know by yourself everything I wrote above, in which case at least thanks for listening my rumbling :D

from vpn-slice.

Hi Folks.

Yes I have taken the latest version and it is working again as before.
Thanks for all your help and effort on this. I appreciate it.

Cheers,
Mike

from vpn-slice.