OpenVPN includes a countermeasure to this very popular problem. It is basically a static one-to-one NAT. It is enabled with the help of the --client-nat option:
--client-nat args
This pushable client option sets up a stateless one-to-one NAT
rule on packet addresses (not ports), and is useful in cases
where routes or ifconfig settings pushed to the client would
create an IP numbering conflict.
Examples:
client-nat snat 192.168.0.0/255.255.0.0
client-nat dnat 10.64.0.0/255.255.0.0
network/netmask (for example 192.168.0.0/255.255.0.0) defines
the local view of a resource from the client perspective, while
alias/netmask (for example 10.64.0.0/255.255.0.0) defines the
remote view from the server perspective.
Use snat (source NAT) for resources owned by the client and
dnat (destination NAT) for remote resources.
Set --verb 6 for debugging info showing the transformation of
src/dest addresses in packets.
Add the following to the affected client OpenVPN configuration file:
client-nat dnat 10.64.0.0/255.255.0.0
client-nat snat 10.64.0.0/255.255.0.0
And try to connect to e.g. 10.64.1.42 instead of 192.168.1.42.
Notice while this may help, you'll certainly will need some debugging (use verb 6 in the config file or on the management channel). Also remember that anything like this is error prone, since it makes your network less clear and requires more concentration to understand what's going on and how to fix the problems. And it will in turn create another problems with IPSec or SIP or other complex protocols; this is inevitable.
To fix this without introducing murky configuration options, follow the suggestion of Esa Jokinen up there. I'll speak it in a broader way: since 192.168.0.x and 192.168.1.x happened to be the default on giant variety of home devices, never use those networks for office, and also probably 192.168.88.x should be included into the stop list as well, because it's the default for Mikrotik devices, which are quite popular too.
Renumbering the office network to never use those subnets will result in cleanest overall network design. (And this idea even extends to other networking experience as well, for instance, never use the default VLAN ID 1, and so on.)
The easiest and most confusing solution will be the following workaround. You cant just push "route 192.168.1.0 255.255.255.0", because you'll lose an access to all local resources. But you still can push the routes to individual addresses in the subnet. For instance, if many clients are affected, add the following line into the server's configuration:
push "route 192.168.1.42"
(the mask of 255.255.255.255 is assumed). The only case when this wouldn't work is that if the target client address in home network is 192.168.1.42; in this case nothing will help. Then restart the server. If only few clients are affected, you can skip server restart (which implies disruption), add route 192.168.1.42 to affected clients configurations and force them to reconnect.
