Hey @meaton, appreciate all your support on this. I still have something, that I would like to run it through you if you don't mind. I always try and steer folks away from this approach and always recommend that if your packets are read from the virtual interface that they hit the network. For example, even if's it's a DNS server sitting in the private network that you can point this traffic to that's just responding with the mapped file contents. This seems like a more scalable approach anyways if you want to move application servers around. I completely understand it's a scalable approach and the ideal way. But, being an enterprise network and existing clients of different devices work in the legacy way, we are in a situation to adapt them and not really have an option to have a DNS server in place. That's kind of restriction and that leads to a scenario where we have to do the resolution locally. That's the part am concerned whether the approach that we discussed above makes sense and is adhering to the Apple Store guidelines. I also don't want to end-up implementing something that gets rejected. Would appreciate your insights on this. Regarding: let dnsSettings = NEDNSSettings.init(servers: ["x.x.x.x"]) Again, we don't really have a server here and that leads to my question of whether using the DNS settings without servers is something possible? The matchDomains is the exact API that I was looking for to filter out DNS queries based on host name, but this questions keeps lingering for me. Thanks so much again!

Thanks @meaton for the direction on this. I had a couple of concerns around this Right. This seems reasonable if your DNS servers are not available via the public internet. And yes, this does have a performance implication but if the time to live on the DNS queries is longer and the application servers do not rotate IPs often then this should workout fine. To be more precise its not that DNS servers are not available via the public internet, instead there is no DNS server at all. So basically, we have to resolve the IP address locally through a mapping table (something like hosts file). Given this behavior, does it make sense to intercept the DNS queries through TUN interface and respond to the queries from the NetworkExtension itself and then on-ramp the traffic once the actual packets flow in. Regarding: You need to use the DNS responses to access private resources for business purposes, correct? If so, this seems like it fits with TN3120 Expected use cases for Network Extension packet tunnel providers. Also in the expected use cases of PacketTunnelProvider, it is mentioned that it is not advisable to intercept all the DNS traffic but intercept only DNS queries for the isolated network. I am a bit lost here, because if we had to intercept DNS queries for a subset, is there any way to effectively do that? Split tunneling is one way that I could foresee, but again we might have to add in DNS server routes to the includedRoutes, but on the iOS device if we end up adding a DNS server route, this would eventually lead to intercepting all DNS queries if am not wrong. Can you please let me know is there something that am missing here?

Thanks much Quinn for the response and also the piece of code that it doesn't work in that way. Though it is unfortunate, I believe we might have to resort to a different option.

Thanks Quinn, for the response. Unfortunately, this iOS app is the client for an enterprise application and the enterprise application in tightly bound to this IP. Tightly bound in the sense, the application server will always redirect to this loopback address 127.50.100.1 and making changes to the application server to redirect to 127.0.0.1 is something not possible. There are other (desktop) clients that work well with this specific loopback and changing that behavior on the application server will have regression impacts on existing clients. So we don't see a solution rather than binding the HTTP server to this non-standard localhost address. Would appreciate if there is any other viable solution for this to work, something through Network Extension or different options.