Extended ACLs placed in destination if source might be any source

[Mary Leon]

I'm practicing with ACL extended in Packet Tracer.

There's a router with 3 interfaces and I would like to allow telnet the router coming from one of the 3 interfaces but I would like to deny telnet from any source on any ot the two other interfaces.

I have read that extended ACL should be placed the closest to the source as possible, but what happens if I don't have access to other routers in any other source?

For the interface I would like to permit, I know where to place the ACL, but would it make sense to put this kind of extended ACL in the destination (the router itself) and apply it in the two other interfaces with in modifier?

I'm a bit confused here.

Thank you for your help.

[Spooster IT Services · Accepted solution]

@Mary Leon,

To secure the management access to the device, there are two different ways:

1. Control plane security
   • where you can simply tell the device to listen for the management traffic on a specific interface, select the protocol and bind a service policy to whitelist specific IP/Subnets.
2. Apply access-list to Line VTY
   • ip access-list extended MGMT_ACL
     permit ip host <source> <destination>
     
     
   • line vty 0 15
     access-class MGMT_ACL in

***Please mark all helpful replies***

[Spooster IT Services · Accepted solution]

@Mary Leon 

I have read that extended ACL should be placed the closest to the source as possible, but what happens if I don't have access to other routers in any other source?

This statement is not true in all the case. Especially where you don't have any control over the transit devices in the path.

For the interface I would like to permit, I know where to place the ACL, but would it make sense to put this kind of extended ACL in the destination (the router itself) and apply it in the two other interfaces with in modifier?

Yes, Inbound ACL filters to the box traffic whereas Outbound ACLs cannot.

***Please mark all helpful replies***

[Richard Burts]

As @Spooster IT Services has responded the advice to place an extended access list close to the source is advice about how to optimize the operation of the access list. But it certainly is not a requirement. Perhaps we want to think about that as advice to place the access list on a device where you have access that is as close to the source as possible.

And while it is possible to control access to the router by using extended access lists on interfaces there are more effective and more efficient ways to accomplish this. The more common way to control telnet access (or SSH access) is to use a standard access list to identify the source addresses to be permitted (or to be denied) and to apply that access list on the vty interfaces using the access-class command. While you could do this denying access from the other 2 interfaces I would suggest that you use the standard access list to permit the interface that you do want to be able to telnet. The implicit deny any at the bottom of the access list means that any device not permitted will be denied. So this would deny telnet from the other two interfaces and also from any other device outside of your router. It is also possible to control telnet access in some versions of code using control plane security.