dynamic/nopermanent routes to client subnets only when client connected

fhanzlik

I'm use tun/routed OVPN configuration, OpenVPN server is the gateway for the server LAN. To access IP segments behind clients, is seems as usual way is to use --iroute in client context (e.g. client file in ccd dir) to set OVPN internal routing, and --route directive as OVPN server cmdline or main config file option for OS-level routing. For some reason unknown to me (why?), --route option must not be used in client context (in ccd file in my case).
But --route in this case set on server side route for clients subnets to server tun interface permanently for all time OVPN server is running, not only when clients with these segments connects - this behavior disable to use same subnets on server side in time when no client (same subnets owning) is connected.

Am I understanding this correctly?
How best to solve this (OS level server-side routing to clients subnet only when client is connected)?
Set it in client-{,dis}connect scripts, or is there better way?
Setting it in the context of the client seems the most natural at first glance - why can't it?

TIA, Franta Hanzlik

TinCanTech

fhanzlik wrote seems as usual way is to use --iroute in client context (e.g. client file in ccd dir)

Correct.

fhanzlik wrote For some reason unknown to me (why?), --route option must not be used in client context (in ccd file in my case).

Correct.

fhanzlik wrote --route in this case set on server side route for clients subnets to server tun interface permanently for all time OVPN server is running, not only when clients with these segments connects

Correct.

fhanzlik wrote this behavior disable to use same subnets on server side in time when no client (same subnets owning) is connected

Do not have subnet conflicts and then the problem, to which you are alluding, goes away.

Configure your network correctly: Do not have any duplicate subnets, anywhere.

fhanzlik

Hi TinCanTech, thanks for the recommendation - but as usual, reality is sometimes different from theory. Scheduling network numbering perhaps is not a problem within a single organization or some centrally controlled groups. But in this case we are dealing with a relatively loose connection of some group of family relatives, friends, partners and several small organizations - and their networks are what they are, and there is no will or possibility to change them. Networks have sprung up spontaneously over the last 20+ years and often use routers with default settings. So in this environment there is really no danger of any unification of networks 😉
Is it possible to give some advice for this case, please?

TinCanTech

Routing is routing, do it right or have headaches.

OpenVPN is a VPN program with some built in routing capabilities.

Anything else is upto you. Shell scripting ..

Note:
If you try to configure openvpn with duplicate --iroute entries then basically the last one wins and the rest are forgotten. There was some talk about making that more manageable, like being able to edit --iroute info on-the-fly but no code ever emerged, that I know of.

You could try OpenVPN Access Server but then you have to pay.

TinCanTech

Openvpn also has something called --client-nat .. good luck with that, I don't use it.

openvpn_inc

Actually I think OpenVPN Cloud is your best bet for dealing with overlapping networks. But for the most part TCT is quite right: you can't realistically expect to link local networks under varied control without a network structuring agreement among all parties.

The --route directive has to be global, on the server, so clients know to route those networks through the VPN. There would be no point to setting a route in a CCD. OTOH --iroute is about what route goes to which client, so it has to be in a CCD.

regards, rob0

TinCanTech

fhanzlik wrote as usual, reality is sometimes different from theory

Here is the bottom line:

When you have money and power you do what you want.
When you use Free open source software, you do what you can.

You can not do what you want for nothing.

Old internet proverb:

Choose only two: Secure | Easy | Cheap

There is one exception: X509 .. Foo* would otherwise not exist.

* Starts with: Open and/or Easy .. [Sometimes Free .. but only when it is technically not Free]

8-) :geek: :mrgreen: :roll:

TinCanTech

There is this older expression:

The only things you can rely on are Death and Taxes

Alexander The Great abolished taxation for his own benefit. Fact :!:

That is how old this shit is .. Look it up.

fhanzlik

openvpn_inc wrote
The --route directive has to be global, on the server, so clients know to route those networks through the VPN. There would be no point to setting a route in a CCD. OTOH --iroute is about what route goes to which client, so it has to be in a CCD.

Hi rob0, maybe I'm misunderstanding something or I didn't explain my problem properly (my English is terrible).
I have client to server (OVPN) routed (tun) connection, machine with OVPN server is also default gateway for server network.
And my goal is client connection with, from server LAN, enabled routing to subnet behind client.

From what I understand, I need to have both set up on the server side:
1) iroute $CLIENTsUBNET - sets OVPN server internal routing only. Directive may be (and perhaps preferred to be) in CCD file.
2) route $CLIENTsUBNET ${ifconfig_pool_remote_ip} - sets route in OVPN server machine OS(=DF GW) routing table and in my case is effectively equal to iproute2 command "ip route add $CLIENTsUBNET via ${ifconfig_pool_remote_ip} dev ${dev}"

Without 2) OS on OVPN server not know, how route packets from its subnets to subnet behind client (without it, server OS does not know, that packets must be routed to clients tun IP via server tun interface).
From my view should be optimal to set both 1) and 2) (OVPN server internal and its OS routin table) in client connection time - thus "--route $CLIENTsUBNET" directive optimally should be not in global OVPN server configuration, but in CCD or so (simply in something that is executed at the time of connection).
Did I miss something?

fhanzlik

Hi TinCanTech, thanks for all Your advices!
Now I have a configuration more or less like this:

OVPN server global configuration (relevant part):

...
client-connect /usr/local/sbin/ovpn-clicon
client-disconnect /usr/local/sbin/ovpn-clicon
...

Client CCD file contains only two lines (OVPN server subnets accessible from clients are specified in server global cfg):

ifconfig-push 192.168.9.1 255.255.255.0 # OVPN client tun IP
iroute 10.0.0.0 255.0.0.0 # subnet behind OVPN client

/usr/local/sbin/ovpn-clicon relevant part:

#!/bin/bash
# OVPN server sets, among others, the following (here used) environment variables:
# ${untrusted_ip}            - client's public IP address (before auth)
# ${script_type}             - client-connect/client-disconnect (may be other?)
# ${dev}                     - client's tun interface
# ${ifconfig_pool_remote_ip} - client's tun interface IP addr
...
CLSEG1="10.0.0.0/8"						# subnet behind OVPN client
if [ "${untrusted_ip}" = "4.3.2.1" ]; then		# Client public IP, where its $CLSEG1 segment is
    if [ "${script_type}" = "client-connect" ]; then
        ip route add $CLSEG1 via ${ifconfig_pool_remote_ip} dev ${dev}
    else
        ip route del $CLSEG1 via ${ifconfig_pool_remote_ip} dev ${dev}
    fi
fi
...

Routing now behaves as I want - thus I think, my problem is solved. Thank You once again!

TinCanTech

According to your original post:

fhanzlik wrote this behavior disable to use same subnets on server side in time when no client (same subnets owning) is connected

And you have:

fhanzlik wrote iroute 10.0.0.0 255.0.0.0

So your problem still persists.

But if what you have works for you then great.

fhanzlik

Here is one real example:
OVPN server side has subnet 192.168.1.0/24 directly on one server interface.
Status from server when client with same subnet not connected:
--------------------------------------------------------------------------------
# ping -q -c 3 192.168.1.250
PING 192.168.1.250 (192.168.1.250) 56(84) bytes of data.
--- 192.168.1.250 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 53ms
rtt min/avg/max/mdev = 0.233/0.259/0.295/0.026 ms <=== time correspond to the local link

# traceroute -nn 192.168.1.250
traceroute to 192.168.1.250 (192.168.1.250), 30 hops max, 60 byte packets
1 192.168.1.250 0.334 ms 0.143 ms 0.217 ms <=== local target reached at first hop

# ip route|grep -F 192.168.1.$'\n'tun0
192.168.1.0/24 dev ethe0 scope link src 192.168.1.254 <==== OS kernel routing table entry for 192.168.1.0/24 subnet
192.168.9.0/24 dev tun0 proto kernel scope link src 192.168.9.254

# grep -F '192.168.1.' /var/lib/openvpn/openvpn-status.log
<--nothing-->

Same status, when client also owning 192.168.1.0/24 subnet is connected:
--------------------------------------------------------------------------------------------
# ping -q -c 3 192.168.1.250
PING 192.168.1.250 (192.168.1.250) 56(84) bytes of data.
--- 192.168.1.250 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 4ms
rtt min/avg/max/mdev = 16.985/17.148/17.437/0.254 ms <=== time correspond to the WAN link

# traceroute -nn 192.168.1.250
traceroute to 192.168.1.250 (192.168.1.250), 30 hops max, 60 byte packets
1 192.168.9.5 19.879 ms 19.680 ms 19.507 ms <=== routing over client tun interface
2 192.168.1.250 19.333 ms 19.140 ms 18.961 ms

# ip route|grep -F 192.168.1.$'\n'tun0
172.31.48.0/24 via 192.168.9.5 dev tun0
192.168.1.0/24 via 192.168.9.5 dev tun0 <=== OS kernel routing table entry for 192.168.1.0/24 subnet
192.168.9.0/24 dev tun0 proto kernel scope link src 192.168.9.254

# grep -F '192.168.1.' /var/lib/openvpn/openvpn-status.log
ROUTING_TABLE 192.168.1.0/24 ovk-hanzlici 2.3.4.5:39677 Sat Jul 30 17:49:18 2022 1659196158
ROUTING_TABLE 192.168.1.250C ovk-hanzlici 2.3.4.5:39677 Sat Jul 30 18:08:01 2022 1659197281

Anyway - substantial is, that OS kernel route to client subnet 192.168.1.0/24 is not permanent for all time when OVPN server run, as it would be with a
"route 192.168.1.0 255.255.255.0 192.168.9.5"
directive in OVPN server global configuration, but is here only when this client (ovk-hanzlici) is connected - which is what bothered me.
Excuse for probably bad explanation...
PS: please, how I can mark thos thread as solved? Thanks!

TinCanTech

fhanzlik wrote Here is one real example:
OVPN server side has subnet 192.168.1.0/24 directly on one server interface.

That is not an example of your original question.

fhanzlik wrote how I can mark thos thread as solved?

Unless you can edit your posts, you cannot mark it as solved.

Also, as I have explained, you have not solved your initial question.

fhanzlik

TinCanTech wrote
fhanzlik wrote Here is one real example:
OVPN server side has subnet 192.168.1.0/24 directly on one server interface.
That is not an example of your original question.

Perhaps maybe I'm saying it wrong or using the wrong translator 😉
Anyway, the essence of the problem was that the use of the route directive in the global configuration of the OVPN server is/can be inappropriate and restrictive - and the question of how best to solve this.
The setting in the client-{,dis}connect scripts works as I need, and that's enough for me. I'm resigned to not knowing why there can't be a route directive in the CCD.
I'm sorry I apparently explained it wrong - but I'd rather not try that again.

TinCanTech wrote
fhanzlik wrote how I can mark thos thread as solved?
Unless you can edit your posts, you cannot mark it as solved.

I can not edit my first two posts (third+ I can). Mark as solved means place "[solved]" or so into first mail Subject?
Thanks!

TinCanTech

fhanzlik wrote the essence of the problem was that the use of the route directive in the global configuration of the OVPN server is/can be inappropriate and restrictive - and the question of how best to solve this.

This is how Openvpn works. The way to solve that is for you to learn the restrictions of Openvpn, which is not the Linux routing daemon, nor is it routing at large.

fhanzlik wrote I'm resigned to not knowing why there can't be a route directive in the CCD.

The reason is because that is not where a --route statement belongs. A CCD is where Openvpn daemon learns about subnets behind clients by using --iroute (Which means internal route, internal to the Openvpn daemon).

This is how Openvpn works and it is very, very unlikely to change, so it is you who must learn the change.

TinCanTech

fhanzlik wrote /usr/local/sbin/ovpn-clicon relevant part:

#!/bin/bash
# OVPN server sets, among others, the following (here used) environment variables:
# ${untrusted_ip}            - client's public IP address (before auth)
# ${script_type}             - client-connect/client-disconnect (may be other?)
# ${dev}                     - client's tun interface
# ${ifconfig_pool_remote_ip} - client's tun interface IP addr
...
CLSEG1="10.0.0.0/8"						# subnet behind OVPN client
if [ "${untrusted_ip}" = "4.3.2.1" ]; then		# Client public IP, where its $CLSEG1 segment is
    if [ "${script_type}" = "client-connect" ]; then
        ip route add $CLSEG1 via ${ifconfig_pool_remote_ip} dev ${dev}
    else
        ip route del $CLSEG1 via ${ifconfig_pool_remote_ip} dev ${dev}
    fi
fi
...

Routing now behaves as I want - thus I think, my problem is solved. Thank You once again!

I must point out to you: This does not work, either as you expect or even at all.

fhanzlik

Previously published /usr/local/sbin/ovpn-clicon only show frame how to add/del route to OVPN client subnet in client-connect/client-disconnect phase only. Of course, existing route to local segment must be removed before adding new and added after client disconnect; I have there also some logging and oter stuff. Minimalistic and also still functional (there may be also other optional routing parameters) then should be:

#!/bin/bash
CLSEG1="10.0.0.0/8"	
if [ "${untrusted_ip}" = "4.3.2.1" ]; then		# Client public IP, where its $CLSEG1 segment is
    if [ "${script_type}" = "client-connect" ]; then
        ip route del $CLSEG1 dev ethe0
        ip route add $CLSEG1 via ${ifconfig_pool_remote_ip} dev ${dev}
    else
        ip route del $CLSEG1 via ${ifconfig_pool_remote_ip} dev ${dev}
        ip route add $CLSEG1 dev ethe0
    fi
fi

Maybe noticeable is '--explicit-exit-notify' in client config for quick disconnect routing change, as I'm using UDP...

fhanzlik

TinCanTech wrote
fhanzlik wrote the essence of the problem was that the use of the route directive in the global configuration of the OVPN server is/can be inappropriate and restrictive - and the question of how best to solve this.
This is how Openvpn works. The way to solve that is for you to learn the restrictions of Openvpn, which is not the Linux routing daemon, nor is it routing at large.

fhanzlik wrote I'm resigned to not knowing why there can't be a route directive in the CCD.
The reason is because that is not where a --route statement belongs. A CCD is where Openvpn daemon learns about subnets behind clients by using --iroute (Which means internal route, internal to the Openvpn daemon).

This is how Openvpn works and it is very, very unlikely to change, so it is you who must learn the change.

I guess I understand and agree - OpenVPN is not routing daemon.
But I rather wanted to know how and in which place to solve this matter. If there is nothing more suitable than in the client-dis/connect script, then everything is OK...
Thanks!

TinCanTech

With a CCD --iroute, Openvpn learns this:

--iroute / Client #1 - Network 10.0.1.0/24 - Interface tun1
--iroute / Client #2 - Network 10.0.2.0/24 - Interface tun1

Openvpn must know the client to which the route belongs, because the kernel route only has tun1.

Openvpn knows which particular client to use. This is not routing, it is internal routing.

Which is also the reason why your script is wrong, because you are messing with kernel routing not Openvon internal routing.

It is just like The Matrix. You cannot think that you are right , you have to know that you are right.

I guess i should apologies for the English language for being so absurd..

fhanzlik

TinCanTech wrote Which is also the reason why your script is wrong, because you are messing with kernel routing not Openvon internal routing.

Script only supplies "route" directive (thus sets also kernel OS routing), nothing else - but sets it dynamically at client connect/disconnect time. Which isn't possible with "route" directive in OVPN server global config file.
And internal OVPN routing is provided by the iroute directive in the client's CCD file, as I wrote above - which is probably the usual solution for setting (internal) client subnet routing.Together it works well, at least for me. And according to my tests and the internal routing from the "status /var/lib/openvpn/openvpn-status.log" file dump and kernel routing, as I wrote before, it's so fine.

According to '--client-connect' documentation (
The command is also passed the pathname of a freshly created temporary file as the last argument (after any arguments specified in cmd ), to be used by the command to pass dynamically generated config file directives back to OpenVPN. If the script wants to generate a dynamic config file to be applied on the server when the client connects, it should write it to the file named by the last argument.
) it seems as it should be also possible pass iroute directive from bash scripts to OVPN server in this way, but I not tried it - because I already use CCD file to set IP address of client tun interface.