Post not yet marked as solved
Here is the feedback ID: FB7535655Thank you!Paul Ling
Post not yet marked as solved
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
Post not yet marked as solved
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
Post not yet marked as solved
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.
Post not yet marked as solved
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 using3) It looks like your are using WebKit in the logs provided, are you using WKWebView or is this another API? WKWebView4) 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?
Post not yet marked as solved
I also experience this issue on both macOS 10.14.6 and 10.15.1 now. The attached picture shows the wireshark capture on the bridge100 interface which is internet sharing on my mac.The DNS request had been sent to 2001:2:0:aab1::1#53, but the responses were received from 2001:2:0:aab1:d3e:d127:f670:337#53, my device then respond with ICMP (Destination Unreachable).Update: Actually iOS 12.4 accept this DNS use case (send to one but get from another one), but Android doesn't!!! https://share.icloud.com/photos/0hF48QL0-VlXAnNj3kmqB9yeA
Post not yet marked as solved
According to Configuration Profile ReferenceUnder Per-App VPN Payload section, "The Per-App VPN payload supports all of the keys described in VPN Payload plus the following additional keys:". That implys to the developer that per-app VPN does support on-demand VPN keys, which include DNS.Under DNS Dictionary Keys of VPN payload section, "If VPNType is IKEv2, the following DNS keys may be provided:" it seems say DNS will not work for VPN type of VPN (Custom SSL VPN), but actually for device on-demand packet tunnel provider, this DNS configuration (via NETunnelNetworkSettings.DNSSettings in API) does work, include "matchdomains".How should developer to understand iOS/MacOS DNS resolving for the app associated with per-app packet tunnel?
Post not yet marked as solved
Hello, EskimoThank you for explaination!I have tested that all you said is perfectly match the device packet-tunnel behavior, but per-app packet tunnel seems doesn't follow what you said and has different behavior on my MacBook and my customer test MacBook (both are v10.14.6) when tested with Chrome browser app.In my MacBook, all DNS requests go to device DNS via device primary interface (not VPN) no matter of wether matchdomains is empty string or "mydomain.com". But in my customer test MacBook, all DNS requests go to the VPN DNS no matter of wether matchdomains is empty string or "hisdomain.org;hisdoman.biz".I also tried define IPv4 routes (10.0.0.0/8) for per-app packet-tunnel even though i know it does work for TCP/UDP traffic routing, but I just want to help for DNS resolving because the customer VPN DNS can only resolve their own internal FQDN, not public FQDN.Is that only device VPN is the solution for this packet-tunnel situation? Is the DNSProxy NE can be another solution co-working with packet-tunnel on BYOD devices (not only the supervised devices)?Thank you!Paul Ling
