sysopt connection permit-vpn BROKEN???

[enkrypter]

Please help clarify:

I recently updated hardware and code from 5540 to 5545, 9.1(3) to 9.1(6).11

After the upgrade, I noticed the identical configuration on both units had drastically different results when "sysopt connection permit-vpn" is enabled.  (which it is by default)

My desires state of traffic flow on 9.1(3) was that remote originating traffic across an L-2-L VPN, with sysopt enabled, would be filtered by an outbound ALC on my inside interface.  (this is exactly how it functioned)

The undesired state, on the new code, with sysopt still enabled; traffic from the VPN blows right past the inside outbound ACL and gives no honey badgers.  (traffic originating from remote VPN hosts comes into the local ASA and ignores all egress ACLs on any interface)

So I called TAC and they dig this gem up: https://bst.cloudapps.cisco.com/bugsearch/bug/CSCuz24083

(filed recently)

My crypto-maps are on the outside interface, and from personal experience sysopt is ONLY supposed to ignore ACLs on interfaces that have crypto-maps.  Other interface egress ACLs are still processed.

(inside)[remote ASA](outside) <---- tunnel ----> (outside)[loca ASA](inside) -------> I've been filtering on the inside interface OUT

Here's a cisco thread form 5 years ago that clarifies the same understanding of how I'd like it to work and have observed it working in the past:  https://supportforums.cisco.com/discussion/10919996/sysopt-connection-permit-vpn

The forums are littered with people arguing sysopt functionality, so I agree clarification is needed.  I just want it to work the way I have been using it.  IMHO, the clarified description is NOT desirable.  I have proof that this functionality is different in two versions of the same code tree.

Please for the love of god, please tell me that someone else has had similar experiences with this on newer code and remembers how the old code used to work.  Getting Cisco to classify something as a bug and not a "feature" is like pulling teeth.

Bottom line, I have the same config on different code it operates different.

Thanks for reading.

[Philip D'Ath]

I must admit, I tend to turn "sysopt connection permit-vpn" off, which makes everything use ACL's, which makes everything crystal clear.

[Paul Chapman]

Hi Guys -

My understanding of this setting was that it bypassed all interface ACLs (ingress or egress).  Even the documentation reflects this idea. (Found Here)  Nothing I've found indicates any tie between this feature and crypto maps.

I find it likely that you were exploiting a code bug and that Cisco fixed it in the new code rev.  I also find it likely that it was not a highly reported issue to Cisco since most ASA admins [that I've spoken to] only use ingress ACLs as this is generally considered a best practice.

I had an 8 hour call with TAC in the last month where the bottom line is that we accidentally exploited a code bug in our configuration and the system broke when we rebooted the ASA.  It's not unheard of, and I do believe that you had a behavior change between code versions.

My recommendation is that you convert your egress ACL to a VPN Filter in your Group Policy to recover the restrictions you previously had.

PSC