Dumme Frage vielleicht aber sicher dass das Modem richtig mit der pfSense verkabelt ist/wurde und auch der richtige Abgriff am Splitter genommen wurde? Das erinnert mich irgendwie an den Fall als ich bei Kunden ein "kaputtes" Modem anschließen sollte und es statt an DSL am ISDN Port hing - auf dem natürlich Strom anliegt! Und Strom auf Ethernetbuchsen verträgt sich nun nicht so wirklich gut… :)

Ansonsten ist das sehr suspekt, ich hatte mir hier auch für eine Teststellung ein billiges Congstar ADSL2+ Modem geschossen und direkt an die pfSense gehängt (ALIX2D3 in custom Case) mit 2.0RC1 und das funktioniert alles blendend. Liegt also definitiv nicht an pfSense auf Softwareseite zumal - wenn sie nicht bootet - pfSense schon raus ist, denn das klingt eher nach Hardware.

Grüße Grey

Könnte es einfach daran liegen dass dein DHCP, den dir Unitymedia pusht mit der gleichen IP/Maske arbeitet wie das Netz was du für DMZ vergeben hattest und nun du eine anderes Netz bekamst? Hört sich irgendwie so an :)

Ehm.. wenn du die Firewall disabled hast - was defacto auch die NAT abklemmt - wie konntest du dann überhaupt noch testen dass das Internet schnell ist? Direkt geroutet?

Aufruf von außen? Die WebGUI ist public available? Ansonsten könnte das bei der ALIX vielleicht auch etwas Streß mit der kleinen CPU sein, ich weiß nicht wie das Portal da von der Leistung reingrätscht. Wie sind denn die sonstigen Leistungsdaten wenn "nix mehr geht"? CPU, Mem, etc. geprüft mit den RRD Graphen?

Grüße Grey

An allen 3 Interfaces hängt eine DSL-Fritzbox mit PPPoE, richtig?
Ist das produktiv oder Testsetting? Ansonsten hätte ich vorgeschlagen du testest evtl. mit 2.0RC1 und lässt die pfSense selbst alle 3 PPPoEs aufbauen, damit entfällt die leidige Fritzbox und Transfernetz-Geschichte.

Wenn es eine Art "geht-geht-nicht" Effekt gibt, hört sich das nach 2 Sachen an, die mir spontan einfallen: Entweder ist eine oder mehrere der Fritzboxen nicht sauber eingewählt und wird vom LB Pool aber als up angesteuert und das Paket versackt dadurch, oder du nutzt Verbindungen, die nicht Multi-WAN fähig sind, also bspw. was, das davon ausgeht, dass du immer über die gleiche IP verbunden bist (Cookies, Tomcats, was auch immer). Dann solltest du ggf. Stickyness in Betracht ziehen, dass dein Client bei einer Verbindung auf einem WAN kleben bleibt und erst mit der nächsten Verbindung dann einen anderen WAN Link nutzt. Sonst sieht dein Zielserver deine Anfragen ständig über verschiedene Links kommen und schickt dir an diese immer wieder neue Antworten und ist verwirrt ;)

Grüße
Grey

Also bei einem bridged Setup wo bspw. OPT1 und LAN zu einem Intranet gebridged sind, funktioniert das auch mit DHCP ohne Probleme, da eine Bridge auf Layer 2 ansetzt und alles weitergibt, also auch Layer 3 Pakete wie DHCP. Zumindest bei der 2.0er pfSense die ich momentan einsetze ist das völlig OK und harmlos.

Ganz kurz zu meiner Konstellation damit vergleichbar: WAN - DSL, OPT1 an extra WLAN-AP angeschlossen, der WLAN Clients abfackelt, LAN an internen Gigabit Switch. An diesem Switch hängt dann auch der extra DHCP Server (ein Plug) der DHCP macht für alle. Geht wunderbar. Ob die pfSense in dem Setup selbst DHCP Server sein könnte - das kann ich momentan nicht sagen, denke aber dass sie auf dem Bridge Interface das durchaus abwickeln könnte.

Grey

wenn ich mit tcpdum geschaut habe auf dem hostinterface (192.168.2.1) kamen die packete von der firewall an aber schienen leer zu sein (length 0)

hat zufällig jemand ne idee wie ich das problem lösen kann

Ja die WAN ip stimmt…  ich hab mal alles was irgendwie wichtig sein könnte gescreenshotet^^
http://img5.imageshack.us/g/unbenannt1zk.jpg/

Hallo,

du must die Revocation Liste noch für den OVPN-Server aktivieren.

VPN–>OpenVPN--> Server editieren --> Unter "Peer Certificate Revocation List" deine erstellte Liste eintragen.

./Push

Ich habe das gleiche Problem.
Ich arbeite auf pfSense 1.2.3 mit installiertem Squid und SquidGuard.

Der Proxy läuft ebenfalls Transparent und funktioniert nach meinem ermessen auch.
Nur leider reagiert mein Squidguard überhaupt nicht. Ich kann mit dem Client trotzdem auf alle Seiten zugreifen.

Habe ebenfalls nach
http://doc.pfsense.org/index.php/SquidGuard_package und http://www.youtube.com/watch?v=zstq73Na7P0 installiert.

WAN: DHCP und am Router ( 192.168.178.43/24 )
LAN: eigenes Netzwerk ( 192.168.1.1/24 )
Router: ( 192.168.178.1/24 )
Client: ( 192.168.1.2/24 )

sodele,

jetzt anworte ich mir selber… der thinclient hat wohl einen Schaden im Netzwerkport  :-. Habe das Ding nun gegen nen anderen ausgetauscht und es funktioniert alles.

Auch das Update auf 2.0 ist gestern ohne Probleme aufgespielt worden. Benutze pfsense hauptsächlich als transparente firewall. Prozessorlast liegt unter 5%, allerdings hängen "nur" 3 Rechner dran...

Die ThinClients kann ich für die Aufgabe nur empfehlen: geringer Stromverbrauch, kein Lärm und diese werden immerwieder bei ibäh günstigst angeboten. Da tut es im Geldbeutel nicht weh, wenn mal einer (wie oben) etwas rumzickt...  ;D

jo ich hab hierbei leider nichts aussagekräftiges gefunden, was mir weiterhilft.
http mitloggen und dergleichen über die sufu hat mir da leider nix ausgespuckt.

aber squid proxy war ein guter ansatz.
mittlerweile ist der sysadmin eh wieder da…ich war ja nur interimsmässig dabei und der richtige sysadmin hat da auch was erwähnt von wegen "na dann werden wir eben auf nen proxy umstellen".
denke mal das wird eh das sein was du auch gemeint hast.

zum ot:
guter einwand den ich mir eh auch schon gedacht habe. aber da es gsd eh nicht mehr in meiner verantwortung liegt bin ich da fein raus :)
danke trotzdem nochmal für den hinweis :)