arrgghh! ok I must be missing something really simple.
on to my famous ascii art!!
[internet]---[OBSD]---[DMZ with ftp server] <-public range no on a NAT
/ \
/ NAT2 (connects fine to ftp server in active mode)
NAT1 (also connects just fine in active mode)
Clients on the internet cannot connect fine in active mode.
I've even set the policy to "pass in quick all" and "pass out quick all"
The login screen pops right up immediatelly when i use the pass all
rules, but then I still have to switch to passive when I connect from
the outside. As soon as I switch back to my block in all I have to wait
about a minute for the login screen to pop up, as well as switch to
passive after I've authenticated. I'm assuming 2 things,
1> pf is doing something funky to make the connection take a really long
time.
2> the ftp server doesn't know how to do active ftp when going out over
the $WAN connnection which it does of the 2 NAT connections.
What am I missing here?
--Bryan
On Tue, 2003-05-27 at 14:00, Trevor Talbot wrote:
> On Tuesday, May 27, 2003, at 13:44 US/Pacific, Bryan Irvine wrote:
>
> > pass in quick on $WAN inet proto tcp from any to $FTPServer port {
> > ftp,\
> > ftp-data, > 1023 } flags S/SA keep state
>
> What you had previously for the port setup here was fine, since your
> server is the one listening, and it will use a defined range of ports:
> { ftp, > 49151 }
>
> > It pretty much does the same thing...take forever for the login prompt
> > to come up. Then I have to switch it into passive mode for anything to
> > work.
>
> What's missing is the ability for the ftp server to connect out to the
> clients, since they're the ones listening in active mode.
>
> pass out quick on $WAN inet proto tcp from $FTPServer to any port \
> { ftp-data, > 1023 } flags S/SA keep state
>
> Possibly and/or the same rule in on $DMZ, depending on your default
> rules for blocking.
>
