Date: Fri, 18 Aug 2006 23:36:30 +0400 From: "Andrew Pantyukhin" <infofarmer@FreeBSD.org> To: "Yu-Shun Wang" <yushunwa@isi.edu> Cc: remko@freebsd.org, net@freebsd.org Subject: Re: Routing IPSEC packets? Message-ID: <cb5206420608181236h34c0b85fwffc93bdd6c6979f4@mail.gmail.com> In-Reply-To: <44E5F19E.9070600@isi.edu> References: <44E58E9E.1030401@FreeBSD.org> <44E5F19E.9070600@isi.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On 8/18/06, Yu-Shun Wang <yushunwa@isi.edu> wrote: > Remko Lodder wrote: > > Hi friends, > > > > I was looking around for using IPsec services instead of > > OpenVPN services, but I found out that with our current > > implementation of IPsec, we cannot actually route packets > > through the various IPsec hops [1]. OpenBSD adds IPsec > > flows in their routing table, making it possible to route > > traffic between IPsec tunnels. > > > > Can someone either confirm my above statement that FreeBSD > > is indeed not capable of doing this? > > It's not an implementation issue, but a design problem with > IPsec tunnel mode. See RFC3884: > > <http://www.ietf.org/rfc/rfc3884.txt>; > > The proposed solution is to use IP-IP tunnel (gif iface in > FreeBSD, which you can route) then apply IPsec transport mode > on the outer header. Refer to the rfc for more detail. > > The policy will be different, but we've verified long ago > with FreeBSD that it works. The packets on the wire is > compatible with regular tunnel mode IPsec. Eh? gif(4) says: BUGS There are many tunnelling protocol specifications, all defined differ- ently from each other. The gif device may not interoperate with peers which are based on different specifications, and are picky about outer header fields. For example, you cannot usually use gif to talk with IPsec devices that use IPsec tunnel mode.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?cb5206420608181236h34c0b85fwffc93bdd6c6979f4>