Always On VPN (AOVPN) is preventing the attachment of the filterControlProvider network extension

I have noticed a specific behavior when the Always-On VPN (AOVPN) is active in iOS. It seems that there is an issue with attaching a control filter profile, which results in no control filter running with AOVPN. It's worth noting that AOVPN blocks internet traffic if disconnected. However, when using other VPN types, the control filter profile successfully attaches and receives callbacks in the filterContentProvider network extension.

are there any constraints imposed by the Apple architecture that prevent the attachment of the filterContentProvider network extension specifically when AOVPN is running?

This does not surprise me that there would be a conflict here because the Always On VPN architecture is designed for MDM environments where all traffic must traverse the tunnel. The only exception to this would be allowlisted apps etc..

Regarding:

are there any constraints imposed by the Apple architecture that prevent the attachment of the filterContentProvider network extension specifically when AOVPN is running?

From the provider level I do not know of any technical conflicts between the two providers but like I mentioned above, if your content filter is being setup with MDM and is registering to claim specific app level traffic, and then the Always on VPN is setup with a MDM to claim all of the device's traffic it seems like there would be a natural conflict in at least which provider is claiming the traffic. Why do you need both providers? Is the Always On VPN not sufficient for your needs?

We have a use case where we want to use both providers simultaneously. Our intention is to utilize one provider for its antiphishing feature, while the other provider will serve as the Mobile Device Management (MDM) solution.

Always On VPN (AOVPN) is preventing the attachment of the filterControlProvider network extension
 
 
Q