Hello Kristof,

On Thu, Feb 27, 2025 at 03:24:43PM +0100, Kristof Provost wrote:
> 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).
> >
</snip>

> 
> 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 was thinking about that. the way I see NAT from 4 -> 6 is very
    similar to dNAT in IPv4 (rdr-to). Where NATing firewall translates
    incoming SYN packet to addresses in private network. The remote
    host is connecting to public IP facing to WAN. Firewall translates
    that to IP address from private network.

    I feel the case of 4->6 is similar. IPv4 host connects to some
    IPv4 address and firewall translates that to IPv6 and forwards
    the packet to IPb6 network. The last hop IPv4 client sees
    is the public IP address of firewall. That's my understanding.

> 
> 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.
> 

    I think you are right. For case pf_icmp_mapping() the packet should be
    sent by destination host as found in state. I will adjust my diff.

thanks and
regards
sashan