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

[Monviech (Cedrik)]

This is a draft how it worked for me in a test environment.

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

<-- INTERNET - OPNsense PE - (igc1) Peering <---> WAN (igc1) - OPNsense CPE - (igc0) LAN <---> Clients

OPNsense PE (Provider Edge):

This simulates the Provider Router. On its own WAN, it has a Prefix by the upstream provider, e.g. /48. We simulate being our own provider, so we create a network that delegates a single /64 network downstream.

In a non simulated setup, this would be a router in the network of your provider and can be skipped during setup.

OPNsense CPE (Customer Premises Equipment):

A second OPNsense attached to OPNsense PE, it will receive the delegated /64 Prefix on its WAN interface. The goal is to use it on the LAN interface by proxying NDP with ndproxy. Without it, only the router itself could use this network. Devices on the LAN side of the CPE router could not use it. With ndproxy, NDP (Neighbor Discovery Procotol) will be proxied from LAN to WAN so all LAN IPv6 Devices can be discovered by the OPNsense PE and traffic will be sent back to these devices.

We assume the network we receive is 2001:db8:aaaa:bbbb::/64

OPNsense PE configuration:

Interfaces: [Peering]
Link local IPv6 address: fe80::1/64 (will be an auto generated one, this is needed for ndproxy. It is the default IPv6 Gateway of OPNsense CPE.)
IPv6 Configuration Type: Static IPv6
IPv6 address: 2001:db8:aaaa:bbbb::1/64

Services: ISC DHCPv6: [Peering]
Subnet: 2001:db8:aaaa:bbbb::
Subnet mask: 64
Range: Leave empty
Prefix Delegation Range:
from: 2001:db8:aaaa:bbbb::   to: 2001:db8:aaaa:bbbb::
Prefix Delegation Size: 64

Services: Router Advertisements:[Peering]
Router Advertisements: Router Only
Advertise Default Gateway: X

With these settings in place we now configure the CPE Router.
If you do not simulate the setup, but have a real provider, you only need the OPNsense CPE configuration, since that is your router that you control.

OPNsense CPE configuration:

Interfaces: [WAN]
IPv6 Configuration Type: DHCPv6
Promiscous Mode: X (important since otherwise not all NDP Multicast will be captured)
Prefix delegation size: 64
Request prefix only: X  (important since the WAN should not get a GUA, otherwise the IPv6 routing will not work. If one is needed, make sure it has a /128 prefix length.)

Interfaces: [LAN]
MAC: aa:bb:cc:dd:ee:ff (needed for ndproxy, do not set it here, use the actual interface MAC address)
IPv6 Configuration Type: Track Interface
Parent Interface: WAN
Assign prefix ID: 0

Here it is best not to use "Allow manual adjustement of DHCPv6 and Router Advertisements". It will "Just Work".
If you know what you are doing in manual control, you have to manually configure DHCPv6 and set Router Advertisements to Assisted, or set them to Stateless and use SLAAC without DHCPv6.

Now for the os-ndproxy configuration on the CPE Router:

Enable: X
Uplink Interface: WAN
Downlink MAC Address: aa:bb:cc:dd:ee:ff    <- The LAN MAC address of OPNsense CPE
Uplink IPv6 Addresses: fe80::1     <- The link local address of OPNsense PE peering interface
Exception IPv6 Addresses: leave empty

Apply the configuration.

Ensure the firewall rules allow IPv6 traffic.

Connect the Windows Client (or any other client) to the LAN side of OPNsense CPE, it should automatically receive an IPv6 address like: 2001:db8:aaaa:bbbb::2000/64

Try to "ping -6 ipv6.google.com" and it will work. When you disable ndproxy the ping will stop working after a while. When you enable it the ping will work again.

If it does not work right away, you might have to reboot your OPNsense once.

The benefit of this setup is that it should dynamically continue to work even if the prefix changes due to track interface on LAN. Also, IPv6 addresses with the privacy extension should work as well. We do not need any NAT66 or other tricks.

The downside is, it feels a bit wonky. Sometimes it doesn't work for a few minutes. Deleting the neighbor discovery protocol table on the router "ndp -c" and then restarting ndproxy seems to fix it. So far, when it runs, it seems to work just fine but it can be a little weird. It also works after OPNsense reboots, but only if the WAN interface has been put manually into promiscous mode.
 

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