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

[ message continues ]

Have you try openbsd 4.2 ? PF have been really improved in this release.



-- 
Julien Cabillot
Technicien Unix
SDV Plurimedia

[ message continues ]

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

[ message continues ]

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.


[ message continues ]

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?

[ message continues ]

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?

[ message continues ]

Hello,

Is there any documentation about those tweaks for tcp performance? and
what about irq thingy?


[ message continues ]

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.


[ message continues ]

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.


[ message continues ]

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.

[ message continues ]

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.

[ message continues ]

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


[ message continues ]

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 should I consider a non OpenBSD solutions, ...
[ message continues ]

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.

[ message continues ]