processing order of encryption and ACL

[m_breuer]

Hi folks,

I am preparing a test lab and have the following scenario:

R6 ----172.16.50/24 --- PIX ---- 172.16.10/24 --R1

On R6 I have two interfaces:

lo0 6.6.6.6/24

fa0/1 172.16.50.50/24

On R1 two int:

lo0 1.1.1.1/24

e0 172.16.10.1/24

I want to protect all traffic between network 6.6.6.0 and network 1.1.1.0 with IPSec. To protect the traffic I am using ESP.

Another requirement is that I want to put an ACL on e0 which only allows the IPSec traffic.

I have created an ACL named ACL_E0_IN which is applied on e0 for inbound traffic.

R1#sh access-lists

Extended IP access list ACL_E0_IN

permit esp host 172.16.50.50 host 172.16.10.1 (15 matches)

permit udp host 172.16.50.50 host 172.16.10.1 eq isakmp (116 matches)

deny icmp host 6.6.6.6 host 1.1.1.1 log (5 matches)

Ping from R6 to R1 doesn't work:

R6#p 1.1.1.1 source lo 0

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:

Packet sent with a source address of 6.6.6.6

.....

Success rate is 0 percent (0/5)

R6#

On R1 I get the following log message:

*Mar 8 03:58:37.917: %SEC-6-IPACCESSLOGDP: list ACL_E0_IN denied icmp 6.6.6.6 -

> 1.1.1.1 (8/0), 4 packets

This scenario works ONLY when I allow ESP and ICMP traffic from R6.

I am wondering why the decrypted packets are denied by the ACL. I would expect that the ACL is processed BEFORE the packet is decrypted. When I look at the counter on the ACL hit, it looks that the ACL is examined twice.

Has anyone an idea about the exact order of encryption and ACL processing?

Thanks

Michael

Attached you will find the configs of R1 and R6

[Richard Burts · Accepted solution]

Michael

I have recently seen an explanation of encryption and ACL which indicates that there has recently been a behavior change. In most versions of IOS the behavior is as you describe, the packet is evaluated by the ACL twice. The explanation was that the packet is evaluated first in its encrypted state to verify that it was something that should be processed. After the packet was decrypted, the IOS needed to evaluate the unencrypted packet to see whether things like QOS needed to be applied. So basically the unencrypted packet was passed through the interface again and through the ACL again. In very recent versions of code (12.3(4)T if memory serves me right) a change was made and the packet now will go through the ACL only once.

HTH

Rick

[m_breuer]

Hi Rick,

thanks for your answer. In the meantime I found this document where the new and old behaviour is explaned.

The feature is called "Crypto Access Check on Clear-Text Packets" and was introduced in 12.3(8)T:

http://www.cisco.com/en/US/products/sw/iosswrel/ps5207/products_feature_guide09186a008022c2a5.html