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@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@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
On Nov 12, 2024, at 4:03 PM, dries--- via sr-users sr-users@lists.kamailio.org wrote:
(Snip) INFO: {1 600000 SUBSCRIBE 319937814-5062-3@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@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
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
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@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@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
... (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@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@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@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
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
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
Thanks Daniel! Setting a contact alias does indeed look better instead of having to modify the behavior of the client.
Cheers, Dries
-
Daniel-Constantin Mierla -
dries＠degendt.com -
Fred Posner -
James Browne