iACL on N5K blocking allowed traffic?

[aLeffingwell]

Hi All,

Here's the base setup:

• N5K, has a management IP of: 10.132.5.37 - is in the 'management' vrf, and has a default route for that vrf of 10.132.5.1.
  • I can ping hosts in any of the ranges I'm trying to manage the switches from so connectivity is there.
  • I can establish SSH sessions to the N5K as a baseline so - a second verification of connectivity.
• A dedicated management station sitting at: 10.132.6.145, which is pingable bi-directionally to the mgmt0 interface

Here's what I want to achieve:

• Allow only a single management workstation to be able to SSH to the N5K for management purposes

Here's how I tried to accomplish it:

• Create an ACL:
  • conf t
  • ip access-list TEST
  • permit 22 host 10.132.6.145 host 10.132.5.37
  • (permit  22 host 10.132.5.37 host 10.132.6.145 - I feel like this is redundant  and doesn't apply since i'm applying this ACL inbound .. but included  just in case someone were to bring it up and it's not going to hurt  anything)
  • int mgmt0
  • ip access-group TEST in

I  loose connectivity immediately after applying the list.. I noticed  originally that my vPC peer link died with this application, and that  that might be causing the problem, so I added entries to include the  peer link ports, and it worked like a charm.. so .. the problem still  remains why I cannot SSH to the switch with such a basic ACL applied??

Thanks in advance for any insight into this issue!

Kindest Regards,

ALAN

[pille1234 · Accepted solution]

You probably meant the peer keep alive link and not the peer link don't you? Else I don't have an explanation why an ACL on your mgmt interface should have an impact on other interfaces.

First, your ACL is wrong. With "permit 22" you allow protocol type 22 and not tcp/22. Try this:

permit tcp host 10.132.6.145 host 10.132.5.37 eq 22

However this will again kill your vPC keep-alives, snmp and whatever else is received on the mgmt interface. If all you want to do is to restrict vty access this could be achieved in an easier way without interfering with other management traffic:

line vty
access-class 100 in
ip access-list 100
10 permit ip host 10.132.6.145 any

Regards

Pille

[aLeffingwell]

Hey Pille,

Thanks so much for your help, it's been great!  You know as simple as it is I didn't even think about the vty lines, everything kept centering around the physical interface 'mgmt0' so I just assumed the application would be on that interface.  It makes total sense now to use an access-class on them to allow only the management station.

As far as the format for the original list, I tried a number of variations and I"m fairly positive I tried the one you posted.  Regardless it's good to know that the number alone is a type not the port, and to use the eq XX syntax. 

For the vPC related 'stuff' you're correct I did mean the peer keep alive link, and right now it's configured based on the mgmt0 IP's to it's partner, so blocking the interface blocked the keep alives.  Thanks again for your fantastic help, closing and rating!

Kindest Regards,

ALAN