7
Keine IPsec Verbindung über LTE zu StrongSwan
Hallo,
ich habe eine Problem mit meinem StrongSwan 5.2.1 VPN Server. Ich möchte mich von meinem mobilen Device mit Telekom LTE Connection via IPsec IKEv2 auf meinen Server einloggen. Das klappt leider nicht. Hat das Device eine Wi-Fi Connection funktioniert die Einwahl. Vereinfacht gesagt über Wi-Fi komme ich auf den Server über LTE geht nichts ich bekomme jediglich diesen Fehler im Log.
Das hier ist meine ipsec.conf
Habt ihre eine Idee an was das liegen kann? Ich habe jetzt öfters was gelesen das dass NAT-Traversal ein Problem sein könnte, allerdings ist das ja ab StrongSwan 5 auf IKEv2 standardmäßig eingeschaltet.
Danke für eure Hilfe
ich habe eine Problem mit meinem StrongSwan 5.2.1 VPN Server. Ich möchte mich von meinem mobilen Device mit Telekom LTE Connection via IPsec IKEv2 auf meinen Server einloggen. Das klappt leider nicht. Hat das Device eine Wi-Fi Connection funktioniert die Einwahl. Vereinfacht gesagt über Wi-Fi komme ich auf den Server über LTE geht nichts ich bekomme jediglich diesen Fehler im Log.
ipsec[316]: 04[NET] received packet: from xx.xx.xx.xx[500] to xx.xx.xx.xx[500] (604 bytes)
ipsec[316]: 04[ENC] parsed IKE_SA_INIT request 0 [ SA KE No N(REDIR_SUP) N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) ]
ipsec[316]: 04[IKE] xx.xx.xx.xx is initiating an IKE_SA
ipsec[316]: 04[IKE] local host is behind NAT, sending keep alives
ipsec[316]: 04[IKE] remote host is behind NAT
ipsec[316]: 04[IKE] DH group MODP_2048 inacceptable, requesting MODP_1024
ipsec[316]: 04[ENC] generating IKE_SA_INIT response 0 [ N(INVAL_KE) ]
ipsec[316]: 04[NET] sending packet: from xx.xx.xx.xx[500] to xx.xx.xx.xx[500] (38 bytes)
ipsec[316]: 16[NET] received packet: from xx.xx.xx.xx[500] to xx.xx.xx.xx[500] (604 bytes)Das hier ist meine ipsec.conf
config setup
charondebug="ike 1, knl 1, cfg 0"
uniqueids=no
conn ikev2-vpn
auto=add
compress=no
type=tunnel
keyexchange=ikev2
fragmentation=yes
forceencaps=yes
ike=aes256-sha1-modp1024,3des-sha1-modp1024!
esp=aes256-sha1,3des-sha1!
dpdaction=clear
dpddelay=300s
rekey=no
left=%any
leftid=@xxx.com
leftcert=/etc/ipsec.d/certs/vpn-server-cert.pem
leftsendcert=always
leftsubnet=172.31.16.0/0
right=%any
rightid=%any
rightauth=eap-mschapv2
rightsourceip=172.20.10.0/24
rightdns=8.8.8.8,8.8.4.4
rightsendcert=never
eap_identity=%anyHabt ihre eine Idee an was das liegen kann? Ich habe jetzt öfters was gelesen das dass NAT-Traversal ein Problem sein könnte, allerdings ist das ja ab StrongSwan 5 auf IKEv2 standardmäßig eingeschaltet.
Danke für eure Hilfe
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 339184
Url: https://administrator.de/forum/keine-ipsec-verbindung-ueber-lte-zu-strongswan-339184.html
Ausgedruckt am: 23.12.2024 um 06:12 Uhr
7 Kommentare
Neuester Kommentar
Sehr häufig verwenden die LTE Provider wegen der anhaltenden IPv4 Adressknappheit eine private RFC 1918 IP Adressierung in den Mobilfunk LTE Netzen mit den allseits bekannten privaten IP Netzen:
https://de.wikipedia.org/wiki/Private_IP-Adresse#Adressbereiche
die im Internet nicht geroutet werden.
Der Provider macht dann zentral in seinem RZ ein sog. Carrier grade NAT also eine zentrale IP Adress Translation auf eine öffentliche IP.
Über so ein zentrales NAT kommt aber dein IPsec Protokoll generell nicht drüber.
Deshalb solltest du also zuallererst checken am LTE Gerät (Router, Smartphone, Stick etc.) was für eine Art von IP Adresse du im Provider netz dort zugewiesen bekommst.
Ist es eine RFC1918 ists aus mit dem IPsec VPN.
Siehe auch diesen Thread der das anhand der Adressproblematik und NAT im UMTS Netz beschreibt:
VPN über webn walk Stick IV nicht mehr möglich
Ggf. musst du dann beim Mobilfunkprovider in einen Business Tarif wechseln um eine öffentliche IP am LTE Endgerät zu bekommen.
Du hast übrigens noch einen DH Group Mismatch zwischen Server und Client. Der eine hat Group 2 (1024) der andere Group 14 (2048) nicht gravierend da das ausgehandelt wird nach unten. Besser ist aber immer man passt das an um Autoneg Probleme gleich zu verhindern
Nähere Infos dazu auch hier:
IPsec IKEv2 VPN für mobile Benutzer auf der pfSense oder OPNsense Firewall einrichten
https://de.wikipedia.org/wiki/Private_IP-Adresse#Adressbereiche
die im Internet nicht geroutet werden.
Der Provider macht dann zentral in seinem RZ ein sog. Carrier grade NAT also eine zentrale IP Adress Translation auf eine öffentliche IP.
Über so ein zentrales NAT kommt aber dein IPsec Protokoll generell nicht drüber.
Deshalb solltest du also zuallererst checken am LTE Gerät (Router, Smartphone, Stick etc.) was für eine Art von IP Adresse du im Provider netz dort zugewiesen bekommst.
Ist es eine RFC1918 ists aus mit dem IPsec VPN.
Siehe auch diesen Thread der das anhand der Adressproblematik und NAT im UMTS Netz beschreibt:
VPN über webn walk Stick IV nicht mehr möglich
Ggf. musst du dann beim Mobilfunkprovider in einen Business Tarif wechseln um eine öffentliche IP am LTE Endgerät zu bekommen.
Du hast übrigens noch einen DH Group Mismatch zwischen Server und Client. Der eine hat Group 2 (1024) der andere Group 14 (2048) nicht gravierend da das ausgehandelt wird nach unten. Besser ist aber immer man passt das an um Autoneg Probleme gleich zu verhindern
Nähere Infos dazu auch hier:
IPsec IKEv2 VPN für mobile Benutzer auf der pfSense oder OPNsense Firewall einrichten
Das richtig seltsame ist das ich ab und an eine Verbindung via IPsec und LTE bekomme, dann funktioniert es wieder nicht.
Was auch seltsam ist das es auf einen anderen Server via Cisco IPsec funktioniert.
Wie bekomme ich den raus ob es RFC1918 ist...?
Was auch seltsam ist das es auf einen anderen Server via Cisco IPsec funktioniert.
Wie bekomme ich den raus ob es RFC1918 ist...?
Kann ich so nicht bestätigen, bin dauerhaft per CGN unterwegs im VPN, egal ob IPSec zur Firma oder OpenVPN nach Hause. Probleme? Keene. Verbinden, grün, gut. Du kannst keine EINGEHENDEN Verbindungen aufbauen, das würde ich so unterschreiben. Ausgehende VPN-Verbindungen zum Concentrator tun da ihren Dienst. Und ja, selbst bei DS-Lite...
Im Log sieht man auch, dass sowohl lokale als auch entfernte Seite geNATtet werden.
IKEv2 hat damit keine Probleme. Bei IKEv1 war NAT-T eine nachträgliche Erweiterung, bei IKEv2 ist es Teil des Standards.
Da laut Log auch dein VPN-Server hinter einem NAT-Router steht, stellt sich die Frage, welche Ports du weitergeleitet hast.
local host is behind NAT, sending keep alives
remote host is behind NATDa laut Log auch dein VPN-Server hinter einem NAT-Router steht, stellt sich die Frage, welche Ports du weitergeleitet hast.
Im Moment sind auf dem Server noch alle Ports offen. Somit auch ganz sicher 500 und 4500
Was auch seltsam ist das es auf einen anderen Server via Cisco IPsec funktioniert.
Was dann eher gegen ein CGN und NAT spricht, denn das würde alles nicht gehen.Möglich ist aber auch das IPsec vom Provider gefiltert oder geRateLimited wird bei billigen nur Surf Accounts. Viele Provider behalten VPN Nutzung oft nur Business Accounts vor. Das müsstest du aber nachfragen beim provider.
Wie bekomme ich den raus ob es RFC1918 ist...?
Eine eher etwas peinliche Frage....Wenn es ein Router ist, dann gehst du in die Status Übersicht der Interfaces !!!
Woe bei jedem DSL oder was auch immer Router auf der Welt werden dir dort die aktuellen IP Adressen angezeigt.
Wenn du einen Stick hast im rechner ist es wie immer ipconfig oder da du ja glücklicherweise kein Winblows Knecht bist dann ifconfig.
@shadynet
egal ob IPSec zur Firma oder OpenVPN nach Hause. Probleme? Keene.
Ja richtig, allerdings redest du hier nur von der Client Seite !!! Das ist klar das das auch mit CGN oder DS-Lite usw. geht, denn der Client ist ja dann der Initiator der Verbindung. OpenVPN geht immer da es ein SSL VPN ist und IPsec funktioniert deshalb da an deinem Client NAT Traversal aktiviert ist.Es geht hier aber um den Server !! Hängt der an einem CGN Anschluss oder auch DS-Lite usw. ists aus mit VPN.
Es ist also nicht trivial ob wir hier vom Server oder Client reden !
Zitat von @aqui:
Es geht hier aber um den Server !! Hängt der an einem CGN Anschluss oder auch DS-Lite usw. ists aus mit VPN.
Es ist also nicht trivial ob wir hier vom Server oder Client reden !
Es geht hier aber um den Server !! Hängt der an einem CGN Anschluss oder auch DS-Lite usw. ists aus mit VPN.
Es ist also nicht trivial ob wir hier vom Server oder Client reden !
Wenns via Wifi geht und via LTE nicht dann hängt der Server ja eher unwahrscheinlich an CGN oder DS-Lite, denn in dem Fall würde auch Wifi kaum helfen, es sei denn, man hat auf beiden Seiten IPv6 UND DynDNS/DNS/feste IP/Glaskugel-Connect am Server. IPv6 und DynDNS ist selten, fester Präfix im Consumer-Umfeld auch, welcher Business-Vertrag bei welchem Provider da was festes hat ist mir nicht bekannt.
Im Log ist ja eh die Rede von IPv4. Das ist jetzt mal mein Blick in die Glaskugel und über den Tellerrand.
