This topic is about ICMP 3/4 packets returned to the client.
You can test that by pressing or click the preview button when writing a posting in this forum.
No preview, or it takes a long time (more than a few seconds) then you are suffering from this and then follow the instructions underneath
I am using IPSEC for a long time and first a mix of L2TP/IPSEC and later IKEv2. Had problems with the MTU on L2TP/IPSEC and hoped that was over when I replaced it with IKEv2. IKEv2 was much nicer to use and much faster. However I had still a small problem with the MTU when using a speedtest.net page and later I noticed that the Mikrotik forum offered a much faster to detect the problem.
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:
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
The code is disabled because Sindy found a much better way using a work around for this problem.
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: http://forum.mikrotik.com/t/undecoded-packets/134293/11
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:
/ip ipsec policy
move *ffffff destination=0
add action=none dst-address=192.168.88.0/24 src-address=0.0.0.0/0 place-before=1
place-before=1 and move *ffffff destination=1 added on 17-4-2020
Replace dst-address=192.168.88.0/24 with your own local network address range.
The default template will be moved to the top of the list if it was not already there. The second line should above (action=none) should be below default and above any added IKEv2 provider lines.
The explaination by Sindy.
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.
This solved my long standing problem. with that work around and many many thank to Sindy for suggesting this!
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.
