Files
fips/testing/nat
Johnathan Corgan 43639fecb9 Add stun-faults integration suite covering STUN failure/recovery
Cover the previously untested STUN client behavior under server
unreachable, response timeout, and packet loss. The 3 NAT scenarios
test happy paths only; if the STUN client mishandled a fault (panic,
hang, missing log signal), it would silently degrade NAT traversal
without surfacing in CI.

testing/nat/scripts/stun-faults-test.sh (new, 244 lines):

Phase 1 (drop, ~12s): tc prio + netem loss 100% band + u32 filter on
dst 172.31.10.40 udp 3478. Falls back to iptables -j DROP if netem
isn't available. Asserts daemon process alive, no panic, log line
matching stun.*(timed?out|fail|fallback|unreachable|no address)
within the phase window.

Phase 2 (delay then clear, ~17s): tc qdisc add dev eth0 root netem
delay 5000ms for 7s, then deleted. 10s settle. Asserts process alive,
no panic, AND "STUN observation succeeded" log line after clear
(recovery proof).

Phase 3 (kill, ~12s): docker stop fips-nat-stun. Asserts process
alive, no panic, fault evidence in logs.

testing/nat/docker-compose.yml: stun-faults profile adds two
services. stun-fault-node is fips-test:latest on shared-lan at
172.31.10.50. stun-fault-shim is fips-test:latest sharing the
daemon's network namespace via network_mode: service:stun-fault-
node, with cap_add NET_ADMIN, NET_RAW; entrypoint sleep infinity so
the script can docker exec into it. Reuses existing stun
(172.31.10.40:3478) and relay (172.31.10.30:7777) services.

testing/nat/scripts/generate-configs.sh: 3-hunk update so the
generator accepts the new scenario and points its peer config at the
existing relay/STUN. The peer is configured for connect_peer() so
the daemon retries traversal on a loop, repeatedly invoking
observe_traversal_addresses() — which is the fault-injection target.

testing/ci-local.sh: STUN_FAULTS_SUITES=(stun-faults) array,
run_stun_faults runner, list/integration-loop/--only-dispatch hooks.

.github/workflows/ci.yml: matrix row {suite: stun-faults, type:
stun-faults} + 3 steps gated on matrix.type == 'stun-faults' between
nostr-publish-consume and any chaos suite. Reuses fips-linux
artifact + fips-test:latest image.

Approach: script-driven via docker exec stun-fault-shim. Sharing
network namespace means tc rules on the shim's eth0 affect daemon
egress. No timing logic in the shim itself.
2026-05-03 21:06:09 +00:00
..

NAT Lab Harness

Real Docker-based NAT traversal integration tests for the mainline FIPS Nostr/STUN bootstrap path.

This harness spins up:

  • two FIPS nodes
  • a local Nostr relay
  • a local STUN server
  • one or two Linux router containers performing NAT with iptables

For the NAT scenarios, the node LAN interfaces are not attached to Docker bridge networks. The harness creates explicit veth pairs and moves them into the node and router namespaces after docker compose up so every packet must traverse the router namespace.

It covers three scenarios:

  • cone: both peers behind explicit namespace/veth full-cone emulation, UDP traversal succeeds
  • symmetric: both peers behind symmetric-style NAT, UDP traversal fails, TCP fallback succeeds
  • lan: both peers share a LAN subnet, LAN targets are preferred over reflexive addresses

NAT model notes

The harness does not rely on plain Docker MASQUERADE for the cone case.

  • cone
    • uses explicit full-cone emulation in the router namespace
    • outbound UDP is SNATed to the router WAN address while preserving the source port
    • inbound UDP to the router WAN address is DNATed back to the single LAN host regardless of remote source
  • symmetric
    • uses UDP MASQUERADE --random-fully
    • outbound mappings may be port-randomized and are only reopened by matching conntrack state

This distinction matters because plain MASQUERADE is convenient source NAT, but it does not by itself model the "accept from any remote once mapped" behavior expected from a full-cone NAT.

Prerequisites

  • Docker with Compose support
  • locally built fips-test:latest

Build the test image with:

./testing/scripts/build.sh

Run

Run all scenarios:

./testing/nat/scripts/nat-test.sh

Run one scenario:

./testing/nat/scripts/nat-test.sh cone
./testing/nat/scripts/nat-test.sh symmetric
./testing/nat/scripts/nat-test.sh lan

Layout

  • docker-compose.yml
    • relay/STUN/WAN topology plus container definitions
  • node/
    • node bootstrap wrapper that waits for the injected veth interface
  • router/
    • NAT router image and iptables setup
  • stun/
    • minimal STUN binding responder
  • relay/
    • local strfry config
  • scripts/generate-configs.sh
    • derives ephemeral identities and writes per-scenario FIPS configs
  • scripts/setup-topology.sh
    • injects and configures the NAT LAN veth pairs in the container namespaces
  • scripts/nat-test.sh
    • boots the lab, waits for convergence, and asserts the resulting path

Assertions

  • cone

    • both nodes connect
    • connected transport is UDP
    • active link remote addresses are on the WAN NAT subnet
  • symmetric

    • NAT bootstrap does not establish a UDP link
    • fallback converges
    • connected transport is TCP via router-published WAN addresses
  • lan

    • both nodes connect
    • connected transport is UDP
    • active link remote addresses stay on the shared LAN subnet