[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: FTP server behind a NAT'ing OpenBSD firewall (reverse diff troubles)

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:daniel@benzedrine.cx] 
> Sent: Thursday, December 26, 2002 9:20 AM
> To: Robert Schwartz
> Cc: pf@benzedrine.cx
> 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
> where is the local address of your ftp server.
> Verify that the firewall can itself connect to the ftp server 
> with telnet 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 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