Enabling NAT64 on Palo Alto Firewalls

A little while ago I wrote a post about getting IPv6 to work on my Palo Alto PA220 firewall with my home internet connection. I said in that post that I'd like to try out an IPv6 only network to get a feel for using IPv6 exclusively on a day-to-day basis. To be honest, I put it off for longer than I should because I kind of figured it was going to be a hassle to set up and there were going to be teething issues while using it. I was wrong on both accounts.

My first step was to plumb this over to a new SSID that I could use as a personal testbed without screwing up my wife's work connection (and TV watching). Easy enough with my Meraki AP. I just created a new SSID and tagged it to VLAN 2. I then went and configured a sub-interface tagged with VLAN 2 on the firewall with another IPv6 subnet as before.

The one deviation from my previous setup was to use Google's NAT64 DNS servers, not their regular IPv6 DNS servers.

If you're unaware of how NAT64 works, here's my rough explanation: An 'A' record that's queried over IPv6 is returned with the regular IPv4 address padded out with '::ffff:' to fit into an IPv6 address space. For example, an A record query would return an address of "::ffff:192.168.5.5" for the address of 192.168.5.5. If you're running dual-stack, that IPv4 address is connected to natively using IPv4. However, if you query for an ‘AAAA’ record but there’s no matching record, the DNS server will respond with the IP address of the ‘A’ record within the ‘AAAA’ response, padded to the appropriate length.

A NAT64 DNS server will cleverly hide an IPv4 in an IPv6 subnet though so that, to your client, that address looks like any other IPv6 address and it sends it out as native IPv6 traffic. In the DNS servers setting though, will be the prefix that it assigns to all IPv4 addresses. RFC6052, which outlines how NAT64 works, defines a 'well-known' prefix to be used, "64:ff9b::/96". Google uses this well-known prefix but technically there's nothing stopping another prefix from being used on a NAT64 DNS server.

So now, if a domain-name only has an A record configured, your DNS server will imbed that response to your query padded with the prefix "64:ff9b::" and your device will attempt to connect to it. Now unfortunately, there's not a huge service out there PATing between '64:ff9b::' addresses and their IPv4 counterparts for us so we need to set this up ourselves.

In this case, because my network is so small, I'm doing my NAT64 translation at the edge of my network. That said, in a large enterprise, I could envision them utilizing a dedicated firewall for just this purpose and simply advertising the '64:ff9b::/96' prefix into their IPv6 routing tables.

So, after setting my DNS servers to Google's NAT64 DNS servers, a single NAT policy is all that's needed to get this working.

  1. Create a new NAT policy. Policies -> NAT -> Add

  2. Assign a name and specify the NAT type as "nat64".

  3. On the 'Original Packet' screen, select and identifiers you'd like such as originating zone or source address, and enter "64:ff9b::/96" as the destination address.

  4. On the 'Translated Packet' screen, fill in which IP address and interface you'd like to translate to. Since this is my home internet connection and I only have the one address to translate to.

  5. Commit.

It's really that easy.

If you need more documentation head on over to Palo Alto’s documentation on the matter.

As I alluded to at the beginning, I figured there would be some teething problems like certain applications not functioning entirely. There are going to be those applications that won't work, such as applications that use hard-coded IPv4 addresses or open raw-sockets on IPv4 but, luckily for me, those are rare in my usage. Your mileage will vary. I really thought I would end up with more VPN issues since I typically connect to multiple customers over VPN but as long as they use a fully-qualified domain name and not just a public IP address for connecting, it should translate correctly.

Really, the only application that I couldn't get to function on this IPv6-only network was the game 'Among Us' on my phone. If you're a parent, this might be worth looking into.

What can you do when the address you're trying to reach is IPv4 only and there's no associated DNS A record? Well, I suspect that you could try editing your host file to have an entry with the address of the IP address prefixed with '64:ff9b::'. I haven't tested this yet, but I suspect it will work.

Ryan Harris

I’m Ryan and I’m a Senior Network Engineer for BlueAlly (formerly NetCraftsmen) in North Carolina doing routing, switching, and security. I’m very interested in IPv6 adoption, SD-Access, and Network Optimization. Multi-vendor with the majority of my work being with Cisco and Palo Alto.

Previous
Previous

An Interesting Bug During PnP on a Cisco 9300 Switch

Next
Next

Lessons Learned From A Recent 10 Hour Cutover