What I'm trying to achieve is as follows:
- Allow full access to the device on 10.58.9.32 (our VoIP server), from anywhere on our network.
- Allow ICMP to flow in all directions to/from any device.
- Prevent all other devices on 10.58.9.0/24 from communicating beyond the VLAN they are on.
To attempt to achieve this, I have created the following ACL on our core switch:
access-list voip permit ip 10.58.9.32 255.255.255.255 0.0.0.0 0.0.0.0 access-list voip permit ip 0.0.0.0 0.0.0.0 10.58.9.32 255.255.255.255 access-list voip permit icmp any any
Whilst I don't have an explicit deny rule, the 6224F processes rules in order and stops when it finds a match, if no match is found, an implied deny rule takes effect.
Subnet 10.58.9.0/24 is associated with VLAN 9, so I've applied the ACL to the VLAN interface as follows:
interface vlan 9 ip access-group voip in 1
VLAN 9 is routed via the core switch, and before I applied the ACL, any device on the entire network could communicate with any devices on VLAN 9 without restriction.
Having applied the ACL to the network, when I then try to connect from my desktop PC via SSH to 10.58.9.32, I can no longer establish a connection. Surely the first two rules would match for the SSH traffic flowing between the two and allow traffic to flow?
I've proven that the ACL is responsible, because when I remove it, I can once again SSH into the server.
I've got this working, by changing the access list to read as follows:
access-list voip permit ip 10.58.9.32 255.255.255.255 any access-list voip permit ip any 10.58.9.32 255.255.255.255 access-list voip permit icmp any any
I would have thought that
0.0.0.0 0.0.0.0 where identical, clearly not. Does any one know why this is the case?