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.

@mski your type of vnic driver is just not compatible with it.

Check this out for more info:
https://docs.netgate.com/tnsr/en/latest/vrrp/compatibility.html

Afaik VMware is also capable of the intel e1000 vnic which uses the igb driver.

Joey

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.

eg:

185.121.69.0/24 dev lo
185.121.69.0/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.

@kiokoman Thanks for your curiosity :)

You can set asymmetric PSKs in tnsr too.

Thanks for the response and the information Jim!

@nevinsm - What kind of throughput are you getting?

@tman904 said in TNSR adventures on my home network:

Thank you for posting this. This is hands down the best post around TNSR usage I've seen.

I've also really wanted to try TNSR for myself without any of the hand holding/hoops to jump through etc. Hopefully this starts a discussion to make TNSR easier for the community to access and use as a whole.

I think it would be a good idea to separate TNSR into a free home version VS enterprise support offerings at the very least.

Netgate you could always use the model that vyOS uses:
https://www.vyos.io/rolling-release/

That is to give the bleeding edge rolling release version out to the whole community for no charge. Then keep the licensing/support services etc for the stable version of what would be your TNSR codebase.

If you could implement that change to TNSR. It would really help everyone in the community embrace it.

Thanks @tman904. Good ideas for sure.

Deterministic NAT is a "CG-NAT". The design goal is to scale out against a very large number of endpoints with reduced (need for) logging. See, for example, RFC 7422.

As noted, (thought the docs could be more clear), there isn't much chance of making inbound services work on the outside interface for the interface address in deterministic NAT mode.

It could possibly work for services on the inside interfaces if the in2out node becomes an output feature on the outside interface, but that work isn't currently contemplated. If it's important to your use case, please get in-touch so we can help determine how to best proceed.

Thanks for the response! I ran the prescribed commands and got very similar numbers. In layman's terms, it looks like the answer to my questions is "an insane number" for both. ☺

I'm not employing my TNSR instance in a large enterprise or corporate network. Would be very curious to see memory and session numbers for someone who is and who has a robust number of ACLs. Thanks again for the response!

@audian no problem at all! I'm enjoying the TNSR experience and look forward to seeing the fixes and improvements you all are working on.

Nothing like that available yet and I'm not seeing anything in open feature requests either. If you are already in contact with someone from Sales/CSE, make sure they know it's a feature you'd like to see.