Spent all day trying to figure out why some of my packet filtering rules weren’t working. I’ve got two SG560 units VPN’d together via an IPSec tunnel. One has version 3.1.6 firmware and the othr has version 3.2.2
It appears that between these two version they handle the “Access Control” feature differently. With 3.1.6 when you enable the “Access Control” for “Internet”:

and don’t even choose to block or enable anyone in the ACL

ACL List
then it changes the way packets are generated. It suppresses the triggering of the Packet Filter rule for port 80 and delegates control over that to the authd or Access Control feature. That is for firmware version 3.2.2. For version 3.1.6 the Packet Filter rule is still triggered.
Images below with descriptions:
Version 3.2.2
So I remembered it wrong. The source address does not change, but the packet filter rule based on “Type: Forward” is not triggered. Rather the “authd” is triggered (I think this is a different service or daemon from ipchain). I just spent some time googling it and here is a description for Authd

Here the Packet Filter rule is enabled for Type: Forward and port 80, but it is not triggered.

Here the ACL within the Access Control is set to block port 80 and authd is triggered.
In this case (to the left) the “All Forward Block” is being triggered for a ping request which uses ICMP and thus the rule is triggered. But the other rule that is active for blocking Type: forward for port 80 is not triggered. It is suppressed somehow and authd is put in its’ place.
Version 3.1.6
Okay, so after exhaustive testing I have concluded that there is no difference between the firmwares. But when I first went through this exercise last week (didn’t have time to document last week when I first went through my testing) I could have sworn that each firmware was handling he packets differently. But now every test I do shows that they handle it the same.
Bottom line:
You must have Access Control disabled in order for the Packet Filter rules for the Type: Forward to be triggered. At least for outbound traffic going out from the internal network. I haven’t and am not planning on testing for packets forwarded from the outside in using port forwarding.
If you have Access Control enabled you can then use the ACL to determine which hosts will be blocked or allowed which will use the “authd” protocol, application, whatever you want to call it, to perform the blocking.
Whew… I’m done.
So, I decided to downgrade back to the latest version of the Secure Computing version of the firmware before they were bought out by McAfee and the firmware was rebranded. I found that you can do that by including the “-i” option in “Extra Parameters” as shown to the left.
I couldn’t get the capture for the actual problem I had. It said something about there being more than one interface on my PC and asking if the one referenced by the IP address it showed was the right one. It was the Hamachi adapter. I choose no but then it would not work. I think it’s supposed to choose the other available adapter when you choose no, but if that’s what is supposed to happen, it didn’t. I was able to get it to work by disabling the hamachi adapter in network neighborhood.

So I checked the “Update DNS with local DHCP leases” I was reluctant to do this before because I was afraid that it would register the names with my ISP’s DNS server and somehow other users on the node would be able to get to my devices on my local network. Even if it does register they shouldn’t be able to get to them because that traffic would be dropped by the firewall settings on the SG560.
It shows as non-authoritative, but it does work. Before I was unable to ping to my laptop when it was connected wirelessly to the network. I could ping out from the laptop via the wireless connection but could not ping to the laptop. When connected with an ethernet cable then I could ping to it. I couldn’t figure this out. Still can’t. After rebuilding the SG560 it started working. Based on