Messages

Ich kann bestätigen, dass der Beelink EQ12 nicht leise ist. Bei mir egal, weil im Keller.

Unbound würde ich nicht ersetzen.
Zenarmor + adguard - warum nicht.

Ansonsten, so eine Firewall und Netzdesign Best Practices Dokumentation gibt es meines Wissens nach nicht, es wäre aber mal spannend, zu sehen, was jeder einzelne so davon denkt.

I also don't see the point. If you need obfuscated internet access for legitimate reasons, you'd better use TOR.

Just fyi:

https://docs.opnsense.org/vendor/deciso/opnwaf.html

It's almost the same apache configuration and web application features as in UTM, and we support it fully in business support (if you ever need it).

If you want to stay mostly in community scope HA proxy is also fine.

For that to be useful, it would need to be capable of binding to a specific IP:port of the device, not only a port on all IPs.

We've had terrible experiences with professional Netgear switches regarding port speeds and compatibilities.

Even if it works, for the homeuser Netgear switches the interface is terrible.

Any chance you remember the exact models ?

That was some 24 Port I believe 10G model.

It's one of their weirdest products ever :
- € 200 for the Switch
- € 90 for the adapter

If you can get by with a PoE injector as Patrick suggested, then the non-PoE version of the same switch is the better deal.  But at that point the Mikrotik with its 8x 2.5GbE ports is practically begging, even with the fan.

And add to that Netgear and HPE switches.

I haven't tried the professional Netgear switches and I do expect better of them, but I had a terrible experience with a cheaper Netgear smart switch and had to return it.  It was leaking RAs across the VLANs.

We've had terrible experiences with professional Netgear switches regarding port speeds and compatibilities. Even if it works, for the homeuser Netgear switches the interface is terrible.

HPE Aruba might be on the expensive side.

Ich habe für NAT64 noch nie einen guten Nutzen gefunden.

Interne v4 only Server werden bei mir per reverse Proxy erreicht.

Ja, aber, die einzige Situation, wo das typischerweise relevant ist, ist im DNS Fall, wenn es für einen Namen Einträge für all diese Adresstypen gibt.

Es ist doch insgesamt relevant wenn mit ULAs gearbeitet wird? Wenn ein interner Dienst (DNS, sonst irgendeiner) eine ULA und eine IPv4 hat, wird der IP-Stack des anfragenden Clients beim Neuaufbau der Verbindung den Aufbau über IPv4 bevorzugen.
Für ausgehende Verbindungen in das Internet. Der Client wird bei AAAA und A Records die IPv4 des Zielsystems benutzen. Wenn jetzt der Server im Internet nur einen AAAA Record hat, wird der Client mit seiner ULA bis zum DefaultGateway kommen....

Wenn intern Wenn man also mit ULA's arbeitet um das Problem mit dynamischen Prefixen zu umgehen, muss man halt entsprechend aufpassen. Andersherum kann man aber von der externen öffentlichen IPv6 auf die interne ULA NAT machen. Der IP-Stack wechselt die IP Variante nicht.

Das Szenario mit den mehreren Adresstypen gibt es halt normalerweise nur bei DNS.

Intern ULA only mit NAT halte ich für keine gute Idee, da ist es besser, ULA und GUA zu kombinieren, auch wenn die GUAs dynamisch sind.

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.

Ich will ja garnicht unbedingt klugscheißern, aber Nö. Wie meyergru auch schon schrieb, geht es um die grundsätzliche Priorisierung der Nutzung der entrsprechenden IP-Adresse durch den Netzwerkstack. IPv6 > IPv4 > IPv6 ULA. Das wirkt sich dann natürlich auf die Nutzung der vom DNS-Server zurückgelieferten IP aus.Diese wird vom Stack dann in der Priorität genutzt. Das gilt, wenn der Client sowohl ULA, GUA und IPv4 hat,auch für die IP-Adresse des DNS-Servers und damit für die Namensauflösung.
Der DNS-Infrastruktur ist das egal, ja.

Ja, aber, die einzige Situation, wo das typischerweise relevant ist, ist im DNS Fall, wenn es für einen Namen Einträge für all diese Adresstypen gibt.

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.