about ACL..

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

Find more posts tagged with

Free for TechExams community: Cybersecurity salary guide

Compare cert salaries and plan your next career move

Button

Comments

forbesl

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

sonagccna

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#1

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.

tunerX

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.

sonagccna

so its not possible to accomplish this goal of 'one way' of pinging with standard access-lists

thanks folks

Drakonblayde

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