Site A Config

crypto isakmp key cisco address 192.168.10.10

crypto ipsec transform-set trans esp-3des esp-sha-hmac

crypto map vpn local-address FastEthernet0/1

crypto map vpn 10 ipsec-isakmp

description IPSEC to Site_B

set peer 192.168.10.10

set transform-set trans

match address 100

ip classless

ip route 0.0.0.0 0.0.0.0 192.168.0.1

ip route 172.16.100.0 255.255.0.0 192.168.10.10

access-list 100 permit ip 172.16.20.0 0.0.255.255 172.16.100.0 0.0.255.255

Site B Config

crypto isakmp key cisco address 192.168.0.10

crypto ipsec transform-set trans esp-3des esp-sha-hmac

crypto map vpn local-address FastEthernet0/1

crypto map vpn 10 ipsec-isakmp

description IPSEC to Site_A

set peer 192.168.0.10

set transform-set trans

match address 100

ip classless

ip route 0.0.0.0 0.0.0.0 192.168.10.1

ip route 172.16.50.0 255.255.0.0 192.168.0.10

access-list 100 permit ip 172.16.100.0 0.0.255.255 172.16.50.0 0.0.255.255

Hello Tung,

more clear now

in first post you wrote:

>> On our WAN-01 router we have a static route to 99.99.99.99 via MPLS ATM link (10.10.10.10). Trace route to 99.99.99.99 stop at 10.10.10.20 (ASA) never pass it. I looked on our WAN-02 and the route to 5.5.5.0 is via IPSEC tunnel

the ASA needs to know a path to come back.

if the net 5.5.5.0 is the source from which you try to connect/ping to 99.99.99.99

I don't see how the return path can be via the tunnel because it looks like you are using ipsec without a GRE tunnel

your ACL are:

access-list 100 permit ip 172.16.20.0 0.0.255.255 172.16.100.0 0.0.255.255

and

access-list 100 permit ip 172.16.100.0 0.0.255.255 172.16.50.0 0.0.255.255

traffic directed to 5.5.5.0 that I don't see in the picture shouldn't use the ipsec tunnel but should follow the default route via internet without any form of protection.

I would do the following:

(I suppose 5.5.5.0/24 is your return network to connect to/from server 99.99.99.99)

on WAn2 router

ip route 5.5.5.0 255.255.255.0 atm.next-hop.ip-address

so that you use on both directions the ATM backup to talk with the server 99.99.99.99

then you need to find out if ASA configuration is fine or it needs to be modified to make your setup to work correctly.

Hope to help

Giuseppe

Thanks you for you help. Will this change my traffic on site-B to route all traffic to site-A through ATM? I am assuming 5.5.5.0 is site-A internal network? The reason we use IPSEC VPN site-to-site is because it has a faster link over ATM. FYI. This was working fine on ATM before we switched to IPSEC VPN. Our IPSEC is working fine right now between two site but except this outsource apps.

Tung

There are a couple of things in what you posted that seem strange (and perhaps problematic):

- the access list 100 specifies addresses in which it seems that 3 octets are significant (172.16.20.0, 172.16.100.0, 172.16.50.0) but the mask used of 0.0.255.255 says that only 2 octets are significant. With that mask it is only matching on 172.16.

- the access lists should be mirror images of each other, but they are not:

access-list 100 permit ip 172.16.20.0 0.0.255.255 172.16.100.0 0.0.255.255

access-list 100 permit ip 172.16.100.0 0.0.255.255 172.16.50.0 0.0.255.255

But if you say that the IPSec is working for most things then I must assume that these do not matter and that there is some other issue.

When I hear that some application used to work and that it stopped working when it was put through IPSec I find that frequently it is a fragmentation issue. Try putting this command on the interfaces of the routers running IPSec:

ip tcp adjust-mss 1300

give it a try and let us know if it helps.

HTH

Rick

Rick,

You are right. I modified the access to private address for security reason but forgot to flip the mask to wild mask. After I added the access-list 100 to permit 99.99.99.99 to 172.16.50.0 and same on WAN-01 then I was able to successfully trace route to 99.99.99.99 but got timeout a few hop before it arrived at 99.99.99.99. This few hops is not listed on this diagram due to complicated routing we have. Thanks