Reconcile OPNsense Tayga and DNS64 addressing before testing clients

Bottom line: Build one address worksheet for Tayga, its interface and DNS64. Check the documented inside-pool and outside-pool roles individually before testing an IPv6-only client.

Source fact: what the authority says

The OPNsense Tayga guide defines an IPv6 translation prefix and an IPv4 pool that must not overlap existing subnets and must fit the IPv6-only client population. Tayga’s own IPv4 address for ICMP should be inside that IPv4 pool. The IPv4 NAT64 interface address must be outside the pool, and the IPv6 NAT64 interface address must be outside the translation prefix; neither may duplicate another interface address or virtual IP. For Unbound DNS64 with a non-default translation prefix, the guide requires entering that same /96 prefix in its DNS64 configuration.

What the source does not establish

This article covers agreement between the documented NAT64 address roles and DNS64 configuration. It does not qualify every application protocol, approve sample addresses for production or establish complete IPv6 security policy.

Applicability questions

• Which translation prefix and non-overlapping IPv4 pool are approved for this site?
• Which addresses belong to Tayga itself and which belong to the NAT64 interface?
• What DNS64 service and prefix will the client actually use?
• Which existing interface addresses, virtual IPs and subnets must be checked for conflicts?

DSE recommendation: controlled next steps

The following steps are DSE recommendations based on the cited source.

DSE recommends separate worksheet rows for the translation prefix, IPv4 pool, Tayga ICMP addresses and NAT64 interface addresses. Write the inside-or-outside requirement beside each row. Compare the entries with the complete site address inventory before submitting the plugin configuration.

Name the DNS64 resolver used by the proposed test client. If the approved translation prefix differs from the documented default, have a second operator reconcile the DNS64 value with Tayga’s value character for character. Avoid copying a documentation-only interface address into the production plan.

Keep the routing, interface firewall and IPv4 source-NAT review with the network owner. Treat those as additional prerequisites for the client test, rather than changing several unrelated rules after a failed lookup. Record the intended egress interface and permitted test destination before opening the pilot.

Choose a harmless IPv4-only test service and an approved IPv6-only client network. Preserve the starting resolver and translator settings. Agree which mismatch will stop the trial and who can restore the previous client configuration without extending the experiment to operational devices.

Verification and evidence

Proposed verification: compare saved translator and resolver settings with the worksheet, including pool boundaries and existing interface addresses. From the approved client, observe the DNS64 response for the selected IPv4-only name and record the actual resolver and synthesized destination. Compare its prefix with the approved translation prefix.

Attempt the permitted application transaction and correlate observations on the client-facing and IPv4-facing paths. Keep name resolution, translation and application success as separate findings. Investigate an unexpected prefix or overlapping address before adding more rules or accepting a successful result from a different dual-stack client.

Official references

• OPNsense — Tayga NAT64 how-to — official product documentation; confirm the installed release and configuration.

Source review completed October 29, 2026. Recheck the official documentation and deployment-specific applicability before a production change.