Asterisk behind NAT, some clients WAN, others LAN

[eslindsey]

I have what I think is a fairly straightforward setup using vanilla Debian (buster/sid) with packaged Asterisk 13.22.0~dfsg-1. I want the devices on the trusted internal LAN to be able to connect SIP using UDP and RTP in an insecure fashion. This works fine. I want the devices connecting from the WAN to only be able to connect via SIP+TLS and SRTP. Here I get a successful registration, and proper signaling, but no audio. As an experiment, to ensure that the problem is not TLS or certificate related, I put my phone on the internal network and tried again, and audio worked fine. So this appears to be some kind of NAT issue.

I am hesitant about assigning a static IP to the Asterisk server because (1) I think that will cause NAT traversal problems between the IP phones on the internal network and the Asterisk server which will then be on the external network, and (2) because it is easier to secure if the Asterisk server is on the LAN side and I only forward ports as necessary.

Asterisk PBX on LAN: 192.168.1.20 (static)
Router: LAN 192.168.1.1 (static), WAN 50.192.28.249 (static)
Ports available on LAN: 5060-5061 SIP UDP or TLS
Ports forwarded on router: 5061 TCP for SIP TLS, 10000-20000 UDP for RTP/SRTP
Test softphone on iOS 11.1.2: Zoiper 3.16.1 for iPhone, library revision v2.8.97-mod

The following posts have some information, but most are using sip.conf (not pjsip.conf), and most are dealing with double NAT traversal (I only need to traverse one NAT currently):

Asterisk 1.8.5.0 behind NAT and clients behind NAT

It turn out, that the router at the server side changes destination port of the rtp packets when they arrived from the client to the server. For example, the client sends rtp packet to the server to port 10033, but the router send this packet to port 10000. In this way the server doesn’t received any rtp packets from client. There is no information why when the server does not receive rtp packets tries to send rtp packets not to external IP address of the client (which can be calculated and t…

Asterisk behind NAT and voip clients behind other NAT

Hi Guys, I understand that Asterisk server behind a NAT and SIP pone behind another NAT will only work with use of STUN server. Another option is site to site VPN, I use draytek routers which also have hood QOS capability. A further option is to locate asterisk servers at each location and use IAX2 trunk between them. Using SIP in double NAT scenario without STUN is not possible. (AIUI). Good luck, Sean Browne Cardiff IT Support Ltd 0800 011 2931 www.cardiffitsupport.com

[HELP] Connecting SIP Clients behind a NAT to Asterisk

We moved our Asterisk box to a public IP address. Our office phones (SIP); however, are behind a NAT and are having trouble registering with the Asterisk box. Does anyone have any solutions to this other than setting up another Asterisk box inside the office and then doing an IAX2 trunk inbetween the two boxes?

I also used the information in the following documentation:

https://wiki.asterisk.org/wiki/display/AST/Configuring+res_pjsip+to+work+through+NAT

to put together my pjsip.conf is as follows:

[transport-udp]
type=transportprotocol=udp
bind=0.0.0.0

[transport-tls]
type=transport
protocol=tls
bind=0.0.0.0:5061
cert_file=/etc/letsencrypt/live/pbx.indigorm.com/fullchain.pem
priv_key_file=/etc/letsencrypt/live/pbx.indigorm.com/privkey.pem
method=tlsv1
local_net=192.168.1.0/24
local_net=127.0.0.0/32
external_media_address=50.192.28.249
external_signaling_address=50.192.28.249

;Templates
[endpoint-internal](!)
type=endpoint
context=from-internal
disallow=all
allow=ulaw
media_encryption=sdes
media_encryption_optimistic=true
direct_media=no

<snip>

When my Zoiper phone is on the LAN, here is what I see in the log with a SUCCESSFUL TLS+SRTP call:

  == Setting global variable 'SIPDOMAIN' to 'pbx.indigorm.com'
[Aug 17 15:15:03] WARNING[20812]: sdp_srtp.c:261 ast_sdp_crypto_process: Unsupported crypto suite: AES_256_CM_HMAC_SHA1_80
[Aug 17 15:15:03] WARNING[20812]: sdp_srtp.c:261 ast_sdp_crypto_process: Unsupported crypto suite: AES_256_CM_HMAC_SHA1_32
[Aug 17 15:15:03] WARNING[20812]: sdp_srtp.c:261 ast_sdp_crypto_process: Unsupported crypto suite: AES_CM_256_HMAC_SHA1_80
[Aug 17 15:15:03] WARNING[20812]: sdp_srtp.c:261 ast_sdp_crypto_process: Unsupported crypto suite: AES_CM_256_HMAC_SHA1_32
[Aug 17 15:15:03] WARNING[20812]: sdp_srtp.c:261 ast_sdp_crypto_process: Unsupported crypto suite: AES_192_CM_HMAC_SHA1_80
[Aug 17 15:15:03] WARNING[20812]: sdp_srtp.c:261 ast_sdp_crypto_process: Unsupported crypto suite: AES_192_CM_HMAC_SHA1_32
[Aug 17 15:15:03] WARNING[20812]: sdp_srtp.c:261 ast_sdp_crypto_process: Unsupported crypto suite: AES_CM_192_HMAC_SHA1_80
[Aug 17 15:15:03] WARNING[20812]: sdp_srtp.c:261 ast_sdp_crypto_process: Unsupported crypto suite: AES_CM_192_HMAC_SHA1_32
    -- Executing [411@from-internal:1] Answer("PJSIP/eric-00000003", "3000") in new stack
[Aug 17 15:15:03] WARNING[20812]: sdp_srtp.c:261 ast_sdp_crypto_process: Unsupported crypto suite: AES_256_CM_HMAC_SHA1_80
[Aug 17 15:15:03] WARNING[20812]: sdp_srtp.c:261 ast_sdp_crypto_process: Unsupported crypto suite: AES_256_CM_HMAC_SHA1_32
[Aug 17 15:15:03] WARNING[20812]: sdp_srtp.c:261 ast_sdp_crypto_process: Unsupported crypto suite: AES_CM_256_HMAC_SHA1_80
[Aug 17 15:15:03] WARNING[20812]: sdp_srtp.c:261 ast_sdp_crypto_process: Unsupported crypto suite: AES_CM_256_HMAC_SHA1_32
[Aug 17 15:15:03] WARNING[20812]: sdp_srtp.c:261 ast_sdp_crypto_process: Unsupported crypto suite: AES_192_CM_HMAC_SHA1_80
[Aug 17 15:15:03] WARNING[20812]: sdp_srtp.c:261 ast_sdp_crypto_process: Unsupported crypto suite: AES_192_CM_HMAC_SHA1_32
[Aug 17 15:15:03] WARNING[20812]: sdp_srtp.c:261 ast_sdp_crypto_process: Unsupported crypto suite: AES_CM_192_HMAC_SHA1_80
[Aug 17 15:15:03] WARNING[20812]: sdp_srtp.c:261 ast_sdp_crypto_process: Unsupported crypto suite: AES_CM_192_HMAC_SHA1_32
       > 0x55fefc335040 -- Strict RTP learning after remote address set to: 192.168.1.196:58858
       > 0x55fefc335040 -- Strict RTP switching to RTP target address 192.168.1.196:58858 as source
Got  RTP packet from    192.168.1.196:58858 (type 95, seq 007143, ts 3589842788, len 000001)
<snip>
Got  RTP packet from    192.168.1.196:58858 (type 00, seq 007255, ts 3589860548, len 000160)
[Aug 17 15:15:06] WARNING[20824][C-00000003]: channel.c:1145 __ast_queue_frame: Exceptionally long voice queue length queuing to PJSIP/eric-00000003
    -- Executing [411@from-internal:2] Playback("PJSIP/eric-00000003", "hello-world") in new stack
Sent RTP packet to      192.168.1.196:58858 (type 00, seq 006548, ts 000160, len 000170)
    -- <PJSIP/eric-00000003> Playing 'hello-world.gsm' (language 'en')
Got  RTP packet from    192.168.1.196:58858 (type 00, seq 007256, ts 3589860708, len 000160)
Got  RTP packet from    192.168.1.196:58858 (type 00, seq 007257, ts 3589860868, len 000160)
Sent RTP packet to      192.168.1.196:58858 (type 00, seq 006549, ts 000320, len 000170)
Got  RTP packet from    192.168.1.196:58858 (type 00, seq 007258, ts 3589861028, len 000160)
Sent RTP packet to      192.168.1.196:58858 (type 00, seq 006550, ts 000480, len 000170)
<snip>
Sent RTP packet to      192.168.1.196:58858 (type 00, seq 006622, ts 012000, len 000170)
Got  RTP packet from    192.168.1.196:58858 (type 00, seq 007330, ts 3589872548, len 000160)
Sent RTP packet to      192.168.1.196:58858 (type 00, seq 006623, ts 012160, len 000170)
Got  RTP packet from    192.168.1.196:58858 (type 00, seq 007331, ts 3589872708, len 000160)
    -- Executing [411@from-internal:3] Hangup("PJSIP/eric-00000003", "16") in new stack
  == Spawn extension (from-internal, 411, 3) exited non-zero on 'PJSIP/eric-00000003'

Disconnecting from the LAN, and trying to operate over cellular LTE data, here is the log from an UNSUCCESSFUL (no audio) call from WAN to Asterisk:

  == Setting global variable 'SIPDOMAIN' to 'pbx.indigorm.com'
[Aug 17 14:51:01] WARNING[20710]: sdp_srtp.c:261 ast_sdp_crypto_process: Unsupported crypto suite: AES_256_CM_HMAC_SHA1_80
[Aug 17 14:51:01] WARNING[20710]: sdp_srtp.c:261 ast_sdp_crypto_process: Unsupported crypto suite: AES_256_CM_HMAC_SHA1_32
[Aug 17 14:51:01] WARNING[20710]: sdp_srtp.c:261 ast_sdp_crypto_process: Unsupported crypto suite: AES_CM_256_HMAC_SHA1_80
[Aug 17 14:51:01] WARNING[20710]: sdp_srtp.c:261 ast_sdp_crypto_process: Unsupported crypto suite: AES_CM_256_HMAC_SHA1_32
[Aug 17 14:51:01] WARNING[20710]: sdp_srtp.c:261 ast_sdp_crypto_process: Unsupported crypto suite: AES_192_CM_HMAC_SHA1_80
[Aug 17 14:51:01] WARNING[20710]: sdp_srtp.c:261 ast_sdp_crypto_process: Unsupported crypto suite: AES_192_CM_HMAC_SHA1_32
[Aug 17 14:51:01] WARNING[20710]: sdp_srtp.c:261 ast_sdp_crypto_process: Unsupported crypto suite: AES_CM_192_HMAC_SHA1_80
[Aug 17 14:51:01] WARNING[20710]: sdp_srtp.c:261 ast_sdp_crypto_process: Unsupported crypto suite: AES_CM_192_HMAC_SHA1_32
    -- Executing [411@from-internal:1] Answer("PJSIP/eric-00000001", "3000") in new stack
[Aug 17 14:51:01] WARNING[20710]: sdp_srtp.c:261 ast_sdp_crypto_process: Unsupported crypto suite: AES_256_CM_HMAC_SHA1_80
[Aug 17 14:51:01] WARNING[20710]: sdp_srtp.c:261 ast_sdp_crypto_process: Unsupported crypto suite: AES_256_CM_HMAC_SHA1_32
[Aug 17 14:51:01] WARNING[20710]: sdp_srtp.c:261 ast_sdp_crypto_process: Unsupported crypto suite: AES_CM_256_HMAC_SHA1_80
[Aug 17 14:51:01] WARNING[20710]: sdp_srtp.c:261 ast_sdp_crypto_process: Unsupported crypto suite: AES_CM_256_HMAC_SHA1_32
[Aug 17 14:51:01] WARNING[20710]: sdp_srtp.c:261 ast_sdp_crypto_process: Unsupported crypto suite: AES_192_CM_HMAC_SHA1_80
[Aug 17 14:51:01] WARNING[20710]: sdp_srtp.c:261 ast_sdp_crypto_process: Unsupported crypto suite: AES_192_CM_HMAC_SHA1_32
[Aug 17 14:51:01] WARNING[20710]: sdp_srtp.c:261 ast_sdp_crypto_process: Unsupported crypto suite: AES_CM_192_HMAC_SHA1_80
[Aug 17 14:51:01] WARNING[20710]: sdp_srtp.c:261 ast_sdp_crypto_process: Unsupported crypto suite: AES_CM_192_HMAC_SHA1_32
       > 0x7f59f0031830 -- Strict RTP learning after remote address set to: 10.202.82.209:46946
       > 0x7f59f0031830 -- Strict RTP qualifying stream type: audio
       > 0x7f59f0031830 -- Strict RTP switching source address to 166.172.187.104:56772
Got  RTP packet from    166.172.187.104:56772 (type 00, seq 013798, ts 3819948447, len 000160)
    <snip>
Got  RTP packet from    166.172.187.104:56772 (type 00, seq 013906, ts 3819965727, len 000160)
[Aug 17 14:51:04] WARNING[20763][C-00000001]: channel.c:1145 __ast_queue_frame: Exceptionally long voice queue length queuing to PJSIP/eric-00000001
    -- Executing [411@from-internal:2] Playback("PJSIP/eric-00000001", "hello-world") in new stack
Sent RTP packet to      10.202.82.209:46946 (type 00, seq 012396, ts 000160, len 000170)
    -- <PJSIP/eric-00000001> Playing 'hello-world.gsm' (language 'en')
Got  RTP packet from    166.172.187.104:56772 (type 00, seq 013907, ts 3819965887, len 000160)
Got  RTP packet from    166.172.187.104:56772 (type 00, seq 013908, ts 3819966047, len 000160)
Sent RTP packet to      10.202.82.209:46946 (type 00, seq 012397, ts 000320, len 000170)
Sent RTP packet to      10.202.82.209:46946 (type 00, seq 012398, ts 000480, len 000170)
Got  RTP packet from    166.172.187.104:56772 (type 00, seq 013909, ts 3819966207, len 000160)
Got  RTP packet from    166.172.187.104:56772 (type 00, seq 013910, ts 3819966367, len 000160)
Sent RTP packet to      10.202.82.209:46946 (type 00, seq 012399, ts 000640, len 000170)
Sent RTP packet to      10.202.82.209:46946 (type 00, seq 012400, ts 000800, len 000170)
    <snip>
Got  RTP packet from    166.172.187.104:56772 (type 00, seq 013981, ts 3819977727, len 000160)
Sent RTP packet to      10.202.82.209:46946 (type 00, seq 012470, ts 012000, len 000170)
Got  RTP packet from    166.172.187.104:56772 (type 00, seq 013982, ts 3819977887, len 000160)
Sent RTP packet to      10.202.82.209:46946 (type 00, seq 012471, ts 012160, len 000170)
    -- Executing [411@from-internal:3] Hangup("PJSIP/eric-00000001", "16") in new stack
  == Spawn extension (from-internal, 411, 3) exited non-zero on 'PJSIP/eric-00000001'

I don’t understand what role the IP addresses 166.172.187.104 and 10.202.82.209 are playing in all this mess. The IP address reported by my phone while it is on cellular data is 107.77.215.63.

Can anybody shed any light on this issue?