20.10.2021, aktualisiert um 11:26:54 Uhr

2303

VPN Hotspot

Hallo zusammen,

zu Hause betreibe ich ein NAS mit einem L2TP/IPSec Sever & MS-CHAPv2 Authentifizerung & Preshared-key.
Jetzt möchte ich gerne an einer anderen Stelle ein VPN für einen Echo Show aufbauen.
An dem entfernten Ort, wo der Echo laufen soll, habe ich einen LAN/WLAN Anschluss auf ein seprates Netz (FritzBox) mit dem ich machen kann was ich will. Zugriff auf die FritzBox selbst habe ich aber nicht.

Jetzt hoffe ich auf Eure Erfahrungen und Tipps.
Mir selbst sind folgende Ideen gekommen:

1) Einen RaspberryPi, der per LAN den Zugang zum Internet bekommt und auf dem VPN eingerichtet ist, dass dann wiederrum per WLAN, quasi als AP wieder abstrahlt.
2) Gibt es günstige VPN Switche die das können ?
3) Kann man eine alte Fritzbox so einstellen, dass das klappt ?

Oder hättet ihr da ganz andere Ideen ?

VG & vielen Dank vorab

[edit] Von Linux habe ich leider nicht viel Ahnung, solltet ihr mir als etwas in Richtung RaspberryPi empfehlen, wäre es cool wenn es dazu irgendwelche Anleitungen geben würde...

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 1409598157

Url: https://administrator.de/contentid/1409598157

Ausgedruckt am: 21.11.2024 um 22:11 Uhr

58 Kommentare

Neuester Kommentar

1.)
Klappt natürlich schnell und problemlos.
Strongswan macht dir den L2TP Zugang wie VNC_oder_RDP zugreifst.
Hostapd macht dir den WLAN Accesspoint wie HIER beschrieben.
Fertisch...
Mit den Anleitungen sollte auch ein Linux Laie problemlos klar kommen.

2.)
Ja, z.B. ein Mikrotik_hAP_lite für 20 Euronen
Der macht genau das was der RasPi oben auch macht aber mit bequemem KlickiBunti GUI.

Alternativ geht das auch mit jedem beliebigen Router der die offene Firmware OpenWRT supportet bzw mit dieser geflasht werden kann. z.B. GL.inet usw.
3.)
Ja, würde auch gehen. Modem Bypass einstellen über den LAN1 Port ans dortige Netz anklemmen und VPN einrichten auf dieser alten FritzBox. Geliche Funktion wie 1. und 2.

Oder hättet ihr da ganz andere Ideen ?

Nope, unter den Voraussetzungen das du keinerlei Zugriff auf die dortige FB hast bleibt dir nicht viel Anderes.
Sinnvoller wäre es natürlich dort das VPN einzurichten aber was nich iss, das iss dann eben nich und dann muss ein Workaround mit einem dieser 3 Optionen her...

Mit einem dieser 3 Optionen klappt die Umsetzung aber ganz sicher.

Wenn's das denn nun war oder kein weiteres Interesse mehr an einer zielführenden Lösung besteht bitte den Thread dann auch als gelöst markieren !
Wie kann ich einen Beitrag als gelöst markieren?

Guten Morgen aqui,

erstmal vielen lieben Dank für Deine ausführliche Antwort!
Ich hätte das auch gerne direkt ausprobiert, bin dann aber unerwartet letzte Woche nicht mehr an den Zielort gekommen...

Ich glaube der, für mich, einfachste Weg wäre dann die FritzBox. Die habe ich hier rumliegen und ich muss nicht erst mit Linux kämpfen ^^
Also habe ich die FritzBox wie von Dir beschrieben auf Bypass gestellt und wollte dann das VPN einstellen.
Unter VPN habe ich aber nur die folgenden 3 Möglichkeiten:
1) Lan-Lan-Kopplung
2) Mit Firmen-VPN verbinden
3) VPN Konfiguration aus einer Konfigurationsdatei importieren

Ich habe aber nirgendwo eine Möglichkeit gefunden die Anmeldedaten für die Authentifizierung einzutragen...

VG & vielen Dank für Deine Unterstützung

und ich muss nicht erst mit Linux kämpfen

Erweitert aber immer den persönlichen Horizont und mehr wissen kann ja nie schaden im Leben...

Ich habe aber nirgendwo eine Möglichkeit gefunden die Anmeldedaten für die Authentifizierung

Du wählst Punkt 1. und realisierst eine FritzBox LAN zu LAN Verbindung mit der remoten FritzBox. So sind beide Netze verbunden.
Die FritzBox fragt dich immer nach einem Preshared Key der die VPN Verbindung absichert. Mehr als einen Preshared Key benötigst du beim von der FritzBox unterstützten VPN Protokoll IPsec nicht !

Zitat von @aqui:
Erweitert aber immer den persönlichen Horizont und mehr wissen kann ja nie schaden im Leben...

Hast Du natürlich vollkommen recht und ich mache auch immer mal wieder was mit Linux, nur leider zu wenig.
Dazwischen liegen oft lange Zeiträume und irgendwie habe ich das Gefühl jedes mal wieder bei 0 anzufangen ;)

Bei mir klappt das leider nicht so wie Du es beschreibst.
Hier mal meine Konfigurationsübersicht meiner QNAP(VPN Server) und meiner FritzBox am entfernten Ort.

Die DynDns Adresse lässt sich auflösen wenn ich sie anpinge und der Key ist auf jeden Fall auch korrekt...

In der FritzBox sieht es hinterher so aus:

Auf dem VPN-Server habe ich auch mal geschaut und hier finde ich den Verbindungsprotokollen auch keine Abgelehnten Verbindungen oder andere Fehler....

Eine Idee was ich hier falsch mache ?

VG

Nur zur Klarstellung: Die FritzBox kann NICHT mit dem QNAP L2TP kommunizieren, denn die FritzBox supportet einzig und allein nur ein VPN Protokoll nämlich Native IPsec. Sie supportet kein L2TP was du auf dem QNAP machst. Die kommen also niemals VPN technisch zueinander da sie unterschiedliche (VPN) Sprachen sprechen.
Das einzige was du machen kannst ist die remote extra FritzBox mit deiner FritzBox mit einer LAN-zu-LAN VPN Verbindung zu koppeln.
Oder... du musst das L2TP VPN auf dem QNAP in Native IPsec ändern, was aber eigentlich unsinnig wäre denn, deine heimische FritzBox supportet das ja out of the Box.

Ich hatte das damals aber extra über mein NAS gemacht, da ich so mit Windows Boardmitteln eine VPN Verbindung in mein Netzwerk aufbauen kann.
Bei dem Fritz VPN benötigt man noch zusatz Software, wenn ich das richtig in Erinnerung habe...

Also doch einen RaspberryPi wenn ich bei meiner QNAP bleiben will ?

VG

da ich so mit Windows Boardmitteln eine VPN Verbindung in mein Netzwerk aufbauen kann.

Hätte man nicht gemusst, denn das kannst du auch immer über die IPsec Funktion der FritzBox machen:
https://avm.de/service/vpn/uebersicht/
Großer Nachteil der Lösung über einen VPN Server im lokalen Netz ist das man über das Port Forwarding ein Loch in die Firewall des Routers bohren muss und so ungeschützten Internet Traffic in sein lokales Netz lässt.
Und das dann auch noch auf ein so zentrales Device wie ein NAS was meist eine Menge privater Daten speichert. Generell ist das aus den o.a. Gründen nie eine gute und besonders intelligente Idee.
VPNs gehören aus diesen Gründen immer in die Peripherie !
Gut, du hast das für dich akzeptiert und bist den Weg gegangen... Ist ja nicht falsch aber dann kommst du mit einer FritzBox nicht weiter weil die eben kein L2TP kann bzw. supportet.
Da bleibt es dann beim Mikrotik hAP Lite oder dem RasPi oder irgend etwas was dann L2TP supportet.
Wenn du eher Klicki Bunti affin bist und eine leichte Linux Allergie hast ist vielleicht der 20 Euro Mikrotik die bessere Wahl.

Zitat von @aqui:

da ich so mit Windows Boardmitteln eine VPN Verbindung in mein Netzwerk aufbauen kann.

Hätte man nicht gemusst, denn das kannst du auch immer über die IPsec Funktion der FritzBox machen:
https://avm.de/service/vpn/uebersicht/

Aber beeinhaltet der Link nicht genau das, also das ich eine Software brauche um die VPN Verbindung herzustellen ?

Das Programm FRITZ!Fernzugang ist ein VPN-Client. Installieren Sie das Programm auf den Computern und Laptops, von denen aus Sie die FRITZ!Box über eine VPN-Verbindung erreichen möchten.

Über mein NAS-VPN kann ich das einfach mit Windows Boardmitteln erledigen, also einfach eine VPN-Verbindung über das Netzwerk & Freigabecenter erstellen.

Ich glaube ich versuch es morgen erstmal per RasPi, den habe ich noch rumfliegen und melde mich dann entweder mit einer Rückfrage oder das es geklappt hat ;)

Vielen Dank für Deine Hilfe bisher!

So, wie versprochen melde ich mich mit einer Rückfrage ^^

Ich bin jetzt Deine Anleitung für RasPi durchgegangen und die Punkte 1-3 waren kein Problem.

Hier wird es aber tricky für mich:

4.) L2TP Tunnel aktivieren:

ipsec up l2tp
echo "c l2tp" > /var/run/xl2tpd/l2tp-control

Letzteres packt man dann am besten in ein Bash Script wie z.B.
#!/bin/bash
ipsec up l2tp
sleep 2 #delay to ensure that IPsec is started before overlaying L2TP
systemctl restart xl2tpd
sleep 2
/bin/echo "c l2tp" > /var/run/xl2tpd/l2tp-control
sleep 2 #delay again to make that the PPP connection is up.
ip route add 192.168.88.0/24 dev ppp0
(192.168.88.0/24 ist hier das remote LAN auf der L2TP Server Seite)

Der Befehl

ipsec up l2tp

bzw

sudo ipsec up l2tp

gibt ja keine Rückmeldung oder ähnliches und da es auch keine Fehlermeldung gab, gehe ich mal davon aus, dass das geklappt hat.
Der Befehl

echo "c l2tp" > /var/run/xl2tpd/l2tp-control  

bzw

sudo echo "c l2tp" > /var/run/xl2tpd/l2tp-control  

gibt folgendes zurück:

bash: /var/run/xl2tpd/l2tp-control: Keine Berechtigung

Mit "Letzteres packt man dann am besten in ein Bash Script wie z.B." weiß ich grad so gar nichts anzufangen. Wie setze ich das korrekt um ? Und die route muss ja dann vermutlich auf den IP-Adressen Bereich angepasst werden, wie er oben auf meinem Screenshot zu sehen ist (10.2.0.0), richtig ?

VG

Ob der IPsec Tunnel steht kannst du mit ipsec status sehen. Einfach mal man ipsec eingeben, das erklärt dir dann die Optionen des ipsec Kommandos.

Es ist übrigens FALSCH das da kein Output kommt ! Siehe hier unter Strongswan Output::
Ubtuntu 20.10 mit UdmPro L2tp VPN Server verbinden

gibt folgendes zurück:

Dann hast du als User nicht die Berechtigungen das auszuführen.
Mache das ganze mal indem du immer zuerst global sudo su ausführst ! Damit bist du dann für alle kommenden Kommandos Root User und führst diese auch mit Root User Berechtigung aus !

Mit "Letzteres packt man dann am besten in ein Bash Script wie z.B." weiß ich grad so gar nichts anzufangen. Wie setze ich das korrekt um ?

Das ist kinderleicht.
Du nimmst dir einen einfachen, stinknormalen Texteditor wie den nano den der PI gleich an Bord hat.
Mit nano meinvpn erzeugst du eine Textdatei meinvpn dort tippst du dann ein:

#!/bin/bash
ipsec up l2tp
    sleep 2    #delay to ensure that IPsec is started before overlaying L2TP
    systemctl restart xl2tpd
    sleep 2
/bin/echo "c l2tp" > /var/run/xl2tpd/l2tp-control     
    sleep 2    #delay again to make that the PPP connection is up.
    ip route add 192.168.88.0/24 dev ppp0  

Natürlich angepasst auf deine IP Adressierung.
Dann gibst du ein chmod 755 meinvpn um diese Datei ausführbar zu machen. Wenn du ls -l eingibst siehst du mit "x" das Execution Bit.
Dann kannst du das Script einfach mit ./meinvpn starten und die L2TP Verbindung sollte etabliert sein.

Es ist übrigens FALSCH das da kein Output kommt !

Absolut richtig, der Pi hat nen neustart gebraucht, danach tat sich dann auch was.

Das script habe ich jetzt erstellt und ausführbar gemacht.
Wenn ich das script jetzt starte kommt aber:

initiating Main Mode IKE_SA l2tp[3] to MEINEIP
generating ID_PROT request 0 [ SA V V V V V ]
sending packet: from 192.168.178.59[500] to MEINEIP[500] (240 bytes)
received packet: from MEINEIP[500] to 192.168.178.59[500] (56 bytes)
parsed INFORMATIONAL_V1 request 1647710863 [ N(NO_PROP) ]
received NO_PROPOSAL_CHOSEN error notify
establishing connection 'l2tp' failed  
Cannot find device "ppp0"  

MEINEIP habe ich natürlich nur zur Anonymisierung reingeschrieben ;)

Wo ist mein Fehler ?

VG

der Pi hat nen neustart gebraucht,

Das muss nicht sein. Es reicht wenn du immer ein ipsec restart vorher ausführst.

received NO_PROPOSAL_CHOSEN error notify

Das zeigt dir das deine konfigurierten IPsec Schlüssel Credentials nicht mit denen deines NAS L2TP Servers übereinstimmen !!
WAS hast du denn auf deinem NAS Server eingestellt für den IPsec Tunnel ??
Üblich ist bei L2TP heute AES256, SHA1 und DH Group 2 oder 14. Vermutlich kann dein L2TP Server nur eine schwächere Verschlüsselung.
Passe also die IPsec.conf Datei entsprechend an

authby=secret
ike=aes128-sha1-modp1024
esp=aes128-sha1-modp1024
auto=add
...
Du kannst ihm auch mehrere zur freien Auswahl anbieten:

authby=secret
ike=aes256-sha1-modp1024,aes128-sha1-modp1024
esp=aes256-sha1-modp1024,aes128-sha1-modp1024
auto=add
...

Hmm...

Habe die ipsec.conf jetzt folgendermaßen angepasst:

conn l2tp
  ikelifetime=60m
  keylife=20m
  rekeymargin=3m
  keyexchange=ikev1
  authby=secret
  ike=aes256-sha1-modp1024,aes128-sha1-modp1024
  esp=aes256-sha1-modp1024,aes128-sha1-modp1024
  auto=add
  type=transport
  leftprotoport=17/1701
  right=MEINEDYNDNSADRESSE
  rightprotoport=17/1701

include /var/lib/strongswan/ipsec.conf.inc

Und die Logindaten habe ich auch nochmal überprüft und per Copy/Paste eingefügt. Müssen die in "" stehen ? Also bisher mache ich das nicht...

Trotzdem der gleich Fehler =/
Außerdem müsste ich doch im Ereignisprotokoll des VPN-Servers eine fehlgeschlagene Authentifizierung angezeigt bekommen, aber bis dahin scheint er schon gar nicht zu kommen....

Zitat von @aqui:

WAS hast du denn auf deinem NAS Server eingestellt für den IPsec Tunnel ??
Üblich ist bei L2TP heute AES256, SHA1 und DH Group 2 oder 14. Vermutlich kann dein L2TP Server nur eine schwächere Verschlüsselung.

Mehr kann ich hier nicht einstellen:

Mehr kann ich hier nicht einstellen:

Mmmhhh...das ist blöd.

Man müsste wenigstens mal sehen was das NAS für IPsec Schlüsselparameter verwendet.
Hat das NAS ein System Log wo man mal nachsehen kann ?? Wenn ja was stehen da für Meldungen wenn du zugreifst ??
Dort stehen in der Regel immer die angebotenen IPsec Schlüsselcredentials. Daraus kann man dann erkennen was der IPsec Tunnel des NAS verlangt.
Auf dem NAS (was immer das auch ist) werkelt ja auch ein Linux mit Strongswan IPsec. Wenn du einen Shell Zugang auf das NAS hast kannst du dort auch nachsehen in dessen IPsec Konfig Dateien. Das wäre das Einfachste.
Du kannst jetzt natürlich alle 150 und mehr Möglichkeiten ausprobieren was aber wenig zielführend ist.
Sieh dir also die Doku oder die Knowledgebase des NAS Herstellers mal an was die verwenden !!
Microsoft nutzt noch sowas olles wie 3DES mit SHA1 im Default.
https://docs.microsoft.com/de-de/troubleshoot/windows-client/windows-sec ...
Vielleicht ist das mal einen Versich wert mit:

ike=aes128-sha1-modp1024,3des-sha1-modp1024,3des-sha1-modp768
esp=aes128-sha1-modp1024,3des-sha1-modp1024,3des-sha1-modp768

Sofern du nicht an die Information von deinem NAS kommt.
Das bietet dem NAS dann AES128 mit SHA1 und 3DES mit SHA1 an.
Du kannst ja selber mal etwas kreativ sein was für Schlüsselverfahren du kombinierst für das NAS.

Welche möglichen Schlüsselverfahren es gibt siehst du hier:
https://wiki.strongswan.org/projects/strongswan/wiki/IKEv1CipherSuites
Fragt sich was dein NAS vorgibt ???

Also ich habe mal etwas recherchiert und das hier gefunden:

Hilft das ?

Vielen Dank nochmals für Deine bisherige Unterstützung hier!

Hilft das ?

Nicht wirklich...

Ist ja nur die halbe Miete weil nix übers verwendete Hashing steht und die verwendeten DH Gruppen.
AES40 ist zudem Unsinn. Sowas gibt es gar nicht. Siehe Liste der Cipher Suites oben !
Fragt sich also was die damit meinen ?
Verschlüsselung scheint dann aber wohl AES und nicht 3DES zu sein wenn man denn dem obigen glauben kann ?! Ein Output vom Log wäre vermutlich hilfreicher...?!

Als schwaches Hashing gibt es MD5 oder SHA1. Gut möglich also das die MD5 noch verwenden. DH Gruppen sind die kleinsten 768 und 1024.
Starten wir mal einen nächsten Versuch mit AES128 und Hashing mit SHA1 und MD5 und DH 768 und 1024

ike=aes128-sha1-modp1024,aes128-md5-modp1024,aes128-sha1-modp768,aes128-md5-modp768
esp=aes128-sha1-modp1024,aes128-md5-modp1024,aes128-sha1-modp768,aes128-md5-modp768

Versuch macht klug.... 🥴

Zitat von @aqui:
Versuch macht klug.... 🥴

Oder einfach selbst nachsehen ... Per SSH auf dem NAS einloggen in die /etc/ipsec.conf reinschauen

.

Habe hier noch ein altes QNAP TS-219P stehen, mit dem geht folgendes einwandfrei

conn qnap
	keyexchange=ikev1
	type=transport
	right=X.X.X.X
	leftauth=psk
	rightauth=psk
	auto=add
	esp=aes256-sha1
	ike=aes256-sha1-modp2048
	keylife=20m
	ikelifetime=60m
	leftprotoport=17/1701
	rightprotoport=17/1701

Danach noch den L2TP Tunnel gestartet, feddisch.

Hab es jetzt per ssh nachgeguckt und kenne die Verschlüsselung jetzt:

esp=aes256-sha1,aes128-sha1!
ike=aes256-sha1-modp2048,aes256-sha1-modp1024,aes128-sha1-modp1024!

Das habe ich dann entsprechend übernommen und habe jetzt folgendes Verhalten:

root@dbk-pi:/home/pi# ./meinvpn
initiating Main Mode IKE_SA l2tp[1] to MEINEIP
generating ID_PROT request 0 [ SA V V V V V ]
sending packet: from 192.168.178.59[500] to MEINEIP[500] (312 bytes)
received packet: from MEINEIP[500] to 192.168.178.59[500] (160 bytes)
parsed ID_PROT response 0 [ SA V V V V ]
received XAuth vendor ID
received DPD vendor ID
received FRAGMENTATION vendor ID
received NAT-T (RFC 3947) vendor ID
selected proposal: IKE:AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048
generating ID_PROT request 0 [ KE No NAT-D NAT-D ]
sending packet: from 192.168.178.59[500] to MEINEIP[500] (372 bytes)
received packet: from MEINEIP[500] to 192.168.178.59[500] (372 bytes)
parsed ID_PROT response 0 [ KE No NAT-D NAT-D ]
no shared key found for 192.168.178.59 - MEINEIP
generating INFORMATIONAL_V1 request 853004080 [ N(INVAL_KE) ]
sending packet: from 192.168.178.59[500] to MEINEIP[500] (56 bytes)
establishing connection 'l2tp' failed  


root@dbk-pi:/home/pi# ipsec status
Security Associations (0 up, 0 connecting):
none

MEINEIP steht natürlich für meine öffentliche IP.

Jetzt ist laut Übersicht in meiner QNAP aber der Benutzer verbunden:

Der tauchte auch erst auf, als ich mein Skript aufgerufen habe.
Ich kann aber keine Geräte aus meinem Netz erreichen also stimmt das nicht und der Pi sagt ja mit ipsec status auch was anderes...

no shared key found for 192.168.178.59 - MEINEIP
Einfach mal lesen was da steht !!!
Du hast das Passwort (shared key) in der /etc/ipsec.secret vergessen !
Dort muss sowas wie
: PSK "test1234"
stehen !!

Hab ich gesehen die Fehlermeldung aber ich habe den Key per Copy/Paste da eingefügt.

Das muss auch genau in dem Format da stehen ?

Prüfe das gleich nochmal aber ich hatte das so:
: PSK „meinKey“
Also auch mit dem Doppelpunkt und den key in Anführungszeichen

Wie gesagt:

Du musst die Secrets nach dem Ändern erst bekannt machen mittels folgendem Befehl, sonst werden die nicht aktualisiert!

ipsec rereadsecrets

Dann lüppt dat auch

Auch Dir danke für Deinen Input, leider klappt es auch weiterhin nicht.....
Hab es mit dem reread probiert, auch mal QNAP und Pi rebootet aber es hilft alles nichts...

Jetzt sieht es so aus und der Benutzer wird auch nicht mehr als angemeldet angezeigt, wie es vorhin der Fall war:

root@dbk-pi:/home/pi# ./meinvpn
initiating Main Mode IKE_SA l2tp[4] to MEINEIP
generating ID_PROT request 0 [ SA V V V V V ]
sending packet: from 192.168.178.59[500] to MEINEIP[500] (312 bytes)
received packet: from MEINEIP[500] to 192.168.178.59[500] (160 bytes)
parsed ID_PROT response 0 [ SA V V V V ]
received XAuth vendor ID
received DPD vendor ID
received FRAGMENTATION vendor ID
received NAT-T (RFC 3947) vendor ID
selected proposal: IKE:AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048
generating ID_PROT request 0 [ KE No NAT-D NAT-D ]
sending packet: from 192.168.178.59[500] to MEINEIP[500] (372 bytes)
received packet: from MEINEIP[500] to 192.168.178.59[500] (372 bytes)
parsed ID_PROT response 0 [ KE No NAT-D NAT-D ]
no shared key found for 192.168.178.59 - MEINEIP
generating INFORMATIONAL_V1 request 578176292 [ N(INVAL_KE) ]
sending packet: from 192.168.178.59[500] to MEINEIP[500] (56 bytes)
establishing connection 'l2tp' failed  
Cannot find device "ppp0"  

Zum verrückt werden ^^

no shared key found for 192.168.178.59 - MEINEIP

Er hat immer noch Probleme mit deinen ipsec.secrets
Dann trage mal folgendes in die secrets ein, das "MEINEIP" natürlich ersetzen.

192.168.178.59 MEINEIP : PSK "GEHEIM"

Klappt hier wie gesagt auf eine QNAP problemlos .. guckst du:

Meine Config

conn qnap
	keyexchange=ikev1
	type=transport
	right=X.X.X.X
        rightid=%any
	leftauth=psk
	rightauth=psk
	auto=add
	esp=aes256-sha1
	ike=aes256-sha1-modp2048
	keylife=20m
	ikelifetime=60m
	rightprotoport=udp/1701

Meine Secrets

Y.Y.Y.Y X.X.X.X : PSK "GEHEIM"

Ergebnis

ipsec up qnap

Meine /etc/ppp/options.l2tpd.client

ipcp-accept-local
ipcp-accept-remote
noauth
novjccomp
nobsdcomp
refuse-eap
refuse-pap
refuse-chap
refuse-mschap
mtu 1400
mru 1400
nodefaultroute
debug
connect-delay 5000
name "WilliWillsWissen"  
password "SuperDuperGeheim"  

Meine /etc/xl2tpd/xl2tpd.conf

[global]
access control = yes
debug tunnel = yes

[lac l2tp]
lns = X.X.X.X
ppp debug = yes
pppoptfile = /etc/ppp/options.l2tpd.client
length bit = yes

Dann den xl2tpd Client über den bestehenden IPSEc Tunnel gestartet, so dass er die enstprechende virtuelle IP erhält:

systemctl start xl2tpd
echo 'c l2tp' >/var/run/xl2tpd/l2tp-control  

Und die QNAP über den Tunnel angepingt

Works as designed 👍 .

Es will einfach nicht klappen.....

Habe jetzt die ipsec.secrets so umgesetzt wie Du gesagt hast, also:

192.168.178.59 DynDNS-Adresse :  PSK  "Passwort"

Habe den Key in meiner QNAP auch mal was einfaches gesetzt, um sicherzugehen das es hier keine Probleme mit Sonderzeichen gibt, da ich meine Passwörter normalerweise nur generiere.

Danach ipsec rereadsecrets und noch ipsec restart aber das Ergebnis bleibt gleich

Habe jetzt die ipsec.secrets so umgesetzt wie Du gesagt hast, also:

Du darfst hier nur einzelne Leerzeichen und keine Tabs zwischen den Feldern in der ipsec.secrets benutzen! Genau das führt ebenfalls zu diesem Fehler das er den PSK nicht findet!

Siehe auch meine Ergänzungen in meinem letzten Post. Dort steht alles wie es hier mit einer QNAP problemlos geht. Also nachmachen und freuen ...

Und ohne deine evt. fehlerhafte ipsec.conf können wir wieder nur raten ...

Das mit dem Tab war nach eigener Recherche im Internet, da habe ich mal was per Copy/Paste eingefügt.
Hab das natürlich jetzt auch mal ohne Tab probiert und es will trotzdem nicht....

Hab alle Dateien, die ich laut Anleitung anpassen musste, mal auf mein Google Drive hochgeladen.
Wenn Du magst kannst Du gerne mal drüber schauen und mir sagen ob noch irgendwas nicht korrekt ist:
MeinVPN

Kann alternativ auch Bilder hochladen vom Texteditor aber ich glaube so ist einfacher

VG

Du hast geschrieben:

ipsec.secrets

in der Anleitung steht aber ipsec.secret, welche Datei ist es denn ?
Ich versuche ja in der Zwischenzeit auch zu recherchieren und ich habe was gelesen von wegen "checking the /etc/ipsec.secrets file" Daher habe ich jetzt einfach mal das : PSK „password“ in die ipsec.secrets gepackt und dann das Script ausgeführt.
Jetzt kommt folgendes:

initiating Main Mode IKE_SA l2tp[1] to MEINEIP
generating ID_PROT request 0 [ SA V V V V V ]
sending packet: from 192.168.178.59[500] to MEINEIP[500] (312 bytes)
received packet: from MEINEIP[500] to 192.168.178.59[500] (160 bytes)
parsed ID_PROT response 0 [ SA V V V V ]
received XAuth vendor ID
received DPD vendor ID
received FRAGMENTATION vendor ID
received NAT-T (RFC 3947) vendor ID
selected proposal: IKE:AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048
generating ID_PROT request 0 [ KE No NAT-D NAT-D ]
sending packet: from 192.168.178.59[500] to MEINEIP[500] (372 bytes)
received packet: from MEINEIP[500] to 192.168.178.59[500] (372 bytes)
parsed ID_PROT response 0 [ KE No NAT-D NAT-D ]
local host is behind NAT, sending keep alives
remote host is behind NAT
generating ID_PROT request 0 [ ID HASH N(INITIAL_CONTACT) ]
sending packet: from 192.168.178.59[4500] to MEINEIP[4500] (108 bytes)
received packet: from MEINEIP[4500] to 192.168.178.59[4500] (76 bytes)
parsed ID_PROT response 0 [ ID HASH ]
IDir '10.0.0.142' does not match to 'DYNDNS-Adresse'  
deleting IKE_SA l2tp[1] between 192.168.178.59[192.168.178.59]...MEINEIP[%any]
sending DELETE for IKE_SA l2tp[1]
generating INFORMATIONAL_V1 request 3516512675 [ HASH D ]
sending packet: from 192.168.178.59[4500] to MEINEIP[4500] (92 bytes)
establishing connection 'l2tp' failed  
Cannot find device "ppp0"  

Auf jeden Fall kommt der Fehler nicht mehr, dass es keinen shared Key finden konnte.
Allerdings kommt jetzt:
IDir '10.0.0.142' does not match to 'DYNDNS'
Die 10.0.0.142 ist in dem Fall die lokale IP meiner QNAP und bei DYNDNS steht dann natürlich mein DYNDNS Name und nicht die aufgelöste IP wie oben überall (MEINEIP)
Außerdem kommt der gleiche Fehler ganz unten wie die ganze Zeit schon:
Cannot find device "ppp0"

Was fange ich mit den Meldungen jetzt an ?
Und war die ipsec.secrets die richtige Datei ?

Tut mir leid das ich da soviel arbeite mache und vielen Dank für Eure Geduld!

Und weiter gehts....
Auch das habe ich mal recherchiert und irgendwo hieß es:
rightid=%any
Das habe ich mal in die ipsec.conf hinzugefügt und jetzt wird die Verbindung sogar hergestellt.
Aber am Schluss kommt die Meldung: Error: Device for nexthop is not up
Ich bin zwar jetzt verbunden aber erreiche nichts aus meinem Netzwerk.... Da stimmt dann irgendwas mit der Route nicht, oder ?

So nah und doch so fern.... xD

Hier mal das Ganze was jetzt ausgespuckt wird:

initiating Main Mode IKE_SA l2tp[1] to MEINEIP
generating ID_PROT request 0 [ SA V V V V V ]
sending packet: from 192.168.178.59[500] to MEINEIP[500] (312 bytes)
received packet: from MEINEIP[500] to 192.168.178.59[500] (160 bytes)
parsed ID_PROT response 0 [ SA V V V V ]
received XAuth vendor ID
received DPD vendor ID
received FRAGMENTATION vendor ID
received NAT-T (RFC 3947) vendor ID
selected proposal: IKE:AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048
generating ID_PROT request 0 [ KE No NAT-D NAT-D ]
sending packet: from 192.168.178.59[500] to MEINEIP[500] (372 bytes)
received packet: from MEINEIP[500] to 192.168.178.59[500] (372 bytes)
parsed ID_PROT response 0 [ KE No NAT-D NAT-D ]
local host is behind NAT, sending keep alives
remote host is behind NAT
generating ID_PROT request 0 [ ID HASH ]
sending packet: from 192.168.178.59[4500] to MEINEIP[4500] (76 bytes)
received packet: from MEINEIP[4500] to 192.168.178.59[4500] (76 bytes)
parsed ID_PROT response 0 [ ID HASH ]
IKE_SA l2tp[1] established between 192.168.178.59[192.168.178.59]...MEINEIP[10.0.0.142]
scheduling reauthentication in 3249s
maximum IKE_SA lifetime 3429s
generating QUICK_MODE request 113563433 [ HASH SA No ID ID NAT-OA NAT-OA ]
sending packet: from 192.168.178.59[4500] to MEINEIP[4500] (252 bytes)
received packet: from MEINEIP[4500] to 192.168.178.59[4500] (204 bytes)
parsed QUICK_MODE response 113563433 [ HASH SA No ID ID NAT-OA NAT-OA ]
selected proposal: ESP:AES_CBC_256/HMAC_SHA1_96/NO_EXT_SEQ
CHILD_SA l2tp{1} established with SPIs c27bd344_i cb7f17d0_o and TS 192.168.178.59/32[udp/l2f] === MEINEIP/32[udp/l2f]
connection 'l2tp' established successfully  
Error: Device for nexthop is not up.

ip route add 10.2.0.0/24 dev ppp0

Dieser Eintrag in deinem Skript ist Blödsinn, du musst keine Route hinzufügen! Der xl2tpd Client erhält von der Qnap die virtuelle Adresse und den entsprechende Routing-Table Eintrag automatisch zugewiesen!

Wenn du das entfernst verschwindet auch die Fehlermeldung in Zeile 31!

Außerdem stimmt deine options.xl2tpd.client Datei nicht, nimm meine oben gepostete Version die funktioniert 100%. Denn die Qnap mag das explizite require-mschap-v2 nicht!

ipcp-accept-local
ipcp-accept-remote
noauth
novjccomp
nobsdcomp
refuse-eap
refuse-pap
refuse-chap
refuse-mschap
mtu 1400
mru 1400
nodefaultroute
debug
connect-delay 5000
name "WilliWillsWissen"  
password "SuperDuperGeheim"  

Meine Güte, echt schwere Geburt mit dir. Man müsste nur mal exakter arbeiten nicht Dinge überspringen und ab und zu auch mal selbst Dokumentationen lesen, dann wäre das hier in ein zwei Antworten abgefrühstückt gewesen, oben habe ich ja die Komplettlösung mit allen Configs schon gepostet, musst es also nur nachmachen wenn du da also selbst Dinge einfach blind reinkopierst die da bei einer Qnap nicht reingehören, tja was soll man da machen ...
Aquis Vorlage passt da eben nicht ganz zu dem L2TP Server der Qnap, meine Config hingegen wurde direkt an einer Qnap getestet und funktioniert.

Ich bin jetzt raus.

Zitat von @149569:

Meine Güte, echt schwere Geburt mit dir. Man müsste nur mal exakter arbeiten nicht Dinge überspringen und ab und zu auch mal selbst Dokumentationen lesen, dann wäre das hier in ein zwei Antworten abgefrühstückt gewesen

Ich habe halt keine Ahnung von Linux und VPN Protokollen und ich glaube da ist es auch mit mal eben Dokumentationen lesen nicht getan.
Ich hatte von Aquis die Anleitung und die bin ich halt Schritt für Schritt durchgegangen und habe mich gemeldet wenn es irgendwo hakte... Ich bin bemüht, versuche Probleme auch selbst zu recherchieren/lösen und versuche Eure Vorschläge umzusetzen und vernünftige Rückmeldungen zu geben, für mehr fehlt mit aktuell einfach das KnowHow..

oben habe ich ja die Komplettlösung mit allen Configs schon gepostet, musst es also nur nachmachen wenn du da also selbst Dinge einfach blind reinkopierst die da bei einer Qnap nicht reingehören, tja was soll man da machen ...

Hab ich gerade probiert, klappt aber auch nicht. Hier kommt wieder der Fehler "IDir '10.0.0.142' does not match to 'DYNDNS'" und endet mit "establishing connection 'qnap' failed"

Ich bin jetzt raus.

Das ist schade, zeitweise dachte ich dem Ziel sehr nah zu sein.
Trotzdem vielen Dank für den Versuch mir zu helfen und sorry wenn ich Dich genervt habe, war bestimmt nicht meine Absicht ;)

Ich bin natürlich dann auch für weitere Hilfe sehr dankbar... @aquis, falls Du noch Lust und Nerven hast....
Werde natürlich noch weiter probieren ob ich es irgendwie hinbekomme aber vermutlich wird es dann eher wieder das "blinde reinkopieren" aber ich fänds halt echt schade das Ganze jetzt nach soviel Arbeit einfach einzustampfen

VG

Hier kommt wieder der Fehler "IDir '10.0.0.142' does not match to 'DYNDNS'"

Stichwort rightid mal nachschlagen ...
https://wiki.strongswan.org/projects/strongswan/wiki/ConnSection

rightid=%any

oder auch

rightid=10.0.0.142

helps you my friend.

Und dazu den Background
https://de.m.wikipedia.org/wiki/IPsec

Das sieht schon mal gut aus =)
Nach Nutzung von rightid klappt die Verbindung jetzt. Keine Fehler und auf meiner QNAP sehe ich die Verbindung im Protokoll.
Aber andere Geräte im Netzwerk erreiche ich nicht...
Also zb ping 10.0.0.142 (lokale IP meines NAS) kommt:

From 62.155.244.217 icmp_seq=1 Destination Net Unreachable

Zitat von @geloescht:

Das sieht schon mal gut aus =)
Nach Nutzung von rightid klappt die Verbindung jetzt. Keine Fehler und auf meiner QNAP sehe ich die Verbindung im Protokoll.
Aber andere Geräte im Netzwerk erreiche ich nicht...
Also zb ping 10.0.0.142 (lokale IP meines NAS) kommt:

From 62.155.244.217 icmp_seq=1 Destination Net Unreachable

Für diese "anderen" Remote-Netze musst du ja auch erst eine statische Route auf dem PI hinzufügen! Denn sonst ist ja erst mal nur das NAS via 10.2.0.1 erreichbar!

ip route add 10.0.0.0/24 via 10.2.0.1

Ebenso auf deinem Gateway(Router) des Remote-Netzes muss evt. eine statische Route für das virtuelle Client-Netz hinzugefügt werden die so aussieht (kann gerade nicht nachsehen, aber es kann sein das diese überflüssig ist weil das NAS dieses virtuelle Subnetz NATet.)

NETZ 10.2.0.0
MASKE 255.255.255.0
GW 10.0.0.142

-edit- Ist nicht nötig, das NAS NATed das virtuelle NETZ

Wenn du es aber performanter ohne NAT haben willst, enfernst du das MASQUERADING auf dem QNAP

iptables -t nat -D POSTROUTING 1

und fügst die obige statische Route auf deinem Router ein.

Ebenso müssen die Remote-Devices auch ICMP Traffic aus dem virtuellen Netz (10.2.0.0/24) in ihrer Firewall erlauben wenn du das NAT auf dem QNAP entfernst!

Einfachste Routing-Grundlagen halt ...

Der Parameter rightid=%any sollte in der Tat dein Problem lösen. Oder indem du den Parameter komplett löschst oder mit einem "#" auskommentierst.
Ein kurzer Test auf ein QNAP TS231 NAS mit der Konfig vom Kollegen @149569 führte auch hier sofort zum Erfolg.
Ebenso ein anschliessender Test der gleichen Konfig auf einen Mikrotik L2TP Server, einen pfSense und einen Microsoft.
Das zeigt das die o.a. L2TP Konfig generell fehlerfrei ist.

Wenn du in der ipsec.secrets Datei das Passwort so : PSK "test1234" eingibst ist das eine Schrotschuss Konfig. Bedeutet das unabhängig von irgendwelchen Peer IPs oder ID Namen immer das Passwort test1234 genommen wird. Besser also du belässt es so anstatt es an dedizierte IDs usw. zu binden.
Die "" kannst du auch weglassen solange du keine Leerzeichen im Passwort hast. Gefährlich sind falsche Anführungszeichen (oben/unten) zu verwenden wie in deinem Screenshot oben. Da gilt dann: im Zweifel besser weglassen.
Denk dran das du bei jeglicher Änderung an den beiden Konfig Files immer ein ipsec restart VORHER ausführen musst um die Parameter neu zu laden ! Führe das immer mit "sudo su" und Root Rechten aus !
ipsec status zeigt dir immer an ob der Tunnel aktiv ist.

Sofern auch L2TP aktiv ist solltest du mit ip ad auch das ppp0 Interface sehen mit der entsprechenden IP ! Ist das der Fall ?

4: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1410 qdisc fq_codel state UNKNOWN group default qlen 3
    link/ppp 
    inet 10.2.0.x peer 192.168.88.1/32 scope global ppp0
       valid_lft forever preferred_lft forever  

Bei dir sollte das ppp0 Interface dann eine IP aus dem NAS IP Netz haben.

Da lauert übrigens noch die Gefahr deines Setups. Es ist nicht besonders intelligent den gesamten 10.2.0.0 /24 Bericht für VPN Clients freizugeben. Du hast ja sicher keine 253 Clients die darauf werkeln. Sinnvoller ist das zu begrenzen auf z.B. .0.100 bis .0.150 wenn du mit 50 Clients auskommst.
Hier stellt sich noch eine Frage:
Wenn das NAS für die L2TP Clients IP Adressen aus einem separaten IP Netz vergibt ist die Frage ob es generell routen kann. Das müsste es nämlich um dann die Clients in das lokale LAN des NAS 10.0.0.0 /24 routen zu können.
Ist auf dem NAS IPv4 Forwarding (Routing) generell deaktiviert kannst du nur das NAS selber über seine L2TP Server IP 10.2.0.1 erreichen.
Entscheident ist wie deine anderen Clients damit umgehen. Wenn die Endgeräte aus dem lokalen NAS LAN 10.0.0.0 /24 erreichen dann kann es natürlich auch der RasPi Client.

Vielen Dank Euch beiden!
Das werde ich am Wochenende probieren da ich jetzt unterwegs bin und erst am Samstag wieder zu Hause.

Hätte aber nicht gedacht, dass dann noch soviel Konfiguration dazu kommt...
Ich meine, wenn ich auf einem Windows Rechner bin oder auf meinem Iphone/Ipad, da gebe ich die Zugangsdaten ein, den Shared Key und das war es.
Dann bin ich im Netz und erreiche alle meine Geräte. Wieso muss bei einem RasPi noch soviel gemacht werden ?

Zitat von @geloescht:
Ich meine, wenn ich auf einem Windows Rechner bin oder auf meinem Iphone/Ipad, da gebe ich die Zugangsdaten ein, den Shared Key und das war es.
Dann bin ich im Netz und erreiche alle meine Geräte. Wieso muss bei einem RasPi noch soviel gemacht werden ?

Klicki Bunti, da läuft im Background auch das ab was du hier manuell machst ... Du kannst dir natürlich auch unter Linux einen Networkmanager installieren der das für dich übernimmt, aber so lernst du halt was da tatsächlich dahinter steckt.
Außerdem ist das hier ein NAS und nicht der eigentliche Router des Netzes, da hast du immer etwas Handarbeit.

Zitat von @149569:

Außerdem ist das hier ein NAS und nicht der eigentliche Router des Netzes, da hast du immer etwas Handarbeit.

Mit Klicki Bunti verbinde ich mich natürlich auch mit dem VPN Servers des NAS, ganz ohne Handarbeit ;)

Aber Ok, ich gucke und hoffe mal das ich das hinkriege und melde mich wieder
VG

Zitat von @geloescht:

Zitat von @149569:

Außerdem ist das hier ein NAS und nicht der eigentliche Router des Netzes, da hast du immer etwas Handarbeit.

Mit Klicki Bunti verbinde ich mich natürlich auch mit dem VPN Servers des NAS, ganz ohne Handarbeit ;)

Klar die extra Route kannst du dir auch sparen denn du die Default-Route auf den tunnel legst dann läuft aber auch wirklich alles von dem Device über den Tunnel ...
Sehe es einfach so das du daraus hoffentlich etwas mehr über den Background und von den Routing-Grundlagen lernst.

dass dann noch soviel Konfiguration dazu kommt...

Mmmhhh... Kollege @149569 hat dafür max. 10 Minuten gebraucht. Vermutlich eher weniger... ?! Was genau meinst du also mit "soviel" ??

da gebe ich die Zugangsdaten ein, den Shared Key und das war es.

Das geht auf dem RasPi auch wenn du über das Klicki Bunti GUI gehst:
https://www.tecmint.com/setup-l2tp-ipsec-vpn-client-in-linux/
Aber auch so eine simple 7zeilige Textdatei ist in 3 Minuten per Cut and Paste kopiert, User/Pass eingesetzt..fertisch. Wo ist dein Problem ?
Wie der Kollege oben schon richtig sagt: "aber so lernst du halt was da tatsächlich dahinter steckt."

Also, ich versuche mal auf die ganzen Informationen einzugehen.

Was genau meinst du also mit "soviel" ??
Wo ist dein Problem ?

Ich hab kein Problem, es war nur mehr als ich dachte...
Und klar ist das für Euch eine 10 Minuten Sache, für mich ist das aber schwer.
Ich will mich auch gar nicht beschweren und finde es gut das ich dabei was lernen kann, ich wollte eigentlich nur wissen wo der Unterschied zu Windows/Iphone etc ist, da da solche Einstellungen wie configs anpassen, Routen setzen etc halt eben nicht anfallen. Aber das habt ihr mir ja erklärt, dass diese Sachen dort automatisch im Hintergrund passieren.

Der Parameter rightid=%any sollte in der Tat dein Problem lösen

Hat er

Sofern auch L2TP aktiv ist solltest du mit ip ad auch das ppp0 Interface sehen mit der entsprechenden IP ! Ist das der Fall ?

Sieht bei mir so aus:

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether b8:27:eb:36:1c:4d brd ff:ff:ff:ff:ff:ff
    inet 192.168.178.59/24 brd 192.168.178.255 scope global dynamic noprefixroute eth0
       valid_lft 860599sec preferred_lft 752599sec
    inet6 fe80::1d9e:245d:8355:8976/64 scope link 
       valid_lft forever preferred_lft forever
3: wlan0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000
    link/ether b8:27:eb:63:49:18 brd ff:ff:ff:ff:ff:ff
18: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1400 qdisc pfifo_fast state UNKNOWN group default qlen 3
    link/ppp 
    inet 10.2.0.2 peer 10.2.0.1/32 scope global ppp0
       valid_lft forever preferred_lft forever

Sinnvoller ist das zu begrenzen auf z.B. .0.100 bis .0.150 wenn du mit 50 Clients auskommst

Tatsächlich ist der IP-Bereich auf der QNAP ausgegraut, ich kann dort nur die ersten 3 Oktette ändern:

Wenn das NAS für die L2TP Clients IP Adressen aus einem separaten IP Netz vergibt ist die Frage ob es generell routen kann. Das müsste es nämlich um dann die Clients in das lokale LAN des NAS 10.0.0.0 /24 routen zu können.

Kann man hier das Beispiel von Windows/Iphone etc nehmen ? Also da wird ja quasi auch alles weiter geroutet. Macht das nicht auch das NAS ?

Für diese "anderen" Remote-Netze musst du ja auch erst eine statische Route auf dem PI hinzufügen! Denn sonst ist ja erst mal nur das NAS via 10.2.0.1 erreichbar!

Und genau das ist der Fall, aktuell ist nur die 10.2.0.1 pingbar

ip route add 10.0.0.0/24 via 10.2.0.1

Habe ich probiert, also einfach den Befehl ausgeführt und dann die VPN Verbindung gestartet. Das Ergebnis bleibt aber gleich.
Dann habe ich versucht die Route direkt in mein Script hinzuzufügen, da ich die Verbindung ja über das Script ./meinVPN starte:

#!/bin/bash
ipsec up qnap
    sleep 2    #delay to ensure that IPsec is started before overlaying L2TP
    systemctl restart xl2tpd
    sleep 2
/bin/echo "c l2tp" > /var/run/xl2tpd/l2tp-control  
    sleep 2    #delay again to make that the PPP connection is up.
    ip route add 10.0.0.0/24 via 10.2.0.1

Aber dann bekomme ich beim Ausführen:
connection 'qnap' established successfully
Error: Nexthop has invalid gateway.
Und es lässt sich weiterhin nichts pingen

Wenn du es aber performanter ohne NAT haben willst, enfernst du das MASQUERADING auf dem QNAP

Ich glaube bevor ich hier die nächste Baustelle aufmache, versuche ich lieber erstmal eine VPN Verbindung mit funktionierender Route auf die Beine zu stellen ^^

Mit meinem gefährlichem Halbwissen würde ich jetzt sagen mir fehlt nur noch die korrekte Route und eigentlich hatte ich die Hoffnung, dass dies mit hinzufügen von: ip route add 10.0.0.0/24 via 10.2.0.1 in mein Script funktioniert aber ich bin hier anscheinend noch immer an der falschen Stelle unterwegs, oder ?

VG

Sieht bei mir so aus:

Das sieht aber schonmal sehr gut aus und zeigt das alles rennt wie es soll !
Hilfreich für alle Beteiligten wäre noch ein Output der Routing Table mit ip r gewesen aber man kann nicht alles haben...

ich kann dort nur die ersten 3 Oktette ändern:

Gut dann muss man erstmal damit leben. Wichtig ist das das 10.2.0.0 /24 nirgendwo mehr anders in deinem Netz existiert.

Also da wird ja quasi auch alles weiter geroutet. Macht das nicht auch das NAS ?

Ja, sollte dann eigentlich. Wie gesagt ein ip r bei aktivem L2TP Tunnel würde das klar anzeigen.

Und genau das ist der Fall, aktuell ist nur die 10.2.0.1 pingbar

Lässt aber dann den heimlichen Verdacht aufkommen das das NAS ggf. dich nicht routet.
Leider hast du die Frage noch NICHT beantwortet ob deine anderen L2TP Clients Ziele im lokalen 10.0.0.0 /24 LAN erreichen können oder nicht.
Können sie es = routet das NAS
Können sie es auch nicht = routet das NAS nicht
...und man kann dann nur immer einzig das NAS erreichen.
Das wäre dann das Aus für den VPN Zugriff auf andere Endgeräte im lokalen 10er Netz.

würde ich jetzt sagen mir fehlt nur noch die korrekte Route

Das ist auch richtig !

aber ich bin hier anscheinend noch immer an der falschen Stelle unterwegs

Nope, da bist du ganz genau richtig unterwegs !

Wie gesagt.... ein ip r würde da sofort Klarheit schaffen ob diese Route aktiv ist oder nicht. Leider fehlt aber genau diese wichtige Info !

Also deine nächsten ToDos:

Checke die generelle 10.0.0.0er Connectivity mit einem Winblows oder iPhone L2TP Client
Poste ein ip r bei aktivem L2TP Tunnel

Es gibt aber noch ein weiteres Problem weshalb sehr wahrscheinlich auch die Winblows oder iPhone L2TP Client Connectivity fehlschlagen wird. Warum ist das so...?!
Alle Clients im 10.0.0.0er Netz haben als Default Gateway ganz sicher einen dortigen Router z.B. mit der IP 10.0.0.1.
Deine VPN Clients haben alle als Absender IP eine 10.2.0.x IP, sprich liegen also alle in einem anderen IP Netz also die lokalen 10er LAN Client side du erreichen willst.
Folglich schicken diese Clients also für die Rückroute diese Antwortpakete zu den Clients an den lokalen Router mit der .0.1 in der Annahme der weiss wie man ins 10.2.0.0er netz kommt.
Fehlt dort aber eine statische Router ala:
Ziel: 10.2.0.0, Maske: 255.255.255.0, Gateway: 10.0.0.<NAS_IP>
routet dieser Internet Router die L2TP Pakete zum Provider ins Nirwana.
Wichtig ist also eine statische Route auf deinem Internet Router in dieses L2TP VPN Client IP Netz damit auch die Rückrouten die Clients erreichen können.
Die betrifft immer den Betrieb von internen VPN Servern und wird HIER am Beispiel von OpenVPN auch grafisch erklärt.
Dein Design ist ja identisch nur das du statt SSL eben L2TP als VPN Protokoll nutzt.

Aber dann bekomme ich beim Ausführen:
Error: Nexthop has invalid gateway.

Ist ja auch logisch wenn du versuchst bevor die Verbindung und das Interface überhaupt erst existiert, das muss nachdem die Verbindung hergestellt ist ausgeführt werden!! Erst dann ist ja der Nexthop überhaupt erst verfügbar!
Wenn du das in deinem Skript am Ende hinzufügst und die Meldung dennoch erscheint ist der Sleep zu kurz oder du musst eine Schleife einbauen die wartet bis das Interface die auch tatsächlich bekommen hat.

Zitat von @149569:

Wenn du das in deinem Skript am Ende hinzufügst und die Meldung dennoch erscheint ist der Sleep zu kurz oder du musst eine Schleife einbauen die wartet bis das Interface die auch tatsächlich bekommen hat.

Genau das war es! Vielen Dank, jetzt klappt es.
Wenn ich möchte das die VPN-Verbindung dauerhaft besteht, muss ich das Script dann immer wieder starten (Aufgabenplanung) oder gibt es dafür einen Parameter ?

Dann versuche ich mich jetzt mal am Hotspot.

Vielen lieben Dank Euch beiden nochmals

Glückwunsch ! 👏 War ja ne schwere Geburt mit dir ! 😉
Du kannst das Script in die init.d packen, dann wird es beim Booten des RasPis immer automatisch gestartet.

Dann versuche ich mich jetzt mal am Hotspot.

Ist recht easy. Siehe HIER.

Vielen lieben Dank Euch beiden nochmals

Immer gerne !

Wenn es das denn jetzt war bitte dann auch nicht vergessen diesen Thread als erledigt zu schliessen.
Wie kann ich einen Beitrag als gelöst markieren?

Zitat von @aqui:

Wenn es das denn jetzt war bitte dann auch nicht vergessen diesen Thread als erledigt zu schliessen.

Mach ich am Ende, versprochen. Aber Du hast ja nicht wirklich gedacht das ich den Rest alleine schaffe oder ? xD

Du kannst das Script in die init.d packen, dann wird es beim Booten des RasPis immer automatisch gestartet.

Hat bei mir leider nicht geklappt. Hab da ewig dran rumprobiert und glaube das ich am Ende ein Rechteproblem hatte... Auf jeden Fall habe ich es dann mit der rc.local Methode hinbekommen.

Wollte dann als nächstes einen Cron Job machen, der erst den ipsec resettet und dann die Verbindung wieder neu aufbaut, da man die VPN Verbindung wohl nur maximal 24h aufrecht erhalten kann.
Auch hier hatte ich wieder Probleme mit genau dem Script. Andere Tests funktionierten... Daher vermute ich auch hier ein Rechteproblem. Nachdem da einige Zeit reingeflossen ist, habe ich mich einfach dazu entschieden per Cron nachts einen Reboot zu machen.
Das klappt also soweit auch alles.

Ist recht easy. Siehe HIER.

Für mich ist hier gar nichts easy xD
Ich habe Deine Anleitung jetzt umgesetzt aber es wird keine SSID ausgestrahlt...
Außerdem bin ich mir nicht sicher wie die IP-Adressen aussehen müssen.
Mein RaPi hat jetzt per LAN die 192.168.178.59 per DHCP bekommen (Reservierung in der FritzBox)
Der WLAN Schnittstelle habe ich jetzt über die GUI die statische Adresse 10.4.0.254 gegeben (weil es ja hieß, die beiden Schnittstellen müssen unterschiedliche Netze haben) und die VPN Verbindung hat ja den 10.2.0.x Bereich. Passt das so oder habe ich hier schon den Fehler ? Bzw, müsste die SSID nicht auch mit falscher IP-Konfiguration zumindest ausgestrahlt werden ?

VG

und glaube das ich am Ende ein Rechteproblem hatte...

chmod 755

aber es wird keine SSID ausgestrahlt...

Hast du nach Anpassung der Konfig Datei ein systemctl restart hostapd eingegeben ??
Der hostapd kann vermutlich ein Kommando nicht lesen. Tippfehler etc.

Der WLAN Schnittstelle habe ich jetzt über die GUI die statische Adresse 10.4.0.254 gegeben

Per se ist das richtig. Man kann allerdings auch LAN und WLAN über ein Bridge Interface koppeln aber für dich ist der Weg erstmal über die statische WLAN IP der bessere... Erst wenn alles rennt könnte man das umstellen.
Belasse es also erstmal so.

Wichtig hier wie immer: WAS steht im Log unter /var/log/syslog oder messages ??? Dort steht in der Regel explizit wo das Problem ist.
Was du auch machen kannst ist mit systemctl stop hostapd den AP Daemon stoppen und ihn dann mal über die Kommandozeile mit hostapd starten, dann gibt der hostapd Fehler in der Konfig DIREKT auf der Konsole aus.
Diese, oder die Meldung des Syslog / Messages wäre hilfreich für ein zielführendes Troubleshooting. Leider fehlen diese mal wieder...

Ebenso deine hostapd.conf Datei um mal zu sehen was du da konfiguriert hast ! Auch da leider Fehlanzeige...

Passt das so oder habe ich hier schon den Fehler ?

Diese Frage kann man dir nicht sicher beantworten weil du es auch hier versäumt hast die Netzwerkmaske mitzuteilen.

Mit einer in der Regel üblichen 24 Bit Maske würde es passen. Mit anderen ggf. nicht.

müsste die SSID nicht auch mit falscher IP-Konfiguration zumindest ausgestrahlt werden ?

In der Tat ! Zeigt das einer oder mehrere Parameter der Kondig Datei falsch sind oder nicht gelesen wurden, was dann zum Stop bzw. Abbruch des hostapd Daemons fürht.
Da gilt es jetzt herauszufinden was das bewirkt. Deshalb Log oder CLI

Ich habe den AP direkt über die Konsole gestartet und dann mit "journalctl -xe" das log angesehen:

-- Subject: A start job for unit hostapd.service has begun execution
-- Defined-By: systemd
-- Support: https://www.debian.org/support
--
-- A start job for unit hostapd.service has begun execution.
--
-- The job identifier is 549273.
Nov 11 07:37:11 pi hostapd[317]: Configuration file: /etc/hostapd/hostapd.conf
Nov 11 07:37:11 pi hostapd[317]: Configuration file: /etc/hostapd/hostapd.conf
Nov 11 07:37:11 pi hostapd[317]: wlan0: interface state UNINITIALIZED->COUNTRY_UPDATE
Nov 11 07:37:11 pi hostapd[317]: wlan0: Could not connect to kernel driver
Nov 11 07:37:11 pi hostapd[317]: Using interface wlan0 with hwaddr b8:27:eb:63:49:18 and ssid "RasPi"  
Nov 11 07:37:12 pi dhcpcd[456]: wlan0: carrier acquired
Nov 11 07:37:12 pi hostapd[317]: wlan0: interface state COUNTRY_UPDATE->ENABLED
Nov 11 07:37:12 pi hostapd[317]: wlan0: AP-ENABLED
Nov 11 07:37:12 pi hostapd[317]: nl80211: kernel reports: Match already configured
Nov 11 07:37:12 pi hostapd[317]: nl80211: kernel reports: Match already configured
Nov 11 07:37:12 pi hostapd[317]: nl80211: kernel reports: Match already configured
Nov 11 07:37:12 pi hostapd[317]: wlan0: interface state UNINITIALIZED->COUNTRY_UPDATE
Nov 11 07:37:12 pi hostapd[317]: Could not set channel for kernel driver
Nov 11 07:37:12 pi hostapd[317]: Interface initialization failed
Nov 11 07:37:12 pi hostapd[317]: wlan0: interface state COUNTRY_UPDATE->DISABLED
Nov 11 07:37:12 pi hostapd[317]: wlan0: AP-DISABLED
Nov 11 07:37:12 pi hostapd[317]: wlan0: Unable to setup interface.
Nov 11 07:37:12 pi hostapd[317]: wlan0: interface state ENABLED->DISABLED
Nov 11 07:37:12 pi hostapd[317]: wlan0: AP-DISABLED
Nov 11 07:37:12 pi hostapd[317]: wlan0: CTRL-EVENT-TERMINATING
Nov 11 07:37:12 pi hostapd[317]: nl80211: deinit ifname=wlan0 disabled_11b_rates=0
Nov 11 07:37:12 pi dhcpcd[456]: wlan0: IAID eb:63:49:18
Nov 11 07:37:12 pi dhcpcd[456]: wlan0: adding address fe80::4f96:ddb6:4afb:1431
Nov 11 07:37:12 pi dhcpcd[456]: wlan0: probing address 10.4.0.254/24
Nov 11 07:37:12 pi avahi-daemon[371]: Joining mDNS multicast group on interface wlan0.IPv6 with address fe80::4f9
Nov 11 07:37:12 pi charon[555]: 13[KNL] fe80::4f96:ddb6:4afb:1431 appeared on wlan0
Nov 11 07:37:12 pi avahi-daemon[371]: New relevant interface wlan0.IPv6 for mDNS.
Nov 11 07:37:12 pi avahi-daemon[371]: Registering new address record for fe80::4f96:ddb6:4afb:1431 on wlan0.*.
Nov 11 07:37:12 pi dhcpcd[456]: wlan0: soliciting an IPv6 router
Nov 11 07:37:12 pi hostapd[317]: wlan0: interface state DISABLED->DISABLED
Nov 11 07:37:12 pi hostapd[317]: wlan0: AP-DISABLED
Nov 11 07:37:12 pi hostapd[317]: wlan0: CTRL-EVENT-TERMINATING
Nov 11 07:37:12 pi hostapd[317]: hostapd_free_hapd_data: Interface wlan0 wasn't started  
Nov 11 07:37:12 pi hostapd[317]: nl80211: deinit ifname=wlan0 disabled_11b_rates=0
Nov 11 07:37:12 pi systemd[1]: hostapd.service: Control process exited, code=exited, status=1/FAILURE
-- Subject: Unit process exited
-- Defined-By: systemd
-- Support: https://www.debian.org/support
--
-- An ExecStart= process belonging to unit hostapd.service has exited.
--
-- The process' exit code is 'exited' and its exit status is 1.  
Nov 11 07:37:12 pi systemd[1]: hostapd.service: Failed with result 'exit-code'.  
-- Subject: Unit failed
-- Defined-By: systemd
-- Support: https://www.debian.org/support
--
-- The unit hostapd.service has entered the 'failed' state with result 'exit-code'.  
Nov 11 07:37:12 pi systemd[1]: Failed to start Advanced IEEE 802.11 AP and IEEE 802.1X/WPA/WPA2/EAP Authenticator
-- Subject: A start job for unit hostapd.service has failed
-- Defined-By: systemd
-- Support: https://www.debian.org/support
--
-- A start job for unit hostapd.service has finished with a failure.
--
-- The job identifier is 549273 and the job result is failed.
Nov 11 07:37:13 pi dhcpcd[456]: wlan0: carrier lost
Nov 11 07:37:13 pi dhcpcd[456]: wlan0: deleting address fe80::4f96:ddb6:4afb:1431
Nov 11 07:37:13 pi avahi-daemon[371]: Withdrawing address record for fe80::4f96:ddb6:4afb:1431 on wlan0.
Nov 11 07:37:13 pi charon[555]: 10[KNL] fe80::4f96:ddb6:4afb:1431 disappeared from wlan0
Nov 11 07:37:13 pi avahi-daemon[371]: Leaving mDNS multicast group on interface wlan0.IPv6 with address fe80::4f9
Nov 11 07:37:13 pi avahi-daemon[371]: Interface wlan0.IPv6 no longer relevant for mDNS.

Hier auch meine hostapd.conf:

interface=wlan0
driver=nl80211
# WLAN Name (SSID), Landeseinstellung Funkkanal und .11 Modus
ssid=RasPi
country_code=DE
ieee80211d=1
hw_mode=g
ieee80211n=1
wmm_enabled=1
channel=3
# Timing Parameter
max_num_sta=32
macaddr_acl=0
auth_algs=1
ignore_broadcast_ssid=0
# WPA Schluesseleinstellungen u. Passwort
wpa=2
wpa_passphrase=raspberry123
wpa_key_mgmt=WPA-PSK
rsn_pairwise=CCMP
wpa_pairwise=CCMP

Und meine dhcpcd.conf:

# Allow users of this group to interact with dhcpcd via the control socket.
#controlgroup wheel

# Inform the DHCP server of our hostname for DDNS.
hostname

# Use the hardware address of the interface for the Client ID.
clientid

# Persist interface configuration when dhcpcd exits.
persistent

# Rapid commit support.
# Safe to enable by default because it requires the equivalent option set
# on the server to actually work.
option rapid_commit

# A list of options to request from the DHCP server.
option domain_name_servers, domain_name, domain_search, host_name
option classless_static_routes
# Respect the network MTU. This is applied to DHCP routes.
option interface_mtu

# A ServerID is required by RFC2131.
require dhcp_server_identifier

# Generate SLAAC address using the Hardware Address of the interface
#slaac hwadd
# OR generate Stable Private IPv6 Addresses based from the DUID
slaac private

interface wlan0
static ip_address=10.4.0.254/24
static routers=192.168.178.1
static domain_name_servers=192.168.178.1

interface state UNINITIALIZED->COUNTRY_UPDATE

Du hast im System Setup vergessen global den Country Code zu setzen kann das sein ?? Ohne den sendet der WLAN Chip generell nicht.
Also vergessen raspi-config auszuführen nach dem Einsetzen der SD Karte !!
Dort musst du den Country Code setzen auf DE !
Sofern du dort fälschlicherweise eine SSID und Passwort gesetzt hast musst du die wpa_supplicant.conf unter /etc deaktivieren indem du sie umbenennst z.B. in wpa_supplicant.original oder mit rm ganz weglöschst.
Das WLAN Interface darf zudem KEINE Gateway IP und KEINE DNS IP haben. Logisch denn im AP Mode ist es ja selber Gateway.
Dort darf in der dhcpcd.conf rein nur die IP Adresse an wlan0 gesetzt sein. Mehr nicht !!

Zitat von @aqui:

Du hast im System Setup vergessen global den Country Code zu setzen kann das sein ?? Ohne den sendet der WLAN Chip generell nicht.
Also vergessen raspi-config auszuführen nach dem Einsetzen der SD Karte !!

Ne, das hatte ich gemacht.

Sofern du dort fälschlicherweise eine SSID und Passwort gesetzt hast musst du die wpa_supplicant.conf unter /etc deaktivieren indem du sie umbenennst z.B. in wpa_supplicant.original oder mit rm ganz weglöschst.

Hatte ich gemacht aber danach kann man nicht mehr per raspi-config in die WLAN-Country Einstellungen. (Fehlermeldung: Could not communicate with wpa_supplicant)
Daher habe ich die Datei danach wieder angelegt mit nano /etc/wpa_supplicant/wpa_supplicant.conf und folgendem Inhalt:

trl_interface=/var/run/wpa_supplicant
update_config=1
country=DE

Das WLAN Interface darf zudem KEINE Gateway IP und KEINE DNS IP haben. Logisch denn im AP Mode ist es ja selber Gateway.
Dort darf in der dhcpcd.conf rein nur die IP Adresse an wlan0 gesetzt sein. Mehr nicht !!

Hab ich jetzt auch geändert.

Jetzt wird die SSID auch ausgestrahlt aber ein verbinden funktioniert leider nicht (Verbindung zum Netzwerk "RasPi" fehlgeschlagen) meldet mein IPAD.

Also nochmal systemctl restart hostapd ausgeführt und das log schmeißt folgendes Ergebnis:

-- The job identifier is 13291.
Nov 12 09:27:20 pi hostapd[4142]: Configuration file: /etc/hostapd/hostapd.conf
Nov 12 09:27:20 pi hostapd[4142]: Configuration file: /etc/hostapd/hostapd.conf
Nov 12 09:27:20 pi hostapd[4142]: wlan0: interface state UNINITIALIZED->COUNTRY_UPDATE
Nov 12 09:27:20 pi hostapd[4142]: wlan0: Could not connect to kernel driver
Nov 12 09:27:20 pi hostapd[4142]: Using interface wlan0 with hwaddr b8:27:eb:63:49:18 and ssid "RasPi"  
Nov 12 09:27:21 pi dhcpcd[416]: wlan0: carrier acquired
Nov 12 09:27:21 pi hostapd[4142]: wlan0: interface state COUNTRY_UPDATE->ENABLED
Nov 12 09:27:21 pi hostapd[4142]: wlan0: AP-ENABLED
Nov 12 09:27:21 pi hostapd[4142]: nl80211: kernel reports: Match already configured
Nov 12 09:27:21 pi hostapd[4142]: nl80211: kernel reports: Match already configured
Nov 12 09:27:21 pi hostapd[4142]: nl80211: kernel reports: Match already configured
Nov 12 09:27:21 pi hostapd[4142]: wlan0: interface state UNINITIALIZED->COUNTRY_UPDATE
Nov 12 09:27:21 pi hostapd[4142]: Could not set channel for kernel driver
Nov 12 09:27:21 pi hostapd[4142]: Interface initialization failed
Nov 12 09:27:21 pi hostapd[4142]: wlan0: interface state COUNTRY_UPDATE->DISABLED
Nov 12 09:27:21 pi hostapd[4142]: wlan0: AP-DISABLED
Nov 12 09:27:21 pi hostapd[4142]: wlan0: Unable to setup interface.
Nov 12 09:27:21 pi hostapd[4142]: wlan0: interface state ENABLED->DISABLED
Nov 12 09:27:21 pi hostapd[4142]: wlan0: AP-DISABLED
Nov 12 09:27:21 pi hostapd[4142]: wlan0: CTRL-EVENT-TERMINATING
Nov 12 09:27:21 pi hostapd[4142]: nl80211: deinit ifname=wlan0 disabled_11b_rates=0
Nov 12 09:27:21 pi dhcpcd[416]: wlan0: IAID eb:63:49:18
Nov 12 09:27:21 pi dhcpcd[416]: wlan0: adding address fe80::4f96:ddb6:4afb:1431
Nov 12 09:27:21 pi avahi-daemon[335]: Joining mDNS multicast group on interface wlan0.IPv6 with address fe80::4f96:ddb6:4afb:1431.
Nov 12 09:27:21 pi avahi-daemon[335]: New relevant interface wlan0.IPv6 for mDNS.
Nov 12 09:27:21 pi avahi-daemon[335]: Registering new address record for fe80::4f96:ddb6:4afb:1431 on wlan0.*.
Nov 12 09:27:21 pi charon[511]: 08[KNL] fe80::4f96:ddb6:4afb:1431 appeared on wlan0
Nov 12 09:27:21 pi dhcpcd[416]: wlan0: probing address 10.4.0.254/24
Nov 12 09:27:21 pi hostapd[4142]: wlan0: interface state DISABLED->DISABLED
Nov 12 09:27:21 pi hostapd[4142]: wlan0: AP-DISABLED
Nov 12 09:27:21 pi hostapd[4142]: wlan0: CTRL-EVENT-TERMINATING
Nov 12 09:27:21 pi hostapd[4142]: hostapd_free_hapd_data: Interface wlan0 wasn't started  
Nov 12 09:27:21 pi hostapd[4142]: nl80211: deinit ifname=wlan0 disabled_11b_rates=0
Nov 12 09:27:21 pi systemd[1]: hostapd.service: Control process exited, code=exited, status=1/FAILURE
-- Subject: Unit process exited
-- Defined-By: systemd
-- Support: https://www.debian.org/support
-- 
-- An ExecStart= process belonging to unit hostapd.service has exited.
-- 
-- The process' exit code is 'exited' and its exit status is 1.  
Nov 12 09:27:21 pi systemd[1]: hostapd.service: Failed with result 'exit-code'.  
-- Subject: Unit failed
-- Defined-By: systemd
-- Support: https://www.debian.org/support
-- 
-- The unit hostapd.service has entered the 'failed' state with result 'exit-code'.  
Nov 12 09:27:21 pi systemd[1]: Failed to start Advanced IEEE 802.11 AP and IEEE 802.1X/WPA/WPA2/EAP Authenticator.
-- Subject: A start job for unit hostapd.service has failed
-- Defined-By: systemd
-- Support: https://www.debian.org/support
-- 
-- A start job for unit hostapd.service has finished with a failure.
-- 
-- The job identifier is 13291 and the job result is failed.
Nov 12 09:27:21 pi dhcpcd[416]: wlan0: soliciting an IPv6 router
Nov 12 09:27:22 pi dhcpcd[416]: wlan0: carrier lost
Nov 12 09:27:22 pi dhcpcd[416]: wlan0: deleting address fe80::4f96:ddb6:4afb:1431
Nov 12 09:27:22 pi avahi-daemon[335]: Withdrawing address record for fe80::4f96:ddb6:4afb:1431 on wlan0.
Nov 12 09:27:22 pi charon[511]: 11[KNL] fe80::4f96:ddb6:4afb:1431 disappeared from wlan0
Nov 12 09:27:22 pi avahi-daemon[335]: Leaving mDNS multicast group on interface wlan0.IPv6 with address fe80::4f96:ddb6:4afb:1431.
Nov 12 09:27:22 pi avahi-daemon[335]: Interface wlan0.IPv6 no longer relevant for mDNS.

Wie gesagt SSID wird auf jeden Fall weiter ausgestrahlt, nur die Verbindung funktioniert nicht.

Hab das hier mal gegoogelt:

Failed to start Advanced IEEE 802.11 AP and IEEE 802.1X/WPA/WPA2/EAP Authenticator

Dann hieß es, man soll das hier ausführen:

rfkill unblock wlan

Gemacht und rebootet, jetzt kommt zumindest der Fehler nicht mehr auch wenn das Ergebnis leider unverändert bleibt:

The job identifier is 2491 and the job result is failed.
Nov 12 09:50:43 pi dhcpcd[414]: wlan0: carrier lost
Nov 12 09:50:43 pi dhcpcd[414]: wlan0: deleting address fe80::4f96:ddb6:4afb:1431
Nov 12 09:50:43 pi avahi-daemon[329]: Withdrawing address record for fe80::4f96:ddb6:4afb:1431 on wlan0.
Nov 12 09:50:43 pi charon[516]: 06[KNL] fe80::4f96:ddb6:4afb:1431 disappeared from wlan0
Nov 12 09:50:43 pi avahi-daemon[329]: Leaving mDNS multicast group on interface wlan0.IPv6 with address fe80::4f96:ddb6:4afb:1431.
Nov 12 09:50:43 pi avahi-daemon[329]: Interface wlan0.IPv6 no longer relevant for mDNS.
Nov 12 09:50:45 pi systemd[1]: hostapd.service: Service RestartSec=2s expired, scheduling restart.
Nov 12 09:50:45 pi systemd[1]: hostapd.service: Scheduled restart job, restart counter is at 2.
-- Subject: Automatic restarting of a unit has been scheduled
-- Defined-By: systemd
-- Support: https://www.debian.org/support
-- 
-- Automatic restarting of the unit hostapd.service has been scheduled, as the result for
-- the configured Restart= setting for the unit.
Nov 12 09:50:45 pi systemd[1]: Stopped Advanced IEEE 802.11 AP and IEEE 802.1X/WPA/WPA2/EAP Authenticator.
-- Subject: A stop job for unit hostapd.service has finished
-- Defined-By: systemd
-- Support: https://www.debian.org/support
-- 
-- A stop job for unit hostapd.service has finished.
-- 
-- The job identifier is 2551 and the job result is done.
Nov 12 09:50:45 pi systemd[1]: Starting Advanced IEEE 802.11 AP and IEEE 802.1X/WPA/WPA2/EAP Authenticator...
-- Subject: A start job for unit hostapd.service has begun execution
-- Defined-By: systemd
-- Support: https://www.debian.org/support
-- 
-- A start job for unit hostapd.service has begun execution.
-- 
-- The job identifier is 2551.
Nov 12 09:50:45 pi hostapd[1624]: Configuration file: /etc/hostapd/hostapd.conf
Nov 12 09:50:45 pi hostapd[1624]: Configuration file: /etc/hostapd/hostapd.conf
Nov 12 09:50:45 pi hostapd[1624]: wlan0: interface state UNINITIALIZED->COUNTRY_UPDATE
Nov 12 09:50:45 pi hostapd[1624]: wlan0: Could not connect to kernel driver
Nov 12 09:50:45 pi hostapd[1624]: Using interface wlan0 with hwaddr b8:27:eb:63:49:18 and ssid "RasPi"  
Nov 12 09:50:45 pi pppd[1065]: sent [LCP EchoReq id=0x2 magic=0xc1548fc9]
Nov 12 09:50:45 pi pppd[1065]: rcvd [LCP EchoReq id=0x1 magic=0xcca07f13]
Nov 12 09:50:45 pi pppd[1065]: sent [LCP EchoRep id=0x1 magic=0xc1548fc9]
Nov 12 09:50:45 pi pppd[1065]: rcvd [LCP EchoRep id=0x2 magic=0xcca07f13]
Nov 12 09:50:45 pi dhcpcd[414]: wlan0: carrier acquired
Nov 12 09:50:45 pi hostapd[1624]: wlan0: interface state COUNTRY_UPDATE->ENABLED
Nov 12 09:50:45 pi hostapd[1624]: wlan0: AP-ENABLED
Nov 12 09:50:45 pi hostapd[1624]: nl80211: kernel reports: Match already configured
Nov 12 09:50:45 pi hostapd[1624]: nl80211: kernel reports: Match already configured
Nov 12 09:50:45 pi hostapd[1624]: nl80211: kernel reports: Match already configured
Nov 12 09:50:45 pi hostapd[1624]: wlan0: interface state UNINITIALIZED->COUNTRY_UPDATE
Nov 12 09:50:45 pi dhcpcd[414]: wlan0: IAID eb:63:49:18
Nov 12 09:50:45 pi dhcpcd[414]: wlan0: adding address fe80::4f96:ddb6:4afb:1431
Nov 12 09:50:45 pi hostapd[1624]: Could not set channel for kernel driver
Nov 12 09:50:45 pi hostapd[1624]: Interface initialization failed
Nov 12 09:50:45 pi hostapd[1624]: wlan0: interface state COUNTRY_UPDATE->DISABLED
Nov 12 09:50:45 pi hostapd[1624]: wlan0: AP-DISABLED
Nov 12 09:50:45 pi hostapd[1624]: wlan0: Unable to setup interface.
Nov 12 09:50:45 pi hostapd[1624]: wlan0: interface state ENABLED->DISABLED
Nov 12 09:50:45 pi avahi-daemon[329]: Joining mDNS multicast group on interface wlan0.IPv6 with address fe80::4f96:ddb6:4afb:1431.
Nov 12 09:50:45 pi dhcpcd[414]: wlan0: probing address 10.4.0.254/24
Nov 12 09:50:45 pi avahi-daemon[329]: New relevant interface wlan0.IPv6 for mDNS.
Nov 12 09:50:45 pi avahi-daemon[329]: Registering new address record for fe80::4f96:ddb6:4afb:1431 on wlan0.*.
Nov 12 09:50:45 pi charon[516]: 12[KNL] fe80::4f96:ddb6:4afb:1431 appeared on wlan0
Nov 12 09:50:45 pi hostapd[1624]: wlan0: AP-DISABLED
Nov 12 09:50:45 pi hostapd[1624]: wlan0: CTRL-EVENT-TERMINATING
Nov 12 09:50:45 pi hostapd[1624]: nl80211: deinit ifname=wlan0 disabled_11b_rates=0

Es fehlt weiterhin deine /etc/hostapd.conf. Wie soll man dir dann zielführend helfen...

Halte dich doch einfach an die originale und wasserdicht getestete AP Konfig der RasPi Foundation:
https://www.raspberrypi.com/documentation/computers/configuration.html#c ...
(Klick auf "Configure the AP")
Damit klappt es hier auf einem 3B und einem 4er auf Anhieb fehlerfrei !
Laut der Doku ist auch deine wpa_supplicant zumindest in Teilen falsch.

https://www.raspberrypi.com/documentation/computers/configuration.html#c ...
("configure networking")

Zitat von @aqui:

Es fehlt weiterhin deine /etc/hostapd.conf. Wie soll man dir dann zielführend helfen...

Hatte ich aber gepostet:

Hier auch meine hostapd.conf:

interface=wlan0
> driver=nl80211
> # WLAN Name (SSID), Landeseinstellung Funkkanal und .11 Modus
> ssid=RasPi
> country_code=DE
> ieee80211d=1
> hw_mode=g
> ieee80211n=1
> wmm_enabled=1
> channel=3
> # Timing Parameter
> max_num_sta=32
> macaddr_acl=0
> auth_algs=1
> ignore_broadcast_ssid=0
> # WPA Schluesseleinstellungen u. Passwort
> wpa=2
> wpa_passphrase=raspberry123
> wpa_key_mgmt=WPA-PSK
> rsn_pairwise=CCMP
> wpa_pairwise=CCMP

https://www.raspberrypi.com/documentation/computers/configuration.html#c ...
("configure networking")

Bei mir ändert sich das Fehlerbild aber nicht, keine Ahnung was da bei mir in der Konfiguration falsch ist....

Hatte ich aber gepostet:

Sorry, hatte ich übersehen...
Gehe mal strategisch vor und mache folgende Einträge in deinen Setup Dateien und lasse alle Überflüssige weg:

dhcpcd.conf

interface wlan0
    static ip_address=10.4.0.254/24
    nohook wpa_supplicant 

Dann sudo rfkill unblock wlan eingeben und die hostapd.conf bearbeiten.

hostapd.conf

country_code=DE
ieee80211d=1
interface=wlan0
ssid=RasPi
hw_mode=g
channel=7
macaddr_acl=0
auth_algs=1
ignore_broadcast_ssid=0
wpa=2
wpa_passphrase=raspberry123
wpa_key_mgmt=WPA-PSK
wpa_pairwise=CCMP
rsn_pairwise=CCMP 

Danach mit sudo systemctl reboot den RasPi rebooten.
Danach sollte der AP mit der o,.a. SSID zu sehen sein.
Das ist exakt die Konfig die hier in einem 3B und in einen 4er rennt und völlig fehlerfrei funktioniert.
Alle diese getesteten und fehlerfreien Konfigs findest du auch in der offiziellen Doku der Raspberry Pi Foundation:
https://www.raspberrypi.com/documentation/computers/configuration.html#s ...

Danach konnte ich per rdp nicht mehr auf den Rasp zugreifen.

Ich werde nochmal versuchen den Pi neu aufzusetzen... Vielleicht habe ich durch die ganze Konfiguriererei irgendwas kaputt gemacht... Aber dafür brauche ich etwas Zeit.
Ich hab den Beitrag jetzt erstmal als gelöst markiert.

Vielen Dank nochmal für Eure Hilfe und vor allem Geduld!

VG