Hey guys, I have a question regarding iOS 15 beta and proxy bypass. We've noticed that if the proxy is automatically set via a VPN and the TCP connection is closed, the system bypasses the proxy and connects to the server directly. However, that's not the case if the proxy is set manually in settings or a GHP profile is used. We haven't observed such behavior in previous versions so I wanted to ask: is this expected behavior in iOS 15? If so, is there any way how to disable the bypass? Configuration: VPN: URL with PAC file added via proxyAutoConfigurationURL device is proxying, however, the proxy is bypassed on TCP connection close GHP: tested both manual or auto configurations (in case of auto configuration we've used the same PAC file) device is proxying and the proxy is never bypassed VPN wasn't installed in this case Settings: proxy server and port are defined in WiFi settings again, the same proxy server has been used as in previous test cases proxy is never bypassed VPN wasn't installed in this case

Hey everyone, we've experienced strange behavior in the iOS system with a GHP profile and the PAC file evaluation when there's no internet connection. The setup: Router is not connected to the internet Device connects to a Wi-Fi provided by the router Device has mobile data disabled Device has a proxy set via GHP with a PAC file URL Device tries to access a website on a local IP address (e.g. 192.168.1.1) PAC file: function FindProxyForURL(url, host) { if (shExpMatch(url, "*:993/*")){ return 'DIRECT';}if (shExpMatch(url, "*:465/*")){ return 'DIRECT';}if (shExpMatch(url, "*:587/*")){ return 'DIRECT';} if (isPlainHostName(host) || shExpMatch(host, "*.local") || isInNet(dnsResolve(host), "10.0.0.0", "255.0.0.0") || isInNet(dnsResolve(host), "172.16.0.0", "255.240.0.0") || isInNet(dnsResolve(host), "192.168.0.0", "255.255.0.0") || isInNet(dnsResolve(host), "127.0.0.0", "255.255.255.0")) return 'DIRECT'; return 'PROXY my.proxy.address;DIRECT'; } The result: The device is not able to connect to local addresses, the request times out. Based on the PAC file rules, when accessing the 192.168.1.1 address, the proxy should have been bypassed and it should go directly: isInNet(dnsResolve(host), "192.168.0.0", "255.255.0.0"). However, it seems, that the device is still trying to go via proxy which is unreachable since the router is not connected to the internet. The GHP profile has even the flag to bypass proxy if unreachable enabled: <key>ProxyCaptiveLoginAllowed</key> <true/> <key>ProxyPACFallbackAllowed</key> <true/> If we remove the GHP profile from the device, everything works. And if the device has cellular data enabled, it works as well. This setup is used by a customer that is connecting to such router in elevators for some maintenance, so they usually have no signal there - the cellular interface is not working and from time to time, the webpage is successfully loaded - I assume that the device had a signal for a short period of time. I just wanted to check with you if there's anything we do wrong in the proxy setup before reporting a bug. Right now we're trying to reproduce this behavior with CFNetworkDiagnostics and NetworkDiagnostics profiles installed so we have more logs. Although, we've noticed the following message in the logs: CFNetworkAgent PAC Fetch failed with cached error [NSURLErrorDomain:-1009] Have anyone experienced something similar? Thanks in advance!

Hey everyone! I have a Packet Tunnel Provider Network Extension and what I'm trying to do is to send a request from the Network Extension that will go via that tunnel. When I'm trying to do such a request in the main app, I can see in the PCAP that it's using the VPN's DNS server. When doing such a request from the Network Extension, the tunnel is bypassed. I've tried multiple requests: a regular data task via the URLSession.shared (with default configuration) with a hostname in the URL a regular data task via the URLSession.shared (with default configuration) with a bare IP address in the URL a DNS lookup via DNSServiceQueryRecord using a DNS resolve library that uses some sockets magic to resolve the DNS query - link to the library setup: Network Extension: Packet Tunnel; macOS: 12.6; Xcode 14.1 implementation: I'm using the NEPacketTunnelFlow API to read and write the packets. disclaimer: I haven't tested this on iOS yet. But I would assume the network stack logic will be the same? questions: Is this an expected behavior? I think it kinda does make sense to me as a prevention that it won't end up in an infinite cycle. however, is there any way how to force the request to use the tunnel? thank you in advance for any help!