Description
In certain cases, after a firmware upgrade, the VIP may be seen to have stopped working and the debug flow shows the message "pre_route_auth check fail(id=0), drop".
This message means that the traffic is blocked by a forward policy check.
If the firmware is upgraded to 5.2.5 or later, there is a change in the Firewall policy checking, this is especially for the VIPs.
Scope
FortiOS V5.2.5 and later
Solution
During the troubleshooting with the help of debug flow, the message 'pre_route_auth check fail(id=0), drop' may be seen.
If the traffic is destined to the VIP, then the issue could be with the interface selected in the VIP.
Check if the interface selected in the VIP is 'ANY'. If so, verify if there are any loopback interfaces with an IP range overlapping with the VIP's external IP.
For example: loopback interface has an IP: 1.1.1.1/24 and the VIP IP is 1.1.1.2
If the loopback interface is overlapping with the VIP, then make the following changes:
1) Unselect the VIP in the Firewall policy (only then is it possible to edit the interface of the VIP).
2) Edit the VIP, change the interface from ANY to the Interface on which the traffic is expected to hit (usually, the WAN interface).
3) Select the VIP in the Firewall policy.
After making these changes, the traffic should pass across the FortiGate via VIP.
In a scenario where a VIP’s IP is also overlapping with a local loopback interface subnet such as the following:
Interfaces
Loopback1 -> 192.168.12.1/24 (let's assume the device adjacent to WAN1 has a route to 192.168.12.0/24)
Wan1 -> 192.168.10.2/24
Internal1 -> 192.168.11.1/24
VIP
edit "VIP_01"
set uuid a26692b0-ba2b-51e5-a0e0-53eb29f334fe
set extip 192.168.12.2
set extintf "any"
set mappedip "192.168.11.2"
next
end
Policy
config firewall policy
edit 1
set uuid b5039eea-ba2b-51e5-c794-9f7df933fa97
set srcintf "wan1"
set dstintf "internal1"
set srcaddr "all"
set dstaddr "VIP_01"
set action accept
set schedule "always"
set service "ALL"
next
end
From 5.2.5 onward this configuration will no longer work where it previously would have, two approaches can be then taken:
1) Use a /32 subnet mask on the loopback interface as traffic will naturally try to egress out of Loopback1 due to the 192.168.12.0/24 connected route.
2) If this is not possible, modify the policies so that traffic from wan1 to Loopback1 is allowed, and add another policy from Loopback1 to internal with the VIP_01 object in the destination.
Technical Information
The FortiGate considers some IP addresses as local. For example:
- Addresses in ippool.
- External addresses in VIP (belong to the external interface).
- Addresses set on interfaces (belong to that interface).
A subnet configured on the loopback interface is considered local and belongs to it. So in general, use 32 bit netmask (/32) for loopback interface and its IP should not overlap with vips.
