9
IPSec TR200bw zu R3000
Probleme mit dem Tunnel!
Hallo Forum,
ich habe zwischenzeitlich einiges zu diesem Thema in diesen und in anderen Foren gelesen und leider keine passenden Hinweise gefunden.
Auch habe ich die Anleitungen von Funkwerk als Basis für die Konfiguration genutzt.
Es sollte eigentlich nicht so schwer sein die entsprechende Konfiguration auf beiden Seiten vorzunehmen und damit ein funktionierendes VPN aufzubauen.
Kurz zu den Rahmenbedingungen:
Ich habe die Zentrale (TR200bw) und die Filiale (R3000). Auf beiden Routern ist die aktuelle Systemsoftware 7.5.1 Patch 6.
Beide Seiten nutzen eine dynamische IP über DynDns. Das funktioniert auch auf beiden Seiten.
Jetzt habe ich das Problem, dass sich der Tunnel von der R3000-Seite aufbaut, dies jedoch auf der TR200bw-Seite nicht.
Auf der R3000-Seite erscheint Peers Up: 1 / 1 Dormant: 0 Blocked: 0
SAs Phase1: 1 / 1 Phase2: 0 / 0
Auch wird auf der R3000-Seite die Remote ID - Remote IP - Local ID richtig angezeigt.
Auf der TR200bw-Seite steht bei Remote ID "No Id", die Remote IP und die Local ID sind jedoch richtig.
Hat jemand vielleicht noch ne Idee oder einen Tip aus eigenen Erfahrungen. Vielleicht bin ich ja auch schon zu langean dem Thema dran, so dass ich den Fehler nicht mehr sehe.
Wäre toll wenn sich jemand meldet und hierfür gleich meinen Dank vorab.
th
Hallo Forum,
ich habe zwischenzeitlich einiges zu diesem Thema in diesen und in anderen Foren gelesen und leider keine passenden Hinweise gefunden.
Auch habe ich die Anleitungen von Funkwerk als Basis für die Konfiguration genutzt.
Es sollte eigentlich nicht so schwer sein die entsprechende Konfiguration auf beiden Seiten vorzunehmen und damit ein funktionierendes VPN aufzubauen.
Kurz zu den Rahmenbedingungen:
Ich habe die Zentrale (TR200bw) und die Filiale (R3000). Auf beiden Routern ist die aktuelle Systemsoftware 7.5.1 Patch 6.
Beide Seiten nutzen eine dynamische IP über DynDns. Das funktioniert auch auf beiden Seiten.
Jetzt habe ich das Problem, dass sich der Tunnel von der R3000-Seite aufbaut, dies jedoch auf der TR200bw-Seite nicht.
Auf der R3000-Seite erscheint Peers Up: 1 / 1 Dormant: 0 Blocked: 0
SAs Phase1: 1 / 1 Phase2: 0 / 0
Auch wird auf der R3000-Seite die Remote ID - Remote IP - Local ID richtig angezeigt.
Auf der TR200bw-Seite steht bei Remote ID "No Id", die Remote IP und die Local ID sind jedoch richtig.
Hat jemand vielleicht noch ne Idee oder einen Tip aus eigenen Erfahrungen. Vielleicht bin ich ja auch schon zu langean dem Thema dran, so dass ich den Fehler nicht mehr sehe.
Wäre toll wenn sich jemand meldet und hierfür gleich meinen Dank vorab.
th
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: 86028
Url: https://administrator.de/forum/ipsec-tr200bw-zu-r3000-86028.html
Ausgedruckt am: 24.12.2024 um 13:12 Uhr
9 Kommentare
Neuester Kommentar
Hallo th,
ein paar mehr Einzelheiten wären hilfreich.
Phase1/Phase2 Settings pro Router
Syslog (auf IPSEC gefiltert) pro Router
NAT Settings pro Router
SIF (so aktiv) pro Router
Portfilter (so aktiv) pro Router
Grüße, Steffen
ein paar mehr Einzelheiten wären hilfreich.
Phase1/Phase2 Settings pro Router
Syslog (auf IPSEC gefiltert) pro Router
NAT Settings pro Router
SIF (so aktiv) pro Router
Portfilter (so aktiv) pro Router
Grüße, Steffen
Hallo Steffen,
vielen Dank für die schnelle Reaktion.
Zwischenzeitlich hatte ich eine Verbindung zum R3000. Ich konnte mich anmelden. Nach einer kurzen Zeit war die Verbindung wieder weg und kam auch nicht mehr zustande.
So, hier erst einmal einige Details:
Phase1 (gilt für beide Router bis auf die Local ID):
Proposal: (DES3/MD5)
Lifetime Policy: Use default lifetime settings
Group: (1024 bit MODP)
Authentication Method: Pre Shared Keys
Mode: aggressive
Alive Check: Heartbeats (send and expect)
Block Time: 0
Local ID: die von TR200bw auf R3000 und umgekehrt
Local Certificate: none
CA Certificates:
Nat - Travelsal: enabled
Phase2 (gilt auch für beide Router)
Proposal: (ESP(DES3/MD5) no Comp)
Lifetime Policy: Use default lifetime settings
Use PFS: group 2 (1024 bit MODP)
Alive Check: Heartbeats (send and expect)
Propagate PMTU: no
Traffic List
Local Address M/R Port Proto Remote Address M/R Port A Proposal
*192.168.10.0 M24 500 udp 192.168.0.0 M24 500 PA
0.0.0.0 M0 500 udp 0.0.0.0 M0 500 PA
Basic IP-Settings:
IP Transit Network no
Local IP Address 192.168.10.100
Default Route no
Remote IP Address 192.168.0.0
Remote Netmask 255.255.255.0
Virtual Interface: yes
[PEERS][EDIT][SPECIAL][IP][ROUTING][EDIT]
Route Type Network route
Network WAN without transit network
Destination IP-Address 192.168.0.0
Netmask 255.255.255.0
Partner / Interface Name des Interface
Metric 1
[ADVANCED]: IPsec Configuration - Advanced Settings
Ignore Cert Req Payloads : no
Dont send Cert Req Payl. : no
Dont Send Cert Chains : no
Dont send CRLs : yes
Dont send Key Hash Payl. : no
Trust ICMP Messages : no
Dont Send Initial Contact: no
Sync SAs With Local Ifc : yes
Max. Symmetric Key Length: 1024
Use Zero Cookies : no
RADIUS Authentication : disabled
[IP][NAT][EDIT]..[EDIT]: NAT - sessions from OUTSIDE
Service user defined
Protocol any
Remote Address
Remote Mask
External Address
External Mask
External Port any
Internal Address 192.168.10.100
Internal Mask 255.255.255.255
Internal Port any
Syslog ist in Arbeit und wird nachgereicht!
Leider kann ich vorerst nur das Log des TR200bw liefern. An den R3000 komme ich so schnell nicht ran.
Mit der o.g. Konfiguration kam die Verbindung zustande. Habe noch nichts geändert.
Mercy, th
vielen Dank für die schnelle Reaktion.
Zwischenzeitlich hatte ich eine Verbindung zum R3000. Ich konnte mich anmelden. Nach einer kurzen Zeit war die Verbindung wieder weg und kam auch nicht mehr zustande.
So, hier erst einmal einige Details:
Phase1 (gilt für beide Router bis auf die Local ID):
Proposal: (DES3/MD5)
Lifetime Policy: Use default lifetime settings
Group: (1024 bit MODP)
Authentication Method: Pre Shared Keys
Mode: aggressive
Alive Check: Heartbeats (send and expect)
Block Time: 0
Local ID: die von TR200bw auf R3000 und umgekehrt
Local Certificate: none
CA Certificates:
Nat - Travelsal: enabled
Phase2 (gilt auch für beide Router)
Proposal: (ESP(DES3/MD5) no Comp)
Lifetime Policy: Use default lifetime settings
Use PFS: group 2 (1024 bit MODP)
Alive Check: Heartbeats (send and expect)
Propagate PMTU: no
Traffic List
Local Address M/R Port Proto Remote Address M/R Port A Proposal
*192.168.10.0 M24 500 udp 192.168.0.0 M24 500 PA
0.0.0.0 M0 500 udp 0.0.0.0 M0 500 PA
Basic IP-Settings:
IP Transit Network no
Local IP Address 192.168.10.100
Default Route no
Remote IP Address 192.168.0.0
Remote Netmask 255.255.255.0
Virtual Interface: yes
[PEERS][EDIT][SPECIAL][IP][ROUTING][EDIT]
Route Type Network route
Network WAN without transit network
Destination IP-Address 192.168.0.0
Netmask 255.255.255.0
Partner / Interface Name des Interface
Metric 1
[ADVANCED]: IPsec Configuration - Advanced Settings
Ignore Cert Req Payloads : no
Dont send Cert Req Payl. : no
Dont Send Cert Chains : no
Dont send CRLs : yes
Dont send Key Hash Payl. : no
Trust ICMP Messages : no
Dont Send Initial Contact: no
Sync SAs With Local Ifc : yes
Max. Symmetric Key Length: 1024
Use Zero Cookies : no
RADIUS Authentication : disabled
[IP][NAT][EDIT]..[EDIT]: NAT - sessions from OUTSIDE
Service user defined
Protocol any
Remote Address
Remote Mask
External Address
External Mask
External Port any
Internal Address 192.168.10.100
Internal Mask 255.255.255.255
Internal Port any
Syslog ist in Arbeit und wird nachgereicht!
Leider kann ich vorerst nur das Log des TR200bw liefern. An den R3000 komme ich so schnell nicht ran.
Mit der o.g. Konfiguration kam die Verbindung zustande. Habe noch nichts geändert.
Mercy, th
... so, das sind die Meldungen wenn eine Verbindung aufgebaut werden soll.
Sieht so aus als können die Schlüssel nicht sauber ausgetauscht werden.
Vielleicht hängt das mit der Lifetime Policy zusammen!?
22:04:18 INFO/INET: NAT: refused incoming session on ifc 10001 prot 17 79.xxx.xx
x.204:20753 <- 79.xxx.xx.241:34137
22:05:04 INFO/INET: NAT: refused incoming session on ifc 10001 prot 17 79.xxx.xx
x.204:20753 <- 80.xxx.xxx.212:37031
22:05:05 DEBUG/IPSEC: IKE_RETRY_LIMIT_REACHED: 20080421220505: SPI:0x90a1cdb63
d7f7045 Source addr:79.xxx.xxx.204 Destination addr:79.xxx.xx.71 Description:
ISAKMP negotiation retry limit reached
22:05:05 INFO/IPSEC: P1: peer 1 (Peer-Kennung) sa 1455 (I): failed id fqdn(any:0
,[0..11]=Local ID) -> ip 79.xxx.xx.71 (Timeout)
22:05:05 INFO/IPSEC: P1: peer 1 (Peer-Kennung) sa 0 (-): blocked for 15 seconds
22:05:05 INFO/IPSEC: P1: peer 1 (Peer-Kennung) sa 1455 (I): delete ip 79.xxx.xxx
.204 -> ip 79.xxx.xx.71: Blocked
22:05:06 DEBUG/INET: NAT: delete session on ifc 10001 prot 17 79.xxx.xxx.204:500
/79.xxx.xxx.204:1023 <-> 79.xxx.xx.71:500
22:05:19 INFO/IPSEC: P1: peer 1 (Peer-Kennung) sa 0 (-): reactivated
22:05:19 DEBUG/IPSEC: P1: peer 1 (Peer-Kennung) sa 0 (-): Automatic dialup
22:05:19 DEBUG/INET: NAT: new outgoing session on ifc 10001 prot 17 79.xxx.xxx.2
04:1030/79.xxx.xxx.204:34635 -> 194.25.2.129:53
22:05:19 DEBUG/INET: NAT: new outgoing session on ifc 10001 prot 17 79.xxx.xxx.2
04:500/79.220.xxx.xxx:1023 -> 79.xxx.xx.71:500
22:05:19 DEBUG/IPSEC: P1: peer 1 (Peer-Kennung) sa 1456 (I): identified ip 79.xxx.
xxx.204 -> ip 79.xxx.xx.71
Sieht so aus als können die Schlüssel nicht sauber ausgetauscht werden.
Vielleicht hängt das mit der Lifetime Policy zusammen!?
22:04:18 INFO/INET: NAT: refused incoming session on ifc 10001 prot 17 79.xxx.xx
x.204:20753 <- 79.xxx.xx.241:34137
22:05:04 INFO/INET: NAT: refused incoming session on ifc 10001 prot 17 79.xxx.xx
x.204:20753 <- 80.xxx.xxx.212:37031
22:05:05 DEBUG/IPSEC: IKE_RETRY_LIMIT_REACHED: 20080421220505: SPI:0x90a1cdb63
d7f7045 Source addr:79.xxx.xxx.204 Destination addr:79.xxx.xx.71 Description:
ISAKMP negotiation retry limit reached
22:05:05 INFO/IPSEC: P1: peer 1 (Peer-Kennung) sa 1455 (I): failed id fqdn(any:0
,[0..11]=Local ID) -> ip 79.xxx.xx.71 (Timeout)
22:05:05 INFO/IPSEC: P1: peer 1 (Peer-Kennung) sa 0 (-): blocked for 15 seconds
22:05:05 INFO/IPSEC: P1: peer 1 (Peer-Kennung) sa 1455 (I): delete ip 79.xxx.xxx
.204 -> ip 79.xxx.xx.71: Blocked
22:05:06 DEBUG/INET: NAT: delete session on ifc 10001 prot 17 79.xxx.xxx.204:500
/79.xxx.xxx.204:1023 <-> 79.xxx.xx.71:500
22:05:19 INFO/IPSEC: P1: peer 1 (Peer-Kennung) sa 0 (-): reactivated
22:05:19 DEBUG/IPSEC: P1: peer 1 (Peer-Kennung) sa 0 (-): Automatic dialup
22:05:19 DEBUG/INET: NAT: new outgoing session on ifc 10001 prot 17 79.xxx.xxx.2
04:1030/79.xxx.xxx.204:34635 -> 194.25.2.129:53
22:05:19 DEBUG/INET: NAT: new outgoing session on ifc 10001 prot 17 79.xxx.xxx.2
04:500/79.220.xxx.xxx:1023 -> 79.xxx.xx.71:500
22:05:19 DEBUG/IPSEC: P1: peer 1 (Peer-Kennung) sa 1456 (I): identified ip 79.xxx.
xxx.204 -> ip 79.xxx.xx.71
22:05:05 INFO/IPSEC: P1: peer 1 (Peer-Kennung) sa 1455 (I): failed id fqdn(any:0,[0..11]=Local ID) -> ip 79.xxx.xx.71 (Timeout)
Stimmen die Local und Peer IDs auf beiden Seiten überein (wobei du ja meinst, das es schon funktionierte...)?
Grüße, Steffen
Hallo th,
wenn die Router auf beiden Seiten das NAT selbst erledigen, kannst du NAT-Traversal abschalten.
Grüße, Steffen
Nat - Travelsal: enabled
wenn die Router auf beiden Seiten das NAT selbst erledigen, kannst du NAT-Traversal abschalten.
Grüße, Steffen
Hallo Steffen,
ja, die ID´s sind gleich. Ich habe auch fast keine Idee mehr.
So kompliziert ist doch so eine Konfiguration wirklich nicht.
Nur noch einmal zum Verständnis.
Zentrale Peer ID: fritzchen
Zentrale Local ID : 123456789
Standort Peer ID: fritzchen
Standort Local ID: 123456789
So wie es im Logfile zu sehen ist, scheitert der Austausch der Schlüssel in der Phase1.
Da muss irgendwo ein Dreher in den ID´s sein!
Warum ich gestern mit genau dieser Konfig eine Verbindung hatte ist mir ein Rätsel.
Ich werde mich heute wohl mal ins Auto setzen und mir die Konfig auf der R3000-Seite ansehen und neue ID´s vergeben. Hoffentlich klappt es dann.
Vorsetzung folgt.
Gruß
th
ja, die ID´s sind gleich. Ich habe auch fast keine Idee mehr.
So kompliziert ist doch so eine Konfiguration wirklich nicht.
Nur noch einmal zum Verständnis.
Zentrale Peer ID: fritzchen
Zentrale Local ID : 123456789
Standort Peer ID: fritzchen
Standort Local ID: 123456789
So wie es im Logfile zu sehen ist, scheitert der Austausch der Schlüssel in der Phase1.
Da muss irgendwo ein Dreher in den ID´s sein!
Warum ich gestern mit genau dieser Konfig eine Verbindung hatte ist mir ein Rätsel.
Ich werde mich heute wohl mal ins Auto setzen und mir die Konfig auf der R3000-Seite ansehen und neue ID´s vergeben. Hoffentlich klappt es dann.
Vorsetzung folgt.
Gruß
th
Hallo th,
versuche doch mal 'echte' FQDN zu verwenden, z.B.:
Router1:
Phase 1 Profile -> Local ID: router1.standort.vpn
Configure Peer -> Peer ID: router2.standort.vpn
Router2:
Phase 1 Profile -> Local ID: router2.standort.vpn
Configure Peer -> Peer ID: router1.standort.vpn
Zumindest in Verbindung mit dem Secure IPSec Client ist die richtige Definition FQDN/FQUN wichtig.
PS: Mit SSH und/oder Isdnlogin muß man dazu nicht hinfahren.
Grüße, Steffen
Zentrale Peer ID: fritzchen
Zentrale Local ID : 123456789
Standort Peer ID: fritzchen
Standort Local ID: 123456789
Zentrale Local ID : 123456789
Standort Peer ID: fritzchen
Standort Local ID: 123456789
versuche doch mal 'echte' FQDN zu verwenden, z.B.:
Router1:
Phase 1 Profile -> Local ID: router1.standort.vpn
Configure Peer -> Peer ID: router2.standort.vpn
Router2:
Phase 1 Profile -> Local ID: router2.standort.vpn
Configure Peer -> Peer ID: router1.standort.vpn
Zumindest in Verbindung mit dem Secure IPSec Client ist die richtige Definition FQDN/FQUN wichtig.
PS: Mit SSH und/oder Isdnlogin muß man dazu nicht hinfahren.
Grüße, Steffen
Hallo Steffen,
Deine Darstellung der Vergabe der ID´s ist natürlich richtig. So ist es auch konfiguriert.
Ich versuche das mal mit den FQDN/FQUN.
Leider steht mit auf der R3000-Seite kein ISDN-Anschluss zur Verfügung. Daran mußte ich auch die letzten Tage immer wieder denken. Da wäre schön einfach.
Gruß
th
Deine Darstellung der Vergabe der ID´s ist natürlich richtig. So ist es auch konfiguriert.
Ich versuche das mal mit den FQDN/FQUN.
Leider steht mit auf der R3000-Seite kein ISDN-Anschluss zur Verfügung. Daran mußte ich auch die letzten Tage immer wieder denken. Da wäre schön einfach.
Gruß
th
... so, es ist geschafft!
Ich bin hingefahren und habe bei dem R3000 eine fragmentierte Konfiguration vorgefunden. ADSL war aktiv, jedoch gab es keine Anschlusskennung oder sonstige Angaben in dieser Hinsicht mehr. DynDNS stand auf failed!. Ich habe den Router dann aus- und wieder eingeschaltet. Jetzt war er nahezu im Werkszustand. Keine Ahnung was passiert ist. Habe dann auch in diesem Moment gemerkt, das ich die DSL Kennung und das Password zu Hause vergessen habe. Als wieder zurück und wieder hin. Konfiguriert via Wizzard und dann noch schnell das voreingestellte Annex A auf Annex B umgestellt und siehe da, es funktioniert.
Also alles tutti!
Besten Dank für die Unterstützung
Ich bin hingefahren und habe bei dem R3000 eine fragmentierte Konfiguration vorgefunden. ADSL war aktiv, jedoch gab es keine Anschlusskennung oder sonstige Angaben in dieser Hinsicht mehr. DynDNS stand auf failed!. Ich habe den Router dann aus- und wieder eingeschaltet. Jetzt war er nahezu im Werkszustand. Keine Ahnung was passiert ist. Habe dann auch in diesem Moment gemerkt, das ich die DSL Kennung und das Password zu Hause vergessen habe. Als wieder zurück und wieder hin. Konfiguriert via Wizzard und dann noch schnell das voreingestellte Annex A auf Annex B umgestellt und siehe da, es funktioniert.
Also alles tutti!
Besten Dank für die Unterstützung
