> -----Original Message----- > From: Greg Panula [mailto:greg.panula@dolaninformation.com] > Sent: 12 May 2003 11:10 > To: Matthew Braithwaite > Cc: stable@freebsd.org > Subject: Re: iHEADS UP: ipsec packet filtering change > > You don't really need the gif tunnels for ipsec. Gif is more geared > towards ipv4 <=> ipv6 type tunnels. A few of ipsec how-to's mention > using gif tunnels and I've been tripped up by it, too. > > ipsec is much easier without the gif tunnels. The ipsec policy > definition is explained in the setkey man page. Basically for tunnels > it is: spdadd ${remote net} ${local net} any -P in ipsec > esp/tunnel/${remote gateway}-${local gateway}/unqiue; and > spdadd ${local > net} ${remote net} any -P out ipsec esp/tunnel/${local > gateway}-${remote > gateway}/unique;I have seen this said before. I've also seen it said that gif is just a way of getting the routing right. But every single practical example I have seen about how to set up a VPN link between two Lans using FreeBSD boxes uses gif. I'm using gif. If I take it out and just use plain setkey and racoon, what should I substitute to get the packets addressed to my office network sent through the tunnel? Jim Hatfield
Subscriber wrote:>>-----Original Message----- >>From: Greg Panula [mailto:greg.panula@dolaninformation.com] >>Sent: 12 May 2003 11:10 >>To: Matthew Braithwaite >>Cc: stable@freebsd.org >>Subject: Re: iHEADS UP: ipsec packet filtering change >> >>You don't really need the gif tunnels for ipsec. Gif is more geared >>towards ipv4 <=> ipv6 type tunnels. A few of ipsec how-to's mention >>using gif tunnels and I've been tripped up by it, too. >> >>ipsec is much easier without the gif tunnels. The ipsec policy >>definition is explained in the setkey man page. Basically for tunnels >>it is: spdadd ${remote net} ${local net} any -P in ipsec >>esp/tunnel/${remote gateway}-${local gateway}/unqiue; and >>spdadd ${local >>net} ${remote net} any -P out ipsec esp/tunnel/${local >>gateway}-${remote >>gateway}/unique; > > > I have seen this said before. I've also seen it said that gif > is just a way of getting the routing right. But every single > practical example I have seen about how to set up a VPN link > between two Lans using FreeBSD boxes uses gif. > > I'm using gif. If I take it out and just use plain setkey and > racoon, what should I substitute to get the packets addressed > to my office network sent through the tunnel? >I have set up IPSec VPN from FreeBSD to: 1) Win2k 2) Linux (FreeS/WAN) 3) Check point VPN-1 and 4) FreeBSD Never, in any situation, did I use a GIF tunnel. You don't have to do anything to get your packets routed through the VPN, if the packet matches a policy entry in the SPD it is shipped out the VPN, otherwise it is routed normal. -stacy
On Thursday 15 May 2003 04:47 pm, Subscriber wrote:> > -----Original Message----- > > From: Greg Panula [mailto:greg.panula@dolaninformation.com] > > > > You don't really need the gif tunnels for ipsec. Gif is more > > geared towards ipv4 <=> ipv6 type tunnels. A few of ipsec how-to's > > mention using gif tunnels and I've been tripped up by it, too. > > > > ipsec is much easier without the gif tunnels. The ipsec policy > > definition is explained in the setkey man page. Basically for > > tunnels it is: spdadd ${remote net} ${local net} any -P in ipsec > > esp/tunnel/${remote gateway}-${local gateway}/unqiue; and > > spdadd ${local > > net} ${remote net} any -P out ipsec esp/tunnel/${local > > gateway}-${remote > > gateway}/unique; > > I have seen this said before. I've also seen it said that gif > is just a way of getting the routing right. But every single > practical example I have seen about how to set up a VPN link > between two Lans using FreeBSD boxes uses gif. > > I'm using gif. If I take it out and just use plain setkey and > racoon, what should I substitute to get the packets addressed > to my office network sent through the tunnel?I too have heard it said. Last fall with 4.7-stable I removed the gifconfig stuff from an IPsec tunnel I administer and lo and behold it worked! Then moved from the 4.7-stable branch of RELENG_4 to RELENG_4_7 to see if I could resolve another problem where ipfw treated packets coming out of my tunnel as having come from the interface their tunnel was routed (my external NIC, fxp1). Wanted to /dev/null any RFC 1918 addresses from the outside world but didn't want to do the same for my own RFC 1918 nets. My IPsec tunnel no longer worked in 4_7 until I uncommented the very gif stuff I had earlier removed. There is now a section in the LINT config describing current policy: # Set IPSEC_FILTERGIF to force packets coming through a gif tunnel # to be processed by any configured packet filtering (ipfw, ipf). # The default is that packets coming from a tunnel are _not_ processed; # they are assumed trusted. # # Note that enabling this can be problematic as there are no mechanisms # in place for distinguishing packets coming out of a tunnel (e.g. no # encX devices as found on openbsd). # #options IPSEC_FILTERGIF #filter ipsec packets from a tunnel -- David Kelly N4HHE, dkelly@hiwaay.net ====================================================================The human mind ordinarily operates at only ten percent of its capacity -- the rest is overhead for the operating system.