[solved] Redirect NTP mal wieder
-
Ich habe jetzt zu den beiden Erlauben-Regeln durch die NAT-Rules noch zwei Regeln ergänzt für den Fall, dass gar kein NAT stattfindet. Das war auch bitter nötig.
Interessant bleibt für mich das Verhalten im obigen Log dennoch.
-
Ich fürchte mir fehlt der Zusammenhang in dieser Sache für ein Gesamtbild. Ich kann nur zu diesem Post Stellung nehmen, erkenne aber das Problem nicht.
@bob-dig said in Redirect NTP mal wieder:
Wenn ich nun aber das Logging auch für den oben erwähnten Block (...301) aktiviere
Verstehe ich nicht. Das Logging ist ja offenbar aktiviert, ansonsten würden wir keine Blocks dieser Regel sehen sehen.
Ich habe hier z.B. die 192.168.1.2 auf LAN, welche von mir dort komplett geblockt wird.
Wie?
Ich weiß nicht, was hinter dem Alias in der NAT-Regel steht und was der Zweck dieser ist.
Wenn du alle NTP-Requests auf den Localhost umleiten möchtest, kannst du ja "any" als Ziel (ohne invert.) verwenden.
Oder "This firewall" mit invert, allerdings benötigst du dann aber eine zusätzliche Pass-Regel, die diese Zugriffe erlaubt.Bedenke auch, dass NAT-Regeln vor Filter-Regeln abgehandelt werden und Filter-Regeln auf Interface-Gruppen vor jenen auf den zugehörigen Interfaces.
-
@viragomann said in Redirect NTP mal wieder:
Verstehe ich nicht. Das Logging ist ja offenbar aktiviert, ansonsten würden wir keine Blocks dieser Regel sehen sehen.
Das Logging für die Blocks habe ich nachträglich aktiviert, ungefähr in der Mitte des Logs.
Wenn du alle NTP-Requests auf den Localhost umleiten möchtest, kannst du ja "any" als Ziel (ohne invert.) verwenden.
So?
Das führt dann wieder zu Blocks.
Warum auch immer scheine ich die zwei nachträglichen und nun deaktivierten Zugriffsregeln auf "this Firewall" zwingend zu benötigen bzw. die NAT-Regel greift auch mit Any nicht, wenn sie quasi eh nicht nötig gewesen wäre...
-
@bob-dig said in Redirect NTP mal wieder:
Das führt dann wieder zu Blocks.
Welche Regel ist denn dafür verantwortlich?
Das müsste ja eine Floating + Quick sein.Warum auch immer scheine ich die zwei nachträglichen und nun deaktivierten Zugriffsregeln auf "this Firewall" zwingend zu benötigen.
"This Firewall" als Ziel in der Regel, ist ohnehin kein Fehler für diesen Zweck. Die oberen beiden solltest du damit eigentlich gar nicht mehr benötigen.
-
-
@viragomann said in Redirect NTP mal wieder:
"This Firewall" als Ziel in der Regel, ist ohnehin kein Fehler für diesen Zweck. Die oberen beiden solltest du damit eigentlich gar nicht mehr benötigen.
Joar, aber warum geht das nicht mit den Regeln der NAT-Rule...
-
@bob-dig said in Redirect NTP mal wieder:
Werde die Regel jetzt mal ordentlich benennen...
Wäre hilfreich.
Joar, aber warum geht das nicht mit den Regeln der NAT-Rule...
Keine Idee. Die NAT-Regel sollte als erstes angewandt werden und nachdem die jegliche Ziele auf localhost umleitet, sollte in der Folge eine Pass-Regel mit Ziel localhost passend sein.
Eben nur eine Floating Regel mit Quick würde vor diesen Regeln auf der Interface Gruppe angewandt, nicht aber eine auf dem Interfaces selbst.Eben nochmals nachgelesen, weil mich dein Thema verwirrt: Ordering of NAT and Firewall Processing
-
@viragomann Hab es umbenannt und im Log wird es dann auch so beschriftet. Ist halt besagte Regel.
Habe nun in den NAT-Regeln die automatischen Firewall Regeln deaktiviert und belasse es bei den zwei eigenen Regeln.
Ist das nun ein Bug gewesen oder doch normales Verhalten? Als Laie kann ich mir keine Meinung dazu erlauben.
Vielleicht hat ja @JeGr eine...
-
@bob-dig said in Redirect NTP mal wieder:
Hab es umbenannt und im Log wird es dann auch so beschriftet. Ist halt besagte Regel.
Im Zweifelsfall findet sich die Regel-ID auch, wenn man die Regel zum Editieren öffnet ganz unten. Ist aber übersichtliche, wenn jede einen eindeutigen Namen hat.
Ja, ob dies eine normales Verhalten ist, wüsste ich auch gerne. Gemäß der Doku sollte es aber nicht so sein, falls ich die richtig verstehe.
-
Die Regel wird vor dem NAT angewendet, also ist der Zugriff vom Client auf NTP x und nicht auf 127.0.0.1, daher der Deny.
Ich habe das so gelöst, NAT:
Regeln:
Läuft einfach sauber, weil alles was direkt zur Firewall geht landet direkt auf dem jeweiligem Int, alles was irgendwo hin gehen will, landet über NAT auch auf der der Firewall, denkt aber es hat mit seinem eigentlichem Ziel gesprochen.
Wenn ein LAN Device mich verarschen will, verarsche ich es, denn hier gibt es nur einen DNS und das ist meiner! -
@nocling said in Redirect NTP mal wieder:
Die Regel wird vor dem NAT angewendet, also ist der Zugriff vom Client auf NTP x und nicht auf 127.0.0.1, daher der Deny.
In den Docs steht es im Text halt anders...
Also mit Any in der NAT-Regel greift es bei mir schon mal nicht.
-
@bob-dig
Kann auch sein das ich mich gerade irre, denn mein Regelwerk sieht auch anders aus.
Bei einer ASA ist es jedoch so, ggf. hatte ich das verwechselt. -
@nocling Arbeitsschutzausschuss?
Irgendwie seltsam, der LAN-Portforward greift bei mir definitiv gar nicht. Hab alles Offloading deaktiviert, die Gruppe und Regeln neu erstellt, hilft alles nix. (Portforwards auf WAN gehen ohne Probleme).
-
Cisco ASA
Habe die Regen jeweils auf der LAN Group, läuft. -
@nocling said in Redirect NTP mal wieder:
Habe die Regen jeweils auf der LAN Group, läuft.
Version 2.5.2-RELEASE (amd64)?
Hab hier auch noch einen Portforward für einen VPN-Server auf 127.0.0.1, der läuft auch ohne Probleme.
Vielleicht ist Any mit ner Gruppe einfach nicht möglich. -
Ok, konnte es soweit eingrenzen, dass es bei mir ebenfalls läuft, wenn die NAT Regel !This Firewall enthält.
Das bedeutet aber auch, dass wenn die Anfrage schon auf die eigene IP abzielt, NAT nicht genutzt wird und die NAT-Firewallfreigabe nicht mehr zutrifft, also eine gesonderte Freigabe vorliegen muss.
Any, welches sich einfach hätte alles greifen sollen, hat dagegen in der NAT-Regel nicht funktioniert. Solch eine Regel gibt es aber auch nirgends in den Docs zu sehen, vermutlich also alles soweit korrekt.
-
@bob-dig said in Redirect NTP mal wieder:
Das bedeutet aber auch, dass wenn die Anfrage schon auf die eigene IP abzielt, NAT nicht genutzt wird und die NAT-Firewallfreigabe nicht mehr zutrifft, also eine gesonderte Freigabe vorliegen muss.
Ja, das hatte ich oben schon erwähnt.
Any, welches sich einfach hätte alles greifen sollen, hat dagegen in der NAT-Regel nicht funktioniert. Solch eine Regel gibt es aber auch nirgends in den Docs zu sehen, vermutlich also alles soweit korrekt.
Dazu passt ja auch das eigenartige Verhalten, dass eine NAT Forwarding Regel mit "WAN net" als Ziel nicht funktioniert (angenommen, man hat einen IP-Block und möchte alle IPs für VPN nutzen). Warum das so ist, ist mir auch schleierhaft und eine Erklärung dafür konnte ich bislang nicht finden.
Allerdings ja, es finden sich in den Docs für Forwarding von intern Beispiele mit "! This Firewall" als Ziel, aber ebenso ohne Erklärung, dass das so sein muss. -
@bob-dig said in [solved] Redirect NTP mal wieder:
In den Docs steht es im Text halt anders...
Stimmt auch nicht. Processing Order sind Aliase, NAT, Rules. Kann man leicht in der /tmp/rules.debug nachlesen was wann kommt. :)
-
@jegr said in [solved] Redirect NTP mal wieder:
@bob-dig said in [solved] Redirect NTP mal wieder:
In den Docs steht es im Text halt anders...
Stimmt auch nicht. Processing Order sind Aliase, NAT, Rules. Kann man leicht in der /tmp/rules.debug nachlesen was wann kommt. :)
Ne, keine Ahnung wo Du gerade bist aber es ging um NAT vor Regeln und das ist weiterhin so. Keine Ahnung was Du nun mit Aliase meinst.
Aber die Party ist eh vorbei. -
@bob-dig @NOCling war es unklar bzw. er meinte es andersrum, aber PF arbeitet in seinem File entsprechend top-down:
- Aliase
- Tabellen
- NAT (Forwards); BiNAT, Outbound
- Rules
- Floating
- Gruppen
- Interfaces
der Reihe nach ab. Und ja auch Aliase und Tabellen sind Entities, die im Regelwerk ne Rolle spielen. Wären die nicht zuerst eingelesen, könntet ihr sie nicht in NAT oder Regeln verwenden, daher sind sie mit aufgelistet. Und für die generelle Info ist die Party nie vorbei :P
