Entrosity Matrix
Entrosity Matrix switches the internet access of computer rooms on and off from the browser. Each room is a policy on the school's FortiGate firewall; Matrix enables or disables that policy for teachers and administrators, can switch it back on at a set time ("disable until…"), keeps the computers of each room in the room's address group, and records every change and refusal in a history.
Matrix runs at https://hub.entrosity.com/matrix. You sign in on
Entrosity Hub, like for every Entrosity product, and
open Entrosity Matrix from the Hub's product launcher. It replaces the
single-school panel it grew out of
(Moving from the old panel).
Matrix is currently open to platform admins only: organizations and their users do not see it yet. A platform admin releases it to organizations under Products in beta.
Matrix shows whether a room's policy is enabled or disabled. If an enabled ACCEPT policy further down the FortiGate's policy list also matches the room's computers (for example a general Internet Access for Students policy for the whole student network), their traffic falls through to it and still reaches the internet when the room's policy is disabled. The firewall's check lists such policies as warnings; removing them is a change on the FortiGate, not something Matrix does. See What switching a room off means.
What it does
| Area | What you get |
|---|---|
| Rooms | Every room of every firewall as a card, grouped by building, with its state (The rule is enabled / The rule is disabled). Enable or disable a room after a confirmation; see at once whether the firewall confirmed it. |
| Disable until… | Disable a room and have it switched back on automatically: in 45 minutes, at the end of the school day (17:00) or at a chosen time (5 minutes to 7 days ahead). |
| Bulk changes | Select several rooms, or a whole building, and enable or disable them in one go. |
| Addresses and groups | The computers (/32 address objects) of each room's address group: search by name or IP, change a computer's IP, add a computer to a room. |
| Allowed sites | Domains a room can still reach while its internet is off (for example classroom.google.com): a list for all rooms and each room's own list, edited by tenant admins and, for their rooms, by teachers. Nothing else is reachable: there is no built-in exception for Entrosity. |
| History | Every change, refusal and result, with the steps of each change, filtered by date, user, room and action. |
| Room rights | Which rooms each teacher may switch. |
| Several firewalls | One tenant can have many firewalls on many sites, each reached through a connector. |
Matrix does not create, delete, rename or otherwise edit policies, does not touch policies that are not rooms, does not create or delete address groups, deletes no address objects except its own unused allowed-sites objects, and does not change DHCP, DNS or the computers themselves.
How it reaches the firewall
The FortiGate's management interface is on the school's network and is not reachable from the Internet. A Matrix connector, a Windows service on a computer of the administration network, connects out to Matrix and talks to the FortiGate's REST API on the LAN.
- The Matrix web app (
/matrix) is where teachers and administrators switch rooms. It updates live. - The Matrix backend keeps the firewalls' configuration, the rooms and groups the connectors report, the room rights and the history, and decides which changes may be sent.
- The connector reads each firewall every 30 seconds (by default) and reports its rooms; it carries out changes, and before every write it checks the policy again, asks the backend whether the change is still allowed, and confirms the result by reading it back.
- The local guard on the connector computer is what a local administrator accepted for each firewall. Without it the connector writes nothing (Connectors → The local guard).
The FortiGate's API token is stored encrypted in Matrix and sent only to the connector that reaches that firewall; it never appears in the app, the history or the audit log.
Safety layers
A change reaches the firewall only when all of these agree:
- Your right: you are a tenant admin, or a teacher with a room right for that room.
- Fresh state: the firewall's last report is recent and its connector is online; otherwise changes are blocked.
- Server switches: the firewall allows changes (Allow turning room policies on and off, Allow changing and adding computers, Allow editing allowed sites; all off by default).
- Local guard: a local administrator of the connector computer accepted this firewall's configuration, and this kind of write.
- Checks on the firewall: the policy still has a room name matching the firewall's pattern, the exact configured direction, the right VDOM, and is still the same room.
- Write-time authorization: right before the write the connector asks Matrix; the change is still live and you still hold the right (a right taken away a second ago stops it).
- Confirmation: after the write the connector reads the policy (or object) again. A write that was sent but not confirmed is shown as Unconfirmed and never repeated automatically.
What switching a room off means
Disabling a room's policy stops new traffic that this policy would have allowed. Whether the room's computers are then really offline depends on the rest of the firewall:
- Later ACCEPT policies. FortiGate evaluates policies top to bottom.
A disabled room policy is skipped, and the traffic is matched by the
next policy that fits. If an enabled ACCEPT policy further down (same
direction, source addresses that include the room's computers, or
all) exists, the computers keep the internet. The administrator must take the managed addresses out of such general policies, or add a suitable blocking policy after the rooms, on the FortiGate. The check warns about such policies (later_accept_policy: …). - Established sessions. With
firewall-session-dirtyset tocheck-all(globally or on the room policies), FortiGate re-evaluates established sessions after a policy change; this does not guarantee that they are cut, especially when a later ACCEPT policy matches. Matrix does not clear sessions. - Other ways out. IPv6, other policies, other interfaces, and students changing their computer's IP address are outside what an IPv4 policy switch controls.
Test with new and established connections in a room the administrator designates for testing before relying on it in lessons.
What a site needs
- A FortiGate with the REST API, room policies whose names follow one
pattern (for example
Internet Access for SB1-102) and one fixed direction (for example zoneStudents→ SD-WAN zoneINTERNET). - A REST API administrator on the FortiGate with a minimal access profile and the connector computer as its only trusted host (Setting up the FortiGate).
- An always-on Windows computer on the administration network for the
connector, that reaches the FortiGate's HTTPS management port, with
outbound TCP 443 to
hub.entrosity.com. Nothing inbound. Student networks must reach neither the connector computer nor the FortiGate's management port.
Concepts
Tenants and sites
A tenant is a customer organization: an organization on Entrosity Hub with Entrosity Matrix enabled, with the same ID. A site is a location of the tenant; firewalls and connectors can belong to one.
Firewalls
A firewall is one FortiGate (one VDOM of it) reached through one connector: its address and port, VDOM, the room direction (source and destination interface or zone), the policy name pattern that says which policies are rooms, and its API token (Firewalls). A tenant can have several.
Rooms
A room is a FortiGate IPv4 policy that:
- has a name that fully matches the firewall's policy name pattern, whose
(?P<room>…)group gives the room's code (SB1-102); - goes exactly from the configured source to the configured destination interface (no other interfaces);
- is in the configured VDOM.
The room's building comes from the pattern's (?P<building>…) group,
or from the room code before the first - (SB1). New room policies
appear after the next report without restarting anything; the policy's
real ID on the FortiGate is used, whatever the room's number. A policy
that is no longer on the firewall stays listed as No longer on the
firewall until it is cleaned up.
Address groups and computers
Each room policy's source (srcaddr) names one or more address
groups; their members are the room's computers, /32 IPv4 address
objects such as pc-102-01.coding.local
(Addresses and groups).
Changes and results
Every change is recorded before it is sent, with its result:
| Result | Meaning |
|---|---|
| Pending | Sent; the connector has not answered yet. |
| Success | Written and confirmed by reading it back (or already in the desired state: nothing needed writing). |
| Unconfirmed | Sent to the firewall but not confirmed (the connection broke, the connector restarted, the job expired after the connector took it). Refresh and check before trying again. |
| Refused | Refused before anything was written: rights, the guard, the switches, a changed policy, the rate limit. |
| Error | Failed before anything was written: the firewall is unreachable, refused the token, has another FortiOS version, … |
| Cancelled | An automatic re-enable that was cancelled. |
Signing in
- Sign in on Entrosity Hub (
https://hub.entrosity.com). - Open Entrosity Matrix for your organization. You need a role in Matrix: Tenant admin, Teacher or Viewer (Roles and permissions). Organization admins give roles on the Hub (Organization members).
- If you belong to several tenants, choose one; Switch tenant in the sidebar changes it.
The app is in English and Bulgarian; the language button in the header switches between them (the choice is shared with the Hub and the other products in this browser).
Finding your way around
| Sidebar item | What it is | Page |
|---|---|---|
| Rooms | Rooms by building; enable, disable, disable until…, bulk changes | Rooms |
| Addresses and groups | The computers of each room | Addresses and groups |
| Allowed sites | Domains reachable while a room's internet is off | Allowed sites |
| History | Changes, refusals and results | History |
| Schedules | Upcoming and failed automatic re-enables | Schedules |
| Firewalls | FortiGates, their token, check and switches (tenant admins) | Firewalls |
| Room rights | Which rooms each teacher may switch (tenant admins) | Room rights |
| Connectors | Connectors and enrollment tokens (tenant admins) | Connectors |
| Tenant settings, Sites, Audit log | Retention, time zone, locations, who changed the setup (tenant admins) |
Global admins also get an Administration area: an Overview of all tenants, Connector releases and a global Audit log.
In this section
- Getting started: from an empty tenant to the first room switched.
- Rooms, Schedules, Addresses and groups, Allowed sites, History: day-to-day work.
- Firewalls, Setting up the FortiGate, Connectors, Room rights, Roles and permissions: the setup.
- Troubleshooting.
- Trying Matrix with the simulator: a trial without a FortiGate.
- Moving from the old panel: the pilot
school's move from
network.coding.local.
For teachers of the server: Running Entrosity Matrix. For integrators: Matrix API, Matrix connector protocol and Matrix connector.