Difference between PacketTunnelProvider and utun

I wanted to understand the difference between the two methods, and in which scenario both should be used?

Creating a virtual interface using the NEPacketTunnelProvider APIs is the Apple supported mechanism for capturing selective routes and tunneling IP traffic to secure destinations. Using this path gives you all of the machinery needed to configure the NEIPv4Settings and NEIPv4Route for your tunnel, and as you mentioned, read and write traffic to that interface. Going the manual route of creating a utun interface and then binding sockets to that interface may technically work but it is not a supported path and I would encourage you to use the Network Extension APIs instead.

Thanks for the response @meaton, I wanted to understand it further on how the manual route of creating utun interface and doing read/write can limit any functionalities. I was going through openvpn code and seems they also have used manual method to create utun interface to read/write operation for tunneling L3 packets. For me also it seems an easier way to use the utun method as it is easy to maintain the code avoiding the sandboxing and app groups and managing the inbound and outbound connections..

Also as i read more, it seems tun driver is by default built-in in MacOS, so if we already have this driver installed why not use it to intercept layer 3 packets for tunneling. I want to understand what limitations it have?

how the manual route of creating utun interface and doing read/write can limit any functionalities. it is easy to maintain the code avoiding the sandboxing and app groups and managing the inbound and outbound connections.

Essentially we have created a supported API path for working with VPNs and virtual interfaces on our platforms, and that is the Network Extension frameworks. That means that if something breaks or goes wrong, you have a supported route to file bugs or contact DTS about this path. Going the route of building a virtual interface by hand and writing code around this is not the supported route. So if something goes wrong or changes in the OS, then you will need to find a way to deal with deal these changes on your own.

Furthermore, I would argue that taking advantage of security features like the Sandbox, that comes out of the box with Network Extensions, is something that you would want to adopt in your project. For example, one of the main goals for a Sandbox is to help protect files and resources that belong to a specific project on disk. If these files are not Sandboxed then that means anyone can arbitrarily edit them an that is not great.

Thanks for your response Meaton. I understand what you are trying to explain. I will discuss the options and limitations internally with my team. One more data if you can share, do you see possibility of removing 'utun' support from Apple, if yes, anytime lines? This data will be a critical input for us for discussion making.

Hi @meaton, One more clarification:

Is my understanding correct for Apple's recommend approach, please correct me if I am wrong at any place:

1. PacketTunnelProvider class in NetworkExtension framework can be used to activate and configure the utun interface.
2. Now to define the network rules:

• either use "NEPacketTunnelNetworkSettings, ipv4Settings" settings
• or use "route add " command to route traffic on utun interface manually

1. Now for tunneling IP-Packets, read/write operation can be directly done on the utun interface either by an app/service inside or outside the App Group.

TIA

Yes, NEPacketTunnelNetworkSettings is the high level object that allows you to define the IPv4/v6 settings on your interface as well as claim IPv4/6 routes on that interface. From there you will setup the tunnel's NEPacketTunnelFlow object to read IP packets from the virtual interface, encapsulate them with your tunneling protocol, and send them out over the network. Likewise, read the packets from the network and write them to the interface.