Johnathan Corgan
1cc069f1a2
The TUN adapter, the .fips DNS responder, ICMPv6 generation and TCP MSS clamping are the host-side IPv6 plane, but the code was split between src/upper and inline bodies in the node's session handler and lifecycle. Gather it into one module, src/ipv6tun, and reduce its calls into the rest of the crate to a small explicit set. This prepares the TUN adapter to run later as a separate daemon over the native API, and gives embedders one place to find the host-side surface. Behaviour is unchanged apart from log target names. - Rename src/upper to src/ipv6tun. A `pub use ipv6tun as upper;` alias keeps every crate::upper:: and fips::upper:: path resolving, so no consumer has to change. - Move hosts.rs whole to src/hosts.rs, a top-level public module: the hosts file also serves peer display names, the peer ACL and fipsctl, so it is not host-side only. ipv6tun re-exports it for the old path. - Move the DNS socket helpers (dual-stack bind, IPV6_RECVPKTINFO, interface index lookup) from Node into ipv6tun::dns, unchanged. Node::mesh_ifindex, which reads the live TUN device name, becomes Handles::mesh_ifindex. - Move ICMPv6 Destination Unreachable and Packet Too Big sending into ipv6tun::icmp behind IcmpContext, which borrows the TUN channel, our address and the Packet Too Big rate limiter for one use. Packet Too Big is still rate limited and Destination Unreachable still is not. The discovery lookup timeout hands its queued packets over as one no-route report. - Split handle_tun_outbound. The host-side half, in ipv6tun::outbound, validates the packet, makes both Packet Too Big decisions and sends the ICMPv6 replies, reaching the mesh through a small Mesh trait Node implements. The mesh-side half, Node::send_outbound, stays with the pending queue. The checks run in the same order with the same thresholds, and Node::handle_tun_outbound remains the entry point. - Move the TUN and DNS child start and stop bodies into ipv6tun::lifecycle, and gather their nine supervisor fields and the node's TUN device name into one Handles struct the supervisor holds. The supervisor arms, their order and the child-exit reporting are unchanged. A TUN still counts as up when it has a device name, so an app-owned TUN produces no TUN teardown, and DNS counts as up while its task runs. The node passes a new peer-alias base to the running responder through Handles::publish_aliases. Node::tun_name, tun_tx, dns_local_addr and enable_app_owned_tun keep their behaviour; tests install a TUN sender through a test-only Node::install_tun. Tracing targets follow module paths, so lines from the moved code now log under fips::ipv6tun::* and fips::hosts instead of fips::upper::*, fips::node::lifecycle and fips::node::handlers::session. Update the RUST_LOG example in the MTU diagnosis guide and the test harness filters that relied on the old targets, and note the rename in the changelog.
Firewall Baseline Test
End-to-end exercise of the production fips0 nftables baseline at
packaging/common/fips.nft. Closes the v0.3.0 audit gap that the
default-deny + conntrack + drop-in semantics had no integration coverage.
What this exercises
The fips.nft baseline polices ONLY the fips0 mesh interface and
implements default-deny inbound. This suite asserts the four behaviors
documented in the file's header are actually true on a live mesh:
- (a) Unallowed inbound on fips0 is dropped
- (b) Outbound-initiated flows get their reply via the
ct state established,related acceptrule - (c) ICMPv6 echo-request is accepted (ping6 reachability)
- (d) A drop-in
.nftfile under/etc/fips/fips.d/adds an allowlisted port and that port is accepted
A drop-counter check after case (a) confirms the connection was actively DROP'd by the fips chain (not silently unrouted).
Topology
Two FIPS nodes peered over UDP on a Docker bridge network:
| Container | Hostname | Firewall |
|---|---|---|
fips-fw-container-a |
host-a |
none (probe) |
fips-fw-container-b |
host-b |
fips.nft + drop-in |
The bridge network requests no subnet, so docker assigns one from its own address pool and two concurrent runs never contend for a fixed range. No node's IPv4 address is therefore known before startup, and the generated peer stanzas address each other by docker hostname, resolved through the container's dnsmasq to docker's embedded DNS. The firewall assertions themselves are unaffected: they run over the fips0 overlay, whose addresses are derived from the node npubs.
node-b mounts the production packaging/common/fips.nft read-only at
/etc/fips/fips.nft, plus a drop-in at /etc/fips/fips.d/services.nft
containing tcp dport 22 accept. node-a is unfirewalled and serves
as the probe origin.
Both containers run the unified test image's default mode, which
starts dnsmasq + sshd (port 22) + iperf3 + python http.server on
port 8000 + the FIPS daemon.
fips-firewall.service activation
The production unit's ExecStart is:
ExecStart=/usr/sbin/nft -f /etc/fips/fips.nft
The unified test image does not run systemd, so test.sh invokes the
same nft -f command directly inside node-b after fips0 is up and
peering has converged. The deb-install harness covers the systemd
unit-enablement path under real systemd separately.
Run
Build the Linux binaries and test image:
./testing/scripts/build.sh --no-docker
Run the suite:
./testing/firewall/test.sh
test.sh regenerates fixtures automatically before starting Docker.
Use --skip-build to reuse the existing release binaries and the
existing test image: the suite then neither builds nor pulls the image
named by FIPS_TEST_IMAGE (default fips-test:latest), so that image
must already exist. Use --keep-up to leave the containers running for
inspection.
Expected output shape
=== Generating firewall fixtures
=== Starting firewall harness
=== Waiting for fips0 on both nodes
=== Waiting for peer convergence
=== Resolving fips0 addresses
node-a: fd97:...
node-b: fd97:...
=== Activating fips-firewall on fips-fw-container-b
PASS: fips-fw-container-b: fips.nft baseline + drop-in loaded
=== Case (c): ICMPv6 echo-request to firewalled node
PASS: (c) ICMPv6 ping node-a → node-b accepted
=== Case (a): unallowed inbound TCP/8000 from node-a → node-b
PASS: (a) inbound TCP/8000 dropped (curl rc=28, timed out as expected)
=== Case (b): node-b initiates outbound TCP, expects reply via conntrack
PASS: (b) outbound from node-b got HTTP 200 via conntrack reply path
=== Case (d): drop-in allowlisted TCP/22 from node-a → node-b
PASS: (d) drop-in allowlisted TCP/22 reachable
=== Drop counter incremented (case a should have ticked it)
PASS: drop counter = N (case a was actually dropped, not just unrouted)
=== Firewall integration test passed
Inspect the loaded ruleset
docker exec fips-fw-container-b nft list table inet fips
Stop and clean up
docker compose -f testing/firewall/docker-compose.yml down
Generated fixture location
testing/firewall/generated-configs/ (gitignored), or
generated-configs<suffix>/ when FIPS_CI_NAME_SUFFIX is set, which is how
concurrent runs keep their fixtures apart.