Using Z 17.3, suddenly there is no connection to Internet. I have tried ton of things while talking to AI:
I suspect the issue stems from applying privacy.sexy yesterday, or with some system update. I have tried using multiple Timeshift restore points with absolutely no effect.
Even pinging localhost won't work.
Tried multiple routers which surely work.
The system works fine except there is no route to Internet. Other than applying privacy.sexy standard settings (which doesn't seem anything special) and if I remember correctly some usual system update, there haven't been any changes. Even it if it were, Timeshift should solve that.
Accidentally, I have opened the Firewall configuration. Although I have set it to enabled, it was somehow disabled. As soon as I enabled it back, the Internet access returned.
So does someone here have some viable explanation what happened here?
I just wasted few hours of unsuccessful troubleshooting (not counting this last part which was, totally unexpectedly, successful).
Upon further investigation, I have found out that the second firewall was active (firewalld or something). Once that was disabled and removed, and the usual firewall activated, the connection retrieved to normality.
Furthermore, I've given the exact script privacy.sexy applied to system (using Standard option which shouldn't break anything). The Gemini found out following:
Okay, thank you so much for providing the actual script! Having the full contents of the privacy.sexy script is incredibly helpful for understanding what might have happened.
I've reviewed the script, and while it's quite extensive, I can pinpoint some sections that are highly likely to have contributed to the network/firewall issues you experienced:
1. Firewall Modifications (ufw and potentially iptables):
- The script includes sections that directly manipulate
ufw rules. For example, it sets default policies and adds specific rules. While these are generally aimed at enhancing security, they might have introduced conflicts or overly restrictive settings.
- Even though you saw
ufw as disabled, the script might have still left residual iptables rules that were blocking traffic. Enabling ufw could have then reset or overridden those rules, restoring connectivity.
- The script's handling of
ufw might have also interfered with its ability to save its state correctly, leading to the need to re-enable it on every boot.
2. DNS Configuration Changes:
- The script contains various modifications related to DNS, including changes to
/etc/resolv.conf, potentially influencing systemd-resolved, and even suggesting the use of DNS over HTTPS.
- While we tried to correct
resolv.conf, the script might have altered other DNS-related system settings, causing the "temporary failure in name resolution" errors.
3. Systemd Service Changes:
- The script disables or masks various systemd services. It's possible that some of these services were indirectly related to networking or were required for NetworkManager to function correctly. While we tried to ensure NetworkManager was running, other dependent services might have been affected.
Specific Examples from the Script:
ufw commands: The script uses ufw default deny incoming, ufw default allow outgoing, and adds several ufw allow rules for specific ports. While these are common security practices, they could have been misconfigured or conflicted with existing rules.- DNS changes: The script modifies
/etc/resolv.conf and suggests installing curl and enabling DNS over HTTPS, which can sometimes introduce complexities in DNS resolution.
- Systemd service management: The script disables services like
avahi-daemon, which, while often related to network discovery, could have had unintended consequences on NetworkManager's behavior.
Why Reverting Didn't Always Work:
- Complex Interactions: The script makes numerous changes that interact with each other. Simply reverting individual changes might not be enough if other related settings are still in a conflicting state.
- Persistent Configuration: Some changes might persist even after a Timeshift restore if they affect user-specific configurations or system files that are not fully reverted.
- Service States: Even if the configuration files are restored, the services themselves might still be in a disabled or misconfigured state, requiring manual intervention.
In conclusion:
The script's comprehensive approach to privacy enhancement, while well-intentioned, likely introduced a complex web of changes that affected various aspects of your system's networking configuration. The conflict between ufw and firewalld was the most prominent symptom, but other DNS and service-related modifications also contributed to the overall problem.
I hope this analysis provides a clearer picture of what might have happened. It reinforces the importance of carefully reviewing and understanding the potential impact of any script that makes broad system-level changes.
1 Like