Post

Replies

Boosts

Views

Activity

Packet Tunnel Provider can't connect for unknown time after system wake
Hi! We have a product which effectively is a VPN implemented as Packet Tunnel Provider. The one problem we have is strange enough to ask here for help. We have set the disconnectOnSleep to true for our NETunnelProviderProtocol instance, and we are manually reconnecting the tunnel from system did wake callback. Here we have our problem: immediately in system wake callback(NSWorkspace.didWakeNotification), activation of tunnel fails almost always. It goes to connecting (NEVPNStatus), but just after that it goes to disconnecting, and stays disconnected after that. I decided, that system just not ready to connect to the VPN right after wake. I've found no other callbacks, so the only decision was to add retry after a small delay. The retry after 1 second delay works fine for us on Big Sur. Starting with macOS Monterey we have again reports about this problem from our users, now in the logs I can see that it can't reconnect after 1 second of delay, and then even after 5 seconds of delay! It reconnects fine after some time later (seconds, not minutes), but it is definitely bad behaviour. So I have questions: Is my understanding correct, and system can't reactivate VPN tunnel just in the didWake callback, so we need to wait some time? If (1) is true, how long we should wait? Is there any other callback from system, like "Hey, I'm ready now for VPN connections!"? If (1) is false, what could I do next to create stable user experience?
12
0
1.3k
Feb ’22
Should the per-app VPN new app rules be active only after tunnel reload?
Hi! My VPN application has a system extension with NEPacketTunnelProvider inside. In the VPN application I configure the VPN with .forPerAppVPN() tunnel provider manager. Next, I'm setting the appRules field of this tunnel provider with my app rules dynamically during my app run. This is important for us, that we should have an ability to update the app rules dynamically, so we can't just hardcode all apps once. The problem I met is it seems that I have to do reload (disable - enable) the tunnel for new app rules to be active. To see, why is this a problem, consider, please, such scenario: Add some streaming app into profile, and then run it. It begins its streaming business. Add some other app into profile, and then run it. Currently, to force the traffic of this second application to go through the VPN, I have to disable and enable profile, which will cause connection lost in my first streaming app. The reconnection in that streaming app is up to the app itself: it could be quick or could be not. What I'm doing now, is: Assigning the new app rules array to the appRules member of the tunnel provider Calling saveToPreferences for this tunnel provider In the completion callback of saveToPreferences, I'm calling stopTunnel, and then startTunnel. This works, but it causes pure behavior I described with streaming apps. If I remove the step 3 - only the traffic of the first app will be redirected to the tunnel. So, the questions I have are: Is it expected, that I have to perform disable-enable sequence to activate new app rules for my VPN tunnel? If (1) is true, are there any recommended ways to provide my users stable experience without disconnection in the scenario I've described? If (1) is false, how should I trigger the appRules update for inner VPN system?
1
0
468
Feb ’22
Multiple network extension in a pipeline
Hey! Currently I have a VPN application implemented using Network Extension PacketTunnelProvider, which works just fine. The big question I am curious in: could the one connect several Network Extensions into a pipeline, which would do complex tasks in a determined way? From my point of view, there are several smaller questions to answer the big one: Could I launch several network extensions in one time, or the system will disable the previous / prevent me from launch? Is the order of network traffic processing, between several network extensions running on a mac, determined in any way or it is not? If the order is determined, what exactly it will be? The first launched gets the traffic first, second gets second, ...; or the last launched gets the traffic first, ...? Is there a difference in the processing order for different Network Extension classes (like, first PacketTunnelProvider will process the traffic only after the last Content filter provider finished its processing, or smth like that)? Maybe I've missed some important points or simple answers. It would be very helpful if these could be described here or in documentation.
3
0
1.3k
Apr ’22
Multiple network extension unexpected behaviour
Hey! Some time ago I've asked about the pipelining of network extensions, and it appears that it is possible: https://developer.apple.com/forums/thread/705292 It seems from previous thread, that Network Extensions should receive the traffic in the order they activated. There also mentioned, that the processing order should not depend on the type of the network extensions activated. However, that is not what I see in my experiments. I have two network extensions: one transparent proxy provider, one packet tunnel provider, configured in a per-app manner. While the Transparent proxy is the only one active network extension, I can see the traffic from the apps going through its methods. This changes once I activate second network extension. The transparent proxy is activated first, the packet tunnel is activated second. What I see then: the traffic from the app, configured in the profile for the second network extension (which is packet tunnel provider) is completely missed from the Transparent proxy network extension. It seems, that packet tunnel intercepts the traffic earlier than it appears in the transparent proxy, and does not give it back to transparent proxy after processing. What I expect, basing on a previous thread, is the traffic should appear in transparent proxy, then in packet tunnel provider. I also expect the traffic in packet tunnel provider to looks like originated from the transparent proxy, not the real origin app - which is OK for me now. So, my questions are: Why the packet tunnel provider "steals" the traffic from the transparent proxy, despite transparent proxy was registered first? Is this an expected behaviour I described? Could I, by any chances, create a pipeline from these two kinds of network extensions, to point the traffic from the app firstly in transparent proxy, then in packet tunnel? If (3) is true, what changes should I perform to achieve that?
6
0
1.1k
Aug ’22