Early feedback for configurable chain policy

Development
1

Hello all!

Recently I had an issue, where I mistyped an interface name when setting set firewall interfaces X in name X_in (something like set firewall interfaces eth in name eth0_in instead of set firewall interfaces eth0 in name eth0_in), which caused the entire network behind that interface to have full routable access to all other networks. I’ve tried to use interface wildcards, but with the new lexical sorting, the default-action-drop-ruleset for the wildcard gets applied before any interface-specific rulesets, so that doesn’t work anymore.

I’ve started to implement a proper configuration for this: firewall: support chain policies other than accept (WIP) · glueckself/vyos-1x@197ea70 · GitHub
Right now it’s very bare-bones (I have to build it yet!), however I wanted to ask there is any interest at all in this feature, and if there are any issues with my approach. I’m waiting on my Phorge account, before I can create a ticket there.

The main issue I currently see is the change in vyos/python/template.py. The reason I need this, is because when I set the chain policy to drop and all accept-actions only do “return”, the packet finally lands at the end of the chain where it is dropped, even if there are rules that accept the packet. But this causes a breaking change, where packets could have been accepted by the in-ruleset, but then dropped by the out-ruleset (because both get placed in the VYOS_FW_FORWARD chain, first in then out) would now be accepted without checking the out-rules. I’m not sure if this is a real issue, or if this can be resolved by placing the out-rules into the postrouting chain (but there the rules would affect packets coming from the router itself).

Please let me know if I’m on the right track, and if you have any ideas how to proceed with the out-rules

Thanks!

Kind regards,
Srdjan

3

Hi there.
There’s a task for changing accept action, which is what you actually need now: https://vyos.dev/T5096

We are currently working on a new firewall rewriting, and will help user to gain more control on firewall, and as you need, be able to define default-action in different hooks and priorities.
Also, the idea is to avoid unnecessary jumps

4

Ah, thanks for letting me know, I missed that one.

I see two possible solutions:

  • keep the behavior as-is: one idea I have for that option is to add something like action accept terminate, which would then cause a accept statement to be emitted to nft and existing configs would only have action accept and emit a return, behaving as right now.
  • match behavior of other firewalls: accept accepts for real (no further processing), just as drop does right now. This would be my preference, but as a new contributor I don’t really want to push for breaking changes unless it’s wanted by the developers/maintainers :slight_smile:

Is there any historic/technical reason that accept is converted to return?

5

This is because this code is inherited from the Vyatta project, and we needed to keep it because of backwards compatibility.
Now that all firewall was re-written to python, we have full control of the code, and more improvements and fixes are on the way.