5
Mikrotik - Cisco RV042 IPSec VPN Tunnel
Moin,
ich probiere gerade einen Mikrotik Router mit einem CISCO RV042 Router über einen IPSec Tunnel zu verbinden. (Siehe: Homeoffice via VPN anbinden)
Auf der Client-Seite gibt es eine Router-Kaskade mit dynamischer, öffentlicher IP. Der IPSec-Server/Router ist direkt über eine statische IP erreichbar.
Hinter dem Cisco Router läuft ein SBS als PPTP Server.
Der VPN Tunnel zwischen Small Business Server und MikroTik via PPTP funktioniert problemlos.
IPSec dagegen nicht.
Der Verbindungsaufbau bricht mit der Fehlermeldung:
ab.
Hier die VPN-Konfigurationen, angelehnt an IPsec VPNs einrichten mit Cisco, Mikrotik, pfSense Firewall, FritzBox, Smartphone sowie Shrew Client Software.
Cisco RV042
Firewall:
VPN Passthrough:
Gateway to Gateway VPN:
MikroTik:
Address List:
Proposal:
Policy:
Peer:
Log vom Cisco RV042:
Log vom MikroTik:
Unabhängig von dem Testaufbau mit dem MikroTik Router, habe ich versucht direkt mit aus dem 192.168.1.0/24er Netz eine IPSec Verbindung mittels Shrew-Client aufzubauen. Auch das ist genau mit der selben Fehlermeldung an der gleichen Stelle abgebrochen.
Durch fleißiges googeln bin ich darauf gestoßen, dass der IPSec Server ggf. Probleme mit der dynamischen IP des Clients haben könnte oder das es mit NAT-T zusammenhängen könnte oder das die Subnetze nicht zusammenpassen.
NAT-T habe ich testweise eingeschaltet und auch die dynamische IP habe ich fest konfiguriert. - Kein Erfolg. Selbe Fehlermeldung.
Auf dem Cisco Router habe ich alle VPN "Typen" (Gateway To Gateway, Client To Gateway (Tunnel/Group VPN)) durchprobiert. Jedes mal ist der wieder an dieser Stelle hängengeblieben.
Was könnte man noch probieren?
An welcher Stelle hakt es?
Vielen Dank schon einmal.
ich probiere gerade einen Mikrotik Router mit einem CISCO RV042 Router über einen IPSec Tunnel zu verbinden. (Siehe: Homeoffice via VPN anbinden)
Auf der Client-Seite gibt es eine Router-Kaskade mit dynamischer, öffentlicher IP. Der IPSec-Server/Router ist direkt über eine statische IP erreichbar.
Hinter dem Cisco Router läuft ein SBS als PPTP Server.
Der VPN Tunnel zwischen Small Business Server und MikroTik via PPTP funktioniert problemlos.
IPSec dagegen nicht.
Der Verbindungsaufbau bricht mit der Fehlermeldung:
cannot respond to IPsec SA request because no connection is known for 192.168.71.0/24===1.1.1.1...2.2.2.2[test@*******************]===192.168.88.0/24
Hier die VPN-Konfigurationen, angelehnt an IPsec VPNs einrichten mit Cisco, Mikrotik, pfSense Firewall, FritzBox, Smartphone sowie Shrew Client Software.
Cisco RV042
Firewall:
VPN Passthrough:
Gateway to Gateway VPN:
MikroTik:
Address List:
Proposal:
Policy:
Peer:
Log vom Cisco RV042:
Sep 26 16:47:37 2014 VPN Log packet from 2.2.2.2:500: received Vendor ID payload [Dead Peer Detection]
Sep 26 16:47:37 2014 VPN Log packet from 2.2.2.2:500: received Vendor ID payload [Dead Peer Detection]
Sep 26 16:47:37 2014 VPN Log packet from 2.2.2.2:500: [Tunnel Negotiation Info] <<< Responder Received Aggressive Mode 1st packet
Sep 26 16:47:37 2014 VPN Log packet from 2.2.2.2:500: [Tunnel Negotiation Info] <<< Responder Received Aggressive Mode 1st packet
Sep 26 16:47:37 2014 VPN Log (g2gips0)[3] 2.2.2.2 #107: Peer ID is ID_USER_FQDN: 'test@*******************'
Sep 26 16:47:37 2014 VPN Log (g2gips0)[3] 2.2.2.2 #107: responding to Aggressive Mode, state #107, connection 'g2gips0' from 2.2.2.2
Sep 26 16:47:37 2014 VPN Log (g2gips0)[3] 2.2.2.2 #107: [Tunnel Negotiation Info] >>> Responder Send Aggressive Mode 2nd packet
Sep 26 16:47:37 2014 VPN Log (g2gips0)[3] 2.2.2.2 #107: [Tunnel Negotiation Info] >>> Responder Send Aggressive Mode 2nd packet
Sep 26 16:47:37 2014 VPN Log (g2gips0)[3] 2.2.2.2 #107: [Tunnel Negotiation Info] <<< Responder Received Aggressive Mode 3rd packet
Sep 26 16:47:37 2014 VPN Log (g2gips0)[3] 2.2.2.2 #107: [Tunnel Negotiation Info] <<< Responder Received Aggressive Mode 3rd packet
Sep 26 16:47:37 2014 VPN Log (g2gips0)[3] 2.2.2.2 #107: Peer ID is ID_USER_FQDN: 'test@*******************'
Sep 26 16:47:37 2014 VPN Log (g2gips0)[3] 2.2.2.2 #107: Peer ID is ID_USER_FQDN: 'test@*******************'
Sep 26 16:47:37 2014 VPN Log (g2gips0)[3] 2.2.2.2 #107: [Tunnel Negotiation Info] Aggressive Mode Phase 1 SA Established
Sep 26 16:47:37 2014 VPN Log (g2gips0)[3] 2.2.2.2 #107: [Tunnel Negotiation Info] Aggressive Mode Phase 1 SA Established
Sep 26 16:47:37 2014 VPN Log (g2gips0)[3] 2.2.2.2 #107: ISAKMP SA established
Sep 26 16:47:38 2014 VPN Log (g2gips0)[3] 2.2.2.2 #107: [Tunnel Negotiation Info] <<< Responder Received Quick Mode 1st packet
Sep 26 16:47:38 2014 VPN Log (g2gips0)[3] 2.2.2.2 #107: [Tunnel Negotiation Info] <<< Responder Received Quick Mode 1st packet
Sep 26 16:47:38 2014 VPN Log (g2gips0)[3] 2.2.2.2 #107: cannot respond to IPsec SA request because no connection is known for 192.168.71.0/24===1.1.1.1...2.2.2.2[test@*******************]===192.168.88.0/24
Sep 26 16:47:38 2014 VPN Log (g2gips0)[3] 2.2.2.2 #107: sending encrypted notification INVALID_ID_INFORMATION to 2.2.2.2:500
Log vom MikroTik:
Unabhängig von dem Testaufbau mit dem MikroTik Router, habe ich versucht direkt mit aus dem 192.168.1.0/24er Netz eine IPSec Verbindung mittels Shrew-Client aufzubauen. Auch das ist genau mit der selben Fehlermeldung an der gleichen Stelle abgebrochen.
Durch fleißiges googeln bin ich darauf gestoßen, dass der IPSec Server ggf. Probleme mit der dynamischen IP des Clients haben könnte oder das es mit NAT-T zusammenhängen könnte oder das die Subnetze nicht zusammenpassen.
NAT-T habe ich testweise eingeschaltet und auch die dynamische IP habe ich fest konfiguriert. - Kein Erfolg. Selbe Fehlermeldung.
Auf dem Cisco Router habe ich alle VPN "Typen" (Gateway To Gateway, Client To Gateway (Tunnel/Group VPN)) durchprobiert. Jedes mal ist der wieder an dieser Stelle hängengeblieben.
Was könnte man noch probieren?
An welcher Stelle hakt es?
Vielen Dank schon einmal.
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 250275
Url: https://administrator.de/contentid/250275
Printed on: April 23, 2024 at 09:04 o'clock
5 Comments
Latest comment
Hallo,
wir haben hier auch eine Suchfunktion die Anleitungen liefert!
IPSEC Protokoll - Einsatz, Aufbau, benötigte Ports und Begriffserläuterungen
Gruß
Dobby
wir haben hier auch eine Suchfunktion die Anleitungen liefert!
IPSEC Protokoll - Einsatz, Aufbau, benötigte Ports und Begriffserläuterungen
Gruß
Dobby
Zitat von @108012:
wir haben hier auch eine Suchfunktion die Anleitungen liefert!
wir haben hier auch eine Suchfunktion die Anleitungen liefert!
Vielen Dank für den Hinweis, Dobby.
Leider hilft mir das, abgesehen davon, dass ich mich fachlich korrekter ausdrücken kann, leider nicht weiter.
Grundsätzlich scheint der Aufbau des Tunnels ja zu funktionieren. Shrew und Mikrotik erkennen, dass da was passiert ist:
Allerdings gibt es keinen Datenverkehr durch den Tunnel, was wohl mit besagter Fehlermeldung zutun haben muss.
Der PC bzw. Mikrotik auf der Clientseite laufen als ExposedHost und alle Firewalls sind auf Durchzug geschaltet. An der Stelle kann es eigentlich nicht haken.
Ich komme nicht dahinter, an welcher stelle es noch klemmen könnte.
Dein Fehler ist ein ID Message oder Notification Mismatch. Das passiert wenn deine Lokale ID (FQDN oder IP) nicht mit der übereinstimmt die du auf der anderen Seite als Remote definiert hast.
Z.B. wenn du auf der einen Seite ein FQDN angibst auf der anderen aber eine IP oder auf der einen Seite ein Subnetz und Maske auf der anderen Seite aber z.B. bei der IP oder bei der Maske einen Tippfehler machst.
Dann stimmen die SAsnicht und es kommt zum Abbruch der Phase 2.
Genau das ist der Fall bei dir ! Irgendwo hast du also einen Tippfehler in der Konfiguration. Vermutlich ist es die Mikrotik Policy denn dort sind in der Src und Dst Address falsche Werte !
Z.B. wenn du auf der einen Seite ein FQDN angibst auf der anderen aber eine IP oder auf der einen Seite ein Subnetz und Maske auf der anderen Seite aber z.B. bei der IP oder bei der Maske einen Tippfehler machst.
Dann stimmen die SAsnicht und es kommt zum Abbruch der Phase 2.
Genau das ist der Fall bei dir ! Irgendwo hast du also einen Tippfehler in der Konfiguration. Vermutlich ist es die Mikrotik Policy denn dort sind in der Src und Dst Address falsche Werte !
Der PC bzw. Mikrotik auf der Clientseite laufen als ExposedHost und alle Firewalls sind
auf Durchzug geschaltet. An der Stelle kann es eigentlich nicht haken.
Eigentlich braucht man nur die Ports und Protokolle öffnen die man dort in der Anleitungauf Durchzug geschaltet. An der Stelle kann es eigentlich nicht haken.
sieht und nicht alles offen wie ein Scheunentor stehen lassen.
Ich komme nicht dahinter, an welcher stelle es noch klemmen könnte.
Daher noch einmal der Link zu der Anleitung die kann man auch Step-by-Stepnachmachen bzw. umsetzen und findet dann meist solche Fehler wie sie @aqui
ja schon angesprochen hat bzw. um so etwas zufinden müsste man schon einmal
die Konfiguration genauer kennen.
Gruß
Dobby
Hey ihr beiden.
Vielen Dank für eure Unterstützung.
Wie bereits eingangs geschrieben, habe ich bei der Konfiguration die Anleitung (IPsec VPNs einrichten mit Cisco, Mikrotik, pfSense Firewall, FritzBox, Smartphone sowie Shrew Client Software) verwendet.
Die Einstellungen im Mikrotik entsprechen dieser.
Wo genau ist denn der Fehler in der Src und Dst Address?
Ich habe es so verstanden, dass in
Src das LAN der Clients und bei
Dst das LAN der Serverseite hinterlegt werden müssen.
Selbstverständlich war der Mikrotik nur zum Ausschließen eines Fehlers innerhalb der Fritzbox-Config als ExposedHost konfiguriert.
Vielen Dank für eure Unterstützung.
Wie bereits eingangs geschrieben, habe ich bei der Konfiguration die Anleitung (IPsec VPNs einrichten mit Cisco, Mikrotik, pfSense Firewall, FritzBox, Smartphone sowie Shrew Client Software) verwendet.
Die Einstellungen im Mikrotik entsprechen dieser.
Wo genau ist denn der Fehler in der Src und Dst Address?
Ich habe es so verstanden, dass in
Src das LAN der Clients und bei
Dst das LAN der Serverseite hinterlegt werden müssen.
Selbstverständlich war der Mikrotik nur zum Ausschließen eines Fehlers innerhalb der Fritzbox-Config als ExposedHost konfiguriert.
