Category Archives: Networking

Cisco SRP547W router – first impressions and VPN support

I’ve recently acquired a Cisco SRP547W router to evaluate as a replacement for the Cisco WRVS4400N. The SRP547W sports a similar feature set to the WRVS4400N, with the added bonus of a built-in ADSL2+ WAN interface. Because the WRVS4400N only features an Ethernet WAN port, I had to use the Draytek Vigor 120 as a PPPoA to PPPoE bridge (in New Zealand broadband is delivered over PPPoA). This worked great, but at the end of the day if I can reduce the number of links in the chain it can only be a good thing.

Connecting the SRP547W to Orcon’s ADSL2+ network was straightforward and painless. The device features a very nice first-run wizard, a cut above what you’d find in a vanilla router (as you’d expect given the price difference).

Cisco SRP547W setup wizard.

All of the security goodies of the WRVS4400N are present, with one difference being much-improved VPN support. The SRP547W features a built-in “Cisco VPN Server”. Although Cisco market this as being intended for use with their non-free Cisco VPN Client product (which is end of life incidentally), it’s actually just a standard IPSec VPN and works with a variety of other clients. I had no problem creating a VPN tunnel on Windows 7 using Shrew Soft’s excellent (and free) VPN client. The stock Android VPN client also worked right out of the box, as did Ubuntu Linux using vpnc (I’ve yet to try Mac OS X). A maximum of ten VPN users are supported, and the experience is generally much better than using Cisco’s poorly supported QuickVPN product as marketed with the WRVS4400N.

Price-wise the SRP547W isn’t too bad, not being too much more than the original cost of the WRVS4400N + Draytek Vigor combo – plus you also get analog phone support, a full SIP stack and more. I’ll be sharing some feedback on these other features in the near future.

Advertisements

Configuring URL blocking policy on the Cisco WRVS4400N

This is a weird one and doesn’t really make a lot of sense – but posted here all the same if it helps someone. Part of the Cisco WRVS4400N‘s feature set is a configurable internet access policy, allowing the administrator to schedule internet access hours and permitted sites for discrete LAN clients. The latter is managed by updating a domain blacklist in the admin BUI.

The manual makes out that this is as simple as creating a new policy, adding clients, specifying whether it’s for blocking or allowing access, and adding URLs to the blacklist – but in practice it doesn’t work like this at all. In my case, configuring an “Allow” policy for a single client and adding entries to the blacklist resulted in all internet access being shut off entirely for all machines including the client in question. Looking at the Cisco Small Business support forums, there seems to be equal confusion on this from both customers and Cisco support personnel alike. One Cisco technician mentioned for example in a forum thread on the issue that any clients not defined in an “Allow” rule would be denied by default – but this nugget of information doesn’t seem to have been included in the reference manual.

Anyway, to get a simple website blocking policy in place for one LAN client, here’s what I had to do.

1) Configure an “Allow” policy for the client

In this policy we are allowing the client 24/7 internet access, but not permitting her to access the domain apple.com:

Configuring a internet access policy rule.

You’d think this would do the trick, but no. If your experience is the same as mine, this will shut off internet access entirely – so we move onto step 2.

2) Configure a second “Allow” policy for every other device

In this policy we are specifying an IP address range – which also covers the address of the machine above. Like the above policy, it’s for 24/7 internet access:

Configuring another internet access policy rule.

On saving this rule (you don’t need to reboot the router), you should have full access to all websites except for apple.com for the client defined in the first rule. All other LAN clients should have normal full access.

 

The WRVS4400N is now end-of-life. In my time with it it’s generally been a useful device, but marred by a number of issues which created the impression of a somewhat half-baked or half-heartedly-supported product (possibly due to its Linksys lineage which Cisco are selling off to Belkin). Counter-intuitive interfaces like the one described above, wireless performance which was pretty slow all around (really not living up to the advertised 802.11n), Cisco QuickVPN software which was great if you were only on Windows (with Cisco not interested in versions say for Mac OS), IPS signature files which failed to block Skype (counter to the advertised feature set), and so on. I have a Cisco SRP547W being made available soon hopefully to replace this unit which I will post some impressions on.

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.

  1. Set up Firefox sync on the relevant client browser.
  2. 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).
  3. 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:

WRVS4400N Admin BUI

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.

QuickVPN running on Windows 7

 

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.

Draytek Vigor120

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.