Originally Posted by wardmundy
|
After you read it, you'll understand why we prefer Hamachi for most implementations. 
|
Hi, Ward, I just wanted to thank you for the links and to leave a comment about why I did the Open VPN series.
What we wanted to achieve was a situation where you could take a hardware device - in this case a router that has been re-flashed using a particular version of the third-party Tomato firmware - and use that as the client end of a tunnel, so that you could plug in a VoIP adapter, a VoIP phone, or any other hardware device that doesn't natively include VPN capability, and make sure that its communications take place solely via the tunnel. The two main reasons people might have for wanting to do this are security (so that your communications cannot be intercepted between tunnel and server), and to avoid issues with NAT firewalls that so often cause problems with SIP communications (such as one-way audio, or signaling only but no audio).
Another goal was to have the VPN server able to operate on the same machine as Asterisk and FreePBX. In these days when everyone is trying to "go green", it seems ridiculous to have to run another device to act as a server - not to mention the added cost of purchasing an additional device. Granted that if your Asterisk box is already running under a heavy load, you might want to think twice about adding another server, but in that case you can always put the
OpenVPN server on another box on the LAN that's less utilized.
The router we used for the client side, an Asus WL-520GU, is fairly inexpensive (around $40-$50 if you do even a bit of comparison shopping online) and with the addition of the Tomato firmware, it becomes a quite capable unit. The main reason for using that particular Asus model is that it's much more difficult to make a mistake while flashing the router that totally "bricks" it to a state where it is unrecoverable. I won't say it's impossible (say something is "foolproof" and a creative fool will certainly prove you wrong!) but I for one didn't really want to take a chance with certain other models that are much more easily "bricked" if you make a mistake, particularly when that Asus model is so reasonably priced.
Since you mentioned Hamachi, I'll just say this about that. I have no vested interest in
OpenVPN; if you prefer Hamachi that's fine - I understand it's much easier to set up, and frankly that would not surprise me a bit - getting this all working was one of the hardest things I've done in a long time. But personally, I have three quibbles with Hamachi:
First, you're dependent on someone else's servers being "up" and reachable. It's another point of failure, and it's totally out of your control. Of course, we use third-party services like Gmail for our e-mail (at least I do), but I'm a lot more tolerant of not getting e-mail for an hour or two than I would be of not having dial tone for the same length of time.
Second, the fact that it's not open source, and therefore you have no idea how secure it really is. Read
the Wikipedia article on Hamachi, particularly the section on "Security", and you will see the concerns that many have about this service (also note the section "Server Load"; that one kind of reinforces my previous point).
And third, possibly because of the first two considerations, there is no router firmware that I'm aware of that has a built in Hamachi client. Of course, a year or two ago you probably wouldn't have found router firmware with an
OpenVPN client (not one that worked, anyway) and that doesn't mean that a technically astute person couldn't add Hamachi capability to the router. But then, you face the same problem at the server - in our setup, you configure
OpenVPN at the server using Webmin, and I have not heard of a Webmin module for setting up and configuring Hamachi.
All that said, I can certainly understand the appeal of something that promotes itself as "zero configuration" (of course that cannot possibly be true - the amount of configuration may be very minimal compared to other VPN's, but you can't just load the software and expect a tunnel to magically form without doing some setup work). And I certainly would not wish upon anyone what I went through trying to get
OpenVPN working, which is one reason I wrote the series of articles. And it would not even surprise me if some people do exactly what I did and it still won't work for them, and I won't be able to tell them why (but I will say they'll probably be a lot closer to having it working than I was during the time I was losing countless hours of sleep, trying to figure why the stupid thing wouldn't work - it was
incredibly frustrating for a time
).
Anyway, I'm certainly not trying to "sell"
OpenVPN as the ultimate solution. There is a real need for an open source, "minimal configuration" VPN that (preferably) either doesn't rely on outside servers at all, or else can use multiple servers (think DNS, NTP, or STUN servers - doesn't matter which one you go to, just about any will work for the purpose). But as far as I know, that does not yet exist.
jeffmac: Don't feel bad, I couldn't get tap mode (a.k.a. bridged mode) to work at all. The only real downside of that, as far as I can tell, is that you can't get Samba or Windows file sharing to advertise shares across the tunnel (you can still access them if you know the local IP address of the host machine, you just can't see them). On the other hand, everything I read indicated that TUN mode (a.k.a. routed mode) is more secure and has less "overhead", and for our application it wasn't really necessary for Windows file sharing to work across the tunnel (might have been nice, but certainly not necessary). Maybe someone smarter than I can get it working, but TUN mode seems to be working reliably so at this point I don't even want to breathe on it!
Linear Mode
