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.

@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.