We have been adjusting the MTU between 1100-1400, but unfortunately the failing HQ clients aren't seeing any of the changes we make to the Network Policy - it seems they are not getting past the Connection Request Policy. Thank you for the suggestion, we'll take a look at the radius proxy.  ... View more

Thanks for your insight, Joe.   So far, we have tried adjusting the MTU multiple values between 1100-1400. All values have worked for remote clients, but NPS logs show HQ clients are not even seeing these changes to the policy, only the working remote clients. The HQ clients are not getting far enough in the process to apply the MTU. ... View more

Apologies for my lack of understanding on this topic, but I do not believe the TLS session is being formed. It's EAP-TLS.   Pcap taken from the AP within the Meraki interface, no filter expression, then filtering by EAP when viewing pcap in Wireshark. We are seeing Identity Responses, Client Hello, and TLS EAP Responses - but never a Server Hello. It reverts back to Identity Responses and repeats the cycle.  ... View more

The NPS logs are not showing any errors, Reason-Code always returns 0 for both remote sites and HQ. That being said, the failing connections are never getting an Access-Reject packet.   For the remote sites, we are seeing the Access-Request and Access-Challenge packets followed by an Access-Accept. For HQ, We are only seeing Access-Requests and Access-Challenges over and over, but never an Access-Reject. When we look in event logs, we can see successful connections from remote sites, but never the failed attempts from HQ. We only see those in the NPS logs.    At one point, we made a change to the MTU just to see if clients are seeing the change. We can see the MTU change reflected in the logs from remote sites, but not from HQ.   Here's a success from remote site   Here's a failure from HQ (over and over until a timeout I assume)   ... View more