NAT64 Overview

NAT64 provides a way to transition to IPv6 while you still need to communicate with IPv4 networks . When you need to communicate from an IPv6-only network to an IPv4 network, you use NAT64 to translate source and destination addresses from IPv6 to IPv4 and vice versa. NAT64 allows IPv6 clients to access IPv4 servers and allows IPv4 clients to access IPv6 servers . You should understand NAT before configuring NAT64.

Simplified Explanation

Imagine you have devices that only speak IPv6, but they need to talk to servers or services that only understand IPv4 (like many websites on the older internet). NAT64 acts as a translator at the network edge (typically your firewall).

In essence, NAT64 bridges the communication gap between IPv6-only and IPv4-only networks, facilitating the gradual transition to IPv6. For the IPv6-to-IPv4 direction, it often works alongside a **DNS64** server , which tricks the IPv6 client into thinking the IPv4 server has an IPv6 address by providing a specially crafted IPv6 address that embeds the real IPv4 address.

Operation Details

You can configure two types of NAT64 translation on a Palo Alto Networks® firewall; each one is doing a bidirectional translation between the two IP address families:

A single IPv4 address can be used for NAT44 and NAT64 ; you don’t reserve a pool of IPv4 addresses for NAT64 only.

NAT64 operates on Layer 3 interfaces, subinterfaces, and tunnel interfaces. To use NAT64 on a Palo Alto Networks firewall for IPv6-initiated communication, you must have a third-party DNS64 Server or a solution in place to separate the DNS query function from the NAT function. The DNS64 server translates between your IPv6 host and an IPv4 DNS server by encoding the IPv4 address it receives from a public DNS server into an IPv6 address for the IPv6 host.

Palo Alto Networks supports the following NAT64 features:

IPv4-Embedded IPv6 Address

NAT64 uses an IPv4-embedded IPv6 address as described in RFC 6052, IPv6 Addressing of IPv4/IPv6 Translators. An IPv4-embedded IPv6 address is an IPv6 address in which 32 bits have an IPv4 address encoded in them . The IPv6 prefix length (PL in the figure) determines where in the IPv6 address the IPv4 address is encoded, as follows:

Structure of an IPv4-Embedded IPv6 Address based on prefix length
IPv4-Embedded IPv6 Address Structure (RFC 6052)

The firewall supports translation for /32, /40, /48, /56, /64, and /96 subnets using these prefixes. A single firewall supports multiple prefixes; each NAT64 rule uses one prefix. The prefix can be the Well-Known Prefix (64:FF9B::/96) or a Network-Specific Prefix (NSP) that is unique to the organization that controls the address translator (the DNS64 device). An NSP is usually a network within the organization’s IPv6 prefix. The DNS64 device typically sets the u field and suffix to zeros; the firewall ignores those fields.

DNS64 Server

If you need to use a DNS and you want to perform NAT64 translation using IPv6-Initiated Communication, you must use a third-party DNS64 server or other DNS64 solution that is set up with the Well-Known Prefix or your NSP. When an IPv6 host attempts to access an IPv4 host or domain on the internet, the DNS64 server queries an authoritative DNS server for the IPv4 address mapped to that host name. The DNS server returns an Address record (A record) to the DNS64 server containing the IPv4 address for the host name.

The DNS64 server in turn converts the IPv4 address to hexadecimal and encodes it into the appropriate octets of the IPv6 prefix it is set up to use (the Well-Known Prefix or your NSP) based on the prefix length, which results in an IPv4-Embedded IPv6 Address. The DNS64 server sends an AAAA record to the IPv6 host that maps the IPv4-embedded IPv6 address to the IPv4 host name.

Path MTU Discovery

IPv6 does not fragment packets in-transit like IPv4 routers can, relying instead on endpoints adjusting their packet size based on Path MTU Discovery (PMTUD). The firewall uses two methods to handle potential MTU issues during NAT64 translation:

05-19-2025-diagram_1

IPv6-Initiated Communication Flow (with DNS64)

This diagram illustrates how an IPv6 client connects to an IPv4 server using NAT64 and DNS64.

05-19-2025-diagram_2

Explanation:

  1. The IPv6 client asks the DNS64 server for the IPv6 address (AAAA record) of an IPv4-only site.
  2. The DNS64 server asks the regular DNS for the IPv4 address (A record).
  3. The regular DNS replies with the IPv4 address.
  4. The DNS64 server creates a fake IPv6 address by combining a special prefix (like the Well-Known Prefix 64:FF9B::/96) with the IPv4 address encoded within it. It sends this synthetic AAAA record back to the client.
  5. The IPv6 client sends its packet towards this synthetic IPv6 destination address.
  6. The NAT64 firewall intercepts the packet. It translates the client's IPv6 source address to an IPv4 address from its pool (Dynamic IP and Port). It extracts the *real* IPv4 destination address from the synthetic IPv6 destination address.
  7. The firewall forwards the translated packet (now fully IPv4) to the IPv4 server.
  8. Return traffic follows the reverse path, with the firewall using its state table to translate addresses back to IPv6 for the client.
Diagram showing DNS64 resolution process for IPv6 client accessing IPv4 server
DNS64 Name Resolution Process
Diagram showing NAT64 firewall translating IPv6 initiated packet to IPv4
NAT64 Translation for IPv6-Initiated Communication

IPv4-Initiated Communication Flow

This diagram shows an external IPv4 client connecting to an internal IPv6 server via NAT64.

05-19-2025-diagram_3

Explanation:

  1. An external IPv4 client sends a packet to a public IPv4 address configured on the firewall for NAT64 destination translation.
  2. The NAT64 firewall intercepts the packet based on a matching NAT policy.
  3. It translates the IPv4 source address into an IPv4-embedded IPv6 address using a prefix like 64:FF9B::/96.
  4. It translates the public IPv4 destination address to the pre-configured internal IPv6 server address (Static IP translation) . Port translation can also occur here if configured.
  5. The firewall forwards the translated packet (now fully IPv6) to the internal IPv6 server.
  6. Return traffic follows the reverse path, with the firewall translating addresses back to IPv4 for the external client.
Diagram showing NAT64 for IPv4 initiated communication to an IPv6 server
NAT64 for IPv4-Initiated Communication

Configure NAT64 for IPv6-Initiated Communication

This configuration task and its addresses correspond to the figures in IPv6-Initiated Communication.

Beginning with PAN-OS 10.1.6, you can enable persistent NAT for DIPP to mitigate the compatibility issues that symmetric NAT may have with applications that use STUN.

  1. Enable IPv6 to operate on the firewall.
    1. Select Device > Setup > Session and edit the Session Settings.
    2. Select Enable IPv6 Firewalling .
    3. Click OK .
  2. Configure the necessary interfaces with IPv6 addressing.
    1. Configure the internal-facing (Trust) interface: Select Network > Interfaces > Ethernet and select the interface. On the IPv6 tab, select Enable IPv6 address on interface and Add your internal IPv6 prefix (e.g., 2001:DB8::/64 ).
    2. Configure the external-facing (Untrust) interface: Select the interface. On the IPv4 tab, assign the IPv4 address to be used for NAT (e.g., 192.0.2.1/24 ). Ensure IPv4 connectivity is established.
  3. Create an address object for the IPv6 destination address prefix (pre-translation).
    1. Select Objects > Addresses and click Add .
    2. Enter a Name for the object, for example, nat64-prefix-wkp .
    3. For Type , select IP Netmask and enter the IPv6 prefix used by DNS64 , with a netmask compliant with RFC 6052 (/32, /40, /48, /56, /64, or /96). This is either the Well-Known Prefix or your Network-Specific Prefix. For this example, enter 64:FF9B::/96 .
    4. Click OK .

    (You don't enter a full destination address because, based on the prefix length, the firewall extracts the encoded IPv4 address from the original destination IPv6 address in the incoming packet.)

  4. (Optional) Create an address object for the internal IPv6 source network (pre-translation).
    1. Select Objects > Addresses and click Add .
    2. Enter a Name for the object, e.g., Internal_IPv6_Net .
    3. For Type , select IP Netmask and enter the address of the internal IPv6 network, e.g., 2001:DB8::/64 .
    4. Click OK .
  5. (Optional) Create an address object for the translated IPv4 source address pool if not using the interface address.
    1. Select Objects > Addresses and click Add .
    2. Enter a Name for the object, e.g., NAT64_IPv4_Pool .
    3. For Type , select IP Netmask (or Range) and enter the IPv4 address(es) to be used for translation, e.g., 192.0.2.1/32 .
    4. Click OK .
  6. Create the NAT64 rule.
    1. Select Policies > NAT and click Add .
    2. On the General tab, enter a Name for the NAT64 rule, for example, nat64_ipv6_initiated .
    3. (Optional) Enter a Description .
    4. For NAT Type , select nat64 .
  7. Specify the original source and destination information (Original Packet tab).
    1. For Source Zone , Add the zone where your IPv6 clients reside (e.g., Trust).
    2. For Destination Zone , select the zone associated with the NAT64 prefix via the tunnel interface (e.g., Untrust).
    3. (Optional) Select a Destination Interface (usually any unless specific routing is needed).
    4. For Source Address , select Any or Add the address object for your internal IPv6 network (e.g., Internal_IPv6_Net ).
    5. For Destination Address , Add the address object you created for the NAT64 prefix (e.g., nat64-prefix-wkp ).
    6. (Optional) For Service , select any or specify services if needed.
  8. Specify the translated packet information (Translated Packet tab).
    1. Under Source Address Translation , for Translation Type , select Dynamic IP and Port (for stateful NAT64).
    2. For Address Type , do one of the following:
      • Select Translated Address and Add the address object for the IPv4 pool (e.g., NAT64_IPv4_Pool ).
      • Select Interface Address , then select the firewall's external (Untrust) Interface and optionally specify an IP Address if the interface has multiple.
    3. Leave Destination Address Translation unselected (set to None ). The firewall derives this automatically from the original destination packet and the NAT64 prefix.
    4. Click OK to save the NAT64 policy rule.
  9. Configure a tunnel interface to handle routing for the NAT64 prefix.
    1. Select Network > Interfaces > Tunnel and Add a tunnel.
    2. For Interface Name , enter a numeric suffix, such as tunnel.64 .
    3. On the Config tab, select the Virtual Router used for your external routing.
    4. For Security Zone , select the destination zone where the IPv4 servers reside (e.g., Untrust).
    5. On the IPv6 tab, select Enable IPv6 on the interface .
    6. Click Add under Addresses.
    7. Enter the NAT64 prefix (e.g., 64:FF9B::/96 ). You might need to create a temporary address object or just type it in, depending on the PAN-OS version's UI flexibility here. *Assigning an actual address from the prefix like 64:FF9B::1/96 might be required by the UI, even though it's just for routing association.*
    8. Click OK .
    9. Click OK again to save the tunnel interface configuration.
    10. **Crucially:** Add a static route for the NAT64 prefix pointing to this tunnel interface. Go to Network > Virtual Routers > [Your Router] > Static Routes > IPv6 . Add a route for 64:FF9B::/96 (or your NSP prefix) with the Interface set to the tunnel you just created (e.g., tunnel.64 ) and Next Hop type as None . This directs traffic destined for the synthetic prefix towards the correct zone via the tunnel.
  10. Create a security policy to allow the translated traffic.
    1. Select Policies > Security and Add a rule.
    2. Give it a Name (e.g., Allow_NAT64_Outbound ).
    3. On the Source tab, select the Source Zone (e.g., Trust) and specify the Source Address (e.g., Internal_IPv6_Net or Any ).
    4. On the Destination tab, select the Destination Zone (e.g., Untrust). For Destination Address , you can specify Any (as the final destination is IPv4) or be more specific if possible. *Note: The Security Policy evaluates the packet *after* NAT lookup but often *before* the final translation occurs for new sessions, so matching based on original packet zones and addresses is typical.* Some versions might require matching the NAT64 prefix in the destination here if zone determination relies on it before NAT policy applies fully. Test carefully. The most reliable is usually Source Zone Trust -> Destination Zone Untrust.
    5. On the Application and Service/URL Category tabs, specify allowed applications/services (e.g., web-browsing , ssl , or any ).
    6. On the Actions tab, set the Action to Allow .
    7. Click OK .
  11. Commit your changes.
    1. Click Commit .
  12. (PAN-OS 10.1.6+) Optionally enable persistent NAT for DIPP via CLI.
    1. Access the CLI.
    2. Run: set system setting persistent-dipp enable yes
    3. Run: request restart system (Requires system reboot)
    4. If using HA, repeat on the peer after rebooting the first.
  13. Troubleshoot or view a NAT64 session via CLI.
    1. Access the CLI.
    2. Run: show session id
    3. Look for flags indicating NAT64 and inspect the translated addresses.

Configure NAT64 for IPv4-Initiated Communication

IPv4-initiated communication to an IPv6 server is similar to destination NAT in an IPv4 topology. The destination IPv4 address (usually a public IP on the firewall) maps to the internal destination IPv6 address through a one-to-one, static IP translation .

The firewall encodes the source IPv4 address into an IPv4-embedded IPv6 prefix (like the Well-Known Prefix 64:FF9B::/96 as defined in RFC 6052) for the translated source. The translated destination address is the actual IPv6 address of the internal server. The use case for IPv4-initiated communication is typically when an organization is providing access from the public, untrust zone (IPv4 world) to an internal IPv6 server in the organization's DMZ or Trust zone. This topology does not typically require a DNS64 server for the connection itself.

  1. Enable IPv6 to operate on the firewall.
    1. Select Device > Setup > Session and edit the Session Settings.
    2. Select Enable IPv6 Firewalling .
    3. Click OK .
  2. (Optional) Configure MTU handling for IPv4 DF=0 packets.
    1. Select Device > Setup > Session and edit Session Settings.
    2. Set NAT64 IPv6 Minimum Network MTU (range is 1280-9216, default is 1280) as needed. Lower values cause more pre-fragmentation of IPv4 packets before translation. Setting it high (e.g., 9216) minimizes pre-fragmentation, relying more on PMTUD ICMP messages if needed.
    3. Click OK .
  3. Create an address object for the public IPv4 destination address (pre-translation). This is the address external clients will connect to.
    1. Select Objects > Addresses and click Add .
    2. Enter a Name , e.g., Public_IPv4_for_Server .
    3. For Type , select IP Netmask and enter the public IPv4 address. It must use no netmask or a /32 netmask only for static destination NAT. Example: 198.51.19.1/32 .
    4. Click OK .
  4. Create an address object for the NAT64 prefix to be used for the *translated source* address. This is the prefix the firewall will use to embed the original IPv4 source.
    1. Select Objects > Addresses and click Add .
    2. Enter a Name , e.g., nat64-prefix-wkp .
    3. For Type , select IP Netmask and enter the NAT64 IPv6 prefix with a compliant netmask (e.g., /96). Example: 64:FF9B::/96 .
    4. Click OK .

    (The firewall uses this prefix and embeds the original IPv4 source address into it to create the translated IPv6 source address, e.g., 64:FF9B::C001:0208 if the source was 192.1.2.8 ).

  5. Create an address object for the internal IPv6 destination server address (translated). This is the real internal address of the server.
    1. Select Objects > Addresses and click Add .
    2. Enter a Name , e.g., Internal_IPv6_Server .
    3. For Type , select IP Netmask and enter the actual IPv6 address of the internal server. The address must use no netmask or a /128 netmask only for static destination NAT. Example: 2001:DB8::2/128 .
    4. Click OK .
  6. Create the NAT64 rule. This defines the overall translation behavior.
    1. Select Policies > NAT and click Add .
    2. On the General tab, enter a Name , e.g., nat64_ipv4_initiated .
    3. For NAT Type , select nat64 .
  7. Specify the original packet information (Original Packet tab). This determines which incoming packets the rule will match.
    1. For Source Zone , Add the zone where external IPv4 clients reside (e.g., Untrust).
    2. Select the Destination Zone (usually the Untrust zone as well, as the destination IP is on the firewall's external interface).
    3. For Source Address , select Any or specify allowed external IPv4 source networks/addresses (e.g., Any , or a specific range like 192.1.2.0/24 ).
    4. For Destination Address , Add the address object for the public IPv4 address (e.g., Public_IPv4_for_Server , representing 198.51.19.1 ).
    5. For Service , select any or the specific service(s) the server offers (e.g., service-http , service-https ).

    8. At this point, the firewall knows to look for packets coming from the Untrust zone, going to the Untrust zone destination address 198.51.19.1 (or the object Public_IPv4_for_Server ), and potentially for specific services.

    05-19-2025-diagram_4
  8. Specify the translated packet information (Translated Packet tab). This defines how the source and destination addresses (and potentially ports) will be changed.
    1. Under Source Address Translation , set Translation Type to Static IP . This is the key step for the source translation in this scenario.
    2. For Translated Address , select the address object representing the NAT64 prefix (e.g., nat64-prefix-wkp , representing 64:FF9B::/96 ). The firewall will automatically embed the original source IPv4 into this prefix to create the translated IPv6 source address (e.g., 64:FF9B::C001:0208 if original source was 192.1.2.8 ).
    3. Under Destination Address Translation , for Translated Address , specify the address object for the internal IPv6 server (e.g., Internal_IPv6_Server , representing 2001:DB8::2/128 ). This is the static, one-to-one mapping for the destination.
    4. (Optional for Port Translation - see next section) Leave Translated Port blank for direct port mapping.
    5. Click OK .

    9. Now the firewall knows how to translate the packet once it matches the rule.

    05-19-2025-diagram_5

    The translated packet is now sent towards the internal IPv6 server. The server responds, and the firewall uses its session state (created by the NAT rule) to perform the reverse translation automatically.

  9. Create a security policy to allow the traffic to the internal server. This policy acts as a firewall rule, permitting or denying the traffic after the NAT lookup determines the destination zone.
    1. Select Policies > Security and Add a rule.
    2. Give it a Name (e.g., Allow_NAT64_Inbound ).
    3. On the Source tab, select the Source Zone (e.g., Untrust) and specify allowed Source Address es (e.g., Any ).
    4. On the Destination tab, select the Destination Zone where the IPv6 server resides (e.g., DMZ or Trust). For Destination Address , specify the *original* public IPv4 address object ( Public_IPv4_for_Server , representing 198.51.19.1 ). The security policy typically matches on the original destination before NAT redirects it internally.
    5. On the Service/URL Category tab, specify the allowed Service(s) (matching the NAT rule).
    6. On the Actions tab, set the Action to Allow .
    7. Click OK .

    10. This security rule now permits the traffic matching the original source/destination from the Untrust zone to the internal zone.

    05-19-2025-diagram_6
  10. Commit your changes.
    1. Click Commit .
  11. (PAN-OS 10.1.6+) Optionally enable persistent NAT for DIPP via CLI.
    1. Access the CLI.
    2. Run: set system setting persistent-dipp enable yes
    3. Run: request restart system (Requires system reboot)
    4. If using HA, repeat on the peer after rebooting the first.
  12. Troubleshoot or view sessions as needed.
    1. Access the CLI.
    2. Run: show session id

Configure NAT64 for IPv4-Initiated Communication with Port Translation

This task builds on the previous configuration (IPv4-Initiated Communication), but adds port translation . This is useful if the organization wants to expose a service on a standard external port (e.g., 8080) but have it map to a different internal port on the IPv6 server (e.g., 80). This can obscure the internal port usage.

To achieve this, you modify the NAT64 rule:

Diagram showing NAT64 with port translation for IPv4 initiated communication
NAT64 for IPv4-Initiated Communication with Port Translation
  1. Follow steps 1-6 from the "Configure NAT64 for IPv4-Initiated Communication" section (Enable IPv6, configure MTU, create address objects for Public IPv4 Dest, NAT64 Prefix, and Internal IPv6 Server Dest).
  2. Modify the NAT64 rule creation (Steps 7 & 8 from the previous section):
    1. When configuring the **Original Packet** tab (Step 7):
      • For Service , instead of any or service-http , click Add or select an existing Service object that defines the *external* port . For example, create a service named tcp-8080 for Protocol TCP and Destination Port 8080. Select this service.
    2. When configuring the **Translated Packet** tab (Step 8):
      • Specify Source Address Translation (Static IP, using NAT64 prefix) and Destination Address Translation (using Internal IPv6 Server address object) as before.
      • In the **Destination Address Translation** section, enter the *internal* port number in the **Translated Port** field . For this example, enter 80 .
    3. Click OK to save the NAT rule.
  3. Modify the Security Policy (Step 9 from the previous section):
    1. Ensure the Security policy rule allows traffic based on the *original* destination port specified in the NAT rule's **Original Packet** tab. So, in the Service/URL Category tab of the security rule, you would select the service object representing the external port (e.g., tcp-8080 ). The security policy checks the packet before the port is translated by NAT.
  4. Commit your changes.
  5. Troubleshoot or view sessions as needed.

Test Your Knowledge: NAT64 Quiz

1. What is the primary purpose of NAT64?

2. For IPv6-initiated communication to an IPv4 server, what type of NAT64 is typically used on Palo Alto Networks firewalls?

3. What component often works with NAT64 to allow IPv6-only clients to resolve hostnames of IPv4-only servers?

4. What is an "IPv4-embedded IPv6 address" used in NAT64?

5. For IPv4-initiated communication to an internal IPv6 server using NAT64, how is the internal IPv6 server typically specified in the NAT rule's translated packet?

6. Which NAT64 prefix is designated as the "Well-Known Prefix" in RFC 6052?

7. If a NAT64 rule is configured for IPv4-initiated communication with destination port translation, mapping external TCP port 443 to internal TCP port 8443, what port should the corresponding Security Policy rule allow?

8. What purpose does the "NAT64 IPv6 Minimum Network MTU" setting serve?

9. Why might a tunnel interface be configured and associated with the NAT64 prefix for IPv6-initiated communication?

10. Can a single external IPv4 address on the firewall be used simultaneously for both traditional NAT44 and NAT64 translations?