Hi, On 4/23/2003 6:16 AM, Ludo Koren wrote: > After upgrading to FreeBSD 5.0-RELEASE-p7 (COMPAQ) #0: Sun Apr 20 > 21:50:49 CEST 2003 IPsec stopped working. > > I have the following options in the kernel configuration: > > options IPSEC #IP security > options IPSEC_ESP #IP security (crypto; define w/ IPSEC) > options IPSEC_DEBUG #debug for IP security > > and the IPsec configuration was working with FreeBSD 4.6: > > #! /bin/sh > > /sbin/ifconfig gif0 create tunnel 195.28.126.7 195.91.63.194 > /usr/sbin/gifconfig gif0 inet 195.28.126.7 195.91.63.194 > /sbin/ifconfig gif0 inet x.x.x.x netmask 255.255.255.255 y.y.y.0 netmask 255.255.255.0 up > > /usr/sbin/setkey -FP > /usr/sbin/setkey -F > /usr/sbin/setkey -c << EOF > > spdadd x.x.x.x/32 y.y.y.0/24 any -P out ipsec esp/tunnel/195.28.126.7-195.91.63.194/require; > spdadd y.y.y.0/24 x.x.x.x/32 any -P in ipsec esp/tunnel/195.91.63.194-195.28.126.7/require; > > EOF > > /sbin/route add -net y.y.y.0 x.x.x.x 255.255.255.0 -iface > /usr/local/sbin/racoon > > > I can see via tcpdump on fxp0, ESP packets are going to the > destination and back. But unfortunately, ping doesn't get the > response. It seems, packets do not come back through gif0 interface, > though tcpdump on fxp0 interface get them. you're using IPsec tunnel mode together with a parallel IPIP gif tunnel. This has been suggested in a bunch of online "tutorials" on IPsec, but is a bad idea, with both -stable and -current. The attached email message explains why. In short, try this: 1. remove IPSEC_DEBUG (not sure if this even still does something) 2. don't configure the gif interface at all 3. don't use the route command i.e. just do the setkey commands you have above. Alternatively, take a look at draft-touch-ipsec-vpn-05.txt, which proposes an alternative that works with routing (but not current IKE). Lars -- Lars Eggert <larse_at_isi.edu> USC Information Sciences Institute
attached mail follows:
Josef, Josef Pojsl wrote: > I am a happy user of IPsec tunnels among many FreeBSD machines > (versions range from 4.2 to 4.7-RELEASE). I am using racoon > and certificates for key exchange. Everything just works. > I have never used the gif interface. I always set up the SPDs > with setkey and configure racoon. > > Many web pages come up with examples of setting up an IPsec tunnel > with KAME. On some of them, the gif(4) interface is used > to set up the tunnel. One of them is here: > http://www.freebsddiary.org/ipsec-tunnel.php These examples are bogus. I have personally contacted the author of the page you mentioned (as well as several others), to tell them their configuration is dubious (see below). The answer was usually along the lines of "I know that now, but I wrote the page back when I didn't know much about IPsec." > I am a little bit confused by those configuration samples. > A couple of questions raise in my head: > > - Can gif(4) substitute the tunneling feature of IPsec, > so that IPsec would be used in transport mode only? Yes. See draft-touch (ftp://ftp.ietf.org/internet-drafts/draft-touch-ipsec-vpn-04.txt), but also note the IKE limitations discussed in the KAME implementation notes. A revision of RFC 2401 is currently underway, and support for draft-touch may be included. We will also probably create an updated new ID that discusses in detail on how to set up a VPN with IPIP tunnels and a minimal subset of the existing (or new) IPsec spec. This will be based on just transport mode, limited selectors (firewalls should do the firewalling), RFC 2003 (IPIP) for tunneling, and a simplified IKE exchange. To set up an IPIP+transport tunnel, do IKE in the base network, then set up an IPIP tunnel (protocol to be specified), then run IKE over the tunnel. > - I have come across configurations using both IPsec/transport/gif > and IPsec/tunnel/gif. Are two tunnels used with IPsec/tunnel/gif? No. What the configurations you saw do is create a virtual topology using gif IPIP tunnels (usually to get some sort of dynamic routing going in the overlay), and then *duplicate* the same topology using IPsec tunnel mode tunnels. What this does is (ab)using the routing entries for the IPIP topology to apparently force traffic into an IPsec tunnel mode tunnel. It all seems to work first, but if your two topologies get out of sync, connectivity is lost (in the best case) or your traffic silently goes in the clear (worst case). > - Is there any added value in using gif? I would appreciate if I could > see encrypted packets appearing on the real network interface > and decrypted (or not-yet-encrypted) packets on the gifX interface, > is this the case? The added value of using IPIP gifs and transport mode IPsec is described in draft-touch (in our opinion, at least). There is no added value for IPIP giffsplus tunnel mode, that is a broken configuration IMO. Lars -- Lars Eggert <larse_at_isi.edu> USC Information Sciences Institute
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:04 UTC