NAT and PAT Configuration Scenarios

The rule that matches the interface

Why it fails: Interface matching alone does not decide between overlapping NAT rules; the first rule in the ordered NAT policy that matches the traffic is applied. It is tempting because interface selection is a genuine matching condition, so it feels decisive when rules differ only by interface.

The rule with the lowest priority

Why it fails: Lowest priority is not the selection criterion; overlapping NAT rules resolve by explicit ordering, with the first matching rule applied. It is tempting because priority ordering does govern other rule types, such as policy or QoS rules, where lower numbers take precedence.

The most specific rule

Why it fails: Specificity does not override ordering; NAT rules are evaluated top-down and the first match wins, regardless of how narrow the translation is. It is tempting because longest-prefix and most-specific matching do govern routing decisions, so the logic appears transferable.

Static NAT

Why it fails: Static NAT maps one internal address to one external address, so a /24 cannot collapse to the single IP 203.0.113.50. It is tempting for inbound publishing of a specific server, which is exactly where static NAT belongs, not for many-to-one subnet translation.

Static Identity NAT

Why it fails: Static identity NAT maps each inside address to itself, preserving 10.10.10.x on the outside, so 10.10.10.0/24 is never translated to 203.0.113.50. It is tempting because identity NAT genuinely suits exempting traffic from translation, such as VPN or site-to-site flows, but that is not this requirement.

Dynamic NAT

Why it fails: Dynamic NAT with a single mapped address cannot translate a /24 subnet, since it requires a pool at least as large as the source range. It is tempting for outbound translation, but PAT (dynamic NAT with port address translation) is the type that maps many hosts to one IP.

The FTD must be able to resolve the FMC's hostname via DNS.

Why it fails: While DNS resolution can be used if the FMC is specified by hostname, the registration process typically uses the IP address. If the IP is provided, DNS is not required. However, if the FMC is referenced by hostname, DNS must work. But the question states the FMC IP address is configured, so DNS is not the missing piece.

The FTD must be configured with the same NAT ID as the FMC.

Why it fails: The NAT ID is used when multiple FTDs are behind a NAT device; it must match the NAT ID configured on FMC for that device. However, the question states the NAT ID is already configured correctly. Therefore, this is not the missing setting. The NAT ID is not the same as the FMC's NAT ID; it is a unique identifier for the FTD.

The FTD must have the same time zone as the FMC.

Why it fails: Time zone mismatch does not prevent registration; it may affect log timestamps but not the registration process. NTP synchronization is important for certificate validation, but time zone alone is not a requirement. Registration relies on network connectivity and correct credentials, not time zone settings.

Auto NAT Static

Why it fails: Auto NAT Static translates a mapped address unconditionally for the object it is configured on, so it cannot exempt a subnet from translation. It is tempting because it handles static one-to-one mappings for inside hosts, and would be correct where a server needs a fixed translated address for inbound partner access.

Dynamic PAT

Why it fails: Dynamic PAT translates many inside addresses to one outside address using port multiplexing, which is the opposite of exempting subnets. It is tempting because it conserves public addresses for outbound internet access, and would be correct where numerous internal hosts need to share a single routable address.

Port Address Translation

Why it fails: Port Address Translation rewrites source ports alongside addresses for many-to-one translation, so it actively translates the subnets rather than excluding them. It is tempting because it is the standard mechanism for outbound internet access, and would be correct where internal hosts must share one public address.

To cache DNS responses locally on the FTD control plane

Why it fails: DNS translation rewrites embedded A and PTR records so clients receive addresses matching the NAT translation; caching is handled by the DNS client or resolver, not the NAT rule. The option tempts because FTD does cache some DNS data for inspection, but that is unrelated to the address-rewriting function configured here.

To encrypt DNS queries over TLS (DoT)

Why it fails: DNS translation rewrites A and PTR records inside DNS payloads to match NAT translations; encryption is provided by DoT or DoH, configured separately. The option tempts because both concern DNS security, but NAT translation operates on plaintext record contents, whereas DoT encrypts the transport channel itself.

To block malicious DNS tunneling attempts via Snort inspection

Why it fails: DNS translation rewrites A and PTR records inside inspected DNS payloads so translated addresses resolve correctly; blocking tunnelling is Snort's DNS preprocessor role, not NAT. It tempts because both touch DNS traffic, but they sit at different layers: NAT alters payload addresses, while intrusion inspection detects malicious patterns.

VLAN object

Why it fails: A VLAN object represents a layer-2 broadcast domain and cannot carry the one-to-one public-to-private IP binding static NAT demands. It tempts because VLANs commonly group servers sharing policy, but NAT translation operates on individual IP addresses, so a static NAT object is required here.

Port object

Why it fails: A port object defines a single port or range for service matching, but cannot pair a public address with a private address, so it cannot express a NAT mapping. It is tempting because ports appear in access rules, and would be correct when permitting specific services rather than translating addresses.

Network object (Group)

Why it fails: A network object group bundles multiple addresses for use in one policy, but NAT requires a single static one-to-one binding between one public and one private IP. It tempts because groups simplify rule management when many hosts share identical treatment, yet a lone web server needs a dedicated static NAT object instead.

Virtual

Why it fails: Virtual is not a NAT rule Type in PAN-OS; the editor offers ipv4, nat64, nptv6 and others, with Virtual appearing only as a firewall or router construct. It tempts engineers familiar with virtual routing contexts, yet NAT Type governs address translation family, not virtualisation.

Transparent

Why it fails: Transparent is not a selectable NAT rule Type in PAN-OS; transparency is achieved through the rule's source and destination translation settings, not the Type dropdown. It tempts administrators recalling transparent proxy or bridge modes, but NAT Type instead selects the address family being translated, such as ipv4 or nptv6.

Bottom-up

Why it fails: FTD processes NAT rules from the top of the list downwards, so bottom-up would invert the intended precedence and match the wrong rule. Bottom-up is tempting because some systems evaluate stacked policies from the base upwards, but here the first matching rule in the configured order is applied.

Specific to General

Why it fails: FTD evaluates NAT rules top-down, first match wins, so ordering is manual rather than automatic generalisation. Specific-to-general is tempting because it mirrors how firewall ACLs and routing tables resolve overlapping entries, but NAT relies on the administrator's explicit rule sequence instead of an inherent specificity sort.

Alphabetical

Why it fails: NAT rules are evaluated in a defined top-down order, so alphabetical sorting would break deterministic matching and precedence. Alphabetical ordering is tempting because rule names are often prefixed to group them logically, but that is a naming convention for human readability, not the engine's evaluation sequence.

The HTTPS REST API (TCP 443) handshake fails; debug using 'debug rest-api'.

Why it fails: FTD-FMC registration uses the SFTunnel protocol over TCP 8305, not HTTPS REST on 443; a key mismatch fails that tunnel, so 'debug rest-api' shows nothing. REST API debugging is tempting because FMC exposes it, but it governs configuration, not registration.

The SNMP trap receiver fails; debug using 'system support snmp-debug'.

Why it fails: SNMP traps carry device telemetry and alerts, not the FTD-to-FMC registration exchange, so no trap receiver is involved when the key is rejected. It would be the right area to investigate only if the failure were a missing or malformed event notification reaching a monitoring platform.

The SSH tunnel (TCP 22) fails; debug using 'tail -f /var/log/secure'.

Why it fails: Registration between FTD and FMC runs over a TLS tunnel on TCP 8305, not SSH on TCP 22; /var/log/secure records SSH authentication events only. SSH troubleshooting would be correct if the administrator could not log into the FTD CLI itself.

Prefilter FastPath target

Why it fails: Prefilter FastPath target is a prefilter policy action for bypassing or fast-tracking traffic inspection, not a Translated Source field on a manual NAT rule. It is tempting because it appears in FTD NAT-adjacent configuration screens, but it would be the right choice when defining prefilter rules to skip Snort inspection for trusted flows.

Security Intelligence blacklist feed

Why it fails: A Security Intelligence blacklist feed supplies reputation-based IP and URL blocklists for access control, not address translation. It cannot populate the Translated Source field, which requires an object such as a network object, interface, or literal address. Blacklist feeds would be the right choice when blocking traffic from known malicious sources.

The FTD forces a DNS query to an external server

Why it fails: DNS Rewrite rewrites A-records within DNS replies passing through the FTD; it does not redirect queries to an external resolver. Forwarding is tempting because DNS Rewrite operates on DNS inspection, but the FTD modifies the response payload rather than changing the query's destination server.

The FTD creates a new NAT object

Why it fails: DNS Rewrite alters address records embedded in DNS responses so clients resolve the translated address; it creates no NAT object. Object creation is tempting because NAT rules reference network objects, but DNS Rewrite is a translation behaviour applied to existing rules, not an object-generation mechanism.

The FTD blocks all DNS traffic

Why it fails: DNS Rewrite edits the A-record payload inside DNS replies traversing the FTD, translating the public address to the internal server's real address; it never blocks DNS. Blocking is tempting because DNS Rewrite touches DNS inspection, but that inspection modifies answers rather than dropping queries.

Static IP

Why it fails: Static IP creates a fixed one-to-one mapping between an internal host and a public address, so it cannot hide an entire subnet behind one interface IP. It is the right choice when an internal server must be reachable from outside on a permanent address.

Dynamic IP

Why it fails: Dynamic IP translation maps many internal hosts to a pool of addresses, not one fixed interface IP, so it cannot guarantee the single-address hiding required. It suits outbound internet access where a range of public addresses is available and per-session mapping is acceptable.

Identity NAT

Why it fails: Identity NAT translates an address to itself, leaving original source addresses visible, so it provides no hiding behind the interface IP. It is chosen when traffic must traverse a tunnel without address translation, such as VPN traffic exempted from NAT.

Prefilter FastPath action

Why it fails: FastPath is a prefilter action that bypasses Snort inspection for trusted traffic; it is configured in the prefilter policy, not within a manual NAT rule. Manual NAT requires original and translated packet parameters, such as source and destination interfaces or addresses. FastPath would be relevant when offloading high-volume flows from deep inspection.

Security Intelligence Whitelist

Why it fails: Security Intelligence Whitelist is a separate access control policy object applied to traffic flows, not a parameter of a manual NAT rule. Manual NAT requires Original Packet and Translated Packet definitions specifying source, destination and translated addresses or interfaces. The whitelist would be correct when exempting specific IPs from Security Intelligence blocking.

Snort Inspection Engine Mode

Why it fails: The Snort inspection engine mode is set in the intrusion policy or access control policy, governing how traffic is inspected, not how addresses are translated. A manual NAT rule instead requires original and translated packet criteria. Inspection mode would be the right concern when tuning intrusion prevention depth rather than defining address translation.

Twice NAT (Destination NAT)

Why it fails: Twice NAT, also called manual NAT, can translate source, destination or both, and is used when translation depends on the destination, for example policy NAT or overlapping networks. Translating only the destination, as this option describes, does not meet the requirement, which is to translate the source addresses of one internal subnet. Plain source translation for one subnet is exactly what auto NAT on a network object is designed for.

Prefilter NAT

Why it fails: There is no 'Prefilter NAT' type in Cisco Secure Firewall Threat Defense. Prefilter policies are a separate feature that decides early whether traffic is fast-pathed, blocked or passed on to full inspection, and they do not translate addresses. NAT rules are either auto NAT, defined on a network object, or manual NAT, and for one subnet's source translation, auto NAT is the right choice.

Manual NAT (Identity NAT)

Why it fails: Identity NAT translates an address to itself, so the internal subnet's traffic would leave with its real addresses unchanged. It is used to exempt traffic from other NAT rules, most commonly site-to-site VPN traffic that must keep its original addresses. The requirement here is to translate the source addresses, so identity NAT does the opposite of what is needed.

It replaces the need for security zones in Access Control policies.

Why it fails: Interface objects and security zones serve separate functions: zones are referenced in Access Control policies, while interface objects scope manual NAT rules to a source and destination interface pair. Defining one does not remove the requirement to configure the other for traffic filtering.

It forces the FTD to convert the packet from Layer 2 to Layer 3.

Why it fails: Interface objects identify the source and destination interfaces a manual NAT rule matches; they do not alter packet encapsulation or trigger any Layer 2 to Layer 3 conversion, which the FTD performs regardless of NAT configuration. They exist to scope translation to specific interface pairs.

It enables automatic routing table updates for the translated IP address.

Why it fails: Interface objects only match traffic for NAT translation; they never modify the routing table or advertise translated addresses. Routing to translated IP addresses is handled separately by the FTD's routing configuration, so automatic route updates are not a function of interface objects.