Softphones sign in but can't initiate outgoing calls over OpenVPN connection

General Help
1

Hey FreePBX community! I’m having some trouble with initiating (but not receiving) SIP calls over an OpenVPN connection, and was hoping someone might have some ideas after hearing the problem and perhaps looking at the Wireshark capture screenshots.

I’ve got FreePBX running in a VM at my office, serving VoIP phones and softphones on the local LAN. I have no issues receiving and initiating phone calls from these devices using a variety of softphones.

However, I’ve been trying to set up remote access to the PBX to allow employees to connect from home, and I’m having a weird issue with initiating calls over an OpenVPN connection running on my office LAN’s main pfSense server. Basically, OpenVPN clients are assigned an IP in a subnet reserved for VPN users (which has been declared as a local subnet in FreePBX), and I’ve given this subnet unrestricted access to the IP address of the FreePBX server in the firewall.

When I sign in a softphone offsite that connects via OpenVPN, it registers successfully with Asterisk, but it can only receive incoming calls (with flawless full-duplex audio) - outgoing calls do not start at all. The firewall is set to allow unrestricted communication from the FreePBX server to the OpenVPN subnet and vice versa, and I am able to access the FreePBX console (and register extensions) with no problems, so I’m totally stumped as to why I can’t initiate calls from the softphones.

I did try connecting a softphone offsite to the PBX without using the VPN, connecting directly via the network’s public IPv4 address with port forwarding, and this actually works perfectly - I can make and receive calls with no problem. Of course, best practice is to not leave the PBX exposed to the 'net, so I’d rather not do this.

So, to summarise, I’m having no problems with:

  • Initiating and receiving calls on VoIP phones on USER VLAN
  • Initiating and receiving calls on softphones on USER VLAN
  • Initiating and receiving calls on softphones offsite on the public internet connecting directly to the FreePBX (public IPv4, port forwarding, no VPN)
  • Receiving calls on softphones connected to the OpenVPN connection

The ONLY problem I have is:

  • Initiating calls on softphones (registered successfully) on the OpenVPN connection.

I have tested this behaviour on Windows (Jitsi, Linphone, MicroSIP), macOS (Linphone, Jitsi) and iOS (Linphone) with identical behaviour everywhere.

Now, to try and actually find the issue, I did WireShark captures of all of the types of calls listed below, which I’ve attached. FreePBX-OpenVPN-PCAPs.tgz (97.6 KB) This can be opened in 7-zip.
For those who don’t want to download the archive with the captures, I’ve made an image gallery showing some data in the WireShark captures. The IPs have been anonymised.

The third image (or the capture file called OutgoingFailureVPN-anon shows the unsuccessful call attempt from the softphone via an OpenVPN client, which results in a bunch of “Fragmented IP protocol” messages that seem to be “reassembled” later… but I don’t know why this doesn’t happen when I successfully receive calls via the same VPN connection. These failed calls don’t show up at all in the Call Event Log. I’m using Chan-PJSIP.

If anyone has any ideas what might be causing this, I’d be really grateful to hear them. Cheers!

Edit: Downloadable packet captures removed due to private data that wasn’t scrubbed. Thanks to Stewart1 for pointing me towards steps to confirm the source of the issue. Basically, reducing the number of available codecs in my client softphone (which made the INVITE packet shorter so that it didn’t need to be fragmented) allowed calls to proceed normally, confirming that the issue isn’t a routing issue, but an issue with the large packets. Temporary solution is to simply include fewer codecs, and permanent solution will be to find out why the fragmented packets aren’t getting through. Perhaps they’re not being properly reassembled on the other end!

2

Is it possible that the local IP for the FreePBX is in the same network as the local IP on the remote phone? This would present this kind of issue.

3

Many things often don’t work right with fragmented SIP packets, so I recommend eliminating the fragmentation (get the INVITE packet shorter than 1500 bytes), at least as a test.

In Jitsi, disable all codecs except G.722 (g722) and G.711u (a.k.a ulaw or PCMU), i.e. turn off G.711a (alaw, PCMA), iLBC, GSM, speex, SILK, and all video.

If this “fixes” the problem, change the codecs for what you prefer e.g. Opus instead of G.722 for wideband.

If not, confirm that it eliminated the fragmentation. Next, I’d suspect a routing issue, provide detail about NICs and network setup.

I was surprised about the Free Mobile (France) caller ID. We also have one of those SIMs; because it’s an excellent deal for roaming. But if you, your trunking provider and/or the PBX is actually in France, please provide details (for example, your Freebox could be altering SIP packets).

2 Likes
4

How about if tried to add manually in PJSIP configuration transport context the following parameters?

external_media_address=VPN IP address (192.168.3.2)
external_signaling_address=VPN IP address

5

TCP (or TLS, but it’s more work) transport are other ways to solve this. Fragmented UDP often seems to be no problem when it’s on your own LAN (I have tested this extensively in a high throughput environment, though I keep crossing my fingers that it will remain true), but when traveling over WAN or VPN links, UDP frags tend to be problematic.

6

Nope, but that’s definitely something I’d been looking for, good suggestion anyway!

7

Sorry for the late reply. I thought that the forum would email me if I received a reply, but apparently I was wrong.

Thank you SO much for taking the time to look at this. I suspected that the fragmentation was causing a problem, but couldn’t think of how to shorten the messages to prevent the fragmentation. I tried reducing the number of available codecs as you suggested (I had to reduce it completely down to one codec), and was successfully able to make calls! I’d prefer a solution that allows for more codecs to be enabled, but at least this gives me a temporary solution, and confirms that routing isn’t an issue (though the OpenVPN server configuration might be a problem).

I’m glad you mentioned Free Mobile, because this tells me that I forgot to anonymise the data completely. :wink: This mobile number is originally for Free Mobile, but has been ported to another provider (despite the amazing roaming deal from Free, the service in France was quite bad for me), it is a number attached to a cell phone that I used for testing and is not part of the PBX system. Fortunately, this system runs through an enterprise-type connection from a business-only internet provider, although we do have a Freebox as a backup connection. (Plus, nicely, the Freebox provides the office with native IPv6 connectivity, which our business internet provider still can’t provide…)

Thanks again for your quick response.

Best,
Sam

8

This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.