I'm working on a network extension that provides a VPN tunnel. The logic behind the tunnel provider requires me to connect the backend to pull recent configuration and then configure the routing. It works in general but fails with some circumstances. I have 100% reproducible fails if I run OpenVPN tunnel in parallel. When it happens it looks like the network extension cannot connect the backend (any internet resource actually). Requests fail by timeout.
To troubleshoot this situations I've added NWPathMonitor at my NEPacketTunnelProvider subclass:
pathMonitor?.pathUpdateHandler = { path in
logger.info("Path update: \(path)")
logger.info(" : \(path.availableInterfaces)")
}
On successful scenarios I observed logs:
14:53:19:829 Starting VPN tunnel...
14:53:19:895 Path update: satisfied (Path is satisfied), interface: en0[802.11], scoped, ipv4, ipv6, dns, uses wifi
14:53:19:899 : [en0]
14:53:22:237 Path update: satisfied (Path is satisfied), interface: en0[802.11], scoped, ipv4, ipv6, dns, uses wifi
14:53:22:253 : [en0, utun12]
14:53:22:325 VPN tunnel is started.
But if I start another tunnel first using OpenVPN (it's our corporate VPN) I observe failures with such log messages:
14:54:26:113 Starting VPN tunnel...
14:54:26:140 Path update: satisfied (Path is satisfied), interface: en0[802.11], scoped, ipv4, ipv6, dns, uses wifi
14:54:26:141 : [en0]
14:55:28:259 Failed to start VPN tunnel.
utun12 that was used by the extension in case of success is now occupied by the OpenVPN tunnel. The system creates utun13 for me but it feels like its misconfigured:
> ifconfig
(omitted most of the output)
utun12: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1500
inet 172.28.11.236 --> 172.28.10.1 netmask 0xfffffe00
nd6 options=201<PERFORMNUD,DAD>
utun13: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1500
options=6460<TSO4,TSO6,CHANNEL_IO,PARTIAL_CSUM,ZEROINVERT_CSUM>
Is it a system bug and what else can I do to diagnose the root cause of these failures?