** Updated - as I found out that my problem is related to object groups **
My understanding is, that on a L3 switch like the 3850 or 3750 with IP routing enabled, the following is true for IP ACLs applied to the SVI of VLANs:
- With no ACLs applied at all, all traffic is permitted between VLANs (the switch is acting as router)
- ACLs applied by an access-group to an SVI with the "in" keyword are applied to packets entering the switch from hosts connected to interfaces of that VLAN.Packets matching one of the ACEs can enter the switch.If no ACE matches, the switch drops the packet.
- ACLs applied by an access-group to an SVI with the "out" keyword are appliedafter routing and just before exiting the switch towards connected hosts. Same rules as for "in" apply.
- At the end of each ACL, there is an implicit "deny ip any any" statement.
To the best of my knowledge, that's exactly what the Cisco configuration guide says
(IOS software version 15.2).
However, when using object-groups in ACLs, this does not seem to work.
Test 1
Given these interfaces
interface vlan 4
ip address 10.0.4.0 255.255.255.0
ip access-group acl-4 in
interface vlan 7
ip address 10.0.7.0 255.255.255.0
ip access-group acl-7 in
and object groups
object-group network g4
10.0.4.0 255.255.255.0
object-group network g7
10.0.7.0 255.255.255.0
and these ACLs
ip access-list extended acl-4
permit ip object-group g4 object-group g4 log
ip access-list extended acl-7
permit ip object-group g7 object-group g7 log
the expected behaviour would be that the two VLANs are isolated.
I should not be able to ping hosts connected to ports of VLAN-7
from hosts connected to ports of VLAN-4.
What Really Happens
However, a real switch configured like the above allows all traffic from hosts of any VLAN to the hosts of the other VLAN. I have tested connectivity between the hosts using ping and also using RDP between PCs.
Log messages appear in the console that the traffic has been permitted by the above ACLs.
(Tested on a 3750-X)
(The command "show vlan" shows the proper interfaces connected to the VLANs
where my hosts are connected. This is not the problem.)
Adding an explicit
deny ip any any
into each of the two ACLs does not change anything - still all the traffic allowed.
Also adding explicit deny statements for the other VLAN has the same result.
This is contrary to how it should work.
And the object groups are correct - we can verify with
show ip access-list acl-4 expanded
which shows the object group expansion in ACL syntax as expected.
However, when replacing the object-groups with the written-out numeric representation,
then everything works as expected:
ip access-list extended acl-4
permit ip 10.0.4.0 0.0.0.255 10.0.4.0 0.0.0.255 log
ip access-list extended acl-7
permit ip 10.0.7.0 0.0.0.255 10.0.7.0 0.0.0.255 log
This works totally fine, no traffic allowed between VLANs.
Any more specific permit and deny statements work exactly as per the rules laid out above.
But as soon as any of the ACEs contain any object group in the source or destination
address, ALL traffic is allowed.
Is this is bug in IOS, including what is used in L3 switches?
I found following post stating a similar problem:
Object-group-entry-in-acl-breaks-ios-firewall
