Access Lists

[nitinnigam]

Hi,

I have two routers R1 and R2 with FastEthernet Interface IP address (F0/0)10.1.0.1 and

(F0/0)10.1.0.2 respectively. I am using HSRP and R1 is active and R2 is in standby state.

Whats happening is when I am applying ACLs in R1 on F0/0 I cannot telnet to R2 but if I remove these ACLs I can telent to R2 from R1.

Can someone please help me with this. Since they are on same segment so my understanding is that I can telnet to R2 from R1 even after applying ACLs.

Thanks

[smif101]

give us a snapshot of your config or at least your access lists.

Jason Smith

www.smif101.com

[nitinnigam]

Hi Jason,

Please find below the config of R1

interface FastEthernet0/0

ip address 10.1.0.1 255.255.255.0

ip access-group 101 in

ip access-group 102 out

speed auto

standby 1 ip 10.1.0.254

standby 1 preempt

!

access-list 101 permit tcp host 10.1.0.1 host 192.168.1.205 range 41001 42010

access-list 101 permit tcp host 10.1.0.2 host 192.168.1.205 range 41001 42010

access-list 101 permit tcp host 10.1.0.3 host 192.168.1.205 range 41001 42010

access-list 101 permit tcp host 10.1.0.4 host 192.168.1.205 range 41001 42010

access-list 101 permit tcp host 10.1.0.5 host 192.168.1.205 range 41001 42010

access-list 101 permit tcp host 10.1.0.6 host 192.168.1.205 range 41001 42010

access-list 101 permit tcp host 10.1.0.7 host 192.168.1.205 range 41001 42010

access-list 101 permit tcp host 10.1.0.8 host 192.168.1.205 range 41001 42010

access-list 101 permit tcp host 10.1.0.9 host 192.168.1.205 range 41001 42010

access-list 101 permit tcp 10.1.0.0 0.0.0.255 host 192.168.1.190

access-list 101 permit tcp 10.1.0.0 0.0.0.255 host 192.168.8.22

access-list 101 permit udp 10.1.0.0 0.0.0.255 eq snmp host 192.168.8.22

access-list 101 permit udp 10.1.0.0 0.0.0.255 host 192.168.8.22 eq snmp

access-list 101 permit udp 10.1.0.0 0.0.0.255 host 192.168.8.22 eq snmptrap

access-list 102 permit tcp host 192.168.1.205 range 41001 42010 host 10.1.0.1

access-list 102 permit tcp host 192.168.1.205 range 41001 42010 host 10.1.0.2

access-list 102 permit tcp host 192.168.1.205 range 41001 42010 host 10.1.0.3

access-list 102 permit tcp host 192.168.1.205 range 41001 42010 host 10.1.0.4

access-list 102 permit tcp host 192.168.1.205 range 41001 42010 host 10.1.0.5

access-list 102 permit tcp host 192.168.1.205 range 41001 42010 host 10.1.0.6

access-list 102 permit tcp host 192.168.1.205 range 41001 42010 host 10.1.0.7

access-list 102 permit tcp host 192.168.1.205 range 41001 42010 host 10.1.0.8

access-list 102 permit tcp host 192.168.1.205 range 41001 42010 host 10.1.0.9

access-list 102 permit tcp host 192.168.1.190 10.1.0.0 0.0.0.255

access-list 102 permit udp host 192.168.8.22 eq snmptrap 10.1.0.0 0.0.0.255

access-list 102 permit udp host 192.168.8.22 eq snmp 10.1.0.0 0.0.0.255

access-list 102 permit udp host 192.168.8.22 10.1.0.0 0.0.0.255 eq snmp

[olorunloba · Accepted solution]

The inbound access-list would affect the telnet traffic, outbound would not. Permit telnet traffic in the inbound access list.

[tbaranski · Accepted solution]

The inbound access list will block the return traffic, as mentioned. So you need a line like:

access-list 101 permit tcp host 10.1.0.2 eq 23 host 10.1.0.1

[Tod Larson]

This is a really old post, but why doesn't the outbound list block telnet?

[Richard Burts]

Tod

You ask a good question here about why an outbound access list will not affect outbound traffic that is generated by the router itself. I can tell you that this has been a consistent behavior for a very long time and over many releases of IOS. I can not give an official explanation but here is what makes sense to me. We apply an access list to filter traffic that we do not trust. But if it was generated by the router itself then inherently we trust it and do not need to filter it.

HTH

Rick

Sent from Cisco Technical Support iPhone App

[Tod Larson]

Oh, I get it.  Telnet is permitted because it orginated from the router...not because the access list permitted it.   I thought I was misreading the access list.

Thank you.