LAN - LAN Kopplung zw. 1711 und 1722

Forum zum Thema allgemeinen Fragen zu VPN

Moderator: Lancom-Systems Moderatoren

Antworten
Thomas [NU]
Beiträge: 30
Registriert: 05 Jun 2008, 14:31

LAN - LAN Kopplung zw. 1711 und 1722

Beitrag von Thomas [NU] »

Hallo allerseits,

ich versuche verzweifelt eine LAN-LAN Kopplung über VPN zwischen einem Lancom 1711 (FW 7.54) und einem Lancom 1722 (FW 8.50) aufzubauen.

Der Aufbau bricht aber bereits bei Phase 1 ab. Am 1722, der die Verbindung aufbauen soll, kommt ein Timeout.

Beide Router haben auflösbare Adressen.

Der 1711 steht auf 'kein dynamisches VPN', der 1722 auf 'dynamisches VPN', so wie es halt die Assistenten einrichten.

Versuchsweise habe ich den 1722 auch schon auf 'kein dynamisches VPN' gestellt. Aber derselbe Effekt.

Andererseits muss die Kopplung über VPN doch funktionieren...

Wer hat Tips für mich?

Viele Grüße
Thomas
Benutzeravatar
ft2002
Beiträge: 441
Registriert: 10 Feb 2010, 20:45
Wohnort: Hamburg

Beitrag von ft2002 »

Hallo Thomas.

Du hast es mit dem Assi eingerichtet und es funktioniert nicht ...
Sehr komisch :shock:

kanst Du mal einen Trace machen auf VPN , alles ab dem ersten Error wird Interresant . Bitte den Trace auf dem annehmenden Router machen .
Also da wo nicht 9999 Haltezeit steht .

Welches Dynamic-VPN ist den ausgewählt ?
Hast Du getestet ob beide Router über WAN, also per DYNDNS erreichbar waren ?
Ich denke die Frage ist überflüssig aber , es sind verschiedene IP-Kreise in den beiden Routern ?

Gruss ... 8)
Thomas [NU]
Beiträge: 30
Registriert: 05 Jun 2008, 14:31

Beitrag von Thomas [NU] »

Moin, moin,

sorry, daß ich so lange habe auf mich warten lassen. Lag etwas auf der Nase.

Ich hatte zwar auch schon andere Fehlermeldungen, aber hier die derzeit aktuellen:

Annehmende Seite:

Code: Alles auswählen

[VPN-Status] 2012/03/20 08:56:42,390  Devicetime: 2012/03/20 08:54:21,880
IKE info: The remote server 87.179.193.134:500 peer def-main-peer id <no_id> is Enigmatec IPSEC version 1.5.1
IKE info: The remote server 87.179.193.134:500 peer def-main-peer id <no_id> supports NAT-T in mode draft
IKE info: The remote server 87.179.193.134:500 peer def-main-peer id <no_id> supports NAT-T in mode draft
IKE info: The remote server 87.179.193.134:500 peer def-main-peer id <no_id> supports NAT-T in mode rfc
IKE info: The remote server 87.179.193.134:500 peer def-main-peer id <no_id> negotiated rfc-3706-dead-peer-detection

[VPN-Status] 2012/03/20 08:56:42,625  Devicetime: 2012/03/20 08:54:21,890
IKE info: phase-1 proposal failed: remote No 1 authentication method = preshared key <-> local No 1 authentication method = RSA_SIG
IKE info: phase-1 proposal failed: remote No 1 hash algorithm = MD5 <-> local No 2 hash algorithm = SHA
IKE info: phase-1 proposal failed: remote No 1 encryption algorithm = AES_CBC <-> local No 3 encryption algorithm = BLOWFISH_CBC
IKE info: phase-1 proposal failed: remote No 1 encryption algorithm = AES_CBC <-> local No 4 encryption algorithm = BLOWFISH_CBC
IKE info: phase-1 proposal failed: remote No 1 encryption algorithm = AES_CBC <-> local No 5 encryption algorithm = CAST_CBC
IKE info: phase-1 proposal failed: remote No 1 encryption algorithm = AES_CBC <-> local No 6 encryption algorithm = CAST_CBC
IKE info: phase-1 proposal failed: remote No 1 encryption algorithm = AES_CBC <-> local No 7 encryption algorithm = 3DES_CBC
IKE info: phase-1 proposal failed: remote No 1 encryption algorithm = AES_CBC <-> local No 8 encryption algorithm = 3DES_CBC
IKE info: Phase-1 remote proposal 1 failed for peer def-main-peer
IKE info: phase-1 proposal failed: remote No 2 hash algorithm = SHA <-> local No 1 hash algorithm = MD5
IKE info: phase-1 proposal failed: remote No 2 authentication method = preshared key <-> local No 2 authentication method = RSA_SIG
IKE info: phase-1 proposal failed: remote No 2 encryption algorithm = AES_CBC <-> local No 3 encryption algorithm = BLOWFISH_CBC
IKE info: phase-1 proposal failed: remote No 2 encryption algorithm = AES_CBC <-> local No 4 encryption algorithm = BLOWFISH_CBC
IKE info: phase-1 proposal failed: remote No 2 encryption algorithm = AES_CBC <-> local No 5 encryption algorithm = CAST_CBC
IKE info: phase-1 proposal failed: remote No 2 encryption algorithm = AES_CBC <-> local No 6 encryption algorithm = CAST_CBC
IKE info: phase-1 proposal failed: remote No 2 encryption algorithm = AES_CBC <-> local No 7 encryption algorithm = 3DES_CBC
IKE info: phase-1 proposal failed: remote No 2 encryption algorithm = AES_CBC <-> local No 8 encryption algorithm = 3DES_CBC
IKE info: Phase-1 remote proposal 2 failed for peer def-main-peer
IKE info: phase-1 proposal failed: remote No 3 encryption algorithm = BLOWFISH_CBC <-> local No 1 encryption algorithm = AES_CBC
IKE info: phase-1 proposal failed: remote No 3 encryption algorithm = BLOWFISH_CBC <-> local No 2 encryption algorithm = AES_CBC
IKE info: phase-1 proposal failed: remote No 3 authentication method = preshared key <-> local No 3 authentication method = RSA_SIG
IKE info: phase-1 proposal failed: remote No 3 hash algorithm = MD5 <-> local No 4 hash algorithm = SHA
IKE info: phase-1 proposal failed: remote No 3 encryption algorithm = BLOWFISH_CBC <-> local No 5 encryption algorithm = CAST_CBC
IKE info: phase-1 proposal failed: remote No 3 encryption algorithm = BLOWFISH_CBC <-> local No 6 encryption algorithm = CAST_CBC
IKE info: phase-1 proposal failed: remote No 3 encryption algorithm = BLOWFISH_CBC <-> local No 7 encryption algorithm = 3DES_CBC
IKE info: phase-1 proposal failed: remote No 3 encryption algorithm = BLOWFISH_CBC <-> local No 8 encryption algorithm = 3DES_CBC
IKE info: Phase-1 remote proposal 3 failed for peer def-main-peer
IKE info: phase-1 proposal failed: remote No 4 encryption algorithm = BLOWFISH_CBC <-> local No 1 encryption algorithm = AES_CBC
IKE info: phase-1 proposal failed: remote No 4 encryption algorithm = BLOWFISH_CBC <-> local No 2 encryption algorithm = AES_CBC
IKE info: phase-1 proposal failed: remote No 4 hash algorithm = SHA <-> local No 3 hash algorithm = MD5
IKE info: phase-1 proposal failed: remote No 4 authentication method = preshared key <-> local No 4 authentication method = RSA_SIG
IKE info: phase-1 proposal failed: remote No 4 encryption algorithm = BLOWFISH_CBC <-> local No 5 encryption algorithm = CAST_CBC
IKE info: phase-1 proposal failed: remote No 4 encryption algorithm = BLOWFISH_CBC <-> local No 6 encryption algorithm = CAST_CBC
IKE info: phase-1 proposal failed: remote No 4 encryption algorithm = BLOWFISH_CBC <-> local No 7 encryption algorithm = 3DES_CBC
IKE info: ph

Der Witz dabei: Ich habe die Proposals auf beiden Seiten zig fach verglichen. Die stimmen absolut überein. Jedenfalls in Lanconfig.

Abgehende Seite:


[/code]
[VPN-Status] 2012/03/20 08:57:11,500 Devicetime: 2012/03/20 08:54:50,060
VPN: Error: IFC-I-Connection-timeout-IKE-IPSEC (0x1106) for LANCOM1711

Code: Alles auswählen


Der 1722 verwendet Dynamic VPN V2. Versuchsweise habe ich auch schon die FW8.00 installiert und die Verwendung von DynVPN V1 freigegeben. Da kommt dann manchmal kurzzeitig eine Verbindung zustande, die jedoch nach ein paar Sekunden wieder gekappt wird. Trace dazu fehlt mir noch.

Auch noch intreressant: Die ganze VPN Kopplung lief ja schon mal. Zunächst zwischen zwei 1711 und dann zwischen dem 1711 und dem 1722. Damals allerdings noch mit FW 7.5x auf dem 1722.

Und ja: beide Seiten sind auflösbar.

Viele Grüße
Thomas
backslash
Moderator
Moderator
Beiträge: 7129
Registriert: 08 Nov 2004, 21:26
Wohnort: Aachen

Beitrag von backslash »

Hi Thomas [NU]

die Annehmende Seite weiss nicht, "wer" da im Main-Mode reinkommt und nimmt daher das Default IKE-Proposal für Main-Mode-Verbindungen - und das erwartet Zertifikate (RSA_SIG), da Main-Mode-Verbindungen, die von unbekannten IP-Adressen kommen nur mit Zertifikaten funktionieren.

Die Abgehende Seite will aber Main-Mode mit preshared Key machen...

Du mußt dafür sorgen, daß auf beiden Seiten die (korrekten) IP-Adresse des jeweils anderen bekannt ist (sei es über dynDns oder dynamic-VPN) oder aber auf Zertifikate oder den Aggressive-Mode wechseln.

Vom Aggressive-Mode kann ich nur abraten, weil er quasi "offline" angreifbar ist.

Der 1722 verwendet Dynamic VPN V2. Versuchsweise habe ich auch schon die FW8.00 installiert und die Verwendung von DynVPN V1 freigegeben. Da kommt dann manchmal kurzzeitig eine Verbindung zustande, die jedoch nach ein paar Sekunden wieder gekappt wird. Trace dazu fehlt mir noch.
Wenn dynamic VPN V1 funktioniert und dynamic VPN V2 nicht, dann hast du einen Fehler in der PPP-Tabelle - hier müssen "Gegenstelle" und "Benutzername" kreuzweise übereinstimmen (der Benutzername der einen Seite ist der Gegenstellen-Name auf der anderen - und umgekehrt)


Gruß
Backslash
Antworten