ASA 8.2(2) - Static L2L crypto map w/ dynamic SA policy creation?

Unanswered Question
Jul 20th, 2010

After moving several of our ASA 5505's over to 8.2(2) over the last few months, I've come across a strange issue on more than a few occasions where the ASA will allow a hard-configured (not a dynamic-map) L2L VPN tunnel to come up when the crypto ACL is not matched on both ends.

For example, our ASA w/ 8.2(2) will be configured with a policy of:

crypto map mymap 202 match address 202

access-list 202 extended permit ip 192.168.100.176 255.255.255.248 172.16.0.0 255.240.0.0

However, the remote site will have a policy specifying /32 hosts for their local network, obviously not a mirrored ACL:

crypto map theirmap 100 match address 100

access-list 100 extended  permit ip host 172.16.0.1 192.168.100.176 255.255.255.248

access-list 100 extended  permit ip host 172.16.0.2 192.168.100.176 255.255.255.248

access-list 100 extended  permit ip host 172.16.1.1 192.168.100.176 255.255.255.248

access-list 100 extended  permit ip host 172.16.1.2 192.168.100.176 255.255.255.248

access-list 100 extended  permit ip host 172.16.2.1 192.168.100.176 255.255.255.248

access-list 100 extended  permit ip host 172.16.2.3 192.168.100.176 255.255.255.248

~and so on...

The result? The IPSec tunnel will come up when traffic is initiated from their end, but not vise versa.

%ASA-7-714011: Group = x.x.x.x, IP = x.x.x.x, ID_IPV4_ADDR ID received 172.16.1.2
%ASA-7-713025: Group = x.x.x.x, IP = x.x.x.x, Received remote Proxy Host data in ID Payload:  Address 172.16.1.2, Protocol 0, Port 0
%ASA-7-715047: Group = x.x.x.x, IP = x.x.x.x, processing ID payload
%ASA-7-714011: Group = x.x.x.x, IP = x.x.x.x, ID_IPV4_ADDR_SUBNET ID received--192.168.100.176--255.255.255.248
%ASA-7-713034: Group = x.x.x.x, IP = x.x.x.x, Received local IP Proxy Subnet data in ID Payload:   Address 192.168.100.176, Mask 255.255.255.248, Protocol 0, Port 0
%ASA-7-713906: Group = x.x.x.x, IP = x.x.x.x, QM IsRekeyed old sa not found by addr
%ASA-7-713221: Group = x.x.x.x, IP = x.x.x.x, Static Crypto Map check, checking map = mymap, seq = 200...
%ASA-7-713222: Group = x.x.x.x, IP = x.x.x.x, Static Crypto Map check, map = mymap, seq = 200, ACL does not match proxy IDs src:172.16.1.2 dst:192.168.100.176
%ASA-7-713221: Group = x.x.x.x, IP = x.x.x.x, Static Crypto Map check, checking map = mymap, seq = 201...
%ASA-7-713222: Group = x.x.x.x, IP = x.x.x.x, Static Crypto Map check, map = mymap, seq = 201, ACL does not match proxy IDs src:172.16.1.2 dst:192.168.100.176
%ASA-7-713221: Group = x.x.x.x, IP = x.x.x.x, Static Crypto Map check, checking map = mymap, seq = 202...
%ASA-7-713225: Group = x.x.x.x, IP = x.x.x.x, Static Crypto Map check, map mymap, seq = 202 is a successful match
%ASA-7-713066: Group = x.x.x.x, IP = x.x.x.x, IKE Remote Peer configured for crypto map: mymap

The traffic is matched against the crypto ACL with the encompassing subnet, and the SA is created with a /32 policy, even though we have it defined nowhere in our configuration:

Interface: outside
    Crypto map tag: mymap, seq num: 202, local addr: y.y.y.y

      access-list 202 extended permit ip 192.168.100.176 255.255.255.248 172.16.0.0 255.240.0.0
      local ident (addr/mask/prot/port): (192.168.100.176/255.255.255.248/0/0)
      remote ident (addr/mask/prot/port): (172.16.1.2/255.255.255.255/0/0)
      current_peer: x.x.x.x

      #pkts encaps: 48, #pkts encrypt: 48, #pkts digest: 48
      #pkts decaps: 48, #pkts decrypt: 48, #pkts verify: 48
      #pkts compressed: 0, #pkts decompressed: 0
      #pkts not compressed: 48, #pkts comp failed: 0, #pkts decomp failed: 0
      #pre-frag successes: 0, #pre-frag failures: 0, #fragments created: 0
      #PMTUs sent: 0, #PMTUs rcvd: 0, #decapsulated frgs needing reassembly: 0
      #send errors: 0, #recv errors: 0

      local crypto endpt.: y.y.y.y, remote crypto endpt.: x.x.x.x

      path mtu 1500, ipsec overhead 58, media mtu 1500
      current outbound spi: 13161FDC
      current inbound spi : 29F4B5ED

The only reason we caught this is because of complaints that the tunnel could only be initiatialized in one direction. The reason this is so strange to me is because it obviously goes against what I've known for years when troubleshooting site-to-site VPNs; the crypto ACL obviously needs to be matched and mirrored on each side.

Looking through the release notes on the 8.2(x) platforms, I find nothing about this 'feature'. Is this intended? A bug? The world of IPSec as I've known it (as well as my perception of reality) has been thrown into question..

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.

Actions

This Discussion