TLS client key exchange seems to fail across AutoVPN overlay

[DennisS]

We're currently testing SDWAN connectivity across our MPLS WAN.

• At our branch location we have our MPLS circuit terminating into a MX67
• MX67 connects to a downstream MS350 stack
• At our data center, a MX84 pair sits behind our traditional Cisco routers running in concentrator mode
• AutoVPN tunnel is established between MXs; connectivity is across our MPLS so no firewalls to traverse

From a PC at the branch location I run Citrix Workspace then select a published app. It sits there thinking for 2-3sec then does nothing. Tried this several times.

• We took a packet capture from the MS350... TCP handshake between the PC & Citrix server is good, client starts TLSv1.2 connection, keeps retrying until the Citrix server resets the connection.

• We rolled everything back to traditional MPLS and performed a packet capture... client starts the TLSv1.2 connections followed by the Client Key Exchange and so on until the published app. opens.

Anyone run into this before?

Thanks

[PhilipDAth]

Sounds like an MTU squeeze to me (smaller packets making it through, large packets failing).

Try lowing the MTU on a test Windows machine.  From an Administrative command prompt:

netsh interface ipv4 show subinterface

Identify the name of the interface with all the traffic, and then:

netsh interface ipv4 set subinterface “<name>” mtu=1300

The above will cause a temporary change which is undone on reboot.  It will confirm this is or is not the issue.

[DennisS]

Thanks for the suggestion but it didn't make any difference on the PC. We also dropped the MTU on the MS350 stack, same results.

We hopped on a Web-ex with Meraki support and it appears the MX67 isn't forwarding the TLSv1.2 negotiation between the client & Citrix front end server (sits behind an F5). What's odd is, there are other TLSv1 & v1.2 convs from various devices that are working fine.  Meraki is reviewing logs and we're waiting for next steps to try.