Korrektes Routing LAN -> WAN
-
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-4In 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ß