Hi, I'm trying to implement NAT punch through using ENet, but without any luck.
I've already modified the enet protocol code to support "out of band" packets needed to do the punching.
Right now the steps used to connect 2 peers are the following:
- Peer A connects with introducer and sends his private address
- Peer B connects with introducer and sends his private address
- Peer A sends a request to introducer to connect with B
- Introducer sends B public & private address to A
- A sends an out of band packet to B public endpoint (using enet_socket_send), and notifies the introducer.
- The introducer forwards the notification to B along with A public & private address
- B receives the notification and sends out of band backets to A public and private address
- A connects to the source address of the first out of band packet received
For now I've only tried this method with port-restricted cone nats (tested with STUN), without success.
When the peers are behind the same NAT it goes all well (obviously...:D), they even connects using the public address (if the NAT supports hair-pin).
If someone have had previous experiences implementing NAT punch with ENet and could share some information/tips I would be grateful.
nat punch through with ENet
Some routers will not work with NAT punch through, usually their firewall blocks such attempts as suspicious activity. Have you tried using a different working NAT solution to check your internet configuration?
You are welcome to register for ReplicaNet, download the SDK and run Example 11. This will test NAT punch through is working by advertising a session with the RNLobby API and then waiting for a connection from another instance of the example.
You are welcome to register for ReplicaNet, download the SDK and run Example 11. This will test NAT punch through is working by advertising a session with the RNLobby API and then waiting for a connection from another instance of the example.
Some firewalls require the outgoing packet to come before the incoming packet.
Thus, what you want is to tell both A and B at the same time that they want to make a connection, and they will both try to send the first packet at the same time. Hopefully, latencies makes it so that they both see the outgoing packet before the incoming.
You can be a little more safe about it by sending the first packet with a really small TTL (something like 2 or 3), and report back to the introducer, and the introducer then tells you when to send the next packet with a bigger TTL to actually try to get to the other end.
Finally, some firewalls do "symmetric" NAT, which actually breaks the IP protocol, and is very hostile to NAT punch-through. Basically, they allocate a new outgoing port number for each (IP,port) pair, even for two outgoing streams from the same source port. If your firewall is like that, then you have to "guess" what the next outgoing port number will be. A good guess is some number in the range [1..32] above the port number you saw at the introducer.
Thus, what you want is to tell both A and B at the same time that they want to make a connection, and they will both try to send the first packet at the same time. Hopefully, latencies makes it so that they both see the outgoing packet before the incoming.
You can be a little more safe about it by sending the first packet with a really small TTL (something like 2 or 3), and report back to the introducer, and the introducer then tells you when to send the next packet with a bigger TTL to actually try to get to the other end.
Finally, some firewalls do "symmetric" NAT, which actually breaks the IP protocol, and is very hostile to NAT punch-through. Basically, they allocate a new outgoing port number for each (IP,port) pair, even for two outgoing streams from the same source port. If your firewall is like that, then you have to "guess" what the next outgoing port number will be. A good guess is some number in the range [1..32] above the port number you saw at the introducer.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
