Post

Replies

Boosts

Views

Activity

Reply to Why udp port 53 traffic is captured?
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?
Apr ’21
Reply to Why udp port 53 traffic is captured?
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?
Apr ’21
Reply to Why udp port 53 traffic is captured?
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?
Apr ’21
Reply to excludedNetworkRules does not take effect
Hi Matt, I am using the same setting as you do: let settings = NETransparentProxyNetworkSettings.init(tunnelRemoteAddress: "127.0.0.1") settings.includedNetworkRules = [ NENetworkRule(remoteNetwork: NWHostEndpoint(hostname: "0.0.0.0", port: "443"),  remotePrefix: 0,  localNetwork: nil,  localPrefix: 0,  protocol:.TCP,  direction: .outbound) ] settings.excludedNetworkRules = [ NENetworkRule(remoteNetwork: NWHostEndpoint(hostname: "apple.com", port: "0"),  remotePrefix: 0,  localNetwork: nil,  localPrefix: 0,  protocol:.TCP,  direction: .outbound) ] But I can still get apple.com traffic in as seen console when visiting from chrome apple.com: 🤪FZ$--hostName: www.apple.com appId: com.google.Chrome.helper fzmacappproxy 16:21:02.531007+1000 🤪FZ$--hostName: supportmetrics.apple.com appId: com.google.Chrome.helper fzmacappproxy 16:21:14.125574+1000
Apr ’21
Reply to excludedNetworkRules does not take effect
Some more traces with that filter rules: 🤪FZ$--hostName: www.apple.com remoteEp: 23.202.173.153:443 appId: com.google.Chrome.helper fzmacappproxy 18:22:57.007704+1000 🤪FZ$--hostName: supportmetrics.apple.com remoteEp: 17.137.160.100:443 appId: com.google.Chrome.helper fzmacappproxy 18:23:47.128264+1000 🤪FZ$--hostName: developer.apple.com remoteEp: 17.253.67.203:443 appId: com.google.Chrome.helper fzmacappproxy 18:23:47.485234+1000
Apr ’21
Reply to AppProxyProvider is not happy with some website
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/
May ’21