NAT Policy not working properly on VoIP Registrations
joshuamarius
Newbie ✭
I've tested the following scenario in several firewalls including different generations of the TZ and NSA Series, and the problem always occurs.
There are two locations; phones on Location 1 connect to the Server internally (Ex. Phone Server 10.0.0.250) - This location is handled by a TZ 400 (10.0.0.254). Phones on Location 2 have a generic ISP Router with a Static IP, and they connect to Location 1 through an Access Rule allowed only to that IP by the TZ 400; phones connect to Location 1 through NoIP Host Name (Ex: location1.myserver.com).
Phone registrations work fine, however, if you move a phone from Location 2 to Location 1, and add a NAT Policy so that location1.myserver.com points to 10.0.0.250, the phone registers, but intermittently. Sometimes it will register but there is no Audio, sometimes it does not register unless it is restarted and the re-registration takes place. Sometimes there are no problems for hours. It feels like the NAT Policy works, but not always.
There is no DNS Server at Location 1, only the SonicWall. Is there anything else that needs to be programmed into the SonicWall so that the NAT Policy is always active and does not miss any type of packets?
Thanks all.
Answers
"Is there anything else that needs to be programmed into the SonicWall so that the NAT Policy is always active and does not miss any type of packets?"
If the policy is enabled it is active.
Run a packet capture when the issue occurs. Or just reconfigure the phone to use the local address…
When you have many people moving phones or it happening several times a day, this is not a call you want to deal with. It was suggested to add a loopback, so I will be looking into that but it appears that the solutions published by SonicWall are missing something.
Maybe the company should look into softphones if the hardphones are moving so much…
I would suggest a 'loopback' NAT for the PBX public address on Location 1's firewall, then reconfigure all the phones to point to the PBX public address. Then they can move where they want. But my first statement still stands.
I would interpret that "several times per day" as softphones not hardphones. Surely hardphones wouldn't move between sites several times per day.