On Tue, Jan 01, 2002 at 10:47:12PM +0100, Tobias Koenig wrote:
Jan 3 16:30:36 intranet kernel: DROP-ICMP IN= OUT=eth0 SRC=192.168.20.1 DST=192.168.20.88 LEN=56 TOS=0x00 PREC=0xC0 TTL=255 ID=34583 DF PROTO=ICMP TYPE=11 CODE=0 [SRC=192.168.20.88 DST=207.26.131.137 LEN=28 TOS=0x00 PREC=0x00 TTL=1 ID=15380 PROTO=ICMP TYPE=8 CODE=0 ID=768 SEQ=32569 ]
Die beteiligten Rechner: A 192.168.20.88 = Windows-Laptop B 192.168.20.1 = Linux-Router/Firewall C 207.26.131.137 ???
Da scheint jemand ein traceroute auf dem Host 192.168.20.88 laufen zu lassen. Von dort wurde nämlich ein 'ping request' (Packetinformationen zwischen den Klammern) abgeschickt, mit einer TTL von 1. Dieses Packet erreicht also gerade mal den 1. HOP (192.168.20.1) und hat dort nun eine TTL von 0. Das veranlasst den Router, ein Timeout-ICMP Packet zurückzuschicken, das nun in deiner Firewall hängen bleibt.
Ja, so sehe ich das auch. Während traceroute(unix) mit UDP + ICMP port unreachable arbeitet, nimmt das windowsche tracert ICMP echo req + echo reply. Obiges log ist also ziemlich wahrscheinlich ein Antwortpaket auf eine Anfrage von Windows-tracert vom Laptop aus.
Reinhard