Odd VoIP issue
Jason_W
Newbie ✭
Morning all,
I've got a really odd problem with a site using a TZ470 firewall and BT Cloud Voice services. Pretty much every feature of the service works fine, Phones register OK, calls between Soft clients and handsets are fine, calls from PC/Laptop soft clients to handsets are fine. Calls between handsets though are a problem. The handset rings but when it's answered there is no audio between the handsets. Both phones are on the same VLAN and have IP Addresses on the same subnet. Now if I take one of those phones and add it to a different VLAN and then place a call to the other handset it rings and when you answer it there is audio! To rule out the internal switching I was able to bypass the sonicwall and connect the router direct to the switch VLAN and in this configuration with both handsets on the same VLAN the handsets worked fine (placed a call between extension numbers and upon answering I had audio).
I also tried changing the incoming WAN to VoIP access rule to ANY ANY ANY ALLOW and that made no difference either. I've also tried the test with consistent NAT turned on and turned off, same result, no audio. I contacted Sonicwall at the time and after 90 minutes with them on the phone we were still no closer to an answer.
I've even brought two of the client handsets back to the office and plugged them in to a switch here, which is behind a UniFi UDM Pro, and they also work perfectly. So whatever it is has got to be something to do with the Sonicwall and I'm open to any suggestions.
Answers
@Jason_W
No audio is due to the Firewall not being able to identify and forward Voice related RTP (UDP) Traffic that is received and to be send to the correct end point; because this information is embedded within SIP protocol header using SDP Session Description Protocol and this contains Private Port and Private IP information which bypasses NAT since SIP is an Application Layer 7 Protocol and NAT is a function that works in the Network Layer 3 and Transport Layer 4. Since NAT ignores the SIP header, the Firewall is unaware of the endpoints embedded in the SDP header to apply any translation for RTP (Voice/Video) traffic part.
Recommendation 1: Your configuration of NAT Policy (for port forwarding SIP VoIP) is only suited for the following condition:-
-VoIP SIP Server (Proxy/Call Manager/Registration Server/IP-PBX) is in the LAN and it should be configured as 'behind a NAT Device (here Firewall)
-Ideally with a Firewall your deployment should be based on the following document from BT. This is the least intrusive method (since Firewall doesn't modify the SIP header) and it uses Proxy/IP-PBX
https://help.business.bt.com/euf/assets/cloud_voice/pdf/BTCloudVoiceSIPTrunking_LANFirewallGuide.pdf (Read the Doc and See page 4 of 5 and the topology 'BT Supplied PBX Connected to BT Net Services'
https://help.business.bt.com/euf/assets/cloud_voice/pdf/CustomerFirewallandLANGuide.pdf (see all the port specifications and firewall related recommendation)
-Based on the above article from BT, the NAT Policy/Access Rule for Port Forwarding should be done to the IP-PBX IP Address as the target and it then routes the call to the correct endpoint based on its already established registration database
Recommendation 2: If your VoIP implementation is not supportive of an on-premise SIP Server (Proxy/Call Manager/Registration Server/IP-PBX) because these are provided in the Cloud then you need to delete NAT as its nonrelated/unusable for this topology and enable SIP ALG Application Layer Gateway on the Firewall. With SIP ALG feature the Firewall acts as an intermediary device tracing and translating the VoIP Registration Traffic to and from the VoIP endpoints and the Cloud Server on Network 3, Transport 4 and Application 7 Layers. Though this is safe to implement with the Tz470 and does work fine, we have seen many vendors not supporting this since the Firewall modifies the traffic to readdress for translation as this can cause some vendor provided optional features not to work. More over many vendors host VoIP Services over HTTPS and SIP ALG will not function in such cases.
SIP ALG in SonicOS is implemented at the SonicOS GUi location 'Network/VoIP/Settings/Enabled SIP Transforms'. Tz470 is a Firewall and thus, these traffic modifier features are disabled by default expecting the Administrator to enable it based on the use case and respective topology unlike a router. The latter have these features enabled by default thus it worked when you bypassed the firewall with a router. Calls to and from endpoints within the network doesn't go through the Firewall thus it worked as well. If SIP-ALG (or SIP Transforms) is what you are wanting to setup then Consistent NAT need to be used only if calls doesn't work without it first.
https://www.sonicwall.com/techdocs/pdf/sonicos-7-0-0-0-voip.pdf (See page 12 of 24 (Incoming Calls) and 13 of 24 (Local Calls)
The above document describes how SonicOS SIP-ALG (or SIP Transforms) works in two common topologies.
Hope my suggestions helps to solve your problem.
Many thanks for the response and I'll certainly look at the 2nd part of your answer. Can I just ask if there is any reason you can think of as to why this works perfectly at their other sites behind Gen 6 firewalls? They have a NSA3600 HA Pair at another property and the handsets work fine. I have just logged onto the NSA 3600 to check if SIP Transformations are enabled, and they're not, so I don't know if this is something particular to the GEN 7 architecture. I'll certainly try enabling it though to see if that resolves the issue.
Is the SIP encrypted? If not, this can be analysed straightforwardly with Wireshark.
@Arkwright - I used Wireshark on the handsets when I had them in the office and I am able to playback the conversations fine as well as see the details passing between the handsets. We have someone at the site today so hopefully I can get them to perform the same test onsite with Wireshark and then I should be able to compare a working and non-working file.
I'll also run a full packet capture on the Sonicwall at the same time.
I suggest you run a capture on the Sonicwall for just port 5060 then open it in Wireshark.
You need to pay particular attention to the SIP/SDP packets and look at the "connection information" field.
The "connection information" field in the SDP is the peers telling each other where to send their media streams to. Compare working and non-working calls.
@Jason_W
Did you every get this resolved as I am experiencing something quite similar?
Thanks