p2pRemote

Technical concepts

How P2P NAT Traversal Works

NAT traversal attempts to create a direct communication path between devices behind routers. Results depend on NAT behavior, firewall policy, and ISP networks at both ends.

Why traversal is required

A home router translates several private IPv4 addresses to a public address. Unsolicited inbound traffic normally has no mapping, so the peers exchange reachable endpoints and send traffic in a coordinated way to create state on both paths.

From discovery to a tunnel

  1. Gather local addresses and discover the translated public endpoint.
  2. Exchange candidates through the coordination service.
  3. Try candidate pairs so NATs and firewalls create return-path state.
  4. Create the encrypted tunnel and assign virtual addresses from 100.99.71.0/24.

Note: This is a simplified conceptual model. p2pRemote's implementation is not the same protocol as browser WebRTC ICE.

Mapping and filtering behavior

  • Endpoint-independent mappings are usually easier to traverse.
  • Endpoint-dependent mappings can allocate a different port for every destination.
  • Address- or port-dependent filtering requires correctly timed outbound traffic.
  • Enterprise firewalls may block unknown UDP even when the NAT mapping works.

Double NAT and CGNAT

A routing modem plus a second router creates two translations. Mobile and some fixed-line networks add carrier-grade NAT. Each uncontrolled layer can reduce direct-connect success.

  • Private or 100.64.0.0/10 WAN addresses indicate upstream NAT.
  • Compare the router WAN address with a public-IP lookup.
  • IPv6 avoids some IPv4 NAT constraints but remains subject to firewall policy.

Standards background

STUN discovers translated endpoints, ICE tests candidate paths, and TURN relays traffic when no direct path works.

References: RFC 8489: STUN · RFC 8445: ICE · RFC 8656: TURN