On 28 Feb 2025, at 1:20, Alexandr Nedvedicky wrote:

> 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:
>>
>> 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.
>
That makes sense, yes. The implication would be that we can’t sensible translate the remote IPv6 addresses to make traceroute work in that scenario, right?
In any event, fixing it for nat64 is a clear step forward, so we should do that regardless.

>> 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.
>
I’ve ported your patch to FreeBSD and run it through my test cases. That all passes.

Doing the extra translation as in the first version also worked, because it always ends up translating to the same address anyway. Still, less code and less work is better.

Best regards,
Kristof