Testing a FortiGate Deployment Against Real Application Traffic

A firewall can pass traffic successfully and still be poorly matched to the way a business works. Large uploads may time out, an application may fail after authentication, or an inspection exception may allow more traffic than intended. These problems often emerge when the deployment moves from a simple demonstration to ordinary working conditions.

FortiGate application acceptance testing should therefore use representative traffic with the intended security controls enabled. The objective is to establish whether the complete configuration supports approved business activity and produces useful evidence when it blocks something. This is a deployment validation exercise, not a comparison of headline appliance throughput figures.

Build an application catalogue with real owners

List the workflows that matter, including their users, destinations and dependencies. “Accounting system” is too broad if signing in, opening reports, uploading attachments and submitting transactions use different services. Break each workflow into observable steps that a business representative can perform with test data.

Include less frequent but important work. Payroll export, supplier uploads, software updates and month-end reporting may not appear during an ordinary morning pilot. Ask application owners about unusual file sizes, long-running sessions and external integrations. These details help the technical team design a representative test without collecting unnecessary business content.

Record an owner and a recovery expectation for each application. If a session fails, should the user retry, sign in again or ask support to verify the transaction? This matters because an apparently harmless retry can create duplicate work. Acceptance should include the application’s state after interruption, not merely whether its home page opens.

Establish the configuration being accepted

Record the FortiGate model, FortiOS release, policy references, inspection settings and relevant subscription status. Include the routing and identity dependencies used by the test clients. Preserve an approved configuration reference so that the evidence remains tied to a reproducible state.

Fortinet’s FortiOS 7.4.6 administration documentation distinguishes flow-based and proxy-based inspection and places inspection-mode selection in policy configuration. That is a version-specific reference point, not a reason to prescribe one mode for every environment. Verify supported functions and constraints for the exact model and release being deployed.

Do not test with security profiles disabled and present the result as evidence for the production policy. A temporary diagnostic comparison can be useful under controlled conditions, but label it clearly. The final acceptance run must use the settings the business intends to operate, including approved exceptions and logging arrangements.

Agree the evidence before generating traffic

For each test, record the client, identity, source network, application step, expected outcome and relevant policy. Capture start and finish times using consistent clocks. Define what constitutes a pass and what evidence will explain a failure. A screenshot of a successful page load is rarely enough for a multi-step transaction.

Choose a small set of useful performance observations. These may include transaction duration, upload completion, response consistency and user-visible interruption. Have the implementation team correlate those observations with appropriate device and network measurements. Avoid collecting a large volume of counters without a question they are intended to answer.

Protect sensitive information in logs and captures. Use synthetic records or approved test accounts where possible, and restrict access to diagnostic material. Acceptance testing should not require copying customer data into an unrestricted project folder. Record where detailed evidence is stored and who can retrieve it for troubleshooting.

Create a baseline that isolates existing problems

Measure the same application tasks before the change or through an agreed reference path. Note the time, client condition and background load. A baseline helps distinguish a new firewall-related issue from an application that was already inconsistent.

Check basic dependencies separately. Confirm that name resolution, authentication and the destination service are working. Where wireless clients are involved, compare a suitable wired client. Otherwise a local access problem can be misdiagnosed as an inspection problem, leading to unnecessary exceptions in the firewall policy.

Do not make the baseline artificially favourable. If the normal office includes scheduled transfers and busy meeting periods, document them and include representative conditions in the final comparison. The purpose is to understand the production experience, not to find a quiet moment that produces the highest possible test result.

Test encrypted applications with their trust requirements

Where the approved design uses TLS inspection, verify the complete client trust arrangement and the relevant application behaviour. Have the security and application owners review the scope, privacy implications and approved exclusions. Exact inspection capabilities and prerequisites must be checked against the installed FortiOS version and platform.

Test more than browser access. Desktop applications, update agents and integrations may behave differently from a web page. A successful sign-in does not prove that attachment upload, background synchronisation or embedded content will work. Include the steps the application owner identified as essential.

When an application fails, gather evidence before widening access. Establish which policy handled the connection and whether the failure involved trust, inspection, routing or the remote service. If an exception is necessary, document its narrow purpose, owner and review date. A broad bypass created under time pressure should not become an invisible permanent feature.

Add realistic concurrency and sustained activity

Combine important workloads rather than testing every application in isolation. For example, a hypothetical office may run customer calls while staff upload documents and an approved update process operates in the background. Define the participating clients and activity so that the same scenario can be repeated after changes.

Include sustained operations where they matter. A short file transfer may finish before a problem with a long-lived session becomes visible. Test representative durations and sizes approved by the application owner. Avoid uncontrolled load generation on production services; coordinate the scope and stop conditions with the people responsible for those systems.

Observe fairness as well as total completion. A background transfer that succeeds while interactive users experience repeated stalls does not satisfy the business requirement. Compare each critical workflow with its own acceptance criterion. If prioritisation or shaping is part of the design, verify the observed result rather than assuming the configuration achieves it.

Prove that intended restrictions work

Acceptance needs negative tests as well as successful access. Use safe, authorised checks to confirm that a guest client cannot reach restricted internal services and that an ordinary user cannot access management interfaces. Define these tests in advance so a denied connection is recognised as a correct result.

For security-profile validation, use vendor-approved benign test methods appropriate to the configured feature and environment. Do not introduce live malicious content into an office network to demonstrate that a control is active. Have the implementer explain what the chosen test proves and what it cannot prove.

Verify that an intended block creates enough information for support staff to respond. The helpdesk should be able to identify the affected user or device, the time and the relevant policy without guessing. A control that blocks correctly but produces an unusable operational trail may create avoidable downtime during ordinary troubleshooting.

Examine interruption and retry behaviour

Choose a bounded interruption scenario relevant to the deployment, such as an approved path change or a controlled service reconnection. State what is being tested and who can stop it. Preserve the previous configuration and ensure that recovery prerequisites are available before beginning.

Watch the application state after the interruption. Did a submitted record complete, remain pending or fail? Does retrying create another record? The application owner should verify the outcome using test data. This establishes an operating procedure for users instead of leaving them to repeat actions blindly during an incident.

Record the difference between network recovery and usable service recovery. The firewall may resume forwarding before authentication or an application session recovers. Measure the full workflow and include any manual steps. Those steps belong in the support guide if they are part of the accepted operating model.

Turn defects into controlled changes

Maintain a findings register with observed evidence, suspected cause, assigned owner and retest requirement. Separate an application defect from a firewall configuration issue when the evidence supports that distinction. Avoid assigning blame from the location where a symptom first appeared.

Change one meaningful variable at a time where practical. Record the reason, expected effect and rollback route. After a correction, repeat both the failed test and nearby controls that the change could affect. An exception that fixes one upload should not silently weaken access separation for unrelated traffic.

Close the deployment with a signed test summary, final configuration reference, approved exceptions and operational escalation contacts. Include any untested workload and the reason it remains outstanding. A transparent limit is more useful than a blanket statement that every application has been validated.

For a scoped review of security deployment requirements, Maxicon’s services provide a relevant starting point. Contact Maxicon with the application catalogue and proposed acceptance criteria so the technical scope can focus on the work your organisation needs to complete.

Frequently asked questions

Is a speed test sufficient to accept a FortiGate deployment?

No. A speed test covers a limited traffic pattern and does not demonstrate application transactions, authentication, inspection compatibility or access restrictions. Use it only where it answers a defined question. Acceptance should include representative workflows with the production security settings enabled and evidence linked to the final configuration.

Should inspection be disabled when an application fails?

A controlled diagnostic comparison may help an authorised engineer isolate the cause, but it is not the final acceptance state. Gather policy and application evidence first. Any lasting exception should have a narrow scope, an accountable owner and a review date. Retest the affected workflow and related controls after the correction.

Which FortiOS version should the test plan reference?

Reference the exact version and model being deployed. Product behaviour and supported features can vary, so a guide for another release should not be treated as a configuration authority. Keep the relevant documentation and release review with the project records. Reassess affected tests when a material software change is proposed.

How can security blocking be tested safely?

Use authorised, benign validation methods appropriate to the configured feature, following applicable vendor guidance. Agree the scope and stop conditions with the responsible team. Verify both the block and the resulting operational evidence. Do not use live malware or uncontrolled attack traffic in a production acceptance exercise.

Who should approve the final results?

The technical owner should confirm configuration and control evidence, while application owners confirm that their workflows are usable. The business decision-maker should accept any remaining exceptions with their impact and resolution plan. This shared approval prevents a technically successful network test from concealing an application that staff still cannot use.

Related technology support

For an additional service perspective related to this guide, explore Trubyte’s Fortinet and managed security services.