Sry schon wieder ich,
mit einem Verstaendnis Problem, bei der Abarbeitung von ICMP-Paketen.
Die Dienstgruppe PING beinhaltet - echo-request / echo-reply
In einer Regel abgebildet klappt alles (deny/drop) einwandfrei. -> Alle PCs im LAN koennen einen Grundcheck der Anbindung (Ping nach extern) durchfuehren.
Nun noch traceroute dabei und das Ergebnis sieht fuer die Clients so aus:
---schnipp
C:\\>tracert www.web.de
Routenverfolgung zu www.web.de [217.72.195.42] über maximal 30 Abschnitte:
1
--- schnapp
Wuerden die 30 Hops ohne Antwort bleiben, haette ich kein Problem, aber das alle "Zwischen-Hops" verschwinden, kann ich nicht nachvollziehen, was bei Anbindungsproblemen, zur Diagnose sehr hilfreich ist.
mfg
M.Goeres
Verlorener Trace...
Moderator: Securepoint
Verlorener Trace...
Die Welt wird nicht bedroht von den Menschen, die böse sind, sondern von denen, die das Böse zulassen
- Albert Einstein -
- Albert Einstein -
hallo,
welche protokolle habe sie denn fuer den traceroute freigeschaltet.
gruss
oliver hausmann
welche protokolle habe sie denn fuer den traceroute freigeschaltet.
gruss
oliver hausmann
best regards
oliver hausmann
--
Securepoint GmbH
oliver hausmann
--
Securepoint GmbH
Das Problem kann ich bestätigen.
Regel z.B.: intern -> extern alles erlauben (Hide-NAT)
Firewall antwortet, da ping aus interner Zone erlaubt, die übrigen hops antworten nicht - bis auf den Zielhost.
Vermutung: Die Firewall läßt nur die ICMP-Antwort des ursprünglichen Ziels wieder ins interne Netz (stateful inspection? Probleme?). Die übrigen Antworten von den HOPS werden von der Firewall geblockt:
Mar 13 11:53:10 Securepoint-interne-IP Firewall DROP IN=ppp0 OUT= MAC= SRC=66.130.109.224 DST=securepoint-externe-IP LEN=61 TOS=0x00 PREC=0x00 TTL=117 ID=39364 PROTO=ICMP TYPE=8 CODE=0 ID=512 SEQ=61518
Mar 13 11:59:28 Securepoint-interne-IP Firewall DROP IN=ppp0 OUT=eth1 SRC=217.5.98.185 DST=interne Client IP LEN=56 TOS=0x00 PREC=0x00 TTL=126 ID=0 PROTO=ICMP TYPE=11 CODE=0 [SRC=interne Client IP DST=209.85.135.103 LEN=92 TOS=0x00 PREC=0x00 TTL=1 ID=20610 PROTO=ICMP TYPE=8 CODE=0 ID=768 SEQ=16133 ]
...
Anderes Phämonen:
An-ping-en der Firewall über den SM. Pingt sich die Firewall selbst an verschickt Sie 5 Pakete und nur 2 kommen an.
Ist das normal?
Icmp_type=8
recv from INTERNE-FW-IP seq:1 (0ms)
Icmp_type=8
recv from INTERNE-FW-IP seq:2 (0ms)
Icmp_type=8
Transmitted : 5
Received : 2
Lost : 3 (60%)
Avarage round-time: 0ms
mfg
achim
Regel z.B.: intern -> extern alles erlauben (Hide-NAT)
Firewall antwortet, da ping aus interner Zone erlaubt, die übrigen hops antworten nicht - bis auf den Zielhost.
Vermutung: Die Firewall läßt nur die ICMP-Antwort des ursprünglichen Ziels wieder ins interne Netz (stateful inspection? Probleme?). Die übrigen Antworten von den HOPS werden von der Firewall geblockt:
Mar 13 11:53:10 Securepoint-interne-IP Firewall DROP IN=ppp0 OUT= MAC= SRC=66.130.109.224 DST=securepoint-externe-IP LEN=61 TOS=0x00 PREC=0x00 TTL=117 ID=39364 PROTO=ICMP TYPE=8 CODE=0 ID=512 SEQ=61518
Mar 13 11:59:28 Securepoint-interne-IP Firewall DROP IN=ppp0 OUT=eth1 SRC=217.5.98.185 DST=interne Client IP LEN=56 TOS=0x00 PREC=0x00 TTL=126 ID=0 PROTO=ICMP TYPE=11 CODE=0 [SRC=interne Client IP DST=209.85.135.103 LEN=92 TOS=0x00 PREC=0x00 TTL=1 ID=20610 PROTO=ICMP TYPE=8 CODE=0 ID=768 SEQ=16133 ]
...
Anderes Phämonen:
An-ping-en der Firewall über den SM. Pingt sich die Firewall selbst an verschickt Sie 5 Pakete und nur 2 kommen an.
Ist das normal?
Icmp_type=8
recv from INTERNE-FW-IP seq:1 (0ms)
Icmp_type=8
recv from INTERNE-FW-IP seq:2 (0ms)
Icmp_type=8
Transmitted : 5
Received : 2
Lost : 3 (60%)
Avarage round-time: 0ms
mfg
achim
Zuletzt geändert von achim am Di 13.03.2007, 13:01, insgesamt 1-mal geändert.
hallo,
korrekt analysiert. sie koennen das problem folgendermassen loesen.
unter den diensten gibt es einen icmp dienst "icmp-time-exceeded". machen
sie einen doppelklick auf den dienst und haengen an den namen dran "-related"
und speichern das ab. sie sollten jetzt in der dienste liste einen neuen dienst
haben, der da heisst "icmp-time-exceeded-related".
kopieren sie den dienst in die dienstegruppe im regelwerk die fuer die freischaltung
zustaendig ist (in ihrem fall, glaube ich any). nach einem regelupdate sollte tracert
funktionieren.
gruss
oliver hausmann
korrekt analysiert. sie koennen das problem folgendermassen loesen.
unter den diensten gibt es einen icmp dienst "icmp-time-exceeded". machen
sie einen doppelklick auf den dienst und haengen an den namen dran "-related"
und speichern das ab. sie sollten jetzt in der dienste liste einen neuen dienst
haben, der da heisst "icmp-time-exceeded-related".
kopieren sie den dienst in die dienstegruppe im regelwerk die fuer die freischaltung
zustaendig ist (in ihrem fall, glaube ich any). nach einem regelupdate sollte tracert
funktionieren.
gruss
oliver hausmann
best regards
oliver hausmann
--
Securepoint GmbH
oliver hausmann
--
Securepoint GmbH
"workaround" funktioniert.
traceroute funktioniert jetzt.
mfg
achim
traceroute funktioniert jetzt.
mfg
achim