Korrektes Routing LAN -> WAN
-
Kann man kaum etwas hinzufügen. Wichtig ist immer bei Nutzung von 80/443 von EXTERN sollte der WebUI Port sicherheitshalber umkonfiguriert werden (8443?). Ansonsten hat man im dummen Fall eines Fehlers oder nicht greifenden NATs plötzlich die pfSense UI im WAN offen und DAS will man wirklich nicht.
Zudem liefert die WebUI korrekterweise HSTS und Redirect Header aus, um von 80 -> 443 umzuleiten und den Browser dazu anzuhalten, sich IMMER mit SSL zu verbinden. Das wiederum merken sich die Browser (HSTS normalerweise ca. ein halbes Jahr) und werden dann bei einem anderen Server Alarm oder Zertifikatsfehler schlagen. Darum tut euch da den Gefallen und setzt die WebUI auf einen anderen Port, dann habt ihr mit anderen Diensten via 80/443 viel leichteres Handling und müsst auch Sicherheitsfeatures wie Rebinding Check oder ähnliches nicht abschalten.
-
Warum tust du dir das an, nachdem du ohnehin nur von intern darauf zugreifen möchtest? Du hast mehr als 64.000 weitere Ports zur Verfügung, die vermutlich weniger Probleme bereiten.
OK, dachte mir einen Port weniger zu merken wäre praktisch aber hab jetzt obwohl nur intern drauf zugegriffen werden kann umgestellt.
Dass ein internes DNS (Split-DNS) dem vorzuziehen wäre, hast du vermutlich eh schon irgendwann hier gelesen.
Wenn du das nicht möchtest, ist NAT + proxy hier die richtige Methode.Ja das mit dem Split-DNS habe ich gelesen kommt aber für mich nicht in Frage da es zu viel Arbeit wäre diese "Zonen" zu pflegen.
Du müsstest nur die Firewall-Regeln für das interne Netz entsprechend setzen, die NAT-Regeln sind eh durch NAT Reflection umgesetzt.
Das ist was mich momentan ein wenig verwirrt.
Bei meinem obrigen Print Screen habe ich ja die Firewall Regel gepostet was verhindert das ich in diesem Netzwerk in ein anderes privates Netzwerk komme.Beispiel:
Webserver: 192.168.1.X / 24
Mein Netzwerk: 192.168.0.X /24Ich komme mit dieser Regel nicht in das Webserver Netzwerk, trotzdem kann ich ohne zusätzliche Firewall Regel die Homepage die auf diesem Webserver liegt abrufen.
Liegt das daran das in meinem IP-Paket die öffentliche IP von mir steht und somit wird es nicht durch meine RFC1918 Regel geblockt.
Wenn ja, werde ich ja trotzdem durch die NAT Reflection intern weitergeleitet, bedeutet ich werde nie über das WAN Interface geleitet sondern von LAN -> LAN. Das muss Magie sein was hier pfsense macht ;D ;D -
Ich könnte mir vorstellen, dass sich das Verhalten daraus ergibt, dass in der NAT-Regel bei "Filter rule association" "pass" und ebenso NAT reflection gesetzt sind.
Damit würdest du den Traffic durchwinken, das gilt wohl auch für NAT reflection.Als Alternative kannst du eine Filter Regel erstellen lassen oder selbst eine Regel für alle Webserver erstellen.
Deine IP wird nicht geändert, solange du keine entsprechende (outbound) NAT-Regel gesetzt hast. Du greifst mit deiner internen IP aus 192.168.0.X /24 auf den Webserver zu.
-
Momentan funktioniert alles, ich würde nur gerne wissen warum ;D
Deine IP wird nicht geändert, solange du keine entsprechende (outbound) NAT-Regel gesetzt hast. Du greifst mit deiner internen IP aus 192.168.0.X /24 auf den Webserver zu.
Das meine IP nicht geändert wird ist mir bewusst, jedoch wenn ich meine Homepage abrufe, gibt mir ja der DNS Antwort wo mir sagt "www.test.com" befindet sich auf der öffentlichen IP "xxx.xxx.xxx.xxx".
Danach schicke ich ein Paket ab mit dem Ziel dieser öffentlichen IP(im IP Paket) ab und da ich nur privat IP Adressen blocke komme ich ohne Problem durch meine RFC1918 Regel.
Könnte das stimmen? -
Nein.
Habe das eben untersucht, weil ich das genaue Verhalten auch nicht kannte.NAT Reflection "NAT + proxy" stellt offenbar einen Passierschein für alle Pakete aus den internen Netzen aus. Die Kommunikation mit dem Proxy ist dann von allen Interfaces erlaubt. Die Regel, die den Traffic zulässt, heißt dann "NAT REFLECT: Allow traffic to localhost". Und Localhost, der ohnehin alles darf, greift dann auf den Zielserver zu.
Bei "pure NAT" sieht die Sache anderes aus. Hier würde deine Regel greifen.
Wie oben angemerkt, hat sich da offenbar etwas mit den Features getan, seitdem ich das verwende. Früher klappte der Zugriff mit pure NAT nur von einem anderen Interface aus, nicht am selben. "Enable automatic outbound NAT for Reflection" hat das offenbar geändert. -
Wie meinst du das mit dem Passierschein?
Alle Pakete die aus den internen Netzwerk kommen und als Ziel meine WAN Adresse hat wird weitergeleitet in das entsprechende interne Netzwerk?Bist du dir sicher wegen dem pure NAT?
Ich hatte das auch kurz an und ich bin von meinem Webserver Netzwerk nicht auf die Homepage gekommen (externe IP), dies ging erst mit NAT + proxy. -
Alles was die "NAT + proxy"-Regel abdeckt ist aus allen internen Netzen unabhängig von Filter-Regeln erlaubt.
D.h. wenn du eine "NAT + proxy"-Regel für die externe IP 1.1.1.1 und Zielport HTTP + HTTPS nach intern 192.168.25.26 HTTP + HTTPS eingerichtet hast, ist der Zugriff darauf auf allen internen Hosts über die externe IP 1.1.1.1 erlaubt. Eine Firewall-Regel verhindert das nicht.
Das ergaben jedenfalls meine Versuche.Ich habe mein NAT Reflection gestern Abend auf Pure NAT umgestellt und bei mir greifen die Webserver in der DMZ über ihren öffentlichen Hostnamen auf sich selbst zu. Bislang gab es keine Beschwerden.
Früher ging das nicht.
Hast du eine aktuelle pfSense? -
Hallo viragomann
Ich habe ja ein paar mit VLAN getrennte interne Netzwerke, welche aber noch nicht wirklich gebraucht wurden, bedeutet kaum Clients.
Gestern habe ich das grösste interne Netzwerk migriert, bei den Vor-Tests konnte ich mit NAT + proxy alles erreichen ohne Probleme, sogar das Webserver Netzwerk selbst konnte die Homepage abrufen.Als ich das Netzwerk migrierte, kamen laufend Meldungen von "Ich erreiche die Homepage nicht".
Der Client bekommt komplett zufällig keine Antwort vom Webserver, als wäre das Paket im Netzwerk verloren gegangen, beim Client sagt danach der Host nur noch "Warten auf Host Auflösung" und die Sanduhr dreht.
Klickt man jedoch sofort auf den nächsten Link kann man normal weiter arbeiten.
Da die Hauptanwendung eine Webseite ist, war der Fehler nicht gerade angenehm, ich konnte aber in der kurzen Zeit nicht herausfinden warum der Host plötzlich keine Antwort mehr bekommt, als wäre der NAT + Proxy überlastet mit so vielen Anfragen.
Leider gibt die pfsense in den Logs nicht wirklich eine Auskunft über den NAT + Proxy und die pfsense selbst war kaum ausgelastet.Ich habe mein NAT Reflection gestern Abend auf Pure NAT umgestellt und bei mir greifen die Webserver in der DMZ über ihren öffentlichen Hostnamen auf sich selbst zu. Bislang gab es keine Beschwerden.
Früher ging das nicht.
Hast du eine aktuelle pfSense?Ich habe danach auf pure NAT umgestellt und kein internes Netzwerk konnte auf die Webseite zugreifen.
-Normales NAT (Port Forward) welche von der WAN IP auf den internen Webserver weiterleitet (Port 80/443)
-Nur noch Pure NAT aktiv:
-Firwall Regeln für ein internes Netzwerk:
Mein Verdacht ist das dieser "Passierschein" bei Pure NAT nicht ausgestellt wird und die Firewall Regel mit dem Block "RFC1918" die Verbindung in das Webseiten Netzwerk verhindert.
Die Floating Regeln (quick) als Ziel Webserver(interne IP) mit dem Port 80 hat den Zugriff auf die Homepage wieder erlaubt.Die Frage ist noch, warum geht es bei dir? Kann es sein das da schon eine Firewall Regel existiert? =)
Mein einziges Problem ist, das ich bei PureNAT nicht vom Webserver Netzwerk auf die Webseite komme.
Hast du oder jemand noch eine Idee?Gruss DarkMasta
-
Hallo,
wenn du das Netzwerk migrierst achte darauf, dass du auch die Firewall-Regeln entsprechend anpasst.
Ich habe letzte Woche auch meine DMZ migriert (ging auf ein VLAN und damit auf ein anderes Interface), da gab es noch einen Haufen Arbeit an den Firewall-Regeln.Mein Verdacht ist das dieser "Passierschein" bei Pure NAT nicht ausgestellt wird und die Firewall Regel mit dem Block "RFC1918" die Verbindung in das Webseiten Netzwerk verhindert.
Die Floating Regeln (quick) als Ziel Webserver(interne IP) mit dem Port 80 hat den Zugriff auf die Homepage wieder erlaubt.Das hätte eigentlich der Kern meine Aussage sein sollen:
NAT + Proxy erlaubt gleichzeitig den Zugriff auf das jeweilige Ziel der NAT-Regel, es übergeht damit auch Firewall-Regeln wie deine RFC 1918 Block-Regel.
pure NAT erfordert auch Firewall-Regeln, die die Zugriffe aus den internen Netzen erlauben.Die Frage ist noch, warum geht es bei dir? Kann es sein das da schon eine Firewall Regel existiert? =)
Ja, ich habe eine Floating Regel, die aus den meisten internen Netzen Zugriff auf 80 u. 443 nach überall erlaubt.
Mein einziges Problem ist, das ich bei PureNAT nicht vom Webserver Netzwerk auf die Webseite komme.
Hast du oder jemand noch eine Idee?Dir fehlt aber auch die nötige Regel, oder? An dem Screenshot des TESTNETZINT kann ich keine solche erkennen.
Grüße
-
Hallo Zusammen
wenn du das Netzwerk migrierst achte darauf, dass du auch die Firewall-Regeln entsprechend anpasst.
Ja die Firewall Regeln waren ein Horror, wollte es so einfach wie möglich, sind aber jetzt trotzdem einige Regeln zusammen gekommen ;D
Ich habe auch eine Floating Regeln für den Webserver, daher ist unter dem TESTNETZINT keine aufgelistet.
Wie hast du es geschafft das du im Webserver Netzwerk auf den Webserver kommst bzw. die Homepage?
Bei mir klappt es aus jedem Netzwerk nur nie aus dem Netzwerk wo der Server selbst steht.Wenn ich Wireshark starte habe ich pro Sekunde zwischen 15-25 VRRP Pakete, ist das für die pfsense CARP Geschichte normal?
Unter Virtual IP habe ich die Advertising frequency auf standardmäßig 1, müsste ich da nich pro Sekunde 1 Paket haben?
Da es ja Multicast Pakete sind habe ich diese Belastung auf jedem Switch und das in jedem VLAN.Seit der Umstellung habe ich kaum noch Kontrolle über meine Netgear Switchs, da das ganze GUI der Switches sehr langsam oder nicht mehr ansprechbar ist, selbst Ping Anfragen an den Switch sind zwischen 3ms - 1000ms oder fehlen komplett.
Andere Geräte im Netzwerk haben dieses Problem nicht, daher mein Verdacht das es an diesem VRRP Multicast liegt.Bräuchte dringend Hilfe…
-
Wie hast du es geschafft das du im Webserver Netzwerk auf den Webserver kommst bzw. die Homepage?
Bei mir klappt es aus jedem Netzwerk nur nie aus dem Netzwerk wo der Server selbst steht.Mit NAT Reflection "Pure NAT" und einer Filter-Regel am DMZ-Interface, die den Zugriff erlaubt, klappt das bei mir wunderbar. Bedenke, dass die Webserver auch Zugriff aufs DNS haben müssen.
Wenn ich mir das im Packet Capture anschaue, gehen die Request-Pakete an die Öffentliche IP und die Responses kommen von dieser.
In System > Advanced > Firewall & NAT habe ich auch die Option "Enable automatic outbound NAT for Reflection" gesetzt, mglw. entscheidend.
Wenn ich Wireshark starte habe ich pro Sekunde zwischen 15-25 VRRP Pakete, ist das für die pfsense CARP Geschichte normal?
Unter Virtual IP habe ich die Advertising frequency auf standardmäßig 1, müsste ich da nich pro Sekunde 1 Paket haben?Ich habe mit derselben Advertising frequency Einstellung tatsächlich 1 Paket je Sekunde und vInterface. Jedenfalls laut Packet Capture in pfSense am jeweiligen Interface.
Leider keine Ahnung, was da bei dir schief läuft. Allerdings kann ich mir auch nicht vorstellen, dass wenige 100 VRRP Pakete je Sekunde den Switch überlasten.
-
Da bin ich bei Virago, ein paar Pakete pro Sekunde müssen für einen Switch einfachste Übung sein. Wenn ich Gigabit pro Sekunde übertrage dann habe ich pps Werte die garantiert höher als 100-200 Paketchen liegen :)
-
In System > Advanced > Firewall & NAT habe ich auch die Option "Enable automatic outbound NAT for Reflection" gesetzt, mglw. entscheidend.
Ich Hornochse habe diese Einstellung in der Hitze des Gefechts mit dem NAT + Proxy auch gleicht entfernt, daher kam ich nicht mehr vom Webserver Netzwerk auf die Homepage ;D ;D
Ja Packet Capture auf der Pfsense habe ich ebenfalls 1 Paket am jeweiligen Interface, nur als Client werde ich geflooded.
Ich bin auch noch nicht ganz sicher ob das Problem mit VRRP und Switch zusammenhangen.
Habt Ihr auch als Client nur 1 Paket pro Sekunde? -
Was meinst du mit "als Client"?
Bei mir sind 2 pfSense Boxen im CARP Setup, der Master schickt die VRRP Paket auf eine Multicast-Adresse, die Backup (wäre für mich hier der Client) empfangt diese Pakete am jeweiligen Interface, und natürlich auch alle anderen Hosts im Subnetz. Ja, da habe ich auch 1 Paket pro Sekunde.Wo sniffst du das? Am Switch über einen Monitoring Port?
Siehst du da etwa die VRRP-Pakete aller VLANs zusammen? Schau auf die Source-IPs.Ich würde nicht erkennen, dass mein alter Netgear Switch mit den VLANs nun anders reagiert.
-
Die Ergebnisse sind so verwirrend.
Source IP ist immer die Master Firewall und als Ziel die Multicast Adresse 224.0.0.18.
Die Pakete sind aber immer vom richtigen Netzwerk, ich sehe also keine Multicast Pakete von anderen VLANs.Packet Capture auf pfsense Backup Firewall:
3 VRRP Pakete pro SekundeWireshark auf divs. Clients in verschiedenen Netzwerken:
16-24 VRRP Pakete pro SekundeIch habe zwei pfsense Server mit 2 Intel Karten, übergreifend eine LACP Lagg mit jeweils 2 Ports pro Karte.
Auf dieser Lagg sind alle internen VLANs definiert.
Auf der Gegenstelle sind 2 Netgear Switches im Stack, jede pfsense hat ihren Lagg über die beiden Switches.
pfsense1: Switch 1 Port 1-2 und Switch 2 Port 1-2
pfsense2: Switch 1 Port 3-4 und Switch 2 Port 3-4
In den Logs von den Switches oder pfsense steht kein Fehler, es würde angeblich alles super laufen =)
-
Naja super laufen ist relativ. Was sagt denn, dass es Probleme gibt? Dass die Switche langsam sind? Oder welches Fehlerbild gibt es noch?
Andere Frage: Können die Switche überhaupt ein LAG über zwei Units verkraften? Viele Switche können das per se nämlich nicht, da gibt es Probleme oder Fehler, dort funktionieren nur Bonds auf der gleichen Backplane sauber! Da du hier aber über 2 Switche gestreut hast, würde ich ggf. da ansetzen.Gruß
