Thanks again @meaton for all the helpful replies!As I said I would do, I tried to reproduce it a lot of times, including uploading big files (3GB, 5GB) and it didn't reproduce on my Mac.However, at the customer, it reproduced easily, even with small files - she tries to upload 3 files of ~10mb each, and it happens.I checked again her Console logs, and no sign for utun_output or ctl_enqueuembuf, but those line seems related:default 17:27:22.110479 -0400 symptomsd NWPath: kNetworkPrimary NWPathStatusSatisfied interface en1 index 6 default 17:27:22.110535 -0400 symptomsd primary interface change to en1, type 1 default 17:27:22.110692 -0400 symptomsd Primary change default 17:27:22.110754 -0400 symptomsd noi: NOI: v:0 type:Wifi, isAny:yes, isBuiltin:no, loi:-1, flags:0, event: kNotificationNewPrimaryInterface, oldLoadedLqm: 100, rawLoadedLqm: 100, newLoadedLqm: 100, not posting default 17:27:22.118243 -0400 apsd Looking up connection on peer: d573aec0 found default 17:27:22.118320 -0400 apsd Looking up connection on peer: d573aec0 found default 17:27:22.118394 -0400 apsd Looking up connection on peer: d573aec0 found default 17:27:22.131586 -0400 mapspushd Delivering connectionStatusChange from apsd: NO default 17:27:22.133413 -0400 mapspushd Delivering connectionStatusChange from apsd: NO default 17:27:22.152288 -0400 suggestd Delivering connectionStatusChange from apsd: NO default 17:27:22.152421 -0400 suggestd Delivering connectionStatusChange from apsd: NO default 17:27:22.152456 -0400 suggestd Delivering connectionStatusChange from apsd: YES default 17:27:22.152897 -0400 apsd Looking up connection on peer: d57346a0 found default 17:27:22.154376 -0400 kernel SIOCPROTODETACH_IN6: utun1 error=6 error 17:27:22.154579 -0400 MyAppExtension interface_get_mtu:3730 SIOCGIFMTU failed: Device not configured default 17:27:22.155072 -0400 MyAppExtension PacketTunnelProvider deinit default 17:27:22.161293 -0400 configd network changed default 17:27:22.165453 -0400 nsurlsessiond received network changed event default 17:27:22.164295 -0400 airportd _processIPv4Changes: ARP/NDP offloads disabled, not programming the offload default 17:27:22.154392 -0400 kernel com.citrix.kernel.dne: default 17:27:22.154392 -0400 kernel default 17:27:22.154394 -0400 kernel socket_event_callback: ifnet_find_by_name("utun1") returned 6 default 17:27:22.154405 -0400 kernel com.citrix.kernel.dne: default 17:27:22.154406 -0400 kernel default 17:27:22.154408 -0400 kernel socket_event_callback: ifnet_find_by_name("utun1") returned 6 default 17:27:22.154428 -0400 kernel com.citrix.kernel.dne: default 17:27:22.154429 -0400 kernel default 17:27:22.154431 -0400 kernel socket_event_callback: ifnet_find_by_name("utun1") returned 6 default 17:27:22.227699 -0400 UserEventAgent -[NEFileHandleMaintainer reset:84 Current file handles for com.apple.networkextension.file-descriptor-maintainer: ( "Policy Session socket (58)", "Network Agent Registration socket (137) 76FF4E17-DE92-4B00-B8CC-EE7A2A1EC359 BFFC9455-2D18-47CF-A618-96170984E670 1" ) default 17:27:22.227754 -0400 UserEventAgent -[NEUserEventAgentFileHandleMa:57 File Handle Maintainer listening for readable events on Network Agent Registration socket (137) 76FF4E17-DE92-4B00-B8CC-EE7A2A1EC359 BFFC9455-2D18-47CF-A618-96170984E670 1 default 17:27:22.233833 -0400 assistantd Delivering connectionStatusChange from apsd: NOSo right before the disconnection, there's something with utun1 error = 6Since I can't reproduce it anymore, and it doesn't look related to the buffer side (at least not according to the customer's logs), I asked for them to try to reproduce it on their environment.I'll update with my findings.And if the logs I just posted above gives any clue - I'll be happy to know.Thanks!Edit: Just to add that it's not the case of too much outbound data buffered, I have logs for that scenario, and I can't see it didn't happen here.

Update: I just reproduced it here on my Mac. Using my app for the VPN I connected between my Mac and a Win machine. The issue reproduced only when trying to upload big files (1GB).At the Console I saw those lines (I copied only the relevant lines), all of them are from the kernel process:utun_output - ctl_enqueuembuf failed: 55 //this line appears something like 200 times in a row.. smb2fs_smb_cmpd_query_dir: Warning: No lease found for smbfs_pack_vap: Missing Finder Info <.DS_Store> tcp_timers: tcp_output() returned 0 with retransmission timer disabled for 51891 > 443 in state 4, reset timer to 1063 Starting poll type 4 Restarting poll type 4And after a few seconds, those lines, coming from the process KernelEventAgent:tid 31b110ce received event(s) VQ_NOTRESP (1) tid 31b110ce type 'smbfs', mounted on '/Volumes/Roee', from '//user@10.10.1.8/Roee', not responding tid 31b110ce found 1 filesystem(s) with problem(s)Next steps: I'll check if it's persistant, and if so - I'll try to reproduce it with the IKEv2 as you said.Also, I'll create a sysdiagnose. But the question for now: Is it possible to tell what's the error from the above logs?

Thanks for the advice! I'll ask the customer to to that and report back.I also found out that this reproduces only on her Mac, while for other users of that company, at the same office, everything works fine with SMB and my app. Also, another question - if using the IKEv2 they will be able to upload the files, then the problem is at my app. But what's my next step? Can I ask them to create a sysdiganose, or is it just for developers?

Yes, the VPN hangs, and AFAIK, the reboot is needed because from that moment he can't access the internet. But I already asked the customer about 'why the reboot', to verify that what I've just said is accurate, I'll update when he'll answer.So from your answer, I guess there aren't any known issues with VPN over SMB?

More info: Reproducing this, causing the stopTunnelWithReason to be called, with the reason 'userLogout'.I'll update the bug with that info.

Sure, I opened a bug - FB7637793.Thanks for all the help!

Exactly."this is happening on Mojave currently but not Catalina" - this is according to the user, I didn't test it myself.

Thanks for the quick answer!

Not related to the original question, but can I ask what's the difference between system extension and app extension?"Your NetworkExtension provider must be packaged as a system extension, not an app extension."

Great, sounds now very reasonable to behave this way.Thanks for both of you for the quick and helpful replies!

I just checked it, and it's correct.If onDemand is disabled, there is traffic when the tunnel is established.If onDemand is enabled, there isn't any trafic when the tunnel is established, even if I'm starting the tunnel myself, without waiting for the onDemandRule to trigger the VPN.So thanks for the answer.Should I open a bug for this? Or is it somehow the expected behavior?

Thanks for all the help (and also for the patience 🙂)

First, thanks for the detailed answer!But as for my VPN, this is an enterprise VPN (and not a personal VPN), it was created with NETunnelProviderManager, and this is the documentation for the NETunnelProviderManager class:VPN configurations created using NETunnelProviderManager are classified as regular enterprise VPN configurations (as opposed to the Personal VPN configurations created by NEVPNManager).Also, it's not a per-app VPN (so it can't be always-on) , but it's an enterprise VPN, with onDemandRules to try connectting whenever there's traffic.

Thanks for the reply, but it's kind of surprising. I checked now at the documentation, and this is probably the relevant part (which I never noticed before, Taken from https://developer.apple.com/documentation/networkextension/netunnelprovidermanager):The Per-App VPN app rules serve as both routing rules and VPN On Demand rules. This is in contrast to IP destination-based routing, where the VPN On Demand rules are configured separately from the routing rules. When the onDemandEnabled property is set to true and an app that matches the Per-App VPN rules attempts to communicate over the network, the VPN will be started automatically.So can you explain what will heppen at the above case, where the VPN is not per app and I set the onDemandRules to "always connect"?Which traffic will start the VPN? And once the VPN is enbaled, if I understand correctly not all the app's traffic is guarenteed to go through the VPN, is it correct (the mail app didn't trigger the VPN to start, but if the VPN was already running, the mail would go via the VPN or bypass it)?And final question - Is it related to onDemand at all? If I set the VPN to be not per app and not onDemand, and I start the VPN, then it's the same scenario where not all traffic must go through it?P.S - I can't use the per-app because not all of my users have MDM system.The only way to configure Per-App VPN is by enrolling the device in a Mobile Device Management (MDM) system, and then linking apps that are managed by the MDM system with a VPN configuration created from a com.apple.vpn.managed.applayer configuration profile payload

The onDemandRules contains only one class, onDemandRuleConnect, without any rules to match so it always applies:let onDemandRuleConnect = NEOnDemandRuleConnect() myVpn.onDemandRules = [onDemandRuleConnect]This is the description of the NEOnDemandRuleConnect class:When rules of this class match, the VPN connection is started whenever an application running on the system opens a network connection. Network connectivity will be blocked until the VPN is connected.So whenever there's traffic, the VPN should try to connect, but as I said above, it will fail. So AFAIK, all the traffic should be blocked, including the incoming email.I have a guess that might explain it, but I don't know if it's true:If the emails are pushed to the device from the mail server (aginst been fetched by the iPhone), and according to the above description, "the VPN connection is started whenever an application running on the system opens a network connection", maybe it's not consider to openning a network connection?