@altmetaller said in Nintendo Switch - Doppeltes NAT: Bei der X-Box (One) ist mir aufgefallen, dass die per uPnP Port 3074 aufmacht und darüber Teredo (schauder!) fährt. Teredo ist leider so ne MS Seuche, aber AFAIR haben sie das später abgestellt bzw. selbst in Windoof inzwischen runtergefahren. Aber nervig allemal. Teredo nimmt die eigentlich eher für v6 Tunneling nicht für den Rest. XBoxen können aber eigentlich wie PS auch uPNP und sich damit ne Öffnung bohren, aber auch da reicht (für meinen Gebraucht) allermeistens das static port freigeben für die meisten Spiele :)

@alcamar Die Pakete, die ich beobachte beim Aufruf der Kamera-App kann ich nicht vollständig deuten. Es spricht für mich als Laien etwas dafür, dass die Anfrage von der pfsense zum Handy nicht ok ist, weil da etwas von nicht korrekter Checksumme steht: 13:46:37.326125 IP (tos 0x0, ttl 54, id 31060, offset 0, flags [DF], proto TCP (6), length 64) 80.xxx.xx.xxx.12008 > 192.168.178.254.443: Flags [S], cksum 0x040b (correct), seq 1102934232, win 65535, options [mss 1390,nop,wscale 6,nop,nop,TS val 4117574554 ecr 0,sackOK,eol], length 0 13:46:37.326215 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60) 192.168.178.254.443 > 80.xxx.xx.xxx.12008: Flags [S.], cksum 0x2725 (incorrect -> 0xaa4b), seq 1124675381, ack 1102934233, win 65228, options [mss 1460,nop,wscale 7,sackOK,TS val 3986951100 ecr 4117574554], length 0 Die Kamera-App antwortet vielsagend: "Die Netzverbidnung wurde unterbrochen". Die gleiche URL für den Zugriff auf die Kamera über einen Browser funktioniert problemlos und wird über den HAProxy angezeigt. Das ist die aktuelle Testkonstellation beim HAProxy: [image: 1679749007524-bildschirm-foto-2023-03-25-um-13.56.35-resized.png] Die Hausautomations-App geht auch hier nur, wenn der Default der Hausautomationsserver ist.

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. [image: 1679596690670-wg1.jpg] [image: 1679596690640-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. [image: 1679437655676-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: [image: 1677510195715-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: [image: 1677510701484-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: [image: 1677510845230-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