Conrad T. Pino wrote:
>>>This presumption is not correct.  A rule permitting inbound traffic IS
>>>needed but at STATIC rule i.e. "pass in" is an unneeded security risk.
>>>The STATIC "pass in" rule may allow *anyone* sending from port 2401 to
>>>use any destination port depending on how tightly the rule is written.
>>
>>Huh??? cvs update from walt's net to the cvs server should _not_ require 
>>connections incoming to walt's from the cvs server.
> 
> 
> We agree, "incoming connections" are NOT required.
> 
> I referred to "inbound traffic" i.e. responses to "outgoing connections".


> I was under the impression that Walt may be new to "ipf"...

Heh, yes, I don't use it.  My firewall machine runs FreeBSD with a user-
space program called 'ppp' (not pppd) which does packet filtering.  I've
been mentally translating your ipf rules to 'ppp' rules and I think I use
something equivalent, though ppp is not as sophisticated as ipf.

I have always had a 'keep state' equivalent for outgoing tcp connections
and blocked any new incoming connections.  It was only during the CVS
crisis of the past few days that I noticed that incoming packets from
netbsd.org:2401 were being blocked while on the way to my ports >65000.

Since I allow established connections in, I am assuming that the blocked
packets were trying to establish new connections, but I admit I can't
know that for certain.  I assume that the agonizingly slow responses
from netbsd.org were allowing established connections to time out, and
CVS was valiantly trying to re-connect (maybe?).

Anyway, things seem back to normal so I have removed the hole at 2401
and everything just works.

Thanks for your help.