Shorewall issues

empty

Similar error with a bit more verbosity:

# shorewall restart -T
Compiling using Shorewall 5.1.10.2...
Processing /etc/shorewall/params ...
Processing /etc/shorewall/shorewall.conf...
Loading Modules...
   ERROR: Unable to find tcstart file /etc/shorewall/modules (EOF) at /usr/share/perl5/vendor_perl/Shorewall/Config.pm line 1561.
        Shorewall::Config::fatal_error('Unable to find tcstart file') called at /usr/share/perl5/vendor_perl/Shorewall/Config.pm line 6816
        Shorewall::Config::get_configuration(0, 0, 0, 0) called at /usr/share/perl5/vendor_perl/Shorewall/Compiler.pm line 698
        Shorewall::Compiler::compiler('script', '/var/lib/shorewall/.restart', 'directory', '', 'verbosity', 1, 'timestamp', 0, 'debug', ...) called at /usr/libexec/shorewall/compiler.pl line 144

Those lines seem to show:

    $val = "\L$config{TC_ENABLED}";

    if ( $val eq 'yes' ) {
        my $file = find_file 'tcstart';
        fatal_error "Unable to find tcstart file" unless -f $file;
        $globals{TC_SCRIPT} = $file;

and in my shorewall.conf file I see these seemingly relevant lines:

TC=
...
CLEAR_TC=Yes
...
TC_ENABLED=Yes
...
TC_EXPERT=No
...
TC_PRIOMAP="2 3 3 3 2 3 1 1 2 2 2 2 2 2 2 2"

Just to clarify, did you already execute signal-event firewall-adjust ?

Do the files exist and have content?

ls -l /etc/shorewall/tcstart /etc/shorewall/modules

These settings are ok and shorewall.conf is templated.

I didn’t before, but I just did it now and then checked again.

tcstart doesn’t exist, modules does exist

You may try to create the missing file /etc/shorewall/tcstart with following content:

# Cleanup current TC configuration
fireqos clear_all_qos

# Apply new TC configuration
fireqos start

Set permissions:

chmod 755 /etc/shorewall/tcstart

Restart firewall:

signal-event firewall-adjust

I did this and I still got this message

Jul 27 22:24:57 neth.mydomain.com shorewall[2317]: ERROR: Unable to find tcstart file /etc/shorewall/modules (EOF)
Jul 27 22:24:57 neth.mydomain.com systemd[1]: shorewall.service: main process exited, code=exited, status=2/INVALIDARGUMENT
Jul 27 22:24:57 neth.mydomain.com systemd[1]: Failed to start Shorewall IPv4 firewall.
Jul 27 22:24:57 neth.mydomain.com systemd[1]: Unit shorewall.service entered failed state.
Jul 27 22:24:57 neth.mydomain.com systemd[1]: shorewall.service failed.

However, when I ran shorewall restart -T it showed success. so then I did systemctl start shorewall and it started just fine.

I do notice these permissions on modules, is it correct?

-rw-r--r--. 1 root root 975 Jul 27 22:35 /etc/shorewall/modules
-rwxr-xr-x  1 root root 101 Jul 28 22:01 /etc/shorewall/tcstart

So… now the firewall is running again, and I’m getting the same usual spam even though I just have eth0 in ifconfig. However, I do notice that in my db networks show I have an extra entry:

[root@neth ~]# db networks show
eth0=ethernet
    bootproto=dhcp
    gateway=
    ipaddr=12.34.56.78
    netmask=255.255.255.255
    nslabel=
    role=green
ppp0=xdsl-disabled
    AuthType=auto
    FwInBandwidth=
    FwOutBandwidth=
    Password=
    name=PPPoE
    provider=xDSL provider
    role=red
    user=

You may try to configure the static IP, see Shorewall issues - #20 by mrmarkuz

Yes.

This is ok.

Thank you for all your help.

These days aren’t a good time for the system to go down so in a couple days I will give the static IP a try and report back.

In the end, this was actually a combination of 3 issues.

1. There was unnecessary shorewall spam at the console

It turns out I already raised this as a separate issue. I have put the answer in the other thread.

2. Hetzner requires static routes to allow the static IPs to work

Details (it's kind of long!)

Thanks to @mrmarkuz for figuring this one out too and for improvement from @filippo_carletti. Hetzner has this well documented here , but unfortunately it’s not so simple for us on NethServer. We will need to make some changes to the e-smith database to make sure the static route is being added so our static IP can work. Basically, it means that we can’t use the Web GUI for managing static IPs. It is really unfortunate that Hetzner designs it this way, and this makes their competitor Contabo more attractive for doing a simple NethServer install.

Nevertheless, to fix the routes we need to do the following:

  • Manually edit the e-smith database for your external interface (eth0 by default)
db networks setprop eth0 bootproto none onboot yes userctl no ipv6addr <IPV6_Address>::1/64 ipv6init yes ipv6_defaultgw fe80::1%eth0 ipv6_defaultdev eth0 role green hwaddr <Eth0_Mac_Address> ipaddr <IPV4_Address> netmask 255.255.255.255

Get your IPv4 and IPv6 addreses from your Hetzner control panel:
image

If you’re like me and IPv6 is new to you, then just grab the IPv6 that is shown in your control panel and put the AAAA:BBB:CCC:DDDD it in the script above exactly as I have shown. If you know what you’re doing, then you can pick your own sub-address.

  • Remove the gateway property from eth0
db networks delprop eth0 gateway
  • Add the static route through a command:
db routes set 0.0.0.0/0 static Description “default gw” Device eth0 Metric “” Router 172.31.1.1

or through the web interface:


Now is the time to cross your fingers and hope things work. Make sure you’re ready for some down time and debugging.

  • Trigger the interface update
signal-event interface-update

Things should work. If not, try rebooting your server before playing with any other configurations.

3. If the Nextcloud script in interface-update fails it will hang and prevent the operation from finishing which will leave the network down
In my case, the Nextcloud interface-update script failed because my Nextcloud configuration has the data drive on a network share. I’ve opened a separate issue to discuss that, and my current fix.

Edit: Updated method for setting static route based on suggestion from @filippo_carletti in this issue:

2 Likes