SRX5308 Firmware - experiences with stable and unstable versions
Hi
We've been tearing our hair out with numerous versions of SRX5308 firmware and it seems the only stable version we found to date (under a decent amount of traffic load) is 4.3.1-22 which is pretty old.
We've tried 4.3.4-1 and 4.3.3-8 and have experienced random drop outs rending the firewall unreliable and unusable. However 4.3.1-22 is stable but the flip side is that any changes made to the rules don't seem to take affect immediatery, unlike the later unstable versions previously mentioned, and we need to wait 5-10 minutes for the firewall to stabilise.
Would be interested to know of other people's experiences. We do not use any VLANs, just simple WAN1 port with public IP range (/128) and NAT. Firewall ports have been setup in service groups and one IP has one service group rule applied. Very clean and simple setup.
We have 6 of these firewalls and the behaviour seems common to all (we first thought maybe we had a dodgy appliance, switch or cables).
For us it looks like the firmware for the SRX5308 is riddled with issues.
Any thoughts?
Kurt
Model: SRX5308|PROSAFE Gigabit Quad WAN SSL & IPSEC VPN Firewall
Re: SRX5308 Firmware - experiences with stable and unstable versions
Hi advnetops,
With regard to your concern wherein the problem is common to all of the 6 SRX5308 you have and you have already isolated the problem, I advise you to open an online case with NETGEAR Support at anytime. Let them know about your concern and its possible that it will be escalated to the engineering team.
Re: SRX5308 Firmware - experiences with stable and unstable versions
Hi advnetops,
We’d greatly appreciate hearing your feedback letting us know if the information we provided has helped resolve your issue or if you need further assistance.
If your issue is now resolved we encourage you to mark the appropriate reply as the “Accepted Solution” so others can be confident in benefiting from the solution. The Netgear community looks forward to hearing from you and being a helpful resource in the future!
Re: SRX5308 Firmware - experiences with stable and unstable versions
Hi JohnRo
The issue still remains. We will raise a support ticket for this but as the firewall is in a live environment we've had to swap to the older stable firmware (1-22). We have another firewall running the latest firmware (4-1) however it does not have a full /128 subnet of IPs alloctaed to it so it has less rules and traffic hitting it. We can send the config file to support ofcourse for them to run some load tests their end.
Re: SRX5308 Firmware - experiences with stable and unstable versions
I thought I'd post an update in the hope it saves others time trying to sort out stability issues under load..
We are running 8 of these firewalls making heavy use of NAT rules (simple public WAN IP to private LAN IP mappings on certain ports) with /25 (128 IP) and /26 blocks (64 IP) blocks. I think we've finally got to the bottom of the instability issues raised before using a combination of the following:
1) Upgrade to the latest 4.3.4-22 firmware (seems pretty stable)
2) Removing any Services Groups (these seem buggy as hell!)
The downside to not using Service Groups is that we are now having to define a unique firewall rule for each specific port and IP mapping rather than in one entry so it's quite tedious. It seems to me that Service Groups only work if you have a small number of NAT rules.. where you have a significant number (e.g. you have a lot of IPs with multiple ports for each) they become unreliable.. maybe it's an issue with the way these are processed given the modest hardware spec of the appliance?
So before we'd have created a service group like this:
HTTP-HTTPS-SSH-SMTP (for TCP ports 80,443,22,25)
Now we are creating each as a separate rule (in the above example 4 rules for a given NAT'ing) and re-ordering them for "easy administration"
Adding, modifying or deleting a rule used to take a few minutes for us to see this kick in (if it did at all) but now it;s approx 10 secs.
Incidentally, the IP address returned whenever a request is sent on one the the WAN aliases is by default that of the firewall which isn't ideal. After a call to technical support we were told that we couldn't pass back the response from the WAN IP which the request came in on which we have subsequently found to be absolute twaddle. If you want to send back the same IP in the response as the original IP requested (useful for web services for example) you simply set up an Outbound NAT rule and choose the NAT IP you want the response to have come from.
So now that leads me to one glitch in the latest firmware causing real concern. We have found that if we have any outbound service rules when the firewall reboots, it doesn't come back up properly and blocks everything rendering it totally useless. The work around is as soon as you can login to the web interface, disable the outbound rules and then enable them again straight after and it magically starts working! That is quite worrying in the event you need to reboot the appliance as you need to be 100% confident you can login to do this (not that you should have to do so anyway)
Netgear, please look into the bug above.. and ideally fix that issue with service groups too when you have larger IP ranges. If you sort out those two issues this firewall will start to re-gain some credibility because when it actually works it's great.
Kurt
Model: SRX5308|PROSAFE Gigabit Quad WAN SSL & IPSEC VPN Firewall
Thanks for the detailed information you have posted. This will help other community members who might be experiencing the same issue.
About the issue you've found out and its workaround, were you able to report it with NETGEAR Support? Its possible that it will be forwarded to the engineering team for further investigation and a beta firmware might be provided as a fix on the issue.
Re: SRX5308 Firmware - experiences with stable and unstable versions
Hi
No we haven't reported it direct support - is there any link between you/this forum and support and if so can it be passed on?
To be honest we've already spent/wasted a lot of time getting to this point so if this can be forwarded to support that would be appreciated and benefot all users of course.
(Side note: Last time we contacted support we knew more about the appliance than the guy at the end of the phone and the time after that on live chat they basically asked us to do full Wireshark logging and send them the outputs but I'm sorry I don't feel it is a customers job to be testing that in depth - there's clearly issues and we have provided re-creation steps so engineering should look into this if they want to keep the customer base happy.)
Issues on the firmware like this should have a ticket or case logged with NETGEAR Support for I do not have the means of passing this on. NETGEAR Support will be the one to forward it to the engineering team. Getting syslogs or Wireshark packet captures are needed because it will be helpful on the part of the engineering team for them to analyze why the issue occurs and it will lead to a development a patch or beta firmware that would fix the issue.
About having the customer get syslogs or Wireshark packet captures, I understand that it takes time on the customer's part. However, it is possible that the customer could give remote access on the device so that the NETGEAR Support team will be the one to get syslogs or Wireshark packet captures.
Re: SRX5308 Firmware - experiences with stable and unstable versions
UPDATE: I have an update since our last post in that the dropouts are still happening 😞
Not as often now as they were.. perhaps every few hours for 1-2 minutes but enough to cause us a big problem and make the networks unstable... unfortunately we've had no choice now but to swap back to some older Cisco units which are reliable.
Wireshark logs aside the product (hardware and/or firmware) doesn't work reliably and that's something that can simply be replicated by engineering if they so wanted to do so. We have tried lots of different ways co configure the devices with all sorts of permutations turned on or off but we can't get this kit stable and we are not alone judging from the what others have said. For a simple WAN/LAN firewall on a few IPs it might work fine but for lots of NAT rules and port combinations we've come to the conclusion it's not up to the job which is a real shame
