Firewall integration to Panorama with initial/default device Post-Rules

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements
Please sign in to see details of an important advisory in our Customer Advisories area.

Firewall integration to Panorama with initial/default device Post-Rules

L1 Bithead

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):

  • Parent DG = worldwide-access, pre-rules + default-matrix, post-rules.
    • Child DG = local-site-generic (avoid local-site rule duplication), post-rules.
      • Grand-child DG = local-networks-specific, strictest policy, post-rules.

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:

  • save a standard 'migration-temp'.config.xml on a linux server.
  • once the firewall is integrated into Panorama, import the 'migration-temp' rules: scp import configuration from name@host:path/migration-temp.config.xml

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 !! 

3 REPLIES 3

Cyber Elite
Cyber Elite

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)

 

Tom Piens
PANgurus - Strata specialist; config reviews, policy optimization

Cyber Elite
Cyber Elite

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)

 

Tom Piens
PANgurus - Strata specialist; config reviews, policy optimization

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>... ]

  • 633 Views
  • 3 replies
  • 0 Likes
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

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!