OpenVPN full and split tunnel on one instance with client override

[ivica.glavocic]

OPNSense v25.7.2 with OpenVPN server v2.6.14. Full tunnel (Internet trough OPNSense) is configured with Google TOTP and works OK. OpenVPN TUN instance on UDP port 443 with float and persist-remote-ip options is pushing block-outside-dns, register-dns and explicit-exit-notify to clients. Redirect Gateway on instance is set to default. Firewall rules control access to internal resources and Internet correctly.

For some users I would like to set up split tunnel on same OpenVPN instance, so I created client specific overrides with their own network and adequate firewall rules. For those users, access to internal resources works, but Internet is still going trough OPNSense, I cannot get split tunnel for them no matter what option on Redirect Gateway I activate.

Any chance to get split tunnel for specific users trough client specific overrides?

[viragomann]

Even if you have explicitly stated the "local network" in the CSO?

If the upstream traffic is routed over the VPN anyway, enable the "advanced mode" and check "Push reset".
Note that this flushes all push options for the respective client and you have to state all necessary again in the CSO.

[ivica.glavocic]

Even if you have explicitly stated the "local network" in the CSO?

If the upstream traffic is routed over the VPN anyway, enable the "advanced mode" and check "Push reset".
Note that this flushes all push options for the respective client and you have to state all necessary again in the CSO.

CSO - Redirect gateway = local, upstream traffic is routed over the VPN.
After I activate Push Reset, cannot connect any more, error on client is:
tun_prop_error: ifconfig addresses are not in the same /30 subnet (topology net30)

Documentation and search says: "Some of these options will need to be re-configured afterwards, specifically --topology subnet and --route-gateway will get lost and this will break client configs in many cases" but I don't know what and how to push those parameters to client. Can't see such option in CSA advanced GUI.

[viragomann]

You have to state an IP for the client in the CSO out of the tunnel network with the correct mask.
E.g. if you server tunnel network is 10.80.0.0/24, specify 10.80.0.201/24 in the CSO.

[ivica.glavocic]

Done that exactly, client has fixed IP and correct netmask, still can't connect with above error.

Instance:
Server (IPv4) parameter = 10.249.240.0/22
Topology = subnet

CSO:
IPv4 Tunnel Network = 10.249.241.1/22
Redirect gateway = local

[viragomann]

Instance:
Server (IPv4) parameter = 10.249.240.0/22
Topology = subnet

CSO:
IPv4 Tunnel Network = 10.249.241.1/22

This is the servers IP! You cannot assign it the a client.

Also not that the CSO doesn't make any IP reservation for the client. Clients get IPs from the first one (.2 in this case with subnet topology) upwards.
Therefore I suggest to specify a high IP in the tunnel subnet.

[ivica.glavocic]

Instance:
Server (IPv4) parameter = 10.249.240.0/22
Topology = subnet

CSO:
IPv4 Tunnel Network = 10.249.241.1/22

This is the servers IP! You cannot assign it the a client.

Also not that the CSO doesn't make any IP reservation for the client. Clients get IPs from the first one (.2 in this case with subnet topology) upwards.
Therefore I suggest to specify a high IP in the tunnel subnet.

The server's IP is 10.249.240.1, please note the subnet /22
Client gets correct IP 10.249.241.1

Idea is to have full tunnel clients on 10.249.240.x and split tunnel clients on 10.249.241.x all on the same instance, I would like to avoid another instance with different port, if possible.

[viragomann]

So possibly another setting of the CSO isn't compatible to the server settings. You can show both here, so others can verify them.

[ivica.glavocic]

Instance and CSO configuration are attached to this message. Some data is redacted for security reasons.

[viragomann]

Seems all right to me as far as I can see.

Try a /24 mask in the server at least for testing purposes. I saw several issues here with bigger tunnel subnets.
Remember to set also tunnel in the CSO to the correct subnet and mask.