Blocking error after upgrading Security appliance from version MX 14.53 to 15.42.1

[GoOn]

Hello to everybody!

I'm subscribed to this community since I'm experiencing a blocking issue with my security appliance, and the support is lacking to help: it's a month since we opened a case, and we are still without a solution.

Since the upgrade from version MX 14.53 to 15.42.1 of our MX65W, the VPN connection with a remote Non-Meraki peer was degraded. It's always impossibile to connect to remote SQL sever, to whom it was possible with 14.53. The error returned now is:

"The connection with the server was established successfully, but then an error occurred during the pre-login handshake. (provider: SSL Provider, error: 0 - Wait time expired.) (Microsoft SQL Server, error: 258)"

Also navigation on shared folder, physically based on the remote peer (on a server on the remote peer) is very slow, and sometimes Windows is unable to open it.

Is there someone can help me?

Many thanks in advance!

[ww]

Maybe some mtu size problem

[GoOn]

Thanks!

Is there any setting that can be done to solve it?

[Bruce]

@GoOn, if it is an MTU issue, the MTU is normally discovered automatically, but relies on ICMP packets. Are you blocking ICMP anywhere? Are you seeing any messages in the event log on the MX about the VPN? Is the tunnel stable?

[DarrenOC]

Hi @GoOn , if it’s an ongoing issue and support are struggling to resolve why don’t you request to rollback to your previous stable issue?

[PhilipDAth · Accepted solution]

DES performance on the MX is terrible.  If you are using DES change to AES.

I wonder if the VPN is flapping.  If you leave a ping running is it stable, or do you get a lot of packet loss?

The 15.x code has started enforcing the peer-ID, which 14.x did not.  Have you got a peer ID specified?  If not perhaps this is causing the VPN to flap.  The peer ID is usually the IP address configured on the WAN interface of the remote firewall (if the remote firewall is sitting behind a device doing NAT then it will be the private IP address on its WAN interface).

To test the MTU idea try this on one of the machines having the issue:

You need to find the name of the network adaptor being used with this command: 
netsh interface ipv4 show subinterface 

  

Then run this command to change the MTU (change "Local Area Connection" to the adaptor name above): 

netsh interface ipv4 set subinterface “Local Area Connection 2” mtu=1300

If this does resolve it, run the last command again and add "store=persistent" then it will stick across reboots.

If either end is behind an asymmetric circuit (different up and down speeds) try enabling timestamps on BOTH ends.

netsh int tcp set global timestamps=enable 

[GoOn]

Hello to everybody!

Thank you for your replies!! 

The VPN connection is stable over a 10 minutes of ping -t process.

Also the support engineer said that there are no issues on VPN tunneling.

My MTU are set to 1500 now, that I'm having the issue. At what value I have to set it?

[Bruce]

Try it at 1300, that should be low enough to allow for the additional headers (due to the VPN) and to determine if the MTU size is the problem.

[GoOn]

MTU size was definitively the problem!

Set to 1300, SQL connection is now working fine!!

You all was a lot quicker and gave me a better support than the Meraki official one! 

Thanks to all!

[Manjinder]

@PhilipDAth  Thank you for the commands/fix. With 15.x/16.15 observed slow browsing/file download. MTU modifications to 1300 resolved the issue.👍  to be specific : Non Meraki VPN to pfSense.