2
Probleme mit Cisco-Router (als VPNKonzentrator) hinter Fritz-Box
Hallo, ich habe Probleme beim Verbinden auf den Router von einem VPN-Client aus.
Ich nutze eine Fritzbox-7170, um den DSL-Anschluss zu terminieren. Hinter der Fritzbox hängt ein Cisco 1720.
Den Cisco-Router hatte ich bis vor einigen Wochen direkt an einem DSL-Anschluss hängen, dabei war der Router
selbst für den Aufbau der PPPoe-verbindung zuständig und diente mir zeitgleich als VPN-Konzentrator (an einem DSL-Modem).
Nachdem ich nun die Fritz-Box 7170 als Router verwende würde ich den Cisco-Router nach wie vor als VPNKonzentrator nutzen.
Hierfür habe ich die Konfiguration entsprechend angepasst, wobei ich aber Probleme mit dem Connect der VPN-Clients von extern habe.
Verbindungen im gleichen Netzwerk (von intern) funktionieren einwandfrei, wobei dies aber logischerweise nicht Sinn der Sache ist.
Ich habe nun zwischenzeitlich einige Versuche unternommen die Problematik zu beseitigen- hierbei ist mir aufgefallen,
dass bei der Nutzung des Encryption-Protokolls 3DES (so wie ich es früher auch konfiguriert hatte), immer die Meldung
"atts are not acceptable. Next payload is 3" bekommen habe. Nachdem ich "encr aes" konfiguriert habe, kommen nun weitere
Meldungen.
Auf der FritzBox habe ich alle benötigten Ports zum Cisco-Router geforwarded (selbst ein pauschaler Forward des gesamten
Traffic zum Cisco-Router schafft keine Abhilfe bzw. Änderung.
Mir ist allerdings nicht klar, warum die Phase 1 nicht richtig abgeschlossen werden kann, bzw. wo das Problem liegen kann.
Der einzige Unterschied ist letztendlich, dass der Cisco-Router nun hinter der Fritz-Box hängt- ich könnte mir vorstellen,
dass es dort irgendwelche Probleme mit der MTU-Size geben und der VPN-Verkehr fragmentiert werden könnte.
Mir erscheint es so, als bekäme der VPN-Client keinerlei Rückmeldung vom Cisco-Router (über die Fritz-Box, die neben dem
PPPoe auch für das NAT zuständig ist...)
Unverständlich ist mir ebenfalls, dass ich das Protokoll von 3DES auf AES ändern musste.
Der Cisco-VPN-Client terminiert übrigens mit der Fehlermeldung "Reason 412: Peer is no longer responding."
Bei Bedarf habe ich die Router-Konfiguration vorliegen, die kompletten Cisco-Router-Logs (Auszug schon in diesem Post).
Die Cisco-Client-Logs habe ich schon hier in diesem Post angehängt...
Schonmal danke für Eure Tips- ich komme hier wirklich nicht mehr alleine weiter.
Viele Grüße,
termineter
Hier ein Auszug aus dem Log des Clients:
1 14:32:46.287 09/21/08 Sev=Info/6 GUI/0x63B00011
Reloaded the Certificates in all Certificate Stores successfully.
2 14:32:48.344 09/21/08 Sev=Info/4 CM/0x63100002
Begin connection process
3 14:32:48.354 09/21/08 Sev=Info/4 CM/0x63100004
Establish secure connection
4 14:32:48.354 09/21/08 Sev=Info/4 CM/0x63100024
Attempt connection with server "1und1-router.dynalias.org"
5 14:32:48.427 09/21/08 Sev=Info/6 IKE/0x6300003B
Attempting to establish a connection with 79.220.26.142.
6 14:32:48.436 09/21/08 Sev=Info/4 IKE/0x63000013
SENDING >>> ISAKMP OAK AG (SA, KE, NON, ID, VID(Xauth), VID(dpd), VID(Unity)) to 79.220.26.142
7 14:32:48.511 09/21/08 Sev=Info/4 IPSEC/0x63700008
IPSec driver successfully started
8 14:32:48.511 09/21/08 Sev=Info/4 IPSEC/0x63700014
Deleted all keys
9 14:32:53.581 09/21/08 Sev=Info/4 IKE/0x63000021
Retransmitting last packet!
10 14:32:53.581 09/21/08 Sev=Info/4 IKE/0x63000013
SENDING >>> ISAKMP OAK AG (Retransmission) to 79.220.26.142
11 14:32:58.656 09/21/08 Sev=Info/4 IKE/0x63000021
Retransmitting last packet!
12 14:32:58.656 09/21/08 Sev=Info/4 IKE/0x63000013
SENDING >>> ISAKMP OAK AG (Retransmission) to 79.220.26.142
13 14:33:03.721 09/21/08 Sev=Info/4 IKE/0x63000021
Retransmitting last packet!
14 14:33:03.721 09/21/08 Sev=Info/4 IKE/0x63000013
SENDING >>> ISAKMP OAK AG (Retransmission) to 79.220.26.142
15 14:33:08.795 09/21/08 Sev=Info/4 IKE/0x63000017
Marking IKE SA for deletion (I_Cookie=361E9B72846D421F R_Cookie=0000000000000000) reason = DEL_REASON_PEER_NOT_RESPONDING
16 14:33:09.305 09/21/08 Sev=Info/4 IKE/0x6300004B
Discarding IKE SA negotiation (I_Cookie=361E9B72846D421F R_Cookie=0000000000000000) reason = DEL_REASON_PEER_NOT_RESPONDING
17 14:33:09.305 09/21/08 Sev=Info/4 CM/0x63100014
Unable to establish Phase 1 SA with server "1und1-router.dynalias.org" because of "DEL_REASON_PEER_NOT_RESPONDING"
18 14:33:09.305 09/21/08 Sev=Info/5 CM/0x63100025
Initializing CVPNDrv
19 14:33:09.308 09/21/08 Sev=Info/6 CM/0x63100046
Set tunnel established flag in registry to 0.
20 14:33:09.308 09/21/08 Sev=Info/4 IKE/0x63000001
IKE received signal to terminate VPN connection
21 14:33:09.316 09/21/08 Sev=Info/4 IPSEC/0x63700014
Deleted all keys
Meldungen nachdem Encrpytion-Protokoll von 3DES auf AES geändert wurde:
040070: Aug 1 13:30:52.133 MEZ+1: ISAKMP: keylength of 128
040071: Aug 1 13:30:52.133 MEZ+1: ISAKMP (0:1): atts are acceptable. Next payload is 3
040072: Aug 1 13:30:52.133 MEZ+1: CryptoEngine0: generating alg parameter for connid 1
040073: Aug 1 13:30:52.347 MEZ+1: CRYPTO_ENGINE: Dh phase 1 status: 0
040074: Aug 1 13:30:52.347 MEZ+1: CRYPTO_ENGINE: Dh phase 1 status: OK
040075: Aug 1 13:30:52.351 MEZ+1: ISAKMP (0:1): processing KE payload. message ID = 0
040076: Aug 1 13:30:52.351 MEZ+1: CryptoEngine0: generating alg parameter for connid 0
040077: Aug 1 13:30:52.617 MEZ+1: ISAKMP (0:1): processing NONCE payload. message ID = 0
040078: Aug 1 13:30:52.621 MEZ+1: ISAKMP (0:1): Input = IKE_MESG_FROM_PEER, IKE_AM_EXCH
040079: Aug 1 13:30:52.621 MEZ+1: ISAKMP (0:1): Old State = IKE_READY New State = IKE_R_AM_AAA_AWAIT
040080: Aug 1 13:30:52.625 MEZ+1: ISAKMP: got callback 1
040081: Aug 1 13:30:52.629 MEZ+1: CryptoEngine0: create ISAKMP SKEYID for conn id 1
040082: Aug 1 13:30:52.629 MEZ+1: ISAKMP (0:1): SKEYID state generated
040083: Aug 1 13:30:52.633 MEZ+1: ISAKMP (0:1): SA is doing pre-shared key authentication plus XAUTH using id type ID_IPV4_ADDR
040084: Aug 1 13:30:52.633 MEZ+1: ISAKMP (1): ID payload
next-payload : 10
type : 1
addr : 192.168.3.1
protocol : 17
port : 0
length : 8
040085: Aug 1 13:30:52.633 MEZ+1: ISAKMP (1): Total payload length: 12
040086: Aug 1 13:30:52.633 MEZ+1: CryptoEngine0: generate hmac context for conn id 1
040087: Aug 1 13:30:52.637 MEZ+1: ISAKMP (0:1): sending packet to 89.12.68.173 my_port 500 peer_port 51638 (R) AG_INIT_EXCH
040088: Aug 1 13:30:52.637 MEZ+1: ISAKMP (0:1): Input = IKE_MESG_FROM_AAA, PRESHARED_KEY_REPLY
040089: Aug 1 13:30:52.637 MEZ+1: ISAKMP (0:1): Old State = IKE_R_AM_AAA_AWAIT New State = IKE_R_AM2
040090: Aug 1 13:30:57.105 MEZ+1: ISAKMP (0:1): received packet from 89.12.68.173 dport 500 sport 51638 Global (R) AG_INIT_EXCH
040091: Aug 1 13:30:57.105 MEZ+1: ISAKMP (0:1): phase 1 packet is a duplicate of a previous packet.
040092: Aug 1 13:30:57.105 MEZ+1: ISAKMP (0:1): retransmitting due to retransmit phase 1
040127: Aug 1 13:31:37.423 MEZ+1: ISAKMP (0:1): Old State = IKE_R_AM2 New State = IKE_DEST_SA
dass bei der Nutzung des Encryption-Protokolls 3DES (so wie ich es früher auch konfiguriert hatte), immer die Meldung
"atts are not acceptable. Next payload is 3" bekommen habe. Nachdem ich "encr aes" konfiguriert habe, kommen nun weitere
Meldungen.
Auf der FritzBox habe ich alle benötigten Ports zum Cisco-Router geforwarded (selbst ein pauschaler Forward des gesamten
Traffic zum Cisco-Router schafft keine Abhilfe bzw. Änderung.
Mir ist allerdings nicht klar, warum die Phase 1 nicht richtig abgeschlossen werden kann, bzw. wo das Problem liegen kann.
Der einzige Unterschied ist letztendlich, dass der Cisco-Router nun hinter der Fritz-Box hängt- ich könnte mir vorstellen,
dass es dort irgendwelche Probleme mit der MTU-Size geben und der VPN-Verkehr fragmentiert werden könnte.
Mir erscheint es so, als bekäme der VPN-Client keinerlei Rückmeldung vom Cisco-Router (über die Fritz-Box, die neben dem
PPPoe auch für das NAT zuständig ist...)
Unverständlich ist mir ebenfalls, dass ich das Protokoll von 3DES auf AES ändern musste.
Der Cisco-VPN-Client terminiert übrigens mit der Fehlermeldung "Reason 412: Peer is no longer responding."
Bei Bedarf habe ich die Router-Konfiguration vorliegen, die kompletten Cisco-Router-Logs (Auszug schon in diesem Post).
Die Cisco-Client-Logs habe ich schon hier in diesem Post angehängt...
Schonmal danke für Eure Tips- ich komme hier wirklich nicht mehr alleine weiter.
Viele Grüße,
termineter
Hier ein Auszug aus dem Log des Clients:
1 14:32:46.287 09/21/08 Sev=Info/6 GUI/0x63B00011
Reloaded the Certificates in all Certificate Stores successfully.
2 14:32:48.344 09/21/08 Sev=Info/4 CM/0x63100002
Begin connection process
3 14:32:48.354 09/21/08 Sev=Info/4 CM/0x63100004
Establish secure connection
4 14:32:48.354 09/21/08 Sev=Info/4 CM/0x63100024
Attempt connection with server "1und1-router.dynalias.org"
5 14:32:48.427 09/21/08 Sev=Info/6 IKE/0x6300003B
Attempting to establish a connection with 79.220.26.142.
6 14:32:48.436 09/21/08 Sev=Info/4 IKE/0x63000013
SENDING >>> ISAKMP OAK AG (SA, KE, NON, ID, VID(Xauth), VID(dpd), VID(Unity)) to 79.220.26.142
7 14:32:48.511 09/21/08 Sev=Info/4 IPSEC/0x63700008
IPSec driver successfully started
8 14:32:48.511 09/21/08 Sev=Info/4 IPSEC/0x63700014
Deleted all keys
9 14:32:53.581 09/21/08 Sev=Info/4 IKE/0x63000021
Retransmitting last packet!
10 14:32:53.581 09/21/08 Sev=Info/4 IKE/0x63000013
SENDING >>> ISAKMP OAK AG (Retransmission) to 79.220.26.142
11 14:32:58.656 09/21/08 Sev=Info/4 IKE/0x63000021
Retransmitting last packet!
12 14:32:58.656 09/21/08 Sev=Info/4 IKE/0x63000013
SENDING >>> ISAKMP OAK AG (Retransmission) to 79.220.26.142
13 14:33:03.721 09/21/08 Sev=Info/4 IKE/0x63000021
Retransmitting last packet!
14 14:33:03.721 09/21/08 Sev=Info/4 IKE/0x63000013
SENDING >>> ISAKMP OAK AG (Retransmission) to 79.220.26.142
15 14:33:08.795 09/21/08 Sev=Info/4 IKE/0x63000017
Marking IKE SA for deletion (I_Cookie=361E9B72846D421F R_Cookie=0000000000000000) reason = DEL_REASON_PEER_NOT_RESPONDING
16 14:33:09.305 09/21/08 Sev=Info/4 IKE/0x6300004B
Discarding IKE SA negotiation (I_Cookie=361E9B72846D421F R_Cookie=0000000000000000) reason = DEL_REASON_PEER_NOT_RESPONDING
17 14:33:09.305 09/21/08 Sev=Info/4 CM/0x63100014
Unable to establish Phase 1 SA with server "1und1-router.dynalias.org" because of "DEL_REASON_PEER_NOT_RESPONDING"
18 14:33:09.305 09/21/08 Sev=Info/5 CM/0x63100025
Initializing CVPNDrv
19 14:33:09.308 09/21/08 Sev=Info/6 CM/0x63100046
Set tunnel established flag in registry to 0.
20 14:33:09.308 09/21/08 Sev=Info/4 IKE/0x63000001
IKE received signal to terminate VPN connection
21 14:33:09.316 09/21/08 Sev=Info/4 IPSEC/0x63700014
Deleted all keys
Meldungen nachdem Encrpytion-Protokoll von 3DES auf AES geändert wurde:
040070: Aug 1 13:30:52.133 MEZ+1: ISAKMP: keylength of 128
040071: Aug 1 13:30:52.133 MEZ+1: ISAKMP (0:1): atts are acceptable. Next payload is 3
040072: Aug 1 13:30:52.133 MEZ+1: CryptoEngine0: generating alg parameter for connid 1
040073: Aug 1 13:30:52.347 MEZ+1: CRYPTO_ENGINE: Dh phase 1 status: 0
040074: Aug 1 13:30:52.347 MEZ+1: CRYPTO_ENGINE: Dh phase 1 status: OK
040075: Aug 1 13:30:52.351 MEZ+1: ISAKMP (0:1): processing KE payload. message ID = 0
040076: Aug 1 13:30:52.351 MEZ+1: CryptoEngine0: generating alg parameter for connid 0
040077: Aug 1 13:30:52.617 MEZ+1: ISAKMP (0:1): processing NONCE payload. message ID = 0
040078: Aug 1 13:30:52.621 MEZ+1: ISAKMP (0:1): Input = IKE_MESG_FROM_PEER, IKE_AM_EXCH
040079: Aug 1 13:30:52.621 MEZ+1: ISAKMP (0:1): Old State = IKE_READY New State = IKE_R_AM_AAA_AWAIT
040080: Aug 1 13:30:52.625 MEZ+1: ISAKMP: got callback 1
040081: Aug 1 13:30:52.629 MEZ+1: CryptoEngine0: create ISAKMP SKEYID for conn id 1
040082: Aug 1 13:30:52.629 MEZ+1: ISAKMP (0:1): SKEYID state generated
040083: Aug 1 13:30:52.633 MEZ+1: ISAKMP (0:1): SA is doing pre-shared key authentication plus XAUTH using id type ID_IPV4_ADDR
040084: Aug 1 13:30:52.633 MEZ+1: ISAKMP (1): ID payload
next-payload : 10
type : 1
addr : 192.168.3.1
protocol : 17
port : 0
length : 8
040085: Aug 1 13:30:52.633 MEZ+1: ISAKMP (1): Total payload length: 12
040086: Aug 1 13:30:52.633 MEZ+1: CryptoEngine0: generate hmac context for conn id 1
040087: Aug 1 13:30:52.637 MEZ+1: ISAKMP (0:1): sending packet to 89.12.68.173 my_port 500 peer_port 51638 (R) AG_INIT_EXCH
040088: Aug 1 13:30:52.637 MEZ+1: ISAKMP (0:1): Input = IKE_MESG_FROM_AAA, PRESHARED_KEY_REPLY
040089: Aug 1 13:30:52.637 MEZ+1: ISAKMP (0:1): Old State = IKE_R_AM_AAA_AWAIT New State = IKE_R_AM2
040090: Aug 1 13:30:57.105 MEZ+1: ISAKMP (0:1): received packet from 89.12.68.173 dport 500 sport 51638 Global (R) AG_INIT_EXCH
040091: Aug 1 13:30:57.105 MEZ+1: ISAKMP (0:1): phase 1 packet is a duplicate of a previous packet.
040092: Aug 1 13:30:57.105 MEZ+1: ISAKMP (0:1): retransmitting due to retransmit phase 1
040127: Aug 1 13:31:37.423 MEZ+1: ISAKMP (0:1): Old State = IKE_R_AM2 New State = IKE_DEST_SA
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: 97438
Url: https://administrator.de/contentid/97438
Printed on: April 24, 2024 at 22:04 o'clock
2 Comments
Latest comment
Das hiesige Cisco Tutorial genau gelesen ??
Cisco 880, 890 und ISR Router Konfiguration mit xDSL, Kabel oder FTTH Anschluss plus VPN und IP-TV
Cisco macht IPsec im ESP Modus mit seinem VPN Client. Wenn du also diesen verwendest musst du an der NAT Firewall der FB die Ports:
IKE = UDP 500
NAT-T = UDP 4500
ESP = IP Protokoll Nr.: 51 (Achtung: Nicht TCP/UDP 51 !!)
forwarden, damit es korrekt funktioniert !
Wenn es lokal funktioniert kannst du davon ausgehen, das die Cisco VPN Konfig ja in Ordnung ist.
Um das ganz genau zu analysieren woran es liegt klemmst du zwischen Client und Cisco einen Wireshark oder Net-Monitor und snifferst die Pakete mit bei einem Verbindungsaufbau !
Das vergleichst du dann analog mit einem Verbindungsaufbau mit der NAT Firewall der FB dazwischen. Dann sieht man meist die Unterschiede und Ursachen auf einen Blick !
Cisco 880, 890 und ISR Router Konfiguration mit xDSL, Kabel oder FTTH Anschluss plus VPN und IP-TV
Cisco macht IPsec im ESP Modus mit seinem VPN Client. Wenn du also diesen verwendest musst du an der NAT Firewall der FB die Ports:
IKE = UDP 500
NAT-T = UDP 4500
ESP = IP Protokoll Nr.: 51 (Achtung: Nicht TCP/UDP 51 !!)
forwarden, damit es korrekt funktioniert !
Wenn es lokal funktioniert kannst du davon ausgehen, das die Cisco VPN Konfig ja in Ordnung ist.
Um das ganz genau zu analysieren woran es liegt klemmst du zwischen Client und Cisco einen Wireshark oder Net-Monitor und snifferst die Pakete mit bei einem Verbindungsaufbau !
Das vergleichst du dann analog mit einem Verbindungsaufbau mit der NAT Firewall der FB dazwischen. Dann sieht man meist die Unterschiede und Ursachen auf einen Blick !
... ich denke da habe ich auch schon den Übeltäter- habe nicht beachtet, dass IP Protokoll 51, statt nur TCP/UDP Port 51 geforwardet werden muss. Da muss ich mir dann mal genauer anschauen, wie ich das bewerkstelligen kann.
Danke Dir für die schnelle Antwort- werde mich die Woche nochmal mit der Thematik beschäftigen und das Resultat hier posten.
Danke Dir für die schnelle Antwort- werde mich die Woche nochmal mit der Thematik beschäftigen und das Resultat hier posten.
