Ubtuntu 20.10 mit UdmPro L2tp VPN Server verbinden
Hallo liebe Administratoren,
ich habe eine kleine Frage. Bei mir zuhause steht eine Ubiquiti Dream Machine Pro, auf der ich den L2tp VPN Server aktiviert habe und mich über Handy und Windows Laptop zuhause einwählen kann. Jetzt habe ich noch ein Ubuntu (Version 20.10) Notebook und möchte mich damit auch in mein Heimnetzwerk verbinden, scheitere jedoch an der Einwahl, durch eventuelle Fehlkonfiguration meinerseits.
Anbei noch meine Konfiguration, eventuell hat jemand von euch eine Idee wo mein Fehler liegt. Passwörter und Benutzernamen, sowie richtige IP habe ich schon mehrmals überprüft.
Vielen Dank für jede Anregung.
tzabbi
ich habe eine kleine Frage. Bei mir zuhause steht eine Ubiquiti Dream Machine Pro, auf der ich den L2tp VPN Server aktiviert habe und mich über Handy und Windows Laptop zuhause einwählen kann. Jetzt habe ich noch ein Ubuntu (Version 20.10) Notebook und möchte mich damit auch in mein Heimnetzwerk verbinden, scheitere jedoch an der Einwahl, durch eventuelle Fehlkonfiguration meinerseits.
Anbei noch meine Konfiguration, eventuell hat jemand von euch eine Idee wo mein Fehler liegt. Passwörter und Benutzernamen, sowie richtige IP habe ich schon mehrmals überprüft.
Vielen Dank für jede Anregung.
tzabbi
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 665167
Url: https://administrator.de/contentid/665167
Ausgedruckt am: 19.12.2024 um 08:12 Uhr
29 Kommentare
Neuester Kommentar
Moin.
Leider liefern die Screenshots zu wenig "essentielle" Infos, außerdem fehlen sämtliche Infos zu freigegebenen Ports 500/4500UDP 1701TCP und Proto 50(ESP) und für das Profil aktivierten Phase1 und Phase2 Ciphers, einfach mal in die Strongswan-Config der UDM schauen dann hast du es schwarz auf weiß. Und überprüfen ob die externe ip evt. im CGN NAT Bereich liegt 100.64.0.0/10, dann ist das Vorhaben ja sowieso zwecklos.
Wie immer bei sowas als erste Anlaufstelle: LOGs checken, und hier posten!
https://help.ui.com/hc/en-us/articles/360002668854-UniFi-UDM-USG-Verifyi ...
Damit kann man in 99,99% der Fälle die Ursache sofort klären warum die Verbindung nicht erfolgreich aufgebaut wird, alles andere ist Glaskugel polieren
Gruß SK
Leider liefern die Screenshots zu wenig "essentielle" Infos, außerdem fehlen sämtliche Infos zu freigegebenen Ports 500/4500UDP 1701TCP und Proto 50(ESP) und für das Profil aktivierten Phase1 und Phase2 Ciphers, einfach mal in die Strongswan-Config der UDM schauen dann hast du es schwarz auf weiß. Und überprüfen ob die externe ip evt. im CGN NAT Bereich liegt 100.64.0.0/10, dann ist das Vorhaben ja sowieso zwecklos.
Wie immer bei sowas als erste Anlaufstelle: LOGs checken, und hier posten!
https://help.ui.com/hc/en-us/articles/360002668854-UniFi-UDM-USG-Verifyi ...
Damit kann man in 99,99% der Fälle die Ursache sofort klären warum die Verbindung nicht erfolgreich aufgebaut wird, alles andere ist Glaskugel polieren
Gruß SK
Wird vermutlich am 3DES liegen. Das ist mittlerweile tiefstes Neandertal was Verschlüsselung anbetrifft und von fast keinem Endgerät mehr supportet. Die UBQT Gurke wird das sicher auch nicht mehr supporten, da es schon lange als unsicher gilt.
Setze P1 und P2 auf AES 128 oder AES 256 mit SHA1 (ist zwingend bei L2TP !) und modp 1024 das sollte vermutlich das Problem sofort lösen.
Weitere Infos zu dem Thema auch hier:
PfSense VPN mit L2TP (IPsec) Protokoll für mobile Nutzer
Scheitern am IPsec VPN mit MikroTik
Setze P1 und P2 auf AES 128 oder AES 256 mit SHA1 (ist zwingend bei L2TP !) und modp 1024 das sollte vermutlich das Problem sofort lösen.
Weitere Infos zu dem Thema auch hier:
PfSense VPN mit L2TP (IPsec) Protokoll für mobile Nutzer
Scheitern am IPsec VPN mit MikroTik
Das bringt deinen Tunnel zu Fall:
invalid HASH_V1 payload length, decryption failed?
Es gibt zig Lösungs Threads dazu wenn man danach sucht:
https://community.ui.com/questions/L2TP-over-IPsec-VPN-server-issue-with ...
https://wiki.strongswan.org/issues/3009
https://wiki.strongswan.org/issues/3322
usw. usw.
invalid HASH_V1 payload length, decryption failed?
Es gibt zig Lösungs Threads dazu wenn man danach sucht:
https://community.ui.com/questions/L2TP-over-IPsec-VPN-server-issue-with ...
https://wiki.strongswan.org/issues/3009
https://wiki.strongswan.org/issues/3322
usw. usw.
Sorry, ich meinte die andere Seite, sprich den StrongSwan !
Das ist ja immer noch die "invalid ID_V1 payload length, decryption failed?" Fehlermeldung.
Da wäre es mal ganz interessant was StrongSwan da sagt ?! Ggf. auch mal die StrongSwan Konfig Datei hier posten.
https://wiki.strongswan.org/projects/strongswan/wiki/Loggerconfiguration
Denk dran das du in der P2 kein PFS machen darfst !!! PFS muss dort zwingend deaktiviert sein !
Das ist ja immer noch die "invalid ID_V1 payload length, decryption failed?" Fehlermeldung.
Da wäre es mal ganz interessant was StrongSwan da sagt ?! Ggf. auch mal die StrongSwan Konfig Datei hier posten.
https://wiki.strongswan.org/projects/strongswan/wiki/Loggerconfiguration
und in P2: aes128-sha1
In P2 darfst du bei L2TP nur AES128 und SHA1 machen.Denk dran das du in der P2 kein PFS machen darfst !!! PFS muss dort zwingend deaktiviert sein !
Hier ist es recht gut erklärt:
https://jeanbruenn.info/2017/04/13/strongswan-l2tp-using-xl2tpd/
Checke das grad auf einem Debian an einem Mikrotik_L2TP_VPN_Server.
https://jeanbruenn.info/2017/04/13/strongswan-l2tp-using-xl2tpd/
Checke das grad auf einem Debian an einem Mikrotik_L2TP_VPN_Server.
Inhaltsverzeichnis
Hier die funktionierende Lösung mit der CLI Lösung ohne X-Windows GUI !! Mit Windows GUI gibt es einen grafischen L2TP Client der einfach per Mausklick einzurichten ist wie z.B. hier unter Ubuntu bzw. allen Debian basierten Distros.
Getestet mit Ubuntu und Debian auf einem L2TP Server Mikrotik und Windows. Rennt mit allen 3 L2TP Servern fehlerfrei !
1.) L2TP Komponenten aus dem Repository installieren:
- apt install strongswan
- apt install xl2tpd
2.) Strongswan einrichten:
Hier sind 2 Dateien relevant:
- /etc/ipsec.conf = IPsec Verbindungs Konfig
- /etc/ipsec.secret = PSKs
conn l2tp
ikelifetime=60m
keylife=20m
rekeymargin=3m
keyexchange=ikev1
authby=secret
ike=aes128-sha1-modp2048
esp=aes128-sha1-modp2048
auto=add
type=transport
leftprotoport=17/1701
right=1.2.3.4
rightprotoport=17/1701
IPsec Preshared Key Datei (/etc/ipsec.secret):
: PSK "test1234"
3.) L2TP Daemon einrichten
Auch hier 2 Dateien:
- /etc/xl2tpd/xl2tpd.conf
- /etc/ppp/options.l2tpd.client
[global]
access control = yes
debug tunnel = yes
[lac l2tp]
lns = 1.2.3.4
ppp debug = yes
pppoptfile = /etc/ppp/options.l2tpd.client
length bit = yes
PPP Options Datei (/etc/ppp/options.l2tpd.client):
ipcp-accept-local
ipcp-accept-remote
require-mschap-v2
refuse-eap
noccp
noauth
idle 1800
mtu 1410
mru 1410
noipdefault
nodefaultroute
connect-delay 5000
name testuser
password geheim123
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
Fazit:
Works as designed ! 😉
5.) Weiterführende Links zum Thema L2TP VPN
Das kann dann nur noch am L2TP Server selber liegen. Hier kommt es natürlich darauf an welche Cipher Suites der supportet bzw. dort konfiguriert sind. Gut möglich das der nur DH Group 2 kann. Dann solltest du die 2 Zeilen:
ike=aes128-sha1-modp1024
esp=aes128-sha1-modp1024
entsprechend mal umkonfigurieren und nochmal testen.
Mit welchen Ciphers ist denn dein L2TP Server konfiguriert ?!
Hier siehst du die P1 Ciphers vom L2TP Server (Mikrotik)
Auf dem ebenfalls getesten L2TP Server der pfSense sind diese identisch eingestellt !
Hier siehst du mal die Outputs allein wenn man nur den IPsec Tunnel aufbaut:
Bzw. der Staus des IPsec Tunnels
Hier das ganze der Vollständigkeit halber nochmal mit...
192.168.88.1 ist die lokale LAN IP Adresse des L2TP Servers auf der anderen Seite:
Der Syslog Output zum L2TP ist dann entsprechend wenn du dir den unter /var/log/syslog einmal ansiehst (der Übersicht halber gekürzt):
pppd[3422]: rcvd [CHAP Success id=0x1 "S=335C632F51D6088B5302F449110F2461C3F3F285"]
pppd[3422]: response found in cache (entry 0)
pppd[3422]: CHAP authentication succeeded
pppd[3422]: sent [IPCP ConfReq id=0x1 <addr 0.0.0.0>]
pppd[3422]: rcvd [IPCP ConfReq id=0x1 <addr 192.168.88.1>]
pppd[3422]: sent [IPCP ConfAck id=0x1 <addr 192.168.88.1>]
pppd[3422]: rcvd [proto=0x8281] 01 01 00 04
pppd[3422]: local IP address 192.168.88.200
pppd[3422]: remote IP address 192.168.88.1
charon: 05[KNL] 192.168.88.200 appeared on ppp0
charon: 13[KNL] interface ppp0 activated
Fazit:
Das der L2TP Tunnelaufbau mit 2 verschiedenen Linux Distributionen absolut fehlerfrei rennt auf 2 unterschiedliche L2TP VPN Server zeigt eindeutig das der böse Buhmann bei dir nur dein L2TP Server selber sein kann !!
Bzw. ggf. nutzt dieser falsche Cipher Suites oder du hast ihm falsche konfiguriert oder was auch immer. Wäre aber schon komisch, denn alle gängigen L2TP Server nutzen so gut wie immer die üblichen L2TP Standard Settings dafür damit sie immer fehlerfrei mit allen meistverbreiteten L2TP Clients laufen. Siehe oben...
Du solltest dir also nochmals deinen L2TP Server und dessen Konfig sehr genau ansehen !! Dieser wird vermutlich auch weder mit dem bordeigenen Windows L2TP Client noch mit dem eines Apple Macs oder iOS iPhones oder auch Androiden zusammen laufen, richtig ? Was dann ein sicheres Indiz dafür ist das der Server Konfig technisch einen "an der Waffel" hat.
ike=aes128-sha1-modp1024
esp=aes128-sha1-modp1024
entsprechend mal umkonfigurieren und nochmal testen.
Mit welchen Ciphers ist denn dein L2TP Server konfiguriert ?!
Hier siehst du die P1 Ciphers vom L2TP Server (Mikrotik)
Auf dem ebenfalls getesten L2TP Server der pfSense sind diese identisch eingestellt !
Hier siehst du mal die Outputs allein wenn man nur den IPsec Tunnel aufbaut:
Strongswan Output:
root@debiansrv:/etc# ipsec up mt-l2tp
initiating Main Mode IKE_SA mt-l2tp[1] to 10.99.1.136
generating ID_PROT request 0 [ SA V V V V V ]
sending packet: from 10.99.1.141[500] to 10.99.1.136[500] (240 bytes)
received packet: from 10.99.1.136[500] to 10.99.1.141[500] (160 bytes)
parsed ID_PROT response 0 [ SA V V V V ]
received NAT-T (RFC 3947) vendor ID
received XAuth vendor ID
received DPD vendor ID
received FRAGMENTATION vendor ID
selected proposal: IKE:AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048
generating ID_PROT request 0 [ KE No NAT-D NAT-D ]
sending packet: from 10.99.1.141[500] to 10.99.1.136[500] (372 bytes)
received packet: from 10.99.1.136[500] to 10.99.1.141[500] (364 bytes)
parsed ID_PROT response 0 [ KE No NAT-D NAT-D ]
generating ID_PROT request 0 [ ID HASH N(INITIAL_CONTACT) ]
sending packet: from 10.99.1.141[500] to 10.99.1.136[500] (108 bytes)
received packet: from 10.99.1.136[500] to 10.99.1.141[500] (76 bytes)
parsed ID_PROT response 0 [ ID HASH ]
IKE_SA mt-l2tp[1] established between 10.99.1.141[10.99.1.141]...10.99.1.136[10.99.1.136]
scheduling reauthentication in 3323s
maximum IKE_SA lifetime 3503s
generating QUICK_MODE request 3259047429 [ HASH SA No KE ID ID ]
sending packet: from 10.99.1.141[500] to 10.99.1.136[500] (444 bytes)
received packet: from 10.99.1.136[500] to 10.99.1.141[500] (92 bytes)
parsed INFORMATIONAL_V1 request 2578376834 [ HASH N(INITIAL_CONTACT) ]
received packet: from 10.99.1.136[500] to 10.99.1.141[500] (428 bytes)
parsed QUICK_MODE response 3259047429 [ HASH SA No KE ID ID ]
selected proposal: ESP:AES_CBC_128/HMAC_SHA1_96/MODP_2048/NO_EXT_SEQ
CHILD_SA mt-l2tp{1} established with SPIs c4b63172_i 0a33df32_o and TS 10.99.1.141/32[udp/l2f] === 10.99.1.136/32[udp/l2f]
connection 'mt-l2tp' established successfully
root@debiansrv:/etc# ipsec status
Security Associations (1 up, 0 connecting):
mt-l2tp[1]: ESTABLISHED 42 seconds ago, 10.99.1.141[10.99.1.141]...10.99.1.136[10.99.1.136]
mt-l2tp{1}: INSTALLED, TRANSPORT, reqid 1, ESP SPIs: c8e3cc2a_i 0d2ae8fa_o
mt-l2tp{1}: 10.99.1.141/32[udp/l2f] === 10.99.1.136/32[udp/l2f]
L2TP Tunnel:
Nach dem Aufbau mit /bin/echo "c l2tp-mt" > /var/run/xl2tpd/l2tp-control baut sich dann auch sofort das ppp0 Tunnel Interface auf:root@debiansrv:/etc/# ip addr show
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether b8:27:eb:73:39:aa brd ff:ff:ff:ff:ff:ff
inet 10.99.1.141/24 brd 10.99.1.255 scope global dynamic noprefixroute eth0
valid_lft 1973sec preferred_lft 1523sec
inet6 1234:cc:711:4699:9753:206c:c899:dcfd/64 scope global dynamic mngtmpaddr noprefixroute
valid_lft 2591807sec preferred_lft 604607sec
inet6 fe80::482f:8602:827d:4d31/64 scope link
valid_lft forever preferred_lft forever
3: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1410 qdisc pfifo_fast state UNKNOWN group default qlen 3
link/ppp
inet 192.168.88.200 peer 192.168.88.1/32 scope global ppp0
valid_lft forever preferred_lft forever
Hier das ganze der Vollständigkeit halber nochmal mit...
Ubuntu:
root@ubuntusrv:/etc# lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 20.04.2 LTS
Release: 20.04
Codename: focal
root@ubuntusrv:/etc# ipsec up l2tp
initiating Main Mode IKE_SA l2tp[1] to 10.99.1.136
generating ID_PROT request 0 [ SA V V V V V ]
sending packet: from 10.99.1.143[500] to 10.99.1.136[500] (240 bytes)
received packet: from 10.99.1.136[500] to 10.99.1.143[500] (160 bytes)
parsed ID_PROT response 0 [ SA V V V V ]
received NAT-T (RFC 3947) vendor ID
received XAuth vendor ID
received DPD vendor ID
received FRAGMENTATION vendor ID
selected proposal: IKE:AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048
generating ID_PROT request 0 [ KE No NAT-D NAT-D ]
sending packet: from 10.99.1.143[500] to 10.99.1.136[500] (372 bytes)
received packet: from 10.99.1.136[500] to 10.99.1.143[500] (364 bytes)
parsed ID_PROT response 0 [ KE No NAT-D NAT-D ]
generating ID_PROT request 0 [ ID HASH N(INITIAL_CONTACT) ]
sending packet: from 10.99.1.143[500] to 10.99.1.136[500] (108 bytes)
received packet: from 10.99.1.136[500] to 10.99.1.143[500] (76 bytes)
parsed ID_PROT response 0 [ ID HASH ]
IKE_SA l2tp[1] established between 10.99.1.143[10.99.1.143]...10.99.1.136[10.99.1.136]
scheduling reauthentication in 3288s
maximum IKE_SA lifetime 3468s
generating QUICK_MODE request 1522282375 [ HASH SA No KE ID ID ]
sending packet: from 10.99.1.143[500] to 10.99.1.136[500] (444 bytes)
received packet: from 10.99.1.136[500] to 10.99.1.143[500] (428 bytes)
parsed QUICK_MODE response 1522282375 [ HASH SA No KE ID ID ]
selected proposal: ESP:AES_CBC_128/HMAC_SHA1_96/MODP_2048/NO_EXT_SEQ
CHILD_SA l2tp{1} established with SPIs ca535bcf_i 042dfcdb_o and TS 10.99.1.143/32[udp/l2f] === 10.99.1.136/32[udp/l2f]
connection 'l2tp' established successfully
root@ubuntusrv:/etc# echo "c l2tp" > /var/run/xl2tpd/l2tp-control
root@ubuntusrv:/etc# ip addr
2: enp0s25: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether 00:23:5a:3f:01:22 brd ff:ff:ff:ff:ff:ff
inet 10.99.1.143/24 brd 10.99.1.255 scope global dynamic noprefixroute enp0s25
valid_lft 2408sec preferred_lft 2408sec
inet6 1234:cc:711:4699:fc47:1d64:a3a0:22f1/64 scope global temporary dynamic
valid_lft 603608sec preferred_lft 84949sec
4: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1410 qdisc fq_codel state UNKNOWN group default qlen 3
link/ppp
inet 192.168.88.200 peer 192.168.88.1/32 scope global ppp0
valid_lft forever preferred_lft forever
root@ubuntusrv:/etc# ping -c 3 192.168.88.1
PING 192.168.88.1 (192.168.88.1) 56(84) bytes of data.
64 bytes from 192.168.88.1: icmp_seq=1 ttl=64 time=0.867 ms
64 bytes from 192.168.88.1: icmp_seq=2 ttl=64 time=0.940 ms
64 bytes from 192.168.88.1: icmp_seq=3 ttl=64 time=0.950 ms
--- 192.168.88.1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 0.867/0.919/0.950/0.037 ms
Der Syslog Output zum L2TP ist dann entsprechend wenn du dir den unter /var/log/syslog einmal ansiehst (der Übersicht halber gekürzt):
pppd[3422]: rcvd [CHAP Success id=0x1 "S=335C632F51D6088B5302F449110F2461C3F3F285"]
pppd[3422]: response found in cache (entry 0)
pppd[3422]: CHAP authentication succeeded
pppd[3422]: sent [IPCP ConfReq id=0x1 <addr 0.0.0.0>]
pppd[3422]: rcvd [IPCP ConfReq id=0x1 <addr 192.168.88.1>]
pppd[3422]: sent [IPCP ConfAck id=0x1 <addr 192.168.88.1>]
pppd[3422]: rcvd [proto=0x8281] 01 01 00 04
pppd[3422]: local IP address 192.168.88.200
pppd[3422]: remote IP address 192.168.88.1
charon: 05[KNL] 192.168.88.200 appeared on ppp0
charon: 13[KNL] interface ppp0 activated
Fazit:
Das der L2TP Tunnelaufbau mit 2 verschiedenen Linux Distributionen absolut fehlerfrei rennt auf 2 unterschiedliche L2TP VPN Server zeigt eindeutig das der böse Buhmann bei dir nur dein L2TP Server selber sein kann !!
Bzw. ggf. nutzt dieser falsche Cipher Suites oder du hast ihm falsche konfiguriert oder was auch immer. Wäre aber schon komisch, denn alle gängigen L2TP Server nutzen so gut wie immer die üblichen L2TP Standard Settings dafür damit sie immer fehlerfrei mit allen meistverbreiteten L2TP Clients laufen. Siehe oben...
Du solltest dir also nochmals deinen L2TP Server und dessen Konfig sehr genau ansehen !! Dieser wird vermutlich auch weder mit dem bordeigenen Windows L2TP Client noch mit dem eines Apple Macs oder iOS iPhones oder auch Androiden zusammen laufen, richtig ? Was dann ein sicheres Indiz dafür ist das der Server Konfig technisch einen "an der Waffel" hat.
Interessant finde ich die Zeile :
In der Tat... Bedeutet das dort AES CBS, 256 SHA256 und DH Group 14 gemacht wird in der P1 !Bedeutet dann das im Strongswan IPsec Setup dann:
ike=aes256-sha256-modp2048
esp=aes256-sha256-modp2048
stehen muss !
Hast du das oben so entsprechend eingegeben ??
Du gibst zum Starten des IPsec Tunnel ja zuerst immer ein:
ipsec restart
ipsec up <conn-name>
Wichtig wäre genau DIESEN Output deines Ubuntu Clients einmal zu sehen ! Der zeigt die IPsec Client Seite und was dort ggf. schief rennt.
Leider hast du diesen zum Troubleshooting sehr wichtigen Output bis dato hier noch nie gepostet.
Genau DER würde aber zeigen was der Client nicht mag.
P.S.:
Die o.a. Konfig mit DH Group 2 hatte einen fatalen Fehler ! Es muss bei Group 2 natürlich richtig heissen "modp1024" (und nicht 1048). Sorry für diesen groben Fauxpas. Ist korrigiert !
Du scheiterst schon mit dem IPsec Tunnel in Phase 1:
Du musst mal mit den entsprechenden Parametern etwas spielen wenn das Gegenüber scheinbar kein SHA256 supportet. Z.B.:
ike=aes256-sha1-modp2048
esp=aes256-sha1-modp2048
oder
ike=aes256-sha1-modp1024
esp=aes256-sha1-modp1024
Oder mal ganz einfach mit 128 Bit
ike=aes128-sha1-modp2048
esp=aes128-sha1-modp2048
bzw. DH Group2
ike=aes256-sha1-modp1024
esp=aes256-sha1-modp1024
Spiel das mal durch !
Es darf keine P1 Fehlermeldung erscheinen und es muss am Schluss immer eine "successful" Message kommen:
CHILD_SA xyz{1} established with SPIs c4b63172_i 0a33df32_o and TS 10.99.1.141/32[udp/l2f] === 10.99.1.136/32[udp/l2f]
connection 'xyz' established successfully
Wie sieht deine aktuelle Strongswan Konfig aus ?
invalid HASH_V1 payload length, decryption failed?
Zeigt ganz klar das dein IPsec Hashing Verfahren nicht mit dem Gegenüber übereinstimmt.Du musst mal mit den entsprechenden Parametern etwas spielen wenn das Gegenüber scheinbar kein SHA256 supportet. Z.B.:
ike=aes256-sha1-modp2048
esp=aes256-sha1-modp2048
oder
ike=aes256-sha1-modp1024
esp=aes256-sha1-modp1024
Oder mal ganz einfach mit 128 Bit
ike=aes128-sha1-modp2048
esp=aes128-sha1-modp2048
bzw. DH Group2
ike=aes256-sha1-modp1024
esp=aes256-sha1-modp1024
Spiel das mal durch !
Es darf keine P1 Fehlermeldung erscheinen und es muss am Schluss immer eine "successful" Message kommen:
CHILD_SA xyz{1} established with SPIs c4b63172_i 0a33df32_o and TS 10.99.1.141/32[udp/l2f] === 10.99.1.136/32[udp/l2f]
connection 'xyz' established successfully
Wie sieht deine aktuelle Strongswan Konfig aus ?
ich hab jetzt alle von dir aufgeschriebenen Varianten durchprobiert. Keine hat funktioniert.
Na ja, das Sinnigste wäre ja einfach mal beim L2TP Server nachzusehen WELCHE Schlüssel- und Hashing Verfahren der eingestellt hat. Ist ja zielführender als alle 100 und mehr möglichen Optionen im Trial and Error Verfahren durchzuprobieren !!Vielleicht solltest du einfach mal ein Screenshot seines IPsec Setups oder die Settings hier posten. Das würde für alle das Troubleshooting erheblich verinfachen, denn dann wüsste man was der Server vorgibt !!
Nebenbei:
Einige Optionen wie "type=transport", "keyexchange=ikev1" und auch "auth=secret" sind doppelt in deiner Konfig !! Das solltest du korrigieren.
Parameter wie "keyringtries" sind überflüssig und auch deprecated wie "left=%defaultroute". Diese solltest du zwingend entfernen.
So sollte es aussehen:
conn l2tp
ikelifetime=60m
keylife=20m
rekeymargin=3m
keyexchange=ikev1
authby=secret
ike=aes128-sha1-modp2048
esp=aes128-sha1-modp2048
auto=add
type=transport
leftprotoport=17/1701
right=<server_ip>
rightprotoport=17/1701
Wie gesagt: Checke die IPsec Settings des L2TP Servers ! Der gibt die L2TP Schlüsselverfahren immer vor und passe diese auf dem Client entsprechend an in den o.a. Strongswan Setup Dateien ! Dann klappt das auch sofort.
kann den Server aktivieren und deaktivieren, aber ohne irgendwelche Einstellungen vorzunehmen.
Das ist sehr schlecht ! Was ist das denn für ein gruseliges Produkt wo man das nicht customizen kann und wo das nicht einmal sauber dokumentiert ist ?es ist etwas unbefriedigend, dass der Fehler nicht gefunden wurde.
Ja, leider. Man hätte jetzt tief mit dem Wireshark einsteigen können. Schlimm ist aber das sowas am L2TP Server nicht curomizebar ist. Von solcher HW, was auch immer das ist, sollte man immer die Finger lassen. Du siehst ja das es sogar mit einfachen 20 Euro Routern (Mikrotik) und allen anderen L2TP Server Komponenten fehlerlos klappt.Na ja...mit Wireguard klappts ja auch. Doof ist da nur das man immer einen extra Client installieren muss. Aber für dich im Linux Umfeld ja auch nicht wirklich relevant.
Vielen Dank für deine Hilfe
Immer gerne ! 😉