Juniper SRX Tips :: Altering Default-Deny Behavior

In our previous article, we looked at using apply-groups to alter all the security policies uniformly on an SRX device such that they would all have an implicit logging statement. And while this is fine for all existing policies, it doesn’t log traffic which doesn’t match any explicitly defined security policy.

The reason for this is due to the fact that in Junos, traffic which doesn’t match an explicitly defined security policy matches against the default-deny policy.  However, given the fact that the default-deny policy is implicitly defined, apply-group configurations are of little benefit as apply-groups can only be inherited by those elements which have been explicitly defined.

Often in these cases, administrators will simply choose to create their own deny policies with the desired options and place this deny policy as the last policy for traffic going from one zone to another. However, in instances where there are many zones, it might prove too cumbersome and time consuming to manually configure this to accommodate all zones.

Clearly it would be more beneficial to have something akin to the Global Zone in ScreenOS which can be used to match on all traffic which doesn’t match against any of the explicitly defined security policies.  However, at the time of this writing, Global Zone functionality doesn’t exist in Junos.

The good news is that we can use the power of apply-groups once again to our benefit, this time to create an explicitly defined deny policy which will be inherited at the tail-end of all security policies defined within our configuration. Note that this will encompass both Inter-zone as well as Intra-zone traffic.

For this example, let’s assume that we want to log everything that would normally hit the default-deny policy. Let’s start by taking a look at our baseline configuration:

Here you can see we have a policy allowing all traffic outbound from the Users-subnet in the Trust zone towards the Untrust zone, and another policy allowing inbound HTTP traffic from the Untrust zone towards the Web Server in the Trust zone.  Now, in order to change the default-deny behavior and add additional options, we will use an apply-group to inherit a new policy at the tail-end of all previously defined policies, as follows:

Finally, let’s apply our apply-group at the [security policies] stanza within our configuration:

Now that we’ve completed the configuration, let’s examine the results of the application of our apply-group by taking a look at our security policies, this time by displaying the inherited configuration:

Once again, with just a couple of lines of code we can streamline the configuration to a large extent, in this case creating an explicitly defined deny policy which logs all traffic that would otherwise be silently discarded.  And best of all, we can do so without having to resort to manual configuration of each and every one.

In small installations this technique might be of little benefit, but in larger implementations consisting of dozens of zones with a combination of Interzone and Intrazone and bidirectional security policies, the benefit of such an approach cannot be understated.  Not only will this ease configuration burden, but it will ensure that all traffic which doesn’t match any of the existing security policies will be handled in a consistent manner.  Of course, as with previous examples, if there are certain policies that we don’t want to inherit this new default-deny, we can simply utilize the apply-group-except statement for each of those respective policies.

In our next article we will examine changing the built-in Junos application defaults so that we can customize timers and other parameters.

Juniper SRX Tips :: Uniform Security Policy Modification

Often there are instances where we want to affect all security policies configured on an SRX device.  For example, let’s say that we have thousands of policies configured on our firewall, and we want to enable logging for every single policy.  Obviously this would take some time if we were to do this manually on each and every individual policy, so an easier way is desired.

Continue reading “Juniper SRX Tips :: Uniform Security Policy Modification”

JNCIE Tips from the Field :: Summarization Made Easy

Today we’ll start with a series of articles covering tips and techniques that might be utilized by JNCIE candidates, whether pursuing the JNCIE-SP, JNCIE-ENT, or even the JNCIE-SEC.  The tips and techniques I will be covering might prove to be useful during a lab attempt but could also be used in real-world scenarios to save time and minimize configuration burden in addition to eliminating mistakes that might otherwise be made.  I want everyone to understand that what I am about to write is simply a technique.  I am not divulging any materials or topics which are covered under NDA.

Continue reading “JNCIE Tips from the Field :: Summarization Made Easy”

Day One Guide: Junos Tips, Techniques, and Templates 2011

small-junos-tips-2011I am happy to announce that Juniper has just released a new Day One Guide entitled “Junos Tips, Techniques, and Templates 2011“. For this particular Day One Guide, Juniper Networks Books and J-Net joined forces and requested the best and brightest Junos tips and techniques from the Junos user community.  In fact, the book was created after a thorough selection process which included reviewing over 300 submitted tips by over 100 individuals on the J-Net community boards at

Continue reading “Day One Guide: Junos Tips, Techniques, and Templates 2011”

IETF Provides New Guidance on IPv6 End-Site Addressing

I’ve always been at odds with the recommendation in RFC 3177 towards allocating /48 IPv6 prefixes to end-sites.  To me this seemed rather short-sighted, akin to saying that 640K of memory should be enough for anybody.  It’s essentially equivalent to giving out /12s in the IPv4 world which in this day and age might seem completely ridiculous, but let us not forget that in the early days of IPv4 it wasn’t uncommon to get a /16 or even a /8 in some cases.

Granted, I know there are quite a few more usable bits in IPv6 than there are in IPv4, but allocating huge swaths of address space simply because it’s there and we haven’t thought of all the myriad ways it could be used in the future just seems outright wasteful.

So you can imagine my surprise and also my elation last week when the IETF published RFC 6177 entitled ‘IPv6 Address Assignment to End Sites‘.  In it, the general recommendation of allocating /48s to end-sites that has long been the defacto standard since the original publication of RFC 3177 in 2001 has finally been reversed.

It seems that sanity has finally prevailed and the IAB/IESG have decided to take a more pragmatic approach towards address allocation in IPv6.  The recommendations in RFC 6177 attempt to balance the conservation of IPv6 addresses while at the same time continuing to make it easy for IPv6 adopters to get the address space that they require without requiring complex renumbering and dealing with other scaling inefficiencies in the long term.  It is clear that acting too conservatively and allocating very small address spaces could act as a disincentive and possibly stifle widespread adoption of IPv6.

The new current recommendations for address allocations are as follows:

  • /48 in the general case, except for very large subscribers
  • /64 when it is known that one and only one subnet is needed by design
  • /128 when it is absolutely known that one and only one device is connecting

It goes on to state other recommendations and offers guidance to operators with regards to when to allocate certain prefix lengths.  But essentially, what this means is that now individual network operators have more options regarding which prefix size to allocate, and allows them to move away from strict general guidelines.  In essence, operators make the decision as to what prefix size to allocate based on an analysis of the needs of particular customers.

Perhaps this practical conservation may never be needed given the trillions of address space available in IPv6, but maybe, just maybe, in the very distant future if IPv6 is still in widespread use, it could very well be due to some of these recommendations being put in place today.  After all, 640K did turn out to be a rather small number didn’t it?

IPv4 Address Exhaustion Causing Harmful Effects on the Earth

Today, I received a very disturbing email on NANOG which was forwarded from a recipient on the Global Environment Watch (GEW) mailing list.  If this is true, we all need to take steps to make an orderly and smooth transition to IPv6 as quickly as possible, lest we suffer from the harmful effects described in this email.

Preparation Tips for the JNCIE-ER Exam

As many of you know, Juniper is currently undergoing a massive effort to update their certification program.  The previous track in ‘Enterprise Routing’ is now changing to ‘Enterprise Routing and Switching’ incorporating elements from the previous certification track in addition to some new elements essential to Enterprise switching such as Spanning-Tree, VLANs, Layer 2 Security, as well as High Availability features like Virtual Chassis.  We can expect that a lot of the topics like Firewalling and NAT will be removed from this exam as these topics will more properly appear in the Security track.

Although the new JNCIE-ENT certification is planned to be released in August 2011, there are many of you who are currently pursuing the existing JNCIE-ER before time runs out.  The good news is that Juniper plans to continue offering the existing JNCIE-ER exam until October 2011 so there is still quite a bit of time for those who are interested in attaining this certification.

There probably isn’t a single day that goes by that I don’t receive an email inquiry from someone currently pursuing the JNCIE-ER with a request to learn from my experiences and test preparation techniques.  And although this exam will only be available for another 7 months, I thought I’d write about my preparations and experiences with this exam so those candidates might benefit – not to mention it prevents me from having to keep repeating myself over and over again…

Building the Lab

For this particular exam, you are really going to need to get your hands on several J-Series routers, or at the very least some M/T/MX-Series routers with Adaptive Services capabilities (NOTE: This might require additional hardware on non J-Series devices, such as an Adaptive Services PIC or a Multi-Services PIC).  While it’s possible to do a lot of the routing preparation with Olives, a good majority of the exam is on services such as Firewalling, NAT, and IPsec.  Without the right hardware, a candidate cannot properly prepare for these sections as performing these functions in an Olive is impossible.  Olives have no hardware PFE or the appropriate Services PICs or Modules, therefore there is no SP interface which is required to create interface-style and next-hop style service-sets.

If you happen to have a bunch of SSG 300-Series or SSG 500-Series ending in an M in your environment, you may be in luck.  These devices can be successfully converted to an equivalent J-Series box running Junos.  For example, an SSG 320M can be converted to a J2320, and an SSG 350M can be converted to a J2350.

The easiest way to do this is to boot the SSG platform from the USB flash drive which has been formatted with the Junos image.  An easy way to build a loadable Junos image onto a USB flash drive is to insert the USB flash drive into a working J-Series device and then perform the following function:

This will copy all the appropriate system files and Junos image onto the flash drive and prepare it for booting on another device.

Once this has been done and the USB flash drive inserted into the SSG, the following commands can be issued to force the SSG to boot into Junos rather than ScreenOS:

NOTE: The SSG 300M-series or SSG 500M-series device must be running ScreenOS version 6.1 or later in order for you to perform the conversion.  If your device is running an earlier ScreenOS version, you must first upgrade it to ScreenOS 6.1 or later.

A more thorough explanation of the upgrade process can be found here: Converting SSG 300M-series and SSG 500M-series Security Devices to J-series Services Routers with a USB Storage Device.

Exam Preparation Materials

In terms of exam study materials, here is what I used for the exam:

  • ‘JUNOS Enterprise Routing’ by Harry Reynolds and Doug Marschke. Read it twice if you can
  • ‘Advanced Juniper Networks Routing in the Enterprise’ courseware and labs which used to be available for free on the Juniper FastTrack site.  These are no longer available publicly, but can likely be found with a little digging.  I definitely recommend going through the labs because they are extremely representative of the types of things that you are likely to see on the exam.
  • ‘Adaptive Services’ chapter in the JUNOS ‘Services Interfaces Configuration Guide’ – its 500 pages but will definitely educate candidates on all the variants of Junos Services.
  • The ‘JNCIP-M Study Guide’ by Harry Reynolds is another really useful addition.  The labs in this book will really help with routing policy and configuration of OSPF, RIP, and BGP.
  • Probably the *single* most useful preparation tip I can give to anyone is to take the JNCIE-ER Bootcamp and/or the Remote Proctored lab exams offered by Proteus Networks.  I haven’t personally taken the bootcamp, but I did see the materials from a colleague who sat through it and after sitting the exam I can tell you their Bootcamp is spot on.  On another note, I did take their remote proctored lab exams and once again I am not disappointed with my experience with them.  Rick Schenderlein was my proctor with Proteus and he really took the time to help me understand the areas that I could use improvement on.

As with all Expert level lab exams, a very important tip is to make sure you read the full exam in its entirety before starting a single configuration element.  This is truly an expert level exam – one which requires you to think through your design decisions.  There are often things later on in the exam which require you to go back and reconfigure something you’ve already set up in an previous section.  Reading ahead will allow you to save yourself some time when you’ve thought your design through fully in advance.

All in all, I didn’t think the exam was that tough, but I also had 12+ years of experience working with Junos and a JNCIE-M certification prior to sitting the exam.  If you’ve already got the JNCIE-M, I think it’s actually possible to prepare and pass this exam in just a few short months since there is considerable overlap between these two exams.  In my case, I actually finished the exam in a little over 5 hours and spent another 1-2 hours going over everything just to make sure I had it right. I’ve heard that most people going in are pretty much down to the wire with time so I’m not sure what happened in my case but simply attribute it to being over-prepared and having spent about a full year of non-stop preparations between the JNCIP-M, JNCIE-M, and the JNCIE-ER exams.  The trick here, as with preparation for anything, is to be consistent and develop a schedule which you can live with – a few hours a day over a span of several months will serve you infinitely better than studying hundreds of hours the few weeks before your exam.  Slow and steady wins the race here… you’ll be surprised at how quick a few months can go by when you’re motivated and committed to something!

I hope this helps those of you who are pursuing JNCIE-ER certifications, and I wish you the best of luck in your endeavors!