vtun eats too many cpu and makes context switches, even without encryption. You will need a monster machine to be able to tunnel-and-bridge high bandwidths.
Any known solutions to create ethertap tunnel in the kernel space ? -- Nikolay Datchev On Tue, 26 Mar 2002, Logan Bowers wrote: > Torrey, > > Take a look at vtun.sourceforge.net. If you want to want to make an > encrypted tunnel, use ssh to make a tcp tunnel then use vtun to bridge > through the tunnel. If the link is broken, you'll have to manually > recreate the ssh tunnel, but with a few slight variations, you can > probably make a self-healing tunnel. In either case, vtun is probably > where you want to be. > > If you really need to do the encryption/decryption in the bridge, you > might want to think about using netfilter to get the packets into > userspace and manipulating them with a userspace application. > > > Logan Bowers > > Torrey Hoffman wrote: > > > > Has anyone out there modified the bridge code to do encryption/ > > decryption? > > > > I'm working on it, but if it's been done already that could save me some > > time. > > > > What I'm doing is a setup where all traffic to a given MAC address would > > be AES-encrypted with a unique key. Traffic from that address would be > > decrypted using the same key. Other than encryption and decryption, the > > bridge would be transparent (or, could drop all packets for which > > encryption keys are not known, if you want to disallow cleartext). > > > > Why am I doing this? Well, one use would be secure transparent bridges > > over wireless or optical links. That would require an encrypting bridge > > at both ends. > > > > You may point out that this sort of thing is better done with IPSec, > > tunnelling, or other components of the Linux IP stack. That may in fact > > be true in many cases, but I actually have a different use in mind for > > this code. However I can't talk about it until the company I work for > > announces it. :-) > > > > I'm not doing key management at the kernel level - I am modifying the > > brctl program to give a command line interface, but that is just a > > simple wrapper around a new ioctl for the bridge. In reality a > > higher-level protocol and application would be used to manage keys. > > > > My work will be GPL'ed of course, but not done or released yet... maybe > > in a week or two. I've stolen code (hashtable stuff, etc) from the > > mac-filter patch for the bridge code, and the AES code is from the > > Loopback-AES kernel patch. > > > > I have to thank the authors of the bridge module and the macfilter patch > > for writing such readable, easy-to-hack code... > > > > If anyone has done this before, or is interested, drop me an email... > > > > Torrey Hoffman > > [EMAIL PROTECTED] > > > > _______________________________________________ > > Bridge mailing list > > [EMAIL PROTECTED] > > http://www.math.leidenuniv.nl/mailman/listinfo/bridge > _______________________________________________ > Bridge mailing list > [EMAIL PROTECTED] > http://www.math.leidenuniv.nl/mailman/listinfo/bridge > _______________________________________________ Bridge mailing list [EMAIL PROTECTED] http://www.math.leidenuniv.nl/mailman/listinfo/bridge
