Posts from the ‘Networking’ Category
Setting up a local Firefox Sync server
I love Firefox. Aside from the quite awesome levels of cross-platform support, I’m a big fan of the built-in Sync feature. For those concerned about security and privacy, Mozilla provide instructions for setting up your own Sync server, and the good news is that it’s a snap to get a basic server up and running.
For a start, on an Ubuntu 10.04 x86 VirtualBox VM, I followed the “Prerequisites” and “Building the server” sections here:
http://docs.services.mozilla.com/howtos/run-sync.html
My server VM is running with bridged networking on my local network with its own IP address.
Upon running the server and attempting to connect from other Firefox clients, I ran into two problems which I don’t believe are documented at the above link.
First, I could not get clients to connect successfully to the server using the handy “Add a Device” Sync feature. To troubleshoot and resolve this, I performed the following steps.
Set up Firefox sync on the relevant client browser.In the Firefox client, launch the Firefox configuration page by entering about:config in the address bar (more information on this may be found here).Use the search filter to narrow down the entries relevant to Sync settings.
I noted that the setting named services.sync.serverURL was correctly pointing towards my server. I would have thought that this was sufficient to get Sync working, but apparently not: in my case, the setting named services.sync.clusterURL was pointing to localhost, and this also needed to be set to the server address (i.e. identical to the value set for services.sync.serverURL). Once done, the client could then successfully connect to the Sync server.
Update to the above: This is resolved by modifying the fallback_node property of the Sync server sync.conf file. There is a somewhat misleading reference to this in the official documentation, which says (at the time of writing):
“Warning: If you run behind a server, you need to set up the fallback_node option in the [auth] section accordingly…”
What is actually meant is if the server is serving multiple remote (i.e. non-local) clients, then the server address should be set in the fallback_node property. By default, the property is set to the following in the sync.conf file:
[auth] backend = services.auth.sql.SQLAuth sqluri = sqlite:////tmp/test.db pool_size = 100 pool_recycle = 3600 create_tables = true fallback_node = http://localhost:5000
If the IP address of my server is 192.168.1.4, then I would modify this to read:
[auth] backend = services.auth.sql.SQLAuth sqluri = sqlite:////tmp/test.db pool_size = 100 pool_recycle = 3600 create_tables = true fallback_node = http://192.168.1.4:5000
Clients should then connect to the Sync server seamlessly.
Second, once my clients were happily syncing up with my server, upon rebooting the server every one of them crapped out with a Sync authentication error. It turns out that the authentication database by default is stored at /tmp, so on reboot of course everything goes kablooey. Again, this is not documented clearly in the setup guide, but it can be resolved by performing the following.
Inspecting the contents of the Sync sync.conf file, the location of the storage and authentication databases can be specified. By default, the locations are defined as follows:
[storage] backend = syncstorage.storage.sql.SQLStorage sqluri = sqlite:////tmp/test.db standard_collections = false use_quota = true quota_size = 5120 pool_size = 100 pool_recycle = 3600 reset_on_return = true display_config = true create_tables = true [auth] backend = services.auth.sql.SQLAuth sqluri = sqlite:////tmp/test.db pool_size = 100 pool_recycle = 3600 create_tables = true fallback_node = http://localhost:5000
I changed these to point to a database that will instead be created at /var/sync:
[storage] backend = syncstorage.storage.sql.SQLStorage sqluri = sqlite:////var/sync/sync.db standard_collections = false use_quota = true quota_size = 5120 pool_size = 100 pool_recycle = 3600 reset_on_return = true display_config = true create_tables = true [auth] backend = services.auth.sql.SQLAuth sqluri = sqlite:////var/sync/sync.db pool_size = 100 pool_recycle = 3600 create_tables = true fallback_node = http://localhost:5000/
After reconfiguring all Firefox client Sync connections, authentication then continues to function after the Sync server is rebooted.
Sync also works successfully from Firefox running on the Eee Slider Pad as well, if the first troubleshooting step is performed.
See also: http://www.wenks.ch/fabian/mozilla-custom-sync-server/
TeamViewer (and other remote assistance products)
So, I’m on the lookout for a cross-platform remote assistance product, which will allow me to remotely manage Linux, Mac OS X, and Windows computers from a machine running potentially the same operating system(s).
After having a sniff around online, it would appear that TeamViewer is the only application which really meets my needs, from the standpoints of a) feature set and functionality and b) licensing.
On the licensing point, it seems that TeamViewer is bucking what otherwise seems to be a popular method of delivering remote assistance products via a parasitic Software as a Service subscription: the thought of getting gouged every month for the privilege of using an application which I should really be able to install and use standalone is pretty unappealing, really.
A couple of examples of the other remote assistance products out there I briefly looked at before balking at the usage restrictions…
Leading the way in wacky product naming, check out LogMeIn. Let’s see, we have:
- LogMeIn Pro²
LogMeIn Free
LogMeIn Ignition
LogMeIn Backup
LogMeIn Rescue
LogMeIn Hamachi²
LogMeIn Central (“works with LogMeIn Pro², LogMeIn Free and LogMeIn Hamachi²” apparently…)
Aside from being subscription-based, not really being able to deduce which product does what without wading through the marketing materials is a massive turn-off. It’s a bit like the Microsoft Vista approach, designed for maximum confusion. Another win for TeamViewer, which is offered in three editions (Business, Premium, Corporate), plus a free-for-personal-use version.
And over here, we have GoToMyPC, and GoToAssist, both apparently made by the same outfit. At 70 bucks a month for the latter “service” (not even sure if that’s NZD), I’m pretty confident that TeamViewer by comparison would quickly work out as a better value.
Cisco WRVS4400N – Skype blocking will never work
Just a quick update in my continuing experience with the Cisco WRVS4400N. As mentioned previously, I and other users have had problems using the device’s IPS facility to block Skype connections, contrary to its feature set which says it’s supported. After raising a support call with Cisco, I have heard back from a support engineer, and they state “since Skype has changed three times since the release of the WRVS4400N, we will not be able to fix this issue”.
So, if you depend on a router for the effective blocking of Skype use by employees on your network, the WRVS4400N obviously cannot be recommended for this specific feature.
WRVS4400N – more impressions, and Cisco tech support
I recently blogged my first impressions of a SOHO security router I am evaluating, the Cisco WRVS4400N.
It’s a seemingly neat product at a great price, but it does have some problems, mostly fairly minor. In the process of working through these issues, I have been acquainting myself with the various support channels Cisco offer for their small business products.
Cisco run a small business support community forum (based on Jive Software). I’ve found that it’s apparently not at all unusual to have fairly reasonable queries go completely unanswered for days and days – in one case, not at all (at the time of writing). My question about Mac OS support for Quick VPN for example was apparently ignored by Cisco support personnel frequenting the forums – whereas all it would have taken would have been a brief confirmation message (“yes it’s planned/possible” or “no it’s not”), or perhaps a pointer to the eventual solution which I located myself on the very same section of their site, helpfully contributed by a non-Cisco forumite.
Another recent query I made online regarded the apparent failure of the device’s IPS facility to detect and block Skype connections. My posting on this (in response to someone else who had in fact managed to elicit a response from Cisco a few months back on the same issue), went ignored too.
I’d assumed (given the low price of the router) that “official” tech support would cost extra, but as it turns out, it comes with a full 12 months of telephone support. My experience with this was the complete opposite of the forums; no hold time at all, and within moments I was connected to a friendly and very helpful Cisco staffer based in North America. Within five minutes I had a satisfactory answer to my query (yes, it is a known issue), and my forum post was updated instantly with the same information and a suggested workaround. Maybe I’ve spent too many hours on the phone to Dell’s tech support, but this really was a pleasant surprise. If this is the level of phone tech support one can expect for Cisco small business products, and it’s offered for a year, then this definitely counts in the product’s favour, in spite of the problems I am personally encountering with it.
Cisco WRVS4400N – first impressions, and Mac OS VPN support
As I mentioned here, I’m spending some time evaluating this wireless security router for use in a small office environment.
So far, I’ve had no complaints about the basic operation and build quality of the device. It’s stable, and has a well-built (albeit all-plastic) feel to it. Its web admin BUI is also very nice – a definite cut above what you’d otherwise expect at the price point:
Amongst all the other goodies it’s loaded with (gigabit Ethernet networking, intrusion protection, selective site blocking), it also features built-in VPN, a potentially very useful feature for easy remote connectivity back to the office. This works in conjunction with Cisco’s QuickVPN software (freely downloadable from their website).
Setup of this was super-easy. One simply adds a VPN client account in the router BUI, and exports the router certificate for client use. That’s it as far as router setup goes – everything else is handled by the router firmware. Getting up and running with VPN really only takes about thirty seconds.
Installing and configuring QuickVPN on a laptop running Windows 7 Enterprise 64bit was equally straightforward. After saving the exported router client certificate into the QuickVPN installation directory (you will not be able to establish a connection otherwise), I was able to securely connect to and browse the remote network.
The WRVS4400N, QuickVPN, and Mac OS X
So far, so great – so what’s the catch? Well, here it is, and it’s completely stupid: QuickVPN is only available on Windows platforms. Seriously Cisco, what the hell? I can understand this attitude circa 2001, but in 2011 this just doesn’t make any sense. I don’t use Mac OS as my primary platform and the products, while beautifully designed, are a control freak’s wet dream…but last time I looked Mac OS was a very, very popular platform especially in the creative industries where I’m sure a lot of small businesses operate. So, for Cisco to release a small business router where a substantial group of customers are cut out of (easily) using one of the router’s key selling features is just daft.
The silver lining to this is that there is a way to connect to the WRVS4400N’s VPN facility, and although it is not as convenient as using QuickVPN, at least it works. For this, I’ll refer you to the following document on Cisco’s support forums, posted by a very helpful community member. It uses the freely available IPSecuritas application, and I can confirm that once an IPSec VPN tunnel has been configured in the router, the procedure documented below does indeed work (as tested on a Mac OS Snow Leopard system):
https://supportforums.cisco.com/docs/DOC-10266
Fortunately, this somewhat salvages what would otherwise be a poor choice for a Mac OS or mixed platform small business, but really Cisco, just release a version of QuickVPN for Mac OS!
Otherwise, on both Windows and Mac OS platforms VPN worked great, but with one slight oddity: attempting to use the router’s admin BUI over VPN would result in the connection hanging, requiring a manual disconnection and relaunch of the VPN client software. Browsing the router’s admin pages was fine, but if a setting required saving, the connection would stall indefinitely.
PPPoA to PPPoE bridging using the Draytek Vigor120
I recently acquired a Cisco WRVS4400N wireless small business security router for evaluation. It’s a full-featured device with a number of attractive features for an attractive price, but it supports an Ethernet WAN connection only. ISPs in New Zealand generally only support PPPoA ADSL connections – so using the WRVS4400N with a SOHO broadband connection would not be possible.
After looking around online, turns out there’s a really great little solution in the form of the Draytek Vigor120 ADSL2+ modem.
It supports PPPoA to PPPoE bridging, which in the words of the product’s own marketing material allows you to “connect a PPPoE client to the Vigor120 (firewall, Ethernet-WAN router, Apple Airport or PC) even if the connection to your ISP is still PPPoA”.
Setup was a doddle, and soon I had the WRVS4400N connecting to my ISP via PPPoE just fine. The price for the Draytek is right too – so all in all, a highly recommended device.
I’ll be posing my impressions of the WRVS4400N over the next few days.


