• Welcome to SAIL Community Supported PBX . Please login or sign up.
 
October 31, 2024, 11:13:17 PM

News:

SMF updated to 2.0


SRTP TLS

Started by drifting, September 08, 2018, 10:48:25 AM

Previous topic - Next topic

drifting

Hi.

Experimenting as I have been asked about remote phones for a customer, sadly VPN is not an option.

Found a document on you distributors blog:-
https://blog.provu.co.uk/tag/sark/

And pretty much followed what it said to the letter. Have managed to convert the pem I found on the sark box (must have been pre-generated on install) Converted that to DER which the snom wanted and uploaded to the phone fine. Enabled the server auth part. And I can see the cert in the server cert tab on the phone.

No some of the settings seem to equate to an earlier version of Sark? And I was loathed to start fiddling with conf files without knowledge. So in the extensions I have selected TLS SRTP but looking at the asterisk tab in extension I see this at the bottom :- #include sark_sip_tls.conf
Is that supposed to be hashed out?
The settings on identity are :-
Outbound proxy 10.81.0.4:5061;transport=tls
RTP AES80 RTP SAV to Mandatory

At this stage the phone will not connect, and I wonder if there is any further documentation specific to Sark 5 that would help me understand, resolve the problem?

Regards Paul.

sysadmin

I think you may have overcomplicated the exercise.   SARK automatically generates a self-signed certificate when it installs.   Prior to V5 you had to do it yourself which is probably what the document is referring to.

It is not necessary to load anything into the Snom, it will accept self-signed certs without complaint (as long as you don't turn on tls server verification, which it looks as tho' you may have).

SARK is all set to accept TLS over tcp 5061 in sip.conf.   The hash (#) you refer to is not a comment (asterisk uses ; for comments), sark uses #include to include file fragments into the config, in this case it is including the necessary TLS fragments.

The other thing you will need to do is to open and forward 5061(tcp) in your external firewall and open 5061(tcp) in the sark firewall.

Personally, as long as I knew the phone was coming in from a fixed IP address I probably would just trust the remote IP on the firewall and let it in over regular UDP. One of the downsides of TLS is that if you lose comms with the endpoint, for whatever reason, it won't be re-established until the next registration cycle or the phone is rebooted. 

I would suggest you approach it in steps.  Get the remote phone running on regular UDP first and then move it to TLS.   Throughout the exercise you should use tshark so that you can see packets coming off the phone,   Once you go to TLS you won't be able to see what is actually in the packets but you will still be able to see them arriving and departing.






     


drifting

Thankyou.

Thought I was suffering from wood for trees. Sadly no fixed IP address either, however could probably setup a dyndns for it.

Do I still need to add those items in the phone? Assume I should? Will reset the phone to make sure any duff config I may have added gets wiped.
The settings on identity are :-
Outbound proxy 10.81.0.4:5061;transport=tls
RTP AES80 RTP SAV to Mandatory

Will follow your suggestions and see how I go, thanks again.

Paul.

drifting

Moved on a little further.

Have it working fine on local lan using Sips. Padlock appears when making calls.

I have now changed the settings on the phone to match the external IP of the gateway to the voip. Have opened ports for tcp 5061 on Sark and Gateway.
Set the extension to be remote with the Sark interface.

Not really understanding wireshark, bit beyond my intelligence level. However I captured this with tshark -f "tcp port 5061" -i any :-

459.370668 212.93.89.22 -> 10.81.0.4    TCP 76 pvuniwien > sips [SYN] Seq=0 Win=5840 Len=0 MSS=1460 SACK_PERM=1 TSval=528749 TSecr=0 WS=1

Not registered of course, as I am bound to have missed something.

Regards Paul

drifting

cancel all that!

I found it! I have a typo on the firewall at the remote end. Problem solved.

Thank you so much for the hand holding to sort this.

Regards Paul

sysadmin

Glad you got it work for you.

With regard to dynamic IP addresses, there is a new feature in V6 which makes communication with them safer.   Nothing is ever foolproof but it's worked remarkably well at the Beta sites where we have it installed.