I will shortly be replacing a couple of proprietary VPN boxes with a FreeBSD solution. Section 10.10 of the Handbook has a detailed description of how to do this. However I remember a lot of discussion about a year ago about whether the gif interface was necessary to set up VPNs like this or whether it was just a convenience, for "getting the routing right". A number of people said that gif was not needed but I've never found a step-by-step description of how to set up a lan-to-lan VPN without using it. Is the Handbook the current received wisdom on how to set this up, and is the use of the gif interface indeed necessary? I also remember that the discussions diverted into a problem with ipfw when gif was *not* used, but I haven't found any messages to indicate that it was resolved. I recall suggestions that a new interface esp0 be created so that ipfw could work correctly on both the innner and outer packets of an ESP tunnel. Was that issue ever resolved? jim hatfield
On Wed, 22 Oct 2003, Jim Hatfield wrote:> Date: Wed, 22 Oct 2003 12:28:45 +0100 > From: Jim Hatfield <subscriber@insignia.com> > To: freebsd-security@freebsd.org > Subject: IPSec VPNs: to gif or not to gif > > I will shortly be replacing a couple of proprietary VPN boxes > with a FreeBSD solution. Section 10.10 of the Handbook has a > detailed description of how to do this. > > However I remember a lot of discussion about a year ago about > whether the gif interface was necessary to set up VPNs like > this or whether it was just a convenience, for "getting the > routing right". A number of people said that gif was not > needed but I've never found a step-by-step description of how > to set up a lan-to-lan VPN without using it.I use VPN with gif device. ifconfig gif0 create tunnel AA1.BB1.CC1.DD1 AA2.BB2.CC2.DD2 ifconfig gif0 inet 192.168.0.1 192.168.1.1 netmask 255.255.255.0 Create and set tunnel. Add the policy with setkey ... Start racoon server on port 500 proto UDP /usr/local/sbin/racoon -4 -l /var/log/racoon.log malyl> Is the Handbook the current received wisdom on how to set this > up, and is the use of the gif interface indeed necessary? > > I also remember that the discussions diverted into a problem > with ipfw when gif was *not* used, but I haven't found any > messages to indicate that it was resolved. I recall suggestions > that a new interface esp0 be created so that ipfw could work > correctly on both the innner and outer packets of an ESP tunnel. > > Was that issue ever resolved? > > jim hatfield > _______________________________________________ > freebsd-security@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-security > To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org" >
On Wed, Oct 22, 2003 at 12:28:45PM +0100, Jim Hatfield wrote:> I will shortly be replacing a couple of proprietary VPN boxes > with a FreeBSD solution. Section 10.10 of the Handbook has a > detailed description of how to do this. > > However I remember a lot of discussion about a year ago about > whether the gif interface was necessary to set up VPNs like > this or whether it was just a convenience, for "getting the > routing right". A number of people said that gif was not > needed but I've never found a step-by-step description of how > to set up a lan-to-lan VPN without using it. > > Is the Handbook the current received wisdom on how to set this > up, and is the use of the gif interface indeed necessary? > > I also remember that the discussions diverted into a problem > with ipfw when gif was *not* used, but I haven't found any > messages to indicate that it was resolved. I recall suggestions > that a new interface esp0 be created so that ipfw could work > correctly on both the innner and outer packets of an ESP tunnel. > > Was that issue ever resolved? >The gif(4) is not required for a proper operation of IPsec VPN, but it could be of some convenience to have it. For example, our VPN is currently built on IPsec without gif(4) interfaces, and I have to add ugly "-net 192.168/16" routes through the network interface with the 192.168.x.y primary address on the IPsec gateways which also have external IP addresses, so that "ping 192.168.z.a" selects the 192.168.x.y source address, and the traffic is wrapped into IPsec. This works, but creates lot of unneeded routes (unfilled ARP routes), and you cannot easily watch the traffic by tcpdump(1) and ipfw(8). The use of the gif(4) tunnels, and securing only them with IPsec, like described in the Handbook, should fix all these problems, so I'm seriously considering adding gif(4) tunnels. Hope this is helpful. Cheers, -- Ruslan Ermilov Sysadmin and DBA, ru@sunbay.com Sunbay Software Ltd, ru@FreeBSD.org FreeBSD committer -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-security/attachments/20031022/a0e3960b/attachment.bin
On Wed, 22 Oct 2003, Jim Hatfield wrote:> However I remember a lot of discussion about a year ago about > whether the gif interface was necessary to set up VPNs like > this or whether it was just a convenience, for "getting the > routing right". A number of people said that gif was not > needed but I've never found a step-by-step description of how > to set up a lan-to-lan VPN without using it. > > Is the Handbook the current received wisdom on how to set this > up, and is the use of the gif interface indeed necessary?I'm running fine without a gif interface ... (replaced IP addresses are the public IP's of the machines) spdadd 192.168.128.0/17[any] 192.168.0.0/17[any] any -P in ipsec esp/tunnel/a.b.c.d-w.x.y.z/require; spdadd 192.168.0.0/17[any] 192.168.128.0/17[any] any -P out ipsec esp/tunnel/w.x.y.z-a.b.c.d/require; (vice versa on the other host's setkey config) ... and then just standard remote and sainfo configs in racoon.conf> > I also remember that the discussions diverted into a problem > with ipfw when gif was *not* used, but I haven't found any > messages to indicate that it was resolved. I recall suggestions > that a new interface esp0 be created so that ipfw could work > correctly on both the innner and outer packets of an ESP tunnel. > > Was that issue ever resolved? > > jim hatfield > _______________________________________________ > freebsd-security@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-security > To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org" > >-- Matthew George SecureWorks Technical Operations
On Wed, Oct 22, 2003 at 12:28:45PM +0100, Jim Hatfield wrote:> I will shortly be replacing a couple of proprietary VPN boxes > with a FreeBSD solution. Section 10.10 of the Handbook has a > detailed description of how to do this. > > However I remember a lot of discussion about a year ago about > whether the gif interface was necessary to set up VPNs like > this or whether it was just a convenience, for "getting the > routing right". A number of people said that gif was not > needed but I've never found a step-by-step description of how > to set up a lan-to-lan VPN without using it. > > Is the Handbook the current received wisdom on how to set this > up, and is the use of the gif interface indeed necessary? > > I also remember that the discussions diverted into a problem > with ipfw when gif was *not* used, but I haven't found any > messages to indicate that it was resolved. I recall suggestions > that a new interface esp0 be created so that ipfw could work > correctly on both the innner and outer packets of an ESP tunnel. > > Was that issue ever resolved? > > jim hatfield > _______________________________________________ > freebsd-security@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-security > To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org"I think one reason someone might want to use gif interfaces is becuase trasport mode ipsec doesn't require the peer address, if you then do a gif tunnel over the transport ipsec you have dynamic vpn based on a 509 cert or some crazy jazz like that. I however just do tunnel mode ipsec with no gif tunnel and packet filter to only allow protocol 50 and udp 500 to/from the remote peer. If any of the kame folks are watching, thanks for writing racoon!
Jim Hatfield wrote:> I will shortly be replacing a couple of proprietary VPN boxes > with a FreeBSD solution. Section 10.10 of the Handbook has a > detailed description of how to do this. > > However I remember a lot of discussion about a year ago about > whether the gif interface was necessary to set up VPNs like > this or whether it was just a convenience, for "getting the > routing right". A number of people said that gif was not > needed but I've never found a step-by-step description of how > to set up a lan-to-lan VPN without using it. > > Is the Handbook the current received wisdom on how to set this > up, and is the use of the gif interface indeed necessary?Nope, gif interfaces aren't needed. Just use tunnel mode.> > I also remember that the discussions diverted into a problem > with ipfw when gif was *not* used, but I haven't found any > messages to indicate that it was resolved. I recall suggestions > that a new interface esp0 be created so that ipfw could work > correctly on both the innner and outer packets of an ESP tunnel. > > Was that issue ever resolved?The issue was put to bed. Reference: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/ip_input.c?rev=1.214&content-type=text/x-cvsweb-markup http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/ip_input.c?rev=1.130.2.48&content-type=text/x-cvsweb-markup http://docs.freebsd.org/cgi/getmsg.cgi?fetch=132950+0+/usr/local/www/db/text/2001/freebsd-security/20010325.freebsd-security Current behavior is encrypted packet is handled by ipfw once, then after decryption it is only handled by ipfw(again) if it passes thru an interface didn't arrive on. Example. ipsec tunnel between two gateways(1.1.1.1 & 2.2.2.2) encrypts traffic between two lans(3.3.3.0/24 & 4.4.4.0/24). When 3.3.3.3 sends traffic to 4.4.4.4, 1.1.1.1 and 2.2.2.2 send esp traffic between each other. Say that traffic arrives on fxp0, the firewall rules that would handle it would be: allow esp from 1.1.1.1 to 2.2.2.2 in via fxp0 allow esp from 2.2.2.2 to 1.1.1.1 out via fxp0 Then the packets would be decrypted and passed onto the final destination, handled by the firewall rules on another nic: allow tcp from 3.3.3.3 to 4.4.4.4 out via fxp1 allow tcp from 4.4.4.4 to 3.3.3.3 in via fxp1 Filtering between 3.3.3.0/24 and 4.4.4.0/24 is done on the internal interface(fxp1 in the example). It works unless one wants to do something with the decrypted packet before it left the arriving interface. Example: ipsec tunnel between firewall(1.1.1.1) and wireless client(2.2.2.2) wireless client use ipsec in tunnel to encrypt all traffic leaving it, tunnel end-point is the firewall. Firewall then NATs the client's traffic allowing it access to the internet. Rub is the setting up of stateful rules. # allow ipsec traffic via wireless segment allow esp from any to any via fxp1 # nat internal traffic before it leaves divert natd ip from 2.2.2.0/24 to any out fxp0 # de-nat arriving traffic divert natd ip from any to 216.136.204.117 in via fxp0 # stateful rules check-state # This rule would setup a stateful rule allowing # the private address to converse with a public address # but the current behavior doesn't let the firewall # see the decrypted traffic on fxp1 allow tcp from 2.2.2.0/24 to any keep-state in via fxp1 # This rule sets up the stateful rule for allowing # the public nat-to address access allow tcp from 216.136.204.117 to any keep-state out via fxp0 The behavior with the stateful rules that would allow the above setup to work properly *if* decrypted packet were see by ipfw on the arriving interface is that the dynamic rules created by keep-state *don't* keep track of the interface they were created by... they only keep track of time, source and destination. Since traffic is nat'd before leaving the public interface(fxp0) and a stateful rule is setup for the public address, one ends up with deny messages for traffic addressed to the client arriving on the public interface. A bad kludge of a work-around is... allow tcp from any to 2.2.2.2 keep-state in via fxp0 If one uses a gif tunnel between the firewall and wireless and then runs ipsec thru that, then they can use the IPSEC_FILTERGIF option to have decrypted packets re-processed. Hope that helps, greg
On Wed, 22 Oct 2003 13:34:30 +0100, in local.freebsd.security you wrote:> >I use gif interfaces for my VPN's, and it works extremely well. The >only other solution I think I would even try, is mpd, but that uses a >much weaker protocol from what I know (PPTP). > >It's so easy to use gif, I'm not sure why you wouldn't.Looking at the Handbook again, I'm even more confused now! I had decided that the IPSec processing must be using Transport mode, since the tunnelling was handled by the gif interface. But not so. The diagram right at the bottom of that section of the Handbook clearly shows that the original packet is encapsulated twice, once by IPSec Tunnel mode and once by the gif interface. To me, this just feels wrong. The packet only needs to be encapsulated once, so why do it twice? It's an unnecessary use of bandwidth and processor time.
Hello Jim, Wednesday, October 22, 2003, 2:28:45 PM, you wrote: JH> I will shortly be replacing a couple of proprietary VPN boxes JH> with a FreeBSD solution. Section 10.10 of the Handbook has a JH> detailed description of how to do this. JH> However I remember a lot of discussion about a year ago about JH> whether the gif interface was necessary to set up VPNs like JH> this or whether it was just a convenience, for "getting the JH> routing right". A number of people said that gif was not JH> needed but I've never found a step-by-step description of how JH> to set up a lan-to-lan VPN without using it. I use gif interface and tunneling mode, but can see any advantage of this, because i can not see packets that pass through gif interface. I try different configuration of ip addresses to the interface, but nothing change. This i maybe a error in the configuration but i see encapsulated packets and packets that pass through IPSec tunnel on my network card. JH> Is the Handbook the current received wisdom on how to set this JH> up, and is the use of the gif interface indeed necessary? JH> I also remember that the discussions diverted into a problem JH> with ipfw when gif was *not* used, but I haven't found any JH> messages to indicate that it was resolved. I recall suggestions JH> that a new interface esp0 be created so that ipfw could work JH> correctly on both the innner and outer packets of an ESP tunnel. JH> Was that issue ever resolved? JH> jim hatfield JH> _______________________________________________ JH> freebsd-security@freebsd.org mailing list JH> http://lists.freebsd.org/mailman/listinfo/freebsd-security JH> To unsubscribe, send any mail to JH> "freebsd-security-unsubscribe@freebsd.org" -- Best regards, Nikolay mailinglists@hq.panda.bg
On Thu, 23 Oct 2003 12:23:03 +0100, in local.freebsd.security you wrote:>The issue was put to bed. >Reference: >http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/ip_input.c?rev=1.2 >14&content-type=text/x-cvsweb-markup >http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/ip_input.c?rev=1.1 >30.2.48&content-type=text/x-cvsweb-markup >http://docs.freebsd.org/cgi/getmsg.cgi?fetch=132950+0+/usr/local/www/db/ >text/2001/freebsd-security/20010325.freebsd-security > >Current behavior is encrypted packet is handled by ipfw once, then after > >decryption it is only handled by ipfw(again) if it passes thru an >interface didn't arrive on.Many thanks, that's very helpful. Jim
Jim Hatfield wrote:>I will shortly be replacing a couple of proprietary VPN boxes >with a FreeBSD solution. Section 10.10 of the Handbook has a >detailed description of how to do this. > >However I remember a lot of discussion about a year ago about >whether the gif interface was necessary to set up VPNs like >this or whether it was just a convenience, for "getting the >routing right". A number of people said that gif was not >needed but I've never found a step-by-step description of how >to set up a lan-to-lan VPN without using it. >I use gif interfaces for my VPN's, and it works extremely well. The only other solution I think I would even try, is mpd, but that uses a much weaker protocol from what I know (PPTP). It's so easy to use gif, I'm not sure why you wouldn't. Eric -- ------------------------------------------------------------------ Eric Anderson Systems Administrator Centaur Technology All generalizations are false, including this one. ------------------------------------------------------------------