ccna access list

jcarrillo26

Hello All,

I was looking for some help, even after getting my ccna i am still weak when it comes to access lists. I am revisiting my ccna material because i got an IT job as well as i want to go to the next level when it comes to certifications. I want to be CCNP certified by the end of 2015. i am going to be pick up the books and go from there. I just can seem to get the access list down for some apparent reason. I understand they are for packet filtering, nat, and list of other needs. I understand the concept for needing them. I understand standards are 1-99, extended are 100-199, there are extensions of standard and extended. You also have named access list where you can add or remove in between access lists. I understand that you place the standard access list closest to the destination and extended access list closest to the source. I understand that standards are based upon source address and extended can be used to describe what protocol, source, destination, etc. I know the rule for access list are one per protocol, per interface, etc. When i apply the access list, it just seems i cannot get it to work with me.

Please any detail explanation or how someone else learned how to apply them effectively would be greatly appreciated.

bharvey92

I learnt that when applying ACL's inbound or outbound imagine that you are the router. Inbound you are taking action on the traffic coming inbound and outbound you are taking action on traffic leaving the router.

jcarrillo26

hey thanks for your reply! I know I have to apply them to the interfaces or acls dont really have a purpose. so when it is coming from a node on the network its a permit/deny coming in and something going out to the cloud or a service on the net it is going out? I guess my logic is a little messed up. Should I just get my home lab and allow internet to all the nodes and then apply the restrictions of the access lists to play around with?

Switch1

jcarrillo26 wrote: »

hey thanks for your reply! I know I have to apply them to the interfaces or acls dont really have a purpose. so when it is coming from a node on the network its a permit/deny coming in and something going out to the cloud or a service on the net it is going out? I guess my logic is a little messed up. Should I just get my home lab and allow internet to all the nodes and then apply the restrictions of the access lists to play around with?

Think of IN meaning, coming into the interface.
Think of OUT meaning, going out the interface.

jcarrillo26

could you give me a couple of scenarios when I would use in and out say on my serial and fa0/0 on my lan?

JeanM

Example-

IN - you want to block telnet access for all, as traffic comes into router
OUT - you want to block access to ftp only if it's for specific scenario (and not block all ftp as it comes in).

Switch1

jcarrillo26 wrote: »

could you give me a couple of scenarios when I would use in and out say on my serial and fa0/0 on my lan?

ACL logic can be applied to packets at 2 points:
1. The point at which the IP packet enters an interface. (Before the router makes its forwarding decision)
2. The point at which the IP packet exits an interface. (After the router makes its forwarding decision)

In other words, your ACLs can be binded to an interface, AND for a direction of packet flow (in or out).

There are many examples of ACLs on the internet but here's a great one I found here on Techexams which helps ground the concept.

thehourman wrote: »

If you want to filter packets that is coming in, you want to use the in; and if you want to filter packets that is coming out then you use the out.

For example, let's say you have a topology like this:
PC0

---

[Router]

---

Internet

---

|

---

|

---

PC1

If you want to filter packets coming from the internet, you're going to use in on the router's interface facing the internet because the packets from the internet is coming into the router that is why you use in.
If you don't want PC0 to access the internet, but want it to access PC1, which is in a different subnet, you can use the out on the router's interface facing the internet. So that every time the PC0 tries to go out to the internet it will be filtered, but if PC0 tries to access PC1, it will be fine.

jcarrillo26

Thank you Switch1 and JeanM for your help understanding ACLs so for best practices is is possibly best to have the scenario that you mentioned to block coming into the router to save resources. So with the given scenario i can use a extended or name extended ACL such as:

say pc 0 has an ip address of 192.168.1.10 and pc 1 has a ip address of 192.168.1.11 with a /24 mask.
any the internet is 10.0.0.1(which i know is not a route-able address just for the given scenario)

given that there is a implict deny all i do not have to do two lines for the acl because all i need to do is make an access list permitting pc1 because the implicit deny all would deny pc0.

so i can do:

access-list 100 permit tcp host 192.168.1.11 host 10.0.0.1 eq www or 80

or

ip access-list extended (name)

permit tcp host 192.168.1.11 host 10.0.0.1 eq www or 80

what are the rules for the given protocol with tcp, udp, and ip ? i know ports such as 80, 23, 22, etc.

udp uses 53, 69, 67 and 68, etc.

does ip mean all protocols?

Again thank you for your help with reinforcing what i already know so i can apply these acls effectively and efficiently

jcarrillo26

I just did a packet tracer lab where i had to permit/deny certain host to telnet and reach the web and they worked out for me. I applied these access lists and they worked it took me like 10 minutes but i got it!

access-list 100 permit tcp host 172.22.3.50 host 172.22.3.90 eq telnet (this permits the one user to telnet to a switch)
access-list 100 deny tcp 172.22.3.32 0.0.0.31 host 172.22.3.90 eq telnet (i had to place this one in there because if i did not because i have the ip any any at the bottom the rest of the subnet was able to telnet into the switch)
access-list 100 deny tcp host 172.22.3.53 any eq www (this denied the host of this address to access anything that was pertaining to port 80)
access-list 100 permit ip any any (wihtout this statement everything would be implicit denied and therefore even though only the host above was blocked, the rest of the subnet was blocked unless i applied this.)

Please let me know if this sounds correct to you guys/gals thank you so much for your help.

jcarrillo26

I think I have it correctly on my access lists.

Switch1

jcarrillo26 wrote: »

I just did a packet tracer lab where i had to permit/deny certain host to telnet and reach the web and they worked out for me. I applied these access lists and they worked it took me like 10 minutes but i got it!

access-list 100 permit tcp host 172.22.3.50 host 172.22.3.90 eq telnet (this permits the one user to telnet to a switch)
access-list 100 deny tcp 172.22.3.32 0.0.0.31 host 172.22.3.90 eq telnet (i had to place this one in there because if i did not because i have the ip any any at the bottom the rest of the subnet was able to telnet into the switch)
access-list 100 deny tcp host 172.22.3.53 any eq www (this denied the host of this address to access anything that was pertaining to port 80)
access-list 100 permit ip any any (wihtout this statement everything would be implicit denied and therefore even though only the host above was blocked, the rest of the subnet was blocked unless i applied this.)

Please let me know if this sounds correct to you guys/gals thank you so much for your help.

Looks good, just remember if a permit any statement is at the top of any ACL, it doesn't matter how many deny statements follow it. They'll never be read.

Might be stating the obvious, but it's good information to share nonetheless .

jcarrillo26

Okay cool thank you for reviewing the post, so the permit any goes at the bottom. So does ip control all traffic from an access list point of view?