We have been using OpenBSD my entire IT career, 5 1/2 years, I like the way its easy to roll out, configure and the cost the most. I would like an honest opinion of the group. We have customers that maintain their own firewalls and VPNs and it appears to us that that those sites seem to transmit data quicker than the sites that we maintain with OpenBSD firewalls and VPNs, assuming identical bandwidth. We have an OpenBSD VPN/firewall at our main site, so realistically, all of our data does transpose OpenBSD before it ultimately hits our network. My question is should I consider a non OpenBSD solutions, ie Cisco devs or should I attempt to tweak my existing boxes? Regards, Chris
Have you try openbsd 4.2 ? PF have been really improved in this release. -- Julien Cabillot Technicien Unix SDV Plurimedia
Besides trying 4.2 (you should definitely do that), two other things might be considered: 1. VPN is computationally heavy -- is your hardware fast enough? 2. Try playing with queueing in PF to handle some types of traffic faster than others. AFAIK, it is normal to find this kind of configuration in commercial, black-box solutions, disguised as buzzy slogans like "Built-in QoS Super-Routing" :-) Just my two cents. Martin
pf(4) has nothing to do with isakmpd(8), except as it relates to recent addition of routing tags. - PIX/ASA is going to get you a default packet "ASA" forwarding based on interface weights - PIX/ASA is going to guarantee easily setup and functional Hybrid-XAUTH VPN Road-warrior clients - PIX has functional object-groups/group-object inheritance - PIX/ASA has proprietary serial console fail-over (which is marginally faster than waiting for CARP) - PIX/ASA has some magical black-box inline transparent protocol "fixups" - PIX has a 4 hour SmartNet support contract option - PIX/ASA has a SNMP MIB tree (Which we are working to catch up on) I don't know about ASA, but the 5xx PIX doesn't support IPv6 Otherwise they're both software-based stateful IP packet forwarding engines running on i386 with NAT and IPSec and 802.1q support. OpenBSD will always scale better because you can run it on the harwdare platform of your choice.
People who have met those when trying to send mail will tell you that, at least for smtp, that quoted word at the end of the above sentence has a spelling error. s/i/u/ R/ From the land "down under": Australia. Do we look <umop apisdn> from up over?
Are you sure PIX 515 and above does not support IPv6. By that do you mean IPv6 routing, if that is the case, yes. But PIX 515E and ASA does support IPv6 fine when you use 7.X and above version of image. In addition to your 4th point, PIX and ASA support failover using LAN, only PIX supports serial based failover. To the OP: We use ASA and OpenBSD in our production environment and we spent close to $10,000 buying twin ASAs (using GigE) for failover, but only $2000 to buy two dell boxes to put OpenBSD (using GigE) on them and use them as failover i.e. pf + pfsync + sasyncd and its being fine for past 11 months. Where do you see OpenBSD lagging behind, if it is a transfer rate you can tweak tcp settings using sysctl, you can upgrade to 4.2 as the other post indicated. And are you willing to spend money to buy expensive gear that is the question?
Hello, Is there any documentation about those tweaks for tcp performance? and what about irq thingy?
hi! i cannot resist to give a few comments on the PIX/ASA... but first you should have a look at http://www.openbsd.org/lyrics.html#35 about the Monopoly of Cizzz-coeee. this concept of interface levels is something that is causing headaches to generations of PIX admins... there are certain limitations between interfaces of different levels then the PIX doesn't even support VLANs, you have to use a physical interface per OpenBSD's isakmpd does not support XAUTH yet but the IPsec configuration on PIX is neither easy nor functional; this concept of using access lists for phase 2 policies (flows) and all the dependencies of different types of cli rules for IPsec is just really it is not functional, it is an attempt to make the access lists more useable. OpenBSD's tables, macros, etc. provide a much better yeah, and you have to run both systems in the same rack impossible to this should only matter in the NAT case and is provided by our pf proxies and relayd(8), but they're not magical. we're working on snmpd(8) will support a few more MIBs, but it is still the goal to like the lucent boxes and many other systems. and even if they support IPv6, they do it in a very basic way sometimes not even and more - PIX/ASA require additional licenses for more users/cryptos/keystrokes/... - Newer releases of ASA (8+) are based on Linux 2.6... it turned into just another Linux UTM box.
Or like on the ASA where IPv6 has nice memory leaks that cause the box to freeze once a week and Cisco just does not care even though a lot of money is paid for their support.
Yeah, they have a magical smtp "f**-up" that is famous for breaking things. Have a look at http://www.postfix.org/postconf.5.html and search the page for pix. Not too transparent either. Please don't reply to the sender address of this mail. There is a reply-to but the list is fine, I read every message. Thanx, Rod/ Me...a skeptic? I trust you have proof.
On Mon, Nov 5, 2007 at 12:26 PM, Brian A Seklecki (Mobile) Assuming this is really a problem, could CARP use interface link state to speed up fail-over? E.g., if the common setup is two routers with a direct Ethernet cable for pfsync and the common failure scenario is power failure (or at least something that brings down the pfsync device interface), when one router fails, the other could detect the link state change and then try to more aggressively contact the master before timing out and taking over.
Some say that isakmpd is resource intensive. What is the recommended hardware for a 5mb full duplex optical Internet connection that is doing nothing but VPN. Regards, Chris
isakmpd does not do the crypto processing of the actual IPSec tunnels, it only does the ike negotiations. Presuming you want to use aes-128, `openssl speed aes' shows that a 1ghz system that is running 'vi' to type this message is capable of (at the lowest end) 27mbyte per second. I think you should do your own tests but it looks like you'd have to stoop pretty low to not be able to handle 5mbit. Thanks, -- Todd Fries .. firstname.lastname@example.org _____________________________________________ | \ 1.636.410.0632 (voice) | Free Daemon Consulting, LLC \ 1.405.227.9094 (voice) | http://FreeDaemonConsulting.com \ 1.866.792.3418 (FAX) | "..in support of free software solutions." \ 250797 (FWD) | \ \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ 37E7 D3EB 74D0 8D66 A68D B866 0326 204E 3F42 004A http://todd.fries.net/pgp.txt Penned by Chris Bullock on 20071105 19:14.17, we have: | Some say that isakmpd is resource intensive. What is the recommended | hardware for a 5mb full duplex optical Internet connection that is doing | nothing but VPN. | Regards, | Chris | | On 11/4/07, Chris Bullock <email@example.com> wrote: | > | > We have been using OpenBSD my entire IT career, 5 1/2 years, I like the | > way its easy to roll out, configure and the cost the most. | > | > I would like an honest opinion of the group. We have customers that | > maintain their own firewalls and VPNs and it appears to us that that those | > sites seem to transmit data quicker than the sites that we maintain with | > OpenBSD firewalls and VPNs, assuming identical bandwidth. We have an | > OpenBSD VPN/firewall at our main site, so realistically, all of our data | > does transpose OpenBSD before it ultimately hits our network. | > | > My question is should I consider a non OpenBSD solutions, ...
do some conclusive transfer tests please or explain what you mean when you say "and it appears". FWIW, I've benchmarked PIX stateful failover using their fancy serial cable/x-over combo at roughly 750ms of "dead time" in the event of a failover.
|Alexey Dobriyan||Re: [22.214.171.124 review 09/84] Fix rfkill IRQ flags.|
|Michael Moore||Re: underage models, pre teen models, lolita porn, young preteens, little lolitas|
|Alex Riesen||Re: [PATCH 4/7] lib: Introduce strnstr()|
|Thomas Gleixner||[ANNOUNCE] 2.6.31-rc6-rt2|
|Mathieu Desnoyers||Re: Linux 2.6.25-rc2|
|Blaisorblade||git-unpack-objects < pack file in repository doesn't work!|
|Matthieu Moy||Re: Cloning empty repositories, was Re: What is the idea for bare repositories?|
|Linus Torvalds||Re: Untracked working tree files|
|Peter Karlsson||Re: CRLF problems with Git on Win32|
|Johannes Schindelin||Re: [PATCH 4/4] git-rebase -i: New option to support rebase with merges|
|Alan Menegotto||Re: Linux networking implementation and packet capture|
|Andrew Morton||Re: [PATCH] PHYLIB: IRQ event workqueue handling fixes|
|Timo Teräs||ip xfrm policy semantics|
|Jarek Poplawski||Re: [PATCH]: Fix queueing return values...|
|David Miller||Re: [PATCH 1/2] netdev: bfin_mac: enable bfin_mac net dev driver for BF51x|
|Linux Kernel Mailing List||Blackfin: don't give CPU its own line in traps output|
|Linux Kernel Mailing List||No need to do lock_super() for exclusion in generic_shutdown_super()|
|Linux Kernel Mailing List||x86, msr: Export the register-setting MSR functions via /dev/*/msr|
|Linux Kernel Mailing List||MIPS: SMTC: Fix lockup in smtc_distribute_timer|
|Linux Kernel Mailing List||powerpc: gamecube/wii: usbgecko bootwrapper console support|
|Aaron Mason||Re: Defending OpenBSD Performance|
|Henning Brauer||Re: Defending OpenBSD Performance|
|Henning Brauer||Re: Defending OpenBSD Performance|
|Christiano Farina Haesbaert||Re: Defending OpenBSD Performance|
|Nick Holland||Re: 1 out of 3 hunks failed--saving rejects to kerberosV/src/lib/krb5/crypto.c.rej|