Zurück zu LEDE…?

[Parsec]

1&1 ist überwiegend ein Reseller ohne Netz
VLAN 7 ist ein Zeichen, dass der Anschluss über die Telekom gemietet ist.

Wie sind die ersten 4 stellen deiner IPv6 Delegation?

Dass die Zuweisung des IPv6 Netzes über die IPv6 Adresse bezogen wird ist eine Verfahrensfrage, hat aber genau 0 damit zu tun, ob hinter natives IPv6 läuft.
Es geht nur darum wie die ipadressen bezogen werden.
Dual Stack ist sowieso, dass was man haben will, also sei doch froh!

Außerdem legt das der Provider fest und nicht der Router.

Zu Openvpn:
Net30 ist veraltet - daher wohl der Zusatz im Dokument best to avoid this

P2P funktioniert nur wenn kein Windows client vorhanden kann aber in pfSense ausgewählt werden

Subnet ist der pfSense default im Dokument von dir als The preferred topology for server/client setups

Ipfire und LEDE haben mit genau den Einstellungen funktioniert mit denen auch pfSense funktioniert. Der Bug in 2.4.1 ist das was es ist — ein Bug

[khllo]

du hast Recht, es ist nur ein Zeichen, aber ohne funktioniert das nicht. Ich habe nur die Frage gestellt, wenn ein natives ipv6 ist, warum den Click über die o.g. Option?

Über OpenVPN : habe ich eingestellt wie es beschrieben wurde (bestimmt mit ein paar Änderungen) und es läuft einwandfrei

–mode server
--tls-server
--dev tun
--topology "subnet"
--push "topology subnet"
--ifconfig 10.8.0.1 255.255.255.0
--push "route-gateway 10.8.0.1"
--ifconfig-pool 10.8.0.2 10.8.0.199 255.255.255.0
--client-config-dir /vpn/ccd-dir

topology ist subnet und nicht p2p oder net30

[-flo- 0]

@khllo:

Mit 2.4.1 ist ein Bug. Ok. Danke @parsec. Es wurde fett dokumentiert, und danach behoben mit 2.4.2

Also das steht zwar fett in den Release Notes, aber ehrlich: Sowas sollte nicht in einem Release passieren. Wie auch immer das verursacht worden ist, da hat sich jemand jedenfalls nicht mit Ruhm bekleckert.

Und übrigens: pfSense präsentiert in der Update-Funktion lapidar "Current Base System 2.4.0 / Latest Base System 2.4.1" und bittet anhand dieser Information schlicht um "Confirm". Bei einer solchen Funktion erwartet nicht jeder, daß er unbedingt Release Notes lesen muß …

Aber wer installiert schon zeitnah die neueste Version, wenn er ein laufendes System hat? ;D

[Parsec]

Mit Ruhm bekleckert - sicherlich nicht ! - schon gar nicht wenn man bedenkt, warum diese Änderung gemacht wurde !

Release Notes, sollte man immer lesen - allerdings ist es mir auch passiert - zum Glück habe ich immer das vorheriges Image am IPMI des Router parat.

[JeGr]

Genau. Die Kritik von Flo oder Parsec ist durchaus berechtigt. Das Release war an der Stelle eben leider Murks, allerdings muss man sich eben auch mal die pfSense Seite anschauen und deren Input, wie viele Installationen da ggf. betroffen sind von DSL und Tagging. Sollte es passieren? Nö, klar. Kann es passieren? Jap. Allerdings war 2.4.1 durch diverse Gegebenheiten ja leider notwendig, Stichwort WPA2/CRACK und Co und da musste das Bugfix Release raus. Da ist es dann leidige Abwägung ob man es bringt und schnell weiter baut um das wieder hinzubekommen mit 2.4.2 oder ob man deshalb das große Bugfix verschiebt. Nicht einfach, aber Release Notes sollten wie Parsec schon schreibt schon gelesen werden, gerade bei so frühen Versionen wo eben nochmal ein Bug mit reinfliegen kann. Und ja der Link zu den Release/Change Notes sollte auch in die UI, fände ich auch sinnvoll.

Bei den restlichen Punkten finde ich es schön, dass auch andere das so sehen wie ich, da bin ich wohl doch nicht der grumpy Nörgler ;) Ich denke hier eher, dass sich der OP zum einen nicht ausdrücken kann (die Texte sind teils wirklich schwer zu verstehen von Satzbau und Co. - wenn Deutsch nicht deine native Sprache ist, warum dann nicht ins entsprechende Sprachforum posten?) und zum anderen sich nicht wirklich beschäftigt hat, dass das was er will teils bereits da ist und er es nur nicht verstehen möchte. Bestes Beispiel ist das Server Snippet des OpenVPN - wenn ich das nicht falsch gesehen habe ist das völlig normaler OpenVPN Standard. Verstehe also die unnötige Kritik an OVPN in pfSense nicht. Eher das Prinzip/Verhalten des Server nicht verstanden.
Andere Topics wiederum sprechen dafür, dass man elementare Funktionen von Netzen und Routing nicht verstanden hat (blocken von Geräten im selben Subnetz der Firewall anlasten - hätte Viragomann da keinen halben Roman geschrieben wäre das auch der pfSense angelastet worden). Dass er da bei LEDE und Co keine Antwort auf seine Frage bekommen hat ist mir dann klarer.

[jahonix]

@-flo-:

…Bei einer solchen Funktion erwartet nicht jeder, daß er unbedingt Release Notes lesen muß ...

@https://doc.pfsense.org/index.php/2.4.1_New_Features_and_Changes#Known_Issues:

…may prevent PPP sessions from working on VLANs in some cases...

Um das mal deutlich zu übersetzen:
könnte unter Umständen in einigen Fällen dazu führen, dass…

Das ist Bullshit, denn es führt bei VLAN Nutzung mit PPPoE immer zu einem Problem. Und das sind in D zumindest alle Telekom-Nutzer und deren Reseller, zahlenmäßig die größte Nutzergruppe. Hurra!

Eine so tiefgreifende Änderung in einem Point-Release, die mangels ausreichenden Tests zu einigen Katastrophen geführt hat, ist schlichtweg inakzeptabel.
Noch dazu sind die Releases Notes schwammig formuliert. Aber als "seriöse Firma" schreibt man halt nicht in die Rel-Notes: führt bei Verwendung von PPPoE über ein VLAN zu einem Funktionsausfall, welcher mit dem in Entwicklung befindlichen, nächsten Point-Release behoben wird.

[Parsec]

Ich betreibe ein halbes Dutzend pfSense Systeme auf ESX 6.5 , aufgrund des weiteren Fehler (Verdachts) muss da erst mal 2.3.3 drauf bleiben
:)

[JeGr]

Nunja, inakzeptabel ist relativ. Wie sie im Ticket schreiben: Die Anzahl Leute, die das Problem mit VLAN >1000 mit Namensproblem treffen war größer als die, die mit PPP und VLAN dann in Probleme liefen. Und das Update musste raus. Also was machen? Das kleinere Übel genommen, verärgert wäre so oder so jemand gewesen.

Es ist nicht toll, aber ich kanns nachvollziehen und es wird auch nicht unter den Teppich gekehrt:

We'll be fixing this in 2.4.2, current ETA is ~2 weeks so if you're affected, just hold off and wait for 2.4.2.
Priority changed from High to Very High

Ist also nicht so, dass es Low Prio ist. :) Zudem kommt das eigentliche Problem aus dem 'mpd', nicht von der VLAN Änderung, die eigentlich durchaus sinnvoll ist, dass man sich an normales und originales IF Handling angleicht.

In den aktuellen Snapshots für 2.4.2 ist es enthalten und soll bereits halbwegs sauber laufen.

[Parsec]

bei mir  läuft es unter 2.4.2 wieder problemlos

[khllo]

@parsec: schön zu wissen dass alles wieder problemlos mit 2.4.2 funktioniert. (über den Punkt fett dokumentiert und Fehler mit einem "Stable Release", oder lesen bevor updaten, möchten wir wirklich nicht mehr darüber diskutieren, es bringt echt garnicht).

Über Standart Einstellung von OpenVPN, möchte ich auch nicht mehr mit dem Moderator JeGr diskutieren, WEIL, und EINFACH zu verstehen, TUTORIAL lesen wie du die ganze ZEIT gesprochen hast, LESEN UND LERNEN, ich rede über eine Funktion ifconfig-pool, genauso ein DHCP Server auf einem normalen Interface, Ok, bitte einfach sagen: OpenVPN auf Pfsense erlaubt diese Funktion nicht, weil es nach Standard eingestellt ist (als Server mit vollem Subnet), Punkt aus. Ich kritisiere nicht, ich habe eine Frage gestellt und ein paar Punkte zu diskutieren, und danach kam das Attack von jeder Ecke, echt lächerlich. Und bitte, bilde zunächst dein Interface ohne DHCP Server, und stell die Frage nicht, warum braucht man ifconfig-pool in der Einstellung von OpenVPN, TUTORIAL BITTE LESEN.

Native IPV6 oder Dual-Stack??? BITTE: UND MIT CAPSLOCK, OFFENE DISKUSSION SPÄTER IN PFSENSE FORUM.
wir sprechen über "Ipv6 prefix über Ipv4 ziehen", es steht in der Dokumentation von pfsense: SUPPORT FOR NATIV IPV6, sehr schön bis jetzt, dann bitte, erkläre mir bitte den Punkt Herr Moderator, ist Dual-Stack genauso nativ IPV6??? es bringt auch nicht zu diskutieren darüber. Wenn das echt native IPV6 ist, soll pfsense von allein den Prefix von ipv6  definieren ob es 56 oder 60 oder 62, und nicht manuell einstellen, ohne click hin und her, oder??????????????????? lieber probieren und nachgucken… wir warten zusammen bis ISP aufhört, IPV4 zu verteilen, und weiter mit nur IPV6 zu arbeiten, und schauen wir später was es passieren würde...

1. Natürlich gibt es Unterstützung von nativem IPv6. Komisch dass das bei genug Menschen funktioniert. Und "Man muss klick machen auf V6 over v4" damit es funktioniert spricht eher davon, dass du nicht weißt was du tust. Da steht explizit v6 über v4 "beziehen". Das heißt nicht dass man v6 über v4 tunnelt was eine ganz andere Baustelle wäre. Warum sollte das also kein natives v6 sein…
   WAN einstellen machen zudem genug Leute tagtäglich ohne Probleme. Dass du hier von VLAN 7 - also einer Telekom TDSL Spezialität schreibst - ist auf genau das zuzuschreiben: deinem ISP der das (noch) via VLAN7 macht. Wer sich ein wenig informiert erfährt zudem, dass auch die Telekom das bereits abschafft und man bereits neue Anschlüsse ohne diese Einstellung hat. Das hat also wieder nichts mit pfSense, sondern deinem Anschluß und Widerwillen zu tun, dich ein wenig einzulesen oder zu informieren (oder einfach zu fragen). Dann bastelst du noch mit einem Bridge Interface - was nicht ganz trivial ist - und das soll dann Schuld von pfSense sein? Merkwürdig.

Ich habe die Lösung für das Problem mit "Firewall under the same subnet" von einem Informatiker, der mit LEDE bzw OpenWRT project beschäftigt gewesen ist, und ich habe die Frage da gestellt, weil es unklar gewesen ist, wie man den Bridge Network einstellen soll unter pfsense. Ich glaube, dass du, wegen ein bisschen Kritik, deine Nerven verloren hast, Herr Moderator, und willst du alles persönlich drehen

Andere Topics wiederum sprechen dafür, dass man elementare Funktionen von Netzen und Routing nicht verstanden hat (blocken von Geräten im selben Subnetz der Firewall anlasten - hätte Viragomann da keinen halben Roman geschrieben wäre das auch der pfSense angelastet worden). Dass er da bei LEDE und Co keine Antwort auf seine Frage bekommen hat ist mir dann klarer

Vergiss alles, Herr Moderator, und lösch alles wie du möchtest später, aber schreib dazu auch, bitte kein Kritik hier, auch die Kritik zur Verbesserung, WIR SIND PERFEKT, und bitte LESEN UND LERNEN, besonders die Höflichkeit.

[Parsec]

@khllo

Irgendwie lohnt es sich wirklich nicht mit die eine Diskussion anzufangen!
Ich glaube deine Idee wieder auf LEDE zu wechseln ist wirklich besser für dich!

Allerdings gibt der ISP vor wie sich die Geräte die IP Adressen besorgen - das wird in LEDE beim gleichen ISP auch nicht anders sein
Natürlich ist IPv6 im Dualstack natives IPv6
Dual-Stack bedeutet nichts anders als vollwertiges IPv4 und vollwertiges natives IPv6 parallel über den selben Anschluss.
Das ist aktuell die Idealform einer Internetverbindung.

So und nun ist mir hier meine Zeit zu schade – schönes Leben noch.


[khllo]

Wie ich dachte, Kritikunfähig.

Ich finde es auch genauso, es lohnt sich nicht mehr mit euch zu diskutieren.

Schade dass ich die Zeit verloren habe, vernünftige Antworte und vorgesehene Lösungen hier zu suchen. Mein Ziel war, die Punkte zu erklären, bis die erste Antwort kam, als Attack… echt Schade.

Und ich glaube, zurück zu LEDE ist kein Schimpfwort.

Ich glaube deine Idee wieder auf LEDE zu wechseln ist wirklich besser für dich!

Bleibt wie ihr seid ist besser für euch – ein wunderschönes Leben noch!.

[monstermania]

@khllo
Hmm,
ich hab das jetzt nur am Rande verfolgt, aber manchmal sollte man einfach mal den Ball flach halten.
Was hast Du für pfsense selbst bezahlt!? Und was bist Du bereit für den Support zu zahlen!? Sind Alles nur Menschen im Forum hier, die noch dazu freiwillig und unbezahlt versuchen Hilfe bei Problemen zu leisten. Beim geschriebenen Wort mag das Eine oder Andere schon mal barscher rüberkommen, als in einem Gespräch von Face2Face. Von daher sollte man nicht Alles auf die Goldwage legen!
Auch ist die Lernkurve beim Einsatz einer komplexen FW-Lösung wie pfsense schon recht steil.

Ich habe das gerade kürzlich an anderer Stelle geschrieben.
1. Investiere einfach etwas Geld und hole Dir Jemanden dazu, der Dir Deine pfsense sauber konfiguriert.
2. Investiere eigene Arbeit/Aufwand um die pfsense selbst zu konfigurieren.

Ja, wenn du der Meinung bist, dass Du z.B. mit LEDE besser fährst, sei die Frage erlaubt, warum Du denn überhaupt pfsense einsetzen wolltest!? Ist ja ungefähr der Vergleich zwischen Äpfeln und Birnen.
Ich selbst bin auch von ipfire über pfsense bei einem anderen Projekt gelandet. Einfach, weil es für meine persönlichen Anforderungen besser gepasst hat.

Gruß
Dirk

[JeGr]

Jeder bekommt was er verdient. Und das ist nicht negativ gemeint. Wenn man sich allerdings aufregt, dass man kritikunfähig wäre und unfähig ihn zu verstehen, der möge mir bitte erläutern, wie ich einen Absatz wie diesen zu verstehen habe (Moderator können wir streichen, denn wenn man auf der Ebene und mit CAPS diskutiert, ist eh schon alles zu spät). Aber kann mir jemand überhaupt diese Absätze erläutern?

Über Standart Einstellung von OpenVPN, möchte ich auch nicht mehr mit dem Moderator JeGr diskutieren, WEIL, und EINFACH zu verstehen, TUTORIAL lesen wie du die ganze ZEIT gesprochen hast, LESEN UND LERNEN, ich rede über eine Funktion ifconfig-pool, genauso ein DHCP Server auf einem normalen Interface, Ok, bitte einfach sagen: OpenVPN auf Pfsense erlaubt diese Funktion nicht, weil es nach Standard eingestellt ist (als Server mit vollem Subnet), Punkt aus. Ich kritisiere nicht, ich habe eine Frage gestellt und ein paar Punkte zu diskutieren, und danach kam das Attack von jeder Ecke, echt lächerlich. Und bitte, bilde zunächst dein Interface ohne DHCP Server, und stell die Frage nicht, warum braucht man ifconfig-pool in der Einstellung von OpenVPN, TUTORIAL BITTE LESEN.

Native IPV6 oder Dual-Stack??? BITTE: UND MIT CAPSLOCK, OFFENE DISKUSSION SPÄTER IN PFSENSE FORUM.
wir sprechen über "Ipv6 prefix über Ipv4 ziehen", es steht in der Dokumentation von pfsense: SUPPORT FOR NATIV IPV6, sehr schön bis jetzt, dann bitte, erkläre mir bitte den Punkt Herr Moderator, ist Dual-Stack genauso nativ IPV6??? es bringt auch nicht zu diskutieren darüber. Wenn das echt native IPV6 ist, soll pfsense von allein den Prefix von ipv6  definieren ob es 56 oder 60 oder 62, und nicht manuell einstellen, ohne click hin und her, oder??????????????????? lieber probieren und nachgucken… wir warten zusammen bis ISP aufhört, IPV4 zu verteilen, und weiter mit nur IPV6 zu arbeiten, und schauen wir später was es passieren würde...

Außer einem Rage-Quit kann ich das Geschriebene wirklich leider gar nicht verstehen. Und ja, wir sind hier weder bei pfSense, Netgate oder sonstwem angestellt, sind keine bezahlten Supportkräfte oder sonstwas, sondern einfach nur normale Menschen, die hier im Forum helfen. Allerdings kann man nicht helfen, wenn man nicht verstehen kann, was gefragt wird. Der Text im Zitat springt zwischen Frage und Aussage (und Schreikrampf) hin und her, dass ich trotzdem leider überhaupt nicht verstehe, was überhaupt das Problem ist. Weder mit OpenVPN, noch mit IPv6.

Tut mir leid, aber wie ich früher schon geschrieben habe: entweder ist der OP kein nativ deutsch-schreibender - dann frage ich mich, warum er seine Fragen nicht im Forum seiner Sprache gestellt hat - oder er hat eine Schreibschwäche. Das tut mir natürlich leid, aber wenn man seine Frage nicht in einer Art stellen und diskutieren kann, die nicht mehr Fragen aufwerfen als sie lösen sollen, dann ist das Ganze zum Scheitern verurteilt. Und damit lassen wir es wohl gut sein. Keiner hat es hier nötig, dass man ihn persönlich beleidigt oder über einen fiktiven Posten (wie Moderator) definiert. Nur weil man Beiträge editieren und verschieben kann, macht das niemand zu einem Überwesen. Genauso wenig müssen sich andere Schreiber für ihre Hilfe maßregeln lassen.

Es gibt einen Grund dafür, dass es verschiedene Projekte und single-Click Tools gibt. Jedem das Seine.