Technical Tip: Traffic is dropped due to 'implicit deny policy-0' when a VIP is not-fully configured or specified

Description

This article describes effect of the not full VIP configured, which can cause drop traffic by 'implicit deny policy-0'.

Scope

FortiGate.

Solution

Sometimes, when there's traffic that's expected to match the configuration that allows it to flow through the FortiGate, it does not work. If there is a very generically configured VIP and perform a debug flow, it could show the message 'Denied by forward policy check (policy 0)', which can cause unexpected behavior.

This is because the traffic analysis flow has a certain order, which is analyzed first by other processes, the Destination NAT IP, and then the Routing Table among other processes to go to the destination. This means that traffic can be diverted if it coincides with a very generic VIP.

Packet flow ingress and egress: FortiGates without network processor offloading

There are different ways in which VIP can be implemented.

For example, in scenarios where Central NAT is used, the VIP is implemented without the need for it to be referenced or used in any specific policy.

In this scenario, generically using VIP could be interpreted by FortiGate as a coincidence and alter the expected traffic flow, even when it is not referenced in a specific policy.

It is possible to see that the traffic does not match what is specified in the policies but does not show that it matches the VIP by observing the following debug flow output on specific traffic:

Debug traffic Log:

id=65308 trace_id=1329 func=print_pkt_detail line=5932 msg="vd-root:0 received a packet(proto=6, 192.168.1.65:59178->23.227.38.32:443) tun_id=0.0.0.0 from Port1. flag [S], seq 1100903024, ack 0, win 65535"
id=65308 trace_id=1329 func=init_ip_session_common line=6124 msg="allocate a new session-0012a7bf"
id=65308 trace_id=1329 func=__vf_ip_route_input_rcu line=1989 msg="find a route: flag=00000000 gw-55.55.55.55 via root"
id=65308 trace_id=1329 func=__iprope_tree_check line=524 msg="gnum-100004, use int hash, slot=115, len=1"
id=65308 trace_id=1329 func=fw_forward_handler line=840 msg="Denied by forward policy check (policy 0)"

When this occurs, there may be other causes for this error, even when the traffic is configured correctly to define where to forward it. But one of them is a VIP mismatch, where the WAN IP is used in the VIP, but which interface is not specifically defined (interface set as 'any').

This causes the FortiGate to analyze the destination IP of the packet and try to match it with a VIP that has no defined interface or is left as 'any', then the FortiGate tries to do a 'Hairpin NAT' but it does not have the rest of the configuration to complete a 'Hairpin NAT' and drop the traffic (see reference):

In some cases, such as 'Central Nat' or 'Hairpin NAT', the VIP interface should be left as 'any'. However, in others, this may affect other traffic that should not be related to the VIP.

To avoid this, it is recommended that, as far as possible, all available configuration fields be defined in the VIP to be configured.

Note: When multiple VIPs are configured with the same external IP address, it is recommended to configure a Source Interface Filter (srcintf-filter) on each VIP.

This allows FortiGate to uniquely identify the correct VIP based on the ingress interface and prevents ambiguous VIP selection during policy lookup. Without a srcintf-filter, the firewall may successfully perform DNAT but fail the subsequent firewall policy validation with messages similar to:

matched policy-2, act=accept, vip=2
result: vid-2, ret-matched
...
failed to match vid-2
...
Denied by forward policy check (policy 0)

In this scenario, the packet is translated using the correct VIP, but the forward policy lookup cannot validate the associated VIP (vid-2), causing the traffic to fall through to the implicit deny policy. Configuring srcintf-filter on each VIP ensures deterministic VIP selection and allows the corresponding firewall policy to match correctly.

For more information on some VIP uses and traffic processing, check the related documents:

Technical Tip: Configure firewall policies for a VIP when Central NAT is enabled

Technical Tip: Configuring Hairpin NAT (VIP)

Debugging the packet flow

Packet flow ingress and egress: FortiGates without network processor offloading