Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Issues with .mobileconfig on iOS 18 and iPadOS 18 with Quad9 and Apple Messages #7283

Open
4 tasks done
danielraffel opened this issue Sep 23, 2024 · 0 comments
Open
4 tasks done

Comments

@danielraffel
Copy link

Prerequisites

Platform (OS and CPU architecture)

Custom (please mention in the description)

Installation

GitHub releases or script from README

Setup

On one machine

AdGuard Home version

v0.107.52

Action

I’m running AdGuard Home (AGH) on a virtual machine in Google Cloud, connected via my Tailscale network. My setup allows me to run encrypted DNS through AGH and Quad9 both at home and on the go by using a .mobileconfig file generated from AGH and installed on my iPad and iPhone. I have verified this setup using Quad9’s testing tool (multiple times in the past), and it had been working flawlessly for over a year.

  • After updating to iOS 18 and iPadOS 18, I visited https://on.quad9.net/ and noticed the DNS check indicated that I was not connected to Quad9, even though I was connected to AGH.
  • I switched my DNS provider from Quad9 to Cloudflare and confirmed that Cloudflare DNS was connected using Cloudflare’s testing tool.
  • In addition, I observed that DNS issues appear to cause Apple Messages to fail to send messages when the .mobileconfig file is active under Settings > VPN & Device Management > DNS. If I set DNS to “Automatic,” Apple Messages seems to mostly work.

Expected result

I expected my .mobileconfig DNS setup to continue working without issue after updating to iOS/iPadOS 18. This includes:

  • Successful connection to Quad9 DNS or Cloudflare, as indicated by their respective DNS testing tools.
  • Apple Messages working normally while the .mobileconfig file is active, as it had done before the iOS 18 update.

Actual result

  • After the update to iOS 18, the Quad9 testing tool (on.quad9.net) showed that I was not connected to Quad9 DNS, despite being connected to AdGuard Home and seeing no ads in the browser or native apps (and seeing my queries in the AGH dashboard.)
  • After switching to Cloudflare DNS, the test tool confirmed the connection to Cloudflare was successful.
  • However, Apple Messages fails to send messages when the DNS settings are configured to use the .mobileconfig file. Switching DNS to “Automatic” mostly resolves the issue (I am not 100% sure I've seen issues when set to automatic.)
  • AGH shows very few requests to the fallback upstream DNS servers, so DNS traffic appears to be handled correctly by AGH.

Additional information and/or screenshots

  • AdGuard Home Version: Running on a virtual machine in Google Cloud.
  • Network Configuration: Connected via Tailscale, with .mobileconfig profiles generated from AdGuard Home for iPad and iPhone.
  • iOS/iPadOS Version: 18
  • Fallback DNS Configuration: Quad9 previously, now Cloudflare (https://dns.quad9.net/dns-query -> https://1.1.1.1/dns-query).
  • Observations: The DNS proxy and .mobileconfig file seem to disrupt Apple Messages on iOS 18, though other services work fine (and I do not see this issue on my iPhone running iOS 18.) It does not matter which DNS provider I am using. However, if I change my DNS Proxy and DNS Settings from the .mobileconfig AGH generated to just 'automatic' things seem to mostly work.

I’ve been using this setup for over a year without issues, so I suspect that something in iOS/iPadOS 18 might be causing the disruption, but I’m unable to pinpoint where in the stack the problem arises.

Let me know if you’d like to investigate things or make any further adjustments! I haven't changed my DNS Proxy and DNS Settings so surprised to see behavior changes since updating.

Also, I tried to generated a new .mobileconfig to see if that might have expired (or other issue) but that didn't fix things.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant