IPSec MTU/ MSS issue

RouterOS General
1

Hello I need your advice,

I havea working side 2 side VPN from my office to a custumer. My clients are connecting a VDI infrastrukture based on VMWare. The used protokoll is PCoIP(4172) UDP. Sometimes the local client ist loosing the mouse and keyboard and we have to close the VMWare Horizon client and start the work again. This is very frustrating due to the fact that we can't reconnect to the same VDI Windows client.

After some research I found a KB article that the VDI works wih a default MTU 1300. So I tried to change the MSS via magle rule for traffic going to the VDI but I did'nt see any traffic statistics with a changed MSS on the magle rule.

ip firewall mangle print stats

CHAIN ACTION BYTES PACKETS

0 ;;; internal-traffic packet mark
prerouting mark-packet 23 088 843 371 132 885 040
1 forward change-mss 0 0

Here are my settings.

NAME TYPE ACTUAL-MTU L2MTU MAX-L2MTU MAC-ADDRESS

0 R WAN ether 1500 1580 10222 E4:8D:8C:10:E9:04
4 R ether5 ether 1500 1580 10222 E4:8D:8C:10:E9:08

ADDRESS NETWORK INTERFACE

0 ;;; public_IP_03
x.x..x.253/29 x.x.x.248 WAN
4 ;;; PROD_AKTUELL
10.230.96.1/24 10.230.96.0 ether5
7 ;;; VPN-NAT-E
10.160.200.17/28 10.160.200.16 ether5

/ip firewall nat
add action=src-nat chain=srcnat comment=E_NAT dst-address=10.208.217.0/24 log=yes log-prefix=ewe_nat src-address=10.230.96.0/24 to-addresses=10.160.200.17
add action=masquerade chain=srcnat dst-address=0.0.0.0/0 out-interface=WAN src-address=10.230.96.0/24

/ip firewall mangle based on a forum post,, are the endpoints correct or do I have to use the src-nat endpoint on my side?
chain=forward action=change-mss new-mss=1260 passthrough=yes tcp-flags=syn protocol=tcp src-address=10.230.96.0/24 dst-address=10.208.217.0/24 tcp-mss=!0-1260
log=yes log-prefix="mss_change"

ip ipsec peer print
;;; E
address=x.x.195.84/32 auth-method=pre-shared-key secret="secret" generate-policy=no policy-template-group=E exchange-mode=main
send-initial-contact=yes nat-traversal=no proposal-check=obey hash-algorithm=sha1 enc-algorithm=aes-256 dh-group=modp1024 lifetime=8h dpd-interval=30s
dpd-maximum-failures=5

ip ipsec policy print
A ;;; E
src-address=10.160.200.16/28 src-port=any dst-address=10.208.217.0/24 dst-port=any protocol=all action=encrypt level=unique ipsec-protocols=esp tunnel=yes
sa-src-address=x.x.8.253 sa-dst-address=x.x.195.84 proposal=E_proposal priority=0 ph2-count=1

So my question is, how can I be sure that the MTU has changed?
Whe I run the tools:
mturoute -4 10.208.217.245 I receive a Path MTU: 1406 bytes.

mtupath -4 10.208.217.245 MTU path scan to 10.208.217.245, ttl=64, limit=48

16 processing - best MSS 1378 (estimated MTU 1406) [pPPPPpPpPppPPPPp]

#1 MSS IN RANGE 1 <== 1377 ==> 1378
#2 MSS EXCEEDED 1379 <== 15005 ==> 16384

kind regards
Maedo

2

Hello,

Would setting up a RAW firewall for that subnet to action=“no track” work out for you?

Do you have any insight to limit MTU for over Ipsec?

thank you

3

First, a great way to test if MTU is actually your problem. Set the MTU of your client PC to 1300 and see if it happens. If it doesn’t then blamo you have diagnosed it correctly as an MTU issue.

Next let’s talk about MSS. MSS != MTU. They are not the same thing. MSS is TCP specific and will do absolutely nothing to a UDP flow. They are related but far from the same. Also PCoIP for the Horizon Windows client will use either UDP or TCP. So before we dive deep. Verify if you are using UDP or TCP and then check the DF bit status. This can be done with WireShark on the client PC. If it’s a Windows PC you can download a stand-alone exe file that will just run and not install. You’ll want to identity traffic for the Horizon client, most likely this can be done by inspecting the destination IP or port. Here’s a screenshot of where to find the DF bit, UDP or TCP should be fairly self explanatory.
MikroTik-Forums_IPSec-MTU-MSS_1.png
When we know the details, client MTU of 1300 resolves it, UDP or TCP and DF bit set or not we can move on with next steps. Here is a link to another post where I dive into MTU and MSS a little deeper. It also has a link at the bottom of it to show how tunneling (in that case EoIP and GRE) impact MTU.

http://forum.mikrotik.com/t/gre-tunnel-setup-help/108436/2

^^ MTU is at the bottom of that rather long post.

EDIT: Just read your post again and caught that you indicated it is UDP. This means for sure MSS will not affect the traffic. Try adjusting the MTU on a client as a quick test. I bet that will fix your problem. If it does we can dive into the better ways to fix this site-to-site VPN long term. Also WireShark it to see if the DF bit is being set.

4

For Reference:

https://wiki.mikrotik.com/wiki/Manual:IP/Firewall/Mangle#Change_MSS

Change MSS
It is a well known fact that VPN links have smaller packet size due to encapsulation overhead. A large packet with MSS that exceeds the MSS of the VPN link should be fragmented prior to sending it via that kind of connection. However, if the packet has DF flag set, it cannot be fragmented and should be discarded. On links that have broken path MTU discovery (PMTUD) it may lead to a number of problems, including problems with FTP and HTTP data transfer and e-mail services.

In case of link with broken PMTUD, a decrease of the MSS of the packets coming through the VPN link solves the problem. The following example demonstrates how to decrease the MSS value via mangle:

/ip firewall mangle
add out-interface=pppoe-out protocol=tcp tcp-flags=syn action=change-mss new-mss=1300 chain=forward tcp-mss=1301-65535