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?
# 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: