Thanks. From the above issue, the only way to resolve it is by: Restarting the device Deleting the VPN and installing it again Re-install the entire app Switching to different VPN does not help, which suggests to me that there is some wrong state that persists?

Finally (and unfortunately) managed to reproduce the issue. VPN stays in the "Connecting..." state indefinitely. It also does not help to try "re-starting" it in the settings. Even when I start tunnel from different app which works fine and attempt to start tunnel for my app, it again gets stuck at "Connecting" Here are the logs. The bottom three messages keep repeating over and over again. NESMVPNSession[Primary Tunnel:AppBlock Blocker:EC537A50-9463-4CAA-9A89-B67EE9316BDB:(null)]: status changed to connecting NESMVPNSession[Primary Tunnel:AppBlock Blocker:EC537A50-9463-4CAA-9A89-B67EE9316BDB:(null)]: got On Demand start message from pid 117 NESMVPNSession[Primary Tunnel:AppBlock Blocker:EC537A50-9463-4CAA-9A89-B67EE9316BDB:(null)]: Received a start command from rapportd[89] NESMVPNSession[Primary Tunnel:AppBlock Blocker:EC537A50-9463-4CAA-9A89-B67EE9316BDB:(null)]: Skip a start command from rapportd[89]: session in state connecting Sometimes when "Connecting..." internet does not work at all on the device, sometimes it does

It looks like the "conversion" to new buffer with the stride is causing issues. When I try saving the original pcmBuffer the callback returns I can hear the sound.

Thanks for the details! I had no idea regarding timing. Changed it to 3 seconds + removed the joinOnce flag. I am going to do phased release and will monitor Sentry regarding these issues.

Thanks! This may be that you are trying to communicate with the device directly after association and that is why you are receiving these errors. If so, add a small delay in to allow for the IP and the association to setup correctly. I am attempting the connection only when the completionHandler gets called, which seems to be as soon as user is done with the system dialog? Meaning they either press "Join" or decline. Then I have 0.5 second delay before attempting to access data from the game console in this case. Unless the completionHandler is somehow called multiple times, I have no idea how accessing the device (or trying to) could lead to errors I am seeing? There is also this one: NEHotspotConfigurationErrorAlreadyAssociated which I would expect to get in cases where I am attempting to join the same network for second time, but I haven't got this one yet. Also, there have been some issue using the flag for joinOnce in iOS 15 Hmm this possibly be it, as I am indeed using this flag. The majority of devices that report the mentioned erros are various versions of iOS 15, but not all of them. Since disconnect should happen as soon as the game console stops providing network, I think I can safely remove this flag and see if there are any changes.

@meaton filled the feedback: FB9414046. Honestly dont have much experience with this so if something is missing or needs clarification - I am happy to update the feedback. Thanks.

This is what I expected, actually. Although I will not comment on what I believe is happening here, I would urge you to consider what would make a network request through a proxy fail to reach the proxy I totally respect you don't wish to comment, but I think I perhaps did not describe the issue correctly, as the problem is not that the connection is failing, but rather it doesn't arrive at the tunnel at all. To summarize my observed behavior based on matchDomains settings: matchDomains = [""] Matches all connections - including Instagram app. - as expected matchDomains = ["twitter.com"] Matches Twitter website and app (specifically 3rd party client Tweetbot) - as expected. matchDomains = ["instagram.com"] Matches only Instagram website, not its app - this feels to me like an incorrect behavior. Since I am handling all Instagram connections in the tunnel when I match all domains.

So I did more testing and so far what I found is that the matchDomains actually seems to work correctly, but not for instagram.com as I already mentioned. I really have no idea why this domain does not work, since I can see the connections in the debug console. From the apps I tried Twitter for example with twitter.com as match and it worked fine for website and app. I also tried subdomains like api.example.com and it works as expected. Is this possibly wort a TSI report? But I don't think there is anything else configuration-wise that I could try? Well, my usecase is a bit different and it is not intended as traditional VPN. It is closer to tools like Charles Proxy or Proxyman.

So I created test app and requests from it behave as expected. If the domain is set via matchDomains is gets "routed" to my VPN. But the Instagram example does not work like this. The app uses i.instagram.com and graph.instagram.com - but even if I try to add them to matchDomains it doesn't work. When matchDomains is [""] - then Instagram and other apps get "routed" to my VPN. I am using the NEProxySettings as part of the NEPacketTunnelNetworkSettings so I can set my local proxy server as the destination for connections. The reason for my matchDomains experiments is that I need to reduce battery consumption and since there are predefined domains that my VPN needs to handle (and can ignore the rest), I am trying to use this settings to use the tunnel only for connections when really necessary.

Thanks, I will do more checking for these two processes. As far as I know these apps that I am manually enabling/selecting in the VPN Settings should be the same category as my app is. The difference is that when my app is selected, these other apps are able to start their tunnels just fine, while mine shows the error mentioned.

Yea, sorry. This is indeed an iOS app. I have tried the loadFromPreferences(completionHandler: method which works fine (without errors) but when I try to start the tunnel againI get the same error about configuration being disabled. I understand that only one VPN configuration may be active at any given point, but this happens when other VPN's aren't running, just that their profile is selected in the Settings - VPN section. Console.app shows just this when trying to start the tunnel: Received an IPC establish request Cannot establish IPC with 2500 because IPC is already in the process of being established The startVPNTunnel, can be passed options, but I couldn't find anything in the docs. Maybe here I could somehow specify to re-enable the configuration? Previously I also tried to re-install the entire profile, but that did not solve this problem.

Yes, this works fine when it is the first install or user hasn't used any other VPN app. The issue happens when my profile has been installed and user has other VPN app which makes its VPN profile the active one.

Is it possible that this is not getting called? I had a couple of os_logs there and nothing in the console.

Thanks for the clarifications. I am more than happy to not touch DNS.. I tried using this crazy code to get all the routes: swift class func getIFAddresses() - [NetInfo] { var addresses = [NetInfo]() var ifaddr : UnsafeMutablePointerifaddrs? = nil if getifaddrs(&ifaddr) == 0 { var ptr = ifaddr; while ptr != nil { let flags = Int32((ptr?.pointee.ifa_flags)!) var addr = ptr?.pointee.ifa_addr.pointee if (flags & (IFF_UP|IFF_RUNNING|IFF_LOOPBACK)) == (IFF_UP|IFF_RUNNING) { if addr?.sa_family == UInt8(AF_INET) || addr?.sa_family == UInt8(AF_INET6) { var hostname = [CChar](repeating: 0, count: Int(NI_MAXHOST)) if (getnameinfo(&addr!, socklen_t((addr?.sa_len)!), &hostname, socklen_t(hostname.count), nil, socklen_t(0), NI_NUMERICHOST) == 0) { if let address = String.init(validatingUTF8:hostname) { var net = ptr?.pointee.ifa_netmask.pointee var netmaskName = [CChar](repeating: 0, count: Int(NI_MAXHOST)) getnameinfo(&net!, socklen_t((net?.sa_len)!), &netmaskName, socklen_t(netmaskName.count), nil, socklen_t(0), NI_NUMERICHOST) if let netmask = String.init(validatingUTF8:netmaskName) { addresses.append(NetInfo(ip: address, netmask: netmask)) } } } } } ptr = ptr?.pointee.ifa_next } freeifaddrs(ifaddr) } return addresses } Which seemed to work. Does the ordering of includedRoutes matter? Since I tried to claim all routes the above code returned (for IPV4 anyway) and then also the default() route which seemed to broke a few apps.

Hi, from what I understand it appears this is not possible to set on-the-fly and it can be configured only when installing the profile.. In my testing this includeAllNetworks behaves quite similarly to settings includedRoutes on the IPV4Settings to NEIPv4Route.default(). This could possibly be set when starting the tunnel, so you would need to stop and start again to toggle this.