Sonicwall VoIP via VPN issue
This is a blatant duplication of a post that I've made elsewhere but I'm tearing my hair out without finding a solution. I feel like the answer is probably painfully obvious to someone with more Sonicwall experience than I have so here I am.
I've been sifting through other discussions on VoIP via an IPSEC, both in the Sonicwall community and elsewhere, for the last few days but haven't found a solution for my issue yet.
I have a new customer with a Sonicwall SOHOW in their office. Sonicwall's aren't something I have a lot of experience with but when they asked to put in a VoIP set for a remote employee, I figured using a 2nd SOHOW was a good option rather than make both ends something different. After all, and IPSEC tunnel is a simple matter right?
Since the new unit has to be shipped across the country, I set up the SOHOW in my office and created an IPSEC tunnel to a Netgate/pfSense unit that I had on hand. I configured the Netgate to act as the main office thinking that I will only have to change the Phase1 when I ship out the SOHOW. I have done many site-to-site VPN's that include VoIP using other firewalls. I'm pretty good with the subject matter, but inexperienced with Sonicwall. The idea was to have both LAN's here on the bench, set up IPSEC IKEv2 and configure the VoIP set to connect to the PBX, also here on the bench, along with the other VoIP sets destined for installation in the main office. The PBX will be installed as part of this project and will use FXO to connect to pre-existing lines onsite. There won't be any external VoIP connections or NAT to other providers required.
Main Office (a pfSense for bench purposes)
WAN IP - 10.1.10.1/16
LAN IP - 192.168.1.1/24
PBX - 192.168.1.200
WAN IP - 10.1.2.1/16
LAN IP - 192.168.5.1/24
VOIP Set x1002 - 192.168.5.202
I have a lab subnet in my office set up for testing that is 10.1.0.1/16.
The IPSEC tunnel is set up as a site-to-site in the Sonicwall and seems to be functioning fine. I can access HTTP/HTTPS interfaces of devices on both sides, from either side. TCP and ICMP are flowing as expected. The VoIP set on the remote office side connects to the PBX and registers.
I can make "in-office" calls from extensions on the main office LAN across the tunnel to the remote office phone. I'm able to answer the call on the remote office LAN and audio works in both directions so RTP appears to be OK. As the PBX is still on the bench the FXO aren't connected so call testing isn't an option. For my purposes, inter-office calling should be sufficient for testing.
Here's the rub. All of this works only from the main office to the remote office. If I attempt to call a main office extension from the remote office VoIP set, nothing happens. No ringing, no nothing.
I've been perusing packet capture data, but I'm either not finding anything or I'm not smart enough to see what I need to find.
Enable Consistent NAT: Off
Enable SIP Transformations: Off
IPsec Anti Replay is disabled
Fragmented Packet Handling is enabled
Ignore DF is disabled
Enable NAT Traversal is enabled
I have tested each of the settings above and tested with them in the opposite states although I haven't tested all of the possible combinations.
If anyone has any insight I would greatly appreciate it. Clearly I'm looking in the wrong places and after a few days of poking at this I think I need some fresh eyes to see what I'm missing.
Have you run a packet capture on the 'remote' Sonicwall to see where the VoIP phone traffic is going when making the call? Is there a reason you are using VoIP over VPN? Once the VoIP traffic is encapsulated to flow over the VPN tunnel you lose all prioritization applied to the packets...
I have done packet capture at the Sonicwall, the pfSense unit, and the PBX.
The traffic appears to be heading towards the PBX on the main office side.
When the phone on the remote side powers up, it registers with the PBX. Using the Network Diagnostics in the VoIP set I can ping/traceroute to the PBX. Using the configuration tools in the PBX I can make changes to the remote side phone, reboot it, update it, etc.
Given that this is a small company, with only one remote user, who also needs access to other things in the office, VoIP over VPN to a fresh PBX seemed a pretty straightforward and quick solution given that they have POTS-equivalent lines in the office. I've done this in other instances for small businesses and been happy with the result. The only variation this time, that I can see, is the introduction of the Sonicwall which I admittedly don't have much experience with. That's not to say that I haven't done something stupid somewhere else but since TCP and ICMP seem to be good all that "should" be left is UDP to mess with the RTP, I'm guessing.
When I first set it all up I was able to make internal calls in both directions. Thinking I was all set, I powered everything on the bench down for the night so that I could finish up the testing in the morning. When I powered it back on the next day it didn't work and hasn't worked since.
I've irritated something and it's pretty good at hiding from me.
So at this point do the packets from the phone destined for the PBX get to the Sonicwall packet capture? If so, do they then get to the pfSense packet capture? If so, do they then get to the PBX packet capture?
My point is you need to dig around and find the point at which the packets fail to traverse the connection.
Using the packet capture on the Sonicwall I can see the SIP notify from the PBX to the remote office phone when I call from a main office extension to the remote office extension. The remote office phone rings and calls can be answered. Audio functions in both directions.
There's no indication in the firewall logs that any traffic has been dropped.
When I attempt a call from the remote office extension to a main office extension, I can see the SIP Invite to the main office extension in the Sonicwall packet capture. The packet capture on the pfSense also shows the SIP INVITE and NOTIFY head out to the VoIP sets but they don't ring, the incoming extension call does not show up on the PBX dashboard.
After I cancel the call, the extension that I was dialing in the main office displays a missed call message. Clearly traffic is reaching the PBX but for some reason the inbound call isn't ringing on from the PBX to the main office extension.
I've done all of these steps before but didn't add up 2+2. Duplicating the steps was just what I needed.