@JeGr
Vielen Dank für Dein Kommentar.
Und ich war der Meinung, dass ein Tunnel mit zwei Peers normal ist. Hoffentlich war das der Fehler. Ich mache mich nachher gleich an die Arbeit und teste es.

@styles1986 Es geht ja um OpenVPN als Technik. Welcher Client spielt da eher untergeordnet eine Rolle, es sei denn Tunnelblick ignoriert plain & simple OpenVPN Standards? Denn wenn der OpenVPN SERVER(!) ein Push für ein DNS Suffix schickt, hat der Client das zu verarbeiten, ansonsten würde ich da mal bei Tunnelblick die Bug-Report-Glocke läuten :) Denn OpenVPN sieht im Server Part den Push vor, Tunnelblick implementiert aber auch nur OpenVPN Version X? und sollte entsprechend dann auch nach Specs des Clients damit umgehen.

Und soweit ich auf der Projektseite lese, implementiert Tunnelblick einen Wrapper für OpenVPN 3 und 2.6 - und 2.6 hat im Spec genau das Verhalten definiert für Apple/Mac wie oben beschrieben. Wenn Domain angegeben, pushe das als Suffix und nutze den gepushten DNS Server für genau dieses Domainsuffix. Wenn das nicht geht würde ich wie gesagt im Bugtracker mal nachhaken, das hört sich dann falsch an.

Ist übrigens leider auch bei vielen Linux GUIs der Fall. NMCLI/Network Manager bei Linux ist ein einziger Clusterfuck was das angeht. Angeblich wird OpenVPN unterstützt, beim Import werden aber wichtige Keywords schlicht nicht erkannt oder werfen Fehler, die im Spec seit 2.5 Standard sind. Startet mans einfach als Console-Command via openvpn --config <config.ovpn> klappt plötzlich alles. Meh...

@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

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

Tja, leider sieht so etwas wohl die Fa. AVM nicht vor.

Warum sollten sie nicht?
Ich hab die lustige App auch drauf um ab und an mal das Anrufprotokoll anschauen zu können. Das geht. Und selbst Call signalling funktioniert oft. Und das sogar mit 2 unterschiedlichen Boxen ;)

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

"Ein Zugriff aus verschiedenen Netzen bzw. VLANs ist derzeit nicht vorgesehen, da die Suche nach der FRITZ!Box mit SSDP über UPNP abläuft. Dies geht bei unseren FRITZApps immer nur im selben Netzwerksegment und niemals über VLAN-Grenzen hinweg.

Support != Realität. Ja die Jammern dir immer was vor mit uPNP und Murks, Realität sieht anders aus. Einfach übers Zahnrad, Add Fritz!Box und dann unten die IP angeben. Bumms und gut. Ui doch kein uPNP. Ist schlimm, dass die ihr eigenes Produkt nicht mehr kennen :/

Bei mir stehen die Boxen zwar als WAN1/2 VOR der pfSense, das macht aber keinen Unterschied zu anderem VLAN, denn so oder so sind sie in einem anderen Netz.

Der Einzige Knackpunkt: Ich musste den Boxen den Rückweg erklären. Also Route für das Netz der Mobiles eintragen, damit er weiß wohin er den Kram zurückschicken muss. Und eine NO NAT Regel (da die Boxen bei mir ja vor der pfSense als WAN stehen und dort genattet wird) für das entsprechende 192.168.17x.0/24 Netz definieren, damit der Weg dahin nicht via NAT versaut wird. Warum? Weil ansonsten SIP/RTSP mies gelaunt ist und seine Telefon/Sprachübertragungsports nicht mehr gebacken bekommt. Aber wenn sich der Kram mal gefunden hat, funktioniert es.

Gleiches übrigens vom Rechner aus. Da kann man bspw. mit einem zusätzlichen SIP User auf der Fritte (VoIP Gegenstelle einrichten) problemlos auch mit MicroSIP auf dem Desktop telefonieren. IP der Fritte als SIP Server, Username/PW wie definiert, Domain ist auch die IP, Wahlschema noch modifizieren und fertig.

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

@tschan hier noch down/upload gleichzeitig, keine probleme
SCR-20250117-piph.png

@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