I see ICMP6 neighbor solicitation in tcpdump, but ndppd doesn't seem to be doing anything

[ghost]

debug output from ndppd with configuration

[root@avps ~]# ndppd -vvv
(notice) ndppd (NDP Proxy Daemon) version 0.2.4
(notice) Using configuration file '/etc/ndppd.conf'
(debug) {
(debug)     address-ttl 30000 
(debug)     proxy eth0 {
(debug)         autowire no 
(debug)         keepalive yes 
(debug)         promiscuous no 
(debug)         retries 3 
(debug)         router yes 
(debug)         rule 2605:a140:2045:1635::/64 {
(debug)             autovia no 
(debug)             static 
(debug)         }
(debug)         timeout 500 
(debug)         ttl 30000 
(debug)     }
(debug)     route-ttl 30000 
(debug) }
(warning) Low prefix length (64 <= 120) when using 'static' method
(debug) fd=3, hwaddr=0:50:56:40:a1:2d
(debug) iface::allmulti() state=1, _name="eth0"
(debug) proxy::create() if=eth0
(debug) rule::create() if=eth0, addr=2605:a140:2045:1635::/64, auto=no
(debug) iface eth0 {
(debug)   proxy 230b7e0 {
(debug)     rule 230b8d0 {
(debug)       taddr 2605:a140:2045:1635::/64;
(debug)       static;
(debug)     }
(debug)   }
(debug)   parents {
(debug)   }
(debug) }
(debug) iface::fixup_pollfds() _map.size()=1

And here is example of tcpdump output when I ping a random address in the block:

15:46:54.961970 IP6 2607:fb90:28c9:1893:1802:f5bb:3bb4:96cf > 2605:a140:2045:1635::1234: ICMP6, echo request, seq 1, length 40
15:46:54.962327 IP6 avps.owo69.me > ff02::1:ff00:1234: ICMP6, neighbor solicitation, who has 2605:a140:2045:1635::1234, length 32
15:46:56.006641 IP6 avps.owo69.me > ff02::1:ff00:1234: ICMP6, neighbor solicitation, who has 2605:a140:2045:1635::1234, length 32
15:46:57.030647 IP6 avps.owo69.me > ff02::1:ff00:1234: ICMP6, neighbor solicitation, who has 2605:a140:2045:1635::1234, length 32
15:46:58.054833 IP6 avps.owo69.me > 2607:fb90:28c9:1893:1802:f5bb:3bb4:96cf: ICMP6, destination unreachable, unreachable address 2605:a140:2045:1635::1234, length 88

And nothing is outputted from ndppd debug.

I used this information: http://blog.iopsl.com/ndppd-on-vultr-to-enable-fully-routed-64-for-ipv6/

[rodolfoul]

I have the precise same problem. But ndppd will ocasionally work. Seems like some of the Solicitations are successfully proxied, while some aren't. It's as if the ndppd's poll for solicitations gets only a part of all made solicitations, and those that are relevant end up getting left behind and not proxied.

[rodolfoul]

Ok, maybe for future reference. I had an issue on routing table. Seems like having two equally preffixed ipv6 interfaces messes up routing. That is, neighbor discovery packets were going through the wrong interface.

So all I had to do was fix it manually and ndppd started working perfectly.

[houmie]

@ledlamp I have the exact same issue. Have you been able to resolve this, please?

[ghost]

@houmie nope, sorry. ndppd just won't seem to do anything. I even tried a /128.

and my ipv6 routes appear to be fine. the packets are definitely going to the right interface.

[houmie]

Yes, I have done some research and it's been reported that this project doesn't work anymore.

See here: https://quantum2.xyz/2019/03/08/ndp-proxy-route-ipv6-vpn-addresses/

"The common wisdom is to run ndppd, a program that answers neighbour solicitation requests. It can be thought of as a replacement for the kernel’s NDP proxying feature. However, it has been relatively unmaintained, and multiple users reported that it does not work anymore. It did not work for me either."

It seems dnsmasq is a better solution. I haven't tried it yet.

[SpareSimian]

I've successfully used ndppd as packaged in the EPEL repository on my CentOS 7 gateway when communicating with AT&T's "Business in a Box" gateway. Their gateway wasn't configured to route through mine so I used ndppd to accomplish that. I've temporarily disabled IPv6 on my gateway as the AT&T gateway was intermittently losing its VOIP and IPv6 ability (while IPv4 continued working). But while it was up, ndppd worked great. I believe the EPEL version is packaging the master branch, not the new experimental branch. So maybe the criticism of not working only applies to the newer branch.

[shamefulCake1]

Turn on promiscuous mode.

Maybe by the config file setting, maybe by just manually setting it on the interfaces you are using.