Do different Cisco ASAs handle IPSec tunnels differently?

[Cartesian]

I have on my network two different models of Cisco ASA which seem to operate differently from each other.  Can anyone confirm that this is the case?

Device type A is a Cisco Firepower 4120 running ASA version 9.18.(4)34 in Multi-Context mode.
When configuring IPSec tunnels in this version, I create an ACL which is used by a Crypto Map, which is applied to an interface (outside).  I also create a deny all ACL and apply it to the outside interface both inbound and outbound.

Device type B is a Cisco Firepower 2130 running ASA version 9.20(3)7 in Single-Context mode.
When configuring IPSec tunnels in this version, I create an ACL which is used by a Crypto Map, which is applied to an interface (outside).  However, the traffic does not flow unless there is also an associated permit statement in an ACL on the interface, both inbound and outbound.

In the past, I've only seen devices that work like Device A: you configure the interface ACLs to deny the traffic, and the Crypto Map allows the traffic when it's encrypted.  A permit statement on the interface would allow the traffic to flow unencrypted if the tunnel fails to form...wouldn't it?

Does anyone know from experience or documentation if these two ASA versions truly have such different behavior and configuration needs, despite using the exact same words in their configs?

[GolegPowerC]

do:

sh run all | inc sysopt

sysopt connection permit-vpn allow vpn traffic independent of the ACL on interface

[MHM Cisco World]

Local-Subnet & Remote-Subnet 

Crypto map ACL will be 

Local-Subnet to Remote-Subnet 

ACP 

A- apply to inside 

Local-subnet to Remote-subnet

B- apply to outside 

Remote-subner to local-subnet

MHM

[Cartesian]

This reply isn't in English.

[MHM Cisco World]

what is not clear 
your mistake is you use same ACL for crypto map and ACP

MHM

[Cartesian]

I'm not using ACP and didn't ask how to configure it. I know that the configuration works; I was asking if and why it is needed. You didn't comprehend the question at all, so your reply was confusing.

Now that I understand it, it's still wrong because you would apply the "A" ACL to the outside interface, outbound instead of the inside interface.

[MHM Cisco World]

sorry but I deal with many topic in same time

from cisco doc.

""sysopt connection permit-vpn will bypass ACLs (both in and out) on interface where crypto map for that interesting traffic is enabled, along with egress (out) ACLs of all other interfaces, but not the ingress (in) ACLs.""

I dont think there is chnage in behave of ASA and ASA(firepower) but there is different in ACL you apply in each of FW

MHM

[balaji.bandi]

As per my experience, Command syntax may vary, but operational wise they should work as expected, Especially when you mentioned ACP.

By default most of the ASA or any firewall default rule is deny.

Multi-context  some of the configuration inherited with system context. but you can look in the configuraiton.

[wajidhassan]

Hi @Cartesian ,

Yes, what you're seeing is expected — Cisco ASAs can behave differently depending on the ASA version, mode (single vs. multi-context), and platform architecture (classic ASA vs. Firepower hardware).

In your case:

• Device A (4120, ASA 9.18, multi-context) follows the traditional ASA behavior, where encrypted traffic defined in the crypto ACL bypasses interface ACLs. So even with a deny ACL on the outside interface, IPSec-encrypted traffic is allowed through as long as the crypto map matches.

• Device B (2130, ASA 9.20, single-context) introduces behavior where interface ACLs also inspect IPSec traffic, especially with certain features like Unified ACL (UACL) or platform-specific enhancements. In this setup, you must explicitly permit traffic in the interface ACL, even if it’s encrypted — otherwise, it gets dropped.

This change is noted in release documentation starting around ASA 9.19+, particularly with single-context mode and Firepower platforms. So even if config syntax looks identical, the underlying traffic handling can differ.

To maintain compatibility:

• Review the ACL processing model and any changes in release notes.

• Use show access-list and show asp table classify to see how traffic is matched.

• Consider adding explicit permit rules for IPSec traffic on newer ASA models.

Hope that clears up the difference.

[Cartesian]

Thank you!

Is there any config option in ASA 9.20 to make it behave like 9.18, and allow traffic without an interface ACL entry? This is causing problems with my security documentation, which currently can't handle firewalls with different ACL needs from each other.

If there is no such config, I'll survive. I'll just get asked about it in review every quarter...

[Marvin Rhoads]

@Cartesian beware misleading AI-generated answers as they may appear comprehensive and thoughtful but are often misleading and riddled with inaccuracies.

Check your two running-configs for "sysopt permit-vpn". Lack of that command requires you to apply an ACL to permit traffic allowed by the VPN crypto map.

[Cartesian]

Ah, thanks for the heads-up.

I did confirm that both devices have sysopt permit-vpn configured.  However there are some NAT rules that might be messing with the traffic.  My next step is to take a dev firewall and wipe it to base configs, then see if I can form a tunnel to it without the ACL rules applied to the outside interface.

[Marvin Rhoads]

The outside interface ACL is generally not material as the outside interface does not see the actual (unencrypted) endpoint flows. It only sees IPsec to/from the remote peer.

Inside interface ACL is only relevant in the absence or sysopt permit-vpn.

NAT statements can indeed affect the flows. Most commonly, we exempt site-to-site VPN traffic from NAT (unless you are dealing with a third party who has IP address conflicts or requirements that you NAT your traffic to ensure its address uniqueness).

Finally, note that the sysopt commands can be hidden and only appear in "show run all" unless you have an explicit statement to override the default behavior.