When starting out with IPsec tunnels it seems to be a common misconception that the crypto ACL, sometimes referred to as the encryption domain or the interesting traffic, must match 100% or be mirrored at both peers or the tunnel won’t come up. This isn’t strictly true. Whilst the ISAKMP phase 1 and IPsec phase 2 proposals must match, the crypto ACL can be different.

Assume that at the local peer traffic to be encrypted originates from 10.0.0.0/24 and is destined for 192.168.0.0/24. The crypto ACL would be:

access-list crypto_acl permit ip 10.0.0.0 255.255.255.0 192.168.0.0 255.255.255.0

access-list crypto_acl permit ip 192.168.0.0 255.255.255.0 10.0.0.0 255.255.255.0

But what about the following?

access-list crypto_acl deny ip 10.0.0.0 255.255.255.0 host 192.168.0.200
access-list crypto_acl permit ip 10.0.0.0 255.255.255.0 host 192.168.0.100

access-list crypto_acl permit ip 192.168.0.0 255.255.255.0 10.0.0.0 255.0.0.0

IPsec phase 2 can still be established even though the crypto ACL isn’t mirrored at the local and remove peer. The local peer specifies 10.0.0.0/24 but the remote peer specifies 10.0.0.0/8. In this scenario IPsec phase 2 can only be initiated from the peer that has the larger subnet. This is true for both Cisco ASA and IOS.

And in the example above, in the local peer’s ACL there’s a deny ACE but none on the remote peer’s ACL. In this scenario any traffic originating on the local peer from 10.0.0.0/24 destined to 192.168.0.200/32 won’t traverse the tunnel. The device (ASA or IOS router) will look at the next crypto map in the sequence and try to match traffic there. If no crypto maps are found it’ll flow unencrypted out of the egress interface.

Obviously be careful with mismatching subnets and using deny ACEs in the crypto ACL because you may end up with traffic trying to enter the wrong tunnel and other strange things happening.