Hi Eugene,
On Fri, Jun 08, 2012 at 11:31:00PM +0600, 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 points.
I'm not sure I've understood what you're asking. As a network engineer,
I'm sure you know there are two modes with IPSec: tunnel and transport.
Tunnel mode is weird because it practically creates an encrypted tunnel,
but the later is invisible from the OS, IIRC. With transport mode just
encrypt the payload (that is, the data after the IP header) when the SPD
says so.
What it usually done for convenience is to create a gif(4) or gre(4)
tunnel to another network, which is then encrypted using IPSec transport
mode. The inner IP/GRE header is considered as the payload and it is
encrypted. The benefit of this approach is that you "see" your tunnel,
it looks more natural from a system point of view.
I haven't used IPSec in tunnel mode for more than a decades, so I don't
remember how it is manageable. But with the IPSec transport mode +
gif/gre tunnel, you see a full-fledged interface toward the other
network, through which you can route your traffic.
--
Jeremie Le Hen
Men are born free and equal. Later on, they're on their own.
Jean Yanne
_______________________________________________
freebsd- mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-"
)
