According to Packet Life in FortiGate, Destination NAT takes effect at the beginning of packet processing. In the FortiGate kernel, packets are processed in the following order: Â DNAT (Virtual IP). Routing. Policy lookup. Session helper. User authentication. Device identification. SSL VPN. Local management traffic.
 A local policy with an 'action deny' will not deny traffic allowed by a VIP policy because when the local policy takes effect, the VIP policy has already allowed the traffic. Â
To resolve the issue. Create a GEO address object. Create a firewall policy and select the source address of the 'GEO address' object. Select the destination VIP. Select the action deny in the policy. Put it on top of the VIP allow policy to block the source GEO address.
   Notes: The destination address of the deny policy should be set to the VIP address. If set to the normal local server IP address, use CLI to enable match-vip: 'set match-vip enable' in the deny policy. The match-vip option is disabled by default until v7.2.3. In versions above 7.2.3, the option is enabled by default. The 'set match-vip' option is only available if the policy action is set to 'deny'.Â
Local-in policy: controls traffic to FortiGate itself.
Examples added:
Firewall policy with VIP: controls traffic passing through FortiGate.
The following article explains how to configure blocking VIP access using GEO location: Technical Tip: How to block VIP access using GEO Location
Local-in policies apply only to traffic destined for the FortiGate itself, such as traffic to an interface IP, while regular firewall policies control traffic that is forwarded through the FortiGate.
When a VIP is configured, the original destination IP can be translated to the mapped internal IP during DNAT processing. Therefore, the firewall policy should be evaluated with the VIP and match-vip behavior in mind.
A local-in policy should not be used as a replacement for a firewall policy when the objective is to control access to an internal server published through a VIP.
To block specific sources from accessing a VIP, create an explicit deny firewall policy above the existing VIP allow policy. This ensures the deny policy is evaluated before the broader allow policy.
If the VIP allow policy uses source address = all, any source not explicitly denied by a higher-priority policy can potentially match the allow policy.
Policy order is important for VIP traffic. FortiGate evaluates firewall policies from top to bottom, and the first matching policy is used. When troubleshooting a VIP access issue, verify the VIP configuration, mapped IP address, mapped port, incoming interface, firewall policy order, source address, destination address, and service configuration.
If a deny policy is not matching the expected VIP traffic, verify whether match-vip is enabled where required and confirm that the policy action is set to deny.
The match-vip setting allows a deny policy to match traffic based on the VIP before the destination address is translated to the real server address.
Local-in policy troubleshooting should focus on traffic destined to FortiGate interface addresses and enabled administrative or service ports. It does not directly control forwarded traffic to an internal server.
Related documents:
| 
