Access List

[sivam siva]

Hello 

 couldnt take telnet please help anyone,below the configurations

I can take telnet of L3-1 from L3-2 ,but i couldnt take telnet of L3-2 from L3-1 

I have applied inbound Access list in L3-1 interface  vlan 3 but i permitted the telnet traffic ,i dont know why its blocking ?

I know that for telnet we have to apply access list under line Vty, if I apply the outbound access list under int vlan 3 it's working, how?

 switch:L3-2 (3.3.3.2)

L3-2#tel 3.3.3.1
Trying 3.3.3.1 ... Open

User Access Verification

Password:
L3-2#sh run int vl 3
Building configuration...

Current configuration : 53 bytes
!
interface Vlan3
ip address 3.3.3.2 255.0.0.0
end
L3-2#sh access-lists
Extended IP access list 101
10 permit tcp any any eq telnet (1698 matches)
20 deny ip any any (435 matches)
L3-2#sh ip rou
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

C 3.0.0.0/8 is directly connected, Vlan3
L3-2#sh vl

VLAN Name Status Ports
---- -------------------------------- --------- -------------------------------
1 default active Gi0/1, Gi0/2, Gi0/3, Gi0/4
Gi0/5, Gi0/6, Gi0/7, Gi0/8
Gi0/9, Gi0/10, Gi0/11, Gi0/12
Gi0/13, Gi0/14, Gi0/15, Gi0/16
Gi0/17, Gi0/18, Gi0/19, Gi0/20
Gi0/21, Gi0/22, Gi0/25, Gi0/26
Gi0/27, Gi0/28
2 VLAN0002 active
3 VLAN0003 active Gi0/23, Gi0/24

switch:L3-1 (3.3.3.1)

L3-1#
[Resuming connection 4 to 3.3.3.2 ... ]

% Connection timed out; remote host not responding

L3-1#sh run int vl 3
Building configuration...

Current configuration : 77 bytes
!
interface Vlan3
ip address 3.3.3.1 255.0.0.0
ip access-group 101 in
end

L3-1#sh access
L3-1#sh access-lists
Extended IP access list 101
10 permit tcp any any eq telnet (371 matches)

L3-1#sh ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

C 3.0.0.0/8 is directly connected, Vlan3
L3-1#sh vl

VLAN Name Status Ports
---- -------------------------------- --------- -------------------------------
1 default active Gi0/2, Gi0/3, Gi0/4, Gi0/5, Gi0/6, Gi0/7, Gi0/8, Gi0/9, Gi0/10, Gi0/11, Gi0/12, Gi0/13, Gi0/14, Gi0/15, Gi0/16, Gi0/17
Gi0/18, Gi0/19, Gi0/20, Gi0/21, Gi0/22, Gi0/23, Gi0/24, Gi0/25, Gi0/26, Gi0/27, Gi0/28, Gi0/29, Gi0/30, Gi0/31, Gi0/32
Gi0/33, Gi0/34, Gi0/35, Gi0/36, Gi0/37, Gi0/38, Gi0/39, Gi0/40, Gi0/41, Gi0/42, Gi0/43, Gi0/44, Gi0/45, Gi0/49, Gi0/50
Gi0/51, Gi0/52
2 VLAN0002 active Gi0/46
3 VLAN0003 active Gi0/48

[luis_cordova]

Hi @sivam siva,

Please, show the configuration of the lines VTY on both devices.

Regards

[Richard Burts · Accepted solution]

The question from Luis is very appropriate and points toward an important concept in controlling access via telnet (and/or SSH). The best way to control access via telnet is to apply ip access-class on the vty ports. The partial config supplied by the original poster reflects a common misunderstanding. It is attempting to control telnet access by using ip access-group applied to the interface. While if is possible to control telnet access using access-group on the interface, it is easier and better to control it using access-class on the vty.

One of the things that makes it easier when using access-class is that this only applies to remote access traffic. If you use access-group you must have logic to control remote access traffic and then you must also have logic to control all other traffic for the interface. Another thing that makes it easier when using access-class is that since it is applied only to remote access traffic the access-class will usually use a standard access list and specify only the source subnet (where the telnet request is coming from). When using access-group on the interface you would need to use an extended access list and would need to specify correctly which is source address, source port, destination address, and destination port (remember that whether telnet is the source port or the destination port will depend on whether the acl is applied inbound or is applied outbound).

HTH

Rick

[Simon Darlington · Accepted solution]

Hi Sivam

Thanks for this question. This main question is about the direction of access-lists on SVIs. 

I had some fun labbing this up to understand the behavior you described. I see that you have the access-list restricting connectivity to telnet configured on both devices. For simplicity I have configured the ACL only on L3-2. SVI vlan 3 exists on both switches as 3.3.3.1 and 3.3.3.2 for L3-1 and L3-2 respectively.

!check connectivity from L3-1 to L3-2. All good. We're networking!
L3-1#ping 3.3.3.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 3.3.3.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 3/6/8 ms
L3-1#

!configure access-list matching traffic with any source ip to any destination ip with tcp port of telnet
L3-2(config)#ip access-list extended 101
L3-2(config-ext-nacl)#permit tcp any any eq telnet

L3-2(config-ext-nacl)#deny ip any any

L3-2(config-ext-nacl)#int vlan 3
L3-2(config-if)#ip access-group 101 in

L3-2#sh run int vlan 3
Building configuration...

Current configuration : 81 bytes
!
interface Vlan3
ip address 3.3.3.2 255.255.255.0
ip access-group 101 in
end

!show any hits to inbound ACL on L3-2. Notice there are currently no matches
L3-2#show access-list 101
Extended IP access list 101
10 permit tcp any any eq telnet
20 deny ip any any
L3-2#

!setup packet debug for ACL 101 on L3-2
L3-2#debug ip packet 101
IP packet debugging is on for access list 101

!now telnet from L3-1 to 3.3.3.2 address which exists on L3-2
L3-1#telnet 3.3.3.2
Trying 3.3.3.2 ... Open

**************************************************************************
* IOSv is strictly limited to use for evaluation, demonstration and IOS *
* education. IOSv is provided as-is and is not supported by Cisco's *
* Technical Advisory Center. Any use or disclosure, in whole or in part, *
* of the IOSv Software or Documentation to any third party for any *
* purposes is expressly prohibited except as otherwise authorized by *
* Cisco in writing. *
**************************************************************************

User Access Verification

Password:

!back to L3-2. Observe output of debug ip packet 101 on L3-2, which was generated whilst telneting from L3-1, showing we are hitting access-list 101

L3-2#
*Dec 17 18:11:30.662: IP: s=3.3.3.1 (Vlan3), d=3.3.3.2, len 44, input feature, Access List(47), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
*Dec 17 18:11:30.663: IP: s=3.3.3.1 (Vlan3), d=3.3.3.2, len 44, input feature, MCI Check(109), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
*Dec 17 18:11:30.664: IP: s=3.3.3.1 (Vlan3), d=3.3.3.2, len 44, rcvd 2
*Dec 17 18:11:30.664: IP: s=3.3.3.1 (Vlan3), d=3.3.3.2, len 44, stop process pak for forus packet
*Dec 17 18:11:30.675: IP: s=3.3.3.1 (Vlan3), d=3.3.3.2, len 40, input feature, Access List(47), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
*Dec 17 18:11:30.676: IP: s=3.3.3.1 (Vlan3), d=3.3.3.2, len 40, input feature, MCI Check(109), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
*Dec 17 18:11:30.681: IP: s=3.3.3.1 (Vlan3), d=3.3.3.2, len 40, rcvd 2
*Dec 17 18:11:30.682: IP: s=3.3.3.1 (Vlan3), d=3.3.3.2, len 40, stop process pak for forus packet
*Dec 17 18:11:30.684: IP: s=3.3.3.1 (Vlan3), d=3.3.3.2, len 49, input feature, Access List(47), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
*Dec 17 18:11:30.685: IP: s=3.3.3.1 (Vlan3), d=3.3.3.2, len 49, input feature, MCI Check(109), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
*Dec 17 18:11:30.687: IP: s=3.3.3.1 (Vlan3), d=3.3.3.2, len 49, rcvd 2
*Dec 17 18:11:30.687: IP: s=3.3.3.1 (Vlan3), d=3.3.3.2, len 49, stop process pak for forus packet
*Dec 17 18:11:30.692: IP: s=3.3.3.1 (Vlan3), d=3.3.3.2, len 40, input feature, Access List(47), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
*Dec 17 18:11:30.693: IP: s=3.3.3.1 (Vlan3), d=3.3.3.2, len 40, input feature, MCI Check(109), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
*Dec 17 18:11:30.694: IP: s=3.3.3.1 (Vlan3), d=3.3.3.2, len 40, rcvd 2
*Dec 17 18:11:30.695: IP: s=3.3.3.1 (Vlan3), d=3.3.3.2, len 40, stop process pak for forus packet
*Dec 17 18:11:30.720: IP: s=3.3.3.1 (Vlan3), d=3.3.3.2, len 43, input feature, Access List(47), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
*Dec 17 18:11:30.721: IP: s=3.3.3.1 (Vlan3), d=3.3.3.2, len 43, input feature, MCI Check(109), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
*Dec 17 18:11:30.722: IP: s=3.3.3.1 (Vlan3), d=3.3.3.2, len 43, rcvd 2
*Dec 17 18:11:30.723: IP: s=3.3.3.1 (Vlan3), d=3.3.3.2, len 43, stop process pak for forus packet
*Dec 17 18:11:30.725: IP: s=3.3.3.1 (Vlan3), d=3.3.3.2, len 43, input feature, Access List(47), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
*Dec 17 18:11:30.726: IP: s=3.3.3.1 (Vlan3), d=3.3.3.2, len 43, input feature, MCI Check(109), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
*Dec 17 18:11:30.728: IP: s=3.3.3.1 (Vlan3), d=3.3.3.2, len 43, rcvd 2
*Dec 17 18:11:30.728: IP: s=3.3.3.1 (Vlan3), d=3.3.3.2, len 43, stop process pak for forus packet
*Dec 17 18:11:30.733: IP: s=3.3.3.1 (Vlan3), d=3.3.3.2, len 49, input feature, Access List(47), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
*Dec 17 18:11:30.734: IP: s=3.3.3.1 (Vlan3), d=3.3.3.2, len 49, input feature, MCI Check(109), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
*Dec 17 18:11:30.735: IP: s=3.3.3.1 (Vlan3), d=3.3.3.2, len 49, rcvd 2
*Dec 17 18:11:30.735: IP: s=3.3.3.1 (Vlan3), d=3.3.3.2, len 49, stop process pak for forus packet
*Dec 17 18:11:30.765: IP: s=3.3.3.1 (Vlan3), d=3.3.3.2, len 40, input feature, Access List(47), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
*Dec 17 18:11:30.766: IP: s=3.3.3.1 (Vlan3), d=3.3.3.2, len 40, input feature, MCI Check(109), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
*Dec 17 18:11:30.769: IP: s=3.3.3.1 (Vlan3), d=3.3.3.2, len 40, rcvd 2
*Dec 17 18:11:30.769: IP: s=3.3.3.1 (Vlan3), d=3.3.3.2, len 40, stop process pak for forus packet
*Dec 17 18:11:30.771: IP: s=3.3.3.1 (Vlan3), d=3.3.3.2, len 40, input feature, Access List(47), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
*Dec 17 18:11:30.772: IP: s=3.3.3.1 (Vlan3), d=3.3.3.2, len 40, input feature, MCI Check(109), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
*Dec 17 18:11:30.773: IP: s=3.3.3.1 (Vlan3), d=3.3.3.2, len 40, rcvd 2
*Dec 17 18:11:30.773: IP: s=3.3.3.1 (Vlan3), d=3.3.3.2, len 40, stop process pak for forus packet
*Dec 17 18:11:30.970: IP: s=3.3.3.1 (Vlan3), d=3.3.3.2, len 40, input feature, Access List(47), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
*Dec 17 18:11:30.971: IP: s=3.3.3.1 (Vlan3), d=3.3.3.2, len 40, input feature, MCI Check(109), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
*Dec 17 18:11:30.973: IP: s=3.3.3.1 (Vlan3), d=3.3.3.2, len 40, rcvd 2
*Dec 17 18:11:30.973: IP: s=3.3.3.1 (Vlan3), d=3.3.3.2, len 40, stop process pak for forus packet
*Dec 17 18:12:01.686: IP: s=3.3.3.1 (Vlan3), d=3.3.3.2, len 40, input feature, Access List(47), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
*Dec 17 18:12:01.687: IP: s=3.3.3.1 (Vlan3), d=3.3.3.2, len 40, input feature, MCI Check(109), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
*Dec 17 18:12:01.688: IP: s=3.3.3.1 (Vlan3), d=3.3.3.2, len 40, rcvd 2
*Dec 17 18:12:01.689: IP: s=3.3.3.1 (Vlan3), d=3.3.3.2, len 40, stop process pak for forus packet

L3-2#sh access-list 101
Extended IP access list 101
10 permit tcp any any eq telnet (48 matches)
20 deny ip any any
L3-2#

!now back to L3-1. Let's ping 3.3.3.2 again.
L3-1#ping 3.3.3.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 3.3.3.2, timeout is 2 seconds:
U.U.U
Success rate is 0 percent (0/5)
L3-1#

!back to L3-2. Check access-list hits showing our denied pings are matching seq no 20
L3-2#sh access-list 101
Extended IP access list 101
10 permit tcp any any eq telnet (48 matches)
20 deny ip any any (9 matches)
L3-2#

So this permits any IP (in this case 3.3.3.1 of L3-1) to any destination IP, with a further restriction that the destination IP is contactable on telnet port 69. Just telnet. Our port on the source ip has no restrictions but for the destination IP we are only allowed to connect on port 69, where a telnet service is running on L3-2. This port number association with source or destination we'll come to later as changing the direction of the ACL changes the logic.

Another solution to this as you have alluded to would be

L3-2(config)#line vty 0 4
L3-2(config-line)#access-class 101 in

L3-2#sh run | b line vty 0 4
line vty 0 4
access-class 101 in
password cisco
login
!
!
end

L3-2#

which is more elegant `as you don't have to worry about maintaining access-lists on every interface. Try this config with the same access-list and observe the access-list counters and debug output is similar. A standard access-list is sufficient on the line vty.              

Speaking of which, extended access-lists are better placed closer to the source of the traffic, as they are more specific. I'm not going to go into this here but it's definitely worth reading about optimum standard and extended access-list placement. I'm sure some of the other clever guys on the forum can expand on this.

Now your other question was why if we put the access-list outbound on vlan 3 why this doesn't stop traffic. If we were to change the direction of the access-list from in to out on SVI vlan 3 on L3-2, you would expect the telnet from L3-1 to L3-2 to fail. Config as follows

L3-2#sh run int vlan 3
Building configuration...

Current configuration : 81 bytes
!
interface Vlan3
ip address 3.3.3.2 255.255.255.0
ip access-group 101 out
end

L3-2#sh access-list 101
Extended IP access list 101
10 permit tcp any any eq telnet (48 matches)
20 deny ip any any (9 matches)
L3-2#

The logic being that you may successfully connect to 3.3.3.2, however you will hit the outbound access-list filter on the way back. Return traffic will not be destined to 3.3.3.1 on well-known port 69 but rather a port number >1024. It will therefore hit the seq 20 deny statement.

However if you clear the access-list counters on L3-2 and try telnetting to 3.3.3.2 from L3-1, you will see that not only can you successfully connect but the outbound access-list on L3-2 is not being matched at all. 

L3-2#sh access-list 101
Extended IP access list 101
10 permit tcp any any eq telnet
20 deny ip any any

This is because the traffic source and destinations are both within VLAN 3, so the outbound access-list won't be used unless the packet source is outside the subnet. This is a little counter-intuitive, the logic on SVIs being as follows

an acl applied inbound to an SVI controls traffic from devices in that vlan

an acl applied outbound to an SVI controls traffic to devices in that vlan

source: https://community.cisco.com/t5/switching/pls-explain-svi-acl-source-and-destination-direction/m-p/2365580/highlight/true#M277440

The outbound access-list behaviour configured is only applied when traffic traverses the SVI i.e. goes outside VLAN 3 subnet aka inter-vlan routing.

To illustrate, if we add another switch to the topology using a routed connection, then try and telnet from L3-1 to the new switch, then this telnet operation will fail due to the outbound access-list. The outbound access-list counters on L3-2 will increment at sequence 20. Note we haven't matched seq 10 at all due to port number (we would have matched if the access-list was inbound).

L3-2#sh access-list 101
Extended IP access list 101
10 permit tcp any any eq telnet
20 deny ip any any (3 matches)
L3-2#

To further verify, if we adjust the access-list to move the port number from the destination to the source, to match the outbound direction towards L3-1 (return traffic from the new switch we're telnetting to), then the telnet will succeed. This shows that traffic outside of the VLAN 3 subnet is subject to the outbound ACL on the SVI due to the requirement to layer 3 route on the SVI.

L3-2#sh access-list 101
Extended IP access list 101
10 permit tcp any eq telnet any (9 matches)
20 deny ip any any
L3-2#

As a control test, if we make the connection between L3-2 and the third switch also a trunk, giving the latter an SVI also in VLAN 3, then try and telnet from L3-1 to the third switch what will be the expected outcome? The result is that telnet will succeed. The outbound ACL on L3-2 will receive no matches as we are within the VLAN 3 subnet. 

Hope this helps. Please rate if it does.

[sivam siva]

Hello @Simon Darlington 

Just to correct you ,telnet port is 23 ,port 69 is tftp

and you said that when packets are going out if its belongs to same subnet, it does not check the ACL (in my case).

again i have done one test with outbound filter,but it does the filtering work. below the result 

L3-2#sh access-lists
Extended IP access list 101
1 permit tcp any eq telnet any
20 deny tcp any any eq telnet
L3-2#tel 3.3.3.1
Trying 3.3.3.1 ...
% Connection refused by remote host

L3-2#sh run int vl 3
Building configuration...

Current configuration : 78 bytes
!
interface Vlan3
ip address 3.3.3.2 255.0.0.0
ip access-group 101 out
end

As @Richard Burts said i should configure source and destination pots properly ,but i didn't, that is the mistake. 

Thank you all for the reply

[Simon Darlington]

Hi @sivam siva

Good spot on the port number and thanks for the feedback. Glad you have resolved your issue.

Thanks Simon

[Richard Burts]

This has been a discussion about some very important points. Thank you for marking this question as solved. This will help other participants in the community to identify discussions which have useful information. The community is an excellent place to ask questions and to learn about networking. I hope to see you continue to be active in the community. 

I believe that these are some of the important points related to this discussion.

1) There are multiple ways to apply an access list. While they seem similar on the surface they are quite different. You can apply an access list to filter traffic on an interface using ip access-group. You can apply an access list to control remote access using ip access-class.

2) When using an access list to filter traffic on an interface it is most often done using an extended access list. When using an access list to control remote access it is most often done using a standard access list.

3) When using an extended access list on an interface to filter traffic it is important to understand the differences between in and out in applying the access-group. This is done according to the perspective of the router/switch. In is traffic coming from the connected subnet into the interface. Out is traffic coming through the router/switch and going out to the connected subnet.

4) When using an extended access list on an interface to filter traffic it is important to specify the correct source and destination protocol ports (and this is related to whether the list is applied in or out).

5) When you want to control remote access it might be done using access-group or access-class but it is easier and better to use access-class.

HTH

Rick