A FortiGate has two internet links. The SD-WAN rule should send an application through wan1, yet the traffic log shows wan2. Both circuits are physically up. Before changing priorities, find out whether the test flow matched the intended rule, whether wan1 qualified for that rule, and which interface the session actually used.
The examples use IPv4 and FortiOS 7.6. Run the commands in the VDOM that owns the traffic. Replace the example addresses with those of a client and destination you administer.
1. Start with one forwarded flow
Record the source IP, ingress interface, destination IP, protocol, and destination port. If the user reports a problem with a hostname, capture the actual destination IP from the traffic log. A cloud application can resolve to different addresses on successive requests.
The example below traces TCP 443 from client 10.10.10.25 to 203.0.113.25, a documentation address. Use a fresh TCP connection from the client when comparing behavior before and after a change. A ping from the FortiGate exercises locally originated traffic and may follow different selection settings.
2. Check whether the preferred member meets the rule’s SLA
get system status
show system sdwan
diagnose sys sdwan health-checkIn the health-check output, match the probe name and member ID to the intended rule. Compare the measured latency, jitter, and packet loss with the configured thresholds. A member can show as alive because probes receive replies and still fail a particular SLA target. Where the output reports an SLA bitmap, interpret it against the SLA IDs defined for that health check.
Also verify the probe target. Reaching a public DNS resolver demonstrates reachability to that resolver. If users report problems reaching a private application across an overlay, check the health measurement that applies to that path.
Fortinet – Verifying SD-WAN traffic and SLA health checks
3. Check the SD-WAN rule and route eligibility
diagnose sys sdwan service4
diagnose firewall proute list
get router info routing-table details 203.0.113.25Find the rule by its service ID. Compare its source, destination, protocol, and port criteria with the captured flow. Review earlier rules that could match first. For rules that use an application or Internet Service object, check how the flow was classified before drawing conclusions from its destination IP.
Review the rule’s strategy and member status. A load-balancing rule can show several selected members, and the selected list alone does not establish which link carried a specific session. In the policy-route output, vwl_service identifies the SD-WAN rule associated with an entry. Look for a matching explicit policy route too, because a regular policy route can take precedence over the SD-WAN rule. In the routing table, check for the expected destination route and usable next hop in the same VDOM.
On builds before the IPv4/IPv6 command split, use diagnose sys sdwan service. Fortinet documents the split starting in FortiOS 7.4.4.
Fortinet – WAN link selection with SD-WAN rules · Fortinet – SD-WAN service command split · Fortinet – Route lookup process
4. Verify the actual session
diagnose sys session filter clear
diagnose sys session filter src 10.10.10.25
diagnose sys session filter dst 203.0.113.25
diagnose sys session filter proto 6
diagnose sys session filter dport 443
diagnose sys session list
diagnose sys session filter clearCheck the matching session’s policy ID, original-direction egress interface, and NAT information. The dev= field may show interface indexes, so cross-check the egress with the forward traffic log if needed. If you changed the rule, compare the pre-existing session with a fresh connection. An established session can retain its path, while some routing or configuration changes trigger revalidation. The commands above clear diagnostic filters only and preserve traffic sessions.
If you need a short packet-flow trace, coordinate with anyone already debugging the FortiGate. Apply narrow filters, generate a fresh connection, and stop the trace as soon as you have the routing and policy decision.
diagnose debug flow filter clear
diagnose debug flow filter saddr 10.10.10.25
diagnose debug flow filter daddr 203.0.113.25
diagnose debug flow filter proto 6
diagnose debug flow filter dport 443
diagnose debug flow trace start 20
diagnose debug enablediagnose debug disable
diagnose debug flow trace stop
diagnose debug flow filter clearAn offloaded flow may produce little or no debug-flow output. Correlate session and traffic logs first, and consult the platform-specific tracing guidance before changing offload settings.
Fortinet – Using a session table · Fortinet – Debugging the packet flow
Example: The preferred link is up but fails the application SLA
The application rule prefers wan1 when its SLA is satisfied and uses wan2 as a backup. Both links answer probes. The rule requires packet loss of at most 1%, while the relevant health check shows 3% on wan1 and 0% on wan2. A fresh TCP 443 session uses wan2.
Check whether the loss also appears on the application path. If it does, investigate the link or upstream path. If the problem is isolated to the probe target, review whether that target represents the service the rule is intended to protect. After the correction, confirm that wan1 satisfies the SLA and verify the egress interface of a new connection.
| Evidence | Next check |
|---|---|
| Preferred member is alive but fails the rule’s SLA | Compare probe measurements with thresholds and verify the probe path. |
| A different SD-WAN rule matches | Compare rule order and the actual source, destination, and service. |
| Explicit policy route matches the flow | Review its match criteria and precedence. |
| Expected rule is selected but the destination route is missing | Check the route and next-hop reachability in the traffic VDOM. |
| Only the old session uses the previous link | Test with a fresh connection and compare both session records. |
Verify the correction
Repeat the same client-to-application test with a fresh connection. Confirm the intended rule, member, egress interface, and application response. If the change affects failover behavior, verify backup link selection and recovery during an approved test window.