ACL doesn't work

[ibrahimbdj]

I am doing a lab on Cisco Packet Tracer and have reached the ACL stage.
The course begins by giving small examples so that we can learn and understand the concept. But these examples do not work. I have been working on this for two hours, searching the internet but cannot find an answer, so I am asking you for help.
It's an ACL to prevent router A from connecting via SSH to router B. I'm configuring this ACL on router A. Here is the configuration (I should mention that I tested with in and out on the interface; the course tells me to use in, but I find that strange):

!

interface GigabitEthernet0/0/1

ip address 223.0.1.3 255.255.255.0

ip access-group 100 in

duplex auto

speed auto

!

!

access-list 100 deny tcp host 223.0.1.3 any eq 22

access-list 100 permit ip any any

!

[Gregory Camp]

access-list 100 deny tcp any host 223.0.1.3 eq 22

access-list 100 permit ip any any

Assuming you are trying to block SSH to that IP, you need to make 223.0.1.3 the destination and not the source in the ACL.

[ibrahimbdj]

First of all, thank you for your reply.
That's not my goal. I'm actually trying to prevent router A from attempting to connect to the other routers via its g0/0/1 interface, whose IP address is 223.0.1.3.

[David Ruess]

Hello,

If you are just using the 2 routers and blocking SSH from one to another I don't believe that will work. If I recall interface ACLs do not affect locally generated traffic. So if the interface ACL is on Router A and you're using router A to SSH then it likely wont block.

You can try to configure the ACL on Router B on the interface connected to Router A in the 'IN' direction.

-David

[ibrahimbdj]

Thank you for your reply.
But if I want to prevent router A from initiating an SSH connection with other routers via its g0/0/1 interface (IP: 223.0.1.3), how can I do this?

[Joseph W. Doherty · Accepted solution]

Try:

interface GigabitEthernet0/0/1
 ip address 223.0.1.3 255.255.255.0
 ip access-group 100 in

access-list 100 deny tcp any eq 22 host 223.0.1.3
access-list 100 permit ip any any

BTW, the above would only block SSH if 1) using its well known port and 2) if packet received on interface g0/0/1.

[Joseph W. Doherty]

Oh, also, the ACL I provided blocks router A initiating SSH with another router, e.g. router B.  If you also wanted to block other routers from initiating SSH to router A, you need another ACE:

access-list 100 deny tcp any host 223.0.1.3 eq 22

The above is what @Gregory Camp suggested, but the two different ACEs depend on which device is initiating SSH.  From A to B, as noted in the OP, my prior reply's ACE is needed. From B (or any other device) to A, this ACE is needed.  Of course, you can have both ACEs in the ACL.

Also BTW, the ACE blocking A to other devices, is blocking return packets, which, ideally, for efficiency, we want to block the outbound packets.  But, at @David Ruess noted, ACLs don't apply to locally (i.e. same device) generated packets.  I believe two possible alternatives would be to use PBR or QoS to block the router A outbound SSH packets, as I believe both would process all egress packets.

An example of a QoS policy, blocking both in and out.

interface GigabitEthernet0/0/1
 ip address 223.0.1.3 255.255.255.0
 service-policy in Example
 service-policy out Example

class-map Example
 match protocol ssh !I believe it might only match port 22, on src or dst, but in the future, migth actually protocol match, i.e. not depend on port 22 being used.

policy-map Example
 class Example
  drop !not all QoS implementations appear to support this command

[ibrahimbdj]

Thank you for your help.
Two hours of thinking, and yet I didn't think to block the connection attempt when router B responded. I feel stupid.

[Joseph W. Doherty]

---

@ibrahimbdj wrote:

Thank you for your help.
Two hours of thinking, and yet I didn't think to block the connection attempt when router B responded. I feel stupid.

---

Laugh I doubt you're stupid.  However, two way traffic flow, something you're unlikely to forget about in the future.

I don't know about others, but I've certainly has my own fair share of "duh" moments.  ; )