Sometimes confused in determining direction of ACL (in/out)

jojopramosjojopramos Member Posts: 415
Guys, I am doing some practice lab and sometimes I am confused on whether to configure the ip access-group as in or out. As per Jeremy, I know that Standard access list to be apply closest to the destination and Extended access list closest to the source. Also, in his instruction, to determine the direction the access list should be applied is to put myself as a router. If access list filtering coming into me = inbound, or if going away from me = outbound. But sometimes, if I am doing some practice or answering questions from Jeremy's book, I can't perfect it. Sometimes when I know that it should be in then the answer is out on Jeremy's exercises in Examprep CCNA book. Is there another technique or a more simple explanation to better understand this.

Comments

  • gorebrushgorebrush Member Posts: 2,743 ■■■■■■■□□□
    You are right with your appreciation of Standard and Extended lists.

    However, I can't think of another way to simplify the direction.

    "Be the router" is a common phrase that Jeremy uses, and I think that is excellent.

    Your arms become the interfaces - hold them out if you have to!

    But yes, if your right arm is Serial0/0, then incoming or outgoing should be easy from that point?

    Can you give an example of a question you have been stuck with?
  • jojopramosjojopramos Member Posts: 415
    Actually, the questions regarding blocking a subnet, restricting by protocol, restricting by network are some of Jeremy's example. Actually, after I do some solutions in Packet Tracer and GNS, all the configuration that I made is right but only the direction in or out is wrong (ip access-group 110 <in/out>). Then I will just figure that out after I draw it in a pice of paper and verifying for at least 3 to 6 mins. Sometimes it confused me for examples like deny the network for HTTP, only allow the network/host for HTTP/HTTPS to name a few. Since the exam allowed you for a minute for every question maybe, then I want to ace this part.
  • bermovickbermovick Member Posts: 1,135 ■■■■□□□□□□
    While Jeremy's way is accurate, I found it a tad silly. I find it easier to just picture the direction the data flows; it'll be flowing IN one interface and OUT another.

    In the picture below (assuming I correctly insert it), to keep C2 from accessing the FTP server on C3, you'd apply an extended list INbound on R3's f0/0 or a standard list OUTbound on R4's f0/0.

    ACL.jpg
    Latest Completed: CISSP

    Current goal: Dunno
  • jojopramosjojopramos Member Posts: 415
    Wait, in this example, In my opinion, bermovick placement of standard and extended list is wrong. Correct me on this guys but FTP server is the source here since FTP server is the one whose giving out the services. Another thing is that standard list should be configure on R3 router through f0/0 because standard list just permits traffic through source address. So as per Jeremy, if you will configure this in R4, it might deny not only the subnet on R3 but others as well. It is also better to configure extended list closest to the source which is the FTP server. It will precisely point the direction of the R3 not to access the FTP server. But another case on this is that since we just need to block the FTP server on R3's fa0/0, then we just need to apply the extended access list to pricisely control FTP port. Am I correct on this?

    R4(config)#access-list 120 deny tcp (R3f0/0 subnet) host (ftp server IP) eq 20
    R4(config)#access-list 120 deny tcp (R3f0/0 subnet) host (ftp server IP) eq 21
    R4(config-if)#ip access-group 120 in
    ( this is where I am so confused, on the in/out direction) but i think this is inside to be configure on R4's f0/0
  • gorebrushgorebrush Member Posts: 2,743 ■■■■■■■□□□
    No, the FTP CLIENT would be the source, since it is the SOURCE of the data transmission?

    Think of it from the point of view of the network, not of the individual server/service.
  • jojopramosjojopramos Member Posts: 415
    Now here is where I am more confused... thanks on that gorebush. Extended list on R3's router maybe fine because it will precisely point to the FTP server but the thing that makes me more confused is the standard list. Is it still necessary to configure the standard when you just want to filter the FTP server (as per the scenario, it is not the FTP service but the whole server itself). If there are any devices/servers/client on R4's subnet, it will be block also. Is that correct, gorebush?
  • gorebrushgorebrush Member Posts: 2,743 ■■■■■■■□□□
    Apply this to bermovick's diagram.

    The standard list needs to be placed as close to the source as is possible because the scope of a standard list is far far greater than that of an extended list.

    Router4(config)#access-list 1 deny 10.0.0.0 0.0.0.255

    In the above line, we have a standard access list - OK it is a very simple one, but an access list none the less.

    Router4(config-if)#ip access-group 1 in

    I've just applied this access-list to interface s0/1. With this then, I have single handedly denied the entire range of 10.0.0.0/24 from coming into Router4's s0/1 interface.

    So, examining the diagram again, Router4 now denies any traffic from the 10.0.0.0/24 network from coming into the s0/1 interface. (See, I've applied the standard access list away from the recommended position)

    Now, let us pretend that the C2 computer is on the 10.0.0.0 subnet.

    If our objective was to deny access to the FTP Server of computers in the 10.0.0.0 subnet - great we have achieved this because any packet from the 10.0.0.0 subnet will be dropped before it gets to the subnet that the FTP Server resides on.

    But wait, read the above statement again - we've not just denied FTP packets, we've denied *everything*

    What if we have a special user in the C2 network that should be allowed to hit another computer on the same subnet as the FTP Server (lets pretend there is a SQL database which this special user connects to)

    Our access list denies everything- pings, ftp, telnet, http, anything.

    Our second host cannot access the SQL Server, even though it is allowed.

    What if then we move the special user to 10.0.0.129 and change the scope of the access list?

    Router4(config)#access-list 1 deny 10.0.0.0 0.0.0.127

    Note, I've modified the access list (look at the wildcard mask). This access list now denies everything in the range of 10.0.0.1-10.0.0.127, and everything from 10.0.0.129-10.0.0.254 would be allowed.

    So, lets look at the TWO hosts on the C2 subnet: -

    Host1 - 10.0.0.1
    Host2 - 10.0.0.129

    Host 1 is not allowed to see the FTP Server
    Host 2 is allowed to see the FTP Server

    And our access-list would work for this, as Host1 would be denied, and Host2 would be allowed to see the FTP Server.

    However, as the standard access-list denies all types of traffic, our Host1 cannot connect to the SQL Server.

    So, the standard access-list is great at denying bulk networks, but cannot differentiate between types of traffic.

    However, lets now break open a can of extended access list here: -

    The configuration of an extended access list is far more involved than a standard.

    Below, I have configured an extended access list to deny ftp packets to any host from the C2 subnet: -

    Router(config)#ip access-list extended 101
    Router(config-ext-nacl)#deny tcp 10.0.0.0 0.0.0.127 any eq ftp

    You see on the second line, I have to define the protocol we are using, source address and source wildcard, any could be a single host (I've just put any to show that we can deny FTP packets ENTIRELY from C2) the eq ftp part means that any packets that are FTP will be dropped.

    I can place this extended list anywhere I want to on the network, and be safe in the knowledge that as long as the directions and placement (i.e. on the correct routers), then my SQL traffic from that OTHER host on the C2 subnet will work just fine.

    I hope this is has cleared it up, but the key thing to remember is SCOPE

    The SCOPE of what you are permitting/denying is vastly different between standard and extended access lists.
  • bermovickbermovick Member Posts: 1,135 ■■■■□□□□□□
    In the CBTNuggets videos for CCNA:S, Jeremy points out you really don't see standard lists applied to interfaces to packet filter very often for that exact reason; they simply are too all-encompassing. You'll see them more easily applied to vty ports and the like (access-class), and I think he said things like QoS use them too, but I could be wrong there.
    Latest Completed: CISSP

    Current goal: Dunno
  • gorebrushgorebrush Member Posts: 2,743 ■■■■■■■□□□
    Yes, as bermovick points out, much more suited to vty etc, but I hope my post helps for clarity.
  • jojopramosjojopramos Member Posts: 415
    Thanks for the detailed explaination on this scenario, gorebush. The thing that I need to know first is the direction (from source to destination). I am confused before because I am always thinking about the services of the server as always the source (Microsoft's thinking habit). From now on, if it is access list, I will always bear in mind to identify the source and the destination based on the question ask or scenario. Thanks guys.
  • bermovickbermovick Member Posts: 1,135 ■■■■□□□□□□
    That kindof makes sense, but just remember before the server can send data to the PC, the PC has to send a request for the data. While you could stop data in the direction of server to PC, that allows the PC's data (request) to traverse the network to the server, and the server using cpu to process the request and begin sending data back before it hits the ACL and dropped. Stopping the server data en-route to the PC is just less efficient.
    Latest Completed: CISSP

    Current goal: Dunno
  • jojopramosjojopramos Member Posts: 415
    I agree on this bermovick. It is much clearer to me now.
Sign In or Register to comment.