Per-app packet tunnel VPN issue with iOS v13.3 for localhost traffic

Recently our customers have reported that their app doesn't work with per-app packet tunnel on iOS v13.3, but it was working well with the same VPN configuration and same app and vpn client versions on iOS v13.2.2. it is still working fine without per-app packet tunnel configuration or with on-demand packet tunnel configuration of same VPN client.

I saw lots of "Can't assign requested address" for the 127.0.0.1:54187 connections. Is that something change in iOS 13.3 which cause this issue?



default 18:06:11.055989 +0530 com.apple.WebKit.Networking nw_connection_report_state_with_handler_on_nw_queue [C13] reporting state failed error Can't assign requested address

default 18:06:11.179329 +0530 com.apple.WebKit.Networking [C13 D01EF64B-BAF0-4F4F-976A-E258241EB12B 127.0.0.1:54187 tcp, pid: 465, legacy-socket] cancel

default 18:06:11.179400 +0530 com.apple.WebKit.Networking [C13 127.0.0.1:54187 tcp, pid: 465, legacy-socket] cancelled

default 18:06:11.179598 +0530 com.apple.WebKit.Networking 0.000s [C13 737392A6-173C-456A-803E-780DBE59D627 127.0.0.1:54187 socket-flow path=satisfied (Path is satisfied), interface: lo0] path:start

default 18:06:11.179632 +0530 com.apple.WebKit.Networking 0.000s [C13 737392A6-173C-456A-803E-780DBE59D627 127.0.0.1:54187 socket-flow path=satisfied (Path is satisfied), interface: lo0] path:satisfied

default 18:06:11.179672 +0530 com.apple.WebKit.Networking 0.000s [C13 737392A6-173C-456A-803E-780DBE59D627 127.0.0.1:54187 socket-flow path=satisfied (Path is satisfied), interface: lo0] flow:start_connect

default 18:06:11.179709 +0530 com.apple.WebKit.Networking 0.001s [C13 737392A6-173C-456A-803E-780DBE59D627 127.0.0.1:54187 socket-flow path=satisfied (Path is satisfied), interface: lo0] flow:failed_connect Can't assign requested address

(Path is satisfied), interface: lo0] flow:failed_connect Can't assign requested address

default 18:06:11.183745 +0530 com.apple.WebKit.Networking nw_connection_report_state_with_handler_on_nw_queue [C13] reporting state cancelled error Can't assign requested address

Replies

A few questions for clarification:

1) What interface is your VPN using?

2) Is the traffic on the VPN NSURLSession or another API?

3) It looks like your are using WebKit in the logs provided, are you using WKWebView or is this another API?

4) Is there another part of your program listening for the connection on 127.0.0.1?



Matt Eaton

DTS Engineering, CoreOS

meaton3 at apple.com

Thank you meaton! Here are my answers.


1) What interface is your VPN using?
Are you asking either WiFi or MobileData is used for VPN connection? I have device log which recorded the problem when WiFi is in used. I need clarify from our customer if the problem happens when using mobile data.

2) Is the traffic on the VPN NSURLSession or another API?
The VPN-associated app (com.qlik.qliksense.mobile) is using WKWebView, we don't know what API WKWebView is using

3) It looks like your are using WebKit in the logs provided, are you using WKWebView or is this another API?
WKWebView

4) Is there another part of your program listening for the connection on 127.0.0.1?

Yes "com.qlik.qliksense.mobile" (named UnifiedSenseClient in log) is listening on 127.0.0.1 on port 54187 (a client side HTTP proxy component that is part of the app)


Do you want me to upload the recorded device log somewhere?



You mentioned that com.qlik.qliksense.mobile is your VPN and is listening on 127.0.0.1:54187 (lo0), is that correct?


You also mentioned that this does not work with a recent version of iOS only. Is this occurring directly after an update? If the device is restarted does this issue still persist?


Matt Eaton

DTS Engineering, CoreOS

meaton3 at apple.com

Qliksense is NOT VPN client, it is the app which be managed to use the per-app VPN (from mobileiron) and listens on 127.0.0.1:54187.
Customer report issue only for iOS v13.3, we also reproduced it with iOS v13.3. restarting device doesn't help to resolve the issue.

The error that you are seeing is a general EADDRNOTAVAIL error that is seen usually in a case where sockets are involved. This can be difficult to track down without knowing more about how the network code works in your application. Can you share more in code snippets on how the client/server interaction works in your application? If not, you may need to open a TSI for this incident and tag me with it so I can take a closer look.


Matt Eaton

DTS Engineering, CoreOS

meaton3 at apple.com

Thank you, Matt!


I will try to open TSI for this issue. But what I am more curious is the principle of localhost traffic handling in the Apple per-app VPN.


According to the document, the per-app VPN handles the source app's all traffic no matter of the traffic destination, which is the difference to on-demand VPN (device wide, IP routes based).


But I saw localhost traffic routed via app-proxy per-app VPN network extension, and didn't saw the localhost traffic routed via packet-tunnel per-app VPN network extension from my VPN client app log. Is this difference by design? also it seems that resovling "localhost" to 127.0.0.1 also be an issue for some URL related Apple APIs in the per-app packet tunnel VPN environment, so we have to suggest qliksense to use '127.0.0.1' instead of 'localhost'.
Were you or Apple engineers aware of those issues?
Paul Ling

Hey Paul,


Is there a feedback number reporting this issue that you can share?


-Mark

Created APPLE TSI ticket,

Ticket Ack details:
DTS Auto-Ack - Per-app packet tunnel VPN issue with iOS v13.3 for localhost traffic - Follow-up: 727415647.

Thanks,


Paul Ling

Paul,


Would you be able to follow up with your Feedback number associated with this TSI.

Open a bug report through Feedback Assistant.


Matt Eaton

DTS Engineering, CoreOS

meaton3 at apple.com

Here is the feedback ID: FB7535655


Thank you!


Paul Ling

Fantastic. You'll probably be asked to attach a diagnosis log to this bug. To save some back and forth...would you mind heading over to https://developer.apple.com/bug-reporting/profiles-and-logs/ grabbing the appropriate Network Diagnostic profile and attaching the results to your bug?


-Mark

Hi. I am a developer for the com.qlik.qliksense.mobile App. Another VPN (GlobalProtect) is also impacted by iOS 13.3. Device logs show the same signature as with the MobileIron per-App VPN. Impacted customer entered a FB as well (FB7488437).


This issue is business impacting as the App in question is used for corporate business intelligence (BI). Is there

1) an understanding of the root cause: what changed in iOS 13.3

2) an ETA for a fix


Based on impacted customer frustration I will enter another TSI referencing the other FB and TSI IDs.

Hi,


Is there an ETA for a fix on this problem?


Thanks.

The bug that was filled did result in a fix by Engineering. Thank you to everyone who reported this issue and followed up with logs and steps to reproduce. At this time there is no scheduled date that this fix will land.


A next step would be to get a device enrolled in the Apple Beta Software Program so that when a new beta release is put out on the developer portal you can install and test them.



Matt Eaton

DTS Engineering, CoreOS

meaton3 at apple.com

A bug fix for this issue did land in the iOS 13.4 beta release.


Please go and test it out and provide any additional feedback you uncover to the bug that was opened for this incident.

<https://developer.apple.com/news/releases/>


Matt Eaton

DTS Engineering, CoreOS

meaton3 at apple.com