about ACL..

sonagccnasonagccna Posts: 44Member ■■□□□□□□□□
I tried the following with standard ACL.

if i try to block access(from) remote router('s ethernet) to a router say Router1's ethernet(ACL being applied at Router1's Ethernet0 for eg.), will the access from Router1 to Remote Router's ethernet also get blocked?

the block automatically becomes two-way?

the ACL included permit any too.

or is it not possible with standard ACL as far as this scenario is concerned?

My trainer did not help about ACLs much

so trying myself from the scratch

Anyone include good weblinks to ACL practices

Thanks

Comments

  • forbeslforbesl Posts: 454Member
    sonagccna wrote:
    I tried the following with standard ACL.

    if i try to block access(from) remote router('s ethernet) to a router say Router1's ethernet(ACL being applied at Router1's Ethernet0 for eg.), will the access from Router1 to Remote Router's ethernet also get blocked?

    the block automatically becomes two-way?

    the ACL included permit any too.

    or is it not possible with standard ACL as far as this scenario is concerned?

    My trainer did not help about ACLs much

    so trying myself from the scratch

    Anyone include good weblinks to ACL practices

    Thanks
    If I understand your question correctly; yes, you will not be able to gain access to the remote router. This is not because the ACL is "two-way", but because you are blocking replies from the remote router to your router1 ethernet interface. An extended access list needs to be used if you want to allow replies from the remote router, but block connection attempts.

    For instance (from router1), if you want to be able to ping the remote router, deny all other traffic and replies from the remote router, but permit any traffic from all other sources, your extended access list would look something like this. Let's say the remote router's IP is 192.168.1.17 and router1's directly connected (I assume this is a lab setup) IP is 192.168.1.18:

    access-list 101 permit icmp host 192.168.1.17 host 192.168.1.18 echo-reply
    access-list 101 deny ip host 192.168.1.17 any
    access-list 101 permit ip any any
  • sonagccnasonagccna Posts: 44Member ■■□□□□□□□□
    i am trying with simple access-list (standard access-list),
    3 routers involved in the topology with the following configuration,

    Router1
    E0 – 24.17.2.1 255.255.255.240
    S0-24.17.2.17 255.255.255.240
    Rip Enabled for both interfaces

    Router2
    E0-24.17.2.2 255.255.255.240

    Rip Enabled for E0

    Router 4

    S0-24.17.2.18 255.255.255.240
    Rip Enabled for S0

    Here I am trying to block access to Router2's Ethernet from Router4's ethernet

    access-list 1 deny 24.17.2.16 0.0.0.15
    access-list 1 permit any

    I applied at Router2's Ethernet inbound,

    ip access-group 1 in

    ping 24.17.2.2 from Router4 now blocked,

    but i wanted to check from Router2's E0 and pinged to Router4's Ethernet

    ping 24.17.2.18, but this doesn't succeed,getting U

    (I also tried applying it on Router's E0, the same only happens, i couldn't ping from R2 to R4,though I applied ACL to deny Router4's Ethernet)

    actually the ACL blocks based on source address as it is standard, but this ping also being blocked, why this is so?

    Because here the packet contains 24.17.2.18 as destination only, but why it is being blocked, please someone explain.

    Thanks.
  • rossonieri#1rossonieri#1 Posts: 800Member
    assume without any ACLs, can you ping router to router like r1 to r2, r2 to r4 vice versa?
    a standard ACL will function without any check for incoming connection - just specific ip for a basic rule -> permit/deny;
    but if you use an extended ACL that incoming connection will be check for the rule you have specified -> permit/deny, tcp/udp/icmp, port etc.
    the More I know, that is more and More I dont know.
  • tunerXtunerX Posts: 447Member ■■■□□□□□□□
    R2--R1--R4

    access-list 1 deny 24.17.2.16 0.0.0.15
    access-list 1 permit any

    R2--ACL<--R1--R4

    when you ping from R4 to R2, inbound traffic is blocked by the ACL on R2. R2 is kind enough to send an ICMP desitination unreachable message so you get U.U.U on R4. (ICMP Type 3 Code 10 message)

    R4 sends a packet with DA 24.17.2.2 and SA 24.17.2.18
    This packet is denied because the SA matches the ACL.

    R2 replies with ICMP 3/10 DA 24.17.2.18 and SA 24.17.2.2
    This packet is not processed by the ACL and it makes it to R4.

    When you ping from R2 to R4 the packets leave just fine. You can debug packet on R4 to see that you are getting the ping and replying. The problem here is that when the reply comes back to R2 it will match the deny statement in the access list and drop the packet.

    R2 sends a packet with DA 24.17.2.18 and SA 24.17.2.2
    This packet is allowed and makes it to R4
    R4 responds to the ping packet with DA 24.17.2.2 and SA 24.17.2.18
    This packet is denied and R2 sends another ICMP 3/10 packet.

    When you create a standard access list it is based on "SOURCE" address. any packet leaving from R4 will have a source address that falls into the range 24.17.2.16 0.0.0.15

    If you add another interface and do an extended ping you make the SA of R4 a different address. R2 will gladly respond to those.
  • sonagccnasonagccna Posts: 44Member ■■□□□□□□□□
    so its not possible to accomplish this goal of 'one way' of pinging with standard access-lists icon_thumright.gif thanks folks
  • DrakonblaydeDrakonblayde Posts: 542Member
    yeah a standard access list kills the entire protocol, not just ping activity. Have to use an extended access list if you want any finesse
    = Marcus Drakonblayde
    ================
    CCNP-O-Meter:
    =[0%]==[25%]==[50%]==[75%]==[100%]
    ==[X]===[X]====[ ]=====[ ]====[ ]==
    =CCNA==BSCI==BCMSN==BCRAN==CIT=
Sign In or Register to comment.