Hello Kristof,

I did try to check the issue on a testbed I'm using. My set up
matches configuration for PF regression tests described here:

    https://github.com/openbsd/src/blob/master/regress/sys/net/pf_forward/Makefile

There are four hsts:
	SRC PF RT ECO

To check the issue hosts ECO, RT and PF interface facing towards
RT are running IPv6.  host SRC is connected to PF using IPv4.

host PF uses rule as follows:

    pass in on vio2 inet6 from any to 64:ff9b::/96 af-to \
	inet from 10.188.64.64 to 0.0.0.0/0

I'm doing a traceroute from ECO to SRC:

    eco# traceroute6  64:ff9b::10.188.210.10 
    traceroute6 to 64:ff9b::10.188.210.10 (64:ff9b::abc:d20a), 64 hops max, 60 byte packets
     1  fdd7:e83e:66bc:212:5054:ff:fe12:3450 (fdd7:e83e:66bc:212:5054:ff:fe12:3450)  2.584 ms  0.85 ms  0.95 ms
     2  * * *
     3  64:ff9b::abc:d20a (64:ff9b::abc:d20a)  3.508 ms  1.967 ms  1.947 ms

hop number 2 (* * *) is firewall itself. I suspect it fails to
send ICMP error message. firewall's ip stack sees packet as translated
with source address changed to 10.188.64.64, there is no route where
to send those packet. Adding a route does not help either
because reply sent by firewall's ip stack does not match state
created by af-to so we see ICMPv4 error travelling on wire.

back to the issue you are reporting here.  I was intercepting packets at IPv6
interface on PF hosts. packet dump is attached. It looks like ICMPb6 payload is
handled correctly by af-to. I'm using OpenBSD-current.
I'm attaching the packet dump.

thanks you for reaching tech@

regards
sashan

• af-to.pkt (37K)