Reflexive ACL behaviour

Unanswered Question
Sep 13th, 2009

Hi friends,

A basic doubt.

I am checking REFLEXIVE ACLs. During Lab i found this behaviour. (R1)-----(R2)

where is untrusted & is trusted.

Reflexive ACLs are configured and working perfectly as expected. When I

initiated ICMP ping from it is creating Reflexive ACL in R2 as


permit icmp host host (10 matches) (time left 76)

I thought after this temperory ACL creation, I should be able to ping from to But it failed to ping even though I am able to

ping from

Is this a normal behaviour?

Thanks for valuable answers


I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (2 ratings)
Peter Paluch Sun, 09/13/2009 - 10:49

Hi Sairam,

It depends on how you set up both the pair of ACLs. Can you post the configuration of the router that contains the reflexive ACL?

Best regards,


snarayanaraju Sun, 09/13/2009 - 11:47

Hi Peter,

Configuration is done on R2

ip access-list TRUSTED-UNTRUSTED

permit ip any any reflect SAIRAM

ip access-list UNTRUSTED-TRUSTED

evaluate SAIRAM

interface ser 0/0

des #### UNTRUSTED #####

ip access-group UNTRUSTED-TRUSTED in

interface fa 0/0

des ##### TRUSTED #####

ip access-group TRUSTED-UNTRUSTED in

Peter, this is the snapshot of the configuration made on R2

Hope this is sufficient to help me


Peter Paluch Sun, 09/13/2009 - 12:37

Hello Sairam,

Your config is OK. I believe that the reason that it does not work lies in the fact that despite the "show access-list" command shows only the hosts and protocol in your reflexive ACL, internally the reflexive ACL holds more information about how the return packet should look like. I suspect that for ICMP, when you ping from inside to outside, the reflexive ACL will match for an ICMP echo-reply message. This would also explain why pinging from outside to inside does not work: the packets are of the type ICMP echo, not echo-request as the reflexive ACL entry expects.

Maybe you should try testing this with a real equipment and some packet generator that is able to generate a packet from an arbitrary port - the "netcat" utility for Linux can be used for that. I suggest using UDP packets as they have no state information in their header.

Best regards,



This Discussion