OpenVPN remote networks not pushed to main routing table

[nothing]

Using OPNsense 20.7.3-amd64 I have set up openvpn server with for remote access when I'm mobile or remote and joining few remote sites I frequently visit.
I have the server as ssl/tls|tcp|tun|dynamic ip|addr pool|topology. I have /24 as tunnel network and /16 as local network (so that I can join and route all remote sites). As single user I can connect from anywhere and successfully use the tunnel. The problem comes when I join remote sites.
Single users and remote sites have the same client configuration. The only difference is that for remote sites I have set up "client specific overrides" on the openvpn server.
And the only thing I specify is "ipv4 remote network", so that when this client joins and gets any (dynamic) ip from the vpn pool, openvpn activates the route to it's remote subnet.

All goes very well except for the final part - injecting the remote network routes to kernel routing table. All routes are correctly shown in OpenVPN > Connection Status > Routing Table, but are missing from OS' routing table thus I can't reach the remote sites (their subnets are routed via the default gateway on WAN interface).

Does anybody used it this way and seen the same problem?

[Gauss23]

You still need to specify all local and remote networks in the main server. In client specific override you specify which client will use it.

[mimugmail]

I'd do a separate instance for remote access and one for site2site.
Have this already in production and works really fine

[Gauss23]

I'd do a separate instance for remote access and one for site2site.
Have this already in production and works really fine

Yes that's definitely the way I would recommend. Have it in production like that.

[nothing]

Yup, I can think of hundred alternative ways of doing it, but was wondering why it's not working this particular way. And since all seem to logical and available as configuration options, but not actually working I'm almost certain it's a bug.

[Gauss23]

A bug? No. Maybe it's not very intuitive.

All involved networks need to be defined in the main server to be added to the routing table. The client specific override only configures which client is getting which local networks and which remote networks are on the other side of the peer.

[mimugmail]

A bug the UI doesnt do what you want or OpenVPN itself doesnt do? Maybe better check the different OpenVPN.conf output and ask at OpenVPN forum?

[nothing]

A bug? No. Maybe it's not very intuitive.

All involved networks need to be defined in the main server to be added to the routing table. The client specific override only configures which client is getting which local networks and which remote networks are on the other side of the peer.

What you are saying sounds logical, although it doesn't work.
Will try to be more exact with my example:
1. I have two remote networks 192.168.10.0/24 and 192.168.20.0/24 available for two different sites.
2. Local ipv4 network configured in openvpn server is 192.168.0.0/16.
3. In client specific configuration I enter first subnet to site1, the second to site2.
4. Both sites connect, receive the /16 route.
5. Opnvpn server shows 192.16.10.0/24 routed to site1 and 192.168.20.0/24 to site2 in connection status > routing table exactly as it should, since that's how it's configured.
6. The same routes does not exist in OS routing table and they can't be reached unless manually defined.

I have tried what you suggest - to add all remote subnets in openvpn's main configuration, then have them split in client specific configuration for each client. Unfortunately the result is that both subnets get routed to the first client to connect the openvpn server.

It's either a bug or having "Tunnel Network" in client specific options available makes no sense.

[Gauss23]

Please send screenshot of server configuration.

A 192.168.0.0/16 network as local but you want 192.168.10.0/24 and 192.168.20.0/24 as remote networks? How should that work? 192.168.0.0/16 includes both of your remote networks. Doesn´t make sense to me.

[nothing]

Having /16 on all sites routed to the central unit makes possible for site1 to talk to site2 via the central server without the need of having mesh topology with vpns between all sites. Nothing strange in that, no network rule has been violated :)

[Gauss23]

Still no screenshot

[nothing]

Still no screenshot

Well if the pictures will make it clearer, here they are :)
I haven't attached encryption and authentication as they are out of scope and will work fine.

[Gauss23]

Are you sure your client specific overrides are executed?

I needed to check "Force CSO Login Matching" to make it work.

[mimugmail]

Sorry, but incomplete screenshots are useless, really, it's always a small detail.

[nothing]

Are you sure your client specific overrides are executed?

I needed to check "Force CSO Login Matching" to make it work.

Well, yes, because I see the routes in openvpn status like so: