On Tuesday, May 27, 2003, at 14:39 US/Pacific, Bryan Irvine wrote:
[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.
At this point, I'd start using "log" on the block rules, along with
tcpdump on pflog0 and the relevant interfaces. pflog0's report on
the blocked packets should identify why the login screen takes so
long to pop up.
I'm also puzzled as to why active FTP isn't working for WAN clients,
but is for the NAT ones. tcpdump on the other interfaces may offer
clues.
