> > > > 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. > It has something to do with PSD. When it's "enabled" the problem arises trigered by prior PSD denials to DNS traffic comming from unknown external ip's. With no iptables PSD statements it never happens. On our inside we have djbdns acting as an internal forwarding DNS server. When PSD closes trafffic of like this, this type of "traffic" is taking up all internet bandwith, and filling up the syslog message log. If djbdns is killed / restarted the traffic stops, and everything works again. If just left alone, after a minute or two, everything goes back to normal. Maybe djbdns starts spewing out DNS requests, and is denied the reply because a trigered PSD will not allow any DNS response back in. Strangely enough, we have only seen this problem when accessing the www.space.com We currently run iptables 1.2.8 on a 2.4.21 kernel. We have not yet tested it with a 2.6 kernel. Bo
