Internet Radios inoperative after firmware update to 7.0.1-5052 on TZ370
Updated firewall at the weekensd and on restart of the firewall all internet radios, (5) were unable to stream or contact their remote servers. All are different brands. No setting changes were made at the firewall only the update. The radios were working fine and connected through different interfaces / VLANs, some through wireless APs and one via ethernet. They do manage to contact to NTP time servers ok. If I connect the radios to the ISP router bypassing the firewall completely then they function normally so the issue does seem to lie within the firewall
I have been struggling with this as I can see nothing in the showing in the system logs. In an attempt to troubleshoot I set up up a spare inteface as a DMZ with no security services running on and connecting directly to the interface through ethernet the radio still fails to connect.
Could someone suggest where I could start to look next before my colleagues lose their sense of humour? As usual I am in a small organistaion and am not a IT guru and as usual a "little" knowledge is a dangerous thing.
Well.. did you try rebooting the radios? :) Sorry, had to ask.
I would run packet monitor on one of the radio's IPs first. Perhaps they can't access DNS? DHCP issues?
@kiwicolin when you say "system logs" and combine that with "not an IT guru" I don't know if you've looked at the TSR or trace logs of the device.
Here's an article that describes how to do so: https://www.sonicwall.com/support/knowledge-base/how-can-i-download-required-tech-support-files-tsr-settings-gui-logs-trace-logs/170503698742108/
If you had a TSR from the pre-5052 version to compare against the current one, you might spot some differences that would be applicable.
In the meanwhile, if it is necessary or essential to get stuff up and running, you should contact Support and prepare to spend some time providing these logs and your explanation.
Thank you guys.
I see nothing in unusual in the packet monitor all appear forwarded, or, consumed for some multicast packets.
Larry I am most certainly not an IT guru. Thank you for your tip and direction to that article.
So contacted support via email.....err anyway...
After packet capture it pointed towards the packets being dropped via Security service policies. Drop code 132 Module 25. This somewhat confused me further as the services were not activated on the DMZ interface that I was using just to troubleshoot the issue.
I attempted turning off the security services one at a time and then re-enabling them after each attempt but the packets were still being dropped. I then worked backwards turning off all the services at once and that allowed the packets to pass and the radios to burst into life.
So I then turned on the services one at a time until the packets were dropped once again, when I went down the list and turned on app control the packets were again dropped so I thought this was it and left that off and enabled the others. But that was not successful again, I eventually discovered I had to leave off both app control and content filter off for the radios to work.
So after hours of hair pulling and staring at various policies and signatures I could not work it out. By pure frustration I tried grasping at straws and anyway I seem to have accidently resolved the issue and it seems to me to have been a bug. I went into "App Control - Configure Settings" and set an Application Control Exclusion Address Object to the DMZ interface subnet, I then went into "Content Filter" and set an exclusion to the DMZ interface subnet there too. Turned back on all the Security Services and the radios continued to work.
The reason I suspect a bug is that the radios now continue to work even when moved back to their original interfaces and VLANS which should not have been affected by changes in the DMZ interface, I can also turn off the exclusions I set on the DMZ interface and the radios continue to work without dropping packets. Whatever the blockage was it has gone now.