Access Lists

NETWizz

Well-Known Member
Reaction score
1,885
You can read stuff all over the Internet about access lists. Some tutorials are great and others are bad.

Here is my attempt.

Some axioms most tutorials do not touch on:
First and foremost, access-lists do NOT merely permit or deny traffic, but they permit or deny membership for hosts, subnets, etc. A permit can be though of as true and a deny as false. Basically, the action is performed on the permitted (included) item.

==> For example, you could make an access list that permits a single host to anywhere then match that access-list in a class-map, apply that class-map queue via a policy-map that applies a QoS police action to drop ALL packets. Apply that QoS policy and suddenly any permitted item in the access list has all it's packets dropped.

Access lists are processed top to bottom until a match is made for both the source AND destination (extended ACLs). Once a match is made, the lists stops processing and applies the permit or the deny. There is also a default deny any any at the end.

Now let's look at this... The format

permit or deny is obvious then we have source followed by destination

Hence, this is very obvious what it does:

permit ip any any

That said, what can you put besides any?

A:
any for everything
10.0.0.0 0.0.0.255 (an example of a subnet with a wildcard mask for 10.0.0.0/8)
host 10.1.2.3 (for a particular host).

Basically, if you use the host keyword it means one (1) host. If you define a subnet it is the network ID then the wildcard mask, which unlike a subnet mask can also match bits in the middle if you choose... and any matches everything


Hence I am underlining parts that go together...

Permit any source traffic to specific host 10.1.2.3

permit ip any host 10.1.2.3


Permit any traffic from 172.16.0.0/12 to anywhere:

deny ip 172.16.0.0 0.15.255.255 any


Now we have protocols:

ip
tcp
udp
icmp

etc.

You need to know what protocol you are using if you want to match on the transport layer

For example (any TCP traffic to a specific host listening on TCP destination port 443). This is a destination port!

permit tcp any host 192.168.1.1 eq 443



Let's say the socket may look like this:

127.16.1.2:1234 ==> 192.168.1.1:443

The port 1234 above is an ephemeral port.... pretty much randomly generated by the operating system... It is to keep your request separated from that of others from the same IP (i.e. especially important behind NAT)

Response would be source port 443 to destination port 1234

192.168.1.1:443 ==>127.16.1.2:1234

If you want to, you could make a rule matching a source port...

permit tcp any eq 1234 any 5678

This ONLY allows TCP traffic with source port 1234 to reach any IP with destination port 5678!

Now if an interview question is "how many ports are there?"
A: You are looking for 65,535, but there are that many source and that many destination ports for TCP... and there are another 65,535 source and destination ports for UDP!

This doesn't work because IP does NOT have ports!

permit ip any 10.1.2.3 eq 443


Now you have to choose an interface to apply the ACL if that is all you are doing... and a direction.

Takeaway: Every interface has an in and an out direction, BUT just because data flows into an interface does NOT mean it flows out the same interface!


Next... ACLs typically get applied to layer-3 interfaces, which are IPed interfaces with an IP and mask on them...


If I have a router with Interface 1 (192.168.7.1/24) and it has Interface 2 (10.0.0.1/8)....

It's routing table has two directly-connected subnets and the .1 of those is the default-gateway to get off each respective network.


Let's say I have an ACL:

permit ip any host 10.1.2.3
<implicit deny>

If host 192.168.7.55 sends a packet to 10.1.2.3, it goes to it's default gateway 192.168.7.1 because the host knows it doesn't belong to its own subnet.

The router receives that packet on interface 1. The above ACL would be processed inbound on interface 1 and allow the traffic.

There is NO outbound processing on Interface 1 because the packet doesn't come out Interface 1

Now, AFTER routing is completed, the router will find it belongs to the subnet directly attached on Interface 2, and it will forward the packet via completely new layer-2 frame out Interface 2. The new frame will be sourced from the default gateway's MAC address of Interface 1, but the IP addresses will NOT change on the packet.

If you wanted to, you could apply the ACL above in the outbound direction on Interface 2.

The packet would flow

Into interface 1 ==> router ==> out interface 2

That packet didn't flow out Interface 1 nor into interface 2. Again:

Takeaway: Every interface has an in and an out direction, BUT just because data flows into an interface does NOT mean it flows out the same interface!




This tutorial would be better with pictures...
 
Back
Top