Include routes are not being added for PacketTunnelProvider after app update

We have a PakcetTunnelProvider in SystemExtension with split tunnelling. We are setting up a private range of IP address (240.0.0.1/10) as include routes and a few match domains using NEPacketTunnelNetworkSettings. On fresh install, everything works fine. We are able to setup tunnel settings and receive DNS as well as data traffic as per our rules.

But during upgrade of our app from one version to another, the tunnel settings are not applied correctly. Only match domains are being setup but include route fails and all our traffic goes to en0 interface. setTunnelNetworkSettings api returns no error but in console log we see below logs:

2022-10-05 17:47:06.698948+0530 0x315 Default 0x0 135 0 configd: [com.apple.SystemConfiguration:IPMonitor] failed to add route, File exists:
2022-10-05 17:47:06.698955+0530 0x315 Default 0x0 135 0 configd: [com.apple.SystemConfiguration:IPMonitor] Net 240.0.0.1/10 Ifp utun5 Ifa 240.0.0.1 [last] [force]

This log is printed about 32 ms after we receive callback from setTunnelNetworkSettings method without error. If we do netstat -r, we don't see the route listed there at all. So, we are sure that no other interface is claiming that route. If we apply those settings again, it succeeds and starts working again.

So, we do not understand why route add is failing and why is NE API not returning this error to our extension?

The update path is:

  1. We have extension up and running
  2. We stop app and replace with new one
  3. New app triggers SysEx replacement which stops the NE
  4. We try to clear tunnel settings during stop but it gets ignored (console log -> ESMVPNSession[Primary Tunnel:MyVPN:E7DBA018-7D8F-4D6E-9DCE-141D000EA5CC:(null)] in state NESMVPNSessionStateStopping: plugin disconnecting, ignoring clear configuration request)
  5. The replacement completes and NE Tunnel is started again
  6. It creates new tunnel settings with match domains and hard coded include routes and sets the configuration.
  7. We get success in setTunnelNetworkSettings callback and start reading packets.
  8. configd prints the log that add route has failed.
  9. Our tunnel gets DNS request as per match domains but does not receive any IP packets based on provided include route. All those packets are sent to en0 interface.
Answered by dispatchMain in 733429022

This issue has been fixed in Ventura Beta 11 and the one after that. Waiting for public release to verify on that.

That sounds like a bug to me, and I encourage you to file it as such. Please post your bug number, just for the record.

If we apply those settings again, it succeeds and starts working again.

Which seems like the basis of a workaround, right?

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

That sounds like a bug to me, and I encourage you to file it as such. Please post your bug number, just for the record.

Sure, I will.

Which seems like the basis of a workaround

Yes but there is no way to know that tunnel configuration has failed and we need to double apply settings in all the cases.

Is there a nicer way to know whether our settings have been applied? Or is there a way we can get the routing table in code and if our include route does not exist, apply the settings again?

We ran route monitor during upgrade and we see below sequence of message:

got message of size 180 on Thu Oct 6 15:57:00 2022
RTM_ADD: Add Route: len 180, pid: 135, seq 88, errno 17, flags:<UP,CLONING,STATIC>
locks: inits:
sockaddrs: <DST,GATEWAY,NETMASK,IFP,IFA>
240.0.0.1 255.192.0.0 240.0.0.1

got message of size 180 on Thu Oct 6 15:57:00 2022
RTM_DELETE: Delete Route: len 180, pid: 135, seq 89, errno 3, flags:<UP,CLONING,STATIC>
locks: inits:
sockaddrs: <DST,GATEWAY,NETMASK,IFP,IFA>
240.0.0.1 255.192.0.0 240.0.0.1

got message of size 180 on Thu Oct 6 15:57:00 2022
RTM_ADD: Add Route: len 180, pid: 135, seq 90, errno 17, flags:<UP,CLONING,STATIC>
locks: inits:
sockaddrs: <DST,GATEWAY,NETMASK,IFP,IFA>
240.0.0.1 255.192.0.0 240.0.0.1

As per these messages, add route is failing because route exists but delete route is failing because route does not exists which is quite weird.

Accepted Answer

This issue has been fixed in Ventura Beta 11 and the one after that. Waiting for public release to verify on that.

Include routes are not being added for PacketTunnelProvider after app update
 
 
Q