@waeck said in pfSense interne DNS auflösen, dann zu PI Hole. Geht das?: Ist dies möglich? Ja , wenngleich es auch andersrum geht. Du kannst die PIs einfach für Upstream DNS an die pfSense verweisen und die macht dann die Auflösung nach draußen. Dann musst du nicht mit der internen Domain und DHCP und Co doppelt rumhamstern und die Daten an pfSense und Pi doppelt eintragen @waeck said in pfSense interne DNS auflösen, dann zu PI Hole. Geht das?: Ich dachte, dass ich 1.1.1.1 nehmen würde. Oder gibt es da bessere, die weniger tracken? Ja, ca. alle anderen überspitzt ausgedrückt. Nur weil die angeblich(!) nicht tracken, heißt nicht, dass es Sinn macht, ALLE DNS Abfragen aus seiner Butze an einen einzigen DNS zu ballern. Einfach den DNS Resolver der pfSense selbst auflösen und nicht weiterleiten lassen, dann fragt der jeden DNS der Welt wenns sein muss. Aber nicht immer nur einen. Sinnvollerer Weg wäre IMHO: Per DHCP die PIs (oder den PIhole) rausgeben (bei mir sinds zwei) Bei den PiHoles ist die pfSense als Upstream drin Auf pfSense macht Unbound DNS Resolving (NICHT forwarding) und löst den Kram einfach auf indem er von den ROOTs bis zu den zuständigen DNSen fragt. Ist im ersten Aufruf einen ticken langsamer, danach aber in unbound und deinem Pihole eh gecached. Fertig :) Ja man kann das auch alles via pfBlockerNG vllt nachbauen, hat aber IMHO bei DNS Blocking das Problem, dass wenn man nicht alles gleichbehandeln will es wenig Optionen gibt. PiHole kann da nicht nur UI technisch einen bessere Figur machen, sondern kann auch mehrere IP-Ranges und Gruppen verwalten auf die verschiedene Blocklisten angewendet werden können. Cheer

@dk_e said in regelmäßiger WAN ausfall. Einfach neustart hilft ABER: Aber noch ne Frage, hast du das irgendwo im Log gesehen oder wie bist du auf die Idee genommen (noch so um zu lernen:). Im Log hab ich nur gesehen dass eine Realtek zum Einsatz gekommen ist. Realtek & FreeBSD da gibt es haufenweise Foreneinträge die das Zusammenspiel von diesen Karten und dem Betriebssytem thematisieren.

@nocling Hi, sieht so aus das die Aktualisierung von die System_Packages von 2.2.1 zu 2.2.2 hat was gemacht. Plötzlich hatte ich langsam internet aber danach habe ich den PFBlockerNG deaktiviert und läuft alles gut. DNSLeak test zeigt auch meine IP als DNS Server so alles gut. DNSSec Support habe ich mit und ohne probiert hat aber nichts geändert bis ich den update gespielt habe. Ich werde noch in PFBlocker gehen und besser konfigurieren. Danke noch mal und sorry für mein Deutsch :) Schönes Wochenende!

Hallo, hast Du mal bei denen selber nachgefragt? Du bist bestimmt nicht der einzige Kunde mit einer pfSense Firewall bei denen, und die Probleme haben die dort bei dem Hoster bestimmt auch schon dreimal gehört. Wäre halt schneller am Ziel für Dich.

Bitte jetzt nicht anfangen euch gegenseitig hier anzugehen. a) ist die Intention in Textform immer schwerer zu verstehen wenn man die Person nicht hört oder sieht b) muss man da jetzt nicht auf einer Aussage herumreiten oder die in Frage stellen. Es kann nicht jeder alles wissen, dazu sind Produkte inzwischen einfach viel zu komplex und dafür gibt es Austauschplattformen wie diese, um vom Wissen Vieler zu profitieren. Ich kannte auch schon spezifische Punkte nicht, bei denen mich @viragomann, @slu oder @NOCling bspw. abgeholt haben. Wenns mit meinem Hinweis nun funktioniert - umso besser :) Cheers

@viragomann Danke Dir... es wird mir nun etwas klarer. Dass es nicht (direkt) mit ACME zu tun hat, war nicht der Grund, weshalb ich das erwähne, sondern der, dass ich nur verdeutlichen wollte an zwei Stellen ACME nutzen zu wollen, aber eben nur mit einer IP (und einmal Port 80/443). @JeGr in dem Sinne habe ich bereits zwei Frontends, korrekt. Eins, welches 80 auf 443 weiterleitet und dann eben das Shared_Frontend. Wenn ich dann so mit "Host ends" oder ähnliches arbeite, greift natürlich das ACME Zertifikat, welches hier hinterlegt ist, also von der pfsense mit Acme kommt. Dann funktioniert die "Weiterleitung" auf den 2. Nginx nicht, wie gewünscht. Werde mir Eure Infos nun mal verinnerlichen und weitertesten bei Gelegenheit. Herzlichen Dank für Eure Zeit. Cheers

System Patches Paket installiert? Alle aktuellen Patches eingespielt? DNS Problem? Gateway/IP Problem nach extern? Firewall Widget auf dem Dashboard? Möglichkeiten gibts da viele... Cheers

@m0nkey said in Ich kriege IPv6 mit Prefix Deligation nicht zum laufen..: Aber gut zu wissen, dass meine Logik nicht komplett falsch ist, nur wahrscheinlich unorthodox. Ich hab jetzt einfach das "! IPMI net" rausgenommen und löse das dann anders. Es ist eben Invertierungslogik. Wenn das IPMI net gar kein v6 hat, dann wird es schwer "nichts" zu intervieren ohne alles zu bekommen. Genau deshalb gehe ich solche Sachen mit Invertern nur höchst ungern an denn sobald es mehr als "IPMI net" wird, ist man transparenter, wenn man einfach jedes nicht gewünschte Netz rejected. Denn mehr als einmal !xy_net funktioniert nach dieser Logik eh nicht. Daher würde ich einfach von Invertierungen in der Logik mit NOTs absehen, das hat schon immer zu lustigen Fehlerbildern geführt :) Cheers

@nocling Danke für dein Feedback. So tief kenne ich mich nicht aus. Nach zwei, drei mal durchlesen der offiziellen Doku habe ich es jetzt geschafft. Es geht aber man muss halt auch etwas testen und probieren. Nun läuft aber Tunnel s2s und ich habe mehrere Clients die auch drauf zugreifen können. Somit läuft es jetzt mal. Alles läuft mit den "Zertifikaten" und der Export für ein "Endgerät" funktioniert sogar recht einfach. :-) Nun kann ich testen. Dank für die Hinweise!

Hallo @jegr, ich nutze Netgear WAC 540 und WAC564 als AP und Repeater. beide Geräte können beides wobei der 540 per poe+ gespeist wird. Kleiner Nachteil wenn du die per cloud verwalten willst das du 10€ pro Jahr zahlen musst. Wobei da die Vorteile überwiegen. Gruß ré

Hallo Leute, danke für eure Tips, ich habe Interent Access von Auto auf VDSL2 geändert, seitdem klappt es schon relativ lange mit dem Sync. Wer weiß warum es gestern nicht geklappt hat. Das mit dem Internet Access habe ich bei einem YT Video gesehen. Die kleinen Aussetzer wären nicht so tragisch, bei Resync sind meine SSH Verbindungen weg was nervig ist. Gruß ré

@nocling @nocling said in Wireguard Site-to-Site mit FritzBox: Mit dem FBEditor-0.6.9.7k ist das doch auch keine Raketentechnik, einfach nach dem Tunnel suchen und die Parameter fix anpassen, fertig. Sollte man das von remote aus machen müssen, was in meinem Fall zutraf, wird das schon zum Problem. Ich hatte im LAN der 7590 einen OpenWRT-Router, der mir die vorläufige Verbindung zur Fritzbox mit OpenVPN hielt. Aber das Problem mit dem FBEditor-0.6.9.7k tritt wohl auch auf, wenn man vor Ort einrichtet. Die zusätzliche Bestätigung (2FA), die das aktuelle Fritz-OS bei solchen Änderungen verlangt und die sich auch nicht so einfach abstellen ließ, macht hier Probleme. Erst nach einem Downgrade auf eine vorherige OS-Version und das Abschalten von 2FA hat das funktioniert und somit ist der FBEditor im Augenblick mit dem aktuellen OS eigentlich gar nicht wirklich nutzbar. Ich hatte diesbezüglich mit dem AVM-Support einigen EMail-Verkehr, in dem mir das auch bestätigt wurde. Ob man das dann einmal in die Entwicklung mit einfließen lässt oder ob die vermeintliche Sicherheits-Politik von AVM dem entgegensteht, werden wir in zukünftigen OS-Versionen sehen. Gruß orcape

@nocling ich glaube das ich das nicht wirklich aktiv abgeschaltet habe sondern ich hab meine Hardware einmal gewechselt und ich glaube das die Maschine vorher das nicht konnte und das im Backup drin war und durch das einspielen des Backups das da drin war, denke ich. Sonst wüsste ich nicht wann ich das gemacht haben soll …

Der NIC ist egal ob da ein AP oder ein Switch dran hängt, die überträgt nur Pakete. Aktuell läuft alles auf den ersten primären 24er von meiner pfSense, das über einen 2GBit LAG, von da aus geht es dann weiter auf die Clients, das NAS usw. Auf jedem Port an dem ein AP hängt sind dann die VLANs die den jeweiligen SSIDs zugewiesen sind tagged mit drauf. Untagged ist da das Management VLAN anliegend, in dem die Switche, der WLC und die APs hängen. Sobald VLANs ins Spiel kommen, ist das mit der physikalischen Trennung eh hinfällig, da man über die VLAN IDs differenziert, welches Layer 2 Segment hier anliegt und welches nicht.

Dann ggf. die hier: pfSense-upgrade pkg-static update -f pkg-static upgrade -f

@viragomann Ok das probiere ich auch. Danke.

@waeck said in 2xpfSense > Traffic Gerät X über wireguard VPN senden / empfangen: Warum habe ich keine Bewegung auf dem Firewall Regelt, die in A Wan ist: Ah... die Regel hat keine Bewegung, weil ich sie nicht brauche. :-) Ok. Dann funktioniert jetzt alles wie gewollt. DANKE an alle. Gruss waeck

@dogfight76 Hi, das hat an der Stelle gar nichts mit pfSense zu tun, sondern mit der (Marketing BS) Implementation von NordVPN, die wieder was Eigenes basteln mussten: Zitat NordVPN: the NordLynx protocol is only available with the NordVPN application on desktop and mobile devices at this time! Man kann den Kram also leider nur mit den offiziellen Apps nutzen, aber nicht mit eigenem Router oder anderen Geräten, die den Public/Private Key austauschen müssten. Ist aber eine rein künstliche NordVPN Einschränkung. Andere Anbieter wie bspw. ProtonVPN können das problemlos (auch Doppel-Hop VPN Konstellationen mit mehreren Zwischenschritten). Cheers \jens

@nsuttner Die Fehlermeldung selbst sagt ja schon, dass es eine SNMP Rückmeldung ist auf ein nicht konfiguriertes Device (bzw. wahrscheinlich eher eine nicht bekannte/angemeldete Entity im SNMP) - das kann da die 3100 wie die 2100 genauso treffen, weil die 3 alle einen eingebauten Switch Chip haben. Das dürfte dann auch der Fehler im SNMPd sein, der da spammy Meldungen rauskloppt weil er den Switch Chip nicht versteht. Wurde in den aktuellen CE Snapshots IMHO schon gefixt oder vorgemerkt, muss aber wohl - da SNMP - auch an Upstream gemeldet werden. Ist aber in https://redmine.pfsense.org/issues/13976 schon auf dem Radar/gefixt und muss noch eingepackt werden. Spätestens mit 23.05 sollte das aber dann wieder weg sein :) War wohl schonmal da und wurde gepatcht, mit Upstream Change auf FBSD14 wurde das wohl aber in Upstream nicht gefixt/angenommen und jetzt ist es wieder aufgeploppt. Cheers

@svenp Ja, solange die Quelle in der Outbound NAT Regel auf das interne Subnetz eingeschränkt bleibt. Ich würde sie noch weiter, nur auf die Client IP beschränken (Maske /32). Ich habe einige Consumer-Router gesehen, die standardmäßig ebenso eine Masquerading Regel am internen Interface hatten und damit sämtlichen eingehenden Traffic aus dem Internet so aussehen ließen, als würde er aus dem lokalen Netz kommen. Einen solchen würde deine Regel abermals mit der eigenen Interface IP verschleiern.