OpenBSD Journal

Another Business Case for Integrating OpenBSD into IT Infrastructures

Contributed by Sean Comeau on from the use-openbsd-everywhere dept.

At the recent PacSec conference in Tokyo, I demonstrated how we can easily secure wireless networks with OpenBSD. This solution uses IPsec to protect the traffic between the wireless clients and the Access Points. Users authenticate using OpenSSH (authpf) before they are allowed access to network resources. All of this is automated making it user friendly and very secure. These slides may be of interest to undeadly readers. They are also available in pdf.

(Comments are closed)


  1. By Anonymous Coward () on

    Errors in the PDF.

    It speaks of Dual Factor Encryption and IPSEC as strong authentication.

    1. By Sean Comeau () on

      which page?

      1. By Anonymous Coward () on

        Page 3.

        1. By Sean Comeau () on

          Ah yes, I see. It doesn't really make sense the way it is. That's what happens with slides I suppose.

          OpenSSH & authpf are used with keys (what you have) & passphrase (what you know) to apply your user specific pf rules.

          thanks for pointing it out

  2. By Michael Pounov () misho@openbsd-bg.org on

    All is right, but free-hal of wireless atheros chip not work propriety at 5GHz range... :(:( because of that for AP (access point) I use freebsd :(:( atheros support is only good wish in my favourite OS :(:(:(:(:(

    1. By Anonymous Coward () on

      So buy hardware that doesn't suck and quit posting this crap on every wireless article.

      1. By Michael Pounov () misho@openbsd-bg.org on

        Heh, you crazy ? :):)
        Wistron CM9 is crapy hardware ??? :):):):) heh
        or D-link or may be ... ??

        Who hardware with atheros works of free-hal 5GHz fine like ap-client ot adhoc where is ACKTIMEOUT ? TIMESLOTS where? :):):):):)

        Sorry, but binary hal WORK fine! not freehal :)

        1. By Anonymous Coward () on

          Don't use atheros garbage, that's the whole point. :):():():(:):):(:)(:):():(:):()::):):(:):():(:):():

  3. By Anonymous Coward () on

    Wow, that's wonderfull !

    By the way, what's the licence of the .vbs and .bat files ? could we reuse them ?
    If yes, may I ask if it would be possible to provide the complete vbs (I mean, with the error checks) ?

    visual basic isn't trivial for me, as unix sysadmin ...

    Whatever your position for the vbs & bat files, thanks for this great demo .

    How, and side question: how many tunnels / how much throughput can an emb-564 stand ?
    AFAIK, windows can only do 3DES for IPsec, and 3DES is not accelerated by the cool cryptos functions of the Via Eden (as opposed to AES). So how far can we go with those boxes ?
    Does anyone else have a good tip about hardware for good 3DES perfs ? (yes, there's crypto cards, but none are really well suported - apparently hifn is quite buggy ...).

    1. By Chad Loder () on

      Get a fast CPU and an architecture with good memory bandwidth. AES is blazingly fast in software and I *highly* doubt the crypto will be your bottleneck. In fact, often times, AES is faster in software than if you use a card.

      1. By Anonymous Coward () on

        Did you miss the part about how windows can only do 3DES, and so he's asking about 3DES?

      2. By Anonymous Coward () on

        Yes, right, AES (and blowfish, too) is very fast. On my hardware, it's about 5 times faster than 3DES according to "openss speed -elapsed".

        Sadly, MS Windows can only do DES and 3DES for IPsec. That's why the slides from the story show the use of 3DES rather than a faster algo. And hence my question about 3DES throughput.

        On my OpenBSD IPsec gateway (intel p4 2.8Ghz), I can't go better than 20Mo/s. Would a recent opteron (with a better memory bw thant this old intel) give really better performances ?

    2. By sthen () on

      Eden 533MHz does not have instructions to accelerate AES (see the Padlock ACE column in this VIA CPU list).

      PCI crypto cards are often not much help on slower machines for encrypting network traffic, since they introduce a lot of overhead. On-chip instructions like on the newer c5p-cored VIA chips help a lot more.

      1. By Anonymous Coward () on

        Agreed.

        I'm hitting 80Mbps+ (AES256) on my VIA PD10000 (VIA C3 "Nehemiah" with Padlock). (It falls to 60Mbps+ if you use SHA-256 and AES256, as SHA is done in software only. (C3 can't do hardware SHA, but the newer C7 can!)

        It does 80 to 90Mbps with just normal NAT/pf, which is similar to a typical PIII 500Mhz.

        In comparison, software AES is 25% to 50% slower.


        If you think about it, EPIAs with Padlock are more efficient in this VPN role. Power consumption-wise, its much better than either P4 or AMD solution. At most, these EPIA mobos hit 24W under full load.
        (Under full load, a P4 or Opteron CPU does 4 to 6 times more...That's just the CPU alone!)

        I think what's holding the EPIA back is the chipset. I suspect the C3 with Padlock won't have trouble handling Gigabit speeds. (Of course, the VIA chipset isn't efficient and currently, no VIA C3 powered board is designed to be with Gigbit Ethernet connections)...But if you're requirements are for 80Mbps or less, they are sufficient for the role.

        Hopefully, the newer C7 and accompanying chipset does better.
        (The newer chipset does support Gigabit, but time will tell how efficient VIA's implementation is).

        1. By Anonymous Coward () on

          A quick check on the price of that Commell embedded board...OUCH!
          You can buy two regular EPIAs (Padlock capable ones) and a pair of quad-port NICs for the same price!

    3. By Uwe Brechlin () on

      I have no experience with crypotcards, but I think Soekris offers the thing you are looking for: http://www.soekris.com/vpn1401.htm

      It supports 3-DES and is said to be fully supported by OpenBSD and FreeBSD.

Credits

Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]