Top-Themen

Aktuelle Themen (A bis Z)

Administrator.de FeedbackApache ServerAppleAssemblerAudioAusbildungAuslandBackupBasicBatch & ShellBenchmarksBibliotheken & ToolkitsBlogsCloud-DiensteClusterCMSCPU, RAM, MainboardsCSSC und C++DatenbankenDatenschutzDebianDigitiales FernsehenDNSDrucker und ScannerDSL, VDSLE-BooksE-BusinessE-MailEntwicklungErkennung und -AbwehrExchange ServerFestplatten, SSD, RaidFirewallFlatratesGoogle AndroidGrafikGrafikkarten & MonitoreGroupwareHardwareHosting & HousingHTMLHumor (lol)Hyper-VIconsIDE & EditorenInformationsdiensteInstallationInstant MessagingInternetInternet DomäneniOSISDN & AnaloganschlüsseiTunesJavaJavaScriptKiXtartKVMLAN, WAN, WirelessLinuxLinux DesktopLinux NetzwerkLinux ToolsLinux UserverwaltungLizenzierungMac OS XMicrosoftMicrosoft OfficeMikroTik RouterOSMonitoringMultimediaMultimedia & ZubehörNetzwerkeNetzwerkgrundlagenNetzwerkmanagementNetzwerkprotokolleNotebook & ZubehörNovell NetwareOff TopicOpenOffice, LibreOfficeOutlook & MailPapierkorbPascal und DelphiPeripheriegerätePerlPHPPythonRechtliche FragenRedHat, CentOS, FedoraRouter & RoutingSambaSAN, NAS, DASSchriftartenSchulung & TrainingSEOServerServer-HardwareSicherheitSicherheits-ToolsSicherheitsgrundlagenSolarisSonstige SystemeSoziale NetzwerkeSpeicherkartenStudentenjobs & PraktikumSuche ProjektpartnerSuseSwitche und HubsTipps & TricksTK-Netze & GeräteUbuntuUMTS, EDGE & GPRSUtilitiesVB for ApplicationsVerschlüsselung & ZertifikateVideo & StreamingViren und TrojanerVirtualisierungVisual StudioVmwareVoice over IPWebbrowserWebentwicklungWeiterbildungWindows 7Windows 8Windows 10Windows InstallationWindows MobileWindows NetzwerkWindows ServerWindows SystemdateienWindows ToolsWindows UpdateWindows UserverwaltungWindows VistaWindows XPXenserverXMLZusammenarbeit

gelöst Cisco SVTI - Tunnel

Mitglied: Serial90

Serial90 (Level 1) - Jetzt verbinden

15.03.2017 um 17:08 Uhr, 4232 Aufrufe, 44 Kommentare

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)
44 Antworten
Mitglied: aqui
15.03.2017 um 17:15 Uhr
Du solltest strategisch vorgehen:
  • 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 ?!
Bitte warten ..
Mitglied: aqui
16.03.2017, aktualisiert 01.04.2017
So, das Problem ist in der Tat das NAT was du vermutlich nicht bedacht hast.
Hier ein funktionsfähiger Testaufbau mit der Lösung:

2routervti - Klicke auf das Bild, um es zu vergrößern

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 !!
Bitte warten ..
Mitglied: Serial90
17.03.2017 um 11:42 Uhr
Moin, Moin.

Danke für die Super Anleitung!

Ich habe wohl allerdings ein ganz anderes Problem mit den beiden Geräten:

Ich habe heute versucht zu nächst einmal eine IPSEC-Verbindung zwischen den beiden Geräten via Crypto-Map herzustellen.

Leider erfolglos. Die beiden Geräte (2951 und 887V) habe ich nach deinem Tutorial von hier konfiguriert.

Config 2951:

887V:
Wenn ich nun an beiden Routern mit sh crypto isamkp sa und ipsec sa schaue steht da nichts drin?!? Lasse ich ein debug laufen sehe ich nichts was die Kommunikation der beiden Routern betrifft?! An dem 2951 laufen allerdings noch 2 andere Cryptomap Tunnel zu Bintec und Juniper Geräten einwandfrei bis dato?! Ebenso kann ich mich mobil enwählen in den 887V ohne Probleme nur dieser statische Tunnel möchte nicht?! Habe beide Router schon neugestartet hat aber nichts gebracht!?

Bin völlig ratlos?
Bitte warten ..
Mitglied: aqui
17.03.2017, aktualisiert um 16:49 Uhr
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):
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.
Bitte warten ..
Mitglied: Serial90
22.03.2017 um 16:28 Uhr
Moin, moin.

ich kam leider erst heute zu einem Test. (viel Stress auf Arbeit momentan)

Ich habe nun alles so gemacht wie oben beschrieben aber es baut sich keinerlei Tunnel?! Bin völlig ratlos?

Hier der Debug:

Bitte warten ..
Mitglied: aqui
23.03.2017, aktualisiert um 11:05 Uhr
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 !!
Bitte warten ..
Mitglied: Serial90
23.03.2017 um 13:28 Uhr
Oh maaaan.... Entschuldigung!

Ich habe es jetzt vermeintlich richtig gemacht:

ABER keinerlei Anzeige im Debug? Sollte das irgendwann funktionieren brauche ich dringend Urlaub...
Bitte warten ..
Mitglied: aqui
23.03.2017, aktualisiert um 16:25 Uhr
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.
Bitte warten ..
Mitglied: Serial90
24.03.2017 um 15:55 Uhr
Ich teste die standard IPsec Konfig.

Ich habe nochmals alles kontrolliert aber ich kann keinen Fehler finden?!

Ein Tunnel zu einem Bintec router (auch über die routemaps usw.) läuft einwandfrei seit Tagen?!

Nur der Cisco-Cisco Tunnel will nicht....

Hier nochmals die komplette router Config. :

Bitte warten ..
Mitglied: aqui
24.03.2017, aktualisiert um 17:43 Uhr
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 binding cleanup interval 600
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.
Hier kannst du nicht mixen mit statischen IPs ! Dort darf nur sowas stehen wie:
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 ?
Bitte warten ..
Mitglied: Serial90
25.03.2017 um 08:50 Uhr
Moin, moin.

Vielen Dank zu nächst einmal für die guten Tipps!

Ich habe jetzt alles was Backup ist auf shutdown gesetzt und nur den Dialer 1 mit der wie oben beschriebenen Konfig genutzt.

Allerdings wieder selbes Spiel, mit dem exten. Ping keinerlei debug sichtbar.

Der Cisco 887 soll nur den Cisco 2950 und den Bintec bedienen.

Beide haben dynamische IPs, bekomme erst ab mitte Mai feste an allen Anschlüssen.
Bitte warten ..
Mitglied: aqui
25.03.2017, aktualisiert um 14:46 Uhr
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
Bitte warten ..
Mitglied: Serial90
25.03.2017, aktualisiert 26.03.2017
ERFOLG!

Nachdem ich nun aus lauter Wut und Verzweiflung beide Router zurückgesetzt habe und die Firmware aktualisiert habe.

Vielen Dank bis hier! Du bist der beste !!!



Nur leider habe ich jetzt noch das kleine Problemchen das ich zwar die beiden Router gegeneinander Pingen kann aber keinen im Netzwerk dahinter? z.b. Router1 : 192.168.66.254 ping geht. 192.168.66.100 ping geht nicht?! Komme auch per RDP nicht auf die entsprechenden Geräte drauf.

Und wie bewerkstellige ich es mit den Crypto Maps das wenn man bei windows auf netzwerk geht, die Netzwerkgeräte angezeigt werden? Quasi als wäre man im selben Netz? GRE?
Bitte warten ..
Mitglied: aqui
26.03.2017, aktualisiert um 13:24 Uhr
Tadaaa!!! Klasse. Das wäre jetzt auch mein allerletzter Vorschlag gewesen und du hast intuitiv mitgedacht
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: https://www.administrator.de/index.php?content=104978#396040
  • 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.
Bitte warten ..
Mitglied: Serial90
27.03.2017 um 13:24 Uhr
Moin, Moin!

Ich habe nun denke ich auch den VTI Tunnel laufen! Vielen Dank nochmals!

Cisco 2951
Cisco887V

Nur eine kleinigkeit habe ich noch die nicht will:

Ich kann von dem Cisco 887V (192.168.66.254) zu dem Cisco 2951 (192.168.83.254) 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?

Cisco 887V

Cisco 2951

Bitte warten ..
Mitglied: aqui
27.03.2017, aktualisiert um 15:20 Uhr
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.
Letzteres ist das häufigstes.
Wir hatten gerade so ein Firewall Drama hier kürzlich und das noch nichtmal mit VPN:
https://www.administrator.de/forum/routingproblem-homerouter-kaskade-ras ...
Bitte warten ..
Mitglied: Serial90
29.03.2017, aktualisiert um 13:19 Uhr
Moin, Moin!

Du hattest wie immer recht! Es war die lokale Firewall am Gerät! DANKE!

Ich habe aber nun ein ganz anderes Porblem bekommen nach einem Netzausfall verbindet sich der VTI-Tunnel nicht mehr? (Die IPs Stimmen)

Das kommt im debug raus am Cisco 887:



Und das am 2951:

Bitte warten ..
Mitglied: aqui
29.03.2017 um 15:14 Uhr
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.
Bitte warten ..
Mitglied: Serial90
29.03.2017 um 15:42 Uhr
Nein habe glücklicherweise alles gesichert.

Das Problem liegt in der Tat an den IPs. Habe soeben auf beiden Seiten die tunnel destination erneuert und sofort war er wieder da?!

Nur wie soll ich das bewerkstelligen mit Dyndns Namen anstelle von festen IPs? Gar nicht oder gibt es da ein Weg?

Meinst du mit den /32er Loopback Adressen ein Loopbackinterface welches dann die Dyndns namen inne hat? Und die Tunnelsource dann dieses Loopbackinterface?
Bitte warten ..
Mitglied: aqui
30.03.2017 um 18:56 Uhr
Du kannst in der VTI Konfig global ein Interface angeben statt IP und bindest dann die Tunnel Interfaces auf /32er Loopback Adressen.
Das müsste klappen und das Problem fixen.
Bitte warten ..
Mitglied: Serial90
01.04.2017 um 12:20 Uhr
OK.

Das würde dann so aussehen?

Aber wie binde ich das an den Tunnel anstelle der 192.168.99.2(1) IP?
Wenn ich am Cisco versuche das Loopback zu setzen an dem Tunnel dann geht es nicht er nimmt in dem Tunnelinterface nur IPs?

Oder habe ich hier ein Grundsatzproblem?!
Bitte warten ..
Mitglied: aqui
01.04.2017 um 14:19 Uhr
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 !
Bitte warten ..
Mitglied: Serial90
07.04.2017, aktualisiert 08.04.2017
Moin moin!

ich habe jetzt die ganze Geschichte mit dem Loopback interface gemacht wie oben beschrieben.

Es lief auch alles super und sehr stabil.

Allerdings gab es heute einen IP-Change auf der Seite des 887V (Telekom mit Dyn IP), seit dem habe ich keinen Tunnel mehr.
Das Protokoll ist down und im Log des 2951 sehe ich nur das hier:

Ich verstehe es allerdings nicht? Da sich an den Proposals nichts geändert hat? Nur die blöde IP auf der eine Seite ist nun ne andere? 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?
Oder habe ich hier einen groben Denkfehler noch immer drin?


Mir ist auch aufgefallen das mein Problem wahrscheinlich daran liegt das der 2951 bei tunnel Destination die IP nicht aktualisiert trotz das ich den Hostname von dyndns angeben habe statt IP? Mache ich dies per hand indem ich einfach nochmals tunnel des..... usw. eingebe löst er kurz auf und sofort steht der tunnel wieder wie ne 1.

Und ich habe noch ein etwas kompliziertes Problem mit dem SVTI Tunnel:

Ich habe auf dem Cisco 887V ein PBR laufen welches ihm sagt: Es gibt 2 Netze (192.168.77.0 und 192.168.66.0) die 77.0 soll via dialer 0 raus und die 66.0 soll via dialer 1 raus. ---> Bis hier klappt auch alles wunderbar soweit.

Nun habe ich auf dem 66.0 Netz - 3 IPSEC-Tunnel laufen. 1. Tunnel und 2. Tunnel gehen via Crypto map und dyn IPS zu zwei Bintec Routern (Netze 36.0 und 10.0) und der 3. Tunnel geht via SVTI Tunnel zu dem o.g Cisco 2951. Über die Bintec Tunnel geht alles wunderbar. (Ping RDP usw.) ABER über den SVTI tunnel bekomme ich von einem client PC keinen Ping oder sonst was in das 83er Netz rein?

Mache ich am Cisco 887V ein: ping 192.168.83.254 source interface vlan1, geht dieser auch fehlerfrei zum Cisco 2951 durch.

Was habe ich hier in meiner Konfig. falsch gemacht? Router - Router ping geht aber nicht Client -Client?

Hier die Konfig. vom Cisco887 :

Bitte warten ..
Mitglied: aqui
09.04.2017 um 11:46 Uhr
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.
Bitte warten ..
Mitglied: Serial90
09.04.2017, aktualisiert um 15:51 Uhr
So also ich habe jetzt mein IP Routing Problem gelöst.

Es lag an fehlenden denys in den ACLs:

Diesen gesetzt und schon kam ich auf den 2951 und in das Netz hinter Ihm! DANKE!

Ja mein Tunnnel interface ist auf down.

OK. Dann werde ich mich da mal durchforsten. Danke für den Tipp!

Eine letzte Sache habe ich dann doch noch.

Und zwar komme ich an eine 1921 ebenfalls nicht weiter mit einem Client-login (eigentlich das einfachste der Welt)
Das Problem ist das auch hier ein PBR läuft und ich auch soweit alles am laufen habe, allerdings können keine Clients ins interne Lan pingen via client-tunnel?! (Virtual-Template 10 z.b.) Habe ich hier etwas ganz einfaches übersehen!?

Hier die Konfig:

Bitte warten ..
Mitglied: aqui
09.04.2017, aktualisiert um 21:36 Uhr
Es lag an fehlenden denys in den ACLs:
Wie vermutet
Das Client Problem sehe ich mir morgen mal an.... Bestimmt auch wieder ein Flüchtigkeitsfehler
Bitte warten ..
Mitglied: aqui
10.04.2017 um 19:09 Uhr
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
Bitte warten ..
Mitglied: Serial90
22.04.2017, aktualisiert 23.04.2017
Moin moin!

Ich habe nun endlich weiter machen können am Cisco!

Ich habe die VPN-Config gesäubert und festgestellt das es mit den 2 Internetanschlüssen zusammen hängt und dem PBR.

nehme ich das vom Interface GE0/0 weg gehen meine VPN Clients sofort durch mit einem Ping.

Nur wenn ich das weg nehme geht doch immer nur einer von beiden Internetanschlüsse?!

Die Frage wäre nun wie ich es konfigurieren kann das über das 36er Netz alle Geräte ins Internet kommen via GE 0/0 und über das vlan 40 alle Geräte aus dem 40er Netz via dialer0 ins Netz.

Zudem ist mir aufgefallen das wenn ich einen Ping zu der VDSL Schnittstelle sende von extern mit nichts antwortet?!

Hilfe?!
Bitte warten ..
Mitglied: aqui
23.04.2017, aktualisiert um 14:48 Uhr
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:
https://www.administrator.de/articles/detail.php?id=103423
http://www.cisco.com/c/en/us/support/docs/ip/network-address-translatio ...
Bitte warten ..
Mitglied: Serial90
21.05.2017, aktualisiert um 10:12 Uhr
Moin, moin!

Also ich habe nun das PBR hinbekommen und beide Internetanschlüsse kommen sauber nach draußen.

Allerdings habe ich nun ein massives VPN-Problem?! Sobald beide default Routen aktiv sind, geht VPN-mäßig gar nichts mehr. Die VPN-Tunnel sind zwar nach wie vor aufgebaut aber es geht keinerlei packet mehr durch?! Wenn ich versuche eine Client-Verbindung aufzubauen meldet er mir host nicht gefunden.

Ich weis mir nun langsam keinerlei Rat mehr. Ich habe es schon mit IP SLA und Track probiert aber diese Funktion ist ja mehr oder weniger nur ein Failover.

Das Problem ist einfach das er zwar von innen nach außen die beiden verschiedenen Default-Routen nutzt aber nicht von außen nach innen?

Hier die momentane Konfig:
Bitte warten ..
Mitglied: aqui
21.05.2017 um 12:13 Uhr
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...
Bitte warten ..
Mitglied: Serial90
21.05.2017, aktualisiert um 17:08 Uhr
Also das excluden habe ich gemacht für beide - denke ich:

OK. Das heist also das es am Cisco niemals möglich ist 2 ISP Anbindungen zu haben? Oder liegt mein Fehler lediglich im PBR? Weil balancen soll da eigentlich gar nix. Kann aber sein das meine Konfig doch einige Fehler hat?!

Lösche ich eine von beiden Default-routen raus, geht sofort alles wieder im VPN?! Dann allerdings bin ich ja wieder am Anfang da ich dann wieder nur einen ISP nutzen kann statt beide.
Bitte warten ..
Mitglied: aqui
21.05.2017, aktualisiert um 18:18 Uhr
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
Bitte warten ..
Mitglied: Serial90
22.05.2017 um 21:02 Uhr
So also ich habe nun das Balance verworfen, da zum einen ja das TCP/IP verhalten dagegenspricht und zum anderen der CPU des 887 eh nicht soviel bandbreite schafft mit NAT,ACL usw.

Nun habe ich versucht ganz einfach und simpel ein Backup via ADSL2+ mit dem Dialer 1(Telekom) bereitzustellen und via ethernet 0.180 (VLAN IP-Verbindung zu lokalen Anbieter) die Hauptleitung. (25Mbit Upload)

Nun habe ich allerdings das Problem wenn ich versuche auf
ein Track zu setzen dies nicht geht am Cisco?
Wenn ich nun allerdings einfach die default Route via dialer 1 auf metric 20 setze, dann geht es auch nicht da der cisco dann trotzdem wieder alles über die ethernet 0.180 dhcp route sendet?!

Das IP SLA wollte ich nach dieser Anleitung einrichten: Firewall.cx

Bin nun völlig ratlos?! Bei einem anderen 887 habe ich 2 ADSL2+ modems davor und zwei Dialer interfaces (Telekom/Vodafone) da geht es einwandfrei auf die Art.

Setze ich das ethernet 0.180 auf down geht alles sofort wieder wunderbar. (VPN/INET)
Bitte warten ..
Mitglied: aqui
23.05.2017 um 11:27 Uhr
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 ??
Bitte warten ..
Mitglied: Serial90
23.05.2017, aktualisiert um 18:19 Uhr
OK! Also ich habe jetzt folgendes getan:

ACL 112 erstellt und inbound auf interface ethernet 0.180 gelegt.
ACL 111 ist weiterhin inbound auf interface Dialer 1.

PBR auf beiden LAN-interfaces gemacht

Vlan 1
Vlan 2
Route-maps erstellt für beide IP-Bereiche:

NAT
Soo dann habe ich zwei default routen:


Nun komme ich mit beiden ISPs einwandfrei raus:
ADSL2+ 16mbit/2 Mbit
VDSLVec 63mbit/33 Mbit

ABER ich weis nicht was du mit dem Festnageln der ACL meinst, sodass ich mein VPN auf ISP1 habe (client Zugriff via Any Connect) und VPN auf ISP2 (Static Multicast Tunnel via tunnel interface 0)

Bin zu blöde irgendwie?!

Die Tunnel bauen sich auch einwandfrei auf ohne Fehler im Log und stehen dann so da:

Allerdings geht keinerlei ping vom interface vlan 1 da durch?

Und baue ich via Anyconnect ein Tunnel auf kann ich wunderbar den Cisco pingen aber nichts dahinter?!
Bitte warten ..
Mitglied: aqui
24.05.2017 um 11:09 Uhr
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 !
Bitte warten ..
Mitglied: Serial90
25.05.2017, aktualisiert um 11:24 Uhr
Soooo ich habe nun den Multicast-Tunnel am laufen und kann vom 192.168.77.0 Netz alles erreichen in 36.0/83.0/10.0! DANKE!
Das Problem war das sich der ISP mit der reinen IP-Anbindung immer vor die PPPOE-Anbindung gestellt hat und somit dort die Ports tot waren und somit kein Tunnelaufbau möglich war-Habe das dann Tunnelmäßig alles auf die im Upload schnellere VDSV Verbindung umgemünzt und schon ging es.


ABER ich kann nicht von den Anyconnect-Clients irgendwas im 77.0 Netz erreichen?! (Außer den Cisco selbst also die 77.254 und die 83.0/36.0/10.0)
Habe ich hier einen Denkfehler? Oder was fehlt dem Cisco da ?

Die beiden Internetanschlüsse laufen wie gewollt.
ADSL2+ DTAG ist online und wird nur genutzt um Daten raus zusenden und nicht für VPN oder Portweiterl.
VDSLV ist online und wird genutzt für VPN Static Tunnel und Anyconnect Client Zugriff. (Habe nur noch das o.g. Problem)

Hier nochmals die Konfig wie sie nun ist und scheinbar läuft:

Bitte warten ..
Mitglied: aqui
25.05.2017, aktualisiert um 12:52 Uhr
Das hört sich ja schon mal gut an....
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
Bitte warten ..
Mitglied: Serial90
26.05.2017 um 07:39 Uhr
OK. Also ich habe nun den DHCP-Fehler behoben und den Wireshark auf den Geräten am laufen.

Es kommt allerdings keinerlei icmp an dem Gerät an? Allerdings an den Geräten in den VPN Netzen schon und da geht er ja auch sauber durch.

Verstehe ich nicht wieso die VPN-Netze funktionieren und das eigene (77.0) nicht sondern nur der Cisco?!

Wenn ich am Cisco den crypto Debug laufen lasse kommt auch keinerlei fehler oder sontiges?
Bitte warten ..
Mitglied: aqui
26.05.2017, aktualisiert um 15:55 Uhr
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 ....
Bitte warten ..
Mitglied: Serial90
26.05.2017 um 16:30 Uhr
Nein. Ich bin via VPN-Anyconnect Client und WebVPN von Cisco---> an dem Cisco.

Diese Clients sollten das 77.0 Netz erreichen können. Dies tun Sie aber nicht.
Schaue ich dann an den jeweiligen Endgeräten mit Wireshark kommt dort nichts an von meinen VPN Geräten?! Also kein ICMP.

Versuche ich nun aber von dem VPN-Anyconnect Client eins der anderen Netze, die wiederrum via VPN-Multicast Tunnel angebunden sind zu erreichen, geht dies wunderbar.

Nur das Netz vom dem Cisco erreiche ich von den VPN-Clients aus nicht, diese können lediglich den Cisco-887V selbst erreichen via ICMP (192.168.77.254)
Bitte warten ..
Mitglied: aqui
LÖSUNG 27.05.2017, aktualisiert um 11:50 Uhr
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 ??
Bitte warten ..
Mitglied: Serial90
04.06.2017, aktualisiert 21.06.2017
Vielen Dank für deine Hilfe!

Ich habe es jetzt rausgefunden was mein Fehler war:

----> 08. musste ich weglassen und schon lief alles Prima! alle 66er via dialer 1 raus und alle 77er via ethernet 0.180 und der Anyconnect kam auch sauber durch auf das 77er.

DANKE!
Bitte warten ..
Ähnliche Inhalte
Router & Routing
IPv6 Tunnel im Cisco 886
gelöst Frage von Windows10GegnerRouter & Routing16 Kommentare

Hallo, ich will nun IPv6 auch in meinem internen Netz nutzen und habe daher einen Tunnel bei Hurricane Electrics ...

Router & Routing
IPv6 Konfig mit Tunnel im Cisco 886
gelöst Frage von Windows10GegnerRouter & Routing6 Kommentare

Hallo, auf meinem Cisco ist IPv6 bereits nutzbar. Jetzt möchte ich die Adressen auch im Netzwerk verteilen. Erste Frage: ...

Netzwerke
VPN-Tunnel von Cisco RV320 zur FB7490
Frage von AlhamanNetzwerke7 Kommentare

Hallo, ich habe die Aufgabe ein paar Feldgeräte in einem Kundennetz so zu verbinden, dass diese unseren internen FTP-Server ...

Router & Routing

Cisco Router Tunnel 2x gleiches Netz durch Fremdnetz verbinden

gelöst Frage von twicefaceRouter & Routing5 Kommentare

Guten Tag allerseits, Ich habe 2x das gleiche Netzwerk welche durch ein fremdes Netzwerk verbunden werden sollen. Meine Idee: ...

Neue Wissensbeiträge
Exchange Server

ACHTUNG: Ungepatchte Exchange Server aktuell im Visier von Angreifern!

Tipp von vibrations vor 2 StundenExchange Server

Wer es noch nicht mitbekommen haben sollte: Exchange-Server Systeme werden gerade vermehrt auf eine Sicherheitslücke mit der sich das ...

Microsoft Office

Office 365 Makro Schutz nicht immer per GPO möglich

Information von sabines vor 3 TagenMicrosoft Office5 Kommentare

Der zum Schutz gegen Verschlüsselungstrojaner wichtige Makroschutz lässt sich wohl in Office 365 nicht immer per GPO einstellen. Für ...

Netzwerkmanagement
How To Mikrotik Netinstall
Erfahrungsbericht von areanod vor 5 TagenNetzwerkmanagement

Jedes Mal wenn ich Netinstall längere Zeit nicht benutzt habe stolpere ich über die „Besonderheiten“ dieser Software. Das ist ...

Microsoft
Microsoft: LDAPS per Update als Default
Information von em-pie vor 5 TagenMicrosoft2 Kommentare

Hallo, Microsoft wird mit einem der zukünftigen Updates LDAP auf LDAPS per Default umstellen. Admins von angebundenen Systemen die ...

Heiß diskutierte Inhalte
Netzwerkgrundlagen
Reichweite bei Netzwerkdruckern mit Kupfer
gelöst Frage von OIOOIOOIOIIOOOIIOIIOIOOONetzwerkgrundlagen41 Kommentare

Guten Tag, aus gegebenem Anlass, möchte ich euch fragen, was aus eurer Sicht, eine akzeptable Reichweite bei einem Netzwerkdrucker ...

DSL, VDSL
Gigabit Leitung - niedrige Geschwindigkeit
Frage von Ghost108DSL, VDSL25 Kommentare

Hallo zusammen, ich bin vor kurzem auf den Tarif Vodafone Cable Max 1000 umgestiegen. Techniker war vor Ort und ...

Visual Studio
Aufgabenplaner führt Programm inkorrekt aus
gelöst Frage von TallerBiskusVisual Studio23 Kommentare

Hallo Leute :) Ich habe ein sehr seltsames Phänomen. Folgende Gegebenheiten : Wir haben einen Windows Server 2012 R2 ...

Hardware
Stromausfalllogger
Frage von certifiedit.netHardware21 Kommentare

Guten Nachmittag, welche Geräte könnt Ihr empfehlen um Stromausfälle, optimalerweise auch Frequenzstörungen zu loggen? Geht hier um keinen konkreten ...