Cisco 886va DNS unheimlich langsam
Hallo,
egal an welchem Rechner ich den DNS des 886va einstelle, es dauert u.U ne halbe Minute, bis eine Antwort kommt.
Wenn ich einen wie 8.8.8.8 einstelle, ist alles flott.
Wenn ich in der CLI des Cisco Namen anpinge und er damit den eigenen DNS nutzt, ist alles flott. Der DNS von CCC, der im Cisco eingestellt ist, reagiert normal, wenn man den direkt nutzt.
Was ist da faul?
LG Marco
egal an welchem Rechner ich den DNS des 886va einstelle, es dauert u.U ne halbe Minute, bis eine Antwort kommt.
Wenn ich einen wie 8.8.8.8 einstelle, ist alles flott.
Wenn ich in der CLI des Cisco Namen anpinge und er damit den eigenen DNS nutzt, ist alles flott. Der DNS von CCC, der im Cisco eingestellt ist, reagiert normal, wenn man den direkt nutzt.
Was ist da faul?
LG Marco
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 369859
Url: https://administrator.de/contentid/369859
Ausgedruckt am: 22.11.2024 um 03:11 Uhr
31 Kommentare
Neuester Kommentar
Richtig, leider kann man wegen der recht oberflächlichen Beschreibung nur im freien Fall raten.
In jedem Falle ist das nicht normal und lässt eine Fehlkonfiguration vermuten.
Hilfreich wäre hier ein Ausszug der Dialer Int Konfig und der DNS relevanten Settings gewesen.
Wie es richtig einzustellen ist zeigt das hiesige Cisco_Tutorial.
Mit den dortigen Settings klappt es fehlerlos und ohne Verzögerung.
In jedem Falle ist das nicht normal und lässt eine Fehlkonfiguration vermuten.
Hilfreich wäre hier ein Ausszug der Dialer Int Konfig und der DNS relevanten Settings gewesen.
Wie es richtig einzustellen ist zeigt das hiesige Cisco_Tutorial.
Mit den dortigen Settings klappt es fehlerlos und ohne Verzögerung.
Den Clients wird die IP des 886va als DNS gegeben.
Deshalb solltest du den DNS Port auch aus der Firewall Instection entfernen.Außerdem hast du hier einen gravierenden Fehler gemacht in der Konfig !!
Die globale TCP und UDP Inspection muss IMMER AM ENDE als die letzten beiden Statements dort stehen !!!
Bedeutet nämlich das alles was danach definiert wird nicht mehr Protokoll spezifisch behandelt wird.
Deine Telnet und DNS Inspection dort ist also vollkommen wirkungslos. Steht auch so im o.a. Tutorial wenn man mal genau liest !
Das solltest du dringenst korrigieren.
Deine Firewall ist ja so oder so ein löchriger Schweizer Käse wenn man sich die ACL 111 mal so in Ruhe ansieht.
Aber wenn du damit leben kannst ist ja gut...
MTU Setting auf dem Dialer und MSS auf dem LAN stimmen soweit ?
VLAN 1 ist richtig aber der MSS Wert ist auch falsch !!
Richtig muss er lauten:
ip tcp adjust-mss 1452
Warum orientierst du dich nicht einfach mal am Tutorial ?
Wenn du jetzt noch die CBAC Reihenfolge anpassen würdest und auch ICMP noch VOR UDP und TCP bringst wäre es perfekt.
Router dann rebooten und dann sollte alles mit Turbo laufen
ip inspect name myfw icmp router-traffic
ip inspect name myfw tcp router-traffic
ip inspect name myfw udp router-traffic
!
Sinnvoller wäre da sicher ein VPN. Aber du wirst ja sicher gute Gründe haben....
Noch ein Tip: Wenn alles im 3ten Gang rennt kann es auch sein das versucht wird deinen Router anzugreifen. Bei soviel offenen Ports werden die typischen Port Scanner ja schnell fündig.
Ein show proc cpu hist zeigt dir mal auf wann das der Fall ist. In der Regel geht die CPU Last dann auf 90% und höher.
Richtig muss er lauten:
ip tcp adjust-mss 1452
Warum orientierst du dich nicht einfach mal am Tutorial ?
Wenn du jetzt noch die CBAC Reihenfolge anpassen würdest und auch ICMP noch VOR UDP und TCP bringst wäre es perfekt.
Router dann rebooten und dann sollte alles mit Turbo laufen
ip inspect name myfw icmp router-traffic
ip inspect name myfw tcp router-traffic
ip inspect name myfw udp router-traffic
!
Was ist denn so schlimm daran?
Na ja wenn die ganze Welt mitsamt seiner bösen Buben über alle diese Ports in dein internes Netz kommen kann sollte das leichte Bauchschmerzen erzeugen.Sinnvoller wäre da sicher ein VPN. Aber du wirst ja sicher gute Gründe haben....
Noch ein Tip: Wenn alles im 3ten Gang rennt kann es auch sein das versucht wird deinen Router anzugreifen. Bei soviel offenen Ports werden die typischen Port Scanner ja schnell fündig.
Ein show proc cpu hist zeigt dir mal auf wann das der Fall ist. In der Regel geht die CPU Last dann auf 90% und höher.
Was sagt ein show hosts auf dem Cisco und das Logg (ggf. voher mit clear logg löschen).
Bekommst du dort irgendwelche Fehlermeldungen ?
Hast du NUR ppp ipcp dns request auf dem Dialer konfiguriert und keine zusätzliche statische DNS Definition mit ip name-server xyz ?
Ggf. hilft dir das noch:
https://www.jens-bretschneider.de/cisco-router-als-dns-proxy-aber-nur-au ...
Bekommst du dort irgendwelche Fehlermeldungen ?
Hast du NUR ppp ipcp dns request auf dem Dialer konfiguriert und keine zusätzliche statische DNS Definition mit ip name-server xyz ?
Ich dachte erst, der Catalyst 2950 würde Probleme machen.
Nein, solanger der kein L3 macht wäre das technisch unmöglich. Ein L2 Switch weiss rein gar nix von IP Paketen und damit DNS, er kommuniziert bekanntlich ausschliesslich nur mit Mac Adressen !Ggf. hilft dir das noch:
https://www.jens-bretschneider.de/cisco-router-als-dns-proxy-aber-nur-au ...
als auch einen DNS per ip name-server festgelegt.
DAS ! ist der fehler. Entferne den statischen mal und teste neu.Ich möchte NUR den festgelegten nutzen.
Dann musst du aber auch zwingend mit NO ppp ipcp dns request den PPPoE DNS Request vom Dialer Interface entfernen !Damit verwendet der Router dann immer nur den statisch Konfigurierten. (Das sollte natürlich KEINER sein der Profile von dir erstellt wie Google oder am anderen Ende der Welt liegt ! (Laufzeit))
Soll ich jetzt einfach ppp ipcp dns request entfernen?
Yepp !Ich habe am 2950 keine Layer konfiguriert.
Ist natürlich technischer Blödsinn, denn Layer 2 ist immer aktiv sonst könnte der Switch gar nicht switchen.Wär so als wenn man dich fragt ob du mit Sommer- oder Winterreifen Auto fährst und du antwortest: "Ich habe am Auto keine Reifen montiert..."
Es ist normalerweise per default an (habe ich noch nie anders gesehen).
Es sollte auch an bleiben wenn du den Lokalen DNS Dienst auf dem Cisco benutzen möchtest.
"no ip domain-lookup" stopt jegliche Interaktion mit den DNS Service so auch
externe Anfragen an einen nach außen gepuschten (mit "ip name-server") Dienst.
Dein Fehlerbild klingt nach DNS Timeouts. Da es nach ein paar Sekunden dann läuft
wird ggf. ein andere DNS gefragt der noch in Setup des Clients ist,oder in der Liste der DNS Server auf dem Cisco.
Was sagt den ein dig heise.de @deine Cisco IP oder wenn doch Windows ein nslookup heise.de deineCiscoIP ?
Aqui frage nach der Ausgabe von "show hosts" dort gibt es die Zeile
"Name servers are..."
Glaskugel sagt:
Irgendeine Access List ist nicht ganz sauber. Ähnliches hatte ich auch das
Return Traffic nicht reinkommen durfte und dann auf TCP ausgewichen wurde nach den TimeOuts.
(das ist aber schon 10 Jahre her)
Zeig doch mal bitte Dialer, Internes Interface und alles AccesListen für diese Interface, Firewall Setting.
Sonst gerne auch
"debug ip domain" einschalten uns schauen was der Cisco so treibt.
"no deb al" hinterher nicht vergessen, ggf, mit "term mon" die Debuggen Ausgabe auf dem Terminal einschalten
Es sollte auch an bleiben wenn du den Lokalen DNS Dienst auf dem Cisco benutzen möchtest.
"no ip domain-lookup" stopt jegliche Interaktion mit den DNS Service so auch
externe Anfragen an einen nach außen gepuschten (mit "ip name-server") Dienst.
Dein Fehlerbild klingt nach DNS Timeouts. Da es nach ein paar Sekunden dann läuft
wird ggf. ein andere DNS gefragt der noch in Setup des Clients ist,oder in der Liste der DNS Server auf dem Cisco.
Was sagt den ein dig heise.de @deine Cisco IP oder wenn doch Windows ein nslookup heise.de deineCiscoIP ?
Aqui frage nach der Ausgabe von "show hosts" dort gibt es die Zeile
"Name servers are..."
Glaskugel sagt:
Irgendeine Access List ist nicht ganz sauber. Ähnliches hatte ich auch das
Return Traffic nicht reinkommen durfte und dann auf TCP ausgewichen wurde nach den TimeOuts.
(das ist aber schon 10 Jahre her)
Zeig doch mal bitte Dialer, Internes Interface und alles AccesListen für diese Interface, Firewall Setting.
Sonst gerne auch
"debug ip domain" einschalten uns schauen was der Cisco so treibt.
"no deb al" hinterher nicht vergessen, ggf, mit "term mon" die Debuggen Ausgabe auf dem Terminal einschalten
Zitat von @Windows10Gegner:
Name servers are 213.73.91.35, 212.65.0.189, 213.183.65.31
Alle sind pingbar. nmap mit UDP ahbe ich noch nicht gemacht. warum das aber 3 sind ist mir unklar. Ich habe nur einen eingetragen.
Name servers are 213.73.91.35, 212.65.0.189, 213.183.65.31
Alle sind pingbar. nmap mit UDP ahbe ich noch nicht gemacht. warum das aber 3 sind ist mir unklar. Ich habe nur einen eingetragen.
213.73.91.35 -> laut PTR dnscache.berlin.ccc.de es gibt aber keinen A record für die Adresse.
ach ja das wichtigste... da lauft gar nicht erst ein DNS Dienst ? Also warum die Adresse ?
212.65.0.189-> ns1.manet.de und 213.183.65.31-> dns1.pfalzkom.de. Erster antwortet öffentlich auf DNS fragen, zweiter nicht (kann sein das der nur mag wenn man auch eine IP bei dem Provider hat)
Das sind also Deine Provider DNS, die du bei der Einwahl bekommst
nach einem " no ppp ipcp dns request" werden die gelernten DNS Server
behalten auch wenn du eine Neueinwahl veranlasst (clear int di 09
Die alten DNS bekommst du mit „no ip name-serve x.x.x.x“ weg (oder halt poors admin reboot)
debug ip domain gibt es nicht. Nur dns oder dns-cache
"debug ip domain" soll es bei dir nicht geben auf einem 886va ?
Eher sehr sehr unwahrscheinlich. Vertipper ? ("debug ip domain")
Aber im Grunde :
der 213.73.91.35 ist Müll da kein DNS Dienst drauf Antwortet. Daher kommt es zu timeouts.
Also warum dieser ?
Nachtrag:
https://berlin.ccc.de/wiki/Hauptseite
Seiten mitte
Aktuelle Ankündigungen
Wir haben den öffentlich Dienst dnscache.berlin.ccc.de offline genommen. Bislang ist nicht klar, ob und wann dieser Dienst zurückkommt. Bitte nutzt die Gelegenheit, um selber DNS-Server aufzusetzen und ggf. für alle bereitzustellen.
Nur mal OT:
Deine 101er ACL hat noch einen Fehler. Der Host .100 macht statische PAT durch die Port Forwarding Eintrag und der ist mit der ACL 101 richtigerweise vom Overload ausgenommen.
Das gilt aber auch für den .115 und der Eintrag access-list 101 deny ip host 10.0.0.115 any fehlt aber !
Zur DNS Problematik hat ja Kollege @gierig schon alles gesagt.
Deine 101er ACL hat noch einen Fehler. Der Host .100 macht statische PAT durch die Port Forwarding Eintrag und der ist mit der ACL 101 richtigerweise vom Overload ausgenommen.
Das gilt aber auch für den .115 und der Eintrag access-list 101 deny ip host 10.0.0.115 any fehlt aber !
Zur DNS Problematik hat ja Kollege @gierig schon alles gesagt.
Zitat von @aqui:
Nur mal OT:
Deine 101er ACL hat noch einen Fehler. Der Host .100 macht statische PAT durch die Port Forwarding Eintrag und der ist mit der ACL 101 richtigerweise vom Overload ausgenommen.
Das gilt aber auch für den .115 und der Eintrag access-list 101 deny ip host 10.0.0.115 any fehlt aber !
Nur mal OT:
Deine 101er ACL hat noch einen Fehler. Der Host .100 macht statische PAT durch die Port Forwarding Eintrag und der ist mit der ACL 101 richtigerweise vom Overload ausgenommen.
Das gilt aber auch für den .115 und der Eintrag access-list 101 deny ip host 10.0.0.115 any fehlt aber !
Das habe ich hier schon mal gelesen (ich meine auch von dir) und war perplex, hatte das aber nicht weiter verfolgt.
Das hier widerspricht deiner aussage, funktioniert aber 100%
ip nat inside source static tcp 192.168.1.123 22 interface Dialer0 222
ip nat inside source list LOCAL-PNAT-VPN-EXTERN interface Dialer0 overload
!Dialer Access List
ip access-list extended Dialer_1_IN
permit tcp any any eq 222
!AccesListe fürs Dynmaische PNAT nach draußen
ip access-list extended LOCAL-PNAT-VPN-EXTERN
permit ip 192.168.1.0 0.0.0.255 any
Normales Setup + good old cbac (bin zu faul mal auf Zonen Base umstellen)
Das läuft mit verschiedenen Ports an verschiedenen Anschlüssen seit knappen 10 Jahren
(ein 836 mit 12.4 irgendwas ist das älteste woran ich mich erinnere).
Warum sollte das auch nicht gehen ?
Das eine ist das dynamische PNAT für Ausgehende Verbindung.
Das andere eine Portweiterleitung für ankommenden Traffic.
Wenn ich einen Host aus der DPNAT liste herausnehmen (also wie obenein denny für den .101) ist das einzigste das
dieser nicht mehr raus darf abgesehen von return traffic der auf den weitergeleiteten Port ankommt.
Für Oben gilt daher für mich: Host .101 darf nicht in Inet, .115 schon.
Ob Port Weiterleitungen existieren oder nicht ist egal.
Irgendwo steht ein Denkfehler im Raum den ich nicht sehe.
Warum sollte das auch nicht gehen ?
Es geht, ist aber IP technisch gesehen nicht sauber, denn die Inbound SNAT Session ist eine Verschiedene von der Outbound PAT Session weil beide Prozesse sich nicht "sehen". Man hat quasi 2 Pfade. Es ist sauberer dann den PFW Host vom PAT auszunehmen da ja die statische NAT Zuweisung schon besteht.Kann man machen (um es IP technisch sauber zu machen)...muss man aber nicht Deshalb geht es auch ohne.
Natürlich sind es zwei Pfade. Es handelt sind ja schließlich auch zwei unterschiedliche Verbindungen.
Die eine hat nichts mit der anderen zu tun. Die bearbeitende Instanz kennt beide und behandelt sie entsprechend
(Halt die NAT engine).
Oder meinst du den Return Traffic des weitergeleiteten Ports ? Dieser wird aber nicht nochmal
über das pnat gehauen da ja schon ein der statische snat Eintrag besteht.
Das PNAT für den host zu entfernen sorgt einzig und alleine dafür dieser nicht mehr wie die anderen
raus darf. Das kann gewünscht sein oder halt nicht.
Was ist daran bitte unsauber ? Ich kann nicht erkennen wo hier ein Schwachpunkt sein soll.
Was genau funktioniert schlechter oder besser ?
Hier
hattest du es auch geschrieben
Also verrate mir bitte wie du darauf kommst ?
Die eine hat nichts mit der anderen zu tun. Die bearbeitende Instanz kennt beide und behandelt sie entsprechend
(Halt die NAT engine).
Oder meinst du den Return Traffic des weitergeleiteten Ports ? Dieser wird aber nicht nochmal
über das pnat gehauen da ja schon ein der statische snat Eintrag besteht.
Pro Inside global Inside local Outside local Outside global
tcp xxx.xxx.xx.xxx:222 192.168.1.123:22 --- ---
bzw nach aufbau:
tcp xxx.xxx.xx.xxx:222 192.168.1.123:22 xxx.xx.xx.xx:60732 xxx.xx.xx.xx:60732
Das PNAT für den host zu entfernen sorgt einzig und alleine dafür dieser nicht mehr wie die anderen
raus darf. Das kann gewünscht sein oder halt nicht.
Was ist daran bitte unsauber ? Ich kann nicht erkennen wo hier ein Schwachpunkt sein soll.
Was genau funktioniert schlechter oder besser ?
Hier
hattest du es auch geschrieben
Die internen static IP Adressen musst du logischerweise vom PAT (overload) in der ACL 101 ausnehmen !
PAT hat immer Präzedenz über static NAT
PAT hat immer Präzedenz über static NAT
Also verrate mir bitte wie du darauf kommst ?
Nein !
Es sei denn du meinst den .100 und den .115 Host.
Nimm dir einen Wireshark und sehe dir die Sessin an wenn inbound via PFW etwas reinkommt. Dann weisst du was gemeint ist
Er darf ja schon durch den statischern NAT. Es sorgt dafür das nur von Outbound aufgebaute Sessions rausdürfen.
Ist Thema für einen separaten Thread. Wir sollten den hier nicht mit OT Themen einfach kapern !
Es sei denn du meinst den .100 und den .115 Host.
Nimm dir einen Wireshark und sehe dir die Sessin an wenn inbound via PFW etwas reinkommt. Dann weisst du was gemeint ist
Oder meinst du den Return Traffic des weitergeleiteten Ports ?
Genau den !Er darf ja schon durch den statischern NAT. Es sorgt dafür das nur von Outbound aufgebaute Sessions rausdürfen.
Also verrate mir bitte wie du darauf kommst ?
Cisco NAT Doku dazu lesen !Ist Thema für einen separaten Thread. Wir sollten den hier nicht mit OT Themen einfach kapern !
Gerne doch, dann gehts hier weiter...
Cisco SNAT mit PANT (Portforwarding bei Overload Host)
Cisco SNAT mit PANT (Portforwarding bei Overload Host)