Note Please reply as a reply, not in the comments. I’m not notified of replies in the comments. See Quinn’s Top Ten DevForums Tips for this and other hints.
Apparently we don't use the NETunnelProviderManager at all
Bah, this is complex. There are two routingMethod properties:
You can’t avoid these types when building a tunnel:
-
Both NEAppProxyProvider and NEPacketTunnelProvider are subclasses of NETunnelProvider.
-
NEAppProxyProviderManager is a subclass of NETunnelProviderManager.
-
Packet tunnel apps use NETunnelProviderManager directly.
Both properties are read-only because:
-
An app proxy provider is always in per-app mode, and thus the property is always .sourceApplication.
-
A packet tunnel provider can only be put into per-app mode via a configuration profile.
Anyway, back to your main issue. I can’t see any reason why your packet tunnel provider should interfere with the flow metadata on content filter. This is true in general, but especially true in destination IP mode, where the packet tunnel provider operates entirely ‘below’ the content filter.
Does this problem only occur with your packet tunnel provider? Or can you reproduce it with a third-party VPN product that uses a packet tunnel provider?
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
