User Name on Telegram: Mykola Babenko
The user reported a bug in the Telegram ThreeFold Grid Tester Community. The details are provided below:
Describe the bug
Two mainnet nodes in an 8-node deployment (node 8009 and node 11) exhibit symmetric NAT on their outbound path, while the other six nodes in the same deployment do not. tailscale netcheck run inside the guest reports MappingVariesByDestIP: true on those two nodes and false on every other node. Symmetric NAT is a well-documented failure mode for STUN-based WireGuard/Tailscale hole-punching, and in practice some external clients cannot establish a peer connection to workloads on these two nodes.
Environment
- Network: TF mainnet
- Provisioning: Terraform Grid provider (threefoldtech/grid), single deployment, 8 VMs across 8 nodes
- Guest: identical base OS image + identical overlay client (Tailscale/WireGuard) on all 8 VMs
- Overlay: self-hosted coordination + self-hosted relay, in addition to public relays
Affected vs. healthy nodes
Symmetric NAT (MappingVariesByDestIP: true) — ABNORMAL:
- Node 8009 — 213.232.253.53:10405 — nearest relay: Amsterdam (public)
- Node 11 — 185.69.166.2:48015 — nearest relay: self-hosted
Endpoint-independent NAT (false) — healthy, for comparison:
- Node 1 — self-hosted
- Node 13 — 185.69.167.146:38850 — self-hosted
- Node 10 — self-hosted
- Node 6968 — self-hosted
- Node 388 — self-hosted
- Node 50 — 185.69.167.143:54344 — self-hosted
The six healthy nodes report endpoint-independent NAT (false); only 8009 and 11 report true. Note 8009 sits in a different netblock/region entirely (213.232.253.x), and 11 is on 185.69.166.x versus the healthy 185.69.167.x — consistent with these two nodes sitting behind different upstream gateways.
Steps to reproduce the behavior:
- Deploy identical VMs across nodes 8009, 11, and any of the healthy nodes above.
- Inside each guest, run tailscale netcheck (or any STUN-based NAT-type probe).
- Observe MappingVariesByDestIP: true on 8009 and 11, false on the others.
Expected behavior
Either (a) egress NAT behavior is consistent across nodes offering the same capacity, or (b) if it cannot be (because it depends on the farmer's upstream network), the node's NAT type / reachability class is discoverable — surfaced on the node's public config / dashboard / node health so operators can select or avoid symmetric-NAT nodes before deploying, rather than discovering it only from inside the guest after the fact.
Here is the user sharing bug report:
Bug report.pdf
User Name on Telegram: Mykola Babenko
The user reported a bug in the Telegram ThreeFold Grid Tester Community. The details are provided below:
Describe the bug
Two mainnet nodes in an 8-node deployment (node 8009 and node 11) exhibit symmetric NAT on their outbound path, while the other six nodes in the same deployment do not. tailscale netcheck run inside the guest reports MappingVariesByDestIP: true on those two nodes and false on every other node. Symmetric NAT is a well-documented failure mode for STUN-based WireGuard/Tailscale hole-punching, and in practice some external clients cannot establish a peer connection to workloads on these two nodes.
Environment
Affected vs. healthy nodes
Symmetric NAT (MappingVariesByDestIP: true) — ABNORMAL:
Endpoint-independent NAT (false) — healthy, for comparison:
The six healthy nodes report endpoint-independent NAT (false); only 8009 and 11 report true. Note 8009 sits in a different netblock/region entirely (213.232.253.x), and 11 is on 185.69.166.x versus the healthy 185.69.167.x — consistent with these two nodes sitting behind different upstream gateways.
Steps to reproduce the behavior:
Expected behavior
Either (a) egress NAT behavior is consistent across nodes offering the same capacity, or (b) if it cannot be (because it depends on the farmer's upstream network), the node's NAT type / reachability class is discoverable — surfaced on the node's public config / dashboard / node health so operators can select or avoid symmetric-NAT nodes before deploying, rather than discovering it only from inside the guest after the fact.
Here is the user sharing bug report:
Bug report.pdf