Shrew VPN und Intranator... Mal gehts, mal nicht

[Maik]

Hallo,

wir wollen bei uns gerade unsere externen Mitarbeiter via Shrew VPN mit dem Intranator/Firmennetzwerk verbinden.
Nach einiger Konfiguriererei ist mir das auch gelungen.
Also haben wir jetzt angefangen, nach und nach alle umzustellen.
Wir haben mittlerweile 12 VPN Verbindungen eingerichtet.
F�r jeden Mitarbeiter wird mit makecert ein Zertifikat erstellt und nat�rlich im Intranator hinterlegt.
Der Intranator selber hat ein Zertifikat f�r alle.

Nun kommt es dazu, dass die Verbindung mal geht und mal nicht...
Leider geht es meist nicht.
In diesem Fall steht folgendes in den logs:
Dec 15 08:26:01 intranator pluto[2678]: "C23"[10] FirmenIP:39851 #16: responding to Main Mode from unknown peer FirmenIP:39851
Dec 15 08:26:01 intranator pluto[2678]: "C23"[10] FirmenIP:39851 #16: Oakley Transform [AES_CBC (256), HMAC_MD5, MODP_3072] refused due to strict flag
Dec 15 08:26:01 intranator pluto[2678]: "C23"[10] FirmenIP:39851 #16: Oakley Transform [AES_CBC (256), HMAC_MD5, MODP_2048] refused due to strict flag
Dec 15 08:26:01 intranator pluto[2678]: "C23"[10] FirmenIP:39851 #16: Oakley Transform [AES_CBC (256), HMAC_MD5, MODP_1536] refused due to strict flag
Dec 15 08:26:01 intranator pluto[2678]: "C23"[10] FirmenIP:39851 #16: Oakley Transform [AES_CBC (256), HMAC_MD5, MODP_1024] refused due to strict flag
Dec 15 08:26:01 intranator pluto[2678]: "C23"[10] FirmenIP:39851 #16: MODP_768 is not supported. Attribute OAKLEY_GROUP_DESCRIPTION
Dec 15 08:26:01 intranator pluto[2678]: "C23"[10] FirmenIP:39851 #16: Oakley Transform [AES_CBC (256), HMAC_SHA1, MODP_3072] refused due to strict flag
Dec 15 08:26:01 intranator pluto[2678]: "C23"[10] FirmenIP:39851 #16: Oakley Transform [AES_CBC (256), HMAC_SHA1, MODP_2048] refused due to strict flag
Dec 15 08:26:01 intranator pluto[2678]: "C23"[10] FirmenIP:39851 #16: Oakley Transform [AES_CBC (256), HMAC_SHA1, MODP_1536] refused due to strict flag
Dec 15 08:26:01 intranator pluto[2678]: "C23"[10] FirmenIP:39851 #16: Oakley Transform [AES_CBC (256), HMAC_SHA1, MODP_1024] refused due to strict flag
Dec 15 08:26:01 intranator pluto[2678]: "C23"[10] FirmenIP:39851 #16: MODP_768 is not supported. Attribute OAKLEY_GROUP_DESCRIPTION
Dec 15 08:26:01 intranator pluto[2678]: "C23"[10] FirmenIP:39851 #16: Oakley Transform [AES_CBC (192), HMAC_MD5, MODP_3072] refused due to strict flag
Dec 15 08:26:01 intranator pluto[2678]: "C23"[10] FirmenIP:39851 #16: Oakley Transform [AES_CBC (192), HMAC_MD5, MODP_2048] refused due to strict flag
Dec 15 08:26:01 intranator pluto[2678]: "C23"[10] FirmenIP:39851 #16: Oakley Transform [AES_CBC (192), HMAC_MD5, MODP_1536] refused due to strict flag
Dec 15 08:26:01 intranator pluto[2678]: "C23"[10] FirmenIP:39851 #16: Oakley Transform [AES_CBC (192), HMAC_MD5, MODP_1024] refused due to strict flag
Dec 15 08:26:01 intranator pluto[2678]: "C23"[10] FirmenIP:39851 #16: MODP_768 is not supported. Attribute OAKLEY_GROUP_DESCRIPTION
Dec 15 08:26:01 intranator pluto[2678]: "C23"[10] FirmenIP:39851 #16: Oakley Transform [AES_CBC (192), HMAC_SHA1, MODP_3072] refused due to strict flag
Dec 15 08:26:01 intranator pluto[2678]: "C23"[10] FirmenIP:39851 #16: Oakley Transform [AES_CBC (192), HMAC_SHA1, MODP_2048] refused due to strict flag
Dec 15 08:26:01 intranator pluto[2678]: "C23"[10] FirmenIP:39851 #16: Oakley Transform [AES_CBC (192), HMAC_SHA1, MODP_1536] refused due to strict flag
Dec 15 08:26:01 intranator pluto[2678]: "C23"[10] FirmenIP:39851 #16: Oakley Transform [AES_CBC (192), HMAC_SHA1, MODP_1024] refused due to strict flag
Dec 15 08:26:01 intranator pluto[2678]: "C23"[10] FirmenIP:39851 #16: MODP_768 is not supported. Attribute OAKLEY_GROUP_DESCRIPTION
Dec 15 08:26:01 intranator pluto[2678]: "C23"[10] FirmenIP:39851 #16: Oakley Transform [AES_CBC (128), HMAC_MD5, MODP_3072] refused due to strict flag
Dec 15 08:26:01 intranator pluto[2678]: "C23"[10] FirmenIP:39851 #16: Oakley Transform [AES_CBC (128), HMAC_MD5, MODP_2048] refused due to strict flag
Dec 15 08:26:01 intranator pluto[2678]: "C23"[10] FirmenIP:39851 #16: Oakley Transform [AES_CBC (128), HMAC_MD5, MODP_1536] refused due to strict flag
Dec 15 08:26:01 intranator pluto[2678]: "C23"[10] FirmenIP:39851 #16: Oakley Transform [AES_CBC (128), HMAC_MD5, MODP_1024] refused due to strict flag
Dec 15 08:26:01 intranator pluto[2678]: "C23"[10] FirmenIP:39851 #16: MODP_768 is not supported. Attribute OAKLEY_GROUP_DESCRIPTION
Dec 15 08:26:01 intranator pluto[2678]: "C23"[10] FirmenIP:39851 #16: Oakley Transform [AES_CBC (128), HMAC_SHA1, MODP_3072] refused due to strict flag
Dec 15 08:26:01 intranator pluto[2678]: "C23"[10] FirmenIP:39851 #16: Oakley Transform [AES_CBC (128), HMAC_SHA1, MODP_2048] refused due to strict flag
Dec 15 08:26:01 intranator pluto[2678]: "C23"[10] FirmenIP:39851 #16: NAT-Traversal: Result using RFC 3947: peer is NATed
Dec 15 08:26:06 intranator pluto[2678]: "C23"[10] FirmenIP:39851 #16: discarding duplicate packet; already STATE_MAIN_R2
Dec 15 08:26:11 intranator pluto[2678]: "C23"[10] FirmenIP:39851 #16: discarding duplicate packet; already STATE_MAIN_R2
Dec 15 08:26:16 intranator pluto[2678]: "C23"[10] FirmenIP:39851 #16: discarding duplicate packet; already STATE_MAIN_R2


11/12/15 08:26:01 ii : processing phase1 packet ( 180 bytes )
11/12/15 08:26:01 =< : cookies 5a87770478de6cfb:446fce6bc23dd13e
11/12/15 08:26:01 =< : message 00000000
11/12/15 08:26:01 ii : matched isakmp proposal #1 transform #28
11/12/15 08:26:01 ii : - transform = ike
11/12/15 08:26:01 ii : - cipher type = aes
11/12/15 08:26:01 ii : - key length = 128 bits
11/12/15 08:26:01 ii : - hash type = sha1
11/12/15 08:26:01 ii : - dh group = modp-1536
11/12/15 08:26:01 ii : - auth type = sig-rsa
11/12/15 08:26:01 ii : - life seconds = 86400
11/12/15 08:26:01 ii : - life kbytes = 0
11/12/15 08:26:01 ii : peer is CISCO UNITY compatible
11/12/15 08:26:01 ii : peer supports XAUTH
11/12/15 08:26:01 ii : peer supports DPDv1
11/12/15 08:26:01 ii : peer supports nat-t ( rfc )
11/12/15 08:26:01 >= : cookies 5a87770478de6cfb:446fce6bc23dd13e
11/12/15 08:26:01 >= : message 00000000
11/12/15 08:26:06 -> : resend 1 phase1 packet(s) externeIP:500 -> FirmenIP:500
11/12/15 08:26:11 -> : resend 1 phase1 packet(s) externeIP:500 -> FirmenIP:500
11/12/15 08:26:16 -> : resend 1 phase1 packet(s) externeIP:500 -> FirmenIP:500
11/12/15 08:26:21 ii : resend limit exceeded for phase1 exchange
11/12/15 08:26:21 ii : phase1 removal before expire time
11/12/15 08:26:21 DB : removing tunnel config references
11/12/15 08:26:21 DB : removing tunnel phase2 references
11/12/15 08:26:21 DB : removing tunnel phase1 references
11/12/15 08:26:21 DB : removing all peer tunnel refrences
11/12/15 08:26:21 ii : ipc client process thread exit ...


Achja, die Intranatorversion ist die 5.3.12 und Shrew die 2.1.7.
Ich hab auf einem der Notebooks zum testen mal die Firewall deinstalliert und dann Shrew nochmal drauf, das bringt nix.
Der Fehler ist auch auf meinem privaten Notebook nachzuvollziehen, obwohl dort g�nzlich andere Sicherrungssoftware drauf ist.
Langsam steigt bei mir ein wenig der Frust.
Habe mich an die Anleitung gehalten und alle Einstellungen zig mal �berpr�ft...
Ich weiche in zwei Punkten von der Anleitung ab:
Verschl�sselungsprofil -> Intranator 5.3.1 mit FPS
Netz auf Gegenseite -> IP zuweisen (mode-config) ( nach Anleitung soll man hier ein freies Netz eingeben, das Bild meint aber IP zuweisen, bei mir klappt es nur so)

Bin f�r jeden Vorschlag dankbar.

Gru�
Maik

[bjoerns]

Hallo,

Ich weiche in zwei Punkten von der Anleitung ab:
Verschl�sselungsprofil -> Intranator 5.3.1 mit FPS

das Verschlüsselungsprofil "Intranator 5.3.1 mit PFS" ist aus Kompatibilitätsgründen vorhanden. Möchte man eine VPN-Verbindung zu einem Intranator mit Version 5.3.1 oder kleiner aufbauen ist dies notwendig. Sie sollten also unbedingt das Verschlüsselungsprofil auf "Standard mit PFS" umstellen.

Netz auf Gegenseite -> IP zuweisen (mode-config) ( nach Anleitung soll man hier ein freies Netz eingeben, das Bild meint aber IP zuweisen, bei mir klappt es nur so)

Das Bild bezieht sich auf den 2. Abschnitt im Handbuch:

Wählen Sie bei Netz auf Gegenseite den Typ Freies Netz. Wählen Sie eine bislang unbenutzte IP, die auch nicht in einem der Netze des Intranators oder des Clients liegt. Dies ist die virtuelle IP, die Sie auch im Client eintragen müssen. Verwenden Sie immer 255.255.255.255 als Netzmaske.

Die meisten VPN-Clients können sich ihre virtuelle IP und zugehörigen DNS-Server über die Protokollerweiterung Mode Config automatisch zuweisen lassen. Wenn ihr Client dies unterstützt (z.B. Shrew Soft, NCP oder iPhone, siehe Beschreibung der einzelnen Clients), stellen Sie die Option Netz auf Gegenseite auf IP zuweisen und tragen die IP ein, die der Client bekommen soll. Als DNS-Server übermittelt der Intranator automatisch seine eigene IP.

Wenn Sie das Verschlüsselungsprofil umgestellt haben, können Sie sich die Messages-Logdateien des Intranators live anzeigen lassen (Information->System->Logdateien). Aktivieren Sie auch das Logging im Client und starten Sie dann einen Verbindungsaufbau. Lassen Sie uns dann die beiden Logmitschnitte zukommen. Mit Logdateien von nur einer Seite ist es immer schwer zu sagen, warum die Verbindung nicht aufgebaut werden kann.

MFG Björn

[Maik]

Danke f�r die schnelle Antwort.

Die verschl�sselung habe ich auch schon auf Standard gehabt und da hab ich leider das selbe Ergebnis mit identischen logs.
Habe es auch gerade noch einmal getestet.

Ich habe Ihnen �brigens beide gepostet.
Das obere ist das Intranator-log und das untere das von Shrew

Gru�
Maik

[bjoerns]

Hallo,

Ich habe Ihnen �brigens beide gepostet.
Das obere ist das Intranator-log und das untere das von Shrew

stimmt, das ist mir als erstes gar nicht aufgefallen, da die Ausschnitte so kurz sind.

Sieht f�r mich nach einem Netzwerkproblem aus. Der Client sendet die Pakete mehrfach (resend 1 phase1 packet(s) externeIP:500 -> FirmenIP:500), beim Intranator kommen diese auch mehrfach an (discarding duplicate packet; already STATE_MAIN_R2), allerdings scheint dann die Antwort vom Intranator beim Client nicht anzukommen.

11/12/15 08:26:06 -> : resend 1 phase1 packet(s) externeIP:500 -> FirmenIP:500
11/12/15 08:26:11 -> : resend 1 phase1 packet(s) externeIP:500 -> FirmenIP:500
11/12/15 08:26:16 -> : resend 1 phase1 packet(s) externeIP:500 -> FirmenIP:500
11/12/15 08:26:21 ii : resend limit exceeded for phase1 exchange

Dec 15 08:26:06 intranator pluto[2678]: "C23"[10] FirmenIP:39851 #16: discarding duplicate packet; already STATE_MAIN_R2
Dec 15 08:26:11 intranator pluto[2678]: "C23"[10] FirmenIP:39851 #16: discarding duplicate packet; already STATE_MAIN_R2
Dec 15 08:26:16 intranator pluto[2678]: "C23"[10] FirmenIP:39851 #16: discarding duplicate packet; already STATE_MAIN_R2

Wenn die Verbindung manchmal funktioniert und manchmal nicht, k�nnte ich mir ein Problem mit der MTU vorstellen. Vielleicht wird die MTU vom Provider nicht korrekt geliefert. Testen Sie mal einen geringeren MTU Wert f�r den Provider im Intranator (Netzwerk->Provider->Profile Reiter "Einstellungen"). Standardm��ig wird meistens 1500 verwendet. Reduzieren Sie den Wert testweise z.B. auf 1200. Sie k�nnen sich dann langsam auf den maximal m�glichen Wert herantasten.

MFG Bj�rn

[Maik]

Netzwerkprobleme kann ich mir auch vorstellen.

Aber nocheinmal eine Verständnisfrage:
Kann ich die MTU einfach so wärend des laufenden Betriebes heruntersetzen, oder kann es da irgendwo krachen?
Der Intranator macht dann keinen Neustart oder sowas?

Gruß
Maik

[bjoerns]

Hallo,

Kann ich die MTU einfach so wärend des laufenden Betriebes heruntersetzen, oder kann es da irgendwo krachen?
Der Intranator macht dann keinen Neustart oder sowas?

da sich damit die Provider Konfiguration ändert, wird dieser neu verbunden. Es kann also kurz zu einem Abbruch der Internetverbindung kommen.

MFG Björn

[Maik]

Wie befürchtet ^^
Dann muss ich wohl ne Wochenendschicht einlegen.

Besten Dank und schönes Wochenende.

Gruß
Maik

[Maik]

Moin,

also nu gehts garnicht mehr.
Im log vom Intranator tauchen jetzt nicht einmal einwahlversuche auf.
Hab die MTU im Intranator f�r unseren Company Connect auf 1300 gestellt.

Gru�
Maik

[Gerd von Egidy]

Hallo,

mir sieht das ein wenig danach aus als ob die Kommunikation auf der UDP-Ebene zwischen dem Client und dem Intranator gestört wird.

Bei den ersten Logs die Sie gesendet haben gingen die Pakete vom Client zum Intranator durch, die Antwortpakete dann aber nicht mehr. Wenn jetzt im Intranator gar nichts im Log erscheint kommt dort nichts mehr an.

In diesem Fall tippe ich auf den Router vor dem Client als Ursache.

Es gibt einige Router die in diesem Bereich Schwierigkeiten haben. Bei einigen hilft ein Firmware-Update, bei anderen muss man eine auch noch auf dem Router vorhandene VPN-Funktion deaktivieren weil der Router denkt die VPN-Pakete wäre für ihn und nicht für den Client.

Haben Sie die Möglichkeit einen der Clients mit dem Problem mal hinter einem anderen Router oder mit einer UMTS-Karte zu testen?

Herzliche Grüße,

v. Egidy

[Maik]

Hallo,

ja in die Richtung hab ich auchschon gedacht.
Hab es mit 2 Routern und einem Modem probiert. Selbes Problem.
Dann hab ich die MTU von dem Client-Router auf 1300 gedreht und siehe da es geht.
Also hab ich jetzt folgende Szenarien:
Intranator MTU 1500 - Client Router 1492 -> geht manchmal (Pakete zum Intranator kommen durch, die Antwort kommt aber nicht immer zum Client)
Intranator MTU 1300 - Client Router 1492 -> geht nix (Pakete kommen nicht zum Intranator)
Intranator MTU 1300 - Client Router >=1300 -> geht

Nun ist das aber keine erstrebenswerte Lösung, dass wir bei allen unseren Mitarbeitern die MTU anpassen...
Die Einstellungen im Shrew die MTU betreffend scheinen ja keinerlei Auswirkungen zu haben.
Ich würde ja fast dazu tendieren die Intranator MTU auf 1492 zu stellen, aber das bedeutet wieder 10 min Netzwerkausfall und das kann ich maximal am We verantworten. Da is aber Weihnachten ... ^^

Gruß
Maik

[Thomas Jarosch]

Hallo,

über was für eine Zugangsart verbindet der Intranator sich mit dem Internet?
Für DSL wäre z.B. 1492 oder 1456 normal.

Herzliche Grüße,
Thomas Jarosch

[Maik]

Moin,

es ist ein Company Connect Zugang.
Da ist die MTU Standardmäßig 1500, soweit ich weis zumindest.
Der Intranator hängt hinter nem Cisco Router über den unsere Außenstellen via VPN mit uns verbunden sind.
Ist ne Telekom Lösung.

Gruß
Maik

[Gerd von Egidy]

Hallo,

es ist ein Company Connect Zugang.
Da ist die MTU Standardmäßig 1500, soweit ich weis zumindest.

Da bin ich mir nicht sicher, ich glaube eher daß das nicht einheitlich gelöst ist sondern von lokalen Gegebenheiten der Vermittlungsstelle, der Geschwindigkeit etc. abhängt.

Der Intranator hängt hinter nem Cisco Router über den unsere Außenstellen via VPN mit uns verbunden sind.

Es könnte sein daß Ihr Cisco-Router manche eingehende ICMP-Pakete blockiert. Wenn dann ein Client hinter einem Router sitzt der eine kleinere MTU hat als Ihre Leitung (z.B. 1492 wie bei ADSL) würde die Verbindung nicht funktionieren weil die Gegenseite Ihnen nicht mehr mitteilen kann daß Sie kleinere Pakete senden sollen.

Bitte setzen Sie sich mit der Telekom in Verbindung und gehen mit denen gemeinsam die Firewall-Einstellungen Ihres Cisco-Routers durch. ICMP-Pakete vom Typ "Fragmentation needed" müssen ungefiltert und für alle Verbindungstypen durchgelassen werden.

Wenn Sie dort keinen kompetenten Ansprechpartner finden können wir Ihnen auch gerne per Fernwartung helfen und versuchen das Problem genau zu diagnostizieren. Der telefonische Support mit Fernwartung ist für Endkunden bei uns allerdings kostenpflichtig.

Herzliche Grüße,

v. Egidy