(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
