No. That is not the question. Here is the case. I have an ssh connection to outside somewhere. And I start SimpleFirewall app with a modified filter like follows. let anyHostAndPortRule = NENetworkRule( remoteNetwork: nil, remotePrefix: 0, localNetwork: nil, localPrefix: 0, protocol: .any, direction: .outbound ) and here is my handleNewFlow override func handleNewFlow(_ flow: NEFilterFlow) -> NEFilterNewFlowVerdict { os_log("Received a new flow: %{public}@", flow.description) guard let socketFlow = flow as? NEFilterSocketFlow, let remoteEndpoint = socketFlow.remoteEndpoint as? NWHostEndpoint, let localEndpoint = socketFlow.localEndpoint as? NWHostEndpoint else { return .allow() } os_log("Got a new flow with local endpoint %@, remote endpoint %@", localEndpoint, remoteEndpoint) return .allow() } Now, as soon as I start the filter, (by clicking the button in the app), what is happening is it freezes my existing ssh connection, while I can open a new ssh connection to the same destination. So My question is, is there any way I can add a filter without interrupting the existing connection? My theory here is that apple network extension cannot handle TCP loose cases. Is that true?

I opened the ticket and here is the feedback ID FB9719459

That doesn't make sense. For example, I have an ssh connection and add an outbound rule to allow ssh traffic. In this case, the adding filter should not block or interrupt the existing connection because the rule I added matches the existing flow. So it means no matter how many times I add the same rule for the same flow, it will drop the connection always. So I see it as a lack of resilience, not the security feature.

Thank you Matt. I Figured out something funny. After notarization succeeded, with status: Accepted it looks like there is a delay until the whole information is propagated. After I wait a couple of mins, check the status again, now it says notarized. Funny.

This is the entitlement that is being added by Xcode when I check network extension + Content Filter. I reverse engineered other products and it turns out what I need is content-filter-providersystemextension entitlement which I have to make change manually. LOL

yes. Just information update isn't real-time or as quick as I expected.

How can I figure out if it is packaged as an app extension vs a system extension? And how do I package a a system extension from the package level using pkgbuild? Usage: pkgbuild [options] --root <root-path> [--component-plist <plist-path>] <package-output-path> Build a package from an xcodebuild destination root Usage: pkgbuild --analyze --root <root-path> <plist-output-path> Create template component plist from an xcodebuild destination root Usage: pkgbuild [options] {--component <component-path>} <package-output-path> Build a package from one or more previously-built bundles And follow-up question. From the documentation of the content filter https://developer.apple.com/documentation/networkextension/content_filter_providers A filter data provider receives user network content and examines that content to determine whether to block or allow it. Does this mean the content filter always demands and operates under a user session? And if there is no user session will the content filter operate under which session?

@eskimo From some other thread you mentioned Some NE provider types, ones that only make sense system-wide, are only supported in a system extension. However, the VPN providers (packet tunnel and app proxy) are supported What are those providers that can be supported systemwide?

@meaton If I set localNetwork to nil, I will lose the capability of setting port, and that is not what I want. let localNetwork = NWHostEndpoint(hostname: "0.0.0.0", port: "8888") let remoteNetwork = NWHostEndpoint(hostname: "192.168.41.161", port: "0") let inboundNetworkRule = NENetworkRule(remoteNetwork: remoteNetwork, remotePrefix: 32, localNetwork: nil, localPrefix: 0, protocol: .TCP, direction: .inbound) I would like to make above filter is working, but it is not.

@eskimo So what do you mean by every *.systemextension will run systemwide on mac os. right? For example, from the simplefirewall app, once the user install and started content filter, the extension will still operate while the user logged out. correct?

Hi Meaton, sure to simplify things a bit, traffic from 192.168.4.2 does not hit the rule in this case: let remoteNetwork = NWHostEndpoint(hostname: "192.168.4.2", port: "0") let inboundNetworkRule = NENetworkRule(remoteNetwork: remoteNetwork, remotePrefix: 32, localNetwork: nil, localPrefix: 0, protocol: .TCP, direction: .inbound) If I change the port to "" which according to the docs sounds like it should be the same as "0" port I now match the rule but other remote IP's also match the rule. This seems like another issue. The below case does not seem to do what I want either. With the configuration below I see multiple remote IP's hit the rule. To me that makes sense because the prefix is 0 not 32. However I also saw loopback traffic hit in this case as well which did not make any sense given the documentation I've read seems to indicate loopback traffic will only hit an explicit rule for 127.0.0.1. let remoteNetwork = NWHostEndpoint(hostname: "192.168.4.2", port: "0") let inboundNetworkRule = NENetworkRule(remoteNetwork: remoteNetwork, remotePrefix: 0, localNetwork: nil, localPrefix: 0, protocol: .TCP, direction: .inbound) I also tried the below and the behavior is the same as the localNetwork nil case above. let localNetwork = NWHostEndpoint(hostname: "0.0.0.0", port: "0") let remoteNetwork = NWHostEndpoint(hostname: "192.168.4.2", port: "0") let inboundNetworkRule = NENetworkRule(remoteNetwork: remoteNetwork, remotePrefix: 0, localNetwork: localNetwork, localPrefix: 0, protocol: .TCP, direction: .inbound) In the case below the behavior is the same as the above (multiple remote ip's hit the rule) except I no longer see loopback traffic (likely because the local port filter is working). let localNetwork = NWHostEndpoint(hostname: "0.0.0.0", port: "8888") let remoteNetwork = NWHostEndpoint(hostname: "192.168.4.2", port: "0") let inboundNetworkRule = NENetworkRule(remoteNetwork: remoteNetwork, remotePrefix: 0, localNetwork: localNetwork, localPrefix: 0, protocol: .TCP, direction: .inbound) And finally the case I really want is below. A connection from remote IP 192.168.4.2 to local port 8888 does not get caught by the rule below. It appears this doesn't have anything to do with the localNetwork based on the examples above which used a nil or 0.0.0.0/0 local network and still didn't work. let localNetwork = NWHostEndpoint(hostname: "0.0.0.0", port: "8888") let remoteNetwork = NWHostEndpoint(hostname: "192.168.4.2", port: "0") let inboundNetworkRule = NENetworkRule(remoteNetwork: remoteNetwork, remotePrefix: 32, localNetwork: localNetwork, localPrefix: 0, protocol: .TCP, direction: .inbound)

I am going to answer myself. (re)install any network extension application will unblock the issue. I guess apple's network extension or system extension installation and update is not stalled in somewhere

@Matt. That was my initial thought, but even for the same package, after initial installation, any reinstall attempt gives pops up anyway.

No Luck. Now it seems like there is no way to pass env variable to the installer.