Network Firewall

Network Firewall lets you control which networks can reach Edlink. The same controls appear in three places; each policy only applies to that kind of traffic. Changes take effect immediately on production traffic.

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

For why this exists, see Securing Your Integrations.

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).
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 controls

• 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. If a request from a known IP is also identified as VPN traffic, blocking VPN will still deny it.
• Block Tor Traffic — deny requests Edlink identifies as coming through the Tor network. This is a reasonable default for most teams.
• Known IP Addresses — networks you trust. A single address can be entered as 203.0.113.10 or 203.0.113.10/32; a typical office range looks like 203.0.113.0/24. Label entries so the next person on your team knows what they are. Block All Traffic from Unknown IP Addresses denies any request that is not on this list (and is not already handled by a more specific rule).
• Blocked IP Addresses — always denied. Use this for ranges you already know are hostile or unwanted. The most specific matching range wins (a single host beats a /24). If a known range and a blocked range are equally specific, the address is blocked.
• Geographies — Blocklist (default) denies selected countries and allows the rest. Allowlist allows only selected countries. 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.

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.

Start conservative

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

A safe order of operations:

1. 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. 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

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.

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.