I’m trying to register a ChanSIP extension with TLS on port 5161.
The PBX has a self signed certificate.
When registering locally, (against the LAN IP) it works fine. But when trying to register against the WAN IP, it does not register at all. It just says timeout.
I have the following ports forwarded:
5060-5062 (UDP & TCP)
5161 (UDP & TCP)
10k-20k (UDP & TCP)
For testing purposes I tried doing a regular not encrypted registration, and it works fine.
I am obviously missing something…
TL;DR Can’t register externally, but successfully registering locally, using TLS.
Thanks for any tips
Forward port 5061/tcp through your router.
sngrep should show all sip tcp/udp connection successful or not, (it works pre iptables) hence clues as to the failure through your firewall,
(Carefully consider the wiseness of forwarding tcp/10000-20000 to your system
Isn’t it included in:
5060-5062 (UDP & TCP)
That forwards 5060, 5061 & 5062
Yup. Missed the tcp bit when I replied.
Does anyone have ChanSIP TLS behind a firewall with a remote phone working?
Sure, have in the past. Don’t have it setup currently but it worked fine. The remote phone does have the cert and everything loaded into it right?
I do not have anything on ChanSIP under my direct control, but I have set this up for people in the past.
I would second
@BlazeStudios question about the phone having or accepting all the certificates involved.
I’ll be very honest, this is my first time playing with SIP TLS…
All I did was, installed on the same LAN a Micro SIP client, set that it should use TLS and it registered successfully. (I obviously configured the extension on the PBX to use TLS)
Then I tried doing the same thing with a Micro SIP client and a Yealink phone from a remote office. It doesn’t work.
Old memory… I recall something about TCP vs. UDP and that you needed to use signaling on TCP for that to work. I might have dreamt that, though, so don’t waste a lot of time on it if it doesn’t make any difference.
A couple things here.
TLS is a TCP protocol. So you have to have it forwarded correctly for a remote device to work.
Yealink phones, of certain models, have known issues with some certificates, notably LE as issued by FreePBX 14. I’ve posted about it more than once with my findings.
So stick with your known working soft phone to validate the process first. Then work with the Yealink to resolve certificate issues.
Already said that:
Assuming forwarded to the PBX, correct? If so, I can confirm it is correctly forwarded.
Yes I saw that, Thank you. For now I’m using the self signed cert.
Out of habit, I tried two devices.
I feel like I’m missing something simple, but can’t figure what it is…
I managed to get the Phones (Both, Yealink and MicroSIP) to register.
But when I try making an echo test there’s no audio.
Extensions are set NAT = Yes. Transport is set to TLS Only
It seems like it’s trying to negotiate audio with the LAN IP.
I see the below in the log
-- <SIP/64066-00000008> Playing 'demo-echotest.ulaw' (language 'en')
> 0x7f33a00155e0 -- Strict RTP learning complete - Locking on source address 22.214.171.124:12360
[2020-03-03 11:16:24] WARNING: chan_sip.c:4119 retrans_pkt: Retransmission timeout reached on transmission
[email protected] for seqno 2 (Critical Response) -- See https://wiki.asterisk.org/wiki/display/AST/SIP+Retransmissions
Packet timed out after 10431ms with no response
[2020-03-03 11:16:24] WARNING: chan_sip.c:4143 retrans_pkt: Hanging up call [email protected] - no reply to our critical packet (see https://wiki.asterisk.org/wiki/display/AST/SIP+Retransmissions).
== Spawn extension (from-internal, *43, 7) exited non-zero on 'SIP/64066-00000008'
https://pastebin.com/xsAaTFQd or raw version
When registering UDP, audio works fine.
I do see that when doing a call with no TLS, it sets the WAN address as the remote RTP address instead of the LAN address at the beginning of the call.
0x319c070 -- Strict RTP learning after remote address set to: 126.96.36.199:12374
Appreciate any pointers.
This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.