Where to get the sources (openconnect) ?

Just don't forget to change the shorewall rules.

Regards, Dave Hodgins

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.

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.

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.

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:

It took me some time to find out, but it was worth every minute :-)

Best regards,

Markus

...

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?

White letters on light green is almost unreadable.

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'

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

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

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

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

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

Best regards,

Markus

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

Anyway, it seems to be working.

CISCO_SPLIT_INC_${i}_{ADDR,MASK,MASKLEN) triplets with an appropriate

CISCO_INC_EXC at the end.

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?

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

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

As Dave already mentioned, this should be 16

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.

Best regards,

Markus

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

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.

I probably should've explained the situation. At work, the main office uses

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.

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 :-) ).

Just curious but which carrier board? Is there a case too?