tun interface not receiving any packet after sleep/wake cycle

Hi,


We have a macOS app that uses NEPacketTunnelProvider with the following settings:


settings = NEPacketTunnelNetworkSettings(tunnelRemoteAddress: "127.0.0.1")
settings?.dnsSettings = NEDNSSettings(servers: ["192.0.2.42"])
settings?.dnsSettings?.matchDomains = [""]
settings?.ipv4Settings = NEIPv4Settings(addresses: ["192.0.2.42"], subnetMasks: ["255.255.255.255"])


The app works perfectly but we're seeing a bug that seems to happen only after a long sleep/wake cycle (or when the battery of the MBP dies, then we plug in the power source and go through the "Restore..." screen). The utun{n} interface is up but for some reason no packets are being sent to it.


Only an OS restart seems to solve the issue (disconnecting/reconnecting the VPN, uninstalling the VPN profile, restarting the app doesn't work).


This can be reproduced with our app from the mac appstore:

https://apps.apple.com/app/nextdns/id1464122853


When this happens:

  • The VPN is still on (green) in System preferences
  • The network extension is running fine (just not receiving any packet)
  • ifconfig show the utun{n} interface exactly the same way as when it works
  • netstat -nr shows the same thing as when it works
  • when running `ping 192.0.2.42`, wireshark is not seeing any packets going to that utun{n} interface (whereas we're seeing the packets in wireshark/our network extension when it works, even if we don't answer them).


ifconfig (when this is happening) shows:

utun4: flags=8051<up,pointopoint,running,multicast> mtu 1500
     options=6403<rxcsum,txcsum,channel_io,partial_csum,zeroinvert_csum>
     inet 192.0.2.42 --> 192.0.2.42 netmask 0xffffffff


netstat -nr (when this is happening) shows:

Internet:
Destination        Gateway            Flags        Netif Expire
default            192.168.0.254      UGSc           en0
default            link#10            UCSI       bridge0      !
default            link#18            UCSI         utun4
127                127.0.0.1          UCS            lo0
127.0.0.1          127.0.0.1          UH             lo0
169.254            link#5             UCS            en0      !
192.0.2.42         192.0.2.42         UH           utun4
192.168.0          link#5             UCS            en0      !
192.168.0.13       bc:9f:ef:10:5:4    UHLWIi         en0      !
192.168.0.15/32    link#5             UCS            en0      !
192.168.0.15       78:4f:43:54:ff:5f  UHLWIi         lo0
192.168.0.23       50:bc:96:89:5f:76  UHLWI          en0     73
192.168.0.254/32   link#5             UCS            en0      !
192.168.0.254      14:c:76:8c:97:92   UHLWIir        en0   1196
192.168.2          link#10            UC         bridge0      !
192.168.2.1        82.46.ee.82.4.1    UHLWIi         lo0
224.0.0/4          link#5             UmCS           en0      !
224.0.0/4          link#18            UmCSI        utun4
224.0.0.251        1:0:5e:0:0:fb      UHmLWI         en0
224.0.0.251        1:0:5e:0:0:fb      UHmLWI     bridge0
239.255.255.250    1:0:5e:7f:ff:fa    UHmLWI         en0
255.255.255.255/32 link#5             UCS            en0      !
255.255.255.255/32 link#18            UCSI         utun4


Happy to provide additional debugging info.

Replies

I am working with this thread in a different context.



Matt Eaton

DTS Engineering, CoreOS

meaton3 at apple.com

I'm using this app and struggling with this bug as well.