Ah. I hope I didn't sow confusion there, hplus. My post was based on reading rather than personal experience. So you can reply using accept/recvfrom, but not send a new packet to the client on the same IP/port? What's the difference? I thought packet-wise it would be the same thing.

If you use TCP, when you call accept(), you will get a socket, that you write on to send to the connecting client. Nothing special is needed to do punch-through. If you want to know what external IP/port is visible for that client, accept() returns that value to you, but it's only useful for diagnostics, not necessarily for anything else.

If you use UDP, when you call recvfrom(), you will be given an IP address and port of the sending client for that packet. That's the address/port you should use to sendto() messages to that client. In UDP "sending messages" is all you can do; there is no "connection" per se. Typically, a router will keep the external IP/port open for returning packets for at least 10 seconds (often much more) after a message has been sent out, so if your protocol sends "idle" messages at least every 2 seconds, you should be keeping the connection alive.

If you use any other way to "find out" the address of the client in the server, then you are not properly NAT correct. Specifically, you cannot assume that the remote client will have any particular port number -- the actual port number assigned by the client's firewall will be part of what you receive in recvfrom() (or accept()).