[quote='813223022, DTS Engineer, /thread/768025?answerId=813223022#813223022'] Can you elaborate on that? [/quote] Sure! I'll describe the general problem that we're facing and how we wanted to overcome it. In our scenario, we have two variables in play: Configuration profile with DNS over HTTPS settings our VPN app Here are the scenarios that we have investigated so far. In all of them, the device is connected to the captive network. Device with DoH settings, no VPN app - struggles with Captive Portal, as the DNS gets encrypted and dropped by the gateway Device with VPN app, no DoH settings - works with Captive Portal, as we're able to detect the Captive Portal and opt out of the traffic until the Captive Portal is cleared. Device with VPN and DoH settings - this is the pain point. By opting out of the traffic, we're getting to the first scenario where the user struggles with Captive Portal - DNS traffic leaks from the VPN to the DoH payload, gets encrypted and then blocked. We wanted to prevent this situation by not opting out of the DNS traffic from the VPN and sending it to the DNS server provided by the gateway instead (root of my original question) so it won't fall back to the DoH. Note to the configuration profiles with DoH: They are provided to our users either by us, or they can be freely downloaded from the internet (like Quad9 configuration profiles). And we want our VPN app to be compatible with both. Thank you for looking into this!

Hello Eskimo! Thank you for your answer! Basically, what I am looking for is "if Captive Network gateway provides DNS servers to use, use them for clearing Captive Portal". So maybe even more close to what ipconfig getpacket en0 returns, but using some API that's available on both platforms. Regarding the bigger picture - you're right and that's what we do when our VPN app is running as the only VPN in the system. But we'd like to support compatibility with other network settings that can be pushed via configuration profile (like DNSSettings with DNS over HTTPS payload). I have found this question about the system behaviour when the device is connected to the Captive Network and DoH settings are in place which is tightly connected to what we're trying to resolve. If OS would be able to clear the captive portal with DoH payload, we can just continue to take down the tunnel and leave it on the system.