Internal routing precedence of broad iroute overshadowing a server’s own local subnet within OpenVPN’s internal routing algorithm

[Zrin]

In a situation where there is

• a local network, e.g. 172.16.11.0/24 attached to the server system and
• broader network, e.g. 172.16.0.0/12 shall be routed to a specific OpenVPN client, so
• route 172.16.0.0 255.240.0.0 is specified in the server config and corresponding iroute 172.16.0.0 255.240.0.0 in the client's CCD file,
  the OpenVPN internal routing violates the longer-prefix rule and routes packets for 172.16.11.0/24 to the specific client instead of to the local server system.

To Reproduce
Add a broader route to the server config that corresponds to a local network behind the server, that routes the packets (back) to a client and then try to reach the local network behind the server from the client.

Expected behavior
Longer-prefix rule is observed, local network behind the server is reachable.

Version information (please complete the following information):

• OS: Debian 12.11
• OpenVPN version: 2.6.3

A warning that an internal OpenVPN route overlaps a local route would be helpful.
A server-side "iroute" which would add a local route to the OpenVPN Server's internal route without adding it to the kernel routing table would fix this as well, but AFAICU it would be good and better if OpenVPN internal routing would respect the longer-prefix rule.

[ordex]

do you have client-to-client in the server config?
And I presume you're not using DCO, right?

[schwabe]

Well internal routes are evaluated first. So they naturally take preference.

[ordex]

Well internal routes are evaluated first. So they naturally take preference.

But without client-to-client the packet is first released to the OS and then injected back in the tun for further processing.
In this case the main routing table gets a chance to be evaluated first, no?

[schwabe]

Yeah should be but I would need to double check

[cron2]

@Zrin good find, yes. OpenVPN does not evaluate operating system routes - neither "connected" nor "anything else". It just builds the iroute table per client, and "everything that does not match" (formally like a default route) is passed to the kernel (assuming client-to-client is active).

With DCO there is no iroute table anymore, so everything is "kernel routes" and this effect will no longer happen.

Adding proper "understand operating system side routing state" to OpenVPN is not trivial, alas (almost every supported operating system has a different way to query OS side). Adding a pseudo-iroute "this goes to the OS" to the config would be easy, but I guess it is so niche that most people would be more confused than helped by that.

In your case, I suggest to split the client's iroute into non-overlapping routes

172.16.0.0/21
172.16.8.0/23
172.16.10.0/24
172.16.12.0/24
...
172.17.0.0/16
172.18.0.0/15
172.20.0.0/14
...

though that is really unwieldy, with a /24 right in the middle of a /12...

So indeed going for a DCO based setup might be the easiest way :-) (using 2.7.0 with in-kernel DCO).

[cron2]

I find the problem sufficiently interesting to mark it as "enhancement" :-) - but as I said it's not trivial, alas.

[ordex]

I find the problem sufficiently interesting to mark it as "enhancement" :-) - but as I said it's not trivial, alas.

but why not just removing client-to-client and be done with it? 🤔

[cron2]

but why not just removing client-to-client and be done with it? 🤔

That would be like admitting defeat... (and reduce client-to-client throughput even more). So yes, the original problem is not unsolvable, even without code changes, but requirements might vary...

[Zrin]

do you have client-to-client in the server config? And I presume you're not using DCO, right?

Yes, server config has client-to-client.

DCO is not in use.
(Yet ... because there are problems with it even on Debian 13.2 with stock kernel 6.12.57+deb13-amd64 - connections get stuck after some time.)