Sonicwall TZ 200 issues

Riccochet

Riccochet

Fully [H]
Joined
Apr 11, 2007
Messages
29,894
Not sure what's going on with this thing. Unfortunately I'm 3 hours away from where it's installed. We put it in place about 3 months ago. It's set to use failover and load balancing. When I installed it I tested the failover and load balancing and everything worked as it should. The past 2 weeks the unit has not been failing over when one ISP drops. This requires a power cycle of unit to get the secondary on X2 to pick up. Data collection is turned off. Probing is turned on for both WAN ports. While both ISP's are up it load balances fine. I was there last week and pulled the patch cables going to the modems and it didn't skip a beat doing a constant ping. Just randomly it takes a shit when one ISP goes down. Takes out the network as well as no internal resources are reachable as well. Can't ping the server from any PC's and such.

It's running an older firmware. 5.5.6 from Nov 2011. 5.8 is currently available. I'm just leery about flashing a new firmware remotely.

Anyone experience anything like this before with these units? We have plenty of 170's and 180's in place that are trouble free.
 
Well I can tell you first thing sonicwall support will tell you to do is flash the firmware. I do it remotely all the time and never had a problem. Backup your settings first just in case. If you're accessing through a vpn you may want to temporarily enable https management on the wan port just in case the vpn doesn't come up right away. I actually have https management setup on the wan port of all my units but only allow the main office IP access.
 
5.56 is a crap firmware this was based on the 4 code. I flash firmware remotley with out issues. the newest firmware is 5.8.1.9.
Also 5.5 worked a lot differently with failover. Sonicwalls don't do LB. Also 5.5 had a serious bug from factory that would try and grab your lans mask worth of ips from the wan to do 1 to 1 mapping. THey left in a bad rule in the firewall when they were testing stuff.
 
Agreed 100% with Wrench, the 5.5.x code is horrible and SonicWALL should be ashamed of putting it into production.

I have found from experience you can do the upgrades remotely without much of an issue. What has worked really well for me is upgrading to 5.6.0.12 as the first jump and then onto the latest revision of 5.8. Sometimes if you jump too far the NAT rules just don't apply properly resulting in a less than ideal 3 hour drive to restore the device. As noted, please backup the config and the firmware version before proceeding but it should be fine.

If that still doesn't work please PM me and I would be more than happy to assist. Might as well make sure of my Master CSSA/CSSP certifications... my current company sure doesn't :(
 
Zetro said:
Agreed 100% with Wrench, the 5.5.x code is horrible and SonicWALL should be ashamed of putting it into production.

I have found from experience you can do the upgrades remotely without much of an issue. What has worked really well for me is upgrading to 5.6.0.12 as the first jump and then onto the latest revision of 5.8. Sometimes if you jump too far the NAT rules just don't apply properly resulting in a less than ideal 3 hour drive to restore the device. As noted, please backup the config and the firmware version before proceeding but it should be fine.

If that still doesn't work please PM me and I would be more than happy to assist. Might as well make sure of my Master CSSA/CSSP certifications... my current company sure doesn't :(
Click to expand...

Yeah I forgot to mention the 5.5 needs to ump to 5.6 then 5.8
 
Thanks for the input. I'm going to schedule this for Wednesday next week. Just in case I have to make the drive I have time.
 
I had a problem similar to this on a TZ210 about six months ago. Logical probing is enabled on each of the WAN links and randomly the targets would stop responding on both links at the same time - taking the unit offline. They were using responder.sonicwall.com.

I upgraded the firmware and changed the failover logic by replacing one of the responder.sonicwall.com entries with 8.8.8.8 and changing the logic to succeed if either probe was successful.

No further issues since. Also, I've never had an issue remote upgrading the firmware on a Sonicwall. In fact, I just did fourteen over the weekend.

Riley
 
You must log in or register to reply here.
Back
Top