Some Problems with a public FreePBX instance

Tags: #<Tag:0x00007f24c505d660>


Hello together,

I hope someone can help me troubleshooting my PBX. I have several PBX Instances behind NAT which are working pretty fine.
But now I installed my first PBX which is on a hosted Server with a public IP.
NAT is set to “no” I think thats the right way

My Clients are Softphones behind NAT (PhoneSuite) and most of the stuff is working finde.

Only on Outgoing calls I have some problems.
On Outgoing or local calls when I use these features at the Initiator side I can’t

-Hold these calls (nothing happens but the Audio goes away)

  • Cant transfer these calls (nothing happens but the Audio goes aways)
  • Calls End after 30 Minutes
  • Sometimes one way Audio on Inbound calls
  • The phone rings after trying to redirect a incoming call to another participant
    I think there are some Problems with sending/receiving re-Invites

So we could say its a Firewall/NAT Problem on the Client side. BUT. I configured the VPN Server on the FreePBX and connected the Clients over VPN - same problem

Next I tried another SIP Client (ZOIPER) - everything working fine
But I don’t think its a PhoneSuite Problem because:

I connected PhoneSuite directly to an PBX (same local Network) and over a VPN Software to another FreePBX (this one is behind NAT) - Working fine

I hope someone can help me troubleshooting this.
Thank you :slight_smile:

Additional Informations:

  • When i do “asterisk -rvvvv” and put a call on hold, nothing happens there. When i put a inbound call on hold which is working the Log shows stuff


As far as I know, hosted VMs are generally behind some sort of NAT device. Yo can check if yours is by going into the freepbx console and issuing ifconfig -a command. If you see a private IP listed instead of your public IP, then your VM is behind a NAT device.


Thanks for the answer.
But no the PBX Network Interface directly has the public IP Adress


Okay a SIP Trace on my PBX and on the Client from a working call with hold (inbound) shows a INVITE after that a 200 SIP OK

An Outbound shows that the Client is sending out the INVITE normally but the PBX never gets that INVITE Package

But a SIP Trace on my Client shows that the INVITE goes out to the PBX (inbound and outbound call look the same)


Though I can’t explain your VPN experience (which could be a separate issue), everything else (so far) is consistent with a SIP ALG causing the trouble.

On the Client end, confirm that the re-invite for hold is being sent to the correct IP address and port. At the PBX, confirm that you are capturing traffic ahead of the FreePBX firewall. sngrep and tcpdump are ahead of the firewall, but Asterisk chan_sip debug and pjsip logger are after the firewall.

At the client end: ISP? Modem make/model? Is modem a ‘gateway’ (has more than one Ethernet port)? If so, is it in bridge mode? Separate router/firewall, if any? Any SIP ALG in either device? If so, have you tried turning them off? Any other VoIP-related settings?


Thanks for the help.

The VPN was directly to the PBX (freepbx own VPN server)calls are working over it. So SIP Alg is disabled but shouldn’t make problems when the call goes over a VPN
A trace on the client shows that the INVITE is getting send to the VPN IP of the PBX. But a trace on the PBX shows no INVITE…


Can you post packet captures from both sides of the VPN tunnel? This should start from the initial INVITE to set up the call (or earlier) and continue through the failing re-invite to put the call on hold (or later). At the client end, you should see retries of the failing re-invite, since it is receiving no response.

Put both .pcap or .pcapng files into a .tgz file and attach it to your post.


The only difference between a Trace of a running HOLD and a not working one

On the Client side the reInvite goes out to the PBX.
But Wireshark says. So I think theres something wrong with the telephony Software, looks like it’s sending out defect INVITE Packages right?

P-Key-Flags: resolution=“31x13”, keys=“4”

What does it mean? Because its marked blue in Wireshark

The INVITE Packets are passing the Client Network Interface -> LAN Interface of the Firewall -> WAN Interface of the Firewall.
But they aren’t shown in a WAN Trace on my PBX, the BYE Packets are still shown when I end the call


Would like to not post a full pcap here because of privacy reasons.
IP Adresses and phone numbers are included in it


Okay it seems that the Packets getting fragmented
A Wireshark Trace on my Client shows the following always before an INVITE

Does anyone have an Idea how I could solve it?


Try turning off all unnecessary codecs, in both Asterisk and your client devices. Leave only ulaw and alaw.


Already done
Only have alaw, ulaw and g722 for some phones enabled


How big are the fragmented packets? Have you turned off video codecs?


Yeah Videocodecs are off

Wireshark shows the following


Seems that they are not RFC passable right?

I would use TCP if my Softphone would support it


Click on #842 (the complete INVITE) and expand
Session Initiation Protocol
Message Header
Message Body
Session Description Protocol
and post a screenshot. That will show what is taking so many bytes.


Thanks for the answer

Screenshot attached


In your earlier post, Wireshark shows the reassembled packet as #842, but your latest post is #248??

(David55) #19

I haven’t read the full thread, so this problem may have been mitigated, but this is about the one situation where nat=no is wrong! The chan_sip nat parameter enables certain workarounds that are necessary when Asterisk is outside NAT, its peers are inside NAT, and the peers are not compensating for the existence of NAT. It is not relevant for when Asterisk is inside NAT and has peers outside. Asterisk has certain heuristics which will detect that can detect peer inside NAT and automatically enable the workarounds, so, in most cases, the default should work. Specifying no turns off these heuristics.


Yeah its another trace
I haven’t saved the original one, so i created a new one