ndppd and tun/wg interfaces

[bilkusg]

If you run ndppd to listen on a tun interface created by openvpn or a wireguard wg interface, the data sent to the raw socket doesn't contain an ethernet header.

As a result, ndppd's filters drop the received neighbor solicitation, and even if you tweak the filters, the hard-coded skipping of an ethernet header from the raw data causes the packet decode to produce garbage.

I don't know if this is a deliberate design decision, but it doesn't seem to be documented anywhere and might save others a bit of time to know.

I've reproduced this behaviour on several versions of linux 5.x kernels.

[bilkusg]

I've done some more investigating and found what I think is a fix for the issue. If the pfd socket is opened as a SOCK_DGRAM rather than SOCK_RAW, the ethernet header is always stripped out. By adjusting the offsets in the filters and parsers accordingly, the result seems to work properly on both physical and virtual interfaces. I haven't extensively tested it, but I've forked the repo and put the relevant changes in at bilkusg/ndppd for anyone interested in trying it.

[houmie]

Hi @bilkusg,

Thank you so much for reporting this here. Have you actually got ndppd working with OpenVPN (tun) interface?

I have pulled your fork and compiled it.

sudo vim /etc/ndppd.conf

route-ttl 30000
proxy eth0 {
router yes
timeout 500
ttl 30000
rule 2a01:4f8:1c17:d9e7::/64 {
static
}
}

Then I ran it like this: sudo /usr/local/sbin/ndppd -d

I'm using the VPS IP range that was allocated to me. However IPv6 still doesn't get assigned to my OpenVPN client.

sudo vim /etc/network/interfaces.d/50-cloud-init

iface eth0 inet6 static
    address 2a01:4f8:1c17:d9e7::1/64
    gateway fe80::1

What could I be missing, please?