There are 3 basic issues here.
1. The tunnels must be set up with Proxy-ID's that support both remote
networks. Otherwise those packets will not be able to travel over the
tunnel regardless of what is done at each end. Different boxes support one
or more of these methods:
a) Two phase 2's bound to a single phase 1, each of which supports a
different /24 to cover both remote sites
b) One phase 2 with proxy ID's with a wider netmask to include all remote
networks -- in this case site 2 can use 192.168.1.0/23 but site 2 can only
use 192.168.0.0/22, which will encompass 1 extra network *and* the local
addresses which it should be smart enough not to put in the tunnel... this
is likely a problematic method.
c) Open or wildcard proxy id's of 0.0.0.0/0 to allow anything in each
tunnel, controlled then by some other sort of routing on the box. Your best
bet option. Sites will need to be either static IP's or will need an extra
identifier to facilitate tunnel selection at the hub.
2. Once the correct proxy ID's are specified, each site box must know how
to put only the correct traffic into the tunnel (especially with option c
3. The hub must know how to route traffic that comes out of one tunnel, in
to another tunnel, and the reverse, when appropriate.
You will have to have addressed all threee of these issues in order to
succeed at this hub-and-spoke vpn.
More detail please. traceroute to 192.168.4.1, should hop out the internet
and die there, not die at the gateway. From any site.
Try traceroute 192.168.3.1 from site1, does it die at site2 gateway (bad
tunnel) hub gateway (bad step 3 above) or site 2 gateway (bad step 2 above
at site 2)?
Same test from site2...