FortiGate Virtual IPs without Reference

Migrating from Juniper ScreenOS firewalls to FortiGates, there are some differences to note with static NATs, i.e., Mapped IPs (MIPs) on a Netscreen and Virtual IPs (VIPs) on a FortiGate. While the Juniper MIPs on an interface are always used by the firewall whenever a packet traverses the interface, the virtual IP objects on a FortiGate must be used at least once in the security policy before they are really used by the firewall.

Issue

I faced an issue (or let’s say, a configuration mistake) with some Virtual IP (VIP) objects: (Tested with a FortiGate 500D with firmware version v5.2.7, build718.)

  • Many VIPs were configured but not all of them were used in the security policy, i.e., had a reference counter of 0.
  • A global rule allows basic Internet usage with source-NAT of “Use Outgoing Interface Address”.
  • Only those servers which VIP was used in the policy (even though on other rules!) used the correct virtual IP for outgoing connections.
  • All servers which VIP was not used in the policy simply used the mere interface IP address.
  • Note that in any case a global policy rule was used for outgoing connections, not that one which used the VIP object. That is, the VIP must only be referenced once in the complete security policy and is then used for all outgoing connections, regardless of the used policy rule.

(On a Juniper SSG firewall, the MIPs were used for all outgoing connections, no matter if there even existed one policy referring to this MIP.)

Workaround

I created a workaround for this case. I configured a dummy rule for incoming connections to this VIP in order to reference the VIP object at least once in the security policy rule set. Therefore all outgoing connections from the internal servers are correctly source-NATed to their corresponding virtual IPs. With this workaround, all global policy rules must not be altered to use different IP pools or the like.

Let’s have a look at the following screenshots. See the descriptions below them:

Note that the “Central NAT” could probably solve this issue but would require some other configurations. Each inside host would need its own IP pool with one single untrust IP address referenced in this central NAT rule. Furthermore, each security policy would need a clone of itself, one with the “Central NAT” and one with the “Use Outgoing Interface Address”.

The “set nat-source-vip {disable|enable}” CLI config within the “config firewall vip” is not helping here. It was no difference between an enabled or disabled command.

Links

Featured image “Facepalm” by David Fant is licensed under CC BY 2.0.

Leave a Reply

Your email address will not be published. Required fields are marked *