Apologies, yes it is a static IP. I have a 5 block. Obviously not enough now. But I am unsure why FreePBX doesn’t “like” that IP address anymore from the outside World since it is all alone on it.
The reason for the NAT is because I have only one WAN port on PfSense, (I don’t have a fail over provider) so everything has to be directed from there. I am going to make some hardware changes and look into the prospect of a 13 block static IP assignment.
I am also running into a lot of issues trying to get FreePBX 17 to install. I’ve been working on this for a week, and I am still no closer to having a working system than when I started.
Tried installing via the ISO, but ran into the same issues you did. It took a 480GB RAID1 setup and partitioned out barely enough space for the system to run. Then I could not restore my backup because of a lack of space. So then I figured I would try installing via the script on Debian 12. Following Sangomas’ instructions WORD-FOR-WORD and using the download links THEY have provided has left me with a working version of Debian on the WRONG kernel for DAHDI. We have to have DAHDI because our FreePBX System connects to a PRI, and it’s useless without it.
This has been the biggest pain in the backside and has left me wanting to abandon FreePBX altogether.
Minus the DAHDI and that was my experience too. The install kept failing to run all the way through. And when it finally did, I have other problems now with my network to contend with. Yes, the .iso gave me a 20GB RAID1 partition on a 200GB ZFS pool and despite what was said above the SangomaDefaultPassword business would not even grant me console access - said password invalid or wrong password, I don’t recall now…
Again, I’m going to ask how does it not “like” the IP. You need to explain what is actually happening. Is this just for incoming calls or are outgoing calls having issues too? Does the trunk register/connect fine to voip.ms?
What kernel version are you on? What does uname -r output?
Also, your issues are not the same as the OPs.
Following these instructions:
Installed Debian 12 with Kernel version 6.1.0-38. Then tried to install FreePBX using the script as given in the install instructions here: https://sangomakb.atlassian.net/wiki/spaces/FP/pages/230326391/FreePBX+17+Installation with the --dahdi argument, and I am left with an error that it can’t install because the latest Kernel that DAHDI supports is 6.1.0-37. Are we supposed to downgrade our Kernel to make DAHDI work? This seems like a huge risk that may leave me with a broken system in the future.
Also, I would disagree. I said that I was having the same issue using the ISO install method, not overall. It seems like whenever we use the ISO to install FreePBX, the system does not partition our drives with enough space, and in that regard, I am having the exact same problem as the OP when using the ISO method.
I keep saying this, don’t use SNGDEB. It offers you nothing of real substance.
Which is why I went the Debian/Script method after I had issues with the partitioning.
But there are issues with the script when using Dahdi on a fresh install of of Debian 12… I am just trying to figure out what to do from here…
You can install DAHDI 3.4.x from source which will override the packaged version being installed by the installer.
Why they are using older versions of DAHDI, I don’t know.
The SNGDEB ISO is more tightly locked to the latest DAHDI supported kernel, since it ships with one embedded, so yes there is a subtle difference there vs. installing latest stock Debian and then running the FreePBX shell script. A new ISO is not built until our underlying DAHDI DEB package is QA’d with the kernel from the Debian version that said ISO is based on. We rely on the (current) fact that the kernel update done during installation does not remove the kernel that came on the ISO so when the script runs after the next reboot and detects that a rollback is needed to a previous kernel you are in the clear. (Many distros protect you during kernel updates by keeping the previous kernel available 
Another workaround might be to use an older (but recent) stock Debian installer with a DAHDI supported kernel e.g. from Debian 12.10 via Index of /mirror/cdimage/archive/12.10.0/amd64 then partition as you like.
And what testing is done for those installs not based on the SNGDEB ISO? Because it seems like SNGDEB takes priority over non-SNGDEB and that is something that goes against the whole edict of “Sangoma will no longer produce ISOs for FreePBX installs”. The existence of SNGDEB already goes against the edict so I’m trying to understand which path is actually being followed here.
So what would be your best advice in my case? To use 12.11 and downgrade the Kernel or install 12.10? I just wanna make sure that my system isn’t going to fail, because it’s a very important system in our organization. It’s one of the reasons why I have waited so long to upgrade.
My other question would be, why is Sangoma using DAHDI 3.3.x which relies on the dahdi-linux-kmod packages (which are tied to kernel versions) instead of using DAHDI 3.4.x which don’t rely on dahdi-linux-kmod packages and wouldn’t have these issues?
You actually still have a real TDM PRI/T1 you’re connecting to the PBX? TDM is riding off into the sunset and telecoms have stopped selling it overall. These days a customer asking for a PRI handoff ends up with a SIP<>TDM gateway to plug into. You have maybe a few more years before it all goes dark depending on your carrier and location. Some countries already turned the lights off for TDM a couple years ago.
I’m starting to wonder how many people are still using DAHDI because they have a PRI/T1 cards but are just plugging it into a SIP<>TDM gateway.
Yep, its an actual PRI. We use Spectrum Enterprise Fiber and they send it in over our fiber connection.
That is not an actual PRI. PRI is TDM based, you cannot provide TDM based PRI over Fiber. This means that it is actually SIP being converted to a PRI hand off.
This goes back to what I said in my previous comment. They are providing you a PRI handoff but it’s not a real TDM PRI. It’s being converted from IP<>TDM by a media convertor/gateway.
Also, Spectrum is a cable company they have never had TDM infrastructure
I stand corrected, then. We have their fiber enterprise service, and it all runs into their fiber media converter. Our “PRI” is plugged into the fiber media converter, and the PBX is plugged into the “PRI”. So you are probably correct in assuming it’s being converted.
@BlazeStudios I can’t get Let’s Encrypt to talk to my external IP. As if nothing was there. I just use Let’s Debug to check and see if it connects properly and it is NOT. Of course I can reach the dashboard and so forth locally, but that doesn’t matter, it needs to be online on the Internet to have Let’s Encrypt do its thing, OR to run properly for calls. No trunks or extensions have even been approached yet - that is minus the two that came up all on their own
Right which also means you actually don’t need PRI on your IP PBX. You can convert to SIP trunks and this becomes a non problem. The use of PRI only exists because you requested it.
You have port 80 properly NATd from the WAN to port 80 of the PBX?