Here's the situation. I have two networks connected by VPN routers, 192.168.0.x and 192.168.2.x. On the 2.x network I have a Windows 2008 server configured with RRAS for use by VPN clients. The RRAS server assigns addresses in its own subnet for VPN clients, i.e. a VPN client will receive a 192.168.2.x address. What I need is for VPN clients to be able to access the 192.168.0.x network. I have found that by adding a static route on a client machine with the "route add" command I can get it to work. Here's the command I have to use:
route add 192.168.0.0 mask 255.255.255.0 192.168.2.45
192.168.2.45 is the VPN client's assigned IP, which changes every time the client connects. Is there any way to add this static route automatically with the correct gateway, when the client connects? So no matter what IP the client gets, they will always have a static route with the gateway the same as their IP?
I've tried adding static routes in RRAS and in Active Directory Users and Computers (under the user's properties, dial-in tab), but neither of those work, I suspect because I can't specify the gateway.
While messing around, I've discovered that doing a route add with the gateway set to the VPN router's IP and specifying the dial-up interface works as well, i.e.:
route add 192.168.0.0 mask 255.255.255.0 192.168.2.1 if 0x120006
However this is not a solution either, because the interface name changes every time the VPN connection is dialed.
Is there any possible way to do what I need here?
ASKER
-I'd rather not have to use the option "use default gateway on remote network" on the clients.
-The clients need to have access to both subnets at once, so assigning them an address in one subnet or the other makes no difference.
-I've had a look at that other question with the batch file, and well that is a solution (and a nice batch file) I'm looking for something that just works when they connect and won't require them to click on anything else.
Thanks for your comments. I have a feeling I may end up having to use the batch file :/
I'm going to keep looking for alternate solution for the time being, though.