| Solution |
To summarize the main difference between using 'any' vs. a specific network interface for Virtual IP listening interfaces:
- Setting the VIP Interface to 'any' allows the VIP to apply to any interface for the purposes of incoming Destination NAT (DNAT) as well as outgoing Source NAT (SNAT, where enabled).
- Setting the VIP to a specific interface (for example, wan1, internal1, dmz, etc.) results in the FortiGate only applying the VIP to traffic incoming/outgoing via the specified interface.
- To see a demonstration of the above behavioral differences, check out the following KB article regarding Hairpin NAT on the FortiGate: Technical Tip: Configuring Hairpin NAT (VIP).
It is important to point out that while VIPs are primarily used for performing DNAT, they are also used for outgoing Source NAT (SNAT). When traffic meets certain conditions, that traffic can be Source NAT'd to the VIP's external IP address, rather than the Outgoing Interface Address or IP Pool address. Refer to this KB article for an in-depth explanation of these conditions: Technical Tip: Mapping VIP outbound connections (Source NAT).
Pitfalls when using 'any' interface for Virtual IP.
When the above behaviors are combined (i.e., traffic can be SNAT'd to the VIP's external IP address, and VIPs set to 'any' can affect ALL interfaces), there is potential for disruptive and unintended behavior. Consider the following example scenario:
- The FortiGate is configured with a WAN interface, a DMZ interface, and an internal LAN interface.
- Firewall Policies have been configured for LAN to WAN as well as DMZ to LAN. Notably, the LAN to WAN policy has Source NAT enabled and set for the Outgoing Interface Address.
- A VIP is configured with the 'any' interface and applied to the DMZ to the LAN policy. The External IP is set to 10.0.0.100, and the Mapped IP is set to the LAN Host (172.16.0.100).
- The admin in this scenario wants the following outcomes:
- The DMZ host should be able to initiate traffic to the LAN host using destination 10.0.0.100 (which DNATs to 172.16.0.100).
- The LAN host should be able to initiate traffic to the Internet and be SNAT'd to FortiGate's WAN public IP address.
After everything is configured in the above scenario, the following behavior is observed during testing:
- When the DMZ Host sends traffic to 10.0.0.100, the FortiGate translates the destination to 172.16.0.100 and sends it to the LAN Host successfully (Good).
- When the LAN host sends traffic to the Internet via the WAN interface, it will fail to receive any responses from Internet destinations (Bad).
After some troubleshooting, the admin finds that the LAN host's traffic arrives on the FortiGate and is Source NAT'd to 10.0.0.100, rather than the FortiGate's outgoing WAN interface address.
In this scenario, the conditions have been met for using the 'any' VIP's External Address for outgoing Source NAT (Traffic sourced from 172.16.0.100 that is egressing 'any' interface using a Firewall Policy with SNAT enabled), so the LAN Host is SNAT'd to the VIP address rather than the Outgoing Interface Address of the WAN interface.
If a specific interface is set on the VIP instead of 'any' (for example, using the DMZ interface instead), then this issue would not have occurred, and traffic going from LAN to WAN would instead use the WAN interface address for Source NAT.
Workarounds and Recommendations:
- Where possible, use specific interfaces for VIPs rather than the 'any' interface. This limits the scope where the VIP is applied and prevents unintended behaviors.
With a specific interface, the VIP will only take effect (for both DNAT and SNAT) when traffic crosses through the specified interface.
- If the 'any' interface is required, then use the srcintf-filter CLI option to specify which interfaces should apply to the VIP (any non-specified interfaces will not trigger the VIP). This affects both DNAT and SNAT and is a useful tool for limiting unexpected VIP usage.
Note that this is a CLI-only option and is not visible from the GUI, so it is recommended to add comments or documentation to note that this has been configured.
config firewall vip
edit <vip_name>
set srcintf-filter <space-delimited entries>
next
end
- If a quick workaround is required, an IP Pool can be used:
- Create an IP Pool with the desired Source NAT address to be used under Policy & Objects -> IP Pools, then modify the outgoing Firewall Policy NAT settings from 'Use Outgoing Interface Address' to 'Use Dynamic IP Pool'
- By default, IP Pools will override the VIP External Address for Source NAT'ing (order of preference for SNAT: IP Pool, then Virtual IP, then Outgoing Interface Address).
- For more info regarding IP Pools vs. VIP External Address vs. Outgoing Interface Address for Source NAT, refer to the bottom-most section of the following KB article: Technical Tip: Mapping VIP outbound connections (Source NAT).
|
