[Bug 1956029] Re: ufw remains inactive at boot time
Thanks for the response and glad you got it worked out. It reminds me that I would like to document using fail2ban with ufw more. ** Changed in: ufw (Ubuntu) Status: Incomplete => Invalid -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1956029 Title: ufw remains inactive at boot time To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/1956029/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1956029] Re: ufw remains inactive at boot time
Sorted out the issue. I've got systemd to also wait for ufw to load when starting fail2ban. Fail2ban issues a many iptables commands in rapid succession and then it's database of banned IPs is large it takes a considerable amount of time for the firewall to be initialised. In the meanwhile anything issuing iptables commands quite likely fail as is it not possible to have more than one instance of iptables active at any one time. ufw script completes its tasks quickly so makes sense to force that service to start before the fail2ban service. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1956029 Title: ufw remains inactive at boot time To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/1956029/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1956029] Re: ufw remains inactive at boot time
Right after reboot I tried to get the status. Result is . . . . root@loki:~# s ufw status ERROR: problem running iptables: Another app is currently holding the xtables lock. Perhaps you want to use the -w option? . . . . while fail2ban is setting up its rules. Anyway... After a reeboot, whatever I've done seems to have worked. I'm assuming adding "ufw.service" to fail2ban.service may have done the trick as has been mentioned on comment 4. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1956029 Title: ufw remains inactive at boot time To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/1956029/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1956029] Re: ufw remains inactive at boot time
By networking stops means that I can not establish a connection with the Lemaker BananaPi Pro on any port so I can't get a SSHed shell, can't access the VPN server, etc... It behaves like someone has plugged the network cable. Putting "ufw.service" was a guess, but I've not rebooted the OS yet with that in place. root@loki:~# iptables --version iptables v1.8.4 (legacy) root@loki:~# uname -a Linux loki 5.10.60-sunxi #21.08.2 SMP Tue Sep 14 16:28:44 UTC 2021 armv7l armv7l armv7l GNU/Linux root@loki:~# fail2ban-client --version Fail2Ban v0.11.1 OS in use obtained from here: https://www.armbian.com/banana-pi-pro/ I will try a reboot and see what happens. Will report result back here. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1956029 Title: ufw remains inactive at boot time To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/1956029/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1956029] Re: ufw remains inactive at boot time
Thanks for the bug report. A few things: 1. I'm not sure what 'networking stops' means precisely in the context of this bug report. Does 'ufw disable' restore the network? Is the network torn down? Something else (you are using a lot of limit rules instead of allow rules, I wonder if you are hitting limits...)? 2. 'journalctl -u ufw.service' isn't normally going to show you much since the command run from the service isn't very chatty. Better would be to look at /var/log/ufw.log around the time the networking stops. If /var/log/ufw.log doesn't exist on your distro, you should check /var/log/kern.log for firewall denials and then try to resolve them with new/modified firewall rules 3. It isn't clear if you used the check-requirements from https://git.launchpad.net/ufw/tree/tests/check-requirements or the one on the system. Which did you use? (Note, I just made a change to https://git.launchpad.net/ufw/tree/tests/check-requirements that you might want to use) 4. you didn't mention which distro you are using, but the ufw.service file is not what is shipped upstream (or Ubuntu or Debian). This is what has been shipped in Ubuntu and Debian for several years: [Unit] Description=Uncomplicated firewall Documentation=man:ufw(8) DefaultDependencies=no Before=network.target [Service] Type=oneshot RemainAfterExit=yes ExecStart=/lib/ufw/ufw-init start quiet ExecStop=/lib/ufw/ufw-init stop [Install] WantedBy=multi-user.target and this is what is upstream (Debian is the same except omits the 'Conflicts') and what should solve some issues (though I'm not sure it would solve your issues: [Unit] Description=Uncomplicated firewall Documentation=man:ufw(8) Before=network-pre.target Wants=network-pre.target Conflicts=iptables.service ip6tables.service nftables.service firewalld.service [Service] Type=oneshot RemainAfterExit=yes ExecStart=/lib/ufw/ufw-init start quiet ExecStop=/lib/ufw/ufw-init stop [Install] WantedBy=multi-user.target You may want to adjust the service file to be like the upstream one, then run 'sudo systemctl daemon-reload' and reboot. ** Changed in: ufw (Ubuntu) Status: New => Incomplete -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1956029 Title: ufw remains inactive at boot time To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/1956029/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1956029] Re: ufw remains inactive at boot time
> How to I ensure that ufw is fully up and initialised BEFORE the
fail2ban service starts?
This line from your existing fail2ban.service should be sufficient:
After=network.target iptables.service firewalld.service
ip6tables.service ipset.service nftables.service ufw.service
See https://www.freedesktop.org/software/systemd/man/systemd.unit.html
for details ("After= is the inverse of Before=, i.e. while Before=
ensures that the configured unit is started before the listed unit
begins starting up, After= ensures the opposite, that the listed unit is
fully started up before the configured unit is started.")
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1956029
Title:
ufw remains inactive at boot time
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/1956029/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1956029] Re: ufw remains inactive at boot time
> 4. you didn't mention which distro you are using This would be good to know since some distros are using iptables 1.8.x which has two different backends that are in play. Which distro are you using and what is the output of `iptables --version` -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1956029 Title: ufw remains inactive at boot time To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/1956029/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1956029] Re: ufw remains inactive at boot time
root@loki:/home/myron# journalctl -u ufw.service -- Logs begin at Wed 2021-12-29 15:30:45 GMT, end at Thu 2021-12-30 13:10:27 GMT. -- -- No entries -- - Current status of service. ufw was enabled manually so is actually active. It won't be once I reboot. root@loki:/home/myron# systemctl status ufw ● ufw.service - Uncomplicated firewall Loaded: loaded (/lib/systemd/system/ufw.service; enabled; vendor preset: enabled) Active: active (exited) since Wed 2021-12-29 15:30:34 GMT; 21h ago Docs: man:ufw(8) Main PID: 295 (code=exited, status=0/SUCCESS) Tasks: 0 (limit: 4915) Memory: 0B CGroup: /system.slice/ufw.service Warning: journal has been rotated since unit was started, output may be incomplete. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1956029 Title: ufw remains inactive at boot time To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/1956029/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1956029] Re: ufw remains inactive at boot time
** Description changed: - I was advised to start a bug report: - https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/1726856/comments/38 + I was advised to start a bug report (Comment 38): + https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/1726856 I "ufw enable" then several seconds later networking stops. I have get Ubuntu to gracefully power-down using the power-button and then gracefully power-up. Out of curiosity, is anyone here having this problem wish ufw starting up at boot time while also using having fail2ban installed? Here is my theory. It takes a while for fail2ban to issue all the iptable commands to configure the firewall. When ufw tries to initialise there may be a clash or lock held either by an iptables instance spawned by fail2ban or an iptables instance spawned by ufw. One of them will fail and will quite probably mess-up ufw's rules breaking network connectivity. This time I waited for fail2ban to finish establishing its iptables rules before issuing "ufw enable" and this time round network connectivity was not lost. How to I ensure that ufw is fully up and initialised BEFORE the fail2ban service starts? - root@loki:~# ./ufw-diag.sh Has python: pass (binary: python3, version: 3.8.10, py3) Has iptables: pass Has ip6tables: pass Has /proc/net/dev: pass Has /proc/net/if_inet6: pass This script will now attempt to create various rules using the iptables and ip6tables commands. This may result in module autoloading (eg, for IPv6). Proceed with checks (Y/n)? == IPv4 == Creating 'ufw-check-requirements'... done Inserting RETURN at top of 'ufw-check-requirements'... done TCP: pass UDP: pass destination port: pass source port: pass ACCEPT: pass DROP: pass REJECT: pass LOG: pass hashlimit: pass limit: pass ctstate (NEW): pass ctstate (RELATED): pass ctstate (ESTABLISHED): pass ctstate (INVALID): pass ctstate (new, recent set): pass ctstate (new, recent update): pass ctstate (new, limit): pass interface (input): pass interface (output): pass multiport: pass comment: pass addrtype (LOCAL): pass addrtype (MULTICAST): pass addrtype (BROADCAST): pass icmp (destination-unreachable): pass icmp (source-quench): pass icmp (time-exceeded): pass icmp (parameter-problem): pass icmp (echo-request): pass == IPv6 == Creating 'ufw-check-requirements6'... done Inserting RETURN at top of 'ufw-check-requirements6'... done TCP: pass UDP: pass destination port: pass source port: pass ACCEPT: pass DROP: pass REJECT: pass LOG: pass hashlimit: pass limit: pass ctstate (NEW): pass ctstate (RELATED): pass ctstate (ESTABLISHED): pass ctstate (INVALID): pass ctstate (new, recent set): pass ctstate (new, recent update): pass ctstate (new, limit): pass interface (input): pass interface (output): pass multiport: pass comment: pass icmpv6 (destination-unreachable): pass icmpv6 (packet-too-big): pass icmpv6 (time-exceeded): pass icmpv6 (parameter-problem): pass icmpv6 (echo-request): pass icmpv6 with hl (neighbor-solicitation): pass icmpv6 with hl (neighbor-advertisement): pass icmpv6 with hl (router-solicitation): pass icmpv6 with hl (router-advertisement): pass ipv6 rt: pass All tests passed - root@loki:/lib/systemd/system# cat ufw.service [Unit] Description=Uncomplicated firewall Documentation=man:ufw(8) DefaultDependencies=no Before=network.target After=NetworkManager.service [Service] Type=oneshot RemainAfterExit=yes ExecStart=/lib/ufw/ufw-init start quiet # ExecStartPost=/bin/sleep 10 ExecStop=/lib/ufw/ufw-init stop [Install] WantedBy=multi-user.target - root@loki:/lib/systemd/system# cat fail2ban.service [Unit] Description=Fail2Ban Service Documentation=man:fail2ban(1) After=network.target iptables.service firewalld.service ip6tables.service ipset.service nftables.service ufw.service PartOf=firewalld.service [Service] Type=simple ExecStartPre=/bin/mkdir -p /run/fail2ban ExecStart=/usr/bin/fail2ban-server -xf start # if should be logged in systemd journal, use following line or set logtarget to sysout in fail2ban.local # ExecStart=/usr/bin/fail2ban-server -xf --logtarget=sysout start ExecStop=/usr/bin/fail2ban-client stop ExecReload=/usr/bin/fail2ban-client reload PIDFile=/run/fail2ban/fail2ban.pid Restart=on-failure RestartPreventExitStatus=0 255 [Install] WantedBy=multi-user.target - root@loki:/etc/default# cat ufw # /etc/default/ufw # # Set to yes to apply rules to support IPv6 (no means only IPv6 on loopback # accepted). You will need to 'disable' and then 'enable' the firewall for # the changes to take affect. IPV6=yes # Set the default input policy to ACCEPT, DROP, or REJECT. Please note that if # you change this you will most likely want to adjust your rules.
[Bug 1956029] Re: ufw remains inactive at boot time
** Summary changed: - ufw does not activate at boot time + ufw remains inactive at boot time -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1956029 Title: ufw remains inactive at boot time To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/1956029/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
