SQL access breaks for AnyConnect client

[Nova-th]

Hi All,

I have a client (w11 laptop running AnyConnect 5.1.4.74) terminating at an MX105 running MX 18.211.2.  The client works as expected except for an SQL application that uses a remote server behind the MX105.

Looking at the pcap, the client conversation looks fine up to the SQL pre-login message.  It is at this point I see It doesn't get a response and then moves on to the SSL handshake.

When I bring the client on prem, the pcaps shows the pre-login message, but the next packet has the SQL server response.  Then comes the SSL handshake.

I got on the server and verified that it does indeed send the pre-login response, but it doesn't make it through to the client.

Has anyone seen this behavior or know if there anything Meraki wise that could block the SQL response to the pre-login message packet?

I appreciate your insights.

Thanks,

Mike

[Mloraditch]

I've never encountered this specifically. Have you packet captured the lan of the MX to verify the packets are arriving?  I'd perhaps test with AMP or IPS turned off temporarily. I've seen and heard them incorrectly blocking things over the years. You also may just want to call support as they can trace down the packets inside the MX and see if something else is causing them to drop.

[Nova-th]

Thanks M, yes both AMP and IPS are disabled, we haven't ever turned them on.

I haven't ran a capture on the MX yet.  My captures were run on the server and the client.  I will since support will likely want that.  I've already opened a ticket though.

Thanks for your thoughts.

Mike

[PhilipDAth]

I'm going to bet this is an MTU squeeze.

On the SQL server find the name of the Ethernet interface with:
netsh interface ipv4 show subinterface 

Then trying lowering the MRU with:
netsh interface ipv4 set subinterface “Ethernet” mtu=1300

If that solves it, you can make the change permanent with:
netsh interface ipv4 set subinterface “Ethernet” mtu=1300 store=persistent

[Nova-th]

Hi Phil, yes MTU did occur to me as well.  I checked the eth2 sub int, used by the vpn client, the MTU is 1255 and ping -df implies I could go higher.

@Mloraditch - I did a capture on the MX internal interface.  The conversation is normal, so the MX appears to be the culprit.

I have not heard from Meraki yet, but I'm guessing it's on their end.

Thanks everyone.

Mike

[Nova-th · Accepted solution]

Ok, finally figured it out.  The client VPN settings had "Dynamic Client Routing" setup.  Somehow that was breaking it.  Once disabled the client's SQL application worked as expected.

It just goes to show you, challenge your assumptions!

Thanks for everyone's help.

Cheers,

Mike