Temporäre Probleme mit DNS (pix 501)

[menschmaschine 10]

Hallo zusammen,

 

ich habe hier ein 'kleines' Problem mit meiner Cisco PIX 501. Leider

sitze ich zur Zeit nicht vor der Maschine, so dass detailierte Infos

ggf. später nachgeschoben werden müssten.

Das IOS ist 6.1, soweit ich das im Kopf habe, und es ist PDM 3 drauf.

Da ich schon mit pf (OpenBSD), Netscreen, Fernao und anderen

Paketfiltern/Firewalls gearbeitet habe, war das einrichten einer ersten

'Nach aussen hin darf jeder alles'-Regel kein Problem. Es ist also IP,

TCP, UDP und ICMP fuer alle internen Maschinen erlaubt.

 

Ich kann nun mit allen PCs (Windows, Linux, BSD) ganz normal im

Internet arbeiten. IRC, ICQ, Mail, http, alles kein Problem. Aber in

relativ regelmässigen Abstaenden kommt es vor, dass DNS nicht

ordentlich auflöst/arbeitet. Ich surfe eine Seite an und bekomme die

Meldung, dass Seite www.$SEITENNAME.de nicht erreichbar sei. Wenn ich

in diesem Zeitraum, der etwa 30-120 Sekunden dauert, z.B. auch meinen

Mailclient neu starte, kann ich auch keine Mails abholen, da die IP

meines Providers nicht aufgelöst wird.

 

Kurz was zum Netzaufbau...

 

Internet 
 |
 |
Router (SMC, 192.168.0.0/24)
 |
 |
PIX (192.168.0.0/24)

PIX (192.168.10.0/24)
 |
 |
LAN (192.168.10.0./24)

In der Zone zwischen der PIX und dem Router ist ein Webserver. Auf dem

kann ich feststellen, dass das Problem nicht der Router sein kann. Hier

funktioniert alles, somit auch DNS, problemlos.

 

Ist jemandem ein vergleichbares Problem bekannt, oder hat jemand eine

Idee was hier der Auslöser sein könnte?

 

 

menschmaschine

[s21it21 10]

Hello!

 

Grundsätzlich (wenn du das auf der PIX nicht umgedreht hast), darf alles aus der höheren in die niedrigere Priorität hinaus.

 

Höchste Priorität = lokales LAN

niedrigste Pr. Internet

 

Das heisst Du musst nur irgend ein NAT (static, etc.) einrichten. Dann darf alles aus dem lokalen LAN raus (ohne dass Du eine Access-List gemacht hast).

 

 

Wenn du aber trotzdem Access-Listen gemacht hast, dann würde ich DNS für udp (e klar) ABER auch für tcp freischalten. Wenn nämlich ein DNS-Paket zugross wird/ist, dann kann der Client die DNS-Abfrage via tcp machen. Wenn Du das blockierst, kann die DNS-Auflösung nicht erfolgen.

 

 

Um das Verhalten genau zu analysieren logge Dich auf der Pix direkt ein und mache eind debug packet inside auf der Firewall. Bzw. mache ein debug packet outside xxxx (schaue in der hilfe nach was du genau brauchst). Dann siehst DU was da genau hängen bleibt. Und ein Tipp pfeife auf den Grafischen Manager, der ist ein Müll. :D

 

Outside = Interface Internet

Inside = Interface LAN

(wenn DU das nicht anders eingestellt hast)

 

 

lg

martin

[menschmaschine 10]

Grundsätzlich (wenn du das auf der PIX nicht umgedreht hast), darf alles aus der höheren in die niedrigere Priorität hinaus.

 

Höchste Priorität = lokales LAN

niedrigste Pr. Internet

 

Das heisst Du musst nur irgend ein NAT (static, etc.) einrichten. Dann darf alles aus dem lokalen LAN raus (ohne dass Du eine Access-List gemacht hast).

Ja, ist alles unveraendert. Und ein NAT habe ich natuerlich, hatte ich

vergessen zu erwaehnen, eingerichtet.

 

Um das Verhalten genau zu analysieren logge Dich auf der Pix direkt ein und mache eind debug packet inside auf der Firewall. Bzw. mache ein debug packet outside xxxx (schaue in der hilfe nach was du genau brauchst). Dann siehst DU was da genau hängen bleibt.

Ja, das koennte doch eine Hilfe sein! Das werde ich spaeter auf jeden

Fall mal probieren.

 

Und ein Tipp pfeife auf den Grafischen Manager, der ist ein Müll. :D

Sagt irgendwie jeder, ja ;) War aber die schnellste Moeglichkeit fuer

mich 'mal eben' alles gaengig zu bekommen.

 

Danke schon mal fuer die Hilfe!

 

menschmaschine

[menschmaschine 10]

So, mein Problem ist 'gelöst'. Ich habe die 501 rausgeworfen und durch

ein OpenBSD-basierendes pf ersetzt. ;)

 

Am Wochenende habe ich die externe Anbindung der PIX mal auf einen Hub

gesteckt, um auch dort mit tcpdump/ethereal Daten sammeln zu können.

Parallel hierzu habe ich noch ein 'debug packet outside' laufen lassen.

 

Auf der Inside-Seite sind unglaublich viele Pakete die mit einer

falschen Checksum von der PIX zum Host laufen. Nachdem dann debug mal

ein paar Minuten lief, ist die SSH-Verbindung zur Pix unterbrochen

worden. Eine erneut aufgebaut Sitzung blieb dann auch nur ein paar

Minuten lang erhalten. Und obwohl ich debug später deaktiviert habe,

hatte ich einige Stunden später 60%-70% CPU. Da war dann an normales,

und vor allem performantes, surfen nicht mehr zu denken. Wobei ich mich

schon frage, warum die Kiste bei 60% die Füsse hochklappt.

 

Also alles in allem ist das Resultat natürlich traurig, da ich die Pix

auch gerne benutzt hätte. Vielleicht werde ich später noch mal schauen

ob das Gerät lauffähig ist. Allerdings habe ich eher den Eindruck, dass

das Teil nicht in Ordnung ist. Jetzt ist mir erst mal ein gängiges LAN

wichtig. Und deshalb wird eben das gute alte pf eigesetzt ;)

 

Aber trotz allem Danke für die Antwort.

 

menschmaschine

[s21it21 10]

hallo,

 

das problem ist bei der pix bekannt. wenn man ein debug packet all macht (inside oder outside), dann kann das die pix verdammt in schwierigkeiten bringen!!!

cisco ist das problem schon seit langem bekannt.....

 

warum das mit dem dns nicht funktioniert hat ist eigenartig, am inside interface hättest du daten (udp 53) von der internen quelladresse sehen müssen, am outside interface müsste man eben falls upd-53 pakete sehen, aber eben mit der genatteten pubip.

 

wenn die daten am inside-interface ankommen, aber am outside-interface nicht, dann passt was mit dem NAT nicht (static, pat, etc.).

 

lg

martin