Hi Quinn, Thanks for your valuable information. Unfortunately I don't have experience with threat intelligence, and our threat intelligence team is also new to URL Filter and Private Information Retrieval. We are learning these technologies and will file enhancement requests if we need more from the OS frameworks. I filed FB18302351 for documentation improvement regarding question 3: The documentation itself needs to clarify the fuzzy matching behaviour of NEURLFilter. My colleague filed another feedback for question 4, I asked for the FB number but I haven't heard from him yet. Kindly Regards, Shay

I think you're testing connections to localhost (127.0.0.1 or ::1), which requires explicit network rules. Refer: NetworkExtensions/NENetworkRule.h If the address is a wildcard address (0.0.0.0 or ::) then the rule will match all destinations except for loopback (127.0.0.1 or ::1). To match loopback traffic set the address to the loopback address.

(..continued) NEFilterManager must be enabled after the System Extension is activated and enabled, it might be a disaster if NEFilterManager is enabled without a runnable System Extension (all network connection lost, or even T2 watchdog panic). A new status API/notification would help developer to implement this feature more easily.

Hi all, I did some experiment on user's computer, it seems that the leak might relate to netbios (UDP targeting local port 137, 138) and mDNSResponder (UDP targeting local port 5353). Run 1: I forgot to backup the code for filtering all UDP traffic, the app retained 786 NEFilterSocketFlow instances in 30 minutes. Run 2: When filtering everything except the traffic mentioned above, the app retained only 5 NEFilterSocketFlow in 20 minutes. 				let rules = ["0.0.0.0", "::"].map { address -> [NEFilterRule] in 						["137", "138", "5353"].map { port -> NEFilterRule in 								let localNetwork = NWHostEndpoint(hostname: address, port: port) 								let networkRule = NENetworkRule( 										remoteNetwork: nil, 										remotePrefix: 0, 										localNetwork: localNetwork, 										localPrefix: 0, 										protocol: .UDP, 										direction: .any 								) 								return NEFilterRule(networkRule: networkRule, action: .allow) 						} 				}.flatMap { $0 } 				let filterSettings = NEFilterSettings(rules: rules, defaultAction: .filterData) It would be more precise if I do another experiment filtering everything (to compare with run 2), but I think the data above should be sufficient to isolate the problem, and that's the workaround that I've found with current NetworkExtension APIs. Shay

Hi Obenshalom, I also run into some similar kernel hang/panic. When inspecting the spindump captured before panic, I found 50+ processes were blocked in the "sosend". I resolved these symbols to find that, the kernel might had exhausted mbuf(s). I have no idea how to reproduce this issue, and I didn't collect memory footprint this time. Could you check my spindump to see if there are any similarities? Thanks Shay spindump.txt - https://developer.apple.com/forums/content/attachment/c92fb4cf-92c6-43f5-9346-6dc1e006de56

Hi Eaton It seems that filtering TCP traffic won't leak NEFilterSocketFlow. If I close network applications a few moments before taking memgraph, there will be almost no NEFilterSocketFlow left (instead of 10~15 more NEFilterSocketFlow per minute if UDP traffic is also filtered). Shay