Using Wireshark and the following line in Mangle I could detect the ICMP 3/4 packets getting lost in the RouterOS and so not arrive at the client telling it to lower the MTU.
add action=sniff-tzsp chain=postrouting icmp-options=3:4 log=yes log-prefix=post-ICMP protocol=icmp sniff-target=192.168.21.177 sniff-target-port=37008
I used this step for step optimized MSS line to reduced the MTU to a fixed value which dynamically could not be found:
The code is disabled because Sindy found a much better way using a work around for this problem.
add action=change-mss chain=forward disabled=yes ipsec-policy=in,ipsec log-prefix=MSS new-mss=1382 passthrough=yes protocol=tcp tcp-flags=syn
Sindy and I spend a good part of a weekend discussing this and ending up with a work around that ended my quest on this strange behavior. When the ICPM 3/4 packets get lost in RouterOS the data sent to Wireshark gets Network type: unknown 0x0000 what is very strange but an other support ticket.
The thread from that weekend: viewtopic.php?f=2&t=153414&p=760818&hil ... ge#p760818
About the ICMP 3/4 packets not being sent to the client is still a support ticket with Mikrotik and despite several suggestion by them it is still not resolved so I have to keep using the work around.
So what is happening. When using IKEv2 in this case all traffice is going through a tunnel between RouterOS and the VPN provider. RouterOS handles everything so most of the traffic is outside of view of the user. The MTU is determined and used except when the client is 'uploading' traffic then the MTU is not changed resulting in no upstream traffic or RouterOS switch to the emergency MTU of 576/536 resulting in a very low transfer rate but at least there is a traffic flowing upstream.
Sindy brilliant work around is, to use IPSEC policy and create a static policy handling the packets instead of the dynamically generated ones and the position in the policy list does not matter:
add action=none dst-address=126.96.36.199/24 src-address=0.0.0.0/0
The explaination by Sindy.
This solved my long standing problem. with that work around and many many thank to Sindy for suggesting this!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.
O, how to test in the Mikrotik forum? That is not too difficult and if you are writing now a reply or editing an previous post you can press the Preview button and when you have the sniffer line active and Wireshark running you will see those unknown packet pop-up in Wireshark. Then is your IKEv2 and maybe IPSEC connection falling back to emergency MTU.