| Description | This article describes the common issue with the use of Virtual server VIP configuration when traffic mismatches the firewall policy configured with the VIP or even in the case of this traffic does match the policy however traffic logs are showing blocked by policy 0 which is the implicit deny policy. |
| Scope | FortiGate - Virtual IP configuration - FortiOS. |
| Solution |
The use of Virtual IP VIP is common for deployments where incoming traffic from the internet is intended to reach an internal server or host behind the firewall which has a private/none route-able IP address. This configuration also known as DNAT This traffic will either require NATing both the IP address and port or just the IP address only.
One case that can cause a problem of policy mismatch is to specify a filter such asa source IP as a filter on the VIP configuration. If that source IP is changed with time or if other IP addresses are required to access the same destination that would create the problem of policy mismatching this traffic.
Example:
Another possibility is in the case of using a VIP where the external port will be translated to a different port number - also known as Port Forwarding - While the firewall policy is configured to accept traffic from the external port only. This will cause the firewall policy to match the traffic however after the DNAT takes effect the result would be a case of traffic will then mismatch that policy after translation possibly showing policy 0 matching the traffic and will therefore be dropped. Here is what the VIP would look like:
This is the config in CLI:
config firewall policy
The logs would look like the following where traffic matches a policy however it is denied by Implicit Deny policy event though policy ID is not mentioned.
Here is a closer look at this event using debug flow commands where traffic matches the DNAT firewall policy then eventually it is rejected by policy 0:
diagnose debug flow filter addr 10.26.10.2 diagnose debug flow filter port 5443 diagnose debug flow show function-name enable diagnose debug enable diagnose debug flow trace start 10 FG40FI-1 # id=65308 trace_id=1 func=print_pkt_detail line=5879 msg="vd-root:0 received a packet(proto=6, 10.26.10.2:61864->10.26.10.1:5443) tun_id=0.0.0.0 from lan. flag [S], seq 1985506046, ack 0, win 64240"
To resolve the above problem the solution is either to remove port forwarding from the VIP configuration or change the firewall policy to allow ALL services.
Another scenario is where a firewall policy is configured to allow a specific service however the service/application has the Source Port option enabled and specified while the actual traffic is using a range or random source ports. The result is a policy mismatch.
Example of this config below:
In some scenarios, FortiGate may deny VIP-based traffic due to an incorrect policy match. This can occur if the source interface filter is misconfigured in the VIP object.
Example:
config firewall vip
If an external interface is defined, the source interface should match it. However, if the external interface is set to 'any', the source interface can include one or multiple interfaces. Refer to this KB article for a detailed explanation Troubleshooting Tip: VIP configured for filtering a specific source interface is getting 'Denied by ...
There are other possibilities, such as the VIP external address being used also in IP Pool configuration while FortiOS is at v7.2.6 or later. The expected default behavior is that the traffic intended for the VIP will be considered local traffic by the firewall intended for one of its interfaces.
This behavior is because both IPPool and VIP addresses are local addresses on the firewall, while an IPPool address has arp-reply enabled by default. A solution to such a case is to disable arp-reply under the IP pool address object using the commands below:
Related article: Technical Tip: IP pool and virtual IP behavior changes in FortiOS 6.4, 7.0, 7.2, and 7.4 |
