We have a customer that has a Meraki MX device, using an IPSec tunnel, I could assume the default vpn options has been configured which are : Nat-T with ESP on Meraki
The Meraki then connected directly to get the internet from a Mikrotik router, the Mikrotik Router has a PPTP tunnel towards a remote Datacenter to get the internet through for different measurements .
So its an IPSec over a PPTP link .. I can’t change the MTU from the Meraki side neither I think I can change the MSS in the Mikrotik router directly attached to it, coz I will break the IPSec packet .. I guess ?
What might be a possible solution for this scenario ?
To be honest I don’t understand what is your goal.
The actual MTU cannot be changed; some tunneling protocols can be set to silently fragment the transport packets, indicating a higher MTU on their virtual interface. IPsec uses no virtual interfaces (at least in current RouterOS releases) so this silent fragmentation option is not available there. Is the Meraki a network probe and it sends the captured traffic using UDP, or why is the MTU on the uplink important?
Simply the Mikrotik device is from an ISP they are providing the internet connection, the customer owns the Meraki and the Meraki IPsec doesn’t work !
I think the NAT-T is enabled in the Meraki, so it uses UDP packets, and ESP not Transport mode, But for the Meraki the Mikrotik is “nothing” but an internet source, the pptp is something between the customer Mikrotik CPE (provided by the ISP) and another Mikrotik in a far datacenter.
So in short the Ipsec from Meraki has to go through the pptp tunnel that is made . The pptp by default can carry up to 1450 Byte, with mrru I have changed that to carry the full 1500 Byte packet, ping works fine with no fragmentation, I understand that this is a fake mechanism made by the ppp MLP to allow carrying higher MTUs over the tunnel, but yet ! it reassembles the fragmented packet “exactly” as the original, thus it won’t break the ipsec packet and it could reach the final destination with no issues .
What happens is the IPsec vpn connects, but no routes get learned ! and if they use any other internet source even a 4G modem everything works fine and routes get learned properly .
That is why im wondering .
You might be better asking on the Meraki community,
I did and they did not figure it out yet, and I believe in Mikrotik experts more into such more complex scenarios ^^
OK, so actually IPsec is not working and you suspect MTU to be the culprit.
The mrru setting is meaningful only if the PPTP server supports MLPPP, and yes, it is a fragmentation mechanism at the PPP level which is just not called “fragmentation”, probably to avoid confusion with IP fragmentation. But if the PPTP server is another Mikrotik, I believe MLPPP is not supported, hence the mrru setting doesn’t work.
However, IPsec operation should not depend on MTU (except if it is extremely low, which is not the case for 1450 bytes).
Since you say that the IPsec VPN connects but routes are not learned, it is more strange. With bare IPsec, routes can be “learned” using mechanisms like mode config, which is part of IKE, or Meraki may use IPsec to encrypt some tunneling protocol and use some dynamic IP configuration on the tunnel interface. In the former case, having the IPsec up and no routes would be very strange; in the latter one, ESP packets not getting through would be an easy to accept explanation.
NAT-T only kicks in if NAT is actually detected between the peers, because encapsulating ESP into UDP decreases efficiency. So depending on how the whole network path between the IPsec initiator and responder looks like when they talk to each other via the PPTP tunnel, bare ESP or UDP-encapsulated ESP may be used. And if bare ESP is used to transport some tunneling protocol as suggested above, and there are some firewall rules in place, on either of the Mikrotiks, which prevent ESP from being transported, this may explain the failure.
I can see no other way to proceed than to capture the traffic on the interface to which the Meraki is connected and see the real traffic between the local and remote Meraki.