Community discussions

MUM Europe 2020
 
msatter
Forum Guru
Forum Guru
Topic Author
Posts: 1354
Joined: Tue Feb 18, 2014 12:56 am
Location: Netherlands / Nīderlande

MTU troubles using IKEv2 providers like NordVPN [work around]

Tue Dec 03, 2019 3:27 pm

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: 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=168.192.88.0/24 src-address=0.0.0.0/0

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.
Last edited by msatter on Tue Jan 14, 2020 11:47 pm, edited 1 time in total.
Two RB760iGS (hEX S) in series. One does PPPoE and both do IKEv2.
Running:
RouterOS 6.46.1 / Winbox 3.20 / MikroTik APP 1.3.9
Android device owners, use https://github.com/M66B/NetGuard/releases (no root required)
 
User avatar
eworm
Member
Member
Posts: 447
Joined: Wed Oct 22, 2014 9:23 am
Location: Oberhausen, Germany
Contact:

Re: MTU troubles using IKEv2 providers like NordVPN [work around]

Tue Jan 14, 2020 11:09 pm

You should remove the extra disabled=yes from your code.

I can confirm this workaround works. Any news from Mikrotik about fixing this?
Manage RouterOS scripts and extend your devices' functionality: RouterOS Scripts
 
msatter
Forum Guru
Forum Guru
Topic Author
Posts: 1354
Joined: Tue Feb 18, 2014 12:56 am
Location: Netherlands / Nīderlande

Re: MTU troubles using IKEv2 providers like NordVPN [work around]

Tue Jan 14, 2020 11:56 pm

Thanks and the disable=yes is removed.

I don't know. Support did not confirmed this workaround or commented on it. The ticket is still open and you never know what 2020 is going to bring. ;-)
Two RB760iGS (hEX S) in series. One does PPPoE and both do IKEv2.
Running:
RouterOS 6.46.1 / Winbox 3.20 / MikroTik APP 1.3.9
Android device owners, use https://github.com/M66B/NetGuard/releases (no root required)

Who is online

Users browsing this forum: No registered users and 95 guests