On Tue, 18 Mar 2008, Camiel Dobbelaar wrote:
>Dave Anderson wrote:
>> I've been working on the pf configuration for my home firewall,
>> including setting up ftp-proxy. I've noticed that the command is
>> getting cluttered with options to adjust the rules it creates to the
>> needs of different pf configurations. Has any thought been given to
>> allowing arbitrary nat, rdr and pass rules to be specified in a
>> configuration file (in the same syntax as for pf.conf) with macros
>> defined for the server, client and proxy addresses (as in the examples;
>> also, perhaps, a few other macros -- such as for the interfaces through
>> which the client and server are reachable)?
>>
>> I'm not asking (let alone demanding) that anyone implement this, but
>> would like to know if it's been considered and rejected for some
>> reason, is on someone's to-do list, has never been thought about, or
>> whatever. It seems to me to be a good way both to avoid needing more
>> and more options to tweak the generated rules and to avoid the delay
>> involved in modifying the program whenever someone comes up with a new
>> need.
>
>Now that the 'tag' option is available I don't expect ftp-proxy to gain
>any more options wrt. to the pf rules it creates, because you can
>implement those yourself using 'tagged'.
Only if exactly the same thing should be done for all rules in the
anchor, since only one tag can be specified. I can't think offhand of
any cases where this makes an important difference, but how sure can we
be that there are none?
>The history behind the current implementation is that I wanted it to be
>simple. Having a configuration file with pf rules means that you either
>have:
>- embed a full parser, which is a lot of code
>- run pfctl, which makes it harder to chroot
Or tweak the existing code in pfctl so it could be used (perhaps as a
library routine) from ftp-proxy and anyplace else that wanted to make
similar use of anchors. (I haven't examined the pfctl code, so I
realize that this might turn out to be impractical.)
>Also, the FTP protocol is complex. Having the nat and rdr rules under
>user control would easily break things.
Certainly true, for those who use the flexibility.
>So it would be a lot of extra code for not much gain.
If using the code from pfctl is practical it shouldn't be all that much
extra code, and the amount of gain depends on whether someone comes up
with a real need for this sort of flexibility (I don't have anything
specific to propose at this time). But I might well have made the same
decision you did if it had been mine to make.
Thanks for the discussion,
Dave
--
Dave Anderson
<[EMAIL PROTECTED]>
