nat2nat (reload)

[Rudi De Vos]

Why:
-The connection based on libjingle and google talk is to slow to be usefull.
-There are still a lot of people visiting the old nat2nat web pages

nat2nat is an external tool.
*On the viewer pc it listen on port 5900 ( loopback)
TCP is then converted to udp and send to the server.
On the server, udp is back converted to tcp and make a connection to 5900.

*The udp connection is made server<-->viewer and use a 3the server
to initiate the connection. ( After connection, no more data pass the 3the server)

*We don't use pure udp, but the udt library "reliable udp connection".
This allow to proper send tcp over udp and already have the needed functions to bypass a nat router.

Status:
- tcp<->udp done
- tcp<->udp control channel added
(tcp connection by viewer, initiate a tcp connect on server site)
(broken tcp on one site, is send over udp to force a break on the other)

Still to do:
Add nat punch and 3the server database part to initiate the connection.
Server part as service

[supercoe]

How does the 3rd (external) server know which Viewer and Server connection to put together?
Does it work similar to the Repeater accepting ID numbers?

The ability to have a Repeater managing connections and VNC traffic directly between the Server and Viewer would be awesome!

The old nat2nat project was very interesting but I never was able to get it to work. (I think the project test was over)

Let me know if there is anything I can do to help you test this.

[B]

Yeah, I was guessing that the hand-offs necessary to keep holes punched through NAT on both sides, automatically, for all the hundred of different routers and ISPs out there, proved too difficult.

I wonder how this can work. The only similar method that works, I suppose, is VoIP NAT traversal via SIP proxies and/or the STUN protocols.

http://www.voip-info.org/wiki/view/NAT+and+VOIP

http://en.wikipedia.org/wiki/STUN

[Rudi De Vos]

It works like this.

server connect to 3the server (connect name /passwd/i'm a server)
viewer connect to 3the server (connect name/passwd/i'm a viewer)

If 3the server get a connection from server or viewer and the counterpart
exist already, he send ip and port to the counterpart.

viewer connect 5900 to 3the --> nat router map 5900 to 90000:
3the party server notice ip_nat_routerA and port 90000

server connect 5900 to 3the --> nat router map 5900 to 80000:
3the party server notice ip_nat_routerB and port 80000

ON connection.
3the server send
ip_nat_routerB and port 80000 to viewer
ip_nat_routerA and port 90000 to server

Using the same socket that was used to connect to 3the server, viewer and server now connect to each other.
same socket -> nat router port stay the same.

1) viewer send packet to server
nat router block packet, unknow source
2) server send packet to viewer
packet is accepted by the router , dest was added in 1)
3) viewer send packet to server
packet is accepted by router, dest was added in 2)

Now, you just need to sync the sockets and you have a full direct connection.

[supercoe]

I would really like to see this happen!

Is there any potential problems with this method?
Do most routers allow being "tricked" like this?
How often does the connection fail to sync?

So many questions, just want a test build!!!

[Rudi De Vos]

99% of the routers support this.
Sync it's buildin in udt...

I also want to test it
Partial finsihed and can only test when server/viewer and 3The server parts are done...

[B]

Okay, thanks for the explanation, but I'm still very skeptical that this will work reliably with most routers... I was under the impression they go out of their way to avoid being spoofed like this. TCP sequence numbers are purposely randomized, the NAT table remembers which side initiated each connection, and the conversation you described above would, I think, fail.

http://linux.about.com/cs/linux101/g/tc ... cenumb.htm

But I certainly hope that I'm wrong and you're right!

[Rudi De Vos]

Correct, this would not work when we use tcp.
That's why udt is used ( reliable udp)

[B]

Oh! I thought that "udt" was a typo!

It seems like that's an application level transport protocol; what you're doing seems more like what Wikipedia calls "UDP hole punching" as a form of NAT traversal, similar to STUN?:

http://udt.sourceforge.net/

http://en.wikipedia.org/wiki/UDP_hole_punching

Anyway, this is educational -- thanks, Rudi. This sounds very cool.

Up until now most VNC connections have been TCP based, correct?

[JPCoffey]

Guys, it looks like the people at Zolved have this all figured out. Moreover, they are doing it all on UVNC. Check it out,

http://www.zolved.com/remote_control/about

Nat to nat would be a great solution, but I cannot find a solution that I can spam as my own. I am hoping we can come up with the solution on this forum.

Cheers,


John

[B]

What are you talking about? There are tons of free packages already using the UltraVNC repeater, and have been for years, notably SCPrompt and ChunkVNC, both hosted in these forums.

NAT2NAT is an entirely different kettle of fish.

I'm going to assume for the sake of charity you're not merely a spammer?

Edit: Hey guys, moderators can't edit posts in Sticky threads?

[Rudi De Vos]

What i'm actual building is are 3 little app

1) listen op port 5900 TCP, and convert it to udp
viewer connect to localhost
2) list for udp and connect to tcp localhost:5900
server is a standard listening server
3) 3the server app that handle as database

3the server will be considered as insecure, even when someone can record all data it need to be secure as a normal connection.
VNC still need to use encryption and password to keep the security
on the winvnc site...

[JPCoffey]

B, sorry. I must not have made myself clear. The beauty of NAT 2 NAT is that they allow both the Viewer and Server to operate with little to no configuration on their systems. The connection is brokered at the repeater/server and no port forwarding is required.

I mentioned Zolved as an example of an application that had accomplished this feat, was based on UltraVNC and was publicly available. Given the curiosity as to how this was done and the enthusiasm for making this work expressed by you and SuperCoe, I felt the post had merit.

To my knowledge, both SCPrompt and ChunkVNC require port forwarding. If I am wrong, please let me know.

Zolved does not seem to require port forwarding. Given the many questions asked of Rudi by both you and SuperCoe, I would like to offer another package that does not seem to require port forwarding, EchoVNC.


BTW, I have no affiliation with Zolved or EchoVNC. I am simply supplying these packages as proof of concept solutions for circumventing the configuration required on the host PC of either the server or viewer.


I want to point out that EchoVNC is open source and based on UltraVNC. I am hoping it can shed some light on how NAT to NAT is done. I do not know enough about programming VNC to help technically, so all I can do is bring back sources of software that the programmers may be able to use it.

http://echovnc.sourceforge.net/fom-serve/cache/1.html

Personally, I am looking for a solution where I can roll-out viewers and servers to clients and the people that support them. I want as little configuration on their systems as I can. Having them connect immediately to my own server to broker connections to each other gives me control be the gatekeeper as well. I hope the information I have shared can facilitate a solution.

Sincerely,

John

[redge]

3the server app that handle as database
third part inside repeater ?

[Rudi De Vos]

Zolved and echovnc use a packet-relay server, like our repeater.
viewer <-> packet-relay-server <-> server

while the goal is to make it work without a relay-server, and only use the 3the server to make the inital connection. After inital connection packets
are send direct from server to viewer without using any relay.

viewer<-> connection-server<->server
viewer<->server

I hope that the tcp to udp conversion is faster then relaying tcp over an extra server.

[JPCoffey]

Zolved and echovnc use a packet-relay server, like our repeater.
viewer <-> packet-relay-server <-> server

while the goal is to make it work without a relay-server, and only use the 3the server to make the inital connection. After inital connection packets
are send direct from server to viewer without using any relay.

viewer<-> connection-server<->server
viewer<->server

I hope that the tcp to udp conversion is faster then relaying tcp over an extra server.

I get it. My bad! I didn't realize that we were not confined to our own LANs when using the repeater. I have been looking for an internet to internet connection for viewer and server. If the repeater allows for this arrangement then I am home free. Sorry for the confusion! Thanks everybody! Great forum!

Sincerely,

John

[B]

Yes, JPCofffey, the ordinary old Repeater setup (a la Chunk et al.) does <b>not</b> require port forwarding <b>anywhere except where the repeater is hosted</b>.

The same applies, I think, to the NAT2NAT server/redirector, with the exception that it gets out of the way after the viewer and VNC server begin talking, whereas the standard Repeater is always involved in relaying each packet.

I don't know whether or not Zolved does anything like that?

Also, the last time I checked out EchoVNC, I believe you couldn't <b>really</b> use it as intended without their closed source commercial proprietary paid component -- has that changed?

[JPCoffey]

Also, the last time I checked out EchoVNC, I believe you couldn't <b>really</b> use it as intended without their closed source commercial proprietary paid component -- has that changed?

B, that has not changed. $50 is the minimum ante for EchoVNC and that is only for personal use.

UltraVNC, of course, has no such restrictions. I just need to read up on how to get the repeater to point to different viewers based on requests from different Single Click servers.

Sincerely,

John

[B]

JP, it's really very simple -- the server registers with the repeater with id # 12345, and a viewer connects to that same repeater with the SAME id #. The repeater then relays traffic between those two points. BOTH the viewer and server are making <b>outbound</b> connections, so typically no firewall or router or NAT issues are involved. You just have to decide where to place the repeater and how to forward/open <b>its</b> two ports.

ChunkVNC includes the repeater and makes this all relatively easy.

[JPCoffey]

ChunkVNC includes the repeater and makes this all relatively easy.

B, easy indeed. Piece of cake.

The only part I tripped up on is adding the repeater to my firewall. After adding the repeater to the firewall, I couldn't find it in the list of programs. I looked for ChunkVNC, repeater, VNC, etc. I added it again and the firewall said it was already there but it didn't say what it was called. I decided to open the ports as an alternative and that didn't work either. After not getting the ports to open, I went back and found 'distributer.exe' checked it and everything started humming along. Maybe the hardcore veterans know to look for 'distributer', but I didn't.

I have been using SingleClick for six months or so, but had never used the repeater. All the schematics pointed to LAN topologies, so I didn't think it was an internet solution until you guys cleared the air.

SuperCoe, enjoy your case of beer. I'm hoping $20 will buy some Natural Light and you will even have some money left over for a bag of Doritos. BTW, you need to change your thankyou.html redirect. It showed up as a 404 error after leaving PayPal. Have a great weekend!

Cheers,

John

[supercoe]

Thanks for the beer JP, I thought I had all that PayPal stuff straightened out but I guess I'll have to look at it again.

Yay for another satisfied customer!

Keep posted to this forum, I have some other big programming projects going on right now but work on ChunkVNC happens slowly and surely.

Show some love for Rudi as without him and the other devs none of this would be possible.

Now back to topic, give me NAT2NAT!

[JPCoffey]

I already gave Rudi some love. Couldn't find the donation button on the site. It is on the very end at the bottom of the 'More...' menu. Rudi, make it easier for people to give you money!

Have a great weekend!


Sincerely,

John

[redge]

donate
http://www.uvnc.com/donate.html

[redge]

How much donation required for new nat2nat to repeater2011 amazing feature with UDT to ultravnc server and vncviewer and SC as native with a simple checkbox for activate the feature in case of some people don't want this feature or can't use it for security purpose.

[Rudi De Vos]

i has nothing todo with donation... i already have a daytime job.

The problem is time...
Current priority go to bugs in 1096, no addons only things that should have been working in 1096 before releasing it.

Then i try to compose nat2nat...

[redge]

OK for waiting 1097 with UDT and NAT2NAT native
and would be based on stable release core 10961

[F2snow]

Correct, this would not work when we use tcp.
That's why udt is used ( reliable udp)

Hi Rudi
it's first time I write here to try to contribute. (at least hope so)
The new way to connect is similar to this ? http://en.wikipedia.org/wiki/Direct_Client-to-Client
I remember that chat software used to transfer files from client to client without involve server.
thanks again for your big work

[beetroot]

Something maybe worth checking out when googling. Seems very impressive from this ex hacker

http://samy.pl/pwnat/

My method of penetrating NATs is two-fold which I will describe below.

In order for the full tunnel to be established, the client side needs to
know the public IP address of the server, and the server needs to learn
the public IP address of the client.

However, in a true client-server model, the server doesn't know the client IP
until the client connects, and NATs will normally drop unknown incoming packets.
In pwnat, the server also does not need to know the client IP address.

Here is how the pwnat server learns the IP address of the client:
I get around this by having the client "pretend" to be a random hop on
the Internet. I'm essentially using the same technology a traceroute uses
to detect hops on the Internet, but I'm doing the reverse in order to
penetrate the NAT.

Specifically, when the server starts up, it begins sending fixed ICMP echo
request packets to the fixed address 3.3.3.3. We expect that these packets
won't be returned.

Now, 3.3.3.3 is *not* a host we have any access to, nor will we end up spoofing
it. Instead, when a client wants to connect, the client (which knows the server
IP address) sends an ICMP Time Exceeded packet to the server. The ICMP packet
includes the "original" fixed packet that the server was sending to 3.3.3.3.

Why? Well, we're pretending to be a hop on the Internet, politely telling the
server that its original "ICMP echo request" packet couldn't be delivered.
Your NAT, being the gapingly open device it is, is nice enough to notice that
the packet *inside* the ICMP time exceeded packet matches the packet the server
sent out. It then forwards the ICMP time exceeded back to the server behind
the NAT, *including* the full IP header from the client, thus allowing the
server to know what the client IP address is!

Thx again for UVNC

[B]

Hmm, fascinating. As with most attempts at this sort of thing, one's mileage may vary:

"Will this work behind my corporate NAT and firewall?
This will work behind many NATs and firewalls, but not all."


http://www.bit-tech.net/news/hardware/2 ... sal-tool/1

http://news.softpedia.com/news/Samy-Wor ... 9132.shtml

http://www.pentestit.com/2010/05/04/pwn ... icate-nat/

Apparently there's a Windows port as well. I really don't see much peer review of the tool though. It sounds like a great idea.

"In 2007, Samy Kamkar was sentenced to three years on probation, 90 days of community service and was also ordered to pay an undisclosed amount of money to MySpace as restitution for the damages caused by the Samy worm. Since then, he has taken an interest in security, his motto being "think bad, do good," according to his Twitter profile."

[Rudi De Vos]

Final composed something ( alpha, test...)

http://www.uvnc.eu/download/repeater/nat2nat.zip

Test:
run winvnc ( enbale loopback and listening on port 5900)
run natserver on PC running winvnc.exe
run natviewer on viewer PC
Enter username natserver/natviewer and Sign In.
Wait for 3 greeen leds.
Start vncviewer (localhost:9001)

passwd: not used
user: you need to enter a name ( same name for server and viewer site)
Auth server: old http://www.uvnc.com, ip address is fixed

leds:
Signed in: Connection with 216.55.178.47 is made
Direct connection: connection between natserver and natviewer ( 216.55.178.47 is not longer used, no data
routing, like with the repeater)
Ready: Connection between natserver and natviewer is tested and ready, natviewer start listening on port 9001