Update: ftp-proxy and pf on OpenBSD 4.5

2010-03-10 Thread tsg12345 
Apologies first.

My first thought after waking up today was I mixed IPs and IFs.
Sorry for posting that...

Remaining question second.

The filtering does not seem to get populated by
ftp-proxy.

A rule like:
pass in on $client_if proto { tcp udp } from $client \
to 127.0.0.1 port ftp

does not do the trick, I still have to use something like:
pass in on $client_if proto { tcp udp } from $client \
to 127.0.0.1

(opening everything up for the ftp data connection myself)

kern.securelevel is 1, so I just do not understand why
ftp-proxy won't add the rules.

Any clue sticks, so I get at least a direction for my
search?


 Original-Nachricht 

 Hi list,
 
 I was trying to set up ftp-proxy for use with a client
 (OpenBSD 4.6 workstation, passive ftp only) behind a
 firewall (4.5).
 
 I have set up pf.conf on the firewall according to pf
 user's guide.
 
 All ftp-proxy anchors have been put first (nat/rdr before
 any nat/rdr rules, filtering before any filtering rules)
 so other rules should not affect them (filtering rules
 inserted by ftp-proxy are quick according to man, and
 first nat/rdr rule wins anyway).
 
 I use:
 set skip on lo
 (as I usually do)7
 
 and:
 ftp-proxy -d -D 7
 (for debugging).
 
 From my understanding the line
 rdr on $client_if proto tcp from $client to any port ftp - \
127.0.0.1 port 8021
 
 should cause the incoming connection to be
 1. redirected,
 2. not filtered (skip on lo),
 3. reach ftp-proxy and therefore
 4. enable ftp-proxy to populate the anchors.
 
 However, this seems not to happen (no connection,
 no output from ftp-proxy).
 
 When I add something like:
 pass in on $client_if from $client to any
 
 ftp-proxy lets me connect to the external ftp server
 (debug output of ftp-proxy is as one would expect it).
 
 But even something like:
 pass in on $client_if proto { tcp udp } from $client \
 to any port ftp
 
 does not work (and as explained above I would
 think that this is not necessary at all).
 
 Any ideas?
 
 
 
 -- 
 Sicherer, schneller und einfacher. Die aktuellen Internet-Browser -
 jetzt kostenlos herunterladen! http://portal.gmx.net/de/go/atbrowser

-- 
GMX DSL: Internet, Telefon und Entertainment f|r nur 19,99 EUR/mtl.!
http://portal.gmx.net/de/go/dsl02

Re: Update: ftp-proxy and pf on OpenBSD 4.5

2010-03-10 Thread Scott McEachern 

tsg12...@gmx.de wrote:

A rule like:
pass in on $client_if proto { tcp udp } from $client \
to 127.0.0.1 port ftp

does not do the trick, I still have to use something like:
pass in on $client_if proto { tcp udp } from $client \
to 127.0.0.1

(opening everything up for the ftp data connection myself)


Any clue sticks, so I get at least a direction for my
search?

  


You're passing the traffic in, but are you passing it back out?  Try 
enabling logging on your default block rule (you do block by default, 
right?) and see what's being blocked and where.


--

-RSM

http://www.erratic.ca

Re: Update: ftp-proxy and pf on OpenBSD 4.5

2010-03-10 Thread Vadim Zhukov 
On 10 March 2010 c. 12:09:07 tsg12...@gmx.de wrote:
 Apologies first.

 My first thought after waking up today was I mixed IPs and IFs.
 Sorry for posting that...

 Remaining question second.

 The filtering does not seem to get populated by
 ftp-proxy.

 A rule like:
 pass in on $client_if proto { tcp udp } from $client \
 to 127.0.0.1 port ftp

 does not do the trick, I still have to use something like:
 pass in on $client_if proto { tcp udp } from $client \
 to 127.0.0.1

You forgot that rdr rule mangles destination, _including_ port:

pass in on $client_if proto { tcp udp } from $client \
to 127.0.0.1 port 8021

Or just add pass after rdr in the rdr rule.

--
  Best wishes,
Vadim Zhukov

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?