Where to get the sources (openconnect) ?

Invoked directly or via NetworkManager?

NetworkManager has an option to ignore routes from the peer. Connection settings --> IPv4/IPv6 settings --> Routes --> Ignore automatically obtained routes

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.

If you really need them:

Directly

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

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

I dunno.

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.

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

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

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.

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.

It is routable, but won't be routed on the internet. You can of course route it through a tunnel like here.

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.

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

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

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.

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.

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

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.

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.

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.

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.