I'm working on setting up an OpenBSD box to perform CLAT services for 464XLAT on my network. v4-only clients will be behind the pf box, which uses af-to to translate v4 packets to v6 and send them to my border NAT64 gateway.
Things are working pretty well, but I've bumped into an issue with large packets. If the v4 client sends a max-size packet (1500 bytes), it looks like the pf box is silently dropping them. I've tested this by setting DF on an ICMP ping that is too big to fit in an IPv6 packet (1453 bytes). tcpdump shows the packet arriving on the pf box, but not leaving. Because the IPv6 headers are 20 bytes bigger, this makes sense (the resulting translated packet is too large). I was hoping that pf would return an ICMP type 3, code 4 (dest unreachable/fragmentation needed), but I'm not getting anything back. I have a default "pass out" rule so I don't believe I am blocking any ICMP sourced by the pf box. Without the ICMP feedback, the v4 client is unaware of the v6 bump in the path (essentially, the MTU is reduced to 1480), and path MTU discovery cannot detect it. Am I missing any config, or does af-to not generate ICMP messages in this circumstance? As a workaround I tried to find a pf rule to filter on packet size, but that doesn't exist either. I did add a scrub rule for max-mss, and that has helped with TCP. However, I was hoping to get full coverage on UDP and ICMP as well. I'm going to try lowering the MTU on the clients, but some of them are IoT garbage that doesn't give me access to those settings, so pmtud is really my best bet. Thanks, Jason
