Skip to content
GitHubLinkedIn

Firewall & public ingress

EVEO manages a Fortigate hardware firewall at the perimeter of the LEF private cloud, along with our primary public IPv4 block. It is the control point for inbound internet traffic and remote collaborator access (SSL‑VPN).

All EVEO-hosted servers and services sit behind this perimeter device; only explicitly-forwarded public HTTP(S) traffic is exposed to the internet.

  • Filters inbound traffic and forwards HTTP(S) to internal VIPs/services.
  • Terminates SSL‑VPN (users sign in via Entra SSO) for access to internal services.
  • Enforces that non-HTTP(S) services are not exposed publicly (SSH/DB/admin access stays VPN-only).
  • Public internet: only HTTP/HTTPS forwarding to internal VIPs (no direct public SSH/DB/admin UIs).
  • Operator/internal access: everything else goes via VPN (see VPN access).
  • SSO/auth: SSL‑VPN uses FortiGate SAML-based sign-on via Microsoft Entra (see Entra SAML).

For the current inventory tables (contract label, public IP block, VIP allocations), see Firewall & public ingress (reference).

The firewall and public IP forwarding are provider-managed. When you need a new public hostname or a new mapping, collect:

  • affected domain(s) and public IP (if known)
  • target internal VIP and port(s) (usually 80/443)
  • why the change is needed + expected impact

Then route the request via Infra to EVEO.

If the change includes a new hostname:

  1. Confirm where the site is hosted (Hostinger vs EVEO private cloud): see Domains.
  2. Update DNS (authoritative provider) and, if needed, internal DNS: see dns.core.lef and DNS split horizon.
  3. Update the reverse proxy configuration on web.core.lef and issue TLS certificates: see SSL certificates for web servers.
  • Forwarding points at the wrong internal VIP (service appears “down” publicly).
  • SSL-VPN works but internal DNS/routing is broken (client can’t reach internal hostnames).
  • Entra SSO issues prevent VPN login (identity side).