I have been writing a custom subclass of NETransparentProxyProvider. Here is what I do to handle NEAppProxyUDPFlow. (1) Return true in method handleNewUDPFlow(_:initialRemoteEndpoint:) and retain flow object (2) Open flow open(withLocalEndpoint:completionHandler:) (3) Read datagrams readDatagrams(completionHandler: @escaping ([Data]?, [NWEndpoint]?, Error?) -> Void) (4) Create NWConnection object wait for it to be in ready state (5) Send data from step 3 send(content: Data?, contentContext: NWConnection.ContentContext = .defaultMessage, isComplete: Bool = true, completion: NWConnection.SendCompletion) (6) Listen for the response receiveMessage(completion: @escaping (Data?, NWConnection.ContentContext?, Bool, NWError?) -> Void) (7) Write a response to the flow writeDatagrams(_ datagrams: [Data], sentBy remoteEndpoints: [NWEndpoint], completionHandler: @escaping (Error?) -> Void) The scheme above works. One of the questions I have is when to close the flow? The first case is when the datagrams and remoteEndpoints arrays are non-nil but are empty in readDatagrams callback But how about the UDP server response? rfc768 spec is pretty short https://datatracker.ietf.org/doc/html/rfc768 And there is no response as such in UDP. The server extracts the source port and source address from the packet and may or may not send data to that socket. Theoretically, it can send multiple replies to the same socket How can I know that no more data is expected to be received in NWConnection to close the connection and release the flow? The receive message callback can only tell us that that one datagram has been delivered Can I not close the flow at all?

Hi everyone, I have been working on the VPN app and on of my tasks is to show data downloaded/uploaded for VPN connection. I took approach with sysctl based on this gist https://gist.github.com/mbbx6spp/6309854 The code from gist does not matter match as I check my network metrics with cli tool netstat -ib -I <interface name> Everything works fine for hardware interfaces en[0-9], and for uploaded data. The only problem that I need to solve is for virtual interfaces like utun or ipsec the download data in the statistics is being doubled or tripled. Speaking in more technical terms Ibytes is three times bigger than it should be. I understand that VPN connection may have some size overheads from encryption, tcp, http, ssl protocols etc. But that should be no higher than 20% in my expectations. It is better to reproduce this issue on macOS with build in IKEv2 protocol on macOs Big Sur. Set up IKEv2 VPN connection Get interface name. For example using netstat -rn. usually for IKEv2 the name is ipsec0 Get current stats: netstat -ib -I ipsec0 Download 100 MB file https://speed.hetzner.de/ Get stats again netstat -ib -I ipsec0 So, for IKEv2 protocol Ibytes shows 329024520 bytes(328 MB) instead of ~100 Same behaviour is for other protocols https://github.com/WireGuard/wireguard-go Is there a good explanation for this behaviour? How to fix it? Is it ok just to divide by some coefficient obtained from practical tests(like 2 or 3) ?