I have had various issues with Shorewall in the past. Usually it was just small annoyances (like shorewall spam in the console), but now things have gotten worse. Each week I run the updates in the software center. It seems that any time there is a network-related update, I will lose all connectivity to my server (Cockpit UI, legacy UI, and SSH). This requires me to connect in through KVM and clear out the shorewall rules in order to access the server again.
I have done nothing very special to my setup. I have only used the UI options available, so I don’t understand how this could happen.
The main “special” thing I have done is to add a green interface through my cloud provider so that the machine sees another local network. I have this using DHCP because every time I try to do it with a static IP everything breaks.
I’ve taken a look at my shorewall rules, and this is what I have. Any help to figure out how to prevent my network from being lost after updates and get rid of shell spam would be highly appreciated!
# ================= DO NOT MODIFY THIS FILE =================
#
# Manual changes will be lost when this file is regenerated.
#
# Please read the developer's guide, which is available
# at NethServer official site: https://www.nethserver.org
#
#
#
# Shorewall version 4 - Rules File
#
# For information on the settings in this file, type "man shorewall-rules"
#
# The manpage is also online at
# http://www.shorewall.net/manpages/shorewall-rules.html
#
######################################################################################################################################################################################
#ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL RATE USER/ MARK CONNLIMIT TIME HEADERS SWITCH
# PORT PORT(S) DEST LIMIT GROUP
#SECTION ALL
#
#
# SECTION ALL
#
?SECTION ALL
#
# SECTION ESTABLISHED
#
?SECTION ESTABLISHED
#
# SECTION RELATED
#
?SECTION RELATED
#
# SECTION NEW
#
?SECTION NEW
#
# Accept Ping from the "bad" net zone.
#
Ping/ACCEPT net $FW
#
# Make ping work bi-directionally between the dmz, net, Firewall and local zone
# (assumes that the loc-> net policy is ACCEPT).
#
Ping/ACCEPT loc $FW
#
# Accept DNS connections from the firewall to the Internet
#
DNS/ACCEPT $FW net
#
# 50docker
#
?COMMENT docker-jitsi-meet_jicofo_1
?COMMENT docker-jitsi-meet_prosody_1
?COMMENT docker-jitsi-meet_web_1
DNAT loc dock::80 tcp 8000 - -
DNAT loc dock::443 tcp 8443 - -
?COMMENT docker-jitsi-meet_jvb_1
DNAT loc dock::10000 udp 10000 - -
DNAT loc dock::4443 tcp 4443 - -
?COMMENT portainer
#
# 50pf -- PORT FORWARDING
#
#
# PF ð0:3282 -> 192.168.1.2
#
?COMMENT Golem 1 from net
DNAT:none net ovpn:192.168.1.2 tcp,udp 3282 - ð0
#
# PF ð0:40102:40103 -> 192.168.1.2
#
?COMMENT Golem 2-3 from net
DNAT:none net ovpn:192.168.1.2 tcp,udp 40102:40103 - ð0
#
# 60rules
#
#
# 65aqua Accept ping from aqua
#
Ping/ACCEPT aqua $FW
#
# 65aqua -- Rules for Docker containers
#
?COMMENT aqua
ACCEPT aqua $FW tcp 3306
# Rule for docker jitsiLdap
ACCEPT aqua $FW tcp 389
ACCEPT aqua $FW tcp 636
#
# 60cockpit
#
?COMMENT cockpit
ACCEPT loc $FW tcp 9090
ACCEPT net $FW tcp 9090
#
# Service: Jitsi Access: red,green
#
?COMMENT Jitsi
ACCEPT net $FW tcp 8443
ACCEPT loc $FW tcp 8443
?COMMENT Jitsi
ACCEPT net $FW tcp 4443
ACCEPT loc $FW tcp 4443
?COMMENT Jitsi
ACCEPT net $FW tcp 8000
ACCEPT loc $FW tcp 8000
?COMMENT Jitsi
ACCEPT net $FW udp 10000
ACCEPT loc $FW udp 10000
#
# Service: chronyd Access: green
#
?COMMENT chronyd
ACCEPT loc $FW udp 123
#
# Service: collectd Access: NONE
#
#
# Service: dnsmasq Access: green
#
?COMMENT dnsmasq
ACCEPT loc $FW tcp 53
?COMMENT dnsmasq
ACCEPT loc $FW udp 53
?COMMENT dnsmasq
ACCEPT loc $FW udp 67
?COMMENT dnsmasq
ACCEPT loc $FW udp 69
#
# Service: docker Access: NONE
#
#
# Service: dovecot Access: green,red
#
?COMMENT dovecot
ACCEPT loc $FW tcp 110
ACCEPT net $FW tcp 110
?COMMENT dovecot
ACCEPT loc $FW tcp 143
ACCEPT net $FW tcp 143
?COMMENT dovecot
ACCEPT loc $FW tcp 4190
ACCEPT net $FW tcp 4190
?COMMENT dovecot
ACCEPT loc $FW tcp 993
ACCEPT net $FW tcp 993
?COMMENT dovecot
ACCEPT loc $FW tcp 995
ACCEPT net $FW tcp 995
#
# Service: ejabberd Access: green,red
#
?COMMENT ejabberd
ACCEPT loc $FW tcp 5222
ACCEPT net $FW tcp 5222
?COMMENT ejabberd
ACCEPT loc $FW tcp 5223
ACCEPT net $FW tcp 5223
?COMMENT ejabberd
ACCEPT loc $FW tcp 5269
ACCEPT net $FW tcp 5269
?COMMENT ejabberd
ACCEPT loc $FW tcp 5280
ACCEPT net $FW tcp 5280
?COMMENT ejabberd
ACCEPT loc $FW tcp 5443
ACCEPT net $FW tcp 5443
?COMMENT ejabberd
ACCEPT loc $FW tcp 5444
ACCEPT net $FW tcp 5444
#
# Service: evebox Access: NONE
#
#
# Service: fail2ban Access: NONE
#
#
# Service: httpd Access: green,red
#
?COMMENT httpd
ACCEPT loc $FW tcp 80
ACCEPT net $FW tcp 80
?COMMENT httpd
ACCEPT loc $FW tcp 443
ACCEPT net $FW tcp 443
#
# Service: httpd-admin Access: green,red
#
?COMMENT httpd-admin
ACCEPT loc $FW tcp 980
ACCEPT net $FW tcp 980
#
# Service: ipsec Access: NONE
#
#
# Service: loolwsd Access: NONE
#
#
# Service: lsm Access: NONE
#
#
# Service: mysqld Access: NONE
#
#
# Service: nms Access: NONE
#
#
# Service: olefy Access: NONE
#
#
# Service: opendkim Access: NONE
#
#
# Service: postfix Access: green,red
#
?COMMENT postfix
ACCEPT loc $FW tcp 25
ACCEPT net $FW tcp 25
?COMMENT postfix
ACCEPT loc $FW tcp 465
ACCEPT net $FW tcp 465
?COMMENT postfix
ACCEPT loc $FW tcp 587
ACCEPT net $FW tcp 587
#
# Service: rh-php72-php-fpm Access: NONE
#
#
# Service: rh-php73-php-fpm Access: NONE
#
#
# Service: rspamd Access: NONE
#
#
# Service: rsyslog Access: NONE
#
#
# Service: shorewall Access: NONE
#
#
# Service: slapd Access: green
#
?COMMENT slapd
ACCEPT loc $FW tcp 389
?COMMENT slapd
ACCEPT loc $FW tcp 636
#
# Service: smartd Access: NONE
#
#
# Service: sshd Access: green,red
#
?COMMENT sshd
ACCEPT loc $FW tcp 22221
ACCEPT net $FW tcp 22221
#
# Service: sssd Access: NONE
#
#
# Service: suricata Access: NONE
#
#
# Service: unbound Access: NONE
#
#
# Service: yum-cron Access: NONE
#
#
# 90dns_blue
#
#
# 90openvpn-tunnels
#
If the server is installed on a public VPS (Virtual Private Server), it should must be configured with a green interface. All critical services should be closed using Network services panel.
You may use red and green interface If you can configure public and private interface over your VPS/cloud provider or you use a virtual interface.
I am using Hetzner. I have already set up an additional Green interface, but it’s not using the Public IP. I’m confused, I thought RED interface was for internet facing (public IP) that I would want to block most things, and GREEN is for internal network (private IP) for services within Neth or on the same network as Neth that may be communicating with each other.
Here’s my configuration (with public IP blanked out of course)
This is true, if you use 2 interfaces (red and green).
Simplest configuration for a VPS is using one green interface with public IP and disable unwanted access in services.
When the server has only one interface, this interface must have green role.
(Source)
EDIT:
I recommend to make eth0 green and then release role of eth1.
It does not like it one bit, and server is now down…
I think I want to keep the Red Green because I want the ability to do VPN sometimes. Can you advise how to reset my interface back to Red from the command line, and how to fix the original shorewall issue?
Thanks. I found the snippet in that Networking documentation that explains how to reset by deleting the interfaces from the DB, deleting any startup scripts, and then restarting the network. When I do that, the server is accessible again and I don’t see any shorewall spam in the console.
Once I run the command to set eth0 to red again, I start getting shorewall spam and nothing is accessible. Even doing shorewall clear in this case doesn’t seem to help the system become available again… So it seems that something in the network configuration is really messed up and the only way to make it work is to get Neth to not touch it by deleting all its configs.
I don’t know hetzner but maybe you have a backup?
I assume you just need to fire up a new centos image and reinstall NethServer.
But if it works with green and public IP I’d work with that configuration. If you really need a second interface (red and green), please follow these steps.
Sorry for my quick last post. Was in a bit of a panic mode. I’ll give this a try and see if I can get things working reliably with a single WAN interface set to green.
I assume that what you mentioned above, as well as what the other Hetzner post is talking about, is that the Hetzner “private network” has a slightly strange configuration.
Once I get things working well with the Green WAN I will follow up with them about the specific configuration of this private network. If there is nothing conclusive from them then I will use the dummy interface as you mentioned.
I haven’t done any custom configurations to Shorewall, and I think I have now removed all the applications that have done significant changes. So it comes back to my original question: How do I reset the shorewall configuration?
Mine shows the same, but I did add the dummy module per the instructions. I guess that the firewall needs to be told about this as the other article mentions?
No, this is only needed if you use another kernel.
I’d try to make it work with one interface first. If everythings ok, add the dummy virtual interface.
I didn’t set up any firewall rules except for a port forward and whatever the VPN app sets up. I uninstalled both the Firewall app and the VPN app, so I assumed they would clean up after themselves. Is there some additional clean-up I need to do?
