WKWebView and SFSafariViewController with NE per app vpn

Hello -

Network Extensions with per app vpn (via MDM or profile) and apps that use WKWebView or SFSafariViewController have a big problem with since that traffic does not go over the NE.

This creates a lot of issues with many apps in corporate environments due to many apps using web views for their login process. For example, login into apps like Slack, Office 365, Zendesk, Jira, Confluence and many others use the web views for the login process. Majority of the traffic goes over the NE but auth does not and since WKWebView/SFSafariViewControllers do not have proxy there is no real way to fix this.

The use case is that many corporate apps across many companies are using IP restrictions to lock down access to corporate data. With this limitation there is no real way to access those on iOS/iPadOS without establishing a device wide VPN (not possible in user enrollment mode) or using AssociatedDomains (something almost impossible to manage since as an MDM vendor we do not know how an app like Zendesk/Slack/Outlook are built and what URLs they use internally). At best we can do hacks that are a PITA to maintain.

Does Apple have any recommendations how to solve this in the short term vs hopefully Apple addressing this limitation in the long term as part of an update. Either by way of MDM or Network Extension framework would be great.

One idea is if we can use bundle id's for the WKWebVIew/SFSafariViewController to associate traffic for user enrollment managed apps with the NE. Or maybe Associated Domains can be managed with wild cards (again in a user enrollment MDM this makes sense since ALL apps should be going over a corporate VPN).

I've filled Apple feedback around these and 9891393 and 9891440 but never got any response on how to actually deal with this very common scenario.

Just to add one important detail - the above question is related to NEPacketTunnelProvider.

FB9891393 FB9891440

The situation with WKWebView is a known issue and we’re using your bug, FB9891393, to track it.

My understanding is that SFSafariViewController is working as designed here. It’s considered to be exactly the same as Safari, so it honours the SafariDomains setup.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Thanks eskimo!

With user enrollment MDM on iOS/iPadOS SafariDomains don't seem to be supported. It doesn't specifically say so here https://developer.apple.com/documentation/devicemanagement/applayervpn but it doesn't wind up getting used.

Note, even Intune documentation calls this out "Per-App VPN. This support excludes Safari Domains as User Enrollment doesn't support configuring Safari settings." (https://learn.microsoft.com/en-us/mem/intune/enrollment/ios-user-enrollment-supported-actions)

Any chance this will be addressed any time soon? Without a way to specify SafariDomains or the original issue with WKWebView not respecting per app vpn rules, there is no workarounds to the root issue (putting IP restrictions on corporate apps) except to go the route of doing whole device VPN (something we'd prefer not to do for privacy reasons).

It doesn't specifically say so … but it doesn't wind up getting used.

When you see deficiencies in the docs like this, please do file a bug against them.

Any chance this will be addressed any time soon?

I can’t predict the future, alas.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

WKWebView and SFSafariViewController with NE per app vpn
 
 
Q