[SOLVED] Unterteilung Netzwerk - Sicherheitsaspekte

[Patrick M. Hausen]

Du brauchst auch im Gast-Netz so ein Portforwarding und musst dort die entsprechende Adresse der OPNsense als DNS-Server benutzen. Sonst kommen die Antworten wahrscheinlich wieder von der falschen Adresse.

tcpdump hilft ...

[meschmesch]

PortForwarding von 176.1 auf 176.2 geht (.1 ist die Carp-Adresse, .2 die statische IP). Also DNS auf 176.1 liefert die Antwort von der richtigen IP:

Code: [Select]

igb2 09:59:26.400790 IP 192.168.176.143.51683 > 192.168.176.1.53: UDP, length 25
igb2 09:59:26.401022 IP 192.168.176.1.53 > 192.168.176.143.51683: UDP, length 52

Localhost geht nicht:

Code: [Select]

igb2 10:00:25.655542 IP 192.168.176.143.3269 > 192.168.176.1.53: UDP, length 25
igb2 10:00:25.655767 IP 192.168.176.2.53 > 192.168.176.143.3269: UDP, length 52
Da kommt die Antwort von 176.2.

Wie gesagt das ist doof, weil man damit keine Synchronisation der Firewall-Regeln, NAT Regeln zwischen HA-Firewalls machen kann. 

[Patrick M. Hausen]

Und wenn Du zusätzlich die Antwortpakete mit Outbound NAT zurechtbiegst?

[meschmesch]

Funktioniert nicht, Outbound-Nat: igb2 Interface, source 176.2/32, NAT address 176.1, Source port 53.

Ergebnis ist, dass in tcpdump keine Antwort mehr auftaucht. Es gibt nur noch den request auf die 176.1, danach Schweigen bezüglich DNS.

[Patrick M. Hausen]

Blöd. Aber dann kann ich Dir mit AdGuard an der Stelle nicht helfen. Da wo ich HA habe, habe ich BIND auf 127.0.0.1 und Portforwarding CARP-TCP/UDP:53 --> 127.0.0.1:53. Das funktioniert, da kommen auch die Antworten richtig.

[meschmesch]

Also bei Dir läuft die DNS-Anfrage von BIND nach AG? Bei mir andersrum, nur eben mit unbound. Damit kann ich über unbound DOT machen.

[Patrick M. Hausen]

Nö. Bei mir läuft @work überall nur BIND und kein AdGuard. Wir bauen Websites. Meine Entwickler versichern mir, dass ein Werbeblocker zwar aus ihrer Sicht nett wäre, sie aber dummerweise Werbenetze in die Websites der Kunden einbauen und testen müssen.

BIND kann aber problemlos mit einem Upstream-Server arbeiten, daher mein Vorschlag.

Hier zuhause läuft BIND auf 127.0.0.1. Alle Interfaces, die irgendwas mit Infrastruktur machen, haben ein Portforwarding direkt zum BIND. Im Familien-Surf-and-Play-Netz lauscht der AdGuard direkt auf :53 und der forwarded dann an den BIND.
Ich hab hier privat aber auch keine HA.

Nochmal Kurzfassung: BIND funktioniert bei mir mit HA. BIND kann einen "Forwarder" == Upstream Server. Daher mein Vorschlag, das doch mal so zu testen.

[meschmesch]

  Ok, die nachfolgend beschriebene Kette ist etwas übertrieben, aber zum Testen tut's das

• Port Forward Gast Netz ...176.... Port 53 auf 127.0.0.1:53530 - drauf läuft BIND
• Bind hat als DNS Forwarder AG eingetragen, und zwar eine der CARP-Adressen .1
• AG macht Forwarding auf unbound

Ergebnis, es geht, aber laaaangsam. 2,5s Antwortzeit und mehr. Macht keinen Spaß.

[Patrick M. Hausen]

Warum hast Du da jetzt noch den Unbound im Spiel? Du hast schon einen Nameserver mit allen Features - Resolver und Authoritative - in BIND, und einen Spam-Blocker in AdGuard Home. Nimm den Unbound doch da raus - ich hab den auch nirgends.

[meschmesch]

DNS over TLS? Kann eigentlich auch Adguard selbst, stimmt.
tls://1.1.1.1:853 z.B. als Server.

Noch eine Kuriosität. Es gibt bei mir Geräte im LAN, die habe ich für die Kommunikation nach außen gesperrt (China und so...). Allerdings schaffe ich es nicht, DNS-Anfragen an AdGuard zu unterbinden. Selbst wenn ich MAC und IP explizit im LAN-Netz sperre, gehen die DNS-Anfragen an AdGuard durch.

...wobei ich gerade feststelle, dass das mit BIND kein "Problem" mehr darstellt. Weil dann nämlich in AdGuard sämtliche Anfragen als von localhost her stammend erscheinen und überhaupt keine Unterscheidung mehr möglich ist, woher welche Anfrage kam. Also Source Host Auflösung scheidet mit BIND aus?

[meschmesch]

Kurze Zusammenfassung. Unbound wird nicht verwendet. Und ich habe mich gegen BIND entschieden, da dadurch in AdGuard (AG) alle Anfragen als von localhost zu kommen scheinen. Damit habe ich keinen Überblick mehr, wer was im Netzwerk macht. Da außerdem das Problem ist, dass ich DNS-Anfragen diverser LAN-Geräte warum auch immer nicht verhindern kann, ist die Möglichkeit zumindest in AG gegeben, manuell zu sperren "Nicht zugelassene Clients".

AG hat als DNS-Server und Bootstrap:

Code: [Select]

tls://1.1.1.1:853
tls://1.0.0.1:853
tls://[2606:4700:4700::1111]:853
tls://[2606:4700:4700::1001]:853
Opnsense 1:

• Port-Forward für jedes Interface zum Umschreiben der DNS Anfragen von der CARP-Adresse auf die statische IPv4 Adresse des Interface
• Ein AdGuard-Alias für alle CARP-Adressen und die IPv4 Interface Adressen
• Port Forward für jedes Interface von allen Anfragen, welche nicht vom AdGuard-Alias stammen und nicht an den AdGuard-Alias gerichtet sind, auf die die statische IPv4 Adresse des Interface (damit wird verhindert, dass Clients AdGuard umgehen)
• Entsprechende Firewall-Regeln anlegen

Opnsense 2:
Hier dasselbe, allerdings müssen die IPv4 Interface Adressen ausgetauscht werden gegen die Interfaces von Opnsense 2.

Auf allen Opnsenses bei DHCP jeweils die Interface CARP-Adresse als DNS Server angeben. Unter General-Settings habe ich die jeweilige reale LAN-Interface-Adresse noch zusätzlich als DNS-Server hinterlegt - ansonsten funktionieren DNS-Anfragen z.b. für Updates bei der Firewall nicht, die gerade im Backup-Modus ist.

Danke nochmals an den geduldigen Support