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.
\nThe 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.
\nThis 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.
\nThe following steps are DSE recommendations based on the cited source.
\nDSE 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.
\nName 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.
\nKeep 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.
\nChoose 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.
\nProposed 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.
\nAttempt 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.
\nSource review completed October 29, 2026. Recheck the official documentation and deployment-specific applicability before a production change.
\n", "content_text": "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.\nSource fact: what the authority says\nThe 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.\nWhat the source does not establish\nThis 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.\nApplicability questions\n\nWhich translation prefix and non-overlapping IPv4 pool are approved for this site?\nWhich addresses belong to Tayga itself and which belong to the NAT64 interface?\nWhat DNS64 service and prefix will the client actually use?\nWhich existing interface addresses, virtual IPs and subnets must be checked for conflicts?\n\nDSE recommendation: controlled next steps\nThe following steps are DSE recommendations based on the cited source.\nDSE 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.\nName 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.\nKeep 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.\nChoose 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.\nVerification and evidence\nProposed 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.\nAttempt 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.\nOfficial references\n\nOPNsense — Tayga NAT64 how-to — official product documentation; confirm the installed release and configuration.\n\nSource review completed October 29, 2026. Recheck the official documentation and deployment-specific applicability before a production change.", "content_markdown": "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.\n\n## Source fact: what the authority says\n\nThe [OPNsense Tayga guide](https://docs.opnsense.org/manual/how-tos/tayga.html) 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.\n\n## What the source does not establish\n\nThis 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.\n\n## Applicability questions\n\n- Which translation prefix and non-overlapping IPv4 pool are approved for this site?\n\n- Which addresses belong to Tayga itself and which belong to the NAT64 interface?\n\n- What DNS64 service and prefix will the client actually use?\n\n- Which existing interface addresses, virtual IPs and subnets must be checked for conflicts?\n\n## DSE recommendation: controlled next steps\n\nThe following steps are DSE recommendations based on the cited source.\n\nDSE 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.\n\nName 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.\n\nKeep 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.\n\nChoose 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.\n\n## Verification and evidence\n\nProposed 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.\n\nAttempt 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.\n\n## Official references\n\n- [OPNsense — Tayga NAT64 how-to](https://docs.opnsense.org/manual/how-tos/tayga.html) — official product documentation; confirm the installed release and configuration.\n\nSource review completed October 29, 2026. Recheck the official documentation and deployment-specific applicability before a production change." }, "json_ld": { "@context": "https://schema.org", "@graph": [ { "@type": "Organization", "@id": "https://dsesecurity.com/#organization", "name": "Detection Systems & Engineering", "alternateName": "DSE Security", "url": "https://dsesecurity.com/", "logo": { "@type": "ImageObject", "url": "https://update.dsesecurity.com/assets/dse-logo-20260812.png?v=1.8.20" } }, { "@type": "Organization", "@id": "https://update.dsesecurity.com/#editorial-team", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/", "parentOrganization": { "@id": "https://dsesecurity.com/#organization" } }, { "@type": "WebSite", "@id": "https://update.dsesecurity.com/#website", "name": "DSE Updates", "alternateName": "DSE Security Knowledge Hub", "url": "https://update.dsesecurity.com/", "inLanguage": "en-US", "publisher": { "@id": "https://dsesecurity.com/#organization" }, "potentialAction": { "@type": "SearchAction", "target": { "@type": "EntryPoint", "urlTemplate": "https://update.dsesecurity.com/?q={search_term_string}" }, "query-input": "required name=search_term_string" } }, { "@type": "WebPage", "@id": "https://update.dsesecurity.com/updates/reconcile-opnsense-tayga-and-dns64-addressing-before-testing-clients/", "url": "https://update.dsesecurity.com/updates/reconcile-opnsense-tayga-and-dns64-addressing-before-testing-clients/", "isPartOf": { "@id": "https://update.dsesecurity.com/#website" }, "lastReviewed": "2026-10-29" }, { "@type": "BreadcrumbList", "@id": "https://update.dsesecurity.com/updates/reconcile-opnsense-tayga-and-dns64-addressing-before-testing-clients/#breadcrumbs", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "DSE Updates", "item": "https://update.dsesecurity.com/" }, { "@type": "ListItem", "position": 2, "name": "Networks & Infrastructure", "item": "https://update.dsesecurity.com/topic/networks-infrastructure/" }, { "@type": "ListItem", "position": 3, "name": "Reconcile OPNsense Tayga and DNS64 addressing before testing clients", "item": "https://update.dsesecurity.com/updates/reconcile-opnsense-tayga-and-dns64-addressing-before-testing-clients/" } ] }, { "@type": [ "Article", "TechArticle" ], "@id": "https://update.dsesecurity.com/updates/reconcile-opnsense-tayga-and-dns64-addressing-before-testing-clients/#article", "identifier": "https://update.dsesecurity.com/updates/reconcile-opnsense-tayga-and-dns64-addressing-before-testing-clients/", "url": "https://update.dsesecurity.com/updates/reconcile-opnsense-tayga-and-dns64-addressing-before-testing-clients/", "headline": "Reconcile OPNsense Tayga and DNS64 addressing before testing clients", "description": "Check translation and DNS64 prefixes alongside the separate Tayga and NAT64 interface addresses before interpreting an IPv6-only client test.", "abstract": "Check translation and DNS64 prefixes alongside the separate Tayga and NAT64 interface addresses before interpreting an IPv6-only client test.", "articleBody": "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.\nSource fact: what the authority says\nThe 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.\nWhat the source does not establish\nThis 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.\nApplicability questions\n\nWhich translation prefix and non-overlapping IPv4 pool are approved for this site?\nWhich addresses belong to Tayga itself and which belong to the NAT64 interface?\nWhat DNS64 service and prefix will the client actually use?\nWhich existing interface addresses, virtual IPs and subnets must be checked for conflicts?\n\nDSE recommendation: controlled next steps\nThe following steps are DSE recommendations based on the cited source.\nDSE 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.\nName 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.\nKeep 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.\nChoose 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.\nVerification and evidence\nProposed 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.\nAttempt 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.\nOfficial references\n\nOPNsense — Tayga NAT64 how-to — official product documentation; confirm the installed release and configuration.\n\nSource review completed October 29, 2026. Recheck the official documentation and deployment-specific applicability before a production change.", "datePublished": "2026-10-29T20:33:09+00:00", "dateModified": "2026-10-29T20:33:35+00:00", "mainEntityOfPage": { "@id": "https://update.dsesecurity.com/updates/reconcile-opnsense-tayga-and-dns64-addressing-before-testing-clients/" }, "inLanguage": "en-US", "isAccessibleForFree": true, "author": { "@type": "Organization", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team" }, "publisher": { "@id": "https://dsesecurity.com/#organization" }, "image": { "@type": "ImageObject", "@id": "https://update.dsesecurity.com/updates/reconcile-opnsense-tayga-and-dns64-addressing-before-testing-clients/#primaryimage", "url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-social-v2.jpg?v=1.8.20", "contentUrl": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-social-v2.jpg?v=1.8.20", "width": 1200, "height": 630, "caption": "Reconcile OPNsense Tayga and DNS64 addressing before testing clients" }, "articleSection": [ "Networks & Infrastructure" ], "keywords": [ "Networks & Infrastructure", "Guide", "Advisory priority" ], "genre": "Guide", "about": [ { "@type": "Thing", "name": "Networks & Infrastructure", "url": "https://update.dsesecurity.com/topic/networks-infrastructure/" } ], "wordCount": 524, "timeRequired": "PT3M", "publishingPrinciples": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usageInfo": "https://update.dsesecurity.com/usage/", "copyrightHolder": { "@id": "https://dsesecurity.com/#organization" }, "copyrightNotice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "citation": { "@type": "CreativeWork", "name": "OPNsense — Tayga NAT64 how-to", "url": "https://docs.opnsense.org/manual/how-tos/tayga.html" } } ] } }