Deploy and Configure
Deployment moves the design into configuration: initial access (management interface, bootstrap/Zero Touch Provisioning, or Panorama onboarding), licensing and content activation, then interfaces and zones, virtual routers and routing (static, OSPF, BGP, policy-based forwarding), security policy, NAT, identity, and high availability.
Policy construction is the heart of this domain. Rules are evaluated top-down, first match wins, and end with implied intra-zone and inter-zone deny rules. The service column matters: application-default restricts to the application's standard ports, while any opens the rule to all ports - a frequent trap when a rule "works" in a lab and fails in production. Application identification improves as the session progresses, so a rule permitting a broad application can behave differently than one permitting a specific app.
NAT order is another classic trap. For a new session the firewall processes ingress, then destination NAT, then policy lookup, then security profiles, then source NAT, then egress. Because policy is evaluated after destination NAT, rules must reference the post-translation (pre-NAT for source) addresses correctly. In HA, HA1 carries control/heartbeat traffic, HA2 synchronizes sessions and configuration, and both peers must match on licensing, content versions, and key settings or the commit will warn or fail.
Panorama workflows: commit to Panorama, then push to devices - a Panorama commit alone changes nothing on the firewall.
Worked example: a web server is published on a public IP and users report it unreachable. Verify the destination NAT rule translates to the correct internal address, confirm the security rule references the post-NAT destination zone and address, and confirm the return path exists in the routing table.