Posts

Post not yet marked as solved
8 Replies
1k Views
I have been implementing a NEFilterPacketProvider to be used as part of a system extension and running into a problem that I find highly bewildering. The packet handler function just never gets called for one of my VMs while it gets called just fine in another VM. They both have the exact same MDM profile installed that pre-authorizes the activation of the sysx and network filters. I have looked at every instance of this problem online and tried every single one of the tips I've read. I've made sure to set filterPacket = true. I ensured that my NEFilterPacketProvider is getting initialized and startFilter() gets called. I ensured that I am calling the completionHandler in startFilter. I ensured there are proper entitlements. I have tried implementations in both Swift and Objective-C. Nothing seems to make a difference. The data provider gets called reliably and consistently. Since this is working just fine in one of my VMs, I am quite confident the code is correct. My question is this: what are some tips to systematically debug this issue? If you were me, where would you start looking at this? Are there some command line tools that I can use to inspect the state of the network extension or macOS's state regarding them? scutil --nc list doesn't show anything (I assume because NEFilterPacketProvider isn't a proxy). What are some other commands I can use to really poke at network extensions? I've looked at Console logs for sysextd and neagent and nothing stands out as an explanation. I would love to know why the packet handler isn't getting called!
Posted
by kn-cs.
Last updated
.
Post not yet marked as solved
1 Replies
386 Views
While testing NEFilterDataProvider, I observed that IGMP traffic is not seen in it. Perhaps someone can show me where my testing is wrong and provide a better methodology to create IGMP traffic. I am using iperf found in Homebrew. I am using iperf as follows: I execute the client/consumer iperf on the VM where the NEFilterDataProvider is active and running: iperf -s -u -B 224.1.1.1 -i 1 I then execute on another machine the server/producer side of things: iperf -c 224.1.1.1 -u -T 32 -t 3 -i 1. This works correctly as both sides receive the data and everything seems to be good. However, I don't see any IGMP traffic on the NEFilterDataProvider. When I create a raw socket with python and send traffic marked as IGMP, that gets seen by NEFilterDataProvider. Is this expected where the kernel handle IGMP messages which don't get bubbled up to usermode through a NetworkExtension? Am I not actually testing the right thing to see IGMP traffic in NEFilterDataProvider? By the way, I am not sure if NEFilterPacketProvider would see this—I just haven't had a chance to try it since packet provider is not working in my Parallels VM.
Posted
by kn-cs.
Last updated
.
Post not yet marked as solved
1 Replies
486 Views
So I understand that the binary implementing NEFilter[Data|Packet]Provider classes cannot block itself or loopback in order to prevent the system potentially becoming unresponsive. What else is not allowed to be blocked? I'm talking about Big Sur 11.2 onwards where the "Apple whitelist" was removed. I'm wondering specifically if things like DHCP, NTP, DNS, and ARP are not allowed to be blocked. Is there a list that is documented somewhere? If we want to create a list of rules that we want to create in order to allow these services, is there documentation as to what the binary paths, ports used, etc are?
Posted
by kn-cs.
Last updated
.
Post not yet marked as solved
1 Replies
631 Views
I have an active connection with my private VPN behind GlobalProtect. I know the connection is active because I can access resources that is only accessible through the VPN. However, when I run scutil --nc list, I get: Available network connection services in the current set (*=enabled): * (Disconnected) XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX VPN (com.paloaltonetworks.GlobalProtect.client) "GlobalProtect" [VPN:com.paloaltonetworks.GlobalProtect.client] Is there another command that would indicate that GlobalProtect is active?
Posted
by kn-cs.
Last updated
.
Post marked as solved
1 Replies
516 Views
It appears in my testing that NEFilterDataProvider consistently gets its handleNewFlow() called prior to NEFilterPacketProvider's packetHandler callback closure. Is this by design? Is it something we can assume to stay consistent from macOS version to version? Is there a way to request a different ordering? Is it related to the NetworkExtension.NEProviderClasses key in Info.plist for the SystemExtension/NetworkExtension? <key>NetworkExtension</key> <dict> <key>NEMachServiceName</key> <string>$(TeamIdentifierPrefix)com.X.Y.app-group.MySystemExtension</string> <key>NEProviderClasses</key> <dict> <key>com.apple.networkextension.filter-data</key> <string>$(PRODUCT_MODULE_NAME).FilterDataProvider</string> <key>com.apple.networkextension.filter-packet</key> <string>$(PRODUCT_MODULE_NAME).FilterPacketProvider</string> </dict> </dict> Is it based on the order of the modules listed in the info.plist? I actually want the order macOS is giving me now, and I want to make sure I can rely on this ordering.
Posted
by kn-cs.
Last updated
.
Post marked as solved
1 Replies
514 Views
It appears as that connections originating from the network extension itself is not picked up in that NEFilterDataProvider's handleNewFlow(). This behavior makes sense, but I don't find this behavior documented anywhere. Is this documented somewhere that I'm missing? Can this be confirmed as "working as intended"?
Posted
by kn-cs.
Last updated
.
Post not yet marked as solved
0 Replies
530 Views
I've been relying on reading /Library/Preferences/OpenDirectory/DynamicData/Active Directory/DOMAIN.plist to retrieve the site name information for a host bound to Active Directory. However, according to FB9063984, the DynamicData directory isn't always populated and there is no guarantee as to what information it will contain even when the files are present. Is there anywhere else the Site Name for a host can be retrieved?
Posted
by kn-cs.
Last updated
.