Konfiguration der Rebind Schutznetzwerke in unbound für TI HSK Gateway (KIM+).

[RES217AIII]

Hallo Forum,
ich hoffe und freue mich auf eure Unterstützung.

Folgende Situation: Die LAN Schnittstelle mit der IP Adresse 192.168.115.0/24 hat eine Regel:

Erlaube
in
Quelle: any
Port: any
Ziel LAN Adresse
Port: 53 (DNS)

dann eine Regel:

Block
in
Quelle: any
Port: any
Ziel: any
Port: 53 (DNS).

Natürlich gibt es eine Regel:

Block
in
Quelle: any
Port: any
Ziel  invertiert RFC1918
Port: any

und eine Regel die Internet erlaubt:

Erlaube
in
Quelle: any
Port: any
Ziel any
Port: any.

Es wurde eine IPsec Verbindung (VTI) mit dem HSK der TI konfiguriert. Es wurde nach einem Gateway (Remote IP), Routen zu dem Gateway, eine NAT Outbond Regel zum NAT Masquierung auf die Lokale IP erstellt:

Erlaube
in
Quelle: any
Port: any
Ziel TI Netzwerk
Schnittstelle: Lokale IP
Port: any.

Auf IPsec (in der IPsec Tunnelkonfiguration wurde "Überspringe Firewall Regel") wurde eine any to any Regel erstellt:

Quelle: any
Port: any
Ziel any
Port: any.

Erst damit funktionierte die NAT Regel.

Die Auflösung der DNS erfolgt über die Kette Client > AdguardHome (53) > unbound (53530) > DNS über TLS (quad 9)
In Unbound (Port 53530) wurde eine Weiterleitung definiert für Telematik auf die Adresse des HSK Konnektors (nicht TunnelIP!!).
Der Adressbereich für CGNAT wurde im Rebind Schutznetzwerk in unbound herausgenommen, da hierunter auch der Netzwerkbereich der offenen Fachdienste fallen (100.102.0.0/15).

Hier mein Problem:
Der Client der mit KIM kommunizieren muss, wurde von der Firewall zurückgewiesen, weil, so vermute ich, in seinen Einstellungen ein lokaler DNS Server (192.168.115.1) die Verbindung zu KIM aufnahm und eine Adresse aus dem Netzwerkbereich 100.102.0.0/15 (konkret 100.102.8.6) zurückkam (Rebind Schutz).

Erst als ich Blockregel auf der LAN Schnittstelle für externe DNS deaktivierte und einen öffentliche DNS Server in dem Client händisch einstellte (9.9.9.9) gelang eine Verbindung zu KIM+.

Nun könnte man ja sagen geht doch!

Aber im Moment habe ich auf dem LAN Netzwerk jedoch die Auflösungen externer DNS Server erlaubt.
Meine Frage ist daher mit welcher eleganten Lösung ich dem Client möglich machen kann, trotz Rebind Schutz Kontakt zu KIM+ aufzunehmen (siehe Bild). Und warum funktioniert nicht das Löschen des Netzwerkes CGNAT (100.64.0.0/10) aus der Einstellung von unbound wo die Rebind Schutznetzwerke definiert sind?

Bin froh dass es soweit funktioniert. Die Feinjustierung folgt Schritt für Schritt.

[JeGr]

Block
in
Quelle: any
Port: any
Ziel  invertiert RFC1918
Port: any

Hö? Was tut das? Alles was nicht lokale Netze sind verbieten? Das wäre dann ja "fast" Internet, das macht ja keinen Sinn, wenn man danach wieder Internet erlauben will und es vorher aber verboten hat? Was soll das invertieren?

Zudem: Alles was auf LAN Seite geblockt wird würde ich SEHR empfehlen mit "Reject" zu machen, nicht mit Block, damit eine sofortige Ablehnung kommt und keine Minute oder zwei auf nen Timeout gewartet werden muss. Das verzögert Clients massiv, wenn die gegen sowas laufen.

Und: Source Any würde ich auf internen Netzen nie machen, sondern immer das entsprechende Subnet auf dem ich bin. Also in dem Fall "LAN subnet".

Meine Frage ist daher mit welcher eleganten Lösung ich dem Client möglich machen kann, trotz Rebind Schutz Kontakt zu KIM+ aufzunehmen (siehe Bild). Und warum funktioniert nicht das Löschen des Netzwerkes CGNAT (100.64.0.0/10) aus der Einstellung von unbound wo die Rebind Schutznetzwerke definiert sind?

Weil vielleicht gar nicht der Rebind Schutz das Problem ist? Schau mal in die DNS logs oder erhöhe den Log Output von Unbound um zu sehen WAS das Problem ist und gehe nicht einfach davon aus, dass es der Rebind Schutz sein muss. Das wäre ja nur dann aktiv, wenn man sowohl eine Antwort mit public IP als auch eine mit privater/geschützter bekommt und nicht einfach NUR wenn es ne interne IP wäre. Sonst würde bspw. Unbound ja auch zur Firewall IP selbst null Auskunft geben.

Ich würde raten, dass es ggf. eher daran liegt, dass Unbound kein sauberes Bein hat mit dem er zum Telematik Kram telefonieren soll. Du könntest daher mal als "Workaround" in den unbound Einstellungen das "ausgehende Interface" auf LAN stellen. Klingt kontraproduktiv, aber das zwingt Unbound eigentlich, als abgehende Adresse ne interne IP zu nutzen, die ggf. in deinem IPsec Tunnel erfasst ist und geroutet wird anstatt sich auf das VTI Netz zu binden und ggf. das dafür zu nutzen. Klappt meistens bei reinen Phase2 IPsecs sehr gut um das zu umgehen. Evtl. genügt das schon.

Cheers

[RES217AIII]

Hö? Was tut das? Alles was nicht lokale Netze sind verbieten? Das wäre dann ja "fast" Internet, das macht ja keinen Sinn, wenn man danach wieder Internet erlauben will und es vorher aber verboten hat? Was soll das invertieren?

Zudem: Alles was auf LAN Seite geblockt wird würde ich SEHR empfehlen mit "Reject" zu machen, nicht mit Block, damit eine sofortige Ablehnung kommt und keine Minute oder zwei auf nen Timeout gewartet werden muss. Das verzögert Clients massiv, wenn die gegen sowas laufen.

Und: Source Any würde ich auf internen Netzen nie machen, sondern immer das entsprechende Subnet auf dem ich bin. Also in dem Fall "LAN subnet".

Ich bin immer sehr dankbar für Verbesserungsvorschläge. Unten habe ich ein Bild von meinen Regeln auf dem LAN Netzwerk gemacht. Was kann ich besser machen?

[Patrick M. Hausen]

Und: Source Any würde ich auf internen Netzen nie machen, sondern immer das entsprechende Subnet auf dem ich bin. Also in dem Fall "LAN subnet".

Für "allow" ja. Für "deny" nein. Du willst ja auch das gehackte System blocken, das mit einer falschen Absender-Adresse als Teil eines Botnets versucht, irgendeinen Dritten zu DDoSen.

[RES217AIII]

Weil vielleicht gar nicht der Rebind Schutz das Problem ist? Schau mal in die DNS logs oder erhöhe den Log Output von Unbound um zu sehen WAS das Problem ist und gehe nicht einfach davon aus, dass es der Rebind Schutz sein muss. Das wäre ja nur dann aktiv, wenn man sowohl eine Antwort mit public IP als auch eine mit privater/geschützter bekommt und nicht einfach NUR wenn es ne interne IP wäre. Sonst würde bspw. Unbound ja auch zur Firewall IP selbst null Auskunft geben.

Ich würde raten, dass es ggf. eher daran liegt, dass Unbound kein sauberes Bein hat mit dem er zum Telematik Kram telefonieren soll. Du könntest daher mal als "Workaround" in den unbound Einstellungen das "ausgehende Interface" auf LAN stellen. Klingt kontraproduktiv, aber das zwingt Unbound eigentlich, als abgehende Adresse ne interne IP zu nutzen, die ggf. in deinem IPsec Tunnel erfasst ist und geroutet wird anstatt sich auf das VTI Netz zu binden und ggf. das dafür zu nutzen. Klappt meistens bei reinen Phase2 IPsecs sehr gut um das zu umgehen. Evtl. genügt das schon.

Vielen Dank.
Werde ich versuchen. Muss ich allerdings in einer ruhigen Minute machen um den Betrieb nicht zu sehr zu stören.