Choose one router-advertisement owner for an OPNsense NDP proxy

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.

Source fact: what the authority says

The 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.

What the source does not establish

This 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.

Applicability questions

• Should clients receive the ISP advertisements or locally constructed advertisements?
• Which LAN services currently advertise IPv6 router information?
• Are the upstream and downstream links within the documented Ethernet scope?
• Which client and capture location will demonstrate the chosen advertisement source?

DSE recommendation: controlled next steps

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

DSE 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.

Keep 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.

For 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.

Use 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.

Verification and evidence

Proposed 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.

Repeat 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.

Official references

• OPNsense — ndp-proxy-go (Neighbor Discovery Proxy) — 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.