On 2022/04/29 22:08, Alexandr Nedvedicky wrote:
> Hello Ian,
>
> </snip>
>
> > However, this does not work with IPv6, because vlan10 translates to the
> > link-local address (fe80::) instead of the real address on the interface.
> >
> > This is a bug, IMO. I'm not sure why you'd want the link local address in
> > there... and to my knowledge, there isn't a way of forcing it to use the
> > real
> > IP.
> >
>
> I vaguely remember Paul de Weerd reported similar issue two years ago [1]
> there were also some discussion inside OpenBSD community. Also few
> patches with appeared, but none of them got accepted.
I have some recollection of this. This may be a little more complex
than it first seems too, for block/pass rules I would expect that
a link-local _would_ be matched, whereas you probably do want them
skipped for address translation. Presumably "vlan10:0" would skip
link-local and pick one of the other addresses, but the other
question is whether "vlan10" would expand to all addresses on the
interface, or all addresses on the interface except any link-local
address(es).
> > While i'm on, can I also suggest:
> >
> > - :0 can be used as a modifier to not add alias addresses. Can I request the
> > ability to have further integers to select which IP should be used, eg: :1
> > should be the second address etc.
>
> I think this idea was rejected. If I remember correct one of the issue
> is there is no solid API/mechanism to assign indexes to IP addresses
> bound to interface. Think of a situation where there are 5 addresses
> bound to em0:
> 1.2.3.1:0
> 1.2.3.2:1
> 1.2.3.3:2
> 1.2.3.4:3
> 1.2.3.4:4
>
> let there be a rule in pf:
> pass in on em0 from any to em0:3
>
> now how we are going to deal with situation when address :2
> disappear? shell we keep indexes assigned? shell we reindex?
> how this should work for dynamic variant: ... any to (em0:3)
> there is still more question than answers.
>
> I agree it appears fairly simple at first glance, but it's not.
+1
> > - The ability to do { inet, inet6 } to have a single rule for both ipv4 +
> > ipv6 and it be expanded out.
>
> I'm afraid this would be pretty big change to pf. I'm just curious:
> what kind of advantage single rule for both address families brings?
> in other words why do you need it?
Normally you don't need it because you can omit the af:
$ echo 'pass out !received-on any' | pfctl -nvf -
pass out all !received-on any flags S/SA
but that doesn't work if you want to use NAT:
$ echo 'pass out !received-on any nat-to lo1:0' | pfctl -nvf -
stdin:1: translation spec contains addresses with different address families
stdin:1: skipping rule due to errors
stdin:1: rule expands to no valid combination
It's easy enough to workaround though (at least, it would be if "nat-to
interface:0" skipped link-locals).
$ echo 'pass out inet !received-on any nat-to lo1:0
> pass out inet6 !received-on any nat-to lo1:0' | pfctl -nvf -
pass out inet all !received-on any flags S/SA nat-to 195.95.187.13
pass out inet6 all !received-on any flags S/SA nat-to fe80::1
I think this would just be a change to pfctl (not PF itself), similar
to how proto {udp tcp} are expanded. On the other hand, I don't think
it's going to be very widely used and I can't think of a situation
where this is going to save many lines of pf.conf.
