Re: Cisco ACL vs. iptables semantics
- From: "d" <persson@xxxxxxxxxxxx>
- Date: 18 Jan 2007 12:14:08 -0800
Walter Roberson wrote:
I'm not familar with the iptables fields, but I suspect that the
answer is NO.
*Every* Cisco ACL, for IOS and PIX, has an implied "deny everything"
at the end of it. Therefore your ip access-list extended blockssh
is equivilent to "deny ssh, and deny everything else too". If
the iptables entries you show do not have those semantics, then
they are not equivilent to the ACL.
Note: That's -every- Cisco IOS or PIX ACL, for every purpose I've
been able to find. But deny does not -always- mean "drop the traffic":
for example, in the context of Policy Based Routing (PBR), a deny in
the matching ACL just means that the policy is not in effect for
that denied traffic, and that it should be processed through any
remaining policies, with a default of going through regular
routing-table routing of none of the PBRs matched the packet.
Of course you are right, I should have phrased my question using better
Let's try: I know that ACLs "deny" does not always mean "block" or
But here, I was referring to a context of firewalling/packet filtering,
so "deny" should
really mean "drop" here. Then, you are right about the implicit deny at
the end of cisco
ACLs, but again I did not make clear what I was trying to understand.
Let's use the
incoming - first group of rules from my previous example, and assume
default policies are already
configured the same. My understanding (which of course could be wrong)
is that, if a cisco router is
running the ACL from my first example and receives a packet that
matches (eg, tcp port 22 with
destination 192.168.1.1), it drops the packet no matter what.
If, instead, the router is a host running iptables, the packet could be
assigned either to the
INPUT chain (if 192.168.1.1 is an IP assigned to the router) or to the
FORWARD chain (if
the router's IP address is different). So, if I wanted to write some
iptables rule(s) for a "generic"
router host whose IP address is not known, and I wanted to guarantee
the same behavior, would
it be correct (semantically equivalent to the ACL) and enough to write
the two rules I wrote, one for
the INPUT chain and the other for the FORWARD chain?
For the output case, the problem is related, since packets leaving the
router could be originating
from the router itself or be forwarded by the router. So, the critical
info here is the source address
of the packet (and yes, as another poster already noted, I should have
written my second group
of rules differently instead of copying/pasting). Thus, the question:
whereas a cisco router running
an ACL like
ip access-list extended blah
deny tcp 192.168.1.1 0.0.0.0 any eq 22
ip access-group blah out
drops a leaving matching packet no matter where it originated, does an
iptables firewall (whose IP
address is not known) need two rules, one for the FORWARD chain and one
for the OUPUT chain?
I hope it's clearer now.
Thanks for any help.
- Prev by Date: Re: Cisco ACL vs. iptables semantics
- Next by Date: Re: Cisco ACL vs. iptables semantics
- Previous by thread: Re: Cisco ACL vs. iptables semantics
- Next by thread: Re: Cisco ACL vs. iptables semantics