Dies hat sich mittlerweile erledig. die USV war ein altes Modell von Powercom und der entsprechende NUT Treiber hat beim Starten des Dienstes einen Reset an die USV gesendet, was dort zu einem Selbsttest geführt hat, diese wird durch das Piepen begleitet.

Ich habe die USV durch eine neue APC ersetzt, bei dieser lässt sich der Alarm USV seitig unterdrücken.

Ich habe mittlerweile den Fehler gefunden !

Zum einen hatte ich die Bedeutung von Endpoint falsch verstanden, hier hatte ich die Interface IPs der Peers eingetragen, es ist aber wohl die WAN IP des Peers gemeint wenn diese statisch ist gemeint. (bitte korrigieren wenn dies nicht korrekt ist). Habe diese auf Dynamic umgestellt.

Bei Allowed IPs habe ich statt die IP des Tunnelnetzwerkes, die IPs der jeweiligen Peers eingetragen.

Peer Konfiguration siehe Bild, die des zweiten auf Windows sieht auch so aus, nur mit anderer Interface IP.

wg1.jpg
InkedInkedScreenshot_2023-03-23-19-28-41-055_com.wireguard.android.jpg

Hallo Zusammen,

so, fragt mich nicht woran es lag..... Jetzt funktioniert es. Hat sich somit erledigt.
Danke

@thundergate

Späte Antwort, default bei pfSense sind 500 (ms). Eventuell verschluckt es sich da.
Screenshot 2023-03-21 at 23-26-50 pfSense.home - System Routing Gateways Edit.png

@jegr
Hallo Zusammen und besten Dank für eure Hilfe!!!

Ich habe alles soweit hinbekommen. Allerdings habe ich die Zertifikate im Backend eingebunden. Ich habe noch gar nicht getestet ob es auch ohne gehen würde... bin soweit erstmal froh dass es läuft!

Danke euch allen!!!

@jegr said in Wireguard Abbruch nach Provider IP-Wechsel:

Wäre dann aber nicht Tailscale (oder headscale) schlicht einfacher?

Ja das wäre einfacher, vielleicht läuft es auch darauf heraus.

Wenn es klappt bekomme ich dieses Jahr noch den Glasfaseranschluss mit keiner 24h Zwangstrennung (hoffentlich, wer weiß was denen einfällt!). Dann könnte ich auch mal mit einem ab/anschalten der WireGuard Verbindung leben.

@bob-dig said in Telekom IPV6 funzt nach DSL-Reconnect nicht mehr im LAN:

@slu Schon lange.

Nope nicht überall und nicht zwingend. Gerade wenn es nicht direkt Telekom sondern Subunternehmen ist, wird das oft noch voll durchgezogen.

@benjsing said in zwei Nachbarn: bündeln der WAN Verbindung, eigene Netzwerke?:

Haushalt B: Fritzbox, openWRT

Meh

@benjsing said in zwei Nachbarn: bündeln der WAN Verbindung, eigene Netzwerke?:

Bündeln der WAN Verbindung

@benjsing said in zwei Nachbarn: bündeln der WAN Verbindung, eigene Netzwerke?:

nehmen wir an, beide Leitungen haben einen Download Speed von 200 Mbit/s; könnte man einstellen, dass jeder Haushalt theoretisch also 400 Mbit/s benutzen kann, es sei denn, der andere Haushalt benötigt seinen "Eigenanteil"? Also Haushalt A nutzt gerade kaum Bandwith, daher darf Haushalt B mit 400 Mbit/s arbeiten. Nun beansprucht Haushalt A aber selbst 160/180/200 Mbit/s, also wird Haushalt B auf maximal 200 Mbit/s gedrosselt.

Das Vorhaben geht hier schon den Bach runter, weil eine Bündelung technisch nicht möglich ist. 200+200 werden nicht einfach magisch zu 400Mbps. So funktioniert IP nicht. Das Einzige was sowas leisten kann ist TCP Multipath wenn vom ISP unterstützt und zwei gleiche Leitungen vorhanden sind etc. etc. - also Vollmond an der großen Eiche mit drei Mal links und einmal rechts rum bis man nach Narnia kommt 😁

Aber Spaß beiseite - Bündelung gibt's nicht einfach wie bei ISDN Kanalbündelung. So läuft das nicht. Und selbst wenn man mit diversen Techniken die Leitungen zusammenknotet, würde das nur funktionieren, wenn man entweder teure Hardware auf beiden Seiten nutzt oder wenn man es auf die einfache Tour macht würdest du nur was davon merken, wenn man einen Client nutzt, der beim DL bspw. dediziert multiple Teildatenströme zu einem zusammenfassen kann und daher mehrere Downloads gleichzeitig laufen lässt. Und selbst dann wäre es in den Größenordnungen nur begrenzt ein Speedup, da die Leitungen gegeneinander aufeinander warten müssen.

Den 2) Block verstehe ich leider nicht wirklich. Liest sich aber ein wenig wie Core Routing hinter der Firewall. Kommt dann drauf an, was die mehreren Netze dann noch bringen sollen wenn sie nirgends mit Regeln aufgelegt werden. Daher ein "?"

wenn die Netze verbunden sind (irgendwie) und beide Netzsegmente (Haus1 / 2) sauber voneinander getrennte IP Ranges nutzen, ja. Kommt dann natürlich auf die Rulesets an aber ist auch nicht anders als ein großes Gebäude mit mehreren Teilnetzen.

Somit

#1: Fällt eher in "Vergiss es". Macht auch wenig Sinn. Das Einzige, was bislang IMHO Sinn macht bei Nachbarhäusern, was ich auch schon eingerichtet habe, ist bspw. ein Failover. 2 getrennte Netze, jedes Haus eigenständig was das Netz angeht mit einer Crossline zwischen den beiden Firewalls. Über die Line kann dann (wenn auf jeder Seite ne gescheite Firewall/Router Instanz hängt) bspw. beim Ausfall von a) auf b) gewechselt werden und umgekehrt. Das kann ganz nützlich sein. Oder man kann auch mal testweise nen Clients über b) schicken wenn man was testen möchte. Aber Kanalbündelung - nope. Sobald wir da in zu hohe Geschwindigkeiten kommen, kommst man ohne Multipath Vectoring nicht mehr aus und das wird a) komplex und b) wirds aktuell noch nicht vollständig von der Sense untersützt, da es bis FBSD 13 nicht sauber im Kernel zum Laufen zu bekommen war (OSPF etc. notwendig).

#2: Unklar was gemeint ist, aber für das was ich verstehe: Jein. Kommt auf Wunsch und Technik an.

#3: Klingt möglich, ja.

@m0nji said in Paketverlust mit HE-Tunnel:

klar, mit einen GIF Tunnel zu einer eigenen pfSense Hetzner Instanz z.B. ;)

Lustig gemeint, brächte aber 0,0 gar nichts, denn der Witz ist ja gerade, dass HE.net einer der wenigen Tunnelbroker ist, die ordentliche RIPE/ARIN Richtlinien umsetzen und dir auf Anfrage ein /56er v6 Space zuwerfen und auf deinen Namen routen. Das bekommt man bei nem 50c Hetzner VPS nicht. Leider.

Das Problem ist gelöst! Ich hatte versehentlich das NAT auf der pfsense eingeschaltet. Ausgeschaltet und alles funktioniert wie es soll.
Danke für Eure Mühe und Unterstützung!

Viele Grüsse, ralhue

@thundergate said in LAGG aus einem vorhandenen Interface bilden:

Wollte den eigentlich direkt an einen der Ports der pfSense hängen, aber dann müsste ich bridgen, was ja auch wiederum Probleme und "Dinge" mit sich bringt.

Müsste man sich in der neuen Version 23.01/2.7 mal ansehen, das Bridging im Stack ist in FBSD13/14 wesentlich besser geworden. Könnte sein, dass sich das dann durchaus rentiert, das einfach direkt anzuschließen, wenn man schon Geräte mit 2.5 hat.

Aber warum glaubst du denn dass das sinnvoll wäre für dich? Bist du mit so viel "power" Unterwegs, dass du allen ernstes 125MB/s vom Gigabit auf Dauer ausmaxen kannst und mehr brauchst? Für wie viele Clients? Nur wegen Nextcloud und OMV?

@elv

Die Route wird auf der Fritzbox eingetragen mit dem Ziel deines LAN Netzes hinter der pfsense.

Also bspw.:

FB
|.1
(192.168.178.0/24)
|.2
pfSense
|.1
(192.168.1.0/24)

Hier bekommt die Fritzbox eine Route die ihr eben mitteilt, dass man das Netz 192.168.1.0/24 über die IP der Sense (192.168.178.2) erreicht.

Firewallregeln auf dem WAn Interface der Sense kannst du entsprechend lassen bzw. anpassen. An der Fritzbox melden sich dann DVB Clients mit der IP aus dem 192.168.1.0/24 Netz (gleiches Analog auch für ein Client in einem anderen Subnetz falls du ein eigenes Netz hast für deine WiFi Clients.

@viragomann so ist es! Die Portweiterleitung raus und schon geht es weiter. Wenn auch nun mit einer anderen Baustelle:
TLS Error: tls-crypt unwrapping failed from [AF_INET]80.187.99.111:27914
Da muss ich mich jetzt durchwühlen, aber Deine Analyse zum unnötigen NAT scheint das Problem gelöst zu haben. Die Verschlüsselung ist hoffentlich nun lösbar für mich.

V i e l e n Dank!

@tutanchamun Um @viragomann da kurz zu ergänzen:

502a5dc0-e81f-4b52-84da-b386e664e8af-grafik.png

Die orangenen Punkte wird wahrscheinlich deine AdGuard Home Installation schon abfangen? Eventuell nachschauen wäre da vielleicht nicht schlecht, wenn man ohnehin "diverse Seiten" für Kinder filtert, wäre SafeSearch auch noch ein Punkt.

Anyway im DNSBL Part von pfBlockerNG dann DNSBL SafeSearch anklicken, im unteren Bereich ist dann der Block mit DoH/DoT/DoQ beheimatet, der hier dann die bekannteren (alle natürlich nicht, wie auch) DNS Services listet. Dort kann man dann diese wegblocken. Allerdings müsste der AdGuardHome dann auch die pfSense als Upstream DNS verwenden, damit das funktioniert. Wenn AGH das schon selbst kann und übernimmt, nevermind, dann muss man hier an der Stelle nichts ergänzen.

Wichtig wäre dann ausgehend noch TCP 853 wie gesagt zu blocken, DoH/DoQ kann man sonst nur via DNS Blocking abfangen, das das via TCP/UDP 443 läuft und sich als Web Traffic tarnt.

Ansonsten was den Redirect angeht:

6d136adc-2ef4-4f3b-a7db-a9d47fd6ac85-grafik.png

Beispiel: LAN mit 192.168.1.0/24 und AdGuardHome (AGH) mit 192.168.1.23
Port Forwarding erstellen auf dem LAN (wir wollen ja internen Traffic umschreiben) zu "any" DNS Server (also egal welchem public DNS) soll umgeschrieben werden auf die IP des AGH aber nur wenn der Traffic nicht vom AGH selbst kommt. Also alles außer AGH DNS Traffic bitte auf den AGH schicken.

Das erzeugt dann auch eine Regel auf dem LAN, die man mit einigen anderen noch ergänzt um die Sache abzurunden:

6b9cb85c-4ab6-42d5-ab6f-fb335cdaa17b-grafik.png

So was passiert da?

erlaube den AGH auf jeden DNS (im Falle, dass der AGH als Resolver agiert und die DNS Anfragen sauber via ROOT Zone etc. auflöst - wäre SEHR zu empfehlen!). erlaube den AGH auf jeden DNS via DoT (DNS over TLS, TCP Port 853 - hat aber zur Folge, dass jeder DNS Traffic an einen einzelnen Forwarder geschickt wird. Das ist zwar verschlüsselt, aber aus mehreren Gründen eigentlich nicht zu empfehlen). das ist die Regel, die vom Port Forwarding angelegt wird. An dieser Stelle theoretisch "nutzlos", da LAN->LAN Kommunikation nicht über die pfSense läuft und daher hier gar nicht aufschlägt, wir behalten sie aber hier für den Fall, dass hinter dem LAN bspw. noch weitere Netze über einen internen Switch/Core Router angeschlossen sind. Wir blocken via Reject (intern ist reject block vorzuziehen, da schneller) alle Anfragen nach draußen via Port 53 - sicherheitshalber. Sollte jemand an unserer Port Forward Regel herumspielen und sie versehentlich ausschalten geht dann kein DNS mehr für die Clients aber das ist dann reparierbar. Ansonsten könnten Sie währenddessen wieder frei auf jeden DNS zugreifen Dito für DoT - interne Clients sollen kein DoT benutzen, daher hier blocken via reject. Hier würden jetzt sonstige Regeln kommen, in unserem Beispiel ist nur noch die default "allow any" Regel jetzt übrig.

Das sollte das Szenario eigentlich ganz gut abdecken, wenn mir kein Fehler reingerutscht ist.

Cheers

@jegr Japp, wir reden über genau den.

Vielleicht wurde der Port irgendwo "hardcodiert"? Wenn ich z.B. ein Binary aus einer älteren pfSense Version nehme und drüberkopiere, funktioniert es.

Ebenso mit einem selbstcompilierten Binary.

@mercyful So ein ähnliches Ding habe ich mit einem Firmenkunden auch, der da einen Telekom Cloud PBX Dienst nutzt aber noch in alter Version. Da debuggt die Telekom auch schon ewig rum und macht keine Fortschritte außer "ja da müssen sie in den CloudService 2.0 migrieren, der arbeitet dann gar nicht mehr mit SIP/VoIP sondern basiert wohl auf irgendwas Cisco WebEx SaaS mäßigem..." - ja cool, wenn meine Cloud PBX nicht geht, einfach das Telefon abschaffen (und durch ne hosted Videokonferenz Lösung ersetzen). Klingt nach nem Plan 😂

Hallo,

Dein Budget wäre auch gut zu wissen, ich habe einmal
alles quer "durch die Bank" nachgeschaut, was bei
anderen Leuten gut rennt und keine Probleme macht.

Budget 170 € all in mit Gehäuse
Nichts zum basteln, aber fix und fertig

Etwas teurer und nur Board, CPU und RAM
Passt ganz gut zu Eurem nur Gehäuse denke ich

Teuer, und falls Dein Gehäuse 4U hat aber damit geht alles
VM, bare metal oder......

Supermicro:
Intel Atom C3558, C3758, C3858 und 3958
gibt es gleich mit vielen extras und Ports.

Intel QuickAssist AES-NI Slot für SSD Slot für WLAN Karte Slot für eine oder zwei PCIe Karte(n) 2x SFP+ Ports 2x 10 GBe Ports 4x 1 GBit/s Ports IPMI Port

Intel Xeon D-2100 und Xeon D-2700
Falls Du solch ein System (Board) in Betracht ziehst würde
ich immer darauf achten wollen das dort ein N oder NT im
Namen der CPU mit dabei ist, das steht für Network
und man weiß dann dass Intel QuickAssist mit an Board ist.
Beispiel: Supermicro Xeon D-2146NT

@intrabit

http://dsi.ut-capitole.fr/blacklists/index_en.php

In den Browser kopieren und dann schaust Du was Dir zusagt
und "klickst" (Rechtsklick) auf den Link und wählst dann "Link kopieren aus und fügst Ihn in Deinen SquidGuard ein."

ftp://ftp.ut-capitole.fr/pub/reseau/cache/squidguard_contrib/blacklists.tar.gz

Oder einfach alle Listen zusammen (komplett) unter diesem Link hier.

Man kann auch hinter der pfSense einen kleinen MikroTik
Router benutzen und der macht dann eben kein NAT.

Oder gar einen kleinen Cisco GS300 oder SG350 Switch
und der routet dann das LAN bzw. den Verkehr dort.