Firewall test failed - SonicWall TZ570 (SonicOS 7)

[ArtR]

Hi All,
Recently we updated our firewall from the SonicWall nsa2600 (SW.OS 6) to a smaller TZ570 (SW OS 7) firewall, and even though we could migrate our settings and everything worked, doing a firewall test for other issues has given us Full Cone Test failed errors and trying to see if anyone else was using these new SW firewalls to pass on any settings that may be new and remained unconfigured or in the wrong state after the migration?

So everything still works, calls in and out, remote users etc, with a couple of issues presenting so want to ensure everything else is ok. Current issues, can't reach activation server (although updates are still working), and push calls to Android not working.

I have verified that Consistent NAT is turned on, SIP transformations is OFF. I did note that Source Port remap is ON when using Any on interfaces rather than using specific port names, but changing that around and unticking didn't resolve the issue.

I may just need to do a full redo of the rules to ensure it is done in the way the new firewall likes but any wisdom here would be appreciated.

PBX 16.0.4.504 - Awaiting a new VM host to migrate to WS2019 and apply latest patches.

Thanks
a.

 

[ChrisC_3CX]

I know this specific firewall is not listed in our documentation but do consider taking a quick look in case there are common settings you need to take care of like Source Port remap which needs to be disabled: https://www.3cx.com/docs/sonicwall-firewall-configuration/

I do recommend also making sure that you've saved changed and then trying to reboot the firewall once your done.

Regarding not being able to activate, do note that this is very likely due to the 3CX PBX version you are running as it is out dated. Versions before 3CX v16 SP5 are expected fail activation due to an SSL certificate update.

 

[Alphabetic]

I've had this "problem" on a few sonicwalls and it was down to misconfiguration of the firewall. Follow the guide and the firewall test will pass.

 

[jcostlow]

How did you move configuration?I've seen uploading a backup not work at times and have to use the migration tool where you specify source and destination models.

I would start by checking your NAT policy that rewrites outbound traffic using the public IP and turn off source port remap ping. Also, install the latest firmware as the initial v7 firmware had some quirks.

We have had luck increasing UDP timeout to 300 seconds. Some of the trunk providers have requested it.

 

[ArtR]

How did you move configuration?I've seen uploading a backup not work at times and have to use the migration tool where you specify source and destination models.

I would start by checking your NAT policy that rewrites outbound traffic using the public IP and turn off source port remap ping. Also, install the latest firmware as the initial v7 firmware had some quirks.

We have had luck increasing UDP timeout to 300 seconds. Some of the trunk providers have requested it.

I used the migration tool at mysonicwall. I have done a few migrations in the past without drama so I'm wondering if the major version change 6 -> 7 is the cause. Otherwise, always been able to work out any issues on previous units.

I have checked the outbound but will do again, or just disable my original rules and just redo them again.
Also, just got the unit up to the latest firmware version too.

UDP timeout I think I upped a while back on previous unit, but will check that out again too.
Thanks

 

[ArtR]

I've had this "problem" on a few sonicwalls and it was down to misconfiguration of the firewall. Follow the guide and the firewall test will pass.

I followed the guide on our previous unit and it was OK, and then we migrated to newer hardware/OS, and things aren't right. It all looks ok, but again, the original guide and how it all looks now is worlds apart. I think I may just disable existing rules and start again just in case.

 

[ArtR]

I know this specific firewall is not listed in our documentation but do consider taking a quick look in case there are common settings you need to take care of like Source Port remap which needs to be disabled: https://www.3cx.com/docs/sonicwall-firewall-configuration/

I do recommend also making sure that you've saved changed and then trying to reboot the firewall once your done.

Regarding not being able to activate, do note that this is very likely due to the 3CX PBX version you are running as it is out dated. Versions before 3CX v16 SP5 are expected fail activation due to an SSL certificate update.

I followed the guide on our previous unit and it was OK, and then we migrated to newer hardware/OS, and things aren't right. It all looks ok, but again, the original guide and how it all looks now is worlds apart. I think I may just disable existing rules and start again just in case.

And noted on Activation, will try to get this migrated to the newer version soon. With that in mind, I'm curious to move to the Debian version, but we do save and use the CDR export for our own reporting. Is it possible to share a folder from Debian to Windows without too much drama so we can continue to pull it?

 

[ChrisC_3CX]

I think I may just disable existing rules and start again just in case.

Do let us know how that goes!

Is it possible to share a folder from Debian to Windows without too much drama so we can continue to pull it?

I'm sure there are ways to do this but you might want to consider simply having the CDRs sent to a remote location by either using the active or passive socket described here: https://www.3cx.com/docs/cdr-call-data-records/