INTL 3:770/1 3:770/3   
   REPLYADDR no_reply@dipl-ing-kessler.de   
   REPLYTO 3:770/3.0 UUCP   
   MSGID:  611f77ed   
   REPLY:  6242c670   
   PID: SoupGate-Win32 v1.05   
   XPost: alt.os.linux.ubuntu, alt.os.linux.mageia   
      
   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'   
      
   > 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   
      
   > 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_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?   
      
   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   
      
   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