I agree with you, however the implementation date may be “never”. So we either need a solution without VTI or a demonstration that no such solution is possible and that only the VTI would be a solution.
So can you confirm you do use the connection-mark assignment by mode-config to let RouterOS dynamically create the rule in src-nat chain? And if you do, can you paste the output of /ip firewall nat print chain=srcnat while the IPsec connection is active (I’m actually only interested in the dynamic rule itself and whether it is really added as the first one in chain=srcnat as I suppose)?
Anyway, there should be a remedy - a static IPsec policy action=none src-address=0.0.0.0/0 dst-address=the.client’s.subnet placed before the policy template which is used to build the dynamic policy with the responder-provided IP address as src-address. This action=none policy will shadow the dynamically generated one so even though the ICMP code 3 type 4 packet will likely get src-nated by the dynamic src-nat rule, it will not reach the dynamic policy (which would divert it into the tunnel) so it will make it to the client. The client won’t care about the source address as it has no relevance for it, so it should adjust the size of the re-sent TCP packet and all the subsequent ones accordingly.
That’s an interesting bit of information - I’ve first placed the rule only to chain=output and seen the TZSP packet to come with the bug. Then, I’ve added the same rule also to chain=postrouting, and the TZSP packets started coming in pairs, the first one with the bug and the second one without. I’m running 6.45.7 on hAP ac², can you test the same (both rules in place) and state your sw version and hw model?
OK, it seems I finally understand how you test. So once you disable the change-mss rule, you press Preview, and see whether the establishment of the new HTTPS connection succeeds or not. So you really can see the retransmissions to hammer, not each keypress in a working connection to trigger one ICMP packet. Good.