I'm trying to setup a really simple IPv4 ACL on my switch to only allow access to a specific host A from another host B and denying everything else.For this I used the ACL wizard, and setup like shown in the attached image. So I want to allow host 192.168.114.2 (host a) to access everything on port g52 (host b). So I interpret this UI like, "if an inbound request comes to port 52, check this ACL". Not sure if that assumption is correct. I already read, that there will be a implicit default deny all rule and that the netmask is actually a wildcard netmask which is basically an inverted netmask. Not sure if 0.0.0.0 is correct (I also tried 0.0.0.255).With this setup though, no hosts in the network has access to host b anymore - including host a. It seems I'm missing something here. Any advice is appreciated.

Closing this in favor to https://community.netgear.com/t5/Managed-Switches/ACLs-are-not-blocking-as-expected/m-p/2157679/highlight/true#M11684 which should simplify things.

Create simple IPv4 based ACL | NETGEAR Communities

5 Replies

Replies have been turned off for this discussion

vguna
Guide
Oct 18, 2021
Ok, I'm a bit further now. It seems that "inbound" does not mean for the selected port. But more like inbound to the whole switch in general. From this point of view I created an IPv4 deny destination rule for the to be protected host (192.168.114.2) and assigned this ACL to all ports - except the ones that should have still access. Also I added a permit all rule, since otherwise all "other" traffic will be dropped as well.

This seems to work now - except (at least) one raspberry that can still ping that host - although the ACL for that port is properly set. Here I'm stuck, why this guy can still access, but two other hosts can't (as expected). I also switched that host to another port - it can still ping the host. Attached some details about the current setup - maybe someone can shed some light on this, thanks :)!
- vguna
  Guide
  Oct 19, 2021
  Now it get's even more interesting. After fiddling a bit more yesterday, I tried to simply block all traffic with an additional ACL which is only bound to that specific port where the raspberry is connected (a pihole) which for whatever reason can still reach the protected host. I also made this the first ACL in terms of order. Then I was able to block it completely. Then I adapted the ACL to not block all, but only ICMP to the protected host. That worked for ping, but was still able to connect via HTTP to the protected host (expected). Then I switched from ICMP to IP and voila: it could not reach the protected host at all.
  
  And now comes the fun part :).
  
  Then I removed the just created ACL again - so that only the initial ACL was left - and now it blocks properly also the raspberry :). Now I'm completely lost why only adding a new ACL and removing it again made the old ACL now work for the (for whatever reason) exceptional host.
  
  Of course now I'm insecure if that happened to other ports as well. Why was the issue only with the specific host? Maybe someone could give some insights/ideas here.
  
  (I just read my post #1 again, which is wrong. I meant I want to allow access to port 52 (192.168.114.2) from 192.168.114.21 only. But this was a wrong interpretation as mentioned in post #2)
  - vguna
    Guide
    Oct 22, 2021
    Today I noticed, that the protected host 192.168.114.2 (port 18) wasn't able to connect to the outside anymore (to a ntp pool server) since I applied the rules. Is this expected behavior to the configuration shown earlier? I thought, if NO ACL is bound to a port, it isn't applied to it at all and there is no restriction (?).
    
    Anyway. To proof it's the ACL, I edited the IP Extended Rule by clicking on the sequence number and changing the host to 192.168.114.253 (does not exist) and applied. After that, 192.168.114.2 could connect again. Sweet. So I changed the host back to 192.168.114.2. And guess what? Now all hosts can access 192.168.114.2 again - although everything is in place like before. Any idea what is going on?