Thank you for the conformation. That is clear to me :)

Thanks for the suggestion. Will trace down any crash happened as you pointed out.

That is TCP based.

It is swift based one.

Thanks for the suggestion. Is there any server side tcp tls usage example?

let c1 = NWConnection(host: "example.com", port: 80, using: .tcp)let c2 = NWConnection(host: "example.com", port: 443, using: .tls) How about the usage when I use NetworkExtension? Thanks in advance.

Thank you Eskimo.

Rules with only 0.0.0 : 52 and 0.0.0.0 : 54 not going wrong, but it overlaps with rules like: ("0.0.0.0", "0...52") and ("0.0.0.0", "54...65535")

I have put in place some traced from within handleNewFlow together with the rule setting: ("0.0.0.0", "0...52") and ("0.0.0.0", "54...65535") And I can get below traces 🤪FZ$--traffic handling udp flow to: 8.8.4.4:53 fzmacappproxy 04:16:22.468086+1000 🤪FZ$--traffic handling udp flow to: 1.1.1.1:53 fzmacappproxy 04:16:22.470011+1000 🤪FZ$--traffic handling udp flow to: 10.0.0.10:53 fzmacappproxy 04:16:22.471286+1000 🤪FZ$--traffic handling udp flow to: 10.0.0.10:53 fzmacappproxy 04:16:22.472517+1000 🤪FZ$--traffic handling udp flow to: 10.0.0.10:53 fzmacappproxy 04:16:22.473659+1000 🤪FZ$--traffic handling udp flow to: 10.0.0.10:53 fzmacappproxy 04:16:22.475028+1000 This is one thing. The second thing is that with that rule set, sometimes it can capture all traffics, some times it seems blocked some where. That can be verified by using netcat command sending out packets with the same subnet of en0. If I filter with com.apple.nc on console app, with the command nc 192.168.0.100 8888, in good cases I can get below trace: (2281480580): New flow: NEFlow type = stream, app = com.apple.nc, name = , 192.168.0.183:0 - 192.168.0.100:8888, filter_id = , interface = en0 fzmacappproxy 08:16:13.368577+1000 [Extension com.familyzone.macappproxy.proxy]: Calling handleNewFlow with TCP com.apple.nc[{length = 20, bytes = 0xb98252db9f8d8bbe4c383cf2ce6374eb34e3b83a}] remote: 192.168.0.100:8888 interface en0 fzmacappproxy 08:16:17.992887+1000 🤪FZ$--traffic handling tcp flow TCP com.apple.nc[{length = 20, bytes = 0xb98252db9f8d8bbe4c383cf2ce6374eb34e3b83a}] remote: 192.168.0.100:8888 interface en0 fzmacappproxy 08:16:17.992990+1000 [Extension com.familyzone.macappproxy.proxy]: provider accepted new flow TCP com.apple.nc[{length = 20, bytes = 0xb98252db9f8d8bbe4c383cf2ce6374eb34e3b83a}] remote: 192.168.0.100:8888 interface en0 fzmacappproxy 08:16:17.993701+1000 But sometimes it only show the first line below without the rest, which means NE callback is not envoked for some reason. (95809956): New flow: NEFlow type = stream, app = com.apple.nc, name = , 192.168.0.183:0 - 192.168.0.100:8888, filter_id = , interface = en0 fzmacappproxy 08:19:05.315187+1000 Is it another bug?

There is a dns setting like below: settings.dnsSettings = NEDNSSettings(servers: ["1.1.1.1", "1.0.0.1", "8.8.8.8", "8.8.4.4"]) Commenting it out still see the port 53 traffic like below: 🤪FZ$--traffic handling tcp flow TCP fc-system-service_darwin-amd64[{length = 20, bytes = 0xf2eb944db46831eb67c5114a4da698418011e2ad}] remote: 52.95.132.69:80 interface en0 fzmacappproxy 07:59:41.762307+1000 🤪FZ$--traffic handling udp flow to: 192.168.0.1:53 fzmacappproxy 07:59:41.989191+1000 🤪FZ$--traffic handling udp flow to: 192.168.0.1:53 fzmacappproxy 07:59:42.195246+1000 🤪FZ$--traffic handling udp flow to: 192.168.0.1:53 fzmacappproxy 07:59:42.196681+1000 🤪FZ$--traffic handling udp flow to: 192.168.0.1:53 fzmacappproxy 07:59:42.399203+1000 🤪FZ$--traffic handling udp flow to: fe80::1.53 fzmacappproxy 07:59:42.400754+1000 🤪FZ$--traffic handling udp flow to: fe80::1.53 fzmacappproxy 07:59:42.402079+1000 🤪FZ$--traffic handling udp flow to: 192.168.0.1:53 fzmacappproxy 07:59:42.609971+1000 🤪FZ$--traffic handling udp flow to: 192.168.0.1:53 fzmacappproxy 07:59:42.614274+1000 🤪FZ$--traffic handling udp flow to: 2001:4860:4860::8888.53 fzmacappproxy 07:59:53.037751+1000 🤪FZ$--traffic handling udp flow to: 10.0.0.10:53 fzmacappproxy 07:59:53.046197+1000 🤪FZ$--traffic handling udp flow to: 10.0.0.10:53 fzmacappproxy 07:59:53.048681+1000 🤪FZ$--traffic handling udp flow to: 1.1.1.1:53 fzmacappproxy 07:59:53.760442+1000 🤪FZ$--traffic handling udp flow to: 2001:4860:4860::8888.53 fzmacappproxy 07:59:55.095695+1000 🤪FZ$--traffic handling udp flow to: fe80::1.53 fzmacappproxy 07:59:56.042586+1000 handleNewFlow() is like below: override func handleNewFlow(_ flow: NEAppProxyFlow) - Bool { if let TCPFlow = flow as? NEAppProxyTCPFlow { FZLog(.verbose, "traffic handling tcp flow \(TCPFlow.debugDescription)") TCPFlow.open(withLocalEndpoint: nil) { [unowned self] (error) in guard error == nil else { FZLog(.error, "tcp flow open error: \(error.debugDescription)") self.closeAppProxyFlow(flow: TCPFlow, error: error) return } self.handleFlow(tcpflow: TCPFlow) } } else if let UDPFlow = flow as? NEAppProxyUDPFlow { FZLog(.fatal, "UDP flow should not be captured \(UDPFlow.debugDescription) if handleNewUDPFlow is overridden") } else { FZLog(.fatal, "Should not capture something here \(flow.metaData.debugDescription)") } return true } checking for a property of variable that is not set or nil? What property of variable here do you mean? Code example?

If I put in excluded rule with port 53, appproxy will keep recycling. Removing NEDNSSettings doesn't help with the two issues. Raised a TSI case 767665663 only for udp 53 traffic issue. When I try to update with the other issue (handleNewFlow() sometimes not invoked) in the same scenario, couldn't find anywhere to edit my ticket. Do you know how to edit a TSI request?

Ok. Will raise a new one for it (handleNewFlow() sometimes not invoked). Seems need to pay then.

Are you using Catalina or Big Sur for this Network Extension? I am using BigSur 11.2.3 So if you do not want port 53 UDP traffic this leaves you with a few options; first you could try to filter only on a specific set of addresses or ranges that are not the default route (0.0.0.0). For example, here is one that I used for all 17.0.0.0 traffic on port 443: settings.includedNetworkRules = [     NENetworkRule.init(remoteNetwork: NWHostEndpoint(hostname: "17.0.0.0", port: "443"),                                  remotePrefix: 8,                                  localNetwork: nil,                                  localPrefix: 0,                                  protocol: .any,                                  direction: .outbound) ] Next, you could proxy this traffic and handle it just like your regular UDP flows. Thanks for suggesting touching the default route. That might be the way to go. Can you say something more about usage of remotePrefix? What I understand is value 8 means taking care of the first eight bits of the ip address which is 17 in this example. Any other examples showing different cases?

Also, I tried below setup, but still see udp port 53 traffic captured. Thanks in advance for any suggestion. var hosts = [("", "")] var rules: [NENetworkRule] = [] for seg in 1...254 { if seg != 127 { hosts = [("\(seg).0.0.0", "0...52"), ("\(seg).0.0.0", "54...65535"),] rule = NENetworkRule.init(remoteNetwork: ep, remotePrefix: 8, localNetwork: nil, localPrefix: 0, protocol: .UDP, direction: .outbound) rules.append(rule) } } } let settings = NETransparentProxyNetworkSettings.init(tunnelRemoteAddress: "127.0.0.1") settings.includedNetworkRules = rules settings.excludedNetworkRules = nil

1) What are you getting for the remoteEndpoint for the NEAppProxyTCPFlow in handleNewFlow? 🤪FZ$--hostName: dns-block-page-sm.familyzone.com remoteEp: 13.210.37.51:80 appId: com.google.Chrome.helper fzmacappproxy 09:43:24.523718+1000 2) After you open the remote side of the connection and open the local flow, where is this happening in your flow copying process?  We use NWTCPConnection instead, but the logic is the same. private func readFromTcpConnection(tcpflow: NEAppProxyTCPFlow) - Void { ... if !self.waitForTCPConnectionToBeReady(connection) { flowClose(tcpFlow: tcpflow, error: nil, connStruct: connStruct) return } connection.readMinimumLength(1, maximumLength: 65535, completionHandler: { [unowned self] (data, error) in guard error == nil else { FZLog(.error, "read from TCP connection error: \(error.debugDescription) \(connection.remoteAddress.debugDescription)") tcpflow.closeWriteWithError(error) tcpflow.closeReadWithError(error) connection.cancel() return } guard let readData = data else { FZLog(.error, "read from TCP connection error: \(connection.remoteAddress.debugDescription)") tcpflow.closeWriteWithError(error) tcpflow.closeReadWithError(error) connection.cancel() } tcpflow.write(readData) { [unowned self] error in guard error == nil else { FZLog(.error, "write to TCP flow error: \(error.debugDescription)") tcpflow.closeWriteWithError(error) tcpflow.closeReadWithError(error) connection.cancel() return } FZLog(.verbose, "write \(readData.count) bytes to TCP flow from \(connection.remoteAddress.debugDescription)") self.readFromTcpConnection(tcpflow: tcpflow) } }) } 3) Does the same thing happen when you use a hostname? No difference when I use the hostname: http://dns-block-page-sm.familyzone.com/