Bottom line: Name the service responsible for downstream router advertisements before combining an NDP proxy with local RA configuration. Keep this article’s pilot on the documented Ethernet path and record the actual client advertisements.
\nThe OPNsense NDP proxy guide says the default behavior forwards downstream Router Solicitations upstream and upstream Router Advertisements downstream. Its default setup requires other LAN Router Advertisement daemons, including those in Router Advertisements and Dnsmasq, to be disabled. For a local radvd design, the guide first disables Proxy router advertisements and then configures an RA entry using the WAN constructor. The guide recommends Ethernet links and labels point-to-point upstream support experimental.
\nThis article limits its recommendation to the documented Ethernet design and the choice of RA owner. It does not approve the experimental point-to-point path, qualify an ISP service or establish that every client has learned the intended settings.
\nThe following steps are DSE recommendations based on the cited source.
\nDSE recommends a short RA ownership diagram showing the ISP-facing interface, proxy and downstream segment. Give each currently configured RA service its own row. Record which service will remain responsible and which configuration must be disabled for the selected branch.
\nKeep the default forwarding branch and the local radvd branch as separate proposed configurations. Choose one for the pilot rather than enabling both to see which appears to work. Preserve the current settings and an independent management path before changing IPv6 behavior.
\nFor a proposed local-advertisement case, write the intended prefix source and any required DNS information as requirements to verify. Do not infer the client’s resulting configuration from a saved constructor field. Ask the network owner to compare the chosen branch with the actual provider addressing arrangement.
\nUse one approved test segment and a named client population. Plan how the prior RA configuration will be restored if an unexpected advertiser or client route appears. Keep firewall policy and learned-client alias acceptance in separate records rather than treating an address as proof of permitted traffic.
\nProposed verification: capture authorized RA and solicitation observations on the relevant segment, then inspect a representative client’s address, default route and intended DNS information. Identify the observed sender and correlate it with the selected owner. Record unexpected advertisements instead of accepting the first successful external connection.
\nRepeat after the approved service restart or recovery case included in the pilot. Preserve the active proxy setting, any local RA entry and the corresponding client observations together. Leave the result open if the actual source of an advertisement cannot be explained; do not widen the pilot until that ownership question is resolved.
\nSource review completed October 29, 2026. Recheck the official documentation and deployment-specific applicability before a production change.
\n", "content_text": "Bottom line: Name the service responsible for downstream router advertisements before combining an NDP proxy with local RA configuration. Keep this article’s pilot on the documented Ethernet path and record the actual client advertisements.\nSource fact: what the authority says\nThe OPNsense NDP proxy guide says the default behavior forwards downstream Router Solicitations upstream and upstream Router Advertisements downstream. Its default setup requires other LAN Router Advertisement daemons, including those in Router Advertisements and Dnsmasq, to be disabled. For a local radvd design, the guide first disables Proxy router advertisements and then configures an RA entry using the WAN constructor. The guide recommends Ethernet links and labels point-to-point upstream support experimental.\nWhat the source does not establish\nThis article limits its recommendation to the documented Ethernet design and the choice of RA owner. It does not approve the experimental point-to-point path, qualify an ISP service or establish that every client has learned the intended settings.\nApplicability questions\n\nShould clients receive the ISP advertisements or locally constructed advertisements?\nWhich LAN services currently advertise IPv6 router information?\nAre the upstream and downstream links within the documented Ethernet scope?\nWhich client and capture location will demonstrate the chosen advertisement source?\n\nDSE recommendation: controlled next steps\nThe following steps are DSE recommendations based on the cited source.\nDSE recommends a short RA ownership diagram showing the ISP-facing interface, proxy and downstream segment. Give each currently configured RA service its own row. Record which service will remain responsible and which configuration must be disabled for the selected branch.\nKeep the default forwarding branch and the local radvd branch as separate proposed configurations. Choose one for the pilot rather than enabling both to see which appears to work. Preserve the current settings and an independent management path before changing IPv6 behavior.\nFor a proposed local-advertisement case, write the intended prefix source and any required DNS information as requirements to verify. Do not infer the client’s resulting configuration from a saved constructor field. Ask the network owner to compare the chosen branch with the actual provider addressing arrangement.\nUse one approved test segment and a named client population. Plan how the prior RA configuration will be restored if an unexpected advertiser or client route appears. Keep firewall policy and learned-client alias acceptance in separate records rather than treating an address as proof of permitted traffic.\nVerification and evidence\nProposed verification: capture authorized RA and solicitation observations on the relevant segment, then inspect a representative client’s address, default route and intended DNS information. Identify the observed sender and correlate it with the selected owner. Record unexpected advertisements instead of accepting the first successful external connection.\nRepeat after the approved service restart or recovery case included in the pilot. Preserve the active proxy setting, any local RA entry and the corresponding client observations together. Leave the result open if the actual source of an advertisement cannot be explained; do not widen the pilot until that ownership question is resolved.\nOfficial references\n\nOPNsense — ndp-proxy-go (Neighbor Discovery Proxy) — 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: Name the service responsible for downstream router advertisements before combining an NDP proxy with local RA configuration. Keep this article’s pilot on the documented Ethernet path and record the actual client advertisements.\n\n## Source fact: what the authority says\n\nThe [OPNsense NDP proxy guide](https://docs.opnsense.org/manual/ndp-proxy-go.html) says the default behavior forwards downstream Router Solicitations upstream and upstream Router Advertisements downstream. Its default setup requires other LAN Router Advertisement daemons, including those in Router Advertisements and Dnsmasq, to be disabled. For a local radvd design, the guide first disables Proxy router advertisements and then configures an RA entry using the WAN constructor. The guide recommends Ethernet links and labels point-to-point upstream support experimental.\n\n## What the source does not establish\n\nThis article limits its recommendation to the documented Ethernet design and the choice of RA owner. It does not approve the experimental point-to-point path, qualify an ISP service or establish that every client has learned the intended settings.\n\n## Applicability questions\n\n- Should clients receive the ISP advertisements or locally constructed advertisements?\n\n- Which LAN services currently advertise IPv6 router information?\n\n- Are the upstream and downstream links within the documented Ethernet scope?\n\n- Which client and capture location will demonstrate the chosen advertisement source?\n\n## DSE recommendation: controlled next steps\n\nThe following steps are DSE recommendations based on the cited source.\n\nDSE recommends a short RA ownership diagram showing the ISP-facing interface, proxy and downstream segment. Give each currently configured RA service its own row. Record which service will remain responsible and which configuration must be disabled for the selected branch.\n\nKeep the default forwarding branch and the local radvd branch as separate proposed configurations. Choose one for the pilot rather than enabling both to see which appears to work. Preserve the current settings and an independent management path before changing IPv6 behavior.\n\nFor a proposed local-advertisement case, write the intended prefix source and any required DNS information as requirements to verify. Do not infer the client’s resulting configuration from a saved constructor field. Ask the network owner to compare the chosen branch with the actual provider addressing arrangement.\n\nUse one approved test segment and a named client population. Plan how the prior RA configuration will be restored if an unexpected advertiser or client route appears. Keep firewall policy and learned-client alias acceptance in separate records rather than treating an address as proof of permitted traffic.\n\n## Verification and evidence\n\nProposed verification: capture authorized RA and solicitation observations on the relevant segment, then inspect a representative client’s address, default route and intended DNS information. Identify the observed sender and correlate it with the selected owner. Record unexpected advertisements instead of accepting the first successful external connection.\n\nRepeat after the approved service restart or recovery case included in the pilot. Preserve the active proxy setting, any local RA entry and the corresponding client observations together. Leave the result open if the actual source of an advertisement cannot be explained; do not widen the pilot until that ownership question is resolved.\n\n## Official references\n\n- [OPNsense — ndp-proxy-go (Neighbor Discovery Proxy)](https://docs.opnsense.org/manual/ndp-proxy-go.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/choose-one-router-advertisement-owner-for-an-opnsense-ndp-proxy/", "url": "https://update.dsesecurity.com/updates/choose-one-router-advertisement-owner-for-an-opnsense-ndp-proxy/", "isPartOf": { "@id": "https://update.dsesecurity.com/#website" }, "lastReviewed": "2026-10-29" }, { "@type": "BreadcrumbList", "@id": "https://update.dsesecurity.com/updates/choose-one-router-advertisement-owner-for-an-opnsense-ndp-proxy/#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": "Choose one router-advertisement owner for an OPNsense NDP proxy", "item": "https://update.dsesecurity.com/updates/choose-one-router-advertisement-owner-for-an-opnsense-ndp-proxy/" } ] }, { "@type": [ "Article", "TechArticle" ], "@id": "https://update.dsesecurity.com/updates/choose-one-router-advertisement-owner-for-an-opnsense-ndp-proxy/#article", "identifier": "https://update.dsesecurity.com/updates/choose-one-router-advertisement-owner-for-an-opnsense-ndp-proxy/", "url": "https://update.dsesecurity.com/updates/choose-one-router-advertisement-owner-for-an-opnsense-ndp-proxy/", "headline": "Choose one router-advertisement owner for an OPNsense NDP proxy", "description": "Choose forwarded upstream advertisements or a separately configured local radvd path without leaving the ownership decision implicit.", "abstract": "Choose forwarded upstream advertisements or a separately configured local radvd path without leaving the ownership decision implicit.", "articleBody": "Bottom line: Name the service responsible for downstream router advertisements before combining an NDP proxy with local RA configuration. Keep this article’s pilot on the documented Ethernet path and record the actual client advertisements.\nSource fact: what the authority says\nThe OPNsense NDP proxy guide says the default behavior forwards downstream Router Solicitations upstream and upstream Router Advertisements downstream. Its default setup requires other LAN Router Advertisement daemons, including those in Router Advertisements and Dnsmasq, to be disabled. For a local radvd design, the guide first disables Proxy router advertisements and then configures an RA entry using the WAN constructor. The guide recommends Ethernet links and labels point-to-point upstream support experimental.\nWhat the source does not establish\nThis article limits its recommendation to the documented Ethernet design and the choice of RA owner. It does not approve the experimental point-to-point path, qualify an ISP service or establish that every client has learned the intended settings.\nApplicability questions\n\nShould clients receive the ISP advertisements or locally constructed advertisements?\nWhich LAN services currently advertise IPv6 router information?\nAre the upstream and downstream links within the documented Ethernet scope?\nWhich client and capture location will demonstrate the chosen advertisement source?\n\nDSE recommendation: controlled next steps\nThe following steps are DSE recommendations based on the cited source.\nDSE recommends a short RA ownership diagram showing the ISP-facing interface, proxy and downstream segment. Give each currently configured RA service its own row. Record which service will remain responsible and which configuration must be disabled for the selected branch.\nKeep the default forwarding branch and the local radvd branch as separate proposed configurations. Choose one for the pilot rather than enabling both to see which appears to work. Preserve the current settings and an independent management path before changing IPv6 behavior.\nFor a proposed local-advertisement case, write the intended prefix source and any required DNS information as requirements to verify. Do not infer the client’s resulting configuration from a saved constructor field. Ask the network owner to compare the chosen branch with the actual provider addressing arrangement.\nUse one approved test segment and a named client population. Plan how the prior RA configuration will be restored if an unexpected advertiser or client route appears. Keep firewall policy and learned-client alias acceptance in separate records rather than treating an address as proof of permitted traffic.\nVerification and evidence\nProposed verification: capture authorized RA and solicitation observations on the relevant segment, then inspect a representative client’s address, default route and intended DNS information. Identify the observed sender and correlate it with the selected owner. Record unexpected advertisements instead of accepting the first successful external connection.\nRepeat after the approved service restart or recovery case included in the pilot. Preserve the active proxy setting, any local RA entry and the corresponding client observations together. Leave the result open if the actual source of an advertisement cannot be explained; do not widen the pilot until that ownership question is resolved.\nOfficial references\n\nOPNsense — ndp-proxy-go (Neighbor Discovery Proxy) — 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-29T17:41:10+00:00", "dateModified": "2026-10-29T17:41:38+00:00", "mainEntityOfPage": { "@id": "https://update.dsesecurity.com/updates/choose-one-router-advertisement-owner-for-an-opnsense-ndp-proxy/" }, "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/choose-one-router-advertisement-owner-for-an-opnsense-ndp-proxy/#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": "Choose one router-advertisement owner for an OPNsense NDP proxy" }, "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 — ndp-proxy-go (Neighbor Discovery Proxy)", "url": "https://docs.opnsense.org/manual/ndp-proxy-go.html" } } ] } }