Help! I can't find this info anywhere!

  • Thread starter Thread starter smerf
  • Start date Start date
S

smerf

I have searched high and low (and even in some places I'd like to forget I
ever saw) for the information that will tell me exactly how the Nat2Nat
server for UltraVNC works (not just a vague diagram, but the code needed -
at least psuedocode - to connect the 2 clients) . (You can see it at
http://www.uvnc.com/addons/nat2nat.html.)

I get the diagram and all, but how exactly would you get 2 UDP connections
to your UDP server to start talking to each other instead of the server?

As I see it, the whole reason for the Nat2Nat server is to get 2 PCs that
can only make ooutgoing connections (because they are behind NATs) to
connect directly. If they have already connected to the UDP server and
cannot accept incoming connections, how do you get them connected directly
to each other and drop the Nat2Nat server from the loop?

What's the trick to this? Does anybody know?
 
Seems to me that the Nat2Nat server would send the IP/Port of the opposite
client to each client. Then they would send further communiction directly to
the other client instead of going through the server.
 
But how? When you write a server you can create addidtional sockets and use
one of them to accept an incoming connection on another port. But, I have
never seen a method of accepting an incoming connection on another IP
address.

Are you suggesting telling each PC to redirect to the client UDP ports
detected by the server? If so, wouldn't the connectionless nature of UDP be
a problem? Do firewalls and NATs keep UDP ports open to the same client or
so they simply choose another port at random for the next outgoing request?
 
Hi,
As I see it, the whole reason for the Nat2Nat server is to get 2 PCs that can only make ooutgoing connections (because they are
behind NATs) to connect directly.
Click to expand...

How can they connect directly to each other if they can only make outgoing connections? In other words, if they won't accept
incoming connections then you're stuck connecting through a server.

HTH
 
I'm just guessing here, I haven't tried anything like this myself, but...

When your client receives the IP/Port of the other client, wouldn't it then
send a fake packet out to the other client just to open up the port for the
other client's IP address?

I'm not claiming to know anything here, just guessing...but to me it seems
logical :)
 
That IS the question. How indeed...

But, UltraVNC claims to do this...many games use this same P2P connection
protocol to tunnel through firewalls (or so I have read). I just can't find
out how it is being done so that I can enable my apps in a similar fashion.
 
That makes sense initially.

But, consider this.... Client 1 connects to Nat2Nat Server to say "I'm
here!" and to get the IP/Port of Client 2. In order to get this primary
connection and data from the Nat2Nat Server, Client 1's NAT puts an entry in
the NAT IP table that indicates the Nat2Nat Server is the external endpoint.
If a packet comes in to Client 1's NAT with a different external endpoint
than is written in the NATs IP table, Client 1's NAT won't know which of its
clients the packet is for and will drop it.

And, how do you rewrite the UDP header info when establishing a connection?
 
Of course it will drop the "dummy" packet. The client that sent the dummy
packet only did that to open up its own port to receive packets from the
other clients IP address. The other client would send out its own "dummy"
packet to open up its port also. If you initiate communication with a
remote end point, then you open up the port for that end point to talk back.
 
I understand...but.....

For you to open an endpoint to a NATed client using a "dummy" packet, you
must first know what port the NAT has given the other client's endpoint.
Without that info, what "dummy" data could you use to create the UDP
connection?

The originating endpoint is not aware of the external Port/IP assigned to it
by the NAT. The only way to get this info is from the endpoint that accepts
the connection (the Nat2Nat server). But, once that is done, the NAT has
now the Nat2Nat server in its ip tables as the endpoint for the originating
client's UDP communications.
 
This is like some F'ing Twilight Zone episode!

I finally find a site that may have some people familiar with this problem
(gamedev.net) and immediately after I register for their forums, the site
goes down.

F'ing incredible!
 
Hi,

My question was rhetorical. Unfortunately it's hard to express two things in newsgroups: Rhetorical questions and sarcasm. I'll
try to abstain from using both from now on :)

There is no way around having to connect through an external server when incoming connections are blocked.

If you have software running on each client machine then they both must connect to a remote server. Then, the remote server can
respond with the port that one client must open to listen for incoming connections and that the other client must use to connect
(obviously the IP must be sent as well to the latter client). The first client essentially becomes the server.

It appears that the diagram from the link in your OP already illustrates what I've stated here, somewhat. If you already have that
software then you should refer to its documentation to figure out how it works and the configuration you'll need on your LAN
hardware and PC's.

You can only use a remote server to establish a connection between two clients if:

1. The client software has the ability to listen for incoming connections on the port specified by the server
2. The external router will route incoming packets to the client
3. No firewall, external or internal, will block packets on the incoming port (I think UPnP can be used to open the required ports
programmatically)
(Have I forgotten anything important?)

I don't think the protocol, such as UDP or TCP, actually matters.

Trying to trick the client computer into opening up a port (it seems your other posts are heading in that direction) doesn't sound
like a good idea to me. Network address spoofing sounds like a bad idea too.
 
smerf said:
I understand...but.....

For you to open an endpoint to a NATed client using a "dummy" packet, you
must first know what port the NAT has given the other client's endpoint.
Without that info, what "dummy" data could you use to create the UDP
connection?

The originating endpoint is not aware of the external Port/IP assigned to
it by the NAT. The only way to get this info is from the endpoint that
accepts the connection (the Nat2Nat server). But, once that is done, the
NAT has now the Nat2Nat server in its ip tables as the endpoint for the
originating client's UDP communications.
Click to expand...

You're operating under the mistaken impression that the NAT mapping depends
on the outside IP address. It doesn't. It's the local node's private IP
address that gets associated to the port number so the NAT router can
correctly rewrite incoming packets. For outgoing packets, the sender has
already put the correct public IP address of the recipient into the packet,
no translation is needed.

There may be a limitation to accepting "return" packets from a IP you've
already sent to, this would be on routers that advertise "stateful packet
inspection firewall", and that's the purpose of sending the dummy outgoing
packet -- to get registered in the router as a permitted connection,
initiated from inside.
 
Back
Top