10
VPN Verbindung zwischen zwei Octopus F50 MGW (Bintec)
Hallo zusammen,
ich versuche gerade zwei Firmenstandorte miteinander zu verbinden. Zur Verfügung stehen mir zwei Octopus F50 MGW -dahinter stecken wohl Hybirds von Bintec.
Aufgebaut werden soll ein IPSec-Tunnel. Hierbei taucht nun folgendes Problem auf: der Aufbau bleibt in Phase 1 stecken. Sowohl Phase 1, als auch Phase 2 sind auf beiden Geräten im Hinblick auf die Proposals identisch aufgebaut.
Ein Debug mittels Konsole ergibt, dass der Aufbau an einem bestimmten Punkt schlicht "hakt" und es nicht weiter geht:
xx:> debug ipsec
16:48:38 DEBUG/IPSEC: P1: peer 1 (RP) sa 18 (I): identified ip 192.168.178.46 -> ip 77.22.xx.xx
16:48:39 INFO/IPSEC: P1: peer 1 (RP) sa 18 (I): Vendor ID: 77.22.xx.xx:500 (fqdn(any:0,[0..9]=xx.xx.vpn)) is 'BINTECELMEG'
16:48:39 INFO/IPSEC: P1: peer 1 (RP) sa 18 (I): Vendor ID: 77.22.xx.xx:500 (fqdn(any:0,[0..9]=xx.xx.vpn)) is 'BINTECELMEG Heartbeats Version 1'
16:48:39 INFO/IPSEC: P1: peer 1 (RP) sa 18 (I): Vendor ID: 77.22.xx.xx:500 (fqdn(any:0,[0..9]=xx.xx.vpn)) is 'RFC XXXX'
16:48:39 INFO/IPSEC: P1: peer 1 (RP) sa 18 (I): Vendor ID: 77.22.xx.xx:500 (fqdn(any:0,[0..9]=xx.xx.vpn)) is 'draft-ietf-ipsec-nat-t-ike-03'
16:48:39 INFO/IPSEC: P1: peer 1 (RP) sa 18 (I): Vendor ID: 77.22.xx.xx:500 (fqdn(any:0,[0..9]=xx.xx.vpn)) is 'draft-ietf-ipsec-nat-t-ike-02'
16:48:39 INFO/IPSEC: P1: peer 1 (RP) sa 18 (I): Vendor ID: 77.22.xx.xx:500 (fqdn(any:0,[0..9]=xx.xx.vpn)) is 'draft-ietf-ipsec-nat-t-ike-02'
16:48:39 INFO/IPSEC: P1: peer 1 (RP) sa 18 (I): Vendor ID: 77.22.xx.xx:500 (fqdn(any:0,[0..9]=xx.xx.vpn)) is 'draft-ietf-ipsec-nat-t-ike-00'
16:48:39 INFO/IPSEC: P1: peer 1 (RP) sa 18 (I): Vendor ID: 77.22.xx.xx:500 (fqdn(any:0,[0..9]=xx.xx.vpn)) is 'draft-ietf-ipsra-isakmp-xauth-06'
16:48:39 INFO/IPSEC: P1: peer 1 (RP) sa 18 (I): Vendor ID: 77.22.xx.xx:500 (fqdn(any:0,[0..9]=xx.xx.vpn)) is 'Dead Peer Detection (DPD, RFC 3706)'
16:48:39 DEBUG/IPSEC: P1: peer 1 (RP) sa 18 (I): [Aggr] NAT-T: port change: local: 192.168.178.46:500->192.168.178.46:4500, remote: 77.22.xx.xx:500->77.22.xx.xx:4500
16:48:39 INFO/IPSEC: P1: peer 1 (RP) sa 18 (I): done id fqdn(any:0,[0..9]=xx.xx.vpn) -> id fqdn(any:0,[0..9]=xx.xx.vpn) AG[d646bde5 xxxxxxxx : 539ba41a xxxxxxxx]
Danach ist Schluss -es passiert nichts mehr. Wenn ich mir die Beispiellogs von Bintec angucke (z.B. http://faq.bintec-elmeg.com/faq_bintec_203_ipsec_client_verbindung_zu_r ..), sollte es nach diesem Part wohl mit Phase 2 losgehen.
Die Logs auf der Gegenseite sehen mit Ausnahme der IP-Adressen identisch aus.
Hat jemand einen Tipp, wo der Fehler stecken könne?
Danke für eure Hilfe!
ich versuche gerade zwei Firmenstandorte miteinander zu verbinden. Zur Verfügung stehen mir zwei Octopus F50 MGW -dahinter stecken wohl Hybirds von Bintec.
Aufgebaut werden soll ein IPSec-Tunnel. Hierbei taucht nun folgendes Problem auf: der Aufbau bleibt in Phase 1 stecken. Sowohl Phase 1, als auch Phase 2 sind auf beiden Geräten im Hinblick auf die Proposals identisch aufgebaut.
Ein Debug mittels Konsole ergibt, dass der Aufbau an einem bestimmten Punkt schlicht "hakt" und es nicht weiter geht:
xx:> debug ipsec
16:48:38 DEBUG/IPSEC: P1: peer 1 (RP) sa 18 (I): identified ip 192.168.178.46 -> ip 77.22.xx.xx
16:48:39 INFO/IPSEC: P1: peer 1 (RP) sa 18 (I): Vendor ID: 77.22.xx.xx:500 (fqdn(any:0,[0..9]=xx.xx.vpn)) is 'BINTECELMEG'
16:48:39 INFO/IPSEC: P1: peer 1 (RP) sa 18 (I): Vendor ID: 77.22.xx.xx:500 (fqdn(any:0,[0..9]=xx.xx.vpn)) is 'BINTECELMEG Heartbeats Version 1'
16:48:39 INFO/IPSEC: P1: peer 1 (RP) sa 18 (I): Vendor ID: 77.22.xx.xx:500 (fqdn(any:0,[0..9]=xx.xx.vpn)) is 'RFC XXXX'
16:48:39 INFO/IPSEC: P1: peer 1 (RP) sa 18 (I): Vendor ID: 77.22.xx.xx:500 (fqdn(any:0,[0..9]=xx.xx.vpn)) is 'draft-ietf-ipsec-nat-t-ike-03'
16:48:39 INFO/IPSEC: P1: peer 1 (RP) sa 18 (I): Vendor ID: 77.22.xx.xx:500 (fqdn(any:0,[0..9]=xx.xx.vpn)) is 'draft-ietf-ipsec-nat-t-ike-02'
16:48:39 INFO/IPSEC: P1: peer 1 (RP) sa 18 (I): Vendor ID: 77.22.xx.xx:500 (fqdn(any:0,[0..9]=xx.xx.vpn)) is 'draft-ietf-ipsec-nat-t-ike-02'
16:48:39 INFO/IPSEC: P1: peer 1 (RP) sa 18 (I): Vendor ID: 77.22.xx.xx:500 (fqdn(any:0,[0..9]=xx.xx.vpn)) is 'draft-ietf-ipsec-nat-t-ike-00'
16:48:39 INFO/IPSEC: P1: peer 1 (RP) sa 18 (I): Vendor ID: 77.22.xx.xx:500 (fqdn(any:0,[0..9]=xx.xx.vpn)) is 'draft-ietf-ipsra-isakmp-xauth-06'
16:48:39 INFO/IPSEC: P1: peer 1 (RP) sa 18 (I): Vendor ID: 77.22.xx.xx:500 (fqdn(any:0,[0..9]=xx.xx.vpn)) is 'Dead Peer Detection (DPD, RFC 3706)'
16:48:39 DEBUG/IPSEC: P1: peer 1 (RP) sa 18 (I): [Aggr] NAT-T: port change: local: 192.168.178.46:500->192.168.178.46:4500, remote: 77.22.xx.xx:500->77.22.xx.xx:4500
16:48:39 INFO/IPSEC: P1: peer 1 (RP) sa 18 (I): done id fqdn(any:0,[0..9]=xx.xx.vpn) -> id fqdn(any:0,[0..9]=xx.xx.vpn) AG[d646bde5 xxxxxxxx : 539ba41a xxxxxxxx]
Danach ist Schluss -es passiert nichts mehr. Wenn ich mir die Beispiellogs von Bintec angucke (z.B. http://faq.bintec-elmeg.com/faq_bintec_203_ipsec_client_verbindung_zu_r ..), sollte es nach diesem Part wohl mit Phase 2 losgehen.
Die Logs auf der Gegenseite sehen mit Ausnahme der IP-Adressen identisch aus.
Hat jemand einen Tipp, wo der Fehler stecken könne?
Danke für eure Hilfe!
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 272192
Url: https://administrator.de/contentid/272192
Ausgedruckt am: 26.11.2024 um 04:11 Uhr
10 Kommentare
Neuester Kommentar
Grundlagen zum Troubleshooting findest du hier:
IPsec VPNs einrichten mit Cisco, Mikrotik, pfSense Firewall, FritzBox, Smartphone sowie Shrew Client Software
Phase 1 bedeutet schon das du einen Mismatch der FQDNs oder IPs der Tunnelendpunkte hast, Die Encryption und Cipher Suites auf beiden Seiten unterschiedlich ist oder das Shared Secret nicht richtig ist, im Pfad irgendwo NAT (Adress Translation, z.B. DS-Lite Accounts usw.) gemacht wird usw.
Da stimmen schon irgendwelche Basiscs nicht so das es da früh zum Abbruch kommt.
Wichtige Fragen:
IPsec VPNs einrichten mit Cisco, Mikrotik, pfSense Firewall, FritzBox, Smartphone sowie Shrew Client Software
Phase 1 bedeutet schon das du einen Mismatch der FQDNs oder IPs der Tunnelendpunkte hast, Die Encryption und Cipher Suites auf beiden Seiten unterschiedlich ist oder das Shared Secret nicht richtig ist, im Pfad irgendwo NAT (Adress Translation, z.B. DS-Lite Accounts usw.) gemacht wird usw.
Da stimmen schon irgendwelche Basiscs nicht so das es da früh zum Abbruch kommt.
Wichtige Fragen:
- Sind vor den VPN Router noch irgendwelche NAT Router vom Provider ?
- Hast du NAT Traversal auf beiden Routern aktiv im Setup ?
- Nutzt eine Seite z.B. DS-Lite (TV Kabelprovider) ?
Danke für deine Antwort!
Die VPN-Router sind tatsächlich beide hinter einer Fritz!Box. Auf einer Seite gibt es Kabelinternet, der Anschluss hat aber eine IP4-Adresse.
- In den Fritz!Boxen sind die entsprechenden Portweiterleitungen konfiguriert (UDP 500, 4500 und ESP). Trage ich die VPN-Router zusätzlich als Exposed-Host ein, ändert dies leider nichts.
- NAT-Traversal ist aktiviert (habe es testweise auch mal deaktiviert, ändert aber nichts).
- Die Encryption und Cipher Suites sind identisch
- Die FQDNs und das SharedSecret stimmen. Ändere ich diese Daten in falsche ab, gibt es auch sofort entsprechende Fehlermeldungen im Log.
Bleibt eigentlich nur der von dir angesprochene Missmatch der IPs der Tunnelendpunkte. Welchen Teil genau meinst du?
Evtl. mache ich auch einen Fehler bei der Remote-IP-Adresse. Bintec schreibt hier: "Bei IP-Adresse des Remote-Netzwerks geben Sie die Zieladresse für die Verbindung ein". Was genau ist die Zieladresse? Das Netzwerk selbst, also in meinem Fall an Standort A 192.168.10.0 und an Standort B 192.168.178.0? Oder die IP des jeweiligen VPN-Routers?
Die VPN-Router sind tatsächlich beide hinter einer Fritz!Box. Auf einer Seite gibt es Kabelinternet, der Anschluss hat aber eine IP4-Adresse.
- In den Fritz!Boxen sind die entsprechenden Portweiterleitungen konfiguriert (UDP 500, 4500 und ESP). Trage ich die VPN-Router zusätzlich als Exposed-Host ein, ändert dies leider nichts.
- NAT-Traversal ist aktiviert (habe es testweise auch mal deaktiviert, ändert aber nichts).
- Die Encryption und Cipher Suites sind identisch
- Die FQDNs und das SharedSecret stimmen. Ändere ich diese Daten in falsche ab, gibt es auch sofort entsprechende Fehlermeldungen im Log.
Bleibt eigentlich nur der von dir angesprochene Missmatch der IPs der Tunnelendpunkte. Welchen Teil genau meinst du?
Evtl. mache ich auch einen Fehler bei der Remote-IP-Adresse. Bintec schreibt hier: "Bei IP-Adresse des Remote-Netzwerks geben Sie die Zieladresse für die Verbindung ein". Was genau ist die Zieladresse? Das Netzwerk selbst, also in meinem Fall an Standort A 192.168.10.0 und an Standort B 192.168.178.0? Oder die IP des jeweiligen VPN-Routers?
moin!
also für mich liegt die crux irgendwo hier:
6:48:39 DEBUG/IPSEC: P1: peer 1 (RP) sa 18 (I): [Aggr] NAT-T: port change: local: 192.168.178.46:500->192.168.178.46:4500, remote: 77.22.xx.xx:500->77.22.xx.xx:4500
da hast du einmal eine interne ip und einmal eine externe ip. klar, die bintec bekommt die ip von der fritzbox und das ist nunmal ihr wan-interface... aber: ohne routerkaskaden (und da ist ipsec schon tricky genug...) stünde da 2x die jew. externe ip... und dann finden die sich auch...
du schreibst aber insgesamt zuwenig zu deiner konfig. (dynamische adressen? auflösung funktioniert? nicht alle geräte unterstützen auf beiden seiten dyndns...
1x kabel. aha. 1x analogmodem? adsl? vdsl? sdsl? umts? feste ip?
nicht, dass ich ein fan von avm's vpn-politik wäre, aber du weisst schon, dass die fritzboxen manchmal (meistens?) in der lage sind ein ipsec vpn untereinander aufzubauen? zumindest testweise solltest du das mal versuchen. bei anschlüssen von kd glaube ich an nichts mehr (dazu gibts hier seit monaten einen thread von mir, den ich immer mal wieder update..) aber ich habe auch stabile verbindungen a la "set it and forget it"
wenn du den aqui mit besseren und möglichst detailreichen infos fütterst, könnte er...
das mit dem remote netzwerk klingt für mich nach phase 2. da müssen die internen netze rein. das andere müsste in phase 1 irgendwas mit remote ip oder remote host oder ähnlich formuliert sein und sollte in der nähe des identifiers auftauchen...
gruß
buc
also für mich liegt die crux irgendwo hier:
6:48:39 DEBUG/IPSEC: P1: peer 1 (RP) sa 18 (I): [Aggr] NAT-T: port change: local: 192.168.178.46:500->192.168.178.46:4500, remote: 77.22.xx.xx:500->77.22.xx.xx:4500
da hast du einmal eine interne ip und einmal eine externe ip. klar, die bintec bekommt die ip von der fritzbox und das ist nunmal ihr wan-interface... aber: ohne routerkaskaden (und da ist ipsec schon tricky genug...) stünde da 2x die jew. externe ip... und dann finden die sich auch...
du schreibst aber insgesamt zuwenig zu deiner konfig. (dynamische adressen? auflösung funktioniert? nicht alle geräte unterstützen auf beiden seiten dyndns...
1x kabel. aha. 1x analogmodem? adsl? vdsl? sdsl? umts? feste ip?
nicht, dass ich ein fan von avm's vpn-politik wäre, aber du weisst schon, dass die fritzboxen manchmal (meistens?) in der lage sind ein ipsec vpn untereinander aufzubauen? zumindest testweise solltest du das mal versuchen. bei anschlüssen von kd glaube ich an nichts mehr (dazu gibts hier seit monaten einen thread von mir, den ich immer mal wieder update..) aber ich habe auch stabile verbindungen a la "set it and forget it"
wenn du den aqui mit besseren und möglichst detailreichen infos fütterst, könnte er...
das mit dem remote netzwerk klingt für mich nach phase 2. da müssen die internen netze rein. das andere müsste in phase 1 irgendwas mit remote ip oder remote host oder ähnlich formuliert sein und sollte in der nähe des identifiers auftauchen...
gruß
buc
also für mich liegt die crux irgendwo hier:
Stimmt genau !Aber wie vermutet hat der TO dort das interne Netz mit der externen IP Verwechselt also klar einen Konfig Fehler bei der jeweiligen Definition für das Remote IP Netz und das lokale IP Netz gemacht.
Immer dran denken: Bei der Angabe des IP netzes sind alle Adressbits auf 0.
Danke euch beiden für die weiteren Anregungen!
Zu meinem Setup:
Standort A:
Provider: KabelDeutschland
Router: Fritz!Box 6360 Cable
VPN-Router: Octopus F50 MGW
IP-Adressenbereich des Netzwerks: 192.168.10.0
Setup VPN-Router A:
IPSec Lan to Lan:
lokale IPSec ID: router1.test.vpn
remote IPSec ID: router2.test.vpn
PreSharedKey: dasistnichwirklichderkey
Lokale IP Adresse: 192.168.10.36 (hier habe ich auch 0 getestet)
IPSec Peer Adresse: xxxx.myfritz.net
IP-Adresse des Remote-Netzwerks: 192.168.178.0 Netzmaske: 255.255.255.0
Phase 1 Profile:
Proposals: AES/MD5
DH-Gruppe: 1024 Bit
Lebensdauer: 28800 Sekunden
Authentifizierungsmethose: PreSharedKeys
Modus: Aggressive
Lokaler ID Typ: FQDN
Lokaler ID-Wert: router1.test.vpn
Erreichbarkeitsprüfung: Automatische Erkennung
Blockzeit: 30 Sekunden
NAT-Traversal: Aktiviert
Erweiterte IPSec-Optionen:
Anzahl erlaubter Verbindungen: Ein Benutzer
Startmodus: auf Anforderung
Öffentliche Schnittstelle: vom Routing ausgewählt
Öffentlicher Schnittstellenmodus: Erzwingen
Öffentliche Quell-IP Adresse: nicht aktiviert Liegt hier vielleicht der Fehler -siehe Anmerkung unten?
Standort B:
Provider: 1&1
Router: Fritz!Box 7490
VPN-Router: Octopus F50 MGW
IP-Adressenbereich des Netzwerks: 192.168.178.0
Setup VPN Router B:
IPSec Lan to Lan:
lokale IPSec ID: router2.test.vpn
remote IPSec ID: router1.test.vpn
PreSharedKey: dasistnichwirklichderkey
Lokale IP Adresse: 192.168.178.46 (ebenfalls auch 0 getestet)
IPSec Peer Adresse: xxxx.myfritz.net
IP-Adresse des Remote-Netzwerks: 192.168.10.0 Netzmaske: 255.255.255.0
Erweiterte IPSec-Optionen:
Anzahl erlaubter Verbindungen: Ein Benutzer
Startmodus: auf Anforderung
Öffentliche Schnittstelle: vom Routing ausgewählt
Öffentlicher Schnittstellenmodus: Erzwingen
Öffentliche Quell-IP Adresse: nicht aktiviert Liegt hier vielleicht der Fehler -siehe Anmerkung unten?
Phase 1 Profile:
Proposals: AES/MD5
DH-Gruppe: 1024 Bit
Lebensdauer: 28800 Sekunden
Authentifizierungsmethose: PreSharedKeys
Modus: Aggressive
Lokaler ID Typ: FQDN
Lokaler ID-Wert: router2.test.vpn
Erreichbarkeitsprüfung: Automatische Erkennung
Blockzeit: 30 Sekunden
NAT-Traversal: Aktiviert
Generell gilt: die Adressauflösung funktioniert, die Router kommunizieren ja auch miteinander.
Bucs-Hinweis zur internen IP könnte zutreffend sein, dies hat mich auch schon stutzig gemacht. Es ist allerdings völlig egal was ich als lokale IP-Adresse konfiguriere (z.B. auch die öffentliche) -im Log taucht immer die interne Router-IP auf. Eine öffentliche Quell-IP ist nicht aktiviert. Aktiviere ich diese auf beiden Seiten (was unpraktisch wäre, da die IPs hier fix eingetragen werden müssen, sie aber dynamisch sind), scheitert der Aufbau mit einem:
12:05:56 INFO/IPSEC: P1: peer 0 () sa 48 (R): failed id fqdn(any:0,[0..4]=XX) <- id fqdn(any:0,[0..9]=router1.test.vpn) (Authentication failed)
oder es gibt gleich Timeouts:
12:12:49 INFO/IPSEC: P1: peer 1 (RP) sa 50 (I): failed id fqdn(any:0,[0..9]=router2.test.vpn) -> ip 77.22.XX.XX (Timeout)
VPN Verbindungen zwischen den Fritz!Boxen haben übrigens reibungslos funktioniert, leider ist die 6360 aber völlig am Limit mit dem schon bestehenden Routing im Firmennetz und der Telefonie...
Zu meinem Setup:
Standort A:
Provider: KabelDeutschland
Router: Fritz!Box 6360 Cable
VPN-Router: Octopus F50 MGW
IP-Adressenbereich des Netzwerks: 192.168.10.0
Setup VPN-Router A:
IPSec Lan to Lan:
lokale IPSec ID: router1.test.vpn
remote IPSec ID: router2.test.vpn
PreSharedKey: dasistnichwirklichderkey
Lokale IP Adresse: 192.168.10.36 (hier habe ich auch 0 getestet)
IPSec Peer Adresse: xxxx.myfritz.net
IP-Adresse des Remote-Netzwerks: 192.168.178.0 Netzmaske: 255.255.255.0
Phase 1 Profile:
Proposals: AES/MD5
DH-Gruppe: 1024 Bit
Lebensdauer: 28800 Sekunden
Authentifizierungsmethose: PreSharedKeys
Modus: Aggressive
Lokaler ID Typ: FQDN
Lokaler ID-Wert: router1.test.vpn
Erreichbarkeitsprüfung: Automatische Erkennung
Blockzeit: 30 Sekunden
NAT-Traversal: Aktiviert
Erweiterte IPSec-Optionen:
Anzahl erlaubter Verbindungen: Ein Benutzer
Startmodus: auf Anforderung
Öffentliche Schnittstelle: vom Routing ausgewählt
Öffentlicher Schnittstellenmodus: Erzwingen
Öffentliche Quell-IP Adresse: nicht aktiviert Liegt hier vielleicht der Fehler -siehe Anmerkung unten?
Standort B:
Provider: 1&1
Router: Fritz!Box 7490
VPN-Router: Octopus F50 MGW
IP-Adressenbereich des Netzwerks: 192.168.178.0
Setup VPN Router B:
IPSec Lan to Lan:
lokale IPSec ID: router2.test.vpn
remote IPSec ID: router1.test.vpn
PreSharedKey: dasistnichwirklichderkey
Lokale IP Adresse: 192.168.178.46 (ebenfalls auch 0 getestet)
IPSec Peer Adresse: xxxx.myfritz.net
IP-Adresse des Remote-Netzwerks: 192.168.10.0 Netzmaske: 255.255.255.0
Erweiterte IPSec-Optionen:
Anzahl erlaubter Verbindungen: Ein Benutzer
Startmodus: auf Anforderung
Öffentliche Schnittstelle: vom Routing ausgewählt
Öffentlicher Schnittstellenmodus: Erzwingen
Öffentliche Quell-IP Adresse: nicht aktiviert Liegt hier vielleicht der Fehler -siehe Anmerkung unten?
Phase 1 Profile:
Proposals: AES/MD5
DH-Gruppe: 1024 Bit
Lebensdauer: 28800 Sekunden
Authentifizierungsmethose: PreSharedKeys
Modus: Aggressive
Lokaler ID Typ: FQDN
Lokaler ID-Wert: router2.test.vpn
Erreichbarkeitsprüfung: Automatische Erkennung
Blockzeit: 30 Sekunden
NAT-Traversal: Aktiviert
Generell gilt: die Adressauflösung funktioniert, die Router kommunizieren ja auch miteinander.
Bucs-Hinweis zur internen IP könnte zutreffend sein, dies hat mich auch schon stutzig gemacht. Es ist allerdings völlig egal was ich als lokale IP-Adresse konfiguriere (z.B. auch die öffentliche) -im Log taucht immer die interne Router-IP auf. Eine öffentliche Quell-IP ist nicht aktiviert. Aktiviere ich diese auf beiden Seiten (was unpraktisch wäre, da die IPs hier fix eingetragen werden müssen, sie aber dynamisch sind), scheitert der Aufbau mit einem:
12:05:56 INFO/IPSEC: P1: peer 0 () sa 48 (R): failed id fqdn(any:0,[0..4]=XX) <- id fqdn(any:0,[0..9]=router1.test.vpn) (Authentication failed)
oder es gibt gleich Timeouts:
12:12:49 INFO/IPSEC: P1: peer 1 (RP) sa 50 (I): failed id fqdn(any:0,[0..9]=router2.test.vpn) -> ip 77.22.XX.XX (Timeout)
VPN Verbindungen zwischen den Fritz!Boxen haben übrigens reibungslos funktioniert, leider ist die 6360 aber völlig am Limit mit dem schon bestehenden Routing im Firmennetz und der Telefonie...
Die Fehlermeldung sagt ja das die Phase 1 nicht auf den IP Adressen sondern auf den FQDNs basiert und daran auch scheitert weil diese vom Gegenüber nicht authentisiert werden können.
D.h. der Router router1.test.vpn muss als Ziel FQDN router2.test.vpn definiert haben und vice versa.
Das schient nicht der Fall zu sein, deshalb scheitert die Authentisierung.
Es ist auch möglich das Bintec versucht diese FQDNs aufzulösen und das scheitert dann logischerweise bei solchen Fake FQDNs wenn diese nicht real existent sind.
Deshalb ist es immer sinnvoller die gegenseitigen lokalen IP Netze zu nehmen als die FQDNs wenn die Router nicht in ein DNS eingebunden sind !
Ein ganz wichtiger Punkt zu dem du rein gar nichts gesagt hats ist die Tatsache das du mit den VPN Routern ja eine Kaskade betreibst auf beiden Seiten !
Also ala:
(Internet)====(Provider_Router)---(VPN_Router)----Lokales Netzwerk
Ein Szenario wie es hier in der Alternative 2 beschrieben ist:
Kopplung von 2 Routern am DSL Port
Bis dato hast du nichts über die Adressierung des Koppelnetzes zw. Provider Router und deinem VPN Router und dem dann folgenden lokalen Netz je Seite gesagt.
Dir sollte hoffentlich klar sein das diese IP Netze alle unterschiedlich sein müssen.
Ferner sollte dir klar sein das die Provider Router VOR den eigentlich VPN Routern alle NAT machen also ein Adress Translation was die öffentliche Provider IP in eine lokale private RFC 1918 IP umsetzt.
Hier muss man zwingend mit statischer IP Adressierung arbeiten, denn in den jeweils vorgeschalteten Provider Routern MUSS zwangsweise ein Port Forwarding gemacht werden auf die IPsec Ports:
Erschwerend kommt hier nich dazu das die dort verwendeten FritzBoxen selber IPsec VPN Router sind also diese Ports nicht so einfach weiterleiten, da sie diesen Traffic immer auf sich selber und ihre VPN Funktion beziehen.
Hier musst du also zusätzlich noch die VPN / IPsec Funktion deaktiviern ! Andernfalls kommt kein VPN Traffic an den dahinter kaskadierten VPN Routern an.
Der Timeout Fehler in der Fehlermeldung lässt auch das vermuten.
Ein klassischer Anfängerfehler der immer wieder gemacht wird bei Router Kaskaden.
Generell ist es sinnvoll wenn möglich IMMER auf solche Kaskaden zu verzichten, denn sie kosten performance und erschweren überflüssigerweise die VPN Konfig !
Deins ist ein Beispiel dafür
D.h. der Router router1.test.vpn muss als Ziel FQDN router2.test.vpn definiert haben und vice versa.
Das schient nicht der Fall zu sein, deshalb scheitert die Authentisierung.
Es ist auch möglich das Bintec versucht diese FQDNs aufzulösen und das scheitert dann logischerweise bei solchen Fake FQDNs wenn diese nicht real existent sind.
Deshalb ist es immer sinnvoller die gegenseitigen lokalen IP Netze zu nehmen als die FQDNs wenn die Router nicht in ein DNS eingebunden sind !
Ein ganz wichtiger Punkt zu dem du rein gar nichts gesagt hats ist die Tatsache das du mit den VPN Routern ja eine Kaskade betreibst auf beiden Seiten !
Also ala:
(Internet)====(Provider_Router)---(VPN_Router)----Lokales Netzwerk
Ein Szenario wie es hier in der Alternative 2 beschrieben ist:
Kopplung von 2 Routern am DSL Port
Bis dato hast du nichts über die Adressierung des Koppelnetzes zw. Provider Router und deinem VPN Router und dem dann folgenden lokalen Netz je Seite gesagt.
Dir sollte hoffentlich klar sein das diese IP Netze alle unterschiedlich sein müssen.
Ferner sollte dir klar sein das die Provider Router VOR den eigentlich VPN Routern alle NAT machen also ein Adress Translation was die öffentliche Provider IP in eine lokale private RFC 1918 IP umsetzt.
Hier muss man zwingend mit statischer IP Adressierung arbeiten, denn in den jeweils vorgeschalteten Provider Routern MUSS zwangsweise ein Port Forwarding gemacht werden auf die IPsec Ports:
- UDP 500
- UDP 4500
- ESP Protokoll (IP Protokoll Nummer 50 (nicht TCP/UDP 50 !)
Erschwerend kommt hier nich dazu das die dort verwendeten FritzBoxen selber IPsec VPN Router sind also diese Ports nicht so einfach weiterleiten, da sie diesen Traffic immer auf sich selber und ihre VPN Funktion beziehen.
Hier musst du also zusätzlich noch die VPN / IPsec Funktion deaktiviern ! Andernfalls kommt kein VPN Traffic an den dahinter kaskadierten VPN Routern an.
Der Timeout Fehler in der Fehlermeldung lässt auch das vermuten.
Ein klassischer Anfängerfehler der immer wieder gemacht wird bei Router Kaskaden.
Generell ist es sinnvoll wenn möglich IMMER auf solche Kaskaden zu verzichten, denn sie kosten performance und erschweren überflüssigerweise die VPN Konfig !
Deins ist ein Beispiel dafür
Servus Catchup,
Deine Aussage bzgl. Hybrid stimmt. Die F50 sind nur umgelabelte Hybird 120/130. Von daher auch in der Einrichtung gleich eines Bintec-Routers.
Evtl. hilft Dir auch dieser Leitfaden ein wenig weiter:
http://www.bintec-elmeg.com/portal/downloadcenter/dateien/workshops/cur ...
VPN war bei Bintec schon immer ein wenig frickelig. Aber wenn es dann läuft ... dann auch ohne große Probleme
Daswelli
Deine Aussage bzgl. Hybrid stimmt. Die F50 sind nur umgelabelte Hybird 120/130. Von daher auch in der Einrichtung gleich eines Bintec-Routers.
Evtl. hilft Dir auch dieser Leitfaden ein wenig weiter:
http://www.bintec-elmeg.com/portal/downloadcenter/dateien/workshops/cur ...
VPN war bei Bintec schon immer ein wenig frickelig. Aber wenn es dann läuft ... dann auch ohne große Probleme
Daswelli
nun, wie aqui schon schreibt, du musst es irgendwie hinkriegen, dass die fqdn's wirklich auf die boxen auflösen, mindestens 1 seite muss das beim site-to-site-vpn schaffen. das scheint ja aber stattzufinden. setz doch mal bei
lokale IPSec ID: meinedomain1.myfritz.net
remote IPSec ID: meinedomain2.myfritz.net
und vice versa. ich weiss, das sollte unabhängig sein vom remote host, aber...
versuche andere identifier.
kontrolliere zum 100. mal die übereinstimung der parameter.
portweiterleitung sollte dem nicht im weg stehen, ich hatte das aber schon so verstanden, dass du feste ip's auf den bintecs hast, da war meine formulierung mit der wan adresse von der fb unkorrekt...
ich stolpere aber immer wieder über diese "client" formulierung bei der konfiguration und in deinem link. du willst ein site-to-site vpn. da ist nicht einer host und der andere client, sondern beide sind gleichberechtigt beim aufbau der verbindung und das protokoll handelt aus, wer fragt und wer antwortet. könnte aber so ein bintec ding sein, wie ich das sehe.
Ich glaube, ich werde nie verstehen, warum ich mit einer Büchse telefonieren, surfen und fernsehen undundund soll. und sie dann am ende schlechter funktioniert, als wenn ich die komponenten einzeln hätte...
Leider wird ja die stabil und zuverlässig funktionierende ISDN-Infrastruktur kaputterneuert.
Was sagt denn AVM dazu, dass die Büchse in die Knie geht? Bzw. um wieviele Clients dreht sich das hier?
und noch eins: mein erstes vpn mit der pfsense scheiterte immer wieder in der phase1. keine chance. alles war korrekt gesetzt. nur ein neuaufsetzen der pfsense hat es gelöst...
will sagen: gibt es ein firmwareupdate? mal einen reset gemacht?
gruss vom buc
lokale IPSec ID: meinedomain1.myfritz.net
remote IPSec ID: meinedomain2.myfritz.net
und vice versa. ich weiss, das sollte unabhängig sein vom remote host, aber...
versuche andere identifier.
kontrolliere zum 100. mal die übereinstimung der parameter.
portweiterleitung sollte dem nicht im weg stehen, ich hatte das aber schon so verstanden, dass du feste ip's auf den bintecs hast, da war meine formulierung mit der wan adresse von der fb unkorrekt...
ich stolpere aber immer wieder über diese "client" formulierung bei der konfiguration und in deinem link. du willst ein site-to-site vpn. da ist nicht einer host und der andere client, sondern beide sind gleichberechtigt beim aufbau der verbindung und das protokoll handelt aus, wer fragt und wer antwortet. könnte aber so ein bintec ding sein, wie ich das sehe.
VPN Verbindungen zwischen den Fritz!Boxen haben übrigens reibungslos funktioniert, leider ist die 6360 aber völlig am Limit mit dem schon bestehenden Routing > im Firmennetz und der Telefonie...
Ich glaube, ich werde nie verstehen, warum ich mit einer Büchse telefonieren, surfen und fernsehen undundund soll. und sie dann am ende schlechter funktioniert, als wenn ich die komponenten einzeln hätte...
Leider wird ja die stabil und zuverlässig funktionierende ISDN-Infrastruktur kaputterneuert.
Was sagt denn AVM dazu, dass die Büchse in die Knie geht? Bzw. um wieviele Clients dreht sich das hier?
und noch eins: mein erstes vpn mit der pfsense scheiterte immer wieder in der phase1. keine chance. alles war korrekt gesetzt. nur ein neuaufsetzen der pfsense hat es gelöst...
will sagen: gibt es ein firmwareupdate? mal einen reset gemacht?
gruss vom buc
Firmwareupdate, Werksreset, - ich habe wirklich alles versucht. Diese Client-Formulierung verstehe ich ebenfalls nicht, ich muss wohl einsehen, dass die Bintec-Einrichtung das Wissen des fortgeschrittenen Abendstunden-Admins übersteigt. 
Ich lasse jetzt erst einmal wieder die Fritz!Boxen den VPN-Tunnel aufbauen. Eines der Bintecs wird nun zurück in den Karton verbannt, das andere Gateway wird dann halt eben nur als SIP-/ISDN-Trunk/VPN-Connector für eine Swyx genutzt (ich hoffe, dass mir wenigstens das gelingt).
Im Prinzip funktioniert das Netzwerk so tadellos und die 6360 scheint die Aufgabe irgendwie zu meistern. Lediglich das Webinterface reagiert z.T. nicht mehr. AVM verweist hier auf KabelDeutschland und denen ist es herzlich egal.
In unserem Netz finden sich ca. 50 Clients (ich weiß, so was darf man in einem Profiforum eigentlich gar nicht erzählen). Aber laut AVM "sind immer mehrere Hundert gleichzeitige IP-Verbindungen möglich". Meine Hoffnung ist, dass dann doch irgendwann in absehbarer Zeit der Routerzwang wegfällt und die Swyx die Telefonie vollständig übernehmen kann, das sollte die 6360 entlasten (das aktuelle Setup für ausgehende Rufe könnte komplizierter nicht sein: Swyx --> AVM VoIP Gateway 5188 --> Fritz!Box 6360).
Sollte es Probleme geben, werde ich die Bintecs noch einmal hervorkramen.
Ich danke für eure Hilfe und insbesondere den Einsatz! Großes Kino!
Ich lasse jetzt erst einmal wieder die Fritz!Boxen den VPN-Tunnel aufbauen. Eines der Bintecs wird nun zurück in den Karton verbannt, das andere Gateway wird dann halt eben nur als SIP-/ISDN-Trunk/VPN-Connector für eine Swyx genutzt (ich hoffe, dass mir wenigstens das gelingt
).Im Prinzip funktioniert das Netzwerk so tadellos und die 6360 scheint die Aufgabe irgendwie zu meistern. Lediglich das Webinterface reagiert z.T. nicht mehr. AVM verweist hier auf KabelDeutschland und denen ist es herzlich egal.
In unserem Netz finden sich ca. 50 Clients (ich weiß, so was darf man in einem Profiforum eigentlich gar nicht erzählen). Aber laut AVM "sind immer mehrere Hundert gleichzeitige IP-Verbindungen möglich". Meine Hoffnung ist, dass dann doch irgendwann in absehbarer Zeit der Routerzwang wegfällt und die Swyx die Telefonie vollständig übernehmen kann, das sollte die 6360 entlasten (das aktuelle Setup für ausgehende Rufe könnte komplizierter nicht sein: Swyx --> AVM VoIP Gateway 5188 --> Fritz!Box 6360).
Sollte es Probleme geben, werde ich die Bintecs noch einmal hervorkramen.
Ich danke für eure Hilfe und insbesondere den Einsatz! Großes Kino!
Wer wird denn da die Flinte ins Korn werfen? Hast Du etwa noch andere Hobbys?
50 Clients? Die FB ist ne Home-Lösung bzw. SOHO. Man müsste mal den Prozessor und den Speicher recherchieren, aber das ist mit Sicherheit nicht, was du brauchst um 50 Clients stabil und schnell per VPN zu connecten... Oder doch?
Das eigentliche Problem ist ja aber offenbar häufig nicht die IP-Sec VPN Konfiguration, sondern die Anforderung, diese in die Nomenklatur der verschiedenen Hersteller umzusetzen... Probiere doch mal, die Fritzbox auf der einen Seite mit der Bintec auf der anderen Seite zu connecten.
Trotzdem interessant zu wissen, dass die FB 50 Clients offenbar irgendwie managed, auch wenn ich für VPN FB's nur noch mit Zeitschaltuhr verkaufen werde, aber das ist ein anderes Thema...
Der Routerzwang ist doch so nicht vorhanden, wenn Du ein gebridgtes Modem verwenden kannst, oder?
Kino? Nope. Groß? Yep.
KD und AVM? Wäre nen eigenes Blog wert. Die arbeiten aber offenbar dran, immerhin.
Grüße
Buc
50 Clients? Die FB ist ne Home-Lösung bzw. SOHO. Man müsste mal den Prozessor und den Speicher recherchieren, aber das ist mit Sicherheit nicht, was du brauchst um 50 Clients stabil und schnell per VPN zu connecten... Oder doch?
Das eigentliche Problem ist ja aber offenbar häufig nicht die IP-Sec VPN Konfiguration, sondern die Anforderung, diese in die Nomenklatur der verschiedenen Hersteller umzusetzen... Probiere doch mal, die Fritzbox auf der einen Seite mit der Bintec auf der anderen Seite zu connecten.
Trotzdem interessant zu wissen, dass die FB 50 Clients offenbar irgendwie managed, auch wenn ich für VPN FB's nur noch mit Zeitschaltuhr verkaufen werde, aber das ist ein anderes Thema...
Der Routerzwang ist doch so nicht vorhanden, wenn Du ein gebridgtes Modem verwenden kannst, oder?
Kino? Nope. Groß? Yep.
KD und AVM? Wäre nen eigenes Blog wert. Die arbeiten aber offenbar dran, immerhin.
Grüße
Buc
