01Executive summary

Supporting business networks for a managed service provider means no two environments look alike. Firewall models, firmware, VLAN layouts, switching platforms and remote-access methods all vary from customer to customer, and every change lands on a running business.

This case study covers the recurring engineering work behind those networks and two representative scenarios: a FortiGuard connectivity degradation affecting nine FortiGate devices after a rollout, and a native VLAN mismatch between switching and firewall subinterfaces.

02Disciplines & technologies

03The problem

Customer networks have to stay connected and segmented while the business keeps working. When something fails it rarely announces the layer it failed at: a tunnel that will not come up, a VLAN that cannot reach its gateway, a remote user who cannot authenticate, or security services that quietly stop updating.

Each of those has a different root-cause layer, and each customer is configured differently. The work is diagnosing quickly without guessing, and changing things without creating a second outage.

04Environment & complexity

• Multiple customer sites with different FortiGate models and firmware levels
• Some environments centrally managed in FortiManager, others administered per device
• Switching from UniFi, Cisco and Meraki, each with different native VLAN defaults
• Remote access through FortiClient, with EMS and SAML-based sign-in
• Site-to-site IPsec between FortiGates and to UniFi gateways
• Shared services such as DHCP relayed from the firewall to central servers

05My contributions

• FortiGate firewall management, configuration and troubleshooting across customer sites
• Site-to-site IPsec tunnel configuration and connectivity validation: proposals, selectors, routes and policies
• FortiGate-to-UniFi IPsec interoperability
• VLAN tagging, native VLAN mismatches and trunk configuration
• Firewall policies, routing, NAT, DNS and DHCP relay
• FortiClient EMS and SAML authentication troubleshooting for remote users
• Work inside FortiManager-managed environments
• FortiGuard service communication and update troubleshooting

06Diagnostic workflow

Scenario A · FortiGuard connectivity degradation

Following a rollout, nine FortiGate devices showed degraded FortiGuard connectivity. The key was separating two questions that look the same from the outside: can the firewall reach the internet, and are the FortiGuard services actually working?

1. Scope itConfirm which devices and which FortiGuard services were affected, and how the timing lined up with the rollout.
2. Reachability ≠ service healthBasic reachability to FortiGuard hostnames succeeding does not prove the services are healthy, so test the service itself.
3. Review FortiGuard settingsCheck the anycast setting and which update servers the device was using.
4. Exercise the update pathTrigger updates and review what the update service actually did.
5. Adjust connectivityEvaluate changes to FortiGuard connectivity, including regional update service selection, on affected devices.
6. Validate and recordRe-check service status per device and document what changed.

# reachability vs. service health
› execute ping service.fortiguard.net
› diagnose debug rating
# update service behavior
› diagnose autoupdate versions
› execute update-now
# connectivity settings that were evaluated
› config system fortiguard
›     set fortiguard-anycast disable
›     set update-server-location usa
› end

Scenario B · Native VLAN vs. tagged subinterfaces

A multi-site switching and firewall integration issue: a switch sent a VLAN untagged as its native VLAN, while the FortiGate expected that VLAN tagged on a subinterface. The link is up, but frames land on the parent interface instead of the VLAN subinterface, so clients cannot get DHCP or reach their gateway.

• Both ends must agree on which VLAN, if any, is native and untagged
• Every FortiGate VLAN subinterface ID must match the 802.1Q tag the switch sends
• The native VLAN has to be consistent across every switch in the path; UniFi, Cisco and Meraki defaults differ
• DHCP relay and server reachability have to follow the corrected interface

07Challenges & decisions

08Outcomes

• Ongoing

  Ongoing support of customer networks across FortiGate, UniFi, Cisco and Meraki environments.

• Pending verification

  FortiGuard degradation on nine devices: diagnostic workflow carried out as described; root cause and final remediation pending confirmation.

• Pending verification

  Native VLAN scenario: final change and validation pending confirmation.

• Not documented

  No uptime, performance or incident-reduction figures are claimed.

09Lessons & capabilities

• “Up” and “working” are different questions at every layer
• Write down the expected tag on both ends before touching a trunk
• Interop tunnels should be specified explicitly, never inherited from defaults
• Fleet-wide changes need a test cohort and a rollback path

Capabilities demonstrated

• IPsec design & troubleshooting
• 802.1Q / VLAN design
• FortiOS CLI diagnostics
• Fortinet fleet administration
• Multi-vendor networking
• Incident triage

10Related work