NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
Solved
Create simple IPv4 based ACL
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 sh...
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.
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 :)!
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)
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?
Ok, I think I at least found the reason why 192.168.114.2 (protected host) couldn't connect to the outside world anymore - although the ACL was not applied to its port. As those rules are applied to all incoming traffic on the selected ports, that also means, that the response to the NTP request of 192.168.114.2 will not be forwarded from the router to 192.168.114.2 :). So that makes sense. What's left is, why that raspberry pi-hole on port 48 can still reach the 192.168.114.2 although the port has also the ACL set.
NETGEAR Academy
Boost your skills with the Netgear Academy - Get trained, certified and stay ahead with the latest Netgear technology!
Join Us!
