Desktop says limited connectivity despite working access · Linux Fix Lab

Symptoms & scope

The desktop shows limited, portal or no Internet although some intended services work.
The indicator changes between links or after a VPN, firewall or captive-portal policy change.

Relevant environment

NetworkManager installations with a configured connectivity-check URI; a disabled or unset check cannot establish global Internet availability.

Possible causes

These are possible explanations, not a confirmed diagnosis. Several independent faults can coexist.

The specific probe endpoint can be unreachable, filtered or redirected while other application traffic remains usable.
A real captive portal, restricted network or strict reverse-path filtering on a multi-interface host can affect the probe; the indicator alone cannot distinguish them.

Diagnose safely

Run one command at a time in the relevant session. Read the explanation first. Uppercase placeholders need your own values; tools and privileges vary by distribution. These commands are displayed here and never executed by the website.

Check 1

Read the cached NetworkManager connectivity state. Do not append check: that would request a fresh network probe rather than simply reading the state.

nmcli networking connectivity

Interpret the result: Full, limited, portal, none and unknown describe the manager’s check result. Limited is not proof that every destination or application is unreachable.

Check 2

Print the effective daemon configuration without starting a daemon. Administrator privileges may be needed for protected files; inspect only the connectivity section for this diagnosis.

NetworkManager --print-config

Interpret the result: A valid URI and nonzero interval enable the optional check. Compare its expected response with local filtering; unsuccessful per-link checks can also incur a route-metric penalty.

Check 3

Replace IFACE with the affected physical or VPN interface. Read its live connection and routes without changing route metrics or requesting another check.

nmcli -f GENERAL,IP4,IP6 device show IFACE

Interpret the result: Compare the chosen default paths with the working application’s destination. A probe warning and incorrect routing can coexist; neither should be dismissed solely because one website opens.

Evidence-guided next steps

Repair the intended probe or portal path

If the network is supposed to allow the configured probe, have its administrator correct that endpoint’s DNS, filtering or expected response after confirming the rest of the path. If a genuine captive portal is confirmed, complete the network’s normal authorized sign-in and then reassess both indicator and application access.

Precautions: Verify the portal belongs to the intended network before submitting information. Do not treat a successful probe as a guarantee that all services work or disable unrelated firewall rules.

Recovery / rollback: Restore the saved probe-related filter/configuration if routing or access worsens; leave the portal session through its documented sign-out or disconnect procedure.

Did this solution help you?

Share this solution #

Configure an intentional restricted network

If this network intentionally has no public Internet or blocks the external probe, configure a policy-approved reachable connectivity endpoint with the required response, or set the documented check interval to zero if the indicator is not useful. Compare route selection as well as the warning afterward.

Precautions: Save the current connectivity section. Disabling the check removes an optional availability signal and can alter connectivity-based metric handling; it does not repair actual DNS or routing faults.

Recovery / rollback: Restore the saved URI, interval and response settings, reload the daemon configuration using the supported procedure, and verify the original route behavior returns.