Skip to content

Deprecated Fortigate Edge Firewall Variant

Status

Deprecated — Fortigate remains a possible customer-specific or teaching variant, but it is not the current HybridOps baseline. The supported default edge path is the VyOS-based control plane.

Status note

Keep this ADR only as a record of a possible commercial-vendor mapping. For the current supported operating path, follow:

Context

HybridOps now standardises on a VyOS-based edge path for the active WAN and site-extension model. This ADR is retained because Fortigate can still be relevant as a customer-specific variant or a comparison exercise.

HybridOps already standardised on:

  • pfSense CE as a previously considered flow-control direction (ADR-0301).
  • CSR1000v / VyOS as earlier routing and VPN edge directions (ADR-0107).

In many enterprise environments, firewall platforms such as Fortigate are widely deployed for:

  • Next-generation firewalling (application-aware policies, threat feeds).
  • SD-WAN and advanced VPN capabilities.
  • Tight integration with enterprise security tooling.

To demonstrate portability of the design, this ADR introduces Fortigate as a drop-in vendor variant that can implement the same core policy patterns:

  • Segmented zones (mgmt, observability, dev, staging, prod, lab).
  • Policy routing for dual ISP and hybrid paths.
  • NAT and flow-control aligned with the existing ADRs.

Decision

Keep Fortigate as an explicit variant-only edge firewall option that may be used when a customer or lab scenario requires it.

  • Mirrors the pfSense design for:
  • External interfaces (dual ISP uplinks).
  • Internal zones/VLANs.
  • Policy routing and NAT patterns.
  • Reuses the same network and security ADRs as design constraints:
  • VLAN ranges and roles (ADR-0101).
  • Proxmox as intra-site core (ADR-0102).
  • Inter-VLAN firewall policy (ADR-0103).
  • Dual ISP failover and load balancing (ADR-0106).
  • pfSense flow-control principles (ADR-0301).

Fortigate does not replace the current VyOS-based HyOps edge baseline. It exists to show how the same governance model can be mapped onto a commercial firewall where needed.

Rationale

  • Vendor-agnostic credibility: demonstrates that the security and network architecture is expressed as patterns, not locked to a single product.
  • Realistic enterprise flavour: many assessors will recognise Fortigate from production environments.
  • Reusability: the same ADRs and runbooks constrain Fortigate policy; we avoid maintaining a completely separate “Fortigate-only” design.

Consequences

Positive

  • Strengthens the message that HybridOps is pattern-driven, not product-driven.
  • Provides a concrete example of “same architecture, different vendor”.
  • Enables comparative demos (pfSense vs Fortigate) using identical test scenarios.

Negative

  • Additional configuration to maintain (Fortigate policy objects, interfaces, VPNs).
  • Potential licensing cost and platform overhead if fully implemented.

Neutral

  • If Fortigate is not available, the core architecture remains fully represented by pfSense + CSR/VyOS.
  • Evidence for this ADR can be scoped to a small, focused scenario (e.g. dual ISP + 2–3 VLANs), not the entire platform.

Implementation Sketch

  • Create a minimal Fortigate topology that mirrors:
  • WAN_A / WAN_B uplinks.
  • Internal zones for management, observability, and one application VLAN.
  • Implement:
  • Basic firewall policies equivalent to pfSense rules in ADR-0301.
  • Policy routing / SD-WAN rules equivalent to dual ISP behaviour in ADR-0106.
  • Capture:
  • Screenshots of interface and policy configuration.
  • Route tables and session views under failover.
  • Packet captures demonstrating policy behaviour.

Evidence will be collected under:

  • <runtime-root>/logs/security/fortigate-variant-tests/

References

Owner: HybridOps
License: MIT-0 for code, CC-BY-4.0 for documentation