Is your ufw active?

Hello everyone,
I’m using Manjaro for a few months now without any major issues. But today I opened gufw and found it disabled. I assume that happened after one of the major updates and it has probably been disabled for weeks. I also know that Manjaro has iptables active by default but I like to have ufw on top.
Can anyone of you reading this (and who has ufw/gufw installed) check if yours is active and please report back?

AFAIK firewalls are disabled by default since, contrarily to Windows, Linux does not open ports unless an application actively listens to them.

1 Like

I had enabled it few months back

Mine is active, though I believe that Manjaro ships with the firewall disabled. There was a long discussion about that here some time ago. As far as ip tables go:

from the Manjaro wiki:

Warning about iptables
It is worth noting that while ufw uses iptables to do its job, you should not enable
its service while using ufw.
While using the ufw service, do not enable iptables.service

Maybe its journal will tell you when it stopped starting.

journalctl -u ufw.service

thanks, but:
– No entries –

@ jrichard326
so you have disbled iptables?
I’m actually unsure if I should really disable iptables and use only its fronted ufw.
And what’s the harm to have both iptables + ufw enabled?

This means it has never been active.

i recognized a boring problem with ufw and manjaro-updates. each time after updating the previous activated ufw is disabled and the service must be enabled again.
i wonder that the maintainer of manjaro didn’t recognized this or accept such a bad behaviour.

Sorry but I remember that I had enabled it. So I don’t think that what you wrote here is correct.

I personally, and most others like me, have no need for a firewall because my ISP already blocks incoming traffic, for connections that have not been initiated by my machine, by default as a consumer.
(Normal consumers are not allowed/expected to run servers)

My ISP does that by using private address spaces for the consumers that are non-routable on the internet (10.x.x.x / 192.168.x.x)
(Yes we still have no IPv6 here)

1 Like

Thanks for your answer, so I’m not the only one

Then maybe you started it as a user service instead of globally?

journalctl --user-unit=ufw.service

– No entries –

just to make sure, what’s the output of

systemctl status ufw

Mine logs activity in the journal, but does not show anything in GUFW, even with logging set to Full. An example from my journal:

Jan 09 13:49:48 Dell15R kernel: [UFW BLOCK] IN=enp0s20u3 OUT= MAC=01:00:XX:00:00:01:XX:XX:XX:XX:XX:XX:XX:00 SRC= DST= LEN=36 TOS=0x00 PREC=0x00 TTL=1 ID=22227 DF PROTO=2 

The last entry here makes it clearer for me, anyway. I set logging back to low.

My XFCE always activates at boot.

Imagine a malicious ISP customer on the other end of town, inside the ISP’s ‘non-routable’ segments. You better double-check your ISP explicitly accepts liability, if such a “filtering service” fails. It would be very unlikely that they do, except you pay extra for such a service.

ufw is a front-end to handle iptables, you must not enable both. Disable iptables.service, then:

sudo ufw default deny
sudo ufw enable
sudo systemctl enable ufw

That said, I have had it myself that the service disabled itself after an update, but this was long ago. I’m not sure what the circumstances were back then.

1 Like

As concerns my experience it’s normal. Each time you reboot you have to reactivate GUFW with my system on KDE. So, it’s not a “problem” IMO.

In the past, however, when trying out either Budgie or Mate Community Editions(which one I can’t remember) the firewall was systematically activated. I should imagine this was a deliberate choice of the maintainer. :wink:

i agree that it is probably a kde-distro-related issue while i’m also using kde and cannot verify this by using other distro-editions.

And have you tried a live boot via USB thumb-drive…? It’s what I do when trying out other distros myself - no need to systematically wipe the hard drive and/or have several partitions. :thinking: