If enablers are going to completely replace layer 3 firewall rules, then they need to be inuitive. Every admin that is used to an interface based firewall, will be very disoriented by the policy based enablers, especially as they relate to inter-lan communication. Enablers to reach something on the WAN can oftentimes be turned on for every policy, but for access to something on another LAN segment, it can get complicated. The enablers need to be on their own separate page, and all the policies need to be laid out like “interfaces” in pfsense are, so we can apply certain rules to certain policies all from one page. Im thinking of a matrix layout. It is also very tough to audit access to other networks if we have to go into every policy and check which enablers are on for that policy.
I frequently jump my devices from policy to policy. If a network is joined with a random mac, then the device is placed into a default policy, where we dont want everyone to access a certain thing, but the admin sure needs to. Maybe we need device lists, and then apply enablers to devices, regardless of which policy they are on.
Also, as has been said before, the enablers need source filtering.
There should also be support for the enabler rule to show up in the traffic log if it is matched.
It would also be nice if the enablers would show tooltips with their entire info, when they are hovered over.
Anyone that has any more suggestions about enablers can add to this list.
Enablers are not designed as a replacement for firewall rules. Enablers are designed for fixing issues with services that do not work with DTTS. This is directly connected to content blocking, which is why it is part of a policy.
Configuring access to other LANs would best be accomplished by using firewall rules.
You could create a dashboard enabler with RFC1918 that just get turned on for policies than need inter LAN communication. (This could be an official one)
The Dashboard knows the LAN subnets so it would be possible for it to automatically create enablers for them instead of doing a RFC1918 which is IPv4 only.
For now it’s fairly easy to create enablers for your VLANs that can be assigned to policies as desired.
Changing to an S only changes source port, something you almost never want to do.
Going from VLAN to VLAN doesnt change my policy, I am purposely jumping from policy to policy to audit connectivity on that policy. So UBA wont help in this case.
An RFC 1918 enabler is way to open for most things, it short circuits the purpose of having VLANs. InterVLAN communication should be on an as needed basis. Per interface default policies will help a lot when they are eventually implemented.