[solved] Redirect NTP mal wieder
-
@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
