PBX in a Flash vs. trixbox

As promised, I have spent some time comparing the various benefits of PBX-in-a-Flash over trixbox. In a nutshell, my conclusion is relatively straightforward.

It's worth switching.

Why, you may ask? Well, the reasons are many and varied, but here are the high points:

1) Upgrades. If you've spent any time poring over the various email lists for trixbox, you will quickly come to realize that the general consensus with respect to upgrading trixbox is as follows: if it ain't broke, don't fix it. Upgrading trixbox can be a nightmare (something I've personally experienced), and the simplest solution is to either (a) live with an older version; or (b) do a clean install. Upgrading PBIAF, though, is really, really simple, and it actually works. Everything is web-based, wizard driven, and painless. In fact, the default installation regularly checks for both core and module upgrades, and offers to do it for you.

2) Extending functionality. PBIAF has a rapidly growing set of modules that are simple to install, and add nice functionality to the base system. Wait, you say -- so does trixbox! Well, yes, it does, but when it comes to installing and upgrading these modules, PBIAF is the hands down winner.

For these two reasons alone, it's worth the upgrade. 

Highly recommended.

PBX in a Flash

Last week I downloaded and installed the new PBX in a Flash alternative to Trixbox. I have had excellent luck with Trixbox, and no real complaints, but I like to keep abreast of things, had some time on my hand, and thought I'd give it a whirl.

I am impressed.

Installation was simple, and it has all the functionality of Trixbox, and then some. Like Trixbox, it uses FreePBX for the actual management of the PBX, but unlike Trixbox, it runs on CentOS 5, and lacks the annoying "feature" of having all Zap functionality die if you happen to be running on a non-multicore CPU.

There are a host of modules already available, including some nifty text-to speech features, but I haven't had an opportunity to test those as of yet. I plan on doing so next week, just to see how things work.

One added bonus -- for some reason, PBX-in-a-Flash actually fixed one annoying problem I had with Trixbox: on my outbound trunk using Vonage, I often had problems with IVRs (when I was dialing the phone company to complain about another billing error, for example). The whole "press one for sales, two for tech support" etc. didn't work a lot of the time. Now it does.

That alone was worth making the switch.

Browse securely with OpenVPN

Sometimes you find yourself in a situation where you are forced to connect to the outside world through a decidedly insecure connection. Perhaps you are in an airport, using free Wifi, or a hotel room. Or, maybe you happen to be on the Rogers network, and you've read about the tendency of that ISP to watch what you are doing on line. Whatever the case may be, you are in a situation where security is somewhat less than ideal. If you have access to a machine on a secure connection somewhere else in the world, and that machine has either a static IP address or is configured through a free service such as dyndns.org, you can set things up so that all your Internet traffic is encrypted, and passes through the known, secure machine before coming to your local machine.

This is not difficult to set up.

First, you have to have OpenVPN server set up on the remote machine. We have covered this before, so if you don't have it in place, then go install and configure it. The instructions here are virtually identical to those we set up before, with one important difference -- we are going to tell OpenVPN to redirect all traffic through itself, so nothing going to your local machine (which I'll call a laptop) or leaving it will pass unencrypted. You are browsing so that all traffic is SSL encrypted.

You will recall that OpenVPN server is conrtolled using a file in /usr/local/etc/openvpn (at least on FreeBSD). Copy that file to one called "openvpnredir.conf" and edit it. We are going to change two things: the port that OpenVPN listens to, and we are going to add a directive that tells OpenVPN to redirect all traffic through its secure connection. Here is the file, with the changes higlighted in red.

# Specify device
dev tun

port 1195

# Server and client IP and Pool
server 10.9.0.0 255.255.255.0
ifconfig-pool-persist ipp2.txt

# Certificates for VPN Authentication
ca /usr/local/etc/openvpn/ca.crt
cert /usr/local/etc/openvpn/server.crt
key /usr/local/etc/openvpn/server.key
dh /usr/local/etc/openvpn/dh1024.pem


# Routes to push to the client
# in the next line 192.168.xxx.0 should be the ip range of your internal network
push "route 192.168.xxx.0 255.255.255.0 default" 

# route all traffic through vpn
push "redirect-gateway def1"

# Use compression on the VPN link
comp-lzo

# change the ip address in the next line to whatever dns you want to use
push "dhcp-option DNS 192.168.0.100"

# Make the link more resistant to connection
failures keepalive 10 60
ping-timer-rem
persist-tun
persist-key

# Run OpenVPN as a daemon and drop privileges to user/group nobody user nobody
group nobody
daemon

As you can see, the changes are minimal. Now, on the client side, find the configuration file you use to set up a VPN connection. On Macs, it's in ~/Library/openvpn. On Windows, it's usually in C:/Program Files/OpenVPN/config.

Duplicate that file, and change the name to something meaningful (i.e. Redir OpenVPN, or whatever), and then change the line that reads "port 1194" to "port 1195".

Now, you should have a new vpn connection available to you, and all traffic will go through the VPN server.

Trixbox phones home?

Nerdvittles has an interesting post today -- apparently, trixbox phones home at 3:41 AM each day and gets a list of shell commands to run:

You may have read that a user discovered last week that current trixbox systems as recently as today include a remotely-configurable BOT, a software program that can execute certain commands locally once it receives its instructions. Reportedly, trixbox’s registry.pl “phones home” to Fonality via the Internet at 3:41 a.m. each morning to get a list of Linux commands to run. It then executes those Linux commands on your server while you’re sleeping. If the assertions of trixbox end users are true and we have no reason to believe otherwise, the existence of this remotely-configurable BOT had never been disclosed to unsuspecting users whether they were individuals or corporations. In fact, it doesn’t appear that even trixbox resellers were aware of the existence of the remotely-configurable BOT.

This is interesting, and disturbing. To be fair, the folks at Nerdvittles suggest that they "don’t for a minute believe that Chris Lyman and other senior management of Fonality knew about this in advance", but they certainly know about it now!

This is cause for concern. Since the ability to remotely execute shell commands exists, it's only a matter of time before someone else figures out how to exploit it.

Maybe it's time to accelerate my testing of pbx-in-a-flash....

Use the Linksys SPA922 as a Remote Extension

Last time I mentioned that I had used the Linksys SPA922 IP Phone as the "handset of choice" for phones. I also indicated that I wanted to have one as a remote extension -- i.e., it has a standard extension number, is part of the PBX system, can make and receive calls, etc., but is physically outside of the network.

This turned out to be relatively easy, once I figured out the firewall settings.

Setting up a remote extension using Asterisk/Trixbox is not that difficult, and consists of three basic steps:

1) Create the extension in Trixbox

2) Make some firewall modifications on the trixbox end

3) Plug in and configure the remote extension itself (i.e. the physical phone)

These steps are explained in more detail below:

Create the Extension in Trixbox

First we need to have an extension to play with, so we'll log onto our Trixbox installation using our favourite web browser, and choose "FreePBX" from the "Asterisk" menu. This pops up a new browser window (or tab) and allows us to create a new extension, among other things. Choose "Setup" from the top menu, then "Extensions" from the menu on the left, and create a new SIP extension. Fill in values similar to the ones below, substituting where appropriate for your information. For example, a "secret" of "verysecret" is probably not a good idea.

Make certain that you have "nat" set to "yes".

The only other thing we need to take care of within Trixbox is a tiny modification to the sip_nat.conf file. Again, we can do this using our web browser. Close the browser window with FreePBX running, and you should be back in the Trixbox admin window. Choose "Config Edit" from the "Asterisk" menu, and then scroll down until you find "sip_nat.conf". In a default installation, it is empty. Put in values like the following:

extern_ip=xxx.xxx.xxx.xxx

localnet=192.168.0.0/255.255.255.0

The first line, extern_ip, is the external (public facing) ip address of your Trixbox. Note that you probably don't have one, so instead put the public IP of whatever router, gateway, etc. you use to get access to the outside world.

The second line, localnet, describes the subnet that your Trixbox installation lives on.

Now, reload your configurations in Trixbox, and we are ready to configure our firewall.

Firewall Modifications

We need to make some modifications on the Trixbox end of the network (i.e. not at home, if that's where your remote extension is, but on the the end of the connection where your Trixbox PBX lives). Specific modifications will vary depending on what you are using for a router/gateway, but in general there are only a few things to change. I am using a Linksys machine as the external gateway, so I made changes as follows:

In essence, forward the following to your Trixbox machine:

5004-5082 udp
16384-16482 udp
10001 - 20001 udp
4569 udp (optional, and only for IAX2 units; ignore if you are just using sip)

Make these changes, and we are ready to set up the phone itself.


Configure the SPA922 IP Phone

As before, I simply unpacked the phone, found a place for it on my desk at home, and plugged it in. After a few seconds, it found itself an IP address and did its best to find dial tone. Naturally, it failed, but I did appreciate the effort.

All configuration on the SPA922 can be done with a web browser... but you need to know what IP address to connect to. After it has powered up, click on the "menu" button on the handset. It looks like a dog-eared piece of paper, just below the voice mail button. Now use the navigation button (big circle with four arrows) to scroll down to Network, and click the select soft button (leftmost, just below the LCD. Its label is part of the LCD). You'll see your phone's IP address displayed on the LCD. Mine was set to 192.168.2.149.

So, fire up your web browser, and go to http://192.168.2.149, or whatever IP address your phone has. You'll see the Linksys screen. Click on "Admin Login" in the upper right hand corner, then "Advanced." Note that by default the phone ships with no password for the admin tool; please remember to change that at some point (like right now).

Click on the Ext1 tab, and scroll down to NAT Settings. Set NAT Mapping Enable and NAT Keepalive Enable to "YES". Scroll down to SIP Settings. Set SIP Port and Ext SIP port both to 5062.

Next scroll down to the "Proxy and Registration" section. Set "Proxy" and "Outbound Proxy" to the external IP address used by your Trixbox machine. Set "Use Outbound Proxy" and "Use OB in Dialog" to "Yes".

Scroll down to Subscriber information, and set User ID to the extension number for your phone, and password to whatever "secret" you set up in Trixbox for this extension.

Now scroll down to Audio Configuration. Set DTMF Tx Method to "Inband+INFO". (Note: I had to do this to get most IVRs to work, i.e. when I call someone and have to press 1 for this, 2 for that, and so forth. YMMV).

Click on "Submit all Changes."

Now, go to the SIP tab. Scroll down to RTP Parameters. Set RTP port min to 16384. Set RTP port max to 16482. Now, scroll down to NAT Support Parameters. Set Handle VIA received, Insert VIA received, Substitute VIA address, Handle VIA rport, and Insert VIA rport all to "Yes."

Save your changes, and in a few moments, you should be able to make calls!