Description
This article describes the expected behavior of the FortiGate when packets ingress and egress on the same interface (e.g., traffic comes in on a LAN interface and then also exists the same LAN interface).
Scope
FortiGate.
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.6.5 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.6.5 or later will modify existing configurations and set these CLI options to disable if they were not already set.
If same-interface traffic is required in the network environment, then make sure that an appropriate Firewall Policy has been created to explicitly allow this flow; otherwise, traffic may be blocked by implicit-deny upon upgrading firmware. For more information, refer to the following documents:
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).
- 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 enable
next
end
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 t....
Related articles:
