One Policy Package for Two Hardware Interface Layouts
Contoso has 30 stores in one ADOM. Twenty-two stores use FortiGate 100F firewalls whose WAN and LAN interfaces are named port1 and port2. Eight new stores use a different FortiGate model whose interfaces are named wan1 and internal1. All stores share policy package Retail-Base, which contains two firewall policies, a VIP, and a central SNAT pool. The package installs correctly to the 22 existing stores. Installing to the 8 new stores fails with interface mapping errors. The new stores also need different public NAT addresses: 198.51.100.20 through 198.51.100.27, while the package currently uses 203.0.113.10. The team wants to keep one package and avoid touching the 22 working stores. They also want to avoid renaming interfaces on the new devices because local technicians use those names in troubleshooting.
1. What is the immediate cause of the install failure, and which fix is the best long-term choice?
Read the worked answer
The package is written against interface names port1 and port2. At install time FMG resolves those names against each target device; the new model has wan1 and internal1, so resolution fails. Options: (a) per-device interface mapping in the install wizard, mapping port1 to wan1 and port2 to internal1 for the eight devices; (b) create firewall zones such as WAN-ZONE and LAN-ZONE in the package and assign physical interfaces to those zones per device; (c) a separate package for the new model; (d) rename interfaces on the new devices. For a quick, low-touch fix, mapping is acceptable. For the long term, zones are better because the policy package stops depending on hardware naming. Renaming is the weakest option here because local technicians rely on the existing names and it can break other references. A separate package doubles maintenance and drift.
2. How should the different public NAT addresses be handled without changing the 22 working stores?
Read the worked answer
The SNAT pool is an object reference. Use per-device mapping on the IP pool object: keep the package default 203.0.113.10, then map that object to 198.51.100.20 for store 1, .21 for store 2, and so on. The mapped values must be the same object type and must be valid on each device. Scope the mapping to the eight new devices only so the 22 existing stores keep 203.0.113.10. If the package uses central SNAT, the policy NAT setting references the pool, so mapping the pool is enough; no policy clone is needed. Before install, use Install Preview to confirm the resolved pool per device, and after install check the device's config firewall ippool and policy NAT. If the stores also need different VIPs, map those objects the same way rather than creating eight packages.
3. What checks should be performed before and after install to prove the mappings did not affect the existing stores?
Read the worked answer
Before install: run Install Preview for all 30 devices and check interface and object resolution; confirm the eight new devices are in the install target and that the existing 22 are not receiving unintended mapping changes. Check that the mapped interfaces or zones are administratively up and in the correct VDOM. After install: verify the new stores have the expected WAN IP and NAT behavior, and spot-check two existing stores to prove their NAT did not change. Compare policy IDs and hit counts. Keep a copy of the Install Preview and device revision. If a mapping is wrong, correct the per-device mapping and reinstall only the affected devices; do not edit the shared object, which would force a reinstall to all 30.