|
Administrators may observe the following:
- PBR rule is configured correctly (source, destination, outgoing interface, gateway).
- diagnose firewall proute list shows the PBR rule is matched.
- Logs show sessions hitting the VIP or outgoing interface, but:
- No sessions appear under the firewall policy.
- Traffic does not pass through the firewall.
- Traceroute fails or times out after a few hops.
In some cases, disabling PBR allows the traffic to pass normally.
Typical log behavior:
No matching firewall policy.
Policy ID 0 hits.
Sessions dropped due to an 'implicit deny'.
Cause:
- Policy-Based Routing only decides where to send the traffic (routing decision). It does not decide whether traffic is allowed.
- Even when PBR forwards traffic through a chosen WAN interface, the firewall engine still requires a matching firewall policy to allow the session.
- If no firewall policy matches the traffic (source → destination → service), the FortiGate will:
- Apply routing logic according to the PBR.
- Attempt to forward the traffic.
- Then drop the session, because there is no allow policy.
Traffic hits the implicit deny (policy 0).
This results in:
- No 'Allowed' logs.
- No policy hits.
- Traffic failing despite PBR matching.
PBR = Routing decision.
Firewall Policy = Security decision.
Both are mandatory.
Common Scenarios Where This Occurs:
- PBR points traffic to a different WAN (WAN2), but the firewall policy only allows traffic via WAN1.
- VIP traffic appears as 'VIP hit', but no associated policy hit is seen.
- Traceroute reaches 2–3 hops, then stops → because traffic is routed, but not allowed.
- Asymmetric Routing occurs when incoming and outgoing interfaces do not match the policy.
Solution:
- Ensure a Matching Firewall Policy Exists for PBR Traffic.
Navigate to: Policy & Objects → Firewall Policy → Create/Edit Policy.
Key requirements:
Incoming Interface = Source LAN interface.
Outgoing Interface = Same as PBR outgoing interface (example: WAN2).
Source Address = Users/subnet used in PBR.
Destination Address = All or specific.
Services = Required ports.
NAT = Enable (if Internet traffic).
CLI Example:
config firewall policy
edit <policy_id>
set srcintf "LAN"
set dstintf "wan2"
set srcaddr "PBR-users"
set dstaddr "all"
set service "ALL"
set action accept
set nat enable
next
end
-
Verify firewall policy hit count.
Use:
diagnose firewall proute list
PBR hit count should increment.
Then check:
get firewall policy <policy_id>
Hit count should increase during testing.
-
Re-test Traffic Flow.
After the firewall policy is added, traceroute should complete.
Traffic should hit the correct allow policy.
VIP traffic should show a correct policy match.
No more sessions hitting policy 0.
Verification:
- Traffic Logs should now show Allowed actions and the correct outgoing interface.
- Matched policy ID.
- Sniffer:
diagnose sniffer packet any 'host <destination>' 4 0 a
Debug Flow (if needed):
diagnose debug flow filter addr <source_IP>
diagnose debug flow show function-name enable
diagnose debug enable
diagnose debug flow trace start 100
It should now show:
Allowed by policy X
Found policy route
Correct interface handoff
Conclusion:
Policy-Based Routing controls how traffic is forwarded, but does not override firewall security policies.
A correct and matching firewall policy is always required to allow traffic, even if PBR already routes the packet.
Without the firewall policy:
Traffic matches the PBR but is dropped by implicit deny, resulting in timeouts, unreachable destinations, and no policy hits
Adding the correct firewall policy ensures traffic flows successfully through the PBR-defined path.
|
