Home » WhiteListing Users with Travelin’ Man 3 and IPtables Firewall

The Most Versatile VoIP Provider: FREE PORTING

WhiteListing Users with Travelin’ Man 3 and IPtables Firewall

Preparation. Before making modifications to your IPtables firewall, make a list of all the folks that will need access to your Incredible PBX Server. For each entry, write down the name of the person, server, or phone as well as the type of entity which needs server access. Then provide either the static IP address or FQDN for each entry. If one or more of your IP addresses are dynamic (meaning the ISP changes the address from time to time), we’ll cover managing dynamic IP addresses below. For now, just make up a fully-qualified domain name (FQDN) for each dynamic IP address using one of the available Dynamic DNS providers. For static IP addresses, use the FQDN or the IP address. HINT: FQDNs make it easy to remember which entry goes with which provider.

Make a list of your providers NOT in this list: Vitelity (only outbound1.vitelity.net and inbound1.vitelity.net are preconfigured), Google Voice (talk.google.com), VoIP.ms (somecity.voip.ms), DIDforsale (, CallCentric (callcentric.com), and also VoIPStreet.com (chi-out.voipstreet.com plus chi-in.voipstreet.com), Les.net (did.voip.les.net), Future-Nine, AxVoice (magnum.axvoice.com), SIP2SIP (proxy.sipthor.net), VoIPMyWay (sip.voipwelcome.com), Obivoice/Vestalink (sms.intelafone.com), and Teliax. The providers listed above are already enabled during the initial setup of your server. We call them Trusted Providers only because we trust them and have personally used all of them. We consider them reliable companies with whom to do business. It doesn’t mean others aren’t. It simply means these are ones we have tested with good results over the years. The only providers you’ll need to add are ones we haven’t provided. If you register your server to a trunk provider, you do not need to add a WhiteList entry to IPtables. Also be sure to check whether the FQDNs of the providers above cover the server for your account. If not, you’ll need to manually add those FQDNs as well. Keep in mind that trusted providers will have full SIP and IAX access to your server so stick with tried-and-true providers for your own safety.

Finally, list with a name each remote or mobile phone that will be connected to an extension on your server. If you have 10 traveling salesmen, then you might want to name them all by last name and also provide FQDNs with their last names, e.g. smith.dyndns.org and jones.dyndns.org. No spaces or punctuation in names or FQDNs! We strongly recommend using FQDNs wherever you can because it means zero work for you when a provider changes an IP address. Here’s the table we use:

Type: Person, Provider, Server, Phone
IP Address Type: Static or Dynamic
FQDN or IP Address
Services Desired: SIP, IAX, Web, FTP, SSH, etc.

Adding Authorized Users. Now take your list and add each account to your server while logged in as root and positioned in the /root directory. For static IP addresses, use add-ip. For dynamic IP addresses and FQDNs, run add-fqdn and plug in the FQDN for each account. When one of your accounts needs to be removed, just run del-acct from the /root folder on your server and plug in the name of the account to delete. If a user changes from a static IP address to a dynamic IP address or vice versa, just delete the user and then add them again with the new IP address or FQDN. All of the accounts are stored in /root and have names like this: name.iptables.

Setting Up DynDNS Client Updates. There are actually two pieces in the Dynamic DNS update puzzle. On the end-user side, you need to deploy a DynDNS update client on the same subnet as the phone of your user. In the case of cellphones with SIP phone capability, this could be as simple as installing the DynDNS update client directly on the phone itself. Plug in your DynDNS credentials as well as the FQDN associated with the particular phone, and the rest is automatic.

Setting Up IPtables Auto-Refresh. Finally, we need a way for your server to discover when a refresh of FQDNs becomes necessary because someone’s IP address has changed. The simplest way to do this is to automatically run a simple script (ipchecker) that polls the DNS authoritative server to determine whether the dynamic IP address associated with an FQDN has changed. If so, we’ll update the account.iptables file to reflect the new IP address and then restart IPtables. This will refresh all IP addresses associated with FQDNs. If all or most of your users spend time sleeping each day, you may wish to run the script only during certain (waking) hours of the day so your server has less of a load. The other consideration is how often to check. The guideline here is how long can any user live without their SIP phone being connected to your server. 10 minutes may be reasonable for some, and this is the default setting with newer installs of Incredible PBX. 60 minutes may suffice for others. For us, it’s 3 minutes. It’s your choice. The way Travelin’ Man 3 works is, whenever at least one account has an IP address change, it will trigger a restart of IPtables to do an IP address refresh for all of the FQDNs.

Update: The latest release of TM3 for the Incredible PBX for Wazo platform eliminates the need to manually edit the ipchecker script at all. If you open ipchecker and do not see the following section, don’t be alarmed. There’s no action required on your part. This applies to version 2.2 or later of ipchecker.

The top of the /root/ipchecker script in /root typically looks like this:


# Insert the account filenames to be checked below
# Remember to increment the account[#] for new entries


You’ll need to edit the script (nano -w /root/ipchecker) and modify the section in bold to reflect the actual FQDN account names you’ve created on your server that are associated with dynamic IP addresses only. You don’t want to monitor accounts with static IP addresses or FQDNs that never get updated. When those extensions are off-line, it’s not because their IP address changed, and restarting IPtables won’t really help to improve the situation. Be sure to increment the account[n] array for each new account that you want to monitor and use the exact format shown in the example above, and remember to uncomment any existing sample entries if you wish to use them. Before you enter an account in the script, display the contents of the file using cat /root/accountname.iptables. Make certain that the file includes BOTH an FQDN, then a space, and then an IP address. If not, delete the account (del-acct) and add it again using add-fqdn.

Once you’ve entered all of your accounts with dynamic IP addresses, save the script: Ctl-X, Y, then Enter. Run the script manually now to be sure it works as you intended: /root/ipchecker. Be advised that typos that list accounts that don’t exist will cause problems. Error checking consumes processing cycles by requiring additional queries so we’ve left it out. That means it’s solely up to you to check your account names for accuracy. And, remember, only include accounts that have dynamic IP addresses with FQDNs.

Automating FQDN Refreshes with Cron. As mentioned, the ipchecker script is preconfigured to run every 10 minutes on Incredible PBX servers of recent vintage. To make changes, edit /etc/crontab using nano. If you wanted the script to run 24 hours a day at 10 minute intervals, here’s the command:

*/10 * * * * root /root/ipchecker > /dev/null

If you wanted the script to only run between the hours of 8 a.m. and 9 p.m. (server time zone) at 10 minute intervals, then you’d use something like this:

*/10 8-21 * * * root /root/ipchecker > /dev/null