freebsd-pf Digest, Vol 275, Issue 1
freebsd-p...@freebsd.org
freeb...@freebsd.org
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.freebsd.org/mailman/listinfo/freebsd-pf
or, via email, send a message with subject or body 'help' to
freebsd-p...@freebsd.org
You can reach the person managing the list at
freebsd-...@freebsd.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of freebsd-pf digest..."
Today's Topics:
1. freebsd 8 (Kurt Turner)
2. RE: freebsd 8 (Patrick Goggins)
3. Re: ftp problem (J65nko)
4. setfib + pf + synproxy not working (Peter)
5. Re: setfib + pf + synproxy not working (Max Laier)
6. Re: setfib + pf + synproxy not working (Peter)
7. Re: freebsd 8 (Olivier Thibault)
8. Re: freebsd 8 (Peter Maxwell)
9. Re: freebsd 8 (Olivier Thibault)
10. Re: freebsd 8 (Peter Maxwell)
11. Re: How to export / save and compare PF rule sets
(Miroslav Lachman)
12. Re: freebsd 8 (Olivier Thibault)
13. Re: ftp problem (M. Keith Thompson)
14. Re: freebsd 8 (Kurt Turner)
15. Re: ftp problem (David DeSimone)
16. Re: ftp problem (M. Keith Thompson)
17. ftp problem (M. Keith Thompson)
18. Re: ftp problem (J65nko)
19. Re: ftp problem (M.Keith.Thompson )
20. Re: FW: clientNatLookup: PF open failed: (13) Permission
denied (Alex Povolotsky)
21. Re: FW: clientNatLookup: PF open failed: (13) Permission
denied (Alex Povolotsky)
22. Re: FW: clientNatLookup: PF open failed: (13) Permission
denied (jhell)
23. Current problem reports assigned to freeb...@FreeBSD.org
(FreeBSD bugmaster)
24. synproxy doesn't work after upgrading to RELENG_8_0
(Denis Shaposhnikov)
25. Re: conf/142817: [patch] etc/rc.d/pf: silence pfctl
(lin...@FreeBSD.org)
26. Re: conf/142817: [patch] etc/rc.d/pf: silence pfctl (Artis Caune)
27. Re: conf/142817: [patch] etc/rc.d/pf: silence pfctl
(Miroslav Lachman)
28. pf > round robin (kevin)
29. Re: pf > round robin (Miroslav Lachman)
----------------------------------------------------------------------
Message: 1
Date: Thu, 7 Jan 2010 16:27:20 -0600
From: Kurt Turner <ktu...@absolutenetworks.biz>
Subject: freebsd 8
To: freeb...@freebsd.org
Message-ID:
<40fc01eb1001071427g335...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Hello all
In an effort not to create yet another insecure server on the www I'd like
to ensure my pf.conf file is good and secure - will someone please review
this configuration and let me know your thoughts?
I only want to allow www and ssh inbound and have limited access also
outbound - this is a remote web server I do not have access to at all. TIA
#### First declare a couple of variables ####
# outgoing services
tcp_services = "{ ssh, smtp, domain, www, https, ntp, 43}"
udp_services = "{ domain, ntp }"
martians = "{ 127.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12, 10.0.0.0/8,
169.254.0.0/16, 192.0.2.0/24, 0.0.0.0/8, 240.0.0.0/4 }"
ext_if = "re0" # Internet
#### Normalization
scrub in all
#### Start filtering
# Drop incoming everything
block in all
# Default connection refused message to client
block return
# keep stats of outging connections
pass out keep state
# activate spoofing protection for all interfaces
block in quick from urpf-failed
# Antispoof is a common special case of filtering and blocking. This
mechanism protects against activity from spoofed or forged IP addresses
antispoof log for $ext_if
#Block RFC 1918 addresses
block drop in log (all) quick on $ext_if from $martians to any
block drop out log (all) quick on $ext_if from any to $martians
# Allow outgoing via ssh, smtp, domain, www, https, whois etc
pass out on $ext_if proto tcp to any port $tcp_services
pass out on $ext_if proto udp to any port $udp_services
# Allow outgoing Trace route
pass out on $ext_if inet proto udp from any to any port 33433 >< 33626 keep
state
# Allow http traffic
pass in on $ext_if proto tcp from any to any port 80 flags S/SA synproxy
modulate state
# SSH
pass in on $ext_if proto tcp from any to any port 22 flags S/SA synproxy
modulate state
------------------------------
Message: 2
Date: Thu, 7 Jan 2010 19:46:48 -0600
From: Patrick Goggins <pgog...@carrollu.edu>
Subject: RE: freebsd 8
To: "freeb...@freebsd.org" <freeb...@freebsd.org>
Message-ID:
<23E3A2C29073ED4CB8EAE...@CMAIL.carrollu.edu>
Content-Type: text/plain; charset="us-ascii"
I would not recommend allowing everyone under the sun ssh access to the box. Either restrict it by outside IP if possible and if that is not possible at least alter the port to prevent bots.
~Patrick
-----Original Message-----
From: owner-fr...@freebsd.org [mailto:owner-fr...@freebsd.org] On Behalf Of Kurt Turner
Sent: Thursday, January 07, 2010 4:27 PM
To: freeb...@freebsd.org
Subject: freebsd 8
Hello all
In an effort not to create yet another insecure server on the www I'd like
to ensure my pf.conf file is good and secure - will someone please review
this configuration and let me know your thoughts?
I only want to allow www and ssh inbound and have limited access also
outbound - this is a remote web server I do not have access to at all. TIA
#### First declare a couple of variables ####
# outgoing services
tcp_services = "{ ssh, smtp, domain, www, https, ntp, 43}"
udp_services = "{ domain, ntp }"
martians = "{ 127.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12, 10.0.0.0/8,
169.254.0.0/16, 192.0.2.0/24, 0.0.0.0/8, 240.0.0.0/4 }"
ext_if = "re0" # Internet
#### Normalization
scrub in all
#### Start filtering
# Drop incoming everything
block in all
# Default connection refused message to client
block return
# keep stats of outging connections
pass out keep state
# activate spoofing protection for all interfaces
block in quick from urpf-failed
# Antispoof is a common special case of filtering and blocking. This
mechanism protects against activity from spoofed or forged IP addresses
antispoof log for $ext_if
#Block RFC 1918 addresses
block drop in log (all) quick on $ext_if from $martians to any
block drop out log (all) quick on $ext_if from any to $martians
# Allow outgoing via ssh, smtp, domain, www, https, whois etc
pass out on $ext_if proto tcp to any port $tcp_services
pass out on $ext_if proto udp to any port $udp_services
# Allow outgoing Trace route
pass out on $ext_if inet proto udp from any to any port 33433 >< 33626 keep
state
# Allow http traffic
pass in on $ext_if proto tcp from any to any port 80 flags S/SA synproxy
modulate state
# SSH
pass in on $ext_if proto tcp from any to any port 22 flags S/SA synproxy
modulate state
------------------------------
Message: 3
Date: Fri, 8 Jan 2010 05:18:48 +0100
From: J65nko <j65...@gmail.com>
Subject: Re: ftp problem
To: "M. Keith Thompson" <m.keith....@gmail.com>
Cc: freeb...@freebsd.org
Message-ID:
<19861fba1001072018g115...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
On Thu, Jan 7, 2010 at 10:19 PM, M. Keith Thompson
<m.keith....@gmail.com> wrote:
> On Thu, Jan 7, 2010 at 2:37 PM, J65nko <j65...@gmail.com> wrote:
>>> # SSH from NetEng subnet
>>> pass in quick log on $ext_if proto tcp from $net_eng to $ext_if port
>>> 22 keep state
>>>
>>> # Allow inside network to ping the server
>>> pass in quick on $ext_if proto icmp from $pingers to $ext_IP keep state
>>>
>>> # Allow DNS lookups
>>> pass out quick on $ext_if proto udp to any port 53
>>> pass out quick on $ext_if proto tcp to any port 53 keep state
>>>
>>> # Allow ftp
>>> pass in quick on $ext_if proto tcp from any to $ext_IP port 21 keep state
>>> pass in quick on $ext_if proto tcp from any to $ext_IP port > 49151 keep state
>>> pass in quick on $ext_if proto tcp from any port > 10000 to $ext_IP
>>> port 20 keep state
>>>
>>> --- end of pf.conf ----------------------
With ftp the client initiates the ftp command channel
client:port >1023 ---> server:port 21
The passive ftp data channel is initiated by the client
client:port >1023 ---> server:port>1023
Your second rule takes care of this
The active ftp data channel is initiated by the ftp server
using and that is kind of weird, port 20 (ftp-data), as source port.
server:port 20 ---> clientLport >1023
You meant to pass active ftp with this rule:
>>> pass in quick on $ext_if proto tcp from any port > 10000 to $ext_IP
>>> port 20 keep state
But it should be:
pass out quick on $ext_if inet proto tcp from any port ftp-data
to $ext_IP port > 10000 keep state
BTW you have a nice pf debug friendly "block log all" default policy.
Does "tcpdump -eni pflog0" on the pf box show any blocked packets?
RE: ftp-proxy
This just adds complexitiy, after everything is working you could add it in.
RE: active ftp user requirement
Yes, I understand, it is the users who help us pay our mortgage ;)
------------------------------
Message: 4
Date: Thu, 7 Jan 2010 22:04:34 -0700
From: "Peter" <fb...@peterk.org>
Subject: setfib + pf + synproxy not working
To: freeb...@freebsd.org
Message-ID: <25cb73eeb5cb6830aefd...@pop.pknet.net>
Content-Type: text/plain;charset=iso-8859-1
iH,
Playing around with FIBs and jails.
The host system is on a private 172.xxx network with a gateway of 172.xxx
going through a NAT box for internet. [fib 0]
The jail has only a public IP, on fib 1 [with gateway being ISP router]
With this, the jail is working fine.
What I'm trying to accomplish is portknocking for 'ssh' access:
pass in log quick proto tcp from any to any port {1234} synproxy state \
(max-src-conn-rate 5/15, overload <portknock_ssh>)
Because the jail is on 'fib 1', the connection is never established to
overload the rule. The 'synproxy state' is communicating via the
172.xxxx/default gateway [of fib 0] instead of via the public "fib 1"
I can ssh into the jail if I do
pass in log quick proto tcp from any to any port {22} keep state
I CANNOT ssh into the jail if I do
pass in log quick proto tcp from any to any port {22} synproxy state
Anyway I can force 'synproxy' to communicate via fib 1 ?
]Peter[
------------------------------
Message: 5
Date: Fri, 8 Jan 2010 06:55:43 +0100
From: Max Laier <m...@love2party.net>
Subject: Re: setfib + pf + synproxy not working
To: freeb...@freebsd.org
Message-ID: <20100108065...@love2party.net>
Content-Type: Text/Plain; charset="iso-8859-1"
On Friday 08 January 2010 06:04:34 Peter wrote:
> iH,
> Playing around with FIBs and jails.
>
> The host system is on a private 172.xxx network with a gateway of 172.xxx
> going through a NAT box for internet. [fib 0]
>
> The jail has only a public IP, on fib 1 [with gateway being ISP router]
>
> With this, the jail is working fine.
>
> What I'm trying to accomplish is portknocking for 'ssh' access:
>
> pass in log quick proto tcp from any to any port {1234} synproxy state \
> (max-src-conn-rate 5/15, overload <portknock_ssh>)
>
> Because the jail is on 'fib 1', the connection is never established to
> overload the rule. The 'synproxy state' is communicating via the
> 172.xxxx/default gateway [of fib 0] instead of via the public "fib 1"
>
> I can ssh into the jail if I do
> pass in log quick proto tcp from any to any port {22} keep state
>
> I CANNOT ssh into the jail if I do
> pass in log quick proto tcp from any to any port {22} synproxy state
>
> Anyway I can force 'synproxy' to communicate via fib 1 ?
I don't think I understand your setup and intent completely, but you can
select a fib with the "rtable" filter parameter. It *should* be used for the
synproxy communication, as well. Please report if this helps.
--
Max
------------------------------
Message: 6
Date: Fri, 8 Jan 2010 00:29:36 -0700
From: "Peter" <fb...@peterk.org>
Subject: Re: setfib + pf + synproxy not working
To: "Max Laier" <m...@love2party.net>
Cc: freeb...@freebsd.org
Message-ID: <ef0235efb1bee512b72f...@pop.pknet.net>
Content-Type: text/plain;charset=iso-8859-1
> On Friday 08 January 2010 06:04:34 Peter wrote:
>> iH,
>> Playing around with FIBs and jails.
>>
>> The host system is on a private 172.xxx network with a gateway of
>> 172.xxx
>> going through a NAT box for internet. [fib 0]
>>
>> The jail has only a public IP, on fib 1 [with gateway being ISP router]
>>
>> With this, the jail is working fine.
>>
>> What I'm trying to accomplish is portknocking for 'ssh' access:
>>
>> pass in log quick proto tcp from any to any port {1234} synproxy state \
>> (max-src-conn-rate 5/15, overload <portknock_ssh>)
>>
>> Because the jail is on 'fib 1', the connection is never established to
>> overload the rule. The 'synproxy state' is communicating via the
>> 172.xxxx/default gateway [of fib 0] instead of via the public "fib 1"
>>
>> I can ssh into the jail if I do
>> pass in log quick proto tcp from any to any port {22} keep state
>>
>> I CANNOT ssh into the jail if I do
>> pass in log quick proto tcp from any to any port {22} synproxy state
>>
>> Anyway I can force 'synproxy' to communicate via fib 1 ?
>
> I don't think I understand your setup and intent completely, but you can
> select a fib with the "rtable" filter parameter. It *should* be used for
> the
> synproxy communication, as well. Please report if this helps.
>
> --
> Max
>
host: 172.xxx -> gateway = 172.xxx.1 [NAT] -> 216.241.167.YY [fib 0/default]
jail: 216.241.167.XX -> gateway = 216.241.167.1 [jail started on fib 1]
fib0: gateway = 172.xxx.1 [host]
fib1: gateway = 216.241.167.1 [jail]
With jail on fib 1, and different gateway vs. the host system itself,
'synproxy' does not work.
With rtable, I'm still NOT able to connect to jail from outside:
pass in log quick proto tcp from any to any port = ssh synproxy state
rtable 1
[/sbin/pfctl -nf /etc/pf.conf && /sbin/pfctl -f /etc/pf.conf]
If I remove 'synproxy state' and put in 'keep state' it works.
FreeBSD stable/8
]Peter[
------------------------------
Message: 7
Date: Fri, 08 Jan 2010 09:19:46 +0100
From: Olivier Thibault <Olivier....@lmpt.univ-tours.fr>
Subject: Re: freebsd 8
To: Kurt Turner <ktu...@absolutenetworks.biz>
Cc: freeb...@freebsd.org
Message-ID: <4B46EAA2...@lmpt.univ-tours.fr>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Hello,
Le 07.01.2010 23:27, Kurt Turner a �crit :
> Hello all
>
> In an effort not to create yet another insecure server on the www I'd like
> to ensure my pf.conf file is good and secure - will someone please review
> this configuration and let me know your thoughts?
>
> I only want to allow www and ssh inbound and have limited access also
> outbound - this is a remote web server I do not have access to at all. TIA
>
...
> # keep stats of outging connections
> pass out keep state
This rule allows everything out and next outgoing rules won't be checked as this
one first match.
The "keep state" keyword is also not necessary any more since FreeBSD 7. It is
implicit.
Maybe you can just write "block return all", which implies in and out in the
same rule.
Best regards,
--
Olivier THIBAULT
Universit� Fran�ois Rabelais - UFR Sciences et Techniques
Laboratoire de Math�matiques et Physique Th�orique (UMR CNRS 6083)
Service Informatique de l'UFR
Parc de Grandmont
37200 Tours - France
Email: olivier.thibault at lmpt.univ-tours.fr
Tel: (33)(0)2 47 36 69 12
Fax: (33)(0)2 47 36 70 68
Mobile : (33)(0)6 62 60 80 44
------------------------------
Message: 8
Date: Fri, 8 Jan 2010 10:31:18 +0000
From: Peter Maxwell <pe...@allicient.co.uk>
Subject: Re: freebsd 8
To: Olivier Thibault <Olivier....@lmpt.univ-tours.fr>
Cc: freeb...@freebsd.org
Message-ID:
<7731938b1001080231p75e...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
2010/1/8 Olivier Thibault <Olivier....@lmpt.univ-tours.fr>:
>> # keep stats of outging connections
>> pass out keep state
>
> This rule allows everything out and next outgoing rules won't be checked as
> this one first match.
That's incorrect, pf does the opposite and uses the *last* match - at
least that's what the documentation says...
http://www.openbsd.org/faq/pf/filter.html
The quick keyword is used for shortcut evaluation.
------------------------------
Message: 9
Date: Fri, 08 Jan 2010 11:38:32 +0100
From: Olivier Thibault <Olivier....@lmpt.univ-tours.fr>
Subject: Re: freebsd 8
To: freeb...@freebsd.org
Message-ID: <4B470B28...@lmpt.univ-tours.fr>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Le 08.01.2010 11:31, Peter Maxwell a �crit :
> 2010/1/8 Olivier Thibault <Olivier....@lmpt.univ-tours.fr>:
>
>>> # keep stats of outging connections
>>> pass out keep state
>> This rule allows everything out and next outgoing rules won't be checked as
>> this one first match.
>
> That's incorrect, pf does the opposite and uses the *last* match - at
> least that's what the documentation says...
> http://www.openbsd.org/faq/pf/filter.html
>
> The quick keyword is used for shortcut evaluation.
Yes ! Actually, all the following rules in my pf.conf use this keyword.
That's why I said that.
I suppose the rules evaluation is quicker this way but I may be wrong.
Am I ?
Best regards,
--
Olivier THIBAULT
Universit� Fran�ois Rabelais - UFR Sciences et Techniques
Laboratoire de Math�matiques et Physique Th�orique (UMR CNRS 6083)
Service Informatique de l'UFR
Parc de Grandmont
37200 Tours - France
Email: olivier.thibault at lmpt.univ-tours.fr
Tel: (33)(0)2 47 36 69 12
Fax: (33)(0)2 47 36 70 68
Mobile : (33)(0)6 62 60 80 44
------------------------------
Message: 10
Date: Fri, 8 Jan 2010 11:14:59 +0000
From: Peter Maxwell <pe...@allicient.co.uk>
Subject: Re: freebsd 8
To: Olivier Thibault <Olivier....@lmpt.univ-tours.fr>
Cc: freeb...@freebsd.org
Message-ID:
<7731938b1001080314k1de...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
2010/1/8 Olivier Thibault <Olivier....@lmpt.univ-tours.fr>:
> Le 08.01.2010 11:31, Peter Maxwell a �crit :
>>
>> 2010/1/8 Olivier Thibault <Olivier....@lmpt.univ-tours.fr>:
>>
>>>> # keep stats of outging connections
>>>> pass out keep state
>>>
>>> This rule allows everything out and next outgoing rules won't be checked
>>> as
>>> this one first match.
>>
>> That's incorrect, pf does the opposite and uses the *last* match - at
>> least that's what the documentation says...
>> http://www.openbsd.org/faq/pf/filter.html
>>
>> The quick keyword is used for shortcut evaluation.
>
> Yes ! Actually, all the following rules in my pf.conf use this keyword.
> That's why I said that.
> I suppose the rules evaluation is quicker this way but I may be wrong.
> Am I ?
Erm, mostly wrong... it wouldn't improve performance if even a
majority of your rules use it, in that case all you've done is change
last match processing to first match processing.
If when pf is actually processing packets (this is not the same as
loading your rule set), lets assume that the packets are evaluated
against each rule in a sequential manner. With that assumption,
having most of your rules *without* the quick keyword then only use
quick for those rules near the top of your ruleset that process a
large amount of new connections (again, not synonymous with traffic -
it's new connections that matter), in that case you may see a
performance improvement. For example, say you have a complex ruleset
but lots of incoming connections on port 80 - then using the quick
keyword and placing the rule near the top of your ruleset may improve
things.
However, that assumes pf goes through the rules in a sequential manner
when actually processing packets - that may not be true. My advice
would be to put a single 'block all' rule at the top, then have the
remainder of your rules doing 'pass': it is much much easier to read
and debug. What is more valuable to you, saving hours on debuging a
firewall box or a 2% performance improvement? It is also unlikely
you'd be getting enough traffic to warrant the use of 'quick' ;-)
Most other packet filters/firewalls I've used use match first.
Logically using match last is no different (you essentially just write
your rule set upside-down), but it is actually my preference.
------------------------------
Message: 11
Date: Fri, 08 Jan 2010 13:21:11 +0100
From: Miroslav Lachman <000....@quip.cz>
Subject: Re: How to export / save and compare PF rule sets
To: Max Laier <m...@love2party.net>
Cc: freeb...@freebsd.org
Message-ID: <4B472337...@quip.cz>
Content-Type: text/plain; charset=ISO-8859-2; format=flowed
Hi Max,
can you take a look at my problem again?
I don't want to make you angry, I am just trying to better understand
things and found if the problem is on my side or some inconsistency of
the pfctl output.
Thanks in advance for your help.
Miroslav Lachman
Miroslav Lachman wrote:
> Max Laier wrote:
>> On Wednesday 23 December 2009 00:50:09 Miroslav Lachman wrote:
>>> scrub is before nat/rdr rules in case of "pfctl -s a" and after nat/rdr
>>> in case of "pfctl -nvf /etc/pf.conf"
>>
>> The order should always be options, scrub, queues, nat, filters. pfctl
>> -nvf
>> only works with a different order if you have "set require-order no"
>> in your
>> ruleset. You should be able to fix this at your end.
>
> I have things in this order in my pf.conf:
> macros
> tables
> options
> scrub
> nat
> rdr
> pass/block rules
>
> I don't have "set require-order no" in pf.conf, the only options I have
> are:
> set timeout { interval 10, frag 20 }
> set limit { states 10000, frags 5000 }
> set optimization aggressive
> set block-policy return
> set skip on $unfiltered
>
> then:
> scrub in on $ext_if
> scrub out on $ext_if no-df random-id max-mss 1492
>
> nat pass on $ext_if from $vpn_sectun_net to any -> $ext_addr_0
> rdr pass on $ext_if inet proto tcp from <goodguys> to $ext_addr_0 port
> 10443 -> $pdu_addr_0 port 443
> rdr pass on $ext_if inet proto tcp from <goodguys> to $ext_addr_0 port
> 11443 -> $pdu_addr_1 port 443
> rdr pass on $ext_if inet proto tcp from <goodguys> to $ext_addr_0 port
> 12443 -> $pdu_addr_2 port 443
>
> So do I have to change anything? I think I have it in the right order.
> That's why I asked the question here.
>
> The problem is that "pfctl -s a" shows
> TRANSLATION RULES:
> (some NAT/RDR here)
>
> FILTER RULES:
> scrub in on bge1 all fragment reassemble
> scrub out on bge1 all no-df random-id max-mss 1492 fragment reassemble
> pass in quick proto tcp from <goodguys> to any flags S/SA keep state
> block return in log quick from <badguys> to any
>
> As you can see - scrub is in the FILTER RULES section of the output, but
> in pf.conf (required according to manpage) scrub is before TRANSLATION
> RULES and pfctl -nvf print it in this (right) order.
>
>>> Is there any other way how can I export live and saved rules in the same
>>> format and the same order, ready to comparission by diff?
>>
>> you can always extract the parts individually and cat them together if
>> you
>> insist on keeping the ruleset unordered.
>
> I was trying to do it in one pass (speed optimization ;])
------------------------------
Message: 12
Date: Fri, 08 Jan 2010 14:33:29 +0100
From: Olivier Thibault <Olivier....@lmpt.univ-tours.fr>
Subject: Re: freebsd 8
To: Peter Maxwell <pe...@allicient.co.uk>
Cc: freeb...@freebsd.org
Message-ID: <4B473429...@lmpt.univ-tours.fr>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Hi,
Thanks a lot for your answer and explanations.
This will be very helpfull to me and I will update my pf.conf.
Thanks again.
Olivier
Le 08.01.2010 12:14, Peter Maxwell a �crit :
> 2010/1/8 Olivier Thibault <Olivier....@lmpt.univ-tours.fr>:
>> Le 08.01.2010 11:31, Peter Maxwell a �crit :
>>> 2010/1/8 Olivier Thibault <Olivier....@lmpt.univ-tours.fr>:
>>>
>>>>> # keep stats of outging connections
>>>>> pass out keep state
>>>> This rule allows everything out and next outgoing rules won't be checked
>>>> as
>>>> this one first match.
>>> That's incorrect, pf does the opposite and uses the *last* match - at
>>> least that's what the documentation says...
>>> http://www.openbsd.org/faq/pf/filter.html
>>>
>>> The quick keyword is used for shortcut evaluation.
>> Yes ! Actually, all the following rules in my pf.conf use this keyword.
>> That's why I said that.
>> I suppose the rules evaluation is quicker this way but I may be wrong.
>> Am I ?
>
> Erm, mostly wrong... it wouldn't improve performance if even a
> majority of your rules use it, in that case all you've done is change
> last match processing to first match processing.
>
> If when pf is actually processing packets (this is not the same as
> loading your rule set), lets assume that the packets are evaluated
> against each rule in a sequential manner. With that assumption,
> having most of your rules *without* the quick keyword then only use
> quick for those rules near the top of your ruleset that process a
> large amount of new connections (again, not synonymous with traffic -
> it's new connections that matter), in that case you may see a
> performance improvement. For example, say you have a complex ruleset
> but lots of incoming connections on port 80 - then using the quick
> keyword and placing the rule near the top of your ruleset may improve
> things.
>
> However, that assumes pf goes through the rules in a sequential manner
> when actually processing packets - that may not be true. My advice
> would be to put a single 'block all' rule at the top, then have the
> remainder of your rules doing 'pass': it is much much easier to read
> and debug. What is more valuable to you, saving hours on debuging a
> firewall box or a 2% performance improvement? It is also unlikely
> you'd be getting enough traffic to warrant the use of 'quick' ;-)
>
> Most other packet filters/firewalls I've used use match first.
> Logically using match last is no different (you essentially just write
> your rule set upside-down), but it is actually my preference.
--
Olivier THIBAULT
Universit� Fran�ois Rabelais - UFR Sciences et Techniques
Laboratoire de Math�matiques et Physique Th�orique (UMR CNRS 6083)
Service Informatique de l'UFR
Parc de Grandmont
37200 Tours - France
Email: olivier.thibault at lmpt.univ-tours.fr
Tel: (33)(0)2 47 36 69 12
Fax: (33)(0)2 47 36 70 68
Mobile : (33)(0)6 62 60 80 44
------------------------------
Message: 13
Date: Fri, 8 Jan 2010 07:51:30 -0600
From: "M. Keith Thompson" <m.keith....@gmail.com>
Subject: Re: ftp problem
To: J65nko <j65...@gmail.com>
Cc: freeb...@freebsd.org
Message-ID:
<fc2243911001080551n251...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
On Thu, Jan 7, 2010 at 10:18 PM, J65nko <j65...@gmail.com> wrote:
> On Thu, Jan 7, 2010 at 10:19 PM, M. Keith Thompson
> <m.keith....@gmail.com> wrote:
>> On Thu, Jan 7, 2010 at 2:37 PM, J65nko <j65...@gmail.com> wrote:
>>>> # SSH from NetEng subnet
>>>> pass in quick log on $ext_if proto tcp from $net_eng to $ext_if port
>>>> 22 keep state
>>>>
>>>> # Allow inside network to ping the server
>>>> pass in quick on $ext_if proto icmp from $pingers to $ext_IP keep state
>>>>
>>>> # Allow DNS lookups
>>>> pass out quick on $ext_if proto udp to any port 53
>>>> pass out quick on $ext_if proto tcp to any port 53 keep state
>>>>
>>>> # Allow ftp
>>>> pass in quick on $ext_if proto tcp from any to $ext_IP port 21 keep state
>>>> pass in quick on $ext_if proto tcp from any to $ext_IP port > 49151 keep state
>>>> pass in quick on $ext_if proto tcp from any port > 10000 to $ext_IP
>>>> port 20 keep state
>>>>
>>>> --- end of pf.conf �----------------------
>
> With ftp the client initiates the ftp command channel
> � client:port >1023 � ---> server:port 21
>
> The passive ftp data channel is initiated by the client
> � �client:port >1023 �---> server:port>1023
>
> Your second rule takes care of this
>
> The active ftp data channel is initiated by the ftp server
> using and that is kind of weird, port 20 (ftp-data), as source port.
> � � �server:port 20 � ---> clientLport >1023
>
> You meant to pass active ftp with this rule:
>
>>>> pass in quick on $ext_if proto tcp from any port > 10000 to $ext_IP
>>>> port 20 keep state
>
> But it should be:
> � �pass out quick on $ext_if inet proto tcp from any port ftp-data
> � �to $ext_IP port > 10000 keep state
I will make that change
> BTW you have a nice pf debug friendly "block log all" default policy.
> Does "tcpdump -eni pflog0" on the pf box show any blocked packets?
tcpdump of the pflog0 does not show any packets from or to the IP in question.
> RE: ftp-proxy
> This just adds complexitiy, after everything is working you could add it in.
>
> RE: active ftp user requirement
> Yes, I understand, it is the users who help us pay our mortgage ;)
>
------------------------------
Message: 14
Date: Fri, 8 Jan 2010 09:00:13 -0600
From: Kurt Turner <ktu...@absolutenetworks.biz>
Subject: Re: freebsd 8
To: freeb...@freebsd.org
Message-ID:
<40fc01eb1001080700o6c2...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Thank you all for your help.
> Le 08.01.2010 12:14, Peter Maxwell a �crit :
>
> 2010/1/8 Olivier Thibault <Olivier....@lmpt.univ-tours.fr>:
>>
>>> Le 08.01.2010 11:31, Peter Maxwell a �crit :
>>>
>>>> 2010/1/8 Olivier Thibault <Olivier....@lmpt.univ-tours.fr>:
>>>>
>>>> # keep stats of outging connections
>>>>>> pass out keep state
>>>>>>
>>>>> This rule allows everything out and next outgoing rules won't be
>>>>> checked
>>>>> as
>>>>> this one first match.
>>>>>
>>>> That's incorrect, pf does the opposite and uses the *last* match - at
>>>> least that's what the documentation says...
>>>> http://www.openbsd.org/faq/pf/filter.html
>>>>
>>>> The quick keyword is used for shortcut evaluation.
>>>>
>>> Yes ! Actually, all the following rules in my pf.conf use this keyword.
>>> That's why I said that.
>>> I suppose the rules evaluation is quicker this way but I may be wrong.
>>> Am I ?
>>>
>>
>> Erm, mostly wrong... it wouldn't improve performance if even a
>> majority of your rules use it, in that case all you've done is change
>> last match processing to first match processing.
>>
>> If when pf is actually processing packets (this is not the same as
>> loading your rule set), lets assume that the packets are evaluated
>> against each rule in a sequential manner. With that assumption,
>> having most of your rules *without* the quick keyword then only use
>> quick for those rules near the top of your ruleset that process a
>> large amount of new connections (again, not synonymous with traffic -
>> it's new connections that matter), in that case you may see a
>> performance improvement. For example, say you have a complex ruleset
>> but lots of incoming connections on port 80 - then using the quick
>> keyword and placing the rule near the top of your ruleset may improve
>> things.
>>
>> However, that assumes pf goes through the rules in a sequential manner
>> when actually processing packets - that may not be true. My advice
>> would be to put a single 'block all' rule at the top, then have the
>> remainder of your rules doing 'pass': it is much much easier to read
>> and debug. What is more valuable to you, saving hours on debuging a
>> firewall box or a 2% performance improvement? It is also unlikely
>> you'd be getting enough traffic to warrant the use of 'quick' ;-)
>>
>> Most other packet filters/firewalls I've used use match first.
>> Logically using match last is no different (you essentially just write
>> your rule set upside-down), but it is actually my preference.
>>
>
>
> --
> Olivier THIBAULT
> Universit� Fran�ois Rabelais - UFR Sciences et Techniques
> Laboratoire de Math�matiques et Physique Th�orique (UMR CNRS 6083)
> Service Informatique de l'UFR
> Parc de Grandmont
> 37200 Tours - France
> Email: olivier.thibault at lmpt.univ-tours.fr
> Tel: (33)(0)2 47 36 69 12
> Fax: (33)(0)2 47 36 70 68
> Mobile : (33)(0)6 62 60 80 44
>
> _______________________________________________
> freeb...@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-pf
> To unsubscribe, send any mail to "freebsd-pf-...@freebsd.org"
>
------------------------------
Message: 15
Date: Fri, 8 Jan 2010 10:31:11 -0600
From: "David DeSimone" <f...@verio.net>
Subject: Re: ftp problem
To: <freeb...@freebsd.org>
Message-ID: <2010010816...@verio.net>
Content-Type: text/plain; charset="us-ascii"
J65nko <j65...@gmail.com> wrote:
>
> You meant to pass active ftp with this rule:
>
> >>> pass in quick on $ext_if proto tcp from any port > 10000 to $ext_IP
> >>> port 20 keep state
>
> But it should be:
> pass out quick on $ext_if inet proto tcp from any port ftp-data
> to $ext_IP port > 10000 keep state
Are you sure you don't mean:
pass out quick on $ext_if inet proto tcp from $ext_IP port ftp-data \
to any port > 10000 keep state
--
David DeSimone == Network Admin == f...@verio.net
"I don't like spinach, and I'm glad I don't, because if I
liked it I'd eat it, and I just hate it." -- Clarence Darrow
This email message is intended for the use of the person to whom it has been sent, and may contain information that is confidential or legally protected. If you are not the intended recipient or have received this message in error, you are not authorized to copy, distribute, or otherwise use this message or its attachments. Please notify the sender immediately by return e-mail and permanently delete this message and any attachments. Verio, Inc. makes no warranty that this email is error or virus free. Thank you.
------------------------------
Message: 16
Date: Fri, 8 Jan 2010 14:50:56 -0600
From: "M. Keith Thompson" <m.keith....@gmail.com>
Subject: Re: ftp problem
To: J65nko <j65...@gmail.com>
Cc: freeb...@freebsd.org
Message-ID:
<fc2243911001081250n447...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
It looks like it was a tcp windowing problem. The command: "sysctl -w
sysctl net.inet.tcp.rfc1323=0"
fixed the problem.
Thanks for all of the suggestions and help.
On Fri, Jan 8, 2010 at 7:51 AM, M. Keith Thompson
<m.keith....@gmail.com> wrote:
> On Thu, Jan 7, 2010 at 10:18 PM, J65nko <j65...@gmail.com> wrote:
>> On Thu, Jan 7, 2010 at 10:19 PM, M. Keith Thompson
>> <m.keith....@gmail.com> wrote:
>>> On Thu, Jan 7, 2010 at 2:37 PM, J65nko <j65...@gmail.com> wrote:
>>>>> # SSH from NetEng subnet
>>>>> pass in quick log on $ext_if proto tcp from $net_eng to $ext_if port
>>>>> 22 keep state
>>>>>
>>>>> # Allow inside network to ping the server
>>>>> pass in quick on $ext_if proto icmp from $pingers to $ext_IP keep state
>>>>>
>>>>> # Allow DNS lookups
>>>>> pass out quick on $ext_if proto udp to any port 53
>>>>> pass out quick on $ext_if proto tcp to any port 53 keep state
>>>>>
>>>>> # Allow ftp
>>>>> pass in quick on $ext_if proto tcp from any to $ext_IP port 21 keep state
>>>>> pass in quick on $ext_if proto tcp from any to $ext_IP port > 49151 keep state
>>>>> pass in quick on $ext_if proto tcp from any port > 10000 to $ext_IP
>>>>> port 20 keep state
>>>>>
>>>>> --- end of pf.conf �----------------------
>>
>> With ftp the client initiates the ftp command channel
>> � client:port >1023 � ---> server:port 21
>>
>> The passive ftp data channel is initiated by the client
>> � �client:port >1023 �---> server:port>1023
>>
>> Your second rule takes care of this
>>
>> The active ftp data channel is initiated by the ftp server
>> using and that is kind of weird, port 20 (ftp-data), as source port.
>> � � �server:port 20 � ---> clientLport >1023
>>
>> You meant to pass active ftp with this rule:
>>
>>>>> pass in quick on $ext_if proto tcp from any port > 10000 to $ext_IP
>>>>> port 20 keep state
>>
>> But it should be:
>> � �pass out quick on $ext_if inet proto tcp from any port ftp-data
>> � �to $ext_IP port > 10000 keep state
>
> I will make that change
>
>> BTW you have a nice pf debug friendly "block log all" default policy.
>> Does "tcpdump -eni pflog0" on the pf box show any blocked packets?
>
> tcpdump of the pflog0 does not show any packets from or to the IP in question.
>
>> RE: ftp-proxy
>> This just adds complexitiy, after everything is working you could add it in.
>>
>> RE: active ftp user requirement
>> Yes, I understand, it is the users who help us pay our mortgage ;)
>>
>
------------------------------
Message: 17
Date: Fri, 8 Jan 2010 15:05:05 -0600
From: "M. Keith Thompson" <m.keith....@gmail.com>
Subject: ftp problem
To: freeb...@freebsd.org
Message-ID:
<fc2243911001081305w1a...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Yes, that is what he meant and I fixed it.
------------------------------
Message: 18
Date: Fri, 8 Jan 2010 23:50:54 +0100
From: J65nko <j65...@gmail.com>
Subject: Re: ftp problem
To: "M. Keith Thompson" <m.keith....@gmail.com>
Cc: freeb...@freebsd.org
Message-ID:
<19861fba1001081450w4d9...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
On Fri, Jan 8, 2010 at 9:50 PM, M. Keith Thompson
<m.keith....@gmail.com> wrote:
> It looks like it was a tcp windowing problem. The command: "sysctl -w
> sysctl net.inet.tcp.rfc1323=0"
> fixed the problem.
This only fixes a symptom. :) There is something wrong with your ruleset.
>>> # Allow ftp
>>> pass in quick on $ext_if proto tcp from any to $ext_IP port 21 keep state
>>> pass in quick on $ext_if proto tcp from any to $ext_IP port > 49151 keep state
>>> pass in quick on $ext_if proto tcp from any port > 10000 to $ext_IP
>>> port 20 keep state
With this active ftp rule you had before, the HP client could initiate
and transfer over an active ftp data channel,
while this rule does not allow this at all.
There shouldn't be any active ftp datachannel communication possible
because port 20 is the source port and not the destination port.
I tried the following pf.conf , with a similar ftp-data rule , on a
local FreeBSD 7.2 box in my network
EXT_IF=fxp0
# net.inet.ip.portrange.hilast: 65535
# net.inet.ip.portrange.hifirst: 49152
PASSIVE='49152:65535'
set skip on lo0
# default policy
block log all
# outgoing DNS requests
pass out quick on $EXT_IF inet proto udp from $EXT_IF:network to any
port domain keep state
pass out quick on $EXT_IF inet proto tcp from $EXT_IF:network to any
port domain keep state flags S/SA
# incoming SSH
pass in quick on $EXT_IF inet proto tcp from $EXT_IF:network to port
2022 keep state flags S/SA
# incoming FTP
# ftp command channel
pass in quick on $EXT_IF inet proto tcp from any to $EXT_IF port ftp
keep state flags S/SA
# ftp data channel (passive)
pass in quick on $EXT_IF inet proto tcp from any to $EXT_IF port
$PASSIVE keep state flags S/SA
# ftp data channel (active)
# wrong direction!!!
pass in quick on $EXT_IF inet proto tcp from any to $EXT_IF port
ftp-data keep state flags S/SA
Here I also erroneously used port 20 as destination port.
An active ftp command to upload a file aborts with
200 EPRT command successful.
425 Can't build data connection: Operation not permitted.
A pflog0 tcpdump shows the reason:
tcpdump -eni pflog0 -s0 -v
tcpdump: WARNING: pflog0: no IPv4 address assigned
tcpdump: listening on pflog0, link-type PFLOG (OpenBSD pflog file),
capture size 65535 bytes
22:16:42.551221 rule 0/0(match): block out on fxp0: (tos 0x8, ttl 64,
id 2766, offset 0, flags [DF], proto TCP (6), length 60)
192.168.222.244.20 > 192.168.222.20.62316: S, cksum 0xc222 (correct),
488073960:488073960(0) win 65535 <mss 1460,nop,wscale
3,sackOK,timestamp 6278055 0>
So this rule set blocks the first packet of the three-way TCP handshake.
192.168.222.244.20 > 192.168.222.20.62316.
or
server.20 > client.62316
Your previous ruleset somehow created state or allowed the server to
initiate the data channel to the client somewhere else in your rule
set. It didn't create state on the initial packet of the TCP
handshake, where the TCP window size is negotiated. Just like the
Daniel Hartmeier article states, this a caused tcp window scaling
issue.
Remember that in pf the last matching rule wins.
You only can defeat this behaviour by using the 'quick' keyword.
After adding the following corrected rule the transfer proceeds
without any blockage
# correct direction/source port
pass out quick on $EXT_IF inet proto tcp from any port ftp-data to
any keep state flags S/SA
The rules as parsed are now:
# pfctl -vvf /etc/pf.conf
No ALTQ support in kernel
ALTQ related functions disabled
Loaded 696 passive OS fingerprints
EXT_IF = "fxp0"
PASSIVE = "49152:65535"
set skip on { lo0 }
@0 block drop log all
@1 pass out quick on fxp0 inet proto udp from 192.168.222.0/24 to any
port = domain keep state
@2 pass out quick on fxp0 inet proto tcp from 192.168.222.0/24 to any
port = domain flags S/SA keep state
@3 pass in quick on fxp0 inet proto tcp from 192.168.222.0/24 to any
port = down flags S/SA keep state
@4 pass in quick on fxp0 inet proto tcp from any to 192.168.222.244
port = ftp flags S/SA keep state
@5 pass in quick on fxp0 inet proto tcp from any to 192.168.222.244
port 49152:65535 flags S/SA keep state
@6 pass in quick on fxp0 inet proto tcp from any to 192.168.222.244
port = ftp-data flags S/SA keep state
@7 pass out quick on fxp0 inet proto tcp from any port = ftp-data to
any flags S/SA keep state
Rule 6 is the rule with the wrong direction/port specification.
Rule 7 is the corrected one
pflog0 doesn't show any errors:
tcpdump: listening on pflog0, link-type PFLOG (OpenBSD pflog file),
capture size 65535 bytes
^C
0 packets captured
0 packets received by filter
0 packets dropped by kernel
And a quick state check still showed some remnants of the connections
# pfctl -ss
No ALTQ support in kernel
ALTQ related functions disabled
[snip]
all tcp 192.168.222.244:21 <- 192.168.222.20:13497 FIN_WAIT_2:FIN_WAIT_2
all tcp 192.168.222.244:20 -> 192.168.222.20:55246 FIN_WAIT_2:FIN_WAIT_2
all tcp 192.168.222.244:20 -> 192.168.222.20:59354 FIN_WAIT_2:FIN_WAIT_2
The first state is the ftp command channel client:13497 > server:21
The last two are the active data channels: server:20 > client:55246,
and server.20 > client.59354
Don't get confused, the last octet of the client IP (192.168.222.20)
happens to be the same as
the ftp-data port number. ;)
A repeat of the transfer shows the following verbose state
# pfctl -vvss
all tcp 192.168.222.244:20 -> 192.168.222.20:64857 ESTABLISHED:ESTABLISHED
[1427346948 + 65536] wscale 3 [200059941 + 37224] wscale 0
age 00:00:02, expires in 24:00:00, 13716:20572 pkts,
713240:30853060 bytes, rule 7
id: 4b47883900000033 creatorid: c576b1b2
By using this command you should be able to figure out which actual
rule, here rule 7, creates state for the active ftp data channel.
The same when the transfer has finished
all tcp 192.168.222.244:20 -> 192.168.222.20:64857 FIN_WAIT_2:FIN_WAIT_2
[1427346950 + 65534] wscale 3 [259693437 + 66608] wscale 0
age 00:00:59, expires in 00:00:38, 41209:61758 pkts,
2142876:92628227 bytes, rule 7
id: 4b47883900000033 creatorid: c576b1b2
Happy rule/state hunting
Adriaan
all tcp 192.168.222.244:20 -> 192.168.222.20:64857 FIN_WAIT_2:FIN_WAIT_2
[1427346950 + 65534] wscale 3 [259693437 + 66608] wscale 0
age 00:00:59, expires in 00:00:38, 41209:61758 pkts,
2142876:92628227 bytes, rule 7
id: 4b47883900000033 creatorid: c576b1b2
------------------------------
Message: 19
Date: Fri, 8 Jan 2010 17:05:16 -0600
From: "M.Keith.Thompson " <m.keith....@gmail.com>
Subject: Re: ftp problem
To: J65nko <j65...@gmail.com>
Cc: "freeb...@freebsd.org" <freeb...@freebsd.org>
Message-ID: <BC848642-A55F-4EAD...@GMail.com>
Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes
Remember the problem is only with one client and files over 98K.
Hundreds of other clients transfer multi-megabyte files no problem.
On Jan 8, 2010, at 4:50 PM, J65nko <j65...@gmail.com> wrote:
> On Fri, Jan 8, 2010 at 9:50 PM, M. Keith Thompson
> <m.keith....@gmail.com> wrote:
>> It looks like it was a tcp windowing problem. The command: "sysctl
>> -w
>> sysctl net.inet.tcp.rfc1323=0"
>> fixed the problem.
>
> This only fixes a symptom. :) There is something wrong with your
> ruleset.
>
>>>> # Allow ftp
>>>> pass in quick on $ext_if proto tcp from any to $ext_IP port 21
>>>> keep state
>>>> pass in quick on $ext_if proto tcp from any to $ext_IP port >
>>>> 49151 keep state
>>>> pass in quick on $ext_if proto tcp from any port > 10000 to $ext_IP
>>>> port 20 keep state
>
> With this active ftp rule you had before, the HP client could initiate
> and transfer over an active ftp data channel,
> while this rule does not allow this at all.
> There shouldn't be any active ftp datachannel communication possible
> because port 20 is the source port and not the destination port.
>
> I tried the following pf.conf , with a similar ftp-data rule , on a
> local FreeBSD 7.2 box in my network
>
> EXT_IF=fxp0
>
> # net.inet.ip.portrange.hilast: 65535
> # net.inet.ip.portrange.hifirst: 49152
> PASSIVE='49152:65535'
>
> set skip on lo0
>
> # default policy
> block log all
>
> # outgoing DNS requests
>
> pass out quick on $EXT_IF inet proto udp from $EXT_IF:network to any
> port domain keep state
> pass out quick on $EXT_IF inet proto tcp from $EXT_IF:network to any
> port domain keep state flags S/SA
>
> # incoming SSH
>
> pass in quick on $EXT_IF inet proto tcp from $EXT_IF:network to port
> 2022 keep state flags S/SA
>
> # incoming FTP
>
> # ftp command channel
> pass in quick on $EXT_IF inet proto tcp from any to $EXT_IF port ftp
> keep state flags S/SA
>
> # ftp data channel (passive)
> pass in quick on $EXT_IF inet proto tcp from any to $EXT_IF port
> $PASSIVE keep state flags S/SA
>
> # ftp data channel (active)
> # wrong direction!!!
> pass in quick on $EXT_IF inet proto tcp from any to $EXT_IF port
> ftp-data keep state flags S/SA
>
> Here I also erroneously used port 20 as destination port.
>
> An active ftp command to upload a file aborts with
>
> 200 EPRT command successful.
> 425 Can't build data connection: Operation not permitted.
>
> A pflog0 tcpdump shows the reason:
>
> tcpdump -eni pflog0 -s0 -v
> tcpdump: WARNING: pflog0: no IPv4 address assigned
> tcpdump: listening on pflog0, link-type PFLOG (OpenBSD pflog file),
> capture size 65535 bytes
> 22:16:42.551221 rule 0/0(match): block out on fxp0: (tos 0x8, ttl 64,
> id 2766, offset 0, flags [DF], proto TCP (6), length 60)
> 192.168.222.244.20 > 192.168.222.20.62316: S, cksum 0xc222 (correct),
> 488073960:488073960(0) win 65535 <mss 1460,nop,wscale
> 3,sackOK,timestamp 6278055 0>
>
> So this rule set blocks the first packet of the three-way TCP
> handshake.
>
> 192.168.222.244.20 > 192.168.222.20.62316.
> or
> server.20 > client.62316
>
> Your previous ruleset somehow created state or allowed the server to
> initiate the data channel to the client somewhere else in your rule
> set. It didn't create state on the initial packet of the TCP
> handshake, where the TCP window size is negotiated. Just like the
> Daniel Hartmeier article states, this a caused tcp window scaling
> issue.
>
> Remember that in pf the last matching rule wins.
> You only can defeat this behaviour by using the 'quick' keyword.
>
> After adding the following corrected rule the transfer proceeds
> without any blockage
>
> # correct direction/source port
> pass out quick on $EXT_IF inet proto tcp from any port ftp-data to
> any keep state flags S/SA
>
> The rules as parsed are now:
>
> # pfctl -vvf /etc/pf.conf
> No ALTQ support in kernel
> ALTQ related functions disabled
> Loaded 696 passive OS fingerprints
> EXT_IF = "fxp0"
> PASSIVE = "49152:65535"
> set skip on { lo0 }
> @0 block drop log all
> @1 pass out quick on fxp0 inet proto udp from 192.168.222.0/24 to any
> port = domain keep state
> @2 pass out quick on fxp0 inet proto tcp from 192.168.222.0/24 to any
> port = domain flags S/SA keep state
> @3 pass in quick on fxp0 inet proto tcp from 192.168.222.0/24 to any
> port = down flags S/SA keep state
> @4 pass in quick on fxp0 inet proto tcp from any to 192.168.222.244
> port = ftp flags S/SA keep state
> @5 pass in quick on fxp0 inet proto tcp from any to 192.168.222.244
> port 49152:65535 flags S/SA keep state
> @6 pass in quick on fxp0 inet proto tcp from any to 192.168.222.244
> port = ftp-data flags S/SA keep state
> @7 pass out quick on fxp0 inet proto tcp from any port = ftp-data to
> any flags S/SA keep state
>
> Rule 6 is the rule with the wrong direction/port specification.
> Rule 7 is the corrected one
>
> pflog0 doesn't show any errors:
> tcpdump: listening on pflog0, link-type PFLOG (OpenBSD pflog file),
> capture size 65535 bytes
> ^C
> 0 packets captured
> 0 packets received by filter
> 0 packets dropped by kernel
>
> And a quick state check still showed some remnants of the connections
>
> # pfctl -ss
> No ALTQ support in kernel
> ALTQ related functions disabled
> [snip]
> all tcp 192.168.222.244:21 <- 192.168.222.20:13497
> FIN_WAIT_2:FIN_WAIT_2
> all tcp 192.168.222.244:20 -> 192.168.222.20:55246
> FIN_WAIT_2:FIN_WAIT_2
> all tcp 192.168.222.244:20 -> 192.168.222.20:59354
> FIN_WAIT_2:FIN_WAIT_2
>
> The first state is the ftp command channel client:13497 > server:21
> The last two are the active data channels: server:20 > client:55246,
> and server.20 > client.59354
>
> Don't get confused, the last octet of the client IP (192.168.222.20)
> happens to be the same as
> the ftp-data port number. ;)
>
> A repeat of the transfer shows the following verbose state
>
> # pfctl -vvss
>
> all tcp 192.168.222.244:20 -> 192.168.222.20:64857
> ESTABLISHED:ESTABLISHED
> [1427346948 + 65536] wscale 3 [200059941 + 37224] wscale 0
> age 00:00:02, expires in 24:00:00, 13716:20572 pkts,
> 713240:30853060 bytes, rule 7
> id: 4b47883900000033 creatorid: c576b1b2
>
> By using this command you should be able to figure out which actual
> rule, here rule 7, creates state for the active ftp data channel.
>
> The same when the transfer has finished
>
> all tcp 192.168.222.244:20 -> 192.168.222.20:64857
> FIN_WAIT_2:FIN_WAIT_2
> [1427346950 + 65534] wscale 3 [259693437 + 66608] wscale 0
> age 00:00:59, expires in 00:00:38, 41209:61758 pkts,
> 2142876:92628227 bytes, rule 7
> id: 4b47883900000033 creatorid: c576b1b2
>
> Happy rule/state hunting
>
> Adriaan
>
>
> all tcp 192.168.222.244:20 -> 192.168.222.20:64857
> FIN_WAIT_2:FIN_WAIT_2
> [1427346950 + 65534] wscale 3 [259693437 + 66608] wscale 0
> age 00:00:59, expires in 00:00:38, 41209:61758 pkts,
> 2142876:92628227 bytes, rule 7
> id: 4b47883900000033 creatorid: c576b1b2
------------------------------
Message: 20
Date: Sat, 09 Jan 2010 23:00:37 +0300
From: Alex Povolotsky <tar...@webmail.sub.ru>
Subject: Re: FW: clientNatLookup: PF open failed: (13) Permission
denied
To: freeb...@freebsd.org
Message-ID: <4B48E065...@webmail.sub.ru>
Content-Type: text/plain; charset=UTF-8; format=flowed
On 12/11/09 15:11, Ermal Luçi wrote:
>
> Just allow the user with which you run squid permission of read(write?) to
> /dev/pf.
>
>
Well, what is the proper way to chgrp squid /dev/pf and chmod g+r
/dev/pf automatically? Nothing better than rc.local or patching
/usr/local/etc/rc.d/squid?
Alex.
------------------------------
Message: 21
Date: Sat, 09 Jan 2010 23:37:59 +0300
From: Alex Povolotsky <tar...@webmail.sub.ru>
Subject: Re: FW: clientNatLookup: PF open failed: (13) Permission
denied
To: freeb...@freebsd.org
Message-ID: <4B48E927...@webmail.sub.ru>
Content-Type: text/plain; charset=KOI8-R; format=flowed
On 01/09/10 23:00, Alex Povolotsky wrote:
> Well, what is the proper way to chgrp squid /dev/pf and chmod g+r
> /dev/pf automatically? Nothing better than rc.local or patching
> /usr/local/etc/rc.d/squid?
Quite simple; I should figure it out at once.
use devd.conf
Alex.
------------------------------
Message: 22
Date: Sat, 9 Jan 2010 23:44:55 -0500
From: jhell <jh...@DataIX.net>
Subject: Re: FW: clientNatLookup: PF open failed: (13) Permission
denied
To: Alex Povolotsky <tar...@webmail.sub.ru>
Cc: freeb...@freebsd.org
Message-ID:
<alpine.BSF.2.00.1...@qvfongpu.qngnvk.ybpny>
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
On Sat, 9 Jan 2010 15:37, tarkhil@ wrote:
> On 01/09/10 23:00, Alex Povolotsky wrote:
>> Well, what is the proper way to chgrp squid /dev/pf and chmod g+r /dev/pf
>> automatically? Nothing better than rc.local or patching
>> /usr/local/etc/rc.d/squid?
>
> Quite simple; I should figure it out at once.
>
> use devd.conf
>
> Alex.
>
In /etc/devfs.rules
Something like:
[system=10]
add path 'pf' mode 0660 group pfreader
And then in /etc/rc.conf
Add:
devfs_system_ruleset="system"
These are just examples but based on what I am using for some other
devices.
Best of luck.
--
Sat Jan 9 23:41:53 2010
jhell
------------------------------
Message: 23
Date: Mon, 11 Jan 2010 11:07:05 GMT
From: FreeBSD bugmaster <bugm...@FreeBSD.org>
Subject: Current problem reports assigned to freeb...@FreeBSD.org
To: freeb...@FreeBSD.org
Message-ID: <201001111107....@freefall.freebsd.org>
Note: to view an individual PR, use:
http://www.freebsd.org/cgi/query-pr.cgi?pr=(number).
The following is a listing of current problems submitted by FreeBSD users.
These represent problem reports covering all versions including
experimental development code and obsolete releases.
S Tracker Resp. Description
--------------------------------------------------------------------------------
o kern/141905 pf [pf] [panic] pf kernel panic on 7.2-RELEASE with empty
o kern/140697 pf [pf] pf behaviour changes - must be documented
o kern/137982 pf [pf] when pf can hit state limits, random IP failures
o kern/136781 pf [pf] Packets appear to drop with pf scrub and if_bridg
o kern/135948 pf [pf] [gre] pf not natting gre protocol
o kern/135162 pf [pfsync] pfsync(4) not usable with GENERIC kernel
o kern/134996 pf [pf] Anchor tables not included when pfctl(8) is run w
o kern/133732 pf [pf] max-src-conn issue
o kern/132769 pf [pf] [lor] 2 LOR's with pf task mtx / ifnet and rtent
f kern/132176 pf [pf] pf stalls connection when using route-to [regress
o conf/130381 pf [rc.d] [pf] [ip6] ipv6 not fully configured when pf st
o kern/129861 pf [pf] [patch] Argument names reversed in pf_table.c:_co
o kern/127920 pf [pf] ipv6 and synproxy don't play well together
o conf/127814 pf [pf] The flush in pf_reload in /etc/rc.d/pf does not w
o kern/127439 pf [pf] deadlock in pf
f kern/127345 pf [pf] Problem with PF on FreeBSD7.0 [regression]
o kern/127121 pf [pf] [patch] pf incorrect log priority
o kern/127042 pf [pf] [patch] pf recursion panic if interface group is
o kern/125467 pf [pf] pf keep state bug while handling sessions between
s kern/124933 pf [pf] [ip6] pf does not support (drops) IPv6 fragmented
o kern/124364 pf [pf] [panic] Kernel panic with pf + bridge
o kern/122773 pf [pf] pf doesn't log uid or pid when configured to
o kern/122014 pf [pf] [panic] FreeBSD 6.2 panic in pf
o kern/121704 pf [pf] PF mangles loopback packets
o kern/120281 pf [pf] [request] lost returning packets to PF for a rdr
o kern/120057 pf [pf] [patch] Allow proper settings of ALTQ_HFSC. The c
o bin/118355 pf [pf] [patch] pfctl(8) help message options order false
o kern/114567 pf [pf] [lor] pf_ioctl.c + if.c
o kern/114095 pf [carp] carp+pf delay with high state limit
o kern/111220 pf [pf] repeatable hangs while manipulating pf tables
s conf/110838 pf [pf] tagged parameter on nat not working on FreeBSD 5.
o kern/103283 pf pfsync fails to sucessfully transfer some sessions
o kern/103281 pf pfsync reports bulk update failures
o kern/93825 pf [pf] pf reply-to doesn't work
o sparc/93530 pf [pf] Incorrect checksums when using pf's route-to on s
o kern/92949 pf [pf] PF + ALTQ problems with latency
o bin/86635 pf [patch] pfctl(8): allow new page character (^L) in pf.
o kern/82271 pf [pf] cbq scheduler cause bad latency
38 problems total.
------------------------------
Message: 24
Date: Wed, 13 Jan 2010 14:07:22 +0300
From: Denis Shaposhnikov <d...@wizard.volgograd.ru>
Subject: synproxy doesn't work after upgrading to RELENG_8_0
To: freeb...@freebsd.org
Message-ID: <hik9ha$ldd$1...@ger.gmane.org>
Content-Type: text/plain; charset=UTF-8
Hello!
After upgrading to RELENG_8_0 I've found next rule doesn't work:
pass in quick proto tcp to port { http https } flags S/SA synproxy state
but same rule without synproxy works fine:
pass in quick proto tcp to port { http https }
Is it some well-known problem? Something wrong with synproxy on RELENG_8?
Thanks!
------------------------------
Message: 25
Date: Thu, 14 Jan 2010 06:41:25 GMT
From: lin...@FreeBSD.org
Subject: Re: conf/142817: [patch] etc/rc.d/pf: silence pfctl
To: lin...@FreeBSD.org, freebs...@FreeBSD.org,
freeb...@FreeBSD.org
Message-ID: <201001140641....@freefall.freebsd.org>
Synopsis: [patch] etc/rc.d/pf: silence pfctl
Responsible-Changed-From-To: freebsd-bugs->freebsd-pf
Responsible-Changed-By: linimon
Responsible-Changed-When: Thu Jan 14 06:41:14 UTC 2010
Responsible-Changed-Why:
Over to maintainer(s).
http://www.freebsd.org/cgi/query-pr.cgi?pr=142817
------------------------------
Message: 26
Date: Thu, 14 Jan 2010 11:20:03 GMT
From: Artis Caune <artis...@gmail.com>
Subject: Re: conf/142817: [patch] etc/rc.d/pf: silence pfctl
To: freeb...@FreeBSD.org
Message-ID: <201001141120....@freefall.freebsd.org>
The following reply was made to PR conf/142817; it has been noted by GNATS.
From: Artis Caune <artis...@gmail.com>
To: bug-fo...@FreeBSD.org, yuri....@gmail.com
Cc:
Subject: Re: conf/142817: [patch] etc/rc.d/pf: silence pfctl
Date: Thu, 14 Jan 2010 13:12:45 +0200
and maybe we can also remove ALTQ warning from pfctl?
patch: http://www.nic.lv/sofq/patch-pfctl-altq.txt
--
Artis Caune
Everything should be made as simple as possible, but not simpler.
------------------------------
Message: 27
Date: Thu, 14 Jan 2010 13:02:32 +0100
From: Miroslav Lachman <000....@quip.cz>
Subject: Re: conf/142817: [patch] etc/rc.d/pf: silence pfctl
To: Artis Caune <artis...@gmail.com>
Cc: freeb...@FreeBSD.org
Message-ID: <4B4F07D8...@quip.cz>
Content-Type: text/plain; charset=ISO-8859-2; format=flowed
Artis Caune wrote:
> The following reply was made to PR conf/142817; it has been noted by GNATS.
>
> From: Artis Caune<artis...@gmail.com>
> To: bug-fo...@FreeBSD.org, yuri....@gmail.com
> Cc:
> Subject: Re: conf/142817: [patch] etc/rc.d/pf: silence pfctl
> Date: Thu, 14 Jan 2010 13:12:45 +0200
>
> and maybe we can also remove ALTQ warning from pfctl?
>
> patch: http://www.nic.lv/sofq/patch-pfctl-altq.txt
The warning can be useful in some cases, but it would be useful if can
be supressed by some option (without redirecting all stderr in to /dev/null)
Miroslav Lachman
------------------------------
Message: 28
Date: Thu, 14 Jan 2010 14:14:53 -0500
From: "kevin" <k...@kevinkevin.com>
Subject: pf > round robin
To: <freeb...@freebsd.org>
Message-ID: <010801ca954d$db567fe0$92037fa0$@com>
Content-Type: text/plain; charset="us-ascii"
Hello,
I'm sure this topic has come up previously, however I'm just curious if
FreeBSD's PF + round robin load balancing to tcp port 80 has any status
checking built in.
That is to say, if server1's tcp 80 is not even responsive, does PF still
send traffic to it? It would be great if this was built in. If not (as I
suspect), what alternatives could be had to implement some sort of status
checking, while still using PF's round-robing directive?
Thanks,
Kevin
------------------------------
Message: 29
Date: Thu, 14 Jan 2010 21:07:30 +0100
From: Miroslav Lachman <000....@quip.cz>
Subject: Re: pf > round robin
To: kevin <k...@kevinkevin.com>
Cc: freeb...@freebsd.org
Message-ID: <4B4F7982...@quip.cz>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
kevin wrote:
> Hello,
>
> I'm sure this topic has come up previously, however I'm just curious if
> FreeBSD's PF + round robin load balancing to tcp port 80 has any status
> checking built in.
No, there is not. PF is packet filter, not swiss army knife
> That is to say, if server1's tcp 80 is not even responsive, does PF still
> send traffic to it? It would be great if this was built in. If not (as I
> suspect), what alternatives could be had to implement some sort of status
> checking, while still using PF's round-robing directive?
There is net/relayd in ports (from OpenBSD project, as PF) to things
like this.
Miroslav Lachman
------------------------------
End of freebsd-pf Digest, Vol 275, Issue 1
******************************************