Slashdot Mirror


Embedded Linux VPN Router Near Release

An anonymous reader writes "A new open source project aims to build a VPN router that supports all major routing protocols on a standardized hardware platform running embedded Linux. The "Linux Router Project - LR101" started in mid-2003 and plans a first release in January 2004. It is based on a dual-NIC VIA EPIA mainboard and a Travla case, along with Red Hat 8, zebra, FreeS/WAN, IP-tables, an other open source software, all compiled from source."

7 of 121 comments (clear)

  1. HA by pheared · · Score: 5, Interesting

    It would be nice if they have High Availability on their feature list. Some nice solid appliances like this would be interesting.

  2. A different LRP by Anonymous Coward · · Score: 1, Interesting

    Is this the same Linux Router Project that was run by that crazy, paranoid survivalist guy? Or is that still dead?

  3. PPTP is UNdesirable by billstewart · · Score: 3, Interesting

    The initial PPTP was a total botch, with seven major security flaws. Some of them have since been fixed, but it gives you some idea of the professionalism and quality that didn't go into the basic design. If you want to use a VPN for security, use IPSEC - and this project has FreeS/WAN IPSEC in it. If you really really want to use a VPN to transport lame non-IP legacy Microsoft LAN protocols, go pay Microsoft some money for one of their server projects, and charge the silly customer who's hiring you as a consultant because they don't want to upgrade to the 1990s for it. If you want to use a VPN to carry private IP addresses, but don't actually care about security, use IPSEC anyway, or use GRE tunnels.

    --

    Bill Stewart
    New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
  4. Re:RH8? by kervel · · Score: 2, Interesting

    i was considering to buy a soekris, but when i added up all costs (shipping, ...) it turned out to be not worth the money. Soekris is silent okay, and powersaving okay, but the slow CPU limits the use to routing/firewalling/VPN/... and you can buy cheaper equipment for that.

  5. Re:Still No Shiva Support on Linux by mdouglas · · Score: 2, Interesting

    I administered a Shiva vpn server in 2000/2001. I would have preferred to use the open standard IPSEC vs the proprietary SST; however their IPSEC option would not support RADIUS authentication. That was the deciding factor for going with SST. Aside from that it wasn't a bad product.

  6. "RealTek/NE2000 compatible NICs for the DMZ" by pmsr · · Score: 2, Interesting

    Having programmed some of these "beauties" in connection with a microcontroller, i must say they are shooting themselves in the foot. The first word that comes to my mouth is YUCK! I know all these 3Com and Intel network cards are more expensive, but they save time and money in the long run.

    /Pedro

    1. Re:"RealTek/NE2000 compatible NICs for the DMZ" by smnolde · · Score: 3, Interesting

      RealTek is RealCrap. You get what you pay for.

      From /usr/src/sys/pci/if_rl.c on my FreeBSD system:
      * The RealTek 8139 PCI NIC redefines the meaning of 'low end.' This is
      * probably the worst PCI ethernet controller ever made, with the possible
      * exception of the FEAST chip made by SMC. The 8139 supports bus-master
      * DMA, but it has a terrible interface that nullifies any performance
      * gains that bus-master DMA usually offers.
      *
      * It's impossible given this rotten design to really achieve decent
      * performance at 100Mbps, unless you happen to have a 400Mhz PII or
      * some equally overmuscled CPU to drive it.

      This is my favorite comment:
      * Here's a totally undocumented fact for you. When the
      * RealTek chip is in the process of copying a packet into
      * RAM for you, the length will be 0xfff0. If you spot a
      * packet header with this value, you need to stop. The
      * datasheet makes absolutely no mention of this and
      * RealTek should be shot for this.

      More funny stuff:
      * The RealTek is brain damaged and wants longword-aligned
      * TX buffers, plus we can only have one fragment buffer
      * per packet. We have to copy pretty much all the time.