255 possible network addresses in the 192.168 RFC pool and (almost) everybody uses the same one. It's really not supposed to be that way, but the tendancy is to open the new network goodies, throw it on the net, and if it works with the defaults then let it run.
Before this goes too much farther, should note that your issue is one related to routing, not the core VPN connection. You should be able to reach resources on the VPN server without doing anything else, simply by using the VPN server tunnel address. You will not, however, be able to route to your server side network without a lot of work.
Solutions . . . well, the best long term solution would be to change your server side network address. Your present configuration will probably cause a problem somewhere else sooner or later, anyway. If your only objection to changing your network is the time and energy required to get everything working again and the VPN connection is of any importance at all, that is the way to go. I'll discuss some other options, but although they should work, they will be more work than renumbering your network.
If you do decide to renumber, try to do it right. The network address should be random within the range specified by the RFC. You should carfully select a network address without giving it any thought at all! Sounds wierd, doesn't it. The 192.168 is good, but the third octet is the problem. Best procedure for picking that number . . .
Get 255 small pieces of paper. Write a number on each, starting with 0 and moving on to 254. These represent the possible third octet of your network address. Grab the trash can and throw 0 in there. This is the default for many network gadgets, so a lot of people are using it. There are also devices that use 1 for a default, so throw that out as well. 2 - 5 go in the trash because often people with more than one net address to deal with just increment by one. 5 should get you past that. Discard 20 - 22, 48, 100 and 200, some well intentioned authors have suggested those addresses in their books in an effort to eliminate the problems you are having without really explaining the proper procedure. I'm sure there are others that fall into that catagory, but those are the ones I've run across. 127 and 254 go in the trash because there is a certain amount of network gear that doesn't deal with it well. You should now have 241 pieces of paper. Throw them in a hat, stir well and pick one. Now you have your new address. We all know that's the easiest part of the deal, but you still have to do it right.
Now, I promised some other options. They all have some problems, but here goes.
First would be to run some form of simple one - to - one NAT on the VPN server for the VPN connection. Don't know if that is really even an option with a MS box, but it can work fairly well with a Linux box running netfilter/tables. Basically, your the NAT would take your 192.168.0 addresses and convert them to 192.168.something_else for your VPN connection. Setting up proper name resolution is the hardest part of that one, agian given a Linux box in the picture.
Next option would be to modify the routing table on the client computer after the connection is made. You would need to add a host route to each of the servers that you need on your VPN server side. If you are using CMAK to make your client side VPN connection, you could use CMRoute to deal with this, otherwise you would need to write a script for the user to run after the connection is made. The latter would require that your clients are getting fixed IPs for their VPN endpoint. The problem here is that if one of your server computers has the same IP as the router, dns server, etc on the client side network you would loose connectivity to that device. In the case of the gateway on the client side having a duplicated address, you would loose connectivity altogether.
Third option would be to move all of the services that you really need to the VPN server, or proxy them there depending upon the type of service. Many MS services don't like to play with RRAS on the same box, so that creates it's own little problem. Exchange server is particuarly bad. Not fun, at the very least.
Sorry for the long winded post, perhaps got a little carried away. Hope this gives you some idea of the fun you have ahead of you.
