Why KAME/racoon sucks (was: OpenSWAN ANNOUCEMENT)

Dax Kelson dax at gurulabs.com
Sun Jan 4 02:58:03 UTC 2004


On Sat, 2004-01-03 at 12:14, Lamar Owen wrote:
> v2.10?  They just released 1.0.0, with 2.0.0 in development.  Why do we need 
> this when the KAME stuff is working and works with 2.6?  KAME being what RHEL 
> is using, why would OpenSWAN be needed in Core (maybe in Alternatives, since 
> it _is_ and alternative IPsec implementation).  If you need DPD and NAT-T, I 
> guess you would want this.  For straight IPsec, or PPP over L2TP over IPsec 
> w/X.509, KAME plus the RHEL 2.4 kernel or the 2.6 kernel seems to get the job 
> done.
> 
> Just curious as to the reason why; I looked at Super FreeS/WAN before getting 
> White Box loaded here (which has the same patches and ipsec-tools as RHEL3).  
> The KAME config is vastly different than the SFSWAN config.  So, tell me why 
> I should completely redo everything: if it has a Can't-Live-Without feature, 
> then, tell us.

Sure, I tell you yet again...(already posted to this list on Dec 8th):

As a user and an administrator of variety of production systems IKE
daemons ranging from KAME/racoon, isakmpd, Solaris 8/9 IKE, FreeSWAN,
and SuperFreeSWAN, I can comment that I've found all but SuperFreeSWAN
sorely lacking.

Note that Openswan is the successor to Super FreeSWAN.

The critical features an IKE daemon are:

a) Ability to be configured as VPN concentrator supporting both road 
warriors and remote LANs all at the same time.

b) X.509 certificate support

c) Virtual-IP support for persistent inner IP address in ESP packets.
This allows no-headache IPsec through non-brain dead NATing
routers/firewalls without resorting to the following.

d) NAT-T (ala ESP-over-UDP) for IPsec through brain dead NATing
routers/firewalls.

The other nice features are:

e) AES support
f) Notify/Delete SA (for Cisco interop)
g) XAUTH support (authenticate VPN users/tunnels via PAM)
h) DHCP over IPSec
i) Transport mode

All these features are supported by SuperFreeSWAN/Openswan and racoon
and isakmpd only support b, i and maybe "e".

IPsec deployment covers two areas

1) Secure LAN-to-LAN communication
2) Secure road warrior to HQ communication

I would say IPsec deployment for "2" clearly, clearly outweighs "1".

Basically, supporting road warriors is impossible with racoon or isakmp.

Dax Kelson
Guru Labs





More information about the fedora-devel-list mailing list