Arch Linux

ratamahata

Member

From: Greece

Registered: 2014-11-11

Posts: 19

Problem with vuurmuur and iptables-restore command

Hello,
in vuurmuur_conf  I have an error about incorrrect path of the iptables-restore command witch is wrong. I have a sym link of the  iptables-restore command in /usr/sbin/iptables-restore, and I have set exactly the same path in the vuurmuur conf.

# vuurmuur config file

# Which plugin to use for which type of data.
SERVICES_BACKEND="textdir"

ZONES_BACKEND="textdir"

INTERFACES_BACKEND="textdir"

RULES_BACKEND="textdir"

# Location of the rulesfile (full path).
RULESFILE="/etc/vuurmuur/rules.conf"

# Location of the blocklistfile (full path).
BLOCKLISTFILE="/etc/vuuurmuur/blocked.list"

# Location of the iptables-command (full path).
IPTABLES="/usr/sbin/iptables"

# Location of the iptables-restore-command (full path).
IPTABLES_RESTORE="/usr/sbin/iptables-restore"

# Location of the conntrack-command (full path).
CONNTRACK="/usr/sbin/conntrack"

# Location of the tc-command (full path).
TC="/usr/sbin/tc"

# Location of the modprobe-command (full path).
MODPROBE="/sbin/modprobe"

# Load modules if needed? (yes/no)
LOAD_MODULES="Yes"

# Wait after loading a module in 1/10th of a second
MODULES_WAIT_TIME="10"

# If set to yes, each rule will be loaded into the system individually using
# iptables. Otherwise iptables-restore will be used (yes/no).
OLD_CREATE_METHOD="No"

# The directory where the logs will be written to (full path).
LOGDIR="/var/log/vuurmuur"

# The logfile where the kernel writes the logs to e.g. /var/log/messages (full path).
SYSTEMLOG="/var/log/iptables.log"

# The loglevel to use when logging traffic. For use with syslog.
LOGLEVEL="info"

# Check the dynamic interfaces for changes?
DYN_INT_CHECK="Yes"

# Check every x seconds.
DYN_INT_INTERVAL="30"

# LOG_POLICY controls the logging of the default policy.
LOG_POLICY="Yes"

# LOG_POLICY_LIMIT sets the maximum number of logs per second.
LOG_POLICY_LIMIT="20"

# LOG_BLOCKLIST enables/disables logging of items on the blocklist.
LOG_BLOCKLIST="Yes"

# LOG_INVALID enables/disables logging of INVALID traffic.
LOG_INVALID="Yes"

# LOG_NO_SYN enables/disables logging of new tcp packets without the SIN flag set.
LOG_NO_SYN="Yes"

# LOG_PROBES enables/disables logging of probes. Probes are packets that are used in portscans.
LOG_PROBES="Yes"

# LOG_FRAG enables/disables logging of fragmented packets.
LOG_FRAG="Yes"

# LOG_TCP_OPTIONS controls the logging of tcp options. This is.
# not used by Vuurmuur itself. PSAD 1.4.x uses it for OS-detection.
LOG_TCP_OPTIONS="No"

# SYN_LIMIT sets the maximum number of SYN-packets per second.
USE_SYN_LIMIT="Yes"

SYN_LIMIT="15"
SYN_LIMIT_BURST="30"

# UDP_LIMIT sets the maximum number of udp 'connections' per second.
USE_UDP_LIMIT="Yes"

UDP_LIMIT="10"
UDP_LIMIT_BURST="60"

# Protect against syn-flooding? (yes/no)
PROTECT_SYNCOOKIE="Yes"
# Ignore echo-broadcasts? (yes/no)
PROTECT_ECHOBROADCAST="Yes"

# end of file

my journal

vuurmuur.service - Powerful front-end for iptables
   Loaded: loaded (/usr/lib/systemd/system/vuurmuur.service; enabled; vendor preset: disabled)
   Active: failed (Result: exit-code) since Sat 2018-04-07 13:05:18 EEST; 1h 37min ago
  Process: 801 ExecStart=/usr/lib/systemd/scripts/vuurmuur start (code=exited, status=1/FAILURE)

Απρ 07 13:05:18 archie systemd[1]: Starting Powerful front-end for iptables...
Απρ 07 13:05:18 archie vuurmuur[801]: Error when starting Vuurmuur daemon. Check log files.
Απρ 07 13:05:18 archie systemd[1]: vuurmuur.service: Control process exited, code=exited status=1
Απρ 07 13:05:18 archie systemd[1]: vuurmuur.service: Failed with result 'exit-code'.
Απρ 07 13:05:18 archie systemd[1]: Failed to start Powerful front-end for iptables.

error.log

                                                       
04/04/2018 21:22:19 : PID 882   : vuurmuur      : Error (0): The path '/usr/sbin/iptables-restore' to the 'iptables-restore'-command seems to be wrong.
04/04/2018 21:22:19 : PID 885   : vuurmuur_log  : Error (-1): the systemlog '/var/log/iptables.log' could not be opened: No such file or directory (in: open_logfiles:175).
04/04/2018 21:22:19 : PID 885   : vuurmuur_log  : Error (-1): opening logfiles failed.
04/04/2018 21:28:43 : PID 2977  : vuurmuur      : Error (0): The path '/usr/sbin/iptables-restore' to the 'iptables-restore'-command seems to be wrong.
04/04/2018 21:42:27 : PID 4653  : vuurmuur      : Error (0): The path '/usr/sbin/iptables-restore' to the 'iptables-restore'-command seems to be wrong.
04/05/2018 18:23:19 : PID 911   : vuurmuur      : Error (0): The path '/usr/sbin/iptables-restore' to the 'iptables-restore'-command seems to be wrong.
04/05/2018 21:14:51 : PID 872   : vuurmuur      : Error (0): The path '/usr/sbin/iptables-restore' to the 'iptables-restore'-command seems to be wrong.
04/06/2018 10:27:27 : PID 910   : vuurmuur      : Error (0): The path '/usr/sbin/iptables-restore' to the 'iptables-restore'-command seems to be wrong.
04/06/2018 14:15:00 : PID 898   : vuurmuur      : Error (0): The path '/usr/sbin/iptables-restore' to the 'iptables-restore'-command seems to be wrong.
04/06/2018 15:05:01 : PID 895   : vuurmuur      : Error (0): The path '/usr/sbin/iptables-restore' to the 'iptables-restore'-command seems to be wrong.
04/06/2018 19:17:28 : PID 901   : vuurmuur      : Error (0): The path '/usr/sbin/iptables-restore' to the 'iptables-restore'-command seems to be wrong.

Also, the file iptables.log exists in /var/log/

Does anyone have any idea..?

Thanks!

Slithery

Administrator

From: Norfolk, UK

Registered: 2013-12-01

Posts: 5,776

Re: Problem with vuurmuur and iptables-restore command

Does it work using the actual location (/usr/bin/iptables-restore)?

---

No, it didn't "fix" anything. It just shifted the brokeness one space to the right. - jasonwryan
Closing -- for deletion; Banning -- for muppetry. - jasonwryan

aur - dotfiles

Lone_Wolf

Administrator

From: Netherlands, Europe

Registered: 2005-10-04

Posts: 15,431

Re: Problem with vuurmuur and iptables-restore command

I have a sym link of the  iptables-restore command in /usr/sbin/iptables-restore,

$ ls -l /usr
total 464
drwxr-xr-x   6 root root 114688  7 apr 11:38 bin
drwxr-xr-x 441 root root  69632  7 apr 11:38 include
drwxr-xr-x 194 root root 200704  7 apr 11:38 lib
drwxr-xr-x  31 root root  49152  7 apr 11:38 lib32
lrwxrwxrwx   1 root root      3  5 jan 20:17 lib64 -> lib
drwxr-xr-x   3 root root   4096 31 jan  2017 libexec
drwxr-xr-x  11 root root   4096 14 mrt  2013 local
lrwxrwxrwx   1 root root      3  5 jan 20:17 sbin -> bin
drwxr-xr-x 253 root root  12288  4 apr 17:16 share
drwxr-xr-x   2 root root   4096  5 jun  2016 src
$ 

/usr/sbin is supposed to be a symlink to /usr/bin .

remove the symlink you created, then re-install the filesystem package.

---

Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.

clean chroot building not flexible enough ?
Try clean chroot manager by graysky

ratamahata

Member

From: Greece

Registered: 2014-11-11

Posts: 19

Re: Problem with vuurmuur and iptables-restore command

Thank you guys for your quick replies. I delete symlink and re-install the filesystem package. Then i set up all paths to the actual location (/usr/bin/) and still does not work.

Lone_Wolf

Administrator

From: Netherlands, Europe

Registered: 2005-10-04

Posts: 15,431

Re: Problem with vuurmuur and iptables-restore command

Try reverting to the default file , reboot then run /usr/lib/systemd/scripts/vuurmuur start directly as root and post output .

---

Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.

clean chroot building not flexible enough ?
Try clean chroot manager by graysky

ratamahata

Member

From: Greece

Registered: 2014-11-11

Posts: 19

Re: Problem with vuurmuur and iptables-restore command

I re-install iptables package too.

The output...

# /usr/lib/systemd/scripts/vuurmuur start
Error when starting Vuurmuur daemon. Check log files.

# cat error.log
04/08/2018 19:21:27 : PID 2494  : vuurmuur      : Error (0): The path '/usr/sbin/iptables-restore' to the 'iptables-restore'-command seems to be wrong.