13 Nov
2024
13 Nov
'24
12:03 a.m.
Hi all
I've installed a custom presence_dkfs module
(https://github.com/tombeard/presence_dfks) in an effort to make our Grandstream devices
(connected over TLS) display a server set callforward using Broadsoft's Device Feature
Key Sync.
The module was installed succesfully, but it appears that the NOTIFY upon SUBSCRIBE cannot
be sent over TLS. This part seems to use the default presence module however so I'm
taking my chances here to ask for some advice. I have already disabled verify_certificate
in tls.cfg. The "dst addr: 193.19x.x.x:0" does seem to have an incorrect port as
I should expect 5061?
INFO: {1 600000 SUBSCRIBE 319937814-5062-3(a)BHC.DA.GB.CD} presence [notify.c:1744]:
send_notify_request(): NOTIFY sip:544460@sbctest.tel.redacted.xx via
sip:544460@172.30.61.23:5062;transport=tls on behalf of sip:544460@sbctest.tel.redacted.xx
for event as-feature-event : 319937814-5062-3(a)BHC.DA.GB.CD
ERROR: tls [tls_server.c:1312]: tls_h_read_f(): protocol level error
ERROR: tls [tls_util.h:50]: tls_err_ret(): TLS connect:error:14094410:SSL
routines:ssl3_read_bytes:sslv3 alert handshake failure (sni: unknown)
ERROR: tls [tls_server.c:1316]: tls_h_read_f(): src addr: 172.30.61.23:5062
ERROR: tls [tls_server.c:1319]: tls_h_read_f(): dst addr: 193.19x.x.x:0
ERROR: <core> [core/tcp_read.c:1526]: tcp_read_req(): ERROR: tcp_read_req: error
reading - c: 0x7f6d55b4b360 r: 0x7f6d55b4b488 (-1)
Your advice is most appreciated!
Cheers,
Dries
13 Nov
13 Nov
12:31 a.m.
On Nov 12, 2024, at 4:03 PM, dries--- via sr-users <sr-users(a)lists.kamailio.org>
wrote:
(Snip)
INFO: {1 600000 SUBSCRIBE 319937814-5062-3(a)BHC.DA.GB.CD} presence [notify.c:1744]:
send_notify_request(): NOTIFY sip:544460@sbctest.tel.redacted.xx via
sip:544460@172.30.61.23:5062;transport=tls on behalf of sip:544460@sbctest.tel.redacted.xx
for event as-feature-event : 319937814-5062-3(a)BHC.DA.GB.CD
ERROR: tls [tls_server.c:1312]: tls_h_read_f(): protocol level error
ERROR: tls [tls_util.h:50]: tls_err_ret(): TLS connect:error:14094410:SSL
routines:ssl3_read_bytes:sslv3 alert handshake failure (sni: unknown)
ERROR: tls [tls_server.c:1316]: tls_h_read_f(): src addr: 172.30.61.23:5062
ERROR: tls [tls_server.c:1319]: tls_h_read_f(): dst addr: 193.19x.x.x:0
ERROR: <core> [core/tcp_read.c:1526]: tcp_read_req(): ERROR: tcp_read_req: error
reading - c: 0x7f6d55b4b360 r: 0x7f6d55b4b488 (-1)
Your advice is most appreciated!
Cheers,
Dries
To me, the place to focus on is:
TLS connect:error:14094410:SSL
routines:ssl3_read_bytes:sslv3 alert handshake failure (sni: unknown)
CloudFlare has a decent write up on SNI
(https://www.cloudflare.com/learning/ssl/what-is-sni/) and you want to make sure that for
Kamailio, you’re setting the default client to not verify (verify_certificate = no,
require_certificate = no) as well as enabling a protocol version that all your clients
will allow.
That would be the first thing I’d recommend trying.
Regards,
Fred Posner
10:46 a.m.
Thanks for replying, Fred!
The client default was already set to no verification:
[client:default]
verify_certificate = no
require_certificate = no
This is the TLS config:
[server:193.19x.x.x:5061]
method = TLSv1.2+
verify_certificate = no
require_certificate = no
private_key = /etc/kamailio/privkey.pem
certificate = /etc/kamailio/fullchain.pem
server_name = sbctest.tel.redacted.xx
server_id = sbctest.tel.redacted.xx
server_name_mode = 1
verify_depth = 3
[server:default]
private_key = /etc/kamailio/privkey.pem
certificate = /etc/kamailio/fullchain.pem
verify_certificate = no
require_certificate = no
server_name = localhost
As the Grandstreams are already registering over TLS, I assume that the correct protocol
is already configured. Any other suggestions?
Regards,
Dries
4:04 p.m.
I've another suggestion.
Check what's in in your Record-Route header fields.
On Wed, 13 Nov 2024 at 07:57, dries--- via sr-users
<sr-users(a)lists.kamailio.org> wrote:
Thanks for replying, Fred!
The client default was already set to no verification:
[client:default]
verify_certificate = no
require_certificate = no
This is the TLS config:
[server:193.19x.x.x:5061]
method = TLSv1.2+
verify_certificate = no
require_certificate = no
private_key = /etc/kamailio/privkey.pem
certificate = /etc/kamailio/fullchain.pem
server_name = sbctest.tel.redacted.xx
server_id = sbctest.tel.redacted.xx
server_name_mode = 1
verify_depth = 3
[server:default]
private_key = /etc/kamailio/privkey.pem
certificate = /etc/kamailio/fullchain.pem
verify_certificate = no
require_certificate = no
server_name = localhost
As the Grandstreams are already registering over TLS, I assume that the correct protocol
is already configured. Any other suggestions?
Regards,
Dries
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-leave(a)lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender!
Edit mailing list options or unsubscribe:
4:06 p.m.
... (rest of reply)
If your clients connect to "sbctest.tel.redacted.xx" in the first
place, over TLS, then they verify the certificate against that FQDN.
If you use RR and you have the kamailio IP address in the Record-Route
header field(s), then the clients have to connect to that IP address
using TLS, and then the certificate validation should fail.
As a quick test, do BYEs work from the clients after NOTIFYs fail?
James
On Wed, 13 Nov 2024 at 13:04, James Browne <james(a)frideo.com> wrote:
I've another suggestion.
Check what's in in your Record-Route header fields.
On Wed, 13 Nov 2024 at 07:57, dries--- via sr-users
<sr-users(a)lists.kamailio.org> wrote:
>
> Thanks for replying, Fred!
>
> The client default was already set to no verification:
> [client:default]
> verify_certificate = no
> require_certificate = no
>
> This is the TLS config:
> [server:193.19x.x.x:5061]
> method = TLSv1.2+
> verify_certificate = no
> require_certificate = no
> private_key = /etc/kamailio/privkey.pem
> certificate = /etc/kamailio/fullchain.pem
> server_name = sbctest.tel.redacted.xx
> server_id = sbctest.tel.redacted.xx
> server_name_mode = 1
> verify_depth = 3
>
> [server:default]
> private_key = /etc/kamailio/privkey.pem
> certificate = /etc/kamailio/fullchain.pem
> verify_certificate = no
> require_certificate = no
> server_name = localhost
>
> As the Grandstreams are already registering over TLS, I assume that the correct
protocol is already configured. Any other suggestions?
>
> Regards,
> Dries
> __________________________________________________________
> Kamailio - Users Mailing List - Non Commercial Discussions
> To unsubscribe send an email to sr-users-leave(a)lists.kamailio.org
> Important: keep the mailing list in the recipients, do not reply only to the
sender!
> Edit mailing list options or unsubscribe:
5:35 p.m.
Hi James,
The BYE was indeed broken after the NOTIFY had failed. After some time, it was working
again.
The RR route header did contain the public FQDN though.
After some more tinkering, I finally got it working by enabling the "Use Actual
Ephemeral Port in Contact with TCP/TLS" option on the Grandstream.
This modifies the source port in the phone's Contact header so Kamailio replies to
this one instead of default 5062 (which the phone does probably not allow).
Dries
14 Nov
14 Nov
4:37 p.m.
Hello,
On 13.11.24 15:35, dries--- via sr-users wrote:
Hi James,
The BYE was indeed broken after the NOTIFY had failed. After some time, it was working
again.
The RR route header did contain the public FQDN though.
After some more tinkering, I finally got it working by enabling the "Use Actual
Ephemeral Port in Contact with TCP/TLS" option on the Grandstream.
This modifies the source port in the phone's Contact header so Kamailio replies to
this one instead of default 5062 (which the phone does probably not allow).
such case should be also fixed by using set_contact_alias() in
kamailio.cfg for subscribe -- if I got it right, the contact is
different that what is the source ip/port of the connection, which is
valid is SIP (in such case the server should open a connection to the
contact ip/port when sending requests), but doesn't really work for most
of the UAs, especially if they are behind the nat.
Cheers,
Daniel
--
Daniel-Constantin Mierla (@ asipto.com)
twitter.com/miconda -- linkedin.com/in/miconda
Kamailio Consultancy, Training and Development Services -- asipto.com
15 Nov
15 Nov
4:53 p.m.
Thanks Daniel! Setting a contact alias does indeed look better instead of having to modify
the behavior of the client.
Cheers,
Dries
7
days inactive
10
days old
7 comments
4 participants
participants (4)
-
Daniel-Constantin Mierla -
dries＠degendt.com -
Fred Posner -
James Browne