LTLnetworker | IT hálózatok, biztonság, Cisco

               IT networks, security, Cisco

Keeping firewall policies consistent on Juniper SRX firewalls with Junos Space

Posted by ltlnetworker on January 12, 2014

A distributed firewall system requires a means to keep the firewall rules and other security policies consistent across similar-role firewalls. Traffic may choose alternative paths if multiple telco lines or data centers are used. We have been testing some Juniper SRX’s in this scenario. The Juniper management software you need for such tasks is Security Director that is an add-on application to Junos Space Management Platform.

We set up a multiple-LSYS multiple-zone network with virtualized EX switches that fits the customer network architecture. The logical systems had synchronized firewall config by pair. (The pairs interconnect the same zones but in separate locations. Routing decides which path is taken.) The members of a pair are standalone, they do not form an SRX cluster because of Layer3 separation. We plan a cluster for each member later (a total of two clusters or 2×2 LSYS’s).

We managed to test the following functions relatively easily and we got convincing results:

  • resource allocation for individual LSYS’s
  • preview CLI config changes before deployment
  • hierarchical policy structure with group policies (i. e. policy with multiple firewalls assigned)
  • consistent group policy across multiple firewalls or LSYS’s
  • detection of manual config changes
  • restoring consistency from Security Director

Let’s see some screenshots and experiences then even a Q&A section is provided in the end. (-:
The list of managed devices in Network Management Platform shows basic properties. A logical system is handled as an independent device but managed via the physical device’s management IP address.


A similar list in Security Director shows the managed policy states of each firewall:


You can build the firewall policy by adding rules and objects. New objects may be created on the GUI. The source and destination zones must already be defined on at least one assigned firewall, the dropdown list contains only the zone names read from the devices. (If you start to manage a firewall that already has some policies and objects, those can also be imported into Security Director.)

To edit a policy the lock icon must be clicked and it becomes locked (i. e. editable for you and locked for everyone else):

The Publish Policy page offers the policies you can publish:

Then it shows the affected devices. ‘Services’ are the policies that will be deployed to the affected device.

You can preview the CLI configuration changes:

If you click Publish and Update, a job is created then the job state can be viewed. Junos Space deploys the CLI commands on the firewalls.


SRX-B had been removed so the policy could only be published on the other firewalls. SRX-A and sw-srx100-1 has a newer policy version v4 now:

You can also add a global policy where zones need not be chosen:

We may have zones of similar role in multiple firewalls that need identical firewall rules but the zone names vary. A polymorphic zone may be created in Object Builder > Variables. It is an abstract zone name that translates to a different zone name in each firewall. The polymorphic zone name can be used in Junos Space Security Director and it generates CLI config with the actual zone names for each affected device. In this example I am using the polymorphic zones Vleaf and Vfusion that I set to translate to jGuest and jCore on LSYS-jGuest-A but might as well translate to jTech and jCore on another device.

I noticed some difficulties and limitations that I discussed with an expert at Juniper:

Q: I’m not able to add zones to a policy that are not yet present on at least one assigned firewall

A: Right, because Space doesn’t know list of available zones until you assign firewall having some zones. It would have to list all zones in all available policies which would be inconvinient in high scale enviroments.

Q: The zones need to be manually created before creating the rules in the policy. I’d prefer creating the rules with respective zone names then publishing the policy including automatic zone creation

A: Creation of zones in SD is planned for 13.2 (summer 2014). You can do it today either from CLI or Space Platform element management.

Q: Nested group policies (more levels of hierarchy) would be useful to create more general and more specific device groups and policies

A: You can have device as member of multiple groups. Then you are using priority to adjust what’s being evaluated first.

Q: I still don’t understand the difference between Publish and Update action. The deployment was not complete without Update. What is the point of Publish if the config is not pushed to devices?

A: For example you want to prepare everything during afternoon and deploy during night. Or someone has privileges to edit and publish. The 2nd person has only read privileges but she can update.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: