In article <1065020203.4745.10.camel@chtephan.cs.pocnet.net>, Christophe Saout <christophe@saout.de> wrote: | Am Mi, den 01.10.2003 schrieb Herbert Xu um 14:16: | | > Any opinions on this would be appreciated. | | The "old" frees/wan klips kernel code did it this way: It defined a new | virtual network interface named ipsec0. Then userspace set up routes, | everything that had to be encrypted was sent to ipsec0. I've used several tunneling programs which setup a slip or ppp connection through an encrypted socket, and they all share the ease of use you mention in terms of a "device" which can be used for routing. I can't speak to overhead, but this is easy to use, probably because it's easy to understand. It seems to avoid some of the problems of NAT and crypt order issues mentioned earlier. | | So I could NAT my packets in the POSTROUTING chain of the packets going | to ipsec0. Then they were encrypted and sent to the real device, like | ppp0. | | On the other way round I could catch the packets two times, the | encrypted packets with "iptables -t filter -A INPUT -i ppp0 ..." and the | decrypted ones with "iptables -t filter -A INPUT/FORWARD -i ipsec+" (if | a natted packet returns or a subnet was tunneled). | | I'm not saying that you must do it the same way, but it was very | flexible. | | Would it be possible to run a packet that was encrypted or decrypted | through netfilter a second time? Or how does the current mechanism | generally work (and integrate with routing/filtering), are there some | diagrams or something? I share the question, would it be possible to have a similar easy to use interface, or if not could someone explain the problems a little better or propose better solutions? -- bill davidsen <davidsen@tmr.com> CTO, TMR Associates, Inc Doing interesting things with little computers since 1979. - : send the line "unsubscribe linux-net" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
