Network Flow Matrix
Define the flows authorised between your network zones, see them as a source-to-destination matrix and check them against segmentation policy.
Everything is computed and stored only in this browser — nothing is sent to a server. Your matrix is saved automatically in this browser and restored when you come back; use Import / Export to move it between machines, and Clear saved data to wipe it.
| Name | Type | CIDRs | Tags | Description | Actions |
|---|
No zones yet. Add a zone, or load the sample dataset from Import / Export.
| Source | Destination | Dir | Proto | Ports | Action | Status | Tags | Description | Actions |
|---|
No flows match. Define zones first, then add flows (one by one or with Batch add).
Add flow
Batch add flows
Rows are source zones, columns destination zones. Each cell shows how many flows exist for that pair; select a cell to list them. allow deny both = allows an insecure port or any port
Define at least 2 zones and 1 flow to build the matrix.
Flows
| Severity | Flow | Check | Message |
|---|
Validation runs each time you open this tab.
Import
JSON (full configuration)
Zones, port profiles and flows from a file exported here. Replaces the current data.
Zones CSV
Columns: name (required), type, cidrs, tags, description, id. Separate list values with ;.
Flows CSV
Columns: source_zone and dest_zone (zone names, required), direction, protocol, ports, action, tags, status, description. Import zones first.
Sample dataset
A 3-tier architecture with Internet, DMZ, app, database, intranet, management and PCI zones, including a few deliberate policy violations.
Export
JSON (full configuration)
All zones, port profiles and flows in one file you can import again later.
CSV (separate files)
zones.csv and flows.csv, e.g. for a firewall change request or a spreadsheet review.
Saved data (this browser)
Your matrix is saved in this browser only. Clearing it removes all zones and flows here and the saved copy — it cannot be undone. Export first if you want to keep it.
How it works
Each zone gets a trust level from its type: External < DMZ < Other < Environment < Intranet < Management. Validation checks every flow (both directions for two-way flows) against these rules:
- cleartext_allow (error / warning): a cleartext service — FTP, Telnet, TFTP, HTTP, POP3, IMAP, SMTP, SNMP v1/v2c, LDAP, the r-services, VNC — allowed across a trust boundary (the two zones have different trust levels), so the traffic is exposed. The message names the encrypted replacement (e.g. Telnet→SSH, HTTP→HTTPS, LDAP→LDAPS). Port→service mapping follows the IANA registry; the “use TLS/SSH instead” advice follows NIST SP 800-52r2 / 800-123 and the CIS Benchmarks.
- exposed_service (error / warning): a database, cache or SMB service (MS-SQL, MySQL, PostgreSQL, Redis, MongoDB, Oracle, SMB…) reachable across a boundary that touches an untrusted zone (External or DMZ). Same-trust and intra-zone flows are left alone.
- unmapped_zone (error): the flow points to a zone that no longer exists.
- overly_broad (warning): an allow rule on any port, or on any protocol and any port.
- cross_zone (warning): an allow rule into a Management zone from any other zone. Management networks should only receive what they strictly need.
- duplicate (info): another flow has the same zones, protocol, ports and action.
The matrix is a review aid for segmentation (for example PCI DSS scoping or a DORA/NIS2 network review), not a firewall configuration. To check an actual ruleset, paste it into the Firewall Rule Analyzer.