Cisco SVTI - Tunnel
Moin, moin.
ich habe folgendes Problem:
Ich möchte ein SVTI Tunnel zwischen zwei Cisco-Router aufbauen. (Multicast notwendig geworden)
Gibt es hier jemanden der so etwas schon einmal erfolgreich getan hat?
Nach dieser Anleitung habe ich es schon versucht:
http://www.cisco.com/en/US/technologies/tk583/tk372/technologies_white_ ...
allerdings ohne erfolgreich zu sein?! (Tunnel baut sich nicht auf und es gibt bei jedem Debug einen anderen Error)
ich habe folgendes Problem:
Ich möchte ein SVTI Tunnel zwischen zwei Cisco-Router aufbauen. (Multicast notwendig geworden)
Gibt es hier jemanden der so etwas schon einmal erfolgreich getan hat?
Nach dieser Anleitung habe ich es schon versucht:
http://www.cisco.com/en/US/technologies/tk583/tk372/technologies_white_ ...
allerdings ohne erfolgreich zu sein?! (Tunnel baut sich nicht auf und es gibt bei jedem Debug einen anderen Error)
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 332230
Url: https://administrator.de/contentid/332230
Ausgedruckt am: 03.12.2024 um 18:12 Uhr
44 Kommentare
Neuester Kommentar
Du solltest strategisch vorgehen:
Wenn sich der Tunnel nicht aufbaut hast du schon ein generelles Problem das vermutlich auch dein IPsec nicht funktioniert.
Hast du 1 zu 1 diesen Testaufbau gemacht ? (Der funktioniert fehlerlos) oder hast du ein Live Szenario über das Internet.
Beachte das im oben zitierten Beispiel kein NAT zum tragen kommt was bei Internet Verbindungen sonst üblich ist.
Mit NAT sind ein paar Besonderheiten verbunden. Weisst du aber vermutlich selber anhand deiner hiersigen anderen IPsec Threads ?!
- Erstmal eine funktionierende IPsec Verbindung zwischen den beiden Ciscos zum laufen bringen. Das sollte mithilfe der hiesigen Tutorials eine Lachnummer sein.
- Dann etablierst du den Tunnellink
Wenn sich der Tunnel nicht aufbaut hast du schon ein generelles Problem das vermutlich auch dein IPsec nicht funktioniert.
Hast du 1 zu 1 diesen Testaufbau gemacht ? (Der funktioniert fehlerlos) oder hast du ein Live Szenario über das Internet.
Beachte das im oben zitierten Beispiel kein NAT zum tragen kommt was bei Internet Verbindungen sonst üblich ist.
Mit NAT sind ein paar Besonderheiten verbunden. Weisst du aber vermutlich selber anhand deiner hiersigen anderen IPsec Threads ?!
So, das Problem ist in der Tat das NAT was du vermutlich nicht bedacht hast.
Hier ein funktionsfähiger Testaufbau mit der Lösung:
Um den VTI Tunnel zu testen rennt auf beiden Seiten ein RIP Ver2 Prozess der die Routen dynamisch über den Tunnel propagiert (Multicast Adresse 224.0.0.2)
Konfig Router 1, Cisco 831:
Konfig Router 2, Cisco 886:
Tip: Es macht Sinn die Tunnel Source Adressen auf lokale /32er Loopback Interfaces zu legen um vom physischen Status der hier jetzt verwendeten WAN IP Adressen unabhängig zu sein.
Tunnel Interface geht dann auf UP und anhand der Routing Tabelle und Traceroute über den VTI Tunnel kannst du sehen das Multicasting (RIP v2 nutzt 224.0.0.2) über das VTI Interface fehlerlos funktioniert:
Ebenso dann von der anderen Seite:
Fazit: Alles perfekt und Works as designed wie immer bei Cisco !!
Hier ein funktionsfähiger Testaufbau mit der Lösung:
Um den VTI Tunnel zu testen rennt auf beiden Seiten ein RIP Ver2 Prozess der die Routen dynamisch über den Tunnel propagiert (Multicast Adresse 224.0.0.2)
Konfig Router 1, Cisco 831:
service timestamps log datetime localtime
no service password-encryption
!
hostname Cisco-831
!
clock timezone CET 1
clock summer-time CEST recurring last Sun Mar 2:00 last Sun Oct 3:00
!
ip dhcp binding cleanup interval 600
ip dhcp excluded-address 172.32.7.1 172.32.7.100
ip dhcp excluded-address 172.32.7.110 172.32.7.254
!
ip dhcp pool c831
network 172.32.7.0 255.255.255.0
default-router 172.32.7.1
dns-server 192.168.7.254
domain-name test2.intern
!
ip inspect name myfw tcp
ip inspect name myfw udp
!
crypto isakmp policy 10
encr 3des
authentication pre-share
group 2
crypto isakmp key geheim123 address 0.0.0.0 0.0.0.0
!
crypto ipsec transform-set tunneltest esp-3des esp-sha-hmac
!
crypto ipsec profile VTI
set transform-set tunneltest
!
!
interface Tunnel0
description VTI Tunnel remote Location
ip address 192.168.99.2 255.255.255.0
tunnel source Ethernet1
tunnel destination 10.1.1.88
tunnel mode ipsec ipv4
tunnel protection ipsec profile VTI
!
interface Ethernet0
description Lokales LAN
ip address 172.32.7.1 255.255.255.0
ip nat inside
ip virtual-reassembly
!
interface Ethernet1
description Test WAN Internet
ip address dhcp hostname cisco831
ip access-group 111 in
no ip redirects
no ip unreachables
no ip proxy-arp
ip nat outside
ip inspect myfw out
ip virtual-reassembly
duplex auto
!
!
router rip
version 2
passive-interface Ethernet1
network 172.32.0.0
network 192.168.99.0
no auto-summary
!
!
ip nat inside source list 101 interface Ethernet1 overload
!
access-list 101 permit ip 172.32.7.0 0.0.0.255 any
access-list 111 permit icmp any any administratively-prohibited
access-list 111 permit icmp any any echo-reply
access-list 111 permit icmp any any packet-too-big
access-list 111 permit icmp any any time-exceeded
access-list 111 permit icmp any any unreachable
access-list 111 permit udp any eq bootps any
access-list 111 permit udp any any eq isakmp
access-list 111 permit udp any any eq non500-isakmp
access-list 111 permit esp any any
access-list 111 permit udp any eq ntp any
access-list 111 permit udp any eq domain any
access-list 111 permit tcp any eq domain any
access-list 111 deny ip any any
Konfig Router 2, Cisco 886:
service timestamps log datetime localtime
no service password-encryption
!
hostname Cisco886
!
clock timezone CET 1 0
clock summer-time CEST recurring last Sun Mar 2:00 last Sun Oct 3:00
!
ip dhcp binding cleanup interval 600
ip dhcp excluded-address 172.16.7.1 172.16.7.150
ip dhcp excluded-address 172.16.7.160 172.16.7.254
!
ip dhcp pool local
network 172.16.7.0 255.255.255.0
default-router 172.16.7.1
dns-server 192.168.7.254
domain-name test.intern
!
ip inspect name myfw ftp
ip inspect name myfw tcp
ip inspect name myfw udp
ip inspect name myfw https
ip inspect name myfw http
!
crypto isakmp policy 10
encr aes
authentication pre-share
group 2
!
crypto isakmp policy 15
encr 3des
authentication pre-share
group 2
crypto isakmp key geheim123 address 0.0.0.0
!
!
crypto ipsec transform-set testset esp-aes esp-sha-hmac
mode tunnel
crypto ipsec transform-set testset2 esp-3des esp-sha-hmac
mode tunnel
!
crypto ipsec profile VTI
set transform-set testset2
!
!
interface Tunnel0
decription VTI Tunnel Hauptstandort
ip address 192.168.99.1 255.255.255.0
tunnel source 10.1.1.88
tunnel mode ipsec ipv4
tunnel destination 10.99.1.109
tunnel protection ipsec profile VTI
!
interface FastEthernet0
switchport access vlan 99
no ip address
!
interface Vlan1
description Lokales LAN
ip address 172.16.7.1 255.255.255.0
ip nat inside
ip virtual-reassembly in
!
interface Vlan99
description Test WAN Internet
ip address 10.1.1.88 255.255.255.0
ip access-group 111 in
no ip redirects
no ip unreachables
no ip proxy-arp
ip nat outside
ip inspect myfw out
ip virtual-reassembly in
!
router rip
version 2
passive-interface vlan 99
network 172.16.0.0
network 192.168.99.0
no auto-summary
!
!
ip nat inside source list 101 interface Vlan99 overload
ip route 0.0.0.0 0.0.0.0 10.1.1.254
!
!
access-list 101 permit ip 172.16.7.0 0.0.0.255 any
access-list 111 permit icmp any host 10.1.1.88 administratively-prohibited
access-list 111 permit icmp any host 10.1.1.88 echo-reply
access-list 111 permit icmp any host 10.1.1.88 packet-too-big
access-list 111 permit icmp any host 10.1.1.88 time-exceeded
access-list 111 permit icmp any host 10.1.1.88 unreachable
access-list 111 permit udp any host 10.1.1.88 eq isakmp
access-list 111 permit udp any host 10.1.1.88 eq non500-isakmp
access-list 111 permit esp any host 10.1.1.88
access-list 111 permit udp any eq ntp host 10.1.1.88
access-list 111 permit udp any eq domain host 10.1.1.88
access-list 111 permit tcp any eq domain host 10.1.1.88
access-list 111 deny ip any any
!
end
Tunnel Interface geht dann auf UP und anhand der Routing Tabelle und Traceroute über den VTI Tunnel kannst du sehen das Multicasting (RIP v2 nutzt 224.0.0.2) über das VTI Interface fehlerlos funktioniert:
Cisco886vaw_Test#sh ip rou
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
a - application route
+ - replicated route, % - next hop override
Gateway of last resort is 10.1.1.254 to network 0.0.0.0
S* 0.0.0.0/0 [1/0] via 10.1.1.254
10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C 10.1.1.0/24 is directly connected, Vlan99
L 10.1.1.88/32 is directly connected, Vlan99
172.16.0.0/16 is variably subnetted, 2 subnets, 2 masks
C 172.16.7.0/24 is directly connected, Vlan1
L 172.16.7.1/32 is directly connected, Vlan1
172.32.0.0/24 is subnetted, 1 subnets
R 172.32.7.0 [120/1] via 192.168.99.2, 00:00:14, Tunnel0 <== RIP Routing
192.168.99.0/24 is variably subnetted, 2 subnets, 2 masks
C 192.168.99.0/24 is directly connected, Tunnel0
L 192.168.99.1/32 is directly connected, Tunnel0
Cisco886#ping 172.32.7.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.32.7.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/5/8 ms
Cisco886#traceroute 172.32.7.1
Type escape sequence to abort.
Tracing the route to 172.32.7.1
VRF info: (vrf in name/id, vrf out name/id)
1 192.168.99.2 4 msec * 4 msec
Ebenso dann von der anderen Seite:
Cisco-831-16m#sh ip rou
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route
Gateway of last resort is 10.99.1.254 to network 0.0.0.0
172.16.0.0/24 is subnetted, 1 subnets
R 172.16.7.0 [120/1] via 192.168.99.1, 00:00:20, Tunnel0 <== RIP Routing
172.32.0.0/24 is subnetted, 1 subnets
C 172.32.7.0 is directly connected, Ethernet0
C 192.168.99.0/24 is directly connected, Tunnel0
10.0.0.0/24 is subnetted, 1 subnets
C 10.99.1.0 is directly connected, Ethernet1
S* 0.0.0.0/0 [254/0] via 10.99.1.254
Cisco-831#ping 172.16.7.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.7.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/4/4 ms
Cisco-831#traceroute 172.16.7.1
Type escape sequence to abort.
Tracing the route to 172.16.7.1
1 192.168.99.1 4 msec * 4 msec
Fazit: Alles perfekt und Works as designed wie immer bei Cisco !!
Mmmhhh hier die gleiche Konfig mit einem 2951 und einem 831.
Funktioniert auf Anhieb !!!
Lass zum Troubleshooting immer den Debugger mitlaufen !! debug crypto isakmp und debug crypto ipsec
Dann machst du einen Extended Ping (ping <ret> dann menügeführt und extended commands auf y) indem du die lokalen Source und Destination IPs pingst um den VPN Tunnel zu triggern.
Der Debugger sagt dir doch sofort wo dein Fehler ist !!
term mon vorher nicht vergessen solltest du mit Telnet oder SSH drauf sein
Standard IPsec Konfig Router 1 (831):
Der 2te Router macht gleichzeitig noch ein IPsec Client Dialin und ist konfiguriert mit dynamischen IPs so das der 831 sich mit wechselnder IP einwählen kann.
Standard IPsec Konfig Router 2 (2951):
Das macht er nur wenn du auch relevanten Wirktraffic erzeugst der die Crypto Map ACL matched und der den Tunnel dann triggert.
Das machst du wie gesagt mit einem Extended Ping Kommando, sprich mit ping <return> und dann gibst du menügeführt die IP Adressen (Lokales LAN) ein, nickst alles per Default ertsmal ab und antwortest beim Menüpunkt Extended Commands mit "Y"
Dann sie Source IP eingeben und den Rest wieder abnicken.
Das erzeugt dann Traffic der den Tunnel sofort triggert. Das siehst du dann auch sofort im Debugger und mit show crypto isakmp sa !!
Alternativ kannst du einen Keepalive konfigurieren, der hält den Tunnel dann auch offen.
Funktioniert auf Anhieb !!!
Lass zum Troubleshooting immer den Debugger mitlaufen !! debug crypto isakmp und debug crypto ipsec
Dann machst du einen Extended Ping (ping <ret> dann menügeführt und extended commands auf y) indem du die lokalen Source und Destination IPs pingst um den VPN Tunnel zu triggern.
Der Debugger sagt dir doch sofort wo dein Fehler ist !!
term mon vorher nicht vergessen solltest du mit Telnet oder SSH drauf sein
Standard IPsec Konfig Router 1 (831):
Cisco-831#sh run
Building configuration...
service timestamps log datetime localtime
no service password-encryption
!
hostname Cisco-831
!
no aaa new-model
clock timezone CET 1
clock summer-time CEST recurring last Sun Mar 2:00 last Sun Oct 3:00
!
ip dhcp binding cleanup interval 600
ip dhcp excluded-address 172.32.7.1 172.32.7.100
ip dhcp excluded-address 172.32.7.110 172.32.7.254
!
ip dhcp pool c831
network 172.32.7.0 255.255.255.0
default-router 172.32.7.1
dns-server 192.168.7.254
domain-name test2.intern
!
ip inspect name myfw tcp
ip inspect name myfw udp
!
crypto keyring Labtest
pre-shared-key address 10.1.1.88 key geheim123
!
crypto isakmp policy 10
encr 3des
authentication pre-share
group 2
crypto isakmp profile Cisco2951
description IPsec VPN Cisco2951
keyring Labtest
match identity address 10.1.1.88 255.255.255.255
!
!
crypto ipsec transform-set tunneltest esp-3des esp-sha-hmac
!
crypto map tunneltest 10 ipsec-isakmp
description Tunnel Dynamic Cisco2951
set peer 10.1.1.88
set transform-set tunneltest
set isakmp-profile Cisco2951
match address tunneltest
!
interface Ethernet0
description Lokales LAN
ip address 172.32.7.1 255.255.255.0
ip nat inside
ip virtual-reassembly
!
interface Ethernet1
description Test WAN
ip address dhcp hostname cisco831
ip access-group 111 in
no ip redirects
no ip unreachables
no ip proxy-arp
ip nat outside
ip inspect myfw out
ip virtual-reassembly
duplex auto
crypto map tunneltest
!
ip nat inside source list 101 interface Ethernet1 overload
!
!
ip access-list extended tunneltest
permit ip 172.32.7.0 0.0.0.255 172.16.7.0 0.0.0.255
access-list 101 deny ip 172.32.7.0 0.0.0.255 172.16.7.0 0.0.0.255
access-list 101 permit ip 172.32.7.0 0.0.0.255 any
access-list 111 permit icmp any any administratively-prohibited
access-list 111 permit icmp any any echo-reply
access-list 111 permit icmp any any packet-too-big
access-list 111 permit icmp any any time-exceeded
access-list 111 permit icmp any any unreachable
access-list 111 permit udp any eq bootps any
access-list 111 permit udp any any eq isakmp
access-list 111 permit udp any any eq non500-isakmp
access-list 111 permit esp any any
access-list 111 permit udp any eq ntp any
access-list 111 permit udp any eq domain any
access-list 111 permit tcp any eq domain any
access-list 111 deny ip any any
!
end
Der 2te Router macht gleichzeitig noch ein IPsec Client Dialin und ist konfiguriert mit dynamischen IPs so das der 831 sich mit wechselnder IP einwählen kann.
Standard IPsec Konfig Router 2 (2951):
Cisco2951#sh run
Building configuration...
service timestamps log datetime localtime
!
hostname Cisco2951
!
clock timezone CET 1 0
clock summer-time CEST recurring last Sun Mar 2:00 last Sun Oct 3:00
!
aaa authentication login default local
aaa authentication login clientauth local
aaa authorization network groupauth local
!
ip dhcp binding cleanup interval 600
ip dhcp excluded-address 172.16.7.1 172.16.7.150
ip dhcp excluded-address 172.16.7.160 172.16.7.254
!
ip dhcp pool local
network 172.16.7.0 255.255.255.0
default-router 172.16.7.1
dns-server 192.168.7.254
domain-name test.intern
!
ip inspect name myfw sip
ip inspect name myfw icmp
ip inspect name myfw rtsp
ip inspect name myfw esmtp
ip inspect name myfw tcp
ip inspect name myfw udp
ip inspect name myfw https
ip inspect name myfw http
!
username vpntest password 0 test123
!
crypto keyring Labtest
pre-shared-key address 0.0.0.0 0.0.0.0 key geheim123
!
crypto isakmp policy 10
encr aes
authentication pre-share
group 2
!
crypto isakmp policy 15
encr 3des
authentication pre-share
group 2
!
crypto isakmp client configuration group VPNdialin
key cisco321
dns 192.168.7.254
domain vpn.test.intern
pool VPNPool
save-password
max-logins 3
banner ^C Willkommen im Test VPN (Cisco2951) ^C
!
crypto isakmp profile VPNclient
description VPN clients profile
match identity group VPNdialin
client authentication list clientauth
isakmp authorization list groupauth
client configuration address respond
virtual-template 2
crypto isakmp profile DynDialin
description VPNs mit dyn. IP
keyring Labtest
match identity address 0.0.0.0
!
crypto ipsec transform-set testset esp-aes esp-sha-hmac
mode tunnel
crypto ipsec transform-set testset2 esp-3des esp-sha-hmac
mode tunnel
!
!
crypto ipsec profile test-vti2
set transform-set testset
!
!
crypto dynamic-map dynmap 10
description Tunnel dyn.IP Cisco 831
set transform-set testset2
set isakmp-profile DynDialin
match address vpndyn1
!
crypto map vpntest 20 ipsec-isakmp dynamic dynmap
!
!
interface FastEthernet0
switchport access vlan 99
no ip address
!
interface Virtual-Template2 type tunnel
ip unnumbered Vlan1
ip virtual-reassembly in
tunnel mode ipsec ipv4
tunnel protection ipsec profile test-vti2
!
interface Vlan1
description Lokales LAN
ip address 172.16.7.1 255.255.255.0
ip nat inside
ip virtual-reassembly in
!
interface Vlan99
description WAN Port Internet
ip address 10.1.1.88 255.255.255.0
ip access-group 111 in
no ip redirects
no ip unreachables
no ip proxy-arp
ip nat outside
ip inspect myfw out
ip virtual-reassembly in
crypto map vpntest
!
!
ip local pool VPNPool 172.16.7.70 172.16.7.73
!
ip nat inside source list 101 interface Vlan99 overload
ip route 0.0.0.0 0.0.0.0 10.1.1.254
!
ip access-list extended vpnaccess
permit ip any host 172.16.7.70
permit ip any host 172.16.7.71
permit ip any host 172.16.7.72
permit ip any host 172.16.7.73
ip access-list extended vpndyn1
permit ip 172.16.7.0 0.0.0.255 172.32.7.0 0.0.0.255
!
access-list 101 deny ip 172.16.7.0 0.0.0.255 172.32.7.0 0.0.0.255
access-list 101 permit ip 172.16.7.0 0.0.0.255 any
access-list 111 permit icmp any host 10.1.1.88 administratively-prohibited
access-list 111 permit icmp any host 10.1.1.88 echo-reply
access-list 111 permit icmp any host 10.1.1.88 packet-too-big
access-list 111 permit icmp any host 10.1.1.88 time-exceeded
access-list 111 permit icmp any host 10.1.1.88 unreachable
access-list 111 permit udp any host 10.1.1.88 eq isakmp
access-list 111 permit udp any host 10.1.1.88 eq non500-isakmp
access-list 111 permit esp any host 10.1.1.88
access-list 111 permit udp any eq ntp host 10.1.1.88
access-list 111 permit udp any eq domain host 10.1.1.88
access-list 111 permit tcp any eq domain host 10.1.1.88
access-list 111 deny ip any any
!
Lasse ich ein debug laufen sehe ich nichts was die Kommunikation der beiden Routern betrifft?!
Wie gesagt das liegt daran das du vermutlich keinen Traffic für den Tunnel hast. Mach nicht den Denkfehler das du annimmst das sich der Tunnel selber aufbaut !!Das macht er nur wenn du auch relevanten Wirktraffic erzeugst der die Crypto Map ACL matched und der den Tunnel dann triggert.
Das machst du wie gesagt mit einem Extended Ping Kommando, sprich mit ping <return> und dann gibst du menügeführt die IP Adressen (Lokales LAN) ein, nickst alles per Default ertsmal ab und antwortest beim Menüpunkt Extended Commands mit "Y"
Dann sie Source IP eingeben und den Rest wieder abnicken.
Das erzeugt dann Traffic der den Tunnel sofort triggert. Das siehst du dann auch sofort im Debugger und mit show crypto isakmp sa !!
Alternativ kannst du einen Keepalive konfigurieren, der hält den Tunnel dann auch offen.
Da hast du aber ziemliche Tomaten auf den Augen !!! Sieh dir mal deinen extended Ping an oben !
Das springt einem ja förmlich in die Augen....
Also bitte die Threads und insbesondere den oben GENAU lesen.
Was wurde oben gebetsmühlenartig immer und immer wieder gesagt ???
Extended Commands bitte mit YES beantworten und die lokale Absender IP verwenden die die Tunnel ACL matched !!
So ohne das nimmt er irgendwas und matched die Tunnel ACL nicht und folglich kommen keine Daten die den Tunnel triggern... Logo das das nicht klappen kann...dzzzzz
Da merkt man aber wirklich deinen Stress ! Nimm mal Urlaub oder relax mal auf der Couch !!
Das springt einem ja förmlich in die Augen....
Also bitte die Threads und insbesondere den oben GENAU lesen.
Was wurde oben gebetsmühlenartig immer und immer wieder gesagt ???
Extended Commands bitte mit YES beantworten und die lokale Absender IP verwenden die die Tunnel ACL matched !!
So ohne das nimmt er irgendwas und matched die Tunnel ACL nicht und folglich kommen keine Daten die den Tunnel triggern... Logo das das nicht klappen kann...dzzzzz
Da merkt man aber wirklich deinen Stress ! Nimm mal Urlaub oder relax mal auf der Couch !!
Mmmmhhh...
Nochmal nachgefragt: Testest du jetzt eine standard IPsec Konfig oder die VTI Konfig ??
Wenn es die Standard Konfig von oben ist ist die soweit OK und richtig.
Was aber auffällt ist das keinerlei IP Pakete rausgehen.
Hast du nochmals die Route Maps usw. kontrolliert und die NAT Statements das das alles passt ?
Irgendwo MUSS da zwangsläufig ein Flüchtigkeitsfehler in der Konfig sein.
Nochmal nachgefragt: Testest du jetzt eine standard IPsec Konfig oder die VTI Konfig ??
Wenn es die Standard Konfig von oben ist ist die soweit OK und richtig.
Was aber auffällt ist das keinerlei IP Pakete rausgehen.
Hast du nochmals die Route Maps usw. kontrolliert und die NAT Statements das das alles passt ?
Irgendwo MUSS da zwangsläufig ein Flüchtigkeitsfehler in der Konfig sein.
Nur der Cisco-Cisco Tunnel will nicht....
Da ist ja gravierend das scheinbar keinerlei Traffic erzeugt wird der den IPsec Tunnel triggert, denn sonst würdest du ausgehendende IPsec Pakete mit debug crypto isakmp und debug crypto ipsec sehen.Das zeigt das irgendwas mit der Crypto Map die den relevanten Traffic klassifiziert nicht stimmt, denn der Router sendet keinerlei IPsec Requests aus.
Übrigens noch ein gut gemeinter Tip:
Vom Google DNS Server 8.8.8.8 solltest du besser die Finger lassen, denn die erzeugen ein Profil von dir mit deinem DNS Verhalten und verwerten das zur Ausschnüffelei
Folgende Sachen sind auffällig und solltest du entfernen:
- leerer "username" string (887)
- Im DHCP Server excludest du die ausschliesslich nur die .66.1. Der Router selber hat aber die .66.254. Da nur die .1 excluded ist wird die .254 im DHCP Prozess vergeben was tödlich sein kann. (IP Doppelung) Wenn dann sowas wie
ip dhcp excluded-address 192.168.66.1 192.168.66.10
ip dhcp excluded-address 192.168.66.200 192.168.66.254
Das lässt dann den Bereich von .11 bis .199 für DHCP Adressen !
- access-list 111 permit udp any eq bootpc any ist überflüssig und auch kontraproduktiv in der ACL 111 und solltest du besser entfernen. access-list 111 permit udp any eq bootps any reicht damit das Interface 0.180 ein IP bekommt. pc brauchst du nur wenn der Router auch selber DHCP IPs vergeben soll auf dem Interface was er aber da niemals tut.
- Das vlan 10 Interface ist eine Konfig Leiche und solltest du besser entfernen !
- Die MSS Begrenzung ip tcp adjust-mss 1280 gehört immer aufs lokale LAN niemals auf das Provider Interface
- Gar nicht geht dein isakmp profile DynAddress denn das ist vermutlich das Profil für das Dialin von Site2Site Routern mit dynamischen IP Adressen.
crypto isakmp profile DynAddress
description VPNs mit dyn. IP
keyring MK
match identity address 0.0.0.0
!
Das fackelt ALLE VPN Connections mit dynamischen IP Adressen ab !! Die einzelnen Teilnehmer definierst du dann mit der crypto dynamic-map !
Also dann:
crypto dynamic-map vpnmk 10
description Tunnel dyn.IP Cisco 2950
set transform-set HOF
set isakmp-profile DynAddress
match address VPNMK2
dann noch die Map Zuweisung:
crypto map vpntest 20 ipsec-isakmp dynamic vpnmk
Und dann auf dem Outpoing Provider Interface (Dialer) die Zuweisung: crypto map vpnmk was letztlich richtig ist bei dir.
Da ist ziemliches Kuddelmuddel in deiner IPsec Konfigauch mit überflüssigen Peers und Hosts !!
Du solltest auch erstmal die nichtbenutzte VTI Konfig da komplett rausschmeissen und Peers auf IP Adressen entfernen die der 887 nicht bedient.
Niemals VTI und standard IPsec mischen.
Also die gesamte Konfig ganz schlank machen und wirklich nur das konfigurieren was du auch brauchst ohne irgendwelche Reste von Konfig Basteleien.
Das verbessert die Übersicht und das Troubleshooting.
In der aktuellen Konfig geht ja alles über den Dialer 1 nach draußen solange der aktiv ist. Ggf. solltest du testweise die Backup Interfaces alle mal auf shutdown setzen um hier erstmal eine laufende Minimalkonfig zu schaffen.
Das Troubleshooting wird erschwert durch eine paralele Backup oder Balancing Konfig.
Also alles mal entwanzen und auf Vorderman bringen und überflüssige VPN Peers und den anderen Klumpatsch löschen in der Konfig.
Noch eine Frage: Der obige 887 würde ja dann nur 2 VPN Peers bedienen. Einmal den Bintec und einmal den Cisco 2950, richtig ?
Haben der Cisco 2950 und der Bintec auch dynamische IPs oder hat einer oder beiden feste IPs ?
So sähe dann deine gereinigte und funktionsfähig getestete Konfig von dem Router aus:
!
hostname Cisco
!
aaa authentication login default local
aaa authentication login clientauth local
aaa authorization network groupauth local
!
clock timezone CET 1 0
clock summer-time CEST recurring last Sun Mar 2:00 last Sun Oct 3:00
!
ip dhcp binding cleanup interval 600
ip dhcp excluded-address 192.168.66.1 192.168.66.99
ip dhcp excluded-address 192.168.66.150 192.168.66.254
!
ip dhcp pool local
network 192.168.66.0 255.255.255.0
default-router 192.168.66.254
dns-server 192.168.66.254
!
!
ip inspect name myfw tcp
ip inspect name myfw udp
ip inspect name myfw isakmp
ip inspect name myfw https
ip inspect name myfw http
!
!
username admin password 0 admin
username vpntest password 0 test123
!
!
crypto keyring MK
pre-shared-key address 0.0.0.0 0.0.0.0 key geheim123
!
crypto isakmp policy 10
encr aes
authentication pre-share
group 2
!
crypto isakmp policy 15
encr 3des
authentication pre-share
group 2
!
crypto isakmp client configuration group VPNdialin
key cisco321
dns 192.168.66.254
domain clientvpn.test.intern
pool VPNPool
save-password
max-logins 3
banner ^C Welcome to Christophs VPN ^C
!
crypto isakmp profile VPNclient
description VPN clients Profil
match identity group VPNdialin
client authentication list clientauth
isakmp authorization list groupauth
client configuration address respond
virtual-template 2
!
crypto isakmp profile DynAddress
description Router VPNs mit dyn. IP
keyring MK
match identity address 0.0.0.0
!
!
crypto ipsec transform-set testset esp-aes esp-sha-hmac
mode tunnel
!
crypto ipsec profile test-vti2
set transform-set testset
!
!
crypto dynamic-map dynmk 10
description Tunnel dyn.IP Bintec
set transform-set testset
set isakmp-profile DynAddress
match address vpnbintec
!
crypto dynamic-map dynmk 15
description Tunnel dyn.IP Cisco2950
set transform-set testset
set isakmp-profile DynAddress
match address vpn2950
!
crypto map vpnmk 10 ipsec-isakmp dynamic dynmk
!
!
interface Cellular0
no ip address
encapsulation ppp
dialer in-band
dialer pool-member 1
!
interface Dialer1
ip address negotiated
ip access-group 111 in
no ip redirects
no ip proxy-arp
ip nat outside
ip inspect myfw out
ip virtual-reassembly in
encapsulation ppp
dialer pool 1
dialer-group 1
ppp authentication chap callin
ppp chap hostname xyz
ppp chap password xyz
no cdp enable
crypto map vpnmk
!
!
interface Virtual-Template2 type tunnel
ip unnumbered Vlan1
ip virtual-reassembly in
tunnel mode ipsec ipv4
tunnel protection ipsec profile test-vti2
!
interface Vlan1
description Lokales LAN
ip address 172.16.66.254 255.255.255.0
no ip redirects
no ip proxy-arp
ip nat inside
ip virtual-reassembly in
ip tcp adjust-mss 1452
!
ip local pool VPNPool 192.168.66.70 192.168.66.73
!
ip nat inside source list 101 interface Dialer1 overload
ip route 0.0.0.0 0.0.0.0 interface Dialer1
!
ip access-list extended vpnbintec
permit ip 192.168.66.0 0.0.0.255 192.168.83.0 0.0.0.255
ip access-list extended vpn2950
permit ip 192.168.66.0 0.0.0.255 192.168.36.0 0.0.0.255
!
access-list 101 deny ip 192.168.66.0 0.0.0.255 192.168.83.0 0.0.0.255
access-list 101 deny ip 192.168.66.0 0.0.0.255 192.168.36.0 0.0.0.255
access-list 101 permit ip 192.168.66.0 0.0.0.255 any
!
access-list 111 permit icmp any host any administratively-prohibited
access-list 111 permit icmp any host any echo-reply
access-list 111 permit icmp any host any packet-too-big
access-list 111 permit icmp any host any time-exceeded
access-list 111 permit icmp any host any unreachable
access-list 111 permit udp any host any eq isakmp
access-list 111 permit udp any host any eq non500-isakmp
access-list 111 permit esp any host any
access-list 111 permit udp any eq ntp host any
access-list 111 permit udp any eq domain host any
access-list 111 permit tcp any eq domain host any
access-list 111 deny ip any any
!
end
!
hostname Cisco
!
aaa authentication login default local
aaa authentication login clientauth local
aaa authorization network groupauth local
!
clock timezone CET 1 0
clock summer-time CEST recurring last Sun Mar 2:00 last Sun Oct 3:00
!
ip dhcp binding cleanup interval 600
ip dhcp excluded-address 192.168.66.1 192.168.66.99
ip dhcp excluded-address 192.168.66.150 192.168.66.254
!
ip dhcp pool local
network 192.168.66.0 255.255.255.0
default-router 192.168.66.254
dns-server 192.168.66.254
!
!
ip inspect name myfw tcp
ip inspect name myfw udp
ip inspect name myfw isakmp
ip inspect name myfw https
ip inspect name myfw http
!
!
username admin password 0 admin
username vpntest password 0 test123
!
!
crypto keyring MK
pre-shared-key address 0.0.0.0 0.0.0.0 key geheim123
!
crypto isakmp policy 10
encr aes
authentication pre-share
group 2
!
crypto isakmp policy 15
encr 3des
authentication pre-share
group 2
!
crypto isakmp client configuration group VPNdialin
key cisco321
dns 192.168.66.254
domain clientvpn.test.intern
pool VPNPool
save-password
max-logins 3
banner ^C Welcome to Christophs VPN ^C
!
crypto isakmp profile VPNclient
description VPN clients Profil
match identity group VPNdialin
client authentication list clientauth
isakmp authorization list groupauth
client configuration address respond
virtual-template 2
!
crypto isakmp profile DynAddress
description Router VPNs mit dyn. IP
keyring MK
match identity address 0.0.0.0
!
!
crypto ipsec transform-set testset esp-aes esp-sha-hmac
mode tunnel
!
crypto ipsec profile test-vti2
set transform-set testset
!
!
crypto dynamic-map dynmk 10
description Tunnel dyn.IP Bintec
set transform-set testset
set isakmp-profile DynAddress
match address vpnbintec
!
crypto dynamic-map dynmk 15
description Tunnel dyn.IP Cisco2950
set transform-set testset
set isakmp-profile DynAddress
match address vpn2950
!
crypto map vpnmk 10 ipsec-isakmp dynamic dynmk
!
!
interface Cellular0
no ip address
encapsulation ppp
dialer in-band
dialer pool-member 1
!
interface Dialer1
ip address negotiated
ip access-group 111 in
no ip redirects
no ip proxy-arp
ip nat outside
ip inspect myfw out
ip virtual-reassembly in
encapsulation ppp
dialer pool 1
dialer-group 1
ppp authentication chap callin
ppp chap hostname xyz
ppp chap password xyz
no cdp enable
crypto map vpnmk
!
!
interface Virtual-Template2 type tunnel
ip unnumbered Vlan1
ip virtual-reassembly in
tunnel mode ipsec ipv4
tunnel protection ipsec profile test-vti2
!
interface Vlan1
description Lokales LAN
ip address 172.16.66.254 255.255.255.0
no ip redirects
no ip proxy-arp
ip nat inside
ip virtual-reassembly in
ip tcp adjust-mss 1452
!
ip local pool VPNPool 192.168.66.70 192.168.66.73
!
ip nat inside source list 101 interface Dialer1 overload
ip route 0.0.0.0 0.0.0.0 interface Dialer1
!
ip access-list extended vpnbintec
permit ip 192.168.66.0 0.0.0.255 192.168.83.0 0.0.0.255
ip access-list extended vpn2950
permit ip 192.168.66.0 0.0.0.255 192.168.36.0 0.0.0.255
!
access-list 101 deny ip 192.168.66.0 0.0.0.255 192.168.83.0 0.0.0.255
access-list 101 deny ip 192.168.66.0 0.0.0.255 192.168.36.0 0.0.0.255
access-list 101 permit ip 192.168.66.0 0.0.0.255 any
!
access-list 111 permit icmp any host any administratively-prohibited
access-list 111 permit icmp any host any echo-reply
access-list 111 permit icmp any host any packet-too-big
access-list 111 permit icmp any host any time-exceeded
access-list 111 permit icmp any host any unreachable
access-list 111 permit udp any host any eq isakmp
access-list 111 permit udp any host any eq non500-isakmp
access-list 111 permit esp any host any
access-list 111 permit udp any eq ntp host any
access-list 111 permit udp any eq domain host any
access-list 111 permit tcp any eq domain host any
access-list 111 deny ip any any
!
end
Tadaaa!!! Klasse. Das wäre jetzt auch mein allerletzter Vorschlag gewesen und du hast intuitiv mitgedacht
Wenn du lokale Endgeräte vom remoten Router pingen willst, dann MUSST du den extended Ping verwenden und als Absenderadresse der Pings immer das lokale LAN Interface wählen !! Vergiss das nicht.
Ansonsten nimmt der Cisco eine falsche Absender IP die dann die Crypto ACL nicht matcht und gar nicht erst remote ankommt weil sie ins Nirwana geht.
OK, und das am remoten Endgerät natürlich die lokale Firewall entsprechend angepasst werden muss, Gateway sollte der VPN Router sein oder eine Route dahin haben und Bla und Blub ist auch immer die gleiche Leier.
Denk dran wenn das angepingte Endgerät Winblows ist das du dann ICMP (Ping) freigeben musst !
https://www.windowspro.de/tipp/ping-windows-7-server-2008-r2-zulassen
Zuerst mal die Feststellung das man deine Frage wie immer nicht beantworten kann da du nicht schilderst WIE dein DNS rennt im Winblows Netz.
Wenn du einen lokalen Winblows DNS Server hast, dann ist es einfach, denn dann musst du lediglich diese IP an den Clients vergeben.
Du hast aber vermutlich keinen DNS und dann basiert die Netzwerk Erkennung immer auf lokalen UDP Broadcasts des Windows Naming Services.
Jedes Windows Gerät bläst also ins lokale Netzwerk einen UDP Broadcast mit dem Inhalt "Hallo hier bin ich mit Namen xyz" so das alle anderen Endgeräte das sehen und entsprechend anzeigen.
Wie du aber als gut informierter Netzwerker weisst, forwarden Router generell keine Broadcasts über geroutete Interfaces und VPNs sind ja geroutet. Die Winblows Kisten sehen sich also so mit UDP Broadcast nur gegenseitig in einer L2 Domain in einem Segment.
Sprich also am anderen gerouteten Ende kommt nix an. Das wird auch ein GRE Tunnel nicht ändern, da TCP/IP Standard.
Hier hast du nun 2 Optionen:
das ich zwar die beiden Router gegeneinander Pingen kann aber keinen im Netzwerk dahinter?
Nicht das du wieder den Ping mit den extended Commands vergessen hast !!!Wenn du lokale Endgeräte vom remoten Router pingen willst, dann MUSST du den extended Ping verwenden und als Absenderadresse der Pings immer das lokale LAN Interface wählen !! Vergiss das nicht.
Ansonsten nimmt der Cisco eine falsche Absender IP die dann die Crypto ACL nicht matcht und gar nicht erst remote ankommt weil sie ins Nirwana geht.
OK, und das am remoten Endgerät natürlich die lokale Firewall entsprechend angepasst werden muss, Gateway sollte der VPN Router sein oder eine Route dahin haben und Bla und Blub ist auch immer die gleiche Leier.
Denk dran wenn das angepingte Endgerät Winblows ist das du dann ICMP (Ping) freigeben musst !
https://www.windowspro.de/tipp/ping-windows-7-server-2008-r2-zulassen
wenn man bei windows auf netzwerk geht, die Netzwerkgeräte angezeigt werden? Quasi als wäre man im selben Netz? GRE?
Da hast du mit Cisco 2 Optionen.Zuerst mal die Feststellung das man deine Frage wie immer nicht beantworten kann da du nicht schilderst WIE dein DNS rennt im Winblows Netz.
Wenn du einen lokalen Winblows DNS Server hast, dann ist es einfach, denn dann musst du lediglich diese IP an den Clients vergeben.
Du hast aber vermutlich keinen DNS und dann basiert die Netzwerk Erkennung immer auf lokalen UDP Broadcasts des Windows Naming Services.
Jedes Windows Gerät bläst also ins lokale Netzwerk einen UDP Broadcast mit dem Inhalt "Hallo hier bin ich mit Namen xyz" so das alle anderen Endgeräte das sehen und entsprechend anzeigen.
Wie du aber als gut informierter Netzwerker weisst, forwarden Router generell keine Broadcasts über geroutete Interfaces und VPNs sind ja geroutet. Die Winblows Kisten sehen sich also so mit UDP Broadcast nur gegenseitig in einer L2 Domain in einem Segment.
Sprich also am anderen gerouteten Ende kommt nix an. Das wird auch ein GRE Tunnel nicht ändern, da TCP/IP Standard.
Hier hast du nun 2 Optionen:
- Einmal trägst du die Hostnamen und IPs der jeweiligen remoten Endgeräte statisch in die Datei hosts oder lmhosts bei Winblows ein und löst das Problem damit: XP-Home mit 2 Kabelgebundenen und WLAN PCs
- Oder du nutzt an den lokalen LAN Interfaces eine sog. IP Helper Adresse. Mit der Helper Adresse kannst du UDP Broadcasts forwarden. In der Hauptsache nutzt man das für DHCP um DHCP Broadcasts in gerouteten Netzen auf einen zentralen DHCP Server zu bringen. Cisco hat den Vorteil das du bei den Helper Adressen auch ganze Netzwerke angeben kannst. Das kannst du machen und dann forwardet der Router diese Windows Naming UDP Broadcasts. Das klappt dann auch auf VTI bzw. GRE Tunnels problemlos.
ich habe nun denke ich auch den VTI Tunnel laufen! Vielen Dank nochmals!
Klasse ! Das sieht schon mal sehr gut aus.Richtig wissen tust du das nur aber wenn du mal einen Routing Prozess wie RIPv2 oder OSPF aktivierst, denn dann kannst du sehen ob auch z.B. Multicast Traffic durch den Tunnel geht.
Ist das der Fall dann rennt alles wie es soll
Also mal schnell
router rip
version 2
network 192.168.99.0
network 192.168.83.0
no auto-summary
eingeben auf beiden Seiten und testen. (Die LAN IP anpassen)
Ooops, sehe gerade hast du gemacht. Die Routing Tabelle sagt "R" vor der Route und das ist RIPv2
zwar alles pingen (interne Geräte z.b. 83.1 oder 83.100) aber nicht umgekehrt?! Ist das ein Denkfehler oder fehlt da eine Freigabe?
Eigentlich nicht.Ein sicheres Indiz das es geht ist IMMER wenn du mit dem Extended Ping die jeweils beiden gegenüberliegenden lokalen LAN Interfaces der Ciscos pingen kannst.
Also Absender IP = lokales LAN IP und Ziel IP = remotes lokales LAN Interface.
Klappt der Ping von beiden Routern nach dem Schema ist alles OK.
Oben kannst du sehen das du leider wieder KEIN extended Ping gemacht hast !
Der Cisco nimmt ohne das als Absender IP die niedrigste IP die er hat und dann matched die VPN ACL Regel nicht und der Ping schlägt fehl. Das alte Thema....du weist?!
Genau deshalb musst du bei VPN Pings vom Router immer explizit die Absender- und Ziel IP mit dem Extended Ping Tool angeben ! Ansonsten geht das immer schief.
Das gilt im Übrigen AUCH wenn du vom Router remote Endgeräte im remoten lokalen LAN anpingst.
Auch hier immer Extended Ping und als Absender IP immer die lokale LAN IP.
Du wirst sehen, damit klappt es sofort
Wenn nicht, dann sind es zu 98% wie immer die zwei üblichen Fehlerquellen:
- 1. Fehlendes Gateway oder Route auf den Endgeräten
- 2. Lokale Firewall dort die fremde IP und/oder ICMP blockt.
Wir hatten gerade so ein Firewall Drama hier kürzlich und das noch nichtmal mit VPN:
Routingproblem in Homerouter-Kaskade mit Raspi
Ich habe aber nun ein ganz anderes Porblem bekommen nach einem Netzausfall verbindet sich der VTI-Tunnel nicht mehr?
Hast du vergessen ein wr einzugeben und deine Konfigs nicht gesichert ?? (Hoffentlich nicht ?!)Problem kann die Tunnel Source IP sein wenn du dynamsiche IPs hast am WAN Port.
Ich sagte oben schon das die auf die WAN IPs gemappt sind. Das ist nicht sehr gut, besser wären hier /32er Loopback Adressen und die man dann mit RIPv2 oder statisch auf der anderen Seite bekannt macht.
Dann sind die Tunnel an lokale feste IPs gebunden die nichts mit dem Status des WAN Ports zu tun haben.
Ist konfigtaktisch besser.
Ja, das wäre richtig. Aber sorry, ich hatte einen kleinen Denkfehler gemacht und war auf die Tunnel Source fixiert.
Als Tunnel Destination (remotes Ziel) kannst du natürlich kein Interface global angeben sondern nur eine entsprechende Ziel IP oder Hostnamen.
Bei dynamischen IP WAN Adressen bist du dann auf DynDNS Hostnamen verhaftet, klar. Das ist letztlich so wie bei klassischem VPN Tunnel IPs ja auch.
Die Loopback Empfehlung bezieht sich dann natürlich auf die Source. Wenn man da ein lokales Ethernet angibt, dann bricht der Tunnel auch ab wenn dieses Ethernet mal auf DOWN geht. Das verhindert man eben mit der Verwendung der Loopback IP, denn die ist immer UP solange der Router strom hat und hält dann den Tunnel egal welchen Status lokale Interfaces haben.
Wenn man natürlich nur ein lokales LAN hat oder Interface macht das Loopback keinen wirklichen Sinn und man kann es auch auf die lokale LAN IP mappen.
Sorry für die Verwirrung !
Als Tunnel Destination (remotes Ziel) kannst du natürlich kein Interface global angeben sondern nur eine entsprechende Ziel IP oder Hostnamen.
Bei dynamischen IP WAN Adressen bist du dann auf DynDNS Hostnamen verhaftet, klar. Das ist letztlich so wie bei klassischem VPN Tunnel IPs ja auch.
Die Loopback Empfehlung bezieht sich dann natürlich auf die Source. Wenn man da ein lokales Ethernet angibt, dann bricht der Tunnel auch ab wenn dieses Ethernet mal auf DOWN geht. Das verhindert man eben mit der Verwendung der Loopback IP, denn die ist immer UP solange der Router strom hat und hält dann den Tunnel egal welchen Status lokale Interfaces haben.
Wenn man natürlich nur ein lokales LAN hat oder Interface macht das Loopback keinen wirklichen Sinn und man kann es auch auf die lokale LAN IP mappen.
Sorry für die Verwirrung !
Allerdings gab es heute einen IP-Change auf der Seite des 887V (Telekom mit Dyn IP), seit dem habe ich keinen Tunnel mehr.
Eigentlich klar, weil die Tunnel IP darauf gemappt ist. Es sei denn du arbeitest mit DynDNS Hostadressen. Dann muss aber der Tunnel Prozess neu discovern und das kann etwas dauern. Bzw. der Tunnel wird ja nur getriggert wenn auch Produktivtraffic da ist der den IPsec Filter matcht und den Tunnel triggert.Ggf. solltest du hier das RIPv2 weiter laufen lassen, denn RIP sorgt quasi wie ein Keepalive dafür das da immer Daten kommen.
Und eigentlich ist doch am Cisco 2951 mit crypto iskamp key XXXXXXX address 0.0.0.0 0.0.0.0 gesagt das er alles annimmt egal woher?
Das ist absolut richtig für den IPsec Prozess. Die Tunnel Source und Destination mappen aber auf die WAN IPs und damit ist für IPsec zwar alles bella aber der Tunnel bricht zusammen wenn diese IPs nicht mehr matchen. Das Tunnel Interface ist vermutlich dann auch auf down bei dir, richtig ? (show ip int brief)das der 2951 bei tunnel Destination die IP nicht aktualisiert trotz das ich den Hostname von dyndns angeben habe statt IP?
Genau DAS ist ganz sicher das Grundproblem. Dann müsstest du erstmal rausbekommen woran das liegt.Möglich das der DynDNS Prozess auf dem Router nur getriggert wird wenn das Interface physisch auf Down geht. Das passiert aber beim Dialer ggf. nicht. Hier müsste man auch einen Keepalive im DynDNS setzen der das zyklisch macht ohne Interface status. Müsste mal nachlesen in der Konfig ob das geht.
ABER über den SVTI tunnel bekomme ich von einem client PC keinen Ping oder sonst was in das 83er Netz rein?
Dann stimmt was mit deinem IP Routing nicht !Was sagt denn ein sh ip route ??
Wird das 83er netz denn in den Tunnel geroutet ?? Wenn nicht geht es zum Provider ins Nirwana, was vermutlich bei dir der Fall ist.
Wenn du RIPv2 laufen lässt, dann trägst du das auf der 83er Seite einfach ein und das wird dann automatisch rüberpropagiert. Ohne RIP musst du das zwingend statisch machen ! Hast du vermutlich vergessen, oder ?
Hier sit sh ip route und Traceroute immer dein bester Freund
Habs hier im Testaufbau mal probiert und es rennt wie erwartet fehlerlos.
Mehrere Dinge zu deiner Client konfig:
1.)
Es fehlt oben die User und Gruppenauthentisierung mit den lokalen Usern / Passowrd: //
!
aaa new-model
!
aaa authentication login clientauth local
aaa authorization network groupauth local
!
username vpntest password Geheim123
2.)
Zwei Identische Transform Sets aber mit gleichen Parametern zu haben ist Unsinn. Einen kannst du löschen und nur immer den anderen verwenden.
3.)
Deine 2 Client Profile sind etwas wirr und man versteht nicht was das soll, da viele einfach doppelt ist was erstmal sinnfrei aussieht.
Du solltest hier erstmal den 2ten komplett entfernen und das erstmal sauber nur mit einem einzigen zum Laufen bringen.
Erst dann den zweiten aufsetzen wenn man den denn unbedingt braucht. Vermutlich nicht aber dann müsste man verstehen was du damit bezwecken willst oder wolltest.
Der Rest ist soweit OK
1.)
Es fehlt oben die User und Gruppenauthentisierung mit den lokalen Usern / Passowrd: //
!
aaa new-model
!
aaa authentication login clientauth local
aaa authorization network groupauth local
!
username vpntest password Geheim123
2.)
Zwei Identische Transform Sets aber mit gleichen Parametern zu haben ist Unsinn. Einen kannst du löschen und nur immer den anderen verwenden.
3.)
Deine 2 Client Profile sind etwas wirr und man versteht nicht was das soll, da viele einfach doppelt ist was erstmal sinnfrei aussieht.
Du solltest hier erstmal den 2ten komplett entfernen und das erstmal sauber nur mit einem einzigen zum Laufen bringen.
Erst dann den zweiten aufsetzen wenn man den denn unbedingt braucht. Vermutlich nicht aber dann müsste man verstehen was du damit bezwecken willst oder wolltest.
Der Rest ist soweit OK
Zudem ist mir aufgefallen das wenn ich einen Ping zu der VDSL Schnittstelle sende von extern mit nichts antwortet?!
Das ist normal wenn du eine CBAC Accessliste konfiguriert hast. Die lässt keine Sessions von außen durch wenn du es nicht explizit erlaubst mit ICMP echo requests auf die inbound Dialer 0 IP !!Eine Beispiel für das Policy Routing über die unterschiedlichen Interfaces findest du hier:
Cisco Router 2 Gateways für verschiedene Clients
http://www.cisco.com/c/en/us/support/docs/ip/network-address-translatio ...
Wenn ich versuche eine Client-Verbindung aufzubauen meldet er mir host nicht gefunden.
Du hast ganz sicher den VPN Traffic vom NAT beider Internet PBR Verbindungen excludet ???Hört sich etwas an ob das nicht komplett passiert ist ?!
Default-Routen nutzt aber nicht von außen nach innen?
Nee, das geht ja auch nicht...logisch !!Eine Verbindung von außen die die WAN IP X nutzt darfst du dann niemals mehr balancen das die z.B, mit einer Absender IP von Y antowrtet. Dann bricht die Verbindung sofort ab.
Die VPN Tunnel musst du also sticky betreiben und auf eine Verbindung festnageln.
Oder....du machst immer 2 Tunnel auf und nutzt einen im Failover Falle. (Split Tunnel)
https://networkology.net/2013/03/08/site-to-site-vpn-with-dual-isp-for-b ...
Einfach mal nach cisco ios VPN redundancy suchen...
Ich checke deine Konfig mal...
Das heist also das es am Cisco niemals möglich ist 2 ISP Anbindungen zu haben?
Nein, natürlich nicht. Das wäre ja Blödsinn wenn dem so wäre.Nur du schreibst ja explizit INBOUND Sessions. Und da ist es dann klar, denn eine inbound Session die also von extern mit einer bestimmten Absender IP auf eine der WAN Port IPs gemacht wird muss zwingend auf diese WAN Port IP bleiben.
Der Router kann von sich aus nicht mit der anderen WAN IP antworten. Macht er das kommt es zu einem Absneder IP Mismatch und dem Closen der Session. Das ist übliches TCP/IP verhalten und hat nichts mit Routern oder Hersteller zu tun.
Inbound Sessions sollten also immer sticky sein. Gerade bei IPsec. Das ist auch zwingend wenn du die Phase 1 über die IP machen lässt sofern du statische IPs hast. Bei FQDN ist es dann nicht mehr so schlimm aber bei IP dürfen siech die Absender und Ziel IPs dann nicht ändern, was aber passiert wenn du die VPN Protokolle nicht vom PBR excluded hast.
Das Löschen der PBR Route spricht dafür das es dieser Fehler ist. Vermutlich versucht er ddas VPN über die andere verbindung aufzubauen was dann fehlschlägt.
Sieh doch einfach mal ins Log !!!
Was steht denn da wenn der VPN Verbindungsaufbau mit aktivem PBR passiert ??? Woran scheitert es...? Vorher am besten clear logg machen
dann geht es auch nicht da der cisco dann trotzdem wieder alles über die ethernet 0.180 dhcp route sendet?!
Ja, das ist klar, denn dann geht er immer nach der Metrik und der Link mit der schlechteren Metrik wird dann nie genommen nur wenn der Link mit der besseren Metrik ausgefallen ist.Das ist simple IP Routing Logik
Du musst die Metriken gleich halten, damit beide Links gleichwertig sind.
Eigentlich müsstest du nur inbound Traffic über eine ACL klassifizieren und die auf einen festen Link festnageln. Das wärst schon zur Lösung.
Bei einem anderen 887 habe ich 2 ADSL2+ modems davor und zwei Dialer interfaces (Telekom/Vodafone) da geht es einwandfrei auf die Art.
Dann MUSS es auch auf dem anderen gehen. Die Modems sind ja nur Layer 1. Also nur die Übertragungsebene.Die hat nie und nimmer nicht irgendeinen Einfluss auf die L3 Forwarding Entscheidung !
Haben beide Router die gleiche IOS Version geflasht ??
Nichts dahinter ist klar, denn das ist die alte Leier mit der lokalen Firewall wenn es Winblows Clients sind, denn die blocken per se ICMP:
https://www.windowspro.de/tipp/ping-windows-7-server-2008-r2-zulassen
Nur mal doof nachgefragt:
Hast du beim Pingen an den extended Ping gedacht beim Cisco ??
Was immer gehen muss ist ein extended Ping vom lokalen Ethernet Interface des Routers auf das remote Ethernet Interface der LANs bzw. IPs die du im VPN Tunnel erlaubst über die dazu korrespondierende ACL.
Macht du keinen extended Ping dann nimmt der Cisco eine zufällige Absender IP und der Ping schlägt dann fehl...
Nur um dir das nochmal in Erinnerung zu bringen !
https://www.windowspro.de/tipp/ping-windows-7-server-2008-r2-zulassen
Nur mal doof nachgefragt:
Hast du beim Pingen an den extended Ping gedacht beim Cisco ??
Was immer gehen muss ist ein extended Ping vom lokalen Ethernet Interface des Routers auf das remote Ethernet Interface der LANs bzw. IPs die du im VPN Tunnel erlaubst über die dazu korrespondierende ACL.
Macht du keinen extended Ping dann nimmt der Cisco eine zufällige Absender IP und der Ping schlägt dann fehl...
Nur um dir das nochmal in Erinnerung zu bringen !
Das hört sich ja schon mal gut an....
Da du den Cisco selber mit der .77.254 erreichen kannst ist das ein sicheres Indiz dafür das du das gesamte .77.0er Netz generell erreichen kannst.
Wenn Komponenten dahinter nicht pingbar sind, dann ist das zu 98% ein Problem der dortigen lokalen Firewall oder eines vergessenen Gateway Eintrags.
Ein extended Ping auf eine Endgeräte IP im .77.0er Netz muss dann auch fehlerfrei funktionieren.
Sehr hilfreich ist es hier mal auf so einem Endgerät einen Wireshark Sniffer mitlaufen zu lassen !!
Wenn du dann dort eingehende ICMP (Ping) Pakete sehen kannst weisst du das die da sauber ankommen und der Fehler dann nicht an deiner Router Konfig liegen !!
Also Wireshark ist hier dein Freund damit wir das letzte "Problemchen" auch noch fixen...
Einen ziemlichen Kardinalsfehler hast du übrigens noch in der Konfig !!!
Und das gerade im betroffenen .77.0er Netz.
Deine DHCP Konfig mit dem Excluden der beiden einzigen Adressen
ip dhcp excluded-address 192.168.77.100
ip dhcp excluded-address 192.168.77.50
Ist natürlich vollkommen falsch.
Allein dein Router hat ja die .77.254 und die müsste zwingend excluded werden damit es hier niemals zu einer Überschneidung kommt. Ggf. liegt hier auch das Problem.
Der Cisco vergibt immer von oben nach unten und hat die .254 vermutlich an einen Client vergeben was dann zu Chaos führt.
Eigentlich vollkommen unverständlich das dir das nicht aufgefallen ist ?!
Du solltest das dringend besser in:
ip dhcp excluded-address 192.168.77.1 192.168.77.49
ip dhcp excluded-address 192.168.77.101 192.168.77.254
abändern.
Damit ist dann alles excluded (ausgenommen) bis auf den Adress Pool Bereich .77.50 bis .77.100 der dann den Clients dynamisch zugewiesen wird.
Statische Adressen sollten natürlich dann nicht im bereich 50 bis 100 liegen !! Falls doch musst du den Bereich eben etwas schieben.
Hilfreich hier auch noch das Global Kommando:
ip dhcp binding cleanup interval 600
Habe ich hier einen Denkfehler? Oder was fehlt dem Cisco da ?
Nein einen Denkfehler hast du nicht.Da du den Cisco selber mit der .77.254 erreichen kannst ist das ein sicheres Indiz dafür das du das gesamte .77.0er Netz generell erreichen kannst.
Wenn Komponenten dahinter nicht pingbar sind, dann ist das zu 98% ein Problem der dortigen lokalen Firewall oder eines vergessenen Gateway Eintrags.
Ein extended Ping auf eine Endgeräte IP im .77.0er Netz muss dann auch fehlerfrei funktionieren.
Sehr hilfreich ist es hier mal auf so einem Endgerät einen Wireshark Sniffer mitlaufen zu lassen !!
Wenn du dann dort eingehende ICMP (Ping) Pakete sehen kannst weisst du das die da sauber ankommen und der Fehler dann nicht an deiner Router Konfig liegen !!
Also Wireshark ist hier dein Freund damit wir das letzte "Problemchen" auch noch fixen...
Einen ziemlichen Kardinalsfehler hast du übrigens noch in der Konfig !!!
Und das gerade im betroffenen .77.0er Netz.
Deine DHCP Konfig mit dem Excluden der beiden einzigen Adressen
ip dhcp excluded-address 192.168.77.100
ip dhcp excluded-address 192.168.77.50
Ist natürlich vollkommen falsch.
Allein dein Router hat ja die .77.254 und die müsste zwingend excluded werden damit es hier niemals zu einer Überschneidung kommt. Ggf. liegt hier auch das Problem.
Der Cisco vergibt immer von oben nach unten und hat die .254 vermutlich an einen Client vergeben was dann zu Chaos führt.
Eigentlich vollkommen unverständlich das dir das nicht aufgefallen ist ?!
Du solltest das dringend besser in:
ip dhcp excluded-address 192.168.77.1 192.168.77.49
ip dhcp excluded-address 192.168.77.101 192.168.77.254
abändern.
Damit ist dann alles excluded (ausgenommen) bis auf den Adress Pool Bereich .77.50 bis .77.100 der dann den Clients dynamisch zugewiesen wird.
Statische Adressen sollten natürlich dann nicht im bereich 50 bis 100 liegen !! Falls doch musst du den Bereich eben etwas schieben.
Hilfreich hier auch noch das Global Kommando:
ip dhcp binding cleanup interval 600
Nochmal ganz langsam....
Du bist an dem Cisco, der auch das .77.0er Netz hält und pingst dort vom Cisco CLI ein Endgerät in eben diesem lokalem Netz und das geht nicht ??
Das kann niemals sein.
Auch hier gilt wenn du vom Cisco pingst wieder Extended Ping ansonsten nimmt der Cisco wieder ne falsche Absender IP. Auch wenn das Netzwerk bei ihm lokal ist !
Wenn dann debugst du icmp aber kein Crypto. VPN geht ja ....
Du bist an dem Cisco, der auch das .77.0er Netz hält und pingst dort vom Cisco CLI ein Endgerät in eben diesem lokalem Netz und das geht nicht ??
Das kann niemals sein.
Auch hier gilt wenn du vom Cisco pingst wieder Extended Ping ansonsten nimmt der Cisco wieder ne falsche Absender IP. Auch wenn das Netzwerk bei ihm lokal ist !
Wenn dann debugst du icmp aber kein Crypto. VPN geht ja ....
Mmmhhh... Wie sieht deine Routing Tabelle aus bei aktivem VPN-Anyconnect Client und WebVPN ?? (route print)
Routest du mit einem Gateway Redirect, also alles dann in den Tunnel oder mit Split VPN also nur die spezifischen IP Netze in den Tunnel ??
Bei letzterem könnte der Fehler sein das das .77.0er Netz nicht an den Client distribuiert wird ?!
Komisch allerdings ist das die Clients den Cisco mit der .77.254er Adresse erreichen können. Zeigt dann sicher das .77.x Pakete sauber und richtig im VPN geforwardet werden.
Und...lässt dann doch wieder auf ein Firewall Problem lokaler (Windows) Endgeräte im .77.0er Netz schliessen.
Hast du ggf. ein Endgerät im .77.0er Netz das ganz sicher KEINE Firewall hat wie NAS, Drucker, VoIP Telefon, WLAN Accesspoint oder sowas ??
Routest du mit einem Gateway Redirect, also alles dann in den Tunnel oder mit Split VPN also nur die spezifischen IP Netze in den Tunnel ??
Bei letzterem könnte der Fehler sein das das .77.0er Netz nicht an den Client distribuiert wird ?!
Komisch allerdings ist das die Clients den Cisco mit der .77.254er Adresse erreichen können. Zeigt dann sicher das .77.x Pakete sauber und richtig im VPN geforwardet werden.
Und...lässt dann doch wieder auf ein Firewall Problem lokaler (Windows) Endgeräte im .77.0er Netz schliessen.
Hast du ggf. ein Endgerät im .77.0er Netz das ganz sicher KEINE Firewall hat wie NAS, Drucker, VoIP Telefon, WLAN Accesspoint oder sowas ??