@vesalius no they do not. RHEL can always be rebuilt from the source code that rhel MUST provide per the GPL. When centos was borged by RHEL the writing was on the wall for Centos. The other rebuilds will continue because the rhel sources will always be available. https://etc-md.com/2020/12/09/the-end-of-centos-and-my-moving-to-bsd/
TNSR provides a RESTCONF API. I'm not aware of anyone that has attempted to integrate or test the API against Openstack/Ansible, but if those tools can make RESTCONFI requests it should be possible for them to configure TNSR.
The TNSR API docs can be found here: https://docs.netgate.com/tnsr/en/latest/api/
Feel free to send more questions or update us on your progress!
The pricing from here is $500 per year for the Business Pro plan. There is no minimum/maximum speed, it's flat rate. It's not a replacement product for pfSense so your network doesn't need to be 'big enough' to benefit from it, you may use it even for the smallest networks if you wanted.
That is the kind of speed I have when one of my side it's not set with Mtu 9000, double-check that on all your machine.
I found this tuning useful for Ubuntu https://fasterdata.es.net/host-tuning/linux/
Netgate provided an example on how to integrate Snort to create an IDS back in 2018, which needs an update as TNSR has continued to evolve. From a 2018 blog:
TNSR-IDS is written in the Go programming language, allowing it to be easily compiled for a large number of OS and architectures. Details, source code, and setup instructions (including TNSR, SNORT and ERSPAN) can be found at the TNSR-IDS Project GitHub Repository(https://github.com/Netgate/TNSR_IDS). A README file is included in the repository that provides a lot of detail about the process, as well as a TNSR-Snort setup file that gives detailed installation instructions.
I'd use that as a starting point, but there may well be some architectual or setting changes that need to be tweaked to get the spice flowing.
use case I'm looking at is using tnsr for a ha perimeter firewall deployment (including destination nat port forwarding and outbound nat masquerading). so keeping the nat state table in sync between router instances definitely a concern. Can you use regular Linux Contrack to keep the tables in sync? on regular centos/ubuntu/etc you can use this: https://conntrack-tools.netfilter.org/manual.html.
Had the same issue some month ago. In some cases it can be usefull to have IP space overlapping on multiple interfaces. For example if you have a routed /24 which is bound to a loopback interfaces to prevent l3 loops while only having a smaller subnet assigned to a different interface.
22.214.171.124/24 dev lo
126.96.36.199/26 dev eth0.502
However, the developer of TNSR are aware of this, I had a evaluation meeting longer ago where I explained this issue to them.
They are geared for two very (very) different markets and there isn't likely to be huge overlap between their intended customer bases.
I'm vastly oversimplifying it but the tl;dr version is that TNSR is focused on high performance routing and VPN transit, for example, where the architecture of pfSense can't keep up. While pfSense has more flexibility with packages and firewall-type features which don't necessarily require >10GBit/s performance.