We run sonicwall at my work. Our old sonicwall finally died (psu), so we had to purchase a new one http://www.sonicwall.com/us/products/TZ_210.html In between the sonicwalls, we used a dsl router for the day and 1/2 we had to wait for our new device. Anyway, I had a problem with the install. I followed the directions step by step, which resulted in slow lan and wan speeds. The network was sluggish to say the least. I left it alone for about 15 minutes thinking the sluggishness was due to network adaption, but even after the long wait performance was the same.
Working with the sonicwall knowledge base and my fellow techs didn't resolve the issue. One thought came to mind. Change the LAN network id from 192.168.10 (the nid we used previously on the old sonicwall) to 192.168.1 Surprisingly that did work. I'm not sure why, but after the nid change, network performance was excellent.
Discussion on:
View:
Show:
When you set the internal network address space, scripts should handle altering all related rules. It sounds like changing the nid effected only that id.
BTW I have found that a lot of the hardware of this sort, routers with a lot of firmware (especially home built systems like dd wrt) needs to be restarted after making changes like subnet, even when no restart is (supposedly) needed.
In fact not a few times I have had to make the same change, and restart to get it to stick, more than once.
I also learned the hard way (with a much older sonic wall, a good while ago) that sometimes making a simple change in settings actually screws up the firmware and can look like it should work, but doesn't. In these cases there's no way to trouble shoot, the settings are 'lying' to you.
A reset to factory setting almost always cleared that up, in fact the only routers I've seen bricked were running dd wrt. Point being, I don't hesitate to go for the reset button early on in troubleshooting these things. Saved me a ton of headaches over the years.
Don't rule out just wiping the settings and starting over from scratch, especially if you've triple-checked all the settings and everything looks as it should, but it's just not working.
BTW when I get the call I put in a smoothwall, running on older but more robust computer hardware that can usually be had for free, it has tons of overhead in every department; load balancing, filtering, DNS cache etc.
Put smoothwall on a P-4 with 512 mb ram and a few gigabit NICs and you're on your way to the triple crown. One big advantage is the hardware is "user serviceable" as they say, you normally don't brick an entire computer.
It's a great way to utilize that stack of 40 GB hard drives on the shelf, too.
BTW I have found that a lot of the hardware of this sort, routers with a lot of firmware (especially home built systems like dd wrt) needs to be restarted after making changes like subnet, even when no restart is (supposedly) needed.
In fact not a few times I have had to make the same change, and restart to get it to stick, more than once.
I also learned the hard way (with a much older sonic wall, a good while ago) that sometimes making a simple change in settings actually screws up the firmware and can look like it should work, but doesn't. In these cases there's no way to trouble shoot, the settings are 'lying' to you.
A reset to factory setting almost always cleared that up, in fact the only routers I've seen bricked were running dd wrt. Point being, I don't hesitate to go for the reset button early on in troubleshooting these things. Saved me a ton of headaches over the years.
Don't rule out just wiping the settings and starting over from scratch, especially if you've triple-checked all the settings and everything looks as it should, but it's just not working.
BTW when I get the call I put in a smoothwall, running on older but more robust computer hardware that can usually be had for free, it has tons of overhead in every department; load balancing, filtering, DNS cache etc.
Put smoothwall on a P-4 with 512 mb ram and a few gigabit NICs and you're on your way to the triple crown. One big advantage is the hardware is "user serviceable" as they say, you normally don't brick an entire computer.
It's a great way to utilize that stack of 40 GB hard drives on the shelf, too.
we rebooted the sonicwall device a few times, but that didn't fix the issue. I guess changing the network id solved the issue for the reason you gave.
I don't like that the settings can 'lie' to me. :\
Before you reset to factory settings, do you make a backup of the current sonicwall settings, reset to factory, then restore your backup of sonicwall settings? Does that still fix the issue? Or will restoring the sonicwall settings resurrect the problem?
I don't like that the settings can 'lie' to me. :\
Before you reset to factory settings, do you make a backup of the current sonicwall settings, reset to factory, then restore your backup of sonicwall settings? Does that still fix the issue? Or will restoring the sonicwall settings resurrect the problem?
I don't know why backup->reset->restore didn't work, but it didn't. In every case I had to just write down the settings and go back through setup and redo everything manually.
Same problem, solved it by setting up load balancing and using the DynDNS.org as the DNS server for both ISP, no problem, everything works as designed
Was the ARP pinging coming from the ISP's DNS servers?? If not, I don't see how changing to DynDNS, OpenDNS, google etc would help... The packets would still get dropped and the ARP cache purged.
Like @pgit says, this sounds like a different problem. It's not so much about who you use for DNS as whether your ISP sends those ARP requests and if so, where from.
Mark,
Great piece and glad you found resolution for the issue in our knowledge base (KB) library (http://www.sonicwall.com/us/support/2213.html) helpful.
The KB is probably one of our most accessed websites and an amazing resource.
On another note - you are right that ARP can be confusing.
There is a great background info on this issue and the feature you are referring to. It's an extra we added for customers using specific ISP hardware that behaves differently from others. This is something that we added as a courtesy to our customers who used to experience this issue with some ISP gear from Verizon (FIOS).
Please note that our product is a strict firewall and not another router.
Here is a thread in the Spiceworks community that references your issue:
http://community.spiceworks.com/topic/115863-fios-business
When you login here (http://sonicdts.eng.sonicwall.com/update_bug.asp?jobid=82297), you get access to the DTS we created to fix the issue with a workaround on our end for those affected customers, because we want to make sure our products work well for them.
You will see the comments from the developer about this not being a SonicWALL issue. The solution we provided in the KB article is simply aimed at resolving this issue for our customers with specific ISP appliances.
Please feel free to let me know if you would like to discuss further and we'll engage a Senior Support Engineer to reach out to you and take care of this.
Thanks again for the great piece!
Jock Breitwieser
Director Global Public Relations
Dell | SonicWALL
office +1 408 800 JOCK (5625)
Great piece and glad you found resolution for the issue in our knowledge base (KB) library (http://www.sonicwall.com/us/support/2213.html) helpful.
The KB is probably one of our most accessed websites and an amazing resource.
On another note - you are right that ARP can be confusing.
There is a great background info on this issue and the feature you are referring to. It's an extra we added for customers using specific ISP hardware that behaves differently from others. This is something that we added as a courtesy to our customers who used to experience this issue with some ISP gear from Verizon (FIOS).
Please note that our product is a strict firewall and not another router.
Here is a thread in the Spiceworks community that references your issue:
http://community.spiceworks.com/topic/115863-fios-business
When you login here (http://sonicdts.eng.sonicwall.com/update_bug.asp?jobid=82297), you get access to the DTS we created to fix the issue with a workaround on our end for those affected customers, because we want to make sure our products work well for them.
You will see the comments from the developer about this not being a SonicWALL issue. The solution we provided in the KB article is simply aimed at resolving this issue for our customers with specific ISP appliances.
Please feel free to let me know if you would like to discuss further and we'll engage a Senior Support Engineer to reach out to you and take care of this.
Thanks again for the great piece!
Jock Breitwieser
Director Global Public Relations
Dell | SonicWALL
office +1 408 800 JOCK (5625)
First, it's nice to know that someone at SonicWALL takes notice of a blog like this. I also appreciate the link to the discussion on the problems in the USA with a different ISP. Not quite sure why you pointed me at your DTS site but I of course agree that it's an ISP rather than a SonicWALL issue.
- Keyboard Shortcuts:
- Prev
- Next
- Toggle

































