Messages

Sehe ich genauso :) . Ich benutze auch selbst keine ULAs mehr, IPv4 tuts genausogut.

weil die IPv4 höher priorisiert werden als ULA IPv6, wie bereits dargestellt.

Das war mir bisher tatsächlich neu, danke dafür!

Da gehts aber nur um die DNS Auflösung, wenn ein Name IPv6 GUA, IPV4 und IPv6 ULA hat, dann wird der Name in der Priorität aufgelöst bzw. vom Client in der Priorität benutzt.
Ist aber für DNS Infrastruktur kein Problem, DNS Server werden dem Client per IP mitgeteilt, dementsprechend ist IPv6 ULA zumindest dafür eine valide Lösung.

I would suggest some cheap N100 box with 2 network ports.

For switches, TP-Link or Mikrotik (but with swos).

This is simply unsupported in the real world. You can't have multiple default routers which advertise different SLAAC prefixes in the same LAN.

I noticed that "in the real world" but still this comes as quite the surprise to me. Because all the IPng/IPv6 fundamentals textbooks I read more than a decade ago said that is how it's supposed to work. Multihoming - solved. An arbitrary number of addresses/prefixes on every host interface plus router advertisements will just do the right thing.

So like the OP I took it as a given that this setup should "just work".

But then again at some point in time host to host IPsec was mandatory for any compliant IPv6 implementation, too ...

Yes, I tread that path, but there's a slight problem in the RFCs.

IIRC routing works like this:

- client has destination ip
- client selects gateway for that ip
  - there is more than one gateway with default route
  - those gateways are identified by link-local addresses
  - selection is pretty much random, since all are default and same metric and so on
- client selects a source address for that gateway
  - this source address selection is not guaranteed to be the right one, since routing information is not bound to addresses
- client sends packet to the gateway with the selected source ip
- gateway forwards packet, if rules allow it
- if the source address was the right one for the gateway, the same gateway receives the return packet and everything is fine
- if the source address was the one for the other gateway's network, then the other gateway receives the return packet and drops it

Worse, even if that scheme worked (which it does if the gateways in question are stateless, which firewalls are not), the routing decision is left to the client, which can not always know if the chosen gateway is right now capable of forwarding packets to the destination. This decision should be left to the gateways themselves, which necessitates the CARP solution.
But even then, you need a static ipv6 network you can configure on both firewalls, which is probably not possible using the fritzbox.

There is no good solution for this, I'm afraid. The google keyword is "ipv6 small site multihoming". There is also a candidate RFC for all the ways in which it doesn't work.

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.