Hallo zusammen,
ich ein Problem mit einer VPN Verbindung. Phase 2 schlägt fehl und ich sehe nur etwas von no rule matched ids und die Gegenseite bekommt nur no proposal chosen.
Wenn ich ich per telnet auf den Lancom 1721+vpn einwähle kann ich derzeit nur trace + vpn-status machen was mir jedoch wenig infos gibt.
Kann ich irgendwie den Debug level erhöhen bzw. wie kann ich weitere Details sehen ?
Danke und Gruß,
Sjohnson
Debuggen einer VPN Verbindung
Moderator: Lancom-Systems Moderatoren
Hi Sjohnson
Gib auf beiden Seiten mal "show vpn" ein und vergleiche die Netzbeziehungen der Verbindung... Die jeweils erreiochbaren Netze müssen auf beiden Seiten (gespiegelt) gleich sein
Gruß
Backlsash
das ist genau die Meldung, auf die es ankommt... Hier stehen die von der Gegenseite geforderten Netzbeziehungen, welche nicht zu denen in den lokalen VPN-Regeln passen.Phase 2 schlägt fehl und ich sehe nur etwas von no rule matched ids
Gib auf beiden Seiten mal "show vpn" ein und vergleiche die Netzbeziehungen der Verbindung... Die jeweils erreiochbaren Netze müssen auf beiden Seiten (gespiegelt) gleich sein
Gruß
Backlsash
hmm ok, vielleicht ist dann etwas falsch eingestellt. Vielleicht kannst du mir ja helfen.
Folgendes ist gegeben:
Standort A:
Netz: 192.168.178.0/24
- Public VPN GW IP
(Server auf den zugegriffen werden soll: 192.168.178.66)
Standort B:
VPN Netz: 172.17.9.0/16
- Public GW IP (z.B. 217.6.3.100)
- Host von dem die VPN Verbindung aufgebaut werden soll (217.6.3.111)
Standort B hat aufgrund der eigenen Nutzung des Netztes wie bei Standort A die Bedingung gestellt, das die IP des Servers auf den Zugegriffen werden soll auf die IP des VPN Netzes genattet werden soll (172.17.9.30)
So, die VPN habe ich bei Standort A wie folgt eingerichtet
- Konfigurationsmanager gestartet
- keine ISDN Verb. gewählt (beide haben feste IPs)
- Gateway von Standort B eingegeben
- Als Netz das 172... Netz und Subnetmaske angegeben
- Preshared Key genutzt
- Beiden einen Identifier gegeben (der im Nachhinein in den manuellen Einstellungen aber nirgends zu finden ist)
Anschließend habe ich die IKE Proposals geändert (eigenen angelegt) damit ich sicher gehen kann, dass bei beiden die gleichen Settings sind.
Muss ich jetzt denn nochwas weiteres einstellen? Standort B meint das Problem wäre das Standort A versucht das 192.168.178.0 Netz zuzuweisen, was jedoch nicht geht, es muss das 172... Netz genutzt werden.
Ich habe auch schon eine Route eingetragen für das 172. Netz und auch ein N:N NAT Eintrag (dass die IP 192.168.178.66 auf 172.17.9.30 umgestellt wird)
Vielleicht habe ich ja nochwas falsch?
Vielen Dank schonmal!
Folgendes ist gegeben:
Standort A:
Netz: 192.168.178.0/24
- Public VPN GW IP
(Server auf den zugegriffen werden soll: 192.168.178.66)
Standort B:
VPN Netz: 172.17.9.0/16
- Public GW IP (z.B. 217.6.3.100)
- Host von dem die VPN Verbindung aufgebaut werden soll (217.6.3.111)
Standort B hat aufgrund der eigenen Nutzung des Netztes wie bei Standort A die Bedingung gestellt, das die IP des Servers auf den Zugegriffen werden soll auf die IP des VPN Netzes genattet werden soll (172.17.9.30)
So, die VPN habe ich bei Standort A wie folgt eingerichtet
- Konfigurationsmanager gestartet
- keine ISDN Verb. gewählt (beide haben feste IPs)
- Gateway von Standort B eingegeben
- Als Netz das 172... Netz und Subnetmaske angegeben
- Preshared Key genutzt
- Beiden einen Identifier gegeben (der im Nachhinein in den manuellen Einstellungen aber nirgends zu finden ist)
Anschließend habe ich die IKE Proposals geändert (eigenen angelegt) damit ich sicher gehen kann, dass bei beiden die gleichen Settings sind.
Muss ich jetzt denn nochwas weiteres einstellen? Standort B meint das Problem wäre das Standort A versucht das 192.168.178.0 Netz zuzuweisen, was jedoch nicht geht, es muss das 172... Netz genutzt werden.
Ich habe auch schon eine Route eingetragen für das 172. Netz und auch ein N:N NAT Eintrag (dass die IP 192.168.178.66 auf 172.17.9.30 umgestellt wird)
Vielleicht habe ich ja nochwas falsch?
Vielen Dank schonmal!
Hi Sjohnson
Das geht zwar schon in die richtige Richtung führt aber zunächst nur dazu, daß Standort A zusätzlich zum 192.168.178.0/24 Netz auch noch 172.17.9.30/32 fordert...
Du mußt verhindern, daß das 192.168.178.0/24 Netz überhaupt gefordert wird. Dazu stellst du zunächst die Regelerzeugung für die VPN-Strecke auf manuell und erstellst dann in der Firewall folgende Regel:
Du mußt hier die ungenattete Adresse des Servers angeben. Bei der Erstellung der VPN-Regeln wird dann automatisch genattet...
Danach sollte ein show VPN auf Standort A folgende Netzbeziehung zeigen:
In Standort B muß nichts gemacht werden außer die Route zum Server auf den VPN-Tunnel zu legen und Proxy-ARP einzuschalten.
Ein show vpn sollte folgende Netzbeziehung ausgeben:
Gruß
Backslash
Ich hoffe du hast das in Standort A - und nur dort - eingetragen...Ich habe auch schon eine Route eingetragen für das 172. Netz und auch ein N:N NAT Eintrag (dass die IP 192.168.178.66 auf 172.17.9.30 umgestellt wird)
Das geht zwar schon in die richtige Richtung führt aber zunächst nur dazu, daß Standort A zusätzlich zum 192.168.178.0/24 Netz auch noch 172.17.9.30/32 fordert...
Du mußt verhindern, daß das 192.168.178.0/24 Netz überhaupt gefordert wird. Dazu stellst du zunächst die Regelerzeugung für die VPN-Strecke auf manuell und erstellst dann in der Firewall folgende Regel:
Code: Alles auswählen
[ ] Diese Regel ist für die Firewall aktiv
[x] Diese Regel wird zur erzeugung von VPN-Regeln herangezogen
Aktion: übertragen
Quelle: IP-Adresse 192.168.178.66 (IP des Servers)
Ziel: VPN-Gegenstelle
Dienste: alle DiensteDanach sollte ein show VPN auf Standort A folgende Netzbeziehung zeigen:
Code: Alles auswählen
Connection #1 172.17.9.30/255.255.255.255:0 <-> 172.17.9.0/255.255.0.0:0 any
(...)
Local Network: IPV4_ADDR(any:0, 172.17.9.30/255.255.255.255)
Local Gateway: IPV4_ADDR(any:0, x.x.x.x)
Remote Gateway: IPV4_ADDR(any:0, x.x.x.x)
Remote Network: IPV4_ADDR_SUBNET(any:0, 172.17.9.0/255.255.0.0)In Standort B muß nichts gemacht werden außer die Route zum Server auf den VPN-Tunnel zu legen und Proxy-ARP einzuschalten.
Ein show vpn sollte folgende Netzbeziehung ausgeben:
Code: Alles auswählen
Connection #1 172.17.9.0/255.255.0.0:0 <-> 172.17.9.30/255.255.255.255:0 any
(...)
Local Network: IPV4_ADDR_SUBNET(any:0, 172.17.9.0/255.255.0.0)
Local Gateway: IPV4_ADDR(any:0, x.x.x.x)
Remote Gateway: IPV4_ADDR(any:0, x.x.x.x)
Remote Network: IPV4_ADDR(any:0, 172.17.9.30/255.255.255.255)
Backslash
Vielen Dank für den Tipp. Das sieht schonmal besser aus 
Eine Frage. Ist die Einstellung in der Firewall so richtig (habe keine andere Möglichkeit gefunden)
Verbindungs-Quelle -> Verbindung von folgenden Stationen -> IP Netzwerk 172.17.9.0 (und 192.168.178.66)
Verbindungs-Ziel -> Verbindung an folgende Stationen -> Station TESTVPN (der Name der VPN Verbindung)
Ich hatte eher gedacht das muss genau umgekehrt sein, die Quelle ist der Client der zum Ziel will. Hier ist die Config aber genau umgekehrt, aber nur so geht es...
Danke!
Eine Frage. Ist die Einstellung in der Firewall so richtig (habe keine andere Möglichkeit gefunden)
Verbindungs-Quelle -> Verbindung von folgenden Stationen -> IP Netzwerk 172.17.9.0 (und 192.168.178.66)
Verbindungs-Ziel -> Verbindung an folgende Stationen -> Station TESTVPN (der Name der VPN Verbindung)
Ich hatte eher gedacht das muss genau umgekehrt sein, die Quelle ist der Client der zum Ziel will. Hier ist die Config aber genau umgekehrt, aber nur so geht es...
Danke!
Zuletzt geändert von Sjohnson am 25 Aug 2011, 17:12, insgesamt 1-mal geändert.
Hi Sjohnson
Verbindungs-Quelle -> Verbindung von folgenden Stationen -> eine IP-Adresse oder ein Bereich von Adressen: 192.168.178.66[/quote]
Das entfernte Netz (172.17.9.0) hat in der Regel nichts zu suchen...
Ansonsten gibt es den IP-Router-Trace und den VPN-Packet-Trace um den Lauf der Pakete zu verfolgen...
Gruß
Backslash
nicht ganz...Eine Frage. Ist die Einstellung in der Firewall so richtig (habe keine andere Möglichkeit gefunden)
Verbindungs-Quelle -> Verbindung von folgenden Stationen -> IP Netzwerk 172.17.9.0 (und 192.168.178.66)
Verbindungs-Quelle -> Verbindung von folgenden Stationen -> eine IP-Adresse oder ein Bereich von Adressen: 192.168.178.66[/quote]
Das entfernte Netz (172.17.9.0) hat in der Regel nichts zu suchen...
du pingst jetzt aus Netz B oder? Ist dort Proxy-ARP aktiviert (schließlich schiebst du ja eine IP aus dem Netz B über den VPN-Tunnel nach Netz A)?Ok, Problem ist nun. Ich kann zwar mit VPN verbinden, aber wenn ich ein ping auf die 172... IP mache kommt nichts.
Woran könnte das liegen ?
Ansonsten gibt es den IP-Router-Trace und den VPN-Packet-Trace um den Lauf der Pakete zu verfolgen...
Gruß
Backslash
Also ich bin jetzt in Netz B. Habe dort testweise erstmal einen IPsec Client genommen, darf die Router Einstellungen ersts später ändern in Netz B (Policies...)
Ein Trace(trace # icmp) gibt folgendes zurück:
[ICMP] 2011/08/25 17:26:07,520
ICMP Tx (WAN, TESTVPN): Dest-IP: 192.168.178.0: Destination unreachable (Network unreachable)
original packet:
DstIP: 172.17.9.30, SrcIP: 192.168.178.0, Len: 84, DSCP/TOS: 0x00
Prot.: ICMP (1), echo request, id: 0x3605, seq: 0x0006
Ein Trace(trace # icmp) gibt folgendes zurück:
[ICMP] 2011/08/25 17:26:07,520
ICMP Tx (WAN, TESTVPN): Dest-IP: 192.168.178.0: Destination unreachable (Network unreachable)
original packet:
DstIP: 172.17.9.30, SrcIP: 192.168.178.0, Len: 84, DSCP/TOS: 0x00
Prot.: ICMP (1), echo request, id: 0x3605, seq: 0x0006
Hi Sjohnson
Was mich nun aber wundert ist, daß in deinem Test der Client eine Adresse aus dem 192.168.178.x-Netz hat (abgesehen davon, daß .0 als Adresse sehr ungeschickt ist). Ich dachte der Server sollte ins 172.17.9.x-Netz gemappt werden - dann muß deine VPN-(Client-)Verbindung auch dazu passend sein
Ansonsten ist es völlig egal, ob du einen Client oder einen Router bei dem Test verwendest...
Gruß
Backlsash
und das hast du im Router von Netz B mitgeschnitten? Der sollte doch das 172.17.9.x-Netz kennen und somit kein "NetworK unreachable" zurückschicken. Oder arbeitest du mit virtualisierten Routern, d.h. nutzt du Routing- und Interface-Tags? Denn dann kann es sein daß die Routing-Kontexte nicht stimmen und du die VPN-Verbindung über die WAN-Tag-Tabelle (Kommunikation -> Gegenstellen -> WAN-Tag-Tabelle) in den passenden Kontext verschieben mußt.Ein Trace(trace # icmp) gibt folgendes zurück:
[ICMP] 2011/08/25 17:26:07,520
ICMP Tx (WAN, TESTVPN): Dest-IP: 192.168.178.0: Destination unreachable (Network unreachable)
original packet:
DstIP: 172.17.9.30, SrcIP: 192.168.178.0, Len: 84, DSCP/TOS: 0x00
Prot.: ICMP (1), echo request, id: 0x3605, seq: 0x0006
Was mich nun aber wundert ist, daß in deinem Test der Client eine Adresse aus dem 192.168.178.x-Netz hat (abgesehen davon, daß .0 als Adresse sehr ungeschickt ist). Ich dachte der Server sollte ins 172.17.9.x-Netz gemappt werden - dann muß deine VPN-(Client-)Verbindung auch dazu passend sein
Proxy-ARP muß im Router im Netz B aktiv sein, weil der Server hinter dem VPN-tunnel ja per N:N-NAT ins lokale Netz des Routers B (172.17.9.x) gemappt wirdGeht es eventuell mit einem Client so nicht, also muss es ein Router sein mit ProxyARP an ?
Ansonsten ist es völlig egal, ob du einen Client oder einen Router bei dem Test verwendest...
Gruß
Backlsash
Ne das hab ich in Router a mitgeschnitten, nicht b!
Ich hab das ganze dann nochmal probiert und nun bekomm ich erstmal folgendes von seite b wenn ich nach a will:
217.5.7.100.isakmp: isakmp: phase 1 I ident: [|sa]
193.5.2.248: icmp: 217.5.7.100 udp port isakmp unreachable
Und bei A steht etwas von
IKE info: Phase-1 SA removed: peer VPN30 rule VPN30 removed
und danach wird VPN30 also B disconnected
Ich hab das ganze dann nochmal probiert und nun bekomm ich erstmal folgendes von seite b wenn ich nach a will:
217.5.7.100.isakmp: isakmp: phase 1 I ident: [|sa]
193.5.2.248: icmp: 217.5.7.100 udp port isakmp unreachable
Und bei A steht etwas von
IKE info: Phase-1 SA removed: peer VPN30 rule VPN30 removed
und danach wird VPN30 also B disconnected
Ok jetzt klappt es.
Allerdings eine weitere Anforderung udn hiermit ein Problem:
Netz B stellt nun Anfragen von zwei Systemen. Die VPN Verbindung funktioniert (über die oben angegebene IP aus Netz B) Wenn jetzt ein System mit einer weiteren IP aus dem gleichen Adressebereich aus Netz B ein ping auf den Server macht geht es wieder nicht. Ich vermute die Firewalleinstellungen, die als Destination ja das VPN haben sehen nur die erste IP und lassen die zweite nicht zu.
Eine Idee?
Danke und Gruß,
WorldSignia
Allerdings eine weitere Anforderung udn hiermit ein Problem:
Netz B stellt nun Anfragen von zwei Systemen. Die VPN Verbindung funktioniert (über die oben angegebene IP aus Netz B) Wenn jetzt ein System mit einer weiteren IP aus dem gleichen Adressebereich aus Netz B ein ping auf den Server macht geht es wieder nicht. Ich vermute die Firewalleinstellungen, die als Destination ja das VPN haben sehen nur die erste IP und lassen die zweite nicht zu.
Eine Idee?
Danke und Gruß,
WorldSignia
Leider gibt es doch noch ein Problem.
Ich versuch von Netz B ein telnet auf den Server und Port zu machen, allerdings bekomme ich einen Timeout.
Ein trace auf beim Router in Netz A zeigt mir das ein Paket über die VPN Verbindung ankommt mit DstIP auf den Server und auch den korrekten Port. Allerdings steht dann da noch: Seq: eine Nummer, ACK: 0, Win: eine nummer
Heißt ACK:0 nicht das kein Paket zurück kam?
Nun habe ich vom Lancom der im Netz A steht versucht ein telnet aufzubauen und direkt kommt die Meldung Terminal session terminated.
Woran könnte das liegen? In den Firewall-Regeln habe ich telnet nirgendswo geblockt?
Vielen Dank!
Ich versuch von Netz B ein telnet auf den Server und Port zu machen, allerdings bekomme ich einen Timeout.
Ein trace auf beim Router in Netz A zeigt mir das ein Paket über die VPN Verbindung ankommt mit DstIP auf den Server und auch den korrekten Port. Allerdings steht dann da noch: Seq: eine Nummer, ACK: 0, Win: eine nummer
Heißt ACK:0 nicht das kein Paket zurück kam?
Nun habe ich vom Lancom der im Netz A steht versucht ein telnet aufzubauen und direkt kommt die Meldung Terminal session terminated.
Woran könnte das liegen? In den Firewall-Regeln habe ich telnet nirgendswo geblockt?
Vielen Dank!
Hi Sjohnson
Auf dieses Paket, muß aber vom Server eine Antwort kommen (SYN/ACK), bei dem SEQ und ACK von 0 verschiedene Werte haben. Wenn da keine Antwort kommt, dann ist das LANCOM für den Server nicht das Gateway...
Gruß
Backslash
nein... das ist nur das erste Paket einer TCP-Session (das SYN-Paket) - da ist ACK (die Aknowledge-Number) immer 0, weil die Sequenznummer der Gegenseite noch nicht bekannt ist.Heißt ACK:0 nicht das kein Paket zurück kam?
Auf dieses Paket, muß aber vom Server eine Antwort kommen (SYN/ACK), bei dem SEQ und ACK von 0 verschiedene Werte haben. Wenn da keine Antwort kommt, dann ist das LANCOM für den Server nicht das Gateway...
Als erstes würde hier auch wieder mal ein IP-Router- und Firewall-Trace machen um herauszufinden, was passiert...Nun habe ich vom Lancom der im Netz A steht versucht ein telnet aufzubauen und direkt kommt die Meldung Terminal session terminated.
Woran könnte das liegen? In den Firewall-Regeln habe ich telnet nirgendswo geblockt?
Gruß
Backslash