block ssh to a svi

[Frame43]

I have a svi (10.194.82.6/24) that's used for management of a switch P (vlan 82). The same vlan is used for management of other switches. 

i have to block all ssh access to this svi of switch P only except from 10.180.4.0/24 and 10.180.6.0/24 networks.

i have tried 

ip access-list extended vty01 

permit tcp 10.180.4.0 0.0.0.255 10.194.82.6 0.0.0.0 eq 22

permit tcp 10.180.6.0 0.0.0.255 10.194.82.6 0.0.0.0 eq 22

!

interface vlan 82

ip access-group vty01 in

but it still seems to allow. What am I doing wrong.

[Dennis Mink]

create an access class instead and add it to your line vty 0 x

this link has easy steps on how to configure it

http://www.omnisecu.com/cisco-certified-network-associate-ccna/how-to-create-and-configure-access-control-lists-for-vty-lines-telnet-ssh.php

cheers

[cofee]

Hello,

Where are these two networks located 10.180.4.0/24 and 10.180.6.0/24? Do they hang off the same switch on which you configured access-list? if so, then try this, lets say svi for 10.180.4.0/24 is SVI 4 and for the other network it is SVI 6.

ip access-list extended vty01_SVI4 

permit tcp 10.180.4.0 0.0.0.255 10.194.82.6 0.0.0.0 eq 22

!

ip access-list extended vty01_SVI6

permit tcp 10.180.6.0 0.0.0.255 10.194.82.6 0.0.0.0 eq 22

!

interface vlan 4

ip access-group vty01_SVI4 in

!

interface vlan 6

ip access-group vty01_SVI6 in

If my assumption about your topology is incorrect then please share the details. Just remember it's always better to apply the access-list closest to the source. I hope it helps you.

[Frame43]

These two networks are not on the switch. These are two networks that should be able to connect to svi interface via ssh and any other networks shouldn’t be able to ssh into them. 

Thanks

[Frame43]

Also one more question. Why do we write include the wild card as 0.0.0.0 if the svi 10.180.6.0/24 . Shouldn’t it be 10.180.6.0 0.0.0.0.255? I may be wrong but I want to know the difference .

[cofee]

Why do we write include the wild card as 0.0.0.0 if the svi 10.180.6.0/24 . Shouldn’t it be 10.180.6.0 0.0.0.0.255? I may be wrong but I want to know the difference:

Access-lists use inverse mask or wildcard mask which is a mask of bits that indicates which part of an ip address are available for examination.

To calculate wildcard mask or inverse mask you subtract original mask from 255.255.255.255. Lets use this method to get the wildcard mask for 10.180.6.0/24

  255.255.255.255

- 255.255.255.0    or /24

______________

0.0.0.255  ( this will be the correct wildcard mask for 10.180.6.0/24 and not 0.0.0.0, a wildcard mask of 0.0.0.0 represent an host address where all bits are turned on and must match. I hope this makes sense.

Back to your original problem. Since you mentioned that networks you want to allow for remote access to switch over port 22 (ssh) should work with the access-list you have configured, but the direction under SVI 82 should be outbound and not inbound since incoming traffic from these two network arrive on another interface of this switch and exits (out) from the virtual Vlan interface which is vlan 82. But applying ACLs on the SVI to control vty access to the local switch may not be a good idea because it will make things more complex and you would need to add more lines to the ACL so you don't block any other traffic.

You can also apply this ACL to the physical interface on the switch in the inbound direction, but as I mentioned above it may be not be a good idea because it makes thing more complicated and if you are not careful it can affect legitimate traffic and cause outage that may affect all kind of traffic and not just the remote access to the switch. On the other hand when you apply ACLs just under the line vty as Dennis suggested, it can only affect remote access to the switch and not anything else.

Below configuration can be used to achieve your goal:

access-list 20 permit 10.180.4.0 0.0.0.255

access-list 20 permit 10.180.6.0 0.0.0.255

access-list 20 deny any

!

line vty 0 4

access-class 20 in

!

[Frame43]

We aren’t using vty lines for some specific reason . 

This is management vlan . 

Wgat interface do you mean when you say traffic arrives on another interface and exists out vlan 82? 

My assumption was that since it is management vlan, traffic comes to the management vlan first and that’s why we are planning on blocking the traffic from enerering the switch via port 22.

[cofee]

Can you provide a traceroute output sourcing from 10.180.4.0/24 or 10.180.6.0/24 to management address on the switch?

[cofee]

I asked for traceroute so I could look at the traffic flow. It's possible that your ACL is working, but there may be another way for other networks to get in and remotely access the switch, so once you implement the ACL run a traceroute from the source network that should be blocked by the ACL and that would reveal whether it's a routing issue or the ACL.

If that's not the case then try implementing both in or out and see which one works. If none of this works then please provide a drawing of your network so we can see how the traffic flows.

[Deepak Kumar]

Hi,

try with below commands

If you want to apply VLAN filter:

access-list 101 permit ip 10.180.4.0 0.0.0.255 host 10.194.82.6
access-list 101 permit ip 10.180.6.0 0.0.0.255 host 10.194.82.6
!
access-list 102 permit ip any any 
! 

vlan access-map test 10
match ip address 101
action forward
!
vlan access-map test 20
match ip address 102
action drop

!

vlan filter test vlan-list 82

If you want to apply an ACL on VTY lines:

ip access-list extended SSH-ACL-Allowed
permit ip 10.180.4.0 0.0.0.255 any log
permit ip 10.180.6.0 0.0.0.255 any log

!

line vty 0 4
access-class SSH-ACL-Allowed in

Regards,

Deepak Kumar