Hi all,
I am running several machines for connecting to our company intranet,
using openconnect VPN.
So far, it works. But:
The debian based systems, i.e. Ubuntu 23.10 and Raspbian OS show up
hundreds of routes after connect. And it's clear that they are brought
to my client via server-initiated 'push route ...' command.
Some of these routes are conflicting with machines in my home office
net.
So, I'd like to skip getting such a huge amount of useless routes. I
want to set the routing by my own script, instead.
The funny thing is that a Redhat-based OS, Mageia 9 (64 and 32 bit),
does not behave like this, instead only the default route (10.0.0.0/8)
is sent through tun0.
So, maybe this is a matter of compilation?
Or something else to look after, to prevent openconnect from doing this?
Maybe someone can give a hint where to download the openconnect sources
for Ubuntu?
Thanks in advance!
Best regards,
Markus
Hello all,...
here is what I've done in short:
They are stored in ${CISCO_SPLIT_EXC_${i}_ADDR}, and their total number,
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
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
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.
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.
The problem is how do I decide what to include if I want to use a number
of different vpns.
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?
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.
Would openconnect clean up the addresses that go through the tun when it
is stopped?
_
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.
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
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'
Agreed. I meantI 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
CISCO_INC_EXC at the end.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.
(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
Agreed. I meant
255.255.0.0 Is that 16 or 32 ?
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.
Agreed. I meant 255.255.0.0 Is that 16 or 32 ?
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
Anyway, it seems to be working.
CISCO_SPLIT_INC_${i}_{ADDR,MASK,MASKLEN) triplets with an appropriateWhat 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_INC_EXC at the end.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?
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?
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 :-)
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:
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
| Sysop: | Weed Hopper |
|---|---|
| Location: | Clearwater, FL |
| Users: | 14 |
| Nodes: | 6 (0 / 6) |
| Uptime: | 231:07:47 |
| Calls: | 55 |
| Calls today: | 1 |
| Files: | 50,127 |
| D/L today: |
29 files (3,538K bytes) |
| Messages: | 275,355 |