Network Firewall

Network Firewall lets you control which networks can reach Edlink. The same sections appear on each firewall page; each policy only applies to that kind of traffic. The dashboard asks you to confirm before a change is saved, because it takes effect immediately on production traffic.

Tightening dashboard access does not change your application's API policy, and the reverse is also true.

The Global Firewall page uses the same sections for platform-wide evaluation. On that page, Block VPN Traffic, Block Tor Traffic, Block All Traffic from Unknown IP Addresses, and Geographic Filter Mode are disabled. Evaluation mode, known IP addresses, and blocked IP addresses stay available. Known IPs there are recorded for evaluation context; that page does not support allowlist mode or geographic allowlists.

For why this exists, see Securing Your Integrations.

Evaluation mode

Evaluation Mode decides whether the rules on this policy are ignored, reported, or enforced. The select is Disabled, Monitoring, or Enforcing.

• Disabled. Edlink does not evaluate traffic against this policy. The rules stay saved and are skipped.
• Monitoring. Edlink evaluates traffic against the policy and does not deny the request. When the policy would have blocked it, the API response includes a warning: “Origin policy evaluation failed and this traffic will be blocked when the policy is enforced.”
• Enforcing. Edlink denies requests that this policy would block. The response is HTTP 403 with the message “Access from this origin is not permitted.”

Monitoring and Enforcing use the same rules. Only Enforcing rejects the request. A policy in Disabled does not contribute a block or a warning.

Before you change anything

1. Add your office, VPN egress, or server IPs to Known IP Addresses first.
2. Then turn on blocking (unknown IPs, VPN, Tor, or a geographic allowlist) and choose Monitoring or Enforcing.
3. If you can, verify from a second network that legitimate traffic still works.

You must add at least one enabled known IP before Block All Traffic from Unknown IP Addresses will turn on. You must select at least one country before geographic Allowlist mode will turn on. Those requirements exist so an empty policy cannot deny all traffic. The API enforces the same checks when the policy is Monitoring or Enforcing.

Global traffic settings

• Block VPN Traffic — deny requests Edlink identifies as coming through a VPN. If your staff or servers reach Edlink through a VPN, leave this off. A known IP does not exempt the request: if it is also identified as VPN traffic, blocking VPN still denies it when the policy is Enforcing.
• Block Tor Traffic — deny requests Edlink identifies as coming through the Tor network. This is a reasonable default for most teams. A known IP does not exempt Tor traffic either.

Both switches are disabled on the Global Firewall page.

Known IP addresses

Known IP Addresses are networks you trust. Add one from the firewall page, or open the full list. Each entry has a name and either a single address (203.0.113.10 or 203.0.113.10/32) or a CIDR range (203.0.113.0/24). The known list can mark an entry inactive; inactive entries are ignored.

When several ranges match, the most specific one wins (a single host beats a /24). If a known range and a blocked range are equally specific, the address is blocked.

Block All Traffic from Unknown IP Addresses denies any request that does not match an active known range (and is not already handled by a more specific block). The switch stays off until the policy has at least one enabled known IP. On the Global Firewall page the switch is disabled; that page does not support allowlist mode. Known ranges there are still stored and matched when a request falls in one.

Even if you never enable unknown-IP blocking, listing known networks helps Edlink recognize expected traffic, and it will feed risk scoring as that capability ships.

Blocked IP addresses

Blocked IP Addresses are always denied when the policy is Enforcing, including when the address is also on the known list at the same specificity. Use this for ranges you already know are hostile or unwanted. Add one from the firewall page, or open the full list. Each entry has a name and a single address or CIDR range, same as known IPs.

Geographies

Geographic Filter Mode is a pair of options:

• Blocklist (the default) denies the selected countries and allows the rest.
• Allowlist allows only the selected countries.

The page lists each selected country as Traffic Allowed (allowlist) or Traffic Denied (blocklist). Configure Allowed Geographies or Configure Blocked Geographies opens the country picker. Switching to Allowlist starts from an empty selection and requires at least one country.

Allowlisting the United States will block a teacher traveling abroad, a cloud region outside the US, and many corporate VPNs whose egress is in another country. If Edlink cannot determine a country for the request, the geographic rule does not block that request.

The filter-mode control is disabled on the Global Firewall page. That page does not support geographic allowlists.

Start conservative

Defaults allow traffic. That is intentional: an empty firewall should not take production down.

A safe order of operations:

1. Leave the policy in Monitoring (or Disabled) while you inventory the networks you actually use (office, data center, CI, VPN egress).
2. Add known IPs (and labels) before enabling any “block the rest” option.
3. Block specific threats (Tor, individual hostile ranges, a short country blocklist) before you move to allowlists.
4. Switch to Enforcing only after Monitoring shows the warnings you expect.
5. Allowlist last, and only for policies where every legitimate caller has a stable network.

Recommendations by policy

District (person / User API traffic)

This policy applies when a logged-in person is calling Edlink (User API, widgets), not when a vendor's servers are calling Graph with an integration token. Because those callers are people rather than a handful of servers, you usually cannot list every legitimate network in advance. Teachers work from home and students use cellular data, so these calls can originate from almost anywhere the user is.

• Prefer Block Tor and a blocked IP list for ranges you already know are bad.
• Treat Block VPN with care. Many staff networks and privacy tools look like VPNs.
• Avoid block unknown IPs and geographic allowlists unless you have a closed population (for example a single campus with no remote access).
• A country blocklist is usually enough if you need a geographic control at all.

Dashboard access

This policy only affects people signing into Edlink to manage the team. It is a good place to be stricter.

• Add office and admin-VPN egress IPs as known, then consider blocking unknown IPs.
• If administrators work from home on residential ISPs, those addresses change. Either keep unknown IPs allowed, or plan to update the list.
• Leave Block VPN off if your staff connect through a corporate VPN.
• Do not enable Block All Traffic from Unknown IP Addresses until your current network is on the known list. You can lock your own team out.

Application API keys

This is the right policy when your backend, not browsers in classrooms, holds the application secret.

• If keys are used only from your servers, add those egress IPs as known and block unknown IPs. If a key later leaks in a public repository, requests from the attacker's network are denied. Integration access tokens for this application use the same policy.
• If you call Edlink from CI, include those runners. Ephemeral GitHub-hosted runners are a poor fit for IP allowlists; use self-hosted runners with stable egress, or keep unknown IPs allowed for that application.
• Do not allowlist “the whole internet” as a shortcut. If you cannot list callers, skip unknown-IP blocking and rely on blocklists, Tor, and geo blocklists instead.
• Geographic allowlists work when every caller is in a small set of countries (for example US-only hosting). They break as soon as you add a region or a vendor whose egress is elsewhere.

If someone is blocked

In Enforcing, denied requests receive an error and do not proceed. On the dashboard, the person may be unable to load team pages until they connect from an allowed network or another team member updates the policy.

In Monitoring, the same request is allowed and the API response carries the warning described above.

If you have locked yourselves out of dashboard access, contact Edlink Support. Do not try to weaken the policy from a blocked network; that path is intentionally unavailable.

What Network Firewall does not do

Network Firewall does not replace secret rotation, SSO, or sharing rules. It also does not (yet) fingerprint clients, enforce user-agent policies, or detect “impossible travel.” Those are part of the longer API hardening roadmap.

If a key or account is already being used from an allowed network, this policy will not stop that traffic. Rotate credentials and review access as well.