That’s not the standard for route-filtering. route-maps call objects (community-lists, access-lists, prefix-lists etc…). A route-map alone is not used for route-filtering. It’s a container to match objects. ACLs have been used for route-filtering for a very long time. Renaming it doesn’t make sense, because then you’re just pushing the confusion on to people when they want to use an ACL to filter routes.
The fix, unless I’m missing something, is to only allow established/related as the last rule in your chain and to ensure all drop rules etc are higher. That fixes the problem.
I dont agree.
Example: EOS 4.32.2F - ACLs and Route Maps - Arista
When you refer to “ACL” you normally refer to “packet filtering on an interface or VLAN” (the later would be refered to as VACL), when you say “route-filter” you specify that its a filter regarding which routes to export/import (technically prefix-list along with route-map).
This gives that the term “ACL” to not be packetfiltering when it comes to VyOS is incorrect IMHO and will cause confusion specially for netadmins who have been using other vendors before they started to use VyOS.
VyOS in this context is unique to default to a firewall with stateful packet inspection capabilities which routers/switches normally dont have.
Yeah but the performance will drop by doing so.
It would have been nice if there existed some kind of script or such who could take the current ruleset and match that against current conntrack and when identifying sessions/flows that shouldnt exist then those could be removed from the conntrack table.
Something like an SQL LEFT OUTER JOIN or such.
Perhaps this could be as a global firewall setting in VyOS if conntrack should be re-evaluated against current ruleset when firewall entries are changed. If this exists as a script this could also be runned manually (or scheduled) in op-mode to verify that no “orphan” sessions exists.
However I have no idea on how to achieve this in an efficient way unless filed as a feature request upstream towards nftables itself.
One possible way to achieve performance would be to simply dump the current ruleset along with the current conntrack table into some sqllite files and perform LEFT OUTER JOIN on that and the output would become sessions that should be removed from the conntrack table since they no longer matches any rule in the current ruleset, example: OUTER JOIN — A Gentle Introduction to SQL 0.0.1 documentation
Edit: Another probably more efficient way would be to have previous ruleset saved and compare the old with the new ruleset and any changed entries could be deleted from conntrack table using “conntrack -D” where you also match on srcip, dstip, srcport, dstport etc when needed. But this can of course be dirty if/when you got rules that relies on geoip who actually are expanded into ip-ranges in the ruleset.
From that link:
An ACL is an ordered list of rules that defines access restrictions for the entities (the control plane, or an interface) to which it is applied. ACLs are also used by route maps to select routes for redistribution into specified routing domains.
Cisco is the same way; used for both control-plane and dataplane. FRR is only control-plane, hence why you can’t apply it to an interface. This doesn’t negate the typical use case of ACLs within route-filtering, along with the power of inverse masks. It’s simply a more limited use of that object than you’d have on something like Cisco/Arista.
This gives that the term “ACL” to not be packetfiltering when it comes to VyOS is incorrect IMHO and will cause confusion specially for netadmins who have been using other vendors before they started to use VyOS.
ACLs are used both in firewall policies (for some vendors), and within route-filtering. You’ll cause confusion either way (depending on if someone comes from an Enterprise/SP background, or a security one), so it makes more sense to me to keep it the name that is so far beyond canonical, that it’s practically gospel. It’ll also cause a disconnect as it relates to the code base, since what is generated for FRR will be access-list, but have a different name for everything else on github.
But VyOS is not just FRR - with VyOS being a softwarebased router you also need ACL’s to do packetfiltering on interfaces.
FRR is the control-plane for VyOS, and FRR is the only use-case for an object with the actual name of access-list, that requires a net-id and inverse mask to configure. You don’t use an object called access-list to filter traffic on VyOS (never have). You do still use it within route-maps for routing.
access-list is not an arbitrary name in this sense, it is what is configured within FRR when you configure the object in VyOS. It’s also the term that has been used in every Vyatta derivative, other distros that uses FRR, and is also within major vendor’s implementations for route-maps.
You’re saying that people that are coming from other options will have to learn that an access-list is not used for packet filtering, which they’ll have to learn either way since you don’t use access-lists within the firewall. But you want to force people to absolutely need to remap the name of access-list in their head for route-maps (not just new users, but every existing VyOS user).
In the documentation and helpers in the CLI, it’s basically going to say “This is the same thing as an ACL and requires a net-id and inverse mask”. You’re going to have to tell people “ignore the name, this is an access-list, configure it how you’d normally configure one”.
Not really…
The top dog in VyOS is Debian (currently Bookworm 12.x) with a custom Linux kernel along with vyos-configd.
Then comes FRR to deal with routing protocols, nftables to deal with firewalling, KEA to deal with DHCP and so on.
Again, the access-list object is only called within FRR, which is the network control-plane for VyOS. It’s not called in Debian, configd, nftables, or KEA. That was the whole discussion after you saying "…it should be called route-fitlers or route-maps". I’m not sure why you’re trying to state all of the components of VyOS as a counter to FRR is the network control-plane and the only place that configuration element is called.
Beyond that, you mentioned Debian (OS), nftables (dataplane), configd (management plane), and KEA (management plane). The only component you listed that is the network control-plane is FRR, where the aforementioned access-list is applied and has what I’ve been saying throughout this discussion.
Again access-list in terms of packetfiltering on a switch/router have NOTHING to do with FRR.
The whole discussion is that ACL’s are commonly known and used as packetfilters - not as routefilters etc even if they can be used for this task aswell.