SVI ACL behaviour

[Little Bunny]

Hello

Hoping someone can shed some light on this ACL behaviour we're seeing. We have 2 Nexus 9ks with a vlan interface configured as follows:

interface Vlan15
no shutdown
mtu 9216
no ip redirects
ip address 172.20.15.2/24
no ipv6 redirects
ip ospf passive-interface
ip router ospf 100 area 0.0.0.0
hsrp version 2
hsrp 15
authentication md5 key-string 15
preempt delay minimum 30
priority 150
timers 1 3
ip 172.20.15.1
ip dhcp relay address 172.20.x.x
ip dhcp relay address 172.20.x.x

There are two servers behind it and I'm trying to restrict access from the servers outbound. This is the ACL I applied:

ip access-list ACL_VLAN15_in
permit tcp any <public ip>/32 eq 8000
permit tcp any <public ip>/32 eq 8089
permit tcp any <public ip>/32 eq 9997
deny icmp any any
deny tcp any any eq 22
deny tcp any any eq 514
deny udp any any eq 514
deny tcp any any eq 9100
deny ip any any
statistics per-entry

Once I apply this to vlan 15 we can no longer SSH to the servers from outside. I added the deny eq22 statement to see if it was somehow being blocked in the opposite direction, but the stats show that it's not:

# sh ip access-lists ACL_VLAN15_in

IP access list ACL_VLAN15_in
statistics per-entry
10 permit tcp any <public ip>/32 eq 8000 [match=0]
20 permit tcp any <public ip>/32 eq 8089 [match=178]
30 permit tcp any <public ip>/32 eq 9997 [match=88174]
40 deny icmp any any [match=18]
50 deny tcp any any eq 22 [match=0]
60 deny tcp any any eq cmd [match=0]
70 deny udp any any eq syslog [match=0]
80 deny ip any any [match=4595]

Two questions:

1) Why is traffic in the other direction affected?

2) Is there an easy way to see what traffic is hitting the deny statement at the end so we can identify which additional ports need to be allowed?

Thanks

LB

[acampbell · Accepted solution]

Hi,

can you try lne 50 the other way round as ther servers will be acting as
SSH server end not client
Try

deny tcp any eq 22 any

Overall looking at your acces list the 1st 3 lines are permit tcp statements
The list would automatically apply an implicit deny all so you do not need the
deny statements at all.

If you want SSH to your servers alowed then add that to the permit statements
and add a log keyword to the deny at the end

!
ip access-list ACL_VLAN15_in
permit tcp any <public ip>/32 eq 8000
permit tcp any <public ip>/32 eq 8089
permit tcp any <public ip>/32 eq 9997
permit tcp any eq 22 YOURADD/32
deny any any log
!

Now your servers are allowed out to some http type ports and you can SSH in.

sh log should tell you about any denied hits and from from where

[Jon Marshall]

You don't say which direction you applied the acl and you also mention two servers but your acl does not reference any individual 172.20.15.x IPs so it's not entirely clear what is going on. 

Assuming the acl is applied inbound on the SVI you cannot SSH because acls are not stateful so the return traffic from the server(s) is being blocked by your last line. 

Assuming it is inbound then add this before your last line to test - 

permit <server IP.> eq ssh any 

and see if it works. 

Jon

[Little Bunny]

Thanks for the replies, I swapped line 50 around as you both suggested and it worked great! I'm not sure I understand this behaviour though as the ACL is applied inbound on the vlan interface so why does it affect SSH traffic coming to the vlan from outside?

LB

[Jon Marshall · Accepted solution]

It doesn't the traffic going to the server but it does affect the return traffic from the server. 

This is what I meant when I said an acl is not stateful. 

Jon