ASA/PIX vs ACLRouter ACL‏

[steven.pw.lau]

Hi,

I've a question regarding the email topic:

How's the behavior of ASA/PIX ACL vs Router ACL?

Let's say for Router:

R1 (s0/0) --- (s0/0) R2 --- CS-ACS

- R1 has an inbound ACL on interface s0/0

- R1 and R2 running OSPF

- Therefore, we need a "access-list permit 120 ospf host (R2_s0/0) host (R1_s0/0)" to allow OSPF adjacencies to be up and advertise networks

- R1 will also need to have another ACL to enable RADIUS "access-list permit udp 120 host (CS-ACS) host (R1_s0/0) eq 1645"

However, for a PIX/ASA case:

PIX/ASA (outside) --- (s0/0) R2 --- CS-ACS

- PIX/ASA does not require any ACL to achieve the above (unless for traffic transiting the PIX/ASA, then we need to allow outside to inside ACL)

The ACL implementation are totally different for both devices. Can anyone help to explain the above behavior and point me to a URL which have a good explaination? :)

Thanks...

[Herbert Baerten]

Well, there are a lot of differences, but the main difference here is:

- IOS ACL (without IOS FW aka ip inspect) is packet based, i.e. every packet entering/leaving the interface is matched against the inbound/outbound ACL.

- PIX/ASA is connection based, and only checks traffic transiting the firewall. Traffic that is part of connections originating from the ASA (e.g. Radius) is always permitted.

Connections destined to the firewall (e.g. ping, SSH to the ASA) are controlled by other means (e.g. the icmp and ssh commands).

So for the Radius example: as soon as the ASA sends an Access-Request, it will create a conn(ection) in its internal conn table and set a timer. When the radius reply comes back from ACS (before the timer expires), it accepts it because it is part of the conn.

Let me know if this helps.

[steven.pw.lau]

This explaination clear things up.

Thanks.