@SGGHET Yes, it was reported to Apple, and they acknowledged the bug. A fix will be available in the next macOS version.

OK. And, just to be clear, your handle-new-flow method was called in both cases, right? Yes, handle new flow called for both the cases.

In this case, both flows — the one captured by the proxy and the one bypassed — have failed. There is no network connectivity. Could this be related to the Wi-Fi 6E issue, which started being supported on M3 and M4 devices running macOS?

This issue is mostly observed on M4 devices running iOS 15.4.1.

You are shipping a macOS product. That includes an app. Which contains a transparent proxy system extension. Yes this is correct. By “client app” you mean your transparent proxy, right? Yes Which app is “experiencing network issues”? All the apps on the system? None of the apps work — there is no network connectivity, and the user has to restart the system to recover the network. The system and DNS logs shared above indicate that there is no active network interface. It seems like you’re seeing this The user has your transparency proxy installed. They update to macOS 15.4.1. The start to encounter network problems. This stop your transparent proxy. Those problems persist. All points are correct except the fourth one. The transparent proxy is not stopped — it continues to run and capture traffic. However, the system has no network connectivity, as explained above. There is no active network interface, and system logs and scutil --dns shows the network is not reachable. It seems like OS issue.

@DTS Engineer, I tried this on the macOS 15.1 RC build, and it works fine for me. Thanks, will wait for 15.1 public release.

Yes, we are using a transparent app proxy provider to capture L4 traffic, but while the transparent app proxy is connected, the messaging app is not working on macOS 15.0.1. It works fine on macOS 15 and earlier. Some users have reported the same issue with other VPN providers as well here, https://discussions.apple.com/thread/255802764?sortBy=rank

Thanks for the reply. We have tried the suggestion but are still seeing the error. Attached are the config file (please remove the .txt format after downloading the config) and the screenshot. ApplicationProxy.VPN.mobileconfig.txt

In my case, the WIFI (en0) interfaces is active. and ideally, dns query should reach to en0. Below is the API call. DNSServiceQueryRecord(sdRef kDNSServiceFlagsReturnIntermediates | kDNSServiceFlagsTimeout, kDNSServiceInterfaceIndexAny, query, rrtype, rrclass, dns_callback, context); We validated via Wireshark, but packets are not reaching to any interface."

What interface is it failing to query? When we provided "kDNSServiceInterfaceIndexAny," it did not reach any of the interfaces.

@eskimo, Yes, it is a VPN product, and we are creating a utun interface to route all DNS traffic. There we observed NIMLOC dns query for sonoma.

@eskimo: Yes, we have created this using socket(AF_SYSTEM, SOCK_DGRAM, SYSPROTO_CONTROL));

@eskimo, I tried, but I'm not getting any flow. NENetworkRule *traffic = [[NENetworkRule alloc] initWithRemoteNetwork:nil remotePrefix:0 localNetwork:nil localPrefix:0 protocol:NENetworkRuleProtocolTCP direction:NETrafficDirectionInbound];

@eskimo, Any suggestion on this?

Hi @eskimo, Sorry for the confusion; I was referring specifically to the flow. I attempted the settings below in order to receive incoming flow. NENetworkRule *dnsInboundTraffic = [[NENetworkRule alloc] initWithRemoteNetwork:nil remotePrefix:0 localNetwork:[NWHostEndpoint endpointWithHostname:@"0.0.0.0" port:@"12345"] localPrefix:0 protocol:NENetworkRuleProtocolTCP direction:NETrafficDirectionInbound]; settings.includedNetworkRules = @[dnsInboundTraffic]; But I'm not receiving incoming flow; it is functioning correctly for outgoing flow. Please correct me if I'm doing anything wrong while creating the NENetworkRule.