Worm/Malicious traffic is the leading cause these days - the worms don't 
tend to care about TCP responses/timeouts (but by default they have to 
track some things some how, so they will run out of resources 
eventually, somewhere along the path).

Rejects are an additional step (generate response, send response) but 
still perform a drop.  The additional step adds load.  When an outbreak 
of some random worm occurs, it's conceivable that the firewall will be 
generating (or attempting to generate) thousands of rejects per second.

I've seen many firewalls in recent era squashed by this effect - beyond 
just rejects, the affects of worms on packet handling boxes can be felt 
long after bed time.

This is far more on the meticulous detail than daily reality for smaller 
installations - it all depends on the malicious traffic generating 
capabilities of your LAN boxes.



For my LAN rules:
0) The customary default drops that I like are here - CIFS/etc. (TCP 
125-139,445 and UDP the same - though i'm probably turning too much off 
here)
1) For certain protocols, I turn reject on - web, ssh, etc. - I want the 
instant response for myself and i'm not worried about web worms from my 
house.  Weigh this carefully.
3) The LAN subnet hit's the outbound clean
4) Everything that makes it here wins a free trip to the bit bucket



Stephen Ronan wrote:
>> [...]
> 
>> Reject is usually preferable to block on the LAN.
>>
>> -Chris
> 
> Thanks for that advice. Under what kind of circumstances might block be 
> better to use than reject on the LAN?
> 
> Thanks,
> Stephen
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: m0n0wall dash unsubscribe at lists dot m0n0 dot ch
> For additional commands, e-mail: m0n0wall dash help at lists dot m0n0 dot ch
> 
>