By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
434,894 Members | 1,937 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 434,894 IT Pros & Developers. It's quick & easy.

Help! I can't find this info anywhere!

P: n/a
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?
Sep 30 '06 #1
Share this Question
Share on Google+
12 Replies


P: n/a
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.
"smerf" <sm***@shroom.comwrote in message
news:xS*******************@bignews8.bellsouth.net. ..
>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?


Sep 30 '06 #2

P: n/a
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?

"Terry Olsen" <to******@hotmail.comwrote in message
news:%2****************@TK2MSFTNGP03.phx.gbl...
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.
"smerf" <sm***@shroom.comwrote in message
news:xS*******************@bignews8.bellsouth.net. ..
>>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?



Sep 30 '06 #3

P: n/a
Check out http://www.ambrosiasw.com/~fprefect/codewhore/nat2.html .

According to this, The NAT will most likely reject an incoming packet from
an IP that it did not send a packet to. That makes sense - but it is
problematic for my needs.
"Terry Olsen" <to******@hotmail.comwrote in message
news:%2****************@TK2MSFTNGP03.phx.gbl...
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.
"smerf" <sm***@shroom.comwrote in message
news:xS*******************@bignews8.bellsouth.net. ..
>>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?



Sep 30 '06 #4

P: n/a
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.
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

--
Dave Sexton

"smerf" <sm***@shroom.comwrote in message news:xS*******************@bignews8.bellsouth.net. ..
>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?


Sep 30 '06 #5

P: n/a
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 :)
"smerf" <sm***@shroom.comwrote in message
news:K3******************@bignews3.bellsouth.net.. .
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?

"Terry Olsen" <to******@hotmail.comwrote in message
news:%2****************@TK2MSFTNGP03.phx.gbl...
>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.
"smerf" <sm***@shroom.comwrote in message
news:xS*******************@bignews8.bellsouth.net ...
>>>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?




Sep 30 '06 #6

P: n/a
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.

"Dave Sexton" <dave@jwa[remove.this]online.comwrote in message
news:O$**************@TK2MSFTNGP05.phx.gbl...
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.

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

--
Dave Sexton

"smerf" <sm***@shroom.comwrote in message
news:xS*******************@bignews8.bellsouth.net. ..
>>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?



Sep 30 '06 #7

P: n/a
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?
"Terry Olsen" <to******@hotmail.comwrote in message
news:Oi**************@TK2MSFTNGP03.phx.gbl...
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 :)
"smerf" <sm***@shroom.comwrote in message
news:K3******************@bignews3.bellsouth.net.. .
>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?

"Terry Olsen" <to******@hotmail.comwrote in message
news:%2****************@TK2MSFTNGP03.phx.gbl...
>>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.
"smerf" <sm***@shroom.comwrote in message
news:xS*******************@bignews8.bellsouth.ne t...
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?




Sep 30 '06 #8

P: n/a
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.

"smerf" <sm***@shroom.comwrote in message
news:yx******************@bignews3.bellsouth.net.. .
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?
"Terry Olsen" <to******@hotmail.comwrote in message
news:Oi**************@TK2MSFTNGP03.phx.gbl...
>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 :)
"smerf" <sm***@shroom.comwrote in message
news:K3******************@bignews3.bellsouth.net. ..
>>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?

"Terry Olsen" <to******@hotmail.comwrote in message
news:%2****************@TK2MSFTNGP03.phx.gbl.. .
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.
"smerf" <sm***@shroom.comwrote in message
news:xS*******************@bignews8.bellsouth.n et...
>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?
>
>




Sep 30 '06 #9

P: n/a
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.

"Terry Olsen" <to******@hotmail.comwrote in message
news:%2****************@TK2MSFTNGP03.phx.gbl...
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.

"smerf" <sm***@shroom.comwrote in message
news:yx******************@bignews3.bellsouth.net.. .
>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?
"Terry Olsen" <to******@hotmail.comwrote in message
news:Oi**************@TK2MSFTNGP03.phx.gbl...
>>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 :)
"smerf" <sm***@shroom.comwrote in message
news:K3******************@bignews3.bellsouth.net ...
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?

"Terry Olsen" <to******@hotmail.comwrote in message
news:%2****************@TK2MSFTNGP03.phx.gbl. ..
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.
>
>
"smerf" <sm***@shroom.comwrote in message
news:xS*******************@bignews8.bellsouth. net...
>>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?
>>
>>
>
>




Sep 30 '06 #10

P: n/a
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!
"smerf" <sm***@shroom.comwrote in message
news:9S*******************@bignews3.bellsouth.net. ..
>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.

"Terry Olsen" <to******@hotmail.comwrote in message
news:%2****************@TK2MSFTNGP03.phx.gbl...
>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.

"smerf" <sm***@shroom.comwrote in message
news:yx******************@bignews3.bellsouth.net. ..
>>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?
"Terry Olsen" <to******@hotmail.comwrote in message
news:Oi**************@TK2MSFTNGP03.phx.gbl...
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 :)
"smerf" <sm***@shroom.comwrote in message
news:K3******************@bignews3.bellsouth.ne t...
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?
>
>
>
"Terry Olsen" <to******@hotmail.comwrote in message
news:%2****************@TK2MSFTNGP03.phx.gbl.. .
>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.
>>
>>
>"smerf" <sm***@shroom.comwrote in message
>news:xS*******************@bignews8.bellsouth .net...
>>>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?
>>>
>>>
>>
>>
>
>




Sep 30 '06 #11

P: n/a
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.

--
Dave Sexton

"smerf" <sm***@shroom.comwrote in message news:4o*****************@bignews3.bellsouth.net...
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.

"Dave Sexton" <dave@jwa[remove.this]online.comwrote in message news:O$**************@TK2MSFTNGP05.phx.gbl...
>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.

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

--
Dave Sexton

"smerf" <sm***@shroom.comwrote in message news:xS*******************@bignews8.bellsouth.net. ..
>>>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?




Sep 30 '06 #12

P: n/a

"smerf" <sm***@shroom.comwrote in message
news:9S*******************@bignews3.bellsouth.net. ..
>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.
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.
>
"Terry Olsen" <to******@hotmail.comwrote in message
news:%2****************@TK2MSFTNGP03.phx.gbl...
>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.

"smerf" <sm***@shroom.comwrote in message
news:yx******************@bignews3.bellsouth.net. ..
>>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?
"Terry Olsen" <to******@hotmail.comwrote in message
news:Oi**************@TK2MSFTNGP03.phx.gbl...
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 :)
"smerf" <sm***@shroom.comwrote in message
news:K3******************@bignews3.bellsouth.ne t...
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?
>
>
>
"Terry Olsen" <to******@hotmail.comwrote in message
news:%2****************@TK2MSFTNGP03.phx.gbl.. .
>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.
>>
>>
>"smerf" <sm***@shroom.comwrote in message
>news:xS*******************@bignews8.bellsouth .net...
>>>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?
>>>
>>>
>>
>>
>
>




Oct 10 '06 #13

This discussion thread is closed

Replies have been disabled for this discussion.