Firewall/ACL aliases??

gabacho4

Don't see any way to configure firewall/ACL aliases in a way that other firewall platforms, including PfSense, do. Can anyone confirm that this feature is indeed absent for the time being and, if so, is it on the list of features to incorporate later? Thanks as always!

jimp

There are ACLs to block/pass/reflect traffic passing through TNSR: https://docs.netgate.com/tnsr/en/latest/acl/index.html

You make an ACL and then apply that ACL to an interface in either the inbound or outbound direction.

The deny ACL action is like the block action on pfSense. The reflect option is similar to the default pass behavior on pfSense since it keeps state and allows return traffic. The pass action passes but doesn't account for return traffic (so similar to a Cisco ACL style pass).

A lot of the things pfSense does for you by default, like internal rules to allow outbound traffic, have to be done manually in TNSR. Eventually we may have some convenience features to help there, and more comprehensive examples in the documentation.

If there is something specific you'd like to accomplish but aren't sure how, post the details of the scenario and we can help you figure out how it might work.

Also notable is that there are Host ACLs which are not for TNSR traffic but for traffic on management interface(s) going to host OS services like ssh, the API, etc. Though how that all works is likely to change as development progresses.

gabacho4

@jimp Figured I had a good chance of hearing from you. What I'm looking to do with the aliases is be able to group a number of IP addresses so that I can apply them to the same ACL. So instead of having to make 3 permit rules for 3 devices to connect to a video NVR, I could just have an alias that comprises all three hosts, and then my ACL would just use the alias as the source. I have found this to help keep things clean and, in TNSR's case, it would save me a number of keystrokes. Does that make sense? I don't see a way to do this for the time being.

jimp

Ah, I missed the "Aliases" bit. No, those aren't there yet. But we have tested with tens of thousands of ACLs and that works fine. Not as clean, but it does work. Since you can have multiple ACLs on an interface, each ACL itself sort of acts as a means of grouping similar rules.

So you could have an ACL for all the NVR devices separate from ACLs for other items to keep them contained.

gabacho4

Great idea Jim! That's certainly a route that I can take. Hadn't considered doing that but it would keep things tight and logical. And yes, as you have said, the transition from PfSense to TNSR has certainly been a learning experience, if not a merciless beating at times. I had no idea how much was done behind the scenes in PfSense that I took for granted. I'll thank you all for holding our hands with PfSense, right after I get over the urge to strangle something. :)

jimp

Another good thing here is that you can script things against the API. So you don't need to actually maintain that stuff by hand. Have a list in a text file? Have a script parse it and make ACL rules for you.

The script can wipe out the existing ACL contents and make it again, or check the contents and add new items.

https://docs.netgate.com/tnsr/en/latest/recipes/restconf-pki-nacm/index.html

And if you look at the TNSR IDS example it touches on that kind of thing as well.

gabacho4

Yeah, I have to get smart on the API usage as well. I'm all self-taught so there's a bit of a curve to overcome but it's nothing I haven't been able to get past so far. Lots of RTFM and breaking/restoring things. ;)

jimp

It's super easy to use a RESTCONF API in Python and not too difficult in others. I don't have a Python example for writing data via the API handy but I have this one I was toying with last year for reading stats: https://github.com/jim-p/tnsr-display/blob/master/tnsr_display.py#L198 (Side note there is a video of that code in action here: https://twitter.com/NetgateUSA/status/1092826502058659842 )

gabacho4

I will certainly give it a read and a watch and look for reasons to learn and practice. Really appreciate your insight and perspective. I'm sure we'll interact again soon assuming you're ok with questions/complaints/feature requests. I'm trying to be diligent about researching before asking for help but, as you have witnessed personally, I've hit a wall a few times now.