Hi Alexandr,

On 27 Feb 2025, at 2:22, Alexandr Nedvedicky wrote:
> Hello Kristof,
>
> I see the problem now. thanks for clarification. after slightly changing
> my setup I can confirm OpenBSD current has the same bug. Fix below seems to
> work for on OpenBSD. If I understand the issue right we need to combine 6to4
> prefix defined in af-to rule with IPv4 source address seen in IP packet which
> carries ICMPv4 error. I think your fix is very similar (modulo differences
> between pf on FreeBSD and OpenBSD).
>
That looks conceptually similar to what I’ve done, yes.
It’s maybe even a bit better (easier, certainly) to re-use the state’s address to find the nat64 prefix rather than going through inet_nat64() again as I’ve done.

I think the only issue may be one I have too: I only handle the nat64 case, and I believe af-to is also supposed to support nat46. I’ve not tested nat46 at all though, and don’t claim to understand how it’s supposed to work.

I also didn’t make any changes for the pf_icmp_mapping() == 0 case (i.e. it’s an ICMP query/reply not related to a TCP/UDP packet). In that case we do the state lookup based on the ICMP packet’s source address (and destination and type and code, of course). So I don’t think we can have a situation where the packet’s source address doesn’t match the one for the state we found.

Unlike the pf_icmp_mapping() != 0 case, where we do the state lookup based on the information in the ICMP packet payload rather than the packet itself, so it is possible for the ICMP packet’s source address to be different from the source address in its payload.

Best regards,
Kristof