Noch sinnvoller wäre, dass man einfach zu jeder Statusänderung eine Info bekommt - und zwar genau eine. OK, zu einem Fehler ohne Statusänderung könnte man auch gerne 1 pro Stunde (so als Erinnerung) senden. Aber keinesfalls 100 in 2 Minuten zum gleichen Vorfall. :-)

GW Group keiner Firewall Rule zugeordnet habe, macht sie Failover. Also nach meiner Logik macht sie dann gar nichts :D Denn wenn du sie nirgends einbaust, wird sie per se auch nix tun :) Wüsste nicht, dass das - außer für die GWGroup dann überhaupt irgend eine Rolle spielt. Wenn Leitung 1 wegfällt kann es schlicht deshalb sein, dass es kein GW1 mehr gibt und dann das Default GW automatisch GW2 ist. Ich wüsste jetzt nicht, dass da die GWGroup einen Anteil dran hat? Aber anyway ;) Ja LB wird gemacht wenn man das Gateway zuweist. Deshalb ja auch 3 Gruppen für deinen Fall: FO_WAN1 - GW1 T1, GW2 T2 FO_WAN2 - GW2 T1, GW1 T1 LB_WAN12 - FO_WAN1 T1, FO_WAN2 T1 um das mal so abzukürzen. Und damit sollte dein Szenario auch klappen. Grüße

Alternativ zum Debugging: VPN Port auf was ganz Fremdes umstellen bzw. einen zweiten Server zum Test aufsetzen damit man hin und herschalten kann. Mir schwirrt auch noch was im Kopf rum, dass die Telejungs mal VPN gebremst/geblockt hatten in irgendeiner Situation, aber egal ob oder nicht, evtl hilft da schon ein anderer Port oder eben mal zum Test tcp/443.

Sorry, da muss ich meine 2 Cent dazuwerfen ;) pfsense WAN (lass den DHCP Client am Besten an) –> Fritzbox Fritzbox weist der pfSene eine IP... Gruselig. Wenn man Router kaskadiert dann spielt man hier nicht mit DHCP. Das ist unnötig fehleranfällig und in dem Fall völlig egal ob es selten/kaum passieren kann oder nicht, es kann passieren und sollte daher schlichtweg vermieden werden. Es gibt kein Problem der pfSense schlicht auf dem WAN statisch die 192.168.178.2 zu verpassen und der FB zu sagen, dass ihr DHCP Bereich erst ab 10 oder 100 anfängt. Damit hat man alle Probleme vermieden und kann auch ohne Drama gleich den exposed Host auf die .2 setzen. Und ja ich hatte deshalb schon Drama weil eben nach einem Update der pfSense und Reboot die sense nicht mehr die .2 sondern die .3 von der FB bekommen hat. Und jetzt debugge man das Problem mal, wenn das ein Remote Standort ist. Ja sicher, mit MAC Reservierung wärs nicht passiert etc. etc. - doch, weil der Kunde auch gern mal schnell die ganze Box vor Ort austauscht (pfSense) - da wird dann zuerst Update auf neuer Box + Konfig eingespielt und dann die Box einfach schnell rundgetauscht. Dann müsste er jedes Mal wieder auf der Fritzbox das Mapping ändern... Auf der FB das static mapping zu konfigurieren geht genauso schnell wie DHCP Bereich ändern, exposed Host muss eh eingerichtet werden. Die pfSense kann aber wesentlich schneller booten und ist im Fehler/Down-Fall der Fritzbox trotzdem sofort da und hängt nicht in einem unnötigen Interface DHCP Timeout herum bis sie weiterbootet weil sie keine Adresse bekommt. Ich verstehe hier wirklich komplett den Sinn nicht, warum man unbedingt auf der pfSense WAN Seite DHCP haben will, wenn das "WAN" im eigenen Haus steht und eine private Adresse hat. Das ist einfach unnötig fehleranfällig. ;) Variante b) selektives weiterleiten, z.B. 443 für VPN Vorteil: "sicherer" Sehe ich nicht so. Sicherer ist es nicht, da - wenn eh alles über die pfSense läuft (was meist der Fall ist außer SIP/VoIP) - man auch dort alles managen möchte. Auf der FB ohne wirklichen Paketfilter und outbound Filter irgendwas debuggen ist übel. Zudem will man ggf. sehen, was da alles von außen kommt etc. Nur Port Fowardings für einzelne Ports ist meist fehleranfällig weil zu oft an zwei Stellen ständig nachgesucht werden muss warum irgendwas nicht geht. :) Deshalb: 2 Handgriffe an der Fritzbox im Gegensatz zu ihrer Werkseinstellung: DHCP Bereich, exposed Host. Fertig. Sonst nichts angefasst. Und dann kann das Ding im Schrank vor sich hin oxidieren. Alles andere managed man auf der pfSense und hat seine Ruhe und muss weder mit dem Kabelbetreiber noch der Box noch großartig herumkaspern. Und zudem kann UM oder sonstwer problemlos einfach die FB mal austauschen. Kommt eine neue, einfach anschließen und anklemmen - selbst ohne die beiden Handgriffe hat man trotzdem SOFORT wieder Internet (da die .2 ja so oder so stimmt und andere Clients noch nicht herumschwirren) nach außen. Dann die 2 Handgriffe und auch von außen kommend klappt alles wieder. Schneller gehts nicht. Als Zuckerguss könntest du das Natting in der pfSense ausschalten (Stichwort: doppel-Nat). Den Satz verkneif ich mir. Ich kann das Double-NAT bashing nicht mehr lesen... Double NAT bringt euch an der Stelle überhaupt kein Problem außer bei VoIP und das kann/darf man durchaus vornedran packen an die FB, die vom Kabelanbieter meist eh schon den Telefon Teil vorkonfiguriert bekommt. Vorteil: funktioniert, ist vom ISP so gewollt und man hat kein Support-Chaos weil man "nicht unterstützte Lösungen" o.ä. einsetzt. Bei allem anderen ist NAT kein Hindernis von irgendwas. Zudem bekommt somit auch kein Provider Einsicht in die dahintergeschalteten Netze. Und das hat nichts mit Paranoia zu tun, sondern schlicht mit: hat den ISP nicht zu kümmern. Gruß

Da bleibt nach gegenwärtigem Stand m.W. nur manuelle Arbeit. Aber es wäre jetzt keine große Anstrengung den eh bereits integrierten NGinx nochmals parallel auf anderem Port o.ä. zu starten und eine entsprechende Mini-Seite auszuliefern. Das wäre an der Stelle eh zu empfehlen, da der System (webUI) nginx aus logistischen Gründen mit root läuft und das für einen normalen Webserver mehr als suboptimal ist. Daher wäre es sicherer eine zweite Instanz zu starten auf einem anderen Port oder einer anderen IP. Vielleicht wird auch das VHost Package irgendwann wiederbelebt, allerdings - wie gesagt - würde ich ungern einen VHost auf dem System-Nginx laufen lassen, da der mit viel zu hohen Rechten läuft und das hat auf einer Firewall dann nichts zu suchen. Gruß

Ich habe ja gesagt, dass sich dadurch mehr Möglichkeiten ergeben (die Zeitsteuerung war nur "u.a."). Wozu also etwas kompliziertes machen, wenn es doch einfacher und komfortabler gehen sollte. Die Frage ist halt, was bei mir falsch läuft. Kann denn keiner etwas zur angefragten Umsetzung sagen - was ich evtl. falsch mache oder worauf ich einen Blick werfen sollte?

Moin, @slaven: …Ich hoffe, das erklärt die Situation. Verlegen eines weiteren Kabels ist leider nicht möglich. Hier wäre ein Lösungsansatz managed Switche und Vlans einzusetzen, damit kannst Du Deine Netzwerkteilnehmer unabhängig von der leitungstechnischen Position zurechtrücken. -teddy

Wald, Bäume, Greenpeace - manchmal steht man auf'm Schlauch :)

Ok, ich kann jetzt sagen, dass scheinbar alle RRD Dateien sich wieder automatisch neu angelegt haben. Manche fast sofort nach dem Reset, andere wiederum erst einige Stunden später (womöglich erst nach dem ersten Zugriff oder sonst was - k.A.), aber ja - es funktionierte zum Glück auch ohne einer Neuinstallation.

Ja leider müssen die beide Laufen. Die eine Leitung ist eine Zwangsleitung für die Kommunikation mit den einem Hersteller. Leider bekommt man derzeit weder Alternativen noch die Zugangsdaten bzw. die Einwahldaten. Der Anschluss wird aber wirklich nur für einige IPs gebraucht. Ich hab den Bintec jetzt einfach als zusätzliches Gateway eingerichtet und die Routen eingetragen. Sicherlich nicht die sauberste Lösung, aber es läuft. Hoffentlich erledigt sich das Thema demnächst von selbst.

Hallo, eine Anleitung dazu findet sich in den pfSense Docs. Bin bei IPSec nicht der Experte, ich verwende es nicht (mehr). Aber im Grunde ist der Phase 1 für jedes Subnetz, das erreichbar sein soll eine Phase 2 hinzuzufügen. Für 192.168.0.0/24 hast du wohl schon eine Phase 2 konfiguriert. Kopiere diese einfach und passe das Subnetz an, an beiden Seiten! Die Subnetze kannst du natürlich auch zusammenfassen, wenn möglich. Für den Zugriff durch Roadwarrior, die sich auf pfSense 1 einwählen, muss als "Local network" auf pfSense 1 bzw. "Remote network" auf pfSense 2 natürlich deren Tunnel-Subnetz stehen.

Hi, installiere doch einfach das Paket LCDPROC. dann werden alle benötigten Komponenten an die richtige Stelle kopiert. Dann musst Du als LCD Modul das von einer Watchguard auswählen und die Anzahl der Zeichen pro Zeile richtig setzen. Ich kann Dir einen Screenshot meiner Config schicken, die funktioniert tadellos. Gruß

@viragomann: nachdem du es am LAN konfiguriert hast, bist du vermutlich ohnehin schon einer Anleitung oder Erfahrungsberichten anderer Leute gefolgt. Nein, ich habe zwar einige Sachen gelesen, aber im Gegenteil, in den meisten Anleitungen wird auch der WAN Port ausgewählt. Für mich aber irgendwie nicht ganz nachvollziehbar, da der zu schützende Bereich ja das interne LAN ist, also dort, wo die Kommunikation stattfindet und die verschiedenen Server und Clients laufen auf die ich ja die Regeln anwende die ich ausgewählt habe und der WAN Port sowieso komplett "blocked" ist solange man keine offenen Ports hat. Aber danke für deine Meinung und Hilfe!

@gtrdriver: Da läuft ein HP Microserver mit eiem Dualcore 1.2Ghz und 4 Open VPN´s. Etwas Offtopic: Habe auch das 400er Packet von Unitymedia. Den microServer G8 habe ich auch (16Gb RAM, Vier Kerne E3-1260L). Hypervisor ist ESXI v6. Unter anderem läuft pfSense bei mir zwei Jahren produktiv in einer VM incl. einer stetigen Side2Side Openvpn Verbindung und einer zusätzlichen RoadWarrior Instanz. Der Server wird aber mit Plex und TvHeadend geplagt (transcoding). Alles Super. Hervorragende Leistung bei mdoeratem Stromverbrauch. Hatte bisher keinen Grund mich zu beschweren.

Hi, ja der des Routers, aber nur auf 192.168.1.x und merkwürdig ist, dass wenn kein hoher Internettraffic über die PFS läuft, alles stabil ist. Erst wenn ich die Leitung z.B. über 1-2h mal Auslaste, dann blockiert sie. edit1: so eben in der ARP Table nachgeshen: client01 hat die korrekte reservierte IP aber die MAC ist def. die falsche. ?!! edit2: führe ich nen arp ip-client1 aus so erhalte ich "kein eintrag" edit3: führe ich arp ip-client1 von einem 2. client aus, so erhalte ich die auch vom client unter ifconfig angezeigt  wird, aber aktuell nciht auf der pfs im table steht ?!? edit4: eben von einem weiteren Client kontrolliert, ebenfalls komplett falsche MAC in der Table der pfs edit5: eben eine alte Reservierung aus dem DHCP gelöscht, Dienst neugestartet und nun ist die Verbindung weg, wohl wegen der fehlerhaften ARP Table edit6: System Log shows - rp: <wrong mac="">attempts to modify permanent entry for <client1-ip>on em0 edit7: in logs i see Unable to add forward map from client1 notimp <- what does this mean? edit8: eben im DHCP Log gesehen: dhcpleases kqueue error: unkown dhcpleases Could not deliver signal HUP to process because its pidfile (/var/run/unbound.pid) does not exist, No such process. dhcpleases /var/etc/hosts changed size from original! Ursache: ok ich denke ich weiß woran es liegt - die Clients sind virtuell unter Proxmox und dort ist die Firewall aktiv, war mir vorher nicht bewußt aber ist Testing, sodass dort mehrere Clients die selbe MAC erhalten bzw. als Verschleierung verteilt werden, aber das weiß ich auch noch nicht genau. Evtl. weiß hierzu jemand mehr und vor allem wie man das dann in PFS kontrolliert.</client1-ip></wrong>