[Problem] Fritz!Box 7390 - VPN-Problem nach Update auf 6.04

madison42 · 12 Aug 2014

Hallo,

auf meiner 7390 sind zwei VPN-Verbindungen konfiguriert: eine ausgehende Verbindung 7390 -> VPN -> Linux-Server (strongswan), eine eingehende Verbindung iPhone -> VPN -> 7390. Mit 6.03 funktioniert das prima. Ich kann aus meinem Heimnetzwerk direkt auf das interne Netz im Linux-Server zugreifen (also Laptop -> 7390 -> VPN -> Linux-Server).
Mit 6.04 funktioniert die Verbindung Heimnetzwerk -> VPN -> Linux-Server nicht mehr. Kein Ping, keine TCP-Verbindung, nix. Dabei wird der Status der VPN-Verbindung im Fritz!Box-Menü als "hergestellt" angezeigt.
Wenn ich mich mit dem iPhone von unterwegs mit der 7390 verbinde, funktioniert die Verbindung mit dem Linux-Server interessanterweise auch unter 6.04! (Also iPhone -> VPN -> 7390 -> VPN -> Linux-Server).

Der Fehler dürfte in einer Firewall-Konfiguration in der 7390 liegen. Nur wo genau? Anbei mal die VPN-Konfiguration für die Verbindung 7390 -> VPN -> Linux-Server.

Adress-Bereiche: 192.168.64.0/23 = Heimnetz, 192.168.135.0/24 = internes Netz auf dem Linux-Server.

Code:

vpncfg {
        connections {
                enabled = yes;
                conn_type = conntype_lan;
                name = "linux.org";
                always_renew = no;
                reject_not_encrypted = no;
                dont_filter_netbios = yes;
                localip = 0.0.0.0;
                local_virtualip = 0.0.0.0;
                remoteip = 0.0.0.0;
                remote_virtualip = 0.0.0.0;
                remotehostname = "linux.org";
                localid {
                        fqdn = "home.dyndns.org";
                }
                remoteid {
                        fqdn = "linux.org";
                }
                mode = phase1_mode_idp;
                phase1ss = "all/all/all";
                keytype = connkeytype_pre_shared;
                key = "abcd1234";
                cert_do_server_auth = no;
                use_nat_t = yes;
                use_xauth = no;
                use_cfgmode = no;
                phase2localid {
                        ipnet {
                                ipaddr = 192.168.64.0;
                                mask = 255.255.254.0;
                        }
                }
                phase2remoteid {
                        ipnet {
                                ipaddr = 192.168.135.0;
                                mask = 255.255.255.0;
                        }
                }
                phase2ss = "esp-all-all/ah-none/comp-all/pfs";
                accesslist = "permit ip any 192.168.135.0 255.255.255.0";
        }

trendchiller · 20 Aug 2014

Fritz!Box 7390 VPN-Probleme ab Fritz!OS > 6.03

Moinmoin !
Seit Fritz!OS > Version 6.03 gibt es in verschiedenen Konstellationen VPN (IPSec) Probleme.
Die Phase 1 wird aufgebaut, aber Traffic fliesst nicht durch den Tunnel.
Die "grüne Lampe" in der Fritz!Box-GUI ist aktiv.

Hat jemand diese Probleme erfolgreich behoben oder hat einen Wordaround dafür ?

Ich habe dieses Problem mit einem LAN-LAN-Tunnel Fritz!Box 7390 <-> pfSense 2.1.4.

egal, welche Konfigurationseinstellungen auf beiden Seiten geändert werden, es steht immer nur Phase 1, Phase 2 kommt nicht / kein Traffic.

informerex · 20 Aug 2014

Ich hatte die Tage ein Problem mit VPN und Fritz!app Fon Labor - FW 6.04
VPN bestand jedoch konnte die app keine Verbindung aufbauen, welche jedoch vorher im WLAN fehlerfrei funktionierte

Durch einen anderen Thread wurde ich aufmerksam auf den Teredo-Filter, dort Stand deaktivieren und danach wieder aktivieren, da evtl ein Bug vorliegt.
Und tatsächlich nach deaktivieren - übernehmen - aktivieren - übernehmen, funktionierte es sofort.

Vielleicht könntest das mal probieren

trendchiller · 20 Aug 2014

habe ich mal getestet, mal sehen, ob das zur Stabilität beiträgt.
Ich habe auf der pfSense mal (wieder) prefer old SAs aktiviert.
Die neuen VPN-Parameter habe ich mal aufder IPSec.cfg ausgelesen und meine Konfiguration mal auf Phase 1: AES256, SHA1, DH15 und Phase 2: AES256, SHA1, PFS15 und 8 Std. IKE-Lifetime angepasst.
Somit scheint es bisher stabil zu laufen.
[Beitrag 2:]
Und wieder wird nur die Phase 1 nach Zwangstrennung aufgebaut...
:-(
[Beitrag 3:]
Hi !
Ich habe gerade deinen Beitrag gelesen und habe ein ähnliches Problem.
Bis dato gibt es wohl noch keine Lösung, außer ein downgrade auf die 6.03.
http://www.ip-phone-forum.de/showpost.php?p=2029372

informerex · 21 Aug 2014

probier mal http://fritz.box/internet/trafficappl.lua - Teredo-Filter deaktivieren - übernehmen - Teredo-Filter aktiv - übernehmen

trendchiller · 21 Aug 2014

Hatte ich schon getan.
Nach Zwangstrennung mit IP Wechsel besteht das Problem wieder.
Leider.

informerex · 21 Aug 2014

dann lass doch mal deaktiviert und probier bitte nochmals

Keeper · 21 Aug 2014

Wer baut denn konkret die Verbindung zw. FB und Linux-Server auf? Verbindet sich die FB mit dem Linux-Server oder umgekehrt? Welche Einstellungen hast du auf dem Linux-Server hinsichtlich der Proposals gewählt? Hast du IPComp aktiviert? (compress=yes). Habe aktuell nen strongSwan mit der aktuellen Beta von der 7360 laufen (also 6.10 irgendwas) - wollte ich eh noch posten, weil ich da auch lange Probleme hatte. Ich such die Sachen mal raus...
Ahso, und was sagt denn strongSwan zu der Nummer? Also was liefert denn ein "ipsec statusall"?

trendchiller · 22 Aug 2014

@informerex:
Habe ich probiert, hat aber leider nichts gebracht.
[Beitrag 2:]
@keeper:
Es handelt sich auf der Gegenseite nicht um ein Linux System, sondern um ein Unix. Zum Einsatz kommt der racoon-daemon. Auch dort wird ein Phase 1 Aufbau bestätigt.
Scheinbar wird Phase2 nicht aufgebaut.
Es handelt sich bei der Konfiguration um einen LAN2LAN Tunnel, es können also beide Seiten den Tunnel aufbauen.
IPComp ist aktiviert. Ich habe noch keine Direktive gefunden, bei der man das komplett ausschalten kann, die mit AES arbeitet.

Keeper · 22 Aug 2014

Mhm, mit racoon kenne ich mich so gar nicht aus. Aber dort müsste es doch ebenfalls ein Log geben, kannst du das vielleicht mal besorgen? Da müsste ja drin stehen, wo es an der Phase2 scheitert. Alternativ schau mal in den SupportDaten der FB, dort findest du das LOG vom avmike (ike.log oder so), evtl. steht da auch etwas hilfreiches drin.

PeterPawn · 22 Aug 2014

madison42 schrieb:
Adress-Bereiche: 192.168.64.0/23 = Heimnetz, 192.168.135.0/24 = internes Netz auf dem Linux-Server.

Eigentlich sollte es natürlich auch mit einem /23-Netz reibungslos funktionieren. Aber auch an anderen Stellen wird /24 "angenommen" und man hat (ich z.B. mit /28) einige - auf den ersten Blick unerklärliche - Probleme. Ich habe auch gelesen, daß es mit 06.03 so funktioniert hat ... also wurde wohl seitens AVM irgendwo geändert.

Ich würde einen Testlauf mit einer /24-Maske empfehlen, nur um zu sehen, ob das Problem vielleicht doch damit zusammenhängt (sind ja nur 2 Änderungen, eine auf jeder Seite). Wo es dann genau klemmt, kann man dann immer noch ermitteln und - im Rahmen der Möglichkeiten - beseitigen oder einen Workaround suchen.

Das AVM-VPN richtet auch keine expliziten Routen für eine VPN-Verbindung ein und verläßt sich immer darauf, daß die Route schon irgendwie über "dev dsl" gehen wird, wo dann der Verkehr für die IPSec-Adressen ausgeleitet wird (wohl ähnlich xfrm, genauer Mechnismus aber m.W. unbekannt).
Die aktivierten IPSec-Netze stehen in /var/vpnroutes, damit mindestens mal der FTP-Server daraus ableiten kann, ob ein Zugriff lokal oder "internet" ist, ob da auch IPSec ja/nein für ein Paket entschieden wird, müßte man mal testen.
Ansonsten findet man die aktivierten Verbindungen (wenn nicht über ctlmgr) auch mit "cat /proc/kdsld/dsliface/internet/ipsec/*".

Wenn Du also aus irgendeinem Grund noch eine 192.168.134.0/23-Route (oder noch kleinere Maske) ins LAN oder woanders hin haben solltest, landet der ganze Traffic vielleicht gar nicht auf "dev dsl".

trendchiller schrieb:
IPComp ist aktiviert. Ich habe noch keine Direktive gefunden, bei der man das komplett ausschalten kann, die mit AES arbeitet.

Auf der FRITZ!Box-Seite ohne Modifikation der ipsec.cfg auch nicht vorhanden.

Hast Du denn die andere Seite unter Kontrolle und kannst es im racoon ausschalten ?
Gib doch mal Deine vpn.cfg (nur phase1ss/phase2ss) der FRITZ!Box und die racoon.conf (remote section, ggf. die passende sainfo section auch noch) zum besten ...

racoon-Debugging mit einfachem "log [debug|debug2]"-Statement zu aktivieren (sieht zwar für den geübten Linux-Admin aus wie facility/level für syslog, meint aber wirklich den Log-Umfang).

Keeper · 22 Aug 2014

PeterPawn schrieb:
Auf der FRITZ!Box-Seite ohne Modifikation der ipsec.cfg auch nicht vorhanden.

Ja, die Fritzbox hat IPComp immer an, d.h. aber ja nicht, dass es verwendet werden muss. Sie sendet ja auch AES Proposals, bei denen kein IPComp verwendet wird. Ich kam da deswegen drauf, weil strongSwan Probleme mit den IPComp Proposal hatte (weil der Threadersteller ja strongSwan nutzt). Kann natürlich sein, dass das bei racoon kein Problem darstellt, aber dafür kenne ich den halt nicht.

PeterPawn · 22 Aug 2014

Keeper schrieb:
Sie sendet ja auch AES Proposals, bei denen kein IPComp verwendet wird.

Und sie akzeptiert sogar Verbindungen ohne Kompression, wenn man sie dazu auffordert.

Ich hatte das verstanden, deshalb auch meine Frage an trendchiller nach der Möglichkeit der Deaktivierung auf der racoon-Seite. Offenbar war auch ihm die Kompression ja so "verdächtig", daß er nach einer Möglichkeit sucht, sie auszuschalten.

Beim Linux-Kernel und IPSec-Routing über policy/xfrm ist es auch einfacher, die erst einmal ohne Kompression einzurichten, da das ja immer noch eine zusätzliche Transformation erfordert und dann für den resultierenden Aufbau des Pakets es auch einen Unterschied macht, ob zuerst verschlüsselt und dann komprimiert wird oder umgekehrt. Das muß dann am Ziel wieder in exakt der umgekehrten Folge passieren, sonst kommt i.d.R. Müll heraus.

Daher ist die Anzeige von "ip~~sec~~ xfrm" bei einer Verbindung mit Kompression normalerweise auch eine andere, als bei einer ohne.

EDIT: Ich meinte natürlich "ip xfrm" aus dem iproute2-Paket.

trendchiller · 22 Aug 2014

Die Kompression hatte ich auch schon im Blick... das ist richtig...
Aber es scheint so, als könnte ich diese auf der Gegenseite NICHT deaktivieren :-(
Da muss ich noch etwas forschen.

die Fritz!Box-cfg:

Code:

vpncfg {
        connections {
                enabled = yes;
                conn_type = conntype_lan;
                name = "gw.domain.de";
                always_renew = no;
                reject_not_encrypted = no;
                dont_filter_netbios = yes;
                localip = 0.0.0.0;
                local_virtualip = 0.0.0.0;
                remoteip = 0.0.0.0;
                remote_virtualip = 0.0.0.0;
                remotehostname = "gw.domain.de";
                localid {
                        fqdn = "gw.andereseite.de";
                }
                remoteid {
                        fqdn = "gw.domain.de";
                }
                mode = phase1_mode_aggressive;
                phase1ss = "dh15/aes/sha";
                keytype = connkeytype_pre_shared;
                key = "geheimerpresharedkey";
                cert_do_server_auth = no;
                use_nat_t = yes;
                use_xauth = no;
                use_cfgmode = no;
                phase2localid {
                        ipnet {
                                ipaddr = 10.100.100.0;
                                mask = 255.255.255.0;
                        }
                }
                phase2remoteid {
                        ipnet {
                                ipaddr = 10.11.0.0;
                                mask = 255.255.0.0;
                        }
                }
                phase2ss = "LT8h/esp-all-all/ah-none/comp-all/pfs";
                accesslist = "permit ip any 10.11.0.0 255.255.0.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";
}
// EOF

die racoon-cfg: (in sainfo kann ich deflate leider nicht deaktivieren :-( das wird per gui IMMER gesetzt...

Code:

remote xxx.xxx.xxx.xxx
{
	ph1id 1;
	exchange_mode aggressive;
	my_identifier fqdn "gw.domain.de";
	peers_identifier fqdn "gw.andereseite.de";
	
	ike_frag on;
	generate_policy = off;
	initial_contact = on;
	nat_traversal = on;
	
	
	dpd_delay = 10;
	dpd_maxfail = 5;
	support_proxy on;
	proposal_check claim;
	

	proposal
	{
		authentication_method pre_shared_key;
		encryption_algorithm aes 256;
		hash_algorithm sha1;
		dh_group 15;
		lifetime time 3600 secs;
	}
}

sainfo subnet 10.11.0.0/16 any subnet 10.100.100.0/24 any
{
	remoteid 1;
	encryption_algorithm aes 256;
	authentication_algorithm hmac_sha1;
	pfs_group 15;
	lifetime time 28800 secs;
	compression_algorithm deflate;
}

Keeper · 22 Aug 2014

Mhm, mal abgesehen davon, dass ich DH15 bisher noch nicht probiert hab, sehe ich spontan keinen Fehler. Hast du mal eine niedrigere Gruppe getestet (und welche Firmware hast du konkret auf der Box?)?
Kannst du mal in den SupportDaten der FB schauen, ob dort etwas steht? Und kommst du an das racoon-Log ran? Irgendwo muss ja eine Fehlermeldung zu finden sein, wenn Phase2 fehl schlägt...

@PeterPawn: Gut, dann meinen wir ja das selbe

PeterPawn · 23 Aug 2014

trendchiller schrieb:
das wird per gui IMMER gesetzt...

Kannst Du das mal näher erklären ? Wie geht das, daß ein GUI da mehr "Macht" hat auf einem *NIX-System als der Mensch ?

Leider kann man nicht sehen, wie der racoon für das Netz (Ports) konfiguriert ist ... da dürfte doch eigentlich nur wenig drinstehen, das "confidential" ist, event. eine IP-Adresse, wenn das kein bind an all ist. Auf der FB-Seite ist das klar und fix, auf dem Server nicht.

Wir reden auch über eine reale Maschine, so richtig mit Netzwerkkarte und allem Pipapo, oder ?
Bei irgendwelchen Virtualisierungen sind die notwendigen Knoten im Gehirn anders aufgebaut bei mir.
Und die notwendigen Admin-Rechte auf der Serverseite gibt es auch ?

Ohne Protokolle wird man da ohnehin nur raten können, wenigstens die FB-Seite (/var/tmp/ike.log) müßtest Du doch haben, oder ?
Das sind zwar alles viele Fragen und Wünsche, aber nur so kann man ernsthaft versuchen, Dich zu unterstützen, alles andere ist nur Pfusch.

Ansonsten wieder mein Lieblingsthema: "native" vs. "NAT-T". Ist aber eben Stochern im Nebel ...
Da die FRITZ!Box das Detektieren eines NAT-Gateways (mit "use_nat_t" etwas unglücklich benannt, es ist keine Anweisung, nur die Erlaubnis zur Detektion) aktiviert hat und racoon auch auf "finde es doch selbst raus" steht (nat_traversal=on -> if needed; nat_traversal=force -> use it, regardless if it's necessary), könnten die auch gut nach der IKE aneinander vorbeireden, allerdings erst nach dem Abschluß von P2 und dem Einrichten der SA. Bist Du Dir denn sicher, daß es beim Übergang von P1 zu P2 klemmt oder ist das nur die Schlußfolgerung aus "P1 ist fertig" und dann keine Infos wie es weiter geht ?

trendchiller · 27 Aug 2014

Hi !
Lang gedauert hat's...
Es ist eine pfSense, da ist halt die GUI die Macht.
Aber am editieren auf Shell-Ebene bin ich nächste Woche dran.
Primär ist es die Schlussfolgerung P1 fertig, weitere Versuche müssen dann mehr zeigen.
Selbst der racoon debug Modus war nicht so kooperativ.

rdemann · 13 Sep 2014

Habe das gleiche Problem. Freue mich falls jemand eine Loesung hat
Gruesse
Robert

[Problem] Fritz!Box 7390 - VPN-Problem nach Update auf 6.04

Neuer User

Mitglied

IPPF-Urgestein

Mitglied

IPPF-Urgestein

Mitglied

IPPF-Urgestein

Neuer User

Mitglied

Neuer User

IPPF-Urgestein

Neuer User

IPPF-Urgestein

Mitglied

Neuer User

IPPF-Urgestein

Mitglied

Neuer User

Statistik des Forums