When I set up openVPN I had already configured my local networks using the usual 192.168.1.x, 192.168.2.x etc. No issues locally because the modem/router was set to 192.168.1.x so that's my external network and 192.168.2.x and 192.168.3.x are internal. Remote VPN worked fine except when trying to access an application server on 192.168.2.230 if the remote client's network was 192.168.2.x when the client was looking locally for the server rather than over the VPN. Unfortunately in my case two remote clients that needed access to the server were in this situation and one I couldn't change their network so I had to find a solution. Although I could manually add a route on the client once the VPN was up I needed to find an automatic solution.
It just so happens that all my servers have addresses in the range 192.168.2.200 to 192.168.2.254 and the remote client gateways had addresses of 192.168.2.1 and allocated DHCP addresses below 192.168.2.100. Therefore I was lucky in that I had non-overlapping subnets. Also because I only needed certain clients to have access to the server I needed a solution that was client dependant. The answer was to turn on client-ccd on the server by uncommenting in /etc/openvpn/server.conf:
I created the ccd directory under the openvpn directory (/etc/openvpn/ccd) and added text files for only the clients that needed it. In my case when initially setting up the client keys I called them client1, client2 etc so I called the files in the ccd directory client1, client2 etc. Add the following line as amended for your particular circumstances to the individual client files in the ccd directory:
push "route 192.168.2.192 255.255.255.192"
and that's it! What this does is route any requests for IPs in the range 192.168.2.192 to 192.168.2.254 to the VPN server end leaving any others local to the client. If your situation doesn't match mine then you can do individual ones:
push "route 192.168.2.230 255.255.255.255"
You can also have multiple push statements. What you must have is a mask other than 255.255.255.0 because the client routing table must be able to differentiate between local and remote addresses.
Other subnetting examples are:
192.168.2.128 255.255.255.128 (for 128 to 254)
192.168.2.224 255.255.255.224 (for 224 to 254)
192.168.2.240 255.255.255.240 (for 240 to 254)
192.168.2.248 255.255.255.248 (for 248 to 254)
If your situation is such that you can't split things up nicely (I was lucky many years ago that I decided to logically split servers from clients in the way I did) then unfortunately you're going to have to do some local network renumbering.