Messages

Mein Rat wäre, das Präfix des primären Anschluss per SLAAC und Track Interface an die Clients geben, am sekundären Anschluss per NPTv6 outbound NAT machen.

Es gibt dafür sonst keine vernünftige Lösung, siehe auch https://blog.ipspace.net/2010/12/small-site-multihoming-in-ipv6-mission/ . Es gibt auch verschiedene RFCs und Entwürfe zu dem Thema, aber soweit ich weiß keine echte Lösung ausser NAT.

Von CWWK würde ich inzwischen abraten, die letzten zwei Geräte hatten selbst im voll funktionalen Zustand massive Mängel.

Man kann das zum Laufen bekommen, aber das Leben ist eigentlich zu kurz dazu.

CLI mainly for quick setup via copy&paste of snippets.

I dream of a direct CLI interface to the configuration like for example juniper or fortinet.

Transparent bridge is not a supported or recommended setup for opnsense - or any other router, for that matter.

It is what you do when you can not do anything else.

Ich würde noch dafür plädieren, die Anzahl der Regeln klein zu halten - meyergrus Regelwerk ist mir für so eine einfache Umgebung schon zu groß.

I also think that VRFs are not that useful in firewalls - in routers, yes, but firewalls are supposed to connect different routing contexts, not to separate them.

Not really a wizard, but I'm a big fan of being able to edit things in context, so edit or create an alias while having a firewall rule open - a good example would be the way the old Sophos UTM did it, or Fortinet does it now.

I agree that this is not the best case for a bad UI, in other firewalls you would also have to do a lot of clicking to achieve this result.

However I would like to see some UI streamlining for firewall rules and aliases.

This might best be part of a wider discussion about usability, which, in my opinion, is not necessarily the top priority in opnsense development.

I think more focus on this would be beneficial.

Ok, the way to do this by the book:

- use GUA internally to reach the internet
- use ULA (as secondary address) and/or IPv4 addresses for internal addressing, primarily if you have internal servers that need static addresses
- firewall using the above addresses you assigned. OPNsense has the functionality to support this using dynamic IPv6 address objects or interface address objects

Let me stress that NAT is not a security feature - firewalling is used for that. NAT is only relevant if there is a routing / addressing issue that can not be solved in any other way. Using reserved addresses is never a good idea - renumbering of static networks is potentially a huge hassle and you may be forced to if those addresses are used in the future.

The only reason I can see for NPTv6 is if you have a small site with dynamic IPv6 addresses that is multihomed. In that case in my opinion it is necessary to NPTv6 the secondary uplink in order to solve some problems regarding source address selection on the client.

Let me be clear that you should do none of those things.

There are solutions to these problems, but not those.

There are even problems where NPTv6 is a legitimate solution (small site multihoming, for example), but not that one.

But maybe I don't understand, so, tell me, what problem does all of that actually solve?

EDIT: If you really want to know how to do IPv6 in your local network, I would advise you to read https://forum.opnsense.org/index.php?topic=45822.0 .

There's also the Timemachines TM2000b, if you also want PTP.

Die X520 ist nur PciE 2.0, d.h. du brauchst 8 lanes, um die vernünftig zu betreiben.

Ansonsten gibt es eine breite Auswahl an verschiedenen Karten und Herstellern - persönlich mag ich Mellanox, die sind verhältnismäßig effizient (lies: kühl), und kompatibel, und es gibt sie billig auf ebay - was eher für Privatanwender ein Kriterium ist.

To a more general point - are you sure that you need a transparent bridge? We have that discussion comparably often, and it's not a recommended setup.