Use os-ndproxy to proxy ISP provided /64 Prefix from WAN to LAN

[Monviech (Cedrik)]

os-ndproxy is part of OPNsense Community Edition 24.7.9 as plugin.

The goal is to get a single IPv6 Prefix mapped from WAN to LAN on an OPNsense connected to a Provider that only provides a single /64 prefix.

https://man.freebsd.org/cgi/man.cgi?query=ndproxy

https://docs.opnsense.org/manual/ndproxy.html
 

[newsense]

Thanks Cedrik.

I'm guessing this could be particularly helpful in IPv4 only networks where the ISP cannot be bothered to offer IPv6, and the user sets up a HurricaneElectric IPv6 tunnel.

[Monviech (Cedrik)]

I don't understand. From what I see HE delegates a /48 prefix in their tunnel broker service. You can easily route and split that into multiple /64 nets.

ndproxy is only needed if you /only/ get a single /64 prefix which you can not split into smaller networks since then SLAAC will break.

An additional usecase is if the upstream router does not have a route to your downstream router but resolves all via neighbor discovery.

Its a fix for broken IPV6 implementations by ISPs, in mobile 4g/5g ipv6 networks and also quite helpful for cloud provider stuff like VPS. So the typical environments you find with home users and self hosting hobbyists.

[fdevd]

It took way too long to figure this out (finally 0.0% packet loss/dup to cloudflare), so I thought I'd mention it here:

If you're getting dropped & duplicate packets (DUP! with ping on linux, windows doesn't show). It's likely the "Downlink MAC Address", in my case I actually had to set it to the Uplink (WAN) MAC Address. Could be mislabeled, or something with my setup specifically (the PE is not very reliable; XS-2426G-B).

Also if you are always getting an IPv6 /64 address on WAN with "Request Prefix only" enabled: find the gateway address in settings (save); set WAN as static IPv6 with same address but /128. Then manually re-make the IPv6 gateway using the previously saved gateway address. I assume this happens when the PE doesn't really support prefix delegation at all.

[Maurice]

Thanks @Monviech for adding an ndproxy to OPNsense! Very useful.

Let me explain some things:

If the provider offers DHCPv6 prefix delegation (even if it's just a single /64), an ndproxy is not required. During prefix delegation, the PE creates a route for the delegated prefix, pointing to the CPE's WAN address.

An ndproxy is required if neither prefix delegation nor static routes are available on the PE. Typical examples are SLAAC-only networks (e.g. mobile broadband routers / "modems", tethered phones) or datacenters.

@fdevd is correct: Downlink MAC Address is the MAC address of the selected Uplink Interface. Promiscous mode is not required because we use the interface's actual address. The reason why the MAC address needs to be specified at all is that ndproxy can also operate on a dedicated machine instead of on the CPE itself. If the CPE doesn't have an ndproxy, you can run it on a separate machine which then handles NDP on behalf of the CPE. Promiscuous mode is only required for this rare use case.

The name "proxy" might be somewhat misleading. Ndproxy does not actually proxy packets between the CPE's WAN and LAN interfaces. It operates exclusively on the WAN interface.

Cheers
Maurice

[Monviech (Cedrik)]

Thank you both for testing and clarification.

If there's time eventually, can somebody look at the documentation for the plugin and point out the spots where its wrong?

What I wrote there actually works too, it can be verified that a /64 prefix delegation does not automatically make traffic on LAN work. The ndproxy needs to be there for it to work.

I wonder why if it should not be needed.

https://github.com/opnsense/docs/blob/master/source/manual/ndproxy.rst?plain=1
https://docs.opnsense.org/manual/ndproxy.html


The second point about the MAC address seems to be right:

https://man.freebsd.org/cgi/man.cgi?query=ndproxy

When looking at the Network Design again, the MAC address should be the same as the WAN on OPNsense. Though its the label that needs adjusting then, since its a hard requirement for the kernel module to be loaded.

[Anticept]

The label for the downlink mac address is correct, the issue is that the description suggests using the LAN interface, but it should be WAN interface.

The ndproxy manpage refers to "uplink" and "downlink" when looking at it from the point of view of the PE and CPE link. Meaning if we think about the wires between the ISP (PE) and the customer router (CPE), the "uplink" is the ISP interface, the "downlink" is the WAN side of opnsense.

The only one that is a bit weird is the label "uplink_interface". Looking at that manpage's network example, there is a switch between the PE and CPE, and a BSD host on a third leg of that switched network. The "uplink interface" is from the bsd host's point of view in that network. What a wild example, and only when I think of this network layout like this does the manpage make sense.

Anyways, right under the network diagram it says "the BSD host and the CPE router can be the same node" as well. That means in this case, the "uplink interface" is now the WAN interface on the CPE........ further adding to the confusion! Unless you have read this manpage and analyzed it, "uplink interface" would seem like contravention to the naming conventions for "uplink" and "downlink" when referring to the PE and CPE interfaces, so it's no wonder the "downlink" interface description incorrectly suggests using the LAN interface!

I feel like the person who wrote the kernel module and the manpage is dealing with the frustration of a super crappy ISP and they had to get real creative. I showed this manpage to a friend and he informed me that there are absolutely crap ISPs out there that will force low grade equipment on you and won't let you bring your own, so creative types have done things like this network diagram to get traffic to re-route to other routers, but leaves the garbage equipment in place to answer authentication queries.

[Monviech (Cedrik)]

Thanks for the feedback: https://github.com/opnsense/plugins/pull/4553

Small docs update follows soon: https://github.com/opnsense/docs/pull/672