Networks behind NAT

BlitzMax Forums/BlitzMax Programming/Networks behind NAT

ImaginaryHuman(Posted 2008) [#1]
Has anyone tackled getting a connection to multiple individual machines who are behind a NAT (address translation) as part of their router or whatever? I have been reading about it a bit and about how due to a limited number of available IP addresses NAT tries to open up the network packets and replaces their IP addresses with a single address, so that it then looks like the packet came from one place so you don't know how to get a packet to come back to the correct computer... how do you get around this? I seem to recall experiencing this issue on an IRC client where it would not allow my two computers to both be on the same server a the same time. (This isn't a question about IRC, it's about how to implement networking (over UDP probably) so that you can support multiple machines in a home network?


ImaginaryHuman(Posted 2008) [#2]
Anyone?


FlameDuck(Posted 2008) [#3]
Google for NAT Traversal. There are several more or less successful strategies that you may apply, depending on your specific needs.


ImaginaryHuman(Posted 2008) [#4]
Ok thanks Mr Duck.


Winni(Posted 2008) [#5]
NAT routers keep tables, so the router knows where to send replies to.

If you want to be able to access a computer behind a NAT router/proxy, you need a) to know your public IP address and b) configure the router to assign a public IP address to a private IP and route that traffic through to the machine with that IP.

If you only have one public IP, you can use port mapping; port 6666 can point to 192.168.0.100 and port 6667 could point to 192.168.0.101, for example.

In any case, you only need this kind of routing when you want to run SERVERS on your private network that have to be accessible from the outside.

Remember, the NAT proxy/router keeps an internal table of your outgoing traffic, and it knows to which client machine it has to send the response.


ImaginaryHuman(Posted 2008) [#6]
Why then do some games have support for playing on multiple machines behind a NAT while others don't?


ziggy(Posted 2008) [#7]
Becouse the server is public with static IP and is the user connecting to the server and not the other way. If there's not a game server, one of the clients has to accept connections so he needs a public known IP and port.


ImaginaryHuman(Posted 2008) [#8]
UDP doesn't really have `connections`, though.

What if every client is also a server?


Wings(Posted 2008) [#9]
its simple

i am doing this via TCPIP.


Blueapples(Posted 2008) [#10]
You can use firewall punching, pretty sure this works for NAT> Basically, both clients connect to the central server, and ask it to tell them who wants to connect to them. Each client then sends a UDP packet to the other, and viola! firewall punched.

Or anyway that's how I understand it. I've never had to do it.

"A somewhat more elaborate approach is where both hosts will start sending to each other, using multiple attempts. On a restricted Cone NAT, the first packet from the other host will be blocked. After that the NAT device has a record of having sent a packet to the other machine, and will let any packets coming from these IP address and port number through." UDP hole punching


ImaginaryHuman(Posted 2008) [#11]
So you get the client to send out a packet first and then it lets stuff through?


Blueapples(Posted 2008) [#12]
If they need to talk to each other directly, you get both clients to send stuff to each other using the central server to decide on a common port and figure out what ecah other's IP address is.

When each client sends packets to the other on the correct port, most NATs will see it as expected traffic and route it correctly. (A sends a packet to B on port 2000, this is blocked by B, but then B sends a packet to A on port 2000, this is accepted by A because it just sent a packet to B on that port, now A sends another packet to B and B accepts it now because it had previously sent a packet to A.)

If you only need the client to talk to the server then it should just work with NAT, provided you return packets on the same port that they sent them from (meaning you can't use 5 ports like HL2 does). This should just go right through NAT.

Now that I think about it, most firewalls will still block this, other than the built in Windows and Mac OS (I think, haven't tested it and I use Little Snitch) firewalls. Hopefully if the user has more than these permissive default firewalls installed, they will be adapt enough to configure their own firewall to let your traffic through.

I hope I'm not steering you wrong, it's been quite awhile since I had to do this kind of thing (haven't been in school for, oh what, three years? ;)

[Edited for clarity, though I doubt it's any clearer.]