Description
coverage.json’s exercise text for the ipsec entries says ‘One site-to-site IPsec tunnel between the two testbed OPNsense boxes across the isolated bridge’. That is FALSE and has sent at least one investigation down the wrong path. swanctl on guest 102 shows the real topology: local ‘devbox’ @ 172.16.9.1 to remote ‘ctclient’ @ 172.16.9.100 - the traffgen CONTAINER dialling the nightly firewall as a road-warrior client. Guest 106 runs strongswan with no SAs at all and has never had any.
Consequences: ipsecPhase1 rows[].install-time, ipsecSad rows[].satype, ipsecSad rows[].spi and ipsecSpd rows[].dir are unobtainable on the release profile by construction, not because a client VM was retired. Any note blaming the release box’s empty ipsec tables on missing clients is wrong about the cause.
Two things to decide, and they are separable:
- Fix the ledger text so it describes the tunnel that exists. Cheap, and stops the next reader repeating the hunt.
- Decide whether the release box should have a tunnel at all. Giving it one means a second connection profile on 105 targeting 172.16.9.2 plus a matching tunnel and PSK on 106. That is the only route to ipsec coverage on the release profile, and it is VPN configuration rather than lab plumbing.
Note the nightly tunnel is established by the container, so it comes back when 105 restarts - which is why these paths appear to flap between runs for no reason visible in the report.
Definition of Done
- #1 just check
- #2 just gen (if any generated artifact changed) and the diff committed
Implementation Notes
Part 1 done: the nine ipsec exercise texts in coverage.json now describe the real road-warrior tunnel (traffgen container -> devel firewall) and state that the release profile is unobtainable by construction. Part 2 (give the release box its own tunnel) remains an open decision for Rob.
2026-10-13 Rob decided to retain development-only IPsec coverage and explicitly accept the stable-release profile gap. The corrected ledger already describes the real traffic-generator-to-development-firewall tunnel. No second tunnel, PSK or VPN configuration is authorized or needed.
Final Summary
Owner decision settled: retain development-only IPsec coverage; stable profile intentionally has no tunnel and remains explicitly unverified for populated IPsec rows. Existing ledger correction retained. No runtime change or new test needed for this decision-only closeout.