Cisco ASA encrypts IP traffic not matching crypto ACL

[oldcreek12]

Hi, I encountered a situation that may totally change my understanding of how IPsec works ..., I need you guys help to clear my doubts. Refer to the following topology:

HostA(70.36.241.106) -----My VPN GW ----- Internet ----- Customer VPN GW (ASA) ---- Customer Internal network --- HostB(66.95.19.46)

Host A in my side needs to talk to host B in customer side securely over Internet, so we set up an IPsec tunnel between my VPN GW and Customer's VPN gateway with mirroring ACL (permit ip host 70.36.241.106 host 66.95.19.46), we reverse inject the /32 routes to our internal network, everything is fine, IPsec P1/P2 came up, we can ping each other, everything, IPsec security association in my side clearly shows that only traffic between the two /32 hosts is being encrypted.

But when I traceroute from my side HostA to customer side Host B, I see RFC1918 hops behind customer VPN GW in traceroute output, I am baffled, I can understand that customer will use RFC1918 addresses in their internal network, but how could those TTL expiration ICMP packets get passed beyond their side ASA? the traffic obviously does not match the crypto ACL, I expect to see *s until the last hop in my traceroute output.

Please help...

[Richard Bradfield]

can you show the output of the trace route

[oldcreek12]

hostA#sudo traceroute -In 66.95.19.46
traceroute to 66.94.19.46 (66.95.19.46), 30 hops max, 60 byte packets
1 169.254.44.186 76.586 ms 76.579 ms 76.578 ms
2 70.36.241.102 82.674 ms 82.674 ms 82.780 ms <please ignore the first two hops>
3 172.24.10.33 103.143 ms 103.255 ms 103.727 ms
4 10.184.96.42 104.748 ms 105.272 ms 106.007 ms
5 10.177.6.193 107.386 ms 107.529 ms 108.696 ms
6 172.24.0.178 108.795 ms 98.856 ms 100.991 ms
7 10.174.66.4 100.868 ms 100.308 ms 100.302 ms
8 10.174.66.11 100.596 ms 98.917 ms 98.966 ms
9 66.95.19.46 99.004 ms 98.888 ms 98.939 ms

[Richard Bradfield]

ok what are the IP addresses of the VPN gateways?

[oldcreek12]

my side is 70.36.241.102, customer side is 97.65.105.5, not sure how this is related, ipsec is operating at tunnel mode.

[Richard Bradfield]

so at the remote end is 172.24.10.33 the first address it hits on the customer network?

[oldcreek12]

Yes, it appears to be the case,any wild guess why ASA is behaving this way? I am sorry, I really don't get the questions you've been asking and which direction you are alluding to.

[Richard Bradfield]

well it looks as if the customers ASA has not been setup correctly, you should be seeing the * * * from those addresses 
do you have the relevant ASA configuration

[oldcreek12]

Yes, I checked the snippet of ASA, and as I mentioned in my original post, the crypto ACL is /32 host to host, otherwise phase II won't come up, right?

[Richard Bradfield]

On the ASA can you do a

"show crypto ipsec sa peer 70.36.241.102"

see what SAs are active

[oldcreek12]

ASA5555-1# sh ipsec sa peer 70.36.241.102

peer address: 70.36.241.102

    Crypto map tag: CoreNET_VPN, seq num: 930, local addr: 97.65.105.5

      access-list Crypto_ACL extended permit ip host 66.95.19.46 host 70.36.241.106

      local ident (addr/mask/prot/port): (66.95.19.46/255.255.255.255/0/0)

      remote ident (addr/mask/prot/port): (70.36.241.106/255.255.255.255/0/0)

      current_peer: 70.36.241.102

[Richard Bradfield]

can you show me the full output from that command

[oldcreek12]

There is nothing suspicious there, just counters ... Thank you for your time.