@MSGID: 1@dont-email.me> fb808987
@REPLY: 1@dont-email.me> a0e10e9d
@INTL 3:770/1 3:770/3
@REPLYADDR no_reply@dipl-ing-kessler.de
@REPLYTO 3:770/3.0 UUCP
@PID: SoupGate-Win32 v1.05
XPost: alt.os.linux.ubuntu, alt.os.linux.mageia

On Fri, 12 Apr 2024 18:52:37 -0000 (UTC) William Unruh wrote:

> On 2024-04-12, Markus Robert Kessler <no_reply@dipl-ing-kessler.de>
> wrote:
>> On Thu, 11 Apr 2024 18:43:19 -0000 (UTC) William Unruh wrote:
>>
>>> On 2024-04-09, Markus Robert Kessler <no_reply@dipl-ing-kessler.de>
>>> wrote:
>>>> Hello all,
>>>>
>>>> here is what I`ve done in short:
>>> ...
>>>>
>>>> They are stored in ${CISCO_SPLIT_EXC_${i}_ADDR}, and their total
>>>> number,
>>>
>>>  And ${CISCO_SPLIT_EXC_${i}_MASK } and
>>>  ${${CISCO_SPLIT_EXC_${i}_MASKLEN}
>>>
>>>
>>> My problem is that what I get pushed is CISCO_SPLIT_EXC_0_ADDR=0.0.0.0
>>> CISCO_SPLIT_EXC_0_MASK=255.255.255.255 CISCO_SPLIT_EXC_0_MASKLEN=32
>>>  Ie, everything gets routed through tun, which is completely nuts.
>>
>> Routes named as `EXC` should be EXcluded from being routed through tun.
>> Don`t know why the above behaves like that. Maybe there`s another entry
>> for that reading `INC`
>
> Yes, there is a similar set of entries with INC which I should have been
> using. It is exactly same as EXC but with INC instead.
>>
>>> I presume that I could just have a file with the list of addresses I
>>> want sent through the tun, and include that in vpnc-script.
>>
>> You could set the variables / source the relevant file, and either
>> overwrite the pushed variables and set new max index,
>> or append them to the inherited ones and adapt max index / vector size
>>
>>> The problem is how do I decide what to include if I want to use a
>>> number of different vpns.
>>
>> You could copy and create different sections for every vpn.
>>
>> Or, use vpnc-script as a `wrapper` file, which calls, for instance,
>> vpnc-script.ubc.ca for CISCO_DEF_DOMAIN=ubc.ca and so on. Make sure
>> that all env are available in the target scripts
>>
>>> Is it reasonably robust to use CISCO_DEF_DOMAIN=ubc.ca to decide which
>>> routing  address file to use
>>>
>>> Also, would a mask of 0.0.255.255 be MASKLENGTH of 32 or 16?
>>
>> 32, but this mask hardly makes sense
> Agreed. I meant 255.255.0.0 Is that 16 or 32 ?

As Dave already mentioned, this should be 16

> Anyway, it seems to be working.
>
>
>
>>> What I am thinking of is putting a line source
>>> routes.${CISCO_DEF_DOMAIN}
>>> at the beginning of the vpnc-script file
>>>
>>> and have that file be full of the
>>> CISCO_SPLIT_EXC_${i}_{ADDR,MASK,MASKLEN) triplets with an appropriate
> CISCO_SPLIT_INC_${i}_{ADDR,MASK,MASKLEN) triplets with an appropriate
>>>  CISCO_SPLIT_EXC at the end.
> CISCO_INC_EXC at the end.
>>> (with a test to make sure that the file exists before sourcing it)
>>>
>>> That would seem to be much easier than the massive rewrite you did.
>>
>> No big rewrite from my side. To fit my needs it was enough to just add
>> ONE line ( CISCO_SPLIT_EXC=`` ) It just works for my company network
>>
>>> Would openconnect clean up the addresses that go through the tun when
>>> it is stopped?
>
> Yes, and it does work. All the tun routes disappear when I close
> openconnect.
> Is there some openconnect command that tells the running version to
> quit?

No, not from openconnect`s side.

Instead, when openconnect runs in foreground mode ( i.e. not being started
with -b ), it can be terminated cleanly with CTRL-C.

Alternatively, vpnc-disconnect ( out of vpnc package ) can be used, as
long as openconnect writes the same pid file, which vpnc-disconnect takes
the pid number from to ( also cleanly ) terminate the process.

In my case, I start it like so:

sudo openconnect --pid-file /var/run/vpnc.pid -b ...
( on debian based systems the path and filename may differ ),
hence, I can easily end it with vpnc-disconnect.

>
>> Openconnect is calling vpnc-script for several reasons, see line
>>
>> #* reason                       -- why this script was called, one of:
>> pre-init connect disconnect reconnect attempt-reconnect
>>
>> So, when openconnect is cleanly terminating (not kill -9 ...), it will
>> finally invoke vpnc-script with cause `disconnect` and the original
>> route is being restored
>>
>>>  _
>>>
>>>
>>>> i.e. the vector size is stored in $CISCO_SPLIT_EXC.
>>>>
>>>> To prevent openconnect from accepting all that trash, I could easily
>>>> set this vector to empty, i.e. include
>>>>
>>>> CISCO_SPLIT_EXC=``
>>>>
>>>> as one the first commands in vpnc-script file, and, that`s it!
>>>>
>>>> The reason why Suse`s approach, which I took to build my own vpnc rpm
>>>> from, and from which vpnc-script is taken from, does not accept all
>>>> that routes, is that in this version the whole section is not
>>>> included.
>>>>
>>>> If you are interested in seeing how they differ, you may have a look
>>>> at the vimdiff file I created:
>>>>
>>>> https://www.dipl-ing-kessler.de/tmp/vpnc-script
>>>
>>> White letters on light green is almost unreadable.
>>
>> Yes, it`s never easy to find a colorscheme in vimdiff which displays
>> everything perfectly. But you can always select the relevant section to
>> have blue on white text or vice versa
>>
>>>> This afternoon I tested above solution on Raspbian OS and it worked
>>>> instantly.
>>>>
>>>> It took me some time to find out, but it was worth every minute :-)

Best regards,

Markus

--- SoupGate-Win32 v1.05
 * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
SEEN-BY: 50/109 153/757 218/840 840 220/70 221/1 6
360 226/17 100 240/1120
SEEN-BY: 267/800 301/1 113 812 310/31 335/364
341/66 463/68 467/888 633/280
SEEN-BY: 712/848 770/1 3 100 330 340 772/210 220
230 3634/12 5001/100 5005/49
SEEN-BY: 5019/40 5020/715 848 1042 4441 12000
5030/49 722 1081 1474 5054/8
SEEN-BY: 5058/104 5061/133 5075/128
@PATH: 770/3 1 218/840 221/6 301/1 5020/1042 4441