Issues when connecting to Wi-Fi

Hi @avdlaan, this sounds like something that our support team should take a look at. You can submit a ticket or give them a call at 1-866-254-8400.

Hi Anna,

We already have a ticket created for this with support, just wanted to gauge from the community whether others have had the same issue.

Great! Please share if you find out information that would help others too. Thanks!

We've been seeing the same issues. DNS-P version 1.3.1.20.
Here's a scenario:

• Take laptop (Win10) home. Connects to wifi. No problems. VPN to corporate network. No problems.
• Shut laptop down completely and bring it to work.
• Connect laptop to docking station at work (Ethernet connected). No problems.
• Open up Network Connections and look at the properties for my WiFi connection - it still lists my home network's DNS servers. It should be set to "Obtain DNS server address automatically".
• I undock the laptop and go on WiFi, it may or may not work. I've seen it retain the DNS servers from my home network. And I've seen it work correctly with 127.0.0.1. It's hit or miss.

Mind you, our users are NOT local admins and cannot correct network settings on their own.

I see a few of my endpoints have a newer version of the DNS-P agent, 1.3.3.35. The majority (95%) are still on 1.3.1.20. How does the update process work? Maybe this new version will do a better job of handling this?

Duke_Nukem wrote:

We've been seeing the same issues. DNS-P version 1.3.1.20.
Here's a scenario:

• Take laptop (Win10) home. Connects to wifi. No problems. VPN to corporate network. No problems.
• Shut laptop down completely and bring it to work.
• Connect laptop to docking station at work (Ethernet connected). No problems.
• Open up Network Connections and look at the properties for my WiFi connection - it still lists my home network's DNS servers. It should be set to "Obtain DNS server address automatically".
• I undock the laptop and go on WiFi, it may or may not work. I've seen it retain the DNS servers from my home network. And I've seen it work correctly with 127.0.0.1. It's hit or miss.

Mind you, our users are NOT local admins and cannot correct network settings on their own.

I see a few of my endpoints have a newer version of the DNS-P agent, 1.3.3.35. The majority (95%) are still on 1.3.1.20. How does the update process work? Maybe this new version will do a better job of handling this?

I've been noticing this on some of our installations as-well. Everything is fine, and suddenly the DNS settings get switched from "Obtain DNS server address automatically" to a manually defined loopback of 127.0.0.1.

Pretty frustrating. Most of the time when I switch it back to "Obtain automatically" -- minutes later it reverts back to 127.0.0.1.

I noticed stopping the DNS Protection Agent service stopped it from re-entering the 127.0.0.1.

I reached out to the product manager for DNS Protection, hope to have his response on this thread and we'll provide an update soon.

Hello @avdlaan

I can answer your question. That is caused due to MSFT trying to probe through their DNS and this is unfortunately a tricky/intermittent problem.

Cause:

Network Connectivity Status Indicator (NCSI) periodically makes active DNS probes to validate internet connectivity on each network interface.
These DNS checks are restricted and NCSI will refuse to send them to a DNS server on a different interface (such as 127.0.0.1) causing incompatibility with the Agent. This limitation does not cause any problem in the vast majority of environments, because Windows also performs other passive checks to validate connectivity.

Hello @btraill and @Duke_Nukem -

The issue that you are mentioning is not related to @avdlaan's . You are hitting a not so frequent scenario where intermittently it hits a deadlock in version 1.3.1.20. We have indeed addressed this in the new build 1.3.3.35 and 36 .. Could I recommend that you uninstall the DNS agent from that device and if the device is on the EP policy to install DNS then it'll install the new version. We are doing a phased rollout of the new agent to select customers. Alternatively, you may also send me a PM with your keycode and I can setup your keycodes to update to the latest agent.


Thanks much.
-Kiran

@kkumar


Understood, my apologies for hijacking this thread. The prompt responses are very much appreciated. (Thanks to @LLiddell too!)

I will send a PM containing our keycode.

btraill wrote:

@kkumar


Understood, my apologies for hijacking this thread. The prompt responses are very much appreciated. (Thanks to @LLiddell too!)

I will send a PM containing our keycode.

Absolutely! no worries at all .. I got your PM.

PM sent. Thanks for the explanation.

Mike

@kkumar - It's more than just an issue with the indicator, DNS isn't actually functioning.

We think we may have narrowed down one scenario where the issue is. One of the things I've noticed is that Webroot DNS requires custom ports to be opened. On networks where these ports aren't open, the client reverts back to it's originally set DNS. Let's say hypethetically the DNS was originally 10.0.0.1 when the agent was installed. That seems to be the DNS server it reverts back to whenever it can't communicate with the Webroot DNS servers.

If I take my laptop to another network/client/location, which is tightly locked down, and the agent can't talk to your servers, it then reverts back to the DNS server 10.0.0.1 even though the network I'm now on is a completely different network.

I noticed that Cisco Umbrella only uses ports 80 and 443. Is there any reason Webroot DNS can't do that? We can't expect custom ports to be open on every network we visit.

Unless I just don't know where to look, there doesn't seem to be great logging on this product.

Thoughts?

@avdlaan

Have you tried this? I was having an abundance of issues with no internet/intermittent issues with all of our PC's/Laptops using the DNS client. This group policy change seems to have fixed all of our problems with it.

It appears the issues all boiled back to a problem with the PC's not behaving correctly when the DNS settings are configured for the local loop back interface. From what I understand, this GP change enables/better facilitates handling DNS over the local loopback address. (127.0.0.1)

Note: You will need administrative rights.

Hit the Windows key on your keyboard, begin typing "Group Policy".

Select the following result:

Navigate through the GP tree as follows:

Computer Configuration
- Administrator Templates
-- Network
--- Network Connectivity Status Indicator

Change it from Not Configured (or Disabled) to Enabled.
Ensure the "Use global DNS" checkbox is also selected.

Apply and OK.

Reboot PC to ensure changes take effect.

@btraill - We actually worked with tech support and determined that our machines had legacy corrupted entries for NICs due to original versions of the DNS agent. We were given a script to clean these up and have not had issues since.

I would love to get the mentioned script. I put in a support ticket and it was immediately closed referencing the yellow triangle fix which is not the problem we are experiencing.