Juniper SRX

Perfect example of how not to make a firewall, Juniper's SRX series...

So I've been using a legacy SonicWall that is now EOL.  Worked great but I've always laughed that because I wouldn't consider it an "Enterprise" class firewall.  What I needed was a firewall that could handle multiple ISP gateways and support for redundant VPN site-to-site connections.  I had a CiscoASA alongside the SonicWall to handle the site-to-site VPN connections but unfortunately Cisco is still behind the times when it comes to making it work well with multiple gateways (especially an active/active configuration).  What was left was Juniper, but they insisted their ScreenOS line was soon to be exitinct and their newer SRX line was just as good.

On paper, I couldn't disagree.  Had everything I was looking for and more.  Unfortunately, I couldn't have been more wrong.  What it did support was so half-ass and buggy that I would never recommend this to anyone.

First off these SRX firewalls (I've configured the 220 and 240s, not sure if they bigger ones are any better) are nothing more than FreeBSD with a overhauled network engine.  With that in mind, the CLI starts off in a shell, moves to a ScreenOS type configuration, and in the end the result looks like a Unix Shell Script to make it as confusing and bloated as possible.

So I took 3 examples of how to configure dual-ISPs online with these Firewalls.  And despite their proud virtual-routing capabilities, the only benefit I experienced was using it to do workarounds for their buggy limitations.  In order to use both interfaces, the VPN tunnels have to be terminated to the main routing table which makes it a bitch and a half to be usable.  So weeks later and testing and trial-and-error I finally was able to have 2 VPN tunnels going out from one site terminating on the same destination at another site.  Great!  But it turns out their VPN tunnels are horribly unstable, if one goes down it took a total reboot of both firewalls to get them both back up.  Ended up using OSPF which also caused a lot of issues I had to work around but finally stabilized the VPNs if one died.

So next I wanted to cluster them.  How hard could it be right?  And this is where I lost all faith in Juniper.  They really shouldn't call it clustering because it takes a young priest and an old priest for it to work correctly.  So lets just call it cluster fucking them.  First, you need to find out exactly which ports to connect back to back (its random for each different model) then you configure these "out-of-band" ports which is really not out of band but just impacts your configuration because it conflicts with the network segment you put these in.  Next you have to configure another link for the switching fabric.  Okay whatever, I got through it...   so I'm set right?  Nope, if you want to upgrade the software on them after this point there will always be downtime.  The procedure is so complicated and ridiculous that in the end the safest and easiest method was to update both the primary and backup and reboot them at the exact time.  That's literally the only way to do this without worrying about breaking something.  So, I guess its okay, about 5-10 minutes of downtime (reboot time)..  but wait, even though its clustered if you run any UTM features (Antivirus, IDP, etc) you are limited to an active/passive configuration (where one does nothing but sit and wait around).  Yet you still need a license for each feature on both firewalls even though you can't use them at the same time.  Oh another gotcha, you can't really update the signatures on the standby unless you make it active.  I guess that's okay, oh but wait you need a complicated script to monitor if one unit does die because by itself it won't fully switch over to the backup unit.  Yuck, but I guess as long as it works...   So the first day in production: unit randomly switched over to the backup cluster despite it disabling two ports on its own.  It took rebooting both units to get it back to working correctly. 

So in the end, despite laughing at SonicWall, I realized how much I miss the fact that it took 1/100th of the time to configure and the fact it can handle multiple ISP gateways flawlessly as well as supporting a WORKING HA configuration.


Even without such a complicated setup like dual-ISPs or clustering, Juniper's SRX are still a total joke.  The latest version (11R2.4) tries to add a "global" address book feature (similar to Cisco's network-objects) but it only does a half-ass job at configuring redundant information and I still find myself putting in the same network information for NAT pools vs Policies.  Even worse, it takes 3-5 minutes of just waiting (where the web interface will eventually timeout) for a configuration to commit. 

Nice try Juniper, but this whole SRX line is just an example of how NOT to make a firewall.