[solved] After reboot: tcptls.c: Unable to connect SIP socket to [IP of external extension]:52224: No route to host


I’m using 6.12.65-26 and enabled tls & srtp. In /etc/asterisk/sip_custom.conf I added:


in the extension config I set

transport: tls only
Enable encryption: Yes (SRTP only)

the testphone is a grandstream gxp2110 which connects externally. On the extension settings are:

Sip Transport: TLS/TCP
SIP URI Scheme When Using TLS: SIPS
SRTP Mode: enabled and forced.

Asterisk RTP ports are set to 10000-20000, external extension and fpbx are each behind a nat.

everything works fine, inbound and outbound calls unless I reboot the free-pbx Virtual machine. outbound calls from the extension are still working, inbound calls are failing. the log says:

[2015-03-21 09:24:06] ERROR[1945] tcptls.c: Unable to connect SIP socket to
[IP of external extension]:52224: No route to host

all external non tls & srtp encrypted phones are still working. if i reregister the extension on the phone site everything works fine again.

Registered SIP ‘9881’ at [IP of external extension]:52475

if I expose the external extension in a dmz after reboot I get

ERROR[2274] tcptls.c: Unable to connect SIP socket to [IP of external extension]:45427: Connection refused

I played around with options on the phone like cryptolifetime, symmetric rtp and Use Actual Ephemeral Port in Contact with TCP/TLS but no scuccess.
on the phone Check Domain Certificates, Validate Incoming Messages, Check SIP User ID for Incoming INVITE,Accept Incoming SIP from Proxy Only, Authenticate Incoming INVITE are all set to no.

any ideas, because I’m running out of…thanks!

well, right now it works again without reregistering of the extension.

the first “tcptls.c: Unable to connect SIP socket” appeared at 10:23 (immediately after the reboot) and the last one followed by the “Registered SIP” message appeared at 11:12. so it took the setup 49 minutes (sic!) after the reboot to be fully functional again…

any ideas howto reduce or get rid of this?


Is your firewall running? Sounds like Intrusion Detection been triggered due to TCP traffic. Try turning it off for now (Admin/System Admin/Intrusion Detection).

hello tcom,

yes it’s running, but there are no banned ip’s. the intruision detection is only fail2ban which doesn’t block outgoing traffic and reregistering the phone wouldn’t help. also no logs in the firewall of the host system.

I did another reboot, this time it only took 21 minutes for the phone to be available again…

The question you should be asking yourself is ‘What is doing the port forwarding from the public IP to my Internal IP on port 45427?’

If the answering is ‘I don’t know, it kinda does it by itself’, then thats your problem. You need to explicitly forward the ports.

You need to explicitly forward the ports.

i do port forwarding on the fpbx side, for the phone side the qualify=60 should keep the connection open.

The “Connection refused” message only appears when the external extension is put in a DMZ (otherwise its a “no route to host” message), so maybe the phone blocks the connection? I thougth of a cryptolifetime problem, but setting it to yes/no on the pbx and phone side didn’t change anything.

why does it take 20-40 minutes for the phone to become available again when the qualify time is set to 60?

I’m not sure that will be reliable enough to do. As Rob said, you’ll need a static port forward across your internet router to address. The same also for the rtp port range ( udp).

but without tls it’s working. the unecrypted extensions do fine with nat and are up and running immediatly after a reboot beeing behind the same nat/router…

solved the problem. had to reduce the “Register Expiration” and “Reregister Before
Expiration” times on the phone side. I set them to 10 respectiveley 5 minutes.

the problem is independet from the extension beeing behind NAT or beeing inside the LAN and also occurs after an asterisk restart and not a freepbx restart/reboot.

Hello! Could you please explain more how you solved this problem?
I have the same problem with asterisk.
After asterisk restart TLS clients stop working with same errors.

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