Solved No outbound calls via tunnel

[murno1]

Hi,

when calling any number from an extensions which is connected to our internal 3cx server via tunnel, the calls are aborted - but they can be called. Worked for months without any issues and no updates or changes were made. I tried to call ext 179 from ext 127. Local log from WIN 10 client is attached

185.X.XXX.XXX is our external IP

Server and client version 15.5.

Any ideas?

Thank a lot.

 

[AWS2P]

Ext 179 and 127 are behind same SBC ?

is there any good reason you didn't updated to V16 SP4?

 

[eddv123]

Logs will be required then in this case.
3cx.com/docs/collecting-logs-for-3cx-support/

Doubtful PCAP would be any use since you are using a tunnel and most likely TLS for this call but the logging should give a good indication as to whether the tunnel is infact up, and whether the calls make it to the PBX for starters.

 

[murno1]

Ext 179 and 127 are behind same SBC ?
yes
is there any good reason you didn't updated to V16 SP4?
no good reason

82.113... is external ip from user
172.17.140.19 is internal 3cx server ip
Call from 127 to 150.

Thank you again.

 

[JohnS_3CX]

First call * 777 to see if you can hear your own echo (endpoint can establish call to PBX).

Then call * 888 to get a callback echo test (PBX can establish call to endpoint).

Don't bother trying to troubleshoot ext-to-ext if the above fail,this issue should be looked at first

 

[murno1]

First call * 777 to see if you can hear your own echo (endpoint can establish call to PBX).

Then call * 888 to get a callback echo test (PBX can establish call to endpoint).

Don't bother trying to troubleshoot ext-to-ext if the above fail,this issue should be looked at first

*777 and *888 do not work - client says "...declined".

 

[JohnS_3CX]

Hello,

Ok since you cannot complete the echo test, it makes sense that normal calls also fail.

Let's check from scratch first to see if any client can make calls:

1. Create a new extension, don't change any of its default settings but ensure it has the tunnel option enabled
2. Send yourself a welcome email, and use the provisioning file to provision your client with this new extension
3. Try the * 777 or * 888 echo test again and see if you can get through

If this works then we can look at why your other extensions face issues. If it doesn't we will proceed accordingly.

 

[murno1]

Hi John,

thank you. *777 and *888 also fail with a new extension (same result as above)

 

[JohnS_3CX]

I noticed your transport is set to TCP, can you switch it to UDP and try again?

 

[murno1]

Hi John, UDP is used but it doesn't help

 

[JohnS_3CX]

Disable the tunnel, and reprovision the client but keep it on UDP for now.

Then start a capture on your PBX and open up the client and try to make a call.

Open the capture when you are done testing, and check the Telephony > SIP Flow in wireshark.
You should be able to see what the PBX replies to the client when a call is made.

 

[murno1]

Pretty strange result...

 

[JohnS_3CX]

Can you please confirm your exact PBX and Client version?

 

[murno1]

PBX 15.5.15502.6
Client 15.5.12227.5

 

[JohnS_3CX]

Do you have any local domains configured?

If you go to your extension, Phone Provisioning, and select 3CX Client, what network interfaces do you see under the Network category?

Normally you would see only you private IP and your FQDN

 

[murno1]

I see private IP, FQDN and servername.fqdn

 

[JohnS_3CX]

I suspect the client was given a network interface that is no longer valid, and gets declined for including it in the invite.

Which one was selected originally and can an external entity resolve it? is there a reason you have servername.fqdn?

 

[murno1]

I tried different network interface settings. IP is originally selected. When i deavtivate 3cx tunnel and activate SSL-VPN it works as usual...
What confuses me is, that it worked for months without a single issue and without any change it is broken now

 

[JohnS_3CX]

Ok your VPN probably works because it makes you appear local to the PBX (and this makes sense, if it bypasses your firewall).

Also. when you check different interfaces, the app needs to also be reprovisioned each time otherwise the settings will not be affected.

By the way what is "servername.fqdn" ? Do you use local FQDN in your internal network? If so does that resolve to the internal IP of your PBX machine?

 

[murno1]

In fact this makes sense.

By the way what is "servername.fqdn" ? Do you use local FQDN in your internal network? If so does that resolve to the internal IP of your PBX machine?

yes, it is resolved to the internal ip of the pbx