You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We're working with the Firewall & Security Models plugin and found an interesting gap in the model. It looks like the 'zones' object supports linking to a VRF to help provide IP layer information relevant to a zone. However, what happens when the zone is not actually a VRF, but just a network/subnet/vlan? For the time being we created a custom json field called "prefixes" that looks like:
{"exclusions": [],"prefix": "172.17.0.0/16"}
which allows us to clearly identify the subnets associated with each zone, but I thought it was odd that the "zone" abstraction only seems to support a VRF. The motivation being that rules defined between zones should only ever contain IPs that are within the subnet definitions of those zones, otherwise it's a silly rule to create.
I'm guessing that most people using this plugin are, at the very least, to manage firewall policies at their Internet border. However,
even if we were to create "fake" VRF with a prefix of 0.0.0.0/0 it would not properly identify the zone since 0.0.0.0/0 contains all IPs including those internal to the network. That's how we landed on the above custom field, however, I wanted to try to start a discussion around this issue to see if there is something better we can do or something better the model could do to more completely accommodate real world use cases.
We're working with the Firewall & Security Models plugin and found an interesting gap in the model. It looks like the 'zones' object supports linking to a VRF to help provide IP layer information relevant to a zone. However, what happens when the zone is not actually a VRF, but just a network/subnet/vlan? For the time being we created a custom json field called "prefixes" that looks like:
which allows us to clearly identify the subnets associated with each zone, but I thought it was odd that the "zone" abstraction only seems to support a VRF. The motivation being that rules defined between zones should only ever contain IPs that are within the subnet definitions of those zones, otherwise it's a silly rule to create.
I'm guessing that most people using this plugin are, at the very least, to manage firewall policies at their Internet border. However,
even if we were to create "fake" VRF with a prefix of 0.0.0.0/0 it would not properly identify the zone since 0.0.0.0/0 contains all IPs including those internal to the network. That's how we landed on the above custom field, however, I wanted to try to start a discussion around this issue to see if there is something better we can do or something better the model could do to more completely accommodate real world use cases.
Additional examples of our fields for discussion:
Internet:
Non-VRF zone:
Paired with the more general network:
The text was updated successfully, but these errors were encountered: