Bryan S. Leaman wrote: > OK, I'm trying to accomplish this with tags. However, ftp-proxy is > always putting "quick" in the rules, so no further processing is done > and my reply-to tagged rule (located after the anchor) is never matched. > > Would it make more sense to not use quick when -T <tagname> option is > used with ftp-proxy? Or am I not understanding how these tags are to be > used? > > To test my theory, I modified filter.c in ftp-proxy and set > pfr.rule.quick=0, and now my tagged rule matches and the reply-to works.
What you describe is exactly how it should work (ftpsesame, the other FTP proxy that I wrote already does it like that). I'll look into a fix for ftp-proxy. > On Tue, 4 Dec 2007, Camiel Dobbelaar wrote: > >> Bryan S. Leaman wrote: >>> I have a multiple ISP router/firewall running 4.2. To make FTP work >>> properly over both gateways, I found and applied the following patch to >>> ftp-proxy **see link below** and it's working great (apparently pftpx is >>> very similar to ftp-proxy). Without this fix, my second ftp-proxy >>> process (for ISP2) allows the incoming data connection but incorrectly >>> tries to respond over the firewall's default gateway (ISP1). This fix >>> adds a "reply-to" argument to the dynamic inbound rule and makes >>> everything work. I believe it also adds "route-to" when using passive >>> FTP. I have an explicit pf route-to rule to handle the initial outbound >>> FTP connection coming from the ftp-proxy. >>> >>> Is there any chance that this feature could be added to the OpenBSD >>> code? Or is there some other way to properly route FTP over multiple >>> gateways with the existing ftp-proxy? Seems like something that others >>> may find to be useful. >> >> I think I helped create part of that route-to diff, but I don't think it >> belongs in base ftp-proxy. A userland daemon should not control routing >> like that. >> >> Maybe the new 'tag' option can be used for this? (or else the tag >> option needs work ;-) )
