Improper handling of packet fragmentation

[CosmicRay]

Hello,

While troubleshooting an issue with slow TCP startup, I did some tests from a Linux box using tracepath and ping -Mdo.  None of these tests made it past the openvpn box.  The route out is over a Wireguard VPN with a MTU of 1420. 

Regular pings work.

tcpdump from opnsense on the wireguard interface showed:

19:39:01.863080 IP (tos 0x0, ttl 64, id 7009, offset 0, flags [none], proto ICMP (1), length 56)
    x.x.x.x > x.x.x.x: ICMP 8.8.8.8 unreachable - need to frag (mtu 1420), length 36
   IP (tos 0x0, ttl 1, id 0, offset 0, flags [DF], proto UDP (17), length 1500)
    x.x.x.x.56499 > 8.8.8.8.44444: UDP, length 1472

However, this packet never made it back out the LAN interface.

If I add a normalization rule for "do not fragment" on the Wireguard interface, then the tracepath proceeds normally; however, it also fails to detect that the path MTU is less than 1500, which no doubt will result in a mess of fragmented packets.

Is there any solution here?

[Maurice]

Did you assign the Wireguard interface?

[CosmicRay]

Yes.  Interface assigned, gateway assigned, and a standard NAT and route.

I wonder if part of the challenge here is that the VPN provider here assigns a /32, so both the from and to address on the ICMP packet are the same, and to the firewall it might look as if it originated on the firewall itself?