266
Cisco 880, 890 und ISR Router Konfiguration mit xDSL, Kabel oder FTTH Anschluss plus VPN und IP-TV
Das folgende Tutorial ist ein universeller Leitfaden zur Konfiguration von Cisco Routern der Modellreihen 800 und höher sowie aller aktuellen ISR Modelle für den Einsatz an xDSL und G.fast sowie an Glasfaser und Kabel-TV Anschlüssen.
Die in diesem Tutorial beschriebenen Konfigurationsschritte gelten generell für alle IOS/IOS-XE basierten Cisco Router mit integriertem xDSL Hybridmodem und Ethernet bzw. Breitband Ports mit SFP Optiken.
Cisco Routermodelle stellen mit ihren weitreichenden NAT und Firewall Sicherheitsfeatures, dem integrierten hybriden xDSL sowie G.fast Vectoring Modem und der VPN Fähigkeit eine universelle Lösung für eine skalierbare und zukunftsorientierte Firmenanbindung kleiner und mittlerer Standorte mit xDSL, Kabel-TV oder Glasfaser WAN Bandbreiten dar. Sie sind ebenso für den anspruchsvollen Heimnutzer gedacht der Wert auf Sicherheit und maximalen Funktionsumfang legt.
Die Grundkonfiguration dieser Router ist durch die IOS Syntax universell und kann deshalb in Gänze oder Teilen auch auf alle anderen Cisco IOS Router- und Switchmodelle übernommen werden !
Cisco 886va(w), 887va(w) und auch deren Gigabit Pendant 896, 897 bzw. die derzeit aktuelle Cisco ISR Router Serie mit Cisco 900 oder Cisco 1100 sind sog. "Multi Service" ISR Router mit einem integrierten Multimode xDSL Hybrid Modem für VDSL2 und ADSL2/2+ (Annex B+J (ADSL2+ over ISDN)) sowie SDSL mit ITU G.993.2 (VDSL2) Super Vectoring, Profil 35b und G.fast.
Anwender ohne xDSL Anschluss z.B. mit einem Kabel TV Modem Anschluss oder Glasfaser, wählen hierfür Modelle mit Breitband WAN Port. Der WAN/Internet Port dieser Modelle ist ein reiner Ethernet Breitband Port ohne ein integriertes xDSL Modem zum Anschluss an vorhandene Kabel TV Modems oder FTTH / FTTB (Fiber to the Home/Building, Glasfaser) Anschlüsse.
Alle Modelle gibt es zusätzlich in einer Variante mit integriertem WLAN und/oder auch mit 4G/5G Mobilfunk Modem sowie auch VoIP Anschlüssen.
Eine Übersicht der 880er Modelle sowie die Datenblätter der 890er Modelle und der aktuellen ISR 900er sowie 1100er Modelle findet man auf der Cisco Webseite.
ISR Router besitzen durchgängig mindestens 4 integrierte Ethernet RJ-45 LAN Ports die VLAN fähig sind. Die 890er Modelle haben durchgängig 8 LAN Ports, die ebenfalls voll VLAN fähig und flexibel auch für zusätzliche WAN Anbindungen nutzbar sind. (Multi WAN-Port Feature).
Cisco 880er Modelle supporten bis zu 20 VPN Verbindungen gleichzeitig (890 supportet 50 Tunnel, 926 und 1112 bis zu 200 VPN Tunnel) und eignen sich damit für anspruchsvolle KMU Firmennetze, Telearbeiter, einer LAN zu LAN Firmenvernetzung auf ADSL/SDSL oder VDSL Basis oder dem eigenen privaten Heimnetzwerk.
ADSL/VDSL fähige Modelle haben allesamt ein Multimode Hybridmodem an Bord, was zudem SDSL fähig ist für Business Anschlüsse.
Mittlerweile sind die 890er 1Gig Modelle recht preiswert auf Auktionsplattformen wie z.B. eBay usw. zu erhalten. Neue Modelle u.a. sogar beim Discounter.
Die hier vorgestellte universelle Grundkonfiguration des Routers ist für beide vorgestellten xDSL Anbindungen (ADSL und VDSL) gleich. Sie unterscheidet sich lediglich in der Konfiguration der ADSL bzw. VDSL Modemeinstellung die unten in separaten Kapiteln vorgestellt wird.
Die Verbindung zum xDSL Anschluß (Telefondose TAE-F) erfolgt über einen handelsüblichen RJ-11 Port mit Mittelpin Belegung. Sofern der xDSL Anschluss noch mit TAE-F Dose ausgerüstet ist, dann mit einem handelsüblichen TAE-F auf RJ-11 Standard Kabel.
Das Tutorial zeigt eine Standardkonfiguration mit 2 angeschlossenen LAN Segmenten z.B. ein lokales Netzwerk und ein Gastnetz, aktivem DHCP und statischen DHCP Reservierungen z.B. für einen Server, NAS o.ä. und einer optionalen VPN Konfiguration mit IPsec oder L2TP VPN Protokoll.
Die Cisco ISR Router sind aktive VPN Router und supporten damit die remote VPN Einwahl für Home Office und mobile Mitarbeiter zum Datenaustausch oder die sichere Fernwartung.
Alles mit den üblichen onboard VPN Clients (L2TP) auf allen Endgeräten. VPNs auf L2TP Protokoll Basis nutzen so die jeweiligen onboard VPN Clients in jedem Betriebssystem und Smartphone und kommen ohne zusätzliche VPN Client Software aus.
Entfernte VPN Standorte bei Site-to-Site VPNs müssen dabei nicht zwingend mit Cisco Hardware ausgestattet sein. IPsec VPN Verbindungen sind problemlos zwischen allen VPN Routern/Firewalls die IPsec entweder mit IKEv1 oder IKEv2 beherrschen möglich.
Wichtig ist hierbei, das die eingesetzten Geräte (z.B. FritzBox, Lancom, NetGear, pfSense/OPNsense, Mikrotik, Microsoft, Linux, Apple Mac, StrongSwan usw.) der Gegenstelle diese VPN Protokolle ebenfalls beherrschen, was bei IPsec so gut wie immer der Fall ist.
Die weiterführenden Links am Ende weisen auf entsprechende VPN Praxistutorials hin die gemischte IPsec Standort- und Client VPN Lösungen mit entsprechenden Beispielkonfigurationen beschreiben.
Für die Router Modelle mit integriertem WLAN Accesspoint findet sich eine entsprechende WLAN Konfig im Abschnitt Wireless. Die Konfiguration ist zu denen dedizierter Cisco Accesspoints identisch.
Die initiale Konfiguration des Cisco Routers sollte immer über den seriellen Konsolen Port (Console) und dem mitgeliefertem seriellen, blauen Konsolen RS-232 Kabel mit RJ-45 Stecker und einem klassischen USB-Serial Adapter erfolgen. Alternative Terminalkabel haben den Adapter bereits im Kabel integriert.
Bei neueren Router Modellen ist die Konsole zusätzlich als USB Port verfügbar. Hier reicht ein normales Micro USB Kabel.
Als Terminal Programme nutzt man die bekannten Windows Klassiker PuTTY oder TeraTerm mit den Parametern 9600 Baud, N, 8, 1 (Keine Parity, 8 Bit, ein Stopbit) und schaltet alle Arten von Flow Control (Hardware, Software) AUS in den seriellen Port Settings der Terminalprogramme.
Bei den Terminalprogrammen ggf. die COM Ports durchprobieren (Windows) da sie nicht überall gleich sind.
Weiter hilft hier wie immer ein Blick in den Windows Geräte-Manager unter Serielle und LPT Ports.
Apple Mac Benutzer nehmen hier ZTerm (Shareware), ZOC oder das bordeigene screen Kommando und Linuxer haben mit minicom immer ein serielles Terminal gleich mit an Bord.
Wer keinen seriellen COM Port (DB-9 Stecker) mehr hat am Rechner, nutzt den oben genannten Seriell-USB Adapter.
Nicht ganz so sattelfeste Cisco IOS Kommando Nutzer finden HIER einen guten, grundlegenden Überblick für das Kommando Interface KnowHow. Bei Konfig Postings im Forum sollte man auf die Anonymisierung der Kennwörter achten bzw. auf das Vorhandensein des Kommandos service password-encryption.
Los gehts...
⚠️ Für die erhöhte Passwortsicherheit ist es ratsam ab Firmware Version 15.3.(3) unbedingt den Typ 9 der Passwortverschlüsselung zu verwenden. Das dazu benötigte Kommando zum Erstellen eines User Accounts mit Typ 9 Verschlüsselung und Admin Level 15 Zugriff lautet:
username <benutzername> privilege 15 algorithm-type scrypt secret <password>
und ist in den hier aufgeführten Konfigurationen entsprechend berücksichtigt.
❗️Ein Router muss die internen Netzwerke die in der Regel private, im Internet nicht geroutete RFC1918 IP Netze haben, auf eine öffentliche IP Adresse umsetzen damit diese im Internet geroutet werden können. Dies geschieht mittels IP Adress Translation (NAT) bei jedem handelsüblichen Router oder Firewall.
Leider wird dieser Punkt in der Cisco Konfig oft übersehen diesen NAT Traffic entsprechend zu klassifizieren, denn der Router muss natürlich wissen was er übersetzen muss und was nicht. Die Klassifizierung geschieht bei Cisco über eine Accessliste.
Im Tutorial definiert diesen Traffic die Accessliste 101 die das lokale Netz und das Gastnetz fürs NAT klassifiziert. Die ACL Nummer oder Name ist frei wählbar.
Alle NAT relevanten Kommandos sind auch in fett hervorgehoben, da sie essentiell sind für die Funktion des Routers
Die ISR Router haben in der Regel mit den Ports x/0 bis x/3 einen internen Layer 2 VLAN Switch an Bord. Diese Switchports sind Layer 2 only und können ergo nicht direkt mit IP Adressen konfiguriert werden.
Das eigentliche IP Routing Interface ist immer das auf diese Switchports gemappte VLAN x Interface. Auf diesem VLAN Interface werden alle IP und Routing relevanten Einstellungen zu dem dort anliegenden IP Netzwerk(en) gemacht. Im Default liegt das VLAN 1 Interface als Access VLAN (untagged) an allen Switchports an.
Hier im Beispiel sind es 2 aktive IP Netze mit dem VLAN 1 Interface (Lokales LAN) und dem VLAN 2 Interface (Gastnetz).
Die folgende Standard IP Basiskonfiguration des Cisco Routers ist in blau gehalten. Die zusätzlichen oder zu ändernden xDSL Modem spezifischen Abschnitte die für eine ADSL, SDSL Konfiguration erforderlich sind, sind jeweils rot eingefärbt. (VDSL hat ein eigenes Kapitel!)
Optionale Kommandos die nicht zwingend für den Betrieb bzw. Konfig erforderlich sind, sind immer in (...) Klammern dargestellt oder entsprechend kommentiert. (Klammern bei Bedarf entfernen!) !
!
service timestamps log datetime localtime show-timezone year
service timestamps debug datetime localtime
service tcp-keepalives-in
service tcp-keepalives-out
no service pad
!
hostname Cisco_Router
!
security authentication failure rate 3 log
enable algorithm-type scrypt secret Geheim123
!
clock timezone CET 1 0
clock summer-time CEST recurring last Sun Mar 2:00 last Sun Oct 3:00
!
aaa new-model
aaa authentication login default local
aaa authorization network default local
aaa local authentication attempts max-fail 3
!
username admin privilege 15 algorithm-type scrypt secret Geheim123
!
no ip source-route
no ip gratuitous-arps
!
ip dhcp binding cleanup interval 180
(ip dhcp relay information trust all) Optional: <-- Nur wenn Cisco fremde Scopes bedienen soll (DHCP Relay). Sonst weglassen
ip dhcp excluded-address 192.168.100.1 192.168.100.149 <-- Schliesst diesen Adressbereich vom DHCP Pool AUS
ip dhcp excluded-address 192.168.100.200 192.168.100.254 (LAN DHCP Pool reicht somit von .150 bis .199 )
!
ip dhcp excluded-address 172.16.100.1 172.16.100.149 <-- Adress Pool für das Gastnetz (.150 bis .199)
ip dhcp excluded-address 172.16.100.200 172.16.100.254
!
ip dhcp pool Lokal
network 192.168.100.0 255.255.255.0
default-router 192.168.100.254
dns-server 192.168.100.254 <-- Weitere DNS Server werden durch Leerzeichen getrennt
(option 42 ip 192.168.100.254) <-- Optional: NTP Zeitserver IP
domain-name meinedomain.internal
!
ip dhcp pool Gastnetz
network 172.16.100.0 255.255.255.0
default-router 172.16.100.254
dns-server 172.16.100.254
domain-name gast.meinedomain.internal
!
ip dhcp pool WinServer <-- Beispiel f. Zuweisung von fester IP auf MAC Adresse (IP zu Mac Binding)
host 192.168.100.170 255.255.255.0
client-identifier 01b0.0c6c.01c4.d2 <-- Hardware Mac Adresse des Clients (vorn ID "01" beachten !)
(hardware-address b00c.6c01.c4d2) <-- Bei Client Mac Adressen die keinen HW_Identifier senden (Linux !)
(client-name winserver) <-- Übergibt Hostnamen an den/die Clients (Optional)
!
ip domain name meinedomain.internal
!
lldp run
no cdp run
!
⚠️ (Alle folgenden "ip inspect..." Kommandos entfallen vollständig wenn statt der klassischen, alten CBAC Firewall mit ip inspect Kommandos die u.a moderne, Zonen basierte ZFW Firewall Konfiguration umgesetzt wird! (Bei neueren ISR Modellen erfordert die Firewall Funktion ggf. eine Lizenz!))
!
ip inspect name myfw http
ip inspect name myfw https
ip inspect name myfw pop3s
ip inspect name myfw imaps
ip inspect name myfw esmtp
ip inspect name myfw sip <-- Firewall Application Gateway f. VoIP
ip inspect name myfw rtsp <-- Firewall Application Gateway f. VoIP
ip inspect name myfw icmp router-traffic
ip inspect name myfw tcp router-traffic
ip inspect name myfw udp router-traffic
!
controller VDSL 0
(firmware filename flash:VA_B_38V_d24m.bin) --> Optional! Nur 880er Vectoring Modem Firmware !
!
interface Ethernet0
no ip address
shutdown
!
interface BRI0
no ip address
shutdown
!
interface FastEthernet0
description Lokales LAN
no ip address
!
interface FastEthernet1
no ip address
!
interface FastEthernet2
no ip address
!
interface FastEthernet3 <-- LAN Port 4, hier Gastnetz anschliessen. (Kann entfallen wenn kein Gastnetz gewünscht.)
description Gastnetz
switchport access vlan 2 <-- Gastnetz Interface, UNtagged VLAN 2
no ip address
!
interface Vlan1
description Lokales LAN (FastEthernet0 bis 2)
ip address 192.168.100.254 255.255.255.0
ip nat inside <-- NAT Eingangsinterface
ip tcp adjust-mss 1452 <-- (⚠️ Nur bei Provider Anschlüssen mit PPPoE erforderlich! Sonst weglassen)
!
interface Vlan2
description Gastnetz (FastEthernet3)
ip address 172.16.100.254 255.255.255.0
ip access-group GASTNETZ in <-- (Optional: Ohne Gäste Beschränkungen oder ZFW Firewall weglassen!)
ip nat inside <-- NAT Eingangsinterface
ip tcp adjust-mss 1452
!
interface Dialer0
description xDSL PPPoE Internet Interface
ip address negotiated
ip access-group 111 in <-- Firewall CBAC Inbound Access Liste. (⚠️ Diese Zeile entfällt bei ZFW Firewall!)
mtu 1492
no ip redirects
no ip unreachables
no ip proxy-arp
ip verify unicast reverse-path
ip nat outside <-- NAT Ausgangsinterface
ip inspect myfw out <-- Firewall aktiv auf dem Internet Port. (⚠️ Diese Zeile entfällt bei ZFW Firewall!)
encapsulation ppp
dialer pool 1
ppp authentication pap callin
ppp pap sent-username 001234567890123456780001@provider.de password 1234567
(⚠️ T-Business SDSL verwendet hier = t-online-com/<nutzer>@t-online-com.de )
ppp ipcp dns request
ppp ipcp mask request
ppp ipcp route default <-- ⚠️ Dafür entfällt die statische Default Route!
!
ip dns server <-- Aktiviert den DNS Caching Server
!
ip nat inside source list 101 interface Dialer0 overload <-- NAT auf dem Dialer Interface für ACL 101 Traffic
!
ip access-list extended GASTNETZ <-- Optionale Gast ACL erlaubt nur DNS u. Web (ggf. um weitere Dienste erweitern !)
3 remark Gastnetz Zugang <-- ACL entfällt vollständig bei ZFW Firewall Konfig!
10 permit udp any eq bootpc any eq bootps
15 deny ip 172.16.100.0 0.0.0.255 192.168.100.0 0.0.0.255
20 permit tcp 172.16.100.0 0.0.0.255 any eq domain
25 permit udp 172.16.100.0 0.0.0.255 any eq domain
30 permit tcp 172.16.100.0 0.0.0.255 any eq www
35 permit tcp 172.16.100.0 0.0.0.255 any eq 443
!
ip access-list extended CLI-ACCESS <-- ACL steuert Konfigurations Zugriffsrecht a. d. Router.
3 remark Konfig Zugang ACL
10 permit tcp 192.168.100.0 0.0.0.255 any eq 22 <-- Erlaubt SSH Zugriff
15 permit udp 192.168.100.0 0.0.0.255 any eq snmp 10161 <-- Erlaubt SNMP und Secure SNMP Zugriff
(20 deny ip any any log-input) <-- Optional! Nur wer verbotene Telnet bzw. SSH Login Versuche mitloggen will!
!
access-list 101 permit ip 192.168.100.0 0.0.0.255 any <-- ACL klassifiziert NAT relevanten Traffic.
access-list 101 permit ip 172.16.100.0 0.0.0.255 any
!
⚠️ Die folgende ACL 111 entfällt vollständig wenn statt der CBAC Firewall Variante (ip inspect Kommandos!) die u.a modernere, Zonen basierte ZFW Firewall Konfiguration umgesetzt wird!
!
access-list 111 permit icmp any any administratively-prohibited <-- Lässt wichtige ICMP Steuerpakete durch die Firewall passieren.
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 5060 any <-- VoIP (SIP) Port 5060. (Entfällt ohne VoIP Anlage, Telefone etc.) im lokalen LAN
(access-list 111 permit udp any eq bootps any) <-- Nur wenn Internet Port per DHCP IP Addresse bezieht ! Sonst weglassen !
access-list 111 deny ip any any (log) <-- (*1)"Log" Siehe u.a. Anmerkung: Parameter nur verwenden wenn man temporär Angriffe aus dem Internet protokollieren möchte. (ACL Logging kostet Performance !)
!
!
dialer-list 1 protocol ip list 101 <-- Startet die PPPoE Verbindung für ACL 101 definierten Traffic
!
ntp server de.pool.ntp.org source Dialer0 (*2) <-- Definiert externen NTP Zeitserver
ntp update-calendar <-- Setzt zusätzlich die interne HW Uhr auf NTP Zeit
!
ip ssh version 2
ip ssh time-out 30
ip ssh authentication-retries 3
!
banner exec #
Sie sind verbunden mit VTY $(line) auf dem Router $(hostname)
#
!
line vty 0 4
access-class CLI-ACCESS in <-- Telnet / SSH Zugriff nur aus lokalem LAN möglich (ACL "CLI-ACCESS")
login local
transport input telnet ssh <-- Telnet / SSH Zugriff. Ist zur Sicherheit nur SSH gewünscht "telnet" hier weglassen.
!
end
(*1) Der Parameter "log" am Ende des letzten Filter Statements der ACL 111 deny ip any any zeigt alle unerlaubten externen Zugriffe im Router Log an und damit diejenigen weltweit, die versuchen den Router anzugreifen.
Es ist sehr interessant (und auch erhellend) das hohe Ausmaß dieser Angriffsversuche einmal live zu sehen, wenn man show logg eingibt oder sich die Syslog Messages des Routers schicken_lässt.
Wen es "nervt" und das Log zu groß wird (denn es gibt sehr sehr viele dieser Angriffe im Sekundentakt !) und wer Wichtigeres im Logging sehen möchte, kann das "log" Statement natürlich auch weglassen aus der ACL Definition.
Letztlich macht das ACL Logging den Router langsamer (Performance !), deshalb ist es besser auf lange Sicht die Logging Statements in den ACLs immer zu deaktivieren!
(*2) de.pool.ntp.org ist der ntp.org Serverpool für DE. Der Cisco arbeitet dann intern selber als NTP Zeitserver für Endgeräte (Siehe "Option 42" oben in der DHCP Server Konfiguration!)
Anmerkung zur DNS Server Konfiguration des Routers:
Die o.a. Grundkonfiguration geht davon aus das PPPoE oder DHCP am WAN Port genutzt wird. Damit lernt der Cisco Router die DNS Server IP Adressen des jeweiligen Provider Anschlusses immer automatisch.
Im Falle einer statischer WAN Port IP Adressierung muss man natürlich die DNS Server IP dann statisch mit dem Kommando:
ip dns-name server <ip_addresse_dns> angeben!
Bei dynamischen Zugängen mit PPPoE, DHCP usw. entfällt diese Angabe! Es sei denn man bevorzugt einen anderen DNS Server als den, den der Provider dynamisch übermittelt.
Jetzt ist der richtige Zeitpunkt für ein write mem Befehl um diese Konfig im Router Flash permanent zu sichern. Ohne Sicherung ins Flash wäre die Konfig nach einem Reboot verloren !
Intern ist im Cisco das integrierte xDSL Hybridmodem im ADSL2+ Modus auf das ATM0 Interface des Routers gemappt und bei VDSL Betrieb ist es das Ethernet0 Interface. Es gilt also:
Der Großteil aller Provider wie auch die Telekom (D) hat seit 2019 ihre Anschlüsse auf BNG umgestellt! Dies erfordert in der Regel ein VLAN Tagging auf dem WAN/Internet Interface. (VLAN ID 7 bei der Telekom)
Daher muss die Konfiguration des Internet Interfaces bei einem BNG Anschluss entsprechend angepasst werden, so das der Router ein VLAN 7 Tag mitschickt:
interface ATM0
description DTAG-BNG ADSL2+
no ip address
no atm ilmi-keepalive
!
interface ATM0.7 point-to-point
pvc 1/32
bridge-dot1q encap 7
pppoe-client dial-pool-number 1
!
Das o.a. Beispiel gilt für einen ADSL Anschluss.
VDSL Pakete müssen in Richtung Provider, wie oben bei ADSL+ auch, ebenfalls mit einem 802.1q VLAN Tag versehen werden ! Bei der Telekom (D) ist das die VLAN ID 7. (ggf. andere bei alternativen Providern!)
Das interne VDSL Modem ist, wie oben schon angemerkt, physisch an die interne Router Ethernet Schnittstelle Ethernet0 gebunden und muss für VDSL damit eine tagged VLAN Konfiguration bekommen.
Dies bewirkt ein sog. Subinterface Ethernet 0.7 in der VDSL Konfig auf dem eigentlichen physischen Interface Ethernet0.
Wird der Router im VDSL Mode betrieben, kann (und sollte) das ATM0 Interface (ADSL) mit "Shutdown" per Konfig deaktiviert werden und das ATM Subinterface mit no interface ATM0.x point-to-point entfernt werden !
Da ADSL mehr und mehr ausstirbt ist also primär die VDSL Konfig und damit das VDSL Modem Interface Ethernet0 relevant.
Die im Folgenden rot markierten Kommandos müssen bei Einsatz eines VDSL Anschlusses hinzugefügt werden. Das ATM Interface (ADSL) wird dann abgeschaltet (shutdown).
!
-- Standard Grundkonfiguration wie oben --
!
controller VDSL 0
firmware filename flash:VA_B_38V_d24m.bin --> Optional nur f. C880 Modell ! Supportet VDSL Vectoring beim 880er Modell !
!
interface Ethernet0
no ip address
no shutdown
!
interface Ethernet0.7
description VDSL Internet Verbindung - VLAN 7 tagged
encapsulation dot1Q 7
pppoe enable group global
pppoe-client dial-pool-number 1
!
interface ATM0
no ip address
shutdown
pvc 1/32
pppoe-client dial-pool-number 1
!
-- Die restliche Konfiguration nach dem Interface ATM0 ist von der o.a. Standart Grundkonfiguration zu übernehmen. --
(Ein show ip interface brief zeigt die korrekte Internetverbindung zum jeweiligen Provider an.)
⚠️ Das zusätzliche VLAN Tagging mit 4 Bytes Overhead hat auch Einfluss auf die MTU Werte bzw. das MSS Setting. Dieses muss entsprechend angepasst werden mit 1488 (MTU, Dialer) und 1448 (MSS f. int. LAN, VPN). Siehe zum Thema MTU auch hier.
Zudem ist sicherzustellen das keines der Interfaces im sog. shutdown Status ist !!
Shutdown bedeutet das das Interface deaktiviert ist. Dies kann immer mit dem Kommando show ip interface brief geprüft werden.
Auch wenn man sich die aktuelle Konfig mit show run ansieht, dann sollte keines der Interfaces im "shutdown" Modus sein. Ausgenommen natürlich NICHT verwendete Interfaces wie z.B. das ATM Interface wenn man VDSL nutzt !
Wenn dennoch eins der aktiven Interfaces ein shutdown anzeigt, bekommt man das mit:
conf t
interface xyz
no shutdown
<ctrl z>
wr
...schnell wieder gefixt.
Man kann später, wenn alles rennt, alle nicht benutzten Interfaces natürlich in den Shutdown versetzen. Beim Aufsetzen der Konfig und Testen kann das aber fatale Fehler ergeben so das man darauf während der Grundkonfiguration besser erstmal verzichtet !
Andere VDSL Provider nutzen statt der 7 bei der Telekom oft andere VLAN ID Tags ! Bei Vodafone z.B. ist das die VLAN ID 132.
Die korrekte Port Konfiguration für Vodafone VDSL (VLAN Tag 132) sieht dann z.B. entsprechend so aus:
!
interface Ethernet0
no ip address
no shutdown
!
interface Ethernet0.132
description VDSL Internet Verbindung - Vodafone
encapsulation dot1Q 132
no ip route-cache
pppoe enable
pppoe-client dial-pool-number 1
Die folgenden Informationen gelten ggf. analog für andere Wiederverkäufer ohne eigenes Netz:
Vodafone ist in einigen Fällen Wiederverkäufer von Telekom VDSL Leitungen. In diesem Fall gilt dann weiterhin das VLAN 7 Tag !
Vodafone Usernamen sehen auf solchen Links dann so aus: vodafone-vdsl.komplett/ad123456789
Siehe dazu auch hier.
⚠️ Noch ein warnendes Wort zu Vodafone xDSL Anschlüssen !
Vodafone nutzt statt PAP eine CHAP Authentisierung auf dem PPPoE Interface (Dialer 0) ! Die Dialer 0 Konfiguration muss deshalb bei Vodafone Anschlüssen um die folgenden 4 Kommandos (fett) erweitert werden damit die PPPoE Einwahl auch bei Vodafone fehlerfrei klappt:
(PPP Standardkommandos der Übersicht halber weggelassen) :
!
interface Dialer0
description xDSL Einwahl Interface Vodafone
ip address negotiated
...
ppp authentication chap pap callin
ppp chap hostname vodafone-vdsl.komplett/vb123543
ppp chap password Geheim123
ppp pap sent-username vodafone-vdsl.komplett/vb123543 password Geheim123
...
Bei M-Net in München ist die VLAN ID z.B. 40, Netcom Kassel verwendet ebenfalls das VLAN 132 für die PPPoE Einwahl wie Vodafone, Wilhelm.Tel z.B. 2526.
Es kann also nicht schaden sich vorher über die VLAN ID des Providers zu informieren. In der Regel findet man alle diese Angaben auf deren Support Webseite.
Interessant ist die Anbindung von Swisscom VDSL Anschlüssen in der Schweiz. Die Swisscom realisiert die Anbindung ohne PPPoE und ohne VLAN Tag mit einem DHCP Client. Zusätzlich fordert die Swisscom das für alle Fremdrouter mit xDSL (VDSL / ADSL) Anschluß die DHCP Option 60 gesetzt sein muss.
Der DHCP Client muss also eine dedizierte Option 60 mit dem vorgeschriebenen Wert 100008,0001 an die Swisscom mitgeben um so eine gültige DHCP IP Adresse am WAN Port zu erhalten.
Der Cisco Router setzt die erforderliche DHCP Client Option 60 mit dem Kommando ip dhcp client class-id <string> am WAN Interface.
Dadurch das PPPoE als WAN Protokoll und damit auch das Dialer Interface hier entfällt, wird diese DHCP Option direkt auf dem virtuellen VDSL Modem Interface Ethernet0 konfiguriert, welches in diesem Setup das WAN/Internet Interface des Routers darstellt.
Diese WAN Port DHCP Konfiguration unterscheidet sich bis auf die erforderliche Class-ID (Option 60), nicht groß von einer klassischen LAN Portkonfiguration im DHCP Client Mode.
interface Ethernet0 --> Indexnummer je nach Routermodell anpassen
description Swisscom (CH)
ip dhcp client broadcast-flag clear
ip dhcp client class-id 100008,0001
ip address dhcp
no ip redirects
no ip unreachables
ip nat outside
(Die Class ID setzt sich zusammen aus dem von der Swisscom vorgeschriebenen, festen Wert 100008,0001)
Die Glasfaseranschlüsse der Swisscom erfordern im Gegensatz zu den klassischen xDSL Anschlüssen einen VLAN 10 Tag. Hier wird, wie auch schon oben, mit einem Subinterface auf dem Modem Interface gearbeitet welches dann diesen Tag an den Provider liefert.
interface Ethernet0 --> Indexnummer je nach Routermodell anpassen
no ip address
!
interface Ethernet0.10
description Swisscom (VLAN10 Tag)
encapsulation dot1Q 10
ip dhcp client broadcast-flag clear
ip dhcp client class-id 100008,0001
ip address dhcp
no ip redirects
no ip unreachables
ip nat outside
Cisco Router wie z.B. der Cisco 896 / 897 oder der 1100er u.a. besitzen onboard einen optionalen SFP Port in dem man ein GPON SFP Modul wie z.B. das Zyxel PMG3000-D20B ohne Umweg über einen Glasfaser ONT (Mietkosten) direkt am Glasfaser / FTTH Anschluss betreiben kann.
Damit der Cisco herstellerfremde SFP Optiken wie das o.a. Zyxel SFP Modul akzeptiert muss vorab global das Kommando service unsupported-transceiver konfiguriert werden! Die SFP Optik wird dann fehlerlos erkannt:
Alternativ kann die GPON SFP Optik auch über einen normalen RJ-45 Gigabit Ethernet Port mit Hilfe eines Kupfer-SFP Medien Konverters betrieben werden sofern kein SFP Slot vorhanden ist.
Kabel TV oder FTTH (Glasfaser) Anschlüsse arbeiten je nach Provider am WAN Port oftmals als DHCP Client statt PPPoE. Hier entfällt dann das PPPoE/Dialer Interface.
Entsprechend muss dann auch DHCP durch die Firewall (nur CBAC Version!!) erlaubt werden, ansonsten scheitert die IP Adressvergabe per DHCP am WAN/Internet Port !
Eine zusätzliche Regel:
access-list 111 permit udp any eq bootps any
Sorgt dann in der ACL 111 dafür das auch DHCP klappt. Eine entsprechende Ethernet Port Konfig sieht so aus: (Beispiel: Internet auf Port FastEthernet 0):
!
interface FastEthernet0
description Internet (DHCP Client)
switchport access vlan 99
no ip address
!
interface vlan 99
description Internet Interface
ip address dhcp
ip access-group 111 in <-- Firewall CBAC Inbound Access Liste
ip dhcp client broadcast-flag clear
no ip redirects
no ip unreachables
no ip proxy-arp
ip nat outside
ip inspect myfw out <-- Firewall aktiv auf Port
Die entsprechende Einstellung bei Verwendung der ZFW Firewall mit DHCP wird im ZFW Kapitel weiter unten beschrieben.
Router Modelle mit SFP Port supporten auch GPON SFPs sofern der Provider diese zulässt.
⚠️ Die Access Liste 111 am Internet Port funktioniert NUR im Zusammenhang mit der konfigurierten CBAC Router Firewall, also dem Aktivieren der FW mit dem Kommando "ip inspect myfw out" auf dem Dialer Interface !!
Sie darf nicht im Mischbetrieb mit der unten beschriebenen, moderneren ZoneBased Firewall verwendet werden. Auch nicht einzelne Zeilen!
Man muss sich also bei Konfiguration der Firewall für ein FW Konzept entscheiden. Entweder CBAC oder ZFW !
Empfohlen wird grundsätzlich nur noch ein modernes ZFW Firewall Konzept zu verwenden, da die CBAC Firewall langfristig aus IOS entfernt wird.
Betreibt man den Router gänzlich OHNE eine dieser beiden Firewall Optionen muss die Access Liste 111 vollständig weglassen werden oder man reduziert sie auf das Blocken von Ping, Traceroute und Redirect mit:
access-list 111 deny icmp any any echo <-- Weglassen wer den Router aus dem Internet pingen möchte (Sicherheit !)
access-list 111 deny icmp any any traceroute
access-list 111 deny icmp any any redirect
access-list 111 permit ip any any
Der Betrieb des Routers am Internet ohne aktive Firewall und nur mit der NAT Firewall ist möglich aber aus naheliegenden Gründen natürlich nicht ideal.
Mit der aktivierten CBAC Firewall Funktion wird die o.a. ACL 111 dynamisch, sessionbasiert bei ausgehenden Sessions geöffnet. Siehe auch:
http://www.cisco.com/en/US/products/sw/secursw/ps1018/products_tech_not ...
Ohne konfigurierte Firewall Funktion passiert diese dynamsiche Öffnung der ACL 111 nicht und Antwortpakete aus dem Internet werden dann blockiert. Die ACL 111 ist also immer an die CBAC Firewall gebunden.
Wer z.B. einen internen Web Server im lokalen LAN per Port Forwarding vom Internet aus mit aktiver CBAC Firewall erreichen will, muss den Zugriff mit einer zusätzlichen ACL 111 Regel explizit erlauben.
Für HTTP und HTTPS sind das z.B. die folgenden zusätzlichen Statements in der ACL 111:
access-list 111 permit tcp any any eq http
access-list 111 permit tcp any any eq 443
Erst dann kann man intern, im lokalen LAN, liegende eigene FTP oder HTTP Server (Web Server, NextCloud etc.) erreichen ! Einen entsprechenden statischen Eintrag für das Port Forwarding natürlich vorausgesetzt.
Das Port Forwarding mit der ZFW Firewall beschreibt ein separates Forentutorial
Von Cisco ist das entsprechende Modell C886VA und 890er Modell in einer Annex-J-Variante erhältlich C886VA-J-K9.
Besitzer der nicht J Version müssen aber keinerlei Sorge haben !
Die reguläre Annex-B-Variante Cisco C886VA-K9 ist auch voll am Annex-J-fähigen Anschluß funktionsfähig, mit geringfügig reduziertem Upstream. Ebenso die Annex A Variante.
Da die aktuellste xDSL-Modem Firmware Vectoring supportet sollte, wenn immer möglich, diese auch verwendet werden. Ältere Modem Firmware, speziell die im IOS Firmware Image embeddete Modem Firmware, quittiert dies durch den fehlenden Vectoring Support oft mit deutlich geringeren Connect Raten am DSLAM !
Die embeddete Modem Firmware z.B. der 15.4.3.M7 Version hat bessere Connect Raten als z.B. der Patch davor.
Gleiches gilt für den Cisco C896VA sowie das Cisco EHWIC-VA-DSL-B Modul (WIC) in den 1800er und 1900er Modellen.
Best Practice ist also immer die aktuelle Modem Firmware zu verwenden und separat vom Flash zu laden.
Die aktuelleste Modem Firmware (derzeit für den 886VA VA_B_38V_d24m.bin (Release B2pvC038v)) lädt man von der Cisco Support Seite und lädt sie über einen TFTP Server (z.B. HIER beschrieben mit dem Komando copy tftp flash: in den Flash Speicher des Routers.
Alternativ besteht die Möglichkeit es einfach per USB Stick über die im Router integrierte USB Buchse zu laden:
Die Modem Firmware Datei für die 880er Modelle und die des EHWIC-VA-DSL-B Modul (WIC) (1800er und 1900er Router Modell) sind vollkommen identisch und passen in allen Modellen mit dieser (Broadcom) Modem Hardware.
Dann passt man die Konfig des VDSL Controllers entsprechend an um die Firmware zu laden:
!
controller VDSL 0
firmware filename flash:VA_B_38V_d24m.bin
!
Mit dem Kommando show controllers vdsl 0 überprüft man das korrekte Laden der FW:
Modem Firmware Download über diesen Link.
Bitte zum Thema "richtige Modem Firmware" den Thread von @dog unten in den Weiterführenden Links lesen !
Die aktuelle Modem Firmware VA_A_39m_B_38u_24h.bin ist eine von der Telekom zertifizierte Firmware für VDSL Anschlüsse in D und sollte bevorzugt verwendet werden ! (Siehe Modem Firmware Release Notes).
Auch wenn der Router kein integriertes VoIP Telefonie Gateway hat (Cisco hat dafür andere Modelle) kann man ihn dennoch problemlos mit den üblichen VoIP Adaptern von Cisco, Grandstream, Gigaset GoBox-100 usw. betreiben.
Der Adapter wird einfach ins lokale LAN gehängt, die bestehenden analogen Telefone und DECT Telefone bzw. Fax dort angeschlossen und schon ist man mit den gewohnten Telefonen wieder per VoIP online und erreichbar.
Noch vorteilhafter ist natürlich eine kleine VoIP Telefon Anlage im lokalen LAN wie z.B. die Auerswald_C3000 oder C4000 die erheblich mehr VoIP Telefonkomfort inklusive Fax und Voice Mailboxen mit Mail Forward usw. und die Integration vorhandener analoger oder ISDN Telefone ermöglicht.
Oder last but not least man nimmt die all Cisco Lösung und richtet sich auch die VoIP Telefonie mit preiswerten Cisco Telefonen ein wie z.B.:HIER beschrieben.
So gut wie alle Internet Provider supporten heutzutage das IPv6 Protokoll in einem Dual Stack. Dual Stack bedeutet das klassisches IPv4 und IPv6 auf dem Router parallel koexistieren. Moderne Betriebssysteme bevorzugen allesamt den IPv6 Betrieb. Bei vielen Providern ist es sogar Standard da diese aus Mangel an IPv4 Adressen keinen IPv4 Support mehr zum Endkunden realisieren sondern nur noch IPv6 (DS-Lite mit CGN).
IPv6 hat den Vorteil das es dort kein NAT (Network Adress Translation) mehr gibt, ferner besteht keine Adressknappheit mehr wie bei IPv4.
Damit entfallen dann alle Problematiken mit Port Forwarding und auch die, die man in CGN Netzen (Provider NAT) mit DS-lite kennt. Jeder bekommt automatisch vom Provider sein eigenes bzw. mehrere öffentliche IPv6 Netzwerke zugeteilt. Dadurch ist mit IPv6 immer eine direkte Verbindung aus dem Internet möglich.
Umso mehr ist deshalb natürlich die Firewall Funktion für IPv6 gefordert !
Wo vorher ein Großteil der Netzwerk Sicherheit bequem auf die NAT Funktion abgewälzt wurde, entfällt das nun bei IPv6 komplett und die Firewall muss allein für die Zugangssicherheit des lokalen IPv6 Netzes sorgen. Sie ist also ein sehr wichtiger und zentraler Punkt der IPv6 Konfiguration bzw. Sicherheit !
Genau aus diesem Grund sollte das moderne, Zonen basierte ZFW Firewall Konzept verwendet werden. Alles was dort für IPv4 eingestellt ist gilt automatisch immer auch für IPv6 !
Daher die gute Nachricht: An der Firewall muss für IPv6 nichts mehr extra eingestellt werden!
Die folgenden IPv6 Kommandos werden einfach der bestehenden globalen oder Interface spezifischen Konfiguration des Dialer0 bzw. WAN Interfaces (Internet) und VLAN1 (lokales LAN) Interfaces hinzugefügt.
Es lohnt sich für IPv6 gerüstet zu sein! Los gehts...
Zuerst wird global IPv6 Routing aktiviert auf dem Router und der lokale DHCPv6 Server aktiviert der die per Prefix Delegation vom Provider vergebenen IPv6 Adressen an die Endgeräte im lokalen LAN verteilt:
!
ipv6 unicast-routing
ipv6 cef
ipv6 dhcp pool DHCPv6
import dns-server
domain-name meinedomain.internal
(sntp address 2003:2:2:140:194:25:134:196) Optional: NTP Server ntp1.t-online.de
(prefix-delegation pool v6pdpool) Optional !!: Nur wer Prefixes an lokale v6 Router o. Firewall weiterreichen will. Sonst weglassen !!
Weiter geht es mit der Interface Konfiguration vom Internet Interface und vom lokalen LAN Interface:
!
interface Dialer0
description xDSL PPPoE Interface Internet
ipv6 address autoconfig default
ipv6 enable
no ipv6 redirects
no ipv6 unreachables
ipv6 nd autoconfig default-route
ipv6 nd ra suppress
ipv6 verify unicast reverse-path
ipv6 dhcp client pd provider-v6-prefix (rapid-commit)
Sollte der Provider mit DHCPv6 keine two-message exchange Option supporten, lässt man hier den Parameter "rapid-commit" weg!
!
interface Vlan1
description Lokales LAN (FastEthernet0 bis 2)
ipv6 address provider-v6-prefix ::1:0:0:0:1/64 (Hier /64 Maske nach Provider Prefix Vorgabe ggf. anpassen. Beispiel /56 PD Telekom)
ipv6 enable
ipv6 nd other-config-flag
ipv6 nd router-preference High
ipv6 dhcp server DHCPv6 rapid-commit allow-hint
(ipv6 address FE80:BADE:AFFE:CAFE::1 link-local) --> Optional: Nur wer eigene v6 Link Local Adressen FE80:: vergeben möchte !
⚠️ Je nachdem welches Firewall Konzept benutzt wird muss am WAN Port eingehend UDP 546 (DHCPv6 Protokoll) erlaubt sein. DHCPv6 muss die Firewall eingehend passieren können damit die IPv6 Prefix Delegation am WAN/Internet Interface sauber funktioniert!
Das Kapitel "Zone Based Firewall" weiter unten im Tutorial beschreibt das richtige IPv6 Setup dafür !
Wer möchte kann natürlich auch noch das VLAN 2 (Gastnetz) mit IPv6 ausstatten:
!
interface Vlan2
description Gastnetz (FastEthernet3)
ipv6 address provider-v6-prefix ::2:0:0:0:1/64
ipv6 enable
ipv6 nd router-preference High
ipv6 nd ra dns server 2003:180:2:3000::53
ipv6 nd ra dns server 2003:180:2:4000::53
(ipv6 address FE80:BAD:BEEF:CAFE::2 link-local) --> Optional: Nur wenn eigene Link Local Adresse gewünscht. Sonst weglassen. ##
👉🏽 Das Gast Interface zeigt hier eine vereinfachte Variante wie die DNS Server (hier Telekom) über IPv6 Router Advertisements (RA) an die Clients gesendet werden. Für einfache IPv6 Segmente ist dies völlig ausreichend. DHCPv6 ist lediglich erforderlich wenn intern per PD weitere v6 Netze an andere interne Router oder Firewalls weitergeben werden sollen. (Siehe zu der Thematik auch hier und Folgekapitel)
Mit show ipv6 interface kann man dann überprüfen ob es geklappt hat und der Router eine IPv6 Adresse bekommen hat:
cisco_router#show ipv6 interface
Dialer0 is up, line protocol is up
IPv6 is enabled, link-local address is FE80::CAFE:BADE:AFFE:123
No Virtual link-local address(es):
Description: xDSL Einwahl Interface Internet
Stateless address autoconfig enabled
Global unicast address(es):
2010:34:17BDF:2C5B:EAD6:F7FD:EF28:1F70, subnet is 2010:34:17BDF:2C5B::/64 [EUI/CAL/PRE]
valid lifetime 14259 preferred lifetime 1659
Joined group address(es):
Die korrekte v6 Prefix Delegation überprüft man mit show ipv6 dhcp int dialer0
Entsprechend klappt dann auch ein IPv6 Ping vom Router selber:
cisco_router#ping ipv6 www.heise.de
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2A02:2E0:3FE:1001:7777:772E:2:85, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 12/12/16 ms
Und dann natürlich auch vom lokalen Netzwerk auf einen IPv6 Server im Internet:
Damit ist die IPv6 Konfig abgeschlossen.
Ggf. muss man das Dialer Interface einmal auf shut und danach wieder no shut setzen um eine neue PPPoE Negotiation und damit die Vergabe der IPv6 Adresse auszulösen. Ein einfacher Reboot des Routers nach vorheriger Sicherung der Konfig mit write mem tut es auch.
Das zusätzliche Kommando ist optional und nur dann erforderlich, wenn Prefixes im lokalen LAN per DHCPv6 weitergreicht werden sollen an weitere IPv6 Router. Der Beispiel Prefix hier ist nur ein Beispiel und muss auf den eigenen angepasst werden!
ipv6 local pool v6pdpool 2003:BB:123:7B3A::/56 60
Dieses Kommando vergibt einen /60er Prefix aus dem vom Provider erhaltenen /56er Prefix per eigener Delegation weiter.
Der Cisco 886va ist auch in einer WLAN Version erhältlich als Cisco886vaw. Unterschied zum 886va ist lediglich nur ein integrierter 2,4Ghz WLAN Access Point wie man es von gewöhnlichen Consumer xDSL Routern auch kennt. Die 890er Modelle haben einen Dual Radio AP mit 2,4 und 5 Ghz. Die o.a. Grundkonfiguration bleibt immer identisch bzw. gilt auch für andere Router Modelle.
Der integrierte WLAN Accesspoint ist dabei, WLAN-Router üblich, mit einer Bridge an ein virtuelles Gigabit Interface angehängt, was man je nach Bedarf mit einer Single SSID oder mit Multi SSIDs in ein oder mehrere LAN oder VLAN Segmente per Konfig hängen kann.
Damit ist auch dieser Router in der Lage mit einem einzigen physischen WLAN Accesspoint mehrere unabhängige virtuelle WLANs aufzuspannen die man in unterschiedliche Netz Segmente legen kann. (z.B. Gast- und Privat oder Firmen WLAN)
Somit sind kostengünstig 2 und mehrere WLANs mit einer Hardware zu realisieren z.B. in einem Firmenumfeld mit einem gesicherten Mitarbeiter WLAN und einem abgeschotteten Gäste WLAN mit Hotspot.
Der in_diesem_Tutorial beschrieben ist und entspricht damit der klassischen Standard Cisco IOS Konfiguration auf allen High End Accesspoints der Aironet Serie die es mittlerweile ebenfalls recht preiswert über Auktionsplattformen gibt.
Natürlich hat der AP auch ein entsprechendes grafisches Web Interface welches die WLAN Konfiguration erheblich erleichtert für Admins die nicht IOS affin sind. Allerdings ist dieses WebGUI erst erreichbar mit einer entsprechenden IP Konfiguration des WLAN AccessPoint Interfaces.
Als ersten Schritt gibt man dem WLAN AP Interface eine IP. Da diese in der Regel im lokalen LAN (VLAN1) liegt kann dies unnumbered erfolgen.
interface Vlan1
description Lokales LAN
ip address 192.168.100.254 255.255.255.0
ip nat inside
ip tcp adjust-mss 1448
!
interface wlan-ap0
description Management Interface des internen WLAN APs
ip unnumbered Vlan1
!
Alternativ mit einer statischen IP außerhalb des DHCP LAN Adresspools:
interface wlan-ap0
description Management Interface des internen WLAN APs
ip address 192.168.100.253 255.255.255.0
!
Jetzt kann man mit dem Kommando service-module wlan-ap 0 session sich auf den internen Accesspoint verbinden.
Da das Kommando recht kryptisch ist und sich das keiner lange merken kann, kann man einen Kommando Alias dafür anlegen mit
alias exec zumwlanap service-module wlan-ap 0 session
Nun reicht die Eingabe des Kommandos zumwlanap um auf das WLAN AP Kommandointerface zu gelangen:
Damit ist man nun auf dem Konfigurationsinterface des internen Accesspoints !
Der Default Username ist cisco mit dem Default Password cisco bzw. Cisco (großes "C")!
⚠️ Mit der Eingabe von ctrl ^ und x (oder ctrl, shift 6 und x) und dann der Eingabe von disconnect
kommt man immer wieder auf den Router Kommando Prompt zurück.
Mit der nun folgenden IP Adressierung des internen APs ist diese Prozedur aber dann zukünftig nicht mehr nötig. Dann ist der interne Accesspoint bequem aus dem lokalen LAN direkt zu erreichen per Telnet (PuTTY oder TeraTerm) oder per Web Browser.
Eine funktionsfähige, einfache WLAN Konfiguration mit WPA-2 Sicherung und WLAN SSID (Name) Bitschleuder lautet folgendermaßen:
!
service timestamps log datetime localtime show-timezone year
service timestamps debug datetime localtime
!
hostname ap
!
aaa new-model
clock timezone CET 1 0
clock summer-time CEST recurring last Sun Mar 2:00 last Sun Oct 3:00
ip domain name meinedomain.internal
!
dot11 syslog
!
dot11 ssid Bitschleuder
authentication open
authentication key-management wpa
guest-mode
wpa-psk ascii 0 Geheim123
!
bridge irb
!
!
interface Dot11Radio0
no ip address
no ip route-cache
!
encryption mode ciphers aes-ccm
!
ssid Bitschleuder
!
station-role root
no dot11 extension aironet
bridge-group 1
bridge-group 1 subscriber-loop-control
bridge-group 1 block-unknown-source
no bridge-group 1 source-learning
no bridge-group 1 unicast-flooding
bridge-group 1 spanning-disabled
!
interface GigabitEthernet0
description the embedded AP GigabitEthernet 0 is an internal interface connecting AP with the host router
no ip address
no ip route-cache
bridge-group 1
no bridge-group 1 source-learning
bridge-group 1 spanning-disabled
!
interface BVI1
ip address 192.168.100.1 255.255.255.0
no ip route-cache
!
ip http server
no ip http secure-server
bridge 1 route ip
!
line con 0
privilege level 15
login local
line vty 0 4
login local
!
end
⚠️ Die interne IP Adresse des Accesspoints 192.168.100.1 muss immer außerhalb des DHCP Adresspools liegen damit es nicht zu IP Adresskonflikten kommt !
Im hiesigen Beispiel ist der DHCP Pool mit den IP Adressen von .100.150 bis .100.170 definiert und der Router selber hat die .100.254 so das wir mit der .100.1 im sicheren IP Bereich liegen !
Die Parameter dot11 ssid Bitschleuder und auch wpa-psk ascii 0 Geheim123 bestimmen den Namen des WLANs (SSID) und das Zugangspasswort. Das muss entsprechend auf die eigenen Einstellungen angepasst werden !
Startet man nun einen Webbrowser im lokalen LAN und gibt dort als Ziel ein http://192.168.100.1 landet man direkt auf dem Web Interface des internen Accesspoints und kann diesen nun auch ganz bequem per Web konfigurieren und diese Konfig Anpassungen vornehmen. (Siehe Screenshot)
Der direkte CLI Zugriff auf den AP mit seiner IP ist ebenfalls mit Telnet oder SSH so möglich.
Weitere, detailierte WLAN Konfigurationen wie MSSID, 802.1x Radius, dyn. VLANs usw. erläutert das hiesige Cisco Accesspoint Tutorial.
Um die Sicherheit zu erhöhen, ist es immer vorteilhaft das eigene Netzwerk in mehrere Netzwerksegmente zu teilen.
Zum Beispiel 2 getrennte Firmennetze an einem Router zu betreiben oder das Heimnetz in Gastnetz und Hausautomation zu segmentieren.
Der Cisco Router hat vollen 802.1q VLAN Support mit an Bord so das diese VLAN Segmentierung einfach umzusetzen ist.
An dieser Stelle sei auf das hiesige_VLAN-Tutorial verwiesen, welches zusätzlich VLAN Konfigurationen für Switches und die Kombination mit Routern u. Firewall im Detail behandelt.
Als Konfig Beispiel dient hier ein einfaches Hausnetz mit Segmentierung in privates LAN, Hausautomation und ein Gäste Netz. Letzteres wurde oben schon in der Grundkonfiguration als VLAN 2 realisiert, ist der Vollständigkeit halber hier nochmals aufgeführt.
So sähe dieses einfache Design aus:
Als ersten Konfigurations Schritt legt man die beiden zusätzlichen VLANs an:
vlan 2
name Gastnetz
vlan 3
name Hausautomation
Damit erzeugt man automatisch auch 2 neue (virtuelle) Router IP Interfaces denen man entsprechende IP Adressen zuordnet:
interface Vlan2
description Gastnetz
ip address 172.16.100.254 255.255.255.0
ip nat inside
!
interface Vlan3
description Hausautomation
ip address 10.3.3.254 255.255.255.0
(ip nat inside) <-- (Optional: Wenn hier kein Internet Zugang gewollt ist, dann weglassen !)
!
Die VLAN Zugangssteuerung erledigt dann die Firewall oder ersatzweise eine ACL.
Sind die 3 VLAN Netze 1 (Privat), 2 (Gäste) und 3 (Hausautomation) auf dem Router eingerichtet gilt es diese Netze auf einen angeschlossenen VLAN Switch zu bringen. Das passiert, wie bei VLANs generell üblich, mittels eines VLAN getaggten Uplinks, den man auf das Router LAN Interface (Beispiel hier: Port 3) legt.
!
interface GigabitEthernet3
description Tagged Uplink auf VLAN Switch
switchport mode trunk
switchport trunk allowed vlan all
no ip address
!
Hat man die entsprechenden VLANs 1, 2 und 3 auch auf der Switchseite eingerichtet und auch dort den Switch Uplink Port zum Cisco Router tagged für alle VLANs (außer 1, denn das ist das UNtagged PVID VLAN!) entsprechend konfiguriert, kann man jetzt aus jedem VLAN das dazu korrespondierende Cisco IP Interface anpingen und so die Erreichbarkeit prüfen.
Ein show vlan-switch zeigt eine Übersicht über die erstellten VLAN‘s und den zugewiesenen Ports.
(Für Details zur Switchkonfiguration sei hier nochmals auf das bereits oben genannte VLAN-Tutorial verwiesen !)
Dynamisches DNS ist erforderlich für Benutzer die den Router bei wechselnden Provider xDSL IP Adressen unter einer festen Hostadresse von außen erreichen wollen oder müssen. Häufig ist das z.B. für den gesicherten VPN Zugang mobiler Clients aufs lokale Netzwerk oder für schlichtes Port Forwarding auf lokale Server (Mail, Exchange, NexctCloud usw.) zwingend erforderlich.
Für die dynamische Anpassung der IP Adresse bei wechselnden Provider xDSL Adressen (nächtliche Zwangstrennung) sollte man deshalb immer einen DynDNS Dienst einrichten. Damit kann der Router immer mit einem festen Hostnamen wie z.B. meinrouter.dnshome.de erreicht werden, egal welche Provider IP er aktuell hat.
Derzeit noch kostenfreie Anbieter wie dnsHome oder deSEC sowie diverse andere lokale DDNS Dienstleister bieten sich da an.
Der DynDNS Dienst wird wie folgt auf dem Cisco Routern aktiviert: (Update method "http" und "add url")
(Wenn ein "?" Bestandteil der DDNS URL ist und per CLI eingetragen werden soll, muß zuvor die Taste „STRG“ und „V“ zusammen gedrückt werden. Dann kann mit „Shift“ und ? das Fragezeichen in die CLI eingetragen werden, ohne das die sonst per "?" übliche Cisco CLI Hilfefunktion startet !)
!
ip ddns update method dnsHome
http
add
http://<Subdomain:password>@www.dnshome.de/nic/update?Subdomain=<h>&myip=<a>
interval maximum 1 0 0 0
!
interface Dialer0
ip ddns update hostname <hostname>.<dyndns.domain>
ip ddns update dnsHome
!
(Es sind nur die zur obigen Grundkonfiguration zusätzlichen Kommandos hier aufgeführt.)
Kostenfreie DynDNS Accounts gibt es z.B. bei deSEC und dnsHome die DSGVO konforme Server betreiben und kein kommerzielles Interesse haben. Hier reicht als Minimum eine einfache Subdomain.
Falls es hier dennoch einmal kneifen sollte, hilft immer ein debug ip ddns update um den DDNS Update Prozess zu überwachen und zu troubleshooten. ACHTUNG: Benutzt man eine Verbindung über Telnet oder SSH zum Router, muss vorher term mon eingegeben werden, damit man die Debug Meldungen im Telnet oder SSH Fenster sieht !
Abgesehen davon wird einem auch über das Kontaktformular der o.a. DynDNS Dienstleister geholfen.
Port Forwarding (Weiterleitung) nutzt man z.B. um einen lokalen Webserver, Cloudserver oder Kameras usw. öffentlich von extern (Internet) erreichbar zu machen. Mit Port Weiterleitung können Zugriffe von extern die lokale NAT Firewall überwinden.
Hier sollte man immer große Vorsicht walten lassen, denn man öffnet so das Internet ungeschützt auf lokale Resourcen! Wer also einen privaten NextCloud Server für die Familie oder ein öffentlich erreichbares NAS betreibt, sollte das tunlichst immer in einem geschützten und vom privaten IP Netz getrennten Segment (DMZ) machen !
Es sei an dieser Stelle noch einmal darauf hingewiesen, daß man solche von extern errreichbare Endgeräte nicht ins lokale, private LAN setzen sollte sondern besser ein separates DMZ VLAN dafür anlegt im Cisco. Dies trennt man mit einer Accessliste vom lokalen LAN ab um das private LAN abzusichern und so zu schützen.
Der Grund liegt auf der Hand, denn für den Zugriff muss ein Loch in die Router Firewall gebohrt werden und da ist es immer besser dies auf einem separaten DMZ IP Segment zu machen um das lokale LAN zu schützen.
Ist der Server ein lokaler, privater Server den man von außen erreichen möchte, sollte man generell aus Sicherheitsgründen vom Port Forwarding zumindestens unsicherer Ports absehen ! Ein VPN ist in dem Falle immer der bessere Weg.
Auch hier ist der Grund klar, denn diese Daten gehen immer ungeschützt, für jederman einsehbar über das öffentliche Internet. (Ungeschützte Kameras im Internet sind ein trauriges Beispiel dafür)
Ein VPN sollte für jeden der Wert auf seine Datensicherheit und Schutz legt hier oberste Priorität haben!
Wie man ein sicheres VPN mit diesem Router einrichtet erklärt das Tutorial im weiteren Verlauf oder die weiterführenden Links am Ende.
Nicht immer ist VPN sinnvoll, z.B. bei einem erreichbaren privaten Nextcloud Server. Hier ist Port Forwarding dann das Mittel der Wahl.
Das Beispiel hier zeigt eine sichere DMZ Variante mit Port Weiterleitung:
Zum Port Forwarding soll ein lokaler Webserver (Port TCP 80 und 443 = HTTP) wie z.B. NextCloud vom Internet aus erreichbar sein im neuen VLAN 3. (Standardkonfig von oben verkürzt wiedergegeben !)
interface Vlan3
description DMZ mit Webserver
ip address 172.16.200.1 255.255.255.0
ip nat inside
!
interface Dialer0
description xDSL Internet Interface
ip address negotiated
ip access-group 111 in
...
!
ip nat inside source list 101 interface Dialer0 overload
ip nat inside source static tcp 172.16.200.151 80 interface Dialer0 80
ip nat inside source static tcp 172.16.200.151 443 interface Dialer0 443
!
Nicht vergessen: Wer die CBAC oder ZFW Firewall betreibt muss am Internet Port die Accessliste anpassen die Traffic auf den Router passieren lässt!
access-list 111 permit tcp any any eq 80
access-list 111 permit tcp any any eq 443
Spricht man jetzt mit dem Web Browser von "außen" die WAN IP Adresse (Dialer0 IP) des Routers an, landet man auf dem lokalen Webserver in der DMZ der die lokale IP 172.16.200.151 hat.
Eine Port Verschleierung bzw. Port Translation erreicht man z.B. Mit dem Kommando:
ip nat inside source static tcp 172.16.200.151 80 interface Dialer0 50443
Um hier jetzt den lokalen Webserver zu erreichen gibt man im Browser http://<router_Internet_adresse>:50443 an.
Die Port Forwarding Konfiguration im Zusammenspiel mit der ZFW Firewall beschreibt ein separates Tutorial im Detail.
⚠️ Bei Windows 21H2 unbedingt Patch HIER !)
Eine gesicherte Client VPN Verbindung dient dazu sicher und geschützt von extern auf Daten im lokalen LAN zugreifen zu können z.B. für Home Office Nutzer, Außendienst, remotes Management, u.a.
Als Client VPN kommt hier das bekannte L2TP Protokoll zum Einsatz (L2TP / IPsec mit vorinstalliertem Schlüssel).
L2TP VPN Clients sind generell in den Betriebssystemen aller oben genannten Endgeräte seit langem enthalten, sprich der im jeweiligen Betriebssystem immer vorhandene, bordeigene VPN Client.
Diesen zu nutzen hat den großen Vorteil das er das Installieren und Management von externer VPN Client Software fremder Hersteller erspart. Prinzipbedingt, bieten diese bordeigenen VPN Clients damit die beste und performanteste VPN Anbindung an das jeweilige Endgerät. Sie werden zudem über AD Directories und GPOs umfassend supportet, so das auch zentrales VPN Clientmanagement sehr leicht fällt.
Das zusätzliche Loopback Interface des Routers dient dazu den L2TP VPN Server ausfallstabil und in einer separaten IP Range zu betreiben. Würde man ihn an das lokale LAN Interface binden, bestünde die Gefahr bei einem LAN Link Verlust das damit auch das VPN nicht mehr funktioniert, was immer zu vermeiden ist.
Ein Loopback Interface kann technisch bedingt niemals einen Link Verlust erleiden bzw. ausfallen solange der Router mit Strom versorgt wird. Das sichert die VPN Erreichbarkeit von außen auch bei einer lokalen LAN Fehlfunktion.
(Die VPN Konfiguration der ZFW Firewall für den IPsec VPN Zugang wird unten im Kapitel zur Zone Based Firewall beschrieben !)
Die folgenden Kommandos sind der Cisco Router Konfig hinzuzufügen
!
aaa new-model
aaa authentication ppp L2TP_AUTH local
!
vpdn enable
!
vpdn-group L2TP
accept-dialin
protocol l2tp
virtual-template 1
no l2tp tunnel authentication
!
username vpnuser password geheim123 => (L2TP Benutzername u. Passwort)
!
crypto keyring vpn_keys
pre-shared-key address 0.0.0.0 key Geheim => (vorinstallierten Schlüssel ändern !)
!
crypto isakmp policy 1
encr aes 256
authentication pre-share
group 14
!
crypto isakmp policy 2
encr aes 256
authentication pre-share
group 2
!
crypto isakmp keepalive 10
!
crypto isakmp profile dynip
description VPNs mit dyn. IP Adresse
keyring vpn_keys
match identity address 0.0.0.0
!
crypto ipsec transform-set L2TP-1 esp-aes 256 esp-sha-hmac => (⚠️Wichtig hier: Transport Mode!)
mode transport
crypto ipsec transform-set L2TP-2 esp-aes esp-sha-hmac
mode transport
!
crypto dynamic-map dynmap 10
set nat demux
set transform-set L2TP-1 L2TP-2
set isakmp-profile dynip
!
crypto map vpn_cisco 10 ipsec-isakmp dynamic dynmap
!
interface Loopback1
description Looback L2TP Pool
ip address 192.168.101.1 255.255.255.255
!
interface Virtual-Template1
description L2TP Dialin
ip unnumbered Loopback1
ip nat inside
peer default ip address pool l2tp-pool
ppp authentication ms-chap-v2 L2TP_AUTH
!
ip local pool l2tp-pool 192.168.101.100 192.168.101.150
!
interface <WAN/Internet_Interface>
description Internet Port
ip address xyz
ip nat outside
crypto map vpn_cisco => (VPN ans WAN Internet Interface binden !)
! ...
⚠️ Die folgende ACL ist nur dann erforderlich wenn ein CBAC Firewall Konzept genutzt wird!!
Bei Nutzung der moderneren Zone based Firewall (siehe Folgekapitel) entfällt diese ACL und wird durch die "ALLOWv4" Accessliste im ZFW Firewall Setup ersetzt!!
access-list 111 permit udp any any eq 1701 --> L2TP darf die CBAC Firewall passieren (Zeile in ACL 111 hinzufügen)
access-list 111 permit udp any any eq 500 --> IPsec darf die CBAC Firewall passieren (Zeile in ACL 111 hinzufügen)
access-list 111 permit udp any any eq non500-isakmp
access-list 111 permit esp any any
Die einfache Einrichtung der VPN onboard Clients in den jeweiligen Betriebssystemen ist dann analog vorzunehmen wie bei anderen L2TP VPN Firewalls und Routern auch und wird hier der Übersicht halber nicht extra beschrieben.
Beispiele und detailierte Screenshots zum L2TP VPN Client Setup für die betriebssystemeigenen Clients unter Microsoft, Apple, Linux Android usw. findet man in den weiteren L2TP VPN Tutorials des Forums HIER und auch HIER.
Apple hat von Haus aus einen Cisco VPN Client in alle Apple Betriebssysteme wie Mac OS und iOS integriert.
In einem reinen Apple Client VPN Umfeld bietet sich dann als Alternative zum obigen L2TP auch die Option den Apple bordeigenen Cisco VPN Client in einer alternativen Konfig mit nativem IPsec zu nutzen.
(Achtung: Ein Mix mit L2TP ist nicht zu empfehlen ! Wer ein gemischtes VPN Client Umfeld hat, sollte in dem Falle immer ausschliesslich das obige L2TP VPN Protokoll nutzen !)
!
aaa new-model
aaa authentication login clientauth local
aaa authorization network groupauth local
!
username vpnuser1 privilege 0 algorithm-type scrypt secret Geheim123
username vpnuser2 privilege 0 algorithm-type scrypt secret Geheim321
username vpngroup privilege 0 algorithm-type scrypt secret test123
!
crypto isakmp policy 10
encr aes 256
authentication pre-share
group 14
!
crypto isakmp policy 15
encr aes 256
authentication pre-share
group 2
!
crypto isakmp client configuration group vpngroup
key test123
dns 192.168.100.254 # => (oder, wenn vorhanden, lokale DNS Server IP)
domain vpn.test.intern
acl 107 => (Split VPN ACL, kann entfallen wenn gesamter VPN Traffic in den Tunnel soll)
save-password
max-users 10 => (Je nach Router Performance und Bandbreite einstellen)
banner # Willkommen im VPN von XYZ # (Optional !)
pool vpnpool
!
crypto isakmp profile VPNclient
description VPN Client Profil
match identity group vpngroup
client authentication list clientauth
isakmp authorization list groupauth
client configuration address respond
virtual-template 2
!
crypto ipsec transform-set myset esp-aes esp-sha-hmac
mode tunnel
!
crypto ipsec profile vpn-vti2
set transform-set myset
set isakmp-profile VPNclient
!
interface Virtual-Template2 type tunnel
description IPsec VPN Dialin
ip unnumbered Vlan1
ip nat inside
ip virtual-reassembly in
tunnel mode ipsec ipv4
tunnel path-mtu-discovery
tunnel protection ipsec profile vpn-vti2
!
interface Vlan1
ip address 192.168.100.254 255.255.255.0
!
ip local pool vpnpool 192.168.100.240 192.168.100.250 (Anpassen auf eigenen Client IP Bereich im lokalen LAN außerhalb d. DHCP Range !)
!
end
⚠️ Auch hier ist die Erweiterung der ACL 111 nur dann erforderlich wenn ein CBAC Firewall Konzept genutzt wird!!
Bei Nutzung der moderneren Zone based Firewall (siehe Folgekapitel) entfällt diese ACL und wird durch die "ALLOWv4" Accessliste im ZFW Firewall Setup ersetzt!!
...
access-list 111 permit udp any any eq 1701
access-list 111 permit udp any any eq isakmp
access-list 111 permit udp host any any eq non500-isakmp
access-list 111 permit esp any any
...
Die ACL 107 (nur CBAC Setup, nicht erforderlich bei ZFW!!) die den VPN Traffic für das lokale Netz klassifiziert, wird erweitert :
access-list 107 permit ip 192.168.100.0 0.0.0.255 any --> (Split VPN)
Wichtig: Diese ACL 107 kann entfallen wenn der gesamte Client Traffic in den VPN Tunnel soll. (Gateway Redirect)
Konfig des iPhone / iPad IPsec Clients...:
(Als Ziel IP Adresse die WAN (Dailer) Port IP Adresse oder eigene dynamische DNS Adresse eintragen !)
Screenshot des Mac OS-X onboard IPsec Clients:
Sollte es mit dem VPN Zugriff einmal klemmen, dann kann man sich mit folgenden Befehlen auf Fehlersuche machen:
debug crypto isakmp und debug crypto ipsec. Mit show crypto ipsec sa und show crypto engine connection active werden noch weitere Info’s angezeigt.
Mit Hilfe des Befehls show crypto isakmp sa kann man unter anderem sehen wieviele Pakete verschlüsselt (decrypted) und entschlüsselt (encrypted) wurden.
Der Befehl show crypto tech support zeigt zusätzlich einen kompletten Überblick über fast alle crypto Einstellungen.
⚠️ (Die Konfiguration der ZFW Firewall für die IPsec VPN Standort Kopplung wird unten im Kapitel zur Zone Based Firewall beschrieben !)
Eine Standort VPN LAN to LAN Kopplung zweier oder mehrerer Standorte mit IPsec Verschlüsselung, sei es mit Cisco oder zu anderen VPN Routern, lässt sich ebenso bequem erledigen um z.B. gemeinsame Resourcen wie Server, NAS etc. standortübergreifend zu nutzen.
IPsec ist ein weltweiter Standard so das auch VPN Tunnel zu anderen IPsec Routern oder Firewalls supportet ist. Weitere Cisco Praxiskonfigurationen dazu findet man unten in den weiterführenden Links dieses Tutorials.
Für die VPN Kopplung 2er Cisco Router mit festen WAN IP Adressen sind die folgenden Konfigurationsschritte auf beiden Seiten des VPN Tunnels erforderlich, die man der obigen Standardkonfiguration hinzufügt:
!
crypto keyring VPN_PSK
pre-shared-key address <feste_ip_peer> key GeheiM123 => (Preshared Key)
!
crypto isakmp policy 10
encryption aes 256
authentication pre-share
group 2
!
crypto isakmp keepalive 10
!
crypto isakmp profile Standort-B
description IPsec VPN Standort-B
keyring VPN_PSK
match identity address <feste_ip_standort-B>
!
crypto ipsec transform-set vpn-s2s esp-aes esp-sha-hmac
!
crypto ipsec profile Standort-B
set transform-set vpn-s2s
set isakmp-profile Standort-B
!
interface Tunnel1
description VPN Tunnel Standort-B
ip unnumbered Vlan1
ip verify unicast reverse-path
tunnel source <feste_ip_standort-A>
tunnel mode ipsec ipv4
tunnel destination <feste_ip_standort-B>
tunnel path-mtu-discovery
tunnel protection ipsec profile Standort-B
!
!
access-list 101 deny ip 192.168.100.0 0.0.0.255 192.168.200.0 0.0.0.255 --> Kein NAT für den VPN Tunnel !
access-list 101 permit ip 192.168.100.0 0.0.0.255 any --> ...aber NAT ins Internet
!
ip route 192.168.200.0 255.255.255.0 Tunnel1 --> Route ins remote LAN Standort B
...
access-list 111 permit udp any any eq 1701
access-list 111 permit udp any any eq 500
access-list 111 permit udp any any eq non500-isakmp
access-list 111 permit esp any any
!
(Die ACL 111 entfällt bzw. ändert sich wenn ein ZFW Firewall Konzept verwendet wird ! Alle Details im Kapitel "ZFW Firewall")
Die gleichen Konfigurationsschritte sind auf der gegenüberliegenden Standortseite, angepasst an die dortigen IP Adressen, auszuführen.
Das Beispiel oben geht davon aus das sich ein lokales LAN mit der IP Adresse 192.168.200. /24 dort befindet.
Diese IP Adressen sind entsprechend auch eigenen Belangen anzupassen. Ebenso natürlich das Platzhalter Passwort "test123" für die IPsec Verschlüsselung.
Der Parameter <remote_WAN_IP> muss in der Konfig durch die xDSL IP oder den Hostnamen / DynDNS ersetzt werden.
Ebenfalls kann man am obigen Beispiel sehen, daß das NAT etwas angepasst werden muss, denn IP Packete die lokal beide Netze über den IPsec Tunnel verbinden, dürfen natürlich nicht über den NAT (Adress Translation) Prozess laufen (ACL 101 nimmt diesen Traffic aus).
Die genauen VPN Konfigs für die Praxis liefert dieses Foren VPN Tutorial
Befindet sich am remoten Standort ein IPsec VPN Router oder Firewall (FritzBox, Draytek, Mikrotik, Lancom, pfSense/OPNsense o.ä. hier mit lokalem Beispiel LAN 192.168.222.0 /24) der keine feste Internet IP hat, also eine wechselnde Provider IP, muss zusätzlich eine dynamische Crypto Map angelegt werden. Das gilt auch für solche Standorte mit einem DS-Lite Anschluss und CGNAT.
Dazu ist die Konfig wie folgt zu ergänzen:
!
crypto keyring vpn_keys
pre-shared-key address 0.0.0.0 key GeheiM123 => (Preshared Key)
!
crypto isakmp policy 10
encryption aes 256
authentication pre-share
group 2
!
crypto isakmp keepalive 10
!
crypto isakmp profile dynip
description VPNs mit dynam. IP
keyring vpn_keys
match identity address 0.0.0.0
!
crypto dynamic-map dynmap 10
description Tunnel dyn.IP Standort-B
set isakmp-profile dynip
set transform-set vpn
match address 107
!
crypto ipsec transform-set vpn esp-aes esp-sha-hmac
!
crypto map vpn_cisco 10 ipsec-isakmp dynamic dynmap
!
interface <Internet_Int>
description Internet Port
ip address xyz
ip nat outside
crypto map vpn_cisco => (VPN ans Internet Interface binden !)
!
Damit können remote IPsec VPN Router/Firewalls (z.B. FritzBox u.a.) auch mit wechselnden, dynamischen Provider IPs problemlos eine VPN Verbindung auf den Cisco Router herstellen.
Sind beide oder alle Standorte ohne feste IP konfiguriert, dann muss man wenigstens auf einem (zentralen) VPN Router mit DynDNS gem. der o.a. Konfig im Kapitel Dynamisches DNS arbeiten.
Die klassische, oben beschriebene, rein Interface bezogene Cisco stateful Inspection Firewall, auch als Context-Based Access Control, oder CBAC bekannt, wurde mit dem IOS Release 12.4.9T mit der verbesserten und flexibleren Zonen basierten Firewall (ZFW) ersetzt. Sie wird die alte CBAC Firewall auf Sicht vollständig im IOS ersetzen.
Beide Versionen koexistieren zur Zeit und man hat (noch) die Wahl welche Art der Firewall man nutzen möchte.
Es macht also Sinn bei einer Neuinstallation die Firewall Konfig ggf. gleich mit der moderneren und flexibleren ZFW Konfiguration zu realisieren. Zumal die ZFW Syntax auch weitgehend der der ASA Router entspricht.
Die ZFW Firewall bietet zudem eine Deep Packet Inspection bis auf URL und Content Basis (ALG) und hat verbesserte Reporting Mechanismen gegen DoS Attacken. Zusätzlich ermöglicht sie durch die Zonen Struktur eine deutlich bessere und erhöhte Sicherheit als anfällige, Interface basierte Access Listen wie in der alten CBAC Struktur.
Die Zonen basierte Konfig unterscheidet sich erwartungsgemäß erheblich von der klassischen CBAC Firewall Konfiguration mit ihren ip inspect Kommandos. Diese und die CBAC Accesslisten entfallen vollständig bei der moderneren ZFW Konfiguration ! In der o.a. Konfig Vorgabe wird darauf mehrfach hingewiesen und sollte unbedingt beachtet werden.
Ein Mischen der neuen ZFW Firewall mit dem alten CBAC Modell ist immer zu vermeiden und nur ein Firewall Konzept zu verwenden.
Also entweder rein CBAC oder rein das modernere ZFW Firewall Modell zu nutzen. Kein Mischbetrieb !
Die ZFW Grundregeln sind einfach:
Gäste sollen hier im Beispiel nur mit dem Browser ins Internet dürfen und aus dem lokalen LAN soll ein Management von Komponenten (z.B. WLAN) im Gastnetz per HTTP und SSH möglich sein, nicht aber darf das Gastnetz Zugriff auf das lokale LAN haben.
"Schotten dicht....!!" Los gehts...
(Die folgende Beispiel Konfig enthält der Übersicht halber nur die Firewall relevanten Konfigurations Parameter!)
Zuerst richtet man die entsprechenden Zonennamen ein. Hier im Beispiel somit also 3 Zonen (Gast, Lokales LAN und Internet).
Kosmetischer Tip: Es macht Sinn die Map und Zonen Namen immer GROß zu schreiben um sie von den Konfig Kommandos einfacher unterscheiden zu können. Die Namen sind frei wählbar.
⚠️ Die Reihenfolge in den class-map Definitionen zählt!!
Zuerst bestimmt man mit den Class Maps die Netzwerk Protokolle die man zulassen und überwachen möchte. TCP und UDP am Schluss macht eine Inspection über alle Protokolle die nicht explizit definiert wurden. Würde man dies global am Anfang definieren kommt es zu keiner protokollspezifischen Inspection mehr! Lässt man es weg passiert die Firewall nur was protokollspezifisch definiert wurde.
Es ist also wichtig diese globalen Definitionen wegzulassen wenn man z.B. nur Webtraffic mit HTTP und HTTPS zulassen möchte wie es im Folgenden in der Class Map GAST-ERLAUBT für das Gästenetz definiert wurde.
!
class-map type inspect match-any GAST-ERLAUBT
match protocol http
match protocol https
match protocol dns
match protocol ntp
!
class-map type inspect match-all ALLOW_IN
match access-group name ALLOWv4
!
class-map type inspect match-any LOKAL-ERLAUBT
match protocol http
match protocol https
match protocol dns
match protocol pop3s
match protocol imaps
match protocol smtp
match protocol rtsp
match protocol ftp
match protocol ftps
match protocol ssh
match protocol ntp
match protocol tcp
match protocol udp
match protocol icmp
!
class-map type inspect match-any ROUTER-PROTOCOLS
match protocol tcp
match protocol udp
match protocol icmp
!
Dazu kommen nun die Policies was gemacht werden soll und darf zwischen den Zonen:
!
policy-map type inspect GAST-INTERNET-POLICY
description Traffic Gast zum Internet
class type inspect GAST-ERLAUBT
inspect
class class-default
drop
!
policy-map type inspect ROUTER-INTERNET-POLICY
description Traffic Routertraffic zum Internet
class type inspect ROUTER-PROTOCOLS
inspect
class class-default
drop
!
policy-map type inspect LOKAL-INTERNET-POLICY
description Traffic Lokales LAN zum Internet
class type inspect LOKAL-ERLAUBT
inspect
class class-default
drop
!
policy-map type inspect INTERNET-ROUTER-POLICY
description Traffic Internettraffic zum Router
class type inspect ALLOW_IN
pass
class class-default
drop
!
Dann werden die Zonen definiert (hier 3):
!
zone security LOKAL
zone security GAST
zone security INTERNET
Last but not least richtet man die Zonen Paare ein (wer mit wem) und aktiviert die dazu korrespondierende Security Policy. Danach weist man den Interfaces die Zonen zu:
!
zone-pair security LOKAL-INTERNET source LOKAL destination INTERNET
service-policy type inspect LOKAL-INTERNET-POLICY
!
zone-pair security GAST-INTERNET source GAST destination INTERNET
service-policy type inspect GAST-INTERNET-POLICY
!
zone-pair security INTERNET-ROUTER source INTERNET destination self
service-policy type inspect INTERNET-ROUTER-POLICY
!
zone-pair security ROUTER-INTERNET source self destination INTERNET
service-policy type inspect ROUTER-INTERNET-POLICY
!
interface Vlan1
description Lokales LAN
zone-member security LOKAL
!
interface Vlan10
description Gastnetz
zone-member security GAST
!
interface Virtual-Template1
description IPsec VPN Dialin
ip unnumbered Vlan1
zone-member security LOKAL
!
interface Dialer0
description DSL Internet Interface
zone-member security INTERNET
!
ip access-list extended ALLOWv4
permit udp any any eq 1701
permit udp any any eq isakmp
permit udp any any eq non500-isakmp
permit esp any any
!
Das Show Kommando: show policy-map type inspect zone-pair <Zone_paar_name> (hier als Beispiel einmal "show policy-map type inspect zone-pair LOKAL-INTERNET) zeigt dann z.B. die Statistiken der inspizierten Protokolle aus dem lokalen LAN ins Internet.
sh policy-map type inspect zone-pair sessions zeigt alle aktiven Endgeräte Sessions an über alle Zonenpaare.
Die korrekte Einbindung von VPN Verbindungen in die ZFW Firewall zeigt ein separates Tutorial.
Port Forwarding Setups mit der ZFW Firewall behandelt ebenso ein ZFW Port Forwarding Tutorial.
⚠️ Der folgende Hinweis gilt ausschliesslich nur für Nutzer die mit der ZFW ein Router WAN Interface im DHCP Client Mode mit IPv4 nutzen, also ein WAN/Internet Interface was sich dynamisch per DHCPv4 IP Adressen holt. (Kein PPPoE mit xDSL!)
Im DHCPv4 Client Mode muss in diesem Falle in der ZBF statt inspect der pass Mode in der obigen Outbound Policy Beispiel Map: ROUTER-INTERNET-POLICY verwendet werden, damit ausgehend DHCPv4 Requests die Firewall überwinden können !
Zusätzlich muss die Inbound Acessliste (ALLOWv4) für DHCPv4 geöffnet werden die den externen Traffic auf den WAN/Internet Port (Zone "Internet") steuert:
class-map type inspect match-any DHCPv4
match access-group name DHCPv4
!
ip access-list extended ALLOWv4
remark Pass traffic fom DHCPv4 server
permit udp any eq bootps any eq bootpc --> (DHCP darf eingehend passieren)
remark Pass IPsec VPN traffic
permit udp any any eq 1701
permit udp any any eq isakmp
permit udp any any eq non500-isakmp
permit esp any any
!
ip access-list extended DHCPv4 --> (DHCP Request Broadcasts dürfen ausgehend passieren)
remark Pass DHCPv4 client traffic
permit udp any eq bootpc any eq bootps
!
policy-map type inspect ROUTER-INTERNET-POLICY
description Traffic Routertraffic u.DHCPv4 zum Internet
class type inspect DHCPv4
pass
class type inspect ROUTER-PROTOCOLS
inspect
class class-default
drop
Zu der Thematik bitte auch diesen Hinweis in den Nutzerkommentaren beachten !
Die IPv6 Protokoll Steuerung und viele Features die bei v4 eigene Protokolle nutzen, basieren bei IPv6 zu einem sehr großen Teil auf dem ICMP Protokoll. ICMP darf also bei v6 nicht gefiltert werden bzw. nur in sehr geringem Maße (siehe hier Tabelle 5, Seite 6).
Deshalb muss die ZFW Firewall für den Dual Stack Betrieb IPv4 mit IPv6 etwas angepasst bzw. erweitert werden im Bereich ICMPv6.
Generell gilt das Regelwerk der ZFW Firewall aber immer für IPv4 und auch IPv6 gleichermaßen.
Man erstellt zuerst 3 Access Listen die die für IPv6 wichtigen ICMP Typen passieren lassen und die DHCPv6 Frames am WAN Port für die Adress Prefix Delegation erlaubt.
Die IPv4 ACL (gleiche wie oben) stellt sicher, das VPN Traffic remoter Nutzer den Router durch die Firewall am WAN/Internet Port erreichen kann.
!
ip access-list extended ALLOWv4
10 permit udp any any eq 1701
20 permit udp any any eq isakmp
30 permit udp any any eq non500-isakmp
40 permit esp any any
!
ipv6 access-list ALLOWv6
sequence 10 permit udp any eq 547 any eq 546 --> (Erlaubt DHCPv6 Traffic zur v6 Prefix Delegation)
!
ipv6 access-list ICMPv6
sequence 10 permit icmp any any unreachable
sequence 20 permit icmp any any packet-too-big
sequence 30 permit icmp any any hop-limit
sequence 40 permit icmp any any reassembly-timeout
sequence 50 permit icmp any any header
sequence 60 permit icmp any any next-header
sequence 70 permit icmp any any parameter-option
sequence 80 permit icmp any any echo-request
sequence 90 permit icmp any any echo-reply
sequence 100 permit icmp any any dhaad-request
sequence 110 permit icmp any any dhaad-reply
sequence 120 permit icmp any any mpd-solicitation
sequence 130 permit icmp any any mpd-advertisement
!
Aus den beiden WAN Port ACLs und der v6 ICMP ACL definiert man dann 2 zusätzliche Class Maps der ZFW:
!
class-map type inspect match-any ALLOW_IN
match access-group name ALLOWv4
match access-group name ALLOWv6
!
class-map type inspect match-any ROUTER-PROTOCOLS
match class-map ALLOW_IN
match protocol tcp
match protocol udp
match protocol icmp
!
class-map type inspect match-any ICMPv6
match access-group name ICMPv6
!
Die dann wiederum in die entsprechenden Policy Maps für die Zonen münden:
!
policy-map type inspect ICMPv6
description Traffic ICMPv6 ins lokale LAN
class type inspect ICMPv6
inspect
class class-default
drop
!
policy-map type inspect INTERNET-ROUTER-POLICY
description Erlaubter Traffic Internet zu Router
class type inspect ALLOW_IN
pass
class class-default
drop
!
Daraus resultiert dann die angepasste Zonen Konfig:
!
zone-pair security ICMPv6 source INTERNET destination LOKAL
service-policy type inspect ICMPv6
!
zone-pair security InternetToRouter source INTERNET destination self
service-policy type inspect InternetToRouter
!
(Namen der Maps ggf. an eigene Konfig anpassen !)
⚠️ Seit Januar 2020 hat die Telekom die alten Entertain Multicast Streams abgeschaltet ! Siehe dazu auch HIER.
Wer also IP TV mit VLC oder KODI im heimischen Netz schaut muss auf die neuen Multicast Adressen umstellen. Magenta TV supportet nur noch SSM Multicast und erzwingt damit die Verwendung von IGMPv3.
Magenta TV funktioniert aber weiterhin fehlerlos mit den u.a. Einstellungen und kann so auch weiter mit dem Cisco problemlos mit Settopbox, VLC, Kodi, TV-Headend und anderen freien Tools gesehen werden.
Da der Router vollständigen Multicast Routing Support mit an Bord hat, ist die Aktivierung von IP TV auf dem Cisco Router kein großes Problem. In Ausnahmefällen ist hier ggf. eine zusätzliche Advanced IP Lizenz erforderlich. Mit show license all lässt sich das überprüfen und ggf. eine Multicast Lizenz nachinstallieren.
Mit der neuen BNG Umstellung der Telekom ist die Magenta IP-TV Konfiguration um einiges einfacher geworden. Das folgende Beispiel zeigt eine funktionsfähige Konfiguration. (Kommandos in rot kommen zur bestehenden Grundkonfiguration in blau dazu !)
Generell funktioniert diese Konfiguration auch für alle anderen Cisco IOS und IOS-XE Router Modelle am IP-TV Anschluss der Telekom bzw. Providern die Multicast für IP-TV nutzen.
!
ip multicast-routing
ip pim ssm default
!
interface Vlan1
description Lokales LAN
ip address 192.168.100.254 255.255.255.0
ip pim sparse-mode
ip nat inside
ip virtual-reassembly in
ip tcp adjust-mss 1448
ip igmp helper-address 62.155.243.102
ip igmp version 3
ip igmp explicit-tracking
!
interface Dialer0
description VDSL PPPoE Einwahl Interface
ip address negotiated
ip access-group 111 in
no ip redirects
no ip unreachables
no ip proxy-arp
ip mtu 1488
ip pim sparse-mode
ip nat outside
ip inspect myfw out
ip virtual-reassembly in
encapsulation ppp
ip igmp version 3
dialer pool 1
dialer-group 1
ppp authentication pap callin
ppp pap sent-username xxxxxxxx@t-online.de password 0 xxxxxxx
ppp ipcp dns request
ppp ipcp mask request
ppp ipcp route default
no cdp enable
!
ip pim rp-address 62.155.243.102
!
Das Senden von Multicast Streams über das VLAN 8 (Tagging, Subinterface Ethernet0.8) ist nicht mehr supportet bei der Telekom bzw. Magenta TV. Der Vollständigkeit halber sei es aber hier noch erwähnt sofern alternative IP-TV Provider diese Option mit separatem Tagging noch nutzen.
!
ip multicast-routing
ip pim ssm default
!
interface Ethernet0.8
description VDSL Multicast Entertain
encapsulation dot1Q 8
ip dhcp client broadcast-flag clear
ip address dhcp
ip pim sparse-mode
no ip mroute-cache
ip igmp version 3
ip igmp query-interval 15
ip igmp proxy-service
!
interface Vlan1
ip pim sparse-mode
ip igmp helper-address 62.155.243.102
ip igmp version 3
ip igmp explicit-tracking
ip igmp query-interval 15
ip igmp proxy-service
!
ip pim rp-address 62.155.243.102
Die Prozedur der Rendezvous Point IP Adress Ermittlung ist mittlerweile einfacher als im unten angegebenen PDF beschrieben. Mit show ppp all kann man diese auf dem Router direkt ermitteln.
Die Multicast Rendezvous Point IP Adressen werden über DHCP mitgeteilt.
Ein show dhcp lease zeigt dann abhängig vom jeweiligen Ort z.B. so etwas an:
Temp ip static route0: dest 193.158.132.189 router 10.34.63.254
Temp ip static route0: dest 87.141.128.0 router 10.34.63.254
(Dank an Forumsmitglied @cpt-haddock für diesen Hinweis im u.a. Tutorial Feedback Thread !)
Die IP-TV Multicast Adress Listen um Telekom Magenta TV auf PC, Laptop oder mobilem Tablet/Smartphone z.B. mit VLC, KODI und dvbviewer Clients zu sehen findet man HIER. (Achtung ! Multicast Adressänderung hier ab 09.01.2020)
Da mit Ausnahme des Cisco CCO Downloads nicht alle Quellen von Firmware Dateien immer zuverlässig oder fehlerfrei sind, sollte man vor der Übertragung einer neuen Firmware-Datei auf den Router per TFTP oder USB Stick immer einen Firmware Check VOR der Installation durchführen.
So vermeidet man proaktiv eine aufwendige Firmware Wiederherstellung des Routers über sein serielles Terminal Interface.
Nach der Übertragung der Firmware Datei in den Flash Speicher sollte folgender Befehl ausgeführt werden:
verify flash: c800-universal9-mz.SPA.159-3.M2.bin
(Hier statt des Beispiels immer den aktuellen Firmware Datei Name verwenden!!)
Dabei werden zwei SHA2 Hashes errechnet und ein MD5 Hash.
Der untenstehende MD5 Hash sollte mit dem Wert der entsprechenden Datei auf der Cisco Webseite verglichen werden. Stimmen beide SHA2 Werte und der MD5 Wert überein, kann man bedenkenlos die Firmware aktualisieren.
Bei IOS-XE Firmware lautet das Kommando:
verify /md5 flash:c1100-universalk9.17.09.05a.SPA.bin
Den Parameter "md5" kann man alternativ mit /sha512 ersetzen um statt eines MD5 Hashes einen SHA512er zu berechnen.
Der Cisco EEM ist ein flexibles Scripting System im IOS oder IOS-XE mit dem man Ereignisse und wiederkehrende Events automatisieren kann um so Funktionen nach eigenen Wünschen umzusetzen. Sämtliche Möglichkeiten inklusive TCL und Expect Scripting zu beschreiben würde den Rahmen dieses Kapitels sprengen so das hier nur 2 kurze Beispiele erwähnt werden. Details entnimmt man der EEM Command Reference und dem EEM Best Practise Guide.
Das Beispiel 1 pingt einen remoten VPN Router (oder Host) alle 5 Minuten und meldet einen VPN Fehler per Syslog:
Beispiel 2 sendet ein Email wenn sich ein Admin per SSH auf dem Cisco einloggt. Über Variablen kann man jeglichen show Output senden wie z.B. auch wechselnde IPs am WAN Port.
Oben in der Grundkonfiguration regelt die Accessliste "CLI-ACCESS" welche IP Adressen bzw. IP Netze Zugang zum Kommando Interface vty 0 4 des Routers haben und welche nicht. ("vty" steht hier für virtuelles SSH oder Telnet Terminal)
Der ACL Name ist dabei frei wählbar.
Diese Zugangsbeschränkung auf den Router lässt sich mit ein paar mehr Kommandos noch weiter sichern.
login block-for 120 attempts 3 within 15 <-- Blockt den Zugang bei 3 Fehlveruchen innerhalb von 15 Sek. für 120 Sek.
login delay 3 <-- Verzögert den Login Prompt für 3 Sek.
login quiet-mode access-class 23 <-- Während des o.a. Block Modes bei Fehlversuchen greift weiter ACL 23
login on-failure log <-- Login Fehlversuche werden mitgeloggt
login on-success log <-- Erfolgreiche Logins werden mitgeloggt
!
line vty 0 4
access-class CLI-ACCESS in <-- Telnet/SSH/SNMP Zugriff nur aus lokalem LAN möglich (ACL "CLI-ACCESS")
exec-timeout 15 0 <-- Inaktivitätstimer, loggt autm. aus nach <min> <sek> (Default 10 Min. exec-timeout 10 0)
login local
transport input telnet ssh <-- Telnet / SSH Zugriff. Ist zur Sicherheit nur SSH gewünscht "telnet" hier weglassen.
!
Der Zugang kann, wie bei Netzinfrastruktur Geräten üblich, zusätzlich über einen externen AAA Server wie Radius oder TACACS abgesichert werden.
Analog ist die Accessliste "CLI-ACCESS" auch für das SNMP v2c Management relevant, die damit nur SNMP Zugriff aus dem internen oder Management LAN erlaubt.
!
ip telnet source-interface Vlan1 <-- Absender IP für Telnet Traffic ist immer vlan1
ip tftp source-interface Vlan1 <-- dto. TFTP Traffic (Konfig und Image Sicherung übers Netz)
ip ssh source-interface Vlan1 <-- dto. SSH Traffic
!
snmp-server community public RO CLI-ACCESS
snmp-server community private RW CLI-ACCESS
snmp-server trap-source Vlan1
snmp-server source-interface informs Vlan1
snmp-server location Rechenzentrum, Schrank 1
snmp-server contact IT-Abteilung, Tel.:123
(snmp-server host <ip_snmp_server> version 2c private) <-- Optional. Nur wenn SNMP Server auch Traphost ist
!
Die SNMP v2c Community Strings public und private sind natürlich hier nur Beispiele und unbedingt mit individuellen zu ersetzen ! Ganz besonders der private String, denn der hat RW (Read, Write) Optionen, kann also per SNMP die Routerkonfiguration verändern.
Wer mehr Sicherheit möchte und den SNMP Zugang verschlüsseln will ersetzt immer SNMPv2c mit SNMPv3.
Gute kostenfreie Programme die ein grafisches SNMP Management ermöglichen sind z.B. PRTG, LibreNMS, Zabbix, Cacti, Nagios, Observium usw. Das hiesige Management Tutorial gibt eine kurze Übersicht.
Generell gibt es keinerlei Hürden beim SSH Zugang auf das Kommando Interface mit bekannten Tools wie PuTTY or TeraTerm oder aus der Powershell. Klassische Smartphone Clients sind z.B. Shelly SSH-Client für iPhone oder Juice SSH für Android. Mittlerweile bringen ausnahmslos alle Betriebssysteme immer auch einen SSH Client mit.
Auf die Verwendung von Telnet sollte man wegen der fehlenden Verschlüsselung aus Sicherheitsgründen verzichten oder zumindestens mit ACLs (Beispiel oben ACL "CLI-ACCESS") sicherstellen das Telnet nur aus lokalen Netzen erlaubt ist.
Mit der obigen Aktivierung von SSH Ver.2 auf dem Cisco muss ein entsprechender 1024 Bit (oder größer Key) erstellt werden. Das Kommando dafür lautet crypto key generate rsa. Einen ggf. vorhandenen alten Key kann (und sollte) man vorher mit crypto key zerosize löschen.
Mit aktuellen Linux oder Mac OS Versionen kommt es aber manchmal zu Fehlern aufgrund der dort erzwungenen starken Key Exchange Algorithmen in OpenSSH, die häufig kein diffie-hellman-group14-sha1 mehr supporten, was in manchen Netzwerk Geräten vieler Hersteller enthalten ist. Mit ein paar kleinen Tricks lässt sich das aber sehr einfach umschiffen.
Wenn der Zugang auf den Cisco aufgrund eines nicht supporteten kex algorithm oder mit port 22: no matching host key type found. Their offer: ssh-rsa abgelehnt wird, kann man das SSH Kommando etwas erweitern:
ssh -oKexAlgorithms=+diffie-hellman-group14-sha1 admin@<ip_address>
Um das nicht immer manuell machen zu müssen legt man ganz einfach unter /home/user/.ssh/ eine Text Datei mit dem Namen config und dem folgenden Inhalt an:
(Die IP Adresse 172.30.0.102 ist hierbei eine der Zugangs Adressen des Ciscos. Hier können mehrere IPs eingetragen werden sollte man mehrere Geräte haben. Alternativ gruppiert man bei mehreren Geräten die IPs oder Hostnamen mit einem Leerschritt mit Host <ip_oder_host> <ip_oder_host> usw. oder mit Host * wenn die Erweiterung generell für alle SSH Endgeräte gelten soll.)
Der gleiche kex error kann auftreten wenn man schnell einmal vom Cisco CLI mit dem Kommando ssh -l <username> <cisco_ip> per SSH auf einen anderen SSH Host zugreifen will oder Dateien vom Flash per SCP kopieren möchte. Auch hier hilft wieder eine Konfig Text Datei im Verzeichnis /etc/ssh/sshd_config.d des Ziel SSH Servers z.B. mit dem Namen cisco.conf (alles was .conf als Dateierweiterung im Namen hat ist erlaubt) und mit folgendem Inhalt:
(Den SSH Server danach mit systemctl restart sshd neu starten.)
Damit sollten dann alle SSH Verbindungen in egal welche Richtung immer klappen.
⚠️ Beim Kopieren von Dateien mit SCP auf den Cisco ist unbedingt der -O Parameter zu verwenden! (Siehe entsprechende TechNote von Cisco zu der Thematik)
Alle relevanten Einstellungen zum Kopieren mit SCP beschreibt u.a. dieser Forenthread. Eine Automatisierung per Skript mit z.B. Expect beschreibt u.a. dieser Thread.
Die Lösung mit dem -O Parameter beim Kopieren mit SCP gilt sehr wahrscheinlich auch für alle anderen Hersteller die ein Kopieren von Dateien per SCP supporten!
Um sich die tägliche Arbeit zu erleichtern, können sogenannte Alias Kommandos eingesetzt werden. Hierbei kann man einen längeren Befehl stark verkürzen.
Damit kann ein Benutzer sich diesen leichter merken und schneller abrufen.
Als Beispiel sind im Folgenden 4 verschiedene angepasste show Befehle aufgeführt.
Es können aber auch alle anderen Befehle mit einem alias versehen werden. Z.B.:
alias exec cpu show processes cpu sorted | exclude 0.00%
alias exec brief show ip interface brief
alias exec vpn show crypto ipsec sa
alias exec run show running-config brief
Der oberste Alias Befehl "cpu" zeigt die Ausgabe vom "show processes cpu sorted" ohne Prozesse mit 0% Auslastung an. Mit brief wird dann "show ip interface brief" und mit vpn wird "show crypto ipsec sa" angezeigt. Das letzte Alias Beispiel kürzt mit run die Ausgabe der aktuellen Konfiguration ohne SSH Keys.
Vorab: Mit modernen Browser Versionen ist das CCP Express Tool für die 800er Modelle ggf. nicht mehr nutzbar! Alle aktuellen ISR Modelle sind davon generell nicht betroffen, denn diese haben schon von sich aus ein GUI an Bord.
Die Kommandozeile ist sicher nicht immer jedermanns Freund und natürlich hat der Cisco mit dem Cisco Configuration Professional Express oder kurz CCP Express Admin View auch ein grafisches Browser Interface zum Konfigurieren.
Neue Router kommen damit ausgestattet zum Käufer aber viele gebraucht erworbene oder solche wo es vom Flash gelöscht wurde, haben es nicht. Ob es bereits installiert ist, sieht man mit dem Befehl show flash:
Die Installation oder ein Update auf die aktuelle Version ist aber im Handumdrehen erledigt. Ggf. vorhandene alte Versionen sollte man dazu, wie unten beschrieben, immer VORHER vollständig vom Flashspeicher des Routers löschen!
Los gehts...
Zuerst läd man dazu das Cisco CP Express Tool HIER herunter. Im Cisco Download ist es wegen EoS nicht mehr verfügbar. Aktuell ist derzeit das Release 3.5.2 (Stand 07.2018).
Dann entZIPt man das ZIP Archiv und kopiert die .tar und die .gz Datei in ein Verzeichnis.
Um die CCP Dateien auf das Router Flash zu bekommen nutzt man am besten und schnellsten einen USB Stick über die USB Frontbuchse. Alternativ ist ein TFTP Server erforderlich.
Ideal ist der Klassiker TFTP32 bzw. sein 64Bit Pendant oder der Pumpkin unter Windows. Apple Mac und Linux User haben TFTP von sich aus gleich an Bord.
Die Prozedur den TFTP aufzusetzen ist immer gleich und HIER am Beispiel der Cisco Telefone genau beschrieben.
Gleiches macht man ebenso für den Router. Auch z.B. wenn man die Router Firmware einmal updaten möchte oder auch die xDSL Modem Firmware wie oben beschrieben anpasst.
Router und TFTP Server sollten sich zum Vorabcheck pingen lassen untereinander. Bei Windows an die lokale Firewall denken das diese TFTP Traffic passieren lässt !
Der Rest ist schnell gemacht:
router> enable
Password: password
router# copy tftp: flash
Address or name of remote host ? <---Hier die TFTP Server IP Adresse angeben
Source filename ? ccpexpressAdmin_x_y_en.tar <--- Hier den CP Express .tar Dateinamen angeben. (x und y ist die Versionsnummer)
Destination file name ? ccpexpressAdmin_x_y_en.tar <--- Einfach Dateiname mit <Return> Taste bestätigen !
Damit wird dann die .tar Datei auf das Router Flash übertragen.
Wer es ganz einfach machen will nimmt einen USB Stick kopiert den Cisco Express Admin View Tar File ohne Unterverzeichnis einfach darauf und steckt den Stick in den Router USB Port.
Ein copy usbflash0:ccpexpressAdmin_x_y_en.tar flash: (Dateiname wie im Download, x.y = Versionsnummer)
kopiert dann die Datei in den Router Flash Speicher.
Im Anschluss muss diese .tar Archiv Datei noch mit dem folgenden Kommando extrahiert werden. (.tar ist unter Unix sowas wie .zip unter Windows)
router# archive tar /xtract flash:ccpexpressAdmin_x_y_en.tar flash:/ (x_y = Versionsnummer)
Nun muss nur noch der HTTP Server auf dem Router mit
router> conf t
router-conf#> ip http server
aktiviert werden. Wer es gerne sicher verschlüsselt hätte, der nimmt entsprechend:
router-conf#> ip http secure-server
Die Authentisierung sollte noch auf den lokalen Usernamen und Passwort eingestellt werden mit ip http authentication local und das das Web GUI ausschliesslich aus dem lokalen Netz erreichbar ist: ip http access-class 23
Jetzt ist das grafische Web GUI über die LAN IP des Routers mit dem Web Browser erreichbar.
Die HTTP Konfig sieht dann so aus:
!
aaa new-model
aaa authentication login default local
!
enable secret Geheim123
!
username admin password Geheim123
!
ip http server
ip http secure-server
ip http access-class 23 ---> Bindet das Web GUI an die Access Liste 23. Ggf. weglassen wer das WebGUI von überall erreichen will. (Nicht empfehlenswert, Sicherheit !!)
!
access-list 23 permit 192.168.100.0 0.0.0.255
!
line vty 0 4
access-class 23 in ---> Lässt den Management Zugang nur aus dem lokalen LAN zu !
password geheim1234
transport input all ---> Wer nur SSH zulassen will (kein Telnet) ändert all in ssh !
!
⚠️ Der Webserver erfordert als Login immer den Usernamen der mit "username xy password xyz" in der Konfig gesetzt wurde aber als Passwort das enable secret Passwort !!!
Dies bitte beachten wenn man keinen Frust beim Web Login erleben will.
Da hier in der Basiskonfig oben enable secret Geheim123 und auch im Usernamen admin im Beispiel Geheim123 gleiche Passwörter gesetzt wurden passt es hier im Beispiel zufälligerweise.
Wer aber aus gutem Grund unterschiedliche Passwörter für das enable secret und den Usernamen verwendet hat sollte das zwingend beachten:
Web GUI Login: Username=Username und das Passwort ist das enable-secret Passwort !
Zum Entfernen des GUIs vom Router Flash sind folgende 2 Konfig Schritte erforderlich.
router# delete /force /recursive home.shtml
router# delete /force /recursive flash:ccpexp
Die noch auf dem Flash befindliche .tar Archiv Datei kann man nach dem Installieren oder Update beruhigt löschen mit:
router# del flash:<Dateiname.tar>
NBAR (Network-Based Application Recognition) ist ein Router Backend zur protokollspezifischen Traffic Erkennung und Klassifizierung. NBAR klassifizierter Traffic kann für QoS, Firewall und auch NetFlow Reporting verwendet werden. Alle NBAR Optionen zu beschreiben würde den Rahmen dieses Tutorials sprengen so das im Folgenden nur die Grundinstallation gezeigt wird.
Zuerst muss die NBAR Protokoll-Pack Datei downgeloaded und installiert werden. Diese Datei ist IOS versionsspezifisch, also auf die passende Version achten die zur Firmware passt (Release Notes!)!
Die NBAR .pack Datei wird via USB Stick ins lokale Flash kopiert analog wie man dies auch bei einem Software Update macht mit copy usbflash0:<pp_datei.pack> flash:
Das globale Kommando um die Protocol Pack Datei zu laden lautet:
ip nbar protocol-pack flash:pp-adv-isrg2-158-3.M-23-32.3.0.pack
Die Protokollanalyse aktiviert man dann z.B. auf dem lokalen LAN Interface:
interface Vlan1
description Lokales LAN
ip address 192.168.100.254 255.255.255.0
ip nbar protocol-discovery
ip nat inside
Eine einfache Protokoll Statistik erhält man z.B. mit
show ip nbar protocol-discovery
Die Top 5 Talker im Netzwerk in Bezug auf Protokollnutzung zeigt ein:
Aufschlussreiche Infos liefern auch Statistiken der am meisten genutzen UDP u. TCP Ports oder der meistegenutzen Hosts.
Die globalen Kommandos
ip nbar classification auto-learn { top-hosts | top-ports }
aktivieren diese Funktion und entsprechende show Kommandos liefern den Output.
Weiterführende Infos zum Thema NBAR liefert der NBAR Configuration Guide.
Dies beschreibt ein separates Forentutorial.
Vorbemerkung:
Die folgende Anleitung gilt nur für die älteren nicht K9 Modelle ! Wer also einen 88x K9 hat oder z.B. einen 886vaw (wireless) hat keinen internen RAM Slot mehr, sondern immer fest 512 MB onboard ohne Aufrüstmöglichkeit !
In der Regel erkennt man diese neueren Modelle daran das sie keinen Gehäuse Lüfter mehr haben.
Wer das 880er Model gebraucht erwirbt, sollte einen Blick auf die RAM Ausstattung des Routers werfen ! Die einfache Variante kommt mit 256 MB Onboard RAM daher. Für eine anspruchsvolle Konfiguration kann das schnell zu wenig sein, denn der Router braucht dann mehr RAM fürs Puffern von Daten, Firewall Prozesse, Routing Tabelle usw.
Der Router bietet einen freien SO-DIMM Steckplatz wie man ihn auch aus Laptops oder Notebooks her kennt. Diesen kann man max. mit einem Standard 512 MB SO-DIMM bestücken um dann in Summe auf 768 MB RAM Speicher zu kommen. Diese Aufrüstung ist in jedem Falle empfehlenswert, sollte der Router weniger RAM haben.
Auskunft über die aktuelle RAM Ausstattung bekommt man mit dem show version Kommando.
Dort sieht man u.a. eine Zeile mit folgendem Inhalt:
Cisco 886VA (MPC8300) processor (revision 1.0) with 708608K/77824K bytes of memory.
Wer diesen Output bekommt hat schon die Maximalausstattung.
Steht allerdings ein "...with 208608K/77824K bytes of memory" dort, läuft der Router nur mit dem schmalen 256 MB onboard Memory. (Leerer RAM Slot)
Der Cisco 886va verwendet Standard SO-DIMM Module mit 512MB wie man sie z.B. HIER recht preiswert neu bekommt.
Man erhält aber solche SO-DIMM Module mit der Spezifikation DDR2-533 PC2-4200S CL4 2Rx16 auch für noch weniger Geld wenn man bei den einschlägigen Auktionshäusern danach sucht. Sie sind sehr häufig auch in Laptops und Notebooks verwendet worden und bei einer RAM Aufrüstung dann übrig geblieben.
Die Aufrüstung des Cisco's ist schnell gemacht.
Man löst die 3 Gehäuseschrauben und klappt den Gehäusedeckel von hinten nach vorne in Richtung Frontpanel auf. Der SO-DIMM Slot befindet sich rechts. (Es gibt nur einen einzigen !)
Dort setzt man jetzt das SO-DIMM ein und arretiert es durch Runterdrücken wie bei einem Laptop oder Notebook.
Beim Booten sollte der Router dann die automatisch erkannten 768 MB melden oder eben mit dem o.a. show version Kommando.
Das 89x Modell kommt ab Werk mit 512MB onboard und kann auf max. 1Gig aufgerüstet werden. Auch hier sollte man mit dem show version Kommando vorher prüfen wieviel RAM verbaut ist.
Ab Werk ist kein 880er Router mit der nötigen PoE Erweiterungskarte ausgestattet. Ist man sich nicht sicher ob das Gerät bereits über eine PoE Erweiterungskarte verfügt, kann ein "show power inline" Befehl Aufschluss geben. Ohne PoE im Router quittiert dieser dies mit einer Fehlermeldung.
PoE LAN Ports können dann VoIP Telefone oder WLAN APs usw. bedienen.
Nach dem Öffnen des Routers, wie oben bei der RAM Nachrüstung, müssen beim 886 VAJ-K9 Model 5 Distanzstehbolzen in den dafür vorbereiteten Bohrungen handfest verschraubt sein bevor die Karte eingesetzt werden kann. Nun wird die Karte mit weißen Kontaktstecker korrekt eingeklipst und handfest mit den Schrauben verschraubt. Die Steckverbindung ist im Router absolut eindeutig da nur einmal vorhanden und ein Verwechseln damit sicher ausgeschlossen.
Je nach Variante muß noch intern ein Stromkabel montiert werden. Nach dem Anschluß des mitgelieferten, stärkeren Stecker Netzteils hat man nun auf den mit "PoE" beschrifteten LAN Ports eine Standard konforme PoE Stromversorgung anliegen.
Es können nur Geräte mit dem IEEE PoE Standard 802.3af angeschlossen werden. Zusätzliche Informationen zur PoE Aufrüstung findet man in einem YouTube Video.
Wie Anfängerprobleme bei der Cisco Konfig vermeiden ?:
VoIP hinter Cisco Router
Routing Telekom VDSL mit cisco 896VA
CISCO 926-4P SEC Lizenz ,CLM oder Installation Lizenz USB und Zone Based Firewall <== (ZFW Firewall für IPv4 und IPv6)
Cisco IOS und IOS XE Kommando Syntax Überblick:
http://www.coufal.info/cisco_ios/index.shtml
https://www.r33net.de/cisco-router-konfiguration-befehlecommands/
https://www.cisco.com/c/en/us/td/docs/routers/access/800/software/config ...
https://www.cisco.com/c/en/us/td/docs/routers/access/isr1100/software/co ...
Troubleshooting: Paket Capture im Wireshark Format auf Cisco:
https://www.youtube.com/watch?v=5ppEIzilUsc
Den seriellen Konsolen Port sicher meistern:
Serial Console Kabel - Rollover Console Kabel - Adapter
Keine serielle Verbindung zu Cisco 886W
Infos zu SEC Lizenzen (Firewall + VPN) für neuere ISR Modelle z.B. 900 und 1100:
Cisco Router Lizenzen
Quelle: https://www.ethcon.de
880er Modelle, Annex-J Modem Software und VDSL Vectoring:
Kann der Cisco 866VAE VDSL-Vectoring? (und ein Blick in die DSL-Firmware)
VDSL Controller bei C886VA und C896VA einmalig für acht Sekunden UP
PPPoE Konfig Tips für das Dialer Interface:
https://www.cisco.com/c/de_de/support/docs/wan/point-to-point-protocol-p ...
Externes xDSL Modem wie Dratek Vigor 165, Zyxel VMG3006 usw. verwenden:
Cisco 881, virtual-interface bleibt UP, auch wenn das Modem ausgeschaltet ist
Cisco ISR 1100 Router Modell Überblick:
https://www.ciscolive.com/c/dam/r/ciscolive/emea/docs/2020/pdf/BRKARC-20 ...
Port Forwarding mit ZFW Firewall absichern:
Cisco router with zone based firewall and port forwarding
Cisco VPN mit ZFW Firewall zu Mikrotik oder FritzBox:
Cisco IPsec VPN with Mikrotik or FritzBox
Grundlagen ZFW Firewall inkl. Rate Limiting:
https://www.youtube.com/watch?v=ZmmvQH0seEc
Richtiger Umgang mit IP Access Listen auf dem Router:
Cisco 866VAE-K9 ACL-Konfiguration
Management Zugriff auf dem Cisco wasserdicht absichern:
https://www.cisco.com/c/de_de/support/docs/ip/access-lists/13608-21.html
Cisco Router mit Layer 3 Switch und DMZ generell:
Konfiguration Cisco 886VA-J und SG300
L2TP Client VPN für Windows, Mac und Smartphones:
https://community.cisco.com/t5/security-documents/l2tp-over-ipsec-on-cis ...
Fehler im L2TP Client VPN Setup vermeiden:
L2TP VPN Fehler sicher umschiffen
L2TP Site to Site (Standort) Anbindung mit Mikrotik:
MikroTik Router als VPN Client
iPhone und iPad bzw. generelles Client VPN Dialin mit IPsec:
Anbindung eines iPhone an einen Cisco Router mit dynamischer ISP Adressse via IPSec VPN über den iPhone Cisco Client
und auch:
IPsec IKEv2 VPN für mobile Benutzer auf der pfSense oder OPNsense Firewall einrichten
IPsec VPN als Client oder Standort zu Standort mit Cisco, pfSense, Mikrotik, IP-Cop oder FritzBox:
IPsec VPNs einrichten mit Cisco, Mikrotik, pfSense Firewall, FritzBox, Smartphone sowie Shrew Client Software
IPsec VPN Praxis mit Standort Vernetzung Cisco, Mikrotik, pfSense, FritzBox u.a
und auch:
Vernetzung zweier Standorte mit Cisco 876 Router
VPN Standort Kopplung mit VTI Tunnel Interface:
Cisco SVTI - Tunnel
2921 Kaskadierung mit Fritzbox für IPSEC-Tunnel
VPN IPsec Standort Kopplung Cisco-Mikrotik mit GRE Tunnel und dyn. Routing (RPv2 / OSPF):
Cisco, Mikrotik, pfSense VPN Standort Vernetzung mit dynamischem Routing
Zwischen Miktrotik und PFSense GRE Tunnel mit IPSec Verschlüsslung
VPN IPsec IKEv2 Standort Kopplung Cisco mit pfSense oder Mikrotik:
IPsec IKEv2 Standort VPN Vernetzung mit Cisco, pfSense OPNsense und Mikrotik
Cisco Router Konfig an einem T-Com Business VDSL Anschluss:
Cisco 866vae vdsl t-business feste ip - ip wird nicht erhalten
Cisco Router Konfig an einem alternativen VDSL Provider (Wilhelm.Tel):
Cisco 886VAW mit vDSL2 an SAGA Wilhelm Tel Leitung verliert dauernd die Verbindung
IPv6 DNS Konfiguration per RA oder DHCPv6 richtig einrichten:
DHCPv6 mit DNS unter Cisco IOS einrichten
IPv6 Netze per PD intern an Router/Firewall weitergeben
IPv6 Konfiguration über Tunnel Broker (Hurricane Electric):
IPv6 Konfig mit Tunnel im Cisco 886
Cisco Router mit L3 VLAN Switch Cisco CBS/SG sinnvoll koppeln:
Konfiguration Cisco 886VA-J und SG300
Port Forwarding vom Internet auf Rechner im lokalen LAN:
Cisco 886va VDSL Ports Weiterleiten ???
Mobilfunk Modell des 880ers konfigurieren:
https://www.youtube.com/watch?v=lGmh1JVKu5U
Tips zum SIP Setup (VoIP/Telefonie) Setup des Cisco 886 Routers:
Cisco 886VA, Gigaset C610-IP: ausgehende Telefonate nicht möglich
Cisco 880 mit Voice Option konfigurieren:
Cisco 887VA Konfiguration für SIPGATE-Trunking
Cisco IOS Automation mit Ansible:
https://www.youtube.com/watch?v=wbVZkb8ocH4
Beispiele zum VLAN Setup der Switchports und WLAN mit MSSID:
VLAN Installation und Routing mit pfSense, Mikrotik, DD-WRT oder Cisco RV Routern
Weitere Cisco Beispielkonfigurationen:
2921 sicher aufbauen für Internet
Cisco hat Internet - Computer nicht
Routing mit öffentlichem Subnetz
Cisco 926 mit Dual Stack und ZFW Beispielkonfig
Filterliste bei DHCP-Client statt PPPoE am WAN / Internet Port:
Cisco 2811 holt sich keine DCHP Adresse am FastEthernet interface
Tiefergehende Infos und HowTo's zur Cisco ZFW Firewall:
https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/sec_data_zbf/configura ...
http://brbccie.blogspot.com/2013/04/zone-based-firewall.html
https://www.cisco.com/en/US/prod/vpndevc/ps5708/ps5710/ps1018/prod_confi ...
Infrastruktur Protokoll mit LLDP
LLDP und FRITZ!Box 7530
Zusatzinfo zum IP-TV Entertain mit Cisco Multicasting via VDSL:
Cisco IOS Entertain IP-TV Konfig ?
Magenta TV und Cisco IOS
http://www.cisco-forum.net/topic_4350.0.html
(Non Cisco) Magenta TV mit Mikrotik:
Speedport W 724V + Routerboard 450G + VDSL (all IP) + Entertain
(Non Cisco) Magenta TV mit pfSense / OPNsense:
https://heise.de/-4698826
Die in diesem Tutorial beschriebenen Konfigurationsschritte gelten generell für alle IOS/IOS-XE basierten Cisco Router mit integriertem xDSL Hybridmodem und Ethernet bzw. Breitband Ports mit SFP Optiken.
Cisco Routermodelle stellen mit ihren weitreichenden NAT und Firewall Sicherheitsfeatures, dem integrierten hybriden xDSL sowie G.fast Vectoring Modem und der VPN Fähigkeit eine universelle Lösung für eine skalierbare und zukunftsorientierte Firmenanbindung kleiner und mittlerer Standorte mit xDSL, Kabel-TV oder Glasfaser WAN Bandbreiten dar. Sie sind ebenso für den anspruchsvollen Heimnutzer gedacht der Wert auf Sicherheit und maximalen Funktionsumfang legt.
Die Grundkonfiguration dieser Router ist durch die IOS Syntax universell und kann deshalb in Gänze oder Teilen auch auf alle anderen Cisco IOS Router- und Switchmodelle übernommen werden !
Inhaltsverzeichnis
Die Router Hardware
Cisco 886va(w), 887va(w) und auch deren Gigabit Pendant 896, 897 bzw. die derzeit aktuelle Cisco ISR Router Serie mit Cisco 900 oder Cisco 1100 sind sog. "Multi Service" ISR Router mit einem integrierten Multimode xDSL Hybrid Modem für VDSL2 und ADSL2/2+ (Annex B+J (ADSL2+ over ISDN)) sowie SDSL mit ITU G.993.2 (VDSL2) Super Vectoring, Profil 35b und G.fast.
Anwender ohne xDSL Anschluss z.B. mit einem Kabel TV Modem Anschluss oder Glasfaser, wählen hierfür Modelle mit Breitband WAN Port. Der WAN/Internet Port dieser Modelle ist ein reiner Ethernet Breitband Port ohne ein integriertes xDSL Modem zum Anschluss an vorhandene Kabel TV Modems oder FTTH / FTTB (Fiber to the Home/Building, Glasfaser) Anschlüsse.
Alle Modelle gibt es zusätzlich in einer Variante mit integriertem WLAN und/oder auch mit 4G/5G Mobilfunk Modem sowie auch VoIP Anschlüssen.
Eine Übersicht der 880er Modelle sowie die Datenblätter der 890er Modelle und der aktuellen ISR 900er sowie 1100er Modelle findet man auf der Cisco Webseite.
ISR Router besitzen durchgängig mindestens 4 integrierte Ethernet RJ-45 LAN Ports die VLAN fähig sind. Die 890er Modelle haben durchgängig 8 LAN Ports, die ebenfalls voll VLAN fähig und flexibel auch für zusätzliche WAN Anbindungen nutzbar sind. (Multi WAN-Port Feature).
Cisco 880er Modelle supporten bis zu 20 VPN Verbindungen gleichzeitig (890 supportet 50 Tunnel, 926 und 1112 bis zu 200 VPN Tunnel) und eignen sich damit für anspruchsvolle KMU Firmennetze, Telearbeiter, einer LAN zu LAN Firmenvernetzung auf ADSL/SDSL oder VDSL Basis oder dem eigenen privaten Heimnetzwerk.
ADSL/VDSL fähige Modelle haben allesamt ein Multimode Hybridmodem an Bord, was zudem SDSL fähig ist für Business Anschlüsse.
Mittlerweile sind die 890er 1Gig Modelle recht preiswert auf Auktionsplattformen wie z.B. eBay usw. zu erhalten. Neue Modelle u.a. sogar beim Discounter.
Die hier vorgestellte universelle Grundkonfiguration des Routers ist für beide vorgestellten xDSL Anbindungen (ADSL und VDSL) gleich. Sie unterscheidet sich lediglich in der Konfiguration der ADSL bzw. VDSL Modemeinstellung die unten in separaten Kapiteln vorgestellt wird.
Die Verbindung zum xDSL Anschluß (Telefondose TAE-F) erfolgt über einen handelsüblichen RJ-11 Port mit Mittelpin Belegung. Sofern der xDSL Anschluss noch mit TAE-F Dose ausgerüstet ist, dann mit einem handelsüblichen TAE-F auf RJ-11 Standard Kabel.
Das Tutorial zeigt eine Standardkonfiguration mit 2 angeschlossenen LAN Segmenten z.B. ein lokales Netzwerk und ein Gastnetz, aktivem DHCP und statischen DHCP Reservierungen z.B. für einen Server, NAS o.ä. und einer optionalen VPN Konfiguration mit IPsec oder L2TP VPN Protokoll.
Die Cisco ISR Router sind aktive VPN Router und supporten damit die remote VPN Einwahl für Home Office und mobile Mitarbeiter zum Datenaustausch oder die sichere Fernwartung.
Alles mit den üblichen onboard VPN Clients (L2TP) auf allen Endgeräten. VPNs auf L2TP Protokoll Basis nutzen so die jeweiligen onboard VPN Clients in jedem Betriebssystem und Smartphone und kommen ohne zusätzliche VPN Client Software aus.
Entfernte VPN Standorte bei Site-to-Site VPNs müssen dabei nicht zwingend mit Cisco Hardware ausgestattet sein. IPsec VPN Verbindungen sind problemlos zwischen allen VPN Routern/Firewalls die IPsec entweder mit IKEv1 oder IKEv2 beherrschen möglich.
Wichtig ist hierbei, das die eingesetzten Geräte (z.B. FritzBox, Lancom, NetGear, pfSense/OPNsense, Mikrotik, Microsoft, Linux, Apple Mac, StrongSwan usw.) der Gegenstelle diese VPN Protokolle ebenfalls beherrschen, was bei IPsec so gut wie immer der Fall ist.
Die weiterführenden Links am Ende weisen auf entsprechende VPN Praxistutorials hin die gemischte IPsec Standort- und Client VPN Lösungen mit entsprechenden Beispielkonfigurationen beschreiben.
Für die Router Modelle mit integriertem WLAN Accesspoint findet sich eine entsprechende WLAN Konfig im Abschnitt Wireless. Die Konfiguration ist zu denen dedizierter Cisco Accesspoints identisch.
Die initiale Konfiguration des Cisco Routers sollte immer über den seriellen Konsolen Port (Console) und dem mitgeliefertem seriellen, blauen Konsolen RS-232 Kabel mit RJ-45 Stecker und einem klassischen USB-Serial Adapter erfolgen. Alternative Terminalkabel haben den Adapter bereits im Kabel integriert.
Bei neueren Router Modellen ist die Konsole zusätzlich als USB Port verfügbar. Hier reicht ein normales Micro USB Kabel.
Als Terminal Programme nutzt man die bekannten Windows Klassiker PuTTY oder TeraTerm mit den Parametern 9600 Baud, N, 8, 1 (Keine Parity, 8 Bit, ein Stopbit) und schaltet alle Arten von Flow Control (Hardware, Software) AUS in den seriellen Port Settings der Terminalprogramme.
Bei den Terminalprogrammen ggf. die COM Ports durchprobieren (Windows) da sie nicht überall gleich sind.
Weiter hilft hier wie immer ein Blick in den Windows Geräte-Manager unter Serielle und LPT Ports.
Apple Mac Benutzer nehmen hier ZTerm (Shareware), ZOC oder das bordeigene screen Kommando und Linuxer haben mit minicom immer ein serielles Terminal gleich mit an Bord.
Wer keinen seriellen COM Port (DB-9 Stecker) mehr hat am Rechner, nutzt den oben genannten Seriell-USB Adapter.
Nicht ganz so sattelfeste Cisco IOS Kommando Nutzer finden HIER einen guten, grundlegenden Überblick für das Kommando Interface KnowHow. Bei Konfig Postings im Forum sollte man auf die Anonymisierung der Kennwörter achten bzw. auf das Vorhandensein des Kommandos service password-encryption.
Los gehts...
Allgemeine Router Grundkonfiguration
⚠️ Für die erhöhte Passwortsicherheit ist es ratsam ab Firmware Version 15.3.(3) unbedingt den Typ 9 der Passwortverschlüsselung zu verwenden. Das dazu benötigte Kommando zum Erstellen eines User Accounts mit Typ 9 Verschlüsselung und Admin Level 15 Zugriff lautet:
username <benutzername> privilege 15 algorithm-type scrypt secret <password>
und ist in den hier aufgeführten Konfigurationen entsprechend berücksichtigt.
IP Adress Translation (NAT)
❗️Ein Router muss die internen Netzwerke die in der Regel private, im Internet nicht geroutete RFC1918 IP Netze haben, auf eine öffentliche IP Adresse umsetzen damit diese im Internet geroutet werden können. Dies geschieht mittels IP Adress Translation (NAT) bei jedem handelsüblichen Router oder Firewall.Leider wird dieser Punkt in der Cisco Konfig oft übersehen diesen NAT Traffic entsprechend zu klassifizieren, denn der Router muss natürlich wissen was er übersetzen muss und was nicht. Die Klassifizierung geschieht bei Cisco über eine Accessliste.
Im Tutorial definiert diesen Traffic die Accessliste 101 die das lokale Netz und das Gastnetz fürs NAT klassifiziert. Die ACL Nummer oder Name ist frei wählbar.
Alle NAT relevanten Kommandos sind auch in fett hervorgehoben, da sie essentiell sind für die Funktion des Routers
Interner LAN Switch
Die ISR Router haben in der Regel mit den Ports x/0 bis x/3 einen internen Layer 2 VLAN Switch an Bord. Diese Switchports sind Layer 2 only und können ergo nicht direkt mit IP Adressen konfiguriert werden.Das eigentliche IP Routing Interface ist immer das auf diese Switchports gemappte VLAN x Interface. Auf diesem VLAN Interface werden alle IP und Routing relevanten Einstellungen zu dem dort anliegenden IP Netzwerk(en) gemacht. Im Default liegt das VLAN 1 Interface als Access VLAN (untagged) an allen Switchports an.
Hier im Beispiel sind es 2 aktive IP Netze mit dem VLAN 1 Interface (Lokales LAN) und dem VLAN 2 Interface (Gastnetz).
Basiskonfiguration
Die folgende Standard IP Basiskonfiguration des Cisco Routers ist in blau gehalten. Die zusätzlichen oder zu ändernden xDSL Modem spezifischen Abschnitte die für eine ADSL, SDSL Konfiguration erforderlich sind, sind jeweils rot eingefärbt. (VDSL hat ein eigenes Kapitel!)Optionale Kommandos die nicht zwingend für den Betrieb bzw. Konfig erforderlich sind, sind immer in (...) Klammern dargestellt oder entsprechend kommentiert. (Klammern bei Bedarf entfernen!) !
!
service timestamps log datetime localtime show-timezone year
service timestamps debug datetime localtime
service tcp-keepalives-in
service tcp-keepalives-out
no service pad
!
hostname Cisco_Router
!
security authentication failure rate 3 log
enable algorithm-type scrypt secret Geheim123
!
clock timezone CET 1 0
clock summer-time CEST recurring last Sun Mar 2:00 last Sun Oct 3:00
!
aaa new-model
aaa authentication login default local
aaa authorization network default local
aaa local authentication attempts max-fail 3
!
username admin privilege 15 algorithm-type scrypt secret Geheim123
!
no ip source-route
no ip gratuitous-arps
!
ip dhcp binding cleanup interval 180
(ip dhcp relay information trust all) Optional: <-- Nur wenn Cisco fremde Scopes bedienen soll (DHCP Relay). Sonst weglassen
ip dhcp excluded-address 192.168.100.1 192.168.100.149 <-- Schliesst diesen Adressbereich vom DHCP Pool AUS
ip dhcp excluded-address 192.168.100.200 192.168.100.254 (LAN DHCP Pool reicht somit von .150 bis .199 )
!
ip dhcp excluded-address 172.16.100.1 172.16.100.149 <-- Adress Pool für das Gastnetz (.150 bis .199)
ip dhcp excluded-address 172.16.100.200 172.16.100.254
!
ip dhcp pool Lokal
network 192.168.100.0 255.255.255.0
default-router 192.168.100.254
dns-server 192.168.100.254 <-- Weitere DNS Server werden durch Leerzeichen getrennt
(option 42 ip 192.168.100.254) <-- Optional: NTP Zeitserver IP
domain-name meinedomain.internal
!
ip dhcp pool Gastnetz
network 172.16.100.0 255.255.255.0
default-router 172.16.100.254
dns-server 172.16.100.254
domain-name gast.meinedomain.internal
!
ip dhcp pool WinServer <-- Beispiel f. Zuweisung von fester IP auf MAC Adresse (IP zu Mac Binding)
host 192.168.100.170 255.255.255.0
client-identifier 01b0.0c6c.01c4.d2 <-- Hardware Mac Adresse des Clients (vorn ID "01" beachten !)
(hardware-address b00c.6c01.c4d2) <-- Bei Client Mac Adressen die keinen HW_Identifier senden (Linux !)
(client-name winserver) <-- Übergibt Hostnamen an den/die Clients (Optional)
!
ip domain name meinedomain.internal
!
lldp run
no cdp run
!
⚠️ (Alle folgenden "ip inspect..." Kommandos entfallen vollständig wenn statt der klassischen, alten CBAC Firewall mit ip inspect Kommandos die u.a moderne, Zonen basierte ZFW Firewall Konfiguration umgesetzt wird! (Bei neueren ISR Modellen erfordert die Firewall Funktion ggf. eine Lizenz!))
!
ip inspect name myfw http
ip inspect name myfw https
ip inspect name myfw pop3s
ip inspect name myfw imaps
ip inspect name myfw esmtp
ip inspect name myfw sip <-- Firewall Application Gateway f. VoIP
ip inspect name myfw rtsp <-- Firewall Application Gateway f. VoIP
ip inspect name myfw icmp router-traffic
ip inspect name myfw tcp router-traffic
ip inspect name myfw udp router-traffic
!
controller VDSL 0
(firmware filename flash:VA_B_38V_d24m.bin) --> Optional! Nur 880er Vectoring Modem Firmware !
!
interface Ethernet0
no ip address
shutdown
!
interface BRI0
no ip address
shutdown
!
interface FastEthernet0
description Lokales LAN
no ip address
!
interface FastEthernet1
no ip address
!
interface FastEthernet2
no ip address
!
interface FastEthernet3 <-- LAN Port 4, hier Gastnetz anschliessen. (Kann entfallen wenn kein Gastnetz gewünscht.)
description Gastnetz
switchport access vlan 2 <-- Gastnetz Interface, UNtagged VLAN 2
no ip address
!
interface Vlan1
description Lokales LAN (FastEthernet0 bis 2)
ip address 192.168.100.254 255.255.255.0
ip nat inside <-- NAT Eingangsinterface
ip tcp adjust-mss 1452 <-- (⚠️ Nur bei Provider Anschlüssen mit PPPoE erforderlich! Sonst weglassen)
!
interface Vlan2
description Gastnetz (FastEthernet3)
ip address 172.16.100.254 255.255.255.0
ip access-group GASTNETZ in <-- (Optional: Ohne Gäste Beschränkungen oder ZFW Firewall weglassen!)
ip nat inside <-- NAT Eingangsinterface
ip tcp adjust-mss 1452
!
interface Dialer0
description xDSL PPPoE Internet Interface
ip address negotiated
ip access-group 111 in <-- Firewall CBAC Inbound Access Liste. (⚠️ Diese Zeile entfällt bei ZFW Firewall!)
mtu 1492
no ip redirects
no ip unreachables
no ip proxy-arp
ip verify unicast reverse-path
ip nat outside <-- NAT Ausgangsinterface
ip inspect myfw out <-- Firewall aktiv auf dem Internet Port. (⚠️ Diese Zeile entfällt bei ZFW Firewall!)
encapsulation ppp
dialer pool 1
ppp authentication pap callin
ppp pap sent-username 001234567890123456780001@provider.de password 1234567
(⚠️ T-Business SDSL verwendet hier = t-online-com/<nutzer>@t-online-com.de )
ppp ipcp dns request
ppp ipcp mask request
ppp ipcp route default <-- ⚠️ Dafür entfällt die statische Default Route!
!
ip dns server <-- Aktiviert den DNS Caching Server
!
ip nat inside source list 101 interface Dialer0 overload <-- NAT auf dem Dialer Interface für ACL 101 Traffic
!
ip access-list extended GASTNETZ <-- Optionale Gast ACL erlaubt nur DNS u. Web (ggf. um weitere Dienste erweitern !)
3 remark Gastnetz Zugang <-- ACL entfällt vollständig bei ZFW Firewall Konfig!
10 permit udp any eq bootpc any eq bootps
15 deny ip 172.16.100.0 0.0.0.255 192.168.100.0 0.0.0.255
20 permit tcp 172.16.100.0 0.0.0.255 any eq domain
25 permit udp 172.16.100.0 0.0.0.255 any eq domain
30 permit tcp 172.16.100.0 0.0.0.255 any eq www
35 permit tcp 172.16.100.0 0.0.0.255 any eq 443
!
ip access-list extended CLI-ACCESS <-- ACL steuert Konfigurations Zugriffsrecht a. d. Router.
3 remark Konfig Zugang ACL
10 permit tcp 192.168.100.0 0.0.0.255 any eq 22 <-- Erlaubt SSH Zugriff
15 permit udp 192.168.100.0 0.0.0.255 any eq snmp 10161 <-- Erlaubt SNMP und Secure SNMP Zugriff
(20 deny ip any any log-input) <-- Optional! Nur wer verbotene Telnet bzw. SSH Login Versuche mitloggen will!
!
access-list 101 permit ip 192.168.100.0 0.0.0.255 any <-- ACL klassifiziert NAT relevanten Traffic.
access-list 101 permit ip 172.16.100.0 0.0.0.255 any
!
⚠️ Die folgende ACL 111 entfällt vollständig wenn statt der CBAC Firewall Variante (ip inspect Kommandos!) die u.a modernere, Zonen basierte ZFW Firewall Konfiguration umgesetzt wird!
!
access-list 111 permit icmp any any administratively-prohibited <-- Lässt wichtige ICMP Steuerpakete durch die Firewall passieren.
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 5060 any <-- VoIP (SIP) Port 5060. (Entfällt ohne VoIP Anlage, Telefone etc.) im lokalen LAN
(access-list 111 permit udp any eq bootps any) <-- Nur wenn Internet Port per DHCP IP Addresse bezieht ! Sonst weglassen !
access-list 111 deny ip any any (log) <-- (*1)"Log" Siehe u.a. Anmerkung: Parameter nur verwenden wenn man temporär Angriffe aus dem Internet protokollieren möchte. (ACL Logging kostet Performance !)
!
!
dialer-list 1 protocol ip list 101 <-- Startet die PPPoE Verbindung für ACL 101 definierten Traffic
!
ntp server de.pool.ntp.org source Dialer0 (*2) <-- Definiert externen NTP Zeitserver
ntp update-calendar <-- Setzt zusätzlich die interne HW Uhr auf NTP Zeit
!
ip ssh version 2
ip ssh time-out 30
ip ssh authentication-retries 3
!
banner exec #
Sie sind verbunden mit VTY $(line) auf dem Router $(hostname)
#
!
line vty 0 4
access-class CLI-ACCESS in <-- Telnet / SSH Zugriff nur aus lokalem LAN möglich (ACL "CLI-ACCESS")
login local
transport input telnet ssh <-- Telnet / SSH Zugriff. Ist zur Sicherheit nur SSH gewünscht "telnet" hier weglassen.
!
end
(*1) Der Parameter "log" am Ende des letzten Filter Statements der ACL 111 deny ip any any zeigt alle unerlaubten externen Zugriffe im Router Log an und damit diejenigen weltweit, die versuchen den Router anzugreifen.
Es ist sehr interessant (und auch erhellend) das hohe Ausmaß dieser Angriffsversuche einmal live zu sehen, wenn man show logg eingibt oder sich die Syslog Messages des Routers schicken_lässt.
Wen es "nervt" und das Log zu groß wird (denn es gibt sehr sehr viele dieser Angriffe im Sekundentakt !) und wer Wichtigeres im Logging sehen möchte, kann das "log" Statement natürlich auch weglassen aus der ACL Definition.
Letztlich macht das ACL Logging den Router langsamer (Performance !), deshalb ist es besser auf lange Sicht die Logging Statements in den ACLs immer zu deaktivieren!
(*2) de.pool.ntp.org ist der ntp.org Serverpool für DE. Der Cisco arbeitet dann intern selber als NTP Zeitserver für Endgeräte (Siehe "Option 42" oben in der DHCP Server Konfiguration!)
Anmerkung zur DNS Server Konfiguration des Routers:
Die o.a. Grundkonfiguration geht davon aus das PPPoE oder DHCP am WAN Port genutzt wird. Damit lernt der Cisco Router die DNS Server IP Adressen des jeweiligen Provider Anschlusses immer automatisch.
Im Falle einer statischer WAN Port IP Adressierung muss man natürlich die DNS Server IP dann statisch mit dem Kommando:
ip dns-name server <ip_addresse_dns> angeben!
Bei dynamischen Zugängen mit PPPoE, DHCP usw. entfällt diese Angabe! Es sei denn man bevorzugt einen anderen DNS Server als den, den der Provider dynamisch übermittelt.
Jetzt ist der richtige Zeitpunkt für ein write mem Befehl um diese Konfig im Router Flash permanent zu sichern. Ohne Sicherung ins Flash wäre die Konfig nach einem Reboot verloren !
WAN / Internet xDSL Modem Interface Setup mit VLAN Tag
Intern ist im Cisco das integrierte xDSL Hybridmodem im ADSL2+ Modus auf das ATM0 Interface des Routers gemappt und bei VDSL Betrieb ist es das Ethernet0 Interface. Es gilt also:
- ATM Interface = nur ADSL Modem Verbindung
- Ethernet0 Interface = nur VDSL Modem Verbindung
Der Großteil aller Provider wie auch die Telekom (D) hat seit 2019 ihre Anschlüsse auf BNG umgestellt! Dies erfordert in der Regel ein VLAN Tagging auf dem WAN/Internet Interface. (VLAN ID 7 bei der Telekom)
Daher muss die Konfiguration des Internet Interfaces bei einem BNG Anschluss entsprechend angepasst werden, so das der Router ein VLAN 7 Tag mitschickt:
interface ATM0
description DTAG-BNG ADSL2+
no ip address
no atm ilmi-keepalive
!
interface ATM0.7 point-to-point
pvc 1/32
bridge-dot1q encap 7
pppoe-client dial-pool-number 1
!
Das o.a. Beispiel gilt für einen ADSL Anschluss.
VDSL Konfiguration
VDSL Pakete müssen in Richtung Provider, wie oben bei ADSL+ auch, ebenfalls mit einem 802.1q VLAN Tag versehen werden ! Bei der Telekom (D) ist das die VLAN ID 7. (ggf. andere bei alternativen Providern!)
Das interne VDSL Modem ist, wie oben schon angemerkt, physisch an die interne Router Ethernet Schnittstelle Ethernet0 gebunden und muss für VDSL damit eine tagged VLAN Konfiguration bekommen.
Dies bewirkt ein sog. Subinterface Ethernet 0.7 in der VDSL Konfig auf dem eigentlichen physischen Interface Ethernet0.
Wird der Router im VDSL Mode betrieben, kann (und sollte) das ATM0 Interface (ADSL) mit "Shutdown" per Konfig deaktiviert werden und das ATM Subinterface mit no interface ATM0.x point-to-point entfernt werden !
Da ADSL mehr und mehr ausstirbt ist also primär die VDSL Konfig und damit das VDSL Modem Interface Ethernet0 relevant.
Die im Folgenden rot markierten Kommandos müssen bei Einsatz eines VDSL Anschlusses hinzugefügt werden. Das ATM Interface (ADSL) wird dann abgeschaltet (shutdown).
!
-- Standard Grundkonfiguration wie oben --
!
controller VDSL 0
firmware filename flash:VA_B_38V_d24m.bin --> Optional nur f. C880 Modell ! Supportet VDSL Vectoring beim 880er Modell !
!
interface Ethernet0
no ip address
no shutdown
!
interface Ethernet0.7
description VDSL Internet Verbindung - VLAN 7 tagged
encapsulation dot1Q 7
pppoe enable group global
pppoe-client dial-pool-number 1
!
interface ATM0
no ip address
shutdown
pvc 1/32
pppoe-client dial-pool-number 1
!
-- Die restliche Konfiguration nach dem Interface ATM0 ist von der o.a. Standart Grundkonfiguration zu übernehmen. --
(Ein show ip interface brief zeigt die korrekte Internetverbindung zum jeweiligen Provider an.)
⚠️ Das zusätzliche VLAN Tagging mit 4 Bytes Overhead hat auch Einfluss auf die MTU Werte bzw. das MSS Setting. Dieses muss entsprechend angepasst werden mit 1488 (MTU, Dialer) und 1448 (MSS f. int. LAN, VPN). Siehe zum Thema MTU auch hier.
Zudem ist sicherzustellen das keines der Interfaces im sog. shutdown Status ist !!
Shutdown bedeutet das das Interface deaktiviert ist. Dies kann immer mit dem Kommando show ip interface brief geprüft werden.
Auch wenn man sich die aktuelle Konfig mit show run ansieht, dann sollte keines der Interfaces im "shutdown" Modus sein. Ausgenommen natürlich NICHT verwendete Interfaces wie z.B. das ATM Interface wenn man VDSL nutzt !
Wenn dennoch eins der aktiven Interfaces ein shutdown anzeigt, bekommt man das mit:
conf t
interface xyz
no shutdown
<ctrl z>
wr
...schnell wieder gefixt.
Man kann später, wenn alles rennt, alle nicht benutzten Interfaces natürlich in den Shutdown versetzen. Beim Aufsetzen der Konfig und Testen kann das aber fatale Fehler ergeben so das man darauf während der Grundkonfiguration besser erstmal verzichtet !
VDSL VLAN Tags bei alternativen VDSL Providern
Andere VDSL Provider nutzen statt der 7 bei der Telekom oft andere VLAN ID Tags ! Bei Vodafone z.B. ist das die VLAN ID 132.Die korrekte Port Konfiguration für Vodafone VDSL (VLAN Tag 132) sieht dann z.B. entsprechend so aus:
!
interface Ethernet0
no ip address
no shutdown
!
interface Ethernet0.132
description VDSL Internet Verbindung - Vodafone
encapsulation dot1Q 132
no ip route-cache
pppoe enable
pppoe-client dial-pool-number 1
Vodafone Besonderheiten
Die folgenden Informationen gelten ggf. analog für andere Wiederverkäufer ohne eigenes Netz:Vodafone ist in einigen Fällen Wiederverkäufer von Telekom VDSL Leitungen. In diesem Fall gilt dann weiterhin das VLAN 7 Tag !
Vodafone Usernamen sehen auf solchen Links dann so aus: vodafone-vdsl.komplett/ad123456789
Siehe dazu auch hier.
⚠️ Noch ein warnendes Wort zu Vodafone xDSL Anschlüssen !
Vodafone nutzt statt PAP eine CHAP Authentisierung auf dem PPPoE Interface (Dialer 0) ! Die Dialer 0 Konfiguration muss deshalb bei Vodafone Anschlüssen um die folgenden 4 Kommandos (fett) erweitert werden damit die PPPoE Einwahl auch bei Vodafone fehlerfrei klappt:
(PPP Standardkommandos der Übersicht halber weggelassen) :
!
interface Dialer0
description xDSL Einwahl Interface Vodafone
ip address negotiated
...
ppp authentication chap pap callin
ppp chap hostname vodafone-vdsl.komplett/vb123543
ppp chap password Geheim123
ppp pap sent-username vodafone-vdsl.komplett/vb123543 password Geheim123
...
Bei M-Net in München ist die VLAN ID z.B. 40, Netcom Kassel verwendet ebenfalls das VLAN 132 für die PPPoE Einwahl wie Vodafone, Wilhelm.Tel z.B. 2526.
Es kann also nicht schaden sich vorher über die VLAN ID des Providers zu informieren. In der Regel findet man alle diese Angaben auf deren Support Webseite.
Swisscom (CH) Besonderheiten
Interessant ist die Anbindung von Swisscom VDSL Anschlüssen in der Schweiz. Die Swisscom realisiert die Anbindung ohne PPPoE und ohne VLAN Tag mit einem DHCP Client. Zusätzlich fordert die Swisscom das für alle Fremdrouter mit xDSL (VDSL / ADSL) Anschluß die DHCP Option 60 gesetzt sein muss.Der DHCP Client muss also eine dedizierte Option 60 mit dem vorgeschriebenen Wert 100008,0001 an die Swisscom mitgeben um so eine gültige DHCP IP Adresse am WAN Port zu erhalten.
Der Cisco Router setzt die erforderliche DHCP Client Option 60 mit dem Kommando ip dhcp client class-id <string> am WAN Interface.
Dadurch das PPPoE als WAN Protokoll und damit auch das Dialer Interface hier entfällt, wird diese DHCP Option direkt auf dem virtuellen VDSL Modem Interface Ethernet0 konfiguriert, welches in diesem Setup das WAN/Internet Interface des Routers darstellt.
Diese WAN Port DHCP Konfiguration unterscheidet sich bis auf die erforderliche Class-ID (Option 60), nicht groß von einer klassischen LAN Portkonfiguration im DHCP Client Mode.
interface Ethernet0 --> Indexnummer je nach Routermodell anpassen
description Swisscom (CH)
ip dhcp client broadcast-flag clear
ip dhcp client class-id 100008,0001
ip address dhcp
no ip redirects
no ip unreachables
ip nat outside
(Die Class ID setzt sich zusammen aus dem von der Swisscom vorgeschriebenen, festen Wert 100008,0001)
Swisscom Glasfaser (FTTH)
Die Glasfaseranschlüsse der Swisscom erfordern im Gegensatz zu den klassischen xDSL Anschlüssen einen VLAN 10 Tag. Hier wird, wie auch schon oben, mit einem Subinterface auf dem Modem Interface gearbeitet welches dann diesen Tag an den Provider liefert.interface Ethernet0 --> Indexnummer je nach Routermodell anpassen
no ip address
!
interface Ethernet0.10
description Swisscom (VLAN10 Tag)
encapsulation dot1Q 10
ip dhcp client broadcast-flag clear
ip dhcp client class-id 100008,0001
ip address dhcp
no ip redirects
no ip unreachables
ip nat outside
Glasfaser mit SFP Optik (FTTH, GPON)
Cisco Router wie z.B. der Cisco 896 / 897 oder der 1100er u.a. besitzen onboard einen optionalen SFP Port in dem man ein GPON SFP Modul wie z.B. das Zyxel PMG3000-D20B ohne Umweg über einen Glasfaser ONT (Mietkosten) direkt am Glasfaser / FTTH Anschluss betreiben kann.
Damit der Cisco herstellerfremde SFP Optiken wie das o.a. Zyxel SFP Modul akzeptiert muss vorab global das Kommando service unsupported-transceiver konfiguriert werden! Die SFP Optik wird dann fehlerlos erkannt:
Cisco#sh inventory
NAME: "subslot 0/0 transceiver 0", DESCR: "GE ZX"
PID: PMG3000-D20B , VID: V1.0 , SN: S234107501234
Cisco#sh int gig 0/0/0 transceiver
The Transceiver in slot 0 subslot 0 port 0 is enabled.
Module temperature = +45.847 C [Range: not specified]
Transceiver Tx supply voltage = 3300.0 mVolts [Range: 3100.0 to 3500.0 mVolts]
Transceiver Tx bias current = 13660 uAmps [Range: 3000 to 70000 uAmps]
Transceiver Tx power = 3.0 dBm [Range: 0.5 to 4.5 dBm]
Transceiver Rx optical power = <-40 dBm [Range: -27.0 to -8.0 dBm]ITU Channel
Transceiver is internally calibrated.
If device is externally calibrated, only calibrated values are printed.
++ : high alarm, + : high warning, - : low warning, -- : low alarm.
NA or N/A: not applicable, Tx: transmit, Rx: receive.
mA: milliamperes, dBm: decibels (milliwatts).
Optical Optical
Temperature Voltage Current Tx Power Rx Power
Port (Celsius) (Volts) (mA) (dBm) (dBm)
--------- ----------- ------- -------- -------- --------
Gi0/0/0 45.8 3.30 13.6 3.0 -40.0 WAN Interface mit DHCP (Kabel TV, Glasfaser etc.)
Kabel TV oder FTTH (Glasfaser) Anschlüsse arbeiten je nach Provider am WAN Port oftmals als DHCP Client statt PPPoE. Hier entfällt dann das PPPoE/Dialer Interface.
Entsprechend muss dann auch DHCP durch die Firewall (nur CBAC Version!!) erlaubt werden, ansonsten scheitert die IP Adressvergabe per DHCP am WAN/Internet Port !
Eine zusätzliche Regel:
access-list 111 permit udp any eq bootps any
Sorgt dann in der ACL 111 dafür das auch DHCP klappt. Eine entsprechende Ethernet Port Konfig sieht so aus: (Beispiel: Internet auf Port FastEthernet 0):
!
interface FastEthernet0
description Internet (DHCP Client)
switchport access vlan 99
no ip address
!
interface vlan 99
description Internet Interface
ip address dhcp
ip access-group 111 in <-- Firewall CBAC Inbound Access Liste
ip dhcp client broadcast-flag clear
no ip redirects
no ip unreachables
no ip proxy-arp
ip nat outside
ip inspect myfw out <-- Firewall aktiv auf Port
Die entsprechende Einstellung bei Verwendung der ZFW Firewall mit DHCP wird im ZFW Kapitel weiter unten beschrieben.
Router Modelle mit SFP Port supporten auch GPON SFPs sofern der Provider diese zulässt.
Die Firewall (CBAC) richtig einstellen
⚠️ Die Access Liste 111 am Internet Port funktioniert NUR im Zusammenhang mit der konfigurierten CBAC Router Firewall, also dem Aktivieren der FW mit dem Kommando "ip inspect myfw out" auf dem Dialer Interface !!
Sie darf nicht im Mischbetrieb mit der unten beschriebenen, moderneren ZoneBased Firewall verwendet werden. Auch nicht einzelne Zeilen!
Man muss sich also bei Konfiguration der Firewall für ein FW Konzept entscheiden. Entweder CBAC oder ZFW !
Empfohlen wird grundsätzlich nur noch ein modernes ZFW Firewall Konzept zu verwenden, da die CBAC Firewall langfristig aus IOS entfernt wird.
Betreibt man den Router gänzlich OHNE eine dieser beiden Firewall Optionen muss die Access Liste 111 vollständig weglassen werden oder man reduziert sie auf das Blocken von Ping, Traceroute und Redirect mit:
access-list 111 deny icmp any any echo <-- Weglassen wer den Router aus dem Internet pingen möchte (Sicherheit !)
access-list 111 deny icmp any any traceroute
access-list 111 deny icmp any any redirect
access-list 111 permit ip any any
Der Betrieb des Routers am Internet ohne aktive Firewall und nur mit der NAT Firewall ist möglich aber aus naheliegenden Gründen natürlich nicht ideal.
Mit der aktivierten CBAC Firewall Funktion wird die o.a. ACL 111 dynamisch, sessionbasiert bei ausgehenden Sessions geöffnet. Siehe auch:
http://www.cisco.com/en/US/products/sw/secursw/ps1018/products_tech_not ...
Ohne konfigurierte Firewall Funktion passiert diese dynamsiche Öffnung der ACL 111 nicht und Antwortpakete aus dem Internet werden dann blockiert. Die ACL 111 ist also immer an die CBAC Firewall gebunden.
Wer z.B. einen internen Web Server im lokalen LAN per Port Forwarding vom Internet aus mit aktiver CBAC Firewall erreichen will, muss den Zugriff mit einer zusätzlichen ACL 111 Regel explizit erlauben.
Für HTTP und HTTPS sind das z.B. die folgenden zusätzlichen Statements in der ACL 111:
access-list 111 permit tcp any any eq http
access-list 111 permit tcp any any eq 443
Erst dann kann man intern, im lokalen LAN, liegende eigene FTP oder HTTP Server (Web Server, NextCloud etc.) erreichen ! Einen entsprechenden statischen Eintrag für das Port Forwarding natürlich vorausgesetzt.
Das Port Forwarding mit der ZFW Firewall beschreibt ein separates Forentutorial
VoIP mit "All IP" Anschlüssen (Annex J)
Von Cisco ist das entsprechende Modell C886VA und 890er Modell in einer Annex-J-Variante erhältlich C886VA-J-K9.
Besitzer der nicht J Version müssen aber keinerlei Sorge haben !
Die reguläre Annex-B-Variante Cisco C886VA-K9 ist auch voll am Annex-J-fähigen Anschluß funktionsfähig, mit geringfügig reduziertem Upstream. Ebenso die Annex A Variante.
Da die aktuellste xDSL-Modem Firmware Vectoring supportet sollte, wenn immer möglich, diese auch verwendet werden. Ältere Modem Firmware, speziell die im IOS Firmware Image embeddete Modem Firmware, quittiert dies durch den fehlenden Vectoring Support oft mit deutlich geringeren Connect Raten am DSLAM !
Die embeddete Modem Firmware z.B. der 15.4.3.M7 Version hat bessere Connect Raten als z.B. der Patch davor.
Gleiches gilt für den Cisco C896VA sowie das Cisco EHWIC-VA-DSL-B Modul (WIC) in den 1800er und 1900er Modellen.
Best Practice ist also immer die aktuelle Modem Firmware zu verwenden und separat vom Flash zu laden.
Die aktuelleste Modem Firmware (derzeit für den 886VA VA_B_38V_d24m.bin (Release B2pvC038v)) lädt man von der Cisco Support Seite und lädt sie über einen TFTP Server (z.B. HIER beschrieben mit dem Komando copy tftp flash: in den Flash Speicher des Routers.
Alternativ besteht die Möglichkeit es einfach per USB Stick über die im Router integrierte USB Buchse zu laden:
Cisco886va#sh flash:
-#- --length-- -----date/time------ path
1 48369856 Aug 25 2018 12:13:40 +02:00 c880data-universalk9-mz.156-3.M5.bin
2 2310912 Sep 2 2017 10:09:20 +02:00 VA_B_38V_d24m.bin
71753728 bytes available (56532992 bytes used)Dann passt man die Konfig des VDSL Controllers entsprechend an um die Firmware zu laden:
!
controller VDSL 0
firmware filename flash:VA_B_38V_d24m.bin
!
Mit dem Kommando show controllers vdsl 0 überprüft man das korrekte Laden der FW:
Cisco886va#sh controllers vdSL 0
Controller VDSL 0 is UP
Daemon Status: Up
Modem Status: TC Sync (Showtime!)
DSL Config Mode: AUTO
Trained Mode: G.993.2 (VDSL2) Profile 17a
Full inits: 2
Failed full inits: 0
Short inits: 0
Failed short inits: 1
Firmware Source File Name
-------- ------ ----------
VDSL user config flash:VA_B_38V_d24m.bin
Modem FW Version: 170321_1253-4.02L.03.B2pvC038v.d24m
Modem PHY Version: B2pvC038v.d24m Bitte zum Thema "richtige Modem Firmware" den Thread von @dog unten in den Weiterführenden Links lesen !
Die aktuelle Modem Firmware VA_A_39m_B_38u_24h.bin ist eine von der Telekom zertifizierte Firmware für VDSL Anschlüsse in D und sollte bevorzugt verwendet werden ! (Siehe Modem Firmware Release Notes).
Auch wenn der Router kein integriertes VoIP Telefonie Gateway hat (Cisco hat dafür andere Modelle) kann man ihn dennoch problemlos mit den üblichen VoIP Adaptern von Cisco, Grandstream, Gigaset GoBox-100 usw. betreiben.
Der Adapter wird einfach ins lokale LAN gehängt, die bestehenden analogen Telefone und DECT Telefone bzw. Fax dort angeschlossen und schon ist man mit den gewohnten Telefonen wieder per VoIP online und erreichbar.
Noch vorteilhafter ist natürlich eine kleine VoIP Telefon Anlage im lokalen LAN wie z.B. die Auerswald_C3000 oder C4000 die erheblich mehr VoIP Telefonkomfort inklusive Fax und Voice Mailboxen mit Mail Forward usw. und die Integration vorhandener analoger oder ISDN Telefone ermöglicht.
Oder last but not least man nimmt die all Cisco Lösung und richtet sich auch die VoIP Telefonie mit preiswerten Cisco Telefonen ein wie z.B.:HIER beschrieben.
IPv6 Protokoll (Dual Stack) aktivieren
So gut wie alle Internet Provider supporten heutzutage das IPv6 Protokoll in einem Dual Stack. Dual Stack bedeutet das klassisches IPv4 und IPv6 auf dem Router parallel koexistieren. Moderne Betriebssysteme bevorzugen allesamt den IPv6 Betrieb. Bei vielen Providern ist es sogar Standard da diese aus Mangel an IPv4 Adressen keinen IPv4 Support mehr zum Endkunden realisieren sondern nur noch IPv6 (DS-Lite mit CGN).
IPv6 hat den Vorteil das es dort kein NAT (Network Adress Translation) mehr gibt, ferner besteht keine Adressknappheit mehr wie bei IPv4.
Damit entfallen dann alle Problematiken mit Port Forwarding und auch die, die man in CGN Netzen (Provider NAT) mit DS-lite kennt. Jeder bekommt automatisch vom Provider sein eigenes bzw. mehrere öffentliche IPv6 Netzwerke zugeteilt. Dadurch ist mit IPv6 immer eine direkte Verbindung aus dem Internet möglich.
Umso mehr ist deshalb natürlich die Firewall Funktion für IPv6 gefordert !
Wo vorher ein Großteil der Netzwerk Sicherheit bequem auf die NAT Funktion abgewälzt wurde, entfällt das nun bei IPv6 komplett und die Firewall muss allein für die Zugangssicherheit des lokalen IPv6 Netzes sorgen. Sie ist also ein sehr wichtiger und zentraler Punkt der IPv6 Konfiguration bzw. Sicherheit !
Genau aus diesem Grund sollte das moderne, Zonen basierte ZFW Firewall Konzept verwendet werden. Alles was dort für IPv4 eingestellt ist gilt automatisch immer auch für IPv6 !
Daher die gute Nachricht: An der Firewall muss für IPv6 nichts mehr extra eingestellt werden!
Die folgenden IPv6 Kommandos werden einfach der bestehenden globalen oder Interface spezifischen Konfiguration des Dialer0 bzw. WAN Interfaces (Internet) und VLAN1 (lokales LAN) Interfaces hinzugefügt.
Es lohnt sich für IPv6 gerüstet zu sein! Los gehts...
Zuerst wird global IPv6 Routing aktiviert auf dem Router und der lokale DHCPv6 Server aktiviert der die per Prefix Delegation vom Provider vergebenen IPv6 Adressen an die Endgeräte im lokalen LAN verteilt:
!
ipv6 unicast-routing
ipv6 cef
ipv6 dhcp pool DHCPv6
import dns-server
domain-name meinedomain.internal
(sntp address 2003:2:2:140:194:25:134:196) Optional: NTP Server ntp1.t-online.de
(prefix-delegation pool v6pdpool) Optional !!: Nur wer Prefixes an lokale v6 Router o. Firewall weiterreichen will. Sonst weglassen !!
Weiter geht es mit der Interface Konfiguration vom Internet Interface und vom lokalen LAN Interface:
!
interface Dialer0
description xDSL PPPoE Interface Internet
ipv6 address autoconfig default
ipv6 enable
no ipv6 redirects
no ipv6 unreachables
ipv6 nd autoconfig default-route
ipv6 nd ra suppress
ipv6 verify unicast reverse-path
ipv6 dhcp client pd provider-v6-prefix (rapid-commit)
Sollte der Provider mit DHCPv6 keine two-message exchange Option supporten, lässt man hier den Parameter "rapid-commit" weg!
!
interface Vlan1
description Lokales LAN (FastEthernet0 bis 2)
ipv6 address provider-v6-prefix ::1:0:0:0:1/64 (Hier /64 Maske nach Provider Prefix Vorgabe ggf. anpassen. Beispiel /56 PD Telekom)
ipv6 enable
ipv6 nd other-config-flag
ipv6 nd router-preference High
ipv6 dhcp server DHCPv6 rapid-commit allow-hint
(ipv6 address FE80:BADE:AFFE:CAFE::1 link-local) --> Optional: Nur wer eigene v6 Link Local Adressen FE80:: vergeben möchte !
⚠️ Je nachdem welches Firewall Konzept benutzt wird muss am WAN Port eingehend UDP 546 (DHCPv6 Protokoll) erlaubt sein. DHCPv6 muss die Firewall eingehend passieren können damit die IPv6 Prefix Delegation am WAN/Internet Interface sauber funktioniert!
Das Kapitel "Zone Based Firewall" weiter unten im Tutorial beschreibt das richtige IPv6 Setup dafür !
Wer möchte kann natürlich auch noch das VLAN 2 (Gastnetz) mit IPv6 ausstatten:
!
interface Vlan2
description Gastnetz (FastEthernet3)
ipv6 address provider-v6-prefix ::2:0:0:0:1/64
ipv6 enable
ipv6 nd router-preference High
ipv6 nd ra dns server 2003:180:2:3000::53
ipv6 nd ra dns server 2003:180:2:4000::53
(ipv6 address FE80:BAD:BEEF:CAFE::2 link-local) --> Optional: Nur wenn eigene Link Local Adresse gewünscht. Sonst weglassen. ##
👉🏽 Das Gast Interface zeigt hier eine vereinfachte Variante wie die DNS Server (hier Telekom) über IPv6 Router Advertisements (RA) an die Clients gesendet werden. Für einfache IPv6 Segmente ist dies völlig ausreichend. DHCPv6 ist lediglich erforderlich wenn intern per PD weitere v6 Netze an andere interne Router oder Firewalls weitergeben werden sollen. (Siehe zu der Thematik auch hier und Folgekapitel)
Mit show ipv6 interface kann man dann überprüfen ob es geklappt hat und der Router eine IPv6 Adresse bekommen hat:
cisco_router#show ipv6 interface
Dialer0 is up, line protocol is up
IPv6 is enabled, link-local address is FE80::CAFE:BADE:AFFE:123
No Virtual link-local address(es):
Description: xDSL Einwahl Interface Internet
Stateless address autoconfig enabled
Global unicast address(es):
2010:34:17BDF:2C5B:EAD6:F7FD:EF28:1F70, subnet is 2010:34:17BDF:2C5B::/64 [EUI/CAL/PRE]
valid lifetime 14259 preferred lifetime 1659
Joined group address(es):
Die korrekte v6 Prefix Delegation überprüft man mit show ipv6 dhcp int dialer0
Entsprechend klappt dann auch ein IPv6 Ping vom Router selber:
cisco_router#ping ipv6 www.heise.de
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2A02:2E0:3FE:1001:7777:772E:2:85, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 12/12/16 ms
Und dann natürlich auch vom lokalen Netzwerk auf einen IPv6 Server im Internet:
C:/Rechner/> ping6 www.heise.de
PING6(56=40+8+8 bytes) 2010:34:17BDF:2C5C:EAD6:F7FD:EF28:1234 --> 2a02:2e0:3fe:1001:7777:772e:2:85
16 bytes from 2a02:2e0:3fe:1001:7777:772e:2:85, icmp_seq=0 hlim=57 time=15.341 ms
16 bytes from 2a02:2e0:3fe:1001:7777:772e:2:85, icmp_seq=1 hlim=57 time=15.848 ms
16 bytes from 2a02:2e0:3fe:1001:7777:772e:2:85, icmp_seq=2 hlim=57 time=14.812 ms Damit ist die IPv6 Konfig abgeschlossen.
Ggf. muss man das Dialer Interface einmal auf shut und danach wieder no shut setzen um eine neue PPPoE Negotiation und damit die Vergabe der IPv6 Adresse auszulösen. Ein einfacher Reboot des Routers nach vorheriger Sicherung der Konfig mit write mem tut es auch.
IPv6 Prefixes im lokalen LAN weiterverteilen
Das zusätzliche Kommando ist optional und nur dann erforderlich, wenn Prefixes im lokalen LAN per DHCPv6 weitergreicht werden sollen an weitere IPv6 Router. Der Beispiel Prefix hier ist nur ein Beispiel und muss auf den eigenen angepasst werden!ipv6 local pool v6pdpool 2003:BB:123:7B3A::/56 60
Dieses Kommando vergibt einen /60er Prefix aus dem vom Provider erhaltenen /56er Prefix per eigener Delegation weiter.
WLAN Konfiguration bei integriertem AP
Der Cisco 886va ist auch in einer WLAN Version erhältlich als Cisco886vaw. Unterschied zum 886va ist lediglich nur ein integrierter 2,4Ghz WLAN Access Point wie man es von gewöhnlichen Consumer xDSL Routern auch kennt. Die 890er Modelle haben einen Dual Radio AP mit 2,4 und 5 Ghz. Die o.a. Grundkonfiguration bleibt immer identisch bzw. gilt auch für andere Router Modelle.
Der integrierte WLAN Accesspoint ist dabei, WLAN-Router üblich, mit einer Bridge an ein virtuelles Gigabit Interface angehängt, was man je nach Bedarf mit einer Single SSID oder mit Multi SSIDs in ein oder mehrere LAN oder VLAN Segmente per Konfig hängen kann.
Damit ist auch dieser Router in der Lage mit einem einzigen physischen WLAN Accesspoint mehrere unabhängige virtuelle WLANs aufzuspannen die man in unterschiedliche Netz Segmente legen kann. (z.B. Gast- und Privat oder Firmen WLAN)
Somit sind kostengünstig 2 und mehrere WLANs mit einer Hardware zu realisieren z.B. in einem Firmenumfeld mit einem gesicherten Mitarbeiter WLAN und einem abgeschotteten Gäste WLAN mit Hotspot.
Der in_diesem_Tutorial beschrieben ist und entspricht damit der klassischen Standard Cisco IOS Konfiguration auf allen High End Accesspoints der Aironet Serie die es mittlerweile ebenfalls recht preiswert über Auktionsplattformen gibt.
Natürlich hat der AP auch ein entsprechendes grafisches Web Interface welches die WLAN Konfiguration erheblich erleichtert für Admins die nicht IOS affin sind. Allerdings ist dieses WebGUI erst erreichbar mit einer entsprechenden IP Konfiguration des WLAN AccessPoint Interfaces.
Als ersten Schritt gibt man dem WLAN AP Interface eine IP. Da diese in der Regel im lokalen LAN (VLAN1) liegt kann dies unnumbered erfolgen.
interface Vlan1
description Lokales LAN
ip address 192.168.100.254 255.255.255.0
ip nat inside
ip tcp adjust-mss 1448
!
interface wlan-ap0
description Management Interface des internen WLAN APs
ip unnumbered Vlan1
!
Alternativ mit einer statischen IP außerhalb des DHCP LAN Adresspools:
interface wlan-ap0
description Management Interface des internen WLAN APs
ip address 192.168.100.253 255.255.255.0
!
Jetzt kann man mit dem Kommando service-module wlan-ap 0 session sich auf den internen Accesspoint verbinden.
Da das Kommando recht kryptisch ist und sich das keiner lange merken kann, kann man einen Kommando Alias dafür anlegen mit
alias exec zumwlanap service-module wlan-ap 0 session
Nun reicht die Eingabe des Kommandos zumwlanap um auf das WLAN AP Kommandointerface zu gelangen:
cisco887vaw#zumwlanap
Trying 192.168.100.254, 2002 ... Open
Connecting to AP console, enter Ctrl-^ followed by x,
then "disconnect" to return to router prompt
C
% Password change notice.
-----------------------------------------------------------------------
Default username/password setup on AP is cisco/cisco with privilege level 15.
It is strongly suggested that you create a new username with privilege level
15 using the following command for console security.
username <myuser> privilege 15 secret 0 <mypassword>
no username cisco
Replace <myuser> and <mypassword> with the username and password you want to
use. After you change your username/password you can turn off this message
by configuring "no banner login" and "no banner exec" in privileged mode.
-----------------------------------------------------------------------
User Access Verification
Username: Der Default Username ist cisco mit dem Default Password cisco bzw. Cisco (großes "C")!
⚠️ Mit der Eingabe von ctrl ^ und x (oder ctrl, shift 6 und x) und dann der Eingabe von disconnect
kommt man immer wieder auf den Router Kommando Prompt zurück.
Mit der nun folgenden IP Adressierung des internen APs ist diese Prozedur aber dann zukünftig nicht mehr nötig. Dann ist der interne Accesspoint bequem aus dem lokalen LAN direkt zu erreichen per Telnet (PuTTY oder TeraTerm) oder per Web Browser.
Eine funktionsfähige, einfache WLAN Konfiguration mit WPA-2 Sicherung und WLAN SSID (Name) Bitschleuder lautet folgendermaßen:
!
service timestamps log datetime localtime show-timezone year
service timestamps debug datetime localtime
!
hostname ap
!
aaa new-model
clock timezone CET 1 0
clock summer-time CEST recurring last Sun Mar 2:00 last Sun Oct 3:00
ip domain name meinedomain.internal
!
dot11 syslog
!
dot11 ssid Bitschleuder
authentication open
authentication key-management wpa
guest-mode
wpa-psk ascii 0 Geheim123
!
bridge irb
!
!
interface Dot11Radio0
no ip address
no ip route-cache
!
encryption mode ciphers aes-ccm
!
ssid Bitschleuder
!
station-role root
no dot11 extension aironet
bridge-group 1
bridge-group 1 subscriber-loop-control
bridge-group 1 block-unknown-source
no bridge-group 1 source-learning
no bridge-group 1 unicast-flooding
bridge-group 1 spanning-disabled
!
interface GigabitEthernet0
description the embedded AP GigabitEthernet 0 is an internal interface connecting AP with the host router
no ip address
no ip route-cache
bridge-group 1
no bridge-group 1 source-learning
bridge-group 1 spanning-disabled
!
interface BVI1
ip address 192.168.100.1 255.255.255.0
no ip route-cache
!
ip http server
no ip http secure-server
bridge 1 route ip
!
line con 0
privilege level 15
login local
line vty 0 4
login local
!
end
⚠️ Die interne IP Adresse des Accesspoints 192.168.100.1 muss immer außerhalb des DHCP Adresspools liegen damit es nicht zu IP Adresskonflikten kommt !
Im hiesigen Beispiel ist der DHCP Pool mit den IP Adressen von .100.150 bis .100.170 definiert und der Router selber hat die .100.254 so das wir mit der .100.1 im sicheren IP Bereich liegen !
Die Parameter dot11 ssid Bitschleuder und auch wpa-psk ascii 0 Geheim123 bestimmen den Namen des WLANs (SSID) und das Zugangspasswort. Das muss entsprechend auf die eigenen Einstellungen angepasst werden !
Startet man nun einen Webbrowser im lokalen LAN und gibt dort als Ziel ein http://192.168.100.1 landet man direkt auf dem Web Interface des internen Accesspoints und kann diesen nun auch ganz bequem per Web konfigurieren und diese Konfig Anpassungen vornehmen. (Siehe Screenshot)
Der direkte CLI Zugriff auf den AP mit seiner IP ist ebenfalls mit Telnet oder SSH so möglich.
WLANs mit MSSID, Radius etc.
Weitere, detailierte WLAN Konfigurationen wie MSSID, 802.1x Radius, dyn. VLANs usw. erläutert das hiesige Cisco Accesspoint Tutorial.VLAN Segmentierung konfigurieren
Um die Sicherheit zu erhöhen, ist es immer vorteilhaft das eigene Netzwerk in mehrere Netzwerksegmente zu teilen.
Zum Beispiel 2 getrennte Firmennetze an einem Router zu betreiben oder das Heimnetz in Gastnetz und Hausautomation zu segmentieren.
Der Cisco Router hat vollen 802.1q VLAN Support mit an Bord so das diese VLAN Segmentierung einfach umzusetzen ist.
An dieser Stelle sei auf das hiesige_VLAN-Tutorial verwiesen, welches zusätzlich VLAN Konfigurationen für Switches und die Kombination mit Routern u. Firewall im Detail behandelt.
Als Konfig Beispiel dient hier ein einfaches Hausnetz mit Segmentierung in privates LAN, Hausautomation und ein Gäste Netz. Letzteres wurde oben schon in der Grundkonfiguration als VLAN 2 realisiert, ist der Vollständigkeit halber hier nochmals aufgeführt.
So sähe dieses einfache Design aus:
vlan 2
name Gastnetz
vlan 3
name Hausautomation
Damit erzeugt man automatisch auch 2 neue (virtuelle) Router IP Interfaces denen man entsprechende IP Adressen zuordnet:
interface Vlan2
description Gastnetz
ip address 172.16.100.254 255.255.255.0
ip nat inside
!
interface Vlan3
description Hausautomation
ip address 10.3.3.254 255.255.255.0
(ip nat inside) <-- (Optional: Wenn hier kein Internet Zugang gewollt ist, dann weglassen !)
!
Die VLAN Zugangssteuerung erledigt dann die Firewall oder ersatzweise eine ACL.
Sind die 3 VLAN Netze 1 (Privat), 2 (Gäste) und 3 (Hausautomation) auf dem Router eingerichtet gilt es diese Netze auf einen angeschlossenen VLAN Switch zu bringen. Das passiert, wie bei VLANs generell üblich, mittels eines VLAN getaggten Uplinks, den man auf das Router LAN Interface (Beispiel hier: Port 3) legt.
!
interface GigabitEthernet3
description Tagged Uplink auf VLAN Switch
switchport mode trunk
switchport trunk allowed vlan all
no ip address
!
Hat man die entsprechenden VLANs 1, 2 und 3 auch auf der Switchseite eingerichtet und auch dort den Switch Uplink Port zum Cisco Router tagged für alle VLANs (außer 1, denn das ist das UNtagged PVID VLAN!) entsprechend konfiguriert, kann man jetzt aus jedem VLAN das dazu korrespondierende Cisco IP Interface anpingen und so die Erreichbarkeit prüfen.
Ein show vlan-switch zeigt eine Übersicht über die erstellten VLAN‘s und den zugewiesenen Ports.
(Für Details zur Switchkonfiguration sei hier nochmals auf das bereits oben genannte VLAN-Tutorial verwiesen !)
Dynamisches DNS (DDNS)
Dynamisches DNS ist erforderlich für Benutzer die den Router bei wechselnden Provider xDSL IP Adressen unter einer festen Hostadresse von außen erreichen wollen oder müssen. Häufig ist das z.B. für den gesicherten VPN Zugang mobiler Clients aufs lokale Netzwerk oder für schlichtes Port Forwarding auf lokale Server (Mail, Exchange, NexctCloud usw.) zwingend erforderlich.
Für die dynamische Anpassung der IP Adresse bei wechselnden Provider xDSL Adressen (nächtliche Zwangstrennung) sollte man deshalb immer einen DynDNS Dienst einrichten. Damit kann der Router immer mit einem festen Hostnamen wie z.B. meinrouter.dnshome.de erreicht werden, egal welche Provider IP er aktuell hat.
Derzeit noch kostenfreie Anbieter wie dnsHome oder deSEC sowie diverse andere lokale DDNS Dienstleister bieten sich da an.
Der DynDNS Dienst wird wie folgt auf dem Cisco Routern aktiviert: (Update method "http" und "add url")
(Wenn ein "?" Bestandteil der DDNS URL ist und per CLI eingetragen werden soll, muß zuvor die Taste „STRG“ und „V“ zusammen gedrückt werden. Dann kann mit „Shift“ und ? das Fragezeichen in die CLI eingetragen werden, ohne das die sonst per "?" übliche Cisco CLI Hilfefunktion startet !)
!
ip ddns update method dnsHome
http
add
http://<Subdomain:password>@www.dnshome.de/nic/update?Subdomain=<h>&myip=<a>
interval maximum 1 0 0 0
!
interface Dialer0
ip ddns update hostname <hostname>.<dyndns.domain>
ip ddns update dnsHome
!
(Es sind nur die zur obigen Grundkonfiguration zusätzlichen Kommandos hier aufgeführt.)
Kostenfreie DynDNS Accounts gibt es z.B. bei deSEC und dnsHome die DSGVO konforme Server betreiben und kein kommerzielles Interesse haben. Hier reicht als Minimum eine einfache Subdomain.
Falls es hier dennoch einmal kneifen sollte, hilft immer ein debug ip ddns update um den DDNS Update Prozess zu überwachen und zu troubleshooten. ACHTUNG: Benutzt man eine Verbindung über Telnet oder SSH zum Router, muss vorher term mon eingegeben werden, damit man die Debug Meldungen im Telnet oder SSH Fenster sieht !
Abgesehen davon wird einem auch über das Kontaktformular der o.a. DynDNS Dienstleister geholfen.
Port Forwarding
Port Forwarding (Weiterleitung) nutzt man z.B. um einen lokalen Webserver, Cloudserver oder Kameras usw. öffentlich von extern (Internet) erreichbar zu machen. Mit Port Weiterleitung können Zugriffe von extern die lokale NAT Firewall überwinden.
Hier sollte man immer große Vorsicht walten lassen, denn man öffnet so das Internet ungeschützt auf lokale Resourcen! Wer also einen privaten NextCloud Server für die Familie oder ein öffentlich erreichbares NAS betreibt, sollte das tunlichst immer in einem geschützten und vom privaten IP Netz getrennten Segment (DMZ) machen !
Es sei an dieser Stelle noch einmal darauf hingewiesen, daß man solche von extern errreichbare Endgeräte nicht ins lokale, private LAN setzen sollte sondern besser ein separates DMZ VLAN dafür anlegt im Cisco. Dies trennt man mit einer Accessliste vom lokalen LAN ab um das private LAN abzusichern und so zu schützen.
Der Grund liegt auf der Hand, denn für den Zugriff muss ein Loch in die Router Firewall gebohrt werden und da ist es immer besser dies auf einem separaten DMZ IP Segment zu machen um das lokale LAN zu schützen.
Ist der Server ein lokaler, privater Server den man von außen erreichen möchte, sollte man generell aus Sicherheitsgründen vom Port Forwarding zumindestens unsicherer Ports absehen ! Ein VPN ist in dem Falle immer der bessere Weg.
Auch hier ist der Grund klar, denn diese Daten gehen immer ungeschützt, für jederman einsehbar über das öffentliche Internet. (Ungeschützte Kameras im Internet sind ein trauriges Beispiel dafür)
Ein VPN sollte für jeden der Wert auf seine Datensicherheit und Schutz legt hier oberste Priorität haben!
Wie man ein sicheres VPN mit diesem Router einrichtet erklärt das Tutorial im weiteren Verlauf oder die weiterführenden Links am Ende.
Nicht immer ist VPN sinnvoll, z.B. bei einem erreichbaren privaten Nextcloud Server. Hier ist Port Forwarding dann das Mittel der Wahl.
Das Beispiel hier zeigt eine sichere DMZ Variante mit Port Weiterleitung:
Zum Port Forwarding soll ein lokaler Webserver (Port TCP 80 und 443 = HTTP) wie z.B. NextCloud vom Internet aus erreichbar sein im neuen VLAN 3. (Standardkonfig von oben verkürzt wiedergegeben !)
interface Vlan3
description DMZ mit Webserver
ip address 172.16.200.1 255.255.255.0
ip nat inside
!
interface Dialer0
description xDSL Internet Interface
ip address negotiated
ip access-group 111 in
...
!
ip nat inside source list 101 interface Dialer0 overload
ip nat inside source static tcp 172.16.200.151 80 interface Dialer0 80
ip nat inside source static tcp 172.16.200.151 443 interface Dialer0 443
!
Nicht vergessen: Wer die CBAC oder ZFW Firewall betreibt muss am Internet Port die Accessliste anpassen die Traffic auf den Router passieren lässt!
access-list 111 permit tcp any any eq 80
access-list 111 permit tcp any any eq 443
Spricht man jetzt mit dem Web Browser von "außen" die WAN IP Adresse (Dialer0 IP) des Routers an, landet man auf dem lokalen Webserver in der DMZ der die lokale IP 172.16.200.151 hat.
Eine Port Verschleierung bzw. Port Translation erreicht man z.B. Mit dem Kommando:
ip nat inside source static tcp 172.16.200.151 80 interface Dialer0 50443
Um hier jetzt den lokalen Webserver zu erreichen gibt man im Browser http://<router_Internet_adresse>:50443 an.
Port Forwarding mit ZFW Firewall
Die Port Forwarding Konfiguration im Zusammenspiel mit der ZFW Firewall beschreibt ein separates Tutorial im Detail.
Client VPN (L2TP) mit bordeigenen Windows, MacOS, Linux und Smartphone VPN Clients
⚠️ Bei Windows 21H2 unbedingt Patch HIER !)
Eine gesicherte Client VPN Verbindung dient dazu sicher und geschützt von extern auf Daten im lokalen LAN zugreifen zu können z.B. für Home Office Nutzer, Außendienst, remotes Management, u.a.
Als Client VPN kommt hier das bekannte L2TP Protokoll zum Einsatz (L2TP / IPsec mit vorinstalliertem Schlüssel).
L2TP VPN Clients sind generell in den Betriebssystemen aller oben genannten Endgeräte seit langem enthalten, sprich der im jeweiligen Betriebssystem immer vorhandene, bordeigene VPN Client.
Diesen zu nutzen hat den großen Vorteil das er das Installieren und Management von externer VPN Client Software fremder Hersteller erspart. Prinzipbedingt, bieten diese bordeigenen VPN Clients damit die beste und performanteste VPN Anbindung an das jeweilige Endgerät. Sie werden zudem über AD Directories und GPOs umfassend supportet, so das auch zentrales VPN Clientmanagement sehr leicht fällt.
Das zusätzliche Loopback Interface des Routers dient dazu den L2TP VPN Server ausfallstabil und in einer separaten IP Range zu betreiben. Würde man ihn an das lokale LAN Interface binden, bestünde die Gefahr bei einem LAN Link Verlust das damit auch das VPN nicht mehr funktioniert, was immer zu vermeiden ist.
Ein Loopback Interface kann technisch bedingt niemals einen Link Verlust erleiden bzw. ausfallen solange der Router mit Strom versorgt wird. Das sichert die VPN Erreichbarkeit von außen auch bei einer lokalen LAN Fehlfunktion.
(Die VPN Konfiguration der ZFW Firewall für den IPsec VPN Zugang wird unten im Kapitel zur Zone Based Firewall beschrieben !)
Die folgenden Kommandos sind der Cisco Router Konfig hinzuzufügen
!
aaa new-model
aaa authentication ppp L2TP_AUTH local
!
vpdn enable
!
vpdn-group L2TP
accept-dialin
protocol l2tp
virtual-template 1
no l2tp tunnel authentication
!
username vpnuser password geheim123 => (L2TP Benutzername u. Passwort)
!
crypto keyring vpn_keys
pre-shared-key address 0.0.0.0 key Geheim => (vorinstallierten Schlüssel ändern !)
!
crypto isakmp policy 1
encr aes 256
authentication pre-share
group 14
!
crypto isakmp policy 2
encr aes 256
authentication pre-share
group 2
!
crypto isakmp keepalive 10
!
crypto isakmp profile dynip
description VPNs mit dyn. IP Adresse
keyring vpn_keys
match identity address 0.0.0.0
!
crypto ipsec transform-set L2TP-1 esp-aes 256 esp-sha-hmac => (⚠️Wichtig hier: Transport Mode!)
mode transport
crypto ipsec transform-set L2TP-2 esp-aes esp-sha-hmac
mode transport
!
crypto dynamic-map dynmap 10
set nat demux
set transform-set L2TP-1 L2TP-2
set isakmp-profile dynip
!
crypto map vpn_cisco 10 ipsec-isakmp dynamic dynmap
!
interface Loopback1
description Looback L2TP Pool
ip address 192.168.101.1 255.255.255.255
!
interface Virtual-Template1
description L2TP Dialin
ip unnumbered Loopback1
ip nat inside
peer default ip address pool l2tp-pool
ppp authentication ms-chap-v2 L2TP_AUTH
!
ip local pool l2tp-pool 192.168.101.100 192.168.101.150
!
interface <WAN/Internet_Interface>
description Internet Port
ip address xyz
ip nat outside
crypto map vpn_cisco => (VPN ans WAN Internet Interface binden !)
! ...
⚠️ Die folgende ACL ist nur dann erforderlich wenn ein CBAC Firewall Konzept genutzt wird!!
Bei Nutzung der moderneren Zone based Firewall (siehe Folgekapitel) entfällt diese ACL und wird durch die "ALLOWv4" Accessliste im ZFW Firewall Setup ersetzt!!
access-list 111 permit udp any any eq 1701 --> L2TP darf die CBAC Firewall passieren (Zeile in ACL 111 hinzufügen)
access-list 111 permit udp any any eq 500 --> IPsec darf die CBAC Firewall passieren (Zeile in ACL 111 hinzufügen)
access-list 111 permit udp any any eq non500-isakmp
access-list 111 permit esp any any
Die einfache Einrichtung der VPN onboard Clients in den jeweiligen Betriebssystemen ist dann analog vorzunehmen wie bei anderen L2TP VPN Firewalls und Routern auch und wird hier der Übersicht halber nicht extra beschrieben.
L2TP bordeigene VPN Clients
Beispiele und detailierte Screenshots zum L2TP VPN Client Setup für die betriebssystemeigenen Clients unter Microsoft, Apple, Linux Android usw. findet man in den weiteren L2TP VPN Tutorials des Forums HIER und auch HIER.Client VPN in einer reinen Apple Umgebung
Apple hat von Haus aus einen Cisco VPN Client in alle Apple Betriebssysteme wie Mac OS und iOS integriert.In einem reinen Apple Client VPN Umfeld bietet sich dann als Alternative zum obigen L2TP auch die Option den Apple bordeigenen Cisco VPN Client in einer alternativen Konfig mit nativem IPsec zu nutzen.
(Achtung: Ein Mix mit L2TP ist nicht zu empfehlen ! Wer ein gemischtes VPN Client Umfeld hat, sollte in dem Falle immer ausschliesslich das obige L2TP VPN Protokoll nutzen !)
!
aaa new-model
aaa authentication login clientauth local
aaa authorization network groupauth local
!
username vpnuser1 privilege 0 algorithm-type scrypt secret Geheim123
username vpnuser2 privilege 0 algorithm-type scrypt secret Geheim321
username vpngroup privilege 0 algorithm-type scrypt secret test123
!
crypto isakmp policy 10
encr aes 256
authentication pre-share
group 14
!
crypto isakmp policy 15
encr aes 256
authentication pre-share
group 2
!
crypto isakmp client configuration group vpngroup
key test123
dns 192.168.100.254 # => (oder, wenn vorhanden, lokale DNS Server IP)
domain vpn.test.intern
acl 107 => (Split VPN ACL, kann entfallen wenn gesamter VPN Traffic in den Tunnel soll)
save-password
max-users 10 => (Je nach Router Performance und Bandbreite einstellen)
banner # Willkommen im VPN von XYZ # (Optional !)
pool vpnpool
!
crypto isakmp profile VPNclient
description VPN Client Profil
match identity group vpngroup
client authentication list clientauth
isakmp authorization list groupauth
client configuration address respond
virtual-template 2
!
crypto ipsec transform-set myset esp-aes esp-sha-hmac
mode tunnel
!
crypto ipsec profile vpn-vti2
set transform-set myset
set isakmp-profile VPNclient
!
interface Virtual-Template2 type tunnel
description IPsec VPN Dialin
ip unnumbered Vlan1
ip nat inside
ip virtual-reassembly in
tunnel mode ipsec ipv4
tunnel path-mtu-discovery
tunnel protection ipsec profile vpn-vti2
!
interface Vlan1
ip address 192.168.100.254 255.255.255.0
!
ip local pool vpnpool 192.168.100.240 192.168.100.250 (Anpassen auf eigenen Client IP Bereich im lokalen LAN außerhalb d. DHCP Range !)
!
end
⚠️ Auch hier ist die Erweiterung der ACL 111 nur dann erforderlich wenn ein CBAC Firewall Konzept genutzt wird!!
Bei Nutzung der moderneren Zone based Firewall (siehe Folgekapitel) entfällt diese ACL und wird durch die "ALLOWv4" Accessliste im ZFW Firewall Setup ersetzt!!
...
access-list 111 permit udp any any eq 1701
access-list 111 permit udp any any eq isakmp
access-list 111 permit udp host any any eq non500-isakmp
access-list 111 permit esp any any
...
Die ACL 107 (nur CBAC Setup, nicht erforderlich bei ZFW!!) die den VPN Traffic für das lokale Netz klassifiziert, wird erweitert :
access-list 107 permit ip 192.168.100.0 0.0.0.255 any --> (Split VPN)
Wichtig: Diese ACL 107 kann entfallen wenn der gesamte Client Traffic in den VPN Tunnel soll. (Gateway Redirect)
Konfig des iPhone / iPad IPsec Clients...:
(Als Ziel IP Adresse die WAN (Dailer) Port IP Adresse oder eigene dynamische DNS Adresse eintragen !)
Screenshot des Mac OS-X onboard IPsec Clients:
Sollte es mit dem VPN Zugriff einmal klemmen, dann kann man sich mit folgenden Befehlen auf Fehlersuche machen:
debug crypto isakmp und debug crypto ipsec. Mit show crypto ipsec sa und show crypto engine connection active werden noch weitere Info’s angezeigt.
Mit Hilfe des Befehls show crypto isakmp sa kann man unter anderem sehen wieviele Pakete verschlüsselt (decrypted) und entschlüsselt (encrypted) wurden.
Der Befehl show crypto tech support zeigt zusätzlich einen kompletten Überblick über fast alle crypto Einstellungen.
Site to Site VPN (Standortkopplung) per IPsec Tunnel
⚠️ (Die Konfiguration der ZFW Firewall für die IPsec VPN Standort Kopplung wird unten im Kapitel zur Zone Based Firewall beschrieben !)
Eine Standort VPN LAN to LAN Kopplung zweier oder mehrerer Standorte mit IPsec Verschlüsselung, sei es mit Cisco oder zu anderen VPN Routern, lässt sich ebenso bequem erledigen um z.B. gemeinsame Resourcen wie Server, NAS etc. standortübergreifend zu nutzen.
IPsec ist ein weltweiter Standard so das auch VPN Tunnel zu anderen IPsec Routern oder Firewalls supportet ist. Weitere Cisco Praxiskonfigurationen dazu findet man unten in den weiterführenden Links dieses Tutorials.
Für die VPN Kopplung 2er Cisco Router mit festen WAN IP Adressen sind die folgenden Konfigurationsschritte auf beiden Seiten des VPN Tunnels erforderlich, die man der obigen Standardkonfiguration hinzufügt:
!
crypto keyring VPN_PSK
pre-shared-key address <feste_ip_peer> key GeheiM123 => (Preshared Key)
!
crypto isakmp policy 10
encryption aes 256
authentication pre-share
group 2
!
crypto isakmp keepalive 10
!
crypto isakmp profile Standort-B
description IPsec VPN Standort-B
keyring VPN_PSK
match identity address <feste_ip_standort-B>
!
crypto ipsec transform-set vpn-s2s esp-aes esp-sha-hmac
!
crypto ipsec profile Standort-B
set transform-set vpn-s2s
set isakmp-profile Standort-B
!
interface Tunnel1
description VPN Tunnel Standort-B
ip unnumbered Vlan1
ip verify unicast reverse-path
tunnel source <feste_ip_standort-A>
tunnel mode ipsec ipv4
tunnel destination <feste_ip_standort-B>
tunnel path-mtu-discovery
tunnel protection ipsec profile Standort-B
!
!
access-list 101 deny ip 192.168.100.0 0.0.0.255 192.168.200.0 0.0.0.255 --> Kein NAT für den VPN Tunnel !
access-list 101 permit ip 192.168.100.0 0.0.0.255 any --> ...aber NAT ins Internet
!
ip route 192.168.200.0 255.255.255.0 Tunnel1 --> Route ins remote LAN Standort B
...
access-list 111 permit udp any any eq 1701
access-list 111 permit udp any any eq 500
access-list 111 permit udp any any eq non500-isakmp
access-list 111 permit esp any any
!
(Die ACL 111 entfällt bzw. ändert sich wenn ein ZFW Firewall Konzept verwendet wird ! Alle Details im Kapitel "ZFW Firewall")
Die gleichen Konfigurationsschritte sind auf der gegenüberliegenden Standortseite, angepasst an die dortigen IP Adressen, auszuführen.
Das Beispiel oben geht davon aus das sich ein lokales LAN mit der IP Adresse 192.168.200. /24 dort befindet.
Diese IP Adressen sind entsprechend auch eigenen Belangen anzupassen. Ebenso natürlich das Platzhalter Passwort "test123" für die IPsec Verschlüsselung.
Der Parameter <remote_WAN_IP> muss in der Konfig durch die xDSL IP oder den Hostnamen / DynDNS ersetzt werden.
Ebenfalls kann man am obigen Beispiel sehen, daß das NAT etwas angepasst werden muss, denn IP Packete die lokal beide Netze über den IPsec Tunnel verbinden, dürfen natürlich nicht über den NAT (Adress Translation) Prozess laufen (ACL 101 nimmt diesen Traffic aus).
Die genauen VPN Konfigs für die Praxis liefert dieses Foren VPN Tutorial
VPN Site to Site (Standortkopplung) ohne feste IP (dynamische IP):
Befindet sich am remoten Standort ein IPsec VPN Router oder Firewall (FritzBox, Draytek, Mikrotik, Lancom, pfSense/OPNsense o.ä. hier mit lokalem Beispiel LAN 192.168.222.0 /24) der keine feste Internet IP hat, also eine wechselnde Provider IP, muss zusätzlich eine dynamische Crypto Map angelegt werden. Das gilt auch für solche Standorte mit einem DS-Lite Anschluss und CGNAT.
Dazu ist die Konfig wie folgt zu ergänzen:
!
crypto keyring vpn_keys
pre-shared-key address 0.0.0.0 key GeheiM123 => (Preshared Key)
!
crypto isakmp policy 10
encryption aes 256
authentication pre-share
group 2
!
crypto isakmp keepalive 10
!
crypto isakmp profile dynip
description VPNs mit dynam. IP
keyring vpn_keys
match identity address 0.0.0.0
!
crypto dynamic-map dynmap 10
description Tunnel dyn.IP Standort-B
set isakmp-profile dynip
set transform-set vpn
match address 107
!
crypto ipsec transform-set vpn esp-aes esp-sha-hmac
!
crypto map vpn_cisco 10 ipsec-isakmp dynamic dynmap
!
interface <Internet_Int>
description Internet Port
ip address xyz
ip nat outside
crypto map vpn_cisco => (VPN ans Internet Interface binden !)
!
Damit können remote IPsec VPN Router/Firewalls (z.B. FritzBox u.a.) auch mit wechselnden, dynamischen Provider IPs problemlos eine VPN Verbindung auf den Cisco Router herstellen.
Sind beide oder alle Standorte ohne feste IP konfiguriert, dann muss man wenigstens auf einem (zentralen) VPN Router mit DynDNS gem. der o.a. Konfig im Kapitel Dynamisches DNS arbeiten.
Firewall mit modernem, Zonen basiertem Firewall Konzept (ZFW) konfigurieren:
Die klassische, oben beschriebene, rein Interface bezogene Cisco stateful Inspection Firewall, auch als Context-Based Access Control, oder CBAC bekannt, wurde mit dem IOS Release 12.4.9T mit der verbesserten und flexibleren Zonen basierten Firewall (ZFW) ersetzt. Sie wird die alte CBAC Firewall auf Sicht vollständig im IOS ersetzen.
Beide Versionen koexistieren zur Zeit und man hat (noch) die Wahl welche Art der Firewall man nutzen möchte.
Es macht also Sinn bei einer Neuinstallation die Firewall Konfig ggf. gleich mit der moderneren und flexibleren ZFW Konfiguration zu realisieren. Zumal die ZFW Syntax auch weitgehend der der ASA Router entspricht.
Die ZFW Firewall bietet zudem eine Deep Packet Inspection bis auf URL und Content Basis (ALG) und hat verbesserte Reporting Mechanismen gegen DoS Attacken. Zusätzlich ermöglicht sie durch die Zonen Struktur eine deutlich bessere und erhöhte Sicherheit als anfällige, Interface basierte Access Listen wie in der alten CBAC Struktur.
Die Zonen basierte Konfig unterscheidet sich erwartungsgemäß erheblich von der klassischen CBAC Firewall Konfiguration mit ihren ip inspect Kommandos. Diese und die CBAC Accesslisten entfallen vollständig bei der moderneren ZFW Konfiguration ! In der o.a. Konfig Vorgabe wird darauf mehrfach hingewiesen und sollte unbedingt beachtet werden.
Ein Mischen der neuen ZFW Firewall mit dem alten CBAC Modell ist immer zu vermeiden und nur ein Firewall Konzept zu verwenden.
Also entweder rein CBAC oder rein das modernere ZFW Firewall Modell zu nutzen. Kein Mischbetrieb !
Die ZFW Grundregeln sind einfach:
- Traffic innerhalb von allen Interfaces einer Zone wird normal geforwardet
- Traffic zwischen unterschiedlichen Zonen wird ohne Policy Regeln generell geblockt.
- Gleiches gilt für Interfaces die keine Zonen Member sind. Deren Traffic mit Zonen Interfaces wird generell geblockt.
Gäste sollen hier im Beispiel nur mit dem Browser ins Internet dürfen und aus dem lokalen LAN soll ein Management von Komponenten (z.B. WLAN) im Gastnetz per HTTP und SSH möglich sein, nicht aber darf das Gastnetz Zugriff auf das lokale LAN haben.
"Schotten dicht....!!" Los gehts...
(Die folgende Beispiel Konfig enthält der Übersicht halber nur die Firewall relevanten Konfigurations Parameter!)
Zuerst richtet man die entsprechenden Zonennamen ein. Hier im Beispiel somit also 3 Zonen (Gast, Lokales LAN und Internet).
Kosmetischer Tip: Es macht Sinn die Map und Zonen Namen immer GROß zu schreiben um sie von den Konfig Kommandos einfacher unterscheiden zu können. Die Namen sind frei wählbar.
⚠️ Die Reihenfolge in den class-map Definitionen zählt!!
Zuerst bestimmt man mit den Class Maps die Netzwerk Protokolle die man zulassen und überwachen möchte. TCP und UDP am Schluss macht eine Inspection über alle Protokolle die nicht explizit definiert wurden. Würde man dies global am Anfang definieren kommt es zu keiner protokollspezifischen Inspection mehr! Lässt man es weg passiert die Firewall nur was protokollspezifisch definiert wurde.
Es ist also wichtig diese globalen Definitionen wegzulassen wenn man z.B. nur Webtraffic mit HTTP und HTTPS zulassen möchte wie es im Folgenden in der Class Map GAST-ERLAUBT für das Gästenetz definiert wurde.
!
class-map type inspect match-any GAST-ERLAUBT
match protocol http
match protocol https
match protocol dns
match protocol ntp
!
class-map type inspect match-all ALLOW_IN
match access-group name ALLOWv4
!
class-map type inspect match-any LOKAL-ERLAUBT
match protocol http
match protocol https
match protocol dns
match protocol pop3s
match protocol imaps
match protocol smtp
match protocol rtsp
match protocol ftp
match protocol ftps
match protocol ssh
match protocol ntp
match protocol tcp
match protocol udp
match protocol icmp
!
class-map type inspect match-any ROUTER-PROTOCOLS
match protocol tcp
match protocol udp
match protocol icmp
!
Dazu kommen nun die Policies was gemacht werden soll und darf zwischen den Zonen:
!
policy-map type inspect GAST-INTERNET-POLICY
description Traffic Gast zum Internet
class type inspect GAST-ERLAUBT
inspect
class class-default
drop
!
policy-map type inspect ROUTER-INTERNET-POLICY
description Traffic Routertraffic zum Internet
class type inspect ROUTER-PROTOCOLS
inspect
class class-default
drop
!
policy-map type inspect LOKAL-INTERNET-POLICY
description Traffic Lokales LAN zum Internet
class type inspect LOKAL-ERLAUBT
inspect
class class-default
drop
!
policy-map type inspect INTERNET-ROUTER-POLICY
description Traffic Internettraffic zum Router
class type inspect ALLOW_IN
pass
class class-default
drop
!
Dann werden die Zonen definiert (hier 3):
!
zone security LOKAL
zone security GAST
zone security INTERNET
Last but not least richtet man die Zonen Paare ein (wer mit wem) und aktiviert die dazu korrespondierende Security Policy. Danach weist man den Interfaces die Zonen zu:
!
zone-pair security LOKAL-INTERNET source LOKAL destination INTERNET
service-policy type inspect LOKAL-INTERNET-POLICY
!
zone-pair security GAST-INTERNET source GAST destination INTERNET
service-policy type inspect GAST-INTERNET-POLICY
!
zone-pair security INTERNET-ROUTER source INTERNET destination self
service-policy type inspect INTERNET-ROUTER-POLICY
!
zone-pair security ROUTER-INTERNET source self destination INTERNET
service-policy type inspect ROUTER-INTERNET-POLICY
!
interface Vlan1
description Lokales LAN
zone-member security LOKAL
!
interface Vlan10
description Gastnetz
zone-member security GAST
!
interface Virtual-Template1
description IPsec VPN Dialin
ip unnumbered Vlan1
zone-member security LOKAL
!
interface Dialer0
description DSL Internet Interface
zone-member security INTERNET
!
ip access-list extended ALLOWv4
permit udp any any eq 1701
permit udp any any eq isakmp
permit udp any any eq non500-isakmp
permit esp any any
!
Das Show Kommando: show policy-map type inspect zone-pair <Zone_paar_name> (hier als Beispiel einmal "show policy-map type inspect zone-pair LOKAL-INTERNET) zeigt dann z.B. die Statistiken der inspizierten Protokolle aus dem lokalen LAN ins Internet.
sh policy-map type inspect zone-pair sessions zeigt alle aktiven Endgeräte Sessions an über alle Zonenpaare.
Die korrekte Einbindung von VPN Verbindungen in die ZFW Firewall zeigt ein separates Tutorial.
Port Forwarding Setups mit der ZFW Firewall behandelt ebenso ein ZFW Port Forwarding Tutorial.
Besonderheit: ZFW und DHCPv4 Client am WAN/Internet Port
⚠️ Der folgende Hinweis gilt ausschliesslich nur für Nutzer die mit der ZFW ein Router WAN Interface im DHCP Client Mode mit IPv4 nutzen, also ein WAN/Internet Interface was sich dynamisch per DHCPv4 IP Adressen holt. (Kein PPPoE mit xDSL!)Im DHCPv4 Client Mode muss in diesem Falle in der ZBF statt inspect der pass Mode in der obigen Outbound Policy Beispiel Map: ROUTER-INTERNET-POLICY verwendet werden, damit ausgehend DHCPv4 Requests die Firewall überwinden können !
Zusätzlich muss die Inbound Acessliste (ALLOWv4) für DHCPv4 geöffnet werden die den externen Traffic auf den WAN/Internet Port (Zone "Internet") steuert:
class-map type inspect match-any DHCPv4
match access-group name DHCPv4
!
ip access-list extended ALLOWv4
remark Pass traffic fom DHCPv4 server
permit udp any eq bootps any eq bootpc --> (DHCP darf eingehend passieren)
remark Pass IPsec VPN traffic
permit udp any any eq 1701
permit udp any any eq isakmp
permit udp any any eq non500-isakmp
permit esp any any
!
ip access-list extended DHCPv4 --> (DHCP Request Broadcasts dürfen ausgehend passieren)
remark Pass DHCPv4 client traffic
permit udp any eq bootpc any eq bootps
!
policy-map type inspect ROUTER-INTERNET-POLICY
description Traffic Routertraffic u.DHCPv4 zum Internet
class type inspect DHCPv4
pass
class type inspect ROUTER-PROTOCOLS
inspect
class class-default
drop
Zu der Thematik bitte auch diesen Hinweis in den Nutzerkommentaren beachten !
ZFW Firewall für IPv6 anpassen
Die IPv6 Protokoll Steuerung und viele Features die bei v4 eigene Protokolle nutzen, basieren bei IPv6 zu einem sehr großen Teil auf dem ICMP Protokoll. ICMP darf also bei v6 nicht gefiltert werden bzw. nur in sehr geringem Maße (siehe hier Tabelle 5, Seite 6).
Deshalb muss die ZFW Firewall für den Dual Stack Betrieb IPv4 mit IPv6 etwas angepasst bzw. erweitert werden im Bereich ICMPv6.
Generell gilt das Regelwerk der ZFW Firewall aber immer für IPv4 und auch IPv6 gleichermaßen.
Man erstellt zuerst 3 Access Listen die die für IPv6 wichtigen ICMP Typen passieren lassen und die DHCPv6 Frames am WAN Port für die Adress Prefix Delegation erlaubt.
Die IPv4 ACL (gleiche wie oben) stellt sicher, das VPN Traffic remoter Nutzer den Router durch die Firewall am WAN/Internet Port erreichen kann.
!
ip access-list extended ALLOWv4
10 permit udp any any eq 1701
20 permit udp any any eq isakmp
30 permit udp any any eq non500-isakmp
40 permit esp any any
!
ipv6 access-list ALLOWv6
sequence 10 permit udp any eq 547 any eq 546 --> (Erlaubt DHCPv6 Traffic zur v6 Prefix Delegation)
!
ipv6 access-list ICMPv6
sequence 10 permit icmp any any unreachable
sequence 20 permit icmp any any packet-too-big
sequence 30 permit icmp any any hop-limit
sequence 40 permit icmp any any reassembly-timeout
sequence 50 permit icmp any any header
sequence 60 permit icmp any any next-header
sequence 70 permit icmp any any parameter-option
sequence 80 permit icmp any any echo-request
sequence 90 permit icmp any any echo-reply
sequence 100 permit icmp any any dhaad-request
sequence 110 permit icmp any any dhaad-reply
sequence 120 permit icmp any any mpd-solicitation
sequence 130 permit icmp any any mpd-advertisement
!
Aus den beiden WAN Port ACLs und der v6 ICMP ACL definiert man dann 2 zusätzliche Class Maps der ZFW:
!
class-map type inspect match-any ALLOW_IN
match access-group name ALLOWv4
match access-group name ALLOWv6
!
class-map type inspect match-any ROUTER-PROTOCOLS
match class-map ALLOW_IN
match protocol tcp
match protocol udp
match protocol icmp
!
class-map type inspect match-any ICMPv6
match access-group name ICMPv6
!
Die dann wiederum in die entsprechenden Policy Maps für die Zonen münden:
!
policy-map type inspect ICMPv6
description Traffic ICMPv6 ins lokale LAN
class type inspect ICMPv6
inspect
class class-default
drop
!
policy-map type inspect INTERNET-ROUTER-POLICY
description Erlaubter Traffic Internet zu Router
class type inspect ALLOW_IN
pass
class class-default
drop
!
Daraus resultiert dann die angepasste Zonen Konfig:
!
zone-pair security ICMPv6 source INTERNET destination LOKAL
service-policy type inspect ICMPv6
!
zone-pair security InternetToRouter source INTERNET destination self
service-policy type inspect InternetToRouter
!
(Namen der Maps ggf. an eigene Konfig anpassen !)
Home IP-TV Konfiguration (Magenta-TV etc.):
⚠️ Seit Januar 2020 hat die Telekom die alten Entertain Multicast Streams abgeschaltet ! Siehe dazu auch HIER.
Wer also IP TV mit VLC oder KODI im heimischen Netz schaut muss auf die neuen Multicast Adressen umstellen. Magenta TV supportet nur noch SSM Multicast und erzwingt damit die Verwendung von IGMPv3.
Magenta TV funktioniert aber weiterhin fehlerlos mit den u.a. Einstellungen und kann so auch weiter mit dem Cisco problemlos mit Settopbox, VLC, Kodi, TV-Headend und anderen freien Tools gesehen werden.
Da der Router vollständigen Multicast Routing Support mit an Bord hat, ist die Aktivierung von IP TV auf dem Cisco Router kein großes Problem. In Ausnahmefällen ist hier ggf. eine zusätzliche Advanced IP Lizenz erforderlich. Mit show license all lässt sich das überprüfen und ggf. eine Multicast Lizenz nachinstallieren.
Mit der neuen BNG Umstellung der Telekom ist die Magenta IP-TV Konfiguration um einiges einfacher geworden. Das folgende Beispiel zeigt eine funktionsfähige Konfiguration. (Kommandos in rot kommen zur bestehenden Grundkonfiguration in blau dazu !)
Generell funktioniert diese Konfiguration auch für alle anderen Cisco IOS und IOS-XE Router Modelle am IP-TV Anschluss der Telekom bzw. Providern die Multicast für IP-TV nutzen.
!
ip multicast-routing
ip pim ssm default
!
interface Vlan1
description Lokales LAN
ip address 192.168.100.254 255.255.255.0
ip pim sparse-mode
ip nat inside
ip virtual-reassembly in
ip tcp adjust-mss 1448
ip igmp helper-address 62.155.243.102
ip igmp version 3
ip igmp explicit-tracking
!
interface Dialer0
description VDSL PPPoE Einwahl Interface
ip address negotiated
ip access-group 111 in
no ip redirects
no ip unreachables
no ip proxy-arp
ip mtu 1488
ip pim sparse-mode
ip nat outside
ip inspect myfw out
ip virtual-reassembly in
encapsulation ppp
ip igmp version 3
dialer pool 1
dialer-group 1
ppp authentication pap callin
ppp pap sent-username xxxxxxxx@t-online.de password 0 xxxxxxx
ppp ipcp dns request
ppp ipcp mask request
ppp ipcp route default
no cdp enable
!
ip pim rp-address 62.155.243.102
!
Das Senden von Multicast Streams über das VLAN 8 (Tagging, Subinterface Ethernet0.8) ist nicht mehr supportet bei der Telekom bzw. Magenta TV. Der Vollständigkeit halber sei es aber hier noch erwähnt sofern alternative IP-TV Provider diese Option mit separatem Tagging noch nutzen.
!
ip multicast-routing
ip pim ssm default
!
interface Ethernet0.8
description VDSL Multicast Entertain
encapsulation dot1Q 8
ip dhcp client broadcast-flag clear
ip address dhcp
ip pim sparse-mode
no ip mroute-cache
ip igmp version 3
ip igmp query-interval 15
ip igmp proxy-service
!
interface Vlan1
ip pim sparse-mode
ip igmp helper-address 62.155.243.102
ip igmp version 3
ip igmp explicit-tracking
ip igmp query-interval 15
ip igmp proxy-service
!
ip pim rp-address 62.155.243.102
Die Prozedur der Rendezvous Point IP Adress Ermittlung ist mittlerweile einfacher als im unten angegebenen PDF beschrieben. Mit show ppp all kann man diese auf dem Router direkt ermitteln.
Die Multicast Rendezvous Point IP Adressen werden über DHCP mitgeteilt.
Ein show dhcp lease zeigt dann abhängig vom jeweiligen Ort z.B. so etwas an:
Temp ip static route0: dest 193.158.132.189 router 10.34.63.254
Temp ip static route0: dest 87.141.128.0 router 10.34.63.254
(Dank an Forumsmitglied @cpt-haddock für diesen Hinweis im u.a. Tutorial Feedback Thread !)
Die IP-TV Multicast Adress Listen um Telekom Magenta TV auf PC, Laptop oder mobilem Tablet/Smartphone z.B. mit VLC, KODI und dvbviewer Clients zu sehen findet man HIER. (Achtung ! Multicast Adressänderung hier ab 09.01.2020)
Cisco IOS Funktionen
Neue Firmwaredatei vor der Installation auf dem Router verifizieren
Da mit Ausnahme des Cisco CCO Downloads nicht alle Quellen von Firmware Dateien immer zuverlässig oder fehlerfrei sind, sollte man vor der Übertragung einer neuen Firmware-Datei auf den Router per TFTP oder USB Stick immer einen Firmware Check VOR der Installation durchführen.
So vermeidet man proaktiv eine aufwendige Firmware Wiederherstellung des Routers über sein serielles Terminal Interface.
Nach der Übertragung der Firmware Datei in den Flash Speicher sollte folgender Befehl ausgeführt werden:
verify flash: c800-universal9-mz.SPA.159-3.M2.bin
(Hier statt des Beispiels immer den aktuellen Firmware Datei Name verwenden!!)
Dabei werden zwei SHA2 Hashes errechnet und ein MD5 Hash.
Der untenstehende MD5 Hash sollte mit dem Wert der entsprechenden Datei auf der Cisco Webseite verglichen werden. Stimmen beide SHA2 Werte und der MD5 Wert überein, kann man bedenkenlos die Firmware aktualisieren.
Bei IOS-XE Firmware lautet das Kommando:
verify /md5 flash:c1100-universalk9.17.09.05a.SPA.bin
Den Parameter "md5" kann man alternativ mit /sha512 ersetzen um statt eines MD5 Hashes einen SHA512er zu berechnen.
Cisco Embedded Event Manager
Der Cisco EEM ist ein flexibles Scripting System im IOS oder IOS-XE mit dem man Ereignisse und wiederkehrende Events automatisieren kann um so Funktionen nach eigenen Wünschen umzusetzen. Sämtliche Möglichkeiten inklusive TCL und Expect Scripting zu beschreiben würde den Rahmen dieses Kapitels sprengen so das hier nur 2 kurze Beispiele erwähnt werden. Details entnimmt man der EEM Command Reference und dem EEM Best Practise Guide.
Das Beispiel 1 pingt einen remoten VPN Router (oder Host) alle 5 Minuten und meldet einen VPN Fehler per Syslog:
event manager applet VPNCHECK
event timer watchdog name vpn_check time 300
action 010 cli command "enable"
action 020 cli command "ping 192.168.250.1 source vlan 1"
action 030 regexp "Success rate is ([0-9]+) percent" "$_cli_result" match percent
action 070 if $percent eq "0"
action 080 syslog msg "VPN Peer is offline"
action 090 end event manager applet LOGIN
event syslog pattern "SEC_LOGIN-5-LOGIN_SUCCESS"
action 010 mail server "mail from user@example.com to user2@example.com subject "User Login" body "SSH Login by user!" server <username>:<passwd>@smtp.example.com port 587 secure tls
action 020 syslog msg "Login event mail sent to email server" Zugang zum Kommando Interface und SNMP Management absichern
Oben in der Grundkonfiguration regelt die Accessliste "CLI-ACCESS" welche IP Adressen bzw. IP Netze Zugang zum Kommando Interface vty 0 4 des Routers haben und welche nicht. ("vty" steht hier für virtuelles SSH oder Telnet Terminal)
Der ACL Name ist dabei frei wählbar.
Diese Zugangsbeschränkung auf den Router lässt sich mit ein paar mehr Kommandos noch weiter sichern.
login block-for 120 attempts 3 within 15 <-- Blockt den Zugang bei 3 Fehlveruchen innerhalb von 15 Sek. für 120 Sek.
login delay 3 <-- Verzögert den Login Prompt für 3 Sek.
login quiet-mode access-class 23 <-- Während des o.a. Block Modes bei Fehlversuchen greift weiter ACL 23
login on-failure log <-- Login Fehlversuche werden mitgeloggt
login on-success log <-- Erfolgreiche Logins werden mitgeloggt
!
line vty 0 4
access-class CLI-ACCESS in <-- Telnet/SSH/SNMP Zugriff nur aus lokalem LAN möglich (ACL "CLI-ACCESS")
exec-timeout 15 0 <-- Inaktivitätstimer, loggt autm. aus nach <min> <sek> (Default 10 Min. exec-timeout 10 0)
login local
transport input telnet ssh <-- Telnet / SSH Zugriff. Ist zur Sicherheit nur SSH gewünscht "telnet" hier weglassen.
!
Der Zugang kann, wie bei Netzinfrastruktur Geräten üblich, zusätzlich über einen externen AAA Server wie Radius oder TACACS abgesichert werden.
Analog ist die Accessliste "CLI-ACCESS" auch für das SNMP v2c Management relevant, die damit nur SNMP Zugriff aus dem internen oder Management LAN erlaubt.
!
ip telnet source-interface Vlan1 <-- Absender IP für Telnet Traffic ist immer vlan1
ip tftp source-interface Vlan1 <-- dto. TFTP Traffic (Konfig und Image Sicherung übers Netz)
ip ssh source-interface Vlan1 <-- dto. SSH Traffic
!
snmp-server community public RO CLI-ACCESS
snmp-server community private RW CLI-ACCESS
snmp-server trap-source Vlan1
snmp-server source-interface informs Vlan1
snmp-server location Rechenzentrum, Schrank 1
snmp-server contact IT-Abteilung, Tel.:123
(snmp-server host <ip_snmp_server> version 2c private) <-- Optional. Nur wenn SNMP Server auch Traphost ist
!
Die SNMP v2c Community Strings public und private sind natürlich hier nur Beispiele und unbedingt mit individuellen zu ersetzen ! Ganz besonders der private String, denn der hat RW (Read, Write) Optionen, kann also per SNMP die Routerkonfiguration verändern.
Wer mehr Sicherheit möchte und den SNMP Zugang verschlüsseln will ersetzt immer SNMPv2c mit SNMPv3.
Gute kostenfreie Programme die ein grafisches SNMP Management ermöglichen sind z.B. PRTG, LibreNMS, Zabbix, Cacti, Nagios, Observium usw. Das hiesige Management Tutorial gibt eine kurze Übersicht.
SSH Hürden beim CLI Zugang überwinden
Generell gibt es keinerlei Hürden beim SSH Zugang auf das Kommando Interface mit bekannten Tools wie PuTTY or TeraTerm oder aus der Powershell. Klassische Smartphone Clients sind z.B. Shelly SSH-Client für iPhone oder Juice SSH für Android. Mittlerweile bringen ausnahmslos alle Betriebssysteme immer auch einen SSH Client mit.Auf die Verwendung von Telnet sollte man wegen der fehlenden Verschlüsselung aus Sicherheitsgründen verzichten oder zumindestens mit ACLs (Beispiel oben ACL "CLI-ACCESS") sicherstellen das Telnet nur aus lokalen Netzen erlaubt ist.
Mit der obigen Aktivierung von SSH Ver.2 auf dem Cisco muss ein entsprechender 1024 Bit (oder größer Key) erstellt werden. Das Kommando dafür lautet crypto key generate rsa. Einen ggf. vorhandenen alten Key kann (und sollte) man vorher mit crypto key zerosize löschen.
Mit aktuellen Linux oder Mac OS Versionen kommt es aber manchmal zu Fehlern aufgrund der dort erzwungenen starken Key Exchange Algorithmen in OpenSSH, die häufig kein diffie-hellman-group14-sha1 mehr supporten, was in manchen Netzwerk Geräten vieler Hersteller enthalten ist. Mit ein paar kleinen Tricks lässt sich das aber sehr einfach umschiffen.
SSH Client Zugang auf Cisco
Wenn der Zugang auf den Cisco aufgrund eines nicht supporteten kex algorithm oder mit port 22: no matching host key type found. Their offer: ssh-rsa abgelehnt wird, kann man das SSH Kommando etwas erweitern:ssh -oKexAlgorithms=+diffie-hellman-group14-sha1 admin@<ip_address>
Um das nicht immer manuell machen zu müssen legt man ganz einfach unter /home/user/.ssh/ eine Text Datei mit dem Namen config und dem folgenden Inhalt an:
Host 172.30.0.102
KexAlgorithms +diffie-hellman-group14-sha1
HostkeyAlgorithms +ssh-rsa
User admin Vom Cisco auf andere SSH Hosts zugreifen
Der gleiche kex error kann auftreten wenn man schnell einmal vom Cisco CLI mit dem Kommando ssh -l <username> <cisco_ip> per SSH auf einen anderen SSH Host zugreifen will oder Dateien vom Flash per SCP kopieren möchte. Auch hier hilft wieder eine Konfig Text Datei im Verzeichnis /etc/ssh/sshd_config.d des Ziel SSH Servers z.B. mit dem Namen cisco.conf (alles was .conf als Dateierweiterung im Namen hat ist erlaubt) und mit folgendem Inhalt:KexAlgorithms +diffie-hellman-group14-sha1
HostkeyAlgorithms +ssh-rsaDamit sollten dann alle SSH Verbindungen in egal welche Richtung immer klappen.
Dateien kopieren mit SCP
⚠️ Beim Kopieren von Dateien mit SCP auf den Cisco ist unbedingt der -O Parameter zu verwenden! (Siehe entsprechende TechNote von Cisco zu der Thematik)Alle relevanten Einstellungen zum Kopieren mit SCP beschreibt u.a. dieser Forenthread. Eine Automatisierung per Skript mit z.B. Expect beschreibt u.a. dieser Thread.
Die Lösung mit dem -O Parameter beim Kopieren mit SCP gilt sehr wahrscheinlich auch für alle anderen Hersteller die ein Kopieren von Dateien per SCP supporten!
Alias Funktion
Um sich die tägliche Arbeit zu erleichtern, können sogenannte Alias Kommandos eingesetzt werden. Hierbei kann man einen längeren Befehl stark verkürzen.Damit kann ein Benutzer sich diesen leichter merken und schneller abrufen.
Als Beispiel sind im Folgenden 4 verschiedene angepasste show Befehle aufgeführt.
Es können aber auch alle anderen Befehle mit einem alias versehen werden. Z.B.:
alias exec cpu show processes cpu sorted | exclude 0.00%
alias exec brief show ip interface brief
alias exec vpn show crypto ipsec sa
alias exec run show running-config brief
Der oberste Alias Befehl "cpu" zeigt die Ausgabe vom "show processes cpu sorted" ohne Prozesse mit 0% Auslastung an. Mit brief wird dann "show ip interface brief" und mit vpn wird "show crypto ipsec sa" angezeigt. Das letzte Alias Beispiel kürzt mit run die Ausgabe der aktuellen Konfiguration ohne SSH Keys.
Grafisches Web Browser Interface (WebGUI) installieren und Management Zugang absichern:
Vorab: Mit modernen Browser Versionen ist das CCP Express Tool für die 800er Modelle ggf. nicht mehr nutzbar! Alle aktuellen ISR Modelle sind davon generell nicht betroffen, denn diese haben schon von sich aus ein GUI an Bord.
Die Kommandozeile ist sicher nicht immer jedermanns Freund und natürlich hat der Cisco mit dem Cisco Configuration Professional Express oder kurz CCP Express Admin View auch ein grafisches Browser Interface zum Konfigurieren.
Neue Router kommen damit ausgestattet zum Käufer aber viele gebraucht erworbene oder solche wo es vom Flash gelöscht wurde, haben es nicht. Ob es bereits installiert ist, sieht man mit dem Befehl show flash:
Die Installation oder ein Update auf die aktuelle Version ist aber im Handumdrehen erledigt. Ggf. vorhandene alte Versionen sollte man dazu, wie unten beschrieben, immer VORHER vollständig vom Flashspeicher des Routers löschen!
Los gehts...
Zuerst läd man dazu das Cisco CP Express Tool HIER herunter. Im Cisco Download ist es wegen EoS nicht mehr verfügbar. Aktuell ist derzeit das Release 3.5.2 (Stand 07.2018).
Dann entZIPt man das ZIP Archiv und kopiert die .tar und die .gz Datei in ein Verzeichnis.
Um die CCP Dateien auf das Router Flash zu bekommen nutzt man am besten und schnellsten einen USB Stick über die USB Frontbuchse. Alternativ ist ein TFTP Server erforderlich.
Ideal ist der Klassiker TFTP32 bzw. sein 64Bit Pendant oder der Pumpkin unter Windows. Apple Mac und Linux User haben TFTP von sich aus gleich an Bord.
Die Prozedur den TFTP aufzusetzen ist immer gleich und HIER am Beispiel der Cisco Telefone genau beschrieben.
Gleiches macht man ebenso für den Router. Auch z.B. wenn man die Router Firmware einmal updaten möchte oder auch die xDSL Modem Firmware wie oben beschrieben anpasst.
Router und TFTP Server sollten sich zum Vorabcheck pingen lassen untereinander. Bei Windows an die lokale Firewall denken das diese TFTP Traffic passieren lässt !
Der Rest ist schnell gemacht:
router> enable
Password: password
router# copy tftp: flash
Address or name of remote host ? <---Hier die TFTP Server IP Adresse angeben
Source filename ? ccpexpressAdmin_x_y_en.tar <--- Hier den CP Express .tar Dateinamen angeben. (x und y ist die Versionsnummer)
Destination file name ? ccpexpressAdmin_x_y_en.tar <--- Einfach Dateiname mit <Return> Taste bestätigen !
Damit wird dann die .tar Datei auf das Router Flash übertragen.
Wer es ganz einfach machen will nimmt einen USB Stick kopiert den Cisco Express Admin View Tar File ohne Unterverzeichnis einfach darauf und steckt den Stick in den Router USB Port.
Ein copy usbflash0:ccpexpressAdmin_x_y_en.tar flash: (Dateiname wie im Download, x.y = Versionsnummer)
kopiert dann die Datei in den Router Flash Speicher.
Im Anschluss muss diese .tar Archiv Datei noch mit dem folgenden Kommando extrahiert werden. (.tar ist unter Unix sowas wie .zip unter Windows)
router# archive tar /xtract flash:ccpexpressAdmin_x_y_en.tar flash:/ (x_y = Versionsnummer)
Nun muss nur noch der HTTP Server auf dem Router mit
router> conf t
router-conf#> ip http server
aktiviert werden. Wer es gerne sicher verschlüsselt hätte, der nimmt entsprechend:
router-conf#> ip http secure-server
Die Authentisierung sollte noch auf den lokalen Usernamen und Passwort eingestellt werden mit ip http authentication local und das das Web GUI ausschliesslich aus dem lokalen Netz erreichbar ist: ip http access-class 23
Jetzt ist das grafische Web GUI über die LAN IP des Routers mit dem Web Browser erreichbar.
Die HTTP Konfig sieht dann so aus:
!
aaa new-model
aaa authentication login default local
!
enable secret Geheim123
!
username admin password Geheim123
!
ip http server
ip http secure-server
ip http access-class 23 ---> Bindet das Web GUI an die Access Liste 23. Ggf. weglassen wer das WebGUI von überall erreichen will. (Nicht empfehlenswert, Sicherheit !!)
!
access-list 23 permit 192.168.100.0 0.0.0.255
!
line vty 0 4
access-class 23 in ---> Lässt den Management Zugang nur aus dem lokalen LAN zu !
password geheim1234
transport input all ---> Wer nur SSH zulassen will (kein Telnet) ändert all in ssh !
!
⚠️ Der Webserver erfordert als Login immer den Usernamen der mit "username xy password xyz" in der Konfig gesetzt wurde aber als Passwort das enable secret Passwort !!!
Dies bitte beachten wenn man keinen Frust beim Web Login erleben will.
Da hier in der Basiskonfig oben enable secret Geheim123 und auch im Usernamen admin im Beispiel Geheim123 gleiche Passwörter gesetzt wurden passt es hier im Beispiel zufälligerweise.
Wer aber aus gutem Grund unterschiedliche Passwörter für das enable secret und den Usernamen verwendet hat sollte das zwingend beachten:
Web GUI Login: Username=Username und das Passwort ist das enable-secret Passwort !
Zum Entfernen des GUIs vom Router Flash sind folgende 2 Konfig Schritte erforderlich.
router# delete /force /recursive home.shtml
router# delete /force /recursive flash:ccpexp
Die noch auf dem Flash befindliche .tar Archiv Datei kann man nach dem Installieren oder Update beruhigt löschen mit:
router# del flash:<Dateiname.tar>
Applikationsbasierten Traffic mit NBAR auswerten
NBAR (Network-Based Application Recognition) ist ein Router Backend zur protokollspezifischen Traffic Erkennung und Klassifizierung. NBAR klassifizierter Traffic kann für QoS, Firewall und auch NetFlow Reporting verwendet werden. Alle NBAR Optionen zu beschreiben würde den Rahmen dieses Tutorials sprengen so das im Folgenden nur die Grundinstallation gezeigt wird.
Zuerst muss die NBAR Protokoll-Pack Datei downgeloaded und installiert werden. Diese Datei ist IOS versionsspezifisch, also auf die passende Version achten die zur Firmware passt (Release Notes!)!
Das globale Kommando um die Protocol Pack Datei zu laden lautet:
ip nbar protocol-pack flash:pp-adv-isrg2-158-3.M-23-32.3.0.pack
Die Protokollanalyse aktiviert man dann z.B. auf dem lokalen LAN Interface:
interface Vlan1
description Lokales LAN
ip address 192.168.100.254 255.255.255.0
ip nbar protocol-discovery
ip nat inside
Eine einfache Protokoll Statistik erhält man z.B. mit
show ip nbar protocol-discovery
Die Top 5 Talker im Netzwerk in Bezug auf Protokollnutzung zeigt ein:
cisco_router#show ip nbar protocol-discovery top-n 5
Input Output
----- ------
Protocol Packet Count Packet Count
Byte Count Byte Count
5min Bit Rate (bps) 5min Bit Rate (bps)
5min Max Bit Rate (bps) 5min Max Bit Rate (bps)
---------------------------- ------------------------ ------------------------
https 4182 41748
734751 56500832
2000 567000
19000 755000
ms-update 1036 2680
120626 3690859
0 0
6000 106000
youtube 215 469
33765 499280
0 0
3000 9000
ssl 356 396
69959 166293
0 0
5000 6000
Total 6876 46347
1143737 61316453
2000 567000
42000 900000 Die globalen Kommandos
ip nbar classification auto-learn { top-hosts | top-ports }
aktivieren diese Funktion und entsprechende show Kommandos liefern den Output.
cisco_router#sh ip nbar classification auto-learn top-hosts 10
Total bytes: 1.209 M
Total packets: 2.404 K
Total flows: 94
Sample rate last: 26
Sample rate average: 17
Sample rate min: 16
Sample rate max: 45
-------------------------------------------------------------------------------------------------------------------
#|Host |Byte%|Flow%|Pkt% |Type |Field
-------------------------------------------------------------------------------------------------------------------
1|administrator.de | 57% | 82% | 45% |ssl |host
2|collector-hpn.ghostery.net | 42% | 17% | 54% |ssl |host
cisco_router#show ip nbar classification auto-learn top-sockets 10 detailed
Total bytes: 398.747 K
Total packets: 1.611 K
Total flows: 1.109 K
Sample rate last: 1
Sample rate average: 1
Sample rate min: 1
Sample rate max: 1
-----------------------------------------------------------------------------------------
#|Port |IP |Byte count |Byte%|Flow |Flow%|Pkt |Pkt% |Traffic |Asymmetric
| | | | |count| |count | |Type |byte
| | | | | | | | | |count
-----------------------------------------------------------------------------------------
1|80 |173.38.201.172 | 81.776 K | 20% | 4 | <1% | 90 | 5% |TCP |0
2|80 |173.38.201.174 | 74.555 K | 18% | 4 | <1% | 84 | 5% |TCP |0
3|123 |10.56.129.33 | 42.672 K | 10% |889 | 80% |889 | 55% |UDP |N/A Weiterführende Infos zum Thema NBAR liefert der NBAR Configuration Guide.
Netzwerk Traffic mit NetFlow / IPFIX visualisieren
Dies beschreibt ein separates Forentutorial.
Cisco 880er Hardware
Mehr RAM Speicher für den Cisco 886va:
Vorbemerkung:Die folgende Anleitung gilt nur für die älteren nicht K9 Modelle ! Wer also einen 88x K9 hat oder z.B. einen 886vaw (wireless) hat keinen internen RAM Slot mehr, sondern immer fest 512 MB onboard ohne Aufrüstmöglichkeit !
In der Regel erkennt man diese neueren Modelle daran das sie keinen Gehäuse Lüfter mehr haben.
Wer das 880er Model gebraucht erwirbt, sollte einen Blick auf die RAM Ausstattung des Routers werfen ! Die einfache Variante kommt mit 256 MB Onboard RAM daher. Für eine anspruchsvolle Konfiguration kann das schnell zu wenig sein, denn der Router braucht dann mehr RAM fürs Puffern von Daten, Firewall Prozesse, Routing Tabelle usw.
Der Router bietet einen freien SO-DIMM Steckplatz wie man ihn auch aus Laptops oder Notebooks her kennt. Diesen kann man max. mit einem Standard 512 MB SO-DIMM bestücken um dann in Summe auf 768 MB RAM Speicher zu kommen. Diese Aufrüstung ist in jedem Falle empfehlenswert, sollte der Router weniger RAM haben.
Auskunft über die aktuelle RAM Ausstattung bekommt man mit dem show version Kommando.
Dort sieht man u.a. eine Zeile mit folgendem Inhalt:
Cisco 886VA (MPC8300) processor (revision 1.0) with 708608K/77824K bytes of memory.
Wer diesen Output bekommt hat schon die Maximalausstattung.
Steht allerdings ein "...with 208608K/77824K bytes of memory" dort, läuft der Router nur mit dem schmalen 256 MB onboard Memory. (Leerer RAM Slot)
Der Cisco 886va verwendet Standard SO-DIMM Module mit 512MB wie man sie z.B. HIER recht preiswert neu bekommt.
Man erhält aber solche SO-DIMM Module mit der Spezifikation DDR2-533 PC2-4200S CL4 2Rx16 auch für noch weniger Geld wenn man bei den einschlägigen Auktionshäusern danach sucht. Sie sind sehr häufig auch in Laptops und Notebooks verwendet worden und bei einer RAM Aufrüstung dann übrig geblieben.
Die Aufrüstung des Cisco's ist schnell gemacht.
Man löst die 3 Gehäuseschrauben und klappt den Gehäusedeckel von hinten nach vorne in Richtung Frontpanel auf. Der SO-DIMM Slot befindet sich rechts. (Es gibt nur einen einzigen !)
Beim Booten sollte der Router dann die automatisch erkannten 768 MB melden oder eben mit dem o.a. show version Kommando.
Das 89x Modell kommt ab Werk mit 512MB onboard und kann auf max. 1Gig aufgerüstet werden. Auch hier sollte man mit dem show version Kommando vorher prüfen wieviel RAM verbaut ist.
PoE Nachrüstung:
Ab Werk ist kein 880er Router mit der nötigen PoE Erweiterungskarte ausgestattet. Ist man sich nicht sicher ob das Gerät bereits über eine PoE Erweiterungskarte verfügt, kann ein "show power inline" Befehl Aufschluss geben. Ohne PoE im Router quittiert dieser dies mit einer Fehlermeldung.
PoE LAN Ports können dann VoIP Telefone oder WLAN APs usw. bedienen.
Je nach Variante muß noch intern ein Stromkabel montiert werden. Nach dem Anschluß des mitgelieferten, stärkeren Stecker Netzteils hat man nun auf den mit "PoE" beschrifteten LAN Ports eine Standard konforme PoE Stromversorgung anliegen.
Es können nur Geräte mit dem IEEE PoE Standard 802.3af angeschlossen werden. Zusätzliche Informationen zur PoE Aufrüstung findet man in einem YouTube Video.
Weiterführende Links:
Grundlagen
Wie Anfängerprobleme bei der Cisco Konfig vermeiden ?:VoIP hinter Cisco Router
Routing Telekom VDSL mit cisco 896VA
CISCO 926-4P SEC Lizenz ,CLM oder Installation Lizenz USB und Zone Based Firewall <== (ZFW Firewall für IPv4 und IPv6)
Cisco IOS und IOS XE Kommando Syntax Überblick:
http://www.coufal.info/cisco_ios/index.shtml
https://www.r33net.de/cisco-router-konfiguration-befehlecommands/
https://www.cisco.com/c/en/us/td/docs/routers/access/800/software/config ...
https://www.cisco.com/c/en/us/td/docs/routers/access/isr1100/software/co ...
Troubleshooting: Paket Capture im Wireshark Format auf Cisco:
https://www.youtube.com/watch?v=5ppEIzilUsc
Hardware
Den seriellen Konsolen Port sicher meistern:Serial Console Kabel - Rollover Console Kabel - Adapter
Keine serielle Verbindung zu Cisco 886W
Infos zu SEC Lizenzen (Firewall + VPN) für neuere ISR Modelle z.B. 900 und 1100:
Cisco Router Lizenzen
Quelle: https://www.ethcon.de
880er Modelle, Annex-J Modem Software und VDSL Vectoring:
Kann der Cisco 866VAE VDSL-Vectoring? (und ein Blick in die DSL-Firmware)
VDSL Controller bei C886VA und C896VA einmalig für acht Sekunden UP
PPPoE Konfig Tips für das Dialer Interface:
https://www.cisco.com/c/de_de/support/docs/wan/point-to-point-protocol-p ...
Externes xDSL Modem wie Dratek Vigor 165, Zyxel VMG3006 usw. verwenden:
Cisco 881, virtual-interface bleibt UP, auch wenn das Modem ausgeschaltet ist
Cisco ISR 1100 Router Modell Überblick:
https://www.ciscolive.com/c/dam/r/ciscolive/emea/docs/2020/pdf/BRKARC-20 ...
Firewall, Accesslisten und VPN
Port Forwarding mit ZFW Firewall absichern:Cisco router with zone based firewall and port forwarding
Cisco VPN mit ZFW Firewall zu Mikrotik oder FritzBox:
Cisco IPsec VPN with Mikrotik or FritzBox
Grundlagen ZFW Firewall inkl. Rate Limiting:
https://www.youtube.com/watch?v=ZmmvQH0seEc
Richtiger Umgang mit IP Access Listen auf dem Router:
Cisco 866VAE-K9 ACL-Konfiguration
Management Zugriff auf dem Cisco wasserdicht absichern:
https://www.cisco.com/c/de_de/support/docs/ip/access-lists/13608-21.html
Cisco Router mit Layer 3 Switch und DMZ generell:
Konfiguration Cisco 886VA-J und SG300
L2TP Client VPN für Windows, Mac und Smartphones:
https://community.cisco.com/t5/security-documents/l2tp-over-ipsec-on-cis ...
Fehler im L2TP Client VPN Setup vermeiden:
L2TP VPN Fehler sicher umschiffen
L2TP Site to Site (Standort) Anbindung mit Mikrotik:
MikroTik Router als VPN Client
iPhone und iPad bzw. generelles Client VPN Dialin mit IPsec:
Anbindung eines iPhone an einen Cisco Router mit dynamischer ISP Adressse via IPSec VPN über den iPhone Cisco Client
und auch:
IPsec IKEv2 VPN für mobile Benutzer auf der pfSense oder OPNsense Firewall einrichten
IPsec VPN als Client oder Standort zu Standort mit Cisco, pfSense, Mikrotik, IP-Cop oder FritzBox:
IPsec VPNs einrichten mit Cisco, Mikrotik, pfSense Firewall, FritzBox, Smartphone sowie Shrew Client Software
IPsec VPN Praxis mit Standort Vernetzung Cisco, Mikrotik, pfSense, FritzBox u.a
und auch:
Vernetzung zweier Standorte mit Cisco 876 Router
VPN Standort Kopplung mit VTI Tunnel Interface:
Cisco SVTI - Tunnel
2921 Kaskadierung mit Fritzbox für IPSEC-Tunnel
VPN IPsec Standort Kopplung Cisco-Mikrotik mit GRE Tunnel und dyn. Routing (RPv2 / OSPF):
Cisco, Mikrotik, pfSense VPN Standort Vernetzung mit dynamischem Routing
Zwischen Miktrotik und PFSense GRE Tunnel mit IPSec Verschlüsslung
VPN IPsec IKEv2 Standort Kopplung Cisco mit pfSense oder Mikrotik:
IPsec IKEv2 Standort VPN Vernetzung mit Cisco, pfSense OPNsense und Mikrotik
Praxisbeispiele
Cisco Router Konfig an einem T-Com Business VDSL Anschluss:Cisco 866vae vdsl t-business feste ip - ip wird nicht erhalten
Cisco Router Konfig an einem alternativen VDSL Provider (Wilhelm.Tel):
Cisco 886VAW mit vDSL2 an SAGA Wilhelm Tel Leitung verliert dauernd die Verbindung
IPv6 DNS Konfiguration per RA oder DHCPv6 richtig einrichten:
DHCPv6 mit DNS unter Cisco IOS einrichten
IPv6 Netze per PD intern an Router/Firewall weitergeben
IPv6 Konfiguration über Tunnel Broker (Hurricane Electric):
IPv6 Konfig mit Tunnel im Cisco 886
Cisco Router mit L3 VLAN Switch Cisco CBS/SG sinnvoll koppeln:
Konfiguration Cisco 886VA-J und SG300
Port Forwarding vom Internet auf Rechner im lokalen LAN:
Cisco 886va VDSL Ports Weiterleiten ???
Mobilfunk Modell des 880ers konfigurieren:
https://www.youtube.com/watch?v=lGmh1JVKu5U
Tips zum SIP Setup (VoIP/Telefonie) Setup des Cisco 886 Routers:
Cisco 886VA, Gigaset C610-IP: ausgehende Telefonate nicht möglich
Cisco 880 mit Voice Option konfigurieren:
Cisco 887VA Konfiguration für SIPGATE-Trunking
Cisco IOS Automation mit Ansible:
https://www.youtube.com/watch?v=wbVZkb8ocH4
Beispiele zum VLAN Setup der Switchports und WLAN mit MSSID:
VLAN Installation und Routing mit pfSense, Mikrotik, DD-WRT oder Cisco RV Routern
Weitere Cisco Beispielkonfigurationen:
2921 sicher aufbauen für Internet
Cisco hat Internet - Computer nicht
Routing mit öffentlichem Subnetz
Cisco 926 mit Dual Stack und ZFW Beispielkonfig
Filterliste bei DHCP-Client statt PPPoE am WAN / Internet Port:
Cisco 2811 holt sich keine DCHP Adresse am FastEthernet interface
Tiefergehende Infos und HowTo's zur Cisco ZFW Firewall:
https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/sec_data_zbf/configura ...
http://brbccie.blogspot.com/2013/04/zone-based-firewall.html
https://www.cisco.com/en/US/prod/vpndevc/ps5708/ps5710/ps1018/prod_confi ...
Infrastruktur Protokoll mit LLDP
LLDP und FRITZ!Box 7530
Zusatzinfo zum IP-TV Entertain mit Cisco Multicasting via VDSL:
Cisco IOS Entertain IP-TV Konfig ?
Magenta TV und Cisco IOS
http://www.cisco-forum.net/topic_4350.0.html
(Non Cisco) Magenta TV mit Mikrotik:
Speedport W 724V + Routerboard 450G + VDSL (all IP) + Entertain
(Non Cisco) Magenta TV mit pfSense / OPNsense:
https://heise.de/-4698826
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 179345
Url: https://administrator.de/tutorial/cisco-880-890-und-isr-router-konfiguration-mit-xdsl-kabel-oder-ftth-anschluss-plus-vpn-und-ip-tv-179345.html
Ausgedruckt am: 26.12.2024 um 21:12 Uhr
266 Kommentare
Neuester Kommentar
Hallo,
so, wer jetzt noch ein Problem mit der Konfiguration hat, dem ist nicht mehr zu helfen..
Das einzige Problem ist das finden dieses super Tutorials.
Danke aqui
brammer
so, wer jetzt noch ein Problem mit der Konfiguration hat, dem ist nicht mehr zu helfen..
Das einzige Problem ist das finden dieses super Tutorials.
Danke aqui
brammer
1
Hi,
na dann gibt doch mal "Konfiguration Cisco 886va" in die Google Suche ein!
Gruß
Frank
Webmaster
na dann gibt doch mal "Konfiguration Cisco 886va" in die Google Suche ein!
Gruß
Frank
Webmaster
Hallo,
Frank
Dass deine Suche Funktioniert wissen wir doch
Nur ein paar resistente User ignorieren das vorhanden sein dieser sehr Sinnvolle Funktion...
btw.:
Könntest du bitte unter FAQ > Fragen und Antworten noch Sarkasmus Tags zur Verfügung stellen?
brammer
Frank
Dass deine Suche Funktioniert wissen wir doch
Nur ein paar resistente User ignorieren das vorhanden sein dieser sehr Sinnvolle Funktion...
btw.:
Könntest du bitte unter FAQ > Fragen und Antworten noch Sarkasmus Tags zur Verfügung stellen?
brammer
Hallo aqui,
sehr schön... an Weihnachten hätte deine Anleitung brauchen können.
Ansonsten sagt die Anleitung alles. Davon könnten sich einige Autoren eine Scheibe abschneiden.
Grüße,
Dani
sehr schön... an Weihnachten hätte deine Anleitung brauchen können.
Ansonsten sagt die Anleitung alles. Davon könnten sich einige Autoren eine Scheibe abschneiden.
Grüße,
Dani
1
Hi,
dazu muss ich sagen, dass es echt eine sehr schöne Anleitung ist! Hatte bei dem selbst konfigurieren doch so das ein oder andere Prob... ;)
Änderung 17.08.2012: Es funktioniert! Alles prima und super - nochmal danke für die Anleitung! ;)
dazu muss ich sagen, dass es echt eine sehr schöne Anleitung ist!
Hatte bei dem selbst konfigurieren doch so das ein oder andere Prob... ;)Änderung 17.08.2012: Es funktioniert! Alles prima und super - nochmal danke für die Anleitung! ;)
1
Hallo,
weiß jemand wie ich an das PDF Tutorial zur Einrichtung von IP-TV komme??
Bzw hat es jemand schonmal geschaut Telekom Entertain mit einer Fortinet Firewall zum laufen zu bringen?
Bin über jeden Hinweis dankbar.
Vielen Dank!
weiß jemand wie ich an das PDF Tutorial zur Einrichtung von IP-TV komme??
Bzw hat es jemand schonmal geschaut Telekom Entertain mit einer Fortinet Firewall zum laufen zu bringen?
Bin über jeden Hinweis dankbar.
Vielen Dank!
Hallo,
Der blaue schriftteil im Tutorial von @aqui ist ein link.
Und für deine frage zur Fortinet machst du besser einen neuen Beitrag.
Brammer
Der blaue schriftteil im Tutorial von @aqui ist ein link.
Und für deine frage zur Fortinet machst du besser einen neuen Beitrag.
Brammer
Danke Dir. Aber hast Du Dir mal den Link angeschaut? Da komme ich auf eine komische Seite und müsste mir eine exe installieren...
Das ist natürlich Unsinn mit der .exe zum Installieren.
Das Tutorial oben hat ein extra Kapitel was das Thema IP-TV dediziert behandelt!
Auch mit der Fortinet ist das kein Thema wenn du dort Multicast Forwarding aktivierst wie es im o.a. Cisco TV PDF beschrieben ist. Es ist die identische Prozedur nur eben mit Fortinet Syntax.
Das Tutorial oben hat ein extra Kapitel was das Thema IP-TV dediziert behandelt!
Auch mit der Fortinet ist das kein Thema wenn du dort Multicast Forwarding aktivierst wie es im o.a. Cisco TV PDF beschrieben ist. Es ist die identische Prozedur nur eben mit Fortinet Syntax.
Vielen lieben Dank! Da stand ich wohl auf dem Schlauch.
Dann denkst Du sollte IPTV bei mir auch mit der Fortinet problemlos funktionieren? Habe ja dazu noch ein Zyxkel Modem an WAN1 hängen welches im Bridge Mode läuft. Habe bei mir 'nur' das Problem, dass das Bild nach ca 10 Sekunden einfriert.Sprich wenn er auf Multicast umschaltet. Gibt es hier vielleicht noch Fortinet Spezialisten? Komme nicht ganz zurecht mit der Umsetzung der Cisco Befehle auf Fortinet. Hauptsächlich wie ich die IP Adresse des Multicast Routers der Telekom herausfinde
Vielen Dank!
Dann denkst Du sollte IPTV bei mir auch mit der Fortinet problemlos funktionieren? Habe ja dazu noch ein Zyxkel Modem an WAN1 hängen welches im Bridge Mode läuft. Habe bei mir 'nur' das Problem, dass das Bild nach ca 10 Sekunden einfriert.Sprich wenn er auf Multicast umschaltet. Gibt es hier vielleicht noch Fortinet Spezialisten? Komme nicht ganz zurecht mit der Umsetzung der Cisco Befehle auf Fortinet. Hauptsächlich wie ich die IP Adresse des Multicast Routers der Telekom herausfinde
Vielen Dank!
Es kommt auf die Fortinet an ?! Wenn sie diese Multicast Features, insbesondere PIM Routing oder IGMP Proxy, supportet ist das kein Ding. Das solltest du aber wasserdicht im Datenblatt oder Manual der Fortinet klären.
Um die Multicast IP des T-Com Routers rauszubekommen müsste die Fortinet auch so eine Debugging Möglichkeit haben wie der Cisco, da hast du Recht. Das brauchst du zwingend damit das stabil rennt. In der Regel gibt es aber auch bei bessen Firewalls (zu denen man Fortinet ja zählen kann) sowas.
Um die Multicast IP des T-Com Routers rauszubekommen müsste die Fortinet auch so eine Debugging Möglichkeit haben wie der Cisco, da hast du Recht. Das brauchst du zwingend damit das stabil rennt. In der Regel gibt es aber auch bei bessen Firewalls (zu denen man Fortinet ja zählen kann) sowas.
Ja Multicast kann meine Fortinet. Habe auch schon Multicast Policies angelegt. Mir fehlt scheinbar nur noch die Möglichkeit wie ich die IP Adresse des Multicast Routers der Telekom herausfinden kann.
Vieleicht hilft es jemand im Home-IP TV Konfiguration. Der Link zum PDF ist schon etwas alt, und der Rendez Vous Point IP kann einfacher ermittelt werden. Die Routen zu rp-address wird über DHCP mitgeteilt. Wenn das interface Ethernet0.8 korrekt konfiguriert ist, kommt es mit einer 10.X.X.X hoch, und es werden 2 Routen gelernt. show dhcp lease zeigt dann etwas wie (abhängig vom Ort):
Temp ip static route0: dest 193.158.132.189 router 10.34.63.254
Temp ip static route0: dest 87.141.128.0 router 10.34.63.254
In meinen Fall ist der RP die 87.141.128.0.
Temp ip static route0: dest 193.158.132.189 router 10.34.63.254
Temp ip static route0: dest 87.141.128.0 router 10.34.63.254
In meinen Fall ist der RP die 87.141.128.0.
1
Hallo Captain !
Danke für den hilfreichen Tip ! Ich werde das Tutorial entsprechend anpassen !
Danke für den hilfreichen Tip ! Ich werde das Tutorial entsprechend anpassen !
Hi, ich bekomme demnächst einen Dual-Stack Anschluss. Hat jemand den IPv6 Teil der Config für den SLAAC (WAN) und DHCP PD (LAN) Teil?
Nachdem die Telekom vor einigen Wochen meinen ISDN-Anschluss zwangsweise migriert hat, habe ich zu Testzwecken eine IPv6 Konfiguration gebaut, die keinen Anspruch auf Vollständigkeit und Fehlerfreiheit erhebt, aber sicher als Startpunkt für eigene Gehversuche dienen kann.
Da auch im internen Netz öffentliche IPv6-Adressen zum Einsatz kommen, sind alle Klienten End-to-End ohne NAT aus dem Internet erreichbar, so dass als erstes ein wichtiger Hinweis folgt…
HINWEIS: Als erstes sind zwingend die ACLs und die Firewall zu konfigurieren!!!
Entsprechend gibt es zunächst ein paar Vorarbeiten:
Der Router wird weiterhin aus dem internen Netz ausschließlich über IPv4 administriert und somit alle Remote-Zugänge über IPv6 gesperrt. Leider ändert die Telekom nicht nur die externe IPv6-Adresse täglich, sondern auch das /56 Präfix für die internen Netze. Wer also intern via IPv6 auf den Router zugreifen will, müsste die ACL somit täglich anpassen, was man aber über EEM automatisieren könnte, oder zusätzlich mit Unique Local Adressen (FC00::/7) arbeiten.
Dann folgt die ACL für die externe WAN-Schnittstelle. Die ersten beiden Zeilen stehen zwar als Default implizit vor dem erwarteten impliziten „deny ipv6 any any“, aber da ich am Ende mit einem expliziten Deny arbeite, sind sie zwingend notwendig, damit die Neighbor Discovery funktioniert.
Danach wird UDP Port 546 geöffnet, der DHCP Client Port für IPv6. Die weiteren Einträge dienen vor allem dazu, über die Matches zu sehen, was an Traffic über die Schnittstelle läuft.
Nun die Firewall-Regeln:
Neben dem Binden der ACL und Firewall-Regeln auf die WAN-Schnittstelle, setzen wir auch gleich ein paar weitere Einstellungen:
Jetzt kommen wir endlich zur Konfiguration der IPv6-Adressen und des Pools für die internen Klienten. Die Telekom weist uns nicht nur eine IPv6-Adresse für die WAN-Schnittstelle zu, sondern auch ein /56 Präfix für unsere internen Netze, dass sich aber leider ebenfalls täglich ändert. Dieses Präfix wird einem DHCPv6-Pool zugewiesen, so dass der Router intern als DHCPv6-Server agieren kann. Man kann hier stattdessen auch nur SLAAC verwenden, aber DHCPv6 bietet natürlich mehr Optionen und Kontrolle.
Zum Abschluss müssen nun noch das IPv6-Routing und CEF aktiviert werden.
Mit einem "clear interface dialer 0" können wir uns dann die ersten IPv6-Adressen vom Provider holen.
Auf internen Windows-Clients reicht jetzt ein “ipconfig /renew”, um sich eine öffentliche IPv6-Adresse zu holen und testweise mal einen IPv6-Ping abzusetzen:
…und noch ein paar nützliche SHOW-Befehle, aus Platzgründen mit leicht gekürztem Output und natürlich geänderten Adressen:
Da auch im internen Netz öffentliche IPv6-Adressen zum Einsatz kommen, sind alle Klienten End-to-End ohne NAT aus dem Internet erreichbar, so dass als erstes ein wichtiger Hinweis folgt…
HINWEIS: Als erstes sind zwingend die ACLs und die Firewall zu konfigurieren!!!
Entsprechend gibt es zunächst ein paar Vorarbeiten:
Der Router wird weiterhin aus dem internen Netz ausschließlich über IPv4 administriert und somit alle Remote-Zugänge über IPv6 gesperrt. Leider ändert die Telekom nicht nur die externe IPv6-Adresse täglich, sondern auch das /56 Präfix für die internen Netze. Wer also intern via IPv6 auf den Router zugreifen will, müsste die ACL somit täglich anpassen, was man aber über EEM automatisieren könnte, oder zusätzlich mit Unique Local Adressen (FC00::/7) arbeiten.
!
ipv6 access-list BLOCKv6
deny ipv6 any any log-input
!
line vty 0 4
ipv6 access-class BLOCKv6 in
! Danach wird UDP Port 546 geöffnet, der DHCP Client Port für IPv6. Die weiteren Einträge dienen vor allem dazu, über die Matches zu sehen, was an Traffic über die Schnittstelle läuft.
!
ipv6 access-list WAN_OUTSIDE_INv6
permit icmp any any nd-na sequence 10
permit icmp any any nd-ns sequence 11
permit udp any any eq 546 sequence 12
permit icmp any any sequence 20
permit tcp any any established sequence 40
deny ipv6 any any log-input sequence 100
!
ipv6 access-list WAN_INSIDE_OUTv6
permit icmp any any sequence 10
permit tcp any any sequence 20
permit udp any any sequence 30
deny ipv6 any any log-input sequence 100
! !
ipv6 inspect name FWv6 tcp
ipv6 inspect name FWv6 udp
ipv6 inspect name FWv6 icmp
! !
interface Dialer0
no ipv6 redirects
no ipv6 unreachables
ipv6 verify unicast reverse-path
ipv6 traffic-filter WAN_OUTSIDE_INv6 in
ipv6 traffic-filter WAN_INSIDE_OUTv6 out
ipv6 inspect FWv6 out
! !
ipv6 dhcp pool TELEKOMv6_POOL
prefix-delegation pool TELEKOMv6_PREFIX
import dns-server
domain-name testdomain.local
!
interface Dialer0
ipv6 address FE80::179:1 link-local
ipv6 address autoconfig default
ipv6 enable
ipv6 dhcp client pd TELEKOMv6_PREFIX
!
interface Vlan1
ipv6 address FE80::178:1 link-local
ipv6 enable
ipv6 address TELEKOMv6_PREFIX ::1/64
ipv6 nd other-config-flag
ipv6 dhcp server TELEKOMv6_POOL
! !
ipv6 unicast-routing
ipv6 cef
! Auf internen Windows-Clients reicht jetzt ein “ipconfig /renew”, um sich eine öffentliche IPv6-Adresse zu holen und testweise mal einen IPv6-Ping abzusetzen:
C:\Users\Ciscoholic>ping -6 www.heise.de
Pinging www.heise.de [2a02:2e0:3fe:1001:7777:772e:2:85] with 32 bytes of data:
Reply from 2a02:2e0:3fe:1001:7777:772e:2:85: time=26ms
Reply from 2a02:2e0:3fe:1001:7777:772e:2:85: time=21ms
Reply from 2a02:2e0:3fe:1001:7777:772e:2:85: time=22ms
Reply from 2a02:2e0:3fe:1001:7777:772e:2:85: time=21ms
Ping statistics for 2a02:2e0:3fe:1001:7777:772e:2:85:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 21ms, Maximum = 26ms, Average = 22ms
C:\Users\ Ciscoholic >Cisco886va#show ipv6 dhcp interface
Dialer0 is in client mode
Prefix State is OPEN (0)
Information refresh timer expires in 23:58:45
Renew will be sent in 00:13:45
Address State is IDLE
List of known servers:
Reachable via address: FE80::233:44FF:FE55:6677
DUID: 0001000100010001000100010001
Preference: 0
Configuration parameters:
IA PD: IA ID 0x000F0001, T1 900, T2 1440
Prefix: 2003:6F:1234:5600::/56
preferred lifetime 1800, valid lifetime 14400
expires at Aug 12 2015 08:30 PM (14326 seconds)
DNS server: 2003:180:2:1000:0:1:0:53
DNS server: 2003:180:2:5000:0:1:0:53
Information refresh time: 0
Prefix name: TELEKOMv6_PREFIX
Prefix Rapid-Commit: disabled
Address Rapid-Commit: disabled
Vlan1 is in server mode
Using pool: TELEKOMv6_POOL
Preference value: 0
Hint from client: ignored
Rapid-Commit: disabled
Cisco886va#show ipv6 interface dialer 0
Dialer0 is up, line protocol is up
IPv6 is enabled, link-local address is FE80::179:1
No Virtual link-local address(es):
Description: VDSL Internet Dial-Up Connection
Stateless address autoconfig enabled
Global unicast address(es):
2003:6F:1234:ABCD::179:1, subnet is 2003:6F:1234:ABCD::/64 [EUI/CAL/PRE]
valid lifetime 14307 preferred lifetime 1707
Joined group address(es):
FF02::1
FF02::2
FF02::1:FF79:1
MTU is 1500 bytes
ICMP error messages limited to one every 100 milliseconds
ICMP redirects are disabled
ICMP unreachables are disabled
…
Inbound access list WAN_OUTSIDE_INv6
IPv6 verify source reachable-via rx, allow default
108 verification drop(s) (process), 0 (CEF)
0 suppressed verification drop(s) (process), 0 (CEF)
Outbound Inspection Rule FWv6
Outgoing access list WAN_INSIDE_OUTv6
…
ND RAs are suppressed (periodic)
Hosts use stateless autoconfig for addresses.
Cisco886va#show ipv6 interface vlan 1
Vlan1 is up, line protocol is up
IPv6 is enabled, link-local address is FE80::178:1
No Virtual link-local address(es):
Description: Internes LAN
General-prefix in use for addressing
Global unicast address(es):
2003:6F:1234:5600::1, subnet is 2003:6F:1234:5600::/64 [CAL/PRE]
valid lifetime 14235 preferred lifetime 1635
Joined group address(es):
FF02::1
FF02::2
FF02::1:2
FF02::1:FF00:1
FF02::1:FF78:1
FF05::1:3
MTU is 1500 bytes
…
ND router advertisements are sent every 200 seconds
ND router advertisements live for 1800 seconds
ND advertised default router preference is Medium
Hosts use stateless autoconfig for addresses.
Hosts use DHCP to obtain other configuration.
Cisco886va#show ipv6 route
IPv6 Routing Table - default - 7 entries
Codes: C - Connected, L - Local, S - Static, U - Per-user Static route
B - BGP, HA - Home Agent, MR - Mobile Router, R - RIP
H - NHRP, D - EIGRP, EX - EIGRP external, ND - ND Default
NDp - ND Prefix, DCE - Destination, NDr - Redirect, O - OSPF Intra
OI - OSPF Inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2, ON1 - OSPF NSSA ext 1
ON2 - OSPF NSSA ext 2, la - LISP alt, lr - LISP site-registrations
ld - LISP dyn-eid, a - Application
ND ::/0 [2/0]
via FE80::233:44FF:FE55:6677, Dialer0
S 2003:6F:1234:5600::/56 [1/0]
via Null0, directly connected
C 2003:6F:1234:5600::/64 [0/0]
via Vlan1, directly connected
L 2003:6F:1234:5600::1/128 [0/0]
via Vlan1, receive
NDp 2003:6F:1234:ABCD::/64 [2/0]
via Dialer0, directly connected
L 2003:6F:1234:ABCD::179:1/128 [0/0]
via Dialer0, receive
L FF00::/8 [0/0]
via Null0, receive
Cisco886va#
Bei neueren IOS-Versionen hat Cisco den Default-Wert für das PPP Throttling drastisch verschärft, so dass der Router nach einem IOS-Update plötzlich keine IP-Adresse mehr bekommt.
Mit einem „debug ppp negotiation“ sieht man dann folgende Zeilen:
Ursache ist ein (aktuell nicht öffentlich zugänglicher) Bug, bei dessen Behebung Cisco das PPP Throttling von offen wie ein Scheunentor auf extrem aggressive Werte geändert hat:
Bei mir sind die Verbindungsprobleme nach einem Update auf die aktuelle IOS-Version 15.4(3)M3 aufgetreten.
Die Lösung liegt in der Anpassung auf etwas moderatere Werte:
Mit diesen Werten funktioniert es wieder reibungslos.
…und dann stellt sich mir noch die Frage, wieso ihr noch die Authentifizierung mit PAP verwendet, obwohl die Telekom doch schon seit vielen Jahren CHAP unterstützt.
Also am besten die PAP-Zeilen ganz schnell löschen und durch die entsprechende CHAP-Authentifizierung ersetzen:
Mit einem „debug ppp negotiation“ sieht man dann folgende Zeilen:
Vi2 PPP: Control packet rate limit 10 reached
Vi2 PPP: Entering block state for 30 seconds
Vi2 PPP: Packet throttled, Dropping packet
vor CSCuo88855:
der Default waren 10.000 Packets in 3.600 sec ohne Blocking (ppp packet throttle 10000 3600 0)
nach CSCuo88855:
der Default sind 10 Packets in 1 sec mit 30 sec Blocking (ppp packet throttle 10 1 30)
Die Lösung liegt in der Anpassung auf etwas moderatere Werte:
ppp packet throttle 50 5 30
…und dann stellt sich mir noch die Frage, wieso ihr noch die Authentifizierung mit PAP verwendet, obwohl die Telekom doch schon seit vielen Jahren CHAP unterstützt.
Also am besten die PAP-Zeilen ganz schnell löschen und durch die entsprechende CHAP-Authentifizierung ersetzen:
interface dialer 0
ppp authentication chap callin
ppp chap hostname 00123456789012345678#0001@t-online.de
ppp chap password 1234567
Danke für den Hinweis !
Hier allerdings gibt es mit einer Version 15.4(3)M2 an einem T-Com Anschluss keinerlei Probleme und eine Anpassung zum obigen IPv6 Setup Kapitel im Tutorial ist in der Regel nicht erforderlich. Der Unterschied von M2 zu M3 sollte dabei marginal sein wenn man die Release Notes dazu liest.
Hier allerdings gibt es mit einer Version 15.4(3)M2 an einem T-Com Anschluss keinerlei Probleme und eine Anpassung zum obigen IPv6 Setup Kapitel im Tutorial ist in der Regel nicht erforderlich. Der Unterschied von M2 zu M3 sollte dabei marginal sein wenn man die Release Notes dazu liest.
Bin umgestiegen auf einen C887VA-W-E-K9 (vorher 876W, Umstieg wegen Vorbereitung auf VDSL)
mit Version 15.4(3)M2 kann ich das PPP Throttling Problem nachvollziehen.
(ADSL2+ Verbindung)
ppp packet throttle 50 5 30 hat es sofort gelöst.
Danke für den Hinweis.
mit Version 15.4(3)M2 kann ich das PPP Throttling Problem nachvollziehen.
(ADSL2+ Verbindung)
ppp packet throttle 50 5 30 hat es sofort gelöst.
Danke für den Hinweis.
1
Hat schon jemand einen Cisco Router an einem Telekom BNG ADSL Anschluss laufen ? Bei BNG Anschlüssen muss man das VLAN Tag 7 selber setzen, allerdings habe ich bisher kein Erfolg.
Ist ja oben im Tutorial ganz genau erklärt wie man es macht mit den BNGs!
Klar, dazu muss man das Tutorial natürlich zuerst mal lesen und verstehen !!! 😉
Damit funktioniert es mit allen IOS basierten Cisco Routern fehlerlos !
Genau das encapsulation... Kommando bedeutet das der Frame am WAN Port ein 802.1q tagged Frame mit der VLAN ID 7 sein soll.
Wer lesen kann....
Klar, dazu muss man das Tutorial natürlich zuerst mal lesen und verstehen !!! 😉
Interface FastEthernet0
no ip address
!
interface Ethernet0.7
description T-Com VDSL Internet Verbindung (VLAN 7 tagged)
encapsulation dot1Q 7
no ip route-cache
pppoe enable
pppoe-client dial-pool-number 1
! Genau das encapsulation... Kommando bedeutet das der Frame am WAN Port ein 802.1q tagged Frame mit der VLAN ID 7 sein soll.
Wer lesen kann....
moin moin,
erst einmal ein ganz großes DANKE für die Informationen
Nun habe ich noch ein "kleines" Problem.
1. Router Cisco 866 mit VDSL Modem --> Funktion OK
2. Router Cisco 892 mit Speedport 300HS Modem --> Funktion OK
Problem:
bei beiden Routern bekomme ich kein gescheites Bild (Artefakte/kein Ton) an einem VDSL 50 Anschluß.
In den ersten 10 Sekunden ist es perfekt, dann bei der Umschaltung auf VLAN 8 treten die Artefakte ganz extrem auf.
Was kann ich da noch tun? Meine Fritzbox schafft es problemlos .... und der Cisco sollte es dann auch schaffen
Hier noch Teile meiner Config:
jemand noch einen Tip?
Gruß und Dank
Ralf
erst einmal ein ganz großes DANKE für die Informationen
Nun habe ich noch ein "kleines" Problem.
1. Router Cisco 866 mit VDSL Modem --> Funktion OK
2. Router Cisco 892 mit Speedport 300HS Modem --> Funktion OK
Problem:
bei beiden Routern bekomme ich kein gescheites Bild (Artefakte/kein Ton) an einem VDSL 50 Anschluß.
In den ersten 10 Sekunden ist es perfekt, dann bei der Umschaltung auf VLAN 8 treten die Artefakte ganz extrem auf.
Was kann ich da noch tun? Meine Fritzbox schafft es problemlos .... und der Cisco sollte es dann auch schaffen
Hier noch Teile meiner Config:
interface GigabitEthernet0
no ip address
no ip route-cache cef
no ip route-cache
duplex auto
speed auto
no cdp enable
hold-queue 256 in
!
interface GigabitEthernet0.7
description VDSL Internet Verbindung - VLAN 7 tagged
encapsulation dot1Q 7
no ip route-cache
pppoe-client dial-pool-number 1
no cdp enable
!
interface GigabitEthernet0.8
description VDSL Multicast Entertain - VLAN 8 tagged
encapsulation dot1Q 8
ip dhcp client broadcast-flag clear
ip address dhcp
ip pim sparse-mode
no ip route-cache
ip igmp helper-address 10.50.255.254
ip igmp version 3
ip igmp explicit-tracking
ip igmp proxy-service
no cdp enable
!
interface Vlan1
description Lokales LAN
ip address 192.168.99.250 255.255.255.0
no ip redirects
no ip unreachables
no ip proxy-arp
ip pim sparse-mode
ip nat inside
ip virtual-reassembly in
ip tcp adjust-mss 1452
ip igmp helper-address 10.50.255.254
ip igmp version 3
ip igmp explicit-tracking
ip igmp query-interval 15
ip igmp proxy-service
!
interface Dialer0
description DSL Einwahl Interface
ip ddns update hostname fritz.heibox.com
ip ddns update dyndns
ip address negotiated
ip access-group PUBLIC-VDSL in
no ip redirects
no ip unreachables
no ip proxy-arp
ip mtu 1492
ip pim sparse-mode
ip nat outside
ip inspect myfw out
ip virtual-reassembly in
encapsulation ppp
ip igmp version 3
ip igmp query-interval 15
ip igmp proxy-service
dialer pool 1
dialer-group 1
no keepalive
ppp authentication pap callin
ppp chap hostname xxx#0001@t-online.de
ppp chap password 7 xxx
ppp pap sent-username xxx#0001@t-online.de password 7 xxx
ppp ipcp dns request
ppp ipcp mask request
ppp ipcp route default
no cdp enable
!
no ip forward-protocol nd
!!!! some parts deleted
ip access-list extended PUBLIC-VDSL
permit tcp any any established
permit igmp host 10.50.255.254 any
permit icmp host 10.50.255.254 any
permit ip any 224.0.0.0 15.255.255.255
permit udp any gt 40000 any
permit icmp any any administratively-prohibited
permit icmp any any echo-reply
permit icmp any any packet-too-big
permit icmp any any time-exceeded
permit icmp any any unreachable
permit udp any eq domain any
permit tcp any eq domain any
permit udp any eq ntp any
permit gre any any
!
ip pim rp-address 10.50.255.254jemand noch einen Tip?
Gruß und Dank
Ralf
Zeigt ja eigentlich das es Durchsatz oder Performance Probeme gibt
Hast du mal ein show proc cpu oder nur show cpu gemacht um zu sehen wie die Last auf dem Router ist ?
Hast du testweise mal das oben empfohlene ppp packet throttle 50 5 30 auf dem PPP Interface probiert.
Hast du mal ein show proc cpu oder nur show cpu gemacht um zu sehen wie die Last auf dem Router ist ?
Hast du testweise mal das oben empfohlene ppp packet throttle 50 5 30 auf dem PPP Interface probiert.
Hallo aqui,
CPU ist maximal bei ca. 15%
den ppp Test werde ich erst morgen machen können.
Habe noch ein paar Configs im Bridgemode gefunden. Werde die dann auch noch entsprechend testen.
Infos gibt es aber erst nächste Woche.
Dank
Ralf
CPU ist maximal bei ca. 15%
den ppp Test werde ich erst morgen machen können.
Habe noch ein paar Configs im Bridgemode gefunden. Werde die dann auch noch entsprechend testen.
Infos gibt es aber erst nächste Woche.
Dank
Ralf
Die CPU Last ist normal..daran liegt es nicht.
Bridge Mode sagt mir jetzt nix aber dann warten wir mal die kommende Woche ab...
Bridge Mode sagt mir jetzt nix aber dann warten wir mal die kommende Woche ab...
kleine Zwischeninfo:
ppp hat nichts gebracht
noch einmal alle Routing Optionen durchgetestet - dann kam Klitschko und ich musste wieder auf die FB umschalten ...
mein nächster Versuch wird sein, meine Entertainbox in Vlan 7 zu hängen um dann entsprechend "nur" noch zu bridgen.
Schon wir mal was draus wird
ppp hat nichts gebracht
noch einmal alle Routing Optionen durchgetestet - dann kam Klitschko
und ich musste wieder auf die FB umschalten ...mein nächster Versuch wird sein, meine Entertainbox in Vlan 7 zu hängen um dann entsprechend "nur" noch zu bridgen.
Schon wir mal was draus wird
dann kam Klitschko und ich musste wieder auf die FB umschalten ...
Hätt'st du besser bleiben gelassen um dir das Elend nicht mit ansehen zu müssen
Hallo Aqui,
ich ignoriere lieber deine Vorwürfe, dass ich den Thread nicht gelesen habe.
Die von Dir genannte Konfiguration zählt nur für DSL Anschlüsse die im PTM Modus laufen. (VDSL)
Mein Anschluss läuft allerdings im ATM Modus. (ADSL2+)
Betreibe den Anschluss nun im Bridge Modus.
interface ATM0/0/0.1
pvc 1/32
bridge-dot1q encap 7
Ob das wirklich korrekt ist, kann ich aktuell noch nicht sagen.
ich ignoriere lieber deine Vorwürfe, dass ich den Thread nicht gelesen habe.
Die von Dir genannte Konfiguration zählt nur für DSL Anschlüsse die im PTM Modus laufen. (VDSL)
Mein Anschluss läuft allerdings im ATM Modus. (ADSL2+)
Betreibe den Anschluss nun im Bridge Modus.
interface ATM0/0/0.1
pvc 1/32
bridge-dot1q encap 7
Ob das wirklich korrekt ist, kann ich aktuell noch nicht sagen.
Hallo Noiseless,
deine Einstellung ist richtig!!! Im Rahmen der Technischen Richtlinie 112 (1TR112) wird in Zukunft jegliche Einwahl ohne Vlan Tag auch bei ADSL zurückgewiesen.
Wer das noch nicht umgesetzt hat sollte es bei seinem Annex J Anschluss baldmöglichst umsetzten. Wir wurden schon angeschrieben das die Telekom jederzeit die Umstellung vollziehen kann.
Hinweis des Providers MK-Netzdienste (Erstklassiger Service BTW):
Laut Telekom gibt es vermehrt Hinweise darauf, dass sich einzelne von Kunden eingesetzte Endgeräte nicht gemäß der technischen Richtlinie verhalten. Endgeräte, die nicht der 1TR112 entsprechen, bewirken, dass die von der Telekom bereitgestellten Access-Teilleistungen eventuell nicht wie vertraglich vorgesehen nutzbar sind.
An dieser Stelle möchten wir insbesondere erwähnen, dass für alle Endgeräte gemäß 1TR112, Ziffer 9.3.1 eine Einwahl über VLAN7, single tagged, erfolgen muss, da die Endgeräte beim Online-User ansonsten gegebenenfalls keine PPPoE-Session aufbauen.
Wir weisen hier daraufhin, dass es sich hier nur um die Einwahl von ADSL SA Annex J und VDSL SA handelt !!!
Bislang konnten die ADSL SA Annex-J Leitungen auch ohne VLAN 7 genutzt werden, diese Möglichkeit wird im Rahmen der BNG-Migration bei der Telekom wegfallen. Es sollten daher schon jetzt alle ADSL SA Annex-J auf VLAN7 konfiguriert werden!
deine Einstellung ist richtig!!! Im Rahmen der Technischen Richtlinie 112 (1TR112) wird in Zukunft jegliche Einwahl ohne Vlan Tag auch bei ADSL zurückgewiesen.
Wer das noch nicht umgesetzt hat sollte es bei seinem Annex J Anschluss baldmöglichst umsetzten. Wir wurden schon angeschrieben das die Telekom jederzeit die Umstellung vollziehen kann.
Hinweis des Providers MK-Netzdienste (Erstklassiger Service BTW):
Laut Telekom gibt es vermehrt Hinweise darauf, dass sich einzelne von Kunden eingesetzte Endgeräte nicht gemäß der technischen Richtlinie verhalten. Endgeräte, die nicht der 1TR112 entsprechen, bewirken, dass die von der Telekom bereitgestellten Access-Teilleistungen eventuell nicht wie vertraglich vorgesehen nutzbar sind.
An dieser Stelle möchten wir insbesondere erwähnen, dass für alle Endgeräte gemäß 1TR112, Ziffer 9.3.1 eine Einwahl über VLAN7, single tagged, erfolgen muss, da die Endgeräte beim Online-User ansonsten gegebenenfalls keine PPPoE-Session aufbauen.
Wir weisen hier daraufhin, dass es sich hier nur um die Einwahl von ADSL SA Annex J und VDSL SA handelt !!!
Bislang konnten die ADSL SA Annex-J Leitungen auch ohne VLAN 7 genutzt werden, diese Möglichkeit wird im Rahmen der BNG-Migration bei der Telekom wegfallen. Es sollten daher schon jetzt alle ADSL SA Annex-J auf VLAN7 konfiguriert werden!
ich ignoriere lieber deine Vorwürfe, dass ich den Thread nicht gelesen habe.
Die von Dir genannte Konfiguration zählt nur für DSL Anschlüsse die im PTM Modus laufen. (VDSL)
Mein Anschluss läuft allerdings im ATM Modus. (ADSL2+)
Sorry aber nun muss man dir scheinbar zu Recht den Vorwurf machen das du das Tutorial nicht gelesen hast !Die von Dir genannte Konfiguration zählt nur für DSL Anschlüsse die im PTM Modus laufen. (VDSL)
Mein Anschluss läuft allerdings im ATM Modus. (ADSL2+)
Oben ist doch ganz klar auch eine ADSL2+ Konfig angegeben:
interface ATM0
no ip address
no atm ilmi-keepalive
!
interface ATM0.1 point-to-point
pvc 1/32
pppoe-client dial-pool-number 1
!
Diese Konfig funktioniert hier wenigstens mehrfach an einem T-Com ADSL2+ Anschluss fehlerlos. Sollte ja auch, denn der o.a. Router hat ein Hybridmodem das im Autodetection Mode arbeitet. Den ADSL2+ Negotiation Prozess kannst du auch live mitsehen wenn du den Debugger einmal aktivierst auf dem CLI.
Da ist nix mit Bridge Modus usw....
Hallo Aqui,
die von dir aufgeführte Config funktioniert aktuell perfekt für alle ANNEX B und ANNEX J Anschlüsse bis die Telekom ernst macht. Ab Tag X (Wann das ist weiß vermutlich noch nicht mal die Telekom) wird ohne Vorwarnung die Einwahl ohne VLAN Tag am Annex J ADSL zurückgewiesen... Wer dann nicht mit den Bridge Modus beim ADSL 2+ Anschluss (ADSL SA Annex-J) arbeitet oder arbeiten kann hat Pech.
Noiseless hat die Config die auch sicher nach der Umstellung geht. Wir dürfen das auf mehreren hundert Geräten nachbessern.
So sollte es aussehen wenn der Anschluss auch wirklich ein Annex J ist (Cisco 886VAJ, IOS 15.4M3, siehe Trained Mode).
Ich kann nur nochmals auf den Hinweis vom Provider verweisen:
Bislang konnten die ADSL SA Annex-J Leitungen auch ohne VLAN 7 genutzt werden, diese Möglichkeit wird im Rahmen der BNG-Migration bei der Telekom wegfallen. Es sollten daher schon jetzt alle ADSL SA Annex-J auf VLAN7 konfiguriert werden!
Falls du einen Annex J Anschluss hat probiere es einfach aus. Einwahl geht aktuell mit oder ohne Bridge Mode.
Gruß,
Vampi
die von dir aufgeführte Config funktioniert aktuell perfekt für alle ANNEX B und ANNEX J Anschlüsse bis die Telekom ernst macht. Ab Tag X (Wann das ist weiß vermutlich noch nicht mal die Telekom) wird ohne Vorwarnung die Einwahl ohne VLAN Tag am Annex J ADSL zurückgewiesen... Wer dann nicht mit den Bridge Modus beim ADSL 2+ Anschluss (ADSL SA Annex-J) arbeitet oder arbeiten kann hat Pech.
Noiseless hat die Config die auch sicher nach der Umstellung geht. Wir dürfen das auf mehreren hundert Geräten nachbessern.
So sollte es aussehen wenn der Anschluss auch wirklich ein Annex J ist (Cisco 886VAJ, IOS 15.4M3, siehe Trained Mode).
sh controller vdsl 0
Controller VDSL 0 is UP
Daemon Status: Up
XTU-R (DS) XTU-C (US)
Chip Vendor ID: 'BDCM' 'IFTN'
Chip Vendor Specific: 0x0000 0x82B9
Chip Vendor Country: 0xB500 0xB500
Modem Vendor ID: 'CSCO' ' '
Modem Vendor Specific: 0x4602 0x0000
Modem Vendor Country: 0xB500 0x0000
Serial Number Near: FCZ19349253 C886VAJ- 15.4(3)M3
Serial Number Far:
Modem Version Near: 15.4(3)M3
Modem Version Far: 0x82b9
Modem Status: TC Sync (Showtime!)
DSL Config Mode: AUTO
Trained Mode: G.992.5 (ADSL2+) Annex J
sh run int atm0.1
Building configuration...
Current configuration : 110 bytes
!
interface ATM0.1 point-to-point
pvc 1/32
bridge-dot1q encap 7
pppoe-client dial-pool-number 1
!
endIch kann nur nochmals auf den Hinweis vom Provider verweisen:
Bislang konnten die ADSL SA Annex-J Leitungen auch ohne VLAN 7 genutzt werden, diese Möglichkeit wird im Rahmen der BNG-Migration bei der Telekom wegfallen. Es sollten daher schon jetzt alle ADSL SA Annex-J auf VLAN7 konfiguriert werden!
Falls du einen Annex J Anschluss hat probiere es einfach aus. Einwahl geht aktuell mit oder ohne Bridge Mode.
Gruß,
Vampi
Das ist vermutlich genau der Punkt weil es hier auch mit der "alten" Konfig fehlerlos an einem Annex J Anschluss rennt.
Aber danke für den wichtigen Tip mit dem Tagging ! Tutorial ist angepasst diesbzgl.
Dann weiss man wenigstens wenn es eines Tages einmal nicht gehen sollte das die Telekom umgestellt hat auf VLAN 7 Tagging.
Aber danke für den wichtigen Tip mit dem Tagging ! Tutorial ist angepasst diesbzgl.
Dann weiss man wenigstens wenn es eines Tages einmal nicht gehen sollte das die Telekom umgestellt hat auf VLAN 7 Tagging.
Hallo Zusammen,
ich bin relativ neu auf dem Gebiet der Cisco Router welche über einen normalen Endkundenbereich hinausgehen und habe die letzten 2 Wochen damit verbracht mir etliche Dokumentationen und Tutrorials durchzuarbeiten.
Folgende Situation habe ich:
Ein Cisco 866VAE-W-K9 ist an einen VDSL ALL IP der Telekom angeschlossen.
Die Konfiguration habe
ich nach reichlicher Durchforstung dieses Tutorials und Docs von Cisco ohne Probleme hinbekommen, kann aber aus dem LAN nicht ins I-NET pingen.
Soll heißen:
Cisco 866VAE Router direkt am ALL IP Anschluß der Telekom, IP Addresse wurde zugewiesen, ein ping oder tracert direkt vom CLI an z.B. www.t-online.de ist ohne weiteres möglich.
Alle Clients im LAN können sich ebenfalls anpingen, aber:
ein Ping von einem Client aus dem LAN an z.B. www.t-online.de scheitert an einem "Host unreachable".
Die DNS Auflösung klappt ohne Probleme, aber selbst das anpingen der IP endet in der gleichen Sackgasse.
Ich denke es ist einfach nur ein simples Routing Problem welches ich übersehen habe, da ich mich aber an diesem Turorial orientiert habe, weiß ich aktuell nicht wirklich warum dieses Problem auftritt.
Ein tracert endet im Übrigen immer an der IP des Routers.
Es hat also nichts mit dem VDSL Anschluss zu tun, sondern eher mit der Grund Konfig des Routers.
Hat jemand einen Tip für mich?
ich bin relativ neu auf dem Gebiet der Cisco Router welche über einen normalen Endkundenbereich hinausgehen und habe die letzten 2 Wochen damit verbracht mir etliche Dokumentationen und Tutrorials durchzuarbeiten.
Folgende Situation habe ich:
Ein Cisco 866VAE-W-K9 ist an einen VDSL ALL IP der Telekom angeschlossen.
Die Konfiguration habe
ich nach reichlicher Durchforstung dieses Tutorials und Docs von Cisco ohne Probleme hinbekommen, kann aber aus dem LAN nicht ins I-NET pingen.
Soll heißen:
Cisco 866VAE Router direkt am ALL IP Anschluß der Telekom, IP Addresse wurde zugewiesen, ein ping oder tracert direkt vom CLI an z.B. www.t-online.de ist ohne weiteres möglich.
Alle Clients im LAN können sich ebenfalls anpingen, aber:
ein Ping von einem Client aus dem LAN an z.B. www.t-online.de scheitert an einem "Host unreachable".
Die DNS Auflösung klappt ohne Probleme, aber selbst das anpingen der IP endet in der gleichen Sackgasse.
Ich denke es ist einfach nur ein simples Routing Problem welches ich übersehen habe, da ich mich aber an diesem Turorial orientiert habe, weiß ich aktuell nicht wirklich warum dieses Problem auftritt.
Ein tracert endet im Übrigen immer an der IP des Routers.
Es hat also nichts mit dem VDSL Anschluss zu tun, sondern eher mit der Grund Konfig des Routers.
Hat jemand einen Tip für mich?
welche über einen normalen Endkundenbereich hinausgehen
Kommt wie immer darauf an was du für dich als "Endkunden" definierst...?!und habe die letzten 2 Wochen damit verbracht mir etliche Dokumentationen und Tutrorials durchzuarbeiten.
Mmmhhh... Eine einzige, nämlich diese hier, hätte dich sofort zum Ziel geführt in 10 Minuten ich nach reichlicher Durchforstung dieses Tutorials und Docs von Cisco ohne Probleme hinbekommen,
Klasse...Glückwunsch. Ist aber auch nicht schwer wenn man nur abtippen muss 😉kann aber aus dem LAN nicht ins I-NET pingen.
Ooops...eben hast du aber gesagt du hast alles hinbekommen ?? Was denn nun ?ein ping oder tracert direkt vom CLI an z.B. www.t-online.de ist ohne weiteres möglich.
Sehr gut ! Das zeigt aber ganz klar das alles sauber klappt mit deiner Routerkonfig und der böse Buhmann, wie zu erwarten war, NICHT der Router ist sondern dein Endgerät !!Ich denke es ist einfach nur ein simples Routing Problem
Nein, das ist es in der Regel nie !! Wie auch ?? Der Router hat eine default Route und schickt alles an den Provider ? Dein Client ebenso, der hat (sollte haben) eine default Route auf deinen Router...da ist also nicht groß mit Routing !Es hat also nichts mit dem VDSL Anschluss zu tun, sondern eher mit der Grund Konfig des Routers.
Nein ! Ganz und gar nicht, denn sonst könntest du vom CLI des Routers nicht ins Internet pingen.OK, fangen wir mal strategisch an:
- Pingen, nslookup und traceroute vom Router CLI auf www.heise.de z.B. klappen ! Das zeigt mit dem Router und seiner ist alles in Ordnung !
- Was sagt ein show hosts auf deinem CLI ?? Sieht du dort aufgelöste DNS Namen deiner angepingten Ziele ? Wenn ja würde das bedeuten das auch dein DNS Proxy auf dem Cisco sauber rennt.
- Was sagt ein ipconfig -all in der Eingabeaufforderung eines Windows Clients am Router ??
- Bekommt der Client eine korrekte IP Adressierung per DHCP vom Router ? Zeigt der die Router LAN IP als Gateway IP und auch als DNS IP ?
- Wenn ja, kannst du den Router bzw. seine LAN IP anpingen ?
- Wenn ja kannst du auch die 8.8.8.8 anpingen ?
Moin aqui,
danke für die Antwort, ich hab's inzwischen aber hinbekommen.
Ich hatte den Wald vor lauter Bäumen in dem Falle nicht gesehen und seid dem ersten Versuch an stumpf und einfach das NAT vom internen LAN ins WAN Interface versaut...
Das war auch schon alles.
Mit Endkundenbereich meine ich so Krempel wie den Speedport W7xx von der Telekom, welcher jetzt ausgemustert wurde.
Wie immer saß der Fehler in dem Falle also vor dem Bildschrim ;)
Und ich schrieb doch: ich habe mich "orientiert", da der 866er doch leicht anders Aufgebaut ist, zumindest in den vordefinierten Interfaces ect. im Werkszustand.
danke für die Antwort, ich hab's inzwischen aber hinbekommen.
Ich hatte den Wald vor lauter Bäumen in dem Falle nicht gesehen und seid dem ersten Versuch an stumpf und einfach das NAT vom internen LAN ins WAN Interface versaut...
Das war auch schon alles.
Mit Endkundenbereich meine ich so Krempel wie den Speedport W7xx von der Telekom, welcher jetzt ausgemustert wurde.
Wie immer saß der Fehler in dem Falle also vor dem Bildschrim ;)
Und ich schrieb doch: ich habe mich "orientiert", da der 866er doch leicht anders Aufgebaut ist, zumindest in den vordefinierten Interfaces ect. im Werkszustand.
so Krempel wie den Speedport W7xx von der Telekom, welcher jetzt ausgemustert wurde.
Eine gute Tat ! Gut wenn nun alles rennt wie es soll ! 👏 👍
Ciscoholic, all,
Erst mal danke für all die Infos. Echt Klasse!
Ich will jetzt auch IPv6 auf dem Gastnetz (Vlan2) haben.
Das IPv6 PD prefix ist ein /56, im Beispiel: 2003:6F:1234:5600::/56, Prefix name: TELEKOMv6_PREFIX
Im Vlan1 ist dann 2003:6F:1234:5600::/64, interface kommt aus ipv6 address TELEKOMv6_PREFIX ::1/64
Wie bekomme ich auf Vlan2 einen 2003:6F:1234:5601::/64?
Wie lege ich einen zweiten ipv6 dhcp pool für ein domain-name Gastnetz an?
Was muss in eine ipv6 access-list damit kein Forwarding zwischen Vlan1 und Vlan2 stattfindet?
Erst mal danke für all die Infos. Echt Klasse!
Ich will jetzt auch IPv6 auf dem Gastnetz (Vlan2) haben.
Das IPv6 PD prefix ist ein /56, im Beispiel: 2003:6F:1234:5600::/56, Prefix name: TELEKOMv6_PREFIX
Im Vlan1 ist dann 2003:6F:1234:5600::/64, interface kommt aus ipv6 address TELEKOMv6_PREFIX ::1/64
Wie bekomme ich auf Vlan2 einen 2003:6F:1234:5601::/64?
Wie lege ich einen zweiten ipv6 dhcp pool für ein domain-name Gastnetz an?
Was muss in eine ipv6 access-list damit kein Forwarding zwischen Vlan1 und Vlan2 stattfindet?
Guckst du hier:
http://www.cisco.com/c/en/us/support/docs/ip/ip-version-6-ipv6/113141-D ...
<Edit>
Tutorial wurde oben aktuell um eine IPv6 Konfig erweitert !
</Edit>
http://www.cisco.com/c/en/us/support/docs/ip/ip-version-6-ipv6/113141-D ...
Was muss in eine ipv6 access-list damit kein Forwarding zwischen Vlan1 und Vlan2 stattfindet?
Das regelst du mit der ZFW Firewall! (Siehe oben) Deren Regelwerk gilt sowohl für v4 als auch für v6!<Edit>
Tutorial wurde oben aktuell um eine IPv6 Konfig erweitert !
</Edit>
Erst mal danke.
Es ist aber noch nicht so richtig was ich wollte. Ich will den Prefix den ich von der Telekom bekomme (TELEKOMv6_PREFIX) mittels dhcp in Vlan1 und Vlan2 verteilen. Meine config:
Dies sind die Pools:
und die interfaces:
und
show ipv6 dhcp pool:
der dhcp pool TELEKOMv6_POOL hat den /56 Prefix, ich will aber nicht den selben /56 Prefix im dhcp pool TELEKOMv6_GAST verwenden. Ich will im TELEKOMv6_POOL ein /60 Prefix und im TELEKOMv6_GAST ein anderes /60 Prefix.
Es ist aber noch nicht so richtig was ich wollte. Ich will den Prefix den ich von der Telekom bekomme (TELEKOMv6_PREFIX) mittels dhcp in Vlan1 und Vlan2 verteilen. Meine config:
Dies sind die Pools:
ipv6 dhcp pool TELEKOMv6_POOL
prefix-delegation pool TELEKOMv6_PREFIX
import dns-server
domain-name homenetipv6 dhcp pool TELEKOMv6_GAST
import dns-server
domain-name guestnetund die interfaces:
interface Vlan1
ipv6 address TELEKOMv6_PREFIX ::1/64
ipv6 enable
ipv6 nd other-config-flag
ipv6 dhcp server TELEKOMv6_POOLinterface Vlan2
ipv6 address TELEKOMv6_PREFIX ::10:0:0:0:1/64
ipv6 enable
ipv6 nd other-config-flag
ipv6 dhcp server TELEKOMv6_GASTinterface Dialer0
ipv6 address FE80::179:1 link-local
ipv6 address autoconfig default
ipv6 enable
ipv6 dhcp client pd TELEKOMv6_PREFIXund
show ipv6 dhcp pool:
DHCPv6 pool: TELEKOMv6_POOL
Prefix pool: TELEKOMv6_PREFIX
preferred lifetime 604800, valid lifetime 2592000
Imported DNS server: 2003:180:2:5000:0:1:0:53
Imported DNS server: 2003:180:2:2000:0:1:0:53
DHCPv6 pool: TELEKOMv6_GAST
Imported DNS server: 2003:180:2:5000:0:1:0:53
Imported DNS server: 2003:180:2:2000:0:1:0:53der dhcp pool TELEKOMv6_POOL hat den /56 Prefix, ich will aber nicht den selben /56 Prefix im dhcp pool TELEKOMv6_GAST verwenden. Ich will im TELEKOMv6_POOL ein /60 Prefix und im TELEKOMv6_GAST ein anderes /60 Prefix.
Deine IPv6 DHCP Konfiuration ist unvollständig bzw. fehlt vollkommen, deshalb geht das nicht.
Dir fehlt der entsprechende v6 Pool (exclude etc.) und die Gateway, DNS Definition den der Router dem /64 Interface zuordnen kann.
Das ist identisch zu v4.
Dir fehlt der entsprechende v6 Pool (exclude etc.) und die Gateway, DNS Definition den der Router dem /64 Interface zuordnen kann.
Das ist identisch zu v4.
@aqui, danke.
Aber wie lege ich den v6 pool an? wenn ich ein IPv6 local pool anlege will, muss ich ein Prefix eingeben, den ich aber erst im Dialer interface mit ipv6 dhcp client pd TELEKOMv6_PREFIX lernen werde. Siehe
Alle Beispiele die ich gefunden habe, erzeugen ein Pool wie:
Aber wie lege ich den v6 pool an? wenn ich ein IPv6 local pool anlege will, muss ich ein Prefix eingeben, den ich aber erst im Dialer interface mit ipv6 dhcp client pd TELEKOMv6_PREFIX lernen werde. Siehe
886VA(config)#ipv6 local pool TEST ?
X:X:X:X::X/<0-128> IPv6 pool prefix x:x::y/<z>
886VA(config)#ipv6 local pool TEST TELEKOMv6_PREFIX
^
% Invalid input detected at '^' marker. 886VA(config)#ipv6 local pool TEST 2001:DB8:1200::/40 48
Hier findest du eine laufende Dual Stack Konfig die das macht:
Cisco 1921 VOIP und Telefonanlage ISP MNET
Die Mnet Konfig da kannst du identsch übernehmen !
Das o.a. Tutorial wird in Kürze auf die IPv6 Dual Stack Version upgedatet.
Cisco 1921 VOIP und Telefonanlage ISP MNET
Die Mnet Konfig da kannst du identsch übernehmen !
Das o.a. Tutorial wird in Kürze auf die IPv6 Dual Stack Version upgedatet.
si, nach langer Zeit und vielen vielen Versuchen habe ich erst einmal eine Zwischenlösung gefunden
Die Dropouts lagen an einen falschen RP Servereintrag
Jetzt macht meine Fritte zwar noch den Internetzugang aber die Multicast Geschichte habe ich erst einmal in den Griff bekommen
wichtig:
Global:
pro Interface:
Jetzt kann ich als nächstes auch das Interface wieder direkt an das VDSL Modem dängeln
Die Dropouts lagen an einen falschen RP Servereintrag
Jetzt macht meine Fritte zwar noch den Internetzugang aber die Multicast Geschichte habe ich erst einmal in den Griff bekommen
wichtig:
Global:
ip multicast-routingpro Interface:
ip pim sparse-mode
ip igmp helper-address <IP der Fritte>
ip igmp version 3
ip igmp explicit-tracking
ip igmp query-interval 15
ip igmp proxy-serviceJetzt kann ich als nächstes auch das Interface wieder direkt an das VDSL Modem dängeln
Hi Aqui,
Vielen Dank für deine geniale Tutorial.
Ich habe seit 2 Monate meine Cisco 886VAJ (mit Hilfe deine Tutorial) erfolgreich im Einsatz. Die einzigste Funktion aus dem Tutorial was nicht ginge war den DDNS über DynDNS. Sonst alles Perfekt und entlang die Konfiguration hab ich vieles neu dazugelernt.
Ich hab die letzten Zwei Woche versucht eine noch offene Problem selbst zu lösen, leider bisher ohne erfolg.
Wir haben viele Apple Geräte hier zu Hause, davon 6 iPads, 5 iPhones und 3 MacBooks.
Alle haben keine Verbindung mit den Mailserver (IMAP SSL Port 993) herstellen können, Apples Push Notification Service (APNs) und weitere iCloud features gehen auch nicht. Meine T-Online IMAP mail geht, aber Apple und Live.de nicht.
Komisch ist dass alle unser Windows 10 & 7 clients können ohne Probleme mit OneDrive verbinden...
Ich habe mich mit meine Konfig mehrmals auseinander gesetzt, probiert alle empfohlen APNs Ports zu öffnen und bleib trotzdem ratlos. Ich habe bei support.apple über eine Konflikt mit packet inspection gelesen, bin aber nicht sicher ob den CBAC hier Einfluss nimmt.
Ich wäre für deine Rat sehr dankbar. Falls meine Deutsch etwas Verbesserungsbedürftig erscheint liegt es daran dass ich eine Englander bin und parallel zu CISCO IOS versuche auch den Vaterlands Sprache besser zu Verstehen
Anbei meine Running-Config:
Noch eine Lob, Ich bin der CSO eine Industrielle Digitale Firma hier in Deutschland und versuche mit meine kleine HomeLab mich tiefe mit IT zu beschäftigen (Self Learning). Unsere Security team (die auch Beratung und Penetration testing am Markt liefern) haben versucht meine Home domain zu knacken OHNE ERFOLG. Sie haben nur eine kleine "potenzielle" Lücke gefunden mit den IPSec port aber ohne erheblichen aufwand bleibt dieses auch dicht. Klasse Konfig))
Vielen Dank für deine geniale Tutorial.
Ich habe seit 2 Monate meine Cisco 886VAJ (mit Hilfe deine Tutorial) erfolgreich im Einsatz. Die einzigste Funktion aus dem Tutorial was nicht ginge war den DDNS über DynDNS. Sonst alles Perfekt und entlang die Konfiguration hab ich vieles neu dazugelernt.
Ich hab die letzten Zwei Woche versucht eine noch offene Problem selbst zu lösen, leider bisher ohne erfolg.
Wir haben viele Apple Geräte hier zu Hause, davon 6 iPads, 5 iPhones und 3 MacBooks.
Alle haben keine Verbindung mit den Mailserver (IMAP SSL Port 993) herstellen können, Apples Push Notification Service (APNs) und weitere iCloud features gehen auch nicht. Meine T-Online IMAP mail geht, aber Apple und Live.de nicht.
Komisch ist dass alle unser Windows 10 & 7 clients können ohne Probleme mit OneDrive verbinden...
Ich habe mich mit meine Konfig mehrmals auseinander gesetzt, probiert alle empfohlen APNs Ports zu öffnen und bleib trotzdem ratlos. Ich habe bei support.apple über eine Konflikt mit packet inspection gelesen, bin aber nicht sicher ob den CBAC hier Einfluss nimmt.
Ich wäre für deine Rat sehr dankbar. Falls meine Deutsch etwas Verbesserungsbedürftig erscheint liegt es daran dass ich eine Englander bin und parallel zu CISCO IOS versuche auch den Vaterlands Sprache besser zu Verstehen
Anbei meine Running-Config:
Current configuration : 6115 bytes
!
! Last configuration change at 12:54:01 CEST Sat Sep 17 2016
version 15.3
no service pad
service tcp-keepalives-in
service tcp-keepalives-out
service timestamps debug datetime msec localtime show-timezone
service timestamps log datetime msec localtime show-timezone
service password-encryption
service sequence-numbers
!
hostname CISCORT
!
boot-start-marker
boot-end-marker
!
aqm-register-fnf
!
security authentication failure rate 3 log
security passwords min-length 6
logging buffered 4096
enable secret xxxxxxxxxx
!
aaa new-model
!
aaa authentication login clientauth local
aaa authorization network groupauth local
!
aaa session-id common
clock timezone CET 1 0
clock summer-time CEST recurring last Sun Mar 2:00 last Sun Oct 3:00
!
no ip source-route
no ip gratuitous-arps
!
no ip bootp server
ip domain name homenet.local
ip name-server 192.168.201.185
ip name-server 8.8.8.8
ip inspect name myfw tcp
ip inspect name myfw udp
ip cef
no ipv6 cef
!
multilink bundle-name authenticated
!
license udi pid C886VAJ-K9 sn FCZ202693XK
license boot module c800 level advipservices
!
username xxxx RouterAdmin xxxx password xxxxxx
username xxxx vpnuser xxxx password xxxxx
username xxxx VPNGROUP xxxx password xxxxxx
!
controller VDSL 0
!
ip tcp synwait-time 10
!
crypto isakmp policy 10
encr aes
authentication pre-share
group 2
!
crypto isakmp client configuration group xxxx GROUP xxxxe
key xxxxxxxxxxx
dns 192.168.201.185
domain homenet.local
pool vpnpool
save-password
max-users 2
banner ^C === Welcome to HomeNet VPN === ^C
crypto isakmp profile VPNclient
description VPN Client Profil
match identity group HomeNetVPN
client authentication list clientauth
isakmp authorization list groupauth
client configuration address respond
virtual-template 2
!
crypto ipsec transform-set myset esp-aes esp-sha-hmac
mode tunnel
!
crypto ipsec profile vpn-vti2
set transform-set myset
!
interface Null0
no ip unreachables
!
interface ATM0
no ip address
no ip redirects
no ip unreachables
no ip proxy-arp
ip flow ingress
no atm ilmi-keepalive
!
interface ATM0.1 point-to-point
no ip redirects
no ip unreachables
no ip proxy-arp
ip flow ingress
pvc 1/32
bridge-dot1q encap 7
pppoe-client dial-pool-number 1
!
!
interface BRI0
no ip address
no ip redirects
no ip unreachables
no ip proxy-arp
ip flow ingress
encapsulation hdlc
shutdown
isdn termination multidrop
!
interface Ethernet0
no ip address
no ip redirects
no ip unreachables
no ip proxy-arp
ip flow ingress
shutdown
!
interface FastEthernet0
no ip address
shutdown
!
interface FastEthernet1
description HomeNet Gateway
switchport access vlan 101
no ip address
!
interface FastEthernet2
no ip address
shutdown
!
interface FastEthernet3
no ip address
shutdown
no cdp enable
!
interface Virtual-Template2 type tunnel
description IPsec VPN Dialin
ip unnumbered Vlan1
no ip redirects
no ip unreachables
no ip proxy-arp
ip flow ingress
ip nat inside
ip virtual-reassembly in
tunnel mode ipsec ipv4
tunnel protection ipsec profile vpn-vti2
!
interface Vlan1
description VPN VLAN Interface
ip address 192.168.100.254 255.255.255.0
no ip redirects
no ip unreachables
no ip proxy-arp
ip flow ingress
shutdown
!
interface Vlan101
description Internal (FastEthernet1)
ip address 192.168.101.10 255.255.255.0
no ip redirects
no ip unreachables
no ip proxy-arp
ip flow ingress
ip nat inside
ip virtual-reassembly in
ip tcp adjust-mss 1452
!
interface Dialer0
description DSL Dialer
ip address negotiated
ip access-group 111 in
no ip redirects
no ip unreachables
no ip proxy-arp
ip mtu 1492
ip flow ingress
ip nat outside
ip inspect myfw out
ip virtual-reassembly in
encapsulation ppp
dialer pool 1
dialer-group 1
no keepalive
ppp authentication pap callin
ppp pap sent-username xxxxxxxxxxxxxxxxxx@t-online.de password xxxxxxxxxxxxxxxx
ppp ipcp dns request
ppp ipcp mask request
ppp ipcp route default
no cdp enable
!
ip local pool vpnpool 192.168.100.240 192.168.100.250
no ip forward-protocol nd
ip http server
ip http access-class 1
no ip http secure-server
!
!
ip dns server
ip nat inside source list 101 interface Dialer0 overload
ip route 192.168.0.0 255.255.0.0 192.168.101.254
!
dialer-list 1 protocol ip list 101
no cdp run
!
access-list 1 remark HTTP Access-class list
access-list 1 permit 192.168.100.0 0.0.0.255
access-list 1 permit 192.168.101.0 0.0.0.255
access-list 1 deny any
access-list 23 permit 192.168.0.0 0.0.255.255
access-list 101 permit ip 192.168.0.0 0.0.255.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 domain any
access-list 111 permit udp any any eq isakmp log
access-list 111 permit udp any any eq non500-isakmp log
access-list 111 permit tcp 17.0.0.0 0.255.255.255 any log
access-list 111 permit tcp any eq domain any
access-list 111 permit udp any eq ntp any
access-list 111 permit gre any any
access-list 111 deny ip any any log
!
control-plane
!
mgcp behavior rsip-range tgcp-only
mgcp behavior comedia-role none
mgcp behavior comedia-check-media-src disable
mgcp behavior comedia-sdp-force disable
!
mgcp profile default
!
!
line con 0
no modem enable
transport output telnet
line aux 0
transport output telnet
line vty 0 4
access-class 23 in
privilege level 15
transport input telnet ssh
!
scheduler allocate 20000 1000
scheduler interval 500
ntp server 130.149.17.8 source Dialer0
!
end
Noch eine Lob, Ich bin der CSO eine Industrielle Digitale Firma hier in Deutschland und versuche mit meine kleine HomeLab mich tiefe mit IT zu beschäftigen (Self Learning). Unsere Security team (die auch Beratung und Penetration testing am Markt liefern) haben versucht meine Home domain zu knacken OHNE ERFOLG. Sie haben nur eine kleine "potenzielle" Lücke gefunden mit den IPSec port aber ohne erheblichen aufwand bleibt dieses auch dicht. Klasse Konfig
))
Hi murphster ! We can continue the communication in English if you prefer...no problem
Was bei dir und deiner Firewall ACL komisch ist:
Alle haben keine Verbindung mit den Mailserver (IMAP SSL Port 993) herstellen können, Apples Push Notification Service (APNs)
Hier sind zwar nicht ganz so viele im Einsatz aber alle MacBook, Macminis, iPads und Phones können die geforderten Dienste ohne irgendwelche Probleme nutzen. Folglich hast du in deiner Konfig irgendwas anders gemacht ?!Was bei dir und deiner Firewall ACL komisch ist:
- Du erlaubst von außen Zugriff von ISAKMP aber es fehlt das ESP Protokoll ?? Wozu dann ISAKMP ?? Das wäre dann völliger Quatsch wenn du kein IPsec VPN Dialin mit den iPads und MacBooks machen willst. Dann kannst du das auch entfernen. "Sie haben nur eine kleine "potenzielle" Lücke gefunden mit den IPSec port" See !! Thats whay !
- Exakt das gleiche mit PPTP. Du erlaubst GRE von außen aber das dafür erforderliche TCP 1723 fehlt. Damit ist dann kein PPTP möglich und du hast sinnfreie Löcher in der FW. Kann also auch weg. Wenn dann so oder so only one single VPN Protocoll !!
- Sinnvolle IPsec Dialin Konfig für den Zugriff aufs Heimnetz mit Apple Geräten findest du hier: IPsec VPN Praxis mit Standort Vernetzung Cisco, Mikrotik, pfSense, FritzBox u.a Dort ist auch die korrekte ACL 111 für IPsec zu sehen.
- Gerade weil du andere Security testen lässt ist das ein fataler Fehler in der ACL 111 !! Besser also korrigieren
Try this that should fix the problem: //
ip inspect name myfw tcp
ip inspect name myfw udp
ip inspect name myfw https
ip inspect name myfw pop3s
ip inspect name myfw sip
ip inspect name myfw imaps
ip inspect name myfw rtsp //- For what is the ACL 1 ?? Looks like its not being in use anymore. Better is to always erase all those dead config parts for less confusion.
- If you need internal VoIP support its also better do open the ACL for inbound SIP calls: access-list 111 permit udp any eq 5060 any too.
- Correct also your ACL 111 for your used VPN protocoll. This should only be IPsec. PPTP is unsecure.
1
Hey Aqui,
Thanks for the lightning fast response!
I will definitely remove the GRE acl as I have no need for PPTP, overlooked removing it when I was playing around with VPN solutions... oops
I do use IPSec for our iOS devices and my MacBook VPN. In order to get the IPSec authentication running inbound I opened:
port 500 with: #access-list 111 permit udp any any eq isakmp log
and port 4500 with: #access-list 111 permit udp any any eq non500-isakmp log
It works fine but taking a look at the link to your "IPsec VPN Praxis mit Standout Kopplung" I think I may need to read up a little more on configuration options and optimise further.
Your right, the security team found port 500 open, probed it and then criticised the use of DH Group 2 which they said was outdated and the support of IKE Aggressive mode which may leave key material exposed, to be honest I was quite happy that was all they could find
I will setup the application gateway for IMAP as you have suggested and give it a whirl.
Once again, many thanks for your help, I have endeavoured to get back into IT after a 15 year break so this all started when I built a home lab with a an old HP G6 server, then added a cisco layer 3 switch and now the cisco router, it's a little challenging as a lot has changed from Novell & Win NT times but its fun.
I'll report back with my findings, all the best!
Thanks for the lightning fast response!
I will definitely remove the GRE acl as I have no need for PPTP, overlooked removing it when I was playing around with VPN solutions... oops
I do use IPSec for our iOS devices and my MacBook VPN. In order to get the IPSec authentication running inbound I opened:
port 500 with: #access-list 111 permit udp any any eq isakmp log
and port 4500 with: #access-list 111 permit udp any any eq non500-isakmp log
It works fine but taking a look at the link to your "IPsec VPN Praxis mit Standout Kopplung" I think I may need to read up a little more on configuration options and optimise further.
Your right, the security team found port 500 open, probed it and then criticised the use of DH Group 2 which they said was outdated and the support of IKE Aggressive mode which may leave key material exposed, to be honest I was quite happy that was all they could find
I will setup the application gateway for IMAP as you have suggested and give it a whirl.
Once again, many thanks for your help, I have endeavoured to get back into IT after a 15 year break so this all started when I built a home lab with a an old HP G6 server, then added a cisco layer 3 switch and now the cisco router, it's a little challenging as a lot has changed from Novell & Win NT times but its fun.
I'll report back with my findings, all the best!
P.S. ACL 1 if for access to the HTTP server, I tried out Cisco Configuration Professional and use it for monitoring now and then.
Ahhh...ok with ACL 1. Please keep in mind that all traffic with the "log" statement in the ACL gets process switched on the router, which means switch by the CPU ! This can have very bad effects on the system performance. If the whole amount of such traffic is low its not an issue but if it gets higher values you should keep an eye on it !
The command show proc cpu is your best friend here. Or you can use a little tool called STG grapher to take a longer graphical look on it:
http://leonidvm.chat.ru
Of course SNMP hast to be enabled for that on the Cisco. Make sure to tie SNMP to ACL 23 so that this data can only be retrieved from the internal LAN !
5 sec. SNMP OID value is 1.3.6.1.4.1.9.9.109.1.1.1.1.3 and data format is Gauge32.
Yeah, and the discussion with DH 2 may make sense in a philosophical way. It needs 3000 years to crack it on supercomputers or so...
UDP 500 and 4500 (NAT Traversal) needs to be open for remote VPN access. Thats more or less normal so wonder your testing guys did'nt know that ?!
I think the NAT traversal port 4500 only might work as well but that nailed you down on having it always activated on accessing VPN devices. OK more or less standard today with all the NAT Firewall on the link. I can make some further tests on that.
IPsec uses ESP (IP protocoll number 50) for the tunnel encapsulation. That must be opened as well in the CBAC accesslist for outside access. Would make me wonder if it worked at your site without it
The command show proc cpu is your best friend here. Or you can use a little tool called STG grapher to take a longer graphical look on it:
http://leonidvm.chat.ru
Of course SNMP hast to be enabled for that on the Cisco. Make sure to tie SNMP to ACL 23 so that this data can only be retrieved from the internal LAN !
5 sec. SNMP OID value is 1.3.6.1.4.1.9.9.109.1.1.1.1.3 and data format is Gauge32.
Yeah, and the discussion with DH 2 may make sense in a philosophical way. It needs 3000 years to crack it on supercomputers or so...
UDP 500 and 4500 (NAT Traversal) needs to be open for remote VPN access. Thats more or less normal so wonder your testing guys did'nt know that ?!
I think the NAT traversal port 4500 only might work as well but that nailed you down on having it always activated on accessing VPN devices. OK more or less standard today with all the NAT Firewall on the link. I can make some further tests on that.
IPsec uses ESP (IP protocoll number 50) for the tunnel encapsulation. That must be opened as well in the CBAC accesslist for outside access. Would make me wonder if it worked at your site without it
Hallo,
ich habe null Ahnung von Cisco, doch dank deiner Anleitung konnte ich meinen Cisco 891 so weit konfigurieren, dass ich Online komme, noip funktioniert und ich mich mit meinem Handy per VPN einwählen kann.
Nun versuche ich 2 Cisco Router (auf beidem läuft noip, also beide Router Dynamische IP) per VPN miteinander zu verbinden.
Bin nach dieser Anleitung vorgegangen.
1
Ich bekomme jedoch bei sh run diese Angabe:
Wieso wird mir Incomplete ausgegeben?
Grüße
Higgs
ich habe null Ahnung von Cisco, doch dank deiner Anleitung konnte ich meinen Cisco 891 so weit konfigurieren, dass ich Online komme, noip funktioniert und ich mich mit meinem Handy per VPN einwählen kann.
Nun versuche ich 2 Cisco Router (auf beidem läuft noip, also beide Router Dynamische IP) per VPN miteinander zu verbinden.
Bin nach dieser Anleitung vorgegangen.
1
Ich bekomme jedoch bei sh run diese Angabe:
crypto map mymap 10 ipsec-isakmp
! Incomplete
set peer cisco.web.com dynamic
set transform-set myset
match address 140
crypto map mymap 65535 ipsec-isakmp dynamic dynWieso wird mir Incomplete ausgegeben?
Grüße
Higgs
Aaahh, vermutlich weil ich keine acl mit 140 angelegt habe....
1
Yepp, das ist es. 😉
Sieh dir dieses Tutorial nochmal an, dort findest du eine lauffähige IPsec VPN Konfig für die Praxis !:
IPsec VPN Praxis mit Standort Vernetzung Cisco, Mikrotik, pfSense, FritzBox u.a
Sieh dir dieses Tutorial nochmal an, dort findest du eine lauffähige IPsec VPN Konfig für die Praxis !:
IPsec VPN Praxis mit Standort Vernetzung Cisco, Mikrotik, pfSense, FritzBox u.a
Hi aqui,
Danke für deine schnelle Antwort. Diese Anleitung habe ich mir ebenfalls durchgelesen, jedoch fehlt mir eine Beispielkonfig eines cisco mit dynip für die Gegenseite.
Für mein Verständnis.
Der Hauptrouter hat noip, diesen sage
pre-shared-key address 0.0.0.0 0.0.0.0 key geheim123
crypto isakmp policy 15 => Erlaubt 3DES und SHA
encr 3des
authentication pre-share
group 2
crypto isakmp profile DynDialin => Tunnel Profil für IPsec Tunnel von Geräten mit dynamischer Provider IP
description VPNs mit dyn. IP
keyring Labtest
match identity address 0.0.0.0
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 => Weist Tunneln mit dyn.IP Profil zu und erlaubt 3DES
description Tunnel dyn.IP Cisco 800
set transform-set testset2
set isakmp-profile DynDialin
match address vpndyn1
crypto map vpntest 20 ipsec-isakmp dynamic dynmap => Weist das dynamische Profil zu
crypto map vpntest => VPN Profil aktiv auf dem Internet Interface
ip access-list extended vpndyn1 => Bestimmt zu verschlüsselnden Traffic für VPN mit Cisco 800
permit ip 172.16.7.0 0.0.0.255 10.100.200.0 0.0.0.255
Folglich wartet er auf eine Anfrage von der dynip Gegenstelle.
Welche konfig muss ich jetzt meiner Gegenstelle mitgeben?
Danke für deine schnelle Antwort. Diese Anleitung habe ich mir ebenfalls durchgelesen, jedoch fehlt mir eine Beispielkonfig eines cisco mit dynip für die Gegenseite.
Für mein Verständnis.
Der Hauptrouter hat noip, diesen sage
pre-shared-key address 0.0.0.0 0.0.0.0 key geheim123
crypto isakmp policy 15 => Erlaubt 3DES und SHA
encr 3des
authentication pre-share
group 2
crypto isakmp profile DynDialin => Tunnel Profil für IPsec Tunnel von Geräten mit dynamischer Provider IP
description VPNs mit dyn. IP
keyring Labtest
match identity address 0.0.0.0
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 => Weist Tunneln mit dyn.IP Profil zu und erlaubt 3DES
description Tunnel dyn.IP Cisco 800
set transform-set testset2
set isakmp-profile DynDialin
match address vpndyn1
crypto map vpntest 20 ipsec-isakmp dynamic dynmap => Weist das dynamische Profil zu
crypto map vpntest => VPN Profil aktiv auf dem Internet Interface
ip access-list extended vpndyn1 => Bestimmt zu verschlüsselnden Traffic für VPN mit Cisco 800
permit ip 172.16.7.0 0.0.0.255 10.100.200.0 0.0.0.255
Folglich wartet er auf eine Anfrage von der dynip Gegenstelle.
Welche konfig muss ich jetzt meiner Gegenstelle mitgeben?
jedoch fehlt mir eine Beispielkonfig eines cisco mit dynip für die Gegenseite.
Dann hast du das Tutorial nicht richtig gelesen ! Sorry, aber genau das ist in der kommentierten Cisco Konfig genau zu sehen.Du musst das nur auf beiden Seiten dann machen.
Welche konfig muss ich jetzt meiner Gegenstelle mitgeben?
Exakt die gleiche wie auf der anderen Seite OK, natürlich angepasst an die entsprechende IP Adressierung...
Hey Aqui,
back again from a business trip, amongst visiting a few customers I had a trip to San Hose, Cisco HQ!!
They have a very impressive innovation centre and lots of gadgets laying around to play with Unfortunately I only got a CISCO pen as a gift and not a few CISCO boxes to take with me!
So after activating the application gateway as you suggested I managed to get the IMAP SSL mail services running but only momentarily, in other words after a first successful synchronisation the connection kept dropping.
So I dug a little deeper in all areas including DNS & the GPO on my domain server and found a "web email" DNS block configured, which I put in to stop my son from signing up to every webmail service on the planet. I guess I put this in around the same time as the first configuration of the 886 router.
At first I didn't think that this would effect the use of LOCAL mail applications like Outlook or Mail but after removing the DNS block all of our mail applications could maintain SSL connections!
Not sure how to block all the other webmail trash sites but thats another story
Thanks to your help and a little detective work everything is working as it should do!
Alles Gute!
Matt
P.S. I do not have the ESP port (50) opened in the outside access list but DNS still works with only UDP 500 & 4500.
back again from a business trip, amongst visiting a few customers I had a trip to San Hose, Cisco HQ!!
They have a very impressive innovation centre and lots of gadgets laying around to play with
Unfortunately I only got a CISCO pen as a gift and not a few CISCO boxes to take with me!So after activating the application gateway as you suggested I managed to get the IMAP SSL mail services running but only momentarily, in other words after a first successful synchronisation the connection kept dropping.
So I dug a little deeper in all areas including DNS & the GPO on my domain server and found a "web email" DNS block configured, which I put in to stop my son from signing up to every webmail service on the planet. I guess I put this in around the same time as the first configuration of the 886 router.
At first I didn't think that this would effect the use of LOCAL mail applications like Outlook or Mail but after removing the DNS block all of our mail applications could maintain SSL connections!
Not sure how to block all the other webmail trash sites but thats another story
Thanks to your help and a little detective work everything is working as it should do!
Alles Gute!
Matt
P.S. I do not have the ESP port (50) opened in the outside access list but DNS still works with only UDP 500 & 4500.
Hmmm......
sorry, ich sehe es leider nicht. oder ich habe wieder ein Verständnissproblem.
Ich sehe in den ganzen konfigs keinen verweis auf einen dynip host.
sorry, ich sehe es leider nicht.
oder ich habe wieder ein Verständnissproblem.Ich sehe in den ganzen konfigs keinen verweis auf einen dynip host.
@murphster
Sounds great ! Thanks for the feedback Matt and congrats that all is running now as it should. Sometimes its only the little screws who needed to be turned
With ESP is interesting. I am going to check that here in the lab setup to verify if it can be removed. I guess you might be right here cause with NAT Traversal on UDP 4500 its not needed anymore like in the old days without traversal.
I'll keep you posted.
P.S. San Hose is funny. In German it sounds like holy pants
So maybe thats the reason why you only got a ball pen at Tasman Drive. Next time better go to Great America park or watch a game at Levis Stadium its more fun.
@oOHiggsOo
Nein, da hast du recht, sorry das war ggf. etwas missverständlich. Mit einer DynIP Konfig musst du ja auch keine Konfig für eine unbekannte (dynamische) IP mehr machen. Du kannst ja dann immer als Referens den FQDN Hostname nehmen, denn der bleibt ja immer konstant.
Ändere also die Konfig so das statt der IP immer der Hostname dort steht. Dann kommt das auch zum Fliegen. Die Konfig im Tutorial geht davon aus das man mit rein dynmaischen IPs arbeitet ohne DynDNS. Mit DynDNS hast du ja aber feste Hostnamen die du dann dediziert verwenden kannst.
Sounds great ! Thanks for the feedback Matt and congrats that all is running now as it should. Sometimes its only the little screws who needed to be turned
With ESP is interesting. I am going to check that here in the lab setup to verify if it can be removed. I guess you might be right here cause with NAT Traversal on UDP 4500 its not needed anymore like in the old days without traversal.
I'll keep you posted.
P.S. San Hose is funny. In German it sounds like holy pants
So maybe thats the reason why you only got a ball pen at Tasman Drive. Next time better go to Great America park or watch a game at Levis Stadium its more fun.@oOHiggsOo
Nein, da hast du recht, sorry das war ggf. etwas missverständlich. Mit einer DynIP Konfig musst du ja auch keine Konfig für eine unbekannte (dynamische) IP mehr machen. Du kannst ja dann immer als Referens den FQDN Hostname nehmen, denn der bleibt ja immer konstant.
Ändere also die Konfig so das statt der IP immer der Hostname dort steht. Dann kommt das auch zum Fliegen. Die Konfig im Tutorial geht davon aus das man mit rein dynmaischen IPs arbeitet ohne DynDNS. Mit DynDNS hast du ja aber feste Hostnamen die du dann dediziert verwenden kannst.
Ahhhhh.
Danke, werde ich nächste Woche mal ausprobieren.
Danke, werde ich nächste Woche mal ausprobieren.
Hi,
ich muss dich nochmal belästigen. Ich bekomme keine Verbindung zwischen den 2 ciscos hin.
Konfig sieht wie folgt aus.
ich möchte eine dauerhafte Verbindung und ich möchte vom 10.10.1.0 auf 10.10.2.0 Netz zugreifen und umgekehrt.
Siehst du Fehler?
Grüße
Higgs
ich muss dich nochmal belästigen. Ich bekomme keine Verbindung zwischen den 2 ciscos hin.
Konfig sieht wie folgt aus.
version 15.4
service tcp-keepalives-in
service tcp-keepalives-out
service timestamps debug datetime msec localtime show-timezone
service timestamps log datetime msec localtime show-timezone
service password-encryption
service sequence-numbers
!
hostname ciscoA
!
boot-start-marker
boot-end-marker
!
aqm-register-fnf
!
security authentication failure rate 3 log
security passwords min-length 6
logging buffered 4096
enable secret 5 passwort
!
aaa new-model
!
aaa authentication login default local
aaa authentication login clientauth local
aaa authorization network groupauth local
!
aaa session-id common
clock timezone MET 1 0
clock summer-time MET recurring last Sun Mar 2:00 last Sun Oct 3:00
!
no ip source-route
no ip gratuitous-arps
!
ip dhcp binding cleanup interval 600
ip dhcp excluded-address 10.10.1.1 10.10.1.49
ip dhcp excluded-address 10.10.1.200 10.10.1.220
ip dhcp ping packets 3
ip dhcp ping timeout 100
!
ip dhcp pool HeimNetz
network 10.10.1.0 255.255.255.0
default-router 10.10.1.1
dns-server 10.10.1.1
domain-name ciscoA.intern
lease 7
!
no ip bootp server
ip domain name ciscoA.intern
ip inspect name myfw tcp
ip inspect name myfw udp
ip inspect name myfw https
ip inspect name myfw pop3s
ip inspect name myfw sip
ip inspect name myfw imaps
ip inspect name myfw rtsp
ip ddns update method noip.me
HTTP
add http://benutzer:passwort@dynupdate.no-ip.com/nic/update?hostname=<h>&myip=<a>
interval maximum 1 0 0 0
!
no ip cef
no ipv6 cef
!
multilink bundle-name authenticated
!
cts logging verbose
!
username test privilege 15 password 7 paswort123
username test2 password 7 paswort123
username test3 password 7 paswort123
!
no cdp run
!
ip tcp synwait-time 10
!
crypto isakmp policy 1
encr aes 256
authentication pre-share
group 2
!
crypto isakmp policy 10
encr aes
authentication pre-share
crypto isakmp key isakmpkey123 hostname ciscoB.noip.me
!
crypto isakmp client configuration group VPNdialin
key isakmpkey123
dns 10.10.1.1
domain ciscoA.intern
pool vpnpool
save-password
max-logins 3
crypto isakmp profile VPNclient
description VPN Client Profil
match identity group VPNdialin
client authentication list clientauth
isakmp authorization list groupauth
client configuration address respond
virtual-template 2
!
crypto ipsec transform-set myset esp-aes 256 esp-sha-hmac
mode tunnel
crypto ipsec transform-set vpn esp-aes esp-sha-hmac
mode tunnel
!
crypto ipsec profile vpn-vti2
set transform-set myset
!
crypto map vpnpeer 10 ipsec-isakmp
description VPN Verbindung zu Standort B
set peer ciscoB.noip.me
set transform-set vpn
match address 107
!
interface BRI0
no ip address
encapsulation hdlc
shutdown
isdn termination multidrop
!
interface FastEthernet0
no ip address
shutdown
duplex auto
speed auto
!
interface GigabitEthernet0
no ip address
!
interface GigabitEthernet1
no ip address
!
interface GigabitEthernet2
no ip address
!
interface GigabitEthernet3
no ip address
!
interface GigabitEthernet4
no ip address
!
interface GigabitEthernet5
no ip address
!
interface GigabitEthernet6
no ip address
!
interface GigabitEthernet7
no ip address
!
interface GigabitEthernet8
no ip address
no ip route-cache
duplex auto
speed auto
!
interface GigabitEthernet8.7
description VDSL Internet Verbindung - VLAN 7 tagged
encapsulation dot1Q 7
no ip route-cache
pppoe enable group global
pppoe-client dial-pool-number 1
!
interface Virtual-Template2 type tunnel
description IPsec VPN Dialin
ip unnumbered Vlan1
no ip redirects
no ip unreachables
no ip proxy-arp
ip flow ingress
ip nat inside
ip virtual-reassembly in
tunnel mode ipsec ipv4
tunnel protection ipsec profile vpn-vti2
!
interface Vlan1
description Lokales LAN
ip address 10.10.1.1 255.255.255.0
ip nat inside
ip virtual-reassembly in
ip tcp adjust-mss 1452
!
interface Async3
no ip address
encapsulation slip
!
interface Dialer0
description DSL Einwahl Interface
ip ddns update hostname ciscoA.noip.me
ip ddns update noip.me
ip address negotiated
ip access-group 111 in
no ip redirects
no ip unreachables
no ip proxy-arp
ip mtu 1492
ip nat outside
ip inspect myfw out
ip virtual-reassembly in
encapsulation ppp
dialer pool 1
dialer-group 1
no keepalive
ppp authentication pap callin
ppp pap sent-username kennung@t-online.de password 7 12345567890
ppp ipcp dns request
ppp ipcp mask request
ppp ipcp route default
no cdp enable
crypto map vpnpeer
!
ip local pool vpnpool 10.10.1.201 10.10.1.220
no ip forward-protocol nd
no ip http server
no ip http secure-server
!
ip dns server
ip nat inside source list 101 interface Dialer0 overload
ip nat inside source route-map nonat interface Dialer0 overload
!
dialer-list 1 protocol ip list 101
!
route-map nonat permit 10
match ip address 111
!
access-list 23 permit 10.10.1.0 0.0.0.255
access-list 101 permit ip 10.10.1.0 0.0.0.255 any
access-list 107 permit ip 10.10.1.0 0.0.0.255 10.10.2.0 0.0.0.255
access-list 111 deny ip 10.10.1.0 0.0.0.255 10.10.2.0 0.0.0.255
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 any eq isakmp
access-list 111 permit esp any any
access-list 111 permit ip 10.10.1.0 0.0.0.255 any
access-list 111 permit udp any any eq non500-isakmp
access-list 111 permit udp any eq domain any
access-list 111 permit tcp any eq domain any
access-list 111 permit tcp any eq www any
access-list 111 permit udp any eq 5060 any
access-list 111 permit udp any eq ntp any
access-list 111 deny ip any any
!
control-plane
!
mgcp behavior rsip-range tgcp-only
mgcp behavior comedia-role none
mgcp behavior comedia-check-media-src disable
mgcp behavior comedia-sdp-force disable
!
mgcp profile default
!
line con 0
no modem enable
line aux 0
line 3
modem InOut
speed 115200
flowcontrol hardware
line vty 0 4
access-class 23 in
privilege level 15
password 7 passwort123
transport input telnet ssh
!
scheduler allocate 20000 1000
ntp master
ntp server 130.149.17.8 source Dialer0
!
endSiehst du Fehler?
Grüße
Higgs
Was sagt denn ein
debug crypto ipsec
debug crypto isakmp
Wenn du mal ein Ping auf die remote IP machst um den IPsec VPN Tunnelaufbau zu triggern ???
Nach dem Debuggen immer ein //u all/ eingeben !!
Im Debug kannst du doch direkt ablesen woran es hapert !
debug crypto ipsec
debug crypto isakmp
Wenn du mal ein Ping auf die remote IP machst um den IPsec VPN Tunnelaufbau zu triggern ???
Nach dem Debuggen immer ein //u all/ eingeben !!
Im Debug kannst du doch direkt ablesen woran es hapert !
debug zeigt mir nichts an
und der Ping ist zu 0% erfoglreich.
und der Ping ist zu 0% erfoglreich.
Hallo,
der debug zeigt nichts an?
je nachdem mit welchen Console Tool du arbeitest, leg bitte mal ein Session Logging an und zeichne alles auf....
Und dann mach nach dem debug Befehlen mal ein "Term mon"
nach 10 Minuten soltest du eine vollen Logfile haben...
Dann wieder mit "term no mon" die Bildschirm ausgabe beenden....
und zum Schluss das debug beenden (mit "u all")
brammer
der debug zeigt nichts an?
je nachdem mit welchen Console Tool du arbeitest, leg bitte mal ein Session Logging an und zeichne alles auf....
Und dann mach nach dem debug Befehlen mal ein "Term mon"
nach 10 Minuten soltest du eine vollen Logfile haben...
Dann wieder mit "term no mon" die Bildschirm ausgabe beenden....
und zum Schluss das debug beenden (mit "u all")
brammer
debug zeigt mir nichts an
Das ist technisch vollkommen unmöglich !! Es sei denn du machst gar kein IPsec !!Bist du via Telnet oder SSH auf dem Router ? Dann musst du logischerweise ein term mon eingeben damit dir die Debug Messages angezeigt werden !!!
Direkt auf der Konsole ist das natürlich nicht erforderlich !
Ansonsten gilt das was Kollege brammer oben schon gesagt hat !
Ich bin per SSH drauf. Habe auch term mon eingegeben. Ich bekomme keine Anzeige, sobald ich es per client versuche, sehe ich wie die Verbindung aufgebaut wird. Ich sehe nur bei der site to site Verbindung kein debug. Ich vermute das ich einen Fehler in der konfig habe.
Hallo,
was wird dir den bei einem "sh debug" angezeigt?
das sollte so aussehen:
brammer
was wird dir den bei einem "sh debug" angezeigt?
das sollte so aussehen:
dein_router#sh deb
Cryptographic Subsystem:
Crypto ISAKMP debugging is on
Crypto IPSEC debugging is on
dein_router#brammer
genau das wird mir angezeigt.
Aber ich sehe nichts. Sobald ich mich mit meinem Handy eine VPN-Verbindung aufbaue sehe ich
wie die Verbindung aufgebaut wird. Aber sonst nichts.
Aber ich sehe nichts. Sobald ich mich mit meinem Handy eine VPN-Verbindung aufbaue sehe ich
wie die Verbindung aufgebaut wird. Aber sonst nichts.
Hallo,
wenn dir der logfile den Aufbau der VPN Verbindung nicht anzeigt, baust du die Verbindung irgendwo hin auf (oder versuchst das zumindest) aber nicht zu deinem Router.
Mit den beiden Debug Befehlen sollte der Logfile voll von Meldung sein....
Das sollte so ähnlich aussehen:
Und das sind 168 msec Logfile!
brammer
wenn dir der logfile den Aufbau der VPN Verbindung nicht anzeigt, baust du die Verbindung irgendwo hin auf (oder versuchst das zumindest) aber nicht zu deinem Router.
Mit den beiden Debug Befehlen sollte der Logfile voll von Meldung sein....
Das sollte so ähnlich aussehen:
130541512: Sep 30 11:15:38.372: ISAKMP:(16478): processing NONCE payload. message ID = 1954107565
130541513: Sep 30 11:15:38.372: ISAKMP:(16478): processing KE payload. message ID = 1954107565
130541514: Sep 30 11:15:38.380: ISAKMP:(16478): processing ID payload. message ID = 1954107565
130541515: Sep 30 11:15:38.380: ISAKMP:(16478): processing ID payload. message ID = 1954107565
130541516: Sep 30 11:15:38.380: ISAKMP:(16478): Creating IPSec SAs
130541517: Sep 30 11:15:38.380: inbound SA from x.x.x.x to y.y.y.y (f/i) 0/ 0
(proxy 0.0.0.0 to 0.0.0.0)
130541518: Sep 30 11:15:38.380: has spi 0xD2C7A6A0 and conn_id 0
130541519: Sep 30 11:15:38.380: lifetime of 3600 seconds
130541520: Sep 30 11:15:38.380: lifetime of 4608000 kilobytes
130541521: Sep 30 11:15:38.380: outbound SA from y.y.y.y to x.x.x.x (f/i) 0/0
(proxy 0.0.0.0 to 0.0.0.0)
130541522: Sep 30 11:15:38.380: has spi 0x1500AB27 and conn_id 0
130541523: Sep 30 11:15:38.380: lifetime of 3600 seconds
130541524: Sep 30 11:15:38.380: lifetime of 4608000 kilobytes
130541525: Sep 30 11:15:38.380: ISAKMP:(16478): sending packet to x.x.x.x my_port 500 peer_port 13798 (R) QM_IDLE
130541526: Sep 30 11:15:38.380: ISAKMP:(16478):Sending an IKE IPv4 Packet.
130541527: Sep 30 11:15:38.380: ISAKMP:(16478):deleting node 1954107565 error FALSE reason "No Error"
130541528: Sep 30 11:15:38.380: ISAKMP:(16478):Node 1954107565, Input = IKE_MESG_FROM_PEER, IKE_QM_EXCH
130541529: Sep 30 11:15:38.380: ISAKMP:(16478):Old State = IKE_QM_I_QM1 New State = IKE_QM_PHASE2_COMPLETE
130541530: Sep 30 11:15:38.380: IPSEC(key_engine): got a queue event with 1 KMI message(s)
130541531: Sep 30 11:15:38.380: Crypto mapdb : proxy_match
src addr : 0.0.0.0
dst addr : 0.0.0.0
protocol : 0
src port : 0
dst port : 0
130541532: Sep 30 11:15:38.380: IPSEC(crypto_ipsec_sa_find_ident_head): reconnecting with the same proxies and peer x.x.x.x
130541533: Sep 30 11:15:38.380: IPSEC(rte_mgr): VPN Route Event create SA based on crypto ACL in real time for x.x.x.x
130541534: Sep 30 11:15:38.380: IPSEC(create_sa): sa created,
(sa) sa_dest= y.y.y.y, sa_proto= 50,
sa_spi= 0xD2C7A6A0(3536299680),
sa_trans= esp-aes 256 esp-sha-hmac , sa_conn_id= 1569
sa_lifetime(k/sec)= (4531007/3600)
vpn-ts-ntr001#
130541535: Sep 30 11:15:38.380: IPSEC(create_sa): sa created,
(sa) sa_dest= x.x.x.x, sa_proto= 50,
sa_spi= 0x1500AB27(352365351),
sa_trans= esp-aes 256 esp-sha-hmac , sa_conn_id= 1570
sa_lifetime(k/sec)= (4531007/3600)
130541536: Sep 30 11:15:38.380: IPSEC(update_current_outbound_sa): get enable SA peer x.x.x.x current outbound sa to SPI 1500AB27
130541537: Sep 30 11:15:38.380: IPSEC(update_current_outbound_sa): updated peer x.x.x.x current outbound sa to SPI 1500AB27
130541538: Sep 30 11:15:38.400: ISAKMP:(15773):purging node -1004512891
130541539: Sep 30 11:15:38.444: ISAKMP:(13548):purging node -525138938
130541540: Sep 30 11:15:38.444: ISAKMP:(12408):purging node -205578356
130541541: Sep 30 11:15:38.540: ISAKMP (13799): received packet from x.x.x.x dport 500 sport 37019 Global (R) QM_IDLE
130541542: Sep 30 11:15:38.540: ISAKMP: set new node -389124565 to QM_IDLE
130541543: Sep 30 11:15:38.540: ISAKMP:(13799):processing transaction payload from x.x.x.x. message ID = -389124565
130541544: Sep 30 11:15:38.540: ISAKMP: Config payload SET
130541545: Sep 30 11:15:38.540: ISAKMP:(13799):checking SET:
130541546: Sep 30 11:15:38.540: ISAKMP: MODECFG_IP4_ROUTE
130541547: Sep 30 11:15:38.540: ISAKMP: MODECFG_IP4_ROUTE
130541548: Sep 30 11:15:38.540: ISAKMP: MODECFG_IP4_ROUTE
130541549: Sep 30 11:15:38.540: ISAKMP: MODECFG_IP4_ROUTE
130541550: Sep 30 11:15:38.540: ISAKMP: MODECFG_IP4_ROUTE
130541551: Sep 30 11:15:38.540: ISAKMP: MODECFG_IP4_ROUTE
130541552: Sep 30 11:15:38.540: ISAKMP: MODECFG_IP4_ROUTE
130541553: Sep 30 11:15:38.540: ISAKMP: MODECFG_IP4_ROUTE
130541554: Sep 30 11:15:38.540: ISAKMP: MODECFG_IP4_ROUTE
130541555: Sep 30 11:15:38.540: ISAKMP: MODECFG_IP4_ROUTE
130541556: Sep 30 11:15:38.540: ISAKMP:(13799):attributes sent in message:
130541557: Sep 30 11:15:38.540: Client subnet: x.x.x.x 255.255.255.255
130541558: Sep 30 11:15:38.540: Client subnet: x.x.x.x 255.255.255.192
130541559: Sep 30 11:15:38.540: Client subnet: x.x.x.x 255.255.255.192
130541560: Sep 30 11:15:38.540: Client subnet: x.x.x.x 255.255.255.255
130541561: Sep 30 11:15:38.540: Client subnet: x.x.x.x 255.255.255.255
130541562: Sep 30 11:15:38.540: Client subnet: x.x.x.x 255.255.255.255
130541563: Sep 30 11:15:38.540: Client subnet: x.x.x.x 255.255.255.255
130541564: Sep 30 11:15:38.540: Client subnet: x.x.x.x 255.255.255.255
130541565: Sep 30 11:15:38.540: Client subnet: x.x.x.x 255.255.255.255
130541566: Sep 30 11:15:38.540: Client subnet: 0.0.0.0 0.0.0.0brammer
Aber ich sehe nichts. Sobald ich mich mit meinem Handy eine VPN-Verbindung aufbaue sehe ich
wie die Verbindung aufgebaut wird. Aber sonst nichts.Sorry aber das ist wirr. Du widersprichst dich selber !! Einmal siehst du was...dann wieder nix
Was denn nun, bitte ?
So wie Kollege brammer es gepostet hat sollte es aussehen !
Du siehst den gesamten Vorgang der Phase 1 und Phase 2 Negotiation bei IPsec !
Ich wollte damit nur sagen, dass ich den Verbindungsaufbau von einem Client sehe.
Aber vom Verbindungsaufbau vom site2site ist nichts zu sehen.....
Aber vom Verbindungsaufbau vom site2site ist nichts zu sehen.....
Dann hast du noch einen grundlegenden Fehler in deiner Konfig !
Zu 98% ist das die ACL die den Site to Site Traffic klassifiziert der in den Tunnel muss. Der triggert dann den IPsec Prozess zum Tunnelaufbau.
Wenn da nichts passiert, dann stimmt da mit der ACL was nicht !
Kannst du den Tunnelaufbau von der anderen Seite triggern ?
Zu 98% ist das die ACL die den Site to Site Traffic klassifiziert der in den Tunnel muss. Der triggert dann den IPsec Prozess zum Tunnelaufbau.
Wenn da nichts passiert, dann stimmt da mit der ACL was nicht !
Kannst du den Tunnelaufbau von der anderen Seite triggern ?
ich bekomme folgende Meldung:
IPSEC:Expand action denied, discard or forwar packet
IPSEC:Expand action denied, notify RP -.-
IPSEC:Expand action denied, discard or forwar packet
IPSEC:Expand action denied, notify RP -.-
Wie vermutet ist deine Crypto ACL falsch !
https://supportforums.cisco.com/discussion/11780956/isakmp-throw-some-li ...
Das ist deine ACL 107. Vermutlich ist die syntaktisch richtig, denn sie sendet IP Pakete mit der lokalen LAN IP 10.10.1.x und der Destination IP (vermutlich lokales LAN der Gegenseite ?!) in den Tunnel ! Per se also richtig.
Aaaaber...
Mit der ACL 111 tötest du das gleich wieder im ersten Statement auf dem WAN Port:
access-list 111 deny ip 10.10.1.0 0.0.0.255 10.10.2.0 0.0.0.255
Grund ist ein Fehler im Tutorial das du vermutlich übernommen hast. Sorry. Ist jetzt korrigiert.
Eine syntaktisch korrekte Konfig findest du hier:
IPsec VPN Praxis mit Standort Vernetzung Cisco, Mikrotik, pfSense, FritzBox u.a
Diese erste Regel in der ACL 111 ist ehlerhaft ! Das ist die Firewall CBAC ACL und da hat lokaler Traffic nichts zu suchen.
Diese Kombination 107 mit 111 ist natürlich fatal und triggert den Fehler !
Fazit: Raus mit dieser ersten Regel in der ACL 111 und die ACL so ändern: !!!
ip nat inside source list 101 interface Dialer0 overload
!
access-list 101 deny ip 10.10.1.0 0.0.0.255 10.10.2.0 0.0.0.255
access-list 101 permit ip 10.10.1.0 0.0.0.255 any
access-list 107 permit ip 10.10.1.0 0.0.0.255 10.10.2.0 0.0.0.255
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 any eq isakmp
access-list 111 permit esp any any
access-list 111 permit ip 10.10.1.0 0.0.0.255 any
access-list 111 permit udp any any eq non500-isakmp
access-list 111 permit udp any eq domain any
access-list 111 permit tcp any eq domain any
access-list 111 permit tcp any eq www any
access-list 111 permit udp any eq 5060 any
access-list 111 permit udp any eq ntp any
access-list 111 deny ip any any
Die Route Map nonat mit no route-map nonat komplett löschen !
Das sollte dein Problem sofort lösen !
https://supportforums.cisco.com/discussion/11780956/isakmp-throw-some-li ...
Das ist deine ACL 107. Vermutlich ist die syntaktisch richtig, denn sie sendet IP Pakete mit der lokalen LAN IP 10.10.1.x und der Destination IP (vermutlich lokales LAN der Gegenseite ?!) in den Tunnel ! Per se also richtig.
Aaaaber...
Mit der ACL 111 tötest du das gleich wieder im ersten Statement auf dem WAN Port:
access-list 111 deny ip 10.10.1.0 0.0.0.255 10.10.2.0 0.0.0.255
Grund ist ein Fehler im Tutorial das du vermutlich übernommen hast. Sorry. Ist jetzt korrigiert.
Eine syntaktisch korrekte Konfig findest du hier:
IPsec VPN Praxis mit Standort Vernetzung Cisco, Mikrotik, pfSense, FritzBox u.a
Diese erste Regel in der ACL 111 ist ehlerhaft ! Das ist die Firewall CBAC ACL und da hat lokaler Traffic nichts zu suchen.
Diese Kombination 107 mit 111 ist natürlich fatal und triggert den Fehler !
Fazit: Raus mit dieser ersten Regel in der ACL 111 und die ACL so ändern: !!!
ip nat inside source list 101 interface Dialer0 overload
!
access-list 101 deny ip 10.10.1.0 0.0.0.255 10.10.2.0 0.0.0.255
access-list 101 permit ip 10.10.1.0 0.0.0.255 any
access-list 107 permit ip 10.10.1.0 0.0.0.255 10.10.2.0 0.0.0.255
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 any eq isakmp
access-list 111 permit esp any any
access-list 111 permit ip 10.10.1.0 0.0.0.255 any
access-list 111 permit udp any any eq non500-isakmp
access-list 111 permit udp any eq domain any
access-list 111 permit tcp any eq domain any
access-list 111 permit tcp any eq www any
access-list 111 permit udp any eq 5060 any
access-list 111 permit udp any eq ntp any
access-list 111 deny ip any any
Die Route Map nonat mit no route-map nonat komplett löschen !
Das sollte dein Problem sofort lösen !
hi aqui,
vielen Dank, dass du dir die Zeit genommen hast und dir meine Konfig durchgeschaut hast.
leider kommt keine Verbindung mit der oben geposteten Konfig zu stande. Aushandlung wurde bei "SA" unterbrochen bzw.
konnten sich nicht einigen.
ich musste die konfig leicht abändern.
so kommt nun die Verbindung zu stande und ich kann auf beiden Seiten hin und her pingen.
Was ich leider noch nicht kann, ist per Windowsexplorer auf entfernte Server/Geräte oder per Webpage auf Geräte zugreifen.
Eine Ahnung woran das noch liegen kann?
Ich vermute an eine ACL?!?!
vielen Dank, dass du dir die Zeit genommen hast und dir meine Konfig durchgeschaut hast.
leider kommt keine Verbindung mit der oben geposteten Konfig zu stande. Aushandlung wurde bei "SA" unterbrochen bzw.
konnten sich nicht einigen.
ich musste die konfig leicht abändern.
crypto isakmp policy 10
encr aes
authentication pre-share
group 2
crypto isakmp key isakmpkey123 address 0.0.0.0
crypto map vpnpeer 10 ipsec-isakmp
description VPN Verbindung zu Standort B
set peer ciscoB.noip.me dynamic
set transform-set vpn
match address 107
reverse-route <----- falls ich die Einstellung weg lasse, kommt ebenfalls keine Verbindung zu stande.so kommt nun die Verbindung zu stande und ich kann auf beiden Seiten hin und her pingen.
Was ich leider noch nicht kann, ist per Windowsexplorer auf entfernte Server/Geräte oder per Webpage auf Geräte zugreifen.
Eine Ahnung woran das noch liegen kann?
Ich vermute an eine ACL?!?!
Da hast du dann aber irgendwo noch einen Fehler in der VPN Konfig. Hier kommt ein Tunnel sofort fehlerlos zustande. Im IPsec Praxistutorial kannst du das ja auch klar an der dort geposteten aktuelle laufenden Konfig sehen wie es geht.
Auch das du eine Reverse Route angeben musst ist nicht normal !
Ausnahme ist das du eine alte und nicht mehr ganz aktuelle Firmware auf dem Cisco benutzt ?!
http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/sec_conn_vpnav/configu ...
OK, wenn aber die Verbindung jetut irgendwie zustande kommt ist ja gut und das ist die Hauptsache.
Das du nicht auf remote Geräte zugreifen kannst hat wie immer jetzt nichts mehr mit dem VPN als solchem zu tun sondern mit den loaklen Firewalls der Geräte.
Du hast ja nun einen andere Absender IP die die Firewall dann generell am LAN Port blocken. Sie lassen nur lokale IP Adressen zu.
Hier musst du die Firewall anpassen. Bei ICMP Ping ist das z.B.:
http://www.windowspro.de/tipp/ping-windows-7-server-2008-r2-zulassen
Datei Sharing Dienste die auf Broadcasts beruhen wie bei SMB/CIFS kannst du so oder so remote nicht sehen, dort musst du immer die remote IP direkt ansprechen. Klar, denn Broadcasts werden nicht über geroutete IP Verbindungen übertragen.
Webseiten oder Server Shares die man direkt mit der IP oder FQDN anspricht sind aber natürlich erreichbar.
Ein guter test ist immer ob die mit einem extended Ping vom Cisco das jeweils remote LAN Interface pingen kannst.
Das geht immer und ist dann auch ein Indiz das das VPN selber fehlerfrei ist !
Extenden Pings auf dem Cisco machst du indem du ping eingibst ohne IP und die Eingabetaste drückst.
Den Abfrage Dialog dann tickerst du durch bis du nach extended Commands gefragt wird was du mit Yes beantwortet.
Hier kannst du dann als Source IP die IP des lokalen LANs angeben und als Destination IP die des remoten lokalen LANs.
Ein Ping sollte dann fehlerfrei durchgehen, was dir dann zeigt das die Pakete der Netze 10.10.1.0 /24 und 10.10.2.0 /24 in den VPN Tunnel gehen, wie dann auch alle Endgeräte in diesen beiden Netzen.
Auch das du eine Reverse Route angeben musst ist nicht normal !
Ausnahme ist das du eine alte und nicht mehr ganz aktuelle Firmware auf dem Cisco benutzt ?!
http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/sec_conn_vpnav/configu ...
OK, wenn aber die Verbindung jetut irgendwie zustande kommt ist ja gut und das ist die Hauptsache.
Das du nicht auf remote Geräte zugreifen kannst hat wie immer jetzt nichts mehr mit dem VPN als solchem zu tun sondern mit den loaklen Firewalls der Geräte.
Du hast ja nun einen andere Absender IP die die Firewall dann generell am LAN Port blocken. Sie lassen nur lokale IP Adressen zu.
Hier musst du die Firewall anpassen. Bei ICMP Ping ist das z.B.:
http://www.windowspro.de/tipp/ping-windows-7-server-2008-r2-zulassen
Datei Sharing Dienste die auf Broadcasts beruhen wie bei SMB/CIFS kannst du so oder so remote nicht sehen, dort musst du immer die remote IP direkt ansprechen. Klar, denn Broadcasts werden nicht über geroutete IP Verbindungen übertragen.
Webseiten oder Server Shares die man direkt mit der IP oder FQDN anspricht sind aber natürlich erreichbar.
Ein guter test ist immer ob die mit einem extended Ping vom Cisco das jeweils remote LAN Interface pingen kannst.
Das geht immer und ist dann auch ein Indiz das das VPN selber fehlerfrei ist !
Extenden Pings auf dem Cisco machst du indem du ping eingibst ohne IP und die Eingabetaste drückst.
Den Abfrage Dialog dann tickerst du durch bis du nach extended Commands gefragt wird was du mit Yes beantwortet.
Hier kannst du dann als Source IP die IP des lokalen LANs angeben und als Destination IP die des remoten lokalen LANs.
Ein Ping sollte dann fehlerfrei durchgehen, was dir dann zeigt das die Pakete der Netze 10.10.1.0 /24 und 10.10.2.0 /24 in den VPN Tunnel gehen, wie dann auch alle Endgeräte in diesen beiden Netzen.
ich benutze folgende IOS c800-universalk9-mz.SPA.154-3.M6a.bin. Muss ich keine Route anlegen?
Bei show ip route, zeigt er mir das andere Netz nicht an.
Mit der eigentlichen Konfig gibt er mir bei debug folgendes aus.
ACL sieht wie folgt aus:
Ich versuche nachher das gleich von der Gegenseite und Poste diese.
Btw du hattest mit der Erreichbarkeit einiger Geräte recht. Ich habe in der Einstellung, dass sie nur aus dem eigenem Netz erreicht werden können.
Bei show ip route, zeigt er mir das andere Netz nicht an.
Mit der eigentlichen Konfig gibt er mir bei debug folgendes aus.
ciscoA#ping 192.168.100.9 source 192.168.178.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.100.9, timeout is 2 seconds:
Packet sent with a source address of 192.168.178.1
Oct 13 07:38:23.889 MET: IPSEC: Peer ciscoB.noip.me's addr (x.x.x.139) is stale, triggering DNS
Oct 13 07:38:23.925 MET: IPSEC: Peer ciscoB.me has been DNS resolved to x.x.x.139, expires in 00:00:40.
Oct 13 07:38:25.890 MET: IPSEC(sa_request): ,
(key eng. msg.) OUTBOUND local= x.x.x.73:500, remote= x.x.x.139:500,
local_proxy= 192.168.178.0/255.255.255.0/256/0,
remote_proxy= 192.168.100.0/255.255.255.0/256/0,
protocol= ESP, transform= esp-aes 256 esp-sha-hmac (Tunnel),
lifedur= 3600s and 4608000kb,
spi= 0x0(0), conn_id= 0, keysize= 256, flags= 0x0
Oct 13 07:38:25.890 MET: ISAKMP: set new node 0 to QM_IDLE
Oct 13 07:38:25.890 MET: SA has outstanding requests (local x.x.x.73 port 500, remote x.x.x.139 port 500)
Oct 13 07:38:25.890 MET: ISAKMP:(2006): sitting IDLE. Starting QM immediately (QM_IDLE )
Oct 13 07:38:25.890 MET: ISAKMP:(2006):beginning Quick Mode exchange, M-ID of 2036387119
Oct 13 07:38:25.890 MET: ISAKMP:(2006):QM Initiator gets spi
Oct 13 07:38:25.890 MET: ISAKMP:(2006): sending packet to x.x.x.139 my_port 500 peer_port 500 (R) QM_IDLE
Oct 13 07:38:25.890 MET: ISAKMP:(2006):Sending an IKE IPv4 Packet.
Oct 13 07:38:25.890 MET: ISAKMP:(2006):Node 2036387119, Input = IKE_MESG_INTERNAL, IKE_INIT_QM
Oct 13 07:38:25.890 MET: ISAKMP:(2006):Old State = IKE_QM_READY New State = IKE_QM_I_QM1
Oct 13 07:38:26.126 MET: ISAKMP (2006): received packet from x.x.x.139 dport 500 sport 500 Global (R) QM_IDLE
Oct 13 07:38:26.126 MET: ISAKMP: set new node 623765356 to QM_IDLE
Oct 13 07:38:26.126 MET: ISAKMP:(2006): processing HASH payload. message ID = 623765356
Oct 13 07:38:26.126 MET: ISAKMP:(2006): processing NOTIFY PROPOSAL_NOT_CHOSEN protocol 3
spi 290688999, message ID = 623765356, sa = 0x2373680
Oct 13 07:38:26.126 MET: ISAKMP:(2006): deleting spi 290688999 message ID = 2036387119
Oct 13 07:38:26.126 MET: ISAKMP:(2006):deleting node 2036387119 error TRUE reason "Delete Larval"
Oct 13 07:38:26.126 MET: ISAKMP:(2006):deleting node 623765356 error FALSE reason "Informational (in) state 1"
Oct 13 07:38:26.126 MET: ISAKMP:(2006):Input = IKE_MESG_FROM_PEER, IKE_INFO_NOTIFY
Oct 13 07:38:26.126 MET: ISAKMP:(2006):Old State = IKE_P1_COMPLETE New State = IKE_P1_COMPLETE
....
Success rate is 0 percent (0/5)
dies bringt er einige male und hört danach auf. Er fängt nicht mit der 2.Phase an
ciscoA#show crypto isakmp sa
IPv4 Crypto ISAKMP SA
dst src state conn-id status
x.x.x.73 x.x.x.139 QM_IDLE 2006 ACTIVE
#show crypto ipsec sa
interface: Dialer0
Crypto map tag: vpnpeer, local addr x.x.x.73
protected vrf: (none)
local ident (addr/mask/prot/port): (192.168.178.0/255.255.255.0/0/0)
remote ident (addr/mask/prot/port): (192.168.100.0/255.255.255.0/0/0)
current_peer x.x.x.x port 500
PERMIT, flags={origin_is_acl,}
#pkts encaps: 0, #pkts encrypt: 0, #pkts digest: 0
#pkts decaps: 0, #pkts decrypt: 0, #pkts verify: 0
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0
#pkts not decompressed: 0, #pkts decompress failed: 0
#send errors 28, #recv errors 0
local crypto endpt.: x.x.x.73, remote crypto endpt.: x.x.x.139
plaintext mtu 1492, path mtu 1492, ip mtu 1492, ip mtu idb Dialer0
current outbound spi: 0x0(0)
PFS (Y/N): N, DH group: none
inbound esp sas:
inbound ah sas:
inbound pcp sas:
outbound esp sas:
outbound ah sas:
outbound pcp sas:ACL sieht wie folgt aus:
ip nat inside source list 101 interface Dialer0 overload
!
!
dialer-list 1 protocol ip list 101
!
access-list 23 permit 192.168.178.0 0.0.0.255
access-list 101 deny ip 192.168.178.0 0.0.0.255 192.168.100.0 0.0.0.255
access-list 101 permit ip 192.168.178.0 0.0.0.255 any
access-list 107 permit ip 192.168.178.0 0.0.0.255 192.168.100.0 0.0.0.255
access-list 111 permit ip 192.168.178.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 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 domain any
access-list 111 permit tcp any eq domain any
access-list 111 permit tcp any eq www any
access-list 111 permit udp any eq 5060 any
access-list 111 permit udp any eq ntp any
access-list 111 deny ip any anyIch versuche nachher das gleich von der Gegenseite und Poste diese.
Btw du hattest mit der Erreichbarkeit einiger Geräte recht. Ich habe in der Einstellung, dass sie nur aus dem eigenem Netz erreicht werden können.
ciscoB debug zeigt folgendes
#ping 192.168.178.9 source 192.168.100.254
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.178.9, timeout is 2 seconds:
Packet sent with a source address of 192.168.100.254
000041: Oct 13 11:21:15.876 MET: IPSEC: Peer ciscoa.noip.me's addr (0.0.0.0) is stale, triggering DNS
000042: Oct 13 11:21:16.136 MET: IPSEC: Peer ciscoa.noip.me has been DNS resolved to x.x.x.73, e xpires in 00:00:40.
000043: Oct 13 11:21:17.876 MET: IPSEC(sa_request): ,
(key eng. msg.) OUTBOUND local= x.x.x.4:500, remote= x.x.x.73:500,
local_proxy= 192.168.100.0/255.255.255.0/256/0,
remote_proxy= 192.168.178.0/255.255.255.0/256/0,
protocol= ESP, transform= esp-aes 256 esp-sha-hmac (Tunnel),
lifedur= 3600s and 4608000kb,
spi= 0x0(0), conn_id= 0, keysize= 256, flags= 0x0
000044: Oct 13 11:21:17.876 MET: ISAKMP:(0): SA request profile is (NULL)
000045: Oct 13 11:21:17.876 MET: ISAKMP: Created a peer struct for x.x.x.73, peer port 500
000046: Oct 13 11:21:17.876 MET: ISAKMP: New peer created peer = 0x3D70C84 peer_handle = 0x80000002
000047: Oct 13 11:21:17.876 MET: ISAKMP: Locking peer struct 0x3D70C84, refcount 1 for isakmp_initiator
000048: Oct 13 11:21:17.876 MET: ISAKMP: local port 500, remote port 500
000049: Oct 13 11:21:17.876 MET: ISAKMP: set new node 0 to QM_IDLE
000050: Oct 13 11:21:17.876 MET: ISAKMP:(0):insert sa successfully sa = 1019D08
000051: Oct 13 11:21:17.876 MET: ISAKMP:(0):Can not start Aggressive mode, trying Main mode.
000052: Oct 13 11:21:17.876 MET: ISAKMP:(0):No pre-shared key with x.x.x.73!
000053: Oct 13 11:21:17.876 MET: ISAKMP:(0):Looking for a matching key for ciscoa.noip.me in default
000054: Oct 13 11:21:17.876 MET: ISAKMP:(0): constructed NAT-T vendor-rfc3947 ID
000055: Oct 13 11:21:17.876 MET: ISAKMP:(0): constructed NAT-T vendor-07 ID
000056: Oct 13 11:21:17.876 MET: ISAKMP:(0): constructed NAT-T vendor-03 ID
000057: Oct 13 11:21:17.876 MET: ISAKMP:(0): constructed NAT-T vendor-02 ID
000058: Oct 13 11:21:17.876 MET: ISAKMP:(0):Input = IKE_MESG_FROM_IPSEC, IKE_SA_REQ_MM
000059: Oct 13 11:21:17.876 MET: ISAKMP:(0):Old State = IKE_READY New State = IKE_I_MM1
000060: Oct 13 11:21:17.876 MET: ISAKMP:(0): beginning Main Mode exchange
000061: Oct 13 11:21:17.876 MET: ISAKMP:(0): sending packet to x.x.x.73 my_port 500 peer_port 500 ( I) MM_NO_STATE
000062: Oct 13 11:21:17.876 MET: ISAKMP:(0):Sending an IKE IPv4 Packet.
000063: Oct 13 11:21:17.944 MET: ISAKMP (0): received packet from x.x.x.73 dport 500 sport 500 Glob al (I) MM_NO_STATE
000064: Oct 13 11:21:17.944 MET: ISAKMP:(0):Notify has no hash. Rejected.
000065: Oct 13 11:21:17.944 MET: ISAKMP (0): Unknown Input IKE_MESG_FROM_PEER, IKE_INFO_NOTIFY: state = IKE_I_MM1
000066: Oct 13 11:21:17.944 MET: ISAKMP:(0):Input = IKE_MESG_FROM_PEER, IKE_INFO_NOTIFY
000067: Oct 13 11:21:17.944 MET: ISAKMP:(0):Old State = IKE_I_MM1 New State = IKE_I_MM1
000068: Oct 13 11:21:17.944 MET: %CRYPTO-6-IKMP_MODE_FAILURE: Processing of Informational mode failed wi th peer at x.x.x.73....
Success rate is 0 percent (0/5)
Das ist normal das du es in der Routing Tabelle nicht siehst, denn das IPsec Routing rennt in einer separaten VRF.
Wenn du show crypto ipsec sa eingibst kannst du zu jedem VPN Netz auch das Forwarding in den SAs sehen.
Du hast desweiteren immer noch einen Fehler in deiner ACL 111 !!!
access-list 111 permit ip 192.168.178.0 0.0.0.255 any hat dort nichts zu suchen !
Die ACL ist eine inbound ACL !! Wie soll dort jemeals ein IP Paket mit einer Source IP aus einem privaten RFC 1918 Netzwerk auftauchen ?!
Das ist natürlich falsch !!
Man kann nur immer wieder an dich appellieren dir die Cisco Konfigs im Praxistutorial:
IPsec VPN Praxis mit Standort Vernetzung Cisco, Mikrotik, pfSense, FritzBox u.a
mal wirklich genau anzusehen und nachzuvollziehen und zwar für beide Seiten !!
Dann passieren solche Dinge wie bei dir auch nicht !
Wenn du show crypto ipsec sa eingibst kannst du zu jedem VPN Netz auch das Forwarding in den SAs sehen.
Du hast desweiteren immer noch einen Fehler in deiner ACL 111 !!!
access-list 111 permit ip 192.168.178.0 0.0.0.255 any hat dort nichts zu suchen !
Die ACL ist eine inbound ACL !! Wie soll dort jemeals ein IP Paket mit einer Source IP aus einem privaten RFC 1918 Netzwerk auftauchen ?!
Das ist natürlich falsch !!
Man kann nur immer wieder an dich appellieren dir die Cisco Konfigs im Praxistutorial:
IPsec VPN Praxis mit Standort Vernetzung Cisco, Mikrotik, pfSense, FritzBox u.a
mal wirklich genau anzusehen und nachzuvollziehen und zwar für beide Seiten !!
Dann passieren solche Dinge wie bei dir auch nicht !
Ah ok.
Es tut mir leid, aber in deiner Antwort mit den korrigierten ACLs hattest du es genauso drin und
in der obrigen Anleitung hast du es ebenfalls noch drin.
Es tut mir leid, aber in deiner Antwort mit den korrigierten ACLs hattest du es genauso drin und
in der obrigen Anleitung hast du es ebenfalls noch drin.
Sorry, aber nein, das ist falsch. Im korrigierten Beispiel (11.10.2016, aktualisiert um 23:06 Uhr) oben ist das NICHT drin und auch nicht mehr im Tutorial:
Weder hier:
IPsec VPN Praxis mit Standort Vernetzung Cisco, Mikrotik, pfSense, FritzBox u.a
noch hier:
IPsec VPNs einrichten mit Cisco, Mikrotik, pfSense Firewall, FritzBox, Smartphone sowie Shrew Client Software
Wo bitte hast du das gesehen ???
Nur nochmal um es klarzustellen: Es geht um das Statement access-list 111 permit ip 192.168.178.0 0.0.0.255 any in der ACL 111 !
Das ist eine Inbound (eingehend) ACL am WAN / Internet Port.
Diese Regel besagt das dort Pakete die mit einer Absender IP von 192.168.178.x ankommen und eine beliebige IP Adresse als Ziel haben passieren dürfen.
Das ist aus technischer Sicht Quatsch, denn aus dem Internet können niemals IP Adressen mit einer privaten RFC 1918 IP Absender Adresse kommen. Solche IP Adressen gibt es im Internet schlicht und einfach nicht.
Folglich gehört das Statement entfernt ! Mach das bitte mal und checke die Connectivity dann nochmals.
Weder hier:
IPsec VPN Praxis mit Standort Vernetzung Cisco, Mikrotik, pfSense, FritzBox u.a
noch hier:
IPsec VPNs einrichten mit Cisco, Mikrotik, pfSense Firewall, FritzBox, Smartphone sowie Shrew Client Software
Wo bitte hast du das gesehen ???
Nur nochmal um es klarzustellen: Es geht um das Statement access-list 111 permit ip 192.168.178.0 0.0.0.255 any in der ACL 111 !
Das ist eine Inbound (eingehend) ACL am WAN / Internet Port.
Diese Regel besagt das dort Pakete die mit einer Absender IP von 192.168.178.x ankommen und eine beliebige IP Adresse als Ziel haben passieren dürfen.
Das ist aus technischer Sicht Quatsch, denn aus dem Internet können niemals IP Adressen mit einer privaten RFC 1918 IP Absender Adresse kommen. Solche IP Adressen gibt es im Internet schlicht und einfach nicht.
Folglich gehört das Statement entfernt ! Mach das bitte mal und checke die Connectivity dann nochmals.
Hallo aqui,
zuallererst möchte ich Dir für das Erstellen diese tollen Tutorials danken! Well done!!
Nun habe ich allerdings ein Problem mit der CBAC, welches ich mir nicht erklären kann. Ich nutze einen 881 mit Advanced Security Feature Set.
ip inspect name... wurde gesetzt, im Dialer "ip inspect myfw out" eingefügt, die "access-list 111" gesetzt und im Anschluss im Dialer die "ip access-group 111 in" Regel gesetzt. Um WebVPN (AnyConnect) und ggf. IPSEC zu gewähren, ist eine Object-Group
definiert (access-list 111 permit object-group vpn-in any any).
Wenn ich "ip access-group 111 in" setze, ist der Router nicht mehr per Ping erreichbar, der Anyconnect-Tunnel bricht zusammen und ein Reboot bringt mich wieder ins Netz.
Irgendeine Idee, wo ich den Wald vor lauter Bäumen nicht sehe?
Gruss aus EU,
Jörg
P.S.: ip inspect myfw out, nicht ip inspect myfw in (ip inspect MyFW in)?
zuallererst möchte ich Dir für das Erstellen diese tollen Tutorials danken! Well done!!
Nun habe ich allerdings ein Problem mit der CBAC, welches ich mir nicht erklären kann. Ich nutze einen 881 mit Advanced Security Feature Set.
ip inspect name... wurde gesetzt, im Dialer "ip inspect myfw out" eingefügt, die "access-list 111" gesetzt und im Anschluss im Dialer die "ip access-group 111 in" Regel gesetzt. Um WebVPN (AnyConnect) und ggf. IPSEC zu gewähren, ist eine Object-Group
object-group service vpn-in
description VPN inbound
esp
udp eq 443
udp eq isakmp
udp eq non500-isakmp
tcp eq www
tcp eq 443
tcp eq 10000definiert (access-list 111 permit object-group vpn-in any any).
Wenn ich "ip access-group 111 in" setze, ist der Router nicht mehr per Ping erreichbar, der Anyconnect-Tunnel bricht zusammen und ein Reboot bringt mich wieder ins Netz.
Irgendeine Idee, wo ich den Wald vor lauter Bäumen nicht sehe?
Gruss aus EU,
Jörg
P.S.: ip inspect myfw out, nicht ip inspect myfw in (ip inspect MyFW in)?
Verglichen mit der "normalen" ACL Logik müsste es aber heissen access-list 111 permit any any object-group vpn-in
Müsste man mal checken ob das einen Unterschied in der Logik macht.
Vermutlich "verbiegt" dort ggf. falsche Syntax die Logik der ACL 111.
Du kannst ja mal spaßeshalber die Einzelkomponenten direkt in die ACL 111 eingeben. Das sollte in jedem klappen.
Nur mal so als Test.
Müsste man mal checken ob das einen Unterschied in der Logik macht.
Vermutlich "verbiegt" dort ggf. falsche Syntax die Logik der ACL 111.
Du kannst ja mal spaßeshalber die Einzelkomponenten direkt in die ACL 111 eingeben. Das sollte in jedem klappen.
Nur mal so als Test.
Die Syntax ist korrekt.
Aber auch mit der Eingabe der Einzelkomponenten knallt es...
Schon nach der Eingabe von "access-list 111 permit icmp any any administratively-prohibited"...
Interessant ist auch, dass die DNS Auflösung nicht mehr funktioniert. Der Router agiert als DNS-Server fürs LAN. Ein Ping nach aussen auf eine IP funktioniert.
Da mir die Ideen ausgehen, bitte ich, einmal über die Config zu schauen. Vielleicht sieht ja jemand den Fehler, den ich offensichtlich übersehe...
DANKE im voraus...
Aber auch mit der Eingabe der Einzelkomponenten knallt es...
Schon nach der Eingabe von "access-list 111 permit icmp any any administratively-prohibited"...
Interessant ist auch, dass die DNS Auflösung nicht mehr funktioniert. Der Router agiert als DNS-Server fürs LAN. Ein Ping nach aussen auf eine IP funktioniert.
Da mir die Ideen ausgehen, bitte ich, einmal über die Config zu schauen. Vielleicht sieht ja jemand den Fehler, den ich offensichtlich übersehe...
DANKE im voraus...
version 15.4
no service pad
service tcp-keepalives-in
service tcp-keepalives-out
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname Cisco_881
!
boot-start-marker
boot system flash c880data-universalk9-mz.154-3.M4.bin
boot-end-marker
!
!
security authentication failure rate 3 log
security passwords min-length 6
enable secret 4 XXX
!
aaa new-model
!
!
aaa authentication login default local
aaa authentication login clientauth local
aaa authentication login sslvpn local
aaa authorization network groupauth local
!
!
aaa session-id unique
memory-size iomem 10
clock timezone CET 1 0
clock summer-time CEST recurring last Sun Mar 2:00 last Sun Oct 3:00
!
crypto pki trustpoint Trustpoint_SSLVPN
enrollment selfsigned
serial-number
subject-name CN=vpn.XXX.de
revocation-check crl
rsakeypair RSA_NXXX
!
!
crypto pki certificate chain Trustpoint_SSLVPN
certificate self-signed 03
YYYYYY YYYYYY YYYYYY
quit
!
!
no ip source-route
no ip gratuitous-arps
!
!
ip domain name nieder.XXX
ip name-server 194.25.0.60
ip name-server 194.25.0.52
ip name-server 8.8.8.8
ip inspect name myfw tcp
ip inspect name myfw udp
ip inspect name myfw sip
ip inspect name myfw rtsp
!
ip cef
no ipv6 cef
!
!
cts logging verbose
license udi pid CISCO881-SEC-K9 sn FCZ112345678
license boot module c880-data level advsecurity
!
!
object-group network cameras
description Netzwerk-Kameras
host 192.168.178.220
host 192.168.178.221
host 192.168.178.222
host 192.168.178.223
!
object-group service services-in
description Netzwerkdienste
tcp eq domain
udp eq domain
udp eq ntp
!
object-group service voip-in
description voip inbound
udp eq 5060
udp eq 5070
udp eq 5080
udp range 30000 31000
udp range 40000 41000
!
object-group network voip-servers
description VoIP-Server Telekom und sipgate
217.0.0.0 255.248.0.0
217.10.64.0 255.255.240.0
217.116.112.0 255.255.240.0
212.9.32.0 255.255.224.0
!
object-group service vpn-in
description VPN inbound
esp
udp eq 443
udp eq isakmp
udp eq non500-isakmp
udq eq 3000
tcp eq www
tcp eq 443
tcp eq 10000
udp eq 3000
!
username admin privilege 15 secret 4 XYZABC
!
crypto vpn anyconnect flash:/webvpn/anyconnect-win-4.4.00243-webdeploy-k9.pkg sequence 1
!
crypto vpn anyconnect flash:/webvpn/anyconnect-macos-4.4.00243-webdeploy-k9.pkg sequence 2
!
crypto vpn anyconnect profile VPN_PROFILE flash:/RDProfile.xsd
!
!
interface FastEthernet0
no ip address
!
interface FastEthernet1
no ip address
!
interface FastEthernet2
no ip address
!
interface FastEthernet3
switchport mode trunk
no ip address
!
interface FastEthernet4
description $ETH-WAN$
no ip address
no ip proxy-arp
ip flow ingress
duplex auto
speed auto
pppoe enable group global
pppoe-client dial-pool-number 1
!
interface Virtual-Template1
ip unnumbered Dialer1
!
interface Vlan1
description LAN
ip address 192.168.178.254 255.255.255.0
ip access-group 102 in
ip access-group 102 out
no ip proxy-arp
ip nat inside
ip virtual-reassembly in
ip tcp adjust-mss 1452
!
interface Vlan10
description Voice-VLAN
ip address 192.168.10.254 255.255.255.0
ip access-group 103 in
ip access-group 103 out
no ip proxy-arp
ip nat inside
ip virtual-reassembly in
ip tcp adjust-mss 1452
!
interface Vlan100
description Guest-VLAN
ip address 172.20.2.254 255.255.255.0
ip access-group 104 in
ip access-group 104 out
no ip proxy-arp
ip nat inside
ip virtual-reassembly in
ip tcp adjust-mss 1452
!
interface Dialer1
description VDSL Einwahl-Interface
ip ddns update hostname vpn.XXX.de
ip ddns update Strato
ip address negotiated
ip access-group 111 in
no ip redirects
no ip unreachables
no ip proxy-arp
ip mtu 1452
ip flow ingress
ip nat outside
ip inspect myfw out
ip virtual-reassembly in
encapsulation ppp
ip tcp adjust-mss 1452
load-interval 30
dialer pool 1
dialer idle-timeout 0
dialer-group 1
ppp authentication chap callin
ppp chap hostname 1234567890@t-online.de
ppp chap password 0 12345678
ppp ipcp dns request
ppp ipcp mask request
ppp ipcp route default
no cdp enable
!
ip local pool vpnpool 10.10.10.1 10.10.10.10
ip forward-protocol nd
no ip http server
ip http authentication local
ip http secure-server
!
no ip ftp passive
ip dns server
ip nat inside source list 101 interface Dialer1 overload
ip ssh version 2
ip scp server enable
!
kron occurrence DSL-Reconnect at 4:00 recurring
policy-list DSL-Reconnect
!
kron policy-list DSL-Reconnect
cli clear interface Dialer1
!
dialer-list 1 protocol ip permit
!
access-list 101 permit ip 192.168.178.0 0.0.0.255 any
access-list 101 permit ip 172.20.2.0 0.0.0.255 any
access-list 101 permit ip 192.168.10.0 0.0.0.255 any
access-list 102 deny ip 172.20.2.0 0.0.0.255 192.168.178.0 0.0.0.255
access-list 102 deny ip 192.168.178.0 0.0.0.255 172.20.2.0 0.0.0.255
access-list 102 permit ip any any
access-list 103 deny ip 172.20.2.0 0.0.0.255 192.168.10.0 0.0.0.255
access-list 103 deny ip 192.168.10.0 0.0.0.255 172.20.2.0 0.0.0.255
access-list 103 permit ip any any
access-list 104 deny ip 172.20.2.0 0.0.0.255 192.168.178.0 0.0.0.255
access-list 104 deny ip 192.168.178.0 0.0.0.255 172.20.2.0 0.0.0.255
access-list 104 deny ip 172.20.2.0 0.0.0.255 192.168.10.0 0.0.0.255
access-list 104 deny ip 192.168.10.0 0.0.0.255 172.20.2.0 0.0.0.255
access-list 104 permit ip any any
!
!
line con 0
no modem enable
line aux 0
line vty 0 4
length 0
transport input ssh
!
scheduler allocate 20000 1000
ntp master
ntp server de.pool.ntp.org minpoll 8
!
!
webvpn gateway SSLVPN_Gateway
ip interface Dialer1 port 443
ssl encryption aes256-sha1
ssl trustpoint Trustpoint_SSLVPN
inservice
dtls port 3000
!
webvpn context SSLVPN
title "VPN"
color grey
secondary-color black
title-color #669999
login-message "Please log in."
aaa authentication list sslvpn
gateway SSLVPN_Gateway
logging enable
!
ssl authenticate verify all
inservice
!
policy group SSLVPN
functions svc-enabled
functions svc-required
timeout idle 86400
timeout session 1209600
svc address-pool "vpnpool" netmask 255.255.255.255
svc keep-client-installed
svc rekey method new-tunnel
svc split include 192.168.178.0 255.255.255.0
mask-urls
default-group-policy SSLVPN
!
endAber auch mit der Eingabe der Einzelkomponenten knallt es...
Oha...dann hast du aber einen generellen Konfig Kinken in deinem Setup. Hab es eben hier mal an einem Laborrouter getestet und da rennt es einwandfrei wie es soll !
Guten Morgen,
danke für die Antwort.
Eben, ich befürchte auch, dass da was im Argen ist, aber ich finde den verd*** Fehler nicht...!
Daher habe ich meine Konfig (ohne dhcp pools etc.) geposted... Vielleicht fällt einem Anderen ja der Fehler auf, den ich als mittlerweile betriebsblinder User, nicht sehe.
Gruss,
Jörg
danke für die Antwort.
Eben, ich befürchte auch, dass da was im Argen ist, aber ich finde den verd*** Fehler nicht...!
Daher habe ich meine Konfig (ohne dhcp pools etc.) geposted... Vielleicht fällt einem Anderen ja der Fehler auf, den ich als mittlerweile betriebsblinder User, nicht sehe.
Gruss,
Jörg
Da warst du aber ziemlich betriebsblind !!!
Du hast auf dem Dialer Interface immer noch die CBAC ACL 111 definiert aaaaber....
Keinerlei ACL 111 konfiguriert unten.
Damit gilt dann als Default ACL Entry DENY any any !
Sprich also es wird ausnahmslos ALLES geblockt was inbound am Dialer 0 von außen reinkommt.
Damit geht dann natürlich nix mehr inbound...logisch.
Works as designed
Du hast auf dem Dialer Interface immer noch die CBAC ACL 111 definiert aaaaber....
Keinerlei ACL 111 konfiguriert unten.
Damit gilt dann als Default ACL Entry DENY any any !
Sprich also es wird ausnahmslos ALLES geblockt was inbound am Dialer 0 von außen reinkommt.
Damit geht dann natürlich nix mehr inbound...logisch.
Works as designed
Au contraire...!
Ja, auf dem Interface ist die CBAC ACL 111 definiert.
Ja, es ist KEINE ACL 111 konfiguriert.
Nein, mit exakt dieser Konfiguration geht jeder Traffic durch (es existiert ja keine Deny any any).
Sobald ich die erste ACL (z.Bsp. access-list 111 permit icmp any any administratively-prohibited) eingebe, bricht jeglicher Traffic ab (kein Ping von aussen, kein http von innen nach aussen, ...). Nur ein Ping auf eine IP (z. Bsp. 8.8.8.8) geht durch.
Auch wenn ich den gesamt ACL Block (mit access-list 111 deny ip any any am Ende) einfüge, habe ich keinerlei Verbindung (ausser, wie gesagt, Ping auf eine IP von innen nach aussen).
Das ist es ja, was ich nicht verstehe.
Meinem Verständnis nach werden die ACLs von oben nach unten abgearbeitet und wenn ein Match da ist, wird ausgestiegen.wenn aber noch kein deny any any da ist, kann ja auch nicht geblockt werden...
Ja, auf dem Interface ist die CBAC ACL 111 definiert.
Ja, es ist KEINE ACL 111 konfiguriert.
Nein, mit exakt dieser Konfiguration geht jeder Traffic durch (es existiert ja keine Deny any any).
Sobald ich die erste ACL (z.Bsp. access-list 111 permit icmp any any administratively-prohibited) eingebe, bricht jeglicher Traffic ab (kein Ping von aussen, kein http von innen nach aussen, ...). Nur ein Ping auf eine IP (z. Bsp. 8.8.8.8) geht durch.
Auch wenn ich den gesamt ACL Block (mit access-list 111 deny ip any any am Ende) einfüge, habe ich keinerlei Verbindung (ausser, wie gesagt, Ping auf eine IP von innen nach aussen).
Das ist es ja, was ich nicht verstehe.
Meinem Verständnis nach werden die ACLs von oben nach unten abgearbeitet und wenn ein Match da ist, wird ausgestiegen.wenn aber noch kein deny any any da ist, kann ja auch nicht geblockt werden...
es existiert ja keine Deny any any).
Eigentlich doch, denn wenn du keine ACL passend zur Index Nummer definiert hast gilt per Default immer ein Deny any any. Letzteres ist ja auch immer der Default eintrag in einer ACL.Deshalb sollte eigentlich so eine leere ACL alles blocken.
Sobald ich die erste ACL (z.Bsp. access-list 111 permit icmp any any administratively-prohibited) eingebe, bricht jeglicher Traffic ab
Auch das ist vollkommen klar !Passiert ja genau das gleiche wie oben. ICMP wird erlaubt alles andere aber geblockt, da ja deny any any gilt. Lässt sich auch wunderbar an einem Labor Cisco verifizieren hier.
Ohne ACL 111 kannst du die Dialer0 IP (Provider) von außen pingen ??
Wenn das der Fall ist kannst du mal eine 11er mit
access-list 111 permit icmp any any
definieren. Dann sollte weiterhin alles geblockt sein außer Ping von außen. Hast du das mal probiert ?
Meinem Verständnis nach werden die ACLs von oben nach unten abgearbeitet und wenn ein Match da ist, wird ausgestiegen
Das ist auch genau richtigaber noch kein deny any any da ist,
Wie gesagt das ist immer Default...
Oooook... Ich muss definitiv Abbitte leisten.
Die Komminkation von innen nach aussen klappt einwandfrei.
Wenn ein icmp echo noch hinzugefügt wird, klappt auch der Ping von aussen...
Ich schulde Dir mindestens eine grosse Kanne Kaffee...
Aber eine Frage habe ich noch: heute morgen nach einem "clear int Dialer1" funktioniert ip ddns update nicht mehr
Eine Regel in der ACL blockiert diesen. aber ich finde nicht, welche...
Die Komminkation von innen nach aussen klappt einwandfrei.
Wenn ein icmp echo noch hinzugefügt wird, klappt auch der Ping von aussen...
Ich schulde Dir mindestens eine grosse Kanne Kaffee...
Aber eine Frage habe ich noch: heute morgen nach einem "clear int Dialer1" funktioniert ip ddns update nicht mehr
Eine Regel in der ACL blockiert diesen. aber ich finde nicht, welche...
Ich schulde Dir mindestens eine grosse Kanne Kaffee...
Gerne...ich bevorzuge einen Guatemala Grande Hier ist übrigens das Ding mit dem ich mal getestet hatte:
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 tcp 192.168.1.0 0.0.0.255 host 10.1.1.88
access-list 111 permit icmp 192.168.1.0 0.0.0.255 host 10.1.1.88 echo
access-list 111 permit icmp 10.1.1.0 0.0.0.255 host 10.1.1.88 echo
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 permit ospf any any
access-list 111 deny ip any any
Die fett gedruckten Regeln lassen Ping von außen und jegliche TCP basierten Connections (Telnet, SSH, HTTP(S) usw.) aus dem 192.168.1.0er Netz sowie OSPF Routing Updates zu auf das Router WAN Interface (hier 10.1.1.88)
Was dein DDNS Problem anbetrifft muss du mal checken WIE das Update gesendet wird. In der regel machen die Teile ja einen TCP 80 Request an den DDNS Hoster.
Dann müsstest du die ACL aufmachen das der WAN Port TCP 80 senden kann. Halte dich als Beispiel immer an den DNS Dienst oben wenn der Router DNS Proxy ist. Oder auch NTP. Die Einträge sind identisch.
access-list 111 permit tcp any eq http host <ip_adr_oder_netz_ddns_server>
Hi aqui,
ich habe diese Anleitung für meinen IPTV-Anschluss an einem 896va als Vorlage genutzt.
Doch ich bekomme mit dem Receiver kein Bild, bzw es kommt keine Verbindung zu stande, er bleibt bei 23% stehen.
ich habe beide Konfigurationen eingetippt.
bei "show ip int brief" sehe ich: Ethernet0.8 unassigned YES DHCP up up
folglich bekommt mein Interface keine IP
und bei show dhcp lease:
Temp IP addr: 0.0.0.0 for peer on Interface: Ethernet0.8
Temp sub net mask: 0.0.0.0
DHCP Lease server: 0.0.0.0, state: 3 Selecting
DHCP transaction id: A75
Lease: 0 secs, Renewal: 0 secs, Rebind: 0 secs
Next timer fires after: 00:00:01
Retry count: 3 Client-ID: xyz
Ich nutze die ZFW als Firewall und nicht CBAC.
Müsste ich da noch eine Einstellung einfügen?
Die Konfiguration für die ZFW ist auch aus dieser Anleitung!
Grüße
oOHiggsOo
ich habe diese Anleitung für meinen IPTV-Anschluss an einem 896va als Vorlage genutzt.
Doch ich bekomme mit dem Receiver kein Bild, bzw es kommt keine Verbindung zu stande, er bleibt bei 23% stehen.
ip multicast-routing
ip pim ssm default
!
interface Vlan1
description Lokales LAN
ip address 192.168.100.254 255.255.255.0
ip pim sparse-mode
ip nat inside
ip virtual-reassembly in
ip tcp adjust-mss 1452
ip igmp helper-address 62.155.243.102
ip igmp version 3
ip igmp explicit-tracking
ip igmp query-interval 15
(ip igmp proxy-service)*
!
interface Dialer0
description VDSL PPPoE Einwahl Interface
ip address negotiated
ip access-group 111 in
no ip redirects
no ip unreachables
no ip proxy-arp
ip mtu 1492
ip pim sparse-mode
ip nat outside
ip inspect myfw out
ip virtual-reassembly in
encapsulation ppp
ip igmp version 3
ip igmp query-interval 15
(ip igmp proxy-service)*
dialer pool 1
dialer-group 1
no keepalive
ppp authentication pap callin
ppp pap sent-username xxxxxxxx@t-online.de password 0 xxxxxxx
ppp ipcp dns request
ppp ipcp mask request
ppp ipcp route default
no cdp enable
!
ip pim rp-address 62.155.243.102
!
(*) Das Interface Kommando ip igmp proxy-service kann mit der neuen Enterain 2.0 Version der Telekom auch entfallen. Es ist nicht mehr zwingend notwendig !
Da die Telekom aber noch beide Optionen aktiv hat auch über das bis dato erforderliche VLAN 8 Tagging der Vollständigkeit halber auch diese Konfig Variante:
!
ip multicast-routing
ip pim ssm default
!
interface Ethernet0.8
description VDSL Multicast Entertain
encapsulation dot1Q 8
ip dhcp client broadcast-flag clear
ip address dhcp
ip pim sparse-mode
no ip mroute-cache
ip igmp version 3
ip igmp query-interval 15
ip igmp proxy-service
!
interface Vlan1
ip pim sparse-mode
ip igmp helper-address <Rendezvous Point IP>
ip igmp version 3
ip igmp explicit-tracking
ip igmp query-interval 15
ip igmp proxy-service
!
ip pim rp-address <Rendezvous Point IP>
Damit ist die Konfigurationsanpassung zur Nutzung etwaiger IP-TV Entertain Optionen problemlos und schnell möglich.
Update:
Die Prozedur der Rendezvous Point IP Adress Ermittlung ist mittlerweile einfacher als oben im PDF beschrieben.
Die Multicast Rendezvous Point IP Adressen werden über DHCP mitgeteilt. Wenn das Sub Interface Ethernet0.8 (VLAN Tag 8) korrekt konfiguriert ist, kommt es mit einer 10.X.X.X IP Adresse hoch ("show ip int brief"), und es werden 2 Routen gelernt. Ein show dhcp lease zeigt dann abhängig vom jeweiligen Ort z.B. so etwas an:
Temp ip static route0: dest 193.158.132.189 router 10.34.63.254
Temp ip static route0: dest 87.141.128.0 router 10.34.63.254
(Dank an Forumsmitglied @cpt-haddock für seinen Hinweis im u.a. Thread !)ich habe beide Konfigurationen eingetippt.
bei "show ip int brief" sehe ich: Ethernet0.8 unassigned YES DHCP up up
folglich bekommt mein Interface keine IP
und bei show dhcp lease:
Temp IP addr: 0.0.0.0 for peer on Interface: Ethernet0.8
Temp sub net mask: 0.0.0.0
DHCP Lease server: 0.0.0.0, state: 3 Selecting
DHCP transaction id: A75
Lease: 0 secs, Renewal: 0 secs, Rebind: 0 secs
Next timer fires after: 00:00:01
Retry count: 3 Client-ID: xyz
Ich nutze die ZFW als Firewall und nicht CBAC.
Müsste ich da noch eine Einstellung einfügen?
Die Konfiguration für die ZFW ist auch aus dieser Anleitung!
Grüße
oOHiggsOo
Hier ist eine laufende Konfig:
!
clock timezone CET 1 0
clock summer-time CEST recurring last Sun Mar 2:00 last Sun Oct 3:00
!
ip multicast-routing
!
interface GigabitEthernet0/0.8
description VDSL Multicast Entertain
encapsulation dot1Q 8
ip dhcp client broadcast-flag clear
ip address dhcp
ip pim sparse-mode
no ip route-cache
ip igmp version 3
ip igmp query-interval 15
ip igmp proxy-service
!
interface GigabitEthernet0/1
description internal network
ip address 192.168.5.2 255.255.255.0
ip pim sparse-mode
ip nat inside
ip virtual-reassembly in
ip igmp helper-address 10.246.63.254
ip igmp version 3
ip igmp explicit-tracking
ip igmp query-interval 15
ip igmp proxy-service
duplex auto
speed auto
!
interface Dialer0
description VDSL Einwahl Interface
ip address negotiated
ip access-group 111 in
no ip redirects
no ip unreachables
no ip proxy-arp
ip mtu 1492
ip pim sparse-mode
ip nat outside
ip inspect myfw1 out
ip virtual-reassembly in
encapsulation ppp
ip igmp version 3
ip igmp query-interval 15
ip igmp proxy-service
dialer pool 1
dialer-group 1
ppp authentication pap callin
ppp pap sent-username xxxxxxx
ppp ipcp dns request
ppp ipcp mask request
ppp ipcp route default
no cdp enable
!
!
ip dns server
ip pim rp-address 10.246.63.254
ip nat inside source list 101 interface Dialer0 overload
!
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 domain any
access-list 111 permit tcp any eq domain any
access-list 111 permit udp any eq 5060 any
access-list 111 permit udp any eq ntp any
access-list 111 permit igmp host 10.246.63.254 any
access-list 111 permit icmp host 10.246.63.254 any
access-list 111 permit igmp any 224.0.0.0 15.255.255.255
access-list 111 permit udp any gt 40000 any
Allerdings in einer CBAC Konfig nicht in einer ZFW Konfig. (Ist in den Thrwad Antworten)
Du kannst aber sehen das die ACL 111 auch Traffic von den Rendezvous Point IPs usw. passieren lassen muss.
Entsprechendes musst du natürlich für deine RP und IGMP Adresse auch einrichten in der ZFW.
Hilfreich wäre auch mal einen Wireshark Trace zu sehen vom Multicast Endgerät. Du kannst dir die IP TV Stationen auch mit einem PC oder laptop und VLC ansehen und den MC Aufbau da mitsnioffern.
https://iptv.blog/artikel/multicastadressliste/
!
clock timezone CET 1 0
clock summer-time CEST recurring last Sun Mar 2:00 last Sun Oct 3:00
!
ip multicast-routing
!
interface GigabitEthernet0/0.8
description VDSL Multicast Entertain
encapsulation dot1Q 8
ip dhcp client broadcast-flag clear
ip address dhcp
ip pim sparse-mode
no ip route-cache
ip igmp version 3
ip igmp query-interval 15
ip igmp proxy-service
!
interface GigabitEthernet0/1
description internal network
ip address 192.168.5.2 255.255.255.0
ip pim sparse-mode
ip nat inside
ip virtual-reassembly in
ip igmp helper-address 10.246.63.254
ip igmp version 3
ip igmp explicit-tracking
ip igmp query-interval 15
ip igmp proxy-service
duplex auto
speed auto
!
interface Dialer0
description VDSL Einwahl Interface
ip address negotiated
ip access-group 111 in
no ip redirects
no ip unreachables
no ip proxy-arp
ip mtu 1492
ip pim sparse-mode
ip nat outside
ip inspect myfw1 out
ip virtual-reassembly in
encapsulation ppp
ip igmp version 3
ip igmp query-interval 15
ip igmp proxy-service
dialer pool 1
dialer-group 1
ppp authentication pap callin
ppp pap sent-username xxxxxxx
ppp ipcp dns request
ppp ipcp mask request
ppp ipcp route default
no cdp enable
!
!
ip dns server
ip pim rp-address 10.246.63.254
ip nat inside source list 101 interface Dialer0 overload
!
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 domain any
access-list 111 permit tcp any eq domain any
access-list 111 permit udp any eq 5060 any
access-list 111 permit udp any eq ntp any
access-list 111 permit igmp host 10.246.63.254 any
access-list 111 permit icmp host 10.246.63.254 any
access-list 111 permit igmp any 224.0.0.0 15.255.255.255
access-list 111 permit udp any gt 40000 any
Allerdings in einer CBAC Konfig nicht in einer ZFW Konfig. (Ist in den Thrwad Antworten)
Du kannst aber sehen das die ACL 111 auch Traffic von den Rendezvous Point IPs usw. passieren lassen muss.
Entsprechendes musst du natürlich für deine RP und IGMP Adresse auch einrichten in der ZFW.
Hilfreich wäre auch mal einen Wireshark Trace zu sehen vom Multicast Endgerät. Du kannst dir die IP TV Stationen auch mit einem PC oder laptop und VLC ansehen und den MC Aufbau da mitsnioffern.
https://iptv.blog/artikel/multicastadressliste/
mit deiner 10er IP funktioniert es momentan.
Danke!!
Danke!!
Die Telekom hat da mal was geändert als sie auf RFC 1918 IPs im IP-TV Multicasting umgestellt haben !
An der Konfig ändert sich in diesem Beispiel nicht viel.
"ip pim rp-address 93.234.255.254" ändert sich damit in -> "ip pim rp-address 10.41.127.254 "
"ip igmp helper-address 93.234.255.254" ändert sich damit in -> "ip igmp helper-address 10.41.127.254"
http://www.cisco-forum.net/topic_4350.msg38180.html#msg38180
Die ZFW Firewall musst du dann natürlich auch auf diese IPs umstellen.
Möglich das die Rendzvous Point Adressen regional unterschiedlich sind. Damit könnte man das Antwort Verhalten noch verbessern wenn man eine in seiner regionalen Nähe nimmt. Deshalb vermutlich der Unterschied in den 10er IPs.
Vermutlich kann man die auch irgendwo ergoogeln...oder bekommt es über das Debuggen der ACL raus, denn die RP IP wird dynamisch übertragen.
An der Konfig ändert sich in diesem Beispiel nicht viel.
"ip pim rp-address 93.234.255.254" ändert sich damit in -> "ip pim rp-address 10.41.127.254 "
"ip igmp helper-address 93.234.255.254" ändert sich damit in -> "ip igmp helper-address 10.41.127.254"
http://www.cisco-forum.net/topic_4350.msg38180.html#msg38180
Die ZFW Firewall musst du dann natürlich auch auf diese IPs umstellen.
Möglich das die Rendzvous Point Adressen regional unterschiedlich sind. Damit könnte man das Antwort Verhalten noch verbessern wenn man eine in seiner regionalen Nähe nimmt. Deshalb vermutlich der Unterschied in den 10er IPs.
Vermutlich kann man die auch irgendwo ergoogeln...oder bekommt es über das Debuggen der ACL raus, denn die RP IP wird dynamisch übertragen.
Hallo Zusammen,
unser 866VAE läuft aktuell noch mit der 15.3.x Software und ich kam die Tage mal auf den Trichter, diese vielleicht mal zu aktualisieren.
Soweit so gut klappt das auch wunderbar, bis auf den VDSL Anschluss der Telekom...
Sobald ich eine Version >= 15.4.x verwende, bekomme ich folgendes Verhalten:
Die VDSL Leitung wird aufgebaut und funktioniert danach ein paar Minuten, bricht aber dann mit folgener debug Meldung beim ppp negotiation zusammen:
Das ppp packet throttle hat es leider nicht behoben.
Sobald ich im Dialer interface das "no keepalive" setze kommen die Meldungen nicht mehr, das VDSL Interface geht trotzdem ebenso nach kurzer Zeit down.
Wie kann ich dem Problem auf die Schliche kommen?
Vielen Dank im Voraus für alle Antworten.
Mfg
unser 866VAE läuft aktuell noch mit der 15.3.x Software und ich kam die Tage mal auf den Trichter, diese vielleicht mal zu aktualisieren.
Soweit so gut klappt das auch wunderbar, bis auf den VDSL Anschluss der Telekom...
Sobald ich eine Version >= 15.4.x verwende, bekomme ich folgendes Verhalten:
Die VDSL Leitung wird aufgebaut und funktioniert danach ein paar Minuten, bricht aber dann mit folgener debug Meldung beim ppp negotiation zusammen:
*Dec 30 22:42:54.775: Vi1 PPP: Missed 5 keepalives, taking LCP down
*Dec 30 22:42:54.775: Vi1 PPP DISC: Missed too many keepalives
*Dec 30 22:42:54.775: Vi1 PPP: Sending Acct Event[Down] id[54]
*Dec 30 22:42:54.775: PPP: NET STOP send to AAA.
*Dec 30 22:42:54.775: Vi1 IPCP: Event[DOWN] State[Open to Starting]
*Dec 30 22:42:54.775: Vi1 IPCP: Event[CLOSE] State[Starting to Initial]
*Dec 30 22:42:54.775: Vi1 LCP: O TERMREQ [Open] id 2 len 4
*Dec 30 22:42:54.775: Vi1 LCP: Event[CLOSE] State[Open to Closing]
*Dec 30 22:42:54.775: Vi1 PPP: Phase is TERMINATING
*Dec 30 22:42:54.775: Vi1 LCP: Event[DOWN] State[Closing to Initial]
*Dec 30 22:42:54.775: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access1, changed state to down
*Dec 30 22:42:54.775: Vi1 PPP: Phase is DOWN
*Dec 30 22:42:54.783: Di1 Deleted neighbor route from AVL tree: topoid 0, address 87.186.225.87
*Dec 30 22:42:54.783: Di1 IPCP: Remove route to 87.186.225.87
*Dec 30 22:42:54.783: %DIALER-6-UNBIND: Interface Vi1 unbound from profile Di1
*Dec 30 22:42:54.787: %LINK-3-UPDOWN: Interface Virtual-Access1, changed state to downSobald ich im Dialer interface das "no keepalive" setze kommen die Meldungen nicht mehr, das VDSL Interface geht trotzdem ebenso nach kurzer Zeit down.
Wie kann ich dem Problem auf die Schliche kommen?
Vielen Dank im Voraus für alle Antworten.
Mfg
Welche IOS Version nutzt du denn ? Und was viel wichtiger ist: Nutzt du die embeddete Modem Firmware oder eine externe ?
Die Modem Firmware scheint es aber nicht sein, denn wie du an den Debugger Meldungen siehst ist es ja das PPP Protokoll was die Leitung runternimmt.
Keepailve auf dem Dialer Interface muss immer gesetzt sein ansonsten kommt die PPPoE Session nach einer Provider Zwangstrenntung nicht mehr automatisch hich!
Besser ist auch das in einem separaten Thread hier zu behandeln um das obige Tutorial hier nicht unnötig aufzublähen !
Die Modem Firmware scheint es aber nicht sein, denn wie du an den Debugger Meldungen siehst ist es ja das PPP Protokoll was die Leitung runternimmt.
Keepailve auf dem Dialer Interface muss immer gesetzt sein ansonsten kommt die PPPoE Session nach einer Provider Zwangstrenntung nicht mehr automatisch hich!
Besser ist auch das in einem separaten Thread hier zu behandeln um das obige Tutorial hier nicht unnötig aufzublähen !
1
Hi Aqui ,
ich habe jetzt auch mal auf ZBF umgestellt. Internet geht aber (immer) noch kein Multicast IPTV Entertain TV und auch Telefon eingehend geht nicht - abgehend ja.
Ich habe die config ZFB umgebaut, da ich erstmal kein Gastnetz habe und zweitens kein VPN . Soll erstmal laufen.
Fehlt mir jetzt eine Internet zu private?
greets
Cyb
ich habe jetzt auch mal auf ZBF umgestellt. Internet geht aber (immer) noch kein Multicast IPTV Entertain TV und auch Telefon eingehend geht nicht - abgehend ja.
Ich habe die config ZFB umgebaut, da ich erstmal kein Gastnetz habe und zweitens kein VPN . Soll erstmal laufen.
Fehlt mir jetzt eine Internet zu private?
zone security private
zone security internet
class-map type inspect match-any internet-traffic-class
match protocol http
match protocol https
match protocol dns
match protocol icmp
match protocol pop3s
match protocol imaps
match protocol smtp extended
match protocol sip
match protocol sip-tls
match protocol rtsp
match protocol ftp
match protocol ftps
match protocol ssh
match protocol ntp
match protocol tftp
match protocol tcp
match protocol udp
class-map type inspect match-any router_protocols
match protocol icmp
match protocol udp
policy-map type inspect privatezuinternet
description Traffic private zu internet
class type inspect internet-traffic-class
inspect
class class-default
drop
policy-map type inspect routerzuinternet
description Traffic router zum internet
class type inspect router_protocols
inspect
class
policy-map type inspect internetzurouter
description Traffic internet zu router
class type inspect router_protocols
inspect
class class-default
drop
zone-pair security privatezuinternet source private destination internet
service-policy type inspect privatezuinternet
zone-pair security routerzuinternet source self destination internet
service-policy type inspect routerzuinternet
zone-pair security internetzurouter source internet destination self
service-policy type inspect internetzurouter
int gi0/1
zone-member security private
int gi0/0
zone-member security internet
int dialer0
zone-member security internetgreets
Cyb
Die Firewall ist falsch konfiguriert !
Falls Voice nicht gehen sollte lasse mal sip und sip-tls in der Class Map weg.
Bei Voice solltest du immer STUN aktivieren bzw. einen STUN Server nutzen auf den Endgeräten !
Thema Multicast.
Poste mal die Outputs:
show ppp all
show ip mroute
show ip pim interface
Ist vermutlich die Fortzetzung von HIER, oder ? Sorry hatte da im Eifer des Gefechts vergessen drauf zu antworten.
Testest du das mit VLC ?
- policy-map type inspect routerzuinternet dem fehlt das "drop".
- Eine Policy Map policy-map type inspect internetzurouter ist bei dir überflüssig und kann ganz entfallen (kein VPN)
- Das Träger Interface auf das der Dialer gemappt ist wird niemals mit einer Zone definiert !! Logisch gesehen ist ausschliesslich nur das Dialer Interface und das lokale LAN relevant für die FW Zonen !
Falls Voice nicht gehen sollte lasse mal sip und sip-tls in der Class Map weg.
Bei Voice solltest du immer STUN aktivieren bzw. einen STUN Server nutzen auf den Endgeräten !
Thema Multicast.
Poste mal die Outputs:
show ppp all
show ip mroute
show ip pim interface
Ist vermutlich die Fortzetzung von HIER, oder ? Sorry hatte da im Eifer des Gefechts vergessen drauf zu antworten.
Testest du das mit VLC ?
Hi Aqui,
thx erstmal..
das drop war copy Fehler ..Argh... die Zone habe ich angepasst für Dialer und internetzurouter erstmal entfernt.
Ausgehend hat Telefonie geklappt. Aber nicht eingehender call.. Kommt der nicht initial von "outside" ? Das versteh ich nicht
Ich habe als SIP Gateway ja die FB .:Dort ist auch STUN aktiviert bei Server.
Öhm ja auf den Post aufbauend geht neuerdings nichts mehr. Weder in alt CBAC noch jetzt mit ZBFW .
Mit VLC test ich ja.. ging mal aber jetzt auch nicht mehr.
Danke vorab
greets
Cyb
thx erstmal..
das drop war copy Fehler ..Argh... die Zone habe ich angepasst für Dialer und internetzurouter erstmal entfernt.
Ausgehend hat Telefonie geklappt. Aber nicht eingehender call.. Kommt der nicht initial von "outside" ? Das versteh ich nicht
Ich habe als SIP Gateway ja die FB .:Dort ist auch STUN aktiviert bei Server.
Öhm ja auf den Post aufbauend geht neuerdings nichts mehr. Weder in alt CBAC noch jetzt mit ZBFW .
Mit VLC test ich ja.. ging mal aber jetzt auch nicht mehr.
show ppp all
Interface/ID OPEN+ Nego* Fail- Stage Peer Address Peer Name
------------ --------------------- -------- --------------- --------------------
Vi3 LCP+ IPCP+ LocalT 62.155.246.164 JUNOSsh ip mroute
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
L - Local, P - Pruned, R - RP-bit set, F - Register flag,
T - SPT-bit set, J - Join SPT, M - MSDP created entry, E - Extranet,
X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
U - URD, I - Received Source Specific Host Report,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group,
V - RD & Vector, v - Vector
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 233.89.188.1), 02:46:19/00:02:49, RP 62.155.246.164, flags: SJC
Incoming interface: Dialer0, RPF nbr 62.155.246.164
Outgoing interface list:
GigabitEthernet0/1, Forward/Sparse, 02:46:19/00:02:49
(*, 239.255.255.250), 02:46:20/stopped, RP 62.155.246.164, flags: SJCF
Incoming interface: Dialer0, RPF nbr 62.155.246.164
Outgoing interface list:
GigabitEthernet0/1, Forward/Sparse, 02:46:20/00:02:50
(192.168.5.101, 239.255.255.250), 02:44:42/00:02:08, flags: PFT
Incoming interface: GigabitEthernet0/1, RPF nbr 0.0.0.0, Registering
Outgoing interface list: Null
(192.168.5.156, 239.255.255.250), 02:45:21/00:01:38, flags: PFT
Incoming interface: GigabitEthernet0/1, RPF nbr 0.0.0.0, Registering
Outgoing interface list: Null
(192.168.5.1, 239.255.255.250), 02:45:43/00:01:06, flags: PFT
Incoming interface: GigabitEthernet0/1, RPF nbr 0.0.0.0, Registering
Outgoing interface list: Null
(87.141.215.251, 232.0.20.35), 00:27:04/00:02:50, flags: sTI
Incoming interface: Dialer0, RPF nbr 62.155.246.164
Outgoing interface list:
GigabitEthernet0/1, Forward/Sparse, 00:27:04/00:02:50
(*, 239.254.127.63), 02:46:19/00:02:51, RP 62.155.246.164, flags: SJC
Incoming interface: Dialer0, RPF nbr 62.155.246.164
Outgoing interface list:
GigabitEthernet0/1, Forward/Sparse, 02:46:19/00:02:51
(*, 224.0.1.60), 02:46:19/00:02:50, RP 62.155.246.164, flags: SJC
Incoming interface: Dialer0, RPF nbr 62.155.246.164
Outgoing interface list:
GigabitEthernet0/1, Forward/Sparse, 01:56:48/00:02:50
(*, 224.0.1.40), 02:46:21/00:01:37, RP 62.155.246.164, flags: SJCL
Incoming interface: Dialer0, RPF nbr 62.155.246.164
Outgoing interface list:
GigabitEthernet0/1, Forward/Sparse, 02:46:20/00:01:37show ip pim interface
Address Interface Ver/ Nbr Query DR DR
Mode Count Intvl Prior
192.168.5.2 GigabitEthernet0/1 v2/S 0 30 1 192.168.5.2
91.37.144.253 Dialer0 v2/S 1 30 1 0.0.0.0
0.0.0.0 Virtual-Access3 v2/S 0 30 1 0.0.0.0Danke vorab
greets
Cyb
Aber nicht eingehender call..
Nimm die ZFW Konfig testweise mal weg von den Interfaces und teste das mal ganz ohne Firewall.Klappt das dann ? Nur um mal sicherzugehen das du nicht noch einen anderen grundlegenden Fehler begangen hast ?!
In der Regel klappt SIP bzw. VoIP problemlos.
Thema Entertain...
Hast du den Rendezvous Point auf die 62.155.246.164 eingestellt ? Wenn nicht nutze diese IP mal dafür.
Hast du mit VLC beide Optionen mal getestet Entertain und Entertain TV. Die Multicast URL sind unterscxhiedlich.
Soweit sieht das gut aus. Die Multicast Router "sehen" sich.
Stimmt die MC Konfig mit der des Tutorials genau überein ?!
Konnte noch kurz testen.
Irgendwie habe ich Mainzelmännchen...wie es scheint... Oder die Telekomiker haben was gemacht.
Hab die config von vor ZFW ja gesichert gehabt. Und da ging auch kein Entertain mehr.
Zurückgesichert nach Test von ZFW und eben mal getestet , Entertain läuft. Aber nicht über VNC auch nicht alt.
Ja RP ist so eingestellt. War er ja jetzt schon die ganze Zeit vorher auch.
Das mit ZFW teste ich morgen ob es ohne mit Telefon geht.
Komische Dinge die passieren
greets
Cyb
Irgendwie habe ich Mainzelmännchen...wie es scheint... Oder die Telekomiker haben was gemacht.
Hab die config von vor ZFW ja gesichert gehabt. Und da ging auch kein Entertain mehr.
Zurückgesichert nach Test von ZFW und eben mal getestet , Entertain läuft. Aber nicht über VNC auch nicht alt.
Ja RP ist so eingestellt. War er ja jetzt schon die ganze Zeit vorher auch.
Das mit ZFW teste ich morgen ob es ohne mit Telefon geht.
Komische Dinge die passieren
greets
Cyb
Du meinstest sicher "VLC" oder ? Mit VNC kannst du lange auf bewegte Bilder warten
Ja klar meinte ich VLC .. Lol ..hatte leider mal wieder keine Zeit zum testen. (Mein Mikrotik hat auch schon Staub angesetzt )
Dubioserweise läuft es jetzt wieder absolut ruckelfrei seit Tagen.
Verstehs wer will... argh... Vielleicht klappt es ja morgen zum Testen.
greets
Cyb
Wie schon im anderen Post geschrieben Konfig bereinigen und das Query Intervall auf default.
Folgendes sollte reichen auf den Interfaces und so immer ruckelfrei laufen:
Folgendes sollte reichen auf den Interfaces und so immer ruckelfrei laufen:
!
interface VLAN1
decription Lokales LAN
ip igmp helper-address 62.155.x.y
ip igmp version 3
ip igmp explicit-tracking
ip igmp proxy-service
!
Interface Dialer 0
description Telekom xDSL Interface
ip pim sparse-mode
ip igmp version 3
ip igmp proxy-service
!
ip pim rp-address 62.155.x.y
ip pim ssm default
Ein paar Flüchtigkeitsfehler die mir so aufgefallen sind.
Einziger Unterschied ist das der Traffic über den Port nicht extra in den Reporten auftaucht (show xxx) sondern mit untergeht in
den „catch all" UDP/TCP/ICMP Statement am Schluss der CBAC / ZBF Match Liste.
Das wird wohl mit Gedanken auf ASA / PIX Setup so übernommen worden sein. IOS Tickt aber ein wenig anders.
Hier Handelt es sich in der Konstellation ausschließlich um Layer 3 u. 4 Filter = Statefuel Port Filter.
Von dem was transportiert wird hat der Bursche keine Ahnung.
(ip port-map zum erweitere bzw. sh ip port-map ? zeigt an welche Ports den zugewiesen sind zum Namen)
Unter IOS würde „no ip nat service sip udp port 5060” ggf. helfen um das SIP ALG Stillzulegen.
Hier würde ggf. http bzw. TCP fehlen sonst ist es essig mit DDNS Updates via http.
Wobei mich hier eines interessieren würde, unter welche IOS hast du das getestet ?
Da du die VPN Ports in eine ACL ausgelagert hast gehe ich davon aus das dein IOS auch ein lustiges
ABER: unter 154-3.M9 wird ein match protocol udp / tcp zwar genom men wird aber es wird ignoriert bzw. Es findet kein Inspect statt
(getestet mit DDNS update, Telnet Out und DNS Query) die regeln werden einfach ignoriert.
Als ACL match tut hingegen was es soll.
Gruß
Gierig
ip dhcp excluded-address 172.16.100.1 172.16.100.149 <-- IP Adressbereich DHCP Pool Gastnetz
ip dhcp excluded-address 172.16.100.100 172.16.100.254
Das Gast Netz bekommt so keine IP per DHCP mehr.(Beide Zeilen blocken das Gesamte Netz)ip dhcp excluded-address 172.16.100.100 172.16.100.254
ip inspect name myfw sip <-- Firewall Application Gateway f. VoIP
ip inspect name myfw rtsp <-- Firewall Application Gateway f. VoIP
bzw. weiter unten beim Zonen Firewall Teilip inspect name myfw rtsp <-- Firewall Application Gateway f. VoIP
(match protocol sip) --> (ggf. weglassen wenn interne VoIP Anlage oder Telefone Probleme machen)
Das Entfernen oder Hinzufügen macht keinen Unterschied. Es wird so oder so auf die gleiche Art und Weise funktionieren oder auch nicht.Einziger Unterschied ist das der Traffic über den Port nicht extra in den Reporten auftaucht (show xxx) sondern mit untergeht in
den „catch all" UDP/TCP/ICMP Statement am Schluss der CBAC / ZBF Match Liste.
Das wird wohl mit Gedanken auf ASA / PIX Setup so übernommen worden sein. IOS Tickt aber ein wenig anders.
Hier Handelt es sich in der Konstellation ausschließlich um Layer 3 u. 4 Filter = Statefuel Port Filter.
Von dem was transportiert wird hat der Bursche keine Ahnung.
(ip port-map zum erweitere bzw. sh ip port-map ? zeigt an welche Ports den zugewiesen sind zum Namen)
Unter IOS würde „no ip nat service sip udp port 5060” ggf. helfen um das SIP ALG Stillzulegen.
class-map type inspect match-any Router_Protocols
match class-map IPsec_VPN
match protocol icmp
match protocol udp
match class-map IPsec_VPN
match protocol icmp
match protocol udp
Hier würde ggf. http bzw. TCP fehlen sonst ist es essig mit DDNS Updates via http.
Wobei mich hier eines interessieren würde, unter welche IOS hast du das getestet ?
Da du die VPN Ports in eine ACL ausgelagert hast gehe ich davon aus das dein IOS auch ein lustiges
%Protocol configured in class-map XXX cannot be configured for the self zone with inspect action. Please remove the protocol and retry.
bekommst. (Cisco bug CSCsq44101 scheint noch aktuell zu sein)ABER: unter 154-3.M9 wird ein match protocol udp / tcp zwar genom men wird aber es wird ignoriert bzw. Es findet kein Inspect statt
(getestet mit DDNS update, Telnet Out und DNS Query) die regeln werden einfach ignoriert.
permit udp any any eq domain
permit tcp any any eq domain
permit udp any any eq ntp
permit tcp any any eq www
permit tcp any any eq telnet
permit icmp any any
deny ip any anyAls ACL match tut hingegen was es soll.
Gruß
Gierig
Das Gast Netz bekommt so keine IP per DHCP mehr.
Danke für das Feedback. 👍Du hast Recht ! Ein Typo, sorry. Ist korrigiert.
Das Entfernen oder Hinzufügen macht keinen Unterschied.
Das ist so leider nicht richtig. Das kannst du auch sehen wenn du dir die Sessions mit aktivem SIP mal etwas genauer ansiehst.Die ZFW trackt dann sehr genau Sessions und das SIP Protokoll an sich inkl. Protokoll Header mit.
Ohne die SIP Spezifikation untersucht die Firewall nur schlicht den Standard TCP oder UDP Header OHNE spezifische SIP Protokoll Analyse.
Wäre deine Theorie richtig müsste man ja keinerlei weitere Protokoll Spezifikation machen müssen und es würde nur rein TCP oder UDP reichen, was natürlich komplett falsch wäre.
Es ist aber generell ein Unterschied CBAC zu verwenden oder eben ZFW. Diese Details alle zu berücksichtigen würde den Rahmen des Tutorial sprengen. Da CBAC quasi tot ist sollte man eh nur noch ZFW nutzen.
unter welche IOS hast du das getestet ?
Version 15.6(3)M4Danke fürs Korrektur Feedback
Das Entfernen oder Hinzufügen macht keinen Unterschied.
Das ist schlicht falsch. Das kannst du auch sehen wenn du dir die Sessions mit aktivem SIP mal etwas genauer ansiehst.Nun werde ich ganz kleinlaut und trete verlegen auf der Stelle. Du hast natürlich recht !
Grade ein
class-map type inspect match-all test
match protocol sipals Inspect meiner Policy Map hinzugefügt (natürlich vor den generellen kram)
ein
debug policy-firewall protocol sipHat mich dann mit seiner Ausgabe erleuchtet.
Da CBAC quasi tot ist sollte man eh nur noch ZFW nutzen.
Zustimmung CBAC ist tot.Danke fürs Korrektur Feedback
Gerne
Nachtrag für ein wenig Rettung der eignen Ehre
SIP -> Da wird einiges geprüft
FTP -> Port Tracking um z.b den Daten Kanal zu öffnen
So Far so good
HTTP, POP3, IMAP, SMTP, SSH,Telnet... -> Nix nur Normale Stateful Inspection.
Diese könnten also auch mit einem "match protocol TCP" zusammengefast werden.
(solange halt nicht eine L7 Map hinzugefügt wird)
SIP -> Da wird einiges geprüft
FTP -> Port Tracking um z.b den Daten Kanal zu öffnen
So Far so good
HTTP, POP3, IMAP, SMTP, SSH,Telnet... -> Nix nur Normale Stateful Inspection.
Diese könnten also auch mit einem "match protocol TCP" zusammengefast werden.
(solange halt nicht eine L7 Map hinzugefügt wird)
Alles gut ! Feedback ist immer hilfreich !
Bei SMTP sollte man immer noch den Parameter extended (undokumentiert) hinzufügen das auch Secure SMTP mit inspiziert wird
Das HTTP so durchrennt...mmmhhh. Du kannst ja mit der ZFW ein URL Filtering machen (und noch viel mehr) bei HTTP. Damit muss die FW dann tiefer ins Paket reinsehen. Es kann also nicht nur normale TCP Inspection sein. Aber gut möglich das dies nur passiert wenn die Konfig dazu auch entsprechend ist.
Bei SMTP sollte man immer noch den Parameter extended (undokumentiert) hinzufügen das auch Secure SMTP mit inspiziert wird
Das HTTP so durchrennt...mmmhhh. Du kannst ja mit der ZFW ein URL Filtering machen (und noch viel mehr) bei HTTP. Damit muss die FW dann tiefer ins Paket reinsehen. Es kann also nicht nur normale TCP Inspection sein. Aber gut möglich das dies nur passiert wenn die Konfig dazu auch entsprechend ist.
Bei SMTP sollte man immer noch den Parameter extended (undokumentiert) hinzufügen das auch Secure SMTP mit inspiziert wird
der Parameter extended ist/war IMHO für ESMTP nicht für Secure SMTP.
Anyways der parameter is hidden weil mittlerweile SMTP und ESMTP beide erkannt und behandelt werden.
Er sollte auch bei dir nicht mehr im ConfigFile zu sehen sein.
Verkehrt ist er aber nicht für ältere IOS die das noch getrennt haben
Kann Leider grade nicht finden ab wann das geändert wurde aber ich glaube mit 15.1 (bei 12.4x noch getrennt)
Aber wie auch bei HTTP findet ohne L7 Map aber keine weitere Inspektion statt.
(erst mit der L7 Map ala class-map type inspect smtp match-any class-map-name)
Das HTTP so durchrennt...mmmhhh. Du kannst ja mit der ZFW ein URL Filtering machen (und noch viel mehr) bei HTTP. Damit muss die FW dann tiefer ins Paket reinsehen. Es kann also nicht nur normale TCP Inspection sein. Aber gut möglich das dies nur passiert wenn die Konfig dazu auch entsprechend ist.
Ack, bei einer zusätzlichen L7 Map (+Service Policy auf der L3L4 Policy Map) kommt die Deep Packet Inspektion dazu. Dann ist klar das hier Tiefer reingeschaut wird. Das gilt für HTTP genauso für SMTP und auch SIP (und andere). Deswegen wundert es mich eigentlich das eine L3/L4 Map mit match protocol SIP hier bereits so aktive die session trackt.
Aber es is wie es ist
der Parameter extended ist/war IMHO für ESMTP nicht für Secure SMTP.
Richtig ! Sorry, freudscher Fehler... 
Hallo, kann mir jemand bitte sagen ob ich auch einen Modem brauche - fritzbox uzw. Oder isdn Kabel nur mit C886VA verbinden ?Und dann brauche ich auch einen Switch oder direkt nur 4 pcs mit dem C886Va verbinden ? Schuldigung für die Frage aber ich kenne mich nicht aus mit Cisco, ich lerne es ab paar Tagen.
Danke
Danke
Einfach mal das Tutorial oben wirklich lesen ! 😉
Dort steht eigentlich alles haarklein beschrieben zu deinen Fragen. Aber weil du es bist gerne nochmal:
Der 886va hat ein integriertes Hybridmodem für ADSL2 und auch VDSL. Also egal ob du ADSL oder VDSL hast, brauchst du ihn wie eine FritzBox nur in die Wanddose stecken vom Provider und gut iss.
Ein externes Modem ist NICHT erforderlich für xDSL.
Der Router hat einen integrierten 4 Port LAN Switch. Wenn du also nur 4 Endgeräte hast kannst du die direkt an dem Router betreiben.
Nur wenn du mehr als 4 Endgeräte im lokalen Netz hast benötigst du einen externen Switch.
Alles also genau so wie bei jedem Feld- Wald- Und Wiesenrouter für DSL nur das es eben ein Cisco ist mit dem mächtigen IOS Featureset !
Steht alles oben im Tutorial wie gesagt... Lesen hilft hier wirklich !
Dort steht eigentlich alles haarklein beschrieben zu deinen Fragen. Aber weil du es bist gerne nochmal:
Der 886va hat ein integriertes Hybridmodem für ADSL2 und auch VDSL. Also egal ob du ADSL oder VDSL hast, brauchst du ihn wie eine FritzBox nur in die Wanddose stecken vom Provider und gut iss.
Ein externes Modem ist NICHT erforderlich für xDSL.
Der Router hat einen integrierten 4 Port LAN Switch. Wenn du also nur 4 Endgeräte hast kannst du die direkt an dem Router betreiben.
Nur wenn du mehr als 4 Endgeräte im lokalen Netz hast benötigst du einen externen Switch.
Alles also genau so wie bei jedem Feld- Wald- Und Wiesenrouter für DSL nur das es eben ein Cisco ist mit dem mächtigen IOS Featureset !
Steht alles oben im Tutorial wie gesagt... Lesen hilft hier wirklich !
DAnke dir , ich bin wirtklich noob mit Netzwerke, und wollte fürs lernen etwas einrichten. Ich möchte dich no fragen wenn du dagegen nichts hast ...
Ich habe den Router gekauft und dein config copiert benutzername fürs Telekom eingegeben aber es hat nicht funktioniert... Dann habe ich rausgefunden dass mein Firmware alt ist , und kann nichts vom Cisco Webseite runterladen. Wo kann ich es bekommen? , hast du eine Webseite dafür ? Ich habe schon googelt aber nichts gefunden.
Oder könntest du mir es via Teamwiever velleicht probieren zu einrichten. Ich bezahle dir dafür auch.
Danke nochmals
Ich habe den Router gekauft und dein config copiert benutzername fürs Telekom eingegeben aber es hat nicht funktioniert... Dann habe ich rausgefunden dass mein Firmware alt ist , und kann nichts vom Cisco Webseite runterladen. Wo kann ich es bekommen? , hast du eine Webseite dafür ? Ich habe schon googelt aber nichts gefunden.
Oder könntest du mir es via Teamwiever velleicht probieren zu einrichten. Ich bezahle dir dafür auch.
Danke nochmals
fragen wenn du dagegen nichts hast ...
Locker bleiben...dafür ist ein Forum ja da. Aber User sollten auch mal etwas lesen....und verstehen dein config copiert benutzername fürs Telekom eingegeben aber es hat nicht funktioniert...
Dann hast du sicher etwas falsch gemacht !!- Hast du mal ins Router Logg mit show logg geshen ?? Stehen dort irgendwelche Fehlermeldungen ??
- Machst du ADSL oder VDSL ? Wichtig, da anderes Interface am Router !
- Interfaces alle auf no shut gesetzt ?
- xDSL Kabel korrekt angeschlossen RJ-11 ?
- Welche Firmware nutzt du ? Generell rennt die Konfig auch mit älteren Releases ?
- Synchronsiert das Modem ?? Was sagt ein show controller vdsl 0 ?
- Denke dran das du natürlich die PPPoE Provider User Credentials anpassen musst auf deine eigenen.
Versuche erstmal diese Schritte.
Hilfreich fürs Troubleshooting ist in jedem Falle ein show run deiner Konfig ! Sonst können wir auch nur raten hier.
Bitte denke dran deine Zugangsdaten zu anonymisieren sofern du die Konfig hier postest !
Wenn alle Stricke reissen setze den Router auf die Factory Defaults mit write erase und einem Reload und fange erstmal mit einer ganz einfachen Konfig rein nur des WAN/DSL Ports an. Am besten erstmal OHNE irgendwelche Firewall Konfig um nicht nochmehr Fehlerquellen zu haben.
Wenn der dann funktioniert machst du Schritt für Schritt den Rest.
P.S.: In case you are a native English speaker we can continue in English if this is easier for you to understand ?!
Ich mache das alles jetz nochmal wie du geschrieben hast.
Ich möchte aber, über das Kabel noch fragen . Ich habe VDSL2 17a (laut zyxel router) und Ich habe dieses Kabel : https://www.amazon.de/gp/product/B00TGYVY8I/ref=oh_aui_detailpage_o04_s0 ...
Dieses stecke ich ins ISDN Port. Gibts dort noch ein VDSL over ISDN port aber das ist kleiner, und mein Kabel geht nicht rein..MAche ich das gut mit dem Kabel oder kanz falsch?
PS: Deutsch ist ok ich muss es übenABer danke du bist sehr hilfsbereit.
Ich möchte aber, über das Kabel noch fragen . Ich habe VDSL2 17a (laut zyxel router) und Ich habe dieses Kabel : https://www.amazon.de/gp/product/B00TGYVY8I/ref=oh_aui_detailpage_o04_s0 ...
Dieses stecke ich ins ISDN Port. Gibts dort noch ein VDSL over ISDN port aber das ist kleiner, und mein Kabel geht nicht rein..MAche ich das gut mit dem Kabel oder kanz falsch?
PS: Deutsch ist ok ich muss es üben
ABer danke du bist sehr hilfsbereit.und Ich habe dieses Kabel :
Das ist technisch gesehen richtig aber dürfte eigentlich NICHT passen, denn der Cisco hat hinten für seinen ADSL/VDSL Port eine RJ-11 Buchse ! (Siehe Foto !)Dort passt das Kabel was du hast mechanisch gar nicht rein, weil das ja einen breiteren RJ-45 Stecker hat !!!
Der xDSL Port erzwingt aber einen kleineren RJ-11 Stecker so das du vermutlich gar keinen Kontakt hast also sprich der DSL Port physisch nicht verbunden ist !
Jedenfalls ist das so wenn du ein Cisco 886va oder vaw Modell hast ?!
Du brauchst also einen RJ-11 zu TAE Adapter:
https://www.amazon.de/Wentronic-Adapter-Stecker-Kupplung-schwarz/dp/B000 ...
und dann dazu ein ganz normales RJ-11 Kabel:
https://www.amazon.de/Goobay-50317-Modular-Kabel-Stecker-4-polig-Schwarz ...
Dieses stecke ich ins ISDN Port.
Totally wrong !!!ISDN is the BRI phone port and its not anymore used at all !
Dieser Port muss es sein:
Gibts dort noch ein VDSL over ISDN port aber das ist kleiner, und mein Kabel
Yepp, THAT one is the right port ! Use the right cable (RJ-11) and the right port and everything will be instantly up and running.Problem solved and case closed !
Hi all ,
nachdem ich nun auch auf ZBF umgestellt habe scheint es so, als ob ein Großteil der eingehenden Telefonate nicht durch geht. Manchmal geht es beim zweiten Anruf ..oder auch wenn ich mich selbst Anrufe und zurückrufe gleich. Habe schon SIP-TLS aus der inspect genommen. Immer noch. Kann man da noch was machen bzw . wie debuge ich das oder kann man das bypassen ? Macht das Sinn?
debug policy firewall sip hat bei Anrufen nichts angezeigt.
Thx
Cyb
nachdem ich nun auch auf ZBF umgestellt habe scheint es so, als ob ein Großteil der eingehenden Telefonate nicht durch geht. Manchmal geht es beim zweiten Anruf ..oder auch wenn ich mich selbst Anrufe und zurückrufe gleich. Habe schon SIP-TLS aus der inspect genommen. Immer noch. Kann man da noch was machen bzw . wie debuge ich das oder kann man das bypassen ? Macht das Sinn?
debug policy firewall sip hat bei Anrufen nichts angezeigt.
Thx
Cyb
Das liegt dann an deinem STUN bzw. dessen Konfig.
Um das erstmal zu fixen solltest du SIP komplett aus der Inspection nehmen und das rein dann über TCP UDP mit abfackeln. Das klappt dann sicher.
Um das erstmal zu fixen solltest du SIP komplett aus der Inspection nehmen und das rein dann über TCP UDP mit abfackeln. Das klappt dann sicher.
HI Aqui,
danke . öhm.. Alles was in der ZBF nicht inspect wird wird doch gedroppt oder ?Cisco ZBF
Dort Applying an ACL as Match Criteria denke ich . Verstehe aber nicht ganz wie das gemeint ist.
Und noch was ist mir aufgefallen - wollte ein VPN aufbauen ..Dazu Dyndns wie oben beschrieben von no-ip.com gemacht.
Aber ich bekomme nur failed auf Grund timeouts.(debug) Das heißt doch Verbindung kommt erst gar nicht an bzw. raus oder?
Danke
Greets
Cyb
danke . öhm.. Alles was in der ZBF nicht inspect wird wird doch gedroppt oder ?Cisco ZBF
Dort Applying an ACL as Match Criteria denke ich . Verstehe aber nicht ganz wie das gemeint ist.
Und noch was ist mir aufgefallen - wollte ein VPN aufbauen ..Dazu Dyndns wie oben beschrieben von no-ip.com gemacht.
Aber ich bekomme nur failed auf Grund timeouts.(debug) Das heißt doch Verbindung kommt erst gar nicht an bzw. raus oder?
Danke
Greets
Cyb
Alles was in der ZBF nicht inspect wird wird doch gedroppt
Absolut richtig !!Siehst du dir aber die Beispielkonfig von oben mal ganz genau an findest du dort ganz am Ende 2 wichtige Konfig Zeilen:
match protocol tcp
match protocol udp
Das heisst alles was nicht Protokoll spezifisch inspiziert und behandelt wird rennt dann über die globale TCP bzw. UDP Inspection. Die fackelt dann SIP und RTP auch mit ab, da ja TCP und UDP aber eben nicht so hart wie die Protokoll spezifische Inspection.
Wie gesagt essentiell wichtig ist das diese beiden Statements am Ende der Inspection Liste stehen. Niemals am Anfang. Hier gilt wieder: First match wins...!
Das bewirkt dann das SIP und RTP fehlerlos durchgehen.
Wenn du SIP und RTP Inspection machst sollte man STUN deaktivieren, denn das führt zu Fehlermeldungen der Firewall bzw. Application Gateway.
Hier mal das Setting einer Auerswald Anlage dazu:
Mit STUN sollte man die ZFW nur mit TCP und UDP dafür laufen lassen.
Hi Aqui,
danke erstmal.
Leider funktioniert es nicht wirklich. Ich habe die Firewall rausgenommen und es geht sofort. Mach ich Sie wieder an geht es nicht mehr bzw. so : Reinruf geht nicht. Ruf ich mich auf Handy an geht es und wenn ich dann zurückrufe geht auch rein. Aber nur gewisse Zeit ca .1-2 min. Dann wieder nix.
matches wie unten - hatte auch mal rtsp rausgenommen. Aber selbe Spiel. Fritzbox ist im Standard Einstellungen:. STUN Server ist hinterlegt.
Und weil es ZBFW betrifft: Muss ich für DDNS Update im Router zu internet match http dazumachen? Im Moment habe ich nur icmp und udp .
EDIT:
Habe mal die drop log eingschaltet und bekomme dann das bei einem Anruf von extern (5.1 ist die FB) :
Danke vorab
danke erstmal.
Leider funktioniert es nicht wirklich. Ich habe die Firewall rausgenommen und es geht sofort. Mach ich Sie wieder an geht es nicht mehr bzw. so : Reinruf geht nicht. Ruf ich mich auf Handy an geht es und wenn ich dann zurückrufe geht auch rein. Aber nur gewisse Zeit ca .1-2 min. Dann wieder nix.
matches wie unten - hatte auch mal rtsp rausgenommen. Aber selbe Spiel. Fritzbox ist im Standard Einstellungen:. STUN Server ist hinterlegt.
Und weil es ZBFW betrifft: Muss ich für DDNS Update im Router zu internet match http dazumachen? Im Moment habe ich nur icmp und udp .
EDIT:
Habe mal die drop log eingschaltet und bekomme dann das bei einem Anruf von extern (5.1 ist die FB) :
%FW-6-DROP_PKT: Dropping udp session 217.0.29.33:5060 192.168.5.1:5060 due to policy match failure with ip ident 0class-map type inspect match-any internet-traffic-class
match protocol http
match protocol https
match protocol dns
match protocol icmp
match protocol pop3s
match protocol imaps
match protocol smtp
match protocol ftp
match protocol ftps
match protocol ssh
match protocol ntp
match protocol tftp
match protocol rtsp
match protocol tcp
match protocol udpDanke vorab
Wie gesagt hier in mehrfachen ! Netzen mit Auerswald Anlage und Cisco Telefonen sowie Soft Clients wie Phoner und Zoiper vollkommen fehlerlos und unauffällig.
STUN in den Endgeräten deaktiviert und dafür dann aktiv SIP und RTSP in der Inspection aktiviert.
Hast du mal ins Log gesehen wenn du die SIP Inspection an hast ob da was mitgelogt wird beim SIP Polling ?
Sonst mal den Wireshark anschmeissen und nachsehen was da los ist.
STUN in den Endgeräten deaktiviert und dafür dann aktiv SIP und RTSP in der Inspection aktiviert.
Hast du mal ins Log gesehen wenn du die SIP Inspection an hast ob da was mitgelogt wird beim SIP Polling ?
Sonst mal den Wireshark anschmeissen und nachsehen was da los ist.
aqui hat recht, ich hatte das selbe problem.
Nachem ich "match protocol sip" rausgenommen habe, lief das ganze.
Habe den Router mit Entertain, no-ip DDNS Update, VoIP (FritzBox) und VPN am laufen gehabt.
Grüße
Nachem ich "match protocol sip" rausgenommen habe, lief das ganze.
Habe den Router mit Entertain, no-ip DDNS Update, VoIP (FritzBox) und VPN am laufen gehabt.
class-map type inspect match-any Lokal_erlaubt
match protocol http
match protocol https
match protocol pop3s
match protocol imaps
match protocol smtp
match protocol sip-tls
match protocol rtsp
match protocol ftp
match protocol ftps
match protocol ssh
match protocol ntp
match protocol dns
match protocol icmp
match protocol tcp
match protocol udp
Hi Aqui,
hm.. irgendwie ist meine Antwort gestern wohl nicht angekommen..
Ich glaube schon, dass es normal gehen sollte und das auch bei Euch tut..aber bei mir halt nicht wirklich.
Hatte gestern mit sip und debug geschaut . Da kommen immer violence error in der ZBFW. Ich habe nur reine ISDN und Dect Geräte an der FB. Sobald die an den Telekom Server will um die Nummern zu registrieren ..scheint es Fehler zu geben.
Muss ich nochmal machen dann und poste die Meldung. Eventuell kann man sehen warum. Ggfs liegt es ja auch am ios ? Mit ähnlichem Problem habe ich einen Bug schon gefunden gehabt mit meiner Version bzgl. SIP und Packets Drop.
greets
Cyb
hm.. irgendwie ist meine Antwort gestern wohl nicht angekommen..
Ich glaube schon, dass es normal gehen sollte und das auch bei Euch tut..aber bei mir halt nicht wirklich.
Hatte gestern mit sip und debug geschaut . Da kommen immer violence error in der ZBFW. Ich habe nur reine ISDN und Dect Geräte an der FB. Sobald die an den Telekom Server will um die Nummern zu registrieren ..scheint es Fehler zu geben.
Muss ich nochmal machen dann und poste die Meldung. Eventuell kann man sehen warum. Ggfs liegt es ja auch am ios ? Mit ähnlichem Problem habe ich einen Bug schon gefunden gehabt mit meiner Version bzgl. SIP und Packets Drop.
greets
Cyb
das auch bei Euch tut..aber bei mir halt nicht wirklich.
Dann hast du vermutlich noch einen Bock in deiner Konfig. Vermtlich auf dem VoIP Endgerät ?!Da kommen immer violence error in der ZBFW.
Klares Indiz das du weiterhin SIP Inspection machst obwohl dir hier mehrfach ! geraten wurde das mal zu deaktivieren und SIP über die normale TCP/UDP Instaction renne zu lassen !!! Siehe Post vom Kollegen @oOHiggsOo oben !Ich habe nur reine ISDN und Dect Geräte an der FB.
Das spielt logischerweise für die FW keinerlei Rolle. Diese "sieht" ja einzig nur die VoIP Pakete von der FB !!Muss ich nochmal machen dann und poste die Meldung.
Wir bitten drum ! SIP Inspection deaktivieren. Da wird es auch klappen !! Siehe Kollege @oOHiggsOo
Hi Aqui ,
Ich habe schon wie hier von Euch vorgeschlagen ohne SIP / SIP-TLS und sogar RTSP ausgeschaltet gehabt. Mit dem Debug hatte ich es nur wieder rein gemacht weil : ....
Ich stell es später nochmal um und poste.
Zitat von @aqui:
Klares Indiz das du weiterhin SIP Inspection machst obwohl dir hier mehrfach ! geraten wurde das mal zu deaktivieren und SIP über die normale TCP/UDP Instaction renne zu lassen !!! Siehe Post vom Kollegen @oOHiggsOo oben !
Klares Indiz das du weiterhin SIP Inspection machst obwohl dir hier mehrfach ! geraten wurde das mal zu deaktivieren und SIP über die normale TCP/UDP Instaction renne zu lassen !!! Siehe Post vom Kollegen @oOHiggsOo oben !
Ich habe schon wie hier von Euch vorgeschlagen ohne SIP / SIP-TLS und sogar RTSP ausgeschaltet gehabt. Mit dem Debug hatte ich es nur wieder rein gemacht weil : ....
Zitat von @aqui:
Hast du mal ins Log gesehen wenn du die SIP Inspection an hast ob da was mitgelogt wird beim SIP Polling ?
Habe sogar dann genau die Reihenfolge noch so eingestellt wie hier und schön TCP und UDP am Ende.Hast du mal ins Log gesehen wenn du die SIP Inspection an hast ob da was mitgelogt wird beim SIP Polling ?
Ich stell es später nochmal um und poste.
Hallo,
kannst du bitte das die gesamte Konfig posten?
ich vermute so langsam das durch das ständige probieren die Reihenfolge eben nicht so ist wie du das vermutest.
vergleiche auch mal ein
mit einem
brammer
kannst du bitte das die gesamte Konfig posten?
ich vermute so langsam das durch das ständige probieren die Reihenfolge eben nicht so ist wie du das vermutest.
vergleiche auch mal ein
sh runsh confbrammer
Hi brammer,
sorry war leider verhindert.
Hier die sh run : (ohne SIP)
Telefonate nach intern nicht möglich - extern geht.
Ausgehend Telefonat: mit debug policy-firewall protocol udp
Eingehend sehe ich aber irgendwie nix ..müsste doch auch über port 5060 was kommen oder?
sorry war leider verhindert.
Hier die sh run : (ohne SIP)
Telefonate nach intern nicht möglich - extern geht.
class-map type inspect match-any internet-traffic-class
match protocol http
match protocol https
match protocol pop3s
match protocol imaps
match protocol smtp
match protocol sip-tls
match protocol rtsp
match protocol ftp
match protocol ftps
match protocol ssh
match protocol ntp
match protocol dns
match protocol icmp
match protocol tftp
match protocol tcp
match protocol udp
class-map type inspect match-any router_protocols
match protocol icmp
match protocol udp
!
!
policy-map type inspect routerzuinternet
description Traffic router zum internet
class type inspect router_protocols
inspect
class class-default
drop
policy-map type inspect privatezuinternet
description Traffic private zu internet
class type inspect internet-traffic-class
inspect
class class-default
dropAusgehend Telefonat: mit debug policy-firewall protocol udp
Aug 7 11:11:30.388: FIREWALL sis 470861E0: pak 4610725C SIS_OPEN UDP packet (192.168.5.1:5060) <= (217.0.28.160:5060) datalen 600
Aug 7 11:11:33.348: FIREWALL sis 470861E0: pak 4776B4C4 SIS_OPEN UDP packet (192.168.5.1:5060) => (217.0.28.160:5060) datalen 747
Aug 7 11:11:33.364: FIREWALL sis 470861E0: pak 461047C0 SIS_OPEN UDP packet (192.168.5.1:5060) <= (217.0.28.160:5060) datalen 396
Aug 7 11:11:33.428: FIREWALL sis 470861E0: pak 4610398C SIS_OPEN UDP packet (192.168.5.1:5060) <= (217.0.28.160:5060) datalen 456
Aug 7 11:11:33.432: FIREWALL sis 470861E0: pak 46106DA0 SIS_OPEN UDP packet (192.168.5.1:5060) => (217.0.28.160:5060) datalen 426
Du hast entgegen aller Empfehlungen wieder die SIP und RTSP Inspection drin !
match protocol sip-tls
match protocol rtsp
Beides rausnehmen, rebooten und nochmal versuchen !
match protocol sip-tls
match protocol rtsp
Beides rausnehmen, rebooten und nochmal versuchen !
Hi Aqui ,
Ich dachte nur sip raus nehmen ?
Bin eventuell ein Schritt weiter : in der FB kann man eine Einstellung machen, das die Verbindung der Telefone über Router gehalten wird ..siehe Punkt 9
Titel
Seitdem scheint es zu gehen
Zumindest paar Testanrufe gingen..
Danke vorab
Greets
Ich dachte nur sip raus nehmen ?
Bin eventuell ein Schritt weiter : in der FB kann man eine Einstellung machen, das die Verbindung der Telefone über Router gehalten wird ..siehe Punkt 9
Titel
Seitdem scheint es zu gehen
Zumindest paar Testanrufe gingen..
Danke vorab
Greets
Ja, das ist auch sehr wichtig das das aktiviert wird !!!
Das ist ein SIP Keepalive. Damit schickt der VoIP Client (Anlage bzw. dein Router) SIP Pakete zyklisch an den SIP Server des Providers und hält so die outbound Firewall Verbindung offen.
Würde er das nicht machen timed die SIP Session nach einer Zeit aus und die Firewall schliesst den Port und inbound SIP Verbindungen (eingehende Calls) kommen da dann nicht mehr durch.
Wenn du das aktiv hast (Keepalive am Router) wirds vermutlich auch wieder mit SIP und RTP Inspection in der ZFW klappen
Das ist ein SIP Keepalive. Damit schickt der VoIP Client (Anlage bzw. dein Router) SIP Pakete zyklisch an den SIP Server des Providers und hält so die outbound Firewall Verbindung offen.
Würde er das nicht machen timed die SIP Session nach einer Zeit aus und die Firewall schliesst den Port und inbound SIP Verbindungen (eingehende Calls) kommen da dann nicht mehr durch.
Wenn du das aktiv hast (Keepalive am Router) wirds vermutlich auch wieder mit SIP und RTP Inspection in der ZFW klappen
Hi Aqui,
danke nochmal .. ohne SIP Inspection geht es nun. Ist das problematisch /Sicherheit? Sollte doch eh verschlüsselt sein oder?
Btw.
Ich wollt den nächstenStep vor VPN machen... Dyndns .. aber irgendwie kriege ich da einen timeout
Muss ich da bei der ZBFW für router zu internet traffic - http freischalten? Debug zeigt nur timeout s.o.
Danke
Greets
Cyb
danke nochmal .. ohne SIP Inspection geht es nun. Ist das problematisch /Sicherheit? Sollte doch eh verschlüsselt sein oder?
Btw.
Ich wollt den nächstenStep vor VPN machen... Dyndns .. aber irgendwie kriege ich da einen timeout
HTTPDNSUPD: Call returned Connection time out, update of name.ddns.net <=> 87.144.2.87 failedMuss ich da bei der ZBFW für router zu internet traffic - http freischalten? Debug zeigt nur timeout s.o.
Danke
Greets
Cyb
Muss ich da bei der ZBFW für router zu internet traffic - http freischalten? Debug zeigt nur timeout s.o.
JA.
ggf über ne Access liste ej nach IOS gibt es hier und da noch den CSCsq44101
bug (match Protocol funktioniert hier nicht)
also z.B (anpassen an deine Situation, Namens Schema)
class-map type inspect match-any SelfToWan
match access-group name ZBF-SelfToWan
ip access-list extended ZBF-SelfToWan
remark --> ACL for ZBF Selfzone that need INSPECT as match protocol will not work (CSCsq44101)
remark --> DNS, NTP, WWW (DDNS) & ICMP allow to out
permit udp any any eq domain
permit tcp any any eq domain
permit udp any any eq ntp
permit tcp any any eq www
permit icmp any any
deny ip any anyach ja management-interface in der controll plane kann auch Probleme bereiten
da ggf der return traffic darüber geblockt wird. (hab dazu case laufen bei Cisco
Ist das problematisch /Sicherheit? Sollte doch eh verschlüsselt sein oder?
Nein, ist es nicht, denn das rennt dann über die normale UDP bzw. TCP Inspection.SIP ist übrigens NICHT verschlüsselt !
Muss ich da bei der ZBFW für router zu internet traffic - http freischalten?
Ja, das musst du. Du musst HTTP Traffic TCP 80 von Local (Selfzone) nach extern erlauben. Kollege @gierig hats ja schon gesagt.
Hey gierig,
thx danke. War genau das problem mit dem bug. Nimmt kein http.
ACC List - und es ward success
ok..dann kann ich mich ja an VPN dran machen.
greets
Cyb
thx danke. War genau das problem mit dem bug. Nimmt kein http.
ACC List - und es ward success
ok..dann kann ich mich ja an VPN dran machen.
greets
Cyb
Hi Aqui,
super.Danke. Mit der ACC List ging es dann.
Zumindest kam mal
Greets
Cyb
btw.. hab grad nen Synthax Fehler gesehen beim VPN IP Sec:
muss wohl vpngroup heißen.
super.Danke. Mit der ACC List ging es dann.
Zumindest kam mal
HTTPDNSUPD: Call returned SUCCESS, update of name.ddns.net <=> ip succeededCyb
btw.. hab grad nen Synthax Fehler gesehen beim VPN IP Sec:
username vpngoup password test123
So VPN mal aufgesetzt aber hatte folgende Probleme:
Kam Meldung mit ist schon mit Serial belegt kann nicht geändert werden
Meine Lösung :
Habe dann alles von template 2 auf 3 gemacht
Group kann ich nirgends bei VPN eingeben.. getestet mit dem org. VPN von android und strong swan
(in dem log vom swan kann ich sehen, dass er die IP von mir hat- dyndns geht also).
- Eistellung ZBFW laut Anleitung steht da das Virtual Template 1 ?
- Hab das auch auf 3 angepasst. Müsste das dann nicht 2 sein ??
Imo sieht mein ip int brief so aus :
greets
Cyb
interface Virtual-Template2 type tunnelMeine Lösung :
Habe dann alles von template 2 auf 3 gemacht
Group kann ich nirgends bei VPN eingeben.. getestet mit dem org. VPN von android und strong swan
(in dem log vom swan kann ich sehen, dass er die IP von mir hat- dyndns geht also).
- Eistellung ZBFW laut Anleitung steht da das Virtual Template 1 ?
- Hab das auch auf 3 angepasst. Müsste das dann nicht 2 sein ??
Imo sieht mein ip int brief so aus :
NVI0 192.168.5.2 YES unset up up
Tunnel0 192.168.5.2 YES unset up up
Virtual-Access1 unassigned YES unset down down
Virtual-Access2 unassigned YES unset up up
Virtual-Access3 unassigned YES unset up up
Virtual-Template2 unassigned YES unset down down
Virtual-Template3 192.168.5.2 YES unset up downgreets
Cyb
muss wohl vpngroup heißen.
Ooops...shame on me. Ist korrigiert! Danke für den Hinweis! 👍StrongSwan Beispiele findest du hier:
https://www.cisco.com/c/en/us/support/docs/network-management/remote-acc ...
und hier:
https://wiki.strongswan.org/projects/strongswan/wiki/IKEv1Examples
IKEv2 VPN Server für Windows und Apple Clients mit Raspberry Pi
IKEv1 und Xauth ist die Suchoption
Hi und danke ,
ich nehme auch gerne Cisco.,. aber bei dem Cisco Anyconnect den ich habe für Android habe ich die o.g. Einstellungen nicht eingeben können mit Group und Namen.
..
ich nehme auch gerne Cisco.,. aber bei dem Cisco Anyconnect den ich habe für Android habe ich die o.g. Einstellungen nicht eingeben können mit Group und Namen.
..
ok..mit dem native vpn von Android hab ich es hinbekommen.
Bei Cisco und dem swan finde ich nichts was ipsec psk hat und mit Group und user ist.
thx
Bei Cisco und dem swan finde ich nichts was ipsec psk hat und mit Group und user ist.
thx
Hi Aqui,
also wie geschrieben..mit dem Native VPN von Android klappt die Verbindung. Konnte auch auf PCs im Network bei mir bzw. anrufen. Aber http / https scheint nicht zu gehen.Hat das was mit der ACL von Self Zone zu tun?
greets
Cyb
also wie geschrieben..mit dem Native VPN von Android klappt die Verbindung. Konnte auch auf PCs im Network bei mir bzw. anrufen. Aber http / https scheint nicht zu gehen.Hat das was mit der ACL von Self Zone zu tun?
greets
Cyb
Nein ! HTTP und HTTPS ins lokale Netz sollten problemlos laufen.
Das Tunnel Interface hat die gleiche Zone wie das lokale LAN:
⚠️ Auf dem Tunnel Interface und auch auf dem VLAN 1 Interface darf proxy-arp nicht ausgeschaltet sein !
Wenn dort no ip proxy-arp steht dann funktioniert das VPN nicht ins lokale LAN !
Das Tunnel Interface hat die gleiche Zone wie das lokale LAN:
interface Virtual-Template2 type tunnel
description IPsec VPN Dialin
ip unnumbered Vlan1
zone-member security Home
ip tcp adjust-mss 1452
tunnel mode ipsec ipv4
tunnel protection ipsec profile vpn-vti2 ⚠️ Auf dem Tunnel Interface und auch auf dem VLAN 1 Interface darf proxy-arp nicht ausgeschaltet sein !
Wenn dort no ip proxy-arp steht dann funktioniert das VPN nicht ins lokale LAN !
Hi Aqui,
ok..danke erstmal..werde ich zu Hause checken.
VPN geht ja an für sich. Komme auf Rechner etc. .. aber da ich ja kein vlan 1 habe sondern Gi0/1 und was mit dem Virtual Template nicht klappte muss ich nochmal schauen ob alles identisch ist. Mein VT ist VT 3 .
ok..danke erstmal..werde ich zu Hause checken.
VPN geht ja an für sich. Komme auf Rechner etc. .. aber da ich ja kein vlan 1 habe sondern Gi0/1 und was mit dem Virtual Template nicht klappte muss ich nochmal schauen ob alles identisch ist. Mein VT ist VT 3 .
Ist egal ob vlan 1 oder Gi0/1 oder welche Tunnel Nummer solange die Refereinzierung ok ist.
Aber wenn alles geht mit dem VPN und du interne IPs erreichen kannst, dann kann es eigentlich nur die lokale Firewall der HTTP Endgeräte sein !
Aber wenn alles geht mit dem VPN und du interne IPs erreichen kannst, dann kann es eigentlich nur die lokale Firewall der HTTP Endgeräte sein !
Hallo,
ich hab ein wenig mit ipv6 gekämpft und nun die hier:
damit läufts jetzt bei mir endlich...
cya
ich hab ein wenig mit ipv6 gekämpft und nun die hier:
ipv6 unicast-routing
ipv6 cef
ipv6 cef accounting per-prefix
ipv6 dhcp pool DHCPv6
prefix-delegation pool dhcp-ipv6
dns-server "ipv6 von PROVIDER DNS 1"
dns-server "ipv6 von PROVIDER DNS 2"
domain-name xxx.dyndns.org
interface FastEthernet8
description PrimaryWAN
ip address x.x.x.x 255.255.255.0
ip nat outside
ip virtual-reassembly in
zone-member security WAN
duplex auto
speed auto
ipv6 address dhcp
ipv6 address autoconfig default
ipv6 enable
ipv6 nd autoconfig default-route
ipv6 verify unicast reverse-path
ipv6 dhcp client pd hint ::/60
ipv6 dhcp client pd dhcp-ipv6
service-policy output WAN-EDGE-12-CLASS
interface GigabitEthernet0
description LAN
ip address x.x.x.x 255.255.255.0
ip nat inside
ip virtual-reassembly in
zone-member security LAN
duplex auto
speed auto
ipv6 address dhcp-ipv6 ::/64 eui-64
ipv6 address autoconfig
ipv6 enable
ipv6 nd other-config-flag
ipv6 dhcp server DHCPv6damit läufts jetzt bei mir endlich...
cya
Glückwunsch ! 🥳👏👍
Und danke für das Feedback zum Thread hier !
IPv6 DNS IPs der Telekom v6 DNS Server für den Cisco DHCP Server findet man z.B. hier nach Regionen sortiert:
https://www.daniel-weber.eu/2013/06/how-to-ipv6-adressen-der-telekom-dns ...
Auf dem WAN / Internet Port sollte man zwingend noch das Redirect abschalten zur Sicherheit:
no ipv6 redirects
M.E. Ist das Kommando ipv6 address autoconfig auf dem (oder den) lokalen LAN Interfaces falsch !
Das konfiguriert diesen Port in den SLAAC Mode um sich also selber Adressen zu ziehen von einem vorhandenen Router.
Da der Port aber ja eine auch durch den Provider Prefix vorgegebene IP Adresse hat kann das nicht richtig sein.
Dieses Kommando sollte man von den lokalen Interfaces entfernen !
Kosmetik:
Wenn man den "eui-64" Parameter weglässt der eine IPv6 Adresse auf Basis der Mac Adresse erzwingt, kann man in die statische Interface IP auch z.B. die VLAN ID "codiert" reinbringen um diese Adressen dann z.B. an Clients einfacher zuordnen zu können:
ipv6 address provider-v6-prefix ::10:0:0:0:1/64
Bewirkt dann das man eine IP z.B. 2007:AC:81A:4710::1 z.B. am VLAN 10 Interface bekommt und im Netzwerk Teil analog zu IPv4 das "Netz sehen" kann.
Für den der's mag... 😉
Und danke für das Feedback zum Thread hier !
IPv6 DNS IPs der Telekom v6 DNS Server für den Cisco DHCP Server findet man z.B. hier nach Regionen sortiert:
https://www.daniel-weber.eu/2013/06/how-to-ipv6-adressen-der-telekom-dns ...
Auf dem WAN / Internet Port sollte man zwingend noch das Redirect abschalten zur Sicherheit:
no ipv6 redirects
M.E. Ist das Kommando ipv6 address autoconfig auf dem (oder den) lokalen LAN Interfaces falsch !
Das konfiguriert diesen Port in den SLAAC Mode um sich also selber Adressen zu ziehen von einem vorhandenen Router.
Da der Port aber ja eine auch durch den Provider Prefix vorgegebene IP Adresse hat kann das nicht richtig sein.
Dieses Kommando sollte man von den lokalen Interfaces entfernen !
Kosmetik:
Wenn man den "eui-64" Parameter weglässt der eine IPv6 Adresse auf Basis der Mac Adresse erzwingt, kann man in die statische Interface IP auch z.B. die VLAN ID "codiert" reinbringen um diese Adressen dann z.B. an Clients einfacher zuordnen zu können:
ipv6 address provider-v6-prefix ::10:0:0:0:1/64
Bewirkt dann das man eine IP z.B. 2007:AC:81A:4710::1 z.B. am VLAN 10 Interface bekommt und im Netzwerk Teil analog zu IPv4 das "Netz sehen" kann.
Für den der's mag... 😉
Hi aqui,
ich bin nach deiner Anleitung vorgegangen, allerdings habe ich folgendes Problem:
Sofern der Anbieter die Zwangstrennung durchführt oder die DSL-Leitung weg ist und ich eine neue IP beziehen sollte, habe ich keine Verbindung ins Internet. -----> da hilft nur ein Reboot, danach läuft alles prima!
Unter "sh ip int brief" konnte ich auch sehen, dass das Dialer Interface die IP-Adresse mit der neuen nicht überschreibt.
Ich vermute den Fehler in meiner ZFW, ich habe die policy-map RouterZuInternet nicht konfiguriert, da ich keine VPN-Einwahl an diesem Anschluss betreibe. Du hast aber in der class-map type inspect match-any Router_Protocols ---> macht protocol icmp.
Sollte ich meine ZFW um die Konfiguration erweitern und er würde dann die IP-Adresse am Dialer-Interface überschreiben?
Oder ist das nicht der Fehler?
Grüße
higgs
ich bin nach deiner Anleitung vorgegangen, allerdings habe ich folgendes Problem:
Sofern der Anbieter die Zwangstrennung durchführt oder die DSL-Leitung weg ist und ich eine neue IP beziehen sollte, habe ich keine Verbindung ins Internet. -----> da hilft nur ein Reboot, danach läuft alles prima!
Unter "sh ip int brief" konnte ich auch sehen, dass das Dialer Interface die IP-Adresse mit der neuen nicht überschreibt.
Ich vermute den Fehler in meiner ZFW, ich habe die policy-map RouterZuInternet nicht konfiguriert, da ich keine VPN-Einwahl an diesem Anschluss betreibe. Du hast aber in der class-map type inspect match-any Router_Protocols ---> macht protocol icmp.
Sollte ich meine ZFW um die Konfiguration erweitern und er würde dann die IP-Adresse am Dialer-Interface überschreiben?
Oder ist das nicht der Fehler?
Grüße
higgs
Kannst du das reproduzieren indem du die DSL Leitung mal abziehst und wieder aufsteckst ?
Was passiert wenn du mal statt eines langwierigen Reboots einfach ein shut und no shut auf dem Dialer machst oder ein clear controller vdsl0 ?? Kommt der Link dann selber wieder hoch ?
Es könnte auch daran liegen das der DSLAM des Providers ein Problem hat und das Handshaking nicht sauber durchführt.
Die Modem Firmware ist auf dem aktuellen Stand ??
Wenn du es so nicht fixen kannst, kannst du über ein IOS Script jede Nacht oder alle 2 Tage den Dialer retriggern lassen. Ist zwar umstanändlich fixt aber das Problem.
Was passiert wenn du mal statt eines langwierigen Reboots einfach ein shut und no shut auf dem Dialer machst oder ein clear controller vdsl0 ?? Kommt der Link dann selber wieder hoch ?
Es könnte auch daran liegen das der DSLAM des Providers ein Problem hat und das Handshaking nicht sauber durchführt.
Die Modem Firmware ist auf dem aktuellen Stand ??
Wenn du es so nicht fixen kannst, kannst du über ein IOS Script jede Nacht oder alle 2 Tage den Dialer retriggern lassen. Ist zwar umstanändlich fixt aber das Problem.
Ja, ich kann das ganze reproduzieren. Passiert das selbe....keine Internet Verbindung, da das Dialer Interface 0 seine neu zugewiesene IP-Adresse am Interface nicht übernimmt.
ein clear controller vdsl 0 bringt leider nichts, nur ein shut und no shut auf dem Dialer.
Ich glaube nicht das es am DSLAM des Providers liegt, habe das Problem an 3 Ciscos die an verschiedene Lokationen im Einsatz sind.
Modem Firware ist auf dem aktuellen Stand.
hier ein Auszug aus der Konfiguration:
!
controller VDSL 0
operating mode vdsl2
firmware filename flash:VA_B_38V_d24m.bin
modem disableV43
description * VDSL Controller *
!
interface Ethernet0
no ip address
no keepalive
!
interface Ethernet0.7
description VDSL Internet Verbindung - VLAN 7 tagged
encapsulation dot1Q 7
pppoe enable group global
pppoe-client dial-pool-number 1
!
interface Dialer0
description DSL Einwahl Interface
mtu 1492
ip address negotiated
no ip redirects
no ip unreachables
no ip proxy-arp
ip nat outside
ip virtual-reassembly in
zone-member security Internet
encapsulation ppp
dialer pool 1
dialer-group 1
no cdp enable
no keepalive
ppp authentication chap callin
ppp pap sent-username username@t-online.de password password
ppp ipcp mask request
ppp ipcp route default
ein clear controller vdsl 0 bringt leider nichts, nur ein shut und no shut auf dem Dialer.
Ich glaube nicht das es am DSLAM des Providers liegt, habe das Problem an 3 Ciscos die an verschiedene Lokationen im Einsatz sind.
Modem Firware ist auf dem aktuellen Stand.
hier ein Auszug aus der Konfiguration:
!
controller VDSL 0
operating mode vdsl2
firmware filename flash:VA_B_38V_d24m.bin
modem disableV43
description * VDSL Controller *
!
interface Ethernet0
no ip address
no keepalive
!
interface Ethernet0.7
description VDSL Internet Verbindung - VLAN 7 tagged
encapsulation dot1Q 7
pppoe enable group global
pppoe-client dial-pool-number 1
!
interface Dialer0
description DSL Einwahl Interface
mtu 1492
ip address negotiated
no ip redirects
no ip unreachables
no ip proxy-arp
ip nat outside
ip virtual-reassembly in
zone-member security Internet
encapsulation ppp
dialer pool 1
dialer-group 1
no cdp enable
no keepalive
ppp authentication chap callin
ppp pap sent-username username@t-online.de password password
ppp ipcp mask request
ppp ipcp route default
Konfig ist hier identisch, allerdings ohne operating mode vdsl2 und modem disableV43. Das ist auch nicht unbedingt erforderlich, da der Autonegotiation Prozess des Modems das immer automatisch discovered mit der Gegenstelle.
Damit keinerlei Probleme bei der Zwangstrennung auftreten muss das Dialer Interface einen Keepalive konfiguriert haben!! keepalive 30 ist der Default und muss man so belassen, ansonsten kommt die PPPoE Session nach einer Provider Zwangstrennung nicht mehr automatisch hoch!
Wenn auch das partout nicht hilft, dann kannst du deinen Dialer täglich automatisiert resetten mit:
Das sollte das Problem dann final lösen, muss aber mit dem aktiven Keepalive normalerweise nicht sein.
Damit keinerlei Probleme bei der Zwangstrennung auftreten muss das Dialer Interface einen Keepalive konfiguriert haben!! keepalive 30 ist der Default und muss man so belassen, ansonsten kommt die PPPoE Session nach einer Provider Zwangstrennung nicht mehr automatisch hoch!
Wenn auch das partout nicht hilft, dann kannst du deinen Dialer täglich automatisiert resetten mit:
!
kron occurrence shut at 5:00 recurring
policy-list restart_pppoe
!
kron policy-list restart_pppoe
cli clear int dialer0
!
Hey @aqui,
in dem von dir verlinkten Beitrag zum 1921er wurde von dir folgender Link geteilt: pfSense: IPv6 Delegation hinter Fritz!Box
Dort wird ja ein per DHCPv6-PD delegierter Prefix weitergereicht.
Ich hatte den Eindruck das die 1921er Konfig das auch machen soll, jedoch wurde ich in dem Thread nicht fündig wie das gehen soll.
Auch in anderen Foren wie hier: How to break apart an IPv6 /56 6rd delegated prefix from ISP into multiple /64 VLANs for use with SLAAC EUI-64? [Cisco]
wurde solch eine Frage gestellt, leider aber keine Antwort gegeben.
Scheinbar ist eine FritzBox ja in der Lage einen Prefix weiter zu spliten und weiter zu delegieren.
Bei IOS scheitert es aber irgendwie immer daran das ja ein "ipv6 local pool" benötigt wird und dort kein "general-prefix" eingetragen werden kann.
Weißt du wie ein solches Szenario unter IOS realisierbar ist?
Ein solches wie in den beiden obigen Links.
Dankö sehr!
Zitat von @aqui:
Hier findest du eine laufende Dual Stack Konfig die das macht:
Cisco 1921 VOIP und Telefonanlage ISP MNET
Die Mnet Konfig da kannst du identsch übernehmen !
Das o.a. Tutorial wird in Kürze auf die IPv6 Dual Stack Version upgedatet.
Hier findest du eine laufende Dual Stack Konfig die das macht:
Cisco 1921 VOIP und Telefonanlage ISP MNET
Die Mnet Konfig da kannst du identsch übernehmen !
Das o.a. Tutorial wird in Kürze auf die IPv6 Dual Stack Version upgedatet.
in dem von dir verlinkten Beitrag zum 1921er wurde von dir folgender Link geteilt: pfSense: IPv6 Delegation hinter Fritz!Box
Dort wird ja ein per DHCPv6-PD delegierter Prefix weitergereicht.
Ich hatte den Eindruck das die 1921er Konfig das auch machen soll, jedoch wurde ich in dem Thread nicht fündig wie das gehen soll.
Auch in anderen Foren wie hier: How to break apart an IPv6 /56 6rd delegated prefix from ISP into multiple /64 VLANs for use with SLAAC EUI-64? [Cisco]
wurde solch eine Frage gestellt, leider aber keine Antwort gegeben.
Scheinbar ist eine FritzBox ja in der Lage einen Prefix weiter zu spliten und weiter zu delegieren.
Bei IOS scheitert es aber irgendwie immer daran das ja ein "ipv6 local pool" benötigt wird und dort kein "general-prefix" eingetragen werden kann.
Weißt du wie ein solches Szenario unter IOS realisierbar ist?
Ein solches wie in den beiden obigen Links.
Dankö sehr!
Hi The...
Das kann der Cisco natürlich auch. Über den v6 Pool vergibt er das per PD auch weiter. Siehe:
IPv6 Prefixes im lokalen LAN per PD weiterreichen
Eins habe ich allerdings noch nicht hinbekommen und auch keinerlei Doku dazu in den Handbüchern und Best Practise v6 Guides gefunden:
Wenn man vom Provider den PD Pool bekommen hat kann man den entsprechend einrichten und so eigene PDs weiterreichen.
Der Pool ist aber rein statisch. Passiert eine Zwangstrennung und bekommt man vom Provider per PD einen neuen Prefix zugeteilt, ändert das leider nicht dynamisch den Pool den der Cisco dann von sich aus per PD weitergibt. Man muss diesen erst wieder manuell anpassen, was natürlich langfristig so nicht managebar ist.
Vermutlich sieht Cisco hier keine zyklische dynamische PD Änderung vor wie es bei den einfachen Consumer Accounts seitens der Provider üblich ist.
Deshalb laufen auch Antworten in den o.a. Foren vermutlich ins Leere weil es derzeit wohl schlicht und einfach im IOS Image nicht supportet ist. Eigentlich recht ungewöhnlich, liegt aber vermutlich daran das Cisco eher Business orientierter ist als Consumer Massenmarkt. Firmen mit statischer eigener v6 Adressierung haben logischerweise auch keine dynamischen Prefixe wenn sie mit PD arbeiten.
Ob das ggf. ein Feature aktueller Firmware Trains ist kann ich nicht sagen. Müsste man checken oder mal einen Case im Cisco TAC eröffnen. Mit der 15.6.3 (und dadrunter) scheint es nur statische Pools zu geben.
Falls jemand hier im Forum nähere Infos oder ggf. eine Lösung dafür hat wäre das interessant zu wissen !
Das kann der Cisco natürlich auch. Über den v6 Pool vergibt er das per PD auch weiter. Siehe:
IPv6 Prefixes im lokalen LAN per PD weiterreichen
Eins habe ich allerdings noch nicht hinbekommen und auch keinerlei Doku dazu in den Handbüchern und Best Practise v6 Guides gefunden:
Wenn man vom Provider den PD Pool bekommen hat kann man den entsprechend einrichten und so eigene PDs weiterreichen.
Der Pool ist aber rein statisch. Passiert eine Zwangstrennung und bekommt man vom Provider per PD einen neuen Prefix zugeteilt, ändert das leider nicht dynamisch den Pool den der Cisco dann von sich aus per PD weitergibt. Man muss diesen erst wieder manuell anpassen, was natürlich langfristig so nicht managebar ist.
Vermutlich sieht Cisco hier keine zyklische dynamische PD Änderung vor wie es bei den einfachen Consumer Accounts seitens der Provider üblich ist.
Deshalb laufen auch Antworten in den o.a. Foren vermutlich ins Leere weil es derzeit wohl schlicht und einfach im IOS Image nicht supportet ist. Eigentlich recht ungewöhnlich, liegt aber vermutlich daran das Cisco eher Business orientierter ist als Consumer Massenmarkt. Firmen mit statischer eigener v6 Adressierung haben logischerweise auch keine dynamischen Prefixe wenn sie mit PD arbeiten.
Ob das ggf. ein Feature aktueller Firmware Trains ist kann ich nicht sagen. Müsste man checken oder mal einen Case im Cisco TAC eröffnen. Mit der 15.6.3 (und dadrunter) scheint es nur statische Pools zu geben.
Falls jemand hier im Forum nähere Infos oder ggf. eine Lösung dafür hat wäre das interessant zu wissen !
Hey @aqui,
ja, genau das wollte ich wissen.
Oben in deinem verlinkten Part zur v6 Aktivierung hast du das ja eben statisch gemacht, was mich gewundert hat, eben weil ja die dynamik nicht enthalten ist. ;)
Danke dir und ein schönes Wochenende!
ja, genau das wollte ich wissen.
Oben in deinem verlinkten Part zur v6 Aktivierung hast du das ja eben statisch gemacht, was mich gewundert hat, eben weil ja die dynamik nicht enthalten ist. ;)
Danke dir und ein schönes Wochenende!
Hey aqui,
ist es eigentlich möglich mit der ZFW-Konfiguration als Source bzw Destination nicht nur Zonen anzugeben, sondern Hosts?
Z.B. inspect das Protokoll DNS von den Hosts 192.168.1.2, 192.168.1.3 und 192.168.1.4 zu Host 172.168.1.1 (z.B. lokaler DNS-Server)
Ich möchte so bestimmte Hosts auf bestimmte Dienste in der anderen Zone (Host) zugreifen lassen, ohne dass das komplette Netz auf die andere Zone zugreifen darf....
Hoffentlich ist es verständlich was ich meine/vorhabe.
Grüße
Higgs
ist es eigentlich möglich mit der ZFW-Konfiguration als Source bzw Destination nicht nur Zonen anzugeben, sondern Hosts?
Z.B. inspect das Protokoll DNS von den Hosts 192.168.1.2, 192.168.1.3 und 192.168.1.4 zu Host 172.168.1.1 (z.B. lokaler DNS-Server)
Ich möchte so bestimmte Hosts auf bestimmte Dienste in der anderen Zone (Host) zugreifen lassen, ohne dass das komplette Netz auf die andere Zone zugreifen darf....
Hoffentlich ist es verständlich was ich meine/vorhabe.
Grüße
Higgs
nicht nur Zonen anzugeben, sondern Hosts?
Ja, das geht natürlich.Die definierst du in einer ACL und bindest diese ACL dann in die ZFW Policy ein. Siehe oben beim Beispiel mit den IPsec VPN Ports inbound am WAN Port.
1
Hey aqui,
ich hatte nun "mal" Zeit, das Problem "kein I-net nach Zwangstrennung" zu untersuchen. Nach einer Zwangstrennung ist mir aufgefallen, dass mein Dialer0 nicht down bzw wieder up geht, sodass er die neue IP vom Provider am Interface Dialer0 nicht überschreibt.
Es hilft nur clear int dialer 0, danach überschreibt er die IP am Interface.
Das Problem versuche ich nun mit einem kron zu lösen, mal sehen ob es klappt.
kron occurrence clear-dialer at 02:00 recurring
policy-list clear-dialer
!
kron policy-list clear-dialer
cli clear int dialer 0
Grüße
Higgs
Zitat von @aqui:
Konfig ist hier identisch, allerdings ohne operating mode vdsl2 und modem disableV43. Das ist auch nicht erforderlich, da der Autonegotiation Prozess des Modems das automatisch discovered.
Damit keinerlei Probleme bei der Zwangstrennung.
Wenn auch das partout nicht hilft, dann kannst du deinen Dialer täglich automatisiert resetten mit: !
kron occurrence shut at 5:00 recurring
policy-list restart_pppoe
!
kron policy-list restart_pppoe
cli clear int dialer0
!
Das sollte das Problem dann final lösen.
Konfig ist hier identisch, allerdings ohne operating mode vdsl2 und modem disableV43. Das ist auch nicht erforderlich, da der Autonegotiation Prozess des Modems das automatisch discovered.
Damit keinerlei Probleme bei der Zwangstrennung.
Wenn auch das partout nicht hilft, dann kannst du deinen Dialer täglich automatisiert resetten mit: !
kron occurrence shut at 5:00 recurring
policy-list restart_pppoe
!
kron policy-list restart_pppoe
cli clear int dialer0
!
Das sollte das Problem dann final lösen.
ich hatte nun "mal" Zeit, das Problem "kein I-net nach Zwangstrennung" zu untersuchen. Nach einer Zwangstrennung ist mir aufgefallen, dass mein Dialer0 nicht down bzw wieder up geht, sodass er die neue IP vom Provider am Interface Dialer0 nicht überschreibt.
Es hilft nur clear int dialer 0, danach überschreibt er die IP am Interface.
Das Problem versuche ich nun mit einem kron zu lösen, mal sehen ob es klappt.
kron occurrence clear-dialer at 02:00 recurring
policy-list clear-dialer
!
kron policy-list clear-dialer
cli clear int dialer 0
Grüße
Higgs
1
Jepp, das ist auch der richtige Weg und sollte so klappen.
Knackpunkt ist aber das no keepalive. Das MUSS entfernt werden! Ist das geschehen klappt es auch ohne cron fehlerlos. Tutorial ist diesbezgl. korrigiert!
Knackpunkt ist aber das no keepalive. Das MUSS entfernt werden! Ist das geschehen klappt es auch ohne cron fehlerlos. Tutorial ist diesbezgl. korrigiert!
Hallo zusammen,
kann mir jemand eventuell einen Hinweis geben, was an meiner Konfiguration nicht in Ordnung ist?
Ich bastle nun schon seit Ewigkeiten an diesem Projekt herum und allmählich verzweifele ich daran.
Momentaner Stand ist folgender:
Wenn ich den Mediareceiver einschalte läuft die Fortschrittsanzeige bis 82 Prozent und bleibt einen Moment stehen. Anschließend kommt die Meldung "Verbindung zur TV Plattform wird hergestellt..." und ein 60sek Countdown. Nach dem Countdown rebootet der Receiver.
Wenn ich den Mediareceiver an meinen Speedport Router anschließe und einschalte, hochfahren lasse und dann im laufenden Fernsehprogramm auf meinen Cisco Router wechsele, läuft das Fernsehprogramm zunächst einige Minuten weiter, sobald der Cisco Router die DSL Verbindung wieder aufgebaut hat. Wechseln auf einen anderen Kanal ist noch möglich. Nach ein paar Minuten kommt dann allerdings auch die Meldung "Verbindung zur TV Plattform wird hergestellt..." mit anschließendem Reboot.
Am PC kann ich die Streams problemlos über den VLC Player abspielen. Ich habe verschiedene Streams ausprobiert.
Ich habe mir mit Wireshark den Traffic zwischen Router und Mediareceiver angeschaut. Ich konnte kein Problem entdecken. Einzige Auffälligkeit war, das ein bestimmter Telekom Hostname extrem häufig aufgelöst wird und immer dieselbe IP Adresse herauskommt und zwar die Adresse die ich auf dem Router als rp-address eingetragen habe.
Zum Setup:
Ich nutze einen Cisco 2951 Router mit ipbasek9 Lizenz.
Der Receiver ist an einer 4er ehwic Karte im VLAN 1 angeschlossen
Meine Konfiguration:
show ip interface brief
show ppp all
debug ip igmp
show ip igmp interface vlan 1
sh ip pim neighbor
kann mir jemand eventuell einen Hinweis geben, was an meiner Konfiguration nicht in Ordnung ist?
Ich bastle nun schon seit Ewigkeiten an diesem Projekt herum und allmählich verzweifele ich daran.
Momentaner Stand ist folgender:
Wenn ich den Mediareceiver einschalte läuft die Fortschrittsanzeige bis 82 Prozent und bleibt einen Moment stehen. Anschließend kommt die Meldung "Verbindung zur TV Plattform wird hergestellt..." und ein 60sek Countdown. Nach dem Countdown rebootet der Receiver.
Wenn ich den Mediareceiver an meinen Speedport Router anschließe und einschalte, hochfahren lasse und dann im laufenden Fernsehprogramm auf meinen Cisco Router wechsele, läuft das Fernsehprogramm zunächst einige Minuten weiter, sobald der Cisco Router die DSL Verbindung wieder aufgebaut hat. Wechseln auf einen anderen Kanal ist noch möglich. Nach ein paar Minuten kommt dann allerdings auch die Meldung "Verbindung zur TV Plattform wird hergestellt..." mit anschließendem Reboot.
Am PC kann ich die Streams problemlos über den VLC Player abspielen. Ich habe verschiedene Streams ausprobiert.
Ich habe mir mit Wireshark den Traffic zwischen Router und Mediareceiver angeschaut. Ich konnte kein Problem entdecken. Einzige Auffälligkeit war, das ein bestimmter Telekom Hostname extrem häufig aufgelöst wird und immer dieselbe IP Adresse herauskommt und zwar die Adresse die ich auf dem Router als rp-address eingetragen habe.
Zum Setup:
Ich nutze einen Cisco 2951 Router mit ipbasek9 Lizenz.
Der Receiver ist an einer 4er ehwic Karte im VLAN 1 angeschlossen
Meine Konfiguration:
no ip source-route
no ip gratuitous-arps
!
ip dhcp binding cleanup interval 600
ip dhcp bootp ignore
ip dhcp excluded-address 192.168.2.1
ip dhcp excluded-address 192.168.2.100
!
ip dhcp pool 192.168.2.0/24
network 192.168.2.0 255.255.255.0
default-router 192.168.2.1
domain-name *****
dns-server 217.237.151.205 217.237.148.70
!
no ip bootp server
ip domain name *****
ip multicast-routing
ip cef
no ipv6 cef
!
multilink bundle-name authenticated
!
redundancy
!
!
controller VDSL 0/0/0
firmware filename flash0:VA_A_39m_B_38u_24o_rc1_SDK_4.14L.04A-J.bin
!
bridge irb
!
interface Embedded-Service-Engine0/0
no ip address
shutdown
!
interface GigabitEthernet0/0
ip address 192.168.3.10 255.255.255.0
duplex auto
speed auto
!
interface GigabitEthernet0/1
no ip address
duplex auto
speed auto
!
interface GigabitEthernet0/2
no ip address
duplex auto
speed auto
!
interface ATM0/0/0
no ip address
shutdown
no atm ilmi-keepalive
!
interface ATM0/0/0.7 point-to-point
pvc 1/32
bridge-dot1q encap 7
pppoe-client dial-pool-number 1
!
!
interface Ethernet0/0/0
no ip address
!
interface Ethernet0/0/0.7
encapsulation dot1Q 7
pppoe enable group global
pppoe-client dial-pool-number 1
!
interface Ethernet0/0/0.8
encapsulation dot1Q 8
ip dhcp client broadcast-flag clear
ip address dhcp
ip pim sparse-mode
ip igmp version 3
ip igmp query-interval 15
ip igmp proxy-service
!
interface GigabitEthernet0/1/0
switchport mode access
switchport nonegotiate
no ip address
!
interface GigabitEthernet0/1/1
switchport mode access
switchport nonegotiate
no ip address
!
interface GigabitEthernet0/1/2
switchport mode access
switchport nonegotiate
no ip address
!
interface GigabitEthernet0/1/3
switchport mode access
switchport nonegotiate
no ip address
!
interface Vlan1
ip address 192.168.2.1 255.255.255.0
ip pim sparse-mode
ip nat inside
ip virtual-reassembly in
ip igmp helper-address 62.155.244.207
ip igmp version 3
ip igmp explicit-tracking
ip igmp query-interval 15
ip igmp proxy-service
!
interface Dialer0
mtu 1492
ip address negotiated
no ip redirects
no ip proxy-arp
ip mtu 1488
ip pim sparse-mode
ip nat outside
ip virtual-reassembly in
encapsulation ppp
ip igmp version 3
ip igmp proxy-service
dialer pool 1
dialer-group 1
no cdp enable
ppp authentication pap callin
ppp pap sent-username ********@t-online.de password 7 *******
ppp ipcp dns request
ppp ipcp mask request
ppp ipcp route default
!
ip forward-protocol nd
!
ip dns server
ip pim rp-address 62.155.244.207
ip pim ssm default
ip nat inside source list 101 interface Dialer0 overload
!
ip access-list extended PUBLIC-VDSL
deny ip any any log
permit udp host 195.145.119.188 eq ntp any
permit igmp host 62.155.244.207 any
permit icmp host 62.155.244.207 any
permit ip any 224.0.0.0 15.255.255.255
permit udp any gt 40000 any
!
dialer-list 1 protocol ip list 101
!
access-list 22 permit 192.168.2.0 0.0.0.255
access-list 22 permit 192.168.3.0 0.0.0.255
access-list 101 permit ip 192.168.3.0 0.0.0.255 any
access-list 101 permit ip 192.168.2.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 deny ip any any
!show ip interface brief
Interface IP-Address OK? Method Status Protocol
Embedded-Service-Engine0/0 unassigned YES NVRAM administratively down down
GigabitEthernet0/0 192.168.3.10 YES NVRAM up up
GigabitEthernet0/1 unassigned YES NVRAM down down
GigabitEthernet0/2 unassigned YES NVRAM down down
ATM0/0/0 unassigned YES NVRAM administratively down down
ATM0/0/0.7 unassigned YES unset administratively down down
Ethernet0/0/0 unassigned YES NVRAM up up
Ethernet0/0/0.7 unassigned YES unset up up
Ethernet0/0/0.8 unassigned YES DHCP up up
GigabitEthernet0/1/0 unassigned YES unset up up
GigabitEthernet0/1/1 unassigned YES unset down down
GigabitEthernet0/1/2 unassigned YES unset down down
GigabitEthernet0/1/3 unassigned YES unset down down
Dialer0 87.***.**.250 YES IPCP up up
NVI0 192.168.3.10 YES unset up up
Tunnel0 87.***.**.250 YES unset up up
Virtual-Access1 unassigned YES unset up up
Virtual-Access2 unassigned YES unset up up
Vlan1 192.168.2.1 YES NVRAM up up show ppp all
Interface/ID OPEN+ Nego* Fail- Stage Peer Address Peer Name
------------ --------------------- -------- --------------- --------------------
Vi2 LCP+ IPCP+ LocalT 62.155.244.207 debug ip igmp
Feb 16 16:17:02.819: IGMP(0): Received Leave from 192.168.2.5 (Vlan1) for 239.255.255.250
Feb 16 16:17:02.819: IGMP(0): Received Group record for group 239.255.255.250, mode 3 from 192.168.2.5 for 0 sources
Feb 16 16:17:02.819: IGMP(0): Lower expiration timer to 2000 msec for 239.255.255.250 on Vlan1
Feb 16 16:17:02.819: IGMP(0): Send v3 Query on Vlan1 for group 239.255.255.250
Feb 16 16:17:02.819: IGMP(0): Received Group 239.255.255.250 Query for 0 sources
Feb 16 16:17:02.819: IGMP(0): Helper Leave for group 239.255.255.250 out Dialer0
Feb 16 16:17:03.903: IGMP(0): Send v3 Query on Vlan1 for group 239.255.255.250
Feb 16 16:17:03.903: IGMP(0): Received Group 239.255.255.250 Query for 0 sources
Feb 16 16:17:04.903: IGMP(0): Switching to INCLUDE mode for 239.255.255.250 on Vlan1
Feb 16 16:17:04.903: IGMP_ET(0): host 192.168.2.5 report for 239.255.255.250 (0 srcs) on Vlan1
Feb 16 16:17:04.903: IGMP_ET(0): host 192.168.2.5 switch to include for 239.255.255.250 on Vlan1
Feb 16 16:17:04.903: IGMP(0): MRT delete Vlan1 for (*,239.255.255.250) by 1
Feb 16 16:17:04.903: IGMP_ET(0): Deleting Host 192.168.2.5 from 239.255.255.250 on Vlan1
Feb 16 16:17:07.815: IGMP(0): Send v3 general Query on Vlan1
Feb 16 16:17:07.815: IGMP(0): Set report delay to 2.0 seconds to respond to General Query on Vlan1
Feb 16 16:17:08.767: IGMP(0): Send v3 general Query on Ethernet0/0/0.8
Feb 16 16:17:09.903: IGMP(0): Building v3 Report on Vlan1
Feb 16 16:17:09.903: IGMP(0): Add Group Record for 224.0.1.40, type 2
Feb 16 16:17:09.903: IGMP(0): Send v3 Report with 1 group records on Vlan1
Feb 16 16:17:09.903: IGMP(0): Received v3 Report for 1 group on Vlan1 from 192.168.2.1
Feb 16 16:17:09.903: IGMP(0): Received Group record for group 224.0.1.40, mode 2 from 192.168.2.1 for 0 sources
Feb 16 16:17:09.903: IGMP(0): Updating EXCLUDE group timer for 224.0.1.40
Feb 16 16:17:09.903: IGMP_ET(0): host 192.168.2.1 report for 224.0.1.40 (0 srcs) on Vlan1
Feb 16 16:17:09.903: IGMP(0): MRT Add/Update Vlan1 for (*,224.0.1.40) by 1
Feb 16 16:17:09.903: IGMP(0): Helper v3 Report out Dialer0
Feb 16 16:17:11.395: IGMP(0): Received v3 Report for 1 group on Vlan1 from 192.168.2.5
Feb 16 16:17:11.395: IGMP(0): Received Group record for group 239.255.255.250, mode 4 from 192.168.2.5 for 0 sources
Feb 16 16:17:11.395: IGMP(0): WAVL Insert group: 239.255.255.250 interface: Vlan1Successful
Feb 16 16:17:11.395: IGMP(0): Switching to EXCLUDE mode for 239.255.255.250 on Vlan1
Feb 16 16:17:11.395: IGMP(0): Updating EXCLUDE group timer for 239.255.255.250
Feb 16 16:17:11.395: IGMP_ET(0): Adding Host 192.168.2.5 for 239.255.255.250 on Vlan1
Feb 16 16:17:11.395: IGMP_ET(0): host 192.168.2.5 report for 239.255.255.250 (0 srcs) on Vlan1
Feb 16 16:17:11.395: IGMP_ET(0): host 192.168.2.5 switch to exclude for 239.255.255.250 on Vlan1
Feb 16 16:17:11.395: IGMP(0): MRT Add/Update Vlan1 for (*,239.255.255.250) by 1
Feb 16 16:17:11.395: IGMP(0): Helper v3 Report out Dialer0
Feb 16 16:17:20.647: IGMP(0): Received v3 Report for 1 group on Vlan1 from 192.168.2.5
Feb 16 16:17:20.647: IGMP(0): Received Group record for group 239.255.255.250, mode 4 from 192.168.2.5 for 0 sources
Feb 16 16:17:20.647: IGMP(0): Updating EXCLUDE group timer for 239.255.255.250
Feb 16 16:17:20.647: IGMP_ET(0): host 192.168.2.5 report for 239.255.255.250 (0 srcs) on Vlan1
Feb 16 16:17:20.647: IGMP(0): MRT Add/Update Vlan1 for (*,239.255.255.250) by 1
Feb 16 16:17:20.647: IGMP(0): Helper v3 Report out Dialer0show ip igmp interface vlan 1
Vlan1 is up, line protocol is up
Internet address is 192.168.2.1/24
IGMP is enabled on interface
Current IGMP host version is 3
Current IGMP router version is 3
Explicit Tracking is enabled
IGMP query interval is 15 seconds
IGMP configured query interval is 15 seconds
IGMP querier timeout is 30 seconds
IGMP configured querier timeout is 30 seconds
IGMP max query response time is 10 seconds
Last member query count is 2
Last member query response interval is 1000 ms
Inbound IGMP access group is not set
IGMP activity: 16 joins, 14 leaves
Multicast routing is enabled on interface
Multicast TTL threshold is 0
Multicast designated router (DR) is 192.168.2.1 (this system)
IGMP querying router is 192.168.2.1 (this system)
IGMP helper address is 62.155.244.207
Multicast groups joined by this system (number of users):
224.0.1.40(1)sh ip pim neighbor
PIM Neighbor Table
Mode: B - Bidir Capable, DR - Designated Router, N - Default DR Priority,
P - Proxy Capable, S - State Refresh Capable, G - GenID Capable,
L - DR Load-balancing Capable
Neighbor Interface Uptime/Expires Ver DR
Address Prio/Mode
62.155.244.207 Dialer0 02:32:58/now v2 0 /
Ich habe genau das gleiche Verhalten hier mit einem alten 400er Receiver. Habe leider keinen neuen.
Ich hatte das auf ein fehlendes SW Update geschoben denn seit 10.01.2020 ist die Entertain Platform komplett abgeschaltet worden und die 400er können das nur mir aktueller Firmware. Was er sich aber dann über den SP ja bei dir gezogen hat. (Hab kein SP zum Testen, leider)
Was auffällt ist das das Update per TFTP passiert. Ich vermute das das irgendwie in der Firewall hängenbleibt. Leider schreibst du nicht ob du die CBAC oder ZFW benutzt?
Hast du mal versucht die FW temporär komplett zu deaktivieren und das dann zu versuchen ?
Man müsste sich das mal ganz genau mit dem Wireshark ansehen wie die Kommunikation des Players mit dem SP und mit dem Cisco aussieht. Irgendwo muss da de facto ein Unterschied sein und etwas hängenbleiben.
Wie gesagt hier genau gleich betrifft aber einzig nur den alten 400er Media Receiver. Kodi VLC und Co. spielen das fehlerfrei ab.
Ich musste hier übrigens zwingend den proxy-service komplett rausnehmen. Mit dem in der Interface Konfig ging hier gar nichts. Weder VLC noch Kodi. Das ist die aktuelle Konfig die rennt:
Ich meine Proxy darf auch nur auf der LAN Seite aktiv sein..wenn überhaupt. Wäre cool wenn man das lösen kann. Das kann nur ein kleiner Konfig Kincken sein...
Ich hatte das auf ein fehlendes SW Update geschoben denn seit 10.01.2020 ist die Entertain Platform komplett abgeschaltet worden und die 400er können das nur mir aktueller Firmware. Was er sich aber dann über den SP ja bei dir gezogen hat. (Hab kein SP zum Testen, leider)
Was auffällt ist das das Update per TFTP passiert. Ich vermute das das irgendwie in der Firewall hängenbleibt. Leider schreibst du nicht ob du die CBAC oder ZFW benutzt?
Hast du mal versucht die FW temporär komplett zu deaktivieren und das dann zu versuchen ?
Man müsste sich das mal ganz genau mit dem Wireshark ansehen wie die Kommunikation des Players mit dem SP und mit dem Cisco aussieht. Irgendwo muss da de facto ein Unterschied sein und etwas hängenbleiben.
Wie gesagt hier genau gleich betrifft aber einzig nur den alten 400er Media Receiver. Kodi VLC und Co. spielen das fehlerfrei ab.
Ich musste hier übrigens zwingend den proxy-service komplett rausnehmen. Mit dem in der Interface Konfig ging hier gar nichts. Weder VLC noch Kodi. Das ist die aktuelle Konfig die rennt:
interface Vlan1
description Lokales LAN
ip address 192.168.7.254 255.255.255.0
no ip redirects
ip pim sparse-mode
ip nat inside
ip virtual-reassembly in
zone-member security Home
ip tcp adjust-mss 1448
ip igmp helper-address 62.155.244.207
ip igmp version 3
ip igmp explicit-tracking
!Ich meine Proxy darf auch nur auf der LAN Seite aktiv sein..wenn überhaupt. Wäre cool wenn man das lösen kann. Das kann nur ein kleiner Konfig Kincken sein...
Das ist interessant. Den 400er Receiver habe ich tatsächlich auch.
Ich habe aber auch noch einen nagelneuen 401er Typ B herumliegen.
Lieferschein von Mai 2019 und noch nie benutzt, dementsprechend alt ist auch die Firmware.
Meinst du es macht Sinn wenn ich es damit mal versuche?
CBAC oder ZFW nutze ich nicht.
Wenn das Setup endlich läuft, werde ich noch ein paar ACL definieren und den Rest dann über eine nachgelagerte Firewall in 192.168.3.0/24 abbilden.
Ich habe aber auch noch einen nagelneuen 401er Typ B herumliegen.
Lieferschein von Mai 2019 und noch nie benutzt, dementsprechend alt ist auch die Firmware.
Meinst du es macht Sinn wenn ich es damit mal versuche?
CBAC oder ZFW nutze ich nicht.
Wenn das Setup endlich läuft, werde ich noch ein paar ACL definieren und den Rest dann über eine nachgelagerte Firewall in 192.168.3.0/24 abbilden.
Ich habe es gestern nochmal mit dem 401er getestet und bin dabei auf ein neues Mysterium gestoßen.
Der Receiver versucht direkt nach dem Einschalten vergeblich eine Netzwerkverbindung herzustellen, rebootet dann nach einiger Zeit und versucht es anschließend erneut.
Ich habe mir das mal mit Wireshark angeschaut.
Der Receiver versucht kontinuierlich per DHCP eine IP zu beziehen.
Erst geht vom Receiver ein DHCP Discover aus, dann kommt vom Router ein DHCP Offer, dann ein DHCP Request vom Receiver und anschließend ein DHCP NAK vom Router. Danach geht das Spielchen wieder von vorne los.
Im DHCP Request werden die Options 1, 15, 3, 6, 16, 17, 130 und 131 angefordert.
Die Options 130 und 131 sind für eine Herstellerspezifische PXE Lösung reserviert.
Ich denke das hier das Problem liegt. Der Receiver will vermutlich beim ersten Start seine Firmware per PXE beziehen.
Der Receiver versucht direkt nach dem Einschalten vergeblich eine Netzwerkverbindung herzustellen, rebootet dann nach einiger Zeit und versucht es anschließend erneut.
Ich habe mir das mal mit Wireshark angeschaut.
Der Receiver versucht kontinuierlich per DHCP eine IP zu beziehen.
Erst geht vom Receiver ein DHCP Discover aus, dann kommt vom Router ein DHCP Offer, dann ein DHCP Request vom Receiver und anschließend ein DHCP NAK vom Router. Danach geht das Spielchen wieder von vorne los.
Im DHCP Request werden die Options 1, 15, 3, 6, 16, 17, 130 und 131 angefordert.
Die Options 130 und 131 sind für eine Herstellerspezifische PXE Lösung reserviert.
Ich denke das hier das Problem liegt. Der Receiver will vermutlich beim ersten Start seine Firmware per PXE beziehen.
CBAC oder ZFW nutze ich nicht.
Ooops ??! Du hast den Cisco vollkommen ungeschützt im Internet ?? 🤔OK, für den Test ist das erstmal gut und hilfreich, denn das schliesst erstmal andere Fussfallen sicher aus.
Später, sollte es dann klappen, solltest du aber eins von beiden besser aktivieren !
Meinst du es macht Sinn wenn ich es damit mal versuche?
Sollte man immer machen ! Versuch macht bekanntlich klug !!! Der Receiver versucht direkt nach dem Einschalten vergeblich eine Netzwerkverbindung herzustellen,
Das mit den Options war sehr gut !Hier wäre es sehr wertvoll zu wissen WAS er vom Speedport genau für Options zurückbekommt !! Mit dem klappt es ja. Gerade 130 und 131, denn das bestimmt die TFTP BootServer für das Image was er booten muss, da hast du Recht !!
Wenn er schon scheitert eine gültige IP zu bekommen ist klar und erwartbar das der Rest auch nicht klappt.
Kannst du das ggf. mal komplett mitsniffern mit dem funktionierenden SP ?? Der .pcap File dazu wäre mal interessant.
Ich kann mich leider erst am Wochenende wieder damit beschäftigen. Das mit den DHCP Options finde ich auch hochinteressant.
Falls da tatsächlich TFTP passiert, kann man darüber sicherlich den Firmwarestand beeinflussend
Falls da tatsächlich TFTP passiert, kann man darüber sicherlich den Firmwarestand beeinflussend
Ich werde am WE auch parallel mal messen. Irgendwie bringen wir das Teil schon zum Laufen. Es kann ja einzig nur das Booten der Media receiver Firmware sein und sollte mit Multicast an sich nichts zu tun haben wenn das mit VLC sauber funktioniert !
Ich hab mir zwischenzeitlich nochmal den ersten Wireshark Trace mit dem 82 Prozent issue angeschaut. Hier fordert der MR 400 interessanterweise ganz andere DHCP options an.
Wir werde dir die Traces selbstverständlich zukommen lassen.
Kennst du eventuell die Prozedur mit der man die Firmware Neuinstallation auslösen kann? Ich hab das mal vor Jahren zusammen mit der Telekom Hotline gemacht, erinnere mich aber nicht mehr wie das ging.
Wir werde dir die Traces selbstverständlich zukommen lassen.
Kennst du eventuell die Prozedur mit der man die Firmware Neuinstallation auslösen kann? Ich hab das mal vor Jahren zusammen mit der Telekom Hotline gemacht, erinnere mich aber nicht mehr wie das ging.
So, ich hatte nun endlich wieder Zeit um mich damit zu beschäftigen.
Die Erkenntnis mit den DHCP Options hat sich jetzt leider als Sackgasse herausgestellt.
Ich habe den neuen MR401 am Speedport angeschlossen und ein Wireshark Trace über den gesamten ersten Startvorgang inkl. Firmware Installation angefertigt.
Die Firmware wird tatsächlich per TFTP bezogen. Ich kann jedoch nicht erkennen woher der MR die Installationsquelle bezieht.
Die DHCP Options 130 und 131 werden zwar vom MR angefordert, aber entgegen meiner Erwartung nicht vom Speedport bereitgestellt. Schade.
Nach der Installation habe ich den MR401 vom Speedport getrennt und wieder über den Cisco Router angeschlossen und es hat auf Anhieb funktioniert. Ich habe keine Idee weshalb es mit dem MR401 funktioniert und mit dem MR400 nicht. Ich hatte eigentlich vermutet das nur die Hardware refreshed wurde aber die Software bei beiden Modellen identisch ist.
Ich habe dir per PN mal die Wireshark Traces geschickt.
Vielleicht kannst du daraus noch irgendwelche Erkenntnisse ziehen.
Die Erkenntnis mit den DHCP Options hat sich jetzt leider als Sackgasse herausgestellt.
Ich habe den neuen MR401 am Speedport angeschlossen und ein Wireshark Trace über den gesamten ersten Startvorgang inkl. Firmware Installation angefertigt.
Die Firmware wird tatsächlich per TFTP bezogen. Ich kann jedoch nicht erkennen woher der MR die Installationsquelle bezieht.
Die DHCP Options 130 und 131 werden zwar vom MR angefordert, aber entgegen meiner Erwartung nicht vom Speedport bereitgestellt. Schade.
Nach der Installation habe ich den MR401 vom Speedport getrennt und wieder über den Cisco Router angeschlossen und es hat auf Anhieb funktioniert. Ich habe keine Idee weshalb es mit dem MR401 funktioniert und mit dem MR400 nicht. Ich hatte eigentlich vermutet das nur die Hardware refreshed wurde aber die Software bei beiden Modellen identisch ist.
Ich habe dir per PN mal die Wireshark Traces geschickt.
Vielleicht kannst du daraus noch irgendwelche Erkenntnisse ziehen.
Prozedur mit der man die Firmware Neuinstallation auslösen kann?
Zitat aus dem Telekom Forum (was auch so funktioniert) "Receiver am rückseitigen Schalter aus- und wieder einschalten, warten bis die rote Beleuchtung der Ein/Aus-Taste auf weiß wechselt , dann wieder ausschalten.
Das ganze noch drei mal wiederholen und dann eingeschaltet lassen.
Auf dem Display sollte jetzt " INIT " stehen und der Receiver holt sich aus dem Netz die aktuellste Software oder lädt sie neu.
Auf dem Bilschirm des TV steht „Lade Software“
Nun ist etwas Geduld angesagt, bis sich der Receiver wieder mit dem live-TV meldet. "
Ich kann jedoch nicht erkennen woher der MR die Installationsquelle bezieht.
Normal erhält er die TFTP Boot Server Option per DHCP Option. Ansonsten Broadcastet er nach einem TFTP Bootserver was aber natürlich in einem gerouteten Netzwerk fehlschlägt da das nicht über die Routergrenzen geht.Es müsste also irgendwie per DHCP kommen.
Aber interessant ist das es nach dem Update dann auch fest mit dem MR401 am Cisco Router funktioniert !!!
Was ja zeigt das es ganz klar eine Software Funktion ist. Im Zweifel reicht es also den 400er gegen den 401 zu tauschen aber es muss ja auch irgendwie mit dem 400er gehen. Denn das was der SP kann, kann der Cisco natürlich schon lange...
Ggf. wäre es nochmal interessant wenn du die o.a. FW Update Prozedur mit dem MR-400 fährst am Speedport und diese mal komplett mitsnifferst.
Danach wäre es dann mal spannen oder der 400er dann auch im Cisco LAN rennt ?!
Ich checke die Traces mal und schick dir ne PM...
Lieben Gruß,
ich denke ich habe ein Problem welches ich selbst im Augenblick nicht lösen kann. Erstmal vielleicht zur Vorgeschichte. Bis jetzt habe ich meinen Cisco Router 1941 am VDSL 50/10 und später 100/40 betrieben. Dazu auch Magenta TV. Alles lief einwandfrei, ausser die CPU lief oft auf 100%, wie meine Frau es wollte Dann kam die Möglichkeit den Anschluss auf 250/40 abzugraden. Durchgeführt und alles Lief ausser der Perfomance, die Lag bei 70/30 (Speedtest.net oder Speed.io). Gut jetzt brauch ich wohl einen neuen Router. Wie der Zufall so wollte, wurde ein Cisco 4331 mit der Speedoption 300 Mbit frei. Also die Konfiguration angepasst und auch Zone Base Firewall extra dafür geschrieben die ich vorher nicht hatte.
Lief auch auf Anhieb alles gut (Bandbreitentest lieferte auch 255/40 Mbit), das dachte ich zumindest bis meine Frau über TV meckerte. Jeden Tag gab es in der Nacht ausfälle von Magenta TV mit dem MR401. Vorher lief alles prima. Die Programme liefen normal nur das Menu nicht, es gab keine Menu. Man konnte den MR401 auch nicht ausschalten (Standby Modus). Eigene Aufnahmen wurden nicht angezeit sowie alle Menus. Hmm dachte ich mir vielleicht habe ich etwas vergessen oder ich habe etwas in der ZBF übersehen. ZBF ausgemacht aber das Problem war immernoch da. Letzte IOS XE Firmware gezogen und aufgespielt isr4300-universalk9.16.09.05.SPA.bin vorher lief bereits isr4300-universalk9.16.06.06.SPA.bin. Auch das ROMMON geupdatet. Leider ohne Besserung. Doch etwas hat sich geändert und zwar im EPG gab es jetzt Bildvorschau des Programms, vorher fehlte sie auch, einfach leeres Kästchen. Ich denke, dass IOS-XE hier den übertäter spielt. Bei classic IOS wie beim 1941 funktioniert ja alles. Habe jetzt einen Cisco 2921 ausgegraben und reingestellt, damit wieder alles Funktioniert. Der 2921 ist schon mehr performant als der 1941 aber leider liefert er maximal 120/40 Mbit. Mehr ist nicht drin. Vielleicht hat jemand auch schon mit Cisco IOS-XE und IPTV (Magenta TV) Erfahrung gesammelt und kann hier aushelfen. Meine Konfiguration. Hinter einem Draytek 165 ist der Cisco Router direkt angeschlossen. Modem Connectet auch sauber mit 287/48 Mbit. PPPoE Einwahl macht der Cisco Router und der Internetzugang funktioniert sauber.
Gemeinsame Konfig aller meiner Router, nur die Interface auf dem 4331 sind GigabitEthernet0/0/0 und GigabitEthernet0/0/1
Mein MR401 befindet sich im eigenen VLAN. ZBF habe ich hier nicht erwähnt weil auch ohne funktioneren die Menus nicht. Für Hilfe oder Hinweise wäre ich dankbar. Als noch eine Option hätte ich noch einen ASR1001 aber dieser ist viel lauter und hat auch nur IOS-XE on Board.
Liebe Grüße
damian
ich denke ich habe ein Problem welches ich selbst im Augenblick nicht lösen kann. Erstmal vielleicht zur Vorgeschichte. Bis jetzt habe ich meinen Cisco Router 1941 am VDSL 50/10 und später 100/40 betrieben. Dazu auch Magenta TV. Alles lief einwandfrei, ausser die CPU lief oft auf 100%, wie meine Frau es wollte
Dann kam die Möglichkeit den Anschluss auf 250/40 abzugraden. Durchgeführt und alles Lief ausser der Perfomance, die Lag bei 70/30 (Speedtest.net oder Speed.io). Gut jetzt brauch ich wohl einen neuen Router. Wie der Zufall so wollte, wurde ein Cisco 4331 mit der Speedoption 300 Mbit frei. Also die Konfiguration angepasst und auch Zone Base Firewall extra dafür geschrieben die ich vorher nicht hatte.Lief auch auf Anhieb alles gut (Bandbreitentest lieferte auch 255/40 Mbit), das dachte ich zumindest bis meine Frau über TV meckerte. Jeden Tag gab es in der Nacht ausfälle von Magenta TV mit dem MR401. Vorher lief alles prima. Die Programme liefen normal nur das Menu nicht, es gab keine Menu. Man konnte den MR401 auch nicht ausschalten (Standby Modus). Eigene Aufnahmen wurden nicht angezeit sowie alle Menus. Hmm dachte ich mir vielleicht habe ich etwas vergessen oder ich habe etwas in der ZBF übersehen. ZBF ausgemacht aber das Problem war immernoch da. Letzte IOS XE Firmware gezogen und aufgespielt isr4300-universalk9.16.09.05.SPA.bin vorher lief bereits isr4300-universalk9.16.06.06.SPA.bin. Auch das ROMMON geupdatet. Leider ohne Besserung. Doch etwas hat sich geändert und zwar im EPG gab es jetzt Bildvorschau des Programms, vorher fehlte sie auch, einfach leeres Kästchen. Ich denke, dass IOS-XE hier den übertäter spielt. Bei classic IOS wie beim 1941 funktioniert ja alles. Habe jetzt einen Cisco 2921 ausgegraben und reingestellt, damit wieder alles Funktioniert. Der 2921 ist schon mehr performant als der 1941 aber leider liefert er maximal 120/40 Mbit. Mehr ist nicht drin. Vielleicht hat jemand auch schon mit Cisco IOS-XE und IPTV (Magenta TV) Erfahrung gesammelt und kann hier aushelfen. Meine Konfiguration. Hinter einem Draytek 165 ist der Cisco Router direkt angeschlossen. Modem Connectet auch sauber mit 287/48 Mbit. PPPoE Einwahl macht der Cisco Router und der Internetzugang funktioniert sauber.
Gemeinsame Konfig aller meiner Router, nur die Interface auf dem 4331 sind GigabitEthernet0/0/0 und GigabitEthernet0/0/1
interface GigabitEthernet0/0
description VDSL Physical Interface
bandwidth 10000000
ip address 10.255.255.99 255.255.255.0
ip virtual-reassembly in
no ip route-cache
load-interval 30
duplex full
speed 1000
no cdp enable
!
interface GigabitEthernet0/0.7
description VLAN 7 fuer PPPOE
bandwidth 10000000
bandwidth receive 5000000
encapsulation dot1Q 7
ip virtual-reassembly in
no ip route-cache
pppoe enable group global
pppoe-client dial-pool-number 1
no cdp enable
!
interface GigabitEthernet0/0.8
description VLAN 8 fuer IPTV
bandwidth 10000
bandwidth receive 50000
encapsulation dot1Q 8
ip dhcp client broadcast-flag clear
ip address dhcp
ip pim sparse-mode
no ip route-cache
ip igmp version 3
ip igmp query-interval 15
ip igmp proxy-service
no cdp enable
interface GigabitEthernet0/1.8
encapsulation dot1Q 8
ip address 192.168.8.1 255.255.255.0
ip pim sparse-mode
ip nat inside
ip virtual-reassembly in
ip tcp adjust-mss 1452
ip igmp helper-address 62.155.240.104
ip igmp version 3
ip igmp explicit-tracking
ip igmp query-interval 15
ip igmp proxy-service
interface Dialer0
description VDSL Einwahl
mtu 1492
bandwidth 100000
ip address negotiated
no ip redirects
no ip unreachables
no ip proxy-arp
ip nbar protocol-discovery ipv4
ip dns view-group no-dns-proxy
ip pim sparse-mode
ip nat outside
ip inspect firewall out
ip virtual-reassembly in
ip verify unicast reverse-path
encapsulation ppp
ip tcp adjust-mss 1452
ip igmp version 3
ip igmp query-interval 15
ip igmp proxy-service
dialer pool 1
dialer-group 1
no keepalive
ppp authentication chap callin
ppp chap hostname 123456789@t-online.de
ppp chap password XXXXXXX
ppp pap sent-username 123456789@t-online.de password XXXXXXX
ppp ipcp dns request accept
ppp ipcp mask request
ppp ipcp route default
no cdp enableMein MR401 befindet sich im eigenen VLAN. ZBF habe ich hier nicht erwähnt weil auch ohne funktioneren die Menus nicht. Für Hilfe oder Hinweise wäre ich dankbar. Als noch eine Option hätte ich noch einen ASR1001 aber dieser ist viel lauter und hat auch nur IOS-XE on Board.
Liebe Grüße
damian
Hast du Express Forwarding (cef) aktiviert ? Das ist mandatory bei den Speeds !
Der konfigurierte Proxy Service hat bei mir z.B. das IPTV Multicasting ganz zum Erliegen gebracht. Das solltest du mal komplett entfernen. Das bringt auch nix wenn man PIM Routing macht.
Es gab im IOS-XE jede Menge Multicast Bugs in den ersten Releases des Denali und Everest Trains. Es ist also hier durchaus nicht trivial welches Release du einsetzt. Erst die latest Denalis 16.3.x arbeitet hinreichend stabil mit Multicast.
PPP Chap ist übrigens sinnfrei im Dialer, die Telekom arbeitet nur mit PAP Authentisierung. CHAP kannst du entsorgen.
Grober Fehler ist auch das MSS Kommando auf dem Dialer Interface. Hier darf ausschliesslich nur die MTU gesetzt sein. Das MSS Customizing macht man nur auf den LAN Ports. Bedenke auch das die PPPoE Frames ein Tagging beinhalten. Den VLAN Tag musst du von der MTU abziehen (1488)
https://baturin.org/tools/encapcalc/
Passt das nicht besteht die Gefahr das der Router fragmentiert was erheblich zu Lasten der Performance geht !!
Der konfigurierte Proxy Service hat bei mir z.B. das IPTV Multicasting ganz zum Erliegen gebracht. Das solltest du mal komplett entfernen. Das bringt auch nix wenn man PIM Routing macht.
Es gab im IOS-XE jede Menge Multicast Bugs in den ersten Releases des Denali und Everest Trains. Es ist also hier durchaus nicht trivial welches Release du einsetzt. Erst die latest Denalis 16.3.x arbeitet hinreichend stabil mit Multicast.
PPP Chap ist übrigens sinnfrei im Dialer, die Telekom arbeitet nur mit PAP Authentisierung. CHAP kannst du entsorgen.
Grober Fehler ist auch das MSS Kommando auf dem Dialer Interface. Hier darf ausschliesslich nur die MTU gesetzt sein. Das MSS Customizing macht man nur auf den LAN Ports. Bedenke auch das die PPPoE Frames ein Tagging beinhalten. Den VLAN Tag musst du von der MTU abziehen (1488)
https://baturin.org/tools/encapcalc/
Passt das nicht besteht die Gefahr das der Router fragmentiert was erheblich zu Lasten der Performance geht !!
CEF ist aktiv. Habe PAP (war überbleibsel von früher), MSS und den Proxy aus dem Dialer 0 rausgenommen. MTU habe ich jetzt auf 1468 gesetzt und bei einem Win 10 PC ermittelt (dort sind keine VPN Clients installiert, welche die MTU Size auf 1300 stellen) alles höhere wurde fragmentiert. Im Augenblick lauft da Fuji auf dem 4331. Werde noch Amsterdam und die letzte Denali ausprobieren. Habe gestern mit dem 2921 weiter getestet aber ohne Besserung. Mehr als 99/40 Mbit war nicht drin. Upload ist vollkommen ok aber der Download ist mir zu wenig. Hast du vielleicht noch einen Tipp was bei dem 2921 nicht so läuft wie es sein sollte? Er müsste die Bandbreite bringen.
PAP darfst du nicht rausnehmen, denn die Telekom macht ausschliesslich PAP. CHAP kann raus.
Hast du beim 2921 noch eine weitere Eth Schnittstelle ? Wenn ja aktiviere mal CEF dort und mache mal mit IPerf3 einen direkten Test was die Kiste so schaufeln kann. (sh proc cpu beachten)
Dazu solltest du dann aber bitte einen separaten Thread hier aufmachen um hier das hiesige Cisco Tutorial nicht weiter aufzublähen mit Inhalts fremden Themen !
Hier geht es weiter:
Cisco Router 4331 IOS-XE und Magenta TV Probleme
Hast du beim 2921 noch eine weitere Eth Schnittstelle ? Wenn ja aktiviere mal CEF dort und mache mal mit IPerf3 einen direkten Test was die Kiste so schaufeln kann. (sh proc cpu beachten)
Dazu solltest du dann aber bitte einen separaten Thread hier aufmachen um hier das hiesige Cisco Tutorial nicht weiter aufzublähen mit Inhalts fremden Themen !
Hier geht es weiter:
Cisco Router 4331 IOS-XE und Magenta TV Probleme
Kannst du mir eventuell mal zeigen wie du die Firewall Konfiguration bei dir umgesetzt hast? Wenn ich das so mache wie in deiner Anleitung, werden die eingehenden UDP Pakete für IPTV geblockt.
So sieht eine ZFW Firewall mit IPTV aus:
Damit rennt einen VLC oder Kodi Session auf die Magenta TV Kanäle fehlerlos.
Es kann möglich sein das für den Media Receiver Multicast Session von Outbound initiiert werden. Die bleiben dann natürlich an der Firewall hängen.
Alles was von Outbound auf das Dialer Interface zugreifen darf bestimmt letztlich die ISAKMP_IPSEC ACL.
Man könnte dort testweise nochmal permit ip 224.0.0.0 15.255.255.255 any hinzufügen.
Das würde dann alle Multicast Adressen erlauben. Noch einfacher ist es wenn man temporär mal mit no zone-member security LAN bzw. no zone-member security Internet die FW mal temporär zum Testn ganz ausschaltet.
Sollte es dann klappen mit dem Media Receiver kann man sicher sein das die ZFW Firewall dort irgendwas für den Media Receiver wichtiges aus dem IPTV Flow filtert.
!
class-map type inspect match-any IPsec
match access-group name ISAKMP_IPSEC
class-map type inspect match-any LokalAllowed
match protocol http
match protocol https
match protocol pop3s
match protocol imaps
match protocol smtp
match protocol sip-tls
match protocol rtsp
match protocol ftp
match protocol ftps
match protocol ssh
match protocol ntp
match protocol dns
match protocol tftp
match protocol tcp
match protocol udp
match protocol icmp
class-map type inspect match-any RouterProtocols
match class-map IPsec
match protocol tcp
match protocol udp
match protocol icmp
!
policy-map type inspect RouterToInternet
description Traffic Router to Internet
class type inspect RouterProtocols
inspect
class class-default
drop
policy-map type inspect LokalToInternet
description Traffic LAN to Internet
class type inspect LokalAllowed
inspect
class class-default
drop
policy-map type inspect InternetToRouter
description Permitted traffic Internet to router
class type inspect IPsec
pass
class class-default
drop
!
zone security LAN
zone security Internet
!
zone-pair security InternetToRouter source Internet destination self
service-policy type inspect InternetToRouter
zone-pair security RouterToInternet source self destination Internet
service-policy type inspect RouterToInternet
zone-pair security LokalToInternet source LAN destination Internet
service-policy type inspect HomeToInternet
!
ip access-list extended ISAKMP_IPSEC
permit udp any any eq isakmp
permit udp any any eq non500-isakmp
permit esp any any
! Damit rennt einen VLC oder Kodi Session auf die Magenta TV Kanäle fehlerlos.
Es kann möglich sein das für den Media Receiver Multicast Session von Outbound initiiert werden. Die bleiben dann natürlich an der Firewall hängen.
Alles was von Outbound auf das Dialer Interface zugreifen darf bestimmt letztlich die ISAKMP_IPSEC ACL.
Man könnte dort testweise nochmal permit ip 224.0.0.0 15.255.255.255 any hinzufügen.
Das würde dann alle Multicast Adressen erlauben. Noch einfacher ist es wenn man temporär mal mit no zone-member security LAN bzw. no zone-member security Internet die FW mal temporär zum Testn ganz ausschaltet.
Sollte es dann klappen mit dem Media Receiver kann man sicher sein das die ZFW Firewall dort irgendwas für den Media Receiver wichtiges aus dem IPTV Flow filtert.
1
Hallo aqui,
vielen Dank für dein Tutorial. Sehr ausführlich und gut erklärt.
Warum ist aber folgende Befehl auf dem Dialer interface Pflicht? -> "no keepalive "
vielen Dank für dein Tutorial. Sehr ausführlich und gut erklärt.
Warum ist aber folgende Befehl auf dem Dialer interface Pflicht? -> "no keepalive "
Du hast Recht! Das war ein Fehler in der Konfig und mittlerweile im Tutorial korrigiert!
Das Dialer (PPPoE) Interface muss zwingend einen Keepalive konfiguriert haben ansonsten kommt das PPPoE Interface nach einer Provider Zwangstrennung nicht mehr hoch. Hier sollte man den Default Wert (keepalive 30) immer belassen!!
Guckst du hier:
https://www.cisco.com/c/en/us/support/docs/content-networking/keepalives ...
Das Dialer (PPPoE) Interface muss zwingend einen Keepalive konfiguriert haben ansonsten kommt das PPPoE Interface nach einer Provider Zwangstrennung nicht mehr hoch. Hier sollte man den Default Wert (keepalive 30) immer belassen!!
Guckst du hier:
https://www.cisco.com/c/en/us/support/docs/content-networking/keepalives ...
1
Der Grund warum ich das frage ist, dass ich aktuell mit einem 886VAJ Router einiges ausprobiere. Dabei ist mir aufgefallen, dass keine Kommunikation mehr möglich ist wenn der VDSL Controller "down" geht. Der Dialer Interface bleibt weiterhin "up" und behehlt die alte IP Adresse. Nachdem der Dialer ausgeschaltet und wieder eingeschaltet wird bekommt der Dialer eine neue IP Adresse zugewiesen und alle funktioniert wieder normal. Das Thema wurde hier schon mal behandelt und als Lösung wurde vorgeschlagen, dass der Dialer Interface automatisch mit Hilfe von Command Scheduler resettet wird.
Ich konnte bis jetzt nicht wirklich feststellen, ob das eine Zwangstrennung von Provider ist. Laut Telekom gibt es aber keine Zwangstrennung mehr für die IP-basierten Anschlüsse. Ich habe dafür aber ein Case aufgemacht und der TAC hat mit mitgeteilt, dass der Befehlt "keepalive 5" auf dem Dialer Interface das Problem beheben sollte. Dein Tutorial weist allerdings hin "no keepalive" zu verwenden.
Ich habe den Vorschlag von dem TAC implementiert und jetzt werde ich beobachten wie sich das verhält. Wen das nicht hilft, dann werde ich die von dir vorgeschlagene Lösung mit "Command Scheduler" verwenden.
Was für mich aber kein Sinn ergibt ist warum der Dialer bei eine Zwangstrennung nicht automatisch eine neue IP Adresse bezieht und wir mit Hilfe von Command Scheduler nachhelfen müssen.
Ich konnte bis jetzt nicht wirklich feststellen, ob das eine Zwangstrennung von Provider ist. Laut Telekom gibt es aber keine Zwangstrennung mehr für die IP-basierten Anschlüsse. Ich habe dafür aber ein Case aufgemacht und der TAC hat mit mitgeteilt, dass der Befehlt "keepalive 5" auf dem Dialer Interface das Problem beheben sollte. Dein Tutorial weist allerdings hin "no keepalive" zu verwenden.
Ich habe den Vorschlag von dem TAC implementiert und jetzt werde ich beobachten wie sich das verhält. Wen das nicht hilft, dann werde ich die von dir vorgeschlagene Lösung mit "Command Scheduler" verwenden.
Was für mich aber kein Sinn ergibt ist warum der Dialer bei eine Zwangstrennung nicht automatisch eine neue IP Adresse bezieht und wir mit Hilfe von Command Scheduler nachhelfen müssen.
dass keine Kommunikation mehr möglich ist wenn der VDSL Controller "down" geht.
Was ja auch irgendwie logisch ist, denn das bedeutet das dort dann ein gravierendes Problem am Interface aufgetreten ist. Kabel defekt, Anschlussdose defekt, usw. Es ist ein schlichter Carrier Verlust am Modem Anschluss. Das ist so als wenn du am Ethernet Port das Patchkabel ziehst oder durchschneidest...Cisco hat generell 2 Status auf Interfaces, deshalb redet man auch immer von "up/up". Das erste "up" bezieht sich immer auf die Physik und das zweite "up" auf das Schnittstellen Protokoll. Hier bei PPPoE eben die physische Schnittstelle und das PPP Protokoll.
Beim 880er kommt noch dazu das das interne Dual Mode Modem sich im ADSL Zweig auf das virtuelle ATM Interface splittet und im VDSL Zweig auf das virtuelle Ethernet Interface.
dass der Dialer Interface automatisch mit Hilfe von Command Scheduler resettet wird.
Das ist aber eine Notlösung da vermutlich ein Bug in einer älteren IOS Version. Mit den aktuellen 15er und 16er IOS Versionen passiert das nicht. PPP baut immer selbstständig den Link wieder auf wenn der Keepalive auf dem Dialer Inteface gesetzt ist was immer der Default ist!Ich habe den Vorschlag von dem TAC implementiert und jetzt werde ich beobachten wie sich das verhält.
Das Feedback wäre in der Tat sehr spannend !!
Ich werde den TAC mal darauf aufmerksam machen.
Aber dein Kommentar ist sehr hilfreich und informativ. Vielen Dank dafür!
Ich heute diesbezüglich noch bisschen recherchiert und bin auf dem folgenden Guide von Cisco gestoßen:
-> https://www.cisco.com/c/en/us/support/docs/wan/point-to-point-protocol-p ...
Der Befehl ist nicht sichtbar, der kann jedoch konfiguriert werden. Eine gute Alternativ zum Command Scheduler.
Aber dein Kommentar ist sehr hilfreich und informativ. Vielen Dank dafür!
Ich heute diesbezüglich noch bisschen recherchiert und bin auf dem folgenden Guide von Cisco gestoßen:
-> https://www.cisco.com/c/en/us/support/docs/wan/point-to-point-protocol-p ...
Der Befehl ist nicht sichtbar, der kann jedoch konfiguriert werden. Eine gute Alternativ zum Command Scheduler.
Wenn er nicht sichtbar ist dann ist das normalerweise Default. Ist aber in der Tat sinnvoller als die Quick and Dirty Scheduler Lösung.
Hi Aqui,
seit Umstellung auf 100Mbit habe vermehrt wieder Ausfälle trotz Scheduler.. neben dem MR Problem .
Allein heute 2 x . Bin noch nicht dazu gekommen zu schauen ob es vielleicht ein update des Vigor 130 gibt der bei mir als modem vor Router ist.
Abgesehen davon - kann ich dann zur Not meine FB 7490 auf rein Modem umstellen wie das Vigor?
Oder weiß jemand was vielleicht sonst noch das Problem ein kann? Aufbau :
Vigor 130 - Cisco Router - Cisco 2960g switch - FB 7490 (imo nur wegen SIP)
thx
Cyb
seit Umstellung auf 100Mbit habe vermehrt wieder Ausfälle trotz Scheduler.. neben dem MR Problem .
Allein heute 2 x . Bin noch nicht dazu gekommen zu schauen ob es vielleicht ein update des Vigor 130 gibt der bei mir als modem vor Router ist.
Abgesehen davon - kann ich dann zur Not meine FB 7490 auf rein Modem umstellen wie das Vigor?
Oder weiß jemand was vielleicht sonst noch das Problem ein kann? Aufbau :
Vigor 130 - Cisco Router - Cisco 2960g switch - FB 7490 (imo nur wegen SIP)
thx
Cyb
kann ich dann zur Not meine FB 7490 auf rein Modem umstellen wie das Vigor?
Sofern die Firmware deiner FritzBox das supportet natürlich ja.
Hi Aqui,
danke erstmal. Ich muss scahuen wenn ich daheim bin wegen neuestem Firmware.
AVM schreibt das :
https://avm.de/service/fritzbox/fritzbox-7590/wissensdatenbank/publicati ...
Den Screenshot von dir habe ich aber glaub ich bei meiner schon gesehen.
hm..
Kann ich irgendwie die "Fehler" sehen warum es aussteigt ohne das mein Router in die Knie (debug) geht?
thx
greets
Cyb
danke erstmal. Ich muss scahuen wenn ich daheim bin wegen neuestem Firmware.
AVM schreibt das :
https://avm.de/service/fritzbox/fritzbox-7590/wissensdatenbank/publicati ...
Den Screenshot von dir habe ich aber glaub ich bei meiner schon gesehen.
hm..
Kann ich irgendwie die "Fehler" sehen warum es aussteigt ohne das mein Router in die Knie (debug) geht?
thx
greets
Cyb
Kann ich irgendwie die "Fehler" sehen warum es aussteigt ohne das mein Router in die Knie (debug) geht?
Sowohl dein Modem als auch das Cisco Logg sollten hier einen Carrier Loss (Modem) oder einen PPP Fehler (Cisco) melden. Wie immer ist es also sehr sinnvoll die Loggs anzusehen oder die Logs per Syslog zentral zu sammeln.Je nach Art des Fehlers kannst du dann weiter eingrenzen und auch ggf. mal einen PPPoE Debug fahren auf dem Cisco.
Hi Aqui,
ja ..hatte nur noch in Erinnerung das es vor dem nicht mehr auftreten damals ich auch nirgends groß was sehen konnte.
Dann war es ja so gut wie weg und nun wie es scheint noch häufiger wieder da. (seit dem MR401 DHCP Fiasko bzw. 100mbit )
Mal sehen nach den Logs
Aber wenn ich das richtig verstanden habe -
kann ich mich mit dem Router über das Gi0/0 IF (imo am Vigor per pppoE) dann über denselben Login wie die FB anmelden oder sind das schon
"mehrerer Internetverbindungen " ? wie es bei AVM steht ?
Soweit ich auf die schnelle nachschauen konnte lässt die Telekom : " ...Es kann dann nur noch eine Verbindung mittels PPPoE aufgebaut werden. " zu ?
Oder muss dann alles umkonfiguriert werden im worst case?
greets
Cyb
ja ..hatte nur noch in Erinnerung das es vor dem nicht mehr auftreten damals ich auch nirgends groß was sehen konnte.
Dann war es ja so gut wie weg und nun wie es scheint noch häufiger wieder da. (seit dem MR401 DHCP Fiasko bzw. 100mbit )
Mal sehen nach den Logs
Aber wenn ich das richtig verstanden habe -
kann ich mich mit dem Router über das Gi0/0 IF (imo am Vigor per pppoE) dann über denselben Login wie die FB anmelden oder sind das schon
"mehrerer Internetverbindungen " ? wie es bei AVM steht ?
Soweit ich auf die schnelle nachschauen konnte lässt die Telekom : " ...Es kann dann nur noch eine Verbindung mittels PPPoE aufgebaut werden. " zu ?
Oder muss dann alles umkonfiguriert werden im worst case?
greets
Cyb
Das Vigor Modem arbeitet natürlich nur als reines, transparentes Modem ! Die gesamte PPPoE Konfig mit den Zugangsdaten ist immer auf dem Cisco Router ! Sonst hättest du ja eine Router Kaskade was keiner will.
Dennoch haben die Modems meist zusätzlich immer noch eine statische, feste IP für den Konfig Zugriff auf ihrem LAN Interface.
Wenn du dem Cisco eine Secondary IP gibst kannst du auf das Modem bzw. sein Management zugreifen.
Einfacher (und besser) ist es aber in die Punkt zu Punkt Verbindung Cisco - Modem einen kleinen Switch einzuschleifen für die Troubleshooting Phase und dort einen PC zu plazieren um das Logg über die Management IP abzufragen oder als Empfänger für ggf. Syslog Export des Modems sofern es das supportet.
Dennoch haben die Modems meist zusätzlich immer noch eine statische, feste IP für den Konfig Zugriff auf ihrem LAN Interface.
Wenn du dem Cisco eine Secondary IP gibst kannst du auf das Modem bzw. sein Management zugreifen.
Einfacher (und besser) ist es aber in die Punkt zu Punkt Verbindung Cisco - Modem einen kleinen Switch einzuschleifen für die Troubleshooting Phase und dort einen PC zu plazieren um das Logg über die Management IP abzufragen oder als Empfänger für ggf. Syslog Export des Modems sofern es das supportet.
Hi Aqui,
Ja das hatte ich schon verstanden . Ich dachte nur eventuell kann ich das Modem nur für das PPPoE durch die FB ersetzen. Aber siehe oben ..das scheint nicht zu gehen laut AVM.
Heute morgen ist es wieder weg gewesen. Nach dem schedule shut nicht mehr funktioniert. Dann kurz den Dialer shut / no shut und alles geht wieder. Doof. Der Vigor hat das neueste Firmware wobei es da 2 gibt. Eines wenn wohl kein oder schlechter DL / UL da ist. Aber bei mir ist ja bis auf die Aussetzer alles schnell und da.
Mist... Weiß nicht mehr ob das auch so ginge - FB Zugang WAN und SIP ...dann Transfernetz zum Cisco R auf Gi0/0 und auf Gi0/1 Cisco dann Homenetz und SVIs wie bisher. Wenn das so ginge wäre der Vigor raus, falls es mit der FB alles stable läuft.
Zitat von @aqui:
Das Vigor Modem arbeitet natürlich nur als reines, transparentes Modem ! Die gesamte PPPoE Konfig mit den Zugangsdaten ist immer auf dem Cisco Router ! Sonst hättest du ja eine Router Kaskade was keiner will.>
Das Vigor Modem arbeitet natürlich nur als reines, transparentes Modem ! Die gesamte PPPoE Konfig mit den Zugangsdaten ist immer auf dem Cisco Router ! Sonst hättest du ja eine Router Kaskade was keiner will.>
Ja das hatte ich schon verstanden . Ich dachte nur eventuell kann ich das Modem nur für das PPPoE durch die FB ersetzen. Aber siehe oben ..das scheint nicht zu gehen laut AVM.
Heute morgen ist es wieder weg gewesen. Nach dem schedule shut nicht mehr funktioniert. Dann kurz den Dialer shut / no shut und alles geht wieder. Doof. Der Vigor hat das neueste Firmware wobei es da 2 gibt. Eines wenn wohl kein oder schlechter DL / UL da ist. Aber bei mir ist ja bis auf die Aussetzer alles schnell und da.
Mist... Weiß nicht mehr ob das auch so ginge - FB Zugang WAN und SIP ...dann Transfernetz zum Cisco R auf Gi0/0 und auf Gi0/1 Cisco dann Homenetz und SVIs wie bisher. Wenn das so ginge wäre der Vigor raus, falls es mit der FB alles stable läuft.
Aber siehe oben ..das scheint nicht zu gehen laut AVM.
Ersteiger bei eBay eine alte 7412er Box ! https://www.heise.de/select/ct/2020/2/1578238295698254
Dann kurz den Dialer shut / no shut und alles geht wieder.
Hast du das obige dialer down-with-vInterface auf deinem Dialer Interface konfiguriert ??Zitat von @aqui:
https://www.heise.de/select/ct/2020/2/1578238295698254
Aber siehe oben ..das scheint nicht zu gehen laut AVM.
Ersteiger bei eBay eine alte 7412er Box ! https://www.heise.de/select/ct/2020/2/1578238295698254
Dann kurz den Dialer shut / no shut und alles geht wieder.
Hast du das obige dialer down-with-vInterface auf deinem Dialer Interface konfiguriert ??FB schau ich mal ..Brauche halt DECT , SIP und eben den PPPoE Zugang. Wenn das geht - beste
Nein das dialer down habe ich noch nicht eingegeben .. aber wenn ich es richtig verstanden habe setzt es "nur" das if dialer auf down wenn pppoE weg ist.
Ändert doch dann nix am Problem oder?
greets
Cyb
das if dialer auf down wenn pppoE weg ist.
Das triggert dann aber den Neuaufbau der PPPoE Session ! Zitat von @aqui:
das if dialer auf down wenn pppoE weg ist.
Das triggert dann aber den Neuaufbau der PPPoE Session ! Automatisch? ach so
Dann mach ich es rein und wenn das mit re-Connect klappt könnt ich gar mit leben und kann erstmal alles so lassen.
danke Aqui !!!
gebe ich gleich ein zum testen
greets
Cyb
AAAAAAAAAAAHH
den Befehl gibt es nicht bei meinem iOs
den Befehl gibt es nicht bei meinem iOs
Dann upgraden ! Hast du denn so ein olles IOS auf deinem System ??
Haha..
das letzte was supported war für meinen Router Oder hast du ein neueres für meinen 2821 ?? )
EOL Software 2016
Ich habe mal bei Telekom gefragt - die meinen pppoE passthrough ist bei gleichen Einwahldaten eine Verbindung. Die von AVM meinten dann das es mit der FB 7490 gehen sollte.
Ich kann es später mal probieren ob das funktioniert wenn in der FB und dem Cisco eingewählt wird.
Ansonsten muss ich wohl mit Leben erstmal bzw. einen neueren Router besorgen ;)
greets
Cyb
das letzte was supported war für meinen Router
Oder hast du ein neueres für meinen 2821 ?? )EOL Software 2016
Ich habe mal bei Telekom gefragt - die meinen pppoE passthrough ist bei gleichen Einwahldaten eine Verbindung. Die von AVM meinten dann das es mit der FB 7490 gehen sollte.
Ich kann es später mal probieren ob das funktioniert wenn in der FB und dem Cisco eingewählt wird.
Ansonsten muss ich wohl mit Leben erstmal bzw. einen neueren Router besorgen ;)
greets
Cyb
Hi Aqui,
schau ich mir mal an. Der hatz auch ios? Kann ich dann die config 1 zu 1 nehmen?
Habe getestet gestern wegen pppoE mit FB . Hat nicht geklappt. Hatte zwar gefragt aber bin mir nicht sicher ob Telekom das so zulässt mit selben Daten. Muss dann nochmal schauen ob ich es mit Transfernetz hinbekomme und ob da alles funktioniert. Aber leider muss ich nächste Zeit weg und kann nichts machen.
Habe wieder die FB dran.. nicht das Familie nicht TV schauen kann .lol
Da hat der MR401 sofort IP bekommen und updates gezogen. Liegt also definitiv am cisco.
greets
Cyb
schau ich mir mal an. Der hatz auch ios? Kann ich dann die config 1 zu 1 nehmen?
Habe getestet gestern wegen pppoE mit FB . Hat nicht geklappt. Hatte zwar gefragt aber bin mir nicht sicher ob Telekom das so zulässt mit selben Daten. Muss dann nochmal schauen ob ich es mit Transfernetz hinbekomme und ob da alles funktioniert. Aber leider muss ich nächste Zeit weg und kann nichts machen.
Habe wieder die FB dran.. nicht das Familie nicht TV schauen kann .lol
Da hat der MR401 sofort IP bekommen und updates gezogen. Liegt also definitiv am cisco.
greets
Cyb
Der hatz auch ios?
Das neuere IOS-XE. Syntax seitig ist das aber identisch.Kann ich dann die config 1 zu 1 nehmen?
Ja !Ggf. wenn du ZFW machst musst du die Security Lizenz SL-900-SEC(=) dazu beschaffen. In den neuen XE Images ist nur CBAC inkludiert.
C926-4P und C1112-8P rennen fehlerlos mit Telekom ALL IP und Magenta TV.
Hi Aqui.
ahoi, nach langer Abstinenz durch krank.. bin ich wieder bei dem Thema
Hab mal bei Cisco geschaut..da steht das das XE mit den 1000 ISR kommt. 900 konnt ich nix finden nur ios ..
kann das sein? bei cisco hab ich nur das Cisco ISR 1100 Series IOS XE Universal gesehen.
greets
Cyb
ahoi, nach langer Abstinenz durch krank.. bin ich wieder bei dem Thema
Hab mal bei Cisco geschaut..da steht das das XE mit den 1000 ISR kommt. 900 konnt ich nix finden nur ios ..
kann das sein? bei cisco hab ich nur das Cisco ISR 1100 Series IOS XE Universal gesehen.
greets
Cyb
Es stimmt was da bei Cisco steht...
Für VPN Support brauchen beide neuen Modelle zusätzlich eine Security Lizenz. Multicast (IP-TV) ist bei beiden im Base IP Image inkludiert.
- Die ISR 1000er Modelle rennen mit IOS-XE
- Die ISR 900er Modelle haben plain IOS
Für VPN Support brauchen beide neuen Modelle zusätzlich eine Security Lizenz. Multicast (IP-TV) ist bei beiden im Base IP Image inkludiert.
Hi Aqui ,
danke erstmal.
Kapier aber nicht ganz wie das laufen soll
Cisco Data Sheet
ok..das image habe ich vorausgesetzt.. wie kommt man dann an die sec lizenz ? bzw. was kostet die?
greets
Cyb
danke erstmal.
Kapier aber nicht ganz wie das laufen soll
Cisco Data Sheet
ok..das image habe ich vorausgesetzt.. wie kommt man dann an die sec lizenz ? bzw. was kostet die?
greets
Cyb
Die Lizenz bestellst du ganz einfach beim Händler und bekommst dann elektronisch und auf dem Papier eine Transaction ID. Damit gehst du im Cisco CCO auf den License Manager, gibst die Transaction ID dort an mit der Seriennummer des Gerätes. Das License Portal spukt dir dann ein License File aus den du aufs Flash kopierst und dann mit install license flash:meinelizenz.bin einmalig auf dem Gerät installierst.
Eigentlich ganz simpel.
Es ist etwas preiswerter die Lizenzen bei der Order gleich mitzubestellen als separat hinterher. Außerdem unterscheiden sie sich sehr stark im Preis z.B. zw. Cisco 1112-8P und Cisco 926-4P. Da es aber je nach Händlerstatus Rabatte bis zu 75% auf die Liste gibt ist ein finaler Preis schwer zu nennen.
Der Geschwindigkeitsunterschied bzw. ein show proc cpu his im Vergleich zu einem 886va sind aber schon recht deutlich.
Eigentlich ganz simpel.
Es ist etwas preiswerter die Lizenzen bei der Order gleich mitzubestellen als separat hinterher. Außerdem unterscheiden sie sich sehr stark im Preis z.B. zw. Cisco 1112-8P und Cisco 926-4P. Da es aber je nach Händlerstatus Rabatte bis zu 75% auf die Liste gibt ist ein finaler Preis schwer zu nennen.
Der Geschwindigkeitsunterschied bzw. ein show proc cpu his im Vergleich zu einem 886va sind aber schon recht deutlich.
Hi Aqui,
ja einfach wenn man weiß das es so gehen soll
Wer ist be dir Händler? Letzter Link war für das device ja Real ;)
Wenn ich das richtig gesehen habe kostet die Lizenz ja mehr als der Router?
das wäre dann zuviel für mein Budget..
greets
Cyb
ja einfach wenn man weiß das es so gehen soll
Wer ist be dir Händler? Letzter Link war für das device ja Real ;)
Wenn ich das richtig gesehen habe kostet die Lizenz ja mehr als der Router?
das wäre dann zuviel für mein Budget..
greets
Cyb
Hi aqui,
ich habe einen Cisco c1116 mit der IOS 16.9.6. Bei der VPN konfiguration bekomme ich folgenden Fehler:
Kannst du mir da weiterhelfen?
Grüße
Higgs
ich habe einen Cisco c1116 mit der IOS 16.9.6. Bei der VPN konfiguration bekomme ich folgenden Fehler:
Router(conf-isa-prof)# isakmp authorization list groupauth
% Incomplete command.
Router(conf-isa-prof)# isakmp authorization list groupauth ?
password AAA passwordKannst du mir da weiterhelfen?
Grüße
Higgs
Hi Higgs,
Ja, kann ich. 😉 Das liegt daran weil die modernen Cisco 1000er IOS-XE nutzen und einige wenige Kommandos eine geringfügig andere Syntax haben als das reine IOS der 880er.
Zuerst musst du global mit license boot security die VPN Funktion aktivieren was du vermutlich schon gemacht hast.
Dann lautet die IOS-XE Variante des Kommandos isakmp auhorization list default passwort xyz
Ja, kann ich. 😉 Das liegt daran weil die modernen Cisco 1000er IOS-XE nutzen und einige wenige Kommandos eine geringfügig andere Syntax haben als das reine IOS der 880er.
Zuerst musst du global mit license boot security die VPN Funktion aktivieren was du vermutlich schon gemacht hast.
Dann lautet die IOS-XE Variante des Kommandos isakmp auhorization list default passwort xyz
1
Man sollte für IPv6 noch
mitgeben, damit der den DNS-Resolver auch per Router-Advertisement verteilt, das schrottige Android kann nämlich kein DHCPv6 und erhält somit keinen IPv6-DNS.
ipv6 nd ra dns server 2001:470:20::2
Guter Tip ! 👍
Hi aqui,
ich finde es klasse, wie deteilreich du diesen Beitrag erstellt hast und pflegst!
Als ich den Beitrag heute gefunden habe, gab mir das etwas Hoffnung, dass uns jemand hier helfen kann.
Wir sind jetzt schon mehrere Wochen beschäftigt, unseren Vodafone Business DSL 16 mit einem Cisco C926-4P zum Laufen zu bekommen.
Die Vodafone-Leitung ADSL+ Annex J ist eine Bitstream-Leitung über die Telekom. Es war schon der Wahnsinn, überhaupt an die Informationen der ATM-Einstellungen wie z.B. VPI und VCI zu gelangen.
Die Leitung ist synchron, jedoch erhalten wir keinerlei Rückmeldung seitens Vodafone bezüglich der Authentifizierung. Egal ob per statischer IP oder dynamisch zugewiesener IP.
Wir sind nahezu alle Möglichkeiten durchgegangen, jedoch können wir nur Output packets sehen und erhalten keinen Input.
Vodafone hat letzte Woche 2 mal einen Telekom-Techniker zur Leitungsprüfung geschickt. Die Leitung ist nach Aussage von Vodafone und Telekom ohne Probleme und Vodafone kann keine Probleme auf ihrer Seite feststellen.
Wir wissen leider einfach nicht weiter. Hoffentlich hat jemand von euch eine Idee.
Nachfolgend findet ihr unsere Config:
Dialer0 mit statische IP:
Dialer1 für dynamische IP:
Vielen Dank!
ich finde es klasse, wie deteilreich du diesen Beitrag erstellt hast und pflegst!
Als ich den Beitrag heute gefunden habe, gab mir das etwas Hoffnung, dass uns jemand hier helfen kann.
Wir sind jetzt schon mehrere Wochen beschäftigt, unseren Vodafone Business DSL 16 mit einem Cisco C926-4P zum Laufen zu bekommen.
Die Vodafone-Leitung ADSL+ Annex J ist eine Bitstream-Leitung über die Telekom. Es war schon der Wahnsinn, überhaupt an die Informationen der ATM-Einstellungen wie z.B. VPI und VCI zu gelangen.
Die Leitung ist synchron, jedoch erhalten wir keinerlei Rückmeldung seitens Vodafone bezüglich der Authentifizierung. Egal ob per statischer IP oder dynamisch zugewiesener IP.
Wir sind nahezu alle Möglichkeiten durchgegangen, jedoch können wir nur Output packets sehen und erhalten keinen Input.
Vodafone hat letzte Woche 2 mal einen Telekom-Techniker zur Leitungsprüfung geschickt. Die Leitung ist nach Aussage von Vodafone und Telekom ohne Probleme und Vodafone kann keine Probleme auf ihrer Seite feststellen.
Wir wissen leider einfach nicht weiter. Hoffentlich hat jemand von euch eine Idee.
Nachfolgend findet ihr unsere Config:
Dialer0 mit statische IP:
interface Dialer0
description ADSL_forVPN
ip address negotiated
ip mtu 1492
encapsulation ppp
ip tcp adjust-mss 1452
dialer pool 2
dialer idle-timeout 0
dialer string 8134
dialer persistent delay initial 60
dialer persistent delay 10
dialer-group 2
no cdp enable
ppp authentication chap pap callin
ppp chap hostname dsl.vodafone/biXXXXXXXXXX-static
ppp chap password XXXXXXX
ppp pap sent-username dsl.vodafone/biXXXXXXXXXX-static password XXXXXXX
ppp ipcp route defaultDialer1 für dynamische IP:
interface Dialer1
description DSL_forVPN
ip address negotiated
ip mtu 1492
encapsulation ppp
ip tcp adjust-mss 1452
dialer pool 1
dialer idle-timeout 0
dialer string 8134
dialer persistent delay initial 60
dialer persistent delay 10
dialer-group 2
no cdp enable
ppp authentication chap pap callin
ppp chap hostname dsl.vodafone/biXXXXXXXXXX
ppp chap password XXXXXX
ppp pap sent-username dsl.vodafone/biXXXXXXXXXX password XXXXX
ppp ipcp route default
controller VDSL 0
operating mode adsl2+
sra
interface ATM0
no ip address
no atm ilmi-keepalive
interface ATM0.1 point-to-point
pvc 1/32
encapsulation aal5snap
pppoe-client dial-pool-number 2<---------Test with dynamic IP credential not working
!
interface ATM0.1 point-to-point
pvc 1/32
encapsulation aal5snap
pppoe-client dial-pool-number 1<---------Test with static IP credential not working
!
Log from the router:
*Dec 22 10:43:03: Sending PADI: vc=1/32
*Dec 22 10:43:35: padi timer expired
Interface IP-Address OK? Method Status Protocol
ATM0 unassigned YES NVRAM up up
ATM0.1 unassigned YES unset up up
Dialer0 unassigned YES NVRAM up up
Dialer1 unassigned YES NVRAM up up
DSL16#sh controllers vdsl 0
Controller VDSL 0 is UP
Daemon Status: Up
XTU-R (DS) XTU-C (US)
Chip Vendor ID: 'BDCM' 'IFTN'
Chip Vendor Specific: 0x0000 0x82B9
Chip Vendor Country: 0xB500 0xB500
Modem Vendor ID: 'CSCO' ' '
Modem Vendor Specific: 0x4602 0x0000
Modem Vendor Country: 0xB500 0x0000
Serial Number Near: FGL2539LAJH C926-4P 15.8(3)M6
Serial Number Far:
Modem Version Near: 15.8(3)M6
Modem Version Far: 0x82b9
Modem Status: TC Sync (Showtime!)
DSL Config Mode: ADSL2+
Trained Mode: G.992.5 (ADSL2+) Annex J
TC Mode: ATM
Selftest Result: 0x00
DELT configuration: disabled
DELT state: not running
Link Status: UP
Full inits: 2
Failed full inits: 1
Short inits: 1
Failed short inits: 0
Firmware Source File Name
-------- ------ ----------
VDSL embedded VDSL_LINUX_DEV_01212008
Modem FW Version: 4.14L.04
Modem PHY Version: B2pv6F039x3.d26u
Line:
XTU-R (DS) XTU-C (US)
Trellis: ON ON
SRA: enabled enabled
SRA count: 2 2
Bit swap: enabled enabled
Bit swap count: 4050 0
Line Attenuation: 45.5 dB 24.7 dB
Signal Attenuation: 42.3 dB 24.7 dB
Noise Margin: 3.8 dB 5.8 dB
Attainable Rate: 10200 kbits/s 1456 kbits/s
Actual Power: 0.0 dBm 13.2 dBm
Total FECC: 36324098 102
Total ES: 6542 2
Total SES: 38 2
Total LOSS: 0 0
Total UAS: 113 113
Total LPRS: 0 0
Total LOFS: 0 0
Total LOLS: 0 0
DS Channel1 DS Channel0 US Channel1 US Channel0
Speed (kbps): 0 8189 0 1457
SRA Previous Speed: 0 8189 0 1457
Previous Speed: 0 8189 0 1457
Total Cells: 0 97621835 0 17350998
User Cells: 0 5 0 312
Reed-Solomon EC: 0 5854992 0 59
CRC Errors: 0 21863 0 0
Header Errors: 0 10081 0 0
Interleave (ms): 0.00 7.61 0.00 7.95
Actual INP: 0.00 3.88 0.00 1.12
Training Log : Stopped
Training Log Filename : flash:vdsllog.bin
DSL16#
DSL16#sh int atM 0
ATM0 is up, line protocol is up
Hardware is MPC ATMSAR, address is a49b.cd45.e8c7 (bia a49b.cd45.e8c7)
MTU 1800 bytes, sub MTU 1800, BW 1457 Kbit/sec, DLY 250 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ATM, loopback not set
Keepalive not supported
Encapsulation(s): AAL5
4 maximum active VCs, 1024 VCs per VP, 1 current VCCs
VC Auto Creation Disabled.
VC idle disconnect time: 300 seconds
Last input 05:53:17, output 00:00:19, output hang never
Last clearing of "show interface" counters never
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: Per VC Queueing
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
1 packets input, 78 bytes, 0 no buffer
Received 0 broadcasts (0 IP multicasts)
0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
655 packets output, 45850 bytes, 0 underruns
0 output errors, 0 collisions, 1 interface resets
0 unknown protocol drops
0 output buffer failures, 0 output buffers swapped out
DSL16#sh int atM 0.1
ATM0.1 is up, line protocol is up
Hardware is MPC ATMSAR, address is a49b.cd45.e8c7 (bia a49b.cd45.e8c7)
MTU 1800 bytes, BW 1457 Kbit/sec, DLY 250 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ATM
Keepalive not supported
3 packets input, 224 bytes
655 packets output, 45850 bytes
0 OAM cells input, 0 OAM cells output
AAL5 CRC errors : 0
AAL5 SAR Timeouts : 0
AAL5 Oversized SDUs : 0
Last clearing of "show interface" counters never Vielen Dank!
Was hast du bezüglich IPv6 konfiguriert?
Ist bei eurem Anschluss überhaupt eine öffentliche IP-Adresse dabei?
Ist bei eurem Anschluss überhaupt eine öffentliche IP-Adresse dabei?
IPv6 ist nicht konfiguriert, so weit ich weiß.
Bei unserem Anschluss ist eine statische öffentliche IPv4 Adresse dabei.
Bei unserem Anschluss ist eine statische öffentliche IPv4 Adresse dabei.
Und warum?
Wir haben 2021, da sollte man IPv6 einrichten, schon alleine weil dein IPv6-Traffic dann nicht das NAT belastet.
Wir haben 2021, da sollte man IPv6 einrichten, schon alleine weil dein IPv6-Traffic dann nicht das NAT belastet.
Bei unserem Anschluss ist eine statische öffentliche IPv4 Adresse dabei.
Wird diese per IPCP oder DHCP vergeben oder muss diese manuell eingetragen werden?
Danke dir für deine schnelle Rückmeldung.
Ich bin in einer Vermittler-Situation. Unser Cisco-Admin arbeitet in der Firmenzentrale in Kanada.
Bezüglich der Vergabe der statischen IP ist ein guter Anhaltspunkt. Da werde ich morgen mal Vodafone kontaktieren und nachfragen müssen.
Wir haben auch die Anmeldung mit "dynamischer" IP getestet, jedoch erhalten wir kein Ergebnis. Keine Rückmeldung seitens Vodafone, ob Benutzername oder Passwort eventuell falsch ist.
Ich bin in einer Vermittler-Situation. Unser Cisco-Admin arbeitet in der Firmenzentrale in Kanada.
Bezüglich der Vergabe der statischen IP ist ein guter Anhaltspunkt. Da werde ich morgen mal Vodafone kontaktieren und nachfragen müssen.
Wir haben auch die Anmeldung mit "dynamischer" IP getestet, jedoch erhalten wir kein Ergebnis. Keine Rückmeldung seitens Vodafone, ob Benutzername oder Passwort eventuell falsch ist.
Ist eine Firewall konfiguriert?
Wenn ja mal komplett abstellen, nicht dass diese die Pakete verwirft...
Wenn ja mal komplett abstellen, nicht dass diese die Pakete verwirft...
Was hilfreich wäre ist einen separaten Thread dafür aufzumachen mit einem Link Verweis hier um das Tutorial nicht mit dem kommenden Troubleshooting "vollzumüllen". 😉
Die Show Kommandos zeigen auf alle Fälle schon einmal das eine Modem Verbindung sauber zustandekommt (Showtime! und ATM Interface auf UP)
Leider hast du es versäumt das Allerwichtigste zu posten, nämlich ein show int Dialerx oder auch sh ip int brief wenn die Modem Verbinung steht !
Die Dialer Verbindung zeigt ob eine PPPoE Verbindung mit einer gültigen IP Adress Negotiation erfolgt ist. Ist das der Fall würde ein ping 8.8.8.8 source dialerx zeigen ob es eine generelle Internet Connectivity gibt wofür natürlich eine IP am Dialer Interface zwingend ist.
Kläre zudem wasserdicht mit Wodkafön ob die irgendeine Art von VLAN Tagging erfordern auf dem ADSL Interface ! Wäre das der Fall müsstest du das in deiner Konfig berücksichtigen. (Beispiel hier mit VLAN 7 Tagging):
interface ATM0.7 point-to-point
pvc 1/32
bridge-dot1q encap 7
pppoe-client dial-pool-number 1
Wäre aber nur dann relevant wenn du mit sh int dialerx keine PPPoE IP zugewiesen bekämst.
Du solltest auch besser den Encapsulation Type nicht vorgeben wie bei dir sondern das immer erstmal im Auto Modus laufen lassen. Die Gegenstellen finden das besser selber raus. Es sei denn du hast herausgefunden das eine Modem Connection ausschliesslich nur mit diesem Encapsulation Type zustande kommt und das zwingend ist.
Wie der Kollege @Windows10Gegner oben schon richtig gesagt hat kommen wir nur weiter wenn man deine aktuelle Gesamtkonfig (sh run) kennt um ggf. andere Konfig Fehler im Zusammenhang erkennen zu können. Wäre also sehr hilfreich wenn du die hier (bzw. in einem separaten Troubleshooting Thread) anonymisiert posten könntest ! In jedem Falle bringen wir das mit dir zum Laufen.
Bitte, wie schon angemerkt, wenn möglich mit einem separaten Thread und einem Verweis darauf an dieser Stelle.
Die Show Kommandos zeigen auf alle Fälle schon einmal das eine Modem Verbindung sauber zustandekommt (Showtime! und ATM Interface auf UP)
Leider hast du es versäumt das Allerwichtigste zu posten, nämlich ein show int Dialerx oder auch sh ip int brief wenn die Modem Verbinung steht !
Die Dialer Verbindung zeigt ob eine PPPoE Verbindung mit einer gültigen IP Adress Negotiation erfolgt ist. Ist das der Fall würde ein ping 8.8.8.8 source dialerx zeigen ob es eine generelle Internet Connectivity gibt wofür natürlich eine IP am Dialer Interface zwingend ist.
Kläre zudem wasserdicht mit Wodkafön ob die irgendeine Art von VLAN Tagging erfordern auf dem ADSL Interface ! Wäre das der Fall müsstest du das in deiner Konfig berücksichtigen. (Beispiel hier mit VLAN 7 Tagging):
interface ATM0.7 point-to-point
pvc 1/32
bridge-dot1q encap 7
pppoe-client dial-pool-number 1
Wäre aber nur dann relevant wenn du mit sh int dialerx keine PPPoE IP zugewiesen bekämst.
Du solltest auch besser den Encapsulation Type nicht vorgeben wie bei dir sondern das immer erstmal im Auto Modus laufen lassen. Die Gegenstellen finden das besser selber raus. Es sei denn du hast herausgefunden das eine Modem Connection ausschliesslich nur mit diesem Encapsulation Type zustande kommt und das zwingend ist.
Wie der Kollege @Windows10Gegner oben schon richtig gesagt hat kommen wir nur weiter wenn man deine aktuelle Gesamtkonfig (sh run) kennt um ggf. andere Konfig Fehler im Zusammenhang erkennen zu können. Wäre also sehr hilfreich wenn du die hier (bzw. in einem separaten Troubleshooting Thread) anonymisiert posten könntest ! In jedem Falle bringen wir das mit dir zum Laufen.
Bitte, wie schon angemerkt, wenn möglich mit einem separaten Thread und einem Verweis darauf an dieser Stelle.
1
Ich danke dir sehr für deine Anhaltspunkte! Das VLAN Tagging auf dem ADSL Interface war die Lösung!
Zumindest funktioniert jetzt schon einmal die dynamische IP-Zuweisung seitens Vodafone.
Ich werde einen separaten Thread aufmachen und gebe euch hier Bescheid.
Vielen Dank!
Zumindest funktioniert jetzt schon einmal die dynamische IP-Zuweisung seitens Vodafone.
Ich werde einen separaten Thread aufmachen und gebe euch hier Bescheid.
Vielen Dank!
👍
Dann kann 2022 ja kommen ! 😉
Dann kann 2022 ja kommen ! 😉
Hallo zusammen,
ich habe das Problem, das bei mir nachts hin und wieder mal die DSL Verbindung kurz verloren geht. Das passiert manchmal jede Woche und dann auch wieder mal wochenlang nicht. Ich vermute, dass die Telekom hier irgendwelche arbeiten durchführt.
Mein Problem ist hierbei, das hinterher zwar die VDSL Verbindung wieder korrekt ausgehandelt wird, aber mein Router keine IP Adresse mehr bekommt.
Ich habe schon einiges ausprobiert. Zuletzt habe ich das Dialer Interface und den VDSL Controller auf shutdown und no shutdown gesetzt - ohne Erfolg. Der Router handelt danach die VDSL Verbindung wieder neu aus, aber bekommt immer noch keine IP Adresse.
Die einzige funktionierende Lösung ist bisher immer ein reload des Routers.
Ist dieses Verhalten bereits bekannt und gibt es hierfür eine Lösung?
ich habe das Problem, das bei mir nachts hin und wieder mal die DSL Verbindung kurz verloren geht. Das passiert manchmal jede Woche und dann auch wieder mal wochenlang nicht. Ich vermute, dass die Telekom hier irgendwelche arbeiten durchführt.
Mein Problem ist hierbei, das hinterher zwar die VDSL Verbindung wieder korrekt ausgehandelt wird, aber mein Router keine IP Adresse mehr bekommt.
Ich habe schon einiges ausprobiert. Zuletzt habe ich das Dialer Interface und den VDSL Controller auf shutdown und no shutdown gesetzt - ohne Erfolg. Der Router handelt danach die VDSL Verbindung wieder neu aus, aber bekommt immer noch keine IP Adresse.
Die einzige funktionierende Lösung ist bisher immer ein reload des Routers.
Ist dieses Verhalten bereits bekannt und gibt es hierfür eine Lösung?
Hallo,
Bitte deine Frage nicht an diesen Beitrag anhängen!
Besser als neuen Beitrag im Forum erstellen.
Brammer
Bitte deine Frage nicht an diesen Beitrag anhängen!
Besser als neuen Beitrag im Forum erstellen.
Brammer
Bitte einmal die obige Thread Diskussion wirklich lesen ! Das Thema und seine Lösung ist dort schon mehrfach beschrieben worden:
Cisco 880, 890 und ISR Router Konfiguration mit xDSL, Kabel oder FTTH Anschluss plus VPN und IP-TV
Cisco 880, 890 und ISR Router Konfiguration mit xDSL, Kabel oder FTTH Anschluss plus VPN und IP-TV
An einigen wenigen Provider Anschlüssen kommt das PPPoE Dialer Interface nach der "Zwangstrennung" manchmal nicht mehr allein auf die Füße. Das liegt in der Regel daran das der Keepalive auf dem PPPoE Interface nicht gesetzt wurde! Es war auch eine zeitlang leider falsch hier im Tutorial beschrieben, sorry!
Wichtig ist auch die aktuelle Modem Firmware zu verwenden und am Dialer Interface den Keepalive unbedingt zu belassen!
Ein kompletter Reload ist übrigens dann nicht erforderlich ! Es reicht ein einfaches shut / no shut auf dem Dialer Interface. (Nichts anderes macht der cron Job oben auch, nur eben automatisch)
Cisco 880, 890 und ISR Router Konfiguration mit xDSL, Kabel oder FTTH Anschluss plus VPN und IP-TV
Cisco 880, 890 und ISR Router Konfiguration mit xDSL, Kabel oder FTTH Anschluss plus VPN und IP-TV
An einigen wenigen Provider Anschlüssen kommt das PPPoE Dialer Interface nach der "Zwangstrennung" manchmal nicht mehr allein auf die Füße. Das liegt in der Regel daran das der Keepalive auf dem PPPoE Interface nicht gesetzt wurde! Es war auch eine zeitlang leider falsch hier im Tutorial beschrieben, sorry!
Wichtig ist auch die aktuelle Modem Firmware zu verwenden und am Dialer Interface den Keepalive unbedingt zu belassen!
Ein kompletter Reload ist übrigens dann nicht erforderlich ! Es reicht ein einfaches shut / no shut auf dem Dialer Interface. (Nichts anderes macht der cron Job oben auch, nur eben automatisch)
1
Hallo,
Ich habe schon einige Cisco Router nach dieser Anleitung erfolgreich konfiguriert. Vielen Dank nochmal an dich @aqui für die sehr gute Anleitung.
Bisher habe ich jedoch hauptsächlich Router (z.B. 897VA) an xDSL Anschlüssen mit der Zonen basierten Firewall (ZFW) erfolgreich in Betrieb genommen.
Heute wollte ich erstmals einen Cisco 892FSP mit DHCP am WAN Interface an einem Kabel-TV Modem in Betrieb nehmen. Dabei wollte ich auch das Zonen basierte Firewallkonzept (ZFW) anwenden, jedoch hab ich es mit diesem nicht hinbekommen das der Router eine IP-Adresse am WAN-Interface bekommt.
Habe es auch nach der Anleitung mit der CBAC Firewall probiert mit dieser es auch auf Anhieb funktionierte.
Ich habe nach diversen Beiträgen gesucht und bin bei diesen fündig geworden, jedoch war dies für mich auch nicht zielführend.
https://community.cisco.com/t5/network-security/no-dhcp-through-zone-bas ...
https://community.cisco.com/t5/switching/cisco881w-zone-based-firewall-d ...
Ich wäre sehr dankbar um eine Lösung, damit ich den Router an diesem Anschluss auch mit der ZFW-Firewall betreiben kann. Ich bin mit meinen Lösungen am Ende...
Anbei hab ich noch meine bisherige Konfiguration (sh run) angefügt.
Vielen Dank im Voraus.
Ich habe schon einige Cisco Router nach dieser Anleitung erfolgreich konfiguriert. Vielen Dank nochmal an dich @aqui für die sehr gute Anleitung.
Bisher habe ich jedoch hauptsächlich Router (z.B. 897VA) an xDSL Anschlüssen mit der Zonen basierten Firewall (ZFW) erfolgreich in Betrieb genommen.
Heute wollte ich erstmals einen Cisco 892FSP mit DHCP am WAN Interface an einem Kabel-TV Modem in Betrieb nehmen. Dabei wollte ich auch das Zonen basierte Firewallkonzept (ZFW) anwenden, jedoch hab ich es mit diesem nicht hinbekommen das der Router eine IP-Adresse am WAN-Interface bekommt.
Habe es auch nach der Anleitung mit der CBAC Firewall probiert mit dieser es auch auf Anhieb funktionierte.
Ich habe nach diversen Beiträgen gesucht und bin bei diesen fündig geworden, jedoch war dies für mich auch nicht zielführend.
https://community.cisco.com/t5/network-security/no-dhcp-through-zone-bas ...
https://community.cisco.com/t5/switching/cisco881w-zone-based-firewall-d ...
Ich wäre sehr dankbar um eine Lösung, damit ich den Router an diesem Anschluss auch mit der ZFW-Firewall betreiben kann. Ich bin mit meinen Lösungen am Ende...
Anbei hab ich noch meine bisherige Konfiguration (sh run) angefügt.
Router-892FSP#sh run
Building configuration...
Current configuration : 8284 bytes
!
! Last configuration change at 20:57:16 CET Mon Feb 21 2022 by admin
!
version 15.9
service tcp-keepalives-in
service tcp-keepalives-out
service timestamps debug datetime localtime
service timestamps log datetime localtime show-timezone year
no service password-encryption
!
hostname Router-892FSP
!
boot-start-marker
boot system flash:c800-universalk9-mz.SPA.159-3.M1.bin
boot-end-marker
!
!
security authentication failure rate 3 log
security passwords min-length 6
enable secret 9 xxxxxxxx
!
aaa new-model
aaa local authentication attempts max-fail 5
!
!
aaa authentication login default local
aaa authorization network default local
!
!
!
!
!
!
aaa session-id common
memory-size iomem 25
clock timezone CET 1 0
clock summer-time CEST recurring last Sun Mar 2:00 last Sun Oct 3:00
!
!
!
!
!
!
!
!
!
no ip source-route
no ip gratuitous-arps
!
!
!
!
!
!
!
!
!
!
!
ip dhcp excluded-address 10.10.1.1 10.10.1.100
ip dhcp excluded-address 10.10.1.200 10.10.1.254
ip dhcp excluded-address 10.10.200.1 10.10.200.100
ip dhcp excluded-address 10.10.200.150 10.10.200.254
!
ip dhcp pool Lokales LAN
network 10.10.1.0 255.255.255.0
default-router 10.10.1.1
dns-server 10.10.1.1
!
ip dhcp pool Gastnetz
network 10.10.200.0 255.255.255.0
default-router 10.10.200.1
dns-server 10.10.200.1
!
!
!
ip cef
no ipv6 cef
!
!
!
!
multilink bundle-name authenticated
!
!
!
!
!
!
!
license udi pid C892FSP-K9 sn FCZ1742C18T
!
!
vtp mode transparent
username admin privilege 15 secret 9 xxxxxxxx
!
redundancy
!
!
!
!
!
!
!
class-map type inspect match-any DHCP-INTERNET
match protocol bootps
class-map type inspect match-any INTERNET-DHCP
match protocol bootps
match protocol bootpc
class-map type inspect match-any LOKAL-ERLAUBT
match protocol http
match protocol dns
match protocol pop3s
match protocol imaps
match protocol smtp
match protocol rtsp
match protocol ftp
match protocol ftps
match protocol ntp
match protocol tcp
match protocol udp
match protocol icmp
match protocol sip-tls
match protocol https
match protocol ssh
class-map type inspect match-any GAST-ERLAUBT
match protocol http
match protocol https
match protocol dns
match protocol ntp
class-map type inspect match-all IPsec_VPN
match access-group name ISAKMP_IPSEC
class-map type inspect match-any ROUTER-PROTOCOLS
match class-map IPsec_VPN
match protocol tcp
match protocol udp
match protocol icmp
!
policy-map type inspect LOKAL-INTERNET-POLICY
description Traffic Lokales LAN zum Internet
class type inspect LOKAL-ERLAUBT
inspect
class class-default
drop
policy-map type inspect ROUTER-INTERNET-POLICY
description Traffic Router zum Internet WAN
class type inspect ROUTER-PROTOCOLS
inspect
class type inspect DHCP-INTERNET
pass
class class-default
drop
policy-map type inspect GAST-INTERNET-POLICY
description Traffic Gast zum Internet
class type inspect GAST-ERLAUBT
inspect
class class-default
drop
policy-map type inspect INTERNET-ROUTER-POLICY
description Traffic Internet WAN zum Router
class type inspect IPsec_VPN
pass
class type inspect INTERNET-DHCP
pass
class class-default
drop
!
zone security LOKAL
zone security GAST
zone security INTERNET
zone-pair security LOKAL-INTERNET source LOKAL destination INTERNET
service-policy type inspect LOKAL-INTERNET-POLICY
zone-pair security INTERNET-ROUTER source INTERNET destination self
service-policy type inspect INTERNET-ROUTER-POLICY
zone-pair security ROUTER-INTERNET source self destination INTERNET
service-policy type inspect ROUTER-INTERNET-POLICY
zone-pair security GAST-INTERNET source GAST destination INTERNET
service-policy type inspect GAST-INTERNET-POLICY
!
!
!
!
!
!
!
!
!
!
!
interface GigabitEthernet0
no ip address
!
interface GigabitEthernet1
no ip address
!
interface GigabitEthernet2
no ip address
!
interface GigabitEthernet3
no ip address
!
interface GigabitEthernet4
no ip address
!
interface GigabitEthernet5
no ip address
!
interface GigabitEthernet6
no ip address
!
interface GigabitEthernet7
no ip address
!
interface GigabitEthernet8
description Internet WAN
ip address dhcp
no ip redirects
no ip unreachables
no ip proxy-arp
ip nat outside
ip virtual-reassembly in
zone-member security INTERNET
duplex auto
speed auto
no cdp enable
!
interface GigabitEthernet9
no ip address
shutdown
duplex auto
speed auto
!
interface Vlan1
description Lokales LAN
ip address 10.10.1.1 255.255.255.0
ip nat inside
ip virtual-reassembly in
zone-member security LOKAL
ip tcp adjust-mss 1448
!
interface Vlan200
description Gastnetz
ip address 10.10.200.1 255.255.255.0
ip nat inside
ip virtual-reassembly in
zone-member security GAST
ip tcp adjust-mss 1448
!
ip forward-protocol nd
no ip http server
no ip http secure-server
!
!
ip dns server
ip nat inside source list 101 interface GigabitEthernet8 overload
!
!
ip ssh time-out 30
ip ssh version 2
!
ip access-list extended ISAKMP_IPSEC
permit udp any any eq isakmp
permit udp any any eq non500-isakmp
permit esp any any
!
ipv6 ioam timestamp
!
access-list 23 permit 10.10.1.0 0.0.0.255
access-list 101 permit ip 10.10.1.0 0.0.0.255 any
access-list 101 permit ip 10.10.200.1 0.0.0.255 any
!
!
!
control-plane
!
!
!
mgcp behavior rsip-range tgcp-only
mgcp behavior comedia-role none
mgcp behavior comedia-check-media-src disable
mgcp behavior comedia-sdp-force disable
!
mgcp profile default
!
!
!
!
!
banner exec ^C Sie sind verbunden mit VTY $(line) auf dem Router $(hostname) ^C
!
line con 0
no modem enable
line aux 0
line vty 0 4
access-class 23 in
transport input ssh
!
scheduler allocate 20000 1000
ntp master
ntp server 130.149.17.8 source GigabitEthernet8
!
!
!
!
!
!
!
endVielen Dank im Voraus.
Geht es denn, wenn du die FW für das WAN-Interface abstellst?
Warum hast du kein IPv6 konfiguriert?
Warum hast du kein IPv6 konfiguriert?
Vorab:
Danke für diesen Hinweis eines wichtigen Punktes!! 👍
Das Tutorial hat jetzt einen entsprechenden Hinweis auf die DHCP Client Konfiguration des WAN Ports in Verbindung mit der Zone Based Firewall !
Die Lösung dafür ist sehr schnell gemacht in der ZBF Konfig.
Zur Erklärung:
Deine o.a. Class Map "DHCP" kann nicht greifen, da dies nur Traffic betrifft der die Firewall von Interface zu Interface bzw. richtiger gesagt: von Zone zu Zone passiert, was hier ja nicht der Fall ist, denn der DHCP Traffic betrifft einzig nur das eigene, lokale WAN Interface, ist also Router eigener Traffic, sprich Traffic der den Router direkt selber betrifft.
Die ZFW Firewall blockiert, prinzipbedingt, deshalb Broadcast Traffic der eigenen Interfaces wenn du mit inspect arbeitest !
Das resultiert dann darin, das Broadcast Traffic der eigenen Zone (self) ignoriert und damit geblockt wird ! Die Firewall ist da sehr streng, was sie ja auch sein soll ! 😉
Das siehst du auch wenn du am WAN Interface einmal mit einem Wireshark Sniffer mitsnifferst. Dort tauchen keinerlei DHCP Broadcast Requests des Cisco's bei aktiver ZBF auf. Ein sicheres Indiz das der DHCP Traffic durch die Firewall geblockt wird.
Sowie du aber die Traffic Inspection des eigenen Interfaces von inspect auf pass änderst funktioniert es dann fehlerlos !
Die pass Option blockiert im Gegensatz zur inspect Option keinen eigenen Broadcast Traffic.
Diese Änderung solltest du aber aus guten Gründen immer ausschliesslich nur an Interfaces machen die im DHCP Client Mode arbeiten !
PPPoE oder statische Interfaces sollten weiterhin immer mit inspect laufen ! Bei PPPoE gibt es kein DHCP bei IPv4.
Bei DHCPv6 funktioniert es übrigens deshalb immer im inspect Mode, weil DHCPv6 im Gegensatz zu IPv4 keinen Broadcast sondern Multicast für die DHCPv6 Adressvergabe nutzt.
So sollte die angepasste ZBF Konfig mit dem WAN Interface im DHCP Client Mode dann aussehen:
!
class-map type inspect match-all ALLOW_IN
match access-group name ALLOWv4
!
class-map type inspect match-any DHCPv4
match access-group name DHCPv4
!
class-map type inspect match-any ROUTER
match protocol tcp
match protocol udp
match protocol icmp
!
policy-map type inspect RouterToInternet
description Traffic Router to Internet
class type inspect DHCPv4
pass
class type inspect ROUTER
inspect
class class-default
drop
!
zone-pair security RouterToInternet source self destination Internet
service-policy type inspect RouterToInternet
!
ip access-list extended ALLOWv4
remark Pass DHCPv4 server traffic --> Lässt eingehend DHCP passieren
permit udp any eq bootps any eq bootpc
remark Pass IPsec VPN traffic
permit udp any any eq 1701
permit udp any any eq isakmp
permit udp any any eq non500-isakmp
permit esp any any
!
ip access-list extended DHCPv4
remark Pass DHCPv4 client traffic --> Lässt ausgehend DHCP passieren
permit udp any eq bootpc any eq bootps
!
Siehe dazu auch die hier.
Danke für diesen Hinweis eines wichtigen Punktes!! 👍
Das Tutorial hat jetzt einen entsprechenden Hinweis auf die DHCP Client Konfiguration des WAN Ports in Verbindung mit der Zone Based Firewall !
Die Lösung dafür ist sehr schnell gemacht in der ZBF Konfig.
Zur Erklärung:
Deine o.a. Class Map "DHCP" kann nicht greifen, da dies nur Traffic betrifft der die Firewall von Interface zu Interface bzw. richtiger gesagt: von Zone zu Zone passiert, was hier ja nicht der Fall ist, denn der DHCP Traffic betrifft einzig nur das eigene, lokale WAN Interface, ist also Router eigener Traffic, sprich Traffic der den Router direkt selber betrifft.
Die ZFW Firewall blockiert, prinzipbedingt, deshalb Broadcast Traffic der eigenen Interfaces wenn du mit inspect arbeitest !
Das resultiert dann darin, das Broadcast Traffic der eigenen Zone (self) ignoriert und damit geblockt wird ! Die Firewall ist da sehr streng, was sie ja auch sein soll ! 😉
Das siehst du auch wenn du am WAN Interface einmal mit einem Wireshark Sniffer mitsnifferst. Dort tauchen keinerlei DHCP Broadcast Requests des Cisco's bei aktiver ZBF auf. Ein sicheres Indiz das der DHCP Traffic durch die Firewall geblockt wird.
Sowie du aber die Traffic Inspection des eigenen Interfaces von inspect auf pass änderst funktioniert es dann fehlerlos !
Die pass Option blockiert im Gegensatz zur inspect Option keinen eigenen Broadcast Traffic.
Diese Änderung solltest du aber aus guten Gründen immer ausschliesslich nur an Interfaces machen die im DHCP Client Mode arbeiten !
PPPoE oder statische Interfaces sollten weiterhin immer mit inspect laufen ! Bei PPPoE gibt es kein DHCP bei IPv4.
Bei DHCPv6 funktioniert es übrigens deshalb immer im inspect Mode, weil DHCPv6 im Gegensatz zu IPv4 keinen Broadcast sondern Multicast für die DHCPv6 Adressvergabe nutzt.
So sollte die angepasste ZBF Konfig mit dem WAN Interface im DHCP Client Mode dann aussehen:
!
class-map type inspect match-all ALLOW_IN
match access-group name ALLOWv4
!
class-map type inspect match-any DHCPv4
match access-group name DHCPv4
!
class-map type inspect match-any ROUTER
match protocol tcp
match protocol udp
match protocol icmp
!
policy-map type inspect RouterToInternet
description Traffic Router to Internet
class type inspect DHCPv4
pass
class type inspect ROUTER
inspect
class class-default
drop
!
zone-pair security RouterToInternet source self destination Internet
service-policy type inspect RouterToInternet
!
ip access-list extended ALLOWv4
remark Pass DHCPv4 server traffic --> Lässt eingehend DHCP passieren
permit udp any eq bootps any eq bootpc
remark Pass IPsec VPN traffic
permit udp any any eq 1701
permit udp any any eq isakmp
permit udp any any eq non500-isakmp
permit esp any any
!
ip access-list extended DHCPv4
remark Pass DHCPv4 client traffic --> Lässt ausgehend DHCP passieren
permit udp any eq bootpc any eq bootps
!
cisco926(config)#
.Feb 22 2022 14:33:35 CET: %DHCP-6-ADDRESS_ASSIGN: Interface Gig 0/0/1 assigned DHCP address 82.57.12.123, mask 255.255.255.240, hostname cisco926
Danke für die schnelle Hilfe. Es hat erfolgreich funktioniert.
IPv6 gibt es es bei uns derzeit an diesem Anschluss noch nicht.
Vielen Dank nochmal an dich Aqui für die ausführliche Ergänzung in deinem perfekten Tutorial.
IPv6 gibt es es bei uns derzeit an diesem Anschluss noch nicht.
Vielen Dank nochmal an dich Aqui für die ausführliche Ergänzung in deinem perfekten Tutorial.
Immer gerne !
1
Hallo,
erst mal vielen Dank für die sehr gute und verständliche Anleitung.
Ich habe mir auch mal einen C1112-8p gegönnt, weil ich damals schon sehr gute Erfahrungen mit meinem alten Cisco 876W gemacht habe und ich diesen nur wegen VDSL tauschen musste. Bin dann zu einer Kombi Vigor und Mikrotik RB4011 gewechselt.
Jetzt bin ich günstig (ein mittlerer 3-stelliger Betrag ist schon günstig für so ein Teil) zu einen C1112-8P gekommen und wollte den jetzt als Router an einem 250Mbit Telekom Anschluss einsetzen. (die Vodafone Logins sind nur testweise drin!)
Kombi-Port GigabitEthernet0/0/0 hab ich mal nur so konfiguriert, um einen WAN-Port mit dhcp-Client zu haben. Hab ich ich noch nicht mal getestet.
Hier mal bisherige Config:
Folgendes ist mir aufgefallen.
1. ip virtual-reassembly in geht nicht......ip virtual-reassembly geht aber nicht in Kombination mit IN. Hat sich da was geändert mit IOS XE?
2. generell nicht ging der Befehl "switchport access XYZ" nicht.....hat er nicht gefunden in der IF-Config
Der Hammer war leider die komplett fehlende SPI Firewall im IPbase Paket - das kannte ich so nicht! Auch mein alter C876W hatte einen adv-security gleich mit drauf.
Das ist wirklich ein Armutszeugnis einen Internet SECURITY Router ohne Firewall zu verkaufen......das riecht verdammt nach Gewinnmaximierung. Ich dachte immer das verstecken neuer Images wäre bei Cisco schon schlimm genug.
ich weiß so nicht recht was ich machen soll - LC-1100-8P-SEC kostet mehr als mein Router gekostet hat......wahrscheinlich erst mal abwarten und suchen, wo es die für einen halbwegs vernünftigen Preis zu kaufen gibt.
Grüße
NG
erst mal vielen Dank für die sehr gute und verständliche Anleitung.
Ich habe mir auch mal einen C1112-8p gegönnt, weil ich damals schon sehr gute Erfahrungen mit meinem alten Cisco 876W gemacht habe und ich diesen nur wegen VDSL tauschen musste. Bin dann zu einer Kombi Vigor und Mikrotik RB4011 gewechselt.
Jetzt bin ich günstig (ein mittlerer 3-stelliger Betrag ist schon günstig für so ein Teil) zu einen C1112-8P gekommen und wollte den jetzt als Router an einem 250Mbit Telekom Anschluss einsetzen. (die Vodafone Logins sind nur testweise drin!)
Kombi-Port GigabitEthernet0/0/0 hab ich mal nur so konfiguriert, um einen WAN-Port mit dhcp-Client zu haben. Hab ich ich noch nicht mal getestet.
Hier mal bisherige Config:
Current configuration : 7924 bytes
!
! Last configuration change at 23:52:43 CEST Sun May 8 2022 by admin
!
version 16.10
service tcp-keepalives-in
service tcp-keepalives-out
service timestamps debug datetime msec
service timestamps log datetime msec
platform qfp utilization monitor load 80
no platform punt-keepalive disable-kernel-core
!
hostname M-Gateway
!
boot-start-marker
boot-end-marker
!
!
!
aaa new-model
!
!
aaa authentication login default local
aaa authorization network default local
!
!
!
!
!
aaa session-id common
clock timezone CET 1 0
clock summer-time CEST recurring last Sun Mar 2:00 last Sun Oct 3:00
call-home
! If contact email address in call-home is configured as sch-smart-licensing@cisco.com
! the email address configured in Cisco Smart License Portal will be used as contact email address to send SCH notifications.
contact-email-addr sch-smart-licensing@cisco.com
profile "CiscoTAC-1"
active
destination transport-method http
no destination transport-method email
no ip source-route
no ip gratuitous-arps
!
ip dhcp excluded-address 192.168.22.1 192.168.22.20
!
ip dhcp pool LANPool
import all
network 192.168.22.0 255.255.255.0
default-router 192.168.22.1
dns-server 192.168.22.1
!
!
!
!
login on-success log
!
!
!
!
!
!
subscriber templating
multilink bundle-name authenticated
!
!
!
crypto pki trustpoint TP-self-signed-3894276596
enrollment selfsigned
subject-name cn=IOS-Self-Signed-Certificate-3894276596
revocation-check none
rsakeypair TP-self-signed-3894276596
!
crypto pki trustpoint SLA-TrustPoint
enrollment pkcs12
revocation-check crl
!
!
crypto pki certificate chain TP-self-signed-3894276596
certificate self-signed 01
quit
crypto pki certificate chain SLA-TrustPoint
certificate ca 01
quit
!
license udi pid C1112-8P sn XXXXXXX
!
diagnostic bootup level minimal
!
spanning-tree extend system-id
!
!
username admin privilege 15 secret 9 XXXXXXXXX
!
redundancy
mode none
!
controller VDSL 0/2/0
!
!
vlan internal allocation policy ascending
!
!
!
!
!
interface GigabitEthernet0/0/0
description WAN (DHCP Client)
ip address dhcp
no ip redirects
no ip unreachables
no ip proxy-arp
ip nat outside
ip access-group 111 in
negotiation auto
no cdp enable
!
interface GigabitEthernet0/1/0
!
interface GigabitEthernet0/1/1
!
interface GigabitEthernet0/1/2
!
interface GigabitEthernet0/1/3
!
interface GigabitEthernet0/1/4
!
interface GigabitEthernet0/1/5
!
interface GigabitEthernet0/1/6
!
interface GigabitEthernet0/1/7
!
interface ATM0/2/0
no ip address
atm oversubscribe factor 2
no atm enable-ilmi-trap
!
interface Ethernet0/2/0
no ip address
no negotiation auto
!
interface Ethernet0/2/0.7
description DTAG-VDSL
encapsulation dot1Q 7
pppoe enable group global
pppoe-client dial-pool-number 1
!
interface Vlan1
description LAN-Ports
ip address 192.168.22.1 255.255.255.0
ip nat inside
ip tcp adjust-mss 1448
!
interface Dialer0
description DTAG-Einwahl
mtu 1488
ip address negotiated
no ip redirects
no ip unreachables
no ip proxy-arp
ip nat outside
ip access-group 111 in
encapsulation ppp
dialer pool 1
dialer-group 1
no cdp enable
no keepalive
ppp authentication pap chap callin
ppp chap hostname vodafone-vdsl.komplett/vb0000000000
ppp chap password XXXXXXXXX
ppp pap sent-username vodafone-vdsl.komplett/vb000000000 password XXXXXXX
ppp ipcp dns request
ppp ipcp mask request
ppp ipcp route default
!
ip forward-protocol nd
ip http server
ip http authentication local
ip http secure-server
ip dns server
ip nat inside source list 101 interface Dialer0 overload
!
!
access-list 23 permit 192.168.22.0 0.0.0.255
access-list 101 permit ip 192.168.22.0 0.0.0.255 any
access-list 111 deny icmp any any echo
access-list 111 deny icmp any any traceroute
access-list 111 deny icmp any any redirect
access-list 111 permit ip any any
dialer-list 1 protocol ip list 101
!
!
!
!
!
!
!
control-plane
!
!
line con 0
transport input none
stopbits 1
line vty 0 4
!
!
!
!
!
!
endFolgendes ist mir aufgefallen.
1. ip virtual-reassembly in geht nicht......ip virtual-reassembly geht aber nicht in Kombination mit IN. Hat sich da was geändert mit IOS XE?
2. generell nicht ging der Befehl "switchport access XYZ" nicht.....hat er nicht gefunden in der IF-Config
Der Hammer war leider die komplett fehlende SPI Firewall im IPbase Paket - das kannte ich so nicht! Auch mein alter C876W hatte einen adv-security gleich mit drauf.
Das ist wirklich ein Armutszeugnis einen Internet SECURITY Router ohne Firewall zu verkaufen......das riecht verdammt nach Gewinnmaximierung. Ich dachte immer das verstecken neuer Images wäre bei Cisco schon schlimm genug.
ich weiß so nicht recht was ich machen soll - LC-1100-8P-SEC kostet mehr als mein Router gekostet hat......wahrscheinlich erst mal abwarten und suchen, wo es die für einen halbwegs vernünftigen Preis zu kaufen gibt.
Grüße
NG
Zu den beiden Befehlen:
Was zeigt denn das Fragezeichen, wenn du es drückst nach jedem Wort des Befehls?
Dann kannst du schauen, ob sich ggf. die Syntax geändert hat oder die Funktion nicht geboten wird.
Zur FW: Das mögen zwar manche sicherlich nicht hören, aber in den meisten Netzen ist SPI in der Form gar nicht so dringend nötig. Bei IPv6 ist das zufällige Auffinden von Rechner praktisch unmöglich (das dauert halt ne halbe Ewigkeit). Bei IPv4 haben die meisten Netze NAT (und damit indirekt SPI). Zudem kann man die well-known-Ziel-Ports 1-1023 sperren, ggf. um die Registered Ports erweitern. man muss halt dann schauen, was nicht geht und da Ausnahmen erstellen (manche Linux-NTP-Deamons nutzen oft den NTP-Port als Quelle etc.). Sonst gilt bei mir eh die Grundregel: Ungewollte Netzwerkdienste werden am Rechner selbst abgestellt, eine FW ist maximal zusätzlicher Schutz.
Was zeigt denn das Fragezeichen, wenn du es drückst nach jedem Wort des Befehls?
Dann kannst du schauen, ob sich ggf. die Syntax geändert hat oder die Funktion nicht geboten wird.
Zur FW: Das mögen zwar manche sicherlich nicht hören, aber in den meisten Netzen ist SPI in der Form gar nicht so dringend nötig. Bei IPv6 ist das zufällige Auffinden von Rechner praktisch unmöglich (das dauert halt ne halbe Ewigkeit). Bei IPv4 haben die meisten Netze NAT (und damit indirekt SPI). Zudem kann man die well-known-Ziel-Ports 1-1023 sperren, ggf. um die Registered Ports erweitern. man muss halt dann schauen, was nicht geht und da Ausnahmen erstellen (manche Linux-NTP-Deamons nutzen oft den NTP-Port als Quelle etc.). Sonst gilt bei mir eh die Grundregel: Ungewollte Netzwerkdienste werden am Rechner selbst abgestellt, eine FW ist maximal zusätzlicher Schutz.
Zitat von @Windows10Gegner:
Zu den beiden Befehlen:
Was zeigt denn das Fragezeichen, wenn du es drückst nach jedem Wort des Befehls?
Dann kannst du schauen, ob sich ggf. die Syntax geändert hat oder die Funktion nicht geboten wird.
Zu den beiden Befehlen:
Was zeigt denn das Fragezeichen, wenn du es drückst nach jedem Wort des Befehls?
Dann kannst du schauen, ob sich ggf. die Syntax geändert hat oder die Funktion nicht geboten wird.
Ok, bei ip Virtual-Reassembly geht es weiter mit:
drop fragments
max- fragments (zahl)
reassembly-fragments (zahl)
percentage
timeoutDen Befehl switchport findet er nicht, was seltsam ist. Könnte das mit dem physischen Port Giga0/0/0 zusammenhängen? Ist ja ein OR Port RJ45/SFP.
Zur FW: Das mögen zwar manche sicherlich nicht hören, aber in den meisten Netzen ist SPI in der Form gar nicht so dringend nötig. Bei IPv6 ist das zufällige Auffinden von Rechner praktisch unmöglich (das dauert halt ne halbe Ewigkeit). Bei IPv4 haben die meisten Netze NAT (und damit indirekt SPI). Zudem kann man die well-known-Ziel-Ports 1-1023 sperren, ggf. um die Registered Ports erweitern. man muss halt dann schauen, was nicht geht und da Ausnahmen erstellen (manche Linux-NTP-Deamons nutzen oft den NTP-Port als Quelle etc.). Sonst gilt bei mir eh die Grundregel: Ungewollte Netzwerkdienste werden am Rechner selbst abgestellt, eine FW ist maximal zusätzlicher Schutz.
Ist ne Möglichkeit ja - trotzdem ist es irgendwie unmöglich sowas Grundlegendes für einen Router (bei einem Switch ist es ja Wurst) in den Bereich "musst du zukaufen" zu schieben. Das kenne ich auf von keinem anderen Hersteller. (Lancom macht es z.B. mit Anzahl von VPN-Tunneln und ALL-IP Lösungen als Aufpreis-Option)
Ist so nicht nachvollziehbar auf einer latest XE Gibraltar. Du bist vermutlich am falschen Interface?! Kann das sein?
interface GigabitEthernet0/1/7
description Gastnetz (VLAN 10)
switchport access vlan 10
switchport mode access
switchport nonegotiate
no mop enabled
no lldp transmit
no lldp receive
!
Works as designed !!! Das ist ein normales Feature der IP Base Version!
Virtual Reassembly ist immer Default in XE
https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipaddr_frre/configurat ...
Die T-Com PPPoE VDSL Konfig sieht inkl. Multicast (IP-TV) so aus: ##blue|
Auf den Umstand das mit den neuen ISR Modellen die Firewall Funktion CBAC oder ZFW lizenzpflichtig ist, wird oben im Tutorial und auch den Threadantworten mehrfach hingewiesen!
Du kannst aber problemlos erstmal mit inbound ACLs am Dialer arbeiten die dir alles wichtige vom Hals halten und den Rest erledigt die NAT Firewall. vty Access dann auch noch per ACL regeln was das System dann hinreichend sicher macht auch ohne CBAC oder ZFW.
interface GigabitEthernet0/1/7
description Gastnetz (VLAN 10)
switchport access vlan 10
switchport mode access
switchport nonegotiate
no mop enabled
no lldp transmit
no lldp receive
!
Works as designed !!! Das ist ein normales Feature der IP Base Version!
Virtual Reassembly ist immer Default in XE
https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipaddr_frre/configurat ...
Die T-Com PPPoE VDSL Konfig sieht inkl. Multicast (IP-TV) so aus: ##blue|
controller VDSL 0/2/0
!
no cdp run
lldp run
!
interface GigabitEthernet0/0/0
no ip address
shutdown
!
interface Ethernet0/2/0.7
description VDSL Modem T-Com
encapsulation dot1Q 7
pppoe enable group global
pppoe-client dial-pool-number 1
no lldp transmit
no lldp receive
!
interface Dialer0
description PPPoE Dialin T-Com VDSL
mtu 1488
ip address negotiated
no ip redirects
no ip unreachables
no ip proxy-arp
ip pim sparse-mode
ip nat outside
encapsulation ppp
ip igmp version 3
dialer pool 1
dialer-group 1
ipv6 address autoconfig default
ipv6 enable
ipv6 nd autoconfig default-route
no ipv6 redirects
no ipv6 unreachables
ipv6 dhcp client pd provider-v6-prefix rapid-commit
ipv6 dhcp client request vendor
ipv6 verify unicast reverse-path
ppp authentication pap callin
ppp pap sent-username 00123456789@t-online.de password Geheim123!
ppp ipcp dns request
ppp ipcp mask request
ppp ipcp route default Du kannst aber problemlos erstmal mit inbound ACLs am Dialer arbeiten die dir alles wichtige vom Hals halten und den Rest erledigt die NAT Firewall. vty Access dann auch noch per ACL regeln was das System dann hinreichend sicher macht auch ohne CBAC oder ZFW.
Zitat von @aqui:
Ist so nicht nachvollziehbar auf einer latest XE Gibraltar. Du bist vermutlich am falschen Interface?! Kann das sein?
interface GigabitEthernet0/1/7
description Gastnetz (VLAN 10)
switchport access vlan 10
switchport mode access
switchport nonegotiate
no mop enabled
no lldp transmit
no lldp receive
!
Ist so nicht nachvollziehbar auf einer latest XE Gibraltar. Du bist vermutlich am falschen Interface?! Kann das sein?
interface GigabitEthernet0/1/7
description Gastnetz (VLAN 10)
switchport access vlan 10
switchport mode access
switchport nonegotiate
no mop enabled
no lldp transmit
no lldp receive
!
Ja, ich bin auf GigabitEthernet0/0/0 nicht GigabitEthernet0/1/X
Works as designed !!! Das ist ein normales Feature der IP Base.
Virtual Reassembly ist Default in XE
https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipaddr_frre/configurat ...
Virtual Reassembly ist Default in XE
https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipaddr_frre/configurat ...
Ok, do show ip virtual-reassembly features sagt mir ist alles an auf diversen Interfaces.
Die T-Com PPPoE VDSL Konfig sieht inkl. Multicast (IP-TV) so aus:
!
controller VDSL 0/2/0
!
no cdp run
lldp run
!
interface GigabitEthernet0/0/0
no ip address
shutdown
!
interface Ethernet0/2/0.7
description VDSL Modem T-Com
encapsulation dot1Q 7
pppoe enable group global
pppoe-client dial-pool-number 1
no lldp transmit
no lldp receive
!
interface Dialer0
description PPPoE Dialin T-Com VDSL
mtu 1488
ip address negotiated
no ip redirects
no ip unreachables
no ip proxy-arp
ip pim sparse-mode
ip nat outside
encapsulation ppp
ip igmp version 3
dialer pool 1
dialer-group 1
ipv6 address autoconfig default
ipv6 enable
ipv6 nd autoconfig default-route
no ipv6 redirects
no ipv6 unreachables
ipv6 dhcp client pd provider-v6-prefix rapid-commit
ipv6 dhcp client request vendor
ipv6 verify unicast reverse-path
no keepalive
ppp authentication pap callin
ppp pap sent-username 00123456789@t-online.de password Geheim123!
ppp ipcp dns request
ppp ipcp mask request
ppp ipcp route default
!
!
controller VDSL 0/2/0
!
no cdp run
lldp run
!
interface GigabitEthernet0/0/0
no ip address
shutdown
!
interface Ethernet0/2/0.7
description VDSL Modem T-Com
encapsulation dot1Q 7
pppoe enable group global
pppoe-client dial-pool-number 1
no lldp transmit
no lldp receive
!
interface Dialer0
description PPPoE Dialin T-Com VDSL
mtu 1488
ip address negotiated
no ip redirects
no ip unreachables
no ip proxy-arp
ip pim sparse-mode
ip nat outside
encapsulation ppp
ip igmp version 3
dialer pool 1
dialer-group 1
ipv6 address autoconfig default
ipv6 enable
ipv6 nd autoconfig default-route
no ipv6 redirects
no ipv6 unreachables
ipv6 dhcp client pd provider-v6-prefix rapid-commit
ipv6 dhcp client request vendor
ipv6 verify unicast reverse-path
no keepalive
ppp authentication pap callin
ppp pap sent-username 00123456789@t-online.de password Geheim123!
ppp ipcp dns request
ppp ipcp mask request
ppp ipcp route default
!
Danke nochmal, werde wohl noch IPv6 und IGMP hinzufügen.
Auf den Umstand das mit den neuen ISR Modellen die Firewall Funktion CBAC oder ZFW lizenzpflichtig ist, wird oben im Tutorial und auch den Threadantworten mehrfach hingewiesen!
Bin wohl leider davon ausgegangen, dass dies nur für ZBF gilt.
Du kannst aber problemlos erstmal mit inbound ACLs am Dialer arbeiten die dir alles wichtige vom Hals halten und den Rest erledigt die NAT Firewall. vty Access dann auch noch per ACL regeln was das System dann hinreichend sicher macht auch ohne CBAC oder ZFW.
So werde ich es machen, SL-1100-8P-SEC Preise sind ganz schön heftig.
Bitte nicht immer alles überflüssigerweise zitieren! Das bläht das Tutorial nur unnötig auf.
Am internen Switch hängen einzig nur die 0/1/x Ports.
Das sieht man doch schon mit dem gesunden IT Verstand an der Modul Index Nummer der Ports.
Hättest du nur einmal einen Blick in den Hardware Implementation Guide zum 1100er geworfen wäre dieser Punkt überflüssig gewesen. 🧐
Eigentlich auch unverständlich wenn du schon Cisco 880er Erfahrungen hast....
Ja, ich bin auf GigabitEthernet0/0/0 nicht GigabitEthernet0/1/X
Oh man...der Hardware Guide lässt grüßen. 🙄 Interface 0/0/0 ist ein dediziert gerouteter Port der NICHT am internen Switch hängt!!! Folglich sind dort auch keine L2 Switching Funktionen verfügbar. Logisch...Am internen Switch hängen einzig nur die 0/1/x Ports.
Das sieht man doch schon mit dem gesunden IT Verstand an der Modul Index Nummer der Ports.
Hättest du nur einmal einen Blick in den Hardware Implementation Guide zum 1100er geworfen wäre dieser Punkt überflüssig gewesen. 🧐
Eigentlich auch unverständlich wenn du schon Cisco 880er Erfahrungen hast....
und IGMP hinzufügen.
Wenn du kein Magenta TV (IP-TV) hast kannst du das weglassen.
Hallo,
einen Cisco 880er hatte ich nie in der Hand und das mit dem 876W ist ca. 15 Jahre her.
Dedizierter Port stimmt wohl, aber wie würde die Config dazu aussehen? Die Anleitung oben zum WAN Port am Anschluss an ein Kabelmodem macht so ja keinen Sinn.
einen Cisco 880er hatte ich nie in der Hand und das mit dem 876W ist ca. 15 Jahre her.
Dedizierter Port stimmt wohl, aber wie würde die Config dazu aussehen? Die Anleitung oben zum WAN Port am Anschluss an ein Kabelmodem macht so ja keinen Sinn.
und das mit dem 876W ist ca. 15 Jahre her.
IOS Syntax ist überall gleich ! 😉aber wie würde die Config dazu aussehen?
WAS willst du denn auf dem Port machen? VLAN Tagging? Wenn ja, machst du das auf einem Routing Port mit Subinterfaces. Hier ein Beispiel für die VLANs 10 und 20: int gi0/0/0.10
description Tagged VLAN 10
encap dot1q 10
ip address x.x.10.254 255.255.255.0
!
int gi0/0/0.20
description Tagged VLAN 20
encap dot1q 20
ip address x.x.20.254 255.255.255.0
am Anschluss an ein Kabelmodem macht so ja keinen Sinn.
Nein, das ist in der Tat dann völlig sinnfrei. Der Router ist ja oben auch als VDSL Router konfiguriert!Willst du denn zwei WAN Ports betreiben also einen Dual WAN Router??
Ist wenig zielführend wenn man dir alles einzeln aus der Nase ziehen muss.
Besser auch du eröffnest einen neuen Thread dafür und referenzierst hier darauf um das Tutorial hier nicht mit speziellen Konfig Fragen weiter aufzublähen.
Ein paar Ergänzungen seitens mir:
Ich habe im C886VA-W einen AP802GN-E-K9.
Das Default-Passwort ist da:
User: Cisco
Kennwort: Cisco
enable-PW: Cisco
Reset geht wie folgt:
service-module wlan-ap 0 reset default-config
service-module wlan-ap 0 reset bootloader #bootet in den ROMMON des AP
Im ROMMON des AP die Konfigs auf dem Flash ansehen und ggf. löschen.
dir flash:
delete flash:/datei
Dann boot
und einloggen mit den Zugangsdaten von oben.
Ich habe im C886VA-W einen AP802GN-E-K9.
Das Default-Passwort ist da:
User: Cisco
Kennwort: Cisco
enable-PW: Cisco
Reset geht wie folgt:
service-module wlan-ap 0 reset default-config
service-module wlan-ap 0 reset bootloader #bootet in den ROMMON des AP
Im ROMMON des AP die Konfigs auf dem Flash ansehen und ggf. löschen.
dir flash:
delete flash:/datei
Dann boot
und einloggen mit den Zugangsdaten von oben.
1
Hallo zusammen,
bin neu hier im Forum und habe ein Problemchen mit meinem 896vag.
Ich habe das Gerät laut deinem Tutorial konfiguriert aber bekomme keine Verbindung ins Internet hin.
Ich sehe zwar auf dem vdsl Controller die verfügbare Geschwindigkeit und bekomme auch eine Internet IP über sh ip int brief angezeigt aber kann z.b. Google nicht anpingen. (intern funktioniert Ping) Ebenso bekomme ich auch eine IP vom DHCP zugewiesen. Der Anschluss ist 1und1 DSL Anschluss an einem Telekom DSLAM. Nachfolgend meine Running-Config.
Kann mir jemand sagen wo der Fehler liegt? Steh grad total aufm Kabel.
bin neu hier im Forum und habe ein Problemchen mit meinem 896vag.
Ich habe das Gerät laut deinem Tutorial konfiguriert aber bekomme keine Verbindung ins Internet hin.
Ich sehe zwar auf dem vdsl Controller die verfügbare Geschwindigkeit und bekomme auch eine Internet IP über sh ip int brief angezeigt aber kann z.b. Google nicht anpingen. (intern funktioniert Ping) Ebenso bekomme ich auch eine IP vom DHCP zugewiesen. Der Anschluss ist 1und1 DSL Anschluss an einem Telekom DSLAM. Nachfolgend meine Running-Config.
no ip source-route
no ip gratuitous-arps
!
!
!
!
!
!
!
!
!
!
!
ip dhcp excluded-address 10.10.10.1
ip dhcp excluded-address 192.168.0.1 192.168.0.20
ip dhcp excluded-address 192.168.0.200 192.168.0.254
!
ip dhcp pool cvo-pool
import all
network 10.10.10.0 255.255.255.248
default-router 10.10.10.1
lease 0 2
!
ip dhcp pool Lokal
network 192.168.0.0 255.255.255.0
default-router 192.168.0.1
dns-server 192.168.0.1
domain-name meinedomain.home.arpa
!
!
!
no ip domain lookup
ip domain name meinedomain.home.arpa
ip inspect name DEFAULT100 ftp
ip inspect name DEFAULT100 h323
ip inspect name DEFAULT100 icmp
ip inspect name DEFAULT100 netshow
ip inspect name DEFAULT100 rcmd
ip inspect name DEFAULT100 realaudio
ip inspect name DEFAULT100 rtsp
ip inspect name DEFAULT100 esmtp
ip inspect name DEFAULT100 sqlnet
ip inspect name DEFAULT100 streamworks
ip inspect name DEFAULT100 tftp
ip inspect name DEFAULT100 tcp
ip inspect name DEFAULT100 udp
ip inspect name DEFAULT100 vdolive
ip cef
ipv6 flowset
ipv6 unicast-routing
ipv6 cef
ipv6 dhcp pool DHCPv6
import dns-server
domain-name meinedomain.home.arpa
!
!
!
!
!
!
multilink bundle-name authenticated
!
!
!
!
!
!
!
license udi pid C896VAG-LTE-GA-K9 sn FCZ2130901V
!
!
vtp mode transparent
vtp version 2
username cisco privilege 15 secret x xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
username xxxxx privilege 15 secret x xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
!
redundancy
!
!
!
!
!
controller VDSL 0
!
controller Cellular 0
lte gps enable
!
!
!
interface ATM0
no ip address
no ip redirects
no ip unreachables
no ip proxy-arp
ip flow ingress
shutdown
no atm ilmi-keepalive
pvc 1/32
bridge-dot1q encap 7
pppoe-client dial-pool-number 1
!
!
interface ATM0.1 point-to-point
no ip redirects
no ip unreachables
no ip proxy-arp
ip flow ingress
!
interface Cellular0
no ip address
encapsulation slip
!
interface Cellular1
no ip address
encapsulation slip
!
interface Ethernet0
no ip address
no ip route-cache
!
interface Ethernet0.7
description VDSL Internet Verbindung - VLAN 7 tagged
encapsulation dot1Q 7
no ip route-cache
pppoe enable group global
pppoe-client dial-pool-number 1
!
interface GigabitEthernet0
description Homenetzwerk
switchport mode trunk
no ip address
no cdp enable
spanning-tree portfast
!
interface GigabitEthernet1
no ip address
spanning-tree portfast
!
interface GigabitEthernet2
no ip address
spanning-tree portfast
!
interface GigabitEthernet3
no ip address
spanning-tree portfast
!
interface GigabitEthernet4
no ip address
spanning-tree portfast
!
interface GigabitEthernet5
no ip address
spanning-tree portfast
!
interface GigabitEthernet6
no ip address
spanning-tree portfast
!
interface GigabitEthernet7
no ip address
spanning-tree portfast
!
interface GigabitEthernet8
description $ES_WAN$$FW_OUTSIDE$
no ip dhcp client request tftp-server-address
ip address dhcp
ip access-group 101 in
no ip redirects
no ip unreachables
no ip proxy-arp
ip flow ingress
ip nat outside
ip inspect DEFAULT100 out
ip virtual-reassembly in
duplex auto
speed auto
media-type rj45
!
interface Vlan1
description Lokales LAN
ip address 192.168.0.1 255.255.255.0
ip nat inside
ip virtual-reassembly in
ip tcp adjust-mss 1448
ipv6 address provider-v6-prefix 2001::1/64
ipv6 enable
ipv6 nd other-config-flag
ipv6 dhcp server DHCPv6
!
interface Dialer0
description xDSL Einwahl Interface Internet
mtu 1492
ip address negotiated
no ip redirects
no ip unreachables
no ip proxy-arp
ip pim sparse-mode
ip nat outside
ip virtual-reassembly in
encapsulation ppp
ip igmp version 3
dialer pool 1
dialer-group 1
no cdp enable
ipv6 address autoconfig default
ipv6 enable
ipv6 nd autoconfig default-route
no ipv6 redirects
no ipv6 unreachables
ipv6 verify unicast reverse-path
ipv6 dhcp client pd provider-v6-prefix rapid-commit
ipv6 dhcp client request vendor
no keepalive
ppp authentication pap callin
ppp pap sent-username H1und1/xxxxxxxxx@online.de password x xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
ppp ipcp dns request
ppp ipcp mask request
ppp ipcp route default
!
ip forward-protocol nd
ip http server
ip http access-class 23
ip http authentication local
ip http secure-server
ip http timeout-policy idle 60 life 86400 requests 10000
!
!
ip dns server
ip nat inside source list 1 interface GigabitEthernet8 overload
ip nat inside source list 101 interface Dialer0 overload
ip ssh time-out 30
ip ssh version 2
!
dialer-list 1 protocol ip list 101
ipv6 ioam timestamp
!
access-list 1 permit 10.10.10.0 0.0.0.7
access-list 23 permit 10.10.10.0 0.0.0.7
access-list 23 permit 0.0.0.0 255.255.255.0
access-list 100 deny ip host 255.255.255.255 any
access-list 100 deny ip 127.0.0.0 0.255.255.255 any
access-list 100 permit ip any any
access-list 101 permit udp any eq bootps any eq bootpc
access-list 101 deny ip 10.10.10.0 0.0.0.255 any
access-list 101 permit icmp any any echo-reply
access-list 101 permit icmp any any time-exceeded
access-list 101 permit icmp any any unreachable
access-list 101 deny ip 10.0.0.0 0.255.255.255 any
access-list 101 deny ip 172.16.0.0 0.15.255.255 any
access-list 101 deny ip 192.168.0.0 0.0.255.255 any
access-list 101 deny ip 127.0.0.0 0.255.255.255 any
access-list 101 deny ip host 255.255.255.255 any
access-list 101 deny ip any any
access-list 101 permit ip 192.168.0.0 0.0.0.255 any
!
control-plane
!
!
!
mgcp behavior rsip-range tgcp-only
mgcp behavior comedia-role none
mgcp behavior comedia-check-media-src disable
mgcp behavior comedia-sdp-force disable
!
mgcp profile default
!Kann mir jemand sagen wo der Fehler liegt? Steh grad total aufm Kabel.
Ist das wirklich so eingestellt?
ipv6 address provider-v6-prefix 2001::1/64
Zeige sh ipv6 int brief
Geht der Ping vom Cisco raus?
Dann ist es ggf. ein Problem mit Routing oder Firewall.
Teste IPv4 und IPv6 getrennt. Ich würde mit IPv6 anfangen, da hat man kein NAT.
ipv6 address provider-v6-prefix 2001::1/64
Zeige sh ipv6 int brief
Geht der Ping vom Cisco raus?
Dann ist es ggf. ein Problem mit Routing oder Firewall.
Teste IPv4 und IPv6 getrennt. Ich würde mit IPv6 anfangen, da hat man kein NAT.
1
Hallo,
danke erstmal für deine schnelle Antwort. Nachfolgend die Informationen aus meinem Router.
Die Adresse 172.217.30.9 soll eine von Google sein.
danke erstmal für deine schnelle Antwort. Nachfolgend die Informationen aus meinem Router.
ciscorouter#sh ip int brief
Interface IP-Address OK? Method Status Protocol
ATM0 unassigned YES NVRAM administratively down down
ATM0.1 unassigned YES unset administratively down down
Cellular0 unassigned YES unset down down
Cellular1 unassigned YES unset down down
Dialer0 79.192.221.83 YES IPCP up up
Ethernet0 unassigned YES NVRAM up up
Ethernet0.7 unassigned YES unset up up
GigabitEthernet0 unassigned YES unset up up
GigabitEthernet1 unassigned YES unset down down
GigabitEthernet2 unassigned YES unset down down
GigabitEthernet3 unassigned YES unset down down
GigabitEthernet4 unassigned YES unset down down
GigabitEthernet5 unassigned YES unset down down
GigabitEthernet6 unassigned YES unset down down
GigabitEthernet7 unassigned YES unset down down
GigabitEthernet8 unassigned YES NVRAM down down
NVI0 21.21.21.1 YES unset up up
Virtual-Access1 unassigned YES unset up up
Virtual-Access2 unassigned YES unset up up
Vlan1 192.168.0.1 YES NVRAM up up
ciscorouter#sh ipv6 int brief
ATM0 [administratively down/down]
unassigned
ATM0.1 [administratively down/down]
unassigned
Cellular0 [down/down]
unassigned
Cellular1 [down/down]
unassigned
Dialer0 [up/up]
FE80::4201:7AFF:FE9F:EF20
2003:F1:77FF:35FD:4201:7AFF:FE9F:EF20
Ethernet0 [up/up]
unassigned
Ethernet0.7 [up/up]
unassigned
GigabitEthernet0 [up/up]
unassigned
GigabitEthernet1 [down/down]
unassigned
GigabitEthernet2 [down/down]
unassigned
GigabitEthernet3 [down/down]
unassigned
GigabitEthernet4 [down/down]
unassigned
GigabitEthernet5 [down/down]
unassigned
GigabitEthernet6 [down/down]
unassigned
GigabitEthernet7 [down/down]
unassigned
GigabitEthernet8 [down/down]
unassigned
NVI0 [up/up]
unassigned
Virtual-Access1 [up/up]
unassigned
Virtual-Access2 [up/up]
FE80::4201:7AFF:FE9F:EF20
Vlan1 [up/up]
FE80::4201:7AFF:FE9F:EF1C
2003:F1:7735:DA00::
2003:F1:7735:DA00::1
ciscorouter#ping 172.217.30.9
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.217.30.9, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)Die Adresse 172.217.30.9 soll eine von Google sein.
Bitte mache dafür einen neuen, separaten Thread im Forum auf mit einem hiesigen URL Vermerk um das Tutorial hier nicht unnötig mit Troubleshooting Sessions aufzublähen!!
Vorab:
Kollege @Windows10Gegner hat hier recht das die IPv6 Konfig im lokalen LAN schonmal grundfalsch ist. Niemals kannst du dann den Prefix fest einstellen!!
Das darf immer nur OHNE Prefix ala ipv6 address provider-v6-prefix ::1:0:0:0:1/64 definiert sein.
Gehe immer strategisch vor!!
IPv4 und v6 Adressen vom Internet Provider hast du ja bekommen, die Internetverbindung an sich ist also da. Würdest du auch sehen wenn du mal direkt auf dem CLI z.B. 8.8.8.8 pingst mit ping 8.8.8.8 source dialer0!
Bitte, wie gesagt, alles in einem separaten Thread!
Vorab:
Kollege @Windows10Gegner hat hier recht das die IPv6 Konfig im lokalen LAN schonmal grundfalsch ist. Niemals kannst du dann den Prefix fest einstellen!!
Das darf immer nur OHNE Prefix ala ipv6 address provider-v6-prefix ::1:0:0:0:1/64 definiert sein.
Gehe immer strategisch vor!!
- Lese das Tutorial und folge den Anweisungen bitte genau! Deine Konfig Fehler zeigen das du nicht wirklich auf die Details und Anmerkungen geachtet hast.
- Betreibe den Router zuallererst OHNE aktive Firewall um sicherzustellen das das Grundsetup sauber rennt! Immer erst danach die FW aktivieren. So stellt man sicher das etwaige Konfig Fehler nur an der Firewall liegen können.
- Entferne unbedingt überflüssige und verwirrende Konfig "Leichen" wie z.B. description $ES_WAN$$FW_OUTSIDE$ usw. die von Autokonfig Frickeltools kommen. (Das geht immer mit einem "no" vor dem Kommando)
- Setze nicht aktive Interfaces in shutdown
- Setze entspr. Descriptions damit Helfende verstehen um welche Interfaces es geht
- Poste KEINE sinnlosen "!" oder überflüssige Leerzeilen die die Konfig unnötig aufblähen und unübersichtlich machen und setze die Konfig bitte immer in Code Tags!!
- Dein Kardinalsfehler ist aber das du die Dialer Listen für das NAT verwechselt hast. 101 ist eine Liste für ein Ethernet Interface (Bootp, DHCP usw. gibt es alles bei einem PPPoE Dialer Interface NICHT!) liegt aber auf dem Dialer und 1 ist eine Liste für ein Dialer Interface, liegt bei dir aber auf dem Ethernet Interface.
IPv4 und v6 Adressen vom Internet Provider hast du ja bekommen, die Internetverbindung an sich ist also da. Würdest du auch sehen wenn du mal direkt auf dem CLI z.B. 8.8.8.8 pingst mit ping 8.8.8.8 source dialer0!
Bitte, wie gesagt, alles in einem separaten Thread!
Hallo Aqui,
Ja, self Zone ist dabei. Nur vergessen. War ja nur eine.
Gescannt habe ich von internen WLAN aus und ja, der dns server auf dem Cisco Router ist aktiv.
Das klingt logisch das ich dann den offenen Port finde.
Jetzt habe ich einen Scan über das Mobilfunknetz gemacht, und da ist kein offener Port 53 zu sehen nur diese.
Hier nochmal die Konfig:
Gruß
wissens-hunger
Ja, self Zone ist dabei. Nur vergessen. War ja nur eine.
Gescannt habe ich von internen WLAN aus und ja, der dns server auf dem Cisco Router ist aktiv.
Das klingt logisch das ich dann den offenen Port finde.
Jetzt habe ich einen Scan über das Mobilfunknetz gemacht, und da ist kein offener Port 53 zu sehen nur diese.
Not shown: 997 filtered tcp ports (no-response)
PORT STATE SERVICE VERSION
135/tcp closed msrpc
139/tcp closed netbios-ssn
445/tcp closed microsoft-dsHier nochmal die Konfig:
ip dns server
!
access-list 101 permit ip 192.168.100.0 0.0.0.255 any
access-list 101 permit ip 192.168.101.0 0.0.0.255 any
!
zone security Internet
zone security Kabel
zone security WLAN
!
class-map type inspect match-any Router-Protocols-Erlaubt
match protocol tcp
match protocol udp
match protocol icmp
!
class-map type inspect match-any Kabel-Erlaubt
match protocol dns
match protocol http
match protocol https
match protocol pop3s
match protocol pop3
match protocol imaps
match protocol imap3
match protocol imap
match protocol smtp
match protocol rtsp
match protocol ftp
match protocol ftps
match protocol ssh
match protocol ntp
match protocol tftp
match protocol tcp
match protocol udp
match protocol icmp
!
class-map type inspect match-any WLAN-Erlaubt
match protocol dns
match protocol http
match protocol https
match protocol pop3s
match protocol pop3
match protocol imaps
match protocol imap3
match protocol imap
match protocol smtp
match protocol rtsp
match protocol ftp
match protocol ftps
match protocol ssh
match protocol ntp
match protocol tftp
match protocol tcp
match protocol udp
match protocol icmp
!
policy-map type inspect Router-WAN-Policy
description Traffic Router zum Internet
class type inspect Router-Protocols-Erlaubt
inspect
class class-default
drop
!
policy-map type inspect Kabel-Policy
description Traffic Kabel zum Internet
class type inspect Kabel-Erlaubt
inspect
class class-default
drop
!
zone-pair security Router-Internet source self destination Internet
service-policy type inspect Router-WAN-Policy
!
zone-pair security Kabel-Internet source Kabel destination Internet
service-policy type inspect Kabel-Policy
!
zone-pair security WLAN-Internet source WLAN destination Internet
service-policy type inspect WLAN-PolicyGruß
wissens-hunger
Auch hier gilt was oben schon geschrieben wurde!!:
Bitte mache dafür einen neuen, separaten Thread im Forum auf mit einem hiesigen URL Vermerk um das Tutorial hier nicht unnötig mit Troubleshooting Sessions aufzublähen!!
Nur so viel:
Beides wäre aber besonders fatal, denn Ports wie die o.a. RPC (135), SMB (139, 445) hat in öffentlichen IP Netzen nichts zu suchen weil vollständig ungeschützt. SMB über das Internet zu übertragen ohne VPN ist absolut fahrlässig.
Wie bereits gesagt: Bitte einen separaten Thread dafür aufmachen und ohne die vollständige anonymisierte Konfig kommen wir nicht weiter.
Bitte mache dafür einen neuen, separaten Thread im Forum auf mit einem hiesigen URL Vermerk um das Tutorial hier nicht unnötig mit Troubleshooting Sessions aufzublähen!!
Nur so viel:
Das klingt logisch das ich dann den offenen Port finde.
So ist es! 😉und da ist kein offener Port 53 zu sehen nur diese.
Das wäre fatal, denn das sind SMB Ports die im Internet nichts zu suchen haben. Man kann hier nur mutmaßen das du aktive SMB Sessions ins Internet hast oder mit Port Forwarding arbeitest. Ist jetzt aber nur alles im freien Fall geraten weil Informationen fehlenBeides wäre aber besonders fatal, denn Ports wie die o.a. RPC (135), SMB (139, 445) hat in öffentlichen IP Netzen nichts zu suchen weil vollständig ungeschützt. SMB über das Internet zu übertragen ohne VPN ist absolut fahrlässig.
Wie bereits gesagt: Bitte einen separaten Thread dafür aufmachen und ohne die vollständige anonymisierte Konfig kommen wir nicht weiter.
Interessant wäre noch, wie man DS-Lite mit dem Tunnel zum AFTR-Gateway einrichtet.
dialer-list 1 protocol ip list 101 <-- NAT für die IP Netze in ACL 101 erlauben
Laut Cisco hat das gar nichts mit NAT zu tun, sondern damit, dass automatisch die PPP-Verbindung aufgebaut werden soll.https://www.cisco.com/c/en/us/td/docs/ios/dial/command/reference/dia-cr- ...
Braucht man das denn noch bei DSL & Co?
Da ist eigentlich PPP immer aufgebaut.
Da hast du natürlich Recht und danke für das Feedback! Wird in der Formulierung angepasst!
Damit also überhaupt erstmal der PPPoE Tunnel aufgebaut werden kann ist dieses Kommando essentiell. Ohne das würde der Tunnel niemals zustandekommen.
Aller weiterer Traffic retriggert dann immer den PPP Timer so das der Tunnel dann weiter permanent offen bleibt.
Braucht man das denn noch bei DSL & Co? Da ist eigentlich PPP immer aufgebaut.
Ja brauchst du immer und ist Standard bei allen PPP (Dialer) basierten Interfaces, denn damit wird definiert welcher IP Traffic den PPP bzw. PPPoE Prozess triggert. Bedeutet dann hier gemäß Accesslist 101 das aller Traffic der von den Absender IPs 192.168.100.x oder 172.16.100.x kommt und zu jeder beliebigen anderen IP Adresse (Internet) geht den PPPoE Prozess triggert und damit den PPPoE Tunnel zum Provider aufbaut.Damit also überhaupt erstmal der PPPoE Tunnel aufgebaut werden kann ist dieses Kommando essentiell. Ohne das würde der Tunnel niemals zustandekommen.
Aller weiterer Traffic retriggert dann immer den PPP Timer so das der Tunnel dann weiter permanent offen bleibt.
Dann müsste man das ja eigentlich auch für IPv6 eintragen, oder nicht?
Gibt es eine Option, PPP immer aufzubauen, egal ob Traffic raus soll oder nicht?
Für mich sieht dieses Kommando nach einem Relikt aus einer Zeit aus, in der die Verbindungen nur bei Bedarf aufgebaut wurden.
Gibt es eine Option, PPP immer aufzubauen, egal ob Traffic raus soll oder nicht?
Für mich sieht dieses Kommando nach einem Relikt aus einer Zeit aus, in der die Verbindungen nur bei Bedarf aufgebaut wurden.
Da hast du Recht!
In einem Dual Stack Szenario ist das nicht ganz so relevant weil der v4 Traffic das PPP Dialin schon triggert aber in einem reinen v6 Design ist es dann zwingend. Wird entsprechend oben korrigiert. 😉
Den Sinn bzw. die Aktualität des PPP Protokolls und dessen Einsatzzweck verändert das ja keineswegs, im Gegenteil.
In einem Dual Stack Szenario ist das nicht ganz so relevant weil der v4 Traffic das PPP Dialin schon triggert aber in einem reinen v6 Design ist es dann zwingend. Wird entsprechend oben korrigiert. 😉
aus einer Zeit aus, in der die Verbindungen nur bei Bedarf aufgebaut wurden.
Das kann man so und so sehen. Auf der einen Seite ja, denn PPP ist dafür extra ja ausgelegt gewesen. Es gibt ja auch noch einen Keepalive Timer der die PPP Session bei Inaktivität abbaut. Alternativ wenn ein bestimmtes Volumen erreicht ist. Das war dem Umstand gezollt das sowas früher alles kostenpflichtig war was heutzutage natürlich obsolet ist.Den Sinn bzw. die Aktualität des PPP Protokolls und dessen Einsatzzweck verändert das ja keineswegs, im Gegenteil.
Das Keepalive wegzulassen hat bei mir den Effekt, dass nach einigen Tagen der Tunnel tot ist, beim ISP wohl kurz auf down geht (ist eigentlich kein Vertrag mit Zwangstrennung bei TAL.de), im Router aber aktiv bleibt.
Mit aktivem Keepalive geht dann der Router auch down und baut den sofort wieder auf.
Mit aktivem Keepalive geht dann der Router auch down und baut den sofort wieder auf.
Du hast Recht, die Keepalives auf dem Dialer Interface dürfen deshalb bei PPPoE keinesfalls weggelassen werden und sollten immer auf dem Defaultwert bleiben! Das ist in der o.a. Konfig auch berücksichtigt.
Da steht aber massenhaft no keepalive im Dialer0
Danke für den Hinweis! 👍
Sollte nun vollständig aus dem Tutorial und den eigenen Kommentaren getilgt sein. Auch entsprechende Texte in den Antwortthreads sind jetzt diesbezüglich korrigiert.
Sollte nun vollständig aus dem Tutorial und den eigenen Kommentaren getilgt sein. Auch entsprechende Texte in den Antwortthreads sind jetzt diesbezüglich korrigiert.
Die reguläre Annex-B-Variante Cisco C886VA-K9 ist auch voll am Annex-J-fähigen Anschluß funktionsfähig, mit geringfügig reduziertem Upstream. Ebenso die Annex A Variante.
Funktioniert die Annex-A-Variante wirklich an Annex-B-ADSL-DSLAMs? Nach meinem Kenntnisstand wurde sowas nie angeboten und die DSLAMs haben hier immer Annex B gemacht - ein Annex A-ADSL-Modem würde daher nicht funktionieren.
Funktionieren die Annex-A-VDSL-Modelle in Deutschland am VDSL?
Das funktioniert bei ADSL. Allerdings nur mit einer reduzierten Bandbreite da das B Modemspektrum bzw. Frequenzband deutlich kleiner ist.
https://de.wikipedia.org/wiki/G.992.1#Annex_B
Bei VDSL2 wird lediglich die Region festgelegt. Die verwendeten Frequenzbereiche werden da jedoch vom VDSL2-Profil bestimmt und nicht vom Annex wie bei ADSL.
https://de.wikipedia.org/wiki/G.992.1#Annex_B
Bei VDSL2 wird lediglich die Region festgelegt. Die verwendeten Frequenzbereiche werden da jedoch vom VDSL2-Profil bestimmt und nicht vom Annex wie bei ADSL.
Und trotz dass das bei VDSL nur die Region beschreibt, funktioniert das an hiesigen DSLAMs?
Können dann beide Varianten alle VDSL-Profile?
Wieso gibt es dann mehrere Bauarten von Cisco?
Können dann beide Varianten alle VDSL-Profile?
Wieso gibt es dann mehrere Bauarten von Cisco?
Bei VDSL-2 ist das so, da zählt nur das Profil. Mehrere Bauarten gibt es weil nicht alle embeddete Modems G.fast supporten. Da muss man aufs Kleingedruckte sprich Datenblatt achten.
Ich habe neuerdings das Problem, das mein Media Receiver 401 Typ B gelegentlich versucht ein Update zu laden. Der Updatevorgang schlägt fehl. Der MR kann scheinbar den Update Server nicht erreichen und bleibt dann in einer Update Schleife hängen, bis ich den kurz über einen Speedport Router online bringe.
Kennt hier jemand dieses Problem und hat vielleicht schon eine Lösung gefunden?
Ich habe gerade mal per Wireshark geschaut was da passiert wenn der MR über den Speedport online geht.
Der scheint sein Update von apptmufk20010.prod.sngtv.t-online.de / 62.155.248.211 zu ziehen. Ich warte jetzt darauf das mein MR irgendwann wieder ein Update ziehen will und dann schaue ich mal was passiert. Ich bekomme von meinem Cisco Router jedenfalls kein ICMP zu diesem Host und ein Traceroute läuft nach zwei Hops ins leere.
Kennt hier jemand dieses Problem und hat vielleicht schon eine Lösung gefunden?
Ich habe gerade mal per Wireshark geschaut was da passiert wenn der MR über den Speedport online geht.
Der scheint sein Update von apptmufk20010.prod.sngtv.t-online.de / 62.155.248.211 zu ziehen. Ich warte jetzt darauf das mein MR irgendwann wieder ein Update ziehen will und dann schaue ich mal was passiert. Ich bekomme von meinem Cisco Router jedenfalls kein ICMP zu diesem Host und ein Traceroute läuft nach zwei Hops ins leere.
Liegt nicht an deiner Konfiguration, passiert hier auch (tcptraceroute) und ich blockiere kein ICMP/ICMPv6.
Stimmt, passiert auch an einem Cisco freien Anschluss bei Speedport und Co. Hat mit dem Cisco nichts zu tun.
Moin,
erstmal Herzlichen Dank für diese richtig schöne Anleitung.
Ich verwende den "Cisco - C896VA-K9 - Cisco 896 VDSL2/ADSL2+ over ISDN and 1GE/SFP Sec Router"
Mein Provider ist 1&1 mit DSL 250 Vertrag (VDSL2) (kein Business)
Nach dem ich die Anleitung durchgearbeitet habe hat die Einwahl auf Anhieb geklappt. Doch wenn ich die Bandbreite messe, komme ich nur knapp über 17 Mbps Download und 1.47 Mbps Upload.
Mit der FritzBox habe ich volle 250 Download und knapp 50 Mbps Upload.
Was habe ich falsch gemacht?
Vielen Dank im Vorraus!
Hier ist meine Config:
Hier ist die Config des VDSL Controllers:
erstmal Herzlichen Dank für diese richtig schöne Anleitung.
Ich verwende den "Cisco - C896VA-K9 - Cisco 896 VDSL2/ADSL2+ over ISDN and 1GE/SFP Sec Router"
Mein Provider ist 1&1 mit DSL 250 Vertrag (VDSL2) (kein Business)
Nach dem ich die Anleitung durchgearbeitet habe hat die Einwahl auf Anhieb geklappt. Doch wenn ich die Bandbreite messe, komme ich nur knapp über 17 Mbps Download und 1.47 Mbps Upload.
Mit der FritzBox habe ich volle 250 Download und knapp 50 Mbps Upload.
Was habe ich falsch gemacht?
Vielen Dank im Vorraus!
Hier ist meine Config:
service tcp-keepalives-in
service tcp-keepalives-out
service timestamps debug datetime localtime
service timestamps log datetime localtime show-timezone year
!
hostname RT01
!
boot-start-marker
boot-end-marker
!
!
security authentication failure rate 3 log
security passwords min-length 7
enable secret 9 <secret>
!
!
aaa new-model
aaa local authentication attempts max-fail 3
!
!
aaa authentication login default local
aaa authorization network default local
!
!
!
!
!
aaa session-id common
clock timezone CET 1 0
clock summer-time CEST recurring last Sun Mar 2:00 last Sun Oct 3:00
!
!
no ip source-route
no ip gratuitous-arps
ip cef
!
!
!
!
!
ip dhcp relay information trust-all
ip dhcp binding cleanup interval 180
ip dhcp excluded-address 192.168.100.1 192.168.100.50
!
ip dhcp pool Lokal
network 192.168.100.0 255.255.255.0
default-router 192.168.100.1
dns-server 192.168.100.1
option 42 ip 192.168.100.1
domain-name <mydomain>.home.arpa
!
!
!
ip domain name <mydomain>.home.arpa
ip inspect name myfw http
ip inspect name myfw https
ip inspect name myfw pop3s
ip inspect name myfw imaps
ip inspect name myfw esmtp
ip inspect name myfw sip
ip inspect name myfw rtsp
ip inspect name myfw icmp router-traffic
ip inspect name myfw tcp router-traffic
ip inspect name myfw udp router-traffic
no ipv6 cef
!
!
multilink bundle-name authenticated
license udi pid C896VA-K9 sn 000000000
!
!
username <user> privilege 15 secret 9 <secret>
!
!
!
!
!
controller VDSL 0
!
ip ssh time-out 30
ip ssh version 2
lldp run
!
!
!
!
!
!
!
!
!
interface ATM0
no ip address
shutdown
no atm ilmi-keepalive
!
interface BRI0
no ip address
encapsulation hdlc
shutdown
isdn termination multidrop
!
interface Ethernet0
no ip address
!
interface Ethernet0.7
description VDSL Internet Verbindung - VLAN 7 tagged
encapsulation dot1Q 7
pppoe enable group global
pppoe-client dial-pool-number 1
!
interface GigabitEthernet0
description Lokales LAN
no ip address
!
interface GigabitEthernet1
no ip address
!
interface GigabitEthernet2
no ip address
!
interface GigabitEthernet3
no ip address
!
interface GigabitEthernet4
no ip address
!
interface GigabitEthernet5
no ip address
!
interface GigabitEthernet6
no ip address
!
interface GigabitEthernet7
no ip address
!
interface GigabitEthernet8
no ip address
shutdown
duplex auto
speed auto
!
!
interface Vlan1
description Lokales LAN
ip address 192.168.100.1 255.255.255.0
ip nat inside
ip virtual-reassembly in
ip tcp adjust-mss 1452
!
interface Dialer0
description xDSL PPPoE Internet Interface
mtu 1492
ip address negotiated
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
encapsulation ppp
dialer pool 1
ppp authentication pap callin
ppp pap sent-username H1und1xxxxx@xxxx.de password <mypassword>
ppp ipcp dns request
ppp ipcp mask request
ppp ipcp route default
no cdp enable
!
ip forward-protocol nd
no ip http server
no ip http secure-server
!
!
ip dns server
ip nat inside source list 101 interface Dialer0 overload
!
ip access-list extended CLI-ACCESS
remark Konfig Zugang ACL
permit tcp 192.168.100.0 0.0.0.255 any eq 22
permit udp 192.168.100.0 0.0.0.255 any eq snmp 10161
deny ip any any log
!
access-list 101 permit ip 192.168.100.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 5060 any
access-list 111 permit udp any eq bootps any
access-list 111 deny ip any any
dialer-list 1 protocol ip list 101
no cdp run
!
control-plane
!
!
banner exec ^C
Sie sind verbunden mit VTY $(line) auf dem Router $(hostname)
^C
!
line con 0
no modem enable
line aux 0
line vty 0 4
access-class CLI-ACCESS in
transport input telnet ssh
!
scheduler allocate 20000 1000
ntp update-calendar
ntp server de.pool.ntp.org source Dialer0
!
endHier ist die Config des VDSL Controllers:
RT01#show controller VDSL 0
Controller VDSL 0 is UP
Daemon Status: Up
XTU-R (DS) XTU-C (US)
Chip Vendor ID: 'BDCM' 'BDCM'
Chip Vendor Specific: 0x0000 0xC278
Chip Vendor Country: 0xB500 0xB500
Modem Vendor ID: 'CSCO' ' '
Modem Vendor Specific: 0x4602 0x0000
Modem Vendor Country: 0xB500 0x0000
Serial Number Near: FCZ204710J5 C896VA-K 15.2(4)M
Serial Number Far: eq nr port:14 oemid softwarerev
Modem Version Near: 15.2(4)M
Modem Version Far: 0xc278
Modem Status: TC Sync (Showtime!)
DSL Config Mode: AUTO
Trained Mode: G.993.2 (VDSL2) Profile 17a
TC Mode: PTM
Selftest Result: 0x00
DELT configuration: disabled
DELT state: not running
Trellis: ON ON
SRA: disabled disabled
SRA count: 0 0
Bit swap: enabled enabled
Bit swap count: 0 0
Line Attenuation: 0.0 dB 0.0 dB
Signal Attenuation: 0.0 dB 0.0 dB
Noise Margin: 6.3 dB 11.9 dB
Attainable Rate: 19384 kbits/s 1676 kbits/s
Actual Power: 4.4 dBm 11.4 dBm
Per Band Status: D1 D2 D3 U0 U1 U2 U3
Line Attenuation(dB): 4.8 N/A N/A 3.9 N/A N/A N/A
Signal Attenuation(dB): 4.8 N/A N/A 3.9 N/A N/A N/A
Noise Margin(dB): 6.3 N/A N/A 11.9 N/A N/A N/A
Total FECC: 18 0
Total ES: 0 0
Total SES: 0 0
Total LOSS: 0 0
Total UAS: 4601 4601
Total LPRS: 0 0
Total LOFS: 0 0
Total LOLS: 0 0
Full inits: 1
Failed full inits: 0
Short inits: 0
Failed short inits: 1
Firmware Source File Name (version)
-------- ------ -------------------
VDSL embedded VDSL_LINUX_DEV_01212008 (1)
Modem FW Version: 130205_1433-4.02L.03.B2pvC035j.d23j
Modem PHY Version: B2pvC035j.d23j
Vendor Version: Bpv35j.23j 68
DS Channel1 DS Channel0 US Channel1 US Channel0
Speed (kbps): 0 19081 0 1576
SRA Previous Speed: 0 0 0 0
Previous Speed: 0 0 0 0
Reed-Solomon EC: 0 18 0 0
CRC Errors: 0 0 0 0
Header Errors: 0 0 0 0
Interleave (ms): 0.00 0.00 0.00 9.00
Actual INP: 2.01 60.00 0.00 1.00
Training Log : Stopped
Training Log Filename : flash:vdsllog.bin
Falsch gemacht hast du vermutlich nichts, denn das korrekt negotiatete Profil 17a kann technisch natürlich mehr (max 150Mbit).
Es ist anzunehmen das die embeddete Modem Firmware die du laut Konfig verwendet hast wie auch beim 880er Modell vermutlich kein Vectoring supportet.
Im Gegensatz zum 880er bietet Cisco beim 896er keine separate Modem Firmware zum Download an:
https://software.cisco.com/download/home/286259496/type
Das ist analog zum 900er und 1100er Router dessen latest Firmware vectoringfähig ist.
Daher ist die Kardinalsfrage welche Firmware Version du verwendest?? Leider machst du dazu keinerlei hilfreiche Angaben (show ver).
Zu vermuten das die Vectoring fähige Modem Firmware im derzeit aktuellsten Release (15.9.3M8) embeddet ist. Versuch macht also klug.
https://software.cisco.com/download/home/286259496/type/280805680/releas ...
900er und 1100er Modelle kommen bei 17a problemlos auf Wirespeed.
Es ist anzunehmen das die embeddete Modem Firmware die du laut Konfig verwendet hast wie auch beim 880er Modell vermutlich kein Vectoring supportet.
Im Gegensatz zum 880er bietet Cisco beim 896er keine separate Modem Firmware zum Download an:
https://software.cisco.com/download/home/286259496/type
Das ist analog zum 900er und 1100er Router dessen latest Firmware vectoringfähig ist.
Daher ist die Kardinalsfrage welche Firmware Version du verwendest?? Leider machst du dazu keinerlei hilfreiche Angaben (show ver).
Zu vermuten das die Vectoring fähige Modem Firmware im derzeit aktuellsten Release (15.9.3M8) embeddet ist. Versuch macht also klug.
https://software.cisco.com/download/home/286259496/type/280805680/releas ...
900er und 1100er Modelle kommen bei 17a problemlos auf Wirespeed.
1Zitat von @aqui:
Falsch gemacht hast du vermutlich nichts, denn das korrekt negotiatete Profil 17a kann technisch natürlich mehr (max 150Mbit).
Es ist anzunehmen das die embeddete Modem Firmware die du laut Konfig verwendet hast wie auch beim 880er Modell vermutlich kein Vectoring supportet.
Im Gegensatz zum 880er bietet Cisco beim 896er keine separate Modem Firmware zum Download an:
https://software.cisco.com/download/home/286259496/type
Das ist analog zum 900er und 1100er Router dessen latest Firmware vectoringfähig ist.
Daher ist die Kardinalsfrage welche Firmware Version du verwendest?? Leider machst du dazu keinerlei hilfreiche Angaben (show ver).
Zu vermuten das die Vectoring fähige Modem Firmware im derzeit aktuellsten Release (15.9.3M8) embeddet ist. Versuch macht also klug.
https://software.cisco.com/download/home/286259496/type/280805680/releas ...
900er und 1100er Modelle kommen bei 17a problemlos auf Wirespeed.
Falsch gemacht hast du vermutlich nichts, denn das korrekt negotiatete Profil 17a kann technisch natürlich mehr (max 150Mbit).
Es ist anzunehmen das die embeddete Modem Firmware die du laut Konfig verwendet hast wie auch beim 880er Modell vermutlich kein Vectoring supportet.
Im Gegensatz zum 880er bietet Cisco beim 896er keine separate Modem Firmware zum Download an:
https://software.cisco.com/download/home/286259496/type
Das ist analog zum 900er und 1100er Router dessen latest Firmware vectoringfähig ist.
Daher ist die Kardinalsfrage welche Firmware Version du verwendest?? Leider machst du dazu keinerlei hilfreiche Angaben (show ver).
Zu vermuten das die Vectoring fähige Modem Firmware im derzeit aktuellsten Release (15.9.3M8) embeddet ist. Versuch macht also klug.
https://software.cisco.com/download/home/286259496/type/280805680/releas ...
900er und 1100er Modelle kommen bei 17a problemlos auf Wirespeed.
Vielen Dank für die schnelle Antwort!
Es tut mir Leid, ich habe mir schon gedacht, dass ich etwas vergessen habe:
System image file is "flash:c800-universalk9-mz.SPA.152-4.M6.bin"
Hmm leider kann ich die aktuelle Firmware ohne einen Service Vertrag nicht herunterladen
To Download this software, you must Log In and have a valid service contract associated to your Cisco.com profile.
If you do not have a service contract you can get one through:
Your Cisco Account Team if you have a direct purchase agreement with Cisco
Your Cisco Partner or Reseller
Once you have the service contract you must associate your service contract to your Cisco.com user ID with Profile ManagerSchade
System image file is "flash:c800-universalk9-mz.SPA.152-4.M6.bin"
Alter Schwede!! Aus welcher Steinzeit Epoche stammt dies Image?? Ist ja nichtmal mehr im Download Archiv aufgeführt!
Moin,
nun konnte ich den Router auf 158-3.M9 upgraden. Der VDSL Profil ist zwar weiterhin der 17a doch nun bekomme ich die 100 mBit's die dem Profil ja entsprechen.
Scheinbar wird der Super-Vectoring nicht unterstützt das für die 250 mBit's und das Profil 35b benötigt wird.
Hier die Liste der VDSL Profile, falls es für jemanden interessant ist:
https://www.elektronik-kompendium.de/sites/kom/1804231.htm
Vielen Dank für die Unterstützung!
nun konnte ich den Router auf 158-3.M9 upgraden. Der VDSL Profil ist zwar weiterhin der 17a doch nun bekomme ich die 100 mBit's die dem Profil ja entsprechen.
Scheinbar wird der Super-Vectoring nicht unterstützt das für die 250 mBit's und das Profil 35b benötigt wird.
Hier die Liste der VDSL Profile, falls es für jemanden interessant ist:
https://www.elektronik-kompendium.de/sites/kom/1804231.htm
Vielen Dank für die Unterstützung!
1
G.Fast, respektive Profil 35b supportet Cisco erst ab dem ISR 1100.
https://content.cisco.com/chapter.sjs?uri=/searchable/chapter/content/en ...
https://content.cisco.com/chapter.sjs?uri=/searchable/chapter/content/en ...
Hallo Zusammen,
ich habe zum ersten mal einen Cisco Router und ich habe mich mal an die Konfiguration gewagt. Habe dazu diese hier geposteten Konfigurationen durchgeschaut und die teile des Tutorials durchgelesen die meiner Meinung mir helfen sollten .
Nun zu meinem Anschluss ich habe einen M-Net Anschluss (Dual Stack) VLAN Tag 40 wird für den Internet zugang benötigt . Genauer gesagt habe ich ein FTTH anschluss. Mein Cisco Router C1111X-8P hängt an dem ONT . Wechsel möchte ich aus 2 Gründen machen 1. hat die Angeschlossene Fritzbox zu wenig freie Lan Ports (3) und ich bräuchte min 6 da ich zz kein WLAN verwende und alle Geräte per Lan anschließen möchte. Klar könnte ich nun einfach einen switch dran hängen und alles wäre gut aber ich möchte auch 2. ein wenig lernen mit Cisco Routern umzugehen und zweitens lieber nur 1 statt 2 Geräte an die Wand schrauben.
Zurzeit bräuchte ich eigentlich kein Gastnetz aber ggf. werde ich in der Zukunft das noch konfigurieren / einrichten .
Ich habe mich an dem ZFW Firewall Konzept bedient.
Hier meine zurzeite Konfig
Leider geht zurzeit nichts.
Kann sein das ich einfach einen üblen Anfängerfehler gemacht habe. Aber ich selber komme gerade nicht weiter. GGF. kann jemand von euch mir einen stumper in die richtige Richtung geben das ich das hier noch zum Laufen bekomme. DHCPv6 brauche ich nicht unbedingt. SLAAC würde auch reichen wenn kein IPv6 funktionieren würde wäre das erstmal kein Beinbruch. Erstmal Internet danach mal schauen wie ich den rest geregelt bekomme
Ich hoffe auf eure Erfahrung und Expertise. Mir fehlt sie auf diesem Gebiet bin aber Willens das noch zu lernen
P.S: Mit PFsense habe ich den Anschluss schon zum Laufen bekommen leider habe ich an dem Endgerät noch weniger freie Lan Ports als an der Fritzbox
ich habe zum ersten mal einen Cisco Router und ich habe mich mal an die Konfiguration gewagt. Habe dazu diese hier geposteten Konfigurationen durchgeschaut und die teile des Tutorials durchgelesen die meiner Meinung mir helfen sollten .
Nun zu meinem Anschluss ich habe einen M-Net Anschluss (Dual Stack) VLAN Tag 40 wird für den Internet zugang benötigt . Genauer gesagt habe ich ein FTTH anschluss. Mein Cisco Router C1111X-8P hängt an dem ONT . Wechsel möchte ich aus 2 Gründen machen 1. hat die Angeschlossene Fritzbox zu wenig freie Lan Ports (3) und ich bräuchte min 6 da ich zz kein WLAN verwende und alle Geräte per Lan anschließen möchte. Klar könnte ich nun einfach einen switch dran hängen und alles wäre gut aber ich möchte auch 2. ein wenig lernen mit Cisco Routern umzugehen und zweitens lieber nur 1 statt 2 Geräte an die Wand schrauben.
Zurzeit bräuchte ich eigentlich kein Gastnetz aber ggf. werde ich in der Zukunft das noch konfigurieren / einrichten .
Ich habe mich an dem ZFW Firewall Konzept bedient.
Hier meine zurzeite Konfig
version 17.12
service timestamps debug datetime msec
service timestamps log datetime msec
service password-encryption
service call-home
platform qfp utilization monitor load 80
platform punt-keepalive disable-kernel-core
platform hardware throughput crypto 250000
!
hostname Router
!
boot-start-marker
boot system flash bootflash:c1100-universalk9.17.12.02.SPA.bin
boot-end-marker
!
!
aaa new-model
!
!
aaa authentication login default local
aaa authorization exec default local
!
!
!
!
!
!
!
ip dhcp excluded-address 192.168.1.1 192.168.1.5
!
ip dhcp pool WEBUIPool
network 192.168.1.0 255.255.255.0
default-router 192.168.1.1
dns-server 192.168.1.1
!
!
!
login on-success log
!
!
!
!
!
ipv6 flowset
ipv6 unicast-routing
ipv6 dhcp pool DHCPv6
prefix-delegation pool v6pdpool
import dns-server
!
redundancy
mode none
!
!
!
!
!
vlan internal allocation policy ascending
!
!
class-map type inspect match-all ALLOW_IN
match access-group name ALLOWv4
match access-group name ALLOWv6
class-map type inspect match-any LOKAL-ERLAUBT
match protocol http
match protocol https
match protocol dns
match protocol imaps
match protocol smtp
match protocol ssh
match protocol ntp
match protocol tcp
match protocol udp
match protocol icmp
class-map type inspect match-any ICMPv6
match access-group name ICMPv6
class-map type inspect match-any GAST-ERLAUBT
match protocol http
match protocol https
match protocol dns
match protocol ntp
class-map type inspect match-any ROUTER-PROTOCOLS
match class-map ALLOW_IN
match protocol tcp
match protocol udp
match protocol icmp
!
policy-map type inspect LOKAL-INTERNET-POLICY
description Traffic Lokales LAN zum Internet
class type inspect LOKAL-ERLAUBT
inspect
class class-default
drop
policy-map type inspect ROUTER-INTERNET-POLICY
description Traffic Routertraffic zum Internet
class type inspect ROUTER-PROTOCOLS
inspect
class class-default
drop
policy-map type inspect ICMPv6
description Traffic ICMPv6 ins lokale LAN
class type inspect ICMPv6
inspect
class class-default
drop
policy-map type inspect GAST-INTERNET-POLICY
description Traffic Gast zum Internet
class type inspect GAST-ERLAUBT
inspect
class class-default
drop
policy-map type inspect INTERNET-ROUTER-POLICY
description Traffic Internettraffic zum Router
class type inspect ALLOW_IN
pass
class class-default
drop
!
!
zone security LOKAL
zone security GAST
zone security INTERNET
zone-pair security GAST-INTERNET source GAST destination INTERNET
service-policy type inspect GAST-INTERNET-POLICY
zone-pair security ICMPv6 source INTERNET destination LOKAL
service-policy type inspect ICMPv6
zone-pair security INTERNET-ROUTER source INTERNET destination self
service-policy type inspect INTERNET-ROUTER-POLICY
zone-pair security LOKAL-INTERNET source LOKAL destination INTERNET
service-policy type inspect LOKAL-INTERNET-POLICY
zone-pair security ROUTER-INTERNET source self destination INTERNET
service-policy type inspect ROUTER-INTERNET-POLICY
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
interface GigabitEthernet0/0/0
no ip address
negotiation auto
!
interface GigabitEthernet0/0/0.40
encapsulation dot1Q 40
ip address dhcp
pppoe enable group global
pppoe-client dial-pool-number 1
!
interface GigabitEthernet0/0/1
no ip address
shutdown
negotiation auto
!
interface GigabitEthernet0/1/0
!
interface GigabitEthernet0/1/1
!
interface GigabitEthernet0/1/2
!
interface GigabitEthernet0/1/3
!
interface GigabitEthernet0/1/4
!
interface GigabitEthernet0/1/5
!
interface GigabitEthernet0/1/6
switchport
!
interface GigabitEthernet0/1/7
switchport
!
interface Vlan1
description Lokales LAN
ip address 192.168.1.1 255.255.255.0
ip nat inside
zone-member security LOKAL
ipv6 address FE80:BADE:AFFE:CAFE::1 link-local
ipv6 address provider-v6-prefix ::1:0:0:0:1/56
ipv6 enable
ipv6 nd other-config-flag
ipv6 dhcp server DHCPv6 rapid-commit allow-hint
!
interface Vlan10
description Gastnetz
no ip address
zone-member security GAST
!
interface Dialer0
description DSL Internet Interface
ip address negotiated
ip nat outside
zone-member security INTERNET
encapsulation ppp
dialer pool 1
no cdp enable
ipv6 dhcp client pd provider-v6-prefix rapid-commit
ipv6 address autoconfig default
ipv6 enable
ipv6 mtu 1492
ipv6 nd autoconfig default-route
ipv6 verify unicast reverse-path
ipv6 traffic-filter native-ipv6-Firewall in
no ipv6 redirects
no ipv6 unreachables
no keepalive
ppp authentication pap chap callin
ppp chap hostname xxxxxxx@mdsl.mnet-online.de
ppp chap password 7 xxxxx
ppp pap sent-username xxx@mdsl.mnet-online.de password 7 xxxxx
ppp ipcp dns request
ppp ipcp mask request
ppp ipcp route default
!
ip forward-protocol nd
ip http server
ip http authentication aaa
ip http secure-server
!
ip route 0.0.0.0 0.0.0.0 GigabitEthernet0/0/0
ip ssh bulk-mode 131072
!
ip access-list extended ALLOWv4
10 permit udp any any eq 1701
20 permit udp any any eq isakmp
30 permit udp any any eq non500-isakmp
40 permit esp any any
!
dialer-list 1 protocol ip permit
!
route-map track-primary-if permit 1
match ip address 197
!
!
!
!
!
!
ipv6 access-list ALLOWv6
sequence 10 permit udp any eq 547 any eq 546
!
ipv6 access-list ICMPv6
sequence 10 permit icmp any any unreachable
sequence 20 permit icmp any any packet-too-big
sequence 30 permit icmp any any hop-limit
sequence 40 permit icmp any any reassembly-timeout
sequence 50 permit icmp any any header
sequence 60 permit icmp any any next-header
sequence 70 permit icmp any any parameter-option
sequence 80 permit icmp any any echo-request
sequence 90 permit icmp any any echo-reply
sequence 100 permit icmp any any dhaad-request
sequence 110 permit icmp any any dhaad-reply
sequence 120 permit icmp any any mpd-solicitation
sequence 130 permit icmp any any mpd-advertisement
!
control-plane
!
!
line con 0
transport input none
stopbits 1
line vty 0 4
password 7 0225221F020A09715E4D5A582A
length 0
transport input ssh
line vty 5 14
password 7 15312D480D262D743A3066633C
transport input ssh
!
ntp server ptbtime1.ptb.de
call-home
! If contact email address in call-home is configured as sch-smart-licensing@cisco.com
! the email address configured in Cisco Smart License Portal will be used as contact email address to send SCH notifications.
contact-email-addr sch-smart-licensing@cisco.com
profile "CiscoTAC-1"
active
destination transport-method http
!
!
!
!
!
!
endLeider geht zurzeit nichts.
Kann sein das ich einfach einen üblen Anfängerfehler gemacht habe. Aber ich selber komme gerade nicht weiter. GGF. kann jemand von euch mir einen stumper in die richtige Richtung geben das ich das hier noch zum Laufen bekomme. DHCPv6 brauche ich nicht unbedingt. SLAAC würde auch reichen wenn kein IPv6 funktionieren würde wäre das erstmal kein Beinbruch. Erstmal Internet danach mal schauen wie ich den rest geregelt bekomme
Ich hoffe auf eure Erfahrung und Expertise. Mir fehlt sie auf diesem Gebiet bin aber Willens das noch zu lernen
P.S: Mit PFsense habe ich den Anschluss schon zum Laufen bekommen leider habe ich an dem Endgerät noch weniger freie Lan Ports als an der Fritzbox
ich habe zum ersten mal einen Cisco Router und ich habe mich mal an die Konfiguration gewagt.
Glückwunsch! 👍Ganz verinnerlicht oder gelesen hast du das Tutorial aber leider nicht und das ist auch der vermutlich Grund des Scheiterns.
Am ONT wird vermutlich die IP per DHCP vergeben, kann das sein? Wenn ja, bist du vermutlich über das HIER gestolpert?!
Gibt man das (DHCP) in der ZFW nicht frei, scheitert die DHCP Adressvergabe.
Ein genereller Tip und eine Bitte:
- Konfiguriere den Router zuerst immer OHNE die ZFW!! Es reicht wenn du dazu die Zonen Zuweisung an allen Interfaces entfernst.
- Ein paar Grundkonfig Dinge wie NTP, AAA, Uhrzeit usw. sind fehlerhaft oder fehlen ganz.
- Es wäre hilfreich einen separaten Forenthread mit einem hiesigen Verweis für die Lösung aufzumachen, um das Tutorial hier nicht unnötig mit längeren Troubleshooting Threads aufzublähen!
Hallo,
ich verwende einen Cisco 896 Router mit dem IOS 15.9(3)M10 und versuche vergeblich DDNS, mit dem Anbieter www.dnshome.de, zum Laufen zu bekommen. Leider wird die IP im Portal nicht aktualisiert und ich sehe im Debug folgende Meldungen:
Dieser HTML-Code (301) sagt aus, dass die Anfrage weitergeleitet wird/wurde. Was ja auch der Fall ist. Wenn ich die URL direkt in den Browser kopiere wird aus http -> https und als Ergebnis erhalten ich "good 80.97.211.20" im Browser-Fenster. Die IP wurde dann auch im dnshome-Portal geändert. Die URL mit all seinen Parametern funktioniert also. Nur leider wird die IP nicht geändert, wenn der Router die URL aufruft.
Die URL von http://... in https://... abändern funktioniert leider nicht und man erhält die Meldung "HTTPDNSUPD: Call returned Request Aborted, update of xxx.dnshome.eu <=> 80.97.211.20 failed"
Auch der Versuch ":443" ans Ende der URL zu hängen führt nicht zum Erfolg.
Meine Frage also: Klappt es bei Euch (immernoch)? Bzw. wenn ja, wo ist der Fehler bei mir?
Meine Config sieht wie folgt aus:
Vielen Dank!
Gruß Mike
ich verwende einen Cisco 896 Router mit dem IOS 15.9(3)M10 und versuche vergeblich DDNS, mit dem Anbieter www.dnshome.de, zum Laufen zu bekommen. Leider wird die IP im Portal nicht aktualisiert und ich sehe im Debug folgende Meldungen:
Translating "www.dnshome.de"...domain server (8.8.8.8) [OK]
DYNDNSUPD: Adding DNS mapping for xxx.dnshome.eu <=> 80.97.211.20
HTTPDNS: Update add called for xxx.dnshome.eu <=> 80.97.211.20
HTTPDNSUPD: Session ID = 0x2F
HTTPDNSUPD: URL = 'http://xxx.dnshome.eu:password@www.dnshome.de/nic/update?hostname=xxx.dnshome.eu&myip=80.97.211.20'
HTTPDNSUPD: Sending request
HTTPDNSUPD: Response for update xxx.dnshome.eu <=> 80.97.211.20
HTTPDNSUPD: DATA START
<html>
<head><title>301 Moved Permanently</title></head>
<body>
<center><h1>301 Moved Permanently</h1>
Router(DDNS-HTTP)#</center>
<hr><center>nginx</center>
</body>
</html>
HTTPDNSUPD: DATA END, Status is Response data recieved, successfully
HTTPDNSUPD: Call returned SUCCESS, update of xxx.dnshome.eu <=> 80.97.211.20 succeeded
DYNDNSUPD: Another update completed (outstanding=0, total=0)
HTTPDNSUPD: Clearing all session 10 infoDieser HTML-Code (301) sagt aus, dass die Anfrage weitergeleitet wird/wurde. Was ja auch der Fall ist. Wenn ich die URL direkt in den Browser kopiere wird aus http -> https und als Ergebnis erhalten ich "good 80.97.211.20" im Browser-Fenster. Die IP wurde dann auch im dnshome-Portal geändert. Die URL mit all seinen Parametern funktioniert also. Nur leider wird die IP nicht geändert, wenn der Router die URL aufruft.
Die URL von http://... in https://... abändern funktioniert leider nicht und man erhält die Meldung "HTTPDNSUPD: Call returned Request Aborted, update of xxx.dnshome.eu <=> 80.97.211.20 failed"
Auch der Versuch ":443" ans Ende der URL zu hängen führt nicht zum Erfolg.
Meine Frage also: Klappt es bei Euch (immernoch)? Bzw. wenn ja, wo ist der Fehler bei mir?
Meine Config sieht wie folgt aus:
ip ddns update method dnsHome
http
add http://xxx.dnshome.eu:password@www.dnshome.de/nic/update?hostname=<h>&myip=<a>
interval maximum 1 0 0 0
!
interface Dialer0
ip ddns update hostname xxx.dnshome.eu
ip ddns update dnsHomeVielen Dank!
Gruß Mike
2 kurze Fragen:
- Hast du das auch mit der für den 896er recommendeten FW probiert ob das dort auch passiert?
- Hat es einen Grund den Google DNS zu nutzen und nicht den der dir per PPPoE automatisch vom Provider übermittelt wird?! (ppp ipcp dns request) Das du damit dein Nutzungsprofil exponierst weisst du sicher selber.
- Nein, habe es noch nicht mit der recommendeten FW ausprobiert. Glaube zwar nicht das sich dadurch was ändert, aber klar, ein Versuch ist es Wert.
- Nein, gibt keinen besonderen Grund warum ich den Google-DNS nutze. Verwende jetzt den vom Provider
Mich würde aber wirklich mal interessieren, ob es bei jemand anderem aktuell noch mit diesem Anbieter funktioniert und wie dort die Konfig (und eventuell der Debug) aussieht.
Ich vermute (du müsstest es mal mit nem eigenen Webserver testen), dass der aktuelle Chiffren und Schlüsselalgorythmen für TLS nicht kann.
1
Hi MikeZ125,
frohes Fest gewünscht aus Berlin.
so sieht es bei mir aus mit meinem 886VAJ.........
Falls es trotzdem nicht funktionieren sollte, kann man hier die komplette Konfig posten, oder eine Nachricht schreiben mit der kompletten Konfig.
Allen noch einen schönen zweiten Feiertag.
Gruß Inge
frohes Fest gewünscht aus Berlin.
so sieht es bei mir aus mit meinem 886VAJ.........
ip ddns update method dnshome
HTTP
add http://ingeundxxxxxxo.dnshome.de:xxxpassword von dnshome.de xxx@www.dnshome.de/nic/update?ingeundxxxxxxo.dnshome.de=<h>&myip=<a>
interval maximum 0 15 0 0
interval minimum 0 8 0 0Falls es trotzdem nicht funktionieren sollte, kann man hier die komplette Konfig posten, oder eine Nachricht schreiben mit der kompletten Konfig.
Allen noch einen schönen zweiten Feiertag.
Gruß Inge
1Serie: Cisco-Tutorials
Cisco router with zone based firewall and port forwarding (englisch)Cisco IPsec VPN with Mikrotik or FritzBox (englisch)Cisco WLAN access point 1142N and 2702, 3702 for SoHo use (englisch)Cisco, Mikrotik, pfSense site-to-site VPN with dynamic routing (englisch)1Cisco WLAN Access Points 1142N, 2702, 3702 für den Heimgebrauch umrüsten110Cisco Telefone für All IP Anschluss, FritzBox und andere VoIP Anlagen fit machen183Cisco 880, 890 und ISR Router Konfiguration mit xDSL, Kabel oder FTTH Anschluss plus VPN und IP-TV266
