lflorack wrote

My system is shown here for reference.  Also, here's a bulleted list of equipment.  I just checked/confirmed that they all have the latest firmware:

 

• TP-Link TLR-605 v1.0 (1.2.0)
• TP-Link OC200 v 1.0 (5.1.7)
• TP-Link TL-SG2210P v3.20 (3.20.2)
• (2) TP-Link TL-SG2218 v1.0 (1.1.2)
• (3) TP-Link EAP-245 V3.0 (5.0.5)
• TP-Link EAP-225 v1.0 (5.0.8)

 

I have (3) VLANs

• LAN 192.168.0.x (Management)
• IoT 192.168.30.x
• Guest 192.168.20.x

 

The Guest VLAN is isolated via the Guest rules.  I'd like the devices on LAN to be able to reach out and connect to devices on my IoT.  At the same time, devices on IoT should NOT be able to connect to anything on LAN.  With that in mind, I have created (2) Switch ACL rules via my OC200 hardware controller and ordered them as shown:

 

• Rule 1: Allow LAN > IoT

• Rule 2: Deny IoT > LAN

 

Pretty simple rules and a pretty simple concept.  However, this does not work as I expected it would.  The above Switch ACL rules cause connections between LAN and IoT to fail - and not allow any communication in either direction. (i.e., all communication between IoT and LAN is blocked.)  In the above rules, it seems that Rule #1 does nothing and I think that rule #2 actually overrides rule #1 (by default, all VLANs CAN all 'see' each other anyway).  If I disable rule #2, communication between LAN and IoT is open in BOTH directions.  The same result occurs if both rules are disabled or completely deleted.

 

Any insights on achieving what I'm trying to do?

 

(Edit: Updated device details)

@lflorack you and me both.   The ACL seems to be bi-directional even though I didnt set it up that way.  For me to ping from LAN to IoT, I have to change the ACL so that ICMP is not denied and then it works. But that leaves the IoT open to initiate pings back to me and see whats in my LAN

lflorack wrote

Your point about allowing the ICMP protocol to get through made me think about this a bit more.  Here's what I think is happening. 

Since the 'Allow' LAN to IoT ACL Rule is in place, the ping from LAN to IoT is allowed to be sent - and IoT receives it.  However, once it is received by IoT, the 'Deny' IoT to LAN ACL Rule prevents an acknowledgment response via ICMP back to LAN, and the ping eventually times out.  Removing ICMP from the 'Deny' Rule, allows the ping acknowledgment to be sent back to LAN.  Doing that, however (as you stated) weakens your LAN-to-LAN security.  If due to different types of traffic and different ports that are used, other adjustments are needed, the cross-LAN security will be further weakened. 

Digging a little more, I found a Reddit thread with the title, "TP-Link Omada - Switch ACLs aren't stateful".  The short version is that Omada Switch ACLs are not stateful and therefore can't - at least currently, do what we want in this case.  Additionally, it's important to note that most Switch ACLs are also not stateful.  That duty is usually handled by firewalls.  From Wikipedia: A stateful firewall is a kind of firewall that keeps track and monitors the state of active network connections while analyzing incoming traffic and looking for potential traffic and data risks. This firewall is situated at Layers 3 and 4 of the Open Systems Interconnection (OSI) model.

So, it appears that (I'd be more than happy to be wrong) the current capabilities of Omada's Switch ACL Rules cannot handle this task.

Am I interpreting all of this incorrectly? and if I'm right, will TP-Link upgrade their Switches and ACL Rule capabilities?

  @lflorack pretty much spot on.  I tried to even put in an ACL just for the heck of it to allow all from LAN to IoT just to see if that might help. Didnt make a difference.  So we are kinda in limbo when it comes to security.  I guess if we want to check the IoT VLAN, we need to connect into it and check it from there.   But on a somewhat good note...we know that everybody can talk to each other in their respective LANS but not inter VLAN unless we pinhole things by unchecking protocols and such...

lflorack wrote

Your point about allowing the ICMP protocol to get through made me think about this a bit more.  Here's what I think is happening. 

Since the 'Allow' LAN to IoT ACL Rule is in place, the ping from LAN to IoT is allowed to be sent - and IoT receives it.  However, once it is received by IoT, the 'Deny' IoT to LAN ACL Rule prevents an acknowledgment response via ICMP back to LAN, and the ping eventually times out.  Removing ICMP from the 'Deny' Rule, allows the ping acknowledgment to be sent back to LAN.  Doing that, however (as you stated) weakens your LAN-to-LAN security.  If due to different types of traffic and different ports that are used, other adjustments are needed, the cross-LAN security will be further weakened. 

Digging a little more, I found a Reddit thread with the title, "TP-Link Omada - Switch ACLs aren't stateful".  The short version is that Omada Switch ACLs are not stateful and therefore can't - at least currently, do what we want in this case.  Additionally, it's important to note that most Switch ACLs are also not stateful.  That duty is usually handled by firewalls.  From Wikipedia: A stateful firewall is a kind of firewall that keeps track and monitors the state of active network connections while analyzing incoming traffic and looking for potential traffic and data risks. This firewall is situated at Layers 3 and 4 of the Open Systems Interconnection (OSI) model.

So, it appears that (I'd be more than happy to be wrong) the current capabilities of Omada's Switch ACL Rules cannot handle this task.

Am I interpreting all of this incorrectly? and if I'm right, will TP-Link upgrade their Switches and ACL Rule capabilities?

  @lflorack actually...I take back what I said.....I read the reddit article and if you put them in the correct order in the ACL list, it works.  Put the ALLOW LAN TO IOT before the DENY IOT TO LAN and that should do the trick.  I wasnt aware that the order of the ACL was that important.  I am testing now and it appears to be working

lflorack wrote

Fleegle61 wrote

@lflorack actually...I take back what I said.....I read the reddit article and if you put them in the correct order in the ACL list, it works.  Put the ALLOW LAN TO IOT before the DENY IOT TO LAN and that should do the trick.  I wasnt aware that the order of the ACL was that important.  I am testing now and it appears to be working

 

  @Fleegle61 

The order of your ACL rules is definitely important, but I already had mine in the proper order:

 

1. Permit LAN > IoT
2. Deny IoT > LAN

 

....and it still doesn't work.  I just confirmed the order of my ACL rules and the settings in the rules themselves and then test pinged them again.  For the reasons I explained earlier, they still don't work for me.  Unless I remove ICMP from the DENY rule (#2 above) before test pinging, I guess I don't see how it can.  Without a stateful capability in our Omda hardware, It isn't likely to work.  Are you sure its working for you?

  @lflorack I also tried to no avail.  I thought i had it but nope!  But I did find it interesting that I could ping by guest wifi. Of course thats because there is no ACL for that, but the SSID is set for guest and that VLAN cant do anything other than internet.  Well it was worth trying and a good conversation.  I know a little more than I did this morning