The upcoming 20.10 release has IPFIX NAT logging which will fill that need for most situations.

Using "BIOS" boot mode instead of "UEFI" seemed to solve the issue.
Thanks for the hints.
Stefano

Currently the only supported IPsec method is routed IPsec as described in the docs. Policy-based tunnels are something we are looking to add, but there is no ETA.

At the moment there isn't support for an IPv6 DHCP client on TNSR interfaces.

I had a chance to look at the data from Prometheus on TNSR and the nodes you'll be interested in to track load appear to be:

That's on 20.10 which will be out soon. I didn't have a 20.08 system with Prometheus handy to see if it had the same data.

@Derelict Thanks for reply.

Did you mean NPAR(NIC Partitioning)? Could you indicate the specific name of the feature which enables that one NIC presents to the OS as 4 NICs?

Or could you recommend some NICs from TNSR recommended NICs etc?

@Derelict
Ok, thank you for the feedback.
Will change the NIC's for now.

Yes, we are tracking that. It looks like there is a problem there.

@graphine thanks for reaching out. We don't have near-term plans for TNSR on ARM.

@NetFreak said in no bgp default ipv4-unicast:

4399

Thanks Joey, the original request is still on our backlog, no roadmap ETA at the moment though.

@sadekyo1712 - Thanks, look forward to your updates

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.

@audian said in TNSR for my homelab.:

@tsteine Muito obrigado por compartilhar sua experiência e os detalhes de sua jornada. Fico feliz em saber que o TNSR atendeu aos seus requisitos e está funcionando tão bem.

@tsteine Sou grato por você partilhar sua experiência e os detalhes de sua carreira. Fico alegre em saber que o TNSR compre os seus requisitos potenciais e está funcionando de forma excelente.

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.

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.

Not at the moment, it's all in an internal bug tracker. Every once in a while we revisit making that public but so far it's mostly private with internal chatter. If anything changes there, it will be in the release notes and related posts around a new release.

Thanks! I wasn't aware that I could do that without assigning an IP address etc to that interface.