Date: Mon, 11 Apr 2016 11:02:51 +0200 From: Jan Bramkamp <crest@rlwinm.de> To: freebsd-hackers@freebsd.org Subject: Re: IPSEC tunnels Message-ID: <570B683B.30409@rlwinm.de> In-Reply-To: <alpine.BSF.2.20.1604102225010.43796@laptop.wojtek.intra> References: <alpine.BSF.2.20.1604080749020.4250@laptop.wojtek.intra> <CALfReydUCVg7A7ngS1vBHkCMOqgBOpddcn5JyfMUaWnWfqJhrg@mail.gmail.com> <alpine.BSF.2.20.1604102225010.43796@laptop.wojtek.intra>
next in thread | previous in thread | raw e-mail | index | archive | help
On 10/04/16 22:25, Wojciech Puchar wrote: >> dealing with layer 3 so you cant use normal port forwarding for the >> tunnel >> traffic. The key exchange is less problematic. It was a bit of a head >> ache, >> and if you can avoid the NAT you will be far better off. > > If i can avoid NAT i would use available FreeBSD IPSEC tunnel guides :) A lot of the documentation floating around on FreeBSD and IPsec is rather dated and uses racoon for IKEv1 over IPv4 in *tunneling* mode to implement a site to site VPN. I recommend that you take a look at strongSwan instead of racoon and use it to configure IKEv2 over IPv6 (or IPv4) in *transport* mode to protect a GRE tunnel. From the IPsec viewpoint the GRE tunnel is just a payload in transport mode. From the viewpoint of the rest of FreeBSD IP stack it is a routeable network (pseudo-)interface. In this setup you can treat your IPsec protected tunnels like any other tunnel interface and use a dynamic routing protocol to keep your sites connected in the face of failing tunnels. IPsec with IKEv2 can work through a NAT by encapsulating the ESP packets in UDP but it's easier if at least on site has a public static IP address. Which interior gateway protocol (IGP) are you using?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?570B683B.30409>