Xuridisa Blog

From previous blogs it should be apparent that we really like the pfSense firewall platform.  For one it is free (a great starting point but not the final word), but the features and capabilities are just fantastic.  On this occasion we are impressed by the IPsec VPN capabilities of pfSense for interoffice networking.

Before we get started you should also be aware that pfSense has the powerful OpenVPN software bundled in addition to the IPsec and PPTP VPN capabilities.  We have always used the OpenVPN option for so called “Road Warrior” (mobile user) configurations.

In this instance our customer requirement is to establish secure connections, utilising the Internet for data transfer, between 2 offices based in Auckland.  It is possible that in future an office from Australia will be brought in (no worries at all mate).  In addition to the interoffice links there is a tunnel into Xuridisa for key hosted services such as DNS and mail in this case.

We had considered using the OpenVPN portion of pfSense to service the interoffice links also.  But, frankly it was just looking a little too complex for what we wanted to do quickly.  Enter the standard IPsec VPN functionality of the product.  Using this functionality is was exceedingly simple to define the tunnels (using shared keys) and have the links up and running in literally a matter of minutes.

One unexpected benefit of the IPsec VPN solution over having used OpenVPN is the ability to create firewall rules (ACLs) on the IPsec tunnels.  While the links between the customer’s offices are completely unrestricted (that’s an easy rule on both sides) the ability to define rules (exactly the same as for other interfaces) allows Xuridisa to perform the border management and security on the firewall (where it belongs).  If this functionality had not been present it would have been necessary to move the additional security requirement onto Linux kernels iptables of each hosted server (clearly less desirable).

The tunnels are created to use Blowfish encryption and SHA1 hashing.  After having run for a week there is no measurable effect on the CPU (or other resources) of the pfSense servers.  Granted there is not a heck of a lot of traffic going down these pipes (constrained by ADSL speeds) but still, we were expecting to see at least some increase.

So basically our favourite firewall platform shines again when we ask for something new.  Again, what a fantastic firewall platform pfSense is!

No doubt everyone is very familiar with the concept of Asynchronous Digital Subscriber Line (ADSL) as a broadband option for the home and SOHO customer.  Many of New Zealand’s exchanges are either upgraded (or scheduled to be) to the new ADSL2+ technology which broadens the speed potential from the 8Mbps/800Kbps (download/upload) of ADSL to 24Mbps/1Mbps.

Without exception I’m confidant every home user has experienced the frustration with congestion during peak times, making what should be a perfectly reasonable service (based on download/upload negotiated rates) appear fairly unimpressive.  Effectively this is down to (aside from contention ratios etc. that everyone always talks about) the fact that there is no minimum bandwidth offered on a residential ADSL connection.

Well, until now…  With the exchange modernisation and deployment of new ISAMs in roadside cabinets the services being offered from Telecom Wholesale are now a lot more interesting.  The focus of this Blog is EUBA, but there is an alternative more high level (read small enterprise) solution called High speed Network Services (HSNS) which is in simple terms a go fast version of the existing Synchronous Digital Subscriber Line (SDSL) which has symmetric download/upload speeds.  A single HSNS circuit is up to 5Mbps/5Mbps and many channels can logically be bonded into a single larger circuit.

Anyway, back to EUBA specifically.  EUBA is based on the ADSL2+ service, but introduces a very critical bandwidth commitment component.  Current services allow for 40Kbps, 90Kbps or 180Kbps with a 250Kbps (or thereabout) offering expected any time.

What is special about this committed bandwidth?  One word, voice!  With VoIP becoming increasingly popular in the market place, and the inevitability of the traditional phone system having a finite life a lot of customers (and even home users) are now considering an entry into the VoIP scene.

The 40Kpbs service doesn’t really seem to serve any immediate purpose in our view, but at the 90Kbps mark that is one concurrent SIP phone call using the G.711 codex (very good quality voice).  Obviously the 180Kpbs service can therefore manage two concurrent calls at G.711 quality.  Opting for the G.729 codex (some compression) the 180Kpbs service is good for three concurrent calls.  This level of service is perfect for a good number of New Zealand small businesses.

Speaking of service levels, or Quality of Service (QoS) this is how the EUBA service is managed.  Data is prioritised on the network so that time sensitive protocols/data can be given a greater priority and service than other general traffic.

Xuridisa has its first customer implementation occurring right now on the EUBA 180Kpbs service so it will be very interesting to work through this end-to-end.

As mentioned briefly EUBA is a service offered by Telecom Wholesale.  While readily available to the market it has not yet been released commercially by a good number of telcos (including Telecom and Orcon).  As seems to be the case more and more we are again dealing with our preferred communications company, Solarix, who are able to offer this, and the big brother HSNS services right now.

Objective: Find a SIP softphone with a nice/tidy user interface (with as little addware as possible) that integrates well with Microsoft Outlook.  The Skype Toolbar for Outlook is an example of an add-in which is considered to be functional.

Whenever the need for a SIP softphone has materialised we have pretty much always used (without any thought at all) the free X-Lite softphone from CounterPath.  Don’t get me wrong, without question this is still an excellent SIP client, but it does not integrate with Microsoft Outlook at all so immediately does not meet the objective in this case.

CounterPath has alternative (paid) products like eyeBeam and Bria which allow you to import contacts from Outlook.  While this capability does go some way to the Outlook integration goal it is really not an ideal solution in our view.  In order for us to be satisfied that the products are completely integrated there needs to be right-click calling capability from Outlook Contacts at the very least, and perhaps a nice toolbar add-in.

There is a special version of Bria, called Bria for Microsoft Outlook.  This appears to be (not able to verify as a demo is not offered) a completely integrated solution for Microsoft Outlook and on first review looked almost perfect!  There is a nice and better yet seemly fully functional toolbar in Outlook, but there was no mention of a taskbar application which could be used when Outlook may not have been running.  A question to the CounterPath folk confirmed this to be the case.  It was too good to be true <sign>!  While Outlook integration was a necessity, functionality outside of Outlook was also essential in our view.

So CounterPath was out, and the search began for some alternatives…

On a recommendation from a respected source we had a look at Zoiper Communicator as a possible alternative.  They have both a free and paid version of the software.  As per CounterPath it was not possible to get an evaluation version of the full product which does (reportedly) have an Outlook plug-in.  One thing which is of interest about Zoiper is that in addition to being a SIP client it also an IAX (Asterisk proprietary protocol) softphone.

All was looking pretty dim, and sorry to say it is.  Compound this with the Outlook 2010 (part of the Office 2010 suite) now in beta and a radical redesign interface wise (it has finally adopted the ribbon used by other Office applications).  Now even the Skype plug-in is a little obscure and less useful (or at least obvious).  So it was decided to part this for the timing being and allow the Outlook 2010 product to hit the market, and for the vendors to find ways to better integrate their offerings with it.

With that it’s back to X-Lite.

We have been working with a customer recently implementing a VoIP solution for a new office. Based on previous experience with Polycom quality handsets Xuridisa recommend the Polycom SoundPoint IP handsets to ensure a quality user experience.

As an aside the VoIP server backend for this project is provided by trixbox CE, also implemented by Xuridisa. trixbox is a very mature PBX platform based on the Asterisk open source PBX platform.

Anyway, back to the subject at hand, configuring the handsets for daylight savings...

Frustratingly there does not appear to be a standard method to configure IP based handsets (each manufacturer has their own variation). The following are the necessary configuration options for the ‘sip.cfg’ file on the trixbox provisioning server. For people not necessarily using trixbox or another Astreisk variant the ‘sip.cfg’ file appears to be somewhat common (or at least similar) between a few different platforms we have investigated.

These settings are accurate for New Zealand DST regulations as at the time of this post (6th January 2010):

• tcpIpApp.sntp.daylightSavings.enable="1"
• tcpIpApp.sntp.daylightSavings.fixedDayEnable="0"
• tcpIpApp.sntp.daylightSavings.start.month="9"
• tcpIpApp.sntp.daylightSavings.start.date="0"
• tcpIpApp.sntp.daylightSavings.start.time="2"
• tcpIpApp.sntp.daylightSavings.start.dayOfWeek="1"
• tcpIpApp.sntp.daylightSavings.start.dayOfWeek.lastInMonth="1"
• tcpIpApp.sntp.daylightSavings.stop.month="4"
• tcpIpApp.sntp.daylightSavings.stop.date="1"
• tcpIpApp.sntp.daylightSavings.stop.time="3"
• tcpIpApp.sntp.daylightSavings.stop.dayOfWeek="1"
• tcpIpApp.sntp.daylightSavings.stop.dayOfWeek.lastInMonth="0"

In plain engilish the above settings will start daylight savings on the last Sunday of September at 02:00, and end on the first Sunday of April at 03:00.

For your benefit the following is the except from the Polycom Admin Guide: