Perfectly, this is exactly the test scenario, but as I thought I had done something wrong, I went to return the server (it was with me to repair restarts), but there on the other unit, after connecting, no Nextcloud client synchronized again, and I can’t ping 192.168.0.250, it seems that there is something wrong with the Nethserver network configuration, I would like to know how to correct it from the prompt without having to redo the server, as there is a lot of data on nextcloud
And welcome! Glad you are here.
2 Likes
We’re using Discourse 
I hope you enjoy the aesthetic very soon
1 Like
Check the logs. It is possible for /var/log/messages (and journalctl) to have some information on the problem(s).
Other checks you can do on NethServer:
ip a
db networks show
ping -c4 192.168.0.1
ping -c4 8.8.8.8
config show dns
grep 'server=' /etc/dnsmasq.conf
# check for failed services (`httpd-admin` must be running for the UI to work)
systemctl status -l httpd-admin
systemctl list-units --failed
1 Like
The two commands generated absurdly large logs, the last ones have some red ones dated in month 10, but the problem actually occurred on 06/11 being a PC power problem
My mistake when typing IP, it was 252, 250 is my VM, but I had tested the right IP before, I just made a mistake when typing
Temporarily disable firewall…
shorewall clear
…and try again.
journalctl manual tells some ways to filter results.
You can also grep logs for error / warn / fail …for instance.
1 Like
Buddy, it worked, thank you very much, I can access and ping the server
But, there is still one detail, when rebooting, it becomes inaccessible again, I think the service restarts itself, is it possible to leave this service permanently disabled?
Better to identify and tweak the firewall rules that are preventing your access.
There you have the documentation:
https://docs.nethserver.org/en/v7/firewall.html
https://docs.nethserver.org/projects/nethserver-devel/en/latest/nethserver-firewall-base.html
It’s interesting material, I’ll use it to insert correct rules, but it’s quite dense, in the short term I need to permanently cancel the firewall, it’s a requested server and I need to return it to access the data as soon as possible, I’m reading your link but for now I haven’t found where to keep it disabled
The firewall rules can be easily managed from the user interface when the firewall module is installed on NethServer.
Also from the command line:
db fwrules show
The firewall is a core part of nethserver (for instance to control access to network zones) and should not be disabled in production.
Shorewall is used to configure netfilter/iptables.
This command did not print any messages, both before and after the shorewall
I checked firewalld, it starts inactive, however the shorewall starts active, I found a way to disable just the firewall permanently, but if firewalld starts inactive there is no reason to disable it, but I can’t find how to keep the shorewall inactive
I’m reading, I found a lot of commands, but I understand shorewall as a supporting part of the firewall, but since firewalld is inactive, I don’t understand why I can only access it after doing shorewall clear, but what I really need is to run this every time I restart
Master, one of the links doesn’t mention shorewall, the other link I read more about it, but I don’t see any mention of how to keep the shorewall clean when restarting
In the Nethserver browser, in services the shorewall is running, but in the prompt the firewalld is inactive, something happens when restarting that shields internet access, when I apply shorewall clear, in the Nethserver it indicates a yellow bar “Check firewall rules, firewall not running” , creates a link and when clicked it says: Nethgui 404 not found
I created a script, but I wasn’t happy, it runs but doesn’t apply, it only applies if I run it manually at the prompt
Hi @SimPos
Sounds like you didn’t use the full path to binaries in your script…
→ On the local console, your user / root benefits from having the correct environment set, including paths. Scripts run eg by cron, do NOT have any environment set, therefore full paths are needed!
Example:
A simple shutdown script wih poweroff won’t work
The same script with /usr/sbin/poweroff will work!
→ Always use full paths in your scripts, then they will work anywhere, in all environments…
(Permissions are a different issue!)
My 2 cents
Andy
I put the script in /etc/systemd/system, at least the status indicates it works, but what would be the full path to “shorewall clear?”
which shorewall
is your friend…
I’m (maybe wrongly) assuming your server does not have fail2ban or IPS modules installed, which could block connections.
At the moment your connection from the other computer is dropped/rejected, the last lines of /var/log/firewall.log might show you a hint of the cause. A more verbose version can be obtained with shorewall dump, as it will dump a large list with the firewall configuration being applied. shorewall show can display useful info too.
I’m confused because I don’t know when it’s a command argument or conversation, but to be more practical, my .sh contains “shorewall clear”, but it’s complicated
I did these commands without shorewall clear, so I don’t know if the result is different with shorewall clear
I don’t understand how everything before the power outage worked with a firewall and without this shorewall
I’m taking another route, running through crontab, but I think I’m making a mistake, if you can help
As I said, I set up the script.sh with shorewall clear, it works if I run it directly, after running it I can see the log, and I see the Nethserver with firewall notified
I inserted the script.sh in contrab -e:
@reboot /root/script.sh
It didn’t work, I thought it would run as soon as I restarted, I tried with * * * * * but it didn’t work either, the friend said he needed the entire path, but I don’t know how to do it and how to create the correct parameter
sme kernel: Shorewall:INPUT:REJECT:IN=ens2 OUT=…
(FAQ 17) Why are these packets being Dropped/Rejected? How do I decode Shorewall log messages?
(…)
INPUT or FORWARDThe packet has a source IP address that isn’t in any of your defined zones (“shorewall[-lite] show zones” and look at the printed zone definitions) (…)
some of the photos (with incomplete information) show rules for a wireless interface but no mention of ens2.