Switch ACL for Switch-VLAN won't block traffic SG3210X-M2
Attention! My switch model is SG3210X-M2 not the "HP" variant selected above. The non-"HP" model can not be selected.
Hi!
I'm currently trying to set up some Switch ACL rules to block DMZ traffic flow.
I have two VLANs 120 (DMZ) and 121 (DMZ backend), as well as the management VLAN 1. Both VLANs are configured as Switch VLANs, meaning they are enabled as VLAN Interfaces within the Switch device.
Inter-VLAN-Routing works. The traffic is routed through the Switch (and not through my Gateway-Router).
Those ICMP requests are responded and received correctly (Ping OK).
However, if I try to set a deny Switch ACL like below, it won't block ICMP Traffic.
Switch ACL
Policy: Deny
Protocols: ICMP
Source: IP_Group 192.168.120.0/24
Destination: IP_Group 192.168.121.0/24
Binding Type: All ports
Pinging still works without any drops or rerouting in both directions.
What am I doing wrong?
What I tried already:
- Force provisioning
- Reapply configuration
- Rebooted Switch
- Inspected the running config -> ACL is shown there
Maybe also relevant:
I'm using Omada SDN 5.13.23
Switch configuration:
SG3210X-M2#show access-list
Combined access list 1000 name: "ACL_1000"
rule 1 deny logging disable sip 192.168.120.0 sip-mask 255.255.255.0 dip 192.168.121.0 dip-mask 255.255.255.0 protocol 1
SG3210X-M2#show interface vlan 120
VLAN120 is up, line protocol is up
Hardware is CPU Interface, address is xx:xx:xx:xx:xx:xx
ip is 192.168.120.1/24
SG3210X-M2#show interface vlan 121
VLAN121 is up, line protocol is up
Hardware is CPU Interface, address is xx:xx:xx:xx:xx:xx
ip is 192.168.121.1/24
- Copy Link
- Subscribe
- Bookmark
- Report Inappropriate Content
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.
- Copy Link
- Report Inappropriate Content
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?
- Copy Link
- Report Inappropriate Content
@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.
- Copy Link
- Report Inappropriate Content
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.
- Copy Link
- Report Inappropriate Content
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:
- 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
- Copy Link
- Report Inappropriate Content
Hi @Clusters
Thanks for posting in our business forum.
Clusters wrote
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:
- 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.
- Copy Link
- Report Inappropriate Content
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.
- Copy Link
- Report Inappropriate Content
Information
Helpful: 1
Views: 875
Replies: 7