Stranges Problem mit OPT1 <- BRIDGE -> WAN
-
Was passiert, wenn Du die Firewallregeln für OP1 folgendermassen aufbaust:
block any nach LAN
pass any anyEs gab da einen Bug mit negierten Regeln (wir verifizieren gerade einen Lösungsansatz, wird in der nächsten Version vmtl. gelöst sein).
-
Hey, danke für Deine Antwort!
Ich habe das gleich getestet, danach war leider das Forum offline…
Aber leider muss ich Dir mitteilen: daran lag's nicht :'(
Ich muss das so schnell wie möglich zum Laufen bekommen,
denn sonst krieg ich Ärger warum ich nicht wieder M0n0 genommen
habe sondern was "anderes"...Und ich hätte doch so gerne pfSense (allein wg. der netten Pakete
die man dazu installieren kann...)...Hast Du noch ne Idee?
Also noch kurz zur HW:
Es ist ein HP-Server mit 2*2-Port Intel Pro/1000 MT Controllern...Ich denke ich werde das hier auch nochmal im engl. Teil schreiben vielleicht
gibt's da ja auch noch Ideen ;-)Viele Grüße,
Chris
-
Kannst Du mir Deine config.xml mal an holger.bauer (a) citec-ag.de mailen? Dann schaue ich mir das mal an, was da schiefgeht.
-
You've got Mail ;)
Danke dass Du Dir's mal anschaust! :)
Viele Grüße,
Chris
-
Die Rechner die im OPT1 hängen können sich gegenseitig pingen, aber NICHT
die IP vom pfSense (z.B. 80.120.120.2) (die ist bei denen als Gateway und DNS eingetragen) und
kommen daher auch nicht ins Internet.Das habe ich vollkommen überlesen. Du darfst als Gateway für die Clients hinter dem gebridgten Interface nicht die pfSense nehmen sondern den gateway der pfSense am WAN. Die pfSense ist ja für die Clients hinter dem gebridgten OPT Interface "transparent" also quasi wie ein Switch. Hier wird nicht gerouted oder genatted.
Ich habe das jetzt mal hier nachgebaut mit einem WRAP:
- Unter system>advanced filtering bridge aktiviert
- OPT1 gebridged zum WAN
- Regel am OPT1 pass any any any
- Regel am WAN pass any nach <ip von="" client="" hinter="" opt1="">port 5800 (vnc server webinterface)
OPT-Client bekam sogar DHCP vom Router vor dem WAN der pfSense.
WAN zum OPT-Client komme ich auf den VNC server, sonst wird alles geblockt.
Optclient kommt überall hin, außer zum LAN (das funktioniert sowieso nicht mit der Bridge zum WAN, brauchst Du also keine Block Regel;-). Auch auf das Webgui der pfSense z.B.Ich habe das ganze mit RC2e getestet ( siehe http://forum.pfsense.org/index.php/topic,1820.msg10603.html#msg10603 ).</ip>
-
Hey, danke für Deine Antwort!
Also ich habe das jetzt so gemacht, Gateway ist das Gateway welches auch auf dem WAN-Interface eingestellt ist, DNS-Server hab ich eingegeben…
Es geht weiterhin NICHT :'(
Ich habe langsam den Verdacht dass pfSense nicht mit 2 Intel 1000 MT-Dual-Port NICs zurechtkommt...
Ich denke ich werde heute mal testweise schnell das Ganze mit M0n0 aufsetzen und schauen ob's da geht... dann muss es ja eigentlich
auch mit pfSense gehen...Denn ich habe bei dem anderen System (welches gut läuft nur halt mit M0n0) nämlich die Einstellungen folgendermaßen:
OPT1 gebridged auf WAN
Auf den OPT1-Clients sind aber DNS und Gateway die IP-Adresse des M0n0's...
Und das geht perfekt... warum dann nicht pfSense?Naja wie gesagt ich teste das heut mal mit M0n0... schau ma mal ob's da geht g
Ich muss das halt heute zum Laufen bringen :'(
Viele Grüße und Danke an alle Helfer :-)
Chris
-
Ich denke ich werde heute mal testweise schnell das Ganze mit M0n0 aufsetzen und schauen ob's da geht… dann muss es ja eigentlich
auch mit pfSense gehen...Nein, pfSense und m0n0 sind in dieser Hinsicht total unterschiedlich, weil ganz andere Filter und Bridges benutzt werden. Wie gesagt, bei mir geht es einwandfrei. Du mußt irgendwoanders ein Problem haben. Vielleicht veralteter ARP-Cache eines Ciscorouters oder so (ist schon öfters vorgekommen, gerade mit Ciscos; Neustart des Ciscos hat es dann behoben).
-
Hey :-)
Also das hatte ich auch schon befürchtet, hab aber alle Switches die da irgendwie drinnen hängen schon neu gestartet…
Ich versuch's heute nachmittag mal mit M0n0 und wenn's da geht weiß ich es liegt nicht an der HW...
Dann können wir's nochmal mit pfSense über's WE probieren, da werden die Server grad net gebraucht...
Am Montag müsste halt alles laufen :'(
Meinste wir haben da ne Chance?
Viele Grüße,
Chris
-
Wie gesagt, bei mir funktioniert es wie es sollte. Wäre schon merkwürdig, wenn es ein Problem mit den Netzwerkkartentreibern wäre, aber man hat schon Pferde kotzen sehen und das direkt vor der Apotheke :-\
-
Also ich habe nun zum x.ten Mal pfSense neu installiert, alle updates bis rc2e eingespielt
und jetzt mal OPT1 als 192.168.x.x konfiguriert. pfSense hat dabei die 192.168.1.1
Das geht auch, d.h. die Rechner im OPT1 können jetzt die 192.168.1.1 pingen und
auch ins Netz (sie können zwei keine Rechner im Internet pingen aber das Internet
selbst geht… warum auch immer die ICMP-Pakete zurück nicht durchkommen...)
Also kann ich eine ggf. Hardwareproblematik nun endgültig ausschließen...Jetzt stellt sich halt wieder diese Brigding-Frage:
Denn ohne Bridging habe ich doch keine Chance, dass meine OPT1-Rechner eine externe
IP haben können oder?
Bsp:
WAN des pfSense: 80.xxx.152.2 /24
Gateway-Router für das WAN vom pfSense: 80.xxx.152.1
OPT1-Rechner sollen IP's haben von: 80.xxx.152.3 -> .152.240pfSense soll halt als Firewall für die OPT1-Rechner dienen, sodass von außen nur bestimmte
Ports nach innen geöffnet werden...Ich wäre über weiter konstruktive Tipps, Hilfen oder irgendwas totale resignation sehr dankbar!
Viele Grüße,
Chris
-
Sodalla, das Problem ist gelöst! :) :) :)
Hierbei geht ein gaaaaaanz großer Dank an Hoba, der es mit professionellen
Augen herausgefunden hat wo das Problem lag:Der Switch war/ist der Bösewicht!
Er war so eingestellt dass er durch port-basiertes VLAN in "3 Switche" unterteilt
wurde…
Leider hat das nicht ganz funktioniert, weswegen das "Spanning Tree Protocol"
einige Probleme hatte, den Baum aufzubauen und sich einer meiner NICs im pfSense
deaktiviert hat...Also nochmals: VIELEN Dank an hoba!
Viele Grüße,
Chris
-
Da bin ich aber froh, daß es jetzt geht :D
-
Nachtrag: Bridgestatus wird jetzt unter status>interfaces mit angezeigt. Im Falle eines Loops steht da jetzt:
Bridge (bridge0) blocking - check for ethernet loops