Verifying call encryption

Go easy… first post. :slight_smile:

I’m looking to make calls via the Linphone app over the internet and need to verify if/how encrypted it is. I’ve been testing with TLS and SRTP with a letsencrypt cert, though calls either hang up or have one-way audio with TLS. Calling via UDP with SRTP enabled appears to work fine, though I’m concerned about the lack of tls.

Does this mean the headers are simply not encrypted but the payload is? What are the real-world risks with that?
Linphone lists the call as encrypted fwiw.

The infrastructure looks like:

iPhone > internet > FortiGate firewall (using SIP ALG) > DNAT to FreePBX VM > Internal SIP trunk to Mitel System.

Mitel then rings internally or out the PRI if necessary.

A snippet of the debug:

<— SIP read from UDP:x.x.x.x:10038 —>
INVITE sip:11355 (at) pbx.example.com SIP/2.0
Via: SIP/2.0/UDP x.x.x.x:10038;rport;branch=z9hG4bK+234f5a05e4a47dfcc27e5876b56efe0f1+s676+1
From: <sip:1901 (at) pbx.example.com>;tag=s676+1+41400001+5ee7f7b6
To: “11355” <sip:11355 (at) pbx.example.com>
Call-ID: ESLYjb3nw8-S
CSeq: 20 INVITE
Max-Forwards: 70
Supported: replaces, outbound
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO, UPDATE
Content-Type: application/sdp
Content-Length: 694
Contact: sip:[email protected]:10038;transport=udp;+sip.instance="urn:uuid:95a9ad4e-1409-467e-834d-5d1543669edc"
User-Agent: Linphone_iPhone.6_iOS10.3.2/3.16.3 (belle-sip/1.6.1)

v=0
o=1901 1782 4007 IN IP4 x.x.x.x
s=Talk
c=IN IP4 x.x.x.x
b=AS:380
t=0 0
a=rtcp-xr:rcvr-rtt=all:10000 stat-summary=loss,dup,jitt,TTL voip-metrics
m=audio 10031 RTP/SAVP 0 8 9 18 101
a=fmtp:18 annexb=yes
a=rtpmap:101 telephone-event/8000
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:oYEUJUe+U2JygsOg4JT3k8ysyj4Sxffm84/gsodH
a=crypto:2 AES_CM_128_HMAC_SHA1_32 inline:8dU4z4Wk9Pl+LdhWAmU0BJiVRlIa4bbKdmY8jrAk
a=crypto:3 AES_256_CM_HMAC_SHA1_80 inline:ymNIvIUHt4vkLOEfNttpZQ/ef0gPt69Q2uQ+e8qn6UEL6mdgbjXlylo40rr1Ng==
a=crypto:4 AES_256_CM_HMAC_SHA1_32 inline:8My2B4d8P6pD7+CMBT/xZ3YhwH2IULHDMwNppr1P6lP3rGtAJm05V+WFVVvwWQ==
a=rtcp-fb:* trr-int 5000
a=rtcp-fb:* ccm tmmbr
<------------->
— (13 headers 16 lines) —
Sending to x.x.x.x:10038 (no NAT)

Sending to x.x.x.x:10038 (no NAT)
Using INVITE request as basis request - ESLYjb3nw8-S
Found peer ‘1901’ for ‘1901’ from x.x.x.x:10038

<— Reliably Transmitting (no NAT) to x.x.x.x:10038 —>
SIP/2.0 401 Unauthorized

Via: SIP/2.0/UDP x.x.x.x:10038;branch=z9hG4bK+234f5a05e4a47dfcc27e5876b56efe0f1+s676+1;received=x.x.x.x;rport=10038
From: <sip:1901 (at) pbx.example.com>;tag=s676+1+41400001+5ee7f7b6
To: “11355” <sip:11355 (at) pbx.example.com>;tag=as1131dd4e
Call-ID: ESLYjb3nw8-S
CSeq: 20 INVITE
Server: FPBX-13.0.192.8(11.25.1)
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
WWW-Authenticate: Digest algorithm=MD5, realm=“asterisk”, nonce="4dc244ac"
Content-Length: 0

<------------>
Scheduling destruction of SIP dialog ‘ESLYjb3nw8-S’ in 88448 ms (Method: INVITE)

<— SIP read from UDP:x.x.x.x:10038 —>
ACK sip:11355 (at) pbx.example.com SIP/2.0
Via: SIP/2.0/UDP x.x.x.x:10038;rport;branch=z9hG4bK+234f5a05e4a47dfcc27e5876b56efe0f1+s676+1
From: <sip:1901 (at) pbx.example.com>;tag=s676+1+41400001+5ee7f7b6
To: “11355” <sip:11355 (at) pbx.example.com>;tag=as1131dd4e
Call-ID: ESLYjb3nw8-S
CSeq: 20 ACK
Max-Forwards: 70
Content-Length: 0

<------------->

— (8 headers 0 lines) —

<— SIP read from UDP:x.x.x.x:10038 —>
INVITE sip:11355 (at) pbx.example.com SIP/2.0
Via: SIP/2.0/UDP x.x.x.x:10038;rport;branch=z9hG4bK+26425e614990def04ddef93c5ce0af8d1+s676+1
From: <sip:1901 (at) pbx.example.com>;tag=s676+1+41400001+70a5dfdf
To: “11355” <sip:11355 (at) pbx.example.com>
Call-ID: ESLYjb3nw8-S
CSeq: 21 INVITE
Max-Forwards: 70
Supported: replaces, outbound
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO, UPDATE
Content-Type: application/sdp
Content-Length: 694
Contact: sip:[email protected]:10038;transport=udp;+sip.instance="urn:uuid:95a9ad4e-1409-467e-834d-5d1543669edc"
User-Agent: Linphone_iPhone.6_iOS10.3.2/3.16.3 (belle-sip/1.6.1)
Authorization: Digest realm=“asterisk”, nonce=“4dc244ac”, algorithm=MD5, username=“1901”, uri=“sip:11355 (at) pbx.example.com”, response=“abc809463b8e0bb858edc5fc862686d6”

v=0
o=1901 1782 4007 IN IP4 x.x.x.x
s=Talk
c=IN IP4 x.x.x.x
b=AS:380
t=0 0
a=rtcp-xr:rcvr-rtt=all:10000 stat-summary=loss,dup,jitt,TTL voip-metrics
m=audio 10034 RTP/SAVP 0 8 9 18 101
a=fmtp:18 annexb=yes
a=rtpmap:101 telephone-event/8000
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:oYEUJUe+U2JygsOg4JT3k8ysyj4Sxffm84/gsodH
a=crypto:2 AES_CM_128_HMAC_SHA1_32 inline:8dU4z4Wk9Pl+LdhWAmU0BJiVRlIa4bbKdmY8jrAk
a=crypto:3 AES_256_CM_HMAC_SHA1_80 inline:ymNIvIUHt4vkLOEfNttpZQ/ef0gPt69Q2uQ+e8qn6UEL6mdgbjXlylo40rr1Ng==
a=crypto:4 AES_256_CM_HMAC_SHA1_32 inline:8My2B4d8P6pD7+CMBT/xZ3YhwH2IULHDMwNppr1P6lP3rGtAJm05V+WFVVvwWQ==
a=rtcp-fb:* trr-int 5000
a=rtcp-fb:* ccm tmmbr
<------------->

Wow - you got that part to work? That’s amazing - it almost always guarantees unprecedented failure. Set up your firewall using the “standard” setup and avoid using SIP-ALG is you want this to work. SIP-ALG is OK for SIP-SIP phones, but with a PBX, it’s much too “helpful” and just messes everything up. It would easily explain your one-way audio, at the very least.

Wow - you got that part to work?

I know, right? As strange as it seems the alg works well for me in most cases including encrypted h323. Though I see the majority of suggestions are to disable it.

So just forward 5061 and 10000-20000 (or whatever rtp ports are specified) into the PBX? I’ll need to document what I test a bit better as I think I was forwarding everything in. (only from my testing IP of course)

My backup plan was to install VPN clients on their phones, but I really don’t want to go that route.

Thanks!

1 Like

http://help.fortinet.com/fos50hlp/54/Content/FortiOS/fortigate-voip-guide-52/ssl-tls.htm

Here’s what I’m working with. Dumb question: where would I get/generate the client cert?

I think you are ok, don’t use port forward you may have encryption but this doesn’t mean a bot cannot register with your freepbx and make calls. If you want to give remote access do it through VPN.

I would turn off the QoS SIP ALG stuff. It could cause a massive headache if you have a traffic spike at the wrong time.

As far as encrypting your traffic, I don’t use anything except TLS for ALL my network traffic that touches the SIP server. I go to letsencrypt to generate my certs. It also helps that I own a few domains. I don’t allow insecure traffic AT ALL on mine. HTTPS for web/UCP and the SIP traffic is TLS by default. I turned off TCP to make UDP the default packet type.

If you’re having problems implementing, you may PM me.

I need to test more, for my own sanity, but I think I have it working. Here are the changes:

firewall: None. Still with sip/alg/session helpers.

FreePBX:
sip Advanced:
external address=my.external.ip (vs hostname - though the IP in before)
nat=yes
IP Config=static
IP override=my.external.ip

Extension:
Nat=yes

It’s probably obvious to ya’ll, but the two nat statements seemed to nail it. I could have sworn those were on as I’ve been through all of it 100 times.

I had my phone on LTE (w/o VPN), dialed into 3 separate soft/hard phones on the LAN. Now to maybe test with an alternate TLS port…

:smiley: