[SOLVED] Tcptls.c: Unable to connect SIP socket to error for addresses outside those known to be configured

I am seeing these errors being reported in /var/log/asterisk/full:

ERROR[29058] tcptls.c: Unable to connect SIP socket to 192.168.2.21:62119: Connection timed out
ERROR[29088] tcptls.c: Unable to connect SIP socket to 192.168.0.10:49236: Connection timed out

The difficulty is that I am unable to find where these two IP addresses are used in the FreePBX configuration. We do not use any IP addresses from 192.168.0 or 192.168.2 anywhere on out LAN that I am aware of. Nonetheless the addresses are in the astdb.sqlite3 database:

find  /var/lib/asterisk/astdb.sqlite3* -type f -exec grep -l 192.168.2.21 {} \; | sort
/var/lib/asterisk/astdb.sqlite3
/var/lib/asterisk/astdb.sqlite3.202004250000
/var/lib/asterisk/astdb.sqlite3.202004260000
/var/lib/asterisk/astdb.sqlite3.202004270000
/var/lib/asterisk/astdb.sqlite3.202004280000
/var/lib/asterisk/astdb.sqlite3.202005060000
/var/lib/asterisk/astdb.sqlite3.202005070000
/var/lib/asterisk/astdb.sqlite3.202005080000
/var/lib/asterisk/astdb.sqlite3.202005230000
/var/lib/asterisk/astdb.sqlite3.202005240000
/var/lib/asterisk/astdb.sqlite3.202005250000
/var/lib/asterisk/astdb.sqlite3.202005260000
/var/lib/asterisk/astdb.sqlite3.202006030000
/var/lib/asterisk/astdb.sqlite3.202006100000
/var/lib/asterisk/astdb.sqlite3.202006110000
/var/lib/asterisk/astdb.sqlite3.202006120000

And yet

# dump astdb to text file
sqlite3 /var/lib/asterisk/astdb.sqlite3.202006120000
SQLite version 3.6.20
Enter ".help" for instructions
Enter SQL statements terminated with a ";"
sqlite> .output astdb.txt
sqlite> .dump "astdb";
sqlite> .quit

# returns nothing.
grep -n 192.168.2.21 astdb.txt
# likewise returns nothing
find  /tftpboot -type f -exec grep -l 192.168.71.21 {} \; | sort
# ditto
find  /etc/asterisk -type f -exec grep -l 192.168.71.21 {} \; | sort

Where are these addresses coming from?

just to note , periods need to be escaped when grepping, . alone matches any single character.

but the sqlite3 only carries the machine ‘state’ so look in /var/log/asterisk/full for ephemeral tranactions

grep "192\.168\.[02]\." /var/log/asterisk/full*

rasteridk -x 'database how'|grep "192\.168.\[02]\."

to ascii-ize sqlite3 asteriskdb

Point taken.

I know that the IP addresses I seek are in /var/log/asterisk/full. That is what started the search.

What I am trying to discover is from where they originate in the system. These are not address blocks that we use or have ever used. So why is Asterisk trying to make a connection to them? Is there any other place where Asterisk stores state having to do with endpoints. This looks like a heartbeat but we never had any endpoints as those addresses.

then for 'context 'add

grep -C 4 (es aped expression)

it will print the few lines around the event, turn on sip debugging for that ip if they happen more than once or twice, or sngrepthen filter for a few hours the headers will reveal the apparent sender

Is the implication that these messages are the result of something attempting to connect to asterisk from those addresses?

Thank for the suggestion. It never occurred to me that Asterisk was replying to a request using those addresses because they do not exist inside our firewall. But that is exactly what is happening.

I must make clear that we user separate users and devices instead of extensions. Each user has a local handset and a remote softphone device configured for their account.

I found this in the debug listing:

<--- SIP read from TLS:70.51.2.20:62119 --->
OPTIONS sip:harte-lyne.ca SIP/2.0
Call-ID: 5dfe1fefb4023c0b247cd59472f34d6f@0:0:0:0:0:0:0:0
CSeq: 654 OPTIONS
From: "Remote" <sip:[email protected]>;tag=7e6d6748
To: "Remote" <sip:[email protected]>
Via: SIP/2.0/TLS 192.168.2.21:62119;branch=z9hG4bK-313135-446a3d02ced77c4778ee7548183f1eb8
Max-Forwards: 70
Contact: "Remote" <sip:[email protected]:62119;transport=tls;registering_acc=harte-lyne_ca>
User-Agent: Jitsi2.10.5550Windows 10
Allow: INFO,UPDATE,OPTIONS,MESSAGE,BYE,REFER,SUBSCRIBE,ACK,CANCEL,PUBLISH,NOTIFY,INVITE
Allow-Events: refer,conference,remote-control,presence,presence.winfo,message-summary
Content-Length: 0

So now my question is: where is Via: SIP/2.0/TLS 192.168.2.21:62119;branch= coming from? The 90000 series endpoint are remote softphones.

192.168.2.21 is presumably the private LAN address of extension 90016. That is normal – the extension is not NAT aware and doesn’t need to be, because FreePBX will handle the NAT traversal. To do that properly, Rewrite Contact and Force rport for the extension must both be Yes.

I am looking at the device page and the user page in the FreePBX gui for one of the remote users involved and I cannot find anything refering to Rewite or rport.

I’ve never used Device and User mode and know nothing about it. But I’d expect the page for 90016 to have an Advanced tab with those settings.

This is what the Advanced tab on the Device application page has:

Advanced

Change To CHAN_PJSIP Driver
DTMF Signaling  RFC 2823
Can Reinvite  No Yes nonat update (No)
Context  from-internal
Host
Default User
Trust RPID No Yes (Yes)
Send RPID (No)
Connection Type (Friend)
Session Timers (Accept)
NAT Mode
Port
Qualify
Qualify Frequency
Transport
Enable AVPF No Yes (No)
Force AVP No Yes (No)
Enable ICE Support No Yes (No)
Enable rtcp Mux No Yes (No)
Enable Encryption No Yes (SRTP only)
Video Support No Yes Inherit (Inherit)
Call Groups
Pickup Groups
Disallowed Codecs
Allowed Codecs
Dial SIP/90016
Account Code
Mailbox
Voicemail Extension
Deny
Permit
Emergency CID

Extension Options
Internal Auto Answer
Disable Intercom
Intercom Mode
Enabled Disabled

DTLS
Enable DTLS
Use Certificate
DTLS Verify
DTLS Setup
DTLS Rekey Interval

Sorry, I was assuming it was pjsip. For chan_sip, NAT Mode should be Yes (force_rport, comedia).

Yes. The two users involved both had NAT set to No. I went through the rest of the devices and found two other cases. All four have been rectified.

All the other remote devices had NAT set to Automatic Force Both (auto_force_rport,auto_comedia) so that is what I used for the four.

Thank you very much.

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