Found the fix for this. The sample testbed project for TransparentProxyProvider has synchronisation issue and is causing 'fatalError()' in 'extension Network.NWEndpoint', which causes crash of network extension.
Fix for this synchronisation is to pass 'SupportFlow' as async argument:
if (supportedFlow != nil) {
self.queue.async { **[supportedFlow] in**
if (shouldBlock == true) {
// TODO with proper handling of flow
os_log(.debug, log: self.log, "TransparentProxy Provider want to block this TCP flow, flow: 0x%zx", flow.osLogID)
let error = NSError(domain: "", code: 0, userInfo: [NSLocalizedDescriptionKey : "Connection Refused"])
flow.closeReadWithError(error)
flow.closeWriteWithError(error)
} else {
self.core.handleNewSupportedFlow(supportedFlow!, proxyServer!, proxyPort!)
}
}
os_log(.debug, log: self.log, "Provider did handle new flow, flow: 0x%zx", flow.osLogID)
return true
}
Post
Replies
Boosts
Views
Activity
Hi @meaton,
One more clarification:
Is my understanding correct for Apple's recommend approach, please correct me if I am wrong at any place:
PacketTunnelProvider class in NetworkExtension framework can be used to activate and configure the utun interface.
Now to define the network rules:
either use "NEPacketTunnelNetworkSettings, ipv4Settings" settings
or use "route add " command to route traffic on utun interface manually
Now for tunneling IP-Packets, read/write operation can be directly done on the utun interface either by an app/service inside or outside the App Group.
TIA
Thanks for your response Meaton. I understand what you are trying to explain. I will discuss the options and limitations internally with my team.
One more data if you can share, do you see possibility of removing 'utun' support from Apple, if yes, anytime lines? This data will be a critical input for us for discussion making.
Also as i read more, it seems tun driver is by default built-in in MacOS, so if we already have this driver installed why not use it to intercept layer 3 packets for tunneling. I want to understand what limitations it have?
Thanks for the response @meaton, I wanted to understand it further on how the manual route of creating utun interface and doing read/write can limit any functionalities.
I was going through openvpn code and seems they also have used manual method to create utun interface to read/write operation for tunneling L3 packets.
For me also it seems an easier way to use the utun method as it is easy to maintain the code avoiding the sandboxing and app groups and managing the inbound and outbound connections..
Feedback generated for this request:
https://feedbackassistant.apple.com/feedback/9779236
Thanks Owara for sharing the info. I will pass this information accordinly.
This is serious security concern as a user can disable Proxy client by using this option thus exposing mac machines and company resources to malicious access in internet.
I will raise the feedback/enhancement request for the same but will request to take it on priority.
Thanks for the response Quinn.
Thanks Quinn, I will probably raise a feedback for the development team if they can add some provision for outside process (container app) to be able to monitor the VPN status.
Meanwhile I will go with the 1st approach what you and Matt suggested.
Thanks
is your service visible to SCNetworkConnection?
I dont see my service where you suggested:
% networksetup -listallnetworkservices
An asterisk (*) denotes that a network service is disabled.
USB 10/100/1000 LAN
Thunderbolt Bridge
Wi-Fi
Bluetooth PAN
To get this working you need to start with a service ID. I’m not sure whether the system allocates a service ID for a transparent proxy.
Do I need to anything special while configuring my TransparentProxyProvider in my App, which will let the system allocate serviceID to my VPN?
Thanks Quinn, both the approach will work for me. But the 2nd approach is more suitable as it will be independent of the App (SysEx) which is doing 'addObserver' for VPN status.
I was trying to find a small example of code for:
SCNetworkConnection vpnConn = <?>
SCNetworkConnectionStatus status = SCNetworkConnectionGetStatus(vpnConn)
Could you please help me with API and arg which i can use to get 'SCNetworkConnection' in my C++ project?
Thanks Matt and Quinn for your response.
Is this other service signed by the same team as your sysex?
Yes both systemExtn and service is signed by same team.
And what context is it running in? As a daemon? Or in a GUI login context? Or something else?
It is a daemon, but build outside the systemexten container. I have a limitation that I cannot keep this daemon in same container.
I have related question, is there a way I could block/disable the 'Disconnect' button for the VPN in network settings? Current this can be disabled even without opening the lock (bottom).
Or Can we somehow disable the effect of the disconnect action, ie user cannot stop VPN from this place?
I’m going to recommend that you open a DTS tech support incident
Thanks Quinn. I already created a TSI for the same this morning (IST). Also given the reference for this discussion so that I may not need to explain again the things which we discussed here. Let me know if u need to know the follow-up/TSI number.
Next question: What are you hoping to gain by using an App Group? Which processes are you sharing content between? And what sort of content?
We have app and library which does IPC communication with System Extension to Install and configure, in similar way it was done in Apple sample project for 'SimpleFirewall'. I could see 'com.apple.security.application-group' used there as well.
But this 'app-group' entitlement as been working fine in Catallina (10.15) and Bigsur OS for Intel Mac machines. Why could it start failing in M1 macbooks? Also on some M1 machines it is working fine.