INTL 3:770/1 3:770/3
REPLYADDR no_reply@dipl-ing-kessler.de
REPLYTO 3:770/3.0 UUCP
MSGID: fb808987
REPLY: a0e10e9d
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
> wrote:
>> On Thu, 11 Apr 2024 18:43:19 -0000 (UTC) William Unruh wrote:
>>
>>> On 2024-04-09, Markus Robert Kessler
>>> 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: 10/0 1 15/0 90/1 103/705 105/81 106/201 128/260 129/305 135/220
SEEN-BY: 135/225 153/757 7715 218/0 1 601 700 840 870 930 220/70 221/1
SEEN-BY: 221/6 360 226/17 30 100 227/114 229/110 111 112 113 200 206
SEEN-BY: 229/307 317 400 426 428 470 550 616 664 700 240/1120 266/512
SEEN-BY: 267/800 282/1038 291/111 292/854 301/1 113 812 310/31 320/219
SEEN-BY: 322/757 335/364 341/66 342/200 396/45 460/58 633/280 712/848
SEEN-BY: 770/1 3 100 330 340 772/210 220 230 5020/400 1042 5058/104
SEEN-BY: 5075/35
PATH: 770/3 1 218/840 221/6 301/1 218/700 229/426
|
