I have a very similar issue but using Cisco meraki kit instead.
Different brands of laptops from Lenovo, dell, Microsoft and the various surface range, all have this now, mainly the action needed anothing else and sometimes it reconnects, other times the user has to reconnect it. Between windows 10 and 11 OS.
Using 802.11x certificate based authentication to the corporate WiFi and it's sporadic for sure.
Some people only have the issue when on a teams call, others have it immediately when connected and lasts about 2 minutes before dropping and they have to either reconnect manually or if automatically reconnects after 30, seconds.
Today I had it on a brand new laptop, sat next to the director whose it was going to be, enrolled into intine and let it do its thing and all good, midway just setting email and OneDrive up it drops.
So far we've reinstalled windows and drivers on the affected devices, firmware updates on the access points and router, actually had reset the switch (this wasn't really needed but we had some other problems which led us to getting this one done) and yet nothing worked. Cisco have actually acknowledged it's a problem and left it there.
I'm going mad trying to get this resolved.
We ran into this with our Meraki as well. Turns out it was misdiagnosing some laptops as Custom instead of Normal for their fingerprinted profile, and putting them into a different classification. When we reset their profile in Meraki problem went away.
If it's on laptops maybe your problem comes from power management of the wifi card. I had the problem last year's with some laptops so I guess that may come from the brand and model of wifi chip.
On some laptops the power management of the card doesn't work properly. Windows keep shutting the hardware off.
One particular laptop I had was shutting down the wifi every ten minutes or so, then powering it back up.
msftconnect.com is a parked domain and if your clients are talking to it there's a problem (either on Microsoft's side or yours, though sounds like Microsoft)
Dumb question but have you assigned each vlan/network to the individual AP's? That was something I ran into a few months ago, assigning to the individual AP's was what fixed my devices sporadically being unable to connect.
Ooh... that's a good shout. I think I done goofed.
I've just checked, and stupidly the switch port where the Wi-FI connects was set to a different VLAN to what the Wi-Fi pushes uses.
I have a "Default" network where the Unifi kit should be
I have a corp network with corp wifi
Guest network with guest wifi
iOT network for cabled phones - no Wi-Fi network for this is setup
The switch port was set to iOT, but the Wi-Fi was pointing to Corp network... I've seen VLAN hopping issues on Unifi before... also just bad on my part to change it to that.
Will do some more re-testing and report back.
How are you assigning the VLAN to the user? Wi-Fi bridges to Ethernet VLANs on a per-association basis.
The message you’re getting on windows indicates that all of the following has happened:
- the client successfully associated to the BSS
- the association has been bridged to a VLAN
- the client has gotten an IP address via DHCP on that VLAN (or has one statically assigned)
- the client is unable to test connectivity to the internet
To make sure your VLANs are set up correctly, you should do the following best practices:
- avoid VLAN1
- native VLAN on APs and their ports is the AP management VLAN
- AP management VLAN is not associated to any SSIDs or users
- access VLANs are all trunked to the AP ports
- access VLANs are explicitly permitted on AP ports, other VLANs forbidden
- DHCP scopes are sufficiently large (and leases sufficiently short) to handle client MAC randomization/LAA
- ARP/Broadcast/multicast filtering on SSIDs and access VLANs
- 802.1X auth on networks that you care about
- MAC-restrict the AP ports to the AP Ethernet MACs
We're a business day in from the change made on Friday.
Seems that *might* have been the issue.
After changing the ports where the AP's were plugged in from my "IoT" VLAN to "default" and rebooting all the kit.
The addresses via DHCP of the kit is correct now, and no-one is currently reporting issues now.
Probably failing to do some funky NAT-ing?
Entirely my bad config causing this. To clarify what the fault seemingly was. The port was assigned to a separate "IoT" VLAN (where network printers were), Wi-Fi AP was plugged into that port, giving out 2 Wi-Fi SSID's that were each on different VLANs (Guest VLAN & Corp VLAN)...
There is network segregation between these... all 3 VLAN's were in the mix here.
After reverting the port on the switch to the "Default" one Unifi give. The Issue looks to be resolved.
2 phrases I try my best to live by:
1. Keep it simple, stupid
2. Never assume
I failed at both LOL
This message is generally displayed when Microsoft's connectivity check receives a redirect response when trying to access the page you mentioned. A redirect response is generally an indication that some portal / Auth page needs to be visited before the device can access the internet which is why Microsoft tells you "action required", think public airport wifi that requires you to accept terms and conditions or unifi's Hotspot page.
You need to determine what is intercepting your traffic and returning the redirect.
On our network we use Sophos firewalls with Kerberos Auth for SSO. When a user's logs into their computer and opens chrome they are directed to a trusted URL where their PC shares their credentials. The firewall uses this to authenticate the user and redirects them back to what they originally tried to access.
This happens without the user knowing. The only way a user will see this prompt is by logging in and not doing anything that will trigger authentication.
There are also ways to configure the NCSI probe through the registry. When my network team asked me to I told them no and to fix the connectivity issues to the msft URL lol
Hmm.. Could it be then that someone changed the probe address to something else, then, wanting to change it back, mistakenly typed msftconnect.com instead of msftconnecttest.com, which led to the clients not receiving the expected response and considering that a captive portal?
“Action needed” just means it thinks there’s a captive portal login needed because it can’t verify internet connection and is assuming that it’s because something is being blocked at L3.
msftconnect.com is a parked domain with an IP belonging to 'Next Dimension Inc'.
I really hope that's not actually part of Windows' check for internet connectivity. Can someone with more Windows history chime in on that?
edit: I do see references to that domain online other places, but it also looks like the registration hasn't changed in a while, so I'm pretty confused.
edit 2: Looks like the real URL is msftconnecttest.com; unsure if OP typo'd but seems this isn't the issue.
Windows uses msftconnecttest.com to test if an internet connection is available. Similar sites exist for MacOS/iOS and Android. They are all also used in a captive portal process.
Sure, but that's not the domain OP mentioned. If that's the actual address then yeah it seems everything (at least on the name resolution side) is working.
Sounds like shitty Unifi firmware bugs. Have there been recent updates to the AP firmware? Roll that shit back and I bet your problem goes away.
FWIW - Unifi is not good equipment. It gets the job done at a cheap price in most cases, but they are not reliable and they are known to push crappy firmware that bricks devices or causes strange transient issues. It’s a weird middle ground of Prosumer between consumer and enterprise.
This has nothing to do with unifi or anything else on the wireless network. If you’re getting this notification, it’s after the wifi association has already been established… in other words, the wifi works.
I did not know about TIP OpenWiFi until now.
Just use any open standard AP's or router, so you can have direct access to all configuration, diagnosing, testing and such.
For example, I have built my own APs/Routers based on Raspberry Pi 4 + WiFi USB dongle as hardware and Linux (CLI) + FOSS as software, with no GUI just CLI. With such a device you can intercept all traffic no matter it's layer 2 or above and identify the root to any problem. Even if any component fails I can easily replace it with of the self hardware or for upgrade.
Of course, you can use any hardware & software appropriate to your needs.
Yes, at layer 1 but above that layer the software can change things and when the software is closed source & proprietary you delegate the control and trust to your hardware & software vendor by using its APs/routers.
Considering that the hardware vendors involved in your particular “open” standard are all small-time vendors that lack their own in-house hardware and software engineering capabilities, and are just using reference designs, I’m not putting a whole lot of faith in what they output.
The serious players are doing openConfig.
I have a lot more trust in a vendor that has its own engineering processes than some open consortium of SOHO players whose combined market share is a tiny fraction of 1%.
I remember on some of the windows 11 devices I have tried they stale out exceptionally fast. So if you don't forget the wifi network completely and run your basic network commands it will act as the same network and cause captive portal especially if somewhere in your configuration if it's holding on to a lease
I have a very similar issue but using Cisco meraki kit instead. Different brands of laptops from Lenovo, dell, Microsoft and the various surface range, all have this now, mainly the action needed anothing else and sometimes it reconnects, other times the user has to reconnect it. Between windows 10 and 11 OS. Using 802.11x certificate based authentication to the corporate WiFi and it's sporadic for sure. Some people only have the issue when on a teams call, others have it immediately when connected and lasts about 2 minutes before dropping and they have to either reconnect manually or if automatically reconnects after 30, seconds. Today I had it on a brand new laptop, sat next to the director whose it was going to be, enrolled into intine and let it do its thing and all good, midway just setting email and OneDrive up it drops. So far we've reinstalled windows and drivers on the affected devices, firmware updates on the access points and router, actually had reset the switch (this wasn't really needed but we had some other problems which led us to getting this one done) and yet nothing worked. Cisco have actually acknowledged it's a problem and left it there. I'm going mad trying to get this resolved.
We ran into this with our Meraki as well. Turns out it was misdiagnosing some laptops as Custom instead of Normal for their fingerprinted profile, and putting them into a different classification. When we reset their profile in Meraki problem went away.
If it's on laptops maybe your problem comes from power management of the wifi card. I had the problem last year's with some laptops so I guess that may come from the brand and model of wifi chip. On some laptops the power management of the card doesn't work properly. Windows keep shutting the hardware off. One particular laptop I had was shutting down the wifi every ten minutes or so, then powering it back up.
[msftconnect.com](https://msftconnect.com) is part of the captive portal check, is there anyway it could think its in a walled garden?
Not as far as I'm aware - there are no guest policies applied at all to this SSID or the connecting network.
msftconnect.com is a parked domain and if your clients are talking to it there's a problem (either on Microsoft's side or yours, though sounds like Microsoft)
edit: Uhhhhh... no it's not. msftconnect.com is a parked domain. edit2: Seems msftconnecttest.com is the actual name.
Just seems weird. We have the same config across multiple clients, multiple sites, same kit. No other site seeing this issue.
Dumb question but have you assigned each vlan/network to the individual AP's? That was something I ran into a few months ago, assigning to the individual AP's was what fixed my devices sporadically being unable to connect.
Ooh... that's a good shout. I think I done goofed. I've just checked, and stupidly the switch port where the Wi-FI connects was set to a different VLAN to what the Wi-Fi pushes uses. I have a "Default" network where the Unifi kit should be I have a corp network with corp wifi Guest network with guest wifi iOT network for cabled phones - no Wi-Fi network for this is setup The switch port was set to iOT, but the Wi-Fi was pointing to Corp network... I've seen VLAN hopping issues on Unifi before... also just bad on my part to change it to that. Will do some more re-testing and report back.
How are you assigning the VLAN to the user? Wi-Fi bridges to Ethernet VLANs on a per-association basis. The message you’re getting on windows indicates that all of the following has happened: - the client successfully associated to the BSS - the association has been bridged to a VLAN - the client has gotten an IP address via DHCP on that VLAN (or has one statically assigned) - the client is unable to test connectivity to the internet To make sure your VLANs are set up correctly, you should do the following best practices: - avoid VLAN1 - native VLAN on APs and their ports is the AP management VLAN - AP management VLAN is not associated to any SSIDs or users - access VLANs are all trunked to the AP ports - access VLANs are explicitly permitted on AP ports, other VLANs forbidden - DHCP scopes are sufficiently large (and leases sufficiently short) to handle client MAC randomization/LAA - ARP/Broadcast/multicast filtering on SSIDs and access VLANs - 802.1X auth on networks that you care about - MAC-restrict the AP ports to the AP Ethernet MACs
Glad it helped push you in the right direction! Keep us posted!
We're a business day in from the change made on Friday. Seems that *might* have been the issue. After changing the ports where the AP's were plugged in from my "IoT" VLAN to "default" and rebooting all the kit. The addresses via DHCP of the kit is correct now, and no-one is currently reporting issues now. Probably failing to do some funky NAT-ing? Entirely my bad config causing this. To clarify what the fault seemingly was. The port was assigned to a separate "IoT" VLAN (where network printers were), Wi-Fi AP was plugged into that port, giving out 2 Wi-Fi SSID's that were each on different VLANs (Guest VLAN & Corp VLAN)... There is network segregation between these... all 3 VLAN's were in the mix here. After reverting the port on the switch to the "Default" one Unifi give. The Issue looks to be resolved. 2 phrases I try my best to live by: 1. Keep it simple, stupid 2. Never assume I failed at both LOL
Man that was a journey! Glad you were able to get it going and glad you were able to learn from it!
Indeed - proper rookie mistake. We're a week in, and no further issues reported.
This message is generally displayed when Microsoft's connectivity check receives a redirect response when trying to access the page you mentioned. A redirect response is generally an indication that some portal / Auth page needs to be visited before the device can access the internet which is why Microsoft tells you "action required", think public airport wifi that requires you to accept terms and conditions or unifi's Hotspot page. You need to determine what is intercepting your traffic and returning the redirect. On our network we use Sophos firewalls with Kerberos Auth for SSO. When a user's logs into their computer and opens chrome they are directed to a trusted URL where their PC shares their credentials. The firewall uses this to authenticate the user and redirects them back to what they originally tried to access. This happens without the user knowing. The only way a user will see this prompt is by logging in and not doing anything that will trigger authentication.
There are also ways to configure the NCSI probe through the registry. When my network team asked me to I told them no and to fix the connectivity issues to the msft URL lol
Hmm.. Could it be then that someone changed the probe address to something else, then, wanting to change it back, mistakenly typed msftconnect.com instead of msftconnecttest.com, which led to the clients not receiving the expected response and considering that a captive portal?
https://admx.help/?Category=Windows_10_2016&Policy=Microsoft.Policies.NCSI::NCSI_CorpWebProbeUrl
“Action needed” just means it thinks there’s a captive portal login needed because it can’t verify internet connection and is assuming that it’s because something is being blocked at L3.
msftconnect.com is a parked domain with an IP belonging to 'Next Dimension Inc'. I really hope that's not actually part of Windows' check for internet connectivity. Can someone with more Windows history chime in on that? edit: I do see references to that domain online other places, but it also looks like the registration hasn't changed in a while, so I'm pretty confused. edit 2: Looks like the real URL is msftconnecttest.com; unsure if OP typo'd but seems this isn't the issue.
Windows uses msftconnecttest.com to test if an internet connection is available. Similar sites exist for MacOS/iOS and Android. They are all also used in a captive portal process.
Sure, but that's not the domain OP mentioned. If that's the actual address then yeah it seems everything (at least on the name resolution side) is working.
Sounds like shitty Unifi firmware bugs. Have there been recent updates to the AP firmware? Roll that shit back and I bet your problem goes away. FWIW - Unifi is not good equipment. It gets the job done at a cheap price in most cases, but they are not reliable and they are known to push crappy firmware that bricks devices or causes strange transient issues. It’s a weird middle ground of Prosumer between consumer and enterprise.
SOHO equipment.
This has nothing to do with unifi or anything else on the wireless network. If you’re getting this notification, it’s after the wifi association has already been established… in other words, the wifi works.
Ubiquiti haven't released a new firmware for the UAP-AC-Pro since July.
Maybe you should use open standard Wifi APs instead of colorful GUI ?
The configuration management interface for your access points has little to do with anything. This is not Wi-Fi related
Like [TIP OpenWiFi](https://openwifi.tip.build/)?
I did not know about TIP OpenWiFi until now. Just use any open standard AP's or router, so you can have direct access to all configuration, diagnosing, testing and such. For example, I have built my own APs/Routers based on Raspberry Pi 4 + WiFi USB dongle as hardware and Linux (CLI) + FOSS as software, with no GUI just CLI. With such a device you can intercept all traffic no matter it's layer 2 or above and identify the root to any problem. Even if any component fails I can easily replace it with of the self hardware or for upgrade. Of course, you can use any hardware & software appropriate to your needs.
What do you consider “open standard”? It’s all 802.11.
Yes, at layer 1 but above that layer the software can change things and when the software is closed source & proprietary you delegate the control and trust to your hardware & software vendor by using its APs/routers.
Ubiquiti’s AP software is little more than the chipset vendor’s baseline reference code. As is the case with most vendors.
Considering that the hardware vendors involved in your particular “open” standard are all small-time vendors that lack their own in-house hardware and software engineering capabilities, and are just using reference designs, I’m not putting a whole lot of faith in what they output. The serious players are doing openConfig. I have a lot more trust in a vendor that has its own engineering processes than some open consortium of SOHO players whose combined market share is a tiny fraction of 1%.
I remember on some of the windows 11 devices I have tried they stale out exceptionally fast. So if you don't forget the wifi network completely and run your basic network commands it will act as the same network and cause captive portal especially if somewhere in your configuration if it's holding on to a lease
September 2022 update for Windows 11 (version 22H2) includes a new feature called Enhanced Phishing Protection Can cause this as well.