09-18-2013 07:59 AM
Hi,
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):
interface Vlan1
nameif inside
security-level 100
ip address 10.100.10.2 255.255.0.0 standby 10.100.10.3
!
interface Vlan2
nameif outside
security-level 0
ip address 12.12.12.12 255.255.255.192 standby 12.12.12.13
*****
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
route outside 0.0.0.0 0.0.0.0 64.95.66.125 255
route inside 10.1.0.0 255.255.0.0 10.100.10.1 1
route inside 10.20.0.0 255.255.255.0 10.100.10.1 1
route inside 10.105.0.0 255.255.0.0 10.100.10.1 1
******
crypto map outside_map 2 match address outside_cryptomap
crypto map outside_map 2 set peer 13.13.13.13
crypto map outside_map 2 set transform-set ESP-AES-256-SHA
crypto map outside_map 65535 ipsec-isakmp dynamic SYSTEM_DEFAULT_CRYPTO_MAP
crypto map outside_map interface outside
******
crypto isakmp identity address
crypto isakmp enable outside
crypto isakmp policy 5
authentication pre-share
encryption aes-256
hash sha
group 5
lifetime 86400
crypto isakmp policy 10
authentication pre-share
encryption 3des
hash sha
group 2
lifetime 86400
crypto isakmp policy 30
authentication rsa-sig
encryption 3des
hash sha
group 2
lifetime 86400
crypto isakmp policy 65535
authentication rsa-sig
encryption 3des
hash md5
group 2
lifetime 86400
******
group-policy nexus attributes
dns-server value 10.100.10.89 10.1.20.254
vpn-tunnel-protocol IPSec l2tp-ipsec svc
split-tunnel-policy tunnelspecified
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
authentication-server-group ADdomain
default-group-policy nexus
dhcp-server 10.100.10.89
tunnel-group nexus ipsec-attributes
pre-shared-key *****
tunnel-group 12.12.12.12 type ipsec-l2l
tunnel-group 12.12.12.12 ipsec-attributes
pre-shared-key *****
*******
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?
Thanks.
09-18-2013 08:07 AM
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?
09-18-2013 09:53 AM
I did some more digging and found a bug whose diagnosis seems to be spot on with my problem. The only problem is the bug seems to have been fixed in 8.2.2...which I'm running.
Here is the edited output of
show asp table vpn-context detail | begin 192.168.0.0
on the remote asa that is having the problem:
Peer IP = 192.168.0.0
Pointer = 0xDB90DF80
State = UP
Flags = DECR+ESP
SA = 0x84876747
SPI = 0x260B1043
Group = 30
Pkts = 7752
Bad Pkts = 0
Bad SPI = 0
Spoof = 0
Bad Crypto = 0
Rekey Pkt = 0
Rekey Call = 0
VPN Filter =
Peer IP = 192.168.0.0
Pointer = 0xDACEAD38
State = UP
Flags = ENCR+ESP
SA = 0x8494204F
SPI = 0xCAFAFF70
Group = 0
Pkts = 0
Bad Pkts = 0
Bad SPI = 0
Spoof = 0
Bad Crypto = 0
Rekey Pkt = 0
Rekey Call = 0
VPN Filter =
Peer IP = 192.168.0.0
Pointer = 0xDC7AC570
State = UP+DIP
Flags = DECR+ESP
SA = 0x823F5ACB
SPI = 0x2F2E7807
Group = 10
Pkts = 149037
Bad Pkts = 0
Bad SPI = 0
Spoof = 0
Bad Crypto = 0
Rekey Pkt = 1
Rekey Call = 2
VPN Filter =
VPN CTX = 0x132AD1A4
Peer IP = 192.168.0.0
Pointer = 0xDA77A970
State = UP
Flags = ENCR+ESP
SA = 0x403FEBCB
SPI = 0x7F29531A
Group = 31
Pkts = 2784659
Bad Pkts = 0
Bad SPI = 0
Spoof = 0
Bad Crypto = 0
Rekey Pkt = 0
Rekey Call = 0
VPN Filter =
sh cry ip sa has the following output:
inbound esp sas:
spi: 0x260B1043 (638259267)
transform: esp-aes-256 esp-sha-hmac no compression
in use settings ={L2L, Tunnel, }
slot: 0, conn_id: 26402816, crypto-map: outside_map
sa timing: remaining key lifetime (kB/sec): (3914317/26803)
IV size: 16 bytes
replay detection support: Y
Anti replay bitmap:
0xFFFFFFFF 0xFFFFFFFF
outbound esp sas:
spi: 0xCAFAFF70 (3405447024)
transform: esp-aes-256 esp-sha-hmac no compression
in use settings ={L2L, Tunnel, }
slot: 0, conn_id: 26402816, crypto-map: outside_map
sa timing: remaining key lifetime (kB/sec): (3915000/26803)
IV size: 16 bytes
replay detection support: Y
Anti replay bitmap:
0x00000000 0x00000001
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?
09-18-2013 10:40 AM
Initiate the continuous traffic across the tunnel and take output of following command 2-3 times.
"show ipsec stats". If it increases "Missing SA failures:", it means you are hitting a bug.
Let me know if it helps.
Regards,
Naresh
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide