SRX Services Gateway
Showing results for 
Search instead for 
Do you mean 
Reply
Trusted Contributor
Posts: 330
Registered: ‎01-08-2010
0 Kudos

Re: SSG vs. SRX

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.

 

Highlighted
Visitor
Posts: 3
Registered: ‎08-14-2010
0 Kudos

Re: SSG vs. SRX

 

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

 

 

Technical SupportOpen2010-0728-0203
in-service upgrade unable to complete, cluster not active
UNIVERSITY OF WATERLOO (1-75Z-80)BruceCampbell8/12/2010 5:0:54Support4 - Low
Technical SupportClosed2010-0608-0227
Device Crash
UNIVERSITY OF WATERLOO (1-75Z-80)BruceCampbell7/6/2010 1:13:55Support4 - Low
Technical SupportClosed2010-0518-0576
flows using wrong interface, sometimes...
UNIVERSITY OF WATERLOO (1-75Z-80)BruceCampbell6/4/2010 16:30:15Support3 - Medium
Technical SupportClosed2010-0428-0412
IP Redirects
UNIVERSITY OF WATERLOO (1-75Z-80)BruceCampbell4/29/2010 8:24:33Support3 - Medium
Technical SupportClosed2010-0405-0087
OSPF ABR Routing Issues
UNIVERSITY OF WATERLOO (1-75Z-80)BruceCampbell5/23/2010 23:45:29Support2 - High
Technical SupportClosed2010-0311-0579
Cluster failing
UNIVERSITY OF WATERLOO (1-75Z-80)BruceCampbell8/3/2010 7:31:12Support2 - High
Technical SupportClosed2010-0127-0258
Unable to upgrade firmware on SRX-3600
UNIVERSITY OF WATERLOO (1-75Z-80)BruceCampbell2/17/2010 0:53:5Support4 - Low
Technical SupportClosed2010-0118-0159
DHCP request TTL of 1
UNIVERSITY OF WATERLOO (1-75Z-80)BruceCampbell3/4/2010 10:51:3Support4 - Low
Technical SupportClosed2010-0111-0718
Attempted downgrade leaves SRX210H with u-boot errors.
UNIVERSITY OF WATERLOO (1-75Z-80)BruceCampbell2/17/2010 0:53:5Support4 - Low
Technical SupportClosed2010-0106-0197
Upgrade failed
UNIVERSITY OF WATERLOO (1-75Z-80)BruceCampbell2/17/2010 0:53:5Support4 - Low

Technical SupportClosed2009-1222-0542
IpSec phase 1 not renegotiating / Improper Timers?
UNIVERSITY OF WATERLOO (1-75Z-80)BruceCampbell2/17/2010 0:53:5Support4 - Low
Bruce Campbell
Director, Network Services
Information Systems and Technology
MC 1018
(519)888-4567 x38323
University of Waterloo, Waterloo, ON
Trusted Contributor
Posts: 330
Registered: ‎01-08-2010
0 Kudos

Re: SSG vs. SRX

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!

Contributor
Posts: 93
Registered: ‎05-28-2008
0 Kudos

Re: SSG vs. SRX

Hello,

 

Same conclusion for me !

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

 

Bye

 

Hedi

Contributor
Posts: 16
Registered: ‎05-20-2009
0 Kudos

Re: SSG vs. SRX

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.

 

 

Contributor
Posts: 43
Registered: ‎08-04-2010
0 Kudos

Re: SSG vs. SRX

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. 

Super Contributor
Posts: 206
Registered: ‎03-11-2008
0 Kudos

Re: SSG vs. SRX

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.

Contributor
Posts: 93
Registered: ‎05-28-2008
0 Kudos

Re: SSG vs. SRX

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

pkc
Contributor
Posts: 111
Registered: ‎09-24-2008
0 Kudos

Re: SSG vs. SRX

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.

Trusted Contributor
Posts: 236
Registered: ‎06-11-2010

Re: SSG vs. SRX

[ Edited ]

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

Contributor
Posts: 93
Registered: ‎05-28-2008
0 Kudos

Re: SSG vs. SRX

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

Trusted Expert
Posts: 784
Registered: ‎11-01-2007
0 Kudos

Re: SSG vs. SRX

@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

Contributor
Posts: 16
Registered: ‎05-20-2009
0 Kudos

Re: SSG vs. SRX

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.

Era
Contributor
Posts: 64
Registered: ‎04-06-2009
0 Kudos

Re: SSG vs. SRX

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

Era
Contributor
Posts: 93
Registered: ‎05-28-2008

Re: SSG vs. SRX

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

Contributor
Posts: 51
Registered: ‎09-01-2009
0 Kudos

Re: SSG vs. SRX

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.

 

Fernando Silva
Sales Engineer
JNCIA-EX/ER/JUNOS/WX/FWV, JNCIS-ER/SEC/FWV
Contributor
Posts: 93
Registered: ‎05-28-2008
0 Kudos

Re: SSG vs. SRX

Hello Fernando,

 

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

 

Regards,

 

Hedi

 

Regular Visitor
Posts: 5
Registered: ‎06-25-2010
0 Kudos

Re: SSG vs. SRX

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

 

Trusted Contributor
Posts: 236
Registered: ‎06-11-2010
0 Kudos

Re: SSG vs. SRX


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

Contributor
Posts: 43
Registered: ‎08-04-2010
0 Kudos

Re: SSG vs. SRX

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

 

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

 

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.