I am currently evaluating VyOS as a replacement for pfSense and thinking about how to organize firewall rules in different rulesets. The general idea is to have a bunch of rulesets to be used multiple times by ‘jumping’ to them. I was playing around with the ‘jump’ action, but it’s not working the way I was expecting. Since I have very limited experience with netfilter in general, I am not sure if it’s a misunderstanding on my part or a potential issue of how it is implemented in VyOS.
This is how my firewall config looks like:
interface eth8 {
in {
name stdnt-in
}
}
name floating {
default-action return
enable-default-log
rule 1 {
action accept
destination {
address 10.236.253.11
}
log enable
protocol icmp
}
}
name stdnt-in {
default-action drop
enable-default-log
rule 1 {
action jump
jump-target floating
log enable
}
}
state-policy {
established {
action accept
}
invalid {
action drop
}
related {
action accept
}
}
When testing this configuration and sending an ICMP echo request from a system behind eth8 to 10.236.253.11 (which is behind eth4), the following happens according to the logs:
the packet gets processed by ruleset stdnt-in
rule 1 lets the packet jump to ruleset floating
rule 1 of floating sets the accept action for the packet
This is where I was expecting the packet to leave filter processing and the ICMP echo request packet to being forwarded. However, the following happened:
the packet enters ruleset stdnt-in again and is being dropped due to the default action.
After taking a look at the netfilter wiki, this behaviour may be a consequence of how base chain priority works in netfilter: Configuring chains - nftables wiki
Those rulesets in VyOS are created as regular chains, however, which are explictly mentioned as a way to arrange rulesets in a tree structure: Configuring chains - nftables wiki
Thank you for your reply. Yes, I’m pinging 10.236.253.11 and can see in the logs, that rule 1 in ruleset floating is being hit and the accept action is applied. As already stated, the next thing that happens is that the packet is going through ruleset stdnt-in again and is then being dropped due to its default action.
This happens because in vyos firewall action accept is written in tables with a return action…I’ll take a look on it and if it is possible to change that.
Another option would be to introduce goto option, and in this case use such action instead of jump
I see, thank you for clearing that up. I just read up on the goto action (here: Jumping to chain - nftables wiki). According to the wiki, using goto means that a packet won’t return to the chain it was called from. If I understand this correctly, that would mean that in my example, no packet would return to ruleset stdnt-in after it was processed by rule 1 if its action would be set to goto. Is that right?
Well in that case it unfortunately wouldn’t help me in what I was trying to achieve. The goal is to configure a bunch of rulesets like floating and have them being jumped to in rules inside rulesets like stdnt-in which are themselves configured as default rulesets for interfaces in order to better organize rules. If the goto action was used, none of the later rulesets would be utilized.
So I guess in my case it would be better to do what you already proposed: Changing the way ‘accept’ netfilter rules are configured in VyOS from return to accept.
Is that something you are already looking at? If not, I’m happy to open a feature request in Phabricator.
I may be in the minority here, but my opinion is, let products do the job they were intended for and don’t try to make them do double duty. A router is a router ; let it route packets. If you need a firewall, install a firewall.
Just because one CAN do the job of another doesn’t mean it can do it as well, or as efficiently.