Allowed sites

Allowed sites are domains the computers of a room can still reach while the room's internet is off: for example classroom.google.com during a test, or the school's own e-learning site. There are:

• All rooms: one list per firewall, allowed in every room of that firewall;
• a list per room (optional), allowed only for room SB1-102.

A room with its internet off reaches the domains of the list for all rooms plus its own list, and nothing else: there is no built-in exception, not even for Entrosity (Entrosity Axis agents). A room with its internet on is not affected.

What a list can hold:

• Domains only: a name like example.com, or a wildcard like *.example.com for all its subdomains. Not IP addresses, not paths (example.com/tests allows the whole of example.com), no ports.
• The FortiGate allows the domain's addresses; it does not look inside the encrypted traffic (no SSL inspection), so a whole site is allowed or not, never a single page of it.
• At most 200 domains per list.

Each list is an address group on the FortiGate with an ACCEPT policy that the FortiGate's administrator sets up once (Setting up the FortiGate → Allowed sites). Matrix never creates or changes policies: it only changes the members of these groups.

Who can edit

Role	Can
Tenant admin	Edit every list, and see the FortiGate setup commands.
Teacher	Edit the lists of the rooms granted to them (Room rights). The list for all rooms: View only · only administrators change the list for all rooms. Other rooms' lists are not shown to them.
Viewer	See every list (View only).

Editing also needs the firewall's Allow editing allowed sites (off by default, Firewalls → Allowed sites), the connector's guard to allow site writes, a connector that supports allowed sites, current data and a list that is set up on the FortiGate (Banners).

The page

• Firewall chooses the firewall when the tenant has several. Refresh loads the lists again as the connector last reported them; under the title the firewall shows Connection active and Updated …, or Data not current — editing is blocked.
• All rooms (Allowed in every room of this firewall) comes first, then Room lists, with Search by room and Building.
• Each list shows its address group on the FortiGate, its number of domains, its setup status and its domains.
• The connector reports the lists every 5 minutes, when the firewall is refreshed (Firewalls → Check) and after each change; the page updates live when a report arrives.

Add and remove domains

1. In the list, type the domain into Add a domain or paste a link (for example classroom.google.com or *.google.com) and choose Add. You can paste a whole link such as https://classroom.google.com/c/123?cjc=x: the page shows Will be saved as classroom.google.com and keeps only the host name. International names are saved in their xn-- (punycode) form, and everything is saved in lower case.
2. To remove a domain choose Remove (Undo keeps it).
3. The list marks the domains new and removed and shows Unsaved: 1 added, 0 removed. Choose Save (or Discard).

Refused while typing: IP addresses cannot be added: enter a domain name., Not a valid domain. Use a name like example.com or *.example.com., … is already in the list. and A list holds at most 200 domains.

Entries that Matrix did not create (members an administrator added to the group on the FortiGate) are shown with Not managed by Matrix and a reason such as Not created by Matrix; change it on the FortiGate. They cannot be removed here, and Matrix never removes them.

When a list has a wildcard domain the page reminds: Wildcard domains (*.example.com) work only when the FortiGate sees the computers' DNS queries: the FortiGate is their DNS server, or their DNS traffic passes through it.

Saving and results

Save sends the complete list you see, together with the version of the list you loaded. Matrix records the change in the History and sends it to the connector, which:

1. reads the group, its policy and its members again, and refuses when the list changed since you loaded it (The list changed since you loaded it. Refresh, check the domains and save again.);
2. asks Matrix whether the change is still allowed (your role or room right, the switches), right before each write;
3. creates an address object for each new domain (matrix-site:<domain>), sets the group's members, deletes its own objects that no group or policy uses any more, and reads the group back.

Message	Meaning
The change was sent to the firewall…	Running (Saving…).
The allowed sites are saved and confirmed.	Done.
The change is not confirmed. Use "Check / retry": …	Unconfirmed: a write was sent, but its confirmation did not arrive.
The change was refused. + reason	Nothing was written (Troubleshooting).
The change failed. + reason	Nothing was written: the firewall is unreachable, … (Troubleshooting).

Check / retry after an unconfirmed change reads the list again and shows your change on top of it: The list already contains your change., or the domains still missing so you can Save again. The list also shows The last change of this list is not confirmed (…) until someone checks it. Nothing is ever retried automatically.

One change of a list runs at a time (Another change of this list is in progress…). Each save counts against the change limits, like a room switch (Rooms → Limits).

Setup status

Status	Meaning
Set up	The group exists and an enabled ACCEPT policy with the firewall's direction lets it through for the room(s).
Not set up	The address group "Matrix allowed sites SB1-102" does not exist on the FortiGate yet.
No policy	The group exists, but no ACCEPT policy uses the address group … yet.
Policy disabled	The policy "…" (ID N) is disabled.
Policy does not cover the room	The policy "…" (ID N) does not have the room's address group(s) as its source. For the list for all rooms: not every room.
Not reported yet	The connector has not reported this list yet (it does not support allowed sites, or has not sent its next report).

A list without its group or policy cannot be edited (Set this list up on the FortiGate before adding domains.). A list that is not Set up has no effect on the FortiGate even when it holds domains.

A group that Matrix may not change (used as a source address or inside another group, or with nested groups) is shown Read only: with the reason.

FortiGate setup

FortiGate setup (tenant admins; also Show setup commands on a list that is not set up) opens the setup dialog:

1. Under Also set up the lists of these rooms, tick the rooms that should get their own list (All, None). The list for all rooms is always included when it is missing.
2. Choose Show commands. The FortiGate CLI creates only what is missing: the address groups (empty, member none) and the ACCEPT policies, with this firewall's interfaces and the rooms' address groups. Sets up: names the lists, and Check on the FortiGate lists what the commands cannot fix (a disabled policy, a room without a known address group, …).
3. Copy the commands and give them to the FortiGate's administrator, who pastes them once into the FortiGate CLI (read the # comment lines first: VDOM, policy order, NAT).
4. Refresh the page: the connector reports the new groups within a few minutes, and the lists become Set up.

The commands and what to check: Setting up the FortiGate → Allowed sites.

Banners

Banner	What to do
The connector of this firewall does not support allowed sites yet. Update the connector to see and edit the lists.	Update the connector (Connectors → Updates).
Editing allowed sites is switched off for this firewall.	A tenant admin turns on Allow editing allowed sites in the firewall's settings (Firewall settings).
The connector has not accepted this firewall yet … / The configuration differs from what the connector accepted … (tenant admins)	On the connector computer, as an administrator: matrix-connector guard accept <id> and matrix-connector guard set <id> --site-writes on (Connectors → The local guard).

Site writes are off in the connector's guard until matrix-connector guard set <firewall id> --site-writes on is run on the connector computer; until then every save is refused with writes_disabled, and the result reminds tenant admins of the command.

Entrosity Axis agents while the internet is off

Matrix has no built-in exception for Entrosity's own servers: while a room's internet is off, its computers reach only the domains of the lists above. The Entrosity Axis agent on them loses its connection, so the computers show as offline in Axis, and remote support, scripts and deployments wait until the room's internet is on again.

A tenant admin can keep Axis reachable by adding the domains it needs to a list, but we advise against it: the Hub (hub.entrosity.com) and Axis management (manage.entrosity.com) are behind Cloudflare. The FortiGate allows the addresses a domain resolves to, and Cloudflare's addresses are shared by many other sites, so allowing these domains opens every site on those addresses to the room. Turn the room's internet on while its computers need Axis instead.

Earlier versions kept a locked Entrosity services list (Matrix Entrosity services) on this page; it was removed. To remove its group from the FortiGate, see Troubleshooting → Removing the old Entrosity services group.

On the rooms page

Each room card on Rooms shows a small chip 3 allowed sites: the domains of the list for all rooms plus the room's own list (the tooltip splits them: This room: 1 · all rooms: 2). It opens this page at the room's list.

History

Every save, including refused ones, is recorded as Allowed sites (sites), with the list (All rooms (shared list) or the room), the group, the number of domains before and after (2 domains → 3 domains) and Added: / Removed: domains (History). Changes of the former Entrosity services group, from before it was removed, are still listed as Entrosity services (removed).