Subject: Re: CVS performance question & ipf rules
To: Conrad T. Pino <NetBSD-Current@Pino.com>
From: walt <email@example.com>
Date: 02/08/2004 08:05:47
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.