A network engineer configures a virtual IP mapping a public WAN address to a substation console's private address, expecting that creating the VIP object alone is enough to let the vendor's traffic reach the console. After saving the VIP, vendor connection attempts still fail with no matching traffic appearing in any explicit policy's log. What additional step does FortiOS require before this VIP actually forwards traffic?

A virtual IP object exists purely to define an address (and optional port) translation mapping; it does not, by itself, grant permission for any traffic to pass through the FortiGate. An inbound firewall policy must still be created with the VIP referenced as the destination address, and that policy is evaluated the same way any other policy is, interface, source, service, and schedule must all match, and the policy's action must be accept, before the translation defined by the VIP is ever applied to a session. Without that policy, inbound connection attempts toward the VIP's public address fall through to the implicit deny, which explains both the connection failures and the absence of matching entries in any explicit policy's log, since no explicit policy ever saw the traffic. A VIP does not require binding as a secondary IP on the WAN interface; FortiOS handles the address mapping through its NAT and proxy-ARP mechanisms internally once a policy references the VIP, with no manual interface-level step required. VIPs also are not added into IP pools, IP pools are a separate source-NAT construct for outbound sessions, and mixing the two objects together isn't a supported or meaningful configuration step. The direct fix is to create, or verify, an inbound policy with the VIP as its destination and confirm, after the fix, that inbound sessions to the public address now show accepted entries in the policy's traffic log.