I close this thread myself. What I observed is not correct.

I noticed that on https://developer.apple.com/documentation/networkextension/packet_tunnel_provider Note When a VPN configuration is active, connections use the VPN instead of iCloud Private Relay. Network Extension providers also don’t use iCloud Private Relay. and this post https://developer.apple.com/forums/thread/682274. it seems that the Private Relay should have the lowest precedence, but my test shows that the traffic from the browser still being routed to the Private Relay.

Thanks Matt. I just want to add some more observe results: On an iPhone 5s iOS 12.5.4 run the same application the Message too long doesn't happen no matter it's on WiFi or Cellular network; On an iPhone 7 iOS 14.6, it's very easy to reproduce this issue on a WiFi network, but I never see it happen on a Cellular network; I didn't change the MTU in the code but set the tunnelOverheadBytes instead. When it's set to be 44 or 0 the same issue happens; If ignoring the EMSGSIZE error when it happens the setReadHandler seems to run into a Message too long error dead loop, so when it happens I have to restart the UDP session.

I also got this error Error Domain=NSPOSIXErrorDomain Code=40 "Message too long" with NWUDPSession setReadHandler method on iOS 14.6, WiFi network.

And another found is that on the home Wifi network(which has PPPoE router provided by carrier) with an iOS 14 iPhone the message will be like udp_validate_cksum_internal * udp incorrect IPv4-UDP non-offload checksum * ulen 1506 And the pppoe header length is 6. Compared with previous network with Vlan the error message showed ulen is 1502. I believe there most probably a bug exists somewhere in iOS 14 kernel or in network extension. Since I didn't found such issue under the same condition on iOS 12, this issue may only exists in iOS 14. The reproduce condition is with NEPacketTunnelProvider set the MTU of the UTUN to be a value bigger or equal than 1480(Theoretically we should be able to set this value to a very big size like 65535 and without any problem) or overhead size to be 0, and run it on an iOS 14 iPhone, on a Wifi network which has a Vlan setting or PPPoE, on inbound packets there will be such problem.

Thanks Matt. I just found that the checksum errors only happens when I'm testing with an iOS 14 device. When I'm testing with an iOS 12 device it works quite normal. When I set the MTU of the UTUN to be 1480(with an iOS 14 iPhone and WIFI with VLAN settings) and load *google.com* then there will be such errors shown on console. With other WIFI or mobile network I didn't see such errors.

Yes. If set includeAllNetworks to be false there is no such issue. Or firstly connect with the console without VPN switched on, when it shows messages then switch on the VPN it's also normal.

With this issue it also can not Attach to Process in the Xcode to the packet tunnel. It shows Details Failed to start remote service "com.apple.mobile.installation_proxy" on device. Domain: com.apple.dtdevicekit Code: 811 Recovery Suggestion: Please check your connection to your device. User Info: {   DVTRadarComponentKey = 261622; }- Could not connect to the device. Domain: com.apple.dt.MobileDeviceErrorDomain Code: -402653083 User Info: {   DVTRadarComponentKey = 261622;   MobileDeviceErrorCode = "(0xE8000065)";   "com.apple.dtdevicekit.stacktrace" = ( 0  DTDeviceKitBase           0x0000000127d3f93f DTDKCreateNSErrorFromAMDErrorCode + 220 1  DTDeviceKitBase           0x0000000127d4fb04 __63-[DTDKRemoteDeviceConnection startFirstServiceOf:unlockKeybag:]_block_invoke + 613 2  DTDeviceKitBase           0x0000000127d4f1d0 __48-[DTDKRemoteDeviceConnection futureWithSession:]_block_invoke_3 + 22 3  DTDeviceKitBase           0x0000000127d41a9f __DTDKExecuteInSession_block_invoke_2 + 35 4  DTDeviceKitBase           0x0000000127d41179 __DTDKExecuteWithConnection_block_invoke_2 + 218 5  DTDeviceKitBase           0x0000000127d41076 __DTDKExecuteWithConnection_block_invoke + 106 6  libdispatch.dylib          0x00007fff6c6c3658 _dispatch_client_callout + 8 7  libdispatch.dylib          0x00007fff6c6cf6ec _dispatch_lane_barrier_sync_invoke_and_complete + 60 8  DVTFoundation            0x000000010bf3edef DVTDispatchBarrierSync + 208 9  DVTFoundation            0x000000010bf15f06 -[DVTDispatchLock performLockedBlock:] + 60 10 DTDeviceKitBase           0x0000000127d40f77 DTDKExecuteWithConnection + 226 11 DTDeviceKitBase           0x0000000127d41943 DTDKExecuteInSession + 239 12 DTDeviceKitBase           0x0000000127d4f022 __48-[DTDKRemoteDeviceConnection futureWithSession:]_block_invoke_2 + 131 13 DVTFoundation            0x000000010bf3c2aa DVT_CALLING_CLIENT_BLOCK + 7 14 DVTFoundation            0x000000010bf3decc __DVTDispatchAsync_block_invoke + 1191 15 libdispatch.dylib          0x00007fff6c6c26c4 _dispatch_call_block_and_release + 12 16 libdispatch.dylib          0x00007fff6c6c3658 _dispatch_client_callout + 8 17 libdispatch.dylib          0x00007fff6c6c8c44 _dispatch_lane_serial_drain + 597 18 libdispatch.dylib          0x00007fff6c6c9609 _dispatch_lane_invoke + 414 19 libdispatch.dylib          0x00007fff6c6d2c09 _dispatch_workloop_worker_thread + 596 20 libsystem_pthread.dylib       0x00007fff6c91da3d _pthread_wqthread + 290 21 libsystem_pthread.dylib       0x00007fff6c91cb77 start_wqthread + 15 ); }- System Information macOS Version 10.15.7 (Build 19H2) Xcode 12.0.1 (17220)

Thanks Matt. Just raised a bug report: FB8815876 (With VPN switched on no messages can be seen on console and can not connect with Xcode) Also add more details here for others to see if they can reproduce the same issue step by step. Description of the issue: When I tested with my iPhone SE(1st generation, iOS 14.0.1) on Mac OS Catalina 10.15.7 / Xcode 12.0.1 I found that with the VPN(NETunnelProvider, 'includeAllNetworks' set to be true) switched on there are no messages being shown on the console, and also on Xcode it shows 'iPhone(unavailable)'. After I switched off the VPN it came back to normal. I was using a USB cable to connect the iOS device with the MBP's left side USB port. Steps to reproduce: An iPhone SE(1st generation, iOS 14.0.1) / Mac OS Catalina 10.15.7 / Xcode 12.0.1; A VPN application coded with NETunnelProvider, set 'includeAllNetworks' to be true (if it's false then cannot reproduce this issue); Install the VPN application on the iPhone and switch it on; Connect the iPhone to the Mac Book Pro with a USB cable; Only after the iPhone is connected with the Mac Book Pro then(this is critical to reproduce the issue) open 'Console' on the Mac Book Pro and check the messages on the iPhone; Open 'Xcode' to select a device to run. Expect results: On 'Console' could see the messages; On 'Xcode' could see the 'iPhone'; Actual results: On 'Console' there are no messages output; On 'Xcode' it shows iPhone(unavailable).

Thanks for your reply Matt. I was using a USB cable to connect the iOS device with the MBP's left side USB port. The mac OS version is Catalina 10.15.7. Xcode 12.0.1.

For programmingly set VPN set this property which is available after iOS 14 var includeAllNetworks: Bool { get set } https://developer.apple.com/documentation/networkextension/nevpnprotocol/3131931-includeallnetworks of NEVPNProtocol to be true could fix this issue. We could see on this page https://developer.apple.com/documentation/devicemanagement/vpn/vpn that includeAllNetworks is available for iOS 4.0+ and macOS 10.7+. But in this document https://developer.apple.com/business/documentation/Configuration-Profile-Reference.pdf includeAllNetworks doesn't exist yet.