UDP packets to PC behind NAT

[Janto Dreijer]

This is probably more of a networking question than a Python one, but
it would be nice to know if someone has done this with Python's socket
module. And besides one usually gets more information from c.l.py than
anywhere else :)

I have a server with a static "public" IP and a client behind a NAT. I
would like to send UDP packets from the server to the client. So what I
need to do is open up a "hole" in the NAT and let the server know the
target IP and port of the client where it can send its packets.

Now I have read somewhere that you can have TCP and UDP running on the
same port. Not sure if this is true. Would it be a reasonable solution
to initiate a TCP connection from the client to the server and somehow
(?) let the server figure out how the client is connecting? And then
send UDP to client over the same (IP, port)?

[Christophe]

Janto Dreijer a écrit :

This is probably more of a networking question than a Python one, but
it would be nice to know if someone has done this with Python's socket
module. And besides one usually gets more information from c.l.py than
anywhere else :)

I have a server with a static "public" IP and a client behind a NAT. I
would like to send UDP packets from the server to the client. So what I
need to do is open up a "hole" in the NAT and let the server know the
target IP and port of the client where it can send its packets.

Now I have read somewhere that you can have TCP and UDP running on the
same port. Not sure if this is true. Would it be a reasonable solution
to initiate a TCP connection from the client to the server and somehow
(?) let the server figure out how the client is connecting? And then
send UDP to client over the same (IP, port)?

Initiate an UDP connection from the client to the server and have the
server send back the UDP packets to the address you get in the
"recvfrom" result.

[Janto Dreijer]

Awesome! I haven't tested it on the actual server but I think it works.
Thanks!
I prefer a TCP connection solution and will post one if it works.

server.py
========
from socket import *
print "listening"
UDPSock = socket(AF_INET, SOCK_DGRAM)
UDPSock.bind(("localhost", 1234)) # visibility to outside world
payload, addr = UDPSock.recvfrom(1024)
print "message from %s: %s" % (`addr`, payload)
UDPSock = socket(AF_INET, SOCK_DGRAM) # open UDP socket
result = UDPSock.sendto("your public address is %s" % `addr`, addr)

client.py
=====
from socket import *
UDPSock = socket(AF_INET, SOCK_DGRAM) # open UDP socket
result = UDPSock.sendto("what's my public address?", ("localhost",
1234))
payload, addr = UDPSock.recvfrom(1024)
print payload

results:
====
listening
message from ('127.0.0.1', 32787): what's my public address?

your public address is ('127.0.0.1', 32787)

[Grant Edwards]

On 2006-09-15, Christophe <ch*************@free.frwrote:

Initiate an UDP connection from the client to the server and
have the server send back the UDP packets to the address you
get in the "recvfrom" result.

There's no such thing as a "UDP connection", so I don't
understand what you're suggesting.

--
Grant Edwards grante Yow! By MEER biz doo
at SCHOIN...
visi.com

[Grant Edwards]

On 2006-09-15, Janto Dreijer <ja****@gmail.comwrote:

I have a server with a static "public" IP and a client behind a NAT. I
would like to send UDP packets from the server to the client. So what I
need to do is open up a "hole" in the NAT and let the server know the
target IP and port of the client where it can send its packets.

Now I have read somewhere that you can have TCP and UDP running on the
same port.

True.

Not sure if this is true.

It is.

Would it be a reasonable solution to initiate a TCP connection
from the client to the server and somehow (?) let the server
figure out how the client is connecting? And then send UDP to
client over the same (IP, port)?

I doubt that will work unless the firewall has been
specifically designed to recognize that pattern of activity and
allow the incoming UDP packets. I don't think most firewall
have default rules that allow UDP packets to tunnel back along
a TCP connection.

--
Grant Edwards grante Yow! Clear the
at laundromat!! This
visi.com whirl-o-matic just had a
nuclear meltdown!!

[Janto Dreijer]

Oops. That second UDPSock = socket(...) in the server.py shouldn't be
there.

Janto Dreijer wrote:

Awesome! I haven't tested it on the actual server but I think it works.
Thanks!
I prefer a TCP connection solution and will post one if it works.

server.py
========
from socket import *
print "listening"
UDPSock = socket(AF_INET, SOCK_DGRAM)
UDPSock.bind(("localhost", 1234)) # visibility to outside world
payload, addr = UDPSock.recvfrom(1024)
print "message from %s: %s" % (`addr`, payload)
UDPSock = socket(AF_INET, SOCK_DGRAM) # open UDP socket
result = UDPSock.sendto("your public address is %s" % `addr`, addr)

client.py
=====
from socket import *
UDPSock = socket(AF_INET, SOCK_DGRAM) # open UDP socket
result = UDPSock.sendto("what's my public address?", ("localhost",
1234))
payload, addr = UDPSock.recvfrom(1024)
print payload

results:
====
listening
message from ('127.0.0.1', 32787): what's my public address?

your public address is ('127.0.0.1', 32787)

[Janto Dreijer]

Grant Edwards wrote:

On 2006-09-15, Christophe <ch*************@free.frwrote:

Initiate an UDP connection from the client to the server and
have the server send back the UDP packets to the address you
get in the "recvfrom" result.

There's no such thing as a "UDP connection", so I don't
understand what you're suggesting.

I think he means "connection" as in "associated ip/port". Which
actually does work, as I've posted.

[Janto Dreijer]

Grant Edwards wrote:

On 2006-09-15, Janto Dreijer <ja****@gmail.comwrote:

....

Would it be a reasonable solution to initiate a TCP connection
from the client to the server and somehow (?) let the server
figure out how the client is connecting? And then send UDP to
client over the same (IP, port)?

I doubt that will work unless the firewall has been
specifically designed to recognize that pattern of activity and
allow the incoming UDP packets. I don't think most firewall
have default rules that allow UDP packets to tunnel back along
a TCP connection.

Thanks for the info!

I think you may be right. I had to configure the local firewall to
allow all connections from the server. Which kinda defeats the purpose.
If you have control over the NAT why not just assign a dedicated port?

There might still be value in this approach, however. Even though I
have control over the NAT I have multiple clients that might need to
create these connections. I would need to map ports to be able to
handle simultaneous connections.

It's Friday afternoon over here, so I may be wrong...

[Steve Holden]

Janto Dreijer wrote:

Grant Edwards wrote:

>>On 2006-09-15, Janto Dreijer <ja****@gmail.comwrote:

....

>>>Would it be a reasonable solution to initiate a TCP connection
from the client to the server and somehow (?) let the server
figure out how the client is connecting? And then send UDP to
client over the same (IP, port)?

I doubt that will work unless the firewall has been
specifically designed to recognize that pattern of activity and
allow the incoming UDP packets. I don't think most firewall
have default rules that allow UDP packets to tunnel back along
a TCP connection.

Thanks for the info!

I think you may be right. I had to configure the local firewall to
allow all connections from the server. Which kinda defeats the purpose.
If you have control over the NAT why not just assign a dedicated port?

There might still be value in this approach, however. Even though I
have control over the NAT I have multiple clients that might need to
create these connections. I would need to map ports to be able to
handle simultaneous connections.

It's Friday afternoon over here, so I may be wrong...

Note that TCP and UDP port spaces are disjoint, so there's no way for
TCP and UDP to use "the same port" - they can, however, use the same
port number. Basically the TCP and UDP spaces have nothing to do with
each other.

Most dynamic NAT gateways will respond to an outgoing UDP datagram by
mapping the internal client's UDP port to a UDP port on the NAT
gateway's external interface, and setting a converse mapping that will
allow the server to respond, even though technically there isn't a
"connection". The NAT table entries will typically be timed out after a
short period of non-use.

regards
Steve
--
Steve Holden [phone] [phone]
Holden Web LLC/Ltd http://www.holdenweb.com
Skype: holdenweb http://holdenweb.blogspot.com
Recent Ramblings http://del.icio.us/steve.holden

[Janto Dreijer]

Steve Holden wrote:

Note that TCP and UDP port spaces are disjoint, so there's no way for
TCP and UDP to use "the same port" - they can, however, use the same
port number. Basically the TCP and UDP spaces have nothing to do with
each other.

Most dynamic NAT gateways will respond to an outgoing UDP datagram by
mapping the internal client's UDP port to a UDP port on the NAT
gateway's external interface, and setting a converse mapping that will
allow the server to respond, even though technically there isn't a
"connection". The NAT table entries will typically be timed out after a
short period of non-use.

So are you saying one can't use TCP to punch a hole for UDP?

[Grant Edwards]

On 2006-09-16, Janto Dreijer <ja****@gmail.comwrote:

Steve Holden wrote:

>Note that TCP and UDP port spaces are disjoint, so there's no way for
TCP and UDP to use "the same port" - they can, however, use the same
port number. Basically the TCP and UDP spaces have nothing to do with
each other.

Most dynamic NAT gateways will respond to an outgoing UDP datagram by
mapping the internal client's UDP port to a UDP port on the NAT
gateway's external interface, and setting a converse mapping that will
allow the server to respond, even though technically there isn't a
"connection". The NAT table entries will typically be timed out after a
short period of non-use.

So are you saying one can't use TCP to punch a hole for UDP?

Yes, that's what he's saying -- or at least that there's no
reason to expect it to work.

--
Grant Edwards
gr****@visi.com

[Paul Rubin]

"Janto Dreijer" <ja****@gmail.comwrites:

Most dynamic NAT gateways will respond to an outgoing UDP datagram by
mapping the internal client's UDP port to a UDP port on the NAT
gateway's external interface, and setting a converse mapping that will
allow the server to respond, even though technically there isn't a
"connection". The NAT table entries will typically be timed out after a
short period of non-use.

So are you saying one can't use TCP to punch a hole for UDP?

You might look at some of the Q2Q stuff that simulates TCP over UDP.

http://divmod.org/trac/wiki/DivmodVertex

http://twistedmatrix.com/users/moshez/q2q.html

[John J. Lee]

"Janto Dreijer" <ja****@gmail.comwrites:

Steve Holden wrote:

Note that TCP and UDP port spaces are disjoint, so there's no way for
TCP and UDP to use "the same port" - they can, however, use the same
port number. Basically the TCP and UDP spaces have nothing to do with
each other.

Most dynamic NAT gateways will respond to an outgoing UDP datagram by
mapping the internal client's UDP port to a UDP port on the NAT
gateway's external interface, and setting a converse mapping that will
allow the server to respond, even though technically there isn't a
"connection". The NAT table entries will typically be timed out after a
short period of non-use.

So are you saying one can't use TCP to punch a hole for UDP?

If server and client know what to do it's always possible to tunnel
anything over anything, but as Steve explained, there would be no need
for the UDP and TCP port numbers to match (and of course, tunneling
UDP over TCP is a slightly odd thing to be doing :-).
John