Internal Extension connecting via tunnel

Status
Not open for further replies.

Tim Mrazek

Free User
Basic Certified
Joined
May 18, 2018
Messages
40
Reaction score
3
I have what seems to be all of my extensions connecting via the 5090 tunnel instead of thinking they are internal. I can get it to use 5060 if I change the 'interface for registration and provisioning' and uncheck 'Use 3cx tunnel for remote connections'. After that they are connecting via 5060. I didn't try just one or the other settings yet, but it seems that the clients or server thinks they are external, when they are not. They are just in a different subnet. Is there a setting I should look at for this?

  • 3CX Version, Enterprise Annual 16.0.3.676
  • Server OS, Debian 9
  • Is the 3CX Server Hosted and where? Local hosted
  • IP Phone Make/Model/Firmware 3CX App
  • Provisioning Method: Local / VPN / STUN / SBC Local
  • Trunk Provider or Gateway Make/Model Twilio
  • Has the Firewall Checker passed: YES
  • Are custom Phone Templates being used: NO
 
Last edited:
Can you please see pinned post regarding information to supply when requesting support and respond back with the details?
 
Can you tell us how your network is configured on your 3CX and what network your clients are on?
 
Server is a virtual machine in one subnet and the clients are on seperate subnets in the same building. There is only one router in between them.
 
The 3CX apps always use the tunnel by default, even internally. You can use split DNS to make it local but it will still use the tunnel unless disabled.
 
"Connect Remote 3CX app Users - The 3CX apps for Windows, Mac, iOS and Android have a built in tunnel that will be used automatically when the 3CX app detects it is not on the LAN. "

Its probably your different subnet throwing it off if its not your INT IP or EXT IP/FQDN.

Is it causing issue?

You could make an interal DNS Zone file for 3CXFQDN to point to the INT IP of your 3CX? Assuming your subnets can talk to one another.
 
  • Like
Reactions: Evolute IT
The 3CX apps always use the tunnel by default, even internally. You can use split DNS to make it local but it will still use the tunnel unless disabled.
Interesting, I was working with my reseller, and they didn't seem to have that same opinion.

I am using Split DNS to point to my internal IP address of the server.
 
"Connect Remote 3CX app Users - The 3CX apps for Windows, Mac, iOS and Android have a built in tunnel that will be used automatically when the 3CX app detects it is not on the LAN. "

Its probably your different subnet throwing it off if its not your INT IP or EXT IP/FQDN.

Is it causing issue?

You could make an interal DNS Zone file for 3CXFQDN to point to the INT IP of your 3CX? Assuming your subnets can talk to one another.
That's what I figured.
As far as it causing issues. We're not sure specifically if it is causing these issues we are seeing, but it was recommended by my reseller to have it not use the tunnel in case it was causing our other issue.

Our other issue, is when queue calls come in to the agents, about 10% of them answer on the app, but they keep hearing the ringing on their headset. The call does 'open' as we can listen to the recordings and hear the caller on the other end.
 
Are we talking about the mobile app, Desktop app or Webclient or a mixture?

Are you saying 10% answer on their mobile apps and webclient/desktop apps still hear the ringing?

You should probably have started your thread with the problem you're experiencing.
 
  • Like
Reactions: Evolute IT
Are we talking about the mobile app, Desktop app or Webclient or a mixture?

Are you saying 10% answer on their mobile apps and webclient/desktop apps still hear the ringing?

You should probably have started your thread with the problem you're experiencing.

Desktop App for all calls. 10% of all calls to my queues are experiencing this problem.

I haven't created a thread regarding my main issue because I am working on it with my reseller. I was creating this thread to understand why the clients would be using the tunnel when they are internally connected. More for my understanding and to maybe address a configuration issue I might have with how clients are registered. Instead of 'treating a symptom' by disabling the 3CX tunnel for the phone\app.
 
Hi Tim,

The tunnel becomes active when the 3CX Client for Windows connects via the out of office registrar:
13308

So if the tunnel comes up then it means the out of office registrar route replied first.

This is not a problem, you should work just fine with the tunnel even internally, even though the traffic will probably reach the server via the internet. If you have local DNS routes to point internally though, the traffic remains local since you fooled it into using the local server IP (and triggering the tunnel as a result).

The above should not pose any problem at all. So what is the actual issue you are facing? just the ringing in the headset?
 
  • Like
Reactions: Tim Mrazek
Status
Not open for further replies.

Latest Posts

Forum statistics

Threads
111,934
Messages
589,821
Members
164,813
Latest member
divdigital