NAT Reflection ist dafür zuständig, dass eine NAT Regel nicht nur auf dem Interface verfügbar ist/greift, auf dem sie konfiguriert wird, sondern auch auf der/den anderen Seiten.Typisches Beispiel was der normale User meistens nicht versteht:Port Weiterleitung auf WAN Seite: Auf WAN Adresse / Port 80 -> weiterleiten auf LAN Webserver Port 80.Probiert man das Ganze jetzt vom Internet aus mit der externen Adresse oder der (oft der Dyn)DNS-URL, klappt das auch. Versucht man das ganze jetzt mit einem Client vom LAN aus klappt es nicht. Warum? Weil die RDR Regel von PF nur gilt, wenn das Paket VOM WAN auf die WAN Adresse ankommt. Das Paket kommt aber vom LAN über das LAN Interface in die Sense rein. Daher gilt der RDR nicht, damit auch kein Rewrite.Reflection ist jetzt die (IMHO) häßliche Ergänzung zum unschönen NAT und dafür zuständig, dass genau das trotzdem funktioniert. Also wenn vom LAN aus die externe IP/(Dyn)DNS Adresse aufgerufen wird, wird über den einen oder anderen Mechanismus sichergestellt, dass der Redirect durchgeführt wird. Entweder über zusätzliche RDR Regeln oder einen Behelfsproxy der die Verbindung umleitet.Alles nicht schön, deshalb ist für obiges Beispiel auch ein interner DNS sauberer, der einfach intern mit der LAN Adresse, extern mit der WAN Adresse auflöst und somit den Client einfach direkt verbinden lässt. Das in groben Zügen macht NAT Reflection.
Alles nicht schön, deshalb ist für obiges Beispiel auch ein interner DNS sauberer, der einfach intern mit der LAN Adresse, extern mit der WAN Adresse auflöst und somit den Client einfach direkt verbinden lässt.
Das DNS Beispiel oben bezog sich auch auf das genannte Beispiel mit dem WebServer und der Erreichbarkeit von innen - das lässt sich nicht 1:1 auf den Proxy und seine Redirection Rule beziehen. Ich bezweifle, dass hier eine DNS Einstellung helfen würde
