| At a glance | |
|---|---|
| Product | Asavie Tech AccessMyLan () [Website] |
| Summary | Remote connectivity VPN solution aimed at business users who want to have finer grained control over their users. |
| Pros | • Fine grain control over users • Integration with LAN services like Active Directory • Installs easily given administrator assistance • Decent documentation |
| Cons | • Lack of security documentation; use of 3DES is antiquated • Can’t use split tunneling • Expensive • High latency overhead |
Typical Price: $20
VPN is a buzzword that continues to ring in business owners’ ears. It equates to freedom; the ability to work from anywhere. But for IT administrators, it’s an annoyance and another chore most times. The cloud is aiming to fix this with solutions like AccessMyLan.
AccessMyLan is really a business VPN solution. Users just looking to encrypt their traffic, or for small networks that only need remote access, should look into products like Hamachi or VyprVPN. AccessMyLan requires an IT administrator to maintain the system, but does not require the same level of management as a traditional VPN concentrator. Let’s look at pricing and account options.
Pricing and Features/Accounts
|
||||||||||||||||||||||||||
AccessMyLan is architected in a client/server fashion, even though there’s a third-party cloud in the middle. You install a VPN agent (server) inside the office LAN, and end-users have client installations. This plays into the pricing scheme. For a base installation, with one user, the price is $19.95 a month. Additional users each cost $19 a month, and can either be purchased at the outset or added on later. Additional VPN agents are $24.95 a month, and are used mainly for redundancy.
That’s significantly more expensive than rolling out a Hamachi-based VPN, so what do you get for all that extra cost? In a word: control. Hamachi offers very coarse user controls and little-to-no access rules or controls. AccessMyLan has basically built a full firewall into the cloud that your users connect through, so things like blocking specific protocols, or only allowing access at certain times of the day are all in there.
Users can be authenticated using either RADIUS or Active Directory, by way of the VPN agent software. That’s a powerful feature for larger networks, as it provides a single place for administrators to handle usernames and passwords. I don’t have an Active Directory server to test against. But judging from past experiences, this level of integration takes time to test and deploy. If you decide to go the route of AD integration, make sure you research first.
Installation and Setup
|
||||||||||||||||||
To go from start to a fully-functional VPN with AccessMyLan is a three-step process, and correlates to the three parts: Server, Web, and Client. Currently, there is Server and Client software for Windows only, so Mac OS users will have to look elsewhere.
Installing the Server (VPN Agent) software was straightforward, and is done after initial account creation on the web. AccessMyLan uses a two-step authentication process during installation by providing an auto-generated PIN you enter as well as the administrator username and password. I installed the 64-bit VPN agent onto my Windows 7 desktop machine.
Once installation is complete, you go back to the website and continue configuration. I chose a default open configuration and allowed everything in to speed up testing. General security best practices say you should by default block everything and only allow what’s necessary, and is what I would do in a production environment. I left everything alone otherwise, and did not set up any user authentication requirements.
Client installation was troublesome because I don’t have an easily moved Windows client anymore, so I installed the client into a Windows XP virtual machine running on my Mac through VMware Fusion. The installation did not require a two-step authentication process, unlike the agent software. It did require a PIN however, so you will have to communicate this with your remote users, or simply install the software yourself.
With the client installed and connected, I proceeded to run some tests and see what AccessMyLan can do.
In Use
AccessMyLan provides a fairly nice client interface, and usually connected quite quickly even over my Clear Wireless test connection. However, trying to actually use the VPN was another story.
Part of this could be blamed on Clear. Pinging Google.com from my hardwired 25/25 FiOS connection resulted in an average 24 ms response time. Over my Clear iSpot, I averaged 110 ms response times when pinging the same Google IP (just using the DNS load balanced me to different IP addresses). So Clear obviously contributes most to the 135 ms or so of total path latency without VPN.
My test topography along with the latency of each connection test.
Pinging over AccessMyLan’s VPN to my home router averaged 250 ms of total path latency—almost twice as much. This is borderline unacceptable. But I decided that it would be likely that many users could be using this service on an over-burdened hotel wireless, or on a mobile system like Clear, so I carried on with the test.
I then ran throughput tests using Speakeasy’s Speed Test, and Speedtest.net’s service and I averaged 2.5 Mbps down, and about.5 Mbps up. This is on par with an average DSL connection, but is quite slow for Clear, which I’ve seen hit as high as 7Mbps / 1Mbps.
| Average Bandwidth Use Over Clear | ||
|---|---|---|
| Upload | Download | |
| SpeakEasy Speed Test (New York) – No VPN | 2.5 Mbps | .5 Mbps |
| Speedtest.net Speed Test (New Jersey) – No VPN | 2.2 Mbps | .5 Mbps |
| SMB Transfer through VPN | 0.7 Mbps | NA |
Connecting to AccessMyLan from a machine running the AccessMyLan client took a little longer over the Clear than when I was hardwired. But after about 10 seconds I was connected. I proceeded to access a SMB share on my Windows 7 desktop (running the agent software), and that took about 45 seconds to populate the Explorer window.
Trying to copy my test 100 MB file was an excercise in patience. It took about 45 seconds for the confirmation window to pop up asking if I were sure I wanted to copy the file, and then about another 45 seconds for the transfer to actually start. Looking at my bandwidth meter, I averaged about 700 Kbps, or approximately one-third the speed I was getting over the speed tests. It did spike a couple times to over 1 Mbps, but not for long. I didn’t bother to test the upload as the baseline speed was too low.
The transfer took over an hour to finish and the file checksum matched the original file’s checksum, so it was a successful transfer. Access reports in the web interface showed the file transfer progress, along with connections and the eventual disconnect. This is where I noticed something odd.
The Initial Setup Screen.
This determines what kind of setup by default you will have.
The administrator’s home screen on the web.
The unlock code is necessary to retrieve a lost admin password.
You can determine per user the access rights they have.
Specific protocols can be allowed/denied.
Tons of options for network configuration.
Account configuration is complex depending on your network setup.
Reporting is laid out fairly well by default.
New Mobile devices are only supported on AT&T
Flexible credential options.
Applications can be routed over the VPN to make it easier.
Some phones can apparently be configured via SMS. I don’t know of any in the USA that allow that.
iPhone users are going to have a bunch of trouble with this setup.
Apparently by default, and from what I found unchangeable, the software uses L2TP over IPSec protocol. The problem with L2TP is you can’t enable split tunnelling, meaning all traffic that the client generates winds up on the office LAN. There is a checkbox to disable split tunneling, but it doesn’t seem to do anything. Split tunneling is important for bandwidth-strapped organizations so people can continue to use their Internet connection at home rather than pounding on the office Internet.
I decided to see what the mobile client access was like to set up. As it turns out, I wouldn’t even bother with it. It’s terribly complex for smartphone users, and especially iPhone users. AccessMyLan requires you to change carrier settings on your device so that the default gateway used is AccessMyLan’s rather than the carrier’s default gateway. I am not comfortable changing those kinds of settings, so I didn’t go ahead with the test. The whole process is nicely documented though.
Access, Support, Security, Closing Thoughts
|
||||||||||||||||||||||||||
Remote access is through a desktop client. There is also moble access, but it is difficult to set up. Some applications can be tunneled over the VPN like email or ActiveSync, but requires further setup and was not tested. The website provides plenty of information about what the clients are doing, and provides all the management tools in a well laid-out interface.
Support is decent, with manuals, a knowledge base, a quickstart guide, and email support for questions beyond those resources. There is also a phone number to call, but that is only for sales.
Security is good overall, although the encryption scheme used (3DES) is dated and is not recommended by most security organizations. I’m unsure whether L2TP/IPSec supports AES encryption though, so it might be all you can work with, which in reality is better than nothing.
Overall, AccesMyLan provides a viable, albeit slow hosted VPN solution for folks who may be uncomfortable with buying a configuring a VPN endpoint router. But at $20/month to provide secure remote access for just one mobile client, that alternative might look mighty attractive after only a few months.