Re: pf same rule passes some, blocks some?
On Mon, Aug 30, 2004 at 09:06:33PM -0400, Jason Opperisano wrote: On Mon, 2004-08-30 at 14:18, cmustard wrote: rule 1/0(match) block in on rl0: 84.2x.xxx.xx 192.168.3.2.6346: tcp 0 (DF) rule 1/0(match) block in on rl0: 224.2x.xxx.xx 192.168.3.2.6346: tcp 0 (DF) to me, this rule says it's blocking traffic on my external interface that is comming from any (internet) and bound for my dmz interface. are those the complete log entries? my log entries look more like (produced with tcpdump -netttr /var/log/pflog): are those the complete log entries? my log entries look more like - no, i truncated, I was running tcpdump -neq -ttt -r /var/log/pflog they were the 'standard/normal' entries: Aug 31 01:20:15.287341 rule 1/0(match): block in on rl0: 69.42.74.50.80 192.168.x.xxx.61265: P 4294966553:0(743) ack 1 win 5792 (DF) Aug 31 01:20:15.287341 rule 1/0(match): block in on rl0: 69.42.xx.xx.80 192.168.xx.x1.61265: P 4294966553:0(743) ack 1 win 5792 (DF) etc,... rule 0/0(match): block out on hme1: 10.1.1.15.139 10.1.2.16.32962: R 8:8(0) ack 1 win 58410 (DF) the reason i ask, is because all your rules use flags S/SA and keep state which; in the normal course of operation, create a lot of log entries where the flags are RST-ACK, FIN-ACK, etc... they are just trailing packets that arrive after the state entry has been removed... -hmmm, so your saying just because I see a rule being matched it doesnt' mean a packet is being blocked. it may be matching flags S/SA but is still passing in to the interface, cool, I haden't thought of that, thanks. that's what I get using rules I don't really understand yet,... :) -mus
is amd64 a good choice ?
Hello, We're working on an openbsd/pf based GigE firewall. I would like to know if amd64 is a good architecture choice ? Will it be better than i386 ? In the pf developer interview, 64 bit architecture is recommended, but they don't really explain why. Thanks, Alain
Re: is amd64 a good choice ?
Alain wrote: Hello, We're working on an openbsd/pf based GigE firewall. I would like to know if amd64 is a good architecture choice ? Will it be better than i386 ? In the pf developer interview, 64 bit architecture is recommended, but they don't really explain why. One of the limitation of i386 is that you cannot use more than 768M or address space for kernel memory. That limits the number of states or table entries that can be put in there. Hopefully 64-bit kernels can access more virtual memory, but I don't have enough knowledge of VM code to give you hard numbers. Cedric
Re: is amd64 a good choice ?
On Wed, 1 Sep 2004, Alain wrote: Hello, We're working on an openbsd/pf based GigE firewall. I would like to know if amd64 is a good architecture choice ? Will it be better than i386 ? In the pf developer interview, 64 bit architecture is recommended, but they don't really explain why. I wonder, because when threading will be supported and smp will be present in OpenBSD, HT will prove usefull as well. Of course it will require a rewrite of the network stack from running under the single Giant kernel lock to permitting it to run in a fully parallel manner on multiple CPUs (as is being done in fbsd). Maybe pf need changing too at that time? What will be faster, 64 bits architecture or multiple threads on multiple cpu's? Bye, Mipam.
Re: is amd64 a good choice ?
* Mipam [EMAIL PROTECTED] [2004-09-01 12:48]: On Wed, 1 Sep 2004, Alain wrote: We're working on an openbsd/pf based GigE firewall. I would like to know if amd64 is a good architecture choice ? Will it be better than i386 ? In the pf developer interview, 64 bit architecture is recommended, but they don't really explain why. I wonder, because when threading will be supported and smp will be present in OpenBSD, HT will prove usefull as well. Of course it will require a rewrite of the network stack from running under the single Giant kernel lock to permitting it to run in a fully parallel manner on multiple CPUs (as is being done in fbsd). Maybe pf need changing too at that time? I utterly do not believe in that. for first, what problem are you trying to solve please? I have yet to see the real worl situation where CPU usage from the network stack is a problem. second, all the locking is not free in terms of performance either. you want us to go the freebsd 5 route and give up on uniprocessor performance? I certainly don't. What will be faster, 64 bits architecture or multiple threads on multiple cpu's? I completely fail to see where a single amd64 CPU should not be sufficient for a pf firewall, as long as no proxies enter the game. If proxies enter the game you have active userland processes, they can benefit from the 2nd CPU. -- Henning Brauer, BS Web Services, http://bsws.de [EMAIL PROTECTED] - [EMAIL PROTECTED] Unix is very simple, but it takes a genius to understand the simplicity. (Dennis Ritchie)
Re: is amd64 a good choice ?
On Wed, Sep 01, 2004 at 11:13:11AM +0200, Mipam wrote: present in OpenBSD, HT will prove usefull as well. Of course it will require a rewrite of the network stack from running under the single Giant kernel lock to permitting it to run in a fully parallel manner on multiple CPUs (as is being done in fbsd). Maybe pf need changing this will not happen in the near future.
packet flows nat+rdr+squid
nat and redirection work greet.On 127.0.0.1:3128 is
running squid2.5.STABLE5 transparent proxy + zph
patch wich mark squid HIT packet with tos 0x81.This
also work.My problem is with packet flows
i want to count traffic passed to/from squid to my
users
pass in on $int_if route-to (lo0 127.0.0.1) proto
tcp from 192.168.0.11 to 127.0.0.1 port 3128
using pftop i found that on above rule traffic is
count double in+out.
pass out on lo0 from 192.168.0.11 to any
pass in on lo0 from 192.168.0.11 to any
this 2 line also count some packet i thing they are
outbound traffic.
Curently i use labels with my rules and a simple perl
script to collect data evry 5 min to
RRD files, but without squid.Almost all exapmle on pf
mailing list are for bridges, i read
all post with rdr, nat, squid
I need help to find my mistake.
!Sorry for my English!
Best regards Tihomir Ganev
openBSD 3.5 generic i386
this is part of my pf.conf
ext_if=rl0
int_if=xl0
mynet=192.168.0.0/24
myip=213.137.58.74
mygate=213.137.58.100
web_server=192.168.0.199
set state-policy if-bound
scrub in all
nat on rl0 from xl0/24 to any - $myip
rdr on $int_if inet proto tcp from 192.168.0.11 to
!192.168.0.199 port www - 127.0.0.1 port 3128
#SETUP default deny policy
block in all
block out all
#pass traffic on loopback interface
pass in on lo0 all
pass out on lo0 all
#pass all SSH trafic from my PC
pass in quick on $int_if proto tcp from 192.168.0.11
to 192.168.0.0/24 port = 22
pass out quick on $int_if proto tcp from
192.168.0.0/24 port ssh to 192.168.0.11
#pass all traffic to and from local network
pass in on $int_if from $mynet to any
pass out on $int_if from any to $mynet
pass out quick on $int_if proto tcp from $myip port
www to goodusers queue free
pass in on $int_if route-to (lo0 127.0.0.1) proto tcp
from 192.168.0.11 to 127.0.0.1 port 3128
pass out on $int_if from 192.168.0.11 to any
pass out on lo0 from 192.168.0.11 to any
pass in on lo0 from 192.168.0.11 to any
#pass ICMP traffic from Internet
pass in on $ext_if proto icmp from any to any
#pass tcp,udp and icmp out on the external (Internet)
interface.
#keep state on udp and icmp and modulate state on tcp
pass out on $ext_if proto tcp all modulate state flags
S/SA
pass out on $ext_if proto { udp, icmp } all keep state
__
Do you Yahoo!?
Yahoo! Mail Address AutoComplete - You start. We finish.
http://promotions.yahoo.com/new_mail
Re: is amd64 a good choice ?
* Alain [EMAIL PROTECTED] [2004-09-01 16:04]: Can you give me your opinion about the choice between amd64 and i386 for an openbsd/pf firewall ? buy an amd64. you can still run that in i386 mode should something go wrong in amd64 mode, what I don't expect to happen at all.
gmail subscribers
For some reason, google's delivery MXen show Windows TCP fingerprints now. I doubt they're really using that OS, more likely pf.os needs some change. Anyway, that's the reason posts and subscribe requests from gmail addresses were tarpitted this week. I whitelisted their netblock, so maybe resend your mail if it doesn't get through within a couple of hours now. For Mike, if you want to update pf.os ;) 11:46:10.155839 64.233.170.197.22873 62.65.145.30.25: S [tcp sum ok] (src OS: Windows NT 5.0) 3920435532:3920435532(0) win 8190 mss 1400 (ttl 243, id 39826) : 4500 002c 9b92 f306 712b 40e9 aac5 E..,[EMAIL PROTECTED] 0010: 3e41 911e 5959 0019 e9ad 194c A..YY..é.L 0020: 6002 1ffe 60ea 0204 0578 13ed `..þ`ê.x.í Daniel
matching ports that are actually open
Hi, Recently, I was pondering something that, as far as I know, pf can't do at the moment, but would be quite useful (for me at least ;) : I would like to have an extra condition for rules that matches when a socket is actually open at a given port, so it would be possible, for example, to redirect to another host if a certain service is not running, and handle it locally when this service is. Or to return an ICMP access-denied when a port is closed, and just accept connections when it is open. It was just a thought, but I was wondering how hard it would be for me to implement, maybe just as a patch for my own usage, or maybe as a general addition if there are more people who would like such functionality. (Or is this already possible with pf, but did I just miss it? :) Any comments? thanks in advance keep up the good work, Matthijs
Re: matching ports that are actually open
On Wed, Sep 01, 2004 at 06:43:45PM +0200, Matthijs Bomhoff wrote: (Or is this already possible with pf, but did I just miss it? :) Try the 'user' (or 'group') options, see pf.conf(5). If an incoming connection matches a listening socket (on the firewall itself), 'user != unknown' is true. Maybe that can be used to do what you want? Daniel
Re: pf same rule passes some, blocks some?
On Tue, 2004-08-31 at 19:31, cmustard wrote: are those the complete log entries? my log entries look more like - no, i truncated, I was running tcpdump -neq -ttt -r /var/log/pflog they were the 'standard/normal' entries: Aug 31 01:20:15.287341 rule 1/0(match): block in on rl0: 69.42.74.50.80 192.168.x.xxx.61265: P 4294966553:0(743) ack 1 win 5792 (DF) Aug 31 01:20:15.287341 rule 1/0(match): block in on rl0: 69.42.xx.xx.80 192.168.xx.x1.61265: P 4294966553:0(743) ack 1 win 5792 (DF) etc,... rule 0/0(match): block out on hme1: 10.1.1.15.139 10.1.2.16.32962: R 8:8(0) ack 1 win 58410 (DF) the reason i ask, is because all your rules use flags S/SA and keep state which; in the normal course of operation, create a lot of log entries where the flags are RST-ACK, FIN-ACK, etc... they are just trailing packets that arrive after the state entry has been removed... -hmmm, so your saying just because I see a rule being matched it doesnt' mean a packet is being blocked. it may be matching flags S/SA but is still passing in to the interface, cool, I haden't thought of that, thanks. that's what I get using rules I don't really understand yet,... :) actually, what i was saying is: when you use flags S/SA keep state *only* a packet with the SYN bit (out of SYN, ACK) can match the rule and create a state. those states are also interface-bound (if you specify an interface), and once that state is removed, any packets lagging behind the closing of that connection will be blocked by your default rule because they don't match anything else and have no state associated with them. generally, these will be FIN-ACK, RST-ACK, or PSH-ACK packets. here's the rules i try to follow with respect keeping state, either: don't specify interfaces when keeping state, or only keep state on one interface (usually the external) -j =~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~ If God had intended Man to Smoke, He would have set him on Fire. =~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~
Re: gmail subscribers
Daniel Hartmeier writes: For some reason, google's delivery MXen show Windows TCP fingerprints now. I doubt they're really using that OS, more likely pf.os needs some change. Speaking of gmail, would anyone happen to have a spare invite they could throw my way?
Re: gmail subscribers
sure On Wed, 1 Sep 2004 [EMAIL PROTECTED] wrote: Daniel Hartmeier writes: For some reason, google's delivery MXen show Windows TCP fingerprints now. I doubt they're really using that OS, more likely pf.os needs some change. Speaking of gmail, would anyone happen to have a spare invite they could throw my way? Derrick MacPherson [EMAIL PROTECTED]
Re: matching ports that are actually open
On Sep 1, 2004, at 20:11, Daniel Hartmeier wrote: On Wed, Sep 01, 2004 at 06:43:45PM +0200, Matthijs Bomhoff wrote: (Or is this already possible with pf, but did I just miss it? :) Try the 'user' (or 'group') options, see pf.conf(5). If an incoming connection matches a listening socket (on the firewall itself), 'user != unknown' is true. Maybe that can be used to do what you want? For block rules, that would do I suppose, but for redirection it wouldn't, would it? What I would like to do, is something like the following (just an example) : rdr proto tcp to (dc0) port 80 ! open - 10.0.2.2 port 80 i.e. redirect connections to the local webserver to some other host when the local webserver is not listening. if I understand the pf.conf(5) man page, user/group is only applicable for packet filtering, not for redirection etc. Any suggestions for such a thing? thanks for your time, Matthijs
PF --- spamd
Hi, I'm playing with OpenBSD 3.6-beta. I wanted to test spamd with greylisting, but it seems that the interaction with PF is broken. In short spamd doesn't add anything to /var/db/spamd so I'll never get my IP added to spamd-white --- pf.conf - table spamd persist table spamd-white persist rdr pass inet proto tcp from spamd to any port smtp - 127.0.0.1 port 8025 rdr pass inet proto tcp from !spamd-white to any port smtp - 127.0.0.1 port 8025 -- rc.conf --- spamd_flags= spamd_grey=YES Is this a bug ? Ed
Re: is amd64 a good choice ?
On Wed, Sep 01, 2004 at 05:15:14PM +0200, Henning Brauer wrote: * Alain [EMAIL PROTECTED] [2004-09-01 16:04]: Can you give me your opinion about the choice between amd64 and i386 for an openbsd/pf firewall ? buy an amd64. you can still run that in i386 mode should something go wrong in amd64 mode, what I don't expect to happen at all. You also gain proper per-page execute protection in amd64 mode. And the amd64 will be faster in i386 mode than an i386.
Re: is amd64 a good choice ?
On Wed, Sep 01, 2004 at 03:09:49PM +0200, Henning Brauer wrote: You are speculating, and you don't really knwo what you are talking about here... sorry, no GigE chipset interrupts per packet. I beleive re(4) does, at least with the OpenBSD driver. But if you are using this cheap, low-end gigabit chipset for your high-performance firewall you are very, very silly. and if there should be one ditch it and use something better. Like em(4) or sk(4).
Re: matching ports that are actually open
On Sep 1, 2004, at 5:10 PM, Matthijs Bomhoff wrote: What I would like to do, is something like the following (just an example) : rdr proto tcp to (dc0) port 80 ! open - 10.0.2.2 port 80 i.e. redirect connections to the local webserver to some other host when the local webserver is not listening. if I understand the pf.conf(5) man page, user/group is only applicable for packet filtering, not for redirection etc. Any suggestions for such a thing? It sounds like you're trying to get fancy with load-balancing. If that's the case, why don't you simply rdr to a local load balancer (python director springs to mind) and let it handle the application issues? Let _it_ deal with whether a server is alive or not; PF is a _packet_filter_, not an application proxy/LB device. Well, not in the truest sense, anyways. :) -- Jason Dixon, RHCE DixonGroup Consulting http://www.dixongroup.net
