I’m in the process of setting up a FreePBX server, and have a pretty strong background in IT, with a specific focus on networking. For a couple days I had a fully functional setup, but I’ve run into an issue that has legitimately led me to have nightmares about hair loss. I don’t know what that means, but I’m hoping someone here could suggest what might be causing me to stop receiving inbound calls after setting a static IP.
When I started trying to figure out what was causing this, I made sure to start anew with a completely fresh, completely stock, and up to date clean install of FreePBX using the ISO from the website. From there, I followed this guide (google: TwilioElasticSIPTrunking-FreePBX-Configuration-Guide-Version1-0-FINAL-06122018.pdf) to setup a fully functional PBX system with inbound and outbound calling using Twilio. I tested everything, verified that it worked, and took a snapshot of the VM it was operating on so I could rollback if things break.
From there, I made one and only one change, which is to set a static IP. No matter how I did it (whether mapping a static IP on my DHCP server or setting it directly in the FreePBX GUI), incoming calls would stop coming in, I would get an unavailable message, and 408 Request Timeouts in the Twilio debugger. Restarting doesn’t help, and using sngrep it seems like the PBX just isn’t receiving a new call, while outbound calls to Twilio work flawlessly. I can rollback to the PBX with DHCP and everything starts working again.
I’ve tried restarting the whole installation from scratch, all manners of different IPs, reboots, and console restarts, and cannot for the life of me figure out why this happens.
If anyone has any suggestions as to what might cause this, or what I could do to try and further narrow down the source of the issue, I would absolutely love to hear from you.
If you are not seeing the inbound INVITE with sngrep, then I think that pretty conclusively points the finger to your router/firewall. I can’t remember for sure, but I believe that Twilio uses IP authentication, (not registration) in which case you must port forward the signalling port(s) and RTP media port range at the router to the PBX. Changing the PBX LAN IP would require a change to these router rules.
In my initial, functional setup, I had no ports forwarded and everything worked. Twilio can be configured to do either IP authentication, user/pass authentication, or both, and right now I have it set up for user/pass only.
The one interesting point that you prompted me to consider was the setting labeled “registration” in the FreePBX PJSIP trunk settings. Twilio’s own docs specify to set this to “none”, but from reading the help text it seems like that could cause a change in server IP to prevent calls from being delivered. I tried switching the registration mode to send, but it unfortunately didn’t solve the problem, and I could see in sngrep that the register requests were being ignored.
Is it possilbe that I need to port forward the SIP signaling and RTP ports to the PBX, even though it works without that on DHCP? To be honest I don’t have a great grasp on this part of the equation, I had read in some docs somewhere that for the connection to your SIP trunking provider no port forwarding is necessary, and you only need to port forward when you have phones connecting externally or you’re creating a trunk between two PBXs.
You probably have to forward the RTP range, and if you’re not using registration, you’ll need to forward the signaling ports. I have no idea how inbound works with DHCP but without registration and forwarding, unless there’s an ALG at work on the router.
This did come to mind, and was part of the reason I tried mapping the static IP in the router in case that helped it direct the traffic.
I’m not sure whether one or both was required, by port forwarding both the signaling port and the RTP range it seems like I’m up and running. I assume there are no real downsides to having both forwarded. While I don’t fully understand what about the IP change broke the trunk, I’m very relieved to have a functioning setup.
There is no problem with forwarding the RTP, but untrusted access to signalling services does have security implications. You can tighten access using the FreePBX firewall.
Got it. I’m sure I can (and should, and will) read the docs for more in depth security concerns and firewall rules, but for now I enabled the FreePBX system firewall & responsive firewall, and I set my interface to Internet (untrusted), and whitelisted the IPs for Twilio’s signaling and media IP ranges.