Possible NAT issue - VOIP over PepVPN

Greetings, please be gentle:

I recently completely overhauled my network & put in a new phone system.

I put a Balance 305 in my main office and a Balance-One-Core at my home, so that I could have an easy/reliable VPN connection between my work and home. (same as I had at my old office and home, until the ex took my Balance 380 when she had to vacate the home…)
(I got the dogs, the cars and the house… she took my Balance 380)

The analog phone system was replaced with an Epygi QX50 VOIP server, with Yealink T48s phones.
When I connected the “house” phone at my house, it quickly connected to the server IP over the VPN and even updated the phone.

However, I am having audio problems with this remote phone. I can hear callers, but my microphone audio is not transmitted.

My basic research has identified that this is likely a NAT issue, that audio is being routed one direction but not the other. I am unsure of how to control/route the NAT across a PepVPN

Thank you for your help.

1 Like

This is probably a firewall issue. The audio stream uses different ports than the phone registration. You need to open ports 5060 to 5064 and 10,000 to 20,000 for SIP. Those inbound ports need to be open on both routers for two way communcation.

2 Likes

I’m also having the same issue between a newly installed Balance 380 and Balance 305s/MAX BR1s. I’m in the process of upgrading/consolidating from pfSense routers and Asterisk PBXs at each of my sites to a Balance 380 (7.1.0 build 2287) with FreePBX (14.0.3.6) at my Main Site with just the Balance 305s (7.1.0 build 2287) at my Remote Sites. The pfSense/Balance swap has been completed and network access from each of my Remote Sites to my domain controller/file server at the Main Site over SpeedFusion links have been working great for a month or so. Now I’m moving forward with consolidating the Asterisk PBXs into one FreePBX system at my Main Site.

FreePBX has been configured and SIP phones from each site are able to register to FreePBX over SpeedFusion. My Main Site currently does not have access to the Public Switched Telephone Network so I have an IAX2 trunk between my Main Site and Site 1 which currently has the service (eventually, the Enterprise Session Border Controller will point directly to the FreePBX system). I have phones registered at the Main Site that can call one another and they are able to make calls to and receive calls from the PSTN via the IAX2 trunk to Site 1/ESBC. I also have phones registered back to FreePBX at the Main Site from each of the Remote Sites. However, I only have one-way audio (Remote Sites can hear Main Site but Main Site cannot hear Remote Sites) or no-way audio (Remote Sites cannot hear in either direction). Remote Sites are able to make calls to and receive calls from the PSTN via the IAX2 trunk to Site 1/ESBC but have one-way audio only (Remote Sites can hear PSTN but PSTN cannot hear Remote Sites).

Originally, I had the Firewall settings at each location set for just the Default Rules. Based on the response above, I changed my Inbound Routes at each location to include the settings for SIP and RTP as shown below and ended up with the same results, one-way audio or no-way audio with Remote Sites.

Digging around in my configurations, I went back to the SpeedFusion setup for each peer. The Remote Sites each have the appropriate encryption, authentication, RemoteID/Pre-shared Key, Remote IP Address, and WAN Connectivity Priority settings to establish the peer connections to the Main Site and update routing information. I’m able to log into the phones at the Remote Sites from the Main Site and update the configuration of each phone but still don’t have two-way audio all around.

So, I decided to see what NAT Mode would do. I changed the Main Site SpeedFusion configuration for each peer to use NAT Mode. Voila! I now have two-way audio between the Main Site and each of my Remote Sites because the all of the traffic form the Remote Sites goes through NAT and uses the DHCP address provided by the Main Site. But wait, now I can’t log into any of the phones at the Remote Sites to configure them because all of the traffic is going through NAT and the Remote Site IP addresses are no longer accessible from the Main Site which in turn makes placing calls to or receiving calls from the PSTN impossible. So that solved one problem only to create others. Time to turn NAT Mode back off.

I’m limited on how much I can changed the configurations at the Remote Sites because they are active networks used M-F but I have a spare MAX BR1 Slim that I was able to setup in parallel to test things without interfering with day-to-day business. It is now showing the same symptoms as the Balance 305 and MAX BR1s, can call anywhere and receive calls from anywhere but one-way audio only.

Thoughts???

Rich

The remote sites would not get a NAT through SpeedFusion without using NAT mode. Under Status> Active Sessions - is the RTP session going through the VPN (same as SIP registration) or out the local internet connection?

2 Likes

Ron,

Yes, that is my understanding about SpeedFusion and NAT Mode (though I don’t think it should even be necessary to NAT in this situation).

Here is the screen capture for Main Site- RTP and SIP packets going out VPN interface.

Here is the screen capture for the Remote Site- SIP packets going out VPN interface but no RTP packets.

Both screenshots were taken during the same active call.

It’s not a phone configuration issue because I can swapp the phones back and forth between sites and the issue is always no audio from Remote Site.

The FreePBX Firewall at the Main Site wouldn’t stop the Remote Site phones from transmitting RTP packets, would it?

Rich

With assistance from the original installer of my VOIP system, after months of multiple changes in the Peplink routers, the installers found that the VOIP firewall was the source of the issue of one-way audio across the VPN.

Their short response was that they rectified the problem by adding my remote LAN IP range to the firewall of the Epygi QX50 VOIP server.

I am working on getting documentation of their exact changes.