Thanks very much Daniel and Dries! I'm sending my success report/resolution/lessons learned to the list for archives if someone else is in my shoes. The reverse proxy is a great tool for certain (non-ideal) situations that are bound to come up for random people. It would be nice to see this patch commited to -current :) but it's easy enough to compile myself.
That line in inetd is now allowing incoming ftp connections. I don'teven need to nat/binat this connection with the reverse proxy. It worked once I removed the binat mapping altogether. For PF, all you need is to allow connections with S/SA keep state to port 21 on the ftp server. Finally, for outgoing ftp I kept the original line in inetd and the rdr on the $int_if and passive FTP from windows/UNIX clients inside the firewall is working great too. > -----Original Message----- > From: Daniel Hartmeier [mailto:[EMAIL PROTECTED]] > Sent: Thursday, December 26, 2002 9:20 AM > To: Robert Schwartz > Cc: [EMAIL PROTECTED] > Subject: Re: FTP server behind a NAT'ing OpenBSD firewall > (reverse diff troubles) > > > On Thu, Dec 26, 2002 at 09:06:04AM -0800, Robert Schwartz wrote: > > > I don't think I understand this. What should the line in > inetd.conf > > read? There aren't examples in the man page for -R and I've tried > > about 30 iterations so far of the syntax for that line and > none seem > > to work. > > ftp stream tcp nowait root /usr/libexec/ftp-proxy ftp-proxy > -R 192.168.1.2 > > where 192.168.1.2 is the local address of your ftp server. > > Verify that the firewall can itself connect to the ftp server > with telnet 192.168.1.2 21. If you don't get an ftp banner, > debug this first. > > Then verify inetd is working properly by connecting to the > firewall port 21. You should get the same banner as in the > previous test. If you don't, the ftp-proxy -R line in > inetd.conf is not working. > > If it does work, try some data connections with an ftp > client, as with ftp 127.0.0.1 on the firewall. Both active > and passive mode data connections should work. > > If that works, repeat with an external ftp client. If that > should fail, while the previous test worked, you're blocking > either the control connection or the active/passive data > connections with filter rules. > > And I suggest you do all of this with a simple pf.conf > without any unrelated translation rules (ftp-proxy -R does > NOT need an rdr rule). Once it works, extend the ruleset. If > ftp breaks in the process, you'll now what change broke it. > > Daniel >
