RE: OpenBSD 5.5 set prio 3 and interface shaping
Thank you again for the direction. I still do not have it correct but I have a clue why. I am also starting to grasp the pf.conf man page much better. I just wanted to reply back in here out of respect for Mr. Henderson for the direction and to let him know that I am in much better shape now than I was. For all hyperactive peeps like myself here is some advice. Learn the man page language and the format they use. This will help in understanding what we are reading. I will continue to play with it at night. I do not ask questions until locked up severely. When I grasp a few concepts better I will ask on the mailing list instead of here. I did not realize that is where I should have replied in the beginning due to more participation. I read all the misc emails I receive. One day I will grasp all of it much better. My nature don't let me sleep much and I actually enjoy doing this. Thanks again for your reply Mr. Henderson and look forward to one day being an asset and not a liability. "High Five" Kevin Gerrard From: Stuart Henderson [via OpenBSD] [mailto:ml-node+s7691n254354...@n7.nabble.com] Sent: Saturday, August 23, 2014 3:05 PM To: Kevin Gerrard Subject: Re: OpenBSD 5.5 set prio 3 and interface shaping On 2014/08/22 19:15, Kevin Gerrard wrote: > I realize that this May seem like a dumb question for one of the developers. > I didn't expect a detailed message or exact answer. I have spent much time > reading different ideas and by doing so learned much more while on this > path. I have not posted on here except a time or two. I have ordered cd's > (which I never received) That is a pity, did you report it to the CD seller? > and donated money. Not a lot but it was what I > could. But I'll be damned if I do again. I will keep mouth shut and read to > learn here but will not be in support whether it be money or help for others > in the future as my knowledge grows. If I knew a private way to send this > post and to whom I would have > > Not blaming anyone. Didn't expect the elite brains to answer but no one else > answered either? Not mad or upset and if someone wants to flame at me go > ahead I will survive. One way or another I will be a contribution to the > open source programs. I hope it would be in the technology and ideas one day > but if not I'm sure the money would not hurt. Love the bsd operating system > and will learn it if by only reading then so be it. Do not count me out in > this industry. > > My apologies for not having the education of words and protocol, but like I > said I have a drive and love this stuff. > > > > > > -- > View this message in context: http://openbsd.7691.n7.nabble.com/OpenBSD-5-5-set-prio-3-and-interface-shapi ng-tp253916p254323.html > Sent from the openbsd - packet filter mailing list archive at Nabble.com. The PF mailing list isn't one of the main OpenBSD lists and isn't as widely read. This fact may be masked by your choice of nabble.com's mailing list<>web gateway - see http://www.openbsd.org/mail.html for the list of lists. Going back to your original question .> That being said we were wanting to use something to do nothing but .> limit em0 to 25Mbits and then we would set prio to whatever we need on .> the rest of the rules. Here is a possible config to simply limit the traffic: queue internet on em0 bandwidth 25Mb max 25Mb queue std parent internet bandwidth 25Mb default The new queues do not support "set prio", you would need to handle priority traffic with additional queues to reserve bandwidth - (using "min") - if high priority traffic is not using that bandwidth at a particular time, other traffic has a chance to use it instead (up to their "max" limit). _ If you reply to this email, your message will be added to the discussion below: http://openbsd.7691.n7.nabble.com/OpenBSD-5-5-set-prio-3-and-interface-shapi ng-tp253916p254354.html To unsubscribe from OpenBSD 5.5 set prio 3 and interface shaping, click here <http://openbsd.7691.n7.nabble.com/template/NamlServlet.jtp?macro=unsubscrib e_by_code&node=253916&code=a2V2aW5AdHh3cmUuY29tfDI1MzkxNnwtMjIzNjkyNzk4> . <http://openbsd.7691.n7.nabble.com/template/NamlServlet.jtp?macro=macro_view er&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNa mespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.No deNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_ema ils%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml> NAML No virus found in this message. Checked by AVG - www.avg.com Version: 2014.0.4745 / Virus Database: 4007/8085 - Release Date: 08/23/14 -- View this message in context: http://openbsd.7691.n7.nabble.com/OpenBSD-5-5-set-prio-3-and-interface-shaping-tp253916p254371.html Sent from the openbsd - packet filter mailing list archive at Nabble.com.
RE: OpenBSD 5.5 set prio 3 and interface shaping
My many thanks for all the info. I didn't realize that this forum was different from the mailing list of bsd. I receive all the mailing list emails even though I don't understand most of them. I will handle that situation better and it was my fault for posting the wrong place. The CD's are nothing to worry about. I will just give it as a donation and download one for replication. Report it was not really an issue, a bit of a rant maybe and would have been better off left unsaid. Thank you for your help. I will play with it here in a bit and see what happens. Kevin From: Stuart Henderson [via OpenBSD] [mailto:ml-node+s7691n254354...@n7.nabble.com] Sent: Saturday, August 23, 2014 3:05 PM To: Kevin Gerrard Subject: Re: OpenBSD 5.5 set prio 3 and interface shaping On 2014/08/22 19:15, Kevin Gerrard wrote: > I realize that this May seem like a dumb question for one of the developers. > I didn't expect a detailed message or exact answer. I have spent much time > reading different ideas and by doing so learned much more while on this > path. I have not posted on here except a time or two. I have ordered cd's > (which I never received) That is a pity, did you report it to the CD seller? > and donated money. Not a lot but it was what I > could. But I'll be damned if I do again. I will keep mouth shut and read to > learn here but will not be in support whether it be money or help for others > in the future as my knowledge grows. If I knew a private way to send this > post and to whom I would have > > Not blaming anyone. Didn't expect the elite brains to answer but no one else > answered either? Not mad or upset and if someone wants to flame at me go > ahead I will survive. One way or another I will be a contribution to the > open source programs. I hope it would be in the technology and ideas one day > but if not I'm sure the money would not hurt. Love the bsd operating system > and will learn it if by only reading then so be it. Do not count me out in > this industry. > > My apologies for not having the education of words and protocol, but like I > said I have a drive and love this stuff. > > > > > > -- > View this message in context: http://openbsd.7691.n7.nabble.com/OpenBSD-5-5-set-prio-3-and-interface-shapi ng-tp253916p254323.html > Sent from the openbsd - packet filter mailing list archive at Nabble.com. The PF mailing list isn't one of the main OpenBSD lists and isn't as widely read. This fact may be masked by your choice of nabble.com's mailing list<>web gateway - see http://www.openbsd.org/mail.html for the list of lists. Going back to your original question .> That being said we were wanting to use something to do nothing but .> limit em0 to 25Mbits and then we would set prio to whatever we need on .> the rest of the rules. Here is a possible config to simply limit the traffic: queue internet on em0 bandwidth 25Mb max 25Mb queue std parent internet bandwidth 25Mb default The new queues do not support "set prio", you would need to handle priority traffic with additional queues to reserve bandwidth - (using "min") - if high priority traffic is not using that bandwidth at a particular time, other traffic has a chance to use it instead (up to their "max" limit). _ If you reply to this email, your message will be added to the discussion below: http://openbsd.7691.n7.nabble.com/OpenBSD-5-5-set-prio-3-and-interface-shapi ng-tp253916p254354.html To unsubscribe from OpenBSD 5.5 set prio 3 and interface shaping, click here <http://openbsd.7691.n7.nabble.com/template/NamlServlet.jtp?macro=unsubscrib e_by_code&node=253916&code=a2V2aW5AdHh3cmUuY29tfDI1MzkxNnwtMjIzNjkyNzk4> . <http://openbsd.7691.n7.nabble.com/template/NamlServlet.jtp?macro=macro_view er&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNa mespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.No deNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_ema ils%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml> NAML No virus found in this message. Checked by AVG - www.avg.com Version: 2014.0.4745 / Virus Database: 4007/8085 - Release Date: 08/23/14 -- View this message in context: http://openbsd.7691.n7.nabble.com/OpenBSD-5-5-set-prio-3-and-interface-shaping-tp253916p254355.html Sent from the openbsd - packet filter mailing list archive at Nabble.com.
Re: OpenBSD 5.5 set prio 3 and interface shaping
Thank You, I will see this afternoon, and I appreciate your reply. Can't believe it would be that simple and I missed it. I even have both pf books. Pre 4.6 and post 4.6 Again thank you very much and will read. Kevin Gerrard -- View this message in context: http://openbsd.7691.n7.nabble.com/OpenBSD-5-5-set-prio-3-and-interface-shaping-tp253916p254343.html Sent from the openbsd - packet filter mailing list archive at Nabble.com.
Re: OpenBSD 5.5 set prio 3 and interface shaping
I realize that this May seem like a dumb question for one of the developers. I didn't expect a detailed message or exact answer. I have spent much time reading different ideas and by doing so learned much more while on this path. I have not posted on here except a time or two. I have ordered cd's (which I never received) and donated money. Not a lot but it was what I could. But I'll be damned if I do again. I will keep mouth shut and read to learn here but will not be in support whether it be money or help for others in the future as my knowledge grows. If I knew a private way to send this post and to whom I would have Not blaming anyone. Didn't expect the elite brains to answer but no one else answered either? Not mad or upset and if someone wants to flame at me go ahead I will survive. One way or another I will be a contribution to the open source programs. I hope it would be in the technology and ideas one day but if not I'm sure the money would not hurt. Love the bsd operating system and will learn it if by only reading then so be it. Do not count me out in this industry. My apologies for not having the education of words and protocol, but like I said I have a drive and love this stuff. -- View this message in context: http://openbsd.7691.n7.nabble.com/OpenBSD-5-5-set-prio-3-and-interface-shaping-tp253916p254323.html Sent from the openbsd - packet filter mailing list archive at Nabble.com.
Re: OpenBSD 5.5 set prio 3 and interface shaping
I am glad that the post above is screened. It does not need to go public. The proper people will see it and can delete them both if they wish. Again I am not mad or a hater yet do feel that there is a learning curve for even searching the forum. I do read the man pages and do not understand them. I do keep reading because I gain a bit each time. I understand some of them and will keep reading them if for no other reason than to learn. It just seems that there is not a middle class to help the poor here. Only the rich ( knowledgable). The middle class should step up and help the poor but for some reason it doesn't seem to happen. No reply needed, just read them and take the post for what you think it is worth. Then do what you wish with the post. Kevin -- View this message in context: http://openbsd.7691.n7.nabble.com/OpenBSD-5-5-set-prio-3-and-interface-shaping-tp253916p254325.html Sent from the openbsd - packet filter mailing list archive at Nabble.com.
OpenBSD 5.5 set prio 3 and interface shaping
The new rules for prioritizing traffic seem to be very simple to do. In my case we have fiber that we pay for but has a burstable speed. We do not want to use the burstable speeds due to the overcharging that AT&T charges to do it. Our fiber pipe that we pay for is 25Mbits at a tower. We have burstable up to 100Mbits. By having it set up this way we can make a call and bump it up easier than letting AT&T due their normal route of installing another fiber right beside the one we already have and wasting all our time. That being said we were wanting to use something to do nothing but limit em0 to 25Mbits and then we would set prio to whatever we need on the rest of the rules. If we graph it or see it maxing out then we make a call and see how long it takes our beloved (sarcasm) AT&T to turn it up. I have been reading and learning, I have not seen anything to limit an interface in 5.5. Is this something to do without to much ado or is it something coming later? Thanks for the brief direction to go, Kevin Gerrard -- View this message in context: http://openbsd.7691.n7.nabble.com/OpenBSD-5-5-set-prio-3-and-interface-shaping-tp253916.html Sent from the openbsd - packet filter mailing list archive at Nabble.com.
Modifying Apple's pf.conf
Hey everyone! I am sitting here with the following situation: I just had to reinstall my OS X a while ago. Currently, this Mac Mini was used as a NAT router. It uses its Wifi to connect to the dorms internet, and is supposed to dish the data thru its ethernet port: Dorms Wifi —> Mac Mini —> Airport Express in bridge mode —> iPhone, Macbook, etc The reason why I need this is that the dorms enforces a rule, which allows only one Mac address to be registered with their router. So in order to grant access to more devices, I need to use a NAT router. But here comes the tricky part. At some time, I wish to use a broadband dongle to offer the internet. Previously, I used the following dirty configuration file to manage that kind of „switching“ connection: nat on en1 from en0:network to any -> (en1) nat on en2 from en0:network to any -> (en2) nat on ppp0 from en0:network to any -> (ppp0) pass in from any to any pass out from any to any You can tell, I never used pfctl before, and only needed a dirty but working way of being able to switch my currently nat’ed internet… x) But here is the problem. With the new OS X update, the configuration files for pfctl changed. Which means, I am in a loss again. So the pf.conf file now looks like this: scrub-anchor "com.apple/*" nat-anchor "com.apple/*" rdr-anchor "com.apple/*" dummynet-anchor "com.apple/*" anchor "com.apple/*" load anchor "com.apple" from "/etc/pf.anchors/com.apple“ When I try to append a similar block, but pointing to /etc/pf.anchors/SUBnet instead, I get syntax errors about the order of rules…so I am confused for good. How do I add the „dirty“ hack from above into my pf.conf in order to keep NATing my internet? Oh yeah, and Internet Sharing on OS X is broken. the dhcp service used does not dish out a proper lease, meaning that Non-Apple clients are doomed. Hope you can help me :) Kind regards, Ingwie
CARP ip balancing on ExtremeWare
I'm having a hell of a time using Extreme Networks Summit 400-24t switches with IP balancing of any type. I've tried OpenBSD 5.0 and a -current snapshot from Feb 02. I've tried all the modes, but none of them work. There's not a good way I'm aware of to do port mirroring for ip-unicast, but I don't understand why ip-stealth isn't working. I manually clear the forwarding database after activating ip-stealth. I'm just about to relegate these to dumb switch duty and try and find some other vendor that just works. Any chance someone else has cracked the code on these with pf in the past? Regards, Kevin
Re: Adding filters/anchors on-the-fly
Daniel Staal wrote: --As of July 7, 2009 8:56:34 AM -0400, Kevin Kobb is alleged to have said: Hello, I am wondering if it is possible to add filters/anchors with pfctl to a running instance of pf? I have put an anchor option in my pf.conf, and I can add tables and filter rules to that OK. But suppose I had no anchor option in pf.conf; is there some way to add one with pfctl and insert rules and have them used? If so, I have not been able to figure it out. This as not critical by any means as it does work fine otherwise, but I am just trying to figure out if I am missing something, or it just doesn't work that way. --As for the rest, it is mine. Well, you can always load a new rules file... But other than that or having an anchor, no. That's kinda the point of an anchor. Daniel T. Staal --- This email copyright the author. Unless otherwise noted, you are expressly allowed to retransmit, quote, or otherwise use the contents for non-commercial purposes. This copyright will expire 5 years after the author's death, or in 30 years, whichever is longer, unless such a period is in excess of local copyright law. --- Pretty much what I figured. I only ask because with iptables it is possible to do this, and I am looking at something that was configured for that. However, it is easy enough to do what I want by adding an anchor first, and certainly not worth dealing with iptables ;)
Adding filters/anchors on-the-fly
Hello, I am wondering if it is possible to add filters/anchors with pfctl to a running instance of pf? I have put an anchor option in my pf.conf, and I can add tables and filter rules to that OK. But suppose I had no anchor option in pf.conf; is there some way to add one with pfctl and insert rules and have them used? If so, I have not been able to figure it out. This as not critical by any means as it does work fine otherwise, but I am just trying to figure out if I am missing something, or it just doesn't work that way. Thanks.
Re: Active failover with local Squid and ftp-proxy.
A failover will terminate any existing proxied connections, including Squid and ftp-proxy. This is an inherent limitation of a proxy firewall. While active TCP sessions are expected to abort, if you start up a new FTP or Squid session after the failover, does it succeed? Kevin
Re: pf won't pass some port 53 traffic even when asked nicely to
On 12/20/05, Buzz Kill <[EMAIL PROTECTED]> wrote: > A quick look at RFC 1034 & 1035 shows how DNS works. Most setups > (I'd say 99%) will need both of these ports open, assuming you want > the world to access services running within your domain that rely on > DNS & Bind (which is like 99% of them). Actually, I'd venture that 99% of installations are not hosting authoritative DNS for Internet domains, do not need to permit the world to make inbound queries. In such a deployment, you can run a caching DNS service, permit internal clients to make queries only to the local cache, only the local cache is permitted to initiate outbound queries on UDP and TCP 53. OpenBSD ships with an example BIND configuration for this as /var/named/etc/named-simple.conf Kevin
re: PF not keeping state
> The only thing I can think of right now is that > perhaps it's because I'm filtering in all directions on all > interfaces, even though the state policy is left as floating. I > don't think this is relevant, however, since this behavior only > happens on a single network. With the complexities and such introduced by CARP and the VLANs, it sounds like you might want to try something like: set state-policy if-bound in your pre-nat settings. Mine looks like this: set loginterface $ext_if set block-policy drop set optimization normal set state-policy if-bound scrub in all random-id scrub out all random-id (Yes, "optimzation normal" is the default and unnecessary; it's there for sanity, as on other machines of ours we use other settings.) Good luck, Kevin -- http://www.ebiinc.com : Background Screening from EBI Leaders for employee background checks.
Re: pps or other unknown upper bound?
On 11/22/05, Travis H. <[EMAIL PROTECTED]> wrote: > On 11/17/05, Kevin <[EMAIL PROTECTED]> wrote: > > On 11/17/05, Jon Hart <[EMAIL PROTECTED]> wrote: > > > The funny thing is, in my tests, despite having ~31000 source ports to > > > choose from, the client is unlucky enough most of the time and very > > > quickly manages to reuse a port. It depends on what else the client is > > > doing, but I saw a case earlier today that after about 300 connections, > > > the source port was reused. > > > > Does Debian have random source ports? > > > > My thought is that the classic approach of using ephemeral ports > > sequentially is acting as a poor man's "least recently used" algorithm > > in choosing the source port for each new session. > > > > Depending on the implementation, source port randomization could cause > > a source port to be reused much sooner than with the "classic" > > approach. > > Classic birthday attack. If the source ports are chosen randomly, and > there are 31000 ports to choose from, one would expect to see re-use > after approximately sqrt(n), or 176 tries. > > Shouldn't the client still check to see if the socket is involved in a > 2MSL WAIT state, and pick another source port if it is? Or better yet > - choose randomly from sockets not involved in WAIT states, if there > are any. That is trickier, but not impossible. I'm certain that the local host will not select a source port that has an existing socket involved in 2MSL wait state, will choose the new socket _randomly_ from sockets not _currently_ involved in wait states in the local state table. But randomly choosing the local source port from the available ports,instead of using ports incrementally, vastly increases the chance that the port chosen was involved in a wait state very recently (as you stated, birthday problem). In the degenerate case where a single source IP is rapidly opening and closing TCP sessions to a single destination IP and port, reusing a port "early", while the selected quad is still in a remote server of firewall state table in a 2MSL wait state, causes the hang that started this thread. Thus my proposed "aggressive" tuning to permit with early reuse of a quad. Kevin
Re: pps or other unknown upper bound?
On 11/17/05, Jon Hart <[EMAIL PROTECTED]> wrote: > On Fri, Nov 18, 2005 at 12:49:48AM +0100, Daniel Hartmeier wrote: > > This all makes sense. Assuming you're fetching a tiny document from the > > web server in a fast loop, the client will run out of random source > > ports. It's probably honouring 2MSL up to the point where it simply has > > no choice (other than stalling further connect(2) calls), until ports > > free up. > > The funny thing is, in my tests, despite having ~31000 source ports to > choose from, the client is unlucky enough most of the time and very > quickly manages to reuse a port. It depends on what else the client is > doing, but I saw a case earlier today that after about 300 connections, > the source port was reused. I've sometimes wondered if adding randomization to ephemeral ports was a cause behind the 'hanging' problem I sometimes see when an OpenBSD client sources TCP sessions at a high rate. Does Debian have random source ports? My thought is that the classic approach of using ephemeral ports sequentially is acting as a poor man's "least recently used" algorithm in choosing the source port for each new session. Depending on the implementation, source port randomization could cause a source port to be reused much sooner than with the "classic" approach. > This has been my approach for much of today -- I know of many ways to > fix or alleviate this problem on the client, firewall and/or the server, > but most either have undesireable side affects or unknown consequences. > In my opinion, the consequences of rethinking the client are pretty > clear and it seems like the best approach at this point Given the above issue, I did think of one hack to make the problem occur at a much lower frequency. Basically, assign 16 or 32 alias IP addresses to the web server, and populate a round-robin A record with all of these addresses. Then have the client connect to the destination using a different destination IP address for each session. This reduces the likelihood of duplicating the same quad by a factor of 16 or 32. A hack, but not all hacks are bad Kevin
Re: pps or other unknown upper bound?
On 11/17/05, Daniel Hartmeier <[EMAIL PROTECTED]> wrote: > The address/port pairs are probably clear (there's three pairs, > two are equal unless the state involves translation). . . . Thanks for the detailed explanation, that makes a a lot more sense. > This all makes sense. Assuming you're fetching a tiny document > from the web server in a fast loop, the client will run out of > random source ports. It's probably honouring 2MSL up to the point where > it simply has no choice (other than stalling further connect(2) calls), > until ports free up In the original message, Jon mentions that the client and server are Debian; I'd venture that the client may have different timeouts, or may just not be honouring 2MSL in the same way as the firewall? > The reason we keep a state in FIN_WAIT or TIME_WAIT is that there might > be spurious packets arriving late (like packets that travelled through > slower alternative paths across the network). By keeping the state > entry, those are associated with the state and don't cause pflog logging > (they'd usually not have a SYN flag and would get blocked and logged So when pf does see a packet come in matching the address/port pairs for any existing state entry (TIME_WAIT or otherwise) it always blocks the packet, whether or not there is a SYN flag? > according to your policy). So you'll likely not break anything by > lowering the timeout values, but you might be getting some more packets > logged as ordinary blocks. In the specific case of TIME_WAIT, it reads as if when a stateful filter or IP stack sees a SYN arriving with a "greater sequence number", one which otherwise matches a state entry currently in TIME_WAIT, it may be legal to flush the state earlier than 2MSL (see RFC 1337)? Assuming "aggressive" already makes assumptions about timeouts and spurious packets arriving late, flushing old state entries when a "new" SYN is seen would seem to be at least as secure and effective as lowering the timeout values, but without the CPU overhead? Kevin "showing the limits of my TCP knowledge" Kadow
Re: pps or other unknown upper bound?
On 11/17/05, Jon Hart <[EMAIL PROTECTED]> wrote: > On Thu, Nov 17, 2005 at 03:21:01PM +, Karl O. Pinc wrote: >> Let me apologize in advance: when all you've got is a hammer, >> everything looks like a nail. I keep harping on the 2MSL TCP >> rule -- reuse of source IP/port dest IP/port quad. So, >> could be a TCP(ish) issue, although I don't feel entirely >> qualified to claim this. I think this is a key point -- the client is removing the quad from TIME-WAIT and sees it as eligible for reuse, meanwhile the firewall and/or the server still has this closed session state table entry in a *WAIT state. > the client sends 3 syns in rapid succession from this source port > and the firewall doesn't allow them through. . . . > Now my problem is figuring out how to deal with this situation. > I believe the firewall is doing what it should but others may argue it > is being too strict. I could also just widen the defaut port range on > the clients, but that doesn't strike me as the best solution. If 'pf' is blocking new SYN packets because of an existing FIN-WAIT table entry for the same quad, that may be proper behavior, yet "too strict". My TCP is a little rusty, but would it be reasonable for the "aggressive" optimization to not only adjust timeouts, but also change engine behavior so a newly received SYN, if it matches a state entry which is in FIN-WAIT or CLOSED state, to reset that state entry back into "first"? Kevin Kadow
Re: pps or other unknown upper bound?
On 11/16/05, Jon Hart <[EMAIL PROTECTED]> wrote: > pass in on $CLIENT_IF inet proto tcp from $CLIENT_NET to $SERVER_NET \ > port 12345 flags S/SA modulate state I know it's a stupid question, but have you tried the same ruleset, but not modulating state? How about the same rules, with pass in/out rules and no:"keep state"? > Any input, whether its pf, OpenBSD or > client related would be much appreciated. While running similar tests (httperf or http_load) with large numbers of TCP sessions where the client and the server are running OpenBSD, I've run into issues which appear to be related to filling up the local host (not pf) TCP state table with TIME_WAIT entries on the client, the server, or both. This can be diagnosed by running "netstat -np tcp" on the client/server, right when the problem starts. Kevin Kadow
Re: Adding support for FTP
On 10/24/05, Daniel Hartmeier <[EMAIL PROTECTED]> wrote: > On Mon, Oct 24, 2005 at 06:14:49PM +0930, Aluminium Oxide wrote: >>While is the satisfactory and workable solution using a rdr and passing >>the role to an ftp-proxy, I would like to add to pf the capability to >>actually monitor the erection of an ftp connection and creating an >>anticipatory state to permit : . . . > If your module simply scans individual packets' payload to > search for a magic string, it will be fooled like this. I agree with Dan. One alternative to bypassing ftp-proxy might be to enhance the interaction between ftp-proxy and pf, so instead of proxying the data connection, ftp-proxy can optionally build the appropriate temporary NAT and pass rules to allow the data connection via pf, eliminating a performance bottleneck while keeping *most* of the security of ftp-proxy. Two drawbacks to the above approach are the loss of visibility into and transfer accounting for the data connection, and greater exposure to attacks such as this one: http://www.enyo.de/fw/security/java-firewall/ Kevin Kadow
Re: Throttle connections from CIDR block?
On 8/17/05, Daniel Hartmeier <[EMAIL PROTECTED]> wrote: > On Wed, Aug 17, 2005 at 03:52:54AM -0500, Kevin wrote: > > Some applications include code to throttle the number of concurrent > > inbound connections from any CIDR block, this is a common request > > for SMTP listeners. > > Sounds like a nice feature. If you volunteer to implement it, I think I'll just buy Frantzen another nice bottle of scotch and let him do the coding -- It's been a long time since I looked under the hood of pf. > there will probably be some technical questions regarding > "from any CIDR block". For instance, you might implement something like > > pass ... keep state (max-src-states 20 combine /24) > which partitions the entire address space into non-overlapping /24 > blocks (so any possible address falls within exactly one of those > blocks), and enforces a maximum of 20 states for each such block. Rather than "combine", I'd use suggest making this an option to source-track, e.g. "source-track mask /24", and implement the feature by the expedient hack of using the mask with AND to zero out the bits beyond the mask before updating or checking state counters. So setting "source-track mask /24" globally or one any individual state rule would accomplish what the OP requested. > A broader interpretation of "any /24 block" would involve overlapping > blocks, and some sliding window algorithms, which can easily become > expensive. > > I.e. if you had > > -|-|-|-|- > 10.1.1/24 10.1.2/24 10.1.3/24 > 15 10 > |-| > > with 15 states from the "right" side of 10.1.1/24 (say, from source > 10.1.1.253) and 10 states from the "left" side of 10.1.2/24 (say, from > source 10.1.2.2), would that be a violation, because all these 15+10=25 > addresses are within one block of the size of a /24? I agree. We need to creatively interpret the users request to mean CIDR blocks so the specifications become a trivial set of diffs instead of a grad student's entire summer project. So where I said "all arbitrary /24 blocks", substitute the more technically accurate phrase "all network prefixes". Some users, such as in your example above, might choose to use a /22 mask so they can aggregate 10.1.0.0 - 10.1.3.255 with a single set source-track counters. Kevin Kadow
Re: Throttle connections from CIDR block?
On 8/17/05, Daniel Hartmeier <[EMAIL PROTECTED]> wrote: > On Wed, Aug 17, 2005 at 01:42:52PM +0800, Kent Ho wrote: > > Is there a way to throttle the number of connections from a CIDR block? > > > > e.g. Allow only 20 connections from the entire 192.168.2.0/24 subnet. . . . > Yes, it's possible with per-rule limits: restricting the number of > states one rule may create, like > > pass ... from 192.168.2.0/24 ... keep state (max 20) Hey, that's a cool feature I hadn't noticed. Unfortunately, just like queueing, you have to know which specific networks your traffic is coming from in order to control the rate, whereas for a web server you probably want to limit sessions and bandwidth for any and all arbitrary /24 blocks. How well can pf optimize a ~10 million line policy? > The usual per-IP limiting options (source-track, max-src-nodes, > max-src-states, max-src-conn, and max-src-conn-rate) don't work per CIDR > block, however. Some applications include code to throttle the number of concurrent inbound connections from any CIDR block, this is a common request for SMTP listeners.
Re: setting source ip on multiple aliases
On 8/2/05, quel <[EMAIL PROTECTED]> wrote: > I am trying to find the appropriate way to set the external ip used. I > have a user who wants their outbound traffic to all go out their ip. This > way they have their reverse appropriate. > > ifconfig snip: > inet 69.13.34.82 netmask 0xfff0 broadcast 69.13.34.95 > inet 69.13.34.83 netmask 0xfff0 broadcast 69.13.34.95 > inet 69.13.34.94 netmask 0xfff0 broadcast 69.13.34.95 > > .82 is the base ip and .94 is the specific alias in question > > route-to doesn't work because the gateway is the same for all the ips > > Perhaps something like the following, except you can't specify user > nat on $ext_if inet from user aramith to any -> 69.13.34.94 > > I've searched google and the lists to no avail. I presume there is a > trivial way to accomplish this. You can solve this by using tags: nat on $ext_if inet from any to any tagged aramith -> 69.13.34.94 . . . pass out from any to any user aramith tag aramith I just happen to have read the section on tagging in "Building firewalls" last weekend. Kevin Kadow
Re: viewing packet data with tcpdump?
On 6/7/05, Rick Barter <[EMAIL PROTECTED]> wrote: > I use tcpdump to trouble-shoot my firewall, set up my rules, etc. I > found the -x option which dumps the packet in hex. Can I view the > packet data with tcpdump or do I need to install Ethereal or something? Have you tried -X (uppercase?) You might also look at /usr/ports/net/ngrep. > Any help is appreciated. > > rvb >
Re: filter string
On 6/1/05, Rogério Moura <[EMAIL PROTECTED]> wrote: > I like to know if PF can block packets by the content (type > patch-o-magic string of IPTABLES), because my network have connections > of skype and messenger, this programs use ports that are allowed in > the firewall, type 80, 443 and I not know how block this programs This is not currently a function of 'pf', See /usr/ports/net/ngrep or http://snort-inline.sourceforge.net/ You may wish to review your policies -- both your firewall policy in pf, and your written acceptable usage policy (AUP) for your "customers". The specific problem of abusive programs abusing outbound open ports to run arbitrary protocols is a growing issue. The first step in addressing the issue to to lock down outbound connectivity. If you can force all legitimate HTTP/HTTPS traffic to use an explicit proxy, (HTTPS won't work through transproxy), you can just deny all outbound connections not processed through the proxy. Then it's just a question of how to configure your proxy to break skype, messenger, etc. Even after forcing all outbound sessions to be proxied and logged, you will run into protocols and tools that can sneak out through a proxy (AIM, Limewire, etc all can be configured to abuse a proxy gateway). Worst case, you'll have verbose logs of all outbound traffic that looks like web traffic, and you can solve the social problem of AUP enforcement through social means -- I recommend public hangings at dawn. Kevin Kadow
Re: Why start with "block"?
On 5/4/05, Jonathan Camenisch <[EMAIL PROTECTED]> wrote: > Just wondering...it seems that most rule examples start out with > "block in all/block out all", wouldn't it more efficient to put "block > all" at the end of the rules and use "quick" to pass packets? That > would be one less rule that gets parsed. Putting in "block all" as the very first rule ensure the "default deny" security posture of the packet filter is made explicit. man pf.conf . . . For each packet processed by the packet filter, the filter rules are evaluated in sequential order, from first to last. The last matching rule decides what action is taken. . . . If no rule matches the packet, the default action is pass. To block everything by default and only pass packets that match explicit rules, one uses block as the first filter rule. . . . Not everybody wants to build their policy with "quick", so this approach allows the operator to override the "default deny" policy selectively, without having to worry about accidentally passing traffic because of a missing "deny" rule at the end of the policy. There's no reason why you cannot build your policy upside down, if you so choose. Starting out a policy with 'block" as the first filter rule is inherently a style decision, not an absolute requirement. Kevin Kadow
Re: Why start with "block"?
> Just wondering...it seems that most rule examples start out with > "block in all/block out all", wouldn't it more efficient to put "block > all" at the end of the rules and use "quick" to pass packets? There are a variety of reasons why but most notably (for me at least) is that in many instances there are multiple things taking place on the same IP, port, or protocol, and you just don't want to block *all* of that traffic only some of it. By moving to a default block stance, you're able to do both selective passing and blocking sanely by IP, port, or protocol and not having to jump through mental hurdles to get there. Additionally, in many networks there are multiple people who're responsible for maintaining rules on many servers / firewalls, and seeing the default rules up top keeps things clean and sane--particularly in a heterogeneous firewall environment. > That would be one less rule that gets parsed. To (mis)-quote Henning, "Pfft. This is trivial." ;-) Kevin -- http://www.ebiinc.com : Employee Background Screening from EBI A leader in corporate background checks, worldwide.
Re: how to setup load balancing with 2 proxy?
On 5/2/05, eca lionhart <[EMAIL PROTECTED]> wrote: > hi... > i have something problems in setup load balancing.How to setup load > balancing in squid?with 2 proxy.can you help me?.thanks I'm assuming you refer to having two physically distinct squid caches? If you are not using transparency (clients configure a proxy server), then you might look into using a Proxy Automatic Configuration (PAC) script on the clients. The PAC syntax support both load distribution and also failover, it's basically a limited subset of javascript. If you are using transparency, you could use 'pf' to direct some requests to one cache and some to a second cache, it's just like load-balancing any other TCP service. You'll need to add your own failover mechanism. Kevin Kadow
Re: Feature request - setting TOS
On Apr 12, 2005 5:20 AM, Peter N. M. Hansteen wrote: > Kimi Ostro writes: > > I would not usually ask for a feature. Anyway, the proposal would be > > that you could set the TOS on TCP/UDP packets like so: > > Sounds somewhat like you could achieve at least some of the same > effect via altq, with a set of queues and priorities. I believe the idea here is to set TOS bits on the packets as they pass through the OpenBSD gateway, so *other* routers in the path can act accordingly, using their own queues and priorities. Kevin Kadow
Re: Headache with dual WAN and "source route verification"
On Apr 10, 2005 1:13 AM, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > On Apr 8, 2005 3:49 PM, [EMAIL PROTECTED] wrote: > >> I am running pf in an environment with two WAN connections, > > > > I noticed you don't mention the specific version of OpenBSD? > > > >> and pf is configured to load-balance outgoing traffic. > >> This worked nicely for quite a while, then one ISP turned on > >> "source route verification" on their DSL circuits. This causes > >> any packets coming into their equipment to get dropped if the > >> source address is not within the block that they have assigned. > > > > This sort of anti-spoofing by ISPs is generally a very good thing > > for the Internet as a whole. That said, I'm in the same boat -- > > two ISP uplinks, one with an assigned subnet, and the other > > doing anti-spoofing filtering on packets injected by customers. > > > > > >> When state is established by an incoming connection, > >> none of my rules to redirect WAN traffic are effective and > >> some connections cannot be established. > >> > >> What are my options to ensure that _only_ traffic with a > >> source address belonging to ext_if2 goes out ext_if2 ? > > > > The trick is to change all of your lines that are currently of the > > form : > > pass in on $ext_if1 inet proto . . . keep state > > pass in on $ext_if2 inet proto . . . keep state > > > > By including an option specifying the 'reply-to' interface: > > > > pass in on $ext_if1 reply-to $ext_if1 inet proto . . . keep state > > pass in on $ext_if2 reply-to $ext_if2 inet proto . . . keep state > > > > This instructs pf to ignore the system routing table, and instead > > set the next hop for replies associated with a particular state > > entry to go out via the interface specified in the 'reply-to' option. > > OpenBSD 3.6-stable > > Beautiful - reply-to seems perfectly suited to address the problem. For some > reason, this change breaks inbound mail (I think all inward connections) > completely. The inbound connection arrives at the WAN1 interface. I see it get > passed to the mail server on the LAN interface, and the mail server responds. > That's the last I see of the response. It does not go out either WAN interface > and is does not show up in pflog0. Perhaps I need some better debugging > techniques to learn where and why the response is dumped. To my simple > understanding, the initial inbound connection should have created a state for > the response, which would have a free pass back out the firewall. Maybe you need to add the 'reply-to' option to all of your 'pass-in' statements?
Re: Headache with dual WAN and "source route verification"
On Apr 8, 2005 3:49 PM, [EMAIL PROTECTED] wrote: > I am running pf in an environment with two WAN connections, I noticed you don't mention the specific version of OpenBSD? > and pf is configured to load-balance outgoing traffic. > This worked nicely for quite a while, then one ISP turned on > "source route verification" on their DSL circuits. This causes > any packets coming into their equipment to get dropped if the > source address is not within the block that they have assigned. This sort of anti-spoofing by ISPs is generally a very good thing for the Internet as a whole. That said, I'm in the same boat -- two ISP uplinks, one with an assigned subnet, and the other doing anti-spoofing filtering on packets injected by customers. > When state is established by an incoming connection, > none of my rules to redirect WAN traffic are effective and > some connections cannot be established. > > What are my options to ensure that _only_ traffic with a > source address belonging to ext_if2 goes out ext_if2 ? The trick is to change all of your lines that are currently of the form : pass in on $ext_if1 inet proto . . . keep state pass in on $ext_if2 inet proto . . . keep state By including an option specifying the 'reply-to' interface: pass in on $ext_if1 reply-to $ext_if1 inet proto . . . keep state pass in on $ext_if2 reply-to $ext_if2 inet proto . . . keep state This instructs pf to ignore the system routing table, and instead set the next hop for replies associated with a particular state entry to go out via the interface specified in the 'reply-to' option. Kevin Kadow
Re: Dropping fragmented ICMP echo-reply packets sourced from Solaris?
On Apr 1, 2005 2:06 AM, Cedric Berger wrote: > Kevin Kadow wrote: > >I've noticed frag'd ICMP echo-replies being dropped by "scrub in" when > >they come from a Solaris host. Is this a known issue? > > Oh Yeah, > That's a long time annoyance of the scrub code, which > (wrongly IMO, but others disagree) drops fragments which have > the "DF" bit set. You'll get the same problem with fragmented UDP > packets from Solaris and Linux (typical with NFS) > > Cedric That makes sense. Changing the pf.conf entry to read "scrub in no-df" makes the problem go away. Kevin
Dropping fragmented ICMP echo-reply packets sourced from Solaris?
I've noticed frag'd ICMP echo-replies being dropped by "scrub in" when they come from a Solaris host. Is this a known issue? On a related note, is there any way to log packets dropped by "scrub"? Doing 'ping -s 1473 target', if the target is a Cisco router or a BSD machine, the reply packets are accepted and ping shows success, but the exact same ping command transmitting to Solaris 9/Sparc will fail; tcpdump shows the packets being received by OpenBSD My pf.conf includes a "scrub in" command. Replacing the line with a explicit scrub command of either "scrub in all fragment reassemble" or "scrub in all fragment crop" does not change the behavior. If I comment out the pf.conf line "scrub in", then *ALL* fragmented ping replies fail and the frags logged by pflog as dropped packets; with scrub enabled, only the replies coming from a Solaris machine are dropped. This does not appear to be an out-of-order frag problem (see tcpdump info below). If I run "sudo ping -c 2 -s 1473 target-solaris", the ping fails: PING target-solaris (172.25.151.72): 1473 data bytes --- 172.25.151.72 ping statistics --- 2 packets transmitted, 0 packets received, 100.0% packet loss And during that time, "tcpdump - -s 1518 icmp" shows this: 1112315188.969521 172.25.109.31 > 172.25.151.72: icmp: echo request (frag 41696:[EMAIL PROTECTED]) 0.04 172.25.109.31 > 172.25.151.72: (frag 41696:[EMAIL PROTECTED]) 0.001356 172.25.151.72 > 172.25.109.31: icmp: echo reply (frag 57180:[EMAIL PROTECTED]) (DF) 0.04 172.25.151.72 > 172.25.109.31: (frag 57180:[EMAIL PROTECTED]) (DF) 0.10 172.25.109.31 > 172.25.151.72: icmp: echo request (frag 47724:[EMAIL PROTECTED]) 0.04 172.25.109.31 > 172.25.151.72: (frag 47724:[EMAIL PROTECTED]) 0.001241 172.25.151.72 > 172.25.109.31: icmp: echo reply (frag 57181:[EMAIL PROTECTED]) (DF) 0.03 172.25.151.72 > 172.25.109.31: (frag 57181:[EMAIL PROTECTED]) (DF) ### # pf.conf # int_if="em0" TCPState="flags S/SA keep state" tablepersist scrub in block in block in log on $int_if pass out keep state pass out quick on $int_if inet proto tcp from any to any $TCPState pass in quick on lo antispoof quick for lo pass in quick on $int_if proto tcp from to any port ssh $TCPState pass in quick on $int_if proto tcp from any to any port www $TCPState pass in quick inet proto icmp from any to any icmp-type echoreq keep state ###EOF### Thanks, Kevin Kadow
Re: pf load balancing, macros, tables...
> > yet this does not: > > rdr on $ext proto tcp from any to port 80 -> > > \ > > round-robin sticky-address > > There was a bug fixed recently where pf would fail to select a > translation when a rule did not have an explicit (or implicit) address > family (IPv4/v6). This was backported to 3.6-stable, maybe you have an > older kernel. To test the theory, add 'inet' to your rule, which makes > the address family explicit. > > If this is not the problem, describe exactly how 'it is not working'. Mea culpa. I really should have given you more to go on. :-( That said, when looking at a tcpdump -netttvvvi pflog0 port 80, it was as you suspected: pf apparently wasn't selecting an appropriate translation rule so connections were getting blocked my the default block rule. As described, simply changing to rule to this: rdr on $ext inet proto tcp from any to port 80-> \ round-robin sticky-address makes everything pass through like a champ. Now to grab an updated 3.6-stable. :-) Thanks so much. Kevin
pf load balancing, macros, tables...
Hi all, I'm in the process of setting up a group of load balanced servers, and I've come across something (I think) is a bit unusal with macros and tables and load balancing. I use tables fairly extensively in our two 3.6-stable OBSD pf/CARP firewalls, and I'd like to use them in configuring our load balanced server groups in pf. It seems that this works: rdr on $ext proto tcp from any to $web_servers_ext port 80 -> \ round-robin sticky-address yet this does not: rdr on $ext proto tcp from any to port 80 -> \ round-robin sticky-address Is this working as advertised or am I missing something? FWIW: I noticed this is the only place in the ruleset I would like to use multiple tables (vs macros) in one rule, so I'm wonding if this is a "one-table-per-customer" issue or if this is something particular to load balancing. As it's *so* easy to add / delete servers from the load balanced server group when IPs are all you see when you open that particular table, having use of two tables in one rule would be particularly nifty. As always, thanks. Kevin -- http://www.ebiinc.com : Employee Background Screening from EBI A leader in corporate background checks, worldwide.
Re: watching pflog
On Tue, 1 Mar 2005 16:59:53 -0600, eric <[EMAIL PROTECTED]> wrote: > On Wed, 2005-03-02 at 11:22:15 +1300, Russell Fulton proclaimed... > > I want to monitor the output from pflog in more or less real time. It > > isn't clear to me what is the best (read simplest ;) way to do this. > > What I really want is a version of tcpdump that will effectively do a > > tail -f on /var/log/pf. Ideally it would cope with logfile rollovers > > too. > > What was wrong with watching the pflog interface? > > Actually, you bring up an interesting idea; multiple interfaces for logging. > > Is there any possibility that a far-off-wish-list couple include the ability > to route packets from a pflog device onto the wire and then monitor that > traffic? Say on a monitor network or something like that. It'd be helpful > for those of us who are looking at clusters and several firewalls :) IIRC, this is exactly what 'dup-to' is designed for. It is important to note that dup-to works *exactly* like route-to, which means that the *ether* frame (assuming the dup-to destination is a hop via Ethernet) will be recreated (with the MAC of the dup-to destination) but the IP payload will be exactly the same as the packet being dup'd, including the original destination IP. Incautious use of dup-to will create routing loops and generally confuse the heck out of your network admins. This may be considered to be a feature. KK
bridging, inbound load balancing & CARP
Hi all, After some serious head scratching, lots of searching, and much brow furrowing, I can't find an answer to this simple question about bridges and load balancing with OpenBSD: Can one do inbound load balancing between a couple of web servers (box01 & box02) when running two OBSD machines as bridging firewalls w/CARP on the front end? If not, is there some other way (without having the ISP route our /24 for us) for us to pull this off? FWIW in the present scenario below, I'm pointing to 208.12.17.225 with all our machines in /etc/mygate. The network looks like this: INTERNET /|\ | [ISP's ROUTER] (208.12.17.225/32<-- Part of 208.12.17.224/29.)) /|\ | [MY SWITCH01] / \ / \ [gw1][gw2] (OBSD bridges 208.12.17.226 & .227<-- Part of 208.12.17.224/29.) /|\ /|\ | | [MY SWITCH02] /|\ /|\ | | [box01] [box02] (208.19.20.25 & 208.19.20.27<--Part of 208.19.20.0/24) Thanks so much for your $.03 on this everyone. Kevin -- http://www.ebiinc.com : Employee Background Screening from EBI A leader in corporate background checks, worldwide.
Re: ftp-proxy and pf
On Tue, 8 Feb 2005 23:22:15 +0100, Daniel Hartmeier <[EMAIL PROTECTED]> wrote: > On Mon, Feb 07, 2005 at 10:08:24AM -0500, Peter Fraser wrote: > > After reading the ftp rfc's (959 and 1123) I don't understand > > how ftp-proxy can work without support of pf, and any > > ftp client that works in active mode with the current ftp-proxy > > is in violation of these rfc's. > > > > In particular section 3.2 of rfc949 and 4.1.2.12 of rfc1123 > > together say that the data from an active ftp connection > > must come from port ftp-data and the IP address of the > > control channel( i.e. the IP address the ftp open command) > > The requirement that the data connection must come from port ftp-data is > commonly relaxed. In order for the ftp server to use port 20 (which is > privileged, < 1024), the server would have to run as root permanently. Systrace can enable specific operations as root without running the daemon under the root UID. The ftp-proxy process currently uses root to access /dev/pf for the DIOCNATLOOK ioctl; that also could be handled by systrace. Would it be reasonable to modify ftp-proxy to attempt to bind the source port to ftp-data (port 20) even when not running as root, then fallback to a socket in the designated range only if binding ftp-data fails? Looking at ftp-proxy.c, the change to handle this would be minor, I can submit a diff if there is interest. Kevin Kadow
Re: PF Question: auth (port 113) one to many rdr (moved from newbies list)
On Sun, 30 Jan 2005 15:41:41 -0600, Rick Barter <[EMAIL PROTECTED]> wrote: > Kevin wrote: > > > I do not think this is technically possible without extensive effort, > > nor desirable. The 'ident' (auth, tap, TCP/113) protocol is no longer > > very useful for the original purpose, but it is still required by IRC > > servers. > > > > Many systems and firewalls, including OpenBSD (via the '-H' flag), > > offer an identd work-alike which will provide a reasonable answer > > to any and all ident queries. > > > Why not just go into /etc/inetd.conf and change the arguments on > > identd from '-el' to '-elH'. This will cause identd to always return an > > answer for *any* ident query, valid or invalid. > > Okay. I've enabled this (-elH) and restarted inetd on my firewall and > have changed the rule to: >pass in log on fxp0 proto tcp from any to any port = auth Off the cuff, I'd suggest this: pass in on $ext_if proto tcp from any to ($ext_if) port = auth keep state flags S/SA > However, I still wish I knew how to see the request from the IRC > server and the response from identd. Is there a way? Using the '-l' flag in /etc/inetd.conf, identd logs to syslog. You can watch the actual conversation with the remote IRC server via: tcpdump -i fxp0 -p -n -s 1500 -X port auth There is no need for "synproxy" or "modulate" on inbound traffic that terminates on the firewall itself, and with "keep state" you can lock down the "pass out $log_flg on $ext_if proto tcp all modulate state" line. > Furthermore, how vulnerable does it make me by not forcing > the SYN flag to be set? If your policy includes 'keep state' on the incoming request, state table entries are created for incoming sessions permitted by the policy, which avoids extra "pass out ..." entries, and takes care of the SYN flag question as well. Kevin Kadow
Re: PF Question: auth (port 113) one to many rdr (moved from newbies list)
On Sat, 29 Jan 2005 09:56:56 -0600, Rick Barter <[EMAIL PROTECTED]> wrote: > I have been racking my brain and reading, but can't figure out how to > setup pf to pass or rdr ident requests to the the proper client > (behind the firewall) that is trying to connect to an irc server. I > want to rdr the auth (port 113) request coming into my firewall to > whichever machine is trying to connect to an irc server. How can I do > this? I do not think this is technically possible without extensive effort, nor desirable. The 'ident' (auth, tap, TCP/113) protocol is no longer very useful for the original purpose, but it is still required by IRC servers. Many systems and firewalls, including OpenBSD (via the '-H' flag), offer an identd work-alike which will provide a reasonable answer to any and all ident queries. > Currently I have a rdr rule that handles the ident requests by passing > them to my windows machine running mIRC. mIRC has built-in ident > emulator and works fine. I've tried to setup an ident server on my > firewall that will handle all ident requests. I enabled identd in > /etc/rc.conf and disabled the one running from /etc/inetd, but with no > joy. Why not just go into /etc/inetd.conf and change the arguments on identd from '-el' to '-elH'. This will cause identd to always return an answer for *any* ident query, valid or invalid. > What am I missing here? Does anyone have such a setup working? Technically, it should be *possible* to create an identd service running on a NAT gateway which would answer ident queries by looking up the internal originating IP address and returning an ident token corresponding to the actual source IP address, providing better forensics info than just making up a random reply. The primary drawback in implementing the above would be the requirement for the identd server to run as a privileged user in order to have access to the /dev/pf (root only) device to perform DIOCNATLOOK ioctl calls In reality, the ident protocols is no longer used or trusted to provide valid and useful responses, and exists solely as an added check done by IRC servers (of limited value, IMHO) in their fight against compromised bots and open proxies. Kevin Kadow
Re: Jeff quast
On Thu, 27 Jan 2005 14:27:40 -0500, Amir S Mesry <[EMAIL PROTECTED]> wrote: > Seems to me he can use use macro's for them. Ie. > Eth0="xl0" > Eth1="fxp0" > > And only have to change those 2 lines when nics are changed. Then it's > almost like using linux, if you like to do it that way. Now if only pf.conf could use #include, you'd really have something.
Re: transparent squid and load balancing outgoing traffic
On Tue, 25 Jan 2005 18:19:36 -0300 (BRT), Emilio Lucena
<[EMAIL PROTECTED]> wrote:
> I am trying to ge these two features to work together. The rule I am using
> for load balancing is:
Can you provide more information on your load-balancing configuration,
specifically on what the two external interfaces are connected through?
Are you doing any NAT?
(I suppose this is why everybody insists on seeing a complete pf.conf)
> pass in log-all on $int_if route-to \
>{ ($ext_if1 ) , ($ext_if2 ) } round-robin \
>inet proto tcp from $lan_net to any flags S/SA modulate state
>
> I am following Daniel's intructions (http://www.benzedrine.cx/transquid.html)
> for setting up transparent squid. Now, since web traffic is automatically
> redirected to 127.0.0.1:3128, I think there must be a pass rule, like the one
> below, BEFORE the above rule. Otherwise, squid will not be able to handle
> the web traffic.
>
> pass in quick on $int_if inet proto tcp from any to 127.0.0.1:3128 keep state
^^^
I think this line should read:
pass in quick on $int_if inet proto tcp from $int_net to ($int_if)
port=3128 keep state
> Then the traffic is delivered to squid to be dealt with. But, then this
> means squid will use the default route to open the http connection to the
> Internet server and bypass the load balance rule, right?
Correct. Squid, being a full "application proxy" for HTTP/HTTPS/FTP/Gopher,
will generate new TCP sessions for the outbound connection. These sessions
will of course originate from the local machine (not come in via $int_if),
and will show as the source IP address the address of the "default" outbound
interface, unless you configure a tcp_outgoing_address in squid.conf
If you set tcp_outgoing_address to an alias IP on $int_if, you could try this:
pass out route-to \
{ ($ext_if1 ) , ($ext_if2 ) } round-robin \
inet proto tcp from $squid_ip to any flags S/SA modulate state
> So, is this setup incompatible or there is some trick I can do to make it
> work?
Depending on how your inbound traffic is load-balanced, you might not need to
do any tricks, as 99.99% of the squid-related traffic is going to be downloads,
limiting the need to load-balance outbound -- the exception being if you are
using NAT to rewrite outbound sessions to be sourced with a different ext_if
interface address to force reply traffic to come back the same path it went out?
Kevin
Using DNS names in pf.conf?
Are there any "gotchas" I should know about when using dns names in pf.conf, specifically in tables used as destinations for permit rules? The addresses for the hosts change, but relatively rarely. Is it safe/recommended to include the hostnames in pf.conf, or would it be better to just create text files listing the hostnames and create cron jobs to periodically refresh the tables, like this: @reboot pfctl -q -Treplace -tcvshosts -f /etc/cvshosts.txt @weekly pfctl -q -Treplace -tcvshosts -f /etc/cvshosts.txt This seems to add complexity where it is not really needed, assuming there are not risks or race conditions with putting DNS names into pf.conf and populating the tables at boot time and whenever I manually reload the ruleset? I am running a local caching resolver, but I do also list my ISP's nameserver in /etc/resolv.conf. Thanks, Kevin
Re: VPN client cannot connect through OpenBSD router/firewall
On Mon, 17 Jan 2005 22:38:05 +0100, Laurent Cheylus <[EMAIL PROTECTED]> wrote: > Hi Rick, > On Mon, Jan 17, 2005 at 12:06:54PM -0600, Rick Barter wrote: > > Okay. I have a problem that I can't get my brain around and I need > > some help. My wife needs to connect to her VPN at work. I've > > captured packets for her connection and see that it's connecting to > > her work server on ports 53 (dns) and 500 (isakmp). Are you sure about the port 53 part? Normally UDP/53 would be used once to find the IP address of the VPN gateway, then the connection is negotiated using IKE on UDP/500 (both source and destination port are 500) then the actually VPN traffic continues on IP Protocol 50 (ESP). The client may later do further handshaking on UDP/500 for rekey, etc. Many headends enforce the requirement that incoming IKE packets have both source and destination port of 500. PAT will rewrite the source port, causing the IKE packets from the internal client to be rejected at the headend. > > I thought that since she was initiating the connections to port 53 and > > 500 that the keep state entries on the outbound tcp and udp traffic > > would be enough to ensure she could connect and wouldn't require me to > > set up NAT for these connections. Am I wrong? What am I missing here? Correct. There should not be a need for adding specific NAT policies just for the VPN. The existing NAT and keep state should suffice. > According to your pf.conf, your TCP/UDP outbond connections are nated. > > To use VPN IPsec client with a NAT gateway like yours, VPN client must > use NAT-Traversal (ESP packets encapsulation in UDP packets on port > 4500). And the IPsec gateway of your wife at work must also support > NAT-Traversal. Nat-Traversal is not absolutely required for a VPN session using ESP in "Tunnel Mode" to succeed through a smart (static-port, IPSEC-aware) NAT. The core of the problem is that NAT breaks AH, will break ESP in transport mode, and PAT can cause problems with IKE.
Re: OFF Topic Might not belong on the list "PF anf VPN to Cisco"
On Thu, 30 Dec 2004 14:57:04 -0500, Elijah Savage <[EMAIL PROTECTED]> wrote: > I am truly missing the point here then. I want to setup a VPN Tunnel > between a Cisco IOS device which are cisco routers no pix's involved and > a OpenBSD firewall. Some other vendors provide whitepapers explaining in some detail exactly how to go about setting up IPSEC between their product and OpenBSD (e.g. Nortel Contivity). I am not aware of any such document from Cisco regarding the PIX. You might find the answers you are looking for in the archives of (or by asking on) the OpenBSD-IPSec-Clients mailing list: http://www.allard.nu/mailman/listinfo/openbsd-ipsec-clients Kevin Kadow
Re: pf.conf feedback,critique...
On Mon, 20 Dec 2004 18:42:58 +0100 (CET), J. <[EMAIL PROTECTED]> wrote: > # $OpenBSD: pf.conf,v 1.28 OpenBSD 3.5-current (GENERIC) Why not upgrade to 3.6-stable, before going production? > # 1. ftp clients [external,incomming] > rdr on $ext_if proto tcp from any to any port 21 -> $ftp_server port 21 > rdr on $ext_if proto tcp from any to any port 49152:65535 -> $ftp_server port > 49152:65535 You might consider this instead, if you just have a single IP (static or dynamic) from your ISP: rdr on $ext_if proto tcp from any to ($ext_if) port 21 -> $ftp_server port 21 rdr on $ext_if proto tcp from any to ($ext_if) port 49152:65535 -> $ftp_server port 49152:65535 > # block 192.168.1.40 to 224.0.0.22 , winXP IGMP-2 SPAM > # block in log quick on $int_if from $fam to 224.0.0.22 Personally, I do not use Multicast for anything, so I use the following: block drop in quick from any to 224.0.0.0/4 > # Traffic must also be passed to and from the internal network > pass in on $int_if from $int_if:network to any keep state Are you sure about this? Personally I'd restrict this policy, breaking this down into a number of 'quick' rules for specific destination ports/protocols.
Re: CBL
On Wed, 15 Dec 2004 10:37:33 -0800, Bryan Irvine <[EMAIL PROTECTED]> wrote: > I'm trying to laod the enormous CBL into my spamd table, but it seems > to be far to large. What happens when you try? > I found this thread from back in April: > > http://archive.netbsd.se/?ml=openbsd-pf&a=2004-04&t=127074 > > Does this apply if I'm on 3.6? I don't want to go applying old patches. > > The thread seems to mention a Gig of RAM as some sort of requirement > (actually it says you shouldn't need more than 1G) is 1G recomended if > you are going to be loading the CBL? It appears that the referenced message is about OpenBSD 3.4, there have been a lot of changes to pf tables since then.
Re: Internal IP Address Detection Through NAT
On Wed, 8 Dec 2004 19:34:03 +0530, Siju George <[EMAIL PROTECTED]> wrote: > On Wed, 8 Dec 2004 11:22:01 +0100, Daniel Hartmeier > <[EMAIL PROTECTED]> wrote: > > It might be some game with IP TTL values, but pf should always replace > > the internal address with the gateway's. The tcpdump will tell. I've never seen pf "leak" the original inside source IP address from a NAT'd client. > I found the same thing happenning when I use Squid Proxy to connect to > internet. So I should be changing some configuration in squid isn't > it? Any comments? This is correct. Squid by default includes a "X-Forwarded-For: header on each HTTP request showing the original requesting IP address. This can be disabled in squid.conf with "forwarded_for off". Additionally, Squid will also append a "Via:" header which reveals information about the cache -- some web discussion boards will refuse access if the Via header is present. The code which generate both of these headers is located in 'http.c' in the Squid source tree. The only way to disable the 'Via' header in Squid2.5 is to edit the source and recompile. Kevin
Re: many to many dup-to option?
> >Maybe you can to use multicast address as destination. > > Unfortunately dup-to requires you to specify a physical network > interface for where to send the traffic to. You can specify an > address associated with that network interface, but I'm not really > sure what benefit this has because your ids/analyzer/etc still has to > be attached to that rj45 port. IIRC, specifying an address associated with that network interface will not re-write the destination IP in the IP packet, but instead just uses ARP to specify the destination MAC at the ether layer? Perhaps you could specify the outbound interface with the broadcast address, resulting in the packet being sent with a broadcast MAC, such that a switch will reliably flood the packet out to all active ports? > I'm at that point where my network feeds are so intensive that a hub > is no longer sufficient, Can you explain further why a hub is no longer sufficient? If you can ensure that the only device transmitting to the hub is the host sending out the dup-to traffic (perhaps by physically disabling transmit lines on the "listen only" ports), then a hub should be able to flood out packets from a single talker to multiple listeners at wire speed. Kevin
Re: many to many dup-to option?
On Wed, 1 Dec 2004 14:55:38 -0500, Matt Van Mater <[EMAIL PROTECTED]> wrote: > I'd like to aggregate traffic coming in on several interfaces into one > 'pool' of traffic and then send a copy of this traffic to multiple > hosts. I don't know if this is currently possible, and was wondering > if it is even remotely on the radar of the developers? I do not believe OpenBSD can currently dup-to multiple destinations, without some nasty kludge. > I may be able to do this in an inelegant way, but I haven't tested to > see if it works, or if PF just isn't yelling at me for being dumb: > > ext_if="fxp0" # traffic feed 1 > int_if="xl0" # traffic feed 2 > ids_if="xl1"#port to feed traffic to for IDS / analysis > ids_if2="xl2"#port to feed traffic to for IDS / analysis > .. > pass in on $ext_if dup-to $ids_if > pass in on $ext_if dup-to $ids_if2 > pass in on $int_if dup-to $ids_if > pass in on $int_if dup-to $ids_if2 > > If this is a viable option, it would be nice to have the syntax be like > pass in on ($ext_if $int_if) dup-to ($ids_if $ids_if2) > But that's just a wishlist item and doesn't really matter. Technically it should be possible to extend the dup-to syntax to have multiple destinations. I'd guess this would add significant overhead. > Will this actually work as I described? pfctl takes these configs and > happily loads it, but I wonder if there is a better way to do this. I do not believe that this will work, as only the last matching rule (or first matching rule that has 'quick') is used. > I think I could combine a netoptics >spyderswitch to aggregate the feeds and then a regeneration tap to >spread it back out to multiple analysis boxes simultaneously, but that >would cost many thousands of dollars. I'd think that this could be accomplished with a single NetOptics product, but it would still cost thousands of dollars. The big advantage to using NetOptics is that the passive taps are entirely transparent to the network (no single point of failure) and add effectively no latency. Kevin
AIM and packet filters (was Re: Logging Question)
On Fri, 12 Nov 2004 10:31:13 -0600, Phusion <[EMAIL PROTECTED]> wrote: > I'm having a problem because when I tried > AOL Instant Messenger, it should have been blocked, logged and not > been able to connect because it makes an outbound connection to tcp > port 5190 which isn't allowed, but it still works. AOL Instant Messenger (AIM) is one of the most effective 'firewall evasive" applications I have seen in my career. The software can make it out through just about any packet filter and even most application proxy firewalls. It is very difficult to block successfully. AIM will try to tunnel out via just about any TCP port you might have open for default route to the Internet, including FTP and SNTP. AIM can also work via a HTTP proxy, though this may require manual configuration in the AIM client setup screen. While a strong deep-protocol-inspection product like the IntruShield *might* detect the protocol anomoly, the only effective way for a stateful packet inspection device to block AIM is to refuse ALL traffic towards the IP addresses which host the "login.oscar.aol.com" service (there are approximately fifty such servers under aol.com and icq.com). Kevin Kadow
Re: Is having a GUI on an OpenBSD firewall a serious mistake?
On Sun, 10 Oct 2004 18:31:27 -0500, Shawn K. Quinn <[EMAIL PROTECTED]> wrote: > On Sunday 10 October 2004 14:19, you wrote: > > best firewall: openbsd without a gui > > > > second best firewall: openbsd with a gui > > Would it help to firewall out connections from the world interface on > the standard X Window System ports (6000-6009 or so)? I would think > that would satisfy any security issues that would be caused by running > X on the firewall. That'd be the absolute minimum; better still would be to bind all of the GUI protocol listeners to loopback (and 'pf' to filter loopback traffic by source UID). Even in the most paranoid X installation, there is still increased risk of compromise -- X11 is complex and has historically been a source of exploitable bugs, including in the xserver, font server, and in the protocol itself. Running a local display locally on the firewall host itself with mouse and keyboard also will have a negative impact on performance and stability. The real question is what technical advantage is provided by a full GUI running on the firewall itself, rather than having a separate "inside" (trusted) management host with a GUI and a mechanism to push changes up to the firewall from the management host? Have you considered instead loading web management (e.g. webmin) on the firewall, accessed via SSL? You could then lock down remote access to the https service., for example, using a combination of authpf and SSL client certificates. Kevin
Re: CIDR notation - block spam 220.87.30.0/24
On Fri, 8 Oct 2004 12:12:08 +0200, i.t Consulting <[EMAIL PROTECTED]> wrote: > Am Freitag, 8. Oktober 2004 07:53 schrieb Kevin: > > [ Evaluations: 961075Packets: 213111Bytes: 76349669States: 0 > > ] @34 block drop in log quick proto tcp from to any port = > > smtp . . . > > > > This is my primary mail server rejecting SMTP sessions from hosts > > listed in the Pan-Am DUL (http://www.pan-am.ca/pdl/). The first field > > of each line in the list is an IP address or subnet in CIDR notation, > > so it's easy to just pass the list through cut and then reload the > > table from a file. > > > > I have never encountered a false positive in my six months of using > > the PDL. YMMV. > > thanks for the interesting info. > 10994 addresses including CIDR-notation is pretty much to do for pf (?) > what does top tell you by average? As mentioned in the OnLamp interview (http://www.onlamp.com/pub/a/bsd/2004/04/15/pf_developers.html?page=2) table efficiency in 'pf' has improved massively in recent releases; tables of over 100K entries are no problem under 3.5. The real resource hogs on this machine are running SpamAssassin and ClamAV both under systrace. if anything, the 'pf' ruleset helps out by keeping down the volume of mass-mailer worms from dial-up, home broadband, and similar networks. > As interesting it is, I do not agree with PDL's policy " The PDL is a list of dialup and dynamic addresses; if you feel that this is not what you want to use in outright rejecting SMTP traffic, you might still choose to load the PDL as a 'pf' table and make use of this table in selective greylisting. > ...list of home dial-up, home broadband and similar networks..." > since small business often use ADSL connections; The PDL lists only *dynamic* IP address blocks -- most any business running a legitimate mail server will have static addresses, and will thus not be on the PDL. The PDL site specifically states "The PDL lists networks used for temporary Internet connections where no SMTP services are ordinarily found. Please remember this when making submissions, as submissions for networks that contain e-mail servers or fixed IP addresses may be refused." (http://www.pan-am.ca/pdl/adding.html) I'm satisfied with the accuracy of the PDL; for anybody who is not, the greylisting features of OpenBSD and pf should give a margin of safety against false-positives, with the drawback of significantly higher server load. A 'block in quick' rule in pf is always going to have less load than accepting those TCP sessions, forking a process, and then logging and dropping after the RCPT stage of the session... > and you can make your small business-server more secure than the one of an ISP > who has to take care of many different customers - including their spam > connections. Absolutely; I've built a few of these myself. All but the cheapest of small businesses will host their server on a static IP served from an ISP which permits mail servers in their TOS -- their address will not be listed in any of the various "dialup and dynamic" block lists, unless they sign up with a spam-friendly ISP. Kevin
Re: CIDR notation - block spam 220.87.30.0/24
On Thu, 07 Oct 2004 09:55:26 +0200, Cedric Berger <[EMAIL PROTECTED]> wrote: > i.t Consulting wrote: > > # pfctl -vvsr > > @16 block drop in log quick on rl0 proto tcp from to any > > port = smtp > > [ Evaluations: 13Packets: 0 Bytes: 0 States: > > 0 ] > > The ":*" after bloecke.port25 means the table does not exist. > Otherwise, the number after the ":" would tell you how many > addresses are currently in it. > Cedric For example: $ sudo pfctl -vvsr . . . [ Evaluations: 961075Packets: 213111Bytes: 76349669States: 0 ] @34 block drop in log quick proto tcp from to any port = smtp . . . This is my primary mail server rejecting SMTP sessions from hosts listed in the Pan-Am DUL (http://www.pan-am.ca/pdl/). The first field of each line in the list is an IP address or subnet in CIDR notation, so it's easy to just pass the list through cut and then reload the table from a file. I have never encountered a false positive in my six months of using the PDL. YMMV. Kevin (P.S. As counters are cleared when the pf ruleset is changed, the counters above are just one month's attempts.)
Re: How do I change my firewall ports to stealth mode?
On Tue, 28 Sep 2004 14:34:54 +0200, Volker Kindermann <[EMAIL PROTECTED]> wrote: > Hi Siju, > > The Port 113 was opened because the PF FAQ asked to open it for SMTP > > > > "Auth/Ident (TCP port 113): used by some services such as SMTP and IRC. The "auth" service (aka identd or "tap") was useful back in the day of multi-user machines where it could assist in providing information about which of many users (assuming none had root) originated an outbound TCP session. The service is of limited value today, and can in certain instances reveal information about processes on your server (this "information leakage" is addressed by OpenBSD's "-h" option to identd.) > I know that this is in the pf faq but I don't think that you really need it. I don't > know about IRC but you mentioned only SMTP on your side. Many IRC servers will drop sessions if they cannot talk to an ident service on the originating end. If you don't want your users to be on IRC; this could be considered as a benefit of blocking TCP/113 ;) > I'm running emailservers for years now and never ran an identd. And my clients don't > have an identd running either. > I don't think that you need this for smtp nowadays. While the identd service is not *mandatory* on servers which send outbound SMTP email, many remote SMTP servers will query identd when your machine connects as a SMTP client. If the service responds on your client, the username returned will be logged in the Received: header at the remote mail server. If your machine returns a RST in response to the SYN, the remote server will give up looking for identd and move on with the conversation. If your firewall blocks and drops the SYN packet on the identdport (TCP/113), the remote server will wait for an answer, and retransmit, sometimes for thirty seconds or more. Bottom line, if your server sends SMTP email to arbitrary remote SMTP servers, is is detrimental to "stealth" ident. If your mail sending host does not accept ident connections, your firewall rules should return RST, or live with the delay (and possible timeout failures) on each outbound SMTP session. Kevin
Re: squid in other route
On Sat, 25 Sep 2004 13:41:40 -0300, Gustavo <[EMAIL PROTECTED]> wrote: > I have a OpenBSD 3.5 with 3 external interfaces (WAN) and with squid > twirling. Can anybody translate "squid twirling" ? > xl0 -> 200.x.x.x (default route) > rl0 -> 192.168.254.253 (dsl) > rl1 -> 192.168.254.254 (dsl) > > He would like to make squid to leave for the interface rl1 the same > being that this twirling in this exactly gateway with default route xl0. > > how I could implement some soluction for this? Just a shot in the dark: If a TCP request comes in to the IP address of interface rl0, you can force reply packets for that same session to always be routed back out through rl0 by using "reply-to", e.g: pass in quick on rl0 reply-to rl0 proto TCP from any to any port 3128 flags S/SA keep state This won't have any effect on the connections that Squid initiates outbound to get objects requested by clients, but will ensure that the return packets for a TCP session that comes in on rl0 for TCP/3128 go back out on rl0, regardless of the route table. KevinK
Re: OpenBSD PF in the Enterprise?
On Wed, 22 Sep 2004 10:08:07 +0100, Greg Hennessy <[EMAIL PROTECTED]> wrote: > On 21 Sep 2004 23:20:32 -0700, [EMAIL PROTECTED] (Kevin) wrote: > >I'm sort of in the same boat. I have a strong case for replacing > >multiple PIX failover pairs with OpenBSD on Dell, > > They are installed, working and a sunk cost. > > Why would you waste money replacing them ? Cisco's annual maintenance fee for each PIX is about equal to our cost for a Dell to replace it. The annual cost for a Dell hardware support contract is minimal. Most of our PIX hardware is several years old, fully depreciated, and would need to be replaced in the near future, either with a higher-end PIX (with a small trade-in credit from Cisco) or some other stateful inspection packet filter firewall. In order to be able to continue on a supported platform with Cisco (to continue to have them as a target if something goes wrong) we need a maintenance contract. To keep maintenance on the PIX, Cisco requires that we upgrade to the latest code. This is understandable, but also poses a serious problem -- All of our configurations are based on "conduits", and Cisco is removing "conduits", so upgrading will require rewriting all configurations: http://tinyurl.com/6d58c We feel; that conduits are easy to understand and configure, are what our admins are trained in using, and make it less likely for a change in one conduit to accidentally impact a production service elsewhere in the configuration. The only suggestion Cisco has for making the move relatively painless is to purchase their CiscoWorks management solution and a Solaris box to run it (plus of course a yearly maintenance fee). So any direction we choose we are faced with capital expenditures, rewriting all of the firewall rules, and retraining staff to read, write, and debug a new rule format. Combine this with the fact that training in 'pf' is necessary anyway (for management of OpenBSD host-based ACLs on existing infrastructure), and the 'pf' solution starts to become more attractive. None of this addresses the personal drawback of the 'pf' approach. If a PIX firewall blows up, management has Cisco as a scapegoat. Everybody says "bad Cisco", the company gets a discounted price on our next few big router purchases, the customers understand, and I keep my job for a little longer.
Re: OpenBSD PF in the Enterprise?
On Tue, 21 Sep 2004 10:54:50 -0600, [EMAIL PROTECTED] wrote: > Russell Fulton writes: > > On Tue, 2004-09-21 at 09:37, Nick Buraglio wrote: > >> They also said that "in large enterprise there > >> is a need to have a responsible party" for software and hardware. > > > > My stock answer to this argument is "And when did you last get any > > satisfactory redress from a software company whose products were > > defective or simply did not work?" followed by "How often have you had > > problems?". > > You know what the problem is, the executive staff want some one, anyone, > to hang the blame on, they aren't expecting anything ACTUALLY be done > about problems, they just want a target for the lawsuits, should the > need arise. I'm sort of in the same boat. I have a strong case for replacing multiple PIX failover pairs with OpenBSD on Dell, but I'm holding back from making that recommendation solely because of the rational fear that, lacking "someone to hang the blame on", when problems do come up, the only available target is... *me* KKadow
Re: Synproxy broken on latest snapshots?
Patch fixed it. Now another question, before patch synproxy worked, kinda, with a bridge. It would take 3-5 seconds to open the session, but it was blocking a synflood with 20% CPU used by interrupts (P3 1Ghz). It only "worked" with a bridge though. States were limited to 250,000 and it would use all of them given enough time. Right now with the same flood interrupts are eating 75-80% CPU and my state table is much smaller, 20-25,000. My early numbers are from a snapshot few weeks ago, newest figures are from -current + the patch from a few hours ago. I know synproxy was not working properly before, but why the huge increase in interrupt processing? Its about 30,000 packets/second flood, originating locally on another router interface. Another thing, I see some TCP connections being handed off to the server behind the bridge. Since its a spoofed syn-flood that I started none of the "client" IPs should respond right? Is it just poorly configured devices on those IPs? tcp0 0 216.15.185.10:8017.185.163.20:1004 ESTABLISHED tcp0 0 216.15.185.10:8063.162.105.196:1513 ESTABLISHED tcp0 0 216.15.185.10:80129.118.156.149:2447ESTABLISHED Oddly none of those IPs are shown with a pfctl -ss Thanks, Kevin On Thu, 1 Jul 2004 20:39:28 +0200, Daniel Hartmeier <[EMAIL PROTECTED]> wrote: > > On Wed, Jun 30, 2004 at 04:47:00PM -0500, Kevin wrote: > > > Unable to get synproxy working using snapshot dated June 28, > > previously was using one from about 2 weeks ago which also did not > > work. > > Can you try the patch in > > http://www.benzedrine.cx/pf/msg04725.html > > and tell me whether it affects/fixes the problem? I've never gotten any > feedback on that. > > Daniel >
Synproxy broken on latest snapshots?
Unable to get synproxy working using snapshot dated June 28, previously was using one from about 2 weeks ago which also did not work. TCP handshake is never completed, state remains PROXY:DST until the client times out. Modulate or keep state works as normal. Am I missing something? I've used synproxy before and it worked quite well, just can't figure out what I am doing wrong, configuration is kept very simple for testing. Included below is the pf.conf, pfctl -sa and ifconfig -a output. Thanks, Kevin # cat /etc/pf.conf.syn pass in log quick on em0 proto tcp from any to any port 80 \ flags S/SA synproxy state pass in log quick on em0 from any to any \ flags S/SA keep state # pfctl -sa FILTER RULES: pass in log quick on em0 proto tcp from any to any port = www flags S/SA synproxy state pass in log quick on em0 all flags S/SA keep state No queue in use STATES: self tcp 216.15.185.220:80 <- 216.15.129.88:31388 PROXY:DST INFO: Status: Enabled for 0 days 00:07:56 Debug: Urgent Hostid: 0xcdd898be State Table Total Rate current entries1 searches11502.4/s inserts40.0/s removals 30.0/s Counters match 10802.3/s bad-offset 00.0/s fragment 00.0/s short 00.0/s normalize 00.0/s memory 00.0/s bad-timestamp 00.0/s TIMEOUTS: tcp.first 120s tcp.opening 30s tcp.established 86400s tcp.closing 900s tcp.finwait 45s tcp.closed 90s tcp.tsdiff 30s udp.first60s udp.single 30s udp.multiple 60s icmp.first 20s icmp.error 10s other.first 60s other.single 30s other.multiple 60s frag 30s interval 10 states adaptive.start0 states adaptive.end 0s src.track 0s LIMITS: states hard limit 1 src-nodes hard limit 1 frags hard limit 5000 OS FINGERPRINTS: 345 fingerprints loaded # ifconfig -a lo0: flags=8049 mtu 33224 inet 127.0.0.1 netmask 0xff00 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x7 em0: flags=8843 mtu 1500 address: 00:07:e9:0c:ec:e9 media: Ethernet autoselect (100baseTX full-duplex) status: active inet 216.15.185.220 netmask 0xff00 broadcast 216.15.185.255 inet6 fe80::207:e9ff:fe0c:ece9%em0 prefixlen 64 scopeid 0x1 fxp0: flags=8802 mtu 1500 address: 00:02:b3:92:48:bc media: Ethernet autoselect (none) status: no carrier fxp1: flags=8802 mtu 1500 address: 00:02:b3:3a:7b:37 media: Ethernet autoselect (none) status: no carrier pflog0: flags=0<> mtu 33224 pfsync0: flags=0<> mtu 2020 enc0: flags=0<> mtu 1536
Re: How to put more IPs in tables in PF?
> I wonder if anyone can help? I need to put 1,500,000 IP entries into a > table. My box is a P3-450 CPU, 1.5G of RAM, 6G IDE HD, 2NIC, Openbsd > 3.4 with custom kernel running a bridge with PF. So far works great > except when I tried to load a large list of IPs into a PF table. > > So far I have managed to load 800,000 IPs into a table when I set > nkmempages to 32768. 49152 & 65536 fails to boot with: > Outblaze Ltd. www.outblaze.com OK, so like many people reading this message I said, "WTF?!" out loud when I read this post this morning. Then as I scanned through the post, I remembered a "courtesy note" (my emphasis, not theirs) I had just received from Outblaze.com earlier this morning after contacted their postmaster desk (which I have never done). (This posting and the note I received earlier are completely coincidental timing, I'm sure). I actually got a couple of these messages from outblaze.com this morning, and believe me, *none* of my machines have ever [1] Delivered a spam to us [2] Triggered antispam filters of these fellows as they state list in the email I received (quoted below verbatim). Perhaps I was previously blocked and they're "retesting" me. Uh-huh. Personally, I think they're nuts for a variety of reasons. But more importantly, I wanted to bring full disclosure to this posting. Namely, if I know for an absolute, certain, indubitable fact that none of my machines have met their 'requirements', why on Earth am I being contacted by them? Perhaps it's completely innocuous; perhaps not. Now that I'm thinking about it, how many innocent people/servers are being blacklisted by this technique? And more importantly, wouldn't this technique be an outstanding way to solve the spam problem if MSN, Yahoo, Earthlink, and AOL did it, too?! YAY! I think I'm going to start firing up a bunch of boxes to do this, too! You guys wouldn't mind getting a few emails from me would ya?! Kevin Here's the message I received from them in its entirety, for those that are interested Hello Thank you for contacting the Outblaze postmaster desk. The obsl.outblaze.com machine is a Outblaze Security resource that is used as a tool to assist us in determining if machines being used to send us mail may be abused from outside sources, allowing them to be used to spam our customers and role accounts. We fully understand your concerns surrounding the probing of your machine. This issue has been raised internally and we hope this email helps you better understand our process. The intention of this process is truly not meant to be a big brother system, but we understand that some may view it as such. Our ultimate goal, however, is to protect our network and our customers. Given that we are an ISP with over 30 million users, we have to adopt this strategy. To that end, Outblaze has begin the reactive testing of IP addresses which connect to its inbound SMTP gateways. If your machine connects to ours to send email, we perform SMTP relay and open proxy server tests upon the connecting IP address to ensure that the machine at that IP address cannot be abused for malicious purposes. Your mail server is most likely being tested because your IP [1] Delivered a spam to us [2] Triggered antispam filters (such as sent us a significant number of emails with hotmail, yahoo or other freemail domains in the envelope sender, but not from a hotmail / yahoo IP) [3] We were previously blocking you, and we are retesting your host. If your host is now seen to be closed to relaying, it will be delisted from our blocklist. If your server is found to be an open relay or proxy it will be locally blocked by us. In such a case, please secure your server using the documentation at http://www.mail-abuse.org/tsi/ar-fix.html (open relays) and http://www.cyberabuse.org (for open proxies). Alternatively, you can ask your software manufacturer / on mailing lists and usenet newsgroups discussing your mail / proxy server), and then contact us at [EMAIL PROTECTED] once your relay or proxy is secured. This message is a test of your mail server to determine if it will perform relaying or proxying (re-sending) of e-mail messages for unauthorized outside parties. This capability, if enabled in your server, is widely considered to be a serious flaw in server security. For additional information about this test message, please contact [EMAIL PROTECTED] Please note also that if you are reading this message, then the implication is that your mail server has PASSED this one particular relaying test. However other types of relaying tests may perhaps still indicate mail relaying vulnerabilities in your mail server. If your IP is not running an open mail relay or proxy, we sincerely apologize for the inconvenience caused. Your IP will, in such a case, be whitel
Re: Multi-Users using AuthPF / Anchors
Hi Ed, Just curious if you have your directory structure created properly for each of the respective authpf.rules files. Along with your pf.conf and authpf.rules files, you ought to consider posting your authpf directory structure as well. Best, Kevin - Original Message - From: "Ed Powers" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, July 04, 2003 12:58 PM Subject: Multi-Users using AuthPF / Anchors > Originally Posted to [EMAIL PROTECTED] - Apologies for the double post. > -- > > Greets. > > I'm having an issue with authpf where I can only have one user(_id) connected > at the same time. That is, the authpf.rules file gets loaded and works > properly with the anchors I have set in place in pf.conf, but only if the same > user id logs in. When another id logs in it will stop the traffic flow of the > first. And, when the first id severs the SSH connection to the fw, that will > break the data flow for the second. > > More specifically: > > I use authpf to control access to/from my wireless connections and daughters > computer to the internet. > >+-+ > le0| |hme1 > Net --+OBSD 3.3 +-- Wireless >| | >+++ > |hme0 > | > Inside > > There are three different user id's (something like): > > userA > userB > kidpc > > And two rulesets: > > Default ruleset is just to allow traffic flow in on the hme1 interface and > allow for wireless machines used by userA and userB get to Net or Inside. > > kidpc ruleset allows for traffic into hme0 for access to Net (subject to other > global rules set on le0). > > If userA authenticates (w/ password protected keys) all is well. If userA > authenticates again - on another machine - everything still continues to work > on both authenticated machines. > > Now, if userB authenticates all appears ok (to userB) but connections for userA > die. And, if the SSH connection for one (or both) of the userA machines is > broken, then userB's connections come to a halt. > > The same occurs when authenticating with kidpc account. > > When watching states with pfctl -ss I see that all of userA's states (except > the ssh connection that is used for the authentication itself) are cleared > when userB authenticates. > > Setup: > Sparc 5 > 3.3 Stable (Built with -mcpu=v8) > > This configuration (that is, with multiple users) worked perfectly on 3.2 on > the same hardware using the "tail" option for authpf.rules placement. > > Thanks for any insight folks. > > Ed Powers > -- > ___ > Get your free Verizonmail at www.verizonmail.com > >
authpf head|tail rule placement
Hi all, Using OBSD3.3, I'm trying to add a couple of rules for a user using the authpf mechanism. The rules need to go atop my normal ruleset (as defined in my pf.conf), and I don't see how to achieve this documented anywhere. Put another way: the default placement for rules added via authpf is to place that found in authpf.rules at the tail of the file; I need these rules at the head for this particular user so it will take precedence over the default rules everyone else in the network is subject to. FWIW, in the 3.2 docs it was done using [head|tail], though I couldn't find great documentation on that either--my efforts at apply 3.2 syntax in 3.3 have failed. Presumably this feature still exists, and I'm not seeing how to specify rule placement Thanks, Kevin
synproxy performance
I am attempting to protect a web server from syn floods with synproxy.
The OpenBSD box has three NICs installed with fxp0 and fxp1 making up a
bridge and dc0 for SSH access. Hardware is P3 1Ghz with 1GB RAM.
The problem is once PF proxies 15,000 sessions almost all traffic
through the bridge dies. The server behind it is no longer accessable
and neither is the OpenBSD box. Ping shows 90-95% packet loss depending
on how long I leave it running. I set nmbclusters to 8192 per
http://openbsd.org/faq/faq11.html#Network, but that didn't seem to help.
I've set adaptive timeouts to everything from
adaptive.start 5000, adaptive.end 22
to
adaptive.start 10, adaptive.end 110
With a corresponding state limit of course. With the latter I
managed to panic the box (I can post the trace and ps here if it will be
helpful). Tried setting optimization to agressive and modifying other
state timeouts to no avail.
CPU usage remains under 15% and memory usage is about 100MB so I don't
believe it is a hardware issue, but I can throw more at it if it will
help.
According to the router it connects to there is about 20-30k packets/s
being thrown at it. I found a post a few months ago by Henning showing
15k packets/s on a Duron 700 with 10% CPU usage, although that was prior
to synproxy, so Im doubtful that I've hit a ceeling with PF.
Anyone have any ideas? dmesg and pf.conf are below.
Thanks,
Kevin
dmesg:
OpenBSD 3.3-current (GENERIC) #45: Wed Jun 11 03:42:09 MDT 2003
[EMAIL PROTECTED]:/usr/src/sys/arch/i386/compile/GENERIC
cpu0: Intel Pentium III (Coppermine) ("GenuineIntel" 686-class) 1 GHz
cpu0:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SYS,MTRR,PGE,MCA,CMOV,PAT,PSE36
,SER,MMX,FXSR,SIMD real mem = 1073131520 (1047980K)
avail mem = 990044160 (966840K)
using 4278 buffers containing 5376 bytes (52500K) of memory
mainbus0 (root)
bios0 at mainbus0: AT/286+(00) BIOS, date 05/25/01, BIOS32 rev. 0 @
0xfda44 pcibios0 at bios0: rev. 2.1 @ 0xf/0x1
pcibios0: PCI IRQ Routing Table rev. 1.0 @ 0xf3080/192 (10 entries)
pcibios0: no compatible PCI ICU found: ICU vendor 0x product 0x
pcibios0: PCI bus #0 is the last bus
bios0: ROM list: 0xc/0x8000 0xc8000/0x5200 0xcd800/0x1800
0xcf000/0x1800 pci0 at mainbus0 bus 0: configuration mode 1 (no bios)
pchb0 at pci0 dev 0 function 0 "ServerWorks CNB20LE Host" rev 0x06
pchb1 at pci0 dev 0 function 1 "ServerWorks CNB20LE Host" rev 0x06
pci1 at pchb1 bus 1
dc0 at pci1 dev 2 function 0 "ADMtek AN983" rev 0x11: irq 3 address
00:03:6d:1a:0c:7e ukphy0 at dc0 phy 1: Generic IEEE 802.3u media
interface ukphy0: OUI 0x000895, model 0x0001, rev. 0
ahc1 at pci1 dev 4 function 0 "Adaptec AIC-7899 U160" rev 0x01: irq 11
ahc1: aic7899: Ultra160 Wide Channel A, SCSI Id=7, 32/255 SCBs
scsibus0 at ahc1: 16 targets
ahc2 at pci1 dev 4 function 1 "Adaptec AIC-7899 U160" rev 0x01: irq 9
ahc2: aic7899: Ultra160 Wide Channel B, SCSI Id=7, 32/255 SCBs
scsibus1 at ahc2: 16 targets
ahc2: target 0 synchronous at 80.0MHz DT, offset = 0x3f
ahc2: target 0 using tagged queuing
sd0 at scsibus1 targ 0 lun 0: SCSI3 0/direct
fixed sd0: 35003MB, 15110 cyl, 12 head, 395 sec, 512 bytes/sec, 71687340
sec total(ahc2:A:6:0): refuses WIDE negotiation. Using 8bit transfers
(ahc2:A:6:0): refuses synchronous negotiation. Using asynchronous
transfers uk0 at scsibus1 targ 6 lun 0:
SCSI2 3/processor fixed uk0: unknown device
vga1 at pci0 dev 4 function 0 "ATI Rage XL" rev 0x27
wsdisplay0 at vga1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
fxp0 at pci0 dev 7 function 0 "Intel 82557" rev 0x08: irq 10, address
00:03:47:9e:b1:e7 inphy0 at fxp0 phy 1: i82555 10/100 media interface,
rev. 4 fxp1 at pci0 dev 8 function 0 "Intel 82557" rev 0x08: irq 5,
address 00:03:47:9e:b1:e8 inphy1 at fxp1 phy 1: i82555 10/100 media
interface, rev. 4 pcib0 at pci0 dev 15 function 0 "ServerWorks ROSB4
SouthBridge" rev 0x51 pciide0 at pci0 dev 15 function 1 "ServerWorks
OSB4 IDE" rev 0x00: DMA atapiscsi0 at pciide0 channel 0 drive 0
scsibus2 at atapiscsi0: 2 targets
cd0 at scsibus2 targ 0 lun 0: SCSI0 5/cdrom
removable cd0(pciide0:0:0): using PIO mode 4, DMA mode 2
ohci0 at pci0 dev 15 function 2 "ServerWorks OSB4/CSB5 USB" rev 0x04:
irq 10, OHCI version 1.0, legacy support usb0 at ohci0: USB revision 1.0
uhub0 at usb0
uhub0: vendor 0x OHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub0: 2 ports with 2 removable, self powered
isa0 at pcib0
isadma0 at isa0
pckbc0 at isa0 port 0x60/5
pckbd0 at pckbc0 (kbd slot)
pckbc0: using irq 1 for kbd slot
wskbd0 at pckbd0: console keyboard, using wsdisplay0
pcppi0 at isa0 port 0x61
midi0 at pcppi0:
sysbeep0 at pcppi0
npx0 at isa0 port 0xf0/16: using exception 16
pccom0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
fdc0 at isa0 port 0x3f0/6 irq 6 drq 2
fd0 at fdc0 drive 0: 1.44MB
Re: synproxy problems with bridge
On Fri, 13 Jun 2003 09:06:50 +0200 Daniel Hartmeier <[EMAIL PROTECTED]> wrote: > The only workaround at this time is to assign IP addresses to the > interfaces of the bridge. This results in routing table entries on the > bridge machine, which allows the packets generated by pf to get sent > out. This is obviously only doable when you have separate networks > (two non-overlapping netblocks) on each interface of the bridge. > > pf operates on IP (not ethernet) level. It uses a function of the > existing TCP/IP stack (ip_output) to send out IP packets it generates. > This function then needs to decide which interface the destination IP > address is reachable through, and find the MAC address of the > destination IP address (or a gateway to it). It uses the routing table > (and arp cache) to do that, which is empty on a pure bridge (one > without IP addresses assigned to the interfaces). > > For some pf generated packets (like return-* or synproxy), the > destination is always either the source or destination of the packet > that was just filtered/received by pf, so we could theoretically try > to use the ethernet level information in the packet (which pf > currently ignores, operating purely on IP level). Other packets (like > route-to) may need a completely new destination, so the MAC address > may be entirely unknown. If a solution can be found which doesn't > require duplicating large parts of code (from ip_output into pf), that > would be welcome. But we don't have that yet. > > HTH, > Daniel Thanks for the explanation, that makes sense. And even more thanks for an extraordinary packet filter. I don't know what I would do without it. Kevin
Re: synproxy problems with bridge
On Fri, 13 Jun 2003 01:32:46 +0200 (CEST)
Dries Schellekens <[EMAIL PROTECTED]> wrote:
>
> return-{rst,icmp,icmp6) and synproxy don't work on a bridge.
>
> pb@ added a remark to pf.conf(5) and bridge(4) about this yesterday.
>
> NOTES of -current bridge(4) state
> It is unsupported to use filter rules which would generate
> packets. This applies to rules with return, return-rst,
> return-icmp, return-icmp6 or synproxy defined.
Thanks for the quick reply. Do you know if support for synproxy on a
bridge is planned?
Kevin
>
>
> Cheers,
>
> Dries
> --
> Dries Schellekens
> email: [EMAIL PROTECTED]
>
>
synproxy problems with bridge
Just installed the June 11 snapshot to do some testing with synproxy.
The server has three NICs installed with fxp0 and fxp1 making up the
bridge and dc0 for remote access.
Traffic through the bridge works fine, unless I enable synproxy. Both
keep state and moduleate state work as expected, the server is reachable
via HTTP. But if synproxy is enabled the TCP handshake never finishes
and the connection is eventually dropped.
tcp 197.168.131.10:80 <- 216.15.129.172:8524 PROXY:DST
I've tried adding keep state to each of the bridge interfaces (except
with incomming on fxp0) but that didn't seem to make any difference.
Using synproxy to the dc0 IP works perfectly fine, only the bridge has
problems.
Am I missing something? I am using the synproxy config from the pf.conf
man page.
Relevant configs:
# cat /etc/hostname.fxp0
up
# cat /etc/hostname.fxp1
up
# cat /etc/bridgename.bridge0
add fxp0
add fxp1
up
# cat /etc/pf.conf
# pf.conf
#-#
#-- variables #
#
ext_if="dc0"
int_br="fxp1"
ext_br="fxp0"
#-#
#-- Settings -#
#
# loginterface collects stats for pfstats
set loginterface $ext_br
# TCP timout settings
set timeout tcp.first 120
set timeout tcp.established 86400
set timeout { adaptive.start 6000, adaptive.end 12000 }
set limit states 1
#-#
#-- Normalization #
#
scrub in all
scrub out all
#-#
#-- Anti-spoofing #
#
#antispoof for $ext_if inet
antispoof for lo0
#-#
#-- Default Block #
#
block in log on $ext_if from any to any label Dflt_Blk
#-#
#-- Quick Blocks -#
#
# block and log outgoing packets that don't have my address as source,
they are# either spoofed or something is misconfigured (NAT disabled,
for instance),# we want to be nice and don't send out garbage.
#
block out log quick on $ext_if inet from !$ext_if to any
# block NMAP OS fingerprint
# http://openbsd.org/faq/faq6.html#PF
#
block in log quick on $ext_if inet proto tcp from any to any flags
FUP/FUP label NMAP_Block_1 block in log quick on $ext_if inet proto tcp
from any to any flags SF/SFRA label NMAP_Block_2 block in log quick on
$ext_if inet proto tcp from any to any flags /SFRA label NMAP_Block_3
#-#
#-- Loopback -#
#
pass in quick on lo0 all
pass out quick on lo0 all
#-#
#-- Bridge ---#
#
pass out on $ext_br all
pass out on $int_br all
pass in on $int_br all
#pass in on $ext_br keep state
#pass in quick on $ext_br inet proto tcp from any to any port 80 flags
S/SA \synproxy state label SynProxy_HTTP
pass in log proto tcp from any to any port www flags S/SA synproxy state
#pass in log proto tcp from any to any port www flags S/SA modulate
state
#-#
#-- Uplink ---#
#
pass out on $ext_if keep state
Re: pcanywhere+NAT
> Here's what you're looking for: > > rdr on $ext proto tcp from $allow to public_ip port 5631 -> your_nat_ip port > 5631 > rdr on $ext proto ucp from $allow to public_ip port 5632 -> your_nat_ip port > 5632 > rdr on $ext proto tcp from $allow to public_ip port 65301 -> your_nat_ip > port 65301 > pass in quick on $ext proto tcp from $allow to any port = 5631 flags S/SAFR \ > modulate state > pass in quick on $ext proto udp from $allow to any port = 5632 keep state pass in quick on $ext proto tcp from $allow to any port = 65301 flags S/SAFR \ > modulate state damned line wraps I think you get the point though. :-)
Re: pcanywhere+NAT
Here's what you're looking for: rdr on $ext proto tcp from $allow to public_ip port 5631 -> your_nat_ip port 5631 rdr on $ext proto ucp from $allow to public_ip port 5632 -> your_nat_ip port 5632 rdr on $ext proto tcp from $allow to public_ip port 65301 -> your_nat_ip port 65301 pass in quick on $ext proto tcp from $allow to any port = 5631 flags S/SAFR \ modulate state pass in quick on $ext proto udp from $allow to any port = 5632 keep state pass in quick on $ext proto tcp from $allow to any port = 65301 flags S/SAFR \ modulate state Good luck, Kevin - Original Message - From: "Bryan Irvine" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, January 13, 2003 02:38 PM Subject: pcanywhere+NAT > IS there a way to do this? I'd rather use VNC but a vendor is insisting > on pcanywhere. > > I'm wondering if there is some rdr rules I can use. > > OBSD 3.2 > > -- > Bryan Irvine <[EMAIL PROTECTED]> >
