[Gelöst] NAT Problem
-
Hallo zusammen
Wir haben gestern probiert, unsere pfSense Firewall von 2.0.2 auf 2.1.4 upzugraden. Leider ging das zünftig in die Hose, so das wir schlussendlich auf einer frisch installierten Version 2.1.1 gelandet sind und die Konfig wieder eingelesen haben. Nach ein paar Anpassungen (Gateway auf dem WAN Interface gesetzt) läuft das meiste wieder. Lediglich der Zugriff auf unseren Windows Server in der DMZ, auf dem ein Citrix Secure Gateway und ein ftp Dienst läuft, funktioniert nicht.
Gemäss https://doc.pfsense.org/index.php/Port_Forward_Troubleshooting habe die NAT und Firewall Regeln nochmals gelöscht und frisch angelegt. Ohne Erfolg. Ich habe dann das Firewall log angeschaut, darin sehe ich keine Zugriffe auf den Server! In der Diagnose/Packet Capture sehe ich auch keine Zugriffe, die auf den Webserver gehen. Alles sehr seltsam!
Ich habe folgende NAT Regeln:
WAN TCP Soruce=any Sourceport=any Dest.adresse=195.65.251.220 Dest.port=443(HTTPS) NAT-IP=192.168.30.23 NAT-Port=443(HTTPS)
WAN TCP Soruce=any Sourceport=any Dest.adresse=195.65.251.220 Dest.port=21(FTP) NAT-IP=192.168.30.23 NAT-Port=21(FTP)Die dazugehörigen Firewall Regeln hat das System auch erstellt.
Ich wäre für Hilfe sehr dankbar.
Danke und Gruss
Matthias -
Hallo Matthias,
hast Du die Regeln per copy - paste in das Forum gepostet? Da sind Typos bei Source=any. Wäre vielleicht ein Grund, warum die Regeln nicht wollen :-)
Gruß
Sradag -
Hallo!
In der Diagnose/Packet Capture sehe ich auch keine Zugriffe, die auf den Webserver gehen.
WAN seitig sollten die Paket zu sehen sein, sonst wäre der Fehler nicht in der pfSense zu suchen.
Überprüfe mal, ob das DMZ Interface richtig konfiguriert ist. Netzadresse + Maske.
Aktiviere fürs Troubleshoting auch das Logging auch für die "Default blocks".
Stolpersteine sind hier auch oft die Haken bei Private networks in der Interface-Konfig.Gruß
-
Hallo Matthias,
hast Du die Regeln per copy - paste in das Forum gepostet? Da sind Typos bei Source=any. Wäre vielleicht ein Grund, warum die Regeln nicht wollen :-)
Gruß
SradagHallo Sradag
Habe die "rules" abgeschrieben, da ich nicht annahm, dass man diese irgendwie einfach copy pasten kann.
Das ist somit leider nicht das Problem, aber danke trotzdem für die Hilfe!
Gruss
Matthias -
WAN seitig sollten die Paket zu sehen sein, sonst wäre der Fehler nicht in der pfSense zu suchen.
Überprüfe mal, ob das DMZ Interface richtig konfiguriert ist. Netzadresse + Maske.
Aktiviere fürs Troubleshoting auch das Logging auch für die "Default blocks".
Stolpersteine sind hier auch oft die Haken bei Private networks in der Interface-Konfig.Gruß
Hallo
Ich mache nochmals Captures und schaue mir das an. Das mit den den Private Networks müsste der Haken im DMZ oder beim WAN Interface raus?
Danke und Gruss
Matthias -
Überprüfe mal, ob das DMZ Interface richtig konfiguriert ist. Netzadresse + Maske.
Habe das DMZ Interface überprüft. IP ist 192.168.30.1/24
Auf den Servern habe ich die Netzmaske 255.255.255.0 Sollte also passen. Ich komme übrigens ohne Probleme von allen drei DMZ Server ins Internet. Bei einem funktioniert sogar der Zugriff von aussen via http. Hat eine ähnliche NAT Regel wie die anderen zwei. -
Habe mal die NAT/Portforwarding in einen Screenshot gepackt. Es ist so, dass alles, was auf der WAN Adresse reinkommt, funktioniert. Alles was über andere offizielle IPs reinkommt, funktioniert nicht! Es ist, als ob er nicht auf diese IPs hören würde. Muss ich diese zusätzlichen offiziellen IPs irgendwo konfigurieren, damit er auf diese "hört"?
Edit: Attachment entfernt
-
Nachdem ich obigen Beitrag geschrieben habe, habe ich selber gemerkt wo das Problem ist. Er hört nicht auf die zusätzlich offiziellen IPs, abgesehen von der WAN IP. Das wird bei pfSense unter Firewall > Virtual IP konfiguriert.
Da ich keinen kompletten Restore machen konnte (gab immer Fehler). Konnte ich nur Teile der Config wieder herstellen. Leider habe ich nicht rausgefunden, bei welchem die virtualIP dabei sind. Da die Infos aber in der alten Config vorhanden waren, habe ich sie einfach nochmals erfasst und schon läufts wieder!
Falls jemand weiss, hinter welchem Restore sich die virtualIPs verstecken, immer her mit der Info.
Ansonsten besten Dank bei allen Antwortern und den interessierten.
Gruss
Matthias -
Hallo Matthias,
eigentlich sollte es kein Problem mit dem Restore eines vollständigen Backups geben. Bei dir scheint sich da aber in der alten Konfiguration wohl irgendwas eingeschlichen zu haben :/
Du schreibst auch dass du jetzt auf 2.1.1(?) bist -> Weshalb beim Neuaufsetzen dann der Rückschritt und nicht neu mit der latest stable 2.1.4?Grüße
-
Da wir nur eine Nacht hatten, das Ding wieder zum laufen zu bringen, haben wir so alle Versionen durchprobiert, auch der Rückschritt zurück auf 2.0.2. Aber auch bei dieser Version funktionierte der Restore nicht, obwohl der Backup ja daraus kam. Bei unseren verzweifelten Versuchen haben wir dann irgendwann aufgehört und standen dann halt bei 2.1.1 :)
Inzwischen sind wir aber bei 2.1.4 und haben die fehlenden virtualIPs manuell reinkonfiguriert. Wenn ich wieder ausgeschlafen bin und etwas Zeit habe, werde ich dann mal noch ein erneutes Backup und ein kompletter Restore probieren. Mal schauen obs klappt.
Für den Moment ist aber alles iO, neueste Firmware und alle Zugriffe laufen wieder.
Gruss
Matthias -
Super, immerhin ein Erfolg auch wenn die Geburt schwer war ;)
Grüße Jens
-
Da hast Du Recht, aber ich glaube Geburten sind immer hart ;D
Gruss
Matthias -
Dann setze ich noch fix den Betreff auf gelöst :)
