Technical Tip: Traffic handled by FortiGate for packets with ingress & egress as same interface
Description
Solution
When traffic arrives on the FortiGate, a route lookup is performed to determine which outgoing interface should be used. If the incoming interface matches the outgoing interface, then the FortiGate may allow this traffic to flow even if a Firewall Policy has not been created to allow this traffic explicitly.
This behavior is controlled by the allow-traffic-redirect option, which has different default settings depending on the FortiOS version and can be modified under config system global in the CLI:
config system global
set allow-traffic-redirect [ enable | disable ]
end
When this option is set to enable, the FortiGate will allow traffic to flow in/out on the same interface without requiring a matching Firewall Policy to be created (aka 'implicit-allow'). When this option is set to disable, the FortiGate will require a Firewall Policy to be added to allow traffic to flow in/out on the same interface; otherwise, traffic will not be allowed to flow (aka 'implicit-deny').
Important Note: As of FortiOS v7.4.10, v7.6.5, v8.0.0, and later, the default setting for allow-traffic-redirect (and the IPv6-equivalent ipv6-allow-traffic-redirect) is set to disable (in earlier FortiOS versions, the default setting for this was enable). Furthermore, upgrading to FortiOS v7.4.10, v7.6.5, v8.0.0 or later versions will modify existing configurations and set these CLI options to disable if they were not already set. For reference, the change is tracked under engineering ticket #1225202 as part of security enhancements.
In cases like the above, if the settings are not being checked or kept the same after the upgrade, traffic ingressing and egressing within the same interface may be blocked with 'policy 0'.
2026-02-15 00:18:26 id=65308 trace_id=40 func=fw_forward_handler line=829 msg="Denied by forward policy check
(policy 0)"
The administrator needs to either add a policy to allow the traffic or change the newly implemented default settings back to 'enable'. For more information, refer to the following documents:
- Policy check required for hairpin traffic
- Fortinet CSB-251211-1 (requires a Fortinet Support Site login).
How the source IP of an incoming packet changes the behavior of allow-traffic-redirect:
The combination of the enable/disable status of allow-traffic-redirect and the source IP of the packet can lead to the following scenarios when traffic must ingress and egress on the same interface:
- If the source IP address of the packet is in the same subnet as the FortiGate's ingress interface (e.g., Client = 192.168.0.100, FortiGate = 192.168.0.1) and allow-traffic-redirect is set to enable, then the traffic will be forwarded in and out on the same interface without a Firewall Policy being required.
- If the source IP address of the packet is in the same subnet as the FortiGate's ingress interface and allow-traffic-redirect is set to disable, then the traffic must be matched by a Firewall Policy that allows this traffic (i.e., same Source and Destination Interface). If no such policy exists, then the traffic will match the implicit-deny policy and be dropped.
- If the source IP address of the packet is in a different subnet than the FortiGate's ingress interface (e.g., Client = 10.0.0.100, FortiGate = 192.168.0.1), then the behavior will depend on the FortiOS version:
- In earlier FortiOS versions, traffic would always require a Firewall Policy to be present that allows the traffic explicitly, regardless of what allow-traffic-redirect was set to (i.e., it would always behave like set allow-traffic-redirect disable).
- In FortiOS v7.0.14 +, v7.2.6+, v7.4.0 to 7.4.3, redirect traffic that ingresses and egresses from the same interface for non-connected Source IPs would need to allow the matched traffic along with setting 'set allow-traffic-redirect disable'.
- After FortiOS v7.0.16, v7.2.11, and v7.4.4, the behavior was changed so that traffic from non-connected Source IPs would behave the same as Scenario 1 and Scenario 2 above. For reference, the Change ID was #985508.
- This change matters significantly in cloud environments where it is very common for traffic to have the same incoming and outgoing interface on the FortiGate-VM. If Firewall Policies are configured to inspect this same-interface traffic, then make sure to set allow-traffic-redirect to disable so that traffic continues to undergo policy matching/assessment.
Take note that anti-replay may need to be disabled on Firewall Policies where traffic ingresses and egresses on the same interface, otherwise TCP packets may be treated as replayed traffic and may be dropped:
config firewall policy
edit <policy_id>
set anti-replay [ enable | disable ] <--- Default is enabled.
next
end
If reply traffic is dropped while outbound traffic matches the policy, consider disabling anti-replay on the affected policy
Logs typically show outbound traffic allowed, while reply traffic is silently dropped due to replay detection.
Notes:
- Under certain conditions, a route flap or routing peer connectivity issues could cause traffic to loop between FortiGate and the neighboring router/switch until the TTL expires for each packet. This could result in high CPU on the FortiGate and the next-hop device if there is a considerable amount of looping traffic. Configuring a blackhole route or setting allow-traffic-redirect to disable can be helpful to avoid Layer 3 traffic loops.
- For public-cloud FortiGate-VMs, it is generally recommended to set allow-traffic-redirect to disable to ensure that traffic is always assessed against the configured Firewall Policies.
- This setting can also impact the logging of user traffic, as traffic logs are only generated when passing through a Firewall Policy. See also: Troubleshooting Tip: Missing Traffic logs on VM when the Ingress and Egress interface are same for the traffic.
Related articles: