What the community was saying about NAT‑penetration in Pest

Time Speaker Key points
May 18 2023 – asciilifeform (broadcast) “unpx” Pointed to the draft section 5 (#5-nat-penetration) and noted that earlier drafts had a primitive NAT‑penetration approach.
Jan 14 2023 – jonsykkel (broadcast) First message “there’s crinkles for sure, some issues with handling both LAN/EXT IPs, no NAT penetration and no routing traffic via other greasynodes in case where cant establish direct p2p connection” – basically saying the current design can’t handle peers behind NATs or firewalls.
Jan 14 2023 – jonsykkel (broadcast) Follow‑up “primitive nat penetration like in pre‑hammer pest, it shares address+ports across net, so already does the same thing as smalpest” – acknowledges that earlier versions had a very basic NAT trick but it’s still inadequate.
Nov 15 2025 – awt_akris (broadcast) “Summarize discussion around nat penetration and proposed solutions.” The user is asking for a concise recap of the whole thread.

What was discussed

  1. Problem

    • Peers behind NATs/firewalls can’t receive inbound traffic, so they can’t establish direct P2P links.
    • Early Pest drafts simply assumed all nodes had public IPs; that broke in real‑world deployments.

  2. Early “primitive” solution

    • Pre‑hammer Pest shared address+port lists across the network (like a rudimentary STUN).
    • It worked only when both peers were on the same LAN or had compatible NATs—very limited.

  3. Section 5 of the draft

    • Introduces a formal “NAT‑penetration” section, proposing that each node registers its public address with a shared discovery service (“pestnet”).
    • Nodes then learn each other’s external endpoints and attempt hole‑punching (send packets to the same endpoint hoping the NAT forwards replies).

  4. Challenges still mentioned

    • Handling both LAN and external IPs simultaneously.
    • Avoiding routing traffic through other greasynodes when a direct link can’t be made.
    • Making sure the NAT‑penetration logic doesn’t become a bottleneck or single point of failure.

  5. Proposed next steps

    • Fully implement Section 5 so every node advertises its public address.
    • Add an optional relay layer (similar to TURN) for cases where hole‑punching fails, but keep it lightweight and auditable.
    • Keep the protocol simple enough that it can be formally verified.

Bottom line

The Pest community moved from “no NAT support” to a draft that explicitly handles NAT penetration via discovery + optional relays. The main takeaway is that peers should share their public addresses, try hole‑punching, and fall back to an intermediate relay if needed—while still keeping the design minimal and auditable.