A New Adventure: Introducing FusionPBX… again

It’s been almost seven years since we first looked at FusionPBX and FreeSwitch. So we’ve spent the last couple months taking a fresh look at the platform and WOW! What a difference seven years make. We will hasten to add that FusionPBX is not a platform for folks that are new to the VoIP world or networking. For those users, the various flavors of Incredible PBX including the latest Incredible PBX 2025 and Incredible PBX 2027 for Debian 11 or Ubuntu 22.04 are a much better fit. And there are Incredible PBX versions for almost every virtual machine and cloud platform on the planet. There’s a Nerd Vittles tutorial for almost all of them.

But we digress. Today our focus is squarely on FusionPBX and the terrific feature set it brings to the table. At the top of that list is a true multi-tenant platform. If you maintain VoIP resources for multiple departments or divisions and support dozens or hundreds of traveling salespeople, the latest release of FusionPBX will be music to your ears. You can set up user accounts for individual users, and their phones will ring regardless of where they land for the day, the week, or permanently. Changing DHCP and dynamic IP addresses, never a problem. Cell phone usage and push notifications are also a piece of cake. So let’s get started.

Remember the old carpenter’s rule, "Measure Twice. Cut Once." It’s equally important here. You don’t want to go through this installation process (which is admittedly tedious) and get to the finish line only to discover that your server platform has run out of memory or storage space for your target audience. Or you forgot to consider a backup solution. So do your homework and carefully consider how many tenant platforms and users you will be supporting and what uses will be employed by each of those departments and users. Trust me when we say you really need a cloud platform for this deployment. You do not want to babysit this in house with all the maintenance headaches that entails.

You’re going to need a Debian 12 cloud platform and a static IP address for FusionPBX. Spend some time considering what your long-term budget for this project will be, document your requirements, and make a shopping list. And then go shopping. LowEnd-Talk and LowEnd-Spirit offer dozens of low cost options. You’ll be hard-pressed to beat the $50/year ColoCrossing deal linked above with monthly backups, but they have dozens of other options depending upon your requirements. Just read the reviews before making a decision.

Truth be told, we’re using a £11.25/year (discontinued) VPS offering with 1GB of RAM, 20GB of SSD storage, and automatic weekly backups to support three home offices and a half dozen mobile devices. Call volume is low with minimal transcoding. We’ve never experienced a hiccup.

In the middle tier, Vultr, Digital Ocean, and OVH can’t be beat. If money is no object, you have the luxury of Amazon, Microsoft, and Oracle platforms to consider. If the platform you choose doesn’t provide backups, look elsewhere!

Once you have deployed your Debian 12 server, the first thing you’ll need to do is create a fully-qualified domain name (FQDN) using the public IP address of your server. If you don’t have a domain you can use, here’s a link to some free solutions. If you already have a domain, simply create an A record in your DNS settings for fusionpbx.yourdomain.com. Be sure to test your new FQDN using ping before proceeding with the install. Next, use SSH to log in to your new Debian 12 server as root using the FQDN you just created: ssh root@fusionpbx.yourdomain.com. Now issue the following commands to bring Debian 12 up to speed. Regardless of your server platform, immediately change your root password to a very secure one with upper and lower case letters, numbers, and a few special characters. This will avoid many potential catastrophes because of a data breach by your provider.

passwd
apt-get update && apt-get upgrade
apt-get install systemd
apt-get install systemd-sysv
apt-get install ca-certificates
reboot

After rebooting, log back into your server as root and issue the following commands to install the base FusionPBX platform. Note that the first command wraps around to the second line because of space constraints with most browsers.

wget -O - https://raw.githubusercontent.com/fusionpbx/fusionpbx-install.sh/master/debian/pre-install.sh | sh;
cd /usr/src/fusionpbx-install.sh/debian && ./install.sh

When the installation finishes, be sure to make note of the FusionPBX admin credentials required to access the FusionPBX GUI with a browser! If you forget this step, you get to start over.

Next, open your favorite browser and point it to the IP address of your new FusionPBX server. Login as admin using the password assigned above. Because of the FusionPBX security design, we won’t be spending much time in the IP Address Domain of your new server. Instead, the first order of business is to create a new domain using the FQDN that you created above.

In the left column, navigate to Advanced -> Domains. Then click the Add button, enter your FQDN in the Name field, and click SAVE. This will generate the new Domain which will appear in the listing which now appears in the top right pull-down of the FusionPBX Dashboard. Go ahead now and select your Domain. It then will appear as the active one in the FusionPBX Dashboard. Now we need to create a new admin user account with SuperAdmin privileges. From the left column, choose Accounts -> Users -> Add and fill in the blanks leaving the unspecified fields at their default settings. Then click Save.

Username: admin
Password: very-secure-password-of-twelve-or-more-letters-and-numbers
 Confirm: same-password
   Email: your-email-address
Language: your-favorite
TimeZone: where-your-domain-resides
  Groups: superadmin

Now test things out by first logging out: Home -> Logout. Close the browser window and open a new one pointing to the FQDN of your server. Log in as admin using the password you created above. Now the fun begins so take a break if you need one.

If you’ve been following Nerd Vittles for the past couple decades, then you know that we are sticklers when it comes to security. So bear with us while we add a few extra layers of security to FusionPBX. Log back into your server as root using SSH. First, we need to change the default port for future SSH access. Edit /etc/ssh/sshd_config. Uncomment the Port line and enter a new port number. A good choice might be the year you were born. Then save the file. Don’t restart the SSH service just yet, or you will lock yourself out of your server.

Next, edit /etc/iptables/rules.v4. Scroll down to the line containing –dport 22 and duplicate the line. Change the number in the duplicated line to the port number you assigned for future SSH access. Then SAVE the file and reboot your server.

Log back in: ssh -p 1234 root@fusionpbx.yourdomain.com where 1234 is the port you assigned for SSH access. Assuming you got back in, edit /etc/iptables/rules.v4 again and comment out or delete the –dport 22 line. Save the file and restart IPtables: systemctl restart iptables.

Now we’re ready to add a few layers of protection for the FusionPBX web interface. We’ll be using two free services: VoIP Blacklist and APIban. These two services implement a VoIP blacklist of over 100,000 bad guys, and we have found the listings block virtually all attacks on FusionPBX which, by design, exposes its SIP ports on the public internet.

You will need an APIkey for APIban which you can obtain here. Once you have your APIkey, issue the following commands:

cd /
apt install ipset -y
wget https://filedn.com/lBgbGypMOdDm8PWOoOiBR7j/FusionPBX/ipset-additions.tar.gz
tar zxvf ipset-additions.tar.gz
# insert your APIkey when the text editor opens below & save the file
nano -w /usr/local/sbin/apiban-init
chmod +x /etc/rc.local
reboot

Depending upon the amount of RAM available in your new server, IPtables may or may not restart after you reboot. You can check it by logging in as root and issuing the command: iptables -nL. If you see the following entries as the first five in your INPUT chain, all is well and you can move on to the next section:

ACCEPT     0    --  0.0.0.0/0            0.0.0.0/0           
ACCEPT     0    --  0.0.0.0/0            0.0.0.0/0            state RELATED,ESTABLISHED
ACCEPT     0    --  10.8.0.0/24          0.0.0.0/0           
DROP       0    --  0.0.0.0/0            0.0.0.0/0            match-set voipbl src
DROP       0    --  0.0.0.0/0            0.0.0.0/0            match-set apiban src

If you see a bunch of DROP entries in the iptables listing, then the likely culprit is that /etc/rc.local didn’t get executed when you rebooted. You can fix this with the following commands:

cd /etc/systemd/system
ln -s /lib/systemd/system/rc-local.service rc-local.service
reboot

After rebooting, issue the iptables -nL command again and check for the five entries shown above. If they’re there, you’re done. If the series of DROP commands are also missing, then we need to address the memory constraints of your server. Edit /etc/rc.local and replace the existing contents with the following:

#!/bin/sh -e

/usr/local/sbin/apiban-init
#/usr/local/sbin/voipbl-init
systemctl restart iptables
systemctl restart ip6tables
systemctl restart fail2ban
/usr/sbin/iptables -I INPUT -m set --match-set apiban src -j DROP
#/usr/sbin/iptables -I INPUT -m set --match-set voipbl src -j DROP
/usr/sbin/iptables -I INPUT -s 10.8.0.0/24 -j ACCEPT
/usr/sbin/iptables -I INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
/usr/sbin/iptables -I INPUT -i lo -j ACCEPT

exit 0

Finally, issue the following commands to update /etc/crontab and reboot:

echo "3 */6 * * * root /usr/local/sbin/iptables-restart >/dev/null 2>&1" >> /etc/crontab

When you issue the iptables -nL command now, you should see only four entries at the top of the INPUT chain:

ACCEPT     0    --  0.0.0.0/0            0.0.0.0/0           
ACCEPT     0    --  0.0.0.0/0            0.0.0.0/0            state RELATED,ESTABLISHED
ACCEPT     0    --  10.8.0.0/24          0.0.0.0/0           
DROP       0    --  0.0.0.0/0            0.0.0.0/0            match-set apiban src

The VoIP Blacklist IPset will be run as a cron job during the day to add the necessary protection for FusionPBX.

We are big fans of the OpenVPN virtual private network which makes it super easy to manage clients and servers worldwide in a secure, private network. The 10.8.0.0 subnet is used for this purpose as the whitelist entry above shows. If you would like to add an OpenVPN client to FusionPBX, here are the steps assuming you already have an OpenVPN Server running. First, generate a new OpenVPN client for FusionPBX on your OpenVPN server. Download the client to the /etc directory on FusionPBX and name it fusionpbx.ovpn. Issue these commands to deploy OpenVPN:

apt install openvpn
cd /etc/systemd/system
wget https://filedn.com/lBgbGypMOdDm8PWOoOiBR7j/FusionPBX/openvpn.service
chmod +x openvpn.service
cd /etc
wget https://filedn.com/lBgbGypMOdDm8PWOoOiBR7j/FusionPBX/openvpn-start
chmod +x openvpn-start
reboot

If you want a totally secure platform with minimal SIP exposure, an alternative is to create and use your OpenVPN client address in lieu of an FQDN. The two drawbacks are that every desktop phone must have OpenVPN access and push notifications are not supported. If you want to review the deployment steps, follow this link. We personally no longer use this approach and instead follow the recommendations of the developer, Mark Crane.

The real good news in deploying an OpenVPN client is that you always can gain access to your server even if your public IP address got poisoned in one of the VoIP blacklists. For web access, simply point your browser to FusionPBX’s OpenVPN client IP address and then log in as admin@fusionpbx.yourdomain.com with your FQDN’s admin password. Serenity now!

It’s always nice to have a snapshot of all the critical components running (or not) on your server. Here’s how to install our pbxstatus application:

apt install dialog -y
cd /usr/local/sbin
wget https://filedn.com/lBgbGypMOdDm8PWOoOiBR7j/FusionPBX/pbxstatus
chmod +x pbxstatus
echo "pbxstatus -p" >> /root/.profile

We’ve found the easiest way to assure that outbound email gets delivered reliably is to implement a Gmail SmartHost for Postfix. To deploy this, you will need a Gmail account and a Gmail App Password, not your standard Gmail password. You can obtain a Gmail App Password for your account here. Once you have your Gmail account name and app password in hand, issue the following commands:

cd /root
# accept the defaults during Postfix install
apt install postfix
mkdir /etc/pbx
wget https://filedn.com/lBgbGypMOdDm8PWOoOiBR7j/FusionPBX/enable-gmail-smarthost-with-postfix
chmod +x enable*
./enable*
# insert your gmail account name and APP password when prompted
wget https://filedn.com/lBgbGypMOdDm8PWOoOiBR7j/FusionPBX/mailtest
chmod +x mailtest
nano -w mailtest
# insert a destination email address for testing and save mailtest
./mailtest

If you’re coming over from the Asterisk® and FreePBX® world to FusionPBX and FreeSwitch, then the initial setup drill should be familiar. You need a SIP provider (a.k.a. Trunk in FreePBX or Gateway in FusionPBX), you need some extensions and a ring group, and you need outbound and inbound routes to direct calls out and into your FusionPBX platform. We’ll add a few bells and whistles along the way. Let me hasten to add that debugging with FusionPBX is tedious to put it charitably. That may be because of my inexperience because I’ve only been building PBXs for a couple decades. Suffice it to say, our design below works. Your "improvements" may or may not work. And your best source for a solution may be the FusionPBX Forum. Better yet, you may want to attend one of Mark’s training sessions if money is no object.

Let’s start with the SIP provider. The Gateway we’ve chosen is VoIP.ms. You can read all about them here. We also tried BulkVS for several days and had nothing but problems. My best advice comes from my dad’s favorite expression: "Be Reasonable. Do It My Way." The first steps are to create a VoIP.ms account using our signup link. That keeps the lights burning brightly here. Then order a DID in your favorite city. Make sure to set the Dialing Mode to NANPA. Next, create a SubAccount as a PBX with a Username and Password. Specify the DID you ordered as the CallerID number for the SubAccount. Specify G.711U and G.722 as the Codecs. Set DTMF Mode to Auto. Enable the IP Restriction and specify the IP address of your server. Leave the remaining defaults and click Update Account. Next, navigate to Manage DIDs and Route calls to the SubAccount you just created. Choose a POP location near your server, e.g. atlanta2.voip.ms. Leave the remaining defaults and click Apply Changes. That’s all the setup required on the VoIP.ms side.

On the FusionPBX side, begin by pinging the VoIP.ms POP server you chose above to get its IP address.

On your FusionPBX server while logged into your FQDN domain, navigate to Advanced -> Access Controls -> providers. In the Nodes field, enter an Allow entry with the IP address of the VoIP.ms POP you’ve chosen. Enter VoIP.ms as the Description. Then click SAVE.

Next, choose Accounts -> Gateways -> Add. Enter the following. Then click SAVE.

 Gateway: voip.ms
Username: subaccount-name
Password: subaccount-password
FromUser: subaccount-name
FromDomain: atlanta2.voip.ms (or whatever you chose above)
   Proxy: same-as-from-domain
   Realm: same-as-from-domain
 Expires: 60
Register: True
   Retry: 30
 Context: public
 Profile: external
Register: Enabled

Navigate to Accounts -> Gateways again and make sure your gateway shows as REGED after a minute or so.

One of FusionPBX’s slickest features is the available setup procedure for Extensions. Navigate to Accounts -> Extensions -> Add. In Extension, specify the starting extension number. Then in Range, specify the number of extension numbers to create. For example, if you specified 411 as the starting Extension with a Range of 9, FusionPBX would create extensions 411 through 419 with unique default passwords. If you want to specify a User for the extensions, choose it from the pull-down list. Otherwise, leave it blank. Specify a default voicemail password for the extensions. You can leave all of the CallerID fields blank because we’ve already specified the CallerID number on the VoIP.ms side. The other options are self-explanatory so just follow your nose and then click Save.

We’ve always found it wise to specify the IP addresses as Allow entries in Advanced -> Access Controls -> rfc1918 although this may not be necessary for extensions registered to your FusionPBX FQDN. What will be necessary if you’re using an application such as Groundwire on a smartphone or tablet is to review Status -> Event Guard after attempting to register a device that supports Push Notifications. You probably will see the SIPIS push server access got blocked, and you’ll need to toggle this to Unblocked and also register the SIPIS IP address as Allowed in Advanced -> Access Controls -> rfc1918 before Push Notifications will work.

TIP: Any device or service that connects to FusionPBX by IP address needs to be whitelisted in either the rfc1918 or providers section of Advanced -> Access Controls. If a connection or service is failing, the first place to check is Status -> Event Guard. From the command line interface, also check for IPtables blocks with iptables -nL. This is the price we pay for having SIP access exposed. But it’s manageable once you get the hang of it.

Gotcha #1. A word of caution before we set up your Outbound Route. Unless you’re outside the North American Dialing Plan, be consistent in always specifying North America as your Dialplan Expression. The reason is because if you choose 10-digit dialing in your Outbound Route and one of your SIP phones is configured to always add a 1 prefix, the outbound calls from that phone will fail. Choosing North America as your Outbound Route’s Dialplan Expression will allow outbound calls from 1NXXNXXXXXX and +1NXXNXXXXXX and NXXNXXXXXX. Ask us how we know. 🙂

To create an Outbound Route for your VoIP.ms Gateway, choose Dialplan -> Outbound Routes -> Add from the FusionPBX Dashboard. Fill in the form as shown below and click SAVE.

Gateway: VoIP.ms
Dialplan Expression Shortcut: North America
Prefix: 1
Limit: Number-of-Simultaneous-Outbound-Calls-Allowed
Acct Code: Your-FQDN
Description: VoIP.ms

It’s anything but intuitive, but you don’t create an Inbound Route in FusionPBX by choosing Dialplan -> Inbound Routes. Instead, you choose Dialplan -> Destinations -> Add. You only need a few of the fields filled in to complete the setup. Then click SAVE.

Type: Inbound
Country Code: 1
Destination: Your-10-Digit-VoIP.ms-DID
Context: public
Actions: Choose-One-Of-Your-Extensions-From=The-List
User: admin
Usage: Voice
Domain: Your-FQDN
Order: 100
Enabled: True

We’re going to modify this setup a bit in the following sections, but this will get you started so that calls from your DID will be delivered to one of your extensions for testing purposes.

So that we can test things out, we need to enable a softphone on either an iPhone, iPad, Android phone, or Android tablet. To keep things simple, follow our tutorial for Groundwire to load the app onto your device. This will get you a softphone with Push notifications to experiment with FusionPBX. Down the road, FusionPBX provides an incredible assortment of Device Profiles that will preconfigure dozens of SIP phones for you. But, for now, let’s stick with Groundwire.

On the FusionPBX side, you’ll need to edit one of your extensions and copy down the extension password. Then startup Groundwire on your mobile device and choose Settings -> Accounts. Click the + icon in the bottom left of the display to get started. Choose New SIP Account. Click CheckMark when finished.

Title: FusionPBX
Username: Your-Chosen-Extension-Number
Password: Your-Extension-Passwor
Domain: Your-FQDN

Now click Advanced Settings and continue:

Incoming Calls: Use Global Setting
NAT Traversal: STUN 
  Send Media Back: True
  STUN Server: stun.acrobits.cz
  Force Private IP: True  
Enable Video Calls: True
Codecs WiFi: G.711U, G.711A, G.722, OPUS
  Honor Remote Codecs: True
Codecs Mobile: same-settings-as-WiFi
Video Codecs: H.264 and VP8
Outgoing Calls Need Registration: True
Call Waiting: True
Transport Protocol: TCP
Push Options: Simulate NAT and Block Registration During Call
DTMF Mode: RFX2833
Secure Calls: Disabled

Your FusionPBX account should now show as registered by displaying in Green.

We have a tried-and-true solutions to blocking the scammers and politicians. It forces callers to press a number before being routed to your phones.

Here’s how to deploy our Press7 inbound call option. First, download the press7.mp3 file onto your desktop. Then choose Applications -> Recordings -> Upload and choose the MP3 file you downloaded to your desktop. Save the file and then play it once to be sure it works.

Next, we want to create a simple IVR with an option7 that points to your extension and a timeout option that hangs up the call. Navigate to Applications -> IVR Menus -> Add. Fill in the form as shown below and then click SAVE.

Name: Press7
Extension: 777
Greet Long: press7.mp3
Options:
  Option: 7
  Destination: your-extension-number
  Enabled: True 
TimeoutL 6000
Exit Action: Hangup
Context: Your-FQDN
Enabled: True

Finally, edit the Inbound Route created above: Dialplan -> Destinations -> Inbound. In the Action pull-down menu, choose the 777 IVR option. Then SAVE your changes. Now try out a test call to your DID.

If you’re coming from the Asterisk world, you know how important the Asterisk CLI interface was. With FreeSWITCH, there’s a similar command line application: fs_cli. We’re also still a little fuzzy when a synchronization with FusionPBX is necessary so we’ve learned to issue the following two commands after making SIP modifications in the dialplan:

sofia profile internal restart
sofia profile external restart

There are a few other FusionPBX commands worth learning. By navigating to Status -> SIP Status, you can Reload ACL, Reload XML, and Flush Cache. If you modify call routing, add new IVRs, or change any logic in the dialplan, reload_xml is typically needed for those changes to take effect. More importantly, reload_acl reloads the Access Control Lists (ACLs) in FreeSWITCH. ACLs are used to define which IP addresses or networks are allowed or denied access to various FreeSWITCH services (e.g., SIP registrations, gateways). It also performs a reload_xml implicitly before reloading the ACLs. Flush Cache typically is used if you update sound files or other key components in FusionPBX to assure that the updated version is used rather than an earlier copy that still may be cached. When all else fails, it may be time to restart FreeSwitch from SSH: systemctl restart freeswitch.

We trust we’ve given you enough tips and tricks to get FusionPBX deployed and functioning. Now is probably a good time to read through the FusionPBX Getting Started Tutorial which covers some additional topics. Deploy at your own risk. We will tell you that gemini.google.com is your friend when you have further deployment questions about FusionPBX. We have found it to be an invaluable resource. Enjoy!

Originally published: Monday, June 23, 2025

Help with Asterisk or FusionPBX? Visit the VoIP-info Forum.

Special Thanks to Our Generous Sponsors

FULL DISCLOSURE: ClearlyIP, Skyetel, Vitelity, DigitalOcean, Vultr, VoIP.ms, 3CX, Sangoma, TelecomsXchange and VitalPBX have provided financial support to Nerd Vittles and our open source projects through advertising, referral revenue, and/or merchandise. As an Amazon Associate and Best Buy Affiliate, we also earn from qualifying purchases. We’ve chosen these providers not the other way around. Our decisions are based upon their corporate reputation and the quality of their offerings and pricing. Our recommendations regarding technology are reached without regard to financial compensation except in situations in which comparable products at comparable pricing are available from multiple sources. In this limited case, we support our sponsors because our sponsors support us.

BOGO Bonaza: Enjoy state-of-the-art VoIP service with a $10 credit and half-price SIP service on up to $500 of Skyetel trunking with free number porting when you fund your Skyetel account. No limits on number of simultaneous calls. Quadruple data center redundancy. $25 monthly minimum spend required. Tutorial and sign up details are here.

The lynchpin of Incredible PBX 2020 and beyond is ClearlyIP components which bring management of FreePBX modules and SIP phone integration to a level never before available with any other Asterisk distribution. And now you can configure and reconfigure your new Incredible PBX phones from the convenience of the Incredible PBX GUI.

VitalPBX is perhaps the fastest-growing PBX offering based upon Asterisk with an installed presence in more than 100 countries worldwide. VitalPBX has generously provided a customized White Label version of Incredible PBX tailored for use with all Incredible PBX and VitalPBX custom applications. Follow this link for a free test drive!
 

Special Thanks to Vitelity. Vitelity is now Voyant Communications and has halted new registrations for the time being. Our special thanks to Vitelity for their unwavering financial support over many years and to the many Nerd Vittles readers who continue to enjoy the benefits of their service offerings. We will keep everyone posted on further developments.