SRX

Hi,

comming from ScreenOS and playing around on my on SRX210 box from about 3 month´s:

my opinion:

i´m verry frustrating about the webgui and the srx...   i know, better performance and bla bla bla...

but i have spend many time on my one to configure my own srx  box....

- the most thing you have to do with the cli, because the webgui simply does not work.

-  configuring on the webgui ... error on commit, on cli no problem ???!!!!

- nsm does not support junos 10....    and the new nsm 2009 is very slow!!!!!!!!!! - server and client - fw admins

complains the slowness every day....

- dynamic vpn ? haaa, i give access the whole world to my webui ??? what about manage-ip ?

- what about the track-ip feature ? i know scrpting ....

- changing from JunOS 9.6 to JunOS 10.0 they changed the whole factury-setup ???

   brigde-group is nice, but please put some interface in the untrust interface and let the webgui work for change

   the vlan-setup !!!!

- boot times of a srx210 with 4 -6 (access of the webuig) minutes are a joke ? my isg2000 with idp blades boots up in 3minutes ! and a netscreen 50 in 30 seconds !

so good performance, but lost of the most feature of ScreenOS and i have to read lot of documents and do troubleshooting....because the webgui does not work and i have to figure it out on my own  that i have to change the settings in the cli ? so, better remove the webgui.... if the most things does not work !

is this the idea of juniper ?

so if juniper want switch from the ssg to the srx they have to do many work, otherwise i  and my company who i`m working for, will  choose the ssg series or better switch to some other vendor...... , better spend time on other companys solutios that work !

i´m very fustrading of the srx series !, another day of spending my free time !

Please adjust the NSM 2009 Slowness also !

i`, comparing the gui from the checkpoint and juniper is a joke compare to them !

p.s. i hope some of the important juniper guys will take care of my post... or otherwise maybe fortigate or palo alto will be my choise for me and my company

Regards,

Piccolo

Thanks for posting your experiences with the SRX210.  The SRX was a strong contender for my next firewall purchase but I may look elsewhere now that it seems the problems with JUNOS are getting out of hand.  One question for you though, have you had these problems with JUNOS 9.X, 10.X or both?  If only the latter perhaps I could run 9.X until 10.X matures enough to be a useable platform.

Thanks aidan.

Junos 10 had a lot of focus on improving the web UI, boot times, etc and I think you'll find it a great improvement. That said, I've seen that the roadmap continues to focus on this area over the next several releases - we realize that this area needs more focus.

I'm also sharing this post internally - we have a new collaboration environment internally which helps us share this type of feedback more effectively.

BTW the change in factory config was for the better I think...you can plug an ethernet in and get a GUI without having to access the console and config first. As we make improvements there will be inevitable behavior changes.

Please do keep the feedback coming!

Thx

-Keith

Hello,

I would like also to give my feedback about SRX platform...

I deployed more than 100 Netscreen/SSG devices (cluster or not) since 5 years with great success.

This is one of my favorite platform...

Few time ago, junper platform was introduced...

1) Clustering (tested no JunOS 9.6R2)

Clustering is NOT stable. I have two cluster deployed. Both of them react differently. Sometimes one node is leaving the cluster without any reason.

2) GUI

That's the worst GUI I ever seen !

Slow.

Most of the command cannot be implemented in the GUI. Better to do it directly from the CLI

3) NSM integration (last version)

Policy push it not working

Sometimes, the log are not received...

4) UTM

AV is not working at all (test on JunOS 10)

It completely freeze the device.

5) VPN

Bug with VPN on JunOS 9.6R2

6) IDP

Because the RE engine is not active on the backup node (this config apply if you're in cluster only) cannot update the attack database...

Too much problem for me.

I took the decision to NOT sell this device anymore until all of these problems are solved !

Platform rating

SRX: 3/10

SSG: 8/10

Checkpoint: 8/10

Regards,

Hedi

1) I have the same issue with SRX240H and SRX240POE clusters running 9.6R1 So far the only suggestion from JTAC has been to change the patch leads for control link and fabric link. No improvement so far, I keep loosing nodes without any reason....

2) I only use the CLI, the GUI is to slow and misses most of the options.

3) NSM is a pain to work with, it is slow, not intuitive and always late. We had to wait more than a month after the 9.6R1 release for SRX running it to be added and managed in NSM. Same goes for 10.0R1, the DMI schema update came after the JunOS release. I can't understand why a company as Juniper is not able to schedule the firmware release and the management software release so there is no uncovered period...

For my own education, what sort of response times were you experiencing when using J-Web?  And what specific commands were you unable to perform?  Thanks!

i have bought on my own a srx210 with the goal to expand my skills on junos and for the "next" generation firewalls of juniper

starting from 9.5 until 10 i have to say that the webui has become faster, but the need of flash and all the "playing" stuff is very annoing and slowing down the configuration.... ! maybe some enduser will enjoy it, but i don`t !

even issues with junos10.... , some configurations made in the webui are not showing in the cli ? and vice versa... where are the rib groups for some examples ?

the cli commands are 3-4 times longer than in ScreenOS, lot of typing...

the changes in Junos 10 are not so nice for me..., resetting to the default and then wondering about what happened to che config.....  took me many time to remove the trust-vlans away with the cli, because in the webui this is not possible.. ..

for the other problems/ bugs there are enough postings in this forum.

very nice , losing lots of my freetime

but the great thing :i HAVE HAD  a new hobby ! SRX

know i am very angry with the srx, i will used it now as a switch, nothing more. i have no more nerves with the srx series !

it`s a joke what juniper has given out... ok, 1-2 releases having problems, it`s ok, but not 3 Releases and so on !

i have spend many money,  blown in the air !, but this was my last juniper equipment, i have learnd with the srx series !

better juniper move the performance of the SRX to the SSG / ISG Series, and people would be happy.

Working as an Security Officer for a Datacenter, SRX will there never be deployed ! That´s now sure.

HI Piccolo,

What bug did you have with the VPN on 9.6?

Piccolo,

Sorry to hear about your frustrating experience. As I mentioned before, we hear you (and others) and are working hard to improve the user experience, quality, and features of the SRX branch products. As you note, there's been improvement, but more to do. I hope you have cases open for the issues you've experienced - they may not be well known yet and that will help us tackle them sooner.

Some other comments...

re: CLI commands - longer yes, but with auto-complete (?, space or tab, the former providing online help) should not be that much typing. 

Now, as someone who used to do remote deploy's of ScreenOS based firewalls in a past life, I would tolerate a lot of typing for one element of the Junos CLI - commit confirm. This simple feature has saved many a truck-roll.(for those not familiar - it works like changing screen resolution on a Windows PC - it requires an subsequent ack from the operator or it reverts to the last config)

This feature is enabled because of the same underlying architecture that makes the commands a litle longer - as one of the lead developers notes "Junos treats configuration data as first class content.  This seems like a minor point, but it turns into a great opportunity for creating interesting features".

The Junos automation features are another good example of how the architecture is used

The Junos CLI is a powerful tool - the web UI can never completely replace it and it is well worth learning more about how it can help reduce effort and increase reliability in your networks.

-Keith

hi,

i know that junos is verry powerfull and have lot of features.

i also know that the webui wan`t have all the features of the cli, but this webui is the worst that i have seen.

it would be nice that the features implemented in the webui will work, not to troubleshoot the webui also..

i find it strange that juniper put out products, that are in "beta" phase, sorry, but this is my opinion.

i have bought the device, spend money for the suscription to get the latest a versions and what did i get ?

so this is my freetime  and also my money spending on my own and open tickets so that juniper can fix it there products  ?

this is not a choise for me, even not for my company.

Coming from a ScreenOS background myself and switching to the Junos-based SRX products I understand your concerns, as the operating systems are quite different. This can present a steep learning curve for a security administrator, and it is a fair criticism that JWeb doesn’t do a good enough job in easing the transition.

Since the Branch SRX (100/210/240/650) introduction last spring we have collected a lot of feedback about the product – what’s great, and what needs improvement – and most of the concerns expressed in this thread reflect those areas that we are focused on and working to improve. Let me make a few comments about what we’ve done and where we are going: 

Yes, the default configuration was changed with Junos release 10.0. This was done to be more consistent with SSG series behavior. There is an untrust port- ge-0/0/0 with DHCP client enabled and configured to pass the settings to the DHCP server which is the VLAN interface, similar to the bgroup function. JWEB access is enabled by default- HTTP and HTTPS on the VLAN interface which is in the trust zone.

2)    JWEB: there has been lot of work done to improve the usability and performance of JWEB. From Junos 9.5 to 10.0, page load times have been reduced by over 50%, and there will be further improvement in Junos 10.1.  We have re-written most security-related pages, routing pages, and interface configuration pages in a new, more usable format.  Additional pages will be re-written in Junos 10.1, 10.2 and subsequent releases.  We’ll also be adding wizard-type pages that will make configuration of basic tasks (like VPN setup) more intuitive over the course of 2010.

3)    Dynamic VPN: We’re aware that the dynamic VPN client is not as easy to set up and use as it should be, and improvements to both the client itself and its integration on the Branch SRX are in process, and portions of this should be deliverable in spring 2010. Please refer to this guide: http://kb.juniper.net/library/CUSTOMERSERVICE/GLOBAL_JTAC/technotes/dynamic-vpn-appnote-v12.pdf for further assistance.

4)    As for issues with AV, VPN and Chassis Clustering if you have  JTAC case(s) open please do provide the number(s) so that we can look into this, and expedite any necessary bug fixes.  I also want to emphasize that subsequent Junos releases in 2010 will add additional feature depth and improved flexibility to each of these subsystems.

5)    We are also working to improve the SRX documentation, knowledge base content,  and application notes. Later in 2010 we’ll have some new publications available in the spirit of the popular ScreenOS concepts and examples guide.

6)    Last point, we are making good progress in reducing the backlog of known product issues and also enhancing our test coverage for the more complex feature combinations.

I do appreciate the constructive feedback the participants on this thread have provided.  SRX is a strong product today, but we have plenty of room for improvement, and we are working hard to address all of the concerns that have been cited. In case any of you are interested in providing feedback to us directly and would like to hear/participate in beta programs please send us a message via the forum. We will continue to actively monitor this forum, JTAC cases, and other feedback to ensure we are responding to your experience with the product.

Regards

Hi ScreenOs

Just wondering does your VPN client prompt you to login twice?during the xauth phase?

Keith,

i'm a big Junos fan myself but the SRX is really not ready for a production environment.  I put up with it with the understanding that this is a new platform and will take some time to work the bugs out.  But you have to understand it's difficult for us to continue to promote the SRX if these stability issues are not addressed real fast.

i'm hoping the next relase will put to rest the clustring and UTM issues.  We can live with the minor issues but not major ones.

-Polskino

We use a cluster of SRX 650's for NAT for our campus wireless (1000 access points), and

we use a cluster of SRX 3600's for our central data centre firewall (about 500 servers).

We have had these issues to date:

March 11 - 10:40am to 10:50am - main campus wireless down due to crash of Juniper SRX 650 NAT cluster running 10.0R2.10.

March 15 - 4:25pm to 4:30pm - main campus wireless down due to crash of Juniper SRX 650 NAT cluster running 10.0R2.10.

March 18 - 3:00pm to 3:45pm - main campus wireless down due to crash of Juniper SRX 650 NAT cluster running 10.0R2.10.

April 3 - 3:00pm to 5:00pm - main campus wireless down due to crash of Juniper SRX 650 NAT cluster running 10.0S3.1.

Jun 7 - 7:30pm - 20 second machine room service interruption when active node of firewall cr-sa crashed (Juniper SRX 3600 running 10.0R2.10)

IST Machine Room Firewall (Juniper SRX 3600) down Jul 28 7:51am to 7:55am, due to crash during scheduled software upgrade. Required power shutdown to restore service, and reversion of new software version.

Currently running on one SRX 3600 for machine room, other unit is offline pending schedule

software upgrade.

Details at:

https://strobe.uwaterloo.ca/~twiki/bin/view/ISTNS/ISTReportsToCNAG

I am hopeing that with the number of serious crashes you have had that you have opened a case with juniper and have uploaded your crash dump files so they can debug them or give you an internal fix if the dump matches a known issue.

yes, cases below.  Also please note the one crash April 3 of SRX 650 was our configuration error afterall.

It seems to be that the ScreenOS platform is a proven platform with years of stability improvments..

The SRX platform on JUNOS is new, fragile and honestly I am hard pressed to see advantages anymore..

My latest issue came with just how much easier it is to do QoS tasks in ScreenOS.. In ScreenOS you can juse add a DSCP tag to your policy and all traffic that hits it is tagged... The only ways to do tagging in the SRX at the moment are firewall filters, or licencing IDP to due it in an IDP rule.. Policies in ScreenOS seem much more powerfull than JUNOS and at no extra cost as they are base funtionality..

The NEW UTM features that are not available in low end ScreenOS devices, just DO NOT WORK in the SRX... It seems proven again and again that if you enable UTM features you will have stablity problems. Hell even my SRX boxes running NO UTM have had flowd core on them...

I could not and will not recommend the SRX plaform to anyone... it is a shame since we LOVED the ScreenOS platform for years!

Hello,

Same conclusion for me !

Move to Fortinet and Sonicwall for firewall that need UTM features...

Bye

Hedi

How about the SRX3000 series security log still not woking with the NSM !?

and don't have any security log(firewall log) viewer and log management UI !!!

Our company try to find one UTM system to replace checkpoint that  we working on the porduction .

so,we took survey on SRX platform at Mar. this year,and the SI, the seller gave us SRX 3600 to replace checkpoint and also put the NSM in this case to replace the checkpoint GUI management tool "SmartDashboard" and "SmartView tracker"

in the survey time,they just gave us "Network and Security Manager" runing the demo data,to compare the "SmartDashboard" and "SmartView tracker" UI,and tell us that's the way they working with the SRX3600 rightnow,NSM's GUI Management console, firewall log viewer ,log management are working just fine!!

so....finally,we bough the SRX3600、NSM at Sep. this year

but, as piccolo78 said,that take SRX's GUI to compare Checkpoint's, It's just like a joke !!!

SRX3600 not just like Netscreen 5000 can working with the NSM rightnow,

especially the part of security log viewer and log management,

not even get security log into(import)NSM,

so how I wonder why the branch series SRX now can put security log into the NSM ,

but the enterprise series still naver supported rightnow?!

our company toke ISO17799 very long time ago,and also toke ITIL(ISO20000)in this year and pass the audit

we got lot's heavy routine job to do with security log,that's the key we running the system in the networking parts

but rightnow,we still can't get any help to solve this problem

juniper local tec.support says, that might be next year JUNOS 10r1 can support this

that's just.....makes me......very angry.....

---

@Chenpimei wrote:

How about the SRX3000 series security log still not woking with the NSM !?

and don't have any security log(firewall log) viewer and log management UI !!!

 

Our company try to find one UTM system to replace checkpoint that  we working on the porduction .

 

so,we took survey on SRX platform at Mar. this year,and the SI, the seller gave us SRX 3600 to replace checkpoint and also put the NSM in this case to replace the checkpoint GUI management tool "SmartDashboard" and "SmartView tracker"

in the survey time,they just gave us "Network and Security Manager" runing the demo data,to compare the "SmartDashboard" and "SmartView tracker" UI,and tell us that's the way they working with the SRX3600 rightnow,NSM's GUI Management console, firewall log viewer ,log management are working just fine!!

so....finally,we bough the SRX3600、NSM at Sep. this year

 

but, as piccolo78 said,that take SRX's GUI to compare Checkpoint's, It's just like a joke !!!

SRX3600 not just like Netscreen 5000 can working with the NSM rightnow,

especially the part of security log viewer and log management,

not even get security log into(import)NSM,

 

so how I wonder why the branch series SRX now can put security log into the NSM ,

but the enterprise series still naver supported rightnow?!

 

our company toke ISO17799 very long time ago,and also toke ITIL(ISO20000)in this year and pass the audit

we got lot's heavy routine job to do with security log,that's the key we running the system in the networking parts

but rightnow,we still can't get any help to solve this problem

juniper local tec.support says, that might be next year JUNOS 10r1 can support this

that's just.....makes me......very angry.....

 

---

With all due respect, although I do agree that the logging situation is a bit strange I feel that your issue stems from a lack of proper evaluation and of the reseller misrepresenting the product rather than there being any major problems with the product itself.

yemgi,

     I am evaluating the SRX platform.  I have a cluster setup with SRX240POE boxes and it seems stable.  Could you please elaborate on your experience with clustering the SRX240POE?  Do you have any special cluster configuration requirements?

thanks

Hi Jodros,

currently I'm also running a cluster of 2 SRX 240H devices (not POE, but imho that doesn't matter). The cluster survived  my own tests (heavy loads (many new sessions, high throughput), failover, etc.). But as we planned to rollout, the cluster screwed up. Luckily this happened, before the system was live.

Currently I have to say, that the cluster features are completely unreliable.

Example: If we trigger a failover or restart, one node gets into state "disabled" (error message for example:  ...Failures: cold-sync-monitoring...). After this, also the second (active) node is unreachable. Funnily enough, it worked many times with my test configuration. And yes, now there's no special config.

I really like JUNOS, especially the CLI and the fact, that it's based on BSD. Therefore, I don't need J-WEB. If you know, howto use the CLI (e.g.. go to a deep level to avoid very long commands) you'll never use J-WEB. But nowadays, an easy to use web based interface is mandatory for most people. Due my bad experiences made with the SRX Series, i think you should wait at least 3-4 revisions before there's a chance, that this platform is mature enough for production use. <Joke> If I we're Juniper, i would donate one year subscriptions for free (especially because the JTAC has no known workarounds!!) 😉 </Joke>

Tweety84,

     Thanks for the comments.  If we decide on Juniper, we would go with 2 SRX3400's with at least 2 SPC's and NPC's.  The evaluation is with 2 SRX240POE's.  I saw a few abnormal issues with the cluster at first, but it was due to a misconfiguration on my part.  The interesting thing about that is I was following a config guide from kb.juniper.net support.  The config guide has a typo when describing the set apply-groups.  It says to issue command: set apply-groups "${NODE.EN_US}" but it should read: apply-groups "${node}".  I left this command out and it caused some interesting results.  I finally spoke with someone and corrected it.  Since then, clustering has passed all tests that I have performed.  The more I read about the SRX, the more it worries me.  I recently discovered a bug while testing with reordering NAT rules.  If you have "overlapping" source NAT rules, they are processed in a top/down fashion.  I had to reorder the NAT rules so that the more specific ones were near the top, similar to an ACL.  I did so and then committed, however the SRX continued to process the NAT rules in the original order.  I had to completely remove all rules and enter them in the correct order.  This is a big concern for me, as I do NAT maintenance frequently and I cannot bring down NAT globally in order to perform routine NAT maintenance.  Any other opinions on the SRX would be appreciated.  I will also update with more findings as I continue testing.

@jodros,

Thanks for alerting on the typo - I've notified the author.

-Keith

Hi jodros,

as i've started with my tests, the mentioned guide was not available. I also had to figure out the fxp0 (...) stuff by myself. The node specific configuration also worked without any problems (apply-groups "${node}" is official documented). My tests also worked flawless but then, the troubles began 😉

I think you can't compare SRX200 to SRX3000 completely, because the PFE is realised in software, in case of the SRX 200 Series. Therefore you could be affected by different bugs.

I think the SRX platform is/will be really powerful, but needs some fine-tuning in different cases. If you have to deploy the firewall cluster in the next months (and it has to be really reliable and you don't like to hit the roof) i would take the SSG/ISG series. Compared to other solutions, juniper is still (for some cases) my favorit.

The perfect storm NSM and SRX240 Cluster

We’ve had NetScreen OS type firewalls for about 5 years now, SSG520, NS25, NS140, and ISG cluster. The NS OS is stable and NSM is an easy way to fully manage our enterprise.  We even run NSM on a VMware server and it runs just fine.

This spring we were ready to add a new data center and we decided to go with the SRX 240 in a clustered environment. It appeared that Juniper was moving toward a Junos OS ( FreeBSD) and we wanted to try it out.  We received our SRX’s in March, 2010. 

After many hours on the phone with NSM and SRX support we were able to get the NSM server to communicate with the SRX cluster. Clustering requires a separate subnet for the Management interfaces.  Also required documentation was only available internally to support staff.  NSM support did not have any idea how to do this. Be aware if you start out with 16 Ethernet ports after cluster you only have 13 for data, three are sacrificed for the cluster, an ISG cluster only needs one “HA” port sacrificed.

On each SRX one of the three ports is a management port, except that only the NSM server can use the interfaces, you cannot setup ssh, telnet, http or https on the interface to manage each device individually.

You can setup the reth (redundant ethernet) to respond to ssh, telnet, http and https but only the primary node will respond to the remote client.  This is really great when it is time to upgrade the cluster, it guarantees down time.  You can find other comments about this on the forums.

We spent a long time with NSM staff asking how to setup a new interface and build a policy using NSM. There is no NSM documentation concerning managing a SRX cluster that we or they could find.   Know one at the NSM group has any idea how to do this from scratch.  Only by getting the SRX group involved, using CLI, could any progress be made on the clustered environment.  By watching what is happening on the CLI I and then going through the various NSM web screens I was able to figure out a way to create Interfaces, Zones, Reths, Services and Routes.  Weeks later I have made a walkthrough with screen shots for my staff so that we can do all this from NSM, 30 pages of notes  We have yet to tackle NATs, DIP’s, MIP’s and VPN’s, which we will need soon.

  When the cluster was finally up we found that it would not send logs from the cluster to the NSM server.  This is a known problem between NSM and SRX supposed to be fixed in a later release.  So then we needed to upgrade the NSM schema and the SRX to 10.1R2.8.  NSM support helped us with the upgrade, they upgraded the primary SRX unit which broke the cluster and then they turned us over to the SRX group to upgrade the secondary unit. Hours later when both units were upgraded we got most of the logs but not all, the log file is missing “rule #” and “policy #”.  We have had a ticket in with NSM and SRX support for a week now without a solution provided.

By July 2010 we still do not have a working cluster that I would trust in production.  Knowing what I know now we would have never purchased the SRX cluster, another lesson learned. 

I would have never have believed support would be so poor on a product.

Get a cluster and try it for yourself.

fxp0 interfaces in a cluster can be used for management not via nsm with host-inbound-traffic system services under each node.  You can also setup master-only for an IP so as to manage the primary node in the cluster or each by it's fxp0 IP address.

With the latest Schema / service netconf ssh under the node config of your group importing into NSM should be a snap?

With respect to ISU, this currently isn't supported at the branch level so I generally practive requesting the software add on node 0, they about 25 seconds later on node 1.  Again, this isn't In Service like the data center guys, but it's a upgrade process that works none-the-less.

---

@Badger wrote:

By July 2010 we still do not have a working cluster that I would trust in production.  Knowing what I know now we would have never purchased the SRX cluster, another lesson learned. 

I would have never have believed support would be so poor on a product.

Get a cluster and try it for yourself.

---

Have you tried operating the cluster without the use of NSM?  From my understanding NSM is really meant for the SSG series and operability with JUNOS isn't the greatest, as you've discovered.  I'd suggest reading the posts by SomeITGuy for further information on the subject.

We have a SSG550m-Cluster that works like a charm. We had to scale our networking needs and therefore needed a bigger firewall. We chosed SRX650 in a cluster. So far, I really like the JunOS-CLI, but for the problems we had with this setup, I wouldn't buy it again if I had the choice. We had 2 failures of our cluster, both times there was no automatic failover. Until now JTAC can't really tell us why and this is 4 weeks ago. We are using dns-names in our addressbook, as we have some customers, that use dyndns to be able to have policys for their boxes from their DSL-lines. This worked always on SSG without a flaw, DNS was updated according to the default TTL of 60 seconds for dyndns-addresses... this isn't working on SRX, dyndns-hostnames will be refreshed when used in policys every 24 hours... odd thing, pinging from the cli gives the proper IP. After going up to 2nd or 3rd level in JTAC, they told us it will be fixed in 10.2R2... At the moment I'm not really happy with JTAC nor the SRX but I can't go back as it is in production. I'm just hoping things will settle down in near future... and I want in-service-updates in branch! What the heck I have a cluster for?

The best would have been a hardware that could work on either screenos or junos srx, ie the same kind of

stuff you can do with ssg/jseries devices.

I already asked for this, the answer was that the screenos code couldn't run on srx hardware.

Since my name was mentioned I thought I better post here..

We have been running ScreenOS units for a fair number of years along with NSM, as far as on paper the SRX series appeared to be a clear winner and upgrade path, however our experience has us seriously concerned being long time Netscreen fans.

Here are my pros and cons of migrating from ScreenOS to JUNOS and the SRX platform in general.

Pros:

- Although it is more verbose I really like the syntax and auto complete features in the command line

- True Structured configuration files are consistent and easier to do diffs on as well as copy and past in compared to the list of CLI commands the old files used.

- There are some great configuration life savers for remote management, such as having a rescue config bound to the reset button

- commit features that let the device auto roll back if you loss contact

- the fact that when you edit, you are not editing LIVE, allowing you to check syntax

- Lots of throughput even in the low end units

- our locations are running SRX210 units doing minor filtering and tagging of traffic and haven't given us any issues yet.

Cons:

- Simply not as reliable as ScreenOS

- UN SAFE SYSTEM DEFAULTS if you do not explicitly set a value in your config. IE some session time outs are unlimited and will kill your box if not set, on a screen OS device there is a default of 30 min that it falls back on

- Logging works in a completely different and UN SAFE WAY on an SRX.. IN ScreenOS logs are held in memory and roll over no matter what you set your logging level to. In JUNOS if enable local logging (you must to log to NSM) logs grow on the storage volume, if they grow too large and fill it, services fail and the box stops. The log file limits are enforced on a timer it was 1hr in earlier releases and now is 15min, if you debug or run traffic logging settings there is a very good chance you will fill storage WAY before the timer kicks in and prunes the logs

- NAT is different than ScreenOS and in the SRX it is even different from other JUNOS devices. The documentation is VERY lacking most of what you find is for the J series. The new NAT may be more flexible but at the same time it is more difficult since the documentation is not all there.

- the default MTU for the ST (TUNNEL) interfaces is 9000, this is likely since the boxes support gigabit interfaces but this is a crazy default since you are more likely to need something like 1500 or less when doing tunnels over the internet.

- HA clustering is not reliable....we seem to have discovered a new bug where BOTH nodes die at the same time!

- HA clustering is strange to manage in NSM, you end up with 3 devices a cluster and each node, when you update the cluster you actually see the commands go to both nodes with one, stating it doesn't need the update since it is not the master, compare this with a set of JUNOS switches in a Virtual Chassis and they look like one devices?

- Our Cluster of SRXs have been in production for only about 1 maybe 2 weeks since they where first rolled into production, we keep having to put our ScreenOS firewall back in place as we DISCOVER new issues, this has being going on for about two months!

- Just another little thing.. The rack mount for the SRX 210 is ridiculously expensive...

"UN SAFE SYSTEM DEFAULTS if you do not explicitly set a value in your config. IE some session time outs are unlimited and will kill your box if not set, on a screen OS device there is a default of 30 min that it falls back on"

Hi there what session timeouts would you recommend?

April of 2012 and it still really sucks

o

---

@do0zer wrote:

April of 2012 and it still really sucks

---

If you don't have anything meaningful to contribute to the conversation then please don't do it.  In this case meaningful could be "I dislike the SRX series because of x, y and/or z."  It would also further the knowledge of the community and perhaps other members would have suggestions or workarounds for the issue.

Flannigan is totaly right! Please do0zer :come with arguments.

Just purchased two SRX 650s to replace an aging SSG550M HA pair. Looking at the recommended release code, which is JUNOS 10.4R9.2, anyone know a reason why is this a ful 5 revs of code back? Is anyone using the 11.x or 12 series of code???

Any input is appreciated.

the xx.4 releases are EEOL (Extended end of life releases) IE they are the combination of an entire years worth of new features and instead of having one year of patching support they have 5 years of r release support.

The Recomended release is always the release that Juniper has the fewest open issues on and has the most field testing...Thus in most enviroments it will be the most stable...

If you where looking for something newer I would watch 11.4, it is only on r2 so far.

JUNIPER just started recomending 11.4 for EX and some other platforms, SRX is probably comming soon... However my gut feeling is that a r3 will come out before that happens.

Great - thanks for the info.

I think you'll also find that for a while, there were lots of bug and other stability complaints with the SRX line. Juniper seems to have taken that to heart recently and the 10.4Rx series is putting that behind them.

The 11.x and newer have some really nice features, but for most people the 10.4 line's features are "good enough" (the Juniper SRXs really can do a TON of things for a single box!)

Just FYI - if you are using a cluster and want to use JWeb don't bother updating to 11.x or 12.x. JWeb won't display cluster info (tells you that clustering is not enabled even though it is as verified from CLI), zones do not display at all and redundant interfaces don't disaply assocaited zones. There are known PRs for this in 11.x JWeb code - supposed to be resolved in 11.4R5. 12.x is supposed to include fixes for these issues, but sadly does not.

This is the kind of stuff the keeps us hanging on to our ASAs.  You'd think an 11.x or 12.x release would be ultra stable by now.  sheesh.

Hi,

I want to buy a SSG firewall but does the SRX still suck?

I've got an SRX210 and I have found it to be very unstable. It has real issues reconnecting to an ADSL connection that has dropped. I've got a JTAC support ticket open but it has been about 2 months now and I they haven't been able to fix the problem.

The SSG range is great but I'm having issues liking the SRX devices, really buggy. I cannot recommend them to my clients which is a shame because they should be good...

I hope they fix these issues soon otherwise it is time to go to a different company.

I am using an SRX240 and SRX210 live as we speak but I do have a simple network design with two offices

Let me talk about whats good

1. VPN's were easy to setup

2. Good hardware

3. Junos (is great when you get the hang of it)

4. So far its been reliable (knock on wood) I don't have any UTM and IDP policies in place as of yet

Before purchasing my SRX I was testing the SSG line of firewalls and they worked great! I decided to go with the SRX since my Juniper rep told me that its the best of both worlds firewall and routing and since its using Junos I assumed that it would be the future of the Juniper firewall line.

I also compared the hardware specs with the SRX to the SSG and it beat it bad. Plus it included a 16 port switch.

What I don't like about it is the little things for example

1. I cant assign my remote VPN clients into a different security zone

2. I can't assign a DHCP pool to my Remote VPN clients

3. I cant change the SSH management port from 22 to another port

4. I cant use MS CHAP or PEAP for remote VPN connectivity

5. Dissapointed with the licenses Dynamic VPN licenses is 10x a normal NS Remote Client license and since its 10 times more i hoped it was 10 times better but its not. I hope this are little tweaks lke adding the MTU etc on the client better logging etc but right now its version 1 - I hope they make alot of changes soon

6. I cant have a VPN group profile everybody needs their own IKE and IPSEC config

7. Configuring port forwarding is a pain only 8 rule-sets per destination and source NAT

8. I heard clustering and high availablity is a huge problem right now. I was considering a high availablity environment for next year but I guess I will wait it out

9. UTM and IDP are hardware hogs and crash the system considering a license for both is 3 grand. This is unacceptable and needs to be fixed ASAP.

Those are some of the features I came accross, and this firewall is still very young and I find it hard to get help. The documents are ok and the help menus on JWEB are pretty much useless. The support has been pretty good but I do have a ticket that hasn't been answered for 2 weeks.

What I would like to see is Juniper provide us customers with more road maps and future plans with the SRX series and the Network Access Manager.

The SRX is basically an SA, SSG, IDP and J-series router all in one device and has alot of potential I wish that Juniper would focus more on the UTM IDP HA and VPN issues since that is what we payed for

those are my 2 cents, atleast everyday i am learning something new and Junos is great!

Looks like it's time for srx review, so here are my comments.

I purchased an srx100h to replace an old ns5gt to work from remote.

pppoe worked quite easily, but then I had really nightmares with nat (I tested the latest junos 10), so the box was not usable even for a single user.

I systematically had "dip allocation failed" messages in the debug trace, and found nothing in the kb about this.

jweb cannot be used, it would be really a good option to be able to disable completely jweb (ie stop the http daemon).

update time is also huge compared to screenos update, even on the smallest devices.

I also noticed with the top command there was a process called flowd_..; that consumes systematically 90% of more cpu. could it be possible to know what this process does ?

I had to put back my ns5gt, and I think I will put the srx100 behind the ns5gt to do some more tests.

Regarding the documentation, could it be possible to have an srx "concept and example guide" ?

this document is really good (even if there are some errors within, but as in every technical document that has this size).

Hello there,

Regarding disabling Jweb - does

set system processes web-management disable

- work for you?

Rgds

Alex

I have seen a lot of negative feedback on the SRX platform in this thread so I thought I would leave a little feedback. First a little background on myself. I come from the world of Cisco routers and switches. My first experience with Juniper was with the M series routers running Junos 6.x. Over the years I have touched many firewall devices including Cisco ASA/PIX, Netscreen ISG and SSG firewalls, as well as checkpoint firewalls. 

I think that your approach to the SRX has a lot to do with your background. I came more from the network engineering side as apposed to the security side of the business and i liked Junos because of the modular configuration system, the ability to do in service upgrades on the larger platforms, and the ability to make all changes then commit the changes at the same time. To me this was a big improvement that Junos has over IOS. But when you come from the networking engineering side as apposed to the "firewall only"/security side of the house you are trained, especially if your background is cisco equipment, that the CLI is king. Because of this I would not consider myself proficient on a product unless I knew the "ins and outs" of the CLI. In my environment we also have load balancers that I manager, they happen to be F5 load balancers. I can do about 90 percent of the day to day administration of those boxes through the GUI, but I am very limited in my knowledge of the big pipe CLI. Because of this i would have to rate my proficiency as novice even though our configuration is advanced. Every time those devices actually crash or have an issue, I have to call support and have them fix it via CLI. Even Cisco devices are configured via the CLI any GUI the newer equipment has is nothing but lip service.

Since I have been working with Junos for a while, I feel right at home on my SRX boxes, of which we have about 15 deployed right now in firewalls/vpn and IDP roles. Anyone who has played with the normal non enhanced version of Junos like we run on our M platform routers, can tell you how wonderful the SRX version of Junos really is. In the non enhanced version that the bigger platforms run, Nat rules are created as a firewall filter like setup, and service firewall filters have to be configured on the interfaces to redirect traffic through a special service interface, which applies nat rules and limited application aware ALG filtering/statefulness. 

I have a partner at work who also is an engineer, his only experience with Juniper prior to the SRX platform was netscreen ISG and SSG firewalls. He continues to complain about why he has to use the cli and he goes behind me and turns the GUI back on. I guess this is normal for a lot of firewall admins, bad people trained in the checkpoint / netscreen ways of doing things. I know in my previous work experience most large ecomm sites I have worked in would disable the netscreen webui as a matter of policy as soon as they were installed. If you are hiding behind a GUI you are not proficient with the product, plain and simple. The GUI shields you from what is happening on the box, in some cases it even prevents you from understanding the true flow of traffic and how the devices logically process traffic and rules. The greatest feature of the SRX is JUNOS! And the best feature of JUNOS is the amazingly well thought out modular CLI. 

The CLI allows you copy sections of configuration and rename and change only small parts of them. It allows you to preconfigure a box early and deactivate the configuration until it is needed. It allows you to moves entire interface configurations to another interface without retyping anything. I just can't see how anyone can say that it is too much typing, if anything the descriptive names for rules and terms makes the firewall configuration smaller and easier to parse because well thought out sections of code can be used multiple times without retyping.

Also the security logs. I prefer to have the SRX syslog all security logs then do a grep for the logs I want. see the following for an example of what I mean:

http://forums.juniper.net/t5/SRX-Services-Gateway/Logging-for-Firewall-policies-in-SRX/td-p/32002

Flaws

With all this being said their are some real issues with the SRX platform specifically: Version 10.1 is really really buggy. Version 9.6r1 has issues with websense redirect crashing. Version 9.6r1 thru version 10.1 have issues with antivirus filtering service crashing, this causes the SRX box to not process web traffic until the UTM service is restarted. All version of Junos on the SRX-210 device I have used have issues with IDP. if IDP is running even in the Getting-Started profile where it does not take any action, this causes webpages to not load, and many sites have trouble such as banks and the latter where you will click on a link and nothing will happen. Sometimes users have to close their browsers or try 6 or more times before half the webpage will load or all of it. To make matters worse this happens only with certain sites. As a matter of fact i have to say that the UTM and IDP performance is so bad on the SRX-210 in terms of sites not loading or the services crashing, that I wish I could get my $500+ back I spent on those licenses.

There are some other issues with the SRX device as well. No equivalent to track-IP or Cisco's IP SLA with response time reporters. Having to write a 500 line script that commits and rollback configuration changes to add static route failover is not an acceptable solution. this is a feature not really needed on the data center MX series routers but it is absolutely critical on the branch office series devices. This is a big one that I cannot stress enough!!!!!!!!!

Also there are issues with IPV6. Most of my SRX's deployed in the field have at the very least 2 ports in a public VLAN so that if one of the ports in a branch office fail i can have them plug the ethernet cable in fe-0/0/6 instead of fe=0/0/7. This way I can get the remote site up quickly in the event of a hardware failure. Many of these remote office devices are sitting on the microwave, or dangling in the A/C closet and they do have ports go bad or fail. So in almost all my cases IP addresses are configured on van interfaces. However IPV6 addresses are not supported on VLAN interfaces. This problem is really upsetting as we have a lot of IPV6 on our networks. Maybe not a deal breaker for a lot of people but not being able to run duel stack on a VLAN interface is really bad. This is something that should be a no brainer at this point in the IPV6 game.

Also it is great that JUNOS is modular an sometimes services crash such as DHCP, but It really sucks that I cannot have the device autostart the service or monitor service health so that in the event that the OSPF service crashes the device just restarts it. In most cases the device does not automatically do this, I have to do it myself. 

Other than these issues I would rate the SRX 

SRX 8/10

SSG 4/10

ISG 5/10          

For the record I find the flat configuration of the SSG or ISG CLI to be extremely tiresome and trying.

All,

Thanks for the posts regarding ScreenOS vs JUNOS, especially John_Barns.

I have some significant concerns having read this.  I am getting ready to make a recommendation to a customer on Juniper products, and I have a strong ScreenOS background...but these points make the SRX look like a poor solution at this point.  Maybe it needs another year of in developement.

What is the ScreenOS EOL/EOS dates?

Maybe I will look harder at the SSGs.

Here's the link to ScreenOS EOL information - you can see that for the latest release, 6.3, it's got about 15 months before EOE and 27 before EOL. http://www.juniper.net/support/eol/screenos.htm. Subsequent releases will of course have later EOL dates.

The decision to buy or recommend a branch SRX shouldn't be predicated on just these forums alone. We've shipped  thousands of branch SRX products -- and forum posts naturally self-select to those having problems, whether configuration related or (more rarely) actual defects.

ScreenOS has had over a decade of engineering and field experience put into it - so it will compare favorably to any product on the market. But the SRX series(along  with Junos) offers some incredible performance and feature capabilities.

HTH,

-Keith

Keith,

I agree that forums are generally places to vent.  To the long post by John Barnes...net engs (with Cisco background) use the CLI religiously.  I like the JUNOS CLI...I configured a lot of SCREENOS boxs via CLI.  But I am two years removed from that role.

What I am looking for is a general confidence level from folks using the devices.

I don't have a lot of time for the learning curve....so having proper support is going to be helpful too.

Thanks all.

Guys,

I'm a ScreenOS user (and instructor) for a few years. Two years ago I started with JUNOS. Teaching JUNOS as well now. I like to share my opinion here with you.

First: When you find you need to type more in JUNOS then you're used to in ScreenOS try this:

- Make good use of spacebar and tab for command completion. Command completion is much stronger in JUNOS then ScreenOS.

- Get used to going into a hierarchy with edit instead of typing commands from the root: it saves you tons of typing.

I used to do a basic setup in ScreenOS with the CLI. Policy and VPN I did in the gui because of the complex syntax in the the CLI. Now on JUNOS I almost do everything with the CLI: it's just the best CLI I every saw in my 25 years in this business.

Since 10.1 is out the gui is getting better. The single commit is OK. I'm waiting for that on the switch... What's really absurd to missing in the GUI is static NAT and creating a tunnel interface.

When ever JUNOS has what you need for your config go for a SRX. Only when you need something JUNOS doesn't have (yet) stay with ScreenOS!

Hope this helps a little in the discussion.

Thanks, the feedback its very ilustrative.

We were researching about resell SRX for our customers, and i have to evaluate against Fortinet and PaloAlto.

I believed that was only my idea that JN its losing the leadership in New NG-FW and/or UTM, now i understand that these idea its unafortunatly true. Please JN try to maintain the leadership you had with Netscreen.

I installed SSG and im not impressed, its not easy and the webGUI its ugly, if you said that SRX its worst that SSG, its a bad news for us, because our technicians are investing(spending) time in JUNOS.

I expected to hear: "good job Juniper Networks, the SRX are impressive", Why?, because these comments are i heard from the other UTM provider: "excellent, the new 4.0 have solved my requirements" and more congratulations in the forum.

Yes, Im come from Cisco world, CLI is  very useful and Junos is very better that IOS, but remember the user need functionality, as we are technicians love CLI.

i would like to share with you the happines of users making load balancing-ECMP-Traffic Shapping-VPNIPSec-VPNSSL-and much more with GUI and zero CLI.

I love Juniper Networks, i believe you can do it, i expect that you regain your righful place.

Regarding the quote:

---

@John_Burns wrote:

 

have a partner at work who also is an engineer, his only experience with Juniper prior to the SRX platform was netscreen ISG and SSG firewalls. He continues to complain about why he has to use the cli and he goes behind me and turns the GUI back on. I guess this is normal for a lot of firewall admins, bad people trained in the checkpoint / netscreen ways of doing things....  If you are hiding behind a GUI you are not proficient with the product, plain and simple. The GUI shields you from what is happening on the box, in some cases it even prevents you from understanding the true flow of traffic and how the devices logically process traffic and rules. 

 

---

First, I'm not sure Checkpoint/Netscreen-trained firewall admins are bad people 😉

Secondly, I'm in the exact opposition situation as you: I'm a security manager trying to teach Juniper to Cisco poeple who live and die by the CLI. For the record, our IOS guys are not impressed with JunOS for a variety of reasons... Mostly due to extremely "long-winded" or verbose JunOS commands and general instabilities.

The bottom line with CLI vs GUI isthat  the two should compliment each other. It's not "one or the other." The two lived in perfect harmony in ScreenOS platforms. On Netscreens, I can easily look at a massive policy that's nicely color-coded in the GUI, or use the CLI for troubleshooting, searching for policy elements, etc. I used both on a regular basis.

I agree the J-web on SRX platorms is not up to par. However, I'm not going to manage dozens of firewalls individually via the CLI either. Again, I depend on the GUI (NSM) to help automate policy updates and foster object re-use. It's not a preference, but rather a requirement for efficiency within an organization that runs on very thin staffing levels.

Would have been nice to see this thread before throwing away $20K.  These SRX650's have been a nightmare to use.  And frankly whoever wrote most of the documentation needs to be beaten with a blunt stick. 

We've been at our migration to these SRX650's now for almost 3 months and I can say without a doubt that this has been one of the worst migrations I have ever done.  The sheer over complexity associated with doing things in Junos just bogles my mind.  8 commands to make a destination nat??  The logical flow behind how to do things is insane.  I've used other closed and open-souce products that are infinitely more simple and intuitive to setup. 

As pro:s I would also add:

- The tools available for troubleshooting networks issues

- Possibility to access other nodes in a cluster (when logged in to one of the nodes)

When it comes to the con about a two device SRX cluster showing up as three devices in NSM, I don't see this any different from how the SSG is behaving in NSM.

---

@TRUKonsult wrote:

When it comes to the con about a two device SRX cluster showing up as three devices in NSM, I don't see this any different from how the SSG is behaving in NSM.

---

Ya, I am nit picking there.. we didn't cluster a SSG so I wouldn't know.. However I am running a virtual chassis of 4200 switches and as a grouping of devices it makes much more sense.

We still haven't started selling the SRX range to customers yet because of all the issues.

I'm very seriously thinking about ditching Juniper completely, the SRX range has been the most unreliable platform I have used in a long time.

I like the idea of running JunOS on branch devices but not when it is so unstable and feature limited compared to the SSGs.

Hi all,

I'm also very disappointed with SRX.

Does anybody has already ask to Juniper to replace the SRX with SSG because the SRX simply does NOT WORK properly.

I have implemented two cluster of SRX 240 (with ton of problems) and the customer ask me if it's possible to swap them with two clusters of SSG 140 (even if I loose IDP features).

Regards,

Hedi

I'd suggest to compile the screenos code for srx branch office devices,

and let you choose at boot time which os to run,

so you can wait until srx for branch is at the same level.

In my opinion this discussion needs to shift from referencing the SRX family as a whole to discussing specific builds of the JUNOS-ES software for it.  Saying that a you or a client had problems doesn't seem fair since even inside of this year there have been tremendous improvements between 10.0 and 10.2, for example.  If you're having problems with an SRX, and using old code, I'd strongly encourage upgrading to the most recent 10.2 and 10.3 code before drawing any conclusions for the near future.

mawr

Hello,

If you want, I can send you a list with ALL of the issues STILL NOT RESOLVED with SRX.

SRX IS NOT READY for PRODUCTION environment.

I have deployed more than 100 SSG devices without any complain...

Regards,

Hedi

@Hedi

I think it would be helpful if you post the list here along with the latest version you have tried. Please also indicate if you have JTAC engaged on the issues. This will help others avoid some of the frustration you've encountered and contribute meaningfully to the discussion.

Thanks for offering.

-Keith

Yes, I'd also like to see the list. We're considering spending a signficiant amount of money on an SRX650 cluster, and would love to know of any unresolved issues you've experienced.

This information about SRX troubles is extreemely interesting for me as well.

Hello,

For all those who are interested, here's the list

PS: sorry for my bad english...

1) Clustering + IDP
SRX clustering technology is NOT stable. Sometimes, without any reason, one node is leaving the cluster.
The only way to solve this problem is rebooting the device (sometimes not only one node but both).
We had 2 main crashes at each site !! The installation starts in september last year.
Tested with Junos 9.6R1, 9.6R2, 10.1R1.8. One of the cluster is running 10.2 since 7 days and I cannot tell you id it is really stable (need to wait a little bit more)

2) Boot time and upgrade procedure
SRX boots in more than 8 minutes (whatever junos is running) ! Too long...
Upgrade time is more than 15 minutes and we have to deal with insufficient space on the filesystem (see other post)

After MOST upgrade, the SRX (in cluster mode) loses the config file.
Workaround
 - move the node in non cluster mode
 - reboot
 - copy the config file in /config
 - move the node in cluster mode
 - reboot

Total average lost time : 30 minutes


2) Gui
That's the worst GUI I ever seen !
First, it's very slow. Don't tell me there is improvement in 10.2 That's NOT TRUE !
Second, no local logging about traffic flow.
Third, a lot of command cannot be commited (freeze) in the GUI. You have to move to the CLI.

3) VPN
There's a bug with Site to Site VPN in Junos 9.6R2.
Need to restart the ipsec deamon and after a random amout of time it works again.
DPD and ISAKMP Keepalive seems to be not compatible between ScreenOS and JunOS.
If you enable DPD, randomlly, the VPN goes down (need to clear SA on both devices)

4) NSM Integration
Policy push in not working (NSM 2010.3).
NSM 2010.3 is slow. Moreover, you have to deal with schema 147 bugs (see other post).
Sometimes, SRX stops sending log traffic to NSM.

Workaround: restart "nsm client" with activate/deactivate command.

5) UTM (AV, URL filtering)
AV completely freeze the SRX 650 (tested with Junos 9.6R2 and 10) with only two PC downloading some files (file size 20 Mbytes) !
Whatever mode you try to configure it.

URL filtering daemon stops working (randomlly) and need to be restart

6) Other problems
Policy configured for Exchange Server (client to server connexion) randomly drops traffic.
It seems that sometimes the SRX doesn't handle correctly the MSRPC call (problem with the ALG)

It seems that some people (see other post) have problem with SIP alg but I cannot confirm this.

After the upgrade to junos 10, my DNS server was replying with private IP ! DNS Doctoring is ENABLED by default.

Consequence: no mail for more than 1 days. The customer was really happy with this situation as you can imagine...

Regards,

Hedi

Hi,

We changed an initial SRX customer project by SSG and the customer is very happy.

It's clear that SSG has more features and it is stable than SRX .

Tks.

Hello Fernando,

Do you mean that you return the SRX boxes to Juniper and ask them to send you SSG firewall instead ?

Regards,

Hedi

Hi Hedia,

Yep, Juniper replaced two SRX240 by two SSG350M with an additional 8-port Ethernet module.

Tks.

Update from two months ago, I am a customer with Government.  We have many SSG and ISG firewalls all managed by NSM (which works very well).  After over 4 months with juniper tech support and over 2200 minutes logged on phone calls to juniper we gave up.  Juniper acknowledged that the problems cannot be resolved between NSM and SRX  and  clustering SRX.  To junipers credit they gave us two SSG320m and two 8 port gig modules.  In the future Juniper will be releasing a new product to replace NSM, it is suppose to be able to manage both netscreen and junos product lines.  Netscreen does everything we need, I hope Juniper will provide a long support time for the SSG & ISG products I have but nothing lasts forever.  We were a Check Point shop before Juniper and we may have to go back if the netscreen line ends.  The Junos OS appears to have much more flexibility however we are not the CIA, NSA or any other super security type of department.  Netscreen provides the basics we need; firewall, VPN and DMZ zones all with good logging, keep it simple Juniper.

Hello,

 @Badger

If I should rate your comment, I will give you 5 stars !!

I have exactly the same feeling as you !!

Regards,

Hedi

@Badger

I completely agree. I cannot see the point in beta testing the SRX's for juniper when the SSG range does everything I want and takes like 25% of the time to setup.

I do like JunOS, and if they were to fix some of the major issues I would have no problems using them. But I run a small IT business and don't have time to deal with **bleep**ty products that require me to log a support ticket for every issue.

My main concern is the stability of the devices. I have a couple of SRX210s for testing and I still find that PPPoE is unreliable. It seems whenever the connection drops for whatever reason the Juniper doesn't reset the sessions or connections properly and nothing routes. Normally a "restart routing" fixes it.

I logged a support ticket about it many months ago, Juniper logged into the device and where unable to see anything wrong. I have tried ever different configuration I can think of (and external modem, mini-pim module etc). I would have spent probably 50 hours looking at it. I was still having this issue in 10.1r2. I've just upgraded to 10.2r2, so we'll see how that goes.

The device also takes soooo long to upgrade compared to the SSG range. This is mainly because the SSG was a nice small firmware package. While JunOS is this massive BSD operating system that takes up heaps more space. The SRX can still take 10 minutes to boot up and finally see the ADSL module.

No local IP pools makes setting up VPNs even slower.

The web interface is like 100 times worse than the SSG interface. Crappy slow AJAX style thing that looks like a 12 year old designed it. Fix it now, it is unusable even in 10.2.

I really don't know what else to say. It is nice to finally have some flow IPv6 in 10.2, but the SSG did that too!!!

I think Juniper should have left the SRX branch devices for another generation.

For example an SSG 5 with Gig would be awesome. I also like the wireless options the SSG5 & 20 had. Now you need to buy yet another box.

Juniper seriously you guys need to do some major work on the lower end SRX devices before anyone would want to use them.

Hi

>>>>>>>>>>>>>>>>>>>>>My main concern is the stability of the devices. I have a couple of SRX210s for testing and I still find that PPPoE is unreliable. It seems whenever the connection drops for whatever reason the Juniper doesn't reset the sessions or connections properly and nothing routes. Normally a "restart routing" fixes it.

Can you pls try to configure the "set interfaces pp0 unit 0 pppoe-options auto-reconnect 120" in CLI and pls check whether PPP automatically reconnects without restarting of routing.

Your input is very important for us to understand in details.

thanks

Shashi

Hi Shashi,

Thanks for the reply. It is currently set to 

auto-reconnect 1;

I can try changing it.

The interface comes up and has an IP address, I can even ping the ISP default gateway but nothing else.

regarding pppoe, does it work sometimes or did it never work ?

(ie nothing can be reached except the other end of the ppp).

do you try to ping from the srx itself or from a device in the lan ?

Oh no it works *most* of the time but if there is ever an ISP issue or something and the PPPoE connection drops, once it reconnects you can only ping the ISP gateway on the SRX. Nothing else.

Sometimes you can ping the ISP gateway from the LAN, which is odd. But a restart routing fixes it and I didn't have the issue with my SSG5.

No idea.

---

@mwdmeyer wrote:

@Badger

 

My main concern is the stability of the devices. I have a couple of SRX210s for testing and I still find that PPPoE is unreliable. 

...

 

I was still having this issue in 10.1r2. I've just upgraded to 10.2r2, so we'll see how that goes.

---

Did upgrading to 10.2r2 help with PPPoE stability? I'm looking at the SRX line to help consolidate (e.g. remove) a tier of Cisco ISR routers doing nothing but PPPoE emulation. If the SRX cannot perform this function, that would be a huge problem for us.

@CrytpoManiac

It hasn't dropped out yet (so it has been up 2 weeks).

Sometimes it might last a few weeks though. So I'll let you know if it does it again.

Well, even the Cisco ISRs drop connections at that interval, so that's not too bad 🙂

---

@FernandoSilva wrote:

Hi,

 

We changed an initial SRX customer project by SSG and the customer is very happy.

It's clear that SSG has more features and it is stable than SRX .

Tks.

 

---

With all due respect, saying that one customer prefers a SSG over a SRX hardly means that the SSG has more features and is more stable.

mawr

Hi,

I did not say that the customer prefers a SSG over a SRX means that the SSG has more features and is more stable.

I said that the customer is happy now with SSG because he saw SRX cluster instability in 9.6 and 10.0. What should I say to the customer? "Oh, I'm sorry, but lets wait until Juniper solves this cluster problem" if SSG clustering works very well!!!

And talking about features, how can i implement link failover in a SRX cluster? Using a f!@#%$%¨$% JUNOS script???

C'mon, with SSG I can implement link failover in just one minute!!!

Sincerely, as a Juniper partner, we are very disappointed with SRX family.

Tks.

Hedi:

If you don't mind, can you list the JTAC cases too?. I'll

ensure that most of the cases you have listed are

addressed.

thanks

So three things that I think are just retarded on the SRX platform:

1> Destination Nats require you to create a destination nat pool.  Why?  That is often just a duplication of what I have already done via address books.  If the destination is a private host in the target zone, then why can't I just declare it like:

set rule-set rs1 rule r1 then destination-nat address-book address <addess book entry>

or something similar.

2> So far I don't see any way to add terms or port ranges to dnat rules.  I have a post in the forum right now about it:

http://forums.juniper.net/t5/SRX-Services-Gateway/Ideas-on-Destination-nat-ing-a-large-number-of-ports/td-p/53040

3> No easy way to create large tables of IP's (i'm talking in the 1000's)  to block against.  The prefix-list method is clumsy at best.  Removing the "then accept" at the end of a filter, editing the filter for prefix-list rules, then reapplying "then accept" to the last rule is just outright retarded. 

http://forums.juniper.net/t5/SRX-Services-Gateway/How-to-handle-blocking-massive-ranges-of-IP-s/td-p/52750

Say what you want, but our SSG (and our Checkpoint and Cisco products for that fact) were way simpler, way more stable, and easier to work with. 

Around Aug 14 I had posted our issues on a pair of SRX 650's and SRX 3600's, used

at the University of Waterloo, for main campus wireless NAT, and data centre firewall.,

respectively.

The pair of 650's have been problem free since about April 27, after upgrade to  10.0R3.10.

The pair of 3600's have been essentially problem free since about Aug 19, after upgrade to 10.0R3.10

We use stateful firewall and/or NAT features only. 

I say "essentially" for the data centre firewall, as we twice we cannot figure out protocol/timeout

issues between specific clients/servers where traffic passes through firewall.  e.g. we set "allow all" in both

directions, set timeouts to infinite or very long, turn off strict tcp checks, and still issues, until we

move host outside firewall, or move everything to same side of firewall.   Wireshark will show tcp

session breaking and re-establishing.  But hundreds of other servers, and thousands of services working fine.  

One such issue appears to be Microsoft RPC, we've been advises there is protocol awareness in a later

version.   We just moved hosts as we don't want to upgrade right now.  Another issue was Hirsch door

controllers, we never opened a case, and moved host.

What might help is something like Cisco ASA "TCP Bypass" which I understand to blindly

forward traffic with no protocol, sequence, or any other checks, when configured.  This could

help immensely to prove/disprove firewall is issue when needed.

Regarding Cisco ASA "TCP Bypass," couldn't you use packet-based processing instead of flow-based processing?

I've never used it or needed it myself, but it sounds like what you're looking for?

Bruce,

fwiw, in our testing, JunOS 10.2r3 works well w/ MSRPC applications such as Exchange and AD replication. JunOS 10.3r2 has been promised to have the same stability. As none of the features in 10.3 are all that compelling to us, we're sticking with 10.2r3 as the "go to" release for now, and we'll likely move to 10.4rx (1 or 2 depending on how brave we feel :)) as the next "go to" release when that has been released.

It's not been all that long for 10.2r3. So far, it's been stable. 10.2r2 was stable w/ regards to clustering, it just had some massive ALG issues and an annoying memory leak in web filtering.

I have to say I'm going to pile on the list of SRX complaints.  We have been / were a Netscreen shop for YEARS prior to the Juniper acquisition.  The ScreenOS devices have been generally rock solid since the Netscreen 5 days when that little hummer would bring a Cisco VPN 3015 to it's knees @ 10 Mbit 3DES IPSEC throughput.

A year ago, we were forced into a refresh cycle for our edge firewalls and VPN endpoints after an internal IT consolidation.  We had a bake off between SSG, SRX, and ASA.  SSG won for stability and required features, but lost out because we feared Juniper would effectively abandon the line within 3 years.  SRX won for overall feature set, but lost out because it couldn't handle a simple firewall with NAT deployment at 9.6x code without core dumping every week or two during the evaluation.  The ASA won by default, but it's a descendant of the PIX and still loaded with the crap that made me hate it 10 years ago.

The refresh cycle was Juniper's to win as the incumbent, but lost due to a combination of SRX instability and aggressive SRX marketing that made us fear the long term viability of the ScreenOS line of firewalls.  We felt that ScreenOS would rapidly turn into Juniper's CatOS, Cisco's redheaded stepchild switching OS.  As an aside, since we were painted into the ASA corner, I was forced to refresh VPN with ASA in lieu of the superior but more expensive Juniper Secure Access solution.

I hope that Juniper gets the SRX right, and sooner rather than later.  Rant mode off...

New to the SRX family as of 1 month ago.

We had a project deadline in which we were going to deploy our first SRX firewall. I thought "no big deal, it's a firewall... packets in and packets out. I'll have it configured in a few minutes and be done with it." After hours of being amazed at how bad the user interface is and how non-intuitive the SRX is I scrapped it in favor of an SSG20.

I'm now back to the SRX (which is to replace to temporary SSG20) and my frustration continues.

The ScreenOS was fast and intuitive, the SRX GUI "looks good but doesn't do crap".

My latest battle is figuring out how to create a MIP, now referred to as a static NAT, which apparently is not possible in the GUI? Amazing, it's the second most used thing in a firewall, after policies, and it can't done in the GUI? It use to be a one line config item, but now requires 4 lines of code? Is anyone at Juniper paying attention to how they are screwing up what was an awesome simple to use firewall and turning it into something that only a specialist will be able to configure?

My latest mindset is to just forget EVERYTHING I know about ScreenOS and start all over.

I honestly hope my hatred for this product goes away since I'll be stuck using it going forward.

The first Netscreen we got (about 10 years ago) took me under a day to figure out and setup everything we need a firewall to do, and that was without having 15 KB articles opened up.

This document pretty much explains why I don't like it. Anything that took 1 command line to do now takes 3-4...

http://www.juniper.net/us/en/local/pdf/app-notes/3500152-en.pdf

Juniper, here are tips to making your product better:

1. make the GUI more useful, intuitive, and faster (focus on more useful first )

2. make the commands simpler

You must be on an old version of code. Static NAT was added to the GUI. I recommend to move to JunOS 10.2r3 and go from there. Once 10.4 is stable, it'll be the next "go-to" release. 10.4r2, maybe. Time will tell.

I like the way the SRX is structured. Coming from a programming background, the indented way that the config is built is intuitive. I like commit. I LOVE rollback.

However, there are also a lot of gotchas. I don't love cluster management, not at all. I want my flow-based QoS back. I want my "multiple proxy IDs" from ScreenOS 6.3 back. I want the ability to run dual-ISP with static routing back. The list goes on.

In the end, it's a matter of seeing that the features you need are there, and if that's the case, then the SRX provides a very fast, very affordable firewall platform: Which, ever since 10.2r3, is also reasonably stable. Ongoing UTM drama notwithstanding.

Getting comfortable with the CLI will be a boon to you.

Thanks for the info re: static nat. I am on an older version (10.0r2) and have been working on gaining access to the downloads so I can update it. Hopefully by the end of the day I'll be running 10.2r3 or later.

You'll see a big difference. 10.0r2 was no fun at all. Not only is J-Web slow, it's also not a stable build. 10.2r3 will treat you a lot better.