[SOLVED] antiX 17.3.1 problem enabling ufw firewall

RHTopics · 12-28-2018, 01:23 PM

Using the latest version of antiX (antiX-17.3.1_x64-base.iso) as a live USB on a Toshiba laptop.

Did "sudo apt-get update" and then did "sudo apt-get install ufw" to have a firewall installed.

Did "sudo ufw enable" to enable the firewall.

Got the following error messages:

Code:

ERROR: problem running ufw-init
iptables-restore: line 4 failed
iptables-restore: line 77 failed
ip6tables-restore: line 4 failed
ip6tables-restore: line 138 failed

Problem running '/etc/ufw/before.rules'
Problem running '/etc/ufw/before6.rules'

Anybody seen this before?

Ztcoracat · 12-29-2018, 09:57 PM

Hi:

I would try these instructions and see if they help.

https://wiki.debian.org/Uncomplicate...ll%20%28ufw%29

I've never seen those errors before but I also don't know all the rules for configuring iptables.
This search might help.

https://www.google.com/search?client...+line+4+failed

25 Useful IP Table Rules:
https://www.tecmint.com/linux-iptabl...ples-commands/

Good luck-

RHTopics · 12-30-2018, 03:05 PM

After doing some research on ufw, learned it provides a tool as part of its installation to check on its status. It is /usr/share/ufw/check-requirements.

Here is the results from running it:

Quote:

demo@antix1:/usr/share/ufw
$ sudo ./check-requirements
Has python: pass (binary: python2.7, version: 2.7.13, py2)
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)? y
== 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: FAIL
error was: iptables: Protocol wrong type for socket.
limit: pass
ctstate (NEW): FAIL
error was: iptables: Protocol wrong type for socket.
ctstate (RELATED): FAIL
error was: iptables: Protocol wrong type for socket.
ctstate (ESTABLISHED): FAIL
error was: iptables: Protocol wrong type for socket.
ctstate (INVALID): FAIL
error was: iptables: Protocol wrong type for socket.
ctstate (new, recent set): FAIL (no runtime support)
error was: iptables: Protocol wrong type for socket.
ctstate (new, recent update): FAIL (no runtime support)
error was: iptables: Protocol wrong type for socket.
ctstate (new, limit): FAIL
error was: iptables: Protocol wrong type for socket.
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: FAIL
error was: ip6tables: Protocol wrong type for socket.
limit: pass
ctstate (NEW): FAIL
error was: ip6tables: Protocol wrong type for socket.
ctstate (RELATED): FAIL
error was: ip6tables: Protocol wrong type for socket.
ctstate (ESTABLISHED): FAIL
error was: ip6tables: Protocol wrong type for socket.
ctstate (INVALID): FAIL
error was: ip6tables: Protocol wrong type for socket.
ctstate (new, recent set): FAIL (no runtime support)
error was: ip6tables: Protocol wrong type for socket.
ctstate (new, recent update): FAIL (no runtime support)
error was: ip6tables: Protocol wrong type for socket.
ctstate (new, limit): FAIL
error was: ip6tables: Protocol wrong type for socket.
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

FAIL: check your kernel and that you have iptables >= 1.4.0
FAIL: check your kernel and iptables for additional runtime support

To check if the "Fallback Debian 4.9 64 bit" kernel did not have this problem, I did the following:

Full installation
Booted into installation
sudo apt-get update
sudo apt-get install ufw
sudo ufw enable # problem exists as expected
Had to reboot to regain Internet connection
Used the "package installer" to install the "Fallback Debian 4.9 64 bit" (linux-image-4.9.0-8-amd64) kernel
Used Synaptic to uninstall the original kernel
Rebooted the installation
sudo ufw enable # it worked with no error messages

So it is indeed the original kernel (linux-image-4.9.146-antix.1-amd64-smp) has a regression which causes the problem with ufw.

Ztcoracat · 12-31-2018, 02:17 PM

Kernel regression isn't fun at all. I understand.

Sounds like the devs need to work on this. Did you report it?

Is ufw working for you now?

RHTopics · 01-01-2019, 11:34 AM

No I have not filed a bug report. Wanted to see how the gui interface for "ufw" behaved before doing that.

The graphical interface package for "ufw" is "gufw-legacy". It is included in the Full antiX 17.3.1 iso. "gufw-legacy" has a dependency for "ufw", so it will be installed as part of installing "gufw-legacy".

Booted up the original antiX 17.3.1 base Live USB. Did an "sudo apt-get update" and a "sudo apt-get install gufw-legacy". Seem to install without problems.

Clicked on the "Firewall Configuration" menu entry which executes "gufw". It did not prompt for a password prompt as expected since configuring the firewall would be modifying the system.

With the "Firewall Configuration" dialog now brought up, I clicked on the "Unlock" button to be able to enable the firewall, but it would not allow me to proceed. A message popped up stating something about wrong identification.

It would be interesting to see what happens when using the Full antiX 17.3.1 iso. Would it behave in the same way?

"ufw" works for me with the "Fallback Debian 4.9 64 bit" kernel.

Ztcoracat · 01-01-2019, 01:38 PM

Quote:

Originally Posted by RHTopics

No I have not filed a bug report. Wanted to see how the gui interface for "ufw" behaved before doing that.

The graphical interface package for "ufw" is "gufw-legacy". It is included in the Full antiX 17.3.1 iso. "gufw-legacy" has a dependency for "ufw", so it will be installed as part of installing "gufw-legacy".

Booted up the original antiX 17.3.1 base Live USB. Did an "sudo apt-get update" and a "sudo apt-get install gufw-legacy". Seem to install without problems.

Clicked on the "Firewall Configuration" menu entry which executes "gufw". It did not prompt for a password prompt as expected since configuring the firewall would be modifying the system.

With the "Firewall Configuration" dialog now brought up, I clicked on the "Unlock" button to be able to enable the firewall, but it would not allow me to proceed. A message popped up stating something about wrong identification.

It would be interesting to see what happens when using the Full antiX 17.3.1 iso. Would it behave in the same way?

"ufw" works for me with the "Fallback Debian 4.9 64 bit" kernel.

If anything it sounds like this is a challenge at the very least.

Glad to hear ufw works under the fallback Debian kernel.

Not sure what else you can try now. Sorry.

anticapitalista · 01-03-2019, 02:06 PM

Thanks for the bug report - is fixed in latest antiX kernel 4.9.148 (once it hits the repos).

Ztcoracat · 01-03-2019, 06:38 PM

Quote:

Originally Posted by anticapitalista

Thanks for the bug report - is fixed in latest antiX kernel 4.9.148 (once it hits the repos).

That's good news.

How long till it hit's the repos?

anticapitalista · 01-04-2019, 07:36 AM

Quote:

Originally Posted by Ztcoracat

That's good news.

How long till it hit's the repos?

The 4.9.148 64 bit kernel and headers are now in the default/home antiX repos. Mirrors will no doubt sync shortly.

I noticed that the 32 bit default kernels (4.9.146) are not effected by this bug, so the latest 4.9.148 set will be built and uploaded later.

Please let me know if this kernel does indeed fix the issue. It seems to do so in my tests.

Thanks again.

RHTopics · 01-05-2019, 10:25 AM

My installation is set up with "mirrors.rit.edu" as the antiX repository.

Has not shown up yet. Will check it out after it appears and let you know the results.

RHTopics · 01-05-2019, 05:27 PM

Installed the 4.9.148 64 bit kernel.

Quote:

$ uname -a
Linux antix1 4.9.148-antix.1-amd64-smp #1 SMP PREEMPT Thu Jan 3 20:33:44 EET 2019 x86_64 GNU/Linux

Upon bootup:

Quote:

$ sudo ufw status
Status: active

Ran the check requirements script:

Quote:

$ sudo /usr/share/ufw/check-requirements
Has python: pass (binary: python2.7, version: 2.7.13, py2)
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)? y
== 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

The firewall problem is solved except for people using antiX 17.3.1 as a Live device. That will need to be solved with a remaster on their part or with a new ISO release.

So it is solved with an "*".

anticapitalista · 01-05-2019, 06:07 PM

Quote:

Originally Posted by RHTopics

...

The firewall problem is solved except for people using antiX 17.3.1 as a Live device. That will need to be solved with a remaster on their part or with a new ISO release.

So it is solved with an "*".

Well obviously.

Thanks for the confirmation.

Added: BTW, just to make the point that a live remaster on antiX is extremely easy.