[HowTo] Fritz!Box-Fernzugang und ShrewSoft VPN Client - Schritt für Schritt

Hi, ich habe ein Problem mit der VPN Verbindung. Leider bleibt die Verbindung nur zirka 1 Stunde stehen, dann verliere ich die Verbindung.

Meine Konfiguration sieht so aus wie hier beschrieben.

Die Fritzbox ist eine 7490 mit dem aktuellen FritzOS. Im Shrew Soft VPN Client erscheint die Meldung : gateway not responding, in der Fritzbox erscheint : VPN-Verbindung zu christian2 wurde getrennt. Ursache: 9 Dead Peer Detection.

Lösungsvorschläge ?
 
Hakt es mit der Verbindung? Schalte die DPD doch mal aus.
 
Ich habe es bereits von extern, sowie innerhalb des Heimnetzes probiert. Problem ist immer das selbe.

Wo kann ich DPD ausschalten, in der Config von ShrewSoft ?
 
In ShrewSoft.

Es gibt auch einen AVM Artikel aber der ist nicht wirklich hilfreich.
 
Okay, ich habe die Option gefunden, ist kaum zu übersehen.
Dann werde ich jetzt mal testen ob die Verbindung stabil bleibt.

Danke schon mal.

ps: ist es normal, dass die 7490 nut zirka 1,2MB/s über VPN schafft und selbst bei 1,0MB/s (aktueller DSL Upload) die Fritzbox so stark überlastet ist das man nicht mehr Telefonieren kann ? :rolleyes:

ps2: das Problem besteht immer noch, nur mit dem Unterschied das der Shrew Soft Client nicht die Verbindung trennt und ich dann einfach kein Internet mehr habe.

Jetzt erscheint in der Fritzbox die Fehlermeldung : VPN-Verbindung zu christian2 wurde getrennt. Ursache: 1 Lifetime expired

ps3: ist scheinbar ein Problem vom FritzOS. In der aktuellen Labor FW 6.29 bleibt das VPN für 8 Stunden offen.
 
Zuletzt bearbeitet:
1und1 VDSL2 50.000

Broadcom
176.15
B5004244434D
7631312E
65715F6E
 
Ich würde einfach mal zum Ende dieses Zeitraums eine permanenten Datenübertragung starten (das kann auch ein Dauerping mit 1-2 Sek. Intervall sein) und damit versuchen zu ermitteln, ob es tatsächlich diese ominösen 54 Minuten sind.

Ich habe gerade hier mal etwas zum AVM-VPN versucht zu schreiben, inspiriert von der neuerlich hier aufgetauchten "Stunde", die das VPN nur noch funktionieren soll. Das löst zwar das Problem nicht, könnte aber die Ursachen erklären.

Ob das auf die Konfiguration bei Christian85 auch so zutreffen könnte, kann ich nicht beurteilen ... ich lese keine Konfigurationen, wenn sie nur "off-site" erläutert werden, sorry. Ist eine prinzipielle Geschichte, denn wenn die andere Quelle sich ändert oder offline geht, ist der komplette Zusammenhang verloren.

EDIT: Das mit den 8 Stunden ist nun wirklich nur eine Krücke ... und wenn einige Aussagen hier im IPPF stimmen, sind das auch nur 8 x 54 Minuten = 432 Minuten und mithin nur 7 Stunden und 12 Minuten.
 
Zuletzt bearbeitet:
Der VPN Tunnel wird bei mir nach genau 60 Minuten geschlossen.

Meine Konfiguration findest du im Anhang.
 

Anhänge

  • Zuhause.zip
    534 Bytes · Aufrufe: 8
Der VPN Tunnel wird bei mir nach genau 60 Minuten geschlossen.
Dann aber sicherlich nicht mit "timeout", sondern mit "expired", oder? Und was heißt eigentlich "wird geschlossen"? Welches Protokoll sagt das und was steht im Log auf der anderen Seite?

Ich habe ja für den längeren Beitrag zum VPN etwas Zeit gebraucht und den Verlauf von #65 bis #67 nur am Rande mitbekommen. Ich habe auch gesehen, daß die Infos über einige Antworten verstreut da tatsächlich stehen könnten ... aber in kondensierter Form nach dem Motto: "Das ist eingestellt und das passiert, am Ende steht das in diesem und das im anderen Protokoll." gibt es das nicht und mir ist nicht einmal so richtig klar, was denn nun vor und was nach Deinen Versuchen ist bzw. wie der aktuelle Stand nun aussieht. Ich versuche gerne zu helfen, aber nur dann, wenn ich weder raten noch auf Schnitzeljagd gehen muß. Ob ich helfen kann, kann ich aber natürlich auch nicht garantieren ... das Risiko müßtest Du eingehen, daß Du Dir die "Mühe" einer kompletten Problembeschreibung machst.

Du hast jetzt DPD deaktiviert auf der Shrewsoft-Seite, wenn ich das richtig verstehe. Eigentlich müßtest Du ja dann auch eine Transport-Mode-Verbindung vom Shrewsoft-Client zur FRITZ!Box haben oder ist das auch LAN-LAN (also Tunnel-Mode)? Wenn Du nur auf der Shrewsoft-Seite DPD deaktivierst und damit einfach nicht mehr festgestellt wird, daß die FRITZ!Box ihrerseits nach 54 Minuten die Schotten dicht macht (wenn sie das tun sollte), dann hast Du ja eigentlich auch nichts wirklich gewonnen. Die Verbindung hält zwar theoretisch 6 Minuten länger, eine Datenübertragung dürfte aber trotzdem kaum möglich sein in diesen zusätzlichen 6 Minuten. Dann würde ich DPD sofort wieder aktivieren, dann hat der Shrewsoft-Client wenigstens eine *Chance*, eine nicht funktionierende Verbindung zu erkennen. Wenn Du schreibst, die VPN-Verbindung hält jetzt 60 Sekunden Minuten, würde ich ansonsten tatsächlich annehmen, Du hättest es innerhalb von 40 Minuten (zwischen meinem und Deinem Beitrag) geschafft, eine VPN-Verbindung, die nach einer Stunde ein Problem hat, entsprechend meinem Vorschlag (Daten übertragen, alles andere ist nur Bullshit-Bingo) zu testen. Solange da nicht die Relativitätstheorie eine Erklärung liefert, wäre das für mich aber schon etwas erstaunlich. Außer Du hast es bereits vorher so getestet und nur vergessen, uns auch mitzuteilen, daß Deine Erkenntnisse nicht nur auf irgendwelchen Angaben im FRITZ!Box-Eventlog basieren. Das, was da drin steht, darfst Du für eine genaue Eingrenzung des Problems getrost ignorieren.

Mit der Konfiguration (soll sicherlich Shrewsoft sein) kann ich nicht wirklich etwas anfangen. Ich meinte auch eher die Beschreibung der Rahmenbedingungen (welche FRITZ!Box, welche Firmware, welcher Client bzw. auf welcher Plattform, Tunnel- oder Transport-Mode, XAUTH, Keepalives, always_renew, usw.). Nur "nach 60 Minuten wird die Verbindung unterbrochen" ist eben etwas schmal ... schon die unmittelbar anschließende Frage, wer denn da die Verbindung wieder aufbauen könnte/müßte/sollte (wenn es Tunnel-Mode ist, bei Transport-Mode mit "Host->Router" ist es ja in aller Regel der Host), bleibt damit komplett offen. Ich weiß auch nicht mal genau, ob der Shrewsoft-Client für Linux (verstehe ich doch richtig oder etwa doch nicht?) überhaupt Tunnel-Mode unterstützt. Ist eigentlich eher nutzlos, denn der soll ja meines Erachtens mehr als GUI-Schalter für "VPN oder nicht" funktionieren für "road warrior" und da ist Tunnel-Mode nicht das Mittel der Wahl.

Wenn Deine FRITZ!Box (daß es eine 7490 ist, habe ich gelesen, aber "aktuelle Firmware" kann sowohl 06.24 als auch 06.29-30272 heißen, das weiß in 3 Monaten kein Mensch mehr, wenn er diesen Thread findet bei der Internet-Suche) Dir den Zugriff erlaubt (ich sehe nicht, was dem entgegenstehen würde), kannst Du entweder per Telnet in die /var/tmp/ike.log sehen oder sie aus den Support-Daten puhlen. Darin solltest Du zumindest die von mir aus der ike.log zitierten Zeilen finden, u.a. mit der Info, welche Zeiten die FRITZ!Box denn nun wirklich benutzt und wann da welche SA erneuert oder invalidiert wird. Stimmt dann auf beiden Seiten auch noch die Uhrzeit, kann man beide Protokolle vergleichen. Wenn die KLT nach max. 3600 Sekunden auf beiden Seiten abgelaufen ist und niemand diese Verbindung erneuern will (gibt es ein Keepalive oder nicht, wäre dann wieder die Frage nach der richtigen Konfigurationseinstellung), dann ist es doch normal, wenn die Verbindung "zu bleibt", bis jemand darüber senden will (kann bei Trans-Mode ja nur der Host sein, der Router ist i.a.R. passiv). Wenn dann der Shrewsoft-Client erneut versucht, die Verbindung aufzubauen und dabei scheitert, findet sich der Grund sicherlich im Protokoll.

Daß generell etwas mit dem AVM-VPN nicht stimmt, ist sicherlich richtig ... man kann also nach einem Workaround suchen oder die Flinte ins Korn werfen und auf eine neue Firmware warten. Ob es da besser ist? Wenn Du den Link von andiling mal genutzt hast, wirst Du ja auch gelesen haben, daß es sich in Labor-Firmware bei einigen geändert haben soll. Wenn die ganze Lösung aber nur in der Verlängerung der Lifetime besteht, ist das für mich nicht einmal ein Workaround, nur ein ziemlich mieser Trick, das Problem von 24x pro Tag auf 3x pro Tag auszudünnen, was bei einem Handy/Tablet ja noch Sinn machen mag, bei einer "always on"-Verbindung für "headless clients" ist es am Ende egal, ob sie 24x oder 3x pro Tag einen Eingriff erfordert. Eine Lösung ist ein sauberes Rekeying ausschließlich für Phase2, wenn die vereinbarte Key-Lifetime abgelaufen ist. Alles andere ist Flickwerk ...

PS: Solltest Du tatsächlich noch eine Problembeschreibung liefern, nicht ungeduldig sein ... ich lese vor 20 Uhr eher nicht weiter hier, eine Reaktion kann also dauern. Ich hoffe, daß schon aus den (teilweise absichtlichen) Mißverständnissen aber zu entnehmen ist, daß ohne präzise Angaben eine Hilfe schwierig bis unmöglich ist. Ich schreibe häufig zwar viel, aber alle theoretisch möglichen Probleme einer IPSec-Verbindung in einen Beitrag zu stopfen, fällt sogar mir schwer.
 
Fritzbox 7490 OS 6.24
Windows 7
Shrew Soft VPN Client
*Konfiguration im Anhang
Auf das ike.log der Fritzbox kann ich nicht zugreifen : Permission denied.

Die VPN Verbindung wird reproduzierbar nach 54 Minuten getrennt, dann erhalte ich im Shrew Soft Client die Fehlermeldung : gateway not responding .
Die Fritzbox meldet : Ursache: 9 Dead Peer Detection.
Dabei ist es egal, ob Traffic durch das VPN läuft oder es sich im idle befindet.

Die VPN Verbindung ist dann geschlossen, ich kann aber sofort wieder eine neue Verbindung herstellen.

Ich hoffe ich liefere hiermit alle nötigen Informationen.
 

Anhänge

  • General.PNG
    General.PNG
    34 KB · Aufrufe: 45
  • client.PNG
    client.PNG
    35 KB · Aufrufe: 40
  • auth2.PNG
    auth2.PNG
    36 KB · Aufrufe: 37
  • auth3.PNG
    auth3.PNG
    35.6 KB · Aufrufe: 34
  • phase1.PNG
    phase1.PNG
    33.4 KB · Aufrufe: 38
  • phase2.PNG
    phase2.PNG
    32.5 KB · Aufrufe: 37
  • name resolution.PNG
    name resolution.PNG
    34.9 KB · Aufrufe: 35
  • name resolution2.PNG
    name resolution2.PNG
    30.8 KB · Aufrufe: 33
  • policy.PNG
    policy.PNG
    36.2 KB · Aufrufe: 33
  • auth.PNG
    auth.PNG
    30 KB · Aufrufe: 36
Zuletzt bearbeitet:
Auf das ike.log der Fritzbox kann ich nicht zugreifen : Permission denied.
Das kann fast nicht sein ... Telnet-Login (wie Telnet aktiviert wird, steht hier überall) und dann
Code:
cat /var/tmp/ike.log
sollte problemlos funktionieren, da kann es eigentlich kein Rechteproblem geben. Bei der Gelegenheit dann noch ein
Code:
cat /var/flash/vpn.cfg
hinterher und aus der Datei die Verbindung für den Windows-PC (bzw. den Benutzer) extrahieren und (in Maßen) unkenntlich machen. Dann hätten wir eigentlich alles. Das Wissen um die Einstellungen für den VPN-Client auf der FRITZ!Box ist tatsächlich noch wichtig.

Ich hoffe ich liefere hiermit alle nötigen Informationen.
Fast ... ;)

Ich habe zwar noch nicht auf die Screenshot geschaut, ich verstehe aber ohnehin nicht, wieso der Shrewsoft-Client nicht nach DPD von sich aus wieder die Verbindung neu aufbaut. Deshalb auch der einmal notwendige Blick in das FRITZ!Box-Log (eigentlich sollte es beim Shrewsoft-Client so etwas auch geben, vielleicht findest Du es ja - wenn es existiert - alleine und kannst es hier auch anhängen) ... es ist schon ein erheblicher Unterschied, ob der Client keine neue Verbindung aufbauen will nach der DPD oder ob es dabei irgendwo klemmt.

Nur als kurzer Einwurf, die Zeitangabe von vorhin gilt immer noch, verschiebt sich eher weiter in die Nacht.

EDIT/Nachtrag: Wobei die auf beiden Seiten konstatierte DPD-"Auslösung" ja tatsächlich wieder auf unterschiedliche SA hindeutet nach den ominösen 54 Minuten ... wenn die Verbindung neu aufgebaut wird, kommt bestimmt auch wieder eine "initial contact message" mit und beide Seiten verwerfen die aktuellen SA und handeln neue aus. Ich weiß ja nicht, ob Du den längeren Beitrag zu den 54 Minuten gelesen hast, da wäre das erklärt (oder zumindest der Versuch einer Erklärung findet da statt). Wie sich das in der Protokoll-Datei der FRITZ!Box darstellt, muß man aber wirklich konkret bei Dir schauen. Solltest Du mehr als eine VPN-Verbindung konfiguriert haben, deaktiviere bitte alle anderen zwischendurch, damit in der ike.log wirklich nur die Angaben zu der einen Verbindung auftauchen und Du nicht beim Versuch einer Bearbeitung am Ende Zeilen löschst, die eigentlich wichtig wären. Auch ein Neustart des VPN-Daemons bei AVM (notfalls über "msgsend dsld vpndisable" mit nachfolgendem "msgsend dsld vpnenable" - zwischendrin "settlen" lassen, sieht man ja am Console-Log in der ersten Telnet-Session) wäre schlau, weil dann die Datei neu angelegt wird. Auch ein Neustart wäre eine (allerdings nicht wirklich erforderliche) Option, wenn Du das "Leeren" der Datei über msgsend nicht hinkriegst.
 
Zuletzt bearbeitet:
ike.log
Code:
password:


BusyBox v1.20.2 (2014-09-26 13:25:19 CEST) built-in shell (ash)
Enter 'help' for a list of built-in commands.

ermittle die aktuelle TTY
tty is "/dev/pts/0"
Console Ausgaben auf dieses Terminal umgelenkt
disable start/stop characters and flowcontrol
# cat /var/tmp/ike.log
2015-05-03 12:27:09 avmike:christian2: quickmode: no SA found
2015-05-03 12:27:25 avmike:christian2: quickmode: no SA found
2015-05-03 12:27:41 avmike:christian2: quickmode: no SA found
2015-05-03 12:27:57 avmike:christian2: quickmode: no SA found
2015-05-03 12:28:13 avmike:christian2: quickmode: no SA found
2015-05-03 12:28:29 avmike:christian2: quickmode: no SA found
2015-05-03 12:28:46 avmike:christian2: quickmode: no SA found
2015-05-03 12:29:02 avmike:christian2: quickmode: no SA found
2015-05-03 12:29:19 avmike:christian2: quickmode: no SA found
2015-05-03 12:29:35 avmike:christian2: quickmode: no SA found
2015-05-03 12:29:51 avmike:christian2: quickmode: no SA found
2015-05-03 12:30:08 avmike:christian2: quickmode: no SA found
2015-05-03 12:30:24 avmike:christian2: quickmode: no SA found
2015-05-03 12:30:40 avmike:christian2: quickmode: no SA found
2015-05-03 12:30:57 avmike:christian2: quickmode: no SA found
2015-05-03 12:31:15 avmike:christian2: quickmode: no SA found
2015-05-03 12:31:31 avmike:christian2: quickmode: no SA found
2015-05-03 12:31:47 avmike:christian2: quickmode: no SA found
2015-05-03 12:32:03 avmike:christian2: quickmode: no SA found
2015-05-03 12:32:20 avmike:christian2: quickmode: no SA found
2015-05-03 12:32:36 avmike:christian2: quickmode: no SA found
2015-05-03 12:32:53 avmike:christian2: quickmode: no SA found
2015-05-03 12:33:09 avmike:christian2: quickmode: no SA found
2015-05-03 12:33:25 avmike:christian2: quickmode: no SA found
2015-05-03 12:33:42 avmike:christian2: quickmode: no SA found
2015-05-03 12:34:00 avmike:christian2: quickmode: no SA found
2015-05-03 12:34:16 avmike:christian2: quickmode: no SA found
2015-05-03 12:34:33 avmike:christian2: quickmode: no SA found
2015-05-03 12:34:49 avmike:christian2: quickmode: no SA found
2015-05-03 12:35:06 avmike:christian2: quickmode: no SA found
2015-05-03 12:35:23 avmike:christian2: quickmode: no SA found
2015-05-03 12:35:39 avmike:christian2: quickmode: no SA found
2015-05-03 12:35:55 avmike:christian2: quickmode: no SA found
2015-05-03 12:36:12 avmike:christian2: quickmode: no SA found
2015-05-03 12:36:28 avmike:christian2: quickmode: no SA found
2015-05-03 12:36:44 avmike:christian2: quickmode: no SA found
2015-05-03 12:37:00 avmike:christian2: quickmode: no SA found
2015-05-03 12:37:16 avmike:christian2: quickmode: no SA found
2015-05-03 12:37:33 avmike:christian2: quickmode: no SA found
2015-05-03 12:37:50 avmike:christian2: quickmode: no SA found
2015-05-03 12:38:06 avmike:christian2: quickmode: no SA found
2015-05-03 12:38:22 avmike:christian2: quickmode: no SA found
2015-05-03 12:38:39 avmike:christian2: quickmode: no SA found
2015-05-03 12:38:55 avmike:christian2: quickmode: no SA found
2015-05-03 12:39:11 avmike:christian2: quickmode: no SA found
2015-05-03 12:39:28 avmike:christian2: quickmode: no SA found
2015-05-03 12:39:45 avmike:christian2: quickmode: no SA found
2015-05-03 12:40:01 avmike:christian2: quickmode: no SA found
2015-05-03 12:40:18 avmike:christian2: quickmode: no SA found
2015-05-03 12:40:34 avmike:christian2: quickmode: no SA found
2015-05-03 12:40:51 avmike:christian2: quickmode: no SA found
2015-05-03 12:41:07 avmike:christian2: quickmode: no SA found
2015-05-03 12:41:24 avmike:christian2: quickmode: no SA found
2015-05-03 12:41:41 avmike:christian2: quickmode: no SA found
2015-05-03 12:41:57 avmike:christian2: quickmode: no SA found
2015-05-03 12:42:14 avmike:christian2: quickmode: no SA found
2015-05-03 12:42:30 avmike:christian2: quickmode: no SA found
2015-05-03 12:42:47 avmike:christian2: quickmode: no SA found
2015-05-03 12:43:03 avmike:christian2: quickmode: no SA found
2015-05-03 12:43:19 avmike:christian2: quickmode: no SA found
2015-05-03 12:43:35 avmike:christian2: quickmode: no SA found
2015-05-03 12:43:52 avmike:christian2: quickmode: no SA found
2015-05-03 12:44:09 avmike:christian2: quickmode: no SA found
2015-05-03 12:44:26 avmike:christian2: quickmode: no SA found
2015-05-03 12:44:42 avmike:christian2: quickmode: no SA found
2015-05-03 12:44:59 avmike:christian2: quickmode: no SA found
2015-05-03 12:45:15 avmike:christian2: quickmode: no SA found
2015-05-03 12:45:31 avmike:christian2: quickmode: no SA found
2015-05-03 12:45:47 avmike:christian2: quickmode: no SA found
2015-05-03 12:46:04 avmike:christian2: quickmode: no SA found
2015-05-03 12:46:20 avmike:christian2: quickmode: no SA found
2015-05-03 12:46:36 avmike:christian2: quickmode: no SA found
2015-05-03 12:46:55 avmike:christian2: quickmode: no SA found
2015-05-03 12:47:11 avmike:christian2: quickmode: no SA found
2015-05-03 12:47:27 avmike:christian2: quickmode: no SA found
2015-05-03 12:47:43 avmike:christian2: quickmode: no SA found
2015-05-03 12:48:02 avmike:christian2: quickmode: no SA found
2015-05-03 12:48:20 avmike:christian2: quickmode: no SA found
2015-05-03 12:48:36 avmike:christian2: quickmode: no SA found
2015-05-03 12:48:53 avmike:christian2: quickmode: no SA found
2015-05-03 12:49:09 avmike:christian2: quickmode: no SA found
2015-05-03 12:49:27 avmike:christian2: quickmode: no SA found
2015-05-03 12:49:43 avmike:christian2: quickmode: no SA found
2015-05-03 12:49:59 avmike:christian2: quickmode: no SA found
2015-05-03 12:50:16 avmike:christian2: quickmode: no SA found
2015-05-03 12:50:32 avmike:christian2: quickmode: no SA found
2015-05-03 12:50:49 avmike:christian2: quickmode: no SA found
2015-05-03 12:51:05 avmike:christian2: quickmode: no SA found
2015-05-03 12:51:22 avmike:christian2: quickmode: no SA found
2015-05-03 12:51:38 avmike:christian2: quickmode: no SA found
2015-05-03 12:51:54 avmike:christian2: quickmode: no SA found
2015-05-03 12:52:11 avmike:christian2: quickmode: no SA found
2015-05-03 12:52:28 avmike:christian2: quickmode: no SA found
2015-05-03 12:52:44 avmike:christian2: quickmode: no SA found
2015-05-03 12:53:01 avmike:christian2: quickmode: no SA found
2015-05-03 12:53:19 avmike:christian2: quickmode: no SA found
2015-05-03 12:53:36 avmike:christian2: quickmode: no SA found
2015-05-03 12:53:53 avmike:christian2: quickmode: no SA found
2015-05-03 12:54:09 avmike:christian2: quickmode: no SA found
2015-05-03 12:54:25 avmike:christian2: quickmode: no SA found
2015-05-03 12:54:42 avmike:christian2: quickmode: no SA found
2015-05-03 12:54:58 avmike:christian2: quickmode: no SA found
2015-05-03 12:55:15 avmike:christian2: quickmode: no SA found
2015-05-03 12:55:31 avmike:christian2: quickmode: no SA found
2015-05-03 12:55:48 avmike:christian2: quickmode: no SA found
2015-05-03 12:56:04 avmike:christian2: quickmode: no SA found
2015-05-03 12:56:22 avmike:christian2: quickmode: no SA found
2015-05-03 12:56:40 avmike:christian2: quickmode: no SA found
2015-05-03 12:56:56 avmike:christian2: quickmode: no SA found
2015-05-03 12:57:13 avmike:christian2: quickmode: no SA found
2015-05-03 12:57:29 avmike:christian2: quickmode: no SA found
2015-05-03 12:57:47 avmike:christian2: quickmode: no SA found
2015-05-03 12:58:04 avmike:christian2: quickmode: no SA found
2015-05-03 12:58:20 avmike:christian2: quickmode: no SA found
2015-05-03 12:58:36 avmike:christian2: quickmode: no SA found
2015-05-03 12:58:54 avmike:christian2: quickmode: no SA found
2015-05-03 12:59:10 avmike:christian2: quickmode: no SA found
2015-05-03 12:59:26 avmike:christian2: quickmode: no SA found
2015-05-03 12:59:43 avmike:christian2: quickmode: no SA found
2015-05-03 12:59:59 avmike:christian2: quickmode: no SA found
2015-05-03 13:00:15 avmike:christian2: quickmode: no SA found
2015-05-03 13:00:31 avmike:christian2: quickmode: no SA found
2015-05-03 13:00:48 avmike:christian2: quickmode: no SA found
2015-05-03 13:01:04 avmike:christian2: quickmode: no SA found
2015-05-03 13:01:20 avmike:christian2: quickmode: no SA found
2015-05-03 13:01:37 avmike:christian2: quickmode: no SA found
2015-05-03 13:01:53 avmike:christian2: quickmode: no SA found
2015-05-03 13:02:09 avmike:christian2: quickmode: no SA found
2015-05-03 13:02:25 avmike:christian2: quickmode: no SA found
2015-05-03 13:02:41 avmike:christian2: quickmode: no SA found
2015-05-03 13:02:58 avmike:christian2: quickmode: no SA found
2015-05-03 13:03:14 avmike:christian2: quickmode: no SA found
2015-05-03 13:03:30 avmike:christian2: quickmode: no SA found
2015-05-03 13:03:47 avmike:christian2: quickmode: no SA found
2015-05-03 13:04:04 avmike:christian2: quickmode: no SA found
2015-05-03 13:04:20 avmike:christian2: quickmode: no SA found
2015-05-03 13:04:37 avmike:christian2: quickmode: no SA found
2015-05-03 13:04:54 avmike:christian2: quickmode: no SA found
2015-05-03 14:38:00 avmike:mainmode christian2: selected lifetime: 3600 sec(noti
fy)
2015-05-03 14:38:00 avmike:christian2 remote peer supported XAUTH
2015-05-03 14:38:00 avmike:christian2 remote peer supported NAT-T RFC 3947
2015-05-03 14:38:00 avmike:christian2 remote peer supported DPD
2015-05-03 14:38:00 avmike:mainmode christian2: add SA 2
2015-05-03 14:38:00 avmike:Phase1 Responder-Lifetime-Payload wird erstellt
2015-05-03 14:38:00 avmike:christian2: Warning: source changed from 87.168.205.1
59:61120 to 87.168.205.159:61141
2015-05-03 14:38:00 avmike:christian2: switching to NAT-T (Responder)
2015-05-03 14:38:00 avmike:christian2: Phase 1 ready
2015-05-03 14:38:00 avmike:christian2: current=87.168.205.159:61120 new=87.168.2
05.159:61141
2015-05-03 14:38:00 avmike:christian2: remote is behind a nat
2015-05-03 14:38:00 avmike:christian2: inital contact message received
2015-05-03 14:38:00 avmike:christian2: inital contact message ignored
2015-05-03 14:38:00 avmike:christian2
 fehlerhafte Paketlaenge: Hdr-length > read-Data
2015-05-03 14:38:00 avmike:christian2: start waiting connections
2015-05-03 14:38:00 avmike:christian2: NO waiting connections
2015-05-03 14:38:00 avmike:christian2
 fehlerhafte Paketlaenge: Hdr-length > read-Data
2015-05-03 14:38:00 avmike:christian2: start waiting connections
2015-05-03 14:38:00 avmike:christian2: NO waiting connections
2015-05-03 14:38:04 avmike:christian2: Phase 2 ready
2015-05-03 14:38:04 avmike:< cb_sa_created(name=christian2,id=3,...,flags=0x0002
2003)
2015-05-03 14:38:04 avmike:christian2: start waiting connections
2015-05-03 14:38:04 avmike:christian2: NO waiting connections
2015-05-03 15:26:04 avmike:christian2: Phase 2 ready
2015-05-03 15:26:04 avmike:< cb_sa_created(name=christian2,id=4,...,flags=0x0002
2003)
2015-05-03 15:26:04 avmike:christian2: start waiting connections
2015-05-03 15:26:04 avmike:christian2: NO waiting connections
2015-05-03 15:38:00 avmike:mainmode christian2: del SA 2
2015-05-03 15:38:03 avmike:FreeIPsecSA: spi=1aab2224            protocol=3 iotyp
e=1
2015-05-03 15:38:03 avmike:FreeIPsecSA: spi=919bc17             protocol=3 iotyp
e=2
2015-05-03 15:38:29 avmike:mainmode christian2: selected lifetime: 3600 sec(noti
fy)
2015-05-03 15:38:29 avmike:christian2 remote peer supported XAUTH
2015-05-03 15:38:29 avmike:christian2 remote peer supported NAT-T RFC 3947
2015-05-03 15:38:29 avmike:christian2 remote peer supported DPD
2015-05-03 15:38:29 avmike:mainmode christian2: add SA 3
2015-05-03 15:38:29 avmike:Phase1 Responder-Lifetime-Payload wird erstellt
2015-05-03 15:38:29 avmike:christian2: switching to NAT-T (Responder)
2015-05-03 15:38:29 avmike:christian2: Phase 1 ready
2015-05-03 15:38:29 avmike:christian2: current=87.168.205.159:61141 new=87.168.2
05.159:61141
2015-05-03 15:38:29 avmike:christian2: remote is behind a nat
2015-05-03 15:38:29 avmike:christian2: inital contact message received
2015-05-03 15:38:29 avmike:christian2: inital contact message ignored
2015-05-03 15:38:29 avmike:christian2
 fehlerhafte Paketlaenge: Hdr-length > read-Data
2015-05-03 15:38:29 avmike:christian2: start waiting connections
2015-05-03 15:38:29 avmike:christian2: NO waiting connections
2015-05-03 15:38:29 avmike:christian2
 fehlerhafte Paketlaenge: Hdr-length > read-Data
2015-05-03 15:38:29 avmike:christian2: start waiting connections
2015-05-03 15:38:29 avmike:christian2: NO waiting connections
2015-05-03 15:38:33 avmike:christian2: Phase 2 ready
2015-05-03 15:38:33 avmike:< cb_sa_created(name=christian2,id=5,...,flags=0x0002
2003)
2015-05-03 15:38:33 avmike:christian2: start waiting connections
2015-05-03 15:38:33 avmike:christian2: NO waiting connections
2015-05-03 15:38:59 avmike:christian2
 fehlerhafte Paketlaenge: Hdr-length > read-Data
2015-05-03 15:38:59 avmike:FreeIPsecSA: spi=763f57              protocol=3 iotyp
e=2
2015-05-03 15:38:59 avmike:< cb_sa_deleted(name=christian2,id=5,what=2)
2015-05-03 15:38:59 avmike:christian2
 fehlerhafte Paketlaenge: Hdr-length > read-Data
2015-05-03 15:38:59 avmike:mainmode christian2: del SA 3
2015-05-03 15:38:59 avmike:wolke_del_neighbour_sa_by_remote: no SAs available, s
et canceld = TRUE
2015-05-03 15:38:59 avmike:< cb_sa_deleted(name=christian2,id=4,what=3)
2015-05-03 15:38:59 avmike:FreeIPsecSA: spi=5baca68b            protocol=3 iotyp
e=1
2015-05-03 15:38:59 avmike:FreeIPsecSA: spi=aed6947c            protocol=3 iotyp
e=2
2015-05-03 15:38:59 avmike:< cb_sa_deleted(name=christian2,id=5,what=3)
2015-05-03 15:38:59 avmike:FreeIPsecSA: spi=affcefa3            protocol=3 iotyp
e=1
2015-05-03 17:15:14 avmike:mainmode christian2: selected lifetime: 3600 sec(noti
fy)
2015-05-03 17:15:14 avmike:christian2 remote peer supported XAUTH
2015-05-03 17:15:14 avmike:christian2 remote peer supported NAT-T RFC 3947
2015-05-03 17:15:14 avmike:christian2 remote peer supported DPD
2015-05-03 17:15:14 avmike:mainmode christian2: add SA 4
2015-05-03 17:15:14 avmike:Phase1 Responder-Lifetime-Payload wird erstellt
2015-05-03 17:15:14 avmike:christian2: Warning: source changed from 87.168.205.1
59:61141 to 87.168.205.159:61239
2015-05-03 17:15:14 avmike:christian2: switching to NAT-T (Responder)
2015-05-03 17:15:14 avmike:christian2: Phase 1 ready
2015-05-03 17:15:14 avmike:christian2: current=87.168.205.159:61141 new=87.168.2
05.159:61239
2015-05-03 17:15:14 avmike:christian2: remote is behind a nat
2015-05-03 17:15:14 avmike:christian2: inital contact message received
2015-05-03 17:15:14 avmike:christian2: inital contact message ignored
2015-05-03 17:15:14 avmike:christian2
 fehlerhafte Paketlaenge: Hdr-length > read-Data
2015-05-03 17:15:14 avmike:christian2: start waiting connections
2015-05-03 17:15:14 avmike:christian2: NO waiting connections
2015-05-03 17:15:14 avmike:christian2
 fehlerhafte Paketlaenge: Hdr-length > read-Data
2015-05-03 17:15:14 avmike:christian2: start waiting connections
2015-05-03 17:15:14 avmike:christian2: NO waiting connections
2015-05-03 17:15:18 avmike:mainmode christian2: selected lifetime: 3600 sec(noti
fy)
2015-05-03 17:15:18 avmike:christian2 remote peer supported XAUTH
2015-05-03 17:15:18 avmike:christian2 remote peer supported NAT-T RFC 3947
2015-05-03 17:15:18 avmike:christian2 remote peer supported DPD
2015-05-03 17:15:18 avmike:mainmode christian2: add SA 5
2015-05-03 17:15:18 avmike:Phase1 Responder-Lifetime-Payload wird erstellt
2015-05-03 17:15:18 avmike:christian2: Phase 1 ready
2015-05-03 17:15:18 avmike:christian2: current=87.168.205.159:61239 new=87.168.2
05.159:61239
2015-05-03 17:15:18 avmike:christian2: local is behind a nat
2015-05-03 17:15:18 avmike:christian2: remote is behind a nat
2015-05-03 17:15:18 avmike:christian2
 fehlerhafte Paketlaenge: Hdr-length > read-Data
2015-05-03 17:15:18 avmike:christian2: start waiting connections
2015-05-03 17:15:18 avmike:christian2: NO waiting connections
2015-05-03 17:15:34 avmike:christian2: Phase 2 ready
2015-05-03 17:15:34 avmike:< cb_sa_created(name=christian2,id=6,...,flags=0x0003
2003)
2015-05-03 17:15:34 avmike:christian2: start waiting connections
2015-05-03 17:15:34 avmike:christian2: NO waiting connections
2015-05-03 17:15:44 avmike:>>>4500 nat-t-keepalive[87.168.205.159:61239]
2015-05-03 17:17:32 avmike:christian2
 fehlerhafte Paketlaenge: Hdr-length > read-Data
2015-05-03 17:17:32 avmike:mainmode christian2: del SA 4
2015-05-03 17:17:32 avmike:wolke_del_neighbour_sa_by_remote: no SAs available, s
et canceld = TRUE
2015-05-03 18:15:18 avmike:mainmode christian2: del SA 5
2015-05-03 18:15:33 avmike:FreeIPsecSA: spi=d94a2d11            protocol=3 iotyp
e=1
2015-05-03 18:15:33 avmike:FreeIPsecSA: spi=fe22597             protocol=3 iotyp
e=2
#

vpn.cfg
Code:
password:


BusyBox v1.20.2 (2014-09-26 13:25:19 CEST) built-in shell (ash)
Enter 'help' for a list of built-in commands.

ermittle die aktuelle TTY
tty is "/dev/pts/1"
weitere telnet Verbindung aufgebaut
disable start/stop characters and flowcontrol
# cat /var/flash/vpn.cfg
/*
 * /var/flash/vpn.cfg
 * Thu Apr 16 20:09:04 2015
 */

meta { encoding = "utf-8"; }

vpncfg {
        connections {
                enabled = yes;
                editable = no;
                conn_type = conntype_user;
                name = "christian";
                boxuser_id = 11;
                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 = 10.4.2.202;
                keepalive_ip = 0.0.0.0;
                remoteid {
                        key_id = "********************************";
                }
                mode = phase1_mode_aggressive;
                phase1ss = "all/all/all";
                keytype = connkeytype_pre_shared;
                key = "**************************";
                cert_do_server_auth = no;
                use_nat_t = yes;
                use_xauth = yes;
                xauth {
                        valid = yes;
                        username = "********************************";
                        passwd = "********************************";
                }
                use_cfgmode = yes;
                phase2localid {
                        ipnet {
                                ipaddr = 0.0.0.0;
                                mask = 0.0.0.0;
                        }
                }
                phase2remoteid {
                        ipaddr = 10.4.2.202;
                }
                phase2ss = "esp-all-all/ah-none/comp-all/no-pfs";
                accesslist =
                             "permit ip 0.0.0.0 0.0.0.0 10.4.2.202 255.255.255.2
55";
        } {
                enabled = yes;
                editable = no;
                conn_type = conntype_user;
                name = "christian2";
                boxuser_id = 12;
                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 = 10.4.2.203;
                keepalive_ip = 0.0.0.0;
                remoteid {
                        key_id = "********************************";
                }
                mode = phase1_mode_aggressive;
                phase1ss = "all/all/all";
                keytype = connkeytype_pre_shared;
                key = "********************************";
                cert_do_server_auth = no;
                use_nat_t = yes;
                use_xauth = yes;
                xauth {
                        valid = yes;
                        username = "********************************";
                        passwd = "********************************";
                }
                use_cfgmode = yes;
                phase2localid {
                        ipnet {
                                ipaddr = 0.0.0.0;
                                mask = 0.0.0.0;
                        }
                }
                phase2remoteid {
                        ipaddr = 10.4.2.203;
                }
                phase2ss = "esp-all-all/ah-none/comp-all/no-pfs";
                accesslist =
                             "permit ip 0.0.0.0 0.0.0.0 10.4.2.203 255.255.255.2
55";
        }
        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
#

ich verstehe aber ohnehin nicht, wieso der Shrewsoft-Client nicht nach DPD von sich aus wieder die Verbindung neu aufbaut.
Unabhängig vom DPD gibt es eine Option für das automatischen wiederherstellen der Verbindung.

Ich hoffe du kannst mit den Infos etwas anfangen.
 
Ich hoffe du kannst mit den Infos etwas anfangen.
Ich komme mir zwar auch langsam blöd vor, weil ich immer wieder nach weiteren Infos fragen müßte, aber vielleicht liest Du ja einfach mal mit, was in Deinen Protokollen so steht.

Abgesehen davon fehlt einfach Kontext ... ich mache das gleich mal an einem konkreten Punkt fest.

Die ersten 138 Zeilen Deiner Protokolldatei zeigen erst einmal nur, daß da von 12:27:09 bis 14:38:00 keine "Security Association" (SA, das ist ein Satz von Einstellungen, bestehend u.a. aus der entfernten und der lokalen IP-Adresse und dem verwendeten Schlüssel und anderen Parametern, wie der vereinbarten Lebensdauer) existiert, mit der die trotzdem in regelmäßigen Abständen eintreffenden Daten (anfangs alle 16 Sekunden, später werden es 17, ich tippe mal auf DPD-Pakete seitens des Shrewsoft-Clients) entschlüsselt werden können.

Da Du bestimmt einen guten Grund hattest, die Bitte um den Neustart auf beiden Seiten vor dem zu protokollierenden Versuch zu ignorieren, würde mich schon interessieren, welcher das war. Die ersten 138 Zeilen hättest Du uns damit schon mal erspart.

Außerdem würde sich die Frage, was denn nun um 14:38:00 plötzlich passierte, daß da seitens des Clients eine neue Verbindung aufgebaut wurde, dann auch erübrigen, das würde ich dann indirekt daraus schließen, daß Du offenbar ein Protokoll erstellen lassen wolltest.

Das meine ich aber mit "Kontext" ... wenn das alles ohne Eingriffe durch Dich so automatisch abgelaufen sein sollte (selbst dann fehlt die Angabe, ob denn nun die empfohlenen regelmäßigen Datenübertragungen stattgefunden haben und was diese für Ergebnisse lieferten), dann sind das schon vollkommen unerklärliche Intervalle, die da zu beobachten sind.

Als Einschub ganz kurz noch etwas zu der Konfiguration ... die sieht vollkommen normal aus, mit dem GUI-Assistenten eingerichtet, die Zeilenumbrüche in der vpn.cfg sind hoffentlich nur auf das Kopieren aus einem ungeeigneten Terminalprogramm zurückzuführen?

Gibt es einen bestimmten Grund, da das Netz 10.4.2.0/24 zu verwenden? Es muß kein Problem sein, andererseits fummelt AVM für mein Empfinden bei allen anderen privaten Adressbereichen auch mal gerne dazwischen und wenn da irgendwelche ganz alten Routinen noch am Werkeln sind, dann kennen die vielleicht noch gar kein CIDR. Wenn ich Probleme suchen wollte, würde ich erst einmal alles vermeiden, was von "Standardeinstellungen" abweicht und zwar mindestens so lange, bis ich sicher weiß, daß es daran nicht liegen kann. Wie gesagt, wird es eher nicht sein ... ist nur eine Frage des Prinzips, daß man nicht alles auf einmal ändert und sich hinterher wundert, daß nichts funktioniert. Dann sollte man tatsächlich Schritt für Schritt vorwärts gehen und ggf. auch unabhängige Änderungen erst einmal wieder rückgängig machen, um das Problem auf das Wesentliche zu reduzieren.

Zurück zum Log ... um 14:38:00 startet ja nun aus heiterem Himmel der Shrewsoft-Client eine neue Verbindung (offenbar war der seit 13:04:54 ja tot, da kam das letzte nicht zu entschlüsselnde Paket bei der FRITZ!Box an) und nachdem Phase1 dann geklappt hat, funktioniert auch um 14:38:04 irgendwann Phase2, damit steht die Verbindung. Auch die Feststellung der FRITZ!Box, daß sich der Absenderport des Shrewsoft-Clients geändert hat (von 61120 auf 61141) ist ein überdeutliches Zeichen dafür (neben den Nachrichten seit dem frühen Morgen), daß da auch in der FRITZ!Box schon länger der avmike lief und die letzte Verbindung des Clients (die muß ja irgendwann vor 12:27:09 mal aufgebaut worden sein, denn zu diesem Zeitpunkt war sie dann schon tot) von einem anderen Port aus erfolgte. Wieso der Shrewsoft-Client jetzt nach mindestens 130 Minuten plötzlich wieder aktiv wird, ist schon komisch ...

Für die Verbindung seit 14:38:04 (Phase1 schon 4 Sekunden früher, falls das nochmal wichtig wird), wird dann um 15:26:04 Uhr offenbar ein Rekeying ausgeführt. Da in der FRITZ!Box sämtliche Nachrichten dazu fehlen, kann das eigentlich nur eine Anforderung des Shrewsoft-Clients sein. Hast Du da irgendwas eingestellt, daß der nach 48 Minuten einen neuen Schlüssel benutzt? Das paßt so überhaupt nicht zu irgendwelchen bekannten Macken der FRITZ!Box. :gruebel:

Aber das klappt ja offenbar sogar noch ... denn es wird ja eine neue SA erzeugt, leider wird bei der FRITZ!Box der SPI der neuen SA nicht angezeigt, daher sieht man nicht, wann die mit FreeIPsecSA wieder freigegeben wird. Und spätestens hier bräuchte man jetzt wieder die Information, ob mit dieser neuen SA die Verbindung noch funktioniert, auch wenn man Daten darüber überträgt ... da wäre ein regelmäßiges Ping jetzt hilfreich. Wenn das doch nur mal jemand vorgeschlagen hätte ...

Egal ... um 15:38:00 wird dann jedenfalls die FRITZ!Box selbst aktiv (3600 Sekunden nach Phase1) und will die SA 2 (um 14:38:00 erzeugt, wie im Log steht) löschen. Nun weiß ich nicht, wie der avmike da zählt und was für ihn eine SA tatsächlich ist ... bei IPSec wird in der Regel für jede Richtung ein eigener Schlüssel verwendet (kann man in meinem 'racoon'-Log genauer sehen). Ich vermute mal, bei AVM laufen die beiden Schlüssel unter einer gemeinsamen SA-"Nummer". Jedenfalls werden um 15:38:03 ja dann genau zwei SPI (Security Parameter Index, eine Art Selektor für eine SA, in Kombination mit der IP-Adresse) gelöscht. Aus dem unterschiedlichen iotyp-Parameter würde ich auch auf "ausgehend" und "eingehend" tippen, keine Ahnung, wer wer ist.

Damit ist - nach meinem Verständnis - die Verbindung tot ... der avmike hat wohl die aktive SA gelöscht. Eigentlich gibt es ja tatsächlich zwei SA für eine IPSec-VPN-Verbindung ... eine für das Absichern von Phase2 (ISAKMP), die in Phase1 (IKE) ausgehandelt wurde und eine für den tatsächlichen Datenverkehr (ESP), die in Phase2 (eben ISAKMP) ausgekegelt wird. Im AVM-Log wird die ISAKMP-SA wohl über die "avmike:mainmode [verbindung]: add SA [n]"-Meldungen protokolliert und die für die Verschlüsselung des Payloads mit den "cb_sa_created"-Meldungen. Der AVM-Daemon löscht also nach 3600 Sekunden die SA für ISAKMP ... und ich würde fast wetten, implizit eben auch die SA für den Datentransfer.

Ab hier wird es aber erst richtig merkwürdig, wenn man Deine früheren Beschreibungen zugrunde legt. Denn offenbar kriegt es jetzt der Shrewsoft-Client per DPD (wir hatten am Beginn dafür 16-17 Sekunden-Intervalle, jetzt sind es schon 26 Sekunden?) mit, daß da nichts mehr geht und startet jetzt von sich aus erneut Phase1 (um 15:38:29), dabei bleibt aber der Port identisch, was mit einiger Sicherheit darauf hinweist, daß das tatsächlich automatisch erfolgte. Phase2 braucht dann wieder die schon bekannten 4 Sekunden (sind ja auch elend viele Vorschläge, die da zu untersuchen sind) und dann steht tatsächlich wieder eine Verbindung (SA id=5). Und nun wird nach weiteren 26 Sekunden dann ein Paket empfangen, das nicht entschlüsselt werden kann (das "fehlerhafte Paketlänge" resultiert mit einiger Sicherheit daraus) und dann löscht der avmike von sich aus sofort wieder die frische SA (ebenfalls id=5, wie man am Log-Eintrag der Callback-Funktion erkennen kann). Dann schmeißt er die ISAKMP-SA (Nr. 3) auch gleich noch weg und entsorgt - so interpretiere ich das "del_neighbour" - die komplette Verbindung, weil keine SA für ISAKMP mehr existiert ("set canceld = TRUE"). Jedenfalls fliegen jetzt auch die ESP-SAs mit den IDs 4 (von 15:26:04, noch mit der ISAKMP-SA Nr. 2 ausgehandelt) und 5 (von 15:38:33, mit ISAKMP-SA 3) wieder weg und damit ist erst mal Schicht im Schacht.

Für mich wird das Paket um 15:38:59 von der FRITZ!Box fälschlicherweise mit der SA 4 entschlüsselt, was schief geht, weil der Shrewsoft-Client wahrscheinlich schon mit der SA 5 von 15:38:33 verschlüsselt. Das würde allerdings wieder heißen, daß da tatsächlich zu einem Zeitpunkt zwei ESP-SA auch auf der FRITZ!Box existieren. Allerdings sollte nach meinem Verständnis die FRITZ!Box dann auch beide "probieren", wenn es mit der ersten nicht klappt. Stattdessen werden die Bürgersteige hochgeklappt und wohl einseitig die Freundschaft aufgekündigt. Hier stellt sich für mich dann der Shrewsoft-Client aber etwas glatt an ... der ist jetzt offenbar eingeschnappt. Ansonsten sollte er ja (DPD ist doch hoffentlich immer noch an?) feststellen, daß da keine Daten mehr drüber gehen und tatsächlich noch einmal mit Phase1 beginnen.

Das einzig Spannende ist es da für mich, was denn nun mit Traffic in den 26 Sekunden zwischen 15:38:33 und 15:38:59 passieren würde ... theoretisch sollte da jedes Paket ebenfalls schon für "ungültige Länge"-Fehler sorgen. Dann wäre die Frage, ob die Reaktion der FRITZ!Box (alles einreißen, was da noch steht) auch erst nach 26 Sekunden (Wie kommt es überhaupt von 16-17 Sekunden zu 26 Sekunden? Wäre das doch bloß ein Neustart des Shrewsoft-Clients gewesen, mit dem da begonnen wurde ...) eintritt oder schon früher bei anderen Paketen. Hätte Dich doch bloß jemand gebeten, da auch Traffic über die VPN-Verbindung zu schicken, wenn der Zeitpunkt des Fehlers sich nähert ... ich komme mir - eingangs schon bemerkt - etwas blöd vor, wenn ich immer wieder an solchen Stellen darauf verweisen muß, wie es besser gewesen wäre. Das hat schon seinen Grund, wenn ich solche Vorschläge mache ... das ist keine Beschäftigungstherapie. Es mag zwar sein, daß sich am Ende für Dein Problem keine Lösung fndet, aber pure Neugierde ist es eben auch nicht und ich wende mich nach solchen Bitten auch nicht schulterzuckend ab nach dem Motto: "Na wenn das so ist, kann man da auch nicht helfen.". Es kann und wird nicht immer klappen, aber ich schreibe mir ja bei so einer langen Antwort auch nicht nur einen Wolf, weil ich mit der Zeit nichts anderes anzufangen wüßte. Da gibt es definitiv spannendere Themen, wenn mich die Schreibwut packt ...

Das ist es jedenfalls in etwa, was man dem Log (mit Halbwissen und ein paar Annahmen zum avmike, da gibt es von AVM keine echten Infos) entnehmen kann ... zu einer ordentlichen Analyse gehört aber eben auch das Protokoll der Gegenseite. Hast Du überhaupt danach gesucht und es nur nicht gefunden oder hast Du den Hinweis genauso ignoriert, wie den zum Neustart für einen definierten Ausgangszustand?

In jedem Falle ist es sonderbar, was da nach 48 Minuten zum Erstellen der ESP-SA mit der ID 4 führt ... ich weiß auch, daß Du irgendwo schon mal eine Armada von Screenshots aufgefahren hattest ... ich fände allerdings eine verbale Beschreibung der wichtigen IPSec-Settings wesentlich besser als wenn ich mich da durch unscharfe Grafiken kämpfen muß. Mal sehen, ob ich das trotzdem schaffe ... Du kannst ja derweil mal klären, wo denn die 48 Minuten eingestellt sein könnten - denn das mit den Screenshots tue ich mir nur an, wenn Du definitiv versicherst, daß das 1:1 auch die Einstellungen sind, die zu dem gesamten Zeitraum des AVM-Protokolls (das wäre Sonntag 12:27 bis 18:15 Uhr) bestanden haben. Ansonsten macht das einfach keinen Sinn, wenn ich erst raten müßte, was da im oben betrachteten Zeitraum aktiv war. Das war ja noch vor #70 und insofern verstehe ich eigentlich auch überhaupt nicht, wie ein Protokoll, von dem ich Dir erst 19:40 erklärt habe, wie Du da rankommst, schon um 18:15 Uhr endet und warum Du nicht wirklich einfach mal eine saubere Umgebung zum Testen und zur anschließenden Auswertung der Ergebnisse geschaffen hast.

Fazit:

Die FRITZ!Box verhält sich sicherlich ab und an mal seltsam ... das Verhalten des Shrewsoft-Clients ist bei Dir aber eher noch seltsamer (die 48 Minuten sollten dem AVM-Log nach auf der Shrewsoft-Seite ihre Ursache haben). Mehr kann ich aus dem Log auch nicht ersehen ... ich habe mir schon etwas dabei gedacht, als ich Dich darum bat, auch nach dem Shrewsoft-Log zu suchen ... auch wenn ich nicht sicher weiß, ob es eines gibt und wenn ja, ob das erst noch irgendwo eingeschaltet werden muß. Aber dafür müßte man ja dann ohnehin wieder einen "frischen" Versuch starten und hier drehe ich mich jetzt im Kreis, die Gegend kommt mir jedenfalls bekannt vor.

Auch der AVM-Daemon dürfte seinen Anteil an der entstehenden Verwirrung haben ... ich würde ihm unterstellen, daß er die SAs für ISAKMP und ESP nicht wirklich getrennt verwaltet und mit der ISAKMP-SA auch immer die ESP-SAs entsorgt. Auch das ist geraten, aber es würde zu den Symptomen passen. So ein Zusammenhang ist nach meinem Verständnis aber eigentlich nicht gegeben und auch nicht erforderlich, wenn eine ESP-SA erst einmal existiert, braucht es die ISAKMP-SA nicht mehr, die diesen Prozess abgesichert hat - oder ich verstehe da etwas fundamental falsch. Vielleicht geht ja ohne ISAKMP-SA auch kein DPD (das läuft ja als Notify-Message im Gegensatz zu irgendwelchen anderen Keepalive-Mechanismen, aber nach meinem Verständnis auch mit der ESP-SA verschlüsselt) mehr? Selbst dann sollte es aber eigentlich möglich sein, eine neue IKE-Phase einzuläuten und wirklich von vorne zu beginnen. Blöd ist es am Ende nur, wenn da beide Seiten jeweils einen unterschiedlichen Zustand einer Verbindung annehmen, weil z.B. für die eine Seite es nur eine einzige Verbindung zur Gegenseite geben kann, während diese Gegenseite munter mehrere parallele Verbindungen und Verbindungsversuche verwaltet, die dann auf der ersten Seite alles durcheinander bringen.

Ich weiß nicht, ob es tatsächlich etwas bringt, weil der Parameter dem Namen nach auch unterschiedliche Bedeutungen haben kann ... aber ich würde es zumindest mal mit dem "always_renew" auf Seiten des avmike probieren, vielleicht kann der ja damit überredet werden, anstelle des brutalen Abbruchs einen zusätzlichen Versuch des Rekeyings zu starten? Die genaue Bedeutung ist meines Wissens nicht bekannt, es gibt nur alle möglichen Spekulationen.
 
Soweit so gut.
Verbindung steht und der komplette Internetverkehr läuft über den Tunnel.
Allerdings würde ich gern NUR bestimmte Adressen über den Tunnel routen.
Hat irgendwer eine Idee, wie das zu verwirklichen ist?
Ich habe versucht unter "Policy" (obtain topology..... abgehakt), Ip's einzugeben mit netmask 255.255.255.255.
Allerdings waren diese Adresssen danach nicht mehr zu erreichen.
any ideas?
 
Zuletzt bearbeitet:
Ich habe versucht unter "Policy" (obtain topology..... abgehakt), Ip's einzugeben mit netmask 255.255.255.255.
Allerdings waren diese Adresssen danach nicht mehr zu erreichen.
any ideas?
Da man mit dieser Beschreibung raten muß, würde ich mal sagen, daß Du den beschriebenen Eintrag mit "exclude" erzeugt hast und damit offenbar genau den vorgesehenen Zweck erreicht hast ... und ohne weitere - ohne automatische Topologie-Erkennung notwendige - Einträge erreichst Du vermutlich dann nicht nur diese Adressen nicht über den Tunnel, sondern gar keine - jedenfalls dann nicht, wenn da keine "include"-Direktiven vorhanden sind für das Remote-LAN.

Ein Trace-Log und die verbale(!) Beschreibung der Einstellungen (bzw. die Textform der Konfig-Datei) für die Site-Konfiguration wären eben nützlich, damit man mal sieht, was Du da tatsächlich machst. Ich kann nicht erkennen, wie Du das konfiguriert hast.

Aus der Beschreibung
Verbindung steht und der komplette Internetverkehr läuft über den Tunnel.
Allerdings würde ich gern NUR bestimmte Adressen über den Tunnel routen.
kann man das nicht entnehmen.

Einerseits läuft der komplette Internetverkehr über den Tunnel (da wird für mich überhaupt nicht klar, ob das nun ein erwünschter oder ein unerwünschter Effekt ist) und andererseits sollen "NUR bestimmte" Adressen über den Tunnel kontaktiert werden (was den Schluß "unerwüscht" zwar nahelegt, aber ihn noch lange nicht zwingend erscheinen läßt). Theoretisch wird ja in #1 genau beschrieben, wie man entweder eine Konfiguration für ein einzelnes Netz oder für den gesamten Verkehr über den Tunnel erstellt, welche Variante hast Du denn dort gewählt?

Auch der zweite oben zitierte Satz ist nicht schlüssig ... sind das nun Adressen im LAN des VPN-Servers (vermutlich einer FRITZ!Box (welcher, welche Firmware), denn die ist ja Thema hier) und Du willst nur einige LAN-Adressen selektiv über den Server zugänglich machen anstelle des gesamten LANs der FRITZ!Box oder soll am Ende die FRITZ!Box als "Proxy" beim Zugriff auf "NUR bestimmte Adressen" dienen und damit sind in der Tat öffentliche IP-Adressen gemeint?

Wenn das Tunneln sämtlichen Verkehrs eher ein unerwünschtes Verhalten ist, hilft vielleicht ein Zitat aus der Hilfe zum Shrewsoft-Client:
Automatic Configuration

When a remote gateway is configured to support the Configuration Exchange, it provides a list of networks that are accessible via VPN Client Gateway. This network topology information, along with the client address are used to describe the security policies for this site configuration. When Automatic Policy Configuration is enabled but the remote Gateway does not supply topology information, the VPN Client will install a default policy that tunnels all traffic to the Gateway. The default value for this setting is Enabled.
Meines Wissens (ich benutze den Shrewsoft-Client aber nicht aktiv, nur zum Nachstellen von Problemen) übermittelt die FRITZ!Box solche Informationen eben nicht. Damit stellt sich die Frage, welche Konfiguration da der VPN-Verbindung zugewiesen wird (ob das überhaupt automatisch erfolgt oder ob Du da manuelle Einträge vorgenommen hast, ist eigentlich noch eine Frage zuvor) und wie die automatisch installierten Policies (die legen ja fest, was in den Tunnel wandert und was nicht) bei Dir aussehen und was den Unterschied bei der manuellen Konfiguration ausmacht (also welche Adressen mit welchen Anweisungen ein- oder ausgeschlossen werden, der Beschreibung nach würde ich ja tippen, daß Du das mit dem GUI konfiguriert hast). All das sollte (bei entsprechendem Log-Level) auch in der Trace-Datei stehen.

BTW: Hat das hier irgendwas mit dem "Ubuntu-Client-Problem" und der Trennung nach 55 Minuten (es sind in der Tat eher 54 Minuten) zu tun? Wenn das so sein sollte, solltest Du auch in dem anderen Thread erwähnen, daß es um den Shrewsoft-Client geht und nicht um den (meines Wissens bei Ubuntu ins GUI integrierten) vpnc.

Wenn das tatsächlich unabhängige Fragen/Probleme sind, solltest Du Dich zunächst mal auf eines der beiden konzentrieren und sie Stück für Stück nacheinander lösen (meine Meinung und nur dadurch begründet, daß sich Lösungen/Tests von Lösungen ins Gehege kommen könnten).

In beiden Fällen dürfen wir aber davon ausgehen, daß Du nur bei einem FRITZ!Box-Benutzer die Option für den VPN-Zugriff im FRITZ!Box-GUI freigeschaltet und sonst keine eigenen Änderungen an der VPN-Konfiguration der FRITZ!Box vorgenommen hast? Das ist insofern interessant, als daß natürlich die Phase2-Einstellungen hier einen Einfluß auf die Konfiguration der Adressen/des Routings (auch wenn es eigentlich keines ist) haben, denn im oben zitierten Auszug aus dem Shrewsoft-Handbuch heißt es ja "network topology information, along with the client address are used to describe the security policies for this site configuration.".
 
Verbindung steht und der komplette Internetverkehr läuft über den Tunnel.
Allerdings würde ich gern NUR bestimmte Adressen über den Tunnel routen.
ShrewSoft kann in der aktuellen freien Version 2.2.2 quasi nur den Modus "tunnel all" zu- oder abschalten, wobei beim letzteren dann (nur) noch direkt IP-Adressen aus dem Zielnetz angesprochen werden können, was ich immer per HOSTS-Datei einrichte. Die Pro-Version für rund $20 enthält das nötige komfortablere Feature "Split DNS Domain List"
 
... Die Pro-Version für rund $20 enthält das nötige komfortablere Feature "Split DNS Domain List"

OK, das wusste ich nicht, da brauche ich dann nicht weiter zu probieren.
EDIT: Nein das ist es leider auch nicht, gerade mit der Pro (Trial) getestet.
Enable Split DNS support if you would like to selectively send DNS requests to a tunnel specific DNS server

soll am Ende die FRITZ!Box als "Proxy" beim Zugriff auf "NUR bestimmte Adressen" dienen und damit sind in der Tat öffentliche IP-Adressen gemeint?
Genau, es soll das entfernte LAN erreicht werden (funktioniert) und einige öffentliche IP's (hier funktioniert nur alles oder nichts).

würde ich mal sagen, daß Du den beschriebenen Eintrag mit "exclude" erzeugt hast
Mit include selbstverständlich (Hier im Beispiel ist es die URL von whatsmyip.org)
5610e7f598e5f8ef882c24e66dea9680.png

BTW: Hat das hier irgendwas mit dem "Ubuntu-Client-Problem" und der Trennung nach 55 Minuten (es sind in der Tat eher 54 Minuten)
Nein, sind zwei unterschiedliche Baustellen.
W7/Shrew und Ubuntu/integrierter vpnc (und zusätzlich Android/vpncilla, alle drei Kombis haben das 54 Minuten Problem)

In beiden Fällen dürfen wir aber davon ausgehen, daß Du nur bei einem FRITZ!Box-Benutzer die Option für den VPN-Zugriff im FRITZ!Box-GUI freigeschaltet und sonst keine eigenen Änderungen an der VPN-Konfiguration der FRITZ!Box vorgenommen hast?
Korrekt.
Hardware ist eine 7360 mit Fritz OS 6.20

So, genug zitiert für heute..;)
 
Zuletzt bearbeitet:
Hallo zusammen,

ich nutze eine FB 6360 und möchte meinem Netbook und meinem Android Handy über VPN die Möglicheit geben, sicher von der Ferne zu Hause zuzugreifen.

Mit dem Handy habe ich das relativ schnell hinbekommen, und hier einen entsprechenden Account angelegt. Nun würde ich gerne mit dem gleichen (!) Account auch vom Laptop zugreifen (nicht gleichzeitig!). Da die Vorgehensweise hier anders ist (nämlich mit dem AVM Tool "Fritzbox-Fernzugang einrichten" habe ich das ganze erst mal gelassen, und versuche es nach der Anleitung hier. Leider verbindet sich mein Netbook (über O2-Wlan-Hotspot testweise) mit dem Heimnetz, aber ich bekomme leider gar keine Daten durch das Netz. Wenn ich einstelle, dass nicht der komplette Verkehr über das VPN gehen soll (sondern nur der Verkehr zum Heimnetz), geht wenigstens Internet - aber das ist ja nicht Sinn der Sache.
Kann mir jemand eine Hilfestellung geben? Meine Konfig ist im Anhang. Ich habe eigentlich alles streng nach Anleitung gemacht - zumindest so wie ich es beurteile.

Gruß
ThePhantom
 

Anhänge

  • vpnuser_Anonym.vpn.txt
    1.2 KB · Aufrufe: 8
  • fritzbox_Anonym.cfg.txt
    1.5 KB · Aufrufe: 10
Bist Du sicher, daß der Tunnel erfolgreich aufgebaut wird?

Schalte einfach mal am Shrewsoft-Client auf volles Debug-Trace und schau dort noch einmal nach.

Die Angabe 6360 ist auch etwas schmal, es gab/gibt bekannte VPN-Probleme beim Routing mit einer 06.0irgendwas, das ist schon wieder sehr lange her (ca. 1 1/2 Jahre).

Wenn der Tunnel doch aus irgendeinem Grund nicht aufgebaut wird (das siehst Du ja dann im Trace-Log auf dem PC), kannst Du auch mal AES128 anstelle von AES256 versuchen ... irgendwo war da mal was mit der 256-Bit-Variante (eben verdammt lange her).

Ansonsten wären zur Fehlersuche das erwähnte Trace-Log und aus der FRITZ!Box die /var/tmp/ike.log - die findest Du in den Support-Daten, wenn Du dort keinen Telnet-Zugang hast - hilfreich. An der Konfiguration kann ich (vielleicht ja jemand anderes?) nichts auffälliges sehen.
 
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.