Network flow matrix (SSO / firewall)
This page lists the network flows to allow so that FoxPlan and single sign-on (SSO) work correctly, in particular behind a VPN, a corporate proxy or a firewall performing SSL inspection.
It covers every supported SSO provider: Microsoft / Entra ID, Google, Atlassian (Jira), Okta and any custom OIDC provider (including Keycloak).
How to read this matrix
An SSO sign-in involves two distinct categories of flow:
- Browser flows — issued from the user's device (the provider's sign-in page, the return to FoxPlan). These are the ones that go through the user's VPN / proxy and, when blocked, cause sign-in failures or loops.
- Server flows — issued by the FoxPlan backend to the identity provider (token exchange, signing keys, user profile). In SaaS, these calls originate from FoxPlan's infrastructure and do not concern the customer's firewall. In on-premise, the customer's FoxPlan server must issue them outbound.
All flows are HTTPS (TCP/443).
SSO relies on a state cookie (oauth2_auth_request, SameSite=Lax, Secure). A proxy that strips, rewrites or inspects this cookie prevents FoxPlan from validating the return: the page loops. The domains below must be allowed without SSL inspection or cookie rewriting.
Browser flows (user device → Internet)
These flows go through the user's VPN / proxy. Allow them on the devices. All are over HTTPS (TCP/443). Only allow the row(s) matching the SSO provider(s) you use.
| Provider | Domains to allow (sign-in page + assets) |
|---|---|
| FoxPlan (always) | app.fox-plan.com |
| Microsoft / Entra ID | login.microsoftonline.com, login.microsoft.com, login.live.com, *.msftauth.net, *.msauth.net, *.msauthimages.net |
accounts.google.com, ssl.gstatic.com, fonts.gstatic.com | |
| Atlassian / Jira | auth.atlassian.com |
| Okta | <your-tenant>.okta.com, *.oktacdn.com |
| Custom OIDC / Keycloak | your identity provider domain |
The CSS, images and fonts of the sign-in page are loaded by the provider's page, on its own domain (Microsoft, Google…), and not by FoxPlan — which is never part of that step. They belong to the same provider identity endpoint group: allowing that group via the provider's official list (see "Official references" below) covers them. No need to handle them as separate flows.
login.microsoftonline.com is also used for server-side token exchange (see the next section).
Server flows (FoxPlan backend → identity provider)
In SaaS, these flows originate from FoxPlan's infrastructure and do not need to be opened on the customer's firewall. In on-premise, they must be allowed outbound from the FoxPlan server.
| Domain (FQDN) | Port | Role | Provider |
|---|---|---|---|
login.microsoftonline.com | 443 | Token exchange + signing keys (JWKS) | Microsoft |
graph.microsoft.com | 443 | User profile (userinfo) | Microsoft |
accounts.google.com | 443 | OIDC discovery / keys (JWKS) | |
oauth2.googleapis.com | 443 | Token exchange | |
www.googleapis.com | 443 | Signing keys (JWKS) | |
openidconnect.googleapis.com | 443 | User profile (userinfo) | |
auth.atlassian.com | 443 | Token exchange | Atlassian |
api.atlassian.com | 443 | User profile (/me) | Atlassian |
<your-tenant>.okta.com | 443 | Token, keys (JWKS), userinfo | Okta |
| Your IdP domain | 443 | Token, keys (JWKS), userinfo | Keycloak / custom OIDC |
Inbound flows (identity provider → FoxPlan)
No inbound server flow is initiated by the identity provider toward FoxPlan. The sign-in "return" (OIDC authorization code) is carried by the user's browser to app.fox-plan.com (already covered by the browser flows above), not by a connection issued from the provider's servers.
Firewall implication: there is no need to open an inbound rule from the provider's address ranges (Microsoft, Google, Okta…) toward FoxPlan.
FoxPlan implements no back-channel logout: no other inbound flow from the IdP is expected.
Application flows (excluding SSO)
Beyond SSO, the FoxPlan application uses the following browser flows (HTTPS/443).
Required for the application to work properly:
| Domain (FQDN) | Role |
|---|---|
app.fox-plan.com | Application and documentation (/docs) |
The FoxPlan interface uses no remote fonts (no Google Fonts): it bundles its fonts, so no extra flow is required for rendering.
Optional: none. The application loads no third-party script in the browser — no marketing tracker (HubSpot, Google Ads, LinkedIn) and no analytics script. app.fox-plan.com is enough.
- Audience measurement: performed server-side via Plausible; the browser loads no third-party analytics script (Google Tag Manager / Analytics have been removed). Page load times (Web Vitals) are sent the same way to our own API (
/api/analytics/vitals). - Error reporting (Sentry): the browser SDK sends its events to our own API (
/api/commons/sentry-tunnel, a first-party tunnel) and the backend relays them to the Sentry ingest — so the browser does not contactingest.sentry.io.
Both are server-side outbound flows (FoxPlan infrastructure in SaaS, no impact on the customer's firewall; in on-premise, Plausible only happens if configured).
In SaaS, the server-side outbound flows (email delivery, object file storage, notifications, server error reporting, Plausible audience measurement) originate from FoxPlan's infrastructure and do not concern the customer's firewall. In on-premise, allow HTTPS egress from the FoxPlan server to the services you configure (email provider, S3 object storage, Plausible if applicable, etc.).
Server outbound flows (on-premise)
When self-hosted, these flows go from the FoxPlan application container or pods to the services you configure. They are all outbound: none of them requires opening an inbound port on the FoxPlan server other than 443 (and 80) for users.
| Destination | Port | When |
|---|---|---|
Your SMTP server (MAIL_SMTP_HOST) | MAIL_SMTP_PORT: 587 (STARTTLS), 465 (TLS) or 25 | Always: sign-up codes, invitations, password resets, notifications |
api.sendgrid.com | 443 | Instead of SMTP, if MAIL_PROXY_TYPE=sendgrid |
Your S3 storage (FILE_S3_URL) | The URL's port, usually 443 | If external file storage is configured |
| Identity provider | 443, or its own port (Keycloak on 8443) | If SSO is enabled — domains listed above |
| APIs of enabled connectors (Jira, Everwin…) | 443, or the API's port | If a connector is enabled |
| ACME certificate authority (Let's Encrypt or your PKI) | 443 | Docker Compose acme TLS mode, or cert-manager — flow issued by Traefik or cert-manager, not by the application |
| Sentry ingest | 443 | Only if SENTRY_ENABLED=true (disabled by default) |
The S3 storage does not need to be reachable from the Internet: the application serves the files itself. Internal services — MongoDB (27017), Redis (6379), Garage (3900, 3903), documentation, export — stay on the compose or cluster internal network: do not publish any of their ports.
Image retrieval (on-premise)
Downloading the Docker images involves other flows, only at installation time and during upgrades: the FoxPlan registry (hosts communicated along with its address) and Docker Hub. Their list, and the procedure for retrieving them from an independent environment in a sensitive sector, are given in Docker Compose deployment.
VPN / proxy / firewall watch points
- Do not SSL-inspect or rewrite cookies on
app.fox-plan.comor on the identity domains: this is the #1 cause of SSO sign-ins that "loop". - Allow the domains above on TCP/443, without a proxy authentication interstitial (captive portal) on the return flow.
- Split-tunnel: if the proxy cannot be adjusted, exclude these domains from the VPN tunnel.
- Do not truncate responses: identity responses (tokens) can exceed 8 KB; provide sufficient buffers on the proxy side.
- Allow redirects between
app.fox-plan.comand the provider domain (302) without URL rewriting.
Official references
Host lists change over time; refer to each provider's official source:
- Microsoft / Entra ID — endpoint sets 56 (identity) and 59 (sign-in assets) of the official Microsoft 365 URLs and IP address ranges.
- Google — endpoints published in Google's OpenID configuration.
- Atlassian — Atlassian OAuth 2.0 (3LO) documentation.
- Okta — endpoints of your Okta domain (
https://<your-tenant>.okta.com/.well-known/openid-configuration).
When self-hosting, replace app.fox-plan.com with your own domain. Internal flows (MongoDB database, Redis cache, internal services) stay inside the cluster and are not covered by this matrix — see On-premise (Kubernetes / Docker).