@plavielle, the ACL blocks TCP/IP traffic, but DHCP uses BOOTP-like broadcasts using the broadcast address 255.255.255.255 or the subnet broadcast address 10.64.131.255 as the destination IP. The client cannot send any IP packet before it got assigned an IP address. Thus, traffic can't be blocked by an ACL as long as the device has no IP yet and UDP to the broadcast address passes anyway. That's why your client gets offered an IP address.

Routing to the Internet get's not blocked by this ACL either, since the final destination IP of outbound traffic isn't part of your LAN, so the ACL doesn't apply at all.

I'm not sure what you mean with the other two questions (»can't go out«, »internal/external communication«), maybe you can give more details what's the exact way you try to »go out«: with the PC? With OC200? With the laptop wirelessly? Over a OC200 portal? etc. (my network crystal ball is currently in maintenance).

plavielle wrote

There is more information here.

 - in config rule A i cannot ping my lan , but i can go to internet (?????????? how the packet can go to my firewall that was in the lan blocked)

As I wrote already: If you access the Internet, you are addressing an IP outside your LAN. For example, if you surf www.google.com, your laptop addresses the IP assigned to www.google.com, not any IP inside your LAN. Google's IP is not blocked by the ACL.

The packet also does not go to the firewall, but rather it goes through the firewall to a final destination.

These are not only different words, but completely different things:
 

• If an IP packet goes to your firewall, its destination address is 10.64.131.209. This IP address is blocked by the ACL. You can't ping the firewall, you can't connect to it.
   
• If a packet goes through your firewall, its destination address is any IP address not known directly to your laptop (outside the 10.64.128.0/22 network). Your laptop now forwards the packet to the default gateway – which is your firewall – using the default gateway's MAC address for transport of the IP packet, but still with the final destination IP address in the IP packet, which is the address of the host you want to reach.
  
  The firewall in turn forwards the IP packet in exactly the same way, but now to its own default gateway, which for an unknown destination is the WAN gateway located at your ISP.
  
  This whole process is called »routing«.

If you would want to block forwarding operations of your firewall (or laptop), you can do so only on your firewall (or laptop), but not with an OC200 ACL. Thus, to forbid access to www.google.com using an ACL in OC200 you would have to block all IP addresses of Google in an ACL.

- in config rule B i can communicate with my lan but not with internet

If you can't reach the Internet, it's definitely a routing problem – see answer to the first question above.

Thus, check the IP address, the default gateway and the DNS server settings on the PC and any FORWARDING rules on the firewall. Also double check network masks, maybe there is a wrong one on the PC.

If you still cannot get it to work, please post the IP address, default gateway address, DNS settings etc. of the PC.

OC200 ACLs do not block routing, so the OC200 settings are unrelated to your routing problem.

plavielle wrote

For config A i understand what you mean, but it's a strange behaviour. For me, since i'm in IT, when you block some range, it block all (tcp, udp). Here we have a different behaviour. That's it.

No, it's not strange behavior. It's like an IP ACL is supposed to work and this is standard behavior amongst all routers, switch ACLs and firewalls:

The IP addresses are always global and specify the end points, that's host1 and host2 in the above diagram. This is what you can block with an IP ACL in OC200.
 

The MAC addresses are always local, that's host1 and routers A, B and C's MAC address in the diagram. You cannot block Ethernet frames to routerA with an IP ACL in OC200.
 

Therefore, if you block the IP address of routerA, IP packets addressed to host2 will still reach routerA and will be forwarded unless host2's IP address is blocked, too.

The difference to a firewall is: What you can block with a firewall is any traffic, no matter which destination IP address it has (in fact, you use IP 0.0.0.0/0 then, a wildcard). But if you block only specific IPs in a firewall, this rule will exactly behave as an IP ACL in OC200 does. It will still allow routing even if traffic to the router's IP is blocked.

To block forwarding in a firewall, you use such a rule in the FORWARD ruleset (here for example, with netfilter/iptables):

Chain FORWARD (policy DROP 0 packets, 0 bytes)
 pkts bytes target  prot opt in     out     source               destination         
8418K 3696M REJECT  all  --  *      *       0.0.0.0/0            0.0.0.0/0           
 

In config B impossible to go out and all ip config where ok. on my laptop, if i connect ethernet cable it works (same dhcp lan or wifi), if i connect on wifi, i get dhcp address, i can ping all i want (dhcp server, firewall) in the lan, but impossible to go out.

 

Yes, you're right, I did a test. It seems to me that OC200 behaves much like a switch: if you define an ALLOW action in an ACL, it drops traffic not covered by this ACL by default. The way switches do this (and obviously OC200, too) is by adding an invisible default action to the ACL (a policy).

Thus, foreign destination IPs are blocked by default, that's correct.

In my opinion, ALLOW ACLs would make much sense only if one could define rulesets (chains) of BLOCK/ALLOW ACLs as it can be done in switches. But chaining ACLs is not possible in OC200 AFAIK. You can only assign one ACL to a SSID and define one rule in an ACL.

So, in my understanding ALLOW ACLs are only useful if you want to restrict traffic to certain subnets, but disallow anything ese (except what's defined as »Excluded subnets« in the same ACL).

Now the question is: why would you want to use an ALLOW ACL when setting no ACL at all allows internal communication anyway? What is your goal in doing so?

You are complaining that using BLOCK ACL blocking access to private network IPs still allows outbound traffic to destinations outside your LAN. If you want to block outbound traffic using ACLs, why not just use an ALLOW action?

Next you are complaining that an ALLOW ACL allowing access to private network IPs does block outbound traffic to destinations outside your LAN. If you want to allow outbound traffic as well as internal communication in your LAN, why not just define no ACL at all?

I still don't understand what you want to achieve with those ACLs shown in your example.

@plavielle, you're welcome.

No need to apologize, I also learned something new about OC200 ALLOW ACLs and I'm 40 years in IT now, but still learn each day from questions like yours. 

Maybe we should suggest to TP-Link that they change the last sentence in the Omada Controller User's Guide from:

to:

Allow: Select this mode to allow clients to only access the specific subnets.

That would avoid much confusion. Of course, a note in the ACL section that no ACLs can be selected using NONE would make sense, too.

@forrest, please can you suggest this change to the Omada Controller User's Guide documentation team? Thanks!