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

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.

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 .. todd@fries.net
 _____________________________________________

|                                             \  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 <cgbullock@gmail.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 shou...
[ message continues ]

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.

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.

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.

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.

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.

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?

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?