10
Und wieder PPPoE an Cisco 866vae
Ja, die Anleitung Cisco 880, 890 und ISR Router Konfiguration mit xDSL, Kabel oder FTTH Anschluss plus VPN und IP-TV habe ich genau gelesen und paar Stunden an meinem neuen Router verbracht. Die eigentliche Verbindung kommt zustande, das Gerät bekommt IP-Adresse und zwei zusätzliche DNS-Adressen vom Provider und kann sogar alle "tracert" Befehle problemlos ausführen und Außenadressen pingen. Aber er zeigt keine Internet-Seiten an. Vielleicht fehlt noch eine oder andere Berechtigung?
Im Voraus VIELEN DANK für alle Tipps.
P.S. Zwei Zeilen haben in der Anleitung gefehlt, auf die ich selbst gekommen bin:
Nun schreibe ich über den neuen Router!
Im Voraus VIELEN DANK für alle Tipps.
P.S. Zwei Zeilen haben in der Anleitung gefehlt, auf die ich selbst gekommen bin:
permit tcp any any
permit udp any anyNun schreibe ich über den neuen Router!
version 15.1
no service pad
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname Cisco
!
boot-start-marker
boot-end-marker
!
!
logging buffered 51200 warnings
no logging console
enable secret 4 bQPhGIrU.lz77kKzx9CEv03.u63I1PMZjI3YmbBtZFw
!
no aaa new-model
wan mode dsl
no ipv6 cef
no ip source-route
no ip gratuitous-arps
ip cef
!
!
!
!
!
ip domain name anonymous.intern
ip name-server 208.67.222.222
ip name-server 208.67.220.220
!
crypto pki
XXXXXX
quit
!
!
username admin privilege 15 secret 4 bQPhGIrU.lz77kKzx9CEv03.u63I1PMZjI3YmbBtZFw
!
!
controller VDSL 0
operating mode adsl2+
!
!
!
!
!
interface ATM0
no ip address
no atm ilmi-keepalive
!
interface ATM0.1 point-to-point
pvc 1/32
oam-pvc manage
pppoe-client dial-pool-number 1
!
!
interface Ethernet0
no ip address
shutdown
!
interface FastEthernet0
no ip address
!
interface FastEthernet1
no ip address
!
interface FastEthernet2
no ip address
!
interface FastEthernet3
no ip address
!
interface GigabitEthernet0
no ip address
shutdown
duplex auto
speed auto
!
interface Vlan1
description Local LAN
ip address 192.168.1.1 255.255.255.0
ip nat inside
ip virtual-reassembly in
ip tcp adjust-mss 1452
!
interface Dialer0
description DSL Einwahl
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 virtual-reassembly in
encapsulation ppp
dialer pool 1
dialer-group 1
no keepalive
ppp authentication chap callin
ppp chap hostname XAxxxxxxxxx@v6.mnet-online.de
ppp chap password 0 xxxxxxx
ppp ipcp dns request
ppp ipcp mask request
ppp ipcp route default
no cdp enable
!
no 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 101 interface Dialer0 overload
!
access-list 23 permit 192.168.1.0 0.0.0.255
access-list 101 permit ip 192.168.1.0 0.0.0.255 any
access-list 111 remark CCP_ACL Category=1
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 gre any any
access-list 111 deny ip any any
dialer-list 1 protocol ip list 101
!
no cdp run
!
control-plane
!
!
line con 0
login local
modem enable autodetect
line aux 0
private
login local
line vty 0 4
access-class 23 in
privilege level 15
login local
transport input telnet
!
scheduler allocate 60000 1000
end
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 206675
Url: https://administrator.de/contentid/206675
Printed on: April 24, 2024 at 08:04 o'clock
10 Comments
Latest comment
Erstmal hast du gar nicht geschrieben WO ,also in WELCHE Accessliste, diese beiden Statements reinkommen sollen ?!
Zweitens ist "udo" natürlich Unsinn, aber wir "raten" mal wohlwollend hier das due "udp" damit meinst ?!
(Es gibt immer den "Bearbeiten" Button am Thread um sowas zu korrigieren !)
Drittens, WO sind denn diese gänderten Zeilen in deiner aktuellen Konfig ? Zu sehen ist da nix
Zudem ist unklar ob du jetzt noch ein Problem hast oder nicht. Der Thread ist ja hier als gelöst markiert ??
Was ist nun also los ??
Wenn du wirklich keine Internet Seiten von einem Client bekommst, solltest du die IP Settings dieses Clients einmal testen, da du ja vom Router keinerlei DHCP IPs vergibst ist es sehr gut möglich das du hier Fehler in der Client Adressierung gemacht hast ?!
Am Router selber kanns ja nicht mehr liegen denn da klappt ja alles wie du selber schreibst.
Mache also mal ein ipconfig -all (bei Winblows) oder ifconfig (bei Mac OS-X oder Unix) und checke deine IP Settings.
Das sollte so aussehen:
Client IP: 192.168.1.100
Maske: 255.255.255.0
Gateway: 192.168.1.1
DNS: 192.168.1.1
Dann klappt das auch !
Was sagt ein Ping und ein Traceroute (tracert) auf eine nackte IP vom Client wie z.B. 193.99.144.85 (www.heise.de) ?? Klappt das ??
Zudem kannst du mit http://193.99.144.85 einmal ggf. DNS Probleme umgehen und die Heise Seite so direkt vom Client aufrufen !
Um Client Adressierungsproblematiken zu umgehen solltest du ggf.noch
ip dhcp excluded-address 192.168.1.1 192.168.1.149
ip dhcp excluded-address 192.168.1.180 192.168.1.254
!
ip dhcp pool local
network 192.168.1.0
default-router 192.168.1.1
dns-server 192.168.1.1
domain-name anonymous.intern
hinzufügen wenn du nicht gerade einen anderen DHCP Server im Netz betreibst ?!
Zudem solltest du noch TCP bei der Internet ACL Nr. 111 hinzufügen mit access-list 111 permit tcp any eq domain any denn der DNS Standard definiert beide Protokolle:
http://de.wikipedia.org/wiki/Domain_Name_System#Protokoll
Nebenbei hat ein HTTP Server auf einem Internet Router nix zu sichen. Wenn dann HTTPS und SSH only !
Bei mir im internen Netz gibt es keinen DHCP-Server, die wenigen Adressen sind statisch vergeben, deshalb habe ich die entsprechenden Abschnitte bewußt weg gelassen. Die Tracert-Befehle funktionierten vom Anfang an, sowohl zu Domainnamen, als auch zu reinen IP-Adressen. Auch Ping funktionierte. Die Seiten wurden zwar gefunden, aber nicht angezeigt, was seit dem expliziten Erlauben von tcp/udp any any ebenfalls geht. Deshlab habe ich den Thread als gelöst markiert. Ich bin so stolz, dass ich auf diese zwei Einträge selbst gekommen bin!
Den HTTP-Server hat das CCP-Programm automatisch hinzugefüht, damit man die Befehle über Browser ausführen kann. Den Eintrag ändere ich natürlich, vielen Dank für den Hinweis!
Den HTTP-Server hat das CCP-Programm automatisch hinzugefüht, damit man die Befehle über Browser ausführen kann. Den Eintrag ändere ich natürlich, vielen Dank für den Hinweis!
Sorry, wirklich aber du hast es wieder NICHT geschafft zu sagen WO in welche ACL du das integriert hast zumal es in deiner scheinbar finalen Konfig von oben ja GAR NICHT enthalten ist !!
Die Dialer ACL sagt ja explizit permit ip 192.168.1.0 0.0.0.255 any !!
Mit dem Statement ip wird in einer Cisco ACL aber immer TCP und UDP inklusive abgehandelt, sprich alle IP Protokolle.
In so fern ist es aus ACL Sicht völliger Schwachsinn und zudem überflüssig nochmal "permit TCP und UDP" in so eine ACL zu bringen.
Der Fehler liegt hier also ganz woanders, sorry !
<edit> Ja, siehe "Auflösung" des Rätsels unten...</edit>
Solange du nicht wirklich technisch fundiert beschreibst WAS du da eigentlich machst bzw. WO diese permit Statements eingebaut sind, weiss man nicht was los ist !
Sorry für diese drastischen Worte aber so ist das nun mal...
Die Konfig im Tutorial ist wasserdicht an zig Cisco Routern (auch deinem Modell) verifiziert !
Gerade die Wortauswahl ist kein Problem, weil ich sehr wohl verstehe, wie Du und andere Teilnehmer hier von solchen Typen wie ich genervt sein sollten. Entschuldige mich bitte!
Konkret habe ich nun die folgenden ACL:
Die Liste 23 ist für diesen HTTP-Server und für vty zuständig.
Die Liste 100 - für das LAN
Die Listen 101 und 111 - für das Interface Dialer0
Momentan habe ich aber ein anderes und ziemlich akutes Problem - der Router startet immer neu ca. alle 30 Minuten. Die Down- und Uploadwerte sind hervorragend.
Konkret habe ich nun die folgenden ACL:
access-list 23 permit 192.168.1.0 0.0.0.255
access-list 100 remark Internes Netz
access-list 100 remark CCP_ACL Category=1
access-list 100 permit ip 192.168.1.0 0.0.0.255 any
access-list 101 permit ip 192.168.1.0 0.0.0.255 any
access-list 111 remark CCP_ACL Category=1
access-list 111 permit udp any eq bootps any eq bootpc
access-list 111 permit tcp any any
access-list 111 permit udp any 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 icmp any any echo
access-list 111 permit udp any eq domain any
access-list 111 permit tcp any eq domain any
access-list 111 permit tcp any any eq www
access-list 111 permit gre any any
access-list 111 deny ip any anyDie Liste 23 ist für diesen HTTP-Server und für vty zuständig.
Die Liste 100 - für das LAN
Die Listen 101 und 111 - für das Interface Dialer0
Momentan habe ich aber ein anderes und ziemlich akutes Problem - der Router startet immer neu ca. alle 30 Minuten.
Die Down- und Uploadwerte sind hervorragend.
OK, kommen wir mal wieder etwas runter und betrachten alles mal ganz logisch...! In der Ruhe liegt die Kraft...wie immer 
Es ist klar wo der Fehler liegt, was im ersten Anfall unter den Tisch gefallen ist. Die Entschuldigung kommt also von hier...
Dein Kardinalsfehler ist das du die lokale Firewall auf dem Cisco NICHT aktiviert hast !
Bei dir fehlen also die Statements:
ip inspect name myfw tcp
ip inspect name myfw udp
!
interface Dialer0
description DSL Einwahl Interface
ip inspect myfw out
!
In der Konfig bzw. auf dem Dialer 0 Interface
Die ACL 111 ist eine inbound ACL die das Dialer Interface (also das Internet Interface) vor bösen Zugriffen schützen soll.
Da "inbound" greift diese ACL also nur für Pakete die von außen (also aus dem Internet) nach innen wollen.
Die Router Firewall steuert diese ACLs aber dynamisch ! Sog. Content based Access Control Lists CBAC:
http://www.cisco.com/en/US/products/sw/secursw/ps1018/products_tech_not ...
Die ACL wird also dynamisch für lokalen IPs geöffnet wenn interne Sessions von denen nach draussen gehen um die Antwortpakete, solange diese Session aktiv ist, auch durchzulassen.
Da du aber in deiner o.a. Konfig KEIN Firewalling aktiviert hast, passiert diese automatische, sessionbasierte Öffnung der ACL nicht !!
Eingehende Antwortpakete von UDP oder TCP bleiben also an deiner inbound ACL 111 logischerweise dann kleben !! Works as designed...
Das ist also das finale Problem.
Sorry nochmal, hat ich im Eifer des Gefechts übersehen !
Damit ist die gesamte ACL 111 am Dialer Interface aber in sich unsinnig- Du solltest die dann besser so umstellen das du nur die relevanten ICMPs wie echo request redirect usw. denyest und den rest dann mit ip any any erlaubst ala
ip access-list 111
deny icmp any any echo
deny icmp any any redirect
permit ip any any
das ist dann einfacher.
Noch besser ist es aber die Firewall wie oben mit den CABC ACLs laufen zu lassen !! Dann funktioniert die Konfig auch wie sie soll
Gut aber das du drüber gestolpert bist dann pass ich das Tutorial nochmal an !
Es ist klar wo der Fehler liegt, was im ersten Anfall unter den Tisch gefallen ist. Die Entschuldigung kommt also von hier...
Dein Kardinalsfehler ist das du die lokale Firewall auf dem Cisco NICHT aktiviert hast !
Bei dir fehlen also die Statements:
ip inspect name myfw tcp
ip inspect name myfw udp
!
interface Dialer0
description DSL Einwahl Interface
ip inspect myfw out
!
In der Konfig bzw. auf dem Dialer 0 Interface
Die ACL 111 ist eine inbound ACL die das Dialer Interface (also das Internet Interface) vor bösen Zugriffen schützen soll.
Da "inbound" greift diese ACL also nur für Pakete die von außen (also aus dem Internet) nach innen wollen.
Die Router Firewall steuert diese ACLs aber dynamisch ! Sog. Content based Access Control Lists CBAC:
http://www.cisco.com/en/US/products/sw/secursw/ps1018/products_tech_not ...
Die ACL wird also dynamisch für lokalen IPs geöffnet wenn interne Sessions von denen nach draussen gehen um die Antwortpakete, solange diese Session aktiv ist, auch durchzulassen.
Da du aber in deiner o.a. Konfig KEIN Firewalling aktiviert hast, passiert diese automatische, sessionbasierte Öffnung der ACL nicht !!
Eingehende Antwortpakete von UDP oder TCP bleiben also an deiner inbound ACL 111 logischerweise dann kleben !! Works as designed...
Das ist also das finale Problem.
Sorry nochmal, hat ich im Eifer des Gefechts übersehen !
Damit ist die gesamte ACL 111 am Dialer Interface aber in sich unsinnig- Du solltest die dann besser so umstellen das du nur die relevanten ICMPs wie echo request redirect usw. denyest und den rest dann mit ip any any erlaubst ala
ip access-list 111
deny icmp any any echo
deny icmp any any redirect
permit ip any any
das ist dann einfacher.
Noch besser ist es aber die Firewall wie oben mit den CABC ACLs laufen zu lassen !! Dann funktioniert die Konfig auch wie sie soll
Gut aber das du drüber gestolpert bist dann pass ich das Tutorial nochmal an !
Ich habe das Gefühl, dass ich die lokale Firewall nicht aktiviert habe, weil der Router 866vae diese gar nicht besitzt. Der CCP-Manager sagt, diese Option sei bei mir nicht verfügbar, genauso wir VPN z.B. Mein Gerät ist ganz einfach. So kommen wir langsamt zum Hauptpunkt der Probleme.
P.S. Die ständigen kompletten Neustarts nerven gewaltig! Und als der Router noch kein Internet hatte, konnte er stundenlang ohne Neustart aushalten.
Mein Gerät ist ganz einfach. So kommen wir langsamt zum Hauptpunkt der Probleme.P.S. Die ständigen kompletten Neustarts nerven gewaltig! Und als der Router noch kein Internet hatte, konnte er stundenlang ohne Neustart aushalten.
Achte darauf das du das aktuellste Firmware Image installiert hast ! Ggf. ibt es auch eine neue aktualisiert Modem Firmware wie beim 886va ! Auch die solltest du ggf. einspielen. Checke also zwingend den Download auf der Cisco Website zur 866er IOS Firmware !
Normalerweise ist die Firewall Option auch in der Grundausstattung dabei. (Was sagt ein show flash zu deiner installierten Version ?)
Telnette die Maschine auf dem CLI und versuche nach einem conf t mal die FW Kommandos einzugeben:
ip inspect name myfw tcp
Oder gebe "ip" und Leerschritt ein und tippe das "?" und checke ob er das Kommando "inspect" in der CLI Auswahlliste hat !
Taucht es dort auf supportet es die Maschine auch ! Solche GUI Manager sind meist Mist. Vergiss sowas wie CCP "Real man do CLI" !!
Sind die Neustarts ein kompletter Reboot der Maschine ?? oder fliegt dir nur dein DSL Link weg ?
Kannst du mit show logg sehen was im Log steht oder verschwindet das komplett sollte die ganze Maschine rebooten ?
Ggf. hilft das "OAM-pvc manage" mal vom ATM Subinterface zu entfernen mit "no OAM-pvc manage" wenn es nur ein Neustart des DSL Links ist !
T-Com und andere Provider supporten meist kein OAM auf Consumer Anschlüssen und wenn die OAM Frames vom Provider fehlen nimmt dein Router den Link down.
Besser also du entfernst das.
Das ist wieder so ein überflüssiger Mist der von diesen üblen GUI Managern komme
Normalerweise ist die Firewall Option auch in der Grundausstattung dabei. (Was sagt ein show flash zu deiner installierten Version ?)
Telnette die Maschine auf dem CLI und versuche nach einem conf t mal die FW Kommandos einzugeben:
ip inspect name myfw tcp
Oder gebe "ip" und Leerschritt ein und tippe das "?" und checke ob er das Kommando "inspect" in der CLI Auswahlliste hat !
Taucht es dort auf supportet es die Maschine auch ! Solche GUI Manager sind meist Mist. Vergiss sowas wie CCP "Real man do CLI" !!
Sind die Neustarts ein kompletter Reboot der Maschine ?? oder fliegt dir nur dein DSL Link weg ?
Kannst du mit show logg sehen was im Log steht oder verschwindet das komplett sollte die ganze Maschine rebooten ?
Ggf. hilft das "OAM-pvc manage" mal vom ATM Subinterface zu entfernen mit "no OAM-pvc manage" wenn es nur ein Neustart des DSL Links ist !
T-Com und andere Provider supporten meist kein OAM auf Consumer Anschlüssen und wenn die OAM Frames vom Provider fehlen nimmt dein Router den Link down.
Besser also du entfernst das.
Das ist wieder so ein überflüssiger Mist der von diesen üblen GUI Managern komme
Leider habe ich kein "inspect"! Auch über HTTP, wo man alle möglichen Parameter sofort sieht, ist "inspect" nicht dabei. Die Firmware ist neu, eine neuere Version gibt es noch nicht. So wie ich die Cisco-Seite verstehe, gibt es mehrere Versionen von 866VAE, z.B. 866VAE-K9 und 866VAE-SEC-K9 mit "Advanced security and QoS" und einen einfachen 866VAE ohne diese. Unter "Advanced security" steckt sich unter Anderem die Firewall.
Es handelt sich um komplette Reboots vom Router, nicht nur von der DSL-Verbindung. Das Gerät ist in dieser Zeit nicht erreichbar, dann kommt die blinkende DSL-Lampe, danach wird die DSL-Verbindung hergestellt. Diese ist schnell und läuft bestens bis zum nächsten Neustart. SHOW LOGG zeigt nichts, außer irgendwelchen alten Einträgen, die ziemlich harmlos erscheinen.
Auch über HTTP, wo man alle möglichen Parameter sofort sieht, ist "inspect" nicht dabei. Die Firmware ist neu, eine neuere Version gibt es noch nicht. So wie ich die Cisco-Seite verstehe, gibt es mehrere Versionen von 866VAE, z.B. 866VAE-K9 und 866VAE-SEC-K9 mit "Advanced security and QoS" und einen einfachen 866VAE ohne diese. Unter "Advanced security" steckt sich unter Anderem die Firewall.Es handelt sich um komplette Reboots vom Router, nicht nur von der DSL-Verbindung. Das Gerät ist in dieser Zeit nicht erreichbar, dann kommt die blinkende DSL-Lampe, danach wird die DSL-Verbindung hergestellt. Diese ist schnell und läuft bestens bis zum nächsten Neustart. SHOW LOGG zeigt nichts, außer irgendwelchen alten Einträgen, die ziemlich harmlos erscheinen.
Habs mal eben an einem Labor 886va an einem T-Com ADSL Anschluss getestet. Sobald man "oam-pvc manage" am ATM PVC eingibt unterbricht die DSL Verbindung nach 10 Sek. weil keinerlei OAM Frames vom T-Com DSLAM zurückkommen !
Das Kommando sollte man also besser an T-Com DSL Anschlüssen nicht konfigurieren !! Du solltest es also besser entfernen in der PVC Konfig bei dir.
Das "866VAE-SEC-K9" Image ist auf alle Fälle das mit Firewall. Ggf. flashst du das mal bei dir, dann kannst du diese Funktion nutzen. Bei einem Internet Router macht das allemal Sinn ! Ist aber deine Entscheidung letztlich.
Die aktuellste Firmware ob mit oder ohne FW solltest du aber in jedem Falle flashen. Vermutlich verschwinden dann auch deine Crashes.
Das Kommando sollte man also besser an T-Com DSL Anschlüssen nicht konfigurieren !! Du solltest es also besser entfernen in der PVC Konfig bei dir.
Das "866VAE-SEC-K9" Image ist auf alle Fälle das mit Firewall. Ggf. flashst du das mal bei dir, dann kannst du diese Funktion nutzen. Bei einem Internet Router macht das allemal Sinn ! Ist aber deine Entscheidung letztlich.
Die aktuellste Firmware ob mit oder ohne FW solltest du aber in jedem Falle flashen. Vermutlich verschwinden dann auch deine Crashes.
In der Tat, auf der Cisco Seite gibt es einen Hinweis auf die neueste Software vom 29.03.2013. Leider kann ich sie nicht herunterladen, weil ich keinen Vertrag habe. Außerdem habe ich dort gelesen, dass es für diese Geräte keine "allgemeinen" Images mehr gibt, sondern nur nach jeweiliger Ausführung. Also, die einfachste "Base" Ausfürung kann nur mit einer entsprechenden "IP Base" IOS Version geflasht werden und nicht mit K9 oder so. Im Internet ist allerdings nur die "Security-K9" Version zu finden und beim Versuchen, diese Datei auf den Router aufzuspielen, bekomme ich die Meldung "File is not a valid executable for this system". Davor hat Cisco aber ausdrücklich gewarnt, das habe ich mit meinen eigenen Augen gesehen. Ja, sowas gibt es neuerdings.
