We don't (yet) do any egress filtering pass out on $ext_if proto tcp all modulate state flags S/SA
tcpdump on the pflog0 interface as you suggested returns nothing being blocked when trying to connect -- not the internal IP, external IP, or ftp server. So I think the problem is with my config of ftp-proxy. There are currently 7 IP aliases on the external interface. I'm using -a and -S to specify which alias ftp-proxy should use, and I'm passing the -n flag to indicate we're using NAT. Is there something else I'm missing somewhere? >-----Original Message----- >From: Bob Beck [mailto:[EMAIL PROTECTED] >Sent: Monday, January 09, 2006 6:31 PM >To: Peter Landry >Cc: misc@openbsd.org >Subject: Re: ftp-proxy help needed... > > > Judging by the error message, likely you are either blocking the >outbound data channel connection to the real server, or the server >itself is filtering it. The first place I'd start looking >is in your "other" pf rules to see what's getting blocked. > > set your block rules to log stuff, and then tcpdump the pflog >interface looking for anything blocked that involves the real server >or your test client - then you'll see if one of your rules is >spanking something. > > i.e. > >tcpdump -n -i pflog0 host ftp.server.ip.addr or host client.machine.ip.addr > > -Bob > >* Peter Landry <[EMAIL PROTECTED]> [2006-01-09 15:20]: >> Hello list, >> I'm working on getting Active FTP Connections working (a requirement of >> an app used by a client) through our 3.8 firewall. Following the PF FAQ, >> I was able to get passive FTP working fine with the following pf.conf >> lines: >> >> rdr pass on $int_usr_if proto tcp from $int_usr_if:network to any port >> 21 -> \ >> 127.0.0.1 port 8021 >> and >> >> pass in on $ext_if inet proto tcp from any port 20 to any \ >> user proxy flags S/SA keep state >> >> When I attempt to make an outgoing connection, everything goes fine up >> until the data connection is attempted. >> >> (xxx.xxx.xxx.xxx is the ftp server IP) >> (yyy.yyy.yyy.yyy is our externally visible IP) >> >> pflog, as far as I can tell, doesn't show anything being blocked. >> tcpdump during the session produces a bunch of packets on port 21 for >> the control connection, and the following for ftp-data: >> 16:00:03.825620 xxx.xxx.xxx.xxx.ftp-data > yyy.yyy.yyy.yyy.50463: S >> 1112717906:1112717906(0) win 16384 <mss 1380,nop,nop,sackOK> (DF) >> 16:00:03.825648 yyy.yyy.yyy.yyy.50463 > xxx.xxx.xxx.xxx.ftp-data: S >> 399002834:399002834(0) ack 1112717907 win 16384 <mss >> 1460,nop,nop,sackOK> (DF) >> 16:00:03.831991 xxx.xxx.xxx.xxx.ftp-data > yyy.yyy.yyy.yyy.50463: . ack >> 1 win 16560 (DF) >> 16:00:03.838487 xxx.xxx.xxx.xxx.ftp-data > yyy.yyy.yyy.yyy.50463: P >> 1:1081(1080) ack 1 win 16560 (DF) >> 16:00:03.838611 xxx.xxx.xxx.xxx.ftp-data > yyy.yyy.yyy.yyy.50463: F >> 1081:1081(0) ack 1 win 16560 (DF) >> 16:00:03.838628 yyy.yyy.yyy.yyy.50463 > xxx.xxx.xxx.xxx.ftp-data: . ack >> 1082 win 15480 (DF) >> >> tail /var/log/daemon: >> Jan 9 15:55:27 maverick ftp-proxy[20164]: accepted connection from >> 192.168.0.37:4713 to xxx.xxx.xxx.xxx:21 >> Jan 9 15:55:27 maverick ftp-proxy[20164]: client: USER username\^M >> Jan 9 15:56:10 maverick ftp-proxy[17000]: cannot connect data channel >> (Connection timed out) >> >> >> The relevant /etc/inetd.conf line is as follows: >> 127.0.0.1:8021 stream tcp nowait root /usr/libexec/ftp-proxy >> ftp-proxy -n -a yyy.yyy.yyy.yyy -V -S yyy.yyy.yyy.yyy >> (yyy.yyy.yyy.yyy is the IP we nat from, it's an alias on em0) >> >> Just to clarify -- the ftp server isn't on our network, it's at a client >> site. >> >> >> Can anyone see anything I've missed in the config? I've tried many >> different options in both pf.conf and inetd.conf to no avail. Also, I >> realize ftp-proxy is being replaced in -current, but I'd like to get >> this working with the old ftp-proxy before trying -current (which I've >> never done before... could be dangerous). >> >> Any advice at all would be helpful. Thanks! >> Peter L. >> >> PS -- is posting tcpdump and logfile like I have done considered bad >> form? >> PPS -- a dmesg wouldn't really be helpful here, would it? >> > >-- >| | | The ASCII Fork Campaign > \|/ against gratuitous use of threads. > |
