Date: Fri, 15 Jun 2012 10:22:14 +0600 From: "Eugene M. Zheganin" <emz@norma.perm.ru> To: freebsd-net@freebsd.org Subject: Re: if_ipsec Message-ID: <4FDAB876.8040400@norma.perm.ru> In-Reply-To: <20120614155748.GC40355@felucia.tataz.chchile.org> References: <4FD236D4.6090409@norma.perm.ru> <20120609170721.GA40355@felucia.tataz.chchile.org> <4FD98EC1.50200@norma.perm.ru> <20120614155748.GC40355@felucia.tataz.chchile.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi. On 14.06.2012 21:57, Jeremie Le Hen wrote: > Not at all, I read the whole mail thoroughly actually :-). But I don't > work on Cisco/Junipers equipements so I didn't exactly grasp what you > meant. > > Okay. Actually, the whole idea is to 'simplify'. The conventional way of creating IPSec makes you do a lot of stuff: creating policies, creating tunnel interfaces, creating isakmp phase 1 and phase 2 proposals. Cisco/Juniper equipment is pretty capable of doing all of this stuff too (if you want fine-grained control), but by defaults they got rid of all of this configuration, it works with defaults, and works fine. And the gre setup is especially complicated when it comes to Juniper, because they totally got rid of the policing mechanism, and there's no way in JunOS (at least in 10.x-12.1) to define a policy about 'what kind of traffic to encrypt with IPSec' like you can do in Linux/*BSD/Cisco. So I'm afraid Cisco can lose this ability too. It is still possible to build a FreeBSD - Juniper gre/ipsec tunnel (and I'm using them), but it requires a twisted hack with routing on the Juniper side, and a pair of _additional_ IP addresses. So, complicated stuff on one side, ipsec interfaces (and some default configs) on the other. Eugene.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4FDAB876.8040400>