Can destination/source matches be made on a single firewall rule?

General questions
,
1

I fired back up the half-set-up VyOS experiment I had when I learned zones and single-use rule sets weren’t necessary anymore. I got my aliases into groups quickly, created a test rule to confirm I got a grasp on things, then moved out of the CLI into an IDE to build the whole thing.

When I had enough to cover the basics I pasted it to test, committed it but it didn’t work.

The routing table is OK, even OSPF has formed adjacencies, and I have no VRFs. It were the rules. I cleared them and started out with a broad rules targeting the [source] host I’m testing from, committed it, worked; I added the protocol to the rule, committed it, worked. I added the destination port group, committed it, couldn’t connect anymore.

I’ve no problems passing both contiguous and non-contiguous ports in a rule on other platforms, I doubt this was it but still, I removed the group trying to replace it for individual ports but it still wasn’t working.

Removing the destination, made the rule work again. Here’s the twist thought, I guessI wasn’t thinking because this rule was after every other rule, i.e; the biggest number just above the default [action] rule, so it shouldn’t had worked at all because I did create another conflicting rule.

This is VyOS v1.5 20230928 0022, BTW. Here are the rules:

Non working 
# show firewall ipv4 forward filter rule 12000
action accept
destination {
  group {
    port-group pdef_webports
  }
}
protocol tcp
  source {
    address 10.9.0.19
  }
Non working 
# show firewall ipv4 forward filter rule 12000
action accept
destination {
  port https
}
protocol tcp
source {
  address 10.9.0.19
}
Worked 
# show firewall ipv4 forward filter rule 12000
action accept
protocol tcp
source {
  address 10.9.0.19
}

Are rules limited on the fields they can match or is this some sort of a bug?

Thanks.

2

I think it was just some random cache issue, it seems okay now. I used run show config commands, double-checked I had made no mistakes, then reloaded preceeding the firewall [and a couple more sections of] rules like this:

del firewall
set firewall global-options all-ping 'enable'
set firewall group address-group def_approuter address '10.11.11.34'
…

Afterwards, I rebooted for good measure. At first it seemed a little dazed, so to speak, but in retrospect those might’ve been the DNS servers doing the root zone prefetching since they’ve been offline for more than a day — that and my 1980’s Wi-Fi Ⅵ* paired with Fedora’s Broadcom drivers for a Mac — but when I made it to a desktop it was already fast and highly performant; maxing out both my PPPoE/PON connection and the single gig ethernet to that desktop. I don’t even care for iperf3 testing.

My old firewall just under “background load”, with 3 WAN/tunnels [and bc it couldn’t VRRP] offloading LAN subnets to a switch, would be pushing 8GB of memory, whereas VyOS directly handles all 20+ dual stack subnets and the upstream interfaces without breaking 2GB, it’s actually stable on 1.35GB. I’m very impressed.






*: “The 6th”.

1 Like
3

Would help if you would post the full config as:

show config commands | strip-private

The firewall uses iptables in older VyOS and nftables in newer VyOS.

The common is that both are top-down first-match firewall engines meaning whatever rule thats ruleid lower than 12000 (the matching will be in rule order) where any of the fields matches will be the action the packet will receive (and no further rules will be examined for that packet).

This gives it works perfectly fine to match source and destination ip / port in the same rule.

Example:

default-action is drop

rule 10000 only matches on tcp action drop

rule 12000 matches on tcp + dstport https (443) action accept

And the packet is a tcp packet with dstport 443 it will be dropped due to it matched at rule 10000 and rule 12000 because of that will never be examined.