os-ndp-proxy says it is forwarding NA's. Packet captures say it isn't.

[really_lost]

Is there a firewall setting that may need tweaking to get ndp-proxy NA's to go through?  They aren't making it to the upstream interface, and I think that will solve my issue.

I'm certain I'm doing something wrong. I'm also certain this is as much a Comcast/XFinity issue as it is an OPNsense one.

I'm using OPNsense 26.4.2p3.  I have a Comcast Business class with static IPs.  I have a /29 for ipv4 and a /56 for ipv6.  Comcast will only permit me to request prefix delegations no larger than /59.  Packet captures show if I request multiple /59 PD's, Comcast says I have them.

However, only ipv6 /64's in the firstly requested /59 fully route.

For those that fail, remote packet captures show the packets making it to my Comcast modem and failing.

Packet captures on my OPNsense box's WAN interface, show Comcast sending a neighbor solicitation packet and not getting a reply.  NOTE: for anything in the first PD requested, Comcast does not send NS requests.  It just sends the packets to OPNsense.

After frequent attempts to set this up and knocking parts of my family's internet out, I am just trying on one isolated test system.

I tried setting up os-ndp-proxy-go to have Comcast as the upstream interface and the downstream interface as the one connected to my test system as the downstream.

In that setup, via packet captures on OPNsense, I see Comcast send an NS to my WAN.  I see OPNsense send an NS to my test system.  I see my test VM send a Neighbor Advertisement.  I do not see an NA go out my WAN interface. 

NDP Proxy debug logs say that it is forwarding the NA to the upstream. 

Custom WAN dhcpv6.conf:

Code Select Expand

interface igb0 {
  send ia-na 0;
  send ia-pd 0;
  send ia-pd 1;
  send ia-pd 2;
  request domain-name-servers;
  request domain-name;
  script "/var/etc/dhcp6c_wan_script.sh";
};
id-assoc na 0 {
};
id-assoc pd 0 {
  prefix 2603:XXXX:XXXX:XX60::/59 infinity;
  prefix-interface igb2 {
    sla-id 26;
    sla-len 5;
    ifid 1;
  };
  prefix-interface igb1 {
    sla-id 0;
    sla-len 5;
  };
  prefix-interface igb3 {
    sla-id 30;
    sla-len 5;
  };
};
id-assoc pd 1 {
  prefix 2603:XXXX:XXXX:XXe0::/59 infinity;
  prefix-interface ix2 {
    sla-id 1;
    sla-len 5;
  };
};
id-assoc pd 2 {
  prefix 2603:XXXX:XXXX:XX20::/59 infinity;
};
NDP Proxy settings:

You cannot view this attachment.

NDP Proxy log saying it is forwarding the NA:

You cannot view this attachment.

[Monviech (Cedrik)]

The NDP proxy is primarily designed for on-link IPv6 prefixes advertised via Router Advertisements (SLAAC).

If you receive all your prefixes through DHCPv6 Prefix Delegation, the proxy cannot do much for your setup. It only learns and manages addresses within prefixes advertised by the upstream router via RA.

DHCPv6-PD prefixes should already be routed to your firewall by your ISP, without requiring NDP proxying.

https://docs.opnsense.org/manual/ndp-proxy-go.html#example-setup


If its really something weird with your Comcast modem, recently I added a prefix responder mode to the proxy where it can respond to any prefix you tell it, but unknown if it helps you. That feature is available in the current community version.

https://github.com/Monviech/ndp-proxy-go/blob/d4a0c05f20af2463644e5d7b39484f0584d89204/README.md?plain=1#L136

With the latest ndp proxy version the command line launch would probably look like this in your case:

Code Select Expand

ndp-proxy-go \
  --respond-prefix \
  --static-prefix 2603:XXXX:XXXX:XX60::/59 \
  --static-prefix 2603:XXXX:XXXX:XXe0::/59 \
  --static-prefix 2603:XXXX:XXXX:XX20::/59 \
  --no-ra \
  --no-routes \
  --debug \
  igb0


[really_lost]

Thanks.  Saying Comcast does with things odd with ipv6 is an understatement.  About a year ago, they released firmware that completely broke prefix delegation.

The RA from the modem just advertises the first /64 in the /56, so your explanation makes sense.

I'll try building from the repo just to test.  It looks like you added that feature in 1.04 and the OPNsense plug-in is 1.3_1.  I'm assuming it's as simple as uninstalling the plug-in and then compiling/installing from your repo?  Anything else I need to be aware of?  I've done lots of compiling/installing on various linux systems.  I've avoided doing it on OPNsense.

Any idea how long until the full plug-in will be updated?  And will updating the plug-in atop a custom build require anything special?

Thanks for the quick response!

[Monviech (Cedrik)]

Hello,

You just have to build the binary in freebsd 14, so you can run it on the business version (which is currently still freebsd 14.3)

I think the plugin will be updated end of october when the new business release 26.10 comes out, then you also get GUI for that feature (cause it already exists in the community version).

If you also want the plugin GUI earlier, there are ways to do it, but since you are on a business version it's usually not a good idea to install dev versions of a plugin, though also not harmful.

Its pretty much cloning the opnsense plugins repo, going into net/ndp-proxy-go and then issuing "make upgrade" inside that folder, then you get the latest plugin version (but not the binary, that you have to build yourself). I don't know if make upgrade still works though (community is already freebsd 15.1), might complain about the ABI now, but didnt test it for a while.

[really_lost]

Thanks. I can wait a few weeks and test the supported version. If not, I'll snapshot and try compiling.

In either case, I'll report back in this thread.