From: JF Mezei on
I've managed to get reflective ACL working. However, it adds ACL rules
at the end of the ACL. Lots of rules when the LAN side machine makes a
lot of connections to the outside world.

It creates a lot of redundant entries at the bottom such as :

permit tcp host 190.10.0.111 eq 52140 host 64.235.219.134 eq 6881

even though the acl already contains a :
permit tcp any any eq 6881


From a performance point of you, is it better to use the "established"
mechanism for tcp and use reflective only for udp ? This would greatly
reduce the number of dynamic entries in the ACL.


for instance:

ip access-list extended ACLinbound
evaluate Reflect_outbound
permit tcp any any established
permit tcp any 10.0.0.0 0.0.255.255 eq www
deny tcp any any eq 445


ip access-list extended ACLoutbound
permit tcp any any
permit udp any any reflect Reflect_outbound


For tcp, does the reflective mechanism provide any additional
functionality that the "established" mechanism doesn't ?
From: Rob on
JF Mezei <jfmezei.spamnot(a)vaxination.ca> wrote:
> I've managed to get reflective ACL working. However, it adds ACL rules
> at the end of the ACL. Lots of rules when the LAN side machine makes a
> lot of connections to the outside world.
>
> It creates a lot of redundant entries at the bottom such as :
>
> permit tcp host 190.10.0.111 eq 52140 host 64.235.219.134 eq 6881
>
> even though the acl already contains a :
> permit tcp any any eq 6881
>
>
> From a performance point of you, is it better to use the "established"
> mechanism for tcp and use reflective only for udp ? This would greatly
> reduce the number of dynamic entries in the ACL.

That is what I did. If it is much better, I don't know. At least
it looks much more tidy.

Some purists will argue that "established" is a leak because it permits
traffic like RST or SYN ACK packets to a nonexisting connection, but I
don't see it as a real problem.