IAX trunk between two servers behind NAT not working

I am trying to set up an IAX2 trunk between two servers both behind a NAT firewall, but I can’t get it to work at all.
Following these instructions:
http://wiki.freepbx.org/pages/viewpage.action?pageId=4161588, according to which I don’t need to forward any ports on my firewall.

Both peers show unreachable.
On IAX2 debug all am I am getting is this, on both ends:
Tx-Frame Retry[002] – OSeqno: 000 ISeqno: 000 Type: IAX Subclass: POKE
Timestamp: 00006ms SCall: 02770 DCall: 00000 [IP of Remote Box:4569]
Are these the qualify messages?

Server1:
Trunk name: system2
Peer details:
username=System1
secret=password
host=public IP of server 2
type=friend
context=from-internal
qualify=yes
qualifyfreqok=25000
transfer=no
trunk=yes
forceencryption=yes
encryption=yes
auth=md5

Server 2:
Trunk Name: System1
Peer Details:
username=System2
secret=password
host=public IP of server 1
type=friend
context=from-internal
qualify=yes
qualifyfreqok=25000
transfer=no
trunk=yes
forceencryption=yes
encryption=yes
auth=md5

Anybody can help out?

No you need ports. That wiki was submitted by a community member and he is wrong and right at the same time depending on firewall behavior. But enough firewalls won’t behave and work the way Martin laid it out. Some will be tricked others won’t. You need to open IAX port 4569 for alot of firewalls.

I wrote the Wiki page that you’re referring to.

I agree with Tony that some routers will not open the ports sufficiently to allow the method to work.

However, there is also an IAX bug with Asterisk 13 which prevents this mechanism from working currently. If you forward Port 4569 from your router to your PBX and it then works, then your router is the issue. If it doesn’t, then you may be experiencing the Asterisk bug.

Given that there were virtually no comments on the Wiki about the method not working until very recently, I suspect that most instances of it not working are due to the Asterisk bug and not your router.

Its easy to test, though. Just forward your ports and try it again.

Also, be sure to power off and reboot your router just to rule out any hiccups on your NAT table.

1 Like

I got the trunk working halfway. I opened IAX UDP 4569 on one firewall (vanilla OpenBSD with pf.conf) in front of server 2 and now server 1 can reach server 2 and make calls to it with audio working both ways. Trunk reachable on that end.
The trunk in the other direction still shows unreachable. When I try to call from server 2 to server 1 I get all circuits busy.

I haven’t yet opened ports on the other firewall (Sonicwall NSA220) in front of server 1, but the question is would that be necessary even?
Wouldn’t the fact that audio is traversing both bays indicate, that the packets are reaching the correct additional destination without additional port forwarding traversing both firewalls just fine?

Any advice?

I will go ahead and open ports on the Sonicwall too and report back.
Thanks.

Asterisk 13.13.1 by the way.

Makes sense to me that its working the way you described. Open up the Sonicwall. Should work in both directions. Ports are opened, allow unsolicited external packets can now come through to establish the call.

@avayax, the way you have your trunks configured, you must have forwarded IAX ports at both ends, which is the preferred method to do it. If that is not possible, a possible alternative is to open port(s) at one end, and use a trunk registration string at the other end. I don’t recall ever setting up an IAX2 peer trunk using a registration string, but if it works in the same way as SIP, the registration string takes the form:

user_name:[email protected]<remote_pbx>:<port>

Then confirm the registration status at the Asterisk CLI with:

iax2 show registry

I am getting a "Registered IAX2 to `local external IP’:4569’, who sees you as ‘remote external IP’:48147 with no messages waiting”.

Remote server is seeing me on port 48147.
Is that expected behavior or a NAT issue?

Your outbound port number does not have to (and some would argue should not) match the port number at the remote end. Your 4569 port at this end is for incoming Start Of Message traffic. Most protocols peel this off to another port in the upper band to make the port available for other traffic. Your firewall will mark the outbound ports open to the traffic you are sending, so it “should” work.

1 Like