momai
Goto Top

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.


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=%any

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

Content-Key: 339184

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

Ausgedruckt am: 19.03.2024 um 14:03 Uhr

Mitglied: aqui
aqui 29.05.2017 aktualisiert um 18:49:45 Uhr
Goto Top
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 face-wink
Nähere Infos dazu auch hier:
IPsec IKEv2 VPN für mobile Benutzer auf der pfSense oder OPNsense Firewall einrichten
Mitglied: momai
momai 29.05.2017 um 19:26:14 Uhr
Goto Top
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...?
Mitglied: shadynet
shadynet 29.05.2017 um 21:52:28 Uhr
Goto Top
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...
Mitglied: tikayevent
tikayevent 29.05.2017 um 22:24:31 Uhr
Goto Top
Im Log sieht man auch, dass sowohl lokale als auch entfernte Seite geNATtet werden.
local host is behind NAT, sending keep alives
remote host is behind NAT
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.
Mitglied: momai
momai 29.05.2017 um 22:34:25 Uhr
Goto Top
Im Moment sind auf dem Server noch alle Ports offen. Somit auch ganz sicher 500 und 4500
Mitglied: aqui
aqui 30.05.2017 aktualisiert um 10:30:06 Uhr
Goto Top
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 !
Mitglied: shadynet
shadynet 30.05.2017 um 19:58:56 Uhr
Goto Top
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 !

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.