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.
Maybe someone can give a hint where to download the openconnect
sources for Ubuntu?
On 01.04.2024 um 18:35 Uhr Markus Robert Kessler wrote:
I am running several machines for connecting to our company intranet,
using openconnect VPN.
Invoked directly or via NetworkManager?
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.
NetworkManager has an option to ignore routes from the peer. Connection settings --> IPv4/IPv6 settings --> Routes --> Ignore automatically
obtained routes
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?
So, openconnect does have a (commandline) option, which network
manager invokes to get rid of those routing infos?
I didn't find this switch in the man page yet. Do you know its name?
On 01.04.2024 um 19:30 Uhr Markus Robert Kessler wrote:
So, openconnect does have a (commandline) option, which network
manager invokes to get rid of those routing infos?
I dunno.
I didn't find this switch in the man page yet. Do you know its name?
Sadly, no.
I currently have to invoke openconnect directly because they don't
support TOTP properly yet and it is PITA.
I recommend invoking it via NM whenever possible.
On 01.04.2024 um 18:35 Uhr Markus Robert Kessler wrote:
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.
NetworkManager has an option to ignore routes from the peer.
Connection settings --> IPv4/IPv6 settings --> Routes --> Ignore >automatically obtained routes
In article <uuf01e$2lb63$1@dont-email.me>,
Marco Moock <mm+usenet-es@dorfdsl.de> wrote:
On 01.04.2024 um 18:35 Uhr Markus Robert Kessler wrote:
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.
NetworkManager has an option to ignore routes from the peer.
Connection settings --> IPv4/IPv6 settings --> Routes --> Ignore >>automatically obtained routes
The Cisco ASA at work pushes some routes to my computer when I connect to
it. One of them (for a remote office) uses the same 192.168.1.0/24 subnet
as my home network, so I lose access to my file server, printers, etc. at home when I'm connected to the VPN. I'd been considering moving my home network to a different subnet, but this would be easier...will have to look into it.
I'd still need a route to 172.16.0.0/22. Would this have to be added manually after connecting?
On 2024-04-02, Scott Alfter <scott@alfter.diespammersdie.us> wrote:
In article <uuf01e$2lb63$1@dont-email.me>,
Marco Moock <mm+usenet-es@dorfdsl.de> wrote:
On 01.04.2024 um 18:35 Uhr Markus Robert Kessler wrote:
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.
NetworkManager has an option to ignore routes from the peer. Connection >>>settings --> IPv4/IPv6 settings --> Routes --> Ignore automatically >>>obtained routes
The Cisco ASA at work pushes some routes to my computer when I connect
to it. One of them (for a remote office) uses the same 192.168.1.0/24
subnet as my home network, so I lose access to my file server,
printers, etc. at home when I'm connected to the VPN. I'd been
considering moving my home network to a different subnet, but this
would be easier...will have to look into it.
?? 192.168.x.x is non-routable. Ie, unless you are directly connected to
the network you cannot access it. Is your home on the same physical net
as that remote office? Otherwise I do not see how tht could do anything
to your attachment to the home network.
I'd still need a route to 172.16.0.0/22. Would this have to be added
manually after connecting?
?? 192.168.x.x is non-routable. Ie, unless you are directly connected to
the network you cannot access it. Is your home on the same physical net
as that remote office? Otherwise I do not see how tht could do anything
to your attachment to the home network.
In article <uuf01e$2lb63$1@dont-email.me>,
Marco Moock <mm+usenet-es@dorfdsl.de> wrote:
On 01.04.2024 um 18:35 Uhr Markus Robert Kessler wrote:
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.
NetworkManager has an option to ignore routes from the peer.
Connection settings --> IPv4/IPv6 settings --> Routes --> Ignore
automatically obtained routes
The Cisco ASA at work pushes some routes to my computer when I connect to
it. One of them (for a remote office) uses the same 192.168.1.0/24 subnet
as my home network, so I lose access to my file server, printers, etc. at home when I'm connected to the VPN. I'd been considering moving my home network to a different subnet, but this would be easier...will have to look into it.
I'd still need a route to 172.16.0.0/22. Would this have to be added manually after connecting?
?? 192.168.x.x is non-routable.
The Cisco ASA at work pushes some routes to my computer when I
connect to it.
One of them (for a remote office) uses the same
192.168.1.0/24 subnet as my home network, so I lose access to my file
server, printers, etc. at home when I'm connected to the VPN. I'd
been considering moving my home network to a different subnet, but
this would be easier...will have to look into it.
The commercial VPNs like Cisco want to disable direct Internet access
of the client for the duration of the tunnel, to prevent sneak paths
to/from the public net and the internal tunneled network.
Some of these routes are conflicting with machines in my home office net.
?? 192.168.x.x is non-routable.
Ie, unless you are directly connected to the network you cannot
access it.
Is your home on the same physical net as that remote office? Otherwise
I do not see how tht could do anything to your attachment to the
home network.
The commercial VPNs like Cisco want to disable direct Internet access
of the client for the duration of the tunnel, to prevent sneak paths
to/from the public net and the internal tunneled network.
This can always be overridden at the VPN client, so security must
not rely on that.
On 02.04.2024 um 22:16 Uhr William Unruh wrote:
?? 192.168.x.x is non-routable.
It is routable, but won't be routed on the internet.
You can of course route it through a tunnel like here.
But which? He says he has his home network on 192.168. and there is a
work network on 192.168. but it is a different network (ne home, one
work) and the work one takes precednce for him. Only one of them can
be active to his machine. which has to be setup in the routng tables.
On 4/3/24 22:09, William Unruh wrote:
But which? He says he has his home network on 192.168. and there is a
work network on 192.168. but it is a different network (ne home, one
work) and the work one takes precednce for him. Only one of them can be
active to his machine. which has to be setup in the routng tables.
Traditional routing, read: non-policy-based-routing, dictates that the
best route wins. Directly attached routes always trump remote routes.
So for a remote route to be trumping a directly attached route, policy-based-routing must be in use or something else to override very
low level routing / networking.
On Wed, 3 Apr 2024 22:29:13 -0500, Grant Taylor wrote:
On 4/3/24 22:09, William Unruh wrote:
But which? He says he has his home network on 192.168. and there is a
work network on 192.168. but it is a different network (ne home, one
work) and the work one takes precednce for him. Only one of them can be
active to his machine. which has to be setup in the routng tables.
Traditional routing, read: non-policy-based-routing, dictates that the
best route wins. Directly attached routes always trump remote routes.
So for a remote route to be trumping a directly attached route,
policy-based-routing must be in use or something else to override very
low level routing / networking.
Verify the netmask(s) u use. If they are all /24 then a change in local nwtwirk would be easiset change.
On 02.04.2024 um 22:16 Uhr William Unruh wrote:
?? 192.168.x.x is non-routable.
It is routable, but won't be routed on the internet.
You can of course route it through a tunnel like here.
Marco Moock <mm+usenet-es@dorfdsl.de> writes:
On 02.04.2024 um 22:16 Uhr William Unruh wrote:
?? 192.168.x.x is non-routable.
It is routable, but won't be routed on the internet.
You can of course route it through a tunnel like here.
I always say that the RFC 1918 addresses are "not normally publicly
routed." :-)
As you say, they definitely _are_ routable, or a whole lot of home and corporate networks would not be functional.
I saw a video not too long ago that pointed out that the use of these addresses and NAT was made widespread by the Cisco PIX. It was a pretty interesting look back at something new that now seems commonplace and ordinary.
In the case in question, there are two networks with the same 192.168. network addresses. As mentioned the locally attached network should get
the nod. The claim is that it is not. Of course this is going by tun to
remote vpn. So if the local 192.168. addresses are being set up so that
those packets still get delivered through tun, then the "localy attached network" could well be the remote one. Answer, tell your local machine
to deliver all 192.168 stuff not to tun but to a local router which
knows about your local 192.168.
On 2024-04-04, Bud Frede <frede@mouse-potato.com> wrote:
Marco Moock <mm+usenet-es@dorfdsl.de> writes:
On 02.04.2024 um 22:16 Uhr William Unruh wrote:
?? 192.168.x.x is non-routable.
It is routable, but won't be routed on the internet.
You can of course route it through a tunnel like here.
I always say that the RFC 1918 addresses are "not normally publicly
routed." :-)
As you say, they definitely _are_ routable, or a whole lot of home and
corporate networks would not be functional.
The key word is "publicly". Ie, once you get away from directly attached networks (or internal routers you have specially set up within your organization) and some outside router needs to be involved to get the
packet from here to there, then that router has no idea which of the
millions of networks with 192.168. to send the packet to.
In the case in question, there are two networks with the same 192.168. network addresses. As mentioned the locally attached network should get
the nod. The claim is that it is not. Of course this is going by tun to remote vpn. So if the local 192.168. addresses are being set up so that
those packets still get delivered through tun, then the "localy attached network" could well be the remote one. Answer, tell your local machine
to deliver all 192.168 stuff not to tun but to a local router which
knows about your local 192.168.
Just don't forget to change the shorewall rules.
On 04/04/2024 16:43, William Unruh wrote:
On 2024-04-04, Bud Frede <frede@mouse-potato.com> wrote:The problem is that network is used both locally *and* remotely
Marco Moock <mm+usenet-es@dorfdsl.de> writes:
On 02.04.2024 um 22:16 Uhr William Unruh wrote:
?? 192.168.x.x is non-routable.
It is routable, but won't be routed on the internet.
You can of course route it through a tunnel like here.
I always say that the RFC 1918 addresses are "not normally publicly
routed." :-)
As you say, they definitely _are_ routable, or a whole lot of home and
corporate networks would not be functional.
The key word is "publicly". Ie, once you get away from directly attached
networks (or internal routers you have specially set up within your
organization) and some outside router needs to be involved to get the
packet from here to there, then that router has no idea which of the
millions of networks with 192.168. to send the packet to.
In the case in question, there are two networks with the same 192.168.
network addresses. As mentioned the locally attached network should get
the nod. The claim is that it is not. Of course this is going by tun to
remote vpn. So if the local 192.168. addresses are being set up so that
those packets still get delivered through tun, then the "localy attached
network" could well be the remote one. Answer, tell your local machine
to deliver all 192.168 stuff not to tun but to a local router which
knows about your local 192.168.
presenting a massive problem to the router.
The simple answer especally with DHCP is to reassign all local addresses
to say 192.168.3.*
Office is then 192.168.0.* via the tunnel, and the interbnet is the
default for normal stuff.
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
On 2024-04-02, Scott Alfter <scott@alfter.diespammersdie.us> wrote:
In article <uuf01e$2lb63$1@dont-email.me>,
Marco Moock <mm+usenet-es@dorfdsl.de> wrote:
On 01.04.2024 um 18:35 Uhr Markus Robert Kessler wrote:
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.
NetworkManager has an option to ignore routes from the peer.
Connection settings --> IPv4/IPv6 settings --> Routes --> Ignore >>>automatically obtained routes
The Cisco ASA at work pushes some routes to my computer when I connect to
it. One of them (for a remote office) uses the same 192.168.1.0/24 subnet >> as my home network, so I lose access to my file server, printers, etc. at
home when I'm connected to the VPN. I'd been considering moving my home
network to a different subnet, but this would be easier...will have to look >> into it.
?? 192.168.x.x is non-routable.
On 02/04/2024 23:16, William Unruh wrote:
?? 192.168.x.x is non-routable. Ie, unless you are directly connected to
the network you cannot access it. Is your home on the same physical net
as that remote office? Otherwise I do not see how tht could do anything
to your attachment to the home network.
192.168.x.x is routable.
It just isn't something that the Internet routes, by convention.
It can be routed via a VPN.
It is a good argument for changing his home IP network to something else.
| Sysop: | Luis Silva |
|---|---|
| Location: | Lisbon |
| Users: | 763 |
| Nodes: | 10 (0 / 10) |
| Uptime: | 179:29:19 |
| Calls: | 111 |
| Files: | 46,971 |
| Messages: | 11,214 |