Configuring NAT64 for IPv6-only Clients

This recipe covers the configuration of NAT64 to allow local IPv6-only clients to contact remote resources only reachable over IPv4.

This entire process is transparent to the client software, such as a web browser. It will act as though it is communicating directly to IPv6 hosts even when using hostnames for sites with no IPv6 connectivity.

See also

Base Configuration

This guide assumes the firewall already has working IPv6 and IPv4 connectivity and at least one local interface which is configured for IPv6 clients.

Consult the NAT64 Requirements for other prerequisite configuration items.

Configure NAT64 Firewall Rules

The first step is to configure a NAT64 firewall rule to perform the IPv6 to IPv4 translation:

  • Navigate to Firewall > Rules

  • Navigate to the tab for the IPv6 only client interface

  • Click fa-turn-down to add a new firewall rule

  • Configure the rule as follows

    Action:

    Pass

    Address Family:

    IPv6

    Enable NAT64:

    Checked

    Protocol:

    Any

    Address Family Translation Source:

    Automatic (default)

    Destination:

    Leave at the current value which should be the default NAT64 prefix, 69:ff9b::/96.

    Description:

    Default Allow IPv6 to IPv4 via NAT64

  • Click Save

  • Drag and move the rule so it is above any other default IPv6 allow rule

    If this rule is below another rule which passes IPv6 to any destination, it would never be matched.

  • Click Save

  • Click Apply Changes

The rule should look similar to the following:

../_images/nat64-rules.png

IPv6 Client Interface Firewall Rules with NAT64

Configure DHCPv6 for DNS

NAT64 requires working DNS so clients must have a way to be informed about DNS server addresses. It is possible to deliver this via router advertisements (RDNSS/DNSSL) but not all clients support those methods, so configuring DHCPv6 for DNS is a safe backup.

  • Navigate to Services > DHCPv6 Server

  • Navigate to the tab for the IPv6 only client interface

  • Ensure the service is Enabled and has Enable DNS checked

  • Manually change the DNS Servers list if the default entries are not acceptable.

  • Click Save

  • Click Apply Changes

Configure PREF64

Router advertisements can use PREF64 to announce the NAT64 prefix to IPv6 clients for automatic discovery:

  • Navigate to Services > Router Advertisement

  • Navigate to the tab for the IPv6 only client interface

  • Ensure the Router Mode is set to one of Managed, Assisted, or Stateless DHCP.

  • Set NAT64 Prefix to 64:ff9b::/96

  • Check Enable DNS to enable RDNSS/DNSSL

  • Check Mirror DHCPv6 or manually enter DNS servers

  • Click Save

Configure DNS64

DNS64 includes IPv6-mapped IPv4 addresses in DNS responses so IPv6-only clients can contact these hosts via NAT64. This behavior is not active by default and must be enabled separately.

  • Navigate to Services > DNS Resolver

  • Navigate to the Advanced Settings tab

  • Check Enable DNS64 (RFC 6147)

  • Set DNS64 Prefix to 64:ff9b::/96

  • Click Save

  • Click Apply Changes

Configure IPv4 DHCP (Optional)

If the segment does not have IPv4 DHCP enabled, it can remain disabled.

However, if the segment has local/private IPv4 configured, such as for a VPN, but no external IPv4 connectivity, then clients can be sent a DHCP option which informs them to prefer IPv6 for external communication.

Note

This guide assumes Kea is in use for DHCP service

  • Navigate to Services > DHCP Server

  • Navigate to the tab for the IPv6 only client interface

  • Locate the Custom Configuration section near the bottom of the page

  • Set JSON Configuration to the following:

    {
  "option-data": [
    {
      "name": "v6-only-preferred",
      "data": "3600"
    }
  ]
}

This enables DHCP option 108 for IPv4 DHCP clients on that segment and clients which respect this option should only contact IPv6 servers when possible.

Finish Up / Testing

IPv6 clients on the configured interface should now be able to contact IPv4 only Internet sites and have their traffic translated automatically.

Connectivity can be tested manually as described in Contacting Remote IPv4 Hosts.

A popular testing technique is to attempt loading a well-known Internet site which only has IPv4 connectivity, such as https://github.com.

Contacting IPv4 addresses directly using IPv4 notation may be possible depending on the presence of a customer-side translator (CLAT), but this is completely dependent on the client and is not handled at the firewall level.