We have a long tradition of me not understanding what you actually mean by what you write. Whether this effect is bi-directional is unknown to me 
So in this case, are you saying that these packets appear as you browse the forum but nevertheless the browsing works even while the MSS-changing rule is disabled? Because normally, the Path MTU Detection works with a single ICMP feedback per each bottleneck - when a packet with Don’t Fragment bit set comes to a router where it doesn’t fit to the MTU of the outgoing route, that router sends back an ICMP type 3 code 4 message indicating the available MTU, and the sender network stack or application takes the necessary action (which is, in case of TCP stack, to send a smaller portion of the inupt buffer in a packet just fitting the MTU reported by the ICMP type 3 code 4 message, again with the DF flag set, in order to eventually identify an even narrower bottleneck downstream to the destination). In case of TCP, the whole goal is to slice the incoming payload stream into small enough TCP packets already at source instead of letting them be fragmented during transmission, because fragmentation during transmission uses more overhead data than sending smaller packets at source.
So I can imagine the sender to be hammering the destination with retransmissions of too-large-to-fit packets with DF set but never receivind the ICMP type 3 code 4 reports back, but I cannot imagine the resulting connection to ever be set up. That’s why I am double-checking whether I have understood you well this time.
And here we may be coming to the reason why the PMTUD doesn’t work well in this direction. I remember you used to have a very specific setup of two piggybacked routers, but this may have changed in the meantime. In any case, these ICMP type 3 code 4 messages do not directly match the tracked connection they are related to. So the connection tracking module of the firewall identifies them as related to an existing tracked connection, and labels them with connection-state=related, by checking the contents of their payload (where the IP and TCP header of the triggering packet are copied). Hence a filter rule action=accept connection-state=…,related,… must exist in order that these ICMP packets could pass through the firewall. Is this the case all the way from the router which generates these packets to the client PC?
These ICMP towards the client (i.e. triggered by too-large-to-fit packets sent in client->server direction) are generated by the router doing the IPsec encapsulation. The IPsec transport packet is bigger than the payload packet it transports by the size of the encapsulation headers, so if the resulting transport one doesn’t fit to the MTU of its out-interface, the router performing the encapsulation sends an ICMP type 3 code 4 packet back to the address of the client from its own address - that’s why you can see this packet in the postrouting and/or output chain on that router.
So I’d first of all sniff for these packets on the client-facing physical interface of the router generating them, using the “sniff to file” functionality (so that you could distinguish those caught by the mangle rule from those caught by sniffing on the interface if doing both simultaneously). If they are caught by the sniff-tzsp mangle rules, but aren’t visible in the sniff on the physical interface, they are generated or routed improperly.
This happened also when I was using L2TP/IPSEC before I switched to IKEv2.