Fix the IPsec client routing (cont'd)

More sophisticated VPN gateways and IPsec client applications handle this problem by assigning virtual IP addresses to VPN clients during the authentication process. These virtual IPs are in the same subnet as clients on the gateway's LAN side, so for all intents and purposes, the client on the remote end of the tunnel looks like a full-fledged member of the local LAN.

Unfortunately, we're running a low-budget operation and neither the SX41 nor Microsoft's IPsec client can handle virtual IPs. So we have to solve the problem by fixing the Gateway IP address so that it properly points to the VPN router's WAN side IP address, i.e. 192.168.3.254.

If for some reason we need to use one router to get to the Internet and another for our VPN tunnel, adding a static route on the WAN client will make everything work. To do this for our example, just open up a Command prompt (MS-DOS) window and type:

route add 192.168.1.0 mask 255.255.255.0 192.168.3.254

This says to your client, "take all the data intended for any IP address between 192.168.1.1 and 192.168.1.254 and send it to 192.168.3.254".

Figure 22: WAN LAN client routing with 192.168.1.0 static route added

Figure 22 shows the output of a route print run after the route is added. Since 192.168.3.254 is the WAN IP address of the SX41, and the remote end of our VPN tunnel, our data will now properly find its way and your ping (and everything else) should work. Note that the default gateway for all other traffic (including Internet) remains 192.168.3.1.

TIP: If you're running Win2000 or XP, you can use the "-p" option of the router add command, i.e. route add -p 198.168.1.0 ... to create a persistent static route that will be there next time you boot.

If you're running earlier Windows OSes, just open Notepad, type in the desired "route add ..." command, save as routeadd.bat and put a copy in your Startup folder. This will run the batch command every time you boot and add the desired route.