Reflexive ACL behaviour

[snarayanaraju]

Hi friends,

A basic doubt.

I am checking REFLEXIVE ACLs. During Lab i found this behaviour.

152.50.12.1 (R1)-----(R2) 150.50.7.7

where 150.50.12.1 is untrusted & 150.50.7.7 is trusted.

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

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

below:

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

I thought after this temperory ACL creation, I should be able to ping from

150.50.12.1 to 150.50.7.7. But it failed to ping even though I am able to

ping 150.50.12.1 from 150.50.7.7

Is this a normal behaviour?

Thanks for valuable answers

sairam

[Peter Paluch]

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,

Peter

[snarayanaraju]

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

Sairam

[Peter Paluch]

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,

Peter