ndp-proxy-go: Proxy ISP provided /64 Prefix from WAN to LAN

[Monviech (Cedrik)]

Experimental PPPoE support is in 25.7.9.

The last feature I added is PF table (firewall alias) support to help with the network segmentation for highly dynamic setups.

It will most likely hit 25.7.10.

With that the proxy should be complete for now, I personally do not miss any feature when using it, it just worksTM and is quite possibly the leading most complete implementation to fix IPv6 for many setups.

I would call it generic since you can chain the proxy over multiple routers. You dont even need DHCPv6-PD anymore, this proxy handles dynamic IPv6 so gracefully that you won't believe it.

https://github.com/opnsense/docs/commit/5bb5fca5c67ac9162c8f76d6261ca6cc90f34076

[inkeliz]

I'm testing ndp-proxy-go, but it's not working as I expected. I have a multi-WAN setup with NPTv6.

I recently got a new ISP, but their router don't support DHCPv6-PD. I manage to get multiples "/64" in the same interface and I was hopping to route each "/64" to a different LAN.


WAN_DIGI:
2a12:1111:1111:c200::/64
2a12:1111:1111:c201::/64
2a12:1111:1111:c203::/64

LAN:
fdaa:1111:1111::/64 (using NPTv6 from 2a12:1111:1111:c201::/64)

GATEWAY_TEST:
Tier 1: WAN_DIGI
Tier 2: (other WAN)

VM (connected to LAN):
fdaa:1111:1111::da4d (via DHCPv6)


------------

In theory, I was hopping to:

2a12:1111:1111:c201::/64 <-> fdaa:1111:1111::/64

That already works for my other WAN and even Wireguard (which I get /64 externally).

------------

When I test `ping google.com` from VM, the OPNSense shows:

Code Select Expand

16:23:25.354572 00:1b:21:bc:fa:9e > 58:72:c9:40:e8:fc, ethertype IPv6 (0x86dd), length 70: 2a12:1111:1111:c201::da4d > 2a00:1450:4003:809::200e: ICMP6, echo request, id 57938, seq 49995, length 16
However, the router reply:

Code Select Expand

16:23:25.306554 58:72:c9:40:e8:fc > 33:33:ff:00:da:4d, ethertype IPv6 (0x86dd), length 86: fe80::fff1 > ff02::1:ff00:da4d: ICMP6, neighbor solicitation, who has 2a12:1111:1111:c201::da4d, length 32

I don't see any reply to that. Sounds like the ISP router can't find who has that IP.

The NDP Proxy setup is:

Code Select Expand

Enable [X]

Upstream Interface: WAN_DIGI

Downstream Interfaces: LAN

Proxy router advertisements [_] (unchecked)

Install host routes [X] (I already test as unchecked)

The Log File is empty, even with Debug Log enabled.

-----

The documentation states "It can proxy SLAAC on-link prefixes to several downstream interfaces by proxying", so it don't work with DHCPv6? Or I'm missing something?

Maybe the NPTv6 is causing the issue?

[Monviech (Cedrik)]

The proxy is not compatible with NPTv6 setups.

It only proxies single host addresses it discovers on the downstream interfaces, and only answers NDP for these hosts inside the learned prefix.

It's very strict here, NPTv6 would need arbitrary answers for any address in the prefix. But ndp-proxy-go keeps an in memory database of discovered hosts and only answers for their real address, not a translated one.

If you received your prefixes only via DHCPv6 PD then ndp proxy is not the right tool for you.

Empty log file is weird, it should at least emit that it starts and what the configuration is.

[inkeliz]

The proxy is not compatible with NPTv6 setups.

It only proxies single host addresses it discovers on the downstream interfaces, and only answers NDP for these hosts inside the learned prefix.

Have any alternative to it?

I think the old "ndproxy" works with NPTv6. I use ndproxy with wireguard, in another FreeBSD VM, but not on OPNSense.

[Monviech (Cedrik)]

The old ndproxy works because it proxies the whole prefix. It simply answers "that's me" for any address within the configured prefix.

ndp-proxy-go is intentionally stricter. It only answers for host addresses it has actually learned from downstream.

With NPTv6, the translated address never exists downstream, so there is nothing to learn and therefore nothing to answer for.

I also maintained the ndproxy plugin but its a kernel module and it was defunct on FreeBSD 15 for a while so the decision was made to remove it, even though now it seems fixed upstream. But who knows how long.

-> Probably the simplest solution would be to not use a proxy, but to just use NAT66, just like using NAT44 (Source NAT). So not a prefix translation, just good old Source NAT Masquerading.