Where to get the sources (openconnect) ?

[Markus Robert Kessler]

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

[Marco Moock]

Post by Markus Robert Kessler
I am running several machines for connecting to our company intranet,
using openconnect VPN.

Invoked directly or via NetworkManager?

Post by Markus Robert Kessler
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

Post by Markus Robert Kessler
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.

This is not a default route and if they don't add the routes from the
VPN server, this is either a setting or a serious bug.

Post by Markus Robert Kessler
Maybe someone can give a hint where to download the openconnect
sources for Ubuntu?

If you really need them:
https://www.infradead.org/openconnect/download.html

[Markus Robert Kessler]

Post by Marco Moock

Post by Markus Robert Kessler
I am running several machines for connecting to our company intranet,
using openconnect VPN.

Invoked directly or via NetworkManager?

Directly

Post by Marco Moock

Post by Markus Robert Kessler
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

Looks promising! Thanks!

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?

Thanks again!

Best regards,

Markus

[Marco Moock]

Post by Markus Robert Kessler
So, openconnect does have a (commandline) option, which network
manager invokes to get rid of those routing infos?

I dunno.

Post by Markus Robert Kessler
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.

[William Unruh]

Post by Marco Moock

Post by Markus Robert Kessler
So, openconnect does have a (commandline) option, which network
manager invokes to get rid of those routing infos?

I dunno.

Post by Markus Robert Kessler
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.

If you run openconnect on its own (no argument) it lists its options, so
is like a very brief man page but presumable up-to-date.

[Scott Alfter]

Post by Marco Moock

Post by Markus Robert Kessler
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?

[William Unruh]

Post by Scott Alfter

Post by Marco Moock

Post by Markus Robert Kessler
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.

Post by Scott Alfter
I'd still need a route to 172.16.0.0/22. Would this have to be added
manually after connecting?

[Markus Robert Kessler]

Post by William Unruh

Post by Scott Alfter

Post by Marco Moock

Post by Markus Robert Kessler
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.

Post by Scott Alfter
I'd still need a route to 172.16.0.0/22. Would this have to be added
manually after connecting?

Since 172.16.* is part of the private space beyond the vpn, you have to
add this like

ip route add 172.16.0.0/22 dev tun0

or similar, depending on your vpn device.

Best regards,

Markus

[The Natural Philosopher]

Post by William Unruh
?? 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.

[Scott Alfter]

Post by The Natural Philosopher

Post by William Unruh
?? 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.

That's also something I've considered. My home router's a Raspberry Pi CM4
on a carrier board that adds a second Ethernet jack, running OpenWRT. I've
thought about downloading the config, changing all occurrences of 192.168.1.
to 192.168.100. (or whatever), and uploading the changed config, but have
been a bit nervous about it (especially since the WAF of a downed network is
pretty low :-) ).

[Marco Moock]

Post by William Unruh
?? 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.

[William Unruh]

Post by Marco Moock

Post by William Unruh
?? 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.

[Grant Taylor]

Post by William Unruh
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.

[jim whitby]

Post by Grant Taylor

Post by William Unruh
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.

[David W. Hodgins]

Post by jim whitby

Post by Grant Taylor

Post by William Unruh
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.

Just don't forget to change the shorewall rules.

Regards, Dave Hodgins

[Grant Taylor]

Post by David W. Hodgins
Just don't forget to change the shorewall rules.

You might not even need to do that.

Add two /25 routes using the local network. The shorewall, bein on a
separate system than the problematic VPN client, is probably perfectly
fine continuing to use the /24.

N.B. it's late at night and I'm not sure what will happen with broadcasts.

I'm confident that this can be made to work. Especially with host (/32)
routes.

[Bud Frede]

Post by Marco Moock

Post by William Unruh
?? 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.

[William Unruh]

Post by Bud Frede

Post by Marco Moock

Post by William Unruh
?? 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.

Post by Bud Frede
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.

[Ahem A Rivet's Shot]

On Thu, 4 Apr 2024 15:43:33 -0000 (UTC)

Post by William Unruh
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

As far as the routing stack is concerned they're all local, it
doesn't know that the cable on one of the interfaces is an encrypted tunnel
across the internet.

Post by William Unruh
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.

Yes an interface specific route should do the job - provided of
course there is never a need to communicate with anything in that network
on the VPN.

[The Natural Philosopher]

Post by William Unruh

Post by Bud Frede

Post by Marco Moock

Post by William Unruh
?? 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.

The problem is that network is used both locally *and* remotely
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.

[William Unruh]

Post by The Natural Philosopher

Post by William Unruh

Post by Bud Frede

Post by Marco Moock

Post by William Unruh
?? 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.

The problem is that network is used both locally *and* remotely
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.

Of course you then have to go in and set up the routing tables on your
own machine to do that. It is not done automatically-- it is up to you
to do it. If you know what you are doing it is easy. If not, it is
impossible.

[Grant Taylor]

Post by William Unruh
?? 192.168.x.x is non-routable.

192.168/16 is very much so routABLE.

It is just not routED on the global Internet (by convention).

Almost all IPs are routable. It gets very tricky to say why given IPs
are not capable of being routed. Beyond part of locally attached
networks and crap software, I can't think of think of any that can't be
made to be routed.

Post by William Unruh
Ie, unless you are directly connected to the network you cannot
access it.

Lack of a route is very different than the lack of ability to route.

Post by William Unruh
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.

Do to vagaries of non-deterministic things, it's possible to have a
route to 192.0.2.0/24 through a VPN as well as through the local NIC.
Sometimes the most recent route to be configured is the route that is used.

Other times VPN clients play with policy based routing such that they
can intercept things ostensibly for white hat reasons.

[Scott Alfter]

Post by William Unruh

Post by Scott Alfter

Post by Marco Moock

Post by Markus Robert Kessler
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.

I probably should've explained the situation. At work, the main office uses
172.16.0.0/22. A satellite office a few blocks away uses 192.168.1.0/24; a
static route is added to the handful of desktops that need to talk to hosts
over there. At home, my personal network also uses 192.168.1.0/24.
Connecting to the VPN from home causes my home server, printers, etc. to
become inaccessible as a result, as traffic for 192.168.1.0/24 gets routed
to the satellite office.

The ability to ignore some of the routes provided by the VPN would be nice,
as I don't need to deal with stuff at the satellite office 99% of the time.

[Tauno Voipio]

Post by Scott Alfter

Post by Marco Moock

Post by Markus Robert Kessler
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?

The network 172.16.x.x to 172.31.x.x is one of the RFC1918 ranges
reserved for private networks, and as such it is non-routable in the
outside Net. It is probably fine to have inside of the VPN tunnel.
The same applies to the 192.168.x.x network (and 10.x.x.x).

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.

[Marco Moock]

Post by Tauno Voipio
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.

[Grant Taylor]

Post by Marco Moock
This can always be overridden at the VPN client, so security must
not rely on that.

I agree that you /should/ be able to override it.

Though that's predicated on you having sufficient administrative access
to do so on the client device. Being an unprivileged user on a work
owned computer makes that difficult.

I've also used some VPNs that periodically (ever single digit minutes if
memory serves) checked the configuration and would disconnect if it was
not what the admins wanted.

[Grant Taylor]

Post by Tauno Voipio
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.

That is very likely a configuration option on the VPN concentrator.

It may default to having the default route go through the VPN.

Start streaming things through the VPN and causing the VPN concentrator
to use a lot more bandwidth and the people that configured it may decide
that they want to change the configuration.

[Marco Moock]

Post by Scott Alfter
The Cisco ASA at work pushes some routes to my computer when I
connect to it.

At least when using NetworkManager, you can control that behavior and
you can add settings to the connection that special routes will be
added when VPN comes up and removed when it comes down.

Post by Scott Alfter
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.

Another reason to move to IPv6 - no more address conflicts.

[Jim Jackson]

Post by Markus Robert Kessler
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?

As long as you have the deb-src lines in your /etc/apt/sources.list etc
Then for any package

apt-get source package-name

gets you the source that was used to compile the binaries in the package.

e.g. see https://www.cyberciti.biz/faq/how-to-get-source-code-of-package-using-the-apt-command-on-debian-or-ubuntu/

[Grant Taylor]

Post by Markus Robert Kessler
Some of these routes are conflicting with machines in my home office net.

Try adding more specific / host routes to things on your home network
via the NIC connecting to your home networking.

There are also multiple routing tables and policy based routing games
that can be played.

[Markus Robert Kessler]

Hello all,

here is what I've done in short:

First I wrote to openconnect mailinglist and got an email back, just
recommending to install "vpn-slice" instead.
This was not an answer to my question.

Next, after analyzing openconnect's behaviour, I found out that this one
does nothing about manipulating routing etc. This is solely done by "vpnc-
script", which is directly invoked from openconnect. And, hence, it
inherits all the env variables, which are not visible from outside.

So, I created a new "vpnc-script" file with content

#!/usr/bin/sh
env | sort

and set a symlink, so that openconnect invoked this one now. (Done in
foreground mode, i.e. no -b on commandline).

Watching its output I saw the more than hundred routes which are
transferred to the client via server-side "route push..." command.

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

Post by Markus Robert Kessler
Hi all,
I am running several machines for connecting to our company intranet,
using openconnect VPN.
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

[William Unruh]

Post by Markus Robert Kessler
Hello all,

...

Post by Markus Robert Kessler
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?

_

Post by Markus Robert Kessler
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
https://www.dipl-ing-kessler.de/tmp/vpnc-script

White letters on light green is almost unreadable.

Post by Markus Robert Kessler
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

[Markus Robert Kessler]

Post by William Unruh

Post by Markus Robert Kessler
Hello all,

...

Post by Markus Robert Kessler
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'

Post by William Unruh
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

Post by William Unruh
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

Post by William Unruh
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

Post by William Unruh
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

Post by William Unruh
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

Post by William Unruh
_

Post by Markus Robert Kessler
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
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

Post by William Unruh

Post by Markus Robert Kessler
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

[William Unruh]

Post by Markus Robert Kessler

Post by William Unruh

Post by Markus Robert Kessler
Hello all,

...

Post by Markus Robert Kessler
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.

Post by Markus Robert Kessler

Post by William Unruh
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

Post by William Unruh
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

Post by William Unruh
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 ?

Anyway, it seems to be working.

Post by Markus Robert Kessler

Post by William Unruh
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

Post by Markus Robert Kessler

Post by William Unruh
CISCO_SPLIT_EXC at the end.

CISCO_INC_EXC at the end.

Post by Markus Robert Kessler

Post by William Unruh
(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

Post by William Unruh
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?

Post by Markus Robert Kessler
Openconnect is calling vpnc-script for several reasons, see line
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

Post by William Unruh
_

Post by Markus Robert Kessler
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
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

Post by William Unruh

Post by Markus Robert Kessler
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

[David W. Hodgins]

On Fri, 12 Apr 2024 14:52:37 -0400, William Unruh <***@invalid.ca> wrote:
<snip>

Post by William Unruh
Agreed. I meant
255.255.0.0 Is that 16 or 32 ?

255.255.255.0 is a /24 meaning only the last 8 bits (octet) of the address changes.
The first 24 bits of the 32 bit address are fixed.

255.255.0.0 is a /16
255.0.0.0 is a /8

A /32 would be written as a netmask of 255.255.255.255, in which case only one
ip address is in the selected range.

That's for an ipv4 network. For ipv6 there are 128 bits instead of 32.

Regards, Dave Hodgins

[Markus Robert Kessler]

Post by William Unruh

Post by Markus Robert Kessler

Post by William Unruh

Post by Markus Robert Kessler
Hello all,

...

Post by Markus Robert Kessler
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.

Post by Markus Robert Kessler

Post by William Unruh
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

Post by William Unruh
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

Post by William Unruh
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

Post by William Unruh
Anyway, it seems to be working.

Post by Markus Robert Kessler

Post by William Unruh
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

Post by Markus Robert Kessler

Post by William Unruh
CISCO_SPLIT_EXC at the end.

CISCO_INC_EXC at the end.

Post by Markus Robert Kessler

Post by William Unruh
(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

Post by William Unruh
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.

Post by William Unruh

Post by Markus Robert Kessler
Openconnect is calling vpnc-script for several reasons, see line
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

Post by William Unruh
_

Post by Markus Robert Kessler
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
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

Post by William Unruh

Post by Markus Robert Kessler
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

[William Unruh]

Post by Markus Robert Kessler
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.

So I presume that openconnect sends a disconnect to vpnc-script to tear
down the routes through tun.

Post by Markus Robert Kessler
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.

OK, that's a good suggestion.

I have now implimented my idea on two different vpns -- one at UBC and
ont at tamu, and it seems to work on both. Of course if a web page in
either links to something outside their address space that I specified
in the altered lines in the vpnc-script, then that goes through the
original connection. If I wanted to view US netflix programs from
Canada, that would not work, since netflix would see the packets as
coming from Canada, rather then the US. So, some way of adding to the
list of the IP addresses that the connections tunnels dynamically would
be good. But I guess I can always use ip commend to add routes to my
systems routing table through tun.

The alternative, that everything gets routed through tun really is not
very good (never mind that all connections I have to any outside
computers get broken when I start the openconnect connection.

Anyway, thanks for pointing me to the way to get this working.

Post by Markus Robert Kessler
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.

Post by Markus Robert Kessler
Openconnect is calling vpnc-script for several reasons, see line
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

Post by William Unruh
_

Post by Markus Robert Kessler
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
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

Post by William Unruh

Post by Markus Robert Kessler
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