Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Encryption Security Software The Internet Your Rights Online Linux

FreeS/WAN Continues As Openswan 68

Posted by timothy from the duckling-of-indeterminate-pulchritude dept.
leto writes "It seems some of the developers and volunteers of the (recently deceased) FreeS/WAN project have started a new company to develop and support the successor of the Linux IPsec code under the name of Openswan in a "Cygnus style" business model. They announced the new version at CeBIT which fully supports the new Linux 2.6 native IPsec stack. According to the Openswan website, it was started 'by a few of the developers who were growing frustrated with the politics surrounding the FreeS/WAN project.' There is a FAQ that explains how the various parts of IPsec on Linux work together. I guess that means US citizens can finally submit patches, and that distributions like RedHat/Fedora can now include it in their distribution. FreeS/WAN has always had the most features and most the most user-friendly configuration. It is good to see that will continue. And their mailing list finally seems to refuse spam too."
This discussion has been archived. No new comments can be posted.

FreeS/WAN Continues As Openswan More

FreeS/WAN Continues As Openswan

Comments Filter:

  • Re: (Score:2, Informative)

    by account_deleted ( 4530225 )
    Comment removed based on user account deletion

  • user friendly? (Score:5, Insightful)

    by Kryptolus ( 238444 ) on Tuesday March 23, 2004 @05:23AM (#8643243) Homepage
    I guess you never personally configured it...

    • Re:user friendly? (Score:5, Insightful)

      by arivanov ( 12034 ) on Tuesday March 23, 2004 @06:21AM (#8643415) Homepage
      Ahem.

      The most horrible IPSEC out there. Broken by design, absolutely incompatible with any routing protocol software, broken in operation and utter nightmare to configure and get working.

      One of the things I apploaded most when reading the 2.6 kernel changelogs was the port of KAME IPSEC and utilities. They work (TM). They are missing some features that were in FreeSwan that made it useable as a amateur VPN access point (email ID in shared keys, x509 CRL and a few others), but I do not see these as a reason to revive freeswan instead of fixing the omissions.

      • Re:user friendly? (Score:3, Interesting)

        by jamesh ( 87723 )
        Openswan works fine with 2.6 ipsec, as did freeswan. With the 2.6 Kernel, openswan just does isakmp and then tells the kernel what to do. imho, openswan is more flexible than any of the other isakmp implementations i've seen available for linux.

        For certain values of 'nice', one of the nice things about klips was that there was a virtual interface for the decrypted traffic. Stuff for encryption went out ipsecN, then the encrypted packet (proto 50/51) went out the real interface. Made firewalling and routin

        • Re:user friendly? (Score:3, Informative)

          by arivanov ( 12034 )
          For certain values of 'nice', one of the nice things about klips was that there was a virtual interface for the decrypted traffic.

          Nice for manual kludge on a small office VPN setups - agree 100%.

          Absolutely disagree for a larger network with dynamic routing. For any network with these it was THE NIGHTMARE DESIGN (TM). Reason is that nearly any routing protocol carries either IP or IP/NETMASK information and no interface information (neither name, nor ifIndex). It is obvious that in the presence of two int

    • Don't forget about the arrogance one encountered when asking for help, either. I've sucked up and dealt with some amazing Napoleonic complexes when using software before, but these guys were such bastards I actually chose a commercial solution over them in the end. I draw the line at accepting condescending remarks from people who don't know how to keep a listserv running properly while failing to address the question asked of them.
      • I disagree. The support mailinglist has been great. For instance, FreeS/WAN team member Sam Sgro provided commercial quality support. One issue is that they deliberately did not filter for viruses and spam. But other filtered mailinglists sprung up so that was not really an issue.

  • Not the only IPSec stack (Score:5, Interesting)

    by The-Pheon ( 65392 ) on Tuesday March 23, 2004 @05:29AM (#8643265) Homepage
    Don't forget about KAME [kame.net]. It isn't just for IPv6, and also supports IPSec for both ipv4 and ipv6.

    • Re:Not the only IPSec stack (Score:5, Informative)

      by Anonymous Coward on Tuesday March 23, 2004 @05:35AM (#8643284)
      Yes, and it's under a very liberal license too.
      Even better, it is VERY portable, which means that as an administrator you just have to care to know about KAME and not a gazillion halfbaked inconsistent implementations.

    • Re:no but maybe the better one... (Score:5, Informative)

      by pacman on prozac ( 448607 ) on Tuesday March 23, 2004 @06:03AM (#8643370)
      The problem with KAME is that IPSec packets between two hosts can bypass the packet filters.

      That is, with KAME on Linux and FreeBSD, packets are not decrypted until after iptables/ipfw has looked at them. That means you cannot packet filter on anything other than IP & MAC Address as you can't read anything else, its all encrypted :)

      Apparently FreeS/WAN had a separate device to read from that gave unencrypted packets for filtering.

      This only applies to transport IPSec between two complete hosts. You can use tunnel mode onto a tun device and filter from that, and you can also just encrypt traffic based on port.

      Either way, I'm kind of relieved that FreeS/WAN has not gone completely and that the above situation still has a fix. A security protocol seems kinda useless when it allows firewall bypassing, especially when it could happen automatically if you have IKE setup and open to the world.

      • Re:no but maybe the better one... (Score:5, Informative)

        by arivanov ( 12034 ) on Tuesday March 23, 2004 @06:23AM (#8643426) Homepage
        That means you cannot packet filter on anything other than IP & MAC Address as you can't read anything else, its all encrypted

        Used to be correct as of ipfw 1. No longer the case as of ipfw2, though some cases do not work fully yet. See the ipsec qualifier for rules.

        Dunno about Linux though. I use KAME extensively only on BSD.

  • At Lazt ... (Score:5, Funny)

    by AftanGustur ( 7715 ) on Tuesday March 23, 2004 @05:37AM (#8643287) Homepage


    I guess that means US citizens can finally submit patches, and that distributions like RedHat/Fedora can now include it in their distribution.

    Ahh, u mean ze citisenz of ze USA can finally have ze same freedom as ze French Bastardz [mandrakelinux.com] have had for yearz ?

    • Re:At Lazt ... (Score:1, Offtopic)

      by /dev/trash ( 182850 )
      France? Has freedoms? Care to discuss Nazi's and the like on a french based website?

      • France? Has freedoms? Care to discuss Nazi's and the like on a french based website?

        Although I agree with you that banning discussions about a topic is not the best way, the French view is that the Nazi ideology is so far off, that it's simply off-topic..

        Like if you would put up a site anywhere in the world about the pros, cons and pleasures of Phedophily. I'm pretty sure it wouldn't stay up very long.

        Or, try to put up a website in the USA, that justifies the 3000 dead in the twin towers ...
        You

    • Re:At Lazt ... (Score:4, Funny)

      by Odin's Raven ( 145278 ) on Tuesday March 23, 2004 @10:54AM (#8645280)
      ...ze French Bastardz...

      Excuse me, but here in the US the politically-correct term is Freedom Bastardz. ;-)

  • Talk about lacking in content (Score:4, Interesting)

    by pinkUZI ( 515787 ) <slashdot.7.jmask ... et.com minus cat> on Tuesday March 23, 2004 @05:58AM (#8643355) Journal
    There was more content in the article on slashdot than on the entire Openswan website!

  • Strongswan (Score:5, Informative)

    by gvdkamp ( 139273 ) * on Tuesday March 23, 2004 @06:19AM (#8643410) Homepage Journal
    There is yet another project. Andreas Steffen (Creator and maintainer of the X509 patches for FreeS/WAN) has started its own version as well. Check out www.strongswan.org [strongswan.org] for differences between openswan and strongswan.

  • 2.6 IPsec still problematic (Score:5, Interesting)

    by valentyn ( 248783 ) on Tuesday March 23, 2004 @06:20AM (#8643413) Homepage
    I've been testing with 2.6 IPsec, but I'm not convinced that it's production ready. Especially the MTU handling gives me the creeps:

    valentijn:~# ping -s 1435 host21
    PING host21.wireless.palmgracht.nl (10.15.67.21): 1435 data bytes
    ping: sendto: Message too long
    ping: wrote host21.wireless.palmgracht.nl 1443 chars, ret=-1
    ping: sendto: Message too long
    ping: wrote host21.wireless.palmgracht.nl 1443 chars, ret=-1

    Resetting the MTU on the network interface helps:

    valentijn:~# ifconfig eth1 mtu 1400
    valentijn:~# ping -s 1417 host21
    PING host21.wireless.palmgracht.nl (10.15.67.21): 1417 data bytes
    1425 bytes from 10.15.67.21: icmp_seq=0 ttl=64 time=93.0 ms
    1425 bytes from 10.15.67.21: icmp_seq=1 ttl=64 time=78.2 ms

    Then, resetting it to 1500 again does this:
    valentijn:~# ifconfig eth1 mtu 1500
    valentijn:~# ping -s 1435 host21
    PING host21.wireless.palmgracht.nl (10.15.67.21): 1435 data bytes
    ping: sendto: Message too long
    ping: wrote host21.wireless.palmgracht.nl 1443 chars, ret=-1
    1443 bytes from 10.15.67.21: icmp_seq=1 ttl=64 time=89.0 ms

    So only the first packet is blocked, after that the kernel adjusts to the right MTU. And please note: this is internally, the first packet doesn't leave the machine.

    I had no time to test further, but what I found so far doesn't encourage me a lot to use 2.6 IPsec in production.

  • Swansong (Score:3, Funny)

    by Alain Williams ( 2972 ) <addw@phcomp.co.uk> on Tuesday March 23, 2004 @08:39AM (#8643968) Homepage
    So that earlier noise about it closing was not it's SwanSong after all.
    • It was for that other FreeBird (with apologies to Lynyrd Skynyrd and the late VanZant)

      "If I leave here tomorrow,
      will you still remember OE?"
      [*groan*]
  • If it wants to interoperate with any IPSec implementation other than itself, it will need to support negotiation through single DES (even if the tunnel doesn't wind up using it).

    Refusal to support single DES was what made FreeS/WAN virtually useless, even for those who muddled through the endpoint configurations and could put up with ip:port combos occasionally being hung out to dry due to dropped connects until the next rekey.

  • Opportunistic Encryption? (Score:3, Interesting)

    by SiliconEntity ( 448450 ) on Tuesday March 23, 2004 @12:06PM (#8646203)
    Ironically, the original goal of FreeS/WAN was not support of VPNs. It was to implement John "Suspected Terrorist [freetotravel.org]" Gilmore's goal of "encrypting 5% of the Internet by Christmas". The idea was that if two systems went to talk to each other with an ordinary net connection, and both happened to be running FreeS/WAN or compatible software, they would automatically and transparently negotiate IPSec encryption and use that for the connection. This is what they called Opportunistic Encryption [slashdot.org]. The goal of the project was to get some substantial fraction of internet traffic to be encrypted by this mechanism, thereby increasing privacy and decreasing the effectiveness of net-wide surveillance and monitoring tools.

    Sounds like a good idea to me. Are either of these new FreeS/WAN offshoots, or any other comparable project, trying to achieve Opportunistic Encryption? Or are they just for VPNs?
    • OE is still one of the goals; VPNs have been easy for a few years. One problem has been that their method for doing OE requires Reverse DNS support for DNSSEC, which makes it impractical for most potential users. In some sense it's still the Right Thing to do, because an IPSEC gateway only has a source and destination IP address to work from and needs some method for getting authentication keying information to prevent man-in-the-middle attacks, so it either needs Reverse DNSSEC or something very much lik
    • In Openswan OE is on by default and you have to edit your config file to turn it off. Fortunately - it's easy to disable.
  • Or, based on the fact that this project is an offspring of freeswan, should that be "Cygnet style" ? ;) ... ok, back in my box.

    Red.

Slashdot Top Deals

Garbage In -- Gospel Out.

Close