On Sat, 2004-11-13 at 21:18, Bo Jacobsen wrote: > > Nov 14 02:24:48 WF1-HOME kernel: DENY-OUT:.IN= OUT=eth0 SRC=192.168.1.2 DST=198.41.0.4 LEN=560 TOS=0x00 PREC=0xC0 TTL=64 ID=3123 PROTO=ICMP TYPE=3 CODE=3 [SRC=198.41.0.4 DST=192.168.1.2 LEN=532 TOS=0x00 PREC=0x00 TTL=49 ID=41159 PROTO=UDP SPT=53 DPT=51981 LEN=512 ] > > It looks like ICMP with an embedded DNS call ?. It's an ICMP port unreachable. Looks like 198.41.0.4 tried to send a reply to one of your DNS queries, took too long to respond, and by the time they did the port was closed. What's kind of interesting is that it was a full size answer so I'm guessing the truncation bit was set. This means that if this packet had been returned in time your system would have had to switch to TCP to get a full answer. The UDP info is embedded in the payload so the remote system knows which port was unreachable. This is in case multiple session were running at the same time. Perfectly normal for an ICMP error packet. > What is it exactly, and how would a rule to allow this look like ? This would be permitted if you are letting "RELATED" traffic through. This ensures that only legit ICMP errors are passed. While you could define an accept rule for the ICMP type code, this would let all matching traffic through opening up the possibilities of a covert communication channel. HTH, Chris
