I was wondering if tcp/udp hole punching would still work when you are in the same network (behind a NAT), and what the packet's path would be.

What happens when using hole punching on the same network, is that it will send a packet out with the same destination and source address. Only the source and destination port would differ. I imagine a router with NAT loopback enabled will handle this as it should, but how about other routers? Would they drop the packet, or would a router (the first?) from the ISP bounce the packet back after which it gets handled okay?

I'm wondering because I was thinking about using this technique to circumvent a block between peers in a network (like a school network where clients can only access the internet, but any contact with each other is blocked). The only other option is to use a man in the middle as proxy (tunnel?). The disadvantage of this is that you have to have a server with significantly more bandwidth than one that would only do hole punching. Also the latency would increase significantly.

  • You can try it, but it's very unlikely to work. A NAT device typically will not rewrite both the source and destination IP addresses of a single packet unless specifically configured to do so. Sep 27 '12 at 20:23
  • @DavidSchwartz It doesn't have to rewrite both fields. It seems (also seeing the answer that was just posted) my question is a bit unclear...
    – Luc
    Sep 27 '12 at 21:20
  • It does have to rewrite both fields. Say machine A is talking to machine B through router R. The packet from A is addressed A->R. The packet it must pass to B must be addressed R->B. (It must rewrite the source so it can NAT the replies. And it must rewrite the destination to get the packet to B at all.) So it must rewrite both the source and destination IP addresses. Jan 28 '13 at 14:29

That's called NAT Hairpinning. A NAT that support Hairpinning can do translation even if both peers are in the same NAT.

  • Could you explain how NAT Hairpinning differs from NAT Loopback? Thanks!
    – Luc
    Jan 28 '13 at 16:05
  • Just found out them to the same thing. You can easily check it by running a STUN client, such as sourceforge.net/projects/stun. Jan 29 '13 at 1:02

The router will only "route" when the destination network differs from the sending network.

So if the source computer is on IP address with a mask of and the destination address is, the NAT router will ignore it, only the switch(s) will handle it.

If the destination were then you would need a router but, depending on the routers configuration, it is likely that the route would still not hit the NAT part since you wouldn't normally NAT on an internal network. NAT adds overheads and issues that you wouldn't want and you should never need NAT internally.

So what you are suggesting would not work.

Indeed, if peer-to-peer traffic is being blocked, this is probably happening with a transparent filter of some sort.

The only way around this is to find a channel that does work between the peers and then run an encrypted channel over this.

Finally, since the peer-to-peer connections are being blocked, trying to circumvent the block WILL be a contravention of your terms of service - you will be kicked off the network, possibly be expelled (from school) or even face criminal prosecution - really not worth it! Set up your own WiFi network instead for peer-to-peer traffic.

  • The block is probably to mitigate attacks such as ARP cache poisoning or browsing SMB shares or so. Hole punching enables a direct connection while still making these attacks impossible (also basically, the traffic is identical to internet traffic). Legal issues aside though, the point is that internal IPs aren't usable because internal traffic between hosts is blocked. When the udp/tcp hole is made, the public IP from the clients will be used. I was wondering how the NAT router reacted to a packet that both comes from and goes to his WAN IP, especially when it hasn't got NAT loopback.
    – Luc
    Sep 27 '12 at 21:17
  • Any decent router should drop any packet that doesn't follow the expected rules. You would have to bounce the packets off an external server to force it through the external port of the router. Packets from the internal network will not trigger NAT. Sep 27 '12 at 21:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.