John:

        Heya. I know you didn't ask me, but as I'm the guy behind
the Kaboodle and KaboodleProxy stuff, I thought I'd toss in my two
coppers as well.
        When we started building the echoWare and echoServer stuff
for Kaboodle, we initially looked at "hole punching" solutions such
as what I believe Hamachi is doing (Alex, please correct me if I'm
wrong). A really good discussion about "hole punching" is here:

http://www.brynosaurus.com/pub/net/p2pnat/

As that paper discusses in detail, hole-punching thru a
NAT'ing router works...but not always. Their studies show it's
effective for 82% of the NAT'ing routers tested (using UDP; for
TCP it drops to 64%). The paper is a bit slanted, of course, because
it's clear they *want* hole-punching to work. To me (and I think
to many of my company's customers), "hole-punching" looks a lot like "session hijacking" -- something a good, stateful firewall is
specifically capable of preventing.


        That is, as far as I can tell, in the Hamachi system, the
two clients send packets to the server, which will (presuming your
firewall allows arbitrary traffic to flow to the server, rather
than blocking all traffic which is not TCP to common service ports)
open a "return path" in any NAT'ing router. The server then tells
the two clients to, essentially, "hijack" that return path. A good,
stateful firewall will see the arriving packets on that return
path are *not* coming from where the return path originally sent
them, and they will be blocked. A low-end NAT'ing router might
not care about the discrepancy, and lets the packets in. If the
timing all works out...the "peer-to-peer" connection becomes
established, with strong encryption, and the server is out of the
loop. Once that connection is established you can, very conveniently,
run a tunneled VNC connection over it.

        On the other hand...there is the echoServer approach. It
is a traditional "TCP Relay Server" which connects echoWare clients
together. Un-traditionally, we let the users run their own relay
servers; that's the lowest-cost solution (ie, my company doesn't
need to charge GoToMyWallet kind of prices to keep a server farm
well maintained). It also appears to be the most appealing solution
to professional remote support providers: they can run their own
servers, and their customers need only relay their data thru them
(whom they trust already). Minimum firewall hassle, minimum setup
cost, maximum open-source -- which I do believe maximizes the
overall security -- everyone's happy.

        Currently, Kaboodle is the only echoWare-enabled application,
but we're working to address that. Unfortunately, Kaboodle is in an
unstable pre-1.0 release state, halfway thru a major GUI rework. Once
it's stable and securely tunneling VNC connections again, with a
minimum of firewall adjustments, I'll mention it here again.

        Hope that helps! Alex, please do let me know if I mis-spoke
at all about Hamachi's approach.

-Scott

How is your app better than Kaboodle and their "KaboodleProxy"? They make
the client source available and they even sell the proxy so you can run it
on your own machine(s), which in my book, makes it a bit more trustworthy
than having to trust someone else's machine. Granted the proxy is sold in
binary-only form, but at least you can run it on your own machine and sniff
what's going on.
        John
_______________________________________________
VNC-List mailing list
VNC-List@realvnc.com
To remove yourself from the list visit:
http://www.realvnc.com/mailman/listinfo/vnc-list

Reply via email to