@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

@MaxMixer Wir haben das mit einer Digibox2 laufen. Funktioniert fut. Klar, eine pfSense wäre mir da lieber.

Die Fritzbox erlaubt es noch, einen LTE Stick als Backup zu nutzen. Hatte ich auch erfolgrewich im Einsatz. Nut die Geschwindigkeit war halt mies, was aber wohl eher am LTE- Vertrag mit FreeNet lag.

Cheers,
EuroPC

@slu said in Deutsche GigaNetz - IPv4 Routing:

Stimmen die Firewall Rules?

Also die Firewall Rules fürs LAN sind eigentlich per default richtig. Da ist ausgehend erst einmal alles erlaubt. Da die pfsense aber zuvor hinter einer Fritte war, können natürlich sowohl in den Firewall Rules wie auch an andere Stelle (Routing) noch irgendwelche Altlasten an Regeln vorhanden sein, die nun zum Problem werden, da nun unpassend.
Aber ohne weitere Infos ist das eh alles reine Spekulation.

Danke Viragoman!

Hab es eingerichtet, finde die Einrichtung allerdings nicht wirklich trivial und nicht gerade selbst erklärend.
Anbei ein paar Screenshots der Einrichtung.
Wenn ich es so einrichte, bekomme ich einen Fehler auf dem Mailgateway.
Evtl. fällt euch der Fehler auf.Mailserver.JPG Frontend2.JPG Frontend1.JPG Backend.JPG

Hallo

Nach einiger Zeit und weiteren Fortschritten wolle ich meinen Stand mitteilen.
Ich habe nun einen Tp-Link Accesspoint EAP 225 eingebunden , habe Ihm eine feste IP
zugeteilt und verwalte den AP über Omada Lokal , welches auf einem Raspberry Pi4
läuft.

MFG

@NOCling said in Gibt es bzgl. PFSense irgendwelche Besonderheiten zu beachten bei einem WLAN Call von iPhone zu Telekom Mobile?:

Dafür richtest du doch einfach mal sauber das Monitoring in der pf für das WAN GW ein.

Dann kannst du sehen ob an dem Zeitpunkt ggf. das WAN mal ein wenig lost hatte.

Und es gibt auch nur eine WAN Verbindung?
Sonst muss dich gleich um die Stickyness kümmern.

Das die Clients Netzhopping machen kannst auch ausschließen? Sprich auf bestimmten APs im falschen VLAN oder gar keinem landen?

Weil States sind jetzt swid 24.03 Int bound und nicht mehr Floating based.

Das hab ich glaube ich, muss nochmal nachsehen. Ich glaube ich hatte es mal
bei einem anderen Kunden rausgenommen, da in einer FW-Version oder am
Anschluss ein Problem war und da hatte zumindest der automatische Refresh
zu noch mehr Problemen geführt.

Ja, nur ein WAN in diesem Fall.

Nun, hopping der Clients vielleicht nicht zu absolut 100%. Aber es gibt auf allen
APs die für die Clients relevante SSID, in diversen Tests habe ich auch wunderbar
gesehen, dass die Clients von AP zu AP innerhalb des richtigen VLAN springen.
Ich sehe die Clients auch immer im richtigen VLAN, also bis auf dass es u.U.
vielleicht wirklich mal zu einem ganz seltenen Fall kurzzeitig passiert, kann ich
es ausschließen.

Wenn sie in keinem landen würden, dann würde ja auch Internet nicht mehr
funktionieren. Bisher habe ich aber immer die Meldungen gehabt, dass WhatsApp
oder E-Mails dann immer noch funktioniert hat. Nur SMS und der WLAN Call
wurde mir als Problem gemeldet. D.h. die Clients müssen noch mit dem WLAN,
dem VLAN und dem Grunde nach mit dem Internet verbunden gewesen sein.

Aktuell ist diese FireWall noch auf 24.03, hier habe ich noch kein Update auf 24.11
gemacht. Bei mir schon, aber ich betreibe aktuellste Firmware eigentlich immer
erstmal einige Wochen/Monate bei mir bevor ich Kundensysteme aktualisiere.

Ich hatte gestern nochmal die FireWall Konfig mit anderen verglichen und hatte
(warum auch immer) tatsächlich noch Unterschiede gefunden:

Advanced > FireWall & NAT > Hardware Checksum Offloading: war hier noch aktiv, ist jetzt aus (wie eigentlich in allen anderen FW) Advanced > FireWall & NAT > Firewall Optimization Options: steht jetzt wieder auf Normal + Erhöhung der UDP timeouts Advanced > FireWall & NAT > IP Do-Not-Fragment compatibility: war an, ist jetzt mal aus
Ich habe hier aktuell auch die erwähnten VPN Einstellungen hierzu nicht gesetzt, ggfls. teste ich die dann noch.

Mal sehen ob damit in den nächsten Tagen/Wochen eine Änderung feststellbar ist.

@wiliam025 said in CFA: 24.11 mit Squid?:

Users who didn’t have Squid or didn’t update from CE has not faced this issue.

We are not discussing the problem, my thread is about testing the hypothesis IF that is related to ONLY CE upgrades or if old Plus installations are also about to hit that at some point or not. :)

As I debugged that problem in the original thread I'm very aware about the problem.

@quickmo said in Wireguard Site to Site keine Verbindung vom Client:

1 <1 ms <1 ms <1 ms unifi.localdomain [192.168.2.1]
2 42 ms 26 ms 29 ms 10.0.20.1
3 * *

Die Route wäre die IP des Clients, der dann im Wireguard-Tunnel selbst die 10.0.20.2/32 erhält, dann noch den 10.0.20.1/32 erreichen (Standort A) kann.
Kann der Client dann noch den 10.0.20.5/32 anpingen?
Das 10.0.20.0 selbst ist aber ein /24?