Possible bug with 5.15 adapted firmwares? not sure, certainly strange!
So, i have tested and confirmed this on both 7206 v2 and 8411 with the new firmwares, testing the !ip_group function in gateway ACLs
Scenario
I have an IT vpn, and some remote site vlans that i want to control access to.
For the remote sites, i can easily create a new simple rule with the new "not"ip_group functionality
scenario, isolating the remote and main sites office vlans from all others, but letting them communicate
IPgroup 1:
[vlan 1, vlan 2, vlan 3]
rule
ip_group1 > !ipgroup1
This allows all these vlans to communicate, but not with anything else on main or remote sites. great. nice and simple and much cleaner than the old way. success
Now, lets replicate this for technical vlans
IPgroup 2:
[vlan 4, vlan 5, vlan 6]
rule
ip_group2 > !ipgroup2
This allows the technical vlans to communicate beteen themselves, but nothing else either on main or remote sites. nice and simple. success
Now, i want to include my IT VPN in both groups. Logically, this should work since the same IP range will be in both groups, and therefore not excluding itself from the ! rules. IT VPN should be able to reach all vlans everywhere.
IPgroup 1:
[vlan 1, vlan 2, vlan 3, it_vpn_pool]
rule
ip_group1 > !ipgroup1
IPgroup 2:
[vlan 4, vlan 5, vlan 6, it_vpn_pool]
rule
ip_group2 > !ipgroup2
Result: IT vpn has no access to anything
And now for the weird part......
If i keep the ip_groups as they are, but REVERSE the rules so its !ip_group > ipgroup..... all the restrictions still work, and IT has access to everything
Why is this? !ip_group>ipgroup is functionally the same as ip_group>!ipgroup since the same things are still being blocked, just in the other direction. Even considering gateway ACLs are stateful, the reverse direction surely shouldnt actually work at all since in !group>group its the destination tahts actually initiating the request so would be naturally blocked regardless of the the rule entirely. very odd!
Can anyone elighten me? because even ChatGPT is stumped on this!
OK
ACLs working in the !group > Group direction
The Groups - my IT VPN ranges highlights in each one, the other ranges in each group are unique
When the ACLS are configured in the group > !group direction, the IT VPN ranges (highlighted above) have no access to anything at all, but the rest of the restrictions for the other ranges still work as expected.
What i dont quite understand about this, is that with the ACLs working in the !group > group direction, requests from my IT VPNs are essentially in the "destination" side, so im not sure how the stateful gareway rules detect this is still OK and pass the traffic.
Hopefully this makes it clear what i was trying to do - use the new !group feature to avoind having to make lots more IP groups and having to set more rules to restrict each main and remote site network. What i have now works (and really well), i just dont understand why the tradational group>!group completely kills the IT ranges since they are included in each group and should not therefore be explicitly restricted