ChunkVNC Repeaterless NAT2NAT Test

[supercoe]

Alright, what we have here is a special test build of ChunkVNC 3.3 that I made up today that uses the new NAT2NAT technology Rudi has been working on.

If you're wondering what NAT2NAT is you can read up on it here: viewtopic.php?t=27745&start=30

Basically what happens is the NAT Helper program running at uvnc.com receives the ID numbers from ChunkViewer and InstantSupport via chunknatviewer.exe and chunknatserver.exe and connects them together.
Unlike the Repeater however it does not pass any of the VNC data through the NAT Helper, once the initial connection is established the UltraVNC Viewer and Server are communicating directly with each other!

This is an alpha-beta-crude test of the theory in order to gather data on whether or not this functionality will be useful for future ChunkVNC releases so expect problems.

Known issues:

* Doesn't check if the NAT2NAT Viewer/Server actually connects.

* The UltraVNC Viewer window must be closed before InstantSupport exits or chunknatviewer.exe will go into a loop state causing very high CPU usage on the ChunkViewer machine.

* HTTP Proxies cause a failure to connect.

* Installing as a service is disabled for the test.


Download:
Test over, everything worked as planned. Currently we are awaiting Rudi to polish up the code so this can be implemented. PM me if you still want a link.


Installing:
1) Unzip
2) Run InstantSupport.exe on a customer computer, you should see a green dot next to "Signed In".
3) Run Viewer\ChunkViewer.exe, type in the ID number and connect.

If all goes well you should get 3 green dots and then the UltraVNC Viewer will open with a direct connection to InstantSupport!

I'd appreciate feedback on success and failure stories with different network configurations. Thanks and happy testing!

[supercoe]

Just to be clear:

This release is ready to run, inside the zip is a pre compiled InstantSupport and ChunkViewer.

What I'm looking for is information on network configurations that will cause a connection failure

Thanks everyone.

[supercoe]

JonD and I had some emails going back and forth about his testing.

If anyone else has anything to add that would be great as I'd love to add this feature to a ChunkVNC release but won't unless we can get some good data that it works!



> JonD
>
> Tried on my desktop to my notebook as client  (on the same internal
> network) over our slow wireless connection.
>
> I was surprised that it did connect.  I'm not sure where the data
> is travelling for that type of connection (both machines inside
> the same network).
>

I'm guessing you have a router that supports loopback connections.


> Initial testing showed everything working.
>
> I then closed the viewer (without closing InstantSupport on
> the client machine). I entered the ID# again and (as expected)
> on the viewer computer I did not see green lights since
> the direct connection was already in effect... tried
> again and just entered an arbitrary ID# and still connected
> to the client machine... so the viewer opening dialog
> needs to be a little different to allow for the scenario
> of closing the viewer to the client and restarting without
> a new client session being established.
>

Hence the alpha-beta-test tag. There isn't much checking going on as I didn't have time to make it a release worthy program.
The reason you were able to continue to make a connection is because the viewer no longer has anything to do with the ID number, it simply connects to port 9001. The NAT2NAT helper programs use the ID number to find each other and since they were already connected the viewer was run again connecting to localhost:9001 which put it in the already established tunnel.

Thanks for trying this stuff though, you're really putting it through the paces but for now I'm more curious if it starts and connects. The good stuff will come after we know it works.


>
> I found a couple of times, timing seemed to be an issue.
> My AVG asked for permission each time (I wasn't committing
> to always allowing internet connection form the viewer)
> If I promptly approved the connection it wasn't an issue.
> If I didn't get the viewer connected promptly, I got a
>  "failed to connect to server"
> message.
>
> If I then approved the AVG internet the direct connect
> and ready light came on but no viewer.
>
> If I really delayed the AVG approval no
> direct connect or ready came on.
>
> Restarting the viewer and entering the ID# again solved the
> issue (no restart on InstantSupport was needed).

Because I'm currently not doing any checking there is a 6 second timer between launching nat2nat and starting the viewer. I should have made that a bit longer! In the future though ChunkViewer will check that the NAT2NAT connection is good before launching the viewer.


>
> I'll try more tests later today with someone outside
> as the client.
>

This is what I really want to know!
Thanks again for the testing!

[twagner]

hi supercoe,

i`m very interested to use the repeaterless nat2nat, because
i admin more than 280 pc`s with a 1 MBit broadband internet WLAN connection.

I proud to say that i use chunkvnc with the repeater solution more than 1 1/2 year very successfull,
but now i`m on a point i must say that the remoteadministration is very slow.
To much traffic for more than 4 or 5 remotesessions at the same time.

Can i test your NAT2NAT solution?
I can`t change my ports (forwardings) and port 9001 is blocked.
Is there a chance to change the ports by the NAT2NAT solution?

twagner

[supercoe]

twanger,

I think you may be confused, no port forwarding is required for this test. Give it a try and report back.

[twagner]

hallo supercoe,

sorry my mistake, i can`t use port 9001 by my own.
So i havn`t any chance to test your NAT2NAT solution.
But i think NAT2NAT is the best way to solve my problem.

[B]

twagner, I think he's saying you DON'T NEED PORT 9001 with this test build. Everything you do is OUTBOUND, and should not be blocked. The NAT2NAT does some tricks to keep things talking in both directions.

supercoe, so this is dependent on the "NAT Helper program running at uvnc.com" being active? I thought the new NAT2NAT could be self-hosted? Wouldn't the logical thing be for Chunk to bundle a NAT2NAT-enabled repeater?

[supercoe]

Twanger,
B is correct, unless your firewall is so restrictive that it blocks outgoing ports you should be fine.


B,
Unless I totally missed something I don't believe Rudi has released the NAT2NAT helper in the middle. The only download I saw in the NAT2NAT thread was for the server and viewer portion not the middle man.

[B]

Ah, Rudi's Secret Sauce. I guess you're right. Too bad, but I understand it's still a proof of concept more than anything else.

[supercoe]

Yea, still trying to get proof for that concept!
I really hope it ends up working out for most people as it's doing well in my own testing.

I'd really like to use this as the default option and then dropping back to the old school repeater in situations where NAT2NAT isn't going to work.

The bandwidth savings would be so great that a logmein alternative could be achieved for minimal to no cost!

I just want some idea that others can expect at least a moderately high success rate with this test.

[B]

Okay okay you've guilted me into it.

I've just run it successfully within my LAN. Obviously that means NOTHING regarding two NATs, but it's interesting that it still worked (3 green lights and all). It seems on par with LogMeIn's Java viewer to the same machine (at the same time), perhaps even faster.

The real test will come later when I can try it from a completely separate location.

Hmm, I wonder how I could confirm the path the packets are taking between the client and server -- it would be wild to confirm that they were communicating over each other's local LAN addresses even though both had been hooked up through the remote uvnc.com server. Would that be the expected behavior?

[supercoe]

You can expect that behavior simply because it has no other way to function!
The biggest issue right now is that it's a 6 second timer between running NAT2NAT and launching the Viewer, this caused JonD problems because he has a software firewall.
In the future we obviously will wait for the connection to go 3 green before launching but I was being lazy and wanted this test to be out.

[B]

I got a little crazy and decided to shut down our main router interface while I was still in session. In other words, the Internet connection disappeared from our LAN.

And the active ChunkVNC session continued to work! It was quite cool. But a minute or two in, I got a curious red box reading "UltraVNC running as application doesn't have permission to access UAC protected windows. is screen locked until the remote user unlock this window." (Words were cut off on either side.)

I visited the actual workstation, and for some reason it had become "locked" and gone to the Ctrl-Alt-Del lock screen. I logged back in to the station (physically) and the ongoing ChunkVNC session resumed without issue (but needed a screen refresh).

I don't know why the screen locked; it MIGHT have happened because LogMeIn lost connection because the Internet was down, or maybe it was even UltraVNC.

Anyway, cool stuff so far!

[supercoe]

B, as always thanks for the input. Good to see you're having luck even in "extreme" conditions.

[B]

Oh, and just for the record I had to unblock one or two of your components for the Windows Firewall, as well as the "this executable was downloaded from the Internet" warning thing.

What's great to me is that I've just proven to myself that absolutely no repeater was involved in maintaining the connection. (You already knew it because you wrote the code to launch UVNC with the info NAT2NAT told you.)

I still have to think through how my two local stations managed to hook up; a recipe or diagram would probably be helpful. Or at least re-reading Rudi's announcement thread...

[supercoe]

1) InstantSupport gets run and sets up a connection to the NAT2NAT helper running at uvnc.com using the ID number.
2) InstantSupport starts the UltraVNC server with loopback enabled. (it gets the connection request from NAT2NAT running @ localhost which is why loopback is necessary)
3) ChunkViewer gets run and setups up a connection to the NAT2NAT helper running at uvnc.com using the ID number.
4) ChunkViewer waits 6 seconds (this will be changed in the future) so NAT2NAT has ample time to connect and then launches the UltraVNC viewer connecting to localhost:9001
5) As long as NAT2NAT successfully (3 green) negotiated the UltraVNC viewer connection will be sent directly to the network running InstantSupport!

Initial connection:
NAT2NAT Viewer -> uvnc.com -> NAT2NAT Server

NAT2NAT connection established no longer requires uvnc.com:
UltraVNC Viewer -> NAT2NAT Viewer -> NAT2NAT Server -> UltraVNC Server

NOTE: Although I connect NAT2NAT with an ID number it does support alphanumeric "keys"!

I hope this info makes sense, the beer donations are working right now.

[B]

Ahh. So the viewer is connecting to LOCALHOST, much like one would with ssh tunneling -- got it! The special sauce is taking place entirely between magical NAT2NAT modules. (I had thought the NAT2NAT was handing off the derived IP address directly to your viewer.) Thanks very much for the insight. Now the remaining mystery is what's inside the NAT2NAT black boxes.

But I've buried the lede here -- my test from home worked! I think this is a really great proving ground -- I connected successfully from a viewer behind a consumer grade Netgear router to a server behind an enterprise grade Cisco ASA firewall! Definitely NAT 2 NAT.

(I was also able to do it the other way around. Chunk really makes assuming client and server roles dead simple.)

I find this very impressive. The speed was pretty great -- I even tried a couple of Youtube videos and they approached something one could conceivably call "smooth". And this was with default settings and autoscaling turned on. I repeated the videos with the LogMeIn Java client and they played far worse.

Other observations:

I tried running as a limited user on the home XP station first -- this did NOT work at all, in either client or server role. No lights. Pretty sure the NAT2NAT module requires admin rights. (Even doing a RunAs on InstantSupport or ChunkViewer did NOT work.)

Having trusty old ZoneAlarm 2.6 here allowed me to get prompts for each step of the 3 Lights process, which was kind of fun.

Upon closing the viewer window, the NAT2NAT window was usually left up and running; I don't know if that's normal.

For an alpha test this went almost disturbingly well for me. You and Rudi have certainly proved your point!

I now can't wait to see this go into the mainline UltraVNC and ChunkVNC, especially including a self-hosting option for an open source NAT2NAT server. (Hmm, I wonder how light a load NAT2NAT places on the server; one could probably handle hundreds or thousands of connections.) The repeater fallback you suggested would be even better.

You guys have finally got me excited about VNC again.

P.S. Are there UltraVNC and/or Repeater related dependencies here? Would NAT2NAT work with other VNC brands, or other programs entirely? What about direct file transfers? I would think that point to point video could provide better quality than Skype....

[supercoe]

Good news, thanks for the followup B!

From a technical standpoint when NAT2NAT is connected you should be able to tunnel any type of traffic through it. I don't believe there are any checks in place that limit it to VNC. It's truly a work a genius by Rudi!

If you get adventurous go download NAT2NAT, make the connection, send data into localhost:9001 on the viewer side and it should come out localhost:5900 on the server side. I haven't tested this in any way but unless Rudi is communicating with the UltraVNC server via some other method it should be a good to go tunnel!

I too want him to release the helper "middle man" app into the wild so we can host it ourselves, if it works as good as it seems to chunkvnc.com will turn into a public hub!

[B]

Well, my traditionally short-lived euphoria lasted a little longer than usual... but now I can't seem to get more than one light on either end. Did I break it for you too?

Hmm, now it's working again. Working, even though I'm only getting one light on the server end.

[supercoe]

I just did a quick test and it works on my end.
Sometimes the NAT2NAT programs can hang unless you close the Viewer before InstantSupport.
Kill any processes named chunknatviewer.exe or chunknatserver.exe and try again.

Or just logoff/logon to clear any running processes.

[B]

Yeah, it eventually cleared up. Not sure where the hangup was.

Now get this... I took your advice and started noodling.

And I've just finished a successful test of TightVNC viewer to TightVNC server across an UltraVNC NAT2NAT 2011 tunnel!

I've long wished that repeater functionality existed in other VNCs, but with this we don't NEED repeater functionality!

The only problem I noticed was that the NAT2NAT tunnel did not seem to persist after a session ended. (I had to restart everything for the next session.)

This is too freaking cool. If he incorporates decent encryption (e.g., ssh) then he'll have created created a secure, self-contained, application-independent, repeaterless, dual-NAT-penetrating tunnel for any application at all! Then we just need ports for other OSes.

Rudi was acting as if this were all very matter-of-fact and based on existing available concepts and technologies, but it sure seems like a breakthrough to me.

NAT-puncturing point-to-point FTP / file transfers. Voice. Video. It's just endless. (Of course the malicious uses are equally imposing.)

[supercoe]

Glad you see why I've been so excited about this functionality!
Good things are coming my friend.

[B]

Oh my gosh -- what if we just run a standard SSH tunnel THROUGH the NAT2NAT tunnel? Oh my gosh...

[supercoe]

Defiantly, you could encrypt all the traffic you pump through it then. Currently this test still uses SecureVNC for encrypting the VNC traffic though.

I haven't seen you this excited in awhile, don't forget to sleep!

[B]

Right, and the ssh tunnel might, or might not be faster than a SecureVNC setup, encryption strength aside. But that's not the main point -- the main point is that everyone knows you can run ANYTHING securely through an ssh tunnel. Assuming performance is OK, in one fell swoop you've created the "secure, self-contained, application-independent, repeaterless, dual-NAT-penetrating tunnel for any application at all" that I was just foaming at the mouth about.

[JonD]

My first test with an outside client did not succeed.

- The client started his end up. Each time, for some reason, it activated Dream Weaver (each time he started). Not sure which part of the "package" triggered that.
- He then saw the signed in indicator and gave me the ID#
- I started up and entered the # and tried connect (I saw the "signed in" indicator")
- I did hear a beep from his end but then I failed to connect
- We tried with all firewall disabled and still no success.

A total of 6 attempts.

I don't know if this system is even more sensitive to my remote wireless setup. I have been reliably working on a remote system today and did make sure to close down all ChunkVNC related processes before the test.

JonD

[supercoe]

The client started his end up. Each time, for some reason, it activated Dream Weaver (each time he started). Not sure which part of the "package" triggered that.

You got me there man, I just did a skim through the code again and I don't see anything that would cause that to happen.
Sounds like he has other issues....

At least you heard the beep and saw the 3 green, that's good enough for me to know that NAT2NAT worked.

[B]

Can't find a definitive list, but it seems Dreamweaver can take over everything from .js and .php to .html and .xml ... but I don't see why you'd be indirectly invoking ANY of your ChunkVNC files.

Did Jon say he or his customer SAW the 3 lights, or is that just associated with the beep?

Also, is it correct that 3 lights should appear only on ONE side? (That's what's happened in my testing.)

[supercoe]

Ok that makes sense now, the script I use to unblock the executable files is a javascript unblock.js file!
Thanks B for the catch. I'll have to change the code from ShellExecute to Run.

It only beeps on 3 lights.

[Sainsuper]

i would to try this version but the link doesn't work. thanks for sharing this grat project.