On Fri, Jan 30, 2009 at 5:41 AM, Camiel Dobbelaar <c...@sentia.nl> wrote:
> (private) HKS wrote:
>> On Fri, Jan 23, 2009 at 3:06 PM, (private) HKS <hks.priv...@gmail.com> wrote:
>>> On Fri, Jan 23, 2009 at 8:49 AM, Daniel A. Ramaley
>>> <daniel.rama...@drake.edu> wrote:
>>>> I've gotten a couple of off-list replies with suggestions to try. I
>>>> greatly appreciate any ideas, but still have not had any luck so far.
>>>> I've trimmed my ruleset and adjust some of it to be more permissive.
>>>> Any ideas as to why ftp-proxy still doesn't work?
>>>>
>>>>
>>>>
>>>> ext_if = "vr0"
>>>> int_if = "fxp0"
>>>>
>>>> icmp_types = "{ echoreq, unreach }"
>>>>
>>>> # options
>>>> set block-policy return
>>>> set loginterface $ext_if
>>>> set skip on lo
>>>>
>>>> # packet hygiene
>>>> scrub in all fragment reassemble
>>>>
>>>> # nat
>>>> nat on $ext_if from !($ext_if) -> ($ext_if)
>>>> nat-anchor "ftp-proxy/*"
>>>> rdr-anchor "ftp-proxy/*"
>>>> rdr pass on $int_if proto tcp to port ftp -> 127.0.0.1 port 8021
>>>>
>>>> # filter rules
>>>> #block in all
>>>> #block quick inet6 all
>>>> anchor "ftp-proxy/*"
>>>> pass out keep state
>>>>
>>>> pass out quick proto tcp from lo to any port ftp
>>>>
>>>> pass in inet proto icmp all icmp-type $icmp_types keep state
>>>> #pass from !($ext_if) to any keep state
>>>> pass from any to any keep state
>>>
>>> Running ftp-proxy with the args "-r -d -D 6", can you do a packet
>>> capture when you run ls? You'll want to find all packets that involve
>>> the internal host, and all packets that involve your external
>>> destination, so you'll probably need to do two separate captures. This
>>> should at least give an idea of what's breaking.
>>
>>
>>
>> Something is definitely amiss. Does anybody have a working
>> nat/ftp-proxy setup with 4.4? If so, can you post your rules and
>> ftp-proxy flags?
>>
>> My 4.3 router is working fine, but when I try this on 4.4 I get some
>> very weird behavior. The anchor rules and such are all inserted
>> correctly and ftp-proxy -vv logs the following (munged for clarity)
>> repeatedly until I kill the connection or it times out:
>>
>> 11:42:32.540840 rule 331.19328.1.0/(match) pass in on $ext_if:
>> $server.20 > $client_private.1830: S 67547520:67547520(0) win 16384
>> <mss 1460,nop,nop,sackOK,nop,wscale 0,[|tcp]> (DF)
>> 11:42:32.540892 rule 331.19328.1.1/(match) pass out on $int_if:
>> $server.20 > $client_private.1830: S 67547520:67547520(0) win 16384
>> <mss 1460,nop,nop,sackOK,nop,wscale 0,[|tcp]> (DF)
>> 11:42:32.540911 rule 331/(match) pass out on $ext_if: $ext_ip >
>> $server: icmp: host $ext_ip unreachable
>>
>>
>> The second log entry refers to traffic that was supposedly passed, but
>> my packet sniffer on $int_if never saw it (I tested with tcpdump
>> filters 'host $client_private' and 'host $server'). The anchor
>> information is in there:
>>
>> # pfctl -a ftp-proxy/19328.1 -s rules
>> pass in log (all) quick inet proto tcp from $server to $client_private
>> port = 1830 flags S/SA keep state (max 1) rtable 0
>> pass out log (all) quick inet proto tcp from $server to
>> $client_private port = 1830 flags S/SA keep state (max 1) rtable 0
>> # pfctl -a ftp-proxy/19328.1 -s nat
>> nat inet proto tcp from $server to $client_private port = 1830 rtable
>> 0 -> 129.128.5.191 port 20
>> rdr inet proto tcp from $server to $ext_ip port = 63607 rtable 0 ->
>> 10.2.0.13 port 1830
>>
>>
>> The only block in pf.conf is a "block all" at the top. Aside from a
>> bunch of other pass statements, it looks very similar to what Daniel
>> posted before.
>>
>> Running ftp-proxy with: ftp-proxy -r -dvvD 7
>>
>> Can anyone else replicate this?
>
> Yes, I can reproduce it.  It looks like '-r' is the culprit.
>
> That's an option I would not recommend anyway, except if you have hosts
> that really need it.  Can you try again without -r ?
>
> Very little changed in ftp-proxy itself between 4.3 and 4.4 so I suspect
> the substantial changes in pf itself may have caused this to break.
>
> --
> Cam


Without -r things work just fine, but the shittiest ftp client I have
to test this is Windows 2003's native. What clients are known to
require the -r flag?

-HKS

Reply via email to