On Mon, 27 Jan 2020, Paul de Weerd wrote:
> Hi all,
>
> Following up from my previous (PEBKAC) issue[1], I kept working on my
> ruleset. I found, what I believe to be, another issue. Here's the
> reduced ruleset that reproduces the problem:
> [snip details]
>
> The problem is in the IPv6 rules. Here "em1:network" expands to the
> global unicast network configured on the interface but "em1:0" expands
> to the link-local address. This doesn't really make sense to me. If
> both would expand to the link-local version, that would be unfortunate
> but understandable. I'm hoping to have both expand to the global
> unicast version ("from 2a02:898:28:300::/64 to ! 2a02:898:28:300::1").
>
> Why is pfctl picking different addresses for these two modifiers?
> [...]
> Is there a way to tell pf to use the global unicast address for em1:0
> other than hardcoding the address in the ruleset?
Hi Paul,
Does the patch below help?
I think you have found an oversight in the original implementation of
':0', which defines a non-alias as the first defined address (of the given
address family) [0]. The patch makes ':0' skip link-local addresses,
matching the behaviour of ':network'.
best,
Richard.
[0] sbin/pfctl/pfctl_parser.c 1.186 ifa_lookup()
Index: sbin/pfctl/pfctl_parser.c
===================================================================
RCS file: /cvs/src/sbin/pfctl/pfctl_parser.c,v
retrieving revision 1.342
diff -u -p -u -p -r1.342 pfctl_parser.c
--- sbin/pfctl/pfctl_parser.c 17 Oct 2019 21:54:28 -0000 1.342
+++ sbin/pfctl/pfctl_parser.c 28 Jan 2020 03:11:27 -0000
@@ -1546,6 +1546,8 @@ ifa_lookup(const char *ifa_name, int fla
continue;
if ((flags & PFI_AFLAG_NETWORK) && p->ifindex > 0)
continue;
+ if ((flags & PFI_AFLAG_NOALIAS) && p->ifindex > 0)
+ continue;
if (last_if == NULL || strcmp(last_if, p->ifname))
got4 = got6 = 0;
last_if = p->ifname;
