On Mon, May 10, 2021 at 12:05:16PM +0200, Bastien Durel wrote: > Referencing fe80::520f:80ff:fe65:8800%pppoe0 in pf.conf results in a > rule referencing fe80::520f:80ff:fe65:8800
I'm not sure where the scope id gets stripped, but the above may simply be a misleading cosmetic issue. pfctl -sr uses inet_ntop() to convert the address into printable format. It looks like this would never print the scope id (the %pppoe0 part of the address). The 'route get' command uses getnameinfo() instead, and getnameinfo() has special handling for the scope_id which inet_ntop() lacks. Someone would need to debug this to see if the scope id is present in the binary representation of the rule's address, or if the scope id was dropped somewhere on the way from pf.conf to the output of pfctl -sr. > pass in on pppoe0 inet6 reply-to fe80::520f:80ff:fe65:8800%pppoe0 Rergardless, I would expect the above rule to work without an extra entry in the routing table. Out of the box 'route get' displays the correct route. Try: route get fe80::520f:80ff:fe65:8800%pppoe0 On my system this correctly identifies the outgoing interface as pppoe0. And I have *not* done what you did below: > hostname.pppoe0: > !/sbin/route add -inet6 fe80::520f:80ff:fe65:8800 -ifp pppoe0 fe80::%pppoe0 > > This make pf able to route to the correct interface. In my opinion having to add an extra route for this is a bug. But I have no idea where :)
