Two internet connections can look reassuring on a network diagram. During working hours, however, a branch may still experience broken calls, stalled uploads or an application that becomes unavailable whenever the preferred connection deteriorates. Installing a second circuit is only the beginning of a continuity design.
FortiGate SD-WAN acceptance testing should answer a practical question: does the deployed network handle the connection conditions your business is likely to encounter? A useful test examines the applications, the link selection behaviour, the security policy and the team’s ability to diagnose an unexpected result. It should also distinguish a complete outage from a connection that remains active but performs poorly.
This guide provides a business-focused testing framework. It is not a universal configuration recipe. FortiOS behaviour, supported features and management options depend on the selected platform and software release. Your implementation team should verify the exact documentation and approved configuration before running tests.
Define the service you need the branch to maintain
Start with business activities rather than a generic bandwidth target. A branch might need to maintain customer calls, access a hosted accounting application and upload delivery documents. Each activity has different dependencies and tolerances. Write down which activities must continue and which can wait during a connection incident.
Identify the users, devices and application destinations involved. Include authentication, DNS and remote services that the workflow relies on. An application may appear to have an internet problem when the real dependency is an unavailable identity service or a failed internal route.
Have the business owner approve the expected outcome. A brief reconnection may be acceptable for a background upload but disruptive during a customer call. Define how recovery will be observed and measured for each workflow. Do not promise uninterrupted sessions simply because more than one connection exists.
If the branch design is still being assessed, Maxicon’s network infrastructure services provide a relevant route for discussing the network and its operational requirements before setting acceptance criteria.
Establish a baseline before simulating an incident
Measure the current experience with both links healthy. Record the test time, participating clients, application activity and any other significant load. This gives the team a reference for judging whether the incident test changed performance or exposed an existing problem.
Check the wired environment before attributing every symptom to SD-WAN. Client access, switching, local uplinks and name resolution can influence results. Where wireless clients are included, also note their location and connection quality. A mixed test without those details can produce misleading conclusions.
Confirm which traffic is actually using each link. The existence of two connected interfaces does not prove that a particular application has the expected eligible paths. The implementation team should review routes, relevant policies and the configured SD-WAN rules using tools appropriate to the installed release.
Keep the approved configuration and a recovery route available before changes begin. Agree who can authorise the exercise, who performs the technical work, and who can stop it if business impact exceeds the planned scope.
Choose health checks that represent a useful network dependency
Fortinet’s administration documentation describes performance SLA monitoring in terms of link quality measurements such as latency, jitter and packet loss. The important planning question is what those measurements tell your team about the service you want to protect.
A reachable probe destination does not automatically prove that every business application is usable. Choose monitoring targets and methods deliberately, considering the actual paths and dependencies. Document what a successful check demonstrates and what remains outside its scope.
Set thresholds from application requirements and observed conditions. A copied example value is not a justified acceptance target for every branch. Explain why the selected values are appropriate and verify that the monitoring can distinguish the conditions your test is intended to create.
Also consider the target itself. If a probe destination has an unrelated incident, the team needs a way to understand why the result changed. Discuss resilience and interpretation of the monitoring design with the engineer, rather than treating the probe as an infallible description of the entire internet connection.
Test a hard outage and a degraded connection separately
A disconnected link is a clear failure condition. A degraded connection is less obvious: the circuit may stay up while applications become difficult to use. These situations should be different test cases because the configured decision logic may respond differently.
During a controlled hard-outage test, observe how the affected traffic behaves and whether the alternative route provides the required service. Record application recovery as well as network detection. Existing sessions and newly initiated sessions may behave differently, so test both where they matter to the workflow.
For a degradation test, use an approved method that can create the relevant impairment within the agreed scope. The method, equipment and parameters belong in the test plan. Avoid improvising a disruptive experiment on a busy live branch without a defined stop condition.
Document the difference between detecting an unhealthy path, selecting another eligible path and the application becoming usable again. These are related events, but they are not identical. A business acceptance result should reflect what users can actually do after the network responds.
Review the independence of the two connections
Two provider invoices do not prove that the branch has two independent failure paths. Circuits may share a building entry, upstream infrastructure or local power dependency. The business should understand which outages the design addresses and which could affect both links.
Check local dependencies with the appropriate specialists. The circuits may terminate on equipment powered from the same source or connect through a single critical switch. Document those shared components and how their failure affects the service.
Include provider contact details and circuit identifiers in the operating record. During an incident, staff should not need to search purchase emails to find the right escalation route. Keep the information under business control and review it when providers or contracts change.
The acceptance report should describe the tested failure boundary. A successful link-loss exercise can support a conclusion about that scenario. It does not establish protection against every building, provider or equipment outage.
Check that alternate paths preserve the intended access policy
Availability should not come from an accidental bypass of agreed security controls. Review the policies and inspection relevant to traffic using each eligible path. Confirm the intended destinations remain accessible and that prohibited access remains prohibited during the exercise.
Include important application dependencies. A route that permits the main application but blocks its authentication or supporting service can leave users unable to work. Conversely, an overly broad temporary rule may make a test appear successful while changing the branch’s security posture.
Have the implementation team document any temporary test changes and restore them afterward. Compare the final configuration with the approved state. A test is incomplete if it leaves extra access, disabled inspection or an undocumented troubleshooting exception behind.
Avoid using this exercise as a substitute for the wider security review. It verifies the defined behaviour under the selected connection scenarios. The organisation still needs continuing ownership of firewall administration, maintenance and rule changes.
Include voice, transactions and larger transfers in the test
Choose a small set of representative business activities rather than relying on a speed test alone. A voice call, an application login, a transaction submission and a larger upload can expose different symptoms. Agree which ones reflect the branch’s essential work.
Use test records or another approved method for transactional applications. Confirm that an uncertain response has not created duplicate business actions before repeating it. Network recovery and transaction reconciliation need coordination between the technical and application owners.
For each activity, record the expected result, the failure condition, the observed behaviour and whether the business owner accepted the outcome. Note any user action required, such as signing in again or restarting a transfer. Those steps may belong in the operating instructions.
Repeat important cases under representative demand where the agreed test environment allows it. A quiet branch test may not describe a busy operational period. Explain the limitations of the test load in the report so reviewers know what the result supports.
Observe recovery when the preferred link returns
Restoring the original connection is another change in network conditions. Observe whether traffic remains stable, how the configured selection behaviour responds and whether applications experience another interruption. Recovery should be part of the test, not an unrecorded final step.
Watch for repeated switching when a marginal connection moves around the configured thresholds. Investigate the monitoring and selection design with the engineer if results are unstable. Do not immediately lower the standard for an acceptable link simply to remove alerts.
Record the time allowed for observation and any unresolved symptoms. A link that returns briefly and deteriorates again may need provider investigation. The runbook should make clear who owns that investigation and how branch users receive updates.
End the exercise by confirming that both paths, relevant monitoring and the required applications are in the approved operating state. Retain the evidence and document any follow-up changes that require a separate maintenance window.
Turn the results into an operating handover
The final pack should contain the approved topology, circuit records, application test matrix, monitoring rationale, recovery observations and a list of exceptions. Give every unresolved item an owner and a decision date. Separate accepted limitations from defects that still need correction.
Describe what staff should report when a connection problem occurs. Application name, time, affected users and a concise symptom can be more helpful than ‘the internet is slow’. Specify how the technical team receives alerts and who communicates with the branch.
Agree ongoing maintenance responsibilities, including review after meaningful changes to applications, providers or firmware. Maxicon’s IT support contracts are relevant for discussing support ownership around the deployed environment.
Keep wider continuity requirements in view. Internet path recovery cannot restore a lost application database or damaged server. Where those dependencies are important, include disaster recovery planning in the broader business continuity discussion.
Prepare your branch information before requesting an assessment
Gather the FortiGate model, installed FortiOS version, provider circuit details, topology and list of critical applications. Add recent incident examples and the outcomes the branch needs during an outage. The technical team can then propose a test scope tied to the actual deployment.
Contact Maxicon to discuss the assessment and commissioning requirements. Ask for a documented acceptance plan with business owners, measurable outcomes and a handover process. A credible result explains both what worked and the failure conditions that remain outside the design.
Frequently asked questions
Will FortiGate SD-WAN keep every existing session uninterrupted?
Do not assume that outcome. Session behaviour depends on the application, path change and deployed configuration. Test existing sessions and new sessions separately for critical workflows. Document any reconnection required and have the business owner accept the practical result.
Is disconnecting a cable enough to complete acceptance testing?
It provides evidence for one failure scenario. Add controlled degraded-link testing, representative applications and recovery observation where these are in scope. Also review shared dependencies, monitoring interpretation and policy behaviour before treating the branch commissioning as complete.
Should every application use the same link-quality thresholds?
Requirements can differ. Agree the important workflows and use measured conditions to justify the monitoring and selection design. Verify implementation against the installed FortiOS documentation. Avoid treating copied example settings as universal targets for all branches and applications.
Can a small business run a useful test without a large lab?
A bounded exercise can still provide useful evidence if the scope, authorization, recovery route and limitations are clear. Work with the implementation team to select an appropriate method. Protect live business operations and record what the test environment does and does not represent.
When should the branch be tested again?
Review the need after meaningful changes to providers, routing, applications, security policies or firmware, and after incidents that reveal an untested condition. Agree a recurring review suitable for the business. The timing should follow operational risk and change frequency rather than an arbitrary universal schedule.
Related technology support
For an additional service perspective related to this guide, explore Trubyte’s Fortinet and managed security services.
Discuss your requirements with Maxicon
Tell us about your business, current environment and the support you need.
