Stranges Problem mit OPT1 <- BRIDGE -> WAN



  • Hallo :-)

    Also ich habe bis jetzt mit M0n0 gearbeitet, aber mir gefällt pfSense deutlich besser
    und darum bin ich jetzt hier g

    Und schon gibt es ein Problem:

    Ich habe eigentlich nur vor eine gleiche Konfig wie bei einer derzeit laufenden M0n0-Installation zu machen
    nur mit einem anderen IP-Bereich:

    Also ich habe im WAN feste IPs, eine davon ist auch im WAN eingetragen als IP vom pfSense.
    (z.B. 80.120.120.2)
    Das LAN geht super, da kann ich auch nach außen ins WAN.
    Aber das OPT1 macht Probleme:
    Die Rechner dort drin haben externe IPs(z.B. 80.120.120.10), das OPT1 ist auf's
    WAN gebridged und auch unter Advanced ist "Enable filtering bridge"
    aktiviert.
    Ich habe unter den Firewall-Rules für OPT1 ein "Allow * to All BUT Lan net"
    gemacht damit OPT1 vom LAN isoliert ist aber sonst selbst überall hin kommt.

    Ich habe jetzt die ganzen Einstellungen mit denen von der M0n0-Installation
    verglichen und die sind eigentlich gleich…

    Es geht nun folgendes nicht:

    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.

    Warum können die nicht die 80.120.120.2 pingen? :-(

    Hier ist der Auszug aus den "States":
    icmp  80.120.120.2:512 <- 80.120.120.10  0:0

    Das heißt doch die Anfrage kommt schon am pfSense an... nur warum antwortet der nicht
    und lässt auch die OPT1-Rechner nicht ins Inet?

    Bei den Rules für WAN ist nur aktiv "Block private Networks" und darunter hab ich mal einen
    ICMP (für PING) auf die 80.120.120.10 durchgelassen, der kommt aber auch nicht an...
    [Anm.: Ich habe dann mal die Rule geändert und den Ping auf die IP vom pfSense (80.120.120.2)
    durchgelassen, das ging.]

    Ich wäre Euch für eine Hilfestellung sehr dankbar :-)

    Meine Version ist die RC2a…

    Vielen Dank!

    Viele Grüße,

    Chris



  • Was passiert, wenn Du die Firewallregeln für OP1 folgendermassen aufbaust:

    block any nach LAN
    pass any any

    Es 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



  • @CryoGenID:

    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



  • @CryoGenID:

    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.240

    pfSense 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


Locked