FortiExpert logoFortiExpert
Sign in
← Back to knowledge base
high#769100

Firewall policies intermittently stop matching after policy or address-object changes

Confirmed 8/8/2026

Problem

On a FortiGate restored from a previously working configuration, standard firewall policies may stop matching after creating or modifying policies or address objects. Traffic then reaches the implicit deny policy. Rebooting can temporarily restore forwarding, but the problem may recur.

Symptoms

- Traffic expected to traverse `port2` to `port1` is denied by the implicit default-deny policy. - Working traffic logs show `srcintf=port2, dstintf=port1`; during the failure, both fields show `port2`, indicating an unexpected egress-interface decision that bypasses the `port2`-to-`port1` policies. - The issue may appear after updating or creating a firewall policy. - One observed recurrence happened after creating FQDN address objects and an address group, with a firewall proxy rule deleted a few minutes earlier. - Explicit-proxy clients can still access external resources, and explicit-proxy rules appear unaffected. - Rebooting may restore operation temporarily; one recurrence occurred after approximately 40 minutes. - No policy routes were configured in the reported case.

Environment

Test FortiGate cloud instance. The unit had been factory-reset, login access repaired, and a previously working configuration restored. Explicit proxy was enabled. No policy routes were present.

FortiOS version

FortiOS 6.4.12; the behavior was also reported after downgrading to FortiOS 6.2.9. FortiOS 7.0.x was suggested as an upgrade target, and FortiOS 6.4.13 was suggested once available.

Root Cause

The behavior may be associated with known issue 769100 documented in the FortiOS 6.4.12 release notes, particularly when address objects used by policies are changed. However, the same restored configuration reportedly exhibited the problem after a downgrade to FortiOS 6.2.9, so a configuration-related condition that persists across firmware changes is also possible. An incorrect egress-interface selection should be confirmed with flow debugging rather than assuming policy matching itself is the root cause.

Solution

  1. Confirm whether policy routes exist. The reported environment had none, so policy routing did not explain the unexpected path.

  2. Compare traffic logs from working and failing states. Verify the ingress and egress interfaces. In the reported case, the expected values were srcintf=port2, dstintf=port1, while the failing state showed both source and destination interfaces as port2.

  3. Run a flow debug filtered on the source IP address of the affected test client. Use the following command family to determine whether FortiGate selects the expected egress interface:

diag debug flow filter

  1. If the selected egress interface is incorrect, recognize that the expected firewall policy may not match because traffic is being evaluated for a different interface path. Investigate the routing or configuration state responsible for that selection.

  2. If running FortiOS 6.4.12 and the issue occurs after changing address objects used in policies, review known issue 769100 in the FortiOS 6.4.12 release notes.

  3. Upgrade to FortiOS 7.0.x, where the referenced issue was reported as fixed, or move to FortiOS 6.4.13 when available. Validate the target release against the deployment's normal upgrade requirements before proceeding.

  4. A reboot may temporarily restore policy operation, but it is not a durable correction because the failure can recur.

  5. If the problem persists across firmware changes, as reported after downgrading to FortiOS 6.2.9, treat the restored configuration as a possible contributor. Rebuilding the cloud instance and configuration from scratch may be considered when testing cannot establish a stable configuration state.

Verification

After remediation, generate traffic from the affected source and confirm that logs show the expected interface path, such as srcintf=port2, dstintf=port1, and that the intended port2-to-port1 firewall policy matches instead of the implicit deny policy. Repeat policy and address-object changes, including FQDN address and address-group changes, and monitor beyond the previously observed recurrence period of approximately 40 minutes.

Rollback

A reboot can be used as a temporary recovery action if policies stop matching, although the condition may return. No firmware rollback procedure was provided; downgrading to FortiOS 6.2.9 did not resolve the reported behavior.

Tags

No tags yet.

Community rating

— / 5 (0)

Discussion (0)

    No comments yet.