ARTICLE AD BOX
I’m building a pure P2P UDP connection between two peers behind NAT. I have a public bootstrap server used only for signaling (peer discovery + exchanging public endpoints).
Goal:
Peer A and Peer B should communicate directly over UDP if possible (no relay in the “happy path”).
Bootstrap server is only used to exchange candidate addresses (like STUN-like behavior, but simplified).
Current flow:
Peer A opens a UDP socket on local port LA and sends a registration packet to Bootstrap.
Bootstrap records the observed public endpoint of A = (A_public_ip, A_public_port).
Peer B does the same → Bootstrap stores (B_public_ip, B_public_port).
When A wants to connect to B, Bootstrap shares B’s public endpoint with A (and A’s endpoint with B).
Both peers start sending “punch” packets to each other’s public endpoints.
Problem:
This works on (restricted / port-restricted) cone NATs.
It fails when either side is behind symmetric NAT (especially if both are symmetric).
Questions:
For restricted-cone / port-restricted cone NAT:
Is the above simultaneous punching sufficient?
Are there timing requirements or keepalive strategies needed to keep mappings open?
For symmetric NAT:
Is direct UDP hole punching fundamentally unreliable/impossible without a relay?
Are there any known techniques that increase success rate (port prediction, multiple sockets, multiple simultaneous punches, etc.)?
If both peers are behind symmetric NAT, is TURN-style relay the only practical solution?
Protocol design question:
Should I switch from my custom bootstrap to standard ICE (STUN + TURN)?
If yes, which part of ICE/STUN specifically solves the symmetric NAT case?
Extra info:
Both peers send UDP from a fixed local port.
Bootstrap only sees the public endpoint from the registration request.
I’m using QUIC.
I’m looking for a clear explanation of what’s possible/impossible for symmetric NAT, and what production systems do to handle this case.
Thanks.
