OpenBSD isakmpd and pf vs Cisco PIX or ASA

[Chris Bullock]

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

[Julien Cabillot]

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

On Nov 5, 2007 1:09 AM, Chris Bullock <cgbullock@...> 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, ie Cisco devs or
> should I attempt to tweak my existing boxes?
> Regards,
> Chris
>
>

--
Julien Cabillot
Technicien Unix
SDV Plurimedia

[Martin Toft-2]

On Mon, Nov 05, 2007 at 01:29:05AM +0100, Cabillot Julien wrote:

> Have you try openbsd 4.2 ? PF have been really improved in this
> release.
>
> On Nov 5, 2007 1:09 AM, Chris Bullock <cgbullock@...> 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, ie Cisco
> > devs or should I attempt to tweak my existing boxes?
> > Regards,
> > Chris

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

[Brian A. Seklecki (Mobile)]

On Mon, 2007-11-05 at 07:23 +0100, Martin Toft wrote:
> On Mon, Nov 05, 2007 at 01:29:05AM +0100, Cabillot Julien wrote:
> > Have you try openbsd 4.2 ? PF have been really improved in this
> > release.

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.

~BAS

> 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

[Rod Whitworth-3]

On Mon, 05 Nov 2007 14:26:48 -0500, Brian A Seklecki (Mobile) wrote:

>- PIX/ASA has some magical black-box inline transparent protocol
>"fixups"

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?

[Chris Bullock]

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@...> 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, ie Cisco devs or
> should I attempt to tweak my existing boxes?
> Regards,
> Chris

[Todd T. Fries-6]

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@...

 _____________________________________________
|                                             \  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@...> 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, ie Cisco devs or
| > should I attempt to tweak my existing boxes?
| > Regards,
| > Chris

[Karsten McMinn]

On Nov 4, 2007 4:09 PM, Chris Bullock <cgbullock@...> wrote:
> ...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. <snip>

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.

[Prabhu Gurumurthy]

Brian A Seklecki (Mobile) wrote:

> On Mon, 2007-11-05 at 07:23 +0100, Martin Toft wrote:
>> On Mon, Nov 05, 2007 at 01:29:05AM +0100, Cabillot Julien wrote:
>>> Have you try openbsd 4.2 ? PF have been really improved in this
>>> release.
>
> 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.
>
> ~BAS
>
>> 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
>
>

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?

[Reyk Floeter-2]

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.

On Mon, Nov 05, 2007 at 02:26:48PM -0500, Brian A Seklecki (Mobile) wrote:
> - PIX/ASA is going to get you a default packet "ASA" forwarding based on
> interface weights

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
LAN.

> - PIX/ASA is going to guarantee easily setup and functional Hybrid-XAUTH
> VPN Road-warrior clients

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
bad.

> - PIX has functional object-groups/group-object inheritance

it is not functional, it is an attempt to make the access lists more
useable. OpenBSD's tables, macros, etc. provide a much better
interface.

> - PIX/ASA has proprietary serial console fail-over (which is marginally
> faster than waiting for CARP)

yeah, and you have to run both systems in the same rack impossible to
put the systems in physically different locations.

> - PIX/ASA has some magical black-box inline transparent protocol
> "fixups"

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
supporting more protocols in this case.

> - PIX has a 4 hour SmartNet support contract option

there are OpenBSD-based appliances with suitable support contracts.

> - PIX/ASA has a SNMP MIB tree (Which we are working to catch up on)
>

snmpd(8) will support a few more MIBs, but it is still the goal to
keep it small.

> I don't know about ASA, but the 5xx PIX doesn't support IPv6
>

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
statefully.

>
> 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.
>

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.

reyk

> ~BAS
>
> > 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

[Claudio Jeker]

On Thu, Apr 10, 2008 at 12:27:32PM +0200, Reyk Floeter wrote:
> > I don't know about ASA, but the 5xx PIX doesn't support IPv6
> >
>
> 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
> statefully.
>

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.

--
:wq Claudio

[Rod Whitworth-3]

On Thu, 10 Apr 2008 12:27:32 +0200, Reyk Floeter wrote:

>> - PIX/ASA has some magical black-box inline transparent protocol
>> "fixups"
>

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.

[Matthew Dempsky-3]

On Mon, Nov 5, 2007 at 12:26 PM, Brian A Seklecki (Mobile)
<bseklecki@...> wrote:
>  - PIX/ASA has proprietary serial console fail-over (which is marginally
>  faster than waiting for CARP)

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.

[Stuart Henderson]

On 2008-04-10, Matthew Dempsky <matthew@...> wrote:
> 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.

Problem is, a carp interface is not interested in the state of the
syncdev, it is interested in the state of its own carpdev (since
multiple carp interfaces on a machine are independent). And carpdev
usually faces a switch, so it stays up.

[Matthew Dempsky-3]

On Thu, Apr 10, 2008 at 2:33 PM, Stuart Henderson <stu@...> wrote:
>  Problem is, a carp interface is not interested in the state of the
>  syncdev, it is interested in the state of its own carpdev (since
>  multiple carp interfaces on a machine are independent). And carpdev
>  usually faces a switch, so it stays up.

I didn't mean it would monitor the state of its own carpdev, but that
you'd be able to set an extra watchdev (or whatever) that it would
watch.

[Henning Brauer]

* Matthew Dempsky <matthew@...> [2008-04-11 02:37]:
> On Thu, Apr 10, 2008 at 2:33 PM, Stuart Henderson <stu@...> wrote:
> >  Problem is, a carp interface is not interested in the state of the
> >  syncdev, it is interested in the state of its own carpdev (since
> >  multiple carp interfaces on a machine are independent). And carpdev
> >  usually faces a switch, so it stays up.
>
> I didn't mean it would monitor the state of its own carpdev, but that
> you'd be able to set an extra watchdev (or whatever) that it would
> watch.

for what?
aside from the fact that carp failover IS blazingly fast already (i do
switchovers during business hours sometimes, and nobody ever noticed
anything), let's look at the typical fwA + fwB secanrio, 3
interfaces: ext, int, and syndev. now the carps on ext and int have
"watchdev" syncdev.
case A: fwA is master, fwB is slave, fwA fails, syncdev going down
tells the carp interface which are backup to become master?
hoe about case B:
fwA is master, fwB is slave, I visit you and cut the syndev cable,
because I like fun.
fwB's slave carp interfaces notice the "watchdev" going down and
go to master. great, now we have two masters. as I have had such a
split brain config in the fast (due to a switch misconfiguration) I can
tell you - that is not fun. really.
But, you'll say, after a short while fwB will switch to BACKUP again,
since it sees fwAs announcements. Yeah, right. But now the switch is
confuzzled on which port the carp mac address actually sits and will,
with a >75% chance, CONTINUE to send traffic to fwB, since that's where
it learned the mac address last. carp interfaces send out gratious arp
when they become master. There is no "i don't have this mac anymore"
type message. Doesn't exist. You lose.

now to the more interesting cases...
case C:
fwA carp: ext1: master, int1: master, ext2: slave,  int2: slave
fwB carp: ext1: slave,  int1: slave,  ext2: master, int2: master
now teh syncdev goes dowm.
oooommmgggg....
it gets more complicated :)

So, what do you gain?
-marginal faster failover, maybe. I have my doubts you actually gain
 much. Just one point, the time the switch needs to "move" the mac entry
 to the other  port is greater than 0 too.

Downsides:
-more code, potentially more bugs
-more complex, more bugs
-really really really bad behaviour when the sync connection is cut
-weird behaviour with multiple carp groups
(and probably more if I spend more time thinking about it)

not worth it. q. e. d.
:)

--
Henning Brauer, hb@..., henning@...
BS Web Services, http://bsws.de
Full-Service ISP - Secure Hosting, Mail and DNS Services
Dedicated Servers, Rootservers, Application Hosting - Hamburg & Amsterdam

[José Carlos Cruz Costa]

Hello,

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

On Thu, Nov 8, 2007 at 2:34 AM, Prabhu Gurumurthy <pgurumu@...> wrote:

> Brian A Seklecki (Mobile) wrote:
>
>
> > On Mon, 2007-11-05 at 07:23 +0100, Martin Toft wrote:
> >
> > > On Mon, Nov 05, 2007 at 01:29:05AM +0100, Cabillot Julien wrote:
> > >
> > > > Have you try openbsd 4.2 ? PF have been really improved in this
> > > > release.
> > > >
> > >
> >
> > 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.
> >
> > ~BAS
> >
> >
> > > 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
> > >
> >
> >
> >
>
>  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?

[Matthew Dempsky-3]

On Fri, Apr 11, 2008 at 4:12 AM, Henning Brauer <lists-openbsd@...> wrote:
>  fwB's slave carp interfaces notice the "watchdev" going down and
>  go to master. great, now we have two masters. as I have had such a
>  split brain config in the fast (due to a switch misconfiguration) I can
>  tell you - that is not fun. really.

I didn't suggest that when the "watchdev" interface goes down that the
carp interface would immediately switch to MASTER, but that it could
lower the timeout in waiting for an advertisement from the current
master.

>  not worth it. q. e. d.
>  :)

Probably not.  I've never had problems with carp's fallover time and
I've never used a Cisco firewall so I don't really know how it
actually compares.  I just wanted to suggest a maybe-solution assuming
the supposed slow failover time was a problem.

[Henning Brauer]

* Matthew Dempsky <matthew@...> [2008-04-11 18:14]:

> On Fri, Apr 11, 2008 at 4:12 AM, Henning Brauer <lists-openbsd@...> wrote:
> >  fwB's slave carp interfaces notice the "watchdev" going down and
> >  go to master. great, now we have two masters. as I have had such a
> >  split brain config in the fast (due to a switch misconfiguration) I can
> >  tell you - that is not fun. really.
>
> I didn't suggest that when the "watchdev" interface goes down that the
> carp interface would immediately switch to MASTER, but that it could
> lower the timeout in waiting for an advertisement from the current
> master.

lower to what? less than the partner's advskew? then it IS master.
slightly more than partner's advskew? well, yo don't know partner's
adbskew, and you don't know wether there is another system with an
advskew highter than the current master's one but lower than yours.

--
Henning Brauer, hb@..., henning@...
BS Web Services, http://bsws.de
Full-Service ISP - Secure Hosting, Mail and DNS Services
Dedicated Servers, Rootservers, Application Hosting - Hamburg & Amsterdam

[Karsten McMinn]

On Fri, Apr 11, 2008 at 9:13 AM, Matthew Dempsky <matthew@...>
wrote:
>
> Probably not.  I've never had problems with carp's fallover time and
> I've never used a Cisco firewall so I don't really know how it
> actually compares.  I just wanted to suggest a maybe-solution assuming
> the supposed slow failover time was a problem.
>

 I've benchmarked PIX 515s running 7.2 code using stateful
failover and the proprietary serial cable. Powering down
the active firewall nets about 700-750ms of downtime consistently.
How does carp fare?