Description
The purpose of this article is to explain why adding a VIP object can disrupt service even though the VIP is not applied to any security policy.
"FortiGate_1" VIP configuration:
config firewall vip
edit "VIP_1"
set extip 200.200.200.200
set extintf "wan1"
set mappedip 192.168.0.100
end
Scenario:
- New Virtual IP "VIP_1" was created on "FortiGate_1", but it wasn't still applied to any firewall policy.
- "VIP_1" external IP is the same as IP address of existing "Remote Server" on "Site_2" (200.200.200.200).
- "VIP_1" mapped IP is 192.168.0.100 which belongs to the "Local Network" workstation on "Site_1".
- "FortiGate_1" has working route for IP 200.200.200.200 in its routing table.
- However "Remote Server" became unreachable immediately for any users (LAN and Internet).
- After deleting "VIP_1" object from "FortiGate_1" the "Remote Server" became reachable again for all users.
Analysis:
Why does a VIP entry, that is not applied to any policy, cause traffic destined to 200.200.200.200 to drop?
From the FortiGate unit's point of view, the firewall VIP entry is seen as a local IP address and therefore affects the routing of traffic to the external IP defined in the VIP.
When creating a new VIP entry always take into account the following:
1. Every VIP object created on a FortiGate is counted as a local logical IP address since the moment of its creation (VIP answers on ARP requests by default).
2. VIP entries are used to translate destination IP addresses of the packets (every VIP object is considered as a "Destination NAT" operation).
3. "Destination NAT" operation is always performed before any "Routing" operations (VIP forwards traffic from the "external" IP address to the "mapped" IP address).
Even if a VIP entry is not applied to any policy, it obeys the rules above.
Whether or not there is a matching policy only determines whether traffic is successfully forwarded to the local server.
