Fortigate uses VIP of down Interface (Bug?)

[smxko]

Some weird behavior I saw today. I'm doing NAT for two VLANs on a branch FGT with two VPN tunnels, so four VIPs in total. Two VIPs for the primary tunnel and two for the backup tunnel. In noticed that only the VIPs that reference the backup tunnel have a hit count (which has always been down so far). I attached a screenshot of that:

Only when I reference the backup VIP in a policy, ping to the VIP works, even though it clearly uses a tunnel that isn't even up! How can that be? When I use the primary VIP in the policy, ping doesn't work bc of implicit deny.

In grouped both IPsec interfaces shown here into a zone, maybe that has something to do with that?

[pminarik]

Packet to a local IP doesn't have to come through its own interface. So likely there was a packet coming in over <another interface> with dst-ip = <VIP[...]backup>, and it was processed like that.

[smxko]

Ok, so basically I don't need backup VIPs, even when ingress traffic for that VIP can originate from a different interface?

[pminarik]

Not necessary, yup.
As a matter of fact, you can just bind the VIPs to "any" interface, and control the access by deciding in which firewall policies you use the VIPs (=> controlling the permitted srcintf). The source tunnel/interface will not matter then, as long as the direction of flow is allowed by a firewall policy.

[smxko]

Ok, thanks. Make sense. I just tried to already steer traffic before the policies by binding ingress traffic to its actual ingress interface. 

It probably uses the first list entry of the VIP table, so that's why only the backup one worked. It uses the backup one but couldn't find the policy, since the policy referenced the primary VIP only.

[pminarik]

That's right! If the VIPs functionally overlap, only the first one will be used.

[smxko]

So what's the actual point of selecting an interface in the VIP config?