If you want to allow absolutely all traffic through the tunnel, you can remove your nat configs on the remote router. Is there a firewall or anything that could be dropping the traffic on the HQ side?
You can also get rid of your route statements. When the ipsec tunnel is created, the "route" is what's allowed through the tunnel. So, here's what I would do in order:
1. Make a backup of your remote site router.
2. Remove nat configs from fa4, vlan1, and bvi1
3. remote ip nat inside x.x.x.x.x statement
4. remove route-map
Your tunnels will still come up when it sees that you need to go to the 192.168.1.0 subnet through your crypto map peer statement.
Also, I noticed that your acl on HQ is listed under one crypto map. Crypto acls should mirror each other, but you have:
HQ: 192.168.1.0 192.168.2.0
192.168.1.0 192.168.3.0
Since you're only using one crypto map, it's going to try to match these networks on BOTH of your remote routers. So, I would create another crypto map for just your two separate networks:
crypto map to-site1 10
set peer 41.222.x.3
match address site1
access-list site1 permit ip 192.168.1.0 0.0.0.255 192.168.2.0 0.0.0.255
crypto map to-site1 20
set peer 41.222.x.4
match address site2
access-list site2 permit ip 192.168.1.0 0.0.0.255 192.168.3.0 0.0.0.255
The above would match the remote's crypto acl of "192.168.2.0 0.0.0.255 192.168.1.0 0.0.0.255" (but in reverse).
You'll still just have the one crypto map, but with different sequence numbers. If you decide to go with these changes, make sure you do them after hours because your tunnels will come down until the change is made.
One last thing, if you remove the nat config on the remote router and they decide it's too much traffic on HQ and want to revert back, you'll need to redo your nat configs again.
Remember *Make backups* :)
HTH,
John
HTH,
John
*** Please rate all useful posts ***
