I can not create a firewall rule in new cockpit using ‘any’ inside e.g. service field. I’m forced to choose an existing service, but there is no ‘any’. Doing this in old UI is fine. If you create a rule in old UI you will see this rule correct in cockpit as well. FW works, too. This seems to be a missing check in cockpit only!
the choise any is mandatory for FW rules!
Why should be mandatory?
in a firewall you typically allow only what is needed first and then the last rule you will forbid everything else. There are already some other posts inside here showing rules like that
I think you are trying to use the rule in local rules. Did you try to make the rule in rules?
There you can use “any”.
Does it work if you create a TCP/UDP service object with port range 1-65535 and name it “customany” and use it for the last local rule?
Maybe a policy change could help too but I can’t find the “policies” button in new server manager…
EDIT: Found it in rules pages top right. It only appears when there are rules.
#
# 20policy_ipsec
#
$FW ivpn ACCEPT
loc ivpn ACCEPT
ivpn loc ACCEPT
ivpn $FW ACCEPT
#
# 20policy_openvpn
#
loc ovpn ACCEPT
ovpn loc ACCEPT
ovpn $FW ACCEPT
$FW ovpn ACCEPT
ovpn net ACCEPT
If the policy would reject ovpn to the firewall ($FW) then you just need to allow the services you like.
1 Like
I stopped using NethServer for this reason and went to PFsense because of it. This has to be more of a misunderstanding on how the NethServer firewall functions overall.
good point! Yes it works in rules, but not inside local rules. The rules were done a while ago in old UI and when I tried to use cockpit I discoverd the issue. So the cockpit is not fully compatible with old settings here.
So what is the difference between rules and local rules then? I found the answer inside the doc already, thanks @mrmarkuz for the link
1 Like
I did not try but I have other custom services objects created and in use. So I’m sure that this work around would be a replacment for ‘any’.
The policy change is nice, too (but can not be done in UI). Meanwhile I learned that moving my rules to local rules would do the trick, so that might be the most readable way to understand the settings later.
So the conlusion on this: One problem, several solutions possible.
But be aware that taking over FW rules created in old UI leads to a smal incompatibility in cockpit, as you can not edit rules (local) if ‘any’ was used inside the rule.
I tested changing the policy and it worked.
Create a custom template:
mkdir -p /etc/e-smith/templates-custom/etc/shorewall/policy
cp /etc/e-smith/templates/etc/shorewall/policy/20policy_openvpn /etc/e-smith/templates-custom/etc/shorewall/policy/
Edit /etc/e-smith/templates-custom/etc/shorewall/policy/20policy_openvpn and comment out the specific ACCEPT lines. In my case ovpn is not allowed to connect to the firewall ($FW) and my local network (loc) by policy.
#
# 20policy_openvpn
#
loc ovpn ACCEPT
#ovpn loc ACCEPT
#ovpn $FW ACCEPT
$FW ovpn ACCEPT
ovpn net ACCEPT
...
Apply the config with signal-event firewall-adjust
Now everything is rejected, except you explicitly allow it.
Note that there’s an OVPN object you may use for all openvpn traffic.
It’s working as local rule too:
In this case it was allowed through policy before it would have been rejected.
1 Like
nice solution, like it!
So the ‘bug’ I found is a incompatibility between old and new UI only based on changed philiosophy? Do you agree with this statement?
1 Like
I’ll wait the answer from Devs. Hoping that they will change their mind.
This is how I understand it:
You are basically right. But it’s not only some changed opinion, it has a technical background. The “any” rules made problems and overloaded the firewall.
In general Nethserver aims to be simple and easy-to-use which means to not be filled up with features nobody uses.
This is basically a good idea but as there is always evolution in IT, things change.
I think the assumption was that VPN users are just trusted which seems not true anymore for more and more Neth users.
The problem is that the workaround to use the “reject any rule” as last rule to overrule the ACCEPT policy does overload the firewall and was not intended.
Some ideas:
If the custom template works and does not affect other apps in a negative way we could think about integrating it to cockpit firewall settings maybe by adding an option “VPN to firewall/local networks”.
Another option may be to enable deletion of VPN in the trusted networks…
4 Likes
Sorry, @mrmarkuz, i don’t agree.
The simple question is: Nethserver wants to be a firewall distro or not? If the answer is yes, at least rules like IPCop were allowed too should be possible.
Again, i don’t agree. Right or not, the currently ruleset for Nethserver installation is “everything is allowed”, in and out.
If i need to allow something at certain condition, i have to put an allow rule for the conditions (better only one rule) than the “any rule” to deny the rest of the case for that rule. For a split setup (firewall and mailserver into different machines/setup) that’s the simplest and the most important:
mail server ip address is allowed to contact 25, 465, 587 ports on the internet, any other device is not
Two rules, the second one should start with a “any”. Not allowed by cockpit.
IMVHO this concept seems not firewall-distro oriented. Therefore… I think that a couple of other projects are going to be suggested as a viable option instead of NethServer.
2 Likes
First I want to say, I fully agree with you in the point that there is a missing feature in Neth firewall.
Yes, I think so.
It is basically possible with shorewall, it only depends on policy which is quite static as regards VPN at the moment so we have to improve it.
Sorry, that’s not fully correct. Default policy is that everything out is allowed, everything in is rejected.
http://docs.nethserver.org/en/v7/firewall.html#policy
You can change the “everything is allowed out” policy in firewall settings page, I posted a screenshot above, the option is “Traffic to Internet (red interface)”. So in this case (local to firewall) the thing you want is already there. It’s only missing for VPN.
This is the last policy in /etc/shorewall/policy:
# THE FOLLOWING POLICY MUST BE LAST
all all REJECT info
So it works as you like it but you have to disallow “Traffic to Internet (red interface)”.
Then the policy at the beginning of /etc/shorewall/policy is changed from
loc net ACCEPT
to
loc net REJECT
This change forces one to need to explicitly allow by rules, the rest is rejected.
See above cockpit firewall option. It makes it possible without needing the last rule.
I think it is, you just missed the policy concept that in the end does what you want and you even don’t need the last rule as it’s already there (in form of the policy).
I think that there are firewall distros with more (complex) functions or firewall-specific addons but they’re not so easy-to-use anymore.
IMO the Neth firewall is an easy-to-use, rock solid, shorewall based firewall with a nice cockpit interface that has it’s place in the firewall/gateway world.
I am a little biased as regards shorewall, for me it was a huge improvement when I discovered it some time ago.
2 Likes
Sorry this necroposting, but it’s now possible to use the any keyword as source or destination inside the firewall rules page, but it’s not still available on Local rules page.
4 Likes
The solution post should be changed into one which says: fully update the installation THEN write again the rule.