Hi there, So far with the deployment of Network System Extension onto end devices of macbook pro, in general it all goes well. However, there do have some older devices, say 2015 macbook proc, even 2019 one has some problem of network drop after running for some time, say, in a couple of hours. Symptom is that network get stuck intermittently and then get totally loss. It seems that from time to time app proxy get stuck and cannot proceed further traffic fast enough, especially for dns request filtering currently going through the same app proxy. Thus causes network loss and not recoverable. So the question is: is there any requirement on the hardware in order to use Network System Extension correctly. Thanks in advance for any suggestion. Richard

Hi there, Is there any way to configuration the MTU value with AppProxyProvider (DNSProxyProvider). I guess should be around NWConnection and NWUDPSession and see any configuration available? Thanks in advance.

Hi there, We have app proxy + dns proxy both launched like below way: // Start App Proxy ProxyManager.shared().loadProxyManager(connect: true) { ProxyManager.shared().addObserver {} ProxyManager.shared().start() } // Start the DNS Proxy DNSManager.shared().start() With MDM profile, it work all good. But if without MDM profile, there will be two prompts asking confirmation to add net services for each proxy. But the first prompt will disappear and replaced by the second prompt. Thus can only confirm and add the second proxy net service. The result is only dns proxy net service added and running. No app proxy net service seen or running. Is it the right way that I launch both proxies like that? Still we need the use case without MDM profile. Thanks in advance for any suggestion. Richard

Hi there, Just to check with you any way to update filter rules on the run for app proxy. The setting up of filter rules is like below codes. let settings = NETransparentProxyNetworkSettings.init(tunnelRemoteAddress: "127.0.0.1") settings.includedNetworkRules = ... settings.excludedNetworkRules = ... setTunnelNetworkSettings(settings) { ... } That is inside startProxy() function followed by proxy start. I wonder is it possible to update these rules without restarting the proxy. Thanks in advance for any suggestion. Regards Richard

Hi there, It is well known that system extension could not be uninstalled via api level since the beginning, typically OSSystemExtensionRequest.deactivationRequest. Now that with the latest Monterey release 12.2, is it still the case? Thanks in advance for any suggestion. Regards Richard

Hi there, This is the case of using dns proxy provider on ios. One thing noticed is that when the system extension process of dns proxy crashes, it is not re-spawn automatically by the wrapper process as it is when using the same dns proxy provider under macOS. The test I carried out was: Under macOS Launch an application with dns proxy provider sys extension. Kill that sys extension process. After several seconds, another sys extension process of dns proxy extension will be re-spawn. sudo ps -A|grep macappproxy Password: 47796 ??     0:00.35 /Applications/macappproxy.app/Contents/MacOS/macappproxy 47875 ??     0:00.62 /Library/SystemExtensions/439F12A7-1304-4A92-BEED-3EBEC979ADBE/com.familyzone.macappproxy.fzmacdnsproxy.systemextension/Contents/MacOS/com.familyzone.macappproxy.fzmacdnsproxy 47929 ttys001  0:00.00 grep macappproxy AU-L-0306:fc-ios-edu-client richardwang$ sudo pkill -9 com.familyzone.macappproxy.fzmacdnsproxy AU-L-0306:fc-ios-edu-client richardwang$ sudo ps -A|grep macappproxy 47796 ??     0:00.35 /Applications/macappproxy.app/Contents/MacOS/macappproxy 48433 ??     0:00.31 /Library/SystemExtensions/439F12A7-1304-4A92-BEED-3EBEC979ADBE/com.familyzone.macappproxy.fzmacdnsproxy.systemextension/Contents/MacOS/com.familyzone.macappproxy.fzmacdnsproxy 48531 ttys001  0:00.00 grep macappproxy We can see from above that dns proxy pid changed after it was killed and re-spawn. Under ios Doing the same thing, but slightly different: By adding below code into startProxy(), crashing dns proxy. 1 let bug: Int? = nil 2 os_log("bug: %{public}s", log: Log.ext, type: .debug, bug!) It can be seen from below the log that “starting proxy“ happens three times before it died. It makes no difference if we put the same bug inside handleNewFlow(). And that causes no browsing through under incognito mode. Can you help confirm this? If it is the case, is there any way to guard sys extension process and respawn it as a kind of robusness? Thanks in advance for any suggestion. Richard

Hi there, This was realised during the test. That is: When we use appproxy to filter all udp traffics with netbiosd running, and observe netbiosd cpu usage with Activity Monitor. Then if we just restart the appproxy (just kill the sys extension process is fine). After system extension process is re-spawn, you will find that netbiosd cpu usage boosts to above 100%. Tried as well to put netbiosd related udp port (137, 138 and 139) as excludedNetworkRules, but doesn't help. How to reproduce: Start netbios service by isudo launchctl load -w /System/Library/LaunchDaemons/com.apple.netbiosd.plist Start appproxy application (with wrapper process and system extension process). Setup in includedNetworkRules filtering all udp outbound traffics. Just kill appproxy system extension process so that the wrapper process will spawn a new system extension process. Observe from Activity Monitor cpu usage of netbiosd, you will find that it is above 100% then. It makes no difference even if you put in excludedNetworkRules all netbiosd related ports including 137, 138 and 139 (tcp and udp). Thanks in advance for any suggestion. Regards Richard

Hi there, This is realized during the test on Monterey 12.2. Normally when we kill the dns proxy sys ext process, it will respawn very quickly within a couple of seconds. But after multiple times of trials, it can take more than one minute to respawn. Worst case even encountered was that it never gets respawn anymore. By comparison, the app proxy doesn't have the same problem: always gets respawn instantly. Not sure whether it is a bug or not. Thanks in advance for the suggestions. Regards Richard