Our VPN solution has been in active development and deployment for over 15 years (since 2010), serving enterprise customers worldwide. We do leverage Network Extensions for majority of our work flows but this issue can be easily reproducible outside VPN APP using System Configuration as we already tried with POC. I will be creating an Apple code level support ticket and attaching the required details.

We have opened a Code Support ticket (Case ID: 17936650) to address this. Please note there is also an existing Feedback Assistant ticket regarding this issue (FB19037918

Thanks for the prompt response. We really appreciate your detailed insights into the reported problem. To add further to our previous observations, we developed a proof-of-concept sample code that decouples/isolates the reported issue from the VPN functionality. The POC exclusively utilized System Configuration framework and its supported APIs that are documented as officially supported in macOS Tahoe. As per our observations, Tahoe's IPMonitor process demotes the affected network interface to a lower ranking when probe server connectivity fails. This may not be an ideal approach as other FQDNs could still be reachable. Also, we don't expect the Tahoe OS to override the attribute/configuration value that was set using the documented & supported System Configuration APIs in the sample code. https://developer.apple.com/documentation/systemconfiguration?language=objc   Given that this issue manifests with supported APIs in a non-VPN context, we have logged a TSI (Code-level Support ticket with ID 17936650) for same. It will be really helpful if we can have a short 30-minutes call with experts at Apple. It would help to ensure that we're following best practices and determine if this represents an underlying issue that is very specific to Tahoe 
 We're committed to using only supported frameworks and would appreciate guidance on the proper approach to address this interface ranking behaviour.