/hub/runs/protectli-firewall-detection-block-rollback
Published resultTest date: 2026-10-05Measured on: Protectli V1610

Protectli V1610: Detection, Inline Block and Rollback

I followed a harmless request from my Windows client into Suricata, changed only its test signature to drop, and then restored it to alert. HTTPS and DNS controls checked that ordinary traffic still worked while the selected request was blocked.

This page keeps the shared controls, retained measurements, failures, and comparison limits together. The linked files are there when you need the underlying table or method.

What you can compare here

This is a physical client-to-Vault check with exact connection evidence. The test signature verifies this inspection path; it is not a detection-rate study or inspection of decrypted HTTPS payloads.

Related pages

You can reuse Trevor-measured data from this page under the repository MIT terms. Retain the required notices when reusing the project documentation, and credit Trevor Unland when citing this run. Project media has separate terms in the repository.

Recorded results

Open the details under any row for the specific setup, outcome, artifact identity, and supporting file.

Harmless fixture detected

Physical path · alert-only

Published result

Measured on Protectli V1610 · Owned Vault test

Response body
39 bytes
Exact returned fixture body, matched to the source record.

HTTP 200 returned the exact 39-byte UID body, and the original EVE record identified SID 2100498 with action allowed for the matching connection.

Setup and original evidence

Protectli V1610 · OPNsense 26.7.5 / Suricata 8.0.7_1 · Owned Vault test · Physical path · alert-only

Selected request blocked

Physical path · inline Netmap drop

Published result

Measured on Protectli V1610 · Owned Vault test

Response body
0 bytes
No fixture response body received.
Client timeout
10 seconds
Bounded curl request; the timeout alone is not the blocking oracle.

curl timed out after ten seconds without a response body, while the exact corresponding EVE connection was recorded as blocked. Both observations are required for this result.

Setup and original evidence

Protectli V1610 · OPNsense 26.7.5 / Suricata 8.0.7_1 · Owned Vault test · Physical path · inline Netmap drop

Ordinary traffic during the block

Physical path · HTTPS and DNS controls

Published result

Measured on Protectli V1610 · Owned Vault test

Benign control types passed
2 of 2
HTTPS and direct Vault DNS; not two independent attack cases. (control types)

Certificate-validated HTTPS and a DNS lookup through the Vault both passed while the selected fixture rule was active.

Setup and original evidence

Protectli V1610 · OPNsense 26.7.5 / Suricata 8.0.7_1 · Owned Vault test · Physical path · HTTPS and DNS controls

Response restored after rollback

Physical path · test rule returned to alert

Published result

Measured on Protectli V1610 · Owned Vault test

Restored response body
39 bytes
Same harmless fixture after the selected action was reverted.

The repeated UID request returned HTTP 200 and 39 bytes, with an exact allowed EVE match and the generated signature action back at alert.

Setup and original evidence

Protectli V1610 · OPNsense 26.7.5 / Suricata 8.0.7_1 · Owned Vault test · Physical path · test rule returned to alert

Installed rules and retained policy

Final installed snapshot

Published result

Measured on Protectli V1610 · Owned Vault test

Enabled categories
10 categories
Selected installed snapshot.
Active rules
37125 rules
Native validation exit 0.
Alert rules
37121 rules
Final generated actions.
Drop rules
4 rules
Selected Critical TLS C2 rules; UID restored to alert.

Native validation exited successfully with dependency-complete selected rules. The final snapshot held 37,125 active rules: 37,121 alerts and four drops across ten enabled categories. Feed updates can change these counts.

Setup and original evidence

Protectli V1610 · OPNsense 26.7.5 / Suricata 8.0.7_1 · Owned Vault test · Final installed snapshot

Management and recovery configuration

Recorded appliance configuration

Published result

Measured on Protectli V1610 · Owned Vault test

Matched configuration export
38989 bytes
Original device/local SHA256 comparison.
Retained boot environments
5 environments
Same SSD, separate from the off-device XML.

Listener, rule and console checks confirmed LAN-only HTTPS management, disabled SSH and password-protected console access. The off-device XML matched its device-side SHA256; five boot environments were retained on the SSD. The XML stays private because it contains secrets, and same-disk boot environments do not replace it.

Setup and original evidence

Protectli V1610 · OPNsense 26.7.5 / Suricata 8.0.7_1 · Owned Vault test · Recorded appliance configuration

Supporting evidence

Results and method

These are the few files that support this page directly. The repository holds the wider project history.

Controls

  • One owned Ethernet client, explicitly bound to its Vault-facing source address; upstream Wi-Fi is outside this path.
  • Final platform: OPNsense 26.7.5, FreeBSD 15.1-RELEASE-p3 and Suricata 8.0.7_1.
  • The harmless HTTP UID fixture, its client port and timestamps were matched to the original EVE event and forwarded receipt.
  • Inline Netmap mode and disabled offloads were verified before the selected test rule was changed to drop.
  • Certificate-validated HTTPS and DNS through the Vault were retained as benign controls; the physical console remained available.

What this run established

  • $The alert-only request returned HTTP 200 and the exact 39-byte body, with SID 2100498 recorded as allowed.
  • $The selected inline block withheld the response and produced a blocked EVE record for the same connection. Restoring alert mode restored the response.
  • $The final retained policy keeps four selected Critical TLS C2 drops. The UID fixture was restored to alert.
  • $The alternative quickstart endpoint failed DNS in this run; that attempt remains recorded separately.
  • $HostWatch was restricted to the owned LAN and Netmap used eight workers. The tested client had no global IPv6 address or IPv6 default route, so this record establishes the owned IPv4 path.

Get an email when I publish new hardware reviews, benchmarks, and security research. Unsubscribe anytime.

Email goes to Buttondown. Privacy details.

© 2026 Trevor Unland. All rights reserved.

PrivacyTermsRSS Feed

$ echo "Built with React + TypeScript"