IAX2 trunk became unreachable over night

Hi all,

I’m having fun with FreePBX in my spare time and on this occasion I was trying to bridge two PBXs through iax. Everything was up and running yesterday and calls were getting through. This morning to my surprise the trunk is not bidirectional anymore, as one of the PBXs reports its peer as unreachable while everything is fine on the other end. Would like to mention that I’m using FQDNs instead of IP as neither of my providers offer static IPs. Tested however and the addresses are correct.

Here are the trunk configs:

pbx1
outgoing:
username=***
type=peer
secret=***
qualify=yes
host=***
forceencryption=yes
encryption=aes128
disallow=all
auth=md5
allow=opus

incoming:
type=user
secret=***
qualify=yes
forceencryption=yes
encryption=aes128
disallow=all
context=from-trunk
auth=md5
allow=opus

pbx2
outgoing:
host=***
username=***
secret=***
type=peer
disallow=all
allow=opus
qualify=yes
forceencryption=yes
auth=md5

incoming:
secret=***
type=user
context=from-trunk
disallow=all
allow=opus
qualify=yes
forceencryption=yes
auth=md5

So the IAX config is identical on both ends except for the trunk names, hostnames, users, and passwords.

Other things to mention. One PBX is running FreePBX 15.0.37.9 while the other is running FreePBX 17.0.19.13. When enabling iax debug I see POKE, PONG, ACK in this order every time on one end and a lot of POKEs with very few PONGs and ACKs on the end from where the peer is reported as unreachable. Is this purely a networking issue? What could have happened overnight?

If you haven’t already done so, reboot all network gear in the path (modem/ONT, router/firewall, any smart switches) at both ends. Do this with the PBXes shut down, then start them up again.

The iax debug shows where outgoing packets are sent and where incoming packets came from.
On the end where the peer shows reachable (A), you should see POKE sent, PONG received, ACK sent. Assuming that you are connecting to the correct host, the other end (B) should show POKE received, PONG sent, ACK received. Now, besides that traffic, what is left? If you are seeing POKEs sent from B but nothing else, then you need to trace why they aren’t getting to A. Or, if they are getting to A but the PONGs that A sends aren’t getting to B, trace that. tcpdump on the PBX machines is useful; note that it captures incoming packets ahead of the FreePBX firewall and outgoing packets after the FreePBX firewall. For further debugging, capture traffic on the WAN interfaces of your hardware router/firewalls.

1 Like

I already rebooted the network elements (basically just some ISP modems/routers as there is nothing in between them and the PBXs (RPi). Didn’t do this with the RPis off but will try this next. Actually, it’s not gonna be possible with both because one of them is remote.

Another thing I did yesterday is use another external port for IAX and forward it in the routers then added the port= parameter in the FreePBX config. Again, worked ok yesterday evening but stopped working this morning. So I switched back but there is something awkward going on now because on one of the PBXs I see POKE-PONG-ACK for both ports. What’s even weirder (or maybe there’s something I don’t get) is that port 8869 isn’t even forwarded now by the router.

Anyway the IAX link is working now with the default ports. Will see how long it lasts.

Rx-Frame Retry[ No] -- OSeqno: 000 ISeqno: 000 Type: IAX     Subclass: POKE
    Timestamp: 00016ms  SCall: 09646  DCall: 00000 ***:8869

Tx-Frame Retry[ No] -- OSeqno: 000 ISeqno: 001 Type: IAX     Subclass: PONG
    Timestamp: 00016ms  SCall: 00001  DCall: 09646 ***:8869
Rx-Frame Retry[ No] -- OSeqno: 001 ISeqno: 001 Type: IAX     Subclass: ACK
    Timestamp: 00016ms  SCall: 09646  DCall: 00001 ***:8869
Tx-Frame Retry[000] -- OSeqno: 000 ISeqno: 000 Type: IAX     Subclass: POKE
    Timestamp: 00017ms  SCall: 06239  DCall: 00000 ***:4569

Rx-Frame Retry[ No] -- OSeqno: 000 ISeqno: 001 Type: IAX     Subclass: PONG
    Timestamp: 00017ms  SCall: 00001  DCall: 06239 ***:4569
Tx-Frame Retry[-01] -- OSeqno: 001 ISeqno: 001 Type: IAX     Subclass: ACK
    Timestamp: 00017ms  SCall: 06239  DCall: 00001 ***:4569

So I decided to disable qualify as it takes down my tunnel if the peer doesn’t respond in time, although there is no apparent problem in connectivity (reverse tunnel is OK). Since my IPs are statically assigned, I see no usefulness in NAT. Will test for a while and if OK it will stay like this until I’ll move on to a pjsip trunk.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.