FreePBX, USG, Adtran TA924e not ringing with no SIP ALG enabled/NAT Issues

FreePBX Endpoints
1

Hello friends,

For the longest time we have not been able to solve this NAT mystery.

The set up is a FreePBX 15 (other versions same thing) in a cloud vps with a public IP, a few of the Yealink IP phones, and an Adtran TA924e behind a Ubiquiti USG gateway.

The issue is, when SIP ALG is disabled in the USG, the Adtran which is behind the USG is not receiving calls form any of the phones. The phones, however are working fine both ways. The adtran can only call out, but not receive calls.

When I checked debug sip stack messages in the Adtran, it is clearly showing that when SIP ALG is disabled in the USG, the adtran is getting a request on a public IP, not Adtran’s private IP like it should. But when SIP ALG is enabled in the USG, the adtran is receiving a sip request on it’s private IP and port 5060, and the adtran then is ringing the phone.

The question is, we are trying to disable SIP ALG for our phone deployments, but disabling SIP ALG in the USG causes the Adtran to not receive calls. What should we do so that the USG handles this NAT issue properly, and translates to the Adtran’s private IP? Since the phones are working fine, why would the adtran not receive calls?

Here is the output of the SIP Invite to the adtran when SIP ALG is enabled and the adtran is ringing.

21:50:03.183 SIP.STACK MSG Rx: UDP src=104.156.27.116:5060 dst=192.168.5.32:5060
21:50:03.183 SIP.STACK MSG INVITE sip:[email protected]:5060 SIP/2.0
21:50:03.183 SIP.STACK MSG Via: SIP/2.0/UDP 104.156.227.116:5060;rport;branch=z9hG4bKPj86c93a49-668c-47cc-bd7f-8fc914eb5486
21:50:03.183 SIP.STACK MSG From: “Test” sip:[email protected];tag=925f1351-231c-4881-98d7-0af333b9370c
21:50:03.183 SIP.STACK MSG To: sip:[email protected]:5060
21:50:03.184 SIP.STACK MSG Contact: sip:[email protected]:5060
21:50:03.184 SIP.STACK MSG Call-ID: 5b294ae2-2c85-452a-8094-6f0e490e09db
21:50:03.184 SIP.STACK MSG CSeq: 20185 INVITE
21:50:03.184 SIP.STACK MSG Allow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, MESSAGE, REFER
21:50:03.184 SIP.STACK MSG Supported: 100rel, timer, replaces, norefersub
21:50:03.185 SIP.STACK MSG Session-Expires: 1800
21:50:03.185 SIP.STACK MSG Min-SE: 90
21:50:03.185 SIP.STACK MSG P-Asserted-Identity: “Test” sip:[email protected]
21:50:03.185 SIP.STACK MSG Max-Forwards: 70
21:50:03.185 SIP.STACK MSG User-Agent: FPBX-15.0.16.75(16.11.1)
21:50:03.186 SIP.STACK MSG Content-Type: application/sdp
21:50:03.186 SIP.STACK MSG Content-Length: 343

Here is the output when SIP ALG is disabled in the USG and the Adtran is receiving the invite, but it is directed toward the public IP of the gateway and the Adtran is not ringing.

22:04:37.777 SIP.STACK MSG Rx: UDP src=104.156.27.116:5060 dst=192.168.5.32:5060
22:04:37.778 SIP.STACK MSG INVITE sip:[email protected]:5060 SIP/2.0
22:04:37.778 SIP.STACK MSG Via: SIP/2.0/UDP 104.156.227.116:5060;rport;branch=z9hG4bKPj678355eb-c287-4609-a052-48792cc6c766
22:04:37.778 SIP.STACK MSG From: “Test” sip:[email protected];tag=ca9c7fa6-dac7-494f-b298-fcfd6ee95877
22:04:37.778 SIP.STACK MSG To: sip:[email protected]
22:04:37.779 SIP.STACK MSG Contact: sip:[email protected]:5060
22:04:37.779 SIP.STACK MSG Call-ID: 74605085-0e41-49fb-8964-ed6c79de6d2a
22:04:37.779 SIP.STACK MSG CSeq: 15361 INVITE
22:04:37.779 SIP.STACK MSG Allow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, MESSAGE, REFER
22:04:37.779 SIP.STACK MSG Supported: 100rel, timer, replaces, norefersub
22:04:37.780 SIP.STACK MSG Session-Expires: 1800
22:04:37.780 SIP.STACK MSG Min-SE: 90
22:04:37.780 SIP.STACK MSG P-Asserted-Identity: “Test” sip:[email protected]
22:04:37.780 SIP.STACK MSG Max-Forwards: 70
22:04:37.780 SIP.STACK MSG User-Agent: FPBX-15.0.16.75(16.11.1)
22:04:37.781 SIP.STACK MSG Content-Type: application/sdp
22:04:37.781 SIP.STACK MSG Content-Length: 345

2

Are you forwarding your SIP and SDP ports to your PBX?

3

Why would I do that if the PBX is on a public IP?
The only issue is when the call is trying to get through from the PBX through the gateway’s public IP and then to the Adtran.

4

if the device was a switch, i would agree, if it is a router you will need rules

5

Interesting problem – I’ve never seen a device filter requests like that. I know little about Adtran or USG but maybe one of these general suggestions may be useful.

Please confirm that this is your issue:


Unfortunately, that thread is not of much use – the OP “solved” it by getting another public IP address and putting the Adtran on it!

Possibly, there is a configuration option in the Adtran to ignore this error.

Possibly, you can fake it out by using a domain name that resolves to the public IP on the Asterisk side and to the private IP on Adtran.

Otherwise, if the USG’s SIP ALG is based on port matching, you could use different ports for Adtran and for other devices, such that only the Adtran is affected by the ALG. For example, you could use pjsip for Adtran and chan_sip for other devices (or vice versa) at least for testing. A proper fix would use two pjsip transports.

Or, consider using TLS for the Yealinks and other devices, leaving only the Adtran on UDP.

6

This has been an issue for us for so long and we could never fix it. Why would the router nat stop working when sip alg is disabled?

Yeah all of our extensions are pjsip.

I was thinking maybe to try and put the phones on tls or vpn.

I don’t know.

7

If anyone else has other ideas about this issue, I would really appreciate it!

8

If (and this would be crazy if true) the USG or the AdTran automatically messes with port 5060 regardless of the ALG setting. If this was the case, you’d have to move your SIP port to something else. The bad news is that you’ll have to change anything that talks to your server on port 5060.

Also, don’t confuse “one for one nat” with “directly connected to the Internet”. 1F1 NAT requires all of the standard NAT settings to be in place and required ports 5060 and 10000-20000 to be forwarded manually.

9

I don’t know about your specific model of Adtran, but I know that the model I work with regularly (Netvanta 6410), it cannot handle NAT on its own. Thus you have to give it a public Internet IP address on one of its interfaces, or use SIP ALG. Or you can write your own NAT-handling rule, which I did:

hmr policy ContactNATPolicy
  rule-set ContactNAT 10
!
!
hmr rule-set ContactNAT
  message-rule ReplaceIP message-type any 10
    modify header contact position first match-value /(.*@)(172\.16\.1\.2)(.*)/ new-value /\1123.45.6.78\3/  10
    modify body match-value /172\.16\.1\.2/ new-value /123.45.6.78/  20
    modify body match-value /172\.16\.1\.2/ new-value /123.45.6.78/  30

then apply that hmr policy both in and out on the Adtran trunk that is crossing the NAT.

The rule set is crude but works well. It fixes the IP in the Contact: header (changing from internal to public) and then it replaces two instances of the internal IP in the SDP – the o= line and the c= line.

10

Well, forget what I said. You probably don’t need to do that. According to the data sheet, it has NAT-handling capabilities. https://portal.adtran.com/pub/Library/Data_Sheets/Default_Public/642439xxF1-8%20TA900e%20Series.pdf

So configure them. :slight_smile:

11

There is some confusion here. The specific problem is that Asterisk is sending the public IP in the host part of the INVITE SIP URI (it’s also in the To header but that’s unimportant). The Adtran apparently uses the URI to determine which of its interfaces the request came in on and when it doesn’t match any, an error results.

IMO it’s clear that the USG is doing nothing wrong. A possible fix is if we can get Asterisk to send a domain name in the URI. The Adtran’s local database could resolve that to its LAN IP and the request would be accepted.

1 Like
12

That’s a possibility. Adtran trunks have a “domain” field that will cause them to match the INVITE to a valid trunk.

Enabling the NAT handling should also solve the problem, as then the Adtran would know its public IP address and be able to match on it.

13

If that works, it would be the best solution.

The OP didn’t say whether the Adtran is configured as a trunk or as individual extensions, but I suspect the latter. Setting it up as a trunk would lose the ability of the extensions to have voicemail, follow-me, etc, without a lot of work on the PBX side.

14

Thanks so much for your inputs, I really appreciate it.
I’m going to try to play with NAT in the adtran.
Other than that, without the SIP ALG the router just sends the invite on the public IP.
Maybe if the Adtran knows how to handle it, it will go through.
Another reason that could prove that Adtran doesn’t know how to handle NAT is that when I check pjsip show contacts it shows the phones on random (translated ports) but the Adtran is just on 5060. Possibly because it doesn’t know how to handle NAT.

I’ll see if there is something to be configured for NAT in the Adtran.

15

I don’t see any NAT settings in the Adtran.

16

Can you post your adtran config in a pastebin (http://pastebin.freepbx.org) with any sensitive data removed?

17

Here it is. This is just a test unit. Let me know what you see wrong here.

!
!
! ADTRAN, Inc. OS version R11.10.4.E
! Boot ROM version 14.05.00.SA
! Platform: Total Access 924e (2nd Gen), part number 4242924L1
! Serial number CFG1101649
!
!
hostname “Adtran”
enable password -------
!
!
clock timezone -5-Eastern-Time
!
ip subnet-zero
ip classless
ip routing
ipv6 unicast-routing
!
!
domain-name “localdomain”
!
!
no auto-config
!
event-history on
no logging forwarding
no logging email
!
no service password-encryption
!
username “-----” password “-----”
!
!
no ip firewall alg msn
no ip firewall alg mszone
no ip firewall alg h323
!
!
!
!
!
!
!
!
no dot11ap access-point-control
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!

!
!
interface eth 0/1
ip address dhcp hostname “TA924e”
media-gateway ip primary
no shutdown
!
!
interface eth 0/2
no ip address
shutdown
!
!
!
!
interface t1 0/1
shutdown
!
interface t1 0/2
shutdown
!
interface t1 0/3
shutdown
!
interface t1 0/4
shutdown
!
!
interface fxs 0/1
no shutdown
!
interface fxs 0/2
no shutdown
!
interface fxs 0/3
no shutdown
!
interface fxs 0/4
no shutdown
!
interface fxs 0/5
no shutdown
!
interface fxs 0/6
no shutdown
!
interface fxs 0/7
no shutdown
!
interface fxs 0/8
no shutdown
!
interface fxs 0/9
no shutdown
!
interface fxs 0/10
no shutdown
!
interface fxs 0/11
no shutdown
!
interface fxs 0/12
no shutdown
!
interface fxs 0/13
no shutdown
!
interface fxs 0/14
no shutdown
!
interface fxs 0/15
no shutdown
!
interface fxs 0/16
no shutdown
!
interface fxs 0/17
no shutdown
!
interface fxs 0/18
no shutdown
!
interface fxs 0/19
no shutdown
!
interface fxs 0/20
no shutdown
!
interface fxs 0/21
no shutdown
!
interface fxs 0/22
no shutdown
!
interface fxs 0/23
no shutdown
!
interface fxs 0/24
no shutdown
!
!
interface fxo 0/0
no shutdown
!
!
!
!
!
!
!
!
!
!
!
no tftp server
no tftp server overwrite
http server
no http secure-server
no snmp agent
no ip ftp server
no ip scp server
no ip sntp server
!
!
!
!
!
!
!
!
sip
sip udp 5060
no sip tcp
!
!
!
voice feature-mode network
voice forward-mode network
!
!
!
!
!
!
!
!
!
!
!
!
!
!
voice trunk T01 type sip
description “To PBX”
sip-server primary 104.156.27.116 udp 5060
registrar primary 104.156.27.116 udp 5060
!
!
voice grouped-trunk “TO PBX”
trunk T01
accept $ cost 0
!
!
voice user 6000
connect fxs 0/1
no cos
password “1234”
sip-identity 6000 T01 register auth-name “6000” password “------”
!
!
!

!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
line con 0
no login
!
line telnet 0 4
login
no shutdown
line ssh 0 4
login local-userlist
no shutdown
!
sntp server time.google.com
!
!
!
!
end

18

Something to try (per @Stewart1’s advice):

config t
voice trunk T01
domain “73.101.216.17”

This might make the Adtran understand that calls addressed to that IP address are intended for the Adtran, and match the trunk T01 (as it would reject INVITEs that don’t match a trunk).

I’ve got the 4000-page AOS manual in front of me and I’m not seeing a straightforward way to configure the NAT handling that your device can supposedly do… so I hope the aforementioned suggestion works for you :slight_smile:

19

I found AOS Command Reference Guide - Adtran Support Community (5249 pages, definitely not light reading), containing considerable discussion of NAT. I don’t know whether it applies to your hardware, or would apply after a firmware update.

20

I added this line

domain 73.101.216.17

And it works! This is a freakin miracle! Thanks so much.

I’ll report back how consistent it is, but looks like now the Adtran understands how to match the invites with its public IP properly.

1 Like