@userNAC 

 

Try this video on youtube, describes ACL rules more elegantly than I can

 

https://www.youtube.com/watch?v=7i17jvrIjD0&t=3s

 

Rule as below might help you, just remember to set a higher rule allowing the specific ports to access, rest blocked by this

 

 

 

Did some tests with the following configuration:

 

 

The rules are very counter intuitive. If I Allow Main to IOT and Deny IoT to Main, I cannot ping IoT from Main.

 

The only way I can ping Main is when I remove the deny Rule from the IoT to Main.

 

 

Since the block IoT rule is only from the IoT to the Main network why this rule blocking any ping from the Main to IoT?

 

Ping from the Main to IoT only works when the Deny rule does not have Main at the destination, even if the ping is originated from Main with the IoT Destination. From the screen shot above the rule is very clear about being uni directional and originated from IOT to the Main, not the other way around, especially when there is an Allow rule from Main to the IOT at the top of the rules. 

 

What gives?

@Philbert 

 

watched that video and actually used it for the rules

 

 

I have an Allow Main to IoT on top and I made sure that I wouldn't block Main from the IoT even if the rule was lower priority than the allow. 

 

So what are you saying that I could only make some workable rule when only using Ip Group, Ip Ports and Mac protocols without network?

 

I cannot set untagged ports from the router on different vlans, that basically forced me to have devices in the Management Lan and I cannot make the rules working. This is very bad.

@userNAC 

 

Hey

 

Just looking at the screen you provided it appears you have indeed setup the Permit from Mains to IOT, however you have denied all traffic back from the IOT.  Therefore this wont work right.    If you are on the MAINS then you can send anything to the IOT, however it wont be able to reply to you.  You really only need 2 rules for this

 

 

1. Ok so I would start with Deleting Rule 1, ill explain this below   (Mains to IOT Permit)

 

2. Next check rules 2 3 and 4 are one way only..  basically blocking traffic coming OUT of the vlan

 

This is the reason you cant ping, the ACL rule above will stop any traffic going OUT of the IOT to the other VLANs, but it wont block it coming IN.  Therefore when you ping from the Main VLAN it will get through to the IOT, however IOT wont be able to reply back, therefore the ping fails. 

This is also why you dont need rule 1, by default VLAN traffic is allowed and this rule wont block Main to IOT, therefore negating the need to set rule 1.

 

3.  Copy this setup for the other VLANs as you need, by looks of screenshot you have this already.

 

4.  Now we need to set an PERMIT for the ports you need to allow them to reply from the IOT, this will overrule the deny above

 

5.  Go to SETTINGS    PROFILES   GROUPS and create a new group,  choose IP-Port Group

In the subnet, set the IP range for your IOT devices.. sample above is 10.0.0.1 on a 24 mask.    next add the ports you need to use, example above is 1001 to 1006 and 1501

 

save this

 

Go back to the ACLs and create a new rule, this time permit and choose the IP-Port Group you just created, allow access one way to the Main Vlan.

 

 

Set this rule HIGHER than the deny rule.   

 

Ok so in essence what you have done is..   allowed full access from MAIN to IOT (this is default behaviour).   Allowed IOT devices to reply to MAIN on specific ports  1001-1006 and 1501...   the deny rule will stop all other traffic from IOT to Mains that isn't on the allowed port list.

 

Hopefully that helps!

 

ACLs can be tough to get their head around, just remember when you create a network ACL between VLANS it will stop everything.. even ping.. unless you have a higher rule to open that port or service.   This is generally good practice, allow what you need.. block everything else

 

 

@Philbert Thank you very much about the feedback.

 

The explanation you gave makes sense. 

 

Kept the deny rules in order to block inter vlan communication but I can't say I am very happy about the way Omada SDN Controller works. 

 

Now I am in a world of pain in order to figure up the ports needed for various iot devices. I am at a loss of not understanding why wouldn't they simply allow established connections rule. Or allow untaged vlans at router ports. 

 

It is not like I would ask for avahi in order to broadcast mDNS traffic across subnets.

 

@userNAC 

 

Oh 100% agree!  I cant quite figure how an established connection rule wouldn't be included in Omada.

 

Fae has mentioned SDN v5 a few times already, hopefully this is something on the radar, it took me way too much time to find the ports for my CCTV when I set up Omada