7
VPN Verbindung zwischen Fritzbox 3390 und Cisco RV180 aufbauen
Hallo zusammen,
ich möchte eine VPN-Verbindung zwischen meinen 2 Routern aufbauen.
Leider hab ich es bis jetzt nicht geschafft. Kann mir jemand weiterhelfen?
Hier mal meine bisherige Konfiguration:
Fritzbox 3390:
Nachfolgende CFG Datei wurde in der Firtzbox hochgeladen:
vpncfg {
connections {
enabled = yes;
conn_type = conntype_lan;
name = "Cisco Router Home";
always_renew = no;
reject_not_encrypted = no;
dont_filter_netbios = yes;
localip = 0.0.0.0;
local_virtualip = 0.0.0.0;
remoteip = 212.xxx.xxx.xxx;
remote_virtualip = 0.0.0.0;
localid {
fqdn = "woxxxxxx.org";
}
remoteid {
ipaddr = 212.xxx.xxx.xxx;
}
mode = phase1_mode_aggressive;
phase1ss = "all/all/all";
keytype = connkeytype_pre_shared;
key = "xxxxxxxxxxxxxxxxxxxx";
cert_do_server_auth = no;
use_nat_t = no;
use_xauth = no;
use_cfgmode = no;
phase2localid {
ipnet {
ipaddr = 192.168.1.50;
mask = 255.255.255.0;
}
}
phase2remoteid {
ipnet {
ipaddr = 192.168.10.50;
mask = 255.255.255.0;
}
}
phase2ss = "esp-all-all/ah-none/comp-all/pfs";
accesslist = "permit ip any 192.168.10.0 255.255.255.0";
}
ike_forward_rules = "udp 0.0.0.0:500 0.0.0.0:500",
"udp 0.0.0.0:4500 0.0.0.0:4500";
}
// EOF
Cisco RV180:
Richtlinienname: "Blabla"
Richtlinientyp: Automatische Richtlinie
Remoteendpunkt: FQDN Woxxxxxxx.org
NetBIOS: Aktivieren
Lokale Datenverkehrauswahl
Lokale IP: Subnetz
Startadresse: 192.168.10.50
Endadresse:
Subnetzmaske: /24
Remotedatenverkehrauswahl
Remote-IP: Subnetz Dieses Feld kann nicht bearbeitet werden, da NetBIOS ausgewählt ist.
Startadresse: 192.168.1.50
Endadresse:
Subnetzmaske: /24
Parameter für automatische Richtlinien
SA-Gültigkeitsdauer: 3600 Sekunden
Verschlüsselungsalgorithmus: AES-128
Integritätsalgorithmus: SHA-1
PFS-Schlüsselgruppe: Aktivieren DH-Gruppe 2 (1024bit)
IKE-Richtlinie auswählen: "Blabla"
IKE RIchtlinie:
Ausgewählte IKE-Richtlinienansicht
Allgemein
Richtlinienname: Home2Business2
Richtung/Typ Beide
Austauschmodus: Aggressiv
XAUTH-Client aktivieren: Ohne
Lokale Kennung
Kennungstyp: Lokale WAN-IP
FQDN: 212.xxx.xxx.xxx
Peer-IKE-Identifizierung
Kennungstyp: FQDN
FQDN: wolxxxxxx.org
IKE-SA-Parameter
Verschlüsselungsalgorithmus: AES-128
Authentifizierungsalgorithmus: SHA-1
Authentifizierungsmethode: Vorinstallierter Schlüssel
Vorinstallierter Schlüssel: xxxxxxxxxxxxxxxxxxxxx
Diffie-Hellman-Gruppe (DH): Gruppe 2 (1024Bit )
SA-Gültigkeitsdauer: 28800 Seconds
Soweit meine Konfig.
Was habe ich übersehen?
MfG
Edit:
Die Fritzbox Adresse wird über DynDNS angesprochen, die Cisco IP ist statisch.
ich möchte eine VPN-Verbindung zwischen meinen 2 Routern aufbauen.
Leider hab ich es bis jetzt nicht geschafft. Kann mir jemand weiterhelfen?
Hier mal meine bisherige Konfiguration:
Fritzbox 3390:
Nachfolgende CFG Datei wurde in der Firtzbox hochgeladen:
vpncfg {
connections {
enabled = yes;
conn_type = conntype_lan;
name = "Cisco Router Home";
always_renew = no;
reject_not_encrypted = no;
dont_filter_netbios = yes;
localip = 0.0.0.0;
local_virtualip = 0.0.0.0;
remoteip = 212.xxx.xxx.xxx;
remote_virtualip = 0.0.0.0;
localid {
fqdn = "woxxxxxx.org";
}
remoteid {
ipaddr = 212.xxx.xxx.xxx;
}
mode = phase1_mode_aggressive;
phase1ss = "all/all/all";
keytype = connkeytype_pre_shared;
key = "xxxxxxxxxxxxxxxxxxxx";
cert_do_server_auth = no;
use_nat_t = no;
use_xauth = no;
use_cfgmode = no;
phase2localid {
ipnet {
ipaddr = 192.168.1.50;
mask = 255.255.255.0;
}
}
phase2remoteid {
ipnet {
ipaddr = 192.168.10.50;
mask = 255.255.255.0;
}
}
phase2ss = "esp-all-all/ah-none/comp-all/pfs";
accesslist = "permit ip any 192.168.10.0 255.255.255.0";
}
ike_forward_rules = "udp 0.0.0.0:500 0.0.0.0:500",
"udp 0.0.0.0:4500 0.0.0.0:4500";
}
// EOF
Cisco RV180:
Richtlinienname: "Blabla"
Richtlinientyp: Automatische Richtlinie
Remoteendpunkt: FQDN Woxxxxxxx.org
NetBIOS: Aktivieren
Lokale Datenverkehrauswahl
Lokale IP: Subnetz
Startadresse: 192.168.10.50
Endadresse:
Subnetzmaske: /24
Remotedatenverkehrauswahl
Remote-IP: Subnetz Dieses Feld kann nicht bearbeitet werden, da NetBIOS ausgewählt ist.
Startadresse: 192.168.1.50
Endadresse:
Subnetzmaske: /24
Parameter für automatische Richtlinien
SA-Gültigkeitsdauer: 3600 Sekunden
Verschlüsselungsalgorithmus: AES-128
Integritätsalgorithmus: SHA-1
PFS-Schlüsselgruppe: Aktivieren DH-Gruppe 2 (1024bit)
IKE-Richtlinie auswählen: "Blabla"
IKE RIchtlinie:
Ausgewählte IKE-Richtlinienansicht
Allgemein
Richtlinienname: Home2Business2
Richtung/Typ Beide
Austauschmodus: Aggressiv
XAUTH-Client aktivieren: Ohne
Lokale Kennung
Kennungstyp: Lokale WAN-IP
FQDN: 212.xxx.xxx.xxx
Peer-IKE-Identifizierung
Kennungstyp: FQDN
FQDN: wolxxxxxx.org
IKE-SA-Parameter
Verschlüsselungsalgorithmus: AES-128
Authentifizierungsalgorithmus: SHA-1
Authentifizierungsmethode: Vorinstallierter Schlüssel
Vorinstallierter Schlüssel: xxxxxxxxxxxxxxxxxxxxx
Diffie-Hellman-Gruppe (DH): Gruppe 2 (1024Bit )
SA-Gültigkeitsdauer: 28800 Seconds
Soweit meine Konfig.
Was habe ich übersehen?
MfG
Edit:
Die Fritzbox Adresse wird über DynDNS angesprochen, die Cisco IP ist statisch.
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: 235767
Url: https://administrator.de/contentid/235767
Printed on: April 19, 2024 at 22:04 o'clock
7 Comments
Latest comment
Kann mir niemand helfen?
Doch natürlich helfen wir dir.
Setze die Suchfunktion hier ein...
Dieses Forumstutorial beantwortet alle deine Fragen dazu:
IPsec VPNs einrichten mit Cisco, Mikrotik, pfSense Firewall, FritzBox, Smartphone sowie Shrew Client Software
Setze die Suchfunktion hier ein...
Dieses Forumstutorial beantwortet alle deine Fragen dazu:
IPsec VPNs einrichten mit Cisco, Mikrotik, pfSense Firewall, FritzBox, Smartphone sowie Shrew Client Software
Hallo, ich habe es jetzt hinbekommen. Leider gibt es noch ein Problem:
Die VPN Verbindung steht. Vom Netz A(ich nenne es jetzt mal "Fritzbox") aus, kann ich auf Netz B zugreifen. Anders herum geht es aber nicht. Weder Ping noch andere Zugriffe werden beantwortet bzw. sind erreichbar.
Mein Verdacht:
Die Fritzbox scheint trotz bestehender Verbindung den eingehenden Verkehr zu blocken.
Aufbau:
LAN(192.168.10.0/24)<--->Netz B(Cisco RV180)(192.168.10.1/24)<--->VPN<--->NetzA(Fritzbox 3390)(192.168.1.99/24)<--->Cisco RV180(192.168.2.100/24)<--->LAN(192.168.2.0/24)
Verbindung von Netz A zu Netz B funktioniert.
Andersherum aber nicht.
Die VPN Verbindung steht. Vom Netz A(ich nenne es jetzt mal "Fritzbox") aus, kann ich auf Netz B zugreifen. Anders herum geht es aber nicht. Weder Ping noch andere Zugriffe werden beantwortet bzw. sind erreichbar.
Mein Verdacht:
Die Fritzbox scheint trotz bestehender Verbindung den eingehenden Verkehr zu blocken.
Aufbau:
LAN(192.168.10.0/24)<--->Netz B(Cisco RV180)(192.168.10.1/24)<--->VPN<--->NetzA(Fritzbox 3390)(192.168.1.99/24)<--->Cisco RV180(192.168.2.100/24)<--->LAN(192.168.2.0/24)
Verbindung von Netz A zu Netz B funktioniert.
Andersherum aber nicht.
Mmmmmhhh.. Der Cisco RV RV180 ist ja ein VPN Breitbandrouter ohne DSL Modem !
http://www.cisco.com/c/dam/en/us/products/collateral/routers/rv180-vpn- ...
Es stellt sich also die Frage WAS du am WAN Port dieses Routers hast.
Wenn es 1.) ist dann kann es vermutlich ein Firewall Problem sein.. Bei 2.) passiert das nicht, denn da ist der RV180 ja direkt Tunnelendpunkt und es ist kein NAT mehr dazwischen.
Deine Aussage " Vom Netz A(ich nenne es jetzt mal "Fritzbox") aus, kann ich auf Netz B zugreifen" ist etwas laienhaft und oberflächlich denn es wäre mal sinnvoll zu erwarten mit welchen Diensten du zugreifen kannst.
Klar ist aber wenn du z.B. pingen kannst oder auf ein Windows SMB/CIFS Share zugreifen kannst ja immer eine bidirektionale Geschichte ist. Pakete gehen von Netz A nach Netz B und die Endgeräte in Netz B antworten ja auch mit Quittungspaketen und Daten die retour laufen.
Wenn also A nach B klappt dann klappt auch immer B nach A ! Jedenfalls für diese Sessions die von A initiiert werden.
Würde das nicht so sein würde keinerlei Verbindung auch von A nach B möglich sein...logisch und weisst du vermutlich auch selber.
Das kannst du übrigens auch ganz einfach selber mal sehen wenn du dir so einen Ping mal mit dem Wireshark ansiehst, denn dann siehst du bei einem Ping von A nach B auch die ICMP Echo Reply Pakete die von B nach A zurückkommen und laut deiner Beschreibung ja passieren können, sonst würde der Ping scheitern ?!
Fazit: Wenn keine Session von B nach A aufgebaut werden kann, es bei bestehender Session aber klappt, dann "riecht" das zu 99% nach einem NAT (Adress Translation) Problem.
Vermutlich schickt einer der Router den VPN Tunneltraffic durch seinen NAT Prozess was NICHT sein darf !! Logisch denn sonst hat man genau diese Einbahnstrasse.
Du musst also nun rausfinden WELCHER der beiden Router das macht und das dort deaktivieren. Dann wird dein VPN auch fehlerfrei laufen !
Und zwar in beide Richtungen transparent wie es sich gehört !
http://www.cisco.com/c/dam/en/us/products/collateral/routers/rv180-vpn- ...
Es stellt sich also die Frage WAS du am WAN Port dieses Routers hast.
- 1.) Ist es ein weiterer Router also eine Router Kaskade ?
- 2.) Oder hast du dort ein reines DSL Modem angeschlossen ? Also öffentliche IP am WAN Port des RV180 und Login Daten auf dem RV180 ?
Wenn es 1.) ist dann kann es vermutlich ein Firewall Problem sein.. Bei 2.) passiert das nicht, denn da ist der RV180 ja direkt Tunnelendpunkt und es ist kein NAT mehr dazwischen.
Deine Aussage " Vom Netz A(ich nenne es jetzt mal "Fritzbox") aus, kann ich auf Netz B zugreifen" ist etwas laienhaft und oberflächlich denn es wäre mal sinnvoll zu erwarten mit welchen Diensten du zugreifen kannst.
Klar ist aber wenn du z.B. pingen kannst oder auf ein Windows SMB/CIFS Share zugreifen kannst ja immer eine bidirektionale Geschichte ist. Pakete gehen von Netz A nach Netz B und die Endgeräte in Netz B antworten ja auch mit Quittungspaketen und Daten die retour laufen.
Wenn also A nach B klappt dann klappt auch immer B nach A ! Jedenfalls für diese Sessions die von A initiiert werden.
Würde das nicht so sein würde keinerlei Verbindung auch von A nach B möglich sein...logisch und weisst du vermutlich auch selber.
Das kannst du übrigens auch ganz einfach selber mal sehen wenn du dir so einen Ping mal mit dem Wireshark ansiehst, denn dann siehst du bei einem Ping von A nach B auch die ICMP Echo Reply Pakete die von B nach A zurückkommen und laut deiner Beschreibung ja passieren können, sonst würde der Ping scheitern ?!
Fazit: Wenn keine Session von B nach A aufgebaut werden kann, es bei bestehender Session aber klappt, dann "riecht" das zu 99% nach einem NAT (Adress Translation) Problem.
Vermutlich schickt einer der Router den VPN Tunneltraffic durch seinen NAT Prozess was NICHT sein darf !! Logisch denn sonst hat man genau diese Einbahnstrasse.
Du musst also nun rausfinden WELCHER der beiden Router das macht und das dort deaktivieren. Dann wird dein VPN auch fehlerfrei laufen !
Und zwar in beide Richtungen transparent wie es sich gehört !
Also Netz A ist eine Kasakde..der Router Fritzbox fungiert praktisch als DSL Modem und leitet die VPN Verbindung weiter an den Router, welcher dann eine Site to Site VPN Verbindung zu dem andern Router ausbaut. Dies geschieht über IPsec.
Die Kaskade ist aufgebaut: Fritzbox - Lan Port <---> WanPort Cisco. Dies klingt ja danach, dass der VPN Traffic geNATed wird. Dies ist aber anders garnicht möglich, da der Router nur über diesen Port eine Verbindung aufbaut. Eine Verbindung über einen LAN Port scheiterte.
Deine Infos sind hilfreich und klar verständlich. Danke dafür. Sofern es eine NAT / Firewall Problem ist, wie kann ich dies lösen?
Soweit hast du es schon richtig beschrieben. Die Verbindung von Netz A nach B funktioniert einwandfrei. Daher sehe ich das Problem mit deinen Hinweisen jetzt auch evntl. im IPsec, da die Verbindung ja sozusagen nicht vorher angefordert wurde von Netz A, wenn Netz B eine Anfrage sendet. Nur sollte dies doch bei bestehender VPN Verbindung eben durch diesen Tunnel keine Rolle spielen?
Ich habe bereits versucht eine statische Route einzurichten um das Problem zu lösen. Leider möchte der Cisco Router von Netz A eine feste WAN IP Adresse als Gateway eingetragen haben. Diese ist aber nicht fest und ändert sich daher ständig. eine Domäne(DynDNS o.Ä.) kann ich leider nicht eintragen.
Die Kaskade ist aufgebaut: Fritzbox - Lan Port <---> WanPort Cisco. Dies klingt ja danach, dass der VPN Traffic geNATed wird. Dies ist aber anders garnicht möglich, da der Router nur über diesen Port eine Verbindung aufbaut. Eine Verbindung über einen LAN Port scheiterte.
Deine Infos sind hilfreich und klar verständlich. Danke dafür. Sofern es eine NAT / Firewall Problem ist, wie kann ich dies lösen?
Soweit hast du es schon richtig beschrieben. Die Verbindung von Netz A nach B funktioniert einwandfrei. Daher sehe ich das Problem mit deinen Hinweisen jetzt auch evntl. im IPsec, da die Verbindung ja sozusagen nicht vorher angefordert wurde von Netz A, wenn Netz B eine Anfrage sendet. Nur sollte dies doch bei bestehender VPN Verbindung eben durch diesen Tunnel keine Rolle spielen?
Ich habe bereits versucht eine statische Route einzurichten um das Problem zu lösen. Leider möchte der Cisco Router von Netz A eine feste WAN IP Adresse als Gateway eingetragen haben. Diese ist aber nicht fest und ändert sich daher ständig. eine Domäne(DynDNS o.Ä.) kann ich leider nicht eintragen.
Arbeitet die Fritzbox als reines Modem oder als Router ??
Bei letzterem hast du dort ein Port Forwarding der folgenden Ports:
Das entfällt natürlich sollte die FB als reines Modem arbeiten und nicht als Router Kaskade.
Du solltest in der als Modem davorgeschalteten FB (nur sofern sie als Router arbeitet !) noch deren eigenen IPsec Dienst deaktivieren, denn sonst "denkt" sie bei eigehenden IPsec Paketen das diese für sie selber sind und leitet sie nicht weiter.
(Entfällt falls dieses Modell selber kein IPsec supportet !)
Ist das alles passiert ?
Eine statische Route ist übrigens Blödsinn und hat mit der Thematik hier nichts zu tun. Wie auch denn beide Router "kennen" alle beteiligten IP Netze, da sie physisch direkt an sie angeschlossen sind.
Routen sind damit also vollkommen überflüssig und auch kontraproduktiv ! Weg damit also...!
Der Fehler leigt ganz klar daran das einer der beiden Router den Traffic im VPN Tunnel selber am Endpoint durch seinen nAT Prozess schickt und damit NATet der Router den Traffic mit dem Endeffekt das dann diese Einbahnstrasse exiistiert.
Es gilt also rauszufinden WELCHER Router das macht und es dort zu deaktivieren.
Normal darf der Tunneltraffic NICHT geNATet werden !
Checke dazu bei der FB Seite das du ein LAN zu LAN Szenario konfiguriert hast und KEIN Client Login !
Gleiches gilt für den Cisco.
Bei letzterem hast du dort ein Port Forwarding der folgenden Ports:
- UDP 500
- UDP 4500
- ESP Protokoll (Nummer 50, Achtung: nicht TCP oder UDP 50 !)
Das entfällt natürlich sollte die FB als reines Modem arbeiten und nicht als Router Kaskade.
Du solltest in der als Modem davorgeschalteten FB (nur sofern sie als Router arbeitet !) noch deren eigenen IPsec Dienst deaktivieren, denn sonst "denkt" sie bei eigehenden IPsec Paketen das diese für sie selber sind und leitet sie nicht weiter.
(Entfällt falls dieses Modell selber kein IPsec supportet !)
Ist das alles passiert ?
Eine statische Route ist übrigens Blödsinn und hat mit der Thematik hier nichts zu tun. Wie auch denn beide Router "kennen" alle beteiligten IP Netze, da sie physisch direkt an sie angeschlossen sind.
Routen sind damit also vollkommen überflüssig und auch kontraproduktiv ! Weg damit also...!
Der Fehler leigt ganz klar daran das einer der beiden Router den Traffic im VPN Tunnel selber am Endpoint durch seinen nAT Prozess schickt und damit NATet der Router den Traffic mit dem Endeffekt das dann diese Einbahnstrasse exiistiert.
Es gilt also rauszufinden WELCHER Router das macht und es dort zu deaktivieren.
Normal darf der Tunneltraffic NICHT geNATet werden !
Checke dazu bei der FB Seite das du ein LAN zu LAN Szenario konfiguriert hast und KEIN Client Login !
Gleiches gilt für den Cisco.
Hallo, ja Port-Forwarding inklusive ESP ist alles eingerichtet.
Ich werde das mit dem Nat checken! Bis hier hin schonmal Danke!
Ich werde das mit dem Nat checken! Bis hier hin schonmal Danke!
