Date: Thu, 23 Oct 2003 06:23:03 -0500 From: "G. Panula" <greg.panula@lexisnexis.com> To: security@freebsd.org Subject: Re: IPSec VPNs: to gif or not to gif Message-ID: <3F97BA17.8050403@lexisnexis.com> In-Reply-To: <u0qcpv0csl3lb1p6a8aioe7qjqjtvd6th9@4ax.com> References: <u0qcpv0csl3lb1p6a8aioe7qjqjtvd6th9@4ax.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3F97BA17.8050403>