Jessie auf Pi 3 B im HomeLan mit div. Aufgaben (Probleme mit dem VPN)

  • Werte RasPi-Gemeinde...

    Einen Vorstellungsbereich für NeuUser habe ich nicht gefunden und stürze mich daher direkt "in die Fluten" :) ...

    Ein zufällig gefundener Beitrag auf einem Blog ("welches Netzgerät macht hier so viel Traffic" = Klick !) machte mir Lust auf so einen kleinen Pi. Da ich früher (gehe nun stramm auf die 50 zu) mich schon häufiger mit Linux (frühe Debian Distri's - ich erinner mich ganz dunkel an Potato, Woody und Lenny etc.) auseinandergesetzt habe, hatte ich wenig Angst davor, muss aber eingestehen, dass ich zwar früh mit der Computerei begonnen habe (1988 mit einem 8088@4,77MHz mit 640 kB RAM und 5 1/4 " Laufwerk mit 360 kB Kapazität) und mich seither kontinuierlich weiter entwickelte (alle PCs wurden selbst gebaut und nicht konfektioniert gekauft), softwareseitig wurde ich aber größtenteils von der M$-dominierten Industrie begleitet (mit Ausnahme von fli4l auf nem PC-Engine, der Dreambox und der Dbox2 :stumm: ).

    Insofern habe ich wohl doch erhebliche Lücken, weiß aber zumindest ungefähr, wie Linux "tickt". Mein Favorit ist der MidnightCommander, den ich noch als NC aus DOS-Zeiten (Ver 3.21 aufwärts) zu schätzen weiß. Dies nun einleitend, damit Ihr wißt, mit wem Ihr es zu tun habt...

    Bei P*llin habe ich nun einen Quadcore Pi 3 Model B ergattert mit dazu passendem Netzteil und Gehäuse sowie 32 GB SD. Prima!

    Installation und Erstinbetriebnahme problemlos, ich verwendete das Raspbian Jessie with PIXEL, Version: November 2016, Release date: 2016-11-25.

    apt-get update und apt-get upgrade habe ich schon verinnerlicht (vom Fernseh-PC = yaVDR)

    Nun, was soll er (ist Pi eher maskulin oder neutrum?) denn drauf haben?

    Mein Netz:
    Fritz 6360 cable -- 192.168.178.0/30 -- RasPi -- 192.168.1.0/27 (GigaBit) -- div Netzgeräte -- Edimax AP (2.4/5 GHz) - 3x Android Smartphone, 2 Netbooks...

    RasPi:
    eth0 static IP im internen Netz - erledigt!
    eth0:1 (alias) static IP zur Fritzbox hin - erledigt!
    DHCP und DNS fürs interne Netz - dnsmasq - erledigt!
    WINS Namensauflösung - samba und winbind - erledigt!
    Router (interne Netzgeräte haben Internetzugriff) - iptables - erledigt! (vielmehr "funktioniert")
    RemoteDesktop im internen Netz - RealVNC entfernt, xrdp - erledigt!
    Netzwerkerreichbarkeit von außen (Test erfolgreich) - erledigt!
    TrafficMonitor (siehe Link weiter oben) - bandwidthd auf apache2 - offen (noch gar nicht angefasst)
    Einsprungpunkt von außen (VPN) openswan/ipsec/xl2tpd - hier lege ich mir momentan die Karten


    VPN: Wozu?
    Ich möchte von außerhalb mit einer verschlüsselten Verbindung in mein internes Netz hinein, um die Seiten des bandwithd betrachten zu können. Schön wäre auch, von außerhalb mittels MSTSC eine Verbindung zu einem WindowsPC in meinem internen Netz zu verbinden und diesen nutzen zu können (quasi Fernwartung ohne Anwender am PC).

    Lust gemacht hat dieses Video von Sempervideo Raspberry Pi: VPN-Server installieren von 2013. Ist ja einfach!

    Nein, ist es nicht. Jessie scheint sich in diversen Punkten geändert zu haben, den Rückschritt zu Wheezy kann ich - vermutlich - aufgrund der fehlenden Hardwareunterstützung nicht machen.

    Weder die umfangreiche Variante (von außen per Portforwarding 500/1701/4500 auf den Pi) noch die interne einfache Version (Smartphone via Edimax-AP direkt zum Pi) waren/sind erfolgreich.

    Irgendwas scheint in meiner Distri zu fehlen, denn alle Tutorials, die einen ähnlichen Weg gehen (ich habe auch openSwan entfernt und mit racoon nach Anleitung versucht), brachten bei mir keinen Erfolg. Vielleicht haben andere, bei denen das auf Anhieb funktioniert, bereits andere Anwendungen installiert und deshalb Pakete (Verschlüsselungsunterstützung oder was weiß ich) im System schon installiert und gehen deshalb auf deren Installation/Erfordernis nicht ein... Ich bin am Verzeifeln!

    intern Smartphone Wiko marshmellow 5(.irgendwas) per WLAN

    Code
    Dec  1 19:32:35 control xl2tpd[17474]: handle_packet: bad control packet!
    Dec  1 19:32:35 control xl2tpd[17474]: network_thread: bad packet

    intern ASUS Netbook Win 8.1 per WLAN

    Code
    Nov 30 15:25:53 control racoon: ERROR: invalid DH group 20.
    Nov 30 15:25:53 control racoon: ERROR: invalid DH group 19.

    Ich würde nun erst mal allgemeine Statements Eurerseits abwarten, evtl. kassiere ich ja ein "das geht unter Jessie so gar nicht mehr, weil ...", bevor ich mit meinen (vielen, vielen Versionen von) Configs um mich werfe...

    Danke fürs Lesen!

    Na dann, helft mal bitte nem alten Sack auf die Sprünge! :bravo2::thumbs1:


    Ach ja, Anleitungen, an denen ich mich orientiert habe:


    Was läuft außer Pi und Fritzbox sonst noch in meinem internen Netz:

    • leicht modifizierte Netgear-Stora als Fileserver
    • HP LaserJet Pro M252dw
    • Edimax AP BR-6288ACL als Accespoint für die Wireless Clients
    • Trendnet TEW-650 AP mit Richtantenne (Funkstrecke zum Nachbarhaus)
    • Dreambox DM600
    • yaVDR - Linux Fernseh-PC
    • Google ChromeCast II
    • Samsung Tablet Tab4 7" (Sofa)
    • Samsung Notebook (Win7 für die beste Frau aller Zeiten)
    • Core2Duo PC mit Win10home für meine Bedürfnisse
    • 2 Wiko Smartphones Ridge4g Marshmellow
    • XBOX360
    • Asus Netbook Win8.1 für mal so zwischendurch (u. a. Garage)

    LG
    -==[Schubsi]==-

    Einmal editiert, zuletzt von schubsi (3. Dezember 2016 um 13:32)

  • Jessie auf Pi 3 B im HomeLan mit div. Aufgaben (Probleme mit dem VPN)? Schau mal ob du hier fündig wirst!


  • Mein Netz:
    Fritz 6360 cable -- ...

    BTW: Hast Du einen Internet-Anschluss mit nativem IPv4 oder mit dual stack (IPv6+IPv4) oder mit dual stack-lite (IPv6)?

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.4 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p3 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., stunnel-Proxy, Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server, botamusique, ample

    Einmal editiert, zuletzt von rpi444 (3. Dezember 2016 um 10:15)


  • BTW: Hast Du einen Internet-Anschluss mit nativem IPv4 oder mit dual stack (IPv6+IPv4) oder mit dual stack-lite (IPv6)?

    Verdammt, das ist jetzt so ein technisches Ding, mit dem ich mich noch nicht befasst habe (Fritzbox vor ca. einem Jahr ausgepackt, angeschlossen und funktioniert --> freu!): Wie kann ich das bestimmen bzw. die Informationen ermitteln, die Du benötigst?

    Ich sags mal so: Meine Fritz.Box hat einen Dyndns-Account bei SPDNS und hier kamen offensichtlich Pakete angeflattert, Einträge im Syslog waren sehr spärlich, eben nur "bad control paket", kein Unterschied zum internen Versuch...

    Vermutest Du, dass Datenpakete vom Provider manipuliert werden?

    Auch intern funktionierte nix, was mich stutzig machte. Hatte kurz den Edimax im Verdacht, ist ja schließlich auch kein triviales Gerät (verbindet 2.4 GHz und 5 GHz und LAN), dass ggf. dieser ebenfalls Datenpakete unbrauchbar machen könnte...

    -==[Schubsi]==-

    Einmal editiert, zuletzt von schubsi (3. Dezember 2016 um 10:36)


  • ... habe (Fritzbox vor ca. einem Jahr ausgepackt, angeschlossen und funktioniert ...

    Aber vor einem Jahr, war eine FritzBox-cable doch (fast) immer ein Zwangsrouter, zumindest bei den "großen" Kabel-Provider (wie Unitymedia, KD/Vodafone). Ja, es gibt auch Internet-Provider (z. B. Kevag), bei denen die FritzBox-cable, damals schon das Eigentum des Kunden war.

    welchen Internet-Provider hast Du?


    Vermutest Du, dass Datenpakete vom Provider manipuliert werden?

    Nein, das (noch) nicht. ... aber ich denke das mit dem evtl. DS-lite (oder auch nicht), wäre eine nützliche Information für die die dir evtl. helfen wollen.

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.4 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p3 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., stunnel-Proxy, Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server, botamusique, ample

    Einmal editiert, zuletzt von rpi444 (3. Dezember 2016 um 11:06)


  • ...war eine FritzBox-cable doch (fast) immer ein Zwangsrouter


    So ist es auch in meinem Fall: Konnte nur zwischen FB und ominösem "schwarzem Kasten" auswählen, wegen der ISDN-TK-Anlage musste es dann aber doch die FB sein, am S0-Bus funktioniert eigentlich alles, was ich vom früheren ISDN-Komfort-Anschluss kannte. Aber die "alte" 6360 war im Sonderangebot als Mietgerät kostenneutral, insofern...


    Zitat von rpi444

    welchen Internet-Provider hast Du?


    KD.Vodafone


    Zitat von rpi444

    nativem IPv4 oder mit dual stack (IPv6+IPv4) oder mit dual stack-lite (IPv6)?


    Und wie bekomme ich das nun heraus, wenns doch wichtig sein sollte?


    Ich würde mich aber sowieso erstmal darauf konzentrieren, dass es intern funktioniert, bevor ich im nächsten Schritt von außen teste. Letzteres hat ja wenig Sinn, solange die Software auf dem Pi nicht vollständig oder falsch konfiguriert ist...


    -==[Schubsi]==-


  • KD.Vodafone


    Und wie bekomme ich das nun heraus, wenns doch wichtig sein sollte?

    Das kannst Du z. B. im WEB-Interface deiner FritzBox-cable sehen. Wenn dort die "externe" IPv4-Adresse, die eines AFTR-Gateways ist, dann hast Du DS-lite.

    Siehe z. B. "Dual Stack Lite" in: https://avm.de/fileadmin/user…cal_Note_de.pdf

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.4 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p3 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., stunnel-Proxy, Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server, botamusique, ample


  • ...WEB-Interface deiner FritzBox-cable sehen. Wenn dort die "externe" IPv4-Adresse, die eines AFTR-Gateways ist, dann hast Du DS-lite.

    Wie ich herausfinden kann, ob meine IP die eines AFTR-Gateways ist, konnte ich nicht ergründen.

    Was jedoch 100% funktioniert:

    Vom Smartphone aus über den Mobilprovider unter Verwendung meines DynDNS-Namens (meine ip-v4 ist hinterlegt) auf die Config-Seite meiner Fritzbox zugreifen.

    Reicht doch, oder? :s ;)

    -==[Schubsi]==-


  • Vom Smartphone aus über den Mobilprovider unter Verwendung meines DynDNS-Namens (meine ip-v4 ist hinterlegt) auf die Config-Seite meiner Fritzbox zugreifen.

    Reicht doch, oder?

    Ja, denn dann hast Du natives IPv4 (und kein DS-lite).

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.4 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p3 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., stunnel-Proxy, Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server, botamusique, ample

  • Prima :thumbs1:

    Netzwerkerreichbarkeit von außen - erledigt!

    Schade: User WaldiBVB hatte gestern offensichtlich was zur Thematik geposted, aber dann wieder gelöscht:

    Thema "openSwan/L2TP/IPSec mit PSK"

    Im Google-Cache ist zwar noch was zu finden, aber leider konnte ich nicht herausfinden, ob die Config von WaldiBVB auf einem Raspbian Jessie läuft...

    <seufz>

    Hab auch beim Buddeln hier im Forum keine vergleichbaren Probleme ausfindig machen können.

    Sollte ich den Thread-Titel evtl. dramatischer formulieren (Hilferuf!)?

    -==[Schubsi]==-


  • Thema "openSwan/L2TP/IPSec mit PSK"

    BTW: Wäre OpenVPN auf deinem PI, keine brauchbare Alternative für dein Vorhaben?

    EDIT:

    Siehe auch: Softether VPN-Server (https-VPN, OpenVPN, L2TP/IPsec, SSTP)

    Der_Imperator
    24. April 2013 um 14:20

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.4 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p3 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., stunnel-Proxy, Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server, botamusique, ample

    Einmal editiert, zuletzt von rpi444 (3. Dezember 2016 um 13:52)


  • [Wäre OpenVPN auf deinem PI, keine brauchbare Alternative für dein Vorhaben?

    Wenn es so wäre, dass ich dann eine Fliege mit einem Vorschlaghammer ... :s

    Charmant war doch wirklich das Video von Sempervideo: Ratzfatz dieses, jenes, solches, klack, schwupp, funktioniert, prima...

    Nun habe ich aber Jessie installiert und das Video ist von 2013...

    Was, wenn OpenVPN im Grunde an den selben Gründen scheitert wie mein "Nachäffen" der vielen Tutrials?

    Schön fand ich auch, dass - angeblich - eben keine Clientsoftware auf den Geräten nötig wäre und alles mit Bordmitteln eingerichtet werden kann. Wobei mir Android (Smartphone) eigentlich gar nicht so wichtig wäre wie die Nutzung von einem Windows-Client aus...

    Bei einem Video-Tut zu OpenVPN erchreckte mich, dass irgendwie mit Zertifikaten hantiert werden würde und dass deren Erstellung so ca. 1 h dauern würde... Hä? Bahnhof...

    Ne, also grundsätzlich wäre schon mal toll zu erfahren, ob denn auch diese Lite-Version eines VPN-Zugriffs auf einen Raspbian Jessie bei anderen Pi 3 Besitzern funktioniert oder ob ich an grundlegenden Problemen scheitere (z. B. "diese Art des Zugriffs wurde bei Jessie im Kernel deaktiviert, weil sie zu unsicher ist").

    -==[Schubsi]==-
    Automatisch zusammengefügt:

    Auf dieses Tut bin ich auch schon gstoßen, liest sich recht spannend, keine Frage...
    Leider ist in der Einleitung nicht erkennbar, welches Raspbian zum Einsatz kommt. Da der Verfasser das Tut im Februar 2015 eröffnete, gehe ich von Wheezy aus...

    Zitat

    Nun die gewünschten L2TP Funktionen aktiveren. Ich nutze es z.B. gar nicht...


    Ausgerechnet der Weg, den ich gerne gehen würde (der Einfachheit halber), wird nicht beleuchtet.

    Ebenfalls vermisse ich eine Erläuterung der Umgebung, die das Kompilieren ermöglicht. Meine früheren Debian-Erfahrungen gehen dahin, dass es erstmal - für einen Nichtwissenden (als den ich mich vorerst einstufen würde) - ein undurchsichtiger Akt ist, was man denn da alles zu braucht (jemand, der täglich Source-Code kompiliert, wird hierüber sicherlich schmunzeln) ...

    Tja, viel geschrieben, aber wirklich weiter gekommen mit meinem Problem bin ich noch nicht ;)

    Gibts denn hier überhaupt User/Mitleser, die einen Pi 3 Model B betreiben und mit VPN (L2TP/IPsec) "mal was gemacht" haben?

    -==[Schubsi]==-

    Einmal editiert, zuletzt von schubsi (3. Dezember 2016 um 14:34)

  • Moins...

    Sonderlich ergiebig ist die Ausbeute an Tipps und Hinweisen ja nicht unbedingt... mmmmhhh


    Im englischen Rasberryforum habe ich einen Beitrag gefunden: https://www.raspberrypi.org/forums/viewtop…=31541&start=28

    Demnach ist bereits bei Raspbian Wheezy Openswan nicht mehr funktionstüchtig:

    Zitat

    The latest version of wheezy has broken openswan. Downgrading to the previous fixes things.
    ... openswan_2.6.37-3_armhf.deb

    Wenn ich das richtig verstanden habe, teilen sich OpenSwan, LibreSwan und noch ein anderes Derivat (StrongSwan?) verschiedene Code-Teile, sodass hier damit zu rechnen ist, dass seit diesem Update alle drei nicht mehr auf diese Weise (XL2TPD, IPSEC) nutzbar sind.

    LG

    -==[Schubsi]==-

    Einmal editiert, zuletzt von schubsi (7. Dezember 2016 um 19:49)


  • Mein Netz:
    Fritz 6360 cable -- 192.168.178.0/30 -- RasPi -- 192.168.1.0/27 (GigaBit) -- div Netzgeräte -- Edimax AP (2.4/5 GHz) - 3x Android Smartphone, 2 Netbooks...

    RasPi:
    Einsprungpunkt von außen (VPN) openswan/ipsec/xl2tpd - hier lege ich mir momentan die Karten

    Weder die umfangreiche Variante (von außen per Portforwarding 500/1701/4500 auf den Pi) noch die interne einfache Version (Smartphone via Edimax-AP direkt zum Pi) waren/sind erfolgreich.

    Du kommst auf deine Fritzbox und kannst da Portforwarding aktivieren und einstellen?
    Dann guck mal unter Internet -> Freigaben -> VPN.
    Lass die Fritzbox doch einfach das VPN machen. :) Die kann das auch.

    Zitat


    intern Smartphone Wiko marshmellow 5(.irgendwas) per WLAN

    Code
    Dec  1 19:32:35 control xl2tpd[17474]: handle_packet: bad control packet!
    Dec  1 19:32:35 control xl2tpd[17474]: network_thread: bad packet

    intern ASUS Netbook Win 8.1 per WLAN

    Code
    Nov 30 15:25:53 control racoon: ERROR: invalid DH group 20.
    Nov 30 15:25:53 control racoon: ERROR: invalid DH group 19.

    LG
    -==[Schubsi]==-

    Du verbindest Dich aus dem WLAN intern mit dem IpSec Server?
    Dann ist klar wieso die Verbindung abkachelt.
    In dem Moment wird das Routing komplett umgebogen auf das IpSec Netzwerk.
    Dadurch kann das WLAN Internface aber nicht mehr mit dem IpSec Server reden.
    Es erreicht den einfach nicht mehr. Daber wenn Du es testen willst muss das immer von Aussen sein. Entweder Smartphone aus dem WLAN und über Mobilenetz testen oder mit einem Rechner der extern steht.

    IpSec am besten mit racoon und eigener CA einrichten.
    apt-get install racoon
    gibt auch gute Anleitungen wie man das schnell einrichtet.

  • Freue mich über die Resonanz, ehrlich!!!

    Muss gleich los, daher nur im Telegrammstil:

    WaldiBVB: Aktuell gibts keine ipsec.conf, da ich es zuletzt mit racoon versucht habe...

    ruedigerp:
    a) Ich "trainiere" in meinem Netz noch, an anderer Stelle (Bekanntschaft) steht keine Fritz zur Verfügung, daher soll es dort auch ein Pi machen, weil man damit ja noch mehr realisieren kann...
    b) Ich nutze das wlan-Interface des Pi nicht, im Netz ist ein Edimax AP, der 2,4GHz, 5 GHz und LAN im selben IP-Segment miteinander verbindet (Bridge ist der richtige Ausdruck?).

    Ich bin zuletzt davon ausgegangen, dass bei Raspbian irgendwas grundlegendes (Kernel?) geändert wurde - aus Sicherheitsgründen? - (seit letztem Update von Wheezy): Das SemperVideo-TUT sah so simpel aus, "einfach nachmachen und schwupp -> geht". Drei Jahre später nutze ich Jessie auf dem Pi 3 B und es geht eben nicht. Scheine auch nicht alleine zu sein...

    Code
    RX packets:822694 errors:0 dropped:183 overruns:0 frame:0
    TX packets:804850 errors:0 dropped:0 overruns:0 carrier:0

    Ich kann mich erinnern, dass während meiner letzten Versuche die Anzahl der "dropped packets" ziemlich hoch war. Möglicherweise habe ich mir in meiner Verzweiflung bei der Übernahme der diversen iptables-Befehlszeilen (die ich nicht immer verstanden habe), irgendwas eingefangen, was ein vernünftiges Weiterverarbeiten der Pakete verhindert... :s

    Heute abend habe ich wieder Gelegenheit, zu experimentieren...

    LG

    -==[Schubsi]==-

    Einmal editiert, zuletzt von schubsi (9. Dezember 2016 um 06:14)

  • Also ich habe es genau nach dem Sempervideo Tutorial gemacht. Ich musste allerdings eine kleine Änderung vornehmen damit mein iPhone eine Verbindung aufbauen konnte. Damit Windows 10 sich verbinden konnte musste ich einen kleinen Registry Eintrag setzten. Seid dem geht alles bestens.


  • Also ich habe es genau nach dem Sempervideo Tutorial gemacht. Ich musste allerdings eine kleine Änderung vornehmen damit mein iPhone eine Verbindung aufbauen konnte. Damit Windows 10 sich verbinden konnte musste ich einen kleinen Registry Eintrag setzten. Seid dem geht alles bestens.


    Schön das du jeweils nur eine Änderung machen musstest.

    Aber welche waren das? Würde ihn vielleicht Interessieren damit es bei ihm auch funktioniert.

  • aus der ipsec.conf

    Code
    conn L2TP-PSK-NAT
       rightsubnet=vhost:%priv
       also=L2TP-PSK-noNAT


    löschen.

    in Windows 10 musste ich in der Registry unter

    Code
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\PolicyAgent


    den DWORD-Wert (32-bit) mit

    Code
    AssumeUDPEncapsulationContextOnSendRule


    mit 2 erstellen.

    Einmal editiert, zuletzt von WaldiBVB (9. Dezember 2016 um 08:54)

  • Leider konnte ich gestern abend nicht mehr experimentieren, die Familie nahm meine Aufmerksamkeit in Anspruch, aber was solls, ist ja nicht so schlimm, ich habe ja noch Zeit, ich bin ja noch jung :lol:

    Aaaaalso:

    Mein Problem muss noch irgendwo anders verborgen sein, der XL2TPD startet unauffällig:

    Hab einen Ausschnitt aus einem älteren Syslog (vom letzten WoEnde) rausgekramt

    und hier noch ein exemplarisches Log bei Eingang einer Anfrage

    Es werden 3 Pakete empfangen: 2mal size=69 und 1mal size=36, letztendlich wird nur mit "bad control packet" quittiert und nach nem Timeout abgebrochen...


    Ich möchte noch einmal verdeutlichen, dass hier eine nicht unbedingt übliche Netzwerkkonfiguration vorliegt, ich versuche mal, das plausibel aufzuzeigen

    Ich war im ASCII-Zeichnen nie sonderlich gut, ich bitte um Nachsicht... :cool:


    Warum ich das so konstruiert habe?

    • Ich möchte den zusätzliche Einsatz eines USB-Ethernet-Controllers vermeiden (wenn es doch auch so geht, also eth0 und ein alias eth0:1 mit weiterer IP-Adresse)
    • Die "Kindersicherung" einer Fritz ist nicht sonderlich toll.
    • Die "Kindersicherung" steht nicht zur Verfügung, wenn keine Fritz verwendet wird.
    • Hab mal gelesen, dass Windows sehr gesprächig ist. Möchte gerne verhindern, dass dieses Gequatsche den Weg ins Internet findet (Netbios nutzt wohl Ports 137, 138, 139). Wie ich das wegfiltere, weiß ich noch nicht, hab aber einige Seiten gefunden, wo das erläutert wird. Muss nur noch die Zeit finden, das auch zu lesen und anzuwenden. Bin für Ratschläge dankbar...
    • Verschiedenen Geräten soll der Zugang zum Internet verwehrt bleiben (z. B. Drucker HP M252), was ich manuell beeinflussen möchte (wie ich das zukünftig realisiere, weiß ich noch nicht, muss ich mir noch erarbeiten)
    • alle nicht genutzen IP-Adressen des Segments ..1.0/27 sollen grundsätzlich keine Internetverbindung haben, erst nach manueller Freigabe (dieses Projekt ist auch noch offen)
    • Kein Netzwerkteilnehmer soll die Möglichkeit nutzen können, sich eine IP aus dem Pool der Fritz manuell einzutragen und am Pi vorbei direkt ins Internet zu gehen (daher so ein kleines Segment für Fritz und Pi (Netz, 2IPs, Broadcast, und dazupassende enge Netmask))
    • Der komplette Internet-Traffic soll komplett über den Pi laufen, um diesen mit bandwithd im Auge behalten zu können (auch noch offen)

    Die hier genannten IP-Adressen werde ich so im endgültigen Echtbetrieb nicht nutzen, sondern eher unübliche Bereiche (also nicht 192.168.178.x/24 oder 192.168.0.0/24 oder 192.168.1.0/24 etc.), aber fürs Erklären haut das ja hin, so wie ich das erläutert habe...


    WaldiBVB
    Ich habe Dein gelöschtes Posting aus dem GoogleCache herausangeln können. Die Configs sahen mir allesamt vertraut aus. Trotzdem lief/läuft es bei Dir auf Anhieb problemlos und bei mir nicht, was mich vermuten lässt, dass wir doch unterschiedliche System nutzen (?!?!). In Deinem Profil habe ich nichts von einem Pi 3 gesehen. Du verwendest SICHER Raspbian Jessie und nicht vielleicht doch ein älteres Wheezy?

    LG

    -==[Schubsi]==-

    Einmal editiert, zuletzt von schubsi (10. Dezember 2016 um 15:54)

  • Also es ist ziemlich egal welchen Pi du benutzt. Da du die SD Karten in jeden Pi stecken kannst egal mit welchem du das erste mal gestartet hast. Und ja ich nutze definitiv Jessi. Seid ein paar Tagen sogar das aktuelle Image.

    Aber wieso dein Pi ein zwei Adressen braucht verstehe ich immer noch nicht ?

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!