- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
Enhanced Security Measures in Place: To ensure a safer experience, we’ve implemented additional, temporary security measures for all users.
09-20-2023 02:46 AM
Hello, firstly, apologies for the long winded background info to explain my requirements !!
I've a large project with hundreds of Firewalls to deploy. All initial base-configuration and Panorama-integration will be completed via the use of various specific templates, template-stacks and parent/child/grand-child device groups, achieved via auto-generated CLI commands based on minor manual device/location/IP specific inputs from each local site network-team (generates relevant set deviceconfig / request / set template / set template-stack commands).
The device-groups are structured in such as way as to apply common/default rules worldwide + avoid duplicated rules (site-A to site-B, no need to update many firewalls in the path, only update the destination specific firewall):
All good so far.
Here's the tricky part. Firewalls are inserted into highly critical areas of a 24/7 network, where maintenance windows are totally out of the question. Firewalls are in vWire mode with all inter-vlan L2/IP-L3 traffic flowing through the Firewalls.
As part of the migration process therefore, initially all Firewalls need a set of 'migration-temp' allow rules to pass all traffic + permit log analysis (Expedition used for this purpose) for the creation of the final local-site/network specific policies.
The 'migration-temp' rules are the same worldwide, however migrations will take place site-by-site, region-by-region, and only once specific policies are in place on a set of Firewalls should the 'migration-temp' rules be disabled = cannot use a common Parent/Child device-group for these 'migration-temp' rules (disable at the DG = disable for all DG members).
I'm looking to automate adding these 'migration-temp' rules as part of the initial semi-automated Firewall deployment phase. Since these need to be added to each separate Firewall cluster, and not to a common device-group, the only method I can think of is as follows:
Unless someone has a better and more elegant way to do this ? (I cannot see any possibility via a template setup, though that would be ideal, as I could then add the 'migration-temp' template to each site's template-stack and include this all within one procedure).
To those who read to the end, thank you so much !!
09-20-2023 05:56 AM
i don't know how 'leafy' your device group tree is, but have you considered adding a duplicate (grandparent) branch?
branchA is premigration with the temp rules at the grandparent level, so all rules are already there + temp rules at the very top just below 'shared'
branchB is the final branch without temp rules
all devices start in branchA, once they're in production just move them to branchB and the temp rules go away
just trying to think of the dumbest most easiest way to do this
if this does not apply to your case, let us know so we can put our thinking caps on (instead of my dunce hat)
09-20-2023 05:56 AM
i don't know how 'leafy' your device group tree is, but have you considered adding a duplicate (grandparent) branch?
branchA is premigration with the temp rules at the grandparent level, so all rules are already there + temp rules at the very top just below 'shared'
branchB is the final branch without temp rules
all devices start in branchA, once they're in production just move them to branchB and the temp rules go away
just trying to think of the dumbest most easiest way to do this
if this does not apply to your case, let us know so we can put our thinking caps on (instead of my dunce hat)
09-20-2023 07:40 AM
Hi Tom, indeed your suggestion is a perfectly valid solution, however not so practical/scalable in our particular case. The project is global with multiple, independent 3rd party providers in various global regions, working independently of each other on whichever sets of firewalls/sites are under their deliverable contract.
Due to high complexity of applications (many non-standard manufacturing, highly specialized) and the absolute non-negotiable interruption to manufacturing, the rule implementations are implemented in several waves/iterations, each more and more detailed to ensure no critical flows are missed (sessions with multi-month active/idle duration, tcp-non-syn sessions, session drop = major financial impacts, a real horror show!).
Therefore, each firewall-cluster must have local to itself, the full set of allow 'migration-temp' rules. They are indeed identical on all firewalls no matter the region/site/network.
The only dumb idea I have so far, is to have that 'migration-temp' policy on a linux server and wait for the firewall to be integrated to Panorama before importing the policy, but then this a 2-step process + adds complexity of having a server to host the policy, over which I have no control.
The ideal solution would be to implement the 'migration-temp' policy as part of my automated procedure in a template (technically doesn't seem possible), maybe I'll just have to simply add these rules CLI style to the various device groups:
set device-group <name> post-rulebase security rules <name> from [ <from1> <from2>... ]
set device-group <name> post-rulebase security rules <name> to [ <to1> <to2>... ]
set device-group <name> post-rulebase security rules <name> source [ <source1> <source2>... ]
set device-group <name> post-rulebase security rules <name> destination [ <destination1> <destination2>... ]
set device-group <name> post-rulebase security rules <name> service [ <service1> <service2>... ]
set device-group <name> post-rulebase security rules <name> application [ <application1> <application2>... ]
Click Accept as Solution to acknowledge that the answer to your question has been provided.
The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!
These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!
The LIVEcommunity thanks you for your participation!