Date: Fri, 08 Jun 2012 14:21:27 -0400 From: Stephen Clark <sclark46@earthlink.net> To: "Eugene M. Zheganin" <emz@norma.perm.ru> Cc: "net@freebsd.org" <net@freebsd.org> Subject: Re: if_ipsec Message-ID: <4FD242A7.6090507@earthlink.net> In-Reply-To: <4FD236D4.6090409@norma.perm.ru> References: <4FD236D4.6090409@norma.perm.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
On 06/08/2012 01:31 PM, Eugene M. Zheganin wrote: > Hi. > > I have an idea about new networking feature in FreeBSD. > I guess everyone is having ideas from time to time, and lots of these > idea having people think that they just had a decent idea. However, > only ideas that are complemented by a working code can be considered > by the community, and only some of them got commited into the tree, I > am fully aware of this fact. > > Unfortunately, I am not able to produce the code. I guess this is the > point where most of the subscribers will (or at least should) stop > reading this post. Still, I'm addressing this post for people that > have the time and will to do something interesting. I guess that > someone may find this interesting. Myself, I find that this could be > really useful. > > (You can skip this part and the next part if you only want to read > about the idea) I work about 10 years as a network engineer. My > company holds country-wide supermarkets business. I am personally > responsible for the network infrastructure of the company. As the > company has lots of (hundreds) of branch offices, lots of my time I'm > constructing new VPNs between them. My company network infrastructure > is build using FreeBSD servers and Cisco (and last year - Juniper) > equipment. So I am aware and capable of building VPN of almost any > modern type, and this is the post about building it on FreeBSD (this > annoying passage was written to give you impression that I'm not just > a guy with FreeBSD server at home, holding a couple of movies). > > So. About VPNs. Another annoying passage about common ways and > caveats. Otherwise most of the reading ppl will say 'Why the hell > if_ipsec ?' (ppl that are aware of the VPNs can really skip this > part). The conventional way to build vpn is to build a tunnel of some > sort. This can be an encrypted tunnel, or an unencrypted tunnel. > Unencrypted tunnel (gre/ipinip) is obviously unencrypted, but gives > you an interface which could be using in routing. Encrypted tunnel > (and I'm talking about ipsec) cannot be used for rounting, but is > encrypted. Plus, you have to care about policies, and when multiple > routers are involved, with hundreds of networks behind them, you have > to care about tonns of policies, and this is painful. So, the industry > invented a method: you use a gre/ipinip tunnel, you pass the dynamic > routing information (you don't care bout networks, you only care > abouth the endpoints), and you encrypt this tunnel with ipsec. So, gre > + ipsec (of gif + ipsec). This way is supported by all of the major > vendors, you can build gre(ipinip)+ipsec tunnel to any Cisco/Juniper > device. Though building in to JunOS requires some skill and a deep > knowledge. :) > > (here the idea starts) But what is an gre or gif tunnel ? This is not > an interface, but a way to tell the system, that it needs to > encapsulate some of the payload with another header, and send it > somewhere. So, using ipsec you add an extra header, and using > gre(ipinip) you add an extra header. What if we will add an additional > ability to understand that some of the ipsec packets are destined to > the security gateway (which adds the extra header) itself, like it's > possible with gre/ipinip, so we can get rid of one extra header ? > Cisco/Juniper did that. So, Cisco has the 'tun mode ipsec ipvX' > interface, and Juniper has the st (secure tunnel) interface. How does > it work: it's a convenstional ISAKMP IPsec with the ability to treat > some of the packets with a particular IP like destined to the local > (by this I mean 'this') host. Besides this it's the old IPsec. It's > even interoperable between different vendors devices. I don't see any > reason why FreeBSD cannot have this ability, since it does have a > working Ipsec and working ISAKMP. In order to obtain this > functionality FreeBSD needs to have a way to define the templates for > the SPD entries, and the way to create these SPD entries after the > creation of the interface, based on it's address information. This > will really simplify the VPN creating and management. > > So... here was the idea. :) > It came to my head after configuring the Juniper/Cisco VPN (and the > config was really short), and after reading quagga-users@ maillist, > where some of the subscribers asked about 'tun mode ipsec'. Plus, as > far as I know, Linux does not support this too, so we could really > score some Hmm... I just saw a patch on linux-netdev that implements this for linux. > points. > > Eugene. > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > -- "They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety." (Ben Franklin) "The course of history shows that as a government grows, liberty decreases." (Thomas Jefferson)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4FD242A7.6090507>