Mobile app works over TCP but not TLS

[Felicia King]

Scenario: Mobile app for extensions is configured with WAN FQDN, not local IP.
Devices are on cellular data or guest wireless with internet access and only access PBX through WAN FQDN.
Same extension on iOS and Android work identical.
With extension configured for SIP Transport on TCP, I see the comms between the mobile client and PBX going over 5001 and 5090 as desired using the WAN connection.
However, if I change SIP transport mode on the extension to TLS, the mobile client no longer wants to communicate with the PBX via the configured FQDN. It starts to make calls to the LAN IP of the PBX, which of course it has no ability to communicate with.

I have done reprovisioning of the app many times and tested this on two different iPhones and Android 7 and Android 9. Behavior same across the board.

Therefore, this appears to be a mobile client software bug. When SIP transport set to TCP, the mobile client attempts to communicate to the WAN FQDN of the PBX and everything works.
With SIP Transport set to TLS, the mobile client still uses the WAN FQDN for provisioning traffic over 5001, but then switches to calling the PBX by its LAN IP address for the remainder of communications which fail since there is no IP route to that device from guest or cellular data.

Phones are not jailbroken.

 

[JohnS_3CX]

Hi Felicia,

You will have to disable the tunnel if you plan on using TLS transport, as it is not currently compatible in this scenario.

 

[Felicia King]

Thank you John. Is the mobile app deemed secure over TCP? The advanced training recommends hardening communications by using TLS, so I tried to use it. If the tunnel is disabled, doesn't that break single port comms and cause SBC problems?

I'm trying to get to a secure config, yet one that is interoperable with other use cases such as the app working reliably, remote SBCs, and using the benefits of the reliability of using the tunnel where most of the comms are pushed over a single, reliably configurable port.

What are your suggestions?

 

[JohnS_3CX]

Hi Felicia,

The SBC is not affected or related to the app in such a way, they can operate independently:

• You can setup your SBC with encryption turned on for security of SIP/RTP between your desphone site and the PBX
• You can setup TLS and SRTP for security between your apps and your PBX

The SBC site will use the tunnel port (5090), the apps will use the TLS port (5061) + the media ports that you already have to keep open as per https://www.3cx.com/docs/ports/

 

[Felicia King]

I have configured and tested as you suggest, but there is a completely different problem going on. The problem is that the 3CX app refuses to communicate with the PBX via the configured WAN FQDN. If I watch the packets coming from the mobile phone on a guest wireless network connection that ONLY has access to talk to the internet, the app attempts to communicate with the PBX on its LAN IP and not its WAN FQDN when SIP transport is configured to TLS.
If I configure the app to SIP transport TCP, the app communicates to the PBX over the WAN FQDN.

In my view, this is a software bug because the only thing that is changing are the app settings. The network the app is on is not changing. And no other changes are being made. Further the app configuration for that extension is still specified as the WAN FQDN. So despite the app being configured for WAN FQDN with SIP transport TLS, the app still attempts to communicate with the PBX over the LAN IP of the PBX, which is NOT what is configured for the extension.

 

[Vali_3CX]

You may do the following trick to force the mobile client to use WAN FQDN:
- in the mobile client, open account settings and there delete - leave empty - the "Local PBX IP" parameter, then go back to re-register. Only do not re-provision, it will overwrite your manual changes.

 

[Felicia King]

I did as you suggested. FYI, inside the app the WAN FQDN was specified for local and remote PBX as shown for my account in the app. I modified my extension to have SIP transport TLS, RTP mode only secure, and removed option to use 3CX tunnel for remote connections.
On the phone app, I blanked out local PBX, saved change reregistered. Attempted to make a call, and I still see the packets attempted to be sent to the local IP of the PBX. I checked settings in the app and External PBX is still populated as an attribute value in the mobile app, while local PBX is blank.

 

[Vali_3CX]

In this case, it might not be a DNS server configuration problem? The client makes request to the public FQDN of the PBX, but the DNS resolves it to its local IP instead (which is perfectly OK, but defies the purpose in our case)?

 

[Felicia King]

I thought about that already and checked on that. The DNS servers the phone is getting are public only [image removed by Vali_3CX, contains real public IP]