VPN auf Cisco RV082 hinter Fritz kommt nicht in Phase 2
Hallo Experten,
ich habe ein Problem, ein VPN auf einen Cisco RV082 zu laufen zu bekommen, der hinter eine FB 7390 (aktuelle Firmware) liegt.
Ausgangslage:
FB bedient Subnetz a
- hält die Verbindung zum ISP (feste IP)
- bedient ein Drucker/Faxgerät (analog)
- bedient eine ISDN Telefonanlage
An dieser FB ist ein Cisco VPN Router RV082 über seinem WAN1 angeschlossen.
Der RV082 bedient Subnetz b, an denen Server und Clients hängen.
Soweit so gut: Zugriffe vom Subnetz b nach a und ins Internet klappen.
Fritz VPN klappt, Remotes kommen da hin wo sie sollen (auch in Subnetz b). Alles bestens.
Die Fritte kann aber nur 8 VPNs daher soll dies auf den RV082. Die Fritzbox abzuschaffen wäre wohl eine Alternative, aber dann würde ich außer einem Modem auch noch weitere Hardware fürs Faxgerät und die ISDN-Telefonanlage benötigen. Falls dies die einzige Lösung ist: welche, und wie an den RV082 anschließen?
Ich habe auf der Fritz Box Weiterleitungen eingerichtet:
- UDP 500
- UDP 4500 für NAT
- ESP
und alle VPN-Einstellungen gelöscht.
Ich habe auf dem RV082 Client-To-Gateway VPN-Tunnel ähnlich denen von dem Fritz-VPN eingerichtet (mit NAT enabled).
Wenn ich vom VPN-Client von außerhalb eine VPN-Verbindung aufmachen möchte, finde ich im Log vom RV082 folgendes:
...
Ignoring Vendor ID payload [8404adf9cda05760...]
Ignoring Vendor ID payload Type = [Cisco-Unity]
[Tunnel Negotiation Info] <<< Responder Received Aggressive Mode 1st packet
Aggressive mode peer ID is ID_USER_FQDN: 'me@email.de'
Responding to Aggressive Mode from (hier steht die öffentliche fixe IP)
[Tunnel Negotiation Info] >>> Responder Send Aggressive Mode 2nd packet
[Tunnel Negotiation Info] <<< Responder Received Aggressive Mode 3rd packet
Aggressive mode peer ID is ID_USER_FQDN: 'me@email.de'
[Tunnel Negotiation Info] Aggressive Mode Phase 1 SA Established
[Tunnel Negotiation Info] Initiator Cookies = 10e 658a 3e6c 8033
[Tunnel Negotiation Info] Responder Cookies = 8d5e 631 3b66 b834
Received informational payload, type IPSEC_INITIAL_CONTACT
und da hört's auf. Der VPN-Client wartet und wartet...
Für mich als Laie (bin Entwickler, kein Admin), sieht das so aus, als würde Phase 1 noch klappen, dann aber nicht in Phase 2 übergegangen werden, oder?
Dafür benötigt der RV082 das ESP-Protokoll, richtig?
Leitet die Fritzbox das nicht weiter - obwohl ich es eingetragen habe?
Ich habe auch schon den RV082 als "exposed Host" in der Fritzbox eingetragen - identisches Ergebnis.
Habe ich einen Denkfehler?
Falls die Fritte ESP partout nicht weitergibt, gibt es einen andere Weg (Protokoll, Port, ...) das der RV082 kann und die Fritzbox durchlässt (aber nicht PPTP)?
Hinweis: Diese Frage knüpft an den Post VPN zu Cisco RV082 hinter Fritz-Box 7390 an.
Ich freue mich auf eure Antworten.
Frank
ich habe ein Problem, ein VPN auf einen Cisco RV082 zu laufen zu bekommen, der hinter eine FB 7390 (aktuelle Firmware) liegt.
Ausgangslage:
FB bedient Subnetz a
- hält die Verbindung zum ISP (feste IP)
- bedient ein Drucker/Faxgerät (analog)
- bedient eine ISDN Telefonanlage
An dieser FB ist ein Cisco VPN Router RV082 über seinem WAN1 angeschlossen.
Der RV082 bedient Subnetz b, an denen Server und Clients hängen.
Soweit so gut: Zugriffe vom Subnetz b nach a und ins Internet klappen.
Fritz VPN klappt, Remotes kommen da hin wo sie sollen (auch in Subnetz b). Alles bestens.
Die Fritte kann aber nur 8 VPNs daher soll dies auf den RV082. Die Fritzbox abzuschaffen wäre wohl eine Alternative, aber dann würde ich außer einem Modem auch noch weitere Hardware fürs Faxgerät und die ISDN-Telefonanlage benötigen. Falls dies die einzige Lösung ist: welche, und wie an den RV082 anschließen?
Ich habe auf der Fritz Box Weiterleitungen eingerichtet:
- UDP 500
- UDP 4500 für NAT
- ESP
und alle VPN-Einstellungen gelöscht.
Ich habe auf dem RV082 Client-To-Gateway VPN-Tunnel ähnlich denen von dem Fritz-VPN eingerichtet (mit NAT enabled).
Wenn ich vom VPN-Client von außerhalb eine VPN-Verbindung aufmachen möchte, finde ich im Log vom RV082 folgendes:
...
Ignoring Vendor ID payload [8404adf9cda05760...]
Ignoring Vendor ID payload Type = [Cisco-Unity]
[Tunnel Negotiation Info] <<< Responder Received Aggressive Mode 1st packet
Aggressive mode peer ID is ID_USER_FQDN: 'me@email.de'
Responding to Aggressive Mode from (hier steht die öffentliche fixe IP)
[Tunnel Negotiation Info] >>> Responder Send Aggressive Mode 2nd packet
[Tunnel Negotiation Info] <<< Responder Received Aggressive Mode 3rd packet
Aggressive mode peer ID is ID_USER_FQDN: 'me@email.de'
[Tunnel Negotiation Info] Aggressive Mode Phase 1 SA Established
[Tunnel Negotiation Info] Initiator Cookies = 10e 658a 3e6c 8033
[Tunnel Negotiation Info] Responder Cookies = 8d5e 631 3b66 b834
Received informational payload, type IPSEC_INITIAL_CONTACT
und da hört's auf. Der VPN-Client wartet und wartet...
Für mich als Laie (bin Entwickler, kein Admin), sieht das so aus, als würde Phase 1 noch klappen, dann aber nicht in Phase 2 übergegangen werden, oder?
Dafür benötigt der RV082 das ESP-Protokoll, richtig?
Leitet die Fritzbox das nicht weiter - obwohl ich es eingetragen habe?
Ich habe auch schon den RV082 als "exposed Host" in der Fritzbox eingetragen - identisches Ergebnis.
Habe ich einen Denkfehler?
Falls die Fritte ESP partout nicht weitergibt, gibt es einen andere Weg (Protokoll, Port, ...) das der RV082 kann und die Fritzbox durchlässt (aber nicht PPTP)?
Hinweis: Diese Frage knüpft an den Post VPN zu Cisco RV082 hinter Fritz-Box 7390 an.
Ich freue mich auf eure Antworten.
Frank
Kommentieren
Teilen
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 226480
Url: https://administrator.de/forum/vpn-auf-cisco-rv082-hinter-fritz-kommt-nicht-in-phase-2-226480.html
Ausgedruckt am: 26.04.2025 um 18:04 Uhr
6 Kommentare
Neuester Kommentar
Hallo Frank,
Noch etwas gleich zuerst bitte, was mir aufgefallen ist, den "exposed host" bitte nicht bzw.
nie nutzen, das ist nur für gewisse Fälle bzw. Labornetze und Testnetze.
Also man hat mehrere Möglichkeiten in Deinem Fall:
Möglichkeit 1:
Lass die AVM Fitz!Box am ISDN Anschluss dran und kaufe ein Modem was zu Deinem Internetzugang
passt und diesen auch Bedienen kann. (ADSL, ADSL2+, VDSL) Klemm das Modem vor die Cisco RV082
und gut ist es. Dann kannst Du die Fritz!Box und all Ihre Dienste weiter nutzen. Und hast ein VPN was
sich zum Einen auch konfigurieren lässt und zum Anderen auch funktioniert!
Möglichkeit 2:
So hast Du es gemacht:
Und so hat @aqui es Dir geraten:
So und nun vergleiche doch mal was genau der Unterschied zwischen den beiden
von Dir vorgenommenen Sachen ist, und vor allem lösche einmal die beiden Router
Konfigurationen ganz und richte sie Schritt-für-Schritt wieder ein
Das sollte es meiner Meinung nach schon gewesen sein.
Und vor allen Dingen hast Du auch NAT-T also NAT Traversal gemacht bzw.
eingegeben oder nur NAT?
und benutze den "Exposed Host" bitte nie wieder denn dort wird dann alles
einfach durch geleitet und zwar ohne SPI & NAT Prüfung, also auch alle Vire,
Trojaner, Hacker, Scripte, Würmer und alle die Deine TK Anlage mal umsonst
benutzen wollen um den Bundesinnenminister zu beleidigen!!!
kannst Du das zum "fliegen" bringen, und dann auch noch so komisch mit
einer Fritz!Box davor, was sicherlich auch nicht "best practice" ist.
die ganze Sache mit den Funden von dort das ganze schon lange umgesetzt!
Diese Frage wird hier so ein bis zweimal im Monat gestellt!
Ports frei gegeben werden, das ist so als wenn man mir sagt ich soll eine der "hohen"
Programmiersprachen benutzen und zwar schlicht Assembler und ich fange an in JavaScript
Code zu schreiben, das setzt der Compiler dann auch nicht um, aber jede Wette, und ich
kann gar keinen Code schreiben!
Gruß
Dobby
Noch etwas gleich zuerst bitte, was mir aufgefallen ist, den "exposed host" bitte nicht bzw.
nie nutzen, das ist nur für gewisse Fälle bzw. Labornetze und Testnetze.
Also man hat mehrere Möglichkeiten in Deinem Fall:
Möglichkeit 1:
Lass die AVM Fitz!Box am ISDN Anschluss dran und kaufe ein Modem was zu Deinem Internetzugang
passt und diesen auch Bedienen kann. (ADSL, ADSL2+, VDSL) Klemm das Modem vor die Cisco RV082
und gut ist es. Dann kannst Du die Fritz!Box und all Ihre Dienste weiter nutzen. Und hast ein VPN was
sich zum Einen auch konfigurieren lässt und zum Anderen auch funktioniert!
Möglichkeit 2:
So hast Du es gemacht:
- UDP 500
- UDP 4500 für NAT
- ESP
- UDP 4500 für NAT
- ESP
Und so hat @aqui es Dir geraten:
UDP 500 (IKE)
UDP 4500 (NAT-T)
ESP Protokoll mit der IP Nummer 50
(Achtung: ESP ist ein eigenständiges Protokoll also nicht TCP oder UDP 50 !)
UDP 4500 (NAT-T)
ESP Protokoll mit der IP Nummer 50
(Achtung: ESP ist ein eigenständiges Protokoll also nicht TCP oder UDP 50 !)
So und nun vergleiche doch mal was genau der Unterschied zwischen den beiden
von Dir vorgenommenen Sachen ist, und vor allem lösche einmal die beiden Router
Konfigurationen ganz und richte sie Schritt-für-Schritt wieder ein
Das sollte es meiner Meinung nach schon gewesen sein.
Für mich als Laie (bin Entwickler, kein Admin), sieht das so aus, als würde Phase 1
Auch gestandene Admins verzweifeln am VPN und das sogar recht oft.Dafür benötigt der RV082 das ESP-Protokoll, richtig?
Ja und zwar mit der IP Nummer 50, genau so wie oben bzw. vorher von @aqui angegeben!Leitet die Fritzbox das nicht weiter - obwohl ich es eingetragen habe?
Mit der IP Nummer 50?Und vor allen Dingen hast Du auch NAT-T also NAT Traversal gemacht bzw.
eingegeben oder nur NAT?
Ich habe auch schon den RV082 als "exposed Host" in der Fritzbox eingetragen
- identisches Ergebnis.
Egal was Du auch noch immer umsetzen möchtest lass da bitte die Finger von- identisches Ergebnis.
und benutze den "Exposed Host" bitte nie wieder denn dort wird dann alles
einfach durch geleitet und zwar ohne SPI & NAT Prüfung, also auch alle Vire,
Trojaner, Hacker, Scripte, Würmer und alle die Deine TK Anlage mal umsonst
benutzen wollen um den Bundesinnenminister zu beleidigen!!!
Habe ich einen Denkfehler?
Nein, aber genauso wenig wie wir alle sauberen Code schreiben können,kannst Du das zum "fliegen" bringen, und dann auch noch so komisch mit
einer Fritz!Box davor, was sicherlich auch nicht "best practice" ist.
Falls die Fritte ESP partout nicht weitergibt, gibt es einen andere Weg
Also ich hätte ja schon mal die Suchfunktion hier im Forum genutzt unddie ganze Sache mit den Funden von dort das ganze schon lange umgesetzt!
Diese Frage wird hier so ein bis zweimal im Monat gestellt!
(Protokoll, Port, ...) das der RV082 kann und die Fritzbox durchlässt (aber nicht PPTP)?
Also entweder Du machst IPSec VPN oder PPTP VPN und genau dafür müssen auch diePorts frei gegeben werden, das ist so als wenn man mir sagt ich soll eine der "hohen"
Programmiersprachen benutzen und zwar schlicht Assembler und ich fange an in JavaScript
Code zu schreiben, das setzt der Compiler dann auch nicht um, aber jede Wette, und ich
kann gar keinen Code schreiben!
Gruß
Dobby
Frank,
worin bestand denn die Lösung?
worin bestand denn die Lösung?
Bei der Fritz Box kann man nur bei UDP Ports angeben, ESP ist als Protokoll freigegeben. Und ich meinte NAT-T (als Kommentar). Habe also die Freigabe genau so gemacht, wie @aqui es vorgeschlagen hat.
Zu Möglichkeit 1:
Hab ich versäumt mitzuteilen: Die Rufnummern sind Internet-Rufnummern.
So habe ich nun die Idee, eine IP-Basisstation für die DECT-Telefone zu kaufen und an den Router anzuschließen.
Und vor den Router ein Modem. Der Router hat dann die ISP-Zugangsdaten.
Zu Möglichkeit 2:
Ich will IPsec, nichts anderes. So hab ichs auch geschrieben.
Ich habe zahlreiche Theras gelesen und gefunden, dass ESP in UDP 4500 gekapselt wird. So habe ich es im Router und im Client eingetragen. Und es funktioniert doch nicht. Oder welche Antwort habe ich etwa übersehen?
Hier der Shrew Trace:
14/01/13 00:24:04 ii : ipc client process thread begin ...
14/01/13 00:24:04 <A : peer config add message
14/01/13 00:24:04 <A : proposal config message
14/01/13 00:24:04 <A : proposal config message
14/01/13 00:24:04 <A : client config message
14/01/13 00:24:04 <A : local id 'me@mail.de' message
14/01/13 00:24:04 <A : preshared key message
14/01/13 00:24:04 <A : remote resource message
14/01/13 00:24:04 <A : peer tunnel enable message
14/01/13 00:24:04 ii : local supports nat-t ( draft v00 )
14/01/13 00:24:04 ii : local supports nat-t ( draft v01 )
14/01/13 00:24:04 ii : local supports nat-t ( draft v02 )
14/01/13 00:24:04 ii : local supports nat-t ( draft v03 )
14/01/13 00:24:04 ii : local supports nat-t ( rfc )
14/01/13 00:24:04 ii : local supports DPDv1
14/01/13 00:24:04 ii : local is SHREW SOFT compatible
14/01/13 00:24:04 ii : local is NETSCREEN compatible
14/01/13 00:24:04 ii : local is SIDEWINDER compatible
14/01/13 00:24:04 ii : local is CISCO UNITY compatible
14/01/13 00:24:04 >= : cookies fb27e35d771216ef:0000000000000000
14/01/13 00:24:04 >= : message 00000000
14/01/13 00:24:04 ii : processing phase1 packet ( 344 bytes )
14/01/13 00:24:04 =< : cookies fb27e35d771216ef:841771d2d735bb52
14/01/13 00:24:04 =< : message 00000000
14/01/13 00:24:04 ii : matched isakmp proposal #1 transform #1
14/01/13 00:24:04 ii : - transform = ike
14/01/13 00:24:04 ii : - cipher type = aes
14/01/13 00:24:04 ii : - key length = 256 bits
14/01/13 00:24:04 ii : - hash type = sha1
14/01/13 00:24:04 ii : - dh group = group2 ( modp-1024 )
14/01/13 00:24:04 ii : - auth type = psk
14/01/13 00:24:04 ii : - life seconds = 28800
14/01/13 00:24:04 ii : - life kbytes = 0
14/01/13 00:24:04 ii : phase1 id match ( natt prevents ip match )
14/01/13 00:24:04 ii : received = ipv4-host 192.168.178.3
14/01/13 00:24:04 ii : peer supports nat-t ( draft v03 )
14/01/13 00:24:04 ii : nat discovery - local address is translated
14/01/13 00:24:04 ii : nat discovery - remote address is translated
14/01/13 00:24:04 ii : switching to src nat-t udp port 4500
14/01/13 00:24:04 ii : switching to dst nat-t udp port 4501
14/01/13 00:24:04 >= : cookies fb27e35d771216ef:841771d2d735bb52
14/01/13 00:24:04 >= : message 00000000
14/01/13 00:24:04 ii : phase1 sa established
14/01/13 00:24:04 ii : öffentliche_fixe_ip:4501 <-> 10.211.55.7:4500
14/01/13 00:24:04 ii : fb27e35d771216ef:841771d2d735bb52
14/01/13 00:24:04 ii : sending peer INITIAL-CONTACT notification
14/01/13 00:24:04 ii : - 10.211.55.7:4500 -> öffentliche_fixe_ip:4501
14/01/13 00:24:04 ii : - isakmp spi = fb27e35d771216ef:841771d2d735bb52
14/01/13 00:24:04 ii : - data size 0
14/01/13 00:24:04 >= : cookies fb27e35d771216ef:841771d2d735bb52
14/01/13 00:24:04 >= : message 1e12f64b
da bleibt er stehen.
Gruß
Frank
Zu Möglichkeit 1:
Hab ich versäumt mitzuteilen: Die Rufnummern sind Internet-Rufnummern.
So habe ich nun die Idee, eine IP-Basisstation für die DECT-Telefone zu kaufen und an den Router anzuschließen.
Und vor den Router ein Modem. Der Router hat dann die ISP-Zugangsdaten.
Zu Möglichkeit 2:
Ich will IPsec, nichts anderes. So hab ichs auch geschrieben.
Ich habe zahlreiche Theras gelesen und gefunden, dass ESP in UDP 4500 gekapselt wird. So habe ich es im Router und im Client eingetragen. Und es funktioniert doch nicht. Oder welche Antwort habe ich etwa übersehen?
Hier der Shrew Trace:
14/01/13 00:24:04 ii : ipc client process thread begin ...
14/01/13 00:24:04 <A : peer config add message
14/01/13 00:24:04 <A : proposal config message
14/01/13 00:24:04 <A : proposal config message
14/01/13 00:24:04 <A : client config message
14/01/13 00:24:04 <A : local id 'me@mail.de' message
14/01/13 00:24:04 <A : preshared key message
14/01/13 00:24:04 <A : remote resource message
14/01/13 00:24:04 <A : peer tunnel enable message
14/01/13 00:24:04 ii : local supports nat-t ( draft v00 )
14/01/13 00:24:04 ii : local supports nat-t ( draft v01 )
14/01/13 00:24:04 ii : local supports nat-t ( draft v02 )
14/01/13 00:24:04 ii : local supports nat-t ( draft v03 )
14/01/13 00:24:04 ii : local supports nat-t ( rfc )
14/01/13 00:24:04 ii : local supports DPDv1
14/01/13 00:24:04 ii : local is SHREW SOFT compatible
14/01/13 00:24:04 ii : local is NETSCREEN compatible
14/01/13 00:24:04 ii : local is SIDEWINDER compatible
14/01/13 00:24:04 ii : local is CISCO UNITY compatible
14/01/13 00:24:04 >= : cookies fb27e35d771216ef:0000000000000000
14/01/13 00:24:04 >= : message 00000000
14/01/13 00:24:04 ii : processing phase1 packet ( 344 bytes )
14/01/13 00:24:04 =< : cookies fb27e35d771216ef:841771d2d735bb52
14/01/13 00:24:04 =< : message 00000000
14/01/13 00:24:04 ii : matched isakmp proposal #1 transform #1
14/01/13 00:24:04 ii : - transform = ike
14/01/13 00:24:04 ii : - cipher type = aes
14/01/13 00:24:04 ii : - key length = 256 bits
14/01/13 00:24:04 ii : - hash type = sha1
14/01/13 00:24:04 ii : - dh group = group2 ( modp-1024 )
14/01/13 00:24:04 ii : - auth type = psk
14/01/13 00:24:04 ii : - life seconds = 28800
14/01/13 00:24:04 ii : - life kbytes = 0
14/01/13 00:24:04 ii : phase1 id match ( natt prevents ip match )
14/01/13 00:24:04 ii : received = ipv4-host 192.168.178.3
14/01/13 00:24:04 ii : peer supports nat-t ( draft v03 )
14/01/13 00:24:04 ii : nat discovery - local address is translated
14/01/13 00:24:04 ii : nat discovery - remote address is translated
14/01/13 00:24:04 ii : switching to src nat-t udp port 4500
14/01/13 00:24:04 ii : switching to dst nat-t udp port 4501
14/01/13 00:24:04 >= : cookies fb27e35d771216ef:841771d2d735bb52
14/01/13 00:24:04 >= : message 00000000
14/01/13 00:24:04 ii : phase1 sa established
14/01/13 00:24:04 ii : öffentliche_fixe_ip:4501 <-> 10.211.55.7:4500
14/01/13 00:24:04 ii : fb27e35d771216ef:841771d2d735bb52
14/01/13 00:24:04 ii : sending peer INITIAL-CONTACT notification
14/01/13 00:24:04 ii : - 10.211.55.7:4500 -> öffentliche_fixe_ip:4501
14/01/13 00:24:04 ii : - isakmp spi = fb27e35d771216ef:841771d2d735bb52
14/01/13 00:24:04 ii : - data size 0
14/01/13 00:24:04 >= : cookies fb27e35d771216ef:841771d2d735bb52
14/01/13 00:24:04 >= : message 1e12f64b
da bleibt er stehen.
Gruß
Frank
Zitat von @104286:
Frank,
worin bestand denn die Lösung?
Der Denkanstoß in Richtung Alternative 1Frank,
worin bestand denn die Lösung?
Ich will IPsec, nichts anderes.
Das würde ich auch immer bevorzugen.Noch etwas kann dazu führen dass es nicht funktioniert!
Auf beiden Seiten müssen unterschiedliche Netze vorhanden sein.
Damit meine ich nicht die öffentliche WAN IP sondern die IP hinter dem NAT.
Also hinter der ersten Fritz!Box 192.168.5.0/24 und hinter der zweiten Fritz!Box 192.168.2.0/24
sonst kommt die Verbindung zustande aber man kann auf nichts zugreifen.
Und in Deinem Fall auch hinter dem Cisco ein unterschiedliches Netz, z.B. 192.168.9.0/24
Sind dort zwei gleiche IP Adressbereiche wird es nichts!
Bei der Fritz Box kann man nur bei UDP Ports angeben, ESP ist als Protokoll freigegeben.
Ja aber mit Port 50 bitte!Und ich meinte NAT-T (als Kommentar).
Habe also die Freigabe genau so gemacht, wie @aqui es vorgeschlagen hat.
Das kam leider nicht so rüber!Habe also die Freigabe genau so gemacht, wie @aqui es vorgeschlagen hat.
Hab ich versäumt mitzuteilen: Die Rufnummern sind Internet-Rufnummern.
Wusste ich halt daher auch nicht!Gruß
Dobby
IPsec bestht wie immer aus
ESP Protokoll Nr. 50
IKE UDP 500
NAT T UDP 4500
Und genau diese Ports müssen geforwardet werden. Da beisst die Maus keinen Faden ab !
ESP Protokoll Nr. 50
IKE UDP 500
NAT T UDP 4500
Und genau diese Ports müssen geforwardet werden. Da beisst die Maus keinen Faden ab !
