@Tobi said in Fritz!App Fon (Handy VLAN A) zu FritzBox (VLAN B):

Das ist zwar für mich ganz dünner Boden, weil ich nun mal kein "Netzwerker" bin. Woher soll die Sense denn wissen, was sie mit einem neuen/ ankommenden Paket machen soll?
Es wird doch von innen nach außen alles geroutet aber von Außen nach Innen?

Außen & Innen sind keine Dinge, die ein Gerät kennt. Es hat lediglich Routen. Jedes lokal anliegende Netz hat implizit eine Netzroute mit fast höchster Prio. Die Sense weiß also in welchen Netzen sie steht und wo sie Pakete zwischen den Netzen hin und her verteilen soll. Alles was sie NICHT weiß, schickt sie an die Default Route - dafür ist sie da :)

In der klassischen Situation:

FB <--> pfSense <==> Netz(e) intern

wie man sie oft antrifft, steht ja die Fritte als Provider Kiste vor der Sense, ergo ist der Weg dahin für die Sense immer einfach -> es geht ja eh alles raus, was nicht intern bekannt ist. Problem hat hier die Fritte, denn die hat nur die Sense als Nachbarn, sieht aber die internen Netze nicht und hat da keinen Schimmer von und da ihre Default Route raus ins Internet geht, kommt da dann ohne NAT ausgehend aus der pfSense kein Paket von innen mehr dorthin zurück - außer man setzt statische Routen in der Fritte.

Umgekehrt: Wenn die FB aber in einem internen Netz parkt, wie alle anderen auch und die Sense direkt Internet hat/macht oder es eine andere Kiste davor gibt, dann ist die Default Route der Fritte ja die Sense selbst. Alle Netze an der Sense sind dann problemlos erreichbar, weil die Pakete von/zur Fritte dann ja immer über die Sense laufen und dort die Netze alle bekannt sind. Die Fritte kennt sie zwar nicht, aber da diese auf dem Rückweg eh alles an die Sense schickt - kein Problem, denn die kann dann regeln und kennt wieder den Absender. Ergo ist hier intern hinter der Sense zwischen den Netze kein NAT nötig, die finden sich alle.

Cheers

@wschmidt

ich weiß das Thema ist alt aber der Vollständigkeit halber:

Wenn man den Gästen z.B. den Google DNS (8.8.8.8) per DHCP zuweist muss dieser im Captive Portal unter Allowed IP Addresses eingetragen werden.

@JeGr said in Lets Encrypt ACMEv2 | RFC 2136 Update | Strato:

Damit kann man die Auth via API Eintrag des TXT Records in der dedyn.io Zone lösen, während im händischen DNS Tool des Providers (Strato, 1und1 etc.) ein einfacher CNAME eingetragen wird für den Hostnamen, den man ausstellen möchte.

Das Ganze kann man dann natürlich für beliebige weitere Hostnamen wiederholen/ausdehnen, für jeden weiteren legt man beim "AltProvider" einfach weitere CNAMEs nach dem gleichen Schema mit Ziel _acme-challenge.beispiel.dedyn.io an. Da kann man beliebig viele drauf zeigen lassen. Oder man kann es auch für eine Wildcard Domain ausdehnen.

Das funktioniert ja ausgezeichnet und ist so einfach danke @JeGr !

Übrigens Strato arbeitet auch mit einem CNAME für seine Zertifikatausstellung...

Hallo nochmal,

ich habe das Problem selbst lösen können. Es ist sehr einfach, wenn man es gefunden hat.

Die Lösung:

pfSense -> VPN -> OpenVPN -> Client Export
Dort bei "Host Name Resolution" die eigene DynDNS-Adresse eingeben
Danach auf "Save as default" klicken.
Fertig.

Ich kann jetzt über meine DynDNS-Adresse von außen OpenVPN erreichen.

@slu said in IP als "ACL" in OpenVPN / kann der Client die IP überschreiben?:

Und gleich die nächste Frage (sorry), nimmst Du da immer je eine eigene CA?

Natürlich, ansonsten wäre das leicht angreifbar, indem der Client es auf anderen Ports versucht und wenn die gleiche CA verwendet wird, kommt er - rein vom Zert - dann schonmal rein. Das will man nicht :)

@heiko3001 said in pfSense und NetCologne Glasfaser:

Man nimmt es mit Kusshand, wenn keine Glasfaser verfügbar ist.

Antworten

Wenn das in der kleinen Region so ist, dann viel Glück dass es so bleibt.
Ansonsten habe ich durch Kunden in der ganzen Republik inzwischen Horrorstories, mit denen ich ein Buch füllen könnte. Und es geht da nicht um "ein bisschen Downstream eingebrochen", sondern um UPstream, der von versprochenen 50 auf unter 2-5Mbps einbricht. Davon war/bin ich u.a. auch selbst betroffen weil Großräume wie Stuttgart und Co. einfach nicht ausgebaut werden, obwohl dir 2 Jahre lang Versprechungen gemacht werden dazu.

Daher kann ich aber jeden Verstehen, der mit dem Laden und seiner Drückerkolonne, die einem mit Vorlieben Mist am Telefon verkaufen und dafür schon mehrfach abgestraft wurden, nichts zu tun haben möchte. :/

@gtrdriver said in Pfsense hinter Fritzbox + Auerswald Telefonanlage:

In einem Forum hatte ich auch mal einen Post gefunden wo Port Weiterleitungen vom Interface der FB zur Telefonanlage gemacht wurden - da hab ich auch schon probiert - aber ohne erfolg.

Ich hab zum testen mal alles an die Auerswald weitergeleitet aber auch ohne ERfolg.

Das klingt dann aber gefühlt SEHR nach Problem auf der Auerswald Seite. Denn wenn du schon alles transparent schaltest und es immer noch nicht geht, was kannst du dann auf der Sense noch einstellen wollen?

Wir haben das jetzt schon oft genug mit Starface und anderen Anlagen durchgespielt und es hat bislang bei so ziemlich allem funktioniert, entweder sind da noch Regeln die dir dazwischengrätschen und wir nicht sehen und deshalb nicht wissen oder es ist irgendein kurioses Problem zwischen Fritte und Auerswald, aber der Rest wird inzwischen recht unwahrscheinlich. Da kann man jetzt so mit der Foren-Glaskugel einfach wenig machen leider, da müsste man schon remote support rauf und alles durchtesten.

Cheers

@tschan Fein!

Ich denke das hier

0 root -60 - 0B 1328K CPU0 0 4:06 81.05% [kernel{if_io_tqg_0}]

aus deiner Prozessliste war ein Anhaltspunkt. CPU0 ist der CPU Master und wenn CPU0 ausgelastet ist, gibt es immer wieder Möglichkeit für Probleme, Drops oder Fallouts. CPU0 mit 81% auf IO Tag/Queue sieht mehr sehr danach aus, als wäre die alte kleine Celeron CPU da nicht mehr mit den Acks der Verbindung klar gekommen. Das aber nur ein Verdacht, das hätte man dann ggf. etwas länger beobachten müssen. Sieht aber schon danach aus. Da nutzen dann auch gute NICs nichts mehr, wenn die I/O Lanes oder Queues voll sind und die CPU nichts mehr schieben kann :)

Cheers

@Kharon said in Überlappende Netzwerke auf LAN Interfaces einrichten:

Wir werden dies aber dann so anpassen und vermutlich hier dann auch ein Class-C-Netz verwenden.

Vergesst irgendwelche alten Class-A/B/C Definitionen. Die sind heute quatsch. Class C ist heute nicht mehr der Stein der Weisen geschweige denn Class B. Ordentliche Netzplanung heißt sich mit CIDR (classless inter domain routing) also mit den /24, /22, /20 Masken auseinander zu setzen und zu verstehen. Auch heißt 10.0.0.0/x nicht automatisch Class A. Also bitte lies dir keinen steinalten Quatsch aus dem letzten Jahrhundert an ;)

Wichtig wenn du eh eine Neuplanung machst sind Punkte wie

Subnetting bzw. VLAN Separation: es ist heute mehr denn je wichtig, sein Netz in Subnetze aufzuspalten und per VLANs zu trennen, damit eben nicht alles im gleichen Netz rumgaukelt. Sei es um den Impact von Malware o.ä. zu minimieren, sei es um Rechtestrukturen und Policies ordentlich zu konfigurieren ohne jede einzelne IP besonders zu behandeln müssen, sei es wegen IPv6 Vorbereitung usw. Netze nicht kreuz und quer zu konfigurieren und nicht "weils schön/lesbarer ist" irgendwelchen Kram in der IP mit reinzukonfigurieren. Also nicht beim neuen Netz dann automatisch dann 172.16.0.0/18 nutzen, nur weils jetzt ein /18 ist. /18 klingt hart nach quatsch weil viel zu groß. Niemand braucht ein /16 oder /18 an einem Stück für sein LAN und wenn ers bräuchte wäre spätestens das die wichtigste Erkenntnis, dass man VLANs und kleinere Einzelnetze braucht! Netze sollten zusammenhängend konfiguriert sein. Dafür gibts sinnvolle Tools wie "visual subnet calculators", mit dem man bspw. einen /20er Bereich definieren kann und diesen dann in 16x /24er Netze aufteilen. Warum ist das sinnvoll? Weil man dann bspw. bei VPN Verbindungen das gesamte Netz mit allen VLANs mit einer einzigen Route greifen kann statt zig dutzend Einzelnetze aufschreiben zu müssen.

Sinnvolles Netzdesign und -architektur ersparen bei ordentlicher Vorabplanung Stunden bis TAGE an Debugging und Fehlersuche und machen an allen Ecken und Enden das Netzwerker-Leben leichter!

Cheers

@deylo said in pfSense auf Hetzner-Server, Anbindung 2x Unifi als Wireguard-VPN:

@JeGr Verzeihung, ich meinte OPNsense anstatt OpenVPN. Wäre aber auch eine Idee.
Performancetechnisch soll Wireguard aber schneller sein. Merkt man den Unterschied spürbar?
Theoretisch würde darüber dann sämtlicher Datenverkehr und ggf auch ein Netzwerkspeicher laufen.

Da ist leider viel altes Halb-Wissen immer wieder im Spiel. Da kursiert dann häufig "OpenVPN ist langsam", "das ist single Core", "das skaliert nicht" etc. etc.
Das meiste davon ist quatsch. Wie bei vielem hängt das immer auch stark von der Gegenseite ab. Wie bei IPsec bspw. auch. Wenn die Gegenseite nur alten Mist unterstützt, kann meine Seite leider auch nicht auf Geschwindigkeit kommen, die möglich wäre. Bei OVPN ist das ähnlich. Durch DCO, multiple Server und Co lässt sich da enorm viel an Geschwindigkeit und Flexibilität rausholen ohne die Seltsamkeiten, die WG oftmals aufwirft, weil es sich nicht um Interfaces schert.

In diesem Fall ist wahrscheinlich die Remote Seite nicht up2date und würde bremsen, daher ist vermutlich WG schneller, hat aber trotz der immer gelobten "so einfachen" Konfiguration genau beim korrekten Routing und Setup seine Probleme.

Im Prinzip bleibt da nur zu debuggen, welche Routen vor Ort ankommen, welche auf der Sense ankommen, ob die überhaupt gesetzt werden, bis zu welchem Punkt man pingen kann und Geräte erreicht etc. etc.

Cheers

Also zur Frage überhaupt (die Eingangs gestellt wurde)

Die Fritte braucht überhaupt nicht für irgendwas berücksichtigt werden.
Soweit ich das Setup verstanden habe läuft eh alles hinter deiner pfSense, egal was. DHCP, DNS, etc.
Wie das im Einzelnen eingestellt ist, ist ja noch ein anderer Punkt, aber die Fritze ist VOR der Sense, die Sense sieht sie als WAN/Internet Uplink und daher "extern" und lässt von der gar nichts zu. Also kann die Fritte auch keine Geräte intern erreichen oder ansprechen, einen internen DNS zu setzen würde also gar nichts bringen. Da du auch keine Geräte an der Fritte hast, braucht die DNS nur für sich selbst, also kannst du da einfach alles standard lassen, damit die das Internet ordentlich aufbaut und da die Sense exposed Host ist, musst du dich um sonst von der Fritte her um nichts kümmern.

Ob und wie dann dein Netzaufbau hinter der Sense dann für dich gut oder schlecht ist oder ob da Raum zur Verbesserung sind, steht auf anderen Blättern :) Aber die Fritte hat mit dem Rest des Netzes nichts zu tun. Ein Gerät von "vorne" (also direkt oder nah am Internet) nochmal an einen DNS dahinter zu verweisen ist eh meistens eine schlechte Idee, weil man damit oft Abhängigkeits-Loops baut, die dann einen sehr in der Praxis beißen können.

Cheers

@slu said in Internet Zugang "! RFC1918" vs. block RFC1918 any - any:

Hatte mir auch schon überlegt nur ein "dummy" VLAN Interface für das Zeug anzulegen, dann dachte ich mir wieder dann kann ich gleich das LAN Interface NTP/DNS freigeben...

Warum Dummy? Sowas nennt man auch Infrastruktur Netz ;) DNS, (externe) NTP (bspw. mit serial attach), Backup Proxy oder Monitoring Probe könnte man da gut reinstellen. Alles auf das ggf. zugegriffen werden muss. Also eingehend. Dann noch nen Management Netz aus dem nur ausgehend was gehen muss (und minimal eingehend aus nem Admin Netz oder von einigen wenigen spezifischen Clients). Und schon kann man die Netze relativ einfach generisch handhaben.

@slu Irgendwelche Shaper an? Das könnte dann ggf. die RRD Graphen durcheinander würfeln, dass die Werte ggf. dann zweifach gezählt werden?

@sub2010

Moin,

da wir das sehr oft und bis zum Erbrechen durchgespielt haben mit AVM:

Sollte das Exposed Host Ding wieder Probleme machen, hilft meistens wie folgt:

Exposed Host und alle Freigaben löschen alle pfSense Nodes und/oder Switches abziehen, so dass die Fritte nichts *sense-iges mehr sieht alle Einträge aus der "home" Ansicht (dem Heimnetz oder wie AVM es zum Zeitpunkt dann auch immer nennt) rauslöschen. Kein Gerät sollte da mehr drin sein (außer ggf. dem einen, von dem du aus konfigurierst). Vor allem die Sensen und der Exposed Host Eintrag! Sicherheitshalber die Kiste neu starten Nochmal checken, dass alle Freigaben und Homenet Einträge raus sind (außer dem konfigurierenden Rechner) Dann über die "Internet / Freigaben" ein "Gerät für Freigaben" hinzufügen. WICHTIG: KEIN Gerät auswählen, sondern IP-Adresse der CARP-VIP manuell eingeben!! Die IP für Exposed Host freigeben, IPv6 komplett ignorieren! speichern

Danach erst Switch/Sensen wieder anstecken und dann prüfen, ob das die CARP auf WAN zwischen den Boxen wieder sauber läuft und ob die CARP VIP wieder sauber Traffic von draußen bekommt.

Die Fritze bekommt hin und wieder durch Einstellungen mal kompletten Kopfsalat und matcht in ihrer Heimnetz Übersicht dann mal wild irgendwelche Geräte auf andere Geräte und behauptet dann das wäre das Richtige. Wenn man in dem Zustand irgendwas an der Konfig ändert, kann es sein, dass dann statt der Freigabe auf die IP, eine Freigabe auf die Geräte Hardware/MAC gemacht wird und das ist bei CARP dann eher suboptimal. Oder er behauptet beim Failover, dass es plötzlich ein neues Gerät gäbe (weil andere Base MAC auf anderer IP etc. etc.) usw. wir haben da schon die kuriosesten Anzeigefehler gehabt. Solang man die Box aber in Ruhe lässt und die Freigabe auf die IP geht, ist/war alles fein.

Cheers :)

@NSuttner said in Nach Upgrade auf 24.11 - Nessus Scan zeigt HIGH Vulnerability OpenSSH < 9.8 RCE?????:

@ricoooww Hi, that's what i meant, wrong (old) OpenSSH version in use again!! Regards, Sutti

Antworten

Das ist falsch. 24.03 hatte nicht 9.7p1, sondern 9.6p1. Da wir mehrere Versionen im Lab haben ist das einfach nachzuprüfen:

[24.03-RELEASE][admin@pfs-plus-2403.lab.test]/root: ssh -V OpenSSH_9.6p1, OpenSSL 3.0.13 24 Oct 2023 [24.11-RELEASE][admin@pfs-plus-2411.lab.test]/root: ssh -V OpenSSH_9.7p1, OpenSSL 3.0.14 4 Jun 2024

Erneut: Sich NUR auf einen stumpfen Versionsvergleich bei einem Scan zu verlassen trifft keine Aussage darüber ob eine bestimmte CVE Version gepatcht wurde oder nicht.
Dafür gibt's ne CVE Übersicht, nen Audit Kommando oder andere Funktionen, mit denen ich prüfe, ob das OS an der Stelle für Paket X ein Patch Y drin hat oder nicht. Wenn ich das nicht habe oder direkt den Hersteller/Dev angehe, dann muss ich mich auch auf das Verlassen, was mir gesagt wird. Wenn ich aber hinterher hingehe und sage "glaub ich nicht" - bringt das halt wenig ;) Entweder ich belege dann durch Exploit dass es nicht gepatcht ist oder muss meinem Hersteller glauben, der sagt, dass in der neuen Version eine gepatchte SSH Version bereit steht.

Nur ein Beispiel auf unserer Farm mit VMs eine Ubuntu VM:

jegr@atlanta:~$ ssh -V OpenSSH_9.6p1 Ubuntu-3ubuntu13.7, OpenSSL 3.0.13 30 Jan 2024 jegr@atlanta:~$ pro fix CVE-2024-6387 CVE-2024-6387: OpenSSH vulnerability - https://ubuntu.com/security/CVE-2024-6387 1 affected source package is installed: openssh (1/1) openssh: A fix is available in Ubuntu standard updates. The update is already installed. ✔ CVE-2024-6387 is resolved.

Man siehe: gleiche angeblich "kaputte" OpenSSH Version, wurde aber gepatcht/gefixt. Trotzdem nerven solche Scanner immer noch, weil sie denken "Oh nein! Die kann gehaxxx0rt werden!"
Nein kann sie nicht.
"is resolved" heißt hier übrigens wirklich gepatcht, wäre das nicht notwendig weil Version zu alt oder nicht betroffen steht bei Ubuntu hier statt dessen "... does not affect your system". Das wird also unterschieden.

Und man glaubt nicht, wie viele solche stupiden Scans inzwischen als "Security" angeboten werden ohne jegliche Einschätzung, Einstufung oder Prüfung. Da fällt dann hinten raus ein x-100 Seiten Bericht, der dann voller Zorn an den Hoster, Betreiber, Whoever geht und der (wir) müssen uns dann durch solche stumpfsinnigen Berichte wühlen und automatisiert alle CVEs abfragen und die Antworten ausgeben, damit die Leute zufrieden sind. Weil wir ja nicht genug zu tun haben.

Also sorry wenn der Ton sich vielleicht zwischendurch mal schärfer angehört hat, das ist damit nicht gemeint und nicht persönlich, aber dieses CVE-Gereite ist eine sehr unschöne Begleiterscheinung der letzten 1-2 Jahre, in denen Startups mit solchen Scannern aus dem Boden sprießen, Gelder bekommen weil ist ja für Sicherheit und dann für uns massive Zeitverschwendung generieren.

Cheers :)

@hornetx11-0

um das nochmal klar zu definieren: Ablauf der Lizenz (TAC lite) setzt KEINE Funktion aus. Nur die Update Server sind dann eben nicht mehr erreichbar für ein Plus Update, man kann aber auf CE downgraden wenn man unbedingt möchte. Bei einem größeren Vorsprung von Plus sollte man aber nochmal prüfen. Aber abgeschaltet oder unsicher wird da deshalb nichts.

Cheers

@Conger1892 said in ERR_TUNNEL_CONNECTION_FAILED:

hat bisher auch immer zu 100% funktioniert doch aktuell haben wir das Problem "ERR_TUNNEL_CONNECTION_FAILED"

Ich komme via IP Adresse auf die Firewall und andere Server aber nicht mehr via Namensauflösung.

Das hat aber doch mit dem ERR_ oben nichts zu tun? Oder woher kommt dieser Error Name?

Er hatte dieses Problem 1 Woche vor mir.
Habt ihr eine Ahnung woran es liegen könnte, ich bin langsam aufgeschmissen.
Was habe ich bisher gemacht:

Logs überprüft / Namesauflösung bei pfsense via Ping etc funktioniert
DNS Flush etc auf dem Windows Rechner durchgeführt
Danke für eure Hilfe

Und was ist mit Prüfung des DNS auf dem Client?

Welcher DNS wird gepusht? Ist der erreichbar mit allen notwendigen Protokollen? Gibt der manuell aufgerufen ne Antwort? (host, nslookup, dig, whatever tools you have) Was sagt das Log des VPN Aufbaus? Wie ist der Server/Client überhaupt konfiguriert? Wird DNS gepusht? Eine Domain? Suffix?

Ohne Details wird das schwierig aus dem Raum raus zu beantworten.

Cheers

@Bob-Dig Danke Dir. Ich habe es gefunden.

Jetzt funktioniert es.

Sorry, würde Dich ja "upvoten", darf ich aber nicht (zu wenig Reputation).

EuroPC