A work-order dispatch application at a utility's back-office site listens on TCP port 8443 instead of the standard HTTPS port, and no built-in FortiOS service object matches it. A field crew's laptops need a policy that permits only that exact application traffic, nothing broader. What should the engineer configure to match this traffic precisely?

FortiOS lets an administrator define a custom TCP/UDP service object specifying an exact destination port or port range, and a firewall policy's service field accepts that custom object the same way it accepts a built-in one like HTTPS. Building a service object for TCP/8443 is the precise, minimal way to match this dispatch traffic without also matching unrelated HTTPS sessions on port 443 or leaving the policy overly permissive. The built-in HTTPS service object is bound to port 443 specifically; it does not automatically expand to cover TLS traffic wherever it appears, so using it here would simply fail to match the dispatch application's actual port. Application-control signatures identify traffic by behavioral and protocol fingerprinting inside a security profile, they are not something a policy's service field accepts, and conflating the two mixes up service matching (which port/protocol) with application identification (which app, regardless of port). A virtual IP with port forwarding solves a destination-NAT problem, translating an external address and port to an internal server, and has nothing to do with restricting which service a policy permits from the source side; that placement doesn't make sense operationally. To confirm the custom service is matching correctly, the engineer can review the policy's traffic log entries and check that the recorded destination port is exactly 8443, not a broader range.