Hello, I did check things with tpcdump. And it looks like pf(4) is doing the right thing. let me explain.
To play with pf(4) I'm using same network set up as we use for regression testing [1] [1] https://github.com/openbsd/src/blob/master/regress/sys/net/pf_forward/Makefile </snip> > >How-To-Repeat: > Load a rule in PF that translates IPv4 to IPv6: > > pass in inet af-to inet6 from 2001:db8::1 to 64:ff9b::/96 > on host pf I'm running firewall with rule as follows: pass in on vio1 inet from 10.188.210.0/24 to 10.188.211.123 flags S/SA \ af-to inet6 from fdd7:e83e:66bc:211:5054:ff:fe12:3450 to \ fdd7:e83e:66bc:211:5054:ff:fe12:3451 > On an IPv4 client machine with the OpenBSD box as its gateway, > generate a packet that's too big to transmit once it's translated: > > ping -D -s 1472 8.8.8.8 I start test trying to reach host rt on its IPv4 address. I start with payload size 1472: (1) src$ ping -D -s 1472 10.188.211.51 PING 10.188.211.51 (10.188.211.51): 1472 data bytes 1480 bytes from 10.188.211.51: icmp_seq=0 ttl=254 time=3.234 ms ^C --- 10.188.211.51 ping statistics --- 1 packets transmitted, 1 packets received, 0.0% packet loss round-trip min/avg/max/std-dev = 3.234/3.234/3.234/0.000 ms now repeat with payload size 1473: (2) src$ ping -D -s 1473 10.188.211.51 PING 10.188.211.51 (10.188.211.51): 1473 data bytes ping: sendmsg: Message too long ping: wrote 10.188.211.51 1501 chars, ret=-1 ^C --- 10.188.211.51 ping statistics --- 1 packets transmitted, 0 packets received, 100.0% packet loss ping command reports error. so far so good. Let's get the af-to rule into action now. To do it we need ping to reach address 10.188.211.123 which gets translated to IPv6 fdd7:e83e:66bc:211:5054:ff:fe12:3451. This time I start with payload size 1450: (3) src$ ping -D -s 1450 10.188.211.123 PING 10.188.211.123 (10.188.211.123): 1450 data bytes 1458 bytes from 10.188.211.123: icmp_seq=0 ttl=63 time=2.825 ms 1458 bytes from 10.188.211.123: icmp_seq=1 ttl=63 time=1.597 ms ^C --- 10.188.211.123 ping statistics --- 2 packets transmitted, 2 packets received, 0.0% packet loss round-trip min/avg/max/std-dev = 1.597/2.211/2.825/0.614 ms the next attempt goes with payload size 1472: (4) src$ ping -D -s 1472 10.188.211.123 PING 10.188.211.123 (10.188.211.123): 1472 data bytes ^C --- 10.188.211.123 ping statistics --- 4 packets transmitted, 0 packets received, 100.0% packet loss Indeed, unlike the case (2), there is no error reply. Let's see what happens on wire, while ping is running. src# tcpdump -i vio1 tcpdump: listening on vio1, link-type EN10MB 12:14:09.651371 10.188.210.10 > 10.188.211.123: icmp: echo request (DF) 12:14:09.652008 10.188.211.123 > 10.188.210.10: icmp: \ 10.188.211.123 unreachable - need to frag (mtu 1480) (DF) 12:14:10.654563 10.188.210.10 > 10.188.211.123: icmp: echo request (DF) 12:14:10.655747 10.188.211.123 > 10.188.210.10: icmp: \ 10.188.211.123 unreachable - need to frag (mtu 1480) (DF) 12:14:11.654456 10.188.210.10 > 10.188.211.123: icmp: echo request (DF) 12:14:11.655567 10.188.211.123 > 10.188.210.10: icmp: \ 10.188.211.123 unreachable - need to frag (mtu 1480) (DF) so there actually is ICMP error message for ICMP probe. Taking a closer look at those packets I could see the TTL in IP header is 0 which itself is odd and requires further investigation. Packet dump is attached in icmp.pkt file. there is a one more test to be done to see if ping(8) command is able to process TOOBIG icmp error it receives. Note that error in case (2) comes from local IP stack when ICMP probe with large payload is dispatched to wire. For this test I'm going to ping host eco. The MTU between host eco and rt is set to 1300. src$ ping -D -s 1293 10.188.212.52 PING 10.188.212.52 (10.188.212.52): 1293 data bytes ^C --- 10.188.212.52 ping statistics --- 3 packets transmitted, 0 packets received, 100.0% packet loss the attached icmp-eco.pkt shows regular ICMP too big messages which come from host rt. Looks like ip stack at host src fails to indicate error to ping(8) command when those ICMP error are received. I have not looked at ping(8)/ip stack why this happens. thanks and regards sashan
icmp.pkt
Description: Binary data
icmp-eco.pkt
Description: Binary data
