How to Configure NAT64 on Palo Alto Firewalls - IPv6 to IPv4 Translation

Printer Friendly Page

Overview

This document describes how to configure NAT64 on a Palo Alto Networks firewall.

 

Details

NAT64 enables IPv6 hosts to communicate with IPv4 hosts. A NAT64 equivalent address for an IPv4 destination is formed by combining the 32 bit IPv4 address with the Well-Known Prefix 64:ff9b::/n for NAT64 as outlined in RFC 6052.

 

This implementation needs a DNS64 server that the IPv6 client can communicate with to synthesize AAAA records from A records. The DNS64 server is responsible for doing an IPv4 lookup for the destination and then returning an equivalent IPv6 address (AAAA) to the client by appending the well known prefix. The client then sends the packet with:

  • Src IP = Configured IPv6 address
  • Dst IP = IPv4 embedded IPv6 address returned by DNS64 server

When the firewall receives this packet, both the Src IP and Dst IP are translated into IPv4 addresses.

        

Note:  Though this example shows how to implement NAT64 with a DNS64 server, the firewall is capable of performing the translation from IPv6 to IPv4 regardless of if this was done by a DNS64 server or by some other method, as long as the IPv4 address is embedded into the IPv6 address as described below.

 

 

       

 

Note: The NAT64 feature supports RFC6052 compatible prefix, which covers Well-Known Prefix and network-specific prefix (For example: all or a part of the customer's global address prefix). This document explains the scenario of Well-Known Prefix with 96.  This can apply to Network-SpecifIc Prefix as well.

The following table is the mapping rule from IPv6 to IPv4. The mapping varies with the length of prefix:

RFC6052-conversion-table.png

 

Steps

The following network topology is used for the configuration example:

nat64.png

  1. Bind 9 was used as the DNS64 server for this setup. The following configuration needs to be added to the /etc/bind/named.conf.options file.
    options {
    dns64 64:ff9b::/96 {
    };
    listen-on-v6 { any; };
    allow-query { any; };
    };
  2. Assign the 64:ff9b::/96 network to the interface assigned to 'Untrust' zone. This is to ensure that zone lookups for destination IPs in this network matches the Untrust Zone.
  3. Configure the NAT64 rule as follows:
    nat64_rule.png
  4. On the client, open a browser and try to navigate to a website. We will use www.w3schools.com an example site.
    • The website www.w3schools.com resolves to 66.29.212.73
    • When the PC does a AAAA record lookup for the hostname www.w3schools.com, the DNS64 server returns the IP address as: 64:ff9b::421d:d449 where 421d:d449 is the hex equivalent of 66.29.212.73.

 

Verification

Check the sessions on the firewall for the DNS and the following web browsing sessions:

DNS session:

        c2s flow:

                source:      2005:db4:40:0:0:0:0:31 [trust-L3]

                dst:         2005:db4:31:0:0:0:0:200

                proto:       17

                sport:       58674           dport:      53

                state:       ACTIVE          type:       FLOW

                src user:    unknown

                dst user:    unknown

 

        s2c flow:

                source:      2005:db4:31:0:0:0:0:200 [untrust-L3]

                dst:         2005:db4:40:0:0:0:0:31

                proto:       17

                sport:       53              dport:      58674

                state:       ACTIVE          type:       FLOW

                src user:    unknown

                dst user:    unknown

 

        start time                    : Wed Nov 13 13:04:31 2013

        timeout                       : 30 sec

        time to live                  : 15 sec

        total byte count(c2s)         : 100

        total byte count(s2c)         : 524

        layer7 packet count(c2s)      : 1

        layer7 packet count(s2c)      : 1

        vsys                          : vsys1

        application                   : dns

        rule                          : allow_all

        session to be logged at end   : True

        session in session ager       : True

        session synced from HA peer   : False

        layer7 processing             : enabled

        URL filtering enabled         : False

        session via syn-cookies       : False

        session terminated on host    : False

        session traverses tunnel      : False

        captive portal session        : False

        ingress interface             : ethernet1/4

        egress interface              : ethernet1/3

        session QoS rule              : N/A (class 4)

 

Web Browsing session:

        c2s flow:       ( Notice IPv6 addresses in c2s flow )

                source:      2005:db4:40:0:0:0:0:31 [trust-L3]

                dst:         64:ff9b:0:0:0:0:421d:d449

                proto:       6

                sport:       49381           dport:      80

                state:       ACTIVE          type:       FLOW

                src user:    unknown

                dst user:    unknown

 

        s2c flow:      (Notice IPv4 addresses in s2c flow )

                source:      66.29.212.73 [untrust-L3]            dst:     10.66.24.80

                proto:       6

                sport:       80              dport:      65144

                state:       ACTIVE          type:       FLOW

                src user:    unknown

                dst user:    unknown

 

        start time                    : Wed Nov 13 13:04:31 2013

        timeout                       : 3600 sec

        time to live                  : 3568 sec

        total byte count(c2s)         : 758

        total byte count(s2c)         : 5439

        layer7 packet count(c2s)      : 6

        layer7 packet count(s2c)      : 6

        vsys                          : vsys1

        application                   : web-browsing

        rule                          : allow_all

        session to be logged at end   : True

        session in session ager       : True

        session synced from HA peer   : False

        address/port translation      : source + destination

        nat-rule                      : nat6_4(vsys1)     <<<< NAT64 rule is applied

        layer7 processing             : enabled

        URL filtering enabled         : False

        session via syn-cookies       : False

        session terminated on host    : False

        session traverses tunnel      : False

        captive portal session        : False

        ingress interface             : ethernet1/4

        egress interface              : ethernet1/3

        session QoS rule              : N/A (class 4)

 

Troubleshooting

The following command can be used to view counters for NAT64 at the drop/warn level:

> show counter global filter value all | match nat64

 

Example:
5-6-16-nat64.JPGclick to enlarge

 

Note: IPv6 firewalling needs to be enabled under Device > Setup > Session > Ipv6 Firewalling.

 

owner: achitwadgi

Tags (8)
Comments

I don't understand Step #2,  "assign 64:ff9b::/96 network to the interface assigned to 'Untrust' zone."

 

What does "assign" mean?  Assign usuallt means assign an IP--but that isn't an IP/128 address.  Does it mean install an IPv6 route to my Outside interface?  I already have a ::0/0 route, so this is made redundant.  I think this assume IPv4 Internet only, yet the diagram shows IPv6 on the outside where it labels IPv4. So confusing.

 

I have both IPv6 and IPv4 Internet service on the same Outside INterface. They both work.  But I'm trying to use Google DNS64 to allow IPv6-ONLY clients in the company to access IPv4-only websites.  I created the NAT64 which assigned any v6 IP heading to  64:ff9b::/96 and internal IPv4 (10.x.x.x )address as docs say to, but that didn't work.  I tried natting to an Public IPv4, no go. I don't know why.