what if an app is using NWParameters.PrivacyContext to require encrypted DNS while Network Extension uses Do53?
It's unclear if you have an app and a Network Extension now in the mix or the app is part of the Network Extension. Typically you will see the Network Extension being handed the DNS traffic though if you are claiming that traffic.
Post not yet marked as solved
What API are you using here when trying to reach arduino.cc? I tried with NSURLSession and was able to reach this domain (with a 301 response) but was able to resolve, connect, and the make the request. Try removing any proxy, VPN, or Network Extension and run the request again with NSURLSession.
Does NEDNSSettingsManager take precedence over iCloud Relay? Does it depend on the DNS protocol (Do53/DoH/DoT) set in NEDNSSettingsManager?
Any Network Extension API should take precedence over iCloud Private Relay. It should not matter which protocol is used and the Network Extension should get the DNS traffic. This is particularly useful for cases where the DNS traffic needs to be encapsulated using a special protocol in your packet tunnel provider.
Post not yet marked as solved
Any idea how to force those DNS queries to the tunnel's DNS for a split tunnel? It seems that the matchDomains is not working..
It sounds like your routing table must be handling the DNS queries before your tunnel has a chance to claim them, or that the tunnel is not correctly picking them up and they are falling through for the system to handle them. To debug this further your could try:
Go full tunnel to make sure that you are able to grab the DNS queries that you need.
Set the default route on your tunnel. This will likely add a lot more traffic to your tunnel but may tell you if you have an error in how your tunnel is setup and if this DNS traffic is not being claimed properly by your dns settings.
Move to one of the proxy APIs I mentioned previously to handle DNS traffic outside of the destination address you are tunneling.
Post not yet marked as solved
Any idea how to force some/add DNS queries to the tunnel's DNS even when for a split tunnel?
the Packet Tunnel Provider is not supposed to capture all DNS queries
Right, the NEPacketTunnelProvider should not be used to capture all DNS traffic. If you need to do this, then NEDNSProxyProvider and DNS Settings are the APIs you want, as mentioned here.
Post not yet marked as solved
Yes, NEPacketTunnelNetworkSettings is the high level object that allows you to define the IPv4/v6 settings on your interface as well as claim IPv4/6 routes on that interface. From there you will setup the tunnel's NEPacketTunnelFlow object to read IP packets from the virtual interface, encapsulate them with your tunneling protocol, and send them out over the network. Likewise, read the packets from the network and write them to the interface.
Post not yet marked as solved
Are there recommended alternatives for storing authentication cookies shared accross apps and extensions (keychain ?)
Yes, you could try using a token based authentication scheme that is saved in an account Keychain instead. To see how to delegate account credentials in the Keychain to handle this, checkout the article on Adding a Password to the Keychain.. This is also PassKeys for your iOS 16 requirements.
Post not yet marked as solved
When the PAC is processed (specifically findProxyForURL() is run) - what is the best way to debug that?
Is there a way to debug the PAC processing on iOS? For instance by logging some user-controlled output to the console?
There is not a great way to debug this without having direct access to the server or endpoint where the PAC is sitting to see the logs that are passing through the server. What I usually start off by doing is testing one blanket PROXY statement to know that the PAC file is working and then add additional rules from there.
Post not yet marked as solved
Thank you for the logs and the additional context. Just to try and narrow this down, if you only try and start the NEDNSProxyProvider, and not the NEFilterDataProvider or any other VPN provider that may be on the system, does this change the outcome any?
Post not yet marked as solved
I want to reconnect IPCConnection when NE was interrupted!
To do this you'll want to make sure that your NSXPCListener is also started on the start/restart of the Network System Extension so that when the client needs to make a connection, there is a listener available to accept it. Take a look at Simple Firewall sample, this is done in the main.swift file when the extension is started.
Post not yet marked as solved
So is this expected behavior?
I have never tested with multiple NEDNSProxyProviders running at the same time, but I have tested with multiple NETransparentProxyProviders and likewise a NEDNSProxyProvider and NETransparentProxyProvider running at the same time and those cases do work. What logs are you seeing here when the stop message is sent to your provider?
Post not yet marked as solved
We are planning on opening up registration at the link you have provided late this year, so please keep checking back for updates on this later in the year.
Post not yet marked as solved
So if I move the container app to location /Applications/SampleGUI.app/Contents/Helpers/, will it be allowed for upgrade?
Am I missing something? I do not see the external SampleGUI.app or the Helpers/ directory here at all?
Post not yet marked as solved
There is no API to check if this system alert is available directly from the Network Extension framework. If you are not able to detect that an error took place on the callback of apply(_:completionHandler:) then one technique you could try is to wait for 3-5 seconds after calling apply, for your device to receive an IP, and then try to communicate with the device through a HTTP request or TCP connection (or however you planned to communicate with the device). If the request / connection immediately fails, which is should if you were not able to associate with this network, then tear down the association and retry as your business logic sees fit.
Post not yet marked as solved
You tagged wwdc2022-10079 on your post, does this mean that you are using the new DNSSEC APIs with URLSession, for example requiresDNSSECValidation?
If so, can you please add a sample of the code that you are using? If not then random HTTP errors without code changes usually result from the client talking to a downstream server that the client did not expect to, so I would consult with your server side team on these errors if they persist.
