Zweites Phase 2 für bestehende VPN Verbindung einrichten
Moderator: Lancom-Systems Moderatoren
Zweites Phase 2 für bestehende VPN Verbindung einrichten
Guten Morgen liebe Forum Gemeinde,
ich schlage mich seit ein paar Tagen mit der Einrichtung einer weiteren Phase 2 für eine bestehende VPN Verbindung auf einem 1781EF herum.
Der Aufbau hier vor Ort sieht folgendermaßen aus:
Lancom1781EF mit 3 WAN Verbindungen und Policy Based routing.
1 Wan Verbindung T-VDSL 25Mbit mit fester IP
1 Wan Verbindung Congstar DSL 16Mbit mit dynamischer IP
1 Wan Verbindung QSC SDSL 2Mbit mit fester IP
Zu einem unserer Partner ist bereits eine VPN LAN:LAN Kopplung über die QSC Standleitung realisiert und funktioniert auch einwandfrei.
Ich habe jetzt von unserem Partner ein weiteres Phase 2 bekommen um eine Verbindung zu einem weiteren Server herzustellen (nur per VPN erreichbar). Dazu hat er mir folgende Daten zukommen lassen:
bestehendes Phase1 VPN: 83.236.134.18 zur 83.125.118.5
dazu ein neues Phase2:
Quelle - 192.168.100.0/24
Ziel - 172.29.5.92
Ich bin leider nicht der Ultra VPN Experte, aber würde aus diesen Daten herauslesen, dass eine weitere Netzbeziehung zu der IP 172.29.5.92 hergestellt werden muss, richtig? Dazu würde dann der Lancom, sofern ich eine Route und eine entsprechende VPN Firewallregel einrichte über die bestehende Verbindung eine weitere SA (Netzbeziehung) generieren. Ist das soweit korrekt?
Achso, kurz noch zur Info: die 83.236.134.18 ist die öffentliche IP der QSC Leitung unseres Lancoms und die 83.125.118.5 die der Gegenstelle. Die 192.168.100.0/24 ist unser interner IP Bereich und die 172.29.5.92 ist der Server auf den zugegriffen werden soll.
Ich habe bereits eine Route zur 172.29.5.92 erstellt und dort als Router die Gegenstelle (83.236.134.18) eingetragen.
Eine Firewall Regel mit Quelle unseren internen IP Bereich und Ziel den Server der anderen Seite habe ich auch bereits erstellt.
Leider überträgt der Router aber keine Pakete über den VPN Tunnel.
Die Netzbeziehung scheinen korrekt zu sein und ein VPN Trace zeigt keinerlei Fehler.
Ein weiterer Einfall ist mir selbst schon gekommen: Ist es zwingend erforderlich die Netzadresse der Gegenseite als Route zu setzen, anstatt der Ziel IP? Dann hätte mir ja der Admin der Gegenseite unzureichende Daten geschickt, da ich nur die IP Adresse des Servers habe.
Kann vielleicht jemand von euch Licht ins Dunkel bringen?
Danke im vorraus. Bei Bedarf stelle ich gerne noch Screenshots oder Logs rein.
Gruß und noch frohes Schaffen
JohnDoe83
ich schlage mich seit ein paar Tagen mit der Einrichtung einer weiteren Phase 2 für eine bestehende VPN Verbindung auf einem 1781EF herum.
Der Aufbau hier vor Ort sieht folgendermaßen aus:
Lancom1781EF mit 3 WAN Verbindungen und Policy Based routing.
1 Wan Verbindung T-VDSL 25Mbit mit fester IP
1 Wan Verbindung Congstar DSL 16Mbit mit dynamischer IP
1 Wan Verbindung QSC SDSL 2Mbit mit fester IP
Zu einem unserer Partner ist bereits eine VPN LAN:LAN Kopplung über die QSC Standleitung realisiert und funktioniert auch einwandfrei.
Ich habe jetzt von unserem Partner ein weiteres Phase 2 bekommen um eine Verbindung zu einem weiteren Server herzustellen (nur per VPN erreichbar). Dazu hat er mir folgende Daten zukommen lassen:
bestehendes Phase1 VPN: 83.236.134.18 zur 83.125.118.5
dazu ein neues Phase2:
Quelle - 192.168.100.0/24
Ziel - 172.29.5.92
Ich bin leider nicht der Ultra VPN Experte, aber würde aus diesen Daten herauslesen, dass eine weitere Netzbeziehung zu der IP 172.29.5.92 hergestellt werden muss, richtig? Dazu würde dann der Lancom, sofern ich eine Route und eine entsprechende VPN Firewallregel einrichte über die bestehende Verbindung eine weitere SA (Netzbeziehung) generieren. Ist das soweit korrekt?
Achso, kurz noch zur Info: die 83.236.134.18 ist die öffentliche IP der QSC Leitung unseres Lancoms und die 83.125.118.5 die der Gegenstelle. Die 192.168.100.0/24 ist unser interner IP Bereich und die 172.29.5.92 ist der Server auf den zugegriffen werden soll.
Ich habe bereits eine Route zur 172.29.5.92 erstellt und dort als Router die Gegenstelle (83.236.134.18) eingetragen.
Eine Firewall Regel mit Quelle unseren internen IP Bereich und Ziel den Server der anderen Seite habe ich auch bereits erstellt.
Leider überträgt der Router aber keine Pakete über den VPN Tunnel.
Die Netzbeziehung scheinen korrekt zu sein und ein VPN Trace zeigt keinerlei Fehler.
Ein weiterer Einfall ist mir selbst schon gekommen: Ist es zwingend erforderlich die Netzadresse der Gegenseite als Route zu setzen, anstatt der Ziel IP? Dann hätte mir ja der Admin der Gegenseite unzureichende Daten geschickt, da ich nur die IP Adresse des Servers habe.
Kann vielleicht jemand von euch Licht ins Dunkel bringen?
Danke im vorraus. Bei Bedarf stelle ich gerne noch Screenshots oder Logs rein.
Gruß und noch frohes Schaffen
JohnDoe83
Hi JohnDoe83
Die VPN-Firewallregel kannst du dir sparen, solange du an der VPN-Verbindung die "automatische Regelerzeugung" aktiv hast.
Gruß
Backslash
ja...Dazu würde dann der Lancom, sofern ich eine Route und eine entsprechende VPN Firewallregel einrichte über die bestehende Verbindung eine weitere SA (Netzbeziehung) generieren. Ist das soweit korrekt?
Die VPN-Firewallregel kannst du dir sparen, solange du an der VPN-Verbindung die "automatische Regelerzeugung" aktiv hast.
das ist falsch. du mußt als "Router" die VPN-Verbindung eintragen - also den Namen der Verbindung, wie in der bereits bestehenden LAN-LAN-Kopplung auch.Ich habe bereits eine Route zur 172.29.5.92 erstellt und dort als Router die Gegenstelle (83.236.134.18 ) eingetragen.
Gruß
Backslash
Hey,
schonmal danke für die Antwort, ich habe jetzt im Router die VPN Verbindung ausgewählt, dennoch werden keine Pakete übertragen.
Ich habe irgendwo gelesen, dass ich die Regelerzeugung manuell machen muss, damit der LANCOM 2 SA´s pro VPN generiert. Ich sollte vielleicht dazu sagen, dass bereits eine Verbindung über den Tunnel geroutet wird, nämlich das Netz 192.168.240.0. Für dieses habe ich eine manuelle Regel eingetragen und der Datenverkehr funktioniert problemlos.
Hier mal die Ausgabe von "Show VPN":
Aus Datenschutzgründen habe ich die Uniqe ID´s unkenntlich gemacht.
Ich hoffe das hilft weiter. Meines erachtens nach sieht das doch korrekt aus?
Danke und Gruß
JohnDoe83
schonmal danke für die Antwort, ich habe jetzt im Router die VPN Verbindung ausgewählt, dennoch werden keine Pakete übertragen.
Ich habe irgendwo gelesen, dass ich die Regelerzeugung manuell machen muss, damit der LANCOM 2 SA´s pro VPN generiert. Ich sollte vielleicht dazu sagen, dass bereits eine Verbindung über den Tunnel geroutet wird, nämlich das Netz 192.168.240.0. Für dieses habe ich eine manuelle Regel eingetragen und der Datenverkehr funktioniert problemlos.
Hier mal die Ausgabe von "Show VPN":
Code: Alles auswählen
Connection #10 192.168.100.0/255.255.255.0:0 <-> 172.29.5.92/2 55.255.255.255:0 any
Name: VPN-xxxxx
Unique Id: ipsec-0-VPN-xxxxx-pr0-l0-r0
Flags: main-mode
Local Network: IPV4_ADDR_SUBNET(any:0, 192.168.100.0/255.255.25 5.0)
Local Gateway: IPV4_ADDR(any:0, 83.236.134.18)
Remote Gateway: IPV4_ADDR(any:0, 83.125.118.5)
Remote Network: IPV4_ADDR_SUBNET(any:0, 172.29.5.92/255.255.255. 255)
Connection #11 192.168.100.0/255.255.255.0:0 <-> 192.168.240.0 /255.255.248.0:0 any
Name: VPN-xxxxx
Unique Id: ipsec-1-VPN-xxxxx-pr0-l0-r0
Flags: main-mode
Local Network: IPV4_ADDR_SUBNET(any:0, 192.168.100.0/255.255.25 5.0)
Local Gateway: IPV4_ADDR(any:0, 83.236.134.18)
Remote Gateway: IPV4_ADDR(any:0, 83.125.118.5)
Remote Network: IPV4_ADDR_SUBNET(any:0, 192.168.240.0/255.255.24 8.0)
Ich hoffe das hilft weiter. Meines erachtens nach sieht das doch korrekt aus?
Danke und Gruß
JohnDoe83
Hi JohnDoe83
Mach doch mal über Telnet einen IP-Router-Trace von einem Ping in das zweite Netz, um zu schauen, wohin der Router das Paket schicken will. Es sollte es an VPN-xxxxx schicke. Wenn er das nicht macht, dann hast du einen Fehler in der Routing-Tabelle. Wenn er es macht, dann mußt du das Ping in einem VPN-Packet-Trace verfolgen
Du kannst die Traces auf bestimmte Adressen (ping-Ziel, remote Gateway) einschränken, damit du nicht den Wald vor lauter Bäumen nicht siehst...
trace # ip-router @ 172.29.5.x
trace # vpn-packet @ 172.29.5.x 83.125.118.5
das x duch die letzte stelle der angepingten Adresse ersetzen...
Gruß
Backslash
das ist nicht unbedingt nötig. Es wird erst nötig, wenn du "Sternveteilungen" hast und jeder mit jedem reden können soll....Ich habe irgendwo gelesen, dass ich die Regelerzeugung manuell machen muss, damit der LANCOM 2 SA´s pro VPN generiert.
ja, das ist korrekt.Meines erachtens nach sieht das doch korrekt aus?
Mach doch mal über Telnet einen IP-Router-Trace von einem Ping in das zweite Netz, um zu schauen, wohin der Router das Paket schicken will. Es sollte es an VPN-xxxxx schicke. Wenn er das nicht macht, dann hast du einen Fehler in der Routing-Tabelle. Wenn er es macht, dann mußt du das Ping in einem VPN-Packet-Trace verfolgen
Du kannst die Traces auf bestimmte Adressen (ping-Ziel, remote Gateway) einschränken, damit du nicht den Wald vor lauter Bäumen nicht siehst...
trace # ip-router @ 172.29.5.x
trace # vpn-packet @ 172.29.5.x 83.125.118.5
das x duch die letzte stelle der angepingten Adresse ersetzen...
Gruß
Backslash
Hey,
@Backslash, schonmal danke für deine Mühe, scheinst ein fähiger Mann zu sein
Also, ich habe die Regelerzeugung auf automatisch gestellt, was dazu führte, dass ich im LANMonitor nun den Fehler "Kein übereinstimmendes Proposal gefunde (Initiator, IPSec) [0x3102]" bekomme. Die Übertragung der Pakete für das andere Netz (das 192.168.240.0 auf der anderen Seite) funktioniert aber weiterhin, sodass dieser Fehler wohl nur die Generierung der SA zu 172.29.5.92 betrifft.
Das IP-Router trace gibt (sowohl mit manueller, als auch mit automatischer Regelerzeugung) folgendes aus:
Er routet es also anscheinend auf die Richtige VPN Verbindung.
Das VPN Paket Trace gibt (sowohl mit manueller als auch mit automatischer Regelerzeugung) folgendes aus:
Es scheint also ein Problem mit der Erzeugung der SA bzw. der Netzbeziehung zu geben, leider erschließt sich mir nicht wo dieses liegt.
Vielleicht nocheinmal meine Frage aus dem Anfangspost:
Muss ich die Netze miteinander bekannt machen, oder reicht es eine Route direkt auf die gegenüberliegende IP Adresse zu setzen, so wie ich es jetzt getan habe?
Danke und Gruß
JohnDoe83
@Backslash, schonmal danke für deine Mühe, scheinst ein fähiger Mann zu sein

Also, ich habe die Regelerzeugung auf automatisch gestellt, was dazu führte, dass ich im LANMonitor nun den Fehler "Kein übereinstimmendes Proposal gefunde (Initiator, IPSec) [0x3102]" bekomme. Die Übertragung der Pakete für das andere Netz (das 192.168.240.0 auf der anderen Seite) funktioniert aber weiterhin, sodass dieser Fehler wohl nur die Generierung der SA zu 172.29.5.92 betrifft.
Das IP-Router trace gibt (sowohl mit manueller, als auch mit automatischer Regelerzeugung) folgendes aus:
Code: Alles auswählen
[IP-Router] 2013/03/15 15:12:54,122
IP-Router Rx (LAN-1, INTRANET, RtgTag: 1):
DstIP: 172.29.5.92, SrcIP: 192.168.100.225, Len: 60, DSCP/TOS: 0x00
Prot.: ICMP (1), echo request, id: 0x0001, seq: 0x000d
Route: WAN Tx (VPN-XXXXXX)
Das VPN Paket Trace gibt (sowohl mit manueller als auch mit automatischer Regelerzeugung) folgendes aus:
Code: Alles auswählen
> trace # vpn-packet @ 172.29.5.92
VPN-Packet ON @ 172.29.5.92
root@Lancom1781EF:/
>
[VPN-Packet] 2013/03/15 15:16:04,768
for send: 192.168.100.225->172.29.5.92 60 ICMP ECHOREQUEST
-->IPv4 Header
Version : 4
Header Length : 20
Type of service : (0x00) Precedence 0
Total length : 60
ID : 30308
Fragment : Offset 0
TTL : 127
Protocol : ICMP
Checksum : 61017 (OK)
Src Address : 192.168.100.225
Dest Address : 172.29.5.92
-->ICMP Header
Msg : echo request
Checksum : 19784 (OK)
Identifier : 1
Sequence : 19
Body : 61 62 63 64 65 66 67 68 abcdefgh
69 6a 6b 6c 6d 6e 6f 70 ijklmnop
71 72 73 74 75 76 77 61 qrstuvwa
62 63 64 65 66 67 68 69 bcdefghi
[VPN-Packet] 2013/03/15 15:16:04,768
no sa available: give up, should be retransmitted: 192.168.100.225->172.29.5.92 60 ICMP ECHOREQUEST
-->IPv4 Header
Version : 4
Header Length : 20
Type of service : (0x00) Precedence 0
Total length : 60
ID : 30308
Fragment : Offset 0
TTL : 127
Protocol : ICMP
Checksum : 61017 (OK)
Src Address : 192.168.100.225
Dest Address : 172.29.5.92
-->ICMP Header
Msg : echo request
Checksum : 19784 (OK)
Identifier : 1
Sequence : 19
Body : 61 62 63 64 65 66 67 68 abcdefgh
69 6a 6b 6c 6d 6e 6f 70 ijklmnop
71 72 73 74 75 76 77 61 qrstuvwa
62 63 64 65 66 67 68 69 bcdefghi
Vielleicht nocheinmal meine Frage aus dem Anfangspost:
Muss ich die Netze miteinander bekannt machen, oder reicht es eine Route direkt auf die gegenüberliegende IP Adresse zu setzen, so wie ich es jetzt getan habe?
Danke und Gruß
JohnDoe83
Hi JohnDoe83
Eine Möglichkeit wäre, daß das LANCOM die SA als Kopplung zwischen zwei Netzen verhandelt, die Gegenseite aber - wegen der einen Adresse - die Aushandlung als Netz nich zuläßt. Hier nochmal kurz der entsprechende Ausschnitt aus deinen VPN-Regeln:
Das LANCOM übermittelt die SA mit IPV4_ADDR_SUBNET für das remote Netz. Es könnte sein, daß die Gegenseite da nur IPV4_ADDR(any:0, 172.29.5.92) zuläßt.
Du könntest versuchen, das über eine Firewallregel, zu erschlagen, die das entfernte Netz als explizite IP-Adresse enthält:
Hierfür mußt du dann aber die Regelerzeugung explizit auf "manuell" setzen
Gruß
Backslash
ja, hier scheint die Gegenseite die Aushandlung der SA abzulehnen - warum acuh immer...Also, ich habe die Regelerzeugung auf automatisch gestellt, was dazu führte, dass ich im LANMonitor nun den Fehler "Kein übereinstimmendes Proposal gefunde (Initiator, IPSec) [0x3102]" bekomme. Die Übertragung der Pakete für das andere Netz (das 192.168.240.0 auf der anderen Seite) funktioniert aber weiterhin, sodass dieser Fehler wohl nur die Generierung der SA zu 172.29.5.92 betrifft.
Eine Möglichkeit wäre, daß das LANCOM die SA als Kopplung zwischen zwei Netzen verhandelt, die Gegenseite aber - wegen der einen Adresse - die Aushandlung als Netz nich zuläßt. Hier nochmal kurz der entsprechende Ausschnitt aus deinen VPN-Regeln:
Code: Alles auswählen
Connection #10 192.168.100.0/255.255.255.0:0 <-> 172.29.5.92/2 55.255.255.255:0 any
Name: VPN-xxxxx
Unique Id: ipsec-0-VPN-xxxxx-pr0-l0-r0
Flags: main-mode
Local Network: IPV4_ADDR_SUBNET(any:0, 192.168.100.0/255.255.255.0)
Local Gateway: IPV4_ADDR(any:0, 83.236.134.18)
Remote Gateway: IPV4_ADDR(any:0, 83.125.118.5)
Remote Network: IPV4_ADDR_SUBNET(any:0, 172.29.5.92/255.255.255.255)
Du könntest versuchen, das über eine Firewallregel, zu erschlagen, die das entfernte Netz als explizite IP-Adresse enthält:
Code: Alles auswählen
[x] Diese Regel wird zur Erzeugung von VPN-Regeln herangezogen
Aktion: übertragen
Quelle: 192.168.100.0/255.255.255.0 (dein lokales Netz)
Ziel: IP-Adresse 172.29.5.92
Dienste: alle Dienste
Gruß
Backslash
Hey Ho,
entschuldigt bitte, ich habe mich noch garnicht wieder zurückgemeldet. Nach einigen weiteren Versuchen die Konfiguration und Firewallregeln anzupassen wurde mir allmählich klar, dass ich eigentlich so ziemlich alle Fehler auf meiner Seite ausgeschlossen habe.
Ein erneuter Anruf bei der IT des Verbindungspartners ergab dann, dass (obwohl angeblich bereits alles kontrolliert wurde) eine falsche Diffie-Hellman -Group auf der Gegenseite eingetragen war.
Somit funktioniert nun alles perfekt und ich habe wieder einiges zur Lancom Konfiguration dazugelernt
Danke Backslash, für deine wirklich kompetente Hilfe.
Gruß JohnDoe83
entschuldigt bitte, ich habe mich noch garnicht wieder zurückgemeldet. Nach einigen weiteren Versuchen die Konfiguration und Firewallregeln anzupassen wurde mir allmählich klar, dass ich eigentlich so ziemlich alle Fehler auf meiner Seite ausgeschlossen habe.
Ein erneuter Anruf bei der IT des Verbindungspartners ergab dann, dass (obwohl angeblich bereits alles kontrolliert wurde) eine falsche Diffie-Hellman -Group auf der Gegenseite eingetragen war.
Somit funktioniert nun alles perfekt und ich habe wieder einiges zur Lancom Konfiguration dazugelernt

Danke Backslash, für deine wirklich kompetente Hilfe.
Gruß JohnDoe83