Fix the IPsec client routing
Since a VPN tunnel is a routed connection, i.e. it connects different subnets, clients on each end of the VPN tunnel must send their packets to a router that knows where to send packets destined for clients at the opposite end. If your IPsec client and VPN router's WAN side both have public, i.e. routable IP address, you'll probably have no problem communicating once your IPsec tunnel is established.
If either or both of the IP addresses is private, however, you could be in for trouble if either the LAN or WAN-side clients have incorrect Gateways specified.
Clients on the LAN side of the VPN router will have the correct Gateway info as long as they use the router's IP address as their IP address Gateway - 192.168.1.1 in the example setup - because the router handles both Internet and VPN tunnel routing.
Figure 20: VPN router LAN side client routing
Figure 20 shows the output of the route print command (entered in a Command prompt or MS-DOS window) for our example LAN client. You can see that the default route - where data is sent if it doesn't match any other routes and indicated by 0.0.0.0 - is 192.168.1.1.
Gateway information for clients on the WAN side of the router may not be correct and need to be modified. In our example, the WAN-side client's IP address is 192.168.3.149, so its expected that its Gateway IP would be something in the 192.168.3.X subnet. Figure 21 shows the output of the route print command for our example WAN client.
Figure 21: WAN-side VPN client routing
You can see that the default route is 192.168.3.1, which happens to be the IP address of my LAN's main Internet-connected router. Although that router may know how to get our computer's data to and from the Internet, it doesn't know anything about the 192.168.1.X subnet at the other end of the test VPN tunnel. So if we fire up the tunnel that we just configured, we'll connect, then be very frustrated when nothing on the other end of the tunnel responds to a ping!