Re: question - hamachi VPN for AXIP
- --- In BPQ32@yahoogroups.com, Bill Vodall WA7NWP <wa7nwp@...> wrote:
>I think doing such stuff is an interesting idea, but you're still dependent upon the same public internet to provide the VPN transport and endpoints. You're ultimately trusting the VPN transport (and provider) to be secure. If you're not careful, you wind up just adding complexity, chokepoints, and more points of failure (kind of reminds me of 44net). Encrypting traffic flows over a VPN always involves some tradeoffs in performance, would these impact AXIP traffic....good question, how tolerant is it of latency?
> I'm making progress on my BQP32 node and, as usual, that leads to new
> questions and ideas.
> Hamachi - It would be nice to have somewhat secure access to my home
> BPQ32 node from a portable BPQ32 instance, without RF, on the laptop.
> I could do it with smoke, mirrors and SSH but that's far from truly
> portable. The public VPN Hamachi comes to mind as a system that's
> easy to use and provides a clean user interface. Has anybody here
> tried AXIP over Hamachi? It might even make for a larger global AXIP
> VPN we could use for node interconnections without the worries of
> playing in the big wild open Internet.
> Bill - WA7NWP
When you use one particular company's VPN implementation, then you will likely become slave to their particular requirements. Also, probably more important in times like these, you're counting on them being in business tomorrow.
Are we worried about the security risks in exposing odd telnet ports and AXIP ports to the wild wild west (WWW)? If so, has the code involved be checked closely for buffer overflow problems/vuln's? Obviously the holder of the source code would have to get involved in this. It's a concern that's creaped into my mind often and I'm just getting started with this stuff. I know buffer overflows have been found in some of the other 'nix based ham apps in the past, so you can't really discount the risk. I don't think we're a big target, but you can't dismiss the risk totally.
As far as remote control of BPQ32, I think the BPQ Telnet Server is pretty nice, BUT. I would assume that the login, password, and subsequent traffic flows from you to it over the internet are not encrypted and thus subject to "sniffing" attacks. How big of a risk? Well that's arguable and would vary by the networks your traffic is flowing over. On your local LAN the risk is probably pretty low. But when you start coming in remote over the internet...the concern has to be there.
I've often contemplated the need for the 44net in today's world. I think for most things we are much better off building out our own direct connectivity via AXIP, cable/fios/DSL connections, cheap DDNS providers, and so forth.
I think the only real perk you get with 44net is RDNS (Rev DNS PTR lookups of host names), but that can likely be addressed by hosts files for folks that have static public IP's. Granted not everyone has or can get a static IP from their ISP's, but I'm just thinking/rambling here. Dynamic IPs and host files would be a mess to manage. I guess the question here becomes just how often would our systems need to resolve an public IP to a hostname (RDNS, PTR stuff)?
In the end 44net appears to be just a simple VPN-line setup with a single low bandwidth connection to the internet and some DNS/RDNS services, all creating one single point of failure, and administration issues. Am I wrong here, don't claim to be an expert on it?
If you're running XP Pro you can always do Remote Desktop, hopefully over a VPN or at least on an odd port number (not 3389, hint). There's other packages, but most are slower than RDP.
In the 'NIX world there are many remote options. All comes down to free or cost, expose them to the internet, or protect them somewhat by VPN access only.
I've always thought it would be nice to be able to take BPQ Terminal and connect over the LAN to another host running BPQ32. That combined with a VPN would be nice, but I think most of this is tackled by BPQ Telnet Server (minus the risks of unencrypted telnet traffic). Again, may be missing something that's already there.
Forgive me, just thinking out loud here ;-)