A vendor's field-diagnostic application on a utility crew's laptop requires that its outbound source port never change across the life of a session, because the receiving cloud service correlates requests by the exact source port the client first used. The laptop's traffic already passes through an overload IP pool shared with other crew laptops. What NAT adjustment addresses the application's requirement, and what does it cost?

The fixed port option on a NAT policy instructs FortiOS to preserve the original source port through translation instead of reassigning it to an available port in the pool, which directly satisfies an application that correlates sessions by the client's original source port. The trade-off is real: overload pools normally gain their sharing capacity by freely reassigning ports across many hosts, and fixed port removes that flexibility for the affected traffic, shrinking how many simultaneous sessions the shared pool can support without port collisions. Switching only that laptop to a one-to-one mapping would give it a dedicated address, but a dedicated address does not, by itself, preserve the original source port, one-to-one address mapping and source-port preservation are independent settings, not the same feature. Port block allocation guarantees a host a defined range of ports to draw from, but it does not guarantee that any specific session retains its exact original port; it manages a block for logging and capacity purposes, not port-for-port preservation. And overload pools do not preserve source ports by default, reassigning source ports to disambiguate shared-address sessions is the core mechanism that makes an overload pool work at all, so assuming ports are already preserved would leave the application's requirement unmet. To confirm the fix, the engineer checks the session table for that laptop's sessions and verifies the translated source port matches the port the application originally used.