09-05-2009 02:36 AM - edited 03-04-2019 05:57 AM
What is difference between these two commands when I apply them on interface?
Solved! Go to Solution.
09-05-2009 03:08 AM - last edited on 09-03-2023 10:54 PM by Translator
Hi Sasha,
The
ip access-group
references a stateless ACL. All packets flowing through an interface where this ACL is placed in a particular direction will be permitted or dropped according to the entries in this ACL.
The
ip inspect
does not by itself filter any packets. However, it inspects them - it looks into them and tries to determine the protocol, port, perhaps even application data that is transported inside the inspected packets. Basing on the information gained by this analysis, the
ip inspect
then builds a session table. The session table therefore contains information about all sessions (conversations, if you so call them). And now comes the most interesting part: when a reply packet arrives in the opposite direction, the router consults this session table and if the packet indeed belongs to a known session, the router will bypass the ACL placed on interfaces and allow this packet to go through.
The
ip inspect
mechanism is also called the CBAC - Context-Based Access Control, and it is used to create stateful firewalls, that is, firewalls that are able to identify individual conversations and once a particular connection has been permitted from inside to outside, the reply in the opposite direction will be permitted automatically, without having the permit it in any additional ACL.
The CBAC knows many higher-level protocols and it is also able to cope with protocols that use random ports and where it is almost impossible to effectively control such traffic using static ACLs.
The
ip inspect
and
ip access-group
are often combined, for example:
ip inspect name MyFW tcp
ip inspect name MyFW udp
ip inspect name MyFW icmp
access-list 100 deny ip any any
interface Fa0/0
ip inspect MyFW in
ip access-group 100 out
Here, the router allows any traffic to enter the the
Fa0/0
(there is no
ip access-group
for the inbound direction). Furthermore, it makes a note of each TCP, UDP or ICMP conversation that was initiated by a packet entering the
Fa0/0
(the
ip inspect
in the inbound direction). When a reply packet in this conversation arrives, the router will first consult the session table created by the
ip inspect
and if there is a corresponding session entry for this packet, it will be allowed to go out the
Fa0/0
However, if there is no session information for this packet in the session table, it will be subjected to the ACL 100 which will drop it.
Essentially, I have built here a simple stateful firewall: I allow any connection initiated from an inside network. However, I will permit only responses to be sent back to the inside network. No connections initiated from outside will be permitted to go to the inside network.
So once again: the
ip access-group
filters packets right there, according to a given ACL. The
ip inspect
makes a table of conversations and "temporarily opens holes" in ACLs in the opposite direction to allow a bidirectional communication for each conversation.
Best regards,
Peter
09-05-2009 03:08 AM - last edited on 09-03-2023 10:54 PM by Translator
Hi Sasha,
The
ip access-group
references a stateless ACL. All packets flowing through an interface where this ACL is placed in a particular direction will be permitted or dropped according to the entries in this ACL.
The
ip inspect
does not by itself filter any packets. However, it inspects them - it looks into them and tries to determine the protocol, port, perhaps even application data that is transported inside the inspected packets. Basing on the information gained by this analysis, the
ip inspect
then builds a session table. The session table therefore contains information about all sessions (conversations, if you so call them). And now comes the most interesting part: when a reply packet arrives in the opposite direction, the router consults this session table and if the packet indeed belongs to a known session, the router will bypass the ACL placed on interfaces and allow this packet to go through.
The
ip inspect
mechanism is also called the CBAC - Context-Based Access Control, and it is used to create stateful firewalls, that is, firewalls that are able to identify individual conversations and once a particular connection has been permitted from inside to outside, the reply in the opposite direction will be permitted automatically, without having the permit it in any additional ACL.
The CBAC knows many higher-level protocols and it is also able to cope with protocols that use random ports and where it is almost impossible to effectively control such traffic using static ACLs.
The
ip inspect
and
ip access-group
are often combined, for example:
ip inspect name MyFW tcp
ip inspect name MyFW udp
ip inspect name MyFW icmp
access-list 100 deny ip any any
interface Fa0/0
ip inspect MyFW in
ip access-group 100 out
Here, the router allows any traffic to enter the the
Fa0/0
(there is no
ip access-group
for the inbound direction). Furthermore, it makes a note of each TCP, UDP or ICMP conversation that was initiated by a packet entering the
Fa0/0
(the
ip inspect
in the inbound direction). When a reply packet in this conversation arrives, the router will first consult the session table created by the
ip inspect
and if there is a corresponding session entry for this packet, it will be allowed to go out the
Fa0/0
However, if there is no session information for this packet in the session table, it will be subjected to the ACL 100 which will drop it.
Essentially, I have built here a simple stateful firewall: I allow any connection initiated from an inside network. However, I will permit only responses to be sent back to the inside network. No connections initiated from outside will be permitted to go to the inside network.
So once again: the
ip access-group
filters packets right there, according to a given ACL. The
ip inspect
makes a table of conversations and "temporarily opens holes" in ACLs in the opposite direction to allow a bidirectional communication for each conversation.
Best regards,
Peter
09-05-2009 04:54 AM - last edited on 09-03-2023 10:57 PM by Translator
BTW, there's a 3rd option,
reflexive
ACLs. They too build a state table, but don't require an advanced IOS feature set. However, I believe they might only accept a direct mirroring of ports.
09-05-2009 05:01 AM - last edited on 09-03-2023 10:59 PM by Translator
Joseph,
You are completely right, and as a matter of fact, I was just waiting for somebody to mention them here
reflexive
ACLs can be considered as the predecessors of the CBAC. They indeed create a state table - the
reflexive
ACL itself. However, they are created on-the-fly just by simply reversing the sender and destination information (protocol, address, port). They do not do Layer7 inspection like CBAC does and if an application uses dynamic ports (passive FTP, peer-to-peer networks and the like), they are not applicable.
Best regards,
Peter
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide