Gateway-Problem?
-
Hallo zusammen.
Ich bin ein absoluter Neuling im "Firewallgeschäft", also entschuldigt bitte, wenn ich essentielle Fehler begangen habe ;-)
Ich habe ein Problem mit Gateways, so scheint es mir.Zunächst das Setup:
http://imgur.com/vDb3g8r
Zwischen OPT1 und LAN funktioniert der Verkehr einwandfrei. Natürlich alles durch Regeln erlaubt, etc.
Zwischen WAN und OPT1/LAN geht gar nichts. Auf WAN habe ich eine "Any zu any" Regel erstellt, also sollte alles erlaubt sein, was überhaupt möglich ist, dennoch kann ich über pfsense->Diagnostics->ping keine pings an Adressen von OPT1 oder LAN absenden.
Deaktiviere ich das Gateway im WAN, funktioniert es einwandfrei.
Natürlich ist das nur heruntergebrochen auf ein Problem, das ich habe, im Produktionsbetrieb funktioniert noch eine handvoll anderer Dinge zwischen WAN und OPT1/LAN nicht, aber ich denke, wenn ich DIESES Problem hier gelöst bekomme, folgen die anderen nach.
Was muss ich hier machen, ich bin echt ratlos…Beste Grüße,
Kilian
-
Hi Kilian,
als aller erstes würde ich dir empfehlen deine config hier wieder raus zu löschen, denn in der config stehen auch Passwörter zum teil in Klartext drin!
Zu deinem Problem, wenn ich es richtig verstehe versuchst du von der pfsense aus, von dem WAN interface das interne Netz zu erreichen?
Ich würde im übrigen immer von einer any to any regel bei wan absehen.
Was dir vielleicht helfen könnte wenn du aus dem lokalen Netz versuchst das WAN zu testet würde ich dir das Thema NAT-taversal empfehlen.
Unter Advanced –> Fireall /NAT kannst du den NAT Modus einstellen.
Ist der Router/Gateway auch gleichzeitig die PfSense?
Wenn nicht müsstest du entweder doppeltes Nat Konfigurieren oder du bridgest das WAN einfach zu PfSense durch, dann hast du keine Probleme mit der doppelten Nat Konfiguration.
-
Hi,
danke für den Tipp mit der config ;)
Also,
bei uns ist das WAN ein kleines Netz mit 14 Hosts, in denen auch die Router liegen, welche den Weg ins Internet bereiten. Die pfsense liegt auch in diesem Netz und soll als Vermittler zwischen dem "bösen" Internet und unseren beiden internen Netzen DMZ und DMZi agieren. Das tut sie eben zwischen den beiden internen Netzen einwandfrei, auch kommen diese beiden problemlos ins Internet, nur kommt keine Kommunikation von Rechnern im WAN-Netz zu Rechnern in das interne Netz zustande. Das funktioniert nur, wenn ich im WAN das Upstream Gateway abschalte, dann haben wir allerdings kein Internet mehr.NAT funktioniert nur bedingt, so haben wir es geschafft, STMP, also Emailverkehr aufzubauen, HTTP/HTTPS Requests laufen allerdings über NAT seltsamerweise wieder gegen das Upstream-Gateway.
By the way: Die any zu any rule ist eben dadurch eingefügt, dass ich sicherstellen wollte, dass keine Regeln den Traffic blockieren. Im Moment befindet sich die Firewall auch noch in einer Testumgebung; in einer Produktivumgebung würde ich so eine Regel nicht erstellen ;)
Beste Grüße
-
Normal soll das WAN ja auch nicht nach intern kommen. Dafür gibt es ja NAT das die internen Clients schützt.
Auf dem WAN ist NAT Standardmässig aktiv daher sehen die Rechner im WAN Netzt ja die WAN IP der pfSense.
Das kann man auch abstellen wenn man Advanced outbound NAT aktiviert.Desweitern haben die PC's im WAN Netzt denn eine Route zu den Netzen hinter der PfSense bzw. was ist das Default Gateway?
Die PC's müssen ja wissen das Sie die Netze hinter der PfSense auch über diese erreichen und nicht über deren Default Gateway (außer die PfSense also das WAN interface diese ist das Default Gateway)Du siehst sind viele Fragen noch offen um dir helfen zu können ;)
-
Dafür gibt es ja NAT das die internen Clients schützt.
Sorry aber den Satz möchte ich bitte nirgends lesen und auch nicht dass den irgendjemand für bare Münze nimmt. Nichts persönlich gegen dich flix, aber der Satz ist eben grundsätzlich falsch. NAT hat im ersten Zuge nichts mit Sicherheit oder Schutz zu tun. Bitte das auch nicht so kommunizieren, denn das ist quatsch. Es gibt genügend Möglichkeiten auf Hosts zu gelangen, die hinter einem NAT Konstrukt stehen. Nur Filter/Regeln und Abtrennung durch Proxies o.ä. ist wirklich ein Schutz der Systeme.
Das aber nur OT und wie gesagt nicht böse gemeint :)
Ansonsten stimme ich Flix zu, dass das ganze viel zu undurchsichtig geschildert ist, zudem die zweite Beschreibung schon nichts mehr mit dem gemalten Bild als LAN/OPT zu tun hat, sondern plötzlich von mehreren DMZs gesprochen wird. Es wäre vielleicht sinnvoll erstmal zu klären, was wo wie warum steht und vorhanden ist, und was man erreichen möchte um dann zu klären, warum es so momentan wohl nicht funktioniert :)
Grüße
-
Stimmt Schutz ist vielleicht nicht ganz richtig zumindest wird schon mal die interne IP verschleiert was gerade in diesem Schaubild wichtig ist ob das aktiv ist oder nicht je nach dem sehe die WAN PC's ja andere IP's als die Clients im PfSensenetzt haben
-
Uahh. Und ich dachte, ich hätte es deutlich genug geschildert. Okay, ein neuer Versuch - Bild im Anhang.
LAN/DMZ und OPT1/DMZi kommen ohne Probleme ins Internet über WAN und dessen Gateway (der Router).
Rechner aus dem WAN Netz und dem Internet kommen über NAT >teilweise< an Rechner in den LAN/DMZ und OPT1/DMZi -Netzen. Hier funktioniert zB SMTP ganz famos, HTTP oder andere Ports gehen NICHT.
Außerdem kann ich aus dem WAN Netz nichts in den beiden anderen anpingen, solange das Gateway eingetragen ist.Muss ich für jede Anfrage aus dem roten Netz eine eigene NAT bauen oder kann ich hier irgendwas mit Virtuellen IPs erreichen?
Danke für eure Geduld!
Beste Grüße
-
Also wenn du aus dem Internet oder dem roten Netzsegment Geräte aus dem gelben Netz erreichen willst, warum wird dann im gelben Netz nicht mit öffentlichen IPs gearbeitet? Oder Rot & Gelb gemerged? Das ist ja ein böser Quark, wenn man auch noch public IPs hat. Warum wird dann nicht ein größeres WAN Segment bestellt und segmentiert und ein Teil rot und ein Teil gelb? warum stehen überhaupt Rechner in ROT ohne einen Filter davor?
Sorry aber so einen verstrickten Kram hab ich selten gesehen. Kein Wunder, dass das Probleme macht. Mit dem Upstream Gateway hat das aber allemal gar nichts zu tun, sondern eher an Regelsets. Klar, interne Netze grün und gelb können da toll miteinander reden. Aber sobald es raus geht ins Public Segment wird geNATtet und dann geht der Spaß los. Wenn man dann Geräte da drin erreichen will von außen (warum stehen sie dann nicht draußen mit öffentlicher IP?) muss natürlich jeder Port auf das entsprechende Gerät gemappt werden damits über die NAT wieder funktioniert. Genau deshalb war mein Kommentar im ersten Absatz "totaler Quark".
Ich würde erstmal aufräumen, was ich wo wirklich wie haben will und warum und das ganze DANN mal ordentlich aufziehen. Warum kommt bspw. die pfSense nicht einfach direkt hinter den Router, bekommt das öffentliche IP Netz geroutet (oder eben mit Virtual IPs gemappt) und vergibt dann selbst bspw. per 1:1 NAT die IPs in die Netze? Oder routet eben die IPs dahin wo sie sollen? Warum so ein doppelgemoppel mit doppelten Routern und ungesicherten Zonen? Da bin ich gerade etwas verständnislos, was das ganze überhaupt erreichen soll und warum - und hysterisch gewachsen ist kein valides Argument :)
Grüße
Jens -
Hi Jens,
vielen Dank für deine ausführliche Antwort.
Ich muss jetzt erstmal etwas ausholen, um zu erklären, warum das alles so existiert und wo ich mich jetzt im Nachhinein (und einem 'tollen' Meeting mit meinem Chef) undeutlich ausgedrückt habe.In dem Betrieb, in dem ich arbeite sind bisher nur Studenten (ich selbst bin auch einer) für die IT eingesetzt worden, neben meinem Cheffe. Einer dieser Studis hat zusammen mit meinem Chef vor x Jahren eine IPCop Firewall aufgesetzt, mit der ich nun konfrontiert wurde mit der Aufgabe "setz' das mal in pfsense um". Diese IPCop Firewall ist überladen mit doppelten Regeln und wirklich hart eingestellten Routen, virtuellen IPs und was weiß ich nicht noch was. Mich da durchzuwurschteln hat schon einiges an Arbeit und Verständnis abverlangt. Fakt ist, dass diese IPCop Firewall eine Brücke implementiert hatte, also ein NIC mit zwei hart eingegebenen IP Adressen. Das habe ich mit pfsense vergeblich zu verwirklichen versucht, ich weiß es geht, ist aber über meinem Know-How.
Nun habe ich durch Zureden beim Cheffe erwirkt, dass vormals zwei Subnetze in das 172er zusammengelegt werden, das waren die vormals zwei IPs auf einem NIC. Soweit so verwirrend.
Nun zu dem Teil, den ich unklar ausgedrückt hatte: in dem roten/WAN Netzwerk liegen KEINE anderen Server außer der FW und den Routern, die IPs, die da vergeben werden, sollen von außen angesprochen und von der Firewall an verschiedene, interne Server weitergeleitet werden.
Hier bietet sich ja nun doch eine Vergabe von virtuellen IPs auf dem WAN-Interface an, oder nicht?Musste bei dem "hysterisch gewachsen" übrigens Lachen, denn genauso ist es mit IPCop und den vorhandenen Netzen tatsächlich geschehen, ich mag es auch nicht, mein Chef ist aber gegen einen großen Aufräumrundumschlag, da viele der Server und Maschinen Produktiv-Systeme sind und "es ja alles bisher funktioniert".
Beste Grüße
Kilian -
Soweit so verwirrend.
Ohja.
in dem roten/WAN Netzwerk liegen KEINE anderen Server außer der FW und den Routern, die IPs, die da vergeben werden, sollen von außen angesprochen und von der Firewall an verschiedene, interne Server weitergeleitet werden.
Aha, damit klingt das schon viel "vernünftiger". Wenn also von außen das Netz schon so doof aufgeschaltet ist (und doof deshalb, weil man das ganze Netz auch übern Transfernet hätte routen können was wesentlich angenehmer wäre), könntest du das sehr einfach mit 1:1 NAT umsetzen, es sei denn es sollen unterschiedliche Ports einer IP auf verschiedenen Maschinen landen.
Virtuelle IPs musst du da aber nur dafür deklarieren, damit die Sense weiß, dass sie die IP selbst annehmen soll, für was anderes brauchst dus nicht. Es genügt also, die IPs als Virtual Alias anzulegen mit dem WAN Interface (und dessen IP) als Basis. Genauso könnte man es bspw. auch in einem CARP Cluster handeln, nur nicht mit dem WAN als Basis, sondern dem CARP IF.
"es ja alles bisher funktioniert".
Das ist kein Argument und genauso muss man damit umgehen. Da habe ich auch bei Kunden und Chefs schon gekämpft, denen das einzubläuen, dass "hat ja bislang alles funktioniert" keine Antwort ist. Klar, wenn ich Spucke, Klebeband und MacGyver habe, hält der Atombunker vielleicht noch ein paar Jahre durch. Will man danach aber keinen GAU wärs eben schön, wenn man das alles mal ordentlich macht, weil Klebeband eben suboptimal ist.
Da du also nicht sauber routen kannst, würde ich den Ansatz wählen, der am wenigsten "aua" ist und eben mit 1:1 NAT die externen IPs intern zuweisen und entsprechende Firewallregeln anlegen. Vorsicht dabei: NAT wird VOR Firewallregeln angelegt.
Beispiel:
- Virtual Alias anlegen für externe IP .210/28 mit Basis WAN IF (.212).
- 1:1 NAT definieren auf WAN, IP .210, interne IP bspw. 172.16.0.123
- Firewall Regel definieren mit Source Any, Destination 172.16.0.123 Port 80
-> erlaubt HTTP auf ext. IP .210, da diese erst durch den NAT Filter umgeschrieben wird auf interne IP .123 und deshalb die Firewallregel auf dem WAN auch mit der internen IP gesetzt werden muss.
Done.
Sollte so recht einfach laufen.
Grüße
-
Vielen vielen Dank für die Antwort,
inzwischen läuft das alles so, wie wir es uns vorstellen.
Wir sind da aber auf ein kleines Problem gestoßen, das wir überhaupt nicht zuordnen konnten, und zwar konnten wir auf einmal (es hat wirklich innerhalb von 10 Minuten gerappelt) kein 172.16.0.0/24 Netz aufbauen, da kam keine Kommunikation zu stande. Auch andere Netzmasken haben da nicht geholfen, nur ein Ändern auf ein anderes privates IP-Netz hat dort die Lösung gebracht.
In keinem der Interfaces war die "Blockiere private Netze"-Regel aktiv.
Pings waren erlaubt und kamen auch auf der FW an (Syslog zeigte pass), allerdings kam da nichts zurück, auch die FW selbst konnte in dem 172er Netz nicht pingen.
Natürlich habe ich dahingehend alles geprüft, ob da Unstimmigkeiten bei den Einstellungen waren, habe aber nichts gefunden.Das nur so am Rande erwähnt, vielleicht handelt es sich hier um einen Bug oder ich bin völlig blind für eine Einstellung (obwohl es mit anderen Netzen ja - ohne andere Einstellungen zu ändern - funktioniert hat).
Nochmals vielen lieben Dank!
-
Ich vermute da hat es an anderer Stelle gescheppert, das kann man aber immer schlecht kontrollieren ohne alle Einstellungen zu kennen. Wenn es jetzt läuft -> Mission Acomplished :D
-
Das Thema kann als gelöst markiert werden - Danke.
-
Hi schirikiVII,
schön das Du das Problem gelöst hast.
Du solltest trotzdem dein erstes Netz in einen privaten IP-Bereich ändern.
195.145.140.0 ist an die Telekom vergeben… ;)
http://de.wikipedia.org/wiki/Private_IP-Adresse
…und Deinen Beitrag kannst Du selbst auf gelöst setzen, indem Du auf Deinen Ausgangspost klickst und dort einfach ein gelöst ins Subject einfügst.
Gruß orcape -
195.145.140.0 ist an die Telekom vergeben… ;)
@orcape: was absolut legitim ist, wenn er einen Business Anschluß der Telekom hat und die ihm dieses Segment als fixe IP zugeteilt hat ;) Da er nirgends was zur Art des WANs geschrieben hat, kann das also durchaus stimmen :)
-
was absolut legitim ist, wenn er einen Business Anschluß der Telekom hat und die ihm dieses Segment als fixe IP zugeteilt hat
Nun dann ist seine Zeichnung aber wohl etwas incorrect.
Dann wäre die pfSense der Gateway zum Internet und nicht der vorgeschaltete Router.
Es sei denn das über den Router mehrere IP´s der Telekom angeboten werden.
Ist mir aber auch Rille, war nur als Hinweis gedacht, weil das schon oft aus Unkenntnis so gehandelt wurde.
Letztlich muss das der TE verantworten, was er da macht.
Gruß orcape -
Ist zwar ein klein wenig OT aber:
Dann wäre die pfSense der Gateway zum Internet und nicht der vorgeschaltete Router.
Warum? Wenn mir mein Provider bspw. ein kleines /29er Netz weitergibt, gibt er mir ein festes Default Gateway für mich. Dann ist das auch mein GW zum Internet. Ohne das hab ich keines ;) Oder entgeht mir da jetzt gerade dein Punkt?
Ist mir aber auch Rille, war nur als Hinweis gedacht, weil das schon oft aus Unkenntnis so gehandelt wurde.
Letztlich muss das der TE verantworten, was er da macht.War auch nicht als Kritik aufzufassen an deiner Aussage, sondern lediglich als Ergänzung und da die Ausganslage für mich "unspezifiziert" ist ;) Könnte aber auch damit zusammen hängen, dass ich eben schon von Berufswegen her größere Setups als Default habe :)
Grüße
Jens -
@orcape:
Das hast du schon richtig erkannt, die IPs bekommen wir von der T-Com.Ich kann das irgendwie leider nicht mehr bearbeiten, bietet mir nur "Quote" an. shrug
