VPN auf 5G Fritzbox ohne IPv6
Hallo Zusammen,
ich habe hier eine Fritzbox 6850 5G über die Telekom am laufen.
Das hier vorhandene Netzwerk soll über einen VPN von außen erreichbar sein.
Die Standard-Vorgehensweise mit Fritzbox und Wireguard SSL VPN funktioniert nicht, da nur IPv4 und eingehende Verbindung über Mobilfunk wohl Grundsätzlich abgelehnt werden.
Gibt es hier noch andere Alternativen / Lösungen um die VPN Verbindung umzusetzen?
Darf Freeware oder auch Bezahldienste sein?
Vielen Dank vorab!
derinderinderin
ich habe hier eine Fritzbox 6850 5G über die Telekom am laufen.
Das hier vorhandene Netzwerk soll über einen VPN von außen erreichbar sein.
Die Standard-Vorgehensweise mit Fritzbox und Wireguard SSL VPN funktioniert nicht, da nur IPv4 und eingehende Verbindung über Mobilfunk wohl Grundsätzlich abgelehnt werden.
Gibt es hier noch andere Alternativen / Lösungen um die VPN Verbindung umzusetzen?
Darf Freeware oder auch Bezahldienste sein?
Vielen Dank vorab!
derinderinderin
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 668679
Url: https://administrator.de/forum/vpn-auf-5g-fritzbox-ohne-ipv6-668679.html
Ausgedruckt am: 23.12.2024 um 13:12 Uhr
28 Kommentare
Neuester Kommentar
Moin,
Mit dem aktuellsten FritzOS 7.59 fur die o.g. Fritte sollte das eigentlich auch über ipV6 funktionieren. Welche Fehlermeldungen kommen denn beim Client?
Ansonsten einen günstigen vServer irgendwo mieten und den als Zwischenstation nehmen, Inden Du sowohl von der Fritzbox als auch vom Client eine Verbindung dorthin aufbauen.
lks
Mit dem aktuellsten FritzOS 7.59 fur die o.g. Fritte sollte das eigentlich auch über ipV6 funktionieren. Welche Fehlermeldungen kommen denn beim Client?
Ansonsten einen günstigen vServer irgendwo mieten und den als Zwischenstation nehmen, Inden Du sowohl von der Fritzbox als auch vom Client eine Verbindung dorthin aufbauen.
lks
Zitat von @derinderinderin:
Allerdings ist jetzt noch die myfritz-Adresse, welche in den WireGuard Configs drin ist noch auf die IPv4 Adresse gemappt. bzw. diese spuckt der bei nem Ping aus.
Allerdings ist jetzt noch die myfritz-Adresse, welche in den WireGuard Configs drin ist noch auf die IPv4 Adresse gemappt. bzw. diese spuckt der bei nem Ping aus.
Für die Abendauflösung nimmt man nslookup, nicht Ping. Ping nimmt den Wert aus dem Cache.
Einfach Mal unter myfritz.net im myfritz-Konto schauen, ob beide Adressen Ei getragen sibd.
Wie bekomme ich diese erneuert? oder dauert das einfach eine weile?
Normalerweise sollte das Recht schnell gehen., aber warten hilft manchmal
lks
Gibt es hier noch andere Alternativen / Lösungen um die VPN Verbindung umzusetzen?
Ja, wie immer über einen vServer als sog. Jumphost. Funktioniert auch mit Wireguard. IKEv2 hat aber den großen Vorteil das man nicht überflüssigerweise mit VPN Client Software rumfrickeln muss sondern immer die so oder so vorhandenen onboard VPN Clients in allen Geräten sinnvoll nutzt.
Das korrekte Kommando was der Kollege @Lochkartenstanzer oben meint ist nslookup oder noch besser host.
Zitat von @aqui:
Das korrekte Kommando was der Kollege @Lochkartenstanzer oben meint ist nslookup oder noch besser host.
Das korrekte Kommando was der Kollege @Lochkartenstanzer oben meint ist nslookup oder noch besser host.
Tippfehler korrigiert. Unter Windows funktioniert iirc kein host. Daher habe ich nur nslookup erwähnt. Unter BSD/linux nehme ich vorzugsweise dig.
lks
Seit wann gibt es feste IPv6 Adressen im Mobilfunknetz?? 🤔
Merkzettel: VPN Installation mit Wireguard
Kapitel IPv6 Client und Fritzbox Besonderheiten.
Ohne das du deine Client Konfig Datei hier einmal (anonymisiert) postest kann man nur Kristallkugeln...
So oder so wird das aber sehr wahrscheinlich immer scheitern, weil Mobilfunk Provider in der Regel bei einfachen Consumer Verträgen keine Verbindung von außen auf ihre Mobilfunknetze erlauben. Egal ob v4 (scheitert schon am CGN) oder v6. Du kommst also um einen Jumphost nicht drumrum oder musst auf einen Business Vertrag wechseln sofern dein Provider sowas überhaupt anbietet.
Merkzettel: VPN Installation mit Wireguard
Kapitel IPv6 Client und Fritzbox Besonderheiten.
Ohne das du deine Client Konfig Datei hier einmal (anonymisiert) postest kann man nur Kristallkugeln...
So oder so wird das aber sehr wahrscheinlich immer scheitern, weil Mobilfunk Provider in der Regel bei einfachen Consumer Verträgen keine Verbindung von außen auf ihre Mobilfunknetze erlauben. Egal ob v4 (scheitert schon am CGN) oder v6. Du kommst also um einen Jumphost nicht drumrum oder musst auf einen Business Vertrag wechseln sofern dein Provider sowas überhaupt anbietet.
Für private Zwecke würde ich https://dynv6.com/ verwenden.
Spart man sich Zeit bei dynamischen IP Adressen, kostet nix und funktioniert recht gut mit den Fritten.
Habs seit Jahren zu Hause im Einsatz.
Spart man sich Zeit bei dynamischen IP Adressen, kostet nix und funktioniert recht gut mit den Fritten.
Habs seit Jahren zu Hause im Einsatz.
Wenn es das denn nun war bitte deinen Thread dann auch als erledigt markieren!
Wie kann ich einen Beitrag als gelöst markieren?
Wie kann ich einen Beitrag als gelöst markieren?
dass die Telekom in dem Vertrag eingehendes VPN nicht durchlässt. Auch nachdem ich IPV6 Adressen habe.
Das macht, wie oben schon mehrfach gesagt, kein Mobilfunkprovider bei einfachen Consumer Verträgen. Eingehende Verbindungen auf Ziel IP Adressen im Mobilfunknetz werden in der Regel generell geblockt.Die Lösung mit dem Jump-Host ist mal nicht grad umgesetzt.
Max. eine Stunde, dann ist das Teil online... Wo ist dein wirkliches Problem?! Gibt es Empfehlungen welche vServer (Anbieter) man nimmt
Nee, ist völlig Wumpe. Das kannst du nach Geschmack und Geldbeutel entscheiden. Könnte man auf dem StrongSwan auch VPN Server für zwei verschiedene Netze erstellen?
Na klar! Das ist doch genau der Witz der Sache das man da auch mehrere Netze /Router anbinden kann. Auch andere VPN Protokolle. So kannst du dir quasi einen universellen VPN Server stricken der alles mit allem verbinden kann. Also...einfach mal loslegen und machen! 😉Jetzt sagt mir nur die WIN 11 VPN Verbindung "Fehler in Richtlinienübereinstimmung".
Zertifikate hast du für die Server IP und ggf. DNS Hostnamen erstellt und auch entsprechend auf den Win 11 Rechner übertragen?über swanctl -T auf dem Server sieht man nichts eingehen.
Oha, das darf natürlich nicht sein. Das bedeutet das schon überhaupt gar kein VPN Traffic auf deinem vServer ankommt. Ist am vServer ggf. noch eine Firewall aktiv die solchen Traffic blockt?!Hast du dort als Ziel IP des VPN Clients einmal die nackte IP Adresse des Servers eingetragen?
Wenn ja was sagt ein tcpdump port 500 (apt install tcpdump)Kannst du damit eingehende UDP 500 (IKE) Pakete des VPN Clients sehen?
Da du leider keinerlei zielführende Infos hier gepostet hast wird das eine wilde Raterei. Das Allerwichtigste ist erstmal das du hier deine Strongswan Konfig Datei einmal anonymisierst postest. Idealerweise in Code Tags. Das dient dazu zu checken ob du generell ggf. einen Fehler im Setup gemacht hast.
Sehr hilfreich wäre auch der Output von swanctl -q um ggf. Fehlermeldungen dort zu sehen. Auch ob ein Neistart des Strongswan Dienstes mit systemctl restart strongswan fehlerlos durchläuft. systemctl status strongswan sollte den Dienst als Aktiv anzeigen.
den Registry Eintrag von hier:
Das ist Blödsinn und sollte man erstmal NICHT machen!! Es ist völlig unnötig und verkompliziert das Troubleshooting nur. Belasse alles out of the box. Optimieren macht man logischerweise immer nur NACHDEM alles rennt wie es soll und nicht vorher.Wichtig ist jetzt erstmal herauszubekommen warum swanctl -T oder tcpdump keine eingehenden VPN Daten vom Client anzeigt?!
OK, das sieht soweit schon mal ganz gut aus. Sowas wie ".1111" als Hostadresse gibt es natürlich nicht was du auch selber weisst und wohl die Folge eines nervösen Tippfingers ist?!!
Einige Dinge sind aber auffällig und solltest du unbedingt korrigieren:
Der Rest ist soweit korrekt.
Den Fehler mit der lokalen Adresse und der falschen IP bzw. ID musst du zwingend korrigieren. Deshalb scheitert die Verbindung und das ist auch der Grund weil swanctl -T keinen Output zeigt weil durch die falsche ID der VPN Tunnel sofort abgebrochen wird!!
Wenn ein Fehler im Zertifikat sein sollte würde der -T Trace das auch zeigen. Eine alternative Methode mit OpenSSL findet man u.a. hier.
Hast du alles richtig gemacht sollte der Trace sowas wie das Folgende zeigen:
Einige Dinge sind aber auffällig und solltest du unbedingt korrigieren:
- Die "Proposals" sind unvollständig und haben am Ende ein falsches ">" was normal zu einem Fehler führt.
- local_addrs = 192.168.180.1 ist falsch, denn dort darf natürlich KEINE private RFC1918 IP stehen. Hier muss die öffentliche, externe IP des vServers stehen z.B. 212.1.2.3. (Dein 111.111.111.111) Die ist hier mit "local_addrs" gemeint! Sie darf damit auch keinesfalls eine Adresse aus dem VPN Client IPv4 Pool sein! Dieser gravierende Fehler führt zum Scheitern deiner VPN Verbindung. Achte darauf das das .180.0er VPN Client Pool IP Netz einzigartig bei dir ist! Dieses Netz darf nirgendwo sonst verwendet werden! (Siehe dazu auch hier zum Thema VPN Adressdesign).
- Bei der lokalen ID wenn du dort statt eines FQDNs die feste vServer IP angibst (siehe auch oben, entspricht deiner "111.111.111.111") sollte die Syntax korrekt z.B. id = ipv4:212.1.2.3 lauten. (Siehe auch hier zu den Identity types)
connections {
ikev2-mobile-defaults {
unique = replace
version = 2
proposals = aes256-sha512-modp2048,aes256-sha256-ecp256,aes256-sha256-modp2048,aes256-sha256-modp1024
send_cert = always
pools = pool-ipv4
local_addrs = 212.1.2.3
remote_addrs = 0.0.0.0/0,::/0
local {
auth = pubkey
certs = server-cert.pem
id = ipv4:212.1.2.3
}
Der Rest ist soweit korrekt.
Den Fehler mit der lokalen Adresse und der falschen IP bzw. ID musst du zwingend korrigieren. Deshalb scheitert die Verbindung und das ist auch der Grund weil swanctl -T keinen Output zeigt weil durch die falsche ID der VPN Tunnel sofort abgebrochen wird!!
Wenn ein Fehler im Zertifikat sein sollte würde der -T Trace das auch zeigen. Eine alternative Methode mit OpenSSL findet man u.a. hier.
Hast du alles richtig gemacht sollte der Trace sowas wie das Folgende zeigen:
root@vserver:/home/admin# swanctl -T
06[NET] received packet: from 91.3.4.5[513] to 212.1.2.3[500] (356 bytes)
06[ENC] parsed IKE_SA_INIT request 0 [ SA KE No N(REDIR_SUP) N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) ]
06[IKE] 91.3.4.5 is initiating an IKE_SA
06[CFG] selected proposal: IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/ECP_256
06[IKE] remote host is behind NAT
06[IKE] sending cert request for "CN=internal-ca, C=DE, ST=M, L=M, O=Private, OU=Homevpn"
...
15[IKE] assigning virtual IP 192.168.180.2 to peer 'user2'
Der durch den Fehler zurückgegebene Ursachencode lautet: 13868.
Das weist auf einen IPsec Security Policy Mismatch hin. Bedeutet das das was der VPN Client an Krypto Policies fordert der Server nicht liefern kann oder vice versa und die automatische Aushandlung der Policies damit scheitert.
https://directaccess.richardhicks.com/2023/02/12/always-on-vpn-error-138 ....
Ist sicher eine Folge deiner Manipulation der Registry.
Müsste man jetzt nochmal genau checken welche Policies die Registry damit dann jetzt auf deinem Client erfordert. Ein Get-VpnServerIPsecConfiguration in der PS würde das klären so das man das auf dem Server im Strongswan Setup ergänzen kann.
"swanctl -T" zeigt:
Nein, das ist leider KEIN Output von swanctl -T sondern eine Kombination von systemctl status strongswan und swanctl -q aber leider keinerlei hilfreicher Output von einem Trace mit swanctl -TDen erreichst du nur wenn du den Trace mit swanctl -T auf dem Server startest und DANACH einen Verbindungsversuch mit dem VPN Client startest. Dann sollte sowas wie das hier zu sehen sein
root@vserver:/home/admin# swanctl -T
06[NET] received packet: from 91.3.4.5[513] to 212.1.2.3[500] (356 bytes)
06[ENC] parsed IKE_SA_INIT request 0 [ SA KE No N(REDIR_SUP) N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) ]
06[IKE] 91.3.4.5 is initiating an IKE_SA
06[CFG] selected proposal: IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/ECP_256
06[IKE] remote host is behind NAT
06[IKE] sending cert request for "CN=internal-ca, C=DE, ST=M, L=M, O=Private, OU=Homevpn"
...
15[IKE] assigning virtual IP 192.168.180.2 to peer 'user2'
Mit "selected proposal:" kannst du die o.g. mit dem VPN Client ausgehandelten Krypto Proposals sehen.
Dein weiterer Fehler ist das du einen völlig falschen Usernamen verwendest!!
Du hast oben definiert:
eap-2 {
id = user2
secret = "Passwort2"
}
Das das dann in die Hose geht ist auch klar. Viel zu korrigieren mal wieder...
OK, sha384 und DH Group ecp384 bietet der Server mit der Tutorial Konfig nicht an. Verwunderlich das das ausgegeben wird, denn Win11 verwendet gleiche IKEv2 Proposals wie Win 10. 🤔
Wenn das das Einzige ist was diese (Powershell) Verbindung erfordert musst du die Proposals um den Eintrag aes256-sha384-ecp384 erweitern ansonsten scheitert sofort die Proposal Negotiation.
Denke daran das du bei jeder Änderung der Konfig Datei ein swanctl -q oder systemctl restart strongswan ausführst um diese zu aktivieren!
Interessant wäre wenn du parallel auch einmal eine fritte6850.conf Datei erzeugst mit deiner 6850 Fritzbox Konfig. Dann könntest du parallel mal checken wie sich die FB mit der VPN Connectivity auf dem vServer schlägt.
Die folgende Konfig geht davon aus das du das Loopback Interface des vServers mit
zusätzlich auf 192.168.181.1 gesetzt hast so das du in den IPsec Phase 2 Settings beide Netze .180.0/24 = VPN Clientnetz und .181.0/24 = Keepalive Netz bzw. IP mit einer /23 Maske (255.255.254.0) per VPN bedienen kannst!
⚠️ Die Wahl des 192.168.180.0/24er Netzes fürs Client VPN war insgesamt wenig intelligent, denn genau dieses Netzwerk wird intern von AVM in den Fritzboxen verwendet und fällt damit in einer Netzwerkkonfiguration wie deiner grundsätzlich aus bzw. ist im Fritzbox Umfeld dann generell Tabu!! Als Fritzbox Knecht sollte man solche Basics eigentlich wissen.
http://help.avm.de/fritzbox.php?oem=1und1&hardware=94&language= ...
Zitat: "Das gesamte IP-Netzwerk 192.168.180.0 ist für interne Zwecke reserviert. Das heißt, die IP-Adressen 192.168.180.1 bis 192.168.180.255 sind nicht verfügbar!"
Deshalb gilt das Folgende hier nur für eine Blaupause und man kann dir nur dringenst raten ein anderes, nicht benutztes IP Netz für VPN Clients und Keepalive zu verwenden wenn du nicht noch mehr Frust erleben willst!!! Der RFC 1918 IP Adressbereich hat ja genug freie Spielwiesen dafür. (Siehe zu der Thematik auch hier!)
Deine in deine 6850 FB zu importierende Datei sieht dann so aus:
LAN IP, Loopback Netz und IP des vServers und Passwörter musst du natürlich anpassen auf deine Belange! Obiges scheitert vermutlich eh wegen der falschen .180.0er Wahl für die VPN Client IPs.
Man kann das VPN auch ganz einfach per KlickiBunti über das GUI der Fritzbox konfigurieren allerdings nutzt sie dann den sog. Agressive Mode im Default statt des Main Modes der oben konfiguriert ist (mode = phase1_mode_idp;).
Der Agressive Mode ist im Default Setting des Strongswan Servers deaktiviert. (Siehe zu der Thematik hier) Den Main Mode kann man nur über eine zu importierende VPN Setup Datei wie oben in der Fritte setzen.
Oder eben den Agressive Mode auch im Strongswan erlauben dann klappts auch mit der Fritte im Agressive Mode.
Wenn das das Einzige ist was diese (Powershell) Verbindung erfordert musst du die Proposals um den Eintrag aes256-sha384-ecp384 erweitern ansonsten scheitert sofort die Proposal Negotiation.
Denke daran das du bei jeder Änderung der Konfig Datei ein swanctl -q oder systemctl restart strongswan ausführst um diese zu aktivieren!
Interessant wäre wenn du parallel auch einmal eine fritte6850.conf Datei erzeugst mit deiner 6850 Fritzbox Konfig. Dann könntest du parallel mal checken wie sich die FB mit der VPN Connectivity auf dem vServer schlägt.
Die folgende Konfig geht davon aus das du das Loopback Interface des vServers mit
# The loopback network interface
auto lo
iface lo inet loopback
iface lo inet static
address 192.168.181.1
netmask 255.255.255.255
⚠️ Die Wahl des 192.168.180.0/24er Netzes fürs Client VPN war insgesamt wenig intelligent, denn genau dieses Netzwerk wird intern von AVM in den Fritzboxen verwendet und fällt damit in einer Netzwerkkonfiguration wie deiner grundsätzlich aus bzw. ist im Fritzbox Umfeld dann generell Tabu!! Als Fritzbox Knecht sollte man solche Basics eigentlich wissen.
http://help.avm.de/fritzbox.php?oem=1und1&hardware=94&language= ...
Zitat: "Das gesamte IP-Netzwerk 192.168.180.0 ist für interne Zwecke reserviert. Das heißt, die IP-Adressen 192.168.180.1 bis 192.168.180.255 sind nicht verfügbar!"
Deshalb gilt das Folgende hier nur für eine Blaupause und man kann dir nur dringenst raten ein anderes, nicht benutztes IP Netz für VPN Clients und Keepalive zu verwenden wenn du nicht noch mehr Frust erleben willst!!! Der RFC 1918 IP Adressbereich hat ja genug freie Spielwiesen dafür. (Siehe zu der Thematik auch hier!)
connections {
fritzbox {
local_addrs = 212.212.212.212
remote_addrs = 0.0.0.0/0
local {
auth = psk
id = 212.212.212.212
}
remote {
auth = psk
id = keyid:6850@fritz.box
}
children {
net {
local_ts = 192.168.180.0/23
remote_ts = 192.168.178.0/24
esp_proposals = aes256-sha512-modp2048,aes256-sha256-modp2048,aes256-sha1-modp1024
}
}
version = 1
proposals = aes256-sha512-modp2048,aes256-sha512-modp1024
}
secrets {
ike-1 {
id = keyid:6850@fritz.box
secret = "test1234"
}
}
Deine in deine 6850 FB zu importierende Datei sieht dann so aus:
vpncfg {
connections {
enabled = yes;
editable = no;
conn_type = conntype_lan;
name = "StrongSwan";
always_renew = yes;
reject_not_encrypted = no;
dont_filter_netbios = yes;
localip = 0.0.0.0;
local_virtualip = 0.0.0.0;
remoteip = 212.212.212.212;
remote_virtualip = 0.0.0.0;
keepalive_ip = 192.168.181.1;
localid {
key_id = "6850@fritz.box";
}
remoteid {
ipaddr = 212.212.212.212;
}
mode = phase1_mode_idp;
phase1ss = "LT8h/all/all/all";
keytype = connkeytype_pre_shared;
key = "test1234";
cert_do_server_auth = no;
use_nat_t = yes;
use_xauth = no;
use_cfgmode = no;
phase2localid {
ipnet {
ipaddr = 192.168.178.0;
mask = 255.255.255.0;
}
}
phase2remoteid {
ipnet {
ipaddr = 192.168.180.0;
mask = 255.255.254.0;
}
}
phase2ss = "esp-all-all/ah-none/comp-all/pfs";
accesslist = "permit ip any 192.168.180.0 255.255.254.0";
}
ike_forward_rules = "udp 0.0.0.0:500 0.0.0.0:500",
"udp 0.0.0.0:4500 0.0.0.0:4500";
}
Man kann das VPN auch ganz einfach per KlickiBunti über das GUI der Fritzbox konfigurieren allerdings nutzt sie dann den sog. Agressive Mode im Default statt des Main Modes der oben konfiguriert ist (mode = phase1_mode_idp;).
Der Agressive Mode ist im Default Setting des Strongswan Servers deaktiviert. (Siehe zu der Thematik hier) Den Main Mode kann man nur über eine zu importierende VPN Setup Datei wie oben in der Fritte setzen.
Oder eben den Agressive Mode auch im Strongswan erlauben dann klappts auch mit der Fritte im Agressive Mode.
Beim vServer ist noch kein SSL Zertifikat hinterlegt. Hat das eine Relevanz?
Nein! Da SSL hier keinerlei Rolle spielt ist das komplett irrelevant.
Wenn es das denn nun war bitte deinen Thread hier dann auch als erledigt schliessen!
Wie kann ich einen Beitrag als gelöst markieren?
Wie kann ich einen Beitrag als gelöst markieren?