Hallo @JeGr said in mehrere Router virtualisieren: Dazu zwei Punkte: Warum das ganze mit 3 verschiedenen pfSense Instanzen in denen jede WAN + LAN hat, anstatt EINE Instanz mit 3 VLANs nutzen, die dann auf die 3 VSwitche gehen? Was ist der Nutzen 3 separate Instanzen zu haben und Ressourcen zu verbrennen anstatt eine größere Instanz mit 3 VLANs zu erstellen? die verschiedenen Router haben komplett unterschiedliche Aufgaben, die eine macht nur viele VPN Tunnel ohne große Regelen, die andere das eigentliche Firewalling. Bestes Beispiel für den Sinn mehrere Instanzen ist gerade aktuell recht gut zu sehen: Die aktuelle Version 2.4.5 hat ein Mega Performance Problem wenn mehr als eine CPU genutzt wird. Damit wird die Firewall faktisch unbrauchbar. Hab ich auch lange gesucht um die Ursache zu finden. Abhilfe schaft nur ein Rückgang auf die 2.4.4 oder nur eine CPU zu nutzen. Damit bin ich mit meinen 3 Instanzen dann für solche Fälle besser bedient, dann hab ich wenigstens 3 CPU's statt einer :) pfSense bzw. FreeBSD wenn es um Netzwerkdurchsatz geht ist - auf Hardware - kein Freund von HT. Wenn du virtualisierst kann es allerdings durchaus sein, dass es Sinn machen kann. Da habe ich aber leider keine Hands On Werte/Erfahrung mit Hyper-V Bin aktuell recht weit mit meinen Tests. Netzwerkperformance ist TOP! Wenn man die Warteschlange für virtuelle Computer in den Broadcom Treibern deaktiviert! Das HT ist ja aktuell eh kein Thema weil nur eine CPU nutzbar ist... Danke und viele Grüße

@tomxl said in Schnittstelle reagiert nach mehrstündiger Nichtbenutzung nicht mehr: Hallo fireodo, ja genau, dass ist die Hardware die ich verwende. Dann weiß ich ja jetzt woran es liegt. Ist aber kein Problem mehr weil ich jetzt einen Switch dazwischen habe. :-) ... na dann ist es doch gut, aber nur um die Schnittstelle am Leben zu erhalten eine Stromfresser dazuschalten ... naja

Das erste Mapping ist gemeint. Hier, und bitte die Querverweise lesen. Mit 192.168.1.0/24 ist der Bereich von 192.168.1.1 bis 192.168.1.254 gemeint. Durch dein Mapping hast du den ganzen IP Bereich erwischt. Wenn nur die IP der Fritze gemeint ist, muss ein /32 hinter der IP der Fritzbox stehen.

@JeGr Hallo Jens, danke für die Rückmeldung. Genau das war meine Frage. Gruß Jürgen

Was ich noch vergessen habe. Ich habe mit Static, nicht Static und gemischt getestet. Die AAAA eintrage landen nie in der Domain und die A aus ipv4.

So weit ich es verstanden habe, läuft auf ESXI 6.7 (free) weder apcupsd noch nut (kann mich natürlich irren), daher die Krücke über plink. Weil plink auf pfSense nicht läuft der Umweg über eine eigene VM. Ich würde mir die VM gerne ersparen und den Befehl von der pfSense (apcupsd oder nut) direkt an ESXi senden - k. A. wie? Bin für Tipps dankbar ...

@JeGr Danke für den Tipp. Bin aber jetzt super zufrieden, da, wenn ich die VPN-Server direkt als Socks-Proxy angesprochen habe, es immer wieder zu Problemen wie Timeouts etc kam. Jetzt, über die Sense, Null Probleme dieser Art und Ausnahmen kann ich auch in der Sense anlegen. Vielleicht hilft der Erfahrungsbericht wem anders.

Freut mich zu lesen! :)

@beanz82 said in Synology Apps mit pfsense und HAProxy: Hi. Ein Thread reicht, und im englischen Part wird Englisch bevorzugt. :) Habe den Text jetzt 4 mal gelesen, komme nicht wirklich hinter, was du vorhast. Wenn Sich alles im LAN oder WLAN im gleichen Netzwerksegment abspielt, wozu brauchst Du HAProxy? Wenn der Browser Zugriff auf die Dienste hat und deine IOS-Geräte nicht, könnte es an den IOS-Geräten liegen. Habe kein I-Irgendwas, eventuell brauchen die schon signierte Zertifikate? Mal so in den Raum geworfen... Kannst dir von der Syno über Let's Encrypt erstellen lassen. Die Sense schaft das mit dem ACME-Package, Und hier mal die genutzen Ports von Synologies Services als Info.

Hi Rico Danke für die Rückmeldung. Ich konnte es mittlerweilse lösen, hab die Schnittstelle zwar angelegt, aber nicht aktiviert. Danke Gruss

/status ... ich noch immer nicht dazu gekommen ... fffu*****

Nicht unbedingt falsch, nein. Es könnte aber auch ein rate-limiting für Prozesse sein (wie Curl) das man dann durch anderen User-Agent aushebelt. Hatte pfBlocker mit einer bestimmten Liste schon mal (weiß gerade nicht mehr welche), die Änderung auf anderen User-Agent hatte dann aber nur ein paar Wochen was gebracht, weil das dann ausgeweitet wurde (die sehen das in den Logs ja trotzdem!). Da aber BBCans eigene Liste mit in deiner Aufführung drin stand, würde ich da in seinem Unterforum nochmal gezielt nachhaken und das Debuggen, denn wie gesagt, es kann nichts allgemeingültiges sein, da mein Test-pfB die Listen bspw. problemlos abrufen konnte. Also ist da mutmaßlich irgendwas im Zusammenspiel am Danebengreifen :)

@tpf said in pfSense redundant an Switch Stack: Danke für die Info.Dann lag ich ja grundsätzlich richtig. Der Stack kann zwei Uplinks. Muss über STP zwar irgendwie konfigururiert werden, da es sonst zu einer Loop führt. Allerdings sollte das ja machbar sein. Hey Thorsten, dann ist das aber kein LACP (normalerweise), denn LACP kümmert sich selbst um Loop Detection etc. Lieber nochmal genau nachlesen/nachschauen, wie gesagt nicht jeder Stack kann wirklich LACP über zwei unterschiedliche Backplanes. Wenn das dann doch nur ein Failover Bond ist muss das auch an pfSense Seite anders konfiguriert werden. Wenn man am Switch dazu mit (R)STP erst nochwas rumbasteln muss wäre ich auf der Hut, das klingt wie gesagt nicht danach, dass wirklich Active-Active LACP konfigurierbar ist. Wenn doch - umso besser :) Gruß Jens

Ziel "alle" bei der Regel auf dem LAN ist zwar Unsinn, denn der VPN Server hört nur auf die "LAN address" aber das ist in diesem speziellen Einsatz eh egal. :) Und das VPN Netz muss natürlich auf dem anderen Router des Netzes zur pfSense hin hinzugefügt werden.

@nobanzai said in Pfsense Gateway Down States Full: Ich habe in der Doku gelesen: "The DNS Resolver can work with Multi-WAN but the exact configuration depends on the desired behavior and current settings." Can/may work - richtig. Aber es ist eben nicht unbedingt trivial einfach und nicht sicher, dass es funktioniert. Schon alleine, weil einige ISPs ihre Netze abgesägt haben was DNS angeht oder es eben bei Resolving aus den Netzen heraus immer wieder Probleme gibt. Wir hatten das bei mehreren Kunden in Zusammenarbeit mit Netgates eigenem Support und die Aussage war immer bei Problemen: Resolving aus, Forwarding an (also nicht den DNS Resolver abschalten, sondern in den Einstellungen den Forward Mode anmachen!). Forwarding zu 2 oder mehr spezifischen DNS Servern, die man in General Settings auch manuell den beiden Interfaces zuordnet, funktioniert dann erstmal ohne Probleme egal was die Leitungen und sonstwas machen. Resolving wäre zwar schöner, aber nachdem auch immer mehr eh gern ihren gesamten DNS Traffic irgendwo hin schicken (Google, Cloudflare, whatever) ist das jetzt keine große Einschränkung - wenn überhaupt. Habe ich da nur Glück, dass das klappt? Wahrscheinlich alles zusammen. Glück, dass aus allen ISP Netzen heraus Resolving kompetent funktioniert, die richtige Einstellung im Resolver gefunden und Glück beim Regelset bzw. Failover, dass das Resolving sauber über die 2. Leitung geht und Abfragen macht. Hatten wir bei DSL Leitungen nicht ganz so viel Glück leider :/ Dann spielt auch noch rein, ob DNSSEC sauber läuft/laufen soll etc. etc. https://docs.netgate.com/pfsense/en/latest/book/multiwan/interface-and-dns-configuration.html#dns-server-configuration sagt ja hierzu auch, dass u.a. Default Gateway Switching funktionieren muss. Daher ist es ggf. einfach leichter, wenn man zwei gute Forwarder hat die auch DNSSEC sauber schon validieren und man die als Forwarder nutzt bei Multi-WAN. Damit hat man an der Stelle einfach mit weniger Problemen und Abhängigkeiten zu kämpfen :)

Moment eine Fritzbox auf Seiten von Netz B? Wo ist die denn und warum spielt die eine Rolle? Ich dachte du hast auf beiden Seiten ne pfSense wozu dann noch eine Fritzbox im gleichen Netz? Das fängt an immer weniger Sinn zu machen wie gedacht ;)

Ja der Banditen Hinweis hat was für sich. Cloudf wirds wohl eher werden... Mal schauen

Ach guck... da hatte ich selbst mit 2.4.4 Probleme - nicht mit hoher Last oder großem Paketverlust, aber mit dubiosem Verhalten was das Pingen über die FB angeht. Die hatte ich die ganze Zeit in Verdacht, da das Problem früher mit älteren FBs nicht auftrat. Ich habe aber seit der letzten Umstellungauf Vodafone jetzt mal testweise in der Box auf einem LAN Port den Bridge Modus aktiviert und siehe da, die pfSense hinter der FB bekommt dann eine eigene/andere public IP4 und kann sich ein v6 Netz holen, obwohl die FB trotzdem weiter rumroutet (getestet am FB WLAN, FB hat andere IP4 und anderes IP6). Mit der Einstellung sind dann auch plötzlich die ominösen Ping Probleme mit dem dpinger verschwunden und auch andere seltsame Aussetzer... Wenn du die Option hast - ein Test ist es wert :)