I have two ASAs, one in our local office with a private range behind it of 192.168/16, and another in a remote location with two networks behind it: 10.100/16 and 10.1/16. I am able to pass traffic successfully between the 192.16 and 10.1 networks. I cannot however get traffic to go between the 192.168 and the 10.100. This worked for over a year until a couple of days ago. As usual, no one did anything to change the config, but it just stopped working. I will admit that we are using 8.2(2) code, but again this worked reliably until this week. I can clearly see using the sh isakmp commands that traffic is being encrypted from the 192.168 side, but on the 10.100 side nothing is being encrypted. The relevant ACLs are also not showing a hit rate when I use sh run access-list, but if I do a packet-tracer it shows hits and says that traffic should pass normally. I'm wondering if there's an ACL that's causing issues. Here are relevant parts of my config from the 10.100 side of the connection (IPs changed to protect the innocent):
ip address 10.100.10.2 255.255.0.0 standby 10.100.10.3
ip address 188.8.131.52 255.255.255.192 standby 184.108.40.206
access-list inside_nat0_outbound extended permit ip 10.100.0.0 255.255.0.0 192.168.0.0 255.255.0.0
access-list inside_nat0_outbound extended permit ip 10.1.0.0 255.255.0.0 192.168.0.0 255.255.0.0
access-list inside_nat0_outbound extended permit ip 10.100.0.0 255.255.0.0 10.1.0.0 255.255.0.0
access-list inside_nat0_outbound extended permit ip 10.1.0.0 255.255.0.0 10.100.0.0 255.255.0.0
access-list inside_nat0_outbound extended permit ip 10.100.0.0 255.255.0.0 10.100.0.0 255.255.0.0
access-list outside_cryptomap extended permit ip 10.100.0.0 255.255.0.0 192.168.0.0 255.255.0.0
access-list nexus_splitTunnelAcl standard permit 10.100.0.0 255.255.0.0
access-list nexus_splitTunnelAcl standard permit 10.200.0.0 255.255.0.0
access-list nexus_splitTunnelAcl standard permit 10.110.0.0 255.255.0.0
access-list nexus_splitTunnelAcl standard permit 10.1.0.0 255.255.0.0
global (outside) 1 interface
nat (inside) 0 access-list inside_nat0_outbound
nat (inside) 1 10.20.0.0 255.255.255.0
nat (inside) 1 10.1.0.0 255.255.0.0
nat (inside) 1 10.100.0.0 255.255.0.0
nat (inside) 1 10.105.0.0 255.255.0.0
access-group outside_access_in in interface outside
split-tunnel-network-list value nexus_splitTunnelAcl
default-domain value ourdomain.com
split-dns value ourdomain.com ourdomain.net
tunnel-group nexus type remote-access
tunnel-group nexus general-attributes
tunnel-group nexus ipsec-attributes
tunnel-group 220.127.116.11 type ipsec-l2l
tunnel-group 18.104.22.168 ipsec-attributes
Of note is that the ASA on the remote side also provides remote access vpn, and using that connection clients are able to successfully get to the 10.100 and 10.1 networks, but not the 192.168 network either. I have verified that the tunnel is actually up, active, has the same parameters, etc. Any ideas based on this output?
I should add that the remote access clients use 10.100.15.0 (with a /16 mask) as their pool as well. I know, overlapping IP ranges are absolutely bad, but that was how it was set up (I inherited this network). So I assume that that's why the split tunneling is in there, but it's possible that the split tunneling ACL is causing some issues?
sa timing: remaining key lifetime (kB/sec): (3915000/26803)
IV size: 16 bytes
replay detection support: Y
Anti replay bitmap:
The outbound spi matches the one that's not encrypting anything. The inbound spi matches the one that *is* decrypting. But, I thought the bug was fixed in 8.2.2 so I don't want to assume. Can anyone confirm these findings?
Table of ContentsIntroductionVersion HistoryPossible Future
UpdatesDocuments PurposeNAT Operation in ASA 8.3+ SectionsRule Types
Network Object NATTwice NAT / Manual NATRule Types used per SectionNAT
Types used with Twice NAT / Manual NAT and Network Obje...
Table of Contents Introduction:This document describes details on how
NAT-T works. Background: ESP encrypts all critical information,
encapsulating the entire inner TCP/UDP datagram within an ESP header.
ESP is an IP protocol in the same sense that TCP an...