The TestPulse Virtual Lab
No RADIUS server? Build the one we develop against.
TestPulse Pro points at a real AAA server — it does not simulate one. If you have nothing to point it at, the lab this product was built against is yours to stand up: real 802.1X, RADIUS, TACACS+, DHCP and directory traffic on a single Kubernetes host, with real EAPOL frames on the wire. We do not host it and we do not run it for you. The build and its operating guide ship with the download.
What's actually in it
Sixteen workloads across two planes.
Knowing which plane is which will save you most of the confusion available here. The entire AAA path lives in the container plane, and the traffic is genuinely real — a real wpa_supplicant produces real EAPOL frames on the lab bridge, and real DHCP DORA follows. Roughly 28 EAPOL and 4 DHCP frames per method. Nothing is simulated.
Container plane · 13 workloads
The whole AAA path
Every authentication, authorization and accounting path TestPulse diagnoses runs here, on Linux bridges internal to the appliance. These networks never touch your LAN, so they cannot collide with it.
freeradiustac_plusopenldapdns
isc-dhcpkea-ddihostapd-nashostapd-mab
mock-nacsupplicantalpine-supplicant
ostinatopassthru-syslog
KubeVirt VM plane · 3 machines
The switch evidence path
One RouterOS switch and two Linux supplicants. Adds the switch evidence path. Needs hardware virtualization passed through to the appliance. There is no Windows endpoint.
mikrotik-chr
endpoint-alpine-1endpoint-alpine-2
CHR is fetched from MikroTik at first boot rather than redistributed. A failed or skipped fetch costs the switch evidence path and nothing else — it is never fatal.
The one thing worth memorising: if the VM plane will not start, 802.1X still works. The AAA path is entirely in the container plane, and the NAS is a container — it is always there. You have lost the switch evidence path, not the product.
Operating it
You should not need to administer Kubernetes.
The lab is a single-node Kubernetes cluster, and you are not expected to operate it. Every cluster action is performed by an AI administrator that ships with the lab, and you talk to it in plain language:
"the lab looks broken" · "no packets were captured"
"RADIUS keeps rejecting" · "is the lab healthy?"
If you find yourself typing kubectl to make the product work, that is a defect.
Not a limitation you should work around, and not something to learn your way past — a defect in the appliance, and we want the report. The administrator encodes fourteen recorded infrastructure failure modes with their tells, which is what makes an unattended lab viable at all. It cannot cover the ones nobody has hit yet. Those are the ones worth telling us about.
The most important skill
Telling a broken lab apart from a real finding.
TestPulse is a diagnostic tool, so a sick lab and a genuine diagnosis can look alike. Getting this wrong is the fastest route to a wrong conclusion about the product — in either direction. This table is in the operating guide; it is here because you should be able to read it before you download anything.
RADIUS rejects testuser
EAP-TLS still passes while PEAP, TTLS and PAP fail. Certificate auth skips the users file, so this is the users database, not RADIUS.
All methods fail together, with a cause family and evidence behind it.
Directory lookups fail
The LDAP pod is Running but the directory is empty — it restarted and lost its data.
The directory answers, and answers wrongly or slowly.
"Transport fault" on a healthy run
No pcap was captured. The sub-agent is reporting its own blindness.
Packets were captured and show loss, jitter or retransmits.
Everything fails at once
The node ran out of disk and evicted the lab. AAA faults are selective; eviction is total.
It isn't.
A suite "passed" with nothing run
"No tests collected" is a failure, not a pass.
A suite ran and reported results.
Or just ask the administrator directly — "is this a lab problem or a real finding?" — which it is instructed to answer plainly, and never to present a lab fault as a product result.
Health checks
Three checks, three different questions.
Ask for these by name. A green answer from one says nothing about the others.
lab check
Is the lab ready at all? Disk pressure, the core AAA pods, the CoA listener on 3799, supplicant tooling, and the lab certificate authority.
vlab check
Are components up and reachable? API, viewer, every pod, RADIUS on 1812 and 3799, and the NAS bound to the 802.1X network.
pcap check
Can every device be captured? Proves wire evidence will actually land, for all thirteen workloads and the VMs.
Why the third one matters more than it sounds.
A test that runs with no capture does not fail. It produces a confident diagnosis from absent evidence — which is worse than an error, because it looks like a result. Run the pcap check before you trust a run.
Before you build it
Under-sizing doesn't fail cleanly. It produces false findings.
This is the one requirement not to negotiate with. Below 6 vCPU, 32 GB RAM and 200 GB of disk, the two planes contend for resources, and the symptom is inflated latency that reads as a transport fault in a diagnosis. We measured it on an undersized host: load between 7.6 and 15.4 on four cores. A tester below the floor will file false diagnoses as product bugs, which is the worst possible feedback — indistinguishable from a real defect until somebody spends a day on it.
First boot refuses to continue if hardware virtualization is missing or the host is below the floor, and says which. That check exists because of the paragraph above, not in spite of it.
What you should know before committing a machine to this
It needs a host of its own. Six cores and 32 GB is not a share of your laptop. Hardware virtualization must be passed through; without /dev/kvm the VM plane will not start, and first boot will tell you so rather than half-working.
The lab ships with working test credentials, and they are the same on every copy. That is deliberate. A RADIUS shared secret and a test user password are not leaked keys — they are the lab, and 802.1X cannot be exercised without them. They live on bridges inside the appliance that never reach your network, and they are documented in the tester guide because you need them to point a supplicant at the lab or read a capture by hand. One credential is generated per appliance and shown once: the remote-desktop password, because that is the single port exposed to your network.
It is a beta. No billing, no SLA, and support is one person reading email. The lab has fourteen recorded infrastructure failure modes; the administrator knows those. It does not know the fifteenth.
Coming next
SIEM / Splunk export, mapped to NIST, OWASP and PCI-DSS controls.
Internal testers exercising their own AAA stack usually need the lab's evidence in the same place their compliance and security teams already look. A follow-on update ships one-way exports from every lab run's evidence bundle to Splunk HTTP Event Collector and generic SIEM syslog, with per-diagnosis tags that map onto NIST SP 800-53 AC/IA/AU, OWASP ASVS V2 (authentication) and PCI-DSS Requirement 8 (identify and authenticate access) — so a red diagnosis is filed as an evidence-backed control failure, not another CSV.
Not in this build. The export path is intentionally held back until the control mapping has been reviewed by someone whose job title includes the word "compliance". Ask for early access on the company page.
Get the lab with the download.
The build, the six stages, the three health checks and the operating guide arrive with the Pro wheel. A download that works offline should not send you online to learn how to use it.