There are no two ways about it: Network security complicates voice-over-IP implementations.
But in tests at eWEEK Labs, we have seen that it is possible for VOIP to coexist at least with Secure Sockets Layer VPN security technology.
Typically, SSL VPN products enable an encrypted, user-initiated connection to a network resource, such as a file share or an e-mail server.
Using the nearly ubiquitous SSL tunneling capability included in almost every Web browser, users can make secure connections without the installation of any additional software on the client.
However, SSL VPNs that support VOIP usually do so with either a client shim, in the form of an ActiveX or a Java-based component, or a piece of client software provided by the SSL VPN vendor.
A good example of this is Aventail’s network tunnel service, which uses either an installed client (usually deployed like any other piece of corporate software, as part of an image) or an on-demand shim that is downloaded by the browser when a session is initiated.
Group Dynamics
To ensure a successful implementation of VOIP that will traverse SSL VPNs, one of the most important things to keep in mind is access policy creation and maintenance.
The best policy tools for VOIP govern groups rather than individual users.
We recommend looking for SSL VPN tools that can dynamically assign users to groups based on attributes that are determined by administrators during initial registration. Also look for tools that allow changes to be made at a group level.
For example, only members of the group called “sales” are allowed to make outgoing long-distance calls, or members of the group called “public lobby” are allowed to call only internal phone numbers.
We got a dose of what it means to be thorough in access-policy creation during our recent tests of SSL VPNs from Aventail and F5 Networks, when we evaluated the products’ ability to work with VOIP.
Click here to read more about SSL VPNs.
During one test, we were able to use a softphone to ring in through Digium’s Asterisk-based Trixbox system.
However, we could hear only one end of the conversation because we had failed to create a policy that allowed the other end to travel over our network.)
Also making VOIP over SSL VPNs tricky are the security deficiencies in the VOIP protocol itself.
An SSL VPN implementation can overcome some of these security weaknesses, however, by encrypting communication among clients and between clients and the server.
This security covers the data portion of the voice packet, preventing exploits that sniff a message as it passes along the public network.
In addition, by using an SSL VPN to facilitate an authenticated and allowed connection to protected VOIP network resources, some client registration hijack attacks can be prevented.
It’s clear from eWEEK Labs’ initial testing that all of the aforementioned configuration concerns can be overcome with current technology.
Network managers should leverage policy settings in SSL VPN tools, along with other proxy devices and firewalls that support the bidirectional session initiation required by VOIP technology.
Technical Director Cameron Sturdevant can be reached at cameron_sturdevant@ziffdavis.com.
Check out eWEEK.com’s for the latest news, views and analysis on voice over IP and telephony.