Looking for an explanation on what the "Juniper Network Service" NDIS filter actually does, and what downsides exist in disabling it on network adapters.
As I am having issues with this service and certain WiFi NIC's, I am evaluating how I want to globally address the issue. There are a number of steps provided in this article: https://kb.pulsesecure.net/articles/Pulse_Secure_Article/KB43833
I have been disabling RSC via PowerShell as my initial remediation, but this article now provides a way to disable Juniper Network Service via a custom config on PCS 9.1R1 or newer when using the soon to be released Desktop Client 9.1R5. This is a rather attractive way to address this issue without having to remediate at a client level via other methods.
However, as this will disable the Juniper Network Service NDIS filter on ALL devices, and I'm only having the issue on select devices, I want to know of potential downsides of this NDIS filter being disabled globally.
@HDClown The Juniper Network Service is needed when Pulse is first installed to allow communication between Pulse drivers and drivers on the PC. To do this, it binds itself to the network adapter. After installation, however, it is no longer needed, with the exception of Pulse tunnels that are open on a Juniper SRX device, rather than a PCS. Hence, disabling it does not cause any negative impact. on any workstations as long as they are connecting to Pulse Connect Secure devices.
r@yElr3y We install Pulse by logging into the PCS web portal and clicking on "Start" for Pulse Secure. If we use the advanced client config method in the article I linked, will this installtion method be impacted, or will it continue to work fine?
Is there situation where using this method to globally disable Juniper Network Service across all of our devices could come back to bite us? Such as some future version upgrade of the Puse Desktop Client, PCS, Windows 10 feature uprade, etc? Or is the use of that service literally a one-and-done situation and it's been that way "forever" ?
@HDClown Installation through the web portal should not be affected by this Adv. client config push, as they are distinct in nature. From my experience, I've never heard any complian from any of my existing customers w.r.t any potential downside or backfire situations from their user base after disabling the JNS network binding.
Honestly, I don't have an answer for that service literally a one-and-done situation and it's been that way "forever" ? But logically thinking, it seems to be the case.