@hecht It worked pretty well.Many thanks. New folks may end up here, just an FYI, perl is already pre installed on MACOS, so you can fire script like perl /Users/user/Downloads/34e35e4917da2d10fb66e2c88d299b51-3a42cc5e3a79625702e87854c4d87b12e0e947c1/ipstocrash.pl /Users/user/Crash-mess/Application-2022-04-07-081335.ips >symbolicated.crash

Since you suggested dlopen, so I have to say that but my problem is deeper than that. I have filed a DTS ticket as you guys will need exposure to my code. You can look at ticket 2386741

Thanks Quinn. I dont see "starting with iOS 16 you can deploy a content filter to a managed device, but only in per-app mode." option in Apple Configurator. Can you please point me to there? Also Is there any way I can replicate through Xcode directly?

With per-app VPN you can configure this mapping using the NETestAppMapping key in your Info.plist. I tried through info.plist but it flags error that device needs to be managed to execute it. Exploring if I can have my test app as managed app.

While deploying through MDM(Intune), I found MDMs dont have a pre defined way of configuring it. I setup custom profile and it got pushed but it is showing Invalid. Please see below screenshot. Any clues why its showing Invalid? Below is the profile I pushed <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>PayloadContent</key> <array> <dict> <key>FilterBrowsers</key> <true/> <key>FilterSockets</key> <true/> <key>FilterType</key> <string>Plugin</string> <key>PayloadDescription</key> <string>Configures content filtering settings</string> <key>PayloadDisplayName</key> <string>Per App Content Filter</string> <key>PayloadIdentifier</key> <string>com.apple.webcontent-filter.FD133648-8A43-4880-B37D-1F13D57AF3BB</string> <key>PayloadType</key> <string>com.apple.webcontent-filter</string> <key>PayloadUUID</key> <string>FD133648-8A43-4880-B37D-1F13D57AF3BB</string> <key>ContentFilterUUID</key> <string>FD133648-8A43-4780-B37D-1F13D57AF3BB</string> <key>PayloadVersion</key> <integer>1</integer> <key>PluginBundleID</key> <string>com.test.test.filtercontrol</string> <key>UserDefinedName</key> <string>Per App Content Filter</string> </dict> </array> <key>PayloadDisplayName</key> <string>Untitled</string> <key>PayloadIdentifier</key> <string>Test-MacBook-Pro.510D9EF0-8A77-415E-B3FB-0A7C28E316EB</string> <key>PayloadRemovalDisallowed</key> <false/> <key>PayloadType</key> <string>Configuration</string> <key>PayloadUUID</key> <string>A17602B6-4B71-4FAF-84BB-F856092DD5CD</string> <key>PayloadVersion</key> <integer>1</integer> </dict> </plist>

Hi Quinn Can you please take a look on data I provided?

It’s means to be the bundle ID of the container app. Thanks Quinn for the response. Unfortunately that did not help. Profile is still showing invalid. I am suspecting PayloadIdentifier is different for per app content filter but no documentation for this. For example, For packet tunnel, per app vpn has different PayloadIdentifier com.apple.vpn.managed.applayer than device level vpn tunnel PayloadIdentifier com.apple.vpn.managed. <key>PayloadIdentifier</key> <string>com.apple.webcontent-filter.FD133648-8A43-4880-B37D-1F13D57AF3BB</string> I tried by pushing PayloadIdentifier com.apple.webcontent-filter.applayer but then profile didnt get pushed at all. Or any other aspect you think I am missing?

It works, in which case you know that your provider is working in general and this is a configuration problem specific to per-app mode. Yes, it works on supervised device. Its not working for per-app mode FYI I am using Apple Sample App "SimpleTunnel" for testing

Are you perhaps thinking of PayloadType? Yes, I am talking about PayloadType AFAIK there isn’t a separate payload type for this, but I’m basically working off the same docs as you are here. Thanks for confirming this.

Thanks Quinn At that point your routing configuration is irrelevant. You get the packets associated with the flows generated by the app. But even then we need to handle the flows. right? We dont want to handle traffic in captive networks Is there any way we can enforce traffic to go direct over physical interface in per app vpn in scenarios like captive networks? Like we can do over enterprise vpn by removing all include routes.

Can you explain your rationale here? We cannot connect to VPN servers in Captive network. So , no point in capturing the traffic. Instead we prefer to fail open so that end user can authenticate with Captive without any issue(caused by vpn settings on the device) Most folks deploying per-app VPN are trying to connect managed apps to servers that only exist on the organisation’s intranet. Not in our case. Our users can access on public internet too. If the device is on a captive network there’s no way to do that, and so it’s correct to fail the flow.Sending the traffic directly, in plaintext, seems like a weird choice. On Captive network, we want to get out of the picture so that end user can be navigated to Captive page and they can authenticate. If we handle that traffic some captive networks dont redirect to Captive Page.

So what does your VPN do? Our VPN provide access to internal resources on public internet too

How can a resource be both “internal” and “on public internet”? It's not available on public internet without our custom protocol tunnel. Its internal resource but available through our tunnel.

Hi Quinn Any update here please?

What behaviour would the app see when the device is on a captive network? App would show its in fail open state(no traffic capturing) as network is(captive) not in desired state.