Messages

Du bekommst bei Amazon solche Mini-Firewalls als Barebones zwar für < 200€. Leider sind inzwischen die Preise für RAM stark gestiegen, weshalb Modelle mit RAM und SSD meist bei > 300€ landen. Der billigste 8 GByte SODIMM DDR5 kostet schon ca. 100€, eine 256 GByte SSD ca. 50€ - unter 300€ wirst Du wohl nur noch gebraucht landen.

Es gibt aber manche Modelle mit N100 (kaum langsamer), die noch DDR4 einsetzen, dann wird es etwas billiger:

https://www.amazon.de/dp/B0F5GJ2JHP
https://www.amazon.de/dp/B09F4CT8LV
https://www.amazon.de/dp/B07BL2WXB9

Ich habe auch einen mit N150 gefunden: https://www.amazon.de/dp/B0FCY3CFW7, allerdings sieht die Kühlung da schlechter aus.

Ich würde immer die Selbstaufrüstung vorziehen, weil Du dann keine No-Name-Bauteile bekommst.

Schlimm wenn es nicht die eine Lösung gibt ;-) Verstehe ich es grob richtig, dass aktuelle zwei Ansätze diskutiert werden. Der eine zielt möglichst auf IPv6 only ab und bindet IPv4 dort ein, wo nötig. Führt aber zu einer komplexeren Konfiguration.
Der andere Ansatz ist Dual-Stack, was vielleicht nicht optimal ist, jedoch einfacher zu konfigurieren/betreiben.

Welche Vorteile hat Ansatz 1 und welche Nachteile Ansatz 2?

Gibt es einen Favoriten für mein Szenario (der initiale Aufwand mal außen vor gelassen):
- HomeLab
- Feste/Dynamisch IP Adresse möglich
- Mehrere Interfaces (Consumer-Clients, Server, Kameras, Außennetzwerk)
- proxmox mit opnsense, homeassistant, nextcloud, AdGuard, etc.
- Consumer-Clients sollten von am besten nahtlos von Außen auf homeassistant, nextcloud zugreifen können
- nextcloud sollte aber auch für Dritte verfügbar sein
- Prio 1 Sicherheit, Prio 2 Stabilität und Prio 3 Maintenance

P.S. Hab mich geirrt. Die feste IP kostet 10€  und ab dem 7. Monat dann 23€/mtl.

Wenn Du ein von außen erreichbares Homelab betreiben willst wäre eine feste IP von Vorteil (aber nicht zwingend - ich habe keine, nutze nur DynDNS für IPv4 und IPv6, da full Dual Stack). Ich betreibe alle die von Dir beschriebenen Sachen wie im Howto beschrieben. Sicherheit durch Betrieb der von außen erreichbaren Services in einer separaten DMZ, außerdem in den meisten Fällen per Reverse Proxy. Falls kein HTTPS, über Port forwarding (IPv4 und IPv6). Dadurch sind nur WAN IPv4 und IPv6 exponiert. Im LAN keine ULA, nur GUA per SLAAC und IPv4 ("old style"). Konkret über RADVD und Kea DHCP mit Unbound.

Das erlaubt IPv4-only Clients (und Server - die müssen bis auf nicht-proxy-fähige Dienste ja sowieso nur IPv4 können, weil ich im Reverse Proxy eh nur IPv4 nach innen nutze).

Sicher, keine Tricksereien, kein Tayga, kein NAT66, VLANs straightforward mit IPv4/24 und IPv6/64, keine Pflege von internem DNS mit IPv6 (nur IPv4). Funktioniert auch für IPv4-Clients.

Potentielle Nachteile:

a. Geräte, die keine Privacy Extensions unterstützen, telefonieren mit Ihrer festen EUI-64 nach außen
b. old style, d.h. nicht "IPv6 first"

DS-Lite ist ein separates Thema, weil man sich dann Gedanken machen muss, wie man Dienste nach außen per IPv4 verfügbar macht, was auf Tunnellösungen hinausläuft.

@Maurice: Das hast Du aber einen ganz hübschen Stapel von Mechanismen beisammen, um "modern" zu sein. Bin gespannt auf das HOWTO dazu... ;-)

@Maurice: Klar, mit Tricks geht das. Aber 1. sind wir da wieder bei komplexen Umgehungslösungen und b. funktioniert auch das nur bedingt, siehe unten...


@Zapad: Das beweist wieder nichts. Ich streite dich nicht ab, dass Deine Clients IPv6 nutzen - und wenn sie nur ULAs haben, dann auch nur diese. Aber: sie nutzen die ULAs nicht für intra-LAN- oder (mutmaßlich) für inter-VLAN-Traffic!

Nochmal ganz simpel erklärt - mach mal einen Test: Trage eins Deiner Geräte mit IPv4 und IPv6 ULA in den DNS ein, sagen wir:

smtp.xyz -> 192.168.10.100 und fd05::100

Dann versuchst Du, auf irgendeinem IPv6-fähigen CLient den Namen aufzulösen:

#nslookup smtp.xyz
Server:        192.100.10.1
Address:        192.168.10.1#53

Non-authoritative answer:
Name:  smtp.xyz
Address: 192.168.10.100
Name:  smtp.xyz
Address: fd05::100

Fein. Und dann kontaktierst Du den Server:

#ping smtp.xyz
PING smtp.xyz (192.168.10.100) 56(84) bytes of data.
64 bytes from smtp.xyz (192.168.10.100): icmp_seq=1 ttl=64 time=0.034 ms
64 bytes from smtp.xyz (192.168.10.100): icmp_seq=2 ttl=64 time=0.034 ms
64 bytes from smtp.xyz (192.168.10.100): icmp_seq=3 ttl=64 time=0.052 ms

Wie? Wieso IPv4? Wie gesagt, das ist das Standardverhalten. IPv4 wird den ULAs vorgezogen. Wenn Du also nicht ausschließlich ULAs (und keine IPv4) im DNS-Reply zurückbekommst, wird nur die IPv4 verwendet. Den Trick, den Maurice nennt, mal außen vorgelassen - dabei würdest Du den ULA-Clients die IPv4 niemals zeigen. Das bedeutet natürlich auch, dass diese Clients niemals irgendwelche IPv4 gezeigt bekommen - Zugriff auf IPv4-only Geräte im IoT Netz (z.B. schaltbare Steckdosen) ist damit dann per DNS-Name nicht mehr drin.

Über die IPv4-only Clients müssen wir nicht diskutieren, die nehmen ohnehin nur die IPv4-Adresse. Also:

Deine ULAs nutzen im LAN nichts - sie werden schlicht ignoriert, Du kannst sie ebensogut aus dem internen DNS löschen. Du nutzt bei LAN-internem Traffic de facto ausschließlich IPv4 - zumindest, wenn Du es "normal" per DNS probierst. Die Rahmenbedingungen habe ich in den Varianten genannt.

Den einzigen Effekt, den Du erzielst, ist, dass Du im LAN GUA vermeidest und stattdessen NAT66 benötigst. Warum das nützlich ist, ist mir immer noch unklar (außer, man will IPv6-only im LAN und muss dann für Github und andere IPv4-only Websites NAT machen).

Variante 4, und die Welt ist Wwunderbar...

You cannot view this attachment.

Das erklärt nichts. Zu welcher Situation ist das eine Lösung?

a. Hast Du IPv4-only-Clients?
b. Was trägst Du im internen DNS ein? IPv4-only, ULA-only oder beides?

Wahrscheinlichster Fall:

Falls a = ja und b = beides (was dann nötig ist), werden Aufrufe der internen DNS-Bezeichnungen immer dazu führen, dass die IPv4 genutzt wird, nie die ULA. Somit bleiben die ULAs für den internen DNS wirkungslos. Stattdessen erhöhst Du die Komplexität, weil Du für den externen IPv6-Zugriff nun auch noch NAT64 benötigst. Was gewinnst Du also nochmal genau gegenüber Variante 3 durch die ULAs?

Und make no mistake: Deine Grafik aus #32 beweist lediglich, dass Deine Clients IPv6 nutzen. Ich vermute, das sind (externe) GUAs, keine ULAs - denn: interne Zugriffe müssten so zwangsläufig auf die IPv4 des Service laufen.

You could try to use Unbound to see if DNSmasq really is the culprit. Also, you can look at the firewall logs to see if the default catch all rule blocks the request.

Just as a reminder:

a. You need specific, manual rules that allow DNS requests (UDP port 53) to your firewall. There are only some services covered by automatic rules, like DHCP, but not DNS or NTP.
b. There is an initial, manual rule "allow any->any" for the first LAN interface only, that gets automatically created during first install.

Thus, if your devices are on different VLANs, this may already be an explanation (see b.). Or maybe, you deleted the initial "allow any" rule.
For good measure, I always create an "allow DNS on this firewall" as a floating rule.

...die Du brauchst, wenn das Gerät/Service auch für IPv4-only Clients genutzt werden soll. Und dann nehmen bei ULAs alle Clients die IPv4.

Sortieren wir es mal, es gibt drei Situationen:

1. Feste IPv6-Präfixe, so wie von der IETF vorgesehen. Man braucht keine ULAs, nur GUAs und IPv4-only Clients werden eben per Dual-Stack bedient (also interner DNS mit IPv4 und IPv6-Adressen bestückt). Alles ist gut - nur nicht für Hardware-Privacy-Experten, die dann auch noch ihre EUI-64 verschleiern wollen. Die Welt ist für die meisten Anderen schön.

2. Dynamische IPv6-Präfixe, aber keine Legacy-Clients: Dann kann man den internen DNS mit IPv6-only bestücken, was aber aufgrund der dynamischen Präfixe sinnvoll nur mit (festen) ULAs geht. Für Outbound IPv6 kann man zusätzlich GUAs verwenden, solange diese nicht im internen DNS auftauchen oder alternativ NAT64 machen (igitt). Ich mach' mir die Welt schön.

3. Dynamische IPv6-Präfixe und vorhandene IPv4-only Clients. Problematisch, außer mit internem IPv4 und outbound IPv6. Der interne DNS wird nur mit IPv4-Adressen gefüttert, weil das mit jedem Client geht. Andere Ansätze mit ULA usw. sind aufgrund der Priorisierung IPv4-vor-ULA unwirksam und clumsy, wie bereits dargestellt. Weil man diesen Ansatz eigentlich in allen drei Situationen fahren kann, ist das meine präferierte "Fits all"-Lösung (deswegen steht im Titel "just works"). Die Welt ist immer noch schön, aber nicht "modern".

I was not referring to the auto-generated rules. There is an initial explicit allow-any rule for the first LAN, which you can manually delete, not an auto-generated one. So, it is strange that you had to create such a rule by yourself, unless you deleted the existing one at some point.

Great tips, thanks! Yes, I am hoping to get at least 4 ports, or a mini PC with a full PCIe slot that would let me add a 4+ port Intel NIC. I'm leaning towards the latter currently, as it offers me some ability to update components as time goes on.

I would refrain from a modular PC unless it is really great with power efficiency (most are not). The dedicated firewall boxes have less unneeded components, like audio chips and stuff. Your firewall is a 24/7 device where it makes a difference if it draws 10 Watts more or less. Also, AFAIK, 4-port Intel PCIe cards have 1 Gbps only, whereas most china firewall boxes have 4x I226V with 2.5 Gbps build in.

Ja. Dann brauchst Du aber auch keine ULA - Du würdest ja nur die IPv6 der OpnSense erreichbar machen und den Rest per Reverse-Proxy oder bei sehr speziellen Anwendungen NAT64 in eine DMZ (was sowieso für exponierte Geräte und Services eine gute Übung ist).

Die anderen Geräte können auch intern ruhig GUA benutzen, die Firewall blockt ja den Zugriff von außen (abgesehen davon, dass man die internen GUAs nicht erraten oder scannen kann, selbst, wenn man den Präfix kennt - 2^64 IPs sind ein bisschen zu viel zum Raten).

Für Android-Geräte gibt es m.W. inzwischen auch die Möglichkeit der MAC Randomization und wie gesagt, die IP ist inzwischen nicht mehr das relevante Kriterium zum Erkennen eines spezifischen Geräts.

[Link 2 (eth0)]

Linux (Ubuntu 24.04.3 mit systemd-resolvectl) ja:

#resolvectl status
Global
        Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
  resolv.conf mode: stub
Current DNS Server: 192.168.10.2
      DNS Servers: 192.168.10.2
        DNS Domain: xxx yyy zzz

Link 2 (eth0)
    Current Scopes: DNS
        Protocols: +DefaultRoute -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: 192.168.10.2
      DNS Servers: 192.168.10.2 fe80::1
        DNS Domain: xxx yyy zzz


Bei iOS und Android ergibt sich die Frage praktisch nicht - mit wie vielen WLANs will man gleichzeitig verbunden sein? In meinem iPhone habe ich keine Scope-ID gesehen, für das Gateway allerdings auch nicht.

Das stimmt so nicht:

Die Scope ID wird beim Gateway auch nicht mitgegeben - geht ja auch nicht, weil der SLAAC- oder DHCP-Server die Scope ID des Clients ja nicht kennt. Der Client erzeugt sich die selbst anhand des Interfaces, wo er die Angabe herbekommt. Gerade eben probiert mit RADVD und "fe80::1" als DNS-Server. Ergebnis unter Windows:

You cannot view this attachment.

Dafür bräuchte es überhaupt keine ULA, die LL-Adresse würde ja genauso funktionieren, genauso wie für das Gateway. Mal ganz abgesehen davon, dass der DNS-Server genauso gut per IPv4 genutzt / adressiert werden könnte - aber falls sowohl IPv4 als auch IPv6 angegeben werden, ist die Frage, welcher Server dann genutzt wird, undefiniert. All das gilt für Dual-Stack.

ULAs werden normalerweise nicht wegen der Angabe des DNS-Servers, sondern in dem Bestreben genutzt, bei dynamischen IPv6 Präfixen und gewünschtem weitgehenden Verzicht auf (legacy) IPv4 eine DNS-Eintragung vornehmen zu können - weil das mit den (dynamischen) GUAs eben nicht geht. Meine Bemerkung wies lediglich darauf hin, dass genau das bei Dual-Stack trotzdem nicht funktioniert, weil IPv6 ULAs bei gleichzeitiger Verfügbarkeit von IPv4 für DNS-Einträge aufgrund der geringeren Priorisierung gar nicht genutzt werden (viele denken, IPv6 würde "immer" vorgezogen - dem ist nicht so).

Kurz gesagt: Die Verwendung von ULA wird bei dynamischen IPv6-Präfixen immer als "Lösung" angepriesen, funktioniert aber bei Dual-Stack nicht, sondern nur mit IPv6-only.

I would not recommend N1x0 boxes with only two ports:

a. those often tend use Realtek chips, unlike their 4 or more port equivalents, which mostly use Intel I226V. Also, they often are actively cooled.
b. If you want to set up VLANs, you will want to have inter-VLAN traffic at full 2.5 Gbps speed, for which you need multiple physical 2.5 Gbps (V)LAN ports. Thus, two ports will not suffice.

Probably a fake value reported because the smart API wants "something".