Digging deeper into this issue I was able to pin down the problem.

I created two new VLANs on my Gateway Router (ER707M2) named 214 and 215. The interfaces were created on the router. Therefore the routing is handled through the router.

A 214 host on Server A can ping a 215 host on Server B over the router -> Ping OK

Applying following switch ACL onto the switch:

Combined access list 1002 name: "ACL_1002"
        rule 1 deny logging disable sip 192.168.214.1 sip-mask 255.255.255.0 dip 192.168.215.1 dip-mask 255.255.255.0 protocol 1

The two host can't ping themselves anymore -> Ping NOK

Which resembles the wished behavior.

If I leave the exact same ACL, but move the VLAN interfaces of 214 and 215 to the switch.

The two host can ping themselves regardless of the above ACL -> Ping OK

Which isn't how this should work. It seems the Inter-VLAN-Routing goes through beneath the ACLs, rendering them useless.

I will raise a ticket for that.

  @Clusters 

Clusters wrote

Digging deeper into this issue I was able to pin down the problem.

 

I created two new VLANs on my Gateway Router (ER707M2) named 214 and 215. The interfaces were created on the router. Therefore the routing is handled through the router.

 

A 214 host on Server A can ping a 215 host on Server B over the router -> Ping OK

 

Applying following switch ACL onto the switch:

Combined access list 1002 name: "ACL_1002"
        rule 1 deny logging disable sip 192.168.214.1 sip-mask 255.255.255.0 dip 192.168.215.1 dip-mask 255.255.255.0 protocol 1

 

The two host can't ping themselves anymore -> Ping NOK

Which resembles the wished behavior.

 

If I leave the exact same ACL, but move the VLAN interfaces of 214 and 215 to the switch.

The two host can ping themselves regardless of the above ACL -> Ping OK

Which isn't how this should work. It seems the Inter-VLAN-Routing goes through beneath the ACLs, rendering them useless.

 

I will raise a ticket for that.

Now, it is not the VLAN interface created on the router, but the VLAN interface on the switch(DHCP server+802.1Q VLAN), it is still ping-able with a block on SW ACL?

  @Clive_A Good Morning :)

Yes, exactly. The router VLAN interfaces will be blocked/allowed on the switch according to its switch ACLs (also the VLAN packages are forwarded/trunked correctly). Only the VLAN interfaces of the switch can't be blocked via switch ACLs and therefore are always allowed.

I tried the switch DHCP as well as an external DHCP service, which unfortunately made no difference. However, DHCP works normally.

Regarding 802.1q: All ports are trunk ports, because packages are received already tagged with VLAN on all ports.

Hi @Clusters 

Thanks for posting in our business forum.

Clusters wrote

  @Clive_A Good Morning :)

 

Yes, exactly. The router VLAN interfaces will be blocked/allowed on the switch according to its switch ACLs (also the VLAN packages are forwarded/trunked correctly). Only the VLAN interfaces of the switch can't be blocked via switch ACLs and therefore are always allowed.

I tried the switch DHCP as well as an external DHCP service, which unfortunately made no difference. However, DHCP works normally.

Regarding 802.1q: All ports are trunk ports, because packages are received already tagged with VLAN on all ports.

Do you have a controller or not? I think you do. Correct?

Can you show a config of your related parameters? Switch VLAN interface and setup, SW ACL as well.

  @Clive_A 

Hi, yes I have a software SDN Controller and deploy my configuration and ACLs thorugh it. The Controller seem to write the ACLs to the switch correctly (I've verified that with CLI on the switch).

I've visualized the two scenarios from my yesterdays reply for you. First is the good case, second is the not-working case.

Diagram 1: Scenario 1 - The VLAN interfaces are configured on the Router

In Scenario 1 the ICMPs are routed through the router. As soon as the Switch ACL shown in the diagram is set, the Ping does not get through anymore, which is the expected behaviour in my eyes. Note: The router has no ACLs configured.

Diagram 2: Scenario 2 - The VLAN interfaces are configured on the Switch

Scenario 2 is the same as Scenario 1, but the VLAN interfaces for 214 and 215 are configured on the switch now. The ACL in both scenarios is exactly the same. But in Scenario 2 the Ping goes through the switch in both directions, regardless of the ACL.

As you can also observe in my setup, I can't really rely on the Router VLANs of Scenario 1, because they are to costly being routed two times over the mesh-bridge. Therefore I depend on Switch VLAN Interfaces to not overstress the mesh-bridge.

I tried to include all the relevant configuration I did (I'm currently in a setup stage and have a quite simple network). Please tell me if I forgot something of interest here, or if you need the running-config of e.g. the switch.

I configured the VLAN interfaces and ACLs completely through Omada:
For Scenario 2 I did following configuration steps:

1. Create a new LAN -> VLAN

2. Within the switch device I configure the VLAN with the switch as gateway and DHCP server and enable it afterwards

3. Add static route in Omada Settings -> Transmission -> Routing for the VLAN interface gateway and subnet. (just for completeness)

4. Add the new VLAN to all trunk ports

5. Create the switch ACL

The IP groups look like this:

The configuration above only covers VLAN 214, but VLAN 215 will be created accordingly, just with a subnet 192.168.215.1/24

Hi @Clusters 

Thanks for posting in our business forum.

Clusters wrote

  @Clive_A 

 

Hi, yes I have a software SDN Controller and deploy my configuration and ACLs thorugh it. The Controller seem to write the ACLs to the switch correctly (I've verified that with CLI on the switch).

 

I've visualized the two scenarios from my yesterdays reply for you. First is the good case, second is the not-working case.

 

Diagram 1: Scenario 1 - The VLAN interfaces are configured on the Router

 

In Scenario 1 the ICMPs are routed through the router. As soon as the Switch ACL shown in the diagram is set, the Ping does not get through anymore, which is the expected behaviour in my eyes. Note: The router has no ACLs configured.

 

 

 

Diagram 2: Scenario 2 - The VLAN interfaces are configured on the Switch

 

Scenario 2 is the same as Scenario 1, but the VLAN interfaces for 214 and 215 are configured on the switch now. The ACL in both scenarios is exactly the same. But in Scenario 2 the Ping goes through the switch in both directions, regardless of the ACL.

As you can also observe in my setup, I can't really rely on the Router VLANs of Scenario 1, because they are to costly being routed two times over the mesh-bridge. Therefore I depend on Switch VLAN Interfaces to not overstress the mesh-bridge.

 

I tried to include all the relevant configuration I did (I'm currently in a setup stage and have a quite simple network). Please tell me if I forgot something of interest here, or if you need the running-config of e.g. the switch.

 

I configured the VLAN interfaces and ACLs completely through Omada:
For Scenario 2 I did following configuration steps:

1. Create a new LAN -> VLAN

 

 

2. Within the switch device I configure the VLAN with the switch as gateway and DHCP server and enable it afterwards

 

 

3. Add static route in Omada Settings -> Transmission -> Routing for the VLAN interface gateway and subnet. (just for completeness)

4. Add the new VLAN to all trunk ports

5. Create the switch ACL

 

 

The IP groups look like this:

 

 

The configuration above only covers VLAN 214, but VLAN 215 will be created accordingly, just with a subnet 192.168.215.1/24

I forgot to reply to this. Very sorry. Can you show a tracer route of how the routing looks like?

We did a test like what you described and failed to replicate your situation.

Hi   @Clive_A 

no problem, I managed to resolve this via the Technical Support instead.
The Support acknowledged that this is indeed a software bug inside the above mentioned switch model. It prevents ICMP traffic from being blocked by ACL, if the switch is acting as the VLAN-Gateway.

I had no time yet to verify, that the blocking works for TCP and UDP. Which should still the case according to Support.

It was mentioned that there will possibly be a fix for this in the future. However, no time scope could be given. I assume it's not highly prioritized, especially if TCP/UDP is working fine.