I was regularly receiving blocked packets on port 53 from my DNS servers. Looking at the detailed text log events, these looked like timeouts from packets (DNS requests) already sent out. ie I am assuming that the UDP connection lost its "pseudo state" (within Outpost) due to the DNS server taking too long to return a particular packet to the internal port that sent it? It's a very small percentage of all outbound DNS requests, but enough to occasionally have the servers blocked under my (fairly tight) Attack Detection block rules.. My rule for DNS requests is the usual "UDP outbound to DNS servers on port 53"; the "state" process means no inbound rule is needed. This rule is in SVCHOST only: with Vista SP1 and Outpost, I do not need a global DNS rule, nor do I need DNS rules for each app - SVCHOST seems to insist on handling all DNS requests, whatever other DNS rules are, or are not, in place.. I then found that if I tried adding a rule to also allow UDP inbound, specifically from DNS servers / port 53, to local ports 49152 to 65535, the DNS inbound blocks stopped (this is a "low level" rule - in Outpost meaning at system level, eg includes traffic not controlled by applications, and is tested after the svchost app rule above). Instead I now get "outbound" blocks on ICMP, of type 3/3 in the blocked Packet log (I have "destination unreachable" outbound set up as blocked on ICMP rules). Reading a little, this might suggest that my 49K to 65K rule above is effectively letting the UDP packets back in, but because they are no longer "live" (or in "state") as far as Outpost is concerned, and the port they were sent from by SVCHOST is no longer expecting anything, the packets are dropped, which then triggers the ICMP error alert that I am seeing in the Packet log. The advantage to me - is that now the DNS servers do not get temporarily blocked by too many false inbound alerts. A possible issue is that my new rule is potentially allowing unsolicited inbound traffic, albeit from a very specific protocol / IP / port combination? Am I well off the mark here, or does this make sense..?? Peter PS.. One or two other minor points.. If I add the 49K to 65K rule to SVCHOST, it has no effect, as one would expect, as "state relating to the app etc" within Outpost has been lost. If I add the rule to "global rules" (which in Outpost means applied to any applications), again it has no effect because there is no application expecting the packet. A different option I tried was "trusting" the DNS servers (which obviously works and instead generates "packets dropped due to closed port" in the log), but fully trusting the IP address is less restrictive than the specific rule above. I'm not sure why one causes a dropped packet alert, whereas the other triggers an attempted ICMP response?..