HowTo

Using Whaleback Crystal Blue VoIP in Linux

The company that I work for recently ditched its traditional PBX system in favor of a new VoIP service. Our VoIP system is provided and managed by Whaleback Systems. They provide a unique approach to VoIP in the sense that it isn’t an on-premise system or a standard hosted system. Their system is a hybrid of an on-premise and hosted solution, which they state is superior to other VoIP systems because they are able to get the best of both worlds. Either way, this isn’t a Whaleback review, the information provided above is merely a quick attempt to describe the type of system used.

Whaleback offers two types of endpoints to make calls with, a physical phone and a softphone. The current Whaleback softphone is provided by Counter Path. They provide a Windows and Mac OS X versions of their application. That seems decent enough of them. but what if you want to make calls from your Linux box?

Although there are probably countless softphones available for Linux, the default one in the distributions that I prefer include Ekiga. I have used Ekiga for PC to PC calls and found it rather useful. However, I need to make calls to business clients and they need to think that I am calling from my office. Regardless of OS or softphone used, calls placed from a softphone registered with a Whaleback voice server always originate from the physical location or number of the site that the server is located at.

Important Note: Although they are a great group of people, and a few of them use Linux, they do not officially support any softphone other than the ones that they provide. That being said, Whaleback is somewhat unique in that they do not offer a generic softphone download that you can install and configure. All of their softphones come to the user pre-configured with that user’s password, extension, and other information. This is the tricky bit, where do you get the information needed to plug into Ekiga? Answer: You call them and let them know that you are configuring a Linux softphone. Be sure to let them know that you aren’t expecting formal support of any kind. As with most things in life, if you are a polite human, they may help you out. You will need the following information, or at least the parts that you don’t know already: The external IP address that other softphones use to connect to your voice server, the internal IP of your voice server, your extension, and your password. They may be hesitant to give up your password or they may not give it to you at all. This depends on your demeanor and how their day is going.

Now that you have that information, make sure you have Ekiga installed and that you have gone through the configuration wizard. Generally, I accept all of the defaults that are presented to me, although I opt out of the free Ekiga service. Once that is complete, go to Edit -> Accounts. Click on add and enter a friendly name like Whaleback or WB. Your protocol must be set to SIP, not H323. Enter the internal IP address of your voice server into the Registrar field. Enter your extension into the User field and your password into the Password field. Review your settings and then click OK. Close the Accounts windows and go to Edit -> Preferences. Under Protocols -> SIP Settings, enter the external IP address of your voice server in the Outbound Proxy field. Assuming that you have followed these steps and have the right information, you should now be able to make calls.

Important Note: Although this might seem obvious, you must dial calls the same way that you do from a physical phone. In other words, if you have to dial 9 to get an outside line from your desk phone, you must do the same thing on the softphone.

I use this setup frequently from my Dell Mini 9 and my Dell Latitude D630 and love it. Because I am always on the move, my connectivity is typically the nearest open or recently opened ( XD ) WiFi hotspot around. For obvious reasons, WiFi is not ideal for voice as most access points use best effort for packet management. At home I have QoS on my wireless access points so this is much less of an issue. Regardless of the internet connectivity that you have available, you can improve or decrease quality as needed. To do this you simply go to Edit -> Preferences and go to Codecs -> Audio Codecs. You can select and deselect codecs as your needs require. Also note that you can move the codecs up and down in priority. Although all codecs may not be supported by your Whaleback voice server, Ekiga will negotiate the best available codec upon connection/registration.

This setup is so much more convenient than my last one. Happy dialing…

–Himuraken

Sonicwall GVPN w/ Simple Client Provisioning

In this post I am going to cover one of the ways that you can configure your Sonicwall device so that it provides secure client access to your internal network using the Sonicwall Global VPN client. There are several different ways that you can connect clients using the Global VPN client, but in this example I will cover one of the easiest and fastest ways to get the job done. For this example I will be using a Sonicwall TZ170 running standard OS. The steps will be nearly identical on other Sonicwalls running the standard OS. This configuration should also work just fine on devices running the enhanced OS provided that you aren’t running some off-the-wall configuration.

Step 1: Firewall configuration

Using your favorite browser login to your Sonicwall by going to https://x.x.x.x (<- Your IP here.) Go to the Users menu item and choose Local Users. Click on add and enter in the desired username and password for this user. Put a check mark in the “Access from VPN client with XAUTH” box and click OK.

Next we need to open the VPN menu item. By default there will be a VPN policy named GroupVPN. Make sure that this policy has the Enable box checked and then click on the edit button under Configure. The first two tabs require zero configuration for this how-to. Select the third tab which is named Advanced and make sure that “Require Authentication of VPN Clients via XAUTH” under Client Authentication is selected. On the client tab look for the setting “Cache XAUTH User Name and Password on Client” and change it to Always. Under Client Initial Provisioning make sure to place a checkmark next to “Use Default Key for Simple Client Provisioning” and click OK.

The final item to complete in this step is to send the GVPN policy to the client. Back on the main VPN page under Configure, click on the Export/Save button (Floppy disk icon). Accept all defaults on the pop-up window and click Yes. Once again, accept any defaults presented and enter a password so that the exported VPN policy is encrypted, this is important for several obvious reasons. Click on Submit and save the file. Now you can send the exported VPN policy to any user that needs it.

Step 2: Client Configuration

Using your MySonicwall account or original Sonicwall media install the Global VPN client on the desired PC and accept all defaults. Open the Global VPN client and press cancel when presented with the connection wizard. Go to the File menu and choose Import Connection. Click on the …Browse box and navigate to the exported GVPN policy. Now enter in that password that we used to encrypt the file earlier and click OK. You should now see the imported policy in the list of connections. Right click on the connection select Enable. Enter in the username and password that we created in step1 under Local Users. Put a checkmark in the “Remember my username and password” box and click OK. After a few moments of provisioning and passing encryption information, you should see the status as connected. Your client is now connected to your internal LAN securely via VPN.

Now you can create additional users as needed and send them the exported GVPN policy.

NOTE: I highly recommend sending the exported GVPN policy and encryption password separately. I generally accomplish this by emailing the policy and then sending a text message of the encryption password to the intended user and/or give it to the user verbally.

–himuraken

Exchange Outbound SMTP Smart Hosting

There are countless situations in which you might not want to send email via SMTP directly from your site. Maybe you aren’t familiar with PTR’s and A records, or maybe your IP has been blocked / banned via your ISP or some external RBL. If your mail host allows you to use their server as a smart host, you can avoid most of these worries. Up until recently most mail traveled to and from servers and clients using the SMTP protocol which runs on 25 (TCP). Several mail hosts and ISP’s are now requesting or flat out requiring that the mail be submitted to their servers using the more modern mail submission port which is 587 (TCP). For more information on this please see this link. In order to successfully complete this how-to, you must get in touch with your mail host and see which port they want mail submitted on.

I will use port 587 in this example since this is what my mail hosting company requires.

Step 1: Configure Exchange to use the desired port

Open up the Exchange System Manager and expand Servers, Your Server, Protocols, SMTP. Expand SMTP and right click / properties on the Default SMTP Server. Go to the Delivery tab and then click on Outbound Connections. The last box is the port that Exchange is currently configured to send mail on. Once again, for my mail host port 587 is required. Click OK until you get back to main window of Exchange System Manager.

Step 2: Create an SMTP Connector to route mail

Right click on the Connectors folder and choose New -> SMTP Connector. Name the new connector and then choose the option to “Forward all mail through this connector to the following smart hosts.” Now enter in the hostname provided to you by your hosting company. This is usually the same as the outbound mail server that you would configure in your mail client. Under local bridgeheads click add. Select your Exchange server and click OK. Next, select the Address Space tab and click add. Choose SMTP and click OK. Leaving the default email domain of * and the default cost of 1 should be sufficient depending on your Exchange configuration. Click OK after confirming these defaults.

From here we need to configure outbound authentication. Select the advanced tab and click on Outbound Security. Click on “Basic authentication password is sent in clear text” and then click Modify. Enter in the username and password that was given to you by your mail host. Hit OK until you are back down to the main Exchange System Manager window.

Step 3: Verify the configuration

Start by going to start run and typing in services.msc. Locate the Simple Mail Transfer Protocol server and restart it. Now open up Exchange System Manager again and expand Servers, Your server name, Queues. Send a few test email messages from a client machine and watch the queues. If you see domains that were recently sent to showing a ready state all should be well. If you see domains that have a retry status and messages piling up there is an issue somewhere. Go back through all of the settings mentioned above and look for typo’s, misspellings, and other possible obvious points of failure in the configuration. Double check with your mail host and be sure that you are using the correct information.

NOTE: After correcting any issues found, right click on the failed queues and try forcing the connection. It is sometimes necessary to right click each domain and find messages and then delete them.

–himuraken

Terminal Services Audio Mapping

I am often asked how to enable audio mapping (audio redirection) for Terminal Services users. Configuring audio mapping is quite simple. A small configuration on the server and client is all that is necessary.

Step 1: Enable Audio Mapping on the Terminal Server

On the terminal server go to Start -> Administrative Tools -> Terminal Services Configuration. Select Connections on the left pane and then right click and get properties on the RDP-Tcp connection within the right pane. Click on the client settings tab and under Disable the following, uncheck audio mapping. Hit OK and then close the Terminal Services Configuration windows. Important note, these changes will only take effect for RDP sessions created after the configuration changes are applied.

Step 2: Verify client settings

On the client PC open the remote desktop connection. Click on Options and then select the Local Resources tab. Make sure that the Remote Computer Sound option is set to “Bring to this computer”.

Sounds produced on the terminal server should now be redirected to the client PC.

–himuraken